[dhcwg] follow-up to draft-ietf-dhc-leasequery-by-remote-id-07

[Alfred Hönes <[e-mail]>]

Authors,
thanks for addressing (most of) the editorials I had reported.

Eventually now following up to your revised I-D,
    draft-ietf-dhc-leasequery-by-remote-id-07 ,
I unfortunately found that a few new nits have been newly introduced,
and AFAICS, one of the details I had mentioned earlier has been missed,
and that I also had overlooked some that had been introduced in a
previous draft update.

No immediate additional re-spinning of the draft is necessary IMHO;
unless the document shepherd recommends otherwise, I suggest that you
address the items below at the next opportunity -- either if another
draft version become necessary based on at-large reviews or comments
from the IESG or later, during RFC Editor processing / AUTH48 review.


(1)  Section 4.1, new 2nd bullet

The draft says:

|  o  Parameter Request List option MUST be populated by the access
|     concentrator with Associated-IP option.  The giaddr and other
|     options listed in Parameter Request List option are set as
      explained in section 6.2 of RFC 4388 [RFC4388].

There are a couple of articles missing here, and the second sentence
seems to be ambiguous or potentially confusing: from the structure
of the sentence, "giaddr and other options" looks like giaddr were
one of these option codes in the Parameter Request List option.  :-)
I suggest to use "the giaddr field" (similarly as in the next bullet)
and replace the "and" by "as well as", to make the text more precise.

Further, I see here the colloquial inprecise language pretending the
PRL option would contain DHCP *options*; but actually it includes
*option codes* only.  This should better be stated more precisely.

Altogether, I recommend to use:

|  o  The Parameter Request List option MUST be populated by the access
|     concentrator with the option code of the Associated-IP option.
      The giaddr filed and other option codes listed in Parameter
      Request List option are set as explained in section 6.2 of RFC
      4388 [RFC4388].

You have dropped the Ref. to RFC 2132 because it has not been used any
more.  But shouldn't that Ref. actually be given for the PRL option
(somewhere in the memo), and [RFC2132] restored, as a Normative Ref.?


(2)  Section 4.3, 3rd para

I had overlooked another two instances of missing articles here.
Please fix, and I also suggest a simplification of the language:

|  For all other options that are specified in Parameter Request List,
|  the processing is same as mentioned in section 6.4.2 of RFC 4388
   [RFC4388].
---                     v            vvvvv
|  For all other options specified in the Parameter Request List, the
|  processing is the same as mentioned in section 6.4.2 of RFC 4388
   [RFC4388].
                ^^^^^
Or even shorter:

|  All other options specified in the Parameter Request List are
|  processed as mentioned in section 6.4.2 of RFC 4388 [RFC4388].


(3)  Section 4.6, 1st para

Fixing a missing article has been missed in one instance; please
insert it:

     ... as well as the Relay Agent Information option ...
                   ^^^^^

(4)  Section 4.7

In the new text, again an article (in this case, an indefinite article)
needs to be fixed up:

                   v
|  The condition of access concentrator receiving no response to a
   DHCPLEASEQUERY message should be handled in the same manner as
   suggested in RFC 4388 [RFC4388].
---                vvvv
|  The condition of an access concentrator receiving no response to a
   DHCPLEASEQUERY message should be handled in the same manner as
   suggested in RFC 4388 [RFC4388].


Kind regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: [phone], Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [e-mail]                     |
+------------------------+--------------------------------------------+