Re: Last Call on draft-ietf-pim-registry-03.txt

On 1/12/2011 5:25 AM, Adrian Farrel wrote:
> Hi Mykyta,
>
>> I am writing to provide some review on the draft-ietf-pim-registry,
>> that is currently in Last Call,
>
> Many thanks for reviewing.
>
>> Furstly, this document does not explain the abreviatures once they has
>> appeared in the title, abstract and main text.
>
> Good catch. It looks like a number of the acronyms we expected to be
> "well-known" are not.
> I find:
> PIM
> RFC (wow, that is a real surprise)

PIM is also in the list. The only one missing is RFC. Which indeed is
a surprise :) I can expand that if you want me to. Or we can leave it
to the RFC-Editor to decide?

> On the other hand, some *are* well-known and don't need to be expanded:
> IANA
> IGMP
> IETF
>
> For reference, see
> http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt
>
>> Moreover, the initial contents of the regsitry does not mention that
>> values that are Unassigned.
>
> Yeah, probably worth adding an entry...
>
> 11-14  Unassigned

I find it a bit superfluous, but I can certainly do that. Just so it's
clear that nothing may have been omitted.

>>   What is more, the document does not have
>> clear regsitry format description, eg. Message Type - an integer,
>> values from 0 to 15 are assigned etc.  I propose to create the
>> separate section and name it 'Regsitry Description' and place a number
>> of sub-section tehre that would describe the regsutry as detailed as
>> possible.
>
> You are right. The description of the Message Type should be included. In
> particular the range is very important.
> This should be added to the end of the paragraph in Section 3.

I agree. The document notes in the introduction that its 4 bits, but it
should be as part of the registry. Once the last call is ended I'll
do a new version where I point this out.

Stig

>> And in this occasion out the follwoing IANA Considerations'
>> Section:
>>
>> 'IANA is asked to create the 'name' regsitry following Section 2 of
>> this document."
>
> I am not sure what your suggestion is here. Section 3 begins with exactly this
> request (using different words).
>
>> So I recommend not to publih this document in the current view,
>
> Agreed. Thanks for catching these issues which can be fixed.
>
>> stop
>> the Last Call, if posible, and work on it a bit more.
>
> No, I don't think so.
> The purpose of a last call is not necessarily to have everyone agree that a
> document is perfect. The purpose is to catch exactly the type of issue you have
> raised.
>
> I do not believe that your input here (which *is* valuable) results in changes
> to the I-D that make a fundamental difference to the document that would
> necessitate a further last call.
>
> Thanks,
> Adrian
>
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf