Re: [6lo] draft-ietf-6lo-mesh-link-establishment-00 (was: Review of draft-kelsey-6lo-mesh-link-establishment)

Regarding the statement, "So it seems like this version of the protocol currently applies only to ZigBee IP and ZigBee NAN and no other standards. If so, I'd suggest making that explicit. There's also the question of other versions of MLE. Is there an issue to tell them apart easily? How would one do that?”

The newest version of MLE describes a technology…a tool to be used by other protocols - I wouldn’t make anything “explicit” about what this version of MLE targets - yeah, certain features were added to support ZigBee-NAN functionality, but other protocols, now or in the future, could possibly use this new version as well.

Randy

> On Mar 30, 2016, at 2:53 PM, Gabriel Montenegro <Gabriel.Montenegro@microsoft.com> wrote:
> 
> <WG chair hat off>
> 
> After Peter's review the abstract's summary of MLE's capabilities was modified. However, section 4 repeats the old language. Suggest aligning with the revised language in the abstract.
> 
> Furthermore, I'd add the clarifications along the lines of what you suggest for the 3 capabilities, namely:
> 
> - on capability #1: This is the primary purpose for MLE.
> - on capability #2: This could be done in lots of ways.  ZigBee IP happened to use MLE.  Removing this functionality would not affect the rest of the protocol.
> - on capability #3: is an optimization to make 1) more efficient.  It isn't strictly necessary.  
> 
> I'm a bit concerned about the lack of clarity in terms of applicability. For example, you say:
> " The draft describes MLE as used in ZigBee IP, not as it is used in Thread.  "
> " the version of MLE described in the draft"
> 
> So it seems like this version of the protocol currently applies only to ZigBee IP and ZigBee NAN and no other standards. If so, I'd suggest making that explicit. There's also the question of other versions of MLE. Is there an issue to tell them apart easily? How would one do that?
> 
> IANA assignments are per IETF Review. For a protocol whose users are a separate organization, this might be too onerous. I would imagine that Specification Required might be easier for other organizations to further develop the protocol while avoiding collisions and further interop issues (https://tools.ietf.org/html/rfc5226#section-4.1). 
> 
> Thanks,
> 
> Gabriel
> _______________________________________________
> 6lo mailing list
> 6lo@ietf.org
> https://www.ietf.org/mailman/listinfo/6lo
> 