Hello Peter,
Please see my comments below, marked [CNG].
Regards, Christian
McCann Peter-A001034 wrote:
Hi, Christian,
I am fine on your and Cullen's explanation on the major issue.
It sounds like expert review is the right policy here. By
choosing
an expert closely affiliated with the ITU study group I guess we
are ceding some of the change control to them, which matches what
has been happening with the rest of the H.248 standards.
[CNG] I don't see the expert issue is one of affiliation or control
it just should be someone who is activity following or contributing
to the work. I would expect that that person would have to follow
both the IETF and the ITU.
On the question of "recognized standards organization", I really
wonder if we can do without this distinction. It seems like the
rules given in the draft mainly allow shorter codes to be
registered by these organizations. Would it really harm the world
for an individual to register a package with a short name? I can
imagine that some packages may become important even when not
developed by a "recognized standards organization". Given the
review that needs to take place, we could easily guard against
squatting or spamming behaviors.
[CNG] I've addressed this point more in response to Cullen email.
The original intention behind the split registry was that packages
defined by SDOs would be perceived differently to private packages.
On the question of publicly available specifications, personally I
would like to see this required of public packages. I don't think
it's fair for someone to use the IETF process for registering such
a package without disclosing enough information for anyone to
produce an interoperable implementation. The situation with H.248
right now is that I can go to the ITU website and download a copy,
which I think removed some of the qualms IETF may have had about
turning over change control from MEGACO to ITU. I wouldn't want
to see H.248 turned into a proprietary protocol through the
extension mechanisms.
[CNG] We've had the distinction between public and private packages
since the first Megaco/H.248 RFC/Recommendation and haven't had any
issues with this aspect thus far. I personally think that standards
should be made available to everyone but the reality is that there
are SDOs/Fora where documents are only available to members. I
think
this availability is a general issue and not just applicable the
Megaco/H.248 work. I think that it is a good thing that they may
want to use Megaco/H.248, if they want to add packages in addition
to what is already defined then for me this is OK. If those
packages are applicable to the wider community then this is a
comment that I think the IESG appointed expert can make and
encourage the organisation to make it more widely available. This
has occurred with 3GPP where they have proposed a 3GPP specific
function but based on feedback have let the ITU produce a more
general widely available solution. Another case was the MSF which
was looking at standardising their own packages which would have
been made available only to there members. On review and feedback
it was pointed out that the packages in instances were incorrect
and in other instances the packages were incorporated into ITU/ETSI
documents. So in short, to this date we haven't had the
"proprietary protocol"
issue and I don't think that the people/companies currently
involved
in the Megaco/H.248 standard would desire that this would happen.
-Pete
Christian Groves wrote:
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
