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