Subject: [Pce] Looking at the PCEP DSTE I-D

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 3 Apr 2008 16:26:22 +0100

Hi,

Thanks for working on this I-D. I have just been looking at it and there a 
couple of process issues I think you need to clean up...

===
Watch out! Your I-D is about to expire
===
Insert a blank line between document title and filename
===
Please run idnits (http://tools.ietf.org/tools/idnits/)
I see 1 error and 8 warnings
===
Indentation and layout.
I think you are victims of Microsoft Word.
You need to leftshift the whole document by five spaces.
It would be nice to have a blank line at the top of each page.
===
Repetition of common object header.
You don't need to (i.e. you shouldn't ;-) reproduce text from [PCEP] because 
that creates a potential conflict of definitions.
===
Use of P and I bits.
If the P bit is set, the Classtype object must be taken into account. If 
clear it can be ignored.
The I bit requests the inclusion of object in the response if it was 
ignored.
But you have:
        Path computation reply message MUST NOT include a CLASSTYPE
        object.
Does that mean that you intend to mandate that the P bit is set in the 
object header on the request?
===
Codepoint allocations
You have some conflicts with other I-Ds.
I have included your I-Ds in the codepoint registry at
http://www.olddog.co.uk/pcep-codepoints.txt
Search for [DSTE] and update your I-D accordingly.
===
IANA section
You mustn't expect the folk at IANA to trawl through the draft or to know 
PCEP. So you need to have more detailed IANA section. For example...

IANA maintains a registry of parameters for PCEP. This contains a 
sub-registry for PCEP objects. IANA is requested to make a new allocation 
from this registry as follows:

   Object   Name                                           Reference
   Class
   22       CLASSTYPE                                      [This.I-D]
              Object-Type
                1: Class Type                              [This.I-D]

You need to make a similar request for the new error type and values.
===
Manageability considerations
This section is not mandatory, but the WG is trying to always consider 
manageability when developing protocol extensions. My guess is that there 
are not many requirements here, but certainly some configurable items.
===
Typos
s/Client(PCC)/Client (PCC)/
s/for which path is to be/for which the path is to be/
s/does not support CLASSTYPE object/does not support the CLASSTYPE object/
s/Author's Addresses/Authors' Addresses/
Several times you have "the draft [PCEP-ID]". You should change this to 
"[PCEP-ID]"

Cheers,
Adrian 

_______________________________________________
Pce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pce

---

From: "Siva Sivabalan (msiva)" <[email-masked]>
Date: Thu, 17 Apr 2008 10:18:13 -0400

Thanks Adrian for your comments. We will address them and send out a new
rev.

Also, regarding the P-bit, yes we will mandate that P-bit is set in the
PCEReq. As such, I bit is ignored for the CLASSTYPE object.

Regards,
Siva 

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]] 
Sent: Thursday, April 03, 2008 11:26 AM
To: Siva Sivabalan (msiva); Jon Parker (jdparker); Sami Boutros
(sboutros); Kenji Kumaki
Cc: [email-masked]
Subject: Looking at the PCEP DSTE I-D

Hi,

Thanks for working on this I-D. I have just been looking at it and there
a couple of process issues I think you need to clean up...

===
Watch out! Your I-D is about to expire
===
Insert a blank line between document title and filename === Please run
idnits (http://tools.ietf.org/tools/idnits/)
I see 1 error and 8 warnings
===
Indentation and layout.
I think you are victims of Microsoft Word.
You need to leftshift the whole document by five spaces.
It would be nice to have a blank line at the top of each page.
===
Repetition of common object header.
You don't need to (i.e. you shouldn't ;-) reproduce text from [PCEP]
because that creates a potential conflict of definitions.
===
Use of P and I bits.
If the P bit is set, the Classtype object must be taken into account. If
clear it can be ignored.
The I bit requests the inclusion of object in the response if it was
ignored.
But you have:
        Path computation reply message MUST NOT include a CLASSTYPE
        object.
Does that mean that you intend to mandate that the P bit is set in the
object header on the request?
===
Codepoint allocations
You have some conflicts with other I-Ds.
I have included your I-Ds in the codepoint registry at
http://www.olddog.co.uk/pcep-codepoints.txt
Search for [DSTE] and update your I-D accordingly.
===
IANA section
You mustn't expect the folk at IANA to trawl through the draft or to
know PCEP. So you need to have more detailed IANA section. For
example...

IANA maintains a registry of parameters for PCEP. This contains a
sub-registry for PCEP objects. IANA is requested to make a new
allocation from this registry as follows:

   Object   Name                                           Reference
   Class
   22       CLASSTYPE                                      [This.I-D]
              Object-Type
                1: Class Type                              [This.I-D]

You need to make a similar request for the new error type and values.
===
Manageability considerations
This section is not mandatory, but the WG is trying to always consider
manageability when developing protocol extensions. My guess is that
there are not many requirements here, but certainly some configurable
items.
===
Typos
s/Client(PCC)/Client (PCC)/
s/for which path is to be/for which the path is to be/ s/does not
support CLASSTYPE object/does not support the CLASSTYPE object/
s/Author's Addresses/Authors' Addresses/ Several times you have "the
draft [PCEP-ID]". You should change this to "[PCEP-ID]"

Cheers,
Adrian