Encapsulation of 6TiSCH Join and Enrollment Information Elements
draft-ietf-6tisch-enrollment-enhanced-beacon-14

[Ballot comment]
Thanks for addressing my previous DISCUSS and COMMENT points.

** Section 2.  network id.  With the hash truncation for the network ID, please consider if additional guidance is needed to clarify that any truncation will work.

[Ballot comment]

[ Thank you for addressing my DISCUSS position, cleared ]

I found this document to be well written, and helpfully explained the background, issue, etc. Thank you!

Question:
"Pledges which have not yet enrolled are unable to authenticate the beacons, and will be forced to temporarily take the contents on faith. After enrollment, a newly enrolled node will be able to return to the beacon and validate it."
Yes, this is true - a newly enrolled node will be able to do this -- but I don't see a suggestion / requirement that they actually *do* so. I'm perfectly capable of picking up my socks, but.... :-)

Nit:
"Although However, even in this case, a" - typo / redundancy.

Please also see Qin Wu's Opsdir review (https://datatracker.ietf.org/doc/review-ietf-6tisch-enrollment-enhanced-beacon-08-opsdir-lc-wu-2020-01-21/), which has some useful questions / nits.

[Ballot discuss]
I am balloting DISCUSS because the relationship between this document and RPL parent selection is not clear.  I expect that the issues I point at will be easy to address, either by clarifying the text or my potential confusion.


It is not clear to me what is the "RPL status" of an enrolled node.  IOW, is an enrolled node to be considered one that has joined a DODAG already?  This is then causing some confusion on how RPL parent selection and the new structure defined here are related.  More details/questions below.

(1) rank priority

What is the relationship between the rank priority and parent selection as described in rfc6550?  The text says that "it is to help enrolled devices only to compare different connection points", but no details on the use are provided.

The rank priority is described as "an indication of how willing this 6LR is to serve as an RPL {?RFC6550} parent", which points directly at parent selection.  The only mention (that I could find) in rfc6550 of an indication of how "willing to act as a parent" a node may be shows up as a guideline when describing the DAO-ACK.  The relative values ("Lower values indicate more willing, and higher values indicate less willing.") are aligned, but the size of the fields is different.  How, if at all, are these values related?


(2) What is the PANID?  Is there a relationship with the DODAGID or the RPL Instance? 


(3) The text says that the pan priority "typically is used by devices which have already enrolled...MAY consider this value when looking for an eligible parent device."  As with the rank priority, there are no details about how a node may use this value during parent selection.

[Ballot comment]
§2 says that the "network ID...[is]...communicated by the RPL Configuration Option payloads".  I scanned rfc6550, but couldn't find a place where the network ID is mentioned.  Maybe I'm looking in the wrong place -- please point me in the right direction.

[Ballot comment]
— Section 1.2 —

  The EB is used by nodes already part of a TSCH network to annouce its
  existence.

I can’t figure out the antecedent to “its”.  Can you rephrase this sentence to make it clearer?

  There is a limited number of timeslots designated as a broadcast slot
  by each router in the network.

While “a limited number” looks as if it should be singular, it is generally considered plural in usage and needs “are”, not “is” (and the plural “broadcast slots”).  This is a tricky one...

You should also get rid of the “/s” later in the paragraph.

— Section 1.3 —

  if a pledge node does not hear an
  RA, and decides to send a RS

You should be consistent in use of “a” or “an”, and I think “an” works better.

In the numbered list, each item is a complete sentence and should start with a capital letter.  You also should fix the sentence capitalization throughout Section 2.

  This document defines a new IETF IE subtype

Please expand “IE” here.

— Section 3 —

  The Enhanced Beagon

Typo...

  validate the beacon, providing them with a trusted

The end of that sentence is missing.

+ + + + + + + + + + + + + + + + + + + +

The following are comments from Murray Kucherawy, incoming ART AD.  Murray is getting an early start on doing reviews, and I’m including his comments into my ballots during the overlap period before he’s officially an Area Director.

- - - - - - - - - - - - - - - - - - - -

Mostly minor things here since this is (currently) well outside my domain.

Every reference to "Enhanced Beacon" in this document parses to me as "Enhanced Bacon".

The nits from directorate reports seem to provide good editorial suggestions, though somehow none of them noticed that the second paragraph of Section 1.3 starts "Although However".  It looks kind of like the "although" should actually come after the second comma.

I don't know what to make sure of "(see {?RFC7554})".  Are they not sure about these references?  Or is this a new format thing?

RFC 8137's IANA section seems especially spartan, but there's nothing to be done about that here.  (I discovered this by following a reference.)

In Section 2, "Values range" should be "Values range from".

Same section: "The exact process is a subject of significant research work."  Are we documenting a process we don't understand?  Are any references to said research appropriate here?

The sentence "This value MUST be ignored by pledges..." is a comma splice.

Under "pan priority", should "Acycling" be "Acyclic"?

"nodes'" should be "node's", I think.

[Ballot discuss]
[ Be ye not afraid - this should be easy to answer / address ]
The Privacy Considerations says:
"The use of a network ID may reveal information about the network."
Good point - but it also goes on to say: "The use of a SHA256 hash of the DODAGID, rather than using the DODAGID (which is usually derived from the LLN prefix) directly provides some privacy for the the addresses used within the network, as the DODAGID is usually the IPv6 address of the root of the RPL mesh."

I don't know if this is an issue, but how much entropy is in a DODAGID? From what I could find, the DODAGID is often just an IP address - and subnets are not randomly distributed, nor are L2 addresses (inputs to address generation) - if I know that many of the nodes come from vendor_A, and I know their L2 / MAC range, can I enumerate this, and by extension the DODAGID, and so the hash?

I will happily admit that I haven't fully researched this / thought it through, so "Nah, won't work" or "Yes, will work, but we did say 'provides some privacy', not 'absolute privacy'" or all acceptable answers :-)

[Ballot comment]
I found this document to be well written, and helpfully explained the background, issue, etc. Thank you!

Question:
"Pledges which have not yet enrolled are unable to authenticate the beacons, and will be forced to temporarily take the contents on faith. After enrollment, a newly enrolled node will be able to return to the beacon and validate it."
Yes, this is true - a newly enrolled node will be able to do this -- but I don't see a suggestion / requirement that they actually *do* so. I'm perfectly capable of picking up my socks, but.... :-)

Nit:
"Although However, even in this case, a" - typo / redundancy.

Please also see Qin Wu's Opsdir review (https://datatracker.ietf.org/doc/review-ietf-6tisch-enrollment-enhanced-beacon-08-opsdir-lc-wu-2020-01-21/), which has some useful questions / nits.

[Ballot comment]
Balloting "No Objection" in the sense of "I trust the sponsoring AD, and have no time this ballot cycle to read the document." I have skimmed the document for typical ART-area gotchas, and found none.

[Ballot discuss]
== Section 2 ==

"If this field is not present,
      then IID is derived from the layer-2 address of the sender as per
      SLAAC ({?RFC4662})."

RFC 8064 recommends that the default IID generation scheme for use with SLAAC is not to use the layer-2 address, but to use the mechanism specified in RFC 7217. Is there a reason this specification is making a different recommendation?

[Ballot comment]
== Section 1.3 ==

This sentence is not comprehensible:

"Although However, even in this case, a unicast RS may be transmitted
  in response[RFC6775] reduces the amount of multicast necessary to do
  address resolution via Neighbor Solicitation (NS) messages, it still
  requires multicast of either RAs or RS."
 
== Section 2 ==

s/({?RFC4662})/[RFC4862] 
 
== Section 4 ==

A network doesn't have privacy considerations. The draft might want to discuss how this specification reveals information about network topology, but that isn't a privacy consideration.

DODAGID needs to be expanded on first use and needs a citation to be provided.

[Ballot comment]
Martin Duke (Incoming TSV AD) provided the below comments and proposals that could improve the document, please consider them:

First, Section 1 is an excellent description of the motivation for the document.

Sec 1.2. "synchronization of ^the^ Absolute Slot Number..."
"carrying ^the^ timeslot template identifier..."
at the end of section, the acronym for Router Advertisements is incorrectly given as (RS).

Sec 1.3. Proposed rewording for the second paragraph:
"However, while a unicast RS transmitted in response [RFC6775] reduces the amount..."
s/RAs or RS./RAs or RSes.
In reason #3, please provide some sense of order of magnitude instead of "a very long time"

Section 2. Please expand the following acronyms on first use: 6L$, RPL, PAN, JRC.

"rank priority" definition: s/willing/willingness

Proposed rewording of 4th paragraph in "rank priority":
"Pledges MUST ignore this value. It helps enrolled devices to compare connection points."

"pan priority" definition, last paragraph: insert comma after "observed PANID in the Beacon"

"Join Proxy Interface ID" definition:
This field communicates the Interface ID bits that should be used
      for this node's layer-3 address, if it should not be derived from
      the layer-2 address.  Communication with the Join Proxy occurs in
      the clear. This field avoids the need for an additional service
      discovery process .."

"network ID": s/convenience/convenient, s/identifing/identifying

last paragraph: "...the it will be an opaque, seemingly random value, and will reveal nothing by itself."

Finally, throughout Section 2 the draft mentions potential information leakage to attackers. Two comments on this:
- I believe "proxy priority" creates a similar exposure, but doesn't mention it.
- It might be good to summarize these issues in the Security Considerations as well.

[Ballot comment]
Where is PAN/PANID defined?  I did not find it in RFC 6550, 8180, or
draft-ietf-6tisch-architecture, nor in the RFC Editor's list
(https://www.rfc-editor.org/materials/abbrev.expansion.txt).

Thank you for discussing the security considerations of each field
throughout!

Section 1.3

  Although However, even in this case, a unicast RS may be transmitted
  in response[RFC6775] reduces the amount of multicast necessary to do
  address resolution via Neighbor Solicitation (NS) messages, it still
  requires multicast of either RAs or RS.  This is an expensive

nits: two capitalized words in a row, also some further rewording is
needed (and maybe s/unicast RS/unicast RA/?).

Section 2

We should probably say something about the 'res' bits being reserved,
set to zero, and ignored by recipients.

      In most cases, every node sending a beacon will set this flag, and
      in a typical mesh, this will be every single node.  When this bit
      is not set, it indicates that this node may be under provisioned,
      or may have no additional slots for additional nodes.  This could
      make this node more interesting to an attacker.

nit: this phrasing suggests that the list is an exhaustive list of
reasons why the flag could be unset; I'd suggest "it might indicate"
instead.

      This value MUST be ignored by pledges, it is to help enrolled
      devices only to compare different connection points.

nit: comma splice.  Maybe also reword to "It is only to help enrolled
devices to compare different connection points"?

      This field communicates an Interface ID bits that should be used
      for this nodes' layer-3 address, if it should not be derived from

nit: singular/plural mistmatch in "an Interface ID bits"
nit: s/nodes'/node's/

      the layer-2 address.  Communication with the Join Proxy occurs in
      the clear, this field avoids the need for an additional service
      discovery process for the case where the L3 address is not derived
      from the L2 address.  An attacker will see both L2 and L3

nit: comma splice.  I'd also hyphenate "service-discovery".

      once.  That is just a suggestion for a default algorithm: it may
      be set in any convenience way that results in a non-identifing
      value.  In some LLNs where multiple PANIDs may lead to the same

nits: I suggest "Per [RFC6550], that is just a suggestion",
s/convenience/convenient/, and s/identifing/identifying/ (though what
exactly it is that is not being identified might be worth clarifying,
too).

      management device (the JRC), then a common value that is the same
      across all PANs MUST be configured so that pledges that attempt to

nit: I think "all the PANs" is more appropriate, since we only care
about the ones that lead to the same JRC (and there may be other PANIDs
in play).

      enroll do not waste time attempting multiple times with the same
      network that has multiple attachment points.

nit: I'd consider expanding (again) what is being attempted.

      If the network ID is derived as suggested, then it will an opaque,

nit: s/will/will be/

      seemingly random value, and will reveal nothing in of itself.  An

I suggest "will not directly reveal any information about the network".

Section 3

  The sensitivity of each field is describe within the description of
  each field.

nit: s/describe/described/

  visible.  Encrypting the schedule does not prevent an attacker from
  jamming, but rather increases the energy cost of doing that jamming.

Perhaps also the side effects/collateral damage of the jamming.

[Ballot comment]
One question: How is the proxy priority supposed to be calculated/set? Is there a default value?

Is also support points raised in Roman's discuss points. More clarification is needed.

Editorial comment:
I would recommend to repeat the abstract in the intro as, as stated in the RFC style guide RFC7322 section 4.3, "[...] an Abstract is not a substitute for an Introduction; the RFC should be self-contained as if there were no Abstract."

Nit: sec 1.3:
s/Although However/Although/ or s/Although However/However/ ?
s/a unicast RS may be transmitted in response[RFC6775] reduces the amount of.../a unicast RS that may be transmitted in response [RFC6775] reduces the amount of.../ ? (Also note missing space before [)

[Ballot comment]
** Section 2.  Rank Priority.
This is a local
      value to be determined in other work.  It might be calculated from
      RPL rank, and it may include some modifications based upon current
      number of children, or number of neighbor cache entries available.

-- what’s a local value?  What’s the other work? 

-- the follow on sentence of “It might be … “ doesn’t seem decisive in the guidance.  Would it be cleaner to say, that the computation of this value is out of scope of this document.

** Editorial

-- Please review Yoav Nir’s SECDIR feedback

-- Abstract.  Per “Nodes in the TSCH network typically frequently transmit …”, likely only “typically” or “frequently” is needed.

-- Typo.  s/the the/the/g

[Ballot discuss]
** Section 2.  Rank Priority and Pan Priority.  Can you please clarify whether a higher or lower number indicated an increased priority:

-- Rank priority says “Lower values are better” -- What does “better” mean?  Is a lower number more or less willing this 6LR is to serve as the RPL parent?

-- Pan priority doesn’t include guidance on whether a higher or lower number indicate increased priority.

** Section 2.  network id.  Can you please clarify the computation of the default value using SHA-256.

The text initially says that network id is a “variable length field, up to 16 bytes in size”.  Later it says that “the network ID can be constructed from a SHA256 hash of the prefix (/64) of the network.  That is just a suggestion for a default value.”  However, a SHA256 hash has a 256 bit output which can’t fit into a 16 byte field size.  Is there a truncation?

[Ballot comment]
** Section 2.  Rank Priority.
This is a local
      value to be determined in other work.  It might be calculated from
      RPL rank, and it may include some modifications based upon current
      number of children, or number of neighbor cache entries available.

-- what’s a local value?  What’s the other work? 

-- the follow on sentence of “It might be … “ doesn’t seem especially crisp in guidance.  Would it be cleaner to say, that the computation of this value is out of scope of this document.

** Editorial

-- Please review Yoav Nir’s SECDIR feedback

-- Abstract.  Per “Nodes in the TSCH network typically frequently transmit …”, likely only “typically” or “frequently” is needed.

-- Typo.  s/the the/the/g

[Ballot comment]
Thank you for the work put into this document: it seems simple and easy :-)

Nevertheless, please find below some non-blocking COMMENTs (and I would appreciate a response from the authors) and NITS.

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

-- Abstract --
"announce the presence of the network" makes me wonder... Do nodes announce the network ? or do nodes announced THEIR presence in the network ? or do router nodes announce the network? or am I too unfamiliar with TSCH ?

-- Section 1.2 --
Please expand "ASN" at first use. I guess that this is not the usual AS Number ;-)

-- Section 1.3 --
Please add a reference for "broadcast aloha slot".

Isn't the word "IETF" in "defines a new IETF Information Element (IE)" redundant in an IETF document ?

-- Section 2 --
"that need addressing via unicast Router Solicitation messages" is unclear to me... Is to do SLAAC ? or look for an actual router?

Add a reference + acronym expansion to RPL at first use.

"This field provides the suffix (IID)" please expand interface ID and, on my side, I do not like naming the IID as a suffix.

-- Section 5 --
Reading and applying RFC 8126 (how to write IANA considerations) would be beneficial.

== NITS ==

-- Abstract --
Suggest to expand TSCH at first use.

-- Section 1.3 --
Unsure whether "reasons: First, there" should have a capitalized "First".

There are also many acronyms that should be expanded at first use (I stopped commenting about those).

[Ballot comment]
— Section 1.2 —

  The EB is used by nodes already part of a TSCH network to annouce its
  existence.

I can’t figure out the antecedent to “its”.  Can you rephrase this sentence to make it clearer?

  There is a limited number of timeslots designated as a broadcast slot
  by each router in the network.

While “a limited number” looks as if it should be singular, it is generally considered plural in usage and needs “are”, not “is” (and the plural “broadcast slots”).  This is a tricky one...

You should also get rid of the “/s” later in the paragraph.

— Section 1.3 —

  if a pledge node does not hear an
  RA, and decides to send a RS

You should be consistent in use of “a” or “an”, and I think “an” works better.

In the numbered list, each item is a complete sentence and should start with a capital letter.  You also should fix the sentence capitalization throughout Section 2.

  This document defines a new IETF IE subtype

Please expand “IE” here.

— Section 3 —

  The Enhanced Beagon

Typo...

  validate the beacon, providing them with a trusted

The end of that sentence is missing.

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

The IANA Functions Operator has completed its review of draft-ietf-6tisch-enrollment-enhanced-beacon-06. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there is a single action which we must complete.

In the IEEE Std 802.15.4 IETF IE Subtype IDs registry located at:

https://www.iana.org/assignments/ieee-std-802.15.4-ietf-ie-subtype-ids/

a new registration is to be made as follows:

Value: [ TBD-at-Registration ]
SubtypeID: 6tisch-Join-Info
Reference: [ RFC-to-be ]

As this document requests registrations in an Expert Review or Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

The IANA Functions Operator understands that this is the only action 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 meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2020-01-22):

From: The IESG
To: IETF-Announce
CC: pthubert@cisco.com, draft-ietf-6tisch-enrollment-enhanced-beacon@ietf.org, Pascal Thubert , 6tisch-chairs@ietf.org, 6tisch@ietf.org, suresh@kaloom.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (IEEE 802.15.4 Information Element encapsulation of 6TiSCH Join and Enrollment Information) to Proposed Standard


The IESG has received a request from the IPv6 over the TSCH mode of IEEE
802.15.4e WG (6tisch) to consider the following document: - 'IEEE 802.15.4
Information Element encapsulation of 6TiSCH Join and
  Enrollment Information'
  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
last-call@ietf.org mailing lists by 2020-01-22. 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


  In TSCH mode of IEEE STD 802.15.4, opportunities for broadcasts are
  limited to specific times and specific channels.  Nodes in a TSCH
  network typically frequently send Enhanced Beacon (EB) frames to
  announce the presence of the network.  This document provides a
  mechanism by which small details critical for new nodes (pledges) and
  long sleeping nodes may be carried within the Enhanced Beacon.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-6tisch-enrollment-enhanced-beacon/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-6tisch-enrollment-enhanced-beacon/ballot/


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


The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc8137: IEEE 802.15.4 Information Element for the IETF (Informational - IETF stream)

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) This is a intended as Proposed Standard, as indicated in the boiler plate and consistent with the WG document page.
This is needed since the doc specifies new frame formats.

(2) The IESG approval announcement includes a Document Announcement

Technical Summary

  In TSCH mode of IEEE802.15.4, as described by [RFC8180],
  opportunities for broadcasts are limited to specific times and
  specific channels.  Nodes in a TSCH network typically frequently send
  Enhanced Beacon (EB) frames to announce the presence of the network.
  This document provides a mechanism by which small details critical
  for new nodes (pledges) and long sleeping nodes may be carried within
  the Enhanced Beacon.

Working Group Summary

This is a simple and well-understood specification. Went through the WG without hassle, raised very few comments actually.

Document Quality

Most of the reviewers were 802.15.4 TSCH experts and the quality is really good.
We have not seen implementation plans, but that should come since this is both simple and needful.

Personnel

Document Shepherd: Pascal Thubert
Responsible Area  Director: Suresh Krishnan

(3) Briefly describe the review of this document that was performed by
the Document Shepherd

The shepherd participated and encouraged discussions in that topic. Also produced the last review before WGLC which lead to -02.

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

There were little reviews but hen again this is just packaging a few needful information. The needed information was heavily discussed at WG meetings.


(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 such thing

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

No such thing

(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 filed IPR disclosure

(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 were no heavy discussion but that’s understandable when basically adding a TLV to an existing format.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent?

No such thing


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

Downref to RFC 8137 to be validated by IESG.

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

No such thing

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

Both RFC-to-be normative refs are already submitted for publication

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

Downref to RFC 8137 to be validated by IESG.

(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 such thing

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

A IANA request is made as desired for an entry in an existing registry

(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 spec does not introduce a new registry, nor does it modify the allocation rules in an existing registry.

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

Just the ID Nits

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) This is a intended as Proposed Standard, as indicated in the boiler plate and consistent with the WG document page.
This is needed since the doc specifies new frame formats.

(2) The IESG approval announcement includes a Document Announcement

Technical Summary

  In TSCH mode of IEEE802.15.4, as described by [RFC8180],
  opportunities for broadcasts are limited to specific times and
  specific channels.  Nodes in a TSCH network typically frequently send
  Enhanced Beacon (EB) frames to announce the presence of the network.
  This document provides a mechanism by which small details critical
  for new nodes (pledges) and long sleeping nodes may be carried within
  the Enhanced Beacon.

Working Group Summary

This is a simple and well-understood specification. Went through the WG without hassle, raised very few comments actually.

Document Quality

Most of the reviewers were 802.15.4 TSCH experts and the quality is really good.
We have not seen implementation plans, but that should come since this is both simple and needful.

Personnel

Document Shepherd: Pascal Thubert
Responsible Area  Director: Suresh Krishnan

(3) Briefly describe the review of this document that was performed by
the Document Shepherd

The shepherd participated and encouraged discussions in that topic. Also produced the last review before WGLC which lead to -02.

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

There were little reviews but hen again this is just packaging a few needful information. The needed information was heavily discussed at WG meetings.


(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 such thing

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

No such thing

(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 filed IPR disclosure

(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 were no heavy discussion but that’s understandable when basically adding a TLV to an existing format.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent?

No such thing


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

Downref to RFC 8137 to be validated by IESG.

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

No such thing

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

Both RFC-to-be normative refs are already submitted for publication

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

Downref to RFC 8137 to be validated by IESG.

(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 such thing

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

A IANA request is made as desired for an entry in an existing registry

(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 spec does not introduce a new registry, nor does it modify the allocation rules in an existing registry.

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

Just the ID Nits

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) This is a intended as Proposed Standard, as indicated in the boiler plate and consistent with the WG document page.
This is needed since the doc specifies new frame formats.

(2) The IESG approval announcement includes a Document Announcement

Technical Summary

  In TSCH mode of IEEE802.15.4, as described by [RFC8180],
  opportunities for broadcasts are limited to specific times and
  specific channels.  Nodes in a TSCH network typically frequently send
  Enhanced Beacon (EB) frames to announce the presence of the network.
  This document provides a mechanism by which small details critical
  for new nodes (pledges) and long sleeping nodes may be carried within
  the Enhanced Beacon.

Working Group Summary

This is a simple and well-understood specification. Went through the WG without hassle, raised very few comments actually.

Document Quality

Most of the reviewers were 802.15.4 TSCH experts and the quality is really good.
We have not seen implementation plans, but that should come since this is both simple and needful.

Personnel

Document Shepherd: Pascal Thubert
Responsible Area  Director: Suresh Krishnan

(3) Briefly describe the review of this document that was performed by
the Document Shepherd

The shepherd participated and encouraged discussions in that topic. Also produced the last review before WGLC which lead to -02.

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

There were little reviews but hen again this is just packaging a few needful information. The needed information was heavily discussed at WG meetings.


(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 such thing

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

No such thing

(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 filed IPR disclosure

(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 were no heavy discussion but that’s understandable when basically adding a TLV to an existing format.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent?

No such thing


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

Downref to RFC 8137 to be validated by IESG.

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

No such thing

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

Both RFC-to-be normative refs are already submitted for publication

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

Downref to RFC 8137 to be validated by IESG.

(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 such thing

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

A IANA request is made as desired for an entry in an existing registry

(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 spec does not introduce a new registry, nor does it modify the allocation rules in an existing registry.

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

Just the ID Nits

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

1) This is a intended as Proposed Standard, as indicated in the boiler plate and consistent with the WG document page.
This is needed since the doc specifies new frame formats.
2) The IESG approval announcement includes a Document Announcement

Technical Summary

  In TSCH mode of IEEE802.15.4, as described by [RFC8180],
  opportunities for broadcasts are limited to specific times and
  specific channels.  Nodes in a TSCH network typically frequently send
  Enhanced Beacon (EB) frames to announce the presence of the network.
  This document provides a mechanism by which small details critical
  for new nodes (pledges) and long sleeping nodes may be carried within
  the Enhanced Beacon.

Working Group Summary

This is a simple and well-understood specification. Went through the WG without hassle, raised very few comments actually.

Document Quality

Most of the reviewers were 802.15.4 TSCH experts and the quality is really good.
We have not seen implementation plans, but that should come since this is both simple and needful.

Personnel

Document Shepherd: Pascal Thubert
Responsible Area  Director: Suresh Krishnan

(3) Briefly describe the review of this document that was performed by
the Document Shepherd

The shepherd participated and encouraged discussions in that topic. Also produced the last review before WGLC which lead to -02.

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

There were little reviews but hen again this is just packaging a few needful information. The needed information was heavily discussed at WG meetings.


(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 such thing

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

No such thing

(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 filed IPR disclosure

(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 were no heavy discussion but that’s understandable when basically adding a TLV to an existing format.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent?

No such thing


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

Downref to RFC 8137 to be validated by IESG.

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

No such thing

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

Both RFC-to-be normative refs are already submitted for publication

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

Downref to RFC 8137 to be validated by IESG.

(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 such thing

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

A IANA request is made as desired for an entry in an existing registry

(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 spec does not introduce a new registry, nor does it modify the allocation rules in an existing registry.

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

Just the ID Nits