headers
Brian Haberman | 1 Dec 2003 13:21

Re: comments on rfc2011 update


Wes Hardaker wrote:

> Unfortunately, I have just learned that I'd really need this update.
> I'll say this is unfortunate because the cutoff date for comment is
> tomorrow, and I haven't had a chance to read the document.

I would encourage you to make comments anyway.  This MIB won't
be published right away due to a dependency on an updated Inet
Address TC document.

> 
> However, a really really really quick scan produced a couple of
> comments.
> 
> 1) The description field for the ipAddressEntry object is simply
>    ridiculously short:
>         "inet addr entry"
> 
> 2) Was there every discussion about making this table writable?  One
>    of the most longstanding needs within MIBs has been the ability to
>    assign addresses to interfaces.  I will have to go back and search
>    the mail archives to find out if this was ever discussed, but it
>    would be pretty simple, I would think, to make this table
>    writable.  This is the obvious place to make support for settable
>    addresses, so I'm curious as to why it wasn't done...
> 

I don't recall this specific topic being discussed.  However, there are
several MIBs that have gone to having multiple conformance statements.
(Continue reading)

Permalink | Reply | 4 comments |
headers
Pascal Thubert (pthubert | 1 Dec 2003 13:48
Picon
Favicon

ND model for routers

Exactly :)

Seems to me that the "ROUTERS" vs. "routers" discussion had the wrong
focus, as Pekka mentioned.

The question may not be about the definition of a router, but rather how
does a box with forwarding/redistributing capabilities present that to
the network at ND level. 

ND seems to say routers send RAs and the rest of the hosts send NAs. And
the real world shows us nodes that do not wish to comply with the ND
model. Proposal is to extend ND, not to change the world.

Pascal

> -----Original Message-----
> From: Mark Smith
[mailto:ipv6 <at> c753173126e0bc8b057a22829880cf26.nosense.org]
> Sent: mercredi 26 novembre 2003 06:45
> To: Pascal Thubert (pthubert)
> Cc: he <at> uninett.no; ftemplin <at> iprg.nokia.com; ipv6 <at> ietf.org;
v6ops <at> ops.ietf.org
> Subject: Re: "ROUTERS" vs. "routers"
> 
> On Tue, 25 Nov 2003 15:22:43 -0000
> "Pascal Thubert (pthubert)" <pthubert <at> cisco.com> wrote:
> 
> > - A PC with multiple Network addressable entities such as storage
media
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Internet-Drafts | 1 Dec 2003 21:29
Picon
Favicon

I-D ACTION:draft-ietf-ipv6-rfc2012-update-05.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Version 6 Working Group Working Group of the IETF.

	Title		: Management Information Base for the Transmission Control Protocol (TCP)
	Author(s)	: R. Raghunarayan
	Filename	: draft-ietf-ipv6-rfc2012-update-05.txt
	Pages		: 27
	Date		: 2003-12-1
	
This memo defines a portion of the Management Information Base (MIB) 
for use with network management protocols in the Internet community.  
In particular, it describes managed objects used for implementations 
of the Transmission Control Protocol (TCP) in an IP version 
independent manner. This memo obsoletes RFCs 2012 and 2452.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipv6-rfc2012-update-05.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ipv6-rfc2012-update-05.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
(Continue reading)

Permalink | Reply | 0 comments |
headers
Internet-Drafts | 1 Dec 2003 21:29
Picon
Favicon

I-D ACTION:draft-ietf-ipv6-rfc2012-update-05.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Version 6 Working Group Working Group of the IETF.

	Title		: Management Information Base for the Transmission Control Protocol (TCP)
	Author(s)	: R. Raghunarayan
	Filename	: draft-ietf-ipv6-rfc2012-update-05.txt
	Pages		: 27
	Date		: 2003-12-1
	
This memo defines a portion of the Management Information Base (MIB) 
for use with network management protocols in the Internet community.  
In particular, it describes managed objects used for implementations 
of the Transmission Control Protocol (TCP) in an IP version 
independent manner. This memo obsoletes RFCs 2012 and 2452.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipv6-rfc2012-update-05.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ipv6-rfc2012-update-05.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
(Continue reading)

Permalink | Reply | 0 comments |
headers
Shawn A. Routhier | 2 Dec 2003 01:04
Favicon

Re: comments on rfc2011 update

At 07:21 AM 12/1/03 -0500, Brian Haberman wrote:

>Wes Hardaker wrote:
>
>>Unfortunately, I have just learned that I'd really need this update.
>>I'll say this is unfortunate because the cutoff date for comment is
>>tomorrow, and I haven't had a chance to read the document.
>
>I would encourage you to make comments anyway.  This MIB won't
>be published right away due to a dependency on an updated Inet
>Address TC document.
>
>>However, a really really really quick scan produced a couple of
>>comments.
>>1) The description field for the ipAddressEntry object is simply
>>   ridiculously short:
>>        "inet addr entry"

As the editor I thought the description for the table object (ipAddressTable)
covered the entry object as well and therefore repeating the same text would
not be useful. Do you think there is something else that should be added to
the description of the entry that isn't in the description of the table?

DESCRIPTION
           "This table contains addressing information relevant to the
            entity's interfaces.

            This table does not contain multicast address information.
            Tables for such information should be contained in multicast
            specific MIBs such as RFC3019.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Wes Hardaker | 2 Dec 2003 03:57

Re: comments on rfc2011 update

>>>>> On Mon, 01 Dec 2003 16:04:26 -0800, "Shawn  A. Routhier" <shawn.routhier <at> windriver.com> said:

>>> 1) The description field for the ipAddressEntry object is simply
>>> ridiculously short:
>>> "inet addr entry"

Shawn> As the editor I thought the description for the table object
Shawn> (ipAddressTable) covered the entry object as well and therefore
Shawn> repeating the same text would not be useful. Do you think there
Shawn> is something else that should be added to the description of
Shawn> the entry that isn't in the description of the table?

"Internet address entry" would have been better.  As is, it just
appears as if the author was in a huge hurry.  Have about: "An address
mapping for a particular interface."?

>>> 2) Was there every discussion about making this table writable?
...
>> I don't recall this specific topic being discussed.

Shawn> As with Brian I don't recall this specific topic being
Shawn> discussed.

Well, then my next question would then be: Is it too late to do this?
It would basically just mean:

1) making ipAddressIfIndex, ipAddressType, & ipAddressPrefix
   MAX-ACCESS clauses read "read-create".

2) Adding a new column: "ipAddressRowStatus" of type RowStatus.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Juergen Schoenwaelder | 2 Dec 2003 14:53
Picon

Re: comments on rfc2011 update

On Mon, Dec 01, 2003 at 06:57:08PM -0800, Wes Hardaker wrote:

> Well, then my next question would then be: Is it too late to do this?
> It would basically just mean:
> 
> 1) making ipAddressIfIndex, ipAddressType, & ipAddressPrefix
>    MAX-ACCESS clauses read "read-create".
> 
> 2) Adding a new column: "ipAddressRowStatus" of type RowStatus.
> 
> 3) Maybe changing the conformance statements to allow the
>    optionality of the writable aspect of it.

You probably also want to have a StorageType column for this.

/js

--

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 <at> ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
Permalink | Reply | 0 comments |
headers
Shawn A. Routhier | 2 Dec 2003 23:14
Favicon

Re: comments on rfc2011 update

At 06:57 PM 12/1/03 -0800, Wes Hardaker wrote:
>>>>>> On Mon, 01 Dec 2003 16:04:26 -0800, "Shawn  A. Routhier" <shawn.routhier <at> windriver.com> said:
>
>>>> 1) The description field for the ipAddressEntry object is simply
>>>> ridiculously short:
>>>> "inet addr entry"
>
>Shawn> As the editor I thought the description for the table object
>Shawn> (ipAddressTable) covered the entry object as well and therefore
>Shawn> repeating the same text would not be useful. Do you think there
>Shawn> is something else that should be added to the description of
>Shawn> the entry that isn't in the description of the table?
>
>"Internet address entry" would have been better.  As is, it just
>appears as if the author was in a huge hurry.  Have about: "An address
>mapping for a particular interface."?
>
>>>> 2) Was there every discussion about making this table writable?
>...
>>> I don't recall this specific topic being discussed.
>
>Shawn> As with Brian I don't recall this specific topic being
>Shawn> discussed.
>
>Well, then my next question would then be: Is it too late to do this?

I suppose that's up to the chairs and the WG.  The document has finished
WG last call, I don't know if these changes would require a new last call
or not.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tony Hain | 3 Dec 2003 23:07

RE: routers - (was: Re: "ROUTERS" vs. "routers")

Erik Nordmark wrote:
> >  Hosts with embedded gateway
> > functions, as described in RFC 1122, section 3.3.4.2 under: "Weak ES
> > Model" also qaulify as routers, and it doesn't matter at all what
> > different routers advertise - they are all still just *routers*.
> 
> That wouldn't be consistent with the definition of router
> in RFC 2460; a node which forwards packets not explicitly addressed
> to itself.
> A host in the weak ES model would still only handle packets destined to
> the addresses assigned to that host; hence it isn't a router per the
> RFC 2460 definition.

What does one call a device that runs an app which acts as an intermediary
to set up or authenticate access to an iSCSI array? Connecting to the app
would imply 'host', but if that is a multi-party app and the node simply
forwards subsequent packets directly to the array, it would fit 'router'. 

We should stop talking about boxes and talk about functions that any
specific node might perform. Some operational environments want to dedicate
a box to a function, and others want to minimize the number of managed
objects so they will run multiple functions on a box.

Tony 

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 <at> ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
(Continue reading)

Permalink | Reply | 0 comments |
headers
john.loughney | 4 Dec 2003 12:13
Picon

RE: Node Req: Issue31: DHCPv6 text (ignore previous mails)

Hi Thomas,

The 2nd paragraph of the current node requirements draft says

   For those IPv6 Nodes (acting as hosts) that implement DHCP, those
   nodes MUST use DHCP upon the receipt of a Router Advertisement with
   the 'O' flag set (see section 5.5.3 of RFC2462).  In addition, in the
   absence of a router, hosts that implement DHCP MUST attempt to use
   DHCP. For IPv6 Nodes that do not implement DHCP, the 'O' flag of a
   Router Advertisement can be ignored.  Furthermore, in the absence of
   a router, these types of node are not required to initiate DHCP.

You said:

> For my tastes, there is too much protocol specification above (use of
> MUST language). Better to just cite the existing standards.

and:

   For those IPv6 Nodes (acting as hosts) that implement DHCP, those
   nodes should use DHCP upon the receipt of a Router Advertisement with
   the 'O' flag set (see section 5.5.3 of RFC2462).  In addition, in the
   absence of a router, hosts that implement DHCP MUST attempt to use
   DHCP. For IPv6 Nodes that do not implement DHCP, the 'O' flag of a
   Router Advertisement can be ignored.  Furthermore, in the absence of
   a router, these types of node are not required to initiate DHCP.

> Perhaps because folk have forgotten about existing text in 2461 &
> 2462? :-)
>
(Continue reading)

Permalink | Reply | 7 comments |

Gmane