Great, thanks! Given basically no other Ad have stated a position yet, I would actually recommend to submit the update now, so the other AD can review the next version.
Mirja > Am 31.07.2017 um 19:37 schrieb Dhruv Dhody <dhruv.dh...@huawei.com>: > > Hi Mirja, > >> -----Original Message----- >> From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Mirja Kühlewind >> Sent: 31 July 2017 21:44 >> To: The IESG <i...@ietf.org> >> Cc: cmarga...@juniper.net; draft-ietf-pce-pc...@ietf.org; pce@ietf.org; >> pce-cha...@ietf.org >> Subject: [Pce] Mirja Kühlewind's No Objection on draft-ietf-pce-pceps-14: >> (with COMMENT) >> >> Mirja Kühlewind has entered the following ballot position for >> draft-ietf-pce-pceps-14: 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/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-pce-pceps/ >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> One high level comment: >> >> As already mentioned by the gen-art review (Thanks Dale for the detailed >> review!), for me the text was for a long time while reading not clear on >> who starts the TLS negotiation. In think there is a statement missing that >> a speaker/PCE that supports PCEPS and receives a StartTLS message MUST >> reply with a StartTLS message and further the PCC MUST initiation the TLS >> after reception of a StartTLS message from the PCC. >> > [[[Dhruv Dhody]]] As part of handling of Dale's comments, this has been > clarified. > > I have also added some text at the start of section 3.2 to make this super > clear. > >> More minor/editorial comments: >> >> 1) There are two cases where the behavior of speakers that do not support >> PCEPS is specified, which is a bit non-sensical given that not support >> probably means it does not follow this spec: >> OLD >> "If the PCEP speaker that does not support PCEPS, receives a StartTLS >> message, it MUST behave according to the existing error mechanism >> described in section 6.2 of [RFC5440] (in case message is received >> prior to an Open message) or section 6.9 of [RFC5440] (for the case >> of reception of unknown message)." >> NEW >> "If the PCEP speaker that does not support PCEPS, receives a StartTLS >> message, it will behave according to the existing error mechanism >> described in section 6.2 of [RFC5440] (in case message is received >> prior to an Open message) or section 6.9 of [RFC5440] (for the case >> of reception of unknown message)." > > [[[Dhruv Dhody]]] Ack, was updated as part of Gen-ART. > >> and >> OLD >> "A PCEP speaker that does not support PCEPS or has learned the peer >> willingness to reestablish session without TLS, can send the Open >> message directly, as per [RFC5440]." >> NEW >> "A PCEP speaker that does not support PCEPS sends the Open message >> directly, as per [RFC5440]. >> A PCEP speaker that supports PCEPS but has previously already learned the >> peer >> willingness to reestablish session without TLS, MAY send the Open >> message directly, as per [RFC5440]." >> > [[[Dhruv Dhody]]] Ack, updated. > >> 2) As already mentioned in the gen-art review, I also think there should >> be more text on what a host should do that uses StartTLS but gets an error >> back. >> This is defined previously in the document but given there is an own >> section here, I would just recommend to re-iterate there. In other words >> please add the proposed text! > [[[Dhruv Dhody]]] Ack, updated. >> >> 3) Why is this a MUST? >> sec 8.1 "A PCE or PCC implementation MUST allow configuring the PCEP >> security >> via TLS capabilities as described in this document." >> Wouldn't a SHOULD be enough/better? Meaning that when PCEPS is >> implemented and turned on by default, I don't necessarily have to provide >> a knob to turn it off? > [[[Dhruv Dhody]]] Agree, updated. >> >> 4) Also related to the previous point >> sec 8.2 "An implementation SHOULD allow the operator to configure the >> PCEPS >> capability and various TLS related parameters, ..." >> Probably this part of sentence should not be normative given this part is >> (differently) specified in the previous section. >> > [[[Dhruv Dhody]]] Ack, updated. > > Thanks Again! > > The working copy and diff (handling gen-ART and your comments) are attached. > > Regards, > Dhruv >> >> _______________________________________________ >> Pce mailing list >> Pce@ietf.org >> https://www.ietf.org/mailman/listinfo/pce > <draft-ietf-pce-pceps-15.txt><Diff_ draft-ietf-pce-pceps-14.txt - > draft-ietf-pce-pceps-15.txt.html> _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
