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 y...@etri.re.kr <mailto:y...@etri.re.kr> On Feb 25, 2023, at 7:59 PM, Zaheduzzaman Sarker <zaheduzzaman.sar...@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: y...@etri.re.kr <y...@etri.re.kr> > Sent: Saturday, February 25, 2023 1:22 AM > To: Zaheduzzaman Sarker <zaheduzzaman.sar...@ericsson.com> > Cc: Erik Kline <ek.i...@gmail.com>; The IESG <i...@ietf.org>; > draft-ietf-6lo-...@ietf.org <draft-ietf-6lo-...@ietf.org>; > 6lo-cha...@ietf.org <6lo-cha...@ietf.org>; 6lo@ietf.org <6lo@ietf.org>; > Samita Chakrabarti <samitac.i...@gmail.com>; Carles Gomez > <carle...@entel.upc.edu>; Wesley Eddy <w...@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 y...@etri.re.kr <mailto:y...@etri.re.kr> > >> On Feb 24, 2023, at 7:16 PM, Zaheduzzaman Sarker >> <zaheduzzaman.sar...@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.i...@gmail.com> wrote: >>> >>> Zahed, >>> >>> Do these proposed changes address your concerns? >>> >>> On Sun, Jan 8, 2023 at 8:52 PM y...@etri.re.kr <mailto:y...@etri.re.kr> >>> <y...@etri.re.kr <mailto:y...@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 >>>> <nore...@ietf.org <mailto:nore...@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 mailing list 6lo@ietf.org https://www.ietf.org/mailman/listinfo/6lo
