Hello Peter and Cullen,
Peter, thanks for the comments. With regards to the major issue I would
agree with Cullen's comments. In addition it's important to point out
that the draft largely documents the process as it being implemented.
The written description (pre this draft) doesn't actually match what is
occurring. The draft also tries to set some review guidelines which
again weren't documented. We have previously in the Megaco/H.248 work
had cases where packages have been registered but basic things were
missing or not well explained which have caused issues. By describing a
review path we hope to pick these issues up before a package is fully
registered.
Please see my comments below on the other issues marked [CNG]
Once we resolve the "recognised standards organisation" issue i'll
provide an updated draft.
Regards, Christian
Cullen Jennings wrote:
Christian, could you take a look at the minor issues & nits and submit
a draft to resolve theses - if some of them don't need to be changed,
just sort that on this email thread.
Peter, on the topic of the Major issue...
The existing procedures require the review to happen at IETF. Almost
all the work on this is actually happening at ITU right now so we are
trying to make it easier for the ITU folks get the approvals they need
done. We will select an expert reviewer that is closely involved with
the ITU folks working on this as they are much more aware of all the
ongoing work is and can catch conflicts, duplicated efforts etc.
This should make it easier to get things approved than the current
process while at the same time helping improve the actual quality of
the review.
Hope that helps.
Cullen
On Feb 23, 2009, at 11:50 AM, McCann Peter-A001034 wrote:
I have been selected as the General Area Review Team (Gen-ART) reviewer
for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-groves-megaco-pkgereg-02
Reviewer: Peter J. McCann
Review Date: 23 February 2009
IETF LC End Date: 23 February 2009
IESG Telechat date: unknown
Summary: Ready with nits, if the IESG wants to change the IANA
considerations for H.248.
Major issues:
This document inserts an expert review procedure in the allocation
policy for new H.248 packages/error codes/service change/profiles.
This is probably a good thing but I have not been following the
history of the H.248 effort so I'm not aware of any problems that
have occurred under the existing allocation policies. The IESG
should weigh carefully whether the allocation policy really needs
changing.
Minor issues:
In a couple of places the document gives special treatment to
"recognized standards bodies." How does a standards body become
"recognized" by the IETF? Should we specify that a liaison relationship
must be in place?
[CNG] Yes it may be good to add which bodies are recognized. Given that
H.248/Megaco was developed jointly the people who came mainly from IETF
thought "IETF Liaison relationship" and those from the ITU probably
thought "Recognised Standards Development Organisation". I had a quick
look at the IETF website and found:
http://www.ietf.org/liaisonActivities.html is this the list of bodies
who the IETF has a liaison relationship with?
The ITU-T also maintains a list of qualified Forums/Consortiums
(http://www.itu.int/ITU-T/lists/qualified.aspx#forums). This seems to be
a more comprehensive list of organisations (i.e. it includes national
bodies). Could I had a pointer to this list in the draft?
Section 4.2 states that a specification is required for review by
the designated expert, but it seems to allow that this specification
isn't publicly available. Should there be a requirement at least for
public packages that the specification be public?
[CNG] I think this is really dependent on the rules of the standards
organisation. The IETF is good that all documents are public but this
doesn't apply to organisations such a MSF where the documents are
available to the members but not the general public. So I don't think
the draft can mandate that the package should be publicly available.
Nits/editorial comments:
Section 1:
OLD:
Given this situation, it is appropriate that the H.248/Package
Package definition
NEW:
Given this situation, it is appropriate that the H.248/Package
definition
[CNG] OK
Section 4.2:
OLD:
2) The package requester shall provide a contact name, email and
postal addresses for that contact shall be specified.
NEW:
2) The package requester shall provide a contact name, and an email
and
postal address for that contact shall be specified.
[CNG] OK
OLD:
provided available for review
NEW:
provided and available for review
[CNG] OK
OLD:
5) Package names are allocated on a first come-first served if all
other conditions are met.
NEW:
5) Package names are allocated on a first come-first served basis if
all
other conditions are met.
[CNG] OK
Section 5.1:
OLD:
shall forward to received information
NEW:
shall forward the received information
[CNG] OK
Section 5.2:
OLD:
On the request for an Error Code registration, the IANA shall forward
to 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).
[CNG] OK
Section 5.3:
OLD:
On the request for an Error Code registration, the IANA shall forward
to 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 Service Change Reason 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).
[CNG] OK
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
