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

From: Bo Burman <[email-masked]>
Date: Thu, 19 Nov 2015 15:56:53 +0000

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.

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

In section 9.1; Editorial: missing ":" in "ssrc-groupFEC-FR"

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.

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

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?

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.

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.

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? The IANA table now also contains "3gpp-roi-arbitrary" and "3gpp-roi-predefined", which should then be added.

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

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

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.

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

In section 15.2.18; Same comment as for section 15.2.17.

Cheers,
Bo

---

From: Suhas Nandakumar <[email-masked]>
Date: Sat, 21 Nov 2015 17:21:28 -0800

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 <[email-masked]> wrote:

> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>
>