Hi Dhruv, Sorry for being slow. Yes, these changes look fine. Thanks for accommodating my concerns. I’ve cleared my discuss.
Regards, Rob From: iesg <iesg-boun...@ietf.org> On Behalf Of Dhruv Dhody Sent: 05 October 2022 14:03 To: Rob Wilton (rwilton) <rwil...@cisco.com> Cc: The IESG <i...@ietf.org>; draft-ietf-lsr-pce-discovery-security-supp...@ietf.org; lsr-cha...@ietf.org; lsr@ietf.org; Acee Lindem (acee) <a...@cisco.com>; p...@ietf.org Subject: Re: Robert Wilton's Discuss on draft-ietf-lsr-pce-discovery-security-support-11: (with DISCUSS and COMMENT) Hi Robert, Thanks for your review. The working copy is at - TXT - https://raw.githubusercontent.com/dhruvdhody/ietf/master/draft-ietf-lsr-pce-discovery-security-support-12.txt DIFF - https://www.ietf.org/rfcdiff?url1=draft-ietf-lsr-pce-discovery-security-support-11&url2=https://raw.githubusercontent.com/dhruvdhody/ietf/master/draft-ietf-lsr-pce-discovery-security-support-12.txt On Tue, Oct 4, 2022 at 10:17 PM Robert Wilton via Datatracker <nore...@ietf.org<mailto:nore...@ietf.org>> wrote: Robert Wilton has entered the following ballot position for draft-ietf-lsr-pce-discovery-security-support-11: Discuss 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/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Hi, Sorry for the discuss, but I find a couple of specification aspects of this draft to be unclear enough that I think that they probably warrant a discuss, hopefully easy to explain or resolve: In section 3.2, it wasn't clear to me exactly where I find what the Key-Id is. I suspect that this is probably referring to "KeyId" in rfc5925. If so, I think that would be emphasizing. Dhruv: Made this change - The KEY-ID sub-TLV specifies an identifier that can be used by the PCC to identify the TCP-AO key [RFC5925] (referred to as KeyID). In section 3.3, it wasn't clear to me what the Key chain name is, or what exactly it refers to. Is this referring to a local key-chain name installed in a YANG Keystore (given that there is a reference to RFC8177) or something else. Either way, I think that expanding on the description here would probably be very beneficial. Dhruv: Here is the updated text - The KEY-CHAIN-NAME sub-TLV specifies a keychain name that can be used by the PCC to identify the keychain. The keychain name could be manually configured via CLI or installed in the YANG datastore (see [RFC8177]) at the PCC. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- One minor comment. I noted that the description of the Key-Id slightly differed for the OSPF encoding vs ISIS encoding and I wanted to check that the difference was intentional. Dhruv: Yes, this is intentional as padding rules are different between OSPF and IS-IS. See this email - https://mailarchive.ietf.org/arch/msg/lsr/T9OLjPkjcvOViHXOZGCJYsi8OJ4/ Thanks! Dhruv Regards, Rob
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
