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

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

Return-Path: <gregimirsky@gmail.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2AA71294C8; Wed, 18 Jan 2017 08:13:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.598
X-Spam-Level:
X-Spam-Status: No, score=-0.598 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, 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 F7h34l3-K-8Q; Wed, 18 Jan 2017 08:13:30 -0800 (PST)
Received: from mail-ot0-x229.google.com (mail-ot0-x229.google.com [IPv6:2607:f8b0:4003:c0f::229]) (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 B72F1129461; Wed, 18 Jan 2017 08:13:29 -0800 (PST)
Received: by mail-ot0-x229.google.com with SMTP id 65so12017986otq.2; Wed, 18 Jan 2017 08:13:29 -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=B3F+7OLl4RKUvjH2ugrOvORpOA2oQOe2IWOKLrb4ZC8=; b=IyNP9YzvXpkwh4ERYt11P3acZPdNI+BR52Obo6ZBo88gyep+xsQv+B1qk7VL37pfdA 8rDUjO9OlyzTyvSPI62PkxAkztUf0zUB8vDdnYKNadb4156gV8x3+g/Khl01CDaMllCA NxIQKon7VysSO7sHWf771sOD1a3eehyFiRRBOh3BX0PEwnNE2LMxNRY29EgF7DWqZIk0 cv28iZpsLUI0JZCfVfXvpm662zMcToL/QZULYN4WfLk4Tbu78Aa/7i6+fOEpdG4hOkz6 Rl+ISq4XGFlfYLMocnpdDGAqYYRtXaeWzn+mrdPHZY2K6Y6a6LN/xTZjWj4POirivv4b AVJw==
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=B3F+7OLl4RKUvjH2ugrOvORpOA2oQOe2IWOKLrb4ZC8=; b=fV6qX6RN+SOlhWWLhrGpTLIpk1ZOSRYHGqiu5zXNWTM5PizhI8mXCmx7k4/2ZJFpiq B41tFBC/kwJ45XdCaHVaIo/iGVuxwcCdWVS0Klbf0jSFMDhVKwcP8K9UGGydu6CNpYsi 89jArWEER7OIDoKoiBHHZLkgpSKofw3gWK1Zy2P1ba7445BMDgz5cqWRRMSmtIIu6NYV vsu7txCo3T/ehQ/l+DxGObtBedkwoA/xYmz3UEy4xeQ4lWbvxUnhNN+BytcljsK1rg8u w32pMlth2vIZtybbMgPWwn2qtsjzqEeQzP3J7OqDXSZ8HczjA+oAF2gL68S7lbB/e2ED FVnw==
X-Gm-Message-State: AIkVDXKkoMEcaJCDnmXl6tk0CWPLdYFJeqIDBHzmGhb1hbtAPmr+wwKdwb/1ErC7RK9nvipn8AUdgwdrSrUxLg==
X-Received: by 10.157.3.22 with SMTP id 22mr2282454otv.118.1484756008968; Wed, 18 Jan 2017 08:13:28 -0800 (PST)
MIME-Version: 1.0
Received: by 10.157.1.103 with HTTP; Wed, 18 Jan 2017 08:13:28 -0800 (PST)
In-Reply-To: <148414970343.8167.4538946698521330202.idtracker@ietfa.amsl.com>
References: <148414970343.8167.4538946698521330202.idtracker@ietfa.amsl.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Wed, 18 Jan 2017 08:13:28 -0800
Message-ID: <CA+RyBmU9W5QP4EjbPezoCpdLHv1RJCrzJvxQmeTnAvjO_6vbJA@mail.gmail.com>
To: Robert Sparks <rjsparks@nostrum.com>
Content-Type: multipart/mixed; boundary="94eb2c0430887e442e054660b263"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/8PfGdvNdXFDSk2c6V4FqBtlfsuA>
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>
Subject: Re: [mpls] Review of draft-ietf-mpls-residence-time-12
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Jan 2017 16:13:36 -0000

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].
>
>
>
>