[Pce] IANA allocation for draft-ietf-pce-stateful-pce and draft-ietf-pce-pce-initiated-lsp

[Jonathan Hardwick <[e-mail]>]

(changing the subject to match the topic)

Hi Robert

Thanks for this.  I believe that a few fixes are needed to the IANA sections of draft-ietf-pce-stateful-pce and draft-ietf-pce-pce-initiated-lsp to clarify the instructions that we are giving to IANA.  Please could you make these fixes so that I can kick off the allocation request?  In case you have not much time to work on these documents, don't worry - the changes are small (but important) and in each case I have proposed what I believe to be the correct text below.  If you have any concerns, please let me know.

Thanks
Jon

== draft-ietf-pce-stateful-pce ==

Section 8.1
Please replace the text before the table with the following:

	IANA is requested to allocate new bits in the OSPF Parameters "PCE Capability Flags" registry, as follows.

Section 8.2
Please replace the text before the table with the following:

	IANA is requested to allocate new message types within the "PCEP Messages" sub-registry of the PCEP Numbers registry, as follows.

Section 8.3
Please replace the text before the table with the following:

	IANA is requested to allocate new object-class values and object types within the "PCEP Objects" sub-registry of the PCEP Numbers registry, as follows.

The format of the table in this section needs to be cleaned up.  Copy the format from any RFC that defines a new PCEP object type.

Section 8.5
Please replace the text before the table with the following:

	IANA is requested to allocate new Error Types and Error Values within the " PCEP-ERROR Object Error Types and Values" sub-registry of the PCEP Numbers registry, as follows.

Section 8.6
Please replace the text before the table with the following:

	IANA is requested to allocate new Notification Types and Notification Values within the "Notification Object" sub-registry of the PCEP Numbers registry, as follows.

Section 8.7
Please replace the text before the table with the following:

	IANA is requested to allocate new TLV Type Indicator values within the " PCEP TLV Type Indicators" sub-registry of the PCEP Numbers registry, as follows.

Section 8.9
Please update the text to explain the procedure for assigning new values, and the qualities to track for each entry in the registry.  I think you need to add the following sentences to the end of the text before the table.

   New values are to be assigned by Standards Action [RFC5226].  Each
   value should be tracked with the following qualities:

   o  Value

   o  Description

   o  Defining RFC

   The following values are defined in this document:


== draft-ietf-pce-pce-initiated-lsp ==

Section 8.1
Please replace the text before the table with the following:

	IANA is requested to allocate a new message type within the "PCEP Messages" sub-registry of the PCEP Numbers registry, as follows.

Section 8.2
Please replace the text before the table with the following

	[I-D.ietf-pce-stateful-pce] defines the LSP Object and requests that IANA creates a registry to manage the value of the LSP Object's Flag field.  IANA is requested to allocate a new bit in the LSP Object Flag Field registry, as follows.

Section 8.3
Since [I-D.ietf-pce-stateful-pce] does not create a registry for the SRP object flags field, this document must do it instead.  Please replace the text in this section with the following.

   This document requests that a new sub-registry, named "SRP Object
   Flag Field", is created within the "Path Computation Element Protocol
   (PCEP) Numbers" registry to manage the Flag field of the SRP
   object.  New values are to be assigned by Standards Action [RFC5226].
   Each bit should be tracked with the following qualities:

   o  Bit number (counting from bit 0 as the most significant bit)

   o  Description

   o  Defining RFC

   The following values are defined in this document:

                 Bit     Description           Reference

                 31      LSP-Remove             This document

Section 8.4
Please replace the text before the table with the following

	[I-D.ietf-pce-stateful-pce] defines the STATEFUL-PCE-CAPABILITY TLV and requests that IANA creates a registry to manage the value of the STATEFUL-PCE-CAPABILITY TLV's Flag field.  IANA is requested to allocate a new bit in the STATEFUL-PCE-CAPABILITY TLV Flag Field registry, as follows.

Section 8.5
Please replace the text before the table with the following

	IANA is requested to allocate new error types and error values within the " PCEP-ERROR Object Error Types and Values" sub-registry of the PCEP Numbers registry, as follows.



-----Original Message-----
From: Robert Varga [mailto:[e-mail]] 
Sent: 27 June 2016 13:11
To: Jonathan Hardwick <[e-mail]>
Cc: DIEGO LOPEZ GARCIA <[e-mail]>; [e-mail]
Subject: Re: [Pce] draft-ietf-pce-pceps-07 available

On 02/02/2016 04:21 PM, Jonathan Hardwick wrote:
> Hi Robert

Hello Jon.

sorry for the delay, PCE work has been on the back burner :-(

> (I'm answering as WG chair.)
> 
>  
> 
> Sorry for the slow reply.  I would expect the progress of 
> draft-ietf-pce-pceps through to RFC to be reasonably fast, so I'm not 
> sure early code point allocation should be needed.  The main risk 
> would be a conflict with the stateful PCE drafts, should the new 
> message in the PCEPS draft be allocated a clashing code point with the 
> values that the stateful drafts have "recommended" for their messages.

I agree.

> I think it is possible that PCEPS will leap-frog stateful PCE on the 
> way to RFC, so I think the best way to proceed is to obtain an early 
> allocation for draft-ietf-pce-stateful-pce and 
> draft-ietf-pce-pce-initiated-lsp.  To do this we would only require 
> help from the stateful draft authors (e.g. you) to answer any 
> questions that IANA has about your text (which would happen sooner or 
> later anyway :-).  Would you like us to start an early allocation for these drafts?

I think this is a fair assessment. I can answer any questions and an early allocation would be an excellent way of ensuring we do not get clashes.

Thanks,
Robert