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

From: "Frank Brockners (fbrockne)" <[email-masked]>
Date: Mon, 26 Apr 2021 10:19:11 +0000

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 <[email-masked]>
> Sent: Donnerstag, 25. März 2021 08:15
> To: The IESG <[email-masked]>
> Cc: [email-masked]; [email-masked]; [email-masked];
> Al Morton <[email-masked]>
> 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

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 26 Apr 2021 17:31:30 -0700

On Mon, Apr 26, 2021 at 3:19 AM Frank Brockners (fbrockne) <
[email-masked]> wrote:

> ...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?
>

Hi Frank,

My comment wasn't about the registries themselves, which can have any
policy you like, but rather this specific sentence about creating new
sub-registries in this group.  I don't think I've ever seen a declaration
that sub-registries can be created in any manner other than publication of
a new RFC.  So what I was really asking is whether the sentence I cited
here is even needed.

-MSK

---

From: "Frank Brockners (fbrockne)" <[email-masked]>
Date: Tue, 27 Apr 2021 06:54:50 +0000

Hi Murray,

From: Murray S. Kucherawy <[email-masked]>
Sent: Dienstag, 27. April 2021 02:32
To: Frank Brockners (fbrockne) <[email-masked]>
Cc: The IESG <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; Al Morton <[email-masked]>
Subject: Re: Murray Kucherawy's Discuss on draft-ietf-ippm-ioam-data-12: (with DISCUSS and COMMENT)

Hi Frank,

My comment wasn't about the registries themselves, which can have any policy you like, but rather this specific sentence about creating new sub-registries in this group.  I don't think I've ever seen a declaration that sub-registries can be created in any manner other than publication of a new RFC.  So what I was really asking is whether the sentence I cited here is even needed.

…FB: Thanks. Got it – and sorry that I did not catch the rhetoric nature of the question. We can of course remove the sentence – but IMHO it doesn’t hurt either, but just states the obvious as you say. If you ask to remove it, we’ll of course get rid of it. What would you suggest us doing?

Thanks, Frank

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 27 Apr 2021 13:01:22 -0700

On Mon, Apr 26, 2021 at 11:54 PM Frank Brockners (fbrockne) <
[email-masked]> wrote:

> *…FB: Thanks. Got it – and sorry that I did not catch the rhetoric nature
> of the question. We can of course remove the sentence – but IMHO it doesn’t
> hurt either, but just states the obvious as you say. If you ask to remove
> it, we’ll of course get rid of it. What would you suggest us doing?*
>

It's a non-blocking comment on my ballot, so I'm not insisting on a change
here.  I just think it's superfluous, and I subscribe to the theory that a
document is done "not when there's nothing more to add, but when there's
nothing left to take away".

-MSK