Hi Spencer,

From: Spencer Dawkins at IETF [mailto:spencerdawkins.i...@gmail.com]
Sent: 07 August 2017 21:17
To: Dhruv Dhody <dhruv.dh...@huawei.com>
Cc: Alexey Melnikov <aamelni...@fastmail.fm>; cmarga...@juniper.net; 
draft-ietf-pce-pc...@ietf.org; pce@ietf.org; The IESG <i...@ietf.org>; 
Subject: Re: [Pce] Alexey Melnikov's Yes on draft-ietf-pce-pceps-15: (with 

Hi, Dhruv,

On Mon, Aug 7, 2017 at 9:43 AM, Dhruv Dhody 
<dhruv.dh...@huawei.com<mailto:dhruv.dh...@huawei.com>> 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

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 

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

   Type    Meaning               Error-value             Reference

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



From: Pce [mailto:pce-boun...@ietf.org<mailto:pce-boun...@ietf.org>] On Behalf 
Of Spencer Dawkins at IETF
Sent: 07 August 2017 19:16
To: Alexey Melnikov <aamelni...@fastmail.fm<mailto:aamelni...@fastmail.fm>>
Cc: cmarga...@juniper.net<mailto:cmarga...@juniper.net>; 
pce@ietf.org<mailto:pce@ietf.org>; The IESG 
Subject: Re: [Pce] Alexey Melnikov's Yes on draft-ietf-pce-pceps-15: (with 

This is Alexey's ballot, but ...

On Mon, Aug 7, 2017 at 5:48 AM, Alexey Melnikov 
<aamelni...@fastmail.fm<mailto:aamelni...@fastmail.fm>> wrote:
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)

This text wasn't clear to me, either.

Thanks for actually mentioning this in your ballot, Alexey.


On Mon, Aug 7, 2017, at 11:46 AM, Alexey Melnikov wrote:
> Alexey Melnikov has entered the following ballot position for
> draft-ietf-pce-pceps-15: Yes
> 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).

Pce mailing list

Reply via email to