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

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

Hi, Christian,

Sorry for the delay in responding.

I am happy to let the IESG make a decision on whether or not
to make a distinction for "recognized" SDOs, and for availability
of specification.  I just wanted to make one point that may have
been glossed over: there is a distinction made between "public"
packages and "private" packages; they have different number spaces
for the binary ID.  Would it be too much to ask that if a specification
is not publicly available at a stable URL, then the package must
be registered in the "private" space?

-Pete

Christian Groves wrote:
> 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