Re: [6lo] Alexey Melnikov's No Objection on draft-ietf-6lo-nfc-13: (with COMMENT)

최영환 <yhc@etri.re.kr> Fri, 07 June 2019 08:08 UTC

From: 최영환 <yhc@etri.re.kr>
To: Alexey Melnikov <aamelnikov@fastmail.fm>, The IESG <iesg@ietf.org>
CC: "draft-ietf-6lo-nfc@ietf.org" <draft-ietf-6lo-nfc@ietf.org>, Carles Gomez <carlesgo@entel.upc.edu>, Samita Chakrabarti <samitac.ietf@gmail.com>, "6lo-chairs@ietf.org" <6lo-chairs@ietf.org>, "6lo@ietf.org" <6lo@ietf.org>
Thread-Topic: Alexey Melnikov's No Objection on draft-ietf-6lo-nfc-13: (with COMMENT)
Thread-Index: AQHU2dp5P6fY7ydUu0GJNXDJ0LczXqaNJQFwgAM1z5A=
Date: Fri, 07 Jun 2019 08:01:59 +0000
Message-ID: <B2C0C4C29044814AB285BBB7C754D9249AC9F23E@SMTP2.etri.info>
References: <155250853613.24902.16265554591912159081.idtracker@ietfa.amsl.com>
Accept-Language: ko-KR, en-US
Content-Language: ko-KR
Content-Type: text/plain; charset="ks_c_5601-1987"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/n79ybp2k_CvaCg-NWT6G73SX-Ns>
Subject: Re: [6lo] Alexey Melnikov's No Objection on draft-ietf-6lo-nfc-13: (with COMMENT)
Precedence: list

Hello Alexey and all,

Thanks for your valuable reviews.
Please find my answers inline.

BRs,
Younghwan Choi

> -----Original Message-----
> From: Alexey Melnikov via Datatracker <noreply@ietf.org>
> Sent: Thursday, March 14, 2019 5:22 AM
> To: The IESG <iesg@ietf.org>
> Cc: draft-ietf-6lo-nfc@ietf.org; Carles Gomez 
> <carlesgo@entel.upc.edu>; Samita Chakrabarti <samitac.ietf@gmail.com>; 
> 6lo-chairs@ietf.org; carlesgo@entel.upc.edu; 6lo@ietf.org
> Subject: Alexey Melnikov's No Objection on draft-ietf-6lo-nfc-13: 
> (with
> COMMENT)
> 
> Alexey Melnikov has entered the following ballot position for
> draft-ietf-6lo-nfc-13: No Objection
> 
> 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/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-6lo-nfc/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> I agree with Benjamin about antenna size. Despite that I have enjoyed 
> reading this document. I have some questions/comments that I would 
> like to discuss before recommending publication of this document as an RFC:

Thanks. Please refer to the answers about Benjamin's DISCUSS (about antenna).

> 
> In 3.2:
> 
>    The LLCP consists of Logical Link Control (LLC) and MAC Mapping.  The
>    MAC Mapping integrates an existing RF protocol into the LLCP
>    architecture.  The LLC contains three components, such as Link
>    Management, Connection-oriented Transmission, and Connection-less
>    Transmission.  The Link Management component is responsible for
>    serializing all connection-oriented and connection-less LLC PDU
>    (Protocol Data Unit) exchanges and for aggregation and disaggregation
>    of small PDUs.  This component also guarantees asynchronous balanced
>    mode communication and provides link status supervision by performing
>    the symmetry procedure.
> 
> Can you translate the last sentence for somebody who is not an expert 
> in this?
> 

Agreed with your point. I think the last sentence, "This component also guarantees asynchronous balanced [...] the symmetry procedure.", is not really helpful for understanding IPv6 over NFC. I would rather get rid of this last sentence. Thanks for your comment.

> In 4.4:
> 
>    The tool for a 6LBR to obtain an IPv6 prefix for numbering the NFC
>    network is can be accomplished via DHCPv6 Prefix Delegation
> 
> I think "is" before "can be" should be deleted above.

Thanks a lot. I will fix it.

> 
>    ([RFC3633]).
> 
> In 4.5:
> 
>    o  When two or more NFC 6LNs(or 6LRs) meet, there are two cases.  One
>       is that three or more NFC devices are linked with multi-hop
>       connections, and the other is that they meet within a single hop
>       range (e.g., isolated network).  In a case of multi-hops, all of
>       6LNs, which have two or more connections with different neighbors,
>       MAY be a router for 6LR/6LBR.  In a case that they meet within a
>       single hop and they have the same properties, any of them can be a
>       router.  When the NFC nodes are not of uniform category (e.g.,
>       different MTU, level of remaining energy, connectivity, etc.), a
>       performance-outstanding device can become a router.
> 
> The last sentence: how can 2 NFC nodes figure out which one has higher 
> level or remaining energy, etc?

Benjamin also pointed out this. I agree with his opinion. 
I am going to remove the sentence, " When the NFC nodes are not [...] performance-outstanding device can become a router.".

> 
> In 4.7:
> 
>    Therefore, IPv6 header compression in [RFC6282] MUST be implemented.
>    Further, implementations MAY also support Generic Header Compression
>    (GHC) of [RFC7400].
> 
> Will 2 NFC implementations interoperate if one of them supports GHC 
> and the other one doesn't? If they can't, then "MAY" seems to be too weak here.

I will change it with "MUST". 

> 
> In 4.8:
> 
>    IPv6-over-NFC fragmentation and reassembly (FAR) for the payloads is
>    NOT RECOMMENDED in this document as discussed in Section 3.4.
> 
> You are using "NOT RECOMMENDED", which is "SHOULD NOT". Why is this 
> not a "MUST NOT" and why implementation of FAR would be Ok if one node 
> supports it and another one doesn't?
> 

Agreed. I will change it with "MUST NOT".

[6lo] Alexey Melnikov's No Objection on draft-iet… Alexey Melnikov via Datatracker
Re: [6lo] Alexey Melnikov's No Objection on draft… 최영환