RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 3 records.

Status: Verified (1)

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

Source of RFC: mmusic (rai)

Errata ID: 2247
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Riccardo Bernardini
Date Reported: 2010-05-06
Verifier Name: Robert Sparks
Date Verified: 2011-02-07

Section 3.2 says:

key-mgmt-spec = "prot" "=" KMPID ";" ["uri" "=" %22 URI %22 ";"] 

It should say:

key-mgmt-spec = "prot" "=" KMPID ";" ["uri" "=" %22 URI %22 ";"] ["data" "=" %22 base64 %22 ";"]

Notes:

There is an inconsistency between the ABNF for key-mgmt-spec on page 6 and the two SETUP examples on top of page 21. In both examples a field data="..." is present in the keymgmt header, but the ABNF on page 6 does not allow for it. The suggested correction solves the inconsistency.


--- From reviewer Dale Worley --
The grammar needs additional work because key-mgmt-spec is not
correctly attached to the original ABNF, and the production provided
does not allow the parameters to appear in any order. In addition,the
terminating CRLF is not shown in the ABNF. A more correct version is:

extension-header =/ KeyMgmt
(Is this the correct nonterminal to extend? RFC 4567 section 3.2 does
not make it clear what sort of header "KeyMgmt" is.)

KeyMgmt = "KeyMgmt" ":" key-mgmt-spec 0*("," key-mgmt-spec) CRLF

key-mgmt-spec = "prot" "=" KMPID 0*(key-mgmt-spec-param)

key-mgmt-spec-param = ";" "uri" "=" %22 URI %22
/ ";" "data" "=" %22 base64 %22

The whole situation is troublesome because the RFC does not make it
clear to what degree the 'prot', 'uri', and 'data' elements are
required to be in a certain order. Given that many headers are copied
from HTTP, the implication is that the first element (that is,
"prot=KMPID") must appear in the first position, but the following
elements ("uri" and "data") may be in any order. But current practice
may have de-facto standardized a different rule. We need some input
from someone who is familiar with current practice.

------
The MMUSIC WG list was polled and the responses were that allowing these parameters to appear in any order was an acceptable technical solution.

Status: Held for Document Update (2)

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

Source of RFC: mmusic (rai)

Errata ID: 56
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

The abstract 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.

Notes:

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.

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



Advanced Search