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

["Eric Vyncke (evyncke)" <[e-mail]>]

Thanks for the -20. As you have seen by now, I have cleared my previous blocking DISCUSS as the points have been addressed.

Regards

-éric


From: Eric Vyncke <[e-mail]>
Date: Thursday, 5 January 2023 at 07:59
To: "[e-mail]" <[e-mail]>
Cc: The IESG <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, Samita Chakrabarti <[e-mail]>, Carles Gomez <[e-mail]>, Pascal Thubert <[e-mail]>
Subject: Re: Éric Vyncke's Discuss on draft-ietf-6lo-nfc-19: (with DISCUSS and COMMENT)

It seems that all your newly proposed changes will address my DISCUSS and COMMENT points.

I will clear my DISCUSS ballot as soon as a revised I-D with the changes is uploaded.

Regards and thanks again for your work,

-éric

From: "[e-mail]" <[e-mail]>
Date: Thursday, 5 January 2023 at 06:07
To: Eric Vyncke <[e-mail]>
Cc: The IESG <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, Samita Chakrabarti <[e-mail]>, Carles Gomez <[e-mail]>, Pascal Thubert <[e-mail]>
Subject: Re: Éric Vyncke's Discuss on draft-ietf-6lo-nfc-19: (with DISCUSS and COMMENT)

Dear Éric Vyncke,

Many thanks for you quick response.
Please find my answers bellow:

Best regards,
Younghwan Choi

On Jan 4, 2023, at 6:38 PM, Eric Vyncke (evyncke) <[e-mail]<mailto:[e-mail]>> wrote:

Dear Younghwan Choi,

Thank you for your reply.

Please see inline for EV> for additional comments. The absence of replies means that I agree with the proposed change.

You will notice that parts of my DISCUSS ballot are not addressed completely.

Regards

-éric


From: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Date: Wednesday, 4 January 2023 at 05:00
To: Eric Vyncke <[e-mail]<mailto:[e-mail]>>
Cc: The IESG <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, Samita Chakrabarti <[e-mail]<mailto:[e-mail]>>, Carles Gomez <[e-mail]<mailto:[e-mail]>>, Pascal Thubert <[e-mail]<mailto:[e-mail]>>
Subject: Re: Éric Vyncke's Discuss on draft-ietf-6lo-nfc-19: (with DISCUSS and COMMENT)

Dear Éric Vyncke,

Thanks for your comments.
Please see responses inline bellows.

Cheers,
Younghwan Choi

-----------------------------------------------
YOUNGHWAN CHOI, Ph.D.
Principal Researcher, PEC, ETRI
Tel [phone]   Fax [phone]
Email  [e-mail]<mailto:[e-mail]>


On Dec 12, 2022, at 7:15 PM, Éric Vyncke via Datatracker <[e-mail]<mailto:[e-mail]>> 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/
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:
----------------------------------------------------------------------


# É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.

EV> Still need to get the RFC 3633 as normative though

I will remove the reference [RFC 3633] from the section of normative reference, and I will put the reference [RFC 8415] in the section of informative reference as well.


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.

EV> but there is still the issue of normative language in something from NFC specification


I will revise your comment as follow:

OLD:

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.

NEW:

When the MIUX parameter is used, the TLV Type field is 0x02 and
the TLV Length field is 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 is set to zero by the
sender and ignored by the receiver.



### 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>.



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.

EV> typo 'eader'

Thanks. I will fix the typo, ‘header’ in the sentence.

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.

EV> do not forget to address the above

Yes, I will not forget it.


### 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].

EV> the 'subnet' term is still ambiguous

NEW: (I put “IPv6 prefix instead of “subnet”)

Section 5.

Two or more 6LNs may be connected with a 6LBR, but each connection uses a different IPv6 prefix.
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/ 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.

EV> I will let the security AD comment on this part

Thanks.

### 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.

EV> 'reliable' is still rather vague as a term

I will change “reliable” with "guaranteed delivery”. What about this?


```
  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.

EV> Sorry, my bad, I meant figure 4


I agree with you. I will remove Figure 4.



### Section 4.3

Please use RFC 5952 for IPv6 address format.

EV> not really, simple s/FE80::/fe80::/ 😊

Thanks. I will use "fe80::/64” in the sentence.


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    |

       +-----------------------------+----------------------------+

Many thanks for your a lot of comments. It helps a lot.



## 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