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

Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> Mon, 07 August 2017 15:47 UTC

Return-Path: <spencerdawkins.ietf@gmail.com>
X-Original-To: pce@ietfa.amsl.com
Delivered-To: pce@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FFF9132394; Mon, 7 Aug 2017 08:47:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fMSaqZONEqiA; Mon, 7 Aug 2017 08:47:10 -0700 (PDT)
Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD0BD13203E; Mon, 7 Aug 2017 08:47:08 -0700 (PDT)
Received: by mail-yw0-x22d.google.com with SMTP id p68so5217818ywg.0; Mon, 07 Aug 2017 08:47:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Xf83a3bUHvPhUvRKd+jUxNw2/qa8UQB2bOhF9W38rMg=; b=KonDkGhLDS2r//t5/6S5UtID83bFl1yh9ba0WIzu7rm8EIiBGMJxVEm3AnKThYSjW+ /WY9avMrsN7JVuWMpHaq/zSVZYwyGv+vlTq1dGIHNAh05gMnR8OCfHObKEWoKjuyFMAM vLYQKhwwcRHgM9f+asXfF+y2VYC4sQ0YAUz3x9mTpdCAEqKnKAK2TJYdp7JHyxyHxEW9 i7fjGeTLCVbHmnRRpZW3L3mGiDVYv+F9vJUjAt6qLag8glpYK7N8WCVMM3UO4J9FCmhp t1Odq3xVdOivmnVxNXG7aeET7AIP2EdbPC21jENG3qvt0LusOR2w4MMmgklhKiyGale0 tQnw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Xf83a3bUHvPhUvRKd+jUxNw2/qa8UQB2bOhF9W38rMg=; b=htciPiS+7o+bb9HDQ072CxRf71YMffHI9J7THnj9VatRW3qhPJXKMsFUCA29md4grC 8xNNTbAzrVHbPabiP56B6ObAItU0ET1aChY3Fd3bh+7FhgjY/lDjR4V7+231ROmI9Ion 9o6l0+aZmXul0Q80XWOOBmC5pqYxqiaZZhgFmBB+iXOW7QeeQHi+DBBxc7mv80KpYBfs kYaEuld5B0ybajfSKq6yHFyJSNgejovpatXa4NHd6xSu6gRXNzTinFwXlgR29UZPfUU9 B7vv2fFnwgJfOr9STgCAwd78QAztNNjjfTfo50y/zgKBWLPENIs0TeBNsoBiC83PoMzT RV4w==
X-Gm-Message-State: AHYfb5jD5bLaH1SZ26YxmJ8m++SS1sh1911T2WzWdmkcp4cLEYjKh3Dj V0arF49Q6gZ+2Jb/kJzB5lk1fUhRvw==
X-Received: by 10.13.213.148 with SMTP id x142mr814026ywd.311.1502120827984; Mon, 07 Aug 2017 08:47:07 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.37.52.79 with HTTP; Mon, 7 Aug 2017 08:47:07 -0700 (PDT)
In-Reply-To: <23CE718903A838468A8B325B80962F9B8CB99553@blreml501-mbb>
References: <150210277776.19062.13322344032277131609.idtracker@ietfa.amsl.com> <1502102888.3075507.1065437200.4EB91616@webmail.messagingengine.com> <CAKKJt-cizZGNOhJcGsAhbbd_m41ji9S-rkDJhZHnDGO+netvTA@mail.gmail.com> <23CE718903A838468A8B325B80962F9B8CB99553@blreml501-mbb>
From: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Date: Mon, 07 Aug 2017 10:47:07 -0500
Message-ID: <CAKKJt-dv5smKQjXyRu6jzGu6zMz429-75ceF1D0OsCDC28VYtA@mail.gmail.com>
To: Dhruv Dhody <dhruv.dhody@huawei.com>
Cc: Alexey Melnikov <aamelnikov@fastmail.fm>, "cmargaria@juniper.net" <cmargaria@juniper.net>, "draft-ietf-pce-pceps@ietf.org" <draft-ietf-pce-pceps@ietf.org>, "pce@ietf.org" <pce@ietf.org>, The IESG <iesg@ietf.org>, "pce-chairs@ietf.org" <pce-chairs@ietf.org>
Content-Type: multipart/alternative; boundary="001a114fa2665ca59e05562bc250"
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/WfMsGry4jbPz1WWkq8gPKWtLiz8>
Subject: Re: [Pce] Alexey Melnikov's Yes on draft-ietf-pce-pceps-15: (with COMMENT)
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Path Computation Element <pce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pce>, <mailto:pce-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pce/>
List-Post: <mailto:pce@ietf.org>
List-Help: <mailto:pce-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Aug 2017 15:47:12 -0000

Hi, Dhruv,

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

>
>
> Regards,
>
> Dhruv
>
>
>
> *From:* Pce [mailto:pce-bounces@ietf.org] *On Behalf Of *Spencer Dawkins
> at IETF
> *Sent:* 07 August 2017 19:16
> *To:* Alexey Melnikov <aamelnikov@fastmail.fm>
> *Cc:* cmargaria@juniper.net; draft-ietf-pce-pceps@ietf.org; pce@ietf.org;
> The IESG <iesg@ietf.org>; pce-chairs@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 <aamelnikov@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).
> >
> >
>
>
>