Re: [Teas] FW: New Version Notification for draft-lee-teas-actn-pm-telemetry-autonomics-12.txt

[Leeyoung <[e-mail]>]

Hi Tom,



Thanks for your comments. You are really making WG chairs job easier ☺. This is still an individual draft and I hope the revision (v.16) is good enough to be considered for WG adoption.



Please see the diff file and also my comment inline. https://www.ietf.org/rfcdiff?url2=draft-lee-teas-actn-pm-telemetry-autonomics-16



Thanks,

Young



-----Original Message-----

From: tom petch [mailto:[e-mail]]

Sent: Monday, April 15, 2019 5:32 AM

To: Leeyoung <[e-mail]>; TEAS WG Chairs <[e-mail]>

Cc: TEAS WG <[e-mail]>

Subject: Re: [Teas] FW: New Version Notification for draft-lee-teas-actn-pm-telemetry-autonomics-12.txt



Young



I may have confused you concerning the Note to RFC Editor.  It is fine to use the same Acronym in many places within the I-D, in fact it is simpler IMHO, so where you want a reference to the RFC to be, it is fine to use 'WWWW' every time, in the YANG modules, IANA Considerations etc.

Not wrong to use AAAA in addition but more complicated IMHO.



But you do seem to give XXXX two different meanings,

  /* Note: The RFC Editor will replace XXXX with the number

     assigned to the RFC once draft-ietf-teas-actn-vn-yang

    becomes an RFC.*/

  /* Note: The RFC Editor will replace AAAA with the number

     assigned to the RFC once draft-lee-teas-pm-telemetry-

     autonomics becomes an RFC.*/

Conventionally, XXXX is the I-D itself throughout the I-D with YYYY AAAA etc referring to other I-D.



YL>> OK. Agreed and changed as you pointed out. I would use XXXX referring to this I-D itself while use YYYY referring to all other I-Ds.



Also, when I asked the RFC Editor they said that they preferred the Notes asking them to replace XXXX YYYY etc with the numbers assigned to the RFC to-be all together at the front; not sure exactly where but just before or after the Introduction seems suitable.  It is also then easier to spot the reuse of XXXX:-)



YL>> This is actually in the IANA section. Once this draft is adopted and under review of RFC Editor, we can address this issue then.



In IANA Considerations, RFC6020 is the preferred reference since all

RFC7950 says is go read RFC6020.



YL>> Since this draft is based on YANG1.1, I believe RFC7950 is the right reference.



I am curious as to why the I-D has six authors when the YANG modules have four.



YL>> Authors and YANG module contributors are not always the same. In our case, there are folks who contributed for the document but not for YANG itself. Hope this explains.



KPI could do with expanding on first use; perhaps OLD

         Key performance

   indicator is a term that describes critical performance data that

   may affect VN/TE-tunnel service.

NEW

   KPI( Key Performance

  Indicator) is a term that describes critical performance data that

   may affect VN/TE-tunnel service.



YL>> Thanks. Will expand as you suggested.



S.1

"The models presented in this draft allow the applications hosted by  the customers to subscribe and monitor their key performance data of

   their interest on the level of VN [VN] or TE-tunnel [TE-Tunnel]. "



is not quite right; 'subscribe' is usually 'to' something, such as alerts, notifications etc as you later have "subscribes to the

     VN level telemetry"



Likewise in s.5.1

    Subscribe notifications on a per client basis.

could perhaps be

    Subscribe to notifications on a per client basis.



YL>> s/subscribe/subscribe to



There a number of such places where the English is a bit quirky but my take is to leave most of that until later since the text may get changed anyway.



YL>> I am sure there are many places English can be improved. Hopefully, once adopted and going through shepherd review, etc. the draft will have opportunities for improvement. Thanks.



Tom Petch





----- Original Message -----

From: "Leeyoung" <[e-mail]>

Sent: Friday, April 12, 2019 9:35 PM





> Hi Tom,

>

> Getting there hopefully with this iteration...

>

> Thanks for your further comment. I think I addressed all your comments

for this round. Please see inline for my comment and the diff file to make it easier for you to review your comment.

>

>

https://www6.ietf.org/rfcdiff/?url2=draft-lee-teas-actn-pm-telemetry-aut

onomics-15 See also the attachment for the details.

>

> Thanks & Have a good weekend.

>

> Young

>

> -----Original Message-----

>

> From: tom petch [mailto:[e-mail]]

> Sent: Friday, April 12, 2019 11:38 AM

>

> Young

>

> I am less confused:-)

>

> The Copyright statements are incomplete; look, for example, at RFC8294

and you lack the final sentence which provides the required link back to the RFC to be, one of the missing references I referred to earlier.

>

>

>

> YL>> Included in both YANG modules with:

>

>

>

> This version of this YANG module is part of RFC AAAA; see

>

>      the RFC itself for full legal notices.;

>

>

>

>   /* Note: The RFC Editor will replace AAAA with the number

>

>      assigned to the RFC once draft-lee-teas-pm-telemetry-

>

>      autonomics becomes an RFC.*/

>

>

>

> Recall that the YANG modules will be extracted and widely used with

nothing else to support them, so from 'CODE BEGINS' to 'CODE ENDS' must be comprehensible standing alone.  Again, look at RFC8294 and you will see reference clauses in the description, which I think are needed in each and every YANG module and one per object is not too many.

>

>

>

> Thus, within the IETF, IPPM have done much on one-way and two-way

delay; do you mean the same as they do? If not, where do your definitions thereof come from?  ITU-T (who are also hot on this)?

>

>

>

> YL>> Added the reference for each performance related parameters in

the ietf-te-kpi-telemetry module come from.

>

>

>

> reference

>

>       "RFC7471<https://tools.ietf.org/html/rfc7471>: OSPF Traffic

Engineering (TE) Metric Extensions.

>

>        RFC8570<https://tools.ietf.org/html/rfc8570>: IS-IS Traffic

Engineering (TE) Metric Extensions.

>

>        RFC7823<https://tools.ietf.org/html/rfc7823>: Performance-Based

Path Selection for Explicitly

>

>        Routed Label Switched Paths (LSPs) Using TE Metric

>

>        Extensions";

>

>

>

>

>

> This makes me note that there are no default values nor guidance as to

what to use; again, references here help, if only to the RFC to be.

>

> Human nature suggests the people will use whatever they can see so

that following s.4 we could see a lot of

>

>

>

> Threshold-time: 3600 (sec)

>

> Cooldown-time:  60 (sec)

>

> threshold-value: 300 mile-seconds [milli?]

>

> threshold-value: 300 megabytes

>

>

>

> which may, or may not, be suitable values.

>

>

>

> Related to this, common practice is to put examples in an Appendix,

the idea being that examples are not Normative and Appendices are not Normative, whereas the body of the document is, which examples are not.

>

> Examples in the body may be blindly followed.

>

>

>

> YL>> I changed the numeric values to XYZ’s so that people would not

get misguided with the illustration. There is not really default value for each of these parameters as they are depending on the use-cases and applications. Keeping the examples in the main body with non-numeric examples, I think, should be fine. Changed mile-seconds to milli-seconds. These parameters are quite generic that they don’t have proper references per se.

>

>

>

> HTH

>

>

>

> Tom Petch

>

>

>

>

>

> ----- Original Message -----

>

> From: "Leeyoung" <[e-mail]>

>

> To: "tom petch" <[e-mail]>; "TEAS WG Chairs"

>

> <[e-mail]>

>

> Cc: "TEAS WG" <[e-mail]>

>

> Sent: Wednesday, April 10, 2019 6:06 PM

>

>

>

> > Hi Tom,

>

> >

>

> > Thanks. I think there is still some inconsistency as you pointed

out.

>

> Please see inline. This should be it. I uploaded v.14 that

incorporated all your comments. Attached is the new version notification and the below is the pointer for the diff.

>

> >

>

> >

>

>

https://www6.ietf.org/rfcdiff/?url2=draft-lee-teas-actn-pm-telemetry-aut

>

> onomics-14

>

> >

>

> > Please let me know if any further fix is needed.

>

> >

--- Begin Message ---

A new version of I-D, draft-lee-teas-actn-pm-telemetry-autonomics-16.txt
has been successfully submitted by Young Lee and posted to the
IETF repository.

Name:           draft-lee-teas-actn-pm-telemetry-autonomics
Revision:       16
Title:          YANG models for VN & TE Performance Monitoring Telemetry and Scaling Intent Autonomics
Document date:  2019-04-18
Group:          Individual Submission
Pages:          29
URL:            https://www.ietf.org/internet-drafts/draft-lee-teas-actn-pm-telemetry-autonomics-16.txt
Status:         https://datatracker.ietf.org/doc/draft-lee-teas-actn-pm-telemetry-autonomics/
Htmlized:       https://tools.ietf.org/html/draft-lee-teas-actn-pm-telemetry-autonomics-16
Htmlized:       https://datatracker.ietf.org/doc/html/draft-lee-teas-actn-pm-telemetry-autonomics
Diff:           https://www.ietf.org/rfcdiff?url2=draft-lee-teas-actn-pm-telemetry-autonomics-16

Abstract:
   This document provides YANG data models that describe performance
   monitoring telemetry and scaling intent mechanism for TE-tunnels and
   Virtual Networks (VN).

   The models presented in this draft allow customers to subscribe to
   and monitor their key performance data of their interest on the
   level of TE-tunnel or VN. The models also provide customers with the
   ability to program autonomic scaling intent mechanism on the level
   of TE-tunnel as well as VN.






Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

--- End Message ---