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

[Cullen Jennings <[e-mail]>]

Thanks all - I have issued the IESG ballot for this and asked the IESG  
to consider the issue Pete raised when evaluating this.


On Mar 31, 2009, at 8:43 AM, McCann Peter-A001034 wrote:

> 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
>