Re: [rtcweb] 2119 language in requirements (Re: Review of draft-ietf-rtcweb-use-cases-and-requirements-10 (Part I))

Where the document is an informational document containing only the requirements, I don't think it matters whether upper case or lower case is used. The field of application of such a requirements document is the resultant solution / specification documents, rather than the implementor directly.

The issue is more difficult where requirements and solution are mixed in the same document, but that does not apply in this case. Where I have dealt with drafts that fall into this case before, we have moved the requirements to an appendix to make very clear they are informative.

Keith

> -----Original Message-----
> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf
> Of Spencer Dawkins
> Sent: 07 February 2013 20:29
> To: rtcweb@ietf.org
> Subject: Re: [rtcweb] 2119 language in requirements (Re: Review of draft-
> ietf-rtcweb-use-cases-and-requirements-10 (Part I))
> 
> On 2/1/2013 3:15 PM, Bernard Aboba wrote:
> > I cannot find an RFC that deals with normative language in requirements
> documents specifically. Part of the reason for that may be that
> requirements documents are by no means uniform.  Some are created to
> assist in making a selection between competing protocols.  Some are just
> created to inform subsequent WG protocol design efforts.  Sometimes the
> eventual output is evaluated against the requirements, sometimes not.
> With such a level of variation, it is not clear me that "one size fits
> all".
> 
> I thought the IESG had done an IESG Statement on the use of normative
> language in Informational documents in general, but I'm not seeing that,
> either. I know it was discussed, but I'm not seeing that it was produced.
> 
> I also checked at the RFC Editor site, but what I found (example:
> http://www.rfc-editor.org/rfc-editor/instructions2authors.txt) doesn't
> provide guidance about 2119 for documents that aren't standards-track.
> 
> > Overall, I'd say it is up to IETF RTCWEB (and W3C WEBRTC) to decide how
> it wants the requirements document to be used, and this in turn will
> influence what the normative language will mean.  Judging by the number of
> issues we have had with requirements documents in the past (e.g. typically
> the understanding of the problem evolves considerably over time and often
> initially specified requirements are "overtaken by events"), we should be
> careful about setting expectations too high.
> 
> I agree with Bernard here.
> 
> Spencer
> 
> 
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb