Subject: [MMUSIC] AD Review: draft-ietf-mmusic-rfc4765bis-05

From: Robert Sparks <[email-masked]>
Date: Thu, 28 Jan 2010 12:46:52 -0600

I've reviewed this document in preparation for IETF LC.
The document is close to ready to go, but I have one
significant concern to discuss and some small changes
to suggest.

The big issue: This document is attempting to Obsolete 4765, but
an implementer that wanted to build new code following this
draft that wanted to interoperate with a legacy 4765
implementation would still have to read RFC 4765. With the level
of detail in this version of the draft, 4765 would really need
to be a normative reference. Instead, I think you need to copy
the normative behavior from 4765 forward into this draft.
It should also be crystal clear whether or not the intent is to
discourage new implementations of 4765.

The smaller suggestions:
*) The use of 2119 words (like MUST) in the examples is probably
    not what you want. I suggest editing them out of section 4.2.
    The only one that might really be capturing a requirement
    is the last one in the section. If that is a new requirement,
    it should probably be somewhere besides the examples.

*) It would be good to document why the string "FEC-XR" was
    was chosen. Without that, I expect there to be confusion,
    at least at the reviewer level, with how this relates to
    RTCP-XR.

I'm going to put the document into "Revised I-D needed" since
I'd like a refresh to at least update the boilerplate before
this goes to IETF LC. But please wait for the conclusion of the
conversation around my big concern above before updating the
document.

RjS
.

---

From: Robert Sparks <[email-masked]>
Date: Thu, 28 Jan 2010 12:53:20 -0600

Typo'd the filename in the subject line - this message is just to get  
the right name on
the subject o make this easier to find when searching the archives  
later.

---

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

Hi Robert,

Thanks for the review.

> > implementation would still have to read RFC 4765. With the level

*If* they want to be 4756-compatible. I brought up this issue a few
times during the course of this draft and the consensus was to obsolete
4756 but list what issues the new implementations would face when they
received 4756-based SDPs/offers/answers.

> > the normative behavior from 4765 forward into this draft.

I am not sure what this means. The new spec includes everything 4756 did
and much more.

> > discourage new implementations of 4765.

I believe it is clear since we are obsoleting 4756. An obsoleted spec
should not be implemented anyway.

> >   it should probably be somewhere besides the examples.

I'll look into this again.

> >   at least at the reviewer level, with how this relates to

There is no particular reason. We had to choose something. If need be, I
can say that it is not related to RTCP-XR at all. But, if you think
there is a risk of misunderstanding and looks like there is, we should
change it rather than writing an explanation for it.

Please suggest one. Or, I will choose something "FEC-FR," short name for
the "framework" maybe.

> > conversation around my big concern above before updating the

I am ready to revise the draft when we agree on that issue.

Cheers, acbegen.

> >
> > RjS
> > .
> 
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: Robert Sparks <[email-masked]>
Date: Thu, 28 Jan 2010 14:18:27 -0600

inline

(and something new at the end, with my apologies for not getting it  
into the first message)

> received 4756-based SDPs/offers/answers.

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?

> I am not sure what this means. The new spec includes everything 4756  

Does my question above better help you see my concern?

> 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.

> Please suggest one. Or, I will choose something "FEC-FR," short name  

I don't feel strongly about changing the name, especially if there are
implementations (how many are there by the way?).
> I am ready to revise the draft when we agree on that issue.

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
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.

---

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

semantics
> semantics are. Where in the new document do you tell an implementer
what

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.

...
> sending offers with group:FEC without them having tried group:FEC-XR

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.

...
> 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)
 
...
failed
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). 

> 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

---

From: "Kevin P. Fleming" <[email-masked]>
Date: Thu, 28 Jan 2010 17:29:14 -0600

> did not think it would be a problem. But, if you say it is a problem, I

The correct word, in English at least, is 'deprecated'. The previous
version is still valid, but is not recommended for new implementations.

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
skype: kpfleming | jabber: [email-masked]
Check us out at www.digium.com & www.asterisk.org