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. 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)." 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]." 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! 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? 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. _______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
