Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-rfc4566bis-32

[Paul Kyzivat <[e-mail]>]

Ben,

Based on your comments, I need to change the "Changes" section to 
mention the removal of private sessions, and remove the offending comma. 
I think that is all.

Given the freeze, what is the process to submit an update?

	Thanks,
	Paul

On 3/21/19 10:36 AM, Ben Campbell wrote:
> 
> 
>> On Mar 21, 2019, at 9:28 AM, Paul Kyzivat <[e-mail]> wrote:
>>
>> Ben,
>>
>> On 3/20/19 11:21 PM, Ben Campbell wrote:
>>
>> I've trimmed this to just the points that seem to call for a reply.
>>
>>>>> - Deleted text formerly in §4.3: The removal of the “private sessions” section in its entirety deserves some explanatory text.
>>>>
>>>> I posted a query about this. The consensus was that the removal here is right, but that more discussion is needed in the Security Considerations section. But I don't know what to write. I need some help on that
>>> Would it make sense to say that “private sessions” have been superseded by the use of things like DTLS-SRTP and RFC 8224
>>
>> The section on private sessions appears to have made sense in the distant past when the primary (or only) use of SDP was SAP. Then most sessions were public. Now almost all use of SDP is in establishing private sessions.
>>
>> I'm not convinced it is necessary to say anything about this, but I could reinstate a §4.3 on private sessions, with text saying what I just said above.
> 
> In that case, a mention in the “changes” section should be good enough. Would that fall under the “removed references to SAP” comment? It might be worth mentioning that this removal included private sessions.
>>
>>>>> §5.8: "Use of the "X-" prefix is NOT RECOMMENDED: instead new (non "X-"
>>>>> prefix) <bwtype> names SHOULD be defined, and then MUST be registered
>>>>> with IANA in the standard namespace.”
>>>>> “SHOULD be defined” seems to be in tension with “MUST be registered”.
>>>>
>>>> I twiddled with this. Does it work for you now?
>>> All I see in 33 is a punctuation change. Did I miss something?
>>
>> There is also a small change in the prior paragraph. I changed it to indicate that this is a legacy of 4566.
>>
>> Re SHOULD vs MUST: IIRC the intent was to leave a little wiggle room for X-, while saying that non-X- names MUST be registered.
>>
>> Can we agree on what we mean to say here? Then I can try to reword to say that more clearly.
>>
>> ISTM that we want to say that *new* uses of X- are forbidden while existing ones may continue. And non-X- names MUST be registered. (What about existing non-X- and unregistered names?)
>>
> 
> Okay, on re-reading, I think I am okay with it. I just wanted to make sure we were looking at the same text.
> 
>>>>> §7, last paragraph:
>>>>> What is the impact of this on RFC 4568 (security descriptions)? That RFC seems to allow the use of “k=“ lines at a MAY level. Does this draft need to update that? But more importantly, is it worth distinguishing the case of E@E protection of keying material vs the HBH protection offered by security descriptions?
>>>>
>>>> This text is unchanged since 4566.
>>>>
>>>> I need help with this from a security person
>>> I’m willing to accept this as legacy text. (But I guess we will see what the SEC ADs have to say.)
>>
>> OK. Then *they* can supply the text.
> 
> We can worry about that when it happens :-) (i.e. IESG evaluation)
> 
>>
>>>>> - "media-, or session-specific basis” : Incorrect comma usage.
>>>>
>>>> IIUC this is an "Oxford comma", and the use of it is controversial. Does IETF have a policy on its use?
>>>>
>>> <channeling-Adam>
>>> Well, yes. The RFC Editor follows the Chicago Manual of Style, which IIUC calls for use of the Oxford comma. However, this isn’t one. The Oxford comma is for a serial conjunction list, e.g. “a, b, and c”. This instance is just a normal conjunction, e.g. “a or b”. “a, or b” is generally incorrect unless there’s some other reason for the comma.
>>> </channeling-Adam>
>>
>> Oh duh! Agree. If I need to make more changes then I will include this one.
>>
>>>>> §5.9: "A "t=" line (time-field) initiates a time description that specifies
>>>>> the start and stop times for a session.”
>>>>> I don't understand what it means to "intitiate" a time description. The text from 4566 seemed more clear.
>>>>
>>>> I changed "initiate" to "begins".
>>>>
>>>> There has been a lot of confusion and questions raised bout how t=/r=/z= work together. I revised the ABNF to clarify that, and then reworked this text to be consistent with and coordinate with the ABNF.
>>> Okay. (Wow, that’s a lot of work for an editorial comment :-) )
>>
>> No. All the ABNF changes were done long ago. This time I simply changed "initiate" to "begins”.
> 
> Ah, okay.
> 
>>
>> 	Thanks,
>> 	Paul
> 
> 
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>