Re: Review of draft-ietf-mpls-residence-time-12

Greg Mirsky <gregimirsky@gmail.com> Wed, 18 January 2017 18:04 UTC

Return-Path: <gregimirsky@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D2EC1294EF; Wed, 18 Jan 2017 10:04:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.559
X-Spam-Level:
X-Spam-Status: No, score=0.559 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_COMMENT_SAVED_URL=1.391, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_BODY=1.157, SPF_PASS=-0.001, T_HTML_ATTACH=0.01] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wDXBYRq7ma70; Wed, 18 Jan 2017 10:03:59 -0800 (PST)
Received: from mail-ot0-x235.google.com (mail-ot0-x235.google.com [IPv6:2607:f8b0:4003:c0f::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8E671294D6; Wed, 18 Jan 2017 10:03:58 -0800 (PST)
Received: by mail-ot0-x235.google.com with SMTP id 65so14325351otq.2; Wed, 18 Jan 2017 10:03:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=SjFAekbER4Rtakl6kVg1aQEMnCTCzpq88rRyPl83ZOQ=; b=TENdfgiaAnP576p2PQwEyJm/Zbf9HIMNpPswOe261TcM0J/4dYQQGuhlV9p8YJtdAf TQhXtv5Jdn7AjnqmpUxBNQ99i2QHLFHPc4x+2CY60gNyZ3VJMwoatojyQmD7s+6apBIV X+QMxvSSQ7yyxmFU6d92cJx5V/tV0sccoJ7VA/lQmOVfjnSxSAw5Fe6kIgpYyPIxA3dr mVKdo5PWSBEP+hy2RcJWFhlLO4juB0Kw4m50P8QffcuhMD9mVADtMU8g8zYn1/gWB0n1 QSjxfmiLVOuhGNHkwHZnMA6O9SWG+eL/6nDbTrb4JPYgnM1U2CGnvQDvSeSDyi7bAkjN m3GQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=SjFAekbER4Rtakl6kVg1aQEMnCTCzpq88rRyPl83ZOQ=; b=bj8Bl7TuZFnLi2DScZfenqy3bM7onwZtRdTy4P4v+u6zAkbaBPP9vQzvHILXgvbF+z La3+uAUVg2V9hxonuPS4MmiyBNIoZmiQnaBuduqDFhvMbRpmkUxtNCjTCDF1pUGv8PY2 3cTDnFUyZiyHWtwGqmBOI3q/OLjNSNKd1PFCQp2zhIBnWmXXJ97Jg+TCAo9RIpwGEWH9 u1ciZKYEAmRcR1l3Wj5qBR8z0vqHbIFlAjrQf9TfspMWvdVPsPPKXtDcUQSWTmHlMCxn R4x8XUTgU8B4gTyvcm4EZ3PBLwq/+C3uQmH5plLfuT4DJ8BpT2+xhi33Zbf/io8xnbVM IS8A==
X-Gm-Message-State: AIkVDXLtE6p4GUm2C2b1lzNR+9cPPN9s+lJw+WFQ5R1w8ukMAPvlicjLLrKLclWG4xPPlvGFVE8wPqYPcq2HVQ==
X-Received: by 10.157.16.9 with SMTP id h9mr2176183ote.40.1484762637984; Wed, 18 Jan 2017 10:03:57 -0800 (PST)
MIME-Version: 1.0
Received: by 10.157.1.103 with HTTP; Wed, 18 Jan 2017 10:03:57 -0800 (PST)
In-Reply-To: <CA+RyBmU9W5QP4EjbPezoCpdLHv1RJCrzJvxQmeTnAvjO_6vbJA@mail.gmail.com>
References: <148414970343.8167.4538946698521330202.idtracker@ietfa.amsl.com> <CA+RyBmU9W5QP4EjbPezoCpdLHv1RJCrzJvxQmeTnAvjO_6vbJA@mail.gmail.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Wed, 18 Jan 2017 10:03:57 -0800
Message-ID: <CA+RyBmVrvyiwDp2kV3VLiQtqOaL=MaVjZugGbvgWnp6y3dwP3Q@mail.gmail.com>
Subject: Re: Review of draft-ietf-mpls-residence-time-12
To: Robert Sparks <rjsparks@nostrum.com>
Content-Type: multipart/mixed; boundary=001a11402c029d10ae0546623d7e
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/wHZjHpnLewDaGRKG-yxSsZdYct4>
Cc: "mpls@ietf.org" <mpls@ietf.org>, "gen-art@ietf.org" <gen-art@ietf.org>, draft-ietf-mpls-residence-time.all@ietf.org, "ietf@ietf.org" <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Jan 2017 18:04:08 -0000

Hi Robert,
Sasha Vainshtein came with elegant idea to address disconnection between
discussion of one-step and two-step modes that you've pointed out. We've
moved Section 7 as sub-section into Section 2 now. Attached are updated
diff and the proposed new version -13.

Regards,
Greg

On Wed, Jan 18, 2017 at 8:13 AM, Greg Mirsky <gregimirsky@gmail.com> wrote:

> Hi Robert,
> once again, thank you for your thorough review and the most detailed
> comments. I've prepared updated version and would greatly appreciate if you
> review the changes and let us know whether your comments been addressed.
> Attached are diff and the new version.
>
> Regards,
> Greg
>
> On Wed, Jan 11, 2017 at 7:48 AM, Robert Sparks <rjsparks@nostrum.com>
> wrote:
>
>> Reviewer: Robert Sparks
>> Review result: Ready with Nits
>>
>> 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 treat these comments just
>> like any other last call comments.
>>
>> For more information, please see the FAQ at
>> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
>>
>> Document: draft-ietf-mpls-residence-time-12
>> Reviewer: Robert Sparks
>> Review Date: 2017-01-10
>> IETF LC End Date: 2017-01-17
>> IESG Telechat date: 2017-02-02
>>
>> Summary: Ready (with nits) for publication as a Proposed Standard
>>
>> I have two primary comments. I expect both are rooted in the authors
>> and working group knowing what the document means instead of seeing
>> what
>> it says or doesn't say:
>>
>> 1) The document is loose with its use of 'packet', and where TTLs
>> appear when
>> they are discussed. It might be helpful to rephrase the text that
>> speaks
>> of RTM packets in terms of RTM messages that are encoded as G-ACh
>> messages and
>> not refer to packets unless you mean the whole encapsulated packet
>> with MPLS
>> header, ACH, and G-ACh message.
>>
>> 2) Since this new mechanic speaks in terms of fractional nanoseconds,
>> some
>> discussion of what trigger-point you intend people to use for taking
>> the
>> precise time of a packet's arrival or departure seems warranted. (The
>> first and
>> last bit of the whole encapsulated packet above are going to appear at
>> the
>> physical layer many nanoseconds apart at OC192 speeds if I've done the
>> math
>> right). It may be obvious to the folks discussing this, but it's not
>> obvious
>> from the document.  If it's _not_ obvious and variation in technique
>> is
>> expected, then some discussion about issues that might arise from
>> different
>> implementation choices would be welcome.
>>
>> The rest of these are editorial nits:
>>
>> It would help to pull an overview description of the difference
>> between
>> one-step and two-step much earlier in the document. I suggest in the
>> overview
>> in section 2. Otherwise, the reader really has to jump forward and
>> read section
>> 7 before section 3's 5th bullet makes any sense.
>>
>> In section 3, "IANA will be asked" should be made active. Say "This
>> document
>> asks IANA to" and point to the IANA consideration section. Apply
>> similar
>> treatment to the other places where you talk about future IANA
>> actions.
>>
>> There are several places where there are missing words (typically
>> articles or
>> prepositions). You're less likely to end up with misinterpretations
>> during the
>> RFC Editor phase if you provide them before the document gets that far
>> in the
>> process. The spots I found most disruptive were these (this is not
>> intended to
>> be exhaustive):
>>
>>   Section 3: "set 1 according" -> "set to 1 according"
>>   Section 3: "the Table 19 [IEEE..." -> "Table 19 of [IEEE..."
>>   Section 4.2: "Detailed discussion of ... modes in Section 7."
>>                         -> "Detailed discussion of ... modes appears
>> in Section 7."
>>   Section 10: "most of" -> "most of all"
>>
>> In Setion 3.1 at "identity of the source port", please point into the
>> document
>> that defines this identity and its representation. I suspect this is a
>> pointer
>> into a specific section in IEEE.1588.2008].
>>
>>
>>
>>
>