Subject: [MMUSIC] Next steps on 4765bis

From: Robert Sparks <[email-masked]>
Date: Wed, 28 Apr 2010 15:55:27 -0500

All -

One of the consistent points of feedback from the IESG evaluation of 
draft-ietf-mmusic-rfc4756bis was that the way we were attempting to
deal with backwards compatibility with 4756 was overly-confusing.
(See: <https://datatracker.ietf.org/doc/draft-ietf-mmusic-rfc4756bis/#ballot>)

I've asked Ali to revise the draft taking a more traditional obsoleting
approach (which will mean moving the information an implementer
needs to deal with a 4756 peer into this draft). When he submits that
update, please review it quickly and comment whether it meets the
goal. 

RjS

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Wed, 28 Apr 2010 14:00:43 -0700

Here is the new version (and its diff):

https://datatracker.ietf.org/doc/draft-ietf-mmusic-rfc4756bis/#history

thanks,
-acbegen

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Sparks
> Sent: Wednesday, April 28, 2010 4:55 PM
> To: [email-masked]
> Subject: [MMUSIC] Next steps on 4765bis
> 
> All -
> 
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: Jean-Francois Mule <[email-masked]>
Date: Fri, 30 Apr 2010 12:23:51 -0600

Hi Ali,

  Thanks for the update.

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

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

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.

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.

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"

   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.

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]
   Forward Error Correction FR  FEC-FR  RFC 4756bis [note to IANA: change with new RFC number]

Jean-Francois.

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Ali C. Begen (abegen)
> Sent: Wednesday, April 28, 2010 3:01 PM
> To: Robert Sparks; [email-masked]
> Subject: Re: [MMUSIC] Next steps on 4765bis
>