Subject: [dhcwg] Adam Roach's No Objection on draft-ietf-dhc-rfc3315bis-10: (with COMMENT)

From: Adam Roach <[email-masked]>
Date: Wed, 24 Jan 2018 10:47:29 -0800

Adam Roach has entered the following ballot position for
draft-ietf-dhc-rfc3315bis-10: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dhc-rfc3315bis/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for everyone who worked on this update. I have a handful of comments
(many of which are simple editorial nits that you can accept or ignore as you
see fit), described in document order below.

One general editorial nit that I found is the use of the plural form of
"octets" when appearing as a noun adjunct (e.g., "A four octets long field"
rather than "a four octet long field") is awkward and distracting. The
conventional form here is singular.

-------------------------------------------------------------------------------

In section 4.1:

>  link-layer identifier     A link-layer identifier for an interface.
>                            Examples include IEEE 802 addresses for
>                            Ethernet or Token Ring network interfaces,
>                            and E.164 addresses for ISDN links.

It's been a while since I worked with ISDN, but this doesn't match my
recollection at all. ISDN uses LAPD as its underlying link protocol and LAPD
uses TEIs as link addresses. On a quick double-check, I don't find a reference
to E.164 from Q.921. I think you want to replace "E.164 addresses" with "TEIs"
above.

-------------------------------------------------------------------------------

In section 4.2:

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

I get that these are in alphabetical order, but it's impossible to understand
this definition without understanding the meaning of "IA". Consider adding
"(Identity Association, see below)" after "IA"

-------------------------------------------------------------------------------

In section 4.2:

>  T1                        The time at which the client contacts the
>                            server from which the addresses in the
>                            IA_NA or prefixes in the IA_PD were
>                            obtained to extend the lifetimes of the
>                            addresses assigned to the IA_NA or prefixes
>                            delegated to the IA_PD.
>
>  T2                        The time at which the client contacts any
>                            available server to extend the lifetimes of
>                            the addresses assigned to the IA_NA or
>                            prefixes delegated to the IA_PD.

I was initially confused about the epoch used for these times, then concerned
about the impending year 2038 problem when I realized these were only 32 bits.
It took me an additional 40 pages of reading before I figured out that these
were not *times*, but *timers*. Please be careful, here and elsewhere, to refer
to these as timers rather than times (e.g., section 21.4 refers to T1 as "The
time at which the client should...", rather than, e.g., "The number of seconds
in which the client should...")

-------------------------------------------------------------------------------

Section 7.2 describes the ports used for communicating with clients, servers,
and relays. These ports in the IANA port registry don't currently point to any
defining document. I would suggest adding a request in the IANA Considerations
section to request that the UDP port entries for 546 and 547 be updated to point
to this document.

-------------------------------------------------------------------------------

In section 11.2:

>  The link-layer
>  address is stored in canonical form, as described in [RFC2464].

I think you want to prefix this sentence with "For Ethernet hardware types," --
I don't see any discussion in RFC 2464 of representation of non-Ethernet
link-layer addresses.

-------------------------------------------------------------------------------

In section 13.2:

>  Clients ask for temporary addresses and servers assign them.
>  Temporary addresses are carried in the Identity Association for
>  Temporary Addresses (IA_TA) option (see Section 21.5).  Each IA_TA
>  option contains at lease one temporary address

Typo: replace "lease" with "least"

-------------------------------------------------------------------------------

In section 18.2:

>  If the client has a source address of sufficient scope that can be
>  used by the server as a return address, and the client has received a
>  Server Unicast option Section 21.12 from the server, the client

For readability, I suggest you place parentheses around "Section 21.12".

-------------------------------------------------------------------------------

In section 18.2.1:

>  The first Solicit message from the client on the interface SHOULD be
>  delayed by a random amount of time between 0 and SOL_MAX_DELAY.  This
>  mechanism is essential for devices that are not battery powered, as
>  they may suffer from power failure.  After recovering from a power
>  outage, many devices may start their transmission at the same time.
>  This is much less of a concern for battery powered devices.

I'm not sure this last sentence is true, and it seems to encourage producers
of battery-operated devices to ignore the advice to delay its initial Solicit.
For wireless networks recovering from a power outage, the time between boot
and sending an initial beacon is going to be pretty uniform for any given
access point/firmware combination. It is highly probable that a large campus
with uniform access points coming on line will result in all the access points
sending their initial beacon frame out all at the same time, that all
battery-powered devices on the network will observe this beacon at the same
moment, and eventually all attempt to send their Solicit messages
simultaneously.

For the cases of battery-powered devices with wired network interfaces, the
same will hold true for their upstream network device coming online and
activating the network link for all devices simultaneously.

I suggest removing discussion of battery-powered devices altogether, as I think
they need to observe the same random delay as all other devices.

-------------------------------------------------------------------------------

In section 18.2.1: the discussion of Reply with Rapid Commit doesn't mention the
possibility of clients performing a Release for any committed resources they
don't use (i.e., from servers other than the one they elect to use). It wasn't
clear to me whether such behavior was permissible until the discussion in
section 21.14. Since section 18.2.1 defines procedures while 21.14 defines
syntax, it probably makes more sense to move the discussion from 21.14 into
section 18.2.1. If you elect not to do so, at least consider referring readers
to the discussion (e.g., "Clients may choose to release unused committed
addresses, as described in section 21.14")

Because client handling of rapid commit is described in several places, this
comment applies elsewhere as well. I call these out below.

-------------------------------------------------------------------------------

In section 18.2.3:

>  The client uses a Confirm message when is has only addresses (no

Typo: "it" instead of "is"

-------------------------------------------------------------------------------

Section 18.2.10.1, like section 18.2.1, would also benefit from a mention of
Release in the multiple-rapid-commit Reply case.

-------------------------------------------------------------------------------

In Section 18.2.12:

>  addresses assigned to the interfaces on that link may no longer be
>  appropriate for the link to which the client is attached.  Examples
>  of times when a client may have moved to a new link include:

[list of examples removed]

>  When the client detects one of the above conditions and it has
>  obtained addresses and no delegated prefixes from a server, the
>  client SHOULD initiate a Confirm/Reply message exchange.

Basing a normative statement on a (presumably non-exhaustive) list of examples
is confusing. I think you want to change the normative sentence to start with
"When the client detects that it may have moved to a new link and it has
obtained addresses..."

-------------------------------------------------------------------------------

Section 22.11:

>     protocol             The authentication protocol used in this
>                          authentication option.  A one octet long
>                          field.
>
>     algorithm            The algorithm used in the authentication
>                          protocol.  A one octet long field.
>
>     RDM                  The replay detection method used in this
>                          authentication option.  A one octet long
>                          field.

The potential values for these fields needs to be indicated in this section. I
would also strongly encourage the creation of an IANA registry for these three
fields (similar to what RFC4030 does), in *particular* to address the need to
eventually move away from MD5.

-------------------------------------------------------------------------------

Section 21.13:

>     status-code          The numeric code for the status encoded in
>                          this option.  A two octets long field.

Since we're cleaning things up, this document should take action to fix the
IANA registry for status-code. Currently, IANA indicates that 23-255 are
unassigned, without mentioning the disposition of codes 256-65535. Presumably,
the "Unassigned" entry should read "23-65535".

-------------------------------------------------------------------------------

Section 21.13:

>     status-message       A UTF-8 encoded text string suitable for
>                          display to an end user, which MUST NOT be
>                          null-terminated.  A variable length field (2
>                          octets less than the value in option-len).

Given the "display to an end user" behavior described here, I would have
expected to see some discussion of localization of this string.

-------------------------------------------------------------------------------

Section 24:

>  (4)   See RFC8156 for details.

Typo: missing brackets around [RFC8156]