[dhcwg] My WGLC comment on draft-ietf-dhc-rfc3315bis-05 - part 1

[Tomek Mrugalski <[e-mail]>]

On 15/08/16 15:26, Bernie Volz (volz) wrote:
> Just a friendly reminder that this (extended) WGLC is scheduled to
> end in a week (August 22nd).
Due to my poor time management and other duties in my day job, I failed
to review the complete document. Here's a partial review I managed to
complete so far. I plan to review the remainder of the text in the
coming days.

While I have many comments, they are mostly editorial in nature. With my
co-chair hat off, I strongly support this work.

Here's my review for pages 1 through 50.

Abstract : => ,
hosts => IPv6 nodes (as the PD is used by routers)

Section 1. The text should mention requestor and leasequery mechanism.
One paragraph somewhere in the introduction with references to RFC5007,
RFC5460 and RFC7653 should do the trick. Maybe somewhere around the text
that mentions servers, clients and relays. If you think it's
inappropriate to mention it that early, we can add one paragraph long
section 1.6 that explains it and then point to that in Section 1.

Need parentheses around section references in the last paragraph of
Section 1.

Section 1.1: extensions published => extensions were published

Section 1.4 seems to mention some more common exchanges (inf-req ->
reply), (solicit -> reply), (renew -> reply). It does not mention
others: (release -> reply), (rebind -> reply), (decline -> reply),
(confirm -> reply). Maybe adding a text similar to: "There are other two
message exchanges defined when the client and the server have
established a relationship: to renew or rebind existing leases (renew
and rebind messages), to release them (release message) or to inform the
server that the address leased is being used by other devices (decline
message)."?

Section 1.5 (4 messages exchanges) mentions Renewal mechanism. It
shouldn't, because it's a 2 messages exchange.

Section 4.1: "Every interface has a link-local address." Is this still
true these days? I recall some discussion on v6ops (or was it 6man?)
about certain tunneling interfaces lacking link-local address. IIRC it
was 6rd tunnel, but I may be wrong.

Section 4.2 binding definition should mention prefixes in its first
sentence.

Section 4.2 delegating router definition "responding to prefix request".
No such thing as prefix request is defined. Need to reword this one
slightly.

'DHCP realm' this definition was used in Delayed Auth protocol, which
is now removed. We should remove that definition as well.

DUID definition - it mentions that each client and server has one. Do
we want to mention that relays optionally may have one as well (see RFC5460)

IA definition - "holds one type of address" => "holds one type of
addresses or prefixes". I would also add "one IA may hold more than one
address or prefix of the same type, e.g. multiple temporary addresses".

Section 6 is called DHCP constants, but it does not contain the most
frequently used constants - the option codes. I think there should be a
pointer to Section 22, which defines the option codes, which are another
type of constants.

Section 6.3: request, renew, rebind, reply, release, inf-request
descriptions should mention prefixes as well.

The link in section 6.4 is incorrect. Status codes are not defined in
20.12, but in 20.13.

Section 8.1. link-address definition. "An address that will be used" =>
"An address that may be used". There are cases when it is not used,
for example when the relay inserts interface-id or it's not the relay
closest to the client.

What should be the hop-count set to when a relay forward client's
message? Text in 8.1 suggests 1 ("Number of relay agents that have
relayed this message", but text in 18.1.1 suggests 0 ("The hop-count in
the Relay-forward message is set to 0.")

Section 10. I think we should remove this sentence: "Clients and servers
MUST NOT in any other way interpret DUIDs.". This is a fiction that many
servers are violating for very good reasons. Removing it would settle
the issue raised in ticket #162. If you're not comfortable with removing
it completely, maybe substituting it with "Servers MAY interpret DUIDs
for policy, logging and other purposes, but MUST use the whole DUID to
identify clients." would be better?

Section 10.4: "DUID-LL MUST NOT be used by DHCP clients or servers that
cannot tell whether or not a network interface is permanently attached
to the device on which the DHCP client is running." I think we should
replace MUST NOT with SHOULD NOT for couple reasons. First, with enough
engineering time everything is replaceable. Second, with the advent of
virtualization software (and virtualization-like techniques, like
docker) it's increasingly difficult to say what is permanently attached
and what is not. Who knows what SDN will allows in couple years?

Section 11.1 "The configuration information in an IA consists of one or
more IPv6 addresses along with the times T1 and T2 for the IA." That's
not true for IA_TA, which does not have T1/T2 timers.

Section 12.1 could use a reference to ietf-dhc-topo-conf (currently in
RFC-Ed queue).

Section 12.3: Add "The same is true for IA_PD." after "The IAID number
space for the IA_TA option IAID number space is separate from the IA_NA
option IAID number space."

Section 13: "sends DHCP messages to the
All_DHCP_Relay_Agents_and_Servers." => "sends DHCP messages to the
All_DHCP_Relay_Agents_and_Servers multicast address."

Section 13.1 "the server still has the lease that was requested just
previously" The word 'just' doesn't seem to fit there. The sentence
should be rephrased.

"This loops can" => "This loop can"

Section 14 "A client is not expected to listen for a response during the
entire period between transmission of Solicit or Information-request
messages." I would add " and may turn off listening capabilities after
a certain time due to power consumption saving or other reasons."

Section 15.1 Add this text: "The exception is Reconfigure message, which
is sent by by the server and the transaction ID is set to zero."

Section 17 mentions that solicit exchange is called server discovery or
server solicitation. Maybe we should stick to one name? "server
discovery" phase has 5 occurrences, while "server solicitation" has only
4. Discovery seems to be also intuitively better understood by
non-native speakers.

Section 17.1 "When a client requests multiple IA option types" =>
"When a client requests multiple IA option types or multiple instances
of the same IA types"

"this situation should be rare or a temporary operational error." =>
"this situation should be rare or a result of temporary operational error."

Section 17.1.1 - we need to reorder the text (basically move paragraph
7 further down, maybe after 9th paragraph). Currently the text says "the
client MUST NOT include any other options..." and the following
paragraphs continue discussing which extra options to include.
Technically the current text is correct (because of the except clause),
but it's confusing.

Section 17.1.1 replace "an Advertise message" with "a valid Advertise
message" in this text: "If the client receives an Advertise message that
includes  a Preference option with a preference value of 255...". The
same is true for the following text "If the first RT elapses and the
client has  received an Advertise message...". And again in "If the
client does not receive any Advertise messages...".

Section 17.1.2 Clarification: After "The client generates a transaction
ID and inserts this value in the "transaction-id" field." add "This
value is likely to be different than the one used in Solicit". I vaguely
recall someone considering the whole solicit-adv-req-reply as a single
transaction. We should clarify that these are two separate transactions.

Not related to any specific text:
The maximum time allowed to be specified in Elapsed is 655.35 seconds.
The MAX_INF_RT and SOL_MAX_RT are 3600 seconds. What value should the
client set in Elapsed option when transmitting after 655 seconds?
The text doesn't specify that.

Tomek