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

[<[e-mail]>]

Hi Ben,
Thank you for guidance.
The draft which updates 7976 is already existing:

https://tools.ietf.org/html/draft-jesske-update-p-visited-network-00

The content of this draft is at least the following text:
3<https://tools.ietf.org/html/draft-jesske-update-p-visited-network-00#section-3>.  Applicability of P-Visited-Network-ID in responses


   In [RFC7976] section 3<https://tools.ietf.org/html/rfc7976#section-3>.  "Updates to RFC 7315<https://tools.ietf.org/html/rfc7315>" the P-Visited-Network-
   ID header field was restricted to the following: The P-Visited-
   Network-ID header field can appear in all SIP methods except ACK,
   BYE, CANCEL, NOTIFY, PRACK, INFO, and UPDATE.  This document allows
   the use of the P-Visited-Network-ID header field additionally within
   Responses as follows: Any SIP Response message, except for a 100
   (Trying), MAY contain a P-Visited-Network-ID header field.  The P-
   Visited-Network-ID header field is not needed in the 100 (Trying)
   responses, since they are transmitted hop by hop, not end to end.

This draft is already cited within 3GPP TS 24.229.
Question for me is if it is better to have it as is above or as I have written it within the errata?
When this is clear then  I will do an update of the draft.
Best Regards

Roland

Von: sipcore <[e-mail]> Im Auftrag von Ben Campbell
Gesendet: Dienstag, 4. Dezember 2018 19:18
An: Jesske, Roland <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Betreff: ***CAUTION_Invalid_Signature*** Re: [sipcore] [Technical Errata Reported] RFC7976 (5393)

To be clear, you do not have to create a full 7976bis draft that would obsolete 7976. One can create a very short draft that updates 7976 by just describing the change. ( I don’t have strong feelings either way; while a “bis” draft might be a little easier for readers, an “updates” draft is much easier to work through the process for minor updates.)

Thanks!

Ben.



On Dec 4, 2018, at 1:53 AM, <[e-mail]<mailto:[e-mail]>> <[e-mail]<mailto:[e-mail]>> wrote:

Hi Ben,
thinking through I think it is better, as you proposed, to update the draft itself
So if I get the files form Christer I can create an new RFC7976bis which would be the easiest way.

To update RFC7315bis would possibly lead in an longer discussion and publication phase as an RFC7976bis approach.

@Atle/Peter/Georg: any thoughts from 3GPP side?

Thank you and Best Regards.

Roland



Von: Ben Campbell <[e-mail]<mailto:[e-mail]>>
Gesendet: Montag, 3. Dezember 2018 15:10
An: Jesske, Roland <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Betreff: Re: [sipcore] [Technical Errata Reported] RFC7976 (5393)

Hi Roland,

I don’t recall if we discussed whether the errata represented something that should have been in the RFC when original published vs a change since the RFC was published.    Do you have thoughts on that?

Do you expect the document(s) that depend on the RFC to explicitly cite the errata report?

Thanks!

Ben.

On Dec 3, 2018, at 6:50 AM, <[e-mail]<mailto:[e-mail]>> <[e-mail]<mailto:[e-mail]>> wrote:
Hi Ben,
thank you for your guidance.
We have discussed this during the 3GPP coordination meeting in Singapore.
Because in 3GPP we have an dependency which points to draft-jesske-update-p-visited-network-00.

At that time the proposal was to write an errata to the RFC but I’m also willing to update the RFC 7976 from Christer.
Or we update RFC 7315 which is describing the whole 3GPP P- headers.

So I’m willing to do either way.

Best Regards

Roland

Von: sipcore <[e-mail]<mailto:[e-mail]>> Im Auftrag von Ben Campbell
Gesendet: Freitag, 30. November 2018 22:51
An: RFC Errata System <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; Gonzalo Salgueiro (gsalguei) <[e-mail]<mailto:[e-mail]>>; Jesske, Roland <[e-mail]<mailto:[e-mail]>>; IESG <[e-mail]<mailto:[e-mail]>>
Betreff: ***CAUTION_Invalid_Signature*** Re: [sipcore] [Technical Errata Reported] RFC7976 (5393)

(+ 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 <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>>
>
> 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
>
_______________________________________________
sipcore mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/sipcore