Hi Paul,

Many thanks for the review and the feedback. Ack on all. I updated the draft 
according to your and other input from the mailing list.

https://www.ietf.org/rfcdiff?url2=draft-tgraf-ipfix-mpls-sr-label-type-02

> If the draft is to be accepted by IANA then it needs to be published or 
> archived somewhere

This was one of the unclarities I had. If I understand you correctly, this 
draft needs to be adopted by SPRING working group and published as RFC for 
documentation purposes before values can be assigned by IANA. Correct?

Best Wishes
Thomas

-----Original Message-----
From: Aitken, Paul <paul.ait...@intl.att.com> 
Sent: Wednesday, March 25, 2020 11:10 AM
To: Graf Thomas, INI-NET-DCF <thomas.g...@swisscom.com>
Cc: spring@ietf.org
Subject: review of draft-tgraf-ipfix-mpls-sr-label-type-01

Thomas, here's some feedback about draft-tgraf-ipfix-mpls-sr-label-type-01 :


Since Figure 1 is intended to update the "IPFIX Information Element #46" 
SubRegistry, it should contain the same columns as that registry - ie, Value, 
Description, Reference.

The ElementID, Abstract Data Type, and Data Type Semantics are already defined 
in the "IPFIX Information Elements" registry; they are not pertinent here.

So Figure 1 should be:

       -------------------------------------------
       |Value|      Description      | Reference |
       |-----------------------------------------|
       |TBD1 | IS-IS Segment Routing |  RFC8667  |
       |-----------------------------------------|
       |TBD2 | OSPF Segment Routing  |  RFC8665  |
       -------------------------------------------


If the draft is to be accepted by IANA then it needs to be published or 
archived somewhere, since RFC 7012 (and RFC 5102) say:

     The specification of new MPLS label types MUST be published using a
     well-established and persistent publication medium.


"not believed" in section 3 is not rigorous; the statement must be definite - 
eg "This document does not add any additional IPFIX security considerations.", 
or "The same security considerations apply as for the IPFIX Protocol [RFC7012]."


Surely many of the Normative references are simply Informative? eg 
I-D.ali-spring-sr-traffic-accounting, RFC4364, RFC5036, RFC8277, RFC8660, 
RFC8665, RFC8667.


Typo: "laveraged" in the second paragraph of section 1.


P.

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Reply via email to