Re: [mpls] Ben Campbell's No Objection on draft-ietf-mpls-residence-time-14: (with COMMENT)

Greg Mirsky <gregimirsky@gmail.com> Thu, 02 March 2017 17:21 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 76C20129579; Thu, 2 Mar 2017 09:21:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 pJ7f4lN3XN4z; Thu, 2 Mar 2017 09:21:46 -0800 (PST)
Received: from mail-ot0-x22d.google.com (mail-ot0-x22d.google.com [IPv6:2607:f8b0:4003:c0f::22d]) (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 8DFCE1294C0; Thu, 2 Mar 2017 09:21:46 -0800 (PST)
Received: by mail-ot0-x22d.google.com with SMTP id i1so56907256ota.3; Thu, 02 Mar 2017 09:21:46 -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=eoP1gQ/J086lsZEm4Ac4IHT0h8wpscNJAgkCPNcQGvo=; b=IupLC2ML/bS5TsW9Yo7ukfkW/5mYoe8mXz6G/OxLSgf4l3stOaZI89b0n1keU39NNs tAHoFKnL6EyjnHx0LaxdLeTZ7G3fE4EixWuPAqC/78VfF/RHtttCFke7KaocVXFrebPD tXskN+evyVyroIm21mK+0c/haBM6m+fdIMpouLlnx04CUF04sENnjVDBLkKaLc8ncRFr 2zX4drvCbji/2oHhodShIxXEPcQHkfg9QbjiNLIJalO5hoyHHSzZ5G1UmcfJ8jEgpRPn GQFF514vYjYGBcze+cNj4Gys7YLVk55BH41SCSVRyDy/XgApntFiWyoORC/iXjbCbl1R kYVw==
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=eoP1gQ/J086lsZEm4Ac4IHT0h8wpscNJAgkCPNcQGvo=; b=POqVR0HYhGd1e7Q6oheH22+jEkADvM2SlXzRPFAwslD+gsCaTuwsJksNQtqDFwbVjK 0yGv8SggRqBScpOtTseq12Ha+SvxWVSG3iEOVMyOpl0SB76MSOn7TB/HznXoSWsGdh8b 3w63aZm9ekoELZZQSwuqMO5ssa+9MHcKs+2rAIwPCmjHlRUi0Zxrd7zwlWKPFcJ9xBar XIWa+JclxBwKVgHbmR4TaANET40A21TAW1ao//w4DHRau0u5uUfHwD+H3WQjtCHK0OQ0 bsPL/x1m8Yi+dabliZPugPHw5VgFXa6SowYkrjHJzNjy9WnlZxoAWaIf0Gx9nZqxte8T /3Gg==
X-Gm-Message-State: AMke39msTMnAANvYor20vuDNhE+LHhLKwYDlJPFPqDAw3GmEVYjnNKe7UBz5Ej2RKT/yKeyay9bzPd4qfK5Ccg==
X-Received: by 10.157.1.247 with SMTP id e110mr6531898ote.40.1488475305740; Thu, 02 Mar 2017 09:21:45 -0800 (PST)
MIME-Version: 1.0
Received: by 10.157.21.21 with HTTP; Thu, 2 Mar 2017 09:21:45 -0800 (PST)
In-Reply-To: <148841019992.7040.2698428179443970594.idtracker@ietfa.amsl.com>
References: <148841019992.7040.2698428179443970594.idtracker@ietfa.amsl.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Thu, 2 Mar 2017 09:21:45 -0800
Message-ID: <CA+RyBmXhbEmN7nQQaPmBCdu3mT4ZsK0=BUwUg4Rvpy4RkM3ToA@mail.gmail.com>
To: Ben Campbell <ben@nostrum.com>
Content-Type: multipart/alternative; boundary=94eb2c03b82adb11be0549c2a9c7
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/xDwNcTKnYZqBhlT27_z_hLFGX8Q>
Cc: mpls-chairs@ietf.org, draft-ietf-mpls-residence-time@ietf.org, "mpls@ietf.org" <mpls@ietf.org>, The IESG <iesg@ietf.org>
Subject: Re: [mpls] Ben Campbell's No Objection on draft-ietf-mpls-residence-time-14: (with COMMENT)
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: Thu, 02 Mar 2017 17:21:48 -0000

Hi Ben,
thank you for your thorough review and comments. Please find my answers
in-line tagged GIM>>.

Regards,
Greg

On Wed, Mar 1, 2017 at 3:16 PM, Ben Campbell <ben@nostrum.com>; wrote:

> Ben Campbell has entered the following ballot position for
> draft-ietf-mpls-residence-time-14: 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-mpls-residence-time/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> I have no objection, but do have some a few minor comments:
>
> Substantive:
>
> -2.1, 4th paragraph from end: Can you offer guidance on what might
> constitute a reasonably bound wait time?\
>
GIM>> Section 7.7.2 Message transmission intervals in IEEE.1588.2008
defines algorithm to calculate intervals  between PTP control messages that
will, in turn, define the range for "the reasonably bound time". But
specification of the precise values are deferred to the appropriate PTP
profiles.

>
> -2.1, 2nd paragraph from end: "... MUST NOT do both": What's the scope of
> that MUST NOT? Does it mean MUST NOT ever? NUST NOT in the same
> message?
>
GIM>> This is in reference to the node behavior in context of the same LSP.
On the given LSP the RTM-capable node MUST NOT perform in one-step and
two-step mode.

>
> Editorial:
> - Abstract: The last paragraph is a single, long sentence. Please
> consider breaking it into simpler sentences.
>
NEW TEXT

   Residence time is the variable part of propagation delay of timing
   and synchronization messages.  Knowing what this delay is for each
   message allows for a more accurate determination of the delay to be
   taken into account in applying the value included in a Precision Time
   Protocol event message.


> - 2.1, paragraph 9: "This bit, once it is set by a two-
>    step mode device, MUST stay set accordingly": Can that MUST be stated
> in process terms? That is, <actors>  MUST NOT unset this bit..."
>
OLD TEXT

   PTP messages also include a bit that indicates whether or not a
   follow-up message will be coming.  This bit, once it is set by a two-
   step mode device, MUST stay set accordingly until the original and
   follow-up messages are combined by an end-point (such as a Boundary
   Clock).

NEW TEXT

   PTP messages also include a bit that indicates whether or not a
   follow-up message will be coming.  This bit MAY be set by a two-step
   mode PTP device.  The value MUST NOT be unset until the original and
   follow-up messages are combined by an end-point (such as a Boundary
   Clock).



>
> -2.1, paragraph 11:  "Without loss of generality should note
>    that handling of Sync event messages..." : I don't follow the
> sentence; are words missing and/or out of order?
> -- "Following outlines handling of PTP Sync event message by the two-step
> RTM node.": I think there's a missing "the" at the start. It's absence
> completely changes the meaning of "following outlines"-- as written it
> seem like the verb is "following", but I think you mean it to be
> "outlines".
>
GIM>> Agreed, Prepend with 'The'.

> -- I have trouble matching some pronouns to their antecedents in the rest
> of the paragraph.
>
>
>