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, y...@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 y...@etri.re.kr <mailto:y...@etri.re.kr>
>
>> On Dec 12, 2022, at 7:15 PM, Éric Vyncke via Datatracker <nore...@ietf.org
>> <mailto:nore...@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 - - - - - - - - - - - ->
_______________________________________________
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo
