Hi, Jens, Thanks for the quick response - I'll be fine with what you do in -09.
Spencer On Thu, Dec 15, 2016 at 4:07 PM, Jens Toftgaard Petersen <[email protected]> wrote: > 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
