Re: [MMUSIC] RTSP 2.0: IANA rules for status codes

Magnus Westerlund <magnus.westerlund@ericsson.com> Thu, 19 November 2009 12:14 UTC

Return-Path: <magnus.westerlund@ericsson.com>
X-Original-To: mmusic@core3.amsl.com
Delivered-To: mmusic@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DD573A6B1F for <mmusic@core3.amsl.com>; Thu, 19 Nov 2009 04:14:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.149
X-Spam-Level:
X-Spam-Status: No, score=-6.149 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
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 aUBOz0k7MHOK for <mmusic@core3.amsl.com>; Thu, 19 Nov 2009 04:14:38 -0800 (PST)
Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 1221528C12B for <mmusic@ietf.org>; Thu, 19 Nov 2009 04:14:35 -0800 (PST)
X-AuditID: c1b4fb24-b7b67ae000001a2a-4e-4b0536a7d064
Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 4D.41.06698.7A6350B4; Thu, 19 Nov 2009 13:14:31 +0100 (CET)
Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 19 Nov 2009 13:14:31 +0100
Received: from [147.214.183.163] ([147.214.183.163]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 19 Nov 2009 13:14:31 +0100
Message-ID: <4B0536A6.308@ericsson.com>
Date: Thu, 19 Nov 2009 13:14:30 +0100
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Jean-Francois Mule <jf.mule@cablelabs.com>
References: <4AED834E.3010601@ericsson.com> <9AAEDF491EF7CA48AB587781B8F5D7C602645858@srvxchg3.cablelabs.com>
In-Reply-To: <9AAEDF491EF7CA48AB587781B8F5D7C602645858@srvxchg3.cablelabs.com>
X-Enigmail-Version: 0.96.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-OriginalArrivalTime: 19 Nov 2009 12:14:31.0067 (UTC) FILETIME=[D911E6B0:01CA6911]
X-Brightmail-Tracker: AAAAAA==
Cc: "mmusic (E-mail)" <mmusic@ietf.org>
Subject: Re: [MMUSIC] RTSP 2.0: IANA rules for status codes
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Nov 2009 12:14:39 -0000

Jean-Francois Mule skrev:
> Hi Magnus,
> 
>   We discussed this during the WG meeting in Hiroshima.  
> 
>    I agree that having a Standards Track RFC may be too high of a bar. I believe however that "IETF Consensus" (per RFC 2434) is preferable to "Specification Required" since it requires an RFC to be published in IETF.
> As I stated during the meeting, my concern with "Specification Required" is that status codes can often be re-used or made more generic.  I do not think it is a good idea to have any SDO or specification body create their own status codes for their specific use of RTSP.

As we are using RFC 5226 language I assume that you are suggesting:

      IETF Review - (Formerly called "IETF Consensus" in
            [IANA-CONSIDERATIONS]) New values are assigned only through
            RFCs that have been shepherded through the IESG as AD-
            Sponsored or IETF WG Documents [RFC3932] [RFC3978].  The
            intention is that the document and proposed assignment will
            be reviewed by the IESG and appropriate IETF WGs (or
            experts, if suitable working groups no longer exist) to
            ensure that the proposed assignment will not negatively
            impact interoperability or otherwise extend IETF protocols
            in an inappropriate or damaging manner.

            To ensure adequate community review, such documents are
            shepherded through the IESG as AD-sponsored (or WG)
            documents with an IETF Last Call.

I think this is better than Standards track, and do allow AD sponsored
informational documentation of other SDOs proposals. I personally are
still willing to suggest Specification required and make it clear that
there will be expert review, and that the reviewer may refuse the request.

Cheers

Magnus Westerlund

IETF Transport Area Director
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------