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. > > > >
- [ippm] Francesca Palombini's Discuss on draft-iet… Francesca Palombini via Datatracker
- Re: [ippm] Francesca Palombini's Discuss on draft… Martin Duke
- Re: [ippm] Francesca Palombini's Discuss on draft… Francesca Palombini
- Re: [ippm] Francesca Palombini's Discuss on draft… Francesca Palombini
- Re: [ippm] Francesca Palombini's Discuss on draft… Frank Brockners (fbrockne)
- Re: [ippm] Francesca Palombini's Discuss on draft… Frank Brockners (fbrockne)
- Re: [ippm] Francesca Palombini's Discuss on draft… Francesca Palombini
- Re: [ippm] Francesca Palombini's Discuss on draft… Frank Brockners (fbrockne)