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

[Francesca Palombini via Datatracker <[e-mail]>]

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.