Subject: Re: [payload] WGLC for draft-ietf-payload-rtp-howto-05

From: Magnus Westerlund <[email-masked]>
Date: Tue, 1 Oct 2013 17:10:55 +0200

On 2013-09-26 14:59, Ali C. Begen (abegen) wrote:
> 
> On Sep 26, 2013, at 3:04 PM, Magnus Westerlund <[email-masked]> wrote:
> 
>> On 2013-09-26 11:46, Ali C. Begen (abegen) wrote:
>>> Looks good to me except that there are bunch of lower-case 2119 keywords.
>>> Any possibility to avoid them or is it better to make them upper case?
>>
>> No, they should not be interpreted in the RFC 2119 upper case meaning.
>> This is an informative document and regular English interpretation are
>> fine.
> 
> yes, it is information and I keep forgetting that.
> 
>> I find it difficult to write without using may, should, recommend
>> and to some degree must. And removing these out of the document would be
>> a massive undertaking which I fail to see the benefit with.
>>
> I think putting a note somewhere around the intro part about the use of these keywords in lower case would be beneficial. 

I think we actually have bigger issue regarding RFC 2119 language. The
fact that we haven't discussed the usage of RFC 2119 language when
writing RTP payload formats.

Thus I propose the following section edits:

New section:

2.3.  Use of Normative Requirements Language

   As this document is an both of the informational category and being
   an instruction rather than a specification for something this
   document does not use any RFC 2119 language and the interpretation of
   may, should, recommended and must are the ones of the English
   language.

New last bullet:

4.1.4.  Writing Style

   When writing an IETF draft for an RTP payload format some few
   consideration on how to write in the IETF:

   Include Motivations:  It is common to include the motivation for why
      a particular design or technical choice was chosen.  These are not
      long statements, a sentence here and there explaining why.

   Use the Defined Terminology:  There exist defined terminology both in
      RTP and in the various media codecs.  A payload format
      specification do needs to use both to make clear the relation of
      features and their functions.

   Keeping It Simple:  IETF has a history of specifications that are
      focused on their main usage.  When it comes to RTP Payload formats
      that has a lot of modes and features the actually deployments has
      in most cases only include the most basic features that had very
      clear requirements.  Time and effort can be saved by only focusing
      on the most important use cases and keep the solution simple.

   Normative Requirements:  When writing specifications there are
      commonly need to make it clear when something is normative and at
      what level.  In IETF the most common method is to use "Key words
      for use in RFCs to Indicate Requirement Levels" [RFC2119] that
      defines the meaning of "MUST", "MUST NOT", "REQUIRED", "SHALL",
      "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
      RECOMMENDED", "MAY", and "OPTIONAL".

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------