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