Subject: [MMUSIC] Mirja Kühlewind's No Objection on draft-ietf-mmusic-sdp-mux-attributes-14: (with COMMENT)

From: "Mirja Kuehlewind" <[email-masked]>
Date: Tue, 25 Oct 2016 10:17:56 -0700

Mirja Kühlewind has entered the following ballot position for
draft-ietf-mmusic-sdp-mux-attributes-14: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-mux-attributes/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Two comments:

1) The category TDB is not fully clear to me. It says: "The attributes in
the TBD category have not been analyzed", but why? Can you further
explain?

2) Is the new registry for the Mux Category really needed? Is it expected
to (much) more categories in future?

---

From: Suhas Nandakumar <[email-masked]>
Date: Tue, 25 Oct 2016 10:30:37 -0700

Hello Mirja ,

Thanks for the review. Please see inline for the response.

> https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-mux-attributes/

[Suhas]: The category TBD serves 2 purposes.

Purpose 1: The WG decided to stop draft updates with new attribute analysis
towards the end of 2015 when it was decided to take the draft to the last
call. This was done so to keep the draft edits under control and not to
keep in a edit-loop forever when new SDP attributes popped up. All those
attributes that were added since then will get the category TBD in the IANA
registry and the individual drafts that define those attributes take on the
role of deciding the MUX category and the corresponding IANA updates.
An excerpt from Section 15.2 along the same lines below:
"

For the entries in the existing subregistries, under the "Session
   Description Protocol (SDP) Parameters" registry, that lack a value
   for the "Mux Category" in this specification will get a value of
   "TBD"

"

Purpose 2: There are few attributes in the current analysis of the draft
that are assigned the category TBD. A specific example is Section 5.54 (ITU
T.38). I have included the note below to explain in the section the reasons
why the WG decided the category as TBD.
"

NOTE: As per section 9.1 of [I-D.ietf-mmusic-sdp-bundle-negotiation],
   there exists no publicly available specification that defines
   procedures for multiplexing/demultiplexing fax protocols flows over a
   single 5-tuple.  Once such a specification is available, the
   multiplexing category assignments for the attributes in this section
   could be revisited.

"
Since we don't have a standard specification to define the mux/demux of Fax
protocols with RTP, the only category that made sense was TBD. This state
can be updated once such a spec is defined in the future. Similar reasoning
applies to other TBD attributes.

Please let me know if the above answers your concerns.

> to (much) more categories in future?

[Suhas] -  We need the registry to list the currently defined Mux
Categories and also we do see there might be couple of more categories (if
not many) that might get defined in the future.

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

---

From: Mirja Kühlewind <[email-masked]>
Date: Thu, 27 Oct 2016 17:56:24 +0200

Hi Suhas,

see below.

On 25.10.2016 19:30, Suhas Nandakumar wrote:
> On Tue, Oct 25, 2016 at 10:17 AM, Mirja Kuehlewind <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     <https://www.ietf.org/iesg/statement/discuss-criteria.html>
>     <https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-mux-attributes/>
>
>
>
> call. This was done so to keep the draft edits under control and not to keep
> in a edit-loop forever when new SDP attributes popped up. All those

I'm not sure I fully get this. There are other doc that will define a 
different value which are not finished yet but the parameter is already 
registered in the registry.

I guess I just would leave those open in this doc (not saying anything about 
them) and not define an own temporal category for those.

Probably you can just have a note in the iana section saying that for these 
parameter the category will be defined by other doc and should be left open 
for now.

>
>
> Purpose 2: There are few attributes in the current analysis of the draft that
> are assigned the category TBD. A specific example is Section 5.54 (ITU T.38).
> I have included the note below to explain in the section the reasons why the
> WG decided the category as TBD.
> "
>
> protocols with RTP, the only category that made sense was TBD. This state can
> be updated once such a spec is defined in the future. Similar reasoning

Still not sure if a TBD category makes sense but don't have a strong opinion, 
so please do whatever you think is the right thing to do.

> [Suhas] -  We need the registry to list the currently defined Mux Categories
> and also we do see there might be couple of more categories (if not many)
> that might get defined in the future.

This seems really vague for me. I would assume that you actually don't need a 
registry now and if there will be more categories defined in the future 
(which doesn't seem very likely) a new doc could still define a registry and 
update this RFC.

Mirja

>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/mmusic>
>
>

---

From: Suhas Nandakumar <[email-masked]>
Date: Thu, 27 Oct 2016 21:29:10 -0700

Hello Mirja

 Thanks for the responses. Please see inline.

Cheers
Suhas

On Thu, Oct 27, 2016 at 8:56 AM, Mirja Kühlewind <[email-masked]>
wrote:

>> keep
> I guess I just would leave those open in this doc (not saying anything
> about them) and not define an own temporal category for those.
>
> Probably you can just have a note in the iana section saying that for
> these parameter the category will be defined by other doc and should be
> left open for now.
>
>
>>
>> that
>> can
> Still not sure if a TBD category makes sense but don't have a strong
> opinion, so please do whatever you think is the right thing to do.
>
>

[Suhas]: Since we had WG consensus on the TBD category for the attributes
that are not analyzed by this draft and for those lacking publicly
available specification, I am inclined to leave those as is.

>> Categories
> This seems really vague for me. I would assume that you actually don't
> need a registry now and if there will be more categories defined in the
> future (which doesn't seem very likely) a new doc could still define a
> registry and update this RFC.
>
>

[Suhas]
 Section 15.2 and its sub-sections assign the multiplexing categories  to
several of the sub-registries in the IANA SDP Parameters registry. This is
done by adding a new column called 'Mux Category' to each of the
sub-registries in the SDP Parameters registry.
Having a registry defined to identify the names of these Multiplexing
categories ( as in Section 15.1) will ensure there is a formal place for
these names and formal rules to expand the category set in the future.

---

From: Mirja Kühlewind <[email-masked]>
Date: Fri, 28 Oct 2016 10:24:52 +0200

Hi Suhas,

see below.

 > these names and formal rules to expand the category set in the future.

The formal place where these categories are explained is this RFC. This RFC 
could also talk about the opportunity or even process to expand this list in 
future. However, as long as it is not clear that any expansion will be really 
needed in future, I don't see a need for e registry.

That's my view point. Please consult your AD for final advise.

Mirja

---

From: "Ben Campbell" <[email-masked]>
Date: Fri, 28 Oct 2016 10:20:10 -0500

On 28 Oct 2016, at 3:24, Mirja Kühlewind wrote:

>  >             2) Is the new registry for the Mux Category really 
> needed? Is it
>  >         expected
> The formal place where these categories are explained is this RFC. 
> This RFC could also talk about the opportunity or even process to 
> expand this list in future. However, as long as it is not clear that 
> any expansion will be really needed in future, I don't see a need for 
> e registry.
>

I understand that the working group thinks that the chance that new 
categories will come up is high enough that they prefer to define the 
registry (and more importantly, the registration policy) in advance. I 
agree that this is a borderline case, and reasonable people could go 
either way. I don't think we should overrule the working group consensus 
this late in the process.

Thanks!

Ben.