Subject: Re: [Last-Call] Last Call: <draft-ietf-ippm-ioam-data-11.txt> (Data Fields for In-situ OAM) to Proposed Standard

From: tom petch <[email-masked]>
Date: Wed, 2 Dec 2020 10:36:58 +0000

This I-D seems at odds with RFC8126 over the use of Expert Review in s.8.7

' The responsible AD will appoinht ...'
RFC8126 seems clear that the IESG appoints and may do so in advance and 
having more than one is recommended

'the expert will approve or deny..'
RFC8126 seems clear that that is the role of IANA.  The expert 
recommends and it is then up to IANA to act

'the expert can approve allocations.
No, that is the role of IANA; early allocation is possible but that is 
the decision of IANA.

On 24/11/2020 18:23, The IESG wrote:
>
> The IESG has received a request from the IP Performance Measurement WG (ippm)
> to consider the following document: - 'Data Fields for In-situ OAM'
>    <draft-ietf-ippm-ioam-data-11.txt> as Proposed Standard
>
> The IESG plans to make a decision in the next few weeks, and solicits final
> comments on this action. Please send substantive comments to the
> [email-masked] mailing lists by 2020-12-08. Exceptionally, comments may
> be sent to [email-masked] instead. In either case, please retain the beginning
> of the Subject line to allow automated sorting.
>
> Abstract
>
>
>     In-situ Operations, Administration, and Maintenance (IOAM) records
>     operational and telemetry information in the packet while the packet
>     traverses a path between two points in the network.  This document
>     discusses the data fields and associated data types for in-situ OAM.
>     In-situ OAM data fields can be encapsulated into a variety of
>     protocols such as NSH, Segment Routing, Geneve, IPv6 (via extension
>     header), or IPv4.  In-situ OAM can be used to complement OAM
>     mechanisms based on e.g.  ICMP or other types of probe packets.
>
>
>
>
> The file can be obtained via
> https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-data/
>
>
> The following IPR Declarations may be related to this I-D:
>
>     https://datatracker.ietf.org/ipr/3526/
>
>
>
>
>
>
> _______________________________________________
> IETF-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-announce
> .
>

---

From: tom petch <[email-masked]>
Date: Wed, 2 Dec 2020 10:46:24 +0000

' the responsible AD will appoint ...'
RFC8126 seems clear that the IESG appoints and may do so in advance and 
having more than one expert is recommended

'the expert will approve or deny..'
RFC8126 seems clear that that is the role of IANA.  The expert 
recommends and it is then up to IANA to accept or reject.

'the expert can approve allocations.'
No, that is the role of IANA; early allocation is possible but that is 
the decision of IANA.

In passing,
'The meaning of bit 0
perhaps better as value 0

s.8.1
/this draft/this memo/

s.3
needs updating to conform to RFC8174

Tom Petch

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 2 Dec 2020 15:32:00 +0000

Let me comment on this. I've been one of the three TLS registry experts for a couple of years. TL;DR I think the draft is not in conflict with how things are done.

On 12/2/20, 5:37 AM, "tom petch" <[email-masked]> wrote:

Well, the AD is part of the IESG. From what I have seen, registry experts are always appointed by the AD's, as they are expected to be the subject matter experts.

IANA's actions are updating the registry. The expert(s) recommendations are binding.

If there's an expert, IANA will forward to the expert(s) and ask what to do.

I think reading Section 5 justifies my views above.  Perhaps 8126 is not internally consistent in some of these details.

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 2 Dec 2020 07:34:00 -0800

> Well, the AD is part of the IESG. From what I have seen, registry experts are always appointed by the AD's, as they are expected to be the subject matter experts.

A single AD is tasked with finding volunteers to be expert(s), but the IESG
as a whole approves them.

-Ben