Re: [MMUSIC] WGLC on draft-ietf-mmusic-rfc8843bis-00

[Paul Kyzivat <[e-mail]>]

Flemming asked me to review this doc...

Its unfortunate that the misalignment between RFC8843 and RFC8829 
occurred, requiring a bis so soon. And I'm not particularly happy with 
the choice to prefer the mechanism in RFC8829 over that in RFC8843, 
since I think the mechanism chosen in RFC8843 was well reasoned. 
However, I did follow the discussions and understand the pragmatics that 
drove this choice. So I am going to take that as a given.

Now to other comments:

First, I have a general question about the overall goals of this bis. 
Superficially it is to eliminate the inconsistencies with RFC8829. But 
why? ISTM that the ultimate goal is to maximize the possibility of 
interoperation between webrtc and other SDP-based sessions such as SIP. 
If that is the true goal, maybe other things ought to be included in 
this bis. Notably, RFC8829 has a multitude of constraints on things that 
are included in bundled "m=" sections. For instance, section 5.2.1 of 
rfc8829 says:

    Bundle-only "m=" sections MUST NOT contain any ICE
    credentials and MUST NOT gather any candidates.

Should that constraint be included in the bis? It would be harmless to 
do so since it only affects syntax, not semantics. There are many 
similar constraints.

OTOH, RFC8829 also contains a lot of restrictions forbidding usage that 
is valid in RFC8843. Those constraints might make sense in the webrtc 
context but not so much for general use of bundle non-webrtc 
environments. Implementations should be free to use features that can't 
interoperate with webrtc. So importing those into this bis would IMO be 
an overreach.

It isn't my place to decide what is right here. But ISTM this ought to 
be discussed by the WG.

Other things:

* Section 1.4 says:

    In addition, this document implements the following erratas: 6431,
    6437

AFAICT errata 6437 was already corrected in RFC8843, which is odd since 
it was reported against it. The fix was a change in section reference 
from 4.2.2 to 4.2.6. But RFC8843 does reference 4.2.6, not 4.2.2, and 
the bis is unchanged in this regard. So perhaps mention of this errata 
should be dropped.

* Notes at the end of sections 7.3 and 7.4 discuss interoperation if 
implementions of the bis with those of RFC8843. It would be good to 
include an example of this. (For the benefit of those who implement from 
the examples!)

	Thanks,
	Paul