Re: [dhcwg] WGLC for draft-ietf-dhc-dhcpv6-active-leasequery-00 - Respond by Feb. 28

["Bernie Volz (volz)" <[e-mail]>]

Comments regarding the draft (WG Co-Chair HAT OFF, though I did read this more as a potential document shepherd so it is a bit more thorough):

I have read this draft and support it moving forward.

I do have an extensive list of minor nits (missing definite articles (the) such as in section 6.3, spelling errors such as signalled -> signaled, can not -> cannot, and minor wording issues). I will provide a complete list to the authors, as I don't think this is a big deal (the RFC Editor would address most of these issues).

There are some other minor issues that should be looked at:
- The use of "continuous" (i.e., in section 3, "provide continuous updates of DHCPv6 IPv6 binding activity". While this isn't wrong, I just wonder if it could be misunderstood as the updates only occur when there are changes -- so if the server is idle, these updates would be. I would if just removing the word would be appropriate (or the entire sentence as the text before it is clear enough by itself).
- Section 6.1 says "one or more DHCPv6 messages to be sent at a time", though I don't understand how this is technically possible as the messages must be sent serially (one after the other). Again, this is probably minor as I think the intent is probably clear, but perhaps we can use better wording.
- Section 6.2.1 has some odd wording (assist requestor keeping -> "keeping the requestor"?)
- Section 6.3.1 specifies that the is an absolute time since midnight Jan 1 2000 UTC modulo 2^32. I don't understand how that "modulo 2^32" can be used. This is a 'future' issue since this will potentially create confusion once the time wraps (hence the modulo part becomes important). But how does a receiver know what the time should be (well, I would guess we can argue that if the year is 2137, the base time is probably 0x100000000 + the received time). While I guess it would be nice to have a fully future proof protocol, I would just remove the "modulo 2^32"? Or, why not make this a 64-bit value and then we avoid any issues for a very very long time?
- Section 6.3.1, 6.3.2, 6.3.3, remove "The length of this option is 4 octets". This is confusing as it really is the length of the data and that is already indicated in the field definitions.
- The text in 6.3 really impacts RFC 5460 because it is adding more functionality (as mentioned in the abstract). As this is kind of buried pretty deep in the document, I think it may be appropriate to add an explicit section to the document that indicates that Bulk Leasequery (RFC 5460) is extended by allowing this? And, nothing in 6.3.1 or 6.3.2 mentions that the those are allowed in a Bulk Leasequery, yet 6.3 does say that can? (6.3.3 does mention that option.) I think it might be best to add a section "Extensions to Bulk Leasequery" that describes those that can be used in those operations?
- This issue also ties in with section 9 ... I assume that the Bulk LQ support must also have been extended as mentioned in 6.3 (i.e., to support the new options). So "A DHCPv6 server with supports Active Leasequery MUST also support DHCPv6 Bulk Leasequery [RFC5460] and as extended herein." Or something like that? This is where referencing a section which contains the extensions would come in handy.
- Section 7, last sentence uses "would never miss", but that isn't true unless the connection remains up. So, perhaps change to "would be less likely to miss"?
- Section 8.2, remove "4 octet" when describing the transmission of the OPTION_LQ_BASE_TIME option. (The option itself is 8 octets if the header is included, and 4 for just the data -- unless this is changed as per comment for 6.3.1.) I don't see any value in the "4 octet".


The idnits tool reports some issues that should also be looked at (there were some others, but these are because the document was from 80+ days ago):

Checking nits according to http://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

  ** There is 1 instance of too long lines in the document, the longest one
     being 1 character in excess of 72.

  Miscellaneous warnings:
  ----------------------------------------------------------------------------

  == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but
     does not include the phrase in its RFC 2119 key words list.


Again, nothing here to prevent this document from moving forward (likely after a revision).

- Bernie

-----Original Message-----
From: dhcwg [mailto:[e-mail]] On Behalf Of Bernie Volz (volz)
Sent: Monday, February 24, 2014 2:42 PM
To: dhcwg
Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-dhcpv6-active-leasequery-00 - Respond by Feb. 28

Reminder that this WGLC is outstanding.

We need feedback in order to determine whether to advance this document.

- Bernie

-----Original Message-----
From: dhcwg [mailto:[e-mail]] On Behalf Of Tomek Mrugalski
Sent: Tuesday, February 11, 2014 3:39 PM
To: dhcwg
Subject: [dhcwg] WGLC for draft-ietf-dhc-dhcpv6-active-leasequery-00 - Respond by Feb. 28

We have adopted two active leasequery drafts after Vancouver meeting.
There was moderate interest in that work during adoption call, but we never saw any discussions about them on the ML. Since authors confidence in those proposals are high due to existing implementations, they have requested WGLC.

After a quick discussion between chairs, we have decided to go ahead with the WGLC, hoping that it will trigger some reviews and discussion.
Please make no mistake - those drafts need reviews and comments. A simple "I support this" followed with couple +1s will not do do the trick here.

This WGLC is for draft-ietf-dhc-dhcpv6-active-leasequery-00. Please send your comments by Feb. 28th. Note that although both documents are very similar, they are separate drafts and are going through separate WGLCs.
If you support this work, make sure that you clearly state which draft (v4, v6 or both) you support. Each WGLC will be assessed independently.

Finally, I'd also remind you that we are looking for volunteers to do the shepherding work. Please let us know if you'd like to be a shepherd for one of those documents. It is not a difficult task, but some prior IETF experience is necessary. As a shepherd, you can get unique insight into the WGLC process and better exposure to how IESG works. Having such an experience can be useful with moving your own draft forward faster.

Bernie & Tomek

_______________________________________________
dhcwg mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dhcwg

_______________________________________________
dhcwg mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dhcwg