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

Greg Mirsky <gregimirsky@gmail.com> Wed, 18 January 2017 16:15 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 A437F129856; Wed, 18 Jan 2017 08:15:31 -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 bD-GTQSQHC9h; Wed, 18 Jan 2017 08:15:22 -0800 (PST)
Received: from mail-ot0-x230.google.com (mail-ot0-x230.google.com [IPv6:2607:f8b0:4003:c0f::230]) (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 E9CDE1294EC; Wed, 18 Jan 2017 08:15:19 -0800 (PST)
Received: by mail-ot0-x230.google.com with SMTP id 65so12056299otq.2; Wed, 18 Jan 2017 08:15:19 -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=xsmQHWJSVqzS7BBwBZSzJERLpe1FmsU5i2rlMkUgZUM=; b=AlvRGYL8TG8frwyfbhTgXFUkNSU3hCdwudbkPPJ0ggybyXsa1I6dCapwrHP8yhRtxa 96OkPg2Av8p7GyvZKq2UU8fwPeCHEShFI0ZbQ0/TnT98kqVTsKMbDFs+o9zuJNJh1VwI /8QM7KNisO39TNHWiAXhf99vgxcw0EjKQG9teWAb79+GmtvVORttrF2KLpRPk1j12veO vbG0D3dfteJkI/MmDvX/yIwJEtnWhoRnvdblXyaJa1E8mN9PfltOg9HLDmHpDgTxAeFs hIJ/3qn+s1YReR0NrzVwkTpkuezHc2dAZYW0GztvVcOyyrODL3ItGRa6YqZd3QZ835wc BjYA==
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=xsmQHWJSVqzS7BBwBZSzJERLpe1FmsU5i2rlMkUgZUM=; b=dlbAFux3nLaVoBAGUqikgSZbIbcL6A36voG972fRgASoXlCRUUIoveN84KFfFnRtd/ Ku1iuNNt3rKRolA7pTOOOaJdvG4w+/OwqtRpRm5a1xesHFmiNb2iH77Rkc7rFKlykdrB 45uqJfJtwy/Hgs1dLhq24ZMpqEwGBjxjbNBg4g1P78jvIi+MNNjrPYeuazazq6RFqiNg 6vq0e0ZtkVAMSor+ovxh/WrAtSzB2xx83kEDZuvFX0ysOCy7EDoM2mbFXMD+ZTi2axVL n0iUG0DPmFvFmwnKCv5aOeepFn9p+5A0WVP8T0QF2nAKyRw3SXT0Hk5mXFP/IQMit/L3 GWiA==
X-Gm-Message-State: AIkVDXIKWQUCLNnJolRQUzM3EnXvt8zzwE4g94cYJQx4zJhdaZoOEeRGb1wKZPFGZ9AqHxuFiXJJp1WJl0ripQ==
X-Received: by 10.157.32.135 with SMTP id x7mr1880172ota.35.1484756119271; Wed, 18 Jan 2017 08:15:19 -0800 (PST)
MIME-Version: 1.0
Received: by 10.157.1.103 with HTTP; Wed, 18 Jan 2017 08:15:18 -0800 (PST)
In-Reply-To: <148429722186.26907.8095583118694640603.idtracker@ietfa.amsl.com>
References: <148429722186.26907.8095583118694640603.idtracker@ietfa.amsl.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Wed, 18 Jan 2017 08:15:18 -0800
Message-ID: <CA+RyBmU3XmrXvu2ZZ2VNxS60jneuMn_TfsrR2NZz3=L0uUKRVg@mail.gmail.com>
Subject: Re: Review of draft-ietf-mpls-residence-time-12
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
Content-Type: multipart/mixed; boundary=94eb2c033074117185054660b98a
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/h4PUzGTctTOGy0LrcRHMorE6Jfk>
Cc: "mpls@ietf.org" <mpls@ietf.org>, ops-dir@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 16:15:32 -0000

Hi Jurgen,
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 Fri, Jan 13, 2017 at 12:47 AM, <"Jürgen Schönwälder
<j.schoenwaelder@jac"@ietfa.amsl.com> wrote:

> Reviewer: Jürgen Schönwälder
> Review result: Has Nits
>
> I do not see any major OPS related issues. I am not an MPLS expert
> and
> this will likely show in my comments. Most of my comments below are
> editorial or trying to make the document easier to read for first
> time
> readers not deeply involved in the work.
>
> - Consider to avoid acronyms in the Abstract. I had to lookup what
>   G-ACh and PTP resolve to in order to read the abstract, which I
>   think should be avoided.
>
> - The sentence starting 'I.e.' in parenthesis in the Introduction
>   almost reads like a definition of Residence Time. Is it useful to
>   have this sentence in parenthesis and starting with 'I.e.'? It
> would
>   be nice to have a clear definition of Residence Time. In fact, my
>   reading is that residence time sometimes refers to the per hop
>   residence them and sometimes to the accumulated per path residence
>   time. Does it make sense to distinguish a Node Residence Time from
> a
>   Path Residence Time? Or a Residence Time from an Accumulated
>   Residence Time?
>
> - While reading section 3, I was wondering what are 1-step nodes and
>   what are 2-step nodes? This is later explained in detail inq
> section
>   7. Perhaps it makes sense to introduce the concept earlier and to
>   provide a forward pointer to section 7 for the details.
>
> - I suggest to either always write one-step and two-step or 1-step
> and
>   2-step. Mixing writing styles makes searching in the text a bit
> more
>   complicated.
>
> - The document seems to be PTP specific even though there are
>   provisions to support other time synchronization protocols. I
>   wonder, though, to what extend this would work for lets say NTP.
>   There is quite some text refering to the correctionField, which
>   seems to be a PTP-specific field.
>
> - s/Scratch Pad filed/Scratch Pad field/
>
> - Does the Interface ID related to other interface numbers, e.g.,
>   SNMP's ifIndex? Or is this an entirely separate number space? Or
>   does it depend on the implementor's choice?
>
> - In section 7, enumerated item 1, there is a hanging open
> parenthesis
>   which seem to have to sub-items inside. I suggest to change this by
>   s/forthcoming (this/forthcoming. This/
>
> - In section 8.3: s/.  .  /.  /
>
> - It may be useful to add instructions that the RFC editor is
> expected
>   to replace TBAx in the text once IANA has done the assignments.
>
> - What does 'particularly as applied to use related to PTP' mean?
>
>
>