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

[t.petch <[e-mail]>]

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" <[e-mail]>
To: "Dhruv Dhody" <[e-mail]>; "DIEGO LOPEZ GARCIA"
<[e-mail]>
Cc: <[e-mail]>
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 - [e-mail]:
> > 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:[e-mail]] 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 - [e-mail]:
> >>>
> >>> 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?