Subject: RE: [rfc2462bis] reword "stateful" for other config info?

From: "Bound, Jim" <[email-masked]>
Date: Fri, 21 May 2004 23:08:24 -0400

Jinmei,

Your wording works for me well.  Good suggestion too.

/jim 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of JINMEI Tatuya / ????
> Sent: Friday, May 21, 2004 4:12 AM
> To: [email-masked]
> Subject: [rfc2462bis] reword "stateful" for other config info?
> 
> One (perhaps last) question about the M/O flags for rfc2462bis:
> 
> Currently, RFC2462 uses the term "stateful" as the counter 
> part of the "stateless" configuration defined in RFC2462, 
> both for address configuration (the M flag) and for other 
> configuration (the O flag).
> 
> Using "stateful" should be okay for address configuration 
> (the M flag part).
> 
> However, as Ralph pointed out before, "stateful" may not be 
> appropriate for other configuration information:
> https://www1.ietf.org/mail-archive/working-groups/ipv6/current
> /msg02262.html
> 
> In particular, the fact that RFC3736 (which we are primarily 
> considering as the protocol for the O flag) is entitled 
> "*Stateless* Dynamic Host Configuration Protocol (DHCP) 
> Service for IPv6" will confuse implementors if we keep 
> calling it "stateful" in rfc2462bis.
> 
> So, I strongly believe we should clarify this point in some way.
> Possible solutions would include:
> 
> 1. remove "stateful" from the definition of the O flag (in
>    rfc2461bis), that is, change
> 
>       O              1-bit "Other stateful configuration" flag.  When
>                      set, hosts use the administered 
> (stateful) protocol
>                      for autoconfiguration of other (non-address)
>                      information.  The use of this flag is 
> described in
>                      [ADDRCONF].
>       (RFC2461 Section 4.2)
> 
>    to (e.g.):
> 
>       O              1-bit "Other configuration" flag.  When
>                      set, hosts use a separate protocol
>                      for autoconfiguration of other (non-address)
>                      information.  The use of this flag is 
> described in
>                      [ADDRCONF].
> 
>    and reword rfc2462bis accordingly.
> 
> 2. do not touch the definition of the O flag, but add notes for
>    clarification in rfc2462bis like this:
> 
>       While the flag and the corresponding protocol are called
>       "stateful" in order to highlight the contrast to the stateless
>       protocol defined in this document, the intended protocol
>       [RFC3736] is also defined to work in a stateless fashion.  This
>       is based on a result, through experiments, that all known
>       "other" configuration information can be managed by a stateless
>       server, that is, a server that does not maintain state of each
>       client that the server provides with the configuration
>       information.
> 
> I personally prefer the former with small preference since it 
> should be a cleaner clarification.  But I can live with the 
> second approach, too.
> 
> What do others think?  Is there any other opinions?
> 
> 					JINMEI, Tatuya
> 					Communication Platform Lab.
> 					Corporate R&D Center, 
> Toshiba Corp.
> 					[email-masked]
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 
> 
1H>����"�+��fj)b�	b�ة�����+�f�x�������z����!��l��0�X���+����Y���b�ا~���

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Sun, 23 May 2004 14:15:54 +0900

>>>>> On Fri, 21 May 2004 23:08:24 -0400, 
>>>>> "Bound, Jim" <[email-masked]> said:

> Your wording works for me well.  Good suggestion too.

Thanks, glad to hear that.  But please let me check one thing: do you
have any preference between the solutions?  That is,

>> rfc2461bis), [...]

or

>> clarification in rfc2462bis like this:
[snip]

I guess you meant solution 2 by "wording", but I'm not really sure.

Thanks,

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]