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/ 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.
_______________________________________________ 6lo mailing list 6lo@ietf.org https://www.ietf.org/mailman/listinfo/6lo
