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

[Eric Rescorla <[e-mail]>]

Just for maximum clarity: given that these comments are non-blocking, my
intent is to leave the document as-is, subject to strong opinions by my
co-authors.

On Tue, Jan 2, 2018 at 4:29 PM, Ben Campbell <[e-mail]> wrote:

>
> […]
>
> > >
> >> >> -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.
>