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

[Erik Kline <[e-mail]>]

Zahed,

Do these proposed changes address your concerns?

On Sun, Jan 8, 2023 at 8:52 PM [e-mail] <[e-mail]> wrote:

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