From nobody Thu Mar 25 10:49:39 2021 Return-Path: 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 Date: Thu, 25 Mar 2021 10:49:18 -0700 Message-ID: To: Francesca Palombini Cc: The IESG , "MORTON, ALFRED C (AL)" , IPPM Chairs , draft-ietf-ippm-ioam-data@ietf.org, IETF IPPM WG Content-Type: multipart/alternative; boundary="00000000000073341e05be6009fb" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Mar 2021 17:49:35 -0000 --00000000000073341e05be6009fb Content-Type: text/plain; charset="UTF-8" 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. > > > > --00000000000073341e05be6009fb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Francesca,

Which "Po= int 5" are you referring to in your DISCUSS? Is it the fifth item in y= our COMMENT?

On Wed, Mar 24, 2021 at 12:05 PM Francesca Palombini = via Datatracker <noreply@ietf.org> wrote:
Fra= ncesca 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/s= tatement/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-ie= tf-ippm-ioam-data/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thank you for this document. I think that the discussion on point 5. about<= br> 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. -----

=C2=A0 =C2=A0document are to be interpreted as described in [RFC2119].

FP: Please update the boilerplate as per RFC 8147.

2. -----

=C2=A0 The specification of how IOAM-Data-Fields
=C2=A0 =C2=A0are encapsulated into "parent" protocols, like e.g.,= NSH or IPv6 is
=C2=A0 =C2=A0outside 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. -----

=C2=A0 =C2=A0 =C2=A0 For example, if 3 IOAM-Trace-Type bits are set and non= e of them
=C2=A0 =C2=A0 =C2=A0 are wide, then NodeLen would be 3.=C2=A0 If 3 IOAM-Tra= ce-Type bits are

FP: As this is the first time the term "wide" appears, it would b= e good to
define it and add a reference. Alternatively, a sentence in the terminology=
might have helped too.

4. -----

=C2=A0 =C2=A0 =C2=A0 Bit 3=C2=A0 =C2=A0 When set, indicates presence of tim= estamp subseconds in

FP: Same as for 3. - please add a reference to where "subsecond" = is defined.

5. -----

=C2=A0 =C2=A0formats; based on either PTP [IEEE1588v2], NTP [RFC5905], or P= OSIX
=C2=A0 =C2=A0[POSIX].=C2=A0 The three timestamp formats are specified in Se= ction 6.=C2=A0 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 8= 877
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. -----

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0computation, indicates which POT-profile = is used.=C2=A0 The two
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0profiles are numbered 0, 1.

FP: (just a comment) I found strange at this point that although two profil= es
are mentioned, only one is defined in this document.

7. -----

=C2=A0 =C2=A0Namespace-ID:=C2=A0 16-bit identifier of an IOAM-Namespace.=C2= =A0 The

FP: Each option-type starts with Namespace-ID: couldn't this be optimiz= ed, or
what is the reasoning behind this?

8. -----

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0IOAM domain.=C2=A0 W= ithin the IOAM encapsulating node, the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0time that the timest= amp is retrieved can depend on the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0implementation.=C2= =A0 Some possibilities are: 1) the time at

=C2=A0 =C2=A0in one of three possible timestamp formats.=C2=A0 It is assume= d that the
=C2=A0 =C2=A0management plane is responsible for determining which timestam= p
=C2=A0 =C2=A0format 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. -----

=C2=A0 =C2=A0New registries in this group can be created via RFC Required p= rocess
=C2=A0 =C2=A0as 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 th= e
reasoning for not going for IETF Review?

10. -----

=C2=A0 =C2=A0The meaning for Bits 1 - 7 are available for assignment via RF= C
=C2=A0 =C2=A0Required process as per [RFC8126].

FP: From section 5.5 the bits 1-7 are indicated as Reserved.

11. -----

=C2=A0 =C2=A0of the current document.=C2=A0 Registry entries for the values= 0x8000 to
=C2=A0 =C2=A00xFFFF are to be assigned via the "Expert Review" po= licy defined in
=C2=A0 =C2=A0[RFC8126].=C2=A0 Upon a new allocation request, the responsibl= e AD will
=C2=A0 =C2=A0appoint a designated expert, who will review the allocation re= quest.
=C2=A0 =C2=A0The expert will post the request on the mailing list of the IP= PM
=C2=A0 =C2=A0working group in the IETF (ippm@ietf.org), and possibly on other
=C2=A0 =C2=A0relevant mailing lists, to allow for community feedback.=C2=A0= Based on
=C2=A0 =C2=A0the review, the expert will either approve or deny the request= .=C2=A0 The
=C2=A0 =C2=A0intention is that any allocation will be accompanied by a publ= ished
=C2=A0 =C2=A0RFC.=C2=A0 But in order to allow for the allocation of values = prior to the
=C2=A0 =C2=A0RFC being approved for publication, the designated expert can = approve
=C2=A0 =C2=A0allocations once it seems clear that an RFC will be published.=

FP: The text above indicates Expert review for the registry. According to R= FC
8126:

=C2=A0 =C2=A0The required documentation and review criteria, giving clear g= uidance
=C2=A0 =C2=A0to the designated expert, should be provided when defining the=
=C2=A0 =C2=A0registry.=C2=A0 It is particularly important to lay out what s= hould be
=C2=A0 =C2=A0considered when performing an evaluation and reasons for rejec= ting a
=C2=A0 =C2=A0request.

Although the paragraph above gives some indication of process for the exper= ts,
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 -<= br> these same criteria will be considered by the working group as well.



--00000000000073341e05be6009fb--