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

Alexey Melnikov <aamelnikov@fastmail.fm> Tue, 08 August 2017 12:34 UTC

Return-Path: <aamelnikov@fastmail.fm>
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 30A581320B5; Tue, 8 Aug 2017 05:34:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.718
X-Spam-Level:
X-Spam-Status: No, score=-2.718 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=FjK/VbFE; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=QUZzbKDp
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 q6xle8yiqGsP; Tue, 8 Aug 2017 05:34:00 -0700 (PDT)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E728D13233A; Tue, 8 Aug 2017 05:33:59 -0700 (PDT)
Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 4CA4020C55; Tue, 8 Aug 2017 08:33:59 -0400 (EDT)
Received: from web5 ([10.202.2.215]) by compute7.internal (MEProxy); Tue, 08 Aug 2017 08:33:59 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=ukmvBs2v0K2PZlPqo1LDRRH3fNoWc xiccXeAPQTo6Bc=; b=FjK/VbFEvQ0Z8rkmaDDoP9TTgob9ptfvQdUoZQ748+4OV GpBtOBZPHG4y7JYvYGuO4XwunhHBHwG1c5Sg4yhtRs1o47ckHTSk6KSmYnbbM1Bk iR2hc/lcbTdx0Hag9WXHBkZKAGnLgsziqPQ7XmQ0dDxXf3kkSjsUV5B4jj2QERih rU69zlDsPDTvrcLfIU9A9nWSUt5ii1bAFyq/uthoFkZbK3KsyI+hO3GBKWC6igU4 8JG+9CsTYfVliEQuCR6aEo5RLTLJK5TMFmoa3V3xH8hAjw+ZfkCjSA28jjvmPdtD +0KhI/JPRzjiGcs72mFeX1x7Th1VFJ1zC27TjymeQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=ukmvBs 2v0K2PZlPqo1LDRRH3fNoWcxiccXeAPQTo6Bc=; b=QUZzbKDpepOTvxupNU3JJs 8/fp+EVcy7C9Zx9KOYdImuaR6vhD9tjlUWK+YergIoErEeSLtmJM2q0bQdtR5Iq6 TgpHLAHXEqKpReIutxXVYn6UJ04oFNsaA4BdFuHQZniRllVSqk7lD+0hFKKoTQFP eBr4GSM0m/kpTerC5KkIjx/KwCoMtYYBoWd+1tcWMqdQ/V2efVx8hteLD35bflO5 0RAPLfEBq1P1phM65OkDMkAn0ykYXszobsQ5EVUGpjaWfQXlcVxGcvdxKGRo55DC baIvmjKVvw/Zo0knnz5iqDaI4k8/TM7ozXwJXb5xw0IsUGeU6hZrTDkQbYcsF+3w ==
X-ME-Sender: <xms:t6-JWcv09SXuLhcVQc2N6sTyxtsfoG50T8BFzXzPIN9X2uUl3Hwkqw>
Received: by mailuser.nyi.internal (Postfix, from userid 99) id 21BB99E2A1; Tue, 8 Aug 2017 08:33:59 -0400 (EDT)
Message-Id: <1502195638.844110.1066755056.4A2217DE@webmail.messagingengine.com>
From: Alexey Melnikov <aamelnikov@fastmail.fm>
To: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>, Dhruv Dhody <dhruv.dhody@huawei.com>
Cc: cmargaria@juniper.net, draft-ietf-pce-pceps@ietf.org, pce@ietf.org, The IESG <iesg@ietf.org>, pce-chairs@ietf.org
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: multipart/alternative; boundary="_----------=_15021956398441104"
X-Mailer: MessagingEngine.com Webmail Interface - ajax-4448c6f4
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> <CAKKJt-dv5smKQjXyRu6jzGu6zMz429-75ceF1D0OsCDC28VYtA@mail.gmail.com> <23CE718903A838468A8B325B80962F9B8CB99BB1@blreml501-mbb> <CAKKJt-ftG+V+zDNSTo9vvZivBW-WitAwzU0f4v21M=SruxiS4w@mail.gmail.com>
In-Reply-To: <CAKKJt-ftG+V+zDNSTo9vvZivBW-WitAwzU0f4v21M=SruxiS4w@mail.gmail.com>
Date: Tue, 08 Aug 2017 13:33:58 +0100
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/hDGV4Fb4V4cy0idSxik3tWni8NY>
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: Tue, 08 Aug 2017 12:34:02 -0000

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
> <dhruv.dhody@huawei.com> wrote:>> Hi Spencer, ____


>> __ __


>> *From:* Spencer Dawkins at IETF
>> [mailto:spencerdawkins.ietf@gmail.com] *Sent:* 07 August 2017 21:17
>> *To:* Dhruv Dhody <dhruv.dhody@huawei.com> *Cc:* Alexey Melnikov
>> <aamelnikov@fastmail.fm>; 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)____>> __ __


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


>> **[[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-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).
>>>>  >
>>>>  >____>>>  ____


>> __ __