Subject: Re: [MMUSIC] Next steps on 4765bis - issue with obsoleting "FEC" yet saying it is ok to use it beyond backward comp.

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Sun, 2 May 2010 19:50:12 -0700

Hi JF,

>   I started reviewing the diff between draft-07 and draft-08 but did not finish so I may send more on
> Monday 5/3.

Sure.
 
> 0) nits
> - Use of "old" in Old "FEC" Grouping semantics - you may want to use Deprecated or Obsoleted in the
> title of section 4.1

"Obsoleted" sounds good.
  
> 1) Deprecating or not deprecating a=group:FEC?
> The new text is ambivalent.  It seems to me that your section 4.1 says it is ok to still use/implement
> the "old" FEC grouping... when you say
> 	" the "FEC" semantics can be safely used. "
> 	=> to me, that means they are not deprecated and are still quite valid to use in certain cases.
> This was ok when you were "updating" 4756 but now, it seems awkward.

The goal is to obsolete 4756, but also keep a definition of the old semantics in the bis document so that implementations willing to stay backward compatible can infer what to do solely from the bis document.
 
> Proposal:
>   Could this draft make it clearer in its obsolescence of RFC4756 by:
> 	- first, defining "FEC-XR" and recommending it be used
> 		-> I'd move up section 4.2 and 4.4
> 	- second, re-defining "FEC" semantics formally (if you maintain the point of 4.1)
> 		-> Use of "FEC" grouping and applicability statement
> 		  This section would basically say that implementations MAY/SHOULD implement "FEC" for
> backward compatibility and also when they are ok with using a single line.

Do you prefer the obsoleted semantics to be mentioned after the new semantics (just before the back com. cons. section)?
 
> Continuing on this point, section 3.1 paragraph 3 on page 6 now says:
> " This document introduces the changes required in the FEC grouping
>    semantics and obsoletes [RFC4756].  New implementations SHOULD use
>    the new semantics introduced in Section 4.2 and Section 4.4 of this
>    document whenever possible, but they may need to use the obsoleted
>    semantics given in Section 4.1 when backward compatibility is
>    desired, as described in Section 4.5."
> 
>   I think this text also lacks clarity, I don't fully get this new text actually.
> To me, *new* implementations MUST use the new semantics - let's ensure all *new* implementations
> actually comply with the new RFC. So you may want to say something like this:
> "In addition to complying with the requirements defined in sections 4.2 and 4.4, new implementations
> MAY/SHOULD also support the "FEC" semantics as specified in <a_section_of_your_rfc5756bis_draft>.
> 	- it makes it clearer what new implementations must do
> 	- it also gives a pointer to a section in the new RFC for the "FEC" semantics (a=group:FEC) and
> that section gives the conditions of applicability for using "FEC"

If we say new implementation MUST use FEC-FR semantics, then saying they MAY also use FEC semantics sounds a bit contradictory. Don’t you think? Maybe, we should connect two sentences by saying "they MUST use FEC-FR except when (or unless) backward comp. is needed..."

> 
>    This proposal is re-enforced by your section 4.5 where you define how new implementations should
> deal with just "FEC" being proposed in o/a.

Actually, the current text in 4.5 implies that the offerer MUST support FEC semantics. In other words, we are mandating the support for FEC semantics, at least for the offerer. To be consistent with the rest of the draft, I suggest we change those MUSTs to SHOULDs or MAYs. 

I.e.:
      In this case, the original sender of the offer SHOULD first check
      whether using the "FEC" grouping semantics from Section 4.1 will
      create any ambiguity or not, ...

> 
> 2) IANA consideration
> Again, if it is ok to sometimes just use "FEC" then shouldn't the IANA section say something like this
> now:
> 
>    The following semantics have been registered by IANA in Semantics for
>    the "group" SDP Attribute under SDP Parameters.
> 
>    Semantics                    Token   Reference
>    ------------------------     -----   ----------
>    Forward Error Correction     FEC     RFC 4756bis [note to IANA: change with new RFC number]

Obsoleting 4756 would not remove the "FEC" semantics from the IANA registry, right? But, I suppose what you propose is a registry update.

>    Forward Error Correction FR  FEC-FR  RFC 4756bis [note to IANA: change with new RFC number]

No need for a note here.

Thanks,
-acbegen

> Jean-Francois.

---

From: Jean-Francois Mule <[email-masked]>
Date: Mon, 3 May 2010 10:40:30 -0600

Hi,

  The IESG or AD recommendations to now obsolete 4756 (instead of just updating it) does imply a few differences in the text.
The document should be updated as if 4756bis is the only document of reference for FEC Grouping in SDP, the one that defines FEC grouping semantics fully (not just the delta you added to meet the 2 new requirements and SSRC-level grouping but all of it).

A) Write 4756bis as the document of reference for FEC grouping in SDP
For example, the text in the abstract would merit some editing (and the pointer to 3388bis you had in the original 4756). 
Consider this proposed text for the new abstract:
"   This document defines the semantics for grouping the associated source and Forward Error Correction (FEC)-based repair flows in the Session Description Protocol (SDP).
   The semantics defined in this document are to be used with "Grouping of Media Lines in the Session Description Protocol" (RFC 3388bis) to group together "m" lines in the same session.
   This document revises the semantics defined in RFC 4756 first to allow one or more source and/or repair flow in the same group, and second, to support describing additive repair flows.  Synchronization Source (SSRC)-level grouping semantics are also introduced in this document for Real-time Transport Protocol (RTP) streams using SSRC multiplexing.
"

B) Is a=group:FEC deprecated or not?

You anwered: 
> The goal is to obsolete 4756, but also keep a definition of the old
> semantics in the bis document so that implementations willing to
> stay backward compatible can infer what to do solely from the bis
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  The current draft says more than this which is what I'm trying to get out of this discuss.
> document.

It says that it is also ok to just use "a=group:FEC". 
So, my question is to clarify what compliant implementations with RFC 4765bis MUST do.
Namely, as an implementer of RFC4756bis, what do I have to do?
   a) I MUST implement FEC-FR and use it no matter what.  I MAY implement the deprecated "FEC" for backward compatibility but its use in the offer is discouraged for new implementations.
   b) I MUST implement FEC-FR and SHOULD use it to send SDP with FEC grouping offers. I SHOULD implement the deprecated "FEC" grouping so that I can deal with backward compatibility
   c) I MUST implement both (and be capable of dealing with both as an answerer).  But it is also ok for me to just use "FEC" in my implementation when offering SDP because my implementation only has one source/repair flow in the same group

The current text is ambivalent.
	With RFC 4756bis as an "update" to RFC 4756, I thought we were going the c) route
	With RFC 4756 "obsoleted" by RFC 4756bis, your text still points to c) based on section 4.5 

Which one is it that you advocate?
I think we want b)	

If it is option b), then I would recommend the following:
	- obsolete the document RFC 4756
	- deprecate the previous "a=group:FEC" and make it clear that "a=group:FEC-FR" SHOULD be used in offers.
In this case, you do have a pure "backward compatibility section" that summarizes the requirements new implementations should meet to be able to cope with "a=group:FEC".
  	- update the IANA registry to clearly mark a=group:FEC as deprecated by RFC4765bis.
Forward Error Correction     FEC (Deprecated)   RFC 4756bis [note to IANA: change with new RFC number]

      -> an example of this can be found here:
 http://tools.ietf.org/html/rfc5568 page 46 (HI, and HAck were deprecated from 5268 and if you look at the IANA registry, it is indicated clearly http://www.iana.org/assignments/mobility-parameters/mobility-parameters.xml ).

If it is still option c), then you keep "a=group:FEC" as valid and add "a=group:FEC-XR" to cover the specific cases you outline in the bis update and to overcome the previous limitations of 4765.

I wrote:
> Do you prefer the obsoleted semantics to be mentioned after the new
> semantics (just before the back com. cons. section)?

Yes.

> > "In addition to complying with the requirements defined in
> sections 4.2 and 4.4, new implementations
> If we say new implementation MUST use FEC-FR semantics, then saying
> they MAY also use FEC semantics sounds a bit contradictory. Don't
> you think? Maybe, we should connect two sentences by saying "they
> MUST use FEC-FR except when (or unless) backward comp. is
> needed..."

I don't think it is contradictory if you decouple the offer/answer roles. Your section 4.5 implies that an offerer that has proposed FEC-FR but receives an answer ignoring it MUST send a new offer with just "FEC".  Let's face it: if this is what you want, both FEC-FR and FEC MUST be implemented and supported.
 Hope the text above on the a) b) c) options helps how I view this.
What I think is important to define is whether new implementations that do not need the support for more than one source/repair flow per grouping can just use FEC as before, or whether they must now use FEC-FR.  I think it is the latter.

> Actually, the current text in 4.5 implies that the offerer MUST
> support FEC semantics. In other words, we are mandating the support
> for FEC semantics, at least for the offerer.
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
And that is why I think you are shooting for option c): both a=group:FEC and a:group=FEC-FR MUST be implemented and supported.

> To be consistent with
> the rest of the draft, I suggest we change those MUSTs to SHOULDs
> or MAYs.
No, please don't.  In many cases, it makes things more ambiguous.

> I.e.:
>       In this case, the original sender of the offer SHOULD first
                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ = offerer

> check

So that we all realize what you are asking new implementers to do:
	- use a=group:FEC-FR
	- if answer ignores the grouping attribute, then
		+ if FEC can be used without ambiguity, then use a=group:FEC
		  Otherwise send new offer without a=group:* 

> Obsoleting 4756 would not remove the "FEC" semantics from the IANA
> registry, right? But, I suppose what you propose is a registry
   ^^^^^^^^^^^^^^^
No, not based on your current text and your section 4.5.
I think it would update the registry to make "FEC" point to the new RFC and there should be a paragraph to clearly say when it is ok to still use FEC in an offer.

> update.

> IANA: change with new RFC number]
As long as IANA understands they need to update the registry with RFC4765bis, I'm fine.

Jean-Francois.