RFC 4567, "Key Management Extensions for Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP)", July 2006

Errata ID: 809
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-11-01
Held for Document Update by: Robert Sparks

(1) [[posted separately.]]
 
(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.  [...]

Notes:

from pending

Report New Errata