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

[Martin Duke <[e-mail]>]

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 <
[e-mail]> 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 ([e-mail]) 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.
>
>
>
>