IETF Logo Mail Archive

[Pce] EKR Discuss on draft-ietf-pce-pceps (was RE: Alexey Melnikov's Discuss on draft-ietf-pce-pceps-15: (with DISCUSS and COMMENT))

Dhruv Dhody <dhruv.dhody@huawei.com> Wed, 23 August 2017 05:44 UTC

Return-Path: <dhruv.dhody@huawei.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 BBA3213233D; Tue, 22 Aug 2017 22:44:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.219
X-Spam-Level:
X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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
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 XPwaIaNJaun1; Tue, 22 Aug 2017 22:44:16 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EF34132334; Tue, 22 Aug 2017 22:44:15 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml706-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DND72108; Wed, 23 Aug 2017 05:44:13 +0000 (GMT)
Received: from BLREML703-CAH.china.huawei.com (10.20.4.172) by lhreml706-cah.china.huawei.com (10.201.108.47) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 23 Aug 2017 06:44:11 +0100
Received: from BLREML501-MBX.china.huawei.com ([10.20.5.198]) by blreml703-cah.china.huawei.com ([::1]) with mapi id 14.03.0301.000; Wed, 23 Aug 2017 11:14:00 +0530
From: Dhruv Dhody <dhruv.dhody@huawei.com>
To: Eric Rescorla <ekr@rtfm.com>
CC: "draft-ietf-pce-pceps.all@ietf.org" <draft-ietf-pce-pceps.all@ietf.org>, "pce@ietf.org" <pce@ietf.org>, The IESG <iesg@ietf.org>, "cmargaria@juniper.net" <cmargaria@juniper.net>, Dhruv Dhody <dhruv.ietf@gmail.com>
Thread-Topic: EKR Discuss on draft-ietf-pce-pceps (was RE: [Pce] Alexey Melnikov's Discuss on draft-ietf-pce-pceps-15: (with DISCUSS and COMMENT))
Thread-Index: AdMbzvJfu3lLrdDTSNmu8GFbH+0PZg==
Date: Wed, 23 Aug 2017 05:43:59 +0000
Message-ID: <23CE718903A838468A8B325B80962F9B8CBB9100@blreml501-mbx>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.18.149.39]
Content-Type: multipart/alternative; boundary="_000_23CE718903A838468A8B325B80962F9B8CBB9100blreml501mbx_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0B0206.599D162D.0157, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 37f6d6dcf7c23ba53eef80a8975528a9
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/flA_8hiClADfwgCKdSKYb5fcMl8>
Subject: [Pce] EKR Discuss on draft-ietf-pce-pceps (was RE: Alexey Melnikov's Discuss on draft-ietf-pce-pceps-15: (with DISCUSS and 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: Wed, 23 Aug 2017 05:44:19 -0000

Hi EKR,

I have been told that my response [1] to your mail [2] has not reach some of the mailboxes.

Thus on advice of our AD, I am starting a new thread to reach closure on this.

The open point is -
EKR suggested that we use the StartTLS message to indicate the local policy if the PCEP speaker is willing to connect without TLS. Whereas the current document does this by using the error message in case it is unwilling or unable to start the TLS.

EKR proposal works, but will require us to add a new PCEP object - StartTLS object, as unfortunately there is no way to carry the information in the current message/objects format defined.

As an editor, my opinion was to avoid making a change in encoding if possible, especially if the benefit is not big and the default setting is strict TLS.

But if the opinion is towards "mandating" making the change, I can put out a version for review soon.

All the other comments are handled in -16 [3]. Thanks for all the comments and discussions!

Regards,
Dhruv

[1] https://www.ietf.org/mail-archive/web/pce/current/msg05487.html
[2] https://www.ietf.org/mail-archive/web/pce/current/msg05486.html
[3] https://tools.ietf.org/html/draft-ietf-pce-pceps-16

v2.23.0 | Report a Bug | By Email