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

[Jamal Hadi Salim <[e-mail]>]

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

On Mon, Jan 31, 2011 at 3:48 PM, Stig Venaas <[e-mail]> wrote:
> Hi
>
> Thanks for the review. I have now submitted revision 04 that I believe
> takes care of your issues. See below.
>
> On 1/17/2011 5:57 AM, Jamal Hadi Salim wrote:
>>
>> 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
>
> I added
>
> 11-14 Unassigned      this document
>
>>     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.
>
> 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
>
>>
>> cheers,
>> jamal
>
>