Re: [Gen-art] Gen-ART review of draft-groves-megaco-pkgereg-02

["McCann Peter-A001034" <[e-mail]>]

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.

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.

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.

-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