Re: [MMUSIC] Editorial nits in draft-ietf-mmusic-mux-attributes-10

[Bo Burman <[e-mail]>]

My apologies for that!
I've added my responses to your earlier questions inline below (removing stuff from the original mail that I did not comment on).

Cheers,
/Bo

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.
[BoB] OK. It's reasonable to defer such discussion until categories are actually changed. I withdraw my comment.


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 ?
[BoB] Put it as TBD.

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??
[BoB] You can at least see what drafts were considered and used to change the registry on a yearly basis. The list for 2015 is here: http://www.iana.org/performance/ietf-draft-status/2015. I doubt the reason for change is there, however. Those missing attributes were actually discussed on the MMUSIC list in January 2015: https://www.ietf.org/mail-archive/web/mmusic/current/msg14266.html
In that thread, it seems to be concluded that those attributes are simply missing from IANA, and it was then unclear "whether the mux draft actually examined them". They were obviously added to IANA since then, but I cannot find exactly when.

I would like to avoid a situation where the draft is considered incomplete, but I recognize that IANA registry changed since you extracted the snapshot. For the particular attributes that are defined in since-long existing RFCs that cannot be changed to cope with categorization, I think they should at least be listed in your draft. It is probably OK to just categorize them as TBD, but I encourage the WG to comment.

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.
[BoB] OK. Leave predefined_ROI out.

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
[BoB] OK

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.
[BoB] OK. Leave them out.

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.

[BoB] OK. Makes sense. You don't need to change anything.

In section 15.2.14; IANA table now also contains "pause", which should then be added.
[Suhas] Same answer as not adding new attributes

[BoB] OK. Leave it out.

From: Suhas Nandakumar (snandaku) [mailto:[e-mail]]
Sent: den 18 december 2015 18:27
To: Bo Burman
Cc: Suhas Nandakumar ([e-mail]); mmusic ([e-mail])
Subject: Re: Editorial nits in draft-ietf-mmusic-mux-attributes-10

Hello Bo

 I will work on these things .. However I had few follow up questions on your previous review comments.
Would love to get your feedback on those so I can incorporate your response fully

Thanks
Suhas

Sent from my iPhone

On Dec 18, 2015, at 7:44 AM, Bo Burman <[e-mail]<mailto:[e-mail]>> wrote:
Hi Suhas,

While making the draft write-up for this one, I found the below nits that need to be addressed:


*         The IPv4 address on the "o=" line in section 4.4 is non-RFC5735-compliant and should be changed.

*         The RFC 2119 boilerplate does not seem to be exactly the recommended one, which should be fixed.

*         Change 'MUST not' to 'MUST NOT' at end of section 5.8, and in the table in section 5.9.

*         Is the use of pre-RFC5378 disclaimer intentional? This draft is according to the document header not formally revising or updating other drafts.

*         The following abbreviations are not expanded on first use (section of first use in parentheses): ICE (1), DTLS-SRTP (3), NAT (3), RTCP (4), DCCP (4.2), VoIP (5.29), OMA (5.44), BCAST (5.44), 3GPP (5.47), BICC (5.55), IPBCP (5.55), RAMS (7.3), DSCP (10.1)

*         Remove parentheses around "(SIP)" in heading of 5.4

*         Review RFC2119 use of "MAY"; is it used in the RFC2119 meaning "is explicitly allowed to", or is it rather "can"?

*         QOS -> QoS in section 4

*         Several abbreviations are expanded multiple times, not only the first, e.g. SDP; consider removing unmotivated expansions

*         Consider using lowercase "altc" in 5.41 heading instead of capitalized

*         Consider using double instead of single quotes for 'IN' in 5.42

*         ITU.T -> ITU-T in 5.55

*         "transport, media and media" -> "transport, media, and media" in 4.6

*         "clients and servers and manage" -> "clients and servers, and manage" in 5.11

*         "extension,Traversal" -> "extension, Traversal" in 5.12

*         "pseudo-wire and others" -> "pseudo-wire, and others" in 5.48

*         "transport, media and media format" -> "transport, media, and media format" in 14

*         "actual and latent configuration" -> "actual, and latent configuration" in 14.3.1

*         Use title case in all headings

*         Use spaces consistently around the hyphen in headings

*          [R3GPPTS183.063] link should likely better point to www.3gpp.org<http://www.3gpp.org>, as other 3GPP references do

*          [R3GPPTS26.114] link should likely better point to www.3gpp.org<http://www.3gpp.org>, as other 3GPP references do

*         Add publication dates to all IETF-external document references, meaning you should reference specific versions of them

Please provide a new version incorporating those, together with any changes addressing my previously posted IANA section comments.
When that is done, I believe the document should be ready for publication request.

Cheers,
/Bo