Re: [rtcweb] Ben Campbell's Yes on draft-ietf-rtcweb-jsep-24: (with COMMENT)

[Ben Campbell <[e-mail]>]

[…]

> >
>> >> -5, throughout: There are a number of normative keywords used in constructions
>> >> like "... MUST foo, as described in RFCXXX". That construction is ambiguous
>> >> about whether it defines a normative requirement to do something, and the doing
>> >> of that something is described in the RFC, or if describes the referenced RFC
>> >> as defining the MUST.
>> >>
>> >> In general, it's best to avoid using 2119/8174 keywords to talk about external
>> >> requirements, except as a direct quote. I think this is especially true here
>> >> given the interdependencies between drafts in cluster 238. If in the future we
>> >> update a dependency to change a normative requirement, we risk creating
>> >> conflicts, and we make it unclear which text is authoritative.
>> >>
>> > Generally, this is pointing the reader at a particular normative section,
>> >    and saying that yeah, you MUST follow that section as written. Perhaps
>> >    the use of 2119 language here isn't ideal, but I don't see this as
>> >    confusing. Do you have a suggestion about how this should be handled instead?
>> 
>> It’s a technicality, but it can create confusion about which text is authoritative. That’s not an issue as long as both are in agreement, but future updates to either this or that spec can easily mess up that agreement.
>> 
>> My personal preference is to reserve 2119/8174 keywords for the text that is authoritative for the requirement, and to have other text that refers to that requirement do it descriptively. For example, “RFC XXXX mandates foo”.
>> 
> I guess this is a matter of opinion.
> I think that it's useful to list the rules here using
> 2119 language. I think the text makes clear that in this construction it's the
> RFC that we are pointing to that's authoritative.
> 

Well, yes, I stated my opinion. To further clarify that opinion: Having a given MUST/SHOULD/etc in more than one place makes updates error prone. If we update the language in dependency in the future, we may also need to update this draft. People updating the dependency may not even be aware of this draft. And yes, I realize this concern is highly dependent on the “what does it mean to update an RFC” philosophical discussion that never seems to resolve.

In any case, it’s not a blocking comment; people are free to ignore it.

>> >
>> >> -5.8.3: The MUSTs in this section seem to be putting requirements on the SDP
>> >> being parsed. Shouldn't they instead describe the parser's behavior based on
>> >> that SDP input? The correctness of the SDP being parsed seems beyond the
>> >> control of the implementation.
>> >>
>> > Yes, the correctness of the SDP is beyond the control of the impl, but,
>> > the handling of broken SDP is spelled out in the beginning of this section:
>> >
>> >         If any line is not well-formed, or cannot be parsed as
>> >         described, the parser MUST stop with an error and reject the
>> >         session description, even if the value is to be discarded. This
>> >         ensures that implementations do not accidentally misinterpret
>> >         ambiguous SDP.
>> >
>> > Saying that a specific line MUST have X and Y is then a shorthand for
>> > repeatedly saying that if the line cannot be parsed properly, the impl MUST
>> > stop with an error.
>> 
>> Again, I don’t think the use of 2119/8174 keywords for things beyond the control of the implementation fits the sense of those documents. I suggest either stating these without 2119/8174 keywords, or adding something to the boilerplate to the effect of “When used in to describe requirements for SDP inputs, these terms indicate requirements for that SDP to be considered well-formed”.
>> 
> I'm comfortable with the current language….

Again, non-blocking comment….

Ben.