Wow! I didn't expect you to go to that much trouble just to make me happy, but that all looks great to me.
Remind me that I owe y'all a frosty beverage in London (assuming you are going) Thank you all again, W On Thu, Oct 6 2022 at 9:05 AM, Dhruv Dhody <dhruv.i...@gmail.com> wrote: > Hi Warren, > > Thanks for your review. Apologies for making you sad (we definitely > don't want that :)! How about this text instead of removing -> > > > 6. Management Considerations > > Manageability considerations for PCE Discovery are addressed in > Section 4.10 of [RFC4674] and Section 9 of [RFC5088] [RFC5089]. > > 6.1. Control of Policy and Functions > > A PCE implementation SHOULD allow the following parameters to be > configured on the PCE: > > * support for TCP-AO > > * the KeyID used by TCP-AO > > * Key Chain Name > > * support for TLS > > 6.2. Information and Data Model > > The YANG model for PCEP [I-D.ietf-pce-pcep-yang] supports PCEP > security parameters (key, key chain and TLS). > > 6.3. Liveness Detection and Monitoring > > Normal operations of the IGP meet the requirements for liveness > detection and monitoring. > > 6.4. Verify Correct Operations > > The correlation of PCEP security information advertised against > information received can be achieved by comparing the information in > the PCED sub-TLV received by the PCC with that stored at the PCE > using the PCEP YANG. > > 6.5. Requirements on Other Protocols and Functional Components > > There are no new requirements on other protocols. > > 6.6. Impact on Network Operations > > Frequent changes in PCEP security information advertised in the PCED > sub-TLV may have a significant impact on IGP and might destabilize > the operation of the network by causing the PCCs to reconnect > sessions with PCE(s). Section 4.10.4 of [RFC4674] and Section 9.6 of > [RFC5088] [RFC5089] list techniques that are applicable to this > document as well. > > Thanks! > Dhruv > > > On Thu, Oct 6, 2022 at 3:42 AM Warren Kumari via Datatracker < > nore...@ietf.org> wrote: > >> Warren Kumari has entered the following ballot position for >> draft-ietf-lsr-pce-discovery-security-support-11: No Objection >> >> 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-lsr-pce-discovery-security-support/ >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> I started ballotting DISCUSS on this, but, surprisingly, "You made Warren >> sad" >> isn't actually one of the DISCUSS criteria, and so I'm (grudgingly and >> with bad >> grace) balloting NoObj instead. >> >> ---- >> 6. Management Considerations >> >> A configuration option may be provided for advertising and >> withdrawing PCEP security capability via OSPF and IS-IS. >> ---- >> >> This section seems more than pointless to me - it seems (admittedly very >> slightly!) harmful. It doesn't actually *say* anything useful, but the >> very act >> of it showing up in the index / table of contents gives the impression >> that >> there may be actually Management Considerations text somewhere below. This >> initially made me all excited, and set my heart a flutter -- only to be >> crushed >> when I actually read it. >> >> Please consider ripping the section out - AFAICT, it doesn't accomplish >> anything, other than leading to false hope... >> >> >> >>
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
