Subject: [ippm] I-D Action: draft-ietf-ippm-ioam-yang-02.txt

From: [email-masked]
Date: Thu, 13 Jan 2022 17:08:45 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Performance Measurement WG of the IETF.

        Title           : A YANG Data Model for In-Situ OAM
        Authors         : Tianran Zhou
                          Jim Guichard
                          Frank Brockners
                          Srihari Raghavan
	Filename        : draft-ietf-ippm-ioam-yang-02.txt
	Pages           : 26
	Date            : 2022-01-13

Abstract:
   In-situ Operations, Administration, and Maintenance (IOAM) records
   operational and telemetry information in user packets while the
   packets traverse a path between two points in the network.  This
   document defines a YANG module for the IOAM function.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-yang/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-yang-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ippm-ioam-yang-02

Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts

---

From: t petch <[email-masked]>
Date: Fri, 14 Jan 2022 09:59:49 +0000

This looks like 'it has been another six months so it is time to 
re-submit' I-D.  I note that the YANG module date remains at 2021 which 
seems a useful indicator!

Tom Petch

On 14/01/2022 01:08, [email-masked] wrote:
> _______________________________________________
> ippm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ippm
> .
>

---

From: Tianran Zhou <[email-masked]>
Date: Fri, 14 Jan 2022 10:30:35 +0000

Hi Tom,
I am sorry. The date is not correct. But the date in the YANG model is correct.
The major improvement is about the ioam info.
We collected some requirements and added in.

Best,
Tianran

________________________________

Sent from WeLink
发件人： t petch<[email-masked]<mailto:[email-masked]>>
收件人： ippm<[email-masked]<mailto:[email-masked]>>
主题： Re: [ippm] I-D Action: draft-ietf-ippm-ioam-yang-02.txt
时间： 2022-01-14 18:00:43

Tom Petch

---

From: t petch <[email-masked]>
Date: Mon, 17 Jan 2022 12:25:02 +0000

> We collected some requirements and added in.

Indeed; it is completely different.  I don't know what I was looking at:-(

'namespace' confuses me.  In ioam-data, it is 16 bit.  Here it is 
identity.  How do you map one to the other?

pot-type seems similar; it is an 8-bit field for which you have type and 
identity.  I think that ioam-data does a bad job of explaining how 
pot-type are identified.  The text has changed a lot but not in  a 
coherent manner IMHO and if you are trying to model something 
incoherent, well, then the model is likely to be incoherent.  (I 
appreciate that ioam-data is with the RFC Editor so there is hope for it 
yet:-)

I would find it clearer if the five options were listed as such, in a 
list, with references, probably in the Introduction.

What is  a timestamp subsecond?  Is it a nanosecond?

/prove/proof/ mostly fixed but not quite all; likewise edge-to-edge

/http:tools/https:datatracker/

/RFC RFC 8532/RFC 8532/
and it needs adding to the I-D References

/for encapsulate/ to encapsulate/
("for encapsulation" is fine)

YANG module references I find clearer as e.g.
"RFC YYYY: Data Fields for In-situ OAM"
since that is the name for the long term, I-D names are ephemeral

I think that many of the YANG identifiers are prolix e..g.
identity ipv6-protocol
base base-protocol

only needs
identity ipv6
base protocol
IMHO
  Any use of base, protocol, type , action etc is likely to be 
unnecessary, confusing even; probably most uses of trace too.  You may 
find that your YANG Doctor makes a few hundred comments along these 
lines - most do.

Security Considerations is out of date

Tom Petch

---

From: Tianran Zhou <[email-masked]>
Date: Tue, 25 Jan 2022 09:57:28 +0000

Hi Tom,
Thanks very much for your detailed review.
I just submitted a new revision to address your comments.
https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-yang/
Some replies please see in line.

Best,
Tianran

-----Original Message-----
From: t petch [mailto:[email-masked]] 
Sent: Monday, January 17, 2022 8:25 PM
To: Tianran Zhou <[email-masked]>; ippm <[email-masked]>
Subject: Re: [ippm] I-D Action: draft-ietf-ippm-ioam-yang-02.txt

'namespace' confuses me.  In ioam-data, it is 16 bit.  Here it is identity.  How do you map one to the other?

pot-type seems similar; it is an 8-bit field for which you have type and identity.  I think that ioam-data does a bad job of explaining how pot-type are identified.  The text has changed a lot but not in  a coherent manner IMHO and if you are trying to model something incoherent, well, then the model is likely to be incoherent.  (I appreciate that ioam-data is with the RFC Editor so there is hope for it
yet:-)

ZTR> I revised the namespace and pot-type description, introduced the mapping.

I would find it clearer if the five options were listed as such, in a list, with references, probably in the Introduction.

ZTR> Yes. I listed in the introduction.

/RFC RFC 8532/RFC 8532/

ZTR> I updated all the above nits. But I forgot to add the ID reference. :P
Will add in the next version. 

only needs
identity ipv6
base protocol
IMHO
  Any use of base, protocol, type , action etc is likely to be unnecessary, confusing even; probably most uses of trace too.  You may find that your YANG Doctor makes a few hundred comments along these lines - most do.

ZTR> Yes, I revised all the above.

Tom Petch

> re-submit' I-D.  I note that the YANG module date remains at 2021 
> which seems a useful indicator!
>
> Tom Petch
>