DHCPv6 Active Leasequery
draft-ietf-dhc-dhcpv6-active-leasequery-04

[Ballot comment]
I believe the questions from Francis Dupon wrt TLS usage and full specification deserve at least an answer, if not even a clarification in the document. Please take a look!

[Ballot discuss]

This might seem like a lot of discuss points, but it's really
two main ones (privacy and use of TLS) broken out into what I
think are separable questions that might help us get the
discussion done quicker.

(1) I'm not sure I'm following the use-cases for this but
clearly this protocol could be used as part of a pervasive
monitoring toolkit, to track users or client-devices with very
fine granularity.  So a) can you explain the main valid
use-case(s) and b) did you consider RFC7258 in developing this
protocol?  The answers here might well result in a few changes
to my other discuss points below. I also had a quick peek at
5460, but note that pre-dates 7258 by quite a bit and I'm also
not clear how or if this protocol has the same goal of restoring
routes.  Note also that I am not claiming that there are no good
uses for this protocol, I'm just asking what (some of) those are
and how you considered the PM issue. 

(2) I also think you need to add (or reference) privacy
considerations text here - the information accessible via this
could have significant privacy impact.

(3) Along the lines of (1) - can you say why all of the various
bits of data one could return are needed by the requestor here?
If not, then isn't there a good data-minimisation case to be
made for profiling down the information returned to the
requestor?  I think one can validly argue that the answers we
arrived at in 2009 (for 5460) might not be those on which we'd
reach consensus today, but this draft seems to (quite
understandably) assume that 2009's answers are still good
enough.  Did the WG consider that?

(4) Having TLS is good. But I don't get why you've not reversed
the TLS client/server roles to make the requester the TLS
server, since it seems to me that authenticating and authorizing
the requestor here is the main thing and not authenticating the
DHCP server. So why not reverse the TLS roles? (I'll clear this
quickly but wanted to check in case it'd not occurred to folks.)

(5) The TLS mutual authentication requirement is underspecified.
The sentence in 9.1 isn't really enough I think, you need to say
that all TLS sessions MUST be mutually authenticated and then
that has administrative consequences that might need more text.
For example, the DHCP servers need to trust the set of CAs that
requestors use - is it ok to be just silent on that?  I also
wonder about naming and other things - does there need to be
some profile of how the DHCP server is named vs. a TLS
certificate?

(6) Why not just make the use of TLS mandatory or RECOMMENDED
here anyway - would that really hurt?

[Ballot discuss]

This might seem like a lot of discuss points, but it's really
two main ones (pricacy and use of TLS) broken out into what I
think are separable questions that might help us get the
discussion done quicker.

(1) I'm not sure I'm following the use-cases for this but
clearly this protocol could be used as part of a pervasive
monitoring toolkit, to track users or client-devices with very
fine granularity.  So a) can you explain the main valid
use-case(s) and b) did you consider RFC7258 in developing this
protocol?  The answers here might well result in a few changes
to my other discuss points below. I also had a quick peek at
5460, but note that pre-dates 7258 by quite a bit and I'm also
not clear how or if this protocol has the same goal of restoring
routes.  Note also that I am not claiming that there are no good
uses for this protocol, I'm just asking what (some of) those are
and how you considered the PM issue. 

(2) I also think you need to add (or reference) privacy
considerations text here - the information accessible via this
could have significant privacy impact.

(3) Along the lines of (1) - can you say why all of the various
bits of data one could return are needed by the requestor here?
If not, then isn't there a good data-minimisation case to be
made for profiling down the information returned to the
requestor?  I think one can validly argue that the answers we
arrived at in 2009 (for 5460) might not be those on which we'd
reach consensus today, but this draft seems to (quite
understandably) assume that 2009's answers are still good
enough.  Did the WG consider that?

(4) Having TLS is good. But I don't get why you've not reversed
the TLS client/server roles to make the requester the TLS
server, since it seems to me that authenticating and authorizing
the requestor here is the main thing and not authenticating the
DHCP server. So why not reverse the TLS roles? (I'll clear this
quickly but wanted to check in case it'd not occurred to folks.)

(5) The TLS mutual authentication requirement is underspecified.
The sentence in 9.1 isn't really enough I think, you need to say
that all TLS sessions MUST be mutually authenticated and then
that has administrative consequences that might need more text.
For example, the DHCP servers need to trust the set of CAs that
requestors use - is it ok to be just silent on that?  I also
wonder about naming and other things - does there need to be
some profile of how the DHCP server is named vs. a TLS
certificate?

(6) Why not just make the use of TLS mandatory or RECOMMENDED
here anyway - would that really hurt?

[Ballot comment]

- I had a look at the DHCPv4 equivalent - is the plan that those
be as close to one another as possible? If so, then the
"DHCPTLS" vs. "STARTTLS" thing seems odd, as does the
duplication of text in the two - would it not have been better
to develop a separate spec for how to talk to a DHCP v4 or v6
server using TLS? I think that'd be cleaner for all sorts of
reasons, e.g. naming, the roles of the peers, TLS extensions
needed etc.

- sections 8/9: Sending the DHCP REPLY with no status code as a
way to indicate acceptance of TLS seems very hacky. Why is that
a good plan? I don't think STARTTLS works that way in other
protocols for example.

- somewhere: I think it'd be a fine thing if you referred to
RFC7525/BCP195 and said implementations need to follow that in
how they use TLS.

- section 10: why is (the usually mythical:-) 3315 a MUST NOT
here? I don't get that. I could see it being an EDONTCAR but I
don't see the harm if one did go mad and try use 3315. And I
could maybe, possibly, with a lot of a nose-holding, see a
universe in which one might use TLS server auth for the DHCP
server and 3315 to authenticate the requestor, so it seems odd
to rule that out in this way.

[Ballot comment]
-- general:
I understand this to be a way for a third party to "actively" monitor client DHCPv6 bindings.  Does that warrant some privacy considerations?

-- section 8.2:
The selection of secure vs insecure mode MAY be administratively selectable. It seems like there should a stronger requirement for an administrative option to force secure mode.

Document Writeup, template from IESG area on ietf.org, dated 6th March 2015.

draft-ietf-dhc-dhcpv6-active-leasequery-02 write-up

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
Standard, Informational, Experimental, or Historic)? Why is this the proper type
of RFC? Is this type of RFC indicated in the title page header?

  Proposed standard. This document expands on the DHCPv6 Leasequery
  protocol, and allows for active transfer of real-time DHCPv6 binding
  information data via TCP.  This document also extends the DHCPv6 Bulk
  Leasequery by adding new options and updates the DHCPv6 Bulk
  Leasequery. The intended type is indicated in the document header.
 
(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent examples
can be found in the "Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary:
Relevant content can frequently be found in the abstract
and/or introduction of the document. If not, this may be
an indication that there are deficiencies in the abstract
or introduction.

  This document enables an entity not directly involved in DHCPv6
  client - server transactions to keep current with the state of the
  DHCPv6 lease state information in real-time.

Working Group Summary:
Was there anything in WG process that is worth noting? For example,
was there controversy about particular points or were there decisions
where the consensus was particularly rough?

  This document was called draft-raghuvanshi-dhc-dhcpv6-active-leasequery
  prior to its adoption. There was unanimous support for it in favor of
  adoption and none against), so this document was adopted in December
  2013. There was interest in this work posts since its adoption.
  There was never any opposition for this work.
 
  This document went through a relevant short document development
  period (2 months for individual document period, 4 month for WG document
  period). Its maturity took advantages from its twin-document -
  "Active DHCPv4 Lease Query" draft-ietf-dhc-dhcpv4-active-leasequery,
  which firstly submitted in early 2010.

Document Quality:
Are there existing implementations of the protocol? Have a significant
number of vendors indicated their plan to implement the specification?
Are there any reviewers that merit special mention as having done a
thorough review, e.g., one that resulted in important changes or a
conclusion that the document had no substantive issues? If there was
a MIB Doctor, Media Type or other expert review, what was its course
(briefly)? In the case of a Media Type review, on what date was the
request posted?

  I'm not aware of any existing implementations, but the authors claimed
  they have customers using DHCPv4 active leasequery. It is reasonable to
  assume these customers would require DHCPv6 active leasequery as long
  as their network extend to IPv6. No external requirements are needed
  as this work is purely DHCPv6 extension. There was a few reviews by
  DHC WG members. This document has requested publication in mid of 2014,
  and received a AD review from Ted Lemon. The authors updated the
  document in March 2015 to address the comments from AD review.


Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

  Sheng Jiang is the document shepherd.
  Brian Haberman is the responsible AD.
 
(3) Briefly describe the review of this document that was performed by the
Document Shepherd. If this version of the document is not ready for publication,
please explain why the document is being forwarded to the IESG.

  I thoroughly reviewed this document  (and had other minor
  comments in between):
 
  http://www.ietf.org/mail-archive/web/dhcwg/current/msg15379.html
 
  The issues raised in my last review were promptly addressed by authors
  in -01 version along with the comments from other DHC WG members. This
  document is ready for publication in my opinion.

  I also reviewed the latest changes from 01 to 02 in March 2015. It looks fine
  for me.
 
(4) Does the document Shepherd have any concerns about the depth or breadth of
the reviews that have been performed?

  No.
 
(5) Do portions of the document need review from a particular or from broader
perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or
internationalization? If so, describe the review that took place.

  No. This document has been carefully reviewed by the DHC WG.
 
(6) Describe any specific concerns or issues that the Document Shepherd has with
this document that the Responsible Area Director and/or the IESG should be aware
of? For example, perhaps he or she is uncomfortable with certain parts of the
document, or has concerns whether there really is a need for it. In any event,
if the WG has discussed those issues and has indicated that it still wishes to
advance the document, detail those concerns here.

  There are no outstanding issues.

(7) Has each author confirmed that any and all appropriate IPR disclosures
required for full conformance with the provisions of BCP 78 and BCP 79 have
already been filed. If not, explain why?

  Yes. The authors, Dushyant Raghuvanshi, Kim Kinnear and Deepak Kukrety
  confirmed that any and all appropriate IPR disclosures required for full
  conformance with the provisions of BCP 78 and BCP 79 have already been
  filed.
 
(8) Has an IPR disclosure been filed that references this document? If so,
summarize any WG discussion and conclusion regarding the IPR disclosures.

  Yes, an IPR disclosure (http://datatracker.ietf.org/ipr/2210/) been filed
  that references this document. The IPR declaration was submitted early on
  but the WG did not explicitly discuss the ipr at any time (wglc or
  otherwise) to my knowledge.
 
(9) How solid is the WG consensus behind this document? Does it represent the
strong concurrence of a few individuals, with others being silent, or does the
WG as a whole understand and agree with it?

  There was broad support for this document. It was reviewed by active WG
  participants. All changes were mostly minor.
 
(10) Has anyone threatened an appeal or otherwise indicated extreme discontent?
If so, please summarise the areas of conflict in separate email messages to the
Responsible Area Director. (It should be in a separate email because this
questionnaire is publicly available.)

  No. There was unanimous support for this work and nobody raised any objections.
 
(11) Identify any ID nits the Document Shepherd has found in this document. (See
http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be thorough.

  This document is now ID nits clean.
 
(12) Describe how the document meets any required formal review criteria, such
as the MIB Doctor, media type, and URI type reviews.

  No MIB Doctor, media type, URI type or similar apply to this
  document.
 
(13) Have all references within this document been identified as either
normative or informative?

  Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative references
exist, what is the plan for their completion?

  All normative references are published RFCs.
 
(15) Are there downward normative references references (see RFC 3967)? If so,
list these downward references to support the Area Director in the Last Call
procedure.

  No.

(16) Will publication of this document change the status of any existing RFCs?
Are those RFCs listed on the title page header, listed in the abstract, and
discussed in the introduction? If the RFCs are not listed in the Abstract and
Introduction, explain why, and point to the part of the document where the
relationship of this document to the other RFCs is discussed. If this
information is not in the document, explain why the WG considers it unnecessary.

  This document updates RFC 5460. It is listed on the title page header, listed
  in the abstract, and discussed in the introduction

(17) Describe the Document Shepherd's review of the IANA considerations section,
especially with regard to its consistency with the body of the document. Confirm
that all protocol extensions that the document makes are associated with the
appropriate reservations in IANA registries. Confirm that any referenced IANA
registries have been clearly identified. Confirm that newly created IANA
registries include a detailed specification of the initial contents for the
registry, that allocations procedures for future registrations are defined, and
a reasonable name for the new registry has been suggested (see RFC 5226).

  IANA is asked to assign 3 option codes for OPTION_LQ_BASE_TIME,
  OPTION_LQ_START_TIME, and OPTION_LQ_END_TIME; 2 status codes for DataMissing
  CatchUpComplete; 1 message type for  ACTIVELEASEQUERY.
 
  All the necessary information is in the IANA considerations document. It is
  clear enough that the IANA will be able to implement it.
 
(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find useful in
selecting the IANA Experts for these new registries.

  No such registry is requested in this document.
 
(19) Describe reviews and automated checks performed by the Document Shepherd to
validate sections of the document written in a formal language, such as XML
code, BNF rules, MIB definitions, etc.

  There are no such parts to the document.

[Ballot comment]
No objection, but if taken into account, Scott's OPS DIR feedback would improve the document.

=================================
Scott,

We totally agree that this protocol should be able to restrict who
gets the information about what is going on with the DHCP server.

We *thought* that we had that covered...

The current draft has TLS connections as a SHOULD, and includes the
following text at the end of section 9.1:

>    In the event that the DHCPv6 server sends a REPLY message without
>    DHCPv6 status code option included (which indicates success), the
>    requestor is supposed to initiate a TLS handshake [RFC5246] (see
>    Section 8.2).  During the TLS handshake, the DHCPv6 server MUST
>    verify the requestor's digital certificate.
>    If the TLS handshake is not successful in creating a TLS connection,
>    the server MUST drop the TCP connection.


The intent here is that in requiring the verification of the
requestor's digital certificate that the server would also be able to
restrict connections to requestors that it considered acceptable.

We recently took a lot of words out of the security considerations
section on restricting connections to acceptable requestors because
that would have required using IP addresses, which everyone thought
was useless.

We didn't put more words back in about the TLS certificates, but
perhaps we should have?

Anyway, there are several issues:

  1. Does the verification of the TLS certificates allow the server to
  be able to determine that a requestor is or is not allowed to access
  the active leasequery capability?

  2. We believe that there is more than one way to utilize
  certificates to decide if a requestor is allowed.  We also sort of
  assumed that was documented elsewhere and wasn't something that we
  needed to detail in this draft.  Do you know of a draft we could
  reference on how to do that, or failing that, know of text we could
  incorporate that explains how to do that.

If #1 is no, then we are confused because we thought that was the
point of verifying the digital certificates (instead of just using
the certificate to ensure that the link is encrypted).

===============================
Scott's answer:
it is always useful to spell out what is on your mind

if you are projecting that the use of certs equals access control you should just say that

a few extra words would dog a LONG way

Scott

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-dhc-dhcpv6-active-leasequery-03.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

IANA has some questions about one of the actions requested in the IANA Considerations section of this document.

We received the following comments/questions from the IANA's reviewer:

IANA understands that, upon approval of this document, there are three actions which must be completed.

First, in the DHCPv6 Option Codes subregistry of the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) located at:

http://www.iana.org/assignments/dhcpv6-parameters

three new option codes will be registered as follows:

Value: [ TBD-at-Registration ]
Description: OPTION_LQ_BASE_TIME
Reference: [ RFC-to-be ]

Value: [ TBD-at-Registration ]
Description: OPTION_LQ_START_TIME
Reference: [ RFC-to-be ]

Value: [ TBD-at-Registration ]
Description: OPTION_LQ_END_TIME
Reference: [ RFC-to-be ]

Questions:
1) This is more like a comment: As this document requests registrations in an xpert Review and Standards Action sub-registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

2) One single place holder TBD is used in section 6.2 for the above three
requested option codes.  Are the authors intended to request one single
option code for the three new options?

Second, in the DHCPv6 Status Codes subregistry of the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) located at:

http://www.iana.org/assignments/dhcpv6-parameters

four new status codes will be registered as follows:

Code: [ TBD-at-Registration ]
Name: DataMissing
Reference: [ RFC-to-be ]

Code: [ TBD-at-Registration ]
Name: CatchUpComplete
Reference: [ RFC-to-be ]

Code: [ TBD-at-Registration ]
Name: NotSupported
Reference: [ RFC-to-be ]

Code: [ TBD-at-Registration ]
Name: TLSConnectionRefused
Reference: [ RFC-to-be ]

Third, in the DHCPv6 Message Types subregistry of the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) located at:

http://www.iana.org/assignments/dhcpv6-parameters

two new message types will be registered as follows:

Value: [ TBD-at-Registration ]
Description: ACTIVELEASEQUERY
Reference: [ RFC-to-be ]

Value: [ TBD-at-Registration ]
Description: STARTTLS
Reference: [ RFC-to-be ]

IANA understands that these three actions are the only ones required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed. 

Please note that IANA cannot reserve specific values. However, early allocation is available for some types of registrations. For more information, please see RFC 7120.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (DHCPv6 Active Leasequery) to Proposed Standard


The IESG has received a request from the Dynamic Host Configuration WG
(dhc) to consider the following document:
- 'DHCPv6 Active Leasequery'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2015-06-29. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) has been
  extended with a Leasequery capability that allows a requestor to
  request information about DHCPv6 bindings.  That mechanism is limited
  to queries for DHCPv6 binding data updates prior to the time the
  DHCPv6 server receives the Leasequery request.  Continuous update of
  an external requestor with Leasequery data is sometimes desired.
  This document expands on the DHCPv6 Leasequery protocol, and allows
  for active transfer of real-time DHCPv6 binding information data via
  TCP.  This document also updates DHCPv6 Bulk Leasequery (RFC5460) by
  adding new options.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-active-leasequery/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-active-leasequery/ballot/


The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/2210/

Document Writeup, template from IESG area on ietf.org, dated 6th March 2015.

draft-ietf-dhc-dhcpv6-active-leasequery-02 write-up

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
Standard, Informational, Experimental, or Historic)? Why is this the proper type
of RFC? Is this type of RFC indicated in the title page header?

  Proposed standard. This document expands on the DHCPv6 Leasequery
  protocol, and allows for active transfer of real-time DHCPv6 binding
  information data via TCP.  This document also extends the DHCPv6 Bulk
  Leasequery by adding new options and updates the DHCPv6 Bulk
  Leasequery. The intended type is indicated in the document header.
 
(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent examples
can be found in the "Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary:
Relevant content can frequently be found in the abstract
and/or introduction of the document. If not, this may be
an indication that there are deficiencies in the abstract
or introduction.

  This document enables an entity not directly involved in DHCPv6
  client - server transactions to keep current with the state of the
  DHCPv6 lease state information in real-time.

Working Group Summary:
Was there anything in WG process that is worth noting? For example,
was there controversy about particular points or were there decisions
where the consensus was particularly rough?

  This document was called draft-raghuvanshi-dhc-dhcpv6-active-leasequery
  prior to its adoption. There was unanimous support for it in favor of
  adoption and none against), so this document was adopted in December
  2013. There was interest in this work posts since its adoption.
  There was never any opposition for this work.
 
  This document went through a relevant short document development
  period (2 months for individual document period, 4 month for WG document
  period). Its maturity took advantages from its twin-document -
  "Active DHCPv4 Lease Query" draft-ietf-dhc-dhcpv4-active-leasequery,
  which firstly submitted in early 2010.

Document Quality:
Are there existing implementations of the protocol? Have a significant
number of vendors indicated their plan to implement the specification?
Are there any reviewers that merit special mention as having done a
thorough review, e.g., one that resulted in important changes or a
conclusion that the document had no substantive issues? If there was
a MIB Doctor, Media Type or other expert review, what was its course
(briefly)? In the case of a Media Type review, on what date was the
request posted?

  I'm not aware of any existing implementations, but the authors claimed
  they have customers using DHCPv4 active leasequery. It is reasonable to
  assume these customers would require DHCPv6 active leasequery as long
  as their network extend to IPv6. No external requirements are needed
  as this work is purely DHCPv6 extension. There was a few reviews by
  DHC WG members. This document has requested publication in mid of 2014,
  and received a AD review from Ted Lemon. The authors updated the
  document in March 2015 to address the comments from AD review.


Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

  Sheng Jiang is the document shepherd.
  Ted Lemon is the responsible AD.
 
(3) Briefly describe the review of this document that was performed by the
Document Shepherd. If this version of the document is not ready for publication,
please explain why the document is being forwarded to the IESG.

  I thoroughly reviewed this document  (and had other minor
  comments in between):
 
  http://www.ietf.org/mail-archive/web/dhcwg/current/msg15379.html
 
  The issues raised in my last review were promptly addressed by authors
  in -01 version along with the comments from other DHC WG members. This
  document is ready for publication in my opinion.

  I also reviewed the latest changes from 01 to 02 in March 2015. It looks fine
  for me.
 
(4) Does the document Shepherd have any concerns about the depth or breadth of
the reviews that have been performed?

  No.
 
(5) Do portions of the document need review from a particular or from broader
perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or
internationalization? If so, describe the review that took place.

  No. This document has been carefully reviewed by the DHC WG.
 
(6) Describe any specific concerns or issues that the Document Shepherd has with
this document that the Responsible Area Director and/or the IESG should be aware
of? For example, perhaps he or she is uncomfortable with certain parts of the
document, or has concerns whether there really is a need for it. In any event,
if the WG has discussed those issues and has indicated that it still wishes to
advance the document, detail those concerns here.

  There are no outstanding issues.

(7) Has each author confirmed that any and all appropriate IPR disclosures
required for full conformance with the provisions of BCP 78 and BCP 79 have
already been filed. If not, explain why?

  Yes. The authors, Dushyant Raghuvanshi, Kim Kinnear and Deepak Kukrety
  confirmed that any and all appropriate IPR disclosures required for full
  conformance with the provisions of BCP 78 and BCP 79 have already been
  filed.
 
(8) Has an IPR disclosure been filed that references this document? If so,
summarize any WG discussion and conclusion regarding the IPR disclosures.

  Yes, an IPR disclosure (http://datatracker.ietf.org/ipr/2210/) been filed
  that references this document. The IPR declaration was submitted early on
  but the WG did not explicitly discuss the ipr at any time (wglc or
  otherwise) to my knowledge.
 
(9) How solid is the WG consensus behind this document? Does it represent the
strong concurrence of a few individuals, with others being silent, or does the
WG as a whole understand and agree with it?

  There was broad support for this document. It was reviewed by active WG
  participants. All changes were mostly minor.
 
(10) Has anyone threatened an appeal or otherwise indicated extreme discontent?
If so, please summarise the areas of conflict in separate email messages to the
Responsible Area Director. (It should be in a separate email because this
questionnaire is publicly available.)

  No. There was unanimous support for this work and nobody raised any objections.
 
(11) Identify any ID nits the Document Shepherd has found in this document. (See
http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be thorough.

  This document is now ID nits clean.
 
(12) Describe how the document meets any required formal review criteria, such
as the MIB Doctor, media type, and URI type reviews.

  No MIB Doctor, media type, URI type or similar apply to this
  document.
 
(13) Have all references within this document been identified as either
normative or informative?

  Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative references
exist, what is the plan for their completion?

  All normative references are published RFCs.
 
(15) Are there downward normative references references (see RFC 3967)? If so,
list these downward references to support the Area Director in the Last Call
procedure.

  No.

(16) Will publication of this document change the status of any existing RFCs?
Are those RFCs listed on the title page header, listed in the abstract, and
discussed in the introduction? If the RFCs are not listed in the Abstract and
Introduction, explain why, and point to the part of the document where the
relationship of this document to the other RFCs is discussed. If this
information is not in the document, explain why the WG considers it unnecessary.

  This document updates RFC 5460. It is listed on the title page header, listed
  in the abstract, and discussed in the introduction

(17) Describe the Document Shepherd's review of the IANA considerations section,
especially with regard to its consistency with the body of the document. Confirm
that all protocol extensions that the document makes are associated with the
appropriate reservations in IANA registries. Confirm that any referenced IANA
registries have been clearly identified. Confirm that newly created IANA
registries include a detailed specification of the initial contents for the
registry, that allocations procedures for future registrations are defined, and
a reasonable name for the new registry has been suggested (see RFC 5226).

  IANA is asked to assign 3 option codes for OPTION_LQ_BASE_TIME,
  OPTION_LQ_START_TIME, and OPTION_LQ_END_TIME; 2 status codes for DataMissing
  CatchUpComplete; 1 message type for  ACTIVELEASEQUERY.
 
  All the necessary information is in the IANA considerations document. It is
  clear enough that the IANA will be able to implement it.
 
(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find useful in
selecting the IANA Experts for these new registries.

  No such registry is requested in this document.
 
(19) Describe reviews and automated checks performed by the Document Shepherd to
validate sections of the document written in a formal language, such as XML
code, BNF rules, MIB definitions, etc.

  There are no such parts to the document.

Document Writeup, template from IESG area on ietf.org, dated 6th March 2015.

draft-ietf-dhc-dhcpv6-active-leasequery-02 write-up

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
Standard, Informational, Experimental, or Historic)? Why is this the proper type
of RFC? Is this type of RFC indicated in the title page header?

  Proposed standard. This document expands on the DHCPv6 Leasequery
  protocol, and allows for active transfer of real-time DHCPv6 binding
  information data via TCP.  This document also extends the DHCPv6 Bulk
  Leasequery by adding new options and updates the DHCPv6 Bulk
  Leasequery. The intended type is indicated in the document header.
 
(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent examples
can be found in the "Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary:
Relevant content can frequently be found in the abstract
and/or introduction of the document. If not, this may be
an indication that there are deficiencies in the abstract
or introduction.

  This document enables an entity not directly involved in DHCPv6
  client - server transactions to keep current with the state of the
  DHCPv6 lease state information in real-time.

Working Group Summary:
Was there anything in WG process that is worth noting? For example,
was there controversy about particular points or were there decisions
where the consensus was particularly rough?

  This document was called draft-raghuvanshi-dhc-dhcpv6-active-leasequery
  prior to its adoption. There was unanimous support for it in favor of
  adoption and none against), so this document was adopted in December
  2013. There was interest in this work posts since its adoption.
  There was never any opposition for this work.
 
  This document went through a relevant short document development
  period (2 months for individual document period, 4 month for WG document
  period). Its maturity took advantages from its twin-document -
  "Active DHCPv4 Lease Query" draft-ietf-dhc-dhcpv4-active-leasequery,
  which firstly submitted in early 2010.

Document Quality:
Are there existing implementations of the protocol? Have a significant
number of vendors indicated their plan to implement the specification?
Are there any reviewers that merit special mention as having done a
thorough review, e.g., one that resulted in important changes or a
conclusion that the document had no substantive issues? If there was
a MIB Doctor, Media Type or other expert review, what was its course
(briefly)? In the case of a Media Type review, on what date was the
request posted?

  I'm not aware of any existing implementations, but the authors claimed
  they have customers using DHCPv4 active leasequery. It is reasonable to
  assume these customers would require DHCPv6 active leasequery as long
  as their network extend to IPv6. No external requirements are needed
  as this work is purely DHCPv6 extension. There was a few reviews by
  DHC WG members. This document has requested publication in mid of 2014,
  and received a AD review from Ted Lemon. The authors updated the
  document in March 2015 to address the comments from AD review.


Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

  Sheng Jiang is the document shepherd.
  Ted Lemon is the responsible AD.
 
(3) Briefly describe the review of this document that was performed by the
Document Shepherd. If this version of the document is not ready for publication,
please explain why the document is being forwarded to the IESG.

  I thoroughly reviewed this document  (and had other minor
  comments in between):
 
  http://www.ietf.org/mail-archive/web/dhcwg/current/msg15379.html
 
  The issues raised in my last review were promptly addressed by authors
  in -01 version along with the comments from other DHC WG members. This
  document is ready for publication in my opinion.

  I also reviewed the latest changes from 01 to 02 in March 2015. It looks fine
  for me.
 
(4) Does the document Shepherd have any concerns about the depth or breadth of
the reviews that have been performed?

  No.
 
(5) Do portions of the document need review from a particular or from broader
perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or
internationalization? If so, describe the review that took place.

  No. This document has been carefully reviewed by the DHC WG.
 
(6) Describe any specific concerns or issues that the Document Shepherd has with
this document that the Responsible Area Director and/or the IESG should be aware
of? For example, perhaps he or she is uncomfortable with certain parts of the
document, or has concerns whether there really is a need for it. In any event,
if the WG has discussed those issues and has indicated that it still wishes to
advance the document, detail those concerns here.

  There are no outstanding issues.

(7) Has each author confirmed that any and all appropriate IPR disclosures
required for full conformance with the provisions of BCP 78 and BCP 79 have
already been filed. If not, explain why?

  Yes. The authors, Dushyant Raghuvanshi, Kim Kinnear and Deepak Kukrety
  confirmed that any and all appropriate IPR disclosures required for full
  conformance with the provisions of BCP 78 and BCP 79 have already been
  filed.
 
(8) Has an IPR disclosure been filed that references this document? If so,
summarize any WG discussion and conclusion regarding the IPR disclosures.

  Yes, an IPR disclosure (http://datatracker.ietf.org/ipr/2210/) been filed
  that references this document. The IPR declaration was submitted early on
  but the WG did not explicitly discuss the ipr at any time (wglc or
  otherwise) to my knowledge.
 
(9) How solid is the WG consensus behind this document? Does it represent the
strong concurrence of a few individuals, with others being silent, or does the
WG as a whole understand and agree with it?

  There was broad support for this document. It was reviewed by active WG
  participants. All changes were mostly minor.
 
(10) Has anyone threatened an appeal or otherwise indicated extreme discontent?
If so, please summarise the areas of conflict in separate email messages to the
Responsible Area Director. (It should be in a separate email because this
questionnaire is publicly available.)

  No. There was unanimous support for this work and nobody raised any objections.
 
(11) Identify any ID nits the Document Shepherd has found in this document. (See
http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be thorough.

  This document is now ID nits clean.
 
(12) Describe how the document meets any required formal review criteria, such
as the MIB Doctor, media type, and URI type reviews.

  No MIB Doctor, media type, URI type or similar apply to this
  document.
 
(13) Have all references within this document been identified as either
normative or informative?

  Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative references
exist, what is the plan for their completion?

  All normative references are published RFCs.
 
(15) Are there downward normative references references (see RFC 3967)? If so,
list these downward references to support the Area Director in the Last Call
procedure.

  No.

(16) Will publication of this document change the status of any existing RFCs?
Are those RFCs listed on the title page header, listed in the abstract, and
discussed in the introduction? If the RFCs are not listed in the Abstract and
Introduction, explain why, and point to the part of the document where the
relationship of this document to the other RFCs is discussed. If this
information is not in the document, explain why the WG considers it unnecessary.

  This document updates RFC 5460. It is listed on the title page header, listed
  in the abstract, and discussed in the introduction

(17) Describe the Document Shepherd's review of the IANA considerations section,
especially with regard to its consistency with the body of the document. Confirm
that all protocol extensions that the document makes are associated with the
appropriate reservations in IANA registries. Confirm that any referenced IANA
registries have been clearly identified. Confirm that newly created IANA
registries include a detailed specification of the initial contents for the
registry, that allocations procedures for future registrations are defined, and
a reasonable name for the new registry has been suggested (see RFC 5226).

  IANA is asked to assign 3 option codes for OPTION_LQ_BASE_TIME,
  OPTION_LQ_START_TIME, and OPTION_LQ_END_TIME; 2 status codes for DataMissing
  CatchUpComplete; 1 message type for  ACTIVELEASEQUERY.
 
  All the necessary information is in the IANA considerations document. It is
  clear enough that the IANA will be able to implement it.
 
(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find useful in
selecting the IANA Experts for these new registries.

  No such registry is requested in this document.
 
(19) Describe reviews and automated checks performed by the Document Shepherd to
validate sections of the document written in a formal language, such as XML
code, BNF rules, MIB definitions, etc.

  There are no such parts to the document.

I'm moving this to AD is watching, which means that I do not consider it a candidate for publication until it has been updated based on my AD review.

Document Writeup, template from IESG area on ietf.org, dated 4th April 2014.

draft-ietf-dhc-dhcpv6-active-leasequery-01 write-up

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
Standard, Informational, Experimental, or Historic)? Why is this the proper type
of RFC? Is this type of RFC indicated in the title page header?

  Proposed standard. This document expands on the DHCPv6 Leasequery
  protocol, and allows for active transfer of real-time DHCPv6 binding
  information data via TCP.  This document also extends DHCPv6 Bulk
  Leasequery by adding new options. The intended type is indicated in
  the document header.
 
(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent examples
can be found in the "Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary:
Relevant content can frequently be found in the abstract
and/or introduction of the document. If not, this may be
an indication that there are deficiencies in the abstract
or introduction.

  This document enables an entity not directly involved in DHCPv6
  client - server transactions to keep current with the state of the
  DHCPv6 lease state information in real-time.

Working Group Summary:
Was there anything in WG process that is worth noting? For example,
was there controversy about particular points or were there decisions
where the consensus was particularly rough?

  This document was called draft-raghuvanshi-dhc-dhcpv6-active-leasequery
  prior to its adoption. There was unanimous support for it in favor of
  adoption and none against), so this document was adopted in December
  2013. There was interest in this work posts since its adoption.
  There was never any opposition for this work.
 
  This document went through a relevant short document development
  period (2 months for individual document period, 4 month for WG document
  period). Its maturity took advantages from its twin-document -
  "Active DHCPv4 Lease Query" draft-ietf-dhc-dhcpv4-active-leasequery,
  which firstly submitted in early 2010.

Document Quality:
Are there existing implementations of the protocol? Have a significant
number of vendors indicated their plan to implement the specification?
Are there any reviewers that merit special mention as having done a
thorough review, e.g., one that resulted in important changes or a
conclusion that the document had no substantive issues? If there was
a MIB Doctor, Media Type or other expert review, what was its course
(briefly)? In the case of a Media Type review, on what date was the
request posted?

  I'm not aware of any existing implementations, but the authors claimed
  they have customers using DHCPv4 active leasequery. It is reasonable to
  assume these customers would require DHCPv6 active leasequery as long
  as their network extend to IPv6. No external requirements are needed
  as this work is purely DHCPv6 extension. There was a few reviews by
  DHC WG members.


Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

  Sheng Jiang is the document shepherd.
  Ted Lemon is the responsible AD.
 
(3) Briefly describe the review of this document that was performed by the
Document Shepherd. If this version of the document is not ready for publication,
please explain why the document is being forwarded to the IESG.

  I thoroughly reviewed this document  (and had other minor
  comments in between):
 
  http://www.ietf.org/mail-archive/web/dhcwg/current/msg15379.html
 
  The issues raised in my last review were promptly addressed by authors
  in -01 version along with the comments from other DHC WG members. This
  document is ready for publication in my opinion.
 
(4) Does the document Shepherd have any concerns about the depth or breadth of
the reviews that have been performed?

  No.
 
(5) Do portions of the document need review from a particular or from broader
perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or
internationalization? If so, describe the review that took place.

  No. This document has been carefully reviewed by DHC WG.
 
(6) Describe any specific concerns or issues that the Document Shepherd has with
this document that the Responsible Area Director and/or the IESG should be aware
of? For example, perhaps he or she is uncomfortable with certain parts of the
document, or has concerns whether there really is a need for it. In any event,
if the WG has discussed those issues and has indicated that it still wishes to
advance the document, detail those concerns here.

  There are no outstanding issues.

(7) Has each author confirmed that any and all appropriate IPR disclosures
required for full conformance with the provisions of BCP 78 and BCP 79 have
already been filed. If not, explain why?

  Yes. The authors, Dushyant Raghuvanshi, Kim Kinnear and Deepak Kukrety
  confirmed that any and all appropriate IPR disclosures required for full
  conformance with the provisions of BCP 78 and BCP 79 have already been
  filed.
 
(8) Has an IPR disclosure been filed that references this document? If so,
summarize any WG discussion and conclusion regarding the IPR disclosures.

  Yes, an IPR disclosure (http://datatracker.ietf.org/ipr/2210/) been filed
  that references this document. The IPR declaration was submitted early on
  but the WG did not explicitly discuss the ipr at any time (wglc or
  otherwise) to my knowledge.
 
(9) How solid is the WG consensus behind this document? Does it represent the
strong concurrence of a few individuals, with others being silent, or does the
WG as a whole understand and agree with it?

  There was broad support for this document. It was reviewed by active WG
  participants. All changes were mostly minor.
 
(10) Has anyone threatened an appeal or otherwise indicated extreme discontent?
If so, please summarise the areas of conflict in separate email messages to the
Responsible Area Director. (It should be in a separate email because this
questionnaire is publicly available.)

  No. There was unanimous support for this work and nobody raised any objections.
 
(11) Identify any ID nits the Document Shepherd has found in this document. (See
http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be thorough.

  This document is now ID nits clean.
 
(12) Describe how the document meets any required formal review criteria, such
as the MIB Doctor, media type, and URI type reviews.

  No MIB Doctor, media type, URI type or similar apply to this
  document.
 
(13) Have all references within this document been identified as either
normative or informative?

  Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative references
exist, what is the plan for their completion?

  All normative references are published RFCs.
 
(15) Are there downward normative references references (see RFC 3967)? If so,
list these downward references to support the Area Director in the Last Call
procedure.

  No.

(16) Will publication of this document change the status of any existing RFCs?
Are those RFCs listed on the title page header, listed in the abstract, and
discussed in the introduction? If the RFCs are not listed in the Abstract and
Introduction, explain why, and point to the part of the document where the
relationship of this document to the other RFCs is discussed. If this
information is not in the document, explain why the WG considers it unnecessary.

  This document does not update any existing RFCs.

(17) Describe the Document Shepherd's review of the IANA considerations section,
especially with regard to its consistency with the body of the document. Confirm
that all protocol extensions that the document makes are associated with the
appropriate reservations in IANA registries. Confirm that any referenced IANA
registries have been clearly identified. Confirm that newly created IANA
registries include a detailed specification of the initial contents for the
registry, that allocations procedures for future registrations are defined, and
a reasonable name for the new registry has been suggested (see RFC 5226).

  IANA is asked to assign 3 option codes for OPTION_LQ_BASE_TIME,
  OPTION_LQ_START_TIME, and OPTION_LQ_END_TIME; 2 status codes for DataMissing
  CatchUpComplete; 1 message type for  ACTIVELEASEQUERY.
 
  All the necessary information is in the IANA considerations document. It is
  clear enough that the IANA will be able to implement it.
 
(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find useful in
selecting the IANA Experts for these new registries.

  No such registry is requested in this document.
 
(19) Describe reviews and automated checks performed by the Document Shepherd to
validate sections of the document written in a formal language, such as XML
code, BNF rules, MIB definitions, etc.

  There are no such parts to the document.