Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-data-channel-sdpneg-20

[Ben Campbell <[e-mail]>]

Hi,

I think this is ready for IETF last call. That should start shortly. I have one editorial comment below that can be handled along with any other LC feedback, or whenever you have a reason to submit a new revision. Please note that I will step-down from the AD position in Prague. It’s too late to get this on a telechat prior to then, so responsibility will transition to one of the remaining ART ADs.

Thanks!

Ben.

----------------

§8: "Otherwise this document do not add any security considerations”
s/do/does




> On Mar 4, 2019, at 6:07 AM, Roni Even (A) <[e-mail]> wrote:
> 
> Hi Bo,
> Did the changes submitted -24
> The new text, changed BFCP and MSRP in the examples to lower case and fixed the author list
> 
> Roni
> 
> From: Bo Burman [mailto:[e-mail]]
> Sent: Monday, March 04, 2019 10:24 AM
> To: Roni Even (A); RIchard Ejzak; Ben Campbell
> Cc: [e-mail]; [e-mail]
> Subject: RE: AD Evaluation of draft-ietf-mmusic-data-channel-sdpneg-20
> 
> Thanks. I think this text is acceptable.
> 
> I assume that you can now submit a new version and that AD evaluation and IESG processing can then proceed. Ben?
> 
> /Bo
> 
> From: Roni Even (A) <[e-mail]>
> Sent: den 25 februari 2019 09:09
> To: RIchard Ejzak <[e-mail]>; Ben Campbell <[e-mail]>
> Cc: Bo Burman <[e-mail]>; [e-mail]; [e-mail]
> Subject: RE: AD Evaluation of draft-ietf-mmusic-data-channel-sdpneg-20
> 
> HI Richard,
> Thanks for the proposed text,  I just suggest a small editorial change.
> 
> 
> 
> The detailed offer/answer procedures for the dcsa attribute are dependent on the associated sub-protocol. If no offer/answer procedures exist for the sub-protocol when used outside of the dcsa attribute, no specification is needed for use with dcsa. The  IANA registration procedures for the WebSocket Subprotocol Name Registry (section 9.1) do not strictly require a specification of the offer/answer procedures for the sub-protocol when used with dcsa. If the sub-protocol has defined offer/answer procedures when used outside of dcsa, such a specification is encouraged to ensure interoperability. If the sub-protocol has defined offer/answer procedures when used outside of dcsa, but no specification exists for the offer/answer procedures for the sub-protocol when used with dcsa, implementations SHOULD assume the use of the default values for all otherwise-negotiable and applicable sub-protocol parameters.
> 
> 
> Is this text or the one from Richard address the FCFS registration  in the IANA WebSocket Subprotocol Name Registry?
> 
> 
> 
> Roni Even
> 
> 
> From: RIchard Ejzak [mailto:[e-mail]]
> Sent: Friday, February 22, 2019 5:51 PM
> To: Ben Campbell
> Cc: Roni Even (A); Bo Burman; [e-mail]; [e-mail]
> Subject: Re: AD Evaluation of draft-ietf-mmusic-data-channel-sdpneg-20
> 
> May I suggest the following text for the last paragraph of 5.2:
> 
> The detailed offer/answer procedures for the dcsa attribute are dependent on the associated sub-protocol. If no offer/answer procedures exist for the sub-protocol when used outside of the dcsa attribute, no specification is needed for use with dcsa. While IANA registration procedures for the sub-protocol do not strictly require a specification of the offer/answer procedures for the sub-protocol when used with dcsa, if the sub-protocol has defined offer/answer procedures when used outside of dcsa, such a specification is encouraged to ensure interoperability. If the sub-protocol has defined offer/answer procedures when used outside of dcsa, but no specification exists for the offer/answer procedures for the sub-protocol when used with dcsa, implementations SHOULD assume the use of the default values for all otherwise-negotiable and applicable sub-protocol parameters.
> 
> If this paragraph is not acceptable, please at least correct the typo "dsca".
> 
> Richard
> 
> On 2/21/19 3:02 PM, Ben Campbell wrote:
> <AD-Hat-Off>
> I think it will confuse people to say things MUST be specified, and elsewhere say a specification is not required. That could be fixed with some clarification along the lines of “While specifications is not strictly required, they are encouraged. If a specification exists, it should include…”
> 
> I do think it would be better to do that non-normatively, as a MUST that applies to an optional spec is pretty diluted for a MUST.
> </AD-Hat-Off>
> 
> <AD-Hat-On>
> My concern as an AD is that the existing text seems inconsistent, as if people had not connected the two parts when thinking about this. I’m okay with whatever the WG wants, as long as it is consistent.
> 
> But in any case, we’ve been spinning on this point for a while now. Can we make a decision soon?
> </AD-Hat-On?
> 
> Thanks!
> 
> Ben.
> 
> 
> On Feb 14, 2019, at 8:45 PM, RIchard Ejzak <[e-mail]> wrote:
> 
> Hi Roni, Bo,
> It seems that we are conflating two different things: the requirements for a subprotocol specification, and the requirements for subprotocol identifier registration.  I see no reason why we cannot have MUST requirements related to subprotocol specifications (re O/A for dcsa) while still having FCFS for identifier registration.  If someone registers an identifier that you would like to use for a specific protocol but does not include a reference to a proper O/A specification for dcsa, then just register another identifier with a reference to an acceptable specification.  The registration of an identifier without proper O/A documentation for dcsa will fail to properly interoperate in practice, should wither from disuse, and could be specifically deprecated in a proper specification.  Am I missing something here?
> Strictly speaking, there is no reason to include any additional text in the document, since the IANA procedures already allow for this case, although it might be helpful to echo the point that a preferred identifier might already be registered without the required documentation, so IANA might select a new identifier.
> Richard
> On 2/14/19 4:42 AM, Roni Even (A) wrote:
> HI Bo,
> I do not think it is realistic to change the policy from FCFS. I was pointing out that it is strange that there is a FCFS policy while in the creation of the registry there is a requirement for a document.
> 
> I am looking for suggestion about  what text we can use in section 5.2 in order to finish this document.
> 
> Roni
> 
> From: Bo Burman [mailto:[e-mail]]
> Sent: Thursday, February 14, 2019 12:38 PM
> To: Roni Even (A); Ben Campbell
> Cc: RIchard Ejzak; [e-mail]; [e-mail]
> Subject: RE: AD Evaluation of draft-ietf-mmusic-data-channel-sdpneg-20
> 
> Yes, a document can be provided with FCFS, but is not required, as said with the definition of IANA FCFS in https://tools.ietf.org/html/rfc5226#section-4.1.
> I certainly agree to the “MUST”s you prefer and wouldn’t object if we changed from FCFS to Specification Required.
> 
> From: Roni Even (A) <[e-mail]>
> Sent: den 14 februari 2019 10:36
> To: Bo Burman <[e-mail]>; Ben Campbell <[e-mail]>
> Cc: RIchard Ejzak <[e-mail]>; [e-mail]; [e-mail]
> Subject: RE: AD Evaluation of draft-ietf-mmusic-data-channel-sdpneg-20
> 
> Hi Bo,
> I agree that this is the issue but I claim that it has nothing to do with the registration but with referencing this document.
> 
> Looking at https://tools.ietf.org/html/rfc6455#section-11.5  it looks like a document is required
> 
> Subprotocol Definition
>       A reference to the document in which the subprotocol being used with the WebSocket Protocol is defined.
> 
> 
> 
> Roni Even
> 
> From: Bo Burman [mailto:[e-mail]]
> Sent: Thursday, February 14, 2019 11:07 AM
> To: Roni Even (A); Ben Campbell
> Cc: RIchard Ejzak; [e-mail]; [e-mail]
> Subject: RE: AD Evaluation of draft-ietf-mmusic-data-channel-sdpneg-20
> 
> 	• any document regardless of which standard body composed it and which reference this document will be required to have follow section 5.2 normative language
> This is the very core of the issue; FCFS doesn’t even require that there is any document - at all! What you suggest with the above sentence is not FCFS but more of “Specification Required”, which will then also have a designated expert.
> 
> From: Roni Even (A) <[e-mail]>
> Sent: den 14 februari 2019 07:43
> To: Bo Burman <[e-mail]>; Ben Campbell <[e-mail]>
> Cc: RIchard Ejzak <[e-mail]>; [e-mail]; [e-mail]
> Subject: RE: AD Evaluation of draft-ietf-mmusic-data-channel-sdpneg-20
> 
> Hi Bo,
> My view is that the MUST is in place, this are the guidelines for writing a document defining a new sub protocol specification. This means that any document regardless of which standard body composed it and which reference this document will be required to have follow section 5.2 normative language otherwise this is an errata in the sub-protocol document and we can ask them to fix it if they reference the data channel SDPneg document . BTW: I believe that in any standard body when you will have such sub protocol to be used with SDP an offer/answer usage will be specified for interoperability reasons.
> We can change it to a SHOULD and say that every IETF document MUST have such a section but I prefer to keep the MUST
> 
> Roni Even
> 
> 
> 
> From: Bo Burman [mailto:[e-mail]]
> Sent: Tuesday, February 12, 2019 6:29 PM
> To: Roni Even (A); Ben Campbell
> Cc: RIchard Ejzak; [e-mail]; [e-mail]
> Subject: RE: AD Evaluation of draft-ietf-mmusic-data-channel-sdpneg-20
> 
> Roni,
> 
> Are you saying that if case 1.4 (a non-IETF spec of datachannel usage with a base protocol for non-datachannel use that is specified in an RFC that has O/A) should occur, and if the IETF community finds out and disapproves, it can create a competing RFC for that same datachannel usage of the base protocol that uses another FCFS tag?
> 
> I guess that is true.
> Cases 2.4 and 4.4 may also be broken, but any datachannel specification there would also be originated outside of IETF.
> Is IETF OK with not using IETF/IANA to perform any check on IANA registration from non-IETF sources?
> Ben?
> 
> If that is the decision, we should replace the “MUST”s discussed below with something like “…is highly encouraged…” as suggested by Ben.
> 
> /Bo
> 
> From: Roni Even (A) <[e-mail]>
> Sent: den 11 februari 2019 10:05
> To: Bo Burman <[e-mail]>; Ben Campbell <[e-mail]>
> Cc: RIchard Ejzak <[e-mail]>; [e-mail]; [e-mail]
> Subject: RE: AD Evaluation of draft-ietf-mmusic-data-channel-sdpneg-20
> 
> Bo,
> This case is even more complicated, we just recently had a registration from ETSI in thehttps://www.iana.org/assignments/media-types/media-types.xhtml on a media subtype that is also in progress as a WG document in the Payload WG.  I think the conclusion that there is no harm in having two registration for the same codec as long as there is a reason to do it.
> I think that if 1.4 will be a concern for the IETF community we can write a document that follow the guidelines. I also want to believe that any one writing a registration document outside the IETF that will have concern with interoperability and is using SDP will write some guidelines for offer/answer and may read this document since it will be specified in the IANA registry references as specified in section 9
> 
> Roni Even
> 
> From: Bo Burman [mailto:[e-mail]]
> Sent: Monday, February 11, 2019 9:51 AM
> To: Roni Even (A); Ben Campbell
> Cc: RIchard Ejzak; [e-mail]; [e-mail]
> Subject: RE: AD Evaluation of draft-ietf-mmusic-data-channel-sdpneg-20
> 
> Hi,
> 
> For all cases where the datachannel sub-protocol spec is an I-D (RFC), you’re right.
> 
> However, the text in the draft breaks for case 1.4 in my list a bit down in this thread, which is a non-RFC sub-protocol datachannel spec that ignores O/A procedures (or no spec – only IANA registration).
> 
> /Bo
> 
> From: Roni Even (A) <[e-mail]>
> Sent: den 10 februari 2019 13:38
> To: Bo Burman <[e-mail]>; Ben Campbell <[e-mail]>
> Cc: RIchard Ejzak <[e-mail]>; [e-mail]; [e-mail]
> Subject: RE: AD Evaluation of draft-ietf-mmusic-data-channel-sdpneg-20
> 
> Hi,
> My view here is that section 5.2 talks about how to specify usage of sub-protocols in data channel  that may be ones that already defined in  the web socket registry or new ones. Therefore the normative language for such a document.
> The IANA registrations addresses the two cases , new ones need registration while existing ones need to add the references to DCSA usage. My view is this is to prevent conflicts. So I am not sure I see a problem with the current text. Maybe to clarify that section 5.2 is about using sub-protocols in DCMAP and that for new ones need to register based in the websocket registry to guarantee uniqueness.
> 
> BTW: the rtcweb protocol (https://tools.ietf.org/html/draft-ietf-rtcweb-data-protocol-09)  only addresses the sub-protocol name and is silent about any parameters of the sub-protocol and about adding new sub-protocol as all.
> 
> Roni Even
> 
> 
> From: Bo Burman [mailto:[e-mail]]
> Sent: Friday, February 08, 2019 10:18 AM
> To: Ben Campbell
> Cc: Roni Even (A); RIchard Ejzak; [e-mail]; [e-mail]
> Subject: RE: AD Evaluation of draft-ietf-mmusic-data-channel-sdpneg-20
> 
> Thanks.
> 
> 	• This still confuses me a bit. If a protocol is used with dcsa, it uses offer/answer, right?
> Strictly, it does, but what I mean with “without O/A” is (typically) where a (sub-)protocol specification has defined a set of attributes and possible parameters with values but did not say anything about how O/A works with those parameters and values. For example; if there are rules for the answerer to follow based on what values were set in the offer, and how the offerer should interpret/act on values received in the answer (comparing with what was in the offer). Lacking O/A description, even the “base” protocol could have “broken” O/A, but it seems like a bad idea to define sub-protocol usage of it and not at least fix O/A for this sub-protocol-with-datachannel usage.
> 
> To be fair, the “default” O/A may still work even if left unspecified (silent), but that would require that attribute parameters are truly independent between offer and answer. If they are not, things break. Also, there might be special conditions that have to be taken into account when the (sub-)protocol runs on top of SCTP/UDP, as with datachannel, instead of (e.g.) directly on IP, which also could cause spec ambiguities and interoperability problems.
> 
> Authors?
> 
> From: Ben Campbell <[e-mail]>
> Sent: den 7 februari 2019 18:43
> To: Bo Burman <[e-mail]>
> Cc: Roni Even (A) <[e-mail]>; RIchard Ejzak <[e-mail]>; [e-mail]; [e-mail]
> Subject: Re: AD Evaluation of draft-ietf-mmusic-data-channel-sdpneg-20
> 
> 
> 
> 
> On Feb 7, 2019, at 7:06 AM, Bo Burman <[e-mail]> wrote:
> 
> Hi Roni, Richard,
> 
> Apologies that this becomes a bit lengthy. Suggest to read this mail as HTML, for clarity since I use colors.
> 
> I think the problem are the "MUST"s in this text in section 5.2:
>    The detailed offer/answer procedures for the dcsa attribute are
>    dependent on the associated sub-protocol.  A sub-protocol
>    specification MUST define the offer/answer procedures for the dsca
>    attribute (if applicable) associated with the sub-protocol, if the
>    sub-protocol has defined offer/answer procedures when used outside of
>    dcsa.  If no offer/answer procedures exist for the sub-protocol when
>    used outside of the dcsa attribute, no specification is required for
>    use with dcsa.
> 
> This still confuses me a bit. If a protocol is used with dcsa, it uses offer/answer, right? Such a registration is not helpful for interop purposes. It would be helpful for code-point collision avoidance purposes.
> 
> IIRC, I got mixed answers to my previous question about whether the dcsa registrations were for the purposes of interop or just collision-avoidance.
> 
> 
> 
> ... and a similar, but not identical (why not?) text in section 6:
>    The detailed offer/answer procedures for the dcsa attribute are
>    dependent on the associated sub-protocol.  A sub-protocol
>    specification MUST define the offer/answer procedures for the dsca
>    attribute (if applicable) associated with the sub-protocol.
> 
> Should “…sub-protocol specification MUST define…” be replaced with “…sub-protocol specification in an RFC MUST define…” (see also discussion below)?
> 
> As I understand it, with FCFS, IANA cannot be used as “trigger” to check if those "MUST"s are fulfilled in a specification for the sub-protocol to be registered. Only if the sub-protocol is specified by an RFC, the “MUST”s can be enforced (by IETF/IESG review). Therefore, this draft has defined a procedure for adding sub-protocol that is not consistent because it doesn't describe any fully solid method to ensure the “MUST”s.
> 
> Ben, please correct me if that understanding is wrong!
> 
> 
> That is correct for FCFS.  A policy of “specification required” would invoke review by a designated expert. This draft could contain instructions to the expert to make sure that the specification follows the MUSTs, even if that spec is not an RFC.
> 
> 
> 
> You can try to fix the inconsistency by going to SHOULD above, but that would also allow for incomplete or non-functional sub-protocol specifications, e.g. if a base spec has Offer/Answer that is not really applicable, not workable, or incomplete for unmodified usage with dcsa.
> 
> I don’t think SHOULD helps. SHOULD means you are expected to do something unless you have a good reason not to and fully understand the consequences. Not bothering to right a spec is not likely to qualify.
> 
> You could replace the language to non-normatively say that such documentation is highly encouraged.
> 
> 
> 
> I don't think the possibility to just register another identifier really helps in that case, because that seems only applicable when an Internet-Draft desires to specify a sub-protocol for use with dcsa but where the base (WebSocket) spec related to that tag is not good enough to build on.
> 
> I had to try to straighten this out for myself and made this table:
> 
> Case #                Base spec         Datachannel    Result
> 1.1                       RFC w O/A       RFC w O/A       OK
> 1.2                       RFC w O/A       RFC wo O/A     NOK (unless Datachannel has trivial mapping to Base)
> 1.3                       RFC w O/A       Other w O/A   OK
> 1.4                       RFC w O/A       Other wo O/A NOK (unless Datachannel has trivial mapping to Base)
> 2.1                       RFC wo O/A     RFC w O/A       No O/A spec required by this draft
> 2.2                       RFC wo O/A     RFC wo O/A     No O/A spec required by this draft
> 2.3                       RFC wo O/A     Other w O/A   No O/A spec required by this draft
> 2.4                       RFC wo O/A     Other wo O/A No O/A spec required by this draft
> 3.1                       Other w O/A   RFC w O/A       OK
> 3.2                       Other w O/A   RFC wo O/A     NOK (unless Datachannel has trivial mapping to Base)
> 3.3                       Other w O/A   Other w O/A   OK
> 3.4                       Other w O/A   Other wo O/A NOK (unless Datachannel has trivial mapping to Base)
> 4.1                       Other wo O/A RFC w O/A       No O/A spec required by this draft
> 4.2                       Other wo O/A RFC wo O/A     No O/A spec required by this draft
> 4.3                       Other wo O/A Other w O/A   No O/A spec required by this draft
> 4.4                       Other wo O/A Other wo O/A No O/A spec required by this draft
> 
> 	• For Cases 2.x and 4.x, the orange text in the draft says that no spec is required.
> 	• Cases 1.1 and 3.1 will have defined dcsa O/A procedures, required by ”MUST”s in blue text, and should therefore work OK.
> 	• Cases 1.3 and 3.3 are not under IETF/IESG control and IANA will not ask for a spec, but will work OK (O/A exist, even if not checked).
> 	• Cases 1.2 and 3.2 violate the blue text, but can possibly work OK if the base spec O/A procedures are also applicable to dcsa without modification (red text). These cases will however be detected by IETF/IESG review of the RFC-to-be and should not occur in practice.
> 	• Case 1.4 violates the blue text, but can possibly work OK if the base spec O/A procedures are also applicable to dcsa without modification (red text). The potentially “broken” (or nonexistent) dcsa sub-protocol spec has no formal relation to IETF/IESG, even if the “base” spec is an RFC. Ben, all; Are we OK that FCFS may let this case through? Can it be covered by adding a note to the FCFS choice?
> 	• Case 3.4 is similar to 1.4, but neither the “base” spec nor the dcsa sub-protocol spec has any relation to IETF/IESG. I believe it should be entirely OK to simply disregard this case in the draft.
> 
> The cases that would be “solved” by picking a new tag are the x.1 and x.3 ones, and where “base” is considered insufficient.
> 
> On how to update IANA information, I assume a dcsa reference (where applicable) should/could simply be added to the existing WebSocket entry?
> 
> /Bo
> 
> -----Original Message-----
> From: Roni Even (A) <[e-mail]>
> Sent: den 4 februari 2019 12:54
> To: RIchard Ejzak <[e-mail]>; Bo Burman <[e-mail]>; [e-mail]
> Cc: [e-mail]
> Subject: RE: AD Evaluation of draft-ietf-mmusic-data-channel-sdpneg-20
> 
> HI Bo,
> I agree with Richard, such a registration can happen today regardless of dcsa  (happened recently with tetra payload). So the recommendation is if there is a difference use a different name, this is the problem with FCFS policy
> 
> As for a note that any subprotocol tag comparison must be case-insensitive, I can add it after iesg last call.
> 
> Roni
> 
> -----Original Message-----
> From: RIchard Ejzak [mailto:[e-mail]]
> Sent: Saturday, January 26, 2019 1:04 AM
> To: Bo Burman; Roni Even (A); [e-mail]
> Cc: [e-mail]
> Subject: Re: AD Evaluation of draft-ietf-mmusic-data-channel-sdpneg-20
> 
> Hi All,
> 
> I have not engaged in any of the discussion recently, but I have a (perhaps naive) proposal to address Bo's subprotocol registration issue.
> 
> First of all, is this really a problem?  If a desired identifier is already in use by another organization but acceptable dcsa procedures are not and will not be documented by that org, what is the harm is just using another identifier?  This possibility could just be described in the document.  Assuming that a better solution is needed, maybe the following could work:
> 
> Is it possible to define the extension to the table so that one and only one entity is responsible for each row, i.e., for both the websocket and dcsa entries for a particular subprotocol identifier?  That way, if dcsa is to apply to an existing subprotocol such as MSRP, then only the entity that registered MSRP can extend the registration to apply to dcsa.  Each entry should still be associated with its own reference to allow the relevant procedures to be in different documents, but this does not appear to conflict with the requirements for FCFS.
> 
> So, if an RFC registers a subprotocol abc for websockets, the same or a different RFC would need to register abc for dcsa.  If organization xyz registers a subprotocol abc for websockets, xyz would provide another reference for the registration of abc for dcsa.  If necessary, this restriction could be documented with another RFC in the same way that RFC 7936 documents a clarification to registry procedures for websocket subprotocols.
> 
> A problem remains if a subprotocol identifier for websockets has been registered by an entity that is not willing or able to acceptably document and register the use of the identifier for dcsa by other entities.  But this potential problem already exists with websockets and is not made worse for dcsa.  An alternative identifier can always be selected if necessary (and is specifically described in the iana procedures).
> 
> Generally speaking, it seems that other alternative extensions to the registration procedures could be specified (such as in RFC7936) to address perceived limitations of the existing procedures, as long as FCFS is not violated.  If FCFS itself is the issue, then it seems that we would have to request a new registry for dcsa subprotocol identifiers.  But this does not seem necessary to me, since one can always just use a different identifier if any existing dcsa reference for the preferred identifier has unacceptable limitations.
> 
> Richard
> 
> On 1/25/19 4:00 AM, Bo Burman wrote:
> > Hi Roni, going temporarily off-list for this one
> >
> > Thanks for addressing my comments.
> >
> > I have a remaining concern with using the WebSocket subprotocol registry that Ben mentioned briefly but that I don't think is fully addressed yet.
> > Assume this scenario:
> > 1) Company "xyz" wants to use subprotocol "abc" with dcsa
> > 2) xyz sends a dcsa subprotocol registration request for "abc.xyz.com" to IANA:
> >      a) the specification URL in the registration is pointing to a document residing on xyz.com, OR there's no specification URL at all, only a brief text
> >      b) the document on xyz.com defines "abc" usage over datachannel,
> > but doesn't include any SDP offer/answer considerations (or no text at
> > all)
> > 3) However, "abc" is in fact an existing protocol:
> >      a) its' "base specification" is not referenced by the xyz.com document (or there's no document, see above)
> >      b) SDP offer/answer is defined in that "base specification"
> >
> > The above case would require that the usage of abc over datachannel describes SDP offer/answer, but it seems unreasonable to rely on IANA to detect that; rather, expert review would be required, although I believe it would go too far to require specification or standards action.
> > --> How do you achieve that with First-Come-First-Serve?
> >
> >
> > As a related nit, I note that the WebSocket subprotocol registry is case sensitive, has a note that registrations that differ only in case will be refused, and that MSRP and BFCP are there registered in lower case ("msrp"/"bfcp") while the examples with dcsa in -sdpneg use upper case, both for SDP (ABNF string literals are per default case-insensitive if not explicitly specified otherwise) and the new usage level in section 9.3. Regardless if changing to lower case or not in -sdpneg examples, I believe this warrants a note that any subprotocol tag comparison must be case-insensitive.
> >
> > I'll leave to you and the other authors to find an agreeable way to prune the author list to 5 or less. Of course, anyone removed from the list of authors should instead be listed in the Acknowledgements section.
> >
> > Cheers,
> > /Bo
> >
> >
> > -----Original Message-----
> > From: Roni Even (A) <[e-mail]>
> > Sent: den 17 januari 2019 09:48
> > To: Ben Campbell <[e-mail]>;
> > [e-mail]
> > Cc: mmusic WG <[e-mail]>
> > Subject: RE: AD Evaluation of draft-ietf-mmusic-data-channel-sdpneg-20
> >
> > Hi Ben,
> > Submitted a new revision -23
> > Changes from -22
> >
> > 1. Change the abstract and introduction sections to remove reference
> > to WGs (RTCWEB) 2. Update the security section with your comment 3.
> > Added the text proposed by Bo to section 5.2
> >
> > As for the number of authored. There were 5 authored when I took the
> > editorship of the document.  I assume this issue is for the WG chairs
> >
> > Ron Even
> >
> > -----Original Message-----
> > From: Ben Campbell [mailto:[e-mail]]
> > Sent: Tuesday, January 15, 2019 1:15 AM
> > To: [e-mail]
> > Cc: mmusic WG
> > Subject: Re: AD Evaluation of draft-ietf-mmusic-data-channel-sdpneg-20
> >
> > Hi, what is the status of this? Any chance of submitting a new revision soon?
> >
> > Thanks!
> >
> > Ben.
> >
> >> On Nov 26, 2018, at 4:32 PM, Ben Campbell <[e-mail]> wrote:
> >>
> >> Hi,
> >>
> >> Version 22 resolves most, but not all of my comments. I’ve copied the
> >> unaddressed comments below for reference. It may be that people
> >> disagree with my comments or suggestions, but if so please tell me so
> >> we can discuss :-)
> >>
> >>> On Aug 27, 2018, at 10:06 PM, Ben Campbell <[e-mail]> wrote:
> >>>
> >> [...]
> >>
> >>> Substantive Comments:
> >>>
> >>> - There are 6 authors listed. Normally the limit is 5 unless there is a really good reason. Did all of the authors contribute substantial text? Could the author list be reduced to just editors, and have the rest in a “contributors” section?
> >> Please note that, unless I can offer a really good reason why this needs more than 5 authors, this issue is almost certain to generate one or more DISCUSS positions during IESG evaluation.
> >>
> >> [...]
> >>
> >>
> >>> §8: I am skeptical that this adds no security considerations above
> >>> those in sctp-sdp. In particular, it seems worth mentioning that
> >>> each subprotocol may come with it’s own security considerations that
> >>> need to be documented as part of the subprotocol definition. (As an
> >>> example, MSRP has security considerations about the URL used in the
> >>> a=path attribute that would apply to any definition of the use of
> >>> “path” at the dcsa level.)
> >> [...]
> >>
> >>> §9.1: What is the rational for sharing the websocket subprotocol registry rather than creating a new one for data channels? The websocket subprotocol name registry has a policy of “First Come First Served”. This draft seems to state requirements for subprotocol specifications, but FCFS does not require specifications.
> >>>
> >> [...]
> >>
> >>> Editorial Comments:
> >>>
> >>> - Abstract: The abstract will not age well. Years from now, no one
> >>> will think in terms of what RTCWeb vs some other working group
> >>> defined. I suggest recasting this in terms of the documents and
> >>> protocols, not the working groups.  (Comment repeats for
> >>> introduction.)
> >>>
> >> [...]
> >>
> >>> §9.3, first paragraph: " SDP attributes that are defined for use at
> >>> the dcsa  usage level only SHALL use the dcsa usage level when
> >>> registering the  attribute.”
> >>>
> >>> I don’t understand this sentence. Consider a MUST NOT/SHALL NOT construction.
> >>>
> 
>