Whilst I agree this looks like repetition, what was the original intent? If the last sentence were written in the active voice, what would have been the subject? The offerer or the offerer's SIP proxy? - If the intent had been that the subject be the offerer, it is indeed repetition and should be deleted. - If the intent had been that the subject be the offerer's SIP proxy, then the proposed correction might make sense. However, I don't think this would have been the intent. The addition of an Identity header field by the offerer's SIP proxy provides the required integrity protection for the rest of the journey to the UAS. Any additional protection (by sending the entire message in a protected channel) is not a necessary part of this mechanism.
John > -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of RFC Errata System > Sent: 16 February 2011 07:28 > To: [email protected]; [email protected]; > [email protected]; [email protected]; > [email protected]; [email protected]; > [email protected] > Cc: [email protected]; [email protected]; [email protected] > Subject: [Sip] [Editorial Errata Reported] RFC5763 (2723) > > > The following errata report has been submitted for RFC5763, > "Framework for Establishing a Secure Real-time Transport > Protocol (SRTP) Security Context Using Datagram Transport > Layer Security (DTLS)". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=5763&eid=2723 > > -------------------------------------- > Type: Editorial > Reported by: sent to answer's sip proxy <[email protected]> > > Section: clause 5 > > Original Text > ------------- > The endpoint SHOULD send the SIP message containing the offer > to the offerer's SIP proxy over an integrity protected > channel. The proxy SHOULD add an Identity header field > according to the procedures outlined in [RFC4474]. The SIP > message containing the offer SHOULD be sent to the offerer's > SIP proxy over an integrity protected channel. > > Corrected Text > -------------- > The endpoint SHOULD send the SIP message containing the offer > to the offerer's SIP proxy over an integrity protected > channel. The proxy SHOULD add an Identity header field > according to the procedures outlined in [RFC4474]. The SIP > message containing the offer SHOULD be sent to the answer's > SIP proxy over an integrity protected channel. > > Notes > ----- > the original text seems to be repetitive. > > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC5763 (draft-ietf-sip-dtls-srtp-framework-07) > -------------------------------------- > Title : Framework for Establishing a Secure > Real-time Transport Protocol (SRTP) Security Context Using > Datagram Transport Layer Security (DTLS) > Publication Date : May 2010 > Author(s) : J. Fischl, H. Tschofenig, E. Rescorla > Category : PROPOSED STANDARD > Source : Session Initiation Protocol > Area : Real-time Applications and Infrastructure > Stream : IETF > Verifying Party : IESG > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is essentially closed and only used for finishing > old business. > Use [email protected] for questions on how to > develop a SIP implementation. > Use [email protected] for new developments on the application of sip. > Use [email protected] for issues related to maintenance of the > core SIP specifications. > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is essentially closed and only used for finishing old business. Use [email protected] for questions on how to develop a SIP implementation. Use [email protected] for new developments on the application of sip. Use [email protected] for issues related to maintenance of the core SIP specifications.
