An Opportunistic Approach for Secure Real-time Transport Protocol (OSRTP)
draft-ietf-sipbrandy-osrtp-10

PROTO Writeup for draft-ietf-sipbrandy-osrtp-07

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

    Informational, as indicated in the title page header. The reasoning for “informational” is two-fold:

  1) The draft does not (or was not supposed to) define new or modify existing protocols.
        It talks about how one can assemble existing building blocks to make the right things
        happen, not how to build new blocks. So it seemed like the most appropriate status
        was either “informational” or “BCP"
  2) Two of those “existing protocols”, namely ZRTP [RFC6189] and SDP Security Descriptions [RFC4568]
        are not particularly well regarded among some of our security experts, who indicated objections to
        using them in a new standards track document or BCP.

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

    Opportunistic Secure Real-time Transport Protocol (OSRTP) is an
    implementation of the Opportunistic Security mechanism, as defined
    in RFC 7435, applied to Real-time Transport Protocol (RTP).  OSRTP
    allows encrypted media to be used in environments where support
    for encryption is not known in advance, and not required.  OSRTP
    does not require SDP extensions or features and is fully backwards
    compatible with existing implementations using encrypted and
    authenticated media and implementations that do not encrypt or
    authenticate media packets.  OSRTP is not specific to any key
    management technique for SRTP.  OSRTP is a transitional approach
    useful for migrating existing deployments of real-time
    communications to a fully encrypted and authenticated state.

Working Group Summary:

    There is consensus in the WG around this document.

Document Quality:

  Section 6 of the document (to be removed before its publication as
  an RFC) discusses the implementation status of the techniques
  described in the document.

Personnel:

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

    Gonzalo Camarillo is the Document Shepherd. Ben Campbell 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.

    The document shepherd reviewed revision 05 of this document, which
    was ready for publication.

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

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

    No concerns.

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

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

    The whole WG understands the document and agree with
    it. Nevertheless, the number of active participants in the
    SIPBRANDY WG is limited at this point.

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

(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 contains no relevant nits.   


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

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

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

    No.

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

    The IANA Considerations Section is complete and consistent.

(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 new registries are defined.

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

    No such checks were needed.

[Ballot comment]
(1) Section 1.1.  Per “It is only to be used in existing deployments which are attempting to transition to fully secure communications.  New applications and new deployments will not use  OSRTP.”, I was expecting RFC2119 words for the second sentence on the order of “New application … should not …”.

(2) Section 3.1.  Is there any value in creating a registry to manage the possible “a=xxx” offer types?

(3) Editorial Nits:
Section 1.0. Extra space.  s/[RFC5939] ./[RFC5939]./
Section 1.0.  Expand OSRTP acronym on first use.  (done in title and abstract but not in text)
Section 3.  Typo.  s/oportunistic/opportunistic/

[Ballot comment]
If ZRTP is already an OS method, and there are no changes to the ZRTP
usage or security considerations as part of OSRTP, why do we need to
cover ZRTP in this document at all (other than a pointer to "this other
OS mechanism exists")?

I could also see someone subscribing to an "attractive nuisance" theory
that obliges us to put a stronger disclaimer against secdes and/or ZRTP
usage, since we mention them in this document.  Perhaps something about
how they are generally considered to not be reasonable solutions for
"comprehensive protection" solutions but can still be useful in OS
environments?

Abstract

  Opportunistic Secure Real-time Transport Protocol (OSRTP) is an
  implementation of the Opportunistic Security mechanism, as defined in

nit: maybe s/implementation/application/?

Section 1

                                    OSRTP allows SRTP to be negotiated
  with the RTP/AVP profile, with fallback to RTP if SRTP is not
  supported.

nit: Given the preceding context, I don't see a way to read this other
than OSRTP using RTP/AVP and disallowing RTP/AVPF.  I don't know whether
an "RFP/AVP(F)" notation is at all conventional (we do "(D)TLS" and
"(EC)DHE" a lot in the security area) or they would need to both be
written out.

I agree with the directorate reviewer that inlining a substantial
portion of the "motivation and requirements for opportunistic secure
media" from draft-kaplan-mmusic-best-effort-srtp into this document
would be appropriate (while still acknowledging the prior effort).

                                      OSRTP requires no additional
  extensions to SDP or new attributes and is defined independently of
  the key agreement mechanism used.  [...]

The "defined independently" part seems to only mostly be true; see,
e.g., the security considerations where we override the need for
authenticated signaling for DTLS-SRTP OSRTP.


Section 2

Please use the boilerplate from RFC 8174 (in particular, just the "BCP
14 [RFC2119] [RFC8174]" label+references is fine).

Section 3

nit: I think most recent documents going by use "m=" rather than "m-".

  It is important to note that OSRTP makes no changes, and has no
  effect on media sessions in which the offer contains a secure profile

nit: comma after "no effect on" -- the current text is saying that OSRTP
makes no changes at all, globally, without scoping to media sessions in
which the offer contains a secure profile (which I presume to be the
intent).  I think we also need to add "to" in "makes no changes to".

Section 4

  While OSRTP does not require authentication of the key-agreement
  mechanism, it does need to avoid exposing SRTP keys to eavesdroppers,
  since this could enable passive attacks against SRTP.  Section 8.3 of
  [RFC7435] requires that any messages that contain SRTP keys be

As already noted, this is probably supposed to be an RFC 4568 reference.
Yet that is specific to secdes and not a generic SRTP consideration.

  encrypted, and further says that encryption "SHOULD" provide end-to-
  end confidentiality protection if intermediaries that could inspect
  the SDP message are present.  At the time of this writing, it is
  understood that the [RFC7435] requirement for end-to-end
  confidentiality protection is commonly ignored.  Therefore, if OSRTP

As noted, this is not an RFC 7435 requirement, and 4568 seems to be
the most likely interpretation.
FWIW, my reading of 4568 is that it requires end-to-end authentication
as well as confidentiality.  (And yes, we attempt to relax that above.)
Finally, the tsvart reviewer's concerns might be alleviated if we say
"end-to-end (as opposed to just hop-by-hop) confidentiality protection".

Also, it might be nice to give some reference for the "commonly ignored"
statement, if such is readily available.

  is used with SDP Security Descriptions, any such intermediaries
  (e.g., SIP proxies) must be assumed to have access to the SRTP keys.

Given that all of this paragraph (except potentially the first sentence)
seems to be secdes-specific, I'd suggest breaking it out into a new
paragraph and explicitly scoping to RFC 4568, and possibly even using a
subsection to indicate the scope.

Also, we should probably have another sentence or two to mention what
the potential consequences of intermediate access to keys are.

  As discussed in [RFC7435], OSRTP is used in cases where support for
  encryption by the other party is not known in advance, and not
  required.  [...]

nit: 7435 does not discuss OS*RTP*'s use at all.  So some rewording
seems in order, like, "As discussed in [RFC7435], opportunistic
security in general, and thus OSRTP specifically, is used" or "Per the
discussion in [RFC7435], OSRTP is used", etc.

Section 6

  There are implementations of [I-D.kaplan-mmusic-best-effort-srtp] in
  deployed products by Microsoft and Unify.  The IMTC "Best Practices
  for SIP Security" document [IMTC-SIP] recommends this approach.  The
  SIP Forum planned to include support in the SIPconnect 2.0 SIP
  trunking recommendation [SIPCONNECT].  There are many deployments of
  ZRTP [RFC6189].

nit: I know this is to be removed before publication, but "recommends
this approach" is a bit ambiguous about whether the kaplan approach or
this document is being recommended.

[Ballot comment]
I share the question of why this is Informational and why the shepherd writeup doesn't explain (the writeup says little more than "yes" and "no").

[Ballot comment]
Why is the intended status informational? Unfortunately, this is not further explained in the shepherd write-up. What was the discussion in the group and why was informational decided? As this is a protocol specification, informational does not seem appropriate. Except this is meant to only document an existing deployment but then the document should say so. I think it should rather be experimental.

[Ballot comment]
Why is the intended status information? Unfortunately, this is not further explained in the shepherd write-up. What was the discuss in the group and why was informational picked? As this is a protocol specification, informational does not seem appropriate. Except this is meant to only document an existing deployment but then the document should say so. I think it should rather be experimental.

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

The IANA Functions Operator has reviewed draft-ietf-sipbrandy-osrtp-09, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

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

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2019-05-16):

From: The IESG
To: IETF-Announce
CC: sipbrandy@ietf.org, sipbrandy-chairs@ietf.org, draft-ietf-sipbrandy-osrtp@ietf.org, gonzalo.camarillo@ericsson.com, Gonzalo Camarillo , alexey.melnikov@isode.com
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (An Opportunistic Approach for Secure Real-time Transport Protocol (OSRTP)) to Informational RFC


The IESG has received a request from the SIP Best-practice Recommendations
Against Network Dangers to privacY WG (sipbrandy) to consider the following
document: - 'An Opportunistic Approach for Secure Real-time Transport Protocol
  (OSRTP)'
  as Informational RFC

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 2019-05-16. 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


  Opportunistic Secure Real-time Transport Protocol (OSRTP) is an
  implementation of the Opportunistic Security mechanism, as defined in
  RFC 7435, applied to Real-time Transport Protocol (RTP).  OSRTP
  allows encrypted media to be used in environments where support for
  encryption is not known in advance, and not required.  OSRTP does not
  require SDP extensions or features and is fully backwards compatible
  with existing implementations using encrypted and authenticated media
  and implementations that do not encrypt or authenticate media
  packets.  OSRTP is not specific to any key management technique for
  SRTP.  OSRTP is a transitional approach useful for migrating existing
  deployments of real-time communications to a fully encrypted and
  authenticated state.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-sipbrandy-osrtp/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-sipbrandy-osrtp/ballot/


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

This is my AD Evaluation of draft-ietf-sipbrandy-osrtp-07.

Thank you for a readable and easy to understand document.There is one comment I would like to resolve prior to IETF LC. The others can be resolved along with any last call feedback.

*** Please resolve prior to IETF LC ***

§4: The relaxation of authentication requirements for DTLS-SRTP and SDES could use some elaboration on why this acceptable. I _think_ the answer is that, since OSRTP doesn’t guaranty authentication, there’s no need for such a guaranty from the signaling channel. Is that correct?

OTOH, §1 says "third mode for security between "cleartext” and "comprehensive protection" that allows encryption and authentication to be used if supported…”. That suggests that that authentication is sometimes provided. Is there a distinction between the authenticated case and unauthenticated case that should be mentioned somewhere? (For example, is there a need to indicate the distinction to the user?)

*** Other Substantive Comments ***

§2: Please use the new boilerplate from RFC 8174.

§3.1: Please clarify that that the offer can contain more than one key management attribute. This is mentioned in §3.1, but not actually in the section on generating the offer.

*** Editorial Comments ***

§3: "As discussed in [RFC7435], this is
the "comprehensive protection" for media mode.”
s/this/that

§3.4: "meaning that the decision to
create an OSRTP type offer or something else should not be influenced”
That’s referring to the decision to create a _new_ offer, right? Not the original offer?

PROTO Writeup for draft-ietf-sipbrandy-osrtp-07

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

    Informational, as indicated in the title page 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:

    Opportunistic Secure Real-time Transport Protocol (OSRTP) is an
    implementation of the Opportunistic Security mechanism, as defined
    in RFC 7435, applied to Real-time Transport Protocol (RTP).  OSRTP
    allows encrypted media to be used in environments where support
    for encryption is not known in advance, and not required.  OSRTP
    does not require SDP extensions or features and is fully backwards
    compatible with existing implementations using encrypted and
    authenticated media and implementations that do not encrypt or
    authenticate media packets.  OSRTP is not specific to any key
    management technique for SRTP.  OSRTP is a transitional approach
    useful for migrating existing deployments of real-time
    communications to a fully encrypted and authenticated state.

Working Group Summary:

    There is consensus in the WG around this document.

Document Quality:

  Section 6 of the document (to be removed before its publication as
  an RFC) discusses the implementation status of the techniques
  described in the document.

Personnel:

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

    Gonzalo Camarillo is the Document Shepherd. Ben Campbell 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.

    The document shepherd reviewed revision 05 of this document, which
    was ready for publication.

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

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

    No concerns.

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

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

    The whole WG understands the document and agree with
    it. Nevertheless, the number of active participants in the
    SIPBRANDY WG is limited at this point.

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

(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 contains no relevant nits.   


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

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

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

    No.

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

    The IANA Considerations Section is complete and consistent.

(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 new registries are defined.

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

    No such checks were needed.

PROTO Writeup for draft-ietf-sipbrandy-osrtp-07

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

    Informational, as indicated in the title page 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:

    Opportunistic Secure Real-time Transport Protocol (OSRTP) is an
    implementation of the Opportunistic Security mechanism, as defined
    in RFC 7435, applied to Real-time Transport Protocol (RTP).  OSRTP
    allows encrypted media to be used in environments where support
    for encryption is not known in advance, and not required.  OSRTP
    does not require SDP extensions or features and is fully backwards
    compatible with existing implementations using encrypted and
    authenticated media and implementations that do not encrypt or
    authenticate media packets.  OSRTP is not specific to any key
    management technique for SRTP.  OSRTP is a transitional approach
    useful for migrating existing deployments of real-time
    communications to a fully encrypted and authenticated state.

Working Group Summary:

    There is consensus in the WG around this document.

Document Quality:

  Section 6 of the document (to be removed before its publication as
  an RFC) discusses the implementation status of the techniques
  described in the document.

Personnel:

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

    Gonzalo Camarillo is the Document Shepherd. Ben Campbell 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.

    The document shepherd reviewed revision 05 of this document, which
    was ready for publication.

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

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

    No concerns.

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

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

    The whole WG understands the document and agree with
    it. Nevertheless, the number of active participants in the
    SIPBRANDY WG is limited at this point.

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

(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 contains no relevant nits.   


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

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

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

    No.

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

    The IANA Considerations Section is complete and consistent.

(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 new registries are defined.

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

    No such checks were needed.