Subject: Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-sdp-bundle-negotiation-47 - Ben's substantive comments

From: Christer Holmberg <[email-masked]>
Date: Sat, 20 Jan 2018 13:44:55 +0000

Hi Ben,

Thanks for your review! Please see inline.

(For convenience, I will address your editorial comments in a separate reply)

*** Substantive Comments ***

---

> - boilerplate: I assume the pre-2008 boilerplate is present due to the extensive quoted text from RFC 3264. 
> I note that it is not usually necessary to quote large amounts of text from an RFC in order to update it. I don’t 
> expect a change in the update approach this late in the process, but I suggest that for future drafts people try to 
> avoid creating the need for the pre-2008 boilerplate.

Ok. I won't do any changes at this point.

---

> - section 8, first paragraph after bullet list: I’m confused as to whether this talks about the initial offer or a subsequent 
> offer. the comment about the “previously negotiated SDP parameters” seems to suggest the latter. I suspect this is intended 
> to cover all offers, in which case it needs clarification.

It's the offer in which the BUNDLE group is created. I may be the initial offer of the session, or it may be a subsequent offer within the session. It's irrelevant as far as BUNDLE is concerned.

Also note that section 2 defines "initial offer" as the offer where the BUNDLE group is created:

   "Initial offer: The first offer, within an SDP session (e.g. a SIP
   dialog when the Session Initiation Protocol (SIP) [RFC3261] is used
   to carry SDP), in which the offerer indicates that it wants to create
   a given BUNDLE group."

But, if we want to make it clear also in Section 8, I could add the following note:

"NOTE: The offer in which the offerer indicates that it wants to create a BUNDLE group can be the initial offer of the session, or a subsequent offer within the session. As defined in section 2, within the scope of this document the initial offer always refers to the offer in which the offerer indicates that it wants to create a BUNDLE group, no matter whether that offer is the initial offer, or a subsequent offer, within the session."

---

> -8.3.3: IIUC, the criteria mean that the only m= sections that the answerer can move out of the bundle are those that 
> have unique addresses but are not listed first in the group attribute. If that is correct, a sentence or two to say that would be helpful.

As long as the m= section contains a unique address (and does not contain a bundle-only attribute) it can be moved out of a BUNDLE group, no matter where it is listed in the group attribute.

---

> -8.5, first paragraph. IIUC, it’s not syntactically possible to assign more than one m= section the bundle address, since only one 
> can be first in the group attribute. If that is correct, the MUST here is a statement of fact. Or am I missing something?

There can only be one first in the group attribute, but syntactically you could assign the bundle address value (IP address and port) to more than one m= section.

(At the end of the day, the tag is really only relevant in the initial offer, where you may assign multiple different unique addresses, and you want to indicate which one you want to use as bundle address. Once the bundle address has been negotiated, you won't assign any other addresses to an offer)

---

> -9: There are several assertions that in order to do something you MUST have a spec saying how to do it. Formally, 
> I think the requirement is really that you MUST NOT do that thing unless such a spec exists. (2119/8174 keywords are normally about implementation behavior.)

Is it ok if I keep that in mind for my next draft? :)

---

> -10.2,
> — paragraph 7: What implementations are we talking about that may not follow the requirements to include the tag in 
> RTP/RTCP? Early implementations of this draft? Something else? As it is, it seems like we are talking about implementations 
> that do not follow this spec. That makes the statement “  … In this situation, each "m=" section MUST use unique payload type 
> values…” problematic, as it seems to be putting requirements on implementations that do not follow this draft in the first place.

There were looooong discussions about this section, and I'll outsource the question to others. 

Cullen? Ekr?

> — '  Therefore, when processing a compound packet, any contained SDES packet MUST be handled first.
>      Note that this is a change from [RFC3550] Section 6.1 which
>      states that "Each individual RTCP packet in the compound packet
>      may be processed independently with no requirements upon the order
>      or combination of packets”.’
>
> Doesn’t this require an update of 3550? It’s not merely a tightening of requirements, it’s a reversal of guidance from that document when used in this context.

How would we update 3550? Adding a sentence saying ", unless a specific usage defines otherwise"?

In my opinion it is a tightening of requirements. But, if others think otherwise I don't have any strong feelings.

---

> -10.3.1.3, last paragraph: What is the expected behavior when that "protocol error" occurs?

I don't think we don't normally specify that in cases like this, because it's an implementation issue. An implementation may trigger a new O/A exchange, or may terminate the whole session, etc etc.

---

> -15.2, last paragraph: Is it worth recommending against patterns which could be used as persistent identifiers, even if 
> they don’t expressly identify a person or application?

What would they identity?

Just saying "..., or could be used as persistent identifiers" sounds a little half baked.

---

> -16.3: Please use the IESG and “[email-masked]” as the contact for the IANA registrations.

Will fix as suggested.

---

> -17, 2nd paragraph:
> — Again, is it worth mentioning the risk of persistent identifiers?

See above.

>—  “… SHOULD be 3 bytes or less, to allow them to efficiently fit into the MID RTP header extension.”
> It seems like that requirement belongs in 15.2

Section 15.2 does say that the length shall be 1-3 bytes. 

---

> -17, last paragraph: Doesn’t that require an update to 7941

If I remember correctly, there were long discussions about this, and it is one of the the-RFC-is-correct-but-not-everyone-implement-that-requirement things...

Cullen? Ekr?

---

> -18: Would it make sense to have one of the examples use media-level c= lines?

I can add an example.

---

Regards,

Christer

---

From: Ben Campbell <[email-masked]>
Date: Thu, 25 Jan 2018 16:57:44 -0600

> On Jan 20, 2018, at 7:44 AM, Christer Holmberg <[email-masked]> wrote:
> 
> Hi Ben,
> 

[…]

> It's the offer in which the BUNDLE group is created. I may be the initial offer of the session, or it may be a subsequent offer within the session. It's irrelevant as far as BUNDLE is concerned.

I assumed that to be the case, but I found the mention of previously negotiated parameters without some clarification that there might not be any to be confusing.

> "NOTE: The offer in which the offerer indicates that it wants to create a BUNDLE group can be the initial offer of the session, or a subsequent offer within the session. As defined in section 2, within the scope of this document the initial offer always refers to the offer in which the offerer indicates that it wants to create a BUNDLE group, no matter whether that offer is the initial offer, or a subsequent offer, within the session.”

I think that would help.

> As long as the m= section contains a unique address (and does not contain a bundle-only attribute) it can be moved out of a BUNDLE group, no matter where it is listed in the group attribute.

Then what does this text from the first bullet under 8.3.3 mean, as part of the criteria for things that _can’t_ be moved out of the group?

“ o  In the corresponding offer, an offerer BUNDLE address (previously
      selected [Section 8.3.1] or new suggested [Section 8.5.1]) has
      been assigned to the "m=" section by the offerer;"

> There can only be one first in the group attribute, but syntactically you could assign the bundle address value (IP address and port) to more than one m= section.

Ah, okay.

> Is it ok if I keep that in mind for my next draft? :)

Okay :-)

> There were looooong discussions about this section, and I'll outsource the question to others.

I think Magnus’s response to this made sense. OTOH, if messing with this text might undo a difficult consensus process, I could be convinced to leave it alone.

> In my opinion it is a tightening of requirements. But, if others think otherwise I don't have any strong feelings.

I think Magnus’s comments here made sense.

> I don't think we don't normally specify that in cases like this, because it's an implementation issue. An implementation may trigger a new O/A exchange, or may terminate the whole session, etc etc.

Those are recovery actions. Would it reasonable for the offerer to pretend the answerer had really meant to accept rtp/rtcp multiplexing? Or must the offerer give up on _this_ offer/answer exchange?

---
> Just saying "..., or could be used as persistent identifiers" sounds a little half baked.

As an example, assume that even though the implementation puts no user-identifying information in the tag, it puts some piece of information in there that is always the same for a given user. If someone manages to correlate that piece to other activity that _does_ identify the user, the piece becomes user-identifying.

[…]

>> — Again, is it worth mentioning the risk of persistent identifiers?

Ditto :-)

> Section 15.2 does say that the length shall be 1-3 bytes.

Okay, I missed it there.

> If I remember correctly, there were long discussions about this, and it is one of the the-RFC-is-correct-but-not-everyone-implement-that-requirement things...

See Magnus’s comments and my response.

[…]

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 26 Jan 2018 11:16:45 +0000

Hi Ben,

Please see inline.

(I¹ll address the comments where Magnus has provided input in the
dedicated thread)

...

>> 
>>> -8.3.3: IIUC, the criteria mean that the only m= sections that the
>>>answerer can move out of the bundle are those that
>>> have unique addresses but are not listed first in the group attribute.
>>>If that is correct, a sentence or two to say that would be helpful.
>> 
>> As long as the m= section contains a unique address (and does not
>>contain a bundle-only attribute) it can be moved out of a BUNDLE group,
>>no matter where it is listed in the group attribute.
>
>Then what does this text from the first bullet under 8.3.3 mean, as part
>of the criteria for things that _can¹t_ be moved out of the group?
>
>³ o  In the corresponding offer, an offerer BUNDLE address (previously

Ok, I see what you mean.

My statement regarding unique address was incorrect.

The important part is ³new suggested² - when a BUNDLE address have
previously been negotiated. Because, compared to the initial offer, when a
NEW BUNDLE address is suggested, it is only assigned to ONE m= line. A
zero port value is assigned to all other m= sections, so because of that
the m= section with the new suggested address cannot be moved out of the
BUNDLE group.

---

>> I don't think we don't normally specify that in cases like this,
>>because it's an implementation issue. An implementation may trigger a
>>new O/A exchange, or may terminate the whole session, etc etc.
>
>Those are recovery actions. Would it reasonable for the offerer to
>pretend the answerer had really meant to accept rtp/rtcp multiplexing? Or
>must the offerer give up on _this_ offer/answer exchange?

I guess we could allow both alternatives.

What about:

"NOTE: It is considered a protocol error if the answerer has not
   accepted the usage of RTP/RTCP multiplexing for RTP-based "m="
   sections that the answerer included in the BUNDLE group. As usage of
RTP/RTCP multiplexing is required within a BUNDLE group, the offerer
can either accept the answer and assume that RTP/RTCP multiplexing
Will be used, or reject the answer and perform proper error handling
actions (e.g., send a new offer, or terminate the whole session)."

---

>> 
>>> -15.2, last paragraph: Is it worth recommending against patterns which
>>>could be used as persistent identifiers, even if
>>> they don¹t expressly identify a person or application?
>> 
>As an example, assume that even though the implementation puts no
>user-identifying information in the tag, it puts some piece of
>information in there that is always the same for a given user. If someone
>manages to correlate that piece to other activity that _does_ identify
>the user, the piece becomes user-identifying.
>
>[Š]

Isn¹t that covered by ³pattern²?

I could add say:

"The identification-tag MUST NOT contain any user information, and
applications SHALL avoid generating
   the identification-tag using a pattern that enables <new>user- or</new>
application identification.²

>> ---
>> 
>>> -17, 2nd paragraph:
>>> ‹ Again, is it worth mentioning the risk of persistent identifiers?
>> 
>> See above.
>
>Ditto :-)

---

Regards,

Christer

---

From: Ben Campbell <[email-masked]>
Date: Mon, 29 Jan 2018 15:33:15 -0600

> On Jan 26, 2018, at 5:16 AM, Christer Holmberg <[email-masked]> wrote:
> 
> Hi Ben,
> 
> Please see inline.
> 

Does that mean “new suggested” does not include “initial suggested”?

> actions (e.g., send a new offer, or terminate the whole session).”
> 
Hrm. I actually intended the bit about assuming the answerer meant something different from what they said to test the bounderies of reasonableness. I’m a bit hesitant to actually suggest doing that :-)

> Isn¹t that covered by ³pattern²?

The term “pattern” was used with “application identification”. I guess my point is that a pattern may become _user_ identifying, even if the tag never includes any data that directly identifies the user.  I think we all know that is true, but a naive implementer may not. But see next comment...

> application identification.²

That WFM.

[…]

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 30 Jan 2018 12:30:31 +0000

Hi,

>Does that mean “new suggested” does not include “initial suggested”?

Correct.

---

>Hrm. I actually intended the bit about assuming the answerer meant
>something different from what they said to test the bounderies of
>reasonableness. I’m a bit hesitant to actually suggest doing that :-)

Not sure I follow :)

---

>The term “pattern” was used with “application identification”. I guess my
>point is that a pattern may become _user_ identifying, even if the tag
>never includes any data that directly identifies the user.  I think we
>all know that is true, but a naive implementer may not. But see next
>comment...
>
>> 
>> I could add say:
>> 

Great! :)

Regards,

Christer

---

From: Ben Campbell <[email-masked]>
Date: Tue, 30 Jan 2018 11:20:07 -0600

> On Jan 30, 2018, at 6:30 AM, Christer Holmberg <[email-masked]> wrote:
> 
>>>>>> 

That is, I didn’t mean to suggest that assuming the answerer will still do rtp/rtcp mux is a good idea, or that the text should suggest it. I was wondering if we should offer guidance _against_ that sort of thing.

I think at this point you have convinced me there is no useful guidance to give, so I’m okay with the original text.

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 31 Jan 2018 08:11:43 +0000

Hi,

>>>>> pretend the answerer had really meant to accept rtp/rtcp
>>>>>multiplexing?
>>>>> Or
>>>> actions (e.g., send a new offer, or terminate the whole session).²
>>>> 
>>> reasonableness. I¹m a bit hesitant to actually suggest doing that :-)
>> 
>> Not sure I follow :)
>
>That is, I didn¹t mean to suggest that assuming the answerer will still
>do rtp/rtcp mux is a good idea, or that the text should suggest it. I was
>wondering if we should offer guidance _against_ that sort of thing.
>
>I think at this point you have convinced me there is no useful guidance
>to give, so I¹m okay with the original text.

Thanks! :)

Regards,

Christer