Subject: RFC 4567 issues and errata

From: Alfred Hönes <[email-masked]>
Date: Wed, 1 Nov 2006 14:01:44 +0100 (MEZ)

Hello,
reading the recently published RFC 4567 (Key Mgmt Extn's for
SDP and RTSP), I found a couple of issues and textual flaws
I'd like to report.

In the first part of the list below, I have collected more
significant items, whereas the second part, item (7) ff.,
lists simple textual issues (typos and grammar).

(1)  wrong protocol named in 'Abstract'

In the second paragraph of the Abstract, on page 1, RFC 4567 says:

   General guidelines are also given on how the framework should be used
   together with SIP and RTSP.  The usage with the Multimedia Internet
   KEYing (MIKEY) key management protocol is also defined.

It should say:

   General guidelines are also given on how the framework should be used
|  together with SIP and SAP.  The usage with the Multimedia Internet
   KEYing (MIKEY) key management protocol is also defined.

Rationale: As can be seen from the title and the body of the RFC, and
as has been correctly stated in the first paragraph of the Abstract,
the RFC primarily deals with SDP and RTSP; it "also" considers the use
of the SDP extensions with SIP (Section 4.1.2) and SAP (Section 4.1.3).
Hence, SAP should be mentioned in the second paragraph of the Abstract
instead of RTSP.

(2)  inappropriate text (cut&paste error?)

On page 6, the explanation below the ABNF in Section 3.2 says:

   where KMPID is as defined in Section 3 of this memo, "base64" as
   defined in [SDPnew], and "URI" as defined in Section 3 of [RFC3986].

It should say:

   where KMPID is as defined in Section 3 of this memo and "URI" as
   defined in Section 3 of [RFC3986].

Rationale: "base64" does not appear in the ABNF of Section 3.2 !

(3)  incomplete sentence

The first paragraph of Section 4.1.1, on page 8, says:

   The processing when SDP is used is slightly different according to
   the way SDP is transported, and if it uses an offer/answer or
   announcement.  The processing can be divided into four different
   steps:

It should say:

   The processing when SDP is used is slightly different according to
   the way SDP is transported, and if it uses an offer/answer or
|  announcement model.  The processing can be divided into four
   different steps:

(4)  misleading word omission

Within Section 5.4, the explanation at top of page 21,

   Each RTSP header is inserted in the SETUP related to the audio and
   video separately:

should be clarified to say:

|  A key management RTSP header is inserted in the SETUP related to the
   audio and video separately:

(5)  suspected inconsistency

The last paragraph of Section 7, on page 22, says:

   The server will need to be able to know the identity of the client
   before creating and sending a MIKEY message.  [...]

IMHO, it is not clear how this fits with the text on page 14.
Perhaps, a 3-way handshake with client auth in DESCRIBE could
be considered.

(6)  inconsistency between ABNF and IANA registrations

Perhaps, a late change to the ABNF in the body of the RFC has lead
to inconsistencies in the filled out IANA registration templates
as presented in Section 9.1 and 9.3; in particular, the hypothetical
attribute name "key-mgmt-att-field" referred to in fact should be just
"key-mgmt"; "key-mgmt-att-field" is the name of the ABNF production
rule (introduced in  Section 3.1) for this literal; in the template
the literal name of the attribute is needed.

Therefore:

In Section 9.1, near the bottom of page 25, change

      SDP Attribute Field ("att-field"):

        Name:               key-mgmt-att-field

to say:

      SDP Attribute Field ("att-field"):

        Name:               key-mgmt

and in Section 9.3, on page 26, change

   Purpose:        Usage of MIKEY with the key-mgmt-att-field
                    attribute and the keymgmt RTSP header

to say:

|  Purpose:        Usage of MIKEY with the key-mgmt SDP attribute
                    and the keymgmt RTSP header

[ I also have added "SDP" for additional clarification. ]

(7)  missing articles

The first paragraph of the Abstract, on page 1 of RFC 4567, says:

   This document defines general extensions for Session Description
   Protocol (SDP) and Real Time Streaming Protocol (RTSP) to carry
   messages, as specified by a key management protocol, in order to
   secure the media.  [...]

It should say:

|  This document defines general extensions for the Session Description
|  Protocol (SDP) and the Real Time Streaming Protocol (RTSP) to carry
   messages, as specified by a key management protocol, in order to
   secure the media.  [...]

(8)  missing article

Near the top of page 7, the paragraph,

   We define one new RTSP status code to report error due to any failure
   during the key management processing (Section 4.2):

should say:

|  We define one new RTSP status code to report an error due to any
   failure during the key management processing (Section 4.2):

(9)  missing article

Within Section 4.2, the last bullet on page 15 says:

   * Key management responses for the initial establishment of security
     parameters for an individual media SHALL only be included in SETUP
     for the corresponding media stream.

It should say:

   * Key management responses for the initial establishment of security
|    parameters for an individual media SHALL only be included in the
     SETUP for the corresponding media stream.

(10)  typo (singular/plural mismatch)

Within Section 5.2, the explanation of the example, in the lower
half of page 19,

   The client checks the validity of the received MIKEY message, and, in
   case of successful verification, it accept the message.  [...]

should say:

   The client checks the validity of the received MIKEY message, and, in
|  case of successful verification, it accepts the message.  [...]

Please comment.

Preferrably, to address these issues, you should prepare an
Author's Errata Note for RFC 4567, making freely use of the
material presented above, and submit it to the RFC Editor
for publication on the RFC Errata web pages.

Best regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+