Subject: [RTG-DIR] RtgDir review: draft-ietf-pim-registry-03

From: Jamal Hadi Salim <[email-masked]>
Date: Mon, 17 Jan 2011 08:57:37 -0500

Hello,

I have been selected as the Routing Directorate reviewer for this draft.
The Routing Directorate seeks to review all routing or routing-related
drafts as they pass through IETF last call and IESG review. The purpose
of the review is to provide assistance to the Routing ADs. For more
information about the Routing Directorate, please see
http://www.ietf.org/iesg/directorate/routing.html

Although these comments are primarily for the use of the Routing ADs, it
would be helpful if you could consider them along with any other IETF
Last Call comments that you receive, and strive to resolve them through
discussion or by updating the draft.

Document: draft-ietf-pim-registry-03
Reviewer: Jamal Hadi Salim
Review Date: 2011-01-17
IETF LC End Date: 2011-01-20
Intended Status: proposed standard

Summary:

I have some very minor concerns about this document that may need
to be cleared before publication.

Comments:

The document is well written and structured to request IANA for
the creation of a registry for PIM message types. The initial
content specified on this document is based on existing RFCs.
The document goes on to specify how new PIM message types should
be allocated.

Major Issues:

No major issues found.

Minor Issues:
Although section 3.2 describes how the new types should be allocated,
given that this document is the first time all allocated PIM message
types are aggregated, it would be useful to also list the unassigned
message types and summarize what 3.2 says. i.e.

   Type   Name                                      Reference
   ----  ----------------------------------------  ---------------------
     0    Hello                                     [RFC3973] [RFC4601]
     1    Register                                  [RFC4601]
     2    Register Stop                             [RFC4601]
     3    Join/Prune                                [RFC3973] [RFC4601]
     4    Bootstrap                                 [RFC4601]
     5    Assert                                    [RFC3973] [RFC4601]
     6    Graft                                     [RFC3973]
     7    Graft-Ack                                 [RFC3973]
     8    Candidate RP Advertisement                [RFC4601]
     9    State Refresh                             [RFC3973]
    10    DF Election                               [RFC5015]
    11-14 Unassigned at the moment                  Future IETF Review
    15    Reserved (for extension of type space)    [this document]

Nits:

There is an interesting nit in that you have RFC 3973 as a normative
reference (which sounds deserving in the context of this document)
but that RFC is an experimental RFC.

cheers,
jamal

---

From: Adrian Farrel <[email-masked]>
Date: Tue, 18 Jan 2011 18:10:17 +0000

Hi,

A Normative reference is one that must be read to understand the document in
hand.

A reference used to say "this code point was created in the referenced document"
does not require the referenced document to be read. That would make it
Informational.

A

> -----Original Message-----
> From: Stig Venaas [mailto:[email-masked]]
> Sent: 18 January 2011 18:02
> To: Jamal Hadi Salim
> Cc: [email-masked]; [email-masked]; draft-ietf-pim-
> [email-masked]
> Subject: Re: RtgDir review: draft-ietf-pim-registry-03
> 
> On 1/17/2011 5:57 AM, Jamal Hadi Salim wrote:
> > Hello,
> >
> Thanks, I agree with your comments. Just one question.
> 
> [...]
> > Nits:
> >
> I'm not sure whether it is important, but I am wondering what is the
> right solution here. Is it OK to have a normative reference, or should
> it be an informative reference?
> 
> I'm sure it must be common that registries are created and need to
> reference e.g. experimental RFCs. In some cases the registry reference
> is not even an RFC. Perhaps it then makes more sense to list them as
> informative references?
> 
> Stig
> 
> >
> > cheers,
> > jamal

---

From: Stig Venaas <[email-masked]>
Date: Tue, 18 Jan 2011 10:02:02 -0800

[...]

Stig

---

From: Jamal Hadi Salim <[email-masked]>
Date: Wed, 19 Jan 2011 11:02:03 -0500

For completion sake: i am assuming the logical conclusion here is for
Stig to move
those refs to informative, correct?

cheers,
jamal

---

From: Stig Venaas <[email-masked]>
Date: Wed, 19 Jan 2011 09:46:34 -0800

> those refs to informative, correct?

I will. Based on the below, I should make all references informational,
even if the document using the code point is standards track.

That makes sense to me :)

Stig
>
> cheers,
> jamal
>
> On Tue, Jan 18, 2011 at 1:10 PM, Adrian Farrel<[email-masked]>  wrote:
>> Hi,
>>

---

From: Stig Venaas <[email-masked]>
Date: Mon, 31 Jan 2011 12:48:44 -0800

Hi

Thanks for the review. I have now submitted revision 04 that I believe
takes care of your issues. See below.

> message types and summarize what 3.2 says. i.e.

I added

11-14 Unassigned      this document

> but that RFC is an experimental RFC.

I have now made them informative. I believe that is appropriate.

In addition I added the sentence:

The message type is a 4-bit integer with possible values from 0 to 15.

Stig

---

From: Jamal Hadi Salim <[email-masked]>
Date: Mon, 31 Jan 2011 18:05:24 -0500

Hi Stig,

Sounds good to me. I will take your word for it and assume
that i dont need to validate the document for those changes ;->

cheers,
jamal