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

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

Hi, Christian,

I can understand your point of view.  I am missing a lot of
history here and I wouldn't be upset to see the registry handled
as you suggest.  I'll let the IESG ponder the points I've raised
and let them make a decision.

-Pete

Christian Groves wrote:
> Hello Pete,
> 
> No worries about the delay as there was IETF meeting to deal with.
> 
> I don't think the fact that public and private packages have
> different ranges has been glossed over. This has been utilised by
> different registrations. You can see from the current registrations
> that private companies i.e. Ericsson, Nokia have registered packages
> in the "private"    
> space.
> 
> I'm hesitant to mandate that unless the document is "publicly"
> available then the package must be registered in the "private" space.
> This is really due to the history of the protocol and the knowledge
> that the wording was like it was to allow membership based SDOs to
> have a different status from private companies. For instance if the
> ITU hadn't made Recommendations publicly available we'd now be
> proposing that their packages become "private" which I sure would
> have raised a few eye brows.       
> 
> So from my perspective I would prefer to leave the current text
> because this aspect of public vs private and the availability of
> packages hasn't caused us trouble since the inception of the
> registry. What has caused trouble is the quality of the packages and
> in part that's what the draft is trying to address.    
> 
> Regards, Christian
> 
> McCann Peter-A001034 wrote:
>> 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