Subject: Re: [payload] [MMUSIC] Comments to draft-ietf-mmusic-media-loopback-16

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 22 Nov 2011 08:25:37 +0000

Howdy,
Miguel sent back a list of comments against media-loopback for the WGLC.
I plan to propose changes to address some of his points in separate emails, for the technical comments.

The following points copied below I consider editorial in nature and wish to resolve directly as the editor. 

Does anyone object to this course of action?

On Oct 16, 2011, at 4:42 PM, Miguel A. Garcia wrote:

> - Terminology. I don't find any justification for this draft to depend on RFC 3261 and for making references to SIP INVITEs and alike. Instead, the draft should be based on the SDP offer/answer model (RFC 3264). As part of this, I will add a paragraph in Section 2 saying that ... "The following terms are borrowed from RFC 3264: offer, offerer, answer, answerer". I will rename section 3 to "SDP offerer behavior", Section 4 to "SDP answerer behavior". An in general, I will not talk of the "offering entity" (section 3), but the "offerer", or the "answering entity" (section 4), but the "answerer".
> 
> - I will add a new paragraph at the end of Section 3 indicating where the "loopback" attribute is defined.
> 
> - Section 4, the last paragraph is not correct, because it puts a normative requirement (MAY) for answerers that are not compliant with this specification. So, if an answerer is not compliant with this specification, how can it comply with the normative MAY?
> 
> I suggest to replace the "MAY" with "is expected".
> 
> - I would rename Section 5 to "New SDP attributes"
> 
> - I would start Section 5.1 with a sentence that says: "This specification defines a new 'loopback' attribute which indicates the type of loopback that the entity is able to do".
> 
...
> - The last two paragraphs in Section 5.1 describe the packet loopback and the media loopback. However, in Section 1.1, there are three modes defined. I would like to have a matching between the two values and the three modes. For example, you could add a sentence indicating in each of these two values "this value is used when the loopback is of type xxx (see Section 1.X)."
> 
> 
...
> - Section 5.3, after the example. There is a note that contains a normative statement (MUST NOT). In principle, notes should be informative by nature, so just remove the word "Note:" from the beginning of the paragraph.
> 
> - Section 5.3, the paragraph after the Note refers to the "m= line" when the draft says "The port number and the address in the offer (m= line)..." However, the address in SDP goes in the c= line, therefore, whenever you refer to port number and address, you should refer to the "m/c= lines".
> 
> 
...
> - Examples at the end of Section 5.3 It would be nice to elaborate these examples, describing what they are showing. Also, at this point in the draft, the "encaprtp" and "rtploopback" tokens have not been introduced, so it would be nice to point to the sections where it will later be defined.
> 
> - Section 5.4, first paragraph, first sentence, replace "a loopback answer" with "an SDP answer". Later in this same paragraph replace "offerere" with "offerer".
> 
> - There is some missing words in the second sentence of the first paragraph in Section 5.4. The sentence is incomplete.
> 
> - Section 5.4, second paragraph, write "attributes" in plural in the first sentence.
> 
> - Section 5.5, first and second sentences, read:
> 
>    The answer to a loopback-source MUST be loopback-mirror.  The
>    answer to a loopback-mirror MUST be loopback-source.
> 
> First, the sentences should be expressed in terms of "SDP offer" and "SDP answer" "containing a loopback-source" or "loopback-mirror". For example:
> 
>    An offer containing a "loopback-source" attribute must be answered with an SDP answer containing a "loopback-mirror attribute in the same media description. An offer containing...
> 
> But, having said that... I wonder whether the above sentence makes sense in this section. This section is titled "Offerer processing of the answer". Therefore, I expect to find there what the offerer should do when it receives an SDP answer, not what the answerer should do to process the offer and generate the answer. So, move these two sentences to the Section 5.4.
> 
> - The third and fourth sentences in Section 5.5 read:
> 
>    The
>    loopback-mode line MUST contain at least one codec the answerer is
>    willing to send or receive depending on whether it is the loopback-
>    source or the loopback-mirror.  In addition, the "m=" line MUST
>    contain at least one codec that the answerer is willing to send or
>    receive depending on whether it is the loopback-mirror or the
>    loopback-source.
> 
> Well, it seems that these sentencse also describe how the answerer generates the answer, so it should be moved to Section 5.4.
> 
> - Second paragraph in Section 5.5. Replace "target UA" with "answerer". But most important, this paragraph needs to say what happens if the offer receives an answer that does not include the loopback-mirror/loopback-source attribute. I believe it should say that a session is still established, but loopback packets are not expected. It is up to the offerer to close down the session by regular means (high level protocol such as a SIP BYE or sending a new offer with the port number set to zero).
> 
> - Section 5.6, I wonder way the "may" in the first sentence is not a MAY.
> 
> - Section 5.6, replace the reference to SIP. You just need the reference to Section 8 of RFC 3264.
> 
...
> - Section 10. All the examples, replace "client", "server" and "INVITE request", and "response" with:
> 
> An [offerer|answerer] sends an SDP [offer|answer] which looks like:
> 
> - Section 10. In all the examples, replace "s=Example" with "s=" (source, RFC 3264). And you can omit the i= and e= lines as well, they do not really add anything, nor they are mandated.
> 
> - Section 10.3. Re-title this section to "SDP answer rejecting loopback media".
> 
> - The note at the end of Section 10.3 reads:
> 
>    NOTE: Loopback request may be rejected by either not including the
>    loopback mode attribute (for backward compatibility) or setting the
>    media port number to zero, or both, in the response.
> 
> First, I don't like this note here, because it may induce to double specification, specially since you have Section 5.4 that describes how to reject a loopback request.
> 
> And actually, here you have double incongruent specification. Section 5.4.1 only offers one mechanism for rejecting a session: setting the port to zero like in regular SDP. Nothing is written about rejecting a session by not including the loopback mode attribute.
> 
> Not including a loopback mode attribute in the answer is not a rejection, it is merely a session with no support for the loopback feature, but the session is established.
> 
> I recommend to delete this note.
> 
> - Section 11. I disagree with the dependency on RFC 3261. Please remove. Also, I am surprised of not seen any dependency of the security considerations of RTP/RTCP.
> 

-hadriel