Ketan Talaulikar has entered the following ballot position for draft-ietf-isis-sr-yang-25: Yes
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/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-isis-sr-yang/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Sharing a few comments for consideration in the form of snippets from idnits output for v25: 376 contact 377 "WG Web: <https://datatracker.ietf.org/wg/lsr/> 378 WG List: <mailto:[email protected]> 379 Author: Stephane Litkowski 380 <mailto:[email protected]> 381 Author: Yingzhen Qu 382 <mailto:[email protected]> 383 Author: Acee Lindem 384 <mailto:[email protected]> <minor> There seems to be a discrepancy between this text and the author list ;-) 385 Author: Pushpasis Sarkar 386 <mailto:[email protected]> 387 Author: Ing-Wher Chen 388 <mailto:[email protected]> 389 Author: Jeff Tantsura 390 <mailto:[email protected]> 391 "; 392 description 393 "The YANG module defines the generic configuration and 394 operational state for Segment Routing ISIS extensions for the 395 MPLS data plane, which is common across all of the vendor 396 implementations. <major> "is common across all of the vendor implementations" ... can this assertion be really made? Suggest to remove this part. 398 This YANG model conforms to the Network Management 399 Datastore Architecture (NMDA) as described in RFC 8342. 533 identity s-flag { 534 base adj-sid-flag; 535 description 536 "Group flag."; <major> This is called a "set" in ISIS RFC8667 537 } 539 identity pe-flag { <minor> Why not "p-flag"? 540 base adj-sid-flag; 541 description 542 "Persistent flag."; 543 } 564 identity sf-flag { <minor> why not s-flag? 565 base sid-binding-flag; 566 description 567 "S flag. If set, the binding label TLV should be flooded 568 across the entire routing domain."; 569 } 602 grouping sid-sub-tlv { 603 description 604 "SID/Label sub-TLV grouping."; 605 container sid-sub-tlv { 606 description 607 "Used to advertise the SID/Label associated with a 608 prefix or adjacency."; 609 leaf length { 610 type uint8; 611 description 612 "Length of the SID value. YANG model specification 613 is necessary since it dictates the semantics of the 614 SID."; 615 } 616 leaf sid { 617 type uint32; 618 description 619 "Segment Identifier (SID) - A 20 bit label or 32 bit SID. 620 If the length is set to 3, then the 20 rightmost bits 621 represent an MPLS label. If the length is set to 4, then 622 the value is a 32-bit index."; 623 } <major> Is this going to be extended similar to what was done for OSPF for consistency? 624 } 625 } 1289 6. Acknowledgements 1291 Authors would like to thank Derek Yeung, Acee Lindem, Yi Yang for 1292 their major contributions to the draft. Also thank Reshad Rahman, 1293 and Tom Petch for their thorough reviews and helpful comments. 1295 MITRE has approved this document for Public Release, Distribution 1296 Unlimited, with Public Release Case Number 19-3033. <major> With the text above (which applies MITRE has some sort of an approval authority over this document), it seems more appropriate for this author to drop their MITRE Corporation affiliation. _______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
