Re: [6lo] Zaheduzzaman Sarker's Discuss on draft-ietf-6lo-nfc-19: (with DISCUSS)

["[e-mail]" <[e-mail]>]

Dear Zaheduzzaman Sarker,

Thanks for your DISCUSS points.
I am not sure what was going on Wesley Eddy's comments and why the comments were not addressed.
Anyway, I’m sorry about that happening.  Please find my answers inline bellow:

Best regards
Younghwan

> On Jan 5, 2023, at 11:19 AM, Zaheduzzaman Sarker via Datatracker <[e-mail]> wrote:
> 
> Zaheduzzaman Sarker 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:
> ----------------------------------------------------------------------
> 
> Thanks for working on this specification. Thanks to Wesley Eddy for his
> excellent TSVART review.
> 
> As I agree with the points brought up by the TAVART reviewer, I would like to
> discuss why the points made by the reviewer should not be considered for this
> specification.
> 

There are three comments in the Wesley Eddy’s review as bellow:

> (1) Are there relations that need to be considered between IP header bits like
> the DSCP or ECN signalling relevant to NFC links, or is it expected that NFC
> links/hosts would not be able to utilize these meaningfully?

I don't think there are relations that need to be considered between IP header bits, 
and NFC links/hosts would not be able to utilize these meaningfully.

If it is required to make this clear in the draft, I will put a new texts at the end of Section 3.2.

NEW:

Section 3.2 (Protocol Stack of NFC)

“In addition, NFC links and host do not need to consider IP header bits for QoS signaling, 
or utilize these meaningfully ." 
 

> (2) How are upper layers made aware of the MTU supported on the link if it
> could established via either MIUX or FAR? TCP and other protocols need the
> correct information in order to send packets properly.

At the beginning of NFC LLCP (v1.0), there was a consideration for separated spec. of 
"binding to IP Protocol" in NFC Forum. Thus, the first draft of IPv6-over-NFC also didn’t 
consider MIUX because NFc can use Fragmentation and Reassembly. 
However,  the spec., "binding to IP Protocol" is not considered any more in NFC Forum. 
From IPv6-over-NFC (ver. 6), "The MIUX value MUST be 0x480 to support the IPv6 MTU 
requirement (of 1280 bytes)" has been put in Section 3.4.

If it is also required to make this clear, I will put the sentence in Section 3.4 as bellow:

OLD:

The MIUX value MUST be 0x480 to support the IPv6 MTU requirement (of 1280 bytes)

NEW:

As per the present specification, the MIUX value MUST be 0x480 to support 
the IPv6 MTU requirement (of 1280 bytes).

-------------------

To make these consistent, I will also revise the Figure 1 as bellow:

OLD:

       +----------------------------------------+ - - - - - - - - -
       |              IPv6 - LLCP               |         
       |                Binding                 |       NFC
       +----------------------------------------+   Logical Link
       |      Logical Link Control Protocol     |      Layer
       |                 (LLCP)                 |         
       +----------------------------------------+ - - - - - - - - -
       |               Activities               |        
       |            Digital Protocol            |   NFC Physical
       +----------------------------------------+       Layer
       |               RF Analog                |         
       +----------------------------------------+ - - - - - - - - -

                      Figure 1: Protocol Stack of NFC


NEW: (removing “ IPv6-LLCP Binding”)

       +----------------------------------------+ - - - - - - - - -
       |      Logical Link Control Protocol     |    NFC Logical
       |                 (LLCP)                 |    Link Layer
       +----------------------------------------+ - - - - - - - - -
       |               Activities               |         
       |            Digital Protocol            |    NFC Physical
       +----------------------------------------+       Layer
       |               RF Analog                |         
       +----------------------------------------+ - - - - - - - - -

                      Figure 1: Protocol Stack of NFC



> (3) The data rate ranges are mentioned, but not whether IP over NFC links would
> be expected to have some type of delays or variation in delays associated with
> them or typical frame loss rates, etc. that might be of interest in properly
> configuring transport protocols. One could imagine this might be the case with
> passive targets.

NFC Link layer Protocol (LLCP 1.4) provides two types of communications 
(i.e., connectionless transport and connection-oriented transport) by itself.
These are described at the end of Section 3.2, Actually, NFC links do not always
guarantee perfect wireless link quality, so some type of delays or variation in delay
would be expected in any case. 

I will put some texts for clarification in Section 3.2. 

OLD:

   The LLCP consists of Logical Link Control (LLC) and MAC Mapping. (…)  
   The Connection-oriented Transmission component is
   responsible for maintaining all connection-oriented data exchanges
   including connection set-up and termination. 

NEW:

   The LLCP consists of Logical Link Control (LLC) and MAC Mapping. (…)  
   The Connection-oriented Transmission component is
   responsible for maintaining all connection-oriented data exchanges
   including connection set-up and termination. However, NFC links do not 
   guarantee perfect wireless link quality, so some type of delays or variation 
   in delay would be expected in any case.