Re: [rfc2462bis] what is the stateful configuration protocol

[JINMEI Tatuya / $B?@L at C#:H(B <jinmei at isl.rdc.toshiba.co.jp>]

>>>>> On Wed, 14 Apr 2004 06:48:57 -0400, 
>>>>> Ralph Droms <rdroms@cisco.com> said:

> I think DHCPv6 ought to be cited as the protocol for other configuration
> information, as well.

> However, it seems to me the phrase "stateful protocol for *other*
> configurations" is a little misleading.  I think the word "stateful" could
> be dropped.

You're running too fast despite the prior notice:-) But anyway, this
thread is surely useful for rfc2462bis.  Thanks for raising this
topic.

(I won't try to make a response to each follow-up in this sub-thread,
but I've read all of them.)

It seems to me that we are discussing two (almost) different issues:

1. whether "stateless" is an appropriate word to describe the address
   autoconfiguration mechanism specified in RFC2462 (and bis)
2. whether we need the M/O flags in the first place

Regarding issue 1, I personally think "stateless" is appropriate, at
least in the sense that we don't have to reword it in rfc2462bis.

In fact, RFC2462 clearly says what "stateless" means in that
document.  For example, it says in Introduction:

   Stateless autoconfiguration requires no manual
   configuration of hosts, minimal (if any) configuration of routers,
   and no additional servers.

which means it's a "third-party-serverless" mechanism.  Also, the
following sentence clearly shows that it is an "autonomous"
configuration mechanism:

   The stateless mechanism allows a host to
   generate its own addresses using a combination of locally available
   information and information advertised by routers.

If we are making a brand-new specification, it might make sense to
reconsider the wording from the scratch.  However, "stateless address
autoconfiguration" has been used for quite a long period (almost for
10 years?), and is used in many documents, including in the title of
RFC2462 itself.

So, I don't think the advantage of rewording is worth the expected
confusion.

Issue 2 is a big question...it may even affect the "consensus" we just
made in the first (and original) part of this thread.  I'm going to
make a separate thread for this.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					jinmei@isl.rdc.toshiba.co.jp

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------