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. //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. >> >> >> >>
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ 6lo mailing list 6lo@ietf.org https://www.ietf.org/mailman/listinfo/6lo
