[Gen-art] Genart telechat review of draft-ietf-intarea-probe-07

Joel Halpern <jmh@joelhalpern.com> Thu, 30 November 2017 21:44 UTC

Return-Path: <jmh@joelhalpern.com>
X-Original-To: gen-art@ietf.org
Delivered-To: gen-art@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E87FB1294F3; Thu, 30 Nov 2017 13:44:37 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Joel Halpern <jmh@joelhalpern.com>
To: gen-art@ietf.org
Cc: draft-ietf-intarea-probe.all@ietf.org, int-area@ietf.org, ietf@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.66.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <151207827781.25922.11037452280009787600@ietfa.amsl.com>
Date: Thu, 30 Nov 2017 13:44:37 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/yjqddexcZvkh1-SP-2Wv61I4KY8>
Subject: [Gen-art] Genart telechat review of draft-ietf-intarea-probe-07
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.22
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Nov 2017 21:44:38 -0000

Reviewer: Joel Halpern
Review result: Almost Ready

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please wait for direction from your
document shepherd or AD before posting a new version of the draft.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-intarea-probe-07
Reviewer: Joel Halpern
Review Date: 2017-11-30
IETF LC End Date: 2017-12-13
IESG Telechat date: 2017-12-14

Summary: This document is almost ready for publication as a Proposed Standard
RFC.

Major issues:
    I can not determine from the text why two identification objects are
    sometimes allowed, or how they are to be used.  The texts seems to indicate
    that they can be somehow combined to identify a single probed interface. 
    But I can not see how.

Minor issues:
    In section 2.1 in describing the usage when the probed interface is
    identified by name or ifindex, the text refers to MIBII, RFC 2863.  I would
    expect to see it refer instead (or at least preferentially) to RFC 7223,
    the YANG model for the Interface stack.

    The E bit in the Extended ICMP Echo reply seems a bit odd.  Shall we try to
    encode all the possible interface types in this field?  Shall we try to
    distinguish Ethernet directly over fiber from Ethernet over ...?  What
    about an emulated Ethernet interface (pseudowire, etc.)  I do not
    understand why this is here, and fear it is ambiguous.

Nits/editorial comments:
    I find the description of the node containing the proxy interface as being
    "the probed node" as being somewhat odd, as it is not the node containing
    the probed interface.  I would have expected it to be called "the proxy
    node"?

    Very nitpicky: In section 4, the step reading "If the Code Field is equal
    to No Error (0) and the L-bit is clear, set the A-Bit." probably ought to
    say "otherwise, clear the A-bit."