An Architecture for IPv6 over the Time-Slotted Channel Hopping Mode of IEEE 802.15.4 (6TiSCH)
draft-ietf-6tisch-architecture-30

[Ballot comment]
Thanks for addressing my discuss and putting more work into the doc.

OLD COMMENT:

As I said, I only had a rather brief read, however, I had a bit of problems to follow exactly which parts of the architecture rely on existing protocols and mechanisms and where 6tsch actually needs to define new approaches. Maybe a short, even higher-level overview than section 3, could address this and help the reader.

[Ballot comment]
** Why are both Section 3.4 and Section 4.4 needed?  Both appear to explain the four scheduling mechanisms.  Section 4.4. appears to have more details.

** Section 3.6. Per the summary table in this section, what is the routing technique “reactive P2P”.  It doesn’t appear to be explained in the text above.

** Section 3.6.  Per the “Hop-by-Hop  (TBD)” in the scheduling column in the summary table, to what does the “TBD”?

** Section 6.  In reviewing the Security Considerations section, there is a substantial amount of technical detail (thank you!).  However, despite this detail, understanding the overall security properties of the architecture and associate implementations mechanisms used by the architecture was challenging for me.  Specifically, if 6TiSCH “is subject to the observations in section 5 of [I-D.ietf-detnet-architecture]”, then per [I-D.ietf-detnet-architecture] it should provide “confidentiality of data traversing the DetNet”, “authentication and authorization … for each connected device”, availability, and precision timing. The text needs to be clearer on how those properties are realized, and if there are residual threat.  My recommended way to realize this clarity is restructure the text into blocks around the relevant security properties and explicitly state the property as an introduction.  A few additional points:

-- Per precision timing, the text in this section says “measures must be taken to protect the time synchronization, and for 6TiSCH this includes ensuring that the Absolute Slot Number (ASN), which is used as ever incrementing counter for the computation of the Link-Layer security nonce, is not compromised, more below on this.”  In the subsequent text there is “[t]he standard [IEEE802154] assumes that the ASN is distributed securely by other means.  The ASN is not passed explicitly in the data frames”.  To confirm, is this the intended guidance on avoiding “compromising” the ASN – distribute it out of band and don’t pass it in the data frame?

-- Per confidentiality (but it is really more than that), a series of security mechanisms/assumptions are inherited from [IEEE Std. 802.15.4] around link-layer security. They need to be explicitly stated (i.e., confidentiality, authenticity, with what crypto, relative to whom, etc.).  The operational details of key management has no treatment.

-- Per availability, the text notes “communication with the PCE must be secured and protected against DoS”.  Secured how?

** Section 6.  Per “Section 9 of [RFC8453] applies equally to 6TiSCH”, this reference organizes threats and mitigations around the CMI and MPI interfaces.  What is the analog to those in this architecture?

** Section 6.  Please provide a citation for “CCM*”

** Editorial
-- Section 3.1. Typo. s/an homogenous/a homogenous/

-- Section 3.5. Typo. s/[RFC6550]is/[RFC6550] is/

-- Section 3.6. Typo. s/A central/a central/

-- Section 3.6. Typo.  s/an hybrid/a hybrid/

-- Section 3.7.  The paragraph starting with “The reference stack that the 6TiSCH architecture presents …” doesn’t seem to add any clarity.

-- Section 4.2.1. Typo.  s/(JP):/(JP),/

-- Section 4.2.2.  Typo. /ND ot the/ND to the/

-- Section 4.3.1.1. Typo. s/are are/are/

-- Section 4.3.1.1. Duplicate phrase.  “added/moved/deleted, in which case 6top can only act as instructed,” appears twice.

-- Section 4.3.5.  Typo.  s/an height/a height/

[Ballot discuss]
Section 4.3.4 asserts:

  [...]                                      We'll note that the Join
  Priority is now specified between 0 and 0x3F leaving 2 bits in the
  octet unused in the IEEE Std. 802.15.4e specification.  After
  consultation with IEEE authors, it was asserted that 6TiSCH can make
  a full use of the octet to carry an integer value up to 0xFF.

I'm extremely reluctant to publish this text in the IETF stream without
a citation.


I also think there are more topics that need to be covered in the
security considerations (see Comment, and not just the Section-6
portions), especially with respect to the reliance on the link-layer
security mechanism and its network-wide shared key.

[Ballot comment]
[The shepherd writeup's answer for the question about "why is this the
proper type of RFC" did not change when the intended status changed from
Proposed Standard to Informational, which would have been nice to see
recorded.]

It would be good to see some architectural discussion about key
management for the link-layer keys.  (Given that 802.15.4 leaves key
management as out of scope, it is clearly our problem.)  Thus far I
don't even have a sense for when it is possible to rotate a network's
keys.

I'd like to see some discussion somewhere that the Join Proxy needs to
take care to not be an open redirector by which an unauthenticated
pledge can attack arbitrary network elements (whether within the LLN or
on the broader network), e.g., by performing some validation on the
claimed MASA identifier.  Similarly, that the JRC will be exposed to
lots of untrusted input and needs to be implemented in an especially
robust manner.

In some qualitative sense that's hard to describe, this document feels
like a mash-up of two or maybe three different documents written at
different levels of abstraction.  I don't know if it's even worth
considering trying to tease them apart, though.

Section 2.1

  Layer-2 vs. Layer-3 bundle:  Bundles are associated for either
              Layer-2 (switching) or Layer-3 (routing) forwarding
              operations.  A pair of Layer-3 bundles (one for each
              direction) maps to an IP Link with a neighbor, whereas a
              set of Layer-2 bundles (a number per neighbor, either
              from or to the neighbor) corresponds to the relation of
              one or more incoming bundle(s) from the previous-hop
              neighbor(s) with one or more outgoing bundle(s) to the
              next-hop neighbor(s) along a Track.

What does "a number per neighbor" mean? That the "set of Layer-2
bundles" can have "arbitrary" cardinality and be partitioned arbitrarily
between an incoming neighbor and an outgoing neighbor as part of the
switching role?

"PDR" seems to currently get defined at its second (last!) use, not the
first use.

  scheduled cell:  A cell which is assigned a neighbor MAC address
              (broadcast address is also possible), and one or more of
              the following flags: TX, RX, shared, timeskeeping.  A

"timeskeeping" does not seem to be defined anywhere.

Section 3.2

In Figure 2, why is the 6LBR "off to the side" and not on the boundary
interface of anything?

  The use of multicast can also be reduced on the backbone with a
  registrar that would contribute to Duplicate Address Detection as
  well as Address Lookup using only unicast request/response exchanges.
  [I-D.thubert-6lo-unicast-lookup] is a proposed method that presents
  an example of how to this could be achieved with an extension of
  [RFC8505], using a 6LBR as a SubNet-level registrar.

How speculative is this reference?

  As detailed in Section 4.1 the 6LBR that serves the LLN and the root
  of the RPL network needs to share information about the devices that
  are learned through either protocol but not both.  The preferred way

What are the two protocols involved in "either protocol but not both"?

Section 3.4

  channel at any point of time.  Scheduled cells that play an equal
  role, e.g., receive IP packets from a peer, are grouped in bundles.

nit: I'd suggest s/play an equal/fulfil the same/

  Neighbor-to-Neighbor Scheduling:  This refers to the dynamic
      adaptation of the bandwidth of the Links that are used for IPv6
      traffic between adjacent routers.  Scheduling Functions such as
      the "6TiSCH Minimal Scheduling Function (MSF)"
      [I-D.ietf-6tisch-msf] influence the operation of the MAC layer to
      add, update and remove cells in its own, and its peer's schedules
      using 6P [RFC8480], for the negotiation of the MAC resources.

nit(?): is this "in its own schedule"?

Section 3.7

In Figure 4, what does "Applis" stand for?  It does not appear anywhere
else in the document.

  RPL is the routing protocol of choice for LLNs.  So far, there was no
  identified need to define a 6TiSCH specific Objective Function.  The
  Minimal 6TiSCH Configuration [RFC8180] describes the operation of RPL
  over a static schedule used in a slotted aloha fashion, whereby all

RFC 8100 does not use the term "slotted aloha", and neither usage in
this document provides an alternative reference or definition.

Section 3.8

  information that is being exchanged.  In contrast, an Interaction
  Models would be more refined and could point on standard operation

nit: I suggest s/point on/point to/

Section 4.1.1

DAO should probably be expanded somewhere.

  The RPL InstanceID that the leaf wants to participate to may be
  signaled in the Opaque field of the EARO.  On the backbone, the

Any (informational) reference as to how?

Section 4.2.1

It's worrisome to see all the excitement around reusing BRSKI without
clear evidence that the assumptions made in core BRSKI are being
revalidated for the new use cases.  (I thought I had even noted such an
assumption that merited a closer look in my ballot position on BRSKI,
but I can't find it right now amongst the 1500 lines.)

Please document somewhere that "@" is used as an abbreviation for
"address" in Figure 5.

Section 4.2.2

I can't tell what the "" in  Figure 6 is intended to refer to.
Is it the whole figure?

  to keep a global address alive and registered to its 6LBR using
  6LoWPAN ND [RFC8505], using 6LoWPAN ND ot the 6LR, RPL to the RPL

nit: s/ot/to/
Also, do we need to say "using 6LoWPAN ND" twice?

Section 4.3.1.1

There seems to be a duplicated source line in here.

Section 4.3.4

  Time distribution requires a loop-free structure.  Nodes taken in a
  synchronization loop will rapidly desynchronize from the network and
  become isolated.  It is expected that a RPL DAG with a dedicated
  global Instance is deployed for the purpose of time synchronization.

The "it is expected" language is confusing.  Is the TSGI part of the
architecture, a common way to provide functionality assumed by the
architecture, or something  else?

  A root is configured or obtains by some external means the knowledge
  of the RPLInstanceID for the TSGI.  The root advertises its DagRank

To what extent will the RPL root be known advance as opposed to
determined at runtime by the protocol execution?

Section 4.3.6

Is the division of the CDU matrix into chunks something expected to be
conveyed during the join process, or provisioned at device manufacture,
or codified into a profile document, or some other mechanism?  (Is this
different from "static scheduling"?)

  The 6TiSCH Architecture expects that a future protocol will enable a
  chunk ownership appropriation whereby a RPL parent discovers a chunk

The writing here is pretty speculative.  Maybe "envisions a protocol
that enables chunk ownership appropriation" is better?

Section 4.4

The descriptions here seems to have high overlap with Section 3.4; can we
deduplicate anything?

Section 4.4.4

  This hop-by-hop reservation mechanism is expected to be similar in
  essence to [RFC3209] and/or [RFC4080]/[RFC5974].  The protocol for a
  node to trigger hop-by-hop scheduling is not yet defined.

For some reason this text feels much less speculative than the one I
quoted from Section 4.3.6.

Section 4.5.1

  Multiple cells may be scheduled in a Track for the transmission of a
  single packet, in which case the normal operation of IEEE Std.
  802.15.4 Automatic Repeat-reQuest (ARQ) can take place; the
  acknowledgment may be omitted in some cases, for instance if there is
  no scheduled cell for a possible retry.

Are there security consequences of having to omit the ack/retry?  Will
the sender know in advance if this is the case?

  4.  Tracks are protected from interfering with one another if a cell
      belongs to at most one Track, and congestion loss is avoided if
      at most one packet can be presented to the MAC to use that cell.
      Tracks enhance the reliability of transmissions and thus further
      improve the energy consumption in LLN Devices by reducing the
      chances of retransmission.

How might these properties (cell belongs to at most one Track, at most
one packet presented to the MAC to use that cell) be achieved?

Section 4.5.2

Do we want to note (again) that setting up this forwarding state costs
energy since the radio will be active for all scheduled cells, or is
that too much repetition?

  For a given iteration of the device schedule, the effective channel
  of the cell is obtained by adding a pseudo-random number to the
  channelOffset of the cell, which results in a rotation of the
  frequency that used for transmission.

I'm not sure that I understand how this works.

Section 4.5.3

Where is PRE defined?

Section 4.5.5

  It results in a frame that is received in a RX-cell of a Track with a
  destination MAC address set to this node as opposed to broadcast must
  be extracted from the Track and delivered to the upper layer (a frame
  with an unrecognized destination MAC address is dropped at the lower
  MAC layer and thus is not received at the 6top sublayer).

I don't think this is a well-formed sentence (somewhere around "as
opposed to broadcast"?).  The parenthetical should probably be its own
sentence, even if it remains in parentheses.

  appropriate bundle if possible.  A frame should be re-Tracked if the
  Per-Hop-Behavior group indicated in the Differentiated Services Field
  of the IPv6 header is set to Deterministic Forwarding, as discussed
  in Section 4.7.1.  A frame is re-Tracked by scheduling it for

I don't see anything about diffserv or deterministic forwarding in
Section 4.7.1.

Section 4.6.1

It would be nice if the subsection order matched the list of the three
different forwarding model[s].

Section 4.6.1.3

  address.  It is thus mandatory at the ingress point to validate that
  the MAC address that was used at the 6LoWPAN sublayer for compression
  matches that of the tunnel egress point.  For that reason, the node
  that injects a packet on a Track checks that the destination is
  effectively that of the tunnel egress point before it overwrites it
  to broadcast.  [...]

What does it do if the check fails?

Section 4.6.3

What are the security consequences of fragment forwarding vs. reassembly
at each hop?  Are we assuming that only nodes granted a certain degree
of trust are on the network (as we might be wont to do given the
link-layer access control) to provide some protection against abuse?

Section 4.7.1

The text here isn't quite enough for me to tease out whether the 6TiSCH
Instance ID and the RPLInstanceID are the same thing or different.
(In particular, the "location [...] must be the same" for the 6TiSCH one
is hard to mesh with the RPL one being in an IPv6 hop-by-hop header.)

Section 4.7.2

"sequence number would be tagged in the packet for that purpose" is
maybe a little heavier on jargon that it needs to be.

Section 6

We might benefit from splitting this into a few subsections.

We could potentially talk about the risk of external/unregulated
interference breaking the deterministic guarantees of any wireless
scheme, as a sufficiently motived (targetted) attacker could always
effectively jam the legitimate communications.

I'd like to see some discussion about the threat model, in addition to
the generic DetNet architecture.  Specifically, for TiSCH, we seem to be
relying heavily on the link-layer security, which ends up being a group
symmetric secret.  Thus, we rely on the join process to deny
authorization of invalid nodes and preserve the integrity of the network
keys.  This, in turn, looks a lot like the "thin crispy shell and gooey
interior" network model that is going out of favor for corporate
networks in favor of a VPNless or "zero-trust" model.  It's not clear
that we can make the same transition at the LLN layer, but we can at
least talk about the risks, especially when we are going to be dependent
on a third party (MASA) in the trust chain.

Will there need to be any (additional) authentication/authorization
mechanisms for cell or chunk reservation/allocation?

For central monitoring/management cases, are there any additional
considerations to mention with respect to getting the monitoring to the
controller in a timely and accurate fashion?  I don't remember how
strongly detnet overlaps with this (but our radio technology potentially
makes this a more important consideration).

  After obtaining the tentative ASN, a pledge that wishes to join the
  6TiSCH network must use a join protocol to obtain its security keys.
  The join protocol used in 6TiSCH is the Constrained Join Protocol
  (CoJP).  In the minimal setting defined in
  [I-D.ietf-6tisch-minimal-security], the authentication requires a
  pre-shared key, based on which a secure session is derived.  The CoJP
  exchange may also be preceded with a zero-touch handshake
  [I-D.ietf-6tisch-dtsecurity-zerotouch-join] in order to enable pledge
  joining based on certificates and/or inter-domain communication.

Do we want to mention that more robuse ("non-minimal") mechanisms are
also in development?
It's probably worth talking about the risks of the pure-PSK usage in
6tisch-minimal-security, lack of forward secrecy(?), etc.

  appropriate network.  As a result of the CoJP exchange, the pledge is
  in possession of a Link-Layer material including keys and a short
  address, and if the ASN is known to be correct, all traffic can now
  be secured using CCM* at the Link-Layer.

What happens if the ASN is not correct?

Section 8.2

I agree with Mirja that many of these nominally-informative references
are really normative.

Section A.2.1

The EDHOC status could be updated to reflect the LAKE developments.

Section A.2.2

The "[formation of RAW] is being considered" text is basically
duplicated.

[Ballot comment]
I support Mirja's DISCUSS.  The same point has been brought up in several of the Directorate reviews...for example [1] and [2].  It seems that the concern has not been fully addressed.

[1] https://mailarchive.ietf.org/arch/msg/tsv-art/OErnkMZ1Vb-BzYSGRs1KMC7g_f8
[2] https://mailarchive.ietf.org/arch/msg/rtg-dir/9eR1oXVO0_n6Cl3CFV1Ytxrv2FU

[Ballot discuss]
I only had a quick read of this document, however, it seems to me that there are strong dependencies on a whole bunch of drafts, that are only listed as informational. I don't have a deep enough understanding to make a final judgement of which draft would need to be listed as normative references, however, I wanted to raise this point on the discuss level in order to ensure that this is considered before publication.

To give an example: Section 4.6.3 goes quite seep into details of what's described in [I-D.ietf-6lo-fragment-recovery]. However as long as [I-D.ietf-6lo-fragment-recovery] is not published yet, the 6tisch arch should probably not rely on the content of this draft that strongly. Putting [I-D.ietf-6lo-fragment-recovery] as a normative reference ensures that this draft will not be published before [I-D.ietf-6lo-fragment-recovery].

[Ballot comment]
As I said, I only had a rather brief read, however, I had a bit of problems to follow exactly which parts of the architecture rely on existing protocols and mechanisms and where 6tsch actually needs to define new approaches. Maybe a short, even higher-level overview than section 3, could address this and help the reader.

[Ballot comment]
Pascal,

Thank you for the hard work put into this document. It is extensive and comprehensive. I really appreciate this well-written document as it is clear (albeit long...), so, the COMMENTs and NITs are to improve the document quality and not as a negative criticism; your reply + comments will be welcome though.

Regards, Bien à toi,

-éric

== COMMENTS ==

-- Section 1 --
Suggest to be more specific about the backbone: layer-2 or IP backbone ?

-- Section 2.1 --
Please define 'PAN' before first use.
The choice of 'ASN' in an IETF document was probably not the choice... ;-)
I was unable to understand the concept and use of layer-2 bundle by reading the definition. Let's hope it is defined/explained later...
It is probably too late to change now, but, this section is really too heavy and by alphabetical order, so, its usefulness is reduced for first-time readers. Section 3 is rather easy to read for similar explanations.

-- Section 3.2 --
For my own curiosity, reducing mcast is always good of course but not critical on the backbone if it is wired Ethernet. So, why mentioning this fact in this memo?

-- Section 3.4 --
Minor inconsistency between the list of the schedule management ways and the enumeration. Nothing critical though but confusing.
In "Neighbor-to-Neighbor Scheduling", perhaps replace "between adjacent routers" by "between adjacent peers" as the text is mainly about peers?

-- Section 3.6 --
It is probably useful to define what "feasable" means in the context of this memo.
Probably too late in the publication process to change, but, I would suggest to use "6LoWPAN Fragments Forwarding" (plural) of even "6LoWPAN Fragments Chain Forwarding".
More a nit but can you re-use the same names in the table at the end of the section? This table should also have a number such as Table 1

-- Section 3.7 --
Figure 4 mentions "to be IEEE Std. 802.15.12"... this is a hint to a IEEE work which should be explained in the text or be removed.

-- Section 3.8 --
The first paragraph would benefit if it was clear that it is about "*difference* between information and data models".
Please define what "duocast" is ;-)

-- Section 4.1.2 --
Its title is just in the reverse order of the previous sentence :-O And, should it mention "colocated" ?

-- Section 4.2.2 --
Is there a difference between "IPv6 ND" in figure 5 and figure 6? It is followed by "NA" "NS" in the latter.

-- Section 4.3.3 --
Please define "ETX" and "LQI" ?

-- Section 4.4 --
Is it on purpose that there is a lot of overlap with section 3.4 ?

-- Section 4.5.3 --
Is it worth to define "PRE" or is DetNet knowledge assumed?

-- Section 4.6 --
Please be consistent with the naming of the sub-sections wrt "three different forwarding model"

-- Section 5 --
Please replace "This specification" by "This document" as it is not aimed to be a Proposed Standard.

-- Section 6 --
"ASN" was not fully described before (except briefly in terminology section), so, I find it weird to build the security section around this concept; moreover, as it comes from DetNet, I would assume that the DetNet documents are more suitable to have this security discussion (with just a point in this memo).


== NITS ==

-- Section 1 --
A comma is probably needed before "Industrial Automation Control Systems (IACS)". Same section could possibly also introduce the 'IT' acronym.
s/require the addition/requires the addition/ ?
s/, e.g., an Ethernet bridged network,/ (e.g. an Ethernet bridged network)/

-- Section 2.1 --
s/:  : /: /

-- Section 3.2 --
s/RPL network needs to share information/RPL network need to share information/ ?

-- Section 3.7 --
s/aloha/Aloha/ ?
The sentence "The reference stack that the 6TiSCH architecture presents was implemented and interop tested" would benefit from a couple of commas.

-- Section 4.3.1.1 --
Duplicate line.
Duplicate line. ;-)

- Section 4.6 --
s/three different forwarding model, /three different forwarding models: /

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) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)?

A: Informational

Q: Why is this the proper type of RFC?

A: This document has inter-IETF Areas and inter-SDO impact, most notably
with IEEE, and having this document be an IETF consensus document is
therefore considered highly important.

Q: Is this type of RFC indicated in the title page header?

A: Yes.


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

A:  This document is the the 6TiSCH architecture of an
  IPv6 Multi-Link subnet that is composed of a high speed powered
  backbone and a number of IEEE802.15.4 TSCH low-power wireless
  networks attached and synchronized by Backbone Routers.  The
  architecture defines mechanisms to establish and maintain routing and
  scheduling in a centralized, distributed, or mixed fashion.

Q: Working Group Summary
A:  The general architectural principles appear to be well supported and understood.  Whilst there have been some controversial discussions within the WG, those have tended to be around potential future implementation decisions rather than with the architecture as a whole.

This document was developed over a period of 5 years. With regular bi-weekly calls with members of the work group.
Minutes and discussions are maintained on etherpad available here:
http://etherpad.tools.ietf.org:9000/p/6tisch?useMonospaceFont=true
For the security section a design team was formed and the proposal of the text in this section was discussed with the work group over the mailer.

This is the base document for the 6tisch work group to build over with requirements to other work groups as well - wg 6lo in particular. There has been collaboration by means of discussions over email and participation by members in the bi-weekly calls to arrive at consensus.

Q: Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification? Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues? If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?

A: There have been two formal WG last calls, with a number of reviewers. The comments and changes are documented as tickets to this document in the tracker.
There have been implementations and interoperability testing at 3 plugfests - at IETF89 London, IETF90 Toronto and another planned for IETF93 Prague.
These plugfests demonstrated inter-operation between different hardware and software implementations of 6TiSCH technology proposed by 6tisch workgroup. The details on the focus of these plugfest can be found in draft-ietf-6tisch-minimal.
This is the first volume of the 6tisch architecture and the claims/proposals presented in this draft are of good quality and can be verified from the outcome of the plugfests.

Personnel

Q:  Who is the Document Shepherd? Who is the Responsible Area
  Director?
A: Document Shepherd: Shwetha Bhandari
A: Responsible AD : Suresh Krishnan

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

A: Document has been reviewed by a number of individuals, 100s of emails exchanged, and 19 versions over 5 years.

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


(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.
A: 6tisch has a large email subscriber base with active members from other SDOs  - IEEE and ETSI and work groups: ROLL, 6LO, but, no, we have not reached out for a community-specific 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.
A: The shepherd has no specific concerns.  The responsible area director has followed this group closely.

(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.
A: Yes.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.
A: Following IPRs are filed:
Cisco  - https://datatracker.ietf.org/ipr/2214/,
Cisco - https://datatracker.ietf.org/ipr/2846/,
Linear Technology - https://datatracker.ietf.org/ipr/2240/

(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? 
A: The WG chairs believe the consensus on what is in this document is solid. Areas of concern have been discussed at length, wordsmithed, and general agreement achieved.

(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.)
A: No.

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

A: Yes - part of the tool submission

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

(13) Have all references within this document been identified as
either normative or informative?
A: 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?
A: No

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.
A: 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.
A: 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).
A: N/A

(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.
A: N/A

(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.
A: N/A

(Via [email protected]): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-6tisch-architecture-20, which is currently in Last Call, and has the following comments:

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

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

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

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2019-06-26):

From: The IESG
To: IETF-Announce
CC: [email protected], [email protected], [email protected], [email protected], [email protected]
Reply-To: [email protected]
Sender:
Subject: Last Call:  (An Architecture for IPv6 over the TSCH mode of IEEE 802.15.4) 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: - 'An Architecture
for IPv6 over the TSCH mode of IEEE 802.15.4'
  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
[email protected] mailing lists by 2019-06-26. Exceptionally, comments may be
sent to [email protected] instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  This document describes a network architecture that provides low-
  latency, low-jitter and high-reliability packet delivery.  It
  combines a high-speed powered backbone and subnetworks using IEEE
  802.15.4 time-slotted channel hopping (TSCH) to meet the requirements
  of LowPower wireless deterministic applications.




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

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

The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/2240/
  https://datatracker.ietf.org/ipr/2214/
  https://datatracker.ietf.org/ipr/2846/

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) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)?

A: Proposed Standard

Q: Why is this the proper type of RFC?

A: This document has inter-IETF Areas and inter-SDO impact, most notably
with IEEE, and having this document be an IETF consensus document is
therefore considered highly important.

Q: Is this type of RFC indicated in the title page header?

A: Yes.


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

A:  This document is the the 6TiSCH architecture of an
  IPv6 Multi-Link subnet that is composed of a high speed powered
  backbone and a number of IEEE802.15.4 TSCH low-power wireless
  networks attached and synchronized by Backbone Routers.  The
  architecture defines mechanisms to establish and maintain routing and
  scheduling in a centralized, distributed, or mixed fashion.

Q: Working Group Summary
A:  The general architectural principles appear to be well supported and understood.  Whilst there have been some controversial discussions within the WG, those have tended to be around potential future implementation decisions rather than with the architecture as a whole.

This document was developed over a period of 5 years. With regular bi-weekly calls with members of the work group.
Minutes and discussions are maintained on etherpad available here:
http://etherpad.tools.ietf.org:9000/p/6tisch?useMonospaceFont=true
For the security section a design team was formed and the proposal of the text in this section was discussed with the work group over the mailer.

This is the base document for the 6tisch work group to build over with requirements to other work groups as well - wg 6lo in particular. There has been collaboration by means of discussions over email and participation by members in the bi-weekly calls to arrive at consensus.

Q: Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification? Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues? If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?

A: There have been two formal WG last calls, with a number of reviewers. The comments and changes are documented as tickets to this document in the tracker.
There have been implementations and interoperability testing at 3 plugfests - at IETF89 London, IETF90 Toronto and another planned for IETF93 Prague.
These plugfests demonstrated inter-operation between different hardware and software implementations of 6TiSCH technology proposed by 6tisch workgroup. The details on the focus of these plugfest can be found in draft-ietf-6tisch-minimal.
This is the first volume of the 6tisch architecture and the claims/proposals presented in this draft are of good quality and can be verified from the outcome of the plugfests.

Personnel

Q:  Who is the Document Shepherd? Who is the Responsible Area
  Director?
A: Document Shepherd: Shwetha Bhandari
A: Responsible AD : Suresh Krishnan

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

A: Document has been reviewed by a number of individuals, 100s of emails exchanged, and 19 versions over 5 years.

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


(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.
A: 6tisch has a large email subscriber base with active members from other SDOs  - IEEE and ETSI and work groups: ROLL, 6LO, but, no, we have not reached out for a community-specific 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.
A: The shepherd has no specific concerns.  The responsible area director has followed this group closely.

(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.
A: Yes.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.
A: Following IPRs are filed:
Cisco  - https://datatracker.ietf.org/ipr/2214/,
Cisco - https://datatracker.ietf.org/ipr/2846/,
Linear Technology - https://datatracker.ietf.org/ipr/2240/

(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? 
A: The WG chairs believe the consensus on what is in this document is solid. Areas of concern have been discussed at length, wordsmithed, and general agreement achieved.

(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.)
A: No.

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

A: Yes - part of the tool submission

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

(13) Have all references within this document been identified as
either normative or informative?
A: 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?
A: No

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.
A: 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.
A: 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).
A: N/A

(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.
A: N/A

(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.
A: N/A

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) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)?

A: Proposed Standard

Q: Why is this the proper type of RFC?

A: This document has inter-IETF Areas and inter-SDO impact, most notably
with IEEE, and having this document be an IETF consensus document is
therefore considered highly important.

Q: Is this type of RFC indicated in the title page header?

A: Yes.


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

A:  This document is the the 6TiSCH architecture of an
  IPv6 Multi-Link subnet that is composed of a high speed powered
  backbone and a number of IEEE802.15.4 TSCH low-power wireless
  networks attached and synchronized by Backbone Routers.  The
  architecture defines mechanisms to establish and maintain routing and
  scheduling in a centralized, distributed, or mixed fashion.

Q: Working Group Summary
A:  The general architectural principles appear to be well supported and understood.  Whilst there have been some controversial discussions within the WG, those have tended to be around potential future implementation decisions rather than with the architecture as a whole.

This document was developed over a period of 5 years. With regular bi-weekly calls with members of the work group.
Minutes and discussions are maintained on etherpad available here:
http://etherpad.tools.ietf.org:9000/p/6tisch?useMonospaceFont=true
For the security section a design team was formed and the proposal of the text in this section was discussed with the work group over the mailer.

This is the base document for the 6tisch work group to build over with requirements to other work groups as well - wg 6lo in particular. There has been collaboration by means of discussions over email and participation by members in the bi-weekly calls to arrive at consensus.

Q: Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification? Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues? If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?

A: There have been two formal WG last calls, with a number of reviewers. The comments and changes are documented as tickets to this document in the tracker.
There have been implementations and interoperability testing at 3 plugfests - at IETF89 London, IETF90 Toronto and another planned for IETF93 Prague.
These plugfests demonstrated inter-operation between different hardware and software implementations of 6TiSCH technology proposed by 6tisch workgroup. The details on the focus of these plugfest can be found in draft-ietf-6tisch-minimal.
This is the first volume of the 6tisch architecture and the claims/proposals presented in this draft are of good quality and can be verified from the outcome of the plugfests.

Personnel

Q:  Who is the Document Shepherd? Who is the Responsible Area
  Director?
A: Document Shepherd: Shwetha Bhandari
A: Responsible AD : Suresh Krishnan

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

A: Document has been reviewed by a number of individuals, 100s of emails exchanged, and 19 versions over 5 years.

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


(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.
A: 6tisch has a large email subscriber base with active members from other SDOs  - IEEE and ETSI and work groups: ROLL, 6LO, but, no, we have not reached out for a community-specific 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.
A: The shepherd has no specific concerns.  The responsible area director has followed this group closely.

(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.
A: Yes.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.
A: Following IPRs are filed:
Cisco  - https://datatracker.ietf.org/ipr/2214/,
Cisco - https://datatracker.ietf.org/ipr/2846/,
Linear Technology - https://datatracker.ietf.org/ipr/2240/

(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? 
A: The WG chairs believe the consensus on what is in this document is solid. Areas of concern have been discussed at length, wordsmithed, and general agreement achieved.

(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.)
A: No.

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

A: Yes - part of the tool submission

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

(13) Have all references within this document been identified as
either normative or informative?
A: 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?
A: No

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.
A: 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.
A: 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).
A: N/A

(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.
A: N/A

(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.
A: N/A

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) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)?

A: Proposed Standard

Q: Why is this the proper type of RFC?

A: This document has inter-IETF Areas and inter-SDO impact, most notably
with IEEE, and having this document be an IETF consensus document is
therefore considered highly important.

Q: Is this type of RFC indicated in the title page header?

A: Yes.


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

A:  This document is the the 6TiSCH architecture of an
  IPv6 Multi-Link subnet that is composed of a high speed powered
  backbone and a number of IEEE802.15.4 TSCH low-power wireless
  networks attached and synchronized by Backbone Routers.  The
  architecture defines mechanisms to establish and maintain routing and
  scheduling in a centralized, distributed, or mixed fashion.

Q: Working Group Summary
A:  The general architectural principles appear to be well supported and understood.  Whilst there have been some controversial discussions within the WG, those have tended to be around potential future implementation decisions rather than with the architecture as a whole.

This document was developed over a period of 5 years. With regular bi-weekly calls with members of the work group.
Minutes and discussions are maintained on etherpad available here:
http://etherpad.tools.ietf.org:9000/p/6tisch?useMonospaceFont=true
For the security section a design team was formed and the proposal of the text in this section was discussed with the work group over the mailer.

This is the base document for the 6tisch work group to build over with requirements to other work groups as well - wg 6lo in particular. There has been collaboration by means of discussions over email and participation by members in the bi-weekly calls to arrive at consensus.

Q: Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification? Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues? If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?

A: There have been two formal WG last calls, with a number of reviewers. The comments and changes are documented as tickets to this document in the tracker.
There have been implementations and interoperability testing at 3 plugfests - at IETF89 London, IETF90 Toronto and another planned for IETF93 Prague.
These plugfests demonstrated inter-operation between different hardware and software implementations of 6TiSCH technology proposed by 6tisch workgroup. The details on the focus of these plugfest can be found in draft-ietf-6tisch-minimal.
This is the first volume of the 6tisch architecture and the claims/proposals presented in this draft are of good quality and can be verified from the outcome of the plugfests.

Personnel

Q:  Who is the Document Shepherd? Who is the Responsible Area
  Director?
A: Document Shepherd: Shwetha Bhandari
A: Responsible AD : Suresh Krishnan

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

A: Document has been reviewed by a number of individuals, 100s of emails exchanged, and 19 versions over 5 years.

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


(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.
A: 6tisch has a large email subscriber base with active members from other SDOs  - IEEE and ETSI and work groups: ROLL, 6LO, but, no, we have not reached out for a community-specific 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.
A: The shepherd has no specific concerns.  The responsible area director has followed this group closely.

(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.
A: Yes.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.
A: Following IPRs are filed:
Cisco  - https://datatracker.ietf.org/ipr/2214/,
Cisco - https://datatracker.ietf.org/ipr/2846/,
Linear Technology - https://datatracker.ietf.org/ipr/2240/

(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? 
A: The WG chairs believe the consensus on what is in this document is solid. Areas of concern have been discussed at length, wordsmithed, and general agreement achieved.

(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.)
A: No.

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

A: Yes - part of the tool submission

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

(13) Have all references within this document been identified as
either normative or informative?
A: 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?
A: No

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.
A: 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.
A: 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).
A: N/A

(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.
A: N/A

(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.
A: N/A

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) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)?

A: Informational RFC

Q: Why is this the proper type of RFC?

A: This is a non-normative architectural document providing design guidelines, not a protocol specification.

Q: Is this type of RFC indicated in the title page header?

A: Yes.


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

A:  This document is the first volume of the 6TiSCH architecture of an
  IPv6 Multi-Link subnet that is composed of a high speed powered
  backbone and a number of IEEE802.15.4 TSCH low-power wireless
  networks attached and synchronized by Backbone Routers.  The
  architecture defines mechanisms to establish and maintain routing and
  scheduling in a centralized, distributed, or mixed fashion.

Q: Working Group Summary
A:  The general architectural principles appear to be well supported and understood.  Whilst there have been some controversial discussions within the WG, those have tended to be around potential future implementation decisions rather than with the architecture as a whole.

This document was developed over a period of 5 years. With regular bi-weekly calls with members of the work group.
Minutes and discussions are maintained on etherpad available here:
http://etherpad.tools.ietf.org:9000/p/6tisch?useMonospaceFont=true
For the security section a design team was formed and the proposal of the text in this section was discussed with the work group over the mailer.

This is the base document for the 6tisch work group to build over with requirements to other work groups as well - wg 6lo in particular. There has been collaboration by means of discussions over email and participation by members in the bi-weekly calls to arrive at consensus.

Q: Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification? Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues? If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?

A: There have been two formal WG last calls, with a number of reviewers. The comments and changes are documented as tickets to this document in the tracker.
There have been implementations and interoperability testing at 3 plugfests - at IETF89 London, IETF90 Toronto and another planned for IETF93 Prague.
These plugfests demonstrated inter-operation between different hardware and software implementations of 6TiSCH technology proposed by 6tisch workgroup. The details on the focus of these plugfest can be found in draft-ietf-6tisch-minimal.
This is the first volume of the 6tisch architecture and the claims/proposals presented in this draft are of good quality and can be verified from the outcome of the plugfests.

Personnel

Q:  Who is the Document Shepherd? Who is the Responsible Area
  Director?
A: Document Shepherd: Shwetha Bhandari
A: Responsible AD : Suresh Krishnan

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

A: Document has been reviewed by a number of individuals, 100s of emails exchanged, and 19 versions over 5 years.

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


(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.
A: 6tisch has a large email subscriber base with active members from other SDOs  - IEEE and ETSI and work groups: ROLL, 6LO, but, no, we have not reached out for a community-specific 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.
A: The shepherd has no specific concerns.  The responsible area director has followed this group closely.

(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.
A: Yes.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.
A: Following IPRs are filed:
Cisco  - https://datatracker.ietf.org/ipr/2214/,
Cisco - https://datatracker.ietf.org/ipr/2846/,
Linear Technology - https://datatracker.ietf.org/ipr/2240/

(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? 
A: The WG chairs believe the consensus on what is in this document is solid. Areas of concern have been discussed at length, wordsmithed, and general agreement achieved.

(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.)
A: No.

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

A: Yes - part of the tool submission

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

(13) Have all references within this document been identified as
either normative or informative?
A: 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?
A: No

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.
A: 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.
A: 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).
A: N/A

(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.
A: N/A

(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.
A: N/A

This document has inter-IETF Areas and inter-SDO impact, most notably
with IEEE, and having this document be an IETF consensus document is
therefore considered highly important

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) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)?

A: Informational RFC

Q: Why is this the proper type of RFC?

A: This is a non-normative architectural document providing design guidelines, not a protocol specification.

Q: Is this type of RFC indicated in the title page header?

A: Yes.


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

A:  This document is the first volume of the 6TiSCH architecture of an
  IPv6 Multi-Link subnet that is composed of a high speed powered
  backbone and a number of IEEE802.15.4 TSCH low-power wireless
  networks attached and synchronized by Backbone Routers.  The
  architecture defines mechanisms to establish and maintain routing and
  scheduling in a centralized, distributed, or mixed fashion.

Q: Working Group Summary
A:  The general architectural principles appear to be well supported and understood.  Whilst there have been some controversial discussions within the WG, those have tended to be around potential future implementation decisions rather than with the architecture as a whole.

This document was developed over a period of 2 years. With regular bi-weekly calls with members of the work group.
Minutes and discussions are maintained on etherpad available here:
http://etherpad.tools.ietf.org:9000/p/6tisch?useMonospaceFont=true
For the security section a design team was formed and the proposal of the text in this section was discussed with the work group over the mailer.

This is the base document for the 6tisch work group to build over with requirements to other work groups as well - wg 6lo in particular. There has been collaboration by means of discussions over email and participation by members in the bi-weekly calls to arrive at consensus.

Q: Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification? Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues? If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?

A: There have been two formal WG last calls, with a number of reviewers. The comments and changes are documented as tickets to this document in the tracker.
There have been implementations and interoperability testing at 3 plugfests - at IETF89 London, IETF90 Toronto and another planned for IETF93 Prague.
These plugfests demonstrated inter-operation between different hardware and software implementations of 6TiSCH technology proposed by 6tisch workgroup. The details on the focus of these plugfest can be found in draft-ietf-6tisch-minimal.
This is the first volume of the 6tisch architecture and the claims/proposals presented in this draft are of good quality and can be verified from the outcome of the plugfests.

Personnel

Q:  Who is the Document Shepherd? Who is the Responsible Area
  Director?
A: Document Shepherd: Shwetha Bhandari
A: Responsible AD : Brian Haberman

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

A: Document has been reviewed by a number of individuals, 100s of emails exchanged, and 8 versions over 2 years.

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


(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.
A: 6tisch i has a large email subscriber base with active members from other SDOs  - IEEE and ETSI and work groups: ROLL, 6LO, but, no, we have not reached out for a community-specific 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.
A: The shepherd has no specific concerns.  The responsible area director has followed this group closely.

(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.
A: Yes.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.
A: Following IPRs are filed:
Cisco  - https://datatracker.ietf.org/ipr/2214/ .
Linear Technology - https://datatracker.ietf.org/ipr/2240/
These disclosures were made before the draft was adopted as a work group document.

(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? 
A: The WG chairs believe the consensus on what is in this document is solid. Areas of concern have been discussed at length, wordsmithed, and general agreement achieved.

(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.)
A: No.

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

A: Yes - part of the tool submission

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

(13) Have all references within this document been identified as
either normative or informative?
A: 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?
A: No

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.
A: 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.
A: 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).
A: N/A

(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.
A: N/A

(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.
A: N/A