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"? 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. 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. 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. 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]. ? 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? 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/ 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? 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? _______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
