Re: [sipcore] Activity proposal on: New Version Notification for draft-jesske-update-p-visited-network-03.txt

Hi,

For me, the draft is ready for RFC publication.

If there is any need for a revision, some proposed changes that might also be taken onboard: 

Section 3:

   In [RFC7976] section 3.  "Updates to RFC 7315" 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.  

It might be useful to provide at least one example of use of the header in the response, to motivate the need for the RFC update.

   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.

According to the text above "Any SIP Response message, except for a 100 (Trying)", I understand that "Not needed" should be replaced by "must not appear" or "should not appear", right?

Other comment:

In section 1 or Section 3, it might be useful to add a NOTE like:

   [RFC5727] deprecates the previous [RFC3427] guidance on the creation of "P-" header fields. 
   New proposals to document SIP header fields of an experimental or private nature are 
   supposed not to use the "P-" prefix.  However, this specification updates a private SIP header
   already registered and used in existing deployments and other standards. Therefore, the 
   recommendation given [RFC5727] does not apply here.

Regards,

Lionel

Orange Restricted

> -----Message d'origine-----
> De : Brian Rosen <br@brianrosen.net>
> Envoyé : vendredi 31 mars 2023 10:45
> À : SIPCORE <sipcore@ietf.org>
> Cc : A. Jean Mahoney <mahoney@nostrum.com>; MORAND Lionel INNOV/NET
> <lionel.morand@orange.com>; eckelcu@cisco.com; R.Jesske@telekom.de
> Objet : Re: [sipcore] Activity proposal on: New Version Notification for draft-
> jesske-update-p-visited-network-03.txt
> 
> Folks, this is a very short draft that seems to be a simple fix to an actual problem.
> Could you please review it and bring any issues you may have with it forward?
> Barring any such issues, chairs will start a WGLC soon.
> 
> Brian
> 
> 
> > On Mar 28, 2023, at 7:43 AM, R.Jesske@telekom.de wrote:
> >
> > Sorry,
> > missed to point to the mail archive with the recommendation out of the former
> days and what to do.
> >
> > https://mailarchive.ietf.org/arch/browse/sipcore/?gbt=1&q=P-visited
> >
> > So I would be happy to finalize the work and procced with the process.
> >
> > Thank you and Best Regards
> >
> > Roland
> >
> > -----Ursprüngliche Nachricht-----
> > Von: sipcore <sipcore-bounces@ietf.org> Im Auftrag von Jesske, Roland
> > Gesendet: Dienstag, 28. März 2023 06:30
> > An: sipcore@ietf.org; mahoney@nostrum.com; br@brianrosen.net
> > Cc: lionel.morand@orange.com; eckelcu@cisco.com
> > Betreff: Re: [sipcore] Activity proposal on: New Version Notification for draft-
> jesske-update-p-visited-network-03.txt
> >
> > Hi,
> > since we had today a F2F coordination meeting for 3GPP/IETF and discussed
> the dependencies.
> > There is still the dependency of an Draft meant to be informal for an description
> how a P-header should behave.
> >
> > Question is how we can pickup the activity again?
> >
> > https://datatracker.ietf.org/doc/draft-jesske-update-p-visited-network/
> >
> > It is a very small draft.
> >
> > Thank you and Best Regards
> >
> > Roland
> >
> > -----Ursprüngliche Nachricht-----
> > Von: Jesske, Roland
> > Gesendet: Montag, 31. Mai 2021 14:23
> > An: sipcore@ietf.org
> > Cc: lionel.morand@orange.com
> > Betreff: Activity proposal on: New Version Notification for draft-jesske-update-p-
> visited-network-03.txt
> >
> >
> > Dear all,
> > There is still an issue that is open with regard to dependencies we have with
> 3GPP.
> > Referring to:
> >
> >
> https://mailarchive.ietf.org/arch/msg/sipcore/86gDbPVcITa4HH4Mg3qLh0LbCMQ/
> >
> > It would be nice if we can take the activity now and finalize the below mentioned
> draft.
> >
> > Seen from 3GPP perspective it would be important to finalize this activity that we
> can proceed with the final solution.
> >
> > Thank you and Best Regards
> >
> > Roland
> >
> > -----Ursprüngliche Nachricht-----
> > Von: internet-drafts@ietf.org <internet-drafts@ietf.org>
> > Gesendet: Montag, 31. Mai 2021 14:16
> > An: Jesske, Roland <R.Jesske@telekom.de>
> > Betreff: New Version Notification for draft-jesske-update-p-visited-network-03.txt
> >
> >
> > A new version of I-D, draft-jesske-update-p-visited-network-03.txt
> > has been successfully submitted by Roland Jesske and posted to the IETF
> repository.
> >
> > Name:		draft-jesske-update-p-visited-network
> > Revision:	03
> > Title:		Update to Private Header Field P-Visited-Network-ID in Session
> Initiation Protocol (SIP) Requests and Responses
> > Document date:	2021-05-31
> > Group:		Individual Submission
> > Pages:		4
> > URL:            https://www.ietf.org/archive/id/draft-jesske-update-p-visited-
> network-03.txt
> > Status:         https://datatracker.ietf.org/doc/draft-jesske-update-p-visited-
> network/
> > Htmlized:       https://datatracker.ietf.org/doc/html/draft-jesske-update-p-visited-
> network
> > Diff:           https://www.ietf.org/rfcdiff?url2=draft-jesske-update-p-visited-
> network-03
> >
> > Abstract:
> >   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
> >   document updates RFC 7976, in order to allow inclusion of the P-
> >   Visited-Network-ID header field in responses.
> >
> >
> >
> >
> > The IETF Secretariat
> >
> >
> > _______________________________________________
> > sipcore mailing list
> > sipcore@ietf.org
> > https://www.ietf.org/mailman/listinfo/sipcore

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.