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

[Ian Farrer <[e-mail]>]

Hi,

Here is my comments on rfc3315-bis-05.

Cheers,
Ian

Section 1.4
Paragraph 2 is a repetition of the beginning of paragraph 12

13.2
T1/T2 times and how they are selected are discussed in this section, but the
purpose of the T1/T2 timers is not described until section 17.1.4. A brief overview
of their purpose would help readers.

16.1 Para 1
The sentence:
"However, the client MAY send the message through another interface if the interface is a logical
interface without direct link attachment"
is ambiguous, suggested reword:
However, the client MAY send the message through another interface if the interface which
configuration is being requested for is a logical interface without direct link attachment  

17.1 DISCUSSION
Is this really a discussion point? The provided text for considerations regarding
the use of unicast with relays seems straightforward enough and the discussion doesn’t pose any questions.

17.1.2
The client includes a Reconfigure Accept option indicating whether or not...
The text here is not accurate (the option is only included if it is supported) - Suggested reword:
The client includes a Reconfigure Accept option (see Section 20.20) if the
client is willing to accept Reconfigure messages from the server.


17.1.10.1 Para beginning ‘When a client had received...'
There are a number of grammatical errors in this paragraph. Suggested re-word:

When a client receives a configuration option in an earlier Reply,
then sends a Renew, Rebind or Information-Request and the requested
option is not present in the Reply, the client MUST stop using
the previously received configuration information.  In other words, the client
should behave as if it never received this configuration option and return
to the relevant default state.  If there is no viable way to stop using the received configuration 
information, the values received/configured from the option MAY persist
if there are no other sources for that data and they have no external impact.
For example, a client that previously received a Client FQDN option and
used it to set up its hostname is allowed to continue using it if
there is no reasonable way for a host to unset its hostname and it
has no external impact.  As a counter example, a client that previously
received an NTP server address from the DHCP server and does not
receive it any more, MUST stop using the configured NTP server IPv6
address.  The client SHOULD be open to other sources of the same
configuration information.  This behavior does not apply to any IA
containers, as their processing is described in detail in other parts
of this document.

* Suggest also that the 'MUST stop using' is replaced with SHOULD, as the
next paragraph describes an exception to the MUST requirement.
* Also, it would be worth extending this to say that if a requested option
is received that has an updated value, then use of the previous value should be
discontinued and replaced with the new value.

17.2 Para 2
s/server sends Advertise message/server sends an Advertise message/

17.2.1 Para 6
"Sending this option back to the client may useful using the server selection
process."  
Current text is unclear, propose:
Sending this option back to the client may be useful for the server selection
process.

17.2.2 Para 6
The term 'prefixes on included addresses' is used (twice). Suggest 'prefixes of'
is used instead.

17.2.9 Para 6
"IA_IA" is listed here. Assume IA_TA was meant.

17.2.11 Para 2
Describes the server including an ORO option to say what is changed/added, but
there is no corresponding text in 17.1.11 saying how the client should use
a received ORO in a reconf. message. (I see Bernie got this one as well)

18.1.1
s/If not addresses/if no addresses/

19 & 19.2
Both sections describe that RFC3315 delayed authentication is obsolete. Is the 
repetition necessary?