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 <mcr@sandelman.ca>
Responsible AD: Alvaro Retana <aretana@cisco.com>
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.