Re: [Megaco] Updated H.248 Package Registration Procedures Draft
"Schwarz Albrecht" <Albrecht.Schwarz@alcatel-lucent.de> Fri, 14 March 2008 08:28 UTC
Return-Path: <megaco-bounces@ietf.org>
X-Original-To: ietfarch-megaco-archive@core3.amsl.com
Delivered-To: ietfarch-megaco-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44BB128C805; Fri, 14 Mar 2008 01:28:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.186
X-Spam-Level:
X-Spam-Status: No, score=-100.186 tagged_above=-999 required=5 tests=[AWL=-0.099, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uZlxheG3i0e3; Fri, 14 Mar 2008 01:28:28 -0700 (PDT)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F3E628C779; Fri, 14 Mar 2008 01:28:28 -0700 (PDT)
X-Original-To: megaco@core3.amsl.com
Delivered-To: megaco@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D72F28C7AA for <megaco@core3.amsl.com>; Fri, 14 Mar 2008 01:28:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BBBj6UrEcouU for <megaco@core3.amsl.com>; Fri, 14 Mar 2008 01:28:25 -0700 (PDT)
Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id 5253D28C677 for <megaco@ietf.org>; Fri, 14 Mar 2008 01:28:24 -0700 (PDT)
Received: from FRVELSBHS07.ad2.ad.alcatel.com (frvelsbhs07.ad2.ad.alcatel.com [155.132.6.79]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id m2E89U2B001920 for <megaco@ietf.org>; Fri, 14 Mar 2008 09:09:48 +0100
Received: from FRVELSMBS23.ad2.ad.alcatel.com ([155.132.6.53]) by FRVELSBHS07.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Fri, 14 Mar 2008 09:26:04 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Fri, 14 Mar 2008 09:26:01 +0100
Message-ID: <F4562D4585113D42AC08DC47FDEC49B09CFDCD@FRVELSMBS23.ad2.ad.alcatel.com>
In-Reply-To: <47D9C466.3000404@nteczone.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Megaco] Updated H.248 Package Registration Procedures Draft
Thread-Index: AciFaT/52alaKZsRRzCMdIKwZ78l7gAQ6Ixw
References: <47D9C466.3000404@nteczone.com>
From: Schwarz Albrecht <Albrecht.Schwarz@alcatel-lucent.de>
To: megaco ietf <megaco@ietf.org>
X-OriginalArrivalTime: 14 Mar 2008 08:26:04.0387 (UTC) FILETIME=[0B344330:01C885AD]
X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13
Subject: Re: [Megaco] Updated H.248 Package Registration Procedures Draft
X-BeenThere: megaco@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Media Gateway Control <megaco.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/megaco>, <mailto:megaco-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:megaco@ietf.org>
List-Help: <mailto:megaco-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/megaco>, <mailto:megaco-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: megaco-bounces@ietf.org
Errors-To: megaco-bounces@ietf.org
Do support the updated draft and agree to update the procedures. Albrecht Schwarz ALCATEL-LUCENT > -----Original Message----- > From: megaco-bounces@ietf.org > [mailto:megaco-bounces@ietf.org] On Behalf Of Christian Groves > Sent: Freitag, 14. März 2008 01:19 > To: megaco ietf > Subject: [Megaco] Updated H.248 Package Registration Procedures Draft > > Hello all, > > The draft-groves-megaco-pkgereg-01.txt has now been updated. > See: > http://www.ietf.org/internet-drafts/draft-groves-megaco-pkgereg-01.txt > > The main changes have been to clarify that the IESG appoints > the Expert reviewer and that the documents for review have to > be made available to the expert reviewer. These changes were > in response to comments from one of the RAI ADs. If you're > interested in the comments see the end of this email. > > There was some concern from the ADs that as there was little > discussion on the Megaco Mailing list that there was no > consensus on this issue. > For those with an interest I would encourage you to respond > even if its "I agree to update the procedures". > > As this issue has been around for quite some time my > intention is to request publication as an RFC in two weeks > (28 March) so please let me know your comments before then. > > Regards, Christian > > > Cullen Jennings wrote: > > > > It's not actually IANA that allocates the expert review it > is IETF so > > would need to change make it clear the expert was appointed by IETF > > not IANA. Specifically the experts are appointed by IESG. > [CNG] No problem I can make the change from make it clear > that the IESG appoints the expert, I see this as a rather > minor change. I've referred to this person as the "IANA > Expert" what do you suggest changing this to? Narten uses > "Expert Reviewer" but considering this text will also appear > in ITU documents should it be "IETF Expert Reviewer", "IESG > Appointed Expert Reviewer", or? > > > > As I have mentioned before, IANA is not keen on the two > stage process, > > I am willing to go talk to IESG about this if you want and > see if this > > is likely to fly or not. IANA would want the expert review > before the > > IP registration - the goal here is to have the expert not > IANA check > > that the rules such as character length and and such had been > > satisfied. Could you live with not having the two stage process? I > > understand the problem of this for early developers of packages. > [CNG] Yes please talk to IESG, but I thought the IANA had the > problem? > This two stage process is already part of the IANA process. > Please look > at: http://www.iana.org/assignments/megaco-h248 there is a > heading "Status" which has "In Progress (IP) and Final (FI). > Today requests for Package IDs get sent to IANA who > communicates with Tom Taylor. I guess he says ok (I don't see > the emails) and IANA gets back to say the package is > registered. Its registered with (IP). Then once the package > is approved by the body that wrote it, they then request IANA > to set the status to (FI). It is then clear for people who > look at the IANA registration what state is package is in and > both organisations are aligned. This was important because of > the MEGACO WG and Q.3/16 link. So as I've mentioned the draft > is not trying to change this element of an already existing process. > > The process was designed for groups to be able to get > PackageID information before their documents were finalised. > This was to allow other standards bodies to be able to > approve their own document. Having a Final status then allows > the IANA/IETF to know that the work is finished. Having IANA > as the central place to send registration requests and then > they communicate with the expert reviewer allows other > standards group to have a central contact point. How does > Tispan / ITU / 3GPP / MSF know who each of the relevant > experts in each area. I don't know of any page that has this > information. The experts are also likely to change. The > process is in alignment with the Narten draft which states " > > IANA forwards requests for an assignment to the expert for > evaluation, and the expert (after performing the evaluation) > informs IANA whether or not to make the assignment or registration." > > > With regards to your comment "I understand the problem of > this for early > developers of packages." I'm not really sure what you mean? > > > > For non public documents "made available for review" is a bit > > undefined. Would this require a NDA in some cases? Is there any > > reasons not to just use "Specification required" here as defined in > > draft-narten-iana-considerations-rfc2434bis? > [CNG] The issue here is that some organisations don't have > their working > drafts "publicaly available". They have them available to > their members. > E.g. you need to be a member of the ITU to get TDs for study Group > meetings. So in this case if the Expert Reviewer is not a > member of the > ITU they won't be able to download the document via a public link. It > must be sent to them. I don't think that a NDA is needed. Sending the > document would be no different than sending a liaison/communication > between standards bodies. Thus the problem with > "specification required" > being linked to a "publically available document" from the > Narten draft > means that a standards body would have to approve the document first > before registration. However we actually want the Expert Reviewer to > look at an early copy before the text is finalised and set in > stone. It > is much harder and causes more delay to provide comments at a late > stage. Effectively its the problem we are having now... > > > Regards, Christian > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www.ietf.org/mailman/listinfo/megaco > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www.ietf.org/mailman/listinfo/megaco
- [Megaco] Updated H.248 Package Registration Proce… Christian Groves
- Re: [Megaco] Updated H.248 Package Registration P… Schwarz Albrecht