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

Alexey Melnikov via Datatracker <noreply@ietf.org> Wed, 13 March 2019 20:22 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: 6lo@ietf.org
Delivered-To: 6lo@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 22947130F04; Wed, 13 Mar 2019 13:22:16 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Alexey Melnikov via Datatracker <noreply@ietf.org>
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
X-Test-IDTracker: no
X-IETF-IDTracker: 6.94.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Alexey Melnikov <aamelnikov@fastmail.fm>
Message-ID: <155250853613.24902.16265554591912159081.idtracker@ietfa.amsl.com>
Date: Wed, 13 Mar 2019 13:22:16 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/YTnkQtb3CtRdspi5jd5BY4JYf-Y>
Subject: [6lo] Alexey Melnikov's No Objection on draft-ietf-6lo-nfc-13: (with COMMENT)
X-BeenThere: 6lo@ietf.org
X-Mailman-Version: 2.1.29
List-Id: "Mailing list for the 6lo WG for Internet Area issues in IPv6 over constrained node networks." <6lo.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6lo>, <mailto:6lo-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6lo/>
List-Post: <mailto:6lo@ietf.org>
List-Help: <mailto:6lo-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6lo>, <mailto:6lo-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Mar 2019 20:22:16 -0000

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:


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:

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?

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.


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?

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.

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?