Dear John Scudder, 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 14, 2022, at 12:26 AM, John Scudder via Datatracker <nore...@ietf.org> > wrote: > > John Scudder has entered the following ballot position for > draft-ietf-6lo-nfc-19: Abstain > > 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/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > # John Scudder, RTG AD, comments for draft-ietf-6lo-nfc-19 > CC @jgscudder > > This document seems promising and needed, but as noted below, I think it still > needs work before it should advance. I support Lars's DISCUSS -- as noted > below, lack of the foundational Normative reference prevented me from being > able to complete a meaningful review of this document. I notice this point was > raised in a DISCUSS by Eric Rescorla in 2019, I'm surprised it hasn't been > addressed. I do see in the shepherd write-up that "Access to the NFC spec has > been available for those that have needed it" but regrettably, it's not clear > how this is accomplished. > > ## COMMENTS > > ### General > > I agree with Warren's observation that "it doesn't seem like [the document] > contains enough information to allow a full implementation". Addressing the > specific comments below would be helpful, but not sufficient to address that > concern, but lacking the [LLCP-1.4] spec it's difficult to be more specific. > Because I feel unable to properly evaluate the document's fitness, I'm > balloting ABSTAIN. I’m sorry for that. I have shared the the LLCP-1.4 spec to all reviewers. If you don’t have it so far, please inform me. > > The shepherd write-up tells us that "An implementation of 6lo-NFC exists and > they participated on a 6lo plugtests". I can only guess that the implementors > benefit from being experts who know what to read between the lines, whereas > reviewers such as myself can read only what's written in the document. > > ### Section 3.2, remove "such as" > > "The LLC contains three components, such as Link Management, > Connection-oriented Transmission, and Connectionless Transmission." > > The "such as" seems wrong here. I guess you mean "namely", or you could just > remove "such as" and not replace it with anything. I agree with you. I will remove “such as” in the next version of the draft. > > ### Section 3.4, "transported to an I PDU" > > "As mentioned in Section 3.2, when an IPv6 packet is transmitted, the packet > MUST be passed down to LLCP of NFC and transported to an I PDU of LLCP of the > NFC-enabled peer device." > > Do you mean "... and transported in an I PDU of LLCP *to* the NFC-enabled peer > device"? > > ### Section 3.4, mystery bits 1011 > > Figure 2 shows a field, labeled "1011", occupying bits 16 through 21. It's not > clear what this means. It's not discussed in the text. One might imagine it's > just a field value mandated by [LLCP-1.4], but in that case one would imagine > it would depict a 6-bit string, since the field it's occupying is six bits. > What is going on there? I would refer to [LLCP-1.4] to try to find out, but as > mentioned, it isn't available for review. > > What's more, the labeling appears to conflict with the text that says "the > unused bits in the TLV Value field MUST be set to zero". I agree with your point. The MIUX parameter MUST be encoded into the least significant 11 bits of the TLV Value field. So, the most significant 5 bits MUST be zero. I intended to show an example of MIUX, but there was something typo in there. “1011” MUST be revised to “00000b” or just “zero”. And “0x0~0x7FF” will be revised to “MIUX” in the next version of the draft. > > ### Section 3.4, how to fit eleven bits into a ten bit field > > Still in Figure 2, we see the rightmost field labeled 0x0~0x7FF, and the > paragraph following agrees that the field "MUST be encoded into the least > significant 11 bits". But the ruler at the top shows the field extending from > bit 22 to bit 31, a field of only 10 bits. > > My guess is you drew the ruler wrong, and it was supposed to start at bit 21? > But that would still leave the previous "1011" question open. You’re right. The least significant 11 bit starts from 21 to 31. I will revise this in the Figure 2. > > ### Section 3.4, MUST be 0x480 > > "The MIUX value MUST be 0x480 to support the IPv6 MTU requirement (of 1280 > bytes)" unambiguously mandates that MIUX must be exactly 0x480, no more and no > less. I understand the "no less" part, as noted in the quote this is needed to > support a 1280 byte MTU. However, IPv6 doesn't forbid offering a larger value > than 1280. > > I'm guessing you left out an "at least", as in "MUST be at least 0x480". If > you > really intend to mandate that packets shall be no larger than 1280, please say > why? I will revise it to "The MIUX value MUST be at least 0x480”. > > ### Section 4.3 et seq, 6LBR, 6LR, 6LM > > Please expand 6LBR, 6LR, 6LM on first use. I will revise expansion of “6LBR, 6BR, 6LM” on the first use in the draft. > > ### Section 4.4, bullet 2 is hard to understand > > I gave up trying to understand what this bullet means, I'm afraid I can't even > hazard a guess at a rewrite. :-( I will rewrite the bullets for better understanding. > > ## NITS > > ### Section 7 > > "(i.e., ad-hoc mode and authenticated mode" > ^ does the missing closing > parenthesis go here? Thanks for your correction. "(i.e., ad-hoc mode and authenticated mode)” is right. :) > > ## 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. > > [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md > [ICT]: https://github.com/mnot/ietf-comments > > > >
_______________________________________________ 6lo mailing list 6lo@ietf.org https://www.ietf.org/mailman/listinfo/6lo
