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

["Frank Brockners (fbrockne)" <[e-mail]>]

Hi Murray,

Thanks a lot for your review - and sorry about the delayed response. Please see inline ("..FB").

> -----Original Message-----
> From: Murray Kucherawy via Datatracker <[e-mail]>
> Sent: Donnerstag, 25. März 2021 08:15
> To: The IESG <[e-mail]>
> Cc: [e-mail]; [e-mail]; [e-mail];
> Al Morton <[e-mail]>
> Subject: Murray Kucherawy's Discuss on draft-ietf-ippm-ioam-data-12: (with
> DISCUSS and COMMENT)
> 
> Murray Kucherawy 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:
> ----------------------------------------------------------------------
> 
> I'd also like to discuss what's going on in Section 8.
> 
> Section 8.1, for instance, says that the registry covers 128 code points.  The first
> seven entries are given, but it's not explicit that a registration comprises a code
> point and (apparently) a name.  It's more typical to include a template that a
> new registration needs to include.  You might require a requested code point
> number and a name at minimum, but also commonly included in such a template
> is a reference to the registering RFC.  If I were to register a code point here in
> some later RFC, it would be awfully convenient to have the registry include a
> reference to that defining document.  As it stands, the registry will only ever
> point to this one.
> 
... FB: Thanks a lot for that suggestion - and Francesca had a very similar point (see reply to Francesca earlier today). For the next revision, we'll add templates to all the new registries. 
Here's a suggestion:

IOAM Option-Type Registry

IOAM Option-Type Registry template. New registration requests MUST use the following template:

  Name:
     Name of the newly registered option type.

  Code point:
     Desired value of the requested code point.
  
  Description:
     Brief description of the newly registered option type.

  Reference
     Reference to the document that defines the new option type.


The templates for the other registries would look very similar. 
The only difference would be for the namespace registry - given that the review process is slightly different, and there could be an allocation of a namespace-id even before an RFC is published. To reflect the different statuses of a registration entry, we could have a status field, which - much like what is done for URIs - could be either "permanent" (RFC is published) or "provisional" (successful expert review; RFC not yet published but envisioned)

IOAM Namespace-ID Registry

IOAM Namespace-ID Registry template. New registration requests MUST use the following 
Template:

  Name:
     Name of the newly registered Namespace-ID.

  Code point:
     Desired value of the requested Namespace-ID.
  
  Description:
     Brief description of the newly registered Namespace-ID.

  Reference
     Reference to the document that defines the new option type.

  Status
     Status of the registration: Permanent or Provisional. 
     Namespace-ID registrations following a successful expert review will have the status "provisional".
     Once the RFC, which defines the new Namespace-ID is published, the status is changed to "permanent".


> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> I support Francesca's DISCUSS position on both points.  In particular on the
> second, I wonder why this registry isn't being created following the
> provisional/permanent model that has been successful elsewhere, such as with
> URI schemes.

..FB: I hope that the above suggestion matches what you have in mind.

> 
> "SFC" appears in the glossary in Section 3, but nowhere else in the document.

...FB: Good catch. We'll remove it.

> 
> In Section 8:
> 
>    New registries in this group can be created via RFC Required process
>    as per [RFC8126].
> 
> Is there any other way to get IANA to create a sub-registry?

...FB: Francesca suggested to use “IETF Review”  ” instead of "RFC required", which very much reflects the way things are currently done in IPPM GW. The current work to define additional Flags, Option-Types, etc. are all following the “IETF Review” process already, i.e., there are working group drafts in IPPM for those. It would be very straight forward and even more natural to change to “IETF Review”. Given that Francesca suggested the change, the plan was to switch to “IETF Review” in the next revision. Would that work for you?

Thanks again, Frank

> 
>