======================================================================
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
