Dear Lars Eggert, Thanks for your comments. Please see responses inline bellows.
Cheers, Younghwan Choi ----------------------------------------------- YOUNGHWAN CHOI, Ph.D. Principal Researcher, PEC, ETRI Tel +82-42-860-1429 Fax +82-42-860-5404 Email y...@etri.re.kr <mailto:y...@etri.re.kr> > On Dec 12, 2022, at 9:28 PM, Lars Eggert via Datatracker <nore...@ietf.org> > wrote: > > Lars Eggert has entered the following ballot position for > draft-ietf-6lo-nfc-19: 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/about/groups/iesg/statements/handling-ballot-positions/ > for more information about how to handle 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: > ---------------------------------------------------------------------- > > # GEN AD review of draft-ietf-6lo-nfc-19 > > CC @larseggert > > ## Discuss > > ### Section 9, paragraph 2 > ``` > [LLCP-1.4] "NFC Logical Link Control Protocol, Version 1.4", NFC > Forum Technical Specification , January 2021. > ``` > Eric raised this for -13 in 2019 already: this specification does not > seem to be publicly available? Did the NFC forum share a copy with > the IETF WG that you could forward to the IESG for our review? > I believe the NFC spec is given to all reviewers by email I sent. If you don't have the NFC spec so far. please inform me. > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > ## Comments > > ### Section 3.4, paragraph 7 > ``` > When the MIUX parameter is used, the TLV Type field MUST be 0x02 and > the TLV Length field MUST be 0x02. The MIUX parameter MUST be > encoded into the least significant 11 bits of the TLV Value field. > The unused bits in the TLV Value field MUST be set to zero by the > sender and ignored by the receiver. > ``` > Figure 2 shows that the V field is split into 4 bits and 12 bits, not > 11? Also, the four bits are not zero? You’re right. There is some tyros in the Figure 2. I will revise the “1011” to “zero” in the next version of the draft. In addition, The least significant 11 bits start from 21 to 31. I will revise this in the Figure 2. > > ### DOWNREFs > > DOWNREF `[RFC3756]` from this Proposed Standard to Informational `RFC3756`. > (For IESG discussion. It seems this DOWNREF was not mentioned in the Last Call > and also seems to not appear in the DOWNREF registry.) I will move “RFC3756” from “normative reference” to "informative reference" with a new section of the draft. > > ### Inclusive language > > Found terminology that should be reviewed for inclusivity; see > https://www.rfc-editor.org/part2/#inclusive_language for background and more > guidance: > > * Term `man`; alternatives might be `individual`, `people`, `person` I can’t find the term “man” in the draft. Do you mean the “man” in "Man-In-The-Middle (MITM) attacks” of the Section 7? > > ## Nits > > All comments below are about very minor potential issues that you may choose > to > address in some way - or ignore - as you see fit. Some were flagged by > automated tools (via https://github.com/larseggert/ietf-reviewtool), so there > will likely be some false positives. There is no need to let me know what you > did with these suggestions. > > ### Typos > > #### Section 3.1, paragraph 1 > ``` > - is used for IPv6 over NFC. > - ^^ > + MUST be used for IPv6 over NFC. > + ^^^^^^^ > ``` I agree with you. I will revise this. > > ### Outdated references > > Reference `[RFC3633]` to `RFC3633`, which was obsoleted by `RFC8415` (this may > be on purpose). Thanks for your correction. I will put “RFC8415” instead of “RFC3633" > > ### Grammar/style > > #### Section 4.2, paragraph 4 > ``` > pology. NFC supports mesh topologies but most of all applications would use a > ^^^^ > ``` > Use a comma before "but" if it connects two independent clauses (unless they > are closely connected and short). Thanks for your correction. I will put a comma before “but”. > > ## Notes > > This review is in the ["IETF Comments" Markdown format][ICMF], You can use the > [`ietf-comments` tool][ICT] to automatically convert this review into > individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT]. > > [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md > [ICT]: https://github.com/mnot/ietf-comments > [IRT]: https://github.com/larseggert/ietf-reviewtool > > > >
_______________________________________________ 6lo mailing list 6lo@ietf.org https://www.ietf.org/mailman/listinfo/6lo
