H.248/MEGACO Registration Procedures
RFC 5615

[Ballot discuss]
5.3. Error Code Registration Procedure

[...]

  6) An error number shall not be redefined nor modified except by the
  organization or individual that originally defined it, or their
  successors or assigns.

I would like to better understand what is meant by "redifinition or modification" of an error number?
If this means that the error condition associated with an error is redefined, then surely this should result in another Expert review (to make sure that redifinition is a clarification, as opposed to assignment of a totally different meaning). If redefinition means changing of the error number, then again, this would require another Expert review.

[Ballot comment]
> 1. Binary ID (or serial number)

Do people really register these using the binary representation?
Perhaps you mean numeric, not binary. On the wire the number may
be binary, but the IANA registry, for instance, uses hexadecimal
representation. (http://www.iana.org/assignments/megaco-h248)

[Ballot discuss]
This document is fine overall, but there were two parts that I was
unable to understand. Am I missing something obvious, or is there
a mistake in the document:

>  3) The public package requester shall provide a reference to a
>  document that describes the package, which should be public:
>
>  a) The document shall specify the version of the package that it
>  describes.
>
>  b) If the document is public, it should be located on a public web
>  server and should have a stable URL. The site should provide a
>  mechanism to provide comments and appropriate responses should be
>  returned.
>
>  c) If the document is not public, it must be made available for
>  review by the IESG appointed Expert (without requiring an NDA) at the
>  time of the application.

I am not sure I understand how a "public package requester" can ask
for a value to a non-public specification, even if the expert reviewer
will be able to see it.

> Note: The documenting text does not have to be publicly available at
> the time of the registration request, however the text shall be
> provided and available for review by the IESG appointed Expert at the
> time of application.

I do not understand the difference between "at the time of the
registration request" and "at the time of application".

Also, how about s/documenting text/document/?

[Ballot comment]
From the Gen-ART Review by Pete McCann ...

  Section 4:

  OLD:
    As at this date
  NEW:
    As of this date


  OLD:
    As H.248 is a master slave protocol if the malicious
  NEW:
    As H.248 is a master slave protocol, if the malicious


  OLD:
    there would be no affect
  NEW:
    there would be no effect


  Section 6.2:

  OLD:
    On the request for an Error Code registration, the IANA shall forward
    thr received information (i.e. the Error Code text (Specification
    required) to the IESG appointed expert for review (See section 4.3).
  NEW:
    On the request for an Error Code registration, the IANA shall forward
    the received information (i.e. the Error Code text and required
    specification) to the IESG appointed expert for review (See section 4.3).


  Section 6.3:

  OLD:
    On the request for an Error Code registration, the IANA shall forward
    the received information (i.e. the Service Change Reason text
    (Specification required) to the IESG appointed expert for review (See
    section 4.4).
  NEW:
    On the request for an Error Code registration, the IANA shall forward
    the received information (i.e. the Service Change Reason text
    and required specification) to the IESG appointed expert for review (See
    section 4.4).

[Ballot discuss]
I have a question.  The answer to the question will determine whether
  a change to the document is needed.  Section 5.2 (Package Registration
  Procedure) allows for two kinds of registrations: public packages and
  private packages.  Section 5.2 paragraph (3)(c) allows a non-public
  documentation to be used by the IESG-appointed IANA Expert (without
  requiring an NDA).  I have no objection if the intent is to allow the
  review to take place before the documentation is made public.  Is this
  the intent?  Can a public package registration have permanently
  non-public documentation?  The Note in Section 5.2 could provide more
  clarity on this topic.

[Note]: 'IESG - when reviewing this, please consider the topic of if it is alright to register a "public" package when the specification is not publicly available. This came up as an IETF LC comment.' added by Cullen Jennings

IANA questions/comments:

Upon approval of this document, we understand that the registration procedures for all registries at  should be listed as "Expert Review."

Question 1: Section 5.1 says, "Updates to packages will be listed in increasing order of version number." We're not sure what this means. Does this change the order in which we list packages?

Question 2: Can you confirm that this document removes IETF Consensus as a
possible for registration procedure, and that only Expert Review will be used?