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

Hi Paul,

Thanks for the review! Please see inline.

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

It is covered in Section 10:

     "the offerer includes ICE-related media-level attributes in each bundled "m=" section (excluding any bundle-only "m=" sections)"

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

I am not sure I understand. What has been imported?

As you said, eventhough something may be optionally allowed by BUNDLE, webrtc can define constraints. 

We DID have a look whether there were other misalignments, but we could not find any, so if there is something one has to point to it.

----

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

Both 8843 and 8843bis does reference 4.2.2, i.e., there has been no change. I think you are looking at the wrong bullet in Section 9.2 :)

But, I guess this means that the change shall be implemented in 8843bis.

---

>* 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!)

You want to include examples of the examples from RFC8843?

Regards,

Christer

_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic