From R.Jesske@telekom.de Tue Dec 3 05:01:14 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71F431AE150 for ; Tue, 3 Dec 2013 05:01:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, MANGLED_AVOID=2.3, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001] autolearn=ham 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 gW68Ve369Xh0 for ; Tue, 3 Dec 2013 05:00:59 -0800 (PST) Received: from tcmail43.telekom.de (tcmail43.telekom.de [80.149.113.173]) by ietfa.amsl.com (Postfix) with ESMTP id D997A1AE139 for ; Tue, 3 Dec 2013 05:00:58 -0800 (PST) Received: from he113656.emea1.cds.t-internal.com ([10.134.99.16]) by tcmail41.telekom.de with ESMTP/TLS/AES128-SHA; 03 Dec 2013 14:00:26 +0100 Received: from HE113667.emea1.cds.t-internal.com ([fe80::c943:1394:e86e:fce3]) by HE113656.emea1.cds.t-internal.com ([10.134.99.16]) with mapi; Tue, 3 Dec 2013 14:00:25 +0100 From: To: Date: Tue, 3 Dec 2013 14:00:24 +0100 Thread-Topic: PROTO Review: draft-drage-sipping-rfc3455bis-09.txt Thread-Index: Ac7qKdnZRAH6t1z7TLGfyU0SETzPdgF/CCyQ Message-ID: <058CE00BD4D6B94FAD033A2439EA1E4B01DF27DB8A63@HE113667.emea1.cds.t-internal.com> References: <058CE00BD4D6B94FAD033A2439EA1E4B01DEBB69CC8A@HE113667.emea1.cds.t-internal.com> In-Reply-To: Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: multipart/alternative; boundary="_000_058CE00BD4D6B94FAD033A2439EA1E4B01DF27DB8A63HE113667eme_" MIME-Version: 1.0 Cc: dispatch@ietf.org, dean.willis@softarmor.com Subject: Re: [dispatch] PROTO Review: draft-drage-sipping-rfc3455bis-09.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 13:01:14 -0000 --_000_058CE00BD4D6B94FAD033A2439EA1E4B01DF27DB8A63HE113667eme_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Mary, Thank you for your comments and proposals. I have now included all comments and uploaded a new version. So we can now proceed. Thank you and Best Regards Roland A new version of I-D, draft-drage-sipping-rfc3455bis-10.txt has been successfully submitted by Roland Jesske and posted to the IETF rep= ository. Filename: draft-drage-sipping-rfc3455bis Revision: 10 Title: Private Header (P-Header) Extensions to the Session Initi= ation Protocol (SIP) for the 3rd-Generation Partnership Project (3GPP) Creation date: 2013-12-03 Group: Individual Submission Number of pages: 46 URL: http://www.ietf.org/internet-drafts/draft-drage-sipping-rf= c3455bis-10.txt Status: http://datatracker.ietf.org/doc/draft-drage-sipping-rfc345= 5bis Htmlized: http://tools.ietf.org/html/draft-drage-sipping-rfc3455bis-= 10 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-drage-sipping-rfc= 3455bis-10 Abstract: This document describes a set of private Session Initiation Protocol (SIP) header fields (P-headers) used by the 3rd-Generation Partnership Project (3GPP), along with their applicability, which is limited to particular environments. The P-header fields are for a variety of purposes within the networks that the partners use, including charging and information about the networks a call traverses. Von: Mary Barnes [mailto:mary.ietf.barnes@gmail.com] Gesendet: Montag, 25. November 2013 23:01 An: Jesske, Roland Cc: DISPATCH; Gonzalo Camarillo; Atle Monrad; Dean Willis Betreff: Re: PROTO Review: draft-drage-sipping-rfc3455bis-09.txt Hi Roland, Thanks for your response. Additional comments below [MB]. Thanks, Mary. On Thu, Nov 21, 2013 at 7:21 AM, > wrote: Hi Mary, Thank you for your review. I have added now your proposals to the draft. Other comments please see below. I hope now everything is OK. Thank you and Best Regards Roland Von: Mary Barnes [mailto:mary.ietf.barnes@gmail.com] Gesendet: Dienstag, 29. Oktober 2013 17:27 An: Jesske, Roland Cc: DISPATCH; Gonzalo Camarillo; Atle Monrad; Dean Willis Betreff: PROTO Review: draft-drage-sipping-rfc3455bis-09.txt In preparation for the PROTO write-up, I have reviewed the document in deta= il. My detailed review was originally based on the -08, but I also reviewe= d the 09 diff. There are a few errors that have been introduced in the -09= and many of my -08 comments remain - I've separated comments from nits bel= ow. A number of these comments are with regards to text that was not chang= ed from RFC 3455, but I think some of the text requires updating and we nee= d to keep in mind that this an entirely new IESG that will be reviewing thi= s document, so they won't have the same context of the IESG that approved R= FC 3455. I will note that I also have not validated the content of section= 9 against a diff of this document and RFC 3455. I will need to do that be= fore I progress the document unless the authors can point me to another rev= iew that has done that. Regards, Mary. Summary: This document needs some work prior to being progressed. Comments: ---------------- - Section 1. I think you should be explicit that these extensions apply on= ly to a private network - saying they are "generally not applicable" is too= soft, so I would suggest some minor rewording something like: OLD: The SIP extensions specified in this document make certain assumptions regarding network topology, linkage between SIP and lower layers, and the availability of transitive trust. These assumptions are generally NOT APPLICABLE in the Internet as a whole. NEW: The SIP extensions specified in this document make certain assumptions regarding network topology, linkage between SIP and lower layers, and the availability of transitive trust. These assumptions apply only to private networks and are not appropriate for use in an Int= ernet environment. - Section 3. This section needs to be updated. I don't think that 10 year= old background is relevant in the current context. You should be able to= model this after the text in more recent 3GPP P-header documents, referrin= g to the SIP change process. [RJ] OK, I have changed the text: The Third Generation Partnership Project (3GPP) has selected SIP as the protocol used to establish and tear down multimedia sessions in th= e context of its IP Multimedia Subsystem (IMS). For more information on the IMS, a detailed description can be found in 3GPP TS 23.228 . This = document is an update of RFC3455 which covers the requirements in RFC4083= and describes updates and adds private extensions to address those require= ments which are needed in for 3GPP Release 11. Each extension, or set of re= lated extensions is described in its own section below [MB] I suggest just a bit more rewording. Note that I didn't see that this= document is adding any new headers The Third Generation Partnership Project (3GPP) uses SIP as the protocol to establish and tear down multimedia sessions in the context of its IP Multimedia Subsystem (IMS), as described in the 3GPP TS 23.228 specification. RFC 3455 defines SIP private header extensions (referred to as P-heade= rs) which are required by the 3GPP specification. Note that the requirements for the= se extensions are documented in RFC 4083. This document is an update to RFC3455. This document updates existing P-header descriptions to address additional requirements which are needed for 3GPP Release 1= 1. Each of the P-headers is described in the sections below. [/MB] - Section 4.1. "registered address-of-record" -> "registered SIP address-of= -record" - Section 4.1, 3rd paragraph. "Note that, generally speaking," -> "Note th= at in standard SIP usage [RFC3261]" - Section 4.1.2.3. I don't think this is stated properly. I think the int= ent is that this header is not applicable to proxies, therefore the proxy M= UST relay the header field unchanged. I would suggest rewording something = like: OLD: This memo does not define any procedure at the proxy. The proxy does not add, read, modify or delete the header field, and therefore any proxy will relay this header field unchanged. NEW: This header is not intended to be used by proxies - a proxy does not add, read, modify or delete the header field, and therefore any proxy MUST relay this header field unchanged. Section 4.2, 1st paragraph. The behavior in this sentence is not normative= from a SIP protocol perspective, thus MAY is not appropriate. I suggest t= he MAY be changed to "can". The UAS MAY use the information to render different distinctive audiovis= ual alerting tones, depending on the URI used to receive the invitation to the session. Section 4.2.2.2, 2nd paragraph. The behavior in this sentence is not norma= tive from a SIP protocol perspective, thus I suggest the MAY be changed to= "can". - Section 4.3.3, last paragraph. I think this ought to be a MUST: "The ide= ntifier should be globally unique.." - Section 4.3.2.1. This text has changed from the -08. I don't know what= a "normal User Equipment" is and the term "User Equipment" is not defined = in this specification. I think it would be better to say something like. H= owever, even with this proposed change, I think you also need text for user= agent server behavior - i.e., what would a UAS do if it received this head= er. OLD: A normal User Equipment has normally no knowledge of the P-Visited- Network-ID when sending the REGISTER. Therefore user agent clients do not insert a P-Visited-Network-ID header field in any SIP message. NEW: In the context of the network to which the header fields defined in this= document apply, a User Agent has no knowledge of the P-Visited-Network-ID = when sending the REGISTER request. Therefore user agent clients MUST NOT i= nsert a P-Visited-Network-ID header field in any SIP message. - Section 4.3.2.2:, 2nd paragraph: "home network MAY use" = -> "home network can use" - Section 4.3.2.2, last paragraph: OLD: Note that a received P-Visited-Network-ID from a UA is a failure case = and must be deleted. NEW: Note that a received P-Visited-Network-ID from a UA is a failure case= and MUST be deleted when the request is forwarded. Section 4.4.2.1, 2nd paragraph: "MUST trust the proxy" -> "MUST have a tru= st relationship with the proxy" Section 4.4.2.1, 3rd paragraph: "there must also be a transitive trust" ->= "there MUST also be a transitive trust" Section 4.4.2.2, 2nd paragraph: "MAY act upon any information present" -> "= can act upon any information present", "MAY use the call id" -> "can use t= he call id" Section 4.5.2: 2nd paragraph: "MAY use the hostnames" -> "can use the hostn= ames" Section 4.5.2.1 2nd paragraph: "MAY use the contents" -> "can use the conte= nts" - Section 4.6.2, 3rd paragraph: "MAY use the values" -> "can use the values= " - Section 4.6.3, 3rd paragraph: needs some editorial work. Maybe the follo= wing change would work: OLD: Depending on the call scenario it is needed to add for each transit network either a transit network name or a void value. Nevertheless it can not be guaranteed that all values will appear within the P-Chargi= ng-Vector header field. NEW: Depending on the call scenario, each transit network can add either a tr= ansit network name or a void value. However, it can not be guaranteed t= hat all the values that are added will appear within the P-Charging-Vector = header field. - Section 4.6.3, next to last paragraph: "which needs to be incremented" ->= "which MUST be incremented" - Section 4.6.3, last paragraph. I have no idea what that is trying to say= other than void values have no index. What does "taken into consideration= " mean. Are you talking about limits on the number of entries or are you su= ggesting that the number of void values must be considered when setting the= index for the transit network names? [RJ] Yes! Changed the text to: A void value has no index. By adding the next value the index has to be inc= remented by the number of void entries +1. - Section 4.6.4.2: I don't know what this means: "A deleti= on of the elements could appear depending on the network policy and trust r= ules". Is it just trying to say that along with the adding and modifying i= n the previous sentence that the elements can also be deleted by the proxy? [RJ] Yes, I have changed the text: Procedures described within 4.6.2.2 apply. A transit-ioi MAY be added or modified by a proxy. A deletion of the transit-ioi or a= entry within the tranist-ioi could appear depending on the network policy and trust rules. This is also valid by replacing the transit-ioi with a void value. - Section 5.7. Delete this text and table. We aren't these tables anymore= as they really don't provide any useful information. You just need to ver= bally state what messages these headers can appear in. [RJ] OK So I changed 5.7 to "New header" The P-Associated-URI can appear in SIP REGISTER method and 2xx resonses, P-= Called-Party-ID can appear in SIP INVITE, OPTIONS, PUBLISH,SUBSCRIBE, MESSA= GE methods and all responses, P-Visited-Network-ID can appear in all SIP me= thods except ACK, BYE and CANCEL and all responses, P-Access-Network-Info c= an appear in all SIP methods exept ACK and CANCEL, P-Charging-Vector can a= ppear in all SIP methods exept CANCEL and the P-Charging-Function-Addresses= can appear in all SIP methods exept ACK and CANCEL. [MB] I suggest you put each of these in separate sentences - i.e., rather t= han use comma separators, use a period. You should also spell out that the= se are header fields - i.e., "The P-Associated-URI header field can appear.= ...2xx responses. The P-Called-Party-ID header field.... - Section 6.1: this needs some tighter wording. What is meant by "potentia= lly annoying" for example? [RJ] I do not know. This is original text. So I deleted the words. - Section 6.2: I think you need to be more specific about the "nature" that= makes this header not of particular concern with regards to security. Does= it reveal additional, unique information about an individual that isn't av= ailable in other headers. Also, the 2nd paragraph needs some work - maybe = something like: OLD: An eavesdropper may collect the list of identities a user is registered. T= his may have privacy implications. To mitigate this problem, this extensio= n SHOULD only be used in a secured environment, where encryption of SIP mes= sages is provided either end-to-end or hop-by-hop. NEW: An eavesdropper could possibly collect the list of identities a user is re= gistered. This can have privacy implications. To mitigate this problem, t= his extension MUST only be used in a secured environment, where encryption = of SIP messages is provided either end-to-end or hop-by-hop. [MB] So, I think the first sentence is trying to say: "An eavesdropper cou= ld possibly collect the list of identities a user has registered." or "An eavesdropper could possibly collect the list of identities register= ed by a user." [/MB] - Section 6.4, --3rd paragraph: "should not" -> "MUST NOT" -- 7th paragraph: "SHOULD NOT be sent" -> "MUST NOT be sent" -- 8th paragraph: "SHOULD NOT send sensitive information" -> "MUST NOT send= sensitive information" -- 9th paragraph: "is required to delete" -> "is REQUIRED to delete" -- 10th paragraph: How does a network ensure the information is not of a s= ensitive nature? I would think that the information just should not be se= nt outside of the trust domain. I believe that's consistent with the scope= of these headers, is it not? [RJ] Yes that is also my understanding so I deleted that paragraph. I think= the rest is sufficient and described well how to behave. -- 11th paragraph: So, what does a proxy do with that information. What ar= e the implications if the information is used and it's not valid? [RJ] Yes I did some changes as follows. A proxy receiving a message containing the P-Access-Network-Info header field from a non-trusted entity is not able to guarantee the validity of the contents. Thus this content SHOULD be deleted based = on local policy. - Section 9, item 2. I think you need to add this text with regards to the= recommendation to use RFC 4244 (bis) to the body of this document and incl= ude a real reference. [RJ] OK done. I let the reference RFC4244 since 3GPP uses currently only RF= C4244. Replaced following text: With section 9.2 Requirements for a more general solution are proposed in . 3GPP will continue to use the P-Called-Party-ID header field even though RFC 4244 has now been published. I think the text in Section 9.2 is better. Nits: - Section 4.1, 2nd paragraph. "has associated to an address-of-record" -> = "has associated with an address-of-record" - Section 4.1.2.2, 2nd paragraph, "In case" -> "If", "shall not" -> SHALL = NOT - Section 4.3.2.2, last sentence. The -09 introduced a typo: "T means" -> = "This means" - Section 4.3.2.3, 1st paragraph after 1st example. The -09 introduced ano= ther typo: "the REGISTRAR" -> "at the REGISTRAR" Section 4.2.2.1, 3rd paragraph: "there must also be a transitive trust" ->= "there MUST also be a transitive trust" Section 4.6, 2nd paragraph: "includes, includes but is not limited to" -> "= includes, but is not limited to," Section 4.6.2.2, 1st paragraph: "one ore more" -> "one or more" On Tue, Oct 8, 2013 at 11:58 AM, > wrote: Dear all, I would like to inform you that I have implemented all comments coming from= the expert review done by Dean Willis. Also an editorial cleanup was made. If there are still some comments that needs to be implemented please inform= me. >From my side I would be happy to proceed the draft further towards publicat= ion. Thank you and Best Regards Roland -----Urspr=FCngliche Nachricht----- Von: internet-drafts@ietf.org [mailto:inte= rnet-drafts@ietf.org] Gesendet: Dienstag, 8. Oktober 2013 13:40 An: Christer Holmberg; Keith Drage; Jesske, Roland Betreff: New Version Notification for draft-drage-sipping-rfc3455bis-09.txt A new version of I-D, draft-drage-sipping-rfc3455bis-09.txt has been successfully submitted by Keith Drage and posted to the IETF repos= itory. Filename: draft-drage-sipping-rfc3455bis Revision: 09 Title: Private Header (P-Header) Extensions to the Session Initia= tion Protocol (SIP) for the 3rd-Generation Partnership Project (3GPP) Creation date: 2013-10-08 Group: Individual Submission Number of pages: 47 URL: http://www.ietf.org/internet-drafts/draft-drage-sipping-rf= c3455bis-09.txt Status: http://datatracker.ietf.org/doc/draft-drage-sipping-rfc345= 5bis Htmlized: http://tools.ietf.org/html/draft-drage-sipping-rfc3455bis-= 09 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-drage-sipping-rfc= 3455bis-09 Abstract: This document describes a set of private Session Initiation Protocol (SIP) header fields (P-headers) used by the 3rd-Generation Partnership Project (3GPP), along with their applicability, which is limited to particular environments. The P-header fields are for a variety of purposes within the networks that the partners use, including charging and information about the networks a call traverses. Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat - --_000_058CE00BD4D6B94FAD033A2439EA1E4B01DF27DB8A63HE113667eme_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Mary,

Thank you for y= our comments and proposals.

I have now included all comments and uploaded a new version.=

So we can no= w proceed.

 

Thank yo= u and Best Regards

 

= Roland

 

A new ve= rsion of I-D, draft-drage-sipping-rfc3455bis-10.txt

has been successfully submitted by= Roland Jesske and posted to the IETF repository.

 

Filename:=A0=A0 draft-drage-sipping-rfc= 3455bis

Rev= ision:=A0=A0 10

Title:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Private Header (P-Header) Ex= tensions to the Session Initiation Protocol (SIP) for the 3rd-Generation Pa= rtnership Project (3GPP)

Creation date:=A0=A0=A0 2013-12-03

Group:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 Individual Submission

Number of pages: 46

URL:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 http://www.ietf.org/internet-drafts/draft-drage= -sipping-rfc3455bis-10.txt<= /p>

Status:=A0=A0=A0=A0=A0=A0=A0= =A0=A0 http://datatracker.ietf.org/doc/draft-drag= e-sipping-rfc3455bis

Htmlized:=A0=A0=A0=A0=A0=A0=A0 http://tools.ietf.org/html/draft-drage-sipping-rfc3455b= is-10

Diff:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 http://www.ietf.org/rfcdiff?url2=3Ddraft-drage-sipping= -rfc3455bis-10

 

Abstract:

=A0=A0 This document describes a set of priva= te Session Initiation Protocol

=A0=A0 (SIP) header fields (P-headers) used by the 3rd-= Generation

= =A0=A0 Partnership Project (3GPP), along with their applicability, which is=

=A0=A0 lim= ited to particular environments.=A0 The P-header fields are for a

=A0=A0 variety of pu= rposes within the networks that the partners use,

=A0=A0 including charging and inform= ation about the networks a call

=A0=A0 traverses.

 

 

 = ;

Von: Mary Barnes [mailto:mary= .ietf.barnes@gmail.com]
Gesendet: Montag, 25. November 2013 23:0= 1
An: Jesske, Roland
Cc: DISPATCH; Gonzalo Camarillo; A= tle Monrad; Dean Willis
Betreff: Re: PROTO Review: draft-drage-si= pping-rfc3455bis-09.txt

 

Hi Roland,

<= p class=3DMsoNormal> 

Th= anks for your response.  Additional comments below [MB].

 

Thanks,

Mary.

=  

On Thu, Nov 21, 2013 at 7:21= AM, <R.Jesske@= telekom.de> wrote:

Hi Mary,

Thank you for yo= ur review.

I have added now= your proposals to the draft.

Other comments please see below.

 

I hope now= everything is OK.

&nb= sp;

Thank you and Best Rega= rds

 

Roland

 

Von: Mary Barne= s [mailto:m= ary.ietf.barnes@gmail.com]
Gesendet: Dienstag, 29. Oktober 2= 013 17:27
An: Jesske, Roland
Cc: DISPATCH; Gonzalo Cama= rillo; Atle Monrad; Dean Willis
Betreff: PROTO Review: draft-drag= e-sipping-rfc3455bis-09.txt

 

In preparation for the PROTO write-up, I have revi= ewed the document in detail.  My detailed review was originally based = on the -08, but I also reviewed the 09 diff.  There are a few errors t= hat have been introduced in the -09 and many of my -08 comments remain - I'= ve separated comments from nits below.  A number of these comments are= with regards to text that was not changed from RFC 3455, but I think some = of the text requires updating and we need to keep in mind that this an enti= rely new IESG that will be reviewing this document, so they won't have the = same context of the IESG that approved RFC 3455.  I will note that I a= lso have not validated the content of section 9 against a diff of this docu= ment and RFC 3455.  I will need to do that before I progress the docum= ent unless the authors can point me to another review that has done that.

 

Regards,

Mary.

 <= o:p>

Summary:  This document nee= ds some work prior to being progressed. 

&= nbsp;

Comments:

----------------

- Section 1.  = I think you should be explicit that these extensions apply only to a privat= e network - saying they are "generally not applicable" is too sof= t, so I would suggest some minor rewording something like:

OLD:

   The SIP extensions specified in th=
is document make certain
 
&=
nbsp;  assumptions regarding network topology, linkage between SIP and=
 lower
   layers, and the availability of tr=
ansitive trust.  These assumptions
   a=
re generally NOT APPLICABLE in the Internet as a whole.
 

NEW: 

 
&nb=
sp;  The SIP extensions specified in this document make certain
   assumptions regarding network topology, linkage=
 between SIP and lower
   layers, and the av=
ailability of transitive trust.  These assumptions
   apply only to private networks and are not appropriate for u= se in an Internet environment.
 
- Sectio=
n 3.  This section needs to be updated.  I don't think that 10 ye=
ar old background is relevant in the current context.   You should be =
able to model this after the text in more recent 3GPP P-header documents, r=
eferring to the SIP change process. 
 
[RJ] OK, I h=
ave changed the text:

The Third Generation Partnership Project (3GPP) has select= ed SIP as

     the protocol used to establish and tear down mu= ltimedia sessions in the

     context of its IP Multimedia Sub= system (IMS). For more information on

     the IMS, a detailed= description can be found in 3GPP TS 23.228 . This document is an update of= RFC3455   which covers the requirements in RFC4083 and describes= updates and adds private extensions to address those requirements which ar= e needed in for 3GPP Release 11. Each extension, or set of related extensio= ns is described in its own section below

<= /div>

[MB] I suggest just a bit = more rewording.  Note that I didn't see that this document is adding a= ny new headers 

&nb= sp;

    The Third = Generation Partnership Project (3GPP) uses SIP as

     the protocol  to estab= lish and tear down multimedia sessions in the

<= span lang=3DEN-US style=3D'font-size:11.0pt;font-family:"Calibri","sans-ser= if";color:#1F497D'>     context of its IP Multimedia Su= bsystem (IMS), as described in 

     the 3GPP TS 23.228 specification. 

     RFC 3455 def= ines SIP private header extensions (referred to as P-headers) which are&nbs= p;

     requ= ired by the 3GPP specification. Note that the requirements for these extens= ions

     ar= e documented in RFC 4083.   This document is an upd= ate to RFC3455. 

&nbs= p;    This document updates existing P-header&nbs= p;descriptions 

     = ;to address additional requirements which are needed for 3GPP Release 11.&n= bsp;

     Each of the P-h= eaders is described in the sections below.

=

 

[= /MB] 

 <= /p>

- Section 4.1. "registered address-of-record" -> "re=
gistered SIP address-of-record"
- Sec=
tion 4.1, 3rd paragraph.  "Note that, generally speaking," -=
> "Note that in standard SIP usage [RFC3261]"
- Section 4.1.2.3.  I don't think this is stated prop=
erly.  I think the intent is that this header is not applicable to pro=
xies, therefore the proxy MUST relay the header field unchanged.  I wo=
uld suggest rewording something like:
OLD:=
 
 &nb=
sp; This memo does not define any procedure at the proxy.  The proxy d=
oes
   not add, read, modify or delete the h=
eader field, and therefore any
   proxy will=
 relay this header field unchanged.
 
NEW:
 
   This header is not intended to=
 be used by proxies - a proxy does
   not ad=
d, read, modify or delete the header field, and therefore any
   proxy MUST relay this header field unchanged.
 =
;
Section 4.2, 1st paragraph.  The behavior in this sentence is no=
t normative from a SIP protocol perspective, thus MAY is not appropriate. &=
nbsp;I suggest the MAY be changed to "can".   
&nb=
sp;  The UAS MAY use the information to render different distinctive a=
udiovisual alerting
   tones, depending on t=
he URI used to receive the invitation to the
 &nb=
sp; session.
Section 4.2.2.2, 2nd p=
aragraph.  The behavior in this sentence is not normative from a SIP p=
rotocol perspective, thus  I suggest the MAY be changed to "can&q=
uot;. 
 
=
- Section 4.3.3, last paragraph.  I think this ought to be a MUST: &qu=
ot;The identifier should be globally unique.." =

 
- Section 4.3.2.1.  This t=
ext has changed from the -08.   I don't know what a "normal User =
Equipment" is and the term "User Equipment" is not defined i=
n this specification.  I think it would be better to say something lik=
e. However, even with this proposed change, I think you also need text for =
user agent server behavior - i.e., what would a UAS do if it received this =
header. 
 
=
OLD:
   A normal User Equipment has normally no knowledge of=
 the P-Visited-
   Network-ID when sending t=
he REGISTER.  Therefore user agent clients
 =
  do not insert a P-Visited-Network-ID header field in any SIP message=
.
NEW: 
   In the context of the network to which =
the header fields defined in this document apply, a User Agent has no =
knowledge of the P-Visited-Network-ID when sending the REGISTER request. &n=
bsp;Therefore user agent clients MUST NOT insert a P-Visited-Network-ID&nbs=
p;header field in any SIP message.
 
- Section 4=
.3.2.2:, 2nd paragraph:  "home network MAY use" -> &q=
uot;home network can use"

&nb=
sp;
- Section 4.3.2.2, last parag=
raph:  
 
 
<=
span style=3D'font-family:"Arial","sans-serif"'>OLD: Note that a rec=
eived P-Visited-Network-ID from a UA is a failure case and must be deleted.=

&=
nbsp;
NEW:  Note that a received P-Visited-Network-ID from a UA is a=
 failure case and MUST be deleted when the request is forwarded. 
 =

Section 4.4.2.1, 2nd paragraph:  "MUST trust the proxy"=
 -> "MUST have a trust relationship with the proxy" 
 
Section 4.4.2.1, 3rd paragraph:  "there must als=
o be a transitive trust" ->  "there MUST also be a transi=
tive trust" 
Secti=
on 4.4.2.2, 2nd paragraph: "MAY act upon any information present"=
 -> "can act upon any information present",  "MAY us=
e the call id" -> "can use the call id" 
Section 4.5.2: 2nd paragraph: "MAY use the hostnames" -&g=
t; "can use the hostnames" 
 
 
Section 4.5.2.1 2n=
d paragraph: "MAY use the contents" -> "can use the =
contents" 
 
- Section 4.6.2, 3rd paragraph: "MAY use the values=
" -> "can use the values" 
- Section 4.6.3, 3rd paragraph: needs some editorial work. &nb=
sp;Maybe the following change would work: 
 
OLD:
   Depending on the c=
all scenario it is needed to add for each transit
&nbs=
p;  network either a transit network name or a void value.  Never=
theless
   it can not be guaranteed that all=
 values will appear within the P-Charging-Vector header field. 
NEW: 
 
   Depending on the call scenario, each trans=
it network can add either a transit network name or a void  =
  value.  However, it can not be guaranteed that all the values t=
hat are added will appear within the P-Charging-Vector header field.
 
<=
span style=3D'font-family:"Arial","sans-serif";color:#222222'>- Section 4.6=
.3, next to last paragraph: "which needs to be incremented" =
-> "which MUST be incremented"
&nb=
sp;
- Section =
4.6.3, last paragraph.  I have no idea what that is trying to say othe=
r than void values have no index.  What does "taken into consider=
ation" mean. Are you talking about limits on the number of entries or =
are you suggesting that the number of void values must be considered when s=
etting the index for the transit network names?  
 
[RJ] Yes! Changed the text to:
 
A void value has no index. By adding the next value the index ha=
s to be incremented by the number of void entries +1.
 
- Section <=
span lang=3DEN-US>4.6.4.2: I don't know what this means:=
 =
 "A deletion of the elements could appear depending on the networ=
k policy and trust rules".  Is it just trying to say that along with the adding and =
modifying in the previous sentence that the elements can also be deleted by=
 the proxy? 
 
[RJ] Yes, I have changed the text:
Proc=
edures described within 4.6.2.2 apply. A transit-ioi MAY be
   &nbs=
p;       added or modified by a proxy. A dele=
tion of the transit-ioi or a entry within the tranist-ioi could=

   =
        appear depending on the network =
policy and trust rules. This is
           also valid =
by replacing the transit-ioi with a void value.
 
 
- Section 5.7. Delete this tex=
t and table.   We aren't these tables anymore as they really don't pro=
vide any useful information.  You just need to verbally state what mes=
sages these headers can appear in. 
 
[RJ] OK<=
/pre>
 
So =
I changed 5.7 to “New header”
The P-Asso=
ciated-URI can appear in SIP REGISTER method and 2xx resonses, P-Called-Par=
ty-ID can appear in SIP INVITE, OPTIONS, PUBLISH,SUBSCRIBE, MESSAGE methods=
 and all responses, P-Visited-Network-ID can appear in all SIP methods exce=
pt ACK, BYE and CANCEL and all responses, P-Access-Network-Info can appear =
in all SIP methods exept ACK and CANCEL, P-Charging-Vector  can appear=
 in all SIP methods exept CANCEL and the P-Charging-Function-Addresses can =
appear in all SIP methods exept ACK and CANCEL.
=

[MB] I= suggest you put each of these in separate sentences - i.e., rather than us= e comma separators, use a period.  You should also spell out that thes= e are header fields - i.e., "The P-Associated-URI header field can app= ear....2xx responses.   The P-Called-Party-ID header field....

= 
 <=
/pre>
 
- Sect=
ion 6.1: this needs some tighter wording.  What is meant by "pote=
ntially annoying"  for example?  
 
[RJ]=
 I do not know. This is original text. So I deleted the words.<=
/o:p>
&nbs=
p;
- Section 6.2: I think you need to be more specific about the "na=
ture" that makes this header not of particular concern with regards to=
 security. Does it reveal additional, unique information about an individua=
l that isn't available in other headers.  Also, the 2nd paragraph need=
s some work - maybe something like:
 =

OLD:
An eavesdropper may collect the list of ide=
ntities a user is registered.  This may have privacy implications.&nbs=
p; To mitigate this problem, this extension SHOULD only be used in a secure=
d environment, where encryption of SIP messages is provided either end-to-e=
nd or

 
hop-by-hop.&=
nbsp;
   
NEW: 
 
 An eavesdropper could possibly collect the=
 list of identities a user is registered.  This can have privacy impli=
cations.  To mitigate this problem, this extension MUST only be used i=
n a secured environment, where encryption of SIP messages is provided eithe=
r end-to-end or hop-by-hop. 
<= /div>

 

[MB]  So, I think the first sentence= is trying to say: "An eavesdropper coul= d possibly collect the list of identities a user has registered."

or  "An eavesdropper could possibly collect the list of ident= ities registered by a user." 

[/MB]  

= 
- Section 6=
.4, 
--3rd paragraph: "should no=
t" -> "MUST NOT" 
 =

-- 7th paragraph:  "SHOULD NOT be sent=
" -> "MUST NOT be sent" 
 
 
-- 8th paragr=
aph: "SHOULD NOT send sensitive information" -> "MUST NOT=
 send sensitive information"
 
 
<=
span style=3D'font-family:"Arial","sans-serif"'>-- 9th paragraph: "is =
required to delete" -> "is REQUIRED to delete" 
 
-- 10th paragraph:=
  How does a network ensure the information is not of a sensitive natu=
re?   I would think that the information just should not be sent outsi=
de of the trust domain.  I believe that's consistent with the scope of=
 these headers, is it not?
 =

[RJ] Yes that is also my un=
derstanding so I deleted that paragraph. I think the rest is sufficient and=
 described well how to behave.
 
-- 11th para=
graph: So, what does a proxy do with that information.  What are the implications if the =
information is used and it's not valid?  
[RJ] Yes I did some changes as follows.
 

     &nbs= p;  <t>A proxy receiving a message containing the P-Access-Netwo= rk-Info

       header field from a non-trusted entit= y is not able to guarantee the

       validity of the contents. Thus this =
content SHOULD be deleted based on local policy.</t>
 
- Section 9, item 2.  I think you need to add this text with regards =
to the recommendation to use RFC 4244 (bis) to the body of this document an=
d include a real reference.
 
[RJ=
] OK done. I let the reference RFC4244 since 3GPP uses currently only RFC42=
44. 
Replaced following tex=
t:
With section 9.2<=
o:p>
     &nbs=
p; <t>Requirements for a more general solution are proposed in <xr=
ef
    =
     target=3D"RFC4244"></xref>. 3GP=
P will continue to use the
=
         P-Called-Party-ID header f=
ield even though RFC 4244 <xref
         target=3D"R=
FC4244"></xref> has now been published.</t>=

 
I think the text in Section 9.2 is better.
=
Nits:
 
- Section 4.1, 2nd paragraph.  "has associa=
ted to an address-of-record" -> "has associated with an addres=
s-of-record"
- Section 4.1.2.2, 2nd paragraph, "In case" -> &quo=
t;If",  "shall not" -> SHALL NOT
- Section 4.3.2.2, last sentence.  =
The -09 introduced a typo: "T means" -> "This means"=
 
 
- Section 4.3.2.3, 1st paragraph after 1st example.  The=
 -09 introduced another typo: "the REGISTRAR" -> "at the =
REGISTRAR"
 
Section 4.2.2.1, 3rd paragraph:  =
"there must also be a transitive trust" ->  "there M=
UST also be a transitive trust" 
&nbs=
p;
Section 4.6=
, 2nd paragraph: "includes, includes but is not limited to" ->=
 "includes, but is not limited to," 
=

 
Se=
ction 4.6.2.2, 1st paragraph: "one ore more" -> "one or m=
ore" 
 
 
 

On Tue, Oct 8, 2013 at 11:58= AM, <R.Jesske@= telekom.de> wrote:

Dear all,
I would like to infor= m you that I have implemented all comments coming from the expert review do= ne by Dean Willis. Also an editorial cleanup was made.

If there are = still some comments that needs to be implemented please inform me.

F= rom my side I would be happy to proceed the draft further towards publicati= on.

Thank you and Best Regards

Roland


-----Urspr= =FCngliche Nachricht-----
Von: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]<= br>Gesendet: Dienstag, 8. Oktober 2013 13:40
An: Christer Holmberg; Keit= h Drage; Jesske, Roland
Betreff: New Version Notification for draft-drag= e-sipping-rfc3455bis-09.txt


A new version of I-D, draft-drage-si= pping-rfc3455bis-09.txt
has been successfully submitted by Keith Drage a= nd posted to the IETF repository.

Filename:       &nb= sp;draft-drage-sipping-rfc3455bis
Revision:        0= 9
Title:           Private Header (P-Header) Ex= tensions to the Session Initiation Protocol (SIP) for the 3rd-Generation Pa= rtnership Project (3GPP)
Creation date:   2013-10-08
Group: &nbs= p;         Individual Submission
Number of pages: 47=
URL:             http://www.ietf.org/internet-drafts/draft-drage-sipping-rfc3455bis-09.= txt
Status:          http= ://datatracker.ietf.org/doc/draft-drage-sipping-rfc3455bis
Htmlized:=        http://tools.ietf.org/html/draf= t-drage-sipping-rfc3455bis-09
Diff:         &nbs= p;  http://www.ietf.org/rfcdiff?url2=3Ddraft-d= rage-sipping-rfc3455bis-09

Abstract:
   This docume= nt describes a set of private Session Initiation Protocol
   (= SIP) header fields (P-headers) used by the 3rd-Generation
   P= artnership Project (3GPP), along with their applicability, which is
&nbs= p;  limited to particular environments.  The P-header fields are = for a
   variety of purposes within the networks that the part= ners use,
   including charging and information about the netw= orks a call
   traverses.




Please note that = it may take a couple of minutes from the time of submission until the htmli= zed version and diff are available at tools.ietf.org.

The IETF Secretariat

  -

=

 

= --_000_058CE00BD4D6B94FAD033A2439EA1E4B01DF27DB8A63HE113667eme_-- From mary.ietf.barnes@gmail.com Thu Dec 12 15:32:51 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EC181AE550 for ; Thu, 12 Dec 2013 15:32:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 0Gazds-F8Jf2 for ; Thu, 12 Dec 2013 15:32:49 -0800 (PST) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) by ietfa.amsl.com (Postfix) with ESMTP id 032A21ADFDA for ; Thu, 12 Dec 2013 15:32:48 -0800 (PST) Received: by mail-wi0-f176.google.com with SMTP id hq4so339587wib.9 for ; Thu, 12 Dec 2013 15:32:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=E3Mot5xTE16sCS1+hyCEsuyDSYrNifJ4I3jMcHOmcJw=; b=NWI4O7M44GUwXUKDzO2YGVoaAeDTVes3N9lR/iyvT1V3TGxBHUrY7xSPPsblfiH4gz N+AMeK9d/PTWz4MspMl3cvLQzDZcQ/0cjk6VhqQSBOm3UbbwTmdS5pBvDEz1/6EKwo9O 79kD7K9JGsjwoh9IUIjPesQEJ3KCJZf4Gzju8v3BGGcg8eifa6fyTBwTyyEtxRxmPZqM buimuxh/H9OkWMxPr42pC5dBHTe9k+9833qLAKI/MHM4ro4bao9ss78tHHCupZuDrH7m s6NVWcFX56OfFACrD54FVSQJzpTqLbKPb0Z0kOX89f5MpOGsaQldTmEHqE3VzcgQGI3E 3qnQ== MIME-Version: 1.0 X-Received: by 10.194.202.230 with SMTP id kl6mr8926687wjc.9.1386891162411; Thu, 12 Dec 2013 15:32:42 -0800 (PST) Received: by 10.216.172.9 with HTTP; Thu, 12 Dec 2013 15:32:42 -0800 (PST) In-Reply-To: References: Date: Thu, 12 Dec 2013 17:32:42 -0600 Message-ID: From: Mary Barnes To: DISPATCH Content-Type: multipart/alternative; boundary=047d7b873a1013e8dd04ed5ec345 Cc: draft-jennings-vipr-overview@tools.ietf.org, "rai-ads@tools.ietf.org" , "vipr-chairs@tools.ietf.org" Subject: [dispatch] Fwd: [VIPR] vipr-overview-06 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Dec 2013 23:32:51 -0000 --047d7b873a1013e8dd04ed5ec345 Content-Type: text/plain; charset=ISO-8859-1 For folks that are not on the VIPR WG mailing list, the plan is to publish draft-jennings-vipr-overview as an AD sponsored document: http://tools.ietf.org/id/draft-jennings-vipr-overview-06.txt It will be the only document published related to the VIPR WG, which will be closed. If you have any comments or concerns about this document being progressed as AD sponsored, please post a note on the VIPR WG mailing list (by the end of the year) as it would be good to have comments all in one archive. Regards, Mary as DISPATCH WG co-chair ---------- Forwarded message ---------- From: Peterson, Jon Date: Thu, Dec 12, 2013 at 5:22 PM Subject: [VIPR] vipr-overview-06 To: "vipr@ietf.org" At the seasonal risk of raising a Ghost of Working Groups Past - for those of you still on this list, please do note the recent publication of vipr-overview-06. This document is no longer being considered as a Standards Track RFC, or even as a working group item of this now-defunct effort. It is being considered now as an individual Informational submission that documents the VIPR architecture for the benefit of posterity, but also explains why we stopped working on VIPR as a potential Standard. If you are still interested, please do read this document and send any comments to this list. For the most part, useful comments at this point will be those that point out respects in which vipr-overview either fails to characterize the VIPR system or fails to correctly document its shortcomings. The new section 7.5 of the overview document is a good place to read up on the latter. It would be great to see any comments before the end of the year. After that, this mailing list will formally give up the ghost. Jon Peterson Neustar, Inc. _______________________________________________ VIPR mailing list VIPR@ietf.org https://www.ietf.org/mailman/listinfo/vipr --047d7b873a1013e8dd04ed5ec345 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
For folks that are not on the VIPR WG mailing list, the pl= an is to publish draft-jennings-vipr-overview as an AD sponsored document:<= br>
http://tools.ietf.org/id/draft-jennings-vipr-overview-06.txt

It will be the only document published related to the V= IPR WG, which will be closed. =A0=A0

If y= ou have any comments or concerns about this document being progressed as AD= sponsored, please post a note on the VIPR WG mailing list (by the end of t= he year) as it would be good to have comments all in one archive.=A0

Regards,
Mary
as DISPATCH WG co-cha= ir

---------- Forwarded message ---------= -
From: Peterson, Jon <jon.peterson@neustar.biz<= /a>>
Date: Thu, Dec 12, 2013 at 5:22 PM
Subject: [VIPR] vipr-overview-06
T= o: "vipr@ietf.org" <vipr@ietf.org>



At the seasonal risk of raising a Ghost of Working Groups Past - for t= hose of you still on this list, please do note the recent publication of vi= pr-overview-06. This document is no longer being considered as a Standards = Track RFC, or even as a working group item of this now-defunct effort. It is being considered now as an in= dividual Informational submission that documents the VIPR architecture for = the benefit of posterity, but also explains why we stopped working on VIPR = as a potential Standard.

If you are still interested, please do read this document and send any= comments to this list. For the most part, useful comments at this point wi= ll be those that point out respects in which vipr-overview either fails to = characterize the VIPR system or fails to correctly document its shortcomings. The new section 7.5 of the o= verview document is a good place to read up on the latter.

It would be great to see any comments before the end of the year. Afte= r that, this mailing list will formally give up the ghost.

Jon Peterson
Neustar, Inc.

_______________________________________________
VIPR mailing list
VIPR@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/vipr


--047d7b873a1013e8dd04ed5ec345-- From mary.ietf.barnes@gmail.com Wed Dec 18 09:41:23 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 037E21AE005 for ; Wed, 18 Dec 2013 09:41:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 L2p94yificYh for ; Wed, 18 Dec 2013 09:41:21 -0800 (PST) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 31EFA1AC448 for ; Wed, 18 Dec 2013 09:41:21 -0800 (PST) Received: by mail-wi0-f173.google.com with SMTP id hn9so1013685wib.0 for ; Wed, 18 Dec 2013 09:41:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=s97FloUe/BlfophcwWn3bQbZSj2JkzPFBDinwi6q4j4=; b=e4/CvBTKaYi54fJs3JwF9piWoRlNAYQbybJsJZAEXoApEcQhPuJBYY8EUmfYAQ3W3X 3YVFd+Lp0OlqWRswLfK0ESSVD3r4ysedXxLKCpFbpo/Ut2G1tpCoEi/R6P5DeTXtcVuP sLnG2wGCLkMVIxXH5LfKgjqSwtWJjoBa0Na+q8k3+Zc8WEJyNN2t012xJR4Y9lSBzvLA +N+RkrWm8S/AOUkCDXTv0lIxi4v/YLrhSVoidqc9AGyiWLeYieqfmwCqObWumD1UWAoi 8HCZXCeof7gvfk95U6+tP6lK0Kj3iXBjjfS4UPRJZxtDvm7REg4XpfaNq0PbSuAtDjeD aBQg== MIME-Version: 1.0 X-Received: by 10.180.93.8 with SMTP id cq8mr9419343wib.38.1387388479097; Wed, 18 Dec 2013 09:41:19 -0800 (PST) Received: by 10.216.172.9 with HTTP; Wed, 18 Dec 2013 09:41:19 -0800 (PST) Date: Wed, 18 Dec 2013 11:41:19 -0600 Message-ID: From: Mary Barnes To: DISPATCH Content-Type: multipart/alternative; boundary=f46d043892b176550a04edd28d4e Cc: Cullen Jennings Subject: [dispatch] Reminder: DISPATCH WG deadlines for IETF-89 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Dec 2013 17:41:23 -0000 --f46d043892b176550a04edd28d4e Content-Type: text/plain; charset=ISO-8859-1 As a reminder, the following are deadlines for the DISPATCH WG for consideration of work items leading up to IETF-89: http://tools.ietf.org/wg/dispatch/trac/wiki - Jan 27, 2014. Cutoff date to notify the chairs/DISPATCH WG of plans to submit a proposal. - Feb 3, 2014. Cutoff for charter proposals for topics (to the mailing list) - Feb 17, 2014. Draft deadline. IF you think you've already made a request of the chairs, it doesn't hurt to send an email reminder. Also, PLEASE ensure the subject is either a response to this email or has an explicit indicator with regards to the topic and IETF-89. The latter is preferred. If you are planning to submit a draft or have submitted a draft, it's extremely helpful if you include -dispatch in the title - that makes it much easier to track using the tools. Thanks, Mary. DISPATCH WG co-chair --f46d043892b176550a04edd28d4e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
As a reminder, the following are deadlines for the DISPATC= H WG for consideration of work items leading up to IETF-89: =A0http://tools.ietf.org/wg/dispat= ch/trac/wiki
  • Jan 27, 2014. Cutoff date to notify the chairs/DISPATCH WG o= f plans to submit a proposal.
  • Feb 3, 2014. Cutoff for charter proposals for topics (to the= mailing list)=A0
  • Feb 17, 2014. Draft deadline.

IF you think you've already made a reque= st of the chairs, it doesn't hurt to send an email reminder. Also, PLEA= SE ensure the subject is either a response to this email or has an explicit= indicator with regards to the topic and IETF-89. =A0 The latter is preferr= ed. =A0

If you are planning to submit a draft or have submitted= a draft, it's extremely helpful if you include -dispatch in the title = - that makes it much easier to track using the tools.

Thanks,
Mary.
DISPATCH WG co-chair

<= /div>



--f46d043892b176550a04edd28d4e-- From mary.ietf.barnes@gmail.com Fri Dec 27 10:45:07 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C7311AE267 for ; Fri, 27 Dec 2013 10:45:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.002 X-Spam-Level: * X-Spam-Status: No, score=1.002 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, MANGLED_AVOID=2.3, NORMAL_HTTP_TO_IP=0.001, SPF_PASS=-0.001] autolearn=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 owaIOqXN3Nwg for ; Fri, 27 Dec 2013 10:45:02 -0800 (PST) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) by ietfa.amsl.com (Postfix) with ESMTP id A47A21AE248 for ; Fri, 27 Dec 2013 10:45:01 -0800 (PST) Received: by mail-wi0-f172.google.com with SMTP id en1so14578980wid.17 for ; Fri, 27 Dec 2013 10:44:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Z1ycbd65+y41Q2MnZ9oV3eWxkQ/sHJyL8B1bUjN4pjk=; b=lWHuF8JLCCiGnvCZwLPAqTu6r/ef80R99zhVfiyhkiJHpY8P7kSIFzblV/5lOzuNg/ r+0aWtLo1m6l1VWYEspl+iC+vrgazHnyVPBrUWGQc5LStw+xCmDYJP1n+YLghh8LEtB7 fiSgKYkJPN9Q139HCYDCazCywWdCc1W4Y8HHSJhMXPW8ePl9lSAR+ZjM9qqGqjnZSfQx XljDVo4xRPUCU6x+huzrpANuLiMaQmRCBTE9oAypbLMTZQGcEAxrSejwI8K7wI/Hy1up v9u8rXlxod7/njsSYDxeMP8+N9rNcSWAc2LPXVbxtNSFJHPA3/xv9xLVgZOAXLBqqKhU tIEg== MIME-Version: 1.0 X-Received: by 10.180.21.101 with SMTP id u5mr34979498wie.38.1388169896420; Fri, 27 Dec 2013 10:44:56 -0800 (PST) Received: by 10.216.172.9 with HTTP; Fri, 27 Dec 2013 10:44:56 -0800 (PST) In-Reply-To: <058CE00BD4D6B94FAD033A2439EA1E4B01DF27DB8A63@HE113667.emea1.cds.t-internal.com> References: <058CE00BD4D6B94FAD033A2439EA1E4B01DEBB69CC8A@HE113667.emea1.cds.t-internal.com> <058CE00BD4D6B94FAD033A2439EA1E4B01DF27DB8A63@HE113667.emea1.cds.t-internal.com> Date: Fri, 27 Dec 2013 12:44:56 -0600 Message-ID: From: Mary Barnes To: "R.Jesske@telekom.de" Content-Type: multipart/alternative; boundary=047d7bb70ca2906bab04ee887d54 Cc: DISPATCH , Dean Willis Subject: Re: [dispatch] PROTO Review: draft-drage-sipping-rfc3455bis-09.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Dec 2013 18:45:07 -0000 --047d7bb70ca2906bab04ee887d54 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Roland, Thanks for making these changes. I finally had a chance to review this updated version. I still have a couple comments on the security section as I think you will get questions during SEC review around this unless some more detail is provided on security threats and impacts. I've extracted these few points from previous review comment threads. Thanks, Mary. ----Previous point ---------------------------------> - Section 6.1: this needs some tighter wording. What is meant by "potentially annoying" for example? *[*RJ] I do not know. This is original text. So I deleted the words. - [MB] So, you removed that part of the sentence and are left with: "This attack should not have any significant impacts." I don't think that adds any value and just begs the question "what are the insignificant impacts and are there any privacy concerns"? Really, it's the next paragraph that provides details of the impacts. I think you could probably remove that sentence altogether and not lose anything. [/MB] ----Previous point ---------------------------------> - Section 6.2: I think you need to be more specific about the "nature" that makes this header not of particular concern with regards to security. Does it reveal additional, unique information about an individual that isn't available in other headers. Also, the 2nd paragraph needs some work - maybe something like: OLD: An eavesdropper may collect the list of identities a user is registered. This may have privacy implications. To mitigate this problem, this extension SHOULD only be used in a secured environment, where encryption of SIP messages is provided either end-to-end or hop-by-hop. NEW: An eavesdropper could possibly collect the list of identities a user is registered. This can have privacy implications. To mitigate this problem, this extension MUST only be used in a secured environment, where encryption of SIP messages is provided either end-to-end or hop-by-hop. ----End previous point ------------------------------< [MB] The suggested change for the first sentence didn't get into the revision. And, I believe you still need to identify privacy/security implications by addressing whether or not this header reveals any unique information about an individual that isn't available in other headers. [/MB] On Tue, Dec 3, 2013 at 7:00 AM, wrote: > Hi Mary, > > Thank you for your comments and proposals. > > I have now included all comments and uploaded a new version. > > So we can now proceed. > > > > Thank you and Best Regards > > > > Roland > > > > A new version of I-D, draft-drage-sipping-rfc3455bis-10.txt > > has been successfully submitted by Roland Jesske and posted to the IETF > repository. > > > > Filename: draft-drage-sipping-rfc3455bis > > Revision: 10 > > Title: Private Header (P-Header) Extensions to the Session > Initiation Protocol (SIP) for the 3rd-Generation Partnership Project (3GP= P) > > Creation date: 2013-12-03 > > Group: Individual Submission > > Number of pages: 46 > > URL: > http://www.ietf.org/internet-drafts/draft-drage-sipping-rfc3455bis-10.txt > > Status: > http://datatracker.ietf.org/doc/draft-drage-sipping-rfc3455bis > > Htmlized: > http://tools.ietf.org/html/draft-drage-sipping-rfc3455bis-10 > > Diff: > http://www.ietf.org/rfcdiff?url2=3Ddraft-drage-sipping-rfc3455bis-10 > > > > Abstract: > > This document describes a set of private Session Initiation Protocol > > (SIP) header fields (P-headers) used by the 3rd-Generation > > Partnership Project (3GPP), along with their applicability, which is > > limited to particular environments. The P-header fields are for a > > variety of purposes within the networks that the partners use, > > including charging and information about the networks a call > > traverses. > > > > > > > > *Von:* Mary Barnes [mailto:mary.ietf.barnes@gmail.com] > *Gesendet:* Montag, 25. November 2013 23:01 > > *An:* Jesske, Roland > *Cc:* DISPATCH; Gonzalo Camarillo; Atle Monrad; Dean Willis > *Betreff:* Re: PROTO Review: draft-drage-sipping-rfc3455bis-09.txt > > > > Hi Roland, > > > > Thanks for your response. Additional comments below [MB]. > > > > Thanks, > > Mary. > > > > On Thu, Nov 21, 2013 at 7:21 AM, wrote: > > Hi Mary, > > Thank you for your review. > > I have added now your proposals to the draft. > > Other comments please see below. > > > > I hope now everything is OK. > > > > Thank you and Best Regards > > > > Roland > > > > *Von:* Mary Barnes [mailto:mary.ietf.barnes@gmail.com] > *Gesendet:* Dienstag, 29. Oktober 2013 17:27 > *An:* Jesske, Roland > *Cc:* DISPATCH; Gonzalo Camarillo; Atle Monrad; Dean Willis > *Betreff:* PROTO Review: draft-drage-sipping-rfc3455bis-09.txt > > > > In preparation for the PROTO write-up, I have reviewed the document in > detail. My detailed review was originally based on the -08, but I also > reviewed the 09 diff. There are a few errors that have been introduced i= n > the -09 and many of my -08 comments remain - I've separated comments from > nits below. A number of these comments are with regards to text that was > not changed from RFC 3455, but I think some of the text requires updating > and we need to keep in mind that this an entirely new IESG that will be > reviewing this document, so they won't have the same context of the IESG > that approved RFC 3455. I will note that I also have not validated the > content of section 9 against a diff of this document and RFC 3455. I wil= l > need to do that before I progress the document unless the authors can poi= nt > me to another review that has done that. > > > > Regards, > > Mary. > > > > Summary: This document needs some work prior to being progressed. > > > > Comments: > > ---------------- > > - Section 1. I think you should be explicit that these extensions apply > only to a private network - saying they are "generally not applicable" is > too soft, so I would suggest some minor rewording something like: > > OLD: > > The SIP extensions specified in this document make certain > > > > assumptions regarding network topology, linkage between SIP and lower > > layers, and the availability of transitive trust. These assumptions > > are generally NOT APPLICABLE in the Internet as a whole. > > > > NEW: > > > > The SIP extensions specified in this document make certain > > assumptions regarding network topology, linkage between SIP and lower > > layers, and the availability of transitive trust. These assumptions > > apply only to private networks and are not appropriate for use in an I= nternet environment. > > > > - Section 3. This section needs to be updated. I don't think that 10 ye= ar old background is relevant in the current context. You should be able = to model this after the text in more recent 3GPP P-header documents, referr= ing to the SIP change process. > > > > [RJ] OK, I have changed the text: > > The Third Generation Partnership Project (3GPP) has selected SIP as > > the protocol used to establish and tear down multimedia sessions in > the > > context of its IP Multimedia Subsystem (IMS). For more information o= n > > the IMS, a detailed description can be found in 3GPP TS 23.228 . Thi= s > document is an update of RFC3455 which covers the requirements in RFC40= 83 > and describes updates and adds private extensions to address those > requirements which are needed in for 3GPP Release 11. Each extension, or > set of related extensions is described in its own section below > > [MB] I suggest just a bit more rewording. Note that I didn't see that > this document is adding any new headers > > > > The Third Generation Partnership Project (3GPP) uses SIP as > > the protocol to establish and tear down multimedia sessions in the > > context of its IP Multimedia Subsystem (IMS), as described in > > the 3GPP TS 23.228 specification. > > RFC 3455 defines SIP private header extensions (referred to as > P-headers) which are > > required by the 3GPP specification. Note that the requirements for > these extensions > > are documented in RFC 4083. This document is an update to RFC3455. > > This document updates existing P-header descriptions > > to address additional requirements which are needed for 3GPP Release > 11. > > Each of the P-headers is described in the sections below. > > > > [/MB] > > > > - Section 4.1. "registered address-of-record" -> "registered SIP address-= of-record" > > - Section 4.1, 3rd paragraph. "Note that, generally speaking," -> "Note = that in standard SIP usage [RFC3261]" > > - Section 4.1.2.3. I don't think this is stated properly. I think the i= ntent is that this header is not applicable to proxies, therefore the proxy= MUST relay the header field unchanged. I would suggest rewording somethin= g like: > > OLD: > > This memo does not define any procedure at the proxy. The proxy does > > not add, read, modify or delete the header field, and therefore any > > proxy will relay this header field unchanged. > > > > NEW: > > > > This header is not intended to be used by proxies - a proxy does > > not add, read, modify or delete the header field, and therefore any > > proxy MUST relay this header field unchanged. > > > > Section 4.2, 1st paragraph. The behavior in this sentence is not normati= ve from a SIP protocol perspective, thus MAY is not appropriate. I suggest= the MAY be changed to "can". > > The UAS MAY use the information to render different distinctive audiov= isual alerting > > tones, depending on the URI used to receive the invitation to the > > session. > > Section 4.2.2.2, 2nd paragraph. The behavior in this sentence is not nor= mative from a SIP protocol perspective, thus I suggest the MAY be changed = to "can". > > > > - Section 4.3.3, last paragraph. I think this ought to be a MUST: "The i= dentifier should be globally unique.." > > > > - Section 4.3.2.1. This text has changed from the -08. I don't know wh= at a "normal User Equipment" is and the term "User Equipment" is not define= d in this specification. I think it would be better to say something like.= However, even with this proposed change, I think you also need text for us= er agent server behavior - i.e., what would a UAS do if it received this he= ader. > > > > OLD: > > A normal User Equipment has normally no knowledge of the P-Visited- > > Network-ID when sending the REGISTER. Therefore user agent clients > > do not insert a P-Visited-Network-ID header field in any SIP message. > > NEW: > > In the context of the network to which the header fields defined in th= is document apply, a User Agent has no knowledge of the P-Visited-Network-I= D when sending the REGISTER request. Therefore user agent clients MUST NOT= insert a P-Visited-Network-ID header field in any SIP message. > > > > - Section 4.3.2.2:, 2nd paragraph: "home network MAY use" -> "home netwo= rk can use" > > > > - Section 4.3.2.2, last paragraph: > > > > > > OLD: Note that a received P-Visited-Network-ID from a UA is a failure cas= e and must be deleted. > > > > NEW: Note that a received P-Visited-Network-ID from a UA is a failure ca= se and MUST be deleted when the request is forwarded. > > > > Section 4.4.2.1, 2nd paragraph: "MUST trust the proxy" -> "MUST have a t= rust relationship with the proxy" > > > > Section 4.4.2.1, 3rd paragraph: "there must also be a transitive trust" = -> "there MUST also be a transitive trust" > > Section 4.4.2.2, 2nd paragraph: "MAY act upon any information present" ->= "can act upon any information present", "MAY use the call id" -> "can use= the call id" > > Section 4.5.2: 2nd paragraph: "MAY use the hostnames" -> "can use the hos= tnames" > > > > > > Section 4.5.2.1 2nd paragraph: "MAY use the contents" -> "can use the con= tents" > > > > - Section 4.6.2, 3rd paragraph: "MAY use the values" -> "can use the valu= es" > > - Section 4.6.3, 3rd paragraph: needs some editorial work. Maybe the fol= lowing change would work: > > > > OLD: > > Depending on the call scenario it is needed to add for each transit > > network either a transit network name or a void value. Nevertheless > > it can not be guaranteed that all values will appear within the P-Char= ging-Vector header field. > > NEW: > > > > Depending on the call scenario, each transit network can add either a = transit network name or a void value. However, it can not be guaranteed= that all the values that are added will appear within the P-Charging-Vecto= r header field. > > > > - Section 4.6.3, next to last paragraph: "which needs to be incremented" = -> "which MUST be incremented" > > > > - Section 4.6.3, last paragraph. I have no idea what that is trying to s= ay other than void values have no index. What does "taken into considerati= on" mean. Are you talking about limits on the number of entries or are you = suggesting that the number of void values must be considered when setting t= he index for the transit network names? > > > > [RJ] Yes! Changed the text to: > > > > A void value has no index. By adding the next value the index has to be i= ncremented by the number of void entries +1. > > > > - Section 4.6.4.2: I don't know what this means: "A deletion of the elem= ents could appear depending on the network policy and trust rules". Is it = just trying to say that along with the adding and modifying in the previous= sentence that the elements can also be deleted by the proxy? > > > > [RJ] Yes, I have changed the text: > > Procedures described within 4.6.2.2 apply. A transit-ioi MAY be > > added or modified by a proxy. A deletion of the transit-ioi or > a entry within the tranist-ioi could > > appear depending on the network policy and trust rules. This i= s > > also valid by replacing the transit-ioi with a void value. > > > > > > - Section 5.7. Delete this text and table. We aren't these tables anymo= re as they really don't provide any useful information. You just need to v= erbally state what messages these headers can appear in. > > > > [RJ] OK > > > > So I changed 5.7 to =93New header=94 > > The P-Associated-URI can appear in SIP REGISTER method and 2xx resonses, > P-Called-Party-ID can appear in SIP INVITE, OPTIONS, PUBLISH,SUBSCRIBE, > MESSAGE methods and all responses, P-Visited-Network-ID can appear in all > SIP methods except ACK, BYE and CANCEL and all responses, > P-Access-Network-Info can appear in all SIP methods exept ACK and CANCEL, > P-Charging-Vector can appear in all SIP methods exept CANCEL and the > P-Charging-Function-Addresses can appear in all SIP methods exept ACK and > CANCEL. > > [MB] I suggest you put each of these in separate sentences - i.e., rather > than use comma separators, use a period. You should also spell out that > these are header fields - i.e., "The P-Associated-URI header field can > appear....2xx responses. The P-Called-Party-ID header field.... > > > > > > - Section 6.1: this needs some tighter wording. What is meant by "potent= ially annoying" for example? > > > > [RJ] I do not know. This is original text. So I deleted the words. > > > > - Section 6.2: I think you need to be more specific about the "nature" th= at makes this header not of particular concern with regards to security. Do= es it reveal additional, unique information about an individual that isn't = available in other headers. Also, the 2nd paragraph needs some work - mayb= e something like: > > > > OLD: > > An eavesdropper may collect the list of identities a user is registered. = This may have privacy implications. To mitigate this problem, this extens= ion SHOULD only be used in a secured environment, where encryption of SIP m= essages is provided either end-to-end or > > > > hop-by-hop. > > > > NEW: > > > > An eavesdropper could possibly collect the list of identities a user is = registered. This can have privacy implications. To mitigate this problem,= this extension MUST only be used in a secured environment, where encryptio= n of SIP messages is provided either end-to-end or hop-by-hop. > > > > [MB] So, I think the first sentence is trying to say: "An eavesdropper > could possibly collect the list of identities a user has registered." > > or "An eavesdropper could possibly collect the list of identities > registered by a user." > > [/MB] > > - Section 6.4, > > --3rd paragraph: "should not" -> "MUST NOT" > > > > -- 7th paragraph: "SHOULD NOT be sent" -> "MUST NOT be sent" > > > > > > -- 8th paragraph: "SHOULD NOT send sensitive information" -> "MUST NOT se= nd sensitive information" > > > > > > -- 9th paragraph: "is required to delete" -> "is REQUIRED to delete" > > > > -- 10th paragraph: How does a network ensure the information is not of a= sensitive nature? I would think that the information just should not be = sent outside of the trust domain. I believe that's consistent with the sco= pe of these headers, is it not? > > > > [RJ] Yes that is also my understanding so I deleted that paragraph. I thi= nk the rest is sufficient and described well how to behave. > > > > -- 11th paragraph: So, what does a proxy do with that information. What = are the implications if the information is used and it's not valid? > > [RJ] Yes I did some changes as follows. > > > > A proxy receiving a message containing the P-Access-Network-In= fo > > header field from a non-trusted entity is not able to guarantee th= e > > validity of the contents. Thus this content SHOULD be deleted base= d on local policy. > > > > - Section 9, item 2. I think you need to add this text with regards to t= he recommendation to use RFC 4244 (bis) to the body of this document and in= clude a real reference. > > > > [RJ] OK done. I let the reference RFC4244 since 3GPP uses currently only = RFC4244. > > Replaced following text: > > With section 9.2 > > Requirements for a more general solution are proposed in > target=3D"RFC4244">. 3GPP will continue to use the > > P-Called-Party-ID header field even though RFC 4244 > target=3D"RFC4244"> has now been published. > > > > I think the text in Section 9.2 is better. > > *Nits:* > > > > - Section 4.1, 2nd paragraph. "has associated to an address-of-record" -= > "has associated with an address-of-record" > > - Section 4.1.2.2, 2nd paragraph, "In case" -> "If", "shall not" -> SHAL= L NOT > > - Section 4.3.2.2, last sentence. The -09 introduced a typo: "T means" -= > "This means" > > > > - Section 4.3.2.3, 1st paragraph after 1st example. The -09 introduced a= nother typo: "the REGISTRAR" -> "at the REGISTRAR" > > > > Section 4.2.2.1, 3rd paragraph: "there must also be a transitive trust" = -> "there MUST also be a transitive trust" > > > > Section 4.6, 2nd paragraph: "includes, includes but is not limited to" ->= "includes, but is not limited to," > > > > Section 4.6.2.2, 1st paragraph: "one ore more" -> "one or more" > > > > > > > > On Tue, Oct 8, 2013 at 11:58 AM, wrote: > > Dear all, > I would like to inform you that I have implemented all comments coming > from the expert review done by Dean Willis. Also an editorial cleanup was > made. > > If there are still some comments that needs to be implemented please > inform me. > > From my side I would be happy to proceed the draft further towards > publication. > > Thank you and Best Regards > > Roland > > > -----Urspr=FCngliche Nachricht----- > Von: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Gesendet: Dienstag, 8. Oktober 2013 13:40 > An: Christer Holmberg; Keith Drage; Jesske, Roland > Betreff: New Version Notification for draft-drage-sipping-rfc3455bis-09.t= xt > > > A new version of I-D, draft-drage-sipping-rfc3455bis-09.txt > has been successfully submitted by Keith Drage and posted to the IETF > repository. > > Filename: draft-drage-sipping-rfc3455bis > Revision: 09 > Title: Private Header (P-Header) Extensions to the Session > Initiation Protocol (SIP) for the 3rd-Generation Partnership Project (3GP= P) > Creation date: 2013-10-08 > Group: Individual Submission > Number of pages: 47 > URL: > http://www.ietf.org/internet-drafts/draft-drage-sipping-rfc3455bis-09.txt > Status: > http://datatracker.ietf.org/doc/draft-drage-sipping-rfc3455bis > Htmlized: > http://tools.ietf.org/html/draft-drage-sipping-rfc3455bis-09 > Diff: > http://www.ietf.org/rfcdiff?url2=3Ddraft-drage-sipping-rfc3455bis-09 > > Abstract: > This document describes a set of private Session Initiation Protocol > (SIP) header fields (P-headers) used by the 3rd-Generation > Partnership Project (3GPP), along with their applicability, which is > limited to particular environments. The P-header fields are for a > variety of purposes within the networks that the partners use, > including charging and information about the networks a call > traverses. > > > > > Please note that it may take a couple of minutes from the time of > submission until the htmlized version and diff are available at > tools.ietf.org. > > The IETF Secretariat > > - > > > --047d7bb70ca2906bab04ee887d54 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi Roland,

Thanks for making these chan= ges. I finally had a chance to review this updated version. =A0 I still hav= e a couple comments on the security section as I think you will get questio= ns during SEC review around this unless some more detail is provided on sec= urity threats and impacts. =A0 I've extracted these few points from pre= vious review comment threads.

Thanks,
Mary.

----Pr= evious point =A0--------------------------------->
- Section 6.1: this needs some tighter wording. =
=A0What is meant by "potentially annoying" =A0for example? =A0=

=A0[RJ] I do not know. This is original text. So I deleted the words.<=
/pre>

-
[MB] So, you removed that part of the sentence a=
nd are left with:


"This attack should not have any significant im=
pacts."
I don&=
#39;t think that adds any value and just begs the question "what are t=
he insignificant impacts and are there any privacy concerns"?  Really,=
 it's the next paragraph that provides details of the impacts.  I think=
 you could probably remove that sentence altogether and not lose anything. =



[/MB]
----Previous point --------------------------------=
->


-  Section 6.2: I think you need to be more specific a=
bout the "nature" that makes this header not of particular concer=
n with regards to security. Does it reveal additional, unique information a=
bout an individual that isn't available in other headers. =A0Also, the =
2nd paragraph needs some work - maybe something like:


OLD:
<=
/pre>

An eavesdropper ma=
y collect the list of identities a user is registered.=A0 This may have pri=
vacy implications.=A0 To mitigate this problem, this extension SHOULD only =
be used in a secured environment, where encryption of SIP messages is provi=
ded either end-to-end or

hop-by-hop.=A0

NEW:=A0
An eavesdropper could possibly collect the list o=
f identities a user is registered.=A0 This can have privacy implications.=
=A0 To mitigate this problem, this extension MUST only be used in a secured=
 environment, where encryption of SIP messages is provided either end-to-en=
d or hop-by-hop.=A0


----End previous point --------=
----------------------<
=
[MB]  The suggested change for the first sentence didn't get in=
to the revision.  And, I believe you still need to identify privacy/securit=
y implications by addressing whether or not this header reveals any unique =
information about an individual that isn't available in other headers. =
  [/MB]







<=
pre style=3D"white-space:pre-wrap">



On Tue, Dec 3, 2013 at 7:00 AM, <R.Jesske@telekom.de> wrote:

Hi Mary,<= u>

Thank you = for your comments and proposals.

I have now included all comments = and uploaded a new version.

= So we can now proceed.<= /u>

=A0

Thank you and Best Regards

=A0=

Roland

=A0=

A new version of I-D, draft= -drage-sipping-rfc3455bis-10.txt

has been successfully submitted by Roland Jesske an= d posted to the IETF repository.

=A0

Filename:=A0=A0 = draft-drage-sipping-rfc3455bis

Revision:=A0=A0 10

Title:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = Private Header (P-Header) Extensions to the Session Initiation Protocol (S= IP) for the 3rd-Generation Partnership Project (3GPP)<= /p>

Creation date:=A0=A0=A0 2013-12-03=

Group:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 Individual Submission

= Number of pages: 46

URL:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 http://www.ietf.org/internet= -drafts/draft-drage-sipping-rfc3455bis-10.txt

Status:=A0=A0=A0=A0=A0=A0=A0=A0=A0 http://datatracker.ietf.org/doc/draft-drag= e-sipping-rfc3455bis

Htmlized:=A0=A0=A0=A0=A0=A0=A0 http://tools.ietf.org/html/draft-drage-sipping-rfc3= 455bis-10

Diff:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 http://www.ietf.org/rfcdiff?url2=3D= draft-drage-sipping-rfc3455bis-10=

=A0

Abstract:

=A0=A0 This document describes a set of private Session Initiation Protoc= ol

=A0=A0 (SIP) header fields (P-headers) used by the = 3rd-Generation

=A0=A0 Partn= ership Project (3GPP), along with their applicability, which is

=A0=A0 limited to particular environments.=A0 The P= -header fields are for a

= =A0=A0 variety of purposes within the networks that the partners use,

=A0=A0 including charging and information about the= networks a call

=A0=A0 traverses.

=A0

=A0

=A0=

Von: Mary Barn= es [mailto:= mary.ietf.barnes@gmail.com]
Gesendet: Montag, 25. November 2013 23:01


An: Jesske, Roland
Cc: DISPATCH; Gonzalo Camarillo; = Atle Monrad; Dean Willis
Betreff: Re: PROTO Review: draft-d= rage-sipping-rfc3455bis-09.txt

=A0

Hi Roland,

=A0

Thanks fo= r your response. =A0Additional comments below [MB].

=A0

Thanks,

M= ary.

=A0

On Thu, Nov 21, 2013 at 7:= 21 AM, <R.Jessk= e@telekom.de> wrote:

Hi Mary,<= /p>

Thank you = for your review.

I have added now your proposals to the draf= t.

Other comm= ents please see below.

=A0

I hope now= everything is OK.

=A0

Thank you = and Best Regards

=A0

Roland

=A0

Von: Mary Barnes [mailto:mary.ietf.barnes@gmail.com]
Gesendet: Dienstag, 29. Oktober 2013 17:27
An: Jesske, Rol= and
Cc: DISPATCH; Gonzalo Camarillo; Atle Monrad; Dean Willis
= Betreff: PROTO Review: draft-drage-sipping-rfc3455bis-09.txt<= u>

=A0

In preparation for the PROTO write-up, I have reviewed the document= in detail. =A0My detailed review was originally based on the -08, but I al= so reviewed the 09 diff. =A0There are a few errors that have been introduce= d in the -09 and many of my -08 comments remain - I've separated commen= ts from nits below. =A0A number of these comments are with regards to text = that was not changed from RFC 3455, but I think some of the text requires u= pdating and we need to keep in mind that this an entirely new IESG that wil= l be reviewing this document, so they won't have the same context of th= e IESG that approved RFC 3455. =A0I will note that I also have not validate= d the content of section 9 against a diff of this document and RFC 3455. = =A0I will need to do that before I progress the document unless the authors= can point me to another review that has done that.

=A0

Regards,

Mary.

=A0

Summary: =A0This document needs some work = prior to being progressed.=A0

= =A0

Comments:<= /u>

----------------

- Section 1. =A0I think you should be explicit that th= ese extensions apply only to a private network - saying they are "gene= rally not applicable" is too soft, so I would suggest some minor rewor= ding something like:

OLD:

=A0=A0 The SIP extensions =
specified in this document make certain
=A0<=
u>
=A0=A0 assumptions regarding network topology, linkage between SIP and=
 lower
=A0=A0 layers, and the availability of trans=
itive trust.=A0 These assumptions
=A0=A0 are genera=
lly NOT APPLICABLE in the Internet as a whole. 
=A0<=
/pre>

NEW:=A0

= 
=A0=

=A0=A0 The SIP extensions specified in this document make certain
=A0=A0 assumptions regarding network topology, linkage =
between SIP and lower
=A0=A0 layers, and the availa=
bility of transitive trust.=A0 These assumptions
=A0=A0 apply only to private networks and are not appropriate for use =
in an=A0Internet environment.
=A0
- Sect=
ion 3. =A0This section needs to be updated. =A0I don't think that 10 ye=
ar old background is relevant in the current context. =A0 You should be abl=
e to model this after the text in more recent 3GPP P-header documents, refe=
rring to the SIP change process.=A0
=A0
[RJ] OK, I have changed the text:

The Third Generation Partnership Project (3GPP) has sel= ected SIP as

=A0=A0=A0=A0 the protocol used to establish and tear do= wn multimedia sessions in the

=A0=A0=A0=A0 context of its IP Multimedia Subsystem (IM= S). For more information on

=A0=A0=A0=A0 the IMS, a detailed description can be fou= nd in 3GPP TS 23.228 . This document is an update of RFC3455=A0 =A0which co= vers the requirements in RFC4083 and describes updates and adds private ext= ensions to address those requirements which are needed in for 3GPP Release = 11. Each extension, or set of related extensions is described in its own se= ction below

[MB] I sugg= est just a bit more rewording. =A0Note that I didn't see that this docu= ment is adding any new headers=A0

=A0

=A0 =A0 The Third Generation Partnership Project (3GP= P) uses SIP as

=A0=A0=A0= =A0 the protocol =A0to establish and tear down multimedia sessions in the

=A0=A0=A0= =A0 context of its IP Multimedia Subsystem (IMS), as described in=A0=

=A0 =A0 = =A0the 3GPP TS 23.228 specification.=A0

=A0 =A0 =A0RFC 3455 d= efines SIP private header extensions (referred to as P-headers) which are= =A0

=A0 =A0 = =A0required by the 3GPP specification. Note that the requirements for these= extensions

=A0 =A0 = =A0are documented in RFC 4083. =A0=A0This= document is an update to RFC3455.=A0

=A0 =A0 = =A0This document updates existing P-header=A0descriptions=A0

=A0 =A0 =A0to address add= itional requirements which are needed for 3GPP Release 11.=A0=

=A0 =A0 =A0Each of the P-= headers is described in the sections below.

<= div>

=A0

[/MB]=A0

=A0

- Section 4.1. "registered addr=
ess-of-record" -> "registered SIP address-of-record"
- Section 4.1, 3rd paragraph. =A0"Note t=
hat, generally speaking," -> "Note that in standard SIP usage =
[RFC3261]"
- Section 4.1.2.3. =A0I don't think this =
is stated properly. =A0I think the intent is that this header is not applic=
able to proxies, therefore the proxy MUST relay the header field unchanged.=
 =A0I would suggest rewording something like:
OLD:=A0
=A0=A0 This memo does not define any procedure at=
 the proxy.=A0 The proxy does
=A0=A0 not add, read, modify or delete the header field, and therefore=
 any
=A0=A0 proxy will relay this header field unch=
anged.
=A0=

N=
EW:
=A0
=A0=A0 This header is not intended to be used by proxies=
 - a proxy does
=A0=A0 not add, read, modify or delete the header field, and therefore=
 any
=A0=A0 proxy MUST relay this header field unch=
anged.
=A0
Section 4.2, 1st paragraph. =A0The beha=
vior in this sentence is not normative from a SIP protocol perspective, thu=
s MAY is not appropriate. =A0I suggest the MAY be changed to "can"=
;. =A0=A0
=A0=A0 The UAS MAY=
 use the information to render different distinctive audiovisual alerting
=A0=A0 tones, depending on the URI used to receive t=
he invitation to the
=A0=A0 session.
Section 4.2.2.2, 2nd paragraph. =A0The behavior in this sentence i=
s not normative from a SIP protocol perspective, thus =A0I suggest the MAY =
be changed to "can".=A0
=A0
- Section 4.3.3, =
last paragraph. =A0I think this ought to be a MUST: "The identifier sh=
ould be globally unique.."=A0
=A0
- Section 4.3.2.1=
. =A0This text has changed from the -08. =A0 I don't know what a "=
normal User Equipment" is and the term "User Equipment" is n=
ot defined in this specification. =A0I think it would be better to say some=
thing like. However, even with this proposed change, I think you also need =
text for user agent server behavior - i.e., what would a UAS do if it recei=
ved this header.=A0
=A0
OLD:
=A0=
=A0 A normal User Equipment has normally no knowledge of the P-Visited-<=
/u>
=A0=A0 Network-ID when sending the REGISTER.=A0 Therefore user agent c=
lients
=A0=A0 do not insert a P-Visited-Network-ID =
header field in any SIP message.
NEW:=
=A0
=A0=A0 In=
 the context of the network to which the header fields defined in this docu=
ment apply, a User Agent has=A0no knowledge of the P-Visited-Network-ID whe=
n sending the REGISTER request. =A0Therefore user agent clients MUST NOT in=
sert a P-Visited-Network-ID=A0header field=A0in any SIP message.<=
/u>
=A0
- Section 4.3.2.2:, 2nd paragraph: =A0"=
;home network MAY use" -> "home network can use"

=A0
- Section 4.3.2.2, last paragraph: =A0
=A0<=
/pre>
=A0
OLD: Note that a received P-Visited-=
Network-ID from a UA is a failure case and must be deleted.

=A0<=
/pre>
NEW: =A0Note that a received P-Visited-Network-ID from a UA is a=
 failure case and MUST be deleted when the request is forwarded. =



=A0<=
/pre>
Section 4.4.2.1, 2nd paragraph: =A0"MUST trust the p=
roxy" -> "MUST have a trust relationship with the proxy"=
=A0


=A0<=
/pre>
Section 4.4.2.1, 3rd paragraph: =A0"there must also =
be a transitive trust" -> =A0"there MUST also be a transitive =
trust"=A0


Section 4.4.2.2, 2nd paragraph:=
 "MAY act upon any information present" -> "can act upon =
any information present", =A0"MAY use the call id" -> &qu=
ot;can use the=A0call id"=A0


Section 4.5.2: 2nd paragraph: "MAY use t=
he hostnames" -> "can use the hostnames"=A0=



=A0
=A0<=
u>
Section 4.5.2.1 2nd paragraph: "MAY use the contents" =
-> "can use the=A0contents"=A0


=A0
- Sec= tion 4.6.2, 3rd paragraph: "MAY use the values" -> "can u= se the values"=A0 
- Section 4.6.3, 3rd paragraph: needs so=
me editorial work. =A0Maybe the following change would work:=A0
=A0
OLD:
=A0=
=A0 Depending on the call scenario it is needed to add for each transit<=
/u>
=A0=A0 network either a transit network name or a void value. =A0Never=
theless
=A0=A0 it can not be guaranteed that all va=
lues will appear within the P-Charging-Vector header field.=A0
NEW:=
=A0
=A0
=A0=
=A0 Depending on the call scenario, each transit network can add either a t=
ransit network name=A0or a void=A0=A0=A0 value.=A0 However, it can not be g=
uaranteed that all the values that are added will appear within the P-Charg=
ing-Vector header field.
=A0
- S=
ection 4.6.3, next to last paragraph:=A0"which needs to be incremented=
" -> "which MUST be incremented"

=A0
- Section 4.6.3, last paragraph. =A0I have no idea what t=
hat is trying to say other than void values have no index. =A0What does &qu=
ot;taken into consideration" mean. Are you talking about limits on the=
 number of entries or are you suggesting that the number of void values mus=
t be considered when setting the index for the transit network names? =A0


=A0
[RJ] Yes! Changed the text to:
=A0
A void value has no =
index. By adding the next value the index has to be incremented by the numb=
er of void entries +1.


=A0
- Section=
 4.6.4.2: I don't know w=
hat this means:=A0=A0"A deletion of the elements could=
 appear depending on the network policy and trust rules". =A0Is it ju=
st trying to say that along with the adding and modifying in the previous s=
entence that the elements can also be deleted by the proxy?=A0


=A0
[RJ] Yes, I have changed the text:<=
/span>


Procedures described within 4.6.2.2 apply. A transit-io=
i MAY be


=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 added or modified by a p=
roxy. A deletion of the transit-ioi or a entry within the tranist-ioi could=



=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 appear depending on the =
network policy and trust rules. This is


=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0 also valid by replacing the transit-ioi with a void value.
=A0
=A0
- Sect=
ion 5.7. Delete this text and table. =A0 We aren't these tables anymore=
 as they really don't provide any useful information. =A0You just need =
to verbally state what messages these headers can appear in.=A0
=A0
[RJ] OK
=A0
So I changed 5.7 to =93New header=94

The P-Associated-URI can appear in SIP REGISTER m= ethod and 2xx resonses, P-Called-Party-ID can appear in SIP INVITE, OPTIONS= , PUBLISH,SUBSCRIBE, MESSAGE methods and all responses, P-Visited-Network-I= D can appear in all SIP methods except ACK, BYE and CANCEL and all response= s, P-Access-Network-Info can appear in all SIP methods exept ACK and CANCEL= , P-Charging-Vector=A0 can appear in all SIP methods exept CANCEL and the P= -Charging-Function-Addresses can appear in all SIP methods exept ACK and CA= NCEL.

[MB] I suggest you put each of these in separate sentences - i.e., rather= than use comma separators, use a period. =A0You should also spell out that= these are header fields - i.e., "The P-Associated-URI header field ca= n appear....2xx responses. =A0 The P-Called-Party-ID header field....

=A0=

=A0
- Section 6.1: this needs some tighter wording. =A0What is meant=
 by "potentially annoying" =A0for example? =A0
=A0
[RJ] I do not know. This is origina=
l text. So I deleted the words.
=A0=

- Section 6.2: I think you need to be more specific about t=
he "nature" that makes this header not of particular concern with=
 regards to security. Does it reveal additional, unique information about a=
n individual that isn't available in other headers. =A0Also, the 2nd pa=
ragraph needs some work - maybe something like:
=A0
OLD:
An e=
avesdropper may collect the list of identities a user is registered.=A0 Thi=
s may have privacy implications.=A0 To mitigate this problem, this extensio=
n SHOULD only be used in a secured environment, where encryption of SIP mes=
sages is provided either end-to-end or


=A0
hop-by-hop.=A0<=
/u>
=A0 =A0
NEW:=A0


=A0
=A0An eave=
sdropper could possibly collect the list of identities a user is registered=
.=A0 This can have privacy implications.=A0 To mitigate this problem, this =
extension MUST only be used in a secured environment, where encryption of S=
IP messages is provided either end-to-end or hop-by-hop.=A0

=A0

[MB] =A0So, = I think the first sentence is trying to say: "An eavesdropper could possibly collect the list of identities a user = has registered."

or =A0"= ;An eavesdropper could possibly collect the list of identities registered b= y a user."=A0

[/MB]=A0=A0

- S= ection 6.4,=A0 
--3rd paragraph: "should not" ->=
 "MUST NOT"=A0
=A0

-- 7th paragraph: =A0"SHOULD NOT be sent=
" -> "MUST NOT be sent"=A0

=A0
=A0
-- 8th paragraph: "S=
HOULD NOT send sensitive information" -> "MUST NOT send sensit=
ive information"
=A0
=A0<=
u>
-- 9th paragraph: "is required to delete" -> "=
is REQUIRED to delete"=A0
=A0
-- 10th paragraph=
: =A0How does a network ensure the information is not of a sensitive nature=
? =A0 I would think that the information just should not be sent outside of=
 the trust domain. =A0I believe that's consistent with the scope of the=
se headers, is it not?
=A0
[RJ] Yes that is also my understand=
ing so I deleted that paragraph. I think the rest is sufficient and describ=
ed well how to behave.
=A0
-- 11th paragraph: So, =
what does a proxy do with that information. =A0What are the implications i=
f the information is used and it's not valid? =A0<=
/pre>

[RJ] Yes I did some ch=
anges as follows.
=A0

=A0=A0=A0=A0=A0=A0=A0 <t>A proxy receiving a mess= age containing the P-Access-Network-Info

=A0=A0=A0=A0=A0=A0 header field from a non-trusted enti= ty is not able to guarantee the

=A0=A0=A0=A0=A0=A0 validity =
of the contents. Thus this content SHOULD be deleted based on local policy.=
</t>
=A0
- Section 9, item 2. =A0I think you need to add this text w=
ith regards to the recommendation to use RFC 4244 (bis) to the body of this=
 document and include a real reference.
=A0
[RJ] OK done. I let the referenc= e RFC4244 since 3GPP uses currently only RFC4244. 
Replaced following text:
With =
section 9.2
=A0=A0=A0=A0=A0=A0 <t>=
Requirements for a more general solution are proposed in <xref=

=A0=A0=A0=A0=A0=A0=A0=A0 tar=
get=3D"RFC4244"></xref>. 3GPP will continue to use the
=A0=A0=A0=A0=A0=A0=A0=A0 P-C=
alled-Party-ID header field even though RFC 4244 <xref<=
/u>
=A0=A0=A0=A0=A0=A0=
=A0=A0 target=3D"RFC4244"></xref> has now been published=
.</t>
=A0
I think the text in Sectio=
n 9.2 is better.


Nits:
=A0
- Section 4.1, 2nd paragraph. =A0"=
has associated to an address-of-record" -> "has associated wit=
h an address-of-record"


- Section =
4.1.2.2, 2nd paragraph, "In case" -> "If", =A0"=
shall not" -> SHALL NOT


- Section 4.3.2.2, last =
sentence. =A0The -09 introduced a typo: "T means" -> "Thi=
s means"=A0


=A0
- Section 4.3.2.3, 1st paragraph after 1st example. =A0The -09 introduc=
ed another typo: "the REGISTRAR" -> "at the REGISTRAR&quo=
t;


=A0
Section 4.2.2.1, 3rd paragraph: =A0"there must also =
be a transitive trust" -> =A0"there MUST also be a transitive =
trust"=A0


=A0
Section 4.6, 2nd paragraph: "includes, includes but =
is not limited to" -> "includes, but is not limited to,"=
=A0


=A0
Section 4.6.2.2, 1st paragraph: "one ore more" =
-> "one or more"=A0


=A0
=A0
=A0

On Tue, Oct 8, 2013 at 11:58 AM, <R.Jesske@telekom.de> wrote:

Dear all,
I would like= to inform you that I have implemented all comments coming from the expert = review done by Dean Willis. Also an editorial cleanup was made.

If there are still some comments that needs to be implemented please in= form me.

From my side I would be happy to proceed the draft further = towards publication.

Thank you and Best Regards

Roland


-----Urspr=FCngliche Nachricht-----
Von: internet-drafts@ietf.org [mailto= :internet-dra= fts@ietf.org]
Gesendet: Dienstag, 8. Oktober 2013 13:40
An: Christer Holmberg; Keith D= rage; Jesske, Roland
Betreff: New Version Notification for draft-drage-s= ipping-rfc3455bis-09.txt


A new version of I-D, draft-drage-sippi= ng-rfc3455bis-09.txt
has been successfully submitted by Keith Drage and posted to the IETF repos= itory.

Filename: =A0 =A0 =A0 =A0draft-drage-sipping-rfc3455bis
Re= vision: =A0 =A0 =A0 =A009
Title: =A0 =A0 =A0 =A0 =A0 Private Header (P-H= eader) Extensions to the Session Initiation Protocol (SIP) for the 3rd-Gene= ration Partnership Project (3GPP)
Creation date: =A0 2013-10-08
Group: =A0 =A0 =A0 =A0 =A0 Individual Subm= ission
Number of pages: 47
URL: =A0 =A0 =A0 =A0 =A0 =A0 http://www.ietf.org/internet-drafts/draft-drage-sipping-rfc= 3455bis-09.txt
Status: =A0 =A0 =A0 =A0 =A0http://datatracker.ietf.org/do= c/draft-drage-sipping-rfc3455bis
Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org/html/draft-drage-sipping-rfc3455bis-09
Diff: =A0 =A0 =A0 =A0 =A0 =A0http://www.ietf.org/rf= cdiff?url2=3Ddraft-drage-sipping-rfc3455bis-09

Abstract:
=A0 = =A0This document describes a set of private Session Initiation Protocol
=A0 =A0(SIP) header fields (P-headers) used by the 3rd-Generation
=A0 = =A0Partnership Project (3GPP), along with their applicability, which is
= =A0 =A0limited to particular environments. =A0The P-header fields are for a=
=A0 =A0variety of purposes within the networks that the partners use, =A0 =A0including charging and information about the networks a call
=A0 = =A0traverses.




Please note that it may take a couple of m= inutes from the time of submission until the htmlized version and diff are = available at tools.ietf= .org.

The IETF Secretariat

=A0 = -

=A0


--047d7bb70ca2906bab04ee887d54--