Subject: Re: [6lo] Comments on draft-ietf-6lo-dect-ule-00

From: Jens Toftgaard Petersen <[email-masked]>
Date: Thu, 22 Jan 2015 22:07:06 +0000

Hi Ralph,

Thanks for reviewing the draft and providing valuable feedback. The changes will be implemented in a new revision of the draft that soon will be uploaded. See my inline comments below.

Thanks and best regards,
  Jens

-----Original Message-----
From: 6lo [mailto:[email-masked]] On Behalf Of Ralph Droms (rdroms)
Sent: 6. november 2014 20:22
To: [email-masked] WG
Subject: [6lo] Comments on draft-ietf-6lo-dect-ule-00

I have a few comments on draft-ietf-6lo-dect-ule-00.  Additional review and comment welcome...  

Content:

I'm curious about why the specification goes in to specifics about the use of various forms of RFC 6282 header compression.  Would it be sufficient to specify that IPv6-over-DECT ULE uses RFC 6282 header compression and leave it to the deployment to choose the forms of compression in use?  Are there any details about the use of RFC 6282 header compression that should be noted as specific to IPv6-over-DECT ULE.
[jens]: Three reasons mainly: 1.: DECT-ULE is star topology and we want to be specific on the features in RFC6282 that is used. 2.: We want to mandate compression of headers with address elision as much as possible. Just stating that RFC6282 shall be used leaves the possibility of not compression at all. Also, mandating some of RFC6282's features removes the need to implement the alternative ones, allowing for simpler coder. 3.: Our layer 2 address is not an IEEE MAC-48 address. Therefore, RFC6282 is not enough to describe the full process of address elision. We have to go through the Neighbour Cache to reconcile Device Address and IID (the same applies to BT-LE in the general case). However, we can probably optimize and compress some of the text and add some more references to RFC6282.

In section 3.2.4, does this document specify that the link-local IPv6 addresses are to be entirely elided, or compressed (which turns out to be elided except for the RFC 6282 header bits)?
[jens]: The intention is that link-local addresses are entirely elided. I will check the wording in the description.

This document may need to make some mention of draft-ietf-6man-default-iids, depending on the progress of that document through the 6man WG.
[jens]: Agreed, it would be appropriate to mention draft-ietf-6man-default-iids. Will be implemented in next revision.

Editorial:

In section 3.2.3, the use of "unicast" and "multicast" wasn't clear to me; specifically when do those terms apply to L2 and L3.
[jens]: Agreed when reading with fresh eyes. The description will be changed and rephrased. 

Section 2.1, para 5: s/Depending of/Depending on/
[jens]: Ok

Section 3.2, para 1: I suggest simply writing out FAR rather than using the abbreviation.
[jens]: Agreed, will be implemented in next revision

Perhaps define 6LBR and 6LN in section 1.2 rather than in-line?
[jens]: Agreed, will be implemented in next revision

_______________________________________________
6lo mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/6lo