Re: [MMUSIC] IANA section review of draft-ietf-mmusic-sdp-mux-attributes-10

[Suhas Nandakumar <[e-mail]>]

Hello Bo

  Thank you for the review. Please see inline.

  Also what should be the process here to submit a new version with the
comment incorporated at this stage of document life cycle.

Cheers
Suhas

On Thu, Nov 19, 2015 at 7:56 AM, Bo Burman <[e-mail]> wrote:

> I have reviewed the IANA section (15) of this draft and have the following
> comments:
>
>
>
> In section 5.47; “alt-group” is inconsistent with IANA table, where it is
> defined as session level.
>
>
>

[Suhas] Will fix this



> In section 5.54; “T38FaxMaxIFP”, “T38FaxUdpECDepth”, “T38UdpFECMaxSpan”,
> and “T38ModemType” are all inconsistent with IANA, where they are defined
> as media level.
>
>
>

[Suhas] Will fix this.


> In section 9.1; Editorial: missing “:” in “ssrc-groupFEC-FR”
>

[Suhas] Will fix


>
>
> In section 15.1; suggest clarifying what it means to “indicate the
> applicability” of a newly defined multiplexing category value to various
> sub-registries is detailed a bit more, e.g. that such new multiplexing
> category can replace the assigned category defined in this document, if
> that is the intent, and in that case what it means (e.g. for
> interoperability) to change the category for an attribute.
>

[Suhas] I am not sure if want to add a note on the possible
interoperability failure of the new registration updating the category
assigned by this specification. If any future registrations update an
existing categorization, such a registration is expected to define the
reason and behavior in the case of multiplexing.



>
>
> In section 15.2.2; “rtsp-ice-d-m” is not discussed anywhere else in the
> document; should it be?
>

[Suhas] I think the categorization for this attribute must be TBD given
that it is still in draft stage and we defined to stop categorizing new
attributes a while back for this specification. What do you suggest we do ?


>
> In section 15.2.3; “qos-mech-send” and “qos-mech-recv” are here both
> listed as NORMAL, which is inconsistent with the categorization TRANSPORT
> in section 5.6. The current table ends with “calgextmap”, but the IANA
> table continues with “phone-context”, “clir”, “Q763-nature”, “Q763-plan”,
> “Q763-INN”, “require”, “record”, and “recordpref”, some of which refer
> quite old RFCs. Why are those not included in the table?
>
>
>

[Suhas] I am not sure why these were missed or did IANA added them in the
last 6-8 months since the last edit was made to this draft. Is there a way
to see IANA edits version history??

I will fix the qos-mech-* categorizations.



> In section 15.2.4; “codecConfig” is inconsistent with IANA value that does
> not use a capital C in the middle: “codecconfig”. The IANA table now also
> has “predefined_ROI”, which should then be added.
>

[Suhas] Will fix the codecConfig entries. If predefined_ROI was newly added
, I would prefer to sticking with WGs decision on not adding new entrants
in this spec.


>
>
> In section 15.2.7; “DDP” is listed here, but is not mentioned or motivated
> in section 8.5, which would be reasonable considering that “DUP” is
> discussed in section 8.6.
>
>
>

[Suhas] Agree and will update


> In section 15.2.8; What does it really mean when “rtcp-fb” attribute as
> such is defined as IDENTICAL-PER-PT, but a certain parameter (here “app”)
> is assigned another category (here “SPECIAL”)? Does the parameter override
> the attribute-wide default? Is this principle described somewhere?
>

[Suhas] The 'app' attribute for rtcp-fb has no clear definition and depends
on the application semantics. Thus having categorization other the SPECIAL
made much sense. Other than that, the remaining rtcp-fb attributes and
their parameters all get IDENTICAL-PER-PT as defined in Section 7


> The IANA table now also contains “3gpp-roi-arbitrary” and
> “3gpp-roi-predefined”, which should then be added.
>
>
[Suhas] same answer as other new attribute categorization.


>
> In section 15.2.9; Same comment regarding override as for 15.2.8, for both
> “app” and “ecn” values.
>

[Suhas] Since the top level attributes can't be defined on their own , i
don't see if we need more clarification in here. An developer looking at
rtcp-fb and distilling to sub-sections that define the individual sub
attributes will know exactly the category to be used.



>
>
> In section 15.2.14; IANA table now also contains “pause”, which should
> then be added.
>

[Suhas] Same answer as not adding new attributes


>
>
> In section 15.2.16; Editorial: Table heading “QoS Mechanism” seems to be
> copy-pasted from 15.2.15, but should probably instead be “Value Name” or
> something similar.
>
>
>

[Suhas] Will fix this


> In section 15.2.17; The names listed in the table are not mentioned or
> motivated in section 5.16 – should they be?
>

[Suhas]. I need to update section 5.16 to spell out these attributes and
will update

>
>
> In section 15.2.18; Same comment as for section 15.2.17.
>

[Suhas] Will do the same as section 15.2.17

>
>
> Cheers,
>
> Bo
>
>
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>
>