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

[Mirja Kühlewind <[e-mail]>]

Hi Suhas,

see below.

On 25.10.2016 19:30, Suhas Nandakumar wrote:
> Hello Mirja ,
>
> Thanks for the review. Please see inline for the response.
>
> On Tue, Oct 25, 2016 at 10:17 AM, Mirja Kuehlewind <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>     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
>     <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/
>     <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?
>
>
> [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"
>
> "

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

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.

>
>
>
>
>     2) Is the new registry for the Mux Category really needed? Is it expected
>     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.

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

>
>
>
>
>     _______________________________________________
>     mmusic mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/mmusic
>     <https://www.ietf.org/mailman/listinfo/mmusic>
>
>