Re: [sipcore] [Technical Errata Reported] RFC7976 (5393)

Ben Campbell <ben@nostrum.com> Fri, 30 November 2018 21:50 UTC

Return-Path: <ben@nostrum.com>
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D671131066; Fri, 30 Nov 2018 13:50:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.879
X-Spam-Level:
X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7xNZW1Q9PKQg; Fri, 30 Nov 2018 13:50:46 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C07D131065; Fri, 30 Nov 2018 13:50:46 -0800 (PST)
Received: from [10.0.1.24] (cpe-70-122-203-106.tx.res.rr.com [70.122.203.106]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id wAULocm6008659 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 30 Nov 2018 15:50:40 -0600 (CST) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-203-106.tx.res.rr.com [70.122.203.106] claimed to be [10.0.1.24]
From: Ben Campbell <ben@nostrum.com>
Message-Id: <E1B0A2AE-213D-431E-9BC1-0FC30E51A4B9@nostrum.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_809B0AA9-122A-4221-85B4-5DAB12E6F2C2"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\))
Date: Fri, 30 Nov 2018 15:50:38 -0600
In-Reply-To: <20180615064001.1C57BB81ABD@rfc-editor.org>
Cc: Christer Holmberg <christer.holmberg@ericsson.com>, nevenka.biondic@ericsson.com, "Gonzalo Salgueiro (gsalguei)" <gsalguei@cisco.com>, IESG <iesg@ietf.org>, r.jesske@telekom.de, sipcore@ietf.org, sipcore-chairs@ietf.org
To: RFC Errata System <rfc-editor@rfc-editor.org>
References: <20180615064001.1C57BB81ABD@rfc-editor.org>
X-Mailer: Apple Mail (2.3445.101.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sipcore/86gDbPVcITa4HH4Mg3qLh0LbCMQ>
Subject: Re: [sipcore] [Technical Errata Reported] RFC7976 (5393)
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: SIP Core Working Group <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sipcore/>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 30 Nov 2018 21:50:48 -0000

(+ sipcore and chairs)

Hi Roland,

When you say the 3GPP identified the need to send P-Visited-Network-ID in responses; was that an error in RFC7976 at the time of publication, or something that was realized after the RFC was published?

The former makes sense for an erratum. But situations where an RFC expresses the intent of the authors at the time of publication, but we learn later that we should have done something different are not appropriate for errata; those usually need us to update (or obsolete) the RFC through the usual processes.

Thanks!

Ben.


> On Jun 15, 2018, at 1:40 AM, RFC Errata System <rfc-editor@rfc-editor.org> wrote:
> 
> The following errata report has been submitted for RFC7976,
> "Updates to Private Header (P-Header) Extension Usage in Session Initiation Protocol (SIP) Requests and Responses".
> 
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata/eid5393
> 
> --------------------------------------
> Type: Technical
> Reported by: Roland Jesske <r.jesske@telekom.de>
> 
> Section: 3
> 
> Original Text
> -------------
> 3.  Updates to RFC 7315
> 
>   This section implements the update to Section 5.7 of RFC 7315, in
>   order to implement the misalignment fixes and the 3GPP requirements
>   described in Section 2.
> 
>   Old text:
> 
>   The P-Associated-URI header field can appear in SIP REGISTER method
>   and 2xx resonses [sic].  The P-Called-Party-ID header field can
>   appear in SIP INVITE, OPTIONS, PUBLISH, SUBSCRIBE, and MESSAGE
>   methods and all responses.  The P-Visited-Network-ID header field can
>   appear in all SIP methods except ACK, BYE, and CANCEL and all
>   responses.  The P-Access-Network-Info header field can appear in all
>   SIP methods except ACK and CANCEL.  The P-Charging-Vector header
>   field can appear in all SIP methods except CANCEL.  The
>   P-Charging-Function-Addresses header field can appear in all SIP
>   methods except ACK and CANCEL.
> 
>   New text:
> 
>   The P-Associated-URI header field can appear in SIP REGISTER 2xx
>   responses.  The P-Called-Party-ID header field can appear in the SIP
>   INVITE, OPTIONS, PUBLISH, REFER, SUBSCRIBE, and MESSAGE methods.  The
>   P-Visited-Network-ID header field can appear in all SIP methods
>   except ACK, BYE, CANCEL, NOTIFY, PRACK, INFO, and UPDATE.  The
>   P-Access-Network-Info header field can appear in all SIP methods and
>   non-100 responses, except in CANCEL methods, CANCEL responses, and
>   ACK methods triggered by non-2xx responses.  The P-Charging-Vector
>   header field can appear in all SIP methods and non-100 responses,
>   except in CANCEL methods, CANCEL responses, and ACK methods triggered
>   by non-2xx responses.  The P-Charging-Function-Addresses header field
>   can appear in all SIP methods and non-100 responses, except in CANCEL
>   methods, CANCEL responses, and ACK methods.
> 
> Corrected Text
> --------------
> 3.  Updates to RFC 7315
> 
>   This section implements the update to Section 5.7 of RFC 7315, in
>   order to implement the misalignment fixes and the 3GPP requirements
>   described in Section 2.
> 
>   Old text:
> 
>   The P-Associated-URI header field can appear in SIP REGISTER method
>   and 2xx resonses [sic].  The P-Called-Party-ID header field can
>   appear in SIP INVITE, OPTIONS, PUBLISH, SUBSCRIBE, and MESSAGE
>   methods and all responses.  The P-Visited-Network-ID header field can
>   appear in all SIP methods except ACK, BYE, and CANCEL and all
>   responses.  The P-Access-Network-Info header field can appear in all
>   SIP methods except ACK and CANCEL.  The P-Charging-Vector header
>   field can appear in all SIP methods except CANCEL.  The
>   P-Charging-Function-Addresses header field can appear in all SIP
>   methods except ACK and CANCEL.
> 
>   New text:
> 
>   The P-Associated-URI header field can appear in SIP REGISTER 2xx
>   responses.  The P-Called-Party-ID header field can appear in the SIP
>   INVITE, OPTIONS, PUBLISH, REFER, SUBSCRIBE, and MESSAGE methods.  The
>   P-Visited-Network-ID header field can appear in all SIP methods
>   except ACK, BYE, CANCEL, NOTIFY, PRACK, INFO, and UPDATE and all
>   responses exept 100.  The
>   P-Access-Network-Info header field can appear in all SIP methods and
>   non-100 responses, except in CANCEL methods, CANCEL responses, and
>   ACK methods triggered by non-2xx responses.  The P-Charging-Vector
>   header field can appear in all SIP methods and non-100 responses,
>   except in CANCEL methods, CANCEL responses, and ACK methods triggered
>   by non-2xx responses.  The P-Charging-Function-Addresses header field
>   can appear in all SIP methods and non-100 responses, except in CANCEL
>   methods, CANCEL responses, and ACK methods.
> 
> Notes
> -----
> The Third Generation Partnership Project (3GPP) has identified cases
>   where the private header field P-Visited-Network-ID SIP private
>   header extensions, which is defined in RFC 7315 and updated by RFC
>   7976, needs to be included in SIP requests and responses.  This
>   eratta updates RFC 7976, in order to allow inclusion of the P-
>   Visited-Network-ID header field in responses exept 100.
> The issue was also discussed within a 3GPP - IETF coordination meeting.
> 
> Instructions:
> -------------
> This erratum 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
> can log in to change the status and edit the report, if necessary.
> 
> --------------------------------------
> RFC7976 (draft-holmberg-dispatch-rfc7315-updates-09)
> --------------------------------------
> Title               : Updates to Private Header (P-Header) Extension Usage in Session Initiation Protocol (SIP) Requests and Responses
> Publication Date    : September 2016
> Author(s)           : C. Holmberg, N. Biondic, G. Salgueiro
> Category            : INFORMATIONAL
> Source              : IETF - NON WORKING GROUP
> Area                : N/A
> Stream              : IETF
> Verifying Party     : IESG
>