RE: 3gpp-analysis-05: editorial issues

[Pekka Savola <pekkas@netcore.fi>]

On Mon, 22 Sep 2003 juha.wiljakka@nokia.com wrote:
> Some comments (JW) on the editorial issues:

Just replying to a few remaining issues.

>     OTA         Over The Air 
> 
> ==> s/The/the/?
> ==> one should probably expand this a bit, because a reader not intimate
> with 3GPP doesn't know what OTA refers to ("configuration protocol named
> OTA?", "interface named OTA?", "generic reference to something done over the
> air?")
> 
>  JW: My solution proposal: I just write "over the air" in the text and do not use 
> that abbreviation at all. This abbreviation is not anyhow relevant from this
> document point of view. Usual meaning for OTA is to send some configuration
> information using SMS.

Agreed, just removing the abbreviation etc. might be best as it really 
isn't so important piece of the specification.

>  1.3 Terminology
> 
> ==> as SHOULD/MUST use was added, in section 2.4, one should also add the
> terminology blurb on what those mean and refer to RFC2026.
> 
>  JW: Another alternative is to write this text in 2.4 with lower case (question: 
> Informational docs do not use capitalized keywords, but how is it in BCP docs?)
> If that text will stay here in capital letters, I can add terminology part.

BCP could have upper caps (as well as specific kinds of informational 
documents).  The problem here is that you're quoting directly what it says 
in the DNStrans document.  So, changing it in this document might not be 
appropriate.

So, I think there may be three ways around this issue:
 - define RFC2026 keywords,
 - just convert the uppercases to lowercases, or
 - in section 2.4, state it more clearly that the recommendations have 
been copied verbatim from DNStrans (which might imply that DNStrans is the 
authorative source here, not the uppercases in this document)

>     As control (or signaling) and user (or data) traffic are separated  
>     in SIP, and thus, the IMS, the translation of the IMS traffic has
>     to be done on two levels - Session Initiation Protocol (SIP)
>     [RFC3261], and Session Description Protocol (SDP) [RFC2327]
>     [RFC3266] on the one hand (Mm-interface), and on the actual user
>     data traffic level on the other (Mb-interface).
> 
> ==> reword "hand" ? ("interface") ?
> 
>  JW: Well, maybe writing interface changes the idea a little bit, how about:
> 
>     " ...the translation of the IMS traffic has
>     to be done at two levels:  1) Session Initiation Protocol (SIP)
>     [RFC3261], and Session Description Protocol (SDP) [RFC2327]
>     [RFC3266] (Mm-interface), and 2) the user
>     data traffic (Mb-interface)."

sounds good.

>  7. Changes from draft-ietf-v6ops-3gpp-analysis-04.txt
>  8. Intellectual Property Statement
>  9. Copyright
> 
> ==> these sections could be after the Editor's contact information section,
> but that isn't really set in stone.
> 
>  JW:  Looking at v6ops and other wg drafts, there seems not to be a
> common practice.. Until you can show me a clear rule, I will keep the order
> as it is now - and let RFC editor make the needed changes.  :-)

There is no strict rule of this, but ID-nits lists these in that order 
(and in most cases, that's what seems to make the most sense to me, 
because those are sections that will be either removed at publication or 
stay the same across all I-Ds):

http://www.ietf.org/ID-nits.html

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings