Subject: RE: SHOULD or MAY for invoking DHCP services using M/O flags

From: [email-masked]
Date: Fri, 20 Aug 2004 10:34:39 +0300

Daniel,

> (slightly changing the subject of this thread to follow up 
> what we saying easily)
> 
> As I indicated previous mail, original intent of M/O flags document 
> is same as what Christian said. This intensity of this document was
> originally from the 2462-bis (IMO) and even Node Requirement as well.
> 
> But, as authors of this document, I am open this issue for moving
> it forward.
> 
> 
> p.s., I'd close the previous issue of whether M=1/O=0 is not
> valid in full 3315 or not. IMO, the consensus is,
> 
> M=1, O=0 is valid combination as described in this document.
> 
> Let me know your view on this if I am missing anything.

Following the discussions, it isn't entirely clear to me why we
could need to open this issue.  I think that there is concensus
for keeping it as is (as described in Christian's mail).

Am I missing something?

John

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

---

From: "S. Daniel Park" <[email-masked]>
Date: Fri, 20 Aug 2004 16:59:47 +0900

> for keeping it as is (as described in Christian's mail).

Hi John, I don't think you are missing anything. Besides, I don't 
have a hard stance to open this issue. What I said *open* is just 
for moving M/O flags document forward as author of this document 
because this issue occured during this thread although several 
documents (Node requirements, 2462-bis and etc.) already decided 
their stance IMO. I think I should listen for various opinions of this 
issue in conjunction with M/O flags document (neither Node 
requirement nor 2462-bis). 

Thanks.

- Daniel (Soohong Daniel Park)
- Mobile Platform Lab. Samsung Electronics.

---

From: Tim Chown <[email-masked]>
Date: Fri, 20 Aug 2004 14:33:52 +0100

> for keeping it as is (as described in Christian's mail).

My impression is that the discussion stems from the newly reached consensus
(since the original semantics were defined in 2462) that M=1 implies that 
RFC3315 functionality is available and O=1 implies that RFC3736 functionality 
is available.  With RFC3736 being a subset of RFC3315, it is thus on first
glance "odd" that you can have M=1, O=0, when M=1 implies RFC3736 support 
is there, as a subset of RFC3315.

While specific protocols were not mentioned in 2462, this wasn't such an
issue, but now that they are (in Section 4), and we know the properties
and features of each, maybe it is?

Tim

---

From: Brian Haberman <[email-masked]>
Date: Fri, 20 Aug 2004 11:05:51 -0400

> is there, as a subset of RFC3315.

I would like to see the wording reflect the concept that M=1
indicates that DHCPv6 Solicit, Advertise, Request, and Response
are available and O=1 indicates that Info-Request and Info-Response
are available.  That way, the flags are not tied to an RFC but rather
to a functionality offered by the administrative authority.

Regards,
Brian

---

From: "S. Daniel Park" <[email-masked]>
Date: Sat, 21 Aug 2004 11:28:15 +0900

My suggestion:

M = ON means only address configuration is learned from the DHCPv6
Server via Solicit/Advertise/Request/Reply (or Solicit/Reply if Rapid
Commit is enabled) message exchanges which is assumed to be Stateful
DHCPv6.

O = ON means only configuration information (not requiring the
assignment of any IPv6 addresses) is learned from the DHCPv6 Server
via Information-request /Reply message exchanges which is assumed to
be Stateless DHCPv6 and Stateful DHCPv6 or either.

Let me know if you have any comments. If no objection, I will add
this text into the M/O flag document as well.

Thanks.

---

From: Ralph Droms <[email-masked]>
Date: Sat, 21 Aug 2004 00:17:19 -0400

I disagree with this wording.  In particular, the Solicit/...
exchange is *not* limites to address configuration.  The
Information-Request/Reply message exchange is not
"Stateful DHCPv6".  "the DHCPv6 Server" might be misleading
as there can be more than one DHCPv6 server.

I don't think the purpose of the exchanges need to be
mentioned.  I think the following would suffice:

M = ON means configuration information is available from a DHCPv6 service
through Solicit/Advertise/Request/Reply or Solicit/Reply (if Rapid Commit is
enabled) message exchanges.

O = ON means configuration information is available from a DHCPv6 service
through Information-request /Reply message exchanges.

- Ralph

---

From: "S. Daniel Park" <[email-masked]>
Date: Mon, 23 Aug 2004 14:07:04 +0900

OK, I will lean to these text. 

M = ON means configuration information is available from a 
DHCPv6 service through Solicit/Advertise/Request/Reply or 
Solicit/Reply (if Rapid Commit is enabled) message exchanges.
 
O = ON means configuration information is available from a 
DHCPv6 service through Information-request /Reply message 
exchanges.

Thanks.

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Mon, 23 Aug 2004 19:22:09 +0900

(Changing the subject again...)

>>>>> On Fri, 20 Aug 2004 14:33:52 +0100, 
>>>>> Tim Chown <[email-masked]> said:

> and features of each, maybe it is?

Assuming we support the idea that M=1 is
Solicit/Advertise/Request/Reply rather than just "RFC3315", I think we
might be clearer on this in documents.

Do you think this will affect rfc2462bis, too?

For example, it currently says in Section 4 that:

   A "managed address
   configuration (M)" flag indicates whether hosts can use stateful
   autoconfiguration [RFC3315] to obtain addresses.  An "other stateful
   configuration (O)" flag indicates whether hosts can use stateful
   autoconfiguration [RFC3736] to obtain additional information
   (excluding addresses).

(note that rfc2462bis clarifies in section 1 why it still calls
the protocol for the O flag "stateful".  So we don't have to worry
about the "contradiction")

Do you think it should be revised using exchange types?  IMO, the
current wording of rfc2462bis does not necessarily contradict our
consensus on the semantics of M=1 (as I assumed above).  In
particular, the text for the M flag seems okay, since the exchange
described in [RFC3315] "to obtain addresses" should be
"Solicit/Advertise/Request/Reply".  It might still be better to revise
the text for the O flag a bit, such as:

   An "other stateful
   configuration (O)" flag indicates whether hosts can use a subset of
   [RFC3315], as defined in [RFC3736], to obtain additional information
   (excluding addresses).
  
Is this better?  Or should we revise more?  Or is there even no need
to revise?

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

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Mon, 23 Aug 2004 19:29:13 +0900

>>>>> On Sat, 21 Aug 2004 00:17:19 -0400, 
>>>>> Ralph Droms <[email-masked]> said:

> exchange is *not* limites to address configuration.

Yes, but regarding the interaction with the M flag, shouldn't the
Solicit/... exchange at least *contain* address configuration?
(Recall that the M flag should be defined as (an
indication/availability of) a couter part of "stateless address
autoconfiguration").

So,

> mentioned.  I think the following would suffice:

I would respectfully disagree with this while I see your other points.

> through Information-request /Reply message exchanges.

How about changing those to:

  M = ON means configuration information (including addresses to be
  allocated) is available from a DHCPv6 service through
  Solicit/Advertise/Request/Reply or Solicit/Reply (if Rapid Commit is
  enabled) message exchanges.

  O = ON means configuration information (excluding addresses) is
  available from a DHCPv6 service through Information-request /Reply
  message exchanges.

					JINMEI, Tatuya