Dear Adam Roach, I am going to produce a new version of the draft (-14) this week. Thanks again.
BRs, Younghwan > -----Original Message----- > From: Adam Roach <[email protected]> > Sent: Wednesday, June 26, 2019 10:08 AM > To: 최영환 <[email protected]>; The IESG <[email protected]> > Cc: [email protected]; Carles Gomez <[email protected]>; > Samita Chakrabarti <[email protected]>; [email protected]; > [email protected] > Subject: Re: Adam Roach's Discuss on draft-ietf-6lo-nfc-13: (with DISCUSS > and COMMENT) > > On 6/25/19 6:17 PM, 최영환 wrote: > > Dear Adam Roach, > > > > Thanks for your feedback. > > Please find the answer inline bellows. > > > > BRs, > > Younghwan > > > >> -----Original Message----- > >> From: Adam Roach <[email protected]> > >> Sent: Wednesday, June 26, 2019 2:06 AM > >> To: 최영환 <[email protected]>; The IESG <[email protected]> > >> Cc: [email protected]; Carles Gomez > >> <[email protected]>; Samita Chakrabarti > >> <[email protected]>; [email protected]; [email protected] > >> Subject: Re: Adam Roach's Discuss on draft-ietf-6lo-nfc-13: (with > >> DISCUSS and COMMENT) > >> > >> Sorry for the relatively slow response. Comments inline. > >> > >> On 6/7/19 3:01 AM, 최영환 wrote: > >>>> ------------------------------------------------------------------- > >>>> -- > >>>> - > >>>> DISCUSS: > >>>> ------------------------------------------------------------------- > >>>> -- > >>>> - > >>>> > >>>> Thanks to everyone who has worked on this document. > >>>> > >>>> I generally agree with Benjamin's discuss points, and in particular > >>>> agree with his comment that it's kind of hard to figure out how all > >>>> these pieces work together. I have an additional issue that is > >>>> somewhat related to some of the points he raised, but which is (I > >>>> think) > >> not completely covered. > >>>> I'm really confused about what the purported privacy properties of > >>>> this protocol are. In section 4.3 (which I *think* talks about > >>>> globally- routable IP addresses, although this is a bit unclear), > >>>> the > >> document says: > >>>> such an IID SHOULD guarantee a stable IPv6 address > >>>> because each data link connection is uniquely identified by the > pair > >>>> of DSAP and SSAP included in the header of each LLC PDU in NFC > >>>> > >>>> (Aside: this "should" is a simple statement of fact, not a > >>>> described behavior of the protocol, and so the use of > >>>> RFC-2119-style all-caps is not > >>>> appropriate.) > >>> Agreed. I will fix it. > >>> > >>>> The presence of "a stable IPv6 address" inherently implies the > >>>> ability to track devices. > >>> Agreed. I will change them with "a secured and stable IPv6 address". > >> This is ok? > >> > >> > >> I don't think this changes the issue. Your response below implies > >> that the address is stable only over very short periods of time, and > >> that would address my concern. If that's true, then the solution > >> would be to add text here that qualifies how long the address is stable > (e.g.: > >> "...such an IID should guarantee a stable IPv6 address during the > >> course of a single connection, because...") > >> > > I got it. I will put the text. Thanks for your comment again. > > > Thanks! I'll clear my discuss once the new version is submitted. > > /a _______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
