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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf