Hi, Dhruv,

On Tue, Aug 8, 2017 at 6:08 AM, Dhruv Dhody <dhruv.dh...@huawei.com> wrote:

> 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>;
> pce-cha...@ietf.org
> *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 <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
>
>       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 –*
>

Thanks! I know what that means.

Spencer


>
>
>    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:pce-boun...@ietf.org] *On Behalf Of *Spencer Dawkins
> at IETF
> *Sent:* 07 August 2017 19:16
> *To:* Alexey Melnikov <aamelni...@fastmail.fm>
> *Cc:* cmarga...@juniper.net; draft-ietf-pce-pc...@ietf.org; pce@ietf.org;
> The IESG <i...@ietf.org>; pce-cha...@ietf.org
> *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 <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.
>
>
>
> Spencer
>
>
>
> 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
>  (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).
> >
> >
>
>
>
>
>
_______________________________________________
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Reply via email to