Hi Yingzhen/Co-authors, Thanks for the update that addresses all the open comments.
Could you please cross-check/clarify one aspect? I notice that Pushpasis was replaced by Acee on the front page authors list in the recent updates. I don't see Pushpasis listed in either contributors or acknowledgement sections. Requesting the authors and the document shepherd/co-chairs to please cross check that is all good. Thanks, Ketan On Thu, Apr 17, 2025 at 3:10 AM Yingzhen Qu <[email protected]> wrote: > Hi Ketan, > > Thanks for the review. Version -27 has been uploaded to address your > comments. Please see my detailed answers below inline. > > Thanks, > Yingzhen > > On Tue, Apr 1, 2025 at 10:15 AM Ketan Talaulikar via Datatracker < > [email protected]> wrote: > >> 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 >> ;-) >> >> [Yingzhen]: fixed. > > >> 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. >> > [Yingzhen]: removed. > >> >> 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 >> > [Yingzhen]: thanks for catching this. fixed. > >> >> 537 } >> >> 539 identity pe-flag { >> >> <minor> Why not "p-flag"? >> >> [Yingzhen]: because there is already a p-flag in prefix-sid-tlv, and we > can't use the same name. > > >> 540 base adj-sid-flag; >> 541 description >> 542 "Persistent flag."; >> 543 } >> >> >> 564 identity sf-flag { >> >> <minor> why not s-flag? >> >> [Yingzhen]: same reason as above. there is a s-flag in adj-sid-sub-tlv. > > 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? >> >> [Yingzhen]: Yes. this has been changed to be consistent with OSPF. > > >> 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. >> >> >> [Yingzhen]: modified. > >
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
