Subject: [Pce] Mirja Kühlewind's No Objection on draft-ietf-pce-pceps-14: (with COMMENT)

From: Mirja Kühlewind <[email-masked]>
Date: Mon, 31 Jul 2017 09:14:17 -0700

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.

---

From: Dhruv Dhody <[email-masked]>
Date: Mon, 31 Jul 2017 17:37:28 +0000

Hi Mirja, 

> -----Original Message-----
> From: Pce [mailto:[email-masked]] On Behalf Of Mirja Kühlewind
> Sent: 31 July 2017 21:44
> To: The IESG <[email-masked]>
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Subject: [Pce] Mirja Kühlewind's No Objection on draft-ietf-pce-pceps-14:
> (with COMMENT)
> 
> 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. 

> 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

[[[Dhruv Dhody]]] Ack, was updated as part of Gen-ART. 

> "A PCEP speaker that does not support PCEPS sends 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.
>  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.
> (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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pce

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Mon, 31 Jul 2017 19:45:38 +0200

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 <[email-masked]>:
> 
> Hi Mirja, 
> 
> <draft-ietf-pce-pceps-15.txt><Diff_ draft-ietf-pce-pceps-14.txt - draft-ietf-pce-pceps-15.txt.html>