Re: [dhcwg] WGLC on draft-ietf-dhc-rfc3315bis-05

Hi:

I've started a branched version of the draft at https://github.com/dhcwg/rfc3315bis/blob/bev_review_08_2016/rfc3315bis.xml for most of my minor edits (as I write this, I have completed those up to and including section 16).

I also should add that a review of the Normative/Informative references is in order. (See https://www.ietf.org/iesg/statement/normative-informative.html for some information as to the distinction.) This document does have a very large number of references (24 Normative and 28 Informative). For example, RFC7083 ended up in the Normative section but is obsoleted by this document, yet RFC3315, RFC3633, and RFC7550 ended up as Informative.

- Bernie

-----Original Message-----
From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Bernie Volz (volz)
Sent: Monday, August 01, 2016 9:49 PM
To: dhcwg <dhcwg@ietf.org>
Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-rfc3315bis-05 - respond by August 8th

Hi:

With WG co-chair hat off, but as a document co-author, I do support this document moving forward after a thorough read through it.

I do have a lot of minor edits, such as:
- replacing "address" with "address or delegated prefix" or most likely "lease" in places we missed (though this is not just a search and replace).
- addressing ticket #167 (https://trac.tools.ietf.org/group/dhcpv6bis/ticket/167) by replacing requesting router with client and delegated router with server (or at least making it clear that these "router" terms don't preclude non-router devices from requesting delegated prefixes if the server is configured to delegate).
- unused terminology ("DHCP realm" is no longer used; was previously used for Delayed Auth Protocol which has been deprecated).
- remove use of "site-scoped" addresses in sections related to the link-address field (i.e., section 8.1, 18.1.1, 18.1.2).
- in a few cases, there is redundant text that can be removed (one example is in section 14, page 36, 3rd paragraph - last sentence duplicates first and is likely unnecessary).
- fix figure 8 as outer link-address should not be 0 but address from link to which relay A was attached.
- text in last paragraph of section 20 missed vendor-class and vendor-specific information options as being allowed to appear more than once (with different enterprise-ids).
- text in last paragraph of section 20.7 (ORO) missed Vendor Class option MUST NOT be in ORO (as this is a client to server option).
- some references were updated from RFC 2462 to 4862, but in some cases that was incorrect (as 4862 has no explicit mention of M- and O-bits processing).

I think it best to just apply many of these minor edits to the github document (likely in a branch or just on the main) rather than reporting the list of changes here.

There are a few other changes that deserve a bit more attention (and may best be handled by opening tickets):
- In 3315 we referenced RFC 2136 for DNS Updates, but perhaps referencing RFC 4704 (The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN) Option) would be better?
- In many of the section 17.1.x (Creation and Transmission of <name> Messages), a forward reference to the corresponding Reply processing section would probably be useful.
- I think something about prefix hints should be added to 17.1.1 and 17.1.2 (such as what is in 17.1.4); alternatively we might want to just add something about that a client may do that and rely on the text already in 20.22 (IAPREFIX option).
- I'm not sure that the text in section 17.2.11 and 17.1.4 are fully aligned for Reconfigures. 17.2.11's text is a bit unclear in that it says "The server MAY include an ORO" (and then says if it includes IA options in the ORO, it must include the IA options themselves); section 17.1.4 assumes that this is always the case. I'm not sure if a "plain" Reconfigure without any ORO is valid from this as 17.1.4's text doesn't work well then? So, I think we need to clarify this a bit more. (The server I work on just sends a Reconfigure without ORO since we don't provide an administrator any way to say what the client should reconfigure and while I think this was intended to be acceptable behavior, but 17.1.4 needs a tweak to make it work?)
- Section 17.1.6 - minor issue but I don't think there's any need to delay sending Information-Request when being sent because of a Reconfigure?
- Section 17.1.10 looks like it is missing text (like in 17.1.9) about processing SOL_MAX_RT/INF_MAX_RT options if present? The earlier section (17.1.x) all said that a client adds the SOL_MAX_RT (or INF_MAX_RT for Information-Request)?
- Section 21 could use a rework as it is a bit scattered and jumps between topics. So, moving around some paragraphs to keep the IPSec and Reconfigure topics together as well as discussing "leases" to combine some of the address assigned/prefix delegation issues should be done.
- We should review section 22 as it first says focus will be on server considerations but then enumerates sections of RFC 7824 that are client related. Then remainder focuses on server allocation strategies (after referencing RFC 7284 section 4.3) and then duplicates some of that material. I think we should just refer readers to RFC 7824 for both client and server privacy considerations and leave it at that?
- In section 23 (IANA Considerations) there is a request to IANA to add a new column; should we perhaps provide IANA that data in a more easily used format? And, there is a "Note to IANA" that we need to clarify and remove. And straighten out the links (as some are .xhtml and others .xml).

There's also the question for the WG and co-authors about whether incorporating RFC 4242 (Information Refresh Time Option) into the bis document makes sense as it is  a MUST and there is text already in 17.1.6 about it and also in 20.25. This probably is a core piece of the base protocol (for assisting in stateless configuration of clients).

- Bernie

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg