Re: [Pce] PCE WG Last Call - draft-ietf-pce-pceps-04

Julien Meuric <julien.meuric@orange.com> Fri, 20 November 2015 15:25 UTC

Return-Path: <julien.meuric@orange.com>
X-Original-To: pce@ietfa.amsl.com
Delivered-To: pce@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BD0A1B32FB for <pce@ietfa.amsl.com>; Fri, 20 Nov 2015 07:25:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.769
X-Spam-Level:
X-Spam-Status: No, score=-3.769 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.585, SPF_SOFTFAIL=0.665] autolearn=ham
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 F5n2o0g0FAXY for <pce@ietfa.amsl.com>; Fri, 20 Nov 2015 07:25:36 -0800 (PST)
Received: from r-mail2.rd.orange.com (r-mail2.rd.orange.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id 8681E1B32FA for <pce@ietf.org>; Fri, 20 Nov 2015 07:25:36 -0800 (PST)
Received: from r-mail2.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id B71BA5D8A4C; Fri, 20 Nov 2015 16:25:35 +0100 (CET)
Received: from FTRDCH01.rd.francetelecom.fr (unknown [10.194.32.11]) by r-mail2.rd.orange.com (Postfix) with ESMTP id AB5F15D8A32; Fri, 20 Nov 2015 16:25:35 +0100 (CET)
Received: from [10.193.71.204] (10.193.71.204) by FTRDCH01.rd.francetelecom.fr (10.194.32.11) with Microsoft SMTP Server id 14.3.224.2; Fri, 20 Nov 2015 16:25:35 +0100
To: "t.petch" <ietfc@btconnect.com>, Dhruv Dhody <dhruv.dhody@huawei.com>, DIEGO LOPEZ GARCIA <diego.r.lopez@telefonica.com>
References: <23CE718903A838468A8B325B80962F9B8C435C02@BLREML509-MBX.china.huawei.com> <00bb01d1172a$1fcc4100$4001a8c0@gateway.2wire.net> <B46D90DD-D634-4832-90F5-1A9DC1E45760@telefonica.com> <01ea01d11eda$b1243920$4001a8c0@gateway.2wire.net> <4B3520A0-F710-4AE6-80F5-D2551600637E@telefonica.com> <564D9593.6090204@orange.com> <23CE718903A838468A8B325B80962F9B8C476E8F@BLREML509-MBX.china.huawei.com> <564DA223.7060807@orange.com> <023901d123a3$280ae8a0$4001a8c0@gateway.2wire.net>
From: Julien Meuric <julien.meuric@orange.com>
Organization: Orange
Message-ID: <564F3B6F.3050204@orange.com>
Date: Fri, 20 Nov 2015 16:25:35 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <023901d123a3$280ae8a0$4001a8c0@gateway.2wire.net>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/pce/xqii3a5yRqBzYop0nRpUqLgfmfQ>
Cc: pce@ietf.org
Subject: Re: [Pce] PCE WG Last Call - draft-ietf-pce-pceps-04
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.15
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: Fri, 20 Nov 2015 15:25:38 -0000

Hi Tom,

Thank you for your valuable feedback. I think your comments could be 
addressed along with those to come from shepherd's review, unless the 
authors prefer to do an update before.

I have just contacted the Security Directorate without specifying a 
fixed version number, which should bring reviewers on the latest at 
review time.

To be continued,

Julien


Nov. 20, 2015 - ietfc@btconnect.com:
> Julien
>
> I am happy for the I-D to progress to IETF LC.  I will be interested to
> see a review by the Security Directorate and most interested to see what
> happens when the Security and Transport ADs review it:-)
>
> Meanwhile, some editorial thoughts to be picked up at some stage.
>
> IANA are being asked to exercise their PCE skills! You are asking for
> the allocation of more than one number but use TBA as the placeholder
> for every number; this requires someone to understand the protocol to
> know which number goes where.  Other editors use TBA1, TBA2,   ... TBA23
> etc which I think IANA would find clearer.
>
> IANA will also have to work out which registry is being updated, which
> is probably a more straightforward task.
>
> SHA-256 has no reference, and is ambiguous.  TLS uses SHA256 as its term
> but another list is currently updating its use of SHA to SHA-2 and is
> using SHA-2-256 on the grounds that SHA-3 is around and so SHA-3-256
> will be too so how do you tell the two apart when all you have is
> SHA256?  I find SHA-2-256 ugly but take their point so think it should
> be used here - and given a normative reference.
>
> s.3.1
> /this procedure update/this procedure updates/
>
> /The details of processing including backward compatibility is discussed
> /The details of processing including backward compatibility are
> discussed /
>
> s.3.2
> /including the open message/including the Open message/
>
> /session must be closed /the session must be closed /
>
> /A PCEP speaker receives any other message /A PCEP speaker receiving any
> other message /
>
> /(e.g. the certificate server is not responding)  /
> Is this a refererence to OCSP?  I am not used to there being certificate
> servers, unless they are CAs or providing CRLs.
>
> s.3.3
> /a PCEP session between the PCEP peers/
>
> Given the context, would /PCEPS session/ be appropriate?
>
> /form the PCEP peer /from the PCEP peer /
>
> Figure 3; based on the preceding text, I would expect there to be a
> PCErr message from PCC to PCE since it has received an Open message and
> not a StartTLS
>
> Figure 3
> /open message/Open message/
>
> s.3.5
> "fingerprint of the presented client certificate"
> Why only the client?  I would have expected this to apply to the server
> as well.
>
> Tom Petch
>
> ----- Original Message -----
> From: "Julien Meuric" <julien.meuric@orange.com>
> To: "Dhruv Dhody" <dhruv.dhody@huawei.com>; "DIEGO LOPEZ GARCIA"
> <diego.r.lopez@telefonica.com>
> Cc: <pce@ietf.org>
> Sent: Thursday, November 19, 2015 10:19 AM
>
>> Hi Dhruv,
>>
>> If you expect some updates after a review from the Security
> Directorate,
>> then the sooner the better. If you feel it useful, we will proceed
> when
>> your next revision is published.
>>
>> Thanks for being proactive here,
>>
>> Julien
>>
>> Nov. 19, 2015 - dhruv.dhody@huawei.com:
>>> Hi Julien,
>>>
>>> We have the update ready to go.
>>>
>>> Quoting from Tom's mail -
>>>
>>>> So I value the early intervention of the
>>>> Security Directorate to try and fix such
>>>> issues sooner, and so cheaper, rather than later.
>>>
>>> We were wondering if it would be worthwhile (and allowed by the
> process) to request for an early Sec-Dir review while the control is
> still with the WG?
>>>
>>> Regards,
>>> Dhruv
>>>
>>>> -----Original Message-----
>>>> From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of Julien Meuric
>>>> Sent: 19 November 2015 14:56
>>>>
>>>> Hola Diego,
>>>>
>>>> The WG LC was started for a 2-week period: you can consider it
> finished.
>>>>
>>>> Finished or not, you are expected to resolve all the received
> comments and
>>>> publish an update accordingly, so as to have the I-D ready to be
> sent to the
>>>> IESG. Feel free to proceed as soon as you are able to.
>>>>
>>>> Cheers,
>>>>
>>>> Julien
>>>>
>>>> Nov. 18, 2015 - diego.r.lopez@telefonica.com:
>>>>>
>>>>> And let me insist that I'd directly ask the UTA WG about this. My
> only
>>>>> question is about procedure: shall we wait till we finish the last
>>>>> call period? Shall we perform it as part of the last call process?
>>>>> What do our chairs think?
>