Subject: RE: Proposed M&O bits text for RFC2461bis

From: "Gray, Eric" <[email-masked]>
Date: Tue, 18 Apr 2006 06:49:20 -0400

Erik,

	In some cases, people feel that SHOULD is weaker than indicated
in RFC 2119.  In others, people feel it is stronger.

	IMO, if we're not going to formally redefine the meaning, we're
obligated not to redefine it informally by usage.  Otherwise, what is
the purpose of inserting the phrase that states that these words have
the meaning defined in RFC 2119?

--
Eric 

--> -----Original Message-----
--> From: Erik Nordmark [mailto:[email-masked]] 
--> Sent: Monday, April 17, 2006 5:52 PM
--> To: Thomas Narten
--> Cc: IPv6 Mailing List
--> Subject: Re: Proposed M&O bits text for RFC2461bis
--> 
--> Thomas Narten wrote:
--> 
--> >> I think making that a SHOULD is premature and too 
--> strong, since we
--> >> haven't explored what the desirable behaviors are when 
--> both M and A
--> >> bits are set.  (When M is set and no prefix has A, then 
--> using DHCP
--> >> is a no-brainer.)
--> > 
--> > Here is how RFC 2119 defines SHOULD:
--> > 
--> >      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.
--> > 
--> > That is, it is not a standards violation to not follow this, but
--> > unless you have a good reason to ignore the advice, follow it.
--> > 
--> > Given that, I think SHOULD is exactly right. This is what
--> > implementations (that don't know any better) ought to be doing.
--> 
--> I've seen to many places were a stronger meaning has been 
--> assigned to 
--> "SHOULD" to be happy with this. For instance, the 
--> implication has been 
--> that to be fully compliant all MUST/MUST NOT has to be 
--> satisfied, as 
--> well as all SHOULD/SHOULD NOT, and some vaguer notion of 
--> "conditional 
--> compliance" or something like it if all the SHOULD/SHOULD 
--> NOT are not 
--> satisfied.
--> 
--> >> I can imagine that a host wants to have the option to 
--> have local policy 
--> >> to handle the case when both M and A bits are set, but 
--> there is nothing 
--> >> in the "SHOULD" that allows for local policy control.
--> > 
--> > I can imagine that too. (And while I'm skeptical that this would
--> > actually be useful in practice, that's beside the point). 
--> Adding such
--> > a local option seems like a fine thing for 
--> implementations to add if
--> > they want to. Nothing in our standards prevents an 
--> implementation from
--> > doing so, and neither would the SHOULD above.
--> 
--> We have a history of making such knobs explicit - for 
--> instance, see the 
--> discussion about default values in RFC 1122.
--> 
--> If what we really want to say is
--> 	An implementation MAY have a configuration option ignore
--> 	stateless addresses and/or stateful (DHCPv6) addresses when both
--> 	are present from their configuration protocols. If so, that
--> 	option SHOULD default to accepting addresses from both stateless
--> 	and DHCPv6.
--> then why can't we explicitly say that?
--> 
-->     Erik
--> 
--> 
--> 
--> 
--> --------------------------------------------------------------------
--> IETF IPv6 working group mailing list
--> [email-masked]
--> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--> --------------------------------------------------------------------
--> 

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: "Durand, Alain" <[email-masked]>
Date: Tue, 18 Apr 2006 10:39:37 -0400

> -----Original Message-----
> From: Thomas Narten [mailto:[email-masked]] 
> Sent: Tuesday, April 18, 2006 9:34 AM
> To: Durand, Alain
> Cc: Ralph Droms; Erik Nordmark; IPv6 Mailing List
> Subject: Re: Proposed M&O bits text for RFC2461bis 
> 
> "Durand, Alain" <[email-masked]> writes:
> 
> > BTW, M&A bot set *is* a valid configuration, where on the 
> same subnet 
> > one would like to use both servers that want to use nothing 
> but DHCP 
> > and laptops who are perfectly happy with stateless autoconf 
> (or small 
> > devices who do not have  implemented anything else)
> 
> This is the crux of the fundamental underlying disagreement 
> we are having on what we are trying to solve here.
> 
> In my view, it is nuts to have devices "that choose to 
> implement only stateless addrconf" because they are "simple" 
> or "perfectly happy" or something. If we go down this route, 
> it is not an operational choice whether to run DHC, because 
> implementations have already made that choice.

I agree with you 100% that implementing only stateless
because it is simpler is "nuts". If you look at the number
of packets that need to be exchanged, DHCP is really not that
hard.

However, one need to deal with today's reality.

It seems to still be the case in 2006 that most implementations only
offer stateless autoconf. There is some kind of myth that this
is "enough".

I'm designing a network where this is clearly not "enough" and
we have made a decision (for many reasons) to push for DHCPv6
address provisioning. I can get this on some critical devices
but I have to be realistic and deal with the fact that DHCPv6
code is still hard to get and there will be many years where
DHCP-enabled and non-DHCP-enabled devices may have to co-exist
on the same subnets.

    - Alain.

---

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Tue, 18 Apr 2006 10:40:38 -0400

Thomas:

I fully agree with you.

I think these two bits have consumed way more time than they should have
- they'll probably go down as the most contested two bits in the history
of the IETF. For something so simple, it is utterly crazy.

- Bernie 

> Cc: Erik Nordmark; IPv6 Mailing List; Ralph Droms (rdroms)
> but DHCP and
> > laptops who are perfectly happy with stateless autoconf (or 
> small devices
> > who do not have  implemented anything else)
> 
> This is the crux of the fundamental underlying disagreement we are
> having on what we are trying to solve here.
> 
> In my view, it is nuts to have devices "that choose to implement only
> stateless addrconf" because they are "simple" or "perfectly happy" or
> something. If we go down this route, it is not an operational choice
> whether to run DHC, because implementations have already made that
> choice.
> 
> If folk chose not to implement DHC or stateless addrconf, that is
> fine, and that is their choice. But the consequences may well be that
> they can't get addresses in all environments. We need to be
> clear/truthful about that. You seem to be suggesting that this  is not
> acceptable and that instead, operations need to provide stateless addr
> conf in all cases since some devices may require that. Is this
> _really_ what you intend?
> 
> Having the M&O bits say "use dhc" (if you have implemented it) or
> "don't bother with DHC" is useful, independent of the above.  But what
> seems to be happening now (as in the past) is that the M&O bits are
> being viewed as somehow mandating the implementation of DHC, and folk
> don't want that.
> 
> IMO, having the M bit say "invoke DHC" does not mandate implementing
> DHC any more than having an RA a Prefix Information Option with the
> "A" bit set "mandates" that one MUST implement stateless address
> autoconfiguration.
> 
> And, BTW, I know of one implementation that does NOT implement
> stateless addr conf and isn't all bent of out shape the specs seeming
> to require (or not require) implementation of stateless
> autoconfiguration. So I really do not understand why we are making
> such a big deal out of this.
> 
> Chairs, Perhaps we need to just accept that we can't get consensus on
> revised wording for the M&O bits and leave the text unchanged
> relative to RFC2461?
> 
> It's long past time for getting closure on this issue and moving on,
> yet we continue to have the same back-and-forth on the mailing
> list. :-(
> 
> Thomas
> 
>

---

From: "Durand, Alain" <[email-masked]>
Date: Wed, 19 Apr 2006 21:48:03 -0400

> From: Bob Hinden [mailto:[email-masked]] 
> I made the assumption that from the clients point of view, 
> DHCPv6 and DHCPv6-lite are equivalent and didn't call out 
> DHCPv6-lite separately in the O flag description.  Please 
> correct me if I am wrong about this.

I'll agree with this. But should we take this to the next logical step,
i.e. just define one bit?

  - Alain.

---

From: Tim Hartrick <[email-masked]>
Date: 20 Apr 2006 09:48:12 -0700

All,

> i.e. just define one bit?

I disagree with this.  If it will prevent such talk we should add a
reference to DHCPv6-lite.

Can we ship this spec.  Please.....

Tim Hartrick

---

From: "Soliman, Hesham" <[email-masked]>
Date: Thu, 20 Apr 2006 10:26:03 -0700

> Can we ship this spec.  Please.....

=> I couldn't agree more. I'm fine with the first version of Ralph's 
suggested text. 

Hesham

---

From: "Soliman, Hesham" <[email-masked]>
Date: Thu, 20 Apr 2006 12:58:59 -0700

> offer stateless autoconf. There is some kind of myth that this

=> Hmm. I find both of the statements above surprising. 
It's not a myth that the node requirements document says 
that stateless is the only mandatory option. You can't blame an
implementer for not implementing a MAY in the doc. 

Hesham

---

From: "Soliman, Hesham" <[email-masked]>
Date: Wed, 19 Apr 2006 22:11:46 -0700

Hesham

---

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Sat, 22 Apr 2006 00:33:00 -0400

I'm also happy with Bob's wording (but also with what Ralph and Thomas
produced).

Bob's wording also leaves it to the DHCPv6 specifications as to how to
do DHCPv6, which is far better than putting more specific details in
RFC2461bis.

But, again, I'm happy with either and do want to see this move forward.

- Bernie

> From: Manfredi, Albert E [mailto:[email-masked]] 
> Sent: Friday, April 21, 2006 4:24 PM
> To: Soliman, Hesham; IPv6 Mailing List
> Subject: RE: Proposed M&O bits text for RFC2461bis
> 
> At the risk of being accused of dragging out this discussion 
> beyond the
> 10 year mark, I'm in favor of Bob's wording. I agree with his 
> rationale
> too.
> 
> Bert
> 
> 
> > From: Soliman, Hesham [mailto:[email-masked]] 
> > Sent: Friday, April 21, 2006 10:57 AM
> > To: Bob Hinden; IPv6 Mailing List
> > Subject: RE: Proposed M&O bits text for RFC2461bis
> > 
> > Folks,
> > 
> > Please take a look at Bob's text below. I'd like to suggest that 
> > we replace the current text in 2461bis with the one below. 
> > Any objections? I'll wait for another week before I can conclude
> > that we agree on this, i.e. if no one responds. 
> > 
> > Hesham 
> > 
> > 
> > 
> > 
> > 
> > 
> >  > For example:
> >  > 
> >  >     M :
> >  >          1-bit "Managed address configuration" flag.  
> When set, it
> >  >          indicates that addresses are available via Dynamic Host
> >  >          Configuration Protocol [DHCPv6].
> >  > 
> >  >          If the M flag is set, the O flag is redundant and can be
> >  >          ignored because DHCPv6 will return all available 
> >  > configuration
> >  >          information.
> >  > 
> >  >      O :
> >  >          1-bit "Other configuration" flag.  When set, it 
> >  > indicates that
> >  >          other configuration information is available via DHCPv6.
> >  >          Examples of such information are DNS-related 
> > information or
> >  >          information on other servers within the network.
> >  > 
> >  >      Note: If neither M nor O flags are set this 
> indicates that no
> >  >      information is available via DHCP.
> >  > 
> >  > -----
> >  > 
> >  > DHCPv6 and  
> >  > DHCPv6-lite are equivalent and didn't call out DHCPv6-lite 
> >  > separately  
> >  > in the O flag description.  Please correct me if I am wrong 
> >  > about this.
> >  > 
> >  > Comments?
> >  > 
> >  > Bob
>