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)" <[e-mail]>]

Hi David,

> -----Original Message-----
> From: David Harrington [mailto:[e-mail]]
> Sent: Saturday, October 02, 2010 12:53 AM
> To: Ali C. Begen (abegen); [e-mail]; 'TSV Dir'
> Cc: [e-mail]; [e-mail]
> Subject: RE: [Fecframe] [IANA #394228] RE: LastCall:<draft-ietf-fecframe-sdp-elements-08.txt> (SessionDescriptionProtocol
> (SDP) Elements for FEC Framework) toProposed Standard
> 
> Hi Ali,
> 
> Thanks for responding.
> I probably should have questioned this more during AD Review. I did
> think it an odd design, but there was apparently WG consensus, so I
> didn't bother to raise my questions. My bad.
> 
> When you say "someone wants to use it as a source flow in the fec
> framework", this is not very clear.
> The fec framework is an abstract description of how things fit
> together.
> Within the fec framework, we have multiple fec schemes.
> Is each fec scheme designed to protect specific types of source flows?

Right, framework draft explains the framework itself. The FEC schemes may have individual requirements for the source (input) flows. In some source flows, sequence numbers will already exist to allow the receiver to identify them uniquely (like RTP). In other source flows (such as UDP), there won't be a seqnum which means something needs to be added at the end of the source packets (explicit source fec payload id). However, once we do that, we cannot describe those packets as regular UDP packets since it would be misleading. Instead, we use FEC/<proto> in the SDP. This way, a receiver that does not implement the framework will not be able to parse FEC/<proto> line and it will not try to use that flow.
 
> When you say "someone wants to use it as a source flow in the fec
> framework",
> is the someone the editor of a fec scheme specification?

Suppose your source flow is UDP. And you wanna apply FEC on it. So, you append the explicit source fec payload id. Now, in the SDP you should use "FEC/UDP." But I think you can only do it if it has been registered with IANA. It does not matter who does the registration. If an FEC scheme draft registers it, others can use it as well since "FEC/UDP" part is common (different FEC schemes will be identified based on their encoding IDs anyway).

So bottom line is, either the SDP draft registers it or an FEC scheme draft that plans to use UDP flows as source flows registers it. Once it is registered, other FEC schemes can use the same registration.

> is "it" a registered identifier?
> What exactly does the identifer identify?
> Does that identifier identify a specific fec scheme for a specific
> type of source flow?
> Would it make sense for a fec scheme specification document to
> register the specific relevant identifiers?

I hope my answer above answers all these questions. FEC schemes are identified by their encoding IDs not protocol identifiers.
 
> Please try to be very explicit in your response, so I can understand
> this better.
> It might help to avoid using pronouns like "someone", "it", and
> phrases like "the ones we care about"
> I care about all standard protocols ;-) Which ones do you care about?

Sure. Certain protocols will unlikely to be used with FEC (e.g., TCP). And for RTP and DCCP (which has its own seqnums), we don't need a new identifier. So, to me UDP is the #1 candidate :) So we can do the registration for UDP and leave the rest for future FEC scheme drafts.

-acbegen

PS tsv-dir emails seem to be bouncing since I am not a member, but keeping their address in the to list just in case the moderator allows these emails.
 
> David Harrington
> Director, IETF Transport Area
> [e-mail] (preferred for ietf)
> [e-mail]
> [phone] (cell)
> 
> > -----Original Message-----
> > From: Ali C. Begen (abegen) [mailto:[e-mail]]
> > Sent: Friday, October 01, 2010 11:48 PM
> > To: David Harrington; [e-mail]; TSV Dir
> > Cc: [e-mail]; [e-mail]
> > Subject: RE: [Fecframe] [IANA #394228] RE:
> > LastCall:<draft-ietf-fecframe-sdp-elements-08.txt>
> > (SessionDescriptionProtocol (SDP) Elements for FEC Framework)
> > toProposed Standard
> >
> > 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: [e-mail]
> > [mailto:[e-mail]] On
> > > Behalf Of David Harrington
> > > Sent: Friday, October 01, 2010 11:39 PM
> > > To: [e-mail]; 'TSV Dir'
> > > Cc: [e-mail]; [e-mail]
> > > 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
> > > [e-mail] (preferred for ietf)
> > > [e-mail]
> > > [phone] (cell)
> > >
> > > > -----Original Message-----
> > > > From: [e-mail]
> > [mailto:[e-mail]] On Behalf
> > > > Of Amanda Baber via RT
> > > > Sent: Friday, October 01, 2010 8:53 PM
> > > > Cc: [e-mail]; [e-mail];
> > [e-mail]
> > > > 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, [e-mail] 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:[e-mail]]
> > > > > > Sent: Friday, September 10, 2010 3:05 PM
> > > > > > Cc: Ali C. Begen (abegen); [e-mail];
> > > > >    [e-mail]
> > > > > > 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, [e-mail] 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
> > > > > > > [e-mail] mailing lists by 2010-09-10.
> > > > Exceptionally, comments
> > > > >    may be
> > > > > > > sent to [e-mail] 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
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/fecframe