IPv6 over the TSCH mode of IEEE 802.15.4e

Note: This ballot was opened for revision 01-00 and is now closed.

Ballot question: "Is this charter ready for external review?"

(Brian Haberman) Yes

Alvaro Retana Yes

Comment (2016-01-18 for -01-00)
No email
send info
I would like to see the related WGs specifically mentioned (not just a general reference to areas).

(Jari Arkko) No Objection

(Alia Atlas) No Objection

Deborah Brungard No Objection

(Ben Campbell) No Objection

(Benoît Claise) No Objection

Comment (2016-01-21 for -01-00)
No email
send info
Not a block, but I would like to discuss the "OPS" situation in the charter/WG.

Looking at this paragraph:
- Produce an Information Model containing the management requirements
of a 6TiSCH node. This includes describing how an entity can manage the
TSCH schedule on a 6TiSCH node, and query timeslot information from that
node. A data model mapping for an existing protocol (such as Concise
Binary Object Representation (CBOR) over the Constrained Application
Protocol (CoAP)) will be provided. This work depends on the standardization of a
method to access management data resources in constrained devices, such as
proposed by CoMI or COOL.

I wonder if this paragraph is still accurate?
There is  this WG document, for a YANG data model, https://tools.ietf.org/html/draft-ietf-6tisch-6top-interface-04, on which I commented during one of the interim call.  So the YANG model should be specifically mentioned.
Also, will the WG still produce an information model? If not, "information model" should be removed

Alissa Cooper No Objection

(Spencer Dawkins) No Objection

(Stephen Farrell) No Objection

Comment (2016-01-21 for -01-00)
No email
send info
This talks about doing security work for bootstrap which is
great, and also about allowing scheduling information to 
be updated/distributed. Would I be correct in assuming that
it needs to be possible for the schedule updates to be as
secure as the bootstrap? I hope so, anyway.  Not sure if
this needs to be stated in the charter though. (Well, if
the answer is "no, updates never need security" then I
think the opposite should be stated in the charter:-)

(Joel Jaeggli) No Objection

Barry Leiba No Objection

(Terry Manderson) No Objection

(Martin Stiemerling) No Objection