Re: [ippm] Second WGLC for draft-ietf-ippm-ioam-data

Hi Tommy and Draft ioam-data Authors,

After completing one pass through the memo in the role of Doc Shepherd,
I ended-up with a few comments that are more like WGLC comments than
those of the shepherd.  Since we are only a few days over WGLC closure,
I have uploaded the preliminary shepherd write-up and share
the comments for optional action below (I don’t think these comments
should have any special status, IOW).

It is clear that lots of work an negotiation went into the present text.
I appreciate that fact and thank all who participated for preparing
an excellent draft.

The current shepherd’s write-up [0] is available for comment, as well.

Al
(as doc shepherd)

[0] https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-data/shepherdwriteup/

Doc Shepherd's Comments:

Closed PR https://github.com/inband-oam/ietf/pull/96
Two Comments indicate the value of a Manageability Considerations section while resolving issues in the discussion. However, the -09 version still does not have this section a year later... The important topic discussed was congestion management, but there are no instances of "congest" in the -09 text.  (more, see below)

Section 3, Scope, etc. contains the topic:
Deployment domain (or scope) of in-situ OAM deployment:, in which many operational considerations are detailed that could be part of a Manageability Considerations: section.

4.4 Trace Option types
...
   ...The maximum number of hops and the minimum path MTU of the IOAM domain is assumed
   to be known.

What are the consequences when they are not known?
     Looks like the Flag Bit 0 O-bit handles this case for number of hops.  (Add this here?)

Or, is this knowledge highly likely, and expected to be violated only under the most unexpected conditions (restoration from multiple failures)?
See point below on "minimum path MTU".

4.4.1
RemainingLen:
...
      Given that the sender knows the minimum path MTU, the sender MAY
      set the initial value of RemainingLen according to the number of
      node data bytes allowed before exceeding the MTU.
"minimum path MTU" is the smallest Maximum Transmission Unit for all links in a path, or simply the Path MTU, PMTU, right?
https://en.wikipedia.org/wiki/Path_MTU_Discovery

4.5 Proof of Transit

Is there a Reference for "Shamir's Secret Sharing Schema (SSSS)" ?
Or, is it a secret?

7.  IANA Considerations
(apologies in advance for a long/recent/good experience with IANA, and the many other folks who try to help our friends at IANA)
This section appears to define a set of related registries.
The hierarchy could be named a bit more efficiently than:

7.1 In-Situ OAM Protocol Parameters Registry (IOAM) Protocol Parameters IANA registry

Suggest:
In-Situ OAM (IOAM) Protocol Parameters Group
7.1  IOAM Protocol Parameters Registry
     7.2  IOAM Option-Type Registry
     7.3  IOAM Trace-Type Registry
       ...

From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of Tommy Pauly
Sent: Thursday, May 28, 2020 12:43 PM
To: Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org>; IETF IPPM WG <ippm@ietf.org>
Subject: Re: [ippm] Second WGLC for draft-ietf-ippm-ioam-data

Our WGLC call for draft-ietf-ippm-ioam-data is now concluded! Thanks everyone.

I’ve marked the document as having WG consensus, and needing a revised I-D (to incorporate Martin’s comments). Once that is ready and we have the shepherd write-up, we’ll submit this to the IESG.

As a reminder, we are still in the WGLC for draft-ietf-ippm-stamp-option-tlv. Please review and comment if you have not already!

Thanks,
Tommy

On May 14, 2020, at 10:16 AM, Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org<mailto:tpauly=40apple.com@dmarc.ietf.org>> wrote:

Hi IPPM,

At our virtual interim meeting, we decided to put draft-ietf-ippm-ioam-data through a second last call, based on the new revisions, in mid-May. This email starts a two-week WGLC for this draft.

The latest version can be found here: https://tools.ietf.org/html/draft-ietf-ippm-ioam-data-09<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dippm-2Dioam-2Ddata-2D09&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=YwMkvN3mqHRxnwcgkB4l4psDqQViP1UTeOxJeyv5T7k&s=_Lv2krlY6UiX1GbDsvMqDhkXEWZf66f0UkBcR3O3csg&e=>

This last call will end on Thursday, May 28. Please reply to ippm@ietf.org<mailto:ippm@ietf.org> with your reviews and comments.

Thanks,
Tommy & Ian
_______________________________________________
ippm mailing list
ippm@ietf.org<mailto:ippm@ietf.org>
https://www.ietf.org/mailman/listinfo/ippm<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ippm&d=DwQFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=YwMkvN3mqHRxnwcgkB4l4psDqQViP1UTeOxJeyv5T7k&s=BSOHsMgZ_JR-B6_CAnlIGEEoEv1CXcvWQ-vOS7UsHRg&e=>