Re: [ippm] Francesca Palombini's Discuss on draft-ietf-ippm-ioam-data-12: (with DISCUSS and COMMENT)

Martin Duke <martin.h.duke@gmail.com> Thu, 25 March 2021 17:49 UTC

Return-Path: <martin.h.duke@gmail.com>
X-Original-To: ippm@ietfa.amsl.com
Delivered-To: ippm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AE1B3A28A1; Thu, 25 Mar 2021 10:49:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 7DMqvjsQwbhO; Thu, 25 Mar 2021 10:49:29 -0700 (PDT)
Received: from mail-il1-x132.google.com (mail-il1-x132.google.com [IPv6:2607:f8b0:4864:20::132]) (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 4411F3A2895; Thu, 25 Mar 2021 10:49:29 -0700 (PDT)
Received: by mail-il1-x132.google.com with SMTP id r8so2821482ilo.8; Thu, 25 Mar 2021 10:49:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0m7hL+5Lxr9f8PAQeZ8eMMCqMkAfF/HI4qAxix2Nz0g=; b=QZWBQ3B/cPFlCb94E+oR7byErW9uqsETiRSZ5i60boD7Svo0a5hyqhJMjTcT6Gh45l Dt5uNqPhxnGyWSeh8H+/xFHChgyckvPJgLKLCbKrnZbIUwZqA1LhFaZL+uIa8KTQTn/B KXrEB+dmaR3CDATmGq/zgZrBpZ323cpL2133AQ1voVt0tWYT3PipJpcKmM5RA/pwP/v1 lVsPUr2EM2NsPpd3UVf0yIG7ll1qlsEBQeoKiUzT0Wp4SAcM/gKY3JSbH/VZph55k6lN ppvKWzW/EuwH7Bdp9XKWwIUzC4hkBS3E30a0SkvgvoiOf7JT3fEwGkvUFnwwXCMLxayn 55ww==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0m7hL+5Lxr9f8PAQeZ8eMMCqMkAfF/HI4qAxix2Nz0g=; b=oDAviYdzIkAedp87vkQenTo6Vt374xqfJY0yHBGq45zZap1rtG0cMuqCBitqtMLdO0 hmd6qBLCJk+QeRnJhnZwM864QKaRE9n232zhFxtoWUjUeaNe9TBVGwVQbLoAEyyTf+wu Tdpbrzl/fwxR/MCeCoQQKlre2x3mEkrqczTqa09ewdLfuIDDwQ9cjfwJzcESRRiAFL/j z/XCT59jLlep1qnsWDk58fMPOpGYH5PF6IWy1+std4qZl6FVRyB4SVr7V5NZqh/n1xUL j36n3yXwPSdOfhwibpb7JQ4URHr7M7tSidWw7qG/LjBTOGDTng3lAZRr075c6fSuPi+P u8Fg==
X-Gm-Message-State: AOAM533NGOxMHymyY5JIduP8+eUvh5NeV1irODhEFGvv10j2S9Not5P0 8h+RdJ8Z4nvVD3HuI5KWhptucgoUG78dZpkR4VI=
X-Google-Smtp-Source: ABdhPJw4Tc1HpmRP2YBy2MEGMWcP/8YQ/AghDET6lx67UGmEATQ3jElDaGa8fmIXdyvmWX4B7/7t5zmAeJ9yvefI900=
X-Received: by 2002:a05:6e02:1e03:: with SMTP id g3mr7413610ila.249.1616694568234; Thu, 25 Mar 2021 10:49:28 -0700 (PDT)
MIME-Version: 1.0
References: <161661268673.916.16348206674906302793@ietfa.amsl.com>
In-Reply-To: <161661268673.916.16348206674906302793@ietfa.amsl.com>
From: Martin Duke <martin.h.duke@gmail.com>
Date: Thu, 25 Mar 2021 10:49:18 -0700
Message-ID: <CAM4esxSYaE27gPRjAuWuZkimW5TLW2J+jrm-7R5r-Wah6OvEsA@mail.gmail.com>
To: Francesca Palombini <francesca.palombini@ericsson.com>
Cc: The IESG <iesg@ietf.org>, "MORTON, ALFRED C (AL)" <acm@research.att.com>, IPPM Chairs <ippm-chairs@ietf.org>, draft-ietf-ippm-ioam-data@ietf.org, IETF IPPM WG <ippm@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000073341e05be6009fb"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/paotTTF7rUr9-6i16wg2hy2Bfxs>
Subject: Re: [ippm] Francesca Palombini's Discuss on draft-ietf-ippm-ioam-data-12: (with DISCUSS and COMMENT)
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ippm>, <mailto:ippm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ippm/>
List-Post: <mailto:ippm@ietf.org>
List-Help: <mailto:ippm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Mar 2021 17:49:35 -0000

Hi Francesca,

Which "Point 5" are you referring to in your DISCUSS? Is it the fifth item
in your COMMENT?

On Wed, Mar 24, 2021 at 12:05 PM Francesca Palombini via Datatracker <
noreply@ietf.org> wrote:

> Francesca Palombini has entered the following ballot position for
> draft-ietf-ippm-ioam-data-12: Discuss
>
> 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-ippm-ioam-data/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> Thank you for this document. I think that the discussion on point 5. about
> referencing normatively IEEE 1588, and 11. about IANA Expert guidelines are
> worth having, and hope we can get them cleared before the document moves
> forward. Also, please find some minor comments below.
>
> Francesca
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> 1. -----
>
>    document are to be interpreted as described in [RFC2119].
>
> FP: Please update the boilerplate as per RFC 8147.
>
> 2. -----
>
>   The specification of how IOAM-Data-Fields
>    are encapsulated into "parent" protocols, like e.g., NSH or IPv6 is
>    outside the scope of this document.
>
> FP: This sentence (or equivalent) appears several times - at least 2 times
> in
> section 4 and once more in 5.1 - please consider removing the repetition.
>
> 3. -----
>
>       For example, if 3 IOAM-Trace-Type bits are set and none of them
>       are wide, then NodeLen would be 3.  If 3 IOAM-Trace-Type bits are
>
> FP: As this is the first time the term "wide" appears, it would be good to
> define it and add a reference. Alternatively, a sentence in the terminology
> might have helped too.
>
> 4. -----
>
>       Bit 3    When set, indicates presence of timestamp subseconds in
>
> FP: Same as for 3. - please add a reference to where "subsecond" is
> defined.
>
> 5. -----
>
>    formats; based on either PTP [IEEE1588v2], NTP [RFC5905], or POSIX
>    [POSIX].  The three timestamp formats are specified in Section 6.  In
>
> FP: Is the normative reference to IEEE 1588 (behind a paywall) absolutely
> necessary? Rob Wilton pointed out that maybe a normative reference to RFC
> 8877
> would be enough, however that would create a downref since 8877 is
> informational. Also (minor) if kept, please consider updating to IEEE
> 1588-2019.
>
> 6. -----
>
>          computation, indicates which POT-profile is used.  The two
>          profiles are numbered 0, 1.
>
> FP: (just a comment) I found strange at this point that although two
> profiles
> are mentioned, only one is defined in this document.
>
> 7. -----
>
>    Namespace-ID:  16-bit identifier of an IOAM-Namespace.  The
>
> FP: Each option-type starts with Namespace-ID: couldn't this be optimized,
> or
> what is the reasoning behind this?
>
> 8. -----
>
>                IOAM domain.  Within the IOAM encapsulating node, the
>                time that the timestamp is retrieved can depend on the
>                implementation.  Some possibilities are: 1) the time at
>
>    in one of three possible timestamp formats.  It is assumed that the
>    management plane is responsible for determining which timestamp
>    format is used.
>
> FP: This is worrying for interoperability within different implementations.
> Maybe more details or guidelines about how the management plane deals with
> this
> (or references to relevant specification for which this is in scope) would
> help.
>
> 9. -----
>
>    New registries in this group can be created via RFC Required process
>    as per [RFC8126].
>
> FP: (asking as this was not included in the shepherd review, and just want
> to
> make sure this was addressed) For this and following registries: what is
> the
> reasoning for not going for IETF Review?
>
> 10. -----
>
>    The meaning for Bits 1 - 7 are available for assignment via RFC
>    Required process as per [RFC8126].
>
> FP: From section 5.5 the bits 1-7 are indicated as Reserved.
>
> 11. -----
>
>    of the current document.  Registry entries for the values 0x8000 to
>    0xFFFF are to be assigned via the "Expert Review" policy defined in
>    [RFC8126].  Upon a new allocation request, the responsible AD will
>    appoint a designated expert, who will review the allocation request.
>    The expert will post the request on the mailing list of the IPPM
>    working group in the IETF (ippm@ietf.org) and possibly on other
>    relevant mailing lists, to allow for community feedback.  Based on
>    the review, the expert will either approve or deny the request.  The
>    intention is that any allocation will be accompanied by a published
>    RFC.  But in order to allow for the allocation of values prior to the
>    RFC being approved for publication, the designated expert can approve
>    allocations once it seems clear that an RFC will be published.
>
> FP: The text above indicates Expert review for the registry. According to
> RFC
> 8126:
>
>    The required documentation and review criteria, giving clear guidance
>    to the designated expert, should be provided when defining the
>    registry.  It is particularly important to lay out what should be
>    considered when performing an evaluation and reasons for rejecting a
>    request.
>
> Although the paragraph above gives some indication of process for the
> experts,
> it does not give clear review criteria or guidance. I would suggest this
> to be
> expanded to give more indication to experts on what criteria to consider -
> these same criteria will be considered by the working group as well.
>
>
>
>