Subject: Re: [Fecframe] [MMUSIC] draft-ietf-mmusic-rfc4756bis (was Re: AD Review:draft-ietf-mmusic-rfc4765bis-05)

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Thu, 28 Jan 2010 12:55:55 -0800

> Section 4.4 of this document says they SHOULD try to make the FEC
semantics
> work when a FEC-XR offer fails. This document does not say what the
FEC
> semantics are. Where in the new document do you tell an implementer
what
>        a=group:FEC 1 2
>        a=group:FEC 3 4
> means?

OK, right. "FEC" semantics are not defined in the new draft. If a new
implementation wants to be able to speak to 4756 endpoints, it will need
4756. Then I guess you are disagreeing that we are obsoleting 4756.

Well, I am not sure what is the right term here. At that time, I was
told "obsoleting" was the right choice. To me, RFC 4756 will still be
available for anybody who wants to be backward compatible anyway. So, I
did not think it would be a problem. But, if you say it is a problem, I
can't argue with that.

...
> 	I believe it is clear since we are obsoleting 4756. An obsoleted
spec
> 	should not be implemented anyway.
> 
> 
> 
> Obsolete in the header refers to the document, not the technology
> in the document. It means the normative behavior that used to be
> defined by this document is now defined somewhere else. That
> somewhere else has to be very explicit about what's changed.
> If the intent is to deprecate an old behavior, you need to say that.
> It is not explicit in this document that you don't want new things
> sending offers with group:FEC without them having tried group:FEC-XR
> first.

We can remove the part saying that new implementations will need to try
FEC semantics before giving up (if the FEC semantics still give them
what they want). This is the part that still requires reading RFC 4756.
If an implementation does not desire to be backward compatible (meaning
it only speaks FEC-XR language), then it does not need 4756.

...
> I don't feel strongly about changing the name, especially if there are
> implementations (how many are there by the way?).

I don't think there are many as this stuff is mostly needed by the FEC
framework which is still in the wg last call process. 

Any objections to FEC-FR? (CC'ing fecframe as well)
 
...
> 
> Looking back through the document, I spotted a minor note I made but
failed
> to transcribe earlier.
> 
> In section 4.4's third paragraph, there is a SHOULD that is
impossible.
> As written, you are placing a requirement on implementations that do
> not implement this spec. I think you are trying to say that
implementations

I see your point. However, is not this what they are supposed to do
anyway based on 3388bis or SDP specs? If one does not understand the
grouping semantics or line grouping, they answer by ignoring the
grouping attribute (or with a refusal to the request). 

> following the already published specifications will behave in one of
the
> two following ways and then providing normative behavior for how the
> offerer will react to either of those two cases.

Yes, this was the intent. And this kind of language is mostly based on
4756. I can remove "SHOULD" or refer to 3388bis to indicate that it is
not this draft who is making the rules for the answerers. 

-acbegen