I support progressing this document. I agree with the IANA related questions asked by Ketan and responses given by authors.
Kind Regards Gyan On Thu, Aug 5, 2021 at 5:05 AM maqiufang (A) <maqiufa...@huawei.com> wrote: > Hi, Ketan, > > > > Thanks for your comments. Please see my reply inline. > > > > *发件人**:* Pce [mailto:pce-boun...@ietf.org <pce-boun...@ietf.org>] *代表 *Ketan > Talaulikar (ketant) > *发送时间:* 2021年7月23日 21:10 > *收件人:* Acee Lindem (acee) <acee=40cisco....@dmarc.ietf.org>; l...@ietf.org > *抄送:* draft-ietf-lsr-pce-discovery-security-supp...@ietf.org; pce@ietf.org > *主题:* Re: [Pce] WG Last Call for IGP extension for PCEP security > capability support in the PCE discovery - > draft-ietf-lsr-pce-discovery-security-support-05 > > > > Hello All, > > > > I have reviewed this draft and have the following comments for the authors > to address and the WG to consider: > > > > 1) Is there any precedent for the advertisement of auth keychain > info (ID/name) in such a manner that is flooded across the IGP domain? When > the actual keychain anyway needs to be configured on all PCCs what is > really the value in their advertisement other than possibly exposure to > attack? I hope the security directorate reviewer looks at this closely and > we get some early feedback specifically on this aspect. > > *[Qiufang Ma] See Acee’s response, thanks Acee.* > > > > 2) In sec 3.2 and 3.3, new sub-TLVs are being introduced. Their > ASCII art pictures represent the OSPF TLVs. The ISIS TLV structure is > different. While this will be obvious to most in this WG, I would request > this to be clarified – perhaps by introducing separate diagrams for both > protocols or skipping the art altogether. > > *[Qiufang Ma] Good catch, I prefer to skip the art altogether.* > > > > 3) RFC5088 applies to both OSPFv2 and OSPFv3. This is however not > clear in the text of this document. > > *[Qiufang Ma] This draft is built on top of RFC 5088, therefore the > extension defined in this draft is applied to both OSPFv2 and OSPFv3. I > understand your confusion in the IANA and will fix this in the IANA.* > > > > 4) Looks like RFC5088 asked for the PCE Capabilities Flags registry > to be created as a top-level IANA OSPF registry - > https://datatracker.ietf.org/doc/html/rfc5088#section-7.2 – so it should > have been placed here : > https://www.iana.org/assignments/ospf-parameters/ospf-parameters.xhtml. > What seems to have happened is that it got created under OSPFv2 which is > wrong - > https://www.iana.org/assignments/ospfv2-parameters/ospfv2-parameters.xml#ospfv2-parameters-14. > Since this draft updates RFC5088, it is necessary for this document to fix > this error. I would support Les in that perhaps all of this (i.e. > everything under/related to PCED TLV) ought to be moved under the IANA > Common IGP registry here : > https://www.iana.org/assignments/igp-parameters/igp-parameters.xhtml > > *[Qiufang Ma] I tend to agree with you. but I am not sure how to move > other existing created registry for Path Computation Element (PCE) > Capability Flags available at* > > *https://www.iana.org/assignments/ospfv2-parameters/ospfv2-parameters.xml#ospfv2-parameters-14 > <https://www.iana.org/assignments/ospfv2-parameters/ospfv2-parameters.xml#ospfv2-parameters-14> > to the new location you recommended.* > > *https://www.iana.org/assignments/igp-parameters/igp-parameters.xhtml > <https://www.iana.org/assignments/igp-parameters/igp-parameters.xhtml> * > > *I need to request the guidance from our chairs and AD for this.* > > 5) The document needs to be more specific and clear about which IANA > registries to be used to avoid errors that have happened in the past (see > (3) above). > > *[Qiufang Ma] Please see above.* > > 6) Appendix A, I believe what the authors intended here was that > whether to use MD5 auth or not was part of discovery but static > configuration on the PCE and PCC? The keychain introduced in this document > can also be used along with MD5. Honestly, I don’t see a strong reason to > not include MD5 in the signalling except that it is deprecated (even if > widely deployed). This document would not conflict or contradict with > RFC5440 if it did include a bit for MD5 support as well. As follow-on, > perhaps this document should also update RFC5440 – specifically for the > security section? I see RFC8253 introducing TLS that updates RFC5440 but > nothing that introduces TCP-AO?. In any case, these are aspects for PCE WG > so I will leave those to the experts there. > > *[Qiufang Ma] See Qin's reply to Acee. I hope your comment get addressed > over there. My personally opinion is MD5 is weak and should be deprecated, > thus it doesn't worth new protocol extension for TCP MD5 support.* > > > > *Best Regards,* > > *Qiufang Ma* > > > > Thanks, > > Ketan > > > > *From:* Lsr <lsr-boun...@ietf.org> *On Behalf Of *Acee Lindem (acee) > *Sent:* 21 July 2021 22:16 > *To:* l...@ietf.org > *Cc:* draft-ietf-lsr-pce-discovery-security-supp...@ietf.org > *Subject:* [Lsr] WG Last Call for IGP extension for PCEP security > capability support in the PCE discovery - > draft-ietf-lsr-pce-discovery-security-support-05 > > > > This begins a 3-week WG Last Call, ending on August 4th, 2021, for > draft-ietf-lsr-pce-discovery-security-support. Please indicate your support > or objection to this list before the end of the WG last call. The longer WG > last call is to account for IETF week. > > > > > https://datatracker.ietf.org/doc/draft-ietf-lsr-pce-discovery-security-support/ > > > > > > Thanks, > > Acee > > > > > _______________________________________________ > Lsr mailing list > l...@ietf.org > https://www.ietf.org/mailman/listinfo/lsr > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mis...@verizon.com <gyan.s.mis...@verizon.com>* *M 301 502-1347*
_______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
