Re: [6tisch] last call for draft-ietf-6tisch-minimal-04

Hi Xavier:

Brief feedback on your feedback below:

Best regards, Rene

On 12/19/2014 12:17 PM, Xavier Vilajosana wrote:
> Hi Rene,
>
> thanks you very much for the comments. See inline please.
>
> 1) several clauses of the draft reproduce information that is also 
> contained in the 802.15.4e-2012 specification. There should be some 
> verbiage that, in case of discrepency, the 802.15.4 specification is 
> "leading". This is esp. important if one decides to move towards 
> another update of 802.15.4.
>
> that's a good point. I will add that. Thanks.
>
> 2) I am still concerned about the TSCH mode, Join priority language 
> (which, I think, 6tisch should ignore or, at least, make optional). 
> Currently, e.g., the join priority parameter text seems to make random 
> installation order very hard (see also email correspondence with Peter 
> van der Stok, Tue-Wed Dec 16-17, 
> 2014,http://www.ietf.org/mail-archive/web/roll/current/msg09039.html)
>
> Minimal is not inteded to support all possible modes of operation. We 
> are recommending a defined procedure to ensure everybody joins a 
> network in a certain manner. Being less restrictive or more open would 
> lead to different interpretations which is what we want to avoid.
RS>> that should work if the idea is to generate more "minimal" drafts 
should some of the non-tree-shape enrolment orders be considered at some 
later moment in time. You may wish to add a cautionary note here.
<<RS
>
> 3) Shouldn't one have some language in the draft about how enhanced 
> beacons are to be secured?
>
> We follow 15.4e specification. We assume nodes know the key. Maybe we 
> should make clear that. Would that in your opinion be fine?
RS>>
The 802.15.4e specification has lots of configuration parameter 
settings. Perhaps, one should add something to the effect that enhanced 
beacons are only authenticated (we do not have too much choice here, 
since 802.15.4e puts some of the IE Fields into the payload, even though 
these would have more logically fitted into the header (since processed 
by the MAC without higher layer interference), so encrypting the payload 
does not work with the current 802.15.4e spec). If you believe we should 
simply remain silent on this and being silent on this would not cause 
trouble, please let me know.
<<RS
> 4) Shouldn't one add some language as to how one deals with 
> conflicting ASN entries from more than one beacon (e.g., if 
> NUM_NEIGHBOURS_TO_WAIT is larger than one)?
>
> That's a good point. I´ll check that too.
RS>> Please let me know offline if you have some suggestions (I have 
been looking into lots of mismatch recovery scenario mechanisms lately, 
of which this is one). Technically, it perhaps is not strictly a 
"minimal draft" issue, so if we should tackle the issue elsewhere, 
please let me know. No matter where one puts this, it does require 
thought, though.
<<RS
>
> 5) Change Clause 8, as follows:
>
>     [OLD]
>     Key distribution is out of scope of this document, but examples
>     include pre-configured keys at the nodes, shared keys amongst
>     peers or well-known keys. Refer to
>     the 6TiSCH architecture document [I-D.ietf-6tisch-architecture]
>     for further details on security aspects
>
>     [NEW]
>     Key distribution is out of scope of this document. Refer to the
>     6TiSCH architecture document [I-D.ietf-6tisch-architecture] for
>     further details on security aspects
>
> thank, I agree with that proposal. I will amend it.
>
> regards,
> Xavi
>
>
> 2014-12-19 16:56 GMT+01:00 Rene Struik <rstruik.ext@gmail.com 
> <mailto:rstruik.ext@gmail.com>>:
>
>     Hi Pascal:
>
>     Some brief feedback:
>     1) several clauses of the draft reproduce information that is also
>     contained in the 802.15.4e-2012 specification. There should be
>     some verbiage that, in case of discrepency, the 802.15.4
>     specification is "leading". This is esp. important if one decides
>     to move towards another update of 802.15.4.
>     2) I am still concerned about the TSCH mode, Join priority
>     language (which, I think, 6tisch should ignore or, at least, make
>     optional). Currently, e.g., the join priority parameter text seems
>     to make random installation order very hard (see also email
>     correspondence with Peter van der Stok, Tue-Wed Dec 16-17, 2014,
>     http://www.ietf.org/mail-archive/web/roll/current/msg09039.html)
>     3) Shouldn't one have some language in the draft about how
>     enhanced beacons are to be secured?
>     4) Shouldn't one add some language as to how one deals with
>     conflicting ASN entries from more than one beacon (e.g., if
>     NUM_NEIGHBOURS_TO_WAIT is larger than one)?
>     5) Change Clause 8, as follows:
>
>         [OLD]
>         Key distribution is out of scope of this document, but
>         examples include pre-configured keys at the nodes, shared keys
>         amongst peers or well-known keys. Refer to
>         the 6TiSCH architecture document
>         [I-D.ietf-6tisch-architecture] for further details on security
>         aspects
>
>         [NEW]
>         Key distribution is out of scope of this document. Refer to
>         the 6TiSCH architecture document
>         [I-D.ietf-6tisch-architecture] for further details on security
>         aspects
>
>     Rene
>
>
>     On 12/12/2014 1:40 PM, Pascal Thubert (pthubert) wrote:
>>     Dear all:
>>
>>     As discussed at the interim meeting last week, it is now time to last call a number of drafts that the group produced over the course of the last 2 years.
>>     This call is the first of a series, and is about the TSCH drafthttp://tools.ietf.org/html/draft-ietf-6tisch-minimal-04    .
>>     The call will last for one week and the conclusion will be discussed at the interim call on Friday 19-Dec-2014;
>>     please express support or concerns about the publication of this work, which is originally aimed at informational status.
>>
>>     Cheers,
>>
>>     Pascal and Thomas
>>
>>     _______________________________________________
>>     6tisch mailing list
>>     6tisch@ietf.org  <mailto:6tisch@ietf.org>
>>     https://www.ietf.org/mailman/listinfo/6tisch
>
>
>     -- 
>     email:rstruik.ext@gmail.com  <mailto:rstruik.ext@gmail.com>  | Skype: rstruik
>     cell:+1 (647) 867-5658  <tel:%2B1%20%28647%29%20867-5658>  | US:+1 (415) 690-7363  <tel:%2B1%20%28415%29%20690-7363>
>
>
>     _______________________________________________
>     6tisch mailing list
>     6tisch@ietf.org <mailto:6tisch@ietf.org>
>     https://www.ietf.org/mailman/listinfo/6tisch
>

-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363