Re: [6lo] Éric Vyncke's Discuss on draft-ietf-6lo-nfc-19: (with DISCUSS and COMMENT)

"yhc@etri.re.kr" <yhc@etri.re.kr> Wed, 04 January 2023 04:11 UTC

Return-Path: <yhc@etri.re.kr>
X-Original-To: 6lo@ietfa.amsl.com
Delivered-To: 6lo@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1927EC15257F for <6lo@ietfa.amsl.com>; Tue, 3 Jan 2023 20:11:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.874
X-Spam-Level:
X-Spam-Status: No, score=-1.874 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NO_DNS_FOR_FROM=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, T_SPF_HELO_TEMPERROR=0.01, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dooray.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Chhhv7hSjZXg for <6lo@ietfa.amsl.com>; Tue, 3 Jan 2023 20:11:45 -0800 (PST)
Received: from mscreen.etri.re.kr (mscreen.etri.re.kr [129.254.9.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D9E5C152585 for <6lo@ietf.org>; Tue, 3 Jan 2023 20:11:29 -0800 (PST)
Received: from unknown (HELO send001-relay.gov-dooray.com) (211.180.235.152) by 129.254.9.16 with ESMTP; 4 Jan 2023 13:11:27 +0900
X-Original-SENDERIP: 211.180.235.152
X-Original-MAILFROM: yhc@etri.re.kr
X-Original-RCPTTO: draft-ietf-6lo-nfc@ietf.org, 6lo@ietf.org, 6lo-chairs@ietf.org, iesg@ietf.org
Received: from [10.162.225.112] (HELO smtp002-imp.gov-dooray.com) ([10.162.225.112]) by send001-relay.gov-dooray.com with SMTP id 93676be663b4fc6f; Wed, 04 Jan 2023 13:11:27 +0900
DKIM-Signature: a=rsa-sha256; b=JkCavmTA9ds0uJrunR8uinkWzRpLFgpnb5W6U635M6RiaW6ZpK7ySHqVyK+SaLg0vWoTvrZdyJ mCAX6+NEvHijlLjbor7K1hTxk+kJJkc2rDtvLTnz+GymcAy+zNf3JOF0cw/iKPXWtj+PerJYSGR/ XCqhCLBNiJn9Hnyxv+REuo3XO3NDgbla5sFNuIIXnx9v4xcpLJrYBzOP7NKhTPhV1uk7AhW+2y1k Q+9PYAH5VO/QT7Dv7V8rVN0ScBYcByMmq6ZrHByHi/lKadk52UKfz4GlLkm4gL3W7YMuNCA2lVK4 8KHlvh3DTGN97Iok9lHqcHRc7lEXf4kO9Sr/eCKQ==; c=relaxed/relaxed; s=selector; d=dooray.com; v=1; bh=0lhsAuFsDQUkRXcG+GDxDK3Af57Vw2p4Vwuibc76tIo=; h=From:To:Subject:Message-ID;
Received: from [129.254.170.125] (HELO smtpclient.apple) ([129.254.170.125]) by smtp002-imp.gov-dooray.com with SMTP id 48eec57263b4fc6e; Wed, 04 Jan 2023 13:11:26 +0900
From: "yhc@etri.re.kr" <yhc@etri.re.kr>
Message-Id: <A42105EB-B07D-4423-A56A-8593A34AC132@etri.re.kr>
Content-Type: multipart/alternative; boundary="Apple-Mail=_FF1E70EB-8426-4521-A425-C92BF2940156"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\))
Date: Wed, 04 Jan 2023 13:11:01 +0900
In-Reply-To: <B7FB7A76-DAE5-46EC-A057-FDEAA8784013@etri.re.kr>
Cc: The IESG <iesg@ietf.org>, draft-ietf-6lo-nfc@ietf.org, 6lo-chairs@ietf.org, 6lo@ietf.org, Samita Chakrabarti <samitac.ietf@gmail.com>, Carles Gomez <carlesgo@entel.upc.edu>, pthubert@cisco.com
To: Éric Vyncke <evyncke@cisco.com>
References: <167084015037.45648.17136765707622403481@ietfa.amsl.com> <B7FB7A76-DAE5-46EC-A057-FDEAA8784013@etri.re.kr>
X-Mailer: Apple Mail (2.3696.120.41.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/xJ-igSay-iCqF7-DDMqhCzKhWP8>
Subject: Re: [6lo] Éric Vyncke's Discuss on draft-ietf-6lo-nfc-19: (with DISCUSS and COMMENT)
X-BeenThere: 6lo@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Mailing list for the 6lo WG for Internet Area issues in IPv6 over constrained node networks." <6lo.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6lo>, <mailto:6lo-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6lo/>
List-Post: <mailto:6lo@ietf.org>
List-Help: <mailto:6lo-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6lo>, <mailto:6lo-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Jan 2023 04:11:52 -0000

Dear Éric Vyncke and all,

I am not sure what is going on my answers. Anyway, my last answer has been cut in the middle.
The whole answer was as like follow:

> 
> ### Section 4.3
> 
> Please use RFC 5952 for IPv6 address format.

Do you mean change the Figure 5 like following?

OLD:

        0          0                  0                          1
        0          1                  6                          2
        0          0                  4                          7
       +----------+------------------+----------------------------+
       |1111111010|       zeros      |    Interface Identifier    |
       +----------+------------------+----------------------------+
       .                                                          .
       . <- - - - - - - - - - - 128 bits - - - - - - - - - - - -> .

NEW:

        0                             0                          1
        0                             6                          2
        0                             4                          7
       +-----------------------------+----------------------------+
       |           0xfe80            |    Interface Identifier    |
       +-----------------------------+----------------------------+


Cheers,
Younghwan

> On Jan 4, 2023, at 12:59 PM, yhc@etri.re.kr wrote:
> 
> Dear Éric Vyncke,
> 
> 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  yhc@etri.re.kr <mailto:yhc@etri.re.kr>
> 
>> On Dec 12, 2022, at 7:15 PM, Éric Vyncke via Datatracker <noreply@ietf.org <mailto:noreply@ietf.org>> wrote:
>> 
>> Éric Vyncke 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/ <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/ <https://datatracker.ietf.org/doc/draft-ietf-6lo-nfc/>
>> 
>> 
>> 
>> ----------------------------------------------------------------------
>> DISCUSS:
>> ----------------------------------------------------------------------
>> 
>> 
>> # Éric Vyncke, INT AD, comments for draft-ietf-6lo-nfc-19
>> CC @evyncke
>> 
>> Thank you for the work put into this document. It could indeed be useful and it
>> would deserve a high quality specification.
>> 
>> Please find below one blocking DISCUSS points (easy to address), some
>> non-blocking COMMENT points (but replies would be appreciated even if only for
>> my own education), and some nits.
>> 
>> Special thanks to Carles Gomez for the shepherd's detailed write-up including
>> the WG consensus *and* the justification of the intended status. But, the
>> write-up is incorrect about the downward reference as
>> https://datatracker.ietf.org/doc/draft-ietf-6lo-nfc/references/ indicates RFC
>> 3756 is a downref...
>> 
>> Please note that Pascal Thubert is the Internet directorate reviewer (at my
>> request) and you may want to consider this int-dir reviews as well when Pascal
>> will complete the review (no need to wait for it though):
>> https://datatracker.ietf.org/doc/draft-ietf-6lo-nfc/reviewrequest/16761/
>> 
>> I hope that this review helps to improve the document,
>> 
>> Regards,
>> 
>> -éric
>> 
>> ## DISCUSS
>> 
>> As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a
>> DISCUSS ballot is a request to have a discussion on the following topics:
>> 
>> ### Tagging of references
>> 
>> I have not checked all references, but at least RFC 3633 should not be
>> normative but only informative.
>> 
>> Moreover, RFC3633 is obsoleted by RFC 8415 for 4 years.
> 
> Thanks for your correction. I will put “RFC8415” instead of “RFC3633"
> 
>> 
>> ### Section 3.4
>> 
>> As far as I understand the document and its relationship with NFC standards,
>> then it is not up to the IETF to use normative language around MIUX (specified
>> by NFC), so, the "MUST" below should rather be "is". ```
>>   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.
>> ```
>> 
>> The "MUST" in `The MIUX value MUST be 0x480 to support the IPv6 MTU requirement
>> (of 1280 bytes).` is of course fine.
>> 
>> Finally, please add a normative reference to RFC 8200.
> 
>  I will put “RFC 8200” in the next version of the draft.
> 
>> 
>> ### Section 4.2
>> 
>> Is this section normative ? There is no BCP14 words in it.
>> 
>> If normative, then how is Network_ID derived from any NFC parameter?
> 
> The Network_ID is derived from SSAP (NFC Link Layer address) of LLCP (NFC Logical Link Layer).
> I will revise the sentence, "NFC Link Layer address (i.e., SSAP) MUST a source of the Net_Iface parameter.” In the Section 4.2
> 
>> 
>> ### Section 4.3
>> 
>> While not really a DISCUSS point, what is the link between DHCP-PD and a LLA ?
>> Remove the part about getting a prefix.
> 
> I will remove the part, "A 6LBR may obtain an IPv6 prefix for numbering the NFC network via DHCPv6 Prefix Delegation ([RFC3633])."
> 
>> 
>> What is a `secured and stable IID` ? Do the authors mean a 'random and stable
>> IID'?
> 
> I revise “ secured and stable IID" to “ random and stable IID”.
> 
>> 
>> ### Section 4.4 and 5
>> 
>> In section 4.4: `NFC supports mesh topologies but ...`
>> 
>> In section 5: `An NFC link does not support a star topology or mesh network
>> topology`
>> 
>> So, is mesh supported or not ?
> 
> NFC supports mesh topologies. I remove the hanging paragraph in Section 5 before Section 5.1. 
> 
>> 
>> ### Section 4.5
>> 
>> Is this section normative ? There is no BCP14 terms.
> 
> Yes It is, I will revise the sentences. 
> 
> OLD: 
> 
> The only sequence currently defined for IPv6-over-NFC is the LOWPAN_IPHC compressed IPv6 header (see Section 4.6) 
> header followed by payload, as depicted in Figure 6.
> 
> NEW:
> 
> The only sequence currently defined for IPv6-over-NFC MUST be the LOWPAN_IPHC compressed IPv6 header (see Section 4.6) 
> header followed by payload, as depicted in Figure 6 & 7.
> 
>> 
>> Is there a IANA registry for "Dispatch" values ? If so, then please add a
>> reference.
> 
> I will put the reference like follows:
> 
> OLD: 
> 
> All IPv6-over-NFC encapsulated datagrams are prefixed by an encapsulation header stack consisting of a Dispatch value. 
> 
> NEW:
> 
> Section 4.5
> 
> All IPv6-over-NFC encapsulated datagrams are prefixed by an encapsulation header stack consisting of a Dispatch value [IANA-6LoWPAN]. 
> 
> Section X.2.  Informative References
> 
>    [IANA-6LoWPAN]
>               IANA, "IPv6 Low Power Personal Area Network Parameters",
>               <https://www.iana.org/assignments/_6lowpan-parameters <https://www.iana.org/assignments/_6lowpan-parameters>>.
> 
> 
>> It *seems* that the length is 1 octet, please specify the length of
>> the value.
> 
> It could be more that 1 octet according to payload. For clarification, I will revise the Figure 6 like following.
> 
> OLD:
> 
> The dispatch value is treated as an unstructured namespace.
> 
> NEW:
> 
> The dispatch value (length: 1 octet) is treated as an unstructured namespace.
> 
>> 
>> ### Section 4.6
>> 
>> Possibly due to my ignorance of RFC 6282, but this document refers to TCP
>> (section 4.1) while RFC 6282 only compresses UDP ?
> 
> I will revise the sentences like following.
> 
> Section 4.1.
> 
> OLD:
>      The adaptation layer for IPv6 over NFC supports neighbor
>      discovery, stateless address auto-configuration, header compression,
>      and fragmentation & reassembly, based on 6LoWPAN.
> 
> NEW:
>      The adaptation layer for IPv6 over NFC supports neighbor
>      discovery, stateless address auto-configuration, header compression,
>      and fragmentation & reassembly, based on 6LoWPAN. Note that 6LoWPAN 
>      eader compression [RFC 6282] does not define header compression for TCP. 
>      The latter can still be supported over IPv6 over NFC, albeit without the performance 
>      optimization of header  compression.
> 
>> Is `6-bit NFC link-layer` the same as the `6-bit SSAP` discussed before ? I
>> guess so but I should not guess but be sure.
>> 
>> ### Section 4.8
>> 
>> Is this section normative about multicast replication ?
> 
> For clarification, I will revise sentences like following.
> 
> OLD:
> The NFC Link Layer does not support multicast. Therefore, packets are always transmitted 
> by unicast between two NFC-enabled devices. Even in the case where a 6LBR is attached to multiple 6LNs, 
> the 6LBR cannot do a multicast to all the connected 6LNs. If the 6LBR needs to send a multicast packet to all its 6LNs, 
> it has to replicate the packet and unicast it on each link. 
> 
> NEW:
> The NFC Link Layer does not support multicast. Therefore, packets are always transmitted 
> by unicast between two NFC-enabled devices. Even in the case where a 6LBR is attached to multiple 6LNs, 
> the 6LBR cannot do a multicast to all the connected 6LNs. If the 6LBR needs to send a multicast packet to all its 6LNs, 
> it has to replicate the packet and unicast it on each link. However, this is not energy-efficient, 
> and the central node, which is battery-powered, must take particular care of power consumption.
> To further conserve power, the 6LBR MUST keep track of multicast listeners at NFC link-level granularity 
> (not at subnet granularity), and it MUST NOT forward multicast packets to  6LNs that have not registered 
> as listeners for multicast groups the packets belong to. In the opposite direction, a 6LN always has to send 
> packets to or through the 6LBR.  Hence, when a 6LN needs to transmit an IPv6 multicast packet, 
> the 6LN will unicast the corresponding NFC packet to the 6LBR.
> 
>> 
>> ### Section 5.1
>> 
>> ```
>>   Two or more 6LNs may be connected with a 6LBR, but each connection
>>   uses a different subnet.
>> ```
>> Unsure whether 'subnet' means 'IPv6 prefix' or 'link' ?
>> 
>> `the 6LBR MUST ensure address collisions do not occur` how can this goal be
>> achieved.
>> 
> 
> For clarification, I would like to revise sentences as bellowing.
> 
> OLD:
> 
> Section 5.1
> 
> Two or more 6LNs may be connected with a 6LBR, but each connection uses a different subnet. 
> The 6LBR is acting as a router and forwarding packets between 6LNs and the Internet. Also, 
> the 6LBR MUST ensure address collisions do not occur and forwards packets sent by one 6LN to another. 
> 
> NEW:
> 
> Section 5.1
> 
> Two or more 6LNs may be connected with a 6LBR, but each connection uses a different subnet. 
> The 6LBR is acting as a router and forwarding packets between 6LNs and the Internet. Also, 
> the 6LBR MUST ensure address collisions do not occur because the 6LNs are connected to the 6LBR like a start topology, 
> so the 6LBR checks whether IPv6 addresses are duplicate or not, since 6LNs need to register their addresses with the 6LBR.
> 
> Section 5.2 (Also, I will put a following new sentence just after Figure 11 in Section 5.2)
> 
> In  multihop (i.e., more complex) topologies, the 6LR can also do the same task, 
> but then Duplicate Address Detection (DAD) requires the extensions for multihop networks such as the ones in [RFC 6775].
> 
>> 
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>> 
>> 
>> ## COMMENTS
>> 
>> ### Shepherd write-up
>> 
>> The write-up is incorrect about the downward reference as
>> https://datatracker.ietf.org/doc/draft-ietf-6lo-nfc/references/ <https://datatracker.ietf.org/doc/draft-ietf-6lo-nfc/references/> indicates RFC
>> 3756 is a downref... Unsure whether this reference to RFC 3756 should be
>> normative though.
> 
> I will move the reference [RFC 3756] from the section of normative reference to the section of informative reference.
> 
>> 
>> ### IEEE 802.15.4
>> 
>> Should there be an informative reference to IEEE Std 802.15.4 ?
> 
> I will put the new reference, [IEEE Std 802.15.4] in the section of informative reference.
> 
>> 
>> ### Section 1
>> 
>> `NFC is often regarded as a secure communications technology, due to its very
>> short transmission range.` More explanations or even a reference would be
>> welcome.
> 
> OLD: 
> 
> NFC is often regarded as a secure communications technology, due to its very short transmission range.
> 
> NEW: 
> 
> NFC has its very short transmission range of 10 cm or less, so the other hidden NFC devices behind outside the range cannot receive NFC signals. Therefore, NFC often regarded as a secure communications technology.
> 
>> ### Section 3.2
>> 
>> Should 'reliable' be qualified ? E.g., does it mean no packet loss ?
> 
> NFC LLCP-1.4 provides connection-oriented communications by itself, so For network layer, it can be reliable.
> 
>> 
>> ```
>>   The LLCP to IPv6 protocol
>>   binding MUST transfer the Source Service Access Point (SSAP) and
>>   Destination Service Access Point (DSAP) value to the IPv6 over NFC
>>   protocol.
>> ```
>> Should this be "to the IPv6 over NFS adaptation later" ?
> 
> You’re right. I will revise that.
> 
> NEW: 
> 
> The LLCP to IPv6 protocol binding MUST transfer the Source Service Access Point (SSAP) and
>  Destination Service Access Point (DSAP) value to the IPv6 over NFC adaptation layer.
> 
>> 
>> ### Section 4.4
>> 
>> There is text for "For sending Router Solicitations and processing Router
>> Advertisements" but what about "receiving RS and sending RA" ?
> 
> I agree with your comment. 
> 
> NEW: 
> 
> For receiving Router Solicitations and sending Router Advertisements, the NFC 6LNs MUST follow Sections 5.3 and 5.4 of [RFC6775]. 
> 
>> 
>> ## NITS
>> 
>> ### kbit/s or kbps
>> 
>> Select one unit and keep using it rather than changing during the document.
> 
> I will use ‘kbps’ only in the document.
> 
>> 
>> ### Hexadecimal presentation
>> 
>> Most IETF drafts use 0x3f rather than 3Fh (really cosmetic). Section 3.4 uses
>> 0x02. Suggest to be consistent.
> 
> I will revise that with “0x3f” in section 3.3.
> 
> OLD: 
> 
> In addition, address values between 20h and 3Fh are assigned by the local 
> LLC as a result of an upper layer service request. Therefore, the address values 
> between 20h and 3Fh can be used for generating IPv6 interface identifiers. 
> 
> NEW: 
> 
> In addition, address values between 0x2 and 0x3f are assigned by the local 
> LLC as a result of an upper layer service request. Therefore, the address values 
> between 0x2 and 0x3f can be used for generating IPv6 interface identifiers. 
> 
>> 
>> ### Section 4.2
>> 
>> I do not see the value of figure 2. Consider removing it.
> 
> Do you mean figure 2 in Section 3.4 (NOT Section 4.2)?
> If so and I have a choice whether removing it or not, I prefer to NOT removing the Figure 2. 
> There have been a lot of discussions about it from the begining.
> The Figure 2 was removed in some versions of this draft because of comments from reviewers.
> However, much more reviewers want to put it back for better understanding. 
> It depicts example for MIUX, I believe the example is useful for better understating NFC characteristics.
> 
>> 
>> ### Section 4.3
>> 
>> Please use RFC 5952 for IPv6 address format.
> 
> Do you mean change the Figure 5 like following?
> 
> OLD:
> 
>         0          0                  0                          1
>         0          1                  6                          2
>         0          0                  4                          7
>        +----------+------------------+----------------------------+
>        |1111111010|       zeros      |    Interface Identifier    |
>        +----------+------------------+----------------------------+
>        .                                                          .
>        . <- - - - - - - - - - - 128 bits - - - - - - - - - - - ->