[Sipping] Errata report on errata 2123 through 2126 on RFC5479 ("Requirements and Analysis of Media Security Management Protocols")

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



======================================================================
RFC5479, "Requirements and Analysis of Media Security Management Protocols"
Source of RFC: sip (rai)

Errata ID: 2123

Status: Reported
Type: Editorial

Reported By: Alfred Hoenes
Date Reported: 2010-04-05

Section A.1.7 says:

[[ second paragraph: ]]

   With this proposal, the ECDSA signature, MIKEY-ECIES, and MIKEY-ECMQV
|  function exactly like MIKEY-RSA, and the new DH-Group code function
   exactly like MIKEY-DHSIGN.  Therefore, these ECC mechanisms are not
   discussed separately in this document.


It should say:

   With this proposal, the ECDSA signature, MIKEY-ECIES, and MIKEY-ECMQV
|  function exactly like MIKEY-RSA, and the new DH-Group code functions
   exactly like MIKEY-DHSIGN.  Therefore, these ECC mechanisms are not
   discussed separately in this document.


Notes:

Rationale: singular/plural mismatch -- keep for update!
----------------------------------------------------------------------
Recommended status:  (correct) Hold for document update
======================================================================
RFC5479, "Requirements and Analysis of Media Security Management Protocols"
Source of RFC: sip (rai)

Errata ID: 2124

Status: Reported
Type: Editorial

Reported By: Alfred Hoenes
Date Reported: 2010-04-05

Section A.1.11 says:

   MIKEYv2 [MIKEYv2] adds mode negotiation to MIKEYv1 and removes the
   time synchronization requirement.  It therefore now takes 2 round
   trips to complete.  In the first round trip, the communicating
   parties learn each other's identities, agree on a MIKEY mode, crypto
|  algorithm, SRTP policy, and exchanges nonces for replay protection.
   In the second round trip, they negotiate unicast and/or group SRTP
   context for SRTP and/or SRTCP.


It should say:

   MIKEYv2 [MIKEYv2] adds mode negotiation to MIKEYv1 and removes the
   time synchronization requirement.  It therefore now takes 2 round
   trips to complete.  In the first round trip, the communicating
   parties learn each other's identities, agree on a MIKEY mode, crypto
|  algorithm, SRTP policy, and exchange nonces for replay protection.
   In the second round trip, they negotiate unicast and/or group SRTP
   context for SRTP and/or SRTCP.


Notes:

Rationale: singular/plural mismatch -- keep for update!
----------------------------------------------------------------------
Recommended status:  (correct) Hold for document update
======================================================================
RFC5479, "Requirements and Analysis of Media Security Management Protocols"
Source of RFC: sip (rai)

Errata ID: 2125

Status: Reported
Type: Editorial

Reported By: Alfred Hoenes
Date Reported: 2010-04-05

Section A.4.3 says:

|  In SRTP, a cryptographic context is defined as the SSRC, destination
|  network address, and destination transport port number.  Whereas RTP,
|  a flow is defined as the destination network address and destination
   transport port number.  This results in a problem -- how to
   communicate the SSRC so that the SSRC can be used for the
   cryptographic context.


It should say:

|  In SRTP, a cryptographic context is defined by the SSRC, destination
|  network address, and destination transport port number, whereas in RTP,
|  a flow is defined by the destination network address and destination
   transport port number.  This results in a problem -- how to
   communicate the SSRC so that the SSRC can be used for the
   cryptographic context.


Notes:

Rationale: clarification/language improvement -- keep for update!
----------------------------------------------------------------------
Recommended status:  (correct) Hold for document update

Given the terminology in RFC 3711 ("SRTP") section 3.2, a better
phrase would be "determined by" -- an SRTP security context is
*identified* by these data but *contains* the various crypto
parameters.
======================================================================
RFC5479, "Requirements and Analysis of Media Security Management Protocols"
Source of RFC: sip (rai)

Errata ID: 2126

Status: Reported
Type: Editorial

Reported By: Alfred Hoenes
Date Reported: 2010-04-05

Section A.5.3 says:

[[ 4th paragraph: ]]

   Currently, several techniques are commonly considered as candidates
|  to provide opportunistic encryption:


It should say:

   Currently, several techniques are commonly considered as candidates
|  to provide best effort encryption:


Notes:

Rationales: consistency with section headline.
----------------------------------------------------------------------
Recommended status:  (correct) Hold for document update

Although "opportunistic" may be a good choice in this situation.
======================================================================

Dale
_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip
Use sip@xxxxxxxx for new developments of core SIP


[Index of Archives]     [IETF Announce]     [IETF Discussion]     [Linux SCSI]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Big List of Linux Books]

  Powered by Linux