A Mechanism to Measure the Routing Metrics along a Point-to-Point Route in a Low-Power and Lossy Network
draft-ietf-roll-p2p-measurement-10

[Ballot comment]

Thanks for addressing my discuss. On the basis that this is an
experimental-track specification and you're depending on the
security from 6550, your changes are enough to clear my
discuss. I'd be really interested in knowing how this goes,
when people implement/deploy, given that you need all
routers to share the same key.

Two other comments,

- its not clear to me if there are cases where a router will
pass on a "secure MO" without changing the message,
but where the router doesn't have the key required. It'd
be good to say if a router needs to drop the message in
that case or not.

- I'm also unclear about that the starting point has to
do if a "secure MO" it sent out gets dropped and the
starting point never hears anything back.

Both of the above may be clear in the document already
(apologies if so) but I didn't immediately see what's
supposed to happen.

[Ballot discuss]

I just don't get how a secure MO can work - do you need
every intermediary to share keys so they can all modify
the message? Please explain. (I didn't find any
description of how a "secure MO" is generated or
processed at all so this has to be a bit of an
open-ended discuss for now sorry.)

[Ballot comment]
3.1, Accumulate Route:

      Route accumulation is allowed (i.e., this flag MAY be set to one)
      inside a Measurement Request only if it travels along a Hop-by-hop
      Route represented by a local RPLInstanceID (i.e., H = 1,
      RPLInstanceID has a local value).

I think you buried the lede here. I suggest instead:

      Route accumulation MUST NOT be used (i.e., this flag set to one)
      inside a Measurement Request unless it travels along a Hop-by-hop
      Route represented by a local RPLInstanceID (i.e., H = 1,
      RPLInstanceID has a local value).

That MAY could cause a reader to miss the important point that this is a requirement, even though this is followed with "In other cases, this flag MUST be set to zero".

[Ballot comment]
Very well-written and easy to understand document.  Thank you.

I have only a few minor comments for your consideration.

1. In this text:

  Such a route could be a Source
  Route [I-D.ietf-roll-p2p-rpl] or a Hop-by-hop Route
  [I-D.ietf-roll-p2p-rpl] established using RPL [RFC6550] or P2P-RPL
  [I-D.ietf-roll-p2p-rpl]

I found the first two citations of [I-D.ietf-roll-p2p-rpl] a little
confusing.  The use of terminology from [I-D.ietf-roll-p2p-rpl] was
already mentioned; no need to cite the sources of those terms here.

2. Are there any restrictions on the addresses (link-local, global
scope, etc.) in the address list, used either for source-routing or
accumulating a route?

4. Are there rules about what address a node should insert in the
address list - for example, link-local if possible, MUST match End
Point address prefix as specified by Compr?

5. Is the RPLInstanceID value 0b10000000 now reserved in some way?
Section 4.4 call for the RPLInstanceID to be set to 0b10000000, but I
don't see any requirement to check that value in a received MO.

[Ballot comment]
  The Gen-ART Review by Pete McCann on 5-Feb-2013 raises one concern
  about clarity.  In Section 5, it says:
  >
  > An Intermediate Point MUST discard the packet with no further
  > processing if the received MO is not a Measurement Request (i.e.,
  > T = 0).
  >
  The Intermediate Points are the routers on the route that are being
  measured, excluding the Start Point and the End Point.  Section 6.1
  identifies situations where the Measurement Reply _may_ travel back
  to the Start Point using the reverse of the measured route. So, it is
  possible that the Measurement Reply travels along the reverse of the
  measured path and, in this case, the Measurement Reply does pass
  through all the Intermediate Points. However, the End Point may decide
  to send the Measurement Reply along a different path than the measured
  one. In that case, the Measurement Reply may not pass through the
  Intermediate Points.

  It would be helpful to share this information with the reader in
  Section 5, instead of waiting for Section 6.1.

[Ballot discuss]
Quite possible some of these are me not getting so I thought I'd get 'em in early:

1) There's a couple of times that the S/MO gets dropped with no further action (e.g., Intermediate Point drops it when Compr field inside the received message is more than what the router considers the length of the common prefix used in IPv6 addresses in the LLN to be) and a couple when an ICMPv6 Destination Unreachable is sent.  I'm curious why s7 doesn't discuss the former.  For example, should the Start Point time out and retry at some point?  Or, because it's not guaranteed devilry the Start Point just knows to not wait?

2) s5.1: In the process of a request by an Intermediate Point, the I flag is is set to zero if the Intermediate Point determines the next hop isn't the End Point.  Wouldn't the Intermediate Point want to leave that flag alone in case the next Intermediate Point knows the aggregated info?

3) s5/6: This might be a simple oversight, but should the 1st paragraph (about not processing an MO based on local policy) be copied from s5 to s6?  In the security considerations, it seems to imply any router cold drop the packets based on local-policy.

4) s8: I'm not following along in the last paragraph.  You say disclosing information found in the MO could harm the LLN so you're allowing routers to drop the requests.  So you're expecting rogue routers to not look in the MO and drop them so they don't get the information?  Or are you saying that routers don't have to process these messages if they think somewhere along the line the information in the MO might be disclosed?

6) s8: As best I can tell, there's no MTI security mechanism (note this is different than must use).  To alleviate that might I suggest:

An LLN deployment MUST support the Secure MO, described in
Section 3.2 messages, to invoke RPL-provided security mechanisms and
prevent misuse of the measurement mechanism by unauthorized nodes.

[Ballot comment]
1) abstract: I'm probably nit picking her but the way I read the abstract is that the mechanism described in the draft will only work in low power and lossy networks.  The bit about the low power and lossy networks about RPL - maybe just drop "in a low power and lossy network".  And, this more closely aligns with s1.

2) s1: please expand ETX.

3) s1: Three things about the last paragraph I found interesting: a) If it's aimed at experimental is it really operational experience? b) I'm not sure referring to a WG in a draft makes sense because the name could change, it could get closed and never come back, etc. c) I would have thought the feedback would have included interoperability issues.  You could just as well say:

The hope is that experiments with P2P-RPL and this document will
result in feedback on the utility and benefits of this document
and it will be revised and progressed on the Standards Track based
on this feedback.

4) s1.1: Instead of redefining the same term could you maybe just call them:
  Forward P2P route direction and Backward P2P route direction?

5) s3.1: Expand DODAGID.

6) Figure 1: Shouldn't the Start Point Address, End Point Address, and Address indicate that they are variable in length?  I guess maybe adding dots in Start and End Point and Address to match Address might work:

  .                      Start Point Address                    .
  .                                                              .
  |                                                              |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                                                              |
  .                      End Point Address                      .
  .                                                              .

7) s3.1: Just checking here, the Start Point knows how to set in Compr, H, and A because it already knows the route - right?

8) s3.1: /Section 4 describes how does a Start Point
        /Section 4 describes how a Start Point

9) s3.2: Implementing SMO is optional, but if you're going to do it then you've got implement RFC 6550 - therefore RFC 6550 needs to be a normative reference.

10) s4: Seems odd that the Start Point would make the request and then discard it.  Could you use "MUST NOT send" instead or flip it to:

  The Start Point MUST also construct the Measurement
  Request with:

  o  a next hop address that is a unicast address;

  o  a next hop address that is on-link;

  o  a next hop address that is in the same RPL routing domain as the Start
      Point.

11) s4: Probably worth pointing out that unless otherwise noted using "MO" refers to both an MO and the contents of a Secure MO.

12) s5: Just so I'm following along:

For the hop-by-hop accumulations, what will the Start Point do if they sends an S/MO and doesn't get an S/MO back because the S/MO has been discarded by an Intermediate Point because the Address vector was too small?  Is the "more than" referring to the Start Point compressing the value more than it should?

13) s5.1/5.2/5.3: Need a normative reference to RFC 4443 for the ICMPv6 Destination Unreachable.

14) s8: Hopefully one malicious request won't break it:

  r/Such Measurement Requests may
  /If sufficient Measurement Requests are sent, then it may

[Ballot comment]
This is a nice, clear document, which was easy to review.  I have just two very minor points, of the extreme-NON-blocking variety:

-- Section 1 --
  Note that it is important that the routing constraints
  are not overly strict; otherwise the P2P-RPL route discovery may fail
  even though a route, much better than the one currently being used,
  exists.

The commas setting off that last phrase make it non-restrictive (it could be removed without changing the meaning of the sentence), and that's not what you want.  So (adding a change to subjunctive mood along the way)...

NEW1
  Note that it is important that the routing constraints
  not be overly strict; otherwise, the P2P-RPL route discovery may fail
  even though a route much better than the one currently being used
  exists.

...or...

NEW2
  Note that it is important that the routing constraints
  not be overly strict; otherwise, the P2P-RPL route discovery may fail
  even though a route exists that is much better than the one currently
  being used.

-- Section 6.1 --
  The remaining fields inside a Measurement Reply may have
  any value and MUST be ignored on reception at the Start Point.  The
  received Measurement Request MAY trivially be converted into a
  Measurement Reply by setting the Type (T) flag to zero.

It's really a small point, but this doesn't feel like the right use of 2119 "MAY", because it simply follows from the rest of the paragraph, and the protocol only cares about what the Measurement Reply looks like, not how you went about creating it.  I suggest this slight change:

NEW
  The remaining fields inside a Measurement Reply may have
  any value and MUST be ignored on reception at the Start Point; the
  received Measurement Request can, therefore, trivially be converted
  into a Measurement Reply by setting the Type (T) flag to zero.
END

IANA has reviewed draft-ietf-roll-p2p-measurement-07 and has the following comments:

IANA understands that, upon approval of this document, there are two actions which IANA must complete.

First, in the RPL Control Codes subregistry of the Routing Protocol for Low Power and Lossy Networks (RPL) subregistry located at:

http://www.iana.org/assignments/rpl/rpl.xml#control-codes

a new control code will be registered as follows:

Code: [ TBD at time of registration ]
Description: Measurement Object
Reverence: [ RFC-to-be ]

IANA notes that this Code should be allocated as assigned from the range 0x00-0x7F to indicate a message without security enabled.

Second, also in the RPL Control Codes subregistry of the Routing Protocol for Low Power and Lossy Networks (RPL) subregistry located at:

http://www.iana.org/assignments/rpl/rpl.xml#control-codes

a new control code will be registered as follows:

Code: [ TBD at time of registration ]
Description: Secure Measurement Object
Reverence: [ RFC-to-be ]

IANA notes that this Code should be assigned from the range 0x80-0xFF to indicate a message with security enabled.

IANA understands that these two actions are the only ones required 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.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (A Mechanism to Measure the Routing Metrics along a Point-to-point Route in a Low Power and Lossy Network) to Experimental RFC


The IESG has received a request from the Routing Over Low power and Lossy
networks WG (roll) to consider the following document:
- 'A Mechanism to Measure the Routing Metrics along a Point-to-point
  Route in a Low Power and Lossy Network'
  as Experimental 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 2013-01-21. 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 specifies a mechanism that enables an RPL router to
  measure the aggregated values of given routing metrics along an
  existing route towards another RPL router in a low power and lossy
  network, thereby allowing the router to decide if it wants to
  initiate the discovery of a better route.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-roll-p2p-measurement/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-roll-p2p-measurement/ballot/


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

Hi,

I have done my usual AD review of your document as part of processing
the publication request. This review should be considered alongside
my review of draft-ietf-roll-p2p-rpl as the documents are closely
linked.

I have a number of questions and minor issues that I would like to
resolve before advancing the documents.

As usual, all of my comments are up for discussion, but I think that a
new revision will be needed, so I have moved the document into "Revised
I-D Needed" state in the data tracker and will wait for your emails
and/or a new revision.

Many thanks for your work,
Adrian


---

As with draft-ietf-roll-p2p-rpl, I would like some discussion in the
Introduction about why this Experimental and what you expect to
discover. I think the text is easier for this document...

  This document provides a mechanism that can be used to determine
  whether and how to establish a new point-to-point route in an LLN.
  This utility of the mechanism described in this document is,
  therefore, dependent on the existence of a protocol mechanism for
  establishing P2P routes. [I-D.ietf-roll-p2p-rpl] is targeted at
  publication as an Experimental RFC for reasons described in that
  document. It makes sense, therefore, for this document also to be
  targeted as Experimental.

  As experience is gained using the mechanisms described in
  [I-D.ietf-roll-p2p-rpl] it is hoped that the mechanisms described in
  this document will also be used, and feedback will be provided to the
  ROLL working group on the utility and benefits of this document.

---

I think that "quality" is the wrong word. "Quality" is usually
associated with measures like packet loss, delay, and jitter. I don't
think you are measuring those things, and while I understand why you
say "quality of a route", I think you need some other phrase.

I think this more like...

  A Mechanism to Record the end-to-end Metrics of a Point-to-point
            Route in a Low Power and Lossy Network

In the Introduction, you have some nice words...

  to measure
  the aggregated values of the routing metrics along the existing
  route

---

Abstract

I'm confused :-)

The document title is very specific to P2P routes. But the Abstract
(deliberately?) does not mention P2P. Section 1 seems to imply that I
could run the mechanisms on any route from origin to target to see if it
is good enough - and that would include routes created using normal RPL.
But section 2 explicitly constrains the mechanism to P2P routes.

Furthermore, the redefined terminology in 1.1 (see below for my
objection to that!) seem to suggest measuring from an arbitrary origin
to an arbitrary target regardless of whether a P2P route exists.

Can you:
- unconfuse me
- make sure that the abstract and introduction explain the real
  situation
- make sure the document title is accurate
- make sure that the document is consistent
- be careful with terminology (just because you run the mechanism from
  A to B in a point-to-point sort of way, doesn't mean that there is a
  P2P route from A to B)

---

1.1                   

Did you really need to redefine these terms instead of use new terms for
new concepts? Given how close the two documents are, it's a shame to
confuse things.

---

3.1

I was going to say...

  Seems like the H flag is not needed since leaving it clear is
  semantically equivalent to setting RPLInstanceID=0b10000000

  Not very important, but you increase the chances of a malformed
  message, and you use your last bit that could be reserved for
  future use.

...but then I read the text lower down about how a transit router
can change the H flag under special circumstances. Now I am confused
because if the H flag setting is changed, surely the rule governing
the RPLInstanceID is broken.

---

3.1

Some of the flag settings that have no meaning dependent on other
flag settings are described as "MUST be set to zero" which is fine.
But should you also say they should be ignored?

---

3.1

I found the description of what goes in the Metric Container Options
inadequate. There should at least be a forward pointer to some section
that describes how this piece of the MO object is constructed, but some
text would help as well.

---

Section 4

  The Origin MUST discard the MO message if:

That reads a bit odd. Didn't the Origin just build the message? Why
would it build a message and then discard it? Why not just not build a
bad message?

---

Section 5

  An Intermediate Router MUST discard the packet with no further
  processing if the received MO is not a Measurement Request.

For clarity and consistency with other paragraphs, can you add...

  i.e., if the T flag is not set to one.

---

Section 7

  The Origin MUST discard the packet with no further processing ...
  ... if the Origin has no
  recollection of sending a Measurement Request with the sequence
  number listed in the received MO.

Trying to decide why that is a "MUST".
I guess there are some security/bug considerations.
But are you unduly limiting the Origin implementation to be required to
keep track of the MOs that it sends?

---

Section 7

  The Origin MUST examine the routing metric objects inside the Metric
  Container options to evaluate the quality of the measured P2P route.
  If a routing metric object contains local metric values recorded by
  routers on the route, the Origin MUST aggregate these local values
  into an end-to-end value as per the aggregation rules for the metric.

That is going too far in the use of "MUST". The Origin can do anything
it likes with the Measurement Reply including discard it, hash it and
use it as a random number, or process it according to policy! I think
what you need is...

  The Origin can use the routing metric objects inside the Metric
  Container to evaluate the metrics for the measured P2P route. If a
  routing metric object contains local metric values recorded by
  routers on the route, the Origin can make use of these local values
  by aggregating them into an end-to-end metric according to the
  aggregation rules for the specific metric. An Origin is then free to
  interpret the metrics for the route according to its local policy.

---

Section 8

Question. Can I use this mechanism to find out stuff about the network
that should/would otherwise be private? And could I, as an outside node
do that?

For example, if I sit next to the network and ping every possible P2P
route, can I find out which nodes are almost out of battery, and which
nodes are key nodes in the topology? Knowing this would help me attack
the network. What are the protections?


---

11.2
You have used [I-D.ietf-roll-p2p-rpl] as a normative reference (at
least for the terminology).

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

The intended track of the RFC is Experimental, and the RFC type is indicated in
the title page header.

The rationale for proceeding with the Experimental track was that this document
and it companion ID (draft-ietf-roll-p2p-rpl-13)?are using the RPL protocol
specified in RFC6550 in a slightly different mode as originally specified by the
RFC.

Thus we think that it was reasonable to first get more experience on actual
deployment before moving to the Standard?track. There was no discontent on that
decision.

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

Point to point (P2P) communication between arbitrary routers in a Low power and
Lossy Network (LLN) is a key requirement for many applications
[RFC5826][RFC5867].

RPL [RFC6550], the IPv6 Routing Protocol for LLNs, constrains the LLN topology
to a Directed Acyclic Graph (DAG) built to optimize the routing costs to reach
the DAG's root. The P2P routing functionality, available under RPL, has the
following key limitations:

  o  The P2P routes are restricted to use the DAG links only.  Such P2P
      routes may potentially be suboptimal and may lead to traffic
      congestion near the DAG root.

  o  RPL is a proactive routing protocol and hence requires all P2P
      routes to be established ahead of the time they are used.  Many
      LLN applications require the ability to establish P2P routes "on
      demand".

  To ameliorate situations, where the core RPL's P2P routing
  functionality does not meet the application requirements,
  [I-D.ietf-roll-p2p-rpl] describes P2P-RPL, an extension to core RPL.
  P2P-RPL provides a reactive mechanism to discover P2P routes that
  meet the specified routing constraints [RFC6551].  In some cases, the
  application requirements or the LLN's topological features allow a
  router to infer these routing constraints implicitly.  For example,
  the application may require the end-to-end loss rate and/or latency
  along the route to be below certain thresholds or the LLN topology
  may be such that a router can safely assume its destination to be
  less than a certain number of hops away from itself.

  When the existing routes are deemed unsatisfactory but the router
  does not implicitly know the routing constraints to be used in P2P-
  RPL route discovery, it may be necessary for the router to measure
  the aggregated values of the routing metrics along the existing
  route.  This knowledge will allow the router to frame reasonable
  routing constraints to discover a better route using P2P-RPL.  For
  example, if the router determines the aggregate ETX [RFC6551] along
  an existing route to be "x", it can use "ETX < x*y", where y is a
  certain fraction, as the routing constraint for use in P2P-RPL route
  discovery.  Note that it is important that the routing constraints
  are not overly strict; otherwise the P2P-RPL route discovery may fail
  even though a route, much better than the one currently being used,
  exists.

  This document specifies a mechanism that enables an RPL router to
  measure the aggregated values of the routing metrics along an
  existing route to another RPL router in an LLN, thereby allowing the
  router to decide if it wants to discover a better route using P2P-RPL
  and determine the routing constraints to be used for this purpose.

  The mechanism described in this document can be used by an Origin in
  an LLN to measure the aggregated values of some routing metrics along
  a P2P route to a Target within the LLN.  The route is measured in the
  direction from the Origin to the Target.  Such a route could be a
  source route or a hop-by-hop route established using RPL [RFC6550] or
  P2P-RPL [I-D.ietf-roll-p2p-rpl].  The Origin decides what metrics to
  measure and sends a Measurement Request message, carrying the desired
  routing metric objects, along the route.  On receiving a Measurement
  Request, an Intermediate Router updates the routing metric values
  inside the message and forwards it to the next hop on the route.
  Thus, the Measurement Request accumulates the values of the routing
  metrics for the complete route as it travels towards the Target.
  Upon receiving the Measurement Request, the Target unicasts a
  Measurement Reply message, carrying the accumulated values of the
  routing metrics, back to the Origin.  Optionally, the Origin may
  allow an Intermediate Router to generate the Measurement Reply if it
  already knows the relevant routing metric values along rest of the
  route.

Working Group Summary:

No discontent. Once again, few comments, request for clarifications that have
all been addressed by in this revision.

Document Quality:

Yes there are several known implementations of this specification, with interop
testing:

An interoperability was carried out last month with INRIA's implementation
against Sigma Design's?
implementation. The report can be found:
http://hal.inria.fr/docs/00/66/16/29/PDF/RR-7864.pdf

Experiments with P2P-RPL have also taken place on the Senslab testbed gathering
boards based?
on MSP430 and 802.15.4 at 2.4GHz:
http://hal.archives-ouvertes.fr/docs/00/65/16/03/PDF/SOFTCOM-2011.pdf

Personnel:

The Document Shepherd is JP Vasseur (ROLL co-chair) and the responsible Area
Director is Adrian Farrel (AD Routing Area)

(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 is sound, has received a very good level of attention and reviews
including from the Shepherd prior to issuing the publication request, and is
ready for publication as experimental track.

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

No Concern.

The I-D has been discussed in great detail by a number of key members of the
Working group. Number of comments have been made on the mailing list during two
WG Last Calls and have all been addressed in this revision. Note that several
tickets have been opened and have been successfully closed.

(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 need for broader review.

(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 particular concern. Some questions were raised has to whether using a
pro-active protocol in a "reactive" way was scalable; thus the choice to advance
the document along the experimental track.

(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. I have personally checked with all co-authors of the document.

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

Good consensus.

(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 threats. No discontent.

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

Checks have been made. No Errors.

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

Not applicable.

(13) Have all references within this document been identified as either
normative or informative?

References split has been done.

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

The only normative reference is to an RFC.

(15) Are there downward normative 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 action is properly documented.

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

The IANA section specifies no new registries.

(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 other automated checks performed.