Re: [Fecframe] [IANA #394228] RE: LastCall:<draft-ietf-fecframe-sdp-elements-08.txt> (SessionDescriptionProtocol (SDP) Elements for FEC Framework) toProposed Standard

"Ali C. Begen (abegen)" <abegen@cisco.com> Sat, 02 October 2010 03:47 UTC

Return-Path: <abegen@cisco.com>
X-Original-To: fecframe@core3.amsl.com
Delivered-To: fecframe@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC8643A6DEF; Fri, 1 Oct 2010 20:47:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.551
X-Spam-Level:
X-Spam-Status: No, score=-10.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 b35Ai9ncwJDg; Fri, 1 Oct 2010 20:47:38 -0700 (PDT)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 1D9A23A6BF1; Fri, 1 Oct 2010 20:47:38 -0700 (PDT)
Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAItIpkyrR7Hu/2dsb2JhbACiP3GqSJwighhzgjkEhFGIcw
X-IronPort-AV: E=Sophos;i="4.57,270,1283731200"; d="scan'208";a="598022527"
Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 02 Oct 2010 03:48:27 +0000
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o923mRUM016491; Sat, 2 Oct 2010 03:48:27 GMT
Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 1 Oct 2010 20:48:27 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 01 Oct 2010 20:48:08 -0700
Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540D4FA7CE@xmb-sjc-215.amer.cisco.com>
In-Reply-To: <EFC5F16399674BB8B9F636AC080EA44E@23FX1C1>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Fecframe] [IANA #394228] RE: LastCall:<draft-ietf-fecframe-sdp-elements-08.txt> (SessionDescriptionProtocol (SDP) Elements for FEC Framework) toProposed Standard
Thread-Index: ActhzFP1FVdTT7ckQ4WL6hHo4fy9GAAFfT8AAAB0rSA=
References: <RT-Ticket-394228@icann.org><RT-Ticket-386944@icann.org><20100827154930.23394.79420.idtracker@localhost><rt-3.8.3pre1-17157-1284145517-1171.386944-7-0@icann.org><04CAD96D4C5A3D48B1919248A8FE0D540D39EB01@xmb-sjc-215.amer.cisco.com><rt-3.8.3pre1-8096-1285980782-1904.394228-7-0@icann.org> <EFC5F16399674BB8B9F636AC080EA44E@23FX1C1>
From: "Ali C. Begen (abegen)" <abegen@cisco.com>
To: David Harrington <ietfdbh@comcast.net>, fecframe@ietf.org, TSV Dir <tsv-dir@ietf.org>
X-OriginalArrivalTime: 02 Oct 2010 03:48:27.0744 (UTC) FILETIME=[AC113E00:01CB61E4]
Cc: fecframe-chairs@tools.ietf.org, iesg@ietf.org
Subject: Re: [Fecframe] [IANA #394228] RE: LastCall:<draft-ietf-fecframe-sdp-elements-08.txt> (SessionDescriptionProtocol (SDP) Elements for FEC Framework) toProposed Standard
X-BeenThere: fecframe@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of FEC Framework <fecframe.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/fecframe>, <mailto:fecframe-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/fecframe>
List-Post: <mailto:fecframe@ietf.org>
List-Help: <mailto:fecframe-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/fecframe>, <mailto:fecframe-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 02 Oct 2010 03:47:39 -0000

One alternative is to register the ones we care about now, and if a new protocol is defined in the future and then later someone wants to use it as a source flow in the fec framework, then, they register it with IANA. In other words, the registration stays "on demand".

One way or another, the flows of the modified source packets have to be described in the SDP. So, a transport protocol identifier is required.

-acbegen

> -----Original Message-----
> From: fecframe-bounces@ietf.org [mailto:fecframe-bounces@ietf.org] On Behalf Of David Harrington
> Sent: Friday, October 01, 2010 11:39 PM
> To: fecframe@ietf.org; 'TSV Dir'
> Cc: fecframe-chairs@tools.ietf.org; iesg@ietf.org
> Subject: Re: [Fecframe] [IANA #394228] RE: LastCall:<draft-ietf-fecframe-sdp-elements-08.txt> (SessionDescriptionProtocol
> (SDP) Elements for FEC Framework) toProposed Standard
> 
> Hi fecframe,
> 
> I didn't like this much when I did my AD review and I still don't.
> I think this puts tremendous load on IANA to do this for us
> automatically for every current and future registration.
> Can we please design a different approach to FEC registration.
> I think there must be a simpler manner to do this.
> 
> TSVDIR, can you suggest a better approach for this?
> 
> David Harrington
> Director, IETF Transport Area
> ietfdbh@comcast.net (preferred for ietf)
> dbharrington@huaweisymantec.com
> +1 603 828 1401 (cell)
> 
> > -----Original Message-----
> > From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On
> > Behalf Of Amanda Baber via RT
> > Sent: Friday, October 01, 2010 8:53 PM
> > Cc: fecframe-chairs@tools.ietf.org; abegen@cisco.com; iesg@ietf.org
> > Subject: [IANA #394228] RE: Last
> > Call:<draft-ietf-fecframe-sdp-elements-08.txt> (Session
> > DescriptionProtocol (SDP) Elements for FEC Framework) to
> > Proposed Standard
> >
> > Hi Ali,
> >
> > Just to make sure we understand what you're asking for: you
> > want this document to modify the registration procedures for
> > the proto registry to be modified so that for every current
> > and future registration -- RTP/AVP, vat, TCP, et al. -- IANA
> > would also automatically register FEC/RTP/AVP, FEC/vat,
> > FEC/TCP, and so on?
> >
> > This sounds like a decision for the ADs. We're able do this
> > -- we'd just  have to insert a note in the registry
> > instructing ourselves to do it -- but we can't think of any
> > other registries that behave this way.
> >
> > Thanks,
> >
> > Amanda
> > IANA
> >
> > On Thu Sep 23 19:55:01 2010, abegen@cisco.com wrote:
> > > Hi Amanda,
> > >
> > > We cleared the earlier issues with this draft. However, during the
> > >    IESG review something came up. This is about section 4.1. In
> > >    addition to registering UDP/FEC, we also need several other
> > >    registrations for FEC/<proto> for the proto's listed in the SDP
> > >    registry. I wonder how we can do this effectively. A shortcut
> > >    maybe?
> > >
> > > I am probably pushing the limit here. But I wonder whether we
> could
> > >    define something here so that when a new proto is
> > registered in the
> > >    future, FEC/<proto> can also be automatically registered based
> on
> > >    this draft.
> > >
> > > I am about to revise this draft. I would appreciate if you
> > could tell
> > >    me what I should put in section 8.1 regarding the above.
> > >
> > > Thanks in advance.
> > >
> > > -acbegen
> > >
> > > > -----Original Message-----
> > > > From: Amanda Baber via RT [mailto:drafts-lastcall@iana.org]
> > > > Sent: Friday, September 10, 2010 3:05 PM
> > > > Cc: Ali C. Begen (abegen); fecframe-chairs@tools.ietf.org;
> > >    iesg@ietf.org
> > > > Subject: [IANA #386944] Last Call: <draft-ietf-fecframe-sdp-
> > >    elements-08.txt> (Session Description Protocol (SDP) Elements
> for
> > > > FEC Framework) to Proposed Standard
> > > >
> > > > IESG:
> > > >
> > > > IANA has reviewed
> > draft-ietf-fecframe-sdp-elements-08.txt, which is
> > > > currently in Last Call, and has the following comments:
> > > >
> > > > IANA has questions about this document.
> > > >
> > > > IANA understands that, upon approval of this document,
> > there are two
> > > > IANA Actions that need to be completed.
> > > >
> > > > First, in the proto type subregistry of the Session Description
> > >    Protocol
> > > > (SDP) Parameters located at:
> > > >
> > > > http://www.iana.org/assignments/sdp-parameters
> > > >
> > > > a single new value is to be registered:
> > > >
> > > > Type SDP Name Reference
> > > > ----- ---------- -----------
> > > > proto UDP/FEC [RFC-to-be]
> > > >
> > > > Second, in one of the att-field subregistries of the Session
> > >    Description
> > > > Protocol (SDP) Parameters located at:
> > > >
> > > > http://www.iana.org/assignments/sdp-parameters
> > > >
> > > > three new attribute names are to be added as follows:
> > > >
> > > > SDP Attribute ("att-field"):
> > > > Attribute name: fec-source-flow
> > > > Long form: Pointer to FEC Source Flow Type of name:
> > att-field Type
> > > > of attribute: Media level Subject to charset: No
> > > > Purpose: Provide parameters for an FEC source flow
> > > > Reference: [RFC-to-be]
> > > > Values: See [RFC-to-be]
> > > >
> > > > SDP Attribute ("att-field"):
> > > > Attribute name: fec-repair-flow
> > > > Long form: Pointer to FEC Repair Flow Type of name:
> > att-field Type
> > > > of attribute: Media level Subject to charset: No
> > > > Purpose: Provide parameters for an FEC repair flow
> > > > Reference: [RFC-to-be]
> > > > Values: See [RFC-to-be]
> > > >
> > > > SDP Attribute ("att-field"):
> > > > Attribute name: repair-window
> > > > Long form: Pointer to FEC Repair Window Type of name:
> > att-field Type
> > > > of attribute: Media level Subject to charset: No
> > > > Purpose: Indicate the size of the repair window
> > > > Reference: [RFC-to-be]
> > > > Values: See [RFC-to-be]
> > > >
> > > > IANA has a question about these registrations. There are four
> att-
> > >    field
> > > > registries: one for session level attributes, one for both
> session
> > >    and
> > > > media level attributes, one for media level attributes
> > only, one for
> > > > source level, and a final one for attributes for unknown levels.
> > >    Which
> > > > of these subregistries are these three attribute names to be
> added
> > >    to?
> > > >
> > > > After clarification, IANA understands that these are the only
> > >    actions
> > > > required upon approval of the document.
> > > >
> > > > Thanks,
> > > >
> > > > Amanda Baber
> > > > IANA
> > > >
> > > > On Fri Aug 27 15:50:26 2010, noreply@ietf.org wrote:
> > > > >
> > > > > The IESG has received a request from the FEC Framework WG
> > >    (fecframe) to
> > > > > consider the following document:
> > > > > - 'Session Description Protocol (SDP) Elements for FEC
> > Framework'
> > > > >   <draft-ietf-fecframe-sdp-elements-08.txt> as a
> > Proposed Standard
> > > > >
> > > > > The IESG plans to make a decision in the next few weeks, and
> > >    solicits
> > > > > final comments on this action. Please send substantive
> > comments to
> > >    the
> > > > > ietf@ietf.org mailing lists by 2010-09-10.
> > Exceptionally, comments
> > >    may be
> > > > > sent to iesg@ietf.org instead. In either case, please
> > retain the
> > > > > beginning of the Subject line to allow automated sorting.
> > > > >
> > > > > The file can be obtained via
> > > > >
> > https://datatracker.ietf.org/doc/draft-ietf-fecframe-sdp-elements/
> > > > >
> > > > > IESG discussion can be tracked via
> > > > >
> > https://datatracker.ietf.org/doc/draft-ietf-fecframe-sdp-elements/
> > > > >
> > > > >
> > > > > No IPR declarations were found that appear related to this
> I-D.
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
> >
> 
> _______________________________________________
> Fecframe mailing list
> Fecframe@ietf.org
> https://www.ietf.org/mailman/listinfo/fecframe