idnits 2.17.1 draft-jesske-update-p-visited-network-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. -- The abstract seems to indicate that this document updates RFC7976, but the header doesn't have an 'Updates:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 24, 2020) is 1241 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC8174' is mentioned on line 86, but not defined == Unused Reference: 'TS24-229' is defined on line 143, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 dispatch R. Jesske 3 Internet-Draft Deutsche Telekom 4 Updates: RFC7976 (if approved) November 24, 2020 5 Intended status: Informational 6 Expires: May 28, 2021 8 Update to Private Header Field P-Visited-Network-ID in Session 9 Initiation Protocol (SIP) Requests and Responses 10 draft-jesske-update-p-visited-network-02.txt 12 Abstract 14 The Third Generation Partnership Project (3GPP) has identified cases 15 where the private header field P-Visited-Network-ID SIP private 16 header extensions, which is defined in RFC 7315 and updated by RFC 17 7976, needs to be included in SIP requests and responses. This 18 document updates RFC 7976, in order to allow inclusion of the P- 19 Visited-Network-ID header field in responses. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on May 28, 2021. 38 Copyright Notice 40 Copyright (c) 2020 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 57 3. Applicability of P-Visited-Network-ID in responses . . . . . 2 58 4. Security Considerations . . . . . . . . . . . . . . . . . . . 3 59 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 3 60 6. Normative References . . . . . . . . . . . . . . . . . . . . 3 61 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 4 63 1. Introduction 65 The Third Generation Partnership Project (3GPP) has identified cases 66 where different Session Initiation Protocol (SIP) [RFC3261] private 67 header extensions referred to as "P-" header fields, and defined in 68 [RFC7315], need to be included in SIP requests and responses which is 69 currently not allowed according to [RFC7315]. This document updates 70 [RFC7315], to allow the inclusion of the affected "P-" header fields 71 in such requests and responses. This document also makes updates for 72 [RFC7976] to fix misalignments that occurred when [RFC7315] was 73 updated for specific "P-" header fields which are mainly used in (and 74 in most cases, only defined for) networks defined by the 3GPP. The 75 updates defined in this document will not cause backward- 76 compatibility problems in 3GPP networks which are using 77 [TS.3GPP.24.229]. 79 2. Terminology 81 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 82 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 83 "OPTIONAL" in this document are to be interpreted as described in BCP 84 14 [RFC2119] [RFC8174] when, and only when, they appear in all 85 capitals, as shown here. 87 3. Applicability of P-Visited-Network-ID in responses 89 In [RFC7976] section 3. "Updates to RFC 7315" the P-Visited-Network- 90 ID header field was restricted to the following: The P-Visited- 91 Network-ID header field can appear in all SIP methods except ACK, 92 BYE, CANCEL, NOTIFY, PRACK, INFO, and UPDATE. This document allows 93 the use of the P-Visited-Network-ID header field additionally within 94 Responses as follows: Any SIP Response message, except for a 100 95 (Trying), MAY contain a P-Visited-Network-ID header field. The P- 96 Visited-Network-ID header field is not needed in the 100 (Trying) 97 responses, since they are transmitted hop by hop, not end to end. 99 4. Security Considerations 101 The security considerations for these "P-" header fields are defined 102 in [RFC7315]. This specification allows some header fields to be 103 present in messages where they were previously not allowed, and the 104 security considerations and assumptions described in [RFC7315] (e.g., 105 regarding only sending information to trusted entities) also apply to 106 those messages. That does not cause any security issues, but 107 implementors need to be aware that implementations may not have been 108 updated according to this document, and take proper actions if a 109 header field does not occur, in a message where it should occur or 110 occurs in a message where it should not occur. The security and 111 privacy considerations for the P-Visited-Network-ID header field are 112 similar to those for the other SIP responses discussed in [RFC7315]. 114 5. Acknowledgments 116 The author would like to acknowledge the constructive feedback 117 provided by Michael Kreipl 119 6. Normative References 121 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 122 Requirement Levels", BCP 14, RFC 2119, 123 DOI 10.17487/RFC2119, March 1997, 124 . 126 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 127 A., Peterson, J., Sparks, R., Handley, M., and E. 128 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 129 DOI 10.17487/RFC3261, June 2002, 130 . 132 [RFC7315] Jesske, R., Drage, K., and C. Holmberg, "Private Header 133 (P-Header) Extensions to the Session Initiation Protocol 134 (SIP) for the 3GPP", RFC 7315, DOI 10.17487/RFC7315, July 135 2014, . 137 [RFC7976] Holmberg, C., Biondic, N., and G. Salgueiro, "Updates to 138 Private Header (P-Header) Extension Usage in Session 139 Initiation Protocol (SIP) Requests and Responses", 140 RFC 7976, DOI 10.17487/RFC7976, September 2016, 141 . 143 [TS24-229] 144 3rd Generation Partnership Project, "3rd Generation 145 Partnership Project; Technical Specification Group Core 146 Network and Terminals; IP multimedia call control protocol 147 based on Session Initiation Protocol (SIP) and Session 148 Description Protocol (SDP); Stage 3", TS 24.229, V 14.4.0, 149 March 2017. 151 Author's Address 153 Roland Jesske 154 Deutsche Telekom 155 Heinrich-Hertz Str. 3-7 156 Darmstadt 64295 157 Germany 159 Email: r.jesske@telekom.de 160 URI: www.telekom.de