Zahed, Do these proposed changes address your concerns?
On Sun, Jan 8, 2023 at 8:52 PM y...@etri.re.kr <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> 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
