Subject: [Pce] Alexey Melnikov's Yes on draft-ietf-pce-pceps-15: (with COMMENT)

From: Alexey Melnikov <[email-masked]>
Date: Mon, 07 Aug 2017 03:46:17 -0700

Alexey Melnikov has entered the following ballot position for
draft-ietf-pce-pceps-15: Yes

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:
----------------------------------------------------------------------

Thank you for addressing my DISCUSS points and comments.

I think the text about use of RFC 6125 should use RFC 6125 terminology like
DNS-ID and CN-ID, because they have a bit more semantics associated with them
other than just subjectAltName:DNS. I think you should also clarify whether you
want to allow wildcards in DNS-ID/CN-ID (RFC 6125 talks about that).

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 07 Aug 2017 11:48:08 +0100

One more little thing:

In figure 5, I see: Send Error (not without TLS)

What does "not without TLS" mean? I think the figure is sending PCErr in
the clear (without TLS)

> draft-ietf-pce-pceps-15: Yes
 (snip)

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 7 Aug 2017 08:45:59 -0500

This is Alexey's ballot, but ...

> What does "not without TLS" mean? I think the figure is sending PCErr in

This text wasn't clear to me, either.

Thanks for actually mentioning this in your ballot, Alexey.

Spencer

---

From: Dhruv Dhody <[email-masked]>
Date: Mon, 7 Aug 2017 14:42:28 +0000

Hi Alexey, 

> -----Original Message-----
> From: Pce [mailto:[email-masked]] On Behalf Of Alexey Melnikov
> Sent: 07 August 2017 16:16
> To: The IESG <[email-masked]>
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Subject: [Pce] Alexey Melnikov's Yes on draft-ietf-pce-pceps-15: (with
> COMMENT)
> 
> I think the text about use of RFC 6125 should use RFC 6125 terminology
> like DNS-ID and CN-ID, because they have a bit more semantics associated
> with them other than just subjectAltName:DNS. I think you should also
> clarify whether you want to allow wildcards in DNS-ID/CN-ID (RFC 6125
> talks about that).
> 
[[[Dhruv Dhody]]] Ack, updated to - 

          +  Implementations MUST follow the rules and guidelines for
             peer validation as defined in [RFC6125].  If an expected
             DNS name or IP address for the peer is configured, then the
             implementations MUST check them against the values in the
             presented certificate.  The DNS names and the IP addresses
             can be contained in the CN-ID [RFC6125] (Common Name
             Identifier) or the subjectAltName entries.  For
             verification, only one of these entries is considered.  The
             following precedence applies: for DNS name validation, DNS-
             ID [RFC6125] has precedence over CN-ID; for IP address
             validation, subjectAltName:iPAddr has precedence over CN-
             ID.

          +  Implementations MAY allow the configuration of a set of
             additional properties of the certificate to check for a
             peer's authorization to communicate (e.g., a set of allowed
             values in URI-ID [RFC6125] or a set of allowed X509v3
             Certificate Policies).  The definition of these properties
             are out of scope of this document. 

Regards,
Dhruv
> 
> _______________________________________________
> Pce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pce

---

From: Dhruv Dhody <[email-masked]>
Date: Mon, 7 Aug 2017 14:43:19 +0000

Hi Spencer, Alexey,

The text refers to the Error itself.

   If a PCEP speaker that is unwilling or unable to negotiate TLS
   receives a StartTLS messages, it MUST return a PCErr message (in
   clear) with Error-Type set to [TBA2 by IANA] (PCEP StartTLS failure)
   and Error-value set to:

   o  3 (not without TLS) if it is not willing to exchange PCEP messages
      without the solicited TLS connection, and it MUST close the TCP
      session.

I can see how it could be misleading and I have corrected it to –

                  +-+-+                 +-+-+
                  |PCC|                 |PCE|
                  +-+-+                 +-+-+
                    |                     |
                    | StartTLS            |
                    | msg                 | PCE waits
                    |-------------------->| for PCC
                    |               PCErr |
                    |<--------------------| Send Error
                    |                     | Type=TBA2,Value=3
                    |                     | (not without TLS)
                    |<--------------------|
                    |       Close         |

   Figure 5: Both PCEP Speaker supports PCEPS as well as without PCEPS,
                   but PCE cannot start TLS negotiation

Regards,
Dhruv

From: Pce [mailto:[email-masked]] On Behalf Of Spencer Dawkins at IETF
Sent: 07 August 2017 19:16
To: Alexey Melnikov <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; The IESG <[email-masked]>; [email-masked]
Subject: Re: [Pce] Alexey Melnikov's Yes on draft-ietf-pce-pceps-15: (with COMMENT)

On Mon, Aug 7, 2017 at 5:48 AM, Alexey Melnikov <[email-masked]<mailto:[email-masked]>> wrote:
One more little thing:

Spencer

 (snip)
> like

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 7 Aug 2017 10:47:07 -0500

Hi, Dhruv,

> I can see how it could be misleading and I have corrected it to –

This is still Alexey's ballot, of course, but ...

I like the change you're making, but the part that confused me is that in
English, multiple negatives don't work well - so, "not without TLS"
simplifies to "with TLS" in common usage.

Are you using "not without TLS" to mean "TLS usage required", or something
like that?

Spencer

>
>
> Regards,
>
> Dhruv
>
>
>
> *From:* Pce [mailto:[email-masked]] *On Behalf Of *Spencer Dawkins
> at IETF
> *Sent:* 07 August 2017 19:16
> *To:* Alexey Melnikov <[email-masked]>
> *Cc:* [email-masked]; [email-masked]; [email-masked];
> The IESG <[email-masked]>; [email-masked]
> *Subject:* Re: [Pce] Alexey Melnikov's Yes on draft-ietf-pce-pceps-15:
> (with COMMENT)
>
>
>

---

From: Dhruv Dhody <[email-masked]>
Date: Tue, 8 Aug 2017 11:08:23 +0000

Hi Spencer,

From: Spencer Dawkins at IETF [mailto:[email-masked]]
Sent: 07 August 2017 21:17
To: Dhruv Dhody <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; The IESG <[email-masked]>; [email-masked]
Subject: Re: [Pce] Alexey Melnikov's Yes on draft-ietf-pce-pceps-15: (with COMMENT)

Hi, Dhruv,

On Mon, Aug 7, 2017 at 9:43 AM, Dhruv Dhody <[email-masked]<mailto:[email-masked]>> wrote:
Hi Spencer, Alexey,

                  +-+-+                 +-+-+
                  |PCC|                 |PCE|
                  +-+-+                 +-+-+
                    |                     |
                    | StartTLS            |
                    | msg                 | PCE waits

I like the change you're making, but the part that confused me is that in English, multiple negatives don't work well - so, "not without TLS" simplifies to "with TLS" in common usage.

Are you using "not without TLS" to mean "TLS usage required", or something like that?

Spencer
[[Dhruv Dhody]] Yes, it means "TLS usage required".  I can reword it to the text we have in the IANA section –

   Error-
   Type    Meaning               Error-value             Reference

                                 3:Failure, connection   This document
                                 without TLS not
                                 possible
                                 4:Failure, connection   This document
                                  without TLS possible

Regards,
Dhruv

Regards,
Dhruv

From: Pce [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Spencer Dawkins at IETF
Sent: 07 August 2017 19:16
To: Alexey Melnikov <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; The IESG <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Pce] Alexey Melnikov's Yes on draft-ietf-pce-pceps-15: (with COMMENT)

Spencer

 (snip)

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 8 Aug 2017 07:28:30 -0500

Hi, Dhruv,

On Tue, Aug 8, 2017 at 6:08 AM, Dhruv Dhody <[email-masked]> wrote:

> Hi Spencer,
>
>
>
> *From:* Spencer Dawkins at IETF [mailto:[email-masked]]
> *Sent:* 07 August 2017 21:17
> *To:* Dhruv Dhody <[email-masked]>
> *Cc:* Alexey Melnikov <[email-masked]>; [email-masked];
> [email-masked]; [email-masked]; The IESG <[email-masked]>;
> [email-masked]
> *[[Dhruv Dhody]] Yes, it means *"TLS usage required".  *I can reword it
> to the text we have in the IANA section –*
>

Thanks! I know what that means.

Spencer

> *Regards,*
> *Dhruv*

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 08 Aug 2017 13:33:58 +0100

Hi,
(Top post)
I agree that the new wording is clearer.

On Tue, Aug 8, 2017, at 01:28 PM, Spencer Dawkins at IETF wrote:
> Hi, Dhruv,
> 
> On Tue, Aug 8, 2017 at 6:08 AM, Dhruv Dhody
> <[email-masked]> wrote:>> Hi Spencer, ____

>> __ __

>> *From:* Spencer Dawkins at IETF
>> [mailto:[email-masked]] *Sent:* 07 August 2017 21:17
>> *To:* Dhruv Dhody <[email-masked]> *Cc:* Alexey Melnikov
>> <[email-masked]>; [email-masked]; draft-ietf-pce-
>> [email-masked]; [email-masked]; The IESG <[email-masked]>; pce-
>> [email-masked] *Subject:* Re: [Pce] Alexey Melnikov's Yes on draft-ietf-pce-pceps-
>> 15: (with COMMENT)____>> __ __

>> Hi, Dhruv,____

>> __ __

>> On Mon, Aug 7, 2017 at 9:43 AM, Dhruv Dhody <[email-masked]>
>> wrote:____>>> Hi Spencer, Alexey,____

>>>  ____

>>> The text refers to the Error itself. ____

>>>  ____

>>>    If a PCEP speaker that is unwilling or unable to negotiate
>>>    TLS____>>>    receives a StartTLS messages, it MUST return a PCErr message
>>>    (in____>>>    clear) with Error-Type set to [TBA2 by IANA] (PCEP StartTLS
>>>    failure)____>>>    and Error-value set to:____

>>>  ____

>>>    o  3 (not without TLS) if it is not willing to exchange PCEP
>>>    messages____>>>       without the solicited TLS connection, and it MUST close the
>>>       TCP____>>>       session.____

>>>  ____

>>> I can see how it could be misleading and I have corrected it to
>>> – ____>>>  ____

>>>                   +-+-+                 +-+-+____

>>>                   |PCC|                 |PCE|____

>>>                   +-+-+                 +-+-+____

>>>                     |                     |____

>>>                     | StartTLS            |____

>>>                     | msg                 | PCE waits____

>>>                     |-------------------->| for PCC____

>>>                     |               PCErr |____

>>>                     |<--------------------| Send Error____

>>>                     |                     | Type=TBA2,Value=3____>>>                     |                     | (not without TLS)____>>>                     |<--------------------|____

>>>                     |       Close         |____

>>>  ____

>>>  ____

>>>  ____

>>>    Figure 5: Both PCEP Speaker supports PCEPS as well as without
>>>    PCEPS,____>>>                    but PCE cannot start TLS negotiation____

>> __ __

>> This is still Alexey's ballot, of course, but ...____

>> __ __

>> I like the change you're making, but the part that confused me is
>> that in English, multiple negatives don't work well - so, "not
>> without TLS" simplifies to "with TLS" in common usage.____>> __ __

>> Are you using "not without TLS" to mean "TLS usage required", or
>> something like that?____>> __ __

>> Spencer ____

>> **[[Dhruv Dhody]] Yes, it means **"TLS usage required".  **I can
>> reword it to the text we have in the IANA section –**> 
>> **____**

>> **__ __**

>>    Error-____

>>    Type    Meaning               Error-value
>>    Reference____>> __ __

>>                                  3:Failure, connection   This
>>                                    document____>>                                  without TLS not____

>>                                  possible____

>>                                  4:Failure, connection   This
>>                                    document____>>                                   without TLS possible____

>> __ __

>> **Regards,____**

>> **Dhruv____**

>>>  ____

>>> Regards,____

>>> Dhruv____

>>>  ____

>>> *From:* Pce [mailto:[email-masked]] *On Behalf Of *Spencer
>>> Dawkins at IETF *Sent:* 07 August 2017 19:16 *To:* Alexey Melnikov
>>> <[email-masked]> *Cc:* [email-masked]; draft-ietf-pce-
>>> [email-masked]; [email-masked]; The IESG <[email-masked]>; pce-
>>> [email-masked] *Subject:* Re: [Pce] Alexey Melnikov's Yes on draft-ietf-pce-pceps-
>>> 15: (with COMMENT)____>>>  ____

>>> This is Alexey's ballot, but ...____

>>>  ____

>>> On Mon, Aug 7, 2017 at 5:48 AM, Alexey Melnikov
>>> <[email-masked]> wrote:____>>>> One more little thing:
>>>>
>>>>
>>>>  What does "not without TLS" mean? I think the figure is sending
>>>>  PCErr in the clear (without TLS)____>>>  ____

>>> This text wasn't clear to me, either.____

>>>  ____

>>> Thanks for actually mentioning this in your ballot, Alexey.____

>>>  ____

>>> Spencer____

>>>  ____

>>>>   (snip)____>>>> > I think the text about use of RFC 6125 should use RFC 6125
>>>> > terminology
>>>>  > like DNS-ID and CN-ID, because they have a bit more semantics
>>>>  > associated with them other than just subjectAltName:DNS. I think
>>>>  > you should also clarify whether you want to allow wildcards in
>>>>  > DNS-ID/CN-ID (RFC 6125 talks about that).
>>>>  >
>>>>  >____>>>  ____

>> __ __