IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Routing Header
draft-ietf-roll-routing-dispatch-05

[Ballot comment]
I enjoyed the introduction (*) and the management section.

(*) as the writeup says: generous (5 page) introduction appropriate for a reader who is unfamiliar with the why).

[Ballot comment]
In figure 2, I'm a bit confused on what the third-from-the-left vertical line represents - is it also IPv6 in IPv6 plus RPL SRH, or something else?

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

The IANA Services Operator has completed its review of draft-ietf-roll-routing-dispatch-01.txt. If any part of this review is inaccurate, please let us know.

We have a question about some of the actions requested in the IANA Considerations section of this document.

Upon approval of this document, we understand that there are three registry actions to complete.

First, in the Dispatch Type Field subregistry of the IPv6 Low Power Personal Area Network Parameters registry, two new values are to be registered as follows:

Bit Pattern: 101xxxxx
Header Type: Elective 6LoWPAN Routing Headers
Reference: [ RFC-to-be ]

Bit Pattern: 100xxxxx
Header Type: Critical 6LoWPAN Routing Headers
Reference: [ RFC-to-be ]

As this is an Expert Review (see RFC 5226) registry, we will initiate the required review via a separate request. Approval by the expert is required for registration. 

Second, a new registry is to be created called the Critical 6LoWPAN Routing Header Type registry. The registry will contain 32 possible values from 0 to 31. The new registry will be managed using RFC Required as defined by RFC 5226.

QUESTION -> Where should this new registry be located? Is it a new registry on the List of all IANA maintained protocol parameter registries or is it a subregistry of an existing registry? If it is a subregistry of an existing registry, in which registry will it be contained?

We understand that there are to be initial registrations in the new registry as follows:

Header Type: Description: Reference:
0 SRH-6LoRH [ RFC-to-be ]
1 SRH-6LoRH [ RFC-to-be ]
2 SRH-6LoRH [ RFC-to-be ]
3 SRH-6LoRH [ RFC-to-be ]
4 SRH-6LoRH [ RFC-to-be ]
5 RPI-6LoRH [ RFC-to-be ]
6-31. Unassigned

Third, a new registry is to be created called the Elective 6LoWPAN Routing Header Type registry. The registry will contain 32 possible values from 0 to 31. The new registry will be managed using RFC Required as defined by RFC 5226.

QUESTION -> Where should this new registry be located? Is it a new registry on the List of all IANA maintained protocol parameter registries or is it a subregistry of an existing registry? If it is a subregistry of an existing registry, in which registry will it be contained?

We understand that there are to be initial registrations in the new registry as follows:

Header Type: Description: Reference:
0-5 Unassigned
6 IP-in-IP-6LORH [ RFC-to-be ]
7-31. Unassigned

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

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

Thank you,

Sabrina Tanamal
IANA Services Specialist
PTI

The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: roll-chairs@ietf.org, mcr+ietf@sandelman.ca, roll@ietf.org, draft-ietf-roll-routing-dispatch@ietf.org, aretana@cisco.com, "Michael Richardson"
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (6LoWPAN Routing Header) to Proposed Standard


The IESG has received a request from the Routing Over Low power and Lossy
networks WG (roll) to consider the following document:
- '6LoWPAN Routing Header'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2016-10-19. 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 specification introduces a new 6LoWPAN dispatch type for use in
  6LoWPAN Route-Over topologies, that initially covers the needs of RPL
  (RFC6550) data packets compression.  Using this dispatch type, this
  specification defines a method to compress RPL Option (RFC6553)
  information and Routing Header type 3 (RFC6554), an efficient IP-in-
  IP technique and is extensible for more applications.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-roll-routing-dispatch/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-roll-routing-dispatch/ballot/


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

=== AD Review of draft-ietf-roll-routing-dispatch-00 ===

The main concern I have about progressing this document is that it requests IANA actions on registries that don't exist (yet) because  draft-ietf-6lo-paging-dispatch hasn't been processed.  This is obviously not a concern with the document itself, but I will hold it until draft-ietf-6lo-paging-dispatch moves:  I'll issue the IETF Last Call and start with the rest of the process in parallel.

In the meantime, I have some comments that I would like to see addressed before IETF Last Call (see below).

Thanks!

Alvaro.


[] Major:

M1. The IANA Considerations section requests the creation of a "registry for the 6LoWPAN Routing Header Type", but there is no registration policy specified for the space that is not assigned.  Please indicate one.  [rfc5226]


M2. Section 5.1. (Encoding) says that "Routers that need to forward a packet with a SRH-6LoRH are expected to be RPL routers and are expected to support this specification." [There is similar text in Section 6.3. (The Overall RPI-6LoRH encoding).]  How do you know if the next RPL router supports this specification?  BTW, by "support this specification" I'm guessing that the authors mean at least the SRH (RPI from 6.3).  Section 4.2. (Critical Format) has a note about this situation being a "critical administrative error" -- is this text what you want to point to when talking about supporting this specification?  It would be ideal if a section on Management Considerations talked about this specific need, or that at least the requirement was more prominent than a Note in a sub-section (with the proper pointers of course).


M3. Also in 5.1: "If a non-RPL router receives a packet with a SRH-6LoRH, this means that there was a routing error and the packet should be dropped so the Type cannot be ignored."  [There is similar text in Section 6.3. (The Overall RPI-6LoRH encoding), but ending in the stronger "…the Type field MUST NOT be ignored."]  The last part of the sentence is confusing to me; I'm not sure if you're saying that the non-RPL router should not ignore the Type and (as a result) drop the packet, OR, if you're saying that the RPL router should not ignore the Type to avoid errors.  In both cases, are you trying to indicate what the behavior of the non-RPL router should be?  Or maybe just indicating that because it won't know what it is looking at it would then drop the packet.  Or probably that the RPL router should make sure to treat the Type correctly.  All this is probably related to the text in Section 4 that says that "Critical (6LoRHC) that may not be ignored". Please clarify and don't rely on the reader guessing.  [After reading some more, I think I figured what you mean by not ignoring the Type — you mean this type of 6LoRH and not the Type field..]


M4. Section 6.3. (The Overall RPI-6LoRH encoding) says that "Since the I flag is not set, the TSE field does not need to be a length expressed in bytes.  In that case the field is fully reused for control bits that encode the O, R and F flags from the RPI, as well as the I and K flags that indicate the compression format."  You are obviously not specifying a recursive check (I hope!), but I can't figure out what the first mention of the "I flag" is -- the only "I flag" I can see in this document is the one in the TSE field, I checked other RFCs, but nothing.


M5. Section 7. (The IP-in-IP 6LoRH Header)  says that this "field is not critical for routing so the Type can be ignored".  When?  Why?  Under what conditions?  Or should it only be "skipped if not understood" (from Section 4)? 


M6. Security Considerations.  I think that the fact that the SRH hops are removed as the packets go through the network introduces a new type of security threat related to attacks from within the RPL domain, and that it should be explicitly mentioned.  RFC6554 talks about mitigating attacks from within the RPL domain by checking for loops, but that is no longer possible when using this specification.  Is there any mitigation possible in this case?


M7. References.  I think both the references to rfc7102 and rfc7228 should be made Informative to avoid the downref.



[]Minor:

p1. Is it "I flag" or "I bit"?  Please be consistent.

p2. It would be very nice if you put an example (with real addresses) related to Section 4.3.1. (Coalescence); it may just be me, but the coalescence process would make (more) sense if I saw it in action.

p3. Section 5.1. (Encoding) defines the Size field two different ways: as the "number of compressed addresses" (in Figure 6), and as the "number of hops minus 1" (after Figure 7).    It looks to me like the rest of the text uses "hops – 1", so taking the comment inside Figure 6 should fix this.

p4. 5.1: "One or more 6LoRH header(s) MAY be placed in a 6LoWPAN packet."  While that is true, the text is inside the section taking about the SRH-6LoRH header — was the intent to say that one or more SRH-6LoRH headers MAY…"?  If not, then this sentence should be moved to where it makes more sense.

p5. In Section 5.2.3. (Inner LOWPAN_IPHC Compression), please be consistent with the terminology in RFC6282:  this section uses S/DAC and S/AM instead of DAC and SAM…unless you're referring to something else…

p6. The 3rd step in Section 5.5. (Popping Headers) seems wrong to me (but I may also be lost): "…if there is a next SRH-6LoRH of a Type with a larger or equal value…then the SRH-6LoRH is removed."  This means that the next SRH-6LoRH can only use a smaller Type as the value.  What happens if multiple consecutive headers are used?  Is the originator stuck with non-optimal compression?

p7. There are a couple of places in the document (5.2.2 and 5.6) where a normative statement is preceded by a condition related to strict source routing.  For example, in 5.6: "If strict source routing is enforced and thus router…then this router MUST drop the packet."  AFAIK (my interpretation of RFC6554), strict source routing is the only type supported in a RPL network.  If so, then is it really necessary to call it out?  There is nothing wrong with the statements, but I think it may cause confusion to the reader (who may try and fid out what happens in the loose case).    [BTW, s/thus/this]

p8. I don't know how to interpret the note in Section 6. (The RPL Packet Information 6LoRH): "Note: A typical packet in RPL non-storing mode going down the RPL graph requires an IP-in-IP encapsulation of the SRH, whereas the RPI is usually (and quite illegally) omitted, unless it is important to indicate the RPLInstanceID.  To match this structure, an optimized IP-in-IP 6LoRH header is defined in Section 7."  It sounds that the optimized header defined in Section 7 is there to match the fact that the RPI is not included (illegally!).  ??

p9. Section 7. (The IP-in-IP 6LoRH Header) says that "the TSE field contains the Length in bytes".  However, the format in Section 4.1 doesn't include a TSE (just the Length).

p10. Also in Section 7: "If the Length of an IP-in-IP-6LoRH header is greater than 1…a Size of 3…"  s/Size/Length

p11. IANA Considerations: Why aren't there separate registries for 6LoRHE and 6LoRHC types?  Note that the definitions in 4.1 and 4.2 talk about the "type of 6LoRHE/6LoRHC" (not just a generic 6LoRH).  In the end, it's up to you how the space is defined — it just seems simpler to separate them.
p11.1. Related question: what happens if (for example) a 6LoRHC is received with type 6 (IP-in-IP-6LoRH)?  Should the packet be discarded?  The Type may be locally supported, but it should not have been Critical.
p11.2. Along the same lines…  If a 6LoRHE is received with type 4 (for example), should the node ignore, skip and forward, or discard?  In this case the node probably already knows that type 4 should be used by 6LoRHC, so there doesn't seem to be a point in forwarding.



[] Nits:

n1. In the Introduction, fix the mention of 6554 to actually say "RFC 6554".

n2. I can't really parse the last sentence in the 4th paragraph in the Introduction: "When to use RFC 6553…"

n3. No text is referencing Figure 1 or 2.  In some cases, such as (no text referencing) Figure 9, it seems ok since the description of the figure immediately follows, but in others (like 1 and 2) the figures just seem to be randomly placed.

n4. This reference seems to not be formatted correctly: "[IPv6 Routing Header for Source Routes with RPL] (#RFC6554)".

n5. 3.2.1.  There are a couple of parenthesis missing in the first paragraph.  s/…(i.e., once a Page 1…subsequent Paging Dispatch has been parsed, the parsing of the packet…Bit Pattern Section 3.1 is found./…(i.e., once a Page 1…subsequent Paging Dispatch has been parsed), the parsing of the packet…Bit Pattern (Section 3.1) is found.

n5.1.  There are a couple of other references to Sections that need parenthesis…

n6. s/usesthe/uses the

n7. s/participates to/participates in

n8. From 4.3.2: "…as described in more details below".  Please put in a reference.

n9. Just to be clear, Section 5.2.1. (Uncompressed SRH Operation) summarized the operation that is specified in RFC6554, right?  If so, please explicitly say so.

n10. In 5.4, "…IPv6 packet [RFC2460]."  This reference is superfluous.

n11. 5.5  s/SRH-6LoRH one of its own addresses/SRH-6LoRH is one of its own addresses

n12.  SRH-6LoRH vs SRH-6LoRH header  The 2 terms are used throughout the document (21 with the word "header" and 57 without).  I know that "header" is already part of the RH part, so why say "header" again?  Unless it is to point out the specific SRH header of the 6LoRH (as in Section 5).  However, in some places both forms seem to be talking about the same thing, for example, in 4.3.1: "…indicated by the Type of the SRH-6LoRH header…the particular case of a Type 4 SRH-6LoRH…".  It would be nice to be consistent.

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

Proposed Standard.

    Q> (2) The IESG approval announcement includes a Document Announcement
    Q> Write-Up. Please provide such a Document Announcement Write-Up. Recent
    Q> examples can be found in the "Action" announcements for approved
    Q> documents. The approval announcement contains the following sections:

    Q> Technical Summary:

Low power And Lossy Networks (LLN) are used in a wide scope of application
areas.  The networks are extremely sensitive to power usage, and every byte
transmitted counts.  When communicating outside of the LLN, or with nodes
that do not act as routers, some routing and loop detection headers must be
added or removed. This has required introduction of a layer of IPIP
encapsulation, at a naive cost of upwards of 40 bytes of overhead per data
packet. While RFC4944 and RFC6282 provide a way to compress some of the base
overhead, it isn't sufficiently flexible to compress the IPIP
encapsulation. This document extends the 6lo mechanisms to deal with more
cases.

    Q> Working Group Summary:

The document started life in 6lo as part of another document.
ROLL WG members participated greatly during the initial work on the document,
providing motivation for why the work was important.  Once the document was
split up, this part returned to the ROLL WG for publication.  Apparently
activity in the ROLL WG itself was muted as most of the work had already been done.

No concerns, the document had good support.

    Q> Document Quality:

The document contains a generous (5 page) introduction appropriate for a reader who is
unfamiliar with the why.  The document then moves to define the compression
mechanisms in detail.  Section 3 goes on to define the rules for using the
compression, and the number of MUSTs is high; but I can suggest no way to
make the text clearer.  Section 4 explains the bit encoding in an appropriate level
of detail.

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

Document Shepherd: Michael Richardson
Responsible AD: Alvaro Retana


    Q> (3) Briefly describe the review of this document that was performed by
    Q> the Document Shepherd. If this version of the document is not ready
    Q> for publication, please explain why the document is being forwarded to
    Q> the IESG.

The shepherd read the document again from beginning to end as part of this
review.  While the document describes a reasonable mechanism to compress the
patterns anticipated by the draft-ietf-roll-useofrpi document, it is possible
that changes in 6man in April 2016 may render some of the patterns demanded
by useofrpi document obsolete.

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

I am concerned that some things may be a problem for 6man, for instance,
section 7 says:
  The encapsulation can also enable the last router prior to
  destination to remove a field such as the RPI, but this can be done
  in the compressed form by removing the RPI-6LoRH, so an IP-in-IP-
  6LoRH encapsulation is not required for that sole purpose.

Some of the implicit destination address text may prove to be less clear.
Implementors seem to be okay with this text; I anticipate clarification here on
PS->IS, but not any changes to the specification. (But I do not know which
part will be confusing).

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

None.

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

See above.
There is a fear of engaging 6man I think.

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

Yes.

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

No.

    Q> (9) How solid is the WG consensus behind this document? Does it
    Q> represent the strong concurrence of a few individuals, with others
    Q> being silent, or does the WG as a whole understand and agree with it?

The ROLL WG seems pretty happy with this work, additionally 6lo seems happy
enough as well.  At this point, pretty much all active parties that had
disputes/concerns are now authors.

    Q> (10) Has anyone threatened an appeal or otherwise indicated extreme
    Q> discontent? If so, please summarise the areas of conflict in separate
    Q> email messages to the Responsible Area Director. (It should be in a
    Q> separate email because this questionnaire is publicly available.)

No.

    Q> (11) Identify any ID nits the Document Shepherd has found in this
    Q> document. (See http://www.ietf.org/tools/idnits/ and the
    Q> Internet-Drafts Checklist). Boilerplate checks are not enough; this
    Q> check needs to be thorough.

None.

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

None.

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

Yes.

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

None.

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

There are some downrefs to documents which are also in WGLC, specifically
ietf-6lo-paging-dispatch.

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

Yes. It will update/extend RFC6550, 6553, 6554 and extend 6282, but it will
not obsolete anything.

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

It allocates some values from the to-be-created ietf-6lo-paging-dispatch registries.

    Q> (18) List any new IANA registries that require Expert Review for
    Q> future allocations. Provide any public guidance that the IESG would
    Q> find useful in selecting the IANA Experts for these new registries.

None.

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

None.

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

Proposed Standard.

    Q> (2) The IESG approval announcement includes a Document Announcement
    Q> Write-Up. Please provide such a Document Announcement Write-Up. Recent
    Q> examples can be found in the "Action" announcements for approved
    Q> documents. The approval announcement contains the following sections:

    Q> Technical Summary:

Low power And Lossy Networks (LLN) are used in a wide scope of application
areas.  The networks are extremely sensitive to power usage, and every byte
transmitted counts.  When communicating outside of the LLN, or with nodes
that do not act as routers, some routing and loop detection headers must be
added or removed. This has required introduction of a layer of IPIP
encapsulation, at a naive cost of upwards of 40 bytes of overhead per data
packet. While RFC4944 and RFC6282 provide a way to compress some of the base
overhead, it isn't sufficently flexible to compress the IPIP
encapsulation. This document extends the 6lo mechanisms to deal with more
cases.

    Q> Working Group Summary:

The document started life in 6lo as part of another document.
ROLL WG members participated greatly during the initial work on the document,
providing motivation for why the work was important.  Once the document was
split up, this part returned to the ROLL WG for publication.  Apparently
activity in the ROLL WG itself was muted as most of the work had already been done.

No concerns, the document had good support.

    Q> Document Quality:

The document contains a generous (5 page) introduction appropriate for a reader who is
unfamiliar with the why.  The document then moves to define the compression
mechanisms in detail.  Section 3 goes on to define the rules for using the
compression, and the number of MUSTs is high; but I can suggest no way to
make it clearer.  Section 4 explains the bit encoding in an appropriate level
of detail.

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

Document Shepherd: Michael Richardson
Responsible AD: Alvaro Retana


    Q> (3) Briefly describe the review of this document that was performed by
    Q> the Document Shepherd. If this version of the document is not ready
    Q> for publication, please explain why the document is being forwarded to
    Q> the IESG.

The shepherd read the document again from beginning to end as part of this
review.  While the document describes a reasonable mechanism to compress the
patterns anticipated by the draft-ietf-roll-useofrpi document, it is possible
that changes in 6man in April 2016 may render some of the patterns demanded
by useofrpi obsolete.

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

I am concerned that some things may be a problem for 6man, for instance,
section 7 says:
  The encapsulation can also enable the last router prior to
  Destination to remove a field such as the RPI, but this can be done
  in the compressed form by removing the RPI-6LoRH, so an IP-in-IP-
  6LoRH encapsulation is not required for that sole purpose.

Some of the implicit destination address text may prove to be less clear.
Implemenators seem okay with it this text; I anticipate clarification here on
PS->IS, but not any changes to the specification. (But I do not know which
part will be confusing)

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

None.

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

see above.
There is a fear of engaging 6man I think.

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

Yes.

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

no.

    Q> (9) How solid is the WG consensus behind this document? Does it
    Q> represent the strong concurrence of a few individuals, with others
    Q> being silent, or does the WG as a whole understand and agree with it?

The WG seems pretty happy with this work, additionally 6lo seems happy
enough.  At this point, pretty much all active parties that had
disputes/concerns are now authors.

    Q> (10) Has anyone threatened an appeal or otherwise indicated extreme
    Q> discontent? If so, please summarise the areas of conflict in separate
    Q> email messages to the Responsible Area Director. (It should be in a
    Q> separate email because this questionnaire is publicly available.)

no.

    Q> (11) Identify any ID nits the Document Shepherd has found in this
    Q> document. (See http://www.ietf.org/tools/idnits/ and the
    Q> Internet-Drafts Checklist). Boilerplate checks are not enough; this
    Q> check needs to be thorough.

none.

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

none

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

yes.

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

none

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

there are some downrefs to documents which are also in WGLC, specifically
ietf-6lo-paging-dispatch.

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

yes. It will update/extend RFC6550, 6553, 6554 and extend 6282, but it will
not obsolete anything.

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

It allocates some values from the to-be-created ietf-6lo-paging-dispatch registries.

    Q> (18) List any new IANA registries that require Expert Review for
    Q> future allocations. Provide any public guidance that the IESG would
    Q> find useful in selecting the IANA Experts for these new registries.

None.

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

none.