Subject: [PWE3] Oustanding Discusses and comments on draft-ietf-pwe3-iana-12.txt ( BCP ) -Brian Carpenter

From: Luca Martini <[email-masked]>
Date: Thu, 20 Oct 2005 22:08:30 -0600

Brian,

Thanks you for your very good comments. Please find the replies in line below.

Luca

DISCUSSES AND COMMENTS:
======================
Brian Carpenter:

Discuss [2005-10-11]:
Clarity and imprecision issues
(Some from me and some from a Gen-ART review by
Joel Halpern.)

LM: Note: I never saw a Gen-ART review. Did an e-mail get lost ?

> 2.1. Pseudowire Type
...
>   ...PW Type values 31 through 1024 are to be assigned by IANA,
>   using the "Expert Review" policy defined in [RFC2434].

There are multiple calls for Expert Review in this draft
and no guidance as to what the Expert will be looking for. This
makes it a guessing game - can we have a few guidelines for each 
case of Expert Review?

LM: Yes. I did not want to be too restrictive. However I will add the following:

-----------------------------
.Pb "Expert Review Directives"
Throughout this document allocation procedures for several registries call for
an expert review process according to [RFC2434]. The expert should consider
the following points:

.Pz *
Avoid Duplication of code point allocations.
.Pz *
A brief clear desctiption of the code point allocation requested.
.Pz *
Whether the type allocaton requested is appropriate for the particular
requested value range in the registry.
.En

The Expert reviewing the request MUST provide an answer, approving, or
disapproving the request within 10 business days from when the he or she
received the expert review request.

-------------------------------------

>   A Pseudowire Type description of up to 65 characters is required for
>   any assignment from this registry.

I don't believe this length restriction is reasonable. I believe it is 
impossible to give an adequate summary in 65 characters in every case.
On the contrary, I believe there should be a minimum length, no
particular maximum length, a requirement to cite a reference, and
a requirement to cite a person or company. For the other sections
of the document, the length restriction is probably OK, but
the citations are needed.

LM: Citing a person/company is no problem. I will also remove the length restriction for 
the pw type allocation, as you requested. 
Citing a reference is a little more complicated. However I will add text to require a reference to a document.

>   Initial Pseudowire type value allocations are specified below:
>
>      PW type Description
>
>      0x0001  Frame Relay DLCI ( Martini Mode )
>      0x0002  ATM AAL5 SDU VCC transport
...

These are not self-explanatory. I believe they should all include citations to wherever they are actually described.

LM: I think that this document is not supposed to be a glossary for PW types, so it's perfectly fine to have to go lookup
other documents that have the same text in the title. For example, presumably one would first read a PW encapsulation 
document, then look up this registry on the IANA web page. On the other hand , if ones searched for "Frame Relay Pseudowire" 
the future RFC describing in great details the frame relay encapsulation should be easily found.
However a reference to the relative document should be included.

> 2.2. Interface Parameters Sub-TLV type
...
>   Any assignments requested from this registry require a description up
>   to 54 characters. Furthermore a length specified as follows:
>     - A decimal integer
>     - Text as follows:"up to X", where X is a decimal integer
>     - Up to 3 different decimal integers.

Does this mean

   The length is specified in one of the following formats:

or something else?

Why is "A decimal integer" listed? It is a subset of "Up to 3 different decimal
integers".
Does "up to X" mean "up to and including X"?

Same comments apply to section 2.3.

LM: it means " The length is specified in one of the following formats "
I will fix the text in the hole document.

Big nit: wherever RFCs are cited they should be proper references,
either normative or informative.

LM: I do not understand this comment. The only RFC cited is Normative. This is clearly indicated in the
"normative reference" section.
IANA registries do not have a reference section, so I do know how to put a reference there.

_______________________________________________
pwe3 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pwe3

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 21 Oct 2005 13:36:05 +0200

Luca,

> Thanks you for your very good comments. Please find the replies in line 

Perhaps you weren't originally copied? In any case you have all the points,
I think.

Thanks for the proposed updates. They look OK to me.

<snip>

> IANA registries do not have a reference section, so I do know how to put 

I understand that when text is copied into an IANA registry, the references
will be treated exactly like plain text. But in the RFC version you can
give a normal reference. Here's an example. You have

    AGI Type     Length    Description
       0x01         8      Route distinguisher (RD) as defined in rfc2547

Isn't that normative? In any case, it can be

    AGI Type     Length    Description
       0x01         8      Route distinguisher (RD) as defined in [RFC2547]

with the reference included.

This is only marginally a DISCUSS comment, but since you'll be making an update
anyway, why not?

Thanks

     Brian