Re: [RAI] Option-tag registration

"Richard Shockey" <richard@shockey.us> Fri, 09 April 2010 16:10 UTC

Return-Path: <richard@shockey.us>
X-Original-To: rai@core3.amsl.com
Delivered-To: rai@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 088343A69ED for <rai@core3.amsl.com>; Fri, 9 Apr 2010 09:10:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.842
X-Spam-Level:
X-Spam-Status: No, score=-1.842 tagged_above=-999 required=5 tests=[AWL=0.757, BAYES_00=-2.599]
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 aAGEUYqbA80K for <rai@core3.amsl.com>; Fri, 9 Apr 2010 09:10:39 -0700 (PDT)
Received: from outbound-mail-360.bluehost.com (oproxy2-pub.bluehost.com [66.147.249.254]) by core3.amsl.com (Postfix) with SMTP id 4F6B73A6828 for <rai@ietf.org>; Fri, 9 Apr 2010 09:10:39 -0700 (PDT)
Received: (qmail 12823 invoked by uid 0); 9 Apr 2010 16:10:35 -0000
Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy2.bluehost.com with SMTP; 9 Apr 2010 16:10:35 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=Q59DaanaTUS0lWLMQzy/fSLwjuOiXMHRI2AaDf4n7F9oDTYJNdETS2bXvQUvMVP9FU32WUuXzohuY3FgLrcRJm4hMmsYTPexxr98b7Vp05ysYd1PahROdoPLwqIG4AL6;
Received: from pool-96-231-199-72.washdc.fios.verizon.net ([96.231.199.72] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from <richard@shockey.us>) id 1O0Gmx-0002Ji-D0; Fri, 09 Apr 2010 10:10:35 -0600
From: Richard Shockey <richard@shockey.us>
To: 'Dan York' <dyork@voxeo.com>, 'Scott Lawrence' <xmlscott@gmail.com>
References: <498A0FE8.5040307@neustar.biz> <E6C2E8958BA59A4FB960963D475F7AC313DE6E8D90@mail> <430FC6BDED356B4C8498F634416644A91A79F3D3F9@mail> <1270818172.4307.167.camel@localhost> <C4C941E3-15D2-4EC7-836F-CC7CE2A56F7C@voxeo.com>
In-Reply-To: <C4C941E3-15D2-4EC7-836F-CC7CE2A56F7C@voxeo.com>
Date: Fri, 09 Apr 2010 12:10:30 -0400
Message-ID: <000601cad7ff$2de5aee0$89b10ca0$@us>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcrX/AF6LknDfgqeS5ywVrb6xd2tCQAAgLnw
Content-Language: en-us
X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 96.231.199.72 authed with richard@shockey.us}
Cc: rai@ietf.org, 'Hadriel Kaplan' <HKaplan@acmepacket.com>
Subject: Re: [RAI] Option-tag registration
X-BeenThere: rai@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Real-time Applications and Infrastructure \(RAI\)" <rai.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/rai>, <mailto:rai-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rai>
List-Post: <mailto:rai@ietf.org>
List-Help: <mailto:rai-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rai>, <mailto:rai-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Apr 2010 16:10:42 -0000

Well needless to say I' +++++ 1 for this proposal. Expert review for Option
Tags is a very sensible idea that would solve a host of problems, including
some we are dealing with right now.

Expert review is what we did in ENUM for new ENUM services and it's the hope
we have for E2MD tags as well. Full RFC requirements here are an excuse for
some to stall, delay and/or kill perfectly good proposals that enhance the
interoperability of SIP. 

The larger problem in the RAI area IMHO is that even the DISPATCH process
had done nothing to reverse the increasing problem in the IETF of demanding
unanimous consent vs rough consensus. From a process perspective we have
become what we always feared and ridiculed...the ITU of the 1980-90's. 



-----Original Message-----
From: rai-bounces@ietf.org [mailto:rai-bounces@ietf.org] On Behalf Of Dan
York
Sent: Friday, April 09, 2010 11:48 AM
To: Scott Lawrence
Cc: rai@ietf.org; Hadriel Kaplan
Subject: Re: [RAI] Option-tag registration

Hadriel,

I also agree with you (and Scott).

I started the process over 2 years ago of simply trying to register a  
P-header that was already in usage among various equipment vendors (P- 
Charge-Info - http://tools.ietf.org/html/draft-york-sipping-p-charge-info 
  ) and found that the RFC 3427 process was incredibly cumbersome.   
All I was trying to do was to help prevent the proliferation of P- 
headers with multiple people trying to do the same thing.  My hope was  
that someone else wanting to pass billing info (in this case) might  
more easily find P-Charge-Info through the IANA SIP header list and,  
hopefully, choose to use that header if it fit for them rather than  
creating yet-another-P-header-that-does-basically-the-same-thing.  The  
proliferation of P-headers doesn't help any of us and certainly  
doesn't help with interop.

I think we need to make it as easy as possible for people to register  
P-headers (and yes, I know that "P-" is deprecated)... and yes, the  
new RFC 5727 (i.e. 3427bis) will help with that, although I'm still  
not sure if it explains the process easily enough for a newbie to the  
IETF to understand what they need to do.  Yes, we need a review  
process to help submitters see if there are valid technical points  
they aren't considering... the process for P-Charge-Info was very  
helpful in identifying a few areas that needed further specification.

But in the end I think we need to remove as much friction as possible  
so that people WILL register headers which will help other people FIND  
those headers and then hopefully not create new ones.  I agree with  
your point, too, Hadriel, about the registration of custom headers  
pointing to areas where work needs to be done.  If we find that there  
are 7 different custom headers being registered that deal with, say,  
the number of buttons on an IP phone... then perhaps there is an area  
that needs true standardization work (hopefully this particular  
example would never occur).

I agree that option tags are in a similar situation.  People are  
creating them anyway. I'm sure there are already duplicates and I'm  
sure they are causing interop issues.

So yes, we should make it as easy as possible to register option tags,  
too, subject to some basic review process, so that we can help guide  
people to option tags that are already existing so that they don't go  
off and create even more.

My 2 cents,
Dan

On Apr 9, 2010, at 9:02 AM, Scott Lawrence wrote:

> On Fri, 2010-04-09 at 01:53 -0400, Hadriel Kaplan wrote:
>
>> It's been over a year since I sent this email, so I thought I'd
>> re-send it to see if anyone else cares about this topic yet, since it
>> got not responses last year...
>>