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

Hello Mirja

 Thanks for the responses. Please see inline.

Cheers
Suhas

On Thu, Oct 27, 2016 at 8:56 AM, Mirja Kühlewind <ietf@kuehlewind.net>
wrote:

> 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 <ietf@kuehlewind.net
>> <mailto:ietf@kuehlewind.net>> 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/stat
>> ement/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-a
>> ttributes/
>>     <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.
>
>

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

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

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

> Mirja
>
>
>>
>>
>>
>>     _______________________________________________
>>     mmusic mailing list
>>     mmusic@ietf.org <mailto:mmusic@ietf.org>
>>     https://www.ietf.org/mailman/listinfo/mmusic
>>     <https://www.ietf.org/mailman/listinfo/mmusic>
>>
>>
>>