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

"yhc@etri.re.kr" <yhc@etri.re.kr> Sun, 26 February 2023 23:09 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 AEB4FC14CE55 for <6lo@ietfa.amsl.com>; Sun, 26 Feb 2023 15:09:23 -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_FONT_FACE_BAD=0.001, 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_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 Wys3hJYmvXm7 for <6lo@ietfa.amsl.com>; Sun, 26 Feb 2023 15:09:17 -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 B3395C14CF1B for <6lo@ietf.org>; Sun, 26 Feb 2023 15:09:10 -0800 (PST)
Received: from unknown (HELO send001-relay.gov-dooray.com) (211.180.235.152) by 129.254.9.16 with ESMTP; 27 Feb 2023 08:02: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.106] (HELO smtp001-imp.gov-dooray.com) ([10.162.225.106]) by send001-relay.gov-dooray.com with SMTP id a9a539e363fbe502; Mon, 27 Feb 2023 08:02:26 +0900
DKIM-Signature: a=rsa-sha256; b=o4ZcB8Q3j+arAzNkmPJSA3TbjRAm6BSXiObF3bSh2Znm2ITGDFW2C/A0657dQSNF8ZFA7/wq7y NMvNqgQVCsBSumJoz4VpPDGELscAYAoBUtBTC3dEYXy+1vw1ig7Du7LykdD5ThrD6I3RdDGDlU6+ WExO+9tzRV80rCh419rkvKg8BZCCXjn9fprssLw9PAZRKpwe00Wg+RvrR/NvsTMagB8mqx6dmPvZ +48Pl5neRJMHiISqRGuF4vZBaHBD1iNWvpV2B2bsyCBSk8gDPqfZGxwuiNbt2qVT3m4hEeOSPjiZ h6ANmOApXyDiodG5GDjCb9wUZi01cTjIsRDKBU1w==; c=relaxed/relaxed; s=selector; d=dooray.com; v=1; bh=7ZULujGuQXsZKOAqX2V/ixVdToB9iCjT2x92aV3YTQY=; h=From:To:Subject:Message-ID;
Received: from [129.254.170.125] (HELO smtpclient.apple) ([129.254.170.125]) by smtp001-imp.gov-dooray.com with SMTP id 64a7393963fbe502; Mon, 27 Feb 2023 08:02:26 +0900
From: "yhc@etri.re.kr" <yhc@etri.re.kr>
Message-Id: <E3D8219E-BCC1-4039-BA42-DD64CFEBADC6@etri.re.kr>
Content-Type: multipart/alternative; boundary="Apple-Mail=_FD968AEA-B6D4-4EAE-85A9-EF767252CAB4"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.2\))
Date: Mon, 27 Feb 2023 08:02:21 +0900
In-Reply-To: <DB7PR07MB399542780D328100D44F25479FA99@DB7PR07MB3995.eurprd07.prod.outlook.com>
Cc: Erik Kline <ek.ietf@gmail.com>, The IESG <iesg@ietf.org>, "draft-ietf-6lo-nfc@ietf.org" <draft-ietf-6lo-nfc@ietf.org>, "6lo-chairs@ietf.org" <6lo-chairs@ietf.org>, "6lo@ietf.org" <6lo@ietf.org>, Samita Chakrabarti <samitac.ietf@gmail.com>, Carles Gomez <carlesgo@entel.upc.edu>, Wesley Eddy <wes@mti-systems.com>
To: Zaheduzzaman Sarker <zaheduzzaman.sarker@ericsson.com>
References: <167288516911.30036.17997314654448194343@ietfa.amsl.com> <36774852-8711-473E-B060-054007B88432@etri.re.kr> <CAMGpriWmjcF-2N-v628KWggojR+kqbCsn5fN14G6oLV6RudGDA@mail.gmail.com> <E0B87E9F-B1DA-4100-9AB6-1D5A3995A2CF@ericsson.com> <E94A678B-E1F5-450A-8DA8-12934ABD957C@etri.re.kr> <DB7PR07MB399542780D328100D44F25479FA99@DB7PR07MB3995.eurprd07.prod.outlook.com>
X-Mailer: Apple Mail (2.3696.120.41.1.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/lyx6bxWPp7Xconkog2WnKALnvWk>
Subject: Re: [6lo] Zaheduzzaman Sarker's Discuss on draft-ietf-6lo-nfc-19: (with DISCUSS)
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: Sun, 26 Feb 2023 23:09:23 -0000

Dear Zaheduzzaman Sarker,

As your suggestion, I will revise the draft as following:

NEW:

"As per the present specification [LLCP-1.4], the MIUX value MUST be 0x480 to support 
the IPv6 MTU requirement (of 1280 bytes)."

I will publish a revised draft, draft-ietf-6lo-nfc-20 shortly.
Many thanks for your review.

Cheers,
Younghwan

-----------------------------------------------
YOUNGHWAN CHOI, Ph.D.

Principal Researcher, PEC, ETRI
Tel +82-42-860-1429 
Email  yhc@etri.re.kr <mailto:yhc@etri.re.kr>

On Feb 25, 2023, at 7:59 PM, Zaheduzzaman Sarker <zaheduzzaman.sarker@ericsson.com> wrote:
> 
> Hello, 
> 
> Thanks for clarifying.
> 
> In that case I would suggest adding reference to the specification we are talking about in the new text you are suggesting -
> 
>>> As per the present specification [ add ref here ], the MIUX value MUST be 0x480 to support 
>>> the IPv6 MTU requirement (of 1280 bytes).
> 
> 
> //Zahed
> From: yhc@etri.re.kr <yhc@etri.re.kr>
> Sent: Saturday, February 25, 2023 1:22 AM
> To: Zaheduzzaman Sarker <zaheduzzaman.sarker@ericsson.com>
> Cc: Erik Kline <ek.ietf@gmail.com>; The IESG <iesg@ietf.org>; draft-ietf-6lo-nfc@ietf.org <draft-ietf-6lo-nfc@ietf.org>; 6lo-chairs@ietf.org <6lo-chairs@ietf.org>; 6lo@ietf.org <6lo@ietf.org>; Samita Chakrabarti <samitac.ietf@gmail.com>; Carles Gomez <carlesgo@entel.upc.edu>; Wesley Eddy <wes@mti-systems.com>
> Subject: Re: Zaheduzzaman Sarker's Discuss on draft-ietf-6lo-nfc-19: (with DISCUSS)
>  
> Dear Zaheduzzaman Sarker,
> 
> Thanks for your response. 
> Please find my answers inline bellow.
> 
> Cheers,
> Younghwan
> 
> -----------------------------------------------
> YOUNGHWAN CHOI, Ph.D.
> 
> Principal Researcher, PEC, ETRI
> Tel +82-42-860-1429 
> Email  yhc@etri.re.kr <mailto:yhc@etri.re.kr>
> 
>> On Feb 24, 2023, at 7:16 PM, Zaheduzzaman Sarker <zaheduzzaman.sarker@ericsson.com> wrote:
>> 
>> It looks mostly OK to me. However, would have been better if we can get any response from Wesley Eddy (I have included him in the CC - in case he missed this conversation).
>> 
>> What I didn’t quite get is the reason behind certainly removing IPV6-LLCP binding from NFC logical link layer in figure 1 and how removing that helps.
> 
> Whan IPv6-over-NFC (I.D.00~I.D.-17) referred to the NFC LLCP specification version 1.3 (LLCP-1.3), the LLCP-1.3 considered the a separate layer for IP-LLCP binding at that time.
> However, IPv6-over-NFC has referred to LLCP-1.4 from I.D.-18. In addition, LLCP-1.4 does not consider the IP-LLCP binding layer any more.
> 
> Thus, I removed the IPv6-LLCP Binding in the Figure 1. I can’t put the binding layer which NFC LLCP does not consider and not provide.
> I am not sure the reason why NFC LLCP does not consider the binding layer any more, but I guess such a binding layer can be one of implementation issues rather than one of standardization issues from the viewpoint of NFC LLCP.
> 
>> 
>> //Zahed
>> 
>>> On 24 Feb 2023, at 07:27, Erik Kline <ek.ietf@gmail.com> wrote:
>>> 
>>> Zahed,
>>> 
>>> Do these proposed changes address your concerns?
>>> 
>>> On Sun, Jan 8, 2023 at 8:52 PM yhc@etri.re.kr <mailto:yhc@etri.re.kr> <yhc@etri.re.kr <mailto:yhc@etri.re.kr>> 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 <noreply@ietf.org <mailto:noreply@ietf.org>> 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/ <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:
>>>> ----------------------------------------------------------------------
>>>> 
>>>> 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.
>>> 
>>> 
>>> 
>>> 
>> 
> 
> 
> 
>