Guidelines for Creating New DHCPv6 Options
draft-ietf-dhc-option-guidelines-17

[Ballot comment]
Thanks to the authors for making section 8 much more balanced.

---old comments---

I realize that v4 is old news, but since not everyone has turned off DHCPv4 yet, is there a reason that this document is v6-only?

In section 5.3, it looks odd to see prefix6-Len in the math, where the "-" character would normally be subtraction.

RFC 5986, 5223 could also be references for 5.10.

[Ballot comment]

Thanks for nicely addressing my discuss points about privacy.

--- old comments below

- 5.7 supports 16 bit URI lengths - maybe you could note
that that's a bit bigger than is likely to be useful

- section 8: that made me wonder if you've any guidance on
whether URIs should include FQDNs or addresses. Just a nit.

- section 8, last para on p15: another nit - there's a case
where an option might be an FQDN that's sent in another
protocol (e.g. HTTP) to a proxy and only then resolved to an
address.

- section 23, 1st para: this should say clearly that the
authentication stuff is hardly used. The 2nd para assume
that but its not explicitly stated and should be.

[Ballot discuss]
It's a DISCUSS but a positive DISCUSS :-). Let me explain.

This document is all about how protocol developers will need to build DHCPv6 options.
I see that http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml#dhcpv6-parameters-2 is "Expert Review and Standards Action", as described in RFC 3315.
I guess that the Experts will be reviewing this BCP for compliance, and will sanction the non-compliant options. I believe that this should be clearly mentioned.

Here is what I have in mind. RFC 7013

                Guidelines for Authors and Reviewers of
        IP Flow Information Export (IPFIX) Information Elements

Abstract

  This document provides guidelines for how to write definitions of new
  Information Elements for the IP Flow Information Export (IPFIX)
  protocol.  It provides instructions on using the proper conventions
  for Information Elements to be registered in the IANA IPFIX
  Information Element registry, and provides guidelines for expert
  reviewers to evaluate new registrations.

So it's just a question of extending the document scope with a couple of extra paragraphs.
What I call a positive DISCUSS.

[Ballot discuss]



I also liked this document, thanks. I've a couple of things
I'd like to discuss though:

(1) There are no privacy considerations here - shouldn't
there be? If some DHCP options (old or new) expose
personally identifying information (PII) and are sent in
clear or broadcast/multicast then that's presumably not a
great thing. Shouldn't you tell people to avoid doing that
unless there's a good reason or something? (If there are
such options already then it might be good to list some of
those and comment on them too as you've done in other
cases.)

(2) The security considerations recognises that DHCP is
basically used in clear, but doesn't that mean you should
recommend that DHCP options not contain values that are
sensitive? E.g. presumaby it'd be dumb to try to define a
new option that sent a client the key to a VPN except in
some really weird circumstance?

[Ballot comment]

- 5.7 supports 16 bit URI lengths - maybe you could note
that that's a bit bigger than is likely to be useful

- section 8: that made me wonder if you've any guidance on
whether URIs should include FQDNs or addresses. Just a nit.

- section 8, last para on p15: another nit - there's a case
where an option might be an FQDN that's sent in another
protocol (e.g. HTTP) to a proxy and only then resolved to an
address.

- section 23, 1st para: this should say clearly that the
authentication stuff is hardly used. The 2nd para assume
that but its not explicitly stated and should be.

[Ballot comment]
typo: participates in leasequery protocol

This an excellent document with a utility that transcends
its primary purpose.

One surprising omission from the security section is the
need to clear padding to prevent the inadvertent transmission
as a result of buffer reuse.

[Ballot comment]
As per my email, I am very interested in the result of the DISCUSSion with Richard. I am left wondering whether the document should loosen the language in section 8, or tighten the language elsewhere.

[Ballot comment]
This is a very fine document, and a very good read.  I think it's an important document.  So, while all my comments below are non-blocking, I think most of them are important to clarity, and I ask you to consider them.  Please chat with me about them if you think it'll help.  (It's especially important to get the advice to the ADs clear; we tend to get all verblunget otherwise.)

-- Section 5.2 --

  Sometimes it is useful to convey a single flag that can either take
  on or off values.  Instead of specifying an option with one bit of
  usable data and 7 bits of padding, it is better to define an option
  without any content.  It is the presence or absence of the option
  that conveys the value.  This approach has the additional benefit of
  absent option designating the default, i.e. administrator has to take
  explicit actions to deploy the opposite of the default value.

First, a nit: the "either" is misplaced; it should say "that can take either on or off values."

Now, the substance: The intent of this is to say that the absence of the option represents the default value and the presence of the option represents the other value, but that this does *not* necessarily mean that absence is "off" (or "false") and presence is "on" (or "true").  That is, if it's desired that the default value for a bistable option is "true"/"on", then the presence of that option would turn it off (make it false).

That seems a potentially confusing point that should be made extremely clear, and I think a bit more text here to clarify it would really help.  It's too easy for someone who doesn't read carefully enough to assume that, naturally, the presence of the option always means "on", and the absence, "off".  If you're saying otherwise, I think that glaringly clear text is needed.

-- Section 5.8 --

  A string must not
  enclude any terminator (such as a null byte).

Misspelling: "enclude".  There's one thing I find unclear about this sentence: is it trying to say that certain characters (such as U+0000) are not allowed in strings?  Or is it simply saying that the representation here is of the string itself, and does not include any applicable termination characters?  It would be good to make this clear, either way.

-- Section 8 --

I'd like to see the conversation from Richard's DISCUSS.  I agree that addresses are better than FQDNs for lower-layer, shorter-term information -- perhaps how to contact VPNs, and such, where the address will be used and then discarded, to be re-obtained next time.  But for options that are used to configure app-layer things (SIP or IMAP server addresses, say), where clients will retain the information and use it long-term, FQDNs are much more appropriate.

-- Section 9 --

I see that Brian's DISCUSS might cause a significant change here, but in case some of this remains I want to point this out:  "SHOULD NOT under any circumstances" makes no sense in a 2119 context.  "SHOULD NOT", by definition (see RFC 2119) allows that there might indeed be circumstances when you might choose to do otherwise.

-- Section 13 --

  This is true whether the new fragment type has the same
  structure as an existing fragment type, but has different semantics.
  It is equally true when the new format has a new structure.

This misuses "whether", to the point that I find it confusing.  "Whether" requires alternatives: "This is true whether  or ."  I don't understand what this means to say.  Does it, perhaps, mean this?:

  This is true whether the new fragment type has the same
  structure as an existing fragment type but has different semantics,
  or the new format has a new structure.

(And, are "new fragment type" and "new format" meant to be different?)  Perhaps some re-wording would be better.

  Responsible Area Directors for working groups that wish to add a work
  item to a working group charter to define a new DHCP option should
  get clarity from the working group as to whether the new option is a
  simple DHCP option with no new fragment type or new fragment
  semantics, or whether it in fact will require new fragment types.

This is a long, involved sentence, so let's be sure it's clear.  Do you mean "no new fragment type and no new fragment semantics"?  The "or" seems unclear.  Then the next part, "or whether it in fact will require new fragment types," leaves me to question what the case should be if it might require new semantics -- that case isn't covered.

Maybe this will work better, and will put the focus in the right place?:

NEW
  Responsible Area Directors for working groups that wish to add a work
  item to a working group charter to define a new DHCP option should
  get clarity from the working group as to whether the new option will
  require a new fragment type or new semantics, or whether it is a
  simple DHCP option that fits existing definitions.
END

  If a working group needs a new fragment type, it is preferable to
  seek out a working group whose members already have sufficient
  expertise to evaluate the new work and try to come up with a new
  format that generalizes well and can be reused, rather than a single-
  use fragment type.

I'm again confused, and I think this and the subsequent text could use some factoring out.  You have a few ideas intermixed here:
1a. Try to find another working group with the right expertise.
1b. Failing that, look for DHCP experts to help.
2. The new option should be defined in a separate document.
3. In defining the new option, it's important to look for a generalizable format, not a single-use thing.

How about if we tease these apart and reorganize two paragraphs?  Maybe this?:

NEW
  If a working group needs a new fragment type, it is preferable to
  see if another working group exists whose members already have
  sufficient expertise to evaluate the new work.  If such a working
  group is available, the work should be chartered in that working
  group instead.  If there is no other working group with DHCP
  expertise that can define the new fragment type, the responsible AD
  should seek help from known DHCP experts within the IETF to provide
  advice and frequent early review as the original working group
  defines the new fragment type.

  In either case, the new option should be defined in a separate
  document, and the work should focus on defining a new format that
  generalizes well and can be reused, rather than a single-use
  fragment type.  The working group that needs the new fragment type
  can define their new option referencing the new fragment type
  document, and the work can generally be done in parallel, avoiding
  unnecessary delays.  Having the definition in its own document will
  foster reuse of the new fragment type.
 
  The responsible AD should work with all relevant working group
  chairs and DHCP experts to ensure that the new fragment type
  document has in fact been carefully reviewed by the experts and
  appears satisfactory.
END

-- Section 15 --

Pet peeve alert:

  In general, if a lot of data needs to be configured (i.e. large
  option lengths)

Is "i.e." really what you want here?  Are large option lengths the *only* reason that a lot of data might need to be configured?  Or could there be other reasons (maybe a large number of short options)?

I think you mean this:

NEW
  In general, if a lot of data needs to be configured (for example,
  some option lengths are quite large)
END

Make "an URI" be "a URI" (or the RFC Editor will).  People don't really say, "an oo-ree", do they?  Everyone I know says, "a yoo-are-eye".  And, by the way, strictly speaking, the URI specifies where (not "how") to obtain the actual configuration information.

-- Section 16 --

  Allowing multiple option instances often leads to confusion.
  Consider the following example.

Considered.  But wasn't the failure there not that there could be multiple instances, but that no one had defined what multiple instances *meant*?  Might it be good here to say that you should avoid multiple instances, but that if you do have to use them it's important to clearly document what to do with them?

-- Section 17 --

  Option order, either the order among many DHCPv6 options or the order
  of multiple instances of the same option, SHOULD NOT be significant
  and MUST NOT be assumed.

What does that sequence of 2119 key words mean?  I think my confusion comes from the second one being orphaned in some way here.  What you're saying is this:
1. Option order SHOULD NOT be significant.
2. Option order MUST NOT be assumed.

1 is fine, and it makes sense.  For 2, I don't know what it means; it's missing something.  And even if I guess, I don't know what the combination of SHOULD NOT and MUST NOT is trying to tell me.  Perhaps you can re-word this?

By the way, a related anecdote: the IMAP email protocol has a number of situations in which things are almost always sent in a certain order by all servers, but the protocol definition doesn't require that ordering.  Someone once wrote an IMAP server that spit those things out in arbitrary order, which differed from response to response.  That server uncovered a lot of client bugs.  :-)

[Ballot comment]
This is a very fine document, and a very good read.  I think it's an important document.  So, while all my comments below are non-blocking, I think most of them are important to clarity, and I ask you to consider them.  Please chat with me about them if you think it'll help.  (It's especially important to get the advice to the ADs clear; we tend to get all verblunget otherwise.)

-- Section 5.2 --

  Sometimes it is useful to convey a single flag that can either take
  on or off values.  Instead of specifying an option with one bit of
  usable data and 7 bits of padding, it is better to define an option
  without any content.  It is the presence or absence of the option
  that conveys the value.  This approach has the additional benefit of
  absent option designating the default, i.e. administrator has to take
  explicit actions to deploy the opposite of the default value.

First, a nit: the "either" is misplaced; it should say "that can take either on or off values."

Now, the substance: The intent of this is to say that the absence of the option represents the default value and the presence of the option represents the other value, but that this does *not* necessarily mean that absence is "off" (or "false") and presence is "on" (or "true").  That is, if it's desired that the default value for a bistable option is "true"/"on", then the presence of that option would turn it off (make it false).

That seems a potentially confusing point that should be made extremely clear, and I think a bit more text here to clarify it would really help.  It's too easy for someone who doesn't read carefully enough to assume that, naturally, the presence of the option always means "on", and the absence, "off".  If you're saying otherwise, I think that glaringly clear text is needed.

-- Section 5.8 --

  A string must not
  enclude any terminator (such as a null byte).

Misspelling: "enclude".  There's one thing I find unclear about this sentence: is it trying to say that certain characters (such as U+0000) are not allowed in strings?  Or is it simply saying that the representation here is of the string itself, and does not include any applicable termination characters?  It would be good to make this clear, either way.

-- Section 8 --

I'd like to see the conversation from Richard's DISCUSS.  I agree that addresses are better than FQDNs for lower-layer, shorter-term information -- perhaps how to contact VPNs, and such, where the address will be used and then discarded, to be re-obtained next time.  But for options that are used to configure app-layer things (SIP or IMAP server addresses, say), where clients will retain the information and use it long-term, FQDNs are much more appropriate.

-- Section 9 --

I see that Brian's DISCUSS might cause a significant change here, but in case some of this remains I want to point this out:  "SHOULD NOT under any circumstances" makes no sense in a 2119 context.  "SHOULD NOT", by definition (see RFC 2119) allows that there might indeed be circumstances when you might choose to do otherwise.

-- Section 13 --

  This is true whether the new fragment type has the same
  structure as an existing fragment type, but has different semantics.
  It is equally true when the new format has a new structure.

This misuses "whether", to the point that I find it confusing.  "Whether" requires alternatives: "This is true whether  or ."  I don't understand what this means to say.  Does it, perhaps, mean this?:

  This is true whether the new fragment type has the same
  structure as an existing fragment type but has different semantics,
  or the new format has a new structure.

(And, are "new fragment type" and "new format" meant to be different?)  Perhaps some re-wording would be bettwe.

  Responsible Area Directors for working groups that wish to add a work
  item to a working group charter to define a new DHCP option should
  get clarity from the working group as to whether the new option is a
  simple DHCP option with no new fragment type or new fragment
  semantics, or whether it in fact will require new fragment types.

This is a long, involved sentence, so let's be sure it's clear.  Do you mean "no new fragment type and no new fragment semantics"?  The "or" seems unclear.  Then the next part, "or whether it in fact will require new fragment types," leaves me to question what the case should be if it might require new semantics -- that case isn't covered.

Maybe this will work better, and will put the focus in the right place?:

NEW
  Responsible Area Directors for working groups that wish to add a work
  item to a working group charter to define a new DHCP option should
  get clarity from the working group as to whether the new option will
  require a new fragment type or new semantics, or whether it is a
  simple DHCP option that fits existing definitions.
END

  If a working group needs a new fragment type, it is preferable to
  seek out a working group whose members already have sufficient
  expertise to evaluate the new work and try to come up with a new
  format that generalizes well and can be reused, rather than a single-
  use fragment type.

I'm again confused, and I think this and the subsequent text could use some factoring out.  You have a few ideas intermixed here:
1a. Try to find another working group with the right expertise.
1b. Failing that, look for DHCP experts to help.
2. The new option should be defined in a separate document.
3. In defining the new option, it's important to look for a generalizable format, not a single-use thing.

How about if we tease these apart and reorganize two paragraphs?  Maybe this?:

NEW
  If a working group needs a new fragment type, it is preferable to
  see if another working group exists whose members already have
  sufficient expertise to evaluate the new work.  If such a working
  group is available, the work should be chartered in that working
  group instead.  If there is no other working group with DHCP
  expertise that can define the new fragment type, the responsible AD
  should seek help from known DHCP experts within the IETF to provide
  advice and frequent early review as the original working group
  defines the new fragment type.

  In either case, the new option should be defined in a separate
  document, and the work should focus on defining a new format that
  generalizes well and can be reused, rather than a single-use
  fragment type.  The working group that needs the new fragment type
  can define their new option referencing the new fragment type
  document, and the work can generally be done in parallel, avoiding
  unnecessary delays.  Having the definition in its own document will
  foster reuse of the new fragment type.
 
  The responsible AD should work with all relevant working group
  chairs and DHCP experts to ensure that the new fragment type
  document has in fact been carefully reviewed by the experts and
  appears satisfactory.
END

-- Section 15 --

Pet peeve alert:

  In general, if a lot of data needs to be configured (i.e. large
  option lengths)

Is "i.e." really what you want here?  Are large option lengths the *only* reason that a lot of data might need to be configured?  Or could there be other reasons (maybe a large number of short options)?

I think you mean this:

NEW
  In general, if a lot of data needs to be configured (for example,
  some option lengths are quite large)
END

Make "an URI" be "a URI" (or the RFC Editor will).  People don't really say, "an oo-ree", do they?  Everyone I know says, "a yoo-are-eye".  And, by the way, strictly speaking, the URI specifies where (not "how") to obtain the actual configuration information.

-- Section 16 --

  Allowing multiple option instances often leads to confusion.
  Consider the following example.

Considered.  But wasn't the failure there not that there could be multiple instances, but that no one had defined what multiple instances *meant*?  Might it be good here to say that you should avoid multiple instances, but that if you do have to use them it's important to clearly document what to do with them?

-- Section 17 --

  Option order, either the order among many DHCPv6 options or the order
  of multiple instances of the same option, SHOULD NOT be significant
  and MUST NOT be assumed.

What does that sequence of 2119 key words mean?  I think my confusion comes from the second one being orphaned in some way here.  What you're saying is this:
1. Option order SHOULD NOT be significant.
2. Option order MUST NOT be assumed.

1 is fine, and it makes sense.  For 2, I don't know what it means; it's missing something.  And even if I guess, I don't know what the combination of SHOULD NOT and MUST NOT is trying to tell me.  Perhaps you can re-word this?

By the way, a related anecdote: the IMAP email protocol has a number of situations in which things are almost always sent in a certain order by all servers, but the protocol definition doesn't require that ordering.  Someone once wrote an IMAP server that spit those things out in arbitrary order, which differed from response to response.  That server uncovered a lot of client bugs.  :-)

[Ballot discuss]
In general, this is a very nice document, but Section 8 seems wrong to me.  I was very surprised to find that Section 8 recommends the use of addresses instead of FQDNs.  From an application-layer perspective, I would have expected the guidance to be exactly the reverse. 

All of the "failure modes" listed at the end of the section are all things that applications have to deal with anyway, whether or not they're configured with DHCP.    The only exception is the first (that the client might not have DNS servers configured), which for many options will cause the application-layer protocol to fail anyway.

This section also fails to consider the drawbacks of using addresses for configuration.  Most obviously, address-based configuration is brittle -- if I add a SIP server to my cluster, should I have to force all the DHCP clients to renew their leases?  There's also a security benefit to using domain names, since it's much more common to have credentials tied to domain names than to IP addresses.

I would strongly urge the WG to reconsider the advice in this section.  The considerations listed are worth noting, but in practice, they are far outweighed by the benefits of using FQDNs.

[Ballot comment]
I realize that v4 is old news, but since not everyone has turned off DHCPv4 yet, is there a reason that this document is v6-only?

In section 5.3, it looks odd to see prefix6-Len in the math, where the "-" character would normally be subtraction.

RFC 5986, 5223 could also be references for 5.10.

[Ballot comment]
Brian's point is germain and should be corrected. 5908 is for better or worse a standards track document which the community approved and the IESG reviewed.

[Ballot discuss]
This document provides some useful advice and I completely support the publication of this document modulo the derogatory example given in section 9 wrt RFC 5908.  We have been around this sinkhole before and the characterization in section 9 does not reflect what really happened with the publication of RFC 5908.  I think the point of the section can be made clearly without embedding a clouded view of the history of 5908.

[Ballot comment]
This one of the most helpful IETF documents I've seen in a long time.

Please thank the working group for producing it. It's clearly written and was a pleasure to review.

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-dhc-option-guidelines-14, which is currently in Last Call, and has the following comments:

We understand that, upon approval of this document, there are no IANA
Actions that need completion.  IANA requests that the IANA Considerations section of the document remain in place upon publication.

If this assessment is not accurate, please respond as soon as possible.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Guidelines for Creating New DHCPv6 Options) to Best Current Practice


The IESG has received a request from the Dynamic Host Configuration WG
(dhc) to consider the following document:
- 'Guidelines for Creating New DHCPv6 Options'
  as Best Current Practice

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 2013-10-03. 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


  This document provides guidance to prospective DHCPv6 Option
  developers to help them creating option formats that are easily
  adoptable by existing DHCPv6 software.  This document updates
  RFC3315.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-dhc-option-guidelines/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-dhc-option-guidelines/ballot/


No IPR declarations have been submitted directly on this I-D.

Depending on how the authors choose to handle one of my comments, this may require a new WGLC; it definitely requires a document update if the authors agree to any of the changes I suggested as a result of my AD review.

(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?

BCP.  This documents how DHCPv6 options should be formatted.

(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:

This document provides guidance to prospective DHCPv6 developers to
help them create new options that are easily adoptable by existing
DHCPv6 software.

Working Group Summary:

This document has been in development in the DHC working group for a
long time. It started out targetted for DHCPv4 but was reworked for
DHCPv6 as the working group expects more options to be defined for
DHCPv6 going fowrard. There has been solid support for this work.

Document Quality:

The document has had extensive review and input by the working group
and "DHCP experts".


Personnel:

Bernie Volz 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 read the document thoroughly, and submitted quite a few editorial
suggestions to the authors, which they implemented.

(4) Does the document Shepherd have any concerns about the depth or
    breadth of the reviews that have been performed?

No, the document has had a great deal of careful review.

(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.

This is strictly a DHCP doc, and has had plenty of review from DHCP
experts.

(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.

I think the document is good as written, and serves an extremely
useful purpose. It will assist other working groups and individuals
in developing new DHCP options.


(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 confirmed that there are no IPR disclosures required.

(8) Has an IPR disclosure been filed that references this document? If
    so, summarize any WG discussion and conclusion regarding the IPR
    disclosures.

No.

(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 is a very strong consensus behind this document and in particular
from very active WG participants (i.e. "DHCP experts").

(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, and nobody's indicated that they were against the WGLC or had
any issues with the document. It document existing, but undocumented,
practices.

(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.

The document passes idnits with no errors and review using the
checklist did not turn up any issues. It does raise an issue with
regards to content prior to Nov 2008, but the one author of the
document (David Hankins) prior to this date has no issues with
granting the BCP78 rights to the IETF Trust.


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

The document contains nothing like this.

(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?

No, all the normative references are to 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.

Not that status, but it does update RFC 3315. I have a small concern
here as this updates to RFC 3315 are not clearly spelled out - they are
in Section 16 (options are singletons unless specified otherwise) and
17 (options have no ordering). These are more clarifications of RFC
3315 as that document did not explicitly address these issues.


(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).

I reviewed the IANA Considerations section and it is fine and clear,
there are no IANA actions.

(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.

None.

(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.

The document has very good support from the community but as several sets of extensive comments were provided, a revised document is needed with those changes so that the WG can review the changes and determine consensus to advance to the document.