Subject: RE: draft-ietf-ipv6-node-requirements-03.txt

From: "Bound, Jim" <[email-masked]>
Date: Sun, 9 Mar 2003 22:01:23 -0500

To further support a SHOULD:  In 2119 it states:

3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.

The full implications documented in 5.3 in fact are justfication based
on RFC 2119 why Stateful Address Configuration for this document should
be  SHOULD.  The M or O bit are valid conditions equal to stateless
within the IPv6 architecture.  There have been some who would have liked
to see stateless only in the architecture but they lost that battle and
stateful is as important to the architecture as is stateless. In
addition it is a user choice in the market.  Implementers who do not
wish to support stateful have that choice but we in the IETF have the
responsibility to assure interoperable implementations based on the
standards that precede the ones we work on later.  The default for ND is
stateless but the M or O bit imply a condition where the option is in
fact used.  This nodes requirement document must deal with the end
result of all possibilities from ND on the link.  One of those is
stateful address configuration.  From the major interoperability
problems that can happen to a users network it should be a SHOULD.
 
5. MAY   This word, or the adjective "OPTIONAL", mean that an item is
   truly optional.  One vendor may choose to include the item because a
   particular marketplace requires it or because the vendor feels that
   it enhances the product while another vendor may omit the same item.
   An implementation which does not include a particular option MUST be
   prepared to interoperate with another implementation which does
   include the option, though perhaps with reduced functionality. In the
   same vein an implementation which does include a particular option
   MUST be prepared to interoperate with another implementation which
   does not include the option (except, of course, for the feature the
   option provides.)

If the user sets the M or O bit as policy a node that has not
implemented stateful address configuration by definition cannot
communicate beyond the link.  The moment the M or O bit is received the
node becomes unable to do the most basic functions for IPv6, which is
obtain addresses with a scope greather than link-local.  For that reason
MAY does not apply.

The logic is that making it a SHOULD states that if a market will never
use stateful then it is safe and a good reason to not build a product
that supports stateful address configuration.  Where a MAY implies it is
only optional and that is not the case when the M or O bit is received.

Regards,
/jim

>-----Original Message-----
>From: Bound, Jim 
>Sent: Sunday, March 09, 2003 9:39 PM
>To: IPV6 WG
>Subject: draft-ietf-ipv6-node-requirements-03.txt
>
>
>
>4.5.5 Stateful Address Autoconfiguration
>Stateful Address Autoconfiguration MAY be supported. DHCP 
>[DHCPv6] is the standard stateful address configuration 
>protocol. See section 5.3 for details on DHCP.
>
>The above MAY should be a SHOULD.  There is not mention of 
>stateful support from ND M or O bits being MAY.  They simply 
>can be used.  It is the option of the user not the standard.  
>To not support any bits suggested for use by users equal to 
>stateless in the ND spec is irresponsible for interoperability 
>requirements in this standards track document.  This not being 
>a SHOULD can cause sever interoperability for clients where 
>the user wants all clients to use stateful auto configuration. 
> Any assumption that it will not be used is premature and we 
>should error on the side of it being used.
>
>The wording in 5.3 supports the reason for a SHOULD in this section.
>
>I could argue it is a MUST but at minimum it is a SHOULD.
>
>Regards,
>/jim
>

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------