Subject: Re: [Dhcpv6bis] New Proposed Section 5 (Operational Models)

From: Tomek Mrugalski <[email-masked]>
Date: Tue, 14 Oct 2014 16:02:07 +0200

On 29.09.2014 23:20, Bernie Volz (volz) wrote:
> I set up an initial draft regarding a proposed new section 5 on
> Operational Models for the RFC3315bis document. The idea for this
Thanks a lot for writing this proposal and for setting it up.

> I guess an alternative is to move it into the GitHub area, but the
> formats available there are somewhat limited. And, there are some nicer
> tools to see what changes/or leave comments in Google docs.
Yup, but to use them you need to grant editing or commenting rights to
other participants. Since I don't have them, I post my comments here.
Commeting on google docs is really convenient, but it has 2
disadvantages. At least one member of the editor team is not able to
access google docs. And second, there are no notifications or any other
public traces that a change been made.

> Please free to comment (either via email or using the google docs).
In general, excellent summary and a well written text.

5. I would add here "The described models are not mutually exclusive and
sometimes are used together. For example, a device may start in stateful
mode to obtain an address and, at a later time when an application is
started, request additional parameters using stateless mode."

5.1
"not used for address assignment or prefix delegation" =>
"not used for address assignment, prefix delegation or any other
stateful resource that may be defined in the future"

The text in 5.2 about stateless is interesting. Perhaps we could have a
separate section providing comparison between stateless and stateful. We
could add it at the end of section 3, perhaps as 3.1? If you think it's
a good idea, I can propose initial text for this.

5.2
"returns the allocate address" => "returns the allocated address"
"valid and preferred" => "preferred and valid" (better to list them in
the order of their expiration

I would add something like "The protocol does make any assumptions
whether returning client gets the same address as previously. Providing
such a property is up to server implementors."

5.3
We need to make it very clear that this is considered stateful mode.
"The prefix delegation mechanism, originally described in [RFC3633], is
intended for..." => "The prefix delegation mechanism, originally
described in [RFC3633], is another stateful mode of operation and is
intended for...".

Every once in a while people, especially those starting IPv6 migration,
come in with strange ideas that prefix delegation can be a rough
substitute for routing configuration in DHCPv6. It would would be good
to have a short, clear text that explains that it's not intended for
that purpose. How about this: "It should be noted that requesting router
is not allowed to assign its delegated prefix on the interface it got
the prefix from. In particular, this feature is not intended for
configuring routing on hosts."

The figure in 5.3 is interesting. I would remove two dashes between left
and right subscriber networks, to make it clear that these are 2
distinct subnets.

Do we want to mention in sections 5.2 to 5.5 that server reconfiguration
is possible if clients support it?

Tomek

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 15 Oct 2014 03:45:42 +0000

Tomek:

Thanks for the comments. I have applied some and added this material to the XML document (and made some other changes, such as removing the two Prefix Delegation section in section 1). I also updated the txt so people can view the current state of the document.

Regarding some of your comments:

I think this would be elsewhere. So, did not include in this "overview" material. I think this might be good to add to the "Selecting Addresses for Assignment to an IA" (was section 11 in 3315, now is section 12). However, I did NOT add this.

I didn't apply this change either. I think this has also been somewhat relax recently for the Prefix Exclude option. See RFC 6603, section 3 (Problem Background). So, I think this may need a bit more consideration before adding something. Also, again, I'm not certain that this is the best section.

I didn't do this since this section wasn't a full review of the features.

- Bernie 

-----Original Message-----
From: Dhcpv6bis [mailto:[email-masked]] On Behalf Of Tomek Mrugalski
Sent: Tuesday, October 14, 2014 10:02 AM
To: [email-masked]
Subject: Re: [Dhcpv6bis] New Proposed Section 5 (Operational Models)

5.1

5.2

5.3

Tomek

_______________________________________________
Dhcpv6bis mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcpv6bis