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 _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
