Subject: Re: [OPSAWG] [6lo] Fwd: Coman Drafts v02

From: <[email-masked]>
Date: Sun, 10 Aug 2014 20:30:57 +0000

Dear All,

I'm working in 6TiSCH WG. I read both your documents. They are well written and address the scope quite well.

These are my minor comments:
Both of these two documents do not specify the protocol that can be used by the central manager to access the nodes in the network and manipulate their management information base.

-Pouria
---------- Forwarded message ----------
From: Thomas Watteyne <[email-masked]<mailto:[email-masked]>>
Date: Sat, Jul 26, 2014 at 10:32 PM
Subject: Fwd: [6lo] Fwd: [OPSAWG] Coman Drafts v02
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>

All,

The OPSWAG chairs have kindly agreed to extend the WGLC period for the following drafts [1] to August 11:

http://tools.ietf.org/html/draft-ietf-opsawg-coman-use-cases-02
http://tools.ietf.org/html/draft-ietf-opsawg-coman-probstate-reqs-01

Pascal and myself believe those two drafts to be important for the ongoing work on managing a 6TiSCH network, and directly in line with e.g. draft-ietf-6tisch-coap. We therefore ask authors of draft-ietf-6tisch-coap, draft-ietf-6tisch-6top-interface, and any other 6TiSCH WG member to send reviews of this document to OPSAWG ML [2].

Thomas

[1] http://www.ietf.org/mail-archive/web/6tisch/current/msg02465.html
[2] https://www.ietf.org/mailman/listinfo/opsawg

---------- Forwarded message ----------
From: Warren Kumari <[email-masked]<mailto:[email-masked]>>
Date: Fri, Jul 25, 2014 at 3:03 PM
Subject: Re: [coman] FW: [OPSAWG] Coman Drafts v02
To: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>"
<[email-masked]<mailto:[email-masked]>>

Hi all.

With apologies to the authors...

The chairs of 6LoWPAN and 6TSCH have asked if we can delay the end of
this WGLC so that their communities can review and comment on these 2
documents.

As we have not received very much feedback, this seems relevant to
their WGs, and they asked nicely, we have decided to extend the
deadline to August 11th.

Now, many folk will be traveling back to their homes over the next few
days - this probably means a few, or many hours on an airplane. May I
suggest copying these documents on your computer or reading device of
choice and reviewing the documents on the way home?

Thanks,
W
_______________________________________________
6lo mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/6lo

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 12 Aug 2014 00:36:38 +0200

I did a cursory review of the Coman drafts.

These consolidate a rather useful body of knowledge, even if it is still in flux in many areas.
It may be more important to get them published in some state, with an explicit qualification of being somewhat work in progress, than trying to further polish them until nothing of substance is left.  My strong recommendation here would be: if in doubt, publish.

The most important aspect that probably needs to be expanded is the security considerations, with a view to resiliency.  Not having a management interface is a security liability.  Adding one is an even greater security liability.
Instead of trying to say what is needed here in my imperfect words, I’d like to refer to the discussion under number (5) in http://geer.tinho.net/geer.blackhat.6viii14.txt

In a related vein, many of the coman-specific management issues stem from the peculiar lifecycles the devices go through.
draft-garcia-core-security is the best document we have about this aspect, and the two coman documents probably should be developed in unison with this one.

It is not always easy to separate “constrained network” considerations from “constrained node network” considerations, and probstate might benefit from one more editing round to get the right focus in the right places. (Adding another unfocused term, LLN, and alternating back and forth, does not help.)  A related editorial problem is the usage “non-constrained” (which of course is physically impossible) — in RFC 7228 we missed coming up with good terminology for what we mean by less-constrained or affluent systems.
But these are more general editorial problems, and it is maybe too much to expect them being solved here.

I support Thomas’ comment on the use of the term “requirement”.
The definition of “Priority” in Section 3 of probstate, where a requirement suddenly becomes less important just because it happens to be impossible to fulfill, is a symptom of this.

Editorially, the requirements list would become less tedious if Requirement Type, Device Type, and Priority could be put into tabular form, maybe together with Req-ID.

2.002 does not mention the cost of copying and maybe should.
2.003 may be a bit optimistic about “compression” (as opposed to concise representation in the first place), but then this term isn’t really defined anyway.

A major problem with using classical network management thinking for constrained devices is that, for these, there may be little difference between network and application configuration, including firmware updating.

There are some actual “requirements” (6.*, 9.001 — which is “medium” priority???); it may be worth calling them out.
I don’t understand 10.004 vs. 6.* — while secure message transport is a good choice in many cases, it is ultimately there to support security objectives.

A great aspect of the use-case document is that it calls out the management responsibility for some of the use cases; this should always be done.  It would be good to know in which cases that responsibility is clearly separable from the application responsibilities (in the way network management has been traditionally).
“Medical Applications” is not a use case, it is a whole universe of use cases, and one or two should be included as their own use cases (e.g., separating a BYOD/personal interest case from a professional/healthcare use case).

I’m sorry for throwing out all these observations in front of the authors; again, if in doubt: publish, but maybe expand on some of these observations in a “future work” section.

Grüße, Carsten