Document: draft-ietf-sipcore-rfc7976bis Title: Updates to Private Header (P-Header) Extension Usage in Session Initiation Protocol (SIP) Requests and Responses Reviewer: Daniel Migault Review result: Has Nits Hi, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. I am not particularly acquainted with SIP; however, I would find it clearer if it were explicitly specify that the information were transmitted through a channel that offers integrity protection. That being said, I concur that this is addressed in 7315. My interpretation of this text is that 7315 outlines security considerations regarding the "P-" header fields, as well as the security considerations related to the transport of the messages that contain these fields. More specifically, the security considerations in 7315 remain independent of the type of message that carries the "P-" header. Since this specification updates the messages that include these "P-" header fields, the same security considerations apply here. Once this has been clarified, I feel that the remaining text reiterates 7315 and could be omitted. The only additional aspect that appears to warrant discussion is the interaction between 7315 and this specification. Once again, I am not well-versed in SIP, but the text seems somewhat underdefined to me. If there is an agreement between 7315 and this specification, then we should not encounter interoperability issues. Conversely, if that is not the case, we may need to address scenarios where an anticipated "P-" header field is absent, as well as situations where an unexpected "P-" field is present. I would be keen to learn how SIP manages unexpected fields. More specifically, I would like to comprehend whether the "P-" field is disregarded, if an error message is generated, or if an error is logged... in order to assess how this specification should address interoperability with 7315 and whether the non-updated 7315 can work in conjunction with the current specification. I would probably expect more guidance in the section. It is likely that the scenario where an expected "P-" header is anticipated but not found is more problematic. I would probably expect more guidance in the section. Yours, Daniel -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
