Re: [6lo] Adam Roach's Discuss on draft-ietf-6lo-nfc-13: (with DISCUSS and COMMENT)

[최영환 <[e-mail]>]

Hello Adam and all,

Thanks for your valuable reviews.
Please find my answers inline.

BRs,
Younghwan Choi

> -----Original Message-----
> From: Adam Roach via Datatracker <[e-mail]>
> Sent: Thursday, March 14, 2019 9:04 AM
> To: The IESG <[e-mail]>
> Cc: [e-mail]; Carles Gomez 
> <[e-mail]>; Samita Chakrabarti <[e-mail]>; 
> [e-mail]; [e-mail]; [e-mail]
> Subject: Adam Roach's Discuss on draft-ietf-6lo-nfc-13: (with DISCUSS 
> and
> COMMENT)
> 
> Adam Roach has entered the following ballot position for
> draft-ietf-6lo-nfc-13: Discuss
> 
> 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-nfc/
> 
> 
> 
> ----------------------------------------------------------------------
> 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?

> 
> Then, in section 7, I find the following text:
> 
> 
>    ...the short address of
>    NFC link layer (LLC) is not generated as a physically permanent value
>    but logically generated for each connection.  Thus, every single
>    touch connection can use a different short address of NFC link with
>    an extremely short-lived link.
> 
> This text seems to imply that addressing information is, in general, 
> not stable, which appears to flatly contradict the text in section 4.3.
> 
> Please clarify, in section 4.3, what the duration of stability of 
> these identifiers is.

This texts means "NFC applications use short-lived connections, and the every connection is made with different address." 
Just one permanent address is not used for a NFC device. If it looks like the texts appears to flatly contract the texts in section 4.3, I need to rephrase the texts for clarification. Thanks. It's good point, I think.

> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> ID Nits reports:
> 
>   == Unused Reference: 'RFC4291' is defined on line 697, but no explicit
>      reference was found in the text

Thanks. I will get rid of the reference.

> 
> ----------------------------------------------------------------------
> ----
> -
> 
> §1:
> 
> >  IPv6 is an ideal internet
> >  protocols owing to its large address space
> 
> Nit: "protocol"
> 

Thanks. I will fix it.