Hi Spencer, Many thanks for your review. See my comments and answer below inline.
Best regards, Jens -----Original Message----- From: Spencer Dawkins [mailto:[email protected]] Sent: 14. december 2016 07:57 To: The IESG <[email protected]> Cc: [email protected]; Samita Chakrabarti <[email protected]>; [email protected]; [email protected]; [email protected] Subject: Spencer Dawkins' No Objection on draft-ietf-6lo-dect-ule-08: (with COMMENT) Spencer Dawkins has entered the following ballot position for draft-ietf-6lo-dect-ule-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-6lo-dect-ule/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I really appreciate the authors taking time to provide this much background for their specification. I did finish with some questions and comments, but if I understood the technology better, I'd be balloting Yes. Could I suggest replacing "an elderly pendant (brooch)" with "a pendant (brooch) for the elderly"? [Jens]: Ok, I will change that. Because I was already picturing a very old brooch, I also misread "Generic Access Profile" as "Geriatric Access Profile" further down the page, but there's nothing you can do to fix that ;-) In this text, The used application protocol is negotiated between the PP and FP when the PVC communication service is established. I think you can delete "used", unless "used application protocol" is a term of art for DECT-ULA. [Jens]: Yes, better wording to delete "used". In this text, A FP is assumed to be less constrained than a PP. Hence, in the primary scenario FP and PP will act as 6LBR and a 6LN, respectively. This document only addresses this primary scenario and all other scenarios are out of scope. Does "all other scenarios" just mean "scenarios where FPs are more constrained than PPs"? If so, that might be clearer. [Jens]: The text is made more clear in revision -09. In this text, In consequence, the mesh header defined in [RFC4944] for mesh under routing are not used in DECT ULE networks. the term "mesh under routing" doesn't appear in RFC 4944. Did this mean something like "mesh underlay routing"? But if the point is that the mesh header defined in RFC 4944 isn't used, that's probably all you need to say. [Jens]: You are right there is no definition of "mesh under routing". Your suggestion will be implemented in the new revision -09 In this text, Although the TPUI is temporary by definition, the same value is usually repeatedly assigned to any given PP, hence it seems not suitable for construction of IID, see [I-D.ietf-6lo-privacy-considerations]. is this saying Although the TPUI is temporary by definition, many implementations assign the the same value repeatedly to any given PP, hence it seems not suitable for construction of IID, see [I-D.ietf-6lo-privacy-considerations]. [Jens]: Ok, for better wording in new revision -09 ? This may be my own lack of knowlesge at fault, but I'm not sure I understand this text, It is expected that the LOWPAN_IPHC packet will fulfil all the requirements for header compression without spending unnecessary overhead for mesh addressing. I'm guessing that the point is that you don't have to put the mesh header in, to make header compression perform acceptably. Is that it? [Jens]: Correct, the wording is changed in new revision -09 I think The DECT ULE implements already fragmentation and reassembly functionality, hence [RFC4944] fragmentation and reassembly function MUST NOT be used. should s/implements already/already implements/ [Jens]: Done in new revision -09 Probably for my own education, but in this text Globally uniqueness of IID in link-local addresses are not required as they should never be leaked outside the subnet domain. if those addresses are leaked, does IPv6 Duplicate Address Detection prevent the obvious problems? [Jens]: What we had in mind was to mention that link-local addresses should never be exposed outside the local domain, for example by application protocols or other means. Obviously Duplicate Address Detection will not detect any such situation. Could you add a few words explaining why The DECT MAC layer broadcast service is considered inadequate for IP multicast. so the reader isn't left to guess? [Jens]: Yes, is done in the new revision -09 _______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
