Re: [dhcwg] WGLC on draft-ietf-dhc-rfc3315bis-05 - respond by August 8th

[Marcin Siodelski <[e-mail]>]

On 08.07.2016 19:03, Tomek Mrugalski wrote:
> Hi all,
> 
> So the day finally has come. Authors working on RFC3315bis believe that
> after over two years of work, this document is ready for working group
> last call. This call initiates the working group last call on
> draft-ietf-dhc-rfc3315bis-05 [1]. Since this is a large document (130+
> pages), there's upcoming meeting and a holiday period, chairs decided to
> do an extended last call that will last 4 weeks. Please post your
> comments by August 8th.
> 
> We do have a slot reserved for this work in Berlin. We will present the
> overview of the document (some areas are organized differently than
> original 3315), go over the most important changes and will discuss any
> comments raised to date.
> 
> If you would like to review more important changes, looking at
> appendices A anb B seems like a good place to start. If you like to see
> the list of tickets addressed, see [2]. Many smaller issues were
> discussed on dhcpv6bis mailing list [3].
> 
> This is the most important document the DHC working group is currently
> working on. Please review it thoroughly. Since both co-chairs are also
> co-authors, our shepherd, Ralph Droms, will determine consensus and wrap
> up the WGLC. Thank you Ralph for stepping up and helping with this!
> 
> 1. https://tools.ietf.org/html/draft-ietf-dhc-rfc3315bis-05
> 2. https://tools.ietf.org/group/dhcpv6bis/
> 3. https://www.ietf.org/mailman/listinfo/dhcpv6bis
> 
> Cheers,
> Bernie & Tomek
> 

As a co-author of this document I strongly support moving it forward. I
have read the entire document and provide a couple of
comments/suggestions below.

Marcin

1.1.  Relation to previous DHCPv6 standards

OLD:
"prefix delegation [RFC3633],stateless [RFC3736], "

NEW:
"prefix delegation [RFC3633], stateless DHCPv6 service [RFC3736],"


1.2.  Relation to DHCP in IPv4

OLD:
"The operational models and relevant configuration information for
   DHCPv4 [RFC2132][RFC2131]"

NEW:
"The operational models and relevant configuration information for
   DHCPv4 [RFC2131]"

1.4.  Client-server Exchanges Involving Two Messages

Didn't we at some point consider removing sections 1.4 and 1.5 as they
present exchanges of messages before we even got to the terminology?

We may consider mentioning after the following paragraph:
"The server sends a Reply message to the client with the new
   lifetimes, allowing the client to continue to use the address or
   delegated prefix without interruption"

that

"If the server is unable to extend the lifetime of an address or
delegated prefix it indicates that by returning the address or delegated
prefix with lifetimes of 0. At the same time, the server may assign
another address or delegated prefix instead."

4.2.  DHCP Terminology
binding: this should be updated to also include delegated prefixes.

Currently it says:

"A binding (or, client binding) is a group of server data records
containing the information the server has about the addresses in an IA"

and further it says:
"... where IA-type is the type of address in the IA ..."

So again, no mention of delegated prefixes.

Similarly, for the IA, is this ok to say:
" Each IA holds one type of address ..." ?. It implies that the prefix
is an address.


IA_PD: I think the following can be removed:
" Each IA_PD has an associated IAID.  A requesting router may have more
than one IA_PD assigned to it; for example, one for each of its
interfaces."

as it duplicates the text for "IA".

singleton option: this seems to be underspecified. In particular,
"appear only once". The question is where? In a message or other option.



6.3.  DHCP Message Types
Message descriptions should probably be updated to use the term
"leases", instead of addresses.

7.  Client/Server Message Formats
msg-type: In wonder if we should add that: "additional message types are
defined in other specifications", to not create impression that those in
section 6.3 are the only valid messages. For example those in RFC7341.


13.1.  Rate Limiting

OLD:
 "This method of bounding burstiness also guarantees that the long-term
transmission rate will not exceed."

NEW:
 "This method of bounding burstiness also guarantees that the long-term
transmission rate will not exceed:" (colon, rather than period at the end).


15.  Message Validation
OLD:
UnSpecFail

NEW:
UnspecFail


17.  DHCP Configuration Exchanges
Some paragraphs of this section require fixing punctuation.

The enumeration of reasons why the client would start DHCP message
exchange could be better placed earlier in this section. Perhaps, right
after the first paragraph.

The paragraph starting with:
"A server may initiate a message exchange with a client by sending a
   Reconfigure message to cause the client to send a Renew, Rebind or..."

could be moved to the end of the section, after the paragraphs
describing client-initiated exchanges.

17.1.3
"In any situation when a client may have moved to a new link and the
   client does not have any delegated prefixes obtained from the DHCP
   server..."

This assumes that the client has delegated prefixes and is interested in
continuing to use them. But, is this also possible that the client
switching to a new link is no longer interested in using delegated
prefixes and simply wants to Confirm the addresses assigned? Is this ok
to send Confirm to verify that the addresses it has are correct, even
though it had received prefixes in previous transaction?


17.1.4. Creation and Transmission of Renew Messages
"The server determines new
   lifetimes for the leases according to the administrative
   configuration of the server.  The server may also add leases to the
   IAs.  The server can remove leases from the IAs by returning IA
   Address options (for IA_NA and IA_TA) and IA Prefix options (for
   IA_PD) with preferred and valid lifetimes set to 0."

This text is server specific and should be better moved to the server
section, or alternatively we may want to consider updating this text to
be more of a client-side type, e.g.

"The client MUST be prepared that the server removes or adds new leases
to the IAs. The leases are removed when server sets their preferred and
valid lifetimes to 0, in which case the client MUST stop using them."

17.1.9. Receipt of Advertise Messages

I'd suggest we put this paragraph at the beginning of the section:

 "Upon receipt of one or more valid Advertise messages, the client
   selects one or more Advertise messages based upon the following
   criteria."

as it is the first for the client to select the Advertise message.

Then, it should be followed by: "The client MUST ignore any Advertise...
with the exception of SOL_MAX_RT and INF_MAX_RT", because we want the
client to process SOL_MAX_RT and INF_MAX_RT from a selected Advertise
message, not from all messages.


17.1.10.1. Reply for Solicit (with Rapid Commit), Request, Renew or Rebind.

The new text starting with:
" When a client had received a configuration option in earlier Reply,
   then sent Renew, Rebind or Information-Request and that requested
   option does not appear in in the Reply any more, it MUST stop using..."

includes Information-request but this section is not about the
Information-request case. One of the option would be to include
Information-request in the section title, but then there is a lot of
text in this section that is not relevant to Information-request.
Perhaps it would be better to have a separate section that includes this
text, e.g. "Lack of Previously Received Options in Reply"

17.2. Server Behavior
Spurious "In most instances".

Duplicated "as indicated by the Reconfigure".

17.2.1. Receipt of Solicit Messages
OLD:
"the servers discard the Solicit message"

NEW:
"the server discards the Solicit message"

OLD:
 "Sending this option back to the client may useful using server
   selection process."

NEW:
 "Sending this option back to the client may be useful in server
   selection process."

17.2.6. Receipt of Information-request Messages
In the following sentence:
"The server includes options containing configuration information to
   be returned to the client as described in Section 17.2. "

it sounds odd to direct the reader to section 17.2. while the reader is
in fact in section 17.2. (specifically 17.2.6).

17.2.9. Creation and Transmission of Advertise Messages
OLD:
"Prefix Excluded"

NEW:
"Prefix Exclude"


24. Obsoleted mechanisms
Together with obsoleting the lifetime hints we obsoleted T1/T2 hints,
which we should probably mention here