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. >>> >>> >>> >>> >> > > > >
- [6lo] Zaheduzzaman Sarker's Discuss on draft-ietf… Zaheduzzaman Sarker via Datatracker
- Re: [6lo] Zaheduzzaman Sarker's Discuss on draft-… yhc@etri.re.kr
- Re: [6lo] Zaheduzzaman Sarker's Discuss on draft-… Erik Kline
- Re: [6lo] Zaheduzzaman Sarker's Discuss on draft-… Zaheduzzaman Sarker
- Re: [6lo] Zaheduzzaman Sarker's Discuss on draft-… yhc@etri.re.kr
- Re: [6lo] Zaheduzzaman Sarker's Discuss on draft-… Zaheduzzaman Sarker
- Re: [6lo] Zaheduzzaman Sarker's Discuss on draft-… yhc@etri.re.kr