From R.Jesske@telekom.de Thu Jan 2 01:30:26 2014 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 CCDCA1AE20F for ; Thu, 2 Jan 2014 01:30:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.214 X-Spam-Level: X-Spam-Status: No, score=0.214 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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.538] 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 DDBfrzBKodrU for ; Thu, 2 Jan 2014 01:30:13 -0800 (PST) Received: from tcmail23.telekom.de (tcmail23.telekom.de [80.149.113.243]) by ietfa.amsl.com (Postfix) with ESMTP id D45F61AE0C3 for ; Thu, 2 Jan 2014 01:30:09 -0800 (PST) Received: from he110890.emea1.cds.t-internal.com ([10.134.92.131]) by tcmail21.telekom.de with ESMTP/TLS/AES128-SHA; 02 Jan 2014 10:30:01 +0100 Received: from HE113667.emea1.cds.t-internal.com ([fe80::c943:1394:e86e:fce3]) by he110890 ([10.134.92.131]) with mapi; Thu, 2 Jan 2014 10:30:01 +0100 From: To: Date: Thu, 2 Jan 2014 10:29:59 +0100 Thread-Topic: PROTO Review: draft-drage-sipping-rfc3455bis-09.txt Thread-Index: Ac8DM78u7dml3KeLS8SXaKfbLvLDbQEW+s2w Message-ID: <058CE00BD4D6B94FAD033A2439EA1E4B01DF8E83EB24@HE113667.emea1.cds.t-internal.com> References: <058CE00BD4D6B94FAD033A2439EA1E4B01DEBB69CC8A@HE113667.emea1.cds.t-internal.com> <058CE00BD4D6B94FAD033A2439EA1E4B01DF27DB8A63@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_058CE00BD4D6B94FAD033A2439EA1E4B01DF8E83EB24HE113667eme_" 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: Thu, 02 Jan 2014 09:30:27 -0000 --_000_058CE00BD4D6B94FAD033A2439EA1E4B01DF8E83EB24HE113667eme_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Mary, I wish you a happy new year 2014. And the best for the next year. I was looking again on my changes I made due to your proposal in December. I realized that if I change the SHOULD to MUST we have now a backward compa= tibility problem. We are using the P-Associated-URI also over the IMS user interface which is= not encrypted. So I propose to add some more words. ... Section 6.1 ... An eavesdropper could possibly collect the list of identities a= user is registered. This can have privacy implications. To mitigate this problem, this e= xtension SHOULD only be used in a secured environment, where encryption of SIP messa= ges is provided either end-to-end or hop-by-hop. Since the P-Associated-URI header field value allows to implicitl= y register a bundle of URIs with one REGISTER Message the impact of security usi= ng the P-Associated-URI header field is not higher than using single REGISTER messages when registering all identities explic= it. For the P-Called-Party-Id the change should be also done like as follows: An eavesdropper could possibly collect the list of identities a = user is registered. This can have privacy implications. To mitigate this problem, this = extension SHOULD only be used in a secured environment, where encryption of SIP messa= ges is provided either end-to-end or hop-by-hop. Normally within a 3GPP environment the P-Called-Party-ID is not = sent towards end users but may be exchanged between carriers where other se= curity mechanisms than SIP encryption are used. Sorry coming so late. If this is OK for you I will include it to a new version. Thank you and Best Regards Roland Von: Mary Barnes [mailto:mary.ietf.barnes@gmail.com] Gesendet: Freitag, 27. Dezember 2013 19:45 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 making these changes. I finally had a chance to review this upda= ted 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 "potentia= lly 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 th= e next paragraph that provides details of the impacts. I think you could p= robably 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" tha= t makes this header not of particular concern with regards to security. Doe= s it reveal additional, unique information about an individual that isn't a= vailable 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 reg= istered. This can have privacy implications. To mitigate this problem, th= is extension MUST only be used in a secured environment, where encryption o= f 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 revis= ion. And, I believe you still need to identify privacy/security implicatio= ns 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 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_058CE00BD4D6B94FAD033A2439EA1E4B01DF8E83EB24HE113667eme_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Mary,

I = wish you a happy new year 2014. And the best for the next year.<= /span>

 =

I was looking again on my chan= ges I made due to your proposal in December.

I realized that if I change the SHOULD to = MUST we have now a backward compatibility problem.

We are using the P-Associated-URI als= o over the IMS user interface which is not encrypted.

=

So I propose to add some more word= s.

…

Section 6.1

…

=A0=A0= =A0=A0=A0=A0=A0=A0 <t>An eave= sdropper could possibly collect the list of identities a user is registered= .=A0

=A0=A0=A0=A0=A0=A0=A0This can have privacy implications. To mitigate = this problem, this extension SHOULD

=A0=A0=A0=A0=A0=A0=A0only be used in a= secured environment, where encryption of SIP messages is

=A0=A0=A0=A0=A0= =A0=A0provided either end-to-end or hop-by-hop.=A0 </t>

=A0=A0

=A0=A0=A0=A0=A0=A0<<= span lang=3DEN-US style=3D'color:maroon;background:white;mso-highlight:whit= e'>t> Since the P-Associated-URI header field value a= llows to implicitly register

=A0=A0=A0=A0=A0=A0a bundle of URIs with one R= EGISTER Message the impact of security using the P-Associated-URI header fi= eld is not higher than=A0

=A0= =A0=A0=A0=A0=A0using single REGISTER messages when registering all identiti= es explicit.</t>

 

 

For the P-Called= -Party-Id the change should be also done like as follows:=

 = ;

=A0= =A0=A0=A0=A0=A0=A0 <t>An eave= sdropper could possibly collect the list of identities a user is registered= .=A0

=A0=A0=A0=A0=A0=A0=A0This can have privacy implications.=A0 To mitiga= te this problem, this extension SHOULD

=A0=A0=A0=A0=A0=A0=A0only be used i= n a secured environment, where encryption of SIP messages is

=A0=A0=A0=A0=A0=A0=A0provided either end-to= -end or hop-by-hop.=A0 </t>

&n= bsp;

= =A0=A0=A0=A0=A0=A0=A0 <t>Norma= lly within a 3GPP environment the P-Called-Party-ID is not sent towards end= users but may be exchanged between carriers where other security mechanism= s than SIP encryption are used.=A0 </t><= /span>

 

Sorry coming so late.

<= span lang=3DEN-US style=3D'font-size:11.0pt;font-family:"Calibri","sans-ser= if";color:#1F497D'>If this is OK for you I will include it to a new version= .

 =

Thank you and Bes= t Regards

 

Roland

 

Von: Mary Barnes [mailto:mary.ietf= .barnes@gmail.com]
Gesendet: Freitag, 27. Dezember 2013 19:45An: Jesske, Roland
Cc: DISPATCH; Gonzalo Camarillo; Atle = Monrad; Dean Willis
Betreff: Re: PROTO Review: draft-drage-sippin= g-rfc3455bis-09.txt

&n= bsp;

Hi Roland,

 

Thanks= for making these changes. I finally had a chance to review this updated ve= rsion.   I still have a couple comments on the security section as I t= hink you will get questions during SEC review around this unless some more = detail is provided on security threats and impacts.   I've extracted t= hese few points from previous review comment threads.

<= div>

 

Thanks,

Mary.

 

----Previous point  --------------------------------->= 

- Section 6.1: this needs some tighter wording.  What is meant by &qu=
ot;potentially annoying"  for example?  
 [RJ] I do not know. This is original text. So I del=
eted the words.
-
[=
MB] So, you removed that part of the sentence and are left with:
&qu=
ot;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 concern=
s"?=A0 Really, it's the next paragraph that provides details of the im=
pacts.=A0 I think you could probably remove that sentence altogether and no=
t lose anything. 

[/MB]
----Previous point ---------------------------------><=
span style=3D'color:#500050'>
-=A0 Section 6.2: I think you need to be more specific abou=
t the "nature" that makes this header not of particular concern w=
ith regards to security. Does it reveal additional, unique information abou=
t an individual that isn't available in other headers.  Also, the 2nd =
paragraph needs some work - maybe something like:

OLD:
An eav=
esdropper may collect the list of identities a user is registered.  Th=
is may have privacy implications.  To mitigate this problem, this exte=
nsion SHOULD only be used in a secured environment, where encryption of SIP=
 messages is provided either end-to-end or

<=
pre>hop-by-h=
op. 
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, wh=
ere encryption of SIP messages is provided either end-to-end or hop-by-hop.=
 
----End previous point -----------------=
-------------<
[MB]=A0 The suggested change =
for the first sentence didn't get into the revision.=A0 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.=A0=A0 [/MB]
 


 


 

<= p class=3DMsoNormal style=3D'margin-bottom:12.0pt'> 

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

Hi Mary,

Thank you for your comments and proposals.=

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

So w= e can now proceed.

&nb= sp;

Thank you and Best Rega= rds

 

Roland

 

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

<= p>has been successfully submitted by Roland Jesske and p= osted to the IETF repository.

&n= bsp;

Filename:   draft= -drage-sipping-rfc3455bis

Revisi= on:   10

Title:&n= bsp;           Private He= ader (P-Header) Extensions to the Session Initiation Protocol (SIP) for the= 3rd-Generation Partnership Project (3GPP)

Creation date:    2013-12-03

Group:      &nbs= p;     Individual Submission

Number of pages: 46

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

Status:      = ;    http://data= tracker.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

=  

Abstra= ct:

   This document d= escribes 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 env= ironments.  The P-header fields are for a

   variety of purposes within the networks that th= e partners use,

   inc= luding charging and information about the networks a call=

   traverses.

&= nbsp;

 

=

 

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


= An: Jesske, Roland
Cc: DISPATCH; Gonzalo Camarillo; Atle M= onrad; Dean Willis

Betreff:= Re: PROTO Review: draft-drage-sipping-rfc3455bis-09.txt

 

Hi Roland,

 

Thanks for your respon= se.  Additional comments below [MB].

&= nbsp;

Thanks,

Mary.

 

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

Hi Mary,

Thank you for your review.

I have added now your proposals to the draft.

Other comments please see below.<= /p>

 

I hope now everything is OK.

<= span lang=3DEN-US style=3D'font-size:11.0pt;font-family:"Calibri","sans-ser= if";color:#1F497D'> 

Thank you and Best Regards

 

Roland<= /o:p>

 

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 PRO= TO write-up, I have reviewed the document in detail.  My detailed revi= ew was originally based on the -08, but I also reviewed 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 below.  A numb= er 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 i= n 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. &n= bsp;I will note that I also have not validated the content of section 9 aga= inst a diff of this document and RFC 3455.  I will need to do that bef= ore I progress the document unless the authors can point me to another revi= ew that has done that.

 

Regards,

Mary.

 

Summar= y:  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 appli= cable" is too soft, so I would suggest some minor rewording something = like:

OLD:

   The SIP exte=
nsions specified in this document make certain
 <=
o:p>
   assumptions regarding network topology, l=
inkage between SIP and lower
   layers, and =
the availability of transitive trust.  These assumptions
   are generally NOT APPLICABLE in the Internet as a whol=
e. 
 

NEW: 

<= div>
 
   The SIP extensions specified in this docume=
nt make certain
   assumptions regarding net=
work topology, linkage between SIP and lower
 &nb=
sp; layers, and the availability of transitive trust.  These assumptio=
ns
   apply only to private networks and are=
 not appropriate for use in an Internet environment.
<= pre style=3D'word-wrap:break-word;white-space:pre-wrap'> 
 
- Section 3.  This section n=
eeds to be updated.  I don't think that 10 year old background is rele=
vant in the current context.   You should be able to model this after =
the text in more recent 3GPP P-header documents, referring to the SIP chang=
e process. 
 
[RJ] OK, I have changed the text:

The Thir= d Generation Partnership Project (3GPP) has selected SIP as

   &nbs= p; the protocol used to establish and tear down multimedia sessions in the<= /span>

 &= nbsp;   context of its IP Multimedia Subsystem (IMS). For more in= formation on

     the IMS, a detailed description can be found= in 3GPP TS 23.228 . This document is an update of RFC3455   whic= h covers the requirements in RFC4083 and describes updates and adds private= extensions to address those requirements which are needed in for 3GPP Rele= ase 11. Each extension, or set of related extensions is described in its ow= n section below

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

 

&n= bsp;   The Third Generation Partnership Project (3GPP) uses SIP as

     the p= rotocol  to establish and tear down multimedia sessions in the<= o:p>

     context o= f its IP Multimedia Subsystem (IMS), as described in 

     the 3GPP TS 23.228 spec= ification. 

  &nb= sp;  RFC 3455 defines SIP private header extensions (referred to as P-= headers) which are 

&n= bsp;    required by the 3GPP specification. Note that the require= ments for these extensions

     are documented in RFC 4083.   = This document is an update to RFC3455. 

<= span lang=3DEN-US style=3D'font-size:11.0pt;font-family:"Calibri","sans-ser= if";color:#1F497D'>     This document updates existing P-hea= der descriptions 

     to address additional requirements which are needed f= or 3GPP Release 11. 

   = ;  Each of the P-headers is described in the sections below.

 

[/MB]&= nbsp;

 

- Section 4.1. "registered address-of-record&qu=
ot; -> "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 t=
his is stated properly.  I think the intent is that this header is not=
 applicable to proxies, therefore the proxy MUST relay the header field unc=
hanged.  I would suggest rewording something like:
OLD: 
   This memo does not define any procedure at the proxy.=
  The proxy does
   not add, read, modi=
fy 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
&=
nbsp;  not add, read, modify or delete the header field, and therefore=
 any
   proxy MUST relay this header field u=
nchanged.
 
 
Section 4.2, 1st paragr=
aph.  The behavior in this sentence is not normative from a SIP protoc=
ol perspective, thus MAY is not appropriate.  I suggest the MAY be cha=
nged to "can".   
   The UAS MAY use the=
 information to render different distinctive audiovisual alerting
   tones, depending on the URI used to receive the in=
vitation to the
   session.
=

Section 4.2.2.2, 2nd paragraph.  The behavior =
in this sentence is not normative from a SIP protocol perspective, thus &nb=
sp;I suggest the MAY be changed to "can". =

 
- Section 4.3.3, last paragraph=
.  I think this ought to be a MUST: "The identifier should be glo=
bally unique.." 
 
- Section 4.3.2.1.  This text has changed from the -08. &=
nbsp; I don't know what a "normal User Equipment" is and the term=
 "User Equipment" is not defined in this specification.  I t=
hink it would be better to say something like. However, even with this prop=
osed 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 the REGISTER.  Therefore us=
er agent clients
   do not insert a P-Visite=
d-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 kno=
wledge of the P-Visited-Network-ID when sending the REGISTER request.  =
;Therefore user agent clients MUST NOT insert a P-Visited-Network-ID h=
eader field in any SIP message.
 =

- Section 4.3.=
2.2:, 2nd paragraph:  "home network MAY use" -> "=
;home network can use"

 =

 
- Se=
ction 4.3.2.2, last paragraph:  
 
&nbs=
p;
OL=
D: 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:  "M=
UST trust the proxy" -> "MUST have a trust relationship with t=
he proxy" 
 
Section 4.4.2.1, 3rd paragraph: &=
nbsp;"there must also be a transitive trust" ->  "th=
ere 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&=
quot;,  "MAY use the call id" -> "can use the <=
/span>call id" <=
/span>
Section 4.5.2: 2nd paragraph: "MAY us=
e the hostnames" -> "can use the hostnames" <=
o:p>
 
=

 
Section 4.5.2.1 2nd paragraph: "MAY use the contents" ->=
; "can use the contents" 
= 
 
- Section 4.6.2, 3rd paragraph:=
 "MAY use the values" -> "can use the values" <=
/span>
- Section 4.6.3, 3rd paragraph: needs=
 some editorial work.  Maybe the following change would work: 
 <=
/pre>
OLD:=

 =
  Depending on the call scenario it is needed to add for each transit<=
o:p>
   network either a transit network name or =
a void value.  Nevertheless
   it can n=
ot be guaranteed that all values will appear within the P-Charging-Vector h=
eader field. 
 
NE=
W: 
 <=
o:p>
&n=
bsp;  Depending on the call scenario, each transit network can add eit=
her a transit network name or a void    value.  Ho=
wever, it can not be guaranteed that all the values that are added will app=
ear within the P-Charging-Vector header field.
 <=
o:p>
- Section 4.6.3, next to last parag=
raph: "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 hav=
e no index.  What does "taken into consideration" mean. Are =
you talking about limits on the number of entries or are you suggesting tha=
t the number of void values must be considered when setting the index for t=
he transit network names?  
 <=
/span>
[RJ] Yes! Changed the=
 text to:
 
A void valu=
e has no index. By adding the next value the index has to be incremented by=
 the number of void entries +1.
 
- Section 4.6.=
4.2: I don't know what this means:  "A deletion=
 of the elements could appear depending on the network policy and trust rul=
es".  Is =
it just trying to say that along with the adding and modifying in the previ=
ous 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

       &nbs= p;   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

   &nb=
sp;       also valid by replacing the transit=
-ioi with a void value.
 <=
/pre>
 
 
=
 
- 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 verbally state what messages these headers can appear in. 
 
<=
span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F=
497D'>[RJ] OK
 
So I changed 5.7 to “New header”
The P-Associated-URI can appear in SIP REGISTER metho=
d and 2xx resonses, P-Called-Party-ID can appear in SIP INVITE, OPTIONS, PU=
BLISH,SUBSCRIBE, MESSAGE methods and all responses, P-Visited-Network-ID ca=
n 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 CAN=
CEL.
=

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

= 
 
 
=
- Section 6.1: this needs =
some tighter wording.  What is meant by "potentially annoying&quo=
t;  for example?  
 
[RJ] I do not know. This =
is original text. So I deleted the words.
 <=
/pre>
- 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 re=
veal additional, unique information about an individual that isn't availabl=
e in other headers.  Also, the 2nd paragraph needs some work - maybe s=
omething like:
 
OLD:
An eavesdropper may collect the list of identities a user is reg=
istered.  This may have privacy implications.  To mitigate this p=
roblem, this extension SHOULD only be used in a secured environment, where =
encryption of SIP messages is provided either end-to-end or

 
 
hop-b=
y-hop. 
  &nb=
sp;
NEW: 
 =

 An eavesdropper could possibly coll=
ect the list of identities a user is registered.  This can have privac=
y implications.  To mitigate this problem, this extension MUST only be=
 used in a secured environment, where encryption of SIP messages is provide=
d either end-to-end or hop-by-hop. 
=

 

[MB]  So, I think the first sentence is trying to say: &q= uot;An eavesdropper could possibly collect th= e list of identities a user has registered."

or  "An eavesdropper = could possibly collect the list of identities registered by a user."&n= bsp;

[= /MB]  

- Section 6.4, 
--3rd paragraph: "should not" ->=
; "MUST NOT" 
 <=
/pre>
-- 7th paragraph:  "SHOULD NOT be sent" ->=
 "MUST NOT be sent" 
 
 
 
-- 8th paragraph: "SHOULD NOT send sensitive information" ->=
; "MUST NOT send sensitive information"
 
 
-- 9th para=
graph: "is required to delete" -> "is REQUIRED to delete&=
quot; 
&nbs=
p;
--=
 10th paragraph:  How does a network ensure the information is not of =
a sensitive nature?   I would think that the information just should n=
ot be sent outside of the trust domain.  I believe that's consistent w=
ith the scope of these headers, is it not?
 
[RJ] Yes th=
at is also my understanding so I deleted that paragraph. I think the rest i=
s sufficient and described well how to behave.
= 
 
-- 11th paragraph: So, what does a proxy do with that information.  =
;What are the impli=
cations if the information is used and it's not valid?  
[RJ] Yes I did some changes as fol=
lows.
 

   &= nbsp;    <t>A proxy receiving a message containing the= P-Access-Network-Info

       header field from a no= n-trusted entity is not able to guarantee the

       validity of the conte=
nts. Thus this content SHOULD be deleted based on local policy.</t>
 =

- Section 9, item 2.  I think you need to add this tex=
t with regards to the recommendation to use RFC 4244 (bis) to the body of t=
his document and include a real reference.
 
[RJ] OK done. I let the reference RFC4244 since 3GPP uses curre=
ntly only RFC4244. 
Replace=
d following text:
With sect=
ion 9.2
   &=
nbsp;   <t>Requirements for a more general solution are pro=
posed in <xref
 &nb=
sp;       target=3D"RFC4244"><=
;/xref>. 3GPP will continue to use the
         P-Called-Pa=
rty-ID header field even though RFC 4244 <xref
         tar= get=3D"RFC4244"></xref> has now been published.</t>= ;
 <=
/pre>
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&=
quot; -> SHALL NOT
- Section 4.3.2.2, last sentence.  The -09 introduced a typo: "T=
 means" -> "This means" 
 
- Section 4.3.2.3, 1=
st paragraph after 1st example.  The -09 introduced another typo: &quo=
t;the REGISTRAR" -> "at the REGISTRAR"<=
/pre>
 
Section 4.2.2.1, 3rd paragraph:  "there must also be a transit=
ive trust" ->  "there MUST also be a transitive trust&quo=
t; 
 
Section 4.6, 2nd paragraph: "includes, i=
ncludes but is not limited to" -> "includes, but is not limite=
d to," 
 
Section 4.6.2.2, 1st paragraph: &quo=
t;one ore more" -> "one or more" <=
/pre>
 
 
 

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 editori= al 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 pr= oceed the draft further towards publication.

Thank you and Best Rega= rds

Roland


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

<= br>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-rfc3455bisRevision:        09
Title:       &nb= sp;   Private Header (P-Header) Extensions to the Session Initiation P= rotocol (SIP) for the 3rd-Generation Partnership Project (3GPP)
Creation= date:   2013-10-08
Group:           Indiv= idual Submission
Number of pages: 47
URL:        =     http://www.ietf.org/internet-dr= afts/draft-drage-sipping-rfc3455bis-09.txt
Status:     &nb= sp;    http://datatracker.ietf.org/doc/draft-dr= age-sipping-rfc3455bis
Htmlized:        http://tools.ietf.org/html/draft-drage-sipping-rfc3455bis-09Diff:            ht= tp://www.ietf.org/rfcdiff?url2=3Ddraft-drage-sipping-rfc3455bis-09
<= br>Abstract:
   This document describes a set of private Sessi= on Initiation Protocol
   (SIP) header fields (P-headers) used= by the 3rd-Generation
   Partnership Project (3GPP), along wi= th their applicability, which is
   limited to particular envi= ronments.  The P-header fields are for a
   variety of pu= rposes within the networks that the partners use,
   including= charging and information about the networks a call
   travers= es.




Please note that it may take a couple of minutes fro= m the time of submission until the htmlized version and diff are available = at tools.ietf.org.<= br>
The IETF Secretariat

  -=

 

 = ;

= --_000_058CE00BD4D6B94FAD033A2439EA1E4B01DF8E83EB24HE113667eme_-- From oej@edvina.net Thu Jan 2 02:16:13 2014 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 82BA91AD669 for ; Thu, 2 Jan 2014 02:16:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 HAD2LjOw-Yl3 for ; Thu, 2 Jan 2014 02:16:11 -0800 (PST) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 30CB01AC4A3 for ; Thu, 2 Jan 2014 02:16:09 -0800 (PST) Received: from [192.168.40.22] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 5AEB493C2A1; Thu, 2 Jan 2014 10:16:01 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: "Olle E. Johansson" Date: Thu, 2 Jan 2014 11:16:00 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0BA14051-5C7F-4416-8CD2-413347D540D3@edvina.net> References: <20140102101042.27427.64547.idtracker@ietfa.amsl.com> To: "dispatch@ietf.org list" X-Mailer: Apple Mail (2.1822) Subject: [dispatch] Fwd: New Version Notification for draft-johansson-dispatch-dane-sip-00.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: Thu, 02 Jan 2014 10:16:13 -0000 Hi! I have renamed my draft and resubmitted it again. Adding DNSsec/DANE = support to SIP is not a bad idea in my point of view.=20 If the view gets larger we might want to focus a bit more on security = aspects of SIP in the RAI area. There are many issues to look at. Why = isn't S/MIME deployed, how do we get more TLS - if that's what we want? = Can we improve upon MD5 digest authentication? Do we want to fix SIP = identity that many claim is broken? Is it possible to set up sessions = with end2end security? Happy New Year! /O Begin forwarded message: >=20 > A new version of I-D, draft-johansson-dispatch-dane-sip-00.txt > has been successfully submitted by Olle E. Johansson and posted to the > IETF repository. >=20 > Name: draft-johansson-dispatch-dane-sip > Revision: 00 > Title: TLS sessions in SIP using DNS-based = Authentication of Named Entities (DANE) TLSA records > Document date: 2014-01-02 > Group: Individual Submission > Pages: 9 > URL: = http://www.ietf.org/internet-drafts/draft-johansson-dispatch-dane-sip-00.t= xt > Status: = https://datatracker.ietf.org/doc/draft-johansson-dispatch-dane-sip/ > Htmlized: = http://tools.ietf.org/html/draft-johansson-dispatch-dane-sip-00 >=20 >=20 > Abstract: > Use of TLS in the SIP protocol is defined in multiple documents, > starting with RFC 3261. The actual verification that happens when > setting up a SIP TLS connection to a SIP server based on a SIP URI = is > described in detail in RFC 5922 - SIP Domain Certificates. >=20 > In this document, an alternative method is defined, using DNS-Based > Authentication of Named Entities (DANE). By looking up TLSA DNS > records and using DNSsec protection of the required queries, > including lookups for NAPTR and SRV records, a SIP Client can verify > the identity of the TLS SIP server in a different way, matching on > the SRV host name in the X.509 PKIX certificate instead of the SIP > domain. This provides more scalability in hosting solutions and = make > it easier to use standard CA certificates (if needed at all). >=20 > This document updates RFC 5922. >=20 >=20 From rifaat.ietf@gmail.com Thu Jan 2 10:34:51 2014 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 13E141AD0EA for ; Thu, 2 Jan 2014 10:34: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 i__9hSKWgBRF for ; Thu, 2 Jan 2014 10:34:48 -0800 (PST) Received: from mail-ee0-x22e.google.com (mail-ee0-x22e.google.com [IPv6:2a00:1450:4013:c00::22e]) by ietfa.amsl.com (Postfix) with ESMTP id D022A1ACC8B for ; Thu, 2 Jan 2014 10:34:47 -0800 (PST) Received: by mail-ee0-f46.google.com with SMTP id d49so6362929eek.19 for ; Thu, 02 Jan 2014 10:34:40 -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=+dfHLXryvp3ybgLhGAtiAf+L8XyojOitQQmqn0mkvts=; b=BgzIVCu7c91cVsWliMammDGRHqUCmG8Y7SW6Jt8cnZTvTU2TbRnolCCLJGRVtsumvJ 3VCsCkBiDbnAs11zdzNrtUQgZWly2+xSXi7cMBNUDYhgybLQnzfFuFzzqgC3no4IgYmg 2yICvxqXis1bPrQJ2KD8IZTpcnp3x+qjv2xCWFYSy0OfJB7MgrsjUhfzlhWZw1QDubTM NH83w4zckxYabADFVERrbhPEU1sAPX+hFQWnrSqc7v4xRitgLVLJ+ccbnhtyV1inExiM zJfW0X7DYw1hQN7nixK5Pb2za5h2JWl64MntnOaeobF/d0xhO4EXj2eJiZzbc2b9diKT KNgA== MIME-Version: 1.0 X-Received: by 10.15.34.197 with SMTP id e45mr17016195eev.61.1388687680366; Thu, 02 Jan 2014 10:34:40 -0800 (PST) Received: by 10.14.53.78 with HTTP; Thu, 2 Jan 2014 10:34:40 -0800 (PST) In-Reply-To: <0BA14051-5C7F-4416-8CD2-413347D540D3@edvina.net> References: <20140102101042.27427.64547.idtracker@ietfa.amsl.com> <0BA14051-5C7F-4416-8CD2-413347D540D3@edvina.net> Date: Thu, 2 Jan 2014 13:34:40 -0500 Message-ID: From: Rifaat Shekh-Yusef To: "Olle E. Johansson" Content-Type: multipart/alternative; boundary=089e016353cae46b0f04ef010bd9 Cc: "dispatch@ietf.org list" Subject: Re: [dispatch] Fwd: New Version Notification for draft-johansson-dispatch-dane-sip-00.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: Thu, 02 Jan 2014 18:34:51 -0000 --089e016353cae46b0f04ef010bd9 Content-Type: text/plain; charset=ISO-8859-1 Hi Olle, >Can we improve upon MD5 digest authentication? Take a look at the following HTTPAuth WG document: https://datatracker.ietf.org/doc/draft-ietf-httpauth-digest/ I have been working on this for some time, with SIP in mind. This started as an attempt to update RFC2617, and now it is a different document that will obsolete RFC2617. The document updates 3 aspects of RFC2617: 1. Algorithms agility: use of SHA2 2. Internationalization 3. Username hashing I am planning on writing a document to update the digest algorithms for SIP. Regards, Rifaat On Thu, Jan 2, 2014 at 5:16 AM, Olle E. Johansson wrote: > Hi! > I have renamed my draft and resubmitted it again. Adding DNSsec/DANE > support to SIP is not a bad idea in my point of view. > > If the view gets larger we might want to focus a bit more on security > aspects of SIP in the RAI area. There are many issues to look at. Why isn't > S/MIME deployed, how do we get more TLS - if that's what we want? Can we > improve upon MD5 digest authentication? Do we want to fix SIP identity that > many claim is broken? Is it possible to set up sessions with end2end > security? > > Happy New Year! > > /O > > > > Begin forwarded message: > > > > A new version of I-D, draft-johansson-dispatch-dane-sip-00.txt > > has been successfully submitted by Olle E. Johansson and posted to the > > IETF repository. > > > > Name: draft-johansson-dispatch-dane-sip > > Revision: 00 > > Title: TLS sessions in SIP using DNS-based Authentication > of Named Entities (DANE) TLSA records > > Document date: 2014-01-02 > > Group: Individual Submission > > Pages: 9 > > URL: > http://www.ietf.org/internet-drafts/draft-johansson-dispatch-dane-sip-00.txt > > Status: > https://datatracker.ietf.org/doc/draft-johansson-dispatch-dane-sip/ > > Htmlized: > http://tools.ietf.org/html/draft-johansson-dispatch-dane-sip-00 > > > > > > Abstract: > > Use of TLS in the SIP protocol is defined in multiple documents, > > starting with RFC 3261. The actual verification that happens when > > setting up a SIP TLS connection to a SIP server based on a SIP URI is > > described in detail in RFC 5922 - SIP Domain Certificates. > > > > In this document, an alternative method is defined, using DNS-Based > > Authentication of Named Entities (DANE). By looking up TLSA DNS > > records and using DNSsec protection of the required queries, > > including lookups for NAPTR and SRV records, a SIP Client can verify > > the identity of the TLS SIP server in a different way, matching on > > the SRV host name in the X.509 PKIX certificate instead of the SIP > > domain. This provides more scalability in hosting solutions and make > > it easier to use standard CA certificates (if needed at all). > > > > This document updates RFC 5922. > > > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --089e016353cae46b0f04ef010bd9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Olle,

=A0 =A0 =A0 =A0>Can we improve upon MD5 di= gest authentication?

Take a look at the follo= wing HTTPAuth WG document:

I have been working on this for some time,= with SIP in mind. This started as an attempt to update RFC2617, and now it= is a different document that will obsolete RFC2617.
The document= updates 3 aspects of RFC2617:
1. Algorithms agility: use of SHA2
2. Internationalization
3. Username hashing

I am planning on writ= ing a document to update the digest algorithms for SIP.

Regards,
=A0Rifaat



On Thu, Jan 2, 2014 at 5:16 = AM, Olle E. Johansson <oej@edvina.net> wrote:
Hi!
I have renamed my draft and resubmitted it again. Adding DNSsec/DANE suppor= t to SIP is not a bad idea in my point of view.

If the view gets larger we might want to focus a bit more on security aspec= ts of SIP in the RAI area. There are many issues to look at. Why isn't = S/MIME deployed, how do we get more TLS - if that's what we want? Can w= e improve upon MD5 digest authentication? Do we want to fix SIP identity th= at many claim is broken? Is it possible to set up sessions with end2end sec= urity?

Happy New Year!

/O



Begin forwarded message:
>
> A new version of I-D, draft-johansson-dispatch-dane-sip-00.txt
> has been successfully submitted by Olle E. Johansson and posted to the=
> IETF repository.
>
> Name: =A0 =A0 =A0 =A0 draft-johansson-dispatch-dane-sip
> Revision: =A0 =A0 00
> Title: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0TLS sessions in SIP using DNS-ba= sed Authentication of Named Entities (DANE) TLSA records
> Document date: =A0 =A0 =A0 =A02014-01-02
> Group: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Individual Submission
> Pages: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A09
> URL: =A0 =A0 =A0 =A0 =A0 =A0http://www= .ietf.org/internet-drafts/draft-johansson-dispatch-dane-sip-00.txt
> Status: =A0 =A0 =A0 =A0 https://datatracker.iet= f.org/doc/draft-johansson-dispatch-dane-sip/
> Htmlized: =A0 =A0 =A0 http://tools.ietf.org/html/dr= aft-johansson-dispatch-dane-sip-00
>
>
> Abstract:
> =A0 Use of TLS in the SIP protocol is defined in multiple documents, > =A0 starting with RFC 3261. =A0The actual verification that happens wh= en
> =A0 setting up a SIP TLS connection to a SIP server based on a SIP URI= is
> =A0 described in detail in RFC 5922 - SIP Domain Certificates.
>
> =A0 In this document, an alternative method is defined, using DNS-Base= d
> =A0 Authentication of Named Entities (DANE). =A0By looking up TLSA DNS=
> =A0 records and using DNSsec protection of the required queries,
> =A0 including lookups for NAPTR and SRV records, a SIP Client can veri= fy
> =A0 the identity of the TLS SIP server in a different way, matching on=
> =A0 the SRV host name in the X.509 PKIX certificate instead of the SIP=
> =A0 domain. =A0This provides more scalability in hosting solutions and= make
> =A0 it easier to use standard CA certificates (if needed at all).
>
> =A0 This document updates RFC 5922.
>
>

_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

--089e016353cae46b0f04ef010bd9-- From oej@edvina.net Thu Jan 2 11:01:34 2014 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 B7FE21AC829 for ; Thu, 2 Jan 2014 11:01:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HTML_MESSAGE=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 G6_2i8aB4ed2 for ; Thu, 2 Jan 2014 11:01:32 -0800 (PST) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 994DF1AC4C1 for ; Thu, 2 Jan 2014 11:01:30 -0800 (PST) Received: from [192.168.40.25] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 9700F93C2A1; Thu, 2 Jan 2014 19:01:21 +0000 (UTC) Content-Type: multipart/alternative; boundary="Apple-Mail=_EA4DF362-C129-444E-96B2-423FD9466D06" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: "Olle E. Johansson" In-Reply-To: Date: Thu, 2 Jan 2014 20:01:41 +0100 Message-Id: References: <20140102101042.27427.64547.idtracker@ietfa.amsl.com> <0BA14051-5C7F-4416-8CD2-413347D540D3@edvina.net> To: Rifaat Shekh-Yusef X-Mailer: Apple Mail (2.1510) Cc: "dispatch@ietf.org list" Subject: Re: [dispatch] Fwd: New Version Notification for draft-johansson-dispatch-dane-sip-00.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: Thu, 02 Jan 2014 19:01:34 -0000 --Apple-Mail=_EA4DF362-C129-444E-96B2-423FD9466D06 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 2 jan 2014 kl. 19:34 skrev Rifaat Shekh-Yusef : > Hi Olle, >=20 > >Can we improve upon MD5 digest authentication? >=20 > Take a look at the following HTTPAuth WG document: > https://datatracker.ietf.org/doc/draft-ietf-httpauth-digest/ >=20 > I have been working on this for some time, with SIP in mind. This = started as an attempt to update RFC2617, and now it is a different = document that will obsolete RFC2617. > The document updates 3 aspects of RFC2617: > 1. Algorithms agility: use of SHA2 > 2. Internationalization > 3. Username hashing >=20 > I am planning on writing a document to update the digest algorithms = for SIP. That's great. I will take a look at this. Thank you! Since this work is on the way - maybe we have enough to start a SIP = security wg? /O >=20 > Regards, > Rifaat >=20 >=20 >=20 > On Thu, Jan 2, 2014 at 5:16 AM, Olle E. Johansson = wrote: > Hi! > I have renamed my draft and resubmitted it again. Adding DNSsec/DANE = support to SIP is not a bad idea in my point of view. >=20 > If the view gets larger we might want to focus a bit more on security = aspects of SIP in the RAI area. There are many issues to look at. Why = isn't S/MIME deployed, how do we get more TLS - if that's what we want? = Can we improve upon MD5 digest authentication? Do we want to fix SIP = identity that many claim is broken? Is it possible to set up sessions = with end2end security? >=20 > Happy New Year! >=20 > /O >=20 >=20 >=20 > Begin forwarded message: > > > > A new version of I-D, draft-johansson-dispatch-dane-sip-00.txt > > has been successfully submitted by Olle E. Johansson and posted to = the > > IETF repository. > > > > Name: draft-johansson-dispatch-dane-sip > > Revision: 00 > > Title: TLS sessions in SIP using DNS-based = Authentication of Named Entities (DANE) TLSA records > > Document date: 2014-01-02 > > Group: Individual Submission > > Pages: 9 > > URL: = http://www.ietf.org/internet-drafts/draft-johansson-dispatch-dane-sip-00.t= xt > > Status: = https://datatracker.ietf.org/doc/draft-johansson-dispatch-dane-sip/ > > Htmlized: = http://tools.ietf.org/html/draft-johansson-dispatch-dane-sip-00 > > > > > > Abstract: > > Use of TLS in the SIP protocol is defined in multiple documents, > > starting with RFC 3261. The actual verification that happens when > > setting up a SIP TLS connection to a SIP server based on a SIP URI = is > > described in detail in RFC 5922 - SIP Domain Certificates. > > > > In this document, an alternative method is defined, using = DNS-Based > > Authentication of Named Entities (DANE). By looking up TLSA DNS > > records and using DNSsec protection of the required queries, > > including lookups for NAPTR and SRV records, a SIP Client can = verify > > the identity of the TLS SIP server in a different way, matching on > > the SRV host name in the X.509 PKIX certificate instead of the SIP > > domain. This provides more scalability in hosting solutions and = make > > it easier to use standard CA certificates (if needed at all). > > > > This document updates RFC 5922. > > > > >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch >=20 --- * Olle E Johansson - oej@edvina.net * Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden --Apple-Mail=_EA4DF362-C129-444E-96B2-423FD9466D06 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1
2 jan 2014 kl. 19:34 skrev Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>:

Hi Olle,

       >Can we improve upon MD5 digest authentication?

Take a look at the following HTTPAuth WG document:

I have been working on this for some time, with SIP in mind. This started as an attempt to update RFC2617, and now it is a different document that will obsolete RFC2617.
The document updates 3 aspects of RFC2617:
1. Algorithms agility: use of SHA2
2. Internationalization
3. Username hashing

I am planning on writing a document to update the digest algorithms for SIP.
That's great. I will take a look at this.  Thank you!

Since this work is on the way - maybe we have enough to start a SIP security wg?

/O

Regards,
 Rifaat



On Thu, Jan 2, 2014 at 5:16 AM, Olle E. Johansson <oej@edvina.net> wrote:
Hi!
I have renamed my draft and resubmitted it again. Adding DNSsec/DANE support to SIP is not a bad idea in my point of view.

If the view gets larger we might want to focus a bit more on security aspects of SIP in the RAI area. There are many issues to look at. Why isn't S/MIME deployed, how do we get more TLS - if that's what we want? Can we improve upon MD5 digest authentication? Do we want to fix SIP identity that many claim is broken? Is it possible to set up sessions with end2end security?

Happy New Year!

/O



Begin forwarded message:
>
> A new version of I-D, draft-johansson-dispatch-dane-sip-00.txt
> has been successfully submitted by Olle E. Johansson and posted to the
> IETF repository.
>
> Name:         draft-johansson-dispatch-dane-sip
> Revision:     00
> Title:                TLS sessions in SIP using DNS-based Authentication of Named Entities (DANE) TLSA records
> Document date:        2014-01-02
> Group:                Individual Submission
> Pages:                9
> URL:            http://www.ietf.org/internet-drafts/draft-johansson-dispatch-dane-sip-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-johansson-dispatch-dane-sip/
> Htmlized:       http://tools.ietf.org/html/draft-johansson-dispatch-dane-sip-00
>
>
> Abstract:
>   Use of TLS in the SIP protocol is defined in multiple documents,
>   starting with RFC 3261.  The actual verification that happens when
>   setting up a SIP TLS connection to a SIP server based on a SIP URI is
>   described in detail in RFC 5922 - SIP Domain Certificates.
>
>   In this document, an alternative method is defined, using DNS-Based
>   Authentication of Named Entities (DANE).  By looking up TLSA DNS
>   records and using DNSsec protection of the required queries,
>   including lookups for NAPTR and SRV records, a SIP Client can verify
>   the identity of the TLS SIP server in a different way, matching on
>   the SRV host name in the X.509 PKIX certificate instead of the SIP
>   domain.  This provides more scalability in hosting solutions and make
>   it easier to use standard CA certificates (if needed at all).
>
>   This document updates RFC 5922.
>
>

_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch


---
* Olle E Johansson - oej@edvina.net
* Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden



--Apple-Mail=_EA4DF362-C129-444E-96B2-423FD9466D06-- From pkyzivat@alum.mit.edu Sat Jan 4 08:23:55 2014 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 4BC171AE02F for ; Sat, 4 Jan 2014 08:23:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.165 X-Spam-Level: X-Spam-Status: No, score=0.165 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] 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 VqVhzrwnnP6B for ; Sat, 4 Jan 2014 08:23:53 -0800 (PST) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:228]) by ietfa.amsl.com (Postfix) with ESMTP id 49EC01AE037 for ; Sat, 4 Jan 2014 08:23:53 -0800 (PST) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta15.westchester.pa.mail.comcast.net with comcast id 9s381n0041YDfWL5FsPlba; Sat, 04 Jan 2014 16:23:45 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta20.westchester.pa.mail.comcast.net with comcast id 9sPl1n00A3ZTu2S3gsPlRV; Sat, 04 Jan 2014 16:23:45 +0000 Message-ID: <52C83591.3080702@alum.mit.edu> Date: Sat, 04 Jan 2014 11:23:45 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: dispatch@ietf.org References: <20140102101042.27427.64547.idtracker@ietfa.amsl.com> <0BA14051-5C7F-4416-8CD2-413347D540D3@edvina.net> In-Reply-To: <0BA14051-5C7F-4416-8CD2-413347D540D3@edvina.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1388852625; bh=ShnbZHHHC38DSvV/1CQfv8RPOBjUKGMVc5jXAbyMqXs=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=bTZOazilVPUChT3KTbeNvLSR+kXCQOHt3dhMNKzY0GtWRR9C/gHjrWb4Ut8OkMujr d42cV9rYkMpR8JbRwXLXb6H2OUwQNPxoyXotLn5b0CFkzi1mo5wmxWuwqsOUt1hxLB 5C0bgmArRaDYskPSJlQbguuXoX+vSpAYFKhJf+XAa3sSGDsxiyYvPG9cguu135FMFl F3uChhQAcDFq7OFMDM7OyWQ72dyLlmxh68EWqOh2NgrIoD7vG0E3d041vddfQQ/Q/a RFLRxE7ni7NIfUdpyXQW0CGpTqujyWY+jdUqlJCrLwoR1ff0TiAaxTEJX6fQoTnxNK 7jUZE1LKeh9vA== Subject: Re: [dispatch] Fwd: New Version Notification for draft-johansson-dispatch-dane-sip-00.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: Sat, 04 Jan 2014 16:23:55 -0000 On 1/2/14 5:16 AM, Olle E. Johansson wrote: > Hi! > I have renamed my draft and resubmitted it again. Adding DNSsec/DANE support to SIP is not a bad idea in my point of view. It seems like a really good idea to me. I have a question about backward compatibility, as discussed in section 9: You say that that servers can use certificates that support both DANE and 5922 style validation. And IIUC that will be necessary in order to handle clients that don't support DANE validation. But the Intro explains that one of the important reasons for introducing DANE authentication is because of various logistic problems providing certificates for 5922 style validation. Providing backward compatibility negates that advantage. Have you considered the migration path? Presumably those currently using 5922 already have a certificate that works for that. Will they be able to get a cert that continues that and also supports DANE validation? What about those coming to this without any history of 5922 support? ISTM that there is need to get ubiquitous client support for this deployed. For that we have the usual chicken/egg scenario. Thanks, Paul > If the view gets larger we might want to focus a bit more on security aspects of SIP in the RAI area. There are many issues to look at. Why isn't S/MIME deployed, how do we get more TLS - if that's what we want? Can we improve upon MD5 digest authentication? Do we want to fix SIP identity that many claim is broken? Is it possible to set up sessions with end2end security? > > Happy New Year! > > /O > > > > Begin forwarded message: >> >> A new version of I-D, draft-johansson-dispatch-dane-sip-00.txt >> has been successfully submitted by Olle E. Johansson and posted to the >> IETF repository. >> >> Name: draft-johansson-dispatch-dane-sip >> Revision: 00 >> Title: TLS sessions in SIP using DNS-based Authentication of Named Entities (DANE) TLSA records >> Document date: 2014-01-02 >> Group: Individual Submission >> Pages: 9 >> URL: http://www.ietf.org/internet-drafts/draft-johansson-dispatch-dane-sip-00.txt >> Status: https://datatracker.ietf.org/doc/draft-johansson-dispatch-dane-sip/ >> Htmlized: http://tools.ietf.org/html/draft-johansson-dispatch-dane-sip-00 >> >> >> Abstract: >> Use of TLS in the SIP protocol is defined in multiple documents, >> starting with RFC 3261. The actual verification that happens when >> setting up a SIP TLS connection to a SIP server based on a SIP URI is >> described in detail in RFC 5922 - SIP Domain Certificates. >> >> In this document, an alternative method is defined, using DNS-Based >> Authentication of Named Entities (DANE). By looking up TLSA DNS >> records and using DNSsec protection of the required queries, >> including lookups for NAPTR and SRV records, a SIP Client can verify >> the identity of the TLS SIP server in a different way, matching on >> the SRV host name in the X.509 PKIX certificate instead of the SIP >> domain. This provides more scalability in hosting solutions and make >> it easier to use standard CA certificates (if needed at all). >> >> This document updates RFC 5922. >> >> > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From atle.monrad@ericsson.com Mon Jan 6 00:19:58 2014 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 272F31AE006 for ; Mon, 6 Jan 2014 00:19:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.938 X-Spam-Level: X-Spam-Status: No, score=-0.938 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, 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 zUqkExCFAsWP for ; Mon, 6 Jan 2014 00:19:49 -0800 (PST) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id E8B4D1ADFB7 for ; Mon, 6 Jan 2014 00:19:47 -0800 (PST) X-AuditID: c1b4fb32-b7f2b8e0000073bf-9e-52ca671a8b88 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.125]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 99.8D.29631.A176AC25; Mon, 6 Jan 2014 09:19:38 +0100 (CET) Received: from ESESSMB203.ericsson.se ([169.254.3.164]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.02.0347.000; Mon, 6 Jan 2014 09:19:06 +0100 From: Atle Monrad To: "R.Jesske@telekom.de" , "mary.ietf.barnes@gmail.com" Thread-Topic: PROTO Review: draft-drage-sipping-rfc3455bis-09.txt Thread-Index: AQHO1MOipbq5M1PHo0yGWyw1ec4wQZovvsCAgAbapICAC/uTAIAmGDcAgAjS8ICABkSfAA== Date: Mon, 6 Jan 2014 08:19:05 +0000 Message-ID: <7D2F7D7ADBA812449F25F4A69922881C266524@ESESSMB203.ericsson.se> References: <058CE00BD4D6B94FAD033A2439EA1E4B01DEBB69CC8A@HE113667.emea1.cds.t-internal.com> <058CE00BD4D6B94FAD033A2439EA1E4B01DF27DB8A63@HE113667.emea1.cds.t-internal.com> <058CE00BD4D6B94FAD033A2439EA1E4B01DF8E83EB24@HE113667.emea1.cds.t-internal.com> In-Reply-To: <058CE00BD4D6B94FAD033A2439EA1E4B01DF8E83EB24@HE113667.emea1.cds.t-internal.com> Accept-Language: nb-NO, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: multipart/alternative; boundary="_000_7D2F7D7ADBA812449F25F4A69922881C266524ESESSMB203ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuphkeLIzCtJLcpLzFFi42KZGfG3Vlcq/VSQwffblha7rmhZLJ20gNXi 8/79zBZNd7rYHFg8ds66y+6xZMlPJo+LS74xerS9VAhgieKySUnNySxLLdK3S+DK2N//n7Fg 0Te2iuULnzI1MN7rZ+ti5OSQEDCReNQ3hxXCFpO4cG89UJyLQ0jgBKPE1XW7WCGcxYwSM2Yd YAepYhPQkTj38w5Yh4hAjkTzijksIEXMAnMYJU79WQNWJCzgIDH1wDmoIkeJlpv/GSHsMImL PU1MIDaLgIrEw1/bmEFsXgFviTmHd0Otvs4s0f7+B1gDp0CsxKf+90AbODgYBWQl5jbxgoSZ BcQlbj2ZzwRxtoDEkj3nmSFsUYmXj/9BvaMksfbwdhaI+nyJpat2sEPsEpQ4OfMJywRG0VlI Rs1CUjYLSRlEXE/ixtQpbBC2tsSyha+ZIWxdiRn/DrEgiy9gZF/FKFmcWlycm25koJebnlui l1qUmVxcnJ+nV5y6iREYowe3/DbawXhyj/0hRmkOFiVx3uusNUFCAumJJanZqakFqUXxRaU5 qcWHGJk4OKUaGDev1/VS+KF9yTj+g/brgNkn/i/t98+7MW/zrlOBPOVTa49K8MyRMebXWyL5 XChcNNW5TC6vVu/GC8Mp39brFFzYrvA3is30YWNH+6bZ2wMuPowJNOz6rjlrxyK/NSzTslgM FlqpOx/ws3KQnhXvI8rHxXz0xdrnbl1/L90S3XCj/lWdUvmCpUosxRmJhlrMRcWJAPkr5bWf AgAA 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: Mon, 06 Jan 2014 08:19:58 -0000 --_000_7D2F7D7ADBA812449F25F4A69922881C266524ESESSMB203ericsso_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Mary I hope that you are OK with Rolands clarifications for a new version of the= draft. Hopefully this version can then be progressed. It contains all 3GPP-additio= ns since RFC 3455 upto & including 3GPP-Rel-11 Thanks /atle ________________________________ Atle Monrad 3GPP CT Chairman Group Function Technology - Standardization and Technical Regulation Ericsson From: R.Jesske@telekom.de [mailto:R.Jesske@telekom.de] Sent: 2. januar 2014 10:30 To: mary.ietf.barnes@gmail.com Cc: dispatch@ietf.org; Gonzalo Camarillo; Atle Monrad; dean.willis@softarmo= r.com Subject: AW: PROTO Review: draft-drage-sipping-rfc3455bis-09.txt Hi Mary, I wish you a happy new year 2014. And the best for the next year. I was looking again on my changes I made due to your proposal in December. I realized that if I change the SHOULD to MUST we have now a backward compa= tibility problem. We are using the P-Associated-URI also over the IMS user interface which is= not encrypted. So I propose to add some more words. ... Section 6.1 ... An eavesdropper could possibly collect the list of identities a= user is registered. This can have privacy implications. To mitigate this problem, this e= xtension SHOULD only be used in a secured environment, where encryption of SIP messa= ges is provided either end-to-end or hop-by-hop. Since the P-Associated-URI header field value allows to implicitl= y register a bundle of URIs with one REGISTER Message the impact of security usi= ng the P-Associated-URI header field is not higher than using single REGISTER messages when registering all identities explic= it. For the P-Called-Party-Id the change should be also done like as follows: An eavesdropper could possibly collect the list of identities a = user is registered. This can have privacy implications. To mitigate this problem, this = extension SHOULD only be used in a secured environment, where encryption of SIP messa= ges is provided either end-to-end or hop-by-hop. Normally within a 3GPP environment the P-Called-Party-ID is not = sent towards end users but may be exchanged between carriers where other se= curity mechanisms than SIP encryption are used. Sorry coming so late. If this is OK for you I will include it to a new version. Thank you and Best Regards Roland Von: Mary Barnes [mailto:mary.ietf.barnes@gmail.com] Gesendet: Freitag, 27. Dezember 2013 19:45 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 making these changes. I finally had a chance to review this upda= ted 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 "potentia= lly 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 th= e next paragraph that provides details of the impacts. I think you could p= robably 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" tha= t makes this header not of particular concern with regards to security. Doe= s it reveal additional, unique information about an individual that isn't a= vailable 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 reg= istered. This can have privacy implications. To mitigate this problem, th= is extension MUST only be used in a secured environment, where encryption o= f 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 revis= ion. And, I believe you still need to identify privacy/security implicatio= ns 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 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_7D2F7D7ADBA812449F25F4A69922881C266524ESESSMB203ericsso_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Mary

 <= /p>

I hope that you are OK wi= th Rolands clarifications for a new version of the draft.=

 <= /p>

Hopefully this version ca= n then be progressed. It contains all 3GPP-additions since RFC 3455 upto &a= mp; including 3GPP-Rel-11

 <= /p>

Thanks<= /p>

/atle

 <= /p>

________________________________


Atle Monrad
3GPP CT Chairman

Group Function Technology – Standardization and Technical Regulation<= /span>
Ericsson

 

 <= /p>

From: R.Jesske= @telekom.de [mailto:R.Jesske@telekom.de]
Sent: 2. januar 2014 10:30
To: mary.ietf.barnes@gmail.com
Cc: dispatch@ietf.org; Gonzalo Camarillo; Atle Monrad; dean.willis@s= oftarmor.com
Subject: AW: PROTO Review: draft-drage-sipping-rfc3455bis-09.txt

 

Hi Mary,

I wish you a happy new ye= ar 2014. And the best for the next year.

 <= /p>

I was looking again on my= changes I made due to your proposal in December.

I realized that if I chan= ge the SHOULD to MUST we have now a backward compatibility problem.

We are using the P-Associ= ated-URI also over the IMS user interface which is not encrypted.

So I propose to add some = more words.

…=

Section 6.1

…=

     &n= bsp;   <= t<= /span>><= /span>An eavesdropper could possibly collect the list of identities a user is regis= tered. 

     &n= bsp; This can have privacy implications. To mitigate this problem, thi= s extension SHOULD

     &n= bsp; only be used in a secured environment, where encryption of SIP me= ssages is

     &n= bsp; provided either end-to-end or hop-by-hop.  <= /t= >=

  

     &n= bsp;= <t&= gt; Since the P-Associated-URI header field value allows to implicitly registe= r

     &n= bsp;a bundle of URIs with one REGISTER Message the impact of security using= the P-Associated-URI header field is not higher than 

      using single REGISTER mess= ages when registering all identities explicit.</t>

 <= /p>

 <= /p>

For the P-Called-Party-Id= the change should be also done like as follows:

 <= /p>

     &n= bsp;  <= t<= /span>><= /span>An eavesdropper could possibly collect the list of identities a user is regis= tered. 

     &n= bsp; This can have privacy implications.  To mitigate this proble= m, this extension SHOULD

     &n= bsp; only be used in a secured environment, where encryption of SIP me= ssages is

       provided either end-= to-end or hop-by-hop.  </t>=

 

     &n= bsp;  <= t<= /span>><= /span>Norm= ally within a 3GPP environment the P-Called-Party-ID is not sent towards end us= ers but may be exchanged between carriers where other security mechanisms t= han SIP encryption are used.  <= /t= >=

 <= /p>

Sorry coming so late.

If this is OK for you I w= ill include it to a new version.

 <= /p>

Thank you and Best Regard= s

 <= /p>

Roland<= /p>

 <= /p>

Von: Mary Barnes [m= ailto:mary.ietf.barnes@gmail.com]
Gesendet: Freitag, 27. Dezember 2013 19:45
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 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 extra= cted these few points from previous review comment threads.

 

Thanks,

Mary.

 

----Previous point  ---------= ------------------------>

- Section 6.1: this needs some tighter wording.  What is meant by &q=
uot;potentially annoying"  for example?  
=
 [RJ] I do not know. This is original text. So I deleted the wo=
rds.

=
-


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


"This attack sho=
uld not have any significant impacts."


I don't think that adds any value and just begs the qu=
estion "what are the insignificant impacts and are there any privacy c=
oncerns"?  Really, it's the next paragraph that provides details =
of the impacts.  I think you could probably remove that sentence altog=
ether and not lose anything. 


=
[/MB]

--=
--Previous point --------------------------------->


-  Section 6.2: I thin=
k 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 someth=
ing like:


OLD:


An eavesdropper may collect th=
e list of identities a user is registered.  This may have privacy impl=
ications.  To mitigate this problem, this extension SHOULD only be use=
d in a secured environment, where encryption of SIP messages is provided ei=
ther end-to-end or


hop-by-hop. 


NEW: 


 


An eavesdropper cou=
ld possibly collect the list of identities a user is registered.  This=
 can have privacy implications.  To mitigate this problem, this extens=
ion MUST only be used in a secured environment, where encryption of SIP mes=
sages 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 in=
formation about an individual that isn't available in other headers. &=
nbsp; [/MB]


 


 


 


 

 

 

On Tue, Dec 3, 2013 at 7:00 AM, &l= t;R.Jesske@telekom= .de> wrote:

Hi Mary,

Thank you for your comments and proposa= ls.

I have now included all comments and up= loaded 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 (S= IP) for the 3rd-Generation Partnership Project (3GPP)

Creation date:    2013-12-03=

Group:           = Individual Submission

Number of pages: 46

URL:           &n= bsp; ht= tp://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-s= ipping-rfc3455bis-10

Diff:            = http://www.i= etf.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<= span lang=3D"DE">

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

   limited to particular environments.  The P-header fiel= ds are for a

   variety of purposes within the networks that the partners u= se,

   including charging and information about the networks a cal= l

   traverses.

 

 

 

Von: Mary Barnes [mailto:ma= ry.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 comme= nts below [MB].

 

Thanks,

Mary.

 

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

Hi Mary,<= /o:p>

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:ma= ry.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<= span lang=3D"DE">

 

In preparation for the PROTO write-up, I have re= viewed the document in detail.  My detailed review was originally base= d on the -08, but I also reviewed 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 below.  = ;A number of these comments are with regards to text that was not changed f= rom RFC 3455, but I think some of the text requires updating and we need to keep in mind that this an entirely new IE= SG that will be reviewing this document, so they won't have the same contex= t of the IESG that approved RFC 3455.  I will note that I also have no= t validated the content of section 9 against a diff of this document and RFC 3455.  I will need to do that= before I progress the document unless the authors can point me to another = review that has done that.

 

Regards,

Mary.

 

Summary:  This document needs some work pri= or to being progressed. 

 

Comments:

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

- Section 1.  I think you should be explici= t that these extensions apply only to a private network - saying they are &= quot;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 transit=
ive trust.  These assumptions
   are generally NOT APPLICABLE in the Int=
ernet as a whole. 
=
 

NEW: 

=
 
   The SIP extensions specified in this do=
cument make certain
   assumptions regarding network topology,=
 linkage between SIP and lower
   layers, and the availability of transit=
ive trust.  These assumptions
   apply only to private networks and are =
not appropriate for use in an Internet environment.<=
/pre>

=
 


 


- Section 3.  This section needs to be updated.  I don=
't think that 10 year old background is relevant in the current context. &n=
bsp; You should be able to model this after the text in more recent 3GPP P-=
header documents, referring 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 es= tablish and tear down multimedia sessions in the

     context of its IP Multi= media Subsystem (IMS). For more information on

     the IMS, a detailed des= cription can be found in 3GPP TS 23.228 . This document is an update of RFC= 3455   which covers the requirements in RFC4083 and describes upd= ates and adds private extensions to address those requirements which are needed in = for 3GPP Release 11. Each extension, or set of related extensions is descri= bed 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 Part= nership Project (3GPP) uses SIP as

     the protocol &= nbsp;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 SI= P private header extensions (referred to as P-headers) which are 

     required by the 3GP= P specification. Note that the requirements for these extensions

     are documented in R= FC 4083.   This document is an update to RFC3455. 

     This document updat= es existing P-header des= criptions 

     to addr= ess 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" -> &q=
uot;registered SIP address-of-record"
- Section 4.1, 3rd paragraph. &nb=
sp;"Note that, generally speaking," -> "Note that in stan=
dard SIP usage [RFC3261]"

- Section 4.1.2.3.  I don't =
think this is stated properly.  I think the intent is that this header=
 is not applicable to proxies, therefore the proxy MUST relay the header fi=
eld unchanged.  I would suggest rewording something like:


OLD: 


   This mem=
o does not define any procedure at the proxy.  The proxy does


   not add, read, modify or delete the hea=
der field, and therefore any


   proxy will relay this header field unch=
anged.


 


NEW:


 


   This header is not intended to be used =
by proxies - a proxy does


   not add, read, modify or delete the hea=
der field, and therefore any


   proxy MUST relay this header field unch=
anged.


=
 


 


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 the MAY be changed to "can". &n=
bsp; 


=
   The UAS MAY use the information to render different distinctiv=
e audiovisual alerting


   tones, depending on the URI used to rec=
eive the invitation to the


   session.


Section 4.2.2.2, 2n=
d paragraph.  The behavior in this sentence is not normative from a SI=
P protocol perspective, thus  I suggest the MAY be changed to "ca=
n". 


 


- Section 4.3.3, last paragraph. =
 I think this ought to be a MUST: "The identifier should be globa=
lly unique.." 


 


- Section 4.3.2.1.  This tex=
t has changed from the -08.   I don't know what a "normal User Eq=
uipment" is and the term "User Equipment" is not defined 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-Vis=
ited-


   Network-ID when sending the REGISTER.&n=
bsp; Therefore user agent clients


   do not insert a P-Visited-Network-ID he=
ader field in any SIP message.


 


NEW: 


   In the c=
ontext of the network to which the header fields defined in this document a=
pply, a User Agent has no knowledge of the P-Visited-Network-ID when s=
ending the REGISTER request.  Therefore user agent clients MUST NOT in=
sert a P-Visited-Network-ID header field in any SIP message.=



 


- Section 4.3.2.2:, 2nd paragraph: &nb=
sp;"home network MAY use" -> "home network can use"<=
/span>


 


 


- Section 4.=
3.2.2, last paragraph:  

=
 


 


OLD: Note that a received P-Visited-Net=
work-ID from a UA is a failure case and must be deleted.<=
/pre>

=
 


NEW:  Note that a received P-Visit=
ed-Network-ID from a UA is a failure case and MUST be deleted when the requ=
est is forwarded. 


=
 


Section 4.4.2.1, 2nd paragraph:  "MUST t=
rust the proxy" -> "MUST have a trust relationship with the pr=
oxy" 


=
 


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, 2n=
d paragraph: "MAY act upon any information present" -> "c=
an act upon any information present",  "MAY use the call id&=
quot; -> "can use the call id" <=
span lang=3D"DE">


Section 4.5.2: 2nd paragraph: &qu=
ot;MAY use the hostnames" -> "can use the hostnames" =
;


 


 


Section 4.5.2.1 2nd paragraph: "MAY use the contents" =
-> "can use the contents" <=
o:p>


 
- Section 4.6.2, 3rd paragraph: "MAY use the values" -=
> "can use the values" 
- Section 4.6.3, 3rd paragraph: n=
eeds some editorial work.  Maybe the following change would work: =
;
 
OLD:
=
   Depending on the call scenario it is needed to add for each tr=
ansit
   network either a transit network name o=
r a void value.  Nevertheless
   it can not be guaranteed that all value=
s will appear within the P-Charging-Vector header field. 
 
NEW: 
 
=
   Depending on the call scenario, each transit network can add e=
ither a transit network name or a void    value.  =
However, it can not be guaranteed that all the values that are added will a=
ppear within the P-Charging-Vector header field.
 
- Section 4.6.3, ne=
xt 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 i=
nto consideration" mean. Are you talking about limits on the number of=
 entries or are you suggesting that the number of void values must be consi=
dered when setting the index for the transit network names?  
 =

[RJ] Yes! Changed the text to:
 <=
/span>
A void value has no index. By adding =
the next value the index has to be incremented by the number of void entrie=
s +1.
 <=
/span>
- Section 4.6=
.4.2: I don't know what this means: <=
span style=3D"font-family:"Arial","sans-serif""> &=
quot;A deletion of the elements could appear depending on the network polic=
y and trust rules".  Is it just trying to say that a=
long with the adding and modifying in the previous sentence that the elemen=
ts can also be deleted by the proxy? 
 =

[RJ] Yes, I have changed the text:

Procedures described within 4.6.2.2 apply. A tra= nsit-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

       &=
nbsp;   also valid by replacing the transit-ioi with a void value=
.
 
 <=
/span>
 
 
- Section 5.7. Delete this text and table.   We aren't thes=
e tables anymore as they really don't provide any useful information.  =
;You just need to verbally 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 REG= ISTER method and 2xx resonses, P-Called-Party-ID can appear in SIP INVITE, = OPTIONS, PUBLISH,SUBSCRIBE, MESSAGE methods and all responses, P-Visited-Ne= twork-ID can appear in all SIP methods except ACK, BYE and CANCEL and all responses, P-Access-Network-Info can ap= pear 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 than use comma separators, use a period.  Yo= u should also spell out that these are header fields - i.e., "The P-Associated-URI header field can appear....2xx r= esponses.   The P-Called-Party-ID header field.... 

 <=
/span>
 
- Section 6.1: this needs some ti=
ghter wording.  What is meant by "potentially annoying" &nbs=
p;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 &q=
uot;nature" that makes this header not of particular concern with rega=
rds to security. Does it reveal additional, unique information about an ind=
ividual that isn't available in other headers.  Also, the 2nd paragrap=
h needs some work - maybe something like:
 
OLD:
An eavesdropper may collect the list of identities a u=
ser is registered.  This may have privacy implications.  To mitig=
ate this problem, this extension SHOULD only be used in a secured environme=
nt, where encryption of SIP messages is provided either end-to-end or<=
/o:p>
 
 
hop-by-hop. 
   
NEW: 
 
 An=
 eavesdropper could possibly collect the list of identities a user is regis=
tered.  This can have privacy implications.  To mitigate this pro=
blem, this extension MUST only be used in a secured environment, where encr=
yption of SIP messages is provided either end-to-end or hop-by-hop. 

 

[MB]  So, I think the first sentence is try= ing to say: "An eavesdropper could possi= bly collect the list of identities a user has registered."=

or  "An eavesd= ropper could possibly collect the list of identities registered by a user.&= quot; 

[/MB]  

- Section 6.4, <=
/pre>

--3rd paragraph: "should not=
" -> "MUST NOT" =



 


-- 7th paragraph:  "SHO=
ULD NOT be sent" -> "MUST NOT be sent" 


 


 


 


-- 8th paragraph: "SHOULD NOT send sensitive information&qu=
ot; -> "MUST NOT send sensitive information"


 


 


-- 9th paragraph: "is required to delete" -> "=
is REQUIRED to delete" 


 


-- 10th paragraph:  How does a network ensure the informati=
on 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 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.
 <=
/span>
-- 11th paragraph: So, what does a proxy do w=
ith that information.  What are the implications if the i=
nformation is used and it's not valid?  =

[RJ] Yes I did some changes as follows.
 <=
/span>

        <t= >A proxy receiving a message containing the P-Access-Network-Info=

       header fiel= d from a non-trusted entity is not able to guarantee the

       validi=
ty of the contents. Thus this content SHOULD be deleted based on local poli=
cy.</t>
 
- Section 9, item 2.  I thin=
k you need to add this text with regards to the recommendation to use RFC 4=
244 (bis) to the body of this document and include a real reference.=

 
[RJ] OK done. I let the reference RFC4244 s=
ince 3GPP uses currently only RFC4244. =

Replaced following text:
With section 9.2
       <t&=
gt;Requirements for a more general solution are proposed in <xref=

       &=
nbsp; target=3D"RFC4244"></xref>. 3GPP will continue to =
use the
       &=
nbsp; P-Called-Party-ID header field even though RFC 4244 <xref
       &=
nbsp; target=3D"RFC4244"></xref> has now been published.=
</t>
 <=
/span>
I think the text in Section 9.2 is better.<=
/span>
Nits:
=
 
 
- Section 4.1, 2nd paragraph.  "has asso=
ciated to an address-of-record" -> "has associated with an add=
ress-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 another ty=
po: "the REGISTRAR" -> "at the REGISTRAR"
 
Section 4.2.2.1, 3rd paragraph:  "there must also be a transiti=
ve trust" ->  "there MUST also be a transitive trust"=
; 
 
Section 4.6, 2nd paragraph: "includes, includes but is not limited t=
o" -> "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, <R.Jesske@telekom.de> w= rote:

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: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.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) Extensi= ons to the Session Initiation Protocol (SIP) for the 3rd-Generation Partner= ship Project (3GPP)
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://datatrac= ker.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 Pr= otocol
   (SIP) header fields (P-headers) used by the 3rd-Generation
   Partnership Project (3GPP), along with their applicability, wh= ich 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_7D2F7D7ADBA812449F25F4A69922881C266524ESESSMB203ericsso_-- From mary.ietf.barnes@gmail.com Mon Jan 6 09:57:56 2014 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 322FA1AE13D; Mon, 6 Jan 2014 09:57:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 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, 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 gT5Jp0jkElVC; Mon, 6 Jan 2014 09:57:53 -0800 (PST) Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id CC19E1AE128; Mon, 6 Jan 2014 09:57:52 -0800 (PST) Received: by mail-we0-f181.google.com with SMTP id x55so15641962wes.26 for ; Mon, 06 Jan 2014 09:57:43 -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 :content-type; bh=AhpZaFbd0BvDCM3Wvt+6KVK4fHNiUgzIqHLrvBaCGZM=; b=TQwHBm+Lr3sIQjVMuvMDvgTmphV+QcguQzr/bFfZEDPZBbDhQOY8n2btuJ52naTsuP Wc/WhwHeVw7xq5uocVYJV5Ag63h29Jf6opzH3IYSiuRoArdPUkwHXd0DpB7h7M1tlNes EhMf5wZ/kiJ5An+uR1JBhJyfaMe0GlrQ6HRxZn+xwIt3zR4OFkNjj/meHIj31NmZu0jA nrk63eYc6A2w2jakk/nNTCp/uSOT/Fay2kM+dBcI3C+8sgE3Y4rZgce8frJwrIB2ua1W QtnhGdgHVPPMjExcKGwEyENyqcXuv0bZUWpY8sWbsbNedp3RhAjfS90Wtw8AoV1xrr+D shWA== MIME-Version: 1.0 X-Received: by 10.180.210.131 with SMTP id mu3mr9951698wic.36.1389031063850; Mon, 06 Jan 2014 09:57:43 -0800 (PST) Received: by 10.216.172.9 with HTTP; Mon, 6 Jan 2014 09:57:43 -0800 (PST) In-Reply-To: <52cae834.c3e7340a.687e.4e41SMTPIN_ADDED_BROKEN@mx.google.com> References: <52cae834.c3e7340a.687e.4e41SMTPIN_ADDED_BROKEN@mx.google.com> Date: Mon, 6 Jan 2014 11:57:43 -0600 Message-ID: From: Mary Barnes To: "rai@ietf.org" , SIPCORE , DISPATCH Content-Type: multipart/alternative; boundary=001a11c38d7024942804ef50ffb0 Subject: [dispatch] Fwd: [SIPForum-techwg] SIPNOC 2014 Call for Presentations and Early-Bird Registration Deadlines Extended! 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: Mon, 06 Jan 2014 17:57:56 -0000 --001a11c38d7024942804ef50ffb0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I thought this might be of interest since SIPNOC is directly relevant to many folks subscribed to these mailing lists. Regards, Mary. ---------- Forwarded message ---------- From: Marc Robins Date: Mon, Jan 6, 2014 at 11:28 AM Subject: [SIPForum-techwg] SIPNOC 2014 Call for Presentations and Early-Bird Registration Deadlines Extended! To: techwg@sipforum.org SIPNOC 2014 Call for Presentations and Early-Bird Registration Deadlines Extended! *Proposals are being accepted for workshops, panels, speaker presentations and =E2=80=9CBirds of a Feather=E2=80=9D sessions addressing the deployment= of SIP in service provider environments at SIPNOC 2014, June 9 -12, 2014.* A three-day educational conference focusing on the challenges and opportunities related to the deployment of SIP-based carrier services globally, SIPNOC 2014 is a unique, network operator-centric event. Organizers invite companies, executives and industry insiders to propose presentations highlighting the use of session initiation protocol (SIP) in service provider environments. Operators are encouraged to present SIP-related success stories, deployment issues and concerns in their networks, while equipment vendors and other industry stakeholders are invited to work with operators to present real-world deployment experiences= . The SIPNOC conferences attract leading technical and operations personnel from the global carrier community and have earned high praise from attendees for their educational, non-commercial and technical content that focuses on the real-world challenges operators face when deploying SIP services in global IP networks. SIPNOC 2014 attendees will include telecommunications providers, major backbone operators, interconnect and wholesale solution providers, ISPs, cable operators, wireless network operators as well as large enterprises deploying major SIP initiatives. SIPNOC 2014 Call for Presentations proposals can be submitted by visiting the SIP Forum SIPNOC 2014 Call for Presentations site. Possible topics can include SIP peering, SIP trunking, Emergency Services, Congestion Control, Scaling and Capacity Issues, SIP-based applications, Routing, Security, SIP-Network Operations Center Best Practices, IPv6 deployment challenges, User-agent Configuration, Standardization Issues and Progress, HD voice deployments, Video Interoperability, WebRTC and SIP, FoIP/T.38 Deployment, Testing or other issues facing SIP network operations. SIPNOC 2014 offers several different types of speaking opportunities including: - General Session Talks: A General Session presentation should be on a topic of interest to the general SIPNOC audience, and may be up to 30 minutes long (including time for Q&A). - General Session Panels: Panels are sessions with a moderator and a team of panelists. The panel moderator should submit an abstract on the panel topic, a list of panelists, and how the panel will be organized. Panel selection is based on the importance, originality, focus and timeliness of the topic, expertise of proposed panelists, as well as the potential for informative and controversial discussion. - Special Workshops: The SIPNOC 2014 program has been expanded to include special workshops that run for 2-3 hours, providing time to focu= s in-depth on a variety of issues important to the SIPNOC community. Topic= s can include a review of SIP RFCs and standards development, the regulato= ry environment, etc. - Research Topics: Researchers are invited to present short summaries of their work for operator feedback. Topics may include call routing, netwo= rk performance, statistical measurement and analysis and protocol developme= nt and implementation. Studies presented may be works in progress. Research= ers from academia, government, and industry are encouraged to present. - BOFs: BOFs (Birds of a Feather sessions) are informal sessions on topics which are of interest to a portion of the SIPNOC community. BOFs = may be held in break=E2=80=90out areas or in an unscheduled room. Requests f= or scheduled BOFs can be made at any time, including on site at the confere= nce. The following is a complete list of key dates for the SIPNOC 2014 speaking program: - Presentation Abstracts Due =E2=80=93 January 31, 2014 - Draft Presentations Due -- February 15, 2014 - Acceptance Decision and Notifications -- February 21, 2014 - Draft Program Published =E2=80=93 March 1, 2014 - Final Presentations Due -- April 1, 2014 - Final Agenda Published -- April 15, 2014 - Conference Begins -- June 9, 2014 ------------------------------ *SIPNOC 2014 General Info* The SIPNOC 2014 event website is located at www.sipnoc.org. To view the official call for presentations, which includes instructions on submitting material and specific SIPNOC policies, please visit www.sipforum.org/content/view/374/275/. To submit, visit https://www.easychair.org/conferences/?conf=3Dsipnoc2014. Registration for SIPNOC 2014 is officially open! Special pricing for SIPNOC 2014 is now in effect! Take advantage of special early-bird pricing now through March 1, 2014. The regular SIPNOC 2014 conference registration fee is $995, but for a limited time regular attendees can save $145 and pay only $850 for three days of conference proceedings. This fee includes a special welcome reception the evening before the event with food and drink; breakfast, lunch and break refreshments and snacks; and special networking receptions the first and second night of the event. *Individuals from SIP Forum Full Member companies save even more ($295 off the regular price to be exact with special early-bird pricing)! Please contact Marc Robins, SIP Forum President and Managing Director, at marc.robins@sipforum.org to obtain the exclusive Full Member discount code.* Register today at www.regonline.com/sipnoc2014. ------------------------------ *SIPNOC 2014 Sponsorship Information* For information about corporate sponsorship opportunities at SIPNOC 2014, please contact Marc Robins, SIP Forum President and Managing Director, at 203-829-6307 or marc.robins@sipforum.org. ------------------------------ ************************* Marc Robins President and Managing Director SIP Forum http://www.sipforum.org Mobile: 203-829-6307 SkypeMe! marcrobins ************************* _______________________________________________ techwg mailing list Send mail to: techwg@sipforum.org Unsubscribe or edit options at: http://sipforum.org/mailman/listinfo/techw= g --001a11c38d7024942804ef50ffb0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I thought this might be of interest since SIPNOC is direct= ly relevant to many folks subscribed to these mailing lists.=C2=A0

=
Regards,
Mary.

-----= ----- Forwarded message ----------
From: Marc Robins <<= a href=3D"mailto:marc.robins@sipforum.org">marc.robins@sipforum.org>=
Date: Mon, Jan 6, 2014 at 11:28 AM
Subject: [SIPForum-techwg]= SIPNOC 2014 Call for Presentations and Early-Bird Registration Deadlines E= xtended!
To: techwg@sipforum.org

<= br>

SIPNOC 2014 Call for Presenta= tions and Early-Bird Registration Deadlines Extended!<= /h1>

Proposals are being accepted= for workshops, panels, speaker presentations and =E2=80=9CBirds of a Feath= er=E2=80=9D sessions addressing the deployment of SIP in service provider e= nvironments at SIPNOC 2014, June 9 -12= , 2014.

A= three-day educational conference focusing on the challenges and opportunit= ies related to the deployment of SIP-based carrier services globally, SIPNO= C 2014 is a unique, network operator-centric event. Organizers invite compa= nies, executives and industry insiders to propose presentations highlightin= g the use of session initiation protocol (SIP) in service provider environm= ents. Operators are encouraged to present SIP-related success stories, depl= oyment issues and concerns in their networks, while equipment vendors and o= ther industry stakeholders are invited to work with operators to present re= al-world deployment experiences.

T= he SIPNOC conferences attract leading technical and operations personnel fr= om the global carrier community and have earned high praise from attendees = for their educational, non-commercial and technical content that focuses on= the real-world challenges operators face when deploying SIP services in gl= obal IP networks. SIPNOC 2014 attendees will include telecommunications pro= viders, major backbone operators, interconnect and wholesale solution provi= ders, ISPs, cable operators, wireless network operators as well as large en= terprises deploying major SIP initiatives.

S= IPNOC 2014 Call for Presentations proposals can be submitted by visiting th= e SIP Forum SIPNOC 2014 Call for Presentations site. Possible topics c= an include SIP peering, SIP trunking, Emergency Services, Congestion Contro= l, Scaling and Capacity Issues, SIP-based applications, Routing, Security, = SIP-Network Operations Center Best Practices, IPv6 deployment challenges, U= ser-agent Configuration, Standardization Issues and Progress, HD voice depl= oyments, Video Interoperability, WebRTC and SIP, FoIP/T.38 Deployment, Test= ing or other issues facing SIP network operations.

S= IPNOC 2014 offers several different types of speaking opportunities includi= ng:

  • General Session Talks: A General Session presen= tation should be on a topic of interest to the general SIPNOC audience, and= may be up to 30 minutes long (including time for Q&A). <= /span>
  • General Session Pa= nels: Panels are sessions with a moderator and a team of panelists. The pan= el moderator should submit an abstract on the panel topic, a list of paneli= sts, and how the panel will be organized. Panel selection is based on the i= mportance, originality, focus and timeliness of the topic, expertise of pro= posed panelists, as well as the potential for informative and controversial= discussion.
  • Special Workshops:= The SIPNOC 2014 program has been expanded to include special workshops tha= t run for 2-3 hours, providing time to focus in-depth on a variety of issue= s important to the SIPNOC community. Topics can include a review of SIP RFC= s and standards development, the regulatory environment, etc.=
  • Research Topics: R= esearchers are invited to present short summaries of their work for operato= r feedback. Topics may include call routing, network performance, statistic= al measurement and analysis and protocol development and implementation. St= udies presented may be works in progress. Researchers from academia, govern= ment, and industry are encouraged to present.
  • BOFs: BOFs (Birds = of a Feather sessions) are informal sessions on topics which are of interes= t to a portion of the SIPNOC community. BOFs may be held in break=E2=80=90o= ut areas or in an unscheduled room. Requests for scheduled BOFs can be made= at any time, including on site at the conference.

The following is a complete list of key dates for the SIPNOC 2014 speak= ing program:

  • Presentation Abstracts Due =E2=80=93 Janua= ry 31, 2014
  • Draft Presentations Due -- February 15, 2014
  • Acceptance Decisio= n and Notifications -- February 21, 2014
  • Draft Program Published =E2= =80=93 March 1, 2014
  • Final Presentation= s Due -- April 1, 2014
  • Final Agenda Published -- April 15, 2014
  • Conference Begins = -- June 9, 2014

=C2=A0

SIPNOC 2014 General Info

The= SIPNOC 2014 event website is located at www.sipnoc.org.

T= o view the official call for presentations, which includes instructions on = submitting material and specific SIPNOC policies, please visit www.sipforu= m.org/content/view/374/275/. To submit, visit https://www.e= asychair.org/conferences/?conf=3Dsipnoc2014.

R= egistration for SIPNOC 2014 is officially open!

= Spec= ial pricing for SIPNOC 2014 is now in effect! Take advantage of special ear= ly-bird pricing now through March 1, 2014. The regular SIPNOC 2014 conferen= ce registration fee is $995, but for a limited time regular attendees can s= ave $145 and pay only $850 for three days of conference proceedings. This f= ee includes a special welcome reception the evening before the event with f= ood and drink; breakfast, lunch and break refreshments and snacks; and spec= ial networking receptions the first and second night of the event.

Individuals from SIP Forum Full Member companies save even m= ore ($295 off the regular price to be exact with special early-bird pricing= )! Please contact Marc Robins, SIP Forum President and Managing Director, a= t marc.robins= @sipforum.org to obtain the exclusive Full Member discount code.=

R= egister today at www.regonline.com/sipnoc2014.=C2=A0

SIPNOC 2014 Sponsorship Information

F= or information about corporate sponsorship opportunities at SIPNOC 2014, pl= ease contact Marc Robins, SIP Forum President and Managing Director, at 203-829-= 6307 or m= arc.robins@sipforum.org.

=

*************************

Marc Robins

President and Managing Director<= u>

SIP Forum

http://www.sipforum.org

Mobile: 203-829-6307<= /p>

SkypeMe! marcrobins

=C2=A0

**************= ***********

=C2=A0

=C2=A0


________________________________________= _______
techwg mailing list
Send mail to: techwg@sipforum.org
Unsubscribe or edit options at: =C2=A0http://sipforum.org/mailman/listinfo/t= echwg


--001a11c38d7024942804ef50ffb0-- From mary.ietf.barnes@gmail.com Mon Jan 6 11:00:26 2014 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 AC72D1AE15B for ; Mon, 6 Jan 2014 11:00:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.698 X-Spam-Level: X-Spam-Status: No, score=-1.698 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, 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 zTDLBPOfTaup for ; Mon, 6 Jan 2014 11:00:20 -0800 (PST) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 94C2D1AE164 for ; Mon, 6 Jan 2014 11:00:18 -0800 (PST) Received: by mail-wi0-f171.google.com with SMTP id bz8so3199558wib.4 for ; Mon, 06 Jan 2014 11:00:09 -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=N1nft89BCvq1Jc3OhIR8+Ex5qcxPqGJsbg7uTZd45Qs=; b=jAB3xmV1X+DA2tc6q/UJ1mZQz91bEE/4pcuzp/UsVtX0C8OqERQXyIY7lG5HEYwvMj 6UP9X1ETMmG3Mx2KQmuzD7aSn/NXRmgej+aYEs6pMvwPA0XZN80ShO41y2ex2qCVBzsF K90u7w6rpTy1seB0O7Sq9lUsj78Sl1/r4yPzchR5jwE8SdZsMNPNaizuhfJqs056gHNu HKEoZpokyVG2EHGs8EVUV0Z6INblSJrtrul7EJlg3PP1TPMvK0CM6t3MQA+MdiAyIABd LYQLvcyYXbGEkaMfDt/3vg7+t4xa/Fqz77uZXL06jVTiUy8FExsTPoj+9FW3V+DhhHcs KKoA== MIME-Version: 1.0 X-Received: by 10.180.228.8 with SMTP id se8mr13401205wic.7.1389034809576; Mon, 06 Jan 2014 11:00:09 -0800 (PST) Received: by 10.216.172.9 with HTTP; Mon, 6 Jan 2014 11:00:09 -0800 (PST) In-Reply-To: <058CE00BD4D6B94FAD033A2439EA1E4B01DF8E83EB24@HE113667.emea1.cds.t-internal.com> References: <058CE00BD4D6B94FAD033A2439EA1E4B01DEBB69CC8A@HE113667.emea1.cds.t-internal.com> <058CE00BD4D6B94FAD033A2439EA1E4B01DF27DB8A63@HE113667.emea1.cds.t-internal.com> <058CE00BD4D6B94FAD033A2439EA1E4B01DF8E83EB24@HE113667.emea1.cds.t-internal.com> Date: Mon, 6 Jan 2014 13:00:09 -0600 Message-ID: From: Mary Barnes To: "R.Jesske@telekom.de" Content-Type: multipart/alternative; boundary=001a1134db5467ed0304ef51de0b 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: Mon, 06 Jan 2014 19:00:26 -0000 --001a1134db5467ed0304ef51de0b Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Roland, One final editorial nit below. If you can spin a revision, then I'll send the PROTO write-up to the AD. Thanks, Mary. On Thu, Jan 2, 2014 at 3:29 AM, wrote: > Hi Mary, > > I wish you a happy new year 2014. And the best for the next year. > > > > I was looking again on my changes I made due to your proposal in December= . > > I realized that if I change the SHOULD to MUST we have now a backward > compatibility problem. > > We are using the P-Associated-URI also over the IMS user interface which > is not encrypted. > > So I propose to add some more words. > > =85 > > Section 6.1 > > =85 > > An eavesdropper could possibly collect the list of identities > a user is registered. > > This can 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. > > > > Since the P-Associated-URI header field value allows to > implicitly register > > a bundle of URIs with one REGISTER Message the impact of security > using the P-Associated-URI header field is not higher than > > using single REGISTER messages when registering all identities > explicit. > [MB] I just have some editorial suggestions for the above: NEW: While the P-Associated-URI header field value allows the implicit registration of a bundle of URIs with one REGISTER Message the impact of security using the P-Associated-URI header field is no higher than using separate REGISTER messages for each of the URIs. [/MB] > > > > > > For the P-Called-Party-Id the change should be also done like as follows: > > > > An eavesdropper could possibly collect the list of identities > a user is registered. > > This can have privacy implications. To mitigate this problem, thi= s > extension SHOULD > > only be used in a secured environment, where encryption of SIP > messages is > > provided either end-to-end or hop-by-hop. > > > > Normally within a 3GPP environment the P-Called-Party-ID is > not sent towards end users but may be exchanged between carriers where > other security mechanisms than SIP encryption are used. > > > > Sorry coming so late. > > If this is OK for you I will include it to a new version. > > > > Thank you and Best Regards > > > > Roland > > > > *Von:* Mary Barnes [mailto:mary.ietf.barnes@gmail.com] > *Gesendet:* Freitag, 27. Dezember 2013 19:45 > > *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 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 so= me > 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 "potent= ially 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 th= e 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" t= hat makes this header not of particular concern with regards to security. D= oes it reveal additional, unique information about an individual that isn't= available in other headers. Also, the 2nd paragraph needs some work - may= be 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 r= egistered. 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 rev= ision. And, I believe you still need to identify privacy/security implicat= ions by addressing whether or not this header reveals any unique informatio= n 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 > > - > > > > > --001a1134db5467ed0304ef51de0b Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi Roland,

One final editorial nit belo= w. =A0If you can spin a revision, then I'll send the PROTO write-up to = the AD.

Thanks,
Mary.=A0


On Thu, Jan 2, 2014 at 3:29 AM, <R.J= esske@telekom.de> wrote:

Hi Mary,

I wish you a happy new year 2014. And the best = for the next year.

=A0

<= p class=3D"MsoNormal">I was looking again on my chan= ges I made due to your proposal in December.

I realized that if I change t= he SHOULD to MUST we have now a backward compatibility problem.

We are using the P-Associated= -URI also over the IMS user interface which is not encrypted.=

So I propose to add some more= words.

=85

Section 6.1

=85

=A0=A0=A0=A0=A0=A0=A0=A0 <t>An eavesdropper could possibl= y collect the list of identities a user is registered.=A0

=A0=A0=A0=A0=A0=A0=A0This can have privacy = implications. To mitigate this problem, this extension SHOULD

=A0=A0=A0=A0=A0=A0=A0only be used in a secu= red environment, where encryption of SIP messages is <= /p>

=A0=A0=A0=A0=A0=A0=A0= provided either end-to-end or hop-by-hop.=A0 </t>

=A0=A0

=A0=A0=A0=A0=A0=A0<t> Since the P-Associated-URI header field value= allows to implicitly register

=A0=A0=A0=A0=A0=A0a bundle of URIs with one= REGISTER Message the impact of security using the P-Associated-URI header = field is not higher than=A0

=A0=A0=A0=A0=A0=A0using single REGISTER messages when registering all ide= ntities explicit.</t>

[MB] I just have some editorial suggestions f= or the above:
NEW: =A0

<t><= span lang=3D"EN-US">=A0While the P-Associated-URI header field value allows= the implicit registration of=A0

=A0=A0=A0=A0=A0=A0a bundle of U= RIs with one REGISTER Message the impact of security using the P-Associated= -URI header field is no higher than=A0

=A0=A0=A0=A0=A0=A0using separate REGISTER m= essages for each of the URIs.=A0</t>

[/MB]

=A0

=A0

=A0=

=A0

For the P-Calle= d-Party-Id the change should be also done like as follows:

=A0=

=A0=A0=A0=A0=A0=A0=A0 <t><= /span>An eavesdropper= could possibly collect the list of identities a user is registered.=A0 =

=A0=A0=A0=A0=A0=A0=A0This can have privacy = implications.=A0 To mitigate this problem, this extension SHOULD =

=A0=A0=A0=A0=A0=A0=A0only be used in a secu= red environment, where encryption of SIP messages is <= /p>

=A0=A0=A0=A0=A0=A0=A0= provided either end-to-end or hop-by-hop.=A0 </t&= gt;

=A0

=A0=A0=A0=A0= =A0=A0=A0 <t>No= rmally within a 3GPP environment the P-Called-Party-ID is not sent towards = end users but may be exchanged between carriers where other security mechan= isms than SIP encryption are used.=A0 </t>

=A0

<= p class=3D"MsoNormal">Sorry coming so late.

If this is OK for you I will = include it to a new version.

=A0

<= span lang=3D"EN-US" style=3D"font-size:11pt;font-family:Calibri,sans-serif;= color:rgb(31,73,125)">Thank you and Best Regards

=A0

<= p class=3D"MsoNormal">Roland

=A0

<= /div>

Von: Mary Barnes [mailto:mary.ietf.barnes@gmail.com]
Gesendet: Freitag, 27. Dezember 2013 19:45


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

=A0=

Hi Roland,

=A0

= Thanks for making these changes. I finally had a chance to review this upda= ted version. =A0 I still have a couple comments on the security section as = I think you will get questions during SEC review around this unless some mo= re detail is provided on security threats and impacts. =A0 I've extract= ed these few points from previous review comment threads.

=A0

Thanks,

M= ary.

=A0

----Previous point =A0------------------------------= --->

- Section 6.1: this needs some tighter wording. =A0What is mean=
t by "potentially annoying" =A0for example? =A0
=A0[RJ] I do not know. T=
his 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 &q=
uot;what are the insignificant impacts and are there any privacy concerns&q=
uot;?=A0 Really, it's the next paragraph that provides details of the i=
mpacts.=A0 I think you could probably remove that sentence altogether and n=
ot lose anything. 


=
[/MB]
<= pre style=3D"white-space:pre-wrap"> ----Previous point --------------------------------->
-=A0 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 individ=
ual that isn't available in other headers. =A0Also, the 2nd paragraph n=
eeds some work - maybe something like:


OLD:
An eavesdropper may collect the list of =
identities a user is registered.=A0 This may have privacy implications.=A0 =
To mitigate this problem, this extension SHOULD only be used in a secured e=
nvironment, where encryption of SIP messages is provided either end-to-end =
or


hop-by-hop.=A0
NEW:=A0
=A0
An =
eavesdropper could possibly collect the list of identities a user is regist=
ered.=A0 This can have privacy implications.=A0 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.=A0
----End previous point --------=
----------------------<=

[MB]=A0 The suggested change fo=
r the first sentence didn't get into the revision.=A0 And, I believe yo=
u still need to identify privacy/security implications by addressing whethe=
r or not this header reveals any unique information about an individual tha=
t isn't available in other headers.=A0=A0 [/MB]
<=
/u>=A0

<=
/u>=A0

=A0

=A0

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

Hi Mary,

<= p class=3D"MsoNormal">Thank you for your comments an= d proposals.

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

So we can now proceed.

=

=A0

Thank you and Best Regards

=A0

Roland

=A0

A new version of I-D, draft-drage-sipping-rfc= 3455bis-10.txt

has been suc= cessfully submitted by Roland Jesske and 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 (SIP) for the 3rd-Ge= neration Partnership Project (3GPP)

Creation date:=A0=A0=A0 2013-12-03<= /u>

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

N= umber 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 Protocol<= /u>

=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

<= /div>

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


An: Jesske, Roland
Cc: DISPA= TCH; Gonzalo Camarillo; Atle Monrad; Dean Willis

Betreff: Re: PROTO Review: draft-drage-sipping-rfc3455bis-09.txt<= /u>

=A0

<= div>

Hi Roland,

=A0

Thanks for your resp= onse. =A0Additional comments below [MB].

=A0

Tha= nks,

Mary.

=A0

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

Hi Mary,<= /u>

Thank you for y= our review.

I have added now your proposa= ls to the draft.

Other comments please see below.

=A0

<= p class=3D"MsoNormal">I hope now everything is OK.

=A0=

Thank you and Best Regard= s

=A0

<= p class=3D"MsoNormal">Roland

=A0

<= /div>

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
=A0
- =
Section 3. =A0This section needs to be updated. =A0I don't think that 1=
0 year old background is relevant in the current context. =A0 You should be=
 able to model this after the text in more recent 3GPP P-header documents, =
referring to the SIP change process.=A0
=A0
[RJ] OK, I have changed the text:

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

=A0=A0=A0=A0 the protocol used to establish and tear down multimedia sessi= ons in the

=A0=A0=A0=A0 context of its IP Multimedia Subsystem (IMS). For more inform= ation on

=A0=A0=A0=A0 the IMS, a detailed description can be found in 3GPP TS 23.22= 8 . This document is an update of RFC3455=A0 =A0which covers the requiremen= ts in RFC4083 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<= u>

[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 (3GPP) uses SIP as

=A0=A0=A0=A0 the protocol =A0= to establish and tear down multimedia sessions in the<= /p>

=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 defines S= IP private header extensions (referred to as P-headers) which are=A0=

=A0 =A0 =A0required by the 3G= PP 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 upda= tes existing P-header=A0descriptions=A0=

=A0 =A0 =A0to address additional requirement= s which are needed for 3GPP Release 11.=A0

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

=A0

[/MB]=A0

=A0

- Section 4.1. "registered address-of-record" ->=
; "registered SIP address-of-record"
- Section 4.1, 3rd paragraph. =A0"Note that, 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 applicable to proxies, therefo=
re the proxy MUST relay the header field unchanged. =A0I would suggest rewo=
rding 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=

NEW:=

=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
=A0
Section 4.2, 1st paragraph. =
=A0The behavior in this sentence is not normative from a SIP protocol persp=
ective, thus MAY is not appropriate. =A0I suggest the MAY be changed to &qu=
ot;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 is not normative fr=
om a SIP protocol perspective, thus =A0I suggest the MAY be changed to &quo=
t;can".=A0
=A0
- Section 4.3.3, last paragraph. =A0I thi=
nk this ought to be a MUST: "The identifier should be globally unique.=
."=A0
=A0
- Section 4.3.2.1. =A0This text has chang=
ed from the -08. =A0 I don't know what a "normal User Equipment&qu=
ot; is and the term "User Equipment" is not defined in this speci=
fication. =A0I think it would be better to say something like. However, eve=
n with this proposed change, I think you also need text for user agent serv=
er behavior - i.e., what would a UAS do if it received this header.=A0
=A0
OLD:
=A0=A0 A normal User Equipme=
nt has normally no knowledge of the P-Visited-
=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.
=A0
NE=
W:=A0
=A0=A0 =
In the context of the network to which the header fields defined in this do=
cument apply, a User Agent has=A0no knowledge of the P-Visited-Network-ID w=
hen sending the REGISTER request. =A0Therefore user agent clients MUST NOT =
insert a P-Visited-Network-ID=A0header field=A0in any SIP message.
=A0
- Section 4.3.2.2:, 2nd paragraph: =A0"home network MAY use&qu=
ot; -> "home network can use"


=A0
=A0<=
/pre>
- 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 b=
e deleted when the request is forwarded. 


=A0<=
/pre>
=
Section 4.4.2.1, 2nd paragraph: =A0"MUST trust the proxy" -> &=
quot;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 tr=
ust" -> =A0"there MUST also be a transitive trust"=A0


Section 4.4.2.2, 2nd paragraph: "MAY act upo=
n any information present" -> "can act upon any information pr=
esent", =A0"MAY use the call id" -> "can use the=A0<=
/span>call id"=A0<=
u>


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



=A0
- Section 4.6.2, 3rd paragrap= h: "MAY use the values" -> "can use the values"=A0 
- Section 4.6.3, 3rd paragraph: needs some editorial work. =A0Ma=
ybe the following change would work:=A0
=A0
OL=
D:
=A0=A0 Depending on the call scenario it is needed to add for ea=
ch transit
=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
=A0
NE=
W:=A0
=A0<=
/u>
=
=A0=A0 Depending on the call scenario, each transit network can add either =
a transit network name=A0or a void=A0=A0=A0 value.=A0 However, it can not b=
e guaranteed that all the values that are added will appear within the P-Ch=
arging-Vector header field.
=A0
- Section 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 that is trying to s=
ay other than void values have no index. =A0What does "taken into cons=
ideration" mean. Are you talking about limits on the number of entries=
 or are you suggesting that the number of void values must be considered wh=
en setting the index for the transit network names? =A0
=A0
[RJ] Yes! Changed the text to:
=A0
A void value has no index. By a=
dding the next value the index has to be incremented by the number of void =
entries +1.
=A0
- Section 4.6.4.2: I don't kn=
ow what this means:=A0=A0"A deletion of the elements could appear depending on=
 the network policy and trust rules". =A0Is it just trying to say that along with the adding =
and modifying in the previous sentence that the elements can also be delete=
d by the proxy?=A0
=A0
[RJ] Yes, I have changed the text:

Procedures described within 4.6.2.2 apply. A transit-ioi MAY be<= /u>

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 added or modified by a proxy. 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 re=
placing the transit-ioi with a void value.
<= pre>=A0 
=A0
=A0
=A0
- Section 5.7. Delete thi=
s 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 w=
hat 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 REGI= STER method and 2xx resonses, P-Called-Party-ID can appear in SIP INVITE, O= PTIONS, PUBLISH,SUBSCRIBE, MESSAGE methods and all responses, P-Visited-Net= work-ID can appear in all SIP methods except ACK, BYE and CANCEL and all re= sponses, 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 CANCEL.

[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 an=
noying" =A0for example? =A0
=A0
[RJ] I do not know. This is original text. So I deleted the words.=

=A0=

- Sectio=
n 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=
9;t available in other headers. =A0Also, the 2nd paragraph needs some work =
- maybe something like:
=A0
OLD:
An eavesdropper may collect =
the list of identities a user is registered.=A0 This may have privacy impli=
cations.=A0 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


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


=A0
=A0An eavesdropper could possibly =
collect the list of identities a user is registered.=A0 This can have priva=
cy implications.=A0 To mitigate this problem, this extension MUST only be u=
sed in a secured environment, where encryption of SIP 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 registe= red by a user."=A0

[/MB]=A0=A0

- Section =
6.4,=A0
--3rd paragraph: "should not&q=
uot; -> "MUST NOT"=A0
=A0
-- 7th paragraph: =A0"SHOULD NOT be =
sent" -> "MUST NOT be sent"=A0
= 
=A0
=A0
=A0
-- 8th paragraph: &qu=
ot;SHOULD NOT send sensitive information" -> "MUST NOT send se=
nsitive information"


=A0
=A0<=
u>
-- 9th paragr=
aph: "is required to delete" -> "is REQUIRED to delete&qu=
ot;=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 these headers, is it not?


=A0
[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.
=A0
-- 11th paragraph: So, what does a proxy do with that informatio=
n. =A0What are the impl=
ications if the information is used and it's not valid? =A0
[RJ] Yes I did some changes as follows.
=A0

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

=A0=A0=A0=A0=A0=A0 header field from a non-trusted entity is not able to g= uarantee the

=A0=A0=A0=A0=A0=A0 validity of the contents. Th=
us this content SHOULD be deleted based on local policy.</t>
=A0
- Sectio=
n 9, item 2. =A0I think you need to add this text with regards to the recom=
mendation to use RFC 4244 (bis) to the body of this document and include a =
real reference.
=A0
[RJ] OK done. I let the reference RFC4244 si=
nce 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 target=3D"RFC4244&q=
uot;></xref>. 3GPP will continue to use the

=A0=A0=A0=A0=A0=A0=A0=A0 P-Called-Party-ID head=
er field even though RFC 4244 <xref
=A0=A0=A0=A0=A0=A0=A0=A0 target=3D"RFC4244">=
</xref> has now been published.</t>


=A0
I think the text in Section 9.2 is better.


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


- Section 4.1.2.2, 2nd parag=
raph, "In case" -> "If", =A0"shall not" -&=
gt; SHALL NOT


- Section 4.3.2.2, last sentence. =A0The -09 int=
roduced a typo: "T means" -> "This means"=A0<=
u>


=A0
- Section 4.3.2.3, 1=
st paragraph after 1st example. =A0The -09 introduced another typo: "t=
he REGISTRAR" -> "at the REGISTRAR"<=
/pre>

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


=A0
=
Section 4.6, 2nd paragraph: "includes, includes but is not limited to&=
quot; -> "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 t= o inform you that I have implemented all comments coming from the expert re= view 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

=A0


<= /div>
--001a1134db5467ed0304ef51de0b-- From mary.ietf.barnes@gmail.com Mon Jan 6 15:04:07 2014 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 523201AE2C6 for ; Mon, 6 Jan 2014 15:04:07 -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 nRrQWsMkSs81 for ; Mon, 6 Jan 2014 15:04:03 -0800 (PST) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) by ietfa.amsl.com (Postfix) with ESMTP id BD67F1AE2C8 for ; Mon, 6 Jan 2014 15:04:02 -0800 (PST) Received: by mail-wi0-f177.google.com with SMTP id cc10so19829wib.16 for ; Mon, 06 Jan 2014 15:03:53 -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=VO7OtHL7PzcSUGoDfb8ZN5FXt9UerIO8RjBP5JyEkPw=; b=ScS6U1eOQPmGCxSMcCJ5H7C7Mx+t+LfiP4yS7Tnfv9uDrPb98t1LuFW7H9MsKqKphe tE/ds0r/Xqx3MFrvzLb/btmkRhpSNR1xck5YI0b0bIjUGLeq6vjzzwxYt/CROWgRgW1N PY1w88sLFauIzXLKz9WJSxqMc/g4+R1X9WLPtYYr1iRgRU4mlowMqTpWpu2ecqs4PDBz kHb+EAWy7Jj6Mj3gze+NNIGvef+OJOILFJ+LNziVALoNwImLSfXpl/Ogyt+gI4vtVdCg DivqBrcEFttQCWkLLj8Em44hIvxKhTeWzVmft1VLIw5J8TGhWRYky6nGSOF8soB0MtjG 5uqQ== MIME-Version: 1.0 X-Received: by 10.180.228.8 with SMTP id se8mr14135049wic.7.1389049433801; Mon, 06 Jan 2014 15:03:53 -0800 (PST) Received: by 10.216.172.9 with HTTP; Mon, 6 Jan 2014 15:03:53 -0800 (PST) In-Reply-To: References: <20130912005949.3447.42089.idtracker@ietfa.amsl.com> <523124B0.2000305@ntt-at.co.jp> Date: Mon, 6 Jan 2014 17:03:53 -0600 Message-ID: From: Mary Barnes To: Mayumi Ohsugi , Shida Schubert Content-Type: multipart/alternative; boundary=001a1134db5413c90d04ef5546c3 Cc: DISPATCH Subject: Re: [dispatch] New Version of draft-vanelburg-dispatch-private-network-ind 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: Mon, 06 Jan 2014 23:04:07 -0000 --001a1134db5413c90d04ef5546c3 Content-Type: text/plain; charset=ISO-8859-1 Hi all, I have reviewed the revised version and I just a few final comments. - Section 1.5, first bullet in the bulleted list: either change "an emergency calls" to "an emergency call" or "emergency calls" - Section 3.6. "require the Specifying a Spec (T)." -> "require specifying a Spec(T)" or "require the specification of a Spec(T)" - Section 5, I had suggested the the requirements be consistent in usage of 2119 language. One of the requirements (R6) was changed, but R2 and R3 were not. Was there a specific reason not to make those suggested changes? R2: "The indication from R1 can be inserted by a SIP proxy" -> "The indication from R1 MAY be inserted by a SIP proxy" R3: "The indication from R1 can be removed by a SIP proxy" -> "The indication from R1 MAY be removed by a SIP proxy" Thanks, Mary. On Tue, Oct 29, 2013 at 9:11 AM, Mary Barnes wrote: > In reviewing the document in preparation for the PROTO write-up, I have a > few comments (minor and nits) that should be addressed prior to the > document being progressed. > > Regards, > Mary. > > Comments: > --------------- > > - General: domains used in this document must use a reserved domain such > as "example.com" and must not use real domains. Thus, all occurrences of > ericsson.com need to be changed to example.com > > - Section 1.5. Bulleted list, first bullet. I would suggest you just > leave out the mention of LI. Emergency services should be a sufficient > example. > > - Section 1.5, last numbered list, item 2. I had a hard time groking this > sentence and had to read several times. I would suggest rewording something > like (if I've properly interpreted the intent): > OLD: > > Different nodes spanning over different networks may need to be > able to act differently on type of traffic, when implicit schemes > are used, it would require distribution of such enterprise > specific logic over multiple nodes in multiple operators. That > is clearly not a manageable architecture and solution. > > > NEW: > > Nodes spanning multiple networks often need to have different > > behavior depending upon the type of traffic. When this is done using implicit > > schemes, enterprise specific logic must be distributed across multiple > > nodes in multiple operator's networks. > > That is clearly not a manageable architecture and solution. > > > > - Section 1.5, last sentence. I don't think that statement is sufficient > for what this document is doing. I would suggest you change that sentence > to something like the following: > OLD: > > Given the above background this document will formulate requirements > for SIP to support an explicit private network indication. > > > NEW: > > Based on the background provided, this document formulates requirements > for SIP to support an explicit private network indication and defines > > a P-header, P-Private-Network-Indication, to support those requirements. > > > > - Section 3, next to last paragraph. I'm not sure what is meant by "the > filling out a Spec(T)". I don't see "filling" used as a concept in RFC > 3324. Perhaps, "specifying a Spec(T)" is more consistent with terminology > in RFC 3324. > > - Section 5. In general, the requirements are not specific consistently - > i.e., some use 2119 language and others not and there is not consistent > capitalization. I would suggest the following changes. > R2: "The indication from R1 can be inserted by a SIP proxy" -> "The > indication from R1 MAY be inserted by a SIP proxy" > R3: "The indication from R1 can be removed by a SIP proxy" -> "The > indication from R1 MAY be removed by a SIP proxy" > R6: "must" -> "MUST" > > - Section 6, 2nd paragraph. The "can" in the first sentence should be a > "MAY" and the sentence needs to be split into two: > OLD: > > A proxy server which handles a message can insert such a P-Private- > Network-Indication header field into the message based on > authentication of the source of a message, configuration or local > policy, and forward it to other proxies in the same administrative > domain or proxies in trusted domain to be handled as private network > traffic. > > > NEW: > > A proxy server which handles a message MAY insert such a P-Private- > Network-Indication header field into the message based on > authentication of the source of a message, configuration or local > policy. A proxy server MAY forward the message to other proxies in the > > same administrative domain or proxies in a trusted > > domain to be handled as private network traffic. > > > > Section 9. You should be explicit about the header name in this section. > The text in the first paragraph needs some work. At a minimum you need to > change the "not supposed to" to something more definitive as all security > issues arise because someone does something they're not supposed to. I > would suggest at least making the following change: > OLD: > > The private network indication defined in this document is to be used > in an environment where elements are trusted and where attackers are > not supposed to have access to the protocol messages between those > elements. Traffic protection between network elements is sometimes > achieved by using IPsec and sometimes by physical protection of the > network. In any case, the environment where the private network > indication will be used ensures the integrity and the confidentiality > of the contents of this header field. > > NEW: > > The private network indication defined in this document MUST only be used > in an environment where elements are trusted and where attackers are > do not have access to the protocol messages between those > elements. Traffic protection between network elements can be > achieved by using IPsec and sometimes by physical protection of the > network. In any case, the environment where the private network > indication will be used ensures the integrity and the confidentiality > of the contents of this header field. > > > > Nits: > ------ > - Section 1.1: "3rd-Generqation" -> 3rd-Generation > - The terms "break-in" and "break-out" traffic are used several places in > the document, but this term is never defined. These terms should be > defined in Section 3. > - Figures should have Titles for readability > > > > On Wed, Sep 11, 2013 at 9:19 PM, Mayumi Ohsugi > wrote: > >> Hi, >> >> I have submitted the following draft: >> >> http://www.ietf.org/internet-drafts/draft-vanelburg- >> dispatch-private-network-ind-03.txt >> >> The draft reflects all the comments discussed in DISPATCH list. >> >> The major changes are as follows: >> >> - corrected the abstract >> - corrected the term "common domain" to "pre-arranged domain" >> - added 7.1.4 "P-Private-Network-Indication verification" >> - editorial changes >> >> Regards, >> Mayumi >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> > > --001a1134db5413c90d04ef5546c3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi all,

I have reviewed the revised ver= sion and I just a few final comments.

- Section 1.= 5, first bullet in the bulleted list: either change "an emergency call= s" to "an emergency call" or "emergency calls"

- Section 3.6. =A0"require the Specifying a Spec (= T)." -> "require specifying a Spec(T)" or "require t= he specification of a Spec(T)"

- Section 5, I= had suggested the the requirements be consistent in usage of 2119 language= . =A0One of the requirements (R6) was changed, but R2 and R3 were not. =A0W= as there a specific reason not to make those suggested changes? =A0=A0

R2: =A0 "The indication from R1 can be inserted by a SIP proxy" -> &= quot;The indication= from R1 MAY be inserted by a SIP proxy" =A0=A0
= R3: "The indication f= rom R1 can be removed by a SIP proxy" -> "The indication from R1 MAY be removed= by a SIP proxy"

Thanks,
Mary.=A0


On Tue, Oct 29, 2013 at 9:11 AM, Mary Barnes <m= ary.ietf.barnes@gmail.com> wrote:
In reviewing the document i= n preparation for the PROTO write-up, I have a few comments (minor and nits= ) that should be addressed prior to the document being progressed.

Regards,
Mary.

Comments:
---------------
=
- General: domains used in this document must use a reserved= domain such as "exam= ple.com" and must not use real domains. Thus, all occurrences of <= a href=3D"http://ericsson.com" target=3D"_blank">ericsson.com need to b= e changed to example.com

- Section 1.5. =A0Bulleted list, first bullet. I would = suggest you just leave out the mention of LI. =A0Emergency services should = be a sufficient example. =A0

- Section 1.5, last numbered list, item 2. =A0I had a hard time groking thi= s sentence and had to read several times. I would suggest rewording somethi= ng like (if I've properly interpreted the intent):
OLD:
       Different nodes spanning over different networks may need=
 to be
       able to act differently on type of traffic, when implicit schemes
       are used, it would require distribution of such enterprise
       specific logic over multiple nodes in multiple operators.  That
       is clearly not a manageable architecture and solution.


OLD:
   Given the above background this document will =
formulate requirements
   for SIP to support an explicit private network indication.
NEW:=A0
   Based on the background provided, this document formulates requirements
   for SIP to support an explicit private network indication and defines 
   a P-header, P-Private-Network-Indication, to support those req=
uirements.


- Section 3, next to last paragraph. =A0I'm not sure what is meant by &= quot;the filling out a Spec(T)". I don't see "filling" u= sed as a concept in RFC 3324. =A0Perhaps, "specifying a Spec(T)" = is more consistent with terminology in RFC 3324.=A0

- Section 5. =A0In general, the requirements are not sp= ecific consistently - i.e., some use 2119 language and others not and there= is not consistent capitalization. =A0I would suggest the following changes= .
R2: =A0 "The ind= ication from R1 can be inserted by a SIP proxy" -> "The indication from R1 MAY be= inserted by a SIP proxy" =A0=A0
R3: "The indicat= ion from R1 can be removed by a SIP proxy" -> "The indication from R1 MAY be remo= ved by a SIP proxy"
R6: "mus= t" -> "MUST"

- Section 6, 2nd p= aragraph. The "can" in the first sentence should be a "MAY&q= uot; and the=A0sentence need= s to be split into two:
OLD:
   A prox=
y server which handles a message can insert such a P-Private-
   Network-Indication header field into the message based on
   authentication of the source of a message, configuration or local
   policy, and forward it to other proxies in the same administrative
   domain or proxies in trusted domain to be handled as private network
   traffic.

NEW:=A0
  =
 A proxy server which handles a message MAY insert such a P-Private-
   Network-Indication header field into the message based on
   authentication of the source of a message, configuration or local
   policy.  A proxy server MAY forward the message to other proxies in the=
=A0
   same administrative domain or proxies in a trusted=A0


   domain to be handled as private network traffic.

Section 9= . =A0You should be explicit about the header name in this section. =A0The t= ext in the first paragraph needs some work. =A0At a minimum you need to cha= nge the "not supposed to" to something more definitive as all sec= urity issues arise because someone does something they're not supposed = to. =A0 I would suggest at least making the following change:
OLD:
   The pr=
ivate network indication defined in this document is to be used
   in an environment where elements are trusted and where attackers are
   not supposed to have access to the protocol messages between those
   elements.  Traffic protection between network elements is sometimes
   achieved by using IPsec and sometimes by physical protection of the
   network.  In any case, the environment where the private network
   indication will be used ensures the integrity and the confidentiality
   of the contents of this header field.
NEW:
   The private network indication defined in this document MUST only=
 be used
   in an environment where elements are trusted and where attackers are
   do not have access to the protocol messages between those
   elements.  Traffic protection between network elements can be
   achieved by using IPsec and sometimes by physical protection of the
   network.  In any case, the environment where the private network
   indication will be used ensures the integrity and the confidentiality
   of the contents of this header field.

Nits:
------
- Section 1.1: =A0"3rd-Generqation" ->=A03rd-Generation =A0
- The terms "bre= ak-in" and "break-out" traffic are used several places in th= e document, but this term is never defined. =A0These terms should be define= d in Section 3.=A0
- Figures should have= Titles for readability



<= div class=3D"im">On Wed, Sep 11, 2013 at 9:19 PM, Mayumi Ohsugi <mayumi.ohsugi@ntt-at.co.jp> wrote:
Hi,

I have submitted the following draft:

http://www.ietf.org/internet-= drafts/draft-vanelburg-dispatch-private-network-ind-03.tx= t

The draft reflects all the comments discussed in DISPATCH list.

The major changes are as follows:

- corrected the abstract
- corrected the term "common domain" to "pre-arranged domain= "
- added 7.1.4 "P-Private-Network-Indication verification"
- editorial changes
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 Regards,
Mayumi
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch


--001a1134db5413c90d04ef5546c3-- From R.Jesske@telekom.de Mon Jan 6 22:35:52 2014 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 4F5B21AE44D for ; Mon, 6 Jan 2014 22:35:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.786 X-Spam-Level: X-Spam-Status: No, score=-1.786 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_NONE=-0.0001, RP_MATCHES_RCVD=-0.538] 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 Z5U2yIsGZ8Sm for ; Mon, 6 Jan 2014 22:35:42 -0800 (PST) Received: from tcmail33.telekom.de (tcmail33.telekom.de [80.149.113.247]) by ietfa.amsl.com (Postfix) with ESMTP id CA4EB1ADFB3 for ; Mon, 6 Jan 2014 22:35:41 -0800 (PST) Received: from he111631.emea1.cds.t-internal.com ([10.134.93.23]) by tcmail31.telekom.de with ESMTP/TLS/AES128-SHA; 07 Jan 2014 07:35:31 +0100 Received: from HE113667.emea1.cds.t-internal.com ([fe80::c943:1394:e86e:fce3]) by HE111631.emea1.cds.t-internal.com ([::1]) with mapi; Tue, 7 Jan 2014 07:35:31 +0100 From: To: Date: Tue, 7 Jan 2014 07:35:30 +0100 Thread-Topic: PROTO Review: draft-drage-sipping-rfc3455bis-09.txt Thread-Index: Ac8LEYdJRe2ml4KQQvOA7ZuPtFFVOAAYLppA Message-ID: <058CE00BD4D6B94FAD033A2439EA1E4B01DF8E83F451@HE113667.emea1.cds.t-internal.com> References: <058CE00BD4D6B94FAD033A2439EA1E4B01DEBB69CC8A@HE113667.emea1.cds.t-internal.com> <058CE00BD4D6B94FAD033A2439EA1E4B01DF27DB8A63@HE113667.emea1.cds.t-internal.com> <058CE00BD4D6B94FAD033A2439EA1E4B01DF8E83EB24@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_058CE00BD4D6B94FAD033A2439EA1E4B01DF8E83F451HE113667eme_" 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, 07 Jan 2014 06:35:52 -0000 --_000_058CE00BD4D6B94FAD033A2439EA1E4B01DF8E83F451HE113667eme_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Mary, Now a new revision is available. Thank you and Best Regards Roland Von: Mary Barnes [mailto:mary.ietf.barnes@gmail.com] Gesendet: Montag, 6. Januar 2014 20:00 An: Jesske, Roland Cc: DISPATCH; Gonzalo Camarillo; Atle Monrad; Dean Willis Betreff: Re: PROTO Review: draft-drage-sipping-rfc3455bis-09.txt Hi Roland, One final editorial nit below. If you can spin a revision, then I'll send = the PROTO write-up to the AD. Thanks, Mary. On Thu, Jan 2, 2014 at 3:29 AM, > wrote: Hi Mary, I wish you a happy new year 2014. And the best for the next year. I was looking again on my changes I made due to your proposal in December. I realized that if I change the SHOULD to MUST we have now a backward compa= tibility problem. We are using the P-Associated-URI also over the IMS user interface which is= not encrypted. So I propose to add some more words. ... Section 6.1 ... An eavesdropper could possibly collect the list of identities a= user is registered. This can have privacy implications. To mitigate this problem, this e= xtension SHOULD only be used in a secured environment, where encryption of SIP messa= ges is provided either end-to-end or hop-by-hop. Since the P-Associated-URI header field value allows to implicitl= y register a bundle of URIs with one REGISTER Message the impact of security usi= ng the P-Associated-URI header field is not higher than using single REGISTER messages when registering all identities explic= it. [MB] I just have some editorial suggestions for the above: NEW: While the P-Associated-URI header field value allows the implicit regis= tration of a bundle of URIs with one REGISTER Message the impact of security usi= ng the P-Associated-URI header field is no higher than using separate REGISTER messages for each of the URIs. [/MB] For the P-Called-Party-Id the change should be also done like as follows: An eavesdropper could possibly collect the list of identities a = user is registered. This can have privacy implications. To mitigate this problem, this = extension SHOULD only be used in a secured environment, where encryption of SIP messa= ges is provided either end-to-end or hop-by-hop. Normally within a 3GPP environment the P-Called-Party-ID is not = sent towards end users but may be exchanged between carriers where other se= curity mechanisms than SIP encryption are used. Sorry coming so late. If this is OK for you I will include it to a new version. Thank you and Best Regards Roland Von: Mary Barnes [mailto:mary.ietf.barnes@gmail.com] Gesendet: Freitag, 27. Dezember 2013 19:45 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 making these changes. I finally had a chance to review this upda= ted 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 "potentia= lly 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 th= e next paragraph that provides details of the impacts. I think you could p= robably 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" tha= t makes this header not of particular concern with regards to security. Doe= s it reveal additional, unique information about an individual that isn't a= vailable 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 reg= istered. This can have privacy implications. To mitigate this problem, th= is extension MUST only be used in a secured environment, where encryption o= f 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 revis= ion. And, I believe you still need to identify privacy/security implicatio= ns 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 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_058CE00BD4D6B94FAD033A2439EA1E4B01DF8E83F451HE113667eme_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Mary,

No= w a new revision is available.

 

Thank you and Best Regards

 

= Roland

 

= Von: Mary Barnes [mailto:mary.ietf.barnes@gmail.com] <= br>Gesendet: Montag, 6. Januar 2014 20:00
An: Jesske, Rolan= d
Cc: DISPATCH; Gonzalo Camarillo; Atle Monrad; Dean Willis
Betreff: Re: PROTO Review: draft-drage-sipping-rfc3455bis-09.txt<= /o:p>

 

Hi Roland,

&nbs= p;

One final editorial nit below. =  If you can spin a revision, then I'll send the PROTO write-up to the = AD.

 

Thanks,

Mary. 

 

On Thu,= Jan 2, 2014 at 3:29 AM, <R.Jesske@telekom.de> wrote:

Hi Mary,

I wish you a happy new year 2014. And the best for the next year.

 

I was looking again on my changes I made due to you= r proposal in December.

I r= ealized that if I change the SHOULD to MUST we have now a backward compatib= ility problem.

We are using= the P-Associated-URI also over the IMS user interface which is not encrypt= ed.

So I propose to add som= e more words.

…

Section 6.1

…

   &n= bsp;     <t>An eaves= dropper could possibly collect the list of identities a user is registered.=  

       This c= an have privacy implications. To mitigate this problem, this extension SHOU= LD

       only = be used in a secured environment, where encryption of SIP messages is

       provided ei= ther end-to-end or hop-by-hop.  </t>

  

   &n= bsp;  <t> Since the P-Associat= ed-URI header field value allows to implicitly register <= /p>

      a bundle of URIs with one REGISTER Mes= sage the impact of security using the P-Associated-URI header field is not = higher than 

      using single REGISTER= messages when registering all identities explicit.</t>

= [MB] I just have some editorial suggestions for the above:

NEW:  

<= span lang=3DEN-US style=3D'color:blue'><t> While the P-Associated-URI header field value al= lows the implicit registration of 

      a bundle of URIs with one R= EGISTER Message the impact of security using the P-Associated-URI header fi= eld is no higher than 

=       using separate REGISTER messages for ea= ch of the URIs. </t>

[/MB]

 

 

 

 

For the P-C= alled-Party-Id the change should be also done like as follows:<= /o:p>

 <= /o:p>

        <t>An eavesdropper could possibly collect the list of identities = a user is registered. 

    &nb= sp;  This can have privacy implications.  To mitigate this p= roblem, this extension SHOULD

   &n= bsp;   only be used in a secured environment, where encrypti= on of SIP messages is

       provi= ded either end-to-end or hop-by-hop.  </t>

 

        &l= t;t&g= t;Normally within a 3GPP environment the P-Called-Party-ID is not se= nt towards end users but may be exchanged between carriers where other secu= rity mechanisms than SIP encryption are used.  </t>

 

Sorry coming so late.

If this is OK for you I will includ= e it to a new version.

 

Thank you and Best = Regards

 <= /o:p>

Roland

 

Von: Mary B= arnes [mailto:mary.ietf.barnes@gmail.com]
Gesendet: Freitag, 27. Dezemb= er 2013 19:45


An= : Jesske, Roland
Cc: DISPATCH; Gonzalo Camarillo; Atle Monrad= ; Dean Willis
Betreff: Re: PROTO Review: draft-drage-sipping-rfc3= 455bis-09.txt

 <= /o:p>

Hi Roland,

 =

Thanks for making these changes. I finally had a chan= ce 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 a= round this unless some more detail is provided on security threats and impa= cts.   I've extracted these few points from previous review comment th= reads.

 

Thanks,

Mary.

<= p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:= auto'> 

----Previous point  -----= ---------------------------->

- Section 6.1: this needs some tighter w=
ording.  What is meant by "potentially annoying"  for e=
xample?  
<=
span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F=
497D'> [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 impac=
ts."
&=
nbsp;
I don't think that adds any value and just beg=
s the question "what are the insignificant impacts and are there any p=
rivacy concerns"?  Really, it's the next paragraph that provides =
details of the impacts.  I think you could probably remove that senten=
ce altogether and not lose anything. <=
br>
 
[/MB]
 
----Previous point ------=
--------------------------->
 
-  Section 6.2: I think =
you need to be more specific about the "nature" that makes this h=
eader not of particular concern with regards to security. Does it reveal ad=
ditional, unique information about an individual that isn't available in ot=
her headers.  Also, the 2nd paragraph needs some work - maybe somethin=
g like:

 
OLD:=

 <=
/o:p>
An eavesdropper may collect t=
he list of identities a user is registered.  This may have privacy imp=
lications.  To mitigate this problem, this extension SHOULD only be us=
ed in a secured environment, where encryption of SIP messages is provided e=
ither end-to-end or

 
hop=
-by-hop. 
<=
span style=3D'font-family:"Arial","sans-serif";color:#500050'>NEW: 
 
An eavesdropper could possibly collect the list of identities=
 a user is registered.  This can have privacy implications.  To m=
itigate this problem, this extension MUST only be used in a secured environ=
ment, where encryption of SIP messages is provided either end-to-end or hop=
-by-hop. 
<=
span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F=
497D'>----End previous point ------------------------------<=

[MB]  The sugge=
sted change for the first sentence didn't get into the revision.  And,=
 I believe you still need to identify privacy/security implications by addr=
essing whether or not this header reveals any unique information about an i=
ndividual that isn't available in other headers.   [/MB]
 
 
 
 

 

 

On Tue, Dec 3, 2013 at 7:00 AM, <R.Jesske@telekom.de> 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 t= he IETF repository.

 

Filename:   draft-drage-sip= ping-rfc3455bis

Revision: &= nbsp; 10

Title:  =           Private Header (P-He= ader) Extensions to the Session Initiation Protocol (SIP) for the 3rd-Gener= ation Partnership Project (3GPP)

Creation date:    2013-12-03

<= p>Group:        =     Individual Submission

Number of pages: 46

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

Status:       &= nbsp;  http://datatracker.= ietf.org/doc/draft-drage-sipping-rfc3455bis

Htmlized:        = http://tools.ietf.org/html/draft-drage-s= ipping-rfc3455bis-10

Diff:&n= bsp;           http://www.ietf.org/rfcdiff?url2=3D= draft-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

   Partners= hip Project (3GPP), along with their applicability, which is

   limited to particular environment= s.  The P-header fields are for a

   variety of purposes within the networks that the part= ners use,

   including= charging and information about the networks a call

   traverses.

 <= o:p>

 

 

<= span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>Von: M= ary Barnes [mailto:mary.ietf.barnes@gmail.com]
Gesendet: Montag, 25. No= vember 2013 23:01


An: Jesske, R= oland
Cc: DISPATCH; Gonzalo Camarillo; Atle Monrad; Dean Willis

Betreff: Re: PROTO Review: draft-drage-sip= ping-rfc3455bis-09.txt

 

Hi Roland,

 

Thanks for your response.  Additional comments bel= ow [MB].

 

Thanks,

Mary.

 

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

Hi Mary,

Thank you for your review.

I have added now your propos= als to the draft.

Other com= ments please see below.

&nb= sp;

I hope now everything i= s OK.

Von: Mary Barnes [mailto:<= a href=3D"mailto:mary.ietf.barnes@gmail.com" target=3D"_blank">mary.ietf.ba= rnes@gmail.com]
Gesendet: Dienstag, 29. Oktober 2013 17:27An: Jesske, Roland
Cc: DISPATCH; Gonzalo Camarillo; Atle= Monrad; Dean Willis
Betreff: PROTO Review: draft-drage-sipping-r= fc3455bis-09.txt

 

In preparation for the PROTO write-up, I have reviewed the do= cument 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 be= en introduced in the -09 and many of my -08 comments remain - I've separate= d comments from nits below.  A number of these comments are with regar= ds 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 IE= SG that will be reviewing this document, so they won't have the same contex= t of the IESG that approved RFC 3455.  I will note that I also have no= t validated the content of section 9 against a diff of this document and RF= C 3455.  I will need to do that before I progress the document unless = the authors can point me to another review that has done that.

 

Regards,

Mary.

 <= /p>

Summary:  This document needs some wor= k prior to being progressed. 

 

Comments:

--------= --------

- Section 1.  I think you sho= uld be explicit that these extensions apply only to a private network - say= ing they are "generally not applicable" is too soft, so I would s= uggest some minor rewording something like:

OLD:

   The SIP extensions specified in this document mak=
e certain
 
   ass=
umptions regarding network topology, linkage between SIP and lower
   layers, and the availability of transitive trust.=
  These assumptions
   are generally NO=
T APPLICABLE in the Internet as a whole. 
 
=

NEW: 

 
   The S=
IP extensions specified in this document make certain
=
   assumptions regarding network topology, linkage between SIP an=
d lower
   layers, and the availability of t=
ransitive 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 b=
e updated.  I don't think that 10 year old background is relevant in t=
he current context.   You should be able to model this after the text =
in more recent 3GPP P-header documents, referring to the SIP change process=
. 
 
[RJ] OK, I have changed the text:<=
/o:p>

The Third Generat= ion Partnership Project (3GPP) has selected SIP as

     the pr= otocol used to establish and tear down multimedia sessions in the

  &nbs= p;  context of its IP Multimedia Subsystem (IMS). For more information= on

&nb= sp;    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 extensio= ns to address those requirements which are needed in for 3GPP Release 11. E= ach 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 tha= t this document is adding any new headers 

 

  &nbs= p; The Third Generation Partnership Project (3GPP) uses SIP as<= /o:p>

     the protocol &= nbsp;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 

  &nbs= p;  required by the 3GPP specification. Note that the requirements for= these extensions

  &n= bsp;  are documented in RFC 4083.   This docum= ent is an update to RFC3455. 

     This document updates existing P-header descriptions 

  =    to address additional requirements which are needed for 3GPP R= elease 11. 

     Eac= h of the P-headers is described in the sections below.

 

[/MB] <= /o:p>

 

- Section 4.1. "registered address-of-record" -> &=
quot;registered SIP address-of-record"
- Section 4.1, 3rd paragraph.  "Note that, generally speaking,&=
quot; -> "Note that in standard SIP usage [RFC3261]"
- Section 4.1.2.3.  I don't think this is stat=
ed properly.  I think the intent is that this header is not applicable=
 to proxies, therefore the proxy MUST relay the header field unchanged. &nb=
sp;I would suggest rewording something like:
OLD: 
&n=
bsp;  This memo does not define any procedure at the proxy.  The =
proxy does
   not add, read, modify or delet=
e the header field, and therefore any
   pro=
xy will relay this header field unchanged.
 
NEW:
 
   This header is not inte=
nded 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.
 
 
 
Sectio=
n 4.2, 1st paragraph.  The behavior in this sentence is not normative =
from a SIP protocol perspective, thus MAY is not appropriate.  I sugge=
st the MAY be changed to "can".   
   Th=
e UAS MAY use the information to render different distinctive audiovisual a=
lerting
   tones, depending on the URI used =
to receive the invitation to the
   session.=

Section 4.2.2.2, 2nd paragraph. &n=
bsp;The behavior in this sentence is not normative from a SIP protocol pers=
pective, thus  I suggest the MAY be changed to "can". <=
/span>
 
- Section 4.3.=
3, last paragraph.  I think this ought to be a MUST: "The identif=
ier should be globally unique.." 
&nb=
sp;
- Section 4.3.2.1.  This text has change=
d from the -08.   I don't know what a "normal User Equipment"=
; is and the term "User Equipment" is not defined in this specifi=
cation.  I think it would be better to say something like. However, ev=
en with this proposed change, I think you also need text for user agent ser=
ver behavior - i.e., what would a UAS do if it received this header. <=
/span>
 
OLD:
&nbs=
p;  A normal User Equipment has normally no knowledge of the P-Visited=
-
   Network-ID when sending the REGISTER.&n=
bsp; Therefore user agent clients
   do not =
insert a P-Visited-Network-ID header field in any SIP message.
 
 <=
o:p>
NEW:&=
nbsp;
 &nbs=
p; 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-Networ=
k-ID when sending the REGISTER request.  Therefore user agent clients =
MUST NOT insert a P-Visited-Network-ID header field in any SIP me=
ssage.
 
- Section 4.3.2.2:, 2nd paragraph:  =
;"home network MAY use" -> "home network can use"

 
 
 
- Sect=
ion 4.3.2.2, last paragraph:  
 
 =

OLD:=
 Note that a received P-Visited-Network-ID from a UA is a failure ca=
se and must be deleted.
 
NEW:  Note that a received P-Visited-Ne=
twork-ID from a UA is a failure case and MUST be deleted when the request i=
s forwarded. 
 
Section 4.4.2.1, 2nd paragraph:  "MUS=
T trust the proxy" -> "MUST have a trust relationship with the=
 proxy" 
 
Section 4.4.2.1, 3rd paragraph: &nb=
sp;"there must also be a transitive trust" ->  "ther=
e MUST also be a transitive trust" 
Section 4.4.2.2, 2nd paragraph: "MAY act upon any in=
formation present" -> "can act upon any information present&qu=
ot;,  "MAY use the call id" -> "can use the call id" 
Section 4.5.2: 2nd paragraph: "MAY use =
the hostnames" -> "can use the hostnames" 
 
 
 
Section 4.5.2.1 2nd paragraph: "MAY u=
se the contents" -> "can use the contents" 
 <=
o:p>
- Sec=
tion 4.6.2, 3rd paragraph: "MAY use the values" -> "can u=
se the values" 
- Section 4=
.6.3, 3rd paragraph: needs some editorial work.  Maybe the following c=
hange would work: 
 
 
OLD:
   Depending on t=
he call scenario it is needed to add for each transit
=
   network either a transit network name or a void value.  N=
evertheless
   it can not be guaranteed that=
 all values will appear within the P-Charging-Vector header field. 
 
 
NEW: 
=
 
   Depending on the call scenario, each transit network can =
add either a transit network name or a void    value.&n=
bsp; However, it can not be guaranteed that all the values that are added w=
ill appear within the P-Charging-Vector header field.
=
 
- Section 4.6.3, next to las=
t paragraph: "which needs to be incremented" -> "whi=
ch MUST be incremented"
 <=
/pre>
- Section 4.6.3, last p=
aragraph.  I have no idea what that is trying to say other than void v=
alues have no index.  What does "taken into consideration" m=
ean. Are you talking about limits on the number of entries or are you sugge=
sting that the number of void values must be considered when setting the in=
dex for the transit network names?  
 
[RJ] Yes! Ch=
anged the text to:
 
A =
void value has no index. By adding the next value the index has to be incre=
mented by the number of void entries +1.
<=
span lang=3DEN-US style=3D'font-size:11.0pt;font-family:"Calibri","sans-ser=
if";color:#1F497D'> 
- Section 4.6.4.2: I don't know what this means: =
 "A=
 deletion of the elements 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?&n=
bsp;
 
[RJ] Yes, I have changed the text:

Procedures describe= d within 4.6.2.2 apply. A transit-ioi MAY be

      =      added or modified by a proxy. A deletion of the tr= ansit-ioi or a entry within the tranist-ioi could

     &n= bsp;     appear depending on the network policy and tru= st rules. This is

  =
;         also valid by replacing t=
he transit-ioi with a void value.
 
 
=
 
 
- Section 5.7. Delete this text and table.   We aren't the=
se tables anymore as they really don't provide any useful information. &nbs=
p;You just need to verbally state what messages these headers can appear in=
. 
 
[RJ] OK
 
So I changed 5.7 to “New heade=
r”

The P-Associated-URI can appear in SIP REGIST= ER method and 2xx resonses, P-Called-Party-ID can appear in SIP INVITE, OPT= IONS, PUBLISH,SUBSCRIBE, MESSAGE methods and all responses, P-Visited-Netwo= rk-ID can appear in all SIP methods except ACK, BYE and CANCEL and all resp= onses, P-Access-Network-Info can appear in all SIP methods exept ACK and CA= NCEL, P-Charging-Vector  can appear in all SIP methods exept CANCEL an= d 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 senten= ces - i.e., rather than use comma separators, use a period.  You shoul= d also spell out that these are header fields - i.e., "The P-Associate= d-URI header field can appear....2xx responses.   The P-Called-Party-I= D header field....

 
 
- Section 6.1: thi=
s needs some tighter wording.  What is meant by "potentially anno=
ying"  for example?  
&nb=
sp;
[RJ] I do not kno=
w. This is original text. So I deleted the words.
 
- Sectio=
n 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 -=
 maybe something like:
 
<= pre style=3D'word-wrap:break-word'>OLD:
An eavesdropper may collect the list of identities a use=
r is registered.  This may have privacy implications.  To mitigat=
e 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 re=
gistered.  This can have privacy implications.  To mitigate this =
problem, this extension MUST only be used in a secured environment, where e=
ncryption 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 ea= vesdropper could possibly collect the list of identities a user has registe= red."

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

[/MB]  

<= /div>
- Section 6.4, 
--3rd pa=
ragraph: "should not" -> "MUST NOT" 
 
-- 7th paragraph:  =
"SHOULD NOT be sent" -> "MUST NOT be sent" 
 
 
 
 
-- 8th p=
aragraph: "SHOULD NOT send sensitive information" -> "MUS=
T NOT send sensitive information"
 
 
<=
pre>-- 9th paragraph: &quo=
t;is required to delete" -> "is REQUIRED to delete" =

 
-- 10th parag=
raph:  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 think the rest is sufficien=
t 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?  
<= /div>
[RJ] Yes I did some changes as follows.
 
     =    <t>A proxy receiving a message containing the P-Access-N= etwork-Info

       header field from a non-trusted e= ntity is not able to guarantee the

       validity of the contents. Thus t=
his content SHOULD be deleted based on local policy.</t><=
/o:p>
 
- Section 9, item 2.  I think you need to add this text with rega=
rds to the recommendation to use RFC 4244 (bis) to the body of this documen=
t and include a real reference.
 
[RJ] OK done. I let the reference RFC4244 since 3GPP uses currently only R=
FC4244. 
Replaced following=
 text:
With section 9.2
     =
  <t>Requirements for a more general solution are proposed in &l=
t;xref
   &n=
bsp;     target=3D"RFC4244"></xref>.=
 3GPP will continue to use the
         P-Called-Party-ID head=
er field even though RFC 4244 <xref
         target=3D"=
;RFC4244"></xref> has now been published.</t>
 
<=
span lang=3DEN-US style=3D'font-size:11.0pt;font-family:"Calibri","sans-ser=
if";color:#1F497D'>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"=

- Sect=
ion 4.1.2.2, 2nd paragraph, "In case" -> "If",  =
;"shall not" -> SHALL NOT
- Section 4.3.2.2, last sentence.  The -09 introduce=
d a typo: "T means" -> "This means" 
 
- S=
ection 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 tra=
nsitive trust" 
 
Section 4.6, 2nd paragraph: =
"includes, includes but is not limited to" -> "includes, =
but is not limited to," 
 <=
/o:p>
Section 4.6.2.2, 1s=
t paragraph: "one ore more" -> "one or more" 
 
 
 

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

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

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

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

Thank= you and Best Regards

Roland


-----Urspr=FCngliche Nachric= ht-----
Von: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
Gesendet: Diens= tag, 8. Oktober 2013 13:40
An: Christer Holmberg; Keith Drage; Jesske, R= oland
Betreff: New Version Notification for draft-drage-sipping-rfc3455b= is-09.txt


A new version of I-D, draft-drage-sipping-rfc3455bis-0= 9.txt
has been successfully submitted by Keith Drage and posted to the I= ETF repository.

Filename:        draft-drage-sip= ping-rfc3455bis
Revision:        09
Title:  =         Private Header (P-Header) Extensions to the Se= ssion Initiation Protocol (SIP) for the 3rd-Generation Partnership Project = (3GPP)
Creation date:   2013-10-08
Group:       &= nbsp;   Individual Submission
Number of pages: 47
URL:   &n= bsp;         http://www.ie= tf.org/internet-drafts/draft-drage-sipping-rfc3455bis-09.txt
Status:=          http://datatracker.iet= f.org/doc/draft-drage-sipping-rfc3455bis
Htmlized:     &nb= sp;  http://tools.ietf.org/html/draft-drage-sipping-rf= c3455bis-09
Diff:            http://www.ietf.org/rfcdiff?url2=3Ddraft-drage-sipping-rfc= 3455bis-09

Abstract:
   This document describes a s= et of private Session Initiation Protocol
   (SIP) header fiel= ds (P-headers) used by the 3rd-Generation
   Partnership Proje= ct (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,
&nb= sp;  including charging and information about the networks a call
&= nbsp;  traverses.




Please note that it may take a co= uple of minutes from the time of submission until the htmlized version and = diff are available at t= ools.ietf.org.

The IETF Secretariat

&= nbsp; -

&= nbsp;

 =

 

= --_000_058CE00BD4D6B94FAD033A2439EA1E4B01DF8E83F451HE113667eme_-- From oej@edvina.net Tue Jan 7 03:13:08 2014 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 CA5391AD9B8 for ; Tue, 7 Jan 2014 03:13:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 GN8frOWUnaP7 for ; Tue, 7 Jan 2014 03:13:06 -0800 (PST) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 837651ADEB1 for ; Tue, 7 Jan 2014 03:13:04 -0800 (PST) Received: from [192.168.0.100] (2.71.213.8.mobile.tre.se [2.71.213.8]) by smtp7.webway.se (Postfix) with ESMTPA id 75AF893C2A1; Tue, 7 Jan 2014 11:12:54 +0000 (UTC) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: "Olle E. Johansson" In-Reply-To: <52C83591.3080702@alum.mit.edu> Date: Tue, 7 Jan 2014 12:12:48 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140102101042.27427.64547.idtracker@ietfa.amsl.com> <0BA14051-5C7F-4416-8CD2-413347D540D3@edvina.net> <52C83591.3080702@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1827) Cc: "dispatch@ietf.org list" Subject: Re: [dispatch] New Version Notification for draft-johansson-dispatch-dane-sip-00.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, 07 Jan 2014 11:13:09 -0000 On 04 Jan 2014, at 17:23, Paul Kyzivat wrote: > On 1/2/14 5:16 AM, Olle E. Johansson wrote: >> Hi! >> I have renamed my draft and resubmitted it again. Adding DNSsec/DANE = support to SIP is not a bad idea in my point of view. >=20 > It seems like a really good idea to me. >=20 > I have a question about backward compatibility, as discussed in = section 9: >=20 > You say that that servers can use certificates that support both DANE = and 5922 style validation. And IIUC that will be necessary in order to = handle clients that don't support DANE validation. Yes. >=20 > But the Intro explains that one of the important reasons for = introducing DANE authentication is because of various logistic problems = providing certificates for 5922 style validation. Providing backward = compatibility negates that advantage. Well, I might need to clarify that. The current way to host multiple SIP = domains is either to have one certificate with a long list of subject = Alt Names or multiple IPs each with it's own certificate with the domain = in SubjAltName. Both are very hard to maintain. Either buy a new cert = for a new domain - and a new IP. Or reissue the existing cert to get an = additional name. SNI could also be used, but is not yet wildely supported out there. It = just means one cert per domain. I don't remember if we've specified how = SNI applies to RFC 5922 - what are we specifying in the SNI lookup? >=20 > Have you considered the migration path? Presumably those currently = using 5922 already have a certificate that works for that. Will they be = able to get a cert that continues that and also supports DANE = validation? Yes, they just need to get the host name into the CN. 5922-compliant = clients ignore the CN when there are SubjectAltNames and clients = supporting this draft will ignore the SubjectAltNames. >=20 > What about those coming to this without any history of 5922 support? Those will look for something in some field that's very unspecified. = Hard to support. I guess that they will look for something to match in = the CN. What that is varies - which is why we need standardization :-) Wild guess is that they look for the domain in the CN. They will not = accept certificates according to this RFC. Again SNI could help. >=20 > ISTM that there is need to get ubiquitous client support for this = deployed. For that we have the usual chicken/egg scenario. Always that chicken and the %&=80&=80& egg. ;-) Thank you for your feedback, Paul! /O >=20 > Thanks, > Paul >=20 >> If the view gets larger we might want to focus a bit more on security = aspects of SIP in the RAI area. There are many issues to look at. Why = isn't S/MIME deployed, how do we get more TLS - if that's what we want? = Can we improve upon MD5 digest authentication? Do we want to fix SIP = identity that many claim is broken? Is it possible to set up sessions = with end2end security? >>=20 >> Happy New Year! >>=20 >> /O >>=20 >>=20 >>=20 >> Begin forwarded message: >>>=20 >>> A new version of I-D, draft-johansson-dispatch-dane-sip-00.txt >>> has been successfully submitted by Olle E. Johansson and posted to = the >>> IETF repository. >>>=20 >>> Name: draft-johansson-dispatch-dane-sip >>> Revision: 00 >>> Title: TLS sessions in SIP using DNS-based = Authentication of Named Entities (DANE) TLSA records >>> Document date: 2014-01-02 >>> Group: Individual Submission >>> Pages: 9 >>> URL: = http://www.ietf.org/internet-drafts/draft-johansson-dispatch-dane-sip-00.t= xt >>> Status: = https://datatracker.ietf.org/doc/draft-johansson-dispatch-dane-sip/ >>> Htmlized: = http://tools.ietf.org/html/draft-johansson-dispatch-dane-sip-00 >>>=20 >>>=20 >>> Abstract: >>> Use of TLS in the SIP protocol is defined in multiple documents, >>> starting with RFC 3261. The actual verification that happens when >>> setting up a SIP TLS connection to a SIP server based on a SIP URI = is >>> described in detail in RFC 5922 - SIP Domain Certificates. >>>=20 >>> In this document, an alternative method is defined, using = DNS-Based >>> Authentication of Named Entities (DANE). By looking up TLSA DNS >>> records and using DNSsec protection of the required queries, >>> including lookups for NAPTR and SRV records, a SIP Client can = verify >>> the identity of the TLS SIP server in a different way, matching on >>> the SRV host name in the X.509 PKIX certificate instead of the SIP >>> domain. This provides more scalability in hosting solutions and = make >>> it easier to use standard CA certificates (if needed at all). >>>=20 >>> This document updates RFC 5922. >>>=20 >>>=20 >>=20 >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >>=20 >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From ibc@aliax.net Tue Jan 7 08:13:00 2014 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 2CCA21AE037 for ; Tue, 7 Jan 2014 08:13:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] 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 r-v6N8uLTz3q for ; Tue, 7 Jan 2014 08:12:58 -0800 (PST) Received: from mail-qa0-f54.google.com (mail-qa0-f54.google.com [209.85.216.54]) by ietfa.amsl.com (Postfix) with ESMTP id 8D2D31AE024 for ; Tue, 7 Jan 2014 08:12:58 -0800 (PST) Received: by mail-qa0-f54.google.com with SMTP id j7so712397qaq.41 for ; Tue, 07 Jan 2014 08:12:49 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=F/MPQrctVaa6FRqQrvCLere1g1ZpsAyMw0H+/6pnMjA=; b=KNXebqwejghe09jM1kmqyOyZWX43GqhOU+GtXYxmBuVx4jtoaGQk6z6VNHOhntcIvu JcP3a0EzPnaAluzAE20afD0UlTd9lAgXz4unuyBqbvCq/CIk0983omk3+Zi3VmsncsSg yylt/hCN2RwQeMowvndwclzC52wayUuuTtWNSUIfi295eZCcFwCW2j5TiVaiFEOGm/ZU p8kMyGBY/fD9gFZ2mCdgI6MrZBkn7SCNzQu7I7ASIMpR7bUCxTgkbyVeWhU2Y9pxKTWf GkNhyMUMCivHImg2rL3gaKxwOFUq0ZF6XBd+2BQv8GAu3VMnbRv3K4z76rc0RWPW/USY SjTQ== X-Gm-Message-State: ALoCoQkCznjh+THpLm34BRqDTU67EtKAoNMAxFW3cAvdVO7vhkyzYvXj9NHtTn56AvggxFqN3y7j MIME-Version: 1.0 X-Received: by 10.224.20.202 with SMTP id g10mr188837837qab.66.1389111169468; Tue, 07 Jan 2014 08:12:49 -0800 (PST) Received: by 10.96.82.97 with HTTP; Tue, 7 Jan 2014 08:12:49 -0800 (PST) Received: by 10.96.82.97 with HTTP; Tue, 7 Jan 2014 08:12:49 -0800 (PST) In-Reply-To: References: <20140102101042.27427.64547.idtracker@ietfa.amsl.com> <0BA14051-5C7F-4416-8CD2-413347D540D3@edvina.net> <52C83591.3080702@alum.mit.edu> Date: Tue, 7 Jan 2014 17:12:49 +0100 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Olle E Johansson Content-Type: multipart/alternative; boundary=001a11c2c83ccf69d404ef63a5e5 Cc: dispatch@ietf.org Subject: Re: [dispatch] New Version Notification for draft-johansson-dispatch-dane-sip-00.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, 07 Jan 2014 16:13:00 -0000 --001a11c2c83ccf69d404ef63a5e5 Content-Type: text/plain; charset=UTF-8 > SNI could also be used, but is not yet wildely supported out there. It just means one cert per domain. I don't remember if we've specified how SNI applies to RFC 5922 - what are we specifying in the SNI lookup? SNI is implemented in MOST of the browsers and HTTPS servers (tested). How is possible that it cannot be a feasible solution for SIP? As you said, multiple SubjectAltNames in the same certificate is really hard to maintain and it is proven to be an unfeasible solution for HTTP world (regardless most of the browsers do support it). About applying SNI and RFC 5922, SNI takes place before the certificate validation rules. I see no issues at all with it. Note: I am 100% pro DANE and any kind of validation that does not depend on buying expensive certificates. Having to pay to some "Internet authority" in order to get sechrityyand encryption is just terrible. Regards. --001a11c2c83ccf69d404ef63a5e5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

> SNI could also be used, but is not yet wildely supporte= d out there. It just means one cert per domain. I don't remember if we&= #39;ve specified how SNI applies to RFC 5922 - what are we specifying in th= e SNI lookup?

SNI is implemented in MOST of the browsers and HTTPS servers= (tested). How is possible that it cannot be a feasible solution for SIP? A= s you said, multiple SubjectAltNames in the same certificate is really hard= to maintain and it is proven to be an unfeasible solution for HTTP world (= regardless most of the browsers do support it).

About applying SNI and RFC 5922, SNI takes place before the = certificate validation rules. I see no issues at all with it.

Note: I am 100% pro DANE and any kind of validation that doe= s not depend on buying expensive certificates. Having to pay to some "= Internet authority" in order to get sechrityyand encryption is just te= rrible.

Regards.

--001a11c2c83ccf69d404ef63a5e5-- From ibc@aliax.net Tue Jan 7 08:17:28 2014 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 3FC971AE047 for ; Tue, 7 Jan 2014 08:17:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] 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 CKZYlktk3kv9 for ; Tue, 7 Jan 2014 08:17:27 -0800 (PST) Received: from mail-qa0-f46.google.com (mail-qa0-f46.google.com [209.85.216.46]) by ietfa.amsl.com (Postfix) with ESMTP id 364001AE02E for ; Tue, 7 Jan 2014 08:17:27 -0800 (PST) Received: by mail-qa0-f46.google.com with SMTP id j5so693386qaq.5 for ; Tue, 07 Jan 2014 08:17:18 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=+W5z1rRW1uc49dol25Q3ObF01LTGsSM07VayiLor/+c=; b=gByklzoVwjEFwfNJ/mB9iQ9M71i9Crrpv5as3f+j5TbAiGCFRY6XlQaPehPg5u8bkC LbiSHmHxPDCRtJIp9dwcNN0dNB9tZNUBnOF/qbjdeFUQMXE0EF8CUuQlXLALsPXdWtm1 pNAZnDmBNeLICTCm4Yf3Ku1MbTOJQB5p33UvnZ7JhJtzPfh20eLg2qIG41Z+j7AsHdDv pDpWdX/nIE4gVDGWeaWGf9Uq96DTQhSHaYfQ2fTK5f03b/S4q0SXjZJAZU7hY4UJe8ee TJ8lLPF0UZ4hy3H1DW3s9RGolKhQp8Qjh3YybQge7+Mq4VOEG6q4m/wF+Q6RFjq/Ms8d OJRw== X-Gm-Message-State: ALoCoQm6KG/HPUpqEVhfvFvTIa/WcxAdIe+PTJeufWf4jiIv9UYJXXEvVVlhZUGdORUOf/ZOqzHc MIME-Version: 1.0 X-Received: by 10.224.68.70 with SMTP id u6mr47075475qai.5.1389111438235; Tue, 07 Jan 2014 08:17:18 -0800 (PST) Received: by 10.96.82.97 with HTTP; Tue, 7 Jan 2014 08:17:18 -0800 (PST) Received: by 10.96.82.97 with HTTP; Tue, 7 Jan 2014 08:17:18 -0800 (PST) In-Reply-To: References: <20140102101042.27427.64547.idtracker@ietfa.amsl.com> <0BA14051-5C7F-4416-8CD2-413347D540D3@edvina.net> <52C83591.3080702@alum.mit.edu> Date: Tue, 7 Jan 2014 17:17:18 +0100 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Olle E Johansson Content-Type: multipart/alternative; boundary=001a11c2f58ed47b0604ef63b54d Cc: dispatch@ietf.org Subject: Re: [dispatch] New Version Notification for draft-johansson-dispatch-dane-sip-00.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, 07 Jan 2014 16:17:28 -0000 --001a11c2f58ed47b0604ef63b54d Content-Type: text/plain; charset=UTF-8 > Those will look for something in some field that's very unspecified. Hard to support. I guess that they will look for something to match in the CN. This is not true. SNI does not mean "ignoring SubjectAltNames". SNI just means that the client indicates the desired hostname during the TLS handshake, the server offers a proper certificate for such a hostname, and the client then validates the server certificate following the protocol rules (in case of SIP it means rules in RFC 5922). --001a11c2f58ed47b0604ef63b54d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


> Those will look for something in some field that's very unspecifie= d. Hard to support. I guess that they will look for something to match in t= he CN.

This is not true. SNI does not mean "ignoring SubjectAl= tNames". SNI just means that the client indicates the desired hostname= during the TLS handshake, the server offers a proper certificate for such = a hostname, and the client then validates the server certificate following = the protocol rules (in case of SIP it means rules in RFC 5922).

--001a11c2f58ed47b0604ef63b54d-- From pkyzivat@alum.mit.edu Tue Jan 7 09:17:40 2014 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 117A31AE066 for ; Tue, 7 Jan 2014 09:17:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] 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 T7W24c4yNWKX for ; Tue, 7 Jan 2014 09:17:38 -0800 (PST) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:16]) by ietfa.amsl.com (Postfix) with ESMTP id 270FD1AE04F for ; Tue, 7 Jan 2014 09:17:38 -0800 (PST) Received: from omta11.westchester.pa.mail.comcast.net ([76.96.62.36]) by qmta01.westchester.pa.mail.comcast.net with comcast id B3Rd1n0020mv7h0515HVWR; Tue, 07 Jan 2014 17:17:29 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta11.westchester.pa.mail.comcast.net with comcast id B5HT1n00k3ZTu2S3X5HTWT; Tue, 07 Jan 2014 17:17:29 +0000 Message-ID: <52CC36A7.1070500@alum.mit.edu> Date: Tue, 07 Jan 2014 12:17:27 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "Olle E. Johansson" References: <20140102101042.27427.64547.idtracker@ietfa.amsl.com> <0BA14051-5C7F-4416-8CD2-413347D540D3@edvina.net> <52C83591.3080702@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1389115049; bh=fqZqNQOFxhhfU7W0MWuYchEjSM8qeEcflJoKyQ0IGw4=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=kY3Q2rYkN2GWSXIXPfaswk1eIWw1Vi4sYEHzMf/BOlaLC1s5W+abTbF9bLwiw9+PE 5ZjNZ1kqLzwK1lOy6QmwB9nTbuPvvME3ik9uNV8HPyVcOIzTJBmgLTj3TYGWgepmrv JRvUE6vSjamvrHitywl00/yRGqUAChUhf2EaZ6d3jFLgagnZbiw3uRUiKELXisR1KJ GDpQkubn+LXjVbzdSeakH+oLHPR0Ac2BtcD2+LeWmFZM/HAnAIHOHd0SGSNqiBvnh9 RPxlWfm0W0Qxbwu23P37PVEyrGHnutd4Wmf0+OT+k3gVBPz036v/Gam1xPGR/1ji4K qteFlT7EDnmVQ== Cc: "dispatch@ietf.org list" Subject: Re: [dispatch] New Version Notification for draft-johansson-dispatch-dane-sip-00.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, 07 Jan 2014 17:17:40 -0000 Olle, Thanks for clarification. I think it would be helpful if you would add a section on deployment hints and issues. Then you could talk about various cases: - updating a server that already supports TLS via 5922 - updating a client that already supports TLS via 5922 - recommendations for a server newly supporting TLS - recommendations for a client newly supporting TLS - ... Another question that came to me is what to do about TLS client authentication? Thanks, Paul On 1/7/14 6:12 AM, Olle E. Johansson wrote: > > On 04 Jan 2014, at 17:23, Paul Kyzivat wrote: > >> On 1/2/14 5:16 AM, Olle E. Johansson wrote: >>> Hi! >>> I have renamed my draft and resubmitted it again. Adding DNSsec/DANE support to SIP is not a bad idea in my point of view. >> >> It seems like a really good idea to me. >> >> I have a question about backward compatibility, as discussed in section 9: >> >> You say that that servers can use certificates that support both DANE and 5922 style validation. And IIUC that will be necessary in order to handle clients that don't support DANE validation. > Yes. >> >> But the Intro explains that one of the important reasons for introducing DANE authentication is because of various logistic problems providing certificates for 5922 style validation. Providing backward compatibility negates that advantage. > Well, I might need to clarify that. The current way to host multiple SIP domains is either to have one certificate with a long list of subject Alt Names or multiple IPs each with it's own certificate with the domain in SubjAltName. Both are very hard to maintain. Either buy a new cert for a new domain - and a new IP. Or reissue the existing cert to get an additional name. > SNI could also be used, but is not yet wildely supported out there. It just means one cert per domain. I don't remember if we've specified how SNI applies to RFC 5922 - what are we specifying in the SNI lookup? > > >> >> Have you considered the migration path? Presumably those currently using 5922 already have a certificate that works for that. Will they be able to get a cert that continues that and also supports DANE validation? > Yes, they just need to get the host name into the CN. 5922-compliant clients ignore the CN when there are SubjectAltNames and clients supporting this draft will ignore the SubjectAltNames. > >> >> What about those coming to this without any history of 5922 support? > Those will look for something in some field that's very unspecified. Hard to support. I guess that they will look for something to match in the CN. What that is varies - which is why we need standardization :-) > > Wild guess is that they look for the domain in the CN. They will not accept certificates according to this RFC. > Again SNI could help. > >> >> ISTM that there is need to get ubiquitous client support for this deployed. For that we have the usual chicken/egg scenario. > Always that chicken and the %&€&€& egg. ;-) > > Thank you for your feedback, Paul! > > /O >> >> Thanks, >> Paul >> >>> If the view gets larger we might want to focus a bit more on security aspects of SIP in the RAI area. There are many issues to look at. Why isn't S/MIME deployed, how do we get more TLS - if that's what we want? Can we improve upon MD5 digest authentication? Do we want to fix SIP identity that many claim is broken? Is it possible to set up sessions with end2end security? >>> >>> Happy New Year! >>> >>> /O >>> >>> >>> >>> Begin forwarded message: >>>> >>>> A new version of I-D, draft-johansson-dispatch-dane-sip-00.txt >>>> has been successfully submitted by Olle E. Johansson and posted to the >>>> IETF repository. >>>> >>>> Name: draft-johansson-dispatch-dane-sip >>>> Revision: 00 >>>> Title: TLS sessions in SIP using DNS-based Authentication of Named Entities (DANE) TLSA records >>>> Document date: 2014-01-02 >>>> Group: Individual Submission >>>> Pages: 9 >>>> URL: http://www.ietf.org/internet-drafts/draft-johansson-dispatch-dane-sip-00.txt >>>> Status: https://datatracker.ietf.org/doc/draft-johansson-dispatch-dane-sip/ >>>> Htmlized: http://tools.ietf.org/html/draft-johansson-dispatch-dane-sip-00 >>>> >>>> >>>> Abstract: >>>> Use of TLS in the SIP protocol is defined in multiple documents, >>>> starting with RFC 3261. The actual verification that happens when >>>> setting up a SIP TLS connection to a SIP server based on a SIP URI is >>>> described in detail in RFC 5922 - SIP Domain Certificates. >>>> >>>> In this document, an alternative method is defined, using DNS-Based >>>> Authentication of Named Entities (DANE). By looking up TLSA DNS >>>> records and using DNSsec protection of the required queries, >>>> including lookups for NAPTR and SRV records, a SIP Client can verify >>>> the identity of the TLS SIP server in a different way, matching on >>>> the SRV host name in the X.509 PKIX certificate instead of the SIP >>>> domain. This provides more scalability in hosting solutions and make >>>> it easier to use standard CA certificates (if needed at all). >>>> >>>> This document updates RFC 5922. >>>> >>>> >>> >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >>> >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch > > From mary.ietf.barnes@gmail.com Tue Jan 7 09:54:50 2014 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 AAB621AE078 for ; Tue, 7 Jan 2014 09:54:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.698 X-Spam-Level: X-Spam-Status: No, score=-1.698 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, 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 iHLzs2xdbs0L for ; Tue, 7 Jan 2014 09:54:44 -0800 (PST) Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 6FF9C1AE077 for ; Tue, 7 Jan 2014 09:54:43 -0800 (PST) Received: by mail-we0-f182.google.com with SMTP id q59so473211wes.27 for ; Tue, 07 Jan 2014 09:54:34 -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=+XLaQjAF/2sqQSUner9UoIERPdNdDKfQrNcwhgkC9vU=; b=ZxvRuru2dbZdqcmOUjg+sPcGWv0ig0lidgc4QXKctsiBC+ARML9MxOnKR6lsPCkLrS zbapUxqreCECsKiw5w/G2LMspgS5d6aw12Q0qNF2Jr7uRwjw2rRh9ccoxc5Ii9QLtgA3 ecxA5DnPhjEOMoP4Nk/m3dy/y5fSZq6IW+SZhzQkhUPfuqFlE4YyY/OmPRmFOKg4QB5k 8EQPt9Dc58pO3X08kztuKN+WGgErmnJmWnlcz2JWEkHtYg9aEPU+p3O3gDqwKTR2LzBK Thrg5IVEeCnin3sWyBKc1/jFS2oqm/E5MVaUpnIb0SkznDTJ+eZhJQvg/BzVEhbB7B/b /krw== MIME-Version: 1.0 X-Received: by 10.194.170.133 with SMTP id am5mr52623934wjc.42.1389117273942; Tue, 07 Jan 2014 09:54:33 -0800 (PST) Received: by 10.216.172.9 with HTTP; Tue, 7 Jan 2014 09:54:33 -0800 (PST) In-Reply-To: <058CE00BD4D6B94FAD033A2439EA1E4B01DF8E83F451@HE113667.emea1.cds.t-internal.com> References: <058CE00BD4D6B94FAD033A2439EA1E4B01DEBB69CC8A@HE113667.emea1.cds.t-internal.com> <058CE00BD4D6B94FAD033A2439EA1E4B01DF27DB8A63@HE113667.emea1.cds.t-internal.com> <058CE00BD4D6B94FAD033A2439EA1E4B01DF8E83EB24@HE113667.emea1.cds.t-internal.com> <058CE00BD4D6B94FAD033A2439EA1E4B01DF8E83F451@HE113667.emea1.cds.t-internal.com> Date: Tue, 7 Jan 2014 11:54:33 -0600 Message-ID: From: Mary Barnes To: "R.Jesske@telekom.de" Content-Type: multipart/alternative; boundary=089e0122e92eaa2ead04ef651171 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: Tue, 07 Jan 2014 17:54:50 -0000 --089e0122e92eaa2ead04ef651171 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Thanks Roland. I have reviewed that version and all the changes I suggested have been made. However, in doing the PROTO write-up I realized that I wasn't certain anyone had reviewed the ABNF. So, I ran the ABNF through Bill Fenner's tool: http://tools.ietf.org/tools/bap/abnf.cgi And, there are a couple things that need to be fixed: 1) DOT needs to change to "." (we had this same bug in RFC 4244): transit-ioi-indexed-value =3D transit-ioi-name DOT transit-ioi-index 2) There's an extra space here (between * and parenthesis): transit-ioi-name =3D ALPHA * (ALPHA / DIGIT) NEw: transit-ioi-name =3D ALPHA *(ALPHA / DIGIT) There are also a number of long lines in the ABNF that should be fixed. In addition, IDNITS identifies other errors and warnings per the following. Those should also be addressed including considering whether obsolete references need changing: idnits 2.13.01 tmp/draft-drage-sipping-rfc3455bis-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see http://trustee.ietf.org/license-info): -------------------------------------------------------------------------= --- No issues found here. Checking nits according to http://www.ietf.org/id-info/1id-guidelines.txt= : -------------------------------------------------------------------------= --- No issues found here. Checking nits according to http://www.ietf.org/id-info/checklist : -------------------------------------------------------------------------= --- ** There are 9 instances of too long lines in the document, the longest o= ne being 20 characters in excess of 72. =3D=3D There are 4 instances of lines with non-RFC2606-compliant FQDNs in= the document. =3D=3D There are 4 instances of lines with non-RFC5735-compliant IPv4 add= resses in the document. If these are example addresses, they should be chang= ed. Miscellaneous warnings: -------------------------------------------------------------------------= --- =3D=3D The document seems to contain a disclaimer for pre-RFC5378 work, b= ut was first submitted on or after 10 November 2008. The disclaimer is usual= ly necessary only for documents that revise or obsolete older RFCs, and t= hat take significant amounts of text from those RFCs. If you can contact = all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at http://trustee.ietf.org/license-info for more information.) Checking references for intended status: Informational -------------------------------------------------------------------------= --- =3D=3D Missing Reference: 'RFC XXXX' is mentioned on line 1667, but not d= efined -- Looks like a reference, but probably isn't: '3' on line 1948 =3D=3D Unused Reference: 'RFC2976' is defined on line 2065, but no explic= it reference was found in the text =3D=3D Unused Reference: 'RFC3262' is defined on line 2068, but no explic= it reference was found in the text =3D=3D Unused Reference: 'RFC3311' is defined on line 2075, but no explic= it reference was found in the text =3D=3D Unused Reference: 'RFC3428' is defined on line 2081, but no explic= it reference was found in the text =3D=3D Unused Reference: 'RFC3903' is defined on line 2093, but no explic= it reference was found in the text ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) -- Obsolete informational reference (is this intentional?): RFC 2976 (Obsoleted by RFC 6086) -- Obsolete informational reference (is this intentional?): RFC 3265 (Obsoleted by RFC 6665) Summary: 2 errors (**), 0 flaws (~~), 9 warnings (=3D=3D), 3 comments = (--). Run idnits with the --verbose option for more detailed information abo= ut the items above. While I apologize for not catching these issues earlier, it really is the responsibility of authors to check idnits (beyond what the submission tool requires) for their documents. I routinely run idnits before I submit a document as it can also save time when fixing the nits that the submission tool catches: https://tools.ietf.org/tools/idnits/ Regards, Mary. On Tue, Jan 7, 2014 at 12:35 AM, wrote: > Hi Mary, > > Now a new revision is available. > > > > Thank you and Best Regards > > > > Roland > > > > *Von:* Mary Barnes [mailto:mary.ietf.barnes@gmail.com] > *Gesendet:* Montag, 6. Januar 2014 20:00 > > *An:* Jesske, Roland > *Cc:* DISPATCH; Gonzalo Camarillo; Atle Monrad; Dean Willis > *Betreff:* Re: PROTO Review: draft-drage-sipping-rfc3455bis-09.txt > > > > Hi Roland, > > > > One final editorial nit below. If you can spin a revision, then I'll sen= d > the PROTO write-up to the AD. > > > > Thanks, > > Mary. > > > > On Thu, Jan 2, 2014 at 3:29 AM, wrote: > > Hi Mary, > > I wish you a happy new year 2014. And the best for the next year. > > > > I was looking again on my changes I made due to your proposal in December= . > > I realized that if I change the SHOULD to MUST we have now a backward > compatibility problem. > > We are using the P-Associated-URI also over the IMS user interface which > is not encrypted. > > So I propose to add some more words. > > =85 > > Section 6.1 > > =85 > > An eavesdropper could possibly collect the list of identities > a user is registered. > > This can 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. > > > > Since the P-Associated-URI header field value allows to > implicitly register > > a bundle of URIs with one REGISTER Message the impact of security > using the P-Associated-URI header field is not higher than > > using single REGISTER messages when registering all identities > explicit. > > [MB] I just have some editorial suggestions for the above: > > NEW: > > While the P-Associated-URI header field value allows the implicit > registration of > > a bundle of URIs with one REGISTER Message the impact of security > using the P-Associated-URI header field is no higher than > > using separate REGISTER messages for each of the URIs. > > [/MB] > > > > > > > > > > For the P-Called-Party-Id the change should be also done like as follows: > > > > An eavesdropper could possibly collect the list of identities > a user is registered. > > This can have privacy implications. To mitigate this problem, thi= s > extension SHOULD > > only be used in a secured environment, where encryption of SIP > messages is > > provided either end-to-end or hop-by-hop. > > > > Normally within a 3GPP environment the P-Called-Party-ID is > not sent towards end users but may be exchanged between carriers where > other security mechanisms than SIP encryption are used. > > > > Sorry coming so late. > > If this is OK for you I will include it to a new version. > > > > Thank you and Best Regards > > > > Roland > > > > *Von:* Mary Barnes [mailto:mary.ietf.barnes@gmail.com] > *Gesendet:* Freitag, 27. Dezember 2013 19:45 > > > *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 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 so= me > 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 "potent= ially 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 th= e 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" t= hat makes this header not of particular concern with regards to security. D= oes it reveal additional, unique information about an individual that isn't= available in other headers. Also, the 2nd paragraph needs some work - may= be 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 r= egistered. 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 rev= ision. And, I believe you still need to identify privacy/security implicat= ions by addressing whether or not this header reveals any unique informatio= n 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 > > - > > > > > > > --089e0122e92eaa2ead04ef651171 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Thanks Roland. =A0I have reviewed that version and all the= changes I suggested have been made. =A0However, in doing the PROTO write-u= p I realized that I wasn't certain anyone had reviewed the ABNF. So, I = ran the ABNF through Bill Fenner's tool:=A0

And, there are a coupl= e things that need to be fixed:
1) =A0DOT needs to change to = "." (we had this same bug in RFC 4244):
transit-ioi-ind= exed-value =3D transit-ioi-name DOT transit-ioi-index

=
2) =A0There's an extra space here (between * and parenthesis):
=
transit-i= oi-name =3D ALPHA * (ALPHA / DIGIT)
= NEw: = transit-ioi-name =3D ALPHA *(ALPHA / DIGIT)

There are also a number of long lines in the ABNF that should be fix= ed.=A0

In addition, IDNITS identifies other errors and warning= s per the following. =A0Those should also be addressed including considerin= g whether obsolete references need changing:
idnits 2.13.01=20

tmp/draft-drage-sipping-rfc3455bis-11.txt:

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  http://trustee.ietf.org/=
license-info):
  -------------------------------------------------------------------------=
---

     No issues found here.

  Checking nits according to http://www.ietf.org/id-info/1id-guidelines.txt:
  -------------------------------------------------------------------------=
---

     No issues found here.

  Checking nits according to http://www.ietf.org/id-info/checklist :
  -------------------------------------------------------------------------=
---

  ** There are 9 instances of too long lines in the document, the longest o=
ne
     being 20 characters in excess of 72.

  =3D=3D There are 4 instances of lines with non-RFC2606-compliant FQDNs in=
 the
     document.

  =3D=3D There are 4 instances of lines with non-RFC5735-compliant IPv4 add=
resses
     in the document.  If these are example addresses, they should be chang=
ed.


  Miscellaneous warnings:
  -------------------------------------------------------------------------=
---

  =3D=3D The document seems to contain a disclaimer for pre-RFC5378 work, b=
ut was
     first submitted on or after 10 November 2008.  The disclaimer is usual=
ly
     necessary only for documents that revise or obsolete older RFCs, and t=
hat
     take significant amounts of text from those RFCs.  If you can contact =
all
     authors of the source material and they are willing to grant the BCP78
     rights to the IETF Trust, you can and should remove the disclaimer.=20
     Otherwise, the disclaimer is needed and you can ignore this comment.=
=20
     (See the Legal Provisions document at
     http://trustee.ietf.o=
rg/license-info for more information.)


  Checking references for intended status: Informational
  -------------------------------------------------------------------------=
---

  =3D=3D Missing Reference: 'RFC XXXX' is mentioned on line 1667, b=
ut not defined

  -- Looks like a reference, but probably isn't: '3' on line 19=
48

  =3D=3D Unused Reference: 'RFC2976' is defined on line 2065, but n=
o explicit
     reference was found in the text

  =3D=3D Unused Reference: 'RFC3262' is defined on line 2068, but n=
o explicit
     reference was found in the text

  =3D=3D Unused Reference: 'RFC3311' is defined on line 2075, but n=
o explicit
     reference was found in the text

  =3D=3D Unused Reference: 'RFC3428' is defined on line 2081, but n=
o explicit
     reference was found in the text

  =3D=3D Unused Reference: 'RFC3903' is defined on line 2093, but n=
o explicit
     reference was found in the text

  ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234)

  -- Obsolete informational reference (is this intentional?): RFC 2976
     (Obsoleted by RFC 6086)

  -- Obsolete informational reference (is this intentional?): RFC 3265
     (Obsoleted by RFC 6665)


     Summary: 2 errors (**), 0 flaws (~~), 9 warnings (=3D=3D), 3 comments =
(--).

     Run idnits with the --verbose option for more detailed information abo=
ut
     the items above.
While I apologize for not catc= hing these issues earlier, it really is the responsibility of authors to ch= eck idnits (beyond what the submission tool requires) for their documents. = =A0I routinely run idnits before I submit a document as it can also save ti= me when fixing the =A0nits that the submission tool catches: =A0=A0https://tools.ietf.org/tools/idni= ts/

Regards,
Mary.=A0




On Tue, Jan 7, 2014 at 12:35 AM, <R.Jesske@telekom.de> wrote:

H= i Mary,

Now a new = revision is available.

=A0

Thank you and B= est Regards

=A0=

Roland

=A0=

Von: Mary Barnes [mailto:mary.ietf.barnes@gmail.com]
Gesendet: Montag, 6. Januar 2014 20:00

=

An: Jesske, Roland
Cc: DISPATCH= ; Gonzalo Camarillo; Atle Monrad; Dean Willis
Betreff: Re: PROTO Review: draft-drage-sipping-rfc3455bis-09.txt<= /u>

=A0

Hi Roland,=

=A0

One final editorial nit below. =A0If you can spin a revision, then = I'll send the PROTO write-up to the AD.

=A0

Thanks,

Mary.=A0

=A0

On Thu, Jan 2, 2014 at 3:29 AM, <R.Jesske@telekom.de> wrote:

=

Hi Ma= ry,

I wish you= a happy new year 2014. And the best for the next year.

=A0=

I was looking again on my changes I made due to your proposal in De= cember.

I realized= that if I change the SHOULD to MUST we have now a backward compatibility p= roblem.

We are usi= ng the P-Associated-URI also over the IMS user interface which is not encry= pted.

So I propo= se to add some more words.

<= span lang=3D"EN-US" style=3D"font-size:11.0pt;font-family:"Calibri&quo= t;,"sans-serif";color:#1f497d">=85

Section 6.= 1

=85

=A0=A0=A0=A0=A0=A0=A0=A0 <t>An eavesdropper could possibly collect the list of identities= a user is registered.=A0

=A0=A0=A0=A0=A0=A0=A0This can have privacy implic= ations. To mitigate this problem, this extension SHOULD

=A0=A0=A0=A0=A0=A0=A0only b= e used in a secured environment, where encryption of SIP messages is

=A0=A0=A0=A0=A0=A0=A0pro= vided either end-to-end or hop-by-hop.=A0 </<= /span>t><= /span>

=A0=A0

=A0=A0=A0=A0=A0=A0<t> Since the= P-Associated-URI header field value allows to implicitly register <= u>

=A0=A0=A0=A0=A0=A0a bundle of URIs with one REGIS= TER Message the impact of security using the P-Associated-URI header field = is not higher than=A0

=A0= =A0=A0=A0=A0=A0using single REGISTER messages when registering all identiti= es explicit.</t>

[MB] I just have some editorial sug= gestions for the above:

= NEW: =A0

<t>=A0While the P-Associated-URI header field value allows the i= mplicit registration of=A0

=A0=A0=A0=A0=A0=A0a bundle of U= RIs with one REGISTER Message the impact of security using the P-Associated= -URI header field is no higher than=A0

=A0=A0=A0=A0=A0=A0using separate REGISTER m= essages for each of the URIs.=A0</t>

[/MB]

=A0

=

=A0

=A0

=A0

For the P-Called-Party-Id the change should be also done like as follows= :

=A0=

=A0=A0=A0=A0=A0=A0=A0 <t>An eavesdropper could possibly collect the lis= t of identities a user is registered.=A0

=A0=A0=A0=A0=A0=A0=A0This can have privacy implic= ations.=A0 To mitigate this problem, this extension SHOULD

=A0=A0=A0=A0=A0=A0=A0only b= e used in a secured environment, where encryption of SIP messages is

=A0=A0=A0=A0=A0=A0=A0provided either end-to-end or ho= p-by-hop.=A0 </t>

=A0

=A0=A0=A0=A0=A0=A0=A0 <t>Normally within a 3GPP environment the P-C= alled-Party-ID is not sent towards end users but may be exchanged between c= arriers where other security mechanisms than SIP encryption are used.=A0 </t<= span style=3D"color:blue">>

=A0=

Sorry coming so late.

If this is= OK for you I will include it to a new version.

=A0=

Thank you and Best Regards

=A0=

Roland

=A0=

Von: Mary Barn= es [mailto:= mary.ietf.barnes@gmail.com]
Gesendet: Freitag, 27. Dezember 2013 19:45

<= div>


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

=A0

Hi Roland,

=A0

Thanks for mak= ing these changes. I finally had a chance to review this updated version. = =A0 I still have a couple comments on the security section as I think you w= ill get questions during SEC review around this unless some more detail is = provided on security threats and impacts. =A0 I've extracted these few = points from previous review comment threads.

=A0

Thanks,

M= ary.

=A0

----Previous point =A0------------------------------= --->

- Section 6.1: this needs some tighter wordi=
ng. =A0What is meant by "potentially annoying" =A0for example? =
=A0
=A0[R=
J] I do not know. This is original text. So I deleted the words.<=
/u>
-<=
/u>
[MB] So, you removed that part of the sentence and are left with:
"This attack should not have any signifi=
cant impacts."
=A0
I don't think th=
at adds any value and just begs the question "what are the insignifica=
nt impacts and are there any privacy concerns"?=A0 Really, it's th=
e next paragraph that provides details of the impacts.=A0 I think you could=
 probably remove that sentence altogether and not lose anything. 


=A0
[/MB]

=A0
----Previous point --------------------------------->


=A0
-=A0 Section 6.2: I think you need to be mor=
e specific about the "nature" that makes this header not of parti=
cular concern with regards to security. Does it reveal additional, unique i=
nformation about an individual that isn't available in other headers. =
=A0Also, the 2nd paragraph needs some work - maybe something like:


=A0
OLD:
=A0
An eavesdropper m=
ay collect the list of identities a user is registered.=A0 This may have pr=
ivacy implications.=A0 To mitigate this problem, this extension SHOULD only=
 be used in a secured environment, where encryption of SIP messages is prov=
ided either end-to-end or


=A0
hop=
-by-hop.=A0
<=
span style=3D"font-family:"Arial","sans-serif";color:#5=
00050">NEW:=A0


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


----End prev=
ious point ------------------------------<

[MB]=A0 The suggested change for the first sente=
nce didn't get into the revision.=A0 And, I believe you still need to i=
dentify privacy/security implications by addressing whether or not this hea=
der reveals any unique information about an individual that isn't avail=
able in other headers.=A0=A0 [/MB]
=A0
=A0
=A0
=A0<=
/pre>

=A0

=A0=

On Tue, Dec 3, 2013 at 7:00 AM, <R.Jesske@telekom.de> 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.<= /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 d= raft-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 (SIP) for the 3rd= -Generation Partnership Project (3GPP)

Creation date:=A0=A0=A0 2013-12-03<= /u>

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

N= umber 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 Protocol<= /u>

=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: DISPA= TCH; Gonzalo Camarillo; Atle Monrad; Dean Willis

Betreff: Re: PROTO Review: draft-drage-sipping-rfc3455bis-09.txt<= /u>

=A0

<= div>

Hi Roland,

=A0

Thanks for your resp= onse. =A0Additional comments below [MB].

=A0

Tha= nks,

Mary.

=A0

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

= Hi Mary,

Thank you for your review.

I have add= ed now your proposals to the draft.

Other comments please see below.<= /span>

=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
=A0
=A0
- Section 3. =A0This sect=
ion needs to be updated. =A0I don't think that 10 year old background i=
s relevant in the current context. =A0 You should be able to model this aft=
er the text in more recent 3GPP P-header documents, referring to the SIP ch=
ange 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
=A0
=A0
Section 4.2, 1st paragraph. =A0The behavior in this senten=
ce is not normative from a SIP protocol perspective, thus MAY is not approp=
riate. =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.
=A0
=A0
NEW:=A0<=
/u>
=A0=A0 In the context of the n=
etwork to which the header fields defined in this document apply, a User Ag=
ent has=A0no knowledge of the P-Visited-Network-ID when sending the REGISTE=
R request. =A0Therefore user agent clients MUST NOT insert a P-Visited-Netw=
ork-ID=A0header field=A0in any SIP message.


=A0
- Section 4.3.2.2:, 2nd paragraph: =A0"=
;home network MAY use" -> "home network can use"

=A0
=A0<=
/pre>
=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>
=A0
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
=A0<=
u>
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 v=
oid value. =A0Nevertheless
=A0=A0 it can not be gua=
ranteed that all values will appear within the P-Charging-Vector header fie=
ld.=A0
=A0
=A0<=
u>
NEW:=A0
=A0
=A0=A0 Depending o=
n the call scenario, each transit network can add either a transit network =
name=A0or a void=A0=A0=A0 value.=A0 However, it can not be guaranteed that =
all the values that are added will appear within the P-Charging-Vector head=
er 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
=A0=

=A0
- Section 5.7. Delete this text and table. =A0 We are=
n't these tables anymore as they really don't provide any useful in=
formation. =A0You just need to verbally state what messages these headers c=
an 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
=A0<=
/pre>
=A0
hop-by-hop.=A0
=A0 =A0
NEW:=
=A0
=A0
=A0An eavesdropper could possibly collect the list of i=
dentities a user is registered.=A0 This can have privacy implications.=A0 T=
o mitigate this problem, this extension MUST only be used in a secured envi=
ronment, where encryption of SIP 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

- Section 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
=A0
=A0
-- 8th paragraph: "SHOULD NOT send sens=
itive information" -> "MUST NOT send sensitive information&quo=
t;


=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
=A0
=A0
- Section 4.1, 2nd paragraph. =A0"has associated to a=
n address-of-record" -> "has associated with an address-of-rec=
ord"


- 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

=A0

=A0

=
--089e0122e92eaa2ead04ef651171-- From mary.ietf.barnes@gmail.com Tue Jan 7 10:09:59 2014 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 559C81AE0C9 for ; Tue, 7 Jan 2014 10:09:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.301 X-Spam-Level: X-Spam-Status: No, score=0.301 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, MANGLED_TOOL=2.3, 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 G0vonmTIVepb for ; Tue, 7 Jan 2014 10:09:57 -0800 (PST) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) by ietfa.amsl.com (Postfix) with ESMTP id C647A1AE06D for ; Tue, 7 Jan 2014 10:09:56 -0800 (PST) Received: by mail-wi0-f175.google.com with SMTP id hi5so4504205wib.2 for ; Tue, 07 Jan 2014 10:09:47 -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=J+getyakOpJq9ea+elVZvtwXTTYpFbNUm/XE/3vzhro=; b=Kaul+regPFKh+NcW66nGrZeMXSsJHOllTpEozsbelCRIgtcISgR+OXWuwQ0V3K7Nij 226mseiQwhWpiZ3SMXy1cWGgx9HzKOxUBZgJZoahPtwHOKc69ry6Fi8kfBw+JentIXbw +wwRWy4Ziu4uRFTRa/R1j6J6KiTxkXz7DkNJH23cgWYbXMu75NLAr+TG0VJxf75cRLHz 6bSyNYlylRDtjB7rHiqqhB+cPTdW057K/WIo/BJGxc2x7ynNqGwZgnK95GnHd/iMFfoj TqlchTtddYfRIpiET4yEMfpBCVpblQjPXjgvCnqJUCyxzPLlk/WdFSBwFrbp6y+uUTWq 3WOw== MIME-Version: 1.0 X-Received: by 10.194.82.68 with SMTP id g4mr6380717wjy.85.1389118187430; Tue, 07 Jan 2014 10:09:47 -0800 (PST) Received: by 10.216.172.9 with HTTP; Tue, 7 Jan 2014 10:09:47 -0800 (PST) Date: Tue, 7 Jan 2014 12:09:47 -0600 Message-ID: From: Mary Barnes To: DISPATCH Content-Type: multipart/alternative; boundary=047d7bea41fe1cec7004ef6548b3 Cc: Anton Tveretin 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: Tue, 07 Jan 2014 18:09:59 -0000 --047d7bea41fe1cec7004ef6548b3 Content-Type: text/plain; charset=ISO-8859-1 Hi all, I'm forwarding this message on behalf of Anton. His messages are getting tagged as SPAM and they're hitting the WG admin Queue (it may be because his email server looks to be tagging the incoming message as SPAM). In the meanwhile, folks might want to consider Anton's draft and provide feedback on the mailing list. I will note that in the cases where folks are getting DIGESTS from mailing list subscriptions, it is *extremely* helpful (and really necessary actually) to change the Subject line to something relevant - in general the same subject as in the original email is appropriate. Regards, Mary as DISPATCH WG co-chair ---------- Forwarded message ---------- From: "Anton Tveretin" To: Cc: Date: Tue, 7 Jan 2014 21:44:01 +0600 Subject: ***SPAM*** 7.944 (5) Re: dispatch Digest, Vol 57, Issue 3 Please consider my draft, draft-tveretin-dispatch-sdp-l2tp-00. I did not make progress to -01 version due to the lack of reaction. I plan to prepare several more I-Ds. However, I'm not sure to complete them within any deadline. IMO the work I'm doing ~25 years could wait few months more. Note: [www.ietf.org/rt #62000] Messages do not reach mailing list ----- Original Message ----- From: To: Sent: Thursday, December 19, 2013 2:00 AM Subject: dispatch Digest, Vol 57, Issue 3 Send dispatch mailing list submissions to > dispatch@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/dispatch > or, via email, send a message with subject or body 'help' to > dispatch-request@ietf.org > > You can reach the person managing the list at > dispatch-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of dispatch digest..." > > > Today's Topics: > > 1. Reminder: DISPATCH WG deadlines for IETF-89 (Mary Barnes) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 18 Dec 2013 11:41:19 -0600 > From: Mary Barnes > To: DISPATCH > Cc: Cullen Jennings > Subject: [dispatch] Reminder: DISPATCH WG deadlines for IETF-89 > Message-ID: > > 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 > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > attachments/20131218/8c92b044/attachment.html> > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > > ------------------------------ > > End of dispatch Digest, Vol 57, Issue 3 > *************************************** > ---------- Forwarded message ---------- From: dispatch-request@ietf.org To: Cc: Date: Tue, 07 Jan 2014 08:07:21 -0800 Subject: confirm d578b391c68591494c8581f1c9dac01b657f9b89 If you reply to this message, keeping the Subject: header intact, Mailman will discard the held message. Do this if the message is spam. If you reply to this message and include an Approved: header with the list password in it, the message will be approved for posting to the list. The Approved: header can also appear in the first line of the body of the reply. --047d7bea41fe1cec7004ef6548b3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi all,

I'm forwarding this message= on behalf of Anton. =A0His messages are getting tagged as SPAM and they= 9;re hitting the WG admin Queue (it may be because his email server looks t= o be tagging the incoming message as SPAM). =A0 In the meanwhile, folks mig= ht want to consider Anton's draft and provide feedback on the mailing l= ist.

I will note that in the cases where folks are getting D= IGESTS from mailing list subscriptions, it is *extremely* helpful (and real= ly necessary actually) to change the Subject line to something relevant - i= n general the same subject as in the original email is appropriate.

Regards,
Mary=A0
as DISPATCH WG co-= chair =A0


---------- Forwarded messag= e ----------
From:=A0"Anton Tveretin" <fas_vm@surguttel.ru>
To:=A0<dispatch@ietf.org>Cc:=A0
Date:=A0Tue, 7 Jan 2014 21:44:01 +0600
Subject:=A0***SPAM*** = 7.944 (5) Re: dispatch Digest, Vol 57, Issue 3
Please consider my draft,= draft-tveretin-dispatch-sdp-l2tp-00. I did not
make progress to -01 version due to the lack of reaction.
I plan to prepare several more I-Ds. However, I'm not sure to complete = them
within any deadline. IMO the work I'm doing ~25 years could wait few mo= nths
more.

Note: [www.ietf.org/rt= #62000] Messages do not reach mailing list

----- Original Message ----- From: <dispatch-request@ietf.org>
To: <dispatch@iet= f.org>
Sent: Thursday, December 19, 2013 2:00 AM
Subject: dispatch Digest, Vol 57, Issue 3


Send dispatch mailing list submissions to
dispatch@ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
https://www.ietf.org/mailman/listinfo/dispatch
or, via email, send a message with subject or body 'help' to
dispatch-req= uest@ietf.org

You can reach the person managing the list at
dispatch-owner= @ietf.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of dispatch digest..."


Today's Topics:

=A0 1. Reminder: DISPATCH WG deadlines for IETF-89 (Mary Barnes)


-------------------------------------------------------------= ---------

Message: 1
Date: Wed, 18 Dec 2013 11:41:19 -0600
From: Mary Barnes <mary.ietf.barnes@gmail.com>
To: DISPATCH <dis= patch@ietf.org>
Cc: Cullen Jennings <fluffy@cisco.com>
Subject: [dispatch] Reminder: DISPATCH WG deadlines for IETF-89
Message-ID:
<CAHBDyN6yxKgc3Xp9pVrHMka9K5G8SbLE7g= no3G-DLOp3BMshYg@mail.gmail.com>
Content-Type: text/plain; charset=3D"iso-8859-1"

As a reminder, the following are deadlines for the DISPATCH WG for
consideration of work items leading up to IETF-89:
h= ttp://tools.ietf.org/wg/dispatch/trac/wiki

=A0 - Jan 27, 2014. Cutoff date to notify the chairs/DISPATCH WG of plans t= o
=A0 submit a proposal.


=A0 - Feb 3, 2014. Cutoff for charter proposals for topics (to the mailing<= br> =A0 list)


=A0 - 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. =A0 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.ietf.org/mail= -archive/web/dispatch/attachments/20131218/8c92b044/at= tachment.html>

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

Subject: Digest Footer

_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch


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

End of dispatch Digest, Vol 57, Issue 3
***************************************



---------- Forwarded message ----------
From:=A0dispatch-request@ietf.org
To:=A0
Cc:= =A0
Date:=A0Tue, 07 Jan 2014 08:07:21 -0800
Subject:=A0confirm d578b3= 91c68591494c8581f1c9dac01b657f9b89
If you reply to this message, keeping the Subject: header intact,
Mailman will discard the held message. =A0Do this if the message is
spam. =A0If you reply to this message and include an Approved: header
with the list password in it, the message will be approved for posting
to the list. =A0The Approved: header can also appear in the first line
of the body of the reply.

--047d7bea41fe1cec7004ef6548b3-- From mary.ietf.barnes@gmail.com Tue Jan 7 10:11:56 2014 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 AD86D1AE0F9 for ; Tue, 7 Jan 2014 10:11:56 -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 1l0dB2hd3u6G for ; Tue, 7 Jan 2014 10:11:54 -0800 (PST) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) by ietfa.amsl.com (Postfix) with ESMTP id 7E0981AE0F8 for ; Tue, 7 Jan 2014 10:11:54 -0800 (PST) Received: by mail-wi0-f182.google.com with SMTP id en1so1069388wid.3 for ; Tue, 07 Jan 2014 10:11:45 -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=OYFHCZVio45OYFqD2ZuX6OakaDYZ5hLeJV5bVxqGSiM=; b=1GDula4bfbhykV5ylTOEnboYiDbMu+WRlOFhjUA0adRw3aUeerS9A6Ue1OTBfk+Zy1 8bxg5C+fJWDxloheWCThUuJsdE908uw1NX4W7LsyjjHguzf7H1bJmpTlsZRfE5A1jJGL AsvPkFBdzFMUR+QK4n0mi5D3gI2wp6WzkI1fB9FaJOF9bPweGbtEs9bw7WWwALoJf7JK MMTcvNqUtkhhEqJ+gD9LeykQUA+d+pfGw6iWtE6qz/HMAdU2TSFuw+oKzVQkPKFSMVkD JAHjtsV+v5fDvGZGB7wtobEppeMpcy7hGRzmOlf4DFiKnYuRoBj7yIBod02kj3umjlhq 9pyA== MIME-Version: 1.0 X-Received: by 10.194.170.133 with SMTP id am5mr52691975wjc.42.1389118305261; Tue, 07 Jan 2014 10:11:45 -0800 (PST) Received: by 10.216.172.9 with HTTP; Tue, 7 Jan 2014 10:11:45 -0800 (PST) In-Reply-To: References: Date: Tue, 7 Jan 2014 12:11:45 -0600 Message-ID: From: Mary Barnes To: DISPATCH Content-Type: multipart/alternative; boundary=089e0122e92e22de3904ef654fc9 Cc: Cullen Jennings Subject: Re: [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: Tue, 07 Jan 2014 18:11:56 -0000 --089e0122e92e22de3904ef654fc9 Content-Type: text/plain; charset=ISO-8859-1 As a reminder the first deadline for IETF-89 is in less than 3 weeks. So, far, we've had one proposal from Olle: http://www.ietf.org/mail-archive/web/dispatch/current/msg05133.html Regards, Mary. On Wed, Dec 18, 2013 at 11:41 AM, Mary Barnes wrote: > 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 > > > > > --089e0122e92e22de3904ef654fc9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
As a reminder the first deadline for IETF-89 is in less th= an 3 weeks. =A0 =A0

So, far, we've had one proposal = from Olle:=A0

Regards,
Mary.=A0

On Wed, Dec 18, 2013 at 11:41 AM,= Mary Barnes <mary.ietf.barnes@gmail.com> wrote:
As a reminder, the following are deadline= s for the DISPATCH WG for consideration of work items leading up to IETF-89= : =A0http://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 li= st)=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>




--089e0122e92e22de3904ef654fc9-- From oej@edvina.net Tue Jan 7 11:23:45 2014 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 E09A61AE11C for ; Tue, 7 Jan 2014 11:23:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 KoQmQEAN-IXy for ; Tue, 7 Jan 2014 11:23:43 -0800 (PST) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id A1CF91AE155 for ; Tue, 7 Jan 2014 11:23:24 -0800 (PST) Received: from [192.168.40.13] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 56EC093C2A1; Tue, 7 Jan 2014 19:23:14 +0000 (UTC) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: "Olle E. Johansson" In-Reply-To: <52CC36A7.1070500@alum.mit.edu> Date: Tue, 7 Jan 2014 20:23:13 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3F943FCA-9D9F-48FD-BEFF-ACFCC8D725D6@edvina.net> References: <20140102101042.27427.64547.idtracker@ietfa.amsl.com> <0BA14051-5C7F-4416-8CD2-413347D540D3@edvina.net> <52C83591.3080702@alum.mit.edu> <52CC36A7.1070500@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1827) Cc: "dispatch@ietf.org list" Subject: Re: [dispatch] New Version Notification for draft-johansson-dispatch-dane-sip-00.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, 07 Jan 2014 19:23:46 -0000 On 07 Jan 2014, at 18:17, Paul Kyzivat wrote: > Olle, >=20 > Thanks for clarification. >=20 > I think it would be helpful if you would add a section on deployment = hints and issues. Then you could talk about various cases: >=20 > - updating a server that already supports TLS via 5922 > - updating a client that already supports TLS via 5922 > - recommendations for a server newly supporting TLS > - recommendations for a client newly supporting TLS > - ... THanks, I'll look into that. We just need to get this document dispatched :-) >=20 > Another question that came to me is what to do about TLS client = authentication? I started thinking about that too. Connection reuse comes to mind. Now = that we have the s/mime dane draft we might be able to steal some ideas from that. I = would like to make that a separate document.=20 /O >=20 > Thanks, > Paul >=20 > On 1/7/14 6:12 AM, Olle E. Johansson wrote: >>=20 >> On 04 Jan 2014, at 17:23, Paul Kyzivat wrote: >>=20 >>> On 1/2/14 5:16 AM, Olle E. Johansson wrote: >>>> Hi! >>>> I have renamed my draft and resubmitted it again. Adding = DNSsec/DANE support to SIP is not a bad idea in my point of view. >>>=20 >>> It seems like a really good idea to me. >>>=20 >>> I have a question about backward compatibility, as discussed in = section 9: >>>=20 >>> You say that that servers can use certificates that support both = DANE and 5922 style validation. And IIUC that will be necessary in order = to handle clients that don't support DANE validation. >> Yes. >>>=20 >>> But the Intro explains that one of the important reasons for = introducing DANE authentication is because of various logistic problems = providing certificates for 5922 style validation. Providing backward = compatibility negates that advantage. >> Well, I might need to clarify that. The current way to host multiple = SIP domains is either to have one certificate with a long list of = subject Alt Names or multiple IPs each with it's own certificate with = the domain in SubjAltName. Both are very hard to maintain. Either buy a = new cert for a new domain - and a new IP. Or reissue the existing cert = to get an additional name. >> SNI could also be used, but is not yet wildely supported out there. = It just means one cert per domain. I don't remember if we've specified = how SNI applies to RFC 5922 - what are we specifying in the SNI lookup? >>=20 >>=20 >>>=20 >>> Have you considered the migration path? Presumably those currently = using 5922 already have a certificate that works for that. Will they be = able to get a cert that continues that and also supports DANE = validation? >> Yes, they just need to get the host name into the CN. 5922-compliant = clients ignore the CN when there are SubjectAltNames and clients = supporting this draft will ignore the SubjectAltNames. >>=20 >>>=20 >>> What about those coming to this without any history of 5922 support? >> Those will look for something in some field that's very unspecified. = Hard to support. I guess that they will look for something to match in = the CN. What that is varies - which is why we need standardization :-) >>=20 >> Wild guess is that they look for the domain in the CN. They will not = accept certificates according to this RFC. >> Again SNI could help. >>=20 >>>=20 >>> ISTM that there is need to get ubiquitous client support for this = deployed. For that we have the usual chicken/egg scenario. >> Always that chicken and the %&=80&=80& egg. ;-) >>=20 >> Thank you for your feedback, Paul! >>=20 >> /O >>>=20 >>> Thanks, >>> Paul >>>=20 >>>> If the view gets larger we might want to focus a bit more on = security aspects of SIP in the RAI area. There are many issues to look = at. Why isn't S/MIME deployed, how do we get more TLS - if that's what = we want? Can we improve upon MD5 digest authentication? Do we want to = fix SIP identity that many claim is broken? Is it possible to set up = sessions with end2end security? >>>>=20 >>>> Happy New Year! >>>>=20 >>>> /O >>>>=20 >>>>=20 >>>>=20 >>>> Begin forwarded message: >>>>>=20 >>>>> A new version of I-D, draft-johansson-dispatch-dane-sip-00.txt >>>>> has been successfully submitted by Olle E. Johansson and posted to = the >>>>> IETF repository. >>>>>=20 >>>>> Name: draft-johansson-dispatch-dane-sip >>>>> Revision: 00 >>>>> Title: TLS sessions in SIP using DNS-based = Authentication of Named Entities (DANE) TLSA records >>>>> Document date: 2014-01-02 >>>>> Group: Individual Submission >>>>> Pages: 9 >>>>> URL: = http://www.ietf.org/internet-drafts/draft-johansson-dispatch-dane-sip-00.t= xt >>>>> Status: = https://datatracker.ietf.org/doc/draft-johansson-dispatch-dane-sip/ >>>>> Htmlized: = http://tools.ietf.org/html/draft-johansson-dispatch-dane-sip-00 >>>>>=20 >>>>>=20 >>>>> Abstract: >>>>> Use of TLS in the SIP protocol is defined in multiple documents, >>>>> starting with RFC 3261. The actual verification that happens = when >>>>> setting up a SIP TLS connection to a SIP server based on a SIP = URI is >>>>> described in detail in RFC 5922 - SIP Domain Certificates. >>>>>=20 >>>>> In this document, an alternative method is defined, using = DNS-Based >>>>> Authentication of Named Entities (DANE). By looking up TLSA DNS >>>>> records and using DNSsec protection of the required queries, >>>>> including lookups for NAPTR and SRV records, a SIP Client can = verify >>>>> the identity of the TLS SIP server in a different way, matching = on >>>>> the SRV host name in the X.509 PKIX certificate instead of the = SIP >>>>> domain. This provides more scalability in hosting solutions and = make >>>>> it easier to use standard CA certificates (if needed at all). >>>>>=20 >>>>> This document updates RFC 5922. >>>>>=20 >>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> dispatch mailing list >>>> dispatch@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dispatch >>>>=20 >>>=20 >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >>=20 >>=20 >=20 From oej@edvina.net Tue Jan 7 11:26:05 2014 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 E44F61AE134 for ; Tue, 7 Jan 2014 11:26:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.25 X-Spam-Level: X-Spam-Status: No, score=-1.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 wjlDZFiErqx1 for ; Tue, 7 Jan 2014 11:26:04 -0800 (PST) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id DF5451AE133 for ; Tue, 7 Jan 2014 11:26:03 -0800 (PST) Received: from [192.168.40.13] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id A0C7B93C2A1; Tue, 7 Jan 2014 19:25:54 +0000 (UTC) Content-Type: multipart/alternative; boundary="Apple-Mail=_B8CB0675-67AC-4D4A-BF17-3AA4B62B97F1" Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: "Olle E. Johansson" In-Reply-To: Date: Tue, 7 Jan 2014 20:25:54 +0100 Message-Id: References: <20140102101042.27427.64547.idtracker@ietfa.amsl.com> <0BA14051-5C7F-4416-8CD2-413347D540D3@edvina.net> <52C83591.3080702@alum.mit.edu> To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= X-Mailer: Apple Mail (2.1827) Cc: "dispatch@ietf.org list" Subject: Re: [dispatch] New Version Notification for draft-johansson-dispatch-dane-sip-00.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, 07 Jan 2014 19:26:06 -0000 --Apple-Mail=_B8CB0675-67AC-4D4A-BF17-3AA4B62B97F1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 07 Jan 2014, at 17:17, I=F1aki Baz Castillo wrote: >=20 > > Those will look for something in some field that's very unspecified. = Hard to support. I guess that they will look for something to match in = the CN. >=20 > This is not true. SNI does not mean "ignoring SubjectAltNames". SNI = just means that the client indicates the desired hostname during the TLS = handshake, the server offers a proper certificate for such a hostname, = and the client then validates the server certificate following the = protocol rules (in case of SIP it means rules in RFC 5922). >=20 Right - where is it documented what a SIP client should provide in a SNI = - a domain name, a SIP uri (which matches the SAN) or the host name - = which we claim should not be used? /O= --Apple-Mail=_B8CB0675-67AC-4D4A-BF17-3AA4B62B97F1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
On 07 Jan 2014, at 17:17, I=F1aki Baz = Castillo <ibc@aliax.net> = wrote:


> Those will look for something in some field that's very = unspecified. Hard to support. I guess that they will look for something = to match in the CN.

This is not true. SNI does not = mean "ignoring SubjectAltNames". SNI just means that the client = indicates the desired hostname during the TLS handshake, the server = offers a proper certificate for such a hostname, and the client then = validates the server certificate following the protocol rules (in case = of SIP it means rules in RFC 5922).

Right - where is it documented what a SIP client = should provide in a SNI - a domain name, a SIP uri (which matches the = SAN) or the host name - which we claim should not be = used?

/O
= --Apple-Mail=_B8CB0675-67AC-4D4A-BF17-3AA4B62B97F1-- From ibc@aliax.net Tue Jan 7 13:31:41 2014 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 F2E071AE19E for ; Tue, 7 Jan 2014 13:31:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] 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 hTEbAePvykrm for ; Tue, 7 Jan 2014 13:31:39 -0800 (PST) Received: from mail-qe0-f53.google.com (mail-qe0-f53.google.com [209.85.128.53]) by ietfa.amsl.com (Postfix) with ESMTP id 85B961AE0E2 for ; Tue, 7 Jan 2014 13:31:39 -0800 (PST) Received: by mail-qe0-f53.google.com with SMTP id t7so991296qeb.12 for ; Tue, 07 Jan 2014 13:31:30 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=vO279wfjwJjCx+nX3EzfgnuRmEQBqrhsTmDPJVeztx0=; b=N8HfEujs+D9I3UrUCMvg+wIt98Z6EYbEom+UCtsZ4bmN3bakOr4HoeGeH7F1MqyohS /qYRjBtg+5BO71PBYS+jKUrnv5Wh3HKyJEBYu3hXECe+phSxOonHpNEXGM26dQGpRki4 zqVDcIP7mFbAqY+eNYarkvnLR5k6ZhHw9RRVkE+tRxD7ngNsSFvG6D2SS8LDYU/NxEcP MVkqRaEnXTmgVnKHWORr0wAK+88WG0buMKd+qiaP8XyUnIjUvA6mpGNhHPFJYeOvSd+D YjxxBee1bjv27BD4++7mdhOBKu0AdRYADPOHIC6BSDlFwcTcwWdwKs/I3VfPfttH1xkL 4rug== X-Gm-Message-State: ALoCoQl2hm7bWy2709sppmZUt4DXSmt5j5BBpRdraiD/u/fuj55+je+FIcWVsQ88ROo+dqQRM4+F X-Received: by 10.49.72.66 with SMTP id b2mr200704403qev.11.1389130290336; Tue, 07 Jan 2014 13:31:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.96.82.97 with HTTP; Tue, 7 Jan 2014 13:31:10 -0800 (PST) In-Reply-To: References: <20140102101042.27427.64547.idtracker@ietfa.amsl.com> <0BA14051-5C7F-4416-8CD2-413347D540D3@edvina.net> <52C83591.3080702@alum.mit.edu> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 7 Jan 2014 22:31:10 +0100 Message-ID: To: "Olle E. Johansson" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "dispatch@ietf.org list" Subject: Re: [dispatch] New Version Notification for draft-johansson-dispatch-dane-sip-00.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, 07 Jan 2014 21:31:41 -0000 2014/1/7 Olle E. Johansson : > Right - where is it documented what a SIP client should provide in a SNI = - a > domain name, a SIP uri (which matches the SAN) or the host name - which w= e > claim should not be used? Honestly I've never understood the real difference between a domain and a hostname. Of course, IMHO, the SIP client should provide in the SNI the destination domain of the server it is attempting to connect to. --=20 I=C3=B1aki Baz Castillo From oej@edvina.net Tue Jan 7 23:02:51 2014 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 5CA541AE2FB for ; Tue, 7 Jan 2014 23:02:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.251 X-Spam-Level: X-Spam-Status: No, score=-1.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, 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 dbhwGUxWRK9F for ; Tue, 7 Jan 2014 23:02:49 -0800 (PST) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id E77411AE2F5 for ; Tue, 7 Jan 2014 23:02:45 -0800 (PST) Received: from [192.168.40.25] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id EA6C193C2A2; Wed, 8 Jan 2014 07:02:34 +0000 (UTC) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: "Olle E. Johansson" In-Reply-To: Date: Wed, 8 Jan 2014 08:02:36 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140102101042.27427.64547.idtracker@ietfa.amsl.com> <0BA14051-5C7F-4416-8CD2-413347D540D3@edvina.net> <52C83591.3080702@alum.mit.edu> To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= X-Mailer: Apple Mail (2.1827) Cc: "dispatch@ietf.org list" Subject: Re: [dispatch] New Version Notification for draft-johansson-dispatch-dane-sip-00.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: Wed, 08 Jan 2014 07:02:51 -0000 7 jan 2014 kl. 22:31 skrev I=F1aki Baz Castillo : > 2014/1/7 Olle E. Johansson : >> Right - where is it documented what a SIP client should provide in a = SNI - a >> domain name, a SIP uri (which matches the SAN) or the host name - = which we >> claim should not be used? >=20 > Honestly I've never understood the real difference between a domain > and a hostname. Of course, IMHO, the SIP client should provide in the > SNI the destination domain of the server it is attempting to connect > to. Right, but... Does anyone find this in any published document? /O= From R.Jesske@telekom.de Wed Jan 8 00:47:48 2014 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 855BE1AE342 for ; Wed, 8 Jan 2014 00:47:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.486 X-Spam-Level: X-Spam-Status: No, score=-2.486 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.538] 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 Wv632AQN9q1U for ; Wed, 8 Jan 2014 00:47:35 -0800 (PST) Received: from tcmail23.telekom.de (tcmail23.telekom.de [80.149.113.243]) by ietfa.amsl.com (Postfix) with ESMTP id 53CD11AE346 for ; Wed, 8 Jan 2014 00:47:34 -0800 (PST) Received: from he110890.emea1.cds.t-internal.com ([10.134.92.131]) by tcmail21.telekom.de with ESMTP/TLS/AES128-SHA; 08 Jan 2014 09:46:30 +0100 Received: from HE113667.emea1.cds.t-internal.com ([fe80::c943:1394:e86e:fce3]) by he110890 ([10.134.92.131]) with mapi; Wed, 8 Jan 2014 09:46:30 +0100 From: To: Date: Wed, 8 Jan 2014 09:46:29 +0100 Thread-Topic: PROTO Review: draft-drage-sipping-rfc3455bis-09.txt Thread-Index: Ac8L0Zm9q04NPEreQPSvWVfCQE6RdwAe5xTA Message-ID: <058CE00BD4D6B94FAD033A2439EA1E4B01DF8EC99D57@HE113667.emea1.cds.t-internal.com> References: <058CE00BD4D6B94FAD033A2439EA1E4B01DEBB69CC8A@HE113667.emea1.cds.t-internal.com> <058CE00BD4D6B94FAD033A2439EA1E4B01DF27DB8A63@HE113667.emea1.cds.t-internal.com> <058CE00BD4D6B94FAD033A2439EA1E4B01DF8E83EB24@HE113667.emea1.cds.t-internal.com> <058CE00BD4D6B94FAD033A2439EA1E4B01DF8E83F451@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_058CE00BD4D6B94FAD033A2439EA1E4B01DF8EC99D57HE113667eme_" 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: Wed, 08 Jan 2014 08:47:48 -0000 --_000_058CE00BD4D6B94FAD033A2439EA1E4B01DF8EC99D57HE113667eme_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thank you Marry, for doing all this review. So I have now put out the errors. There are still some unused references which are in our informal reference = section. But useful for the reader to know they exist. There are also some warnings with regard to IP addresses and wrong FQDNs wh= ich I think is some interpretation of strings in the text which are not mea= nt to be a IP address or FQDN at all. Detail see below. So now hopefully everything is ready for the next step. Best Regards Roland tmp/draft-drage-sipping-rfc3455bis-12.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see http://trustee.ietf.org/license-info): -------------------------------------------------------------------------= --- No issues found here. Checking nits according to http://www.ietf.org/id-info/1id-guidelines.txt= : -------------------------------------------------------------------------= --- No issues found here. Checking nits according to http://www.ietf.org/id-info/checklist : -------------------------------------------------------------------------= --- =3D=3D There are 4 instances of lines with non-RFC2606-compliant FQDNs in = the document. =3D=3D There are 4 instances of lines with non-RFC5735-compliant IPv4 add= resses in the document. If these are example addresses, they should be chang= ed. Miscellaneous warnings: -------------------------------------------------------------------------= --- No issues found here. Checking references for intended status: Informational -------------------------------------------------------------------------= --- =3D=3D Missing Reference: 'RFC XXXX' is mentioned on line 1662, but not d= efined -- Looks like a reference, but probably isn't: '3' on line 1943 =3D=3D Unused Reference: 'RFC3262' is defined on line 2068, but no explic= it reference was found in the text =3D=3D Unused Reference: 'RFC3311' is defined on line 2072, but no explic= it reference was found in the text =3D=3D Unused Reference: 'RFC3428' is defined on line 2078, but no explic= it reference was found in the text =3D=3D Unused Reference: 'RFC3903' is defined on line 2090, but no explic= it reference was found in the text =3D=3D Unused Reference: 'RFC6086' is defined on line 2101, but no explic= it reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 8 warnings (=3D=3D), 1 comment (= --). Run idnits with the --verbose option for more detailed information abo= ut the items above. ---------------------------------------------------------------------------= ----- Von: Mary Barnes [mailto:mary.ietf.barnes@gmail.com] Gesendet: Dienstag, 7. Januar 2014 18:55 An: Jesske, Roland Cc: DISPATCH; Gonzalo Camarillo; Atle Monrad; Dean Willis Betreff: Re: PROTO Review: draft-drage-sipping-rfc3455bis-09.txt Thanks Roland. I have reviewed that version and all the changes I suggeste= d have been made. However, in doing the PROTO write-up I realized that I w= asn't certain anyone had reviewed the ABNF. So, I ran the ABNF through Bill= Fenner's tool: http://tools.ietf.org/tools/bap/abnf.cgi And, there are a couple things that need to be fixed: 1) DOT needs to change to "." (we had this same bug in RFC 4244): transit-ioi-indexed-value =3D transit-ioi-name DOT transit-ioi-index 2) There's an extra space here (between * and parenthesis): transit-ioi-name =3D ALPHA * (ALPHA / DIGIT) NEw: transit-ioi-name =3D ALPHA *(ALPHA / DIGIT) There are also a number of long lines in the ABNF that should be fixed. In addition, IDNITS identifies other errors and warnings per the following.= Those should also be addressed including considering whether obsolete ref= erences need changing: idnits 2.13.01 tmp/draft-drage-sipping-rfc3455bis-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see http://trustee.ietf.org/license-info): -------------------------------------------------------------------------= --- No issues found here. Checking nits according to http://www.ietf.org/id-info/1id-guidelines.txt= : -------------------------------------------------------------------------= --- No issues found here. Checking nits according to http://www.ietf.org/id-info/checklist : -------------------------------------------------------------------------= --- ** There are 9 instances of too long lines in the document, the longest o= ne being 20 characters in excess of 72. =3D=3D There are 4 instances of lines with non-RFC2606-compliant FQDNs in= the document. =3D=3D There are 4 instances of lines with non-RFC5735-compliant IPv4 add= resses in the document. If these are example addresses, they should be chang= ed. Miscellaneous warnings: -------------------------------------------------------------------------= --- =3D=3D The document seems to contain a disclaimer for pre-RFC5378 work, b= ut was first submitted on or after 10 November 2008. The disclaimer is usual= ly necessary only for documents that revise or obsolete older RFCs, and t= hat take significant amounts of text from those RFCs. If you can contact = all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at http://trustee.ietf.org/license-info for more information.) Checking references for intended status: Informational -------------------------------------------------------------------------= --- =3D=3D Missing Reference: 'RFC XXXX' is mentioned on line 1667, but not d= efined -- Looks like a reference, but probably isn't: '3' on line 1948 =3D=3D Unused Reference: 'RFC2976' is defined on line 2065, but no explic= it reference was found in the text =3D=3D Unused Reference: 'RFC3262' is defined on line 2068, but no explic= it reference was found in the text =3D=3D Unused Reference: 'RFC3311' is defined on line 2075, but no explic= it reference was found in the text =3D=3D Unused Reference: 'RFC3428' is defined on line 2081, but no explic= it reference was found in the text =3D=3D Unused Reference: 'RFC3903' is defined on line 2093, but no explic= it reference was found in the text ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) -- Obsolete informational reference (is this intentional?): RFC 2976 (Obsoleted by RFC 6086) -- Obsolete informational reference (is this intentional?): RFC 3265 (Obsoleted by RFC 6665) Summary: 2 errors (**), 0 flaws (~~), 9 warnings (=3D=3D), 3 comments = (--). Run idnits with the --verbose option for more detailed information abo= ut the items above. While I apologize for not catching these issues earlier, it really is the r= esponsibility of authors to check idnits (beyond what the submission tool r= equires) for their documents. I routinely run idnits before I submit a doc= ument as it can also save time when fixing the nits that the submission to= ol catches: https://tools.ietf.org/tools/idnits/ Regards, Mary. On Tue, Jan 7, 2014 at 12:35 AM, > wrote: Hi Mary, Now a new revision is available. Thank you and Best Regards Roland Von: Mary Barnes [mailto:mary.ietf.barnes@gmail.com] Gesendet: Montag, 6. Januar 2014 20:00 An: Jesske, Roland Cc: DISPATCH; Gonzalo Camarillo; Atle Monrad; Dean Willis Betreff: Re: PROTO Review: draft-drage-sipping-rfc3455bis-09.txt Hi Roland, One final editorial nit below. If you can spin a revision, then I'll send = the PROTO write-up to the AD. Thanks, Mary. On Thu, Jan 2, 2014 at 3:29 AM, > wrote: Hi Mary, I wish you a happy new year 2014. And the best for the next year. I was looking again on my changes I made due to your proposal in December. I realized that if I change the SHOULD to MUST we have now a backward compa= tibility problem. We are using the P-Associated-URI also over the IMS user interface which is= not encrypted. So I propose to add some more words. ... Section 6.1 ... An eavesdropper could possibly collect the list of identities a= user is registered. This can have privacy implications. To mitigate this problem, this e= xtension SHOULD only be used in a secured environment, where encryption of SIP messa= ges is provided either end-to-end or hop-by-hop. Since the P-Associated-URI header field value allows to implicitl= y register a bundle of URIs with one REGISTER Message the impact of security usi= ng the P-Associated-URI header field is not higher than using single REGISTER messages when registering all identities explic= it. [MB] I just have some editorial suggestions for the above: NEW: While the P-Associated-URI header field value allows the implicit regis= tration of a bundle of URIs with one REGISTER Message the impact of security usi= ng the P-Associated-URI header field is no higher than using separate REGISTER messages for each of the URIs. [/MB] For the P-Called-Party-Id the change should be also done like as follows: An eavesdropper could possibly collect the list of identities a = user is registered. This can have privacy implications. To mitigate this problem, this = extension SHOULD only be used in a secured environment, where encryption of SIP messa= ges is provided either end-to-end or hop-by-hop. Normally within a 3GPP environment the P-Called-Party-ID is not = sent towards end users but may be exchanged between carriers where other se= curity mechanisms than SIP encryption are used. Sorry coming so late. If this is OK for you I will include it to a new version. Thank you and Best Regards Roland Von: Mary Barnes [mailto:mary.ietf.barnes@gmail.com] Gesendet: Freitag, 27. Dezember 2013 19:45 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 making these changes. I finally had a chance to review this upda= ted 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 "potentia= lly 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 th= e next paragraph that provides details of the impacts. I think you could p= robably 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" tha= t makes this header not of particular concern with regards to security. Doe= s it reveal additional, unique information about an individual that isn't a= vailable 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 reg= istered. This can have privacy implications. To mitigate this problem, th= is extension MUST only be used in a secured environment, where encryption o= f 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 revis= ion. And, I believe you still need to identify privacy/security implicatio= ns 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 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_058CE00BD4D6B94FAD033A2439EA1E4B01DF8EC99D57HE113667eme_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Thank you Marry,

for doing all this review.

= So I have now put out the errors.

=

There are still some unused refere= nces which are in our informal reference section. But useful for the reader= to know they exist.

There are also some warnings with regard to IP addresses and wron= g FQDNs which I think is some interpretation of strings in the text which a= re not meant to be a IP address or FQDN at all.

 

Detail see below.

 

So now hopefully everything is ready for the n= ext step.

 

Best Rega= rds

&nbs= p;

Roland

 

tmp/draft-drage-sipping-rfc3455bis-12.txt:

 

=A0 http://trustee.ietf.org/license-in= fo):

=A0 ---------------------------= -------------------------------------------------

 

=A0=A0=A0=A0 = No issues found here.

 

=A0 Checking nits according to http://www.= ietf.org/id-info/1id-guidelines.txt:

=A0 ----------------------------------------------------------------------= ------

 

=A0=A0=A0=A0 No issues found here.

=

 

=A0 Checkin= g nits according to http://www.ietf.org/id-info/checklist :

=A0 -----------------------------------------------= -----------------------------

&= nbsp;

=A0=3D=3D There are 4 instances of= lines with non-RFC2606-compliant FQDNs in the

=A0=A0=A0=A0 document.

 

=A0 =3D=3D There are 4 instance= s of lines with non-RFC5735-compliant IPv4 addresses

<= p class=3DMsoNormal>=A0=A0=A0=A0 in the document.=A0 If these are example addr= esses, they should be changed.

=  

 

=A0 Miscellaneous warnings:

=A0 -------------------------------------------------------------------= ---------

 

=A0=A0=A0=A0 No issues found here.

 

=A0 Checki= ng references for intended status: Informational

=A0 ----------------------------------------------------------= ------------------

 =

=A0 =3D=3D Missing Reference: 'RFC XXXX' is me= ntioned on line 1662, but not defined

=A0 -- Looks like a referen= ce, but probably isn't: '3' on line 1943

 

=A0 =3D=3D Unused Refere= nce: 'RFC3262' is defined on line 2068, but no explicit

=A0=A0=A0=A0 reference was found in the text=

 

= =A0 =3D=3D Unused Reference: 'RFC3311' is defined on line 2072, but no expl= icit

=A0=A0=A0=A0 reference was foun= d in the text

 

=A0 =3D=3D Unused Reference: 'RFC3428' is defined o= n line 2078, but no explicit

=A0=A0= =A0=A0 reference was found in the text

=A0 =3D=3D Unused Referenc= e: 'RFC3903' is defined on line 2090, but no explicit

=

=A0=A0=A0=A0 reference was found in the text

 

= =A0 =3D=3D Unused Reference: 'RFC6086' is defined on line 2101, but no expl= icit

=A0=A0=A0=A0 reference was foun= d in the text

 

 

=A0= =A0=A0=A0 Summary: 0 errors (**), 0 flaws (~~), 8 warnings (=3D=3D), 1 comm= ent (--).

 

=A0=A0=A0=A0 Run idnits with the --verbose option for m= ore detailed information about

=A0= =A0=A0=A0 the items above.

-------------------------------= -------------------------------------------------

 

 

 = ;

Von: Mary Barnes [mailto:mary= .ietf.barnes@gmail.com]
Gesendet: Dienstag, 7. Januar 2014 18:55=
An: Jesske, Roland
Cc: DISPATCH; Gonzalo Camarillo; At= le Monrad; Dean Willis
Betreff: Re: PROTO Review: draft-drage-sip= ping-rfc3455bis-09.txt

 

Thanks Roland.  I have revi= ewed that version and all the changes I suggested have been made.  How= ever, in doing the PROTO write-up I realized that I wasn't certain anyone h= ad reviewed the ABNF. So, I ran the ABNF through Bill Fenner's tool: <= o:p>

 

And, there are a couple things that need to be fixed:

1)  DOT needs to change to "= ;." (we had this same bug in RFC 4244):

transit-ioi-indexed-value =3D tr= ansit-ioi-name DOT transit-ioi-index

 

= 2)  There's an extra space here (between * and parenthesis):

transit-ioi= -name=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D ALPHA * (ALPHA / DIGIT)<= o:p>

NEw: = transit-ioi-name=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D = ALPHA *(ALPHA / DIGIT)

 

There are also= a number of long lines in the ABNF that should be fixed. <= /p>

 

In addition, IDNITS identifies other errors and warnings per t= he following.  Those should also be addressed including considering wh= ether obsolete references need changing:

 
idnits 2.13=
.01 
 
tmp/draft-drage-sipping-rf=
c3455bis-11.txt:
 
=A0 Checking b=
oilerplate required by RFC 5378 and the IETF Trust (see
=A0 http://trustee.ietf.org/license-info):=

=A0 --------------------------------=
--------------------------------------------
 
=A0=A0=A0=A0 No issues found here.
 
=A0 Checking nits according to http://www.ietf.org/id-info/1id-guidelines=
.txt:
=A0 -----=
-----------------------------------------------------------------------
 
=A0=A0=A0=A0 No issues found here.=

 <=
/span>
=A0 Checking nits according to=
 http://www.ietf.org/id-i=
nfo/checklist :
=A0 ----------------------------------------------------------------------=
------
 <=
/o:p>
=A0 ** There are 9 insta=
nces of too long lines in the document, the longest one
=A0=A0=A0=A0 being 20 characters in ex=
cess of 72.
&n=
bsp;
=A0 =3D=3D There ar=
e 4 instances of lines with non-RFC2606-compliant FQDNs in the
=A0=A0=A0=A0 document.
 
=A0 =3D=3D There are 4 instances of lin=
es with non-RFC5735-compliant IPv4 addresses
=A0=A0=A0=A0 in the document.=A0 If these are exa=
mple addresses, they should be changed.
 
 
=A0=
 Miscellaneous warnings:
=A0 -----------------------------------------------------------------=
-----------
&n=
bsp;
=A0 =3D=3D The docu=
ment seems to contain a disclaimer for pre-RFC5378 work, but was=

=A0=A0=A0=A0 first submitted =
on or after 10 November 2008.=A0 The disclaimer is usually
=A0=A0=A0=A0 necessary only for doc=
uments that revise or obsolete older RFCs, and that
=

=A0=A0=A0=A0 take significant amounts of t=
ext from those RFCs.=A0 If you can contact all
=
=A0=A0=A0=A0 authors of the source material and=
 they are willing to grant the BCP78
=A0=A0=A0=A0 rights to the IETF Trust, you can and should=
 remove the disclaimer. 
=A0=A0=A0=A0=A0Otherwise, the disclaimer is needed and you can ignore=
 this comment. 
=A0=
=A0=A0=A0=A0(See the Legal Provisions document at
=A0=A0=A0=A0 http://trustee.ietf.org/license-info for more informa=
tion.)
 <=
/o:p>
 =

=A0 Checking references for intended=
 status: Informational
=A0 -------------------------------------------------------------------=
---------
&nbs=
p;
=A0 =3D=3D Missing Re=
ference: 'RFC XXXX' is mentioned on line 1667, but not defined
 
<=
pre>=A0 -- Looks like a reference, but probably=
 isn't: '3' on line 1948
 
=A0 =
=3D=3D Unused Reference: 'RFC2976' is defined on line 2065, but no explicit=

=A0=A0=A0=A0 refer=
ence was found in the text
 
=A0 =
=3D=3D Unused Reference: 'RFC3262' is defined on line 2068, but no explicit=

=A0=A0=A0=A0 refer=
ence was found in the text
 
=A0 =
=3D=3D Unused Reference: 'RFC3311' is defined on line 2075, but no explicit=

=A0=A0=A0=A0 refer=
ence was found in the text
 
=A0 =
=3D=3D Unused Reference: 'RFC3428' is defined on line 2081, but no explicit=

=A0=A0=A0=A0 refer=
ence was found in the text
 
=A0 =
=3D=3D Unused Reference: 'RFC3903' is defined on line 2093, but no explicit=

=A0=A0=A0=A0 refer=
ence was found in the text
 
=A0 =
** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234)
 
=A0 -- Obsolete informational reference =
(is this intentional?): RFC 2976
=A0=A0=A0=A0 (Obsoleted by RFC 6086)
<=
pre> 
=A0 -- Obsolete informational reference (is this intent=
ional?): RFC 3265
=
=A0=A0=A0=A0 (Obsoleted by RFC 6665)
 
 
=A0=A0=
=A0=A0 Summary: 2 errors (**), 0 flaws (~~), 9 warnings (=3D=3D), 3 comment=
s (--).
 =

=A0=A0=A0=A0 Run idnits=
 with the --verbose option for more detailed information about
=A0=A0=A0=A0 the items above.

While I apologize for= not catching these issues earlier, it really is the responsibility of auth= ors to check idnits (beyond what the submission tool requires) for their do= cuments.  I routinely run idnits before I submit a document as it can = also save time when fixing the  nits that the submission tool catches:=   https://tools= .ietf.org/tools/idnits/

<= o:p> 

Regards,

=

Mary. 

 

&n= bsp;

 

On Tue, Jan 7, 2014 = at 12:35 AM, <R= .Jesske@telekom.de> wrote:

Hi Mary,

Now a ne= w revision is available.

 

Thank you and Bes= t Regards

 

Roland

<= span lang=3DEN-US style=3D'font-size:11.0pt;font-family:"Calibri","sans-ser= if";color:#1F497D'> 

Von: Mary Barnes [mailto:mary.ietf.barnes@gmail.com]
Gese= ndet: Montag, 6. Januar 2014 20:00


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

=

 

Hi Roland,

=

 

One final editorial nit below= .  If you can spin a revision, then I'll send the PROTO write-up to th= e AD.

 

Thanks,

Mary. 

<= div>

 

On Thu, Jan 2, 2014 at 3:29 AM, <<= a href=3D"mailto:R.Jesske@telekom.de" target=3D"_blank">R.Jesske@telekom.de= > wrote:

Hi Mary,=

I wish you a happy new yea= r 2014. And the best for the next year.

 

I was l= ooking again on my changes I made due to your proposal in December.<= o:p>

I realized that if I change the SH= OULD to MUST we have now a backward compatibility problem.

We are using the P-Associated-URI also over= the IMS user interface which is not encrypted.

So I propose to add some more words.=

…

Section 6.1

= 230;

         <t>An eavesdropper could possibly collect = the list of identities a user is registered. 

&nbs= p;      This can have privacy implications. T= o mitigate this problem, this extension SHOULD

<= p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:= auto;text-autospace:none'>&nb= sp;      only be used in a secured environmen= t, where encryption of SIP messages is

 &nbs= p;     provided either end-to-end or hop-by-hop.&n= bsp; </t<= /span>>

 &nbs= p;

      <t> Since the P-Associated-URI header field value allows= to implicitly register

     &= nbsp;a bundle of URIs with one REGISTER Message the impact of security usin= g the P-Associated-URI header field is not higher than 

  &n= bsp;   using single REGISTER messages when registering all i= dentities explicit.</t>

[MB] I just have some editorial suggestions fo= r the above:

NEW:  

<t> While the P-Associated-URI header = field value allows the implicit registration of 

=

      a bundle of U= RIs with one REGISTER Message the impact of security using the P-Associated= -URI header field is no higher than 

      using separate REGISTER m= essages for each of the URIs. </<= span style=3D'color:maroon'>t><= /span>

[/MB]

 

 

 

 

For the P-Ca= lled-Party-Id the change should be also done like as follows:

 

        <t>An eavesdropper could possibly collect the list of identities a= user is registered. 

    &nbs= p;  This can have privacy implications.  To mitigate this pr= oblem, this extension SHOULD

   &nb= sp;   only be used in a secured environment, where encryptio= n of SIP messages is

       provid= ed either end-to-end or hop-by-hop.  </t>=

 =

        <= ;t>= ;Normally within a 3GPP environment the P-Called-Party-ID is not sen= t towards end users but may be exchanged between carriers where other secur= ity mechanisms than SIP encryption are used.  </t>

 

Sorry coming so late.

If this is OK for you I will include= it to a new version.

 

Thank you and Best = Regards

 <= /o:p>

Roland

 

Von: Mary B= arnes [mailto:mary.ietf.barnes@gmail.com]
Gesendet: Freitag, 27. Dezemb= er 2013 19:45


An: Jesske, = Roland
Cc: DISPATCH; Gonzalo Camarillo; Atle Monrad; Dean Willis<= br>Betreff: Re: PROTO Review: draft-drage-sipping-rfc3455bis-09.txt<= o:p>

 

=

Hi Roland,

 

Thanks for making these changes. I finally had a chance to review t= his updated version.   I still have a couple comments on the security = section as I think you will get questions during SEC review around this unl= ess 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.  Wh=
at is meant by "potentially annoying"  for example?  
 [=
RJ] I do not know. This is original text. So I deleted the words.
-<=
/o:p>
[MB] So, you removed =
that part of the sentence and are left with:
"This attack should not have any significant impacts."<=
o:p>
 
= 
 
I don't think that adds any value a=
nd just begs the question "what are the insignificant impacts and are =
there any privacy concerns"?  Really, it's the next paragraph tha=
t 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 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.  Also, the 2nd par=
agraph needs some work - maybe something like:

 
&n=
bsp;
OLD:
 
 
An eavesd=
ropper may collect the list of identities a user is registered.  This =
may have privacy implications.  To mitigate this problem, this extensi=
on SHOULD only be used in a secured environment, where encryption of SIP me=
ssages is provided either end-to-end or

 
 
hop-by-hop. <=
/o:p>
NEW: 
 
An eavesdropper=
 could possibly collect the list of identities a user is registered.  =
This can have privacy implications.  To mitigate this problem, this ex=
tension 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 sugges=
ted change for the first sentence didn't get into the revision.  And, =
I believe you still need to identify privacy/security implications by addre=
ssing whether or not this header reveals any unique information about an in=
dividual that isn't available in other headers.   [/MB]
 
 
 
 

 

 

=

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

Hi Mary,

Thank you for your comments and proposals.

<= p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:= auto'>I have now included all comments and uploaded a n= ew version.

So we can now p= roceed.

 <= o:p>

Thank you and Best Regards<= o:p>

 

Roland

 

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

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

 =

Filename:   draft-drage-sipp= ing-rfc3455bis

Revision: &n= bsp; 10

Title:  &= nbsp;         Private Header (P-Hea= der) Extensions to the Session Initiation Protocol (SIP) for the 3rd-Genera= tion Partnership Project (3GPP)

Creation date:    2013-12-03

<= span lang=3DEN-US>Group:        &nb= sp;   Individual Submission

Number of pages: 46

URL:&n= bsp;            http://www.ietf.org/inte= rnet-drafts/draft-drage-sipping-rfc3455bis-10.txt

=

Status:       &nbs= p;  http://datatracker.iet= f.org/doc/draft-drage-sipping-rfc3455bis

Htmlized:        http://tools.ietf.org/html/draft-drage-sipp= ing-rfc3455bis-10

Diff: = ;           http://www.ietf.org/rfcdiff?url2=3Ddra= ft-drage-sipping-rfc3455bis-10

 

Abstract:=

   This document describes a= set of private Session Initiation Protocol

   (SIP) header fields (P-headers) used by the 3rd-Ge= neration

   Partnershi= p 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 cha= rging and information about the networks a call

   traverses.

 =

 

<= span lang=3DEN-US style=3D'font-size:11.0pt;font-family:"Calibri","sans-ser= if";color:#1F497D'> 

Von:= Mar= y Barnes [mailto:mary.ietf.barnes@gmail.com]
Gesendet: Montag, 25. Nove= mber 2013 23:01


An: Jesske, Rol= and
Cc: DISPATCH; Gonzalo Camarillo; Atle Monrad; Dean Willis

Betreff: Re: PROTO Review: draft-drage-sippi= ng-rfc3455bis-09.txt

 =

Hi Roland,

 

<= /div>

Thanks for your response.  Additional comments below = [MB].

 

Thanks,

Mary.

&= nbsp;

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

Hi Mary,

Thank you for your review.

I have added now your proposals= to the draft.

Other commen= ts please see below.

&nbs= p;

I hope now everything is= OK.

 

Thank you and Best Regards

 

<= span lang=3DEN-US style=3D'font-size:11.0pt;font-family:"Calibri","sans-ser= if";color:#1F497D'>Roland

 

Von: Mary Barnes [mailto:<= a href=3D"mailto:mary.ietf.barnes@gmail.com" target=3D"_blank">mary.ietf.ba= rnes@gmail.com]
Gesendet: Dienstag, 29. Oktober 2013 17:27An: Jesske, Roland
Cc: DISPATCH; Gonzalo Camarillo; Atle= Monrad; Dean Willis
Betreff: PROTO Review: draft-drage-sipping-r= fc3455bis-09.txt

 

In preparation for the PROTO write-up, I have reviewed the do= cument 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 be= en introduced in the -09 and many of my -08 comments remain - I've separate= d comments from nits below.  A number of these comments are with regar= ds 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 IE= SG that will be reviewing this document, so they won't have the same contex= t of the IESG that approved RFC 3455.  I will note that I also have no= t validated the content of section 9 against a diff of this document and RF= C 3455.  I will need to do that before I progress the document unless = the authors can point me to another review that has done that.

 

Regards,

Mary.

 <= /p>

Summary:  This document needs some wor= k prior to being progressed. 

 

Comments:

--------= --------

- Section 1.  I think you sho= uld be explicit that these extensions apply only to a private network - say= ing they are "generally not applicable" is too soft, so I would s= uggest some minor rewording something like:

OLD:

   The SIP extensions specified in this document mak=
e certain
 
   ass=
umptions regarding network topology, linkage between SIP and lower
   layers, and the availability of transitive trust.=
  These assumptions
   are generally NO=
T APPLICABLE in the Internet as a whole. 
 
=

NEW: 

 
   The S=
IP extensions specified in this document make certain
=
   assumptions regarding network topology, linkage between SIP an=
d lower
   layers, and the availability of t=
ransitive trust.  These assumptions
   =
apply only to private networks and are not appropriate for use in an I=
nternet environment.
 
 
 
 
- Section 3. &=
nbsp;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 t=
o model this after the text in more recent 3GPP P-header documents, referri=
ng to the SIP change process. 
&nbs=
p;
[RJ] OK, I have ch=
anged the text:

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

&nb= sp;    the protocol used to establish and tear down multimed= ia sessions in the

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

     the IMS, a detailed descr= iption can be found in 3GPP TS 23.228 . This document is an update of RFC34= 55   which covers the requirements in RFC4083 and describes updat= es and adds private extensions to address those requirements which are need= ed in for 3GPP Release 11. Each extension, or set of related extensions is = described in its own section below

<= /div>

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

 

<= span lang=3DEN-US style=3D'font-size:11.0pt;font-family:"Calibri","sans-ser= if";color:#1F497D'>    The Third Generation Partnership Project (= 3GPP) uses SIP as

 &nb= sp;   the protocol  to establish and tear down multimedia se= ssions in the

  &= nbsp;  context of its IP Multimedia Subsystem (IMS), as described in&n= bsp;

     th= e 3GPP TS 23.228 specification. 

     RFC 3455 defines SIP private header extensio= ns (referred to as P-headers) which are 

<= span lang=3DEN-US style=3D'font-size:11.0pt;font-family:"Calibri","sans-ser= if";color:#1F497D'>     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 upd= ates existing P-header descriptions 

     to address additional requirements= which are needed for 3GPP Release 11. 

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F= 497D'>     Each of the P-headers is described in the section= s below.

 

=

[/MB] 

 

- Section 4.1. "registered ad=
dress-of-record" -> "registered SIP address-of-record"
- Section 4.1, 3rd paragraph.  "No=
te that, generally speaking," -> "Note that in standard SIP us=
age [RFC3261]"
- Section 4.1.2.3. &nb=
sp;I don't think this is stated properly.  I think the intent is that =
this header is not applicable to proxies, therefore the proxy MUST relay th=
e header field unchanged.  I would suggest rewording something like:
OLD: 
   This memo does not define any proce=
dure at the proxy.  The proxy does
   n=
ot add, read, modify or delete the header field, and therefore any
   proxy will relay this header field unchanged.
 
NEW:
 
 &=
nbsp; This header is not intended to be used by proxies - a proxy does=

   not add, read, modify or delete the header fi=
eld, and therefore any
   proxy MUST relay t=
his header field unchanged.
 
 
 
 
Section 4.2, 1st paragr=
aph.  The behavior in this sentence is not normative from a SIP protoc=
ol perspective, thus MAY is not appropriate.  I suggest the MAY be cha=
nged to "can".   
   The UAS MAY use the=
 information to render different distinctive audiovisual alerting
   tones, depending on the URI used to receive the in=
vitation to the
   session.
=

Section 4.2.2.2, 2nd paragraph.  The behavior =
in this sentence is not normative from a SIP protocol perspective, thus &nb=
sp;I suggest the MAY be changed to "can". =

 
- Section 4.3.3, last paragraph=
.  I think this ought to be a MUST: "The identifier should be glo=
bally unique.." 
 
- Section 4.3.2.1.  This text has changed from the -08. &=
nbsp; I don't know what a "normal User Equipment" is and the term=
 "User Equipment" is not defined in this specification.  I t=
hink it would be better to say something like. However, even with this prop=
osed 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 the REGISTER.  Therefore us=
er agent clients
   do not insert a P-Visite=
d-Network-ID header field in any SIP message.
 
 
<=
pre> 
NEW: 
   In the context of the network to which the header fields defi=
ned in this document apply, a User Agent has no knowledge of the P-Vis=
ited-Network-ID when sending the REGISTER request.  Therefore user age=
nt clients MUST NOT insert a P-Visited-Network-ID header field in=
 any SIP message.
 
- S=
ection 4.3.2.2:, 2nd parag=
raph:  "home network MAY use" -> "home network can u=
se"

 
&n=
bsp;
 
 
- Section 4.3.2.2, last paragraph:  <=
/span>
 
 
OLD: Note that a received P-Visit=
ed-Network-ID from a UA is a failure case and must be deleted.
 
NEW:  <=
/span>Note that a received P-Visited-Network-ID from a UA is a failure case=
 and MUST be deleted when the request is forwarded. 
 
<=
pre>Section =
4.4.2.1, 2nd paragraph:  "MUST trust the proxy" -> "=
MUST have a trust relationship with the proxy" =

 <=
/o:p>
Section 4.4.2.1, 3rd paragraph:  "there must also be a transi=
tive trust" ->  "there MUST also be a transitive trust&qu=
ot; 
Section 4.4.2.2, 2=
nd paragraph: "MAY act upon any information present" -> "=
can act upon any information present",  "MAY use the call id=
" -> "can use the call id" 
Secti=
on 4.5.2: 2nd paragraph: "MAY use the hostnames" -> "can =
use the hostnames" 
 
 
 =
;
Sec=
tion 4.5.2.1 2nd paragraph: "MAY use the contents" -> "ca=
n 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 edit=
orial work.  Maybe the following change would work: <=
/o:p>
 
=
 
OLD:
 
   Depending on the call =
scenario it is needed to add for each transit
 &n=
bsp; network either a transit network name or a void value.  Neverthel=
ess
   it can not be guaranteed that all val=
ues will appear within the P-Charging-Vector header field. =

 
 =
;
NEW=
: 
 
&nb=
sp;  Depending on the call scenario, each transit network can add eith=
er a transit network name or a void    value.  How=
ever, it can not be guaranteed that all the values that are added will appe=
ar within the P-Charging-Vector header field.
 
- Section 4.6.3, next to last paragr=
aph: "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 y= ou talking about limits on the number of entries or are you suggesting that= the number of void values must be considered when setting the index for th= e 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 incremented by =
the number of void entries +1.
 
- Section 4.6.=
4.2: I don't know what this means:  "A deletion=
 of the elements could appear depending on the network policy and trust rul=
es".  Is =
it just trying to say that along with the adding and modifying in the previ=
ous 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

       &nbs= p;   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

   &nb=
sp;       also valid by replacing the transit=
-ioi with a void value.
 <=
/pre>
 
 
 
 
 
- Section 5.7. De=
lete this text and table.   We aren't these tables anymore as they rea=
lly don't provide any useful information.  You just need to verbally s=
tate 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, MESS=
AGE methods and all responses, P-Visited-Network-ID can appear in all SIP m=
ethods 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-Add=
resses can appear in all SIP methods exept ACK and CANCEL.

[MB] I su= ggest you put each of these in separate sentences - i.e., rather than use c= omma separators, use a period.  You should also spell out that these a= re 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 "potentially annoying"  for example=
?  
 
<= /div>
[RJ] I do not know. This is original text. So=
 I deleted the words.
 
- Section 6.2: I think you need to b=
e more specific about the "nature" that makes this header not of =
particular concern with regards to security. Does it reveal additional, uni=
que information about an individual that isn't available in other headers. =
 Also, the 2nd paragraph needs some work - maybe something like:
 
OLD:
An eavesd=
ropper may collect the list of identities a user is registered.  This =
may have privacy implications.  To mitigate this problem, this extensi=
on SHOULD only be used in a secured environment, where encryption of SIP me=
ssages is provided either end-to-end or

&=
nbsp;
 
 
 
hop-by-hop. 
   
 
NEW: 
 =

 An eavesdropper could possibly collect the lis=
t of identities a user is registered.  This can have privacy implicati=
ons.  To mitigate this problem, this extension MUST only be used in a =
secured environment, where encryption of SIP messages is provided either en=
d-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 i= dentities a user has registered."

or  "An eavesdropper could possi= bly collect the list of identities registered by a user." =

[/MB] <= /span> 

- Section 6.4, 
--3rd paragraph: "should not" -> "MUS=
T NOT" 
 
-- 7th paragraph:  "SHOULD NOT be sent" -> "MUST=
 NOT be sent" 
 
 
 
 
 
<=
span style=3D'font-family:"Arial","sans-serif"'>-- 8th paragraph: "SHO=
ULD NOT send sensitive information" -> "MUST NOT send sensitiv=
e information"
 
 
-- 9th paragraph: "is required to de=
lete" -> "is REQUIRED to delete" <=
/pre>
 
-- 10th paragraph:  How doe=
s a network ensure the information is not of a sensitive nature?   I w=
ould think that the information just should not be sent outside of the trus=
t 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 wel=
l how to behave.
&nbs=
p;
-- 11th paragraph: So, wha=
t 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.
= 
 

        <t= >A proxy receiving a message containing the P-Access-Network-Info=

  &= nbsp;    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.</t>
 
- Section 9, =
item 2.  I think you need to add this text with regards to the recomme=
ndation to use RFC 4244 (bis) to the body of this document and include a re=
al reference.
&nb=
sp;
[RJ] OK done. I l=
et the reference RFC4244 since 3GPP uses currently only RFC4244. 
Replaced following text:=

With section 9.2
       <t>Re=
quirements for a more general solution are proposed in <xref=

      &n=
bsp;  target=3D"RFC4244"></xref>. 3GPP will continu=
e to use the
  &n=
bsp;      P-Called-Party-ID header field even thou=
gh RFC 4244 <xref
&nbs=
p;        target=3D"RFC4244"&g=
t;</xref> has now been published.</t>
 
I think the text in Section 9.2 is better.
<= div>
Nits:
&nb=
sp;
 
 
 
- Section 4.1, 2nd paragraph.  "has associated t=
o an address-of-record" -> "has associated with an address-of-=
record"
- Section 4.1.2.2, 2nd paragraph, "In case" -> "If&=
quot;,  "shall not" -> SHALL NOT
<= pre style=3D'word-wrap:break-word;white-space:pre-wrap'>- 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 REGIS=
TRAR"
 
Section 4.2.2.1, 3rd paragraph:  "=
;there must also be a transitive trust" ->  "there MUST a=
lso be a transitive trust" 
 
Section 4.6, 2nd=
 paragraph: "includes, includes but is not limited to" -> &quo=
t;includes, but is not limited to," 
=
 
Section=
 4.6.2.2, 1st paragraph: "one ore more" -> "one or more&q=
uot; 
 
 
 

On Tue, Oct 8, 2013 at 11:58 AM, = <R.Jesske@telek= om.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 inform me.

From m= y side I would be happy to proceed the draft further towards publication.
Thank you and Best Regards

Roland


-----Urspr=FCngli= che Nachricht-----
Von: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
Gese= ndet: Dienstag, 8. Oktober 2013 13:40
An: Christer Holmberg; Keith Drage= ; Jesske, Roland
Betreff: New Version Notification for draft-drage-sippi= ng-rfc3455bis-09.txt


A new version of I-D, draft-drage-sipping-r= fc3455bis-09.txt
has been successfully submitted by Keith Drage and post= ed to the IETF repository.

Filename:        draf= t-drage-sipping-rfc3455bis
Revision:        09
Ti= tle:           Private Header (P-Header) Extension= s to the Session Initiation Protocol (SIP) for the 3rd-Generation Partnersh= ip Project (3GPP)
Creation date:   2013-10-08
Group:   &nbs= p;       Individual Submission
Number of pages: 47
URL= :             ht= tp://www.ietf.org/internet-drafts/draft-drage-sipping-rfc3455bis-09.txt=
Status:          http://data= tracker.ietf.org/doc/draft-drage-sipping-rfc3455bis
Htmlized:  =      http://tools.ietf.org/html/draft-drage= -sipping-rfc3455bis-09
Diff:           &nbs= p;http://www.ietf.org/rfcdiff?url2=3Ddraft-drage-si= pping-rfc3455bis-09

Abstract:
   This document desc= ribes a set of private Session Initiation Protocol
   (SIP) he= ader fields (P-headers) used by the 3rd-Generation
   Partners= hip 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 partners us= e,
   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 ver= sion and diff are available at tools.ietf.org.

The IETF Secretariat

  -

<= p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:= auto'> 

 

 

 

= --_000_058CE00BD4D6B94FAD033A2439EA1E4B01DF8EC99D57HE113667eme_-- From ibc@aliax.net Wed Jan 8 01:06:51 2014 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 E51351AE07E for ; Wed, 8 Jan 2014 01:06:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] 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 hBxq_clNI_00 for ; Wed, 8 Jan 2014 01:06:50 -0800 (PST) Received: from mail-qe0-f49.google.com (mail-qe0-f49.google.com [209.85.128.49]) by ietfa.amsl.com (Postfix) with ESMTP id 4FDD01AE048 for ; Wed, 8 Jan 2014 01:06:50 -0800 (PST) Received: by mail-qe0-f49.google.com with SMTP id w7so1457463qeb.22 for ; Wed, 08 Jan 2014 01:06:41 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=hTb0STpKJQaVI0l3GaIalIlVAakW52p/sQ1z48r8HEc=; b=J16QK5aLMUbBZbvqPW69/B0Att1tQLaW9eS27r8V16u7G6/fUffhN5kUdGi3hlhlWW GB/mV2Hhy33Z5A8wC2Qr/wLhlaW3Y1Ddh74urSZ58xzvBVLn7UuqHLG72vhgAbCT/PKl lm32IHLMFMF1SIeVoLmfTPRsPp7y7JDEokY7tmzK+feHPJeFeL5KpGfzolDSkNL+5/xX s1x4NQfQMgyRCl4WOTboAog1+/uzMlyOO9sUWemMLeKLYzLyGspE9OWv9JA48WnBH+sL KS/yk7r4a0mZz5SNbQvtgj/O68J+t0T5LGhHviCW2MPLPSF5ynWZY8JqPYwUFvfF2EKP PGJg== X-Gm-Message-State: ALoCoQnvJv95l8TpE7R6QkYdF0WaYO+cdVNaii0I5Wrh9Esbi91r1rW39Pa3QxtaBr2/NNH6eR3V X-Received: by 10.229.71.5 with SMTP id f5mr197575288qcj.18.1389172000873; Wed, 08 Jan 2014 01:06:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.96.82.97 with HTTP; Wed, 8 Jan 2014 01:06:20 -0800 (PST) In-Reply-To: References: <20140102101042.27427.64547.idtracker@ietfa.amsl.com> <0BA14051-5C7F-4416-8CD2-413347D540D3@edvina.net> <52C83591.3080702@alum.mit.edu> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Wed, 8 Jan 2014 10:06:20 +0100 Message-ID: To: "Olle E. Johansson" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "dispatch@ietf.org list" Subject: Re: [dispatch] New Version Notification for draft-johansson-dispatch-dane-sip-00.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: Wed, 08 Jan 2014 09:06:52 -0000 2014/1/8 Olle E. Johansson : >> Honestly I've never understood the real difference between a domain >> and a hostname. Of course, IMHO, the SIP client should provide in the >> SNI the destination domain of the server it is attempting to connect >> to. > Right, but... > > Does anyone find this in any published document? Not AFAIK :) But in this case SIP should follow well proven mechanisms and rules of HTTP= (s). --=20 I=C3=B1aki Baz Castillo From oej@edvina.net Wed Jan 8 01:16:22 2014 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 66AF61AE043 for ; Wed, 8 Jan 2014 01:16:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.251 X-Spam-Level: X-Spam-Status: No, score=-1.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, 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 Q06sLFRcWWrv for ; Wed, 8 Jan 2014 01:16:21 -0800 (PST) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 5106C1ADF99 for ; Wed, 8 Jan 2014 01:16:21 -0800 (PST) Received: from [192.168.40.22] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id E4C3B93C2A1; Wed, 8 Jan 2014 09:16:11 +0000 (UTC) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: "Olle E. Johansson" In-Reply-To: Date: Wed, 8 Jan 2014 10:16:11 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <17645DB3-06D2-4E6A-8B1E-759EEA2B68C9@edvina.net> References: <20140102101042.27427.64547.idtracker@ietfa.amsl.com> <0BA14051-5C7F-4416-8CD2-413347D540D3@edvina.net> <52C83591.3080702@alum.mit.edu> To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= X-Mailer: Apple Mail (2.1827) Cc: "dispatch@ietf.org list" Subject: Re: [dispatch] New Version Notification for draft-johansson-dispatch-dane-sip-00.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: Wed, 08 Jan 2014 09:16:22 -0000 On 08 Jan 2014, at 10:06, I=F1aki Baz Castillo wrote: > 2014/1/8 Olle E. Johansson : >>> Honestly I've never understood the real difference between a domain >>> and a hostname. Of course, IMHO, the SIP client should provide in = the >>> SNI the destination domain of the server it is attempting to connect >>> to. >> Right, but... >>=20 >> Does anyone find this in any published document? >=20 > Not AFAIK :) > But in this case SIP should follow well proven mechanisms and rules of = HTTP(s). >=20 If so, that is what we need to write.=20 /O= From rifaat.ietf@gmail.com Wed Jan 8 05:23:12 2014 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 7F9161AE381 for ; Wed, 8 Jan 2014 05:23:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 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, MIME_8BIT_HEADER=0.3, 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 9wBwh0ZrHekl for ; Wed, 8 Jan 2014 05:23:10 -0800 (PST) Received: from mail-ee0-x229.google.com (mail-ee0-x229.google.com [IPv6:2a00:1450:4013:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id 9AFF91AE39B for ; Wed, 8 Jan 2014 05:23:10 -0800 (PST) Received: by mail-ee0-f41.google.com with SMTP id t10so684741eei.14 for ; Wed, 08 Jan 2014 05:23:01 -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=0+0KZSbUFdYqB/FhFI+ZQG4r7Fvh4SpEnOq1InOzx9Y=; b=HdbaShjJ40u5uCWXpZ6UpaACmEVT86wCyKqd/SP+Wgzk/IQtvhqLdFTIAn/p2qXvqe GNkhbRzYwWrN4fF1l+3xzXi0DSI27jMCmVeWVuKHXKT1sSAgDGLpkKmgRMT76CqG7XW9 qUnzDFZo7zzlP7Jw8mRpm4zLGs4YpgLeDtIF/e83e8M3iTRSf9wXk0RbHYh6rpDgksBB 3b0YDMDDAcOGf82cDpOvnvsryY2uVX2wq+hUELawESPyvsqxMaikKAEyKB55HKWayRW+ xXyyn8iHO8BZsWsTjKK6Erf2qIE83U0yP3fowLyM1rtdjTjCISXYSlhuuvVdn9c/4igI a2kg== MIME-Version: 1.0 X-Received: by 10.15.95.72 with SMTP id bc48mr46146308eeb.49.1389187381013; Wed, 08 Jan 2014 05:23:01 -0800 (PST) Received: by 10.14.53.78 with HTTP; Wed, 8 Jan 2014 05:23:00 -0800 (PST) In-Reply-To: References: <20140102101042.27427.64547.idtracker@ietfa.amsl.com> <0BA14051-5C7F-4416-8CD2-413347D540D3@edvina.net> <52C83591.3080702@alum.mit.edu> Date: Wed, 8 Jan 2014 08:23:00 -0500 Message-ID: From: Rifaat Shekh-Yusef To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=089e01681b345f2fcc04ef7564f2 Cc: "dispatch@ietf.org list" Subject: Re: [dispatch] New Version Notification for draft-johansson-dispatch-dane-sip-00.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: Wed, 08 Jan 2014 13:23:12 -0000 --089e01681b345f2fcc04ef7564f2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The following is a quote from RFC6066, Section 3: Currently, the only server names supported are DNS hostnames; however, this does not imply any dependency of TLS on DNS, and other name types may be added in the future (by an RFC that updates this document). Should a new name_type be defined for this purpose, instead of overloading the host_name type? Regards, Rifaat On Wed, Jan 8, 2014 at 4:06 AM, I=F1aki Baz Castillo wrote: > 2014/1/8 Olle E. Johansson : > >> Honestly I've never understood the real difference between a domain > >> and a hostname. Of course, IMHO, the SIP client should provide in the > >> SNI the destination domain of the server it is attempting to connect > >> to. > > Right, but... > > > > Does anyone find this in any published document? > > Not AFAIK :) > But in this case SIP should follow well proven mechanisms and rules of > HTTP(s). > > > -- > I=F1aki Baz Castillo > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --089e01681b345f2fcc04ef7564f2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
The following is a q= uote from RFC6066, Section 3:

   Currently, the only server names supported are DNS hostnames;
   however, this does not imply any dependency of TLS on DNS, and other
   name types may be added in the future (by an RFC that updates this
   document).

Should a new name_type be defi= ned for this purpose, instead of overloading the=A0host_name type?

=
Regards,
=A0Rifaat



On Wed, Jan 8, 2014 at = 4:06 AM, I=F1aki Baz Castillo <ibc@aliax.net> wrote:
2014/1/8 Olle E. Johansson <oej@edvina.net>:
>> Honestly I've never understood the real diff= erence between a domain
>> and a hostname. Of course, IMHO, the SIP client should provide in = the
>> SNI the destination domain of the server it is attempting to conne= ct
>> to.
> Right, but...
>
> Does anyone find this in any published document?

Not AFAIK :)
But in this case SIP should follow well proven mechanisms and rules of HTTP= (s).


--
I=F1aki Baz Castillo
<ibc@aliax.net>
_____________________________= __________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

--089e01681b345f2fcc04ef7564f2-- From pkyzivat@alum.mit.edu Wed Jan 8 07:47:58 2014 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 8C5FC1AD8EC for ; Wed, 8 Jan 2014 07:47:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.334 X-Spam-Level: X-Spam-Status: No, score=-0.334 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, GB_I_INVITATION=-2, J_CHICKENPOX_34=0.6, MANGLED_AVOID=2.3, NORMAL_HTTP_TO_IP=0.001, SPF_SOFTFAIL=0.665] 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 nCJX1m9GDFP7 for ; Wed, 8 Jan 2014 07:47:54 -0800 (PST) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:56]) by ietfa.amsl.com (Postfix) with ESMTP id 531221AD627 for ; Wed, 8 Jan 2014 07:47:54 -0800 (PST) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta06.westchester.pa.mail.comcast.net with comcast id BSqZ1n0011ZXKqc56Tnlp5; Wed, 08 Jan 2014 15:47:45 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta21.westchester.pa.mail.comcast.net with comcast id BTll1n0023ZTu2S3hTlljl; Wed, 08 Jan 2014 15:45:45 +0000 Message-ID: <52CD72A8.4050805@alum.mit.edu> Date: Wed, 08 Jan 2014 10:45:44 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: dispatch@ietf.org References: <058CE00BD4D6B94FAD033A2439EA1E4B01DEBB69CC8A@HE113667.emea1.cds.t-internal.com> <058CE00BD4D6B94FAD033A2439EA1E4B01DF27DB8A63@HE113667.emea1.cds.t-internal.com> <058CE00BD4D6B94FAD033A2439EA1E4B01DF8E83EB24@HE113667.emea1.cds.t-internal.com> <058CE00BD4D6B94FAD033A2439EA1E4B01DF8E83F451@HE113667.emea1.cds.t-internal.com> <058CE00BD4D6B94FAD033A2439EA1E4B01DF8EC99D57@HE113667.emea1.cds.t-internal.com> In-Reply-To: <058CE00BD4D6B94FAD033A2439EA1E4B01DF8EC99D57@HE113667.emea1.cds.t-internal.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1389196065; bh=FWn02C6XeyBS61egHdZgBRpHnbqD+07e5a/EkkofDE0=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=LOJOTY6S5U79chBJ1j4xZbkCWYvUD/D2EPxwukNA/t47Ql23twhSG6FDMl0/sIIs+ vNMeRwlHsRRDySBEgOpC0yJI5l85Y/r4YJiOAHt3isooF+qP0qrqFPnHI6EvzxxSFp 4wtiH74Y3Knxfa6Rc1gvqWB5iu+pDT36WMfV1JAIFx6mNZYouNBMQqo2xtf2BblMZl qDVpmwKFUEpfEcifymuLpv4vgnAQhb6bVOdHBlCDMfFLs+amRhYc0IUWelKa3fIpZB +6Zo0yKfXtq83duG483tGlQW7VFY0qMI1hPd6pXK7hx6sCh+tEUK/A8JsxBFhI9Ayj vuLvjeV6nIshA== 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: Wed, 08 Jan 2014 15:47:58 -0000 On 1/8/14 3:46 AM, R.Jesske@telekom.de wrote: > Thank you Marry, > > for doing all this review. > > So I have now put out the errors. > > There are still some unused references which are in our informal > reference section. But useful for the reader to know they exist. You could avoid the error by adding a bit of text that simply notes that these might provide useful context for the reader. Then the references will be referenced. Thanks, Paul > There are also some warnings with regard to IP addresses and wrong FQDNs > which I think is some interpretation of strings in the text which are > not meant to be a IP address or FQDN at all. > > Detail see below. > > So now hopefully everything is ready for the next step. > > Best Regards > > Roland > > tmp/draft-drage-sipping-rfc3455bis-12.txt: > > Checking boilerplate required by RFC 5378 and the IETF Trust (see > > http://trustee.ietf.org/license-info): > > > ---------------------------------------------------------------------------- > > No issues found here. > > Checking nits according to > http://www.ietf.org/id-info/1id-guidelines.txt: > > > ---------------------------------------------------------------------------- > > No issues found here. > > Checking nits according to http://www.ietf.org/id-info/checklist : > > > ---------------------------------------------------------------------------- > > == There are 4 instances of lines with non-RFC2606-compliant FQDNs in the > > document. > > == There are 4 instances of lines with non-RFC5735-compliant IPv4 > addresses > > in the document. If these are example addresses, they should be > changed. > > Miscellaneous warnings: > > > ---------------------------------------------------------------------------- > > No issues found here. > > Checking references for intended status: Informational > > > ---------------------------------------------------------------------------- > > == Missing Reference: 'RFC XXXX' is mentioned on line 1662, but not > defined > > -- Looks like a reference, but probably isn't: '3' on line 1943 > > == Unused Reference: 'RFC3262' is defined on line 2068, but no explicit > > reference was found in the text > > == Unused Reference: 'RFC3311' is defined on line 2072, but no explicit > > reference was found in the text > > == Unused Reference: 'RFC3428' is defined on line 2078, but no explicit > > reference was found in the text > > == Unused Reference: 'RFC3903' is defined on line 2090, but no explicit > > reference was found in the text > > == Unused Reference: 'RFC6086' is defined on line 2101, but no explicit > > reference was found in the text > > Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). > > Run idnits with the --verbose option for more detailed information > about > > the items above. > > -------------------------------------------------------------------------------- > > *Von:*Mary Barnes [mailto:mary.ietf.barnes@gmail.com] > *Gesendet:* Dienstag, 7. Januar 2014 18:55 > *An:* Jesske, Roland > *Cc:* DISPATCH; Gonzalo Camarillo; Atle Monrad; Dean Willis > *Betreff:* Re: PROTO Review: draft-drage-sipping-rfc3455bis-09.txt > > Thanks Roland. I have reviewed that version and all the changes I > suggested have been made. However, in doing the PROTO write-up I > realized that I wasn't certain anyone had reviewed the ABNF. So, I ran > the ABNF through Bill Fenner's tool: > > http://tools.ietf.org/tools/bap/abnf.cgi > > And, there are a couple things that need to be fixed: > > 1) DOT needs to change to "." (we had this same bug in RFC 4244): > > transit-ioi-indexed-value = transit-ioi-name DOT transit-ioi-index > > 2) There's an extra space here (between * and parenthesis): > > transit-ioi-name = ALPHA * (ALPHA / DIGIT) > > NEw: transit-ioi-name = ALPHA *(ALPHA / DIGIT) > > There are also a number of long lines in the ABNF that should be fixed. > > In addition, IDNITS identifies other errors and warnings per the > following. Those should also be addressed including considering whether > obsolete references need changing: > > > > idnits 2.13.01 > > > > tmp/draft-drage-sipping-rfc3455bis-11.txt: > > > > Checking boilerplate required by RFC 5378 and the IETF Trust (see > > http://trustee.ietf.org/license-info): > > ---------------------------------------------------------------------------- > > > > No issues found here. > > > > Checking nits according tohttp://www.ietf.org/id-info/1id-guidelines.txt: > > ---------------------------------------------------------------------------- > > > > No issues found here. > > > > Checking nits according tohttp://www.ietf.org/id-info/checklist : > > ---------------------------------------------------------------------------- > > > > ** There are 9 instances of too long lines in the document, the longest one > > being 20 characters in excess of 72. > > > > == There are 4 instances of lines with non-RFC2606-compliant FQDNs in the > > document. > > > > == There are 4 instances of lines with non-RFC5735-compliant IPv4 addresses > > in the document. If these are example addresses, they should be changed. > > > > > > Miscellaneous warnings: > > ---------------------------------------------------------------------------- > > > > == The document seems to contain a disclaimer for pre-RFC5378 work, but was > > first submitted on or after 10 November 2008. The disclaimer is usually > > necessary only for documents that revise or obsolete older RFCs, and that > > take significant amounts of text from those RFCs. If you can contact all > > authors of the source material and they are willing to grant the BCP78 > > rights to the IETF Trust, you can and should remove the disclaimer. > > Otherwise, the disclaimer is needed and you can ignore this comment. > > (See the Legal Provisions document at > > http://trustee.ietf.org/license-info for more information.) > > > > > > Checking references for intended status: Informational > > ---------------------------------------------------------------------------- > > > > == Missing Reference: 'RFC XXXX' is mentioned on line 1667, but not defined > > > > -- Looks like a reference, but probably isn't: '3' on line 1948 > > > > == Unused Reference: 'RFC2976' is defined on line 2065, but no explicit > > reference was found in the text > > > > == Unused Reference: 'RFC3262' is defined on line 2068, but no explicit > > reference was found in the text > > > > == Unused Reference: 'RFC3311' is defined on line 2075, but no explicit > > reference was found in the text > > > > == Unused Reference: 'RFC3428' is defined on line 2081, but no explicit > > reference was found in the text > > > > == Unused Reference: 'RFC3903' is defined on line 2093, but no explicit > > reference was found in the text > > > > ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) > > > > -- Obsolete informational reference (is this intentional?): RFC 2976 > > (Obsoleted by RFC 6086) > > > > -- Obsolete informational reference (is this intentional?): RFC 3265 > > (Obsoleted by RFC 6665) > > > > > > Summary: 2 errors (**), 0 flaws (~~), 9 warnings (==), 3 comments (--). > > > > Run idnits with the --verbose option for more detailed information about > > the items above. > > While I apologize for not catching these issues earlier, it really is > the responsibility of authors to check idnits (beyond what the > submission tool requires) for their documents. I routinely run idnits > before I submit a document as it can also save time when fixing the > nits that the submission tool catches: > https://tools.ietf.org/tools/idnits/ > > Regards, > > Mary. > > On Tue, Jan 7, 2014 at 12:35 AM, > wrote: > > Hi Mary, > > Now a new revision is available. > > Thank you and Best Regards > > Roland > > *Von:*Mary Barnes [mailto:mary.ietf.barnes@gmail.com > ] > *Gesendet:* Montag, 6. Januar 2014 20:00 > > > *An:* Jesske, Roland > *Cc:* DISPATCH; Gonzalo Camarillo; Atle Monrad; Dean Willis > *Betreff:* Re: PROTO Review: draft-drage-sipping-rfc3455bis-09.txt > > Hi Roland, > > One final editorial nit below. If you can spin a revision, then I'll > send the PROTO write-up to the AD. > > Thanks, > > Mary. > > On Thu, Jan 2, 2014 at 3:29 AM, > wrote: > > Hi Mary, > > I wish you a happy new year 2014. And the best for the next year. > > I was looking again on my changes I made due to your proposal in December. > > I realized that if I change the SHOULD to MUST we have now a backward > compatibility problem. > > We are using the P-Associated-URI also over the IMS user interface which > is not encrypted. > > So I propose to add some more words. > > … > > Section 6.1 > > … > > An eavesdropper could possibly collect the list of identities a user > is registered. > > This can 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. > > Since the P-Associated-URI header field value allows to implicitly > register > > a bundle of URIs with one REGISTER Message the impact of security > using the P-Associated-URI header field is not higher than > > using single REGISTER messages when registering all identities > explicit. > > [MB] I just have some editorial suggestions for the above: > > NEW: > > While the P-Associated-URI header field value allows the implicit > registration of > > a bundle of URIs with one REGISTER Message the impact of security > using the P-Associated-URI header field is no higher than > > using separate REGISTER messages for each of the URIs. > > [/MB] > > For the P-Called-Party-Id the change should be also done like as > follows: > > An eavesdropper could possibly collect the list of identities a > user is registered. > > This can 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. > > Normally within a 3GPP environment the P-Called-Party-ID is not > sent towards end users but may be exchanged between carriers where > other security mechanisms than SIP encryption are used. > > Sorry coming so late. > > If this is OK for you I will include it to a new version. > > Thank you and Best Regards > > Roland > > *Von:*Mary Barnes [mailto:mary.ietf.barnes@gmail.com > ] > *Gesendet:* Freitag, 27. Dezember 2013 19:45 > > > *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 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 (3GPP) > > 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=draft-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 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 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 will need to do > that before I progress the document unless the authors can point 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 Internet 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, referring 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 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 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 intent is that this header is not applicable to proxies, therefore the proxy MUST 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 the MAY be changed to "can". > > The UAS MAY use the information to render different distinctive audiovisual 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 normative 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 identifier 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. 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 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 insert a P-Visited-Network-ID header field in any SIP message. > > > > - Section4.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 trust 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 thecall id" > > Section 4.5.2: 2nd paragraph: "MAY use the hostnames" -> "can use the hostnames" > > > > > > > > Section 4.5.2.1 2nd 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. Maybe the following 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-Charging-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-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 suggesting 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 incremented by the number of void entries +1. > > > > - Section4.6.4.2 : I don't know what this means: "A deletion of the elements 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 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 verbally 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, 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 "potentially 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 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. > > [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 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 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 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 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-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 include 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="RFC4244">. 3GPP will continue to use the > > P-Called-Party-ID header field even though RFC 4244 > target="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" -> 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 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üngliche 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.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 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 (3GPP) > 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=draft-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 > > - > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From pkyzivat@alum.mit.edu Wed Jan 8 07:53:08 2014 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 EC7FB1AE4D2 for ; Wed, 8 Jan 2014 07:53:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.935 X-Spam-Level: X-Spam-Status: No, score=-0.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MIME_8BIT_HEADER=0.3, SPF_SOFTFAIL=0.665] 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 KacaPv45Trzi for ; Wed, 8 Jan 2014 07:53:06 -0800 (PST) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:227]) by ietfa.amsl.com (Postfix) with ESMTP id 343A81AE434 for ; Wed, 8 Jan 2014 07:53:05 -0800 (PST) Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by qmta12.westchester.pa.mail.comcast.net with comcast id BQzW1n0060Fqzac5CTsvtZ; Wed, 08 Jan 2014 15:52:55 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta08.westchester.pa.mail.comcast.net with comcast id BTss1n00h3ZTu2S3UTssdn; Wed, 08 Jan 2014 15:52:55 +0000 Message-ID: <52CD7454.8080208@alum.mit.edu> Date: Wed, 08 Jan 2014 10:52:52 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "Olle E. Johansson" , =?ISO-8859-1?Q?I=F1aki_Baz_?= =?ISO-8859-1?Q?Castillo?= References: <20140102101042.27427.64547.idtracker@ietfa.amsl.com> <0BA14051-5C7F-4416-8CD2-413347D540D3@edvina.net> <52C83591.3080702@alum.mit.edu> <17645DB3-06D2-4E6A-8B1E-759EEA2B68C9@edvina.net> In-Reply-To: <17645DB3-06D2-4E6A-8B1E-759EEA2B68C9@edvina.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1389196376; bh=4a17xCvabc6pTi0aTNU/nTTNT1IB8MeUul9BWAnHf68=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=QvDYmbZs2njAM1uv2yyakz6TazSrzSl97C8M2I9Ry2zSpQfcmrjCAsaRr6yyc6E2y hSmQK2S1XUNM4rGAnDzTRxNaowE5PHufFYD6j+gZnihsRVK27lr0JCkn1IdJ1firWs FBmquI22IE8NlcXzJhr0GJsaNqn+DuuzxjT3mdRXqkSgHBJbSTRwyZ8GA1Jy7OORjn 9Ns7xUsuz5K3B2/Vhnmk6wfHEx4xKMnh+h+w1d64zb9VpM0MhkqStcaIDKhhA4FWQ6 bByXWT355U2VgZWflYUDJQ4O2Zc+oKJ02xNHCHCYB8QzjQAHv2ag0MWR7x22rDCcfr u+uqmYijT4rhg== Cc: "dispatch@ietf.org list" Subject: Re: [dispatch] New Version Notification for draft-johansson-dispatch-dane-sip-00.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: Wed, 08 Jan 2014 15:53:08 -0000 On 1/8/14 4:16 AM, Olle E. Johansson wrote: > > On 08 Jan 2014, at 10:06, Iñaki Baz Castillo wrote: > >> 2014/1/8 Olle E. Johansson : >>>> Honestly I've never understood the real difference between a domain >>>> and a hostname. Of course, IMHO, the SIP client should provide in the >>>> SNI the destination domain of the server it is attempting to connect >>>> to. >>> Right, but... >>> >>> Does anyone find this in any published document? >> >> Not AFAIK :) >> But in this case SIP should follow well proven mechanisms and rules of HTTP(s). >> > If so, that is what we need to write. +1 This seems to be yet another place where as time goes on we find aspects of SIP that are underspecified. The problem with underspecification is that implementers make assumptions, often without even realizing they are doing so. And if implementers don't all make the *same* assumptions then we get interop problems. I'm strongly in favor of publishing clarifications for such things. Thanks, Paul From mary.ietf.barnes@gmail.com Wed Jan 8 08:06:59 2014 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 0716B1ADFA9 for ; Wed, 8 Jan 2014 08:06:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.098 X-Spam-Level: X-Spam-Status: No, score=-1.098 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, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, 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 COi8mZar2MuC for ; Wed, 8 Jan 2014 08:06:50 -0800 (PST) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 900DD1ADFA3 for ; Wed, 8 Jan 2014 08:06:49 -0800 (PST) Received: by mail-wg0-f45.google.com with SMTP id y10so1655450wgg.24 for ; Wed, 08 Jan 2014 08:06:40 -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=XyOa/CAKVswwVsT5QCVZm27A75TBRMREfXa//UTnywM=; b=ysd/RJptBlRG0ofN8iMjNJCsPnZxL9NUWKMf1nN4mzeKBa+JfEWio0K0eQopDaPcY9 FxDonQlJyXMI8Zv3FPPlTnPW8xSkN4wxUwhcQ6kLsX1QCsZBoahQyq6GUeqJZwDKTWth KBuKcGytTw+XQKspCUIu+oM0gFvuvVVU7snW4TqQpEqLh+rn0/fSLpzqx3R9GUi0OY9z 8dSekasJ/wt3wsSPjo/B4ZIEqOc23MYmTzQLN89m229Uym4yrxQc1CtxplzpNm91u9nE c07Lz+dKpv0Imw6RrqqR+YZWZorBVhT0NgUuIP0AjamM1N/l/uoJmGNFcJXoo7lZBEf6 aCNg== MIME-Version: 1.0 X-Received: by 10.180.210.131 with SMTP id mu3mr18463418wic.36.1389197198371; Wed, 08 Jan 2014 08:06:38 -0800 (PST) Received: by 10.216.172.9 with HTTP; Wed, 8 Jan 2014 08:06:38 -0800 (PST) In-Reply-To: <52CD72A8.4050805@alum.mit.edu> References: <058CE00BD4D6B94FAD033A2439EA1E4B01DEBB69CC8A@HE113667.emea1.cds.t-internal.com> <058CE00BD4D6B94FAD033A2439EA1E4B01DF27DB8A63@HE113667.emea1.cds.t-internal.com> <058CE00BD4D6B94FAD033A2439EA1E4B01DF8E83EB24@HE113667.emea1.cds.t-internal.com> <058CE00BD4D6B94FAD033A2439EA1E4B01DF8E83F451@HE113667.emea1.cds.t-internal.com> <058CE00BD4D6B94FAD033A2439EA1E4B01DF8EC99D57@HE113667.emea1.cds.t-internal.com> <52CD72A8.4050805@alum.mit.edu> Date: Wed, 8 Jan 2014 10:06:38 -0600 Message-ID: From: Mary Barnes To: Paul Kyzivat Content-Type: multipart/alternative; boundary=001a11c38d70882f7304ef77ad0c Cc: DISPATCH 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: Wed, 08 Jan 2014 16:06:59 -0000 --001a11c38d70882f7304ef77ad0c Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Wed, Jan 8, 2014 at 9:45 AM, Paul Kyzivat wrote: > On 1/8/14 3:46 AM, R.Jesske@telekom.de wrote: > >> Thank you Marry, >> >> for doing all this review. >> >> So I have now put out the errors. >> >> There are still some unused references which are in our informal >> reference section. But useful for the reader to know they exist. >> > > You could avoid the error by adding a bit of text that simply notes that > these might provide useful context for the reader. Then the references wi= ll > be referenced. > > Thanks, > Paul > [MB] I agree. Otherwise, you will still be dealing with this when the RFC Editor gets the document as one of the things they will do is to remove unused references. [/MB] > > There are also some warnings with regard to IP addresses and wrong FQDNs >> which I think is some interpretation of strings in the text which are >> not meant to be a IP address or FQDN at all. >> >> Detail see below. >> >> So now hopefully everything is ready for the next step. >> >> Best Regards >> >> Roland >> >> tmp/draft-drage-sipping-rfc3455bis-12.txt: >> >> Checking boilerplate required by RFC 5378 and the IETF Trust (see >> >> http://trustee.ietf.org/license-info): >> >> >> ------------------------------------------------------------ >> ---------------- >> >> No issues found here. >> >> Checking nits according to >> http://www.ietf.org/id-info/1id-guidelines.txt: >> >> >> ------------------------------------------------------------ >> ---------------- >> >> No issues found here. >> >> Checking nits according to http://www.ietf.org/id-info/checklist : >> >> >> ------------------------------------------------------------ >> ---------------- >> >> =3D=3D There are 4 instances of lines with non-RFC2606-compliant FQDNs= in >> the >> >> document. >> >> =3D=3D There are 4 instances of lines with non-RFC5735-compliant IPv4 >> addresses >> >> in the document. If these are example addresses, they should be >> changed. >> >> Miscellaneous warnings: >> >> >> ------------------------------------------------------------ >> ---------------- >> >> No issues found here. >> >> Checking references for intended status: Informational >> >> >> ------------------------------------------------------------ >> ---------------- >> >> =3D=3D Missing Reference: 'RFC XXXX' is mentioned on line 1662, but n= ot >> defined >> >> -- Looks like a reference, but probably isn't: '3' on line 1943 >> >> =3D=3D Unused Reference: 'RFC3262' is defined on line 2068, but no ex= plicit >> >> reference was found in the text >> >> =3D=3D Unused Reference: 'RFC3311' is defined on line 2072, but no ex= plicit >> >> reference was found in the text >> >> =3D=3D Unused Reference: 'RFC3428' is defined on line 2078, but no ex= plicit >> >> reference was found in the text >> >> =3D=3D Unused Reference: 'RFC3903' is defined on line 2090, but no ex= plicit >> >> reference was found in the text >> >> =3D=3D Unused Reference: 'RFC6086' is defined on line 2101, but no ex= plicit >> >> reference was found in the text >> >> Summary: 0 errors (**), 0 flaws (~~), 8 warnings (=3D=3D), 1 comme= nt >> (--). >> >> Run idnits with the --verbose option for more detailed information >> about >> >> the items above. >> >> ------------------------------------------------------------ >> -------------------- >> >> *Von:*Mary Barnes [mailto:mary.ietf.barnes@gmail.com] >> *Gesendet:* Dienstag, 7. Januar 2014 18:55 >> *An:* Jesske, Roland >> *Cc:* DISPATCH; Gonzalo Camarillo; Atle Monrad; Dean Willis >> *Betreff:* Re: PROTO Review: draft-drage-sipping-rfc3455bis-09.txt >> >> >> Thanks Roland. I have reviewed that version and all the changes I >> suggested have been made. However, in doing the PROTO write-up I >> realized that I wasn't certain anyone had reviewed the ABNF. So, I ran >> the ABNF through Bill Fenner's tool: >> >> http://tools.ietf.org/tools/bap/abnf.cgi >> >> And, there are a couple things that need to be fixed: >> >> 1) DOT needs to change to "." (we had this same bug in RFC 4244): >> >> transit-ioi-indexed-value =3D transit-ioi-name DOT transit-ioi-index >> >> 2) There's an extra space here (between * and parenthesis): >> >> transit-ioi-name =3D ALPHA * (ALPHA / DIGIT) >> >> NEw: transit-ioi-name =3D ALPHA *(ALPHA / DIGIT) >> >> There are also a number of long lines in the ABNF that should be fixed. >> >> In addition, IDNITS identifies other errors and warnings per the >> following. Those should also be addressed including considering whether >> obsolete references need changing: >> >> >> >> idnits 2.13.01 >> >> >> >> tmp/draft-drage-sipping-rfc3455bis-11.txt: >> >> >> >> Checking boilerplate required by RFC 5378 and the IETF Trust (see >> >> http://trustee.ietf.org/license-info): >> >> ------------------------------------------------------------ >> ---------------- >> >> >> >> No issues found here. >> >> >> >> Checking nits according tohttp://www.ietf.org/id-info/ >> 1id-guidelines.txt: >> >> >> ------------------------------------------------------------ >> ---------------- >> >> >> >> No issues found here. >> >> >> >> Checking nits according tohttp://www.ietf.org/id-info/checklist : >> >> >> ------------------------------------------------------------ >> ---------------- >> >> >> >> ** There are 9 instances of too long lines in the document, the >> longest one >> >> being 20 characters in excess of 72. >> >> >> >> =3D=3D There are 4 instances of lines with non-RFC2606-compliant FQDN= s in >> the >> >> document. >> >> >> >> =3D=3D There are 4 instances of lines with non-RFC5735-compliant IPv4 >> addresses >> >> in the document. If these are example addresses, they should be >> changed. >> >> >> >> >> >> Miscellaneous warnings: >> >> ------------------------------------------------------------ >> ---------------- >> >> >> >> =3D=3D The document seems to contain a disclaimer for pre-RFC5378 wor= k, >> but was >> >> first submitted on or after 10 November 2008. The disclaimer is >> usually >> >> necessary only for documents that revise or obsolete older RFCs, >> and that >> >> take significant amounts of text from those RFCs. If you can >> contact all >> >> authors of the source material and they are willing to grant the >> BCP78 >> >> rights to the IETF Trust, you can and should remove the disclaimer= . >> >> Otherwise, the disclaimer is needed and you can ignore this commen= t. >> >> (See the Legal Provisions document at >> >> http://trustee.ietf.org/license-info for more information.) >> >> >> >> >> >> Checking references for intended status: Informational >> >> ------------------------------------------------------------ >> ---------------- >> >> >> >> =3D=3D Missing Reference: 'RFC XXXX' is mentioned on line 1667, but n= ot >> defined >> >> >> >> -- Looks like a reference, but probably isn't: '3' on line 1948 >> >> >> >> =3D=3D Unused Reference: 'RFC2976' is defined on line 2065, but no ex= plicit >> >> reference was found in the text >> >> >> >> =3D=3D Unused Reference: 'RFC3262' is defined on line 2068, but no ex= plicit >> >> reference was found in the text >> >> >> >> =3D=3D Unused Reference: 'RFC3311' is defined on line 2075, but no ex= plicit >> >> reference was found in the text >> >> >> >> =3D=3D Unused Reference: 'RFC3428' is defined on line 2081, but no ex= plicit >> >> reference was found in the text >> >> >> >> =3D=3D Unused Reference: 'RFC3903' is defined on line 2093, but no ex= plicit >> >> reference was found in the text >> >> >> >> ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) >> >> >> >> -- Obsolete informational reference (is this intentional?): RFC 2976 >> >> (Obsoleted by RFC 6086) >> >> >> >> -- Obsolete informational reference (is this intentional?): RFC 3265 >> >> (Obsoleted by RFC 6665) >> >> >> >> >> >> Summary: 2 errors (**), 0 flaws (~~), 9 warnings (=3D=3D), 3 comme= nts >> (--). >> >> >> >> Run idnits with the --verbose option for more detailed information >> about >> >> the items above. >> >> While I apologize for not catching these issues earlier, it really is >> the responsibility of authors to check idnits (beyond what the >> submission tool requires) for their documents. I routinely run idnits >> before I submit a document as it can also save time when fixing the >> nits that the submission tool catches: >> https://tools.ietf.org/tools/idnits/ >> >> Regards, >> >> Mary. >> >> On Tue, Jan 7, 2014 at 12:35 AM, > > wrote: >> >> Hi Mary, >> >> Now a new revision is available. >> >> Thank you and Best Regards >> >> Roland >> >> *Von:*Mary Barnes [mailto:mary.ietf.barnes@gmail.com >> ] >> *Gesendet:* Montag, 6. Januar 2014 20:00 >> >> >> *An:* Jesske, Roland >> *Cc:* DISPATCH; Gonzalo Camarillo; Atle Monrad; Dean Willis >> *Betreff:* Re: PROTO Review: draft-drage-sipping-rfc3455bis-09.txt >> >> >> Hi Roland, >> >> One final editorial nit below. If you can spin a revision, then I'll >> send the PROTO write-up to the AD. >> >> Thanks, >> >> Mary. >> >> On Thu, Jan 2, 2014 at 3:29 AM, > > wrote: >> >> Hi Mary, >> >> I wish you a happy new year 2014. And the best for the next year. >> >> I was looking again on my changes I made due to your proposal in Decembe= r. >> >> I realized that if I change the SHOULD to MUST we have now a backward >> compatibility problem. >> >> We are using the P-Associated-URI also over the IMS user interface which >> is not encrypted. >> >> So I propose to add some more words. >> >> =85 >> >> Section 6.1 >> >> =85 >> >> An eavesdropper could possibly collect the list of identities a user >> is registered. >> >> This can 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. >> >> Since the P-Associated-URI header field value allows to implicitly >> register >> >> a bundle of URIs with one REGISTER Message the impact of security >> using the P-Associated-URI header field is not higher than >> >> using single REGISTER messages when registering all identities >> explicit. >> >> [MB] I just have some editorial suggestions for the above: >> >> NEW: >> >> While the P-Associated-URI header field value allows the implicit >> registration of >> >> a bundle of URIs with one REGISTER Message the impact of security >> using the P-Associated-URI header field is no higher than >> >> using separate REGISTER messages for each of the URIs. >> >> [/MB] >> >> For the P-Called-Party-Id the change should be also done like as >> follows: >> >> An eavesdropper could possibly collect the list of identities a >> user is registered. >> >> This can 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. >> >> Normally within a 3GPP environment the P-Called-Party-ID is not >> sent towards end users but may be exchanged between carriers where >> other security mechanisms than SIP encryption are used. >> >> Sorry coming so late. >> >> If this is OK for you I will include it to a new version. >> >> Thank you and Best Regards >> >> Roland >> >> *Von:*Mary Barnes [mailto:mary.ietf.barnes@gmail.com >> ] >> *Gesendet:* Freitag, 27. Dezember 2013 19:45 >> >> >> *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 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 word= s. >> >> >> - >> >> [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"? Real= ly, >> it's the next paragraph that provides details of the impacts. I think y= ou >> 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 securit= y. >> Does it reveal additional, unique information about an individual that >> isn't available in other headers. Also, the 2nd paragraph needs some wo= rk >> - maybe something like: >> >> >> >> >> >> >> OLD: >> >> >> >> >> >> An eavesdropper may collect the list of identities a user is >> registered. This may have privacy implications. To mitigate this probl= em, >> 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, wher= e >> 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 th= e >> 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 (3GPP) >> >> 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, whic= h >> 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 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 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 will need to do >> that before I progress the document unless the authors can point 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 i= n >> an Internet 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= , >> referring 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 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 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 intent is that this header is not applicable to proxies, >> therefore the proxy MUST relay the header field unchanged. I would sugg= est >> 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 no= t >> normative 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 audiovisual alerting >> >> tones, depending on the URI used to receive the invitation t= o >> the >> >> session. >> >> Section 4.2.2.2, 2nd paragraph. The behavior in this sentence i= s >> not normative from a SIP protocol perspective, thus I suggest the MAY b= e >> changed to "can". >> >> >> >> - Section 4.3.3, last paragraph. I think this ought to be a >> MUST: "The identifier 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 someth= ing >> like. However, even with this proposed change, I think you also need tex= t >> for user agent server behavior - i.e., what would a UAS do if it receive= d >> this header. >> >> >> >> 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 insert a P-Visited-Network-ID header field in any >> SIP message. >> >> >> >> - Section4.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 trust relationship with the proxy" >> >> >> >> Section 4.4.2.1, 3rd paragraph: "there must also be a transitiv= e >> 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 i= d" >> -> "can use thecall id" >> >> >> Section 4.5.2: 2nd paragraph: "MAY use the hostnames" -> "can us= e >> the hostnames" >> >> >> >> >> >> >> >> Section 4.5.2.1 2nd paragraph: "MAY use the contents" -> "can us= e >> 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. Mayb= e >> the following 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-Charging-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 b= e >> guaranteed that 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 in= to >> consideration" mean. Are you talking about limits on the number of entri= es >> or are you suggesting 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 ha= s >> to be incremented by the number of void entries +1. >> >> >> >> - Section4.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 add= ing >> 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 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 verbally 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 b= y >> "potentially annoying" for example? >> >> >> >> [RJ] I do not know. This is original text. So I deleted the word= s. >> >> >> >> - Section 6.2: I think you need to be more specific about the >> "nature" that makes this header not of particular concern with regards t= o >> security. Does it reveal additional, unique information about an individ= ual >> that isn't available in other headers. Also, the 2nd paragraph needs so= me >> 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 probl= em, >> 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 th= is >> problem, this extension MUST only be used in a secured environment, wher= e >> 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 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 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 sensitive nature? I would think that the information just sho= uld >> not be sent outside of the trust domain. I believe that's consistent wi= th >> 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 beha= ve. >> >> >> >> -- 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-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 include 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= " >> -> 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 transitiv= e >> 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.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 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 (3GPP) >> 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 us= e, >> 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 >> >> - >> >> >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> >> > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --001a11c38d70882f7304ef77ad0c Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable



On Wed, Jan 8, 2014 at 9:45 AM, Paul Kyzivat <= pkyzivat@alum.mi= t.edu> wrote:
On 1/8/14 3:46 AM, R.Jesske@telekom.de w= rote:
Thank you Marry,

for doing all this review.

So I have now put out the errors.

There are still some unused references which are in our informal
reference section. But useful for the reader to know they exist.

You could avoid the error by adding a bit of text that simply notes that th= ese might provide useful context for the reader. Then the references will b= e referenced.

=A0 =A0 =A0 =A0 Thanks,
=A0 =A0 =A0 =A0 Paul

[MB] I agree. Othe= rwise, you will still be dealing with this when the RFC Editor gets the doc= ument as one of the things they will do is to remove unused references. [/M= B]=A0

There are also some warnings with regard to IP addresses and wrong FQDNs which I think is some interpretation of strings in the text which are
not meant to be a IP address or FQDN at all.

Detail see below.

So now hopefully everything is ready for the next step.

Best Regards

Roland

tmp/draft-drage-sipping-rfc3455bis-12.txt:

=A0 =A0Checking boilerplate required by RFC 5378 and the IETF Trust (see
=A0 =A0h= ttp://trustee.ietf.org/license-info):


-------------------------------------------------------------= ---------------

=A0 =A0 =A0 No issues found here.

=A0 =A0Checking nits according to
http://www.ietf.org/id-info/1id-guidelines.txt:


-------------------------------------------------------------= ---------------

=A0 =A0 =A0 No issues found here.

=A0 =A0Checking nits according to http://www.ietf.org/id-info/checklist= :


-------------------------------------------------------------= ---------------

=A0 =3D=3D There are 4 instances of lines with non-RFC2606-compliant FQDNs = in the

=A0 =A0 =A0 document.

=A0 =A0=3D=3D There are 4 instances of lines with non-RFC5735-compliant IPv= 4
addresses

=A0 =A0 =A0 in the document. =A0If these are example addresses, they should= be
changed.

=A0 =A0Miscellaneous warnings:


-------------------------------------------------------------= ---------------

=A0 =A0 =A0 No issues found here.

=A0 =A0Checking references for intended status: Informational


-------------------------------------------------------------= ---------------

=A0 =A0=3D=3D Missing Reference: 'RFC XXXX' is mentioned on line 16= 62, but not
defined

=A0 =A0-- Looks like a reference, but probably isn't: '3' on li= ne 1943

=A0 =A0=3D=3D Unused Reference: 'RFC3262' is defined on line 2068, = but no explicit

=A0 =A0 =A0 reference was found in the text

=A0 =A0=3D=3D Unused Reference: 'RFC3311' is defined on line 2072, = but no explicit

=A0 =A0 =A0 reference was found in the text

=A0 =A0=3D=3D Unused Reference: 'RFC3428' is defined on line 2078, = but no explicit

=A0 =A0 =A0 reference was found in the text

=A0 =A0=3D=3D Unused Reference: 'RFC3903' is defined on line 2090, = but no explicit

=A0 =A0 =A0 reference was found in the text

=A0 =A0=3D=3D Unused Reference: 'RFC6086' is defined on line 2101, = but no explicit

=A0 =A0 =A0 reference was found in the text

=A0 =A0 =A0 Summary: 0 errors (**), 0 flaws (~~), 8 warnings (=3D=3D), 1 co= mment (--).

=A0 =A0 =A0 Run idnits with the --verbose option for more detailed informat= ion
about

the items above.

-------------------------------------------------------------= -------------------

*Von:*Mary Barnes [mailto:mary.ietf.barnes@gmail.com]
*Gesendet:* Dienstag, 7. Januar 2014 18:55
*An:* Jesske, Roland
*Cc:* DISPATCH; Gonzalo Camarillo; Atle Monrad; Dean Willis
*Betreff:* Re: PROTO Review: draft-drage-sipping-rfc3455bis-09.txt

Thanks Roland. =A0I have reviewed that version and all the changes I
suggested have been made. =A0However, in doing the PROTO write-up I
realized that I wasn't certain anyone had reviewed the ABNF. So, I ran<= br> the ABNF through Bill Fenner's tool:

http= ://tools.ietf.org/tools/bap/abnf.cgi

And, there are a couple things that need to be fixed:

1) =A0DOT needs to change to "." (we had this same bug in RFC 424= 4):

transit-ioi-indexed-value =3D transit-ioi-name DOT transit-ioi-index

2) =A0There's an extra space here (between * and parenthesis):

transit-ioi-name =A0 =A0 =A0 =A0 =A0=3D ALPHA * (ALPHA / DIGIT)

NEw: transit-ioi-name =A0 =A0 =A0 =A0 =A0=3D ALPHA *(ALPHA / DIGIT)

There are also a number of long lines in the ABNF that should be fixed.

In addition, IDNITS identifies other errors and warnings per the
following. =A0Those should also be addressed including considering whether<= br> obsolete references need changing:



idnits 2.13.01



tmp/draft-drage-sipping-rfc3455bis-11.txt:



=A0 =A0Checking boilerplate required by RFC 5378 and the IETF Trust (see
=A0 =A0h= ttp://trustee.ietf.org/license-info):

=A0 =A0------------------------------------------------------------<= u>----------------



=A0 =A0 =A0 No issues found here.



=A0 =A0Checking nits according tohttp://www.ietf.org/id-info/1id-g= uidelines.txt:


=A0 =A0------------------------------------------------------------<= u>----------------



=A0 =A0 =A0 No issues found here.



=A0 =A0Checking nits according tohttp://www.ietf.org/id-info/checklist = =A0:


=A0 =A0------------------------------------------------------------<= u>----------------



=A0 =A0** There are 9 instances of too long lines in the document, the long= est one

=A0 =A0 =A0 being 20 characters in excess of 72.



=A0 =A0=3D=3D There are 4 instances of lines with non-RFC2606-compliant FQD= Ns in the

=A0 =A0 =A0 document.



=A0 =A0=3D=3D There are 4 instances of lines with non-RFC5735-compliant IPv= 4 addresses

=A0 =A0 =A0 in the document. =A0If these are example addresses, they should= be changed.





=A0 =A0Miscellaneous warnings:

=A0 =A0------------------------------------------------------------<= u>----------------



=A0 =A0=3D=3D The document seems to contain a disclaimer for pre-RFC5378 wo= rk, but was

=A0 =A0 =A0 first submitted on or after 10 November 2008. =A0The disclaimer= is usually

=A0 =A0 =A0 necessary only for documents that revise or obsolete older RFCs= , and that

=A0 =A0 =A0 take significant amounts of text from those RFCs. =A0If you can= contact all

=A0 =A0 =A0 authors of the source material and they are willing to grant th= e BCP78

=A0 =A0 =A0 rights to the IETF Trust, you can and should remove the disclai= mer.

=A0 =A0 =A0 Otherwise, the disclaimer is needed and you can ignore this com= ment.

=A0 =A0 =A0 (See the Legal Provisions document at

=A0 =A0 =A0 http://trustee.ietf.org/license-info =A0for more information= .)





=A0 =A0Checking references for intended status: Informational

=A0 =A0------------------------------------------------------------<= u>----------------



=A0 =A0=3D=3D Missing Reference: 'RFC XXXX' is mentioned on line 16= 67, but not defined



=A0 =A0-- Looks like a reference, but probably isn't: '3' on li= ne 1948



=A0 =A0=3D=3D Unused Reference: 'RFC2976' is defined on line 2065, = but no explicit

=A0 =A0 =A0 reference was found in the text



=A0 =A0=3D=3D Unused Reference: 'RFC3262' is defined on line 2068, = but no explicit

=A0 =A0 =A0 reference was found in the text



=A0 =A0=3D=3D Unused Reference: 'RFC3311' is defined on line 2075, = but no explicit

=A0 =A0 =A0 reference was found in the text



=A0 =A0=3D=3D Unused Reference: 'RFC3428' is defined on line 2081, = but no explicit

=A0 =A0 =A0 reference was found in the text



=A0 =A0=3D=3D Unused Reference: 'RFC3903' is defined on line 2093, = but no explicit

=A0 =A0 =A0 reference was found in the text



=A0 =A0** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234)


=A0 =A0-- Obsolete informational reference (is this intentional?): RFC 2976=

=A0 =A0 =A0 (Obsoleted by RFC 6086)



=A0 =A0-- Obsolete informational reference (is this intentional?): RFC 3265=

=A0 =A0 =A0 (Obsoleted by RFC 6665)





=A0 =A0 =A0 Summary: 2 errors (**), 0 flaws (~~), 9 warnings (=3D=3D), 3 co= mments (--).



=A0 =A0 =A0 Run idnits with the --verbose option for more detailed informat= ion about

=A0 =A0 =A0 the items above.

While I apologize for not catching these issues earlier, it really is
the responsibility of authors to check idnits (beyond what the
submission tool requires) for their documents. =A0I routinely run idnits before I submit a document as it can also save time when fixing the
=A0 nits that the submission tool catches:
https://= tools.ietf.org/tools/idnits/

Regards,

Mary.

On Tue, Jan 7, 2014 at 12:35 AM, <R.Jesske@telekom.de
<mailto:R.Jessk= e@telekom.de>> wrote:

Hi Mary,

Now a new revision is available.

Thank you and Best Regards

Roland

*Von:*Mary Barnes [mailto:mary.ietf.barnes@gmail.com
<mailto:= mary.ietf.barnes@gmail.com>]
*Gesendet:* Montag, 6. Januar 2014 20:00


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

Hi Roland,

One final editorial nit below. =A0If you can spin a revision, then I'll=
send the PROTO write-up to the AD.

Thanks,

Mary.

On Thu, Jan 2, 2014 at 3:29 AM, <R.Jesske@telekom.de
<mailto:R.Jessk= e@telekom.de>> wrote:

Hi Mary,

I wish you a happy new year 2014. And the best for the next year.

I was looking again on my changes I made due to your proposal in December.<= br>
I realized that if I change the SHOULD to MUST we have now a backward
compatibility problem.

We are using the P-Associated-URI also over the IMS user interface which is not encrypted.

So I propose to add some more words.

=85

Section 6.1

=85

<t>An eavesdropper could possibly collect the list of identities a us= er
is registered.

=A0 =A0 =A0 =A0 This can have privacy implications. To mitigate this proble= m,
this extension SHOULD

=A0 =A0 =A0 =A0 only be used in a secured environment, where encryption of = SIP
messages is

=A0 =A0 =A0 =A0 provided either end-to-end or hop-by-hop. </t>

<t> Since the P-Associated-URI header field value allows to implicitl= y
register

=A0 =A0 =A0 =A0a bundle of URIs with one REGISTER Message the impact of sec= urity
using the P-Associated-URI header field is not higher than

=A0 =A0 =A0 =A0using single REGISTER messages when registering all identiti= es
explicit.</t>

[MB] I just have some editorial suggestions for the above:

NEW:

<t> While the P-Associated-URI header field value allows the implicit=
registration of

=A0 =A0 =A0 =A0a bundle of URIs with one REGISTER Message the impact of sec= urity
using the P-Associated-URI header field is no higher than

=A0 =A0 =A0 =A0using separate REGISTER messages for each of the URIs. </= t>

[/MB]

=A0 =A0 For the P-Called-Party-Id the change should be also done like as =A0 =A0 follows:

=A0 =A0 <t>An eavesdropper could possibly collect the list of identit= ies a
=A0 =A0 user is registered.

=A0 =A0 =A0 =A0 =A0 =A0 This can have privacy implications. =A0To mitigate = this
=A0 =A0 problem, this extension SHOULD

=A0 =A0 =A0 =A0 =A0 =A0 only be used in a secured environment, where encryp= tion of
=A0 =A0 SIP messages is

=A0 =A0 =A0 =A0 =A0 =A0 provided either end-to-end or hop-by-hop. </t>= ;

=A0 =A0 <t>Normally within a 3GPP environment the P-Called-Party-ID i= s not
=A0 =A0 sent towards end users but may be exchanged between carriers where<= br> =A0 =A0 other security mechanisms than SIP encryption are used. </t><= br>
=A0 =A0 Sorry coming so late.

=A0 =A0 If this is OK for you I will include it to a new version.

=A0 =A0 Thank you and Best Regards

=A0 =A0 Roland

=A0 =A0 *Von:*Mary Barnes [mailto:mary.ietf.barnes@gmail.com
=A0 =A0 <mailto:mary.ietf.barnes@gmail.com>]
=A0 =A0 *Gesendet:* Freitag, 27. Dezember 2013 19:45


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


=A0 =A0 Hi Roland,

=A0 =A0 Thanks for making these changes. I finally had a chance to review =A0 =A0 this updated version. =A0 I still have a couple comments on the
=A0 =A0 security section as I think you will get questions during SEC revie= w
=A0 =A0 around this unless some more detail is provided on security threats=
=A0 =A0 and impacts. =A0 I've extracted these few points from previous = review
=A0 =A0 comment threads.

=A0 =A0 Thanks,

=A0 =A0 Mary.

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

=A0 =A0 =A0 _[_RJ] I do not know. This is original text. So I deleted the w= ords.


=A0 =A0 -

=A0 =A0 [MB] So, you removed that part of the sentence and are left with:
=A0 =A0 "This attack should not have any significant impacts."




=A0 =A0 I don't think that adds any value and just begs the question &q= uot;what are the insignificant impacts and are there any privacy concerns&q= uot;? =A0Really, it's the next paragraph that provides details of the i= mpacts. =A0I think you could probably remove that sentence altogether and n= ot lose anything.





=A0 =A0 [/MB]



=A0 =A0 ----Previous point --------------------------------->



=A0 =A0 -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 individ= ual that isn't available in other headers. =A0Also, the 2nd paragraph n= eeds some work - maybe something like:






=A0 =A0 OLD:





=A0 =A0 An eavesdropper may collect the list of identities a user is regist= ered. =A0This may have privacy implications. =A0To mitigate this problem, t= his extension SHOULD only be used in a secured environment, where encryptio= n of SIP messages is provided either end-to-end or





=A0 =A0 hop-by-hop.

=A0 =A0 NEW:



=A0 =A0 An eavesdropper could possibly collect the list of identities a use= r is registered. =A0This can have privacy implications. =A0To 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.

=A0 =A0 ----End previous point ------------------------------<


=A0 =A0 [MB] =A0The suggested change for the first sentence didn't get = into the revision. =A0And, I believe you still need to identify privacy/sec= urity implications by addressing whether or not this header reveals any uni= que information about an individual that isn't available in other heade= rs. =A0 [/MB]









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

=A0 =A0 Hi Mary,

=A0 =A0 Thank you for your comments and proposals.

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

=A0 =A0 So we can now proceed.

=A0 =A0 Thank you and Best Regards

=A0 =A0 Roland

=A0 =A0 A new version of I-D, draft-drage-sipping-rfc3455bis-10.txt<= br>
=A0 =A0 has been successfully submitted by Roland Jesske and posted to the<= br> =A0 =A0 IETF repository.

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

=A0 =A0 Revision: =A0 10

=A0 =A0 Title: =A0 =A0 =A0 =A0 =A0 =A0Private Header (P-Header) Extensions = to the
=A0 =A0 Session Initiation Protocol (SIP) for the 3rd-Generation Partnershi= p
=A0 =A0 Project (3GPP)

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

=A0 =A0 Group: =A0 =A0 =A0 =A0 =A0 =A0Individual Submission

=A0 =A0 Number of pages: 46

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

=A0 =A0 Status: http://datatracker.ietf.org/doc/dr= aft-drage-sipping-rfc3455bis

=A0 =A0 Htmlized: http://tools.ietf.org/html/draft-d= rage-sipping-rfc3455bis-10

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

=A0 =A0 Abstract:

=A0 =A0 =A0 =A0 This document describes a set of private Session Initiation= Protocol

=A0 =A0 =A0 =A0 (SIP) header fields (P-headers) used by the 3rd-Generation<= br>
=A0 =A0 =A0 =A0 Partnership Project (3GPP), along with their applicability,= which is

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

=A0 =A0 =A0 =A0 variety of purposes within the networks that the partners u= se,

=A0 =A0 =A0 =A0 including charging and information about the networks a cal= l

=A0 =A0 traverses.

=A0 =A0 *Von:*Mary Barnes [mailto:mary.ietf.barnes@gmail.com
=A0 =A0 <mailto:mary.ietf.barnes@gmail.com>]
=A0 =A0 *Gesendet:* Montag, 25. November 2013 23:01


=A0 =A0 *An:* Jesske, Roland
=A0 =A0 *Cc:* DISPATCH; Gonzalo Camarillo; Atle Monrad; Dean Willis

=A0 =A0 *Betreff:* Re: PROTO Review: draft-drage-sipping-rfc3455bis-= 09.txt


=A0 =A0 Hi Roland,

=A0 =A0 Thanks for your response. =A0Additional comments below [MB].

=A0 =A0 Thanks,

=A0 =A0 Mary.

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

=A0 =A0 Hi Mary,

=A0 =A0 Thank you for your review.

=A0 =A0 I have added now your proposals to the draft.

=A0 =A0 Other comments please see below.

=A0 =A0 I hope now everything is OK.

=A0 =A0 Thank you and Best Regards

=A0 =A0 Roland

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


=A0 =A0 In preparation for the PROTO write-up, I have reviewed the document=
=A0 =A0 in detail. =A0My detailed review was originally based on the -08, b= ut
=A0 =A0 I also reviewed the 09 diff. =A0There are a few errors that have be= en
=A0 =A0 introduced in the -09 and many of my -08 comments remain - I've=
=A0 =A0 separated comments from nits below. =A0A number of these comments a= re
=A0 =A0 with regards to text that was not changed from RFC 3455, but I thin= k
=A0 =A0 some of the text requires updating and we need to keep in mind that=
=A0 =A0 this an entirely new IESG that will be reviewing this document, so<= br> =A0 =A0 they won't have the same context of the IESG that approved RFC = 3455.
=A0 =A0 =A0 I will note that I also have not validated the content of secti= on
=A0 =A0 9 against a diff of this document and RFC 3455. =A0I will need to d= o
=A0 =A0 that before I progress the document unless the authors can point me=
=A0 =A0 to another review that has done that.

=A0 =A0 Regards,

=A0 =A0 Mary.

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

=A0 =A0 Comments:

=A0 =A0 ----------------

=A0 =A0 - Section 1. =A0I think you should be explicit that these extension= s
=A0 =A0 apply only to a private network - saying they are "generally n= ot
=A0 =A0 applicable" is too soft, so I would suggest some minor rewordi= ng
=A0 =A0 something like:

=A0 =A0 OLD:

=A0 =A0 =A0 =A0 The SIP extensions specified in this document make certain<= br>


=A0 =A0 =A0 =A0 assumptions regarding network topology, linkage between SIP= and lower

=A0 =A0 =A0 =A0 layers, and the availability of transitive trust. =A0These = assumptions

=A0 =A0 =A0 =A0 are generally NOT APPLICABLE in the Internet as a whole.


=A0 =A0 NEW:



=A0 =A0 =A0 =A0 The SIP extensions specified in this document make certain<= br>
=A0 =A0 =A0 =A0 assumptions regarding network topology, linkage between SIP= and lower

=A0 =A0 =A0 =A0 layers, and the availability of transitive trust. =A0These = assumptions

=A0 =A0 =A0 =A0 apply only to private networks and are not appropriate for = use in an Internet environment.









=A0 =A0 - Section 3. =A0This section needs to be updated. =A0I don't th= ink that 10 year old background is relevant in the current context. =A0 You= should be able to model this after the text in more recent 3GPP P-header d= ocuments, referring to the SIP change process.



=A0 =A0 [RJ] OK, I have changed the text:

=A0 =A0 The Third Generation Partnership Project (3GPP) has selected SIP as=

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

=A0 =A0 =A0 =A0 =A0 context of its IP Multimedia Subsystem (IMS). For more<= br> =A0 =A0 information on

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

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

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

=A0 =A0 =A0 =A0 =A0 the protocol =A0to establish and tear down multimedia s= essions
=A0 =A0 in the

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

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

=A0 =A0 =A0 =A0 =A0 RFC 3455 defines SIP private header extensions (referre= d to as
=A0 =A0 P-headers) which are

=A0 =A0 =A0 =A0 =A0 required by the 3GPP specification. Note that the requi= rements
=A0 =A0 for these extensions

=A0 =A0 =A0 =A0 =A0 are documented in RFC 4083. This document is an update = to
=A0 =A0 RFC3455.

=A0 =A0 =A0 =A0 =A0 This document updates existing P-header descriptions
=A0 =A0 =A0 =A0 =A0 to address additional requirements which are needed for= 3GPP
=A0 =A0 Release 11.

=A0 =A0 =A0 =A0 =A0 Each of the P-headers is described in the sections belo= w.

=A0 =A0 [/MB]

=A0 =A0 =A0 =A0 - Section 4.1. "registered address-of-record" -&g= t; "registered SIP address-of-record"

=A0 =A0 =A0 =A0 - Section 4.1, 3rd paragraph. =A0"Note that, generally= speaking," -> "Note that in standard SIP usage [RFC3261]"= ;

=A0 =A0 =A0 =A0 - Section 4.1.2.3. =A0I don't think this is stated prop= erly. =A0I think the intent is that this header is not applicable to proxie= s, therefore the proxy MUST relay the header field unchanged. =A0I would su= ggest rewording something like:

=A0 =A0 =A0 =A0 OLD:

=A0 =A0 =A0 =A0 =A0 =A0 This memo does not define any procedure at the prox= y. =A0The proxy does

=A0 =A0 =A0 =A0 =A0 =A0 not add, read, modify or delete the header field, a= nd therefore any

=A0 =A0 =A0 =A0 =A0 =A0 proxy will relay this header field unchanged.



=A0 =A0 =A0 =A0 NEW:



=A0 =A0 =A0 =A0 =A0 =A0 This header is not intended to be used by proxies -= a proxy does

=A0 =A0 =A0 =A0 =A0 =A0 not add, read, modify or delete the header field, a= nd therefore any

=A0 =A0 =A0 =A0 =A0 =A0 proxy MUST relay this header field unchanged.









=A0 =A0 =A0 =A0 Section 4.2, 1st paragraph. =A0The behavior in this sentenc= e is not normative from a SIP protocol perspective, thus MAY is not appropr= iate. =A0I suggest the MAY be changed to "can".

=A0 =A0 =A0 =A0 =A0 =A0 The UAS MAY use the information to render different= distinctive audiovisual alerting

=A0 =A0 =A0 =A0 =A0 =A0 tones, depending on the URI used to receive the inv= itation to the

=A0 =A0 =A0 =A0 =A0 =A0 session.

=A0 =A0 =A0 =A0 Section 4.2.2.2, 2nd paragraph. =A0The behavior in this sen= tence is not normative from a SIP protocol perspective, thus =A0I suggest t= he MAY be changed to "can".



=A0 =A0 =A0 =A0 - Section 4.3.3, last paragraph. =A0I think this ought to b= e a MUST: "The identifier should be globally unique.."



=A0 =A0 =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 te= rm "User Equipment" is not defined in this specification. =A0I th= ink it would be better to say something like. However, even with this propo= sed change, I think you also need text for user agent server behavior - i.e= ., what would a UAS do if it received this header.



=A0 =A0 =A0 =A0 OLD:

=A0 =A0 =A0 =A0 =A0 =A0 A normal User Equipment has normally no knowledge o= f the P-Visited-

=A0 =A0 =A0 =A0 =A0 =A0 Network-ID when sending the REGISTER. =A0Therefore = user agent clients

=A0 =A0 =A0 =A0 =A0 =A0 do not insert a P-Visited-Network-ID header field i= n any SIP message.







=A0 =A0 =A0 =A0 NEW:

=A0 =A0 =A0 =A0 =A0 =A0 In the context of the network to which the header f= ields defined in this document apply, a User Agent has no knowledge of the = P-Visited-Network-ID when sending the REGISTER request. =A0Therefore user a= gent clients MUST NOT insert a P-Visited-Network-ID header field in any SIP= message.



=A0 =A0 =A0 =A0 - Section4.3.2.2 =A0<http://4.3.2.2>:, 2nd paragraph: =A0"home network M= AY use" -> "home network can use"










=A0 =A0 =A0 =A0 - Section 4.3.2.2, last paragraph:





=A0 =A0 =A0 =A0 OLD: =A0Note that a received P-Visited-Network-ID from a UA= is a failure case and must be deleted.



=A0 =A0 =A0 =A0 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.



=A0 =A0 =A0 =A0 Section 4.4.2.1, 2nd paragraph: =A0"MUST trust the pro= xy" -> "MUST have a trust relationship with the proxy"


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

=A0 =A0 =A0 =A0 Section 4.4.2.2, 2nd paragraph: "MAY act upon any info= rmation present" -> "can act upon any information present"= ;, =A0"MAY use the call id" -> "can use thecall id"<= div class=3D"im">

=A0 =A0 =A0 =A0 Section 4.5.2: 2nd paragraph: "MAY use the hostnames&q= uot; -> "can use the hostnames"







=A0 =A0 =A0 =A0 Section 4.5.2.1 2nd paragraph: "MAY use the contents&q= uot; -> "can use the contents"



=A0 =A0 =A0 =A0 - Section 4.6.2, 3rd paragraph: "MAY use the values&qu= ot; -> "can use the values"

=A0 =A0 =A0 =A0 - Section 4.6.3, 3rd paragraph: needs some editorial work. = =A0Maybe the following change would work:





=A0 =A0 =A0 =A0 OLD:



=A0 =A0 =A0 =A0 =A0 =A0 Depending on the call scenario it is needed to add = for each transit

=A0 =A0 =A0 =A0 =A0 =A0 network either a transit network name or a void val= ue. =A0Nevertheless

=A0 =A0 =A0 =A0 =A0 =A0 it can not be guaranteed that all values will appea= r within the P-Charging-Vector header field.





=A0 =A0 =A0 =A0 NEW:



=A0 =A0 =A0 =A0 =A0 =A0 Depending on the call scenario, each transit networ= k can add either a transit network name or a void =A0 =A0value. =A0However,= it can not be guaranteed that all the values that are added will appear wi= thin the P-Charging-Vector header field.



=A0 =A0 =A0 =A0 - Section 4.6.3, next to last paragraph: "which needs = to be incremented" -> "which MUST be incremented"



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



=A0 =A0 =A0 =A0 [RJ] Yes! Changed the text to:



=A0 =A0 =A0 =A0 A void value has no index. By adding the next value the ind= ex has to be incremented by the number of void entries +1.



=A0 =A0 =A0 =A0 - Section4.6.4.2 =A0<http://4.6.4.2>: I don't know what this means: =A0&q= uot;A deletion of the elements 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 delete= d by the proxy?




=A0 =A0 =A0 =A0 [RJ] Yes, I have changed the text:

=A0 =A0 =A0 =A0 Procedures described within 4.6.2.2 apply. A transit-ioi MA= Y be

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 added or modified by a proxy. A del= etion of the
=A0 =A0 =A0 =A0 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 pol= icy and trust
=A0 =A0 =A0 =A0 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 =A0 =A0 - Section 5.7. Delete this text and table. =A0 We aren'= t these tables anymore as they really don't provide any useful informat= ion. =A0You just need to verbally state what messages these headers can app= ear in.



=A0 =A0 =A0 =A0 [RJ] OK



=A0 =A0 =A0 =A0 So I changed 5.7 to =93New header=94

=A0 =A0 =A0 =A0 The P-Associated-URI can appear in SIP REGISTER method and = 2xx
=A0 =A0 =A0 =A0 resonses, P-Called-Party-ID can appear in SIP INVITE, OPTIO= NS,
=A0 =A0 =A0 =A0 PUBLISH,SUBSCRIBE, MESSAGE methods and all responses,
=A0 =A0 =A0 =A0 P-Visited-Network-ID can appear in all SIP methods except A= CK,
=A0 =A0 =A0 =A0 BYE and CANCEL and all responses, P-Access-Network-Info can=
=A0 =A0 =A0 =A0 appear in all SIP methods exept ACK and CANCEL,
=A0 =A0 =A0 =A0 P-Charging-Vector =A0can appear in all SIP methods exept CA= NCEL
=A0 =A0 =A0 =A0 and the P-Charging-Function-Addresses can appear in all SIP=
=A0 =A0 =A0 =A0 methods exept ACK and CANCEL.

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





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



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



=A0 =A0 =A0 =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 =A0 =A0 =A0 OLD:

=A0 =A0 =A0 =A0 An eavesdropper may collect the list of identities a user i= s registered. =A0This may have privacy implications. =A0To mitigate this pr= oblem, this extension SHOULD only be used in a secured environment, where e= ncryption of SIP messages is provided either end-to-end or









=A0 =A0 =A0 =A0 hop-by-hop.





=A0 =A0 =A0 =A0 NEW:



=A0 =A0 =A0 =A0 =A0 An eavesdropper could possibly collect the list of iden= tities a user is registered. =A0This can have privacy implications. =A0To m= itigate this problem, this extension MUST only be used in a secured environ= ment, where encryption of SIP 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 =A0 =A0 eavesdropper could possibly collect the list of identities a user =A0 =A0 has registered."

=A0 =A0 or =A0"An eavesdropper could possibly collect the list of iden= tities
=A0 =A0 registered by a user."

=A0 =A0 [/MB]

=A0 =A0 =A0 =A0 - Section 6.4,

=A0 =A0 =A0 =A0 --3rd paragraph: "should not" -> "MUST NO= T"



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











=A0 =A0 =A0 =A0 -- 8th paragraph: "SHOULD NOT send sensitive informati= on" -> "MUST NOT send sensitive information"





=A0 =A0 =A0 =A0 -- 9th paragraph: "is required to delete" -> &= quot;is REQUIRED to delete"



=A0 =A0 =A0 =A0 -- 10th paragraph: =A0How does a network ensure the informa= tion is not of a sensitive nature? =A0 I would think that the information j= ust should not be sent outside of the trust domain. =A0I believe that's= consistent with the scope of these headers, is it not?



=A0 =A0 =A0 =A0 [RJ] Yes that is also my understanding so I deleted that pa= ragraph. I think the rest is sufficient and described well how to behave.


=A0 =A0 =A0 =A0 -- 11th paragraph: So, what does a proxy do with that infor= mation.What are the implications if the information is used and it's no= t valid?


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



=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<t>A proxy receiving a message con= taining the
=A0 =A0 =A0 =A0 P-Access-Network-Info

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 header field from a non-trusted entity is n= ot able to
=A0 =A0 =A0 =A0 guarantee the

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 validity of the contents. Thus this content= SHOULD be deleted based on local policy.</t>



=A0 =A0 =A0 =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 =A0 =A0 =A0 [RJ] OK done. I let the reference RFC4244 since 3GPP uses c= urrently only RFC4244.

=A0 =A0 =A0 =A0 Replaced following text:

=A0 =A0 =A0 =A0 With section 9.2

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <t>Requirements for a more general so= lution are proposed in <xref

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 target=3D"RFC4244"></xr= ef>. 3GPP will continue to use the

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 P-Called-Party-ID header field even tho= ugh RFC 4244 <xref

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 target=3D"RFC4244"></xr= ef> has now been published.</t>



=A0 =A0 =A0 =A0 I think the text in Section 9.2 is better.

=A0 =A0 =A0 =A0 _Nits:_










=A0 =A0 =A0 =A0 - Section 4.1, 2nd paragraph. =A0"has associated to an= address-of-record" -> "has associated with an address-of-reco= rd"

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

=A0 =A0 =A0 =A0 - Section 4.3.2.2, last sentence. =A0The -09 introduced a t= ypo: "T means" -> "This means"



=A0 =A0 =A0 =A0 - Section 4.3.2.3, 1st paragraph after 1st example. =A0The = -09 introduced another typo: "the REGISTRAR" -> "at the R= EGISTRAR"



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



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


=A0 =A0 =A0 =A0 Section 4.6.2.2, 1st paragraph: "one ore more" -&= gt; "one or more"







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

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

=A0 =A0 =A0 =A0 If there are still some comments that needs to be implement= ed
=A0 =A0 =A0 =A0 please inform me.

=A0 =A0 =A0 =A0 =A0From my side I would be happy to proceed the draft furth= er
=A0 =A0 =A0 =A0 towards publication.

=A0 =A0 =A0 =A0 Thank you and Best Regards

=A0 =A0 =A0 =A0 Roland


=A0 =A0 =A0 =A0 -----Urspr=FCngliche Nachricht-----
=A0 =A0 =A0 =A0 Von: internet-drafts@ietf.org <mailto:internet-drafts@ietf.org><= br>
=A0 =A0 =A0 =A0 [mailto:internet-drafts@ietf.org <mailto:internet-drafts@ietf.o= rg>]

=A0 =A0 =A0 =A0 Gesendet: Dienstag, 8. Oktober 2013 13:40
=A0 =A0 =A0 =A0 An: Christer Holmberg; Keith Drage; Jesske, Roland
=A0 =A0 =A0 =A0 Betreff: New Version Notification for
=A0 =A0 =A0 =A0 draft-drage-sipping-rfc3455bis-09.txt


=A0 =A0 =A0 =A0 A new version of I-D, draft-drage-sipping-rfc3455bis= -09.txt
=A0 =A0 =A0 =A0 has been successfully submitted by Keith Drage and posted t= o the
=A0 =A0 =A0 =A0 IETF repository.

=A0 =A0 =A0 =A0 Filename: =A0 =A0 =A0 =A0draft-drage-sipping-rfc3455bis
=A0 =A0 =A0 =A0 Revision: =A0 =A0 =A0 =A009
=A0 =A0 =A0 =A0 Title: =A0 =A0 =A0 =A0 =A0 Private Header (P-Header) Extens= ions to the
=A0 =A0 =A0 =A0 Session Initiation Protocol (SIP) for the 3rd-Generation =A0 =A0 =A0 =A0 Partnership Project (3GPP)
=A0 =A0 =A0 =A0 Creation date: =A0 2013-10-08
=A0 =A0 =A0 =A0 Group: =A0 =A0 =A0 =A0 =A0 Individual Submission
=A0 =A0 =A0 =A0 Number of pages: 47
=A0 =A0 =A0 =A0 URL:
=A0 =A0 =A0 =A0 http://www.ietf.org/internet-<= u>drafts/draft-drage-sipping-rfc3455bis-09.txt
=A0 =A0 =A0 =A0 Status:
=A0 =A0 =A0 =A0 http://datatracker.ietf.org/doc/dr= aft-drage-sipping-rfc3455bis
=A0 =A0 =A0 =A0 Htmlized:
=A0 =A0 =A0 =A0 http://tools.ietf.org/html/draft-dra= ge-sipping-rfc3455bis-09
=A0 =A0 =A0 =A0 Diff:
=A0 =A0 =A0 =A0 http://www.ietf.org/rfcdiff?= url2=3Ddraft-drage-sipping-rfc3455bis-09

=A0 =A0 =A0 =A0 Abstract:
=A0 =A0 =A0 =A0 =A0 =A0 This document describes a set of private Session In= itiation
=A0 =A0 =A0 =A0 Protocol
=A0 =A0 =A0 =A0 =A0 =A0 (SIP) header fields (P-headers) used by the 3rd-Gen= eration
=A0 =A0 =A0 =A0 =A0 =A0 Partnership Project (3GPP), along with their applic= ability,
=A0 =A0 =A0 =A0 which is
=A0 =A0 =A0 =A0 =A0 =A0 limited to particular environments. =A0The P-header= fields are
=A0 =A0 =A0 =A0 for a
=A0 =A0 =A0 =A0 =A0 =A0 variety of purposes within the networks that the pa= rtners use,
=A0 =A0 =A0 =A0 =A0 =A0 including charging and information about the networ= ks a call
=A0 =A0 =A0 =A0 =A0 =A0 traverses.




=A0 =A0 =A0 =A0 Please note that it may take a couple of minutes from the t= ime
=A0 =A0 =A0 =A0 of submission until the htmlized version and diff are avail= able
=A0 =A0 =A0 =A0 at tool= s.ietf.org <http= ://tools.ietf.org>.

=A0 =A0 =A0 =A0 The IETF Secretariat

=A0 =A0 =A0 =A0 =A0 =A0-



_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch


_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

--001a11c38d70882f7304ef77ad0c-- From fluffy@cisco.com Wed Jan 8 10:49:25 2014 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 AA86D1AE0B6 for ; Wed, 8 Jan 2014 10:49:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.739 X-Spam-Level: X-Spam-Status: No, score=-114.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] 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 YpVRNpKgtf6P for ; Wed, 8 Jan 2014 10:49:23 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id CF6191AE076 for ; Wed, 8 Jan 2014 10:49:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=977; q=dns/txt; s=iport; t=1389206955; x=1390416555; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=J2+IXuP4KMAmA0D2P7hp+Fum0rBQ4BsB/++rK1RZl2w=; b=EwlMWdn1641AJSNysuEfII1IeFgZpTLYDJaogLxTUefVtkM1vXTNyHYj uRtuUTAXpvOlNOnC0FiJG3aWZ4MkyqKKqFHgAyWjALIFKw6D7BUfhZ+BB S1TEGr82zgS5sSIt5jrh3GScdRnE7KgjYly20/piUrP1muIhvxM5qu4Eo k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai0FAGSczVKtJXG+/2dsb2JhbABZgws4Vrk2gRQWdIIlAQEBAwF3AgULAgFDCyERJQIEDgWHcAMJCA2/PA2FABMEjHKCEweDJIETBJYrgWyMWoU7gW+BPoIq X-IronPort-AV: E=Sophos;i="4.95,625,1384300800"; d="scan'208";a="296162542" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-4.cisco.com with ESMTP; 08 Jan 2014 18:49:14 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id s08InEWE000917 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 8 Jan 2014 18:49:14 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.76]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0123.003; Wed, 8 Jan 2014 12:49:14 -0600 From: "Cullen Jennings (fluffy)" To: Rifaat Shekh-Yusef Thread-Topic: =?Windows-1252?Q?New_SIP_digest_algorithm_=85_Re:_[dispatch]_New_Version_?= =?Windows-1252?Q?Notification_for_draft-johansson-dispatch-dane-sip-00.tx?= =?Windows-1252?Q?t?= Thread-Index: AQHPDKJSz/DSP7kAEkCu96SQQU4jtw== Date: Wed, 8 Jan 2014 18:49:13 +0000 Message-ID: References: <20140102101042.27427.64547.idtracker@ietfa.amsl.com> <0BA14051-5C7F-4416-8CD2-413347D540D3@edvina.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.164] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dispatch@ietf.org list" Subject: [dispatch] =?windows-1252?q?New_SIP_digest_algorithm_=85_Re=3A__N?= =?windows-1252?q?ew_Version_Notification_for_draft-johansson-dispatch-dan?= =?windows-1252?q?e-sip-00=2Etxt?= 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, 08 Jan 2014 18:49:25 -0000 On Jan 2, 2014, at 11:34 AM, Rifaat Shekh-Yusef wro= te: > Hi Olle, >=20 > >Can we improve upon MD5 digest authentication? >=20 > Take a look at the following HTTPAuth WG document: > https://datatracker.ietf.org/doc/draft-ietf-httpauth-digest/ >=20 > I have been working on this for some time, with SIP in mind. This started= as an attempt to update RFC2617, and now it is a different document that w= ill obsolete RFC2617. > The document updates 3 aspects of RFC2617: > 1. Algorithms agility: use of SHA2 > 2. Internationalization > 3. Username hashing >=20 > I am planning on writing a document to update the digest algorithms for S= IP. >=20 > Regards, > Rifaat >=20 >=20 I suspect that sip core would be the best place to move forward a proposal = like that. Personally, I would probably ague that moving to OAuth might be = a better way to move forward.=20 Cullen (with my individual contribute hat on) From fluffy@cisco.com Wed Jan 8 11:02:17 2014 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 253BC1AE403 for ; Wed, 8 Jan 2014 11:02:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.039 X-Spam-Level: X-Spam-Status: No, score=-115.039 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] 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 Nzfccj5rcxwp for ; Wed, 8 Jan 2014 11:02:15 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 915C41AE3E3 for ; Wed, 8 Jan 2014 11:02:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1646; q=dns/txt; s=iport; t=1389207726; x=1390417326; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=bZpm+xKiuEJ8DwbhKAnn9hRtONBVcF5rkCxOuyN8hOU=; b=kn8k5qqNsVE6wnZOOHGSlFhT4Bop9zGXogGTBU8NWzxUDD28fTM7udBp EXDEaUjPGnkJXtxqO4YP+co2Z2HuJHH8qWMhdWF38Yt7wqCeXAv5QZ4BY shUgepUTxTH0QJZBpCJ3/YHAduZR/IwSqgArr5OwVc+AgNGp+yA4u9WAu s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AisFAOOfzVKtJXG9/2dsb2JhbABZgws4VrpLFnSCLDpRAT5CJwQBiBYNxEAXkjCBEwSYF4EwkGWDLYIq X-IronPort-AV: E=Sophos;i="4.95,625,1384300800"; d="scan'208";a="296165283" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-4.cisco.com with ESMTP; 08 Jan 2014 19:02:06 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id s08J26U8011889 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 8 Jan 2014 19:02:06 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.76]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0123.003; Wed, 8 Jan 2014 13:02:06 -0600 From: "Cullen Jennings (fluffy)" To: "dispatch@ietf.org list" , Olle E Johansson Thread-Topic: Question about draft-johansson-dispatch-dane-sip-00.txt Thread-Index: AQHPDKQftZGSv+rEq0COn61AU3OD+Q== Date: Wed, 8 Jan 2014 19:02:05 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.164] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [dispatch] Question about draft-johansson-dispatch-dane-sip-00.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: Wed, 08 Jan 2014 19:02:17 -0000 I'm a bit confused about if this differs from the procedures specified in h= ttp://tools.ietf.org/html/draft-ietf-dane-srv 1) I was assuming that all we need to do for DANE in SIP was more or less m= ake a draft which is an extension to 3261 (and not a modification of 3261) = that said do what draft-ietf-dane-srv says. So when I read the normative pa= rts of text of draft-johansson-dispatch-dane-sip I have a hard time decidin= g if is saying to do something different than draft-ietf-dane-srv or not. C= an you help make this clear? I would prefer to see the draft crisply separated into what the normative p= art of the draft is and what is gnarly tutorial but actually specified in o= ther specifications.=20 2) Lets say we have a domain example.com that is happily doing SIP with TLS= with a normal cert. But an attacker managed to insert a DNS SRV record tha= t points example.com to a host at attacker.com and get all the DNS signed f= or that. The host at attacker.com does have the private key for the certifi= cate at example.com.=20 In this case, my understanding of your draft is the attack successes and th= e DANE enabled client would successfully connect to attacker.com. Do I have= this right and does this match up with assumptions on how DANE will be be = deployed and used ? I'm not arguing this one way or other yet, I just want = the draft to be very clear and help people understand.=20 BTW - thanks for working on this. We've needed a DANE SIP draft for a long = time. I would guess that this will all end up in sip core but glad to discu= ss it here in meantime.=20 Cullen From pkyzivat@alum.mit.edu Wed Jan 8 11:14:18 2014 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 D4F481AE117 for ; Wed, 8 Jan 2014 11:14:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.935 X-Spam-Level: X-Spam-Status: No, score=-0.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MIME_8BIT_HEADER=0.3, SPF_SOFTFAIL=0.665] 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 wcdl_J8XbCJm for ; Wed, 8 Jan 2014 11:14:17 -0800 (PST) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:64]) by ietfa.amsl.com (Postfix) with ESMTP id 75AF41AE118 for ; Wed, 8 Jan 2014 11:14:16 -0800 (PST) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta07.westchester.pa.mail.comcast.net with comcast id BSkf1n0041c6gX857XE7wv; Wed, 08 Jan 2014 19:14:07 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta23.westchester.pa.mail.comcast.net with comcast id BXE61n00a3ZTu2S3jXE7ru; Wed, 08 Jan 2014 19:14:07 +0000 Message-ID: <52CDA37E.1040804@alum.mit.edu> Date: Wed, 08 Jan 2014 14:14:06 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: dispatch@ietf.org References: <20140102101042.27427.64547.idtracker@ietfa.amsl.com> <0BA14051-5C7F-4416-8CD2-413347D540D3@edvina.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1389208447; bh=Q0iTTQSgQt9b2NRycp6C82u/6pccZItm5EJwsDUstGU=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=VcikfrG5bCxGLdFkolTfsgjpTnPRdlxQ6272rFPS9r+JCCch/zHdrYXXXtMo6tm/E kHKAyJz3LXhkeO2CroS+YKDoA1IHiu3UNiTVrXrd4o11guB6vlVW1k6jYjX1UTrVcx VyBpkvGUr0ZD55h8ZmKajQi5IpL9/pRyqIg9jHaeihoeuq/dMUkkGl6j8x2ID4Wx5K mP93GuIgTQKXxiH+JOITFl9kZomeXkIZg2SEJq36n5DU0D6IBTEPorDqQ7twjNsSX0 W8lVCFtTHMqoPOQuBHTmbzwsR+oDPOV8xJt2+hglP2nJb3vjBJ0fjGPPT5T6SlFSE3 u0uAwqT2H0PYg== Subject: Re: [dispatch] =?windows-1252?q?New_SIP_digest_algorithm_=85_Re=3A__N?= =?windows-1252?q?ew_Version_Notification_for_draft-johansson-dispatch-dan?= =?windows-1252?q?e-sip-00=2Etxt?= 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, 08 Jan 2014 19:14:19 -0000 For both this and dane-sip, sipcore is certainly the obvious candidate. Here in dispatch we have an opportunity to hear from anyone who thinks there are aspects to the work that might need to be considered elsewhere. If there is interest in the work, and no reason to deal with it elsewhere, then we can proceed with it in sipcore. Thanks, Paul On 1/8/14 1:49 PM, Cullen Jennings (fluffy) wrote: > > On Jan 2, 2014, at 11:34 AM, Rifaat Shekh-Yusef wrote: > >> Hi Olle, >> >> >Can we improve upon MD5 digest authentication? >> >> Take a look at the following HTTPAuth WG document: >> https://datatracker.ietf.org/doc/draft-ietf-httpauth-digest/ >> >> I have been working on this for some time, with SIP in mind. This started as an attempt to update RFC2617, and now it is a different document that will obsolete RFC2617. >> The document updates 3 aspects of RFC2617: >> 1. Algorithms agility: use of SHA2 >> 2. Internationalization >> 3. Username hashing >> >> I am planning on writing a document to update the digest algorithms for SIP. >> >> Regards, >> Rifaat >> >> > > I suspect that sip core would be the best place to move forward a proposal like that. Personally, I would probably ague that moving to OAuth might be a better way to move forward. > > Cullen (with my individual contribute hat on) > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From rifaat.ietf@gmail.com Wed Jan 8 12:56:29 2014 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 136311AE1AA for ; Wed, 8 Jan 2014 12:56:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 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, MIME_8BIT_HEADER=0.3, 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 LsXdl7I3J2rD for ; Wed, 8 Jan 2014 12:56:27 -0800 (PST) Received: from mail-ea0-x231.google.com (mail-ea0-x231.google.com [IPv6:2a00:1450:4013:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 5C1D91AE19F for ; Wed, 8 Jan 2014 12:56:27 -0800 (PST) Received: by mail-ea0-f177.google.com with SMTP id n15so1060655ead.8 for ; Wed, 08 Jan 2014 12:56:17 -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=HE9+9E8YMJt9ZSJ5ZC5FFIKl5Aj1Woj3hYacp6AU4GU=; b=QKUDZgma7Kf926lwW+rClDlyCov8274ZYSGLL2gdQC9b37CbEJw7XQYPBN9GNl/N6S R2AGskzkKNmAqVBPYdg/XYYVu7TcJ5iTPGqursxCQsHa6YUzLZmjoOzB/ayCoSb30iYF uu3fsHRr7130xcOouRPZLVBYr1ZHRoQ95o/qEjc4r42PdGUL751nQeovFFMJguTnzehK MqtXVtEZ0M9bym9TmwHNG91AdSxYj6KV+iMLzFDpYn7EIa8mll5mWffaVKQ0LO1QcqXb Mz8wIsZclTeKRgGhfHg+bEFQgzoqMScttcZQxF789tEI41DBHNf0LjUbcKyKvnvyEMNj yU9A== MIME-Version: 1.0 X-Received: by 10.15.43.10 with SMTP id w10mr101886258eev.13.1389214577521; Wed, 08 Jan 2014 12:56:17 -0800 (PST) Received: by 10.14.53.78 with HTTP; Wed, 8 Jan 2014 12:56:17 -0800 (PST) In-Reply-To: References: <20140102101042.27427.64547.idtracker@ietfa.amsl.com> <0BA14051-5C7F-4416-8CD2-413347D540D3@edvina.net> Date: Wed, 8 Jan 2014 15:56:17 -0500 Message-ID: From: Rifaat Shekh-Yusef To: "Cullen Jennings (fluffy)" Content-Type: multipart/alternative; boundary=089e0168164468f9c204ef7bb9ef Cc: "dispatch@ietf.org list" Subject: Re: [dispatch] =?windows-1252?q?New_SIP_digest_algorithm_=85_Re=3A__N?= =?windows-1252?q?ew_Version_Notification_for_draft-johansson-dispa?= =?windows-1252?q?tch-dane-sip-00=2Etxt?= 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, 08 Jan 2014 20:56:29 -0000 --089e0168164468f9c204ef7bb9ef Content-Type: text/plain; charset=ISO-8859-1 Thanks Cullen, Updating the Digest mechanism should be simple and straightforward to allow us to address the algorithms limitation without requiring major changes to the deployed systems. I agree that we need a better solution for SIP that would also allow us to provide a better way of storing the passwords in the DB. I have been thinking about other solutions, but did not have a chance to look at OAuth yet; I will take a look. Regards, Rifaat On Wed, Jan 8, 2014 at 1:49 PM, Cullen Jennings (fluffy) wrote: > > On Jan 2, 2014, at 11:34 AM, Rifaat Shekh-Yusef > wrote: > > > Hi Olle, > > > > >Can we improve upon MD5 digest authentication? > > > > Take a look at the following HTTPAuth WG document: > > https://datatracker.ietf.org/doc/draft-ietf-httpauth-digest/ > > > > I have been working on this for some time, with SIP in mind. This > started as an attempt to update RFC2617, and now it is a different document > that will obsolete RFC2617. > > The document updates 3 aspects of RFC2617: > > 1. Algorithms agility: use of SHA2 > > 2. Internationalization > > 3. Username hashing > > > > I am planning on writing a document to update the digest algorithms for > SIP. > > > > Regards, > > Rifaat > > > > > > I suspect that sip core would be the best place to move forward a proposal > like that. Personally, I would probably ague that moving to OAuth might be > a better way to move forward. > > Cullen (with my individual contribute hat on) > > > --089e0168164468f9c204ef7bb9ef Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks Cullen,

Updating the Digest mech= anism should be simple and straightforward to allow us to address the algor= ithms limitation without requiring major changes to the deployed systems.

I agree that we need a better solution for SIP that wou= ld also allow us to provide a better way of storing the passwords in the DB= .
I have been thinking about other solutions, but did not have a = chance to look at OAuth yet; I will take a look.

Regards,
=A0Rifaat

=


On Wed, Jan 8= , 2014 at 1:49 PM, Cullen Jennings (fluffy) <fluffy@cisco.com> wrote:

On Jan 2, 2014, at 11:34 AM, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:

> Hi Olle,
>
> =A0 =A0 =A0 =A0>Can we improve upon MD5 digest authentication?
>
> Take a look at the following HTTPAuth WG document:
> https://datatracker.ietf.org/doc/draft-ietf-httpauth-d= igest/
>
> I have been working on this for some time, with SIP in mind. This star= ted as an attempt to update RFC2617, and now it is a different document tha= t will obsolete RFC2617.
> The document updates 3 aspects of RFC2617:
> 1. Algorithms agility: use of SHA2
> 2. Internationalization
> 3. Username hashing
>
> I am planning on writing a document to update the digest algorithms fo= r SIP.
>
> Regards,
> =A0Rifaat
>
>

I suspect that sip core would be the best place to move forward a proposal = like that. Personally, I would probably ague that moving to OAuth might be = a better way to move forward.

Cullen (with my individual contribute hat on)



--089e0168164468f9c204ef7bb9ef-- From shida@ntt-at.com Wed Jan 8 22:30:09 2014 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 7E5C01A8028 for ; Wed, 8 Jan 2014 22:30:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_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 9gvpEOhjISej for ; Wed, 8 Jan 2014 22:30:03 -0800 (PST) Received: from gator4135.hostgator.com (gator4135.hostgator.com [192.185.4.147]) by ietfa.amsl.com (Postfix) with ESMTP id 8DE3F1A1F7A for ; Wed, 8 Jan 2014 22:30:03 -0800 (PST) Received: from [50.184.77.69] (port=59294 helo=[192.168.1.23]) by gator4135.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1W197p-0003c9-PN; Thu, 09 Jan 2014 00:29:54 -0600 Content-Type: multipart/alternative; boundary="Apple-Mail=_E76C1CD3-1BE4-4798-BC26-1A2FEF699573" Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Shida Schubert In-Reply-To: Date: Wed, 8 Jan 2014 22:29:49 -0800 Message-Id: <5863E5DF-F01A-44DC-B0E6-74D1763AE178@ntt-at.com> References: <20130912005949.3447.42089.idtracker@ietfa.amsl.com> <523124B0.2000305@ntt-at.co.jp> To: Mary Barnes X-Mailer: Apple Mail (2.1822) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator4135.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ntt-at.com X-BWhitelist: no X-Source-IP: 50.184.77.69 X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.1.23]) [50.184.77.69]:59294 X-Source-Auth: shida.schubert+tingle.jp X-Email-Count: 1 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQxMzUuaG9zdGdhdG9yLmNvbQ== Cc: DISPATCH Subject: Re: [dispatch] New Version of draft-vanelburg-dispatch-private-network-ind 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, 09 Jan 2014 06:30:09 -0000 --Apple-Mail=_E76C1CD3-1BE4-4798-BC26-1A2FEF699573 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi Mary; Thanks for reviewing the document again.=20 On Jan 6, 2014, at 3:03 PM, Mary Barnes = wrote: > Hi all, >=20 > I have reviewed the revised version and I just a few final comments. >=20 > - Section 1.5, first bullet in the bulleted list: either change "an = emergency calls" to "an emergency call" or "emergency calls" >=20 I will fix it with "emergency calls" > - Section 3.6. "require the Specifying a Spec (T)." -> "require = specifying a Spec(T)" or "require the specification of a Spec(T)" >=20 =20 I will fix it with "require the specification of a Spec(T)" > - Section 5, I had suggested the the requirements be consistent in = usage of 2119 language. One of the requirements (R6) was changed, but = R2 and R3 were not. Was there a specific reason not to make those = suggested changes? =20 >=20 > R2: "The indication from R1 can be inserted by a SIP proxy" -> "The = indication from R1 MAY be inserted by a SIP proxy" =20 > R3: "The indication from R1 can be removed by a SIP proxy" -> "The = indication from R1 MAY be removed by a SIP proxy" So I reverted the change after Keith told that the requirements above = is not stating=20 a normative behaviour and that he believes "can" is more appropriate.=20 I am okay either way.=20 I will create a version with "MAY".=20 Keith, please provide comments if you have a strong opposition to = changing it to "MAY". Thanks!=20 Shida >=20 > Thanks, > Mary.=20 >=20 >=20 > On Tue, Oct 29, 2013 at 9:11 AM, Mary Barnes = wrote: > In reviewing the document in preparation for the PROTO write-up, I = have a few comments (minor and nits) that should be addressed prior to = the document being progressed. >=20 > Regards, > Mary. >=20 > Comments: > --------------- >=20 > - General: domains used in this document must use a reserved domain = such as "example.com" and must not use real domains. Thus, all = occurrences of ericsson.com need to be changed to example.com >=20 > - Section 1.5. Bulleted list, first bullet. I would suggest you just = leave out the mention of LI. Emergency services should be a sufficient = example. =20 >=20 > - Section 1.5, last numbered list, item 2. I had a hard time groking = this sentence and had to read several times. I would suggest rewording = something like (if I've properly interpreted the intent): > OLD: > Different nodes spanning over different networks may need to be > able to act differently on type of traffic, when implicit = schemes > are used, it would require distribution of such enterprise > specific logic over multiple nodes in multiple operators. That > is clearly not a manageable architecture and solution. >=20 > NEW:=20 > Nodes spanning multiple networks often need to have different=20= > behavior depending upon the type of traffic. When this is done = using implicit > schemes, enterprise specific logic must be distributed across = multiple > nodes in multiple operator's networks. =20 > That is clearly not a manageable architecture and solution. >=20 >=20 > - Section 1.5, last sentence. I don't think that statement is = sufficient for what this document is doing. I would suggest you change = that sentence to something like the following: > OLD: > Given the above background this document will formulate = requirements > for SIP to support an explicit private network indication. >=20 > NEW:=20 > Based on the background provided, this document formulates = requirements > for SIP to support an explicit private network indication and = defines=20 > a P-header, P-Private-Network-Indication, to support those = requirements.=20 >=20 >=20 > - Section 3, next to last paragraph. I'm not sure what is meant by = "the filling out a Spec(T)". I don't see "filling" used as a concept in = RFC 3324. Perhaps, "specifying a Spec(T)" is more consistent with = terminology in RFC 3324.=20 >=20 > - Section 5. In general, the requirements are not specific = consistently - i.e., some use 2119 language and others not and there is = not consistent capitalization. I would suggest the following changes. > R2: "The indication from R1 can be inserted by a SIP proxy" -> "The = indication from R1 MAY be inserted by a SIP proxy" =20 > R3: "The indication from R1 can be removed by a SIP proxy" -> "The = indication from R1 MAY be removed by a SIP proxy" > R6: "must" -> "MUST" >=20 > - Section 6, 2nd paragraph. The "can" in the first sentence should be = a "MAY" and the sentence needs to be split into two: > OLD: > A proxy server which handles a message can insert such a P-Private- > Network-Indication header field into the message based on > authentication of the source of a message, configuration or local > policy, and forward it to other proxies in the same administrative > domain or proxies in trusted domain to be handled as private = network > traffic.=20 >=20 > NEW:=20 > A proxy server which handles a message MAY insert such a P-Private- > Network-Indication header field into the message based on > authentication of the source of a message, configuration or local > policy. A proxy server MAY forward the message to other proxies in = the=20 > same administrative domain or proxies in a trusted=20 > domain to be handled as private network traffic.=20 >=20 >=20 >=20 > Section 9. You should be explicit about the header name in this = section. The text in the first paragraph needs some work. At a minimum = you need to change the "not supposed to" to something more definitive as = all security issues arise because someone does something they're not = supposed to. I would suggest at least making the following change: > OLD: > The private network indication defined in this document is to be = used > in an environment where elements are trusted and where attackers = are > not supposed to have access to the protocol messages between those > elements. Traffic protection between network elements is sometimes > achieved by using IPsec and sometimes by physical protection of the > network. In any case, the environment where the private network > indication will be used ensures the integrity and the = confidentiality > of the contents of this header field. > NEW: > The private network indication defined in this document MUST only = be used > in an environment where elements are trusted and where attackers = are > do not have access to the protocol messages between those > elements. Traffic protection between network elements can be > achieved by using IPsec and sometimes by physical protection of the > network. In any case, the environment where the private network > indication will be used ensures the integrity and the = confidentiality > of the contents of this header field. >=20 >=20 > Nits: > ------ > - Section 1.1: "3rd-Generqation" -> 3rd-Generation =20 > - The terms "break-in" and "break-out" traffic are used several places = in the document, but this term is never defined. These terms should be = defined in Section 3.=20 > - Figures should have Titles for readability >=20 >=20 >=20 > On Wed, Sep 11, 2013 at 9:19 PM, Mayumi Ohsugi = wrote: > Hi, >=20 > I have submitted the following draft: >=20 > = http://www.ietf.org/internet-drafts/draft-vanelburg-dispatch-private-netwo= rk-ind-03.txt >=20 > The draft reflects all the comments discussed in DISPATCH list. >=20 > The major changes are as follows: >=20 > - corrected the abstract > - corrected the term "common domain" to "pre-arranged domain" > - added 7.1.4 "P-Private-Network-Indication verification" > - editorial changes > = Regards, > Mayumi > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch >=20 >=20 --Apple-Mail=_E76C1CD3-1BE4-4798-BC26-1A2FEF699573 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1

Hi Mary;

 Thanks for reviewing the document again. 

On Jan 6, 2014, at 3:03 PM, Mary Barnes <mary.ietf.barnes@gmail.com> wrote:

Hi all,

I have reviewed the revised version and I just a few final comments.

- Section 1.5, first bullet in the bulleted list: either change "an emergency calls" to "an emergency call" or "emergency calls"


 I will fix it with "emergency calls"

- Section 3.6.  "require the Specifying a Spec (T)." -> "require specifying a Spec(T)" or "require the specification of a Spec(T)"

 
 I will fix it with "require the specification of a Spec(T)"

- Section 5, I had suggested the the requirements be consistent in usage of 2119 language.  One of the requirements (R6) was changed, but R2 and R3 were not.  Was there a specific reason not to make those suggested changes?   

R2:   "The indication from R1 can be inserted by a SIP proxy" -> "The indication from R1 MAY be inserted by a SIP proxy"   
R3: "The indication from R1 can be removed by a SIP proxy" -> "The indication from R1 MAY be removed by a SIP proxy"

 So I reverted the change after Keith told that the requirements above is not stating 
a normative behaviour and that he believes "can" is more appropriate. 

 I am okay either way. 

 I will create a version with "MAY". 

 Keith, please provide comments if you have a strong opposition to changing it to "MAY".

 Thanks! 
  Shida


Thanks,
Mary. 


On Tue, Oct 29, 2013 at 9:11 AM, Mary Barnes <mary.ietf.barnes@gmail.com> wrote:
In reviewing the document in preparation for the PROTO write-up, I have a few comments (minor and nits) that should be addressed prior to the document being progressed.

Regards,
Mary.

Comments:
---------------

- General: domains used in this document must use a reserved domain such as "example.com" and must not use real domains. Thus, all occurrences of ericsson.com need to be changed to example.com

- Section 1.5.  Bulleted list, first bullet. I would suggest you just leave out the mention of LI.  Emergency services should be a sufficient example.  

- Section 1.5, last numbered list, item 2.  I had a hard time groking this sentence and had to read several times. I would suggest rewording something like (if I've properly interpreted the intent):
OLD:
       Different nodes spanning over different networks may need to be
       able to act differently on type of traffic, when implicit schemes
       are used, it would require distribution of such enterprise
       specific logic over multiple nodes in multiple operators.  That
       is clearly not a manageable architecture and solution.

NEW: 
       Nodes spanning multiple networks often need to have different 
       behavior depending upon the type of traffic.  When this is done using implicit
       schemes, enterprise specific logic must be distributed across multiple
       nodes in multiple operator's networks.  
       That is clearly not a manageable architecture and solution.


- Section 1.5, last sentence.  I don't think that statement is sufficient for what this document is doing. I would suggest you change that sentence to something like the following:
OLD:
   Given the above background this document will formulate requirements
   for SIP to support an explicit private network indication.

NEW: 
   Based on the background provided, this document formulates requirements
   for SIP to support an explicit private network indication and defines 
   a P-header, P-Private-Network-Indication, to support those requirements.


- Section 3, next to last paragraph.  I'm not sure what is meant by "the filling out a Spec(T)". I don't see "filling" used as a concept in RFC 3324.  Perhaps, "specifying a Spec(T)" is more consistent with terminology in RFC 3324. 

- Section 5.  In general, the requirements are not specific consistently - i.e., some use 2119 language and others not and there is not consistent capitalization.  I would suggest the following changes.
R2:   "The indication from R1 can be inserted by a SIP proxy" -> "The indication from R1 MAY be inserted by a SIP proxy"   
R3: "The indication from R1 can be removed by a SIP proxy" -> "The indication from R1 MAY be removed by a SIP proxy"
R6: "must" -> "MUST"

- Section 6, 2nd paragraph. The "can" in the first sentence should be a "MAY" and the sentence needs to be split into two:
OLD:
   A proxy server which handles a message can insert such a P-Private-
   Network-Indication header field into the message based on
   authentication of the source of a message, configuration or local
   policy, and forward it to other proxies in the same administrative
   domain or proxies in trusted domain to be handled as private network
   traffic.

NEW: 
   A proxy server which handles a message MAY insert such a P-Private-
   Network-Indication header field into the message based on
   authentication of the source of a message, configuration or local
   policy.  A proxy server MAY forward the message to other proxies in the 
   same administrative domain or proxies in a trusted 
   domain to be handled as private network traffic.

Section 9.  You should be explicit about the header name in this section.  The text in the first paragraph needs some work.  At a minimum you need to change the "not supposed to" to something more definitive as all security issues arise because someone does something they're not supposed to.   I would suggest at least making the following change:
OLD:
   The private network indication defined in this document is to be used
   in an environment where elements are trusted and where attackers are
   not supposed to have access to the protocol messages between those
   elements.  Traffic protection between network elements is sometimes
   achieved by using IPsec and sometimes by physical protection of the
   network.  In any case, the environment where the private network
   indication will be used ensures the integrity and the confidentiality
   of the contents of this header field.
NEW:
   The private network indication defined in this document MUST only be used
   in an environment where elements are trusted and where attackers are
   do not have access to the protocol messages between those
   elements.  Traffic protection between network elements can be
   achieved by using IPsec and sometimes by physical protection of the
   network.  In any case, the environment where the private network
   indication will be used ensures the integrity and the confidentiality
   of the contents of this header field.


Nits:
------
- Section 1.1:  "3rd-Generqation" -> 3rd-Generation  
- The terms "break-in" and "break-out" traffic are used several places in the document, but this term is never defined.  These terms should be defined in Section 3. 
- Figures should have Titles for readability



On Wed, Sep 11, 2013 at 9:19 PM, Mayumi Ohsugi <mayumi.ohsugi@ntt-at.co.jp> wrote:
Hi,

I have submitted the following draft:

http://www.ietf.org/internet-drafts/draft-vanelburg-dispatch-private-network-ind-03.txt

The draft reflects all the comments discussed in DISPATCH list.

The major changes are as follows:

- corrected the abstract
- corrected the term "common domain" to "pre-arranged domain"
- added 7.1.4 "P-Private-Network-Indication verification"
- editorial changes
                                                                                  Regards,
Mayumi
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch



--Apple-Mail=_E76C1CD3-1BE4-4798-BC26-1A2FEF699573-- From oej@edvina.net Wed Jan 8 23:39:18 2014 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 34C331AE0E3 for ; Wed, 8 Jan 2014 23:39:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 swd3VSxAJ5M8 for ; Wed, 8 Jan 2014 23:39:15 -0800 (PST) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 775CF1AE09B for ; Wed, 8 Jan 2014 23:39:14 -0800 (PST) Received: from [192.168.40.13] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 2BC2B93C2A1; Thu, 9 Jan 2014 07:39:04 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: "Olle E. Johansson" In-Reply-To: Date: Thu, 9 Jan 2014 08:39:03 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0A864EF2-E6F3-4B62-A986-8FCEA4647AC0@edvina.net> References: To: "Cullen Jennings (fluffy)" X-Mailer: Apple Mail (2.1827) Cc: "dispatch@ietf.org list" Subject: Re: [dispatch] Question about draft-johansson-dispatch-dane-sip-00.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: Thu, 09 Jan 2014 07:39:18 -0000 On 08 Jan 2014, at 20:02, Cullen Jennings (fluffy) = wrote: >=20 > I'm a bit confused about if this differs from the procedures specified = in http://tools.ietf.org/html/draft-ietf-dane-srv >=20 > 1) I was assuming that all we need to do for DANE in SIP was more or = less make a draft which is an extension to 3261 (and not a modification = of 3261) that said do what draft-ietf-dane-srv says. So when I read the = normative parts of text of draft-johansson-dispatch-dane-sip I have a = hard time deciding if is saying to do something different than = draft-ietf-dane-srv or not. Can you help make this clear? I need to go back and compare and maybe remove parts that are = overlapping. On the other hand I want to have a document that is very = clear for SIP developers. I guess the only difference is the way we = start with a SIP uri domain part to look up the SRV. Remember that I'm still a newbie in this document-writing space :-) The "updates 5922" part will be removed in a coming edition of this = draft. It's a misunderstanding on my behalf. >=20 > I would prefer to see the draft crisply separated into what the = normative part of the draft is and what is gnarly tutorial but actually = specified in other specifications.=20 ok. >=20 >=20 > 2) Lets say we have a domain example.com that is happily doing SIP = with TLS with a normal cert. But an attacker managed to insert a DNS SRV = record that points example.com to a host at attacker.com and get all the = DNS signed for that. The host at attacker.com does have the private key = for the certificate at example.com.=20 >=20 > In this case, my understanding of your draft is the attack successes = and the DANE enabled client would successfully connect to attacker.com. = Do I have this right and does this match up with assumptions on how DANE = will be be deployed and used ? I'm not arguing this one way or other = yet, I just want the draft to be very clear and help people understand.=20= Well if attackers can insert records and get them signed, then the hole = assumption of DANE being a secure platform falls on its head. It's like = saying "If an attacker can get a certificate for fluffy.com signed by a = well-known CA then people will trust the attackers web site to be owned = by fluffy." Yes. And btw, that has happend... That's one of the target scenarios that DANE is trying to stop by being = able to specify the CA used for a service in a domain in the signed = zone. I guess we will have to look at DNS updates and how they're being signed = at some point. But that's out of scope for this group. >=20 >=20 > BTW - thanks for working on this. We've needed a DANE SIP draft for a = long time. I would guess that this will all end up in sip core but glad = to discuss it here in meantime.=20 Your welcome. /O >=20 >=20 > Cullen >=20 From keith.drage@alcatel-lucent.com Thu Jan 9 03:06:31 2014 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 624E41AE273 for ; Thu, 9 Jan 2014 03:06:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] 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 8EASjEad4z5e for ; Thu, 9 Jan 2014 03:06:27 -0800 (PST) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id 7F9AD1AE262 for ; Thu, 9 Jan 2014 03:06:27 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s09B6BoF011468 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 9 Jan 2014 05:06:12 -0600 (CST) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s09B679Z017447 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 9 Jan 2014 12:06:10 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.203]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Thu, 9 Jan 2014 12:05:46 +0100 From: "DRAGE, Keith (Keith)" To: Shida Schubert , Mary Barnes Thread-Topic: [dispatch] New Version of draft-vanelburg-dispatch-private-network-ind Thread-Index: AQHO1LDOad+HXPRI7U+wBzsQbNSDfpp4rP2AgAOhQoCAAFshYA== Date: Thu, 9 Jan 2014 11:05:45 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B100BA1@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <20130912005949.3447.42089.idtracker@ietfa.amsl.com> <523124B0.2000305@ntt-at.co.jp> <5863E5DF-F01A-44DC-B0E6-74D1763AE178@ntt-at.com> In-Reply-To: <5863E5DF-F01A-44DC-B0E6-74D1763AE178@ntt-at.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: multipart/alternative; boundary="_000_949EF20990823C4C85C18D59AA11AD8B100BA1FR712WXCHMBA11zeu_" MIME-Version: 1.0 Cc: DISPATCH Subject: Re: [dispatch] New Version of draft-vanelburg-dispatch-private-network-ind 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, 09 Jan 2014 11:06:31 -0000 --_000_949EF20990823C4C85C18D59AA11AD8B100BA1FR712WXCHMBA11zeu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The text from RFC 2119 states: 5. MAY This word, or the adjective "OPTIONAL", mean that an item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item. An implementation which does not include a particular option MUST be prepared to interoperate with another implementation which does include the option, though perhaps with reduced functionality. In the same vein an implementation which does include a particular option MUST be prepared to interoperate with another implementation which does not include the option (except, of course, for the feature the option provides.) My belief is that we are not defining an option here, and it is certainly n= ot a vendor decision. Further we are not identifying an interoperability is= sue here. We are defining a possibility that a valid implementation can take. If you go to the procedures you will see both these items are covered with = "If MUST" type sentences. There is no specified optionality. Keith ________________________________ From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Shida Schube= rt Sent: 09 January 2014 06:30 To: Mary Barnes Cc: DISPATCH Subject: Re: [dispatch] New Version of draft-vanelburg-dispatch-private-net= work-ind Hi Mary; Thanks for reviewing the document again. On Jan 6, 2014, at 3:03 PM, Mary Barnes > wrote: Hi all, I have reviewed the revised version and I just a few final comments. - Section 1.5, first bullet in the bulleted list: either change "an emergen= cy calls" to "an emergency call" or "emergency calls" I will fix it with "emergency calls" - Section 3.6. "require the Specifying a Spec (T)." -> "require specifying= a Spec(T)" or "require the specification of a Spec(T)" I will fix it with "require the specification of a Spec(T)" - Section 5, I had suggested the the requirements be consistent in usage of= 2119 language. One of the requirements (R6) was changed, but R2 and R3 we= re not. Was there a specific reason not to make those suggested changes? R2: "The indication from R1 can be inserted by a SIP proxy" -> "The indic= ation from R1 MAY be inserted by a SIP proxy" R3: "The indication from R1 can be removed by a SIP proxy" -> "The indicati= on from R1 MAY be removed by a SIP proxy" So I reverted the change after Keith told that the requirements above is n= ot stating a normative behaviour and that he believes "can" is more appropriate. I am okay either way. I will create a version with "MAY". Keith, please provide comments if you have a strong opposition to changing= it to "MAY". Thanks! Shida Thanks, Mary. On Tue, Oct 29, 2013 at 9:11 AM, Mary Barnes > wrote: In reviewing the document in preparation for the PROTO write-up, I have a f= ew comments (minor and nits) that should be addressed prior to the document= being progressed. Regards, Mary. Comments: --------------- - General: domains used in this document must use a reserved domain such as= "example.com" and must not use real domains. Thus, al= l occurrences of ericsson.com need to be changed to e= xample.com - Section 1.5. Bulleted list, first bullet. I would suggest you just leave= out the mention of LI. Emergency services should be a sufficient example. - Section 1.5, last numbered list, item 2. I had a hard time groking this = sentence and had to read several times. I would suggest rewording something= like (if I've properly interpreted the intent): OLD: Different nodes spanning over different networks may need to be able to act differently on type of traffic, when implicit schemes are used, it would require distribution of such enterprise specific logic over multiple nodes in multiple operators. That is clearly not a manageable architecture and solution. NEW: Nodes spanning multiple networks often need to have different behavior depending upon the type of traffic. When this is done usin= g implicit schemes, enterprise specific logic must be distributed across multip= le nodes in multiple operator's networks. That is clearly not a manageable architecture and solution. - Section 1.5, last sentence. I don't think that statement is sufficient f= or what this document is doing. I would suggest you change that sentence to= something like the following: OLD: Given the above background this document will formulate requirements for SIP to support an explicit private network indication. NEW: Based on the background provided, this document formulates requirements for SIP to support an explicit private network indication and defines a P-header, P-Private-Network-Indication, to support those requirements. - Section 3, next to last paragraph. I'm not sure what is meant by "the fi= lling out a Spec(T)". I don't see "filling" used as a concept in RFC 3324. = Perhaps, "specifying a Spec(T)" is more consistent with terminology in RFC= 3324. - Section 5. In general, the requirements are not specific consistently - = i.e., some use 2119 language and others not and there is not consistent cap= italization. I would suggest the following changes. R2: "The indication from R1 can be inserted by a SIP proxy" -> "The indic= ation from R1 MAY be inserted by a SIP proxy" R3: "The indication from R1 can be removed by a SIP proxy" -> "The indicati= on from R1 MAY be removed by a SIP proxy" R6: "must" -> "MUST" - Section 6, 2nd paragraph. The "can" in the first sentence should be a "MA= Y" and the sentence needs to be split into two: OLD: A proxy server which handles a message can insert such a P-Private- Network-Indication header field into the message based on authentication of the source of a message, configuration or local policy, and forward it to other proxies in the same administrative domain or proxies in trusted domain to be handled as private network traffic. NEW: A proxy server which handles a message MAY insert such a P-Private- Network-Indication header field into the message based on authentication of the source of a message, configuration or local policy. A proxy server MAY forward the message to other proxies in the same administrative domain or proxies in a trusted domain to be handled as private network traffic. Section 9. You should be explicit about the header name in this section. = The text in the first paragraph needs some work. At a minimum you need to = change the "not supposed to" to something more definitive as all security i= ssues arise because someone does something they're not supposed to. I wou= ld suggest at least making the following change: OLD: The private network indication defined in this document is to be used in an environment where elements are trusted and where attackers are not supposed to have access to the protocol messages between those elements. Traffic protection between network elements is sometimes achieved by using IPsec and sometimes by physical protection of the network. In any case, the environment where the private network indication will be used ensures the integrity and the confidentiality of the contents of this header field. NEW: The private network indication defined in this document MUST only be use= d in an environment where elements are trusted and where attackers are do not have access to the protocol messages between those elements. Traffic protection between network elements can be achieved by using IPsec and sometimes by physical protection of the network. In any case, the environment where the private network indication will be used ensures the integrity and the confidentiality of the contents of this header field. Nits: ------ - Section 1.1: "3rd-Generqation" -> 3rd-Generation - The terms "break-in" and "break-out" traffic are used several places in t= he document, but this term is never defined. These terms should be defined= in Section 3. - Figures should have Titles for readability On Wed, Sep 11, 2013 at 9:19 PM, Mayumi Ohsugi > wrote: Hi, I have submitted the following draft: http://www.ietf.org/internet-drafts/draft-vanelburg-dispatch-private-networ= k-ind-03.txt The draft reflects all the comments discussed in DISPATCH list. The major changes are as follows: - corrected the abstract - corrected the term "common domain" to "pre-arranged domain" - added 7.1.4 "P-Private-Network-Indication verification" - editorial changes = Regards, Mayumi _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch --_000_949EF20990823C4C85C18D59AA11AD8B100BA1FR712WXCHMBA11zeu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
The text from RFC 2119 states:
 
5. MAY   This word, or the adjective "OPTIONAL", mean that a=
n item is
   truly optional.  One vendor may choose to include the item because a
   particular marketplace requires it or because the vendor feels that
   it enhances the product while another vendor may omit the same item.
   An implementation which does not include a particular option MUST be
   prepared to interoperate with another implementation which does
   include the option, though perhaps with reduced functionality. In the
   same vein an implementation which does include a particular option
   MUST be prepared to interoperate with another implementation which
   does not include the option (except, of course, for the feature the
   option provides.)

M=
y belief is that we are not defining&nbs=
p;an option here, and it is certainly no=
t a vendor decision. Furt=
her we are not identifying an interoperability issue here.
We are=
 defining a possibility that a valid implementation can take.
= 
If you=
 go to the procedures you will see both these items are covered with "=
If <condition> MUST" type sentences. There is no specified optio=
nality.
= 
Keith<=
/span>
From: dispatch [mailto:dispatch-bou= nces@ietf.org] On Behalf Of Shida Schubert
Sent: 09 January 2014 06:30
To: Mary Barnes
Cc: DISPATCH
Subject: Re: [dispatch] New Version of draft-vanelburg-dispatch-priv= ate-network-ind


Hi Mary;

 Thanks for reviewing the document again. 

On Jan 6, 2014, at 3:03 PM, Mary Barnes <mary.ietf.barnes@gmail.com> wrote:

Hi all,

I have reviewed the revised version and I just a few final comments.

- Section 1.5, first bullet in the bulleted list: either change "= an emergency calls" to "an emergency call" or "emergenc= y calls"


 I will fix it with "emergency calls"

- Section 3.6.  "require the Specifying a Spec (T)." -&= gt; "require specifying a Spec(T)" or "require the specifica= tion of a Spec(T)"

 
 I will fix it with "require the specification of a Spec(T)&= quot;

- Section 5, I had suggested the the requirements be consistent in usa= ge of 2119 language.  One of the requirements (R6) was changed, but R2= and R3 were not.  Was there a specific reason not to make those sugge= sted changes?   

R2:   &q= uot;The indication from= R1 can be inserted by a SIP proxy" -> "The indication from R1 MAY be inserted by a SIP proxy"   
R3: "The indication from R1 can= be removed by a SIP proxy" -> "The indication from R1 MAY be removed by a SIP proxy"

 So I reverted the change after Keith told that the requirements = above is not stating 
a normative behaviour and that he believes "can" is more app= ropriate. 

 I am okay either way. 

 I will create a version with "MAY". 

 Keith, please provide comments if you have a strong opposition t= o changing it to "MAY".

 Thanks! 
  Shida


Thanks,
Mary. 


On Tue, Oct 29, 2013 at 9:11 AM, Mary Barnes <mary.ie= tf.barnes@gmail.com> wrote:
In reviewing the document in preparation for the PROTO wri= te-up, I have a few comments (minor and nits) that should be addressed prio= r to the document being progressed.

Regards,
Mary.

Comments:
---------------

- General: domains used in this document must use a reserved domain su= ch as "example.com" and must not use real domains. Thus, all occurrences of ericsson.com need to= be changed to example.com

- Section 1.5.  Bulleted list, first bullet. I would suggest you = just leave out the mention of LI.  Emergency services should be a suff= icient example.  

- Section 1.5, last numbered list, item 2.  I had a hard time gro= king this sentence and had to read several times. I would suggest rewording= something like (if I've properly interpreted the intent):
OLD:
       Different nodes spanning over different networks may ne=
ed to be
       able to act differently on type of traffic, when implicit schemes
       are used, it would require distribution of such enterprise
       specific logic over multiple nodes in multiple operators.  That
       is clearly not a manageable architecture and solution.

NEW: 
       Nodes spanning multiple networks often need to hav=
e different 
       behavior depending u=
pon the type of traffic.  When this is done using implicit
       schemes, enterprise specific logic must be distributed =
across multiple
       nodes in multiple operator's networks.  
       That is clearly not a manageable architecture and solut=
ion.


- Section 1.5, last sentence.  I don't think that statement is su= fficient for what this document is doing. I would suggest you change that s= entence to something like the following:
OLD:
   Given the above background this document will formulate req=
uirements
   for SIP to support an explicit private network indication.

NEW: 
   Based on the background provided, this document formulates =
requirements
   for SIP to support an explicit private network indication and defines 

   a P-header, P-Private-Network-Indication, to support those =
requirements.
- Section 3, next to last paragraph.  I'm not sure what is meant = by "the filling out a Spec(T)". I don't see "filling" u= sed as a concept in RFC 3324.  Perhaps, "specifying a Spec(T)&quo= t; is more consistent with terminology in RFC 3324. 

- Section 5.  In general, the requirements are not specific consi= stently - i.e., some use 2119 language and others not and there is not cons= istent capitalization.  I would suggest the following changes.
R2:   "T= he indication from R1 can be inserted by a SIP proxy" -> "The indication from = R1 MAY be inserted by a SIP proxy"   
R3: "The indi= cation from R1 can be removed by a SIP proxy" -> "The indication from R1 MAY b= e removed by a SIP proxy"
R6: "must= " -> "MUST"

- Section 6, 2= nd paragraph. The "can" in the first sentence should be a "M= AY" and the sente= nce needs to be split into two:
OLD:
   A proxy server which handles a message can insert such a P-=
Private-
   Network-Indication header field into the message based on
   authentication of the source of a message, configuration or local
   policy, and forward it to other proxies in the same administrative
   domain or proxies in trusted domain to be handled as private network
   traffic.

NEW: 
   A proxy server which handles a message MAY insert such a P-=
Private-
   Network-Indication header field into the message based on
   authentication of the source of a message, configuration or local
   policy.  A proxy server MAY forward the message to other proxies in the&=
nbsp;
   same administrative domain or proxies in a trusted 

   domain to be handled as private network traffic.
Section 9.  You should be expli= cit about the header name in this section.  The text in the first para= graph needs some work.  At a minimum you need to change the "not = supposed to" to something more definitive as all security issues arise because someone does something they're not supposed to.  = ; I would suggest at least making the following change:
OLD:
   The private network indication defined in this document is =
to be used
   in an environment where elements are trusted and where attackers are
   not supposed to have access to the protocol messages between those
   elements.  Traffic protection between network elements is sometimes
   achieved by using IPsec and sometimes by physical protection of the
   network.  In any case, the environment where the private network
   indication will be used ensures the integrity and the confidentiality
   of the contents of this header field.
NEW:
   The private network indication defined in this document MUS=
T only be used
   in an environment where elements are trusted and where attackers are
   do not have access to the protocol messages between those
   elements.  Traffic protection between network elements can be
   achieved by using IPsec and sometimes by physical protection of the
   network.  In any case, the environment where the private network
   indication will be used ensures the integrity and the confidentiality
   of the contents of this header field.


Nits:
------
- Section 1.1:  "3rd-Generqation" -> 3rd-Generation  
- The terms "= break-in" and "break-out" traffic are used several places in= the document, but this term is never defined.  These terms should be = defined in Section 3. 
- Figures should h= ave Titles for readability



On Wed, Sep 11, 2013 at 9:19 PM, Mayumi Ohsugi <mayumi.ohsugi@ntt-at.co.jp> wrote:
Hi,

I have submitted the following draft:

http://www.ietf.org/internet-= drafts/draft-vanelburg-dispatch-private-network-ind-03.tx= t

The draft reflects all the comments discussed in DISPATCH list.

The major changes are as follows:

- corrected the abstract
- corrected the term "common domain" to "pre-arranged domain= "
- added 7.1.4 "P-Private-Network-Indication verification"
- editorial changes
                     = ;                     &nb= sp;                     &= nbsp;                 Regards,
Mayumi
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch



--_000_949EF20990823C4C85C18D59AA11AD8B100BA1FR712WXCHMBA11zeu_-- From mary.ietf.barnes@gmail.com Thu Jan 9 07:23:03 2014 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 039F01AE3E7 for ; Thu, 9 Jan 2014 07:23:03 -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 aPiIoXfK7qw0 for ; Thu, 9 Jan 2014 07:22:59 -0800 (PST) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 59D761AE3E8 for ; Thu, 9 Jan 2014 07:22:59 -0800 (PST) Received: by mail-wi0-f171.google.com with SMTP id bz8so7074172wib.10 for ; Thu, 09 Jan 2014 07:22:49 -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=lav2C/jR42cxEtBH5fjq86xcsideMkPdaXzvTc8DCUo=; b=h9JaHtk0d7ytc97nAbuaIby3ZnemlLUPE7yxkr7XtrDtuj46nSUSZJhtc9IwB1shiB e4c9mxpvMLZ2fHRzUDTJGFBfW7ek+lhiUH9+9xBZVe8fDp0FSqAAgqJH+fY1cY9LGnZN MC6wU7Gdm01yJPyotK+3VlK0T0eLQ3jpC763sna52xUZaYN8u4ZGj1E5bFMVqTvw+EtT v6VQMyz964AvMljSe1/V+KL5U9fShEtRSv7kFstS29JaSrPtE+eED3TItd60q3HNMIJj X3FKn81SH281dqpv/Y6zFvkX+UBxVF9zwWw6KujxBO1RRqznStWPX/9u/8CtPnR0fVo7 r80w== MIME-Version: 1.0 X-Received: by 10.194.170.133 with SMTP id am5mr3512644wjc.42.1389280968973; Thu, 09 Jan 2014 07:22:48 -0800 (PST) Received: by 10.216.172.9 with HTTP; Thu, 9 Jan 2014 07:22:48 -0800 (PST) In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B100BA1@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <20130912005949.3447.42089.idtracker@ietfa.amsl.com> <523124B0.2000305@ntt-at.co.jp> <5863E5DF-F01A-44DC-B0E6-74D1763AE178@ntt-at.com> <949EF20990823C4C85C18D59AA11AD8B100BA1@FR712WXCHMBA11.zeu.alcatel-lucent.com> Date: Thu, 9 Jan 2014 09:22:48 -0600 Message-ID: From: Mary Barnes To: "DRAGE, Keith (Keith)" Content-Type: multipart/alternative; boundary=089e0122e92ea6235c04ef8b2e47 Cc: DISPATCH Subject: Re: [dispatch] New Version of draft-vanelburg-dispatch-private-network-ind 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, 09 Jan 2014 15:23:03 -0000 --089e0122e92ea6235c04ef8b2e47 Content-Type: text/plain; charset=ISO-8859-1 Then, why are those even requirements? Mary. On Thu, Jan 9, 2014 at 5:05 AM, DRAGE, Keith (Keith) < keith.drage@alcatel-lucent.com> wrote: > The text from RFC 2119 states: > > > 5. MAY This word, or the adjective "OPTIONAL", mean that an item is > truly optional. One vendor may choose to include the item because a > particular marketplace requires it or because the vendor feels that > it enhances the product while another vendor may omit the same item. > An implementation which does not include a particular option MUST be > prepared to interoperate with another implementation which does > include the option, though perhaps with reduced functionality. In the > same vein an implementation which does include a particular option > MUST be prepared to interoperate with another implementation which > does not include the option (except, of course, for the feature the > option provides.) > > > My belief is that we are not defining an option here, and it is certainly not a vendor decision.Further we are not identifying an interoperability issue here. > > We are defining a possibility that a valid implementation can take. > > If you go to the procedures you will see both these items are covered with "If MUST" type sentences. There is no specified optionality. > > Keith > > ------------------------------ > *From:* dispatch [mailto:dispatch-bounces@ietf.org] *On Behalf Of *Shida > Schubert > *Sent:* 09 January 2014 06:30 > *To:* Mary Barnes > > *Cc:* DISPATCH > *Subject:* Re: [dispatch] New Version of > draft-vanelburg-dispatch-private-network-ind > > > Hi Mary; > > Thanks for reviewing the document again. > > On Jan 6, 2014, at 3:03 PM, Mary Barnes > wrote: > > Hi all, > > I have reviewed the revised version and I just a few final comments. > > - Section 1.5, first bullet in the bulleted list: either change "an > emergency calls" to "an emergency call" or "emergency calls" > > > I will fix it with "emergency calls" > > - Section 3.6. "require the Specifying a Spec (T)." -> "require > specifying a Spec(T)" or "require the specification of a Spec(T)" > > > I will fix it with "require the specification of a Spec(T)" > > - Section 5, I had suggested the the requirements be consistent in usage > of 2119 language. One of the requirements (R6) was changed, but R2 and R3 > were not. Was there a specific reason not to make those suggested changes? > > > > R2: "The indication from R1 can be inserted by a SIP proxy" -> "The > indication from R1 MAY be inserted by a SIP proxy" > R3: "The indication from R1 can be removed by a SIP proxy" -> "The > indication from R1 MAY be removed by a SIP proxy" > > > So I reverted the change after Keith told that the requirements above > is not stating > a normative behaviour and that he believes "can" is more appropriate. > > I am okay either way. > > I will create a version with "MAY". > > Keith, please provide comments if you have a strong opposition to > changing it to "MAY". > > Thanks! > Shida > > > Thanks, > Mary. > > > On Tue, Oct 29, 2013 at 9:11 AM, Mary Barnes wrote: > >> In reviewing the document in preparation for the PROTO write-up, I have a >> few comments (minor and nits) that should be addressed prior to the >> document being progressed. >> >> Regards, >> Mary. >> >> Comments: >> --------------- >> >> - General: domains used in this document must use a reserved domain >> such as "example.com" and must not use real domains. Thus, all >> occurrences of ericsson.com need to be changed to example.com >> >> - Section 1.5. Bulleted list, first bullet. I would suggest you just >> leave out the mention of LI. Emergency services should be a sufficient >> example. >> >> - Section 1.5, last numbered list, item 2. I had a hard time groking >> this sentence and had to read several times. I would suggest rewording >> something like (if I've properly interpreted the intent): >> OLD: >> >> Different nodes spanning over different networks may need to be >> able to act differently on type of traffic, when implicit schemes >> are used, it would require distribution of such enterprise >> specific logic over multiple nodes in multiple operators. That >> is clearly not a manageable architecture and solution. >> >> >> NEW: >> >> Nodes spanning multiple networks often need to have different >> >> behavior depending upon the type of traffic. When this is done using implicit >> >> schemes, enterprise specific logic must be distributed across multiple >> >> nodes in multiple operator's networks. >> >> That is clearly not a manageable architecture and solution. >> >> >> >> - Section 1.5, last sentence. I don't think that statement is >> sufficient for what this document is doing. I would suggest you change that >> sentence to something like the following: >> OLD: >> >> Given the above background this document will formulate requirements >> for SIP to support an explicit private network indication. >> >> >> NEW: >> >> Based on the background provided, this document formulates requirements >> for SIP to support an explicit private network indication and defines >> >> a P-header, P-Private-Network-Indication, to support those requirements. >> >> >> >> - Section 3, next to last paragraph. I'm not sure what is meant by >> "the filling out a Spec(T)". I don't see "filling" used as a concept in RFC >> 3324. Perhaps, "specifying a Spec(T)" is more consistent with terminology >> in RFC 3324. >> >> - Section 5. In general, the requirements are not specific >> consistently - i.e., some use 2119 language and others not and there is not >> consistent capitalization. I would suggest the following changes. >> R2: "The indication from R1 can be inserted by a SIP proxy" -> "The >> indication from R1 MAY be inserted by a SIP proxy" >> R3: "The indication from R1 can be removed by a SIP proxy" -> "The >> indication from R1 MAY be removed by a SIP proxy" >> R6: "must" -> "MUST" >> >> - Section 6, 2nd paragraph. The "can" in the first sentence should be a >> "MAY" and the sentence needs to be split into two: >> OLD: >> >> A proxy server which handles a message can insert such a P-Private- >> Network-Indication header field into the message based on >> authentication of the source of a message, configuration or local >> policy, and forward it to other proxies in the same administrative >> domain or proxies in trusted domain to be handled as private network >> traffic. >> >> >> NEW: >> >> A proxy server which handles a message MAY insert such a P-Private- >> Network-Indication header field into the message based on >> authentication of the source of a message, configuration or local >> policy. A proxy server MAY forward the message to other proxies in the >> >> same administrative domain or proxies in a trusted >> >> domain to be handled as private network traffic. >> >> >> >> Section 9. You should be explicit about the header name in this >> section. The text in the first paragraph needs some work. At a minimum >> you need to change the "not supposed to" to something more definitive as >> all security issues arise because someone does something they're not >> supposed to. I would suggest at least making the following change: >> OLD: >> >> The private network indication defined in this document is to be used >> in an environment where elements are trusted and where attackers are >> not supposed to have access to the protocol messages between those >> elements. Traffic protection between network elements is sometimes >> achieved by using IPsec and sometimes by physical protection of the >> network. In any case, the environment where the private network >> indication will be used ensures the integrity and the confidentiality >> of the contents of this header field. >> >> NEW: >> >> The private network indication defined in this document MUST only be used >> in an environment where elements are trusted and where attackers are >> do not have access to the protocol messages between those >> elements. Traffic protection between network elements can be >> achieved by using IPsec and sometimes by physical protection of the >> network. In any case, the environment where the private network >> indication will be used ensures the integrity and the confidentiality >> of the contents of this header field. >> >> >> >> Nits: >> ------ >> - Section 1.1: "3rd-Generqation" -> 3rd-Generation >> - The terms "break-in" and "break-out" traffic are used several places in >> the document, but this term is never defined. These terms should be >> defined in Section 3. >> - Figures should have Titles for readability >> >> >> >> On Wed, Sep 11, 2013 at 9:19 PM, Mayumi Ohsugi < >> mayumi.ohsugi@ntt-at.co.jp> wrote: >> >>> Hi, >>> >>> I have submitted the following draft: >>> >>> http://www.ietf.org/internet-drafts/draft-vanelburg- >>> dispatch-private-network-ind-03.txt >>> >>> The draft reflects all the comments discussed in DISPATCH list. >>> >>> The major changes are as follows: >>> >>> - corrected the abstract >>> - corrected the term "common domain" to "pre-arranged domain" >>> - added 7.1.4 "P-Private-Network-Indication verification" >>> - editorial changes >>> >>> Regards, >>> Mayumi >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >>> >> >> > > --089e0122e92ea6235c04ef8b2e47 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Then, why are those even requirements? =A0

<= div>Mary.=A0


On Thu, Jan 9, 2014 at 5:05 AM, DRAGE, Keith (Keith) <keith.drage@alcatel-lucent.com> wrote:
The text from RFC 2119 states:
=A0
5. MAY   This word, or the adjective "OPTIONAL", mean that a=
n item is
   truly optional.  One vendor may choose to include the item because a
   particular marketplace requires it or because the vendor feels that
   it enhances the product while another vendor may omit the same item.
   An implementation which does not include a particular option MUST be
   prepared to interoperate with another implementation which does
   include the option, though perhaps with reduced functionality. In the
   same vein an implementation which does include a particular option
   MUST be prepared to interoperate with another implementation which
   does not include the option (except, of course, for the feature the
   option provides.)

My=A0b=
elief=A0is=A0that=A0we=A0are=A0not=A0defining=A0an=A0option=A0here,=A0and=
=A0it=A0is=A0certainly=A0not=A0a=A0vendor=A0decision. Further we are =
not identifying an interoperability issue here.

We are defining a possibility that a valid implementation can take. =







If you go to the procedures you will see both these items are covered with =
"If <condition> MUST" type sentences. There is no specified=
 optionality.







Keith









From: dispatch [mailto:dispatch-bounces@ietf.org]
On Behalf Of Shida Schubert

Sent: 09 January 2014 06:30

To: Mary Barnes


Cc: DISPATCH

Subject: Re: [dispatch] New Version of draft-vanelburg-dispatch-priv=
ate-network-ind














Hi Mary;







=A0Thanks for reviewing the document again.=A0






On Jan 6, 2014, at 3:03 PM, Mary Barnes <mary.ietf.barnes@gmail.com> wr=
ote:






Hi all,






I have reviewed the revised version and I just a few final comments.






- Section 1.5, first bullet in the bulleted list: either change "=
an emergency calls" to "an emergency call" or "emergenc=
y calls"
















=A0I will fix it with "emergency calls"








- Section 3.6. =A0"require the Specifying a Spec (T)." ->=
 "require specifying a Spec(T)" or "require the specificatio=
n of a Spec(T)"










=A0


=A0I will fix it with "require the specification of a Spec(T)&quo=
t;








- Section 5, I had suggested the the requirements be consistent in usa=
ge of 2119 language. =A0One of the requirements (R6) was changed, but R2 an=
d R3 were not. =A0Was there a specific reason not to make those suggested c=
hanges? =A0=A0


















R2: =A0 "The indication from R1 can b=
e inserted by a SIP proxy" -> "The indication from R1 MAY
 be inserted by a SIP proxy" =A0=A0


R3: "The indication from R1 can be re=
moved by a SIP proxy" -> "The indication from R1 MAY
 be removed by a SIP proxy"













=A0So I reverted the change after Keith told that the requirements abo=
ve is not stating=A0


a normative behaviour and that he believes "can" is more app=
ropriate.=A0







=A0I am okay either way.=A0







=A0I will create a version with "MAY".=A0







=A0Keith, please provide comments if you have a strong opposition to c=
hanging it to "MAY".







=A0Thanks!=A0


=A0 Shida















Thanks,




Mary.=A0









On Tue, Oct 29, 2013 at 9:11 AM, Mary Barnes 
<mary.ie=
tf.barnes@gmail.com> wrote:




In reviewing the document in preparation for the PROTO wri=
te-up, I have a few comments (minor and nits) that should be addressed prio=
r to the document being progressed.






Regards,


Mary.







Comments:


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







- General: domains used in this document must use a reserved domain su=
ch as "example.com" and must not use real domains. Thus, all occurrences of
ericsson.com need to=
 be changed to
example.com







- Section 1.5. =A0Bulleted list, first bullet. I would suggest you jus=
t leave out the mention of LI. =A0Emergency services should be a sufficient=
 example. =A0







- Section 1.5, last numbered list, item 2. =A0I had a hard time grokin=
g this sentence and had to read several times. I would suggest rewording so=
mething like (if I've properly interpreted the intent):


OLD:




       Different nodes spanning over different networks may need to b=
e
       able to act differently on type of traffic, when implicit schemes
       are used, it would require distribution of such enterprise
       specific logic over multiple nodes in multiple operators.  That
       is clearly not a manageable architecture and solution.









NEW:=A0




      =A0Nodes spanning multiple networks often need to have differen=
t=A0


       behavior depending upon the =
type of traffic.  When this is done using implicit


       schemes, enterprise specific logic must be distributed across =
multiple


       nodes in multiple operator's networks.  


       That is clearly not a manageable architecture and solution.











- Section 1.5, last sentence. =A0I don't think that statement is s=
ufficient for what this document is doing. I would suggest you change that =
sentence to something like the following:


OLD:




   Given the above background this document will formulate requiremen=
ts
   for SIP to support an explicit private network indication.







NEW:=A0




   Based on the background provided, this document formulates require=
ments
   for SIP to support an explicit private network indication and defines 

   a P-header, P-Private-Network-Indication, to support those require=
ments. 










- Section 3, next to last paragraph. =A0I'm not sure what is meant=
 by "the filling out a Spec(T)". I don't see "filling&qu=
ot; used as a concept in RFC 3324. =A0Perhaps, "specifying a Spec(T)&q=
uot; is more consistent with terminology in RFC 3324.=A0








- Section 5. =A0In general, the requirements are not specific consiste=
ntly - i.e., some use 2119 language and others not and there is not consist=
ent capitalization. =A0I would suggest the following changes.


R2: =A0 "The ind=
ication from R1 can be inserted by a SIP proxy" -> "The indication from R1 MAY be=
 inserted by a SIP proxy" =A0=A0



R3: "The indicat=
ion from R1 can be removed by a SIP proxy" -> "The indication from R1 MAY be remo=
ved by a SIP proxy"



R6: "must"=
; -> "MUST"







- Section 6, 2nd pa=
ragraph. The "can" in the first sentence should be a "MAY&qu=
ot; and the=A0sentence needs=
 to be split into two:



OLD:




   A proxy server which handles a message can insert such a P-Private=
-
   Network-Indication header field into the message based on
   authentication of the source of a message, configuration or local
   policy, and forward it to other proxies in the same administrative
   domain or proxies in trusted domain to be handled as private network
   traffic. 









NEW:=A0




   A proxy server which handles a message MAY insert such a P-Private=
-
   Network-Indication header field into the message based on
   authentication of the source of a message, configuration or local
   policy.  A proxy server MAY forward the message to other proxies in the=
=A0


   same administrative domain or proxies in a trusted=A0


   domain to be handled as private network traffic. 












Section 9. =A0You should be explicit =
about the header name in this section. =A0The text in the first paragraph n=
eeds some work. =A0At a minimum you need to change the "not supposed t=
o" to something more definitive as all security
 issues arise because someone does something they're not supposed to. =
=A0 I would suggest at least making the following change:


OLD:




   The private network indication defined in this document is to be u=
sed
   in an environment where elements are trusted and where attackers are
   not supposed to have access to the protocol messages between those
   elements.  Traffic protection between network elements is sometimes
   achieved by using IPsec and sometimes by physical protection of the
   network.  In any case, the environment where the private network
   indication will be used ensures the integrity and the confidentiality
   of the contents of this header field.




NEW:






   The private network indication defined in this document MUST only =
be used
   in an environment where elements are trusted and where attackers are
   do not have access to the protocol messages between those
   elements.  Traffic protection between network elements can be
   achieved by using IPsec and sometimes by physical protection of the
   network.  In any case, the environment where the private network
   indication will be used ensures the integrity and the confidentiality
   of the contents of this header field.














Nits:


------


- Section 1.1: =A0"3rd-Generqation" ->=A03rd-Generation =A0


- The terms "bre=
ak-in" and "break-out" traffic are used several places in th=
e document, but this term is never defined. =A0These terms should be define=
d in Section 3.=A0



- Figures should have=
 Titles for readability


















On Wed, Sep 11, 2013 at 9:19 PM, Mayumi Ohsugi <<=
a href=3D"mailto:mayumi.ohsugi@ntt-at.co.jp" target=3D"_blank">mayumi.ohsug=
i@ntt-at.co.jp> wrote:









Hi,



I have submitted the following draft:



http://www.ietf.org/internet-=
drafts/draft-vanelburg-dispatch-private-network-ind-03.tx=
t




The draft reflects all the comments discussed in DISPATCH list.



The major changes are as follows:



- corrected the abstract

- corrected the term "common domain" to "pre-arranged domain=
"

- added 7.1.4 "P-Private-Network-Indication verification"

- editorial changes

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 Regards,

Mayumi

_______________________________________________

dispatch mailing list

dispatch@ietf.org

https://www.ietf.org/mailman/listinfo/dispatch




































--089e0122e92ea6235c04ef8b2e47--

From oej@edvina.net  Thu Jan  9 08:09:40 2014
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 8FA3A1ACCE0 for ; Thu,  9 Jan 2014 08:09:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.551
X-Spam-Level: 
X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 ERqzH2jKsDFL for ; Thu,  9 Jan 2014 08:09:38 -0800 (PST)
Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id E2F931ADEB5 for ; Thu,  9 Jan 2014 08:09:37 -0800 (PST)
Received: from [192.168.40.13] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id A5C6693C2A1; Thu,  9 Jan 2014 16:09:27 +0000 (UTC)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: "Olle E. Johansson" 
Date: Thu, 9 Jan 2014 17:09:25 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <2ECFFECF-84DE-4F74-B515-716EE03800B3@edvina.net>
References: <20140109154214.22968.46430.idtracker@ietfa.amsl.com>
To: "dispatch@ietf.org list" 
X-Mailer: Apple Mail (2.1827)
Subject: [dispatch] Fwd: New Version Notification for draft-johansson-dispatch-dane-sip-01.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: Thu, 09 Jan 2014 16:09:40 -0000

Hi!

Just a tiny edit to remove the "updates 5922" label.

Taking this to sipcore seems perfect to me.

/O

Begin forwarded message:

> From: internet-drafts@ietf.org
> Subject: New Version Notification for =
draft-johansson-dispatch-dane-sip-01.txt
> Date: 9 Jan 2014 16:42:14 GMT+1
> To: Olle E. Johansson , "Olle E. Johansson" =

>=20
>=20
> A new version of I-D, draft-johansson-dispatch-dane-sip-01.txt
> has been successfully submitted by Olle E. Johansson and posted to the
> IETF repository.
>=20
> Name:		draft-johansson-dispatch-dane-sip
> Revision:	01
> Title:		TLS sessions in SIP using DNS-based =
Authentication of Named Entities (DANE) TLSA records
> Document date:	2014-01-09
> Group:		Individual Submission
> Pages:		9
> URL:            =
http://www.ietf.org/internet-drafts/draft-johansson-dispatch-dane-sip-01.t=
xt
> Status:         =
https://datatracker.ietf.org/doc/draft-johansson-dispatch-dane-sip/
> Htmlized:       =
http://tools.ietf.org/html/draft-johansson-dispatch-dane-sip-01
> Diff:           =
http://www.ietf.org/rfcdiff?url2=3Ddraft-johansson-dispatch-dane-sip-01
>=20
> Abstract:
>   Use of TLS in the SIP protocol is defined in multiple documents,
>   starting with RFC 3261.  The actual verification that happens when
>   setting up a SIP TLS connection to a SIP server based on a SIP URI =
is
>   described in detail in RFC 5922 - SIP Domain Certificates.
>=20
>   In this document, an alternative method is defined, using DNS-Based
>   Authentication of Named Entities (DANE).  By looking up TLSA DNS
>   records and using DNSsec protection of the required queries,
>   including lookups for NAPTR and SRV records, a SIP Client can verify
>   the identity of the TLS SIP server in a different way, matching on
>   the SRV host name in the X.509 PKIX certificate instead of the SIP
>   domain.  This provides more scalability in hosting solutions and =
make
>   it easier to use standard CA certificates (if needed at all).
>=20
>=20
>=20
>=20
> 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.
>=20
> The IETF Secretariat
>=20


From mary.ietf.barnes@gmail.com  Fri Jan 10 11:35:04 2014
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 C99451AE1D6 for ; Fri, 10 Jan 2014 11:35:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.698
X-Spam-Level: 
X-Spam-Status: No, score=-1.698 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, 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 I_xxwDJO-8TR for ; Fri, 10 Jan 2014 11:34:57 -0800 (PST)
Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) by ietfa.amsl.com (Postfix) with ESMTP id A9C271AE0F3 for ; Fri, 10 Jan 2014 11:34:56 -0800 (PST)
Received: by mail-wi0-f180.google.com with SMTP id hn9so37826wib.7 for ; Fri, 10 Jan 2014 11:34:46 -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=zZehB+bt5LAqNAbcsCway6RvOunVVGxBKG2rLRFDQyo=; b=sMttEnfCfrU0js1aQbTV5npeeJuaUoqmH0oMSXziLuOr8bl+FZRvZDq5HSunTV4pk0 uo1Yvs0Q60oUTUdfa00MwD0/T9zoeeHSPFXuKKqHfdqOUK6mVyMO6h9VMDb2CaDaVdy6 2imgEsbuFa5jPmvK3erFaGBpPXizHUCSreVgLFcEjTn92yh+Tny/DGuYz8+HqpC2ONJs 0SNx7hISxYDRprzgn0jQvpYBA5anBjsS0kwnABgl1xFiUHcPOxDdkiddNe7MozxB8BR9 6zLO6Wjeeg6x4zDPAkLCRTzZhxhE6d3wkUTKevSe/z/Irg8gaf1lWR6FRYVi4lkIuea4 /YLA==
MIME-Version: 1.0
X-Received: by 10.180.228.8 with SMTP id se8mr4219218wic.7.1389382486099; Fri, 10 Jan 2014 11:34:46 -0800 (PST)
Received: by 10.216.172.9 with HTTP; Fri, 10 Jan 2014 11:34:45 -0800 (PST)
In-Reply-To: <058CE00BD4D6B94FAD033A2439EA1E4B01DF8EC99D57@HE113667.emea1.cds.t-internal.com>
References:  <058CE00BD4D6B94FAD033A2439EA1E4B01DEBB69CC8A@HE113667.emea1.cds.t-internal.com>  <058CE00BD4D6B94FAD033A2439EA1E4B01DF27DB8A63@HE113667.emea1.cds.t-internal.com>  <058CE00BD4D6B94FAD033A2439EA1E4B01DF8E83EB24@HE113667.emea1.cds.t-internal.com>  <058CE00BD4D6B94FAD033A2439EA1E4B01DF8E83F451@HE113667.emea1.cds.t-internal.com>  <058CE00BD4D6B94FAD033A2439EA1E4B01DF8EC99D57@HE113667.emea1.cds.t-internal.com>
Date: Fri, 10 Jan 2014 13:34:45 -0600
Message-ID: 
From: Mary Barnes 
To: "R.Jesske@telekom.de" 
Content-Type: multipart/alternative; boundary=001a1134db548a8d8b04efa2d174
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, 10 Jan 2014 19:35:05 -0000

--001a1134db548a8d8b04efa2d174
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

IN addition to removing the unused references in the next update, there are
still 4 domain names that are not using an appropriate documentation domain
(e.g., home.net).  Please add that change to the list for the next
revision.  I'm going to ahead and forward the PROTO write-up to Gonzalo,
noting the changes that are needed and suggesting those changes can be made
along with other IETF LC changes.

Thanks,
Mary


On Wed, Jan 8, 2014 at 2:46 AM,  wrote:

> Thank you Marry,
>
> for doing all this review.
>
> So I have now put out the errors.
>
> There are still some unused references which are in our informal referenc=
e
> section. But useful for the reader to know they exist.
>
> There are also some warnings with regard to IP addresses and wrong FQDNs
> which I think is some interpretation of strings in the text which are not
> meant to be a IP address or FQDN at all.
>
>
>
> Detail see below.
>
>
>
> So now hopefully everything is ready for the next step.
>
>
>
> Best Regards
>
>
>
> Roland
>
>
>
> tmp/draft-drage-sipping-rfc3455bis-12.txt:
>
>
>
>   Checking boilerplate required by RFC 5378 and the IETF Trust (see
>
>   http://trustee.ietf.org/license-info):
>
>
> -------------------------------------------------------------------------=
---
>
>
>
>      No issues found here.
>
>
>
>   Checking nits according to
> http://www.ietf.org/id-info/1id-guidelines.txt:
>
>
> -------------------------------------------------------------------------=
---
>
>
>
>      No issues found here.
>
>
>
>   Checking nits according to http://www.ietf.org/id-info/checklist :
>
>
> -------------------------------------------------------------------------=
---
>
>
>
>  =3D=3D There are 4 instances of lines with non-RFC2606-compliant FQDNs i=
n the
>
>      document.
>
>
>
>   =3D=3D There are 4 instances of lines with non-RFC5735-compliant IPv4
> addresses
>
>      in the document.  If these are example addresses, they should be
> changed.
>
>
>
>
>
>   Miscellaneous warnings:
>
>
> -------------------------------------------------------------------------=
---
>
>
>
>      No issues found here.
>
>
>
>   Checking references for intended status: Informational
>
>
> -------------------------------------------------------------------------=
---
>
>
>
>   =3D=3D Missing Reference: 'RFC XXXX' is mentioned on line 1662, but not
> defined
>
>
>
>   -- Looks like a reference, but probably isn't: '3' on line 1943
>
>
>
>   =3D=3D Unused Reference: 'RFC3262' is defined on line 2068, but no expl=
icit
>
>      reference was found in the text
>
>
>
>   =3D=3D Unused Reference: 'RFC3311' is defined on line 2072, but no expl=
icit
>
>      reference was found in the text
>
>
>
>   =3D=3D Unused Reference: 'RFC3428' is defined on line 2078, but no expl=
icit
>
>      reference was found in the text
>
>
>
>   =3D=3D Unused Reference: 'RFC3903' is defined on line 2090, but no expl=
icit
>
>      reference was found in the text
>
>
>
>   =3D=3D Unused Reference: 'RFC6086' is defined on line 2101, but no expl=
icit
>
>      reference was found in the text
>
>
>
>
>
>      Summary: 0 errors (**), 0 flaws (~~), 8 warnings (=3D=3D), 1 comment=
 (--).
>
>
>
>      Run idnits with the --verbose option for more detailed information
> about
>
>      the items above.
>
>
> -------------------------------------------------------------------------=
-------
>
>
>
>
>
>
>
> *Von:* Mary Barnes [mailto:mary.ietf.barnes@gmail.com]
> *Gesendet:* Dienstag, 7. Januar 2014 18:55
>
> *An:* Jesske, Roland
> *Cc:* DISPATCH; Gonzalo Camarillo; Atle Monrad; Dean Willis
> *Betreff:* Re: PROTO Review: draft-drage-sipping-rfc3455bis-09.txt
>
>
>
> Thanks Roland.  I have reviewed that version and all the changes I
> suggested have been made.  However, in doing the PROTO write-up I realize=
d
> that I wasn't certain anyone had reviewed the ABNF. So, I ran the ABNF
> through Bill Fenner's tool:
>
> http://tools.ietf.org/tools/bap/abnf.cgi
>
>
>
> And, there are a couple things that need to be fixed:
>
> 1)  DOT needs to change to "." (we had this same bug in RFC 4244):
>
> transit-ioi-indexed-value =3D transit-ioi-name DOT transit-ioi-index
>
>
>
> 2)  There's an extra space here (between * and parenthesis):
>
> transit-ioi-name          =3D ALPHA * (ALPHA / DIGIT)
>
> NEw: transit-ioi-name          =3D ALPHA *(ALPHA / DIGIT)
>
>
>
> There are also a number of long lines in the ABNF that should be fixed.
>
>
>
> In addition, IDNITS identifies other errors and warnings per the
> following.  Those should also be addressed including considering whether
> obsolete references need changing:
>
>
>
> idnits 2.13.01
>
>
>
> tmp/draft-drage-sipping-rfc3455bis-11.txt:
>
>
>
>   Checking boilerplate required by RFC 5378 and the IETF Trust (see
>
>   http://trustee.ietf.org/license-info):
>
>   -----------------------------------------------------------------------=
-----
>
>
>
>      No issues found here.
>
>
>
>   Checking nits according to http://www.ietf.org/id-info/1id-guidelines.t=
xt:
>
>   -----------------------------------------------------------------------=
-----
>
>
>
>      No issues found here.
>
>
>
>   Checking nits according to http://www.ietf.org/id-info/checklist :
>
>   -----------------------------------------------------------------------=
-----
>
>
>
>   ** There are 9 instances of too long lines in the document, the longest=
 one
>
>      being 20 characters in excess of 72.
>
>
>
>   =3D=3D There are 4 instances of lines with non-RFC2606-compliant FQDNs =
in the
>
>      document.
>
>
>
>   =3D=3D There are 4 instances of lines with non-RFC5735-compliant IPv4 a=
ddresses
>
>      in the document.  If these are example addresses, they should be cha=
nged.
>
>
>
>
>
>   Miscellaneous warnings:
>
>   -----------------------------------------------------------------------=
-----
>
>
>
>   =3D=3D The document seems to contain a disclaimer for pre-RFC5378 work,=
 but was
>
>      first submitted on or after 10 November 2008.  The disclaimer is usu=
ally
>
>      necessary only for documents that revise or obsolete older RFCs, and=
 that
>
>      take significant amounts of text from those RFCs.  If you can contac=
t all
>
>      authors of the source material and they are willing to grant the BCP=
78
>
>      rights to the IETF Trust, you can and should remove the disclaimer.
>
>      Otherwise, the disclaimer is needed and you can ignore this comment.
>
>      (See the Legal Provisions document at
>
>      http://trustee.ietf.org/license-info for more information.)
>
>
>
>
>
>   Checking references for intended status: Informational
>
>   -----------------------------------------------------------------------=
-----
>
>
>
>   =3D=3D Missing Reference: 'RFC XXXX' is mentioned on line 1667, but not=
 defined
>
>
>
>   -- Looks like a reference, but probably isn't: '3' on line 1948
>
>
>
>   =3D=3D Unused Reference: 'RFC2976' is defined on line 2065, but no expl=
icit
>
>      reference was found in the text
>
>
>
>   =3D=3D Unused Reference: 'RFC3262' is defined on line 2068, but no expl=
icit
>
>      reference was found in the text
>
>
>
>   =3D=3D Unused Reference: 'RFC3311' is defined on line 2075, but no expl=
icit
>
>      reference was found in the text
>
>
>
>   =3D=3D Unused Reference: 'RFC3428' is defined on line 2081, but no expl=
icit
>
>      reference was found in the text
>
>
>
>   =3D=3D Unused Reference: 'RFC3903' is defined on line 2093, but no expl=
icit
>
>      reference was found in the text
>
>
>
>   ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234)
>
>
>
>   -- Obsolete informational reference (is this intentional?): RFC 2976
>
>      (Obsoleted by RFC 6086)
>
>
>
>   -- Obsolete informational reference (is this intentional?): RFC 3265
>
>      (Obsoleted by RFC 6665)
>
>
>
>
>
>      Summary: 2 errors (**), 0 flaws (~~), 9 warnings (=3D=3D), 3 comment=
s (--).
>
>
>
>      Run idnits with the --verbose option for more detailed information a=
bout
>
>      the items above.
>
> While I apologize for not catching these issues earlier, it really is the
> responsibility of authors to check idnits (beyond what the submission too=
l
> requires) for their documents.  I routinely run idnits before I submit a
> document as it can also save time when fixing the  nits that the submissi=
on
> tool catches:   https://tools.ietf.org/tools/idnits/
>
>
>
> Regards,
>
> Mary.
>
>
>
>
>
>
>
> On Tue, Jan 7, 2014 at 12:35 AM,  wrote:
>
> Hi Mary,
>
> Now a new revision is available.
>
>
>
> Thank you and Best Regards
>
>
>
> Roland
>
>
>
> *Von:* Mary Barnes [mailto:mary.ietf.barnes@gmail.com]
> *Gesendet:* Montag, 6. Januar 2014 20:00
>
>
> *An:* Jesske, Roland
> *Cc:* DISPATCH; Gonzalo Camarillo; Atle Monrad; Dean Willis
> *Betreff:* Re: PROTO Review: draft-drage-sipping-rfc3455bis-09.txt
>
>
>
> Hi Roland,
>
>
>
> One final editorial nit below.  If you can spin a revision, then I'll sen=
d
> the PROTO write-up to the AD.
>
>
>
> Thanks,
>
> Mary.
>
>
>
> On Thu, Jan 2, 2014 at 3:29 AM,  wrote:
>
> Hi Mary,
>
> I wish you a happy new year 2014. And the best for the next year.
>
>
>
> I was looking again on my changes I made due to your proposal in December=
.
>
> I realized that if I change the SHOULD to MUST we have now a backward
> compatibility problem.
>
> We are using the P-Associated-URI also over the IMS user interface which
> is not encrypted.
>
> So I propose to add some more words.
>
> =85
>
> Section 6.1
>
> =85
>
>          An eavesdropper could possibly collect the list of identities
> a user is registered.
>
>        This can 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.  
>
>
>
>        Since the P-Associated-URI header field value allows to
> implicitly register
>
>       a bundle of URIs with one REGISTER Message the impact of security
> using the P-Associated-URI header field is not higher than
>
>       using single REGISTER messages when registering all identities
> explicit.
>
> [MB] I just have some editorial suggestions for the above:
>
> NEW:
>
>  While the P-Associated-URI header field value allows the implicit
> registration of
>
>       a bundle of URIs with one REGISTER Message the impact of security
> using the P-Associated-URI header field is no higher than
>
>       using separate REGISTER messages for each of the URIs. 
>
> [/MB]
>
>
>
>
>
>
>
>
>
> For the P-Called-Party-Id the change should be also done like as follows:
>
>
>
>         An eavesdropper could possibly collect the list of identities
> a user is registered.
>
>        This can have privacy implications.  To mitigate this problem, thi=
s
> extension SHOULD
>
>        only be used in a secured environment, where encryption of SIP
> messages is
>
>        provided either end-to-end or hop-by-hop.  
>
>
>
>         Normally within a 3GPP environment the P-Called-Party-ID is
> not sent towards end users but may be exchanged between carriers where
> other security mechanisms than SIP encryption are used.  
>
>
>
> Sorry coming so late.
>
> If this is OK for you I will include it to a new version.
>
>
>
> Thank you and Best Regards
>
>
>
> Roland
>
>
>
> *Von:* Mary Barnes [mailto:mary.ietf.barnes@gmail.com]
> *Gesendet:* Freitag, 27. Dezember 2013 19:45
>
>
> *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 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 so=
me
> 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 "potent=
ially 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 th=
e 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" t=
hat makes this header not of particular concern with regards to security. D=
oes it reveal additional, unique information about an individual that isn't=
 available in other headers.  Also, the 2nd paragraph needs some work - may=
be 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 r=
egistered.  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 rev=
ision.  And, I believe you still need to identify privacy/security implicat=
ions by addressing whether or not this header reveals any unique informatio=
n 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
>
>   -
>
>
>
>
>
>
>
>
>

--001a1134db548a8d8b04efa2d174
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable


IN addition to removing the unused references in the next =
update, there are still 4 domain names that are not using an appropriate do=
cumentation domain (e.g., home.net). =A0Ple=
ase add that change to the list for the next revision. =A0I'm going to =
ahead and forward the PROTO write-up to Gonzalo, noting the changes that ar=
e needed and suggesting those changes can be made along with other IETF LC =
changes.


Thanks,
Mary


On Wed, Jan 8, 2014 at 2:46 AM,  <R.=
Jesske@telekom.de> wrote:


T=
hank you Marry,


for doing =
all this review.
So I have now put out the errors.=



There are =
still some unused references which are in our informal reference section. B=
ut useful for the reader to know they exist.


There are =
also some warnings with regard to IP addresses and wrong FQDNs which I thin=
k is some interpretation of strings in the text which are not meant to be a=
 IP address or FQDN at all. 


=A0=

Detail see below.


=A0=

So now hopefully everything is ready for the next step.


=A0=

Best Regards


=A0=

Roland


=A0=

tmp/draft-drage-sipping-r=
fc3455bis-12.txt:


=A0<=
/p>
=A0 Checking boilerplate required by RFC=
 5378 and the IETF Trust (see


=A0 http://trustee.ietf.org/license-info):


=A0 ---------------------------------------=
-------------------------------------

=A0
=A0=A0=
=A0=A0 No issues found here.


=A0
=A0 Checking nits according to http://www.ietf.org/id-in=
fo/1id-guidelines.txt:


=A0 ---------------------------------------=
-------------------------------------

=A0
=A0=A0=
=A0=A0 No issues found here.


=A0
=A0 Checking nits according to http://www.ietf.org/id-info/checkl=
ist :


=A0 ---------------------------------------=
-------------------------------------

=A0
=
 =A0=3D=3D There are 4 instances of lines with non-RFC2606-compliant FQDNs =
in the


=A0=A0=A0=A0 document.=

=A0


=A0 =3D=3D There are 4 instances of lines w=
ith non-RFC5735-compliant IPv4 addresses

=A0=A0=A0=A0 in the document.=A0 If these are example addresses, t=
hey should be changed.
=A0


=A0
=A0 Miscellaneous warnings:


=A0 ---------------------------------------=
-------------------------------------

=A0
=
=A0=A0=A0=A0 No issues found here.


=A0
=A0 Checking references for intended status: Informational=



=A0 ---------------------------------------=
-------------------------------------

=A0
=A0 =
=3D=3D Missing Reference: 'RFC XXXX' is mentioned on line 1662, but=
 not defined


=A0
=A0 -- Looks like a reference, but probably isn't: =
9;3' on line 1943


=A0<=
/p>
=A0 =3D=3D Unused Reference: 'RFC326=
2' is defined on line 2068, but no explicit


=A0=A0=A0=A0 reference was found in the tex=
t
=A0=



=A0 =3D=3D Unused Reference: 'RFC=
3311' is defined on line 2072, but no explicit
=



=A0=A0=A0=A0 reference was found in the tex=
t
=A0=



=A0 =3D=3D Unused Reference: 'RFC=
3428' is defined on line 2078, but no explicit
=



=A0=A0=A0=A0 reference was found in the tex=
t
=A0=



=A0 =3D=3D Unused Reference: 'RFC=
3903' is defined on line 2090, but no explicit
=



=A0=A0=A0=A0 reference was found in the tex=
t
=A0=



=A0 =3D=3D Unused Reference: 'RFC=
6086' is defined on line 2101, but no explicit
=



=A0=A0=A0=A0 reference was found in the tex=
t
=A0=



=A0
=A0=A0=A0=A0 Summary: 0 errors (**), 0 flaws (~~), =
8 warnings (=3D=3D), 1 comment (--).


=A0<=
/p>
=A0=A0=A0=A0 Run idnits with the --verbo=
se option for more detailed information about


=A0=A0=A0=A0 the items above.


----------------------------------------------------=
----------------------------
=A0


=A0=

=A0


Von: Mary Barnes [mailto:mary.ietf.barnes@gmail.com] 

Gesendet: Dienstag, 7. Januar 2014 18:55

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


=A0=

Thanks Roland. =A0I have reviewed th=
at version and all the changes I suggested have been made. =A0However, in d=
oing the PROTO write-up I realized that I wasn't certain anyone had rev=
iewed the ABNF. So, I ran the ABNF through Bill Fenner's tool:=A0


=A0

And, there are a couple things that need to be fixed:
1) =A0DOT needs to change to "." (w=
e had this same bug in RFC 4244):

=
transit-ioi-indexed-value =3D transit-ioi-name DOT transit-ioi-index=

=A0


2) =A0There's an extra space here (be=
tween * and parenthesis):
NEw: transit-ioi-name=A0=A0=A0=A0=A0=A0=A0=
=A0=A0 =3D ALPHA *(ALPHA / DIGIT)


=A0
There are also a number of long lines in the ABNF that shoul=
d be fixed.=A0
=
=A0


In addition, IDNITS identifies other erro=
rs and warnings per the following. =A0Those should also be addressed includ=
ing considering whether obsolete references need changing:

=A0
idnits 2.13.01 <=
u>
=A0
tmp/draft-drage-sipping-rfc3455bis-11.txt:

=A0
=A0 Checkin=
g boilerplate required by RFC 5378 and the IETF Trust (see
=A0 http://trustee.ietf.org/license-info):=



=A0 ------------------------------------------------------=
----------------------
=
=A0
=A0=A0=A0=A0 No issues found here.<=
u>


=A0
=A0 Checkin=
g nits according to http://www.ietf.org/id-info/1id-guidelines.txt:


=A0 ------------------------------------------------------=
----------------------
=
=A0
=A0=A0=A0=A0 No issues found here.<=
u>


=A0
=A0 Checkin=
g nits according to http://www.ietf.org/id-info/checklist :


=A0 ------------------------------------------------------=
----------------------
=
=A0
=A0 ** There are 9 instances of too=
 long lines in the document, the longest one


=A0=A0=A0=A0 being 20 characters in excess of 72.
=A0
=A0 =3D=3D There are 4 instances of lines with non-RFC2606-compliant=
 FQDNs in the


=A0=A0=A0=A0 document.
=A0
=A0 =3D=3D There are=
 4 instances of lines with non-RFC5735-compliant IPv4 addresses


=A0=A0=A0=A0 in the document.=A0 If these are example addr=
esses, they should be changed.
<=
u>=A0
=A0
=A0 Miscellaneous warnings:


=A0 ------------------------------------------------------=
----------------------
=
=A0
=A0 =3D=3D The document seems to co=
ntain a disclaimer for pre-RFC5378 work, but was


=A0=A0=A0=A0 first submitted on or after 10 November 2008.=
=A0 The disclaimer is usually
=
=A0=A0=A0=A0 necessary only for documents that revise or obsolete older RFC=
s, and that


=A0=A0=A0=A0 take significant amounts of text from those R=
FCs.=A0 If you can contact all
=
=A0=A0=A0=A0 authors of the source material and they are willing to grant t=
he BCP78


=A0=A0=A0=A0 rights to the IETF Trust, you can and should =
remove the disclaimer. 
=A0=A0=
=A0=A0=A0Otherwise, the disclaimer is needed and you can ignore this commen=
t. 


=A0=A0=A0=A0=A0(See the Legal Provisions document at
=A0=A0=A0=A0 http://trustee.ietf.org/license-=
info for more information.)


=A0
=A0<=
u>
=A0 Checking references for intended st=
atus: Informational
=A0 --------=
--------------------------------------------------------------------=



=A0
=A0 =3D=3D =
Missing Reference: 'RFC XXXX' is mentioned on line 1667, but not de=
fined
=A0
=A0 -- Looks like a reference, but probably isn't: '3&#=
39; on line 1948
=A0
=A0 =3D=3D Unused Reference: 'RFC2976&#=
39; is defined on line 2065, but no explicit


=A0=A0=A0=A0 reference was found in the text=

=A0
=A0 =3D=3D Unused Reference: 'RFC3262' is defined on line 2068, b=
ut no explicit


=A0=A0=A0=A0 reference was found in the text=

=A0
=A0 =3D=3D Unused Reference: 'RFC3311' is defined on line 2075, b=
ut no explicit


=A0=A0=A0=A0 reference was found in the text=

=A0
=A0 =3D=3D Unused Reference: 'RFC3428' is defined on line 2081, b=
ut no explicit


=A0=A0=A0=A0 reference was found in the text=

=A0
=A0 =3D=3D Unused Reference: 'RFC3903' is defined on line 2093, b=
ut no explicit


=A0=A0=A0=A0 reference was found in the text=

=A0
=A0 ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234)<=
/u>


=A0
=A0 -- Obso=
lete informational reference (is this intentional?): RFC 2976=

=A0=A0=A0=A0 (Obsoleted by RFC 6086)


=A0
=A0 -- Obso=
lete informational reference (is this intentional?): RFC 3265=

=A0=A0=A0=A0 (Obsoleted by RFC 6665)


=A0
=A0<=
u>
=A0=A0=A0=A0 Summary: 2 errors (**), 0 =
flaws (~~), 9 warnings (=3D=3D), 3 comments (--).
=A0


=A0=A0=A0=A0 Run idnits with the --verbose option for more=
 detailed information about
=A0=
=A0=A0=A0 the items above.
While I apologize for not catching these issues earlier, it rea=
lly is the responsibility of authors to check idnits (beyond what the submi=
ssion tool requires) for their documents. =A0I routinely run idnits before =
I submit a document as it can also save time when fixing the =A0nits that t=
he submission tool catches: =A0=A0https://tools.ietf.org/tools/idnits/


=A0
Regards,
=
Mary.=A0
=A0


=A0
=A0
On Tue, Jan 7, 2014 at 12:35 AM, <R.Jesske@telekom.de> wrote:


=
Hi Mary,
Now a new revision is available.


=A0
Thank you and Best Regards


=A0=

Roland


=A0=



Von: Mary Barnes [mailto:mary.ietf.barnes@gmail.com] 

Gesendet: Montag, 6. Januar 2014 20:00<=
/u>

An: Jesske, Rolan=
d

Cc: DISPATCH; Gonzalo Camarillo; Atle Monrad; Dean Willis
Betr=
eff: Re: PROTO Review: draft-drage-sipping-rfc3455bis-09.txt<=
/u>
=A0=



Hi Roland,
=A0
One final e=
ditorial nit below. =A0If you can spin a revision, then I'll send the P=
ROTO write-up to the AD.


=A0
Thanks,
M=
ary.=A0

=A0
On Thu, Jan 2, 2014 at 3:2=
9 AM, <R.Jesske=
@telekom.de> wrote:
Hi Mary,

I wish you=
 a happy new year 2014. And the best for the next year.


=A0=

I was looking again on my changes I made due to your proposal in De=
cember.


I realized=
 that if I change the SHOULD to MUST we have now a backward compatibility p=
roblem.


We are usi=
ng the P-Associated-URI also over the IMS user interface which is not encry=
pted.


So I propo=
se to add some more words.
<=
span lang=3D"EN-US" style=3D"font-size:11.0pt;font-family:"Calibri&quo=
t;,"sans-serif";color:#1f497d">=85


Section 6.=
1
=85


=A0=A0=A0=A0=A0=A0=A0=A0 <t>An eavesdropper could possibly collect the list of identities=
 a user is registered.=A0 


=A0=A0=A0=A0=A0=A0=A0This can have privacy implic=
ations. To mitigate this problem, this extension SHOULD 

=A0=A0=A0=A0=A0=A0=A0only b=
e used in a secured environment, where encryption of SIP messages is 
=A0=A0=A0=A0=A0=A0=A0pro=
vided either end-to-end or hop-by-hop.=A0 </<=
/span>t><=
/span>


=A0=A0 
=A0=A0=A0=A0=A0=A0<t> Since the=
 P-Associated-URI header field value allows to implicitly register <=
u>


=A0=A0=A0=A0=A0=A0a bundle of URIs with one REGIS=
TER Message the impact of security using the P-Associated-URI header field =
is not higher than=A0 


=A0=
=A0=A0=A0=A0=A0using single REGISTER messages when registering all identiti=
es explicit.</t>

[MB] I just have some editorial sug=
gestions for the above:
=
NEW: =A0
<t>=A0While the P-Associated-URI header field value allows the i=
mplicit registration of=A0


=A0=A0=A0=A0=A0=A0a bundle of U=
RIs with one REGISTER Message the impact of security using the P-Associated=
-URI header field is no higher than=A0
=A0=A0=A0=A0=A0=A0using separate REGISTER m=
essages for each of the URIs.=A0</t>


[/MB]
=A0
=



=A0


=
=A0
=A0
For the P-Called-Party-Id the change sh=
ould be also done like as follows:


=A0=

=A0=A0=A0=A0=A0=A0=A0 <t>An eavesdropper could possibly collect the lis=
t of identities a user is registered.=A0 


=A0=A0=A0=A0=A0=A0=A0This can have privacy implic=
ations.=A0 To mitigate this problem, this extension SHOULD 

=A0=A0=A0=A0=A0=A0=A0only b=
e used in a secured environment, where encryption of SIP messages is 
=A0=A0=A0=A0=A0=A0=A0provided either end-to-end or ho=
p-by-hop.=A0 </t>


=A0

=A0=A0=A0=A0=A0=A0=A0 <t>Normally within a 3GPP environment the P-C=
alled-Party-ID is not sent towards end users but may be exchanged between c=
arriers where other security mechanisms than SIP encryption are used.=A0 </t<=
span style=3D"color:blue">>


=A0=

Sorry coming so late.


If this is=
 OK for you I will include it to a new version.


=A0=

Thank you and Best Regards


=A0=

Roland


=A0=



Von: Mary Barn=
es [mailto:=
mary.ietf.barnes@gmail.com] 

Gesendet: Freitag, 27. Dezember 2013 19:45
<=
div>

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


=A0
Hi Roland,
=A0
Thanks for mak=
ing these changes. I finally had a chance to review this updated version. =
=A0 I still have a couple comments on the security section as I think you w=
ill get questions during SEC review around this unless some more detail is =
provided on security threats and impacts. =A0 I've extracted these few =
points from previous review comment threads.


=A0
Thanks,
M=
ary.
=A0


----Previous point =A0------------------------------=
--->
- Section 6.1: this needs some tighter wordi=
ng. =A0What is meant by "potentially annoying" =A0for example? =
=A0


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


-<=
/u>
[MB] So, you removed that part of the sentence and are left with:


"This attack should not have any signifi=
cant impacts."
=A0
=A0
I don't think that adds any value and just begs the question &q=
uot;what are the insignificant impacts and are there any privacy concerns&q=
uot;?=A0 Really, it's the next paragraph that provides details of the i=
mpacts.=A0 I think you could probably remove that sentence altogether and n=
ot lose anything. 


=A0
=A0<=
u>
=
[/MB]


=A0
----Previous point --------------------------------->


=A0
-=A0 Section 6.2: I think you need to be mor=
e specific about the "nature" that makes this header not of parti=
cular concern with regards to security. Does it reveal additional, unique i=
nformation about an individual that isn't available in other headers. =
=A0Also, the 2nd paragraph needs some work - maybe something like:


=A0
=A0<=
u>
OLD:<=
u>


=A0<=
/pre>
=A0
An eave=
sdropper may collect the list of identities a user is registered.=A0 This m=
ay have privacy implications.=A0 To mitigate this problem, this extension S=
HOULD only be used in a secured environment, where encryption of SIP messag=
es is provided either end-to-end or


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


An eavesdropper could possibly =
collect the list of identities a user is registered.=A0 This can have priva=
cy implications.=A0 To mitigate this problem, this extension MUST only be u=
sed in a secured environment, where encryption of SIP messages is provided =
either end-to-end or hop-by-hop.=A0


----End prev=
ious point ------------------------------<

=A0
[MB]=A0 The suggeste=
d change for the first sentence didn't get into the revision.=A0 And, I=
 believe you still need to identify privacy/security implications by addres=
sing whether or not this header reveals any unique information about an ind=
ividual that isn't available in other headers.=A0=A0 [/MB]


=A0
=A0
=A0


=A0<=
/pre>
=A0
=A0=



On Tue, Dec 3, 2013 at 7:00 AM, <R.Jesske@telekom.de> 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.<=
/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 d=
raft-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 (SIP) for the 3rd=
-Generation Partnership Project (3GPP)


Creation date:=A0=A0=A0 2013-12-03<=
/u>
Group:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0 Individual Submission
N=
umber 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 Protocol<=
/u>


=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: DISPA=
TCH; Gonzalo Camarillo; Atle Monrad; Dean Willis

Betreff: Re: PROTO Review: draft-drage-sipping-rfc3455bis-09.txt<=
/u>
=A0
<=
div>
Hi Roland,

=A0
Thanks for your resp=
onse. =A0Additional comments below [MB].
=A0
Tha=
nks,


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


=
Hi Mary,
Thank you for your review.


I have add=
ed now your proposals to the draft.

Other comments please see below.<=
/span>
=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
=A0
=A0
=A0
- Section 3. =A0This section needs to be updated. =A0I don't think t=
hat 10 year old background is relevant in the current context. =A0 You shou=
ld be able to model this after the text in more recent 3GPP P-header docume=
nts, referring 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
=A0
=A0
=A0
Section 4.2, 1st paragraph. =
=A0The behavior in this sentence is not normative from a SIP protocol persp=
ective, thus MAY is not appropriate. =A0I suggest the MAY be changed to &qu=
ot;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.
=A0
=A0
=A0
NEW:=A0
=
=A0=A0 In the context of the network to which the header fields defined in =
this document apply, a User Agent has=A0no knowledge of the P-Visited-Netwo=
rk-ID when sending the REGISTER request. =A0Therefore user agent clients MU=
ST NOT insert a P-Visited-Network-ID=A0header field=A0in any SIP message.


=A0
- Section 4.3.2.2:, 2nd paragraph: =A0"=
;home network MAY use" -> "home network can use"

=A0
=A0<=
/pre>
=A0
=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>
=A0
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
=A0<=
u>
OLD:
=A0
=A0=A0 Depending on the call scenario it is nee=
ded to add for each transit
=A0=A0 network either a=
 transit network name or a void value. =A0Nevertheless
<=
pre>=A0=A0 it can not be guaranteed that all values will appear within the =
P-Charging-Vector header field.=A0

=A0
=A0<=
u>
NEW:=A0
=A0


=A0=A0 Depending o=
n the call scenario, each transit network can add either a transit network =
name=A0or a void=A0=A0=A0 value.=A0 However, it can not be guaranteed that =
all the values that are added will appear within the P-Charging-Vector head=
er 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
=A0
=A0


=A0
=A0<=
u>
- Section 5.7. Delete this text and table. =A0 We aren't the=
se tables anymore as they really don't provide any useful information. =
=A0You just need to verbally state what messages these headers can appear i=
n.=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
=A0<=
/pre>
=A0
=A0
hop-by-ho=
p.=A0
=A0 =A0=



=A0
NEW:=A0=

=A0
=
=A0An eavesdropper could possibly collect the list of identities a u=
ser is registered.=A0 This can have privacy implications.=A0 To mitigate th=
is problem, this extension MUST only be used in a secured environment, wher=
e encryption of SIP 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


- Section 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
=A0
=A0
=A0
-- 8th paragraph=
: "SHOULD NOT send sensitive information" -> "MUST NOT se=
nd sensitive 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
=A0
=A0
=A0
- Section 4.1, 2nd paragraph. =
=A0"has associated to an address-of-record" -> "has assoc=
iated with 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

=A0
=A0
=

=A0
<=
/div>



--001a1134db548a8d8b04efa2d174--

From mary.ietf.barnes@gmail.com  Fri Jan 10 11:38:06 2014
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 ED3131AE072 for ; Fri, 10 Jan 2014 11:38:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.698
X-Spam-Level: 
X-Spam-Status: No, score=-1.698 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, 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 L666dX9IfHYt for ; Fri, 10 Jan 2014 11:37:59 -0800 (PST)
Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id B09A61ADFB2 for ; Fri, 10 Jan 2014 11:37:58 -0800 (PST)
Received: by mail-we0-f181.google.com with SMTP id u56so2226732wes.12 for ; Fri, 10 Jan 2014 11:37:48 -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=MzDedalXsVTZq5ua/zFqWc0jEmLBCwefELMNubGiePM=; b=eUkzwb/cUb9+we6hTzStKX9FPQ69CO4B5C6ri4jbDbmNi4rwWZQ/96PZUVt/DnkWxw t/cZodvVKE5WdPL+USJbEZHk310C2dnvhVBEPXXQnvgjItZ/m1Z2GpPZtFcFWayHkaxl EYZ3ZKtUxkKnCu9381yPz2vPRi1hMN5mc7VM+kfZrZaYW8wbIZRpUjrHL/nRo2JlBQhJ xeNJYWZq4ZIfJrCQdXore/qed50dljRM3QmrX4Qak99WeKhHEdxNs/6lSQcKHBwncTVS iA7dq3RrA9urUhy3IaUCbY3SkwPz0b+92GU4Yn+v0KRIPhGGsmvPiigCBUKlF2g9Q6YB 9W7A==
MIME-Version: 1.0
X-Received: by 10.194.82.68 with SMTP id g4mr10352008wjy.85.1389382668228; Fri, 10 Jan 2014 11:37:48 -0800 (PST)
Received: by 10.216.172.9 with HTTP; Fri, 10 Jan 2014 11:37:48 -0800 (PST)
In-Reply-To: 
References:  <058CE00BD4D6B94FAD033A2439EA1E4B01DEBB69CC8A@HE113667.emea1.cds.t-internal.com>  <058CE00BD4D6B94FAD033A2439EA1E4B01DF27DB8A63@HE113667.emea1.cds.t-internal.com>  <058CE00BD4D6B94FAD033A2439EA1E4B01DF8E83EB24@HE113667.emea1.cds.t-internal.com>  <058CE00BD4D6B94FAD033A2439EA1E4B01DF8E83F451@HE113667.emea1.cds.t-internal.com>  <058CE00BD4D6B94FAD033A2439EA1E4B01DF8EC99D57@HE113667.emea1.cds.t-internal.com> 
Date: Fri, 10 Jan 2014 13:37:48 -0600
Message-ID: 
From: Mary Barnes 
To: "R.Jesske@telekom.de" 
Content-Type: multipart/alternative; boundary=047d7bea41fe659fe104efa2dc1d
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, 10 Jan 2014 19:38:06 -0000

--047d7bea41fe659fe104efa2dc1d
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

There is yet one more change needed.  This document is an Updates to
3455bis (AFAIK, unless Obseletes works better for 3GPP usage).  That
categorization needs to be included in the document header (3rd line).

Thanks,
Mary.


On Fri, Jan 10, 2014 at 1:34 PM, Mary Barnes wr=
ote:

> IN addition to removing the unused references in the next update, there
> are still 4 domain names that are not using an appropriate documentation
> domain (e.g., home.net).  Please add that change to the list for the next
> revision.  I'm going to ahead and forward the PROTO write-up to Gonzalo,
> noting the changes that are needed and suggesting those changes can be ma=
de
> along with other IETF LC changes.
>
> Thanks,
> Mary
>
>
> On Wed, Jan 8, 2014 at 2:46 AM,  wrote:
>
>> Thank you Marry,
>>
>> for doing all this review.
>>
>> So I have now put out the errors.
>>
>> There are still some unused references which are in our informal
>> reference section. But useful for the reader to know they exist.
>>
>> There are also some warnings with regard to IP addresses and wrong FQDNs
>> which I think is some interpretation of strings in the text which are no=
t
>> meant to be a IP address or FQDN at all.
>>
>>
>>
>> Detail see below.
>>
>>
>>
>> So now hopefully everything is ready for the next step.
>>
>>
>>
>> Best Regards
>>
>>
>>
>> Roland
>>
>>
>>
>> tmp/draft-drage-sipping-rfc3455bis-12.txt:
>>
>>
>>
>>   Checking boilerplate required by RFC 5378 and the IETF Trust (see
>>
>>   http://trustee.ietf.org/license-info):
>>
>>
>> ------------------------------------------------------------------------=
----
>>
>>
>>
>>      No issues found here.
>>
>>
>>
>>   Checking nits according to
>> http://www.ietf.org/id-info/1id-guidelines.txt:
>>
>>
>> ------------------------------------------------------------------------=
----
>>
>>
>>
>>      No issues found here.
>>
>>
>>
>>   Checking nits according to http://www.ietf.org/id-info/checklist :
>>
>>
>> ------------------------------------------------------------------------=
----
>>
>>
>>
>>  =3D=3D There are 4 instances of lines with non-RFC2606-compliant FQDNs =
in the
>>
>>      document.
>>
>>
>>
>>   =3D=3D There are 4 instances of lines with non-RFC5735-compliant IPv4
>> addresses
>>
>>      in the document.  If these are example addresses, they should be
>> changed.
>>
>>
>>
>>
>>
>>   Miscellaneous warnings:
>>
>>
>> ------------------------------------------------------------------------=
----
>>
>>
>>
>>      No issues found here.
>>
>>
>>
>>   Checking references for intended status: Informational
>>
>>
>> ------------------------------------------------------------------------=
----
>>
>>
>>
>>   =3D=3D Missing Reference: 'RFC XXXX' is mentioned on line 1662, but no=
t
>> defined
>>
>>
>>
>>   -- Looks like a reference, but probably isn't: '3' on line 1943
>>
>>
>>
>>   =3D=3D Unused Reference: 'RFC3262' is defined on line 2068, but no exp=
licit
>>
>>      reference was found in the text
>>
>>
>>
>>   =3D=3D Unused Reference: 'RFC3311' is defined on line 2072, but no exp=
licit
>>
>>      reference was found in the text
>>
>>
>>
>>   =3D=3D Unused Reference: 'RFC3428' is defined on line 2078, but no exp=
licit
>>
>>      reference was found in the text
>>
>>
>>
>>   =3D=3D Unused Reference: 'RFC3903' is defined on line 2090, but no exp=
licit
>>
>>      reference was found in the text
>>
>>
>>
>>   =3D=3D Unused Reference: 'RFC6086' is defined on line 2101, but no exp=
licit
>>
>>      reference was found in the text
>>
>>
>>
>>
>>
>>      Summary: 0 errors (**), 0 flaws (~~), 8 warnings (=3D=3D), 1 commen=
t
>> (--).
>>
>>
>>
>>      Run idnits with the --verbose option for more detailed information
>> about
>>
>>      the items above.
>>
>>
>> ------------------------------------------------------------------------=
--------
>>
>>
>>
>>
>>
>>
>>
>> *Von:* Mary Barnes [mailto:mary.ietf.barnes@gmail.com]
>> *Gesendet:* Dienstag, 7. Januar 2014 18:55
>>
>> *An:* Jesske, Roland
>> *Cc:* DISPATCH; Gonzalo Camarillo; Atle Monrad; Dean Willis
>> *Betreff:* Re: PROTO Review: draft-drage-sipping-rfc3455bis-09.txt
>>
>>
>>
>> Thanks Roland.  I have reviewed that version and all the changes I
>> suggested have been made.  However, in doing the PROTO write-up I realiz=
ed
>> that I wasn't certain anyone had reviewed the ABNF. So, I ran the ABNF
>> through Bill Fenner's tool:
>>
>> http://tools.ietf.org/tools/bap/abnf.cgi
>>
>>
>>
>> And, there are a couple things that need to be fixed:
>>
>> 1)  DOT needs to change to "." (we had this same bug in RFC 4244):
>>
>> transit-ioi-indexed-value =3D transit-ioi-name DOT transit-ioi-index
>>
>>
>>
>> 2)  There's an extra space here (between * and parenthesis):
>>
>> transit-ioi-name          =3D ALPHA * (ALPHA / DIGIT)
>>
>> NEw: transit-ioi-name          =3D ALPHA *(ALPHA / DIGIT)
>>
>>
>>
>> There are also a number of long lines in the ABNF that should be fixed.
>>
>>
>>
>> In addition, IDNITS identifies other errors and warnings per the
>> following.  Those should also be addressed including considering whether
>> obsolete references need changing:
>>
>>
>>
>> idnits 2.13.01
>>
>>
>>
>> tmp/draft-drage-sipping-rfc3455bis-11.txt:
>>
>>
>>
>>   Checking boilerplate required by RFC 5378 and the IETF Trust (see
>>
>>   http://trustee.ietf.org/license-info):
>>
>>   ----------------------------------------------------------------------=
------
>>
>>
>>
>>      No issues found here.
>>
>>
>>
>>   Checking nits according to http://www.ietf.org/id-info/1id-guidelines.=
txt:
>>
>>   ----------------------------------------------------------------------=
------
>>
>>
>>
>>      No issues found here.
>>
>>
>>
>>   Checking nits according to http://www.ietf.org/id-info/checklist :
>>
>>   ----------------------------------------------------------------------=
------
>>
>>
>>
>>   ** There are 9 instances of too long lines in the document, the longes=
t one
>>
>>      being 20 characters in excess of 72.
>>
>>
>>
>>   =3D=3D There are 4 instances of lines with non-RFC2606-compliant FQDNs=
 in the
>>
>>      document.
>>
>>
>>
>>   =3D=3D There are 4 instances of lines with non-RFC5735-compliant IPv4 =
addresses
>>
>>      in the document.  If these are example addresses, they should be ch=
anged.
>>
>>
>>
>>
>>
>>   Miscellaneous warnings:
>>
>>   ----------------------------------------------------------------------=
------
>>
>>
>>
>>   =3D=3D The document seems to contain a disclaimer for pre-RFC5378 work=
, but was
>>
>>      first submitted on or after 10 November 2008.  The disclaimer is us=
ually
>>
>>      necessary only for documents that revise or obsolete older RFCs, an=
d that
>>
>>      take significant amounts of text from those RFCs.  If you can conta=
ct all
>>
>>      authors of the source material and they are willing to grant the BC=
P78
>>
>>      rights to the IETF Trust, you can and should remove the disclaimer.
>>
>>      Otherwise, the disclaimer is needed and you can ignore this comment=
.
>>
>>      (See the Legal Provisions document at
>>
>>      http://trustee.ietf.org/license-info for more information.)
>>
>>
>>
>>
>>
>>   Checking references for intended status: Informational
>>
>>   ----------------------------------------------------------------------=
------
>>
>>
>>
>>   =3D=3D Missing Reference: 'RFC XXXX' is mentioned on line 1667, but no=
t defined
>>
>>
>>
>>   -- Looks like a reference, but probably isn't: '3' on line 1948
>>
>>
>>
>>   =3D=3D Unused Reference: 'RFC2976' is defined on line 2065, but no exp=
licit
>>
>>      reference was found in the text
>>
>>
>>
>>   =3D=3D Unused Reference: 'RFC3262' is defined on line 2068, but no exp=
licit
>>
>>      reference was found in the text
>>
>>
>>
>>   =3D=3D Unused Reference: 'RFC3311' is defined on line 2075, but no exp=
licit
>>
>>      reference was found in the text
>>
>>
>>
>>   =3D=3D Unused Reference: 'RFC3428' is defined on line 2081, but no exp=
licit
>>
>>      reference was found in the text
>>
>>
>>
>>   =3D=3D Unused Reference: 'RFC3903' is defined on line 2093, but no exp=
licit
>>
>>      reference was found in the text
>>
>>
>>
>>   ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234)
>>
>>
>>
>>   -- Obsolete informational reference (is this intentional?): RFC 2976
>>
>>      (Obsoleted by RFC 6086)
>>
>>
>>
>>   -- Obsolete informational reference (is this intentional?): RFC 3265
>>
>>      (Obsoleted by RFC 6665)
>>
>>
>>
>>
>>
>>      Summary: 2 errors (**), 0 flaws (~~), 9 warnings (=3D=3D), 3 commen=
ts (--).
>>
>>
>>
>>      Run idnits with the --verbose option for more detailed information =
about
>>
>>      the items above.
>>
>> While I apologize for not catching these issues earlier, it really is th=
e
>> responsibility of authors to check idnits (beyond what the submission to=
ol
>> requires) for their documents.  I routinely run idnits before I submit a
>> document as it can also save time when fixing the  nits that the submiss=
ion
>> tool catches:   https://tools.ietf.org/tools/idnits/
>>
>>
>>
>> Regards,
>>
>> Mary.
>>
>>
>>
>>
>>
>>
>>
>> On Tue, Jan 7, 2014 at 12:35 AM,  wrote:
>>
>> Hi Mary,
>>
>> Now a new revision is available.
>>
>>
>>
>> Thank you and Best Regards
>>
>>
>>
>> Roland
>>
>>
>>
>> *Von:* Mary Barnes [mailto:mary.ietf.barnes@gmail.com]
>> *Gesendet:* Montag, 6. Januar 2014 20:00
>>
>>
>> *An:* Jesske, Roland
>> *Cc:* DISPATCH; Gonzalo Camarillo; Atle Monrad; Dean Willis
>> *Betreff:* Re: PROTO Review: draft-drage-sipping-rfc3455bis-09.txt
>>
>>
>>
>> Hi Roland,
>>
>>
>>
>> One final editorial nit below.  If you can spin a revision, then I'll
>> send the PROTO write-up to the AD.
>>
>>
>>
>> Thanks,
>>
>> Mary.
>>
>>
>>
>> On Thu, Jan 2, 2014 at 3:29 AM,  wrote:
>>
>> Hi Mary,
>>
>> I wish you a happy new year 2014. And the best for the next year.
>>
>>
>>
>> I was looking again on my changes I made due to your proposal in Decembe=
r.
>>
>> I realized that if I change the SHOULD to MUST we have now a backward
>> compatibility problem.
>>
>> We are using the P-Associated-URI also over the IMS user interface which
>> is not encrypted.
>>
>> So I propose to add some more words.
>>
>> =85
>>
>> Section 6.1
>>
>> =85
>>
>>          An eavesdropper could possibly collect the list of
>> identities a user is registered.
>>
>>        This can have privacy implications. To mitigate this problem, thi=
s
>> extension SHOULD
>>
>>        only be used in a secured environment, where encryption of SIP
>> messages is
>>
>>        provided either end-to-end or hop-by-hop.  
>>
>>
>>
>>        Since the P-Associated-URI header field value allows to
>> implicitly register
>>
>>       a bundle of URIs with one REGISTER Message the impact of security
>> using the P-Associated-URI header field is not higher than
>>
>>       using single REGISTER messages when registering all identities
>> explicit.
>>
>> [MB] I just have some editorial suggestions for the above:
>>
>> NEW:
>>
>>  While the P-Associated-URI header field value allows the implicit
>> registration of
>>
>>       a bundle of URIs with one REGISTER Message the impact of security
>> using the P-Associated-URI header field is no higher than
>>
>>       using separate REGISTER messages for each of the URIs. 
>>
>> [/MB]
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> For the P-Called-Party-Id the change should be also done like as follows=
:
>>
>>
>>
>>         An eavesdropper could possibly collect the list of identities
>> a user is registered.
>>
>>        This can 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.  
>>
>>
>>
>>         Normally within a 3GPP environment the P-Called-Party-ID is
>> not sent towards end users but may be exchanged between carriers where
>> other security mechanisms than SIP encryption are used.  
>>
>>
>>
>> Sorry coming so late.
>>
>> If this is OK for you I will include it to a new version.
>>
>>
>>
>> Thank you and Best Regards
>>
>>
>>
>> Roland
>>
>>
>>
>> *Von:* Mary Barnes [mailto:mary.ietf.barnes@gmail.com]
>> *Gesendet:* Freitag, 27. Dezember 2013 19:45
>>
>>
>> *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 making these changes. I finally had a chance to review this
>> updated version.   I still have a couple comments on the security sectio=
n
>> as I think you will get questions during SEC review around this unless s=
ome
>> more detail is provided on security threats and impacts.   I've extracte=
d
>> these few points from previous review comment threads.
>>
>>
>>
>> Thanks,
>>
>> Mary.
>>
>>
>>
>> ----Previous point  --------------------------------->
>>
>> - Section 6.1: this needs some tighter wording.  What is meant by "poten=
tially 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 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 coul=
d 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 - ma=
ybe 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 exten=
sion 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 encryptio=
n 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 re=
vision.  And, I believe you still need to identify privacy/security implica=
tions by addressing whether or not this header reveals any unique informati=
on 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 (3G=
PP)
>>
>> Creation date:    2013-12-03
>>
>> Group:            Individual Submission
>>
>> Number of pages: 46
>>
>> URL:
>> http://www.ietf.org/internet-drafts/draft-drage-sipping-rfc3455bis-10.tx=
t
>>
>> 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 =
in
>> the -09 and many of my -08 comments remain - I've separated comments fro=
m
>> nits below.  A number of these comments are with regards to text that wa=
s
>> not changed from RFC 3455, but I think some of the text requires updatin=
g
>> 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 wi=
ll
>> need to do that before I progress the document unless the authors can po=
int
>> 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" i=
s
>> 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 =
Internet environment.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> - Section 3.  This section needs to be updated.  I don't think that 10 y=
ear 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, refer=
ring 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 =
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 tho=
se
>> 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 Releas=
e
>> 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 =
intent is that this header is not applicable to proxies, therefore the prox=
y MUST relay the header field unchanged.  I would suggest rewording somethi=
ng 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 normat=
ive from a SIP protocol perspective, thus MAY is not appropriate.  I sugges=
t the MAY be changed to "can".
>>
>>    The UAS MAY use the information to render different distinctive audio=
visual 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 no=
rmative 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 =
identifier should be globally unique.."
>>
>>
>>
>> - Section 4.3.2.1.  This text has changed from the -08.   I don't know w=
hat a "normal User Equipment" is and the term "User Equipment" is not defin=
ed 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 u=
ser agent server behavior - i.e., what would a UAS do if it received this h=
eader.
>>
>>
>>
>> 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 t=
his document apply, a User Agent has no knowledge of the P-Visited-Network-=
ID when sending the REGISTER request.  Therefore user agent clients MUST NO=
T insert a P-Visited-Network-ID header field in any SIP message.
>>
>>
>>
>> - Section 4.3.2.2:, 2nd paragraph:  "home network MAY use" -> "home netw=
ork can use"
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> - Section 4.3.2.2, last paragraph:
>>
>>
>>
>>
>>
>> OLD: Note that a received P-Visited-Network-ID from a UA is a failure ca=
se and must be deleted.
>>
>>
>>
>> NEW:  Note that a received P-Visited-Network-ID from a UA is a failure c=
ase 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 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 us=
e the call id"
>>
>> Section 4.5.2: 2nd paragraph: "MAY use the hostnames" -> "can use the ho=
stnames"
>>
>>
>>
>>
>>
>>
>>
>> Section 4.5.2.1 2nd paragraph: "MAY use the contents" -> "can use the co=
ntents"
>>
>>
>>
>> - Section 4.6.2, 3rd paragraph: "MAY use the values" -> "can use the val=
ues"
>>
>> - Section 4.6.3, 3rd paragraph: needs some editorial work.  Maybe the fo=
llowing 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-Cha=
rging-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 guarantee=
d that all the values that are added will appear within the P-Charging-Vect=
or 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 considerat=
ion" 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 =
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 =
incremented by the number of void entries +1.
>>
>>
>>
>> - Section 4.6.4.2: I don't know what this means:  "A deletion of the ele=
ments 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 previou=
s 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 o=
r
>> 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 anym=
ore as they really don't provide any useful information.  You just need to =
verbally 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 al=
l
>> 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 an=
d
>> CANCEL.
>>
>> [MB] I suggest you put each of these in separate sentences - i.e., rathe=
r
>> 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 "poten=
tially 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" t=
hat makes this header not of particular concern with regards to security. D=
oes it reveal additional, unique information about an individual that isn't=
 available in other headers.  Also, the 2nd paragraph needs some work - may=
be 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 exten=
sion 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 encrypti=
on 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 s=
end 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 sc=
ope of these headers, is it not?
>>
>>
>>
>> [RJ] Yes that is also my understanding so I deleted that paragraph. I th=
ink 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-Info
>>
>>        header field from a non-trusted entity is not able to guarantee t=
he
>>
>>        validity of the contents. Thus this content SHOULD be deleted bas=
ed 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 i=
nclude 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" -> SHA=
LL 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 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 wa=
s
>> 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.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
>> 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 (3G=
PP)
>> Creation date:   2013-10-08
>> Group:           Individual Submission
>> Number of pages: 47
>> URL:
>> http://www.ietf.org/internet-drafts/draft-drage-sipping-rfc3455bis-09.tx=
t
>> 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
>>
>>   -
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
>

--047d7bea41fe659fe104efa2dc1d
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable


There is yet one more change needed. =A0This document is a=
n Updates to 3455bis (AFAIK, unless Obseletes works better for 3GPP usage).=
 =A0That categorization needs to be included in the document header (3rd li=
ne).=A0


Thanks,
Mary.=A0


On Fri, Jan 10, 2014 at 1:34 PM, Ma=
ry Barnes <mary.ietf.barnes@gmail.com> wrote:


IN addition to removing the=
 unused references in the next update, there are still 4 domain names that =
are not using an appropriate documentation domain (e.g., home.net). =A0Please add that change to the=
 list for the next revision. =A0I'm going to ahead and forward the PROT=
O write-up to Gonzalo, noting the changes that are needed and suggesting th=
ose changes can be made along with other IETF LC changes.



Thanks,
Mary


On Wed, Jan 8, 2014 at 2:46 AM,  <R.Jesske@telekom.de> wr=
ote:



T=
hank you Marry,



for doing =
all this review.
So I have now put out the errors.=




There are =
still some unused references which are in our informal reference section. B=
ut useful for the reader to know they exist.



There are =
also some warnings with regard to IP addresses and wrong FQDNs which I thin=
k is some interpretation of strings in the text which are not meant to be a=
 IP address or FQDN at all. 



=A0=

Detail see below.



=A0=

So now hopefully everything is ready for the next step.



=A0=

Best Regards



=A0=

Roland



=A0=

tmp/draft-drage-sipping-r=
fc3455bis-12.txt:



=A0
=A0 Checking boilerplate required by RFC 5378 and t=
he IETF Trust (see



=A0 http://trustee.ietf.org/license-info):



=A0 ---------------------------------------=
-------------------------------------


=A0
=A0=A0=
=A0=A0 No issues found here.



=A0
=A0 Checking nits according to http://www.ietf.org/id-in=
fo/1id-guidelines.txt:



=A0 ---------------------------------------=
-------------------------------------


=A0
=A0=A0=
=A0=A0 No issues found here.



=A0
=A0 Checking nits according to http://www.ietf.org/id-info/checkl=
ist :



=A0 ---------------------------------------=
-------------------------------------


=A0
=
 =A0=3D=3D There are 4 instances of lines with non-RFC2606-compliant FQDNs =
in the



=A0=A0=A0=A0 document.
=A0



=A0 =3D=3D There are 4 instances of lines w=
ith non-RFC5735-compliant IPv4 addresses


=A0=A0=A0=A0 in the document.=A0 If these are example addresses, t=
hey should be changed.
=A0



=A0
=A0 Miscellaneous warnings:



=A0 ---------------------------------------=
-------------------------------------


=A0
=
=A0=A0=A0=A0 No issues found here.



=A0
=A0 Checking references for intended status: Informational=




=A0 ---------------------------------------=
-------------------------------------


=A0
=A0 =
=3D=3D Missing Reference: 'RFC XXXX' is mentioned on line 1662, but=
 not defined



=A0
=A0 -- Looks like a reference, but probably isn't: =
9;3' on line 1943



=A0
=A0 =3D=3D Unused Reference: 'RFC3262' is d=
efined on line 2068, but no explicit



=A0=A0=A0=A0 reference was found in the tex=
t
=A0=




=A0 =3D=3D Unused Reference: 'RFC=
3311' is defined on line 2072, but no explicit
=



=A0=A0=A0=A0 reference was found in the tex=
t
=A0=




=A0 =3D=3D Unused Reference: 'RFC=
3428' is defined on line 2078, but no explicit
=



=A0=A0=A0=A0 reference was found in the tex=
t
=A0=




=A0 =3D=3D Unused Reference: 'RFC=
3903' is defined on line 2090, but no explicit
=



=A0=A0=A0=A0 reference was found in the tex=
t
=A0=




=A0 =3D=3D Unused Reference: 'RFC=
6086' is defined on line 2101, but no explicit
=



=A0=A0=A0=A0 reference was found in the tex=
t
=A0=




=A0
=A0=A0=A0=A0 Summary: 0 errors (**), 0 flaws (~~), =
8 warnings (=3D=3D), 1 comment (--).



=A0
=A0=A0=A0=A0 Run idnits with the --verbose option f=
or more detailed information about



=A0=A0=A0=A0 the items above.



----------------------------------------------------=
----------------------------

=A0


=A0=

=A0



Von: Mary Barnes [mailto:mary.ietf.barnes@gmail.com] 


Gesendet: Dienstag, 7. Januar 2014 18:55

=
An: Jesske, Roland
Cc: DISPATCH; Gonzalo Camarillo; Atle Monr=
ad; Dean Willis
Betreff: Re: PROTO Review: draft-drage-sipping-rf=
c3455bis-09.txt



=A0
Thanks Roland. =A0I have reviewed that version an=
d all the changes I suggested have been made. =A0However, in doing the PROT=
O write-up I realized that I wasn't certain anyone had reviewed the ABN=
F. So, I ran the ABNF through Bill Fenner's tool:=A0



=A0


And, there are a couple things that need to be fixed:
1) =A0DOT needs to change to "." (w=
e had this same bug in RFC 4244):


=
transit-ioi-indexed-value =3D transit-ioi-name DOT transit-ioi-index=

=A0



2) =A0There's an extra space here (be=
tween * and parenthesis):
NEw: transit-ioi-name=A0=A0=A0=A0=A0=A0=A0=
=A0=A0 =3D ALPHA *(ALPHA / DIGIT)



=A0
There are also a number of long lines in the ABNF that shoul=
d be fixed.=A0
=
=A0



In addition, IDNITS identifies other erro=
rs and warnings per the following. =A0Those should also be addressed includ=
ing considering whether obsolete references need changing:


<=
u>=A0
idnits 2.13.01 
=A0
tmp/draft-drage-=
sipping-rfc3455bis-11.txt:



=A0
=A0 Checking boilerplat=
e required by RFC 5378 and the IETF Trust (see
=A0 http://trustee.ietf.org/license-info):


=A0 ------------------------------------------------------------=
----------------
=A0
=A0=A0=A0=A0 No issues found here.=



=A0
=A0 Checking nits accor=
ding to http://www.ietf.org/id-info/1id-guidelines.txt:



=A0 ------------------------------------------------------------=
----------------
=A0
=A0=A0=A0=A0 No issues found here.=



=A0
=A0 Checking nits accor=
ding to http://www.ietf.org/id-info/checklist :


=A0 ------------------------------------------------------------=
----------------
=A0
=A0 ** There are 9 instances of too long lines in the d=
ocument, the longest one



=A0=A0=A0=A0 being 20 characters in excess of 72.<=
/span>
=A0
=A0 =3D=3D =
There are 4 instances of lines with non-RFC2606-compliant FQDNs in the



=A0=A0=A0=A0 document.
<=
/u>=A0
=A0 =3D=3D There are 4 instances of li=
nes with non-RFC5735-compliant IPv4 addresses


=A0=A0=A0=A0 in the document.=A0 If these are example addresses,=
 they should be changed.
=A0=

=A0
=A0 Mi=
scellaneous warnings:



=A0 ------------------------------------------------------------=
----------------
=A0
=A0 =3D=3D The document seems to contain a disclaimer f=
or pre-RFC5378 work, but was



=A0=A0=A0=A0 first submitted on or after 10 November 2008.=A0 Th=
e disclaimer is usually
=A0=A0=A0=A0 n=
ecessary only for documents that revise or obsolete older RFCs, and that=




=A0=A0=A0=A0 take significant amounts of text from those RFCs.=
=A0 If you can contact all
=A0=A0=A0=
=A0 authors of the source material and they are willing to grant the BCP78<=
u>



=A0=A0=A0=A0 rights to the IETF Trust, you can and should remove=
 the disclaimer. 
=A0=A0=A0=A0=A0Other=
wise, the disclaimer is needed and you can ignore this comment. <=
/u>



=A0=A0=A0=A0=A0(See the Legal Provisions document at
=A0=A0=A0=A0 http://trustee.ietf.org/license-info for=
 more information.)



=A0
=A0
=A0 Checking references for intended status: Informationa=
l
=A0 --------------------------------=
--------------------------------------------



=A0
=A0 =3D=3D Missing Refe=
rence: 'RFC XXXX' is mentioned on line 1667, but not defined=

=A0
=A0=
 -- Looks like a reference, but probably isn't: '3' on line 194=
8


=A0
=A0 =3D=3D Unused Refer=
ence: 'RFC2976' is defined on line 2065, but no explicit<=
/u>


=A0=A0=A0=A0 reference was found in the text
=A0
=A0 =3D=3D Unuse=
d Reference: 'RFC3262' is defined on line 2068, but no explicit<=
/u>



=A0=A0=A0=A0 reference was found in the text
=A0
=A0 =3D=3D Unuse=
d Reference: 'RFC3311' is defined on line 2075, but no explicit<=
/u>



=A0=A0=A0=A0 reference was found in the text
=A0
=A0 =3D=3D Unuse=
d Reference: 'RFC3428' is defined on line 2081, but no explicit<=
/u>



=A0=A0=A0=A0 reference was found in the text
=A0
=A0 =3D=3D Unuse=
d Reference: 'RFC3903' is defined on line 2093, but no explicit<=
/u>



=A0=A0=A0=A0 reference was found in the text
=A0
=A0 ** Obsolete =
normative reference: RFC 2234 (Obsoleted by RFC 4234)<=
/pre>

=A0
=A0 -- Obsolete informa=
tional reference (is this intentional?): RFC 2976
=A0=A0=A0=A0 (Obsoleted by RFC 6086)


=A0
=A0 -- Obsolete informa=
tional reference (is this intentional?): RFC 3265
=A0=A0=A0=A0 (Obsoleted by RFC 6665)


=A0
=A0
=A0=A0=A0=A0 Summary: 2 errors (**), 0 flaws (~~), 9 warn=
ings (=3D=3D), 3 comments (--).
=A0



=A0=A0=A0=A0 Run idnits with the --verbose option for more detai=
led information about
=A0=A0=A0=A0 the=
 items above.
W=
hile I apologize for not catching these issues earlier, it really is the re=
sponsibility of authors to check idnits (beyond what the submission tool re=
quires) for their documents. =A0I routinely run idnits before I submit a do=
cument as it can also save time when fixing the =A0nits that the submission=
 tool catches: =A0=A0https://tools.ietf.org/tools/idnits/



=A0
Regards,
=
Mary.=A0
=A0



=A0
=A0
On Tue, Jan 7, 2014 at 12:35 AM, <R.Jesske@telekom.de> wrote:



=
Hi Mary,
Now a new revision is available.



=A0
Thank you and Best Regards



=A0=

Roland



=A0=




Von: Mary Barnes [mailto:mary.ietf.barnes@gmail.com] 


Gesendet: Montag, 6. Januar 2014 20:00<=
/u>

An: Jesske, Rolan=
d


Cc: DISPATCH; Gonzalo Camarillo; Atle Monrad; Dean Willis
Betr=
eff: Re: PROTO Review: draft-drage-sipping-rfc3455bis-09.txt<=
/u>
=A0=




Hi Roland,
=A0
One final e=
ditorial nit below. =A0If you can spin a revision, then I'll send the P=
ROTO write-up to the AD.



=A0
Thanks,
M=
ary.=A0


=A0
On Thu, Jan 2, 2014 at 3:2=
9 AM, <R.Jesske=
@telekom.de> wrote:
Hi Mary,


I wish you=
 a happy new year 2014. And the best for the next year.



=A0=

I was looking again on my changes I made due to your proposal in De=
cember.



I realized=
 that if I change the SHOULD to MUST we have now a backward compatibility p=
roblem.



We are usi=
ng the P-Associated-URI also over the IMS user interface which is not encry=
pted.



So I propo=
se to add some more words.
<=
span lang=3D"EN-US" style=3D"font-size:11.0pt;font-family:"Calibri&quo=
t;,"sans-serif";color:#1f497d">=85



Section 6.=
1
=85



=A0=A0=A0=A0=A0=A0=A0=A0 <t>An eavesdropper could possibly collect the list of identities=
 a user is registered.=A0 



=A0=A0=A0=A0=A0=A0=A0This can have privacy implic=
ations. To mitigate this problem, this extension SHOULD 


=A0=A0=A0=A0=A0=A0=A0only b=
e used in a secured environment, where encryption of SIP messages is 
=A0=A0=A0=A0=A0=A0=A0pro=
vided either end-to-end or hop-by-hop.=A0 </<=
/span>t><=
/span>



=A0=A0 
=A0=A0=A0=A0=A0=A0<t> Since the=
 P-Associated-URI header field value allows to implicitly register <=
u>



=A0=A0=A0=A0=A0=A0a bundle of URIs with one REGIS=
TER Message the impact of security using the P-Associated-URI header field =
is not higher than=A0 



=A0=
=A0=A0=A0=A0=A0using single REGISTER messages when registering all identiti=
es explicit.</t>


[MB] I just have some editorial sug=
gestions for the above:
=
NEW: =A0
<t>=A0While the P-Associated-URI header field value allows the i=
mplicit registration of=A0



=A0=A0=A0=A0=A0=A0a bundle of U=
RIs with one REGISTER Message the impact of security using the P-Associated=
-URI header field is no higher than=A0
=A0=A0=A0=A0=A0=A0using separate REGISTER m=
essages for each of the URIs.=A0</t>



[/MB]
=A0
=




=A0



=
=A0
=A0
For the P-Called-Party-Id the change sh=
ould be also done like as follows:



=A0=

=A0=A0=A0=A0=A0=A0=A0 <t>An eavesdropper could possibly collect the lis=
t of identities a user is registered.=A0 



=A0=A0=A0=A0=A0=A0=A0This can have privacy implic=
ations.=A0 To mitigate this problem, this extension SHOULD 


=A0=A0=A0=A0=A0=A0=A0only b=
e used in a secured environment, where encryption of SIP messages is 
=A0=A0=A0=A0=A0=A0=A0provided either end-to-end or ho=
p-by-hop.=A0 </t>



=A0


=A0=A0=A0=A0=A0=A0=A0 <t>Normally within a 3GPP environment the P-C=
alled-Party-ID is not sent towards end users but may be exchanged between c=
arriers where other security mechanisms than SIP encryption are used.=A0 </t<=
span style=3D"color:blue">>



=A0=

Sorry coming so late.



If this is=
 OK for you I will include it to a new version.



=A0=

Thank you and Best Regards



=A0=

Roland



=A0=




Von: Mary Barn=
es [mailto:=
mary.ietf.barnes@gmail.com] 


Gesendet: Freitag, 27. Dezember 2013 19:45
<=
div>

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



=A0
Hi Roland,
=A0
Thanks for mak=
ing these changes. I finally had a chance to review this updated version. =
=A0 I still have a couple comments on the security section as I think you w=
ill get questions during SEC review around this unless some more detail is =
provided on security threats and impacts. =A0 I've extracted these few =
points from previous review comment threads.



=A0
Thanks,
M=
ary.
=A0




----Previous point =A0------------------------------=
--->
- Section 6.1: this needs some tighter wordi=
ng. =A0What is meant by "potentially annoying" =A0for example? =
=A0



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



-<=
/u>
[MB] So, you removed that part of the sentence and are left with:



"This attack should not have any signifi=
cant impacts."
=A0
=A0
I don't think that adds any value and just begs the question &q=
uot;what are the insignificant impacts and are there any privacy concerns&q=
uot;?=A0 Really, it's the next paragraph that provides details of the i=
mpacts.=A0 I think you could probably remove that sentence altogether and n=
ot lose anything. 



=A0
=A0<=
u>
=
[/MB]



=A0
----Previous point --------------------------------->



=A0
-=A0 Section 6.2: I think you need to be mor=
e specific about the "nature" that makes this header not of parti=
cular concern with regards to security. Does it reveal additional, unique i=
nformation about an individual that isn't available in other headers. =
=A0Also, the 2nd paragraph needs some work - maybe something like:



=A0
=A0<=
u>
OLD:<=
u>



=A0<=
/pre>
=A0
An eave=
sdropper may collect the list of identities a user is registered.=A0 This m=
ay have privacy implications.=A0 To mitigate this problem, this extension S=
HOULD only be used in a secured environment, where encryption of SIP messag=
es is provided either end-to-end or



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



An eavesdropper could possibly =
collect the list of identities a user is registered.=A0 This can have priva=
cy implications.=A0 To mitigate this problem, this extension MUST only be u=
sed in a secured environment, where encryption of SIP messages is provided =
either end-to-end or hop-by-hop.=A0



----End prev=
ious point ------------------------------<

=A0
[MB]=A0 The suggeste=
d change for the first sentence didn't get into the revision.=A0 And, I=
 believe you still need to identify privacy/security implications by addres=
sing whether or not this header reveals any unique information about an ind=
ividual that isn't available in other headers.=A0=A0 [/MB]



=A0
=A0
=A0



=A0<=
/pre>
=A0
=A0=




On Tue, Dec 3, 2013 at 7:00 AM, <R.Jesske@telekom.de> 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.<=
/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 d=
raft-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 (SIP) for the 3rd=
-Generation Partnership Project (3GPP)



Creation date:=A0=A0=A0 2013-12-03<=
/u>
Group:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0 Individual Submission
N=
umber 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 Protocol<=
/u>



=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: DISPA=
TCH; Gonzalo Camarillo; Atle Monrad; Dean Willis



Betreff: Re: PROTO Review: draft-drage-sipping-rfc3455bis-09.txt<=
/u>
=A0
<=
div>
Hi Roland,


=A0
Thanks for your resp=
onse. =A0Additional comments below [MB].
=A0
Tha=
nks,



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



=
Hi Mary,
Thank you for your review.



I have add=
ed now your proposals to the draft.


Other comments please see below.<=
/span>
=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
=A0
=A0
=A0
- Section 3. =A0This section needs to be updated. =A0I don't think t=
hat 10 year old background is relevant in the current context. =A0 You shou=
ld be able to model this after the text in more recent 3GPP P-header docume=
nts, referring 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
=A0
=A0
=A0
Section 4.2, 1st paragraph. =
=A0The behavior in this sentence is not normative from a SIP protocol persp=
ective, thus MAY is not appropriate. =A0I suggest the MAY be changed to &qu=
ot;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.
=A0
=A0
=A0
NEW:=A0
=
=A0=A0 In the context of the network to which the header fields defined in =
this document apply, a User Agent has=A0no knowledge of the P-Visited-Netwo=
rk-ID when sending the REGISTER request. =A0Therefore user agent clients MU=
ST NOT insert a P-Visited-Network-ID=A0header field=A0in any SIP message.



=A0
- Section 4.3.2.2:, 2nd paragraph: =A0"=
;home network MAY use" -> "home network can use"


=A0
=A0<=
/pre>
=A0
=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>
=A0
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
=A0<=
u>
OLD:
=A0
=A0=A0 Depending on the call scenario it is nee=
ded to add for each transit
=A0=A0 network either a=
 transit network name or a void value. =A0Nevertheless
<=
pre>=A0=A0 it can not be guaranteed that all values will appear within the =
P-Charging-Vector header field.=A0


=A0
=A0<=
u>
NEW:=A0
=A0



=A0=A0 Depending o=
n the call scenario, each transit network can add either a transit network =
name=A0or a void=A0=A0=A0 value.=A0 However, it can not be guaranteed that =
all the values that are added will appear within the P-Charging-Vector head=
er 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
=A0
=A0



=A0
=A0<=
u>
- Section 5.7. Delete this text and table. =A0 We aren't the=
se tables anymore as they really don't provide any useful information. =
=A0You just need to verbally state what messages these headers can appear i=
n.=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
=A0<=
/pre>
=A0
=A0
hop-by-ho=
p.=A0
=A0 =A0=




=A0
NEW:=A0=

=A0
=
=A0An eavesdropper could possibly collect the list of identities a u=
ser is registered.=A0 This can have privacy implications.=A0 To mitigate th=
is problem, this extension MUST only be used in a secured environment, wher=
e encryption of SIP 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



- Section 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
=A0
=A0
=A0
-- 8th paragraph=
: "SHOULD NOT send sensitive information" -> "MUST NOT se=
nd sensitive 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
=A0
=A0
=A0
- Section 4.1, 2nd paragraph. =
=A0"has associated to an address-of-record" -> "has assoc=
iated with 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


=A0
=A0
=

=A0
<=
/div>






--047d7bea41fe659fe104efa2dc1d--

From aallen@blackberry.com  Fri Jan 10 11:45:28 2014
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 029281AE073 for ; Fri, 10 Jan 2014 11:45:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.136
X-Spam-Level: 
X-Spam-Status: No, score=-2.136 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, MANGLED_AVOID=2.3, NORMAL_HTTP_TO_IP=0.001, RP_MATCHES_RCVD=-0.538] 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 WPAIZsn0zNP1 for ; Fri, 10 Jan 2014 11:45:20 -0800 (PST)
Received: from smtp-p02.blackberry.com (smtp-p02.blackberry.com [208.65.78.89]) by ietfa.amsl.com (Postfix) with ESMTP id 5FBDC1AE1C7 for ; Fri, 10 Jan 2014 11:45:19 -0800 (PST)
Received: from xct108cnc.rim.net ([10.65.161.208]) by mhs214cnc.rim.net with ESMTP/TLS/AES128-SHA; 10 Jan 2014 14:45:06 -0500
Received: from XCT113CNC.rim.net (10.65.161.213) by XCT108CNC.rim.net (10.65.161.208) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 10 Jan 2014 14:45:06 -0500
Received: from XMB122CNC.rim.net ([fe80::28c6:fa1c:91c6:2e23]) by XCT113CNC.rim.net ([::1]) with mapi id 14.03.0158.001; Fri, 10 Jan 2014 14:45:05 -0500
From: Andrew Allen 
To: "mary.ietf.barnes@gmail.com" , "R.Jesske@telekom.de" 
Thread-Topic: [dispatch] PROTO Review: draft-drage-sipping-rfc3455bis-09.txt
Thread-Index: AQHPDjx1ffYXAL6MKUqyPrS6NTUpvg==
Date: Fri, 10 Jan 2014 19:45:04 +0000
Message-ID: 
In-Reply-To: 
Accept-Language: en-CA, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.65.160.251]
Content-Type: multipart/alternative; boundary="_000_BBF5DDFE515C3946BC18D733B20DAD233985F212XMB122CNCrimnet_"
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: Fri, 10 Jan 2014 19:45:28 -0000

--_000_BBF5DDFE515C3946BC18D733B20DAD233985F212XMB122CNCrimnet_
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64

DQpJIHRoaW5rIGl0IG9ic29sZXRlcyBSRkMgMzQ1NS4gSXQgaXMgYSBjb21wbGV0ZSByZXBsYWNl
bWVudCBmb3IgdGhlIG9yaWdpbmFsLg0KDQpBbmRyZXcNCg0KRnJvbTogTWFyeSBCYXJuZXMgW21h
aWx0bzptYXJ5LmlldGYuYmFybmVzQGdtYWlsLmNvbV0NClNlbnQ6IEZyaWRheSwgSmFudWFyeSAx
MCwgMjAxNCAwMjozNyBQTSBFYXN0ZXJuIFN0YW5kYXJkIFRpbWUNClRvOiBSLkplc3NrZUB0ZWxl
a29tLmRlIDxSLkplc3NrZUB0ZWxla29tLmRlPg0KQ2M6IERJU1BBVENIIDxkaXNwYXRjaEBpZXRm
Lm9yZz47IERlYW4gV2lsbGlzIDxkZWFuLndpbGxpc0Bzb2Z0YXJtb3IuY29tPg0KU3ViamVjdDog
UmU6IFtkaXNwYXRjaF0gUFJPVE8gUmV2aWV3OiBkcmFmdC1kcmFnZS1zaXBwaW5nLXJmYzM0NTVi
aXMtMDkudHh0DQoNClRoZXJlIGlzIHlldCBvbmUgbW9yZSBjaGFuZ2UgbmVlZGVkLiAgVGhpcyBk
b2N1bWVudCBpcyBhbiBVcGRhdGVzIHRvIDM0NTViaXMgKEFGQUlLLCB1bmxlc3MgT2JzZWxldGVz
IHdvcmtzIGJldHRlciBmb3IgM0dQUCB1c2FnZSkuICBUaGF0IGNhdGVnb3JpemF0aW9uIG5lZWRz
IHRvIGJlIGluY2x1ZGVkIGluIHRoZSBkb2N1bWVudCBoZWFkZXIgKDNyZCBsaW5lKS4NCg0KVGhh
bmtzLA0KTWFyeS4NCg0KDQpPbiBGcmksIEphbiAxMCwgMjAxNCBhdCAxOjM0IFBNLCBNYXJ5IEJh
cm5lcyA8bWFyeS5pZXRmLmJhcm5lc0BnbWFpbC5jb208bWFpbHRvOm1hcnkuaWV0Zi5iYXJuZXNA
Z21haWwuY29tPj4gd3JvdGU6DQpJTiBhZGRpdGlvbiB0byByZW1vdmluZyB0aGUgdW51c2VkIHJl
ZmVyZW5jZXMgaW4gdGhlIG5leHQgdXBkYXRlLCB0aGVyZSBhcmUgc3RpbGwgNCBkb21haW4gbmFt
ZXMgdGhhdCBhcmUgbm90IHVzaW5nIGFuIGFwcHJvcHJpYXRlIGRvY3VtZW50YXRpb24gZG9tYWlu
IChlLmcuLCBob21lLm5ldDxodHRwOi8vaG9tZS5uZXQ+KS4gIFBsZWFzZSBhZGQgdGhhdCBjaGFu
Z2UgdG8gdGhlIGxpc3QgZm9yIHRoZSBuZXh0IHJldmlzaW9uLiAgSSdtIGdvaW5nIHRvIGFoZWFk
IGFuZCBmb3J3YXJkIHRoZSBQUk9UTyB3cml0ZS11cCB0byBHb256YWxvLCBub3RpbmcgdGhlIGNo
YW5nZXMgdGhhdCBhcmUgbmVlZGVkIGFuZCBzdWdnZXN0aW5nIHRob3NlIGNoYW5nZXMgY2FuIGJl
IG1hZGUgYWxvbmcgd2l0aCBvdGhlciBJRVRGIExDIGNoYW5nZXMuDQoNClRoYW5rcywNCk1hcnkN
Cg0KDQpPbiBXZWQsIEphbiA4LCAyMDE0IGF0IDI6NDYgQU0sIDxSLkplc3NrZUB0ZWxla29tLmRl
PG1haWx0bzpSLkplc3NrZUB0ZWxla29tLmRlPj4gd3JvdGU6DQpUaGFuayB5b3UgTWFycnksDQpm
b3IgZG9pbmcgYWxsIHRoaXMgcmV2aWV3Lg0KU28gSSBoYXZlIG5vdyBwdXQgb3V0IHRoZSBlcnJv
cnMuDQpUaGVyZSBhcmUgc3RpbGwgc29tZSB1bnVzZWQgcmVmZXJlbmNlcyB3aGljaCBhcmUgaW4g
b3VyIGluZm9ybWFsIHJlZmVyZW5jZSBzZWN0aW9uLiBCdXQgdXNlZnVsIGZvciB0aGUgcmVhZGVy
IHRvIGtub3cgdGhleSBleGlzdC4NClRoZXJlIGFyZSBhbHNvIHNvbWUgd2FybmluZ3Mgd2l0aCBy
ZWdhcmQgdG8gSVAgYWRkcmVzc2VzIGFuZCB3cm9uZyBGUUROcyB3aGljaCBJIHRoaW5rIGlzIHNv
bWUgaW50ZXJwcmV0YXRpb24gb2Ygc3RyaW5ncyBpbiB0aGUgdGV4dCB3aGljaCBhcmUgbm90IG1l
YW50IHRvIGJlIGEgSVAgYWRkcmVzcyBvciBGUUROIGF0IGFsbC4NCg0KRGV0YWlsIHNlZSBiZWxv
dy4NCg0KU28gbm93IGhvcGVmdWxseSBldmVyeXRoaW5nIGlzIHJlYWR5IGZvciB0aGUgbmV4dCBz
dGVwLg0KDQpCZXN0IFJlZ2FyZHMNCg0KUm9sYW5kDQoNCnRtcC9kcmFmdC1kcmFnZS1zaXBwaW5n
LXJmYzM0NTViaXMtMTIudHh0Og0KDQogIENoZWNraW5nIGJvaWxlcnBsYXRlIHJlcXVpcmVkIGJ5
IFJGQyA1Mzc4IGFuZCB0aGUgSUVURiBUcnVzdCAoc2VlDQogIGh0dHA6Ly90cnVzdGVlLmlldGYu
b3JnL2xpY2Vuc2UtaW5mbyk6DQogIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KICAgICBObyBpc3N1
ZXMgZm91bmQgaGVyZS4NCg0KICBDaGVja2luZyBuaXRzIGFjY29yZGluZyB0byBodHRwOi8vd3d3
LmlldGYub3JnL2lkLWluZm8vMWlkLWd1aWRlbGluZXMudHh0Og0KICAtLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tDQoNCiAgICAgTm8gaXNzdWVzIGZvdW5kIGhlcmUuDQoNCiAgQ2hlY2tpbmcgbml0cyBhY2Nv
cmRpbmcgdG8gaHR0cDovL3d3dy5pZXRmLm9yZy9pZC1pbmZvL2NoZWNrbGlzdCA6DQogIC0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0NCg0KID09IFRoZXJlIGFyZSA0IGluc3RhbmNlcyBvZiBsaW5lcyB3aXRo
IG5vbi1SRkMyNjA2LWNvbXBsaWFudCBGUUROcyBpbiB0aGUNCiAgICAgZG9jdW1lbnQuDQoNCiAg
PT0gVGhlcmUgYXJlIDQgaW5zdGFuY2VzIG9mIGxpbmVzIHdpdGggbm9uLVJGQzU3MzUtY29tcGxp
YW50IElQdjQgYWRkcmVzc2VzDQogICAgIGluIHRoZSBkb2N1bWVudC4gIElmIHRoZXNlIGFyZSBl
eGFtcGxlIGFkZHJlc3NlcywgdGhleSBzaG91bGQgYmUgY2hhbmdlZC4NCg0KDQogIE1pc2NlbGxh
bmVvdXMgd2FybmluZ3M6DQogIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KICAgICBObyBpc3N1ZXMg
Zm91bmQgaGVyZS4NCg0KICBDaGVja2luZyByZWZlcmVuY2VzIGZvciBpbnRlbmRlZCBzdGF0dXM6
IEluZm9ybWF0aW9uYWwNCiAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQogID09IE1pc3NpbmcgUmVm
ZXJlbmNlOiAnUkZDIFhYWFgnIGlzIG1lbnRpb25lZCBvbiBsaW5lIDE2NjIsIGJ1dCBub3QgZGVm
aW5lZA0KDQogIC0tIExvb2tzIGxpa2UgYSByZWZlcmVuY2UsIGJ1dCBwcm9iYWJseSBpc24ndDog
JzMnIG9uIGxpbmUgMTk0Mw0KDQogID09IFVudXNlZCBSZWZlcmVuY2U6ICdSRkMzMjYyJyBpcyBk
ZWZpbmVkIG9uIGxpbmUgMjA2OCwgYnV0IG5vIGV4cGxpY2l0DQogICAgIHJlZmVyZW5jZSB3YXMg
Zm91bmQgaW4gdGhlIHRleHQNCg0KICA9PSBVbnVzZWQgUmVmZXJlbmNlOiAnUkZDMzMxMScgaXMg
ZGVmaW5lZCBvbiBsaW5lIDIwNzIsIGJ1dCBubyBleHBsaWNpdA0KICAgICByZWZlcmVuY2Ugd2Fz
IGZvdW5kIGluIHRoZSB0ZXh0DQoNCiAgPT0gVW51c2VkIFJlZmVyZW5jZTogJ1JGQzM0MjgnIGlz
IGRlZmluZWQgb24gbGluZSAyMDc4LCBidXQgbm8gZXhwbGljaXQNCiAgICAgcmVmZXJlbmNlIHdh
cyBmb3VuZCBpbiB0aGUgdGV4dA0KDQogID09IFVudXNlZCBSZWZlcmVuY2U6ICdSRkMzOTAzJyBp
cyBkZWZpbmVkIG9uIGxpbmUgMjA5MCwgYnV0IG5vIGV4cGxpY2l0DQogICAgIHJlZmVyZW5jZSB3
YXMgZm91bmQgaW4gdGhlIHRleHQNCg0KICA9PSBVbnVzZWQgUmVmZXJlbmNlOiAnUkZDNjA4Nicg
aXMgZGVmaW5lZCBvbiBsaW5lIDIxMDEsIGJ1dCBubyBleHBsaWNpdA0KICAgICByZWZlcmVuY2Ug
d2FzIGZvdW5kIGluIHRoZSB0ZXh0DQoNCg0KICAgICBTdW1tYXJ5OiAwIGVycm9ycyAoKiopLCAw
IGZsYXdzICh+fiksIDggd2FybmluZ3MgKD09KSwgMSBjb21tZW50ICgtLSkuDQoNCiAgICAgUnVu
IGlkbml0cyB3aXRoIHRoZSAtLXZlcmJvc2Ugb3B0aW9uIGZvciBtb3JlIGRldGFpbGVkIGluZm9y
bWF0aW9uIGFib3V0DQogICAgIHRoZSBpdGVtcyBhYm92ZS4NCi0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tDQoNCg0KDQpWb246IE1hcnkgQmFybmVzIFttYWlsdG86bWFyeS5pZXRmLmJhcm5lc0BnbWFp
bC5jb208bWFpbHRvOm1hcnkuaWV0Zi5iYXJuZXNAZ21haWwuY29tPl0NCkdlc2VuZGV0OiBEaWVu
c3RhZywgNy4gSmFudWFyIDIwMTQgMTg6NTUNCg0KQW46IEplc3NrZSwgUm9sYW5kDQpDYzogRElT
UEFUQ0g7IEdvbnphbG8gQ2FtYXJpbGxvOyBBdGxlIE1vbnJhZDsgRGVhbiBXaWxsaXMNCkJldHJl
ZmY6IFJlOiBQUk9UTyBSZXZpZXc6IGRyYWZ0LWRyYWdlLXNpcHBpbmctcmZjMzQ1NWJpcy0wOS50
eHQNCg0KVGhhbmtzIFJvbGFuZC4gIEkgaGF2ZSByZXZpZXdlZCB0aGF0IHZlcnNpb24gYW5kIGFs
bCB0aGUgY2hhbmdlcyBJIHN1Z2dlc3RlZCBoYXZlIGJlZW4gbWFkZS4gIEhvd2V2ZXIsIGluIGRv
aW5nIHRoZSBQUk9UTyB3cml0ZS11cCBJIHJlYWxpemVkIHRoYXQgSSB3YXNuJ3QgY2VydGFpbiBh
bnlvbmUgaGFkIHJldmlld2VkIHRoZSBBQk5GLiBTbywgSSByYW4gdGhlIEFCTkYgdGhyb3VnaCBC
aWxsIEZlbm5lcidzIHRvb2w6DQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvdG9vbHMvYmFwL2FibmYu
Y2dpDQoNCkFuZCwgdGhlcmUgYXJlIGEgY291cGxlIHRoaW5ncyB0aGF0IG5lZWQgdG8gYmUgZml4
ZWQ6DQoxKSAgRE9UIG5lZWRzIHRvIGNoYW5nZSB0byAiLiIgKHdlIGhhZCB0aGlzIHNhbWUgYnVn
IGluIFJGQyA0MjQ0KToNCnRyYW5zaXQtaW9pLWluZGV4ZWQtdmFsdWUgPSB0cmFuc2l0LWlvaS1u
YW1lIERPVCB0cmFuc2l0LWlvaS1pbmRleA0KDQoyKSAgVGhlcmUncyBhbiBleHRyYSBzcGFjZSBo
ZXJlIChiZXR3ZWVuICogYW5kIHBhcmVudGhlc2lzKToNCnRyYW5zaXQtaW9pLW5hbWUgICAgICAg
ICAgPSBBTFBIQSAqIChBTFBIQSAvIERJR0lUKQ0KTkV3OiB0cmFuc2l0LWlvaS1uYW1lICAgICAg
ICAgID0gQUxQSEEgKihBTFBIQSAvIERJR0lUKQ0KDQpUaGVyZSBhcmUgYWxzbyBhIG51bWJlciBv
ZiBsb25nIGxpbmVzIGluIHRoZSBBQk5GIHRoYXQgc2hvdWxkIGJlIGZpeGVkLg0KDQpJbiBhZGRp
dGlvbiwgSUROSVRTIGlkZW50aWZpZXMgb3RoZXIgZXJyb3JzIGFuZCB3YXJuaW5ncyBwZXIgdGhl
IGZvbGxvd2luZy4gIFRob3NlIHNob3VsZCBhbHNvIGJlIGFkZHJlc3NlZCBpbmNsdWRpbmcgY29u
c2lkZXJpbmcgd2hldGhlciBvYnNvbGV0ZSByZWZlcmVuY2VzIG5lZWQgY2hhbmdpbmc6DQoNCg0K
DQppZG5pdHMgMi4xMy4wMQ0KDQoNCg0KdG1wL2RyYWZ0LWRyYWdlLXNpcHBpbmctcmZjMzQ1NWJp
cy0xMS50eHQ6DQoNCg0KDQogIENoZWNraW5nIGJvaWxlcnBsYXRlIHJlcXVpcmVkIGJ5IFJGQyA1
Mzc4IGFuZCB0aGUgSUVURiBUcnVzdCAoc2VlDQoNCiAgaHR0cDovL3RydXN0ZWUuaWV0Zi5vcmcv
bGljZW5zZS1pbmZvKToNCg0KICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCg0KDQogICAgIE5vIGlz
c3VlcyBmb3VuZCBoZXJlLg0KDQoNCg0KICBDaGVja2luZyBuaXRzIGFjY29yZGluZyB0byBodHRw
Oi8vd3d3LmlldGYub3JnL2lkLWluZm8vMWlkLWd1aWRlbGluZXMudHh0Og0KDQogIC0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0NCg0KDQoNCiAgICAgTm8gaXNzdWVzIGZvdW5kIGhlcmUuDQoNCg0KDQogIENo
ZWNraW5nIG5pdHMgYWNjb3JkaW5nIHRvIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaWQtaW5mby9jaGVj
a2xpc3QgOg0KDQogIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KDQoNCiAgKiogVGhlcmUgYXJlIDkg
aW5zdGFuY2VzIG9mIHRvbyBsb25nIGxpbmVzIGluIHRoZSBkb2N1bWVudCwgdGhlIGxvbmdlc3Qg
b25lDQoNCiAgICAgYmVpbmcgMjAgY2hhcmFjdGVycyBpbiBleGNlc3Mgb2YgNzIuDQoNCg0KDQog
ID09IFRoZXJlIGFyZSA0IGluc3RhbmNlcyBvZiBsaW5lcyB3aXRoIG5vbi1SRkMyNjA2LWNvbXBs
aWFudCBGUUROcyBpbiB0aGUNCg0KICAgICBkb2N1bWVudC4NCg0KDQoNCiAgPT0gVGhlcmUgYXJl
IDQgaW5zdGFuY2VzIG9mIGxpbmVzIHdpdGggbm9uLVJGQzU3MzUtY29tcGxpYW50IElQdjQgYWRk
cmVzc2VzDQoNCiAgICAgaW4gdGhlIGRvY3VtZW50LiAgSWYgdGhlc2UgYXJlIGV4YW1wbGUgYWRk
cmVzc2VzLCB0aGV5IHNob3VsZCBiZSBjaGFuZ2VkLg0KDQoNCg0KDQoNCiAgTWlzY2VsbGFuZW91
cyB3YXJuaW5nczoNCg0KICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCg0KDQogID09IFRoZSBkb2N1
bWVudCBzZWVtcyB0byBjb250YWluIGEgZGlzY2xhaW1lciBmb3IgcHJlLVJGQzUzNzggd29yaywg
YnV0IHdhcw0KDQogICAgIGZpcnN0IHN1Ym1pdHRlZCBvbiBvciBhZnRlciAxMCBOb3ZlbWJlciAy
MDA4LiAgVGhlIGRpc2NsYWltZXIgaXMgdXN1YWxseQ0KDQogICAgIG5lY2Vzc2FyeSBvbmx5IGZv
ciBkb2N1bWVudHMgdGhhdCByZXZpc2Ugb3Igb2Jzb2xldGUgb2xkZXIgUkZDcywgYW5kIHRoYXQN
Cg0KICAgICB0YWtlIHNpZ25pZmljYW50IGFtb3VudHMgb2YgdGV4dCBmcm9tIHRob3NlIFJGQ3Mu
ICBJZiB5b3UgY2FuIGNvbnRhY3QgYWxsDQoNCiAgICAgYXV0aG9ycyBvZiB0aGUgc291cmNlIG1h
dGVyaWFsIGFuZCB0aGV5IGFyZSB3aWxsaW5nIHRvIGdyYW50IHRoZSBCQ1A3OA0KDQogICAgIHJp
Z2h0cyB0byB0aGUgSUVURiBUcnVzdCwgeW91IGNhbiBhbmQgc2hvdWxkIHJlbW92ZSB0aGUgZGlz
Y2xhaW1lci4NCg0KICAgICBPdGhlcndpc2UsIHRoZSBkaXNjbGFpbWVyIGlzIG5lZWRlZCBhbmQg
eW91IGNhbiBpZ25vcmUgdGhpcyBjb21tZW50Lg0KDQogICAgIChTZWUgdGhlIExlZ2FsIFByb3Zp
c2lvbnMgZG9jdW1lbnQgYXQNCg0KICAgICBodHRwOi8vdHJ1c3RlZS5pZXRmLm9yZy9saWNlbnNl
LWluZm8gZm9yIG1vcmUgaW5mb3JtYXRpb24uKQ0KDQoNCg0KDQoNCiAgQ2hlY2tpbmcgcmVmZXJl
bmNlcyBmb3IgaW50ZW5kZWQgc3RhdHVzOiBJbmZvcm1hdGlvbmFsDQoNCiAgLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLQ0KDQoNCg0KICA9PSBNaXNzaW5nIFJlZmVyZW5jZTogJ1JGQyBYWFhYJyBpcyBtZW50
aW9uZWQgb24gbGluZSAxNjY3LCBidXQgbm90IGRlZmluZWQNCg0KDQoNCiAgLS0gTG9va3MgbGlr
ZSBhIHJlZmVyZW5jZSwgYnV0IHByb2JhYmx5IGlzbid0OiAnMycgb24gbGluZSAxOTQ4DQoNCg0K
DQogID09IFVudXNlZCBSZWZlcmVuY2U6ICdSRkMyOTc2JyBpcyBkZWZpbmVkIG9uIGxpbmUgMjA2
NSwgYnV0IG5vIGV4cGxpY2l0DQoNCiAgICAgcmVmZXJlbmNlIHdhcyBmb3VuZCBpbiB0aGUgdGV4
dA0KDQoNCg0KICA9PSBVbnVzZWQgUmVmZXJlbmNlOiAnUkZDMzI2MicgaXMgZGVmaW5lZCBvbiBs
aW5lIDIwNjgsIGJ1dCBubyBleHBsaWNpdA0KDQogICAgIHJlZmVyZW5jZSB3YXMgZm91bmQgaW4g
dGhlIHRleHQNCg0KDQoNCiAgPT0gVW51c2VkIFJlZmVyZW5jZTogJ1JGQzMzMTEnIGlzIGRlZmlu
ZWQgb24gbGluZSAyMDc1LCBidXQgbm8gZXhwbGljaXQNCg0KICAgICByZWZlcmVuY2Ugd2FzIGZv
dW5kIGluIHRoZSB0ZXh0DQoNCg0KDQogID09IFVudXNlZCBSZWZlcmVuY2U6ICdSRkMzNDI4JyBp
cyBkZWZpbmVkIG9uIGxpbmUgMjA4MSwgYnV0IG5vIGV4cGxpY2l0DQoNCiAgICAgcmVmZXJlbmNl
IHdhcyBmb3VuZCBpbiB0aGUgdGV4dA0KDQoNCg0KICA9PSBVbnVzZWQgUmVmZXJlbmNlOiAnUkZD
MzkwMycgaXMgZGVmaW5lZCBvbiBsaW5lIDIwOTMsIGJ1dCBubyBleHBsaWNpdA0KDQogICAgIHJl
ZmVyZW5jZSB3YXMgZm91bmQgaW4gdGhlIHRleHQNCg0KDQoNCiAgKiogT2Jzb2xldGUgbm9ybWF0
aXZlIHJlZmVyZW5jZTogUkZDIDIyMzQgKE9ic29sZXRlZCBieSBSRkMgNDIzNCkNCg0KDQoNCiAg
LS0gT2Jzb2xldGUgaW5mb3JtYXRpb25hbCByZWZlcmVuY2UgKGlzIHRoaXMgaW50ZW50aW9uYWw/
KTogUkZDIDI5NzYNCg0KICAgICAoT2Jzb2xldGVkIGJ5IFJGQyA2MDg2KQ0KDQoNCg0KICAtLSBP
YnNvbGV0ZSBpbmZvcm1hdGlvbmFsIHJlZmVyZW5jZSAoaXMgdGhpcyBpbnRlbnRpb25hbD8pOiBS
RkMgMzI2NQ0KDQogICAgIChPYnNvbGV0ZWQgYnkgUkZDIDY2NjUpDQoNCg0KDQoNCg0KICAgICBT
dW1tYXJ5OiAyIGVycm9ycyAoKiopLCAwIGZsYXdzICh+fiksIDkgd2FybmluZ3MgKD09KSwgMyBj
b21tZW50cyAoLS0pLg0KDQoNCg0KICAgICBSdW4gaWRuaXRzIHdpdGggdGhlIC0tdmVyYm9zZSBv
cHRpb24gZm9yIG1vcmUgZGV0YWlsZWQgaW5mb3JtYXRpb24gYWJvdXQNCg0KICAgICB0aGUgaXRl
bXMgYWJvdmUuDQpXaGlsZSBJIGFwb2xvZ2l6ZSBmb3Igbm90IGNhdGNoaW5nIHRoZXNlIGlzc3Vl
cyBlYXJsaWVyLCBpdCByZWFsbHkgaXMgdGhlIHJlc3BvbnNpYmlsaXR5IG9mIGF1dGhvcnMgdG8g
Y2hlY2sgaWRuaXRzIChiZXlvbmQgd2hhdCB0aGUgc3VibWlzc2lvbiB0b29sIHJlcXVpcmVzKSBm
b3IgdGhlaXIgZG9jdW1lbnRzLiAgSSByb3V0aW5lbHkgcnVuIGlkbml0cyBiZWZvcmUgSSBzdWJt
aXQgYSBkb2N1bWVudCBhcyBpdCBjYW4gYWxzbyBzYXZlIHRpbWUgd2hlbiBmaXhpbmcgdGhlICBu
aXRzIHRoYXQgdGhlIHN1Ym1pc3Npb24gdG9vbCBjYXRjaGVzOiAgIGh0dHBzOi8vdG9vbHMuaWV0
Zi5vcmcvdG9vbHMvaWRuaXRzLw0KDQpSZWdhcmRzLA0KTWFyeS4NCg0KDQoNCk9uIFR1ZSwgSmFu
IDcsIDIwMTQgYXQgMTI6MzUgQU0sIDxSLkplc3NrZUB0ZWxla29tLmRlPG1haWx0bzpSLkplc3Nr
ZUB0ZWxla29tLmRlPj4gd3JvdGU6DQpIaSBNYXJ5LA0KTm93IGEgbmV3IHJldmlzaW9uIGlzIGF2
YWlsYWJsZS4NCg0KVGhhbmsgeW91IGFuZCBCZXN0IFJlZ2FyZHMNCg0KUm9sYW5kDQoNClZvbjog
TWFyeSBCYXJuZXMgW21haWx0bzptYXJ5LmlldGYuYmFybmVzQGdtYWlsLmNvbTxtYWlsdG86bWFy
eS5pZXRmLmJhcm5lc0BnbWFpbC5jb20+XQ0KR2VzZW5kZXQ6IE1vbnRhZywgNi4gSmFudWFyIDIw
MTQgMjA6MDANCg0KQW46IEplc3NrZSwgUm9sYW5kDQpDYzogRElTUEFUQ0g7IEdvbnphbG8gQ2Ft
YXJpbGxvOyBBdGxlIE1vbnJhZDsgRGVhbiBXaWxsaXMNCkJldHJlZmY6IFJlOiBQUk9UTyBSZXZp
ZXc6IGRyYWZ0LWRyYWdlLXNpcHBpbmctcmZjMzQ1NWJpcy0wOS50eHQNCg0KSGkgUm9sYW5kLA0K
DQpPbmUgZmluYWwgZWRpdG9yaWFsIG5pdCBiZWxvdy4gIElmIHlvdSBjYW4gc3BpbiBhIHJldmlz
aW9uLCB0aGVuIEknbGwgc2VuZCB0aGUgUFJPVE8gd3JpdGUtdXAgdG8gdGhlIEFELg0KDQpUaGFu
a3MsDQpNYXJ5Lg0KDQpPbiBUaHUsIEphbiAyLCAyMDE0IGF0IDM6MjkgQU0sIDxSLkplc3NrZUB0
ZWxla29tLmRlPG1haWx0bzpSLkplc3NrZUB0ZWxla29tLmRlPj4gd3JvdGU6DQpIaSBNYXJ5LA0K
SSB3aXNoIHlvdSBhIGhhcHB5IG5ldyB5ZWFyIDIwMTQuIEFuZCB0aGUgYmVzdCBmb3IgdGhlIG5l
eHQgeWVhci4NCg0KSSB3YXMgbG9va2luZyBhZ2FpbiBvbiBteSBjaGFuZ2VzIEkgbWFkZSBkdWUg
dG8geW91ciBwcm9wb3NhbCBpbiBEZWNlbWJlci4NCkkgcmVhbGl6ZWQgdGhhdCBpZiBJIGNoYW5n
ZSB0aGUgU0hPVUxEIHRvIE1VU1Qgd2UgaGF2ZSBub3cgYSBiYWNrd2FyZCBjb21wYXRpYmlsaXR5
IHByb2JsZW0uDQpXZSBhcmUgdXNpbmcgdGhlIFAtQXNzb2NpYXRlZC1VUkkgYWxzbyBvdmVyIHRo
ZSBJTVMgdXNlciBpbnRlcmZhY2Ugd2hpY2ggaXMgbm90IGVuY3J5cHRlZC4NClNvIEkgcHJvcG9z
ZSB0byBhZGQgc29tZSBtb3JlIHdvcmRzLg0K4oCmDQpTZWN0aW9uIDYuMQ0K4oCmDQogICAgICAg
ICA8dD5BbiBlYXZlc2Ryb3BwZXIgY291bGQgcG9zc2libHkgY29sbGVjdCB0aGUgbGlzdCBvZiBp
ZGVudGl0aWVzIGEgdXNlciBpcyByZWdpc3RlcmVkLg0KICAgICAgIFRoaXMgY2FuIGhhdmUgcHJp
dmFjeSBpbXBsaWNhdGlvbnMuIFRvIG1pdGlnYXRlIHRoaXMgcHJvYmxlbSwgdGhpcyBleHRlbnNp
b24gU0hPVUxEDQogICAgICAgb25seSBiZSB1c2VkIGluIGEgc2VjdXJlZCBlbnZpcm9ubWVudCwg
d2hlcmUgZW5jcnlwdGlvbiBvZiBTSVAgbWVzc2FnZXMgaXMNCiAgICAgICBwcm92aWRlZCBlaXRo
ZXIgZW5kLXRvLWVuZCBvciBob3AtYnktaG9wLiAgPC90Pg0KDQogICAgICA8dD4gU2luY2UgdGhl
IFAtQXNzb2NpYXRlZC1VUkkgaGVhZGVyIGZpZWxkIHZhbHVlIGFsbG93cyB0byBpbXBsaWNpdGx5
IHJlZ2lzdGVyDQogICAgICBhIGJ1bmRsZSBvZiBVUklzIHdpdGggb25lIFJFR0lTVEVSIE1lc3Nh
Z2UgdGhlIGltcGFjdCBvZiBzZWN1cml0eSB1c2luZyB0aGUgUC1Bc3NvY2lhdGVkLVVSSSBoZWFk
ZXIgZmllbGQgaXMgbm90IGhpZ2hlciB0aGFuDQogICAgICB1c2luZyBzaW5nbGUgUkVHSVNURVIg
bWVzc2FnZXMgd2hlbiByZWdpc3RlcmluZyBhbGwgaWRlbnRpdGllcyBleHBsaWNpdC48L3Q+DQpb
TUJdIEkganVzdCBoYXZlIHNvbWUgZWRpdG9yaWFsIHN1Z2dlc3Rpb25zIGZvciB0aGUgYWJvdmU6
DQpORVc6DQo8dD4gV2hpbGUgdGhlIFAtQXNzb2NpYXRlZC1VUkkgaGVhZGVyIGZpZWxkIHZhbHVl
IGFsbG93cyB0aGUgaW1wbGljaXQgcmVnaXN0cmF0aW9uIG9mDQogICAgICBhIGJ1bmRsZSBvZiBV
UklzIHdpdGggb25lIFJFR0lTVEVSIE1lc3NhZ2UgdGhlIGltcGFjdCBvZiBzZWN1cml0eSB1c2lu
ZyB0aGUgUC1Bc3NvY2lhdGVkLVVSSSBoZWFkZXIgZmllbGQgaXMgbm8gaGlnaGVyIHRoYW4NCiAg
ICAgIHVzaW5nIHNlcGFyYXRlIFJFR0lTVEVSIG1lc3NhZ2VzIGZvciBlYWNoIG9mIHRoZSBVUklz
LiA8L3Q+DQpbL01CXQ0KDQoNCg0KDQpGb3IgdGhlIFAtQ2FsbGVkLVBhcnR5LUlkIHRoZSBjaGFu
Z2Ugc2hvdWxkIGJlIGFsc28gZG9uZSBsaWtlIGFzIGZvbGxvd3M6DQoNCiAgICAgICAgPHQ+QW4g
ZWF2ZXNkcm9wcGVyIGNvdWxkIHBvc3NpYmx5IGNvbGxlY3QgdGhlIGxpc3Qgb2YgaWRlbnRpdGll
cyBhIHVzZXIgaXMgcmVnaXN0ZXJlZC4NCiAgICAgICBUaGlzIGNhbiBoYXZlIHByaXZhY3kgaW1w
bGljYXRpb25zLiAgVG8gbWl0aWdhdGUgdGhpcyBwcm9ibGVtLCB0aGlzIGV4dGVuc2lvbiBTSE9V
TEQNCiAgICAgICBvbmx5IGJlIHVzZWQgaW4gYSBzZWN1cmVkIGVudmlyb25tZW50LCB3aGVyZSBl
bmNyeXB0aW9uIG9mIFNJUCBtZXNzYWdlcyBpcw0KICAgICAgIHByb3ZpZGVkIGVpdGhlciBlbmQt
dG8tZW5kIG9yIGhvcC1ieS1ob3AuICA8L3Q+DQoNCiAgICAgICAgPHQ+Tm9ybWFsbHkgd2l0aGlu
IGEgM0dQUCBlbnZpcm9ubWVudCB0aGUgUC1DYWxsZWQtUGFydHktSUQgaXMgbm90IHNlbnQgdG93
YXJkcyBlbmQgdXNlcnMgYnV0IG1heSBiZSBleGNoYW5nZWQgYmV0d2VlbiBjYXJyaWVycyB3aGVy
ZSBvdGhlciBzZWN1cml0eSBtZWNoYW5pc21zIHRoYW4gU0lQIGVuY3J5cHRpb24gYXJlIHVzZWQu
ICA8L3Q+DQoNClNvcnJ5IGNvbWluZyBzbyBsYXRlLg0KSWYgdGhpcyBpcyBPSyBmb3IgeW91IEkg
d2lsbCBpbmNsdWRlIGl0IHRvIGEgbmV3IHZlcnNpb24uDQoNClRoYW5rIHlvdSBhbmQgQmVzdCBS
ZWdhcmRzDQoNClJvbGFuZA0KDQpWb246IE1hcnkgQmFybmVzIFttYWlsdG86bWFyeS5pZXRmLmJh
cm5lc0BnbWFpbC5jb208bWFpbHRvOm1hcnkuaWV0Zi5iYXJuZXNAZ21haWwuY29tPl0NCkdlc2Vu
ZGV0OiBGcmVpdGFnLCAyNy4gRGV6ZW1iZXIgMjAxMyAxOTo0NQ0KDQpBbjogSmVzc2tlLCBSb2xh
bmQNCkNjOiBESVNQQVRDSDsgR29uemFsbyBDYW1hcmlsbG87IEF0bGUgTW9ucmFkOyBEZWFuIFdp
bGxpcw0KQmV0cmVmZjogUmU6IFBST1RPIFJldmlldzogZHJhZnQtZHJhZ2Utc2lwcGluZy1yZmMz
NDU1YmlzLTA5LnR4dA0KDQpIaSBSb2xhbmQsDQoNClRoYW5rcyBmb3IgbWFraW5nIHRoZXNlIGNo
YW5nZXMuIEkgZmluYWxseSBoYWQgYSBjaGFuY2UgdG8gcmV2aWV3IHRoaXMgdXBkYXRlZCB2ZXJz
aW9uLiAgIEkgc3RpbGwgaGF2ZSBhIGNvdXBsZSBjb21tZW50cyBvbiB0aGUgc2VjdXJpdHkgc2Vj
dGlvbiBhcyBJIHRoaW5rIHlvdSB3aWxsIGdldCBxdWVzdGlvbnMgZHVyaW5nIFNFQyByZXZpZXcg
YXJvdW5kIHRoaXMgdW5sZXNzIHNvbWUgbW9yZSBkZXRhaWwgaXMgcHJvdmlkZWQgb24gc2VjdXJp
dHkgdGhyZWF0cyBhbmQgaW1wYWN0cy4gICBJJ3ZlIGV4dHJhY3RlZCB0aGVzZSBmZXcgcG9pbnRz
IGZyb20gcHJldmlvdXMgcmV2aWV3IGNvbW1lbnQgdGhyZWFkcy4NCg0KVGhhbmtzLA0KTWFyeS4N
Cg0KLS0tLVByZXZpb3VzIHBvaW50ICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0+
DQoNCi0gU2VjdGlvbiA2LjE6IHRoaXMgbmVlZHMgc29tZSB0aWdodGVyIHdvcmRpbmcuICBXaGF0
IGlzIG1lYW50IGJ5ICJwb3RlbnRpYWxseSBhbm5veWluZyIgIGZvciBleGFtcGxlPw0KDQogW1JK
XSBJIGRvIG5vdCBrbm93LiBUaGlzIGlzIG9yaWdpbmFsIHRleHQuIFNvIEkgZGVsZXRlZCB0aGUg
d29yZHMuDQoNCi0NCg0KW01CXSBTbywgeW91IHJlbW92ZWQgdGhhdCBwYXJ0IG9mIHRoZSBzZW50
ZW5jZSBhbmQgYXJlIGxlZnQgd2l0aDoNCg0KIlRoaXMgYXR0YWNrIHNob3VsZCBub3QgaGF2ZSBh
bnkgc2lnbmlmaWNhbnQgaW1wYWN0cy4iDQoNCg0KDQoNCg0KDQpJIGRvbid0IHRoaW5rIHRoYXQg
YWRkcyBhbnkgdmFsdWUgYW5kIGp1c3QgYmVncyB0aGUgcXVlc3Rpb24gIndoYXQgYXJlIHRoZSBp
bnNpZ25pZmljYW50IGltcGFjdHMgYW5kIGFyZSB0aGVyZSBhbnkgcHJpdmFjeSBjb25jZXJucyI/
ICBSZWFsbHksIGl0J3MgdGhlIG5leHQgcGFyYWdyYXBoIHRoYXQgcHJvdmlkZXMgZGV0YWlscyBv
ZiB0aGUgaW1wYWN0cy4gIEkgdGhpbmsgeW91IGNvdWxkIHByb2JhYmx5IHJlbW92ZSB0aGF0IHNl
bnRlbmNlIGFsdG9nZXRoZXIgYW5kIG5vdCBsb3NlIGFueXRoaW5nLg0KDQoNCg0KDQoNCg0KDQoN
ClsvTUJdDQoNCg0KDQotLS0tUHJldmlvdXMgcG9pbnQgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tPg0KDQoNCg0KLSAgU2VjdGlvbiA2LjI6IEkgdGhpbmsgeW91IG5lZWQgdG8gYmUg
bW9yZSBzcGVjaWZpYyBhYm91dCB0aGUgIm5hdHVyZSIgdGhhdCBtYWtlcyB0aGlzIGhlYWRlciBu
b3Qgb2YgcGFydGljdWxhciBjb25jZXJuIHdpdGggcmVnYXJkcyB0byBzZWN1cml0eS4gRG9lcyBp
dCByZXZlYWwgYWRkaXRpb25hbCwgdW5pcXVlIGluZm9ybWF0aW9uIGFib3V0IGFuIGluZGl2aWR1
YWwgdGhhdCBpc24ndCBhdmFpbGFibGUgaW4gb3RoZXIgaGVhZGVycy4gIEFsc28sIHRoZSAybmQg
cGFyYWdyYXBoIG5lZWRzIHNvbWUgd29yayAtIG1heWJlIHNvbWV0aGluZyBsaWtlOg0KDQoNCg0K
DQoNCg0KDQoNCk9MRDoNCg0KDQoNCg0KDQpBbiBlYXZlc2Ryb3BwZXIgbWF5IGNvbGxlY3QgdGhl
IGxpc3Qgb2YgaWRlbnRpdGllcyBhIHVzZXIgaXMgcmVnaXN0ZXJlZC4gIFRoaXMgbWF5IGhhdmUg
cHJpdmFjeSBpbXBsaWNhdGlvbnMuICBUbyBtaXRpZ2F0ZSB0aGlzIHByb2JsZW0sIHRoaXMgZXh0
ZW5zaW9uIFNIT1VMRCBvbmx5IGJlIHVzZWQgaW4gYSBzZWN1cmVkIGVudmlyb25tZW50LCB3aGVy
ZSBlbmNyeXB0aW9uIG9mIFNJUCBtZXNzYWdlcyBpcyBwcm92aWRlZCBlaXRoZXIgZW5kLXRvLWVu
ZCBvcg0KDQoNCg0KDQoNCg0KDQoNCmhvcC1ieS1ob3AuDQoNCg0KTkVXOg0KDQoNCg0KQW4gZWF2
ZXNkcm9wcGVyIGNvdWxkIHBvc3NpYmx5IGNvbGxlY3QgdGhlIGxpc3Qgb2YgaWRlbnRpdGllcyBh
IHVzZXIgaXMgcmVnaXN0ZXJlZC4gIFRoaXMgY2FuIGhhdmUgcHJpdmFjeSBpbXBsaWNhdGlvbnMu
ICBUbyBtaXRpZ2F0ZSB0aGlzIHByb2JsZW0sIHRoaXMgZXh0ZW5zaW9uIE1VU1Qgb25seSBiZSB1
c2VkIGluIGEgc2VjdXJlZCBlbnZpcm9ubWVudCwgd2hlcmUgZW5jcnlwdGlvbiBvZiBTSVAgbWVz
c2FnZXMgaXMgcHJvdmlkZWQgZWl0aGVyIGVuZC10by1lbmQgb3IgaG9wLWJ5LWhvcC4NCg0KLS0t
LUVuZCBwcmV2aW91cyBwb2ludCAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08DQoNCg0K
DQoNCltNQl0gIFRoZSBzdWdnZXN0ZWQgY2hhbmdlIGZvciB0aGUgZmlyc3Qgc2VudGVuY2UgZGlk
bid0IGdldCBpbnRvIHRoZSByZXZpc2lvbi4gIEFuZCwgSSBiZWxpZXZlIHlvdSBzdGlsbCBuZWVk
IHRvIGlkZW50aWZ5IHByaXZhY3kvc2VjdXJpdHkgaW1wbGljYXRpb25zIGJ5IGFkZHJlc3Npbmcg
d2hldGhlciBvciBub3QgdGhpcyBoZWFkZXIgcmV2ZWFscyBhbnkgdW5pcXVlIGluZm9ybWF0aW9u
IGFib3V0IGFuIGluZGl2aWR1YWwgdGhhdCBpc24ndCBhdmFpbGFibGUgaW4gb3RoZXIgaGVhZGVy
cy4gICBbL01CXQ0KDQoNCg0KDQoNCg0KDQoNCg0KDQpPbiBUdWUsIERlYyAzLCAyMDEzIGF0IDc6
MDAgQU0sIDxSLkplc3NrZUB0ZWxla29tLmRlPG1haWx0bzpSLkplc3NrZUB0ZWxla29tLmRlPj4g
d3JvdGU6DQpIaSBNYXJ5LA0KVGhhbmsgeW91IGZvciB5b3VyIGNvbW1lbnRzIGFuZCBwcm9wb3Nh
bHMuDQpJIGhhdmUgbm93IGluY2x1ZGVkIGFsbCBjb21tZW50cyBhbmQgdXBsb2FkZWQgYSBuZXcg
dmVyc2lvbi4NClNvIHdlIGNhbiBub3cgcHJvY2VlZC4NCg0KVGhhbmsgeW91IGFuZCBCZXN0IFJl
Z2FyZHMNCg0KUm9sYW5kDQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWRyYWdlLXNp
cHBpbmctcmZjMzQ1NWJpcy0xMC50eHQNCg0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRl
ZCBieSBSb2xhbmQgSmVzc2tlIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0K
DQoNCkZpbGVuYW1lOiAgIGRyYWZ0LWRyYWdlLXNpcHBpbmctcmZjMzQ1NWJpcw0KDQpSZXZpc2lv
bjogICAxMA0KDQpUaXRsZTogICAgICAgICAgICBQcml2YXRlIEhlYWRlciAoUC1IZWFkZXIpIEV4
dGVuc2lvbnMgdG8gdGhlIFNlc3Npb24gSW5pdGlhdGlvbiBQcm90b2NvbCAoU0lQKSBmb3IgdGhl
IDNyZC1HZW5lcmF0aW9uIFBhcnRuZXJzaGlwIFByb2plY3QgKDNHUFApDQoNCkNyZWF0aW9uIGRh
dGU6ICAgIDIwMTMtMTItMDMNCg0KR3JvdXA6ICAgICAgICAgICAgSW5kaXZpZHVhbCBTdWJtaXNz
aW9uDQoNCk51bWJlciBvZiBwYWdlczogNDYNCg0KVVJMOiAgICAgICAgICAgICBodHRwOi8vd3d3
LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1kcmFnZS1zaXBwaW5nLXJmYzM0NTViaXMt
MTAudHh0DQoNClN0YXR1czogICAgICAgICAgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv
Yy9kcmFmdC1kcmFnZS1zaXBwaW5nLXJmYzM0NTViaXMNCg0KSHRtbGl6ZWQ6ICAgICAgICBodHRw
Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1kcmFnZS1zaXBwaW5nLXJmYzM0NTViaXMtMTAN
Cg0KRGlmZjogICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFm
dC1kcmFnZS1zaXBwaW5nLXJmYzM0NTViaXMtMTANCg0KDQoNCkFic3RyYWN0Og0KDQogICBUaGlz
IGRvY3VtZW50IGRlc2NyaWJlcyBhIHNldCBvZiBwcml2YXRlIFNlc3Npb24gSW5pdGlhdGlvbiBQ
cm90b2NvbA0KDQogICAoU0lQKSBoZWFkZXIgZmllbGRzIChQLWhlYWRlcnMpIHVzZWQgYnkgdGhl
IDNyZC1HZW5lcmF0aW9uDQoNCiAgIFBhcnRuZXJzaGlwIFByb2plY3QgKDNHUFApLCBhbG9uZyB3
aXRoIHRoZWlyIGFwcGxpY2FiaWxpdHksIHdoaWNoIGlzDQoNCiAgIGxpbWl0ZWQgdG8gcGFydGlj
dWxhciBlbnZpcm9ubWVudHMuICBUaGUgUC1oZWFkZXIgZmllbGRzIGFyZSBmb3IgYQ0KDQogICB2
YXJpZXR5IG9mIHB1cnBvc2VzIHdpdGhpbiB0aGUgbmV0d29ya3MgdGhhdCB0aGUgcGFydG5lcnMg
dXNlLA0KDQogICBpbmNsdWRpbmcgY2hhcmdpbmcgYW5kIGluZm9ybWF0aW9uIGFib3V0IHRoZSBu
ZXR3b3JrcyBhIGNhbGwNCg0KICAgdHJhdmVyc2VzLg0KDQoNCg0KDQpWb246IE1hcnkgQmFybmVz
IFttYWlsdG86bWFyeS5pZXRmLmJhcm5lc0BnbWFpbC5jb208bWFpbHRvOm1hcnkuaWV0Zi5iYXJu
ZXNAZ21haWwuY29tPl0NCkdlc2VuZGV0OiBNb250YWcsIDI1LiBOb3ZlbWJlciAyMDEzIDIzOjAx
DQoNCkFuOiBKZXNza2UsIFJvbGFuZA0KQ2M6IERJU1BBVENIOyBHb256YWxvIENhbWFyaWxsbzsg
QXRsZSBNb25yYWQ7IERlYW4gV2lsbGlzDQpCZXRyZWZmOiBSZTogUFJPVE8gUmV2aWV3OiBkcmFm
dC1kcmFnZS1zaXBwaW5nLXJmYzM0NTViaXMtMDkudHh0DQoNCkhpIFJvbGFuZCwNCg0KVGhhbmtz
IGZvciB5b3VyIHJlc3BvbnNlLiAgQWRkaXRpb25hbCBjb21tZW50cyBiZWxvdyBbTUJdLg0KDQpU
aGFua3MsDQpNYXJ5Lg0KDQpPbiBUaHUsIE5vdiAyMSwgMjAxMyBhdCA3OjIxIEFNLCA8Ui5KZXNz
a2VAdGVsZWtvbS5kZTxtYWlsdG86Ui5KZXNza2VAdGVsZWtvbS5kZT4+IHdyb3RlOg0KSGkgTWFy
eSwNClRoYW5rIHlvdSBmb3IgeW91ciByZXZpZXcuDQpJIGhhdmUgYWRkZWQgbm93IHlvdXIgcHJv
cG9zYWxzIHRvIHRoZSBkcmFmdC4NCk90aGVyIGNvbW1lbnRzIHBsZWFzZSBzZWUgYmVsb3cuDQoN
CkkgaG9wZSBub3cgZXZlcnl0aGluZyBpcyBPSy4NCg0KVGhhbmsgeW91IGFuZCBCZXN0IFJlZ2Fy
ZHMNCg0KUm9sYW5kDQoNClZvbjogTWFyeSBCYXJuZXMgW21haWx0bzptYXJ5LmlldGYuYmFybmVz
QGdtYWlsLmNvbTxtYWlsdG86bWFyeS5pZXRmLmJhcm5lc0BnbWFpbC5jb20+XQ0KR2VzZW5kZXQ6
IERpZW5zdGFnLCAyOS4gT2t0b2JlciAyMDEzIDE3OjI3DQpBbjogSmVzc2tlLCBSb2xhbmQNCkNj
OiBESVNQQVRDSDsgR29uemFsbyBDYW1hcmlsbG87IEF0bGUgTW9ucmFkOyBEZWFuIFdpbGxpcw0K
QmV0cmVmZjogUFJPVE8gUmV2aWV3OiBkcmFmdC1kcmFnZS1zaXBwaW5nLXJmYzM0NTViaXMtMDku
dHh0DQoNCkluIHByZXBhcmF0aW9uIGZvciB0aGUgUFJPVE8gd3JpdGUtdXAsIEkgaGF2ZSByZXZp
ZXdlZCB0aGUgZG9jdW1lbnQgaW4gZGV0YWlsLiAgTXkgZGV0YWlsZWQgcmV2aWV3IHdhcyBvcmln
aW5hbGx5IGJhc2VkIG9uIHRoZSAtMDgsIGJ1dCBJIGFsc28gcmV2aWV3ZWQgdGhlIDA5IGRpZmYu
ICBUaGVyZSBhcmUgYSBmZXcgZXJyb3JzIHRoYXQgaGF2ZSBiZWVuIGludHJvZHVjZWQgaW4gdGhl
IC0wOSBhbmQgbWFueSBvZiBteSAtMDggY29tbWVudHMgcmVtYWluIC0gSSd2ZSBzZXBhcmF0ZWQg
Y29tbWVudHMgZnJvbSBuaXRzIGJlbG93LiAgQSBudW1iZXIgb2YgdGhlc2UgY29tbWVudHMgYXJl
IHdpdGggcmVnYXJkcyB0byB0ZXh0IHRoYXQgd2FzIG5vdCBjaGFuZ2VkIGZyb20gUkZDIDM0NTUs
IGJ1dCBJIHRoaW5rIHNvbWUgb2YgdGhlIHRleHQgcmVxdWlyZXMgdXBkYXRpbmcgYW5kIHdlIG5l
ZWQgdG8ga2VlcCBpbiBtaW5kIHRoYXQgdGhpcyBhbiBlbnRpcmVseSBuZXcgSUVTRyB0aGF0IHdp
bGwgYmUgcmV2aWV3aW5nIHRoaXMgZG9jdW1lbnQsIHNvIHRoZXkgd29uJ3QgaGF2ZSB0aGUgc2Ft
ZSBjb250ZXh0IG9mIHRoZSBJRVNHIHRoYXQgYXBwcm92ZWQgUkZDIDM0NTUuICBJIHdpbGwgbm90
ZSB0aGF0IEkgYWxzbyBoYXZlIG5vdCB2YWxpZGF0ZWQgdGhlIGNvbnRlbnQgb2Ygc2VjdGlvbiA5
IGFnYWluc3QgYSBkaWZmIG9mIHRoaXMgZG9jdW1lbnQgYW5kIFJGQyAzNDU1LiAgSSB3aWxsIG5l
ZWQgdG8gZG8gdGhhdCBiZWZvcmUgSSBwcm9ncmVzcyB0aGUgZG9jdW1lbnQgdW5sZXNzIHRoZSBh
dXRob3JzIGNhbiBwb2ludCBtZSB0byBhbm90aGVyIHJldmlldyB0aGF0IGhhcyBkb25lIHRoYXQu
DQoNClJlZ2FyZHMsDQpNYXJ5Lg0KDQpTdW1tYXJ5OiAgVGhpcyBkb2N1bWVudCBuZWVkcyBzb21l
IHdvcmsgcHJpb3IgdG8gYmVpbmcgcHJvZ3Jlc3NlZC4NCg0KQ29tbWVudHM6DQotLS0tLS0tLS0t
LS0tLS0tDQotIFNlY3Rpb24gMS4gIEkgdGhpbmsgeW91IHNob3VsZCBiZSBleHBsaWNpdCB0aGF0
IHRoZXNlIGV4dGVuc2lvbnMgYXBwbHkgb25seSB0byBhIHByaXZhdGUgbmV0d29yayAtIHNheWlu
ZyB0aGV5IGFyZSAiZ2VuZXJhbGx5IG5vdCBhcHBsaWNhYmxlIiBpcyB0b28gc29mdCwgc28gSSB3
b3VsZCBzdWdnZXN0IHNvbWUgbWlub3IgcmV3b3JkaW5nIHNvbWV0aGluZyBsaWtlOg0KT0xEOg0K
DQogICBUaGUgU0lQIGV4dGVuc2lvbnMgc3BlY2lmaWVkIGluIHRoaXMgZG9jdW1lbnQgbWFrZSBj
ZXJ0YWluDQoNCg0KDQogICBhc3N1bXB0aW9ucyByZWdhcmRpbmcgbmV0d29yayB0b3BvbG9neSwg
bGlua2FnZSBiZXR3ZWVuIFNJUCBhbmQgbG93ZXINCg0KICAgbGF5ZXJzLCBhbmQgdGhlIGF2YWls
YWJpbGl0eSBvZiB0cmFuc2l0aXZlIHRydXN0LiAgVGhlc2UgYXNzdW1wdGlvbnMNCg0KICAgYXJl
IGdlbmVyYWxseSBOT1QgQVBQTElDQUJMRSBpbiB0aGUgSW50ZXJuZXQgYXMgYSB3aG9sZS4NCg0K
DQpORVc6DQoNCg0KDQogICBUaGUgU0lQIGV4dGVuc2lvbnMgc3BlY2lmaWVkIGluIHRoaXMgZG9j
dW1lbnQgbWFrZSBjZXJ0YWluDQoNCiAgIGFzc3VtcHRpb25zIHJlZ2FyZGluZyBuZXR3b3JrIHRv
cG9sb2d5LCBsaW5rYWdlIGJldHdlZW4gU0lQIGFuZCBsb3dlcg0KDQogICBsYXllcnMsIGFuZCB0
aGUgYXZhaWxhYmlsaXR5IG9mIHRyYW5zaXRpdmUgdHJ1c3QuICBUaGVzZSBhc3N1bXB0aW9ucw0K
DQogICBhcHBseSBvbmx5IHRvIHByaXZhdGUgbmV0d29ya3MgYW5kIGFyZSBub3QgYXBwcm9wcmlh
dGUgZm9yIHVzZSBpbiBhbiBJbnRlcm5ldCBlbnZpcm9ubWVudC4NCg0KDQoNCg0KDQoNCg0KDQoN
Cg0KLSBTZWN0aW9uIDMuICBUaGlzIHNlY3Rpb24gbmVlZHMgdG8gYmUgdXBkYXRlZC4gIEkgZG9u
J3QgdGhpbmsgdGhhdCAxMCB5ZWFyIG9sZCBiYWNrZ3JvdW5kIGlzIHJlbGV2YW50IGluIHRoZSBj
dXJyZW50IGNvbnRleHQuICAgWW91IHNob3VsZCBiZSBhYmxlIHRvIG1vZGVsIHRoaXMgYWZ0ZXIg
dGhlIHRleHQgaW4gbW9yZSByZWNlbnQgM0dQUCBQLWhlYWRlciBkb2N1bWVudHMsIHJlZmVycmlu
ZyB0byB0aGUgU0lQIGNoYW5nZSBwcm9jZXNzLg0KDQoNCg0KW1JKXSBPSywgSSBoYXZlIGNoYW5n
ZWQgdGhlIHRleHQ6DQpUaGUgVGhpcmQgR2VuZXJhdGlvbiBQYXJ0bmVyc2hpcCBQcm9qZWN0ICgz
R1BQKSBoYXMgc2VsZWN0ZWQgU0lQIGFzDQogICAgIHRoZSBwcm90b2NvbCB1c2VkIHRvIGVzdGFi
bGlzaCBhbmQgdGVhciBkb3duIG11bHRpbWVkaWEgc2Vzc2lvbnMgaW4gdGhlDQogICAgIGNvbnRl
eHQgb2YgaXRzIElQIE11bHRpbWVkaWEgU3Vic3lzdGVtIChJTVMpLiBGb3IgbW9yZSBpbmZvcm1h
dGlvbiBvbg0KICAgICB0aGUgSU1TLCBhIGRldGFpbGVkIGRlc2NyaXB0aW9uIGNhbiBiZSBmb3Vu
ZCBpbiAzR1BQIFRTIDIzLjIyOCAuIFRoaXMgZG9jdW1lbnQgaXMgYW4gdXBkYXRlIG9mIFJGQzM0
NTUgICB3aGljaCBjb3ZlcnMgdGhlIHJlcXVpcmVtZW50cyBpbiBSRkM0MDgzIGFuZCBkZXNjcmli
ZXMgdXBkYXRlcyBhbmQgYWRkcyBwcml2YXRlIGV4dGVuc2lvbnMgdG8gYWRkcmVzcyB0aG9zZSBy
ZXF1aXJlbWVudHMgd2hpY2ggYXJlIG5lZWRlZCBpbiBmb3IgM0dQUCBSZWxlYXNlIDExLiBFYWNo
IGV4dGVuc2lvbiwgb3Igc2V0IG9mIHJlbGF0ZWQgZXh0ZW5zaW9ucyBpcyBkZXNjcmliZWQgaW4g
aXRzIG93biBzZWN0aW9uIGJlbG93DQpbTUJdIEkgc3VnZ2VzdCBqdXN0IGEgYml0IG1vcmUgcmV3
b3JkaW5nLiAgTm90ZSB0aGF0IEkgZGlkbid0IHNlZSB0aGF0IHRoaXMgZG9jdW1lbnQgaXMgYWRk
aW5nIGFueSBuZXcgaGVhZGVycw0KDQogICAgVGhlIFRoaXJkIEdlbmVyYXRpb24gUGFydG5lcnNo
aXAgUHJvamVjdCAoM0dQUCkgdXNlcyBTSVAgYXMNCiAgICAgdGhlIHByb3RvY29sICB0byBlc3Rh
Ymxpc2ggYW5kIHRlYXIgZG93biBtdWx0aW1lZGlhIHNlc3Npb25zIGluIHRoZQ0KICAgICBjb250
ZXh0IG9mIGl0cyBJUCBNdWx0aW1lZGlhIFN1YnN5c3RlbSAoSU1TKSwgYXMgZGVzY3JpYmVkIGlu
DQogICAgIHRoZSAzR1BQIFRTIDIzLjIyOCBzcGVjaWZpY2F0aW9uLg0KICAgICBSRkMgMzQ1NSBk
ZWZpbmVzIFNJUCBwcml2YXRlIGhlYWRlciBleHRlbnNpb25zIChyZWZlcnJlZCB0byBhcyBQLWhl
YWRlcnMpIHdoaWNoIGFyZQ0KICAgICByZXF1aXJlZCBieSB0aGUgM0dQUCBzcGVjaWZpY2F0aW9u
LiBOb3RlIHRoYXQgdGhlIHJlcXVpcmVtZW50cyBmb3IgdGhlc2UgZXh0ZW5zaW9ucw0KICAgICBh
cmUgZG9jdW1lbnRlZCBpbiBSRkMgNDA4My4gICBUaGlzIGRvY3VtZW50IGlzIGFuIHVwZGF0ZSB0
byBSRkMzNDU1Lg0KICAgICBUaGlzIGRvY3VtZW50IHVwZGF0ZXMgZXhpc3RpbmcgUC1oZWFkZXIg
ZGVzY3JpcHRpb25zDQogICAgIHRvIGFkZHJlc3MgYWRkaXRpb25hbCByZXF1aXJlbWVudHMgd2hp
Y2ggYXJlIG5lZWRlZCBmb3IgM0dQUCBSZWxlYXNlIDExLg0KICAgICBFYWNoIG9mIHRoZSBQLWhl
YWRlcnMgaXMgZGVzY3JpYmVkIGluIHRoZSBzZWN0aW9ucyBiZWxvdy4NCg0KWy9NQl0NCg0KDQot
IFNlY3Rpb24gNC4xLiAicmVnaXN0ZXJlZCBhZGRyZXNzLW9mLXJlY29yZCIgLT4gInJlZ2lzdGVy
ZWQgU0lQIGFkZHJlc3Mtb2YtcmVjb3JkIg0KDQotIFNlY3Rpb24gNC4xLCAzcmQgcGFyYWdyYXBo
LiAgIk5vdGUgdGhhdCwgZ2VuZXJhbGx5IHNwZWFraW5nLCIgLT4gIk5vdGUgdGhhdCBpbiBzdGFu
ZGFyZCBTSVAgdXNhZ2UgW1JGQzMyNjFdIg0KDQotIFNlY3Rpb24gNC4xLjIuMy4gIEkgZG9uJ3Qg
dGhpbmsgdGhpcyBpcyBzdGF0ZWQgcHJvcGVybHkuICBJIHRoaW5rIHRoZSBpbnRlbnQgaXMgdGhh
dCB0aGlzIGhlYWRlciBpcyBub3QgYXBwbGljYWJsZSB0byBwcm94aWVzLCB0aGVyZWZvcmUgdGhl
IHByb3h5IE1VU1QgcmVsYXkgdGhlIGhlYWRlciBmaWVsZCB1bmNoYW5nZWQuICBJIHdvdWxkIHN1
Z2dlc3QgcmV3b3JkaW5nIHNvbWV0aGluZyBsaWtlOg0KDQpPTEQ6DQoNCiAgIFRoaXMgbWVtbyBk
b2VzIG5vdCBkZWZpbmUgYW55IHByb2NlZHVyZSBhdCB0aGUgcHJveHkuICBUaGUgcHJveHkgZG9l
cw0KDQogICBub3QgYWRkLCByZWFkLCBtb2RpZnkgb3IgZGVsZXRlIHRoZSBoZWFkZXIgZmllbGQs
IGFuZCB0aGVyZWZvcmUgYW55DQoNCiAgIHByb3h5IHdpbGwgcmVsYXkgdGhpcyBoZWFkZXIgZmll
bGQgdW5jaGFuZ2VkLg0KDQoNCg0KTkVXOg0KDQoNCg0KICAgVGhpcyBoZWFkZXIgaXMgbm90IGlu
dGVuZGVkIHRvIGJlIHVzZWQgYnkgcHJveGllcyAtIGEgcHJveHkgZG9lcw0KDQogICBub3QgYWRk
LCByZWFkLCBtb2RpZnkgb3IgZGVsZXRlIHRoZSBoZWFkZXIgZmllbGQsIGFuZCB0aGVyZWZvcmUg
YW55DQoNCiAgIHByb3h5IE1VU1QgcmVsYXkgdGhpcyBoZWFkZXIgZmllbGQgdW5jaGFuZ2VkLg0K
DQoNCg0KDQoNCg0KDQoNCg0KDQpTZWN0aW9uIDQuMiwgMXN0IHBhcmFncmFwaC4gIFRoZSBiZWhh
dmlvciBpbiB0aGlzIHNlbnRlbmNlIGlzIG5vdCBub3JtYXRpdmUgZnJvbSBhIFNJUCBwcm90b2Nv
bCBwZXJzcGVjdGl2ZSwgdGh1cyBNQVkgaXMgbm90IGFwcHJvcHJpYXRlLiAgSSBzdWdnZXN0IHRo
ZSBNQVkgYmUgY2hhbmdlZCB0byAiY2FuIi4NCg0KICAgVGhlIFVBUyBNQVkgdXNlIHRoZSBpbmZv
cm1hdGlvbiB0byByZW5kZXIgZGlmZmVyZW50IGRpc3RpbmN0aXZlIGF1ZGlvdmlzdWFsIGFsZXJ0
aW5nDQoNCiAgIHRvbmVzLCBkZXBlbmRpbmcgb24gdGhlIFVSSSB1c2VkIHRvIHJlY2VpdmUgdGhl
IGludml0YXRpb24gdG8gdGhlDQoNCiAgIHNlc3Npb24uDQoNClNlY3Rpb24gNC4yLjIuMiwgMm5k
IHBhcmFncmFwaC4gIFRoZSBiZWhhdmlvciBpbiB0aGlzIHNlbnRlbmNlIGlzIG5vdCBub3JtYXRp
dmUgZnJvbSBhIFNJUCBwcm90b2NvbCBwZXJzcGVjdGl2ZSwgdGh1cyAgSSBzdWdnZXN0IHRoZSBN
QVkgYmUgY2hhbmdlZCB0byAiY2FuIi4NCg0KDQoNCi0gU2VjdGlvbiA0LjMuMywgbGFzdCBwYXJh
Z3JhcGguICBJIHRoaW5rIHRoaXMgb3VnaHQgdG8gYmUgYSBNVVNUOiAiVGhlIGlkZW50aWZpZXIg
c2hvdWxkIGJlIGdsb2JhbGx5IHVuaXF1ZS4uIg0KDQoNCg0KLSBTZWN0aW9uIDQuMy4yLjEuICBU
aGlzIHRleHQgaGFzIGNoYW5nZWQgZnJvbSB0aGUgLTA4LiAgIEkgZG9uJ3Qga25vdyB3aGF0IGEg
Im5vcm1hbCBVc2VyIEVxdWlwbWVudCIgaXMgYW5kIHRoZSB0ZXJtICJVc2VyIEVxdWlwbWVudCIg
aXMgbm90IGRlZmluZWQgaW4gdGhpcyBzcGVjaWZpY2F0aW9uLiAgSSB0aGluayBpdCB3b3VsZCBi
ZSBiZXR0ZXIgdG8gc2F5IHNvbWV0aGluZyBsaWtlLiBIb3dldmVyLCBldmVuIHdpdGggdGhpcyBw
cm9wb3NlZCBjaGFuZ2UsIEkgdGhpbmsgeW91IGFsc28gbmVlZCB0ZXh0IGZvciB1c2VyIGFnZW50
IHNlcnZlciBiZWhhdmlvciAtIGkuZS4sIHdoYXQgd291bGQgYSBVQVMgZG8gaWYgaXQgcmVjZWl2
ZWQgdGhpcyBoZWFkZXIuDQoNCg0KDQpPTEQ6DQoNCiAgIEEgbm9ybWFsIFVzZXIgRXF1aXBtZW50
IGhhcyBub3JtYWxseSBubyBrbm93bGVkZ2Ugb2YgdGhlIFAtVmlzaXRlZC0NCg0KICAgTmV0d29y
ay1JRCB3aGVuIHNlbmRpbmcgdGhlIFJFR0lTVEVSLiAgVGhlcmVmb3JlIHVzZXIgYWdlbnQgY2xp
ZW50cw0KDQogICBkbyBub3QgaW5zZXJ0IGEgUC1WaXNpdGVkLU5ldHdvcmstSUQgaGVhZGVyIGZp
ZWxkIGluIGFueSBTSVAgbWVzc2FnZS4NCg0KDQoNCg0KDQoNCg0KDQpORVc6DQoNCiAgIEluIHRo
ZSBjb250ZXh0IG9mIHRoZSBuZXR3b3JrIHRvIHdoaWNoIHRoZSBoZWFkZXIgZmllbGRzIGRlZmlu
ZWQgaW4gdGhpcyBkb2N1bWVudCBhcHBseSwgYSBVc2VyIEFnZW50IGhhcyBubyBrbm93bGVkZ2Ug
b2YgdGhlIFAtVmlzaXRlZC1OZXR3b3JrLUlEIHdoZW4gc2VuZGluZyB0aGUgUkVHSVNURVIgcmVx
dWVzdC4gIFRoZXJlZm9yZSB1c2VyIGFnZW50IGNsaWVudHMgTVVTVCBOT1QgaW5zZXJ0IGEgUC1W
aXNpdGVkLU5ldHdvcmstSUQgaGVhZGVyIGZpZWxkIGluIGFueSBTSVAgbWVzc2FnZS4NCg0KDQoN
Ci0gU2VjdGlvbiA0LjMuMi4yPGh0dHA6Ly80LjMuMi4yPjosIDJuZCBwYXJhZ3JhcGg6ICAiaG9t
ZSBuZXR3b3JrIE1BWSB1c2UiIC0+ICJob21lIG5ldHdvcmsgY2FuIHVzZSINCg0KDQoNCg0KDQoN
Cg0KDQoNCg0KDQoNCi0gU2VjdGlvbiA0LjMuMi4yLCBsYXN0IHBhcmFncmFwaDoNCg0KDQoNCg0K
DQpPTEQ6IE5vdGUgdGhhdCBhIHJlY2VpdmVkIFAtVmlzaXRlZC1OZXR3b3JrLUlEIGZyb20gYSBV
QSBpcyBhIGZhaWx1cmUgY2FzZSBhbmQgbXVzdCBiZSBkZWxldGVkLg0KDQoNCg0KTkVXOiAgTm90
ZSB0aGF0IGEgcmVjZWl2ZWQgUC1WaXNpdGVkLU5ldHdvcmstSUQgZnJvbSBhIFVBIGlzIGEgZmFp
bHVyZSBjYXNlIGFuZCBNVVNUIGJlIGRlbGV0ZWQgd2hlbiB0aGUgcmVxdWVzdCBpcyBmb3J3YXJk
ZWQuDQoNCg0KDQpTZWN0aW9uIDQuNC4yLjEsIDJuZCBwYXJhZ3JhcGg6ICAiTVVTVCB0cnVzdCB0
aGUgcHJveHkiIC0+ICJNVVNUIGhhdmUgYSB0cnVzdCByZWxhdGlvbnNoaXAgd2l0aCB0aGUgcHJv
eHkiDQoNCg0KDQpTZWN0aW9uIDQuNC4yLjEsIDNyZCBwYXJhZ3JhcGg6ICAidGhlcmUgbXVzdCBh
bHNvIGJlIGEgdHJhbnNpdGl2ZSB0cnVzdCIgLT4gICJ0aGVyZSBNVVNUIGFsc28gYmUgYSB0cmFu
c2l0aXZlIHRydXN0Ig0KDQpTZWN0aW9uIDQuNC4yLjIsIDJuZCBwYXJhZ3JhcGg6ICJNQVkgYWN0
IHVwb24gYW55IGluZm9ybWF0aW9uIHByZXNlbnQiIC0+ICJjYW4gYWN0IHVwb24gYW55IGluZm9y
bWF0aW9uIHByZXNlbnQiLCAgIk1BWSB1c2UgdGhlIGNhbGwgaWQiIC0+ICJjYW4gdXNlIHRoZSBj
YWxsIGlkIg0KDQpTZWN0aW9uIDQuNS4yOiAybmQgcGFyYWdyYXBoOiAiTUFZIHVzZSB0aGUgaG9z
dG5hbWVzIiAtPiAiY2FuIHVzZSB0aGUgaG9zdG5hbWVzIg0KDQoNCg0KDQoNCg0KDQpTZWN0aW9u
IDQuNS4yLjEgMm5kIHBhcmFncmFwaDogIk1BWSB1c2UgdGhlIGNvbnRlbnRzIiAtPiAiY2FuIHVz
ZSB0aGUgY29udGVudHMiDQoNCg0KDQotIFNlY3Rpb24gNC42LjIsIDNyZCBwYXJhZ3JhcGg6ICJN
QVkgdXNlIHRoZSB2YWx1ZXMiIC0+ICJjYW4gdXNlIHRoZSB2YWx1ZXMiDQoNCi0gU2VjdGlvbiA0
LjYuMywgM3JkIHBhcmFncmFwaDogbmVlZHMgc29tZSBlZGl0b3JpYWwgd29yay4gIE1heWJlIHRo
ZSBmb2xsb3dpbmcgY2hhbmdlIHdvdWxkIHdvcms6DQoNCg0KDQoNCg0KT0xEOg0KDQoNCg0KDQog
ICBEZXBlbmRpbmcgb24gdGhlIGNhbGwgc2NlbmFyaW8gaXQgaXMgbmVlZGVkIHRvIGFkZCBmb3Ig
ZWFjaCB0cmFuc2l0DQoNCiAgIG5ldHdvcmsgZWl0aGVyIGEgdHJhbnNpdCBuZXR3b3JrIG5hbWUg
b3IgYSB2b2lkIHZhbHVlLiAgTmV2ZXJ0aGVsZXNzDQoNCiAgIGl0IGNhbiBub3QgYmUgZ3VhcmFu
dGVlZCB0aGF0IGFsbCB2YWx1ZXMgd2lsbCBhcHBlYXIgd2l0aGluIHRoZSBQLUNoYXJnaW5nLVZl
Y3RvciBoZWFkZXIgZmllbGQuDQoNCg0KDQoNCg0KTkVXOg0KDQoNCg0KICAgRGVwZW5kaW5nIG9u
IHRoZSBjYWxsIHNjZW5hcmlvLCBlYWNoIHRyYW5zaXQgbmV0d29yayBjYW4gYWRkIGVpdGhlciBh
IHRyYW5zaXQgbmV0d29yayBuYW1lIG9yIGEgdm9pZCAgICB2YWx1ZS4gIEhvd2V2ZXIsIGl0IGNh
biBub3QgYmUgZ3VhcmFudGVlZCB0aGF0IGFsbCB0aGUgdmFsdWVzIHRoYXQgYXJlIGFkZGVkIHdp
bGwgYXBwZWFyIHdpdGhpbiB0aGUgUC1DaGFyZ2luZy1WZWN0b3IgaGVhZGVyIGZpZWxkLg0KDQoN
Cg0KLSBTZWN0aW9uIDQuNi4zLCBuZXh0IHRvIGxhc3QgcGFyYWdyYXBoOiAid2hpY2ggbmVlZHMg
dG8gYmUgaW5jcmVtZW50ZWQiIC0+ICJ3aGljaCBNVVNUIGJlIGluY3JlbWVudGVkIg0KDQoNCg0K
LSBTZWN0aW9uIDQuNi4zLCBsYXN0IHBhcmFncmFwaC4gIEkgaGF2ZSBubyBpZGVhIHdoYXQgdGhh
dCBpcyB0cnlpbmcgdG8gc2F5IG90aGVyIHRoYW4gdm9pZCB2YWx1ZXMgaGF2ZSBubyBpbmRleC4g
IFdoYXQgZG9lcyAidGFrZW4gaW50byBjb25zaWRlcmF0aW9uIiBtZWFuLiBBcmUgeW91IHRhbGtp
bmcgYWJvdXQgbGltaXRzIG9uIHRoZSBudW1iZXIgb2YgZW50cmllcyBvciBhcmUgeW91IHN1Z2dl
c3RpbmcgdGhhdCB0aGUgbnVtYmVyIG9mIHZvaWQgdmFsdWVzIG11c3QgYmUgY29uc2lkZXJlZCB3
aGVuIHNldHRpbmcgdGhlIGluZGV4IGZvciB0aGUgdHJhbnNpdCBuZXR3b3JrIG5hbWVzPw0KDQoN
Cg0KW1JKXSBZZXMhIENoYW5nZWQgdGhlIHRleHQgdG86DQoNCg0KDQpBIHZvaWQgdmFsdWUgaGFz
IG5vIGluZGV4LiBCeSBhZGRpbmcgdGhlIG5leHQgdmFsdWUgdGhlIGluZGV4IGhhcyB0byBiZSBp
bmNyZW1lbnRlZCBieSB0aGUgbnVtYmVyIG9mIHZvaWQgZW50cmllcyArMS4NCg0KDQoNCi0gU2Vj
dGlvbiA0LjYuNC4yPGh0dHA6Ly80LjYuNC4yPjogSSBkb24ndCBrbm93IHdoYXQgdGhpcyBtZWFu
czogICJBIGRlbGV0aW9uIG9mIHRoZSBlbGVtZW50cyBjb3VsZCBhcHBlYXIgZGVwZW5kaW5nIG9u
IHRoZSBuZXR3b3JrIHBvbGljeSBhbmQgdHJ1c3QgcnVsZXMiLiAgSXMgaXQganVzdCB0cnlpbmcg
dG8gc2F5IHRoYXQgYWxvbmcgd2l0aCB0aGUgYWRkaW5nIGFuZCBtb2RpZnlpbmcgaW4gdGhlIHBy
ZXZpb3VzIHNlbnRlbmNlIHRoYXQgdGhlIGVsZW1lbnRzIGNhbiBhbHNvIGJlIGRlbGV0ZWQgYnkg
dGhlIHByb3h5Pw0KDQoNCg0KW1JKXSBZZXMsIEkgaGF2ZSBjaGFuZ2VkIHRoZSB0ZXh0Og0KUHJv
Y2VkdXJlcyBkZXNjcmliZWQgd2l0aGluIDQuNi4yLjIgYXBwbHkuIEEgdHJhbnNpdC1pb2kgTUFZ
IGJlDQogICAgICAgICAgIGFkZGVkIG9yIG1vZGlmaWVkIGJ5IGEgcHJveHkuIEEgZGVsZXRpb24g
b2YgdGhlIHRyYW5zaXQtaW9pIG9yIGEgZW50cnkgd2l0aGluIHRoZSB0cmFuaXN0LWlvaSBjb3Vs
ZA0KICAgICAgICAgICBhcHBlYXIgZGVwZW5kaW5nIG9uIHRoZSBuZXR3b3JrIHBvbGljeSBhbmQg
dHJ1c3QgcnVsZXMuIFRoaXMgaXMNCg0KICAgICAgICAgICBhbHNvIHZhbGlkIGJ5IHJlcGxhY2lu
ZyB0aGUgdHJhbnNpdC1pb2kgd2l0aCBhIHZvaWQgdmFsdWUuDQoNCg0KDQoNCg0KDQoNCg0KDQoN
Cg0KDQoNCg0KLSBTZWN0aW9uIDUuNy4gRGVsZXRlIHRoaXMgdGV4dCBhbmQgdGFibGUuICAgV2Ug
YXJlbid0IHRoZXNlIHRhYmxlcyBhbnltb3JlIGFzIHRoZXkgcmVhbGx5IGRvbid0IHByb3ZpZGUg
YW55IHVzZWZ1bCBpbmZvcm1hdGlvbi4gIFlvdSBqdXN0IG5lZWQgdG8gdmVyYmFsbHkgc3RhdGUg
d2hhdCBtZXNzYWdlcyB0aGVzZSBoZWFkZXJzIGNhbiBhcHBlYXIgaW4uDQoNCg0KDQpbUkpdIE9L
DQoNCg0KDQpTbyBJIGNoYW5nZWQgNS43IHRvIOKAnE5ldyBoZWFkZXLigJ0NClRoZSBQLUFzc29j
aWF0ZWQtVVJJIGNhbiBhcHBlYXIgaW4gU0lQIFJFR0lTVEVSIG1ldGhvZCBhbmQgMnh4IHJlc29u
c2VzLCBQLUNhbGxlZC1QYXJ0eS1JRCBjYW4gYXBwZWFyIGluIFNJUCBJTlZJVEUsIE9QVElPTlMs
IFBVQkxJU0gsU1VCU0NSSUJFLCBNRVNTQUdFIG1ldGhvZHMgYW5kIGFsbCByZXNwb25zZXMsIFAt
VmlzaXRlZC1OZXR3b3JrLUlEIGNhbiBhcHBlYXIgaW4gYWxsIFNJUCBtZXRob2RzIGV4Y2VwdCBB
Q0ssIEJZRSBhbmQgQ0FOQ0VMIGFuZCBhbGwgcmVzcG9uc2VzLCBQLUFjY2Vzcy1OZXR3b3JrLUlu
Zm8gY2FuIGFwcGVhciBpbiBhbGwgU0lQIG1ldGhvZHMgZXhlcHQgQUNLIGFuZCBDQU5DRUwsIFAt
Q2hhcmdpbmctVmVjdG9yICBjYW4gYXBwZWFyIGluIGFsbCBTSVAgbWV0aG9kcyBleGVwdCBDQU5D
RUwgYW5kIHRoZSBQLUNoYXJnaW5nLUZ1bmN0aW9uLUFkZHJlc3NlcyBjYW4gYXBwZWFyIGluIGFs
bCBTSVAgbWV0aG9kcyBleGVwdCBBQ0sgYW5kIENBTkNFTC4NCltNQl0gSSBzdWdnZXN0IHlvdSBw
dXQgZWFjaCBvZiB0aGVzZSBpbiBzZXBhcmF0ZSBzZW50ZW5jZXMgLSBpLmUuLCByYXRoZXIgdGhh
biB1c2UgY29tbWEgc2VwYXJhdG9ycywgdXNlIGEgcGVyaW9kLiAgWW91IHNob3VsZCBhbHNvIHNw
ZWxsIG91dCB0aGF0IHRoZXNlIGFyZSBoZWFkZXIgZmllbGRzIC0gaS5lLiwgIlRoZSBQLUFzc29j
aWF0ZWQtVVJJIGhlYWRlciBmaWVsZCBjYW4gYXBwZWFyLi4uLjJ4eCByZXNwb25zZXMuICAgVGhl
IFAtQ2FsbGVkLVBhcnR5LUlEIGhlYWRlciBmaWVsZC4uLi4NCg0KDQoNCg0KDQotIFNlY3Rpb24g
Ni4xOiB0aGlzIG5lZWRzIHNvbWUgdGlnaHRlciB3b3JkaW5nLiAgV2hhdCBpcyBtZWFudCBieSAi
cG90ZW50aWFsbHkgYW5ub3lpbmciICBmb3IgZXhhbXBsZT8NCg0KDQoNCltSSl0gSSBkbyBub3Qg
a25vdy4gVGhpcyBpcyBvcmlnaW5hbCB0ZXh0LiBTbyBJIGRlbGV0ZWQgdGhlIHdvcmRzLg0KDQoN
Cg0KLSBTZWN0aW9uIDYuMjogSSB0aGluayB5b3UgbmVlZCB0byBiZSBtb3JlIHNwZWNpZmljIGFi
b3V0IHRoZSAibmF0dXJlIiB0aGF0IG1ha2VzIHRoaXMgaGVhZGVyIG5vdCBvZiBwYXJ0aWN1bGFy
IGNvbmNlcm4gd2l0aCByZWdhcmRzIHRvIHNlY3VyaXR5LiBEb2VzIGl0IHJldmVhbCBhZGRpdGlv
bmFsLCB1bmlxdWUgaW5mb3JtYXRpb24gYWJvdXQgYW4gaW5kaXZpZHVhbCB0aGF0IGlzbid0IGF2
YWlsYWJsZSBpbiBvdGhlciBoZWFkZXJzLiAgQWxzbywgdGhlIDJuZCBwYXJhZ3JhcGggbmVlZHMg
c29tZSB3b3JrIC0gbWF5YmUgc29tZXRoaW5nIGxpa2U6DQoNCg0KDQpPTEQ6DQoNCkFuIGVhdmVz
ZHJvcHBlciBtYXkgY29sbGVjdCB0aGUgbGlzdCBvZiBpZGVudGl0aWVzIGEgdXNlciBpcyByZWdp
c3RlcmVkLiAgVGhpcyBtYXkgaGF2ZSBwcml2YWN5IGltcGxpY2F0aW9ucy4gIFRvIG1pdGlnYXRl
IHRoaXMgcHJvYmxlbSwgdGhpcyBleHRlbnNpb24gU0hPVUxEIG9ubHkgYmUgdXNlZCBpbiBhIHNl
Y3VyZWQgZW52aXJvbm1lbnQsIHdoZXJlIGVuY3J5cHRpb24gb2YgU0lQIG1lc3NhZ2VzIGlzIHBy
b3ZpZGVkIGVpdGhlciBlbmQtdG8tZW5kIG9yDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpob3At
YnktaG9wLg0KDQoNCg0KDQoNCk5FVzoNCg0KDQoNCiBBbiBlYXZlc2Ryb3BwZXIgY291bGQgcG9z
c2libHkgY29sbGVjdCB0aGUgbGlzdCBvZiBpZGVudGl0aWVzIGEgdXNlciBpcyByZWdpc3RlcmVk
LiAgVGhpcyBjYW4gaGF2ZSBwcml2YWN5IGltcGxpY2F0aW9ucy4gIFRvIG1pdGlnYXRlIHRoaXMg
cHJvYmxlbSwgdGhpcyBleHRlbnNpb24gTVVTVCBvbmx5IGJlIHVzZWQgaW4gYSBzZWN1cmVkIGVu
dmlyb25tZW50LCB3aGVyZSBlbmNyeXB0aW9uIG9mIFNJUCBtZXNzYWdlcyBpcyBwcm92aWRlZCBl
aXRoZXIgZW5kLXRvLWVuZCBvciBob3AtYnktaG9wLg0KDQpbTUJdICBTbywgSSB0aGluayB0aGUg
Zmlyc3Qgc2VudGVuY2UgaXMgdHJ5aW5nIHRvIHNheTogIkFuIGVhdmVzZHJvcHBlciBjb3VsZCBw
b3NzaWJseSBjb2xsZWN0IHRoZSBsaXN0IG9mIGlkZW50aXRpZXMgYSB1c2VyIGhhcyByZWdpc3Rl
cmVkLiINCm9yICAiQW4gZWF2ZXNkcm9wcGVyIGNvdWxkIHBvc3NpYmx5IGNvbGxlY3QgdGhlIGxp
c3Qgb2YgaWRlbnRpdGllcyByZWdpc3RlcmVkIGJ5IGEgdXNlci4iDQpbL01CXQ0KDQotIFNlY3Rp
b24gNi40LA0KDQotLTNyZCBwYXJhZ3JhcGg6ICJzaG91bGQgbm90IiAtPiAiTVVTVCBOT1QiDQoN
Cg0KDQotLSA3dGggcGFyYWdyYXBoOiAgIlNIT1VMRCBOT1QgYmUgc2VudCIgLT4gIk1VU1QgTk9U
IGJlIHNlbnQiDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQotLSA4dGggcGFyYWdyYXBoOiAiU0hP
VUxEIE5PVCBzZW5kIHNlbnNpdGl2ZSBpbmZvcm1hdGlvbiIgLT4gIk1VU1QgTk9UIHNlbmQgc2Vu
c2l0aXZlIGluZm9ybWF0aW9uIg0KDQoNCg0KDQoNCi0tIDl0aCBwYXJhZ3JhcGg6ICJpcyByZXF1
aXJlZCB0byBkZWxldGUiIC0+ICJpcyBSRVFVSVJFRCB0byBkZWxldGUiDQoNCg0KDQotLSAxMHRo
IHBhcmFncmFwaDogIEhvdyBkb2VzIGEgbmV0d29yayBlbnN1cmUgdGhlIGluZm9ybWF0aW9uIGlz
IG5vdCBvZiBhIHNlbnNpdGl2ZSBuYXR1cmU/ICAgSSB3b3VsZCB0aGluayB0aGF0IHRoZSBpbmZv
cm1hdGlvbiBqdXN0IHNob3VsZCBub3QgYmUgc2VudCBvdXRzaWRlIG9mIHRoZSB0cnVzdCBkb21h
aW4uICBJIGJlbGlldmUgdGhhdCdzIGNvbnNpc3RlbnQgd2l0aCB0aGUgc2NvcGUgb2YgdGhlc2Ug
aGVhZGVycywgaXMgaXQgbm90Pw0KDQoNCg0KW1JKXSBZZXMgdGhhdCBpcyBhbHNvIG15IHVuZGVy
c3RhbmRpbmcgc28gSSBkZWxldGVkIHRoYXQgcGFyYWdyYXBoLiBJIHRoaW5rIHRoZSByZXN0IGlz
IHN1ZmZpY2llbnQgYW5kIGRlc2NyaWJlZCB3ZWxsIGhvdyB0byBiZWhhdmUuDQoNCg0KDQotLSAx
MXRoIHBhcmFncmFwaDogU28sIHdoYXQgZG9lcyBhIHByb3h5IGRvIHdpdGggdGhhdCBpbmZvcm1h
dGlvbi4gIFdoYXQgYXJlIHRoZSBpbXBsaWNhdGlvbnMgaWYgdGhlIGluZm9ybWF0aW9uIGlzIHVz
ZWQgYW5kIGl0J3Mgbm90IHZhbGlkPw0KDQpbUkpdIFllcyBJIGRpZCBzb21lIGNoYW5nZXMgYXMg
Zm9sbG93cy4NCg0KDQogICAgICAgIDx0PkEgcHJveHkgcmVjZWl2aW5nIGEgbWVzc2FnZSBjb250
YWluaW5nIHRoZSBQLUFjY2Vzcy1OZXR3b3JrLUluZm8NCiAgICAgICBoZWFkZXIgZmllbGQgZnJv
bSBhIG5vbi10cnVzdGVkIGVudGl0eSBpcyBub3QgYWJsZSB0byBndWFyYW50ZWUgdGhlDQoNCiAg
ICAgICB2YWxpZGl0eSBvZiB0aGUgY29udGVudHMuIFRodXMgdGhpcyBjb250ZW50IFNIT1VMRCBi
ZSBkZWxldGVkIGJhc2VkIG9uIGxvY2FsIHBvbGljeS48L3Q+DQoNCg0KDQotIFNlY3Rpb24gOSwg
aXRlbSAyLiAgSSB0aGluayB5b3UgbmVlZCB0byBhZGQgdGhpcyB0ZXh0IHdpdGggcmVnYXJkcyB0
byB0aGUgcmVjb21tZW5kYXRpb24gdG8gdXNlIFJGQyA0MjQ0IChiaXMpIHRvIHRoZSBib2R5IG9m
IHRoaXMgZG9jdW1lbnQgYW5kIGluY2x1ZGUgYSByZWFsIHJlZmVyZW5jZS4NCg0KDQoNCltSSl0g
T0sgZG9uZS4gSSBsZXQgdGhlIHJlZmVyZW5jZSBSRkM0MjQ0IHNpbmNlIDNHUFAgdXNlcyBjdXJy
ZW50bHkgb25seSBSRkM0MjQ0Lg0KDQpSZXBsYWNlZCBmb2xsb3dpbmcgdGV4dDoNCg0KV2l0aCBz
ZWN0aW9uIDkuMg0KDQogICAgICAgPHQ+UmVxdWlyZW1lbnRzIGZvciBhIG1vcmUgZ2VuZXJhbCBz
b2x1dGlvbiBhcmUgcHJvcG9zZWQgaW4gPHhyZWYNCg0KICAgICAgICAgdGFyZ2V0PSJSRkM0MjQ0
Ij48L3hyZWY+LiAzR1BQIHdpbGwgY29udGludWUgdG8gdXNlIHRoZQ0KDQogICAgICAgICBQLUNh
bGxlZC1QYXJ0eS1JRCBoZWFkZXIgZmllbGQgZXZlbiB0aG91Z2ggUkZDIDQyNDQgPHhyZWYNCg0K
ICAgICAgICAgdGFyZ2V0PSJSRkM0MjQ0Ij48L3hyZWY+IGhhcyBub3cgYmVlbiBwdWJsaXNoZWQu
PC90Pg0KDQoNCg0KSSB0aGluayB0aGUgdGV4dCBpbiBTZWN0aW9uIDkuMiBpcyBiZXR0ZXIuDQoN
Ck5pdHM6DQoNCg0KDQoNCg0KDQoNCg0KDQoNCi0gU2VjdGlvbiA0LjEsIDJuZCBwYXJhZ3JhcGgu
ICAiaGFzIGFzc29jaWF0ZWQgdG8gYW4gYWRkcmVzcy1vZi1yZWNvcmQiIC0+ICJoYXMgYXNzb2Np
YXRlZCB3aXRoIGFuIGFkZHJlc3Mtb2YtcmVjb3JkIg0KDQotIFNlY3Rpb24gNC4xLjIuMiwgMm5k
IHBhcmFncmFwaCwgIkluIGNhc2UiIC0+ICJJZiIsICAic2hhbGwgbm90IiAtPiBTSEFMTCBOT1QN
Cg0KLSBTZWN0aW9uIDQuMy4yLjIsIGxhc3Qgc2VudGVuY2UuICBUaGUgLTA5IGludHJvZHVjZWQg
YSB0eXBvOiAiVCBtZWFucyIgLT4gIlRoaXMgbWVhbnMiDQoNCg0KDQotIFNlY3Rpb24gNC4zLjIu
MywgMXN0IHBhcmFncmFwaCBhZnRlciAxc3QgZXhhbXBsZS4gIFRoZSAtMDkgaW50cm9kdWNlZCBh
bm90aGVyIHR5cG86ICJ0aGUgUkVHSVNUUkFSIiAtPiAiYXQgdGhlIFJFR0lTVFJBUiINCg0KDQoN
ClNlY3Rpb24gNC4yLjIuMSwgM3JkIHBhcmFncmFwaDogICJ0aGVyZSBtdXN0IGFsc28gYmUgYSB0
cmFuc2l0aXZlIHRydXN0IiAtPiAgInRoZXJlIE1VU1QgYWxzbyBiZSBhIHRyYW5zaXRpdmUgdHJ1
c3QiDQoNCg0KDQpTZWN0aW9uIDQuNiwgMm5kIHBhcmFncmFwaDogImluY2x1ZGVzLCBpbmNsdWRl
cyBidXQgaXMgbm90IGxpbWl0ZWQgdG8iIC0+ICJpbmNsdWRlcywgYnV0IGlzIG5vdCBsaW1pdGVk
IHRvLCINCg0KDQoNClNlY3Rpb24gNC42LjIuMiwgMXN0IHBhcmFncmFwaDogIm9uZSBvcmUgbW9y
ZSIgLT4gIm9uZSBvciBtb3JlIg0KDQoNCg0KDQoNCg0KT24gVHVlLCBPY3QgOCwgMjAxMyBhdCAx
MTo1OCBBTSwgPFIuSmVzc2tlQHRlbGVrb20uZGU8bWFpbHRvOlIuSmVzc2tlQHRlbGVrb20uZGU+
PiB3cm90ZToNCkRlYXIgYWxsLA0KSSB3b3VsZCBsaWtlIHRvIGluZm9ybSB5b3UgdGhhdCBJIGhh
dmUgaW1wbGVtZW50ZWQgYWxsIGNvbW1lbnRzIGNvbWluZyBmcm9tIHRoZSBleHBlcnQgcmV2aWV3
IGRvbmUgYnkgRGVhbiBXaWxsaXMuIEFsc28gYW4gZWRpdG9yaWFsIGNsZWFudXAgd2FzIG1hZGUu
DQoNCklmIHRoZXJlIGFyZSBzdGlsbCBzb21lIGNvbW1lbnRzIHRoYXQgbmVlZHMgdG8gYmUgaW1w
bGVtZW50ZWQgcGxlYXNlIGluZm9ybSBtZS4NCg0KRnJvbSBteSBzaWRlIEkgd291bGQgYmUgaGFw
cHkgdG8gcHJvY2VlZCB0aGUgZHJhZnQgZnVydGhlciB0b3dhcmRzIHB1YmxpY2F0aW9uLg0KDQpU
aGFuayB5b3UgYW5kIEJlc3QgUmVnYXJkcw0KDQpSb2xhbmQNCg0KDQotLS0tLVVyc3Byw7xuZ2xp
Y2hlIE5hY2hyaWNodC0tLS0tDQpWb246IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzxtYWlsdG86
aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPiBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9y
ZzxtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPl0NCkdlc2VuZGV0OiBEaWVuc3RhZywg
OC4gT2t0b2JlciAyMDEzIDEzOjQwDQpBbjogQ2hyaXN0ZXIgSG9sbWJlcmc7IEtlaXRoIERyYWdl
OyBKZXNza2UsIFJvbGFuZA0KQmV0cmVmZjogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBk
cmFmdC1kcmFnZS1zaXBwaW5nLXJmYzM0NTViaXMtMDkudHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBv
ZiBJLUQsIGRyYWZ0LWRyYWdlLXNpcHBpbmctcmZjMzQ1NWJpcy0wOS50eHQNCmhhcyBiZWVuIHN1
Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgS2VpdGggRHJhZ2UgYW5kIHBvc3RlZCB0byB0aGUgSUVU
RiByZXBvc2l0b3J5Lg0KDQpGaWxlbmFtZTogICAgICAgIGRyYWZ0LWRyYWdlLXNpcHBpbmctcmZj
MzQ1NWJpcw0KUmV2aXNpb246ICAgICAgICAwOQ0KVGl0bGU6ICAgICAgICAgICBQcml2YXRlIEhl
YWRlciAoUC1IZWFkZXIpIEV4dGVuc2lvbnMgdG8gdGhlIFNlc3Npb24gSW5pdGlhdGlvbiBQcm90
b2NvbCAoU0lQKSBmb3IgdGhlIDNyZC1HZW5lcmF0aW9uIFBhcnRuZXJzaGlwIFByb2plY3QgKDNH
UFApDQpDcmVhdGlvbiBkYXRlOiAgIDIwMTMtMTAtMDgNCkdyb3VwOiAgICAgICAgICAgSW5kaXZp
ZHVhbCBTdWJtaXNzaW9uDQpOdW1iZXIgb2YgcGFnZXM6IDQ3DQpVUkw6ICAgICAgICAgICAgIGh0
dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWRyYWdlLXNpcHBpbmctcmZj
MzQ1NWJpcy0wOS50eHQNClN0YXR1czogICAgICAgICAgaHR0cDovL2RhdGF0cmFja2VyLmlldGYu
b3JnL2RvYy9kcmFmdC1kcmFnZS1zaXBwaW5nLXJmYzM0NTViaXMNCkh0bWxpemVkOiAgICAgICAg
aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZHJhZ2Utc2lwcGluZy1yZmMzNDU1Ymlz
LTA5DQpEaWZmOiAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRy
YWZ0LWRyYWdlLXNpcHBpbmctcmZjMzQ1NWJpcy0wOQ0KDQpBYnN0cmFjdDoNCiAgIFRoaXMgZG9j
dW1lbnQgZGVzY3JpYmVzIGEgc2V0IG9mIHByaXZhdGUgU2Vzc2lvbiBJbml0aWF0aW9uIFByb3Rv
Y29sDQogICAoU0lQKSBoZWFkZXIgZmllbGRzIChQLWhlYWRlcnMpIHVzZWQgYnkgdGhlIDNyZC1H
ZW5lcmF0aW9uDQogICBQYXJ0bmVyc2hpcCBQcm9qZWN0ICgzR1BQKSwgYWxvbmcgd2l0aCB0aGVp
ciBhcHBsaWNhYmlsaXR5LCB3aGljaCBpcw0KICAgbGltaXRlZCB0byBwYXJ0aWN1bGFyIGVudmly
b25tZW50cy4gIFRoZSBQLWhlYWRlciBmaWVsZHMgYXJlIGZvciBhDQogICB2YXJpZXR5IG9mIHB1
cnBvc2VzIHdpdGhpbiB0aGUgbmV0d29ya3MgdGhhdCB0aGUgcGFydG5lcnMgdXNlLA0KICAgaW5j
bHVkaW5nIGNoYXJnaW5nIGFuZCBpbmZvcm1hdGlvbiBhYm91dCB0aGUgbmV0d29ya3MgYSBjYWxs
DQogICB0cmF2ZXJzZXMuDQoNCg0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBj
b3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0
bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZzxo
dHRwOi8vdG9vbHMuaWV0Zi5vcmc+Lg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KICAtDQoNCg0K
DQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0KVGhpcyB0cmFuc21pc3Npb24gKGluY2x1ZGluZyBhbnkgYXR0
YWNobWVudHMpIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBpbmZvcm1hdGlvbiwgcHJpdmlsZWdl
ZCBtYXRlcmlhbCAoaW5jbHVkaW5nIG1hdGVyaWFsIHByb3RlY3RlZCBieSB0aGUgc29saWNpdG9y
LWNsaWVudCBvciBvdGhlciBhcHBsaWNhYmxlIHByaXZpbGVnZXMpLCBvciBjb25zdGl0dXRlIG5v
bi1wdWJsaWMgaW5mb3JtYXRpb24uIEFueSB1c2Ugb2YgdGhpcyBpbmZvcm1hdGlvbiBieSBhbnlv
bmUgb3RoZXIgdGhhbiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IGlzIHByb2hpYml0ZWQuIElmIHlv
dSBoYXZlIHJlY2VpdmVkIHRoaXMgdHJhbnNtaXNzaW9uIGluIGVycm9yLCBwbGVhc2UgaW1tZWRp
YXRlbHkgcmVwbHkgdG8gdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgaW5mb3JtYXRpb24gZnJv
bSB5b3VyIHN5c3RlbS4gVXNlLCBkaXNzZW1pbmF0aW9uLCBkaXN0cmlidXRpb24sIG9yIHJlcHJv
ZHVjdGlvbiBvZiB0aGlzIHRyYW5zbWlzc2lvbiBieSB1bmludGVuZGVkIHJlY2lwaWVudHMgaXMg
bm90IGF1dGhvcml6ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4K

--_000_BBF5DDFE515C3946BC18D733B20DAD233985F212XMB122CNCrimnet_
Content-Type: text/html; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPGZvbnQgc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz
YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxicj4NCkkgdGhpbmsgaXQgb2Jzb2xldGVz
IFJGQyAzNDU1LiBJdCBpcyBhIGNvbXBsZXRlIHJlcGxhY2VtZW50IGZvciB0aGUgb3JpZ2luYWwu
PGJyPg0KPGJyPg0KQW5kcmV3PC9mb250Pjxicj4NCiZuYnNwOzxicj4NCjxkaXYgc3R5bGU9ImJv
cmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBp
biAwaW4gMGluIj4NCjxmb250IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48Yj5Gcm9tPC9iPjogTWFy
eSBCYXJuZXMgW21haWx0bzptYXJ5LmlldGYuYmFybmVzQGdtYWlsLmNvbV0NCjxicj4NCjxiPlNl
bnQ8L2I+OiBGcmlkYXksIEphbnVhcnkgMTAsIDIwMTQgMDI6MzcgUE0gRWFzdGVybiBTdGFuZGFy
ZCBUaW1lPGJyPg0KPGI+VG88L2I+OiBSLkplc3NrZUB0ZWxla29tLmRlICZsdDtSLkplc3NrZUB0
ZWxla29tLmRlJmd0OyA8YnI+DQo8Yj5DYzwvYj46IERJU1BBVENIICZsdDtkaXNwYXRjaEBpZXRm
Lm9yZyZndDs7IERlYW4gV2lsbGlzICZsdDtkZWFuLndpbGxpc0Bzb2Z0YXJtb3IuY29tJmd0OyA8
YnI+DQo8Yj5TdWJqZWN0PC9iPjogUmU6IFtkaXNwYXRjaF0gUFJPVE8gUmV2aWV3OiBkcmFmdC1k
cmFnZS1zaXBwaW5nLXJmYzM0NTViaXMtMDkudHh0DQo8YnI+DQo8L2ZvbnQ+Jm5ic3A7PGJyPg0K
PC9kaXY+DQo8ZGl2IGRpcj0ibHRyIj5UaGVyZSBpcyB5ZXQgb25lIG1vcmUgY2hhbmdlIG5lZWRl
ZC4gJm5ic3A7VGhpcyBkb2N1bWVudCBpcyBhbiBVcGRhdGVzIHRvIDM0NTViaXMgKEFGQUlLLCB1
bmxlc3MgT2JzZWxldGVzIHdvcmtzIGJldHRlciBmb3IgM0dQUCB1c2FnZSkuICZuYnNwO1RoYXQg
Y2F0ZWdvcml6YXRpb24gbmVlZHMgdG8gYmUgaW5jbHVkZWQgaW4gdGhlIGRvY3VtZW50IGhlYWRl
ciAoM3JkIGxpbmUpLiZuYnNwOw0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+VGhhbmtzLDwvZGl2
Pg0KPGRpdj5NYXJ5LiZuYnNwOzwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9leHRy
YSI+PGJyPg0KPGJyPg0KPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPk9uIEZyaSwgSmFuIDEwLCAy
MDE0IGF0IDE6MzQgUE0sIE1hcnkgQmFybmVzIDxzcGFuIGRpcj0ibHRyIj4NCiZsdDs8YSBocmVm
PSJtYWlsdG86bWFyeS5pZXRmLmJhcm5lc0BnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5tYXJ5
LmlldGYuYmFybmVzQGdtYWlsLmNvbTwvYT4mZ3Q7PC9zcGFuPiB3cm90ZTo8YnI+DQo8YmxvY2tx
dW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXIt
bGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NCjxkaXYgZGlyPSJsdHIiPklO
IGFkZGl0aW9uIHRvIHJlbW92aW5nIHRoZSB1bnVzZWQgcmVmZXJlbmNlcyBpbiB0aGUgbmV4dCB1
cGRhdGUsIHRoZXJlIGFyZSBzdGlsbCA0IGRvbWFpbiBuYW1lcyB0aGF0IGFyZSBub3QgdXNpbmcg
YW4gYXBwcm9wcmlhdGUgZG9jdW1lbnRhdGlvbiBkb21haW4gKGUuZy4sDQo8YSBocmVmPSJodHRw
Oi8vaG9tZS5uZXQiIHRhcmdldD0iX2JsYW5rIj5ob21lLm5ldDwvYT4pLiAmbmJzcDtQbGVhc2Ug
YWRkIHRoYXQgY2hhbmdlIHRvIHRoZSBsaXN0IGZvciB0aGUgbmV4dCByZXZpc2lvbi4gJm5ic3A7
SSdtIGdvaW5nIHRvIGFoZWFkIGFuZCBmb3J3YXJkIHRoZSBQUk9UTyB3cml0ZS11cCB0byBHb256
YWxvLCBub3RpbmcgdGhlIGNoYW5nZXMgdGhhdCBhcmUgbmVlZGVkIGFuZCBzdWdnZXN0aW5nIHRo
b3NlIGNoYW5nZXMgY2FuIGJlIG1hZGUgYWxvbmcNCiB3aXRoIG90aGVyIElFVEYgTEMgY2hhbmdl
cy4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlRoYW5rcyw8L2Rpdj4NCjxkaXY+TWFyeTwvZGl2
Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJIT0VuWmIiPg0KPGRpdiBjbGFzcz0iaDUiPg0KPGRpdiBj
bGFzcz0iZ21haWxfZXh0cmEiPjxicj4NCjxicj4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj5P
biBXZWQsIEphbiA4LCAyMDE0IGF0IDI6NDYgQU0sIDxzcGFuIGRpcj0ibHRyIj4mbHQ7PGEgaHJl
Zj0ibWFpbHRvOlIuSmVzc2tlQHRlbGVrb20uZGUiIHRhcmdldD0iX2JsYW5rIj5SLkplc3NrZUB0
ZWxla29tLmRlPC9hPiZndDs8L3NwYW4+IHdyb3RlOjxicj4NCjxibG9ja3F1b3RlIGNsYXNzPSJn
bWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2Nj
IHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPg0KPGRpdiBsYW5nPSJERSIgbGluaz0iYmx1ZSIgdmxp
bms9InB1cnBsZSI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t
VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMWY0OTdkIj5UaGFuayB5b3UgTWFycnks
PHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu
Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMWY0OTdkIj5mb3IgZG9pbmcg
YWxsIHRoaXMgcmV2aWV3Ljx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFm
NDk3ZCI+U28gSSBoYXZlIG5vdyBwdXQgb3V0IHRoZSBlcnJvcnMuPHU+PC91Pjx1PjwvdT48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu
cy1zZXJpZiZxdW90Oztjb2xvcjojMWY0OTdkIj5UaGVyZSBhcmUgc3RpbGwgc29tZSB1bnVzZWQg
cmVmZXJlbmNlcyB3aGljaCBhcmUgaW4gb3VyIGluZm9ybWFsIHJlZmVyZW5jZSBzZWN0aW9uLiBC
dXQgdXNlZnVsIGZvciB0aGUgcmVhZGVyIHRvIGtub3cgdGhleSBleGlzdC48dT48L3U+PHU+PC91
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv
dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxZjQ5N2QiPlRoZXJlIGFyZSBhbHNvIHNvbWUgd2Fy
bmluZ3Mgd2l0aCByZWdhcmQgdG8gSVAgYWRkcmVzc2VzIGFuZCB3cm9uZyBGUUROcyB3aGljaCBJ
IHRoaW5rIGlzIHNvbWUgaW50ZXJwcmV0YXRpb24gb2Ygc3RyaW5ncyBpbiB0aGUgdGV4dCB3aGlj
aCBhcmUNCiBub3QgbWVhbnQgdG8gYmUgYSBJUCBhZGRyZXNzIG9yIEZRRE4gYXQgYWxsLiA8dT48
L3U+PHU+PC91Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF
Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxZjQ5N2QiPjx1PjwvdT4mbmJzcDs8
dT48L3U+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT
IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFmNDk3ZCI+RGV0YWlsIHNlZSBiZWxvdy48
dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n
PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxZjQ5N2QiPjx1PjwvdT4mbmJz
cDs8dT48L3U+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO
LVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFmNDk3ZCI+U28gbm93IGhvcGVmdWxs
eSBldmVyeXRoaW5nIGlzIHJlYWR5IGZvciB0aGUgbmV4dCBzdGVwLjx1PjwvdT48dT48L3U+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFmNDk3ZCI+PHU+PC91PiZuYnNwOzx1PjwvdT48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z
ZXJpZiZxdW90Oztjb2xvcjojMWY0OTdkIj5CZXN0IFJlZ2FyZHM8dT48L3U+PHU+PC91Pjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z
LXNlcmlmJnF1b3Q7O2NvbG9yOiMxZjQ5N2QiPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDs7Y29sb3I6IzFmNDk3ZCI+Um9sYW5kPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx
dW90Oztjb2xvcjojMWY0OTdkIj48dT48L3U+Jm5ic3A7PHU+PC91Pjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPnRtcC9kcmFmdC1kcmFnZS1z
aXBwaW5nLXJmYzM0NTViaXMtMTIudHh0Ojx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6
ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjx1PjwvdT4mbmJz
cDs8dT48L3U+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO
LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l
dyZxdW90OyI+Jm5ic3A7IENoZWNraW5nIGJvaWxlcnBsYXRlIHJlcXVpcmVkIGJ5IFJGQyA1Mzc4
IGFuZCB0aGUgSUVURiBUcnVzdCAoc2VlPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsNCjxhIGhyZWY9Imh0
dHA6Ly90cnVzdGVlLmlldGYub3JnL2xpY2Vuc2UtaW5mbyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6
Ly90cnVzdGVlLmlldGYub3JnL2xpY2Vuc2UtaW5mbzwvYT4pOjx1PjwvdT48dT48L3U+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u
dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7
IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS08dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i
Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE5vIGlzc3VlcyBmb3VuZCBoZXJlLjx1PjwvdT48dT48L3U+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls
ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+
PHU+PC91PiZuYnNwOzx1PjwvdT48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsgQ2hlY2tpbmcgbml0cyBhY2NvcmRpbmcgdG8NCjxh
IGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvaWQtaW5mby8xaWQtZ3VpZGVsaW5lcy50eHQiIHRh
cmdldD0iX2JsYW5rIj5odHRwOi8vd3d3LmlldGYub3JnL2lkLWluZm8vMWlkLWd1aWRlbGluZXMu
dHh0PC9hPjo8dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPHU+PC91Pjx1
PjwvdT48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi
IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1
b3Q7Ij48dT48L3U+Jm5ic3A7PHU+PC91Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBObyBpc3N1
ZXMgZm91bmQgaGVyZS48dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7IENo
ZWNraW5nIG5pdHMgYWNjb3JkaW5nIHRvDQo8YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL2lk
LWluZm8vY2hlY2tsaXN0IiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3d3dy5pZXRmLm9yZy9pZC1p
bmZvL2NoZWNrbGlzdDwvYT4gOjx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7IC0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS08dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs
YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291
cmllciBOZXcmcXVvdDsiPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6
MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs9PSBUaGVy
ZSBhcmUgNCBpbnN0YW5jZXMgb2YgbGluZXMgd2l0aCBub24tUkZDMjYwNi1jb21wbGlhbnQgRlFE
TnMgaW4gdGhlPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh
bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRv
Y3VtZW50Ljx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv
dDtDb3VyaWVyIE5ldyZxdW90OyI+PHU+PC91PiZuYnNwOzx1PjwvdT48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsgPT0gVGhlcmUg
YXJlIDQgaW5zdGFuY2VzIG9mIGxpbmVzIHdpdGggbm9uLVJGQzU3MzUtY29tcGxpYW50IElQdjQg
YWRkcmVzc2VzPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaW4gdGhlIGRv
Y3VtZW50LiZuYnNwOyBJZiB0aGVzZSBhcmUgZXhhbXBsZSBhZGRyZXNzZXMsIHRoZXkgc2hvdWxk
IGJlIGNoYW5nZWQuPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48dT48L3U+Jm5ic3A7PHU+PC91Pjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6
ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjx1PjwvdT4mbmJz
cDs8dT48L3U+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO
LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l
dyZxdW90OyI+Jm5ic3A7IE1pc2NlbGxhbmVvdXMgd2FybmluZ3M6PHU+PC91Pjx1PjwvdT48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJz
cDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLTx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm
b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PHU+PC91PiZuYnNwOzx1PjwvdT48
L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V
UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm
cXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBObyBpc3N1ZXMgZm91bmQgaGVyZS48dT48
L3U+PHU+PC91Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF
Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO
ZXcmcXVvdDsiPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh
bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7IENoZWNraW5nIHJlZmVyZW5jZXMg
Zm9yIGludGVuZGVkIHN0YXR1czogSW5mb3JtYXRpb25hbDx1PjwvdT48dT48L3U+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7IC0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS08dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u
dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7
ID09IE1pc3NpbmcgUmVmZXJlbmNlOiAnUkZDIFhYWFgnIGlzIG1lbnRpb25lZCBvbiBsaW5lIDE2
NjIsIGJ1dCBub3QgZGVmaW5lZDx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PHU+PC91PiZuYnNwOzx1PjwvdT48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJz
cDsgLS0gTG9va3MgbGlrZSBhIHJlZmVyZW5jZSwgYnV0IHByb2JhYmx5IGlzbid0OiAnMycgb24g
bGluZSAxOTQzPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh
bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PHU+PC91PiZuYnNwOzx1PjwvdT48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250
LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsg
PT0gVW51c2VkIFJlZmVyZW5jZTogJ1JGQzMyNjInIGlzIGRlZmluZWQgb24gbGluZSAyMDY4LCBi
dXQgbm8gZXhwbGljaXQ8dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyByZWZl
cmVuY2Ugd2FzIGZvdW5kIGluIHRoZSB0ZXh0PHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48dT48L3U+Jm5ic3A7PHU+
PC91Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9
IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy
IE5ldyZxdW90OyI+Jm5ic3A7ID09IFVudXNlZCBSZWZlcmVuY2U6ICdSRkMzMzExJyBpcyBkZWZp
bmVkIG9uIGxpbmUgMjA3MiwgYnV0IG5vIGV4cGxpY2l0PHU+PC91Pjx1PjwvdT48L3NwYW4+PC9w
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i
Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHJlZmVyZW5jZSB3YXMgZm91bmQgaW4gdGhlIHRleHQ8dT48
L3U+PHU+PC91Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF
Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO
ZXcmcXVvdDsiPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsgPT0gVW51c2VkIFJl
ZmVyZW5jZTogJ1JGQzM0MjgnIGlzIGRlZmluZWQgb24gbGluZSAyMDc4LCBidXQgbm8gZXhwbGlj
aXQ8dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgcmVmZXJlbmNl
IHdhcyBmb3VuZCBpbiB0aGUgdGV4dDx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm
b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PHU+PC91PiZuYnNwOzx1PjwvdT48
L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V
UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm
cXVvdDsiPiZuYnNwOyA9PSBVbnVzZWQgUmVmZXJlbmNlOiAnUkZDMzkwMycgaXMgZGVmaW5lZCBv
biBsaW5lIDIwOTAsIGJ1dCBubyBleHBsaWNpdDx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyByZWZlcmVuY2Ugd2FzIGZvdW5kIGluIHRoZSB0ZXh0PHU+PC91Pjx1
PjwvdT48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi
IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1
b3Q7Ij48dT48L3U+Jm5ic3A7PHU+PC91Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7ID09IFVudXNlZCBSZWZlcmVu
Y2U6ICdSRkM2MDg2JyBpcyBkZWZpbmVkIG9uIGxpbmUgMjEwMSwgYnV0IG5vIGV4cGxpY2l0PHU+
PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD
b3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHJlZmVyZW5jZSB3YXMg
Zm91bmQgaW4gdGhlIHRleHQ8dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u
dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PHU+PC91
PiZuYnNwOzx1PjwvdT48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBTdW1tYXJ5OiAw
IGVycm9ycyAoKiopLCAwIGZsYXdzICh+fiksIDggd2FybmluZ3MgKD09KSwgMSBjb21tZW50ICgt
LSkuPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom
cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PHU+PC91PiZuYnNwOzx1PjwvdT48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6
MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsgUnVuIGlkbml0cyB3aXRoIHRoZSAtLXZlcmJvc2Ugb3B0aW9uIGZvciBtb3Jl
IGRldGFpbGVkIGluZm9ybWF0aW9uIGFib3V0PHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+dGhlIGl0ZW1zIGFib3ZlLjx1PjwvdT48dT48L3U+
PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPi0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q291cmllciBOZXcmcXVvdDsiPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7
Y29sb3I6IzFmNDk3ZCI+PHU+PC91PiZuYnNwOzx1PjwvdT48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv
cjojMWY0OTdkIj48dT48L3U+Jm5ic3A7PHU+PC91Pjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJi
b3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNiNWM0ZGYgMS4wcHQ7cGFkZGluZzozLjBwdCAw
Y20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90OyI+Vm9uOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBNYXJ5
IEJhcm5lcyBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzptYXJ5LmlldGYuYmFybmVzQGdtYWlsLmNv
bSIgdGFyZ2V0PSJfYmxhbmsiPm1hcnkuaWV0Zi5iYXJuZXNAZ21haWwuY29tPC9hPl0NCjxicj4N
CjxiPkdlc2VuZGV0OjwvYj4gRGllbnN0YWcsIDcuIEphbnVhciAyMDE0IDE4OjU1PC9zcGFuPjwv
cD4NCjxkaXY+DQo8ZGl2Pjxicj4NCjxiPkFuOjwvYj4gSmVzc2tlLCBSb2xhbmQ8YnI+DQo8Yj5D
Yzo8L2I+IERJU1BBVENIOyBHb256YWxvIENhbWFyaWxsbzsgQXRsZSBNb25yYWQ7IERlYW4gV2ls
bGlzPGJyPg0KPGI+QmV0cmVmZjo8L2I+IFJlOiBQUk9UTyBSZXZpZXc6IGRyYWZ0LWRyYWdlLXNp
cHBpbmctcmZjMzQ1NWJpcy0wOS50eHQ8dT48L3U+PHU+PC91PjwvZGl2Pg0KPC9kaXY+DQo8cD48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHU+PC91PiZu
YnNwOzx1PjwvdT48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzIFJvbGFu
ZC4gJm5ic3A7SSBoYXZlIHJldmlld2VkIHRoYXQgdmVyc2lvbiBhbmQgYWxsIHRoZSBjaGFuZ2Vz
IEkgc3VnZ2VzdGVkIGhhdmUgYmVlbiBtYWRlLiAmbmJzcDtIb3dldmVyLCBpbiBkb2luZyB0aGUg
UFJPVE8gd3JpdGUtdXAgSSByZWFsaXplZCB0aGF0IEkgd2Fzbid0IGNlcnRhaW4gYW55b25lIGhh
ZCByZXZpZXdlZCB0aGUgQUJORi4gU28sIEkgcmFuIHRoZSBBQk5GIHRocm91Z2ggQmlsbCBGZW5u
ZXIncyB0b29sOiZuYnNwOzx1PjwvdT48dT48L3U+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy90b29scy9iYXAvYWJuZi5jZ2ki
IHRhcmdldD0iX2JsYW5rIj5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvdG9vbHMvYmFwL2FibmYuY2dp
PC9hPjx1PjwvdT48dT48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHU+PC91PiZuYnNwOzx1PjwvdT48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj5BbmQsIHRoZXJlIGFyZSBhIGNvdXBsZSB0aGluZ3MgdGhhdCBuZWVkIHRvIGJlIGZp
eGVkOjx1PjwvdT48dT48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+MSkgJm5ic3A7RE9UIG5lZWRzIHRvIGNoYW5nZSB0byAmcXVvdDsuJnF1b3Q7ICh3ZSBoYWQg
dGhpcyBzYW1lIGJ1ZyBpbiBSRkMgNDI0NCk6PHU+PC91Pjx1PjwvdT48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw
LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+dHJhbnNpdC1pb2ktaW5k
ZXhlZC12YWx1ZSA9IHRyYW5zaXQtaW9pLW5hbWUgRE9UIHRyYW5zaXQtaW9pLWluZGV4PC9zcGFu
Pjwvc3Bhbj48dT48L3U+PHU+PC91PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+MikgJm5ic3A7VGhlcmUncyBhbiBleHRyYSBzcGFjZSBoZXJlIChiZXR3ZWVu
ICogYW5kIHBhcmVudGhlc2lzKTo8dT48L3U+PHU+PC91PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij50cmFuc2l0LWlvaS1uYW1lJm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ID0gQUxQSEEg
KiAoQUxQSEEgLyBESUdJVCk8L3NwYW4+PC9zcGFuPjx1PjwvdT48dT48L3U+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFt
aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5ORXc6IDwvc3Bhbj48L3NwYW4+PHNwYW4+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm
cXVvdDsiPnRyYW5zaXQtaW9pLW5hbWUmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsgPSBBTFBIQSAqKEFMUEhBIC8gRElHSVQpPC9zcGFuPjwvc3Bh
bj48dT48L3U+PHU+PC91PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
Pjx1PjwvdT4mbmJzcDs8dT48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+VGhlcmUgYXJlIGFsc28gYSBudW1iZXIgb2YgbG9uZyBsaW5lcyBpbiB0aGUgQUJORiB0
aGF0IHNob3VsZCBiZSBmaXhlZC4mbmJzcDs8dT48L3U+PHU+PC91PjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SW4gYWRkaXRpb24sIElETklUUyBpZGVudGlm
aWVzIG90aGVyIGVycm9ycyBhbmQgd2FybmluZ3MgcGVyIHRoZSBmb2xsb3dpbmcuICZuYnNwO1Ro
b3NlIHNob3VsZCBhbHNvIGJlIGFkZHJlc3NlZCBpbmNsdWRpbmcgY29uc2lkZXJpbmcgd2hldGhl
ciBvYnNvbGV0ZSByZWZlcmVuY2VzIG5lZWQgY2hhbmdpbmc6PHU+PC91Pjx1PjwvdT48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cHJlIHN0eWxlPSJ3b3JkLXdyYXA6YnJlYWstd29yZDt3aGl0ZS1zcGFj
ZTpwcmUtd3JhcCI+PHNwYW4+PHU+PC91PiZuYnNwOzx1PjwvdT48L3NwYW4+PC9wcmU+DQo8cHJl
PjxzcGFuPmlkbml0cyAyLjEzLjAxIDx1PjwvdT48dT48L3U+PC9zcGFuPjwvcHJlPg0KPHByZT48
c3Bhbj48dT48L3U+Jm5ic3A7PHU+PC91Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4+dG1wL2Ry
YWZ0LWRyYWdlLXNpcHBpbmctcmZjMzQ1NWJpcy0xMS50eHQ6PHU+PC91Pjx1PjwvdT48L3NwYW4+
PC9wcmU+DQo8cHJlPjxzcGFuPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9zcGFuPjwvcHJlPg0KPHBy
ZT48c3Bhbj4mbmJzcDsgQ2hlY2tpbmcgYm9pbGVycGxhdGUgcmVxdWlyZWQgYnkgUkZDIDUzNzgg
YW5kIHRoZSBJRVRGIFRydXN0IChzZWU8dT48L3U+PHU+PC91Pjwvc3Bhbj48L3ByZT4NCjxwcmU+
PHNwYW4+Jm5ic3A7IDxhIGhyZWY9Imh0dHA6Ly90cnVzdGVlLmlldGYub3JnL2xpY2Vuc2UtaW5m
byIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly90cnVzdGVlLmlldGYub3JnL2xpY2Vuc2UtaW5mbzwv
YT4pOjx1PjwvdT48dT48L3U+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bhbj4mbmJzcDsgLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLTx1PjwvdT48dT48L3U+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bhbj48dT48
L3U+Jm5ic3A7PHU+PC91Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4+Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7IE5vIGlzc3VlcyBmb3VuZCBoZXJlLjx1PjwvdT48dT48L3U+PC9zcGFuPjwvcHJl
Pg0KPHByZT48c3Bhbj48dT48L3U+Jm5ic3A7PHU+PC91Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw
YW4+Jm5ic3A7IENoZWNraW5nIG5pdHMgYWNjb3JkaW5nIHRvIDxhIGhyZWY9Imh0dHA6Ly93d3cu
aWV0Zi5vcmcvaWQtaW5mby8xaWQtZ3VpZGVsaW5lcy50eHQiIHRhcmdldD0iX2JsYW5rIj5odHRw
Oi8vd3d3LmlldGYub3JnL2lkLWluZm8vMWlkLWd1aWRlbGluZXMudHh0PC9hPjo8dT48L3U+PHU+
PC91Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4+Jm5ic3A7IC0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08
dT48L3U+PHU+PC91Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4+PHU+PC91PiZuYnNwOzx1Pjwv
dT48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBObyBp
c3N1ZXMgZm91bmQgaGVyZS48dT48L3U+PHU+PC91Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4+
PHU+PC91PiZuYnNwOzx1PjwvdT48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuPiZuYnNwOyBDaGVj
a2luZyBuaXRzIGFjY29yZGluZyB0byA8YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL2lkLWlu
Zm8vY2hlY2tsaXN0IiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3d3dy5pZXRmLm9yZy9pZC1pbmZv
L2NoZWNrbGlzdDwvYT4gOjx1PjwvdT48dT48L3U+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bhbj4m
bmJzcDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTx1PjwvdT48dT48L3U+PC9zcGFuPjwvcHJlPg0KPHBy
ZT48c3Bhbj48dT48L3U+Jm5ic3A7PHU+PC91Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4+Jm5i
c3A7ICoqIFRoZXJlIGFyZSA5IGluc3RhbmNlcyBvZiB0b28gbG9uZyBsaW5lcyBpbiB0aGUgZG9j
dW1lbnQsIHRoZSBsb25nZXN0IG9uZTx1PjwvdT48dT48L3U+PC9zcGFuPjwvcHJlPg0KPHByZT48
c3Bhbj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYmVpbmcgMjAgY2hhcmFjdGVycyBpbiBleGNl
c3Mgb2YgNzIuPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuPjx1PjwvdT4m
bmJzcDs8dT48L3U+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bhbj4mbmJzcDsgPT0gVGhlcmUgYXJl
IDQgaW5zdGFuY2VzIG9mIGxpbmVzIHdpdGggbm9uLVJGQzI2MDYtY29tcGxpYW50IEZRRE5zIGlu
IHRoZTx1PjwvdT48dT48L3U+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bhbj4mbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsgZG9jdW1lbnQuPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wcmU+DQo8cHJlPjxz
cGFuPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bhbj4mbmJzcDsg
PT0gVGhlcmUgYXJlIDQgaW5zdGFuY2VzIG9mIGxpbmVzIHdpdGggbm9uLVJGQzU3MzUtY29tcGxp
YW50IElQdjQgYWRkcmVzc2VzPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu
PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBpbiB0aGUgZG9jdW1lbnQuJm5ic3A7IElmIHRoZXNl
IGFyZSBleGFtcGxlIGFkZHJlc3NlcywgdGhleSBzaG91bGQgYmUgY2hhbmdlZC48dT48L3U+PHU+
PC91Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4+PHU+PC91PiZuYnNwOzx1PjwvdT48L3NwYW4+
PC9wcmU+DQo8cHJlPjxzcGFuPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9zcGFuPjwvcHJlPg0KPHBy
ZT48c3Bhbj4mbmJzcDsgTWlzY2VsbGFuZW91cyB3YXJuaW5nczo8dT48L3U+PHU+PC91Pjwvc3Bh
bj48L3ByZT4NCjxwcmU+PHNwYW4+Jm5ic3A7IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08dT48L3U+PHU+
PC91Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4+PHU+PC91PiZuYnNwOzx1PjwvdT48L3NwYW4+
PC9wcmU+DQo8cHJlPjxzcGFuPiZuYnNwOyA9PSBUaGUgZG9jdW1lbnQgc2VlbXMgdG8gY29udGFp
biBhIGRpc2NsYWltZXIgZm9yIHByZS1SRkM1Mzc4IHdvcmssIGJ1dCB3YXM8dT48L3U+PHU+PC91
Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGZpcnN0
IHN1Ym1pdHRlZCBvbiBvciBhZnRlciAxMCBOb3ZlbWJlciAyMDA4LiZuYnNwOyBUaGUgZGlzY2xh
aW1lciBpcyB1c3VhbGx5PHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuPiZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBuZWNlc3Nhcnkgb25seSBmb3IgZG9jdW1lbnRzIHRoYXQg
cmV2aXNlIG9yIG9ic29sZXRlIG9sZGVyIFJGQ3MsIGFuZCB0aGF0PHU+PC91Pjx1PjwvdT48L3Nw
YW4+PC9wcmU+DQo8cHJlPjxzcGFuPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0YWtlIHNpZ25p
ZmljYW50IGFtb3VudHMgb2YgdGV4dCBmcm9tIHRob3NlIFJGQ3MuJm5ic3A7IElmIHlvdSBjYW4g
Y29udGFjdCBhbGw8dT48L3U+PHU+PC91Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4+Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7IGF1dGhvcnMgb2YgdGhlIHNvdXJjZSBtYXRlcmlhbCBhbmQgdGhl
eSBhcmUgd2lsbGluZyB0byBncmFudCB0aGUgQkNQNzg8dT48L3U+PHU+PC91Pjwvc3Bhbj48L3By
ZT4NCjxwcmU+PHNwYW4+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHJpZ2h0cyB0byB0aGUgSUVU
RiBUcnVzdCwgeW91IGNhbiBhbmQgc2hvdWxkIHJlbW92ZSB0aGUgZGlzY2xhaW1lci4gPHU+PC91
Pjx1PjwvdT48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwO090aGVyd2lzZSwgdGhlIGRpc2NsYWltZXIgaXMgbmVlZGVkIGFuZCB5b3UgY2FuIGln
bm9yZSB0aGlzIGNvbW1lbnQuIDx1PjwvdT48dT48L3U+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh
bj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsoU2VlIHRoZSBMZWdhbCBQcm92aXNpb25z
IGRvY3VtZW50IGF0PHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuPiZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyA8YSBocmVmPSJodHRwOi8vdHJ1c3RlZS5pZXRmLm9yZy9saWNl
bnNlLWluZm8iIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vdHJ1c3RlZS5pZXRmLm9yZy9saWNlbnNl
LWluZm88L2E+IGZvciBtb3JlIGluZm9ybWF0aW9uLik8dT48L3U+PHU+PC91Pjwvc3Bhbj48L3By
ZT4NCjxwcmU+PHNwYW4+PHU+PC91PiZuYnNwOzx1PjwvdT48L3NwYW4+PC9wcmU+DQo8cHJlPjxz
cGFuPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bhbj4mbmJzcDsg
Q2hlY2tpbmcgcmVmZXJlbmNlcyBmb3IgaW50ZW5kZWQgc3RhdHVzOiBJbmZvcm1hdGlvbmFsPHU+
PC91Pjx1PjwvdT48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuPiZuYnNwOyAtLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuPjx1PjwvdT4mbmJz
cDs8dT48L3U+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bhbj4mbmJzcDsgPT0gTWlzc2luZyBSZWZl
cmVuY2U6ICdSRkMgWFhYWCcgaXMgbWVudGlvbmVkIG9uIGxpbmUgMTY2NywgYnV0IG5vdCBkZWZp
bmVkPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuPjx1PjwvdT4mbmJzcDs8
dT48L3U+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bhbj4mbmJzcDsgLS0gTG9va3MgbGlrZSBhIHJl
ZmVyZW5jZSwgYnV0IHByb2JhYmx5IGlzbid0OiAnMycgb24gbGluZSAxOTQ4PHU+PC91Pjx1Pjwv
dT48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9zcGFuPjwv
cHJlPg0KPHByZT48c3Bhbj4mbmJzcDsgPT0gVW51c2VkIFJlZmVyZW5jZTogJ1JGQzI5NzYnIGlz
IGRlZmluZWQgb24gbGluZSAyMDY1LCBidXQgbm8gZXhwbGljaXQ8dT48L3U+PHU+PC91Pjwvc3Bh
bj48L3ByZT4NCjxwcmU+PHNwYW4+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHJlZmVyZW5jZSB3
YXMgZm91bmQgaW4gdGhlIHRleHQ8dT48L3U+PHU+PC91Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw
YW4+PHU+PC91PiZuYnNwOzx1PjwvdT48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuPiZuYnNwOyA9
PSBVbnVzZWQgUmVmZXJlbmNlOiAnUkZDMzI2MicgaXMgZGVmaW5lZCBvbiBsaW5lIDIwNjgsIGJ1
dCBubyBleHBsaWNpdDx1PjwvdT48dT48L3U+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bhbj4mbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsgcmVmZXJlbmNlIHdhcyBmb3VuZCBpbiB0aGUgdGV4dDx1Pjwv
dT48dT48L3U+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bhbj48dT48L3U+Jm5ic3A7PHU+PC91Pjwv
c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4+Jm5ic3A7ID09IFVudXNlZCBSZWZlcmVuY2U6ICdSRkMz
MzExJyBpcyBkZWZpbmVkIG9uIGxpbmUgMjA3NSwgYnV0IG5vIGV4cGxpY2l0PHU+PC91Pjx1Pjwv
dT48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyByZWZl
cmVuY2Ugd2FzIGZvdW5kIGluIHRoZSB0ZXh0PHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wcmU+DQo8
cHJlPjxzcGFuPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bhbj4m
bmJzcDsgPT0gVW51c2VkIFJlZmVyZW5jZTogJ1JGQzM0MjgnIGlzIGRlZmluZWQgb24gbGluZSAy
MDgxLCBidXQgbm8gZXhwbGljaXQ8dT48L3U+PHU+PC91Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw
YW4+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHJlZmVyZW5jZSB3YXMgZm91bmQgaW4gdGhlIHRl
eHQ8dT48L3U+PHU+PC91Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4+PHU+PC91PiZuYnNwOzx1
PjwvdT48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuPiZuYnNwOyA9PSBVbnVzZWQgUmVmZXJlbmNl
OiAnUkZDMzkwMycgaXMgZGVmaW5lZCBvbiBsaW5lIDIwOTMsIGJ1dCBubyBleHBsaWNpdDx1Pjwv
dT48dT48L3U+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bhbj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsgcmVmZXJlbmNlIHdhcyBmb3VuZCBpbiB0aGUgdGV4dDx1PjwvdT48dT48L3U+PC9zcGFuPjwv
cHJlPg0KPHByZT48c3Bhbj48dT48L3U+Jm5ic3A7PHU+PC91Pjwvc3Bhbj48L3ByZT4NCjxwcmU+
PHNwYW4+Jm5ic3A7ICoqIE9ic29sZXRlIG5vcm1hdGl2ZSByZWZlcmVuY2U6IFJGQyAyMjM0IChP
YnNvbGV0ZWQgYnkgUkZDIDQyMzQpPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wcmU+DQo8cHJlPjxz
cGFuPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bhbj4mbmJzcDsg
LS0gT2Jzb2xldGUgaW5mb3JtYXRpb25hbCByZWZlcmVuY2UgKGlzIHRoaXMgaW50ZW50aW9uYWw/
KTogUkZDIDI5NzY8dT48L3U+PHU+PC91Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4+Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7IChPYnNvbGV0ZWQgYnkgUkZDIDYwODYpPHU+PC91Pjx1PjwvdT48
L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9zcGFuPjwvcHJl
Pg0KPHByZT48c3Bhbj4mbmJzcDsgLS0gT2Jzb2xldGUgaW5mb3JtYXRpb25hbCByZWZlcmVuY2Ug
KGlzIHRoaXMgaW50ZW50aW9uYWw/KTogUkZDIDMyNjU8dT48L3U+PHU+PC91Pjwvc3Bhbj48L3By
ZT4NCjxwcmU+PHNwYW4+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IChPYnNvbGV0ZWQgYnkgUkZD
IDY2NjUpPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuPjx1PjwvdT4mbmJz
cDs8dT48L3U+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bhbj48dT48L3U+Jm5ic3A7PHU+PC91Pjwv
c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFN1bW1hcnk6
IDIgZXJyb3JzICgqKiksIDAgZmxhd3MgKH5+KSwgOSB3YXJuaW5ncyAoPT0pLCAzIGNvbW1lbnRz
ICgtLSkuPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuPjx1PjwvdT4mbmJz
cDs8dT48L3U+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bhbj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsgUnVuIGlkbml0cyB3aXRoIHRoZSAtLXZlcmJvc2Ugb3B0aW9uIGZvciBtb3JlIGRldGFpbGVk
IGluZm9ybWF0aW9uIGFib3V0PHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu
PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0aGUgaXRlbXMgYWJvdmUuPHU+PC91Pjx1PjwvdT48
L3NwYW4+PC9wcmU+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaGlsZSBJ
IGFwb2xvZ2l6ZSBmb3Igbm90IGNhdGNoaW5nIHRoZXNlIGlzc3VlcyBlYXJsaWVyLCBpdCByZWFs
bHkgaXMgdGhlIHJlc3BvbnNpYmlsaXR5IG9mIGF1dGhvcnMgdG8gY2hlY2sgaWRuaXRzIChiZXlv
bmQgd2hhdCB0aGUgc3VibWlzc2lvbiB0b29sIHJlcXVpcmVzKSBmb3IgdGhlaXIgZG9jdW1lbnRz
LiAmbmJzcDtJIHJvdXRpbmVseSBydW4gaWRuaXRzIGJlZm9yZSBJIHN1Ym1pdCBhIGRvY3VtZW50
IGFzIGl0DQogY2FuIGFsc28gc2F2ZSB0aW1lIHdoZW4gZml4aW5nIHRoZSAmbmJzcDtuaXRzIHRo
YXQgdGhlIHN1Ym1pc3Npb24gdG9vbCBjYXRjaGVzOiAmbmJzcDsmbmJzcDs8YSBocmVmPSJodHRw
czovL3Rvb2xzLmlldGYub3JnL3Rvb2xzL2lkbml0cy8iIHRhcmdldD0iX2JsYW5rIj5odHRwczov
L3Rvb2xzLmlldGYub3JnL3Rvb2xzL2lkbml0cy88L2E+PHU+PC91Pjx1PjwvdT48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48dT48L3U+Jm5ic3A7PHU+PC91PjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJlZ2FyZHMsPHU+PC91Pjx1Pjwv
dT48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NYXJ5LiZuYnNwOzx1
PjwvdT48dT48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHU+
PC91PiZuYnNwOzx1PjwvdT48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48dT48L3U+Jm5ic3A7PHU+PC91PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48dT48L3U+Jm5ic3A7
PHU+PC91PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUdWUsIEphbiA3LCAy
MDE0IGF0IDEyOjM1IEFNLCAmbHQ7PGEgaHJlZj0ibWFpbHRvOlIuSmVzc2tlQHRlbGVrb20uZGUi
IHRhcmdldD0iX2JsYW5rIj5SLkplc3NrZUB0ZWxla29tLmRlPC9hPiZndDsgd3JvdGU6PHU+PC91
Pjx1PjwvdT48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh
bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFmNDk3ZCI+SGkgTWFyeSw8
L3NwYW4+PHU+PC91Pjx1PjwvdT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n
PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxZjQ5N2QiPk5vdyBhIG5ldyBy
ZXZpc2lvbiBpcyBhdmFpbGFibGUuPC9zcGFuPjx1PjwvdT48dT48L3U+PC9wPg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv
dDs7Y29sb3I6IzFmNDk3ZCI+Jm5ic3A7PC9zcGFuPjx1PjwvdT48dT48L3U+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj
b2xvcjojMWY0OTdkIj5UaGFuayB5b3UgYW5kIEJlc3QgUmVnYXJkczwvc3Bhbj48dT48L3U+PHU+
PC91PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFmNDk3ZCI+Jm5ic3A7PC9zcGFuPjx1PjwvdT48dT48L3U+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z
ZXJpZiZxdW90Oztjb2xvcjojMWY0OTdkIj5Sb2xhbmQ8L3NwYW4+PHU+PC91Pjx1PjwvdT48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm
JnF1b3Q7O2NvbG9yOiMxZjQ5N2QiPiZuYnNwOzwvc3Bhbj48dT48L3U+PHU+PC91PjwvcD4NCjwv
ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjYjVjNGRmIDEu
MHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+
PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Wb246PC9zcGFuPjwvYj48
c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBNYXJ5IEJhcm5lcyBbbWFp
bHRvOjxhIGhyZWY9Im1haWx0bzptYXJ5LmlldGYuYmFybmVzQGdtYWlsLmNvbSIgdGFyZ2V0PSJf
YmxhbmsiPm1hcnkuaWV0Zi5iYXJuZXNAZ21haWwuY29tPC9hPl0NCjxicj4NCjxiPkdlc2VuZGV0
OjwvYj4gTW9udGFnLCA2LiBKYW51YXIgMjAxNCAyPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm
JnF1b3Q7Ij4wOjAwPC9zcGFuPjx1PjwvdT48dT48L3U+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8Yj5Bbjo8L2I+IEplc3NrZSwgUm9sYW5kPGJyPg0KPGI+
Q2M6PC9iPiBESVNQQVRDSDsgR29uemFsbyBDYW1hcmlsbG87IEF0bGUgTW9ucmFkOyBEZWFuIFdp
bGxpczxicj4NCjxiPkJldHJlZmY6PC9iPiBSZTogUFJPVE8gUmV2aWV3OiBkcmFmdC1kcmFnZS1z
aXBwaW5nLXJmYzM0NTViaXMtMDkudHh0PHU+PC91Pjx1PjwvdT48L3A+DQo8L2Rpdj4NCjwvZGl2
Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzx1Pjwv
dT48dT48L3U+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIFJvbGFuZCw8dT48
L3U+PHU+PC91PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8dT48L3U+
PHU+PC91PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uZSBmaW5h
bCBlZGl0b3JpYWwgbml0IGJlbG93LiAmbmJzcDtJZiB5b3UgY2FuIHNwaW4gYSByZXZpc2lvbiwg
dGhlbiBJJ2xsIHNlbmQgdGhlIFBST1RPIHdyaXRlLXVwIHRvIHRoZSBBRC48dT48L3U+PHU+PC91
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzx1PjwvdT48
dT48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzLDx1
PjwvdT48dT48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TWFy
eS4mbmJzcDs8dT48L3U+PHU+PC91PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+Jm5ic3A7PHU+PC91Pjx1PjwvdT48
L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVGh1LCBKYW4gMiwgMjAxNCBhdCAz
OjI5IEFNLCAmbHQ7PGEgaHJlZj0ibWFpbHRvOlIuSmVzc2tlQHRlbGVrb20uZGUiIHRhcmdldD0i
X2JsYW5rIj5SLkplc3NrZUB0ZWxla29tLmRlPC9hPiZndDsgd3JvdGU6PHU+PC91Pjx1PjwvdT48
L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT
IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFmNDk3ZCI+SGkgTWFyeSw8L3NwYW4+PHU+
PC91Pjx1PjwvdT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm
cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxZjQ5N2QiPkkgd2lzaCB5b3UgYSBoYXBweSBu
ZXcgeWVhciAyMDE0LiBBbmQgdGhlIGJlc3QgZm9yIHRoZSBuZXh0IHllYXIuPC9zcGFuPjx1Pjwv
dT48dT48L3U+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1
b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMWY0OTdkIj4mbmJzcDs8L3NwYW4+PHU+PC91Pjx1
PjwvdT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz
YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxZjQ5N2QiPkkgd2FzIGxvb2tpbmcgYWdhaW4gb24gbXkg
Y2hhbmdlcyBJIG1hZGUgZHVlIHRvIHlvdXIgcHJvcG9zYWwgaW4gRGVjZW1iZXIuPC9zcGFuPjx1
PjwvdT48dT48L3U+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss
JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMWY0OTdkIj5JIHJlYWxpemVkIHRoYXQgaWYg
SSBjaGFuZ2UgdGhlIFNIT1VMRCB0byBNVVNUIHdlIGhhdmUgbm93IGEgYmFja3dhcmQgY29tcGF0
aWJpbGl0eSBwcm9ibGVtLjwvc3Bhbj48dT48L3U+PHU+PC91PjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFm
NDk3ZCI+V2UgYXJlIHVzaW5nIHRoZSBQLUFzc29jaWF0ZWQtVVJJIGFsc28gb3ZlciB0aGUgSU1T
IHVzZXIgaW50ZXJmYWNlIHdoaWNoIGlzIG5vdCBlbmNyeXB0ZWQuPC9zcGFuPjx1PjwvdT48dT48
L3U+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu
cy1zZXJpZiZxdW90Oztjb2xvcjojMWY0OTdkIj5TbyBJIHByb3Bvc2UgdG8gYWRkIHNvbWUgbW9y
ZSB3b3Jkcy48L3NwYW4+PHU+PC91Pjx1PjwvdT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxZjQ5N2QiPuKA
pjwvc3Bhbj48dT48L3U+PHU+PC91PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh
bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFmNDk3ZCI+U2VjdGlvbiA2
LjE8L3NwYW4+PHU+PC91Pjx1PjwvdT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs
YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs
aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxZjQ5N2QiPuKApjwvc3Bh
bj48dT48L3U+PHU+PC91PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWF1
dG9zcGFjZTpub25lIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUi
PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPHNwYW4g
c3R5bGU9ImNvbG9yOmJsdWUiPiZsdDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOm1hcm9vbiI+
dDwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6Ymx1ZSI+Jmd0Ozwvc3Bhbj5BbiBlYXZlc2Ryb3Bw
ZXIgY291bGQgcG9zc2libHkgY29sbGVjdCB0aGUgbGlzdCBvZiBpZGVudGl0aWVzIGEgdXNlciBp
cyByZWdpc3RlcmVkLiZuYnNwOw0KPC9zcGFuPjx1PjwvdT48dT48L3U+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYXV0b3NwYWNlOm5vbmUiPjxzcGFuIGxhbmc9IkVOLVVT
IiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7VGhpcyBjYW4gaGF2ZSBwcml2YWN5IGltcGxpY2F0aW9ucy4gVG8gbWl0aWdh
dGUgdGhpcyBwcm9ibGVtLCB0aGlzIGV4dGVuc2lvbiBTSE9VTEQNCjwvc3Bhbj48dT48L3U+PHU+
PC91PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hdXRvc3Bh
Y2U6bm9uZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtvbmx5IGJlIHVzZWQgaW4gYSBz
ZWN1cmVkIGVudmlyb25tZW50LCB3aGVyZSBlbmNyeXB0aW9uIG9mIFNJUCBtZXNzYWdlcyBpcw0K
PC9zcGFuPjx1PjwvdT48dT48L3U+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0idGV4dC1hdXRvc3BhY2U6bm9uZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJiYWNr
Z3JvdW5kOndoaXRlIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtw
cm92aWRlZCBlaXRoZXIgZW5kLXRvLWVuZCBvciBob3AtYnktaG9wLiZuYnNwOw0KPHNwYW4gc3R5
bGU9ImNvbG9yOmJsdWUiPiZsdDsvPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjptYXJvb24iPnQ8
L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsdWUiPiZndDs8L3NwYW4+PC9zcGFuPjx1PjwvdT48
dT48L3U+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYXV0b3NwYWNlOm5v
bmUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7Jm5i
c3A7DQo8L3NwYW4+PHU+PC91Pjx1PjwvdT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0idGV4dC1hdXRvc3BhY2U6bm9uZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJiYWNrZ3Jv
dW5kOndoaXRlIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8c3BhbiBzdHls
ZT0iY29sb3I6Ymx1ZSI+Jmx0Ozwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6bWFyb29uIj50PC9z
cGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibHVlIj4mZ3Q7PC9zcGFuPiBTaW5jZSB0aGUgUC1Bc3Nv
Y2lhdGVkLVVSSSBoZWFkZXIgZmllbGQgdmFsdWUgYWxsb3dzIHRvDQogaW1wbGljaXRseSByZWdp
c3RlciA8L3NwYW4+PHU+PC91Pjx1PjwvdT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0idGV4dC1hdXRvc3BhY2U6bm9uZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJiYWNrZ3Jv
dW5kOndoaXRlIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDthIGJ1bmRsZSBv
ZiBVUklzIHdpdGggb25lIFJFR0lTVEVSIE1lc3NhZ2UgdGhlIGltcGFjdCBvZiBzZWN1cml0eSB1
c2luZyB0aGUgUC1Bc3NvY2lhdGVkLVVSSSBoZWFkZXIgZmllbGQgaXMgbm90IGhpZ2hlciB0aGFu
Jm5ic3A7DQo8L3NwYW4+PHU+PC91Pjx1PjwvdT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwO3VzaW5nIHNpbmdsZSBSRUdJU1RFUiBtZXNzYWdlcyB3aGVu
IHJlZ2lzdGVyaW5nIGFsbCBpZGVudGl0aWVzIGV4cGxpY2l0LjxzcGFuIHN0eWxlPSJjb2xvcjpi
bHVlIj4mbHQ7Lzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6bWFyb29uIj50PC9zcGFuPjxzcGFu
IHN0eWxlPSJjb2xvcjpibHVlIj4mZ3Q7PC9zcGFuPjwvc3Bhbj48dT48L3U+PHU+PC91PjwvcD4N
CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+W01CXSBJIGp1c3Qg
aGF2ZSBzb21lIGVkaXRvcmlhbCBzdWdnZXN0aW9ucyBmb3IgdGhlIGFib3ZlOjx1PjwvdT48dT48
L3U+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TkVXOiAmbmJzcDs8
dT48L3U+PHU+PC91PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6Ymx1ZSI+Jmx0Ozwvc3Bhbj48c3BhbiBsYW5n
PSJFTi1VUyIgc3R5bGU9ImNvbG9yOm1hcm9vbiI+dDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIg
c3R5bGU9ImNvbG9yOmJsdWUiPiZndDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwO1do
aWxlIHRoZSBQLUFzc29jaWF0ZWQtVVJJIGhlYWRlciBmaWVsZCB2YWx1ZSBhbGxvd3MgdGhlIGlt
cGxpY2l0IHJlZ2lzdHJhdGlvbg0KIG9mJm5ic3A7PC9zcGFuPjx1PjwvdT48dT48L3U+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwO2EgYnVuZGxlIG9mIFVSSXMgd2l0aCBvbmUgUkVHSVNURVIgTWVz
c2FnZSB0aGUgaW1wYWN0IG9mIHNlY3VyaXR5IHVzaW5nIHRoZSBQLUFzc29jaWF0ZWQtVVJJIGhl
YWRlciBmaWVsZCBpcyBubyBoaWdoZXIgdGhhbiZuYnNwOzwvc3Bhbj48dT48L3U+PHU+PC91Pjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt1c2luZyBzZXBhcmF0ZSBSRUdJU1RFUiBtZXNzYWdlcyBm
b3IgZWFjaCBvZiB0aGUgVVJJcy4mbmJzcDs8c3BhbiBzdHlsZT0iY29sb3I6Ymx1ZSI+Jmx0Oy88
L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOm1hcm9vbiI+dDwvc3Bhbj48c3BhbiBzdHlsZT0iY29s
b3I6Ymx1ZSI+Jmd0Ozwvc3Bhbj48L3NwYW4+PHU+PC91Pjx1PjwvdT48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsdWUiPlsvTUJdPC9z
cGFuPjx1PjwvdT48dT48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+Jm5ic3A7PHU+PC91Pjx1PjwvdT48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJi
b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjY2NjY2NjIDEuMHB0O3BhZGRpbmc6MGNtIDBj
bSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmln
aHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj4mbmJzcDs8dT48L3U+PHU+PC91PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2Nr
cXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg
I2NjY2NjYyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0
O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4N
CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0
eWxlPSJjb2xvcjpibHVlIj4mbmJzcDs8L3NwYW4+PHU+PC91Pjx1PjwvdT48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsdWUiPiZuYnNw
Ozwvc3Bhbj48dT48L3U+PHU+PC91PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh
bmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6Ymx1ZSI+Rm9yIHRoZSBQLUNhbGxlZC1QYXJ0eS1JZCB0
aGUgY2hhbmdlIHNob3VsZCBiZSBhbHNvIGRvbmUgbGlrZSBhcyBmb2xsb3dzOjwvc3Bhbj48dT48
L3U+PHU+PC91PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz
dHlsZT0iY29sb3I6Ymx1ZSI+Jm5ic3A7PC9zcGFuPjx1PjwvdT48dT48L3U+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYXV0b3NwYWNlOm5vbmUiPjxzcGFuIGxhbmc9IkVO
LVVTIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7DQo8c3BhbiBzdHlsZT0iY29sb3I6Ymx1ZSI+Jmx0Ozwvc3Bhbj48c3Bh
biBzdHlsZT0iY29sb3I6bWFyb29uIj50PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibHVlIj4m
Z3Q7PC9zcGFuPkFuIGVhdmVzZHJvcHBlciBjb3VsZCBwb3NzaWJseSBjb2xsZWN0IHRoZSBsaXN0
IG9mIGlkZW50aXRpZXMgYSB1c2VyIGlzIHJlZ2lzdGVyZWQuJm5ic3A7DQo8L3NwYW4+PHU+PC91
Pjx1PjwvdT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hdXRvc3BhY2U6
bm9uZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtUaGlzIGNhbiBoYXZlIHByaXZhY3kg
aW1wbGljYXRpb25zLiZuYnNwOyBUbyBtaXRpZ2F0ZSB0aGlzIHByb2JsZW0sIHRoaXMgZXh0ZW5z
aW9uIFNIT1VMRA0KPC9zcGFuPjx1PjwvdT48dT48L3U+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWF1dG9zcGFjZTpub25lIj48c3BhbiBsYW5nPSJFTi1VUyIg
c3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwO29ubHkgYmUgdXNlZCBpbiBhIHNlY3VyZWQgZW52aXJvbm1lbnQsIHdoZXJlIGVu
Y3J5cHRpb24gb2YgU0lQIG1lc3NhZ2VzIGlzDQo8L3NwYW4+PHU+PC91Pjx1PjwvdT48L3A+DQo8
L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iYmFj
a2dyb3VuZDp3aGl0ZSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
cHJvdmlkZWQgZWl0aGVyIGVuZC10by1lbmQgb3IgaG9wLWJ5LWhvcC4mbmJzcDsNCjwvc3Bhbj48
c3BhbiBzdHlsZT0iY29sb3I6Ymx1ZTtiYWNrZ3JvdW5kOndoaXRlIj4mbHQ7Lzwvc3Bhbj48c3Bh
biBzdHlsZT0iY29sb3I6bWFyb29uO2JhY2tncm91bmQ6d2hpdGUiPnQ8L3NwYW4+PHNwYW4gc3R5
bGU9ImNvbG9yOmJsdWU7YmFja2dyb3VuZDp3aGl0ZSI+Jmd0Ozwvc3Bhbj48dT48L3U+PHU+PC91
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWF1dG9zcGFjZTpub25lIj48
c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxZjQ5N2QiPiZu
YnNwOzwvc3Bhbj48dT48L3U+PHU+PC91PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJ0ZXh0LWF1dG9zcGFjZTpub25lIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImJhY2tncm91
bmQ6d2hpdGUiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPHNw
YW4gc3R5bGU9ImNvbG9yOmJsdWUiPiZsdDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOm1hcm9v
biI+dDwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6Ymx1ZSI+Jmd0Ozwvc3Bhbj5Ob3JtYWxseSB3
aXRoaW4gYSAzR1BQIGVudmlyb25tZW50IHRoZSBQLUNhbGxlZC1QYXJ0eS1JRCBpcyBub3Qgc2Vu
dCB0b3dhcmRzIGVuZCB1c2VycyBidXQgbWF5IGJlIGV4Y2hhbmdlZCBiZXR3ZWVuIGNhcnJpZXJz
IHdoZXJlIG90aGVyIHNlY3VyaXR5IG1lY2hhbmlzbXMNCiB0aGFuIFNJUCBlbmNyeXB0aW9uIGFy
ZSB1c2VkLiZuYnNwOyA8c3BhbiBzdHlsZT0iY29sb3I6Ymx1ZSI+Jmx0Oy88L3NwYW4+PHNwYW4g
c3R5bGU9ImNvbG9yOm1hcm9vbiI+dDwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6Ymx1ZSI+Jmd0
Ozwvc3Bhbj48L3NwYW4+PHU+PC91Pjx1PjwvdT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxZjQ5N2QiPiZu
YnNwOzwvc3Bhbj48dT48L3U+PHU+PC91PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFmNDk3ZCI+U29ycnkg
Y29taW5nIHNvIGxhdGUuPC9zcGFuPjx1PjwvdT48dT48L3U+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMWY0
OTdkIj5JZiB0aGlzIGlzIE9LIGZvciB5b3UgSSB3aWxsIGluY2x1ZGUgaXQgdG8gYSBuZXcgdmVy
c2lvbi48L3NwYW4+PHU+PC91Pjx1PjwvdT48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMWY0OTdk
Ij4mbmJzcDs8L3NwYW4+PHU+PC91Pjx1PjwvdT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxZjQ5N2QiPlRo
YW5rIHlvdSBhbmQgQmVzdCBSZWdhcmRzPC9zcGFuPjx1PjwvdT48dT48L3U+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj
b2xvcjojMWY0OTdkIj4mbmJzcDs8L3NwYW4+PHU+PC91Pjx1PjwvdT48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y
OiMxZjQ5N2QiPlJvbGFuZDwvc3Bhbj48dT48L3U+PHU+PC91PjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFm
NDk3ZCI+Jm5ic3A7PC9zcGFuPjx1PjwvdT48dT48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxl
PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNiNWM0ZGYgMS4wcHQ7cGFkZGluZzozLjBw
dCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z
ZXJpZiZxdW90OyI+Vm9uOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBN
YXJ5IEJhcm5lcyBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzptYXJ5LmlldGYuYmFybmVzQGdtYWls
LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1hcnkuaWV0Zi5iYXJuZXNAZ21haWwuY29tPC9hPl0NCjxi
cj4NCjxiPkdlc2VuZGV0OjwvYj4gRnJlaXRhZywgMjcuIERlemVtYmVyIDIwMTMgMTk6NDU8L3Nw
YW4+PHU+PC91Pjx1PjwvdT48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
Pjxicj4NCjxiPkFuOjwvYj4gSmVzc2tlLCBSb2xhbmQ8YnI+DQo8Yj5DYzo8L2I+IERJU1BBVENI
OyBHb256YWxvIENhbWFyaWxsbzsgQXRsZSBNb25yYWQ7IERlYW4gV2lsbGlzPGJyPg0KPGI+QmV0
cmVmZjo8L2I+IFJlOiBQUk9UTyBSZXZpZXc6IGRyYWZ0LWRyYWdlLXNpcHBpbmctcmZjMzQ1NWJp
cy0wOS50eHQ8dT48L3U+PHU+PC91PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PHU+PC91Pjx1PjwvdT48L3A+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgUm9sYW5kLDx1PjwvdT48dT48L3U+PC9wPg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzx1PjwvdT48dT48L3U+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzIGZvciBtYWtpbmcgdGhlc2Ug
Y2hhbmdlcy4gSSBmaW5hbGx5IGhhZCBhIGNoYW5jZSB0byByZXZpZXcgdGhpcyB1cGRhdGVkIHZl
cnNpb24uICZuYnNwOyBJIHN0aWxsIGhhdmUgYSBjb3VwbGUgY29tbWVudHMgb24gdGhlIHNlY3Vy
aXR5IHNlY3Rpb24gYXMgSSB0aGluayB5b3Ugd2lsbCBnZXQgcXVlc3Rpb25zIGR1cmluZyBTRUMg
cmV2aWV3IGFyb3VuZCB0aGlzIHVubGVzcyBzb21lIG1vcmUgZGV0YWlsIGlzDQogcHJvdmlkZWQg
b24gc2VjdXJpdHkgdGhyZWF0cyBhbmQgaW1wYWN0cy4gJm5ic3A7IEkndmUgZXh0cmFjdGVkIHRo
ZXNlIGZldyBwb2ludHMgZnJvbSBwcmV2aW91cyByZXZpZXcgY29tbWVudCB0aHJlYWRzLjx1Pjwv
dT48dT48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7
PHU+PC91Pjx1PjwvdT48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5U
aGFua3MsPHU+PC91Pjx1PjwvdT48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj5NYXJ5Ljx1PjwvdT48dT48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+Jm5ic3A7PHU+PC91Pjx1PjwvdT48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj4tLS0tUHJldmlvdXMgcG9pbnQgJm5ic3A7LS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tJmd0Ozx1PjwvdT48dT48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRp
dj4NCjxwcmUgc3R5bGU9IndoaXRlLXNwYWNlOnByZS13cmFwO3dvcmQtd3JhcDpicmVhay13b3Jk
Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z
ZXJpZiZxdW90Oztjb2xvcjojNTAwMDUwIj4tIFNlY3Rpb24gNi4xOiB0aGlzIG5lZWRzIHNvbWUg
dGlnaHRlciB3b3JkaW5nLiAmbmJzcDtXaGF0IGlzIG1lYW50IGJ5ICZxdW90O3BvdGVudGlhbGx5
IGFubm95aW5nJnF1b3Q7ICZuYnNwO2ZvciBleGFtcGxlPyAmbmJzcDs8L3NwYW4+PHU+PC91Pjx1
PjwvdT48L3ByZT4NCjxwcmUgc3R5bGU9IndoaXRlLXNwYWNlOnByZS13cmFwIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90
O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFmNDk3ZCI+Jm5ic3A7PHU+WzwvdT5SSl0gSSBkbyBu
b3Qga25vdy4gVGhpcyBpcyBvcmlnaW5hbCB0ZXh0LiBTbyBJIGRlbGV0ZWQgdGhlIHdvcmRzLjwv
c3Bhbj48dT48L3U+PHU+PC91PjwvcHJlPg0KPHByZSBzdHlsZT0id2hpdGUtc3BhY2U6cHJlLXdy
YXAiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMWY0OTdkIj4tPC9zcGFuPjx1
PjwvdT48dT48L3U+PC9wcmU+DQo8cHJlIHN0eWxlPSJ3aGl0ZS1zcGFjZTpwcmUtd3JhcCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90
OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxZjQ5N2QiPltNQl0gU28sIHlvdSByZW1v
dmVkIHRoYXQgcGFydCBvZiB0aGUgc2VudGVuY2UgYW5kIGFyZSBsZWZ0IHdpdGg6PC9zcGFuPjx1
PjwvdT48dT48L3U+PC9wcmU+DQo8cHJlIHN0eWxlPSJ3aGl0ZS1zcGFjZTpwcmUtd3JhcCI+PHNw
YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm
cXVvdDsiPiZxdW90O1RoaXMgYXR0YWNrIHNob3VsZCBub3QgaGF2ZSBhbnkgc2lnbmlmaWNhbnQg
aW1wYWN0cy4mcXVvdDs8L3NwYW4+PHU+PC91Pjx1PjwvdT48L3ByZT4NCjxwcmUgc3R5bGU9Indo
aXRlLXNwYWNlOnByZS13cmFwIj4NCjx1PjwvdT4mbmJzcDs8dT48L3U+PC9wcmU+DQo8cHJlPiZu
YnNwOzx1PjwvdT48dT48L3U+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90
Oztjb2xvcjojMWY0OTdkIj5JIGRvbid0IHRoaW5rIHRoYXQgYWRkcyBhbnkgdmFsdWUgYW5kIGp1
c3QgYmVncyB0aGUgcXVlc3Rpb24gJnF1b3Q7d2hhdCBhcmUgdGhlIGluc2lnbmlmaWNhbnQgaW1w
YWN0cyBhbmQgYXJlIHRoZXJlIGFueSBwcml2YWN5IGNvbmNlcm5zJnF1b3Q7PyZuYnNwOyBSZWFs
bHksIGl0J3MgdGhlIG5leHQgcGFyYWdyYXBoIHRoYXQgcHJvdmlkZXMgZGV0YWlscyBvZiB0aGUg
aW1wYWN0cy4mbmJzcDsgSSB0aGluayB5b3UgY291bGQgcHJvYmFibHkgcmVtb3ZlIHRoYXQgc2Vu
dGVuY2UgYWx0b2dldGhlciBhbmQgbm90IGxvc2UgYW55dGhpbmcuIDwvc3Bhbj48c3BhbiBzdHls
ZT0iY29sb3I6IzUwMDA1MCI+PGJyPg0KDQo8YnI+PHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wcmU+
DQo8cHJlPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9wcmU+DQo8cHJlPiZuYnNwOzx1PjwvdT48dT48
L3U+PC9wcmU+DQo8cHJlIHN0eWxlPSJ3aGl0ZS1zcGFjZTpwcmUtd3JhcCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz
YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxZjQ5N2QiPlsvTUJdPC9zcGFuPjx1PjwvdT48dT48L3U+
PC9wcmU+DQo8cHJlIHN0eWxlPSJ3aGl0ZS1zcGFjZTpwcmUtd3JhcCI+Jm5ic3A7PHU+PC91Pjx1
PjwvdT48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMjIyMjIy
Ij4tLS0tUHJldmlvdXMgcG9pbnQgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tJmd0
Ozwvc3Bhbj48dT48L3U+PHU+PC91PjwvcHJlPg0KPHByZSBzdHlsZT0id2hpdGUtc3BhY2U6cHJl
LXdyYXAiPiZuYnNwOzx1PjwvdT48dT48L3U+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z
ZXJpZiZxdW90Oztjb2xvcjojMWY0OTdkIj4tJm5ic3A7IDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u
dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj
NTAwMDUwIj5TZWN0aW9uIDYuMjogSSB0aGluayB5b3UgbmVlZCB0byBiZSBtb3JlIHNwZWNpZmlj
IGFib3V0IHRoZSAmcXVvdDtuYXR1cmUmcXVvdDsgdGhhdCBtYWtlcyB0aGlzIGhlYWRlciBub3Qg
b2YgcGFydGljdWxhciBjb25jZXJuIHdpdGggcmVnYXJkcyB0byBzZWN1cml0eS4gRG9lcyBpdCBy
ZXZlYWwgYWRkaXRpb25hbCwgdW5pcXVlIGluZm9ybWF0aW9uIGFib3V0IGFuIGluZGl2aWR1YWwg
dGhhdCBpc24ndCBhdmFpbGFibGUgaW4gb3RoZXIgaGVhZGVycy4gJm5ic3A7QWxzbywgdGhlIDJu
ZCBwYXJhZ3JhcGggbmVlZHMgc29tZSB3b3JrIC0gbWF5YmUgc29tZXRoaW5nIGxpa2U6PC9zcGFu
PjxzcGFuIHN0eWxlPSJjb2xvcjojNTAwMDUwIj48YnI+DQoNCjxicj48dT48L3U+PHU+PC91Pjwv
c3Bhbj48L3ByZT4NCjxwcmU+PHU+PC91PiZuYnNwOzx1PjwvdT48L3ByZT4NCjxwcmU+Jm5ic3A7
PHU+PC91Pjx1PjwvdT48L3ByZT4NCjxwcmUgc3R5bGU9IndoaXRlLXNwYWNlOnByZS13cmFwIj48
c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90Oztjb2xvcjojNTAwMDUwIj5PTEQ6PC9zcGFuPjx1PjwvdT48dT48L3U+PC9wcmU+DQo8
cHJlIHN0eWxlPSJ3aGl0ZS1zcGFjZTpwcmUtd3JhcDt3b3JkLXdyYXA6YnJlYWstd29yZCI+PHU+
PC91PiZuYnNwOzx1PjwvdT48L3ByZT4NCjxwcmU+Jm5ic3A7PHU+PC91Pjx1PjwvdT48L3ByZT4N
CjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOiM1MDAwNTAiPkFuIGVhdmVzZHJvcHBlciBtYXkgY29s
bGVjdCB0aGUgbGlzdCBvZiBpZGVudGl0aWVzIGEgdXNlciBpcyByZWdpc3RlcmVkLiZuYnNwOyBU
aGlzIG1heSBoYXZlIHByaXZhY3kgaW1wbGljYXRpb25zLiZuYnNwOyBUbyBtaXRpZ2F0ZSB0aGlz
IHByb2JsZW0sIHRoaXMgZXh0ZW5zaW9uIFNIT1VMRCBvbmx5IGJlIHVzZWQgaW4gYSBzZWN1cmVk
IGVudmlyb25tZW50LCB3aGVyZSBlbmNyeXB0aW9uIG9mIFNJUCBtZXNzYWdlcyBpcyBwcm92aWRl
ZCBlaXRoZXIgZW5kLXRvLWVuZCBvcjxicj4NCg0KPGJyPjx1PjwvdT48dT48L3U+PC9zcGFuPjwv
cHJlPg0KPHByZT48dT48L3U+Jm5ic3A7PHU+PC91PjwvcHJlPg0KPHByZT4mbmJzcDs8dT48L3U+
PHU+PC91PjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm
cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojNTAwMDUwIj5ob3AtYnktaG9wLiZu
YnNwOzwvc3Bhbj48dT48L3U+PHU+PC91PjwvcHJlPg0KPHByZSBzdHlsZT0id2hpdGUtc3BhY2U6
cHJlLXdyYXAiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx
dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzUwMDA1MCI+TkVXOiZuYnNwOzwvc3Bhbj48dT48
L3U+PHU+PC91PjwvcHJlPg0KPHByZSBzdHlsZT0id2hpdGUtc3BhY2U6cHJlLXdyYXA7d29yZC13
cmFwOmJyZWFrLXdvcmQiPjxzcGFuIHN0eWxlPSJjb2xvcjojNTAwMDUwIj4mbmJzcDs8L3NwYW4+
PHU+PC91Pjx1PjwvdT48L3ByZT4NCjxwcmUgc3R5bGU9IndoaXRlLXNwYWNlOnByZS13cmFwIj48
c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90Oztjb2xvcjojNTAwMDUwIj5BbiBlYXZlc2Ryb3BwZXIgY291bGQgcG9zc2libHkgY29s
bGVjdCB0aGUgbGlzdCBvZiBpZGVudGl0aWVzIGEgdXNlciBpcyByZWdpc3RlcmVkLiZuYnNwOyBU
aGlzIGNhbiBoYXZlIHByaXZhY3kgaW1wbGljYXRpb25zLiZuYnNwOyBUbyBtaXRpZ2F0ZSB0aGlz
IHByb2JsZW0sIHRoaXMgZXh0ZW5zaW9uIE1VU1Qgb25seSBiZSB1c2VkIGluIGEgc2VjdXJlZCBl
bnZpcm9ubWVudCwgd2hlcmUgZW5jcnlwdGlvbiBvZiBTSVAgbWVzc2FnZXMgaXMgcHJvdmlkZWQg
ZWl0aGVyIGVuZC10by1lbmQgb3IgaG9wLWJ5LWhvcC4mbmJzcDs8L3NwYW4+PHU+PC91Pjx1Pjwv
dT48L3ByZT4NCjxwcmUgc3R5bGU9IndoaXRlLXNwYWNlOnByZS13cmFwIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFmNDk3ZCI+LS0tLUVuZCBwcmV2aW91cyBwb2ludCAtLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0mbHQ7PC9zcGFuPjx1PjwvdT48dT48L3U+PC9wcmU+
DQo8cHJlIHN0eWxlPSJ3aGl0ZS1zcGFjZTpwcmUtd3JhcCI+DQo8dT48L3U+Jm5ic3A7PHU+PC91
PjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom
cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFmNDk3ZCI+
W01CXSZuYnNwOyBUaGUgc3VnZ2VzdGVkIGNoYW5nZSBmb3IgdGhlIGZpcnN0IHNlbnRlbmNlIGRp
ZG4ndCBnZXQgaW50byB0aGUgcmV2aXNpb24uJm5ic3A7IEFuZCwgSSBiZWxpZXZlIHlvdSBzdGls
bCBuZWVkIHRvIGlkZW50aWZ5IHByaXZhY3kvc2VjdXJpdHkgaW1wbGljYXRpb25zIGJ5IGFkZHJl
c3Npbmcgd2hldGhlciBvciBub3QgdGhpcyBoZWFkZXIgcmV2ZWFscyBhbnkgdW5pcXVlIGluZm9y
bWF0aW9uIGFib3V0IGFuIGluZGl2aWR1YWwgdGhhdCBpc24ndCBhdmFpbGFibGUgaW4gb3RoZXIg
aGVhZGVycy4mbmJzcDsmbmJzcDsgWy9NQl08L3NwYW4+PHU+PC91Pjx1PjwvdT48L3ByZT4NCjxw
cmUgc3R5bGU9IndoaXRlLXNwYWNlOnByZS13cmFwIj48c3BhbiBzdHlsZT0iY29sb3I6IzUwMDA1
MCI+Jm5ic3A7PC9zcGFuPjx1PjwvdT48dT48L3U+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4t
Ym90dG9tOjEyLjBwdDt3aGl0ZS1zcGFjZTpwcmUtd3JhcCI+Jm5ic3A7PHU+PC91Pjx1PjwvdT48
L3ByZT4NCjxwcmUgc3R5bGU9IndoaXRlLXNwYWNlOnByZS13cmFwIj48c3BhbiBzdHlsZT0iY29s
b3I6IzUwMDA1MCI+Jm5ic3A7PC9zcGFuPjx1PjwvdT48dT48L3U+PC9wcmU+DQo8cHJlIHN0eWxl
PSJtYXJnaW4tYm90dG9tOjEyLjBwdDt3aGl0ZS1zcGFjZTpwcmUtd3JhcCI+Jm5ic3A7PHU+PC91
Pjx1PjwvdT48L3ByZT4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw
Ozx1PjwvdT48dT48L3U+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+Jm5ic3A7PHU+PC91
Pjx1PjwvdT48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVHVlLCBEZWMgMywg
MjAxMyBhdCA3OjAwIEFNLCAmbHQ7PGEgaHJlZj0ibWFpbHRvOlIuSmVzc2tlQHRlbGVrb20uZGUi
IHRhcmdldD0iX2JsYW5rIj5SLkplc3NrZUB0ZWxla29tLmRlPC9hPiZndDsgd3JvdGU6PHU+PC91
Pjx1PjwvdT48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1
b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMWY0OTdkIj5IaSBNYXJ5LDwvc3Bhbj48dT48L3U+
PHU+PC91PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90
O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFmNDk3ZCI+VGhhbmsgeW91IGZvciB5b3VyIGNvbW1l
bnRzIGFuZCBwcm9wb3NhbHMuPC9zcGFuPjx1PjwvdT48dT48L3U+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj
MWY0OTdkIj5JIGhhdmUgbm93IGluY2x1ZGVkIGFsbCBjb21tZW50cyBhbmQgdXBsb2FkZWQgYSBu
ZXcgdmVyc2lvbi48L3NwYW4+PHU+PC91Pjx1PjwvdT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxZjQ5N2Qi
PlNvIHdlIGNhbiBub3cgcHJvY2VlZC48L3NwYW4+PHU+PC91Pjx1PjwvdT48L3A+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx
dW90Oztjb2xvcjojMWY0OTdkIj4mbmJzcDs8L3NwYW4+PHU+PC91Pjx1PjwvdT48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7
O2NvbG9yOiMxZjQ5N2QiPlRoYW5rIHlvdSBhbmQgQmVzdCBSZWdhcmRzPC9zcGFuPjx1PjwvdT48
dT48L3U+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7
c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMWY0OTdkIj4mbmJzcDs8L3NwYW4+PHU+PC91Pjx1Pjwv
dT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z
LXNlcmlmJnF1b3Q7O2NvbG9yOiMxZjQ5N2QiPlJvbGFuZDwvc3Bhbj48dT48L3U+PHU+PC91Pjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDs7Y29sb3I6IzFmNDk3ZCI+Jm5ic3A7PC9zcGFuPjx1PjwvdT48dT48L3U+PC9wPg0K
PC9kaXY+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyI+QSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0
LWRyYWdlLXNpcHBpbmctcmZjMzQ1NWJpcy0xMC50eHQ8L3NwYW4+PHU+PC91Pjx1PjwvdT48L3A+
DQo8cD48c3BhbiBsYW5nPSJFTi1VUyI+aGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBi
eSBSb2xhbmQgSmVzc2tlIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS48L3NwYW4+
PHU+PC91Pjx1PjwvdT48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjx1
PjwvdT48dT48L3U+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiPkZpbGVuYW1lOiZuYnNwOyZu
YnNwOyBkcmFmdC1kcmFnZS1zaXBwaW5nLXJmYzM0NTViaXM8L3NwYW4+PHU+PC91Pjx1PjwvdT48
L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyI+UmV2aXNpb246Jm5ic3A7Jm5ic3A7IDEwPC9zcGFu
Pjx1PjwvdT48dT48L3U+PC9wPg0KPGRpdj4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIj5UaXRsZTom
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsgUHJpdmF0ZSBIZWFkZXIgKFAtSGVhZGVyKSBFeHRlbnNpb25zIHRvIHRoZSBTZXNz
aW9uIEluaXRpYXRpb24gUHJvdG9jb2wgKFNJUCkgZm9yIHRoZSAzcmQtR2VuZXJhdGlvbiBQYXJ0
bmVyc2hpcCBQcm9qZWN0ICgzR1BQKTwvc3Bhbj48dT48L3U+PHU+PC91PjwvcD4NCjwvZGl2Pg0K
PHA+PHNwYW4gbGFuZz0iRU4tVVMiPkNyZWF0aW9uIGRhdGU6Jm5ic3A7Jm5ic3A7Jm5ic3A7IDIw
MTMtMTItMDM8L3NwYW4+PHU+PC91Pjx1PjwvdT48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyI+
R3JvdXA6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7IEluZGl2aWR1YWwgU3VibWlzc2lvbjwvc3Bhbj48dT48L3U+PHU+PC91
PjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIj5OdW1iZXIgb2YgcGFnZXM6IDQ2PC9zcGFuPjx1
PjwvdT48dT48L3U+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiPlVSTDombmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsgPC9zcGFuPjxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2Ry
YWZ0LWRyYWdlLXNpcHBpbmctcmZjMzQ1NWJpcy0xMC50eHQiIHRhcmdldD0iX2JsYW5rIj48c3Bh
biBsYW5nPSJFTi1VUyI+aHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQt
ZHJhZ2Utc2lwcGluZy1yZmMzNDU1YmlzLTEwLnR4dDwvc3Bhbj48L2E+PHU+PC91Pjx1PjwvdT48
L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyI+U3RhdHVzOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+PGEgaHJlZj0iaHR0cDovL2Rh
dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1kcmFnZS1zaXBwaW5nLXJmYzM0NTViaXMiIHRh
cmdldD0iX2JsYW5rIj48c3BhbiBsYW5nPSJFTi1VUyI+aHR0cDovL2RhdGF0cmFja2VyLmlldGYu
b3JnL2RvYy9kcmFmdC1kcmFnZS1zaXBwaW5nLXJmYzM0NTViaXM8L3NwYW4+PC9hPjx1PjwvdT48
dT48L3U+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiPkh0bWxpemVkOiZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+PGEgaHJlZj0iaHR0cDovL3Rvb2xz
LmlldGYub3JnL2h0bWwvZHJhZnQtZHJhZ2Utc2lwcGluZy1yZmMzNDU1YmlzLTEwIiB0YXJnZXQ9
Il9ibGFuayI+PHNwYW4gbGFuZz0iRU4tVVMiPmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry
YWZ0LWRyYWdlLXNpcHBpbmctcmZjMzQ1NWJpcy0xMDwvc3Bhbj48L2E+PHU+PC91Pjx1PjwvdT48
L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyI+RGlmZjombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjxhIGhyZWY9
Imh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWRyYWdlLXNpcHBpbmctcmZj
MzQ1NWJpcy0xMCIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIGxhbmc9IkVOLVVTIj5odHRwOi8vd3d3
LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1kcmFnZS1zaXBwaW5nLXJmYzM0NTViaXMtMTA8
L3NwYW4+PC9hPjx1PjwvdT48dT48L3U+PC9wPg0KPGRpdj4NCjxwPjxzcGFuIGxhbmc9IkVOLVVT
Ij4mbmJzcDs8L3NwYW4+PHU+PC91Pjx1PjwvdT48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyI+
QWJzdHJhY3Q6PC9zcGFuPjx1PjwvdT48dT48L3U+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMi
PiZuYnNwOyZuYnNwOyBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBhIHNldCBvZiBwcml2YXRlIFNl
c3Npb24gSW5pdGlhdGlvbiBQcm90b2NvbDwvc3Bhbj48dT48L3U+PHU+PC91PjwvcD4NCjxwPjxz
cGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsgKFNJUCkgaGVhZGVyIGZpZWxkcyAoUC1oZWFk
ZXJzKSB1c2VkIGJ5IHRoZSAzcmQtR2VuZXJhdGlvbjwvc3Bhbj48dT48L3U+PHU+PC91PjwvcD4N
CjxwPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsgUGFydG5lcnNoaXAgUHJvamVjdCAo
M0dQUCksIGFsb25nIHdpdGggdGhlaXIgYXBwbGljYWJpbGl0eSwgd2hpY2ggaXM8L3NwYW4+PHU+
PC91Pjx1PjwvdT48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7IGxpbWl0
ZWQgdG8gcGFydGljdWxhciBlbnZpcm9ubWVudHMuJm5ic3A7IFRoZSBQLWhlYWRlciBmaWVsZHMg
YXJlIGZvciBhPC9zcGFuPjx1PjwvdT48dT48L3U+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMi
PiZuYnNwOyZuYnNwOyB2YXJpZXR5IG9mIHB1cnBvc2VzIHdpdGhpbiB0aGUgbmV0d29ya3MgdGhh
dCB0aGUgcGFydG5lcnMgdXNlLDwvc3Bhbj48dT48L3U+PHU+PC91PjwvcD4NCjxwPjxzcGFuIGxh
bmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsgaW5jbHVkaW5nIGNoYXJnaW5nIGFuZCBpbmZvcm1hdGlv
biBhYm91dCB0aGUgbmV0d29ya3MgYSBjYWxsPC9zcGFuPjx1PjwvdT48dT48L3U+PC9wPg0KPHA+
PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyA8L3NwYW4+dHJhdmVyc2VzLjx1PjwvdT48
dT48L3U+PC9wPg0KPHA+Jm5ic3A7PHU+PC91Pjx1PjwvdT48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxZjQ5
N2QiPiZuYnNwOzwvc3Bhbj48dT48L3U+PHU+PC91PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom
cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFmNDk3ZCI+
Jm5ic3A7PC9zcGFuPjx1PjwvdT48dT48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJib3Jk
ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNiNWM0ZGYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20g
MGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx
dW90OyI+Vm9uOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBNYXJ5IEJh
cm5lcyBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzptYXJ5LmlldGYuYmFybmVzQGdtYWlsLmNvbSIg
dGFyZ2V0PSJfYmxhbmsiPm1hcnkuaWV0Zi5iYXJuZXNAZ21haWwuY29tPC9hPl0NCjxicj4NCjxi
Pkdlc2VuZGV0OjwvYj4gTW9udGFnLCAyNS4gTm92ZW1iZXIgMjAxMyAyMzowMTwvc3Bhbj48dT48
L3U+PHU+PC91PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8Yj5Bbjo8
L2I+IEplc3NrZSwgUm9sYW5kPGJyPg0KPGI+Q2M6PC9iPiBESVNQQVRDSDsgR29uemFsbyBDYW1h
cmlsbG87IEF0bGUgTW9ucmFkOyBEZWFuIFdpbGxpczx1PjwvdT48dT48L3U+PC9wPg0KPC9kaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5CZXRyZWZmOjwvYj4gUmU6IFBST1RPIFJldmlldzog
ZHJhZnQtZHJhZ2Utc2lwcGluZy1yZmMzNDU1YmlzLTA5LnR4dDx1PjwvdT48dT48L3U+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzx1PjwvdT48
dT48L3U+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIFJvbGFuZCw8dT48L3U+
PHU+PC91PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8dT48L3U+PHU+
PC91PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcyBmb3Ig
eW91ciByZXNwb25zZS4gJm5ic3A7QWRkaXRpb25hbCBjb21tZW50cyBiZWxvdyBbTUJdLjx1Pjwv
dT48dT48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7
PHU+PC91Pjx1PjwvdT48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5U
aGFua3MsPHU+PC91Pjx1PjwvdT48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj5NYXJ5Ljx1PjwvdT48dT48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij4mbmJzcDs8dT48L3U+PHU+PC91
PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUaHUsIE5vdiAyMSwgMjAxMyBh
dCA3OjIxIEFNLCAmbHQ7PGEgaHJlZj0ibWFpbHRvOlIuSmVzc2tlQHRlbGVrb20uZGUiIHRhcmdl
dD0iX2JsYW5rIj5SLkplc3NrZUB0ZWxla29tLmRlPC9hPiZndDsgd3JvdGU6PHU+PC91Pjx1Pjwv
dT48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO
LVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFmNDk3ZCI+SGkgTWFyeSw8L3NwYW4+
PHU+PC91Pjx1PjwvdT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V
UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90
OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxZjQ5N2QiPlRoYW5rIHlvdSBmb3IgeW91
ciByZXZpZXcuPC9zcGFuPjx1PjwvdT48dT48L3U+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMWY0OTdkIj5J
IGhhdmUgYWRkZWQgbm93IHlvdXIgcHJvcG9zYWxzIHRvIHRoZSBkcmFmdC48L3NwYW4+PHU+PC91
Pjx1PjwvdT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv
dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxZjQ5N2QiPk90aGVyIGNvbW1lbnRzIHBsZWFzZSBz
ZWUgYmVsb3cuPC9zcGFuPjx1PjwvdT48dT48L3U+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMWY0OTdkIj4m
bmJzcDs8L3NwYW4+PHU+PC91Pjx1PjwvdT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxZjQ5N2QiPkkgaG9w
ZSBub3cgZXZlcnl0aGluZyBpcyBPSy48L3NwYW4+PHU+PC91Pjx1PjwvdT48L3A+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx
dW90Oztjb2xvcjojMWY0OTdkIj4mbmJzcDs8L3NwYW4+PHU+PC91Pjx1PjwvdT48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7
O2NvbG9yOiMxZjQ5N2QiPlRoYW5rIHlvdSBhbmQgQmVzdCBSZWdhcmRzPC9zcGFuPjx1PjwvdT48
dT48L3U+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7
c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMWY0OTdkIj4mbmJzcDs8L3NwYW4+PHU+PC91Pjx1Pjwv
dT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z
LXNlcmlmJnF1b3Q7O2NvbG9yOiMxZjQ5N2QiPlJvbGFuZDwvc3Bhbj48dT48L3U+PHU+PC91Pjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDs7Y29sb3I6IzFmNDk3ZCI+Jm5ic3A7PC9zcGFuPjx1PjwvdT48dT48L3U+PC9wPg0K
PC9kaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNiNWM0ZGYg
MS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEm
cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Vm9uOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDsiPiBNYXJ5IEJhcm5lcyBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzptYXJ5
LmlldGYuYmFybmVzQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1hcnkuaWV0Zi5iYXJuZXNA
Z21haWwuY29tPC9hPl0NCjxicj4NCjxiPkdlc2VuZGV0OjwvYj4gRGllbnN0YWcsIDI5LiBPa3Rv
YmVyIDIwMTMgMTc6Mjc8YnI+DQo8Yj5Bbjo8L2I+IEplc3NrZSwgUm9sYW5kPGJyPg0KPGI+Q2M6
PC9iPiBESVNQQVRDSDsgR29uemFsbyBDYW1hcmlsbG87IEF0bGUgTW9ucmFkOyBEZWFuIFdpbGxp
czxicj4NCjxiPkJldHJlZmY6PC9iPiBQUk9UTyBSZXZpZXc6IGRyYWZ0LWRyYWdlLXNpcHBpbmct
cmZjMzQ1NWJpcy0wOS50eHQ8L3NwYW4+PHU+PC91Pjx1PjwvdT48L3A+DQo8L2Rpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPiZuYnNwOzx1PjwvdT48dT48L3U+PC9wPg0KPGRpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj5JbiBwcmVwYXJhdGlvbiBmb3IgdGhlIFBST1RPIHdyaXRlLXVw
LCBJIGhhdmUgcmV2aWV3ZWQgdGhlIGRvY3VtZW50IGluIGRldGFpbC4gJm5ic3A7TXkgZGV0YWls
ZWQgcmV2aWV3IHdhcyBvcmlnaW5hbGx5IGJhc2VkIG9uIHRoZSAtMDgsIGJ1dCBJIGFsc28gcmV2
aWV3ZWQgdGhlIDA5IGRpZmYuICZuYnNwO1RoZXJlIGFyZSBhIGZldyBlcnJvcnMgdGhhdCBoYXZl
IGJlZW4gaW50cm9kdWNlZCBpbiB0aGUgLTA5IGFuZCBtYW55IG9mDQogbXkgLTA4IGNvbW1lbnRz
IHJlbWFpbiAtIEkndmUgc2VwYXJhdGVkIGNvbW1lbnRzIGZyb20gbml0cyBiZWxvdy4gJm5ic3A7
QSBudW1iZXIgb2YgdGhlc2UgY29tbWVudHMgYXJlIHdpdGggcmVnYXJkcyB0byB0ZXh0IHRoYXQg
d2FzIG5vdCBjaGFuZ2VkIGZyb20gUkZDIDM0NTUsIGJ1dCBJIHRoaW5rIHNvbWUgb2YgdGhlIHRl
eHQgcmVxdWlyZXMgdXBkYXRpbmcgYW5kIHdlIG5lZWQgdG8ga2VlcCBpbiBtaW5kIHRoYXQgdGhp
cyBhbiBlbnRpcmVseSBuZXcNCiBJRVNHIHRoYXQgd2lsbCBiZSByZXZpZXdpbmcgdGhpcyBkb2N1
bWVudCwgc28gdGhleSB3b24ndCBoYXZlIHRoZSBzYW1lIGNvbnRleHQgb2YgdGhlIElFU0cgdGhh
dCBhcHByb3ZlZCBSRkMgMzQ1NS4gJm5ic3A7SSB3aWxsIG5vdGUgdGhhdCBJIGFsc28gaGF2ZSBu
b3QgdmFsaWRhdGVkIHRoZSBjb250ZW50IG9mIHNlY3Rpb24gOSBhZ2FpbnN0IGEgZGlmZiBvZiB0
aGlzIGRvY3VtZW50IGFuZCBSRkMgMzQ1NS4gJm5ic3A7SSB3aWxsIG5lZWQgdG8gZG8gdGhhdCBi
ZWZvcmUNCiBJIHByb2dyZXNzIHRoZSBkb2N1bWVudCB1bmxlc3MgdGhlIGF1dGhvcnMgY2FuIHBv
aW50IG1lIHRvIGFub3RoZXIgcmV2aWV3IHRoYXQgaGFzIGRvbmUgdGhhdC48dT48L3U+PHU+PC91
PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8dT48L3U+PHU+PC91Pjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJlZ2FyZHMsPHU+PC91Pjx1
PjwvdT48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NYXJ5Ljx1Pjwv
dT48dT48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7
PHU+PC91Pjx1PjwvdT48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj5TdW1tYXJ5OiAmbmJzcDtUaGlzIGRvY3VtZW50IG5lZWRzIHNvbWUgd29y
ayBwcmlvciB0byBiZWluZyBwcm9ncmVzc2VkLiZuYnNwOzx1PjwvdT48dT48L3U+PC9wPg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzx1PjwvdT48dT48L3U+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q29tbWVudHM6PHU+PC91Pjx1PjwvdT48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLS0tLS0tLS0tLS0tLS0tPHU+
PC91Pjx1PjwvdT48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tIFNl
Y3Rpb24gMS4gJm5ic3A7SSB0aGluayB5b3Ugc2hvdWxkIGJlIGV4cGxpY2l0IHRoYXQgdGhlc2Ug
ZXh0ZW5zaW9ucyBhcHBseSBvbmx5IHRvIGEgcHJpdmF0ZSBuZXR3b3JrIC0gc2F5aW5nIHRoZXkg
YXJlICZxdW90O2dlbmVyYWxseSBub3QgYXBwbGljYWJsZSZxdW90OyBpcyB0b28gc29mdCwgc28g
SSB3b3VsZCBzdWdnZXN0IHNvbWUgbWlub3IgcmV3b3JkaW5nIHNvbWV0aGluZyBsaWtlOjx1Pjwv
dT48dT48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T0xEOjx1
PjwvdT48dT48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHByZSBzdHlsZT0id29yZC13cmFwOmJy
ZWFrLXdvcmQ7d2hpdGUtc3BhY2U6cHJlLXdyYXAiPiZuYnNwOyZuYnNwOyBUaGUgU0lQIGV4dGVu
c2lvbnMgc3BlY2lmaWVkIGluIHRoaXMgZG9jdW1lbnQgbWFrZSBjZXJ0YWluPHU+PC91Pjx1Pjwv
dT48L3ByZT4NCjxwcmU+Jm5ic3A7PHU+PC91Pjx1PjwvdT48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5i
c3A7IGFzc3VtcHRpb25zIHJlZ2FyZGluZyBuZXR3b3JrIHRvcG9sb2d5LCBsaW5rYWdlIGJldHdl
ZW4gU0lQIGFuZCBsb3dlcjx1PjwvdT48dT48L3U+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBs
YXllcnMsIGFuZCB0aGUgYXZhaWxhYmlsaXR5IG9mIHRyYW5zaXRpdmUgdHJ1c3QuJm5ic3A7IFRo
ZXNlIGFzc3VtcHRpb25zPHU+PC91Pjx1PjwvdT48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IGFy
ZSBnZW5lcmFsbHkgTk9UIEFQUExJQ0FCTEUgaW4gdGhlIEludGVybmV0IGFzIGEgd2hvbGUuIDx1
PjwvdT48dT48L3U+PC9wcmU+DQo8cHJlIHN0eWxlPSJ3b3JkLXdyYXA6YnJlYWstd29yZDt3aGl0
ZS1zcGFjZTpwcmUtd3JhcCI+Jm5ic3A7PHU+PC91Pjx1PjwvdT48L3ByZT4NCjwvZGl2Pg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TkVXOiZuYnNwOzx1PjwvdT48dT48L3U+
PC9wPg0KPGRpdj4NCjxkaXY+DQo8cHJlIHN0eWxlPSJ3b3JkLXdyYXA6YnJlYWstd29yZDt3aGl0
ZS1zcGFjZTpwcmUtd3JhcCI+Jm5ic3A7PHU+PC91Pjx1PjwvdT48L3ByZT4NCjxwcmU+Jm5ic3A7
Jm5ic3A7IFRoZSBTSVAgZXh0ZW5zaW9ucyBzcGVjaWZpZWQgaW4gdGhpcyBkb2N1bWVudCBtYWtl
IGNlcnRhaW48dT48L3U+PHU+PC91PjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgYXNzdW1wdGlv
bnMgcmVnYXJkaW5nIG5ldHdvcmsgdG9wb2xvZ3ksIGxpbmthZ2UgYmV0d2VlbiBTSVAgYW5kIGxv
d2VyPHU+PC91Pjx1PjwvdT48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IGxheWVycywgYW5kIHRo
ZSBhdmFpbGFiaWxpdHkgb2YgdHJhbnNpdGl2ZSB0cnVzdC4mbmJzcDsgVGhlc2UgYXNzdW1wdGlv
bnM8dT48L3U+PHU+PC91PjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgYXBwbHkgb25seSB0byBw
cml2YXRlIG5ldHdvcmtzIGFuZCBhcmUgbm90IGFwcHJvcHJpYXRlIGZvciB1c2UgaW4gYW4mbmJz
cDtJbnRlcm5ldCBlbnZpcm9ubWVudC48dT48L3U+PHU+PC91PjwvcHJlPg0KPHByZSBzdHlsZT0i
d29yZC13cmFwOmJyZWFrLXdvcmQ7d2hpdGUtc3BhY2U6cHJlLXdyYXAiPiZuYnNwOzx1PjwvdT48
dT48L3U+PC9wcmU+DQo8cHJlIHN0eWxlPSJ3b3JkLXdyYXA6YnJlYWstd29yZCI+DQo8dT48L3U+
Jm5ic3A7PHU+PC91PjwvcHJlPg0KPHByZT4mbmJzcDs8dT48L3U+PHU+PC91PjwvcHJlPg0KPHBy
ZT4mbmJzcDs8dT48L3U+PHU+PC91PjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1mYW1p
bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+LSBTZWN0aW9uIDMu
ICZuYnNwO1RoaXMgc2VjdGlvbiBuZWVkcyB0byBiZSB1cGRhdGVkLiAmbmJzcDtJIGRvbid0IHRo
aW5rIHRoYXQgMTAgeWVhciBvbGQgYmFja2dyb3VuZCBpcyByZWxldmFudCBpbiB0aGUgY3VycmVu
dCBjb250ZXh0LiAmbmJzcDsgWW91IHNob3VsZCBiZSBhYmxlIHRvIG1vZGVsIHRoaXMgYWZ0ZXIg
dGhlIHRleHQgaW4gbW9yZSByZWNlbnQgM0dQUCBQLWhlYWRlciBkb2N1bWVudHMsIHJlZmVycmlu
ZyB0byB0aGUgU0lQIGNoYW5nZSBwcm9jZXNzLiZuYnNwOzwvc3Bhbj48dT48L3U+PHU+PC91Pjwv
cHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv
dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFmNDk3ZCI+Jm5i
c3A7PC9zcGFuPjx1PjwvdT48dT48L3U+PC9wcmU+DQo8L2Rpdj4NCjxwcmU+PHNwYW4gbGFuZz0i
RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMWY0OTdkIj5bUkpdIE9LLCBJIGhh
dmUgY2hhbmdlZCB0aGUgdGV4dDo8L3NwYW4+PHU+PC91Pjx1PjwvdT48L3ByZT4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWF1dG9zcGFjZTpub25lIj48c3BhbiBsYW5nPSJFTi1V
UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90
OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxZjQ5N2QiPlRoZSBUaGlyZCBHZW5lcmF0
aW9uIFBhcnRuZXJzaGlwIFByb2plY3QgKDNHUFApIGhhcyBzZWxlY3RlZCBTSVAgYXM8L3NwYW4+
PHU+PC91Pjx1PjwvdT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hdXRv
c3BhY2U6bm9uZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv
cjojMWY0OTdkIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdGhlIHByb3RvY29sIHVzZWQgdG8g
ZXN0YWJsaXNoIGFuZCB0ZWFyIGRvd24gbXVsdGltZWRpYSBzZXNzaW9ucyBpbiB0aGU8L3NwYW4+
PHU+PC91Pjx1PjwvdT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hdXRv
c3BhY2U6bm9uZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv
cjojMWY0OTdkIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgY29udGV4dCBvZiBpdHMgSVAgTXVs
dGltZWRpYSBTdWJzeXN0ZW0gKElNUykuIEZvciBtb3JlIGluZm9ybWF0aW9uIG9uPC9zcGFuPjx1
PjwvdT48dT48L3U+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYXV0b3Nw
YWNlOm5vbmUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6
IzFmNDk3ZCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRoZSBJTVMsIGEgZGV0YWlsZWQgZGVz
Y3JpcHRpb24gY2FuIGJlIGZvdW5kIGluIDNHUFAgVFMgMjMuMjI4IC4gVGhpcyBkb2N1bWVudCBp
cyBhbiB1cGRhdGUgb2YgUkZDMzQ1NSZuYnNwOyAmbmJzcDt3aGljaA0KIGNvdmVycyB0aGUgcmVx
dWlyZW1lbnRzIGluIFJGQzQwODMgYW5kIGRlc2NyaWJlcyB1cGRhdGVzIGFuZCBhZGRzIHByaXZh
dGUgZXh0ZW5zaW9ucyB0byBhZGRyZXNzIHRob3NlIHJlcXVpcmVtZW50cyB3aGljaCBhcmUgbmVl
ZGVkIGluIGZvciAzR1BQIFJlbGVhc2UgMTEuIEVhY2ggZXh0ZW5zaW9uLCBvciBzZXQgb2YgcmVs
YXRlZCBleHRlbnNpb25zIGlzIGRlc2NyaWJlZCBpbiBpdHMgb3duIHNlY3Rpb24gYmVsb3c8L3Nw
YW4+PHU+PC91Pjx1PjwvdT48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+W01CXSBJIHN1Z2dlc3Qg
anVzdCBhIGJpdCBtb3JlIHJld29yZGluZy4gJm5ic3A7Tm90ZSB0aGF0IEkgZGlkbid0IHNlZSB0
aGF0IHRoaXMgZG9jdW1lbnQgaXMgYWRkaW5nIGFueSBuZXcgaGVhZGVycyZuYnNwOzx1PjwvdT48
dT48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PHU+
PC91Pjx1PjwvdT48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxZjQ5N2QiPiZuYnNw
OyAmbmJzcDsgVGhlIFRoaXJkIEdlbmVyYXRpb24gUGFydG5lcnNoaXAgUHJvamVjdCAoM0dQUCkg
dXNlcyBTSVAgYXM8L3NwYW4+PHU+PC91Pjx1PjwvdT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxZjQ5N2Qi
PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0aGUgcHJvdG9jb2wgJm5ic3A7dG8gZXN0YWJsaXNo
IGFuZCB0ZWFyIGRvd24gbXVsdGltZWRpYSBzZXNzaW9ucyBpbiB0aGU8L3NwYW4+PHU+PC91Pjx1
PjwvdT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz
YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxZjQ5N2QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBj
b250ZXh0IG9mIGl0cyBJUCBNdWx0aW1lZGlhIFN1YnN5c3RlbSAoSU1TKSwgYXMgZGVzY3JpYmVk
IGluJm5ic3A7PC9zcGFuPjx1PjwvdT48dT48L3U+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMWY0OTdkIj4m
bmJzcDsgJm5ic3A7ICZuYnNwO3RoZSAzR1BQIFRTIDIzLjIyOCBzcGVjaWZpY2F0aW9uLiZuYnNw
Ozwvc3Bhbj48dT48L3U+PHU+PC91PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh
bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFmNDk3ZCI+Jm5ic3A7ICZu
YnNwOyAmbmJzcDtSRkMgMzQ1NSBkZWZpbmVzIFNJUCBwcml2YXRlIGhlYWRlciBleHRlbnNpb25z
IChyZWZlcnJlZCB0byBhcyBQLWhlYWRlcnMpIHdoaWNoIGFyZSZuYnNwOzwvc3Bhbj48dT48L3U+
PHU+PC91PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90
O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFmNDk3ZCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDtyZXF1
aXJlZCBieSB0aGUgM0dQUCBzcGVjaWZpY2F0aW9uLiBOb3RlIHRoYXQgdGhlIHJlcXVpcmVtZW50
cyBmb3IgdGhlc2UgZXh0ZW5zaW9uczwvc3Bhbj48dT48L3U+PHU+PC91PjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s
b3I6IzFmNDk3ZCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDthcmUgZG9jdW1lbnRlZCBpbiBSRkMgNDA4
My4gJm5ic3A7Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj
MWY0OTdkIj5UaGlzIGRvY3VtZW50IGlzIGFuIHVwZGF0ZQ0KIHRvIFJGQzM0NTUuJm5ic3A7PC9z
cGFuPjx1PjwvdT48dT48L3U+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i
RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMWY0OTdkIj4mbmJzcDsgJm5ic3A7
ICZuYnNwO1RoaXMgZG9jdW1lbnQgdXBkYXRlcyBleGlzdGluZyBQLWhlYWRlcjwvc3Bhbj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFmNDk3ZCI+Jm5ic3A7ZGVzY3JpcHRpb25z
Jm5ic3A7PC9zcGFuPjx1PjwvdT48dT48L3U+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90
OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxZjQ5N2QiPiZuYnNwOyAmbmJzcDsgJm5i
c3A7dG8gYWRkcmVzcyBhZGRpdGlvbmFsIHJlcXVpcmVtZW50cyB3aGljaCBhcmUgbmVlZGVkIGZv
ciAzR1BQIFJlbGVhc2UgMTEuJm5ic3A7PC9zcGFuPjx1PjwvdT48dT48L3U+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxZjQ5N2Qi
PiZuYnNwOyAmbmJzcDsgJm5ic3A7RWFjaCBvZiB0aGUgUC1oZWFkZXJzIGlzIGRlc2NyaWJlZCBp
biB0aGUgc2VjdGlvbnMgYmVsb3cuPC9zcGFuPjx1PjwvdT48dT48L3U+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PHU+PC91Pjx1PjwvdT48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5bL01CXSZuYnNwOzx1PjwvdT48dT48L3U+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PHU+PC91Pjx1
PjwvdT48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt
bGVmdDpzb2xpZCAjY2NjY2NjIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2lu
LWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0
b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp
dj4NCjxkaXY+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90
OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4tIFNlY3Rpb24gNC4xLiAmcXVvdDtyZWdpc3RlcmVk
IGFkZHJlc3Mtb2YtcmVjb3JkJnF1b3Q7IC0mZ3Q7ICZxdW90O3JlZ2lzdGVyZWQgU0lQIGFkZHJl
c3Mtb2YtcmVjb3JkJnF1b3Q7PC9zcGFuPjx1PjwvdT48dT48L3U+PC9wcmU+DQo8cHJlIHN0eWxl
PSJ3b3JkLXdyYXA6YnJlYWstd29yZCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Fy
aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPi0gU2VjdGlvbiA0LjEsIDNyZCBwYXJh
Z3JhcGguICZuYnNwOyZxdW90O05vdGUgdGhhdCwgZ2VuZXJhbGx5IHNwZWFraW5nLCZxdW90OyAt
Jmd0OyAmcXVvdDtOb3RlIHRoYXQgaW4gc3RhbmRhcmQgU0lQIHVzYWdlIFtSRkMzMjYxXSZxdW90
Ozwvc3Bhbj48dT48L3U+PHU+PC91PjwvcHJlPg0KPHByZSBzdHlsZT0id29yZC13cmFwOmJyZWFr
LXdvcmQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz
YW5zLXNlcmlmJnF1b3Q7Ij4tIFNlY3Rpb24gNC4xLjIuMy4gJm5ic3A7SSBkb24ndCB0aGluayB0
aGlzIGlzIHN0YXRlZCBwcm9wZXJseS4gJm5ic3A7SSB0aGluayB0aGUgaW50ZW50IGlzIHRoYXQg
dGhpcyBoZWFkZXIgaXMgbm90IGFwcGxpY2FibGUgdG8gcHJveGllcywgdGhlcmVmb3JlIHRoZSBw
cm94eSBNVVNUIHJlbGF5IHRoZSBoZWFkZXIgZmllbGQgdW5jaGFuZ2VkLiAmbmJzcDtJIHdvdWxk
IHN1Z2dlc3QgcmV3b3JkaW5nIHNvbWV0aGluZyBsaWtlOjwvc3Bhbj48dT48L3U+PHU+PC91Pjwv
cHJlPg0KPHByZSBzdHlsZT0id29yZC13cmFwOmJyZWFrLXdvcmQiPjxzcGFuIHN0eWxlPSJmb250
LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5PTEQ6Jm5i
c3A7PC9zcGFuPjx1PjwvdT48dT48L3U+PC9wcmU+DQo8cHJlIHN0eWxlPSJ3b3JkLXdyYXA6YnJl
YWstd29yZCI+Jm5ic3A7Jm5ic3A7IFRoaXMgbWVtbyBkb2VzIG5vdCBkZWZpbmUgYW55IHByb2Nl
ZHVyZSBhdCB0aGUgcHJveHkuJm5ic3A7IFRoZSBwcm94eSBkb2VzPHU+PC91Pjx1PjwvdT48L3By
ZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IG5vdCBhZGQsIHJlYWQsIG1vZGlmeSBvciBkZWxldGUgdGhl
IGhlYWRlciBmaWVsZCwgYW5kIHRoZXJlZm9yZSBhbnk8dT48L3U+PHU+PC91PjwvcHJlPg0KPHBy
ZT4mbmJzcDsmbmJzcDsgcHJveHkgd2lsbCByZWxheSB0aGlzIGhlYWRlciBmaWVsZCB1bmNoYW5n
ZWQuPHU+PC91Pjx1PjwvdT48L3ByZT4NCjxwcmUgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3Jk
Ij4mbmJzcDs8dT48L3U+PHU+PC91PjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1mYW1p
bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+TkVXOjwvc3Bhbj48
dT48L3U+PHU+PC91PjwvcHJlPg0KPHByZSBzdHlsZT0id29yZC13cmFwOmJyZWFrLXdvcmQiPiZu
YnNwOzx1PjwvdT48dT48L3U+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBUaGlzIGhlYWRlciBp
cyBub3QgaW50ZW5kZWQgdG8gYmUgdXNlZCBieSBwcm94aWVzIC0gYSBwcm94eSBkb2VzPHU+PC91
Pjx1PjwvdT48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IG5vdCBhZGQsIHJlYWQsIG1vZGlmeSBv
ciBkZWxldGUgdGhlIGhlYWRlciBmaWVsZCwgYW5kIHRoZXJlZm9yZSBhbnk8dT48L3U+PHU+PC91
PjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgcHJveHkgTVVTVCByZWxheSB0aGlzIGhlYWRlciBm
aWVsZCB1bmNoYW5nZWQuPHU+PC91Pjx1PjwvdT48L3ByZT4NCjxwcmUgc3R5bGU9IndvcmQtd3Jh
cDpicmVhay13b3JkO3doaXRlLXNwYWNlOnByZS13cmFwIj4NCjx1PjwvdT4mbmJzcDs8dT48L3U+
PC9wcmU+DQo8cHJlPiZuYnNwOzx1PjwvdT48dT48L3U+PC9wcmU+DQo8cHJlPiZuYnNwOzx1Pjwv
dT48dT48L3U+PC9wcmU+DQo8cHJlPiZuYnNwOzx1PjwvdT48dT48L3U+PC9wcmU+DQo8cHJlPjxz
cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm
JnF1b3Q7O2NvbG9yOiMyMjIyMjIiPlNlY3Rpb24gNC4yLCAxc3QgcGFyYWdyYXBoLiAmbmJzcDtU
aGUgYmVoYXZpb3IgaW4gdGhpcyBzZW50ZW5jZSBpcyBub3Qgbm9ybWF0aXZlIGZyb20gYSBTSVAg
cHJvdG9jb2wgcGVyc3BlY3RpdmUsIHRodXMgTUFZIGlzIG5vdCBhcHByb3ByaWF0ZS4gJm5ic3A7
SSBzdWdnZXN0IHRoZSBNQVkgYmUgY2hhbmdlZCB0byAmcXVvdDtjYW4mcXVvdDsuICZuYnNwOyZu
YnNwOzwvc3Bhbj48dT48L3U+PHU+PC91PjwvcHJlPg0KPHByZSBzdHlsZT0id29yZC13cmFwOmJy
ZWFrLXdvcmQ7d2hpdGUtc3BhY2U6cHJlLXdyYXAiPiZuYnNwOyZuYnNwOyBUaGUgVUFTIE1BWSB1
c2UgdGhlIGluZm9ybWF0aW9uIHRvIHJlbmRlciBkaWZmZXJlbnQgZGlzdGluY3RpdmUgYXVkaW92
aXN1YWwgYWxlcnRpbmc8dT48L3U+PHU+PC91PjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgdG9u
ZXMsIGRlcGVuZGluZyBvbiB0aGUgVVJJIHVzZWQgdG8gcmVjZWl2ZSB0aGUgaW52aXRhdGlvbiB0
byB0aGU8dT48L3U+PHU+PC91PjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgc2Vzc2lvbi48dT48
L3U+PHU+PC91PjwvcHJlPg0KPHByZSBzdHlsZT0id29yZC13cmFwOmJyZWFrLXdvcmQiPjxzcGFu
IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1
b3Q7O2NvbG9yOiMyMjIyMjIiPlNlY3Rpb24gNC4yLjIuMiwgMm5kIHBhcmFncmFwaC4gJm5ic3A7
VGhlIGJlaGF2aW9yIGluIHRoaXMgc2VudGVuY2UgaXMgbm90IG5vcm1hdGl2ZSBmcm9tIGEgU0lQ
IHByb3RvY29sIHBlcnNwZWN0aXZlLCB0aHVzICZuYnNwO0kgc3VnZ2VzdCB0aGUgTUFZIGJlIGNo
YW5nZWQgdG8gJnF1b3Q7Y2FuJnF1b3Q7LiZuYnNwOzwvc3Bhbj48dT48L3U+PHU+PC91PjwvcHJl
Pg0KPHByZT4mbmJzcDs8dT48L3U+PHU+PC91PjwvcHJlPg0KPHByZSBzdHlsZT0id29yZC13cmFw
OmJyZWFrLXdvcmQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm
cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4tIFNlY3Rpb24gNC4zLjMsIGxhc3QgcGFyYWdyYXBoLiAm
bmJzcDtJIHRoaW5rIHRoaXMgb3VnaHQgdG8gYmUgYSBNVVNUOiAmcXVvdDtUaGUgaWRlbnRpZmll
ciBzaG91bGQgYmUgZ2xvYmFsbHkgdW5pcXVlLi4mcXVvdDsmbmJzcDs8L3NwYW4+PHU+PC91Pjx1
PjwvdT48L3ByZT4NCjxwcmU+Jm5ic3A7PHU+PC91Pjx1PjwvdT48L3ByZT4NCjxwcmUgc3R5bGU9
IndvcmQtd3JhcDpicmVhay13b3JkIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJp
YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+LSBTZWN0aW9uIDQuMy4yLjEuICZuYnNw
O1RoaXMgdGV4dCBoYXMgY2hhbmdlZCBmcm9tIHRoZSAtMDguICZuYnNwOyBJIGRvbid0IGtub3cg
d2hhdCBhICZxdW90O25vcm1hbCBVc2VyIEVxdWlwbWVudCZxdW90OyBpcyBhbmQgdGhlIHRlcm0g
JnF1b3Q7VXNlciBFcXVpcG1lbnQmcXVvdDsgaXMgbm90IGRlZmluZWQgaW4gdGhpcyBzcGVjaWZp
Y2F0aW9uLiAmbmJzcDtJIHRoaW5rIGl0IHdvdWxkIGJlIGJldHRlciB0byBzYXkgc29tZXRoaW5n
IGxpa2UuIEhvd2V2ZXIsIGV2ZW4gd2l0aCB0aGlzIHByb3Bvc2VkIGNoYW5nZSwgSSB0aGluayB5
b3UgYWxzbyBuZWVkIHRleHQgZm9yIHVzZXIgYWdlbnQgc2VydmVyIGJlaGF2aW9yIC0gaS5lLiwg
d2hhdCB3b3VsZCBhIFVBUyBkbyBpZiBpdCByZWNlaXZlZCB0aGlzIGhlYWRlci4mbmJzcDs8L3Nw
YW4+PHU+PC91Pjx1PjwvdT48L3ByZT4NCjxwcmU+Jm5ic3A7PHU+PC91Pjx1PjwvdT48L3ByZT4N
CjxwcmUgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3JkIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p
bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+T0xEOjwvc3Bhbj48
dT48L3U+PHU+PC91PjwvcHJlPg0KPHByZSBzdHlsZT0id29yZC13cmFwOmJyZWFrLXdvcmQ7d2hp
dGUtc3BhY2U6cHJlLXdyYXAiPiZuYnNwOyZuYnNwOyBBIG5vcm1hbCBVc2VyIEVxdWlwbWVudCBo
YXMgbm9ybWFsbHkgbm8ga25vd2xlZGdlIG9mIHRoZSBQLVZpc2l0ZWQtPHU+PC91Pjx1PjwvdT48
L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IE5ldHdvcmstSUQgd2hlbiBzZW5kaW5nIHRoZSBSRUdJ
U1RFUi4mbmJzcDsgVGhlcmVmb3JlIHVzZXIgYWdlbnQgY2xpZW50czx1PjwvdT48dT48L3U+PC9w
cmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBkbyBub3QgaW5zZXJ0IGEgUC1WaXNpdGVkLU5ldHdvcmst
SUQgaGVhZGVyIGZpZWxkIGluIGFueSBTSVAgbWVzc2FnZS48dT48L3U+PHU+PC91PjwvcHJlPg0K
PHByZSBzdHlsZT0id29yZC13cmFwOmJyZWFrLXdvcmQiPg0KPHU+PC91PiZuYnNwOzx1PjwvdT48
L3ByZT4NCjxwcmU+Jm5ic3A7PHU+PC91Pjx1PjwvdT48L3ByZT4NCjxwcmU+Jm5ic3A7PHU+PC91
Pjx1PjwvdT48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFs
JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPk5FVzombmJzcDs8L3NwYW4+PHU+PC91Pjx1
PjwvdT48L3ByZT4NCjxwcmUgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3JkIj4mbmJzcDsmbmJz
cDsgSW4gdGhlIGNvbnRleHQgb2YgdGhlIG5ldHdvcmsgdG8gd2hpY2ggdGhlIGhlYWRlciBmaWVs
ZHMgZGVmaW5lZCBpbiB0aGlzIGRvY3VtZW50IGFwcGx5LCBhIFVzZXIgQWdlbnQgaGFzJm5ic3A7
bm8ga25vd2xlZGdlIG9mIHRoZSBQLVZpc2l0ZWQtTmV0d29yay1JRCB3aGVuIHNlbmRpbmcgdGhl
IFJFR0lTVEVSIHJlcXVlc3QuICZuYnNwO1RoZXJlZm9yZSB1c2VyIGFnZW50IGNsaWVudHMgTVVT
VCBOT1QgaW5zZXJ0IGEgUC1WaXNpdGVkLU5ldHdvcmstSUQmbmJzcDtoZWFkZXIgZmllbGQmbmJz
cDtpbiBhbnkgU0lQIG1lc3NhZ2UuPHU+PC91Pjx1PjwvdT48L3ByZT4NCjxwcmU+Jm5ic3A7PHU+
PC91Pjx1PjwvdT48L3ByZT4NCjxwcmUgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3JkIj48c3Bh
biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx
dW90OyI+LSBTZWN0aW9uIDxhIGhyZWY9Imh0dHA6Ly80LjMuMi4yIiB0YXJnZXQ9Il9ibGFuayI+
NC4zLjIuMjwvYT46LCAybmQgcGFyYWdyYXBoOiAmbmJzcDsmcXVvdDtob21lIG5ldHdvcmsgTUFZ
IHVzZSZxdW90OyAtJmd0OyAmcXVvdDtob21lIG5ldHdvcmsgY2FuIHVzZSZxdW90Ozwvc3Bhbj48
YnI+DQoNCjxicj48dT48L3U+PHU+PC91PjwvcHJlPg0KPHByZT48dT48L3U+Jm5ic3A7PHU+PC91
PjwvcHJlPg0KPHByZT4mbmJzcDs8dT48L3U+PHU+PC91PjwvcHJlPg0KPHByZT4mbmJzcDs8dT48
L3U+PHU+PC91PjwvcHJlPg0KPHByZT4mbmJzcDs8dT48L3U+PHU+PC91PjwvcHJlPg0KPHByZSBz
dHlsZT0id29yZC13cmFwOmJyZWFrLXdvcmQ7d2hpdGUtc3BhY2U6cHJlLXdyYXAiPjxzcGFuIHN0
eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7
Ij4tIFNlY3Rpb24gNC4zLjIuMiwgbGFzdCBwYXJhZ3JhcGg6ICZuYnNwOzwvc3Bhbj48dT48L3U+
PHU+PC91PjwvcHJlPg0KPHByZSBzdHlsZT0id29yZC13cmFwOmJyZWFrLXdvcmQ7d2hpdGUtc3Bh
Y2U6cHJlLXdyYXAiPiZuYnNwOzx1PjwvdT48dT48L3U+PC9wcmU+DQo8cHJlPiZuYnNwOzx1Pjwv
dT48dT48L3U+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlh
bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5PTEQ6PC9zcGFuPiBOb3RlIHRoYXQgYSBy
ZWNlaXZlZCBQLVZpc2l0ZWQtTmV0d29yay1JRCBmcm9tIGEgVUEgaXMgYSBmYWlsdXJlIGNhc2Ug
YW5kIG11c3QgYmUgZGVsZXRlZC48dT48L3U+PHU+PC91PjwvcHJlPg0KPHByZSBzdHlsZT0id29y
ZC13cmFwOmJyZWFrLXdvcmQ7d2hpdGUtc3BhY2U6cHJlLXdyYXAiPiZuYnNwOzx1PjwvdT48dT48
L3U+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90
OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5ORVc6ICZuYnNwOzwvc3Bhbj5Ob3RlIHRoYXQgYSBy
ZWNlaXZlZCBQLVZpc2l0ZWQtTmV0d29yay1JRCBmcm9tIGEgVUEgaXMgYSBmYWlsdXJlIGNhc2Ug
YW5kIE1VU1QgYmUgZGVsZXRlZCB3aGVuIHRoZSByZXF1ZXN0IGlzIGZvcndhcmRlZC4gPHU+PC91
Pjx1PjwvdT48L3ByZT4NCjxwcmUgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3JkO3doaXRlLXNw
YWNlOnByZS13cmFwIj4mbmJzcDs8dT48L3U+PHU+PC91PjwvcHJlPg0KPHByZT48c3BhbiBzdHls
ZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj
b2xvcjojMjIyMjIyIj5TZWN0aW9uIDQuNC4yLjEsIDJuZCBwYXJhZ3JhcGg6ICZuYnNwOyZxdW90
O01VU1QgdHJ1c3QgdGhlIHByb3h5JnF1b3Q7IC0mZ3Q7ICZxdW90O01VU1QgaGF2ZSBhIHRydXN0
IHJlbGF0aW9uc2hpcCB3aXRoIHRoZSBwcm94eSZxdW90OyZuYnNwOzwvc3Bhbj48dT48L3U+PHU+
PC91PjwvcHJlPg0KPHByZSBzdHlsZT0id29yZC13cmFwOmJyZWFrLXdvcmQ7d2hpdGUtc3BhY2U6
cHJlLXdyYXAiPiZuYnNwOzx1PjwvdT48dT48L3U+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJm
b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y
OiMyMjIyMjIiPlNlY3Rpb24gNC40LjIuMSwgM3JkIHBhcmFncmFwaDogJm5ic3A7JnF1b3Q7dGhl
cmUgbXVzdCBhbHNvIGJlIGEgdHJhbnNpdGl2ZSB0cnVzdCZxdW90OyAtJmd0OyAmbmJzcDsmcXVv
dDt0aGVyZSBNVVNUIGFsc28gYmUgYSB0cmFuc2l0aXZlIHRydXN0JnF1b3Q7Jm5ic3A7PC9zcGFu
Pjx1PjwvdT48dT48L3U+PC9wcmU+DQo8cHJlIHN0eWxlPSJ3b3JkLXdyYXA6YnJlYWstd29yZCI+
PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDs7Y29sb3I6IzIyMjIyMiI+U2VjdGlvbiA0LjQuMi4yLCAybmQgcGFyYWdyYXBoOiAm
cXVvdDtNQVkgYWN0IHVwb24gYW55IGluZm9ybWF0aW9uIHByZXNlbnQmcXVvdDsgLSZndDsgJnF1
b3Q7Y2FuIGFjdCB1cG9uIGFueSBpbmZvcm1hdGlvbiBwcmVzZW50JnF1b3Q7LCAmbmJzcDsmcXVv
dDtNQVkgdXNlIHRoZSBjYWxsIGlkJnF1b3Q7IC0mZ3Q7ICZxdW90O2NhbiB1c2UgdGhlJm5ic3A7
PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz
YW5zLXNlcmlmJnF1b3Q7Ij5jYWxsIGlkJnF1b3Q7Jm5ic3A7PC9zcGFuPjx1PjwvdT48dT48L3U+
PC9wcmU+DQo8cHJlIHN0eWxlPSJ3b3JkLXdyYXA6YnJlYWstd29yZCI+PHNwYW4gc3R5bGU9ImZv
bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlNlY3Rp
b24gNC41LjI6IDJuZCBwYXJhZ3JhcGg6ICZxdW90O01BWSB1c2UgdGhlIGhvc3RuYW1lcyZxdW90
OyAtJmd0OyAmcXVvdDtjYW4gdXNlIHRoZSBob3N0bmFtZXMmcXVvdDsmbmJzcDs8L3NwYW4+PHU+
PC91Pjx1PjwvdT48L3ByZT4NCjxwcmUgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3JkIj4mbmJz
cDs8dT48L3U+PHU+PC91PjwvcHJlPg0KPHByZT4mbmJzcDs8dT48L3U+PHU+PC91PjwvcHJlPg0K
PHByZT4mbmJzcDs8dT48L3U+PHU+PC91PjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1m
YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+U2VjdGlvbiA0
LjUuMi4xIDJuZCBwYXJhZ3JhcGg6ICZxdW90O01BWSB1c2UgdGhlIGNvbnRlbnRzJnF1b3Q7IC0m
Z3Q7ICZxdW90O2NhbiB1c2UgdGhlJm5ic3A7Y29udGVudHMmcXVvdDsmbmJzcDs8L3NwYW4+PHU+
PC91Pjx1PjwvdT48L3ByZT4NCjwvZGl2Pg0KPC9kaXY+DQo8cHJlIHN0eWxlPSJ3b3JkLXdyYXA6
YnJlYWstd29yZCI+Jm5ic3A7PHU+PC91Pjx1PjwvdT48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9
ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPi0g
U2VjdGlvbiA0LjYuMiwgM3JkIHBhcmFncmFwaDogJnF1b3Q7TUFZIHVzZSB0aGUgdmFsdWVzJnF1
b3Q7IC0mZ3Q7ICZxdW90O2NhbiB1c2UgdGhlIHZhbHVlcyZxdW90OyZuYnNwOzwvc3Bhbj48dT48
L3U+PHU+PC91PjwvcHJlPg0KPGRpdj4NCjxwcmUgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3Jk
Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z
ZXJpZiZxdW90OyI+LSBTZWN0aW9uIDQuNi4zLCAzcmQgcGFyYWdyYXBoOiBuZWVkcyBzb21lIGVk
aXRvcmlhbCB3b3JrLiAmbmJzcDtNYXliZSB0aGUgZm9sbG93aW5nIGNoYW5nZSB3b3VsZCB3b3Jr
OiZuYnNwOzwvc3Bhbj48dT48L3U+PHU+PC91PjwvcHJlPg0KPHByZSBzdHlsZT0id29yZC13cmFw
OmJyZWFrLXdvcmQiPiZuYnNwOzx1PjwvdT48dT48L3U+PC9wcmU+DQo8cHJlPiZuYnNwOzx1Pjwv
dT48dT48L3U+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlh
bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5PTEQ6PC9zcGFuPjx1PjwvdT48dT48L3U+
PC9wcmU+DQo8cHJlIHN0eWxlPSJ3b3JkLXdyYXA6YnJlYWstd29yZDt3aGl0ZS1zcGFjZTpwcmUt
d3JhcCI+DQo8dT48L3U+Jm5ic3A7PHU+PC91PjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgRGVw
ZW5kaW5nIG9uIHRoZSBjYWxsIHNjZW5hcmlvIGl0IGlzIG5lZWRlZCB0byBhZGQgZm9yIGVhY2gg
dHJhbnNpdDx1PjwvdT48dT48L3U+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBuZXR3b3JrIGVp
dGhlciBhIHRyYW5zaXQgbmV0d29yayBuYW1lIG9yIGEgdm9pZCB2YWx1ZS4gJm5ic3A7TmV2ZXJ0
aGVsZXNzPHU+PC91Pjx1PjwvdT48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IGl0IGNhbiBub3Qg
YmUgZ3VhcmFudGVlZCB0aGF0IGFsbCB2YWx1ZXMgd2lsbCBhcHBlYXIgd2l0aGluIHRoZSBQLUNo
YXJnaW5nLVZlY3RvciBoZWFkZXIgZmllbGQuJm5ic3A7PHU+PC91Pjx1PjwvdT48L3ByZT4NCjxw
cmUgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3JkIj4mbmJzcDs8dT48L3U+PHU+PC91PjwvcHJl
Pg0KPHByZT4mbmJzcDs8dT48L3U+PHU+PC91PjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9u
dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+TkVXOiZu
YnNwOzwvc3Bhbj48dT48L3U+PHU+PC91PjwvcHJlPg0KPHByZSBzdHlsZT0id29yZC13cmFwOmJy
ZWFrLXdvcmQiPiZuYnNwOzx1PjwvdT48dT48L3U+PC9wcmU+DQo8cHJlIHN0eWxlPSJ3b3JkLXdy
YXA6YnJlYWstd29yZDt3aGl0ZS1zcGFjZTpwcmUtd3JhcCI+Jm5ic3A7Jm5ic3A7IERlcGVuZGlu
ZyBvbiB0aGUgY2FsbCBzY2VuYXJpbywgZWFjaCB0cmFuc2l0IG5ldHdvcmsgY2FuIGFkZCBlaXRo
ZXIgYSB0cmFuc2l0IG5ldHdvcmsgbmFtZSZuYnNwO29yIGEgdm9pZCZuYnNwOyZuYnNwOyZuYnNw
OyB2YWx1ZS4mbmJzcDsgSG93ZXZlciwgaXQgY2FuIG5vdCBiZSBndWFyYW50ZWVkIHRoYXQgYWxs
IHRoZSB2YWx1ZXMgdGhhdCBhcmUgYWRkZWQgd2lsbCBhcHBlYXIgd2l0aGluIHRoZSBQLUNoYXJn
aW5nLVZlY3RvciBoZWFkZXIgZmllbGQuPHU+PC91Pjx1PjwvdT48L3ByZT4NCjxwcmU+Jm5ic3A7
PHU+PC91Pjx1PjwvdT48L3ByZT4NCjxwcmUgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3JkIj48
c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90Oztjb2xvcjojMjIyMjIyIj4tIFNlY3Rpb24gNC42LjMsIG5leHQgdG8gbGFzdCBwYXJh
Z3JhcGg6Jm5ic3A7JnF1b3Q7d2hpY2ggbmVlZHMgdG8gYmUgaW5jcmVtZW50ZWQmcXVvdDsgLSZn
dDsgJnF1b3Q7d2hpY2ggTVVTVCBiZSBpbmNyZW1lbnRlZCZxdW90Ozwvc3Bhbj48dT48L3U+PHU+
PC91PjwvcHJlPg0KPHByZT4mbmJzcDs8dT48L3U+PHU+PC91PjwvcHJlPg0KPHByZSBzdHlsZT0i
d2hpdGUtc3BhY2U6cHJlLXdyYXA7d29yZC13cmFwOmJyZWFrLXdvcmQiPjxzcGFuIHN0eWxlPSJm
b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y
OiMyMjIyMjIiPi0gU2VjdGlvbiA0LjYuMywgbGFzdCBwYXJhZ3JhcGguICZuYnNwO0kgaGF2ZSBu
byBpZGVhIHdoYXQgdGhhdCBpcyB0cnlpbmcgdG8gc2F5IG90aGVyIHRoYW4gdm9pZCB2YWx1ZXMg
aGF2ZSBubyBpbmRleC4gJm5ic3A7V2hhdCBkb2VzICZxdW90O3Rha2VuIGludG8gY29uc2lkZXJh
dGlvbiZxdW90OyBtZWFuLiBBcmUgeW91IHRhbGtpbmcgYWJvdXQgbGltaXRzIG9uIHRoZSBudW1i
ZXIgb2YgZW50cmllcyBvciBhcmUgeW91IHN1Z2dlc3RpbmcgdGhhdCB0aGUgbnVtYmVyIG9mIHZv
aWQgdmFsdWVzIG11c3QgYmUgY29uc2lkZXJlZCB3aGVuIHNldHRpbmcgdGhlIGluZGV4IGZvciB0
aGUgdHJhbnNpdCBuZXR3b3JrIG5hbWVzPyAmbmJzcDs8L3NwYW4+PHU+PC91Pjx1PjwvdT48L3By
ZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxZjQ5N2QiPiZuYnNw
Ozwvc3Bhbj48dT48L3U+PHU+PC91PjwvcHJlPg0KPC9kaXY+DQo8cHJlPjxzcGFuIGxhbmc9IkVO
LVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFmNDk3ZCI+W1JKXSBZZXMhIENoYW5n
ZWQgdGhlIHRleHQgdG86PC9zcGFuPjx1PjwvdT48dT48L3U+PC9wcmU+DQo8cHJlPjxzcGFuIGxh
bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFmNDk3ZCI+Jm5ic3A7PC9z
cGFuPjx1PjwvdT48dT48L3U+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i
YmFja2dyb3VuZDp3aGl0ZSI+QSB2b2lkIHZhbHVlIGhhcyBubyBpbmRleC4gQnkgYWRkaW5nIHRo
ZSBuZXh0IHZhbHVlIHRoZSBpbmRleCBoYXMgdG8gYmUgaW5jcmVtZW50ZWQgYnkgdGhlIG51bWJl
ciBvZiB2b2lkIGVudHJpZXMgJiM0MzsxLjwvc3Bhbj48dT48L3U+PHU+PC91PjwvcHJlPg0KPGRp
dj4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj
MWY0OTdkIj4mbmJzcDs8L3NwYW4+PHU+PC91Pjx1PjwvdT48L3ByZT4NCjxwcmUgc3R5bGU9Indv
cmQtd3JhcDpicmVhay13b3JkIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5
OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzIyMjIyMiI+
LSBTZWN0aW9uIDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv
dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMjIyMjIyIj48YSBocmVmPSJodHRwOi8v
NC42LjQuMiIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIGxhbmc9IkVOLVVTIj40LjYuNC4yPC9zcGFu
PjwvYT48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtB
cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMyMjIyMjIiPjogSSBkb24n
dCBrbm93IHdoYXQgdGhpcyBtZWFuczombmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0
eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7
Ij4mbmJzcDsmcXVvdDtBIGRlbGV0aW9uIG9mIHRoZSBlbGVtZW50cyBjb3VsZCBhcHBlYXIgZGVw
ZW5kaW5nIG9uIHRoZSBuZXR3b3JrIHBvbGljeSBhbmQgdHJ1c3QgcnVsZXMmcXVvdDsuICZuYnNw
Ozwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7
c2Fucy1zZXJpZiZxdW90OyI+SXMgaXQganVzdCB0cnlpbmcgdG8gc2F5IHRoYXQgYWxvbmcgd2l0
aCB0aGUgYWRkaW5nIGFuZCBtb2RpZnlpbmcgaW4gdGhlIHByZXZpb3VzIHNlbnRlbmNlIHRoYXQg
dGhlIGVsZW1lbnRzIGNhbiBhbHNvIGJlIGRlbGV0ZWQgYnkgdGhlIHByb3h5PyZuYnNwOzwvc3Bh
bj48dT48L3U+PHU+PC91PjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7
Y29sb3I6IzFmNDk3ZCI+Jm5ic3A7PC9zcGFuPjx1PjwvdT48dT48L3U+PC9wcmU+DQo8L2Rpdj4N
CjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMWY0
OTdkIj5bUkpdIFllcywgSSBoYXZlIGNoYW5nZWQgdGhlIHRleHQ6PC9zcGFuPjx1PjwvdT48dT48
L3U+PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hdXRvc3BhY2U6bm9u
ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMWY0OTdk
Ij5Qcm9jZWR1cmVzIGRlc2NyaWJlZCB3aXRoaW4gNC42LjIuMiBhcHBseS4gQSB0cmFuc2l0LWlv
aSBNQVkgYmU8L3NwYW4+PHU+PC91Pjx1PjwvdT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0idGV4dC1hdXRvc3BhY2U6bm9uZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z
ZXJpZiZxdW90Oztjb2xvcjojMWY0OTdkIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYWRkZWQgb3IgbW9kaWZpZWQgYnkgYSBwcm94
eS4gQSBkZWxldGlvbiBvZiB0aGUgdHJhbnNpdC1pb2kgb3IgYSBlbnRyeSB3aXRoaW4gdGhlIHRy
YW5pc3QtaW9pIGNvdWxkPC9zcGFuPjx1PjwvdT48dT48L3U+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9InRleHQtYXV0b3NwYWNlOm5vbmUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90
O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFmNDk3ZCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFwcGVhciBkZXBlbmRpbmcgb24g
dGhlIG5ldHdvcmsgcG9saWN5IGFuZCB0cnVzdCBydWxlcy4gVGhpcyBpczwvc3Bhbj48dT48L3U+
PHU+PC91PjwvcD4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90
Oztjb2xvcjojMWY0OTdkIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsgYWxzbyB2YWxpZCBieSByZXBsYWNpbmcgdGhlIHRyYW5zaXQt
aW9pIHdpdGggYSB2b2lkIHZhbHVlLjwvc3Bhbj48dT48L3U+PHU+PC91PjwvcHJlPg0KPGRpdj4N
CjxwcmU+DQo8dT48L3U+Jm5ic3A7PHU+PC91PjwvcHJlPg0KPHByZT4mbmJzcDs8dT48L3U+PHU+
PC91PjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7
O2NvbG9yOiMxZjQ5N2QiPiZuYnNwOzwvc3Bhbj48dT48L3U+PHU+PC91PjwvcHJlPg0KPHByZT48
c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjx1PjwvdT48dT48L3U+PC9wcmU+DQo8cHJl
IHN0eWxlPSJ3b3JkLXdyYXA6YnJlYWstd29yZCI+PHU+PC91PiZuYnNwOzx1PjwvdT48L3ByZT4N
CjxwcmU+Jm5ic3A7PHU+PC91Pjx1PjwvdT48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQt
ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPi0gU2VjdGlv
biA1LjcuIERlbGV0ZSB0aGlzIHRleHQgYW5kIHRhYmxlLiAmbmJzcDsgV2UgYXJlbid0IHRoZXNl
IHRhYmxlcyBhbnltb3JlIGFzIHRoZXkgcmVhbGx5IGRvbid0IHByb3ZpZGUgYW55IHVzZWZ1bCBp
bmZvcm1hdGlvbi4gJm5ic3A7WW91IGp1c3QgbmVlZCB0byB2ZXJiYWxseSBzdGF0ZSB3aGF0IG1l
c3NhZ2VzIHRoZXNlIGhlYWRlcnMgY2FuIGFwcGVhciBpbi4mbmJzcDs8L3NwYW4+PHU+PC91Pjx1
PjwvdT48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxZjQ5
N2QiPiZuYnNwOzwvc3Bhbj48dT48L3U+PHU+PC91PjwvcHJlPg0KPC9kaXY+DQo8cHJlPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss
JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMWY0OTdkIj5bUkpdIE9LPC9zcGFuPjx1Pjwv
dT48dT48L3U+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj
MWY0OTdkIj4mbmJzcDs8L3NwYW4+PHU+PC91Pjx1PjwvdT48L3ByZT4NCjxwcmU+PHNwYW4gbGFu
Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMWY0OTdkIj5TbyBJIGNoYW5n
ZWQgNS43IHRvIOKAnE5ldyBoZWFkZXLigJ08L3NwYW4+PHU+PC91Pjx1PjwvdT48L3ByZT4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWF1dG9zcGFjZTpub25lIj48c3BhbiBsYW5n
PSJFTi1VUyIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPlRoZSBQLUFzc29jaWF0ZWQtVVJJIGNh
biBhcHBlYXIgaW4gU0lQIFJFR0lTVEVSIG1ldGhvZCBhbmQgMnh4IHJlc29uc2VzLCBQLUNhbGxl
ZC1QYXJ0eS1JRCBjYW4gYXBwZWFyIGluIFNJUCBJTlZJVEUsIE9QVElPTlMsIFBVQkxJU0gsU1VC
U0NSSUJFLCBNRVNTQUdFIG1ldGhvZHMgYW5kDQogYWxsIHJlc3BvbnNlcywgUC1WaXNpdGVkLU5l
dHdvcmstSUQgY2FuIGFwcGVhciBpbiBhbGwgU0lQIG1ldGhvZHMgZXhjZXB0IEFDSywgQllFIGFu
ZCBDQU5DRUwgYW5kIGFsbCByZXNwb25zZXMsIFAtQWNjZXNzLU5ldHdvcmstSW5mbyBjYW4gYXBw
ZWFyIGluIGFsbCBTSVAgbWV0aG9kcyBleGVwdCBBQ0sgYW5kIENBTkNFTCwgUC1DaGFyZ2luZy1W
ZWN0b3ImbmJzcDsgY2FuIGFwcGVhciBpbiBhbGwgU0lQIG1ldGhvZHMgZXhlcHQgQ0FOQ0VMIGFu
ZCB0aGUNCiBQLUNoYXJnaW5nLUZ1bmN0aW9uLUFkZHJlc3NlcyBjYW4gYXBwZWFyIGluIGFsbCBT
SVAgbWV0aG9kcyBleGVwdCBBQ0sgYW5kIENBTkNFTC48L3NwYW4+PHU+PC91Pjx1PjwvdT48L3A+
DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2Nr
cXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+W01CXSBJIHN1Z2dlc3QgeW91IHB1
dCBlYWNoIG9mIHRoZXNlIGluIHNlcGFyYXRlIHNlbnRlbmNlcyAtIGkuZS4sIHJhdGhlciB0aGFu
IHVzZSBjb21tYSBzZXBhcmF0b3JzLCB1c2UgYSBwZXJpb2QuICZuYnNwO1lvdSBzaG91bGQgYWxz
byBzcGVsbCBvdXQgdGhhdCB0aGVzZSBhcmUgaGVhZGVyIGZpZWxkcyAtIGkuZS4sICZxdW90O1Ro
ZSBQLUFzc29jaWF0ZWQtVVJJIGhlYWRlciBmaWVsZCBjYW4gYXBwZWFyLi4uLjJ4eCByZXNwb25z
ZXMuDQogJm5ic3A7IFRoZSBQLUNhbGxlZC1QYXJ0eS1JRCBoZWFkZXIgZmllbGQuLi4uPHU+PC91
Pjx1PjwvdT48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk
ZXItbGVmdDpzb2xpZCAjY2NjY2NjIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFy
Z2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1i
b3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K
PGRpdj4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv
cjojMWY0OTdkIj4mbmJzcDs8L3NwYW4+PHU+PC91Pjx1PjwvdT48L3ByZT4NCjxwcmU+PHNwYW4g
bGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48dT48L3U+PHU+PC91PjwvcHJlPg0KPHByZSBzdHls
ZT0id29yZC13cmFwOmJyZWFrLXdvcmQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtB
cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4tIFNlY3Rpb24gNi4xOiB0aGlzIG5l
ZWRzIHNvbWUgdGlnaHRlciB3b3JkaW5nLiAmbmJzcDtXaGF0IGlzIG1lYW50IGJ5ICZxdW90O3Bv
dGVudGlhbGx5IGFubm95aW5nJnF1b3Q7ICZuYnNwO2ZvciBleGFtcGxlPyAmbmJzcDs8L3NwYW4+
PHU+PC91Pjx1PjwvdT48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv
bG9yOiMxZjQ5N2QiPiZuYnNwOzwvc3Bhbj48dT48L3U+PHU+PC91PjwvcHJlPg0KPC9kaXY+DQo8
cHJlPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFmNDk3
ZCI+W1JKXSBJIGRvIG5vdCBrbm93LiBUaGlzIGlzIG9yaWdpbmFsIHRleHQuIFNvIEkgZGVsZXRl
ZCB0aGUgd29yZHMuPC9zcGFuPjx1PjwvdT48dT48L3U+PC9wcmU+DQo8ZGl2Pg0KPHByZSBzdHls
ZT0id29yZC13cmFwOmJyZWFrLXdvcmQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+
PHU+PC91Pjx1PjwvdT48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90
O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPi0gU2VjdGlvbiA2LjI6IEkgdGhp
bmsgeW91IG5lZWQgdG8gYmUgbW9yZSBzcGVjaWZpYyBhYm91dCB0aGUgJnF1b3Q7bmF0dXJlJnF1
b3Q7IHRoYXQgbWFrZXMgdGhpcyBoZWFkZXIgbm90IG9mIHBhcnRpY3VsYXIgY29uY2VybiB3aXRo
IHJlZ2FyZHMgdG8gc2VjdXJpdHkuIERvZXMgaXQgcmV2ZWFsIGFkZGl0aW9uYWwsIHVuaXF1ZSBp
bmZvcm1hdGlvbiBhYm91dCBhbiBpbmRpdmlkdWFsIHRoYXQgaXNuJ3QgYXZhaWxhYmxlIGluIG90
aGVyIGhlYWRlcnMuICZuYnNwO0Fsc28sIHRoZSAybmQgcGFyYWdyYXBoIG5lZWRzIHNvbWUgd29y
ayAtIG1heWJlIHNvbWV0aGluZyBsaWtlOjwvc3Bhbj48dT48L3U+PHU+PC91PjwvcHJlPg0KPHBy
ZT4mbmJzcDs8dT48L3U+PHU+PC91PjwvcHJlPg0KPHByZSBzdHlsZT0id29yZC13cmFwOmJyZWFr
LXdvcmQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz
YW5zLXNlcmlmJnF1b3Q7Ij5PTEQ6PC9zcGFuPjx1PjwvdT48dT48L3U+PC9wcmU+DQo8cHJlIHN0
eWxlPSJ3b3JkLXdyYXA6YnJlYWstd29yZDt3aGl0ZS1zcGFjZTpwcmUtd3JhcCI+QW4gZWF2ZXNk
cm9wcGVyIG1heSBjb2xsZWN0IHRoZSBsaXN0IG9mIGlkZW50aXRpZXMgYSB1c2VyIGlzIHJlZ2lz
dGVyZWQuJm5ic3A7IFRoaXMgbWF5IGhhdmUgcHJpdmFjeSBpbXBsaWNhdGlvbnMuJm5ic3A7IFRv
IG1pdGlnYXRlIHRoaXMgcHJvYmxlbSwgdGhpcyBleHRlbnNpb24gU0hPVUxEIG9ubHkgYmUgdXNl
ZCBpbiBhIHNlY3VyZWQgZW52aXJvbm1lbnQsIHdoZXJlIGVuY3J5cHRpb24gb2YgU0lQIG1lc3Nh
Z2VzIGlzIHByb3ZpZGVkIGVpdGhlciBlbmQtdG8tZW5kIG9yPGJyPg0KDQo8YnI+PHU+PC91Pjx1
PjwvdT48L3ByZT4NCjxwcmU+PHU+PC91PiZuYnNwOzx1PjwvdT48L3ByZT4NCjxwcmU+Jm5ic3A7
PHU+PC91Pjx1PjwvdT48L3ByZT4NCjxwcmU+Jm5ic3A7PHU+PC91Pjx1PjwvdT48L3ByZT4NCjxw
cmU+Jm5ic3A7PHU+PC91Pjx1PjwvdT48L3ByZT4NCjxwcmU+aG9wLWJ5LWhvcC4mbmJzcDs8dT48
L3U+PHU+PC91PjwvcHJlPg0KPHByZSBzdHlsZT0id29yZC13cmFwOmJyZWFrLXdvcmQiPiZuYnNw
OyAmbmJzcDs8dT48L3U+PHU+PC91PjwvcHJlPg0KPHByZSBzdHlsZT0id29yZC13cmFwOmJyZWFr
LXdvcmQiPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250
LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5ORVc6Jm5i
c3A7PC9zcGFuPjx1PjwvdT48dT48L3U+PC9wcmU+DQo8cHJlPiZuYnNwOzx1PjwvdT48dT48L3U+
PC9wcmU+DQo8cHJlIHN0eWxlPSJ3b3JkLXdyYXA6YnJlYWstd29yZCI+PHNwYW4gc3R5bGU9ImZv
bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNw
Ozwvc3Bhbj5BbiBlYXZlc2Ryb3BwZXIgY291bGQgcG9zc2libHkgY29sbGVjdCB0aGUgbGlzdCBv
ZiBpZGVudGl0aWVzIGEgdXNlciBpcyByZWdpc3RlcmVkLiZuYnNwOyBUaGlzIGNhbiBoYXZlIHBy
aXZhY3kgaW1wbGljYXRpb25zLiZuYnNwOyBUbyBtaXRpZ2F0ZSB0aGlzIHByb2JsZW0sIHRoaXMg
ZXh0ZW5zaW9uIE1VU1Qgb25seSBiZSB1c2VkIGluIGEgc2VjdXJlZCBlbnZpcm9ubWVudCwgd2hl
cmUgZW5jcnlwdGlvbiBvZiBTSVAgbWVzc2FnZXMgaXMgcHJvdmlkZWQgZWl0aGVyIGVuZC10by1l
bmQgb3IgaG9wLWJ5LWhvcC4mbmJzcDs8dT48L3U+PHU+PC91PjwvcHJlPg0KPC9kaXY+DQo8L2Rp
dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PHU+PC91Pjx1PjwvdT48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5bTUJdICZuYnNwO1NvLCBJIHRoaW5r
IHRoZSBmaXJzdCBzZW50ZW5jZSBpcyB0cnlpbmcgdG8gc2F5OiAmcXVvdDs8c3BhbiBzdHlsZT0i
Y29sb3I6IzUwMDA1MCI+QW4gZWF2ZXNkcm9wcGVyIGNvdWxkIHBvc3NpYmx5IGNvbGxlY3QgdGhl
IGxpc3Qgb2YgaWRlbnRpdGllcyBhIHVzZXIgaGFzIHJlZ2lzdGVyZWQuJnF1b3Q7PC9zcGFuPjx1
PjwvdT48dT48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImNvbG9yOiM1MDAwNTAiPm9yICZuYnNwOyZxdW90O0FuIGVhdmVzZHJvcHBlciBj
b3VsZCBwb3NzaWJseSBjb2xsZWN0IHRoZSBsaXN0IG9mIGlkZW50aXRpZXMgcmVnaXN0ZXJlZCBi
eSBhIHVzZXIuJnF1b3Q7Jm5ic3A7PC9zcGFuPjx1PjwvdT48dT48L3U+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM1MDAwNTAiPlsv
TUJdJm5ic3A7PC9zcGFuPiZuYnNwOzx1PjwvdT48dT48L3U+PC9wPg0KPC9kaXY+DQo8YmxvY2tx
dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI2NjY2NjYyAxLjBwdDtw
YWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4w
cHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0K
PGRpdj4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx
dW90O3NhbnMtc2VyaWYmcXVvdDsiPi0gU2VjdGlvbiA2LjQsJm5ic3A7PC9zcGFuPjx1PjwvdT48
dT48L3U+PC9wcmU+DQo8cHJlIHN0eWxlPSJ3b3JkLXdyYXA6YnJlYWstd29yZCI+PHNwYW4gc3R5
bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi
Pi0tM3JkIHBhcmFncmFwaDogJnF1b3Q7c2hvdWxkIG5vdCZxdW90OyAtJmd0OyAmcXVvdDtNVVNU
IE5PVCZxdW90OyZuYnNwOzwvc3Bhbj48dT48L3U+PHU+PC91PjwvcHJlPg0KPHByZT4mbmJzcDs8
dT48L3U+PHU+PC91PjwvcHJlPg0KPHByZSBzdHlsZT0id29yZC13cmFwOmJyZWFrLXdvcmQiPjxz
cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm
JnF1b3Q7Ij4tLSA3dGggcGFyYWdyYXBoOiAmbmJzcDsmcXVvdDtTSE9VTEQgTk9UIGJlIHNlbnQm
cXVvdDsgLSZndDsgJnF1b3Q7TVVTVCBOT1QgYmUgc2VudCZxdW90OyZuYnNwOzwvc3Bhbj48dT48
L3U+PHU+PC91PjwvcHJlPg0KPHByZSBzdHlsZT0id29yZC13cmFwOmJyZWFrLXdvcmQiPg0KPHU+
PC91PiZuYnNwOzx1PjwvdT48L3ByZT4NCjxwcmU+Jm5ic3A7PHU+PC91Pjx1PjwvdT48L3ByZT4N
CjxwcmU+Jm5ic3A7PHU+PC91Pjx1PjwvdT48L3ByZT4NCjxwcmU+Jm5ic3A7PHU+PC91Pjx1Pjwv
dT48L3ByZT4NCjxwcmU+Jm5ic3A7PHU+PC91Pjx1PjwvdT48L3ByZT4NCjxwcmU+PHNwYW4gc3R5
bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi
Pi0tIDh0aCBwYXJhZ3JhcGg6ICZxdW90O1NIT1VMRCBOT1Qgc2VuZCBzZW5zaXRpdmUgaW5mb3Jt
YXRpb24mcXVvdDsgLSZndDsgJnF1b3Q7TVVTVCBOT1Qgc2VuZCBzZW5zaXRpdmUgaW5mb3JtYXRp
b24mcXVvdDs8L3NwYW4+PHU+PC91Pjx1PjwvdT48L3ByZT4NCjxwcmUgc3R5bGU9IndvcmQtd3Jh
cDpicmVhay13b3JkIj4mbmJzcDs8dT48L3U+PHU+PC91PjwvcHJlPg0KPHByZT4mbmJzcDs8dT48
L3U+PHU+PC91PjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJp
YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+LS0gOXRoIHBhcmFncmFwaDogJnF1b3Q7
aXMgcmVxdWlyZWQgdG8gZGVsZXRlJnF1b3Q7IC0mZ3Q7ICZxdW90O2lzIFJFUVVJUkVEIHRvIGRl
bGV0ZSZxdW90OyZuYnNwOzwvc3Bhbj48dT48L3U+PHU+PC91PjwvcHJlPg0KPHByZSBzdHlsZT0i
d29yZC13cmFwOmJyZWFrLXdvcmQiPiZuYnNwOzx1PjwvdT48dT48L3U+PC9wcmU+DQo8cHJlPjxz
cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm
JnF1b3Q7Ij4tLSAxMHRoIHBhcmFncmFwaDogJm5ic3A7SG93IGRvZXMgYSBuZXR3b3JrIGVuc3Vy
ZSB0aGUgaW5mb3JtYXRpb24gaXMgbm90IG9mIGEgc2Vuc2l0aXZlIG5hdHVyZT8gJm5ic3A7IEkg
d291bGQgdGhpbmsgdGhhdCB0aGUgaW5mb3JtYXRpb24ganVzdCBzaG91bGQgbm90IGJlIHNlbnQg
b3V0c2lkZSBvZiB0aGUgdHJ1c3QgZG9tYWluLiAmbmJzcDtJIGJlbGlldmUgdGhhdCdzIGNvbnNp
c3RlbnQgd2l0aCB0aGUgc2NvcGUgb2YgdGhlc2UgaGVhZGVycywgaXMgaXQgbm90Pzwvc3Bhbj48
dT48L3U+PHU+PC91PjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s
b3I6IzFmNDk3ZCI+Jm5ic3A7PC9zcGFuPjx1PjwvdT48dT48L3U+PC9wcmU+DQo8L2Rpdj4NCjxw
cmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMWY0OTdk
Ij5bUkpdIFllcyB0aGF0IGlzIGFsc28gbXkgdW5kZXJzdGFuZGluZyBzbyBJIGRlbGV0ZWQgdGhh
dCBwYXJhZ3JhcGguIEkgdGhpbmsgdGhlIHJlc3QgaXMgc3VmZmljaWVudCBhbmQgZGVzY3JpYmVk
IHdlbGwgaG93IHRvIGJlaGF2ZS48L3NwYW4+PHU+PC91Pjx1PjwvdT48L3ByZT4NCjxkaXY+DQo8
cHJlPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFmNDk3
ZCI+Jm5ic3A7PC9zcGFuPjx1PjwvdT48dT48L3U+PC9wcmU+DQo8cHJlIHN0eWxlPSJ3b3JkLXdy
YXA6YnJlYWstd29yZCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVv
dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4tLSAxMXRoIHBhcmFncmFwaDog
U28sIHdoYXQgZG9lcyBhIHByb3h5IGRvIHdpdGggdGhhdCBpbmZvcm1hdGlvbi4gJm5ic3A7PC9z
cGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z
LXNlcmlmJnF1b3Q7Ij5XaGF0IGFyZSB0aGUgaW1wbGljYXRpb25zIGlmIHRoZSBpbmZvcm1hdGlv
biBpcyB1c2VkIGFuZCBpdCdzIG5vdCB2YWxpZD8gJm5ic3A7PC9zcGFuPjx1PjwvdT48dT48L3U+
PC9wcmU+DQo8L2Rpdj4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx
dW90Oztjb2xvcjojMWY0OTdkIj5bUkpdIFllcyBJIGRpZCBzb21lIGNoYW5nZXMgYXMgZm9sbG93
cy48L3NwYW4+PHU+PC91Pjx1PjwvdT48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1
b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMWY0OTdkIj4mbmJzcDs8L3NwYW4+PHU+PC91Pjx1
PjwvdT48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWF1dG9zcGFjZTpu
b25lIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxZjQ5
N2QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7dCZndDtB
IHByb3h5IHJlY2VpdmluZyBhIG1lc3NhZ2UgY29udGFpbmluZyB0aGUgUC1BY2Nlc3MtTmV0d29y
ay1JbmZvPC9zcGFuPjx1PjwvdT48dT48L3U+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9InRleHQtYXV0b3NwYWNlOm5vbmUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDs7Y29sb3I6IzFmNDk3ZCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7IGhlYWRlciBmaWVsZCBmcm9tIGEgbm9uLXRydXN0ZWQgZW50aXR5IGlzIG5vdCBhYmxlIHRv
IGd1YXJhbnRlZSB0aGU8L3NwYW4+PHU+PC91Pjx1PjwvdT48L3A+DQo8cHJlPjxzcGFuIGxhbmc9
IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp
JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFmNDk3ZCI+Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHZhbGlkaXR5IG9mIHRoZSBjb250ZW50cy4gVGh1cyB0
aGlzIGNvbnRlbnQgU0hPVUxEIGJlIGRlbGV0ZWQgYmFzZWQgb24gbG9jYWwgcG9saWN5LiZsdDsv
dCZndDs8L3NwYW4+PHU+PC91Pjx1PjwvdT48L3ByZT4NCjxkaXY+DQo8cHJlPjxzcGFuIGxhbmc9
IkVOLVVTIj4mbmJzcDs8L3NwYW4+PHU+PC91Pjx1PjwvdT48L3ByZT4NCjxwcmUgc3R5bGU9Indv
cmQtd3JhcDpicmVhay13b3JkIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm
cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+LSBTZWN0aW9uIDksIGl0ZW0gMi4gJm5ic3A7
SSB0aGluayB5b3UgbmVlZCB0byBhZGQgdGhpcyB0ZXh0IHdpdGggcmVnYXJkcyB0byB0aGUgcmVj
b21tZW5kYXRpb24gdG8gdXNlIFJGQyA0MjQ0IChiaXMpIHRvIHRoZSBib2R5IG9mIHRoaXMgZG9j
dW1lbnQgYW5kIGluY2x1ZGUgYSByZWFsIHJlZmVyZW5jZS48L3NwYW4+PHU+PC91Pjx1PjwvdT48
L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOiMxZjQ5N2QiPiZuYnNwOzwvc3Bhbj48dT48
L3U+PHU+PC91PjwvcHJlPg0KPC9kaXY+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFmNDk3ZCI+W1JKXSBPSyBkb25lLiBJIGxldCB0aGUgcmVm
ZXJlbmNlIFJGQzQyNDQgc2luY2UgM0dQUCB1c2VzIGN1cnJlbnRseSBvbmx5IFJGQzQyNDQuIDwv
c3Bhbj48dT48L3U+PHU+PC91PjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz
YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxZjQ5N2QiPlJlcGxhY2VkIGZvbGxvd2luZyB0ZXh0Ojwv
c3Bhbj48dT48L3U+PHU+PC91PjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz
YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxZjQ5N2QiPldpdGggc2VjdGlvbiA5LjI8L3NwYW4+PHU+
PC91Pjx1PjwvdT48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90Oztjb2xvcjojMWY0OTdkIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsgJmx0O3QmZ3Q7UmVxdWlyZW1lbnRzIGZvciBhIG1vcmUgZ2VuZXJhbCBzb2x1dGlvbiBhcmUg
cHJvcG9zZWQgaW4gJmx0O3hyZWY8L3NwYW4+PHU+PC91Pjx1PjwvdT48L3ByZT4NCjxwcmU+PHNw
YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMWY0OTdkIj4mbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdGFyZ2V0PSZxdW90
O1JGQzQyNDQmcXVvdDsmZ3Q7Jmx0Oy94cmVmJmd0Oy4gM0dQUCB3aWxsIGNvbnRpbnVlIHRvIHVz
ZSB0aGU8L3NwYW4+PHU+PC91Pjx1PjwvdT48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMi
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss
JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMWY0OTdkIj4mbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgUC1DYWxsZWQtUGFydHktSUQgaGVhZGVyIGZp
ZWxkIGV2ZW4gdGhvdWdoIFJGQyA0MjQ0ICZsdDt4cmVmPC9zcGFuPjx1PjwvdT48dT48L3U+PC9w
cmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6
IzFmNDk3ZCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
IHRhcmdldD0mcXVvdDtSRkM0MjQ0JnF1b3Q7Jmd0OyZsdDsveHJlZiZndDsgaGFzIG5vdyBiZWVu
IHB1Ymxpc2hlZC4mbHQ7L3QmZ3Q7PC9zcGFuPjx1PjwvdT48dT48L3U+PC9wcmU+DQo8cHJlPjxz
cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv
dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFmNDk3ZCI+Jm5i
c3A7PC9zcGFuPjx1PjwvdT48dT48L3U+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx
dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFmNDk3ZCI+SSB0aGluayB0aGUgdGV4dCBpbiBT
ZWN0aW9uIDkuMiBpcyBiZXR0ZXIuPC9zcGFuPjx1PjwvdT48dT48L3U+PC9wcmU+DQo8ZGl2Pg0K
PGRpdj4NCjxwcmUgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3JkO3doaXRlLXNwYWNlOnByZS13
cmFwIj48dT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7
c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMjIyMjIyIj5OaXRzOjwvc3Bhbj48L3U+PHU+PC91Pjx1
PjwvdT48L3ByZT4NCjxwcmUgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3JkO3doaXRlLXNwYWNl
OnByZS13cmFwIj4NCjx1PjwvdT4mbmJzcDs8dT48L3U+PC9wcmU+DQo8cHJlPiZuYnNwOzx1Pjwv
dT48dT48L3U+PC9wcmU+DQo8cHJlPiZuYnNwOzx1PjwvdT48dT48L3U+PC9wcmU+DQo8cHJlPiZu
YnNwOzx1PjwvdT48dT48L3U+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom
cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMyMjIyMjIiPi0g
U2VjdGlvbiA0LjEsIDJuZCBwYXJhZ3JhcGguICZuYnNwOyZxdW90O2hhcyBhc3NvY2lhdGVkIHRv
IGFuIGFkZHJlc3Mtb2YtcmVjb3JkJnF1b3Q7IC0mZ3Q7ICZxdW90O2hhcyBhc3NvY2lhdGVkIHdp
dGggYW4gYWRkcmVzcy1vZi1yZWNvcmQmcXVvdDs8L3NwYW4+PHU+PC91Pjx1PjwvdT48L3ByZT4N
CjxwcmUgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3JkO3doaXRlLXNwYWNlOnByZS13cmFwIj48
c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90Oztjb2xvcjojMjIyMjIyIj4tIFNlY3Rpb24gNC4xLjIuMiwgMm5kIHBhcmFncmFwaCwg
JnF1b3Q7SW4gY2FzZSZxdW90OyAtJmd0OyAmcXVvdDtJZiZxdW90OywgJm5ic3A7JnF1b3Q7c2hh
bGwgbm90JnF1b3Q7IC0mZ3Q7IFNIQUxMIE5PVDwvc3Bhbj48dT48L3U+PHU+PC91PjwvcHJlPg0K
PHByZSBzdHlsZT0id29yZC13cmFwOmJyZWFrLXdvcmQ7d2hpdGUtc3BhY2U6cHJlLXdyYXAiPjxz
cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm
JnF1b3Q7Ij4tIFNlY3Rpb24gNC4zLjIuMiwgbGFzdCBzZW50ZW5jZS4gJm5ic3A7VGhlIC0wOSBp
bnRyb2R1Y2VkIGEgdHlwbzogJnF1b3Q7VCBtZWFucyZxdW90OyAtJmd0OyAmcXVvdDtUaGlzIG1l
YW5zJnF1b3Q7Jm5ic3A7PC9zcGFuPjx1PjwvdT48dT48L3U+PC9wcmU+DQo8cHJlPiZuYnNwOzx1
PjwvdT48dT48L3U+PC9wcmU+DQo8cHJlIHN0eWxlPSJ3b3JkLXdyYXA6YnJlYWstd29yZDt3aGl0
ZS1zcGFjZTpwcmUtd3JhcCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPi0gU2VjdGlvbiA0LjMuMi4zLCAxc3QgcGFyYWdy
YXBoIGFmdGVyIDFzdCBleGFtcGxlLiAmbmJzcDtUaGUgLTA5IGludHJvZHVjZWQgYW5vdGhlciB0
eXBvOiAmcXVvdDt0aGUgUkVHSVNUUkFSJnF1b3Q7IC0mZ3Q7ICZxdW90O2F0IHRoZSBSRUdJU1RS
QVImcXVvdDs8L3NwYW4+PHU+PC91Pjx1PjwvdT48L3ByZT4NCjxwcmU+Jm5ic3A7PHU+PC91Pjx1
PjwvdT48L3ByZT4NCjxwcmUgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3JkO3doaXRlLXNwYWNl
OnByZS13cmFwIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1
b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMjIyMjIyIj5TZWN0aW9uIDQuMi4yLjEsIDNyZCBw
YXJhZ3JhcGg6ICZuYnNwOyZxdW90O3RoZXJlIG11c3QgYWxzbyBiZSBhIHRyYW5zaXRpdmUgdHJ1
c3QmcXVvdDsgLSZndDsgJm5ic3A7JnF1b3Q7dGhlcmUgTVVTVCBhbHNvIGJlIGEgdHJhbnNpdGl2
ZSB0cnVzdCZxdW90OyZuYnNwOzwvc3Bhbj48dT48L3U+PHU+PC91PjwvcHJlPg0KPHByZT4mbmJz
cDs8dT48L3U+PHU+PC91PjwvcHJlPg0KPHByZSBzdHlsZT0id29yZC13cmFwOmJyZWFrLXdvcmQ7
d2hpdGUtc3BhY2U6cHJlLXdyYXAiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlh
bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMyMjIyMjIiPlNlY3Rpb24gNC42
LCAybmQgcGFyYWdyYXBoOiAmcXVvdDtpbmNsdWRlcywgaW5jbHVkZXMgYnV0IGlzIG5vdCBsaW1p
dGVkIHRvJnF1b3Q7IC0mZ3Q7ICZxdW90O2luY2x1ZGVzLCBidXQgaXMgbm90IGxpbWl0ZWQgdG8s
JnF1b3Q7Jm5ic3A7PC9zcGFuPjx1PjwvdT48dT48L3U+PC9wcmU+DQo8cHJlPiZuYnNwOzx1Pjwv
dT48dT48L3U+PC9wcmU+DQo8cHJlIHN0eWxlPSJ3b3JkLXdyYXA6YnJlYWstd29yZDt3aGl0ZS1z
cGFjZTpwcmUtd3JhcCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7
LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzIyMjIyMiI+U2VjdGlvbiA0LjYuMi4yLCAx
c3QgcGFyYWdyYXBoOiAmcXVvdDtvbmUgb3JlIG1vcmUmcXVvdDsgLSZndDsgJnF1b3Q7b25lIG9y
IG1vcmUmcXVvdDsmbmJzcDs8L3NwYW4+PHU+PC91Pjx1PjwvdT48L3ByZT4NCjxwcmU+Jm5ic3A7
PHU+PC91Pjx1PjwvdT48L3ByZT4NCjxwcmUgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3JkO3do
aXRlLXNwYWNlOnByZS13cmFwIj4mbmJzcDs8dT48L3U+PHU+PC91PjwvcHJlPg0KPHByZSBzdHls
ZT0id29yZC13cmFwOmJyZWFrLXdvcmQ7d2hpdGUtc3BhY2U6cHJlLXdyYXAiPiZuYnNwOzx1Pjwv
dT48dT48L3U+PC9wcmU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVHVlLCBPY3QgOCwgMjAxMyBhdCAx
MTo1OCBBTSwgJmx0OzxhIGhyZWY9Im1haWx0bzpSLkplc3NrZUB0ZWxla29tLmRlIiB0YXJnZXQ9
Il9ibGFuayI+Ui5KZXNza2VAdGVsZWtvbS5kZTwvYT4mZ3Q7IHdyb3RlOjx1PjwvdT48dT48L3U+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5E
ZWFyIGFsbCw8YnI+DQpJIHdvdWxkIGxpa2UgdG8gaW5mb3JtIHlvdSB0aGF0IEkgaGF2ZSBpbXBs
ZW1lbnRlZCBhbGwgY29tbWVudHMgY29taW5nIGZyb20gdGhlIGV4cGVydCByZXZpZXcgZG9uZSBi
eSBEZWFuIFdpbGxpcy4gQWxzbyBhbiBlZGl0b3JpYWwgY2xlYW51cCB3YXMgbWFkZS48YnI+DQo8
YnI+DQpJZiB0aGVyZSBhcmUgc3RpbGwgc29tZSBjb21tZW50cyB0aGF0IG5lZWRzIHRvIGJlIGlt
cGxlbWVudGVkIHBsZWFzZSBpbmZvcm0gbWUuPGJyPg0KPGJyPg0KRnJvbSBteSBzaWRlIEkgd291
bGQgYmUgaGFwcHkgdG8gcHJvY2VlZCB0aGUgZHJhZnQgZnVydGhlciB0b3dhcmRzIHB1YmxpY2F0
aW9uLjxicj4NCjxicj4NClRoYW5rIHlvdSBhbmQgQmVzdCBSZWdhcmRzPGJyPg0KPGJyPg0KUm9s
YW5kPGJyPg0KPGJyPg0KPGJyPg0KLS0tLS1VcnNwcsO8bmdsaWNoZSBOYWNocmljaHQtLS0tLTxi
cj4NClZvbjogPGEgaHJlZj0ibWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyIgdGFyZ2V0
PSJfYmxhbmsiPmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzwvYT4gW21haWx0bzo8YSBocmVmPSJt
YWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+aW50ZXJuZXQt
ZHJhZnRzQGlldGYub3JnPC9hPl08YnI+DQpHZXNlbmRldDogRGllbnN0YWcsIDguIE9rdG9iZXIg
MjAxMyAxMzo0MDxicj4NCkFuOiBDaHJpc3RlciBIb2xtYmVyZzsgS2VpdGggRHJhZ2U7IEplc3Nr
ZSwgUm9sYW5kPGJyPg0KQmV0cmVmZjogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFm
dC1kcmFnZS1zaXBwaW5nLXJmYzM0NTViaXMtMDkudHh0PGJyPg0KPGJyPg0KPGJyPg0KQSBuZXcg
dmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWRyYWdlLXNpcHBpbmctcmZjMzQ1NWJpcy0wOS50eHQ8YnI+
DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEtlaXRoIERyYWdlIGFuZCBwb3N0
ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS48YnI+DQo8YnI+DQpGaWxlbmFtZTogJm5ic3A7ICZu
YnNwOyAmbmJzcDsgJm5ic3A7ZHJhZnQtZHJhZ2Utc2lwcGluZy1yZmMzNDU1YmlzPGJyPg0KUmV2
aXNpb246ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzA5PGJyPg0KVGl0bGU6ICZuYnNwOyAm
bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgUHJpdmF0ZSBIZWFkZXIgKFAtSGVhZGVyKSBFeHRl
bnNpb25zIHRvIHRoZSBTZXNzaW9uIEluaXRpYXRpb24gUHJvdG9jb2wgKFNJUCkgZm9yIHRoZSAz
cmQtR2VuZXJhdGlvbiBQYXJ0bmVyc2hpcCBQcm9qZWN0ICgzR1BQKTxicj4NCkNyZWF0aW9uIGRh
dGU6ICZuYnNwOyAyMDEzLTEwLTA4PGJyPg0KR3JvdXA6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu
YnNwOyAmbmJzcDsgSW5kaXZpZHVhbCBTdWJtaXNzaW9uPGJyPg0KTnVtYmVyIG9mIHBhZ2VzOiA0
Nzxicj4NClVSTDogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgPGEg
aHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtZHJhZ2Utc2lw
cGluZy1yZmMzNDU1YmlzLTA5LnR4dCIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cDovL3d3dy5pZXRm
Lm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtZHJhZ2Utc2lwcGluZy1yZmMzNDU1YmlzLTA5LnR4
dDwvYT48YnI+DQpTdGF0dXM6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8YSBo
cmVmPSJodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWRyYWdlLXNpcHBpbmct
cmZjMzQ1NWJpcyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k
b2MvZHJhZnQtZHJhZ2Utc2lwcGluZy1yZmMzNDU1YmlzPC9hPjxicj4NCkh0bWxpemVkOiAmbmJz
cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRt
bC9kcmFmdC1kcmFnZS1zaXBwaW5nLXJmYzM0NTViaXMtMDkiIHRhcmdldD0iX2JsYW5rIj5odHRw
Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1kcmFnZS1zaXBwaW5nLXJmYzM0NTViaXMtMDk8
L2E+PGJyPg0KRGlmZjogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8
YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1kcmFnZS1zaXBw
aW5nLXJmYzM0NTViaXMtMDkiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vd3d3LmlldGYub3JnL3Jm
Y2RpZmY/dXJsMj1kcmFmdC1kcmFnZS1zaXBwaW5nLXJmYzM0NTViaXMtMDk8L2E+PGJyPg0KPGJy
Pg0KQWJzdHJhY3Q6PGJyPg0KJm5ic3A7ICZuYnNwO1RoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGEg
c2V0IG9mIHByaXZhdGUgU2Vzc2lvbiBJbml0aWF0aW9uIFByb3RvY29sPGJyPg0KJm5ic3A7ICZu
YnNwOyhTSVApIGhlYWRlciBmaWVsZHMgKFAtaGVhZGVycykgdXNlZCBieSB0aGUgM3JkLUdlbmVy
YXRpb248YnI+DQombmJzcDsgJm5ic3A7UGFydG5lcnNoaXAgUHJvamVjdCAoM0dQUCksIGFsb25n
IHdpdGggdGhlaXIgYXBwbGljYWJpbGl0eSwgd2hpY2ggaXM8YnI+DQombmJzcDsgJm5ic3A7bGlt
aXRlZCB0byBwYXJ0aWN1bGFyIGVudmlyb25tZW50cy4gJm5ic3A7VGhlIFAtaGVhZGVyIGZpZWxk
cyBhcmUgZm9yIGE8YnI+DQombmJzcDsgJm5ic3A7dmFyaWV0eSBvZiBwdXJwb3NlcyB3aXRoaW4g
dGhlIG5ldHdvcmtzIHRoYXQgdGhlIHBhcnRuZXJzIHVzZSw8YnI+DQombmJzcDsgJm5ic3A7aW5j
bHVkaW5nIGNoYXJnaW5nIGFuZCBpbmZvcm1hdGlvbiBhYm91dCB0aGUgbmV0d29ya3MgYSBjYWxs
PGJyPg0KJm5ic3A7ICZuYnNwO3RyYXZlcnNlcy48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+
DQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0
aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZm
IGFyZSBhdmFpbGFibGUgYXQNCjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZyIgdGFyZ2V0
PSJfYmxhbmsiPnRvb2xzLmlldGYub3JnPC9hPi48YnI+DQo8YnI+DQpUaGUgSUVURiBTZWNyZXRh
cmlhdDx1PjwvdT48dT48L3U+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz
cDsgLTx1PjwvdT48dT48L3U+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8
L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzx1PjwvdT48
dT48L3U+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2
Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8dT48L3U+PHU+PC91PjwvcD4N
CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8
L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzx1PjwvdT48dT48L3U+PC9wPg0KPC9k
aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48dT48L3U+Jm5ic3A7PHU+PC91PjwvcD4NCjwvZGl2Pg0KPC9kaXY+
DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxicj4NCjwv
ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyPg0KPC9kaXY+
DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS08YnI+VGhpcyB0cmFuc21pc3Npb24gKGluY2x1ZGluZyBhbnkgYXR0YWNo
bWVudHMpIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBpbmZvcm1hdGlvbiwgcHJpdmlsZWdlZCBt
YXRlcmlhbCAoaW5jbHVkaW5nIG1hdGVyaWFsIHByb3RlY3RlZCBieSB0aGUgc29saWNpdG9yLWNs
aWVudCBvciBvdGhlciBhcHBsaWNhYmxlIHByaXZpbGVnZXMpLCBvciBjb25zdGl0dXRlIG5vbi1w
dWJsaWMgaW5mb3JtYXRpb24uIEFueSB1c2Ugb2YgdGhpcyBpbmZvcm1hdGlvbiBieSBhbnlvbmUg
b3RoZXIgdGhhbiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IGlzIHByb2hpYml0ZWQuIElmIHlvdSBo
YXZlIHJlY2VpdmVkIHRoaXMgdHJhbnNtaXNzaW9uIGluIGVycm9yLCBwbGVhc2UgaW1tZWRpYXRl
bHkgcmVwbHkgdG8gdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgaW5mb3JtYXRpb24gZnJvbSB5
b3VyIHN5c3RlbS4gVXNlLCBkaXNzZW1pbmF0aW9uLCBkaXN0cmlidXRpb24sIG9yIHJlcHJvZHVj
dGlvbiBvZiB0aGlzIHRyYW5zbWlzc2lvbiBieSB1bmludGVuZGVkIHJlY2lwaWVudHMgaXMgbm90
IGF1dGhvcml6ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC48YnI+PC9ib2R5Pg0KPC9odG1sPg0K

--_000_BBF5DDFE515C3946BC18D733B20DAD233985F212XMB122CNCrimnet_--



From mary.ietf.barnes@gmail.com  Fri Jan 10 11:48:45 2014
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 3F1ED1AE005 for ; Fri, 10 Jan 2014 11:48:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.698
X-Spam-Level: 
X-Spam-Status: No, score=-1.698 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, 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 EGd2Kf-rVcO4 for ; Fri, 10 Jan 2014 11:48:37 -0800 (PST)
Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 0D3041AE1B7 for ; Fri, 10 Jan 2014 11:48:36 -0800 (PST)
Received: by mail-wg0-f43.google.com with SMTP id k14so4427926wgh.34 for ; Fri, 10 Jan 2014 11:48:26 -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=WWk9eqEp+ZWI7vbpoHf/XbbUeNRmmdPAy8hrV4zp+rI=; b=IBAWHj4KJ/A9q0tIdd3++e4u61lt95FTem0bzZuHgV2ZBMqKlkRU+j9YQmr9I/lvCL tPhXDUUHqgmB0wFf9ZYkBMA1ZlRwk/RzXFJgarQJsTaYuLsBBjVMAx2MslvWvfYGw9lz ay2Q9cRi14XuEp/VEwoSFnE4DIwM4EHGQTSgSluuH/oWVBUZNVulLVgr/BaqH/lOBiDE uBkHxujtA0rUU5UFhhzj9kk81oBjNhOoNrPqBAegAMu8FYYgRYYz4KyNB0gpwttCGyca oqXjQXS6ZiE6EO3Ugc963xKocJhXmWPiS1+jt6XqsrudgwQ/Q2NGc+xO/y1sVrLAbOEZ Y5VQ==
MIME-Version: 1.0
X-Received: by 10.180.206.41 with SMTP id ll9mr4269912wic.7.1389383306491; Fri, 10 Jan 2014 11:48:26 -0800 (PST)
Received: by 10.216.172.9 with HTTP; Fri, 10 Jan 2014 11:48:26 -0800 (PST)
In-Reply-To: 
References:  
Date: Fri, 10 Jan 2014 13:48:26 -0600
Message-ID: 
From: Mary Barnes 
To: Andrew Allen 
Content-Type: multipart/alternative; boundary=001a11c3888270bd0204efa302b6
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: Fri, 10 Jan 2014 19:48:45 -0000

--001a11c3888270bd0204efa302b6
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Thanks Andrew.  So, that needs to be clearly stated in the abstract as
well.  In addition, the Overview section states:
"This document is an update to RFC3455".  So that also needs to be fixed.
Given the number of changes at this point, I would now prefer Roland make
those changes before we ask Gonzalo to progress it to IETF LC.

Mary.


On Fri, Jan 10, 2014 at 1:45 PM, Andrew Allen  wrote=
:

>
> I think it obsoletes RFC 3455. It is a complete replacement for the
> original.
>
> Andrew
>
>  *From*: Mary Barnes [mailto:mary.ietf.barnes@gmail.com]
> *Sent*: Friday, January 10, 2014 02:37 PM Eastern Standard Time
> *To*: R.Jesske@telekom.de 
> *Cc*: DISPATCH ; Dean Willis 
>
> *Subject*: Re: [dispatch] PROTO Review:
> draft-drage-sipping-rfc3455bis-09.txt
>
>  There is yet one more change needed.  This document is an Updates to
> 3455bis (AFAIK, unless Obseletes works better for 3GPP usage).  That
> categorization needs to be included in the document header (3rd line).
>
>  Thanks,
> Mary.
>
>
> On Fri, Jan 10, 2014 at 1:34 PM, Mary Barnes =
wrote:
>
>> IN addition to removing the unused references in the next update, there
>> are still 4 domain names that are not using an appropriate documentation
>> domain (e.g., home.net).  Please add that change to the list for the
>> next revision.  I'm going to ahead and forward the PROTO write-up to
>> Gonzalo, noting the changes that are needed and suggesting those changes
>> can be made along with other IETF LC changes.
>>
>>  Thanks,
>> Mary
>>
>>
>> On Wed, Jan 8, 2014 at 2:46 AM,  wrote:
>>
>>>  Thank you Marry,
>>>
>>> for doing all this review.
>>>
>>> So I have now put out the errors.
>>>
>>> There are still some unused references which are in our informal
>>> reference section. But useful for the reader to know they exist.
>>>
>>> There are also some warnings with regard to IP addresses and wrong FQDN=
s
>>> which I think is some interpretation of strings in the text which are n=
ot
>>> meant to be a IP address or FQDN at all.
>>>
>>>
>>>
>>> Detail see below.
>>>
>>>
>>>
>>> So now hopefully everything is ready for the next step.
>>>
>>>
>>>
>>> Best Regards
>>>
>>>
>>>
>>> Roland
>>>
>>>
>>>
>>> tmp/draft-drage-sipping-rfc3455bis-12.txt:
>>>
>>>
>>>
>>>   Checking boilerplate required by RFC 5378 and the IETF Trust (see
>>>
>>>   http://trustee.ietf.org/license-info):
>>>
>>>
>>> -----------------------------------------------------------------------=
-----
>>>
>>>
>>>
>>>      No issues found here.
>>>
>>>
>>>
>>>   Checking nits according to
>>> http://www.ietf.org/id-info/1id-guidelines.txt:
>>>
>>>
>>> -----------------------------------------------------------------------=
-----
>>>
>>>
>>>
>>>      No issues found here.
>>>
>>>
>>>
>>>   Checking nits according to http://www.ietf.org/id-info/checklist :
>>>
>>>
>>> -----------------------------------------------------------------------=
-----
>>>
>>>
>>>
>>>  =3D=3D There are 4 instances of lines with non-RFC2606-compliant FQDNs=
 in
>>> the
>>>
>>>      document.
>>>
>>>
>>>
>>>   =3D=3D There are 4 instances of lines with non-RFC5735-compliant IPv4
>>> addresses
>>>
>>>      in the document.  If these are example addresses, they should be
>>> changed.
>>>
>>>
>>>
>>>
>>>
>>>   Miscellaneous warnings:
>>>
>>>
>>> -----------------------------------------------------------------------=
-----
>>>
>>>
>>>
>>>      No issues found here.
>>>
>>>
>>>
>>>   Checking references for intended status: Informational
>>>
>>>
>>> -----------------------------------------------------------------------=
-----
>>>
>>>
>>>
>>>   =3D=3D Missing Reference: 'RFC XXXX' is mentioned on line 1662, but n=
ot
>>> defined
>>>
>>>
>>>
>>>   -- Looks like a reference, but probably isn't: '3' on line 1943
>>>
>>>
>>>
>>>   =3D=3D Unused Reference: 'RFC3262' is defined on line 2068, but no ex=
plicit
>>>
>>>      reference was found in the text
>>>
>>>
>>>
>>>   =3D=3D Unused Reference: 'RFC3311' is defined on line 2072, but no ex=
plicit
>>>
>>>      reference was found in the text
>>>
>>>
>>>
>>>   =3D=3D Unused Reference: 'RFC3428' is defined on line 2078, but no ex=
plicit
>>>
>>>      reference was found in the text
>>>
>>>
>>>
>>>   =3D=3D Unused Reference: 'RFC3903' is defined on line 2090, but no ex=
plicit
>>>
>>>      reference was found in the text
>>>
>>>
>>>
>>>   =3D=3D Unused Reference: 'RFC6086' is defined on line 2101, but no ex=
plicit
>>>
>>>      reference was found in the text
>>>
>>>
>>>
>>>
>>>
>>>      Summary: 0 errors (**), 0 flaws (~~), 8 warnings (=3D=3D), 1 comme=
nt
>>> (--).
>>>
>>>
>>>
>>>      Run idnits with the --verbose option for more detailed information
>>> about
>>>
>>>      the items above.
>>>
>>>
>>> -----------------------------------------------------------------------=
---------
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *Von:* Mary Barnes [mailto:mary.ietf.barnes@gmail.com]
>>> *Gesendet:* Dienstag, 7. Januar 2014 18:55
>>>
>>> *An:* Jesske, Roland
>>> *Cc:* DISPATCH; Gonzalo Camarillo; Atle Monrad; Dean Willis
>>> *Betreff:* Re: PROTO Review: draft-drage-sipping-rfc3455bis-09.txt
>>>
>>>
>>>
>>> Thanks Roland.  I have reviewed that version and all the changes I
>>> suggested have been made.  However, in doing the PROTO write-up I reali=
zed
>>> that I wasn't certain anyone had reviewed the ABNF. So, I ran the ABNF
>>> through Bill Fenner's tool:
>>>
>>> http://tools.ietf.org/tools/bap/abnf.cgi
>>>
>>>
>>>
>>> And, there are a couple things that need to be fixed:
>>>
>>> 1)  DOT needs to change to "." (we had this same bug in RFC 4244):
>>>
>>> transit-ioi-indexed-value =3D transit-ioi-name DOT transit-ioi-index
>>>
>>>
>>>
>>> 2)  There's an extra space here (between * and parenthesis):
>>>
>>> transit-ioi-name          =3D ALPHA * (ALPHA / DIGIT)
>>>
>>> NEw: transit-ioi-name          =3D ALPHA *(ALPHA / DIGIT)
>>>
>>>
>>>
>>> There are also a number of long lines in the ABNF that should be fixed.
>>>
>>>
>>>
>>> In addition, IDNITS identifies other errors and warnings per the
>>> following.  Those should also be addressed including considering whethe=
r
>>> obsolete references need changing:
>>>
>>>
>>>
>>> idnits 2.13.01
>>>
>>>
>>>
>>> tmp/draft-drage-sipping-rfc3455bis-11.txt:
>>>
>>>
>>>
>>>   Checking boilerplate required by RFC 5378 and the IETF Trust (see
>>>
>>>   http://trustee.ietf.org/license-info):
>>>
>>>   ---------------------------------------------------------------------=
-------
>>>
>>>
>>>
>>>      No issues found here.
>>>
>>>
>>>
>>>   Checking nits according to http://www.ietf.org/id-info/1id-guidelines=
.txt:
>>>
>>>   ---------------------------------------------------------------------=
-------
>>>
>>>
>>>
>>>      No issues found here.
>>>
>>>
>>>
>>>   Checking nits according to http://www.ietf.org/id-info/checklist :
>>>
>>>   ---------------------------------------------------------------------=
-------
>>>
>>>
>>>
>>>   ** There are 9 instances of too long lines in the document, the longe=
st one
>>>
>>>      being 20 characters in excess of 72.
>>>
>>>
>>>
>>>   =3D=3D There are 4 instances of lines with non-RFC2606-compliant FQDN=
s in the
>>>
>>>      document.
>>>
>>>
>>>
>>>   =3D=3D There are 4 instances of lines with non-RFC5735-compliant IPv4=
 addresses
>>>
>>>      in the document.  If these are example addresses, they should be c=
hanged.
>>>
>>>
>>>
>>>
>>>
>>>   Miscellaneous warnings:
>>>
>>>   ---------------------------------------------------------------------=
-------
>>>
>>>
>>>
>>>   =3D=3D The document seems to contain a disclaimer for pre-RFC5378 wor=
k, but was
>>>
>>>      first submitted on or after 10 November 2008.  The disclaimer is u=
sually
>>>
>>>      necessary only for documents that revise or obsolete older RFCs, a=
nd that
>>>
>>>      take significant amounts of text from those RFCs.  If you can cont=
act all
>>>
>>>      authors of the source material and they are willing to grant the B=
CP78
>>>
>>>      rights to the IETF Trust, you can and should remove the disclaimer=
.
>>>
>>>      Otherwise, the disclaimer is needed and you can ignore this commen=
t.
>>>
>>>      (See the Legal Provisions document at
>>>
>>>      http://trustee.ietf.org/license-info for more information.)
>>>
>>>
>>>
>>>
>>>
>>>   Checking references for intended status: Informational
>>>
>>>   ---------------------------------------------------------------------=
-------
>>>
>>>
>>>
>>>   =3D=3D Missing Reference: 'RFC XXXX' is mentioned on line 1667, but n=
ot defined
>>>
>>>
>>>
>>>   -- Looks like a reference, but probably isn't: '3' on line 1948
>>>
>>>
>>>
>>>   =3D=3D Unused Reference: 'RFC2976' is defined on line 2065, but no ex=
plicit
>>>
>>>      reference was found in the text
>>>
>>>
>>>
>>>   =3D=3D Unused Reference: 'RFC3262' is defined on line 2068, but no ex=
plicit
>>>
>>>      reference was found in the text
>>>
>>>
>>>
>>>   =3D=3D Unused Reference: 'RFC3311' is defined on line 2075, but no ex=
plicit
>>>
>>>      reference was found in the text
>>>
>>>
>>>
>>>   =3D=3D Unused Reference: 'RFC3428' is defined on line 2081, but no ex=
plicit
>>>
>>>      reference was found in the text
>>>
>>>
>>>
>>>   =3D=3D Unused Reference: 'RFC3903' is defined on line 2093, but no ex=
plicit
>>>
>>>      reference was found in the text
>>>
>>>
>>>
>>>   ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234)
>>>
>>>
>>>
>>>   -- Obsolete informational reference (is this intentional?): RFC 2976
>>>
>>>      (Obsoleted by RFC 6086)
>>>
>>>
>>>
>>>   -- Obsolete informational reference (is this intentional?): RFC 3265
>>>
>>>      (Obsoleted by RFC 6665)
>>>
>>>
>>>
>>>
>>>
>>>      Summary: 2 errors (**), 0 flaws (~~), 9 warnings (=3D=3D), 3 comme=
nts (--).
>>>
>>>
>>>
>>>      Run idnits with the --verbose option for more detailed information=
 about
>>>
>>>      the items above.
>>>
>>>  While I apologize for not catching these issues earlier, it really is
>>> the responsibility of authors to check idnits (beyond what the submissi=
on
>>> tool requires) for their documents.  I routinely run idnits before I su=
bmit
>>> a document as it can also save time when fixing the  nits that the
>>> submission tool catches:   https://tools.ietf.org/tools/idnits/
>>>
>>>
>>>
>>> Regards,
>>>
>>> Mary.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Tue, Jan 7, 2014 at 12:35 AM,  wrote:
>>>
>>> Hi Mary,
>>>
>>> Now a new revision is available.
>>>
>>>
>>>
>>> Thank you and Best Regards
>>>
>>>
>>>
>>> Roland
>>>
>>>
>>>
>>> *Von:* Mary Barnes [mailto:mary.ietf.barnes@gmail.com]
>>> *Gesendet:* Montag, 6. Januar 2014 20:00
>>>
>>>
>>> *An:* Jesske, Roland
>>> *Cc:* DISPATCH; Gonzalo Camarillo; Atle Monrad; Dean Willis
>>> *Betreff:* Re: PROTO Review: draft-drage-sipping-rfc3455bis-09.txt
>>>
>>>
>>>
>>> Hi Roland,
>>>
>>>
>>>
>>> One final editorial nit below.  If you can spin a revision, then I'll
>>> send the PROTO write-up to the AD.
>>>
>>>
>>>
>>> Thanks,
>>>
>>> Mary.
>>>
>>>
>>>
>>> On Thu, Jan 2, 2014 at 3:29 AM,  wrote:
>>>
>>> Hi Mary,
>>>
>>> I wish you a happy new year 2014. And the best for the next year.
>>>
>>>
>>>
>>> I was looking again on my changes I made due to your proposal in
>>> December.
>>>
>>> I realized that if I change the SHOULD to MUST we have now a backward
>>> compatibility problem.
>>>
>>> We are using the P-Associated-URI also over the IMS user interface whic=
h
>>> is not encrypted.
>>>
>>> So I propose to add some more words.
>>>
>>> =85
>>>
>>> Section 6.1
>>>
>>> =85
>>>
>>>          An eavesdropper could possibly collect the list of
>>> identities a user is registered.
>>>
>>>        This can 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.  
>>>
>>>
>>>
>>>        Since the P-Associated-URI header field value allows to
>>> implicitly register
>>>
>>>       a bundle of URIs with one REGISTER Message the impact of security
>>> using the P-Associated-URI header field is not higher than
>>>
>>>       using single REGISTER messages when registering all identities
>>> explicit.
>>>
>>> [MB] I just have some editorial suggestions for the above:
>>>
>>> NEW:
>>>
>>>  While the P-Associated-URI header field value allows the implicit
>>> registration of
>>>
>>>       a bundle of URIs with one REGISTER Message the impact of security
>>> using the P-Associated-URI header field is no higher than
>>>
>>>       using separate REGISTER messages for each of the URIs. 
>>>
>>> [/MB]
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> For the P-Called-Party-Id the change should be also done like as follow=
s:
>>>
>>>
>>>
>>>         An eavesdropper could possibly collect the list of
>>> identities a user is registered.
>>>
>>>        This can 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.  
>>>
>>>
>>>
>>>         Normally within a 3GPP environment the P-Called-Party-ID is
>>> not sent towards end users but may be exchanged between carriers where
>>> other security mechanisms than SIP encryption are used.  
>>>
>>>
>>>
>>> Sorry coming so late.
>>>
>>> If this is OK for you I will include it to a new version.
>>>
>>>
>>>
>>> Thank you and Best Regards
>>>
>>>
>>>
>>> Roland
>>>
>>>
>>>
>>> *Von:* Mary Barnes [mailto:mary.ietf.barnes@gmail.com]
>>> *Gesendet:* Freitag, 27. Dezember 2013 19:45
>>>
>>>
>>> *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 making these changes. I finally had a chance to review this
>>> updated version.   I still have a couple comments on the security secti=
on
>>> 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 extract=
ed
>>> these few points from previous review comment threads.
>>>
>>>
>>>
>>> Thanks,
>>>
>>> Mary.
>>>
>>>
>>>
>>> ----Previous point  --------------------------------->
>>>
>>> - Section 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.
>>>
>>> -
>>>
>>> [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 cou=
ld 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 - m=
aybe 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 exte=
nsion 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 encrypti=
on 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 r=
evision.  And, I believe you still need to identify privacy/security implic=
ations by addressing whether or not this header reveals any unique informat=
ion 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 (3=
GPP)
>>>
>>> Creation date:    2013-12-03
>>>
>>> Group:            Individual Submission
>>>
>>> Number of pages: 46
>>>
>>> URL:
>>> http://www.ietf.org/internet-drafts/draft-drage-sipping-rfc3455bis-10.t=
xt
>>>
>>> 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=
 in
>>> the -09 and many of my -08 comments remain - I've separated comments fr=
om
>>> nits below.  A number of these comments are with regards to text that w=
as
>>> not changed from RFC 3455, but I think some of the text requires updati=
ng
>>> 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 IES=
G
>>> 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 w=
ill
>>> need to do that before I progress the document unless the authors can p=
oint
>>> 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 appl=
y
>>> 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 lowe=
r
>>>
>>>    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 lowe=
r
>>>
>>>    layers, and the availability of transitive trust.  These assumptions
>>>
>>>    apply only to private networks and are not appropriate for use in an=
 Internet 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 abl=
e to model this after the text in more recent 3GPP P-header documents, refe=
rring 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 i=
n
>>> the
>>>
>>>      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 i=
n
>>> RFC4083 and describes updates and adds private extensions to address th=
ose
>>> requirements which are needed in for 3GPP Release 11. Each extension, o=
r
>>> 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 th=
e
>>>
>>>      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 ad=
dress-of-record"
>>>
>>> - Section 4.1, 3rd paragraph.  "Note that, generally speaking," -> "Not=
e that in standard SIP usage [RFC3261]"
>>>
>>> - Section 4.1.2.3.  I don't think this is stated properly.  I think the=
 intent is that this header is not applicable to proxies, therefore the pro=
xy MUST relay the header field unchanged.  I would suggest rewording someth=
ing like:
>>>
>>> OLD:
>>>
>>>    This memo does not define any procedure at the proxy.  The proxy doe=
s
>>>
>>>    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 norma=
tive from a SIP protocol perspective, thus MAY is not appropriate.  I sugge=
st the MAY be changed to "can".
>>>
>>>    The UAS MAY use the information to render different distinctive audi=
ovisual 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 n=
ormative from a SIP protocol perspective, thus  I suggest the MAY be change=
d to "can".
>>>
>>>
>>>
>>> - Section 4.3.3, last paragraph.  I think this ought to be a MUST: "The=
 identifier 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 defi=
ned in 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 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 N=
OT insert a P-Visited-Network-ID header field in any SIP message.
>>>
>>>
>>>
>>> - Section 4.3.2.2:, 2nd paragraph:  "home network MAY use" -> "home net=
work can use"
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> - Section 4.3.2.2, last paragraph:
>>>
>>>
>>>
>>>
>>>
>>> OLD: Note that a received P-Visited-Network-ID from a UA is a failure c=
ase 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=
 trust 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 u=
se the call id"
>>>
>>> Section 4.5.2: 2nd paragraph: "MAY use the hostnames" -> "can use the h=
ostnames"
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Section 4.5.2.1 2nd paragraph: "MAY use the contents" -> "can use the c=
ontents"
>>>
>>>
>>>
>>> - Section 4.6.2, 3rd paragraph: "MAY use the values" -> "can use the va=
lues"
>>>
>>>  - Section 4.6.3, 3rd paragraph: needs some editorial work.  Maybe the =
following 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-Ch=
arging-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 guarante=
ed that all the values that are added will appear within the P-Charging-Vec=
tor 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 considera=
tion" mean. Are you talking about limits on the number of entries or are yo=
u suggesting 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=
 incremented by the number of void entries +1.
>>>
>>>
>>>
>>> - Section 4.6.4.2: I don't know what this means:  "A deletion of the el=
ements could appear depending on the network policy and trust rules".  Is i=
t just trying to say that along with the adding and modifying in the previo=
us 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 any=
more as they really don't provide any useful information.  You just need to=
 verbally 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 a=
ll
>>> SIP methods except ACK, BYE and CANCEL and all responses,
>>> P-Access-Network-Info can appear in all SIP methods exept ACK and CANCE=
L,
>>> 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 a=
nd
>>> 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 "pote=
ntially 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 available in other headers.  Also, the 2nd paragraph needs some work - ma=
ybe 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 exte=
nsion 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 i=
s registered.  This can have privacy implications.  To mitigate this proble=
m, this extension MUST only be used in a secured environment, where encrypt=
ion 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 =
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 sensitive nature?   I would think that the information just should not b=
e sent outside of the trust domain.  I believe that's consistent with the s=
cope 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.  Wha=
t 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-Info
>>>
>>>        header field from a non-trusted entity is not able to guarantee
>>> the
>>>
>>>        validity of the contents. Thus this content SHOULD be deleted ba=
sed 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 =
include a real reference.
>>>
>>>
>>>
>>>  [RJ] OK done. I let the reference RFC4244 since 3GPP uses currently on=
ly 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" -> SH=
ALL 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 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 w=
as
>>> 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.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
>>> 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 (3=
GPP)
>>> Creation date:   2013-10-08
>>> Group:           Individual Submission
>>> Number of pages: 47
>>> URL:
>>> http://www.ietf.org/internet-drafts/draft-drage-sipping-rfc3455bis-09.t=
xt
>>> 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
>>>
>>>   -
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>  ---------------------------------------------------------------------
> This transmission (including any attachments) may contain confidential
> information, privileged material (including material protected by the
> solicitor-client or other applicable privileges), or constitute non-publi=
c
> information. Any use of this information by anyone other than the intende=
d
> recipient is prohibited. If you have received this transmission in error,
> please immediately reply to the sender and delete this information from
> your system. Use, dissemination, distribution, or reproduction of this
> transmission by unintended recipients is not authorized and may be unlawf=
ul.
>

--001a11c3888270bd0204efa302b6
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable


Thanks Andrew. =A0So, that needs to be clearly stated in t=
he abstract as well. =A0In addition, the Overview section states:=A0
&qu=
ot;This document is an update to RFC3455". =A0So that also needs to be=
 fixed. =A0 Given the number of changes at this=A0point, I would now prefer=
 Roland make those changes before we ask Gonzalo to progress it to IETF LC.=



Mary.=A0


On Fri, Jan 10, 2014 at 1:45 PM, Andrew Allen <a=
allen@blackberry.com> wrote:










I think it obsoletes RFC 3455. It is a complete replacement for the origina=
l.



Andrew

=A0




From: Mary Barnes [mailto:mary.ietf.barnes@gmail.=
com]



Sent: Friday, January 10, 2014 02:37 PM Eastern Standard Time<=
br>
To: R.Jessk=
e@telekom.de <R.Jesske@telekom.de> 

Cc: DISPATCH <dispatch@ietf.org>; Dean Willis <dean.willis@softarmor.com> 

Subject: Re: [dispatch] PROTO Review: draft-drage-sipping-rfc3455bis=
-09.txt


=A0




There is yet one more change needed. =A0This document is a=
n Updates to 3455bis (AFAIK, unless Obseletes works better for 3GPP usage).=
 =A0That categorization needs to be included in the document header (3rd li=
ne).=A0






Thanks,


Mary.=A0









On Fri, Jan 10, 2014 at 1:34 PM, Mary Barnes 
<mary.ie=
tf.barnes@gmail.com> wrote:




IN addition to removing the unused references in the next =
update, there are still 4 domain names that are not using an appropriate do=
cumentation domain (e.g.,
home.net). =A0Please add =
that change to the list for the next revision. =A0I'm going to ahead an=
d forward the PROTO write-up to Gonzalo, noting the changes that are needed=
 and suggesting those changes can be made along
 with other IETF LC changes.






Thanks,


Mary













On Wed, Jan 8, 2014 at 2:46 AM, <R.Jesske@tel=
ekom.de> wrote:








Thank you =
Marry,


for doing =
all this review.


So I have =
now put out the errors.


There are =
still some unused references which are in our informal reference section. B=
ut useful for the reader to know they exist.



There are =
also some warnings with regard to IP addresses and wrong FQDNs which I thin=
k is some interpretation of strings in the text which are
 not meant to be a IP address or FQDN at all. 


=A0=



Detail see=
 below.


=A0=



So now hop=
efully everything is ready for the next step.


=A0=



Best Regar=
ds


=A0=



Roland<=
/u>


=A0=



tmp/draft-drage-sipping-rfc3455bis-12.txt:<=
u>




=A0


=A0 Checking boilerplate required by RFC 53=
78 and the IETF Trust (see


=A0
http://t=
rustee.ietf.org/license-info):


=A0 ---------------------------------------=
-------------------------------------


=A0


=A0=A0=A0=A0 No issues found here.


=A0


=A0 Checking nits according to
http://www.ietf.org/id-info/1id-guidelines.txt:<=
/p>

=A0 ---------------------------------------=
-------------------------------------


=A0


=A0=A0=A0=A0 No issues found here.


=A0


=A0 Checking nits according to
http://=
www.ietf.org/id-info/checklist :


=A0 ---------------------------------------=
-------------------------------------


=A0




=A0=3D=3D There are 4 instances of lines wi=
th non-RFC2606-compliant FQDNs in the




=A0=A0=A0=A0 document.=



=A0


=A0 =3D=3D There are 4 instances of lines w=
ith non-RFC5735-compliant IPv4 addresses


=A0=A0=A0=A0 in the document.=A0 If these a=
re example addresses, they should be changed.


=A0


=A0


=A0 Miscellaneous warnings:


=A0 ---------------------------------------=
-------------------------------------


=A0




=A0=A0=A0=A0 No issues found here.


=A0


=A0 Checking references for intended status=
: Informational


=A0 ---------------------------------------=
-------------------------------------


=A0


=A0 =3D=3D Missing Reference: 'RFC XXXX=
' is mentioned on line 1662, but not defined


=A0


=A0 -- Looks like a reference, but probably=
 isn't: '3' on line 1943




=A0


=A0 =3D=3D Unused Reference: 'RFC3262&#=
39; is defined on line 2068, but no explicit


=A0=A0=A0=A0 reference was found in the tex=
t


=A0




=A0 =3D=3D Unused Reference: 'RFC3311&#=
39; is defined on line 2072, but no explicit




=A0=A0=A0=A0 reference was found in the tex=
t


=A0




=A0 =3D=3D Unused Reference: 'RFC3428&#=
39; is defined on line 2078, but no explicit




=A0=A0=A0=A0 reference was found in the tex=
t


=A0




=A0 =3D=3D Unused Reference: 'RFC3903&#=
39; is defined on line 2090, but no explicit




=A0=A0=A0=A0 reference was found in the tex=
t


=A0




=A0 =3D=3D Unused Reference: 'RFC6086&#=
39; is defined on line 2101, but no explicit




=A0=A0=A0=A0 reference was found in the tex=
t


=A0


=A0




=A0=A0=A0=A0 Summary: 0 errors (**), 0 flaw=
s (~~), 8 warnings (=3D=3D), 1 comment (--).




=A0


=A0=A0=A0=A0 Run idnits with the --verbose =
option for more detailed information about


=A0=A0=A0=A0
the items above.




----------------------------------------------------------=
----------------------


=A0


=A0=



=A0=





Von: Mary Barn=
es [mailto:=
mary.ietf.barnes@gmail.com]


Gesendet: Dienstag, 7. Januar 2014 18:55






An: Jesske, Roland

Cc: DISPATCH; Gonzalo Camarillo; Atle Monrad; Dean Willis

Betreff: Re: PROTO Review: draft-drage-sipping-rfc3455bis-09.txt<=
/u>












=A0




Thanks Roland. =A0I have reviewed that version and a=
ll the changes I suggested have been made. =A0However, in doing the PROTO w=
rite-up I realized that I wasn't certain anyone had reviewed the ABNF. =
So, I ran the ABNF through Bill Fenner's tool:=A0






=A0






And, there are a couple things that need to be fixed=
:






1) =A0DOT needs to change to "." (we had t=
his same bug in RFC 4244):






transit-ioi-indexed-value =3D transit-ioi-name DOT t=
ransit-ioi-index






=A0






2) =A0There's an extra space here (between * and=
 parenthesis):






transit-ioi-name=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D ALPH=
A * (ALPHA / DIGIT)






NEw: transit-ioi-name=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D AL=
PHA *(ALPHA / DIGIT)







=A0






There are also a number of long lines in the ABNF th=
at should be fixed.=A0






=A0






In addition, IDNITS identifies other errors and warn=
ings per the following. =A0Those should also be addressed including conside=
ring whether obsolete references need changing:






=A0


idnits 2.13.01 


=A0


tmp/draft-drage-sipping-rfc3455bis-11.txt:<=
/pre>

=A0


=A0 Checking boilerplate required by RFC 5378 and the IETF Trust=
 (see


=A0 http://trustee.ietf.org/license-info):

=A0 ------------------------------------------------------------=
----------------


=A0


=A0=A0=A0=A0 No issues found here.


=A0


=A0 Checking nits according to http://www.ietf.org/id-info/1id=
-guidelines.txt:


=A0 ------------------------------------------------------------=
----------------


=A0


=A0=A0=A0=A0 No issues found here.


=A0


=A0 Checking nits according to http://www.ietf.org/id-info/checklist :


=A0 ------------------------------------------------------------=
----------------


=A0


=A0 ** There are 9 instances of too long lines in the document, =
the longest one


=A0=A0=A0=A0 being 20 characters in excess of 72.<=
/span>


=A0


=A0 =3D=3D There are 4 instances of lines with non-RFC2606-compl=
iant FQDNs in the


=A0=A0=A0=A0 document.


=A0


=A0 =3D=3D There are 4 instances of lines with non-RFC5735-compl=
iant IPv4 addresses


=A0=A0=A0=A0 in the document.=A0 If these are example addresses,=
 they should be changed.


=A0


=A0


=A0 Miscellaneous warnings:


=A0 ------------------------------------------------------------=
----------------


=A0


=A0 =3D=3D The document seems to contain a disclaimer for pre-RF=
C5378 work, but was


=A0=A0=A0=A0 first submitted on or after 10 November 2008.=A0 Th=
e disclaimer is usually


=A0=A0=A0=A0 necessary only for documents that revise or obsolet=
e older RFCs, and that


=A0=A0=A0=A0 take significant amounts of text from those RFCs.=
=A0 If you can contact all


=A0=A0=A0=A0 authors of the source material and they are willing=
 to grant the BCP78


=A0=A0=A0=A0 rights to the IETF Trust, you can and should remove=
 the disclaimer. 


=A0=A0=A0=A0=A0Otherwise, the disclaimer is needed and you can i=
gnore this comment. 


=A0=A0=A0=A0=A0(See the Legal Provisions document at


=A0=A0=A0=A0 http://trustee.ietf.org/license-info for more informati=
on.)


=A0


=A0


=A0 Checking references for intended status: Informational


=A0 ------------------------------------------------------------=
----------------


=A0


=A0 =3D=3D Missing Reference: 'RFC XXXX' is mentioned on=
 line 1667, but not defined


=A0


=A0 -- Looks like a reference, but probably isn't: '3=
9; on line 1948


=A0


=A0 =3D=3D Unused Reference: 'RFC2976' is defined on lin=
e 2065, but no explicit


=A0=A0=A0=A0 reference was found in the text


=A0


=A0 =3D=3D Unused Reference: 'RFC3262' is defined on lin=
e 2068, but no explicit


=A0=A0=A0=A0 reference was found in the text


=A0


=A0 =3D=3D Unused Reference: 'RFC3311' is defined on lin=
e 2075, but no explicit


=A0=A0=A0=A0 reference was found in the text


=A0


=A0 =3D=3D Unused Reference: 'RFC3428' is defined on lin=
e 2081, but no explicit


=A0=A0=A0=A0 reference was found in the text


=A0


=A0 =3D=3D Unused Reference: 'RFC3903' is defined on lin=
e 2093, but no explicit


=A0=A0=A0=A0 reference was found in the text


=A0


=A0 ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC =
4234)


=A0


=A0 -- Obsolete informational reference (is this intentional?): =
RFC 2976


=A0=A0=A0=A0 (Obsoleted by RFC 6086)


=A0


=A0 -- Obsolete informational reference (is this intentional?): =
RFC 3265


=A0=A0=A0=A0 (Obsoleted by RFC 6665)


=A0


=A0


=A0=A0=A0=A0 Summary: 2 errors (**), 0 flaws (~~), 9 warnings (=
=3D=3D), 3 comments (--).


=A0


=A0=A0=A0=A0 Run idnits with the --verbose option for more detai=
led information about


=A0=A0=A0=A0 the items above.






While I apologize for not catching these issues earl=
ier, it really is the responsibility of authors to check idnits (beyond wha=
t the submission tool requires) for their documents. =A0I routinely run idn=
its before I submit a document as it
 can also save time when fixing the =A0nits that the submission tool catche=
s: =A0=A0https://tools.ietf.org/tools/idnits/






=A0






Regards,






Mary.=A0






=A0






=A0








=A0




On Tue, Jan 7, 2014 at 12:35 AM, <R.Jesske@telekom.de> wrote=
:






Hi Mary,


Now a new =
revision is available.




=A0=



Thank you =
and Best Regards


=A0=



Roland


=A0=







Von: Mary Barnes [mailto:mary.ietf.barnes@gmail.com]


Gesendet: Montag, 6. Januar 2014 20:00<=
/u>








An: Jesske, Roland

Cc: DISPATCH; Gonzalo Camarillo; Atle Monrad; Dean Willis

Betreff: Re: PROTO Review: draft-drage-sipping-rfc3455bis-09.txt<=
/u>












=A0




Hi Roland,




=A0






One final editorial nit below. =A0If you can spin a =
revision, then I'll send the PROTO write-up to the AD.





=A0






Thanks,






Mary.=A0






=A0




On Thu, Jan 2, 2014 at 3:29 AM, <R.Jesske@telekom.de> wrote:=







Hi Mary,


I wish you=
 a happy new year 2014. And the best for the next year.



=A0=



I was look=
ing again on my changes I made due to your proposal in December.<=
/u>



I realized=
 that if I change the SHOULD to MUST we have now a backward compatibility p=
roblem.



We are usi=
ng the P-Associated-URI also over the IMS user interface which is not encry=
pted.



So I propo=
se to add some more words.


=85=



Section 6.=
1


=85=



=A0=A0=A0=A0=A0=A0=A0=A0
<t=
>An eavesdropper could possibly collec=
t the list of identities a user is registered.=A0



=A0=A0=A0=A0=A0=A0=A0This can have privacy implic=
ations. To mitigate this problem, this extension SHOULD





=A0=A0=A0=A0=A0=A0=A0only be used in a secured en=
vironment, where encryption of SIP messages is





=A0=A0=A0=A0=A0=A0=A0provided either end-to-end o=
r hop-by-hop.=A0
</t>


=A0=A0



=A0=A0=A0=A0=A0=A0<=
t>=
 Since the P-Associated-URI header field value allows to
 implicitly register 


=A0=A0=A0=A0=A0=A0a bundle of URIs with one REGIS=
TER Message the impact of security using the P-Associated-URI header field =
is not higher than=A0



=A0=
=A0=A0=A0=A0=A0using single REGISTER messages when registering all identiti=
es explicit.</t>








[MB] I just have some editorial suggestions for the =
above:






NEW: =A0






<t>=A0While the P-Associat=
ed-URI header field value allows the implicit registration
 of=A0


=A0=A0=A0=A0=A0=A0a bundle of U=
RIs with one REGISTER Message the impact of security using the P-Associated=
-URI header field is no higher than=A0


=A0=A0=A0=A0=A0=A0using separat=
e REGISTER messages for each of the URIs.=A0<=
/t>=
;



[/MB]






=A0










=A0














=A0=



=A0=



For the P-=
Called-Party-Id the change should be also done like as follows:


=A0=



=A0=A0=A0=A0=A0=A0=A0
<t=
>An eavesdropper could possibly collec=
t the list of identities a user is registered.=A0



=A0=A0=A0=A0=A0=A0=A0This can have privacy implic=
ations.=A0 To mitigate this problem, this extension SHOULD





=A0=A0=A0=A0=A0=A0=A0only be used in a secured en=
vironment, where encryption of SIP messages is





=A0=
=A0=A0=A0=A0=A0=A0provided either end-to-end or hop-by-hop.=A0
</t>


=A0


=A0=A0=A0=A0=A0=A0=A0
<t=
>Normally within a 3GPP environment th=
e P-Called-Party-ID is not sent towards end users but may be exchanged betw=
een carriers where other security mechanisms
 than SIP encryption are used.=A0 </t>


=A0=



Sorry comi=
ng so late.


If this is=
 OK for you I will include it to a new version.




=A0=



Thank you =
and Best Regards


=A0=



Roland


=A0=







Von: Mary Barn=
es [mailto:=
mary.ietf.barnes@gmail.com]


Gesendet: Freitag, 27. Dezember 2013 19:45








An: Jesske, Roland

Cc: DISPATCH; Gonzalo Camarillo; Atle Monrad; Dean Willis

Betreff: Re: PROTO Review: draft-drage-sipping-rfc3455bis-09.txt<=
/u>












=A0




Hi Roland,




=A0






Thanks for making these changes. I finally had a cha=
nce to review this updated version. =A0 I still have a couple comments on t=
he security section as I think you will get questions during SEC review aro=
und this unless some more detail is
 provided on security threats and impacts. =A0 I've extracted these few=
 points from previous review comment threads.






=A0






Thanks,






Mary.






=A0






----Previous point =A0------------------------------=
--->








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



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



-<=
/u>


[MB] So, you=
 removed that part of the sentence and are left with:<=
/pre>


"This attack should not have any signifi=
cant impacts."


=A0


=A0


I don't think that adds any value and j=
ust begs the question "what are the insignificant impacts and are ther=
e any privacy concerns"?=A0 Really, it's the next paragraph that p=
rovides details of the impacts.=A0 I think you could probably remove that s=
entence altogether and not lose anything. 






=A0


=A0


[/MB]=



=A0


----Previous point --------------------------=
------->


=A0


-=A0 Section 6.2: I think yo=
u need to be more specific about the "nature" that makes this hea=
der not of particular concern with regards to security. Does it reveal addi=
tional, unique information about an individual that isn't available in =
other headers. =A0Also, the 2nd paragraph needs some work - maybe something=
 like:






=A0


=A0


OLD:


=A0<=
/pre>

=A0


An eavesdropper may collect the list of =
identities a user is registered.=A0 This may have privacy implications.=A0 =
To mitigate this problem, this extension SHOULD only be used in a secured e=
nvironment, where encryption of SIP messages is provided either end-to-end =
or






=A0


=A0


hop-by-hop.=A0


NEW:=A0

=A0


An eavesdropper could possibly =
collect the list of identities a user is registered.=A0 This can have priva=
cy implications.=A0 To mitigate this problem, this extension MUST only be u=
sed in a secured environment, where encryption of SIP messages is provided =
either end-to-end or hop-by-hop.=A0



----End prev=
ious point ------------------------------<


=A0


[MB]=A0 The suggested change for the first =
sentence didn't get into the revision.=A0 And, I believe you still need=
 to identify privacy/security implications by addressing whether or not thi=
s header reveals any unique information about an individual that isn't =
available in other headers.=A0=A0 [/MB]



=A0


=A0<=
/pre>

=A0


=A0<=
/pre>





=A0










=A0




On Tue, Dec 3, 2013 at 7:00 AM, <R.Jesske@telekom.de> 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.




=A0=



Thank you =
and Best Regards


=A0=



Roland


=A0=





A new version of I-D, draft-drage-sipping-rfc3455bi=
s-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 Hea=
der (P-Header) Extensions to the Session Initiation Protocol (SIP) for the =
3rd-Generation Partnership 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



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 Ses=
sion 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 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<=
/u>




Betreff: Re: PROTO Review: draft-drage-sippin=
g-rfc3455bis-09.txt








=A0




Hi Roland,




=A0






Thanks for your response. =A0Additional comments bel=
ow [MB].






=A0






Thanks,






Mary.






=A0




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






Hi Mary,


Thank you =
for your review.


I have add=
ed now your proposals to the draft.


Other comm=
ents please see below.


=A0=



I hope now=
 everything is OK.




=A0=



Thank you =
and Best Regards


=A0=



Roland


=A0=







Von: Mary Barn=
es [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<=
u>




=A0






In preparation for the PROTO write-up, I have review=
ed the document in detail. =A0My detailed review was originally based on th=
e -08, but I also reviewed the 09 diff. =A0There are a few errors that have=
 been introduced in the -09 and many of
 my -08 comments remain - I've separated comments from nits below. =A0A=
 number of these comments are with regards to text that was not changed fro=
m RFC 3455, but I think some of the text requires updating and we need to k=
eep 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. =A0I will note that I also hav=
e not validated the content of section 9 against a diff of this document an=
d 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 b=
eing progressed.=A0




=A0






Comments:






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






- Section 1. =A0I think you should be explicit that =
these extensions apply only to a private network - saying they are "ge=
nerally not applicable" is too soft, so I would suggest some minor rew=
ording something like:







OLD:






=A0=A0 The SIP ext=
ensions specified in this document make certain


=A0


=A0=A0 assumptions regarding network topology, linkage between SIP and=
 lower


=A0=A0 layers, and the availability of transitive trust.=A0 These assu=
mptions


=A0=A0 are generally NOT APPLICABLE in the Internet as a whole. 


=A0<=
/pre>







NEW:=A0






=A0<=
/pre>

=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 availability of transitive trust.=A0 These assu=
mptions


=A0=A0 apply only to private networks and are not appropriate for use =
in an=A0Internet environment.


=A0<=
/pre>

=A0


=A0


=A0


-=
 Section 3. =A0This section needs to be updated. =A0I don't think that =
10 year old background is relevant in the current context. =A0 You should b=
e able to model this after the text in more recent 3GPP P-header documents,=
 referring 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
 covers the requirements in RFC4083 and describes updates and adds private =
extensions to address those requirements which are needed in for 3GPP Relea=
se 11. Each extension, or set of related extensions is described in its own=
 section below

















[MB] I suggest just a bit more rewording. =A0Note th=
at I didn't see that this document is adding any new headers=A0<=
u>






=A0






=A0 =A0 Th=
e Third Generation Partnership Project (3GPP) uses SIP as<=
/u>



=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 defines 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.






=A0






[/MB]=A0






=A0






















-=
 Section 4.1. "registered address-of-record" -> "register=
ed 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 pr=
ocedure 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 unchanged.

=A0


N=
EW:


=A0


=A0=A0 This header is not intended to be used by proxies - a proxy doe=
s


=A0=A0 not add, read, modify or delete the header field, and therefore=
 any


=A0=A0 proxy MUST relay this header field unchanged.

=A0<=
/pre>

=A0


=A0


=A0


Section 4.2, 1st paragraph. =A0The behavior in this sentence i=
s not normative from a SIP protocol perspective, thus MAY is not appropriat=
e. =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 the invitation to t=
he


=A0=A0 session.


Section 4.2.2.2, 2nd paragraph.=
 =A0The behavior in this sentence is not normative from a SIP protocol pers=
pective, thus =A0I suggest the MAY be changed to "can".=A0=




=A0


- Section 4.3.3, last paragraph. =A0I think t=
his ought to be a MUST: "The identifier should be globally unique..&qu=
ot;=A0



=A0


- Section 4.3.2.1. =A0This text has changed f=
rom the -08. =A0 I don't know what a "normal User Equipment" =
is and the term "User Equipment" is not defined in this specifica=
tion. =A0I think it would be better to say something like. However, even wi=
th this proposed change, I think you also need text for user agent server b=
ehavior - i.e., what would a UAS do if it received this header.=A0



=A0


OLD:


=A0=A0 A normal Us=
er Equipment has normally no knowledge of the P-Visited-

=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 me=
ssage.


=A0


=A0


=A0


N=
EW:=A0


=A0=A0 In the context of the network to=
 which the header fields defined in this document apply, a User Agent has=
=A0no knowledge of the P-Visited-Network-ID when sending the REGISTER reque=
st. =A0Therefore user agent clients MUST NOT insert a P-Visited-Network-ID=
=A0header field=A0in any SIP message.



=A0


- Section 4.3.2.2:, 2nd paragraph: =A0"home network MAY use"=
; -> "home network can use"






=A0


=A0


=A0


=A0


- Section 4.3.2.2, last =
paragraph: =A0


=A0<=
/pre>

=A0


O=
LD: Note that a received P-Visited-Network-ID from a UA is a failure=
 case and must be deleted.


=A0<=
/pre>

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


=A0<=
/pre>

Section 4.4.2.1, 2nd paragraph: =A0"MUST trust the proxy&=
quot; -> "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


=A0


S=
ection 4.5.2.1 2nd paragraph: "MAY use the contents" -> "=
can use the=A0contents"=A0






=A0


-=
 Section 4.6.2, 3rd paragraph: "MAY use the values" -> "c=
an use the values"=A0




- Section 4.6.3, 3rd paragraph: needs some ed=
itorial work. =A0Maybe the following change would work:=A0=




=A0


=A0


O=
LD:


=A0<=
/pre>

=A0=A0 Depending on the call scenario it is needed to add for each tra=
nsit


=A0=A0 network either a transit network name or a void value. =A0Never=
theless


=A0=A0 it can not be guaranteed that all values will appear within the=
 P-Charging-Vector header field.=A0


=A0


=A0


N=
EW:=A0


=A0


=A0=A0 Depending o=
n the call scenario, each transit network can add either a transit network =
name=A0or a void=A0=A0=A0 value.=A0 However, it can not be guaranteed that =
all the values that are added will appear within the P-Charging-Vector head=
er field.



=A0


- Section 4.6.3, next to last p=
aragraph:=A0"which needs to be incremented" -> "which MUS=
T be incremented"



=A0


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



=A0




[RJ] Yes! Changed the text t=
o:


=A0

A void value has no in=
dex. By adding the next value the index has to be incremented by the number=
 of void entries +1.




=A0

- Section =
4.6.4.2: I don't know what thi=
s means:=A0=A0"A deletion of the elements could appear=
 depending on the network policy and trust rules". =A0Is it just tryi=
ng to say that along with the adding and modifying in the previous sentence=
 that the elements can also be deleted by the proxy?=A0



=A0




[RJ] Yes, I have changed the=
 text:


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


=A0

=A0


=A0


=A0


-=
 Section 5.7. Delete this text and table. =A0 We aren't these tables an=
ymore 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 h=
eader=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-ID can appear in all SIP methods except A=
CK, BYE and CANCEL and all responses, P-Access-Network-Info can appear in a=
ll 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 =
CANCEL.


















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




















=A0

=A0


- Section 6.1: this needs some tighter wordin=
g. =A0What is meant by "potentially annoying" =A0for example? =A0=




=A0




[RJ] I do not know. This is =
original text. So I deleted the words.




=A0<=
u>


-=
 Section 6.2: I think you need to be more specific about the "nature&q=
uot; that makes this header not of particular concern with regards to secur=
ity. Does it reveal additional, unique information about an individual that=
 isn't available in other headers. =A0Also, the 2nd paragraph needs som=
e work - maybe something like:



=A0


OLD:


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






=A0


=A0


=A0


=A0


hop-by-hop.=A0


=A0 =A0


=A0


N=
EW:=A0


=A0


=A0An eavesdropper could possibly coll=
ect the list of identities a user is registered.=A0 This can have privacy i=
mplications.=A0 To mitigate this problem, this extension MUST only be used =
in a secured environment, where encryption of SIP messages is provided eith=
er end-to-end or hop-by-hop.=A0





















=A0






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







or =A0"An eavesdr=
opper could possibly collect the list of identities registered by a user.&q=
uot;=A0






[/MB]=A0=A0<=
/u>












-=
 Section 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


=A0


=A0


=A0


-=
- 8th paragraph: "SHOULD NOT send sensitive information" -> &q=
uot;MUST NOT send sensitive information"



=A0


=A0


-=
- 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 these headers, is it not?



=A0




[RJ] Yes that is also my und=
erstanding so I deleted that paragraph. I think the rest is sufficient and =
described well how to behave.





=A0

-- 11th paragraph: So, what do=
es a proxy do with that information. =A0What are the implications if the i=
nformation is used and it's not valid? =A0





[RJ] Yes I did some changes =
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 a=
dd this text with regards to the recommendation to use RFC 4244 (bis) to th=
e body of this document and include a real reference.<=
/pre>


=A0




[RJ] OK done. I let the refe=
rence 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 tar=
get=3D"RFC4244"></xref> has now been published.</t>=
;



=A0

I think the text in Section =
9.2 is better.






Nits:


=A0<=
/pre>

=A0


=A0


=A0


- Section 4.1, 2nd paragraph. =A0"has associated to an ad=
dress-of-record" -> "has associated with an address-of-record&=
quot;



- 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 p=
aragraph after 1st example. =A0The -09 introduced another typo: "the R=
EGISTRAR" -> "at the REGISTRAR"


=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<=
/pre>

=A0<=
/pre>















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 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: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.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: =A0 =A0 =A0 =A0draft-drage-sipping-rfc3455bis

Revision: =A0 =A0 =A0 =A009

Title: =A0 =A0 =A0 =A0 =A0 Private Header (P-Header) Extensions to the Sess=
ion Initiation Protocol (SIP) for the 3rd-Generation Partnership Project (3=
GPP)

Creation date: =A0 2013-10-08

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

Number of pages: 47

URL: =A0 =A0 =A0 =A0 =A0 =A0 
http://www.ietf.org/internet-drafts/draft-drage-sipping-rfc3455bis-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-d=
rage-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 minutes from the time of submissio=
n until the htmlized version and diff are available at
tools.ietf.org.



The IETF Secretariat




=A0 -














=A0
















=A0
















=A0
















=A0































---------------------------------------------------------------------
Th=
is transmission (including any attachments) may contain confidential inform=
ation, privileged material (including material protected by the solicitor-c=
lient or other applicable privileges), or constitute non-public information=
. Any use of this information by anyone other than the intended recipient i=
s prohibited. If you have received this transmission in error, please immed=
iately reply to the sender and delete this information from your system. Us=
e, dissemination, distribution, or reproduction of this transmission by uni=
ntended recipients is not authorized and may be unlawful.








--001a11c3888270bd0204efa302b6--


From mary.ietf.barnes@gmail.com  Fri Jan 10 14:59:11 2014
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 934DC1AC4A7 for ; Fri, 10 Jan 2014 14:59:11 -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 GLvpbo_0yEZY for ; Fri, 10 Jan 2014 14:59:09 -0800 (PST)
Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) by ietfa.amsl.com (Postfix) with ESMTP id A49B81A8031 for ; Fri, 10 Jan 2014 14:59:08 -0800 (PST)
Received: by mail-wg0-f43.google.com with SMTP id k14so4707429wgh.10 for ; Fri, 10 Jan 2014 14:58:58 -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=1ymRBS3stbyXdxYIJlQH4z21XC64Z7yLuMGYpHz78ns=; b=af9xrijYEGJXkuifJTbooPJ78wGznHRaTEfotCb0MOs9aii8NqbJKezAYSf1vXtFNC oUIR0ZQbY5ub8GDB8WyZJTBXUKjVSGfc7NlBVCnUIomURbjmG59FFxI7L80MNVTT4vJL xPc/sZt3K0Y86izS1zTRh3X9ncGQPTyxZ0qrf92iuYuSQ9tn2IYpwiIxtm/H5lY8Fciw fy/FXIbs8vuC8nWaGH9452kql4ZBhSKAxiv2INL1TyBCOP1nQFTOlRjvgbEUItZpA7na wXywcVukgdRcsJAgzWRLEjQ8A1vbg2kYXncs9BGAcHDV68rLvmwV1zoh2zAZhUmlL64W LNqw==
MIME-Version: 1.0
X-Received: by 10.194.82.68 with SMTP id g4mr15195wjy.85.1389394738090; Fri, 10 Jan 2014 14:58:58 -0800 (PST)
Received: by 10.216.172.9 with HTTP; Fri, 10 Jan 2014 14:58:57 -0800 (PST)
In-Reply-To: <20131213005747.777.34301.idtracker@ietfa.amsl.com>
References: <20131213005747.777.34301.idtracker@ietfa.amsl.com>
Date: Fri, 10 Jan 2014 16:58:57 -0600
Message-ID: 
From: Mary Barnes 
To: DISPATCH 
Content-Type: multipart/alternative; boundary=047d7bea41fed1166304efa5ab96
Cc: Ben Campbell , draft-pd-dispatch-msrp-websocket@tools.ietf.org
Subject: Re: [dispatch] I-D Action: draft-pd-dispatch-msrp-websocket-03.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, 10 Jan 2014 22:59:11 -0000

--047d7bea41fed1166304efa5ab96
Content-Type: text/plain; charset=ISO-8859-1

I have agreed to shepherd this document.  I've reviewed the document in
anticipation of doing the PROTO write-up and have the following comments
and questions.  Ben Campbell has agreed to do the required expert review
and that should be posted within the next week or so.    This is also a
good time for anyone in the WG that hasn't previously reviewed this
document to review and provide any final comments.  Note, that this
document was agreed to be AD sponsored around the IETF-86 timeframe.

Regards,
Mary.

Review Summary: Almost ready. Comments & questions below.

1)  Section 2 & General.  I'm not sure the documented approach for
separating normative text from non-normative is quite so helpful.  In
general, we expect that in the case of standards track document use RFC
2119 language to indicate normative behaviors.  I think the first sentence
is good, but that's not a terminology thing.   I just don't see a lot of
value in writing the document this way.  For example, the definitions
aren't stated to be non-normative, but I don't see anything normative about
the definitions.  I think you could easily title Section 3 as "WebSocket
Protocol overview" and that would clearly imply non-normative behavior.
 There are also several places in the document in sections that I believe
are intended to provide normative behavior, but there is certainly
non-normative text in those sections (e.g., section 5.2.2, second
paragraph).  I would suggest this document follow the typical (and
accepted) style of identifying normative behavior with 2119 language
(consistently using upper case for normative behavior and avoiding using
2119 language in cases where alternative words can be substituted).

2) Section 5.2.2, 2nd paragraph.  Related to my point above, it's not clear
to me this is normative behavior.  I don't think it is since it's referring
to existing 4975 behavior. However, I didn't see that the reference given
in 4975 relates to the second part of that sentence stating that
implementations "should" already be allowing unrecognized transports.  It
would be quite useful to have the exact reference here as I was trying to
double check this point and I couldn't find it.

3) Section 6.  I'm really puzzled as to why the Connection Keep-alive would
be non-normative.  In particular given that 2119 language is clearly being
used.

4) Section 7.  Again, I'm puzzled as to why Authentication is considered
non-normative. AGain, you have 2119 language in this section.

5) Section 10.1. Since securing the connection is just RECOMMENDED, what
are the implications and risks if the MSRP traffic isn't transported over a
secure connection?

6) Section 11.  You should change the name of the registry to be the exact
name of the IANA registry to avoid any confusion.- i.e.,:
OLD:
  registry of WebSocket sub-protocols
NEW:
  WebSocket Subprotocol Name Registry

7) Section 11. There is also a Reference field in that IANA registry. I
would suggest you use the same information as the pointer to the
Subprotocol Definition (i.e., this RFC).

8) It's typical for documents that are updating existing RFCs to have a
section that summarizes the updates to the existing RFCs that are made by
this document.



On Thu, Dec 12, 2013 at 6:57 PM,  wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>
>         Title           : The WebSocket Protocol as a Transport for the
> Message Session Relay Protocol (MSRP)
>         Author(s)       : Peter Dunkley
>                           Gavin Llewellyn
>                           Victor Pascual
>                           Anton Roman
>                           Gonzalo Salgueiro
>         Filename        : draft-pd-dispatch-msrp-websocket-03.txt
>         Pages           : 21
>         Date            : 2013-12-12
>
> Abstract:
>    The WebSocket protocol enables two-way real-time communication
>    between clients and servers.  This document specifies a new WebSocket
>    sub-protocol as a reliable transport mechanism between MSRP (Message
>    Session Relay Protocol) clients and relays to enable usage of MSRP in
>    new scenarios.  This document normatively updates RFC 4975 and RFC
>    4976.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-pd-dispatch-msrp-websocket
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-pd-dispatch-msrp-websocket-03
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-pd-dispatch-msrp-websocket-03
>
>
> 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.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>

--047d7bea41fed1166304efa5ab96
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


I have agreed to shepherd this document. =A0I've revie=
wed the document in anticipation of doing the PROTO write-up and have the f=
ollowing comments and questions. =A0Ben Campbell has agreed to do the requi=
red expert review and that should be posted within the next week or so. =A0=
 =A0This is also a good time for anyone in the WG that hasn't previousl=
y reviewed this document to review and provide any final comments. =A0Note,=
 that this document was agreed to be AD sponsored around the IETF-86 timefr=
ame.


Regards,
Mary.=A0
=

Review Summ=
ary: Almost ready. Comments & questions below.


1) =A0Section 2 & General. =A0I=
9;m not sure the documented approach for separating normative text from non=
-normative is quite so helpful. =A0In general, we expect that in the case o=
f standards track document use RFC 2119 language to indicate normative beha=
viors. =A0I think the first sentence is good, but that's not a terminol=
ogy thing. =A0 I just don't see a lot of value in writing the document =
this way. =A0For example, the definitions aren't stated to be non-norma=
tive, but I don't see anything normative about the definitions. =A0I th=
ink you could easily title Section 3 as "WebSocket Protocol overview&q=
uot; and that would clearly imply non-normative behavior. =A0There are also=
 several places in the document in sections that I believe are intended to =
provide normative behavior, but there is certainly non-normative text in th=
ose sections (e.g., section 5.2.2, second paragraph). =A0I would suggest th=
is document follow the typical (and accepted) style of identifying normativ=
e behavior with 2119 language (consistently using upper case for normative =
behavior and avoiding using 2119 language in cases where alternative words =
can be substituted).



2) Section =
5.2.2, 2nd paragraph. =A0Related to my point above, it's not clear to m=
e this is normative behavior. =A0I don't think it is since it's ref=
erring to existing 4975 behavior. However, I didn't see that the refere=
nce given in 4975 relates to the second part of that sentence stating that =
implementations "should" already be allowing unrecognized transpo=
rts. =A0It would be quite useful to have the exact reference here as I was =
trying to double check this point and I couldn't find it.=A0



3) Section =
6. =A0I'm really puzzled as to why the Connection Keep-alive would be n=
on-normative. =A0In particular given that 2119 language is clearly being us=
ed. =A0



4) Section =
7. =A0Again, I'm puzzled as to why Authentication is considered non-nor=
mative. AGain, you have 2119 language in this section. =A0


5) Section 10.1. Since securing the co=
nnection is just RECOMMENDED, what are the implications and risks if the MS=
RP traffic isn't transported over a secure connection?=A0


6) Section 11. =A0You should change th=
e name of the registry to be the exact name of the IANA registry to avoid a=
ny confusion.- i.e.,:
OLD:

=A0 registry of WebSocket sub-protocols
NEW=
:=A0
=A0 WebSocket Subprotocol Name Registr=
y =A0

=
7) Section 11. There is also a Reference field in that IANA registry. I wou=
ld suggest you use the same information as the pointer to the Subprotocol D=
efinition (i.e., this RFC).=A0



8) It's=
 typical for documents that are updating existing RFCs to have a section th=
at summarizes the updates to the existing RFCs that are made by this docume=
nt. =A0





On Thu, Dec 12, 2013 at 6:57 PM,  <=
internet-draf=
ts@ietf.org> wrote:




A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.





=A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : The WebSocket Protocol as a Tra=
nsport for the Message Session Relay Protocol (MSRP)

=A0 =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Peter Dunkley

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Gavin Llewellyn

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Victor Pascual

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Anton Roman

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Gonzalo Salgueiro

=A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-pd-dispatch-msrp-websocket-=
03.txt

=A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 21

=A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2013-12-12



Abstract:

=A0 =A0The WebSocket protocol enables two-way real-time communication

=A0 =A0between clients and servers. =A0This document specifies a new WebSoc=
ket

=A0 =A0sub-protocol as a reliable transport mechanism between MSRP (Message=


=A0 =A0Session Relay Protocol) clients and relays to enable usage of MSRP i=
n

=A0 =A0new scenarios. =A0This document normatively updates RFC 4975 and RFC=


=A0 =A04976.





The IETF datatracker status page for this draft is:

https://datatracker.ietf.org/doc/draft-pd-dispatch-msr=
p-websocket



There's also a htmlized version available at:

http://tools.ietf.org/html/draft-pd-dispatch-msrp-websock=
et-03



A diff from the previous version is available at:

http://www.ietf.org/rfcdiff?url2=3Ddraft-pd-dispa=
tch-msrp-websocket-03





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.



Internet-Drafts are also available by anonymous FTP at:

ftp://ftp=
.ietf.org/internet-drafts/



_______________________________________________

I-D-Announce mailing list

I-D-Announce@ietf.org

https://www.ietf.org/mailman/listinfo/i-d=
-announce

Internet-Draft directories: http://www.ietf.org/shadow.html

or =
ftp://ftp.ietf.org/ietf/1shadow-sites.txt





--047d7bea41fed1166304efa5ab96--

From ben@nostrum.com  Fri Jan 10 22:01:27 2014
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 02EEB1AE00E; Fri, 10 Jan 2014 22:01:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.264
X-Spam-Level: *
X-Spam-Status: No, score=1.264 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, MANGLED_LIST=2.3] 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 EKyTISGTKT5t; Fri, 10 Jan 2014 22:01:24 -0800 (PST)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 9821E1AD94A; Fri, 10 Jan 2014 22:01:24 -0800 (PST)
Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id s0B615kG034931 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 11 Jan 2014 00:01:07 -0600 (CST) (envelope-from ben@nostrum.com)
From: Ben Campbell 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Sat, 11 Jan 2014 00:01:08 -0600
Message-Id: <5F44E887-4513-46DF-9C05-8C68F54842B8@nostrum.com>
To: draft-pd-dispatch-msrp-websocket.all@tools.ietf.org, Mary Barnes 
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
X-Mailer: Apple Mail (2.1827)
Received-SPF: pass (shaman.nostrum.com: 173.172.146.58 is authenticated by a trusted mechanism)
Cc: DISPATCH , rai@ietf.org
Subject: [dispatch] MSRP Expert Review of draft-pd-dispatch-msrp-websocket-04
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: Sat, 11 Jan 2014 06:01:27 -0000

[Oops, I meant to copy dispatch. Sorry for the repeat. Please include =
dispatch on any discussion.]

Hi,

Mary asked me to do a review of draft-pd-dispatch-msrp-websocket-04 from =
the perspective of an alleged MSRP expert. (Actually she requested it =
for 03, but since 04 is available, I reviewed that one. Please be =
advised that my knowledge of WebSocket is somewhat limited.

I think this draft is on the right track and generally well written. But =
I have two general areas of concern, which I think I've mentioned =
before:

I'd like to see more detail on the expected support (and behavior) for a =
WebSocket MSRP Relay when dealing with 4975/4976 clients and relays. For =
example, would it be acceptable to build a WebSocket MSRP Relay that =
would only talk to WebSocket clients, and not support "legacy" MSRP =
relays and clients at all? Since this draft introduces some new rules on =
chunk sizes, how would a WebSocket MSRP relay handle it if a "legacy" =
peer did not follow them?=20

The security considerations section needs considerably more meat. I'd =
like to see a discussion of the security implications of downgrading the =
4976 MUST requirement for TLS between a client and a server, as well as =
the use of the MSRPS scheme if the WebSocket connection is not =
protected.

It would be worth a discussion of any other TLS requirements that differ =
between MSRP/WebSocket and 4975/4976. For example, are the certificate =
matching rules the same for WebSocket as for MSRP/TLS? Is there any =
requirement that the domain names match between the WebSocket and MSRP =
layers? (i.e. could I authenticate as example.com, but except traffic =
for example.net?)

=46rom higher level perspective, does the use of WebSocket introduce =
potential web oriented vunerabilities that native MSRP wouldn't have? =
(e.g., sidejacking of authentication cookies over non-protected =
connections?)

specific comments:

-- Abstract and Introduction:

The idea that WebSocket enables communication between clients and =
servers needs a bit more context. One assumes that clients and servers =
could talk to each other before the advent of WebSocket. When does it =
make sense to use MSRP/WebSocket rather than MSRP/TLS or MSRP/TCP?

-- section 1, last bullet:

This point needs more context. The need to apply policy to a messages is =
already one of the justifications for 4976. Likewise, MSRP using SIP =
already offers varying degrees of authentication. How is the need for =
these things different in the WebSockets context?

--3

I am not happy with the downgrade of of the TLS requirement between =
client and relay. I recognize that WebSocket

-- 4.2:

MSRP only allows a "binary" transfer encoding. I'm not sure it makes =
sense to use text frames, even for text content. If text frames are =
allowed, do you need to verify that only text-based content-types are =
negotiated at the signaling layer? Does introduce a mapping requirement =
for WebSocket relays, for example if a WebSocket client sends text =
frames towards a "legacy" peer?

-- 5.1, 1st paragraph:

Is it impossible to have an MSRP _client_ implemented on a WebSocket =
_server_? (For example, an robot endpoint for human-to-machine or =
machine-to-machine communication?)

-- 5.1, last paragraph:

Can you offer guidance on a reasonable or maximum chunk size? It may be =
worth suggesting a minimum size beneath which MSRP messages should not =
be chunked. Can a MSRP chunk in a WebSocket frame be interrupted? (I =
note the examples have interruptible chunks.)

nit: Indented paragraphs are usually considered parenthetical =
explanations. It's generally not a good idea to put 2119 normative =
language in them.

-- 5.2.1:=20

Is there ever a need to map between MSRP URIs and HTTP URIs? Is a =
WebSocket MSRP client expected to always connect to it's own server, or =
would it ever connect to a WebSocket server that it learned about in the =
offer/answer? (e.g a WebSocket server acting on behalf of the peer?) Is =
there any requirement that the MSRP URI domain name matches the HTTP =
domain name in any way? (In particular, can a server that presented a =
TLS cert for one or more domains accept MSRP URIs for a domain that was =
not included in the cert?)

-- 5.3.1:

It seems ambiguous when you allow the connection to be authenticated at =
the WebSocket layer whether the AUTH request is still required. I assume =
it is, since all the examples use it. But it's not clear to me from the =
language in this section.

-- 5.3.2:

This issue has given me heartburn for WebSocket in general. It's not as =
big of an issue for protocols that do not have MUST level requirements =
for TLS. But I really don't like downgrading a security related MUST =
from 4976. As I mentioned above, if we are going to do so, we need a =
thorough discussion of the security implications. (For example, do we =
introduce a requirement to ensure MSRPS URLs are never used for =
unprotected links? Do we need to worry about "legacy" endpoint users =
that assume that the peer's client to relay connection is always =
protected?=20

It seems like we should have some general IETF policy on this, as I'm =
sure MSRP is not the first place it has come up. But in general, while I =
am sensitive to "existing code" or "API" limitations preventing some =
requirements from being MUSTs, I am personally less sympathetic when it =
means downgrading an already existing security requirement.=20

-- 6, last paragraph:

Seems lile they also need to be prepared to receive bodiless SEND =
keep-alives  from the peer, especially from legacy peers.

-- 7:

Is there any requirent (in WebSockets or otherwise) that authentication =
cookies only be tranferred over protected connections? Does this =
introduce a sidejacking attack into MSRP?

-- 7, last paragraph: " ... authentication MAY be requested at MSRP =
protocol level."

Who can request it? Just the client by sending an AUTH? (Still not clear =
if AUTH is expected when authenticating at the WebSocket layer.) Also, =
you might consider avoiding 2119 language in a section marked as =
"non-normative".

-- 8:

I'd like to see an example with authentication included. It would also =
be good to see an example where the peer has it's own relay.

All the examples assume default settings for the Failure-Report and =
Success-Report header fields. There's no other mention of them. Does =
anything change with those as a result of using WebSocket?

-- 8.4:

Does this not still assume the offer/answer exchange from the previous =
example? Why not include the "bob -> alice" message in the previous =
example? (Or are we assuming Bob initiated the session negotiation this =
time?)



Thanks!

Ben.



From de_subhrajyoti@yahoo.co.uk  Fri Jan 10 22:04:27 2014
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 875C21AE00E for ; Fri, 10 Jan 2014 22:04:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.57
X-Spam-Level: 
X-Spam-Status: No, score=-3.57 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, GB_I_LETTER=-2, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.428, RCVD_IN_DNSWL_NONE=-0.0001] 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 SZJDLUpV7rZ1 for ; Fri, 10 Jan 2014 22:04:25 -0800 (PST)
Received: from nm31.bullet.mail.ne1.yahoo.com (nm31.bullet.mail.ne1.yahoo.com [98.138.229.24]) by ietfa.amsl.com (Postfix) with ESMTP id 0B9E91AD94A for ; Fri, 10 Jan 2014 22:04:24 -0800 (PST)
Received: from [127.0.0.1] by nm31.bullet.mail.ne1.yahoo.com with NNFMP; 11 Jan 2014 06:04:14 -0000
Received: from [98.138.100.117] by nm31.bullet.mail.ne1.yahoo.com with NNFMP; 11 Jan 2014 06:01:19 -0000
Received: from [212.82.98.124] by tm108.bullet.mail.ne1.yahoo.com with NNFMP; 11 Jan 2014 06:01:18 -0000
Received: from [212.82.98.121] by tm17.bullet.mail.ir2.yahoo.com with NNFMP; 11 Jan 2014 06:01:18 -0000
Received: from [127.0.0.1] by omp1058.mail.ir2.yahoo.com with NNFMP; 11 Jan 2014 06:01:18 -0000
X-Yahoo-Newman-Property: ymail-4
X-Yahoo-Newman-Id: 744963.77123.bm@omp1058.mail.ir2.yahoo.com
Received: (qmail 90738 invoked by uid 60001); 11 Jan 2014 06:01:18 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.uk; s=s1024; t=1389420078; bh=g8RAM2FerkGMi9jSeG3HZyzkcPy0nhtxMSipj/ajrOk=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=fs0/BaFB/+nZ3xmk387e1/5agx/l9qDGWwG25gwxGeQrquMXDiw2m2PVZBryg+GinzDwgDuORlxoy0HVtp5pIohS954b72/ptVVmgGmFFLCUWx7Uhn7C6imPf94zwlzFsSVL9eWxueCNpR8uACXz7aTSctynLbG6sVcJfmhj6as=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.uk; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=qkxuvX4lDjmNqCGWR4vcmBZtVlL5emSqP5k5YkxkuuoHQXVOOuNxSY2zQMqp6t2RggvVmSB4QqX7nTgW+q1Wt6ZZGPv+lTdLt87CIb3FYArtY5vXPlIyUA2v1uiaXaBDtmxO9mOXUHosduBAvU5QwWhY6UE46BoaOep1AxqxCN0=;
X-YMail-OSG: wek2stEVM1nhGNcRKGLpAXbyo103W.C5Payr.UKQMIfldtC rfUHqoIHhDWpQP0KU4twNZ4dHF1le838FHORT7PxsXPxMEEACirASNnFHuqS 0aWWkgTegcE7Mr0YreeSf8bpLpan8mzYdDjNnVDfMmGgHyCqt1mV_O7d1NIb JImVIrQXb.br_d5_W8TQyxU68kfgJSVl6780_l4O..W8PC36X_qc2W2gGVqn fI4eWtsaUAzxwzIiCvY91Dj6GUbhTzxMwDT.jfCFKqGS41XK5TnGr76QFqa4 RUEhqr7ERzmHay13SzXkb2nGx1VTgcx5I.QNyaPvqC8EaIoV5UJWoA5VF2S8 6je2K_k8uj26kC1K9KvygWI7a5OCIODEmPSlJmTwRKhYX.MvI.FSG5Q6sxmZ TpuA81B_obiu9VRIWA.FnjCbJKC_k.C77QAHbbzBYkz5cFyku0D2EUJxwAhw k8mTiin4x3ifTe_K5x7wUBpqyLnc0XE6Jne3Bdt6FL9qM34G0HhmBH.T1RKc jPqu.3IK6v0LtOkyc6ejIY_kI1x1CJfArSmK5UmbEzzweyqrWm5BVWxbFKIG krBKPeJdzsMn.BwzzwEHxR7VEbO3CT9Ut4cWi5z48cQXR3Q7J6VCeWtdwdqi XuMiS0gFfTfgT_3Lktsodsqhs_.4.pNBiTxRg1WHD7Vx0xbLJzSxONpMJoiP A3xMDkSgnmPocKUIeReHLL5_SR0ZTFFw6zocM8v_jc8n.9buynXEHJvttwuh zOvxifs4OzF5oUysjDYHd_LTYuJfBHKv3
Received: from [62.255.133.203] by web171706.mail.ir2.yahoo.com via HTTP; Sat, 11 Jan 2014 06:01:18 GMT
X-Rocket-MIMEInfo: 002.001, RG9uZSwga2luZGx5IGNvbmZpcm0uwqAgCgpPbmx5IDEgZG9jIHJlbWFpbmluZ8KgIC1sZXR0ZXIgZnJvbSBDQQoKU2VudCBmcm9tIFlhaG9vIE1haWwgb24gQW5kcm9pZAoKATABAQEB
X-Mailer: YahooMailAndroidMobile/3.0.18 YahooMailWebService/0.8.172.614
Message-ID: <1389420078.62085.YahooMailAndroidMobile@web171706.mail.ir2.yahoo.com>
Date: Sat, 11 Jan 2014 06:01:18 +0000 (GMT)
From: Subhrajyoti De 
To: "dispatch@ietf.org" 
In-Reply-To: 
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="1708739093-1985182907-1389420078=:62085"
Subject: Re: [dispatch] dispatch Digest, Vol 58, Issue 13
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: Sat, 11 Jan 2014 06:04:27 -0000

--1708739093-1985182907-1389420078=:62085
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Done, kindly confirm.=A0 =0A=0AOnly 1 doc remaining=A0 -letter from CA=0A=
=0ASent from Yahoo Mail on Android=0A=0A
--1708739093-1985182907-1389420078=:62085
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable


Done, kindly confirm.  
=0A
Only 1 doc =
remaining  -letter from CA
=0A
Sent from Yahoo Mail on Android<=
/a>
=0A
            
=0A          =
      
=0A                    
=0A                    
=0A    =
                    
=0A                     =
       
=0A                            =0A                =
                From:=0A           =
                 =0A                            dispatch-request@ietf.o=
rg <dispatch-request@ietf.org>;                            
=0A   =
                         =0A                                To:=0A                            =0A     =
                        <dispatch@ietf.org>;                         =
                                                                           =
 
=0A                            =0A                                <=
span style=3D"font-weight:bold">Subject:=0A                         =
   =0A                            dispatch Digest, Vol 58, Issue 13    =
                        
=0A                            =0A          =
                      Sent:=0A     =
                       =0A                            Thu, Jan 9, 2014 =
6:30:10 AM                            
=0A                        
=
=0A                            
=0A                            =0A                         =
       =0A                                    =0A               =
                         =0A                                    =0A                =
                =0A                            
Send dispatch mailing list subm=
issions to
    dispatch@ietf.org

To subscribe or unsub=
scribe via the World Wide Web, visit
    https://www.iet=
f.org/mailman/listinfo/dispatch
or, via email, send a message with s=
ubject or body 'help' to
    dispatch-request@ietf.org

You can reach the person managing the list at
   =
; =
dispatch-owner@ietf.org

When replying, please edit your Subject =
line so it is more specific
than "Re: Contents of dispatch digest..."

Today's Topics:

   1. Re: New SIP digest algorithm
 ? Re:  New Version Notification
      for draft-joh=
ansson-dispatch-dane-sip-00.txt (Rifaat Shekh-Yusef)
   2. Re: New =
Version of
      draft-vanelburg-dispatch-private-network=
-ind (Shida Schubert)


------------------------------------------=
----------------------------

Message: 1
Date: Wed, 8 Jan 2014 15:=
56:17 -0500
From: Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>
To=
: "Cullen Jennings (fluffy)" <fluffy@cisco.com>
Cc: "dispatch@ietf.org list=
" <di=
spatch@ietf.org>
Subject: Re: [dispatch] New SIP digest algorithm=
 ? Re:  New Version
    Notification for
 draft-johansson-dispatch-dane-sip-00.txt
Message-ID:
  &nb=
sp; <CAGL6epJdY+ZG-v_vZB706Z9XbfX1n=3D6Ag8GnrK7atdSq4DP5Dg@mai=
l.gmail.com>
Content-Type: text/plain; charset=3D"iso-8859-1"
=

Thanks Cullen,

Updating the Digest mechanism should be simple an=
d straightforward to allow
us to address the algorithms limitation witho=
ut requiring major changes to
the deployed systems.

I agree that =
we need a better solution for SIP that would also allow us to
provide a =
better way of storing the passwords in the DB.
I have been thinking abou=
t other solutions, but did not have a chance to
look at OAuth yet; I wil=
l take a look.

Regards,
 Rifaat



On Wed, Jan 8, 201=
4 at 1:49 PM, Cullen Jennings (fluffy)
<fluffy@cisco.com>wrote:

>
&=
gt; On Jan 2, 2014, at 11:34 AM, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>
> wrote:
>
> > Hi Olle,
> >
> &g=
t;        >Can we improve upon MD5 digest authentica=
tion?
> >
> > Take a look at the following HTTPAuth WG do=
cument:
> > https://datatracker.ietf.org/doc/draft-=
ietf-httpauth-digest/
> >
> > I have been working on =
this for some time, with SIP in mind. This
> started as an attempt to=
 update RFC2617, and now it is a different document
> that will obsol=
ete RFC2617.
> > The document updates 3 aspects of RFC2617:
>=
; > 1. Algorithms agility: use of SHA2
> > 2.
 Internationalization
> > 3. Username hashing
> >
>=
 > I am planning on writing a document to update the digest algorithms f=
or
> SIP.
> >
> > Regards,
> >  Rifaa=
t
> >
> >
>
> I suspect that sip core would b=
e the best place to move forward a proposal
> like that. Personally, =
I would probably ague that moving to OAuth might be
> a better way to=
 move forward.
>
> Cullen (with my individual contribute hat on=
)
>
>
>
-------------- next part --------------
An =
HTML attachment was scrubbed...
URL: <http://www.ietf.org/mail-archive/web/dispatch/attachments/20=
140108/8f00018e/attachment.html>

----------------------------=
--

Message: 2
Date: Wed, 8 Jan 2014 22:29:49 -0800
From:
 Shida Schubert <shida@ntt-at.com>
To: Mary Barnes <mary.ietf.barne=
s@gmail.com>
Cc: DISPATCH <dispatch@ietf.org>
Subject: Re: [=
dispatch] New Version of
    draft-vanelburg-dispatch-pri=
vate-network-ind
Message-ID: <5863E5DF-F01A-44D=
C-B0E6-74D1763AE178@ntt-at.com>
Content-Type: text/plain; charset=
=3D"iso-8859-1"


Hi Mary;

 Thanks for reviewing the docume=
nt again. 

On Jan 6, 2014, at 3:03 PM, Mary Barnes <mary.ietf.ba=
rnes@gmail.com> wrote:

> Hi all,
> 
> I have r=
eviewed the
 revised version and I just a few final comments.
> 
> - Sectio=
n 1.5, first bullet in the bulleted list: either change "an emergency calls=
" to "an emergency call" or "emergency calls"
> 

 I will fix i=
t with "emergency calls"

> - Section 3.6.  "require the Spec=
ifying a Spec (T)." -> "require specifying a Spec(T)" or "require the sp=
ecification of a Spec(T)"
> 
 
 I will fix it with "require the=
 specification of a Spec(T)"

> - Section 5, I had suggested the t=
he requirements be consistent in usage of 2119 language.  One of the r=
equirements (R6) was changed, but R2 and R3 were not.  Was there a spe=
cific reason not to make those suggested changes?   
> 
> =
R2:   "The indication from R1 can be inserted by a SIP proxy" -> "T=
he indication from R1 MAY be inserted by a SIP proxy"   
> R3: "=
The indication from R1 can be removed by a SIP proxy" -> "The
 indication from R1 MAY be removed by a SIP proxy"

 So I reverted th=
e change after Keith told that the requirements above is not stating 
a =
normative behaviour and that he believes "can" is more appropriate. 
 I am okay either way. 

 I will create a version with "MAY". 
 Keith, please provide comments if you have a strong opposition to changi=
ng it to "MAY".

 Thanks! 
  Shida

> 
> Thank=
s,
> Mary. 
> 
> 
> On Tue, Oct 29, 2013 at 9:11 AM=
, Mary Barnes <mary.ietf.barnes@gmail.com> wrote:
> In rev=
iewing the document in preparation for the PROTO write-up, I have a few com=
ments (minor and nits) that should be addressed prior to the document being=
 progressed.
> 
> Regards,
> Mary.
> 
> Comme=
nts:
> ---------------
> 
> - General: domains used in
 this document must use a reserved domain such as "example.com" and must no=
t use real domains. Thus, all occurrences of ericsson.com need to be change=
d to example.com
> 
> - Section 1.5.  Bulleted list, first=
 bullet. I would suggest you just leave out the mention of LI.  Emerge=
ncy services should be a sufficient example.  
> 
> - Sect=
ion 1.5, last numbered list, item 2.  I had a hard time groking this s=
entence and had to read several times. I would suggest rewording something =
like (if I've properly interpreted the intent):
> OLD:
>  =
      Different nodes spanning over different networks may n=
eed to be
>        able to act differently on typ=
e of traffic, when implicit schemes
>        are =
used, it would require distribution of such enterprise
>   =
     specific logic over multiple nodes in multiple
 operators.  That
>        is clearly not a =
manageable architecture and solution.
> 
> NEW: 
>  =
      Nodes spanning multiple networks often need to have di=
fferent 
>        behavior depending upon the typ=
e of traffic.  When this is done using implicit
>    &=
nbsp;   schemes, enterprise specific logic must be distributed across =
multiple
>        nodes in multiple operator's ne=
tworks.  
>        That is clearly not a man=
ageable architecture and solution.
> 
> 
> - Section 1.5,=
 last sentence.  I don't think that statement is sufficient for what t=
his document is doing. I would suggest you change that sentence to somethin=
g like the following:
> OLD:
>    Given the above bac=
kground this document will formulate requirements
> 
   for SIP to support an explicit private network indication.
> =

> NEW: 
>    Based on the background provided, this =
document formulates requirements
>    for SIP to support an=
 explicit private network indication and defines 
>    a P-=
header, P-Private-Network-Indication, to support those requirements. 
&g=
t; 
> 
> - Section 3, next to last paragraph.  I'm not sur=
e what is meant by "the filling out a Spec(T)". I don't see "filling" used =
as a concept in RFC 3324.  Perhaps, "specifying a Spec(T)" is more con=
sistent with terminology in RFC 3324. 
> 
> - Section 5.  =
In general, the requirements are not specific consistently - i.e., some use=
 2119 language and others not and there is not consistent capitalization.&n=
bsp; I would suggest the following changes.
> R2:   "The indicat=
ion from R1 can be inserted by a SIP proxy" -> "The indication
 from R1 MAY be inserted by a SIP proxy"   
> R3: "The indicatio=
n from R1 can be removed by a SIP proxy" -> "The indication from R1 MAY =
be removed by a SIP proxy"
> R6: "must" -> "MUST"
> 
>=
 - Section 6, 2nd paragraph. The "can" in the first sentence should be a "M=
AY" and the sentence needs to be split into two:
> OLD:
> =
   A proxy server which handles a message can insert such a P-Private-=

>    Network-Indication header field into the message base=
d on
>    authentication of the source of a message, config=
uration or local
>    policy, and forward it to other proxi=
es in the same administrative
>    domain or proxies in tru=
sted domain to be handled as private network
>    traffic. =

> 
> NEW: 
>    A proxy server which handles a=
 message MAY insert such a P-Private-
>   
 Network-Indication header field into the message based on
>  &n=
bsp; authentication of the source of a message, configuration or local
&=
gt;    policy.  A proxy server MAY forward the message to ot=
her proxies in the 
>    same administrative domain or prox=
ies in a trusted 
>    domain to be handled as private netw=
ork traffic. 
> 
> 
> 
> Section 9.  You shoul=
d be explicit about the header name in this section.  The text in the =
first paragraph needs some work.  At a minimum you need to change the =
"not supposed to" to something more definitive as all security issues arise=
 because someone does something they're not supposed to.   I would sug=
gest at least making the following change:
> OLD:
>   =
; The private network indication defined in this document is to be used
=
>    in an environment where elements are trusted and
 where attackers are
>    not supposed to have access to th=
e protocol messages between those
>    elements.  Traf=
fic protection between network elements is sometimes
>    a=
chieved by using IPsec and sometimes by physical protection of the
>&=
nbsp;   network.  In any case, the environment where the private =
network
>    indication will be used ensures the integrity =
and the confidentiality
>    of the contents of this header=
 field.
> NEW:
>    The private network indication de=
fined in this document MUST only be used
>    in an environ=
ment where elements are trusted and where attackers are
>   =
; do not have access to the protocol messages between those
>  &=
nbsp; elements.  Traffic protection between network elements can be>    achieved by using IPsec and sometimes by physical
 protection of the
>    network.  In any case, the env=
ironment where the private network
>    indication will be =
used ensures the integrity and the confidentiality
>    of =
the contents of this header field.
> 
> 
> Nits:
> =
------
> - Section 1.1:  "3rd-Generqation" -> 3rd-Generation&=
nbsp; 
> - The terms "break-in" and "break-out" traffic are used seve=
ral places in the document, but this term is never defined.  These ter=
ms should be defined in Section 3. 
> - Figures should have Titles fo=
r readability
> 
> 
> 
> On Wed, Sep 11, 2013 at 9:=
19 PM, Mayumi Ohsugi <mayumi.ohsugi@ntt-at.co.jp> wrote:
>=
 Hi,
> 
> I have submitted the following draft:
> 
>=
; http://www.ietf.org/internet-drafts=
/draft-vanelburg-dispatch-private-network-ind-03.txt
> 
> T=
he draft reflects all the comments discussed in DISPATCH list.
> 
=
> The major changes are as follows:
> 
> - corrected the abs=
tract
> - corrected the term "common domain" to "pre-arranged domain"=

> - added 7.1.4 "P-Private-Network-Indication verification"
> =
- editorial changes
>             =
                     &nbs=
p;                     &n=
bsp;                     =
     Regards,
> Mayumi
> ____________________________=
___________________
> dispatch mailing list
> dispatch@i=
etf.org
> https://www.ietf.org/mailman/listinfo/dispatch
=
> 
> 

-------------- next part --------------
An HTML at=
tachment was scrubbed...
URL: <http://www.ietf.org/mail-archive/web/dispatch/attachments/20140108/=
d1ade163/attachment.html>

------------------------------
<=
BR>Subject: Digest Footer

__________________________________________=
_____
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/ma=
ilman/listinfo/dispatch


------------------------------
End of
 dispatch Digest, Vol 58, Issue 13
*************************************=
***
=0A         =
           
=0A                
=0A            
=0A
--1708739093-1985182907-1389420078=:62085--

From oej@edvina.net  Sat Jan 11 06:59:37 2014
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 37CEE1AE009 for ; Sat, 11 Jan 2014 06:59:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.55
X-Spam-Level: 
X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HTML_MESSAGE=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 ldTa8WpnX2c0 for ; Sat, 11 Jan 2014 06:59:34 -0800 (PST)
Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 981C31AE007 for ; Sat, 11 Jan 2014 06:59:33 -0800 (PST)
Received: from [192.168.40.13] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id E6F5993C2A1; Sat, 11 Jan 2014 14:59:21 +0000 (UTC)
Content-Type: multipart/alternative; boundary="Apple-Mail=_B055EE70-3924-4044-BF94-BFC0D6E24E6B"
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: "Olle E. Johansson" 
In-Reply-To: 
Date: Sat, 11 Jan 2014 15:59:20 +0100
Message-Id: 
References: <20140102101042.27427.64547.idtracker@ietfa.amsl.com> <0BA14051-5C7F-4416-8CD2-413347D540D3@edvina.net> <52C83591.3080702@alum.mit.edu>       
To: Rifaat Shekh-Yusef 
X-Mailer: Apple Mail (2.1827)
Cc: "dispatch@ietf.org list" 
Subject: Re: [dispatch] New Version Notification for draft-johansson-dispatch-dane-sip-00.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: Sat, 11 Jan 2014 14:59:37 -0000

--Apple-Mail=_B055EE70-3924-4044-BF94-BFC0D6E24E6B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1


On 08 Jan 2014, at 14:23, Rifaat Shekh-Yusef  =
wrote:

> The following is a quote from RFC6066, Section 3:
>=20
>    Currently, the only server names supported are DNS hostnames;
>    however, this does not imply any dependency of TLS on DNS, and =
other
>    name types may be added in the future (by an RFC that updates this
>    document).
>=20
> Should a new name_type be defined for this purpose, instead of =
overloading the host_name type?
>=20
You are right, we are not allowed to ask for a domain. Now, what's =
fastest - getting TLS implementations
that support a new "domain" name_type or SIP-domain name type or =
DNSsec/Dane? :-)


If we need to add a new name_type - I guess that's work outside of RAI, =
maybe in the TLS wg. I don't see RFC 6066 defining an IANA registry for =
name_types even though it mentions that more name types can be added by =
RFCs.

Summary: In order for SIP domain certs to use SNI we do need to write an =
RFC that defines new name types when asking for a domain or a SIP URI =
that matches a SIP domain certificate. We might have to add a new IANA =
registry. Then we need code for this is the TLS libraries.

/O
> Regards,
>  Rifaat
>=20
>=20
>=20
> On Wed, Jan 8, 2014 at 4:06 AM, I=F1aki Baz Castillo  =
wrote:
> 2014/1/8 Olle E. Johansson :
> >> Honestly I've never understood the real difference between a domain
> >> and a hostname. Of course, IMHO, the SIP client should provide in =
the
> >> SNI the destination domain of the server it is attempting to =
connect
> >> to.
> > Right, but...
> >
> > Does anyone find this in any published document?
>=20
> Not AFAIK :)
> But in this case SIP should follow well proven mechanisms and rules of =
HTTP(s).
>=20
>=20
> --
> I=F1aki Baz Castillo
> 
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>=20


--Apple-Mail=_B055EE70-3924-4044-BF94-BFC0D6E24E6B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=iso-8859-1


On 08 Jan 2014, at 14:23, Rifaat =
Shekh-Yusef <rifaat.ietf@gmail.com> =
wrote:

The =
following is a quote from RFC6066, Section 3:

   Currently, =
the only server names supported are DNS hostnames;
   however, this does not imply any dependency of TLS on DNS, and other
   name types may be added in the future (by an RFC that updates this
   document).

Should a new name_type be defined for this purpose, instead =
of overloading the host_name =
type?



You =
are right, we are not allowed to ask for a domain. Now, what's fastest - =
getting TLS implementations
that support a new "domain" =
name_type or SIP-domain name type or DNSsec/Dane? =
:-)


If we need to add a new =
name_type - I guess that's work outside of RAI, maybe in the TLS wg. I =
don't see RFC 6066 defining an IANA registry for name_types even though =
it mentions that more name types can be added by =
RFCs.

Summary: In order for SIP domain certs to =
use SNI we do need to write an RFC that defines new name types when =
asking for a domain or a SIP URI that matches a SIP domain certificate. =
We might have to add a new IANA registry. Then we need code for this is =
the TLS libraries.

/O
Regards,
 Rifaat





On Wed, Jan 8, =
2014 at 4:06 AM, I=F1aki Baz Castillo <ibc@aliax.net> wrote:


2014/1/8 Olle E. =
Johansson <oej@edvina.net>:


>> Honestly I've never understood the real =
difference between a domain

>> and a hostname. Of course, IMHO, the SIP client should provide =
in the

>> SNI the destination domain of the server it is attempting to =
connect

>> to.

> Right, but...

>

> Does anyone find this in any published document?




Not AFAIK :)

But in this case SIP should follow well proven mechanisms and rules of =
HTTP(s).






--

I=F1aki Baz Castillo

<ibc@aliax.net>


_______________________________________________

dispatch mailing list

dispatch@ietf.org

https://www.ietf.org/mailman/listinfo/dispatch






=

--Apple-Mail=_B055EE70-3924-4044-BF94-BFC0D6E24E6B--

From ben@nostrum.com  Sat Jan 11 13:54:24 2014
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 D889F1A1F61; Sat, 11 Jan 2014 13:54:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.036
X-Spam-Level: 
X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] 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 eR3gv9N-ruNk; Sat, 11 Jan 2014 13:54:22 -0800 (PST)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 1E4C81A1F4C; Sat, 11 Jan 2014 13:54:22 -0800 (PST)
Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id s0BLs7YL076321 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 11 Jan 2014 15:54:08 -0600 (CST) (envelope-from ben@nostrum.com)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Ben Campbell 
In-Reply-To: <45B84D8F-AD8C-4B28-90DF-9B1C40771104@nostrum.com>
Date: Sat, 11 Jan 2014 15:54:08 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <6833E320-7B45-4FC2-853B-62311DCF7E7B@nostrum.com>
References: <45B84D8F-AD8C-4B28-90DF-9B1C40771104@nostrum.com>
To: draft-pd-dispatch-msrp-websocket.all@tools.ietf.org, Mary Barnes 
X-Mailer: Apple Mail (2.1827)
Received-SPF: pass (shaman.nostrum.com: 173.172.146.58 is authenticated by a trusted mechanism)
Cc: DISPATCH , rai@ietf.org
Subject: Re: [dispatch] [RAI] MSRP Expert Review of draft-pd-dispatch-msrp-websocket-04
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: Sat, 11 Jan 2014 21:54:25 -0000

On Jan 10, 2014, at 5:34 PM, Ben Campbell  wrote:

> --3
>=20
> I am not happy with the downgrade of of the TLS requirement between =
client and relay. I recognize that WebSocket

Robert pointed out to me that my comments on this section were =
truncated. Apparently I'm not qualified for this email gizmo. Here's =
another try:

I recognize that the WebSocket API limits the application's ability to =
control the security parameters of the connection. I think this is a =
general issue for moving application protocols to use WebSocket, that =
perhaps needs to be addressed in the WebSocket API.  We probably need an =
whole IETF (or at least RAI+APPS) policy for how to handle this. But =
MSRP is somewhat unusual in having a "MUST use" TLS requirement, and in =
the current security climate we need to take a really hard look at =
anything that weakens the normative security requirements of a messaging =
protocol.

I don't have an answer for how to proceed, but at a minimum I would like =
to see considerably more discussion of the implications and any =
potential mitigation of this in the Security Considerations sections.=

From peter.dunkley@crocodilertc.net  Mon Jan 13 01:41:32 2014
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 773C81AE112 for ; Mon, 13 Jan 2014 01:41:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level: 
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=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 kvfxuimIBFdl for ; Mon, 13 Jan 2014 01:41:31 -0800 (PST)
Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) by ietfa.amsl.com (Postfix) with ESMTP id B9D761AE0E0 for ; Mon, 13 Jan 2014 01:41:30 -0800 (PST)
Received: by mail-ig0-f177.google.com with SMTP id k19so2262684igc.4 for ; Mon, 13 Jan 2014 01:41:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=crocodilertc.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=aoOSuxZahC5jk4/90nAXLdbeGOzhh2xwQzhIhvPGBrA=; b=j1Is20oUtVyG60avExKBuSqPC8eQaiH9wEB3f4e5b0ILfEap4Gmafuy1EMmVeJrQYe a4GCsMOEGtIOlxw4iawjV6iAG9gOf3cqoe5NTaY1hILrn/h9Rs7fOkSCXbc4WN6oqbg+ uUQog3UF+XaQ5uRIiJufA++o3PAN0Qa/t+AA4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=aoOSuxZahC5jk4/90nAXLdbeGOzhh2xwQzhIhvPGBrA=; b=RvPFzaAMWJ3UW6BwKB7sNPYl1IeapGGbuCNM/gbWt6mFyomeBVx12FiqHnGusEIETU IJL84J65IlUStR+OR26K0MpJy8KdAtWE+UmxNylCmdEczOZ9KXPbU1DDt5niTwL+MoNp GRIctgTW0ZjpSLqDUrZomma2qUo54gYiORj38oTqubWSQUURKnbQY4OvrkmpVlRB2Lzm yTBNgDRTKsowru5USzI88w3FUpcJ4xtJyhMMWJ4YAbvo9bc51596YozshatyTh3JOCa7 gylKI0Vshsv9YtGB4CIt1Jaqsxuw/LbEZ5TU+JBkMh4EJ65HgLjgoKY2t3NyL0sVrkGb +2qA==
X-Gm-Message-State: ALoCoQmWS6uyFmBz80+o9WxK/Jq5mgXfNyoJMGlTWMslUO5kAS18yQ+AJZXA+aRj1rM66aHdNXyF
MIME-Version: 1.0
X-Received: by 10.50.66.208 with SMTP id h16mr18538393igt.0.1389606079802; Mon, 13 Jan 2014 01:41:19 -0800 (PST)
Received: by 10.64.229.13 with HTTP; Mon, 13 Jan 2014 01:41:19 -0800 (PST)
In-Reply-To: <6833E320-7B45-4FC2-853B-62311DCF7E7B@nostrum.com>
References: <45B84D8F-AD8C-4B28-90DF-9B1C40771104@nostrum.com> <6833E320-7B45-4FC2-853B-62311DCF7E7B@nostrum.com>
Date: Mon, 13 Jan 2014 09:41:19 +0000
Message-ID: 
From: Peter Dunkley 
To: Ben Campbell 
Content-Type: multipart/alternative; boundary=047d7bdca4fec3c18f04efd6e030
Cc: DISPATCH , draft-pd-dispatch-msrp-websocket.all@tools.ietf.org, rai@ietf.org
Subject: Re: [dispatch] [RAI] MSRP Expert Review of draft-pd-dispatch-msrp-websocket-04
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: Mon, 13 Jan 2014 09:41:32 -0000

--047d7bdca4fec3c18f04efd6e030
Content-Type: text/plain; charset=ISO-8859-1

On 11 January 2014 21:54, Ben Campbell  wrote:

>
> I don't have an answer for how to proceed, but at a minimum I would like
> to see considerably more discussion of the implications and any potential
> mitigation of this in the Security Considerations sections.
>

More discussion is certainly needed here.  The reason I chose to downgrade
the security here was purely pragmatic.

As nice as it would be to make the security requirements for MSRP over
WebSockets very strict it would also be utterly pointless as (right now and
for the foreseeable future) it would not be possible to implement.

Regards,

Peter

-- 
Peter Dunkley
Technical Director
Crocodile RCS Ltd

--047d7bdca4fec3c18f04efd6e030
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable




--047d7bf0d2de83131504efe00c06--

From ben@nostrum.com  Mon Jan 13 14:43:51 2014
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 37BE81A1F4E; Mon, 13 Jan 2014 14:43:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.036
X-Spam-Level: 
X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] 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 vCIkBjYDG7wt; Mon, 13 Jan 2014 14:43:50 -0800 (PST)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 1B9EA1A1F1B; Mon, 13 Jan 2014 14:43:50 -0800 (PST)
Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id s0DMhWN4002882 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 13 Jan 2014 16:43:33 -0600 (CST) (envelope-from ben@nostrum.com)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Ben Campbell 
In-Reply-To: 
Date: Mon, 13 Jan 2014 16:43:34 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <8DB83E85-08E6-44DB-AF0F-FE135687F8A2@nostrum.com>
References: <45B84D8F-AD8C-4B28-90DF-9B1C40771104@nostrum.com> <6833E320-7B45-4FC2-853B-62311DCF7E7B@nostrum.com> 
To: Peter Dunkley 
X-Mailer: Apple Mail (2.1827)
Received-SPF: pass (shaman.nostrum.com: 173.172.146.58 is authenticated by a trusted mechanism)
Cc: draft-pd-dispatch-msrp-websocket.all@tools.ietf.org, DISPATCH , rai@ietf.org
Subject: Re: [dispatch] [RAI] MSRP Expert Review of draft-pd-dispatch-msrp-websocket-04
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: Mon, 13 Jan 2014 22:43:51 -0000

On Jan 13, 2014, at 3:41 AM, Peter Dunkley =
 wrote:

> On 11 January 2014 21:54, Ben Campbell  wrote:
>=20
> I don't have an answer for how to proceed, but at a minimum I would =
like to see considerably more discussion of the implications and any =
potential mitigation of this in the Security Considerations sections.
>=20
> More discussion is certainly needed here.  The reason I chose to =
downgrade the security here was purely pragmatic.
>=20
> As nice as it would be to make the security requirements for MSRP over =
WebSockets very strict it would also be utterly pointless as (right now =
and for the foreseeable future) it would not be possible to implement.

Understood. I think the conversation needs to cover the general case of =
"how do we handle things when new transport options take security =
decisions away from the application protocol implementations". MSRP is =
an especially interesting case due to the MUST USE requirement in RFC =
4976.

Maybe that's already been discussed, but if so I've missed it.

Ben.=

From R.Jesske@telekom.de  Tue Jan 14 23:55:18 2014
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 E0A201AE335 for ; Tue, 14 Jan 2014 23:55:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.486
X-Spam-Level: 
X-Spam-Status: No, score=-2.486 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.538] 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 vQrNSyocGN_0 for ; Tue, 14 Jan 2014 23:55:04 -0800 (PST)
Received: from tcmail93.telekom.de (tcmail93.telekom.de [80.149.113.205]) by ietfa.amsl.com (Postfix) with ESMTP id 18F0B1AE050 for ; Tue, 14 Jan 2014 23:55:02 -0800 (PST)
Received: from he113445.emea1.cds.t-internal.com ([10.134.93.105]) by tcmail91.telekom.de with ESMTP/TLS/AES128-SHA; 15 Jan 2014 08:54:50 +0100
Received: from HE113667.emea1.cds.t-internal.com ([fe80::c943:1394:e86e:fce3]) by HE113445.emea1.cds.t-internal.com ([::1]) with mapi; Wed, 15 Jan 2014 08:54:49 +0100
From: 
To: , 
Date: Wed, 15 Jan 2014 08:54:18 +0100
Thread-Topic: [dispatch] PROTO Review: draft-drage-sipping-rfc3455bis-09.txt
Thread-Index: Ac8OPO8VPDjmjXIVQFOXyuuRA7vPZwDiWuwg
Message-ID: <058CE00BD4D6B94FAD033A2439EA1E4B01DF8EE7BA91@HE113667.emea1.cds.t-internal.com>
References:   
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_058CE00BD4D6B94FAD033A2439EA1E4B01DF8EE7BA91HE113667eme_"
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: Wed, 15 Jan 2014 07:55:18 -0000

--_000_058CE00BD4D6B94FAD033A2439EA1E4B01DF8EE7BA91HE113667eme_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Mary,
Version -13 is uploaded. (http://www.ietf.org/internet-drafts/draft-drage-s=
ipping-rfc3455bis-13.txt )
I hope I have covered everything now.
-RFC references not used deleted.
-FQDN corrected
-statement that RFC3455 is obsolete included in Head and Abstract

Best Regards

Roland

Von: Mary Barnes [mailto:mary.ietf.barnes@gmail.com]
Gesendet: Freitag, 10. Januar 2014 20:48
An: Andrew Allen
Cc: Jesske, Roland; dispatch@ietf.org; dean.willis@softarmor.com
Betreff: Re: [dispatch] PROTO Review: draft-drage-sipping-rfc3455bis-09.txt

Thanks Andrew.  So, that needs to be clearly stated in the abstract as well=
.  In addition, the Overview section states:
"This document is an update to RFC3455".  So that also needs to be fixed.  =
 Given the number of changes at this point, I would now prefer Roland make =
those changes before we ask Gonzalo to progress it to IETF LC.

Mary.

On Fri, Jan 10, 2014 at 1:45 PM, Andrew Allen > wrote:

I think it obsoletes RFC 3455. It is a complete replacement for the origina=
l.

Andrew

From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com]
Sent: Friday, January 10, 2014 02:37 PM Eastern Standard Time
To: R.Jesske@telekom.de >
Cc: DISPATCH >; Dean Willis >
Subject: Re: [dispatch] PROTO Review: draft-drage-sipping-rfc3455bis-09.txt

There is yet one more change needed.  This document is an Updates to 3455bi=
s (AFAIK, unless Obseletes works better for 3GPP usage).  That categorizati=
on needs to be included in the document header (3rd line).

Thanks,
Mary.

On Fri, Jan 10, 2014 at 1:34 PM, Mary Barnes > wrote:
IN addition to removing the unused references in the next update, there are=
 still 4 domain names that are not using an appropriate documentation domai=
n (e.g., home.net).  Please add that change to the list fo=
r the next revision.  I'm going to ahead and forward the PROTO write-up to =
Gonzalo, noting the changes that are needed and suggesting those changes ca=
n be made along with other IETF LC changes.

Thanks,
Mary

On Wed, Jan 8, 2014 at 2:46 AM, > wrote:
Thank you Marry,
for doing all this review.
So I have now put out the errors.
There are still some unused references which are in our informal reference =
section. But useful for the reader to know they exist.
There are also some warnings with regard to IP addresses and wrong FQDNs wh=
ich I think is some interpretation of strings in the text which are not mea=
nt to be a IP address or FQDN at all.

Detail see below.

So now hopefully everything is ready for the next step.

Best Regards

Roland

tmp/draft-drage-sipping-rfc3455bis-12.txt:

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  http://trustee.ietf.org/license-info):
  -------------------------------------------------------------------------=
---

     No issues found here.

  Checking nits according to http://www.ietf.org/id-info/1id-guidelines.txt=
:
  -------------------------------------------------------------------------=
---

     No issues found here.

  Checking nits according to http://www.ietf.org/id-info/checklist :
  -------------------------------------------------------------------------=
---

 =3D=3D There are 4 instances of lines with non-RFC2606-compliant FQDNs in =
the
     document.

  =3D=3D There are 4 instances of lines with non-RFC5735-compliant IPv4 add=
resses
     in the document.  If these are example addresses, they should be chang=
ed.


  Miscellaneous warnings:
  -------------------------------------------------------------------------=
---

     No issues found here.

  Checking references for intended status: Informational
  -------------------------------------------------------------------------=
---

  =3D=3D Missing Reference: 'RFC XXXX' is mentioned on line 1662, but not d=
efined

  -- Looks like a reference, but probably isn't: '3' on line 1943

  =3D=3D Unused Reference: 'RFC3262' is defined on line 2068, but no explic=
it
     reference was found in the text

  =3D=3D Unused Reference: 'RFC3311' is defined on line 2072, but no explic=
it
     reference was found in the text

  =3D=3D Unused Reference: 'RFC3428' is defined on line 2078, but no explic=
it
     reference was found in the text

  =3D=3D Unused Reference: 'RFC3903' is defined on line 2090, but no explic=
it
     reference was found in the text

  =3D=3D Unused Reference: 'RFC6086' is defined on line 2101, but no explic=
it
     reference was found in the text


     Summary: 0 errors (**), 0 flaws (~~), 8 warnings (=3D=3D), 1 comment (=
--).

     Run idnits with the --verbose option for more detailed information abo=
ut
     the items above.
---------------------------------------------------------------------------=
-----



Von: Mary Barnes [mailto:mary.ietf.barnes@gmail.com]
Gesendet: Dienstag, 7. Januar 2014 18:55

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

Thanks Roland.  I have reviewed that version and all the changes I suggeste=
d have been made.  However, in doing the PROTO write-up I realized that I w=
asn't certain anyone had reviewed the ABNF. So, I ran the ABNF through Bill=
 Fenner's tool:
http://tools.ietf.org/tools/bap/abnf.cgi

And, there are a couple things that need to be fixed:
1)  DOT needs to change to "." (we had this same bug in RFC 4244):
transit-ioi-indexed-value =3D transit-ioi-name DOT transit-ioi-index

2)  There's an extra space here (between * and parenthesis):
transit-ioi-name          =3D ALPHA * (ALPHA / DIGIT)
NEw: transit-ioi-name          =3D ALPHA *(ALPHA / DIGIT)

There are also a number of long lines in the ABNF that should be fixed.

In addition, IDNITS identifies other errors and warnings per the following.=
  Those should also be addressed including considering whether obsolete ref=
erences need changing:



idnits 2.13.01



tmp/draft-drage-sipping-rfc3455bis-11.txt:



  Checking boilerplate required by RFC 5378 and the IETF Trust (see

  http://trustee.ietf.org/license-info):

  -------------------------------------------------------------------------=
---



     No issues found here.



  Checking nits according to http://www.ietf.org/id-info/1id-guidelines.txt=
:

  -------------------------------------------------------------------------=
---



     No issues found here.



  Checking nits according to http://www.ietf.org/id-info/checklist :

  -------------------------------------------------------------------------=
---



  ** There are 9 instances of too long lines in the document, the longest o=
ne

     being 20 characters in excess of 72.



  =3D=3D There are 4 instances of lines with non-RFC2606-compliant FQDNs in=
 the

     document.



  =3D=3D There are 4 instances of lines with non-RFC5735-compliant IPv4 add=
resses

     in the document.  If these are example addresses, they should be chang=
ed.





  Miscellaneous warnings:

  -------------------------------------------------------------------------=
---



  =3D=3D The document seems to contain a disclaimer for pre-RFC5378 work, b=
ut was

     first submitted on or after 10 November 2008.  The disclaimer is usual=
ly

     necessary only for documents that revise or obsolete older RFCs, and t=
hat

     take significant amounts of text from those RFCs.  If you can contact =
all

     authors of the source material and they are willing to grant the BCP78

     rights to the IETF Trust, you can and should remove the disclaimer.

     Otherwise, the disclaimer is needed and you can ignore this comment.

     (See the Legal Provisions document at

     http://trustee.ietf.org/license-info for more information.)





  Checking references for intended status: Informational

  -------------------------------------------------------------------------=
---



  =3D=3D Missing Reference: 'RFC XXXX' is mentioned on line 1667, but not d=
efined



  -- Looks like a reference, but probably isn't: '3' on line 1948



  =3D=3D Unused Reference: 'RFC2976' is defined on line 2065, but no explic=
it

     reference was found in the text



  =3D=3D Unused Reference: 'RFC3262' is defined on line 2068, but no explic=
it

     reference was found in the text



  =3D=3D Unused Reference: 'RFC3311' is defined on line 2075, but no explic=
it

     reference was found in the text



  =3D=3D Unused Reference: 'RFC3428' is defined on line 2081, but no explic=
it

     reference was found in the text



  =3D=3D Unused Reference: 'RFC3903' is defined on line 2093, but no explic=
it

     reference was found in the text



  ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234)



  -- Obsolete informational reference (is this intentional?): RFC 2976

     (Obsoleted by RFC 6086)



  -- Obsolete informational reference (is this intentional?): RFC 3265

     (Obsoleted by RFC 6665)





     Summary: 2 errors (**), 0 flaws (~~), 9 warnings (=3D=3D), 3 comments =
(--).



     Run idnits with the --verbose option for more detailed information abo=
ut

     the items above.
While I apologize for not catching these issues earlier, it really is the r=
esponsibility of authors to check idnits (beyond what the submission tool r=
equires) for their documents.  I routinely run idnits before I submit a doc=
ument as it can also save time when fixing the  nits that the submission to=
ol catches:   https://tools.ietf.org/tools/idnits/

Regards,
Mary.



On Tue, Jan 7, 2014 at 12:35 AM, > wrote:
Hi Mary,
Now a new revision is available.

Thank you and Best Regards

Roland

Von: Mary Barnes [mailto:mary.ietf.barnes@gmail.com]
Gesendet: Montag, 6. Januar 2014 20:00

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

Hi Roland,

One final editorial nit below.  If you can spin a revision, then I'll send =
the PROTO write-up to the AD.

Thanks,
Mary.

On Thu, Jan 2, 2014 at 3:29 AM, > wrote:
Hi Mary,
I wish you a happy new year 2014. And the best for the next year.

I was looking again on my changes I made due to your proposal in December.
I realized that if I change the SHOULD to MUST we have now a backward compa=
tibility problem.
We are using the P-Associated-URI also over the IMS user interface which is=
 not encrypted.
So I propose to add some more words.
...
Section 6.1
...
         An eavesdropper could possibly collect the list of identities a=
 user is registered.
       This can have privacy implications. To mitigate this problem, this e=
xtension SHOULD
       only be used in a secured environment, where encryption of SIP messa=
ges is
       provided either end-to-end or hop-by-hop.  

       Since the P-Associated-URI header field value allows to implicitl=
y register
      a bundle of URIs with one REGISTER Message the impact of security usi=
ng the P-Associated-URI header field is not higher than
      using single REGISTER messages when registering all identities explic=
it.
[MB] I just have some editorial suggestions for the above:
NEW:
 While the P-Associated-URI header field value allows the implicit regis=
tration of
      a bundle of URIs with one REGISTER Message the impact of security usi=
ng the P-Associated-URI header field is no higher than
      using separate REGISTER messages for each of the URIs. 
[/MB]




For the P-Called-Party-Id the change should be also done like as follows:

        An eavesdropper could possibly collect the list of identities a =
user is registered.
       This can have privacy implications.  To mitigate this problem, this =
extension SHOULD
       only be used in a secured environment, where encryption of SIP messa=
ges is
       provided either end-to-end or hop-by-hop.  

        Normally within a 3GPP environment the P-Called-Party-ID is not =
sent towards end users but may be exchanged between carriers where other se=
curity mechanisms than SIP encryption are used.  

Sorry coming so late.
If this is OK for you I will include it to a new version.

Thank you and Best Regards

Roland

Von: Mary Barnes [mailto:mary.ietf.barnes@gmail.com]
Gesendet: Freitag, 27. Dezember 2013 19:45

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 making these changes. I finally had a chance to review this upda=
ted 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 "potentia=
lly 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 th=
e next paragraph that provides details of the impacts.  I think you could p=
robably 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" tha=
t makes this header not of particular concern with regards to security. Doe=
s it reveal additional, unique information about an individual that isn't a=
vailable 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 reg=
istered.  This can have privacy implications.  To mitigate this problem, th=
is extension MUST only be used in a secured environment, where encryption o=
f 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 revis=
ion.  And, I believe you still need to identify privacy/security implicatio=
ns 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 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
  -






---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential info=
rmation, privileged material (including material protected by the solicitor=
-client or other applicable privileges), or constitute non-public informati=
on. Any use of this information by anyone other than the intended recipient=
 is prohibited. If you have received this transmission in error, please imm=
ediately reply to the sender and delete this information from your system. =
Use, dissemination, distribution, or reproduction of this transmission by u=
nintended recipients is not authorized and may be unlawful.


--_000_058CE00BD4D6B94FAD033A2439EA1E4B01DF8EE7BA91HE113667eme_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


On 1=
1 January 2014 21:54, Ben Campbell <ben@nostrum.com> wrote:




I don't have an answer for how to proceed, but at a minimum I would lik=
e to see considerably more discussion of the implications and any potential=
 mitigation of this in the Security Considerations sections.



More discussion is certainly needed here. =
=A0The reason I chose to downgrade the security here was purely pragmatic.<=
/div>

As nice as it would be to make the security requir=
ements for MSRP over WebSockets very strict it would also be utterly pointl=
ess as (right now and for the foreseeable future) it would not be possible =
to implement.



Regards,

Peter

-- 
Peter Dunkley<=
/div>

Technical Director
<=
font face=3D"courier new, monospace">Crocodile RCS Ltd




--047d7bdca4fec3c18f04efd6e030--

From shida@ntt-at.com  Mon Jan 13 12:32:37 2014
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 D76911AE026 for ; Mon, 13 Jan 2014 12:32:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_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 kypVPK9XhFdl for ; Mon, 13 Jan 2014 12:32:32 -0800 (PST)
Received: from gator4135.hostgator.com (gator4135.hostgator.com [192.185.4.147]) by ietfa.amsl.com (Postfix) with ESMTP id 2E9A61AE01C for ; Mon, 13 Jan 2014 12:32:32 -0800 (PST)
Received: from [208.66.25.2] (port=64252 helo=[192.168.1.23]) by gator4135.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1W2oBI-0000B2-1l; Mon, 13 Jan 2014 14:32:20 -0600
Content-Type: multipart/alternative; boundary="Apple-Mail=_5257B5F7-0116-4F7D-AEA6-C9182E1FF452"
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
From: Shida Schubert 
In-Reply-To: 
Date: Mon, 13 Jan 2014 12:32:17 -0800
Message-Id: 
References: <20130912005949.3447.42089.idtracker@ietfa.amsl.com> <523124B0.2000305@ntt-at.co.jp>   <5863E5DF-F01A-44DC-B0E6-74D1763AE178@ntt-at.com> <949EF20990823C4C85C18D59AA11AD8B100BA1@FR712WXCHMBA11.zeu.alcatel-lucent.com> 
To: Mary Barnes 
X-Mailer: Apple Mail (2.1822)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - gator4135.hostgator.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - ntt-at.com
X-BWhitelist: no
X-Source-IP: 208.66.25.2
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: ([192.168.1.23]) [208.66.25.2]:64252
X-Source-Auth: shida.schubert+tingle.jp
X-Email-Count: 1
X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQxMzUuaG9zdGdhdG9yLmNvbQ==
Cc: DISPATCH 
Subject: Re: [dispatch] New Version of draft-vanelburg-dispatch-private-network-ind
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: Mon, 13 Jan 2014 20:32:38 -0000

--Apple-Mail=_5257B5F7-0116-4F7D-AEA6-C9182E1FF452
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1


Why don't we just reword it to say=20

 "SIP proxy MAY insert the indication from R1"=20

 Whether it is a can or MAY what we are ultimately trying to say is that=20=

proxy MAY insert the indication from R1 right? We are not preventing=20
it and I am assuming as a spec, we want to let the implementer know=20
that proxy MAY send requests with these values.=20

 Regards
  Shida

On Jan 9, 2014, at 7:22 AM, Mary Barnes  =
wrote:

> Then, why are those even requirements? =20
>=20
> Mary.=20
>=20
>=20
> On Thu, Jan 9, 2014 at 5:05 AM, DRAGE, Keith (Keith) =
 wrote:
> The text from RFC 2119 states:
> =20
>  5. MAY   This word, or the adjective "OPTIONAL", mean that an item is
>    truly optional.  One vendor may choose to include the item because =
a
>    particular marketplace requires it or because the vendor feels that
>    it enhances the product while another vendor may omit the same =
item.
>    An implementation which does not include a particular option MUST =
be
>    prepared to interoperate with another implementation which does
>    include the option, though perhaps with reduced functionality. In =
the
>    same vein an implementation which does include a particular option
>    MUST be prepared to interoperate with another implementation which
>    does not include the option (except, of course, for the feature the
>    option provides.)
> My belief is that we are not defining an option here, and it is =
certainly not a vendor decision. Further we are not identifying an =
interoperability issue here.
> We are defining a possibility that a valid implementation can take.=20
>  If you go to the procedures you will see both these items are covered =
with "If  MUST" type sentences. There is no specified =
optionality.
>  Keith
> From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Shida =
Schubert
> Sent: 09 January 2014 06:30
> To: Mary Barnes
>=20
> Cc: DISPATCH
> Subject: Re: [dispatch] New Version of =
draft-vanelburg-dispatch-private-network-ind
>=20
>=20
> Hi Mary;
>=20
>  Thanks for reviewing the document again.=20
>=20
> On Jan 6, 2014, at 3:03 PM, Mary Barnes  =
wrote:
>=20
>> Hi all,
>>=20
>> I have reviewed the revised version and I just a few final comments.
>>=20
>> - Section 1.5, first bullet in the bulleted list: either change "an =
emergency calls" to "an emergency call" or "emergency calls"
>>=20
>=20
>  I will fix it with "emergency calls"
>=20
>> - Section 3.6.  "require the Specifying a Spec (T)." -> "require =
specifying a Spec(T)" or "require the specification of a Spec(T)"
>>=20
> =20
>  I will fix it with "require the specification of a Spec(T)"
>=20
>> - Section 5, I had suggested the the requirements be consistent in =
usage of 2119 language.  One of the requirements (R6) was changed, but =
R2 and R3 were not.  Was there a specific reason not to make those =
suggested changes?  =20
>>=20
>> R2:   "The indication from R1 can be inserted by a SIP proxy" -> "The =
indication from R1 MAY be inserted by a SIP proxy"  =20
>> R3: "The indication from R1 can be removed by a SIP proxy" -> "The =
indication from R1 MAY be removed by a SIP proxy"
>=20
>  So I reverted the change after Keith told that the requirements above =
is not stating=20
> a normative behaviour and that he believes "can" is more appropriate.=20=

>=20
>  I am okay either way.=20
>=20
>  I will create a version with "MAY".=20
>=20
>  Keith, please provide comments if you have a strong opposition to =
changing it to "MAY".
>=20
>  Thanks!=20
>   Shida
>=20
>>=20
>> Thanks,
>> Mary.=20
>>=20
>>=20
>> On Tue, Oct 29, 2013 at 9:11 AM, Mary Barnes =
 wrote:
>> In reviewing the document in preparation for the PROTO write-up, I =
have a few comments (minor and nits) that should be addressed prior to =
the document being progressed.
>>=20
>> Regards,
>> Mary.
>>=20
>> Comments:
>> ---------------
>>=20
>> - General: domains used in this document must use a reserved domain =
such as "example.com" and must not use real domains. Thus, all =
occurrences of ericsson.com need to be changed to example.com
>>=20
>> - Section 1.5.  Bulleted list, first bullet. I would suggest you just =
leave out the mention of LI.  Emergency services should be a sufficient =
example. =20
>>=20
>> - Section 1.5, last numbered list, item 2.  I had a hard time groking =
this sentence and had to read several times. I would suggest rewording =
something like (if I've properly interpreted the intent):
>> OLD:
>>        Different nodes spanning over different networks may need to =
be
>>        able to act differently on type of traffic, when implicit =
schemes
>>        are used, it would require distribution of such enterprise
>>        specific logic over multiple nodes in multiple operators.  =
That
>>        is clearly not a manageable architecture and solution.
>>=20
>> NEW:=20
>>        Nodes spanning multiple networks often need to have different=20=

>>        behavior depending upon the type of traffic.  When this is =
done using implicit
>>        schemes, enterprise specific logic must be distributed across =
multiple
>>        nodes in multiple operator's networks. =20
>>        That is clearly not a manageable architecture and solution.
>>=20
>>=20
>> - Section 1.5, last sentence.  I don't think that statement is =
sufficient for what this document is doing. I would suggest you change =
that sentence to something like the following:
>> OLD:
>>    Given the above background this document will formulate =
requirements
>>    for SIP to support an explicit private network indication.
>>=20
>> NEW:=20
>>    Based on the background provided, this document formulates =
requirements
>>    for SIP to support an explicit private network indication and =
defines=20
>>    a P-header, P-Private-Network-Indication, to support those =
requirements.=20
>>=20
>>=20
>> - Section 3, next to last paragraph.  I'm not sure what is meant by =
"the filling out a Spec(T)". I don't see "filling" used as a concept in =
RFC 3324.  Perhaps, "specifying a Spec(T)" is more consistent with =
terminology in RFC 3324.=20
>>=20
>> - Section 5.  In general, the requirements are not specific =
consistently - i.e., some use 2119 language and others not and there is =
not consistent capitalization.  I would suggest the following changes.
>> R2:   "The indication from R1 can be inserted by a SIP proxy" -> "The =
indication from R1 MAY be inserted by a SIP proxy"  =20
>> R3: "The indication from R1 can be removed by a SIP proxy" -> "The =
indication from R1 MAY be removed by a SIP proxy"
>> R6: "must" -> "MUST"
>>=20
>> - Section 6, 2nd paragraph. The "can" in the first sentence should be =
a "MAY" and the sentence needs to be split into two:
>> OLD:
>>    A proxy server which handles a message can insert such a =
P-Private-
>>    Network-Indication header field into the message based on
>>    authentication of the source of a message, configuration or local
>>    policy, and forward it to other proxies in the same administrative
>>    domain or proxies in trusted domain to be handled as private =
network
>>    traffic.=20
>>=20
>> NEW:=20
>>    A proxy server which handles a message MAY insert such a =
P-Private-
>>    Network-Indication header field into the message based on
>>    authentication of the source of a message, configuration or local
>>    policy.  A proxy server MAY forward the message to other proxies =
in the=20
>>    same administrative domain or proxies in a trusted=20
>>    domain to be handled as private network traffic.=20
>>=20
>>=20
>>=20
>> Section 9.  You should be explicit about the header name in this =
section.  The text in the first paragraph needs some work.  At a minimum =
you need to change the "not supposed to" to something more definitive as =
all security issues arise because someone does something they're not =
supposed to.   I would suggest at least making the following change:
>> OLD:
>>    The private network indication defined in this document is to be =
used
>>    in an environment where elements are trusted and where attackers =
are
>>    not supposed to have access to the protocol messages between those
>>    elements.  Traffic protection between network elements is =
sometimes
>>    achieved by using IPsec and sometimes by physical protection of =
the
>>    network.  In any case, the environment where the private network
>>    indication will be used ensures the integrity and the =
confidentiality
>>    of the contents of this header field.
>> NEW:
>>    The private network indication defined in this document MUST only =
be used
>>    in an environment where elements are trusted and where attackers =
are
>>    do not have access to the protocol messages between those
>>    elements.  Traffic protection between network elements can be
>>    achieved by using IPsec and sometimes by physical protection of =
the
>>    network.  In any case, the environment where the private network
>>    indication will be used ensures the integrity and the =
confidentiality
>>    of the contents of this header field.
>>=20
>>=20
>> Nits:
>> ------
>> - Section 1.1:  "3rd-Generqation" -> 3rd-Generation =20
>> - The terms "break-in" and "break-out" traffic are used several =
places in the document, but this term is never defined.  These terms =
should be defined in Section 3.=20
>> - Figures should have Titles for readability
>>=20
>>=20
>>=20
>> On Wed, Sep 11, 2013 at 9:19 PM, Mayumi Ohsugi =
 wrote:
>> Hi,
>>=20
>> I have submitted the following draft:
>>=20
>> =
http://www.ietf.org/internet-drafts/draft-vanelburg-dispatch-private-netwo=
rk-ind-03.txt
>>=20
>> The draft reflects all the comments discussed in DISPATCH list.
>>=20
>> The major changes are as follows:
>>=20
>> - corrected the abstract
>> - corrected the term "common domain" to "pre-arranged domain"
>> - added 7.1.4 "P-Private-Network-Indication verification"
>> - editorial changes
>>                                                                       =
            Regards,
>> Mayumi
>> _______________________________________________
>> dispatch mailing list
>> dispatch@ietf.org
>> https://www.ietf.org/mailman/listinfo/dispatch
>>=20
>>=20
>=20
>=20


--Apple-Mail=_5257B5F7-0116-4F7D-AEA6-C9182E1FF452
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=iso-8859-1



Why don't we just reword it to =
say 

 "SIP proxy MAY insert the =
indication from R1" 

 Whether it is a =
can or MAY what we are ultimately trying to say is =
that 
proxy MAY insert the indication from R1 right? We =
are not preventing 
it and I am assuming as a spec, we =
want to let the implementer know 
that proxy MAY send =
requests with these =
values. 

 Regards
  =
Shida

On Jan 9, 2014, at 7:22 AM, Mary Barnes <mary.ietf.barnes@gmail.com&=
gt; wrote:

Then, why are those even requirements? =
 

Mary. 


On Thu, Jan 9, =
2014 at 5:05 AM, DRAGE, Keith (Keith) <keith.drage@alcatel-lucent.com> =
wrote:











The text from RFC 2119 states:


 




5. MAY   This word, or the adjective "OPTIONAL", mean that an item =
is
   truly optional.  One vendor may choose to include the item because a
   particular marketplace requires it or because the vendor feels that
   it enhances the product while another vendor may omit the same item.
   An implementation which does not include a particular option MUST be
   prepared to interoperate with another implementation which does
   include the option, though perhaps with reduced functionality. In the
   same vein an implementation which does include a particular option
   MUST be prepared to interoperate with another implementation which
   does not include the option (except, of course, for the feature the
   option provides.)



My belief is that we are&=
nbsp;not defining an option here, and it&nbs=
p;is certainly not a vendor decision. =
Further we are not identifying an interoperability issue =
here.

We are defining a possibility that a valid =
implementation can take. 






If you go to the procedures you will see =
both these items are covered with "If <condition> MUST" type =
sentences. There is no specified =
optionality.







Keith









From: dispatch [mailto:dispatch-bounces@ietf.org]
On Behalf Of Shida Schubert

Sent: 09 January 2014 06:30

To: Mary Barnes


Cc: DISPATCH

Subject: Re: [dispatch] New Version of =
draft-vanelburg-dispatch-private-network-ind














Hi Mary;







 Thanks for reviewing the document again. 






On Jan 6, 2014, at 3:03 PM, Mary Barnes <mary.ietf.barnes@gmail.com> wrote:






Hi all,






I have reviewed the revised version and I just a few final =
comments.







- Section 1.5, first bullet in the bulleted list: either change "an =
emergency calls" to "an emergency call" or "emergency calls"
















 I will fix it with "emergency calls"








- Section 3.6.  "require the Specifying a Spec (T)." -> =
"require specifying a Spec(T)" or "require the specification of a =
Spec(T)"










 


 I will fix it with "require the specification of a =
Spec(T)"








- Section 5, I had suggested the the requirements be consistent in =
usage of 2119 language.  One of the requirements (R6) was changed, =
but R2 and R3 were not.  Was there a specific reason not to make =
those suggested changes?   


















R2:   =
"The indication from R1 =
can be inserted by a SIP proxy" -> "The indication from R1 MAY
 be inserted by a SIP proxy"   


R3: "The indication from R1 can be =
removed by a SIP proxy" -> "The indication from R1 MAY
 be removed by a SIP proxy"













 So I reverted the change after Keith told that the =
requirements above is not stating 


a normative behaviour and that he believes "can" is more =
appropriate. 







 I am okay either way. 







 I will create a version with "MAY". 







 Keith, please provide comments if you have a strong =
opposition to changing it to "MAY".







 Thanks! 


  Shida















Thanks,




Mary. 









On Tue, Oct 29, 2013 at 9:11 AM, Mary Barnes =

<mary.ietf.barnes@gmail.com> wrote:




In reviewing the document in preparation for the PROTO =
write-up, I have a few comments (minor and nits) that should be =
addressed prior to the document being progressed.






Regards,


Mary.







Comments:


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







- General: domains used in this document must use a reserved domain =
such as "example.com" and must not use real domains. Thus, =
all occurrences of
ericsson.com need =
to be changed to
example.com







- Section 1.5.  Bulleted list, first bullet. I would suggest =
you just leave out the mention of LI.  Emergency services should be =
a sufficient example.  







- Section 1.5, last numbered list, item 2.  I had a hard time =
groking this sentence and had to read several times. I would suggest =
rewording something like (if I've properly interpreted the =
intent):


OLD:




       Different nodes spanning over different networks may need to be
       able to act differently on type of traffic, when implicit schemes
       are used, it would require distribution of such enterprise
       specific logic over multiple nodes in multiple operators.  That
       is clearly not a manageable architecture and solution.









NEW: 




       Nodes spanning multiple networks often need to have =
different 


       behavior depending upon the =
type of traffic.  When this is done using implicit


       schemes, enterprise specific logic must be distributed across =
multiple


       nodes in multiple operator's networks.  


       That is clearly not a manageable architecture and =
solution.












- Section 1.5, last sentence.  I don't think that statement is =
sufficient for what this document is doing. I would suggest you change =
that sentence to something like the following:


OLD:




   Given the above background this document will formulate =
requirements
   for SIP to support an explicit private network indication.







NEW: 




   Based on the background provided, this document formulates =
requirements
   for SIP to support an explicit private network indication and defines =



   a P-header, P-Private-Network-Indication, to support those =
requirements. 










- Section 3, next to last paragraph.  I'm not sure what is =
meant by "the filling out a Spec(T)". I don't see "filling" used as a =
concept in RFC 3324.  Perhaps, "specifying a Spec(T)" is more =
consistent with terminology in RFC 3324. 








- Section 5.  In general, the requirements are not specific =
consistently - i.e., some use 2119 language and others not and there is =
not consistent capitalization.  I would suggest the following =
changes.


R2:   "The =
indication from R1 can be inserted by a SIP proxy" -> "The indication from R1 MAY be =
inserted by a SIP proxy"   



R3: "The =
indication from R1 can be removed by a SIP proxy" -> "The indication from R1 MAY be =
removed by a SIP proxy"



R6: "must" -> =
"MUST"







- Section 6, 2nd =
paragraph. The "can" in the first sentence should be a "MAY" and =
the sentence needs =
to be split into two:



OLD:




   A proxy server which handles a message can insert such a P-Private-
   Network-Indication header field into the message based on
   authentication of the source of a message, configuration or local
   policy, and forward it to other proxies in the same administrative
   domain or proxies in trusted domain to be handled as private network
   traffic. 









NEW: 




   A proxy server which handles a message MAY insert such a P-Private-
   Network-Indication header field into the message based on
   authentication of the source of a message, configuration or local
   policy.  A proxy server MAY forward the message to other proxies in =
the 


   same administrative domain or proxies in a trusted 


   domain to be handled as private network traffic. 












Section 9.  You should be =
explicit about the header name in this section.  The text in the =
first paragraph needs some work.  At a minimum you need to change =
the "not supposed to" to something more definitive as all security
 issues arise because someone does something they're not supposed to. =
  I would suggest at least making the following =
change:


OLD:




   The private network indication defined in this document is to be =
used
   in an environment where elements are trusted and where attackers are
   not supposed to have access to the protocol messages between those
   elements.  Traffic protection between network elements is sometimes
   achieved by using IPsec and sometimes by physical protection of the
   network.  In any case, the environment where the private network
   indication will be used ensures the integrity and the confidentiality
   of the contents of this header field.




NEW:






   The private network indication defined in this document MUST only =
be used
   in an environment where elements are trusted and where attackers are
   do not have access to the protocol messages between those
   elements.  Traffic protection between network elements can be
   achieved by using IPsec and sometimes by physical protection of the
   network.  In any case, the environment where the private network
   indication will be used ensures the integrity and the confidentiality
   of the contents of this header field.














Nits:


------


- Section 1.1:  "3rd-Generqation" =
-> 3rd-Generation =
 


- The terms =
"break-in" and "break-out" traffic are used several places in the =
document, but this term is never defined.  These terms should be =
defined in Section 3. 



- Figures should =
have Titles for readability


















On Wed, Sep 11, 2013 at 9:19 PM, Mayumi Ohsugi <mayumi.ohsugi@ntt-at.co.jp> wrote:









Hi,



I have submitted the following draft:



http://www.ietf.org/internet-drafts/draft-vanelbu=
rg-dispatch-private-network-ind-03.txt




The draft reflects all the comments discussed in DISPATCH list.



The major changes are as follows:



- corrected the abstract

- corrected the term "common domain" to "pre-arranged domain"

- added 7.1.4 "P-Private-Network-Indication verification"

- editorial changes

                    =
                    =
                    =
                    =
  Regards,

Mayumi

_______________________________________________

dispatch mailing list

dispatch@ietf.org

https://www.ietf.org/mailman/listinfo/dispatch





































=

--Apple-Mail=_5257B5F7-0116-4F7D-AEA6-C9182E1FF452--

From mary.ietf.barnes@gmail.com  Mon Jan 13 12:38:05 2014
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 EA7E41AE15D for ; Mon, 13 Jan 2014 12:38:04 -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 KWc9BCRiOL91 for ; Mon, 13 Jan 2014 12:38:00 -0800 (PST)
Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 39B841AE00F for ; Mon, 13 Jan 2014 12:38:00 -0800 (PST)
Received: by mail-wi0-f170.google.com with SMTP id hq4so3602598wib.1 for ; Mon, 13 Jan 2014 12:37:48 -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=7xjhICGnYywn/SRZbgs3e52R/F1vNlRRi/V0qX+CF+Q=; b=W/g2eFMWK9yaOT3kFkpTkcJ0p5Ev5TKzO3kO7QYh0pFQy2wtvbUPmYAk806LSZeWg/ PezAcT6yHZk0y4WuJ7kalTnP/X8k6f82w+DpTPzJf/g1d/XMglJQrGJDXcJZPRjtMBEL LuJ+QkAu3ZNY252o2JK0c7KciNCIo4sI7fC0DzxkXQLThUAz7mVAc2V5Jg7Y79lv91Hr uqCPEmfGmlM7d/tDMNwmIroRavKHcVIFl7vafF7ask/WFZx0EnQg1gN5T5HIt2tFzONy oHFrzWPu3VIOh0ep8q0jVOR1RwtDicVN/pFmgIbLf/g7TJsA6FWgk8YB/+cQrd8drmSQ EuGQ==
MIME-Version: 1.0
X-Received: by 10.194.92.68 with SMTP id ck4mr23930347wjb.53.1389645468470; Mon, 13 Jan 2014 12:37:48 -0800 (PST)
Received: by 10.216.172.9 with HTTP; Mon, 13 Jan 2014 12:37:48 -0800 (PST)
In-Reply-To: 
References: <20130912005949.3447.42089.idtracker@ietfa.amsl.com> <523124B0.2000305@ntt-at.co.jp>   <5863E5DF-F01A-44DC-B0E6-74D1763AE178@ntt-at.com> <949EF20990823C4C85C18D59AA11AD8B100BA1@FR712WXCHMBA11.zeu.alcatel-lucent.com>  
Date: Mon, 13 Jan 2014 14:37:48 -0600
Message-ID: 
From: Mary Barnes 
To: Shida Schubert 
Content-Type: multipart/alternative; boundary=047d7bf0d2de83131504efe00c06
Cc: DISPATCH 
Subject: Re: [dispatch] New Version of draft-vanelburg-dispatch-private-network-ind
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: Mon, 13 Jan 2014 20:38:05 -0000

--047d7bf0d2de83131504efe00c06
Content-Type: text/plain; charset=ISO-8859-1

That works for me.


On Mon, Jan 13, 2014 at 2:32 PM, Shida Schubert  wrote:

>
> Why don't we just reword it to say
>
>  "SIP proxy MAY insert the indication from R1"
>
>  Whether it is a can or MAY what we are ultimately trying to say is that
> proxy MAY insert the indication from R1 right? We are not preventing
> it and I am assuming as a spec, we want to let the implementer know
> that proxy MAY send requests with these values.
>
>  Regards
>   Shida
>
> On Jan 9, 2014, at 7:22 AM, Mary Barnes 
> wrote:
>
> Then, why are those even requirements?
>
> Mary.
>
>
> On Thu, Jan 9, 2014 at 5:05 AM, DRAGE, Keith (Keith) <
> keith.drage@alcatel-lucent.com> wrote:
>
>>  The text from RFC 2119 states:
>>
>>
>> 5. MAY   This word, or the adjective "OPTIONAL", mean that an item is
>>    truly optional.  One vendor may choose to include the item because a
>>    particular marketplace requires it or because the vendor feels that
>>    it enhances the product while another vendor may omit the same item.
>>    An implementation which does not include a particular option MUST be
>>    prepared to interoperate with another implementation which does
>>    include the option, though perhaps with reduced functionality. In the
>>    same vein an implementation which does include a particular option
>>    MUST be prepared to interoperate with another implementation which
>>    does not include the option (except, of course, for the feature the
>>    option provides.)
>>
>>
>> My belief is that we are not defining an option here, and it is certainly not a vendor decision.Further we are not identifying an interoperability issue here.
>>
>> We are defining a possibility that a valid implementation can take.
>>
>>  If you go to the procedures you will see both these items are covered with "If  MUST" type sentences. There is no specified optionality.
>>
>>  Keith
>>
>>   ------------------------------
>> *From:* dispatch [mailto:dispatch-bounces@ietf.org] *On Behalf Of *Shida
>> Schubert
>> *Sent:* 09 January 2014 06:30
>> *To:* Mary Barnes
>>
>> *Cc:* DISPATCH
>> *Subject:* Re: [dispatch] New Version of
>> draft-vanelburg-dispatch-private-network-ind
>>
>>
>>  Hi Mary;
>>
>>   Thanks for reviewing the document again.
>>
>>  On Jan 6, 2014, at 3:03 PM, Mary Barnes 
>> wrote:
>>
>>  Hi all,
>>
>>  I have reviewed the revised version and I just a few final comments.
>>
>>  - Section 1.5, first bullet in the bulleted list: either change "an
>> emergency calls" to "an emergency call" or "emergency calls"
>>
>>
>>   I will fix it with "emergency calls"
>>
>>  - Section 3.6.  "require the Specifying a Spec (T)." -> "require
>> specifying a Spec(T)" or "require the specification of a Spec(T)"
>>
>>
>>  I will fix it with "require the specification of a Spec(T)"
>>
>>  - Section 5, I had suggested the the requirements be consistent in
>> usage of 2119 language.  One of the requirements (R6) was changed, but R2
>> and R3 were not.  Was there a specific reason not to make those suggested
>> changes?
>>
>>
>>  R2:   "The indication from R1 can be inserted by a SIP proxy" -> "The
>> indication from R1 MAY be inserted by a SIP proxy"
>> R3: "The indication from R1 can be removed by a SIP proxy" -> "The
>> indication from R1 MAY be removed by a SIP proxy"
>>
>>
>>   So I reverted the change after Keith told that the requirements above
>> is not stating
>> a normative behaviour and that he believes "can" is more appropriate.
>>
>>   I am okay either way.
>>
>>   I will create a version with "MAY".
>>
>>   Keith, please provide comments if you have a strong opposition to
>> changing it to "MAY".
>>
>>   Thanks!
>>   Shida
>>
>>
>>  Thanks,
>>  Mary.
>>
>>
>> On Tue, Oct 29, 2013 at 9:11 AM, Mary Barnes wrote:
>>
>>> In reviewing the document in preparation for the PROTO write-up, I have
>>> a few comments (minor and nits) that should be addressed prior to the
>>> document being progressed.
>>>
>>>  Regards,
>>> Mary.
>>>
>>>  Comments:
>>> ---------------
>>>
>>>  - General: domains used in this document must use a reserved domain
>>> such as "example.com" and must not use real domains. Thus, all
>>> occurrences of ericsson.com need to be changed to example.com
>>>
>>>  - Section 1.5.  Bulleted list, first bullet. I would suggest you just
>>> leave out the mention of LI.  Emergency services should be a sufficient
>>> example.
>>>
>>>  - Section 1.5, last numbered list, item 2.  I had a hard time groking
>>> this sentence and had to read several times. I would suggest rewording
>>> something like (if I've properly interpreted the intent):
>>> OLD:
>>>
>>>        Different nodes spanning over different networks may need to be
>>>        able to act differently on type of traffic, when implicit schemes
>>>        are used, it would require distribution of such enterprise
>>>        specific logic over multiple nodes in multiple operators.  That
>>>        is clearly not a manageable architecture and solution.
>>>
>>>
>>>  NEW:
>>>
>>>        Nodes spanning multiple networks often need to have different
>>>
>>>        behavior depending upon the type of traffic.  When this is done using implicit
>>>
>>>        schemes, enterprise specific logic must be distributed across multiple
>>>
>>>        nodes in multiple operator's networks.
>>>
>>>        That is clearly not a manageable architecture and solution.
>>>
>>>
>>>
>>>  - Section 1.5, last sentence.  I don't think that statement is
>>> sufficient for what this document is doing. I would suggest you change that
>>> sentence to something like the following:
>>> OLD:
>>>
>>>    Given the above background this document will formulate requirements
>>>    for SIP to support an explicit private network indication.
>>>
>>>
>>>  NEW:
>>>
>>>    Based on the background provided, this document formulates requirements
>>>    for SIP to support an explicit private network indication and defines
>>>
>>>    a P-header, P-Private-Network-Indication, to support those requirements.
>>>
>>>
>>>
>>>  - Section 3, next to last paragraph.  I'm not sure what is meant by
>>> "the filling out a Spec(T)". I don't see "filling" used as a concept in RFC
>>> 3324.  Perhaps, "specifying a Spec(T)" is more consistent with terminology
>>> in RFC 3324.
>>>
>>>  - Section 5.  In general, the requirements are not specific
>>> consistently - i.e., some use 2119 language and others not and there is not
>>> consistent capitalization.  I would suggest the following changes.
>>> R2:   "The indication from R1 can be inserted by a SIP proxy" -> "The
>>> indication from R1 MAY be inserted by a SIP proxy"
>>> R3: "The indication from R1 can be removed by a SIP proxy" -> "The
>>> indication from R1 MAY be removed by a SIP proxy"
>>> R6: "must" -> "MUST"
>>>
>>>  - Section 6, 2nd paragraph. The "can" in the first sentence should be
>>> a "MAY" and the sentence needs to be split into two:
>>> OLD:
>>>
>>>    A proxy server which handles a message can insert such a P-Private-
>>>    Network-Indication header field into the message based on
>>>    authentication of the source of a message, configuration or local
>>>    policy, and forward it to other proxies in the same administrative
>>>    domain or proxies in trusted domain to be handled as private network
>>>    traffic.
>>>
>>>
>>>  NEW:
>>>
>>>    A proxy server which handles a message MAY insert such a P-Private-
>>>    Network-Indication header field into the message based on
>>>    authentication of the source of a message, configuration or local
>>>    policy.  A proxy server MAY forward the message to other proxies in the
>>>
>>>    same administrative domain or proxies in a trusted
>>>
>>>    domain to be handled as private network traffic.
>>>
>>>
>>>
>>>  Section 9.  You should be explicit about the header name in this
>>> section.  The text in the first paragraph needs some work.  At a minimum
>>> you need to change the "not supposed to" to something more definitive as
>>> all security issues arise because someone does something they're not
>>> supposed to.   I would suggest at least making the following change:
>>> OLD:
>>>
>>>    The private network indication defined in this document is to be used
>>>    in an environment where elements are trusted and where attackers are
>>>    not supposed to have access to the protocol messages between those
>>>    elements.  Traffic protection between network elements is sometimes
>>>    achieved by using IPsec and sometimes by physical protection of the
>>>    network.  In any case, the environment where the private network
>>>    indication will be used ensures the integrity and the confidentiality
>>>    of the contents of this header field.
>>>
>>>  NEW:
>>>
>>>    The private network indication defined in this document MUST only be used
>>>    in an environment where elements are trusted and where attackers are
>>>    do not have access to the protocol messages between those
>>>    elements.  Traffic protection between network elements can be
>>>    achieved by using IPsec and sometimes by physical protection of the
>>>    network.  In any case, the environment where the private network
>>>    indication will be used ensures the integrity and the confidentiality
>>>    of the contents of this header field.
>>>
>>>
>>>
>>>  Nits:
>>> ------
>>> - Section 1.1:  "3rd-Generqation" -> 3rd-Generation
>>> - The terms "break-in" and "break-out" traffic are used several places
>>> in the document, but this term is never defined.  These terms should be
>>> defined in Section 3.
>>> - Figures should have Titles for readability
>>>
>>>
>>>
>>>  On Wed, Sep 11, 2013 at 9:19 PM, Mayumi Ohsugi <
>>> mayumi.ohsugi@ntt-at.co.jp> wrote:
>>>
>>>> Hi,
>>>>
>>>> I have submitted the following draft:
>>>>
>>>> http://www.ietf.org/internet-drafts/draft-vanelburg-
>>>> dispatch-private-network-ind-03.txt
>>>>
>>>> The draft reflects all the comments discussed in DISPATCH list.
>>>>
>>>> The major changes are as follows:
>>>>
>>>> - corrected the abstract
>>>> - corrected the term "common domain" to "pre-arranged domain"
>>>> - added 7.1.4 "P-Private-Network-Indication verification"
>>>> - editorial changes
>>>>
>>>>           Regards,
>>>> Mayumi
>>>> _______________________________________________
>>>> dispatch mailing list
>>>> dispatch@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/dispatch
>>>>
>>>
>>>
>>
>>
>
>

--047d7bf0d2de83131504efe00c06
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


That works for me.=A0

=

On Mon, Jan 13, 2014 at 2:32 PM, Shida Schub=
ert <shida@ntt-at.com> wrote:


Why don't we just reword it to say=A0

<=
div>
=A0"SIP proxy MAY insert the indication from R1"=A0
=A0Whether it is a can or MAY what we are ultimately trying to =
say is that=A0
proxy MAY insert the indication from R1 right? We =
are not preventing=A0


it and I am assuming as a spec, we want to let the implementer know=A0=

that proxy MAY send requests with these values.=A0
=A0Regards
=

=A0 Shida



On Jan 9, 2014, at 7:22 =
AM, Mary Barnes <mary.ietf.barnes@gmail.com> wrote:



Then, why are those even requirements? =A0

<=
div>Mary.=A0


On Thu, Jan 9, 2014 at 5:05 AM, DRAGE, Keith (Keith) <keith.drage@alcatel-lucent.com> wrote:












The text from RFC 2119 states:


=A0




5. MAY   This word, or the adjective "OPTIONAL", mean that a=
n item is
   truly optional.  One vendor may choose to include the item because a
   particular marketplace requires it or because the vendor feels that
   it enhances the product while another vendor may omit the same item.
   An implementation which does not include a particular option MUST be
   prepared to interoperate with another implementation which does
   include the option, though perhaps with reduced functionality. In the
   same vein an implementation which does include a particular option
   MUST be prepared to interoperate with another implementation which
   does not include the option (except, of course, for the feature the
   option provides.)



My=A0b=
elief=A0is=A0that=A0we=A0are=A0not=A0defining=A0an=A0option=A0here,=A0and=
=A0it=A0is=A0certainly=A0not=A0a=A0vendor=A0decision. Further we are =
not identifying an interoperability issue here.

We are defining a possibility that a valid implementation can take. =






If you go to the procedures you will see both these items are covered with =
"If <condition> MUST" type sentences. There is no specified=
 optionality.







Keith









From: dispatch [mailto:dispatch-bounces@ietf.org]
On Behalf Of Shida Schubert

Sent: 09 January 2014 06:30

To: Mary Barnes


Cc: DISPATCH

Subject: Re: [dispatch] New Version of draft-vanelburg-dispatch-priv=
ate-network-ind














Hi Mary;







=A0Thanks for reviewing the document again.=A0






On Jan 6, 2014, at 3:03 PM, Mary Barnes <mary.ietf.barnes@gmail.com> wr=
ote:






Hi all,






I have reviewed the revised version and I just a few final comments.






- Section 1.5, first bullet in the bulleted list: either change "=
an emergency calls" to "an emergency call" or "emergenc=
y calls"
















=A0I will fix it with "emergency calls"








- Section 3.6. =A0"require the Specifying a Spec (T)." ->=
 "require specifying a Spec(T)" or "require the specificatio=
n of a Spec(T)"










=A0


=A0I will fix it with "require the specification of a Spec(T)&quo=
t;








- Section 5, I had suggested the the requirements be consistent in usa=
ge of 2119 language. =A0One of the requirements (R6) was changed, but R2 an=
d R3 were not. =A0Was there a specific reason not to make those suggested c=
hanges? =A0=A0



















R2: =A0 "The indication from R1 can b=
e inserted by a SIP proxy" -> "The indication from R1 MAY
 be inserted by a SIP proxy" =A0=A0


R3: "The indication from R1 can be re=
moved by a SIP proxy" -> "The indication from R1 MAY
 be removed by a SIP proxy"













=A0So I reverted the change after Keith told that the requirements abo=
ve is not stating=A0


a normative behaviour and that he believes "can" is more app=
ropriate.=A0







=A0I am okay either way.=A0







=A0I will create a version with "MAY".=A0







=A0Keith, please provide comments if you have a strong opposition to c=
hanging it to "MAY".







=A0Thanks!=A0


=A0 Shida















Thanks,




Mary.=A0









On Tue, Oct 29, 2013 at 9:11 AM, Mary Barnes 
<mary.ie=
tf.barnes@gmail.com> wrote:




In reviewing the document in preparation for the PROTO wri=
te-up, I have a few comments (minor and nits) that should be addressed prio=
r to the document being progressed.






Regards,


Mary.







Comments:


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







- General: domains used in this document must use a reserved domain su=
ch as "example.com" and must not use real domains. Thus, all occurrences of
ericsson.com need to=
 be changed to
example.com







- Section 1.5. =A0Bulleted list, first bullet. I would suggest you jus=
t leave out the mention of LI. =A0Emergency services should be a sufficient=
 example. =A0







- Section 1.5, last numbered list, item 2. =A0I had a hard time grokin=
g this sentence and had to read several times. I would suggest rewording so=
mething like (if I've properly interpreted the intent):


OLD:




       Different nodes spanning over different networks may need to b=
e
       able to act differently on type of traffic, when implicit schemes
       are used, it would require distribution of such enterprise
       specific logic over multiple nodes in multiple operators.  That
       is clearly not a manageable architecture and solution.









NEW:=A0




      =A0Nodes spanning multiple networks often need to have differen=
t=A0


       behavior depending upon the =
type of traffic.  When this is done using implicit


       schemes, enterprise specific logic must be distributed across =
multiple


       nodes in multiple operator's networks.  


       That is clearly not a manageable architecture and solution.











- Section 1.5, last sentence. =A0I don't think that statement is s=
ufficient for what this document is doing. I would suggest you change that =
sentence to something like the following:


OLD:




   Given the above background this document will formulate requiremen=
ts
   for SIP to support an explicit private network indication.







NEW:=A0




   Based on the background provided, this document formulates require=
ments
   for SIP to support an explicit private network indication and defines 

   a P-header, P-Private-Network-Indication, to support those require=
ments. 










- Section 3, next to last paragraph. =A0I'm not sure what is meant=
 by "the filling out a Spec(T)". I don't see "filling&qu=
ot; used as a concept in RFC 3324. =A0Perhaps, "specifying a Spec(T)&q=
uot; is more consistent with terminology in RFC 3324.=A0









- Section 5. =A0In general, the requirements are not specific consiste=
ntly - i.e., some use 2119 language and others not and there is not consist=
ent capitalization. =A0I would suggest the following changes.


R2: =A0 "The ind=
ication from R1 can be inserted by a SIP proxy" -> "The indication from R1 MAY be=
 inserted by a SIP proxy" =A0=A0




R3: "The indicat=
ion from R1 can be removed by a SIP proxy" -> "The indication from R1 MAY be remo=
ved by a SIP proxy"




R6: "must"=
; -> "MUST"







- Section 6, 2nd pa=
ragraph. The "can" in the first sentence should be a "MAY&qu=
ot; and the=A0sentence needs=
 to be split into two:




OLD:




   A proxy server which handles a message can insert such a P-Private=
-
   Network-Indication header field into the message based on
   authentication of the source of a message, configuration or local
   policy, and forward it to other proxies in the same administrative
   domain or proxies in trusted domain to be handled as private network
   traffic. 









NEW:=A0




   A proxy server which handles a message MAY insert such a P-Private=
-
   Network-Indication header field into the message based on
   authentication of the source of a message, configuration or local
   policy.  A proxy server MAY forward the message to other proxies in the=
=A0


   same administrative domain or proxies in a trusted=A0


   domain to be handled as private network traffic. 












Section 9. =A0You should be explicit =
about the header name in this section. =A0The text in the first paragraph n=
eeds some work. =A0At a minimum you need to change the "not supposed t=
o" to something more definitive as all security
 issues arise because someone does something they're not supposed to. =
=A0 I would suggest at least making the following change:


OLD:




   The private network indication defined in this document is to be u=
sed
   in an environment where elements are trusted and where attackers are
   not supposed to have access to the protocol messages between those
   elements.  Traffic protection between network elements is sometimes
   achieved by using IPsec and sometimes by physical protection of the
   network.  In any case, the environment where the private network
   indication will be used ensures the integrity and the confidentiality
   of the contents of this header field.




NEW:






   The private network indication defined in this document MUST only =
be used
   in an environment where elements are trusted and where attackers are
   do not have access to the protocol messages between those
   elements.  Traffic protection between network elements can be
   achieved by using IPsec and sometimes by physical protection of the
   network.  In any case, the environment where the private network
   indication will be used ensures the integrity and the confidentiality
   of the contents of this header field.














Nits:


------


- Section 1.1: =A0"3rd-Generqation" ->=A03rd-Generation =A0


- The terms "bre=
ak-in" and "break-out" traffic are used several places in th=
e document, but this term is never defined. =A0These terms should be define=
d in Section 3.=A0




- Figures should have=
 Titles for readability


















On Wed, Sep 11, 2013 at 9:19 PM, Mayumi Ohsugi <<=
a href=3D"mailto:mayumi.ohsugi@ntt-at.co.jp" target=3D"_blank">mayumi.ohsug=
i@ntt-at.co.jp> wrote:









Hi,



I have submitted the following draft:



http://www.ietf.org/internet-=
drafts/draft-vanelburg-dispatch-private-network-ind-03.tx=
t





The draft reflects all the comments discussed in DISPATCH list.



The major changes are as follows:



- corrected the abstract

- corrected the term "common domain" to "pre-arranged domain=
"

- added 7.1.4 "P-Private-Network-Indication verification"

- editorial changes

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 Regards,

Mayumi

_______________________________________________

dispatch mailing list

dispatch@ietf.org

https://www.ietf.org/mailman/listinfo/dispatch





































 <=
/p>=

--_000_058CE00BD4D6B94FAD033A2439EA1E4B01DF8EE7BA91HE113667eme_--

From mary.ietf.barnes@gmail.com  Thu Jan 16 07:27:50 2014
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 3113F1AE36D for ; Thu, 16 Jan 2014 07:27:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.698
X-Spam-Level: 
X-Spam-Status: No, score=-1.698 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, 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 9NScPypnz7Kx for ; Thu, 16 Jan 2014 07:27:43 -0800 (PST)
Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) by ietfa.amsl.com (Postfix) with ESMTP id 5C08E1AE38B for ; Thu, 16 Jan 2014 07:27:42 -0800 (PST)
Received: by mail-wg0-f51.google.com with SMTP id z12so3340841wgg.30 for ; Thu, 16 Jan 2014 07:27:29 -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=H0gRqXabx4BT04NFLTRCoieo9lGqzSDGhYbVP5haljQ=; b=z3oT6RTLHFX2vZHpZn4PNFUIvpjC5QeSn8jDgE/tl5OUaXiUNO4ZK2P2KzoqoXAJi5 PHujmlZBTXpO2u/KyJ0IFctuB4Dd80HAlh+10wx0DEW2zhnxbSMnf5sstd3b7fzSX7IQ CV8sjg7ggq2mvMJ43vME4x2rXamLwADWxElbQZrXm1FGLdIY9MtDtQM1aqfVQm+Md0ty oYMZ1+NZIuCfAaP1EDAC2XXuKOwdVcficALrAv0bXQjYRuaK/0wt2h5ngsXRqm30CXzA VMTGba5YACFVFh6pmDeE1tlzYKGss/cPgmo9ntGZ6sgJoH/l5fOoX2R/AhZq3dGwQ/2g EvsQ==
MIME-Version: 1.0
X-Received: by 10.195.13.164 with SMTP id ez4mr8983195wjd.11.1389886049554; Thu, 16 Jan 2014 07:27:29 -0800 (PST)
Received: by 10.216.172.9 with HTTP; Thu, 16 Jan 2014 07:27:28 -0800 (PST)
In-Reply-To: <058CE00BD4D6B94FAD033A2439EA1E4B01DF8EE7BA91@HE113667.emea1.cds.t-internal.com>
References:    <058CE00BD4D6B94FAD033A2439EA1E4B01DF8EE7BA91@HE113667.emea1.cds.t-internal.com>
Date: Thu, 16 Jan 2014 09:27:28 -0600
Message-ID: 
From: Mary Barnes 
To: "R.Jesske@telekom.de" 
Content-Type: multipart/alternative; boundary=047d7bb04f6843180104f01810b6
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: Thu, 16 Jan 2014 15:27:50 -0000

--047d7bb04f6843180104f01810b6
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Roland,

Thank you for making these changes and fixing additional nits.  There are
still a couple of things, but I'll go ahead and note those in the PROTO
write-up and I believe these can be changed with any other LC comments.
 Note, that some of these comments relate to things that idnits has
identified:
http://tools.ietf.org/idnits?url=3Dhttp://tools.ietf.org/id/draft-drage-sip=
ping-rfc3455bis-13.txt

It really does save you grief to run a doc through idnits before you submit
- the nits checked
by the submission tool are the bare minimum and the submission tool does
not block submission for a number of other nits.   Please keep this in mind
when you make changes based on IETF LC comments.

Thanks,
Mary.

1) Abstract:   This document is an update to RFC3455. ->  This
document obsoletes RFC 3455.

2) There are still quite a few domain names in the examples in this
document that are not using the domain names that are specified to be
used in examples in RFCs per RFC 2606 - e.g. home1.net -> example.net,
visited.net, etc.  It think the tool did not catch all of these as
some are embedded in SIP URIs, etc.

3) As idnits points out, there are still some IP addresses that don't
follow the rules in terms of those to be used in examples in
documentation per RFC 5735.




On Wed, Jan 15, 2014 at 1:54 AM,  wrote:

> Hi Mary,
>
> Version -13 is uploaded. (
> http://www.ietf.org/internet-drafts/draft-drage-sipping-rfc3455bis-13.txt
> )
>
> I hope I have covered everything now.
>
> -RFC references not used deleted.
>
> -FQDN corrected
>
> -statement that RFC3455 is obsolete included in Head and Abstract
>
>
>
> Best Regards
>
>
>
> Roland
>
>
>
> *Von:* Mary Barnes [mailto:mary.ietf.barnes@gmail.com]
> *Gesendet:* Freitag, 10. Januar 2014 20:48
> *An:* Andrew Allen
> *Cc:* Jesske, Roland; dispatch@ietf.org; dean.willis@softarmor.com
> *Betreff:* Re: [dispatch] PROTO Review:
> draft-drage-sipping-rfc3455bis-09.txt
>
>
>
> Thanks Andrew.  So, that needs to be clearly stated in the abstract as
> well.  In addition, the Overview section states:
> "This document is an update to RFC3455".  So that also needs to be fixed.
>   Given the number of changes at this point, I would now prefer Roland ma=
ke
> those changes before we ask Gonzalo to progress it to IETF LC.
>
>
>
> Mary.
>
>
>
> On Fri, Jan 10, 2014 at 1:45 PM, Andrew Allen 
> wrote:
>
>
> I think it obsoletes RFC 3455. It is a complete replacement for the
> original.
>
> Andrew
>
>
> *From*: Mary Barnes [mailto:mary.ietf.barnes@gmail.com]
>
> *Sent*: Friday, January 10, 2014 02:37 PM Eastern Standard Time
> *To*: R.Jesske@telekom.de 
> *Cc*: DISPATCH ; Dean Willis 
>
> *Subject*: Re: [dispatch] PROTO Review:
> draft-drage-sipping-rfc3455bis-09.txt
>
>
> There is yet one more change needed.  This document is an Updates to
> 3455bis (AFAIK, unless Obseletes works better for 3GPP usage).  That
> categorization needs to be included in the document header (3rd line).
>
>
>
> Thanks,
>
> Mary.
>
>
>
> On Fri, Jan 10, 2014 at 1:34 PM, Mary Barnes 
> wrote:
>
> IN addition to removing the unused references in the next update, there
> are still 4 domain names that are not using an appropriate documentation
> domain (e.g., home.net).  Please add that change to the list for the next
> revision.  I'm going to ahead and forward the PROTO write-up to Gonzalo,
> noting the changes that are needed and suggesting those changes can be ma=
de
> along with other IETF LC changes.
>
>
>
> Thanks,
>
> Mary
>
>
>
> On Wed, Jan 8, 2014 at 2:46 AM,  wrote:
>
> Thank you Marry,
>
> for doing all this review.
>
> So I have now put out the errors.
>
> There are still some unused references which are in our informal referenc=
e
> section. But useful for the reader to know they exist.
>
> There are also some warnings with regard to IP addresses and wrong FQDNs
> which I think is some interpretation of strings in the text which are not
> meant to be a IP address or FQDN at all.
>
>
>
> Detail see below.
>
>
>
> So now hopefully everything is ready for the next step.
>
>
>
> Best Regards
>
>
>
> Roland
>
>
>
> tmp/draft-drage-sipping-rfc3455bis-12.txt:
>
>
>
>   Checking boilerplate required by RFC 5378 and the IETF Trust (see
>
>   http://trustee.ietf.org/license-info):
>
>
> -------------------------------------------------------------------------=
---
>
>
>
>      No issues found here.
>
>
>
>   Checking nits according to
> http://www.ietf.org/id-info/1id-guidelines.txt:
>
>
> -------------------------------------------------------------------------=
---
>
>
>
>      No issues found here.
>
>
>
>   Checking nits according to http://www.ietf.org/id-info/checklist :
>
>
> -------------------------------------------------------------------------=
---
>
>
>
>  =3D=3D There are 4 instances of lines with non-RFC2606-compliant FQDNs i=
n the
>
>      document.
>
>
>
>   =3D=3D There are 4 instances of lines with non-RFC5735-compliant IPv4
> addresses
>
>      in the document.  If these are example addresses, they should be
> changed.
>
>
>
>
>
>   Miscellaneous warnings:
>
>
> -------------------------------------------------------------------------=
---
>
>
>
>      No issues found here.
>
>
>
>   Checking references for intended status: Informational
>
>
> -------------------------------------------------------------------------=
---
>
>
>
>   =3D=3D Missing Reference: 'RFC XXXX' is mentioned on line 1662, but not
> defined
>
>
>
>   -- Looks like a reference, but probably isn't: '3' on line 1943
>
>
>
>   =3D=3D Unused Reference: 'RFC3262' is defined on line 2068, but no expl=
icit
>
>      reference was found in the text
>
>
>
>   =3D=3D Unused Reference: 'RFC3311' is defined on line 2072, but no expl=
icit
>
>      reference was found in the text
>
>
>
>   =3D=3D Unused Reference: 'RFC3428' is defined on line 2078, but no expl=
icit
>
>      reference was found in the text
>
>
>
>   =3D=3D Unused Reference: 'RFC3903' is defined on line 2090, but no expl=
icit
>
>      reference was found in the text
>
>
>
>   =3D=3D Unused Reference: 'RFC6086' is defined on line 2101, but no expl=
icit
>
>      reference was found in the text
>
>
>
>
>
>      Summary: 0 errors (**), 0 flaws (~~), 8 warnings (=3D=3D), 1 comment=
 (--).
>
>
>
>      Run idnits with the --verbose option for more detailed information
> about
>
>      the items above.
>
>
> -------------------------------------------------------------------------=
-------
>
>
>
>
>
>
>
> *Von:* Mary Barnes [mailto:mary.ietf.barnes@gmail.com]
> *Gesendet:* Dienstag, 7. Januar 2014 18:55
>
>
> *An:* Jesske, Roland
> *Cc:* DISPATCH; Gonzalo Camarillo; Atle Monrad; Dean Willis
> *Betreff:* Re: PROTO Review: draft-drage-sipping-rfc3455bis-09.txt
>
>
>
> Thanks Roland.  I have reviewed that version and all the changes I
> suggested have been made.  However, in doing the PROTO write-up I realize=
d
> that I wasn't certain anyone had reviewed the ABNF. So, I ran the ABNF
> through Bill Fenner's tool:
>
> http://tools.ietf.org/tools/bap/abnf.cgi
>
>
>
> And, there are a couple things that need to be fixed:
>
> 1)  DOT needs to change to "." (we had this same bug in RFC 4244):
>
> transit-ioi-indexed-value =3D transit-ioi-name DOT transit-ioi-index
>
>
>
> 2)  There's an extra space here (between * and parenthesis):
>
> transit-ioi-name          =3D ALPHA * (ALPHA / DIGIT)
>
> NEw: transit-ioi-name          =3D ALPHA *(ALPHA / DIGIT)
>
>
>
> There are also a number of long lines in the ABNF that should be fixed.
>
>
>
> In addition, IDNITS identifies other errors and warnings per the
> following.  Those should also be addressed including considering whether
> obsolete references need changing:
>
>
>
> idnits 2.13.01
>
>
>
> tmp/draft-drage-sipping-rfc3455bis-11.txt:
>
>
>
>   Checking boilerplate required by RFC 5378 and the IETF Trust (see
>
>   http://trustee.ietf.org/license-info):
>
>   -----------------------------------------------------------------------=
-----
>
>
>
>      No issues found here.
>
>
>
>   Checking nits according to http://www.ietf.org/id-info/1id-guidelines.t=
xt:
>
>   -----------------------------------------------------------------------=
-----
>
>
>
>      No issues found here.
>
>
>
>   Checking nits according to http://www.ietf.org/id-info/checklist :
>
>   -----------------------------------------------------------------------=
-----
>
>
>
>   ** There are 9 instances of too long lines in the document, the longest=
 one
>
>      being 20 characters in excess of 72.
>
>
>
>   =3D=3D There are 4 instances of lines with non-RFC2606-compliant FQDNs =
in the
>
>      document.
>
>
>
>   =3D=3D There are 4 instances of lines with non-RFC5735-compliant IPv4 a=
ddresses
>
>      in the document.  If these are example addresses, they should be cha=
nged.
>
>
>
>
>
>   Miscellaneous warnings:
>
>   -----------------------------------------------------------------------=
-----
>
>
>
>   =3D=3D The document seems to contain a disclaimer for pre-RFC5378 work,=
 but was
>
>      first submitted on or after 10 November 2008.  The disclaimer is usu=
ally
>
>      necessary only for documents that revise or obsolete older RFCs, and=
 that
>
>      take significant amounts of text from those RFCs.  If you can contac=
t all
>
>      authors of the source material and they are willing to grant the BCP=
78
>
>      rights to the IETF Trust, you can and should remove the disclaimer.
>
>      Otherwise, the disclaimer is needed and you can ignore this comment.
>
>      (See the Legal Provisions document at
>
>      http://trustee.ietf.org/license-info for more information.)
>
>
>
>
>
>   Checking references for intended status: Informational
>
>   -----------------------------------------------------------------------=
-----
>
>
>
>   =3D=3D Missing Reference: 'RFC XXXX' is mentioned on line 1667, but not=
 defined
>
>
>
>   -- Looks like a reference, but probably isn't: '3' on line 1948
>
>
>
>   =3D=3D Unused Reference: 'RFC2976' is defined on line 2065, but no expl=
icit
>
>      reference was found in the text
>
>
>
>   =3D=3D Unused Reference: 'RFC3262' is defined on line 2068, but no expl=
icit
>
>      reference was found in the text
>
>
>
>   =3D=3D Unused Reference: 'RFC3311' is defined on line 2075, but no expl=
icit
>
>      reference was found in the text
>
>
>
>   =3D=3D Unused Reference: 'RFC3428' is defined on line 2081, but no expl=
icit
>
>      reference was found in the text
>
>
>
>   =3D=3D Unused Reference: 'RFC3903' is defined on line 2093, but no expl=
icit
>
>      reference was found in the text
>
>
>
>   ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234)
>
>
>
>   -- Obsolete informational reference (is this intentional?): RFC 2976
>
>      (Obsoleted by RFC 6086)
>
>
>
>   -- Obsolete informational reference (is this intentional?): RFC 3265
>
>      (Obsoleted by RFC 6665)
>
>
>
>
>
>      Summary: 2 errors (**), 0 flaws (~~), 9 warnings (=3D=3D), 3 comment=
s (--).
>
>
>
>      Run idnits with the --verbose option for more detailed information a=
bout
>
>      the items above.
>
> While I apologize for not catching these issues earlier, it really is the
> responsibility of authors to check idnits (beyond what the submission too=
l
> requires) for their documents.  I routinely run idnits before I submit a
> document as it can also save time when fixing the  nits that the submissi=
on
> tool catches:   https://tools.ietf.org/tools/idnits/
>
>
>
> Regards,
>
> Mary.
>
>
>
>
>
>
>
> On Tue, Jan 7, 2014 at 12:35 AM,  wrote:
>
> Hi Mary,
>
> Now a new revision is available.
>
>
>
> Thank you and Best Regards
>
>
>
> Roland
>
>
>
> *Von:* Mary Barnes [mailto:mary.ietf.barnes@gmail.com]
> *Gesendet:* Montag, 6. Januar 2014 20:00
>
>
> *An:* Jesske, Roland
> *Cc:* DISPATCH; Gonzalo Camarillo; Atle Monrad; Dean Willis
> *Betreff:* Re: PROTO Review: draft-drage-sipping-rfc3455bis-09.txt
>
>
>
> Hi Roland,
>
>
>
> One final editorial nit below.  If you can spin a revision, then I'll sen=
d
> the PROTO write-up to the AD.
>
>
>
> Thanks,
>
> Mary.
>
>
>
> On Thu, Jan 2, 2014 at 3:29 AM,  wrote:
>
> Hi Mary,
>
> I wish you a happy new year 2014. And the best for the next year.
>
>
>
> I was looking again on my changes I made due to your proposal in December=
.
>
> I realized that if I change the SHOULD to MUST we have now a backward
> compatibility problem.
>
> We are using the P-Associated-URI also over the IMS user interface which
> is not encrypted.
>
> So I propose to add some more words.
>
> =85
>
> Section 6.1
>
> =85
>
>          An eavesdropper could possibly collect the list of identities
> a user is registered.
>
>        This can 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.  
>
>
>
>        Since the P-Associated-URI header field value allows to
> implicitly register
>
>       a bundle of URIs with one REGISTER Message the impact of security
> using the P-Associated-URI header field is not higher than
>
>       using single REGISTER messages when registering all identities
> explicit.
>
> [MB] I just have some editorial suggestions for the above:
>
> NEW:
>
>  While the P-Associated-URI header field value allows the implicit
> registration of
>
>       a bundle of URIs with one REGISTER Message the impact of security
> using the P-Associated-URI header field is no higher than
>
>       using separate REGISTER messages for each of the URIs. 
>
> [/MB]
>
>
>
>
>
>
>
>
>
> For the P-Called-Party-Id the change should be also done like as follows:
>
>
>
>         An eavesdropper could possibly collect the list of identities
> a user is registered.
>
>        This can have privacy implications.  To mitigate this problem, thi=
s
> extension SHOULD
>
>        only be used in a secured environment, where encryption of SIP
> messages is
>
>        provided either end-to-end or hop-by-hop.  
>
>
>
>         Normally within a 3GPP environment the P-Called-Party-ID is
> not sent towards end users but may be exchanged between carriers where
> other security mechanisms than SIP encryption are used.  
>
>
>
> Sorry coming so late.
>
> If this is OK for you I will include it to a new version.
>
>
>
> Thank you and Best Regards
>
>
>
> Roland
>
>
>
> *Von:* Mary Barnes [mailto:mary.ietf.barnes@gmail.com]
> *Gesendet:* Freitag, 27. Dezember 2013 19:45
>
>
> *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 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 so=
me
> 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 "potent=
ially 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 th=
e 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" t=
hat makes this header not of particular concern with regards to security. D=
oes it reveal additional, unique information about an individual that isn't=
 available in other headers.  Also, the 2nd paragraph needs some work - may=
be 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 r=
egistered.  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 rev=
ision.  And, I believe you still need to identify privacy/security implicat=
ions by addressing whether or not this header reveals any unique informatio=
n 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
>
>   -
>
>
>
>
>
>
>
>
>
>
>
>
>
> ---------------------------------------------------------------------
> This transmission (including any attachments) may contain confidential
> information, privileged material (including material protected by the
> solicitor-client or other applicable privileges), or constitute non-publi=
c
> information. Any use of this information by anyone other than the intende=
d
> recipient is prohibited. If you have received this transmission in error,
> please immediately reply to the sender and delete this information from
> your system. Use, dissemination, distribution, or reproduction of this
> transmission by unintended recipients is not authorized and may be unlawf=
ul.
>
>
>

--047d7bb04f6843180104f01810b6
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable


It really does save you grief to run a doc through idnits be=
fore you submit - the nits checked=A0
by the submission tool are =
the bare minimum and the submission tool does not block submission for a nu=
mber of other nits. =A0 Please keep this in mind when you make changes base=
d on IETF LC comments.



Thanks,
Mary.=A0
1) Abstract: =A0=A0This document is an update to RFC3455. ->  <=
/span>This document obsoletes RFC 3455. =
=A0


<=
span style=3D"font-family:arial">2) There are still quite a few domain name=
s in the examples in this document that are not using the domain names that=
 are specified to be used in examples in RFCs per RFC 2606 - e.g. home1.net -> ex=
ample.net, visited.net, etc.  It thi=
nk the tool did not catch all of these as some are embedded in SIP URIs, et=
c. =A0


<=
span style=3D"font-family:arial">3) As idnits points out, there are still s=
ome IP addresses that don't follow the rules in terms of those to be us=
ed in examples in documentation per RFC 5735.  







O=
n Wed, Jan 15, 2014 at 1:54 AM,  <R.Jesske@telekom.de> wro=
te:




Hi Mary,

Version -13 is uploaded. (http://www.ietf.org/internet-drafts/draft-=
drage-sipping-rfc3455bis-13.txt )<=
u>



I hope I have covered everyth=
ing now.
-RFC references not used deleted.



-FQDN corrected=

-statement that RF=
C3455 is obsolete included in Head and Abstract



=A0
<=
p class=3D"MsoNormal">Best Regards



=A0
<=
p class=3D"MsoNormal">Roland


=A0
<=
div style=3D"border-style:solid none none;border-top-color:rgb(181,196,223)=
;border-top-width:1pt;padding:3pt 0cm 0cm">


Von: Mary Barnes [mailto:mary.ietf.barnes@gmail.com] 


Gesendet: Freitag, 10. Januar 2014 20:48
An: Andrew Allen<=
br>Cc: Jesske, Roland; dispatch@ietf.org; dean.willis@softarmor.com


Betreff: Re: [dispatch] PROTO Review: draft-drage-sipping-rfc3455bis=
-09.txt
=A0<=
/u>
Thanks Andrew. =A0So, that needs to be c=
learly stated in the abstract as well. =A0In addition, the Overview section=
 states:=A0


"This document is an update to RFC3455". =A0So that also needs to=
 be fixed. =A0 Given the number of changes at this=A0point, I would now pre=
fer Roland make those changes before we ask Gonzalo to progress it to IETF =
LC.



=A0
Mary.=A0
=A0
On Fri, Jan 10, 2014 at 1:45 PM, Andrew Allen <aallen@blackberry.com> wrote:=





I think it obsoletes RFC 3455. It i=
s a complete replacement for the original.

Andrew

=A0
From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com] 


Sent: Friday, January 10, 2014 02:37 PM Eastern Standard Tim=
e


To: R.Jessk=
e@telekom.de <R.Jesske@telekom.de> 
Cc: DISPATCH <dispatch@ietf.org>; Dean Will=
is <dean.=
willis@softarmor.com> 


Subject: Re: [dispatch] PROTO Review: draft-drage-sipping-rfc3455bis=
-09.txt 
=A0
There is yet one more change needed. =A0This document is an Update=
s to 3455bis (AFAIK, unless Obseletes works better for 3GPP usage). =A0That=
 categorization needs to be included in the document header (3rd line).=A0 =




=A0
Thanks,
Mary.=A0=



=A0
On Fri, Jan 10, 2014 at 1:=
34 PM, Mary Barnes <mary.ietf.barnes@gmail.com> wrote:


IN addition to removing the unused references in the next update, there are=
 still 4 domain names that are not using an appropriate documentation domai=
n (e.g., home.net). =A0Pl=
ease add that change to the list for the next revision. =A0I'm going to=
 ahead and forward the PROTO write-up to Gonzalo, noting the changes that a=
re needed and suggesting those changes can be made along with other IETF LC=
 changes. 



=A0
Thanks,
Mary<=
/u>


=A0
On Wed, Jan 8, 2014 at 2:4=
6 AM, <R.Jesske=
@telekom.de> wrote:
Thank you Marry,



for doing all this review.
So I ha=
ve now put out the errors.



There are still some unused r=
eferences which are in our informal reference section. But useful for the r=
eader to know they exist.



There are also some warnings =
with regard to IP addresses and wrong FQDNs which I think is some interpret=
ation of strings in the text which are not meant to be a IP address or FQDN=
 at all. 



=A0
<=
p class=3D"MsoNormal">Detail see below.



=A0
<=
p class=3D"MsoNormal">So now hopefully everything is=
 ready for the next step.



=A0
<=
p class=3D"MsoNormal">Best Regards<=
/u>



=A0
<=
p class=3D"MsoNormal">Roland


=A0
<=
p class=3D"MsoNormal">tmp/draft-drage-sipping-rfc3455bis-12.txt:



=A0
=A0 Checking boilerplate required by RFC 5378 and the IETF Tr=
ust (see



=A0 http://trustee.ietf.org/license-info):



=A0 -------------------------------------------=
---------------------------------


=A0
=A0=A0=A0=A0 N=
o issues found here.



=A0
=A0 Checking nits according to http://www.ietf.org/id-info/1id-g=
uidelines.txt:



=A0 -------------------------------------------=
---------------------------------


=A0
=A0=A0=A0=A0 N=
o issues found here.



=A0
=A0 Checking nits according to http://www.ietf.org/id-info/checklist =
:



=A0 -------------------------------------------=
---------------------------------


=A0
=A0=3D=
=3D There are 4 instances of lines with non-RFC2606-compliant FQDNs in the<=
/span>



=A0=A0=A0=A0 document.
=A0



=A0 =3D=3D There are 4 instances of lines with =
non-RFC5735-compliant IPv4 addresses


=A0=A0=A0=A0 in the document.=A0 If these are example addresses, they =
should be changed.
=A0<=
/span>



=A0
=A0 Miscellaneous warnings:



=A0 -------------------------------------------=
---------------------------------


=A0
=A0=A0=
=A0=A0 No issues found here.



=A0
=A0 Checking references for intended status: Informational<=
u>



=A0 -------------------------------------------=
---------------------------------


=A0
=A0 =3D=3D Mis=
sing Reference: 'RFC XXXX' is mentioned on line 1662, but not defin=
ed



=A0
=A0 -- Looks like a reference, but probably isn't: '3'=
 on line 1943



=A0
=A0 =3D=3D Unused Reference: 'RFC3262' is defined on =
line 2068, but no explicit



=A0=A0=A0=A0 reference was found in the text
=A0<=
/p>


=A0 =3D=3D Unused Reference: 'RFC3311=
' is defined on line 2072, but no explicit


=A0=A0=A0=A0 reference was found in the text
<=
p class=3D"MsoNormal">=A0



=A0 =3D=3D Unused Reference: 'RFC3428=
' is defined on line 2078, but no explicit


=A0=A0=A0=A0 reference was found in the text
<=
p class=3D"MsoNormal">=A0



=A0 =3D=3D Unused Reference: 'RFC3903=
' is defined on line 2090, but no explicit


=A0=A0=A0=A0 reference was found in the text
<=
p class=3D"MsoNormal">=A0



=A0 =3D=3D Unused Reference: 'RFC6086=
' is defined on line 2101, but no explicit


=A0=A0=A0=A0 reference was found in the text
<=
p class=3D"MsoNormal">=A0



=A0
=A0=A0=A0=A0 Summary: 0 errors (**), 0 flaws (~~), 8 warning=
s (=3D=3D), 1 comment (--).



=A0
=A0=A0=A0=A0 Run idnits with the --verbose option for more de=
tailed information about



=A0=A0=A0=A0 the items above.=



--------------------------------------------------------=
------------------------
=A0=




=A0
<=
p class=3D"MsoNormal">=A0



Von: Mary Barnes [mail=
to:mary.iet=
f.barnes@gmail.com] 


Gesendet: Dienstag, 7. Januar 2014 18:55

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



=A0
Thanks Roland. =A0I have reviewed that version and=
 all the changes I suggested have been made. =A0However, in doing the PROTO=
 write-up I realized that I wasn't certain anyone had reviewed the ABNF=
. So, I ran the ABNF through Bill Fenner's tool:=A0



=A0


And, there are a couple things that need to be fixed:
1) =A0DOT needs to change to "." (w=
e had this same bug in RFC 4244):


transit-io=
i-indexed-value =3D transit-ioi-name DOT transit-ioi-index=

=A0
<=
p class=3D"MsoNormal">

2) =A0There's an extra space here (between * and parenthesis):
transit-ioi-name=A0=A0=A0=A0=A0=A0=A0=A0=
=A0 =3D ALPHA * (ALPHA / DIGIT)



NEw: transit-ioi-name=A0=A0=A0=A0=A0=A0=A0=A0=A0 =3D ALPHA *(ALPHA / =
DIGIT)



=A0
There are also a number of long lines in the ABNF that shoul=
d be fixed.=A0
=A0



In addition, IDNITS identifies other erro=
rs and warnings per the following. =A0Those should also be addressed includ=
ing considering whether obsolete references need changing:


=A0<=
/u>
idnits 2.13.01 
=A0<=
/u>
tmp/draft-drage-sipping-rfc3455bis-11.txt:

=A0
=A0 Checking boilerplate required by RFC 5=
378 and the IETF Trust (see
=A0 http://trustee.ietf.org/lic=
ense-info):



=A0 ------------------------------------------------------------------=
----------
=A0
=A0=A0=A0=A0=
 No issues found here.
=A0
=
=A0 Checking nits according to http://www.ietf.org/id-info/1id-guidelines=
.txt:



=A0 ------------------------------------------------------------------=
----------
=A0
=A0=A0=A0=A0=
 No issues found here.
=A0
=
=A0 Checking nits according to http://www.ietf.org/id-info/checklist :<=
u>



=A0 ------------------------------------------------------------------=
----------
=A0
=A0 ** There=
 are 9 instances of too long lines in the document, the longest one<=
u>



=A0=A0=A0=A0 being 20 characters in excess of 72.
<=
pre>=A0
=A0 =3D=3D There are 4 instances of lines w=
ith non-RFC2606-compliant FQDNs in the
=A0=A0=A0=A0=
 document.



=A0
=A0 =3D=3D There are 4 instances of lines =
with non-RFC5735-compliant IPv4 addresses
=A0=A0=A0=
=A0 in the document.=A0 If these are example addresses, they should be chan=
ged.



=A0
=A0
=A0 Miscellane=
ous warnings:
=A0 ---------------------------------=
-------------------------------------------
=A0<=
/u>



=A0 =3D=3D The document seems to contain a disclaimer for pre-RFC5378 =
work, but was
=A0=A0=A0=A0 first submitted on or af=
ter 10 November 2008.=A0 The disclaimer is usually
=
=A0=A0=A0=A0 necessary only for documents that revise or obsolete older RFC=
s, and that



=A0=A0=A0=A0 take significant amounts of text from those RFCs.=A0 If y=
ou can contact all
=A0=A0=A0=A0 authors of the sour=
ce material and they are willing to grant the BCP78
=A0=A0=A0=A0 rights to the IETF Trust, you can and should remove the discl=
aimer. 


=A0=A0=A0=A0=A0Otherwise, the disclaimer is needed and you can ignore =
this comment. 
=A0=A0=A0=A0=A0(See the Legal Provis=
ions document at
=A0=A0=A0=A0 http://trustee.ietf.org/licen=
se-info for more information.)



=A0
=A0
=A0 Checking r=
eferences for intended status: Informational
=A0 --=
--------------------------------------------------------------------------<=
u>



=A0
=A0 =3D=3D Missing Reference: 'RFC XXX=
X' is mentioned on line 1667, but not defined
=
=A0
=A0 -- Looks like a reference, but probably isn=
't: '3' on line 1948



=A0
=A0 =3D=3D Unused Reference: 'RFC2976&=
#39; is defined on line 2065, but no explicit
=A0=
=A0=A0=A0 reference was found in the text
=A0
=A0 =3D=3D Unused Reference: 'RFC3262' is defined on line 2068, but=
 no explicit
=A0=A0=A0=A0 reference was found in th=
e text
=A0
=A0 =3D=3D Unuse=
d Reference: 'RFC3311' is defined on line 2075, but no explicit<=
/u>



=A0=A0=A0=A0 reference was found in the text
=
=A0
=A0 =3D=3D Unused Reference: 'RFC3428' =
is defined on line 2081, but no explicit
=A0=A0=A0=
=A0 reference was found in the text



=A0
=A0 =3D=3D Unused Reference: 'RFC3903&=
#39; is defined on line 2093, but no explicit
=A0=
=A0=A0=A0 reference was found in the text
=A0
=A0 ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234)
=A0
=A0 -- Obsolete informationa=
l reference (is this intentional?): RFC 2976
=A0=A0=
=A0=A0 (Obsoleted by RFC 6086)



=A0
=A0 -- Obsolete informational reference (i=
s this intentional?): RFC 3265
=A0=A0=A0=A0 (Obsole=
ted by RFC 6665)
=A0
=A0=




=A0=A0=A0=A0 Summary: 2 errors (**), 0 flaws (~~), 9 warnings (=3D=3D)=
, 3 comments (--).
=A0
=A0=
=A0=A0=A0 Run idnits with the --verbose option for more detailed informatio=
n about



=A0=A0=A0=A0 the items above.
While I apologize for not catching these issues earlier, it =
really is the responsibility of authors to check idnits (beyond what the su=
bmission tool requires) for their documents. =A0I routinely run idnits befo=
re I submit a document as it can also save time when fixing the =A0nits tha=
t the submission tool catches: =A0=A0https://tools.ietf.org/tools/idnits/



=A0
Regards,
=
Mary.=A0
=A0



=A0
=A0
On Tue, Jan 7, 2014 at 12:35 AM, <R.Jesske@telekom.de> wrote:<=
/u>



Hi Mary,<=
/u>
Now a new revis=
ion is available.



=A0=

Thank you and Best Regard=
s



=A0
<=
p class=3D"MsoNormal">Roland


=A0
<=
/div>



Von: Mary Barnes [mailto:mary.ietf.barnes@gmail=
.com] 


Gesendet: Montag, 6. Januar 2014 20:00

An: Jesske, Roland

Cc: DISPATCH; Gonzalo Camarillo; Atle Monrad; Dean Willis
Betr=
eff: Re: PROTO Review: draft-drage-sipping-rfc3455bis-09.txt<=
/u>
=A0=




Hi Roland,
=A0
One final e=
ditorial nit below. =A0If you can spin a revision, then I'll send the P=
ROTO write-up to the AD.



=A0
Thanks,
M=
ary.=A0


=A0
On Thu, Jan 2, 2014 at 3:2=
9 AM, <R.Jesske=
@telekom.de> wrote:
Hi Mary,



I wish you a happy new year 2=
014. And the best for the next year.


=A0
<=
p class=3D"MsoNormal">I was looking again on my chan=
ges I made due to your proposal in December.



I realized that if I change t=
he SHOULD to MUST we have now a backward compatibility problem.



We are using the P-Associated=
-URI also over the IMS user interface which is not encrypted.=




So I propose to add some more=
 words.
=85



Section 6.1<=
/u>
=85



=A0=A0=A0=A0=A0=A0=A0=A0 <t>An eavesdropper could possibly collect the list of iden=
tities a user is registered.=A0 



=A0=A0=A0=A0=A0=A0=A0This can have privacy =
implications. To mitigate this problem, this extension SHOULD 



=A0=A0=A0=A0=A0=A0=A0=
only be used in a secured environment, where encryption of SIP messages is =

=A0=A0=A0=A0=
=A0=A0=A0provided either end-to-end or hop-by-hop.=A0 </t>



=A0=A0 
=A0=A0=A0=A0=A0=A0<t> Since the P-Associated-URI header field value allows to implicitly regis=
ter 



=A0=A0=A0=A0=A0=A0a bundle of URIs with one=
 REGISTER Message the impact of security using the P-Associated-URI header =
field is not higher than=A0 



=A0=A0=A0=A0=A0=A0using single REGISTER messages when registering all ide=
ntities explicit.</t>



[MB] I just have some editorial sug=
gestions for the above:
=
NEW: =A0
<t>=A0While the P-Associated-URI header field value allows the i=
mplicit registration of=A0



=A0=A0=A0=A0=A0=A0a bundle of U=
RIs with one REGISTER Message the impact of security using the P-Associated=
-URI header field is no higher than=A0
=A0=A0=A0=A0=A0=A0using separate REGISTER m=
essages for each of the URIs.=A0</t>



[/MB]
=A0
=




=A0



=
=A0
=A0
For the P-Called-Party-Id the change sh=
ould be also done like as follows:



=A0=

=A0=A0=A0=A0=A0=A0=A0 <t>An eavesdropper could possibly collect t=
he list of identities a user is registered.=A0 



=A0=A0=A0=A0=A0=A0=A0This can have privacy =
implications.=A0 To mitigate this problem, this extension SHOULD =




=A0=A0=A0=A0=A0=A0=A0=
only be used in a secured environment, where encryption of SIP messages is =

=A0=A0=A0=A0=A0=A0=A0provided either end-t=
o-end or hop-by-hop.=A0 </t><=
/u>



=A0

=A0=A0=A0=A0=A0=A0=A0=
 <t>Normally within a 3GPP environment t=
he P-Called-Party-ID is not sent towards end users but may be exchanged bet=
ween carriers where other security mechanisms than SIP encryption are used.=
=A0 </t>



=A0
<=
p class=3D"MsoNormal">Sorry coming so late.



If this is OK for you I will =
include it to a new version.


=A0
<=
p class=3D"MsoNormal">Thank you and Best Regards



=A0
<=
p class=3D"MsoNormal">Roland


=A0
<=
/div>



Von: Mary Barnes [mailto:mary.ietf.barnes@gmail.com] 


Gesendet: Freitag, 27. Dezember 2013 19:45
<=
div>

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



=A0
Hi Roland,
=A0
Thanks for mak=
ing these changes. I finally had a chance to review this updated version. =
=A0 I still have a couple comments on the security section as I think you w=
ill get questions during SEC review around this unless some more detail is =
provided on security threats and impacts. =A0 I've extracted these few =
points from previous review comment threads.



=A0
Thanks,
M=
ary.
=A0




----Previous point =A0------------------------------=
--->
- Section 6.1: this needs some tighter wording. =A0What is mean=
t by "potentially annoying" =A0for example? =A0<=
/u>



=A0[RJ] I do not know. T=
his 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."
=A0=



=A0
I don't think that adds any va=
lue and just begs the question "what are the insignificant impacts and=
 are there any privacy concerns"?=A0 Really, it's the next paragra=
ph that provides details of the impacts.=A0 I think you could probably remo=
ve that sentence altogether and not lose anything. 



<=
/u>=A0
=
=A0
=A0
=A0
=A0


[/MB]
=A0


----Previous point --------------------------------->
=A0


-=A0 Section 6.2: I think you need to be more specific about the &=
quot;nature" that makes this header not of particular concern with reg=
ards to security. Does it reveal additional, unique information about an in=
dividual that isn't available in other headers. =A0Also, the 2nd paragr=
aph needs some work - maybe something like:



<=
/u>=A0
=
=A0
=A0
=A0
=A0


OLD:
=A0


=A0
An eave=
sdropper may collect the list of identities a user is registered.=A0 This m=
ay have privacy implications.=A0 To mitigate this problem, this extension S=
HOULD only be used in a secured environment, where encryption of SIP messag=
es is provided either end-to-end or



<=
/u>=A0
=
=A0
=A0
=A0
=A0


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



=A0
An =
eavesdropper could possibly collect the list of identities a user is regist=
ered.=A0 This can have privacy implications.=A0 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.=A0



----End previous point --------=
----------------------<
=A0
[MB]=A0 The suggested change for the fi=
rst sentence didn't get into the revision.=A0 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=
9;t available in other headers.=A0=A0 [/MB]



=A0<=
/span>
=A0
=A0



=A0
=A0
=A0=




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

Hi Mary,<=
u>



Thank you for your comments a=
nd proposals.

I have now included all comments and uploaded a new =
version.
So we can now proceed.



=A0=

Thank you and Best Regard=
s



=A0
<=
p class=3D"MsoNormal">Roland


=A0
<=
/div>
A new version of I-D, draft-drage-sipping-rfc3=
455bis-10.txt



has been successfully submitted by Roland Jesske an=
d posted to the IETF repository.
=A0
Filename:=A0=A0 d=
raft-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 (SIP) for the 3rd=
-Generation Partnership Project (3GPP)



Creation date:=A0=A0=A0 2013-12-03<=
/u>
Group:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0 Individual Submission
N=
umber 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 Protocol<=
/u>



=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
<=
/div>



Von: Mary Barnes [mailto:mary.ietf.barnes@gmail.com] 


Gesendet: Montag, 25. November 2013 23:01

An: Jesske, Roland
Cc: DISPA=
TCH; Gonzalo Camarillo; Atle Monrad; Dean Willis



Betreff: Re: PROTO Review: draft-drage-sipping-rfc3455bis-09.txt<=
/u>
=A0
<=
div>
Hi Roland,


=A0
Thanks for your resp=
onse. =A0Additional comments below [MB].
=A0
Tha=
nks,



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




Hi Mary,<=
/u>
Thank you for y=
our review.



I have added now your proposa=
ls to the draft.

Other comments please see below.
=A0=




I hope now everything is OK.<=
/span>
=
=A0



Thank you and Best Regards
=A0



Roland
=A0


Von: Mary Barnes=
 [mailto:ma=
ry.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
=A0
=A0
=A0
- Section 3. =A0This =
section needs to be updated. =A0I don't think that 10 year old backgrou=
nd is relevant in the current context. =A0 You should be able to model this=
 after the text in more recent 3GPP P-header documents, referring to the SI=
P change process.=A0



=A0
[RJ] OK, I have changed the text:



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




=A0=A0=A0=A0 the protocol used to establish and tear down multimedia sessi=
ons in the



=A0=A0=A0=A0 context of its IP Multimedia Subsystem (IMS). For more inform=
ation on



=A0=A0=A0=A0 the IMS, a detailed description can be found in 3GPP TS 23.22=
8 . This document is an update of RFC3455=A0 =A0which covers the requiremen=
ts in RFC4083 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<=
u>



[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 (3GPP) uses SIP as



=A0=A0=A0=A0 the protocol =A0=
to establish and tear down multimedia sessions in the<=
/p>

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


=A0 =A0 =A0the 3GPP TS 23.228=
 specification.=A0
=A0 =A0 =A0RFC 3455 defines SIP private header extensions (re=
ferred to as P-headers) which are=A0



=A0 =A0 =A0required by the 3G=
PP 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 upda=
tes existing P-header=A0descriptions=A0=




=A0 =A0 =A0to address additional requirement=
s which are needed for 3GPP Release 11.=A0


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


=A0
[/MB]=A0
=A0



- Section 4.1. "registered address-of-record" ->=
; "registered SIP address-of-record"



- Section 4.1, 3rd paragraph. =A0"Note that, 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 applicable to proxies, therefo=
re the proxy MUST relay the header field unchanged. =A0I would suggest rewo=
rding 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=




NEW:=

=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
=A0
=A0
=A0
Section 4.2, 1st paragraph. =A0The behavior in t=
his sentence is not normative from a SIP protocol perspective, thus 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 is not normative fr=
om a SIP protocol perspective, thus =A0I suggest the MAY be changed to &quo=
t;can".=A0



=A0
- Section 4.3.3, last paragraph. =A0I thi=
nk this ought to be a MUST: "The identifier should be globally unique.=
."=A0



=A0
- Section 4.3.2.1. =A0This text has chang=
ed from the -08. =A0 I don't know what a "normal User Equipment&qu=
ot; is and the term "User Equipment" is not defined in this speci=
fication. =A0I think it would be better to say something like. However, eve=
n with this proposed change, I think you also need text for user agent serv=
er behavior - i.e., what would a UAS do if it received this header.=A0



=A0
OLD:
=A0=A0 A normal User Equipme=
nt has normally no knowledge of the P-Visited-



=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.
=A0
=A0
=A0
NEW:=A0=

=A0=A0 In the context of t=
he network to which the header fields defined in this document apply, a Use=
r Agent has=A0no knowledge of the P-Visited-Network-ID when sending the REG=
ISTER request. =A0Therefore user agent clients MUST NOT insert a P-Visited-=
Network-ID=A0header field=A0in any SIP message.



=A0
- Section 4.3.2.2:, 2nd paragraph: =A0"home network MAY use&qu=
ot; -> "home network can use"



=A0
=A0<=
/pre>
=A0
=A0
=A0
=A0
=A0
- Section 4.3.2.2, last paragr=
aph: =A0
=A0
=A0


OLD: Note that a r=
eceived P-Visited-Network-ID from a UA is a failure case and must be delete=
d.
=A0
NE=
W: =A0Note that a received P-Visited-Network-ID from a UA is a failu=
re case and MUST be deleted when the request is forwarded. 


=A0<=
/pre>
=
Section 4.4.2.1, 2nd paragraph: =A0"MUST trust the proxy" -> &=
quot;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 tr=
ust" -> =A0"there MUST also be a transitive trust"=A0



Section 4.4.2.2, 2nd paragraph: "MAY act upo=
n any information present" -> "can act upon any information pr=
esent", =A0"MAY use the call id" -> "can use the=A0<=
/span>call id"=A0<=
u>



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


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



=A0
- Section 4.6.2, 3rd paragrap=
h: "MAY use the values" -> "can use the values"=A0


- Section 4.6.3, 3rd paragraph: needs some editorial work. =A0Ma=
ybe the following change would work:=A0


=A0
=A0<=
u>
OLD:
=
=A0


=A0=A0 Depending on the call scenario it is needed to add for each tra=
nsit
=A0=A0 network either a transit network name o=
r a void value. =A0Nevertheless
=A0=A0 it can not b=
e guaranteed that all values will appear within the P-Charging-Vector heade=
r field.=A0



=A0
=A0<=
u>
NEW:=A0
=A0<=
/pre>

=A0=A0 Depending o=
n the call scenario, each transit network can add either a transit network =
name=A0or a void=A0=A0=A0 value.=A0 However, it can not be guaranteed that =
all the values that are added will appear within the P-Charging-Vector head=
er field.



=A0
- Section 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 that is trying to s=
ay other than void values have no index. =A0What does "taken into cons=
ideration" mean. Are you talking about limits on the number of entries=
 or are you suggesting that the number of void values must be considered wh=
en setting the index for the transit network names? =A0



=A0
[RJ] Yes! Changed the text to:



=A0
A void value has no index. By a=
dding the next value the index has to be incremented by the number of void =
entries +1.



=A0
- Section 4.6.4.2: I don't kn=
ow what this means:=A0=A0"A deletion of the elements could appear depending on=
 the network policy and trust rules". =A0Is it just trying to say that along with the adding =
and modifying in the previous sentence that the elements can also be delete=
d by the proxy?=A0



=A0
[RJ] Yes, I have changed the text:



Procedures described within 4.6.2.2 apply. A transit-ioi MAY be<=
/u>



=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 added or modified by a proxy. 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 re=
placing the transit-ioi with a void value.
<=
pre>=A0

=A0
=A0
=A0


=A0
=A0<=
u>
- Section 5.7=
. Delete this text and table. =A0 We aren't these tables anymore as the=
y really don't provide any useful information. =A0You just need to verb=
ally 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 REGI=
STER method and 2xx resonses, P-Called-Party-ID can appear in SIP INVITE, O=
PTIONS, PUBLISH,SUBSCRIBE, MESSAGE methods and all responses, P-Visited-Net=
work-ID can appear in all SIP methods except ACK, BYE and CANCEL and all re=
sponses, 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 CANCEL.



[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 an=
noying" =A0for example? =A0



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




=A0=

- Sectio=
n 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=
9;t available in other headers. =A0Also, the 2nd paragraph needs some work =
- maybe something like:



=A0
OLD:
An eavesdropper may collect =
the list of identities a user is registered.=A0 This may have privacy impli=
cations.=A0 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



=A0
=A0<=
/pre>
=A0
=A0
=A0
=A0
=A0
=
hop-by-hop.=A0



=A0 =A0
=A0
NEW:=A0
=A0
=A0An eavesdropper coul=
d possibly collect the list of identities a user is registered.=A0 This can=
 have privacy implications.=A0 To mitigate this problem, this extension MUS=
T only be used in a secured environment, where encryption of SIP messages i=
s 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 registe=
red by a user."=A0

[/MB]=A0=A0


- Section 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
=A0
=A0
=A0
-- 8th paragraph: "SHOULD NOT send =
sensitive information" -> "MUST NOT send sensitive information=
"



=A0
=A0<=
u>
-- 9th paragr=
aph: "is required to delete" -> "is REQUIRED to delete&qu=
ot;=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 these headers, is it not?



=A0
[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.



=A0
-- 11th paragraph: So, what does a proxy do with that informatio=
n. =A0What are the impl=
ications if the information is used and it's not valid? =A0



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



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



=A0=A0=A0=A0=A0=A0 header field from a non-trusted entity is not able to g=
uarantee the



=A0=A0=A0=A0=A0=A0 validity of the contents. Th=
us this content SHOULD be deleted based on local policy.</t>



=A0
- Sectio=
n 9, item 2. =A0I think you need to add this text with regards to the recom=
mendation to use RFC 4244 (bis) to the body of this document and include a =
real reference.



=A0
[RJ] OK done. I let the reference RFC4244 si=
nce 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 target=3D"RFC4244=
"></xref>. 3GPP will continue to use the=



=A0=A0=A0=A0=A0=A0=A0=A0 P-Called-Party-ID head=
er field even though RFC 4244 <xref
=A0=A0=A0=A0=A0=A0=A0=A0 target=3D"RFC4244">=
</xref> has now been published.</t>



=A0
I think the text in Section 9.2 is better.



Nits:
=A0
=A0
=A0
=A0
- Section 4.1, 2nd paragraph. =A0"has assoc=
iated to an address-of-record" -> "has associated with an addr=
ess-of-record"



- Section 4.1.2.2, 2nd parag=
raph, "In case" -> "If", =A0"shall not" -&=
gt; SHALL NOT



- Section 4.3.2.2, last sentence. =A0The -09 int=
roduced a typo: "T means" -> "This means"=A0<=
u>



=A0
- Section 4.3.2.3, 1=
st paragraph after 1st example. =A0The -09 introduced another typo: "t=
he REGISTRAR" -> "at the REGISTRAR"<=
/pre>


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



=A0
=
Section 4.6, 2nd paragraph: "includes, includes but is not limited to&=
quot; -> "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 t=
o inform you that I have implemented all comments coming from the expert re=
view 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


=A0
=A0
=

=A0
<=
/div>


=A0
=A0
---------------------------------------------------------------------This transmission (including any attachments) may contain confidential inf=
ormation, privileged material (including material protected by the solicito=
r-client or other applicable privileges), or constitute non-public informat=
ion. Any use of this information by anyone other than the intended recipien=
t is prohibited. If you have received this transmission in error, please im=
mediately reply to the sender and delete this information from your system.=
 Use, dissemination, distribution, or reproduction of this transmission by =
unintended recipients is not authorized and may be unlawful.<=
/p>


=A0
<=
/blockquote>


--047d7bb04f6843180104f01810b6--


From christer.holmberg@ericsson.com  Sat Jan 18 00:53:08 2014
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 A289C1ADDBD for ; Sat, 18 Jan 2014 00:53:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.85
X-Spam-Level: 
X-Spam-Status: No, score=-3.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 lIdwteLlTgp8 for ; Sat, 18 Jan 2014 00:53:05 -0800 (PST)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 397251ADD9D for ; Sat, 18 Jan 2014 00:53:04 -0800 (PST)
X-AuditID: c1b4fb2d-b7f1c8e000005ceb-05-52da40e2d4e6
Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id A9.C4.23787.2E04AD25; Sat, 18 Jan 2014 09:52:50 +0100 (CET)
Received: from ESESSMB209.ericsson.se ([169.254.9.114]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.02.0387.000; Sat, 18 Jan 2014 09:52:50 +0100
From: Christer Holmberg 
To: Mary Barnes , DISPATCH 
Thread-Topic: [dispatch] I-D Action: draft-pd-dispatch-msrp-websocket-03.txt
Thread-Index: AQHPDleQGzr1Sxm0FkKTa2Dy1OUwAJqKNzng
Date: Sat, 18 Jan 2014 08:52:49 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1D104D91@ESESSMB209.ericsson.se>
References: <20131213005747.777.34301.idtracker@ietfa.amsl.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: fi-FI
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.150]
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D104D91ESESSMB209erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNLMWRmVeSWpSXmKPExsUyM+Jvje4jh1tBBj/+aFg0P/zFZrF00gJW i8tbPrNbfN6/n9mBxePx11msHjtn3WX3WLLkJ5PHl8uf2QJYorhsUlJzMstSi/TtErgy9syU KDg6m7Fi65t5zA2MD1oYuxg5OSQETCSOHn3CCmGLSVy4t56ti5GLQ0jgEKPE8u/LmCCcJYwS d3rmA1VxcLAJWEh0/9MGaRAR8JJ48fsDWA2zQA+jxL29E1hAEsIC3hJTlr9lhijykbi5/QAT hG0k8W3CVDYQm0VAVeJm30Mwm1fAV2Lv3P9Qy9oYJfq2L2YHSXAKBErc3XAWrJkR6Lzvp9aA 2cwC4hIfDl5nhjhbQGLJnvNQtqjEy8f/oN5Rklix/RIjRH2+xJbDJ6GWCUqcnPmEZQKj6Cwk o2YhKZuFpAwiridxY+oUNghbW2LZwtdQ9boSM/4dYkEWX8DIvoqRPTcxMye93HATIzACD275 rbuD8dQ5kUOM0hwsSuK8H946BwkJpCeWpGanphakFsUXleakFh9iZOLglGpg9JmuuTFP3cHx JdvEdfWs5Z9mLsgRNCn1YJj+UN/Dde/JVIcbnT/uaJw9sOVZXS3Xh60+bmenCPF3nfaIOau/ bEq57dfzK8zFe4XKF/F+dT7LE/siWs5nKvvaNRW8Wyduuv36WXTiUf/Jtev0V0u4tK66KfKP pzGxx06mrOOzw9pzxm4c8rmflViKMxINtZiLihMB4gSjQY4CAAA=
Cc: Ben Campbell , "draft-pd-dispatch-msrp-websocket@tools.ietf.org" 
Subject: Re: [dispatch] I-D Action: draft-pd-dispatch-msrp-websocket-03.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: Sat, 18 Jan 2014 08:53:08 -0000

--_000_7594FB04B1934943A5C02806D1A2204B1D104D91ESESSMB209erics_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,

I have not followed the work on this draft, so I appologize if the followin=
g has been discussed.

While I do understand that a WS Client has to establish the WebSocket with =
the Web Server, I don't understand why we need to mandate the WS Server to =
be an MSRP Relay. That would e.g. prevent the usage of MSRP-CEMA.

Regards,

Christer



L=E4hett=E4j=E4: dispatch [mailto:dispatch-bounces@ietf.org] Puolesta Mary =
Barnes
L=E4hetetty: 11. tammikuuta 2014 0:59
Vastaanottaja: DISPATCH
Kopio: Ben Campbell; draft-pd-dispatch-msrp-websocket@tools.ietf.org
Aihe: Re: [dispatch] I-D Action: draft-pd-dispatch-msrp-websocket-03.txt

I have agreed to shepherd this document.  I've reviewed the document in ant=
icipation of doing the PROTO write-up and have the following comments and q=
uestions.  Ben Campbell has agreed to do the required expert review and tha=
t should be posted within the next week or so.    This is also a good time =
for anyone in the WG that hasn't previously reviewed this document to revie=
w and provide any final comments.  Note, that this document was agreed to b=
e AD sponsored around the IETF-86 timeframe.

Regards,
Mary.

Review Summary: Almost ready. Comments & questions below.

1)  Section 2 & General.  I'm not sure the documented approach for separati=
ng normative text from non-normative is quite so helpful.  In general, we e=
xpect that in the case of standards track document use RFC 2119 language to=
 indicate normative behaviors.  I think the first sentence is good, but tha=
t's not a terminology thing.   I just don't see a lot of value in writing t=
he document this way.  For example, the definitions aren't stated to be non=
-normative, but I don't see anything normative about the definitions.  I th=
ink you could easily title Section 3 as "WebSocket Protocol overview" and t=
hat would clearly imply non-normative behavior.  There are also several pla=
ces in the document in sections that I believe are intended to provide norm=
ative behavior, but there is certainly non-normative text in those sections=
 (e.g., section 5.2.2, second paragraph).  I would suggest this document fo=
llow the typical (and accepted) style of identifying normative behavior wit=
h 2119 language (consistently using upper case for normative behavior and a=
voiding using 2119 language in cases where alternative words can be substit=
uted).

2) Section 5.2.2, 2nd paragraph.  Related to my point above, it's not clear=
 to me this is normative behavior.  I don't think it is since it's referrin=
g to existing 4975 behavior. However, I didn't see that the reference given=
 in 4975 relates to the second part of that sentence stating that implement=
ations "should" already be allowing unrecognized transports.  It would be q=
uite useful to have the exact reference here as I was trying to double chec=
k this point and I couldn't find it.

3) Section 6.  I'm really puzzled as to why the Connection Keep-alive would=
 be non-normative.  In particular given that 2119 language is clearly being=
 used.

4) Section 7.  Again, I'm puzzled as to why Authentication is considered no=
n-normative. AGain, you have 2119 language in this section.

5) Section 10.1. Since securing the connection is just RECOMMENDED, what ar=
e the implications and risks if the MSRP traffic isn't transported over a s=
ecure connection?

6) Section 11.  You should change the name of the registry to be the exact =
name of the IANA registry to avoid any confusion.- i.e.,:
OLD:
  registry of WebSocket sub-protocols
NEW:
  WebSocket Subprotocol Name Registry

7) Section 11. There is also a Reference field in that IANA registry. I wou=
ld suggest you use the same information as the pointer to the Subprotocol D=
efinition (i.e., this RFC).

8) It's typical for documents that are updating existing RFCs to have a sec=
tion that summarizes the updates to the existing RFCs that are made by this=
 document.



On Thu, Dec 12, 2013 at 6:57 PM, > wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.


        Title           : The WebSocket Protocol as a Transport for the Mes=
sage Session Relay Protocol (MSRP)
        Author(s)       : Peter Dunkley
                          Gavin Llewellyn
                          Victor Pascual
                          Anton Roman
                          Gonzalo Salgueiro
        Filename        : draft-pd-dispatch-msrp-websocket-03.txt
        Pages           : 21
        Date            : 2013-12-12

Abstract:
   The WebSocket protocol enables two-way real-time communication
   between clients and servers.  This document specifies a new WebSocket
   sub-protocol as a reliable transport mechanism between MSRP (Message
   Session Relay Protocol) clients and relays to enable usage of MSRP in
   new scenarios.  This document normatively updates RFC 4975 and RFC
   4976.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-pd-dispatch-msrp-websocket

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-pd-dispatch-msrp-websocket-03

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-pd-dispatch-msrp-websocket-03


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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


--_000_7594FB04B1934943A5C02806D1A2204B1D104D91ESESSMB209erics_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Hi,


 <=
/p>

I have not=
 followed the work on this draft, so I appologize if the following has been=
 discussed.


 =
;


While I do=
 understand that a WS Client has to establish the WebSocket with the Web Se=
rver, I don’t understand why we need to mandate the WS Server
 to be an MSRP Relay. That would e.g. prevent the usage of MSRP-CEMA.<=
/o:p>


 =
;


Regards,


 =
;


Christer


 =
;


 =
;


 =
;


L=E4hett=E4j=E4: dispatch [mailto:dispatch-bounces@ietf.org]
Puolesta Mary Barnes

L=E4hetetty: 11. tammikuuta 2014 0:59

Vastaanottaja: DISPATCH

Kopio: Ben Campbell; draft-pd-dispatch-msrp-websocket@tools.ietf.org=


Aihe: Re: [dispatch] I-D Action: draft-pd-dispatch-msrp-websocket-03=
.txt


 




I have agreed to shepherd this document.  I've =
reviewed the document in anticipation of doing the PROTO write-up and have =
the following comments and questions.  Ben Campbell has agreed to do t=
he required expert review and that should be
 posted within the next week or so.    This is also a good time f=
or anyone in the WG that hasn't previously reviewed this document to review=
 and provide any final comments.  Note, that this document was agreed =
to be AD sponsored around the IETF-86 timeframe.




 






Regards,






Mary. 






 








Review Summary: Almost ready. Comments & questio=
ns below.






 






1)  Section 2 & General.  I'm not sure=
 the documented approach for separating normative text from non-normative i=
s quite so helpful.  In general, we expect that in the case of standar=
ds track document use RFC 2119 language to indicate normative
 behaviors.  I think the first sentence is good, but that's not a term=
inology thing.   I just don't see a lot of value in writing the docume=
nt this way.  For example, the definitions aren't stated to be non-nor=
mative, but I don't see anything normative about
 the definitions.  I think you could easily title Section 3 as "W=
ebSocket Protocol overview" and that would clearly imply non-normative=
 behavior.  There are also several places in the document in sections =
that I believe are intended to provide normative behavior,
 but there is certainly non-normative text in those sections (e.g., section=
 5.2.2, second paragraph).  I would suggest this document follow the t=
ypical (and accepted) style of identifying normative behavior with 2119 lan=
guage (consistently using upper case
 for normative behavior and avoiding using 2119 language in cases where alt=
ernative words can be substituted).






 






2) Section 5.2.2, 2nd paragraph.  Related to my=
 point above, it's not clear to me this is normative behavior.  I don'=
t think it is since it's referring to existing 4975 behavior. However, I di=
dn't see that the reference given in 4975 relates
 to the second part of that sentence stating that implementations "sho=
uld" already be allowing unrecognized transports.  It would be qu=
ite useful to have the exact reference here as I was trying to double check=
 this point and I couldn't find it. 






 






3) Section 6.  I'm really puzzled as to why the=
 Connection Keep-alive would be non-normative.  In particular given th=
at 2119 language is clearly being used.  






 






4) Section 7.  Again, I'm puzzled as to why Aut=
hentication is considered non-normative. AGain, you have 2119 language in t=
his section.  






 






5) Section 10.1. Since securing the connection is ju=
st RECOMMENDED, what are the implications and risks if the MSRP traffic isn=
't transported over a secure connection? 






 






6) Section 11.  You should change the name of t=
he registry to be the exact name of the IANA registry to avoid any confusio=
n.- i.e.,:






OLD:






  registry of WebSocket sub-protocols






NEW: 






  WebSocket Subprotocol Name Registry  






 






7) Section 11. There is also a Reference field in th=
at IANA registry. I would suggest you use the same information as the point=
er to the Subprotocol Definition (i.e., this RFC). 






 






8) It's typical for documents that are updating exis=
ting RFCs to have a section that summarizes the updates to the existing RFC=
s that are made by this document.  






 






 








 




On Thu, Dec 12, 2013 at 6:57 PM, <internet-drafts@ietf.org=
> wrote:




A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.





        Title           : The =
WebSocket Protocol as a Transport for the Message Session Relay Protocol (M=
SRP)

        Author(s)       : Peter Dunkley<=
br>
                     =
;     Gavin Llewellyn

                     =
;     Victor Pascual

                     =
;     Anton Roman

                     =
;     Gonzalo Salgueiro

        Filename        : draft-pd-=
dispatch-msrp-websocket-03.txt

        Pages           : 21
        Date            :=
 2013-12-12



Abstract:

   The WebSocket protocol enables two-way real-time communication=


   between clients and servers.  This document specifies a n=
ew WebSocket

   sub-protocol as a reliable transport mechanism between MSRP (M=
essage

   Session Relay Protocol) clients and relays to enable usage of =
MSRP in

   new scenarios.  This document normatively updates RFC 497=
5 and RFC

   4976.





The IETF datatracker status page for this draft is:

https://datatracker.ietf.org/doc/draft-pd-dispatch-msr=
p-websocket



There's also a htmlized version available at:

http://tools.ietf.org/html/draft-pd-dispatch-msrp-websock=
et-03



A diff from the previous version is available at:

http://www.ietf.org/rfcdiff?url2=3Ddraft-pd-dispa=
tch-msrp-websocket-03





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.



Internet-Drafts are also available by anonymous FTP at:

ftp://ftp=
.ietf.org/internet-drafts/



_______________________________________________

I-D-Announce mailing list

I-D-Announce@ietf.org

https://www.ietf.org/mailman/listinfo/i-d-announce

Internet-Draft directories: 
http://www.ietf.org/shadow.html

or =
ftp://ftp.ietf.org/ietf/1shadow-sites.txt




 










--_000_7594FB04B1934943A5C02806D1A2204B1D104D91ESESSMB209erics_--

From peter.dunkley@crocodilertc.net  Sun Jan 19 05:53:13 2014
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 E40761ACCEB for ; Sun, 19 Jan 2014 05:53:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level: 
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=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 XbFYmcalVOF6 for ; Sun, 19 Jan 2014 05:53:11 -0800 (PST)
Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 761BC1AC421 for ; Sun, 19 Jan 2014 05:53:11 -0800 (PST)
Received: by mail-ie0-f169.google.com with SMTP id tq11so5483696ieb.28 for ; Sun, 19 Jan 2014 05:52:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=crocodilertc.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BWL11cdD/JDijz9Xi7t7jJFcmjXPbxz+IDhoe3bXRRE=; b=gqmyjCTp+m+MEFlXCtll2koFSJY03tBP1jQCJTOgLelx0TM98sso1v7JBg+Prg4Htz LqZhsKJmPGfx4O635IdHCgoFWLjSgyuLZnLEI9NHlwK11o7GOTUxiFioBcmnRp0ZIcm9 GRwJejqkP99HbKJGsGtudiGvo6u5tDk/0Qrkg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=BWL11cdD/JDijz9Xi7t7jJFcmjXPbxz+IDhoe3bXRRE=; b=ERKxMWWdGVzcbtVuXA2EgrY7XbBWnZagtNXBHDRxnNem5y8Xh0nF5UedvAOX6kASCw JiWNKJxZVMEYhV43GCQrksCc6gZ+Ga3jd30kbypOx/gbB+E6wzp5hxsrxwLVMCP4E4P5 YeV2JNlgsLlVpUptrS1JHupFKeNbjfNywZUSdtfdjB0XKDXTQpgfnXzjFxK53bcjn9bS 9bji2DH3Hv9KZakEVQx9aMgYcN6wGGstP/LtPKoFNP6LiWgR+BAglWHa28O/lxtfS3xf 4Yfgq9W5MvfPausgMaafE3uxw+At3M0LyiOSM7pWv7er5mk54Mb8MFGMcXqp/1RFv+Vl 4fFw==
X-Gm-Message-State: ALoCoQlU+qC94in/+JniD68jnf74t1jmwm1j2IUcih9K1EPPnNS5GqQmmNSo2NA9Yb6XOQKhvXuW
MIME-Version: 1.0
X-Received: by 10.50.50.70 with SMTP id a6mr7726893igo.1.1390139578055; Sun, 19 Jan 2014 05:52:58 -0800 (PST)
Received: by 10.64.229.13 with HTTP; Sun, 19 Jan 2014 05:52:57 -0800 (PST)
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D104D91@ESESSMB209.ericsson.se>
References: <20131213005747.777.34301.idtracker@ietfa.amsl.com>  <7594FB04B1934943A5C02806D1A2204B1D104D91@ESESSMB209.ericsson.se>
Date: Sun, 19 Jan 2014 13:52:57 +0000
Message-ID: 
From: Peter Dunkley 
To: Christer Holmberg 
Content-Type: multipart/alternative; boundary=089e010d9d40bd187304f053175b
Cc: DISPATCH , Ben Campbell , "draft-pd-dispatch-msrp-websocket@tools.ietf.org" 
Subject: Re: [dispatch] I-D Action: draft-pd-dispatch-msrp-websocket-03.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: Sun, 19 Jan 2014 13:53:14 -0000

--089e010d9d40bd187304f053175b
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Hello,

Perhaps the document title should be corrected. MSRP-CEMA is outside of the
scope of this document as this document is intended to describe connecting
to a WebSocket server that is an MSRP relay.

I can see no reason why MSRP-CEMA can't be used over WebSockets, but if
anyone has an interest in this I think that they should put it in a
document of its own.


Regards,

Peter


On 18 January 2014 08:52, Christer Holmberg
wrote:

>  Hi,
>
>
>
> I have not followed the work on this draft, so I appologize if the
> following has been discussed.
>
>
>
> While I do understand that a WS Client has to establish the WebSocket wit=
h
> the Web Server, I don=92t understand why we need to mandate the WS Server=
 to
> be an MSRP Relay. That would e.g. prevent the usage of MSRP-CEMA.
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
>
>
>
>
> *L=E4hett=E4j=E4:* dispatch [mailto:dispatch-bounces@ietf.org] *Puolesta =
*Mary
> Barnes
> *L=E4hetetty:* 11. tammikuuta 2014 0:59
> *Vastaanottaja:* DISPATCH
> *Kopio:* Ben Campbell; draft-pd-dispatch-msrp-websocket@tools.ietf.org
> *Aihe:* Re: [dispatch] I-D Action: draft-pd-dispatch-msrp-websocket-03.tx=
t
>
>
>
> I have agreed to shepherd this document.  I've reviewed the document in
> anticipation of doing the PROTO write-up and have the following comments
> and questions.  Ben Campbell has agreed to do the required expert review
> and that should be posted within the next week or so.    This is also a
> good time for anyone in the WG that hasn't previously reviewed this
> document to review and provide any final comments.  Note, that this
> document was agreed to be AD sponsored around the IETF-86 timeframe.
>
>
>
> Regards,
>
> Mary.
>
>
>
> Review Summary: Almost ready. Comments & questions below.
>
>
>
> 1)  Section 2 & General.  I'm not sure the documented approach for
> separating normative text from non-normative is quite so helpful.  In
> general, we expect that in the case of standards track document use RFC
> 2119 language to indicate normative behaviors.  I think the first sentenc=
e
> is good, but that's not a terminology thing.   I just don't see a lot of
> value in writing the document this way.  For example, the definitions
> aren't stated to be non-normative, but I don't see anything normative abo=
ut
> the definitions.  I think you could easily title Section 3 as "WebSocket
> Protocol overview" and that would clearly imply non-normative behavior.
>  There are also several places in the document in sections that I believe
> are intended to provide normative behavior, but there is certainly
> non-normative text in those sections (e.g., section 5.2.2, second
> paragraph).  I would suggest this document follow the typical (and
> accepted) style of identifying normative behavior with 2119 language
> (consistently using upper case for normative behavior and avoiding using
> 2119 language in cases where alternative words can be substituted).
>
>
>
> 2) Section 5.2.2, 2nd paragraph.  Related to my point above, it's not
> clear to me this is normative behavior.  I don't think it is since it's
> referring to existing 4975 behavior. However, I didn't see that the
> reference given in 4975 relates to the second part of that sentence stati=
ng
> that implementations "should" already be allowing unrecognized transports=
.
>  It would be quite useful to have the exact reference here as I was tryin=
g
> to double check this point and I couldn't find it.
>
>
>
> 3) Section 6.  I'm really puzzled as to why the Connection Keep-alive
> would be non-normative.  In particular given that 2119 language is clearl=
y
> being used.
>
>
>
> 4) Section 7.  Again, I'm puzzled as to why Authentication is considered
> non-normative. AGain, you have 2119 language in this section.
>
>
>
> 5) Section 10.1. Since securing the connection is just RECOMMENDED, what
> are the implications and risks if the MSRP traffic isn't transported over=
 a
> secure connection?
>
>
>
> 6) Section 11.  You should change the name of the registry to be the exac=
t
> name of the IANA registry to avoid any confusion.- i.e.,:
>
> OLD:
>
>   registry of WebSocket sub-protocols
>
> NEW:
>
>   WebSocket Subprotocol Name Registry
>
>
>
> 7) Section 11. There is also a Reference field in that IANA registry. I
> would suggest you use the same information as the pointer to the
> Subprotocol Definition (i.e., this RFC).
>
>
>
> 8) It's typical for documents that are updating existing RFCs to have a
> section that summarizes the updates to the existing RFCs that are made by
> this document.
>
>
>
>
>
>
>
> On Thu, Dec 12, 2013 at 6:57 PM,  wrote:
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>
>         Title           : The WebSocket Protocol as a Transport for the
> Message Session Relay Protocol (MSRP)
>         Author(s)       : Peter Dunkley
>                           Gavin Llewellyn
>                           Victor Pascual
>                           Anton Roman
>                           Gonzalo Salgueiro
>         Filename        : draft-pd-dispatch-msrp-websocket-03.txt
>         Pages           : 21
>         Date            : 2013-12-12
>
> Abstract:
>    The WebSocket protocol enables two-way real-time communication
>    between clients and servers.  This document specifies a new WebSocket
>    sub-protocol as a reliable transport mechanism between MSRP (Message
>    Session Relay Protocol) clients and relays to enable usage of MSRP in
>    new scenarios.  This document normatively updates RFC 4975 and RFC
>    4976.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-pd-dispatch-msrp-websocket
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-pd-dispatch-msrp-websocket-03
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=3Ddraft-pd-dispatch-msrp-websocket-03
>
>
> 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.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draftdirectories:
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
>



--=20
Peter Dunkley
Technical Director
Crocodile RCS Ltd

--089e010d9d40bd187304f053175b
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable


Hello,

Perhaps the document title shoul=
d be corrected. MSRP-CEMA is outside of the scope of this document as this =
document is intended to describe connecting to a WebSocket server that is a=
n MSRP relay.



I can see no reason why MSRP-CEMA can't be used ove=
r WebSockets, but if anyone has an interest in this I think that they shoul=
d put it in a document of its own.



Regards,

Peter


On 18 January 2014 08:52, Christer Ho=
lmberg <christer.holmberg@ericsson.com> wrote:<=
br>












Hi,<=
/p>

=A0<=
/p>

I have not=
 followed the work on this draft, so I appologize if the following has been=
 discussed.



=A0=



While I do=
 understand that a WS Client has to establish the WebSocket with the Web Se=
rver, I don=92t understand why we need to mandate the WS Server
 to be an MSRP Relay. That would e.g. prevent the usage of MSRP-CEMA.


=A0=



Regards,


=A0=



Christer


=A0=



=A0=



=A0=



L=E4hett=E4j=E4: dispatch [mailto:dispatch-bounces@ietf.org]
Puolesta Mary Barnes

L=E4hetetty: 11. tammikuuta 2014 0:59

Vastaanottaja: DISPATCH

Kopio: Ben Campbell; draft-pd-dispatch-msrp-websocket@tool=
s.ietf.org

Aihe: Re: [dispatch] I-D Action: draft-pd-dispatch-msrp-websocket-03=
.txt


=A0




I have agreed to shepherd this document. =A0I've=
 reviewed the document in anticipation of doing the PROTO write-up and have=
 the following comments and questions. =A0Ben Campbell has agreed to do the=
 required expert review and that should be
 posted within the next week or so. =A0 =A0This is also a good time for any=
one in the WG that hasn't previously reviewed this document to review a=
nd provide any final comments. =A0Note, that this document was agreed to be=
 AD sponsored around the IETF-86 timeframe.





=A0






Regards,






Mary.=A0






=A0








Review Summary: Almost ready. Comments & questio=
ns below.






=A0






1) =A0Section 2 & General. =A0I'm not sure t=
he documented approach for separating normative text from non-normative is =
quite so helpful. =A0In general, we expect that in the case of standards tr=
ack document use RFC 2119 language to indicate normative
 behaviors. =A0I think the first sentence is good, but that's not a ter=
minology thing. =A0 I just don't see a lot of value in writing the docu=
ment this way. =A0For example, the definitions aren't stated to be non-=
normative, but I don't see anything normative about
 the definitions. =A0I think you could easily title Section 3 as "WebS=
ocket Protocol overview" and that would clearly imply non-normative be=
havior. =A0There are also several places in the document in sections that I=
 believe are intended to provide normative behavior,
 but there is certainly non-normative text in those sections (e.g., section=
 5.2.2, second paragraph). =A0I would suggest this document follow the typi=
cal (and accepted) style of identifying normative behavior with 2119 langua=
ge (consistently using upper case
 for normative behavior and avoiding using 2119 language in cases where alt=
ernative words can be substituted).






=A0






2) Section 5.2.2, 2nd paragraph. =A0Related to my po=
int above, it's not clear to me this is normative behavior. =A0I don=
9;t think it is since it's referring to existing 4975 behavior. However=
, I didn't see that the reference given in 4975 relates
 to the second part of that sentence stating that implementations "sho=
uld" already be allowing unrecognized transports. =A0It would be quite=
 useful to have the exact reference here as I was trying to double check th=
is point and I couldn't find it.=A0







=A0






3) Section 6. =A0I'm really puzzled as to why th=
e Connection Keep-alive would be non-normative. =A0In particular given that=
 2119 language is clearly being used. =A0






=A0






4) Section 7. =A0Again, I'm puzzled as to why Au=
thentication is considered non-normative. AGain, you have 2119 language in =
this section. =A0






=A0






5) Section 10.1. Since securing the connection is ju=
st RECOMMENDED, what are the implications and risks if the MSRP traffic isn=
't transported over a secure connection?=A0






=A0






6) Section 11. =A0You should change the name of the =
registry to be the exact name of the IANA registry to avoid any confusion.-=
 i.e.,:






OLD:






=A0 registry of WebSocket sub-protocols






NEW:=A0






=A0 WebSocket Subprotocol Name Registry =A0






=A0






7) Section 11. There is also a Reference field in th=
at IANA registry. I would suggest you use the same information as the point=
er to the Subprotocol Definition (i.e., this RFC).=A0






=A0






8) It's typical for documents that are updating =
existing RFCs to have a section that summarizes the updates to the existing=
 RFCs that are made by this document. =A0






=A0






=A0








=A0




On Thu, Dec 12, 2013 at 6:57 PM, <internet-drafts@ietf.org=
> wrote:




A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.





=A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : The WebSocket Protocol as a Tra=
nsport for the Message Session Relay Protocol (MSRP)

=A0 =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Peter Dunkley

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Gavin Llewellyn

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Victor Pascual

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Anton Roman

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Gonzalo Salgueiro

=A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-pd-dispatch-msrp-websocket-=
03.txt

=A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 21

=A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2013-12-12



Abstract:

=A0 =A0The WebSocket protocol enables two-way real-time communication

=A0 =A0between clients and servers. =A0This document specifies a new WebSoc=
ket

=A0 =A0sub-protocol as a reliable transport mechanism between MSRP (Message=


=A0 =A0Session Relay Protocol) clients and relays to enable usage of MSRP i=
n

=A0 =A0new scenarios. =A0This document normatively updates RFC 4975 and RFC=


=A0 =A04976.





The IETF datatracker status page for this draft is:

https://datatracker.ietf.org/doc/draft-pd-dispatch-msr=
p-websocket



There's also a htmlized version available at:

http://tools.ietf.org/html/draft-pd-dispatch-msrp-websock=
et-03



A diff from the previous version is available at:

http://www.ietf.org/rfcdiff?url2=3Ddraft-pd-dispa=
tch-msrp-websocket-03





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.



Internet-Drafts are also available by anonymous FTP at:

ftp://ftp=
.ietf.org/internet-drafts/



_______________________________________________

I-D-Announce mailing list

I-D-Announce@iet=
f.org

https://www.ietf.org/mailman/listinfo/i-d-announce

Internet-Draft directories: 
http://www.ietf.org/shadow.html

or =
ftp://ftp.ietf.org/ietf/1shadow-sites.txt




=A0














-- 
Peter Dunkley
<=
div>Technical Director

Crocodile RCS Ltd



--089e010d9d40bd187304f053175b--

From christer.holmberg@ericsson.com  Sun Jan 19 19:28:59 2014
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 744281A0023 for ; Sun, 19 Jan 2014 19:28:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.15
X-Spam-Level: 
X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 EhpvAQVyK3fO for ; Sun, 19 Jan 2014 19:28:56 -0800 (PST)
Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id D83361A001F for ; Sun, 19 Jan 2014 19:28:55 -0800 (PST)
X-AuditID: c1b4fb30-b7f228e000003e6c-48-52dc97f43fbc
Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 83.AD.15980.4F79CD25; Mon, 20 Jan 2014 04:28:52 +0100 (CET)
Received: from ESESSMB209.ericsson.se ([169.254.9.114]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.02.0387.000; Mon, 20 Jan 2014 04:28:51 +0100
From: Christer Holmberg 
To: Peter Dunkley 
Thread-Topic: [dispatch] I-D Action: draft-pd-dispatch-msrp-websocket-03.txt
Thread-Index: AQHPDleQGzr1Sxm0FkKTa2Dy1OUwAJqKNznggAHW2ICAAPS5Pw==
Date: Mon, 20 Jan 2014 03:28:50 +0000
Message-ID: 
References: <20131213005747.777.34301.idtracker@ietfa.amsl.com>  <7594FB04B1934943A5C02806D1A2204B1D104D91@ESESSMB209.ericsson.se>, 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: multipart/alternative; boundary="_000_t8ggf2ti82dib0706kka9dx11390188532252emailandroidcom_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrKLMWRmVeSWpSXmKPExsUyM+Jvje6X6XeCDI7t07RofviLzWLppAWs Fpe3fGa3+Lx/P7PF+e3bmBxYPR71hHo8/jqL1WPnrLvsHkuW/GTy+HL5M1sAaxSXTUpqTmZZ apG+XQJXxs3eJWwF91cwVjRfVWpgXNTP2MXIwSEhYCJx5KJPFyMnkCkmceHeejYQW0jgEKPE yj/cXYxcQPYSRomd33vYQOrZBCwkuv9pg9SICBhJrFiwkhWkhlngGqPEp+vzmUASwgLeEmev /WSDKPKRuLn9ABOE7SRxuPkjK4jNIqAq8ejPaWYQm1fATeL+b5B7QBb3M0mceKEJYnMKBEpM PXoVrIYR6Ljvp9aAzWEWEJe49QRil4SAgMSSPeeZIWxRiZeP/7FC1ORIfF87mQ1ivqDEyZlP WCYwisxC0j4LSdksJGUQcQOJ9+fmM0PY2hLLFr6GsvUlNn45y4gsvoCRfRUje25iZk56ufkm RmDUHdzy22AH46b7YocYpTlYlMR5P7x1DhISSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXAGNtU zuf79VGzruvzhRHlPkvu7C5TPy/w+O/8BOEN7pyxs09N0Dxu8vsyi+D/pdv5esRLU5beZtf7 dMzv1X2WWQW6m0NTr2yoPCDQl5D66OGd/3u/zVDYMt9rtqkNi4bS1guRKzdPPDlFvz7oWQv/ i89rKp6LRes3vXy7LKZI3O18ZXpJQEuSrBJLcUaioRZzUXEiAKv2hySIAgAA
Cc: DISPATCH , Ben Campbell , "draft-pd-dispatch-msrp-websocket@tools.ietf.org" 
Subject: Re: [dispatch] I-D Action: draft-pd-dispatch-msrp-websocket-03.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: Mon, 20 Jan 2014 03:28:59 -0000

--_000_t8ggf2ti82dib0706kka9dx11390188532252emailandroidcom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Hi,

I see no reason why it should be a separate document, as it should not have=
 any affect on the websocket specific procedures, which is the main scope o=
f the document.

Regards,

Christer

Sent from my Sony Ericsson Xperia arc S

Peter Dunkley  wrote:



Hello,

Perhaps the document title should be corrected. MSRP-CEMA is outside of the=
 scope of this document as this document is intended to describe connecting=
 to a WebSocket server that is an MSRP relay.

I can see no reason why MSRP-CEMA can't be used over WebSockets, but if any=
one has an interest in this I think that they should put it in a document o=
f its own.


Regards,

Peter


On 18 January 2014 08:52, Christer Holmberg > wrote:
Hi,

I have not followed the work on this draft, so I appologize if the followin=
g has been discussed.

While I do understand that a WS Client has to establish the WebSocket with =
the Web Server, I don=92t understand why we need to mandate the WS Server t=
o be an MSRP Relay. That would e.g. prevent the usage of MSRP-CEMA.

Regards,

Christer



L=E4hett=E4j=E4: dispatch [mailto:dispatch-bounces@ietf.org] Puolesta Mary Barnes
L=E4hetetty: 11. tammikuuta 2014 0:59
Vastaanottaja: DISPATCH
Kopio: Ben Campbell; draft-pd-dispatch-msrp-websocket@tools.ietf.org
Aihe: Re: [dispatch] I-D Action: draft-pd-dispatch-msrp-websocket-03.txt

I have agreed to shepherd this document.  I've reviewed the document in ant=
icipation of doing the PROTO write-up and have the following comments and q=
uestions.  Ben Campbell has agreed to do the required expert review and tha=
t should be posted within the next week or so.    This is also a good time =
for anyone in the WG that hasn't previously reviewed this document to revie=
w and provide any final comments.  Note, that this document was agreed to b=
e AD sponsored around the IETF-86 timeframe.

Regards,
Mary.

Review Summary: Almost ready. Comments & questions below.

1)  Section 2 & General.  I'm not sure the documented approach for separati=
ng normative text from non-normative is quite so helpful.  In general, we e=
xpect that in the case of standards track document use RFC 2119 language to=
 indicate normative behaviors.  I think the first sentence is good, but tha=
t's not a terminology thing.   I just don't see a lot of value in writing t=
he document this way.  For example, the definitions aren't stated to be non=
-normative, but I don't see anything normative about the definitions.  I th=
ink you could easily title Section 3 as "WebSocket Protocol overview" and t=
hat would clearly imply non-normative behavior.  There are also several pla=
ces in the document in sections that I believe are intended to provide norm=
ative behavior, but there is certainly non-normative text in those sections=
 (e.g., section 5.2.2, second paragraph).  I would suggest this document fo=
llow the typical (and accepted) style of identifying normative behavior wit=
h 2119 language (consistently using upper case for normative behavior and a=
voiding using 2119 language in cases where alternative words can be substit=
uted).

2) Section 5.2.2, 2nd paragraph.  Related to my point above, it's not clear=
 to me this is normative behavior.  I don't think it is since it's referrin=
g to existing 4975 behavior. However, I didn't see that the reference given=
 in 4975 relates to the second part of that sentence stating that implement=
ations "should" already be allowing unrecognized transports.  It would be q=
uite useful to have the exact reference here as I was trying to double chec=
k this point and I couldn't find it.

3) Section 6.  I'm really puzzled as to why the Connection Keep-alive would=
 be non-normative.  In particular given that 2119 language is clearly being=
 used.

4) Section 7.  Again, I'm puzzled as to why Authentication is considered no=
n-normative. AGain, you have 2119 language in this section.

5) Section 10.1. Since securing the connection is just RECOMMENDED, what ar=
e the implications and risks if the MSRP traffic isn't transported over a s=
ecure connection?

6) Section 11.  You should change the name of the registry to be the exact =
name of the IANA registry to avoid any confusion.- i.e.,:
OLD:
  registry of WebSocket sub-protocols
NEW:
  WebSocket Subprotocol Name Registry

7) Section 11. There is also a Reference field in that IANA registry. I wou=
ld suggest you use the same information as the pointer to the Subprotocol D=
efinition (i.e., this RFC).

8) It's typical for documents that are updating existing RFCs to have a sec=
tion that summarizes the updates to the existing RFCs that are made by this=
 document.



On Thu, Dec 12, 2013 at 6:57 PM, > wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.


        Title           : The WebSocket Protocol as a Transport for the Mes=
sage Session Relay Protocol (MSRP)
        Author(s)       : Peter Dunkley
                          Gavin Llewellyn
                          Victor Pascual
                          Anton Roman
                          Gonzalo Salgueiro
        Filename        : draft-pd-dispatch-msrp-websocket-03.txt
        Pages           : 21
        Date            : 2013-12-12

Abstract:
   The WebSocket protocol enables two-way real-time communication
   between clients and servers.  This document specifies a new WebSocket
   sub-protocol as a reliable transport mechanism between MSRP (Message
   Session Relay Protocol) clients and relays to enable usage of MSRP in
   new scenarios.  This document normatively updates RFC 4975 and RFC
   4976.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-pd-dispatch-msrp-websocket

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-pd-dispatch-msrp-websocket-03

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-pd-dispatch-msrp-websocket-03


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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt




--
Peter Dunkley
Technical Director
Crocodile RCS Ltd

--_000_t8ggf2ti82dib0706kka9dx11390188532252emailandroidcom_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable







Hi,=0A=
=0A=
I see no reason why it should be a separate document, as it should not have=
 any affect on the websocket specific procedures, which is the main scope o=
f the document.=0A=
=0A=
Regards,=0A=
=0A=
Christer=0A=
=0A=
Sent from my Sony Ericsson Xperia arc S=0A=
=0A=
Peter Dunkley <peter.dunkley@crocodilertc.net> wrote:=0A=
=0A=





Hello,






Perhaps the document title should be corrected. MSRP-CEMA is outside o=
f the scope of this document as this document is intended to describe conne=
cting to a WebSocket server that is an MSRP relay.







I can see no reason why MSRP-CEMA can't be used over WebSockets, but i=
f anyone has an interest in this I think that they should put it in a docum=
ent of its own.












Regards,







Peter









On 18 January 2014 08:52, Christer Holmberg 
<chr=
ister.holmberg@ericsson.com> wrote:








Hi,


 


I have n=
ot followed the work on this draft, so I appologize if the following has be=
en discussed.


&=
nbsp;


While I =
do understand that a WS Client has to establish the WebSocket with the Web =
Server, I don=92t understand why we need to mandate the WS Server
 to be an MSRP Relay. That would e.g. prevent the usage of MSRP-CEMA.


&=
nbsp;


Regards,=



&=
nbsp;


Christer=



&=
nbsp;


&=
nbsp;


&=
nbsp;


L=E4hett=E4j=E4: dispatch [mailto:dispatch-bounces@ietf.org]
Puolesta Mary Barnes

L=E4hetetty: 11. tammikuuta 2014 0:59

Vastaanottaja: DISPATCH

Kopio: Ben Campbell; 
draft-pd-dispatch-msrp-websocket@tools.ietf.org

Aihe: Re: [dispatch] I-D Action: draft-pd-dispatch-msrp-websocket-03=
.txt






 




I have agreed to shepherd this document.  I've =
reviewed the document in anticipation of doing the PROTO write-up and have =
the following comments and questions.  Ben Campbell has agreed to do t=
he required expert review and that should be
 posted within the next week or so.    This is also a good time f=
or anyone in the WG that hasn't previously reviewed this document to review=
 and provide any final comments.  Note, that this document was agreed =
to be AD sponsored around the IETF-86 timeframe.




 






Regards,






Mary. 






 








Review Summary: Almost ready. Comments & questio=
ns below.






 






1)  Section 2 & General.  I'm not sure=
 the documented approach for separating normative text from non-normative i=
s quite so helpful.  In general, we expect that in the case of standar=
ds track document use RFC 2119 language to indicate normative
 behaviors.  I think the first sentence is good, but that's not a term=
inology thing.   I just don't see a lot of value in writing the docume=
nt this way.  For example, the definitions aren't stated to be non-nor=
mative, but I don't see anything normative about
 the definitions.  I think you could easily title Section 3 as "W=
ebSocket Protocol overview" and that would clearly imply non-normative=
 behavior.  There are also several places in the document in sections =
that I believe are intended to provide normative behavior,
 but there is certainly non-normative text in those sections (e.g., section=
 5.2.2, second paragraph).  I would suggest this document follow the t=
ypical (and accepted) style of identifying normative behavior with 2119 lan=
guage (consistently using upper case
 for normative behavior and avoiding using 2119 language in cases where alt=
ernative words can be substituted).






 






2) Section 5.2.2, 2nd paragraph.  Related to my=
 point above, it's not clear to me this is normative behavior.  I don'=
t think it is since it's referring to existing 4975 behavior. However, I di=
dn't see that the reference given in 4975 relates
 to the second part of that sentence stating that implementations "sho=
uld" already be allowing unrecognized transports.  It would be qu=
ite useful to have the exact reference here as I was trying to double check=
 this point and I couldn't find it. 






 






3) Section 6.  I'm really puzzled as to why the=
 Connection Keep-alive would be non-normative.  In particular given th=
at 2119 language is clearly being used.  






 






4) Section 7.  Again, I'm puzzled as to why Aut=
hentication is considered non-normative. AGain, you have 2119 language in t=
his section.  






 






5) Section 10.1. Since securing the connection is ju=
st RECOMMENDED, what are the implications and risks if the MSRP traffic isn=
't transported over a secure connection? 






 






6) Section 11.  You should change the name of t=
he registry to be the exact name of the IANA registry to avoid any confusio=
n.- i.e.,:






OLD:






  registry of WebSocket sub-protocols=







NEW: 






  WebSocket Subprotocol Name Registry  =







 






7) Section 11. There is also a Reference field in th=
at IANA registry. I would suggest you use the same information as the point=
er to the Subprotocol Definition (i.e., this RFC). 






 






8) It's typical for documents that are updating exis=
ting RFCs to have a section that summarizes the updates to the existing RFC=
s that are made by this document.  






 






 








 




On Thu, Dec 12, 2013 at 6:57 PM, <internet-drafts@ietf.org=
> wrote:




A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.





        Title           : The =
WebSocket Protocol as a Transport for the Message Session Relay Protocol (M=
SRP)

        Author(s)       : Peter Dunkley<=
br>
                     =
;     Gavin Llewellyn

                     =
;     Victor Pascual

                     =
;     Anton Roman

                     =
;     Gonzalo Salgueiro

        Filename        : draft-pd-=
dispatch-msrp-websocket-03.txt

        Pages           : 21
        Date            :=
 2013-12-12



Abstract:

   The WebSocket protocol enables two-way real-time communication=


   between clients and servers.  This document specifies a n=
ew WebSocket

   sub-protocol as a reliable transport mechanism between MSRP (M=
essage

   Session Relay Protocol) clients and relays to enable usage of =
MSRP in

   new scenarios.  This document normatively updates RFC 497=
5 and RFC

   4976.





The IETF datatracker status page for this draft is:

https://datatracker.ietf.org/doc/draft-pd-dispatch-msr=
p-websocket



There's also a htmlized version available at:

http://tools.ietf.org/html/draft-pd-dispatch-msrp-websock=
et-03



A diff from the previous version is available at:

http://www.ietf.org/rfcdiff?url2=3Ddraft-pd-dispa=
tch-msrp-websocket-03





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.



Internet-Drafts are also available by anonymous FTP at:

ftp://ftp=
.ietf.org/internet-drafts/



_______________________________________________

I-D-Announce mailing list

I-D-Announce@iet=
f.org

https://www.ietf.org/mailman/listinfo/i-d-announce

Internet-Draft directories: 
http://www.ietf.org/shadow.html

or =
ftp://ftp.ietf.org/ietf/1shadow-sites.txt




 


























-- 




Peter Dunkley


Technical Director


Crocodile RCS Ltd










--_000_t8ggf2ti82dib0706kka9dx11390188532252emailandroidcom_--

From ben@nostrum.com  Sun Jan 19 20:32:39 2014
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 09A6D1A0043 for ; Sun, 19 Jan 2014 20:32:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.036
X-Spam-Level: 
X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] 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 WzCIOJPb0-lB for ; Sun, 19 Jan 2014 20:32:36 -0800 (PST)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 672BF1A0032 for ; Sun, 19 Jan 2014 20:32:36 -0800 (PST)
Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id s0K4WMoV014055 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 19 Jan 2014 22:32:23 -0600 (CST) (envelope-from ben@nostrum.com)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Ben Campbell 
In-Reply-To: 
Date: Sun, 19 Jan 2014 22:32:21 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20131213005747.777.34301.idtracker@ietfa.amsl.com>  <7594FB04B1934943A5C02806D1A2204B1D104D91@ESESSMB209.ericsson.se>,  
To: Christer Holmberg 
X-Mailer: Apple Mail (2.1827)
Received-SPF: pass (shaman.nostrum.com: 173.172.146.58 is authenticated by a trusted mechanism)
Cc: DISPATCH , "draft-pd-dispatch-msrp-websocket@tools.ietf.org" 
Subject: Re: [dispatch] I-D Action: draft-pd-dispatch-msrp-websocket-03.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: Mon, 20 Jan 2014 04:32:39 -0000

On Jan 19, 2014, at 9:28 PM, Christer Holmberg =
 wrote:

> Hi,
>=20
> I see no reason why it should be a separate document, as it should not =
have any affect on the websocket specific procedures, which is the main =
scope of the document.

Christer, I assume you mean for a WebSocket MSRP "server" acting on =
behalf of a WS MSRP client to be able to use CEMA between itself and a =
third party client? Not between a WebSocket MSRP client and a WebSocket =
MSRP server, right?

>=20
> Regards,
>=20
> Christer
>=20
> Sent from my Sony Ericsson Xperia arc S
>=20
> Peter Dunkley  wrote:
>=20
>=20
> Hello,
>=20
> Perhaps the document title should be corrected. MSRP-CEMA is outside =
of the scope of this document as this document is intended to describe =
connecting to a WebSocket server that is an MSRP relay.
>=20
> I can see no reason why MSRP-CEMA can't be used over WebSockets, but =
if anyone has an interest in this I think that they should put it in a =
document of its own.
>=20
>=20
> Regards,
>=20
> Peter
>=20
>=20
> On 18 January 2014 08:52, Christer Holmberg =
 wrote:
> Hi,
>=20
>=20
>=20
> I have not followed the work on this draft, so I appologize if the =
following has been discussed.
>=20
>=20
>=20
> While I do understand that a WS Client has to establish the WebSocket =
with the Web Server, I don=92t understand why we need to mandate the WS =
Server to be an MSRP Relay. That would e.g. prevent the usage of =
MSRP-CEMA.
>=20
>=20
>=20
> Regards,
>=20
>=20
>=20
> Christer
>=20
>=20
>=20
>=20
>=20
>=20
>=20
> L=E4hett=E4j=E4: dispatch [mailto:dispatch-bounces@ietf.org] Puolesta =
Mary Barnes
> L=E4hetetty: 11. tammikuuta 2014 0:59
> Vastaanottaja: DISPATCH
> Kopio: Ben Campbell; draft-pd-dispatch-msrp-websocket@tools.ietf.org
> Aihe: Re: [dispatch] I-D Action: =
draft-pd-dispatch-msrp-websocket-03.txt
>=20
>=20
>=20
> I have agreed to shepherd this document.  I've reviewed the document =
in anticipation of doing the PROTO write-up and have the following =
comments and questions.  Ben Campbell has agreed to do the required =
expert review and that should be posted within the next week or so.    =
This is also a good time for anyone in the WG that hasn't previously =
reviewed this document to review and provide any final comments.  Note, =
that this document was agreed to be AD sponsored around the IETF-86 =
timeframe.
>=20
>=20
>=20
> Regards,
>=20
> Mary.=20
>=20
>=20
>=20
> Review Summary: Almost ready. Comments & questions below.
>=20
>=20
>=20
> 1)  Section 2 & General.  I'm not sure the documented approach for =
separating normative text from non-normative is quite so helpful.  In =
general, we expect that in the case of standards track document use RFC =
2119 language to indicate normative behaviors.  I think the first =
sentence is good, but that's not a terminology thing.   I just don't see =
a lot of value in writing the document this way.  For example, the =
definitions aren't stated to be non-normative, but I don't see anything =
normative about the definitions.  I think you could easily title Section =
3 as "WebSocket Protocol overview" and that would clearly imply =
non-normative behavior.  There are also several places in the document =
in sections that I believe are intended to provide normative behavior, =
but there is certainly non-normative text in those sections (e.g., =
section 5.2.2, second paragraph).  I would suggest this document follow =
the typical (and accepted) style of identifying normative behavior with =
2119 language (consistently using upper case for normative behavior and =
avoiding using 2119 language in cases where alternative words can be =
substituted).
>=20
>=20
>=20
> 2) Section 5.2.2, 2nd paragraph.  Related to my point above, it's not =
clear to me this is normative behavior.  I don't think it is since it's =
referring to existing 4975 behavior. However, I didn't see that the =
reference given in 4975 relates to the second part of that sentence =
stating that implementations "should" already be allowing unrecognized =
transports.  It would be quite useful to have the exact reference here =
as I was trying to double check this point and I couldn't find it.=20
>=20
>=20
>=20
> 3) Section 6.  I'm really puzzled as to why the Connection Keep-alive =
would be non-normative.  In particular given that 2119 language is =
clearly being used. =20
>=20
>=20
>=20
> 4) Section 7.  Again, I'm puzzled as to why Authentication is =
considered non-normative. AGain, you have 2119 language in this section. =
=20
>=20
>=20
>=20
> 5) Section 10.1. Since securing the connection is just RECOMMENDED, =
what are the implications and risks if the MSRP traffic isn't =
transported over a secure connection?=20
>=20
>=20
>=20
> 6) Section 11.  You should change the name of the registry to be the =
exact name of the IANA registry to avoid any confusion.- i.e.,:
>=20
> OLD:
>=20
>  registry of WebSocket sub-protocols
>=20
> NEW:=20
>=20
>  WebSocket Subprotocol Name Registry =20
>=20
>=20
>=20
> 7) Section 11. There is also a Reference field in that IANA registry. =
I would suggest you use the same information as the pointer to the =
Subprotocol Definition (i.e., this RFC).=20
>=20
>=20
>=20
> 8) It's typical for documents that are updating existing RFCs to have =
a section that summarizes the updates to the existing RFCs that are made =
by this document. =20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
> On Thu, Dec 12, 2013 at 6:57 PM,  wrote:
>=20
>=20
> A New Internet-Draft is available from the on-line Internet-Drafts =
directories.
>=20
>=20
>        Title           : The WebSocket Protocol as a Transport for the =
Message Session Relay Protocol (MSRP)
>        Author(s)       : Peter Dunkley
>                          Gavin Llewellyn
>                          Victor Pascual
>                          Anton Roman
>                          Gonzalo Salgueiro
>        Filename        : draft-pd-dispatch-msrp-websocket-03.txt
>        Pages           : 21
>        Date            : 2013-12-12
>=20
> Abstract:
>   The WebSocket protocol enables two-way real-time communication
>   between clients and servers.  This document specifies a new =
WebSocket
>   sub-protocol as a reliable transport mechanism between MSRP (Message
>   Session Relay Protocol) clients and relays to enable usage of MSRP =
in
>   new scenarios.  This document normatively updates RFC 4975 and RFC
>   4976.
>=20
>=20
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-pd-dispatch-msrp-websocket
>=20
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-pd-dispatch-msrp-websocket-03
>=20
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=3Ddraft-pd-dispatch-msrp-websocket-03
>=20
>=20
> 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.
>=20
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>=20
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>=20
>=20
>=20
>=20
>=20
>=20
> --=20
> Peter Dunkley
> Technical Director
> Crocodile RCS Ltd


From christer.holmberg@ericsson.com  Sun Jan 19 22:13:06 2014
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 945851A0052 for ; Sun, 19 Jan 2014 22:13:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.869
X-Spam-Level: 
X-Spam-Status: No, score=-2.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 bkoPmGCPyp7k for ; Sun, 19 Jan 2014 22:13:03 -0800 (PST)
Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 8B72A1A004B for ; Sun, 19 Jan 2014 22:13:02 -0800 (PST)
X-AuditID: c1b4fb30-b7f228e000003e6c-78-52dcbe6a7d53
Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id DB.19.15980.A6EBCD25; Mon, 20 Jan 2014 07:13:01 +0100 (CET)
Received: from ESESSMB209.ericsson.se ([169.254.9.114]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.02.0387.000; Mon, 20 Jan 2014 07:12:58 +0100
From: Christer Holmberg 
To: Ben Campbell 
Thread-Topic: [dispatch] I-D Action: draft-pd-dispatch-msrp-websocket-03.txt
Thread-Index: AQHPDleQGzr1Sxm0FkKTa2Dy1OUwAJqKNznggAHW2ICAAPS5P4AAAPqAgAAs4UI=
Date: Mon, 20 Jan 2014 06:12:58 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1D108321@ESESSMB209.ericsson.se>
References: <20131213005747.777.34301.idtracker@ietfa.amsl.com>  <7594FB04B1934943A5C02806D1A2204B1D104D91@ESESSMB209.ericsson.se>,  , 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D108321ESESSMB209erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBLMWRmVeSWpSXmKPExsUyM+JvjW7uvjtBBnsWGVjM7zzNbrF00gJW i8tbPrNbfN6/n9ni/PZtTA6sHo96Qj12zrrL7rFkyU8mj1k7n7B4fLn8mS2ANYrLJiU1J7Ms tUjfLoEr49flZqaCX3cZK87Pu8DYwNhzg7GLkZNDQsBEYuWH/+wQtpjEhXvr2boYuTiEBA4x Suy6OhvKWcIocXPXe+YuRg4ONgELie5/2iANIgJKEs+bt7KA1DALPGWUuP9hA9hUYQFvibPX frJBFPlI3Nx+gAnC9pNo3f4XzGYRUJVonXgYzOYV8JU49/8CO8Sy/0wSj3ums4AkOAXsJTZM uQNmMwKd9/3UGrAGZgFxiVtP5jNBnC0gsWTPeWYIW1Ti5eN/rBA1+RInHs9nh1ggKHFy5hOW CYwis5C0z0JSNgtJ2SygP5kFNCXW79KHKFGUmNL9kB3C1pBonTOXHVl8ASP7Kkb23MTMnPRy 802MwNg7uOW3wQ7GTffFDjFKc7AoifN+eOscJCSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoHR 0eKeSnawTHr8maduRy9+PVJ2MVhkxcHjDyJ7gwpC9ZN/LvPV7NRbz6NutaTr1NxFhoGzL26c Ham+uujb34VdjqGu/6aof51q163Q9HqC+nL/mff2XL5tNXF/7OHHouuSF+U8++437Wjo+3c5 3BFZwnkfX9jv3My83EKgU6NZLGhvu+i8ixEBSizFGYmGWsxFxYkAgx52t4sCAAA=
Cc: DISPATCH , "draft-pd-dispatch-msrp-websocket@tools.ietf.org" 
Subject: Re: [dispatch] I-D Action: draft-pd-dispatch-msrp-websocket-03.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: Mon, 20 Jan 2014 06:13:06 -0000

--_000_7594FB04B1934943A5C02806D1A2204B1D108321ESESSMB209erics_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGkgQmVuLA0KDQpNeSB0aGlua2luZyBpcyB0aGF0IHRoZSBXUyBjbGllbnQgY291bGQgaW5kaWNh
dGUgc3VwcG9ydCBvZiBDRU1BLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoNClNlbnQgZnJv
bSBXaW5kb3dzIE1haWwNCg0KRnJvbTogQmVuIENhbXBiZWxsPG1haWx0bzpiZW5Abm9zdHJ1bS5j
b20+DQpTZW50OiDigI5Nb25kYXnigI4sIOKAjkphbnVhcnnigI4g4oCOMjDigI4sIOKAjjIwMTQg
4oCONuKAjjrigI4zMuKAjiDigI5BTQ0KVG86IENocmlzdGVyIEhvbG1iZXJnPG1haWx0bzpjaHJp
c3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+DQpDYzogUGV0ZXIgRHVua2xleTxtYWlsdG86cGV0
ZXIuZHVua2xleUBjcm9jb2RpbGVydGMubmV0PiwgTWFyeSBCYXJuZXM8bWFpbHRvOm1hcnkuaWV0
Zi5iYXJuZXNAZ21haWwuY29tPiwgRElTUEFUQ0g8bWFpbHRvOmRpc3BhdGNoQGlldGYub3JnPiwg
ZHJhZnQtcGQtZGlzcGF0Y2gtbXNycC13ZWJzb2NrZXRAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOmRy
YWZ0LXBkLWRpc3BhdGNoLW1zcnAtd2Vic29ja2V0QHRvb2xzLmlldGYub3JnPg0KDQoNCk9uIEph
biAxOSwgMjAxNCwgYXQgOToyOCBQTSwgQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1i
ZXJnQGVyaWNzc29uLmNvbT4gd3JvdGU6DQoNCj4gSGksDQo+DQo+IEkgc2VlIG5vIHJlYXNvbiB3
aHkgaXQgc2hvdWxkIGJlIGEgc2VwYXJhdGUgZG9jdW1lbnQsIGFzIGl0IHNob3VsZCBub3QgaGF2
ZSBhbnkgYWZmZWN0IG9uIHRoZSB3ZWJzb2NrZXQgc3BlY2lmaWMgcHJvY2VkdXJlcywgd2hpY2gg
aXMgdGhlIG1haW4gc2NvcGUgb2YgdGhlIGRvY3VtZW50Lg0KDQpDaHJpc3RlciwgSSBhc3N1bWUg
eW91IG1lYW4gZm9yIGEgV2ViU29ja2V0IE1TUlAgInNlcnZlciIgYWN0aW5nIG9uIGJlaGFsZiBv
ZiBhIFdTIE1TUlAgY2xpZW50IHRvIGJlIGFibGUgdG8gdXNlIENFTUEgYmV0d2VlbiBpdHNlbGYg
YW5kIGEgdGhpcmQgcGFydHkgY2xpZW50PyBOb3QgYmV0d2VlbiBhIFdlYlNvY2tldCBNU1JQIGNs
aWVudCBhbmQgYSBXZWJTb2NrZXQgTVNSUCBzZXJ2ZXIsIHJpZ2h0Pw0KDQo+DQo+IFJlZ2FyZHMs
DQo+DQo+IENocmlzdGVyDQo+DQo+IFNlbnQgZnJvbSBteSBTb255IEVyaWNzc29uIFhwZXJpYSBh
cmMgUw0KPg0KPiBQZXRlciBEdW5rbGV5IDxwZXRlci5kdW5rbGV5QGNyb2NvZGlsZXJ0Yy5uZXQ+
IHdyb3RlOg0KPg0KPg0KPiBIZWxsbywNCj4NCj4gUGVyaGFwcyB0aGUgZG9jdW1lbnQgdGl0bGUg
c2hvdWxkIGJlIGNvcnJlY3RlZC4gTVNSUC1DRU1BIGlzIG91dHNpZGUgb2YgdGhlIHNjb3BlIG9m
IHRoaXMgZG9jdW1lbnQgYXMgdGhpcyBkb2N1bWVudCBpcyBpbnRlbmRlZCB0byBkZXNjcmliZSBj
b25uZWN0aW5nIHRvIGEgV2ViU29ja2V0IHNlcnZlciB0aGF0IGlzIGFuIE1TUlAgcmVsYXkuDQo+
DQo+IEkgY2FuIHNlZSBubyByZWFzb24gd2h5IE1TUlAtQ0VNQSBjYW4ndCBiZSB1c2VkIG92ZXIg
V2ViU29ja2V0cywgYnV0IGlmIGFueW9uZSBoYXMgYW4gaW50ZXJlc3QgaW4gdGhpcyBJIHRoaW5r
IHRoYXQgdGhleSBzaG91bGQgcHV0IGl0IGluIGEgZG9jdW1lbnQgb2YgaXRzIG93bi4NCj4NCj4N
Cj4gUmVnYXJkcywNCj4NCj4gUGV0ZXINCj4NCj4NCj4gT24gMTggSmFudWFyeSAyMDE0IDA4OjUy
LCBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPiB3cm90
ZToNCj4gSGksDQo+DQo+DQo+DQo+IEkgaGF2ZSBub3QgZm9sbG93ZWQgdGhlIHdvcmsgb24gdGhp
cyBkcmFmdCwgc28gSSBhcHBvbG9naXplIGlmIHRoZSBmb2xsb3dpbmcgaGFzIGJlZW4gZGlzY3Vz
c2VkLg0KPg0KPg0KPg0KPiBXaGlsZSBJIGRvIHVuZGVyc3RhbmQgdGhhdCBhIFdTIENsaWVudCBo
YXMgdG8gZXN0YWJsaXNoIHRoZSBXZWJTb2NrZXQgd2l0aCB0aGUgV2ViIFNlcnZlciwgSSBkb27i
gJl0IHVuZGVyc3RhbmQgd2h5IHdlIG5lZWQgdG8gbWFuZGF0ZSB0aGUgV1MgU2VydmVyIHRvIGJl
IGFuIE1TUlAgUmVsYXkuIFRoYXQgd291bGQgZS5nLiBwcmV2ZW50IHRoZSB1c2FnZSBvZiBNU1JQ
LUNFTUEuDQo+DQo+DQo+DQo+IFJlZ2FyZHMsDQo+DQo+DQo+DQo+IENocmlzdGVyDQo+DQo+DQo+
DQo+DQo+DQo+DQo+DQo+IEzDpGhldHTDpGrDpDogZGlzcGF0Y2ggW21haWx0bzpkaXNwYXRjaC1i
b3VuY2VzQGlldGYub3JnXSBQdW9sZXN0YSBNYXJ5IEJhcm5lcw0KPiBMw6RoZXRldHR5OiAxMS4g
dGFtbWlrdXV0YSAyMDE0IDA6NTkNCj4gVmFzdGFhbm90dGFqYTogRElTUEFUQ0gNCj4gS29waW86
IEJlbiBDYW1wYmVsbDsgZHJhZnQtcGQtZGlzcGF0Y2gtbXNycC13ZWJzb2NrZXRAdG9vbHMuaWV0
Zi5vcmcNCj4gQWloZTogUmU6IFtkaXNwYXRjaF0gSS1EIEFjdGlvbjogZHJhZnQtcGQtZGlzcGF0
Y2gtbXNycC13ZWJzb2NrZXQtMDMudHh0DQo+DQo+DQo+DQo+IEkgaGF2ZSBhZ3JlZWQgdG8gc2hl
cGhlcmQgdGhpcyBkb2N1bWVudC4gIEkndmUgcmV2aWV3ZWQgdGhlIGRvY3VtZW50IGluIGFudGlj
aXBhdGlvbiBvZiBkb2luZyB0aGUgUFJPVE8gd3JpdGUtdXAgYW5kIGhhdmUgdGhlIGZvbGxvd2lu
ZyBjb21tZW50cyBhbmQgcXVlc3Rpb25zLiAgQmVuIENhbXBiZWxsIGhhcyBhZ3JlZWQgdG8gZG8g
dGhlIHJlcXVpcmVkIGV4cGVydCByZXZpZXcgYW5kIHRoYXQgc2hvdWxkIGJlIHBvc3RlZCB3aXRo
aW4gdGhlIG5leHQgd2VlayBvciBzby4gICAgVGhpcyBpcyBhbHNvIGEgZ29vZCB0aW1lIGZvciBh
bnlvbmUgaW4gdGhlIFdHIHRoYXQgaGFzbid0IHByZXZpb3VzbHkgcmV2aWV3ZWQgdGhpcyBkb2N1
bWVudCB0byByZXZpZXcgYW5kIHByb3ZpZGUgYW55IGZpbmFsIGNvbW1lbnRzLiAgTm90ZSwgdGhh
dCB0aGlzIGRvY3VtZW50IHdhcyBhZ3JlZWQgdG8gYmUgQUQgc3BvbnNvcmVkIGFyb3VuZCB0aGUg
SUVURi04NiB0aW1lZnJhbWUuDQo+DQo+DQo+DQo+IFJlZ2FyZHMsDQo+DQo+IE1hcnkuDQo+DQo+
DQo+DQo+IFJldmlldyBTdW1tYXJ5OiBBbG1vc3QgcmVhZHkuIENvbW1lbnRzICYgcXVlc3Rpb25z
IGJlbG93Lg0KPg0KPg0KPg0KPiAxKSAgU2VjdGlvbiAyICYgR2VuZXJhbC4gIEknbSBub3Qgc3Vy
ZSB0aGUgZG9jdW1lbnRlZCBhcHByb2FjaCBmb3Igc2VwYXJhdGluZyBub3JtYXRpdmUgdGV4dCBm
cm9tIG5vbi1ub3JtYXRpdmUgaXMgcXVpdGUgc28gaGVscGZ1bC4gIEluIGdlbmVyYWwsIHdlIGV4
cGVjdCB0aGF0IGluIHRoZSBjYXNlIG9mIHN0YW5kYXJkcyB0cmFjayBkb2N1bWVudCB1c2UgUkZD
IDIxMTkgbGFuZ3VhZ2UgdG8gaW5kaWNhdGUgbm9ybWF0aXZlIGJlaGF2aW9ycy4gIEkgdGhpbmsg
dGhlIGZpcnN0IHNlbnRlbmNlIGlzIGdvb2QsIGJ1dCB0aGF0J3Mgbm90IGEgdGVybWlub2xvZ3kg
dGhpbmcuICAgSSBqdXN0IGRvbid0IHNlZSBhIGxvdCBvZiB2YWx1ZSBpbiB3cml0aW5nIHRoZSBk
b2N1bWVudCB0aGlzIHdheS4gIEZvciBleGFtcGxlLCB0aGUgZGVmaW5pdGlvbnMgYXJlbid0IHN0
YXRlZCB0byBiZSBub24tbm9ybWF0aXZlLCBidXQgSSBkb24ndCBzZWUgYW55dGhpbmcgbm9ybWF0
aXZlIGFib3V0IHRoZSBkZWZpbml0aW9ucy4gIEkgdGhpbmsgeW91IGNvdWxkIGVhc2lseSB0aXRs
ZSBTZWN0aW9uIDMgYXMgIldlYlNvY2tldCBQcm90b2NvbCBvdmVydmlldyIgYW5kIHRoYXQgd291
bGQgY2xlYXJseSBpbXBseSBub24tbm9ybWF0aXZlIGJlaGF2aW9yLiAgVGhlcmUgYXJlIGFsc28g
c2V2ZXJhbCBwbGFjZXMgaW4gdGhlIGRvY3VtZW50IGluIHNlY3Rpb25zIHRoYXQgSSBiZWxpZXZl
IGFyZSBpbnRlbmRlZCB0byBwcm92aWRlIG5vcm1hdGl2ZSBiZWhhdmlvciwgYnV0IHRoZXJlIGlz
IGNlcnRhaW5seSBub24tbm9ybWF0aXZlIHRleHQgaW4gdGhvc2Ugc2VjdGlvbnMgKGUuZy4sIHNl
Y3Rpb24gNS4yLjIsIHNlY29uZCBwYXJhZ3JhcGgpLiAgSSB3b3VsZCBzdWdnZXN0IHRoaXMgZG9j
dW1lbnQgZm9sbG93IHRoZSB0eXBpY2FsIChhbmQgYWNjZXB0ZWQpIHN0eWxlIG9mIGlkZW50aWZ5
aW5nIG5vcm1hdGl2ZSBiZWhhdmlvciB3aXRoIDIxMTkgbGFuZ3VhZ2UgKGNvbnNpc3RlbnRseSB1
c2luZyB1cHBlciBjYXNlIGZvciBub3JtYXRpdmUgYmVoYXZpb3IgYW5kIGF2b2lkaW5nIHVzaW5n
IDIxMTkgbGFuZ3VhZ2UgaW4gY2FzZXMgd2hlcmUgYWx0ZXJuYXRpdmUgd29yZHMgY2FuIGJlIHN1
YnN0aXR1dGVkKS4NCj4NCj4NCj4NCj4gMikgU2VjdGlvbiA1LjIuMiwgMm5kIHBhcmFncmFwaC4g
IFJlbGF0ZWQgdG8gbXkgcG9pbnQgYWJvdmUsIGl0J3Mgbm90IGNsZWFyIHRvIG1lIHRoaXMgaXMg
bm9ybWF0aXZlIGJlaGF2aW9yLiAgSSBkb24ndCB0aGluayBpdCBpcyBzaW5jZSBpdCdzIHJlZmVy
cmluZyB0byBleGlzdGluZyA0OTc1IGJlaGF2aW9yLiBIb3dldmVyLCBJIGRpZG4ndCBzZWUgdGhh
dCB0aGUgcmVmZXJlbmNlIGdpdmVuIGluIDQ5NzUgcmVsYXRlcyB0byB0aGUgc2Vjb25kIHBhcnQg
b2YgdGhhdCBzZW50ZW5jZSBzdGF0aW5nIHRoYXQgaW1wbGVtZW50YXRpb25zICJzaG91bGQiIGFs
cmVhZHkgYmUgYWxsb3dpbmcgdW5yZWNvZ25pemVkIHRyYW5zcG9ydHMuICBJdCB3b3VsZCBiZSBx
dWl0ZSB1c2VmdWwgdG8gaGF2ZSB0aGUgZXhhY3QgcmVmZXJlbmNlIGhlcmUgYXMgSSB3YXMgdHJ5
aW5nIHRvIGRvdWJsZSBjaGVjayB0aGlzIHBvaW50IGFuZCBJIGNvdWxkbid0IGZpbmQgaXQuDQo+
DQo+DQo+DQo+IDMpIFNlY3Rpb24gNi4gIEknbSByZWFsbHkgcHV6emxlZCBhcyB0byB3aHkgdGhl
IENvbm5lY3Rpb24gS2VlcC1hbGl2ZSB3b3VsZCBiZSBub24tbm9ybWF0aXZlLiAgSW4gcGFydGlj
dWxhciBnaXZlbiB0aGF0IDIxMTkgbGFuZ3VhZ2UgaXMgY2xlYXJseSBiZWluZyB1c2VkLg0KPg0K
Pg0KPg0KPiA0KSBTZWN0aW9uIDcuICBBZ2FpbiwgSSdtIHB1enpsZWQgYXMgdG8gd2h5IEF1dGhl
bnRpY2F0aW9uIGlzIGNvbnNpZGVyZWQgbm9uLW5vcm1hdGl2ZS4gQUdhaW4sIHlvdSBoYXZlIDIx
MTkgbGFuZ3VhZ2UgaW4gdGhpcyBzZWN0aW9uLg0KPg0KPg0KPg0KPiA1KSBTZWN0aW9uIDEwLjEu
IFNpbmNlIHNlY3VyaW5nIHRoZSBjb25uZWN0aW9uIGlzIGp1c3QgUkVDT01NRU5ERUQsIHdoYXQg
YXJlIHRoZSBpbXBsaWNhdGlvbnMgYW5kIHJpc2tzIGlmIHRoZSBNU1JQIHRyYWZmaWMgaXNuJ3Qg
dHJhbnNwb3J0ZWQgb3ZlciBhIHNlY3VyZSBjb25uZWN0aW9uPw0KPg0KPg0KPg0KPiA2KSBTZWN0
aW9uIDExLiAgWW91IHNob3VsZCBjaGFuZ2UgdGhlIG5hbWUgb2YgdGhlIHJlZ2lzdHJ5IHRvIGJl
IHRoZSBleGFjdCBuYW1lIG9mIHRoZSBJQU5BIHJlZ2lzdHJ5IHRvIGF2b2lkIGFueSBjb25mdXNp
b24uLSBpLmUuLDoNCj4NCj4gT0xEOg0KPg0KPiAgcmVnaXN0cnkgb2YgV2ViU29ja2V0IHN1Yi1w
cm90b2NvbHMNCj4NCj4gTkVXOg0KPg0KPiAgV2ViU29ja2V0IFN1YnByb3RvY29sIE5hbWUgUmVn
aXN0cnkNCj4NCj4NCj4NCj4gNykgU2VjdGlvbiAxMS4gVGhlcmUgaXMgYWxzbyBhIFJlZmVyZW5j
ZSBmaWVsZCBpbiB0aGF0IElBTkEgcmVnaXN0cnkuIEkgd291bGQgc3VnZ2VzdCB5b3UgdXNlIHRo
ZSBzYW1lIGluZm9ybWF0aW9uIGFzIHRoZSBwb2ludGVyIHRvIHRoZSBTdWJwcm90b2NvbCBEZWZp
bml0aW9uIChpLmUuLCB0aGlzIFJGQykuDQo+DQo+DQo+DQo+IDgpIEl0J3MgdHlwaWNhbCBmb3Ig
ZG9jdW1lbnRzIHRoYXQgYXJlIHVwZGF0aW5nIGV4aXN0aW5nIFJGQ3MgdG8gaGF2ZSBhIHNlY3Rp
b24gdGhhdCBzdW1tYXJpemVzIHRoZSB1cGRhdGVzIHRvIHRoZSBleGlzdGluZyBSRkNzIHRoYXQg
YXJlIG1hZGUgYnkgdGhpcyBkb2N1bWVudC4NCj4NCj4NCj4NCj4NCj4NCj4NCj4NCj4gT24gVGh1
LCBEZWMgMTIsIDIwMTMgYXQgNjo1NyBQTSwgPGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4gd3Jv
dGU6DQo+DQo+DQo+IEEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBv
bi1saW5lIEludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmllcy4NCj4NCj4NCj4gICAgICAgIFRpdGxl
ICAgICAgICAgICA6IFRoZSBXZWJTb2NrZXQgUHJvdG9jb2wgYXMgYSBUcmFuc3BvcnQgZm9yIHRo
ZSBNZXNzYWdlIFNlc3Npb24gUmVsYXkgUHJvdG9jb2wgKE1TUlApDQo+ICAgICAgICBBdXRob3Io
cykgICAgICAgOiBQZXRlciBEdW5rbGV5DQo+ICAgICAgICAgICAgICAgICAgICAgICAgICBHYXZp
biBMbGV3ZWxseW4NCj4gICAgICAgICAgICAgICAgICAgICAgICAgIFZpY3RvciBQYXNjdWFsDQo+
ICAgICAgICAgICAgICAgICAgICAgICAgICBBbnRvbiBSb21hbg0KPiAgICAgICAgICAgICAgICAg
ICAgICAgICAgR29uemFsbyBTYWxndWVpcm8NCj4gICAgICAgIEZpbGVuYW1lICAgICAgICA6IGRy
YWZ0LXBkLWRpc3BhdGNoLW1zcnAtd2Vic29ja2V0LTAzLnR4dA0KPiAgICAgICAgUGFnZXMgICAg
ICAgICAgIDogMjENCj4gICAgICAgIERhdGUgICAgICAgICAgICA6IDIwMTMtMTItMTINCj4NCj4g
QWJzdHJhY3Q6DQo+ICAgVGhlIFdlYlNvY2tldCBwcm90b2NvbCBlbmFibGVzIHR3by13YXkgcmVh
bC10aW1lIGNvbW11bmljYXRpb24NCj4gICBiZXR3ZWVuIGNsaWVudHMgYW5kIHNlcnZlcnMuICBU
aGlzIGRvY3VtZW50IHNwZWNpZmllcyBhIG5ldyBXZWJTb2NrZXQNCj4gICBzdWItcHJvdG9jb2wg
YXMgYSByZWxpYWJsZSB0cmFuc3BvcnQgbWVjaGFuaXNtIGJldHdlZW4gTVNSUCAoTWVzc2FnZQ0K
PiAgIFNlc3Npb24gUmVsYXkgUHJvdG9jb2wpIGNsaWVudHMgYW5kIHJlbGF5cyB0byBlbmFibGUg
dXNhZ2Ugb2YgTVNSUCBpbg0KPiAgIG5ldyBzY2VuYXJpb3MuICBUaGlzIGRvY3VtZW50IG5vcm1h
dGl2ZWx5IHVwZGF0ZXMgUkZDIDQ5NzUgYW5kIFJGQw0KPiAgIDQ5NzYuDQo+DQo+DQo+IFRoZSBJ
RVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0KPiBodHRwczov
L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1wZC1kaXNwYXRjaC1tc3JwLXdlYnNvY2tl
dA0KPg0KPiBUaGVyZSdzIGFsc28gYSBodG1saXplZCB2ZXJzaW9uIGF2YWlsYWJsZSBhdDoNCj4g
aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcGQtZGlzcGF0Y2gtbXNycC13ZWJzb2Nr
ZXQtMDMNCj4NCj4gQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxl
IGF0Og0KPiBodHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1wZC1kaXNwYXRj
aC1tc3JwLXdlYnNvY2tldC0wMw0KPg0KPg0KPiBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtl
IGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQo+IHVudGls
IHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0
Zi5vcmcuDQo+DQo+IEludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnlt
b3VzIEZUUCBhdDoNCj4gZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCj4NCj4g
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gSS1ELUFu
bm91bmNlIG1haWxpbmcgbGlzdA0KPiBJLUQtQW5ub3VuY2VAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93
d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pLWQtYW5ub3VuY2UNCj4gSW50ZXJuZXQtRHJh
ZnQgZGlyZWN0b3JpZXM6IGh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwNCj4gb3IgZnRw
Oi8vZnRwLmlldGYub3JnL2lldGYvMXNoYWRvdy1zaXRlcy50eHQNCj4NCj4NCj4NCj4NCj4NCj4N
Cj4gLS0NCj4gUGV0ZXIgRHVua2xleQ0KPiBUZWNobmljYWwgRGlyZWN0b3INCj4gQ3JvY29kaWxl
IFJDUyBMdGQNCg0K

--_000_7594FB04B1934943A5C02806D1A2204B1D108321ESESSMB209erics_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9ImdlbmVyYXRvciIgY29udGVu
dD0iV2luZG93cyBNYWlsIDE3LjUuOTYwMC4yMDMxNSI+DQo8c3R5bGUgdHlwZT0idGV4dC9jc3Mi
PjwhLS1odG1sIHsgZm9udC1mYW1pbHk6ICJDb2xvciBFbW9qaSIsICJDYWxpYnJpIiwgIlNlZ29l
IFVJIiwgIk1laXJ5byIsICJNaWNyb3NvZnQgWWFIZWkgVUkiLCAiTWljcm9zb2Z0IEpoZW5nSGVp
IFVJIiwgIk1hbGd1biBHb3RoaWMiLCAic2Fucy1zZXJpZiI7IH0tLT48L3N0eWxlPjxzdHlsZSBk
YXRhLWV4dGVybmFsc3R5bGU9InRydWUiPjwhLS0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29M
aXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaCB7Cm1hcmdpbi10b3A6MGluOwptYXJn
aW4tcmlnaHQ6MGluOwptYXJnaW4tYm90dG9tOjBpbjsKbWFyZ2luLWxlZnQ6LjVpbjsKbWFyZ2lu
LWJvdHRvbTouMDAwMXB0Owp9CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3Jt
YWwgewptYXJnaW46MGluOwptYXJnaW4tYm90dG9tOi4wMDAxcHQ7Cn0KcC5Nc29MaXN0UGFyYWdy
YXBoQ3hTcEZpcnN0LCBsaS5Nc29MaXN0UGFyYWdyYXBoQ3hTcEZpcnN0LCBkaXYuTXNvTGlzdFBh
cmFncmFwaEN4U3BGaXJzdCwgCnAuTXNvTGlzdFBhcmFncmFwaEN4U3BNaWRkbGUsIGxpLk1zb0xp
c3RQYXJhZ3JhcGhDeFNwTWlkZGxlLCBkaXYuTXNvTGlzdFBhcmFncmFwaEN4U3BNaWRkbGUsIApw
Lk1zb0xpc3RQYXJhZ3JhcGhDeFNwTGFzdCwgbGkuTXNvTGlzdFBhcmFncmFwaEN4U3BMYXN0LCBk
aXYuTXNvTGlzdFBhcmFncmFwaEN4U3BMYXN0IHsKbWFyZ2luLXRvcDowaW47Cm1hcmdpbi1yaWdo
dDowaW47Cm1hcmdpbi1ib3R0b206MGluOwptYXJnaW4tbGVmdDouNWluOwptYXJnaW4tYm90dG9t
Oi4wMDAxcHQ7CmxpbmUtaGVpZ2h0OjExNSU7Cn0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5
IGRpcj0ibHRyIj4NCjxkaXYgZGF0YS1leHRlcm5hbHN0eWxlPSJmYWxzZSIgZGlyPSJsdHIiIHN0
eWxlPSJmb250LWZhbWlseTogJ0NhbGlicmknLCAnU2Vnb2UgVUknLCAnTWVpcnlvJywgJ01pY3Jv
c29mdCBZYUhlaSBVSScsICdNaWNyb3NvZnQgSmhlbmdIZWkgVUknLCAnTWFsZ3VuIEdvdGhpYycs
ICdzYW5zLXNlcmlmJztmb250LXNpemU6MTJwdDsiPg0KPGRpdj5IaSBCZW4sPC9kaXY+DQo8ZGl2
Pjxicj4NCjwvZGl2Pg0KPGRpdj5NeSB0aGlua2luZyBpcyB0aGF0IHRoZSBXUyBjbGllbnQgY291
bGQgaW5kaWNhdGUgc3VwcG9ydCBvZiBDRU1BLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxk
aXY+UmVnYXJkcyw8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkNocmlzdGVyPC9kaXY+
DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdiBkYXRhLXNpZ25hdHVyZWJsb2NrPSJ0cnVlIj4NCjxk
aXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlNlbnQgZnJvbSBXaW5kb3dzIE1haWw8L2Rpdj4NCjxkaXY+
PGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9InBhZGRpbmctdG9wOiA1cHg7IGJvcmRl
ci10b3AtY29sb3I6IHJnYigyMjksIDIyOSwgMjI5KTsgYm9yZGVyLXRvcC13aWR0aDogMXB4OyBi
b3JkZXItdG9wLXN0eWxlOiBzb2xpZDsiPg0KPGRpdj48Zm9udCBmYWNlPSIgJ0NhbGlicmknLCAn
U2Vnb2UgVUknLCAnTWVpcnlvJywgJ01pY3Jvc29mdCBZYUhlaSBVSScsICdNaWNyb3NvZnQgSmhl
bmdIZWkgVUknLCAnTWFsZ3VuIEdvdGhpYycsICdzYW5zLXNlcmlmJyIgc3R5bGU9ImxpbmUtaGVp
Z2h0OiAxNXB0OyBsZXR0ZXItc3BhY2luZzogMC4wMmVtOyBmb250LWZhbWlseTogJnF1b3Q7Q2Fs
aWJyaSZxdW90OywgJnF1b3Q7U2Vnb2UgVUkmcXVvdDssICZxdW90O01laXJ5byZxdW90OywgJnF1
b3Q7TWljcm9zb2Z0IFlhSGVpIFVJJnF1b3Q7LCAmcXVvdDtNaWNyb3NvZnQgSmhlbmdIZWkgVUkm
cXVvdDssICZxdW90O01hbGd1biBHb3RoaWMmcXVvdDssICZxdW90O3NhbnMtc2VyaWYmcXVvdDs7
IGZvbnQtc2l6ZTogMTJwdDsiPjxiPkZyb206PC9iPiZuYnNwOzxhIGhyZWY9Im1haWx0bzpiZW5A
bm9zdHJ1bS5jb20iIHRhcmdldD0iX3BhcmVudCI+QmVuDQogQ2FtcGJlbGw8L2E+PGJyPg0KPGI+
U2VudDo8L2I+Jm5ic3A74oCOTW9uZGF54oCOLCDigI5KYW51YXJ54oCOIOKAjjIw4oCOLCDigI4y
MDE0IOKAjjbigI464oCOMzLigI4g4oCOQU08YnI+DQo8Yj5Ubzo8L2I+Jm5ic3A7PGEgaHJlZj0i
bWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbSIgdGFyZ2V0PSJfcGFyZW50Ij5D
aHJpc3RlciBIb2xtYmVyZzwvYT48YnI+DQo8Yj5DYzo8L2I+Jm5ic3A7PGEgaHJlZj0ibWFpbHRv
OnBldGVyLmR1bmtsZXlAY3JvY29kaWxlcnRjLm5ldCIgdGFyZ2V0PSJfcGFyZW50Ij5QZXRlciBE
dW5rbGV5PC9hPiwNCjxhIGhyZWY9Im1haWx0bzptYXJ5LmlldGYuYmFybmVzQGdtYWlsLmNvbSIg
dGFyZ2V0PSJfcGFyZW50Ij5NYXJ5IEJhcm5lczwvYT4sIDxhIGhyZWY9Im1haWx0bzpkaXNwYXRj
aEBpZXRmLm9yZyIgdGFyZ2V0PSJfcGFyZW50Ij4NCkRJU1BBVENIPC9hPiwgPGEgaHJlZj0ibWFp
bHRvOmRyYWZ0LXBkLWRpc3BhdGNoLW1zcnAtd2Vic29ja2V0QHRvb2xzLmlldGYub3JnIiB0YXJn
ZXQ9Il9wYXJlbnQiPg0KZHJhZnQtcGQtZGlzcGF0Y2gtbXNycC13ZWJzb2NrZXRAdG9vbHMuaWV0
Zi5vcmc8L2E+PC9mb250PjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdiBk
aXI9IiI+DQo8ZGl2IGlkPSJyZWFkaW5nUGFuZUJvZHlDb250ZW50Ij48YnI+DQpPbiBKYW4gMTks
IDIwMTQsIGF0IDk6MjggUE0sIENocmlzdGVyIEhvbG1iZXJnICZsdDtjaHJpc3Rlci5ob2xtYmVy
Z0Blcmljc3Nvbi5jb20mZ3Q7IHdyb3RlOjxicj4NCjxicj4NCiZndDsgSGksPGJyPg0KJmd0OyA8
YnI+DQomZ3Q7IEkgc2VlIG5vIHJlYXNvbiB3aHkgaXQgc2hvdWxkIGJlIGEgc2VwYXJhdGUgZG9j
dW1lbnQsIGFzIGl0IHNob3VsZCBub3QgaGF2ZSBhbnkgYWZmZWN0IG9uIHRoZSB3ZWJzb2NrZXQg
c3BlY2lmaWMgcHJvY2VkdXJlcywgd2hpY2ggaXMgdGhlIG1haW4gc2NvcGUgb2YgdGhlIGRvY3Vt
ZW50Ljxicj4NCjxicj4NCkNocmlzdGVyLCBJIGFzc3VtZSB5b3UgbWVhbiBmb3IgYSBXZWJTb2Nr
ZXQgTVNSUCAmcXVvdDtzZXJ2ZXImcXVvdDsgYWN0aW5nIG9uIGJlaGFsZiBvZiBhIFdTIE1TUlAg
Y2xpZW50IHRvIGJlIGFibGUgdG8gdXNlIENFTUEgYmV0d2VlbiBpdHNlbGYgYW5kIGEgdGhpcmQg
cGFydHkgY2xpZW50PyBOb3QgYmV0d2VlbiBhIFdlYlNvY2tldCBNU1JQIGNsaWVudCBhbmQgYSBX
ZWJTb2NrZXQgTVNSUCBzZXJ2ZXIsIHJpZ2h0Pzxicj4NCjxicj4NCiZndDsgPGJyPg0KJmd0OyBS
ZWdhcmRzLDxicj4NCiZndDsgPGJyPg0KJmd0OyBDaHJpc3Rlcjxicj4NCiZndDsgPGJyPg0KJmd0
OyBTZW50IGZyb20gbXkgU29ueSBFcmljc3NvbiBYcGVyaWEgYXJjIFM8YnI+DQomZ3Q7IDxicj4N
CiZndDsgUGV0ZXIgRHVua2xleSAmbHQ7cGV0ZXIuZHVua2xleUBjcm9jb2RpbGVydGMubmV0Jmd0
OyB3cm90ZTo8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyBIZWxsbyw8YnI+DQomZ3Q7
IDxicj4NCiZndDsgUGVyaGFwcyB0aGUgZG9jdW1lbnQgdGl0bGUgc2hvdWxkIGJlIGNvcnJlY3Rl
ZC4gTVNSUC1DRU1BIGlzIG91dHNpZGUgb2YgdGhlIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQgYXMg
dGhpcyBkb2N1bWVudCBpcyBpbnRlbmRlZCB0byBkZXNjcmliZSBjb25uZWN0aW5nIHRvIGEgV2Vi
U29ja2V0IHNlcnZlciB0aGF0IGlzIGFuIE1TUlAgcmVsYXkuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7
IEkgY2FuIHNlZSBubyByZWFzb24gd2h5IE1TUlAtQ0VNQSBjYW4ndCBiZSB1c2VkIG92ZXIgV2Vi
U29ja2V0cywgYnV0IGlmIGFueW9uZSBoYXMgYW4gaW50ZXJlc3QgaW4gdGhpcyBJIHRoaW5rIHRo
YXQgdGhleSBzaG91bGQgcHV0IGl0IGluIGEgZG9jdW1lbnQgb2YgaXRzIG93bi48YnI+DQomZ3Q7
IDxicj4NCiZndDsgPGJyPg0KJmd0OyBSZWdhcmRzLDxicj4NCiZndDsgPGJyPg0KJmd0OyBQZXRl
cjxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IE9uIDE4IEphbnVhcnkgMjAxNCAwODo1
MiwgQ2hyaXN0ZXIgSG9sbWJlcmcgJmx0O2NocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbSZn
dDsgd3JvdGU6PGJyPg0KJmd0OyBIaSw8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyA8
YnI+DQomZ3Q7IEkgaGF2ZSBub3QgZm9sbG93ZWQgdGhlIHdvcmsgb24gdGhpcyBkcmFmdCwgc28g
SSBhcHBvbG9naXplIGlmIHRoZSBmb2xsb3dpbmcgaGFzIGJlZW4gZGlzY3Vzc2VkLjxicj4NCiZn
dDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgV2hpbGUgSSBkbyB1bmRlcnN0YW5k
IHRoYXQgYSBXUyBDbGllbnQgaGFzIHRvIGVzdGFibGlzaCB0aGUgV2ViU29ja2V0IHdpdGggdGhl
IFdlYiBTZXJ2ZXIsIEkgZG9u4oCZdCB1bmRlcnN0YW5kIHdoeSB3ZSBuZWVkIHRvIG1hbmRhdGUg
dGhlIFdTIFNlcnZlciB0byBiZSBhbiBNU1JQIFJlbGF5LiBUaGF0IHdvdWxkIGUuZy4gcHJldmVu
dCB0aGUgdXNhZ2Ugb2YgTVNSUC1DRU1BLjxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7
IDxicj4NCiZndDsgUmVnYXJkcyw8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+
DQomZ3Q7IENocmlzdGVyPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0
OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEzDpGhldHTDpGrD
pDogZGlzcGF0Y2ggW21haWx0bzpkaXNwYXRjaC1ib3VuY2VzQGlldGYub3JnXSBQdW9sZXN0YSBN
YXJ5IEJhcm5lczxicj4NCiZndDsgTMOkaGV0ZXR0eTogMTEuIHRhbW1pa3V1dGEgMjAxNCAwOjU5
PGJyPg0KJmd0OyBWYXN0YWFub3R0YWphOiBESVNQQVRDSDxicj4NCiZndDsgS29waW86IEJlbiBD
YW1wYmVsbDsgZHJhZnQtcGQtZGlzcGF0Y2gtbXNycC13ZWJzb2NrZXRAdG9vbHMuaWV0Zi5vcmc8
YnI+DQomZ3Q7IEFpaGU6IFJlOiBbZGlzcGF0Y2hdIEktRCBBY3Rpb246IGRyYWZ0LXBkLWRpc3Bh
dGNoLW1zcnAtd2Vic29ja2V0LTAzLnR4dDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7
IDxicj4NCiZndDsgSSBoYXZlIGFncmVlZCB0byBzaGVwaGVyZCB0aGlzIGRvY3VtZW50LiZuYnNw
OyBJJ3ZlIHJldmlld2VkIHRoZSBkb2N1bWVudCBpbiBhbnRpY2lwYXRpb24gb2YgZG9pbmcgdGhl
IFBST1RPIHdyaXRlLXVwIGFuZCBoYXZlIHRoZSBmb2xsb3dpbmcgY29tbWVudHMgYW5kIHF1ZXN0
aW9ucy4mbmJzcDsgQmVuIENhbXBiZWxsIGhhcyBhZ3JlZWQgdG8gZG8gdGhlIHJlcXVpcmVkIGV4
cGVydCByZXZpZXcgYW5kIHRoYXQgc2hvdWxkIGJlIHBvc3RlZCB3aXRoaW4gdGhlDQogbmV4dCB3
ZWVrIG9yIHNvLiZuYnNwOyZuYnNwOyZuYnNwOyBUaGlzIGlzIGFsc28gYSBnb29kIHRpbWUgZm9y
IGFueW9uZSBpbiB0aGUgV0cgdGhhdCBoYXNuJ3QgcHJldmlvdXNseSByZXZpZXdlZCB0aGlzIGRv
Y3VtZW50IHRvIHJldmlldyBhbmQgcHJvdmlkZSBhbnkgZmluYWwgY29tbWVudHMuJm5ic3A7IE5v
dGUsIHRoYXQgdGhpcyBkb2N1bWVudCB3YXMgYWdyZWVkIHRvIGJlIEFEIHNwb25zb3JlZCBhcm91
bmQgdGhlIElFVEYtODYgdGltZWZyYW1lLjxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7
IDxicj4NCiZndDsgUmVnYXJkcyw8YnI+DQomZ3Q7IDxicj4NCiZndDsgTWFyeS4gPGJyPg0KJmd0
OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyBSZXZpZXcgU3VtbWFyeTogQWxtb3N0
IHJlYWR5LiBDb21tZW50cyAmYW1wOyBxdWVzdGlvbnMgYmVsb3cuPGJyPg0KJmd0OyA8YnI+DQom
Z3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyAxKSZuYnNwOyBTZWN0aW9uIDIgJmFtcDsgR2VuZXJh
bC4mbmJzcDsgSSdtIG5vdCBzdXJlIHRoZSBkb2N1bWVudGVkIGFwcHJvYWNoIGZvciBzZXBhcmF0
aW5nIG5vcm1hdGl2ZSB0ZXh0IGZyb20gbm9uLW5vcm1hdGl2ZSBpcyBxdWl0ZSBzbyBoZWxwZnVs
LiZuYnNwOyBJbiBnZW5lcmFsLCB3ZSBleHBlY3QgdGhhdCBpbiB0aGUgY2FzZSBvZiBzdGFuZGFy
ZHMgdHJhY2sgZG9jdW1lbnQgdXNlIFJGQyAyMTE5IGxhbmd1YWdlIHRvIGluZGljYXRlIG5vcm1h
dGl2ZSBiZWhhdmlvcnMuJm5ic3A7DQogSSB0aGluayB0aGUgZmlyc3Qgc2VudGVuY2UgaXMgZ29v
ZCwgYnV0IHRoYXQncyBub3QgYSB0ZXJtaW5vbG9neSB0aGluZy4mbmJzcDsmbmJzcDsgSSBqdXN0
IGRvbid0IHNlZSBhIGxvdCBvZiB2YWx1ZSBpbiB3cml0aW5nIHRoZSBkb2N1bWVudCB0aGlzIHdh
eS4mbmJzcDsgRm9yIGV4YW1wbGUsIHRoZSBkZWZpbml0aW9ucyBhcmVuJ3Qgc3RhdGVkIHRvIGJl
IG5vbi1ub3JtYXRpdmUsIGJ1dCBJIGRvbid0IHNlZSBhbnl0aGluZyBub3JtYXRpdmUgYWJvdXQg
dGhlIGRlZmluaXRpb25zLiZuYnNwOw0KIEkgdGhpbmsgeW91IGNvdWxkIGVhc2lseSB0aXRsZSBT
ZWN0aW9uIDMgYXMgJnF1b3Q7V2ViU29ja2V0IFByb3RvY29sIG92ZXJ2aWV3JnF1b3Q7IGFuZCB0
aGF0IHdvdWxkIGNsZWFybHkgaW1wbHkgbm9uLW5vcm1hdGl2ZSBiZWhhdmlvci4mbmJzcDsgVGhl
cmUgYXJlIGFsc28gc2V2ZXJhbCBwbGFjZXMgaW4gdGhlIGRvY3VtZW50IGluIHNlY3Rpb25zIHRo
YXQgSSBiZWxpZXZlIGFyZSBpbnRlbmRlZCB0byBwcm92aWRlIG5vcm1hdGl2ZSBiZWhhdmlvciwg
YnV0IHRoZXJlIGlzDQogY2VydGFpbmx5IG5vbi1ub3JtYXRpdmUgdGV4dCBpbiB0aG9zZSBzZWN0
aW9ucyAoZS5nLiwgc2VjdGlvbiA1LjIuMiwgc2Vjb25kIHBhcmFncmFwaCkuJm5ic3A7IEkgd291
bGQgc3VnZ2VzdCB0aGlzIGRvY3VtZW50IGZvbGxvdyB0aGUgdHlwaWNhbCAoYW5kIGFjY2VwdGVk
KSBzdHlsZSBvZiBpZGVudGlmeWluZyBub3JtYXRpdmUgYmVoYXZpb3Igd2l0aCAyMTE5IGxhbmd1
YWdlIChjb25zaXN0ZW50bHkgdXNpbmcgdXBwZXIgY2FzZSBmb3Igbm9ybWF0aXZlDQogYmVoYXZp
b3IgYW5kIGF2b2lkaW5nIHVzaW5nIDIxMTkgbGFuZ3VhZ2UgaW4gY2FzZXMgd2hlcmUgYWx0ZXJu
YXRpdmUgd29yZHMgY2FuIGJlIHN1YnN0aXR1dGVkKS48YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJy
Pg0KJmd0OyA8YnI+DQomZ3Q7IDIpIFNlY3Rpb24gNS4yLjIsIDJuZCBwYXJhZ3JhcGguJm5ic3A7
IFJlbGF0ZWQgdG8gbXkgcG9pbnQgYWJvdmUsIGl0J3Mgbm90IGNsZWFyIHRvIG1lIHRoaXMgaXMg
bm9ybWF0aXZlIGJlaGF2aW9yLiZuYnNwOyBJIGRvbid0IHRoaW5rIGl0IGlzIHNpbmNlIGl0J3Mg
cmVmZXJyaW5nIHRvIGV4aXN0aW5nIDQ5NzUgYmVoYXZpb3IuIEhvd2V2ZXIsIEkgZGlkbid0IHNl
ZSB0aGF0IHRoZSByZWZlcmVuY2UgZ2l2ZW4gaW4gNDk3NSByZWxhdGVzIHRvIHRoZSBzZWNvbmQN
CiBwYXJ0IG9mIHRoYXQgc2VudGVuY2Ugc3RhdGluZyB0aGF0IGltcGxlbWVudGF0aW9ucyAmcXVv
dDtzaG91bGQmcXVvdDsgYWxyZWFkeSBiZSBhbGxvd2luZyB1bnJlY29nbml6ZWQgdHJhbnNwb3J0
cy4mbmJzcDsgSXQgd291bGQgYmUgcXVpdGUgdXNlZnVsIHRvIGhhdmUgdGhlIGV4YWN0IHJlZmVy
ZW5jZSBoZXJlIGFzIEkgd2FzIHRyeWluZyB0byBkb3VibGUgY2hlY2sgdGhpcyBwb2ludCBhbmQg
SSBjb3VsZG4ndCBmaW5kIGl0Lg0KPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJy
Pg0KJmd0OyAzKSBTZWN0aW9uIDYuJm5ic3A7IEknbSByZWFsbHkgcHV6emxlZCBhcyB0byB3aHkg
dGhlIENvbm5lY3Rpb24gS2VlcC1hbGl2ZSB3b3VsZCBiZSBub24tbm9ybWF0aXZlLiZuYnNwOyBJ
biBwYXJ0aWN1bGFyIGdpdmVuIHRoYXQgMjExOSBsYW5ndWFnZSBpcyBjbGVhcmx5IGJlaW5nIHVz
ZWQuJm5ic3A7DQo8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDQp
IFNlY3Rpb24gNy4mbmJzcDsgQWdhaW4sIEknbSBwdXp6bGVkIGFzIHRvIHdoeSBBdXRoZW50aWNh
dGlvbiBpcyBjb25zaWRlcmVkIG5vbi1ub3JtYXRpdmUuIEFHYWluLCB5b3UgaGF2ZSAyMTE5IGxh
bmd1YWdlIGluIHRoaXMgc2VjdGlvbi4mbmJzcDsNCjxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+
DQomZ3Q7IDxicj4NCiZndDsgNSkgU2VjdGlvbiAxMC4xLiBTaW5jZSBzZWN1cmluZyB0aGUgY29u
bmVjdGlvbiBpcyBqdXN0IFJFQ09NTUVOREVELCB3aGF0IGFyZSB0aGUgaW1wbGljYXRpb25zIGFu
ZCByaXNrcyBpZiB0aGUgTVNSUCB0cmFmZmljIGlzbid0IHRyYW5zcG9ydGVkIG92ZXIgYSBzZWN1
cmUgY29ubmVjdGlvbj8NCjxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZn
dDsgNikgU2VjdGlvbiAxMS4mbmJzcDsgWW91IHNob3VsZCBjaGFuZ2UgdGhlIG5hbWUgb2YgdGhl
IHJlZ2lzdHJ5IHRvIGJlIHRoZSBleGFjdCBuYW1lIG9mIHRoZSBJQU5BIHJlZ2lzdHJ5IHRvIGF2
b2lkIGFueSBjb25mdXNpb24uLSBpLmUuLDo8YnI+DQomZ3Q7IDxicj4NCiZndDsgT0xEOjxicj4N
CiZndDsgPGJyPg0KJmd0OyZuYnNwOyByZWdpc3RyeSBvZiBXZWJTb2NrZXQgc3ViLXByb3RvY29s
czxicj4NCiZndDsgPGJyPg0KJmd0OyBORVc6IDxicj4NCiZndDsgPGJyPg0KJmd0OyZuYnNwOyBX
ZWJTb2NrZXQgU3VicHJvdG9jb2wgTmFtZSBSZWdpc3RyeSZuYnNwOyA8YnI+DQomZ3Q7IDxicj4N
CiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDcpIFNlY3Rpb24gMTEuIFRoZXJlIGlzIGFsc28g
YSBSZWZlcmVuY2UgZmllbGQgaW4gdGhhdCBJQU5BIHJlZ2lzdHJ5LiBJIHdvdWxkIHN1Z2dlc3Qg
eW91IHVzZSB0aGUgc2FtZSBpbmZvcm1hdGlvbiBhcyB0aGUgcG9pbnRlciB0byB0aGUgU3VicHJv
dG9jb2wgRGVmaW5pdGlvbiAoaS5lLiwgdGhpcyBSRkMpLg0KPGJyPg0KJmd0OyA8YnI+DQomZ3Q7
IDxicj4NCiZndDsgPGJyPg0KJmd0OyA4KSBJdCdzIHR5cGljYWwgZm9yIGRvY3VtZW50cyB0aGF0
IGFyZSB1cGRhdGluZyBleGlzdGluZyBSRkNzIHRvIGhhdmUgYSBzZWN0aW9uIHRoYXQgc3VtbWFy
aXplcyB0aGUgdXBkYXRlcyB0byB0aGUgZXhpc3RpbmcgUkZDcyB0aGF0IGFyZSBtYWRlIGJ5IHRo
aXMgZG9jdW1lbnQuJm5ic3A7DQo8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+
DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgT24gVGh1
LCBEZWMgMTIsIDIwMTMgYXQgNjo1NyBQTSwgJmx0O2ludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyZn
dDsgd3JvdGU6PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgQSBOZXcgSW50ZXJuZXQt
RHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIGRpcmVj
dG9yaWVzLjxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRpdGxlJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDogVGhlIFdlYlNvY2tldCBQcm90b2Nv
bCBhcyBhIFRyYW5zcG9ydCBmb3IgdGhlIE1lc3NhZ2UgU2Vzc2lvbiBSZWxheSBQcm90b2NvbCAo
TVNSUCk8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
IEF1dGhvcihzKSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA6IFBldGVyIER1
bmtsZXk8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEdhdmlu
IExsZXdlbGx5bjxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg
VmljdG9yIFBhc2N1YWw8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7IEFudG9uIFJvbWFuPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyBHb256YWxvIFNhbGd1ZWlybzxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsgRmlsZW5hbWUmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsgOiBkcmFmdC1wZC1kaXNwYXRjaC1tc3JwLXdlYnNvY2tldC0wMy50eHQ8YnI+
DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFBhZ2VzJm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
IDogMjE8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
IERhdGUmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsgOiAyMDEzLTEyLTEyPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEFic3RyYWN0
Ojxicj4NCiZndDsmbmJzcDsmbmJzcDsgVGhlIFdlYlNvY2tldCBwcm90b2NvbCBlbmFibGVzIHR3
by13YXkgcmVhbC10aW1lIGNvbW11bmljYXRpb248YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7IGJldHdl
ZW4gY2xpZW50cyBhbmQgc2VydmVycy4mbmJzcDsgVGhpcyBkb2N1bWVudCBzcGVjaWZpZXMgYSBu
ZXcgV2ViU29ja2V0PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyBzdWItcHJvdG9jb2wgYXMgYSByZWxp
YWJsZSB0cmFuc3BvcnQgbWVjaGFuaXNtIGJldHdlZW4gTVNSUCAoTWVzc2FnZTxicj4NCiZndDsm
bmJzcDsmbmJzcDsgU2Vzc2lvbiBSZWxheSBQcm90b2NvbCkgY2xpZW50cyBhbmQgcmVsYXlzIHRv
IGVuYWJsZSB1c2FnZSBvZiBNU1JQIGluPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyBuZXcgc2NlbmFy
aW9zLiZuYnNwOyBUaGlzIGRvY3VtZW50IG5vcm1hdGl2ZWx5IHVwZGF0ZXMgUkZDIDQ5NzUgYW5k
IFJGQzxicj4NCiZndDsmbmJzcDsmbmJzcDsgNDk3Ni48YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJy
Pg0KJmd0OyBUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBp
czo8YnI+DQomZ3Q7IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXBkLWRp
c3BhdGNoLW1zcnAtd2Vic29ja2V0PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFRoZXJlJ3MgYWxzbyBh
IGh0bWxpemVkIHZlcnNpb24gYXZhaWxhYmxlIGF0Ojxicj4NCiZndDsgaHR0cDovL3Rvb2xzLmll
dGYub3JnL2h0bWwvZHJhZnQtcGQtZGlzcGF0Y2gtbXNycC13ZWJzb2NrZXQtMDM8YnI+DQomZ3Q7
IDxicj4NCiZndDsgQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxl
IGF0Ojxicj4NCiZndDsgaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtcGQt
ZGlzcGF0Y2gtbXNycC13ZWJzb2NrZXQtMDM8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0
OyBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0
aGUgdGltZSBvZiBzdWJtaXNzaW9uPGJyPg0KJmd0OyB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lv
biBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLjxicj4NCiZndDsgPGJy
Pg0KJmd0OyBJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBG
VFAgYXQ6PGJyPg0KJmd0OyBmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLzxicj4N
CiZndDsgPGJyPg0KJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fXzxicj4NCiZndDsgSS1ELUFubm91bmNlIG1haWxpbmcgbGlzdDxicj4NCiZndDsgSS1E
LUFubm91bmNlQGlldGYub3JnPGJyPg0KJmd0OyBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu
L2xpc3RpbmZvL2ktZC1hbm5vdW5jZTxicj4NCiZndDsgSW50ZXJuZXQtRHJhZnQgZGlyZWN0b3Jp
ZXM6IGh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWw8YnI+DQomZ3Q7IG9yIGZ0cDovL2Z0
cC5pZXRmLm9yZy9pZXRmLzFzaGFkb3ctc2l0ZXMudHh0PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxi
cj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyAtLSA8
YnI+DQomZ3Q7IFBldGVyIER1bmtsZXk8YnI+DQomZ3Q7IFRlY2huaWNhbCBEaXJlY3Rvcjxicj4N
CiZndDsgQ3JvY29kaWxlIFJDUyBMdGQ8YnI+DQo8YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+
DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_7594FB04B1934943A5C02806D1A2204B1D108321ESESSMB209erics_--

From peter.dunkley@crocodilertc.net  Mon Jan 20 01:44:56 2014
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 4DD4E1A00B0 for ; Mon, 20 Jan 2014 01:44:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level: 
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=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 PjhZEVUSDySs for ; Mon, 20 Jan 2014 01:44:53 -0800 (PST)
Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id C1EA31A00AF for ; Mon, 20 Jan 2014 01:44:53 -0800 (PST)
Received: by mail-ie0-f181.google.com with SMTP id tq11so6181907ieb.40 for ; Mon, 20 Jan 2014 01:44:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=crocodilertc.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=EOLwdo9YVTZrKyKwN45DKwfiPZ9+aJbxy5mykkav82E=; b=Muxzal/Oywo+gsZaCkbIOOOOOv+74pG3ZX8XveAv8+pXXSKZnSsH1Krh+9FkljkBrb f0OkSp5Em41O8RSpkYBLozvW2U47HvigzzWe4kU8WiDuHrLTiBhiodBToznv0/spZ5Fx Y8uNeE4NBhTNJkm5ht1wLFZxOg/dzUEnb3Ynk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=EOLwdo9YVTZrKyKwN45DKwfiPZ9+aJbxy5mykkav82E=; b=QD1ksE+8hLLHlIB1W92rAYo5fgFcHYmdHFP5q0QMj1IKG3IiXittqmehKDo2n+3Rpw zqQs8QlwZN6WoSibQ+NBUrYnbAnFdSeXiPO72dx4JoNMuObglXcbYKjwsQO4yccnF+Rd awMo9qcl7BX3DCaJbgygLj7kNW2x3ENpCNfTq2YfjnikEqNkduCXtCuRKeIjaE1ptTY0 Eqo3dJTKzfzN97ZCWfhjB+7aC1EIvYEiNP0vRDlV3AS4DB/F7jQhK4S3Ovd7NSXwvNY/ acV8qxqnrWgzrFZf+NLMEVyUEHC6p08VKOvvaJKwasAfLiunkNlWpVan0CJbT1VTmGaV MD5A==
X-Gm-Message-State: ALoCoQmS+RIaH/05M9FVvGZVQkTwDzlJAnhG49EKjbRaHxGdYNbv8FrGLzq4yv7vOYTesC483Wsf
MIME-Version: 1.0
X-Received: by 10.50.79.138 with SMTP id j10mr11660440igx.2.1390211093920; Mon, 20 Jan 2014 01:44:53 -0800 (PST)
Received: by 10.64.229.13 with HTTP; Mon, 20 Jan 2014 01:44:53 -0800 (PST)
In-Reply-To: 
References: <20131213005747.777.34301.idtracker@ietfa.amsl.com>  <7594FB04B1934943A5C02806D1A2204B1D104D91@ESESSMB209.ericsson.se>  
Date: Mon, 20 Jan 2014 09:44:53 +0000
Message-ID: 
From: Peter Dunkley 
To: Christer Holmberg 
Content-Type: multipart/alternative; boundary=089e0122ab746a930a04f063bea1
Cc: DISPATCH , Ben Campbell , "draft-pd-dispatch-msrp-websocket@tools.ietf.org" 
Subject: Re: [dispatch] I-D Action: draft-pd-dispatch-msrp-websocket-03.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: Mon, 20 Jan 2014 09:44:56 -0000

--089e0122ab746a930a04f063bea1
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Hi Christer,

There is working code for the document as-is and plans for more
implementations. I think that if someone has a need for MSRP-CEMA in this
scenario then they should join with the current authors to contribute the
text and working code for this.

Regards,

Peter


On 20 January 2014 03:28, Christer Holmberg
wrote:

>  Hi,
>
> I see no reason why it should be a separate document, as it should not ha=
ve any affect on the websocket specific procedures, which is the main scope=
 of the document.
>
> Regards,
>
> Christer
>
> Sent from my Sony Ericsson Xperia arc S
>
> Peter Dunkley  wrote:
>
>
>  Hello,
>
>  Perhaps the document title should be corrected. MSRP-CEMA is outside of
> the scope of this document as this document is intended to describe
> connecting to a WebSocket server that is an MSRP relay.
>
>  I can see no reason why MSRP-CEMA can't be used over WebSockets, but if
> anyone has an interest in this I think that they should put it in a
> document of its own.
>
>
>  Regards,
>
>  Peter
>
>
> On 18 January 2014 08:52, Christer Holmberg <
> christer.holmberg@ericsson.com> wrote:
>
>>  Hi,
>>
>>
>>
>> I have not followed the work on this draft, so I appologize if the
>> following has been discussed.
>>
>>
>>
>> While I do understand that a WS Client has to establish the WebSocket
>> with the Web Server, I don=92t understand why we need to mandate the WS
>> Server to be an MSRP Relay. That would e.g. prevent the usage of MSRP-CE=
MA.
>>
>>
>>
>> Regards,
>>
>>
>>
>> Christer
>>
>>
>>
>>
>>
>>
>>
>> *L=E4hett=E4j=E4:* dispatch [mailto:dispatch-bounces@ietf.org] *Puolesta=
 *Mary
>> Barnes
>> *L=E4hetetty:* 11. tammikuuta 2014 0:59
>> *Vastaanottaja:* DISPATCH
>> *Kopio:* Ben Campbell; draft-pd-dispatch-msrp-websocket@tools.ietf.org
>> *Aihe:* Re: [dispatch] I-D Action:
>> draft-pd-dispatch-msrp-websocket-03.txt
>>
>>
>>
>> I have agreed to shepherd this document.  I've reviewed the document in
>> anticipation of doing the PROTO write-up and have the following comments
>> and questions.  Ben Campbell has agreed to do the required expert review
>> and that should be posted within the next week or so.    This is also a
>> good time for anyone in the WG that hasn't previously reviewed this
>> document to review and provide any final comments.  Note, that this
>> document was agreed to be AD sponsored around the IETF-86 timeframe.
>>
>>
>>
>> Regards,
>>
>> Mary.
>>
>>
>>
>> Review Summary: Almost ready. Comments & questions below.
>>
>>
>>
>> 1)  Section 2 & General.  I'm not sure the documented approach for
>> separating normative text from non-normative is quite so helpful.  In
>> general, we expect that in the case of standards track document use RFC
>> 2119 language to indicate normative behaviors.  I think the first senten=
ce
>> is good, but that's not a terminology thing.   I just don't see a lot of
>> value in writing the document this way.  For example, the definitions
>> aren't stated to be non-normative, but I don't see anything normative ab=
out
>> the definitions.  I think you could easily title Section 3 as "WebSocket
>> Protocol overview" and that would clearly imply non-normative behavior.
>>  There are also several places in the document in sections that I believ=
e
>> are intended to provide normative behavior, but there is certainly
>> non-normative text in those sections (e.g., section 5.2.2, second
>> paragraph).  I would suggest this document follow the typical (and
>> accepted) style of identifying normative behavior with 2119 language
>> (consistently using upper case for normative behavior and avoiding using
>> 2119 language in cases where alternative words can be substituted).
>>
>>
>>
>> 2) Section 5.2.2, 2nd paragraph.  Related to my point above, it's not
>> clear to me this is normative behavior.  I don't think it is since it's
>> referring to existing 4975 behavior. However, I didn't see that the
>> reference given in 4975 relates to the second part of that sentence stat=
ing
>> that implementations "should" already be allowing unrecognized transport=
s.
>>  It would be quite useful to have the exact reference here as I was tryi=
ng
>> to double check this point and I couldn't find it.
>>
>>
>>
>> 3) Section 6.  I'm really puzzled as to why the Connection Keep-alive
>> would be non-normative.  In particular given that 2119 language is clear=
ly
>> being used.
>>
>>
>>
>> 4) Section 7.  Again, I'm puzzled as to why Authentication is considered
>> non-normative. AGain, you have 2119 language in this section.
>>
>>
>>
>> 5) Section 10.1. Since securing the connection is just RECOMMENDED, what
>> are the implications and risks if the MSRP traffic isn't transported ove=
r a
>> secure connection?
>>
>>
>>
>> 6) Section 11.  You should change the name of the registry to be the
>> exact name of the IANA registry to avoid any confusion.- i.e.,:
>>
>> OLD:
>>
>>   registry of WebSocket sub-protocols
>>
>> NEW:
>>
>>   WebSocket Subprotocol Name Registry
>>
>>
>>
>> 7) Section 11. There is also a Reference field in that IANA registry. I
>> would suggest you use the same information as the pointer to the
>> Subprotocol Definition (i.e., this RFC).
>>
>>
>>
>> 8) It's typical for documents that are updating existing RFCs to have a
>> section that summarizes the updates to the existing RFCs that are made b=
y
>> this document.
>>
>>
>>
>>
>>
>>
>>
>> On Thu, Dec 12, 2013 at 6:57 PM,  wrote:
>>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>>
>>
>>         Title           : The WebSocket Protocol as a Transport for the
>> Message Session Relay Protocol (MSRP)
>>         Author(s)       : Peter Dunkley
>>                           Gavin Llewellyn
>>                           Victor Pascual
>>                           Anton Roman
>>                           Gonzalo Salgueiro
>>         Filename        : draft-pd-dispatch-msrp-websocket-03.txt
>>         Pages           : 21
>>         Date            : 2013-12-12
>>
>> Abstract:
>>    The WebSocket protocol enables two-way real-time communication
>>    between clients and servers.  This document specifies a new WebSocket
>>    sub-protocol as a reliable transport mechanism between MSRP (Message
>>    Session Relay Protocol) clients and relays to enable usage of MSRP in
>>    new scenarios.  This document normatively updates RFC 4975 and RFC
>>    4976.
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-pd-dispatch-msrp-websocket
>>
>> There's also a htmlized version available at:
>> http://tools.ietf.org/html/draft-pd-dispatch-msrp-websocket-03
>>
>> A diff from the previous version is available at:
>> http://www.ietf.org/rfcdiff?url2=3Ddraft-pd-dispatch-msrp-websocket-03
>>
>>
>> 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.
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> _______________________________________________
>> I-D-Announce mailing list
>> I-D-Announce@ietf.org
>> https://www.ietf.org/mailman/listinfo/i-d-announce
>> Internet-Draftdirectories:
>> http://www.ietf.org/shadow.html
>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>
>>
>>
>
>
>
>  --
>  Peter Dunkley
> Technical Director
> Crocodile RCS Ltd
>



--=20
Peter Dunkley
Technical Director
Crocodile RCS Ltd

--089e0122ab746a930a04f063bea1
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable


Hi Christer,

There is working code for the documen=
t as-is and plans for more implementations. I think that if someone has a n=
eed for MSRP-CEMA in this scenario then they should join with the current a=
uthors to contribute the text and working code for this.



Regards,

Peter


On 20 January 201=
4 03:28, Christer Holmberg <christer.holmberg@ericsson.com> wrote:









Hi,

I see no reason why it should be a separate document, as it should not have=
 any affect on the websocket specific procedures, which is the main scope o=
f the document.

Regards,

Christer

Sent from my Sony Ericsson Xperia arc S

Peter Dunkley <peter.dunkley@crocodilertc.net> wrote:






Hello,






Perhaps the document title should be corrected. MSRP-CEMA is outside o=
f the scope of this document as this document is intended to describe conne=
cting to a WebSocket server that is an MSRP relay.







I can see no reason why MSRP-CEMA can't be used over WebSockets, b=
ut if anyone has an interest in this I think that they should put it in a d=
ocument of its own.












Regards,







Peter









On 18 January 2014 08:52, Christer Holmberg 
<chr=
ister.holmberg@ericsson.com> wrote:








Hi,<=
/p>

=A0<=
/p>

I have not=
 followed the work on this draft, so I appologize if the following has been=
 discussed.



=A0=



While I do=
 understand that a WS Client has to establish the WebSocket with the Web Se=
rver, I don=92t understand why we need to mandate the WS Server
 to be an MSRP Relay. That would e.g. prevent the usage of MSRP-CEMA.


=A0=



Regards,


=A0=



Christer


=A0=



=A0=



=A0=



L=E4hett=E4j=E4: dispatch [mailto:dispatch-bounces@ietf.org]
Puolesta Mary Barnes

L=E4hetetty: 11. tammikuuta 2014 0:59

Vastaanottaja: DISPATCH

Kopio: Ben Campbell; 
draft-pd-dispatch-msrp-websocket@tools.ietf.org

Aihe: Re: [dispatch] I-D Action: draft-pd-dispatch-msrp-websocket-03=
.txt






=A0




I have agreed to shepherd this document. =A0I've=
 reviewed the document in anticipation of doing the PROTO write-up and have=
 the following comments and questions. =A0Ben Campbell has agreed to do the=
 required expert review and that should be
 posted within the next week or so. =A0 =A0This is also a good time for any=
one in the WG that hasn't previously reviewed this document to review a=
nd provide any final comments. =A0Note, that this document was agreed to be=
 AD sponsored around the IETF-86 timeframe.





=A0






Regards,






Mary.=A0






=A0








Review Summary: Almost ready. Comments & questio=
ns below.






=A0






1) =A0Section 2 & General. =A0I'm not sure t=
he documented approach for separating normative text from non-normative is =
quite so helpful. =A0In general, we expect that in the case of standards tr=
ack document use RFC 2119 language to indicate normative
 behaviors. =A0I think the first sentence is good, but that's not a ter=
minology thing. =A0 I just don't see a lot of value in writing the docu=
ment this way. =A0For example, the definitions aren't stated to be non-=
normative, but I don't see anything normative about
 the definitions. =A0I think you could easily title Section 3 as "WebS=
ocket Protocol overview" and that would clearly imply non-normative be=
havior. =A0There are also several places in the document in sections that I=
 believe are intended to provide normative behavior,
 but there is certainly non-normative text in those sections (e.g., section=
 5.2.2, second paragraph). =A0I would suggest this document follow the typi=
cal (and accepted) style of identifying normative behavior with 2119 langua=
ge (consistently using upper case
 for normative behavior and avoiding using 2119 language in cases where alt=
ernative words can be substituted).






=A0






2) Section 5.2.2, 2nd paragraph. =A0Related to my po=
int above, it's not clear to me this is normative behavior. =A0I don=
9;t think it is since it's referring to existing 4975 behavior. However=
, I didn't see that the reference given in 4975 relates
 to the second part of that sentence stating that implementations "sho=
uld" already be allowing unrecognized transports. =A0It would be quite=
 useful to have the exact reference here as I was trying to double check th=
is point and I couldn't find it.=A0







=A0






3) Section 6. =A0I'm really puzzled as to why th=
e Connection Keep-alive would be non-normative. =A0In particular given that=
 2119 language is clearly being used. =A0






=A0






4) Section 7. =A0Again, I'm puzzled as to why Au=
thentication is considered non-normative. AGain, you have 2119 language in =
this section. =A0






=A0






5) Section 10.1. Since securing the connection is ju=
st RECOMMENDED, what are the implications and risks if the MSRP traffic isn=
't transported over a secure connection?=A0






=A0






6) Section 11. =A0You should change the name of the =
registry to be the exact name of the IANA registry to avoid any confusion.-=
 i.e.,:






OLD:






=A0 registry of WebSocket sub-protocols






NEW:=A0






=A0 WebSocket Subprotocol Name Registry =A0






=A0






7) Section 11. There is also a Reference field in th=
at IANA registry. I would suggest you use the same information as the point=
er to the Subprotocol Definition (i.e., this RFC).=A0






=A0






8) It's typical for documents that are updating =
existing RFCs to have a section that summarizes the updates to the existing=
 RFCs that are made by this document. =A0






=A0






=A0








=A0




On Thu, Dec 12, 2013 at 6:57 PM, <internet-drafts@ietf.org=
> wrote:




A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.





=A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : The WebSocket Protocol as a Tra=
nsport for the Message Session Relay Protocol (MSRP)

=A0 =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Peter Dunkley

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Gavin Llewellyn

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Victor Pascual

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Anton Roman

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Gonzalo Salgueiro

=A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-pd-dispatch-msrp-websocket-=
03.txt

=A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 21

=A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2013-12-12



Abstract:

=A0 =A0The WebSocket protocol enables two-way real-time communication

=A0 =A0between clients and servers. =A0This document specifies a new WebSoc=
ket

=A0 =A0sub-protocol as a reliable transport mechanism between MSRP (Message=


=A0 =A0Session Relay Protocol) clients and relays to enable usage of MSRP i=
n

=A0 =A0new scenarios. =A0This document normatively updates RFC 4975 and RFC=


=A0 =A04976.





The IETF datatracker status page for this draft is:

https://datatracker.ietf.org/doc/draft-pd-dispatch-msr=
p-websocket



There's also a htmlized version available at:

http://tools.ietf.org/html/draft-pd-dispatch-msrp-websock=
et-03



A diff from the previous version is available at:

http://www.ietf.org/rfcdiff?url2=3Ddraft-pd-dispa=
tch-msrp-websocket-03





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.



Internet-Drafts are also available by anonymous FTP at:

ftp://ftp=
.ietf.org/internet-drafts/



_______________________________________________

I-D-Announce mailing list

I-D-Announce@iet=
f.org

https://www.ietf.org/mailman/listinfo/i-d-announce

Internet-Draft directories: 
http://www.ietf.org/shadow.html

or =
ftp://ftp.ietf.org/ietf/1shadow-sites.txt




=A0


























-- 




Peter Dunkley


Technical Director


Crocodile RCS Ltd














-- 
Peter Dunkley
<=
div>Technical Director

Crocodile RCS Ltd


--089e0122ab746a930a04f063bea1--

From christer.holmberg@ericsson.com  Mon Jan 20 01:55:30 2014
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 811361A00BA for ; Mon, 20 Jan 2014 01:55:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.85
X-Spam-Level: 
X-Spam-Status: No, score=-3.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 BGe2HQJp5gfx for ; Mon, 20 Jan 2014 01:55:25 -0800 (PST)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 7AAE41A00B3 for ; Mon, 20 Jan 2014 01:55:24 -0800 (PST)
X-AuditID: c1b4fb2d-b7f1c8e000005ceb-2e-52dcf28be724
Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id F8.24.23787.B82FCD25; Mon, 20 Jan 2014 10:55:24 +0100 (CET)
Received: from ESESSMB209.ericsson.se ([169.254.9.114]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.02.0387.000; Mon, 20 Jan 2014 10:55:19 +0100
From: Christer Holmberg 
To: Peter Dunkley 
Thread-Topic: [dispatch] I-D Action: draft-pd-dispatch-msrp-websocket-03.txt
Thread-Index: AQHPDleQGzr1Sxm0FkKTa2Dy1OUwAJqKNznggAHW2ICAAPS5P4AAWE2AgAAStzA=
Date: Mon, 20 Jan 2014 09:55:18 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1D10A3A1@ESESSMB209.ericsson.se>
References: <20131213005747.777.34301.idtracker@ietfa.amsl.com>  <7594FB04B1934943A5C02806D1A2204B1D104D91@ESESSMB209.ericsson.se>   
In-Reply-To: 
Accept-Language: en-US
Content-Language: fi-FI
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.150]
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D10A3A1ESESSMB209erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphkeLIzCtJLcpLzFFi42KZGfG3Rrfn050gg87rXBbND3+xWSydtIDV 4vKWz+wWn/fvZ7Y4v30bkwOrx6OeUI/HX2exeuycdZfdY8mSn0weXy5/ZgtgjeKySUnNySxL LdK3S+DK+PP2MWvBpQ6mioV7LzI2MH59xtjFyMkhIWAi8fPlYTYIW0ziwr31YLaQwCFGiT0H PbsYuYDsJYwSZ95fBkpwcLAJWEh0/9MGqRERMJJYsWAlK0gNs8A1RolP1+czgSSEBbwlpix/ ywxR5CNxc/sBJgjbT+LPle1gcRYBVYmTGztYQWxeAV+J5kuPmSCWTWWW2PDnKdh1nAKBEhue b2AHsRmBrvt+ag3YIGYBcYkPB68zQ1wtILFkz3koW1Ti5eN/rBC2ksSK7ZcYIerzJS5NnMEG sUxQ4uTMJywTGEVnIRk1C0nZLCRlEHE9iRtTp7BB2NoSyxa+hqrXlZjx7xALsvgCRvZVjOy5 iZk56eWGmxiBMXlwy2/dHYynzokcYpTmYFES5/3w1jlISCA9sSQ1OzW1ILUovqg0J7X4ECMT B6dUA6PLsgcHL9n98VlZtSvB+y5/nctB687lkS/f3Y3JuFnxcX/EtNMnki9vP2Xp18rHLcPU ydl28fCa9k/znjXknxfeZ+Gz2N5M/mvsnf/F/Ixz3K9eSj2RbjrRco/KVB1Z7b4NxwUlWBRt 8q+eXfBvxZIXHT8mOcq3scvv/3Lf/Zrnl0NeXxgaX85XYinOSDTUYi4qTgQAy0FhSZcCAAA=
Cc: DISPATCH , Ben Campbell , "draft-pd-dispatch-msrp-websocket@tools.ietf.org" 
Subject: Re: [dispatch] I-D Action: draft-pd-dispatch-msrp-websocket-03.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: Mon, 20 Jan 2014 09:55:30 -0000

--_000_7594FB04B1934943A5C02806D1A2204B1D10A3A1ESESSMB209erics_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Peter,

I am willing to help, and contribute text.

But, I request that we don't move the document forward before I've had a ch=
ance to do that :)

(3GPP also has a requirement to specify the usage of MSRP over WebSocket.)

Regards,

Christer

L=E4hett=E4j=E4: Peter Dunkley [mailto:peter.dunkley@crocodilertc.net]
L=E4hetetty: 20. tammikuuta 2014 11:45
Vastaanottaja: Christer Holmberg
Kopio: Mary Barnes; DISPATCH; Ben Campbell; draft-pd-dispatch-msrp-websocke=
t@tools.ietf.org
Aihe: Re: [dispatch] I-D Action: draft-pd-dispatch-msrp-websocket-03.txt

Hi Christer,

There is working code for the document as-is and plans for more implementat=
ions. I think that if someone has a need for MSRP-CEMA in this scenario the=
n they should join with the current authors to contribute the text and work=
ing code for this.

Regards,

Peter

On 20 January 2014 03:28, Christer Holmberg > wrote:

Hi,



I see no reason why it should be a separate document, as it should not have=
 any affect on the websocket specific procedures, which is the main scope o=
f the document.



Regards,



Christer



Sent from my Sony Ericsson Xperia arc S



Peter Dunkley > wrote:


Hello,

Perhaps the document title should be corrected. MSRP-CEMA is outside of the=
 scope of this document as this document is intended to describe connecting=
 to a WebSocket server that is an MSRP relay.

I can see no reason why MSRP-CEMA can't be used over WebSockets, but if any=
one has an interest in this I think that they should put it in a document o=
f its own.


Regards,

Peter

On 18 January 2014 08:52, Christer Holmberg > wrote:
Hi,

I have not followed the work on this draft, so I appologize if the followin=
g has been discussed.

While I do understand that a WS Client has to establish the WebSocket with =
the Web Server, I don't understand why we need to mandate the WS Server to =
be an MSRP Relay. That would e.g. prevent the usage of MSRP-CEMA.

Regards,

Christer



L=E4hett=E4j=E4: dispatch [mailto:dispatch-bounces@ietf.org] Puolesta Mary Barnes
L=E4hetetty: 11. tammikuuta 2014 0:59
Vastaanottaja: DISPATCH
Kopio: Ben Campbell; draft-pd-dispatch-msrp-websocket@tools.ietf.org
Aihe: Re: [dispatch] I-D Action: draft-pd-dispatch-msrp-websocket-03.txt

I have agreed to shepherd this document.  I've reviewed the document in ant=
icipation of doing the PROTO write-up and have the following comments and q=
uestions.  Ben Campbell has agreed to do the required expert review and tha=
t should be posted within the next week or so.    This is also a good time =
for anyone in the WG that hasn't previously reviewed this document to revie=
w and provide any final comments.  Note, that this document was agreed to b=
e AD sponsored around the IETF-86 timeframe.

Regards,
Mary.

Review Summary: Almost ready. Comments & questions below.

1)  Section 2 & General.  I'm not sure the documented approach for separati=
ng normative text from non-normative is quite so helpful.  In general, we e=
xpect that in the case of standards track document use RFC 2119 language to=
 indicate normative behaviors.  I think the first sentence is good, but tha=
t's not a terminology thing.   I just don't see a lot of value in writing t=
he document this way.  For example, the definitions aren't stated to be non=
-normative, but I don't see anything normative about the definitions.  I th=
ink you could easily title Section 3 as "WebSocket Protocol overview" and t=
hat would clearly imply non-normative behavior.  There are also several pla=
ces in the document in sections that I believe are intended to provide norm=
ative behavior, but there is certainly non-normative text in those sections=
 (e.g., section 5.2.2, second paragraph).  I would suggest this document fo=
llow the typical (and accepted) style of identifying normative behavior wit=
h 2119 language (consistently using upper case for normative behavior and a=
voiding using 2119 language in cases where alternative words can be substit=
uted).

2) Section 5.2.2, 2nd paragraph.  Related to my point above, it's not clear=
 to me this is normative behavior.  I don't think it is since it's referrin=
g to existing 4975 behavior. However, I didn't see that the reference given=
 in 4975 relates to the second part of that sentence stating that implement=
ations "should" already be allowing unrecognized transports.  It would be q=
uite useful to have the exact reference here as I was trying to double chec=
k this point and I couldn't find it.

3) Section 6.  I'm really puzzled as to why the Connection Keep-alive would=
 be non-normative.  In particular given that 2119 language is clearly being=
 used.

4) Section 7.  Again, I'm puzzled as to why Authentication is considered no=
n-normative. AGain, you have 2119 language in this section.

5) Section 10.1. Since securing the connection is just RECOMMENDED, what ar=
e the implications and risks if the MSRP traffic isn't transported over a s=
ecure connection?

6) Section 11.  You should change the name of the registry to be the exact =
name of the IANA registry to avoid any confusion.- i.e.,:
OLD:
  registry of WebSocket sub-protocols
NEW:
  WebSocket Subprotocol Name Registry

7) Section 11. There is also a Reference field in that IANA registry. I wou=
ld suggest you use the same information as the pointer to the Subprotocol D=
efinition (i.e., this RFC).

8) It's typical for documents that are updating existing RFCs to have a sec=
tion that summarizes the updates to the existing RFCs that are made by this=
 document.



On Thu, Dec 12, 2013 at 6:57 PM, > wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.


        Title           : The WebSocket Protocol as a Transport for the Mes=
sage Session Relay Protocol (MSRP)
        Author(s)       : Peter Dunkley
                          Gavin Llewellyn
                          Victor Pascual
                          Anton Roman
                          Gonzalo Salgueiro
        Filename        : draft-pd-dispatch-msrp-websocket-03.txt
        Pages           : 21
        Date            : 2013-12-12

Abstract:
   The WebSocket protocol enables two-way real-time communication
   between clients and servers.  This document specifies a new WebSocket
   sub-protocol as a reliable transport mechanism between MSRP (Message
   Session Relay Protocol) clients and relays to enable usage of MSRP in
   new scenarios.  This document normatively updates RFC 4975 and RFC
   4976.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-pd-dispatch-msrp-websocket

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-pd-dispatch-msrp-websocket-03

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-pd-dispatch-msrp-websocket-03


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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt




--
Peter Dunkley
Technical Director
Crocodile RCS Ltd



--
Peter Dunkley
Technical Director
Crocodile RCS Ltd

--_000_7594FB04B1934943A5C02806D1A2204B1D10A3A1ESESSMB209erics_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Hi Peter,<=
o:p>


 =
;


I am willi=
ng to help, and contribute text.


 =
;


But, I req=
uest that we don’t move the document forward before I’ve had a =
chance to do that :)


 =
;


(3GPP also=
 has a requirement to specify the usage of MSRP over WebSocket.)=



 =
;


Regards,


 =
;


Christer


 =
;


L=E4hett=E4j=E4: Peter Dunkley [mailto:peter.dunkley@crocodilertc.net]


L=E4hetetty: 20. tammikuuta 2014 11:45

Vastaanottaja: Christer Holmberg

Kopio: Mary Barnes; DISPATCH; Ben Campbell; draft-pd-dispatch-msrp-w=
ebsocket@tools.ietf.org

Aihe: Re: [dispatch] I-D Action: draft-pd-dispatch-msrp-websocket-03=
.txt


 




Hi Christer,






There is working code for the document as-is and plans for more implementat=
ions. I think that if someone has a need for MSRP-CEMA in this scenario the=
n they should join with the current authors to contribute the text and work=
ing code for this.






 






Regards,






 






Peter








 




On 20 January 2014 03:28, Christer Holmberg <christer.ho=
lmberg@ericsson.com> wrote:




Hi,


=
 


=
I see no reason why it should be a separate document, as it should not have=
 any affect on the websocket specific procedures, which is the main scope o=
f the document.


=
 


=
Regards,


=
 


=
Christer


=
 


=
Sent from my Sony Ericsson Xperia arc S


=
 


=
Peter Dunkley <peter.dunkley@crocodilertc.net> wrote:=



=
 










Hello, 




 






Perhaps the document title should be corrected. MSRP=
-CEMA is outside of the scope of this document as this document is intended=
 to describe connecting to a WebSocket server that is an MSRP relay.






 






I can see no reason why MSRP-CEMA can't be used over=
 WebSockets, but if anyone has an interest in this I think that they should=
 put it in a document of its own.






 






 






Regards,






 






Peter








 




On 18 January 2014 08:52, Christer Holmberg <christer.ho=
lmberg@ericsson.com> wrote:






Hi,


 


I have not followed the =
work on this draft, so I appologize if the following has been
 discussed.


 =



While I do understand th=
at a WS Client has to establish the WebSocket with the Web Server,
 I don’t understand why we need to mandate the WS Server to be an MSR=
P Relay. That would e.g. prevent the usage of MSRP-CEMA.<=
/p>

 =



Regards,


 =



Christer


 =



 =



 =



L=E4hett=E4j=E4: dispatch [m=
ailto:dispat=
ch-bounces@ietf.org]
Puolesta Mary Barnes

L=E4hetetty: 11. tammikuuta 2014 0:59

Vastaanottaja: DISPATCH

Kopio: Ben Campbell; 
draft-pd-dispatch-msrp-websocket@tools.ietf.org

Aihe: Re: [dispatch] I-D Action: draft-pd-dispatch-msrp-websocket-03=
.txt






 




I have agreed to shepherd this document.  I've reviewed the d=
ocument in anticipation of doing the PROTO write-up and have the following =
comments and questions.  Ben Campbell has
 agreed to do the required expert review and that should be posted within t=
he next week or so.    This is also a good time for anyone in the=
 WG that hasn't previously reviewed this document to review and provide any=
 final comments.  Note, that this document
 was agreed to be AD sponsored around the IETF-86 timeframe.




 






Regards,






Mary. 






 








Review Summary: Almost ready. Comments & questions below.=







 






1)  Section 2 & General.  I'm not sure the documente=
d approach for separating normative text from non-normative is quite so hel=
pful.  In general, we expect that in the case of standards
 track document use RFC 2119 language to indicate normative behaviors. &nbs=
p;I think the first sentence is good, but that's not a terminology thing. &=
nbsp; I just don't see a lot of value in writing the document this way. &nb=
sp;For example, the definitions aren't stated to
 be non-normative, but I don't see anything normative about the definitions=
.  I think you could easily title Section 3 as "WebSocket Protoco=
l overview" and that would clearly imply non-normative behavior.  =
;There are also several places in the document in sections
 that I believe are intended to provide normative behavior, but there is ce=
rtainly non-normative text in those sections (e.g., section 5.2.2, second p=
aragraph).  I would suggest this document follow the typical (and acce=
pted) style of identifying normative
 behavior with 2119 language (consistently using upper case for normative b=
ehavior and avoiding using 2119 language in cases where alternative words c=
an be substituted).






 






2) Section 5.2.2, 2nd paragraph.  Related to my point above, =
it's not clear to me this is normative behavior.  I don't think it is =
since it's referring to existing 4975 behavior.
 However, I didn't see that the reference given in 4975 relates to the seco=
nd part of that sentence stating that implementations "should" al=
ready be allowing unrecognized transports.  It would be quite useful t=
o have the exact reference here as I was trying
 to double check this point and I couldn't find it. 






 






3) Section 6.  I'm really puzzled as to why the Connection Ke=
ep-alive would be non-normative.  In particular given that 2119 langua=
ge is clearly being used.  






 






4) Section 7.  Again, I'm puzzled as to why Authentication is=
 considered non-normative. AGain, you have 2119 language in this section. &=
nbsp;






 






5) Section 10.1. Since securing the connection is just RECOMMENDED=
, what are the implications and risks if the MSRP traffic isn't transported=
 over a secure connection? 






 






6) Section 11.  You should change the name of the registry to=
 be the exact name of the IANA registry to avoid any confusion.- i.e.,:






OLD:






  registry of WebSocket sub-protocols






NEW: 






  WebSocket Subprotocol Name Registry  






 






7) Section 11. There is also a Reference field in that IANA regist=
ry. I would suggest you use the same information as the pointer to the Subp=
rotocol Definition (i.e., this RFC). 






 






8) It's typical for documents that are updating existing RFCs to h=
ave a section that summarizes the updates to the existing RFCs that are mad=
e by this document.  






 






 








 




On Thu, Dec 12, 2013 at 6:57 PM, <internet-drafts@ietf.org> wrote:




A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.





        Title           : The =
WebSocket Protocol as a Transport for the Message Session Relay Protocol (M=
SRP)

        Author(s)       : Peter Dunkley<=
br>
                     =
;     Gavin Llewellyn

                     =
;     Victor Pascual

                     =
;     Anton Roman

                     =
;     Gonzalo Salgueiro

        Filename        : draft-pd-=
dispatch-msrp-websocket-03.txt

        Pages           : 21
        Date            :=
 2013-12-12



Abstract:

   The WebSocket protocol enables two-way real-time communication=


   between clients and servers.  This document specifies a n=
ew WebSocket

   sub-protocol as a reliable transport mechanism between MSRP (M=
essage

   Session Relay Protocol) clients and relays to enable usage of =
MSRP in

   new scenarios.  This document normatively updates RFC 497=
5 and RFC

   4976.





The IETF datatracker status page for this draft is:

https://datatracker.ietf.org/doc/draft-pd-dispatch-msr=
p-websocket



There's also a htmlized version available at:

http://tools.ietf.org/html/draft-pd-dispatch-msrp-websock=
et-03



A diff from the previous version is available at:

http://www.ietf.org/rfcdiff?url2=3Ddraft-pd-dispa=
tch-msrp-websocket-03





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.



Internet-Drafts are also available by anonymous FTP at:

ftp://ftp=
.ietf.org/internet-drafts/



_______________________________________________

I-D-Announce mailing list

I-D-Announce@iet=
f.org

https://www.ietf.org/mailman/listinfo/i-d-announce

Internet-Draft directories: 
http://www.ietf.org/shadow.html

or =
ftp://ftp.ietf.org/ietf/1shadow-sites.txt




 

























 




-- 






=
Peter Dunkley






=
Technical Director






=
Crocodile RCS Ltd



























 




-- 






=
Peter Dunkley






=
Technical Director






=
Crocodile RCS Ltd












--_000_7594FB04B1934943A5C02806D1A2204B1D10A3A1ESESSMB209erics_--

From christer.holmberg@ericsson.com  Tue Jan 21 00:43:28 2014
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 A87AC1A009D for ; Tue, 21 Jan 2014 00:43:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.85
X-Spam-Level: 
X-Spam-Status: No, score=-3.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 V_5CsiSGCaav for ; Tue, 21 Jan 2014 00:43:23 -0800 (PST)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 9EEE91A006B for ; Tue, 21 Jan 2014 00:43:22 -0800 (PST)
X-AuditID: c1b4fb25-b7f038e000005d01-c4-52de332903d9
Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id B3.FA.23809.9233ED25; Tue, 21 Jan 2014 09:43:21 +0100 (CET)
Received: from ESESSMB209.ericsson.se ([169.254.9.114]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.02.0387.000; Tue, 21 Jan 2014 09:43:21 +0100
From: Christer Holmberg 
To: Christer Holmberg , Peter Dunkley 
Thread-Topic: [dispatch] I-D Action: draft-pd-dispatch-msrp-websocket-03.txt
Thread-Index: AQHPDleQGzr1Sxm0FkKTa2Dy1OUwAJqKNznggAHW2ICAAPS5P4AAWE2AgAAStzCAAX6poA==
Date: Tue, 21 Jan 2014 08:43:20 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1D11137F@ESESSMB209.ericsson.se>
References: <20131213005747.777.34301.idtracker@ietfa.amsl.com>  <7594FB04B1934943A5C02806D1A2204B1D104D91@ESESSMB209.ericsson.se>    <7594FB04B1934943A5C02806D1A2204B1D10A3A1@ESESSMB209.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D10A3A1@ESESSMB209.ericsson.se>
Accept-Language: en-US
Content-Language: fi-FI
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.154]
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D11137FESESSMB209erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJLMWRmVeSWpSXmKPExsUyM+Jvja6m8b0gg6uv1S2aH/5is1g6aQGr xeUtn9ktzm/fxuTA4vGoJ9Tj8ddZrB5Llvxk8vhy+TNbAEsUl01Kak5mWWqRvl0CV8bKLQfZ Cm4sZarYd7SfpYHxUSNTFyMHh4SAiURfi28XIyeQKSZx4d56ti5GLg4hgUOMEpvO/IRyljBK HHu4nBmkgU3AQqL7nzZIg4hAhsTuvqVgNcwCqxglNlxZxwaSEBbwlpiy/C0zRJGPxM3tB8CW iQiESZw8qQgSZhFQldh+Yz8jiM0r4Cvx6FAfO8Sum8wSyy4cBevlFPCTWNx2iR3EZgS67vup NUwgNrOAuMSHg9eZIa4WkFiy5zyULSrx8vE/VghbSWLR7c9Q9fkSW49uYoZYJihxcuYTlgmM orOQjJqFpGwWkjKIuJ7EjalT2CBsbYllC19D1etKzPh3iAVZfAEj+ypG9tzEzJz0cqNNjMDo O7jlt+oOxjvnRA4xSnOwKInzfnjrHCQkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBUYedY8HF piXtWzMzqjzWq7o8SbBiMrtYk6lVMm/31+2Zht+faLZfPRPRlH9oktK+M6nrLrbbaeunzPZf dvbxKWbWKa4x1uFLeoPVFk7r+n5zYpHFw/DfmXkL9dYbeabt4K0+Ix31b/aiuzm5sh88WGRu KdelMrudfH5ugrOtlrXIUQ93sdzJSizFGYmGWsxFxYkA0JHdbIwCAAA=
Cc: Ben Campbell , DISPATCH , "draft-pd-dispatch-msrp-websocket@tools.ietf.org" 
Subject: Re: [dispatch] I-D Action: draft-pd-dispatch-msrp-websocket-03.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, 21 Jan 2014 08:43:28 -0000

--_000_7594FB04B1934943A5C02806D1A2204B1D11137FESESSMB209erics_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,

I made a false statement earlier, regarding 3GPP.

3GPP does not have requirement to transport MSRP over WebSocket.

Sorry for the confusion.

Regards,

Christer

L=E4hett=E4j=E4: dispatch [mailto:dispatch-bounces@ietf.org] Puolesta Chris=
ter Holmberg
L=E4hetetty: 20. tammikuuta 2014 11:55
Vastaanottaja: Peter Dunkley
Kopio: DISPATCH; Ben Campbell; draft-pd-dispatch-msrp-websocket@tools.ietf.=
org
Aihe: Re: [dispatch] I-D Action: draft-pd-dispatch-msrp-websocket-03.txt

Hi Peter,

I am willing to help, and contribute text.

But, I request that we don't move the document forward before I've had a ch=
ance to do that :)

(3GPP also has a requirement to specify the usage of MSRP over WebSocket.)

Regards,

Christer

L=E4hett=E4j=E4: Peter Dunkley [mailto:peter.dunkley@crocodilertc.net]
L=E4hetetty: 20. tammikuuta 2014 11:45
Vastaanottaja: Christer Holmberg
Kopio: Mary Barnes; DISPATCH; Ben Campbell; draft-pd-dispatch-msrp-websocke=
t@tools.ietf.org
Aihe: Re: [dispatch] I-D Action: draft-pd-dispatch-msrp-websocket-03.txt

Hi Christer,

There is working code for the document as-is and plans for more implementat=
ions. I think that if someone has a need for MSRP-CEMA in this scenario the=
n they should join with the current authors to contribute the text and work=
ing code for this.

Regards,

Peter

On 20 January 2014 03:28, Christer Holmberg > wrote:

Hi,



I see no reason why it should be a separate document, as it should not have=
 any affect on the websocket specific procedures, which is the main scope o=
f the document.



Regards,



Christer



Sent from my Sony Ericsson Xperia arc S



Peter Dunkley > wrote:


Hello,

Perhaps the document title should be corrected. MSRP-CEMA is outside of the=
 scope of this document as this document is intended to describe connecting=
 to a WebSocket server that is an MSRP relay.

I can see no reason why MSRP-CEMA can't be used over WebSockets, but if any=
one has an interest in this I think that they should put it in a document o=
f its own.


Regards,

Peter

On 18 January 2014 08:52, Christer Holmberg > wrote:
Hi,

I have not followed the work on this draft, so I appologize if the followin=
g has been discussed.

While I do understand that a WS Client has to establish the WebSocket with =
the Web Server, I don't understand why we need to mandate the WS Server to =
be an MSRP Relay. That would e.g. prevent the usage of MSRP-CEMA.

Regards,

Christer



L=E4hett=E4j=E4: dispatch [mailto:dispatch-bounces@ietf.org] Puolesta Mary Barnes
L=E4hetetty: 11. tammikuuta 2014 0:59
Vastaanottaja: DISPATCH
Kopio: Ben Campbell; draft-pd-dispatch-msrp-websocket@tools.ietf.org
Aihe: Re: [dispatch] I-D Action: draft-pd-dispatch-msrp-websocket-03.txt

I have agreed to shepherd this document.  I've reviewed the document in ant=
icipation of doing the PROTO write-up and have the following comments and q=
uestions.  Ben Campbell has agreed to do the required expert review and tha=
t should be posted within the next week or so.    This is also a good time =
for anyone in the WG that hasn't previously reviewed this document to revie=
w and provide any final comments.  Note, that this document was agreed to b=
e AD sponsored around the IETF-86 timeframe.

Regards,
Mary.

Review Summary: Almost ready. Comments & questions below.

1)  Section 2 & General.  I'm not sure the documented approach for separati=
ng normative text from non-normative is quite so helpful.  In general, we e=
xpect that in the case of standards track document use RFC 2119 language to=
 indicate normative behaviors.  I think the first sentence is good, but tha=
t's not a terminology thing.   I just don't see a lot of value in writing t=
he document this way.  For example, the definitions aren't stated to be non=
-normative, but I don't see anything normative about the definitions.  I th=
ink you could easily title Section 3 as "WebSocket Protocol overview" and t=
hat would clearly imply non-normative behavior.  There are also several pla=
ces in the document in sections that I believe are intended to provide norm=
ative behavior, but there is certainly non-normative text in those sections=
 (e.g., section 5.2.2, second paragraph).  I would suggest this document fo=
llow the typical (and accepted) style of identifying normative behavior wit=
h 2119 language (consistently using upper case for normative behavior and a=
voiding using 2119 language in cases where alternative words can be substit=
uted).

2) Section 5.2.2, 2nd paragraph.  Related to my point above, it's not clear=
 to me this is normative behavior.  I don't think it is since it's referrin=
g to existing 4975 behavior. However, I didn't see that the reference given=
 in 4975 relates to the second part of that sentence stating that implement=
ations "should" already be allowing unrecognized transports.  It would be q=
uite useful to have the exact reference here as I was trying to double chec=
k this point and I couldn't find it.

3) Section 6.  I'm really puzzled as to why the Connection Keep-alive would=
 be non-normative.  In particular given that 2119 language is clearly being=
 used.

4) Section 7.  Again, I'm puzzled as to why Authentication is considered no=
n-normative. AGain, you have 2119 language in this section.

5) Section 10.1. Since securing the connection is just RECOMMENDED, what ar=
e the implications and risks if the MSRP traffic isn't transported over a s=
ecure connection?

6) Section 11.  You should change the name of the registry to be the exact =
name of the IANA registry to avoid any confusion.- i.e.,:
OLD:
  registry of WebSocket sub-protocols
NEW:
  WebSocket Subprotocol Name Registry

7) Section 11. There is also a Reference field in that IANA registry. I wou=
ld suggest you use the same information as the pointer to the Subprotocol D=
efinition (i.e., this RFC).

8) It's typical for documents that are updating existing RFCs to have a sec=
tion that summarizes the updates to the existing RFCs that are made by this=
 document.



On Thu, Dec 12, 2013 at 6:57 PM, > wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.


        Title           : The WebSocket Protocol as a Transport for the Mes=
sage Session Relay Protocol (MSRP)
        Author(s)       : Peter Dunkley
                          Gavin Llewellyn
                          Victor Pascual
                          Anton Roman
                          Gonzalo Salgueiro
        Filename        : draft-pd-dispatch-msrp-websocket-03.txt
        Pages           : 21
        Date            : 2013-12-12

Abstract:
   The WebSocket protocol enables two-way real-time communication
   between clients and servers.  This document specifies a new WebSocket
   sub-protocol as a reliable transport mechanism between MSRP (Message
   Session Relay Protocol) clients and relays to enable usage of MSRP in
   new scenarios.  This document normatively updates RFC 4975 and RFC
   4976.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-pd-dispatch-msrp-websocket

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-pd-dispatch-msrp-websocket-03

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-pd-dispatch-msrp-websocket-03


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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt




--
Peter Dunkley
Technical Director
Crocodile RCS Ltd



--
Peter Dunkley
Technical Director
Crocodile RCS Ltd

--_000_7594FB04B1934943A5C02806D1A2204B1D11137FESESSMB209erics_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Hi,


 <=
/p>

I made a f=
alse statement earlier, regarding 3GPP.


 =
;


3GPP does =
not have requirement to transport MSRP over WebSocket.

 =
;


Sorry for =
the confusion.


 =
;


Regards,


 =
;


Christer


 =
;






L=E4hett=E4j=E4: dispatch [mailto:dispatch-bounces@ietf.org]
Puolesta Christer Holmberg

L=E4hetetty: 20. tammikuuta 2014 11:55

Vastaanottaja: Peter Dunkley

Kopio: DISPATCH; Ben Campbell; draft-pd-dispatch-msrp-websocket@tool=
s.ietf.org

Aihe: Re: [dispatch] I-D Action: draft-pd-dispatch-msrp-websocket-03=
.txt






 


Hi Peter,<=
/span>


 


I am willi=
ng to help, and contribute text.


 


But, I req=
uest that we don’t move the document forward before I’ve had a =
chance to do that :)


 


(3GPP also=
 has a requirement to specify the usage of MSRP over WebSocket.)


 


Regards,


 


Christer


 


L=E4hett=E4j=E4: Peter Dunkley [mailto:=
peter.dunkley@crocodilertc.net]


L=E4hetetty: 20. tammikuuta 2014 11:45

Vastaanottaja: Christer Holmberg

Kopio: Mary Barnes; DISPATCH; Ben Campbell; 
draft-pd-dispatch-msrp-websocket@tools.ietf.org

Aihe: Re: [dispatch] I-D Action: draft-pd-dispatch-msrp-websocket-03=
.txt


 




Hi Christer,






There is working code for the document as-is and plans for more implementat=
ions. I think that if someone has a need for MSRP-CEMA in this scenario the=
n they should join with the current authors to contribute the text and work=
ing code for this.






 






Regards,






 






Peter








 




On 20 January 2014 03:28, Christer Holmberg <christer.ho=
lmberg@ericsson.com> wrote:




Hi,


=
 


=
I see no reason why it should be a separate document, as it should not have=
 any affect on the websocket specific procedures, which is the main scope o=
f the document.


=
 


=
Regards,


=
 


=
Christer


=
 


=
Sent from my Sony Ericsson Xperia arc S


=
 


=
Peter Dunkley <peter.dunkley@crocodilertc.net> wrote:=



=
 










Hello, 




 






Perhaps the document title should be corrected. MSRP=
-CEMA is outside of the scope of this document as this document is intended=
 to describe connecting to a WebSocket server that is an MSRP relay.






 






I can see no reason why MSRP-CEMA can't be used over=
 WebSockets, but if anyone has an interest in this I think that they should=
 put it in a document of its own.






 






 






Regards,






 






Peter








 




On 18 January 2014 08:52, Christer Holmberg <christer.ho=
lmberg@ericsson.com> wrote:






Hi,


 


I have not followed the =
work on this draft, so I appologize if the following has been
 discussed.


 =



While I do understand th=
at a WS Client has to establish the WebSocket with the Web Server,
 I don’t understand why we need to mandate the WS Server to be an MSR=
P Relay. That would e.g. prevent the usage of MSRP-CEMA.<=
/p>

 =



Regards,


 =



Christer


 =



 =



 =



L=E4hett=E4j=E4: dispatch [m=
ailto:dispat=
ch-bounces@ietf.org]
Puolesta Mary Barnes

L=E4hetetty: 11. tammikuuta 2014 0:59

Vastaanottaja: DISPATCH

Kopio: Ben Campbell; 
draft-pd-dispatch-msrp-websocket@tools.ietf.org

Aihe: Re: [dispatch] I-D Action: draft-pd-dispatch-msrp-websocket-03=
.txt






 




I have agreed to shepherd this document.  I've reviewed the d=
ocument in anticipation of doing the PROTO write-up and have the following =
comments and questions.  Ben Campbell has
 agreed to do the required expert review and that should be posted within t=
he next week or so.    This is also a good time for anyone in the=
 WG that hasn't previously reviewed this document to review and provide any=
 final comments.  Note, that this document
 was agreed to be AD sponsored around the IETF-86 timeframe.




 






Regards,






Mary. 






 








Review Summary: Almost ready. Comments & questions below.=







 






1)  Section 2 & General.  I'm not sure the documente=
d approach for separating normative text from non-normative is quite so hel=
pful.  In general, we expect that in the case of standards
 track document use RFC 2119 language to indicate normative behaviors. &nbs=
p;I think the first sentence is good, but that's not a terminology thing. &=
nbsp; I just don't see a lot of value in writing the document this way. &nb=
sp;For example, the definitions aren't stated to
 be non-normative, but I don't see anything normative about the definitions=
.  I think you could easily title Section 3 as "WebSocket Protoco=
l overview" and that would clearly imply non-normative behavior.  =
;There are also several places in the document in sections
 that I believe are intended to provide normative behavior, but there is ce=
rtainly non-normative text in those sections (e.g., section 5.2.2, second p=
aragraph).  I would suggest this document follow the typical (and acce=
pted) style of identifying normative
 behavior with 2119 language (consistently using upper case for normative b=
ehavior and avoiding using 2119 language in cases where alternative words c=
an be substituted).






 






2) Section 5.2.2, 2nd paragraph.  Related to my point above, =
it's not clear to me this is normative behavior.  I don't think it is =
since it's referring to existing 4975 behavior.
 However, I didn't see that the reference given in 4975 relates to the seco=
nd part of that sentence stating that implementations "should" al=
ready be allowing unrecognized transports.  It would be quite useful t=
o have the exact reference here as I was trying
 to double check this point and I couldn't find it. 






 






3) Section 6.  I'm really puzzled as to why the Connection Ke=
ep-alive would be non-normative.  In particular given that 2119 langua=
ge is clearly being used.  






 






4) Section 7.  Again, I'm puzzled as to why Authentication is=
 considered non-normative. AGain, you have 2119 language in this section. &=
nbsp;






 






5) Section 10.1. Since securing the connection is just RECOMMENDED=
, what are the implications and risks if the MSRP traffic isn't transported=
 over a secure connection? 






 






6) Section 11.  You should change the name of the registry to=
 be the exact name of the IANA registry to avoid any confusion.- i.e.,:






OLD:






  registry of WebSocket sub-protocols






NEW: 






  WebSocket Subprotocol Name Registry  






 






7) Section 11. There is also a Reference field in that IANA regist=
ry. I would suggest you use the same information as the pointer to the Subp=
rotocol Definition (i.e., this RFC). 






 






8) It's typical for documents that are updating existing RFCs to h=
ave a section that summarizes the updates to the existing RFCs that are mad=
e by this document.  






 






 








 




On Thu, Dec 12, 2013 at 6:57 PM, <internet-drafts@ietf.org> wrote:




A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.





        Title           : The =
WebSocket Protocol as a Transport for the Message Session Relay Protocol (M=
SRP)

        Author(s)       : Peter Dunkley<=
br>
                     =
;     Gavin Llewellyn

                     =
;     Victor Pascual

                     =
;     Anton Roman

                     =
;     Gonzalo Salgueiro

        Filename        : draft-pd-=
dispatch-msrp-websocket-03.txt

        Pages           : 21
        Date            :=
 2013-12-12



Abstract:

   The WebSocket protocol enables two-way real-time communication=


   between clients and servers.  This document specifies a n=
ew WebSocket

   sub-protocol as a reliable transport mechanism between MSRP (M=
essage

   Session Relay Protocol) clients and relays to enable usage of =
MSRP in

   new scenarios.  This document normatively updates RFC 497=
5 and RFC

   4976.





The IETF datatracker status page for this draft is:

https://datatracker.ietf.org/doc/draft-pd-dispatch-msr=
p-websocket



There's also a htmlized version available at:

http://tools.ietf.org/html/draft-pd-dispatch-msrp-websock=
et-03



A diff from the previous version is available at:

http://www.ietf.org/rfcdiff?url2=3Ddraft-pd-dispa=
tch-msrp-websocket-03





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.



Internet-Drafts are also available by anonymous FTP at:

ftp://ftp=
.ietf.org/internet-drafts/



_______________________________________________

I-D-Announce mailing list

I-D-Announce@iet=
f.org

https://www.ietf.org/mailman/listinfo/i-d-announce

Internet-Draft directories: 
http://www.ietf.org/shadow.html

or =
ftp://ftp.ietf.org/ietf/1shadow-sites.txt




 

























 




-- 






=
Peter Dunkley






=
Technical Director






=
Crocodile RCS Ltd



























 




-- 






=
Peter Dunkley






=
Technical Director






=
Crocodile RCS Ltd












--_000_7594FB04B1934943A5C02806D1A2204B1D11137FESESSMB209erics_--


From christer.holmberg@ericsson.com  Tue Jan 21 01:43:24 2014
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 61C6B1A0087 for ; Tue, 21 Jan 2014 01:43:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.85
X-Spam-Level: 
X-Spam-Status: No, score=-3.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 IAMgu8ewW-lP for ; Tue, 21 Jan 2014 01:43:19 -0800 (PST)
Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 9016A1A00A2 for ; Tue, 21 Jan 2014 01:43:18 -0800 (PST)
X-AuditID: c1b4fb30-b7faa8e000007034-00-52de4135ea2e
Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 22.1D.28724.5314ED25; Tue, 21 Jan 2014 10:43:17 +0100 (CET)
Received: from ESESSMB209.ericsson.se ([169.254.9.114]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.02.0387.000; Tue, 21 Jan 2014 10:43:14 +0100
From: Christer Holmberg 
To: Victor Pascual 
Thread-Topic: [dispatch] I-D Action: draft-pd-dispatch-msrp-websocket-03.txt
Thread-Index: AQHPDleQGzr1Sxm0FkKTa2Dy1OUwAJqKNznggAHW2ICAAPS5P4AAWE2AgAAStzCAAX6poP///cyAgAATWxA=
Date: Tue, 21 Jan 2014 09:43:14 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1D11142F@ESESSMB209.ericsson.se>
References: <20131213005747.777.34301.idtracker@ietfa.amsl.com>  <7594FB04B1934943A5C02806D1A2204B1D104D91@ESESSMB209.ericsson.se>    <7594FB04B1934943A5C02806D1A2204B1D10A3A1@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D11137F@ESESSMB209.ericsson.se> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: fi-FI
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.154]
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D11142FESESSMB209erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmplkeLIzCtJLcpLzFFi42KZGfG3RtfU8V6Qwe9XihbND3+xWSydtIDV 4vKWz+wW57dvY7LYue4wqwOrx6OeUI/HX2exeixZ8pPJ40TvCyaPL5c/swWwRnHZpKTmZJal FunbJXBlnF3az1bQd5epYtPpXUwNjJe2MnUxcnJICJhI3HhxlBXCFpO4cG89WxcjF4eQwCFG ifOPG5ghnCWMEjeungZyODjYBCwkuv9pgzSICOhJtM99C9bALHCHUeLiuQOMIAlhAW+JKcvf MkMU+Ujc3H6ACcJOkjh+cikbiM0ioCrR8XAJWJxXwFfiQdNTqGVPWCQ+vFoFVsQpECjxZu06 dhCbEei876fWgDUwC4hLfDh4nRnibAGJJXvOQ9miEi8f/4N6R0li0e3PUPX5Eu8m7YFaJihx cuYTlgmMorOQjJqFpGwWkjKIuJ7EjalT2CBsbYllC19D1etKzPh3iAVZfAEj+ypG9tzEzJz0 cvNNjMCoPLjlt8EOxk33xQ4xSnOwKInzfnjrHCQkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qB sXFl+yHmV+s/N094Y8SxouPenKpS5o0nlydK2hhJXn/NrC98Jr9zUvzWy4GzWm7IbApSkIyK 5Lt2ZqreJI9/9wVufDvAdHuGV4fxh/K5ARrlHzMlXDdr7mk24rsvk5pYvXdl4PvcsLv94iyy FjtKD9g25szgjV0eGvrp5qEWv3vpnGWJt8tOK7EUZyQaajEXFScCAMX97JeYAgAA
Cc: Ben Campbell , DISPATCH , "draft-pd-dispatch-msrp-websocket@tools.ietf.org" 
Subject: Re: [dispatch] I-D Action: draft-pd-dispatch-msrp-websocket-03.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, 21 Jan 2014 09:43:24 -0000

--_000_7594FB04B1934943A5C02806D1A2204B1D11142FESESSMB209erics_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,

>I believe current approach for 3GPP (WebRTC access to IMS) is datachannel =
transport for both MSRP and BFCP being open to other mechanisms like websoc=
ket.

Correct.

Regards,

Christer




2014/1/21 Christer Holmberg >
Hi,

I made a false statement earlier, regarding 3GPP.

3GPP does not have requirement to transport MSRP over WebSocket.

Sorry for the confusion.

Regards,

Christer

L=E4hett=E4j=E4: dispatch [mailto:dispatch-bounces@ietf.org] Puolesta Christer Holmberg
L=E4hetetty: 20. tammikuuta 2014 11:55
Vastaanottaja: Peter Dunkley
Kopio: DISPATCH; Ben Campbell; draft-pd-dispatch-msrp-websocket@tools.ietf.=
org

Aihe: Re: [dispatch] I-D Action: draft-pd-dispatch-msrp-websocket-03.txt

Hi Peter,

I am willing to help, and contribute text.

But, I request that we don't move the document forward before I've had a ch=
ance to do that :)

(3GPP also has a requirement to specify the usage of MSRP over WebSocket.)

Regards,

Christer

L=E4hett=E4j=E4: Peter Dunkley [mailto:peter.dunkley@crocodilertc.net]
L=E4hetetty: 20. tammikuuta 2014 11:45
Vastaanottaja: Christer Holmberg
Kopio: Mary Barnes; DISPATCH; Ben Campbell; draft-pd-dispatch-msrp-websocke=
t@tools.ietf.org
Aihe: Re: [dispatch] I-D Action: draft-pd-dispatch-msrp-websocket-03.txt

Hi Christer,

There is working code for the document as-is and plans for more implementat=
ions. I think that if someone has a need for MSRP-CEMA in this scenario the=
n they should join with the current authors to contribute the text and work=
ing code for this.

Regards,

Peter

On 20 January 2014 03:28, Christer Holmberg > wrote:

Hi,



I see no reason why it should be a separate document, as it should not have=
 any affect on the websocket specific procedures, which is the main scope o=
f the document.



Regards,



Christer



Sent from my Sony Ericsson Xperia arc S



Peter Dunkley > wrote:


Hello,

Perhaps the document title should be corrected. MSRP-CEMA is outside of the=
 scope of this document as this document is intended to describe connecting=
 to a WebSocket server that is an MSRP relay.

I can see no reason why MSRP-CEMA can't be used over WebSockets, but if any=
one has an interest in this I think that they should put it in a document o=
f its own.


Regards,

Peter

On 18 January 2014 08:52, Christer Holmberg > wrote:
Hi,

I have not followed the work on this draft, so I appologize if the followin=
g has been discussed.

While I do understand that a WS Client has to establish the WebSocket with =
the Web Server, I don't understand why we need to mandate the WS Server to =
be an MSRP Relay. That would e.g. prevent the usage of MSRP-CEMA.

Regards,

Christer



L=E4hett=E4j=E4: dispatch [mailto:dispatch-bounces@ietf.org] Puolesta Mary Barnes
L=E4hetetty: 11. tammikuuta 2014 0:59
Vastaanottaja: DISPATCH
Kopio: Ben Campbell; draft-pd-dispatch-msrp-websocket@tools.ietf.org
Aihe: Re: [dispatch] I-D Action: draft-pd-dispatch-msrp-websocket-03.txt

I have agreed to shepherd this document.  I've reviewed the document in ant=
icipation of doing the PROTO write-up and have the following comments and q=
uestions.  Ben Campbell has agreed to do the required expert review and tha=
t should be posted within the next week or so.    This is also a good time =
for anyone in the WG that hasn't previously reviewed this document to revie=
w and provide any final comments.  Note, that this document was agreed to b=
e AD sponsored around the IETF-86 timeframe.

Regards,
Mary.

Review Summary: Almost ready. Comments & questions below.

1)  Section 2 & General.  I'm not sure the documented approach for separati=
ng normative text from non-normative is quite so helpful.  In general, we e=
xpect that in the case of standards track document use RFC 2119 language to=
 indicate normative behaviors.  I think the first sentence is good, but tha=
t's not a terminology thing.   I just don't see a lot of value in writing t=
he document this way.  For example, the definitions aren't stated to be non=
-normative, but I don't see anything normative about the definitions.  I th=
ink you could easily title Section 3 as "WebSocket Protocol overview" and t=
hat would clearly imply non-normative behavior.  There are also several pla=
ces in the document in sections that I believe are intended to provide norm=
ative behavior, but there is certainly non-normative text in those sections=
 (e.g., section 5.2.2, second paragraph).  I would suggest this document fo=
llow the typical (and accepted) style of identifying normative behavior wit=
h 2119 language (consistently using upper case for normative behavior and a=
voiding using 2119 language in cases where alternative words can be substit=
uted).

2) Section 5.2.2, 2nd paragraph.  Related to my point above, it's not clear=
 to me this is normative behavior.  I don't think it is since it's referrin=
g to existing 4975 behavior. However, I didn't see that the reference given=
 in 4975 relates to the second part of that sentence stating that implement=
ations "should" already be allowing unrecognized transports.  It would be q=
uite useful to have the exact reference here as I was trying to double chec=
k this point and I couldn't find it.

3) Section 6.  I'm really puzzled as to why the Connection Keep-alive would=
 be non-normative.  In particular given that 2119 language is clearly being=
 used.

4) Section 7.  Again, I'm puzzled as to why Authentication is considered no=
n-normative. AGain, you have 2119 language in this section.

5) Section 10.1. Since securing the connection is just RECOMMENDED, what ar=
e the implications and risks if the MSRP traffic isn't transported over a s=
ecure connection?

6) Section 11.  You should change the name of the registry to be the exact =
name of the IANA registry to avoid any confusion.- i.e.,:
OLD:
  registry of WebSocket sub-protocols
NEW:
  WebSocket Subprotocol Name Registry

7) Section 11. There is also a Reference field in that IANA registry. I wou=
ld suggest you use the same information as the pointer to the Subprotocol D=
efinition (i.e., this RFC).

8) It's typical for documents that are updating existing RFCs to have a sec=
tion that summarizes the updates to the existing RFCs that are made by this=
 document.



On Thu, Dec 12, 2013 at 6:57 PM, > wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.


        Title           : The WebSocket Protocol as a Transport for the Mes=
sage Session Relay Protocol (MSRP)
        Author(s)       : Peter Dunkley
                          Gavin Llewellyn
                          Victor Pascual
                          Anton Roman
                          Gonzalo Salgueiro
        Filename        : draft-pd-dispatch-msrp-websocket-03.txt
        Pages           : 21
        Date            : 2013-12-12

Abstract:
   The WebSocket protocol enables two-way real-time communication
   between clients and servers.  This document specifies a new WebSocket
   sub-protocol as a reliable transport mechanism between MSRP (Message
   Session Relay Protocol) clients and relays to enable usage of MSRP in
   new scenarios.  This document normatively updates RFC 4975 and RFC
   4976.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-pd-dispatch-msrp-websocket

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-pd-dispatch-msrp-websocket-03

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-pd-dispatch-msrp-websocket-03


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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt




--
Peter Dunkley
Technical Director
Crocodile RCS Ltd



--
Peter Dunkley
Technical Director
Crocodile RCS Ltd


--_000_7594FB04B1934943A5C02806D1A2204B1D11142FESESSMB209erics_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Hi,


 




>I believe current approach for 3GPP (WebRTC access=
 to IMS) is datachannel transport for both MSRP and BFCP being open to othe=
r mechanisms like websocket.


 =
;


Correct.


 =
;


Regards,


 =
;


Christer


 =
;


 =
;


 =
;






 




2014/1/21 Christer Holmberg <christer.holmberg@ericsson.=
com>






Hi,


 


I made a false statement=
 earlier, regarding 3GPP.


 =



3GPP does not have requi=
rement to transport MSRP over WebSocket.


 =



Sorry for the confusion.=



 =



Regards,


 =



Christer


 =







L=E4hett=E4j=E4: dispatch [m=
ailto:dispat=
ch-bounces@ietf.org]
Puolesta Christer Holmberg

L=E4hetetty: 20. tammikuuta 2014 11:55

Vastaanottaja: Peter Dunkley

Kopio: DISPATCH; Ben Campbell; 
draft-pd-dispatch-msrp-websocket@tools.ietf.org








Aihe: Re: [dispatch] I-D Action: draft-pd-dispatch-msrp-websocket-03=
.txt














 


Hi Peter,


 =



I am willing to help, an=
d contribute text.


 =



But, I request that we d=
on’t move the document forward before I’ve had a chance to do
 that :)


 =



(3GPP also has a require=
ment to specify the usage of MSRP over WebSocket.)


 =



Regards,


 =



Christer


 =



L=E4hett=E4j=E4: Peter Dunkl=
ey [mai=
lto:peter.dunkley@crocodilertc.net]


L=E4hetetty: 20. tammikuuta 2014 11:45

Vastaanottaja: Christer Holmberg

Kopio: Mary Barnes; DISPATCH; Ben Campbell; 
draft-pd-dispatch-msrp-websocket@tools.ietf.org

Aihe: Re: [dispatch] I-D Action: draft-pd-dispatch-msrp-websocket-03=
.txt


 




Hi Christer,






There is working code for the document as-is and plans for more implementat=
ions. I think that if someone has a need for MSRP-CEMA in this scenario the=
n they should join with the current authors to contribute the text and work=
ing code for this.






 






Regards,






 






Peter








 




On 20 January 2014 03:28, Christer Holmberg <christer.holmberg@ericsso=
n.com> wrote:




Hi,


=
 


=
I see no reason why it should be a separate document, as it should not have=
 any affect on the websocket specific procedures, which is the main scope o=
f the document.


=
 


=
Regards,


=
 


=
Christer


=
 


=
Sent from my Sony Ericsson Xperia arc S


=
 


=
Peter Dunkley <peter.dunkley@crocodilertc.net> wrote:=



=
 










Hello,





 






Perhaps the document title should be corrected. MSRP-CEMA is outsi=
de of the scope of this document as this document is intended to describe c=
onnecting to a WebSocket server that
 is an MSRP relay.






 






I can see no reason why MSRP-CEMA can't be used over WebSockets, b=
ut if anyone has an interest in this I think that they should put it in a d=
ocument of its own.






 






 






Regards,






 






Peter








 




On 18 January 2014 08:52, Christer Holmberg <christer.holmberg@ericsso=
n.com> wrote:






Hi,


 


I have not followed the =
work on this draft, so I appologize if the following has been
 discussed.


 =



While I do understand th=
at a WS Client has to establish the WebSocket with the Web Server,
 I don’t understand why we need to mandate the WS Server to be an MSR=
P Relay. That would e.g. prevent the usage of MSRP-CEMA.<=
/p>

 =



Regards,


 =



Christer


 =



 =



 =



L=E4hett=E4j=E4: dispatch [m=
ailto:dispat=
ch-bounces@ietf.org]
Puolesta Mary Barnes

L=E4hetetty: 11. tammikuuta 2014 0:59

Vastaanottaja: DISPATCH

Kopio: Ben Campbell; 
draft-pd-dispatch-msrp-websocket@tools.ietf.org

Aihe: Re: [dispatch] I-D Action: draft-pd-dispatch-msrp-websocket-03=
.txt






 




I have agreed to shepherd this document.  I've reviewed the d=
ocument in anticipation of doing the PROTO write-up and have the following =
comments and questions.  Ben Campbell has
 agreed to do the required expert review and that should be posted within t=
he next week or so.    This is also a good time for anyone in the=
 WG that hasn't previously reviewed this document to review and provide any=
 final comments.  Note, that this document
 was agreed to be AD sponsored around the IETF-86 timeframe.




 






Regards,






Mary. 






 








Review Summary: Almost ready. Comments & questions below.=







 






1)  Section 2 & General.  I'm not sure the documente=
d approach for separating normative text from non-normative is quite so hel=
pful.  In general, we expect that in the case of standards
 track document use RFC 2119 language to indicate normative behaviors. &nbs=
p;I think the first sentence is good, but that's not a terminology thing. &=
nbsp; I just don't see a lot of value in writing the document this way. &nb=
sp;For example, the definitions aren't stated to
 be non-normative, but I don't see anything normative about the definitions=
.  I think you could easily title Section 3 as "WebSocket Protoco=
l overview" and that would clearly imply non-normative behavior.  =
;There are also several places in the document in sections
 that I believe are intended to provide normative behavior, but there is ce=
rtainly non-normative text in those sections (e.g., section 5.2.2, second p=
aragraph).  I would suggest this document follow the typical (and acce=
pted) style of identifying normative
 behavior with 2119 language (consistently using upper case for normative b=
ehavior and avoiding using 2119 language in cases where alternative words c=
an be substituted).






 






2) Section 5.2.2, 2nd paragraph.  Related to my point above, =
it's not clear to me this is normative behavior.  I don't think it is =
since it's referring to existing 4975 behavior.
 However, I didn't see that the reference given in 4975 relates to the seco=
nd part of that sentence stating that implementations "should" al=
ready be allowing unrecognized transports.  It would be quite useful t=
o have the exact reference here as I was trying
 to double check this point and I couldn't find it. 






 






3) Section 6.  I'm really puzzled as to why the Connection Ke=
ep-alive would be non-normative.  In particular given that 2119 langua=
ge is clearly being used.  






 






4) Section 7.  Again, I'm puzzled as to why Authentication is=
 considered non-normative. AGain, you have 2119 language in this section. &=
nbsp;






 






5) Section 10.1. Since securing the connection is just RECOMMENDED=
, what are the implications and risks if the MSRP traffic isn't transported=
 over a secure connection? 






 






6) Section 11.  You should change the name of the registry to=
 be the exact name of the IANA registry to avoid any confusion.- i.e.,:






OLD:






  registry of WebSocket sub-protocols






NEW: 






  WebSocket Subprotocol Name Registry  






 






7) Section 11. There is also a Reference field in that IANA regist=
ry. I would suggest you use the same information as the pointer to the Subp=
rotocol Definition (i.e., this RFC). 






 






8) It's typical for documents that are updating existing RFCs to h=
ave a section that summarizes the updates to the existing RFCs that are mad=
e by this document.  






 






 








 




On Thu, Dec 12, 2013 at 6:57 PM, <internet-drafts@ietf.org> wrote:




A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.





        Title           : The =
WebSocket Protocol as a Transport for the Message Session Relay Protocol (M=
SRP)

        Author(s)       : Peter Dunkley<=
br>
                     =
;     Gavin Llewellyn

                     =
;     Victor Pascual

                     =
;     Anton Roman

                     =
;     Gonzalo Salgueiro

        Filename        : draft-pd-=
dispatch-msrp-websocket-03.txt

        Pages           : 21
        Date            :=
 2013-12-12



Abstract:

   The WebSocket protocol enables two-way real-time communication=


   between clients and servers.  This document specifies a n=
ew WebSocket

   sub-protocol as a reliable transport mechanism between MSRP (M=
essage

   Session Relay Protocol) clients and relays to enable usage of =
MSRP in

   new scenarios.  This document normatively updates RFC 497=
5 and RFC

   4976.





The IETF datatracker status page for this draft is:

https://datatracker.ietf.org/doc/draft-pd-dispatch-msr=
p-websocket



There's also a htmlized version available at:

http://tools.ietf.org/html/draft-pd-dispatch-msrp-websock=
et-03



A diff from the previous version is available at:

http://www.ietf.org/rfcdiff?url2=3Ddraft-pd-dispa=
tch-msrp-websocket-03





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.



Internet-Drafts are also available by anonymous FTP at:

ftp://ftp=
.ietf.org/internet-drafts/



_______________________________________________

I-D-Announce mailing list

I-D-Announce@iet=
f.org

https://www.ietf.org/mailman/listinfo/i-d-announce

Internet-Draft directories: 
http://www.ietf.org/shadow.html

or =
ftp://ftp.ietf.org/ietf/1shadow-sites.txt




 

























 




--







Peter Dunkley<=
/span>






Technical Dire=
ctor






Crocodile RCS =
Ltd



























 




--







Peter Dunkley<=
/span>






Technical Dire=
ctor






Crocodile RCS =
Ltd


















 








--_000_7594FB04B1934943A5C02806D1A2204B1D11142FESESSMB209erics_--


From gsalguei@cisco.com  Tue Jan 21 06:31:52 2014
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 1DB911A0153 for ; Tue, 21 Jan 2014 06:31:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.036
X-Spam-Level: 
X-Spam-Status: No, score=-10.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 yJmt7NvY3jNt for ; Tue, 21 Jan 2014 06:31:49 -0800 (PST)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) by ietfa.amsl.com (Postfix) with ESMTP id 0D6D31A013A for ; Tue, 21 Jan 2014 06:31:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9934; q=dns/txt; s=iport; t=1390314709; x=1391524309; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=pofUNhyTdAQntBVQMWo84X4pdm50JI5bM0ctWZR1VWA=; b=PWLb2fIluAMPcjN81Yuwxh8EZvlTHysT69wCNRBDp8ydW/kt6YLa+yHh XV8qe6DyA3dMA+22AdWs5xNshrkY3VnQjbRnhHDigW6lHY6aDrMbP8PVo JjuQmDJDTVHs6kBwoacC55VVUCs3PLpyIYkG/kJ+hE/JMbRppPpWptS30 E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ak4FAPuD3lKtJV2Y/2dsb2JhbABagws4UAa7Hk+BDxZ0giUBAQEDAQEBAQlfAwsFCwIBCBgnBycLFBECBA4FCYd0CAgFxF4XjkwzAgWDJIEUBJgigTKLLoU4gy2CKg
X-IronPort-AV: E=Sophos;i="4.95,696,1384300800"; d="scan'208";a="14369576"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-4.cisco.com with ESMTP; 21 Jan 2014 14:31:48 +0000
Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s0LEVmSp001014 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 21 Jan 2014 14:31:48 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.37]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0123.003; Tue, 21 Jan 2014 08:31:48 -0600
From: "Gonzalo Salgueiro (gsalguei)" 
To: Christer Holmberg 
Thread-Topic: [dispatch] I-D Action: draft-pd-dispatch-msrp-websocket-03.txt
Thread-Index: AQHPDleQGzr1Sxm0FkKTa2Dy1OUwAJqKNznggAHW2ICAAPS5P4AAzaWAgAAC6QCAAX46AIAADgqAgAACsgCAAFCfgA==
Date: Tue, 21 Jan 2014 14:31:47 +0000
Message-ID: 
References: <20131213005747.777.34301.idtracker@ietfa.amsl.com>  <7594FB04B1934943A5C02806D1A2204B1D104D91@ESESSMB209.ericsson.se>    <7594FB04B1934943A5C02806D1A2204B1D10A3A1@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D11137F@ESESSMB209.ericsson.se>  <7594FB04B1934943A5C02806D1A2204B1D11142F@ESESSMB209.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D11142F@ESESSMB209.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.116.132.51]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <46FFF56561EE234084B52B377EA4CC10@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: DISPATCH , "draft-pd-dispatch-msrp-websocket@tools.ietf.org" 
Subject: Re: [dispatch] I-D Action: draft-pd-dispatch-msrp-websocket-03.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, 21 Jan 2014 14:31:52 -0000

So just to be explicit; despite DC being the preferred transport for 3GPP, =
are we are still waiting on supplementary text from you on MSRP-CEMA for th=
is MSRPoWS draft?  If so, when do we expect to have that so we can progress=
 the draft?  We have some pending edits to make after Ben and Mary's review=
s, but we plan to publish a new version soon. It would be good to incorpora=
te this new text along with those other edits.

Cheers,

Gonzalo


On Jan 21, 2014, at 4:43 AM, Christer Holmberg  wrote:

> Hi,
> =20
> >I believe current approach for 3GPP (WebRTC access to IMS) is datachanne=
l transport for both MSRP and BFCP being open to other mechanisms like webs=
ocket.
> =20
> Correct.
> =20
> Regards,
> =20
> Christer
> =20
> =20
> =20
> =20
>=20
> 2014/1/21 Christer Holmberg 
> Hi,
> =20
> I made a false statement earlier, regarding 3GPP.
> =20
> 3GPP does not have requirement to transport MSRP over WebSocket.
> =20
> Sorry for the confusion.
> =20
> Regards,
> =20
> Christer
> =20
> L=E4hett=E4j=E4: dispatch [mailto:dispatch-bounces@ietf.org] Puolesta Chr=
ister Holmberg
> L=E4hetetty: 20. tammikuuta 2014 11:55
> Vastaanottaja: Peter Dunkley
> Kopio: DISPATCH; Ben Campbell; draft-pd-dispatch-msrp-websocket@tools.iet=
f.org
>=20
> Aihe: Re: [dispatch] I-D Action: draft-pd-dispatch-msrp-websocket-03.txt
> =20
> Hi Peter,
> =20
> I am willing to help, and contribute text.
> =20
> But, I request that we don=92t move the document forward before I=92ve ha=
d a chance to do that :)
> =20
> (3GPP also has a requirement to specify the usage of MSRP over WebSocket.=
)
> =20
> Regards,
> =20
> Christer
> =20
> L=E4hett=E4j=E4: Peter Dunkley [mailto:peter.dunkley@crocodilertc.net]=20
> L=E4hetetty: 20. tammikuuta 2014 11:45
> Vastaanottaja: Christer Holmberg
> Kopio: Mary Barnes; DISPATCH; Ben Campbell; draft-pd-dispatch-msrp-websoc=
ket@tools.ietf.org
> Aihe: Re: [dispatch] I-D Action: draft-pd-dispatch-msrp-websocket-03.txt
> =20
> Hi Christer,
>=20
> There is working code for the document as-is and plans for more implement=
ations. I think that if someone has a need for MSRP-CEMA in this scenario t=
hen they should join with the current authors to contribute the text and wo=
rking code for this.
> =20
> Regards,
> =20
> Peter
> =20
>=20
> On 20 January 2014 03:28, Christer Holmberg  wrote:
> Hi,
> =20
> I see no reason why it should be a separate document, as it should not ha=
ve any affect on the websocket specific procedures, which is the main scope=
 of the document.
> =20
> Regards,
> =20
> Christer
> =20
> Sent from my Sony Ericsson Xperia arc S
> =20
> Peter Dunkley  wrote:
> =20
> Hello,
> =20
> Perhaps the document title should be corrected. MSRP-CEMA is outside of t=
he scope of this document as this document is intended to describe connecti=
ng to a WebSocket server that is an MSRP relay.
> =20
> I can see no reason why MSRP-CEMA can't be used over WebSockets, but if a=
nyone has an interest in this I think that they should put it in a document=
 of its own.
> =20
> =20
> Regards,
> =20
> Peter
> =20
>=20
> On 18 January 2014 08:52, Christer Holmberg  wrote:
> Hi,
> =20
> I have not followed the work on this draft, so I appologize if the follow=
ing has been discussed.
> =20
> While I do understand that a WS Client has to establish the WebSocket wit=
h the Web Server, I don=92t understand why we need to mandate the WS Server=
 to be an MSRP Relay. That would e.g. prevent the usage of MSRP-CEMA.
> =20
> Regards,
> =20
> Christer
> =20
> =20
> =20
> L=E4hett=E4j=E4: dispatch [mailto:dispatch-bounces@ietf.org] Puolesta Mar=
y Barnes
> L=E4hetetty: 11. tammikuuta 2014 0:59
> Vastaanottaja: DISPATCH
> Kopio: Ben Campbell; draft-pd-dispatch-msrp-websocket@tools.ietf.org
> Aihe: Re: [dispatch] I-D Action: draft-pd-dispatch-msrp-websocket-03.txt
> =20
> I have agreed to shepherd this document.  I've reviewed the document in a=
nticipation of doing the PROTO write-up and have the following comments and=
 questions.  Ben Campbell has agreed to do the required expert review and t=
hat should be posted within the next week or so.    This is also a good tim=
e for anyone in the WG that hasn't previously reviewed this document to rev=
iew and provide any final comments.  Note, that this document was agreed to=
 be AD sponsored around the IETF-86 timeframe.
> =20
> Regards,
> Mary.=20
> =20
> Review Summary: Almost ready. Comments & questions below.
> =20
> 1)  Section 2 & General.  I'm not sure the documented approach for separa=
ting normative text from non-normative is quite so helpful.  In general, we=
 expect that in the case of standards track document use RFC 2119 language =
to indicate normative behaviors.  I think the first sentence is good, but t=
hat's not a terminology thing.   I just don't see a lot of value in writing=
 the document this way.  For example, the definitions aren't stated to be n=
on-normative, but I don't see anything normative about the definitions.  I =
think you could easily title Section 3 as "WebSocket Protocol overview" and=
 that would clearly imply non-normative behavior.  There are also several p=
laces in the document in sections that I believe are intended to provide no=
rmative behavior, but there is certainly non-normative text in those sectio=
ns (e.g., section 5.2.2, second paragraph).  I would suggest this document =
follow the typical (and accepted) style of identifying normative behavior w=
ith 2119 language (consistently using upper case for normative behavior and=
 avoiding using 2119 language in cases where alternative words can be subst=
ituted).
> =20
> 2) Section 5.2.2, 2nd paragraph.  Related to my point above, it's not cle=
ar to me this is normative behavior.  I don't think it is since it's referr=
ing to existing 4975 behavior. However, I didn't see that the reference giv=
en in 4975 relates to the second part of that sentence stating that impleme=
ntations "should" already be allowing unrecognized transports.  It would be=
 quite useful to have the exact reference here as I was trying to double ch=
eck this point and I couldn't find it.=20
> =20
> 3) Section 6.  I'm really puzzled as to why the Connection Keep-alive wou=
ld be non-normative.  In particular given that 2119 language is clearly bei=
ng used. =20
> =20
> 4) Section 7.  Again, I'm puzzled as to why Authentication is considered =
non-normative. AGain, you have 2119 language in this section. =20
> =20
> 5) Section 10.1. Since securing the connection is just RECOMMENDED, what =
are the implications and risks if the MSRP traffic isn't transported over a=
 secure connection?=20
> =20
> 6) Section 11.  You should change the name of the registry to be the exac=
t name of the IANA registry to avoid any confusion.- i.e.,:
> OLD:
>   registry of WebSocket sub-protocols
> NEW:=20
>   WebSocket Subprotocol Name Registry =20
> =20
> 7) Section 11. There is also a Reference field in that IANA registry. I w=
ould suggest you use the same information as the pointer to the Subprotocol=
 Definition (i.e., this RFC).=20
> =20
> 8) It's typical for documents that are updating existing RFCs to have a s=
ection that summarizes the updates to the existing RFCs that are made by th=
is document. =20
> =20
> =20
> =20
> On Thu, Dec 12, 2013 at 6:57 PM,  wrote:
>=20
> A New Internet-Draft is available from the on-line Internet-Drafts direct=
ories.
>=20
>=20
>         Title           : The WebSocket Protocol as a Transport for the M=
essage Session Relay Protocol (MSRP)
>         Author(s)       : Peter Dunkley
>                           Gavin Llewellyn
>                           Victor Pascual
>                           Anton Roman
>                           Gonzalo Salgueiro
>         Filename        : draft-pd-dispatch-msrp-websocket-03.txt
>         Pages           : 21
>         Date            : 2013-12-12
>=20
> Abstract:
>    The WebSocket protocol enables two-way real-time communication
>    between clients and servers.  This document specifies a new WebSocket
>    sub-protocol as a reliable transport mechanism between MSRP (Message
>    Session Relay Protocol) clients and relays to enable usage of MSRP in
>    new scenarios.  This document normatively updates RFC 4975 and RFC
>    4976.
>=20
>=20
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-pd-dispatch-msrp-websocket
>=20
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-pd-dispatch-msrp-websocket-03
>=20
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=3Ddraft-pd-dispatch-msrp-websocket-03
>=20
>=20
> Please note that it may take a couple of minutes from the time of submiss=
ion
> until the htmlized version and diff are available at tools.ietf.org.
>=20
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>=20
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> =20
>=20
>=20
> =20
> --
> Peter Dunkley
> Technical Director
> Crocodile RCS Ltd
>=20
>=20
> =20
> --
> Peter Dunkley
> Technical Director
> Crocodile RCS Ltd
> =20
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch


From victor.pascual@quobis.com  Tue Jan 21 01:33:41 2014
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 506731A02C8 for ; Tue, 21 Jan 2014 01:33:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 0xMqVrY3Dp1r for ; Tue, 21 Jan 2014 01:33:36 -0800 (PST)
Received: from mail-lb0-f179.google.com (mail-lb0-f179.google.com [209.85.217.179]) by ietfa.amsl.com (Postfix) with ESMTP id 42BA11A0102 for ; Tue, 21 Jan 2014 01:33:35 -0800 (PST)
Received: by mail-lb0-f179.google.com with SMTP id l4so4041004lbv.24 for ; Tue, 21 Jan 2014 01:33:35 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Z29X+sAVG3xuAq1Q/EenpQ9gjIOimzjTdAvsRwcCr6A=; b=KXeODy/CqL/uqtBYyjvGjmJhzVcoB6uf8Xtvhw3PUI7nvBAMJRToYk193AhghBax02 b3AHGQn2FaecLwB+sm7A0SsXFj9AzmvU6bF1fB7YnT9bKIQahiWcS2oisyDX6pfj5/QQ 4WemxWJrGA7zwdqgB+AU95u//0oAu/WZvA25vlY1Y19DIsT7QFjuOJuNFXhwvMbf/OMK OiF5lCmoosfBm94j3F68PsXD+nlfCp7aROAQhp3rABwCJQarTp8Sv2E4h5lk3t6RuhLK zmtbQQA02cWKhK9H3QqELglxkcwjYrXRE7ckpIXnngjbsoEMRqwhOwXYGwayNkSBXMiO iuqw==
X-Gm-Message-State: ALoCoQmcs4LDbrmQqjFo36zQP0DPYH8I9am+J9RUr3XtLf7k6ezOamU4I2pqDY/1p+dLXVmPVrkx
MIME-Version: 1.0
X-Received: by 10.152.19.170 with SMTP id g10mr15631379lae.9.1390296815222; Tue, 21 Jan 2014 01:33:35 -0800 (PST)
Received: by 10.114.240.136 with HTTP; Tue, 21 Jan 2014 01:33:35 -0800 (PST)
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D11137F@ESESSMB209.ericsson.se>
References: <20131213005747.777.34301.idtracker@ietfa.amsl.com>  <7594FB04B1934943A5C02806D1A2204B1D104D91@ESESSMB209.ericsson.se>    <7594FB04B1934943A5C02806D1A2204B1D10A3A1@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D11137F@ESESSMB209.ericsson.se>
Date: Tue, 21 Jan 2014 10:33:35 +0100
Message-ID: 
From: Victor Pascual 
To: Christer Holmberg 
Content-Type: multipart/alternative; boundary=089e01493f64cdced304f077b384
X-Mailman-Approved-At: Tue, 21 Jan 2014 08:06:48 -0800
Cc: Ben Campbell , DISPATCH , "draft-pd-dispatch-msrp-websocket@tools.ietf.org" 
Subject: Re: [dispatch] I-D Action: draft-pd-dispatch-msrp-websocket-03.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, 21 Jan 2014 09:33:41 -0000

--089e01493f64cdced304f077b384
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

I believe current approach for 3GPP (WebRTC access to IMS) is datachannel
transport for both MSRP and BFCP being open to other mechanisms like
websocket.

*Victor Pascual*
Chief Strategy Officer @ Quobis  | e:
victor.pascual@quobis.com | m:  +34630169875 | t: +34902999465


2014/1/21 Christer Holmberg 

>  Hi,
>
>
>
> I made a false statement earlier, regarding 3GPP.
>
>
>
> 3GPP does not have requirement to transport MSRP over WebSocket.
>
>
>
> Sorry for the confusion.
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
> *L=E4hett=E4j=E4:* dispatch [mailto:dispatch-bounces@ietf.org] *Puolesta =
*Christer
> Holmberg
> *L=E4hetetty:* 20. tammikuuta 2014 11:55
> *Vastaanottaja:* Peter Dunkley
> *Kopio:* DISPATCH; Ben Campbell;
> draft-pd-dispatch-msrp-websocket@tools.ietf.org
>
> *Aihe:* Re: [dispatch] I-D Action: draft-pd-dispatch-msrp-websocket-03.tx=
t
>
>
>
> Hi Peter,
>
>
>
> I am willing to help, and contribute text.
>
>
>
> But, I request that we don=92t move the document forward before I=92ve ha=
d a
> chance to do that :)
>
>
>
> (3GPP also has a requirement to specify the usage of MSRP over WebSocket.=
)
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
> *L=E4hett=E4j=E4:* Peter Dunkley [mailto:peter.dunkley@crocodilertc.net]
>
> *L=E4hetetty:* 20. tammikuuta 2014 11:45
> *Vastaanottaja:* Christer Holmberg
> *Kopio:* Mary Barnes; DISPATCH; Ben Campbell;
> draft-pd-dispatch-msrp-websocket@tools.ietf.org
> *Aihe:* Re: [dispatch] I-D Action: draft-pd-dispatch-msrp-websocket-03.tx=
t
>
>
>
> Hi Christer,
>
>
> There is working code for the document as-is and plans for more
> implementations. I think that if someone has a need for MSRP-CEMA in this
> scenario then they should join with the current authors to contribute the
> text and working code for this.
>
>
>
> Regards,
>
>
>
> Peter
>
>
>
> On 20 January 2014 03:28, Christer Holmberg <
> christer.holmberg@ericsson.com> wrote:
>
> Hi,
>
>
>
> I see no reason why it should be a separate document, as it should not ha=
ve any affect on the websocket specific procedures, which is the main scope=
 of the document.
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
> Sent from my Sony Ericsson Xperia arc S
>
>
>
> Peter Dunkley  wrote:
>
>
>
>   Hello,
>
>
>
> Perhaps the document title should be corrected. MSRP-CEMA is outside of
> the scope of this document as this document is intended to describe
> connecting to a WebSocket server that is an MSRP relay.
>
>
>
> I can see no reason why MSRP-CEMA can't be used over WebSockets, but if
> anyone has an interest in this I think that they should put it in a
> document of its own.
>
>
>
>
>
> Regards,
>
>
>
> Peter
>
>
>
> On 18 January 2014 08:52, Christer Holmberg <
> christer.holmberg@ericsson.com> wrote:
>
> Hi,
>
>
>
> I have not followed the work on this draft, so I appologize if the
> following has been discussed.
>
>
>
> While I do understand that a WS Client has to establish the WebSocket wit=
h
> the Web Server, I don=92t understand why we need to mandate the WS Server=
 to
> be an MSRP Relay. That would e.g. prevent the usage of MSRP-CEMA.
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
>
>
>
>
> *L=E4hett=E4j=E4:* dispatch [mailto:dispatch-bounces@ietf.org] *Puolesta =
*Mary
> Barnes
> *L=E4hetetty:* 11. tammikuuta 2014 0:59
> *Vastaanottaja:* DISPATCH
> *Kopio:* Ben Campbell; draft-pd-dispatch-msrp-websocket@tools.ietf.org
> *Aihe:* Re: [dispatch] I-D Action: draft-pd-dispatch-msrp-websocket-03.tx=
t
>
>
>
> I have agreed to shepherd this document.  I've reviewed the document in
> anticipation of doing the PROTO write-up and have the following comments
> and questions.  Ben Campbell has agreed to do the required expert review
> and that should be posted within the next week or so.    This is also a
> good time for anyone in the WG that hasn't previously reviewed this
> document to review and provide any final comments.  Note, that this
> document was agreed to be AD sponsored around the IETF-86 timeframe.
>
>
>
> Regards,
>
> Mary.
>
>
>
> Review Summary: Almost ready. Comments & questions below.
>
>
>
> 1)  Section 2 & General.  I'm not sure the documented approach for
> separating normative text from non-normative is quite so helpful.  In
> general, we expect that in the case of standards track document use RFC
> 2119 language to indicate normative behaviors.  I think the first sentenc=
e
> is good, but that's not a terminology thing.   I just don't see a lot of
> value in writing the document this way.  For example, the definitions
> aren't stated to be non-normative, but I don't see anything normative abo=
ut
> the definitions.  I think you could easily title Section 3 as "WebSocket
> Protocol overview" and that would clearly imply non-normative behavior.
>  There are also several places in the document in sections that I believe
> are intended to provide normative behavior, but there is certainly
> non-normative text in those sections (e.g., section 5.2.2, second
> paragraph).  I would suggest this document follow the typical (and
> accepted) style of identifying normative behavior with 2119 language
> (consistently using upper case for normative behavior and avoiding using
> 2119 language in cases where alternative words can be substituted).
>
>
>
> 2) Section 5.2.2, 2nd paragraph.  Related to my point above, it's not
> clear to me this is normative behavior.  I don't think it is since it's
> referring to existing 4975 behavior. However, I didn't see that the
> reference given in 4975 relates to the second part of that sentence stati=
ng
> that implementations "should" already be allowing unrecognized transports=
.
>  It would be quite useful to have the exact reference here as I was tryin=
g
> to double check this point and I couldn't find it.
>
>
>
> 3) Section 6.  I'm really puzzled as to why the Connection Keep-alive
> would be non-normative.  In particular given that 2119 language is clearl=
y
> being used.
>
>
>
> 4) Section 7.  Again, I'm puzzled as to why Authentication is considered
> non-normative. AGain, you have 2119 language in this section.
>
>
>
> 5) Section 10.1. Since securing the connection is just RECOMMENDED, what
> are the implications and risks if the MSRP traffic isn't transported over=
 a
> secure connection?
>
>
>
> 6) Section 11.  You should change the name of the registry to be the exac=
t
> name of the IANA registry to avoid any confusion.- i.e.,:
>
> OLD:
>
>   registry of WebSocket sub-protocols
>
> NEW:
>
>   WebSocket Subprotocol Name Registry
>
>
>
> 7) Section 11. There is also a Reference field in that IANA registry. I
> would suggest you use the same information as the pointer to the
> Subprotocol Definition (i.e., this RFC).
>
>
>
> 8) It's typical for documents that are updating existing RFCs to have a
> section that summarizes the updates to the existing RFCs that are made by
> this document.
>
>
>
>
>
>
>
> On Thu, Dec 12, 2013 at 6:57 PM,  wrote:
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>
>         Title           : The WebSocket Protocol as a Transport for the
> Message Session Relay Protocol (MSRP)
>         Author(s)       : Peter Dunkley
>                           Gavin Llewellyn
>                           Victor Pascual
>                           Anton Roman
>                           Gonzalo Salgueiro
>         Filename        : draft-pd-dispatch-msrp-websocket-03.txt
>         Pages           : 21
>         Date            : 2013-12-12
>
> Abstract:
>    The WebSocket protocol enables two-way real-time communication
>    between clients and servers.  This document specifies a new WebSocket
>    sub-protocol as a reliable transport mechanism between MSRP (Message
>    Session Relay Protocol) clients and relays to enable usage of MSRP in
>    new scenarios.  This document normatively updates RFC 4975 and RFC
>    4976.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-pd-dispatch-msrp-websocket
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-pd-dispatch-msrp-websocket-03
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=3Ddraft-pd-dispatch-msrp-websocket-03
>
>
> 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.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draftdirectories:
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
>
>
>
>
>
> --
>
> Peter Dunkley
>
> Technical Director
>
> Crocodile RCS Ltd
>
>
>
>
>
> --
>
> Peter Dunkley
>
> Technical Director
>
> Crocodile RCS Ltd
>

--089e01493f64cdced304f077b384
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable


I believe current approach for 3GPP (WebRTC access to IMS)=
 is datachannel transport for both MSRP and BFCP being open to other mechan=
isms like websocket.



Victor Pascual
Chief Strategy Officer @=A0Quobis=
=A0| e:=A0victor.pascual@quobis.com=A0| m:=A0=
=A0+34630169875=A0| t:=A0+34902999465





2014/1/21 Christer Holmberg <christer.holmberg@ericsson.com>












Hi,<=
/p>

=A0<=
/p>

I made a f=
alse statement earlier, regarding 3GPP.


=A0=



3GPP does =
not have requirement to transport MSRP over WebSocket.=




=A0=



Sorry for =
the confusion.


=A0=



Regards,


=A0=



Christer


=A0=







L=E4hett=E4j=E4: dispatch [mailto:dispatch-bounces@ietf.org]
Puolesta Christer Holmberg

L=E4hetetty: 20. tammikuuta 2014 11:55

Vastaanottaja: Peter Dunkley

Kopio: DISPATCH; Ben Campbell; draft-pd-dispatch-msrp-webs=
ocket@tools.ietf.org


Aihe: Re: [dispatch] I-D Action: draft-pd-dispatch-msrp-websocket-03=
.txt






=A0


Hi Peter,<=
/span>


=A0=



I am willi=
ng to help, and contribute text.


=A0=



But, I req=
uest that we don=92t move the document forward before I=92ve had a chance t=
o do that :)



=A0=



(3GPP also=
 has a requirement to specify the usage of MSRP over WebSocket.)<=
/u>



=A0=



Regards,


=A0=



Christer


=A0=



L=E4hett=E4j=E4: Peter Dunkley [mailto:peter.dunkley@crocodilertc.net]


L=E4hetetty: 20. tammikuuta 2014 11:45

Vastaanottaja: Christer Holmberg

Kopio: Mary Barnes; DISPATCH; Ben Campbell; 
draft-pd-dispatch-msrp-websocket@tools.ietf.org

Aihe: Re: [dispatch] I-D Action: draft-pd-dispatch-msrp-websocket-03=
.txt


=A0




Hi Christer,






There is working code for the document as-is and plans for more implementat=
ions. I think that if someone has a need for MSRP-CEMA in this scenario the=
n they should join with the current authors to contribute the text and work=
ing code for this.







=A0






Regards,






=A0






Peter








=A0




On 20 January 2014 03:28, Christer Holmberg <christer.ho=
lmberg@ericsson.com> wrote:




Hi,


=
=A0


=
I see no reason why it should be a separate document, as it should not have=
 any affect on the websocket specific procedures, which is the main scope o=
f the document.



=
=A0


=
Regards,


=
=A0


=
Christer


=
=A0


=
Sent from my Sony Ericsson Xperia arc S


=
=A0


=
Peter Dunkley <peter.dunkley@crocodilertc.net> wrote:<=
/u>



=
=A0










Hello, 




=A0






Perhaps the document title should be corrected. MSRP=
-CEMA is outside of the scope of this document as this document is intended=
 to describe connecting to a WebSocket server that is an MSRP relay.=








=A0






I can see no reason why MSRP-CEMA can't be used =
over WebSockets, but if anyone has an interest in this I think that they sh=
ould put it in a document of its own.






=A0






=A0






Regards,






=A0






Peter








=A0




On 18 January 2014 08:52, Christer Holmberg <christer.ho=
lmberg@ericsson.com> wrote:






Hi,<=
/p>

=A0<=
/p>

I have not=
 followed the work on this draft, so I appologize if the following has been
 discussed.


=A0=



While I do=
 understand that a WS Client has to establish the WebSocket with the Web Se=
rver,
 I don=92t understand why we need to mandate the WS Server to be an MSRP Re=
lay. That would e.g. prevent the usage of MSRP-CEMA.

=A0=



Regards,


=A0=



Christer


=A0=



=A0=



=A0=



L=E4hett=E4j=E4: dispatch [mailto:dispatch-bounces@ietf.org]
Puolesta Mary Barnes

L=E4hetetty: 11. tammikuuta 2014 0:59

Vastaanottaja: DISPATCH

Kopio: Ben Campbell; 
draft-pd-dispatch-msrp-websocket@tools.ietf.org

Aihe: Re: [dispatch] I-D Action: draft-pd-dispatch-msrp-websocket-03=
.txt






=A0




I have agreed to shepherd this document. =A0I've=
 reviewed the document in anticipation of doing the PROTO write-up and have=
 the following comments and questions. =A0Ben Campbell has
 agreed to do the required expert review and that should be posted within t=
he next week or so. =A0 =A0This is also a good time for anyone in the WG th=
at hasn't previously reviewed this document to review and provide any f=
inal comments. =A0Note, that this document
 was agreed to be AD sponsored around the IETF-86 timeframe.<=
/p>



=A0






Regards,






Mary.=A0






=A0








Review Summary: Almost ready. Comments & questio=
ns below.






=A0






1) =A0Section 2 & General. =A0I'm not sure t=
he documented approach for separating normative text from non-normative is =
quite so helpful. =A0In general, we expect that in the case of standards
 track document use RFC 2119 language to indicate normative behaviors. =A0I=
 think the first sentence is good, but that's not a terminology thing. =
=A0 I just don't see a lot of value in writing the document this way. =
=A0For example, the definitions aren't stated to
 be non-normative, but I don't see anything normative about the definit=
ions. =A0I think you could easily title Section 3 as "WebSocket Protoc=
ol overview" and that would clearly imply non-normative behavior. =A0T=
here are also several places in the document in sections
 that I believe are intended to provide normative behavior, but there is ce=
rtainly non-normative text in those sections (e.g., section 5.2.2, second p=
aragraph). =A0I would suggest this document follow the typical (and accepte=
d) style of identifying normative
 behavior with 2119 language (consistently using upper case for normative b=
ehavior and avoiding using 2119 language in cases where alternative words c=
an be substituted).






=A0






2) Section 5.2.2, 2nd paragraph. =A0Related to my po=
int above, it's not clear to me this is normative behavior. =A0I don=
9;t think it is since it's referring to existing 4975 behavior.
 However, I didn't see that the reference given in 4975 relates to the =
second part of that sentence stating that implementations "should"=
; already be allowing unrecognized transports. =A0It would be quite useful =
to have the exact reference here as I was trying
 to double check this point and I couldn't find it.=A0





=A0






3) Section 6. =A0I'm really puzzled as to why th=
e Connection Keep-alive would be non-normative. =A0In particular given that=
 2119 language is clearly being used. =A0






=A0






4) Section 7. =A0Again, I'm puzzled as to why Au=
thentication is considered non-normative. AGain, you have 2119 language in =
this section. =A0






=A0






5) Section 10.1. Since securing the connection is ju=
st RECOMMENDED, what are the implications and risks if the MSRP traffic isn=
't transported over a secure connection?=A0






=A0






6) Section 11. =A0You should change the name of the =
registry to be the exact name of the IANA registry to avoid any confusion.-=
 i.e.,:






OLD:






=A0 registry of WebSocket sub-protocols






NEW:=A0






=A0 WebSocket Subprotocol Name Registry =A0






=A0






7) Section 11. There is also a Reference field in th=
at IANA registry. I would suggest you use the same information as the point=
er to the Subprotocol Definition (i.e., this RFC).=A0






=A0






8) It's typical for documents that are updating =
existing RFCs to have a section that summarizes the updates to the existing=
 RFCs that are made by this document. =A0






=A0






=A0








=A0




On Thu, Dec 12, 2013 at 6:57 PM, <internet-drafts@ietf.org=
> wrote:




A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.





=A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : The WebSocket Protocol as a Tra=
nsport for the Message Session Relay Protocol (MSRP)

=A0 =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Peter Dunkley

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Gavin Llewellyn

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Victor Pascual

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Anton Roman

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Gonzalo Salgueiro

=A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-pd-dispatch-msrp-websocket-=
03.txt

=A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 21

=A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2013-12-12



Abstract:

=A0 =A0The WebSocket protocol enables two-way real-time communication

=A0 =A0between clients and servers. =A0This document specifies a new WebSoc=
ket

=A0 =A0sub-protocol as a reliable transport mechanism between MSRP (Message=


=A0 =A0Session Relay Protocol) clients and relays to enable usage of MSRP i=
n

=A0 =A0new scenarios. =A0This document normatively updates RFC 4975 and RFC=


=A0 =A04976.





The IETF datatracker status page for this draft is:

https://datatracker.ietf.org/doc/draft-pd-dispatch-msr=
p-websocket



There's also a htmlized version available at:

http://tools.ietf.org/html/draft-pd-dispatch-msrp-websock=
et-03



A diff from the previous version is available at:

http://www.ietf.org/rfcdiff?url2=3Ddraft-pd-dispa=
tch-msrp-websocket-03





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.



Internet-Drafts are also available by anonymous FTP at:

ftp://ftp=
.ietf.org/internet-drafts/



_______________________________________________

I-D-Announce mailing list

I-D-Announce@iet=
f.org

https://www.ietf.org/mailman/listinfo/i-d-announce

Internet-Draft directories: 
http://www.ietf.org/shadow.html

or =
ftp://ftp.ietf.org/ietf/1shadow-sites.txt




=A0

























=A0




-- 






=
Peter Dunkley






=
Technical Director






=
Crocodile RCS Ltd



























=A0




-- 






=
Peter Dunkley






=
Technical Director






=
Crocodile RCS Ltd
















--089e01493f64cdced304f077b384--

From christer.holmberg@ericsson.com  Wed Jan 22 03:00:16 2014
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 A6C6B1A041F for ; Wed, 22 Jan 2014 03:00:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.851
X-Spam-Level: 
X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, 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 0o-cCMVURbpC for ; Wed, 22 Jan 2014 03:00:12 -0800 (PST)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 7FBAE1A03DF for ; Wed, 22 Jan 2014 03:00:11 -0800 (PST)
X-AuditID: c1b4fb25-b7f038e000005d01-cb-52dfa4ba92e3
Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id E5.34.23809.AB4AFD25; Wed, 22 Jan 2014 12:00:10 +0100 (CET)
Received: from ESESSMB209.ericsson.se ([169.254.9.114]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.02.0387.000; Wed, 22 Jan 2014 12:00:10 +0100
From: Christer Holmberg 
To: "Gonzalo Salgueiro (gsalguei)" 
Thread-Topic: [dispatch] I-D Action: draft-pd-dispatch-msrp-websocket-03.txt
Thread-Index: AQHPDleQGzr1Sxm0FkKTa2Dy1OUwAJqKNznggAHW2ICAAPS5P4AAWE2AgAAStzCAAX6poP///cyAgAATWxCAAD/2gIABY5ag
Date: Wed, 22 Jan 2014 11:00:09 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1D114F40@ESESSMB209.ericsson.se>
References: <20131213005747.777.34301.idtracker@ietfa.amsl.com>  <7594FB04B1934943A5C02806D1A2204B1D104D91@ESESSMB209.ericsson.se>    <7594FB04B1934943A5C02806D1A2204B1D10A3A1@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D11137F@ESESSMB209.ericsson.se>  <7594FB04B1934943A5C02806D1A2204B1D11142F@ESESSMB209.ericsson.se> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: fi-FI
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.149]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGLMWRmVeSWpSXmKPExsUyM+Jvje6uJfeDDFo3q1gsnbSA1eLyls/s FnOn+Dkwe0z5vZHVY8mSn0weXy5/ZgtgjuKySUnNySxLLdK3S+DKeL34IHvBmeCKV1vfsDQw /nTsYuTkkBAwkWifto0RwhaTuHBvPVsXIxeHkMAhRokrn98xQzhLGCWWnrnM2sXIwcEmYCHR /U8bpEFEwFxiz+8WsAZmgU5Gibn3tzCDJIQFvCWmLH/LDFHkI3Fz+wEmCDtP4uavqWwgc1gE VCW2r9UFCfMK+Ep8n/mREWLXbVaJx29fg13EKWArceXmenYQmxHouu+n1oDNYRYQl/hw8Doz xNUCEkv2nIeyRSVePv7HCmErSaw9vJ0Fol5P4sbUKWwQtrbEsoWvmSEWC0qcnPmEZQKj2Cwk Y2chaZmFpGUWkpYFjCyrGNlzEzNz0suNNjEC4+bglt+qOxjvnBM5xCjNwaIkzvvhrXOQkEB6 YklqdmpqQWpRfFFpTmrxIUYmDk6pBsYdF+sfqs/Ydmihq237ypWsR3ymCyyrSdYKW+Atesg8 wNPT4tmXB9Z6QYs2lzPmFbtGB01yiG3JO7Br48cJCpP4rbROMFREVz4XM8xdsVnURMd/x4+r L/1nf9DODL18fYdQ619jsyuLelp+/Viw7+N9huTAK9NkVr+Y9/x7oEzFbYEmRqnPS6SVWIoz Eg21mIuKEwESOhU5aQIAAA==
Cc: DISPATCH , "draft-pd-dispatch-msrp-websocket@tools.ietf.org" 
Subject: Re: [dispatch] I-D Action: draft-pd-dispatch-msrp-websocket-03.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: Wed, 22 Jan 2014 11:00:16 -0000

Hi Gonzalo,

> So just to be explicit; despite DC being the preferred transport for 3GPP=
, are we are still waiting on supplementary text from you on MSRP-CEMA=20
> for this MSRPoWS draft?  If so, when do we expect to have that so we can =
progress the draft?  We have some pending edits to make after Ben=20
> and Mary's reviews, but we plan to publish a new version soon. It would b=
e good to incorporate this new text along with those other edits.

As there is no 3GPP connection, I would have to put this pretty far down on=
 my priority list. And, as I don't want to hold the work, I guess the best =
thing is for you to move on with the work.

Mabye you could add a note to the draft, saying something like:

"NOTE: As the WebSocket server acts as a MSRP relay, the usage of MSRP-CEMA=
 [RFC6714] will be disabled in most cases. A mechanism where the WebServer =
does not act as a MSRP relay is outside the scope of this document, and wou=
ld have to be defined in a specification."

In addition, I think it would be good to point out that RFC 6135 (An Altern=
ative Connection Model for the MSRP) CAN be used with MSRP over WebSocket. =
That has no impact on the mechanism itself, and is not impacted by the usag=
e of relays.

Regards,

Christer




> Hi,
> =20
> >I believe current approach for 3GPP (WebRTC access to IMS) is datachanne=
l transport for both MSRP and BFCP being open to other mechanisms like webs=
ocket.
> =20
> Correct.
> =20
> Regards,
> =20
> Christer
> =20
> =20
> =20
> =20
>=20
> 2014/1/21 Christer Holmberg  Hi,
> =20
> I made a false statement earlier, regarding 3GPP.
> =20
> 3GPP does not have requirement to transport MSRP over WebSocket.
> =20
> Sorry for the confusion.
> =20
> Regards,
> =20
> Christer
> =20
> L=E4hett=E4j=E4: dispatch [mailto:dispatch-bounces@ietf.org] Puolesta=20
> Christer Holmberg
> L=E4hetetty: 20. tammikuuta 2014 11:55
> Vastaanottaja: Peter Dunkley
> Kopio: DISPATCH; Ben Campbell;=20
> draft-pd-dispatch-msrp-websocket@tools.ietf.org
>=20
> Aihe: Re: [dispatch] I-D Action:=20
> draft-pd-dispatch-msrp-websocket-03.txt
> =20
> Hi Peter,
> =20
> I am willing to help, and contribute text.
> =20
> But, I request that we don't move the document forward before I've had=20
> a chance to do that :)
> =20
> (3GPP also has a requirement to specify the usage of MSRP over=20
> WebSocket.)
> =20
> Regards,
> =20
> Christer
> =20
> L=E4hett=E4j=E4: Peter Dunkley [mailto:peter.dunkley@crocodilertc.net]
> L=E4hetetty: 20. tammikuuta 2014 11:45
> Vastaanottaja: Christer Holmberg
> Kopio: Mary Barnes; DISPATCH; Ben Campbell;=20
> draft-pd-dispatch-msrp-websocket@tools.ietf.org
> Aihe: Re: [dispatch] I-D Action:=20
> draft-pd-dispatch-msrp-websocket-03.txt
> =20
> Hi Christer,
>=20
> There is working code for the document as-is and plans for more implement=
ations. I think that if someone has a need for MSRP-CEMA in this scenario t=
hen they should join with the current authors to contribute the text and wo=
rking code for this.
> =20
> Regards,
> =20
> Peter
> =20
>=20
> On 20 January 2014 03:28, Christer Holmberg  wrote:
> Hi,
> =20
> I see no reason why it should be a separate document, as it should not ha=
ve any affect on the websocket specific procedures, which is the main scope=
 of the document.
> =20
> Regards,
> =20
> Christer
> =20
> Sent from my Sony Ericsson Xperia arc S
> =20
> Peter Dunkley  wrote:
> =20
> Hello,
> =20
> Perhaps the document title should be corrected. MSRP-CEMA is outside of t=
he scope of this document as this document is intended to describe connecti=
ng to a WebSocket server that is an MSRP relay.
> =20
> I can see no reason why MSRP-CEMA can't be used over WebSockets, but if a=
nyone has an interest in this I think that they should put it in a document=
 of its own.
> =20
> =20
> Regards,
> =20
> Peter
> =20
>=20
> On 18 January 2014 08:52, Christer Holmberg  wrote:
> Hi,
> =20
> I have not followed the work on this draft, so I appologize if the follow=
ing has been discussed.
> =20
> While I do understand that a WS Client has to establish the WebSocket wit=
h the Web Server, I don't understand why we need to mandate the WS Server t=
o be an MSRP Relay. That would e.g. prevent the usage of MSRP-CEMA.
> =20
> Regards,
> =20
> Christer
> =20
> =20
> =20
> L=E4hett=E4j=E4: dispatch [mailto:dispatch-bounces@ietf.org] Puolesta Mar=
y=20
> Barnes
> L=E4hetetty: 11. tammikuuta 2014 0:59
> Vastaanottaja: DISPATCH
> Kopio: Ben Campbell; draft-pd-dispatch-msrp-websocket@tools.ietf.org
> Aihe: Re: [dispatch] I-D Action:=20
> draft-pd-dispatch-msrp-websocket-03.txt
> =20
> I have agreed to shepherd this document.  I've reviewed the document in a=
nticipation of doing the PROTO write-up and have the following comments and=
 questions.  Ben Campbell has agreed to do the required expert review and t=
hat should be posted within the next week or so.    This is also a good tim=
e for anyone in the WG that hasn't previously reviewed this document to rev=
iew and provide any final comments.  Note, that this document was agreed to=
 be AD sponsored around the IETF-86 timeframe.
> =20
> Regards,
> Mary.=20
> =20
> Review Summary: Almost ready. Comments & questions below.
> =20
> 1)  Section 2 & General.  I'm not sure the documented approach for separa=
ting normative text from non-normative is quite so helpful.  In general, we=
 expect that in the case of standards track document use RFC 2119 language =
to indicate normative behaviors.  I think the first sentence is good, but t=
hat's not a terminology thing.   I just don't see a lot of value in writing=
 the document this way.  For example, the definitions aren't stated to be n=
on-normative, but I don't see anything normative about the definitions.  I =
think you could easily title Section 3 as "WebSocket Protocol overview" and=
 that would clearly imply non-normative behavior.  There are also several p=
laces in the document in sections that I believe are intended to provide no=
rmative behavior, but there is certainly non-normative text in those sectio=
ns (e.g., section 5.2.2, second paragraph).  I would suggest this document =
follow the typical (and accepted) style of identifying normative behavior w=
ith 2119 language (consistently using upper case for normative behavior and=
 avoiding using 2119 language in cases where alternative words can be subst=
ituted).
> =20
> 2) Section 5.2.2, 2nd paragraph.  Related to my point above, it's not cle=
ar to me this is normative behavior.  I don't think it is since it's referr=
ing to existing 4975 behavior. However, I didn't see that the reference giv=
en in 4975 relates to the second part of that sentence stating that impleme=
ntations "should" already be allowing unrecognized transports.  It would be=
 quite useful to have the exact reference here as I was trying to double ch=
eck this point and I couldn't find it.=20
> =20
> 3) Section 6.  I'm really puzzled as to why the Connection Keep-alive wou=
ld be non-normative.  In particular given that 2119 language is clearly bei=
ng used. =20
> =20
> 4) Section 7.  Again, I'm puzzled as to why Authentication is considered =
non-normative. AGain, you have 2119 language in this section. =20
> =20
> 5) Section 10.1. Since securing the connection is just RECOMMENDED, what =
are the implications and risks if the MSRP traffic isn't transported over a=
 secure connection?=20
> =20
> 6) Section 11.  You should change the name of the registry to be the exac=
t name of the IANA registry to avoid any confusion.- i.e.,:
> OLD:
>   registry of WebSocket sub-protocols
> NEW:=20
>   WebSocket Subprotocol Name Registry
> =20
> 7) Section 11. There is also a Reference field in that IANA registry. I w=
ould suggest you use the same information as the pointer to the Subprotocol=
 Definition (i.e., this RFC).=20
> =20
> 8) It's typical for documents that are updating existing RFCs to have a s=
ection that summarizes the updates to the existing RFCs that are made by th=
is document. =20
> =20
> =20
> =20
> On Thu, Dec 12, 2013 at 6:57 PM,  wrote:
>=20
> A New Internet-Draft is available from the on-line Internet-Drafts direct=
ories.
>=20
>=20
>         Title           : The WebSocket Protocol as a Transport for the M=
essage Session Relay Protocol (MSRP)
>         Author(s)       : Peter Dunkley
>                           Gavin Llewellyn
>                           Victor Pascual
>                           Anton Roman
>                           Gonzalo Salgueiro
>         Filename        : draft-pd-dispatch-msrp-websocket-03.txt
>         Pages           : 21
>         Date            : 2013-12-12
>=20
> Abstract:
>    The WebSocket protocol enables two-way real-time communication
>    between clients and servers.  This document specifies a new WebSocket
>    sub-protocol as a reliable transport mechanism between MSRP (Message
>    Session Relay Protocol) clients and relays to enable usage of MSRP in
>    new scenarios.  This document normatively updates RFC 4975 and RFC
>    4976.
>=20
>=20
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-pd-dispatch-msrp-websocket
>=20
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-pd-dispatch-msrp-websocket-03
>=20
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=3Ddraft-pd-dispatch-msrp-websocket-03
>=20
>=20
> Please note that it may take a couple of minutes from the time of=20
> submission until the htmlized version and diff are available at tools.iet=
f.org.
>=20
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>=20
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html or=20
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> =20
>=20
>=20
> =20
> --
> Peter Dunkley
> Technical Director
> Crocodile RCS Ltd
>=20
>=20
> =20
> --
> Peter Dunkley
> Technical Director
> Crocodile RCS Ltd
> =20
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch


From gsalguei@cisco.com  Wed Jan 22 08:20:53 2014
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 C6EB11A0198 for ; Wed, 22 Jan 2014 08:20:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.036
X-Spam-Level: 
X-Spam-Status: No, score=-15.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 LWBAQscW_jg4 for ; Wed, 22 Jan 2014 08:20:51 -0800 (PST)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 263531A035C for ; Wed, 22 Jan 2014 08:20:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11494; q=dns/txt; s=iport; t=1390407651; x=1391617251; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=UAuW9eufBrFkZwUh6NScRnRLa86Q2zu7sng0utbVpxY=; b=dP/9u19hXCRUqFas6tZaErrZEaC5Om1iIp2GFe4PVu4PEl3oCiUZqsEo pLGXZWpWGmXBq90EEpdfbO4w7N5QH6OHRiUU57BJrbosc2hrHUfow+9lq PeWZgFnVBHJoXh23DrdlJR3yG3WpKybsMNnqTqNNkEBKkcsjJU56X0B9Q k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AkEFAPTu31KtJXHB/2dsb2JhbABbgws4UAa7Dk+BFBZ0giUBAQEDAQEBAQkdQgMLBQsCAQIGGCcHJwsUEQIEDgUJh3QICAXCXxeOKCEzAgWDJIEUBIkPjxOBMosuhTiDLYIq
X-IronPort-AV: E=Sophos;i="4.95,700,1384300800"; d="scan'208";a="298957116"
Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-7.cisco.com with ESMTP; 22 Jan 2014 16:20:50 +0000
Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id s0MGKoiQ016520 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 Jan 2014 16:20:50 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.37]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0123.003; Wed, 22 Jan 2014 10:20:49 -0600
From: "Gonzalo Salgueiro (gsalguei)" 
To: Christer Holmberg 
Thread-Topic: [dispatch] I-D Action: draft-pd-dispatch-msrp-websocket-03.txt
Thread-Index: AQHPDleQGzr1Sxm0FkKTa2Dy1OUwAJqKNznggAHW2ICAAPS5P4AAzaWAgAAC6QCAAX46AIAADgqAgAACsgCAAFCfgIABVzOAgABZmIA=
Importance: high
X-Priority: 1
Date: Wed, 22 Jan 2014 16:20:49 +0000
Message-ID: <4C6BB9DC-93EA-4139-BDEC-0C51D30C43C1@cisco.com>
References: <20131213005747.777.34301.idtracker@ietfa.amsl.com>  <7594FB04B1934943A5C02806D1A2204B1D104D91@ESESSMB209.ericsson.se>    <7594FB04B1934943A5C02806D1A2204B1D10A3A1@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D11137F@ESESSMB209.ericsson.se>  <7594FB04B1934943A5C02806D1A2204B1D11142F@ESESSMB209.ericsson.se>  <7594FB04B1934943A5C02806D1A2204B1D114F40@ESESSMB209.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D114F40@ESESSMB209.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.116.132.51]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: DISPATCH , "draft-pd-dispatch-msrp-websocket@tools.ietf.org" 
Subject: Re: [dispatch] I-D Action: draft-pd-dispatch-msrp-websocket-03.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: Wed, 22 Jan 2014 16:20:54 -0000

Hi Christer -=20


On Jan 22, 2014, at 6:00 AM, Christer Holmberg  wrote:

> Hi Gonzalo,
>=20
>> So just to be explicit; despite DC being the preferred transport for 3GP=
P, are we are still waiting on supplementary text from you on MSRP-CEMA=20
>> for this MSRPoWS draft?  If so, when do we expect to have that so we can=
 progress the draft?  We have some pending edits to make after Ben=20
>> and Mary's reviews, but we plan to publish a new version soon. It would =
be good to incorporate this new text along with those other edits.
>=20
> As there is no 3GPP connection, I would have to put this pretty far down =
on my priority list. And, as I don't want to hold the work, I guess the bes=
t thing is for you to move on with the work.

OK. I didn't think the text contribution you would be proposing would be th=
at significant.  Were you?  I'm happy to work with you on it if you'd like =
or we can discuss in London if you prefer.  I certainly don't want to lock =
you out from making the contribution you wanted.
>=20
> Mabye you could add a note to the draft, saying something like:
>=20
> "NOTE: As the WebSocket server acts as a MSRP relay, the usage of MSRP-CE=
MA [RFC6714] will be disabled in most cases. A mechanism where the WebServe=
r does not act as a MSRP relay is outside the scope of this document, and w=
ould have to be defined in a specification."=20
>=20
> In addition, I think it would be good to point out that RFC 6135 (An Alte=
rnative Connection Model for the MSRP) CAN be used with MSRP over WebSocket=
. That has no impact on the mechanism itself, and is not impacted by the us=
age of relays.

Sounds reasonable, but it doesn't need to be in lieu of the more detailed c=
ontribution you suggested earlier if we can get it done in a reasonable amo=
unt of time.

Cheers,

Gonzalo

>=20
> Regards,
>=20
> Christer
>=20
>=20
>=20
>=20
>> Hi,
>>=20
>>> I believe current approach for 3GPP (WebRTC access to IMS) is datachann=
el transport for both MSRP and BFCP being open to other mechanisms like web=
socket.
>>=20
>> Correct.
>>=20
>> Regards,
>>=20
>> Christer
>>=20
>>=20
>>=20
>>=20
>>=20
>> 2014/1/21 Christer Holmberg  Hi,
>>=20
>> I made a false statement earlier, regarding 3GPP.
>>=20
>> 3GPP does not have requirement to transport MSRP over WebSocket.
>>=20
>> Sorry for the confusion.
>>=20
>> Regards,
>>=20
>> Christer
>>=20
>> L=E4hett=E4j=E4: dispatch [mailto:dispatch-bounces@ietf.org] Puolesta=20
>> Christer Holmberg
>> L=E4hetetty: 20. tammikuuta 2014 11:55
>> Vastaanottaja: Peter Dunkley
>> Kopio: DISPATCH; Ben Campbell;=20
>> draft-pd-dispatch-msrp-websocket@tools.ietf.org
>>=20
>> Aihe: Re: [dispatch] I-D Action:=20
>> draft-pd-dispatch-msrp-websocket-03.txt
>>=20
>> Hi Peter,
>>=20
>> I am willing to help, and contribute text.
>>=20
>> But, I request that we don't move the document forward before I've had=20
>> a chance to do that :)
>>=20
>> (3GPP also has a requirement to specify the usage of MSRP over=20
>> WebSocket.)
>>=20
>> Regards,
>>=20
>> Christer
>>=20
>> L=E4hett=E4j=E4: Peter Dunkley [mailto:peter.dunkley@crocodilertc.net]
>> L=E4hetetty: 20. tammikuuta 2014 11:45
>> Vastaanottaja: Christer Holmberg
>> Kopio: Mary Barnes; DISPATCH; Ben Campbell;=20
>> draft-pd-dispatch-msrp-websocket@tools.ietf.org
>> Aihe: Re: [dispatch] I-D Action:=20
>> draft-pd-dispatch-msrp-websocket-03.txt
>>=20
>> Hi Christer,
>>=20
>> There is working code for the document as-is and plans for more implemen=
tations. I think that if someone has a need for MSRP-CEMA in this scenario =
then they should join with the current authors to contribute the text and w=
orking code for this.
>>=20
>> Regards,
>>=20
>> Peter
>>=20
>>=20
>> On 20 January 2014 03:28, Christer Holmberg  wrote:
>> Hi,
>>=20
>> I see no reason why it should be a separate document, as it should not h=
ave any affect on the websocket specific procedures, which is the main scop=
e of the document.
>>=20
>> Regards,
>>=20
>> Christer
>>=20
>> Sent from my Sony Ericsson Xperia arc S
>>=20
>> Peter Dunkley  wrote:
>>=20
>> Hello,
>>=20
>> Perhaps the document title should be corrected. MSRP-CEMA is outside of =
the scope of this document as this document is intended to describe connect=
ing to a WebSocket server that is an MSRP relay.
>>=20
>> I can see no reason why MSRP-CEMA can't be used over WebSockets, but if =
anyone has an interest in this I think that they should put it in a documen=
t of its own.
>>=20
>>=20
>> Regards,
>>=20
>> Peter
>>=20
>>=20
>> On 18 January 2014 08:52, Christer Holmberg  wrote:
>> Hi,
>>=20
>> I have not followed the work on this draft, so I appologize if the follo=
wing has been discussed.
>>=20
>> While I do understand that a WS Client has to establish the WebSocket wi=
th the Web Server, I don't understand why we need to mandate the WS Server =
to be an MSRP Relay. That would e.g. prevent the usage of MSRP-CEMA.
>>=20
>> Regards,
>>=20
>> Christer
>>=20
>>=20
>>=20
>> L=E4hett=E4j=E4: dispatch [mailto:dispatch-bounces@ietf.org] Puolesta Ma=
ry=20
>> Barnes
>> L=E4hetetty: 11. tammikuuta 2014 0:59
>> Vastaanottaja: DISPATCH
>> Kopio: Ben Campbell; draft-pd-dispatch-msrp-websocket@tools.ietf.org
>> Aihe: Re: [dispatch] I-D Action:=20
>> draft-pd-dispatch-msrp-websocket-03.txt
>>=20
>> I have agreed to shepherd this document.  I've reviewed the document in =
anticipation of doing the PROTO write-up and have the following comments an=
d questions.  Ben Campbell has agreed to do the required expert review and =
that should be posted within the next week or so.    This is also a good ti=
me for anyone in the WG that hasn't previously reviewed this document to re=
view and provide any final comments.  Note, that this document was agreed t=
o be AD sponsored around the IETF-86 timeframe.
>>=20
>> Regards,
>> Mary.=20
>>=20
>> Review Summary: Almost ready. Comments & questions below.
>>=20
>> 1)  Section 2 & General.  I'm not sure the documented approach for separ=
ating normative text from non-normative is quite so helpful.  In general, w=
e expect that in the case of standards track document use RFC 2119 language=
 to indicate normative behaviors.  I think the first sentence is good, but =
that's not a terminology thing.   I just don't see a lot of value in writin=
g the document this way.  For example, the definitions aren't stated to be =
non-normative, but I don't see anything normative about the definitions.  I=
 think you could easily title Section 3 as "WebSocket Protocol overview" an=
d that would clearly imply non-normative behavior.  There are also several =
places in the document in sections that I believe are intended to provide n=
ormative behavior, but there is certainly non-normative text in those secti=
ons (e.g., section 5.2.2, second paragraph).  I would suggest this document=
 follow the typical (and accepted) style of identifying normative behavior =
with 2119 language (consistently using upper case for normative behavior an=
d avoiding using 2119 language in cases where alternative words can be subs=
tituted).
>>=20
>> 2) Section 5.2.2, 2nd paragraph.  Related to my point above, it's not cl=
ear to me this is normative behavior.  I don't think it is since it's refer=
ring to existing 4975 behavior. However, I didn't see that the reference gi=
ven in 4975 relates to the second part of that sentence stating that implem=
entations "should" already be allowing unrecognized transports.  It would b=
e quite useful to have the exact reference here as I was trying to double c=
heck this point and I couldn't find it.=20
>>=20
>> 3) Section 6.  I'm really puzzled as to why the Connection Keep-alive wo=
uld be non-normative.  In particular given that 2119 language is clearly be=
ing used. =20
>>=20
>> 4) Section 7.  Again, I'm puzzled as to why Authentication is considered=
 non-normative. AGain, you have 2119 language in this section. =20
>>=20
>> 5) Section 10.1. Since securing the connection is just RECOMMENDED, what=
 are the implications and risks if the MSRP traffic isn't transported over =
a secure connection?=20
>>=20
>> 6) Section 11.  You should change the name of the registry to be the exa=
ct name of the IANA registry to avoid any confusion.- i.e.,:
>> OLD:
>>  registry of WebSocket sub-protocols
>> NEW:=20
>>  WebSocket Subprotocol Name Registry
>>=20
>> 7) Section 11. There is also a Reference field in that IANA registry. I =
would suggest you use the same information as the pointer to the Subprotoco=
l Definition (i.e., this RFC).=20
>>=20
>> 8) It's typical for documents that are updating existing RFCs to have a =
section that summarizes the updates to the existing RFCs that are made by t=
his document. =20
>>=20
>>=20
>>=20
>> On Thu, Dec 12, 2013 at 6:57 PM,  wrote:
>>=20
>> A New Internet-Draft is available from the on-line Internet-Drafts direc=
tories.
>>=20
>>=20
>>        Title           : The WebSocket Protocol as a Transport for the M=
essage Session Relay Protocol (MSRP)
>>        Author(s)       : Peter Dunkley
>>                          Gavin Llewellyn
>>                          Victor Pascual
>>                          Anton Roman
>>                          Gonzalo Salgueiro
>>        Filename        : draft-pd-dispatch-msrp-websocket-03.txt
>>        Pages           : 21
>>        Date            : 2013-12-12
>>=20
>> Abstract:
>>   The WebSocket protocol enables two-way real-time communication
>>   between clients and servers.  This document specifies a new WebSocket
>>   sub-protocol as a reliable transport mechanism between MSRP (Message
>>   Session Relay Protocol) clients and relays to enable usage of MSRP in
>>   new scenarios.  This document normatively updates RFC 4975 and RFC
>>   4976.
>>=20
>>=20
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-pd-dispatch-msrp-websocket
>>=20
>> There's also a htmlized version available at:
>> http://tools.ietf.org/html/draft-pd-dispatch-msrp-websocket-03
>>=20
>> A diff from the previous version is available at:
>> http://www.ietf.org/rfcdiff?url2=3Ddraft-pd-dispatch-msrp-websocket-03
>>=20
>>=20
>> Please note that it may take a couple of minutes from the time of=20
>> submission until the htmlized version and diff are available at tools.ie=
tf.org.
>>=20
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>=20
>> _______________________________________________
>> I-D-Announce mailing list
>> I-D-Announce@ietf.org
>> https://www.ietf.org/mailman/listinfo/i-d-announce
>> Internet-Draft directories: http://www.ietf.org/shadow.html or=20
>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>=20
>>=20
>>=20
>>=20
>> --
>> Peter Dunkley
>> Technical Director
>> Crocodile RCS Ltd
>>=20
>>=20
>>=20
>> --
>> Peter Dunkley
>> Technical Director
>> Crocodile RCS Ltd
>>=20
>> _______________________________________________
>> dispatch mailing list
>> dispatch@ietf.org
>> https://www.ietf.org/mailman/listinfo/dispatch
>=20


From christer.holmberg@ericsson.com  Wed Jan 22 08:26:36 2014
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 1E2901A014B for ; Wed, 22 Jan 2014 08:26:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.258
X-Spam-Level: 
X-Spam-Status: No, score=-0.258 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=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 i4HX0t0sEFHz for ; Wed, 22 Jan 2014 08:26:33 -0800 (PST)
Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 7247D1A035D for ; Wed, 22 Jan 2014 08:26:32 -0800 (PST)
X-AuditID: c1b4fb32-b7f4c8e0000012f5-29-52dff136d1ad
Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 04.63.04853.631FFD25; Wed, 22 Jan 2014 17:26:31 +0100 (CET)
Received: from ESESSMB209.ericsson.se ([169.254.9.114]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.02.0387.000; Wed, 22 Jan 2014 17:26:30 +0100
From: Christer Holmberg 
To: "gsalguei@cisco.com" 
Thread-Topic: [dispatch] I-D Action: draft-pd-dispatch-msrp-websocket-03.txt
Thread-Index: AQHPDleQGzr1Sxm0FkKTa2Dy1OUwAJqKNznggAHW2ICAAPS5P4AAWE2AgAAStzCAAX6poP///cyAgAATWxCAAD/2gIABY5aggABNNoCAABJaoA==
Date: Wed, 22 Jan 2014 16:26:30 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1D1156CE@ESESSMB209.ericsson.se>
References: <20131213005747.777.34301.idtracker@ietfa.amsl.com>  <7594FB04B1934943A5C02806D1A2204B1D104D91@ESESSMB209.ericsson.se>    <7594FB04B1934943A5C02806D1A2204B1D10A3A1@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D11137F@ESESSMB209.ericsson.se>  <7594FB04B1934943A5C02806D1A2204B1D11142F@ESESSMB209.ericsson.se>  <7594FB04B1934943A5C02806D1A2204B1D114F40@ESESSMB209.ericsson.se>, <4C6BB9DC-93EA-4139-BDEC-0C51D30C43C1@cisco.com>
In-Reply-To: <4C6BB9DC-93EA-4139-BDEC-0C51D30C43C1@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D1156CEESESSMB209erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrCLMWRmVeSWpSXmKPExsUyM+Jvja75x/tBBlePc1osnbSA1eLyls/s FnOn+Dkwe0z5vZHVY8mSn0weXy5/ZgtgjuKySUnNySxLLdK3S+DKmHPyAUvBsh1MFR1n/RoY J2xg6mLk5JAQMJFYcvYYM4QtJnHh3nq2LkYuDiGBE4wSpz4cZoJwljBKnP+0D8jh4GATsJDo /qcN0iAioCvxZspLZpAaZoFORom597eATRIW8JY4e+0nG0SRj8TN7QeYIOw6ie3Xd7GCzGER UJWY3OINEuYV8JVYd3s+1OILbBJzz65gBElwCthK/P68lR3EZgS67vupNWBzmAXEJW49mQ/1 gYDEkj3noT4QlXj5+B8rRE2+xIVZR1kgFghKnJz5hGUCo8gsJO2zkJTNQlI2C+g8ZgFNifW7 9CFKFCWmdD9kh7A1JFrnzGVHFl/AyL6KUbI4tbg4N93IQC83PbdEL7UoM7m4OD9Przh1EyMw 5g5u+W20g/HkHvtDjNIcLErivNdZa4KEBNITS1KzU1MLUovii0pzUosPMTJxcEo1MMr3y957 9TjL/GVXiq0rH19h0nkjduMe/wxTi69yaRtdspVnLVtg+L/Qu5aj6c6vXI5th2NiJLVvZ55d s/hl3kfGNZ+trZbVXPzY+sn76/FrIYptDxL3fElsu8ywaJrYXROfNY0O31652KaI+6gcuf3m bsyes1d9Mp4o3mw7rfri6cyVby65HlRiKc5INNRiLipOBABle925hwIAAA==
Cc: DISPATCH , "draft-pd-dispatch-msrp-websocket@tools.ietf.org" 
Subject: Re: [dispatch] I-D Action: draft-pd-dispatch-msrp-websocket-03.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: Wed, 22 Jan 2014 16:26:36 -0000

--_000_7594FB04B1934943A5C02806D1A2204B1D1156CEESESSMB209erics_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGksDQoNCkkgZG9uJ3QgdGhpbmsgdGhlcmUgd291bGQgYmUgbXVjaCB0ZXh0IG5lZWRlZCB0byBj
b3ZlciBDRU1BLiBCdXQsIEkgdGhvdWdodCB5b3Ugd2FudGVkIHRoZSB0ZXh0IHllc3RlcmRheTpp
c2gg8J+Yig0KDQpCdXQsIGlmIHlvdSB3YW50IHRvIHRhbGsgYWJvdXQgaXQsIGFuZCB3ZSBoYXZl
IHNvbWUgdGltZSwgSeKAmWxsIGJlIGhhcHB5IHRvIGNvbnRyaWJ1dGUuDQoNClJlZ2FyZHMsDQoN
CkNocmlzdGVyDQoNClNlbnQgZnJvbSBXaW5kb3dzIE1haWwNCg0KRnJvbTogZ3NhbGd1ZWlAY2lz
Y28uY29tPG1haWx0bzpnc2FsZ3VlaUBjaXNjby5jb20+DQpTZW50OiDigI5XZWRuZXNkYXnigI4s
IOKAjkphbnVhcnnigI4g4oCOMjLigI4sIOKAjjIwMTQg4oCONuKAjjrigI4yMOKAjiDigI5QTQ0K
VG86IEhhbnMtQ2hyaXN0ZXIgSG9sbWJlcmc8bWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNz
c29uLmNvbT4NCkNjOiBESVNQQVRDSDxtYWlsdG86ZGlzcGF0Y2hAaWV0Zi5vcmc+LCBkcmFmdC1w
ZC1kaXNwYXRjaC1tc3JwLXdlYnNvY2tldEB0b29scy5pZXRmLm9yZzxtYWlsdG86ZHJhZnQtcGQt
ZGlzcGF0Y2gtbXNycC13ZWJzb2NrZXRAdG9vbHMuaWV0Zi5vcmc+DQoNCkhpIENocmlzdGVyIC0N
Cg0KDQpPbiBKYW4gMjIsIDIwMTQsIGF0IDY6MDAgQU0sIENocmlzdGVyIEhvbG1iZXJnIDxjaHJp
c3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+IHdyb3RlOg0KDQo+IEhpIEdvbnphbG8sDQo+DQo+
PiBTbyBqdXN0IHRvIGJlIGV4cGxpY2l0OyBkZXNwaXRlIERDIGJlaW5nIHRoZSBwcmVmZXJyZWQg
dHJhbnNwb3J0IGZvciAzR1BQLCBhcmUgd2UgYXJlIHN0aWxsIHdhaXRpbmcgb24gc3VwcGxlbWVu
dGFyeSB0ZXh0IGZyb20geW91IG9uIE1TUlAtQ0VNQQ0KPj4gZm9yIHRoaXMgTVNSUG9XUyBkcmFm
dD8gIElmIHNvLCB3aGVuIGRvIHdlIGV4cGVjdCB0byBoYXZlIHRoYXQgc28gd2UgY2FuIHByb2dy
ZXNzIHRoZSBkcmFmdD8gIFdlIGhhdmUgc29tZSBwZW5kaW5nIGVkaXRzIHRvIG1ha2UgYWZ0ZXIg
QmVuDQo+PiBhbmQgTWFyeSdzIHJldmlld3MsIGJ1dCB3ZSBwbGFuIHRvIHB1Ymxpc2ggYSBuZXcg
dmVyc2lvbiBzb29uLiBJdCB3b3VsZCBiZSBnb29kIHRvIGluY29ycG9yYXRlIHRoaXMgbmV3IHRl
eHQgYWxvbmcgd2l0aCB0aG9zZSBvdGhlciBlZGl0cy4NCj4NCj4gQXMgdGhlcmUgaXMgbm8gM0dQ
UCBjb25uZWN0aW9uLCBJIHdvdWxkIGhhdmUgdG8gcHV0IHRoaXMgcHJldHR5IGZhciBkb3duIG9u
IG15IHByaW9yaXR5IGxpc3QuIEFuZCwgYXMgSSBkb24ndCB3YW50IHRvIGhvbGQgdGhlIHdvcmss
IEkgZ3Vlc3MgdGhlIGJlc3QgdGhpbmcgaXMgZm9yIHlvdSB0byBtb3ZlIG9uIHdpdGggdGhlIHdv
cmsuDQoNCk9LLiBJIGRpZG4ndCB0aGluayB0aGUgdGV4dCBjb250cmlidXRpb24geW91IHdvdWxk
IGJlIHByb3Bvc2luZyB3b3VsZCBiZSB0aGF0IHNpZ25pZmljYW50LiAgV2VyZSB5b3U/ICBJJ20g
aGFwcHkgdG8gd29yayB3aXRoIHlvdSBvbiBpdCBpZiB5b3UnZCBsaWtlIG9yIHdlIGNhbiBkaXNj
dXNzIGluIExvbmRvbiBpZiB5b3UgcHJlZmVyLiAgSSBjZXJ0YWlubHkgZG9uJ3Qgd2FudCB0byBs
b2NrIHlvdSBvdXQgZnJvbSBtYWtpbmcgdGhlIGNvbnRyaWJ1dGlvbiB5b3Ugd2FudGVkLg0KPg0K
PiBNYWJ5ZSB5b3UgY291bGQgYWRkIGEgbm90ZSB0byB0aGUgZHJhZnQsIHNheWluZyBzb21ldGhp
bmcgbGlrZToNCj4NCj4gIk5PVEU6IEFzIHRoZSBXZWJTb2NrZXQgc2VydmVyIGFjdHMgYXMgYSBN
U1JQIHJlbGF5LCB0aGUgdXNhZ2Ugb2YgTVNSUC1DRU1BIFtSRkM2NzE0XSB3aWxsIGJlIGRpc2Fi
bGVkIGluIG1vc3QgY2FzZXMuIEEgbWVjaGFuaXNtIHdoZXJlIHRoZSBXZWJTZXJ2ZXIgZG9lcyBu
b3QgYWN0IGFzIGEgTVNSUCByZWxheSBpcyBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGlzIGRvY3Vt
ZW50LCBhbmQgd291bGQgaGF2ZSB0byBiZSBkZWZpbmVkIGluIGEgc3BlY2lmaWNhdGlvbi4iDQo+
DQo+IEluIGFkZGl0aW9uLCBJIHRoaW5rIGl0IHdvdWxkIGJlIGdvb2QgdG8gcG9pbnQgb3V0IHRo
YXQgUkZDIDYxMzUgKEFuIEFsdGVybmF0aXZlIENvbm5lY3Rpb24gTW9kZWwgZm9yIHRoZSBNU1JQ
KSBDQU4gYmUgdXNlZCB3aXRoIE1TUlAgb3ZlciBXZWJTb2NrZXQuIFRoYXQgaGFzIG5vIGltcGFj
dCBvbiB0aGUgbWVjaGFuaXNtIGl0c2VsZiwgYW5kIGlzIG5vdCBpbXBhY3RlZCBieSB0aGUgdXNh
Z2Ugb2YgcmVsYXlzLg0KDQpTb3VuZHMgcmVhc29uYWJsZSwgYnV0IGl0IGRvZXNuJ3QgbmVlZCB0
byBiZSBpbiBsaWV1IG9mIHRoZSBtb3JlIGRldGFpbGVkIGNvbnRyaWJ1dGlvbiB5b3Ugc3VnZ2Vz
dGVkIGVhcmxpZXIgaWYgd2UgY2FuIGdldCBpdCBkb25lIGluIGEgcmVhc29uYWJsZSBhbW91bnQg
b2YgdGltZS4NCg0KQ2hlZXJzLA0KDQpHb256YWxvDQoNCj4NCj4gUmVnYXJkcywNCj4NCj4gQ2hy
aXN0ZXINCj4NCj4NCj4NCj4NCj4+IEhpLA0KPj4NCj4+PiBJIGJlbGlldmUgY3VycmVudCBhcHBy
b2FjaCBmb3IgM0dQUCAoV2ViUlRDIGFjY2VzcyB0byBJTVMpIGlzIGRhdGFjaGFubmVsIHRyYW5z
cG9ydCBmb3IgYm90aCBNU1JQIGFuZCBCRkNQIGJlaW5nIG9wZW4gdG8gb3RoZXIgbWVjaGFuaXNt
cyBsaWtlIHdlYnNvY2tldC4NCj4+DQo+PiBDb3JyZWN0Lg0KPj4NCj4+IFJlZ2FyZHMsDQo+Pg0K
Pj4gQ2hyaXN0ZXINCj4+DQo+Pg0KPj4NCj4+DQo+Pg0KPj4gMjAxNC8xLzIxIENocmlzdGVyIEhv
bG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+IEhpLA0KPj4NCj4+IEkgbWFk
ZSBhIGZhbHNlIHN0YXRlbWVudCBlYXJsaWVyLCByZWdhcmRpbmcgM0dQUC4NCj4+DQo+PiAzR1BQ
IGRvZXMgbm90IGhhdmUgcmVxdWlyZW1lbnQgdG8gdHJhbnNwb3J0IE1TUlAgb3ZlciBXZWJTb2Nr
ZXQuDQo+Pg0KPj4gU29ycnkgZm9yIHRoZSBjb25mdXNpb24uDQo+Pg0KPj4gUmVnYXJkcywNCj4+
DQo+PiBDaHJpc3Rlcg0KPj4NCj4+IEzDpGhldHTDpGrDpDogZGlzcGF0Y2ggW21haWx0bzpkaXNw
YXRjaC1ib3VuY2VzQGlldGYub3JnXSBQdW9sZXN0YQ0KPj4gQ2hyaXN0ZXIgSG9sbWJlcmcNCj4+
IEzDpGhldGV0dHk6IDIwLiB0YW1taWt1dXRhIDIwMTQgMTE6NTUNCj4+IFZhc3RhYW5vdHRhamE6
IFBldGVyIER1bmtsZXkNCj4+IEtvcGlvOiBESVNQQVRDSDsgQmVuIENhbXBiZWxsOw0KPj4gZHJh
ZnQtcGQtZGlzcGF0Y2gtbXNycC13ZWJzb2NrZXRAdG9vbHMuaWV0Zi5vcmcNCj4+DQo+PiBBaWhl
OiBSZTogW2Rpc3BhdGNoXSBJLUQgQWN0aW9uOg0KPj4gZHJhZnQtcGQtZGlzcGF0Y2gtbXNycC13
ZWJzb2NrZXQtMDMudHh0DQo+Pg0KPj4gSGkgUGV0ZXIsDQo+Pg0KPj4gSSBhbSB3aWxsaW5nIHRv
IGhlbHAsIGFuZCBjb250cmlidXRlIHRleHQuDQo+Pg0KPj4gQnV0LCBJIHJlcXVlc3QgdGhhdCB3
ZSBkb24ndCBtb3ZlIHRoZSBkb2N1bWVudCBmb3J3YXJkIGJlZm9yZSBJJ3ZlIGhhZA0KPj4gYSBj
aGFuY2UgdG8gZG8gdGhhdCA6KQ0KPj4NCj4+ICgzR1BQIGFsc28gaGFzIGEgcmVxdWlyZW1lbnQg
dG8gc3BlY2lmeSB0aGUgdXNhZ2Ugb2YgTVNSUCBvdmVyDQo+PiBXZWJTb2NrZXQuKQ0KPj4NCj4+
IFJlZ2FyZHMsDQo+Pg0KPj4gQ2hyaXN0ZXINCj4+DQo+PiBMw6RoZXR0w6Rqw6Q6IFBldGVyIER1
bmtsZXkgW21haWx0bzpwZXRlci5kdW5rbGV5QGNyb2NvZGlsZXJ0Yy5uZXRdDQo+PiBMw6RoZXRl
dHR5OiAyMC4gdGFtbWlrdXV0YSAyMDE0IDExOjQ1DQo+PiBWYXN0YWFub3R0YWphOiBDaHJpc3Rl
ciBIb2xtYmVyZw0KPj4gS29waW86IE1hcnkgQmFybmVzOyBESVNQQVRDSDsgQmVuIENhbXBiZWxs
Ow0KPj4gZHJhZnQtcGQtZGlzcGF0Y2gtbXNycC13ZWJzb2NrZXRAdG9vbHMuaWV0Zi5vcmcNCj4+
IEFpaGU6IFJlOiBbZGlzcGF0Y2hdIEktRCBBY3Rpb246DQo+PiBkcmFmdC1wZC1kaXNwYXRjaC1t
c3JwLXdlYnNvY2tldC0wMy50eHQNCj4+DQo+PiBIaSBDaHJpc3RlciwNCj4+DQo+PiBUaGVyZSBp
cyB3b3JraW5nIGNvZGUgZm9yIHRoZSBkb2N1bWVudCBhcy1pcyBhbmQgcGxhbnMgZm9yIG1vcmUg
aW1wbGVtZW50YXRpb25zLiBJIHRoaW5rIHRoYXQgaWYgc29tZW9uZSBoYXMgYSBuZWVkIGZvciBN
U1JQLUNFTUEgaW4gdGhpcyBzY2VuYXJpbyB0aGVuIHRoZXkgc2hvdWxkIGpvaW4gd2l0aCB0aGUg
Y3VycmVudCBhdXRob3JzIHRvIGNvbnRyaWJ1dGUgdGhlIHRleHQgYW5kIHdvcmtpbmcgY29kZSBm
b3IgdGhpcy4NCj4+DQo+PiBSZWdhcmRzLA0KPj4NCj4+IFBldGVyDQo+Pg0KPj4NCj4+IE9uIDIw
IEphbnVhcnkgMjAxNCAwMzoyOCwgQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJn
QGVyaWNzc29uLmNvbT4gd3JvdGU6DQo+PiBIaSwNCj4+DQo+PiBJIHNlZSBubyByZWFzb24gd2h5
IGl0IHNob3VsZCBiZSBhIHNlcGFyYXRlIGRvY3VtZW50LCBhcyBpdCBzaG91bGQgbm90IGhhdmUg
YW55IGFmZmVjdCBvbiB0aGUgd2Vic29ja2V0IHNwZWNpZmljIHByb2NlZHVyZXMsIHdoaWNoIGlz
IHRoZSBtYWluIHNjb3BlIG9mIHRoZSBkb2N1bWVudC4NCj4+DQo+PiBSZWdhcmRzLA0KPj4NCj4+
IENocmlzdGVyDQo+Pg0KPj4gU2VudCBmcm9tIG15IFNvbnkgRXJpY3Nzb24gWHBlcmlhIGFyYyBT
DQo+Pg0KPj4gUGV0ZXIgRHVua2xleSA8cGV0ZXIuZHVua2xleUBjcm9jb2RpbGVydGMubmV0PiB3
cm90ZToNCj4+DQo+PiBIZWxsbywNCj4+DQo+PiBQZXJoYXBzIHRoZSBkb2N1bWVudCB0aXRsZSBz
aG91bGQgYmUgY29ycmVjdGVkLiBNU1JQLUNFTUEgaXMgb3V0c2lkZSBvZiB0aGUgc2NvcGUgb2Yg
dGhpcyBkb2N1bWVudCBhcyB0aGlzIGRvY3VtZW50IGlzIGludGVuZGVkIHRvIGRlc2NyaWJlIGNv
bm5lY3RpbmcgdG8gYSBXZWJTb2NrZXQgc2VydmVyIHRoYXQgaXMgYW4gTVNSUCByZWxheS4NCj4+
DQo+PiBJIGNhbiBzZWUgbm8gcmVhc29uIHdoeSBNU1JQLUNFTUEgY2FuJ3QgYmUgdXNlZCBvdmVy
IFdlYlNvY2tldHMsIGJ1dCBpZiBhbnlvbmUgaGFzIGFuIGludGVyZXN0IGluIHRoaXMgSSB0aGlu
ayB0aGF0IHRoZXkgc2hvdWxkIHB1dCBpdCBpbiBhIGRvY3VtZW50IG9mIGl0cyBvd24uDQo+Pg0K
Pj4NCj4+IFJlZ2FyZHMsDQo+Pg0KPj4gUGV0ZXINCj4+DQo+Pg0KPj4gT24gMTggSmFudWFyeSAy
MDE0IDA4OjUyLCBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24u
Y29tPiB3cm90ZToNCj4+IEhpLA0KPj4NCj4+IEkgaGF2ZSBub3QgZm9sbG93ZWQgdGhlIHdvcmsg
b24gdGhpcyBkcmFmdCwgc28gSSBhcHBvbG9naXplIGlmIHRoZSBmb2xsb3dpbmcgaGFzIGJlZW4g
ZGlzY3Vzc2VkLg0KPj4NCj4+IFdoaWxlIEkgZG8gdW5kZXJzdGFuZCB0aGF0IGEgV1MgQ2xpZW50
IGhhcyB0byBlc3RhYmxpc2ggdGhlIFdlYlNvY2tldCB3aXRoIHRoZSBXZWIgU2VydmVyLCBJIGRv
bid0IHVuZGVyc3RhbmQgd2h5IHdlIG5lZWQgdG8gbWFuZGF0ZSB0aGUgV1MgU2VydmVyIHRvIGJl
IGFuIE1TUlAgUmVsYXkuIFRoYXQgd291bGQgZS5nLiBwcmV2ZW50IHRoZSB1c2FnZSBvZiBNU1JQ
LUNFTUEuDQo+Pg0KPj4gUmVnYXJkcywNCj4+DQo+PiBDaHJpc3Rlcg0KPj4NCj4+DQo+Pg0KPj4g
TMOkaGV0dMOkasOkOiBkaXNwYXRjaCBbbWFpbHRvOmRpc3BhdGNoLWJvdW5jZXNAaWV0Zi5vcmdd
IFB1b2xlc3RhIE1hcnkNCj4+IEJhcm5lcw0KPj4gTMOkaGV0ZXR0eTogMTEuIHRhbW1pa3V1dGEg
MjAxNCAwOjU5DQo+PiBWYXN0YWFub3R0YWphOiBESVNQQVRDSA0KPj4gS29waW86IEJlbiBDYW1w
YmVsbDsgZHJhZnQtcGQtZGlzcGF0Y2gtbXNycC13ZWJzb2NrZXRAdG9vbHMuaWV0Zi5vcmcNCj4+
IEFpaGU6IFJlOiBbZGlzcGF0Y2hdIEktRCBBY3Rpb246DQo+PiBkcmFmdC1wZC1kaXNwYXRjaC1t
c3JwLXdlYnNvY2tldC0wMy50eHQNCj4+DQo+PiBJIGhhdmUgYWdyZWVkIHRvIHNoZXBoZXJkIHRo
aXMgZG9jdW1lbnQuICBJJ3ZlIHJldmlld2VkIHRoZSBkb2N1bWVudCBpbiBhbnRpY2lwYXRpb24g
b2YgZG9pbmcgdGhlIFBST1RPIHdyaXRlLXVwIGFuZCBoYXZlIHRoZSBmb2xsb3dpbmcgY29tbWVu
dHMgYW5kIHF1ZXN0aW9ucy4gIEJlbiBDYW1wYmVsbCBoYXMgYWdyZWVkIHRvIGRvIHRoZSByZXF1
aXJlZCBleHBlcnQgcmV2aWV3IGFuZCB0aGF0IHNob3VsZCBiZSBwb3N0ZWQgd2l0aGluIHRoZSBu
ZXh0IHdlZWsgb3Igc28uICAgIFRoaXMgaXMgYWxzbyBhIGdvb2QgdGltZSBmb3IgYW55b25lIGlu
IHRoZSBXRyB0aGF0IGhhc24ndCBwcmV2aW91c2x5IHJldmlld2VkIHRoaXMgZG9jdW1lbnQgdG8g
cmV2aWV3IGFuZCBwcm92aWRlIGFueSBmaW5hbCBjb21tZW50cy4gIE5vdGUsIHRoYXQgdGhpcyBk
b2N1bWVudCB3YXMgYWdyZWVkIHRvIGJlIEFEIHNwb25zb3JlZCBhcm91bmQgdGhlIElFVEYtODYg
dGltZWZyYW1lLg0KPj4NCj4+IFJlZ2FyZHMsDQo+PiBNYXJ5Lg0KPj4NCj4+IFJldmlldyBTdW1t
YXJ5OiBBbG1vc3QgcmVhZHkuIENvbW1lbnRzICYgcXVlc3Rpb25zIGJlbG93Lg0KPj4NCj4+IDEp
ICBTZWN0aW9uIDIgJiBHZW5lcmFsLiAgSSdtIG5vdCBzdXJlIHRoZSBkb2N1bWVudGVkIGFwcHJv
YWNoIGZvciBzZXBhcmF0aW5nIG5vcm1hdGl2ZSB0ZXh0IGZyb20gbm9uLW5vcm1hdGl2ZSBpcyBx
dWl0ZSBzbyBoZWxwZnVsLiAgSW4gZ2VuZXJhbCwgd2UgZXhwZWN0IHRoYXQgaW4gdGhlIGNhc2Ug
b2Ygc3RhbmRhcmRzIHRyYWNrIGRvY3VtZW50IHVzZSBSRkMgMjExOSBsYW5ndWFnZSB0byBpbmRp
Y2F0ZSBub3JtYXRpdmUgYmVoYXZpb3JzLiAgSSB0aGluayB0aGUgZmlyc3Qgc2VudGVuY2UgaXMg
Z29vZCwgYnV0IHRoYXQncyBub3QgYSB0ZXJtaW5vbG9neSB0aGluZy4gICBJIGp1c3QgZG9uJ3Qg
c2VlIGEgbG90IG9mIHZhbHVlIGluIHdyaXRpbmcgdGhlIGRvY3VtZW50IHRoaXMgd2F5LiAgRm9y
IGV4YW1wbGUsIHRoZSBkZWZpbml0aW9ucyBhcmVuJ3Qgc3RhdGVkIHRvIGJlIG5vbi1ub3JtYXRp
dmUsIGJ1dCBJIGRvbid0IHNlZSBhbnl0aGluZyBub3JtYXRpdmUgYWJvdXQgdGhlIGRlZmluaXRp
b25zLiAgSSB0aGluayB5b3UgY291bGQgZWFzaWx5IHRpdGxlIFNlY3Rpb24gMyBhcyAiV2ViU29j
a2V0IFByb3RvY29sIG92ZXJ2aWV3IiBhbmQgdGhhdCB3b3VsZCBjbGVhcmx5IGltcGx5IG5vbi1u
b3JtYXRpdmUgYmVoYXZpb3IuICBUaGVyZSBhcmUgYWxzbyBzZXZlcmFsIHBsYWNlcyBpbiB0aGUg
ZG9jdW1lbnQgaW4gc2VjdGlvbnMgdGhhdCBJIGJlbGlldmUgYXJlIGludGVuZGVkIHRvIHByb3Zp
ZGUgbm9ybWF0aXZlIGJlaGF2aW9yLCBidXQgdGhlcmUgaXMgY2VydGFpbmx5IG5vbi1ub3JtYXRp
dmUgdGV4dCBpbiB0aG9zZSBzZWN0aW9ucyAoZS5nLiwgc2VjdGlvbiA1LjIuMiwgc2Vjb25kIHBh
cmFncmFwaCkuICBJIHdvdWxkIHN1Z2dlc3QgdGhpcyBkb2N1bWVudCBmb2xsb3cgdGhlIHR5cGlj
YWwgKGFuZCBhY2NlcHRlZCkgc3R5bGUgb2YgaWRlbnRpZnlpbmcgbm9ybWF0aXZlIGJlaGF2aW9y
IHdpdGggMjExOSBsYW5ndWFnZSAoY29uc2lzdGVudGx5IHVzaW5nIHVwcGVyIGNhc2UgZm9yIG5v
cm1hdGl2ZSBiZWhhdmlvciBhbmQgYXZvaWRpbmcgdXNpbmcgMjExOSBsYW5ndWFnZSBpbiBjYXNl
cyB3aGVyZSBhbHRlcm5hdGl2ZSB3b3JkcyBjYW4gYmUgc3Vic3RpdHV0ZWQpLg0KPj4NCj4+IDIp
IFNlY3Rpb24gNS4yLjIsIDJuZCBwYXJhZ3JhcGguICBSZWxhdGVkIHRvIG15IHBvaW50IGFib3Zl
LCBpdCdzIG5vdCBjbGVhciB0byBtZSB0aGlzIGlzIG5vcm1hdGl2ZSBiZWhhdmlvci4gIEkgZG9u
J3QgdGhpbmsgaXQgaXMgc2luY2UgaXQncyByZWZlcnJpbmcgdG8gZXhpc3RpbmcgNDk3NSBiZWhh
dmlvci4gSG93ZXZlciwgSSBkaWRuJ3Qgc2VlIHRoYXQgdGhlIHJlZmVyZW5jZSBnaXZlbiBpbiA0
OTc1IHJlbGF0ZXMgdG8gdGhlIHNlY29uZCBwYXJ0IG9mIHRoYXQgc2VudGVuY2Ugc3RhdGluZyB0
aGF0IGltcGxlbWVudGF0aW9ucyAic2hvdWxkIiBhbHJlYWR5IGJlIGFsbG93aW5nIHVucmVjb2du
aXplZCB0cmFuc3BvcnRzLiAgSXQgd291bGQgYmUgcXVpdGUgdXNlZnVsIHRvIGhhdmUgdGhlIGV4
YWN0IHJlZmVyZW5jZSBoZXJlIGFzIEkgd2FzIHRyeWluZyB0byBkb3VibGUgY2hlY2sgdGhpcyBw
b2ludCBhbmQgSSBjb3VsZG4ndCBmaW5kIGl0Lg0KPj4NCj4+IDMpIFNlY3Rpb24gNi4gIEknbSBy
ZWFsbHkgcHV6emxlZCBhcyB0byB3aHkgdGhlIENvbm5lY3Rpb24gS2VlcC1hbGl2ZSB3b3VsZCBi
ZSBub24tbm9ybWF0aXZlLiAgSW4gcGFydGljdWxhciBnaXZlbiB0aGF0IDIxMTkgbGFuZ3VhZ2Ug
aXMgY2xlYXJseSBiZWluZyB1c2VkLg0KPj4NCj4+IDQpIFNlY3Rpb24gNy4gIEFnYWluLCBJJ20g
cHV6emxlZCBhcyB0byB3aHkgQXV0aGVudGljYXRpb24gaXMgY29uc2lkZXJlZCBub24tbm9ybWF0
aXZlLiBBR2FpbiwgeW91IGhhdmUgMjExOSBsYW5ndWFnZSBpbiB0aGlzIHNlY3Rpb24uDQo+Pg0K
Pj4gNSkgU2VjdGlvbiAxMC4xLiBTaW5jZSBzZWN1cmluZyB0aGUgY29ubmVjdGlvbiBpcyBqdXN0
IFJFQ09NTUVOREVELCB3aGF0IGFyZSB0aGUgaW1wbGljYXRpb25zIGFuZCByaXNrcyBpZiB0aGUg
TVNSUCB0cmFmZmljIGlzbid0IHRyYW5zcG9ydGVkIG92ZXIgYSBzZWN1cmUgY29ubmVjdGlvbj8N
Cj4+DQo+PiA2KSBTZWN0aW9uIDExLiAgWW91IHNob3VsZCBjaGFuZ2UgdGhlIG5hbWUgb2YgdGhl
IHJlZ2lzdHJ5IHRvIGJlIHRoZSBleGFjdCBuYW1lIG9mIHRoZSBJQU5BIHJlZ2lzdHJ5IHRvIGF2
b2lkIGFueSBjb25mdXNpb24uLSBpLmUuLDoNCj4+IE9MRDoNCj4+ICByZWdpc3RyeSBvZiBXZWJT
b2NrZXQgc3ViLXByb3RvY29scw0KPj4gTkVXOg0KPj4gIFdlYlNvY2tldCBTdWJwcm90b2NvbCBO
YW1lIFJlZ2lzdHJ5DQo+Pg0KPj4gNykgU2VjdGlvbiAxMS4gVGhlcmUgaXMgYWxzbyBhIFJlZmVy
ZW5jZSBmaWVsZCBpbiB0aGF0IElBTkEgcmVnaXN0cnkuIEkgd291bGQgc3VnZ2VzdCB5b3UgdXNl
IHRoZSBzYW1lIGluZm9ybWF0aW9uIGFzIHRoZSBwb2ludGVyIHRvIHRoZSBTdWJwcm90b2NvbCBE
ZWZpbml0aW9uIChpLmUuLCB0aGlzIFJGQykuDQo+Pg0KPj4gOCkgSXQncyB0eXBpY2FsIGZvciBk
b2N1bWVudHMgdGhhdCBhcmUgdXBkYXRpbmcgZXhpc3RpbmcgUkZDcyB0byBoYXZlIGEgc2VjdGlv
biB0aGF0IHN1bW1hcml6ZXMgdGhlIHVwZGF0ZXMgdG8gdGhlIGV4aXN0aW5nIFJGQ3MgdGhhdCBh
cmUgbWFkZSBieSB0aGlzIGRvY3VtZW50Lg0KPj4NCj4+DQo+Pg0KPj4gT24gVGh1LCBEZWMgMTIs
IDIwMTMgYXQgNjo1NyBQTSwgPGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4gd3JvdGU6DQo+Pg0K
Pj4gQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50
ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzLg0KPj4NCj4+DQo+PiAgICAgICAgVGl0bGUgICAgICAg
ICAgIDogVGhlIFdlYlNvY2tldCBQcm90b2NvbCBhcyBhIFRyYW5zcG9ydCBmb3IgdGhlIE1lc3Nh
Z2UgU2Vzc2lvbiBSZWxheSBQcm90b2NvbCAoTVNSUCkNCj4+ICAgICAgICBBdXRob3IocykgICAg
ICAgOiBQZXRlciBEdW5rbGV5DQo+PiAgICAgICAgICAgICAgICAgICAgICAgICAgR2F2aW4gTGxl
d2VsbHluDQo+PiAgICAgICAgICAgICAgICAgICAgICAgICAgVmljdG9yIFBhc2N1YWwNCj4+ICAg
ICAgICAgICAgICAgICAgICAgICAgICBBbnRvbiBSb21hbg0KPj4gICAgICAgICAgICAgICAgICAg
ICAgICAgIEdvbnphbG8gU2FsZ3VlaXJvDQo+PiAgICAgICAgRmlsZW5hbWUgICAgICAgIDogZHJh
ZnQtcGQtZGlzcGF0Y2gtbXNycC13ZWJzb2NrZXQtMDMudHh0DQo+PiAgICAgICAgUGFnZXMgICAg
ICAgICAgIDogMjENCj4+ICAgICAgICBEYXRlICAgICAgICAgICAgOiAyMDEzLTEyLTEyDQo+Pg0K
Pj4gQWJzdHJhY3Q6DQo+PiAgIFRoZSBXZWJTb2NrZXQgcHJvdG9jb2wgZW5hYmxlcyB0d28td2F5
IHJlYWwtdGltZSBjb21tdW5pY2F0aW9uDQo+PiAgIGJldHdlZW4gY2xpZW50cyBhbmQgc2VydmVy
cy4gIFRoaXMgZG9jdW1lbnQgc3BlY2lmaWVzIGEgbmV3IFdlYlNvY2tldA0KPj4gICBzdWItcHJv
dG9jb2wgYXMgYSByZWxpYWJsZSB0cmFuc3BvcnQgbWVjaGFuaXNtIGJldHdlZW4gTVNSUCAoTWVz
c2FnZQ0KPj4gICBTZXNzaW9uIFJlbGF5IFByb3RvY29sKSBjbGllbnRzIGFuZCByZWxheXMgdG8g
ZW5hYmxlIHVzYWdlIG9mIE1TUlAgaW4NCj4+ICAgbmV3IHNjZW5hcmlvcy4gIFRoaXMgZG9jdW1l
bnQgbm9ybWF0aXZlbHkgdXBkYXRlcyBSRkMgNDk3NSBhbmQgUkZDDQo+PiAgIDQ5NzYuDQo+Pg0K
Pj4NCj4+IFRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlz
Og0KPj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtcGQtZGlzcGF0Y2gt
bXNycC13ZWJzb2NrZXQNCj4+DQo+PiBUaGVyZSdzIGFsc28gYSBodG1saXplZCB2ZXJzaW9uIGF2
YWlsYWJsZSBhdDoNCj4+IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXBkLWRpc3Bh
dGNoLW1zcnAtd2Vic29ja2V0LTAzDQo+Pg0KPj4gQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZl
cnNpb24gaXMgYXZhaWxhYmxlIGF0Og0KPj4gaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3Vy
bDI9ZHJhZnQtcGQtZGlzcGF0Y2gtbXNycC13ZWJzb2NrZXQtMDMNCj4+DQo+Pg0KPj4gUGxlYXNl
IG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUg
b2YNCj4+IHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJl
IGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCj4+DQo+PiBJbnRlcm5ldC1EcmFmdHMgYXJl
IGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQo+PiBmdHA6Ly9mdHAuaWV0Zi5v
cmcvaW50ZXJuZXQtZHJhZnRzLw0KPj4NCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fDQo+PiBJLUQtQW5ub3VuY2UgbWFpbGluZyBsaXN0DQo+PiBJLUQt
QW5ub3VuY2VAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu
Zm8vaS1kLWFubm91bmNlDQo+PiBJbnRlcm5ldC1EcmFmdCBkaXJlY3RvcmllczogaHR0cDovL3d3
dy5pZXRmLm9yZy9zaGFkb3cuaHRtbCBvcg0KPj4gZnRwOi8vZnRwLmlldGYub3JnL2lldGYvMXNo
YWRvdy1zaXRlcy50eHQNCj4+DQo+Pg0KPj4NCj4+DQo+PiAtLQ0KPj4gUGV0ZXIgRHVua2xleQ0K
Pj4gVGVjaG5pY2FsIERpcmVjdG9yDQo+PiBDcm9jb2RpbGUgUkNTIEx0ZA0KPj4NCj4+DQo+Pg0K
Pj4gLS0NCj4+IFBldGVyIER1bmtsZXkNCj4+IFRlY2huaWNhbCBEaXJlY3Rvcg0KPj4gQ3JvY29k
aWxlIFJDUyBMdGQNCj4+DQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fXw0KPj4gZGlzcGF0Y2ggbWFpbGluZyBsaXN0DQo+PiBkaXNwYXRjaEBpZXRmLm9y
Zw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaXNwYXRjaA0KPg0K
DQo=

--_000_7594FB04B1934943A5C02806D1A2204B1D1156CEESESSMB209erics_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9ImdlbmVyYXRvciIgY29udGVu
dD0iV2luZG93cyBNYWlsIDE3LjUuOTYwMC4yMDMxNSI+DQo8c3R5bGUgdHlwZT0idGV4dC9jc3Mi
PjwhLS1odG1sIHsgZm9udC1mYW1pbHk6ICJDb2xvciBFbW9qaSIsICJDYWxpYnJpIiwgIlNlZ29l
IFVJIiwgIk1laXJ5byIsICJNaWNyb3NvZnQgWWFIZWkgVUkiLCAiTWljcm9zb2Z0IEpoZW5nSGVp
IFVJIiwgIk1hbGd1biBHb3RoaWMiLCAic2Fucy1zZXJpZiI7IH0tLT48L3N0eWxlPjxzdHlsZSBk
YXRhLWV4dGVybmFsc3R5bGU9InRydWUiPjwhLS0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29M
aXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaCB7Cm1hcmdpbi10b3A6MGluOwptYXJn
aW4tcmlnaHQ6MGluOwptYXJnaW4tYm90dG9tOjBpbjsKbWFyZ2luLWxlZnQ6LjVpbjsKbWFyZ2lu
LWJvdHRvbTouMDAwMXB0Owp9CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3Jt
YWwgewptYXJnaW46MGluOwptYXJnaW4tYm90dG9tOi4wMDAxcHQ7Cn0KcC5Nc29MaXN0UGFyYWdy
YXBoQ3hTcEZpcnN0LCBsaS5Nc29MaXN0UGFyYWdyYXBoQ3hTcEZpcnN0LCBkaXYuTXNvTGlzdFBh
cmFncmFwaEN4U3BGaXJzdCwgCnAuTXNvTGlzdFBhcmFncmFwaEN4U3BNaWRkbGUsIGxpLk1zb0xp
c3RQYXJhZ3JhcGhDeFNwTWlkZGxlLCBkaXYuTXNvTGlzdFBhcmFncmFwaEN4U3BNaWRkbGUsIApw
Lk1zb0xpc3RQYXJhZ3JhcGhDeFNwTGFzdCwgbGkuTXNvTGlzdFBhcmFncmFwaEN4U3BMYXN0LCBk
aXYuTXNvTGlzdFBhcmFncmFwaEN4U3BMYXN0IHsKbWFyZ2luLXRvcDowaW47Cm1hcmdpbi1yaWdo
dDowaW47Cm1hcmdpbi1ib3R0b206MGluOwptYXJnaW4tbGVmdDouNWluOwptYXJnaW4tYm90dG9t
Oi4wMDAxcHQ7CmxpbmUtaGVpZ2h0OjExNSU7Cn0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5
IGRpcj0ibHRyIj4NCjxkaXYgZGF0YS1leHRlcm5hbHN0eWxlPSJmYWxzZSIgZGlyPSJsdHIiIHN0
eWxlPSJmb250LWZhbWlseTogJ0NhbGlicmknLCAnU2Vnb2UgVUknLCAnTWVpcnlvJywgJ01pY3Jv
c29mdCBZYUhlaSBVSScsICdNaWNyb3NvZnQgSmhlbmdIZWkgVUknLCAnTWFsZ3VuIEdvdGhpYycs
ICdzYW5zLXNlcmlmJztmb250LXNpemU6MTJwdDsiPg0KPGRpdj5IaSw8L2Rpdj4NCjxkaXY+PGJy
Pg0KPC9kaXY+DQo8ZGl2PkkgZG9uJ3QgdGhpbmsgdGhlcmUgd291bGQgYmUgbXVjaCB0ZXh0IG5l
ZWRlZCB0byBjb3ZlciBDRU1BLiBCdXQsIEkgdGhvdWdodCB5b3Ugd2FudGVkIHRoZSB0ZXh0IHll
c3RlcmRheTppc2gg8J+YijwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+QnV0LCBpZiB5
b3Ugd2FudCB0byB0YWxrIGFib3V0IGl0LCBhbmQgd2UgaGF2ZSBzb21lIHRpbWUsIEnigJlsbCBi
ZSBoYXBweSB0byBjb250cmlidXRlLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+UmVn
YXJkcyw8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkNocmlzdGVyPC9kaXY+DQo8ZGl2
Pjxicj4NCjwvZGl2Pg0KPGRpdiBkYXRhLXNpZ25hdHVyZWJsb2NrPSJ0cnVlIj4NCjxkaXY+U2Vu
dCBmcm9tIFdpbmRvd3MgTWFpbDwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp
diBzdHlsZT0icGFkZGluZy10b3A6IDVweDsgYm9yZGVyLXRvcC1jb2xvcjogcmdiKDIyOSwgMjI5
LCAyMjkpOyBib3JkZXItdG9wLXdpZHRoOiAxcHg7IGJvcmRlci10b3Atc3R5bGU6IHNvbGlkOyI+
DQo8ZGl2Pjxmb250IGZhY2U9IiAnQ2FsaWJyaScsICdTZWdvZSBVSScsICdNZWlyeW8nLCAnTWlj
cm9zb2Z0IFlhSGVpIFVJJywgJ01pY3Jvc29mdCBKaGVuZ0hlaSBVSScsICdNYWxndW4gR290aGlj
JywgJ3NhbnMtc2VyaWYnIiBzdHlsZT0ibGluZS1oZWlnaHQ6IDE1cHQ7IGxldHRlci1zcGFjaW5n
OiAwLjAyZW07IGZvbnQtZmFtaWx5OiAmcXVvdDtDYWxpYnJpJnF1b3Q7LCAmcXVvdDtTZWdvZSBV
SSZxdW90OywgJnF1b3Q7TWVpcnlvJnF1b3Q7LCAmcXVvdDtNaWNyb3NvZnQgWWFIZWkgVUkmcXVv
dDssICZxdW90O01pY3Jvc29mdCBKaGVuZ0hlaSBVSSZxdW90OywgJnF1b3Q7TWFsZ3VuIEdvdGhp
YyZxdW90OywgJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsgZm9udC1zaXplOiAxMnB0OyI+PGI+RnJv
bTo8L2I+Jm5ic3A7PGEgaHJlZj0ibWFpbHRvOmdzYWxndWVpQGNpc2NvLmNvbSIgdGFyZ2V0PSJf
cGFyZW50Ij5nc2FsZ3VlaUBjaXNjby5jb208L2E+PGJyPg0KPGI+U2VudDo8L2I+Jm5ic3A74oCO
V2VkbmVzZGF54oCOLCDigI5KYW51YXJ54oCOIOKAjjIy4oCOLCDigI4yMDE0IOKAjjbigI464oCO
MjDigI4g4oCOUE08YnI+DQo8Yj5Ubzo8L2I+Jm5ic3A7PGEgaHJlZj0ibWFpbHRvOmNocmlzdGVy
LmhvbG1iZXJnQGVyaWNzc29uLmNvbSIgdGFyZ2V0PSJfcGFyZW50Ij5IYW5zLUNocmlzdGVyIEhv
bG1iZXJnPC9hPjxicj4NCjxiPkNjOjwvYj4mbmJzcDs8YSBocmVmPSJtYWlsdG86ZGlzcGF0Y2hA
aWV0Zi5vcmciIHRhcmdldD0iX3BhcmVudCI+RElTUEFUQ0g8L2E+LCA8YSBocmVmPSJtYWlsdG86
ZHJhZnQtcGQtZGlzcGF0Y2gtbXNycC13ZWJzb2NrZXRAdG9vbHMuaWV0Zi5vcmciIHRhcmdldD0i
X3BhcmVudCI+DQpkcmFmdC1wZC1kaXNwYXRjaC1tc3JwLXdlYnNvY2tldEB0b29scy5pZXRmLm9y
ZzwvYT48L2ZvbnQ+PC9kaXY+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2IGRpcj0i
Ij4NCjxkaXYgaWQ9InJlYWRpbmdQYW5lQm9keUNvbnRlbnQiPkhpIENocmlzdGVyIC0gPGJyPg0K
PGJyPg0KPGJyPg0KT24gSmFuIDIyLCAyMDE0LCBhdCA2OjAwIEFNLCBDaHJpc3RlciBIb2xtYmVy
ZyAmbHQ7Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tJmd0OyB3cm90ZTo8YnI+DQo8YnI+
DQomZ3Q7IEhpIEdvbnphbG8sPGJyPg0KJmd0OyA8YnI+DQomZ3Q7Jmd0OyBTbyBqdXN0IHRvIGJl
IGV4cGxpY2l0OyBkZXNwaXRlIERDIGJlaW5nIHRoZSBwcmVmZXJyZWQgdHJhbnNwb3J0IGZvciAz
R1BQLCBhcmUgd2UgYXJlIHN0aWxsIHdhaXRpbmcgb24gc3VwcGxlbWVudGFyeSB0ZXh0IGZyb20g
eW91IG9uIE1TUlAtQ0VNQQ0KPGJyPg0KJmd0OyZndDsgZm9yIHRoaXMgTVNSUG9XUyBkcmFmdD8m
bmJzcDsgSWYgc28sIHdoZW4gZG8gd2UgZXhwZWN0IHRvIGhhdmUgdGhhdCBzbyB3ZSBjYW4gcHJv
Z3Jlc3MgdGhlIGRyYWZ0PyZuYnNwOyBXZSBoYXZlIHNvbWUgcGVuZGluZyBlZGl0cyB0byBtYWtl
IGFmdGVyIEJlbg0KPGJyPg0KJmd0OyZndDsgYW5kIE1hcnkncyByZXZpZXdzLCBidXQgd2UgcGxh
biB0byBwdWJsaXNoIGEgbmV3IHZlcnNpb24gc29vbi4gSXQgd291bGQgYmUgZ29vZCB0byBpbmNv
cnBvcmF0ZSB0aGlzIG5ldyB0ZXh0IGFsb25nIHdpdGggdGhvc2Ugb3RoZXIgZWRpdHMuPGJyPg0K
Jmd0OyA8YnI+DQomZ3Q7IEFzIHRoZXJlIGlzIG5vIDNHUFAgY29ubmVjdGlvbiwgSSB3b3VsZCBo
YXZlIHRvIHB1dCB0aGlzIHByZXR0eSBmYXIgZG93biBvbiBteSBwcmlvcml0eSBsaXN0LiBBbmQs
IGFzIEkgZG9uJ3Qgd2FudCB0byBob2xkIHRoZSB3b3JrLCBJIGd1ZXNzIHRoZSBiZXN0IHRoaW5n
IGlzIGZvciB5b3UgdG8gbW92ZSBvbiB3aXRoIHRoZSB3b3JrLjxicj4NCjxicj4NCk9LLiBJIGRp
ZG4ndCB0aGluayB0aGUgdGV4dCBjb250cmlidXRpb24geW91IHdvdWxkIGJlIHByb3Bvc2luZyB3
b3VsZCBiZSB0aGF0IHNpZ25pZmljYW50LiZuYnNwOyBXZXJlIHlvdT8mbmJzcDsgSSdtIGhhcHB5
IHRvIHdvcmsgd2l0aCB5b3Ugb24gaXQgaWYgeW91J2QgbGlrZSBvciB3ZSBjYW4gZGlzY3VzcyBp
biBMb25kb24gaWYgeW91IHByZWZlci4mbmJzcDsgSSBjZXJ0YWlubHkgZG9uJ3Qgd2FudCB0byBs
b2NrIHlvdSBvdXQgZnJvbSBtYWtpbmcgdGhlIGNvbnRyaWJ1dGlvbg0KIHlvdSB3YW50ZWQuPGJy
Pg0KJmd0OyA8YnI+DQomZ3Q7IE1hYnllIHlvdSBjb3VsZCBhZGQgYSBub3RlIHRvIHRoZSBkcmFm
dCwgc2F5aW5nIHNvbWV0aGluZyBsaWtlOjxicj4NCiZndDsgPGJyPg0KJmd0OyAmcXVvdDtOT1RF
OiBBcyB0aGUgV2ViU29ja2V0IHNlcnZlciBhY3RzIGFzIGEgTVNSUCByZWxheSwgdGhlIHVzYWdl
IG9mIE1TUlAtQ0VNQSBbUkZDNjcxNF0gd2lsbCBiZSBkaXNhYmxlZCBpbiBtb3N0IGNhc2VzLiBB
IG1lY2hhbmlzbSB3aGVyZSB0aGUgV2ViU2VydmVyIGRvZXMgbm90IGFjdCBhcyBhIE1TUlAgcmVs
YXkgaXMgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVudCwgYW5kIHdvdWxkIGhhdmUg
dG8gYmUgZGVmaW5lZCBpbiBhIHNwZWNpZmljYXRpb24uJnF1b3Q7DQo8YnI+DQomZ3Q7IDxicj4N
CiZndDsgSW4gYWRkaXRpb24sIEkgdGhpbmsgaXQgd291bGQgYmUgZ29vZCB0byBwb2ludCBvdXQg
dGhhdCBSRkMgNjEzNSAoQW4gQWx0ZXJuYXRpdmUgQ29ubmVjdGlvbiBNb2RlbCBmb3IgdGhlIE1T
UlApIENBTiBiZSB1c2VkIHdpdGggTVNSUCBvdmVyIFdlYlNvY2tldC4gVGhhdCBoYXMgbm8gaW1w
YWN0IG9uIHRoZSBtZWNoYW5pc20gaXRzZWxmLCBhbmQgaXMgbm90IGltcGFjdGVkIGJ5IHRoZSB1
c2FnZSBvZiByZWxheXMuPGJyPg0KPGJyPg0KU291bmRzIHJlYXNvbmFibGUsIGJ1dCBpdCBkb2Vz
bid0IG5lZWQgdG8gYmUgaW4gbGlldSBvZiB0aGUgbW9yZSBkZXRhaWxlZCBjb250cmlidXRpb24g
eW91IHN1Z2dlc3RlZCBlYXJsaWVyIGlmIHdlIGNhbiBnZXQgaXQgZG9uZSBpbiBhIHJlYXNvbmFi
bGUgYW1vdW50IG9mIHRpbWUuPGJyPg0KPGJyPg0KQ2hlZXJzLDxicj4NCjxicj4NCkdvbnphbG88
YnI+DQo8YnI+DQomZ3Q7IDxicj4NCiZndDsgUmVnYXJkcyw8YnI+DQomZ3Q7IDxicj4NCiZndDsg
Q2hyaXN0ZXI8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4N
CiZndDsmZ3Q7IEhpLDxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyBJIGJlbGlldmUg
Y3VycmVudCBhcHByb2FjaCBmb3IgM0dQUCAoV2ViUlRDIGFjY2VzcyB0byBJTVMpIGlzIGRhdGFj
aGFubmVsIHRyYW5zcG9ydCBmb3IgYm90aCBNU1JQIGFuZCBCRkNQIGJlaW5nIG9wZW4gdG8gb3Ro
ZXIgbWVjaGFuaXNtcyBsaWtlIHdlYnNvY2tldC48YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0
OyBDb3JyZWN0Ljxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IFJlZ2FyZHMsPGJyPg0KJmd0
OyZndDsgPGJyPg0KJmd0OyZndDsgQ2hyaXN0ZXI8YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0
OyA8YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7
Jmd0OyAyMDE0LzEvMjEgQ2hyaXN0ZXIgSG9sbWJlcmcgJmx0O2NocmlzdGVyLmhvbG1iZXJnQGVy
aWNzc29uLmNvbSZndDsgSGksPGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZndDsgSSBtYWRlIGEg
ZmFsc2Ugc3RhdGVtZW50IGVhcmxpZXIsIHJlZ2FyZGluZyAzR1BQLjxicj4NCiZndDsmZ3Q7IDxi
cj4NCiZndDsmZ3Q7IDNHUFAgZG9lcyBub3QgaGF2ZSByZXF1aXJlbWVudCB0byB0cmFuc3BvcnQg
TVNSUCBvdmVyIFdlYlNvY2tldC48YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyBTb3JyeSBm
b3IgdGhlIGNvbmZ1c2lvbi48YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyBSZWdhcmRzLDxi
cj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IENocmlzdGVyPGJyPg0KJmd0OyZndDsgPGJyPg0K
Jmd0OyZndDsgTMOkaGV0dMOkasOkOiBkaXNwYXRjaCBbbWFpbHRvOmRpc3BhdGNoLWJvdW5jZXNA
aWV0Zi5vcmddIFB1b2xlc3RhIDxicj4NCiZndDsmZ3Q7IENocmlzdGVyIEhvbG1iZXJnPGJyPg0K
Jmd0OyZndDsgTMOkaGV0ZXR0eTogMjAuIHRhbW1pa3V1dGEgMjAxNCAxMTo1NTxicj4NCiZndDsm
Z3Q7IFZhc3RhYW5vdHRhamE6IFBldGVyIER1bmtsZXk8YnI+DQomZ3Q7Jmd0OyBLb3BpbzogRElT
UEFUQ0g7IEJlbiBDYW1wYmVsbDsgPGJyPg0KJmd0OyZndDsgZHJhZnQtcGQtZGlzcGF0Y2gtbXNy
cC13ZWJzb2NrZXRAdG9vbHMuaWV0Zi5vcmc8YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyBB
aWhlOiBSZTogW2Rpc3BhdGNoXSBJLUQgQWN0aW9uOiA8YnI+DQomZ3Q7Jmd0OyBkcmFmdC1wZC1k
aXNwYXRjaC1tc3JwLXdlYnNvY2tldC0wMy50eHQ8YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0
OyBIaSBQZXRlciw8YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyBJIGFtIHdpbGxpbmcgdG8g
aGVscCwgYW5kIGNvbnRyaWJ1dGUgdGV4dC48YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyBC
dXQsIEkgcmVxdWVzdCB0aGF0IHdlIGRvbid0IG1vdmUgdGhlIGRvY3VtZW50IGZvcndhcmQgYmVm
b3JlIEkndmUgaGFkIDxicj4NCiZndDsmZ3Q7IGEgY2hhbmNlIHRvIGRvIHRoYXQgOik8YnI+DQom
Z3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyAoM0dQUCBhbHNvIGhhcyBhIHJlcXVpcmVtZW50IHRvIHNw
ZWNpZnkgdGhlIHVzYWdlIG9mIE1TUlAgb3ZlciA8YnI+DQomZ3Q7Jmd0OyBXZWJTb2NrZXQuKTxi
cj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IFJlZ2FyZHMsPGJyPg0KJmd0OyZndDsgPGJyPg0K
Jmd0OyZndDsgQ2hyaXN0ZXI8YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyBMw6RoZXR0w6Rq
w6Q6IFBldGVyIER1bmtsZXkgW21haWx0bzpwZXRlci5kdW5rbGV5QGNyb2NvZGlsZXJ0Yy5uZXRd
PGJyPg0KJmd0OyZndDsgTMOkaGV0ZXR0eTogMjAuIHRhbW1pa3V1dGEgMjAxNCAxMTo0NTxicj4N
CiZndDsmZ3Q7IFZhc3RhYW5vdHRhamE6IENocmlzdGVyIEhvbG1iZXJnPGJyPg0KJmd0OyZndDsg
S29waW86IE1hcnkgQmFybmVzOyBESVNQQVRDSDsgQmVuIENhbXBiZWxsOyA8YnI+DQomZ3Q7Jmd0
OyBkcmFmdC1wZC1kaXNwYXRjaC1tc3JwLXdlYnNvY2tldEB0b29scy5pZXRmLm9yZzxicj4NCiZn
dDsmZ3Q7IEFpaGU6IFJlOiBbZGlzcGF0Y2hdIEktRCBBY3Rpb246IDxicj4NCiZndDsmZ3Q7IGRy
YWZ0LXBkLWRpc3BhdGNoLW1zcnAtd2Vic29ja2V0LTAzLnR4dDxicj4NCiZndDsmZ3Q7IDxicj4N
CiZndDsmZ3Q7IEhpIENocmlzdGVyLDxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IFRoZXJl
IGlzIHdvcmtpbmcgY29kZSBmb3IgdGhlIGRvY3VtZW50IGFzLWlzIGFuZCBwbGFucyBmb3IgbW9y
ZSBpbXBsZW1lbnRhdGlvbnMuIEkgdGhpbmsgdGhhdCBpZiBzb21lb25lIGhhcyBhIG5lZWQgZm9y
IE1TUlAtQ0VNQSBpbiB0aGlzIHNjZW5hcmlvIHRoZW4gdGhleSBzaG91bGQgam9pbiB3aXRoIHRo
ZSBjdXJyZW50IGF1dGhvcnMgdG8gY29udHJpYnV0ZSB0aGUgdGV4dCBhbmQgd29ya2luZyBjb2Rl
IGZvciB0aGlzLjxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IFJlZ2FyZHMsPGJyPg0KJmd0
OyZndDsgPGJyPg0KJmd0OyZndDsgUGV0ZXI8YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyA8
YnI+DQomZ3Q7Jmd0OyBPbiAyMCBKYW51YXJ5IDIwMTQgMDM6MjgsIENocmlzdGVyIEhvbG1iZXJn
ICZsdDtjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20mZ3Q7IHdyb3RlOjxicj4NCiZndDsm
Z3Q7IEhpLDxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IEkgc2VlIG5vIHJlYXNvbiB3aHkg
aXQgc2hvdWxkIGJlIGEgc2VwYXJhdGUgZG9jdW1lbnQsIGFzIGl0IHNob3VsZCBub3QgaGF2ZSBh
bnkgYWZmZWN0IG9uIHRoZSB3ZWJzb2NrZXQgc3BlY2lmaWMgcHJvY2VkdXJlcywgd2hpY2ggaXMg
dGhlIG1haW4gc2NvcGUgb2YgdGhlIGRvY3VtZW50Ljxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsm
Z3Q7IFJlZ2FyZHMsPGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZndDsgQ2hyaXN0ZXI8YnI+DQom
Z3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyBTZW50IGZyb20gbXkgU29ueSBFcmljc3NvbiBYcGVyaWEg
YXJjIFM8YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyBQZXRlciBEdW5rbGV5ICZsdDtwZXRl
ci5kdW5rbGV5QGNyb2NvZGlsZXJ0Yy5uZXQmZ3Q7IHdyb3RlOjxicj4NCiZndDsmZ3Q7IDxicj4N
CiZndDsmZ3Q7IEhlbGxvLDxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IFBlcmhhcHMgdGhl
IGRvY3VtZW50IHRpdGxlIHNob3VsZCBiZSBjb3JyZWN0ZWQuIE1TUlAtQ0VNQSBpcyBvdXRzaWRl
IG9mIHRoZSBzY29wZSBvZiB0aGlzIGRvY3VtZW50IGFzIHRoaXMgZG9jdW1lbnQgaXMgaW50ZW5k
ZWQgdG8gZGVzY3JpYmUgY29ubmVjdGluZyB0byBhIFdlYlNvY2tldCBzZXJ2ZXIgdGhhdCBpcyBh
biBNU1JQIHJlbGF5Ljxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IEkgY2FuIHNlZSBubyBy
ZWFzb24gd2h5IE1TUlAtQ0VNQSBjYW4ndCBiZSB1c2VkIG92ZXIgV2ViU29ja2V0cywgYnV0IGlm
IGFueW9uZSBoYXMgYW4gaW50ZXJlc3QgaW4gdGhpcyBJIHRoaW5rIHRoYXQgdGhleSBzaG91bGQg
cHV0IGl0IGluIGEgZG9jdW1lbnQgb2YgaXRzIG93bi48YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7
Jmd0OyA8YnI+DQomZ3Q7Jmd0OyBSZWdhcmRzLDxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7
IFBldGVyPGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZndDsgT24gMTgg
SmFudWFyeSAyMDE0IDA4OjUyLCBDaHJpc3RlciBIb2xtYmVyZyAmbHQ7Y2hyaXN0ZXIuaG9sbWJl
cmdAZXJpY3Nzb24uY29tJmd0OyB3cm90ZTo8YnI+DQomZ3Q7Jmd0OyBIaSw8YnI+DQomZ3Q7Jmd0
OyA8YnI+DQomZ3Q7Jmd0OyBJIGhhdmUgbm90IGZvbGxvd2VkIHRoZSB3b3JrIG9uIHRoaXMgZHJh
ZnQsIHNvIEkgYXBwb2xvZ2l6ZSBpZiB0aGUgZm9sbG93aW5nIGhhcyBiZWVuIGRpc2N1c3NlZC48
YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyBXaGlsZSBJIGRvIHVuZGVyc3RhbmQgdGhhdCBh
IFdTIENsaWVudCBoYXMgdG8gZXN0YWJsaXNoIHRoZSBXZWJTb2NrZXQgd2l0aCB0aGUgV2ViIFNl
cnZlciwgSSBkb24ndCB1bmRlcnN0YW5kIHdoeSB3ZSBuZWVkIHRvIG1hbmRhdGUgdGhlIFdTIFNl
cnZlciB0byBiZSBhbiBNU1JQIFJlbGF5LiBUaGF0IHdvdWxkIGUuZy4gcHJldmVudCB0aGUgdXNh
Z2Ugb2YgTVNSUC1DRU1BLjxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IFJlZ2FyZHMsPGJy
Pg0KJmd0OyZndDsgPGJyPg0KJmd0OyZndDsgQ2hyaXN0ZXI8YnI+DQomZ3Q7Jmd0OyA8YnI+DQom
Z3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyBMw6RoZXR0w6Rqw6Q6IGRpc3Bh
dGNoIFttYWlsdG86ZGlzcGF0Y2gtYm91bmNlc0BpZXRmLm9yZ10gUHVvbGVzdGEgTWFyeSA8YnI+
DQomZ3Q7Jmd0OyBCYXJuZXM8YnI+DQomZ3Q7Jmd0OyBMw6RoZXRldHR5OiAxMS4gdGFtbWlrdXV0
YSAyMDE0IDA6NTk8YnI+DQomZ3Q7Jmd0OyBWYXN0YWFub3R0YWphOiBESVNQQVRDSDxicj4NCiZn
dDsmZ3Q7IEtvcGlvOiBCZW4gQ2FtcGJlbGw7IGRyYWZ0LXBkLWRpc3BhdGNoLW1zcnAtd2Vic29j
a2V0QHRvb2xzLmlldGYub3JnPGJyPg0KJmd0OyZndDsgQWloZTogUmU6IFtkaXNwYXRjaF0gSS1E
IEFjdGlvbjogPGJyPg0KJmd0OyZndDsgZHJhZnQtcGQtZGlzcGF0Y2gtbXNycC13ZWJzb2NrZXQt
MDMudHh0PGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZndDsgSSBoYXZlIGFncmVlZCB0byBzaGVw
aGVyZCB0aGlzIGRvY3VtZW50LiZuYnNwOyBJJ3ZlIHJldmlld2VkIHRoZSBkb2N1bWVudCBpbiBh
bnRpY2lwYXRpb24gb2YgZG9pbmcgdGhlIFBST1RPIHdyaXRlLXVwIGFuZCBoYXZlIHRoZSBmb2xs
b3dpbmcgY29tbWVudHMgYW5kIHF1ZXN0aW9ucy4mbmJzcDsgQmVuIENhbXBiZWxsIGhhcyBhZ3Jl
ZWQgdG8gZG8gdGhlIHJlcXVpcmVkIGV4cGVydCByZXZpZXcgYW5kIHRoYXQgc2hvdWxkIGJlIHBv
c3RlZCB3aXRoaW4gdGhlDQogbmV4dCB3ZWVrIG9yIHNvLiZuYnNwOyZuYnNwOyZuYnNwOyBUaGlz
IGlzIGFsc28gYSBnb29kIHRpbWUgZm9yIGFueW9uZSBpbiB0aGUgV0cgdGhhdCBoYXNuJ3QgcHJl
dmlvdXNseSByZXZpZXdlZCB0aGlzIGRvY3VtZW50IHRvIHJldmlldyBhbmQgcHJvdmlkZSBhbnkg
ZmluYWwgY29tbWVudHMuJm5ic3A7IE5vdGUsIHRoYXQgdGhpcyBkb2N1bWVudCB3YXMgYWdyZWVk
IHRvIGJlIEFEIHNwb25zb3JlZCBhcm91bmQgdGhlIElFVEYtODYgdGltZWZyYW1lLjxicj4NCiZn
dDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IFJlZ2FyZHMsPGJyPg0KJmd0OyZndDsgTWFyeS4gPGJyPg0K
Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsgUmV2aWV3IFN1bW1hcnk6IEFsbW9zdCByZWFkeS4gQ29t
bWVudHMgJmFtcDsgcXVlc3Rpb25zIGJlbG93Ljxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7
IDEpJm5ic3A7IFNlY3Rpb24gMiAmYW1wOyBHZW5lcmFsLiZuYnNwOyBJJ20gbm90IHN1cmUgdGhl
IGRvY3VtZW50ZWQgYXBwcm9hY2ggZm9yIHNlcGFyYXRpbmcgbm9ybWF0aXZlIHRleHQgZnJvbSBu
b24tbm9ybWF0aXZlIGlzIHF1aXRlIHNvIGhlbHBmdWwuJm5ic3A7IEluIGdlbmVyYWwsIHdlIGV4
cGVjdCB0aGF0IGluIHRoZSBjYXNlIG9mIHN0YW5kYXJkcyB0cmFjayBkb2N1bWVudCB1c2UgUkZD
IDIxMTkgbGFuZ3VhZ2UgdG8gaW5kaWNhdGUgbm9ybWF0aXZlIGJlaGF2aW9ycy4mbmJzcDsNCiBJ
IHRoaW5rIHRoZSBmaXJzdCBzZW50ZW5jZSBpcyBnb29kLCBidXQgdGhhdCdzIG5vdCBhIHRlcm1p
bm9sb2d5IHRoaW5nLiZuYnNwOyZuYnNwOyBJIGp1c3QgZG9uJ3Qgc2VlIGEgbG90IG9mIHZhbHVl
IGluIHdyaXRpbmcgdGhlIGRvY3VtZW50IHRoaXMgd2F5LiZuYnNwOyBGb3IgZXhhbXBsZSwgdGhl
IGRlZmluaXRpb25zIGFyZW4ndCBzdGF0ZWQgdG8gYmUgbm9uLW5vcm1hdGl2ZSwgYnV0IEkgZG9u
J3Qgc2VlIGFueXRoaW5nIG5vcm1hdGl2ZSBhYm91dCB0aGUgZGVmaW5pdGlvbnMuJm5ic3A7DQog
SSB0aGluayB5b3UgY291bGQgZWFzaWx5IHRpdGxlIFNlY3Rpb24gMyBhcyAmcXVvdDtXZWJTb2Nr
ZXQgUHJvdG9jb2wgb3ZlcnZpZXcmcXVvdDsgYW5kIHRoYXQgd291bGQgY2xlYXJseSBpbXBseSBu
b24tbm9ybWF0aXZlIGJlaGF2aW9yLiZuYnNwOyBUaGVyZSBhcmUgYWxzbyBzZXZlcmFsIHBsYWNl
cyBpbiB0aGUgZG9jdW1lbnQgaW4gc2VjdGlvbnMgdGhhdCBJIGJlbGlldmUgYXJlIGludGVuZGVk
IHRvIHByb3ZpZGUgbm9ybWF0aXZlIGJlaGF2aW9yLCBidXQgdGhlcmUgaXMNCiBjZXJ0YWlubHkg
bm9uLW5vcm1hdGl2ZSB0ZXh0IGluIHRob3NlIHNlY3Rpb25zIChlLmcuLCBzZWN0aW9uIDUuMi4y
LCBzZWNvbmQgcGFyYWdyYXBoKS4mbmJzcDsgSSB3b3VsZCBzdWdnZXN0IHRoaXMgZG9jdW1lbnQg
Zm9sbG93IHRoZSB0eXBpY2FsIChhbmQgYWNjZXB0ZWQpIHN0eWxlIG9mIGlkZW50aWZ5aW5nIG5v
cm1hdGl2ZSBiZWhhdmlvciB3aXRoIDIxMTkgbGFuZ3VhZ2UgKGNvbnNpc3RlbnRseSB1c2luZyB1
cHBlciBjYXNlIGZvciBub3JtYXRpdmUNCiBiZWhhdmlvciBhbmQgYXZvaWRpbmcgdXNpbmcgMjEx
OSBsYW5ndWFnZSBpbiBjYXNlcyB3aGVyZSBhbHRlcm5hdGl2ZSB3b3JkcyBjYW4gYmUgc3Vic3Rp
dHV0ZWQpLjxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IDIpIFNlY3Rpb24gNS4yLjIsIDJu
ZCBwYXJhZ3JhcGguJm5ic3A7IFJlbGF0ZWQgdG8gbXkgcG9pbnQgYWJvdmUsIGl0J3Mgbm90IGNs
ZWFyIHRvIG1lIHRoaXMgaXMgbm9ybWF0aXZlIGJlaGF2aW9yLiZuYnNwOyBJIGRvbid0IHRoaW5r
IGl0IGlzIHNpbmNlIGl0J3MgcmVmZXJyaW5nIHRvIGV4aXN0aW5nIDQ5NzUgYmVoYXZpb3IuIEhv
d2V2ZXIsIEkgZGlkbid0IHNlZSB0aGF0IHRoZSByZWZlcmVuY2UgZ2l2ZW4gaW4gNDk3NSByZWxh
dGVzIHRvIHRoZSBzZWNvbmQNCiBwYXJ0IG9mIHRoYXQgc2VudGVuY2Ugc3RhdGluZyB0aGF0IGlt
cGxlbWVudGF0aW9ucyAmcXVvdDtzaG91bGQmcXVvdDsgYWxyZWFkeSBiZSBhbGxvd2luZyB1bnJl
Y29nbml6ZWQgdHJhbnNwb3J0cy4mbmJzcDsgSXQgd291bGQgYmUgcXVpdGUgdXNlZnVsIHRvIGhh
dmUgdGhlIGV4YWN0IHJlZmVyZW5jZSBoZXJlIGFzIEkgd2FzIHRyeWluZyB0byBkb3VibGUgY2hl
Y2sgdGhpcyBwb2ludCBhbmQgSSBjb3VsZG4ndCBmaW5kIGl0Lg0KPGJyPg0KJmd0OyZndDsgPGJy
Pg0KJmd0OyZndDsgMykgU2VjdGlvbiA2LiZuYnNwOyBJJ20gcmVhbGx5IHB1enpsZWQgYXMgdG8g
d2h5IHRoZSBDb25uZWN0aW9uIEtlZXAtYWxpdmUgd291bGQgYmUgbm9uLW5vcm1hdGl2ZS4mbmJz
cDsgSW4gcGFydGljdWxhciBnaXZlbiB0aGF0IDIxMTkgbGFuZ3VhZ2UgaXMgY2xlYXJseSBiZWlu
ZyB1c2VkLiZuYnNwOw0KPGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZndDsgNCkgU2VjdGlvbiA3
LiZuYnNwOyBBZ2FpbiwgSSdtIHB1enpsZWQgYXMgdG8gd2h5IEF1dGhlbnRpY2F0aW9uIGlzIGNv
bnNpZGVyZWQgbm9uLW5vcm1hdGl2ZS4gQUdhaW4sIHlvdSBoYXZlIDIxMTkgbGFuZ3VhZ2UgaW4g
dGhpcyBzZWN0aW9uLiZuYnNwOw0KPGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZndDsgNSkgU2Vj
dGlvbiAxMC4xLiBTaW5jZSBzZWN1cmluZyB0aGUgY29ubmVjdGlvbiBpcyBqdXN0IFJFQ09NTUVO
REVELCB3aGF0IGFyZSB0aGUgaW1wbGljYXRpb25zIGFuZCByaXNrcyBpZiB0aGUgTVNSUCB0cmFm
ZmljIGlzbid0IHRyYW5zcG9ydGVkIG92ZXIgYSBzZWN1cmUgY29ubmVjdGlvbj8NCjxicj4NCiZn
dDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IDYpIFNlY3Rpb24gMTEuJm5ic3A7IFlvdSBzaG91bGQgY2hh
bmdlIHRoZSBuYW1lIG9mIHRoZSByZWdpc3RyeSB0byBiZSB0aGUgZXhhY3QgbmFtZSBvZiB0aGUg
SUFOQSByZWdpc3RyeSB0byBhdm9pZCBhbnkgY29uZnVzaW9uLi0gaS5lLiw6PGJyPg0KJmd0OyZn
dDsgT0xEOjxicj4NCiZndDsmZ3Q7Jm5ic3A7IHJlZ2lzdHJ5IG9mIFdlYlNvY2tldCBzdWItcHJv
dG9jb2xzPGJyPg0KJmd0OyZndDsgTkVXOiA8YnI+DQomZ3Q7Jmd0OyZuYnNwOyBXZWJTb2NrZXQg
U3VicHJvdG9jb2wgTmFtZSBSZWdpc3RyeTxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IDcp
IFNlY3Rpb24gMTEuIFRoZXJlIGlzIGFsc28gYSBSZWZlcmVuY2UgZmllbGQgaW4gdGhhdCBJQU5B
IHJlZ2lzdHJ5LiBJIHdvdWxkIHN1Z2dlc3QgeW91IHVzZSB0aGUgc2FtZSBpbmZvcm1hdGlvbiBh
cyB0aGUgcG9pbnRlciB0byB0aGUgU3VicHJvdG9jb2wgRGVmaW5pdGlvbiAoaS5lLiwgdGhpcyBS
RkMpLg0KPGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZndDsgOCkgSXQncyB0eXBpY2FsIGZvciBk
b2N1bWVudHMgdGhhdCBhcmUgdXBkYXRpbmcgZXhpc3RpbmcgUkZDcyB0byBoYXZlIGEgc2VjdGlv
biB0aGF0IHN1bW1hcml6ZXMgdGhlIHVwZGF0ZXMgdG8gdGhlIGV4aXN0aW5nIFJGQ3MgdGhhdCBh
cmUgbWFkZSBieSB0aGlzIGRvY3VtZW50LiZuYnNwOw0KPGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0
OyZndDsgPGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZndDsgT24gVGh1LCBEZWMgMTIsIDIwMTMg
YXQgNjo1NyBQTSwgJmx0O2ludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyZndDsgd3JvdGU6PGJyPg0K
Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsgQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxl
IGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzLjxicj4NCiZndDsm
Z3Q7IDxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRpdGxlJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDogVGhlIFdlYlNvY2tldCBQcm90b2NvbCBhcyBh
IFRyYW5zcG9ydCBmb3IgdGhlIE1lc3NhZ2UgU2Vzc2lvbiBSZWxheSBQcm90b2NvbCAoTVNSUCk8
YnI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBB
dXRob3IocykmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgOiBQZXRlciBEdW5r
bGV5PGJyPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgR2F2
aW4gTGxld2VsbHluPGJyPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsgVmljdG9yIFBhc2N1YWw8YnI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyBBbnRvbiBSb21hbjxicj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7IEdvbnphbG8gU2FsZ3VlaXJvPGJyPg0KJmd0OyZndDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgRmlsZW5hbWUmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgOiBkcmFmdC1wZC1kaXNwYXRjaC1tc3JwLXdl
YnNvY2tldC0wMy50eHQ8YnI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyBQYWdlcyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA6IDIxPGJyPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgRGF0ZSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA6IDIwMTMtMTItMTI8YnI+
DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyBBYnN0cmFjdDo8YnI+DQomZ3Q7Jmd0OyZuYnNwOyZu
YnNwOyBUaGUgV2ViU29ja2V0IHByb3RvY29sIGVuYWJsZXMgdHdvLXdheSByZWFsLXRpbWUgY29t
bXVuaWNhdGlvbjxicj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7IGJldHdlZW4gY2xpZW50cyBhbmQg
c2VydmVycy4mbmJzcDsgVGhpcyBkb2N1bWVudCBzcGVjaWZpZXMgYSBuZXcgV2ViU29ja2V0PGJy
Pg0KJmd0OyZndDsmbmJzcDsmbmJzcDsgc3ViLXByb3RvY29sIGFzIGEgcmVsaWFibGUgdHJhbnNw
b3J0IG1lY2hhbmlzbSBiZXR3ZWVuIE1TUlAgKE1lc3NhZ2U8YnI+DQomZ3Q7Jmd0OyZuYnNwOyZu
YnNwOyBTZXNzaW9uIFJlbGF5IFByb3RvY29sKSBjbGllbnRzIGFuZCByZWxheXMgdG8gZW5hYmxl
IHVzYWdlIG9mIE1TUlAgaW48YnI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyBuZXcgc2NlbmFyaW9z
LiZuYnNwOyBUaGlzIGRvY3VtZW50IG5vcm1hdGl2ZWx5IHVwZGF0ZXMgUkZDIDQ5NzUgYW5kIFJG
Qzxicj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7IDQ5NzYuPGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0
OyZndDsgPGJyPg0KJmd0OyZndDsgVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9y
IHRoaXMgZHJhZnQgaXM6PGJyPg0KJmd0OyZndDsgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y
Zy9kb2MvZHJhZnQtcGQtZGlzcGF0Y2gtbXNycC13ZWJzb2NrZXQ8YnI+DQomZ3Q7Jmd0OyA8YnI+
DQomZ3Q7Jmd0OyBUaGVyZSdzIGFsc28gYSBodG1saXplZCB2ZXJzaW9uIGF2YWlsYWJsZSBhdDo8
YnI+DQomZ3Q7Jmd0OyBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1wZC1kaXNwYXRj
aC1tc3JwLXdlYnNvY2tldC0wMzxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IEEgZGlmZiBm
cm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDo8YnI+DQomZ3Q7Jmd0OyBo
dHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1wZC1kaXNwYXRjaC1tc3JwLXdl
YnNvY2tldC0wMzxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IFBs
ZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0
aW1lIG9mIDxicj4NCiZndDsmZ3Q7IHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNp
b24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy48YnI+DQomZ3Q7Jmd0
OyA8YnI+DQomZ3Q7Jmd0OyBJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFu
b255bW91cyBGVFAgYXQ6PGJyPg0KJmd0OyZndDsgZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0
LWRyYWZ0cy88YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsmZ3Q7IEktRC1Bbm5vdW5jZSBt
YWlsaW5nIGxpc3Q8YnI+DQomZ3Q7Jmd0OyBJLUQtQW5ub3VuY2VAaWV0Zi5vcmc8YnI+DQomZ3Q7
Jmd0OyBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ktZC1hbm5vdW5jZTxi
cj4NCiZndDsmZ3Q7IEludGVybmV0LURyYWZ0IGRpcmVjdG9yaWVzOiBodHRwOi8vd3d3LmlldGYu
b3JnL3NoYWRvdy5odG1sIG9yIDxicj4NCiZndDsmZ3Q7IGZ0cDovL2Z0cC5pZXRmLm9yZy9pZXRm
LzFzaGFkb3ctc2l0ZXMudHh0PGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0
OyZndDsgPGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZndDsgLS08YnI+DQomZ3Q7Jmd0OyBQZXRl
ciBEdW5rbGV5PGJyPg0KJmd0OyZndDsgVGVjaG5pY2FsIERpcmVjdG9yPGJyPg0KJmd0OyZndDsg
Q3JvY29kaWxlIFJDUyBMdGQ8YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7
Jmd0OyA8YnI+DQomZ3Q7Jmd0OyAtLTxicj4NCiZndDsmZ3Q7IFBldGVyIER1bmtsZXk8YnI+DQom
Z3Q7Jmd0OyBUZWNobmljYWwgRGlyZWN0b3I8YnI+DQomZ3Q7Jmd0OyBDcm9jb2RpbGUgUkNTIEx0
ZDxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyZndDsgZGlzcGF0Y2ggbWFpbGluZyBsaXN0
PGJyPg0KJmd0OyZndDsgZGlzcGF0Y2hAaWV0Zi5vcmc8YnI+DQomZ3Q7Jmd0OyBodHRwczovL3d3
dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Rpc3BhdGNoPGJyPg0KJmd0OyA8YnI+DQo8YnI+
DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_7594FB04B1934943A5C02806D1A2204B1D1156CEESESSMB209erics_--


From gsalguei@cisco.com  Wed Jan 22 08:33:44 2014
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 DDFA31A0121 for ; Wed, 22 Jan 2014 08:33:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.036
X-Spam-Level: 
X-Spam-Status: No, score=-10.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 7GaQ7pJTAsf9 for ; Wed, 22 Jan 2014 08:33:41 -0800 (PST)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) by ietfa.amsl.com (Postfix) with ESMTP id 2CF071A0424 for ; Wed, 22 Jan 2014 08:33:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16932; q=dns/txt; s=iport; t=1390408421; x=1391618021; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=MU/+mnM5vARderqEgpczDBw/QLSvVQkAfwlaGS3vImg=; b=iaYN+fcT8kzEzayNfYX0VBqvFX8NrkMNpbHCDG8WfIc6Asu8s56Lxve9 aMTGQANSiAQ/5L4IDC3adE3FemWm5IiviJsiK1h7qu7+T6sIn6m8Im/NT dReagJ5RYfqHVm/Fc/VN6sEtDWKJaKW7tKbGOczFu5YEC5XudLXGBs+gV I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AmUFABPy31KtJXG//2dsb2JhbABbgws4UAaCNEq4EU8YfRZ0giUBAQEDAQEBAQkXBgs3AwsFCwIBAgQCFQECAgIjAwICAiULFAECAQ0CBA4FCYd0CAgFij6bcZwuF4EpjH8DAQEcMweCbzWBFASYIoEyiy6FOIMtgXE5
X-IronPort-AV: E=Sophos;i="4.95,700,1384300800"; d="scan'208";a="14699585"
Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by alln-iport-1.cisco.com with ESMTP; 22 Jan 2014 16:33:39 +0000
Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id s0MGXdVr013209 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 Jan 2014 16:33:39 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.37]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0123.003; Wed, 22 Jan 2014 10:33:38 -0600
From: "Gonzalo Salgueiro (gsalguei)" 
To: Christer Holmberg 
Thread-Topic: [dispatch] I-D Action: draft-pd-dispatch-msrp-websocket-03.txt
Thread-Index: AQHPDleQGzr1Sxm0FkKTa2Dy1OUwAJqKNznggAHW2ICAAPS5P4AAzaWAgAAC6QCAAX46AIAADgqAgAACsgCAAFCfgIABVzOAgABZmICAAAGXAIAAAf2A
Importance: high
X-Priority: 1
Date: Wed, 22 Jan 2014 16:33:37 +0000
Message-ID: 
References: <20131213005747.777.34301.idtracker@ietfa.amsl.com>  <7594FB04B1934943A5C02806D1A2204B1D104D91@ESESSMB209.ericsson.se>    <7594FB04B1934943A5C02806D1A2204B1D10A3A1@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D11137F@ESESSMB209.ericsson.se>  <7594FB04B1934943A5C02806D1A2204B1D11142F@ESESSMB209.ericsson.se>  <7594FB04B1934943A5C02806D1A2204B1D114F40@ESESSMB209.ericsson.se>, <4C6BB9DC-93EA-4139-BDEC-0C51D30C43C1@cisco.com> <7594FB04B1934943A5C02806D1A2204B1D1156CE@ESESSMB209.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D1156CE@ESESSMB209.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.116.132.51]
Content-Type: text/plain; charset="utf-8"
Content-ID: <7A0ADDBB6BEA854EA9BC51DE4A49971F@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: DISPATCH , "draft-pd-dispatch-msrp-websocket@tools.ietf.org" 
Subject: Re: [dispatch] I-D Action: draft-pd-dispatch-msrp-websocket-03.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: Wed, 22 Jan 2014 16:33:45 -0000

DQpPbiBKYW4gMjIsIDIwMTQsIGF0IDExOjI2IEFNLCBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0
ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPiB3cm90ZToNCg0KPiBIaSwNCj4gDQo+IEkgZG9uJ3Qg
dGhpbmsgdGhlcmUgd291bGQgYmUgbXVjaCB0ZXh0IG5lZWRlZCB0byBjb3ZlciBDRU1BLiBCdXQs
IEkgdGhvdWdodCB5b3Ugd2FudGVkIHRoZSB0ZXh0IHllc3RlcmRheTppc2gg8J+Yig0KDQpUaGF0
IHdvdWxkIGJlIG5pY2UsIGJ1dCB0aGlzIGlzIHRoZSBJRVRGIGFmdGVyIGFsbCBhbmQgc3VjaCBz
cGVlZHMgY291bGQgZ2V0IGZvbGtzIGh1cnQgOy0pDQo+IA0KPiBCdXQsIGlmIHlvdSB3YW50IHRv
IHRhbGsgYWJvdXQgaXQsIGFuZCB3ZSBoYXZlIHNvbWUgdGltZSwgSeKAmWxsIGJlIGhhcHB5IHRv
IGNvbnRyaWJ1dGUuDQoNClRoZW4gbGV0J3MgcGxhbiB0byBkbyB0aGF0LiAgSSB0aGluayBpZiB3
ZSBjb3VsZCBhZ3JlZSBvbiBzb21lIGVhcmx5IHRleHQgYnkgdGhlIGRyYWZ0IGRlYWRsaW5lIChG
ZWIgMTQpIHRoYXQgd291bGQgYmUgZ29vZC4gV291bGQgdGhhdCB3b3JrIGZvciB5b3U/DQoNCkdv
bnphbG8NCiANCj4gDQo+IFJlZ2FyZHMsDQo+IA0KPiBDaHJpc3Rlcg0KPiANCj4gU2VudCBmcm9t
IFdpbmRvd3MgTWFpbA0KPiANCj4gRnJvbTogZ3NhbGd1ZWlAY2lzY28uY29tDQo+IFNlbnQ6IOKA
jldlZG5lc2RheeKAjiwg4oCOSmFudWFyeeKAjiDigI4yMuKAjiwg4oCOMjAxNCDigI424oCOOuKA
jjIw4oCOIOKAjlBNDQo+IFRvOiBIYW5zLUNocmlzdGVyIEhvbG1iZXJnDQo+IENjOiBESVNQQVRD
SCwgZHJhZnQtcGQtZGlzcGF0Y2gtbXNycC13ZWJzb2NrZXRAdG9vbHMuaWV0Zi5vcmcNCj4gDQo+
IEhpIENocmlzdGVyIC0gDQo+IA0KPiANCj4gT24gSmFuIDIyLCAyMDE0LCBhdCA2OjAwIEFNLCBD
aHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPiB3cm90ZToN
Cj4gDQo+ID4gSGkgR29uemFsbywNCj4gPiANCj4gPj4gU28ganVzdCB0byBiZSBleHBsaWNpdDsg
ZGVzcGl0ZSBEQyBiZWluZyB0aGUgcHJlZmVycmVkIHRyYW5zcG9ydCBmb3IgM0dQUCwgYXJlIHdl
IGFyZSBzdGlsbCB3YWl0aW5nIG9uIHN1cHBsZW1lbnRhcnkgdGV4dCBmcm9tIHlvdSBvbiBNU1JQ
LUNFTUEgDQo+ID4+IGZvciB0aGlzIE1TUlBvV1MgZHJhZnQ/ICBJZiBzbywgd2hlbiBkbyB3ZSBl
eHBlY3QgdG8gaGF2ZSB0aGF0IHNvIHdlIGNhbiBwcm9ncmVzcyB0aGUgZHJhZnQ/ICBXZSBoYXZl
IHNvbWUgcGVuZGluZyBlZGl0cyB0byBtYWtlIGFmdGVyIEJlbiANCj4gPj4gYW5kIE1hcnkncyBy
ZXZpZXdzLCBidXQgd2UgcGxhbiB0byBwdWJsaXNoIGEgbmV3IHZlcnNpb24gc29vbi4gSXQgd291
bGQgYmUgZ29vZCB0byBpbmNvcnBvcmF0ZSB0aGlzIG5ldyB0ZXh0IGFsb25nIHdpdGggdGhvc2Ug
b3RoZXIgZWRpdHMuDQo+ID4gDQo+ID4gQXMgdGhlcmUgaXMgbm8gM0dQUCBjb25uZWN0aW9uLCBJ
IHdvdWxkIGhhdmUgdG8gcHV0IHRoaXMgcHJldHR5IGZhciBkb3duIG9uIG15IHByaW9yaXR5IGxp
c3QuIEFuZCwgYXMgSSBkb24ndCB3YW50IHRvIGhvbGQgdGhlIHdvcmssIEkgZ3Vlc3MgdGhlIGJl
c3QgdGhpbmcgaXMgZm9yIHlvdSB0byBtb3ZlIG9uIHdpdGggdGhlIHdvcmsuDQo+IA0KPiBPSy4g
SSBkaWRuJ3QgdGhpbmsgdGhlIHRleHQgY29udHJpYnV0aW9uIHlvdSB3b3VsZCBiZSBwcm9wb3Np
bmcgd291bGQgYmUgdGhhdCBzaWduaWZpY2FudC4gIFdlcmUgeW91PyAgSSdtIGhhcHB5IHRvIHdv
cmsgd2l0aCB5b3Ugb24gaXQgaWYgeW91J2QgbGlrZSBvciB3ZSBjYW4gZGlzY3VzcyBpbiBMb25k
b24gaWYgeW91IHByZWZlci4gIEkgY2VydGFpbmx5IGRvbid0IHdhbnQgdG8gbG9jayB5b3Ugb3V0
IGZyb20gbWFraW5nIHRoZSBjb250cmlidXRpb24geW91IHdhbnRlZC4NCj4gPiANCj4gPiBNYWJ5
ZSB5b3UgY291bGQgYWRkIGEgbm90ZSB0byB0aGUgZHJhZnQsIHNheWluZyBzb21ldGhpbmcgbGlr
ZToNCj4gPiANCj4gPiAiTk9URTogQXMgdGhlIFdlYlNvY2tldCBzZXJ2ZXIgYWN0cyBhcyBhIE1T
UlAgcmVsYXksIHRoZSB1c2FnZSBvZiBNU1JQLUNFTUEgW1JGQzY3MTRdIHdpbGwgYmUgZGlzYWJs
ZWQgaW4gbW9zdCBjYXNlcy4gQSBtZWNoYW5pc20gd2hlcmUgdGhlIFdlYlNlcnZlciBkb2VzIG5v
dCBhY3QgYXMgYSBNU1JQIHJlbGF5IGlzIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMgZG9jdW1l
bnQsIGFuZCB3b3VsZCBoYXZlIHRvIGJlIGRlZmluZWQgaW4gYSBzcGVjaWZpY2F0aW9uLiIgDQo+
ID4gDQo+ID4gSW4gYWRkaXRpb24sIEkgdGhpbmsgaXQgd291bGQgYmUgZ29vZCB0byBwb2ludCBv
dXQgdGhhdCBSRkMgNjEzNSAoQW4gQWx0ZXJuYXRpdmUgQ29ubmVjdGlvbiBNb2RlbCBmb3IgdGhl
IE1TUlApIENBTiBiZSB1c2VkIHdpdGggTVNSUCBvdmVyIFdlYlNvY2tldC4gVGhhdCBoYXMgbm8g
aW1wYWN0IG9uIHRoZSBtZWNoYW5pc20gaXRzZWxmLCBhbmQgaXMgbm90IGltcGFjdGVkIGJ5IHRo
ZSB1c2FnZSBvZiByZWxheXMuDQo+IA0KPiBTb3VuZHMgcmVhc29uYWJsZSwgYnV0IGl0IGRvZXNu
J3QgbmVlZCB0byBiZSBpbiBsaWV1IG9mIHRoZSBtb3JlIGRldGFpbGVkIGNvbnRyaWJ1dGlvbiB5
b3Ugc3VnZ2VzdGVkIGVhcmxpZXIgaWYgd2UgY2FuIGdldCBpdCBkb25lIGluIGEgcmVhc29uYWJs
ZSBhbW91bnQgb2YgdGltZS4NCj4gDQo+IENoZWVycywNCj4gDQo+IEdvbnphbG8NCj4gDQo+ID4g
DQo+ID4gUmVnYXJkcywNCj4gPiANCj4gPiBDaHJpc3Rlcg0KPiA+IA0KPiA+IA0KPiA+IA0KPiA+
IA0KPiA+PiBIaSwNCj4gPj4gDQo+ID4+PiBJIGJlbGlldmUgY3VycmVudCBhcHByb2FjaCBmb3Ig
M0dQUCAoV2ViUlRDIGFjY2VzcyB0byBJTVMpIGlzIGRhdGFjaGFubmVsIHRyYW5zcG9ydCBmb3Ig
Ym90aCBNU1JQIGFuZCBCRkNQIGJlaW5nIG9wZW4gdG8gb3RoZXIgbWVjaGFuaXNtcyBsaWtlIHdl
YnNvY2tldC4NCj4gPj4gDQo+ID4+IENvcnJlY3QuDQo+ID4+IA0KPiA+PiBSZWdhcmRzLA0KPiA+
PiANCj4gPj4gQ2hyaXN0ZXINCj4gPj4gDQo+ID4+IA0KPiA+PiANCj4gPj4gDQo+ID4+IA0KPiA+
PiAyMDE0LzEvMjEgQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29u
LmNvbT4gSGksDQo+ID4+IA0KPiA+PiBJIG1hZGUgYSBmYWxzZSBzdGF0ZW1lbnQgZWFybGllciwg
cmVnYXJkaW5nIDNHUFAuDQo+ID4+IA0KPiA+PiAzR1BQIGRvZXMgbm90IGhhdmUgcmVxdWlyZW1l
bnQgdG8gdHJhbnNwb3J0IE1TUlAgb3ZlciBXZWJTb2NrZXQuDQo+ID4+IA0KPiA+PiBTb3JyeSBm
b3IgdGhlIGNvbmZ1c2lvbi4NCj4gPj4gDQo+ID4+IFJlZ2FyZHMsDQo+ID4+IA0KPiA+PiBDaHJp
c3Rlcg0KPiA+PiANCj4gPj4gTMOkaGV0dMOkasOkOiBkaXNwYXRjaCBbbWFpbHRvOmRpc3BhdGNo
LWJvdW5jZXNAaWV0Zi5vcmddIFB1b2xlc3RhIA0KPiA+PiBDaHJpc3RlciBIb2xtYmVyZw0KPiA+
PiBMw6RoZXRldHR5OiAyMC4gdGFtbWlrdXV0YSAyMDE0IDExOjU1DQo+ID4+IFZhc3RhYW5vdHRh
amE6IFBldGVyIER1bmtsZXkNCj4gPj4gS29waW86IERJU1BBVENIOyBCZW4gQ2FtcGJlbGw7IA0K
PiA+PiBkcmFmdC1wZC1kaXNwYXRjaC1tc3JwLXdlYnNvY2tldEB0b29scy5pZXRmLm9yZw0KPiA+
PiANCj4gPj4gQWloZTogUmU6IFtkaXNwYXRjaF0gSS1EIEFjdGlvbjogDQo+ID4+IGRyYWZ0LXBk
LWRpc3BhdGNoLW1zcnAtd2Vic29ja2V0LTAzLnR4dA0KPiA+PiANCj4gPj4gSGkgUGV0ZXIsDQo+
ID4+IA0KPiA+PiBJIGFtIHdpbGxpbmcgdG8gaGVscCwgYW5kIGNvbnRyaWJ1dGUgdGV4dC4NCj4g
Pj4gDQo+ID4+IEJ1dCwgSSByZXF1ZXN0IHRoYXQgd2UgZG9uJ3QgbW92ZSB0aGUgZG9jdW1lbnQg
Zm9yd2FyZCBiZWZvcmUgSSd2ZSBoYWQgDQo+ID4+IGEgY2hhbmNlIHRvIGRvIHRoYXQgOikNCj4g
Pj4gDQo+ID4+ICgzR1BQIGFsc28gaGFzIGEgcmVxdWlyZW1lbnQgdG8gc3BlY2lmeSB0aGUgdXNh
Z2Ugb2YgTVNSUCBvdmVyIA0KPiA+PiBXZWJTb2NrZXQuKQ0KPiA+PiANCj4gPj4gUmVnYXJkcywN
Cj4gPj4gDQo+ID4+IENocmlzdGVyDQo+ID4+IA0KPiA+PiBMw6RoZXR0w6Rqw6Q6IFBldGVyIER1
bmtsZXkgW21haWx0bzpwZXRlci5kdW5rbGV5QGNyb2NvZGlsZXJ0Yy5uZXRdDQo+ID4+IEzDpGhl
dGV0dHk6IDIwLiB0YW1taWt1dXRhIDIwMTQgMTE6NDUNCj4gPj4gVmFzdGFhbm90dGFqYTogQ2hy
aXN0ZXIgSG9sbWJlcmcNCj4gPj4gS29waW86IE1hcnkgQmFybmVzOyBESVNQQVRDSDsgQmVuIENh
bXBiZWxsOyANCj4gPj4gZHJhZnQtcGQtZGlzcGF0Y2gtbXNycC13ZWJzb2NrZXRAdG9vbHMuaWV0
Zi5vcmcNCj4gPj4gQWloZTogUmU6IFtkaXNwYXRjaF0gSS1EIEFjdGlvbjogDQo+ID4+IGRyYWZ0
LXBkLWRpc3BhdGNoLW1zcnAtd2Vic29ja2V0LTAzLnR4dA0KPiA+PiANCj4gPj4gSGkgQ2hyaXN0
ZXIsDQo+ID4+IA0KPiA+PiBUaGVyZSBpcyB3b3JraW5nIGNvZGUgZm9yIHRoZSBkb2N1bWVudCBh
cy1pcyBhbmQgcGxhbnMgZm9yIG1vcmUgaW1wbGVtZW50YXRpb25zLiBJIHRoaW5rIHRoYXQgaWYg
c29tZW9uZSBoYXMgYSBuZWVkIGZvciBNU1JQLUNFTUEgaW4gdGhpcyBzY2VuYXJpbyB0aGVuIHRo
ZXkgc2hvdWxkIGpvaW4gd2l0aCB0aGUgY3VycmVudCBhdXRob3JzIHRvIGNvbnRyaWJ1dGUgdGhl
IHRleHQgYW5kIHdvcmtpbmcgY29kZSBmb3IgdGhpcy4NCj4gPj4gDQo+ID4+IFJlZ2FyZHMsDQo+
ID4+IA0KPiA+PiBQZXRlcg0KPiA+PiANCj4gPj4gDQo+ID4+IE9uIDIwIEphbnVhcnkgMjAxNCAw
MzoyOCwgQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4g
d3JvdGU6DQo+ID4+IEhpLA0KPiA+PiANCj4gPj4gSSBzZWUgbm8gcmVhc29uIHdoeSBpdCBzaG91
bGQgYmUgYSBzZXBhcmF0ZSBkb2N1bWVudCwgYXMgaXQgc2hvdWxkIG5vdCBoYXZlIGFueSBhZmZl
Y3Qgb24gdGhlIHdlYnNvY2tldCBzcGVjaWZpYyBwcm9jZWR1cmVzLCB3aGljaCBpcyB0aGUgbWFp
biBzY29wZSBvZiB0aGUgZG9jdW1lbnQuDQo+ID4+IA0KPiA+PiBSZWdhcmRzLA0KPiA+PiANCj4g
Pj4gQ2hyaXN0ZXINCj4gPj4gDQo+ID4+IFNlbnQgZnJvbSBteSBTb255IEVyaWNzc29uIFhwZXJp
YSBhcmMgUw0KPiA+PiANCj4gPj4gUGV0ZXIgRHVua2xleSA8cGV0ZXIuZHVua2xleUBjcm9jb2Rp
bGVydGMubmV0PiB3cm90ZToNCj4gPj4gDQo+ID4+IEhlbGxvLA0KPiA+PiANCj4gPj4gUGVyaGFw
cyB0aGUgZG9jdW1lbnQgdGl0bGUgc2hvdWxkIGJlIGNvcnJlY3RlZC4gTVNSUC1DRU1BIGlzIG91
dHNpZGUgb2YgdGhlIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQgYXMgdGhpcyBkb2N1bWVudCBpcyBp
bnRlbmRlZCB0byBkZXNjcmliZSBjb25uZWN0aW5nIHRvIGEgV2ViU29ja2V0IHNlcnZlciB0aGF0
IGlzIGFuIE1TUlAgcmVsYXkuDQo+ID4+IA0KPiA+PiBJIGNhbiBzZWUgbm8gcmVhc29uIHdoeSBN
U1JQLUNFTUEgY2FuJ3QgYmUgdXNlZCBvdmVyIFdlYlNvY2tldHMsIGJ1dCBpZiBhbnlvbmUgaGFz
IGFuIGludGVyZXN0IGluIHRoaXMgSSB0aGluayB0aGF0IHRoZXkgc2hvdWxkIHB1dCBpdCBpbiBh
IGRvY3VtZW50IG9mIGl0cyBvd24uDQo+ID4+IA0KPiA+PiANCj4gPj4gUmVnYXJkcywNCj4gPj4g
DQo+ID4+IFBldGVyDQo+ID4+IA0KPiA+PiANCj4gPj4gT24gMTggSmFudWFyeSAyMDE0IDA4OjUy
LCBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPiB3cm90
ZToNCj4gPj4gSGksDQo+ID4+IA0KPiA+PiBJIGhhdmUgbm90IGZvbGxvd2VkIHRoZSB3b3JrIG9u
IHRoaXMgZHJhZnQsIHNvIEkgYXBwb2xvZ2l6ZSBpZiB0aGUgZm9sbG93aW5nIGhhcyBiZWVuIGRp
c2N1c3NlZC4NCj4gPj4gDQo+ID4+IFdoaWxlIEkgZG8gdW5kZXJzdGFuZCB0aGF0IGEgV1MgQ2xp
ZW50IGhhcyB0byBlc3RhYmxpc2ggdGhlIFdlYlNvY2tldCB3aXRoIHRoZSBXZWIgU2VydmVyLCBJ
IGRvbid0IHVuZGVyc3RhbmQgd2h5IHdlIG5lZWQgdG8gbWFuZGF0ZSB0aGUgV1MgU2VydmVyIHRv
IGJlIGFuIE1TUlAgUmVsYXkuIFRoYXQgd291bGQgZS5nLiBwcmV2ZW50IHRoZSB1c2FnZSBvZiBN
U1JQLUNFTUEuDQo+ID4+IA0KPiA+PiBSZWdhcmRzLA0KPiA+PiANCj4gPj4gQ2hyaXN0ZXINCj4g
Pj4gDQo+ID4+IA0KPiA+PiANCj4gPj4gTMOkaGV0dMOkasOkOiBkaXNwYXRjaCBbbWFpbHRvOmRp
c3BhdGNoLWJvdW5jZXNAaWV0Zi5vcmddIFB1b2xlc3RhIE1hcnkgDQo+ID4+IEJhcm5lcw0KPiA+
PiBMw6RoZXRldHR5OiAxMS4gdGFtbWlrdXV0YSAyMDE0IDA6NTkNCj4gPj4gVmFzdGFhbm90dGFq
YTogRElTUEFUQ0gNCj4gPj4gS29waW86IEJlbiBDYW1wYmVsbDsgZHJhZnQtcGQtZGlzcGF0Y2gt
bXNycC13ZWJzb2NrZXRAdG9vbHMuaWV0Zi5vcmcNCj4gPj4gQWloZTogUmU6IFtkaXNwYXRjaF0g
SS1EIEFjdGlvbjogDQo+ID4+IGRyYWZ0LXBkLWRpc3BhdGNoLW1zcnAtd2Vic29ja2V0LTAzLnR4
dA0KPiA+PiANCj4gPj4gSSBoYXZlIGFncmVlZCB0byBzaGVwaGVyZCB0aGlzIGRvY3VtZW50LiAg
SSd2ZSByZXZpZXdlZCB0aGUgZG9jdW1lbnQgaW4gYW50aWNpcGF0aW9uIG9mIGRvaW5nIHRoZSBQ
Uk9UTyB3cml0ZS11cCBhbmQgaGF2ZSB0aGUgZm9sbG93aW5nIGNvbW1lbnRzIGFuZCBxdWVzdGlv
bnMuICBCZW4gQ2FtcGJlbGwgaGFzIGFncmVlZCB0byBkbyB0aGUgcmVxdWlyZWQgZXhwZXJ0IHJl
dmlldyBhbmQgdGhhdCBzaG91bGQgYmUgcG9zdGVkIHdpdGhpbiB0aGUgbmV4dCB3ZWVrIG9yIHNv
LiAgICBUaGlzIGlzIGFsc28gYSBnb29kIHRpbWUgZm9yIGFueW9uZSBpbiB0aGUgV0cgdGhhdCBo
YXNuJ3QgcHJldmlvdXNseSByZXZpZXdlZCB0aGlzIGRvY3VtZW50IHRvIHJldmlldyBhbmQgcHJv
dmlkZSBhbnkgZmluYWwgY29tbWVudHMuICBOb3RlLCB0aGF0IHRoaXMgZG9jdW1lbnQgd2FzIGFn
cmVlZCB0byBiZSBBRCBzcG9uc29yZWQgYXJvdW5kIHRoZSBJRVRGLTg2IHRpbWVmcmFtZS4NCj4g
Pj4gDQo+ID4+IFJlZ2FyZHMsDQo+ID4+IE1hcnkuIA0KPiA+PiANCj4gPj4gUmV2aWV3IFN1bW1h
cnk6IEFsbW9zdCByZWFkeS4gQ29tbWVudHMgJiBxdWVzdGlvbnMgYmVsb3cuDQo+ID4+IA0KPiA+
PiAxKSAgU2VjdGlvbiAyICYgR2VuZXJhbC4gIEknbSBub3Qgc3VyZSB0aGUgZG9jdW1lbnRlZCBh
cHByb2FjaCBmb3Igc2VwYXJhdGluZyBub3JtYXRpdmUgdGV4dCBmcm9tIG5vbi1ub3JtYXRpdmUg
aXMgcXVpdGUgc28gaGVscGZ1bC4gIEluIGdlbmVyYWwsIHdlIGV4cGVjdCB0aGF0IGluIHRoZSBj
YXNlIG9mIHN0YW5kYXJkcyB0cmFjayBkb2N1bWVudCB1c2UgUkZDIDIxMTkgbGFuZ3VhZ2UgdG8g
aW5kaWNhdGUgbm9ybWF0aXZlIGJlaGF2aW9ycy4gIEkgdGhpbmsgdGhlIGZpcnN0IHNlbnRlbmNl
IGlzIGdvb2QsIGJ1dCB0aGF0J3Mgbm90IGEgdGVybWlub2xvZ3kgdGhpbmcuICAgSSBqdXN0IGRv
bid0IHNlZSBhIGxvdCBvZiB2YWx1ZSBpbiB3cml0aW5nIHRoZSBkb2N1bWVudCB0aGlzIHdheS4g
IEZvciBleGFtcGxlLCB0aGUgZGVmaW5pdGlvbnMgYXJlbid0IHN0YXRlZCB0byBiZSBub24tbm9y
bWF0aXZlLCBidXQgSSBkb24ndCBzZWUgYW55dGhpbmcgbm9ybWF0aXZlIGFib3V0IHRoZSBkZWZp
bml0aW9ucy4gIEkgdGhpbmsgeW91IGNvdWxkIGVhc2lseSB0aXRsZSBTZWN0aW9uIDMgYXMgIldl
YlNvY2tldCBQcm90b2NvbCBvdmVydmlldyIgYW5kIHRoYXQgd291bGQgY2xlYXJseSBpbXBseSBu
b24tbm9ybWF0aXZlIGJlaGF2aW9yLiAgVGhlcmUgYXJlIGFsc28gc2V2ZXJhbCBwbGFjZXMgaW4g
dGhlIGRvY3VtZW50IGluIHNlY3Rpb25zIHRoYXQgSSBiZWxpZXZlIGFyZSBpbnRlbmRlZCB0byBw
cm92aWRlIG5vcm1hdGl2ZSBiZWhhdmlvciwgYnV0IHRoZXJlIGlzIGNlcnRhaW5seSBub24tbm9y
bWF0aXZlIHRleHQgaW4gdGhvc2Ugc2VjdGlvbnMgKGUuZy4sIHNlY3Rpb24gNS4yLjIsIHNlY29u
ZCBwYXJhZ3JhcGgpLiAgSSB3b3VsZCBzdWdnZXN0IHRoaXMgZG9jdW1lbnQgZm9sbG93IHRoZSB0
eXBpY2FsIChhbmQgYWNjZXB0ZWQpIHN0eWxlIG9mIGlkZW50aWZ5aW5nIG5vcm1hdGl2ZSBiZWhh
dmlvciB3aXRoIDIxMTkgbGFuZ3VhZ2UgKGNvbnNpc3RlbnRseSB1c2luZyB1cHBlciBjYXNlIGZv
ciBub3JtYXRpdmUgYmVoYXZpb3IgYW5kIGF2b2lkaW5nIHVzaW5nIDIxMTkgbGFuZ3VhZ2UgaW4g
Y2FzZXMgd2hlcmUgYWx0ZXJuYXRpdmUgd29yZHMgY2FuIGJlIHN1YnN0aXR1dGVkKS4NCj4gPj4g
DQo+ID4+IDIpIFNlY3Rpb24gNS4yLjIsIDJuZCBwYXJhZ3JhcGguICBSZWxhdGVkIHRvIG15IHBv
aW50IGFib3ZlLCBpdCdzIG5vdCBjbGVhciB0byBtZSB0aGlzIGlzIG5vcm1hdGl2ZSBiZWhhdmlv
ci4gIEkgZG9uJ3QgdGhpbmsgaXQgaXMgc2luY2UgaXQncyByZWZlcnJpbmcgdG8gZXhpc3Rpbmcg
NDk3NSBiZWhhdmlvci4gSG93ZXZlciwgSSBkaWRuJ3Qgc2VlIHRoYXQgdGhlIHJlZmVyZW5jZSBn
aXZlbiBpbiA0OTc1IHJlbGF0ZXMgdG8gdGhlIHNlY29uZCBwYXJ0IG9mIHRoYXQgc2VudGVuY2Ug
c3RhdGluZyB0aGF0IGltcGxlbWVudGF0aW9ucyAic2hvdWxkIiBhbHJlYWR5IGJlIGFsbG93aW5n
IHVucmVjb2duaXplZCB0cmFuc3BvcnRzLiAgSXQgd291bGQgYmUgcXVpdGUgdXNlZnVsIHRvIGhh
dmUgdGhlIGV4YWN0IHJlZmVyZW5jZSBoZXJlIGFzIEkgd2FzIHRyeWluZyB0byBkb3VibGUgY2hl
Y2sgdGhpcyBwb2ludCBhbmQgSSBjb3VsZG4ndCBmaW5kIGl0LiANCj4gPj4gDQo+ID4+IDMpIFNl
Y3Rpb24gNi4gIEknbSByZWFsbHkgcHV6emxlZCBhcyB0byB3aHkgdGhlIENvbm5lY3Rpb24gS2Vl
cC1hbGl2ZSB3b3VsZCBiZSBub24tbm9ybWF0aXZlLiAgSW4gcGFydGljdWxhciBnaXZlbiB0aGF0
IDIxMTkgbGFuZ3VhZ2UgaXMgY2xlYXJseSBiZWluZyB1c2VkLiAgDQo+ID4+IA0KPiA+PiA0KSBT
ZWN0aW9uIDcuICBBZ2FpbiwgSSdtIHB1enpsZWQgYXMgdG8gd2h5IEF1dGhlbnRpY2F0aW9uIGlz
IGNvbnNpZGVyZWQgbm9uLW5vcm1hdGl2ZS4gQUdhaW4sIHlvdSBoYXZlIDIxMTkgbGFuZ3VhZ2Ug
aW4gdGhpcyBzZWN0aW9uLiAgDQo+ID4+IA0KPiA+PiA1KSBTZWN0aW9uIDEwLjEuIFNpbmNlIHNl
Y3VyaW5nIHRoZSBjb25uZWN0aW9uIGlzIGp1c3QgUkVDT01NRU5ERUQsIHdoYXQgYXJlIHRoZSBp
bXBsaWNhdGlvbnMgYW5kIHJpc2tzIGlmIHRoZSBNU1JQIHRyYWZmaWMgaXNuJ3QgdHJhbnNwb3J0
ZWQgb3ZlciBhIHNlY3VyZSBjb25uZWN0aW9uPyANCj4gPj4gDQo+ID4+IDYpIFNlY3Rpb24gMTEu
ICBZb3Ugc2hvdWxkIGNoYW5nZSB0aGUgbmFtZSBvZiB0aGUgcmVnaXN0cnkgdG8gYmUgdGhlIGV4
YWN0IG5hbWUgb2YgdGhlIElBTkEgcmVnaXN0cnkgdG8gYXZvaWQgYW55IGNvbmZ1c2lvbi4tIGku
ZS4sOg0KPiA+PiBPTEQ6DQo+ID4+ICByZWdpc3RyeSBvZiBXZWJTb2NrZXQgc3ViLXByb3RvY29s
cw0KPiA+PiBORVc6IA0KPiA+PiAgV2ViU29ja2V0IFN1YnByb3RvY29sIE5hbWUgUmVnaXN0cnkN
Cj4gPj4gDQo+ID4+IDcpIFNlY3Rpb24gMTEuIFRoZXJlIGlzIGFsc28gYSBSZWZlcmVuY2UgZmll
bGQgaW4gdGhhdCBJQU5BIHJlZ2lzdHJ5LiBJIHdvdWxkIHN1Z2dlc3QgeW91IHVzZSB0aGUgc2Ft
ZSBpbmZvcm1hdGlvbiBhcyB0aGUgcG9pbnRlciB0byB0aGUgU3VicHJvdG9jb2wgRGVmaW5pdGlv
biAoaS5lLiwgdGhpcyBSRkMpLiANCj4gPj4gDQo+ID4+IDgpIEl0J3MgdHlwaWNhbCBmb3IgZG9j
dW1lbnRzIHRoYXQgYXJlIHVwZGF0aW5nIGV4aXN0aW5nIFJGQ3MgdG8gaGF2ZSBhIHNlY3Rpb24g
dGhhdCBzdW1tYXJpemVzIHRoZSB1cGRhdGVzIHRvIHRoZSBleGlzdGluZyBSRkNzIHRoYXQgYXJl
IG1hZGUgYnkgdGhpcyBkb2N1bWVudC4gIA0KPiA+PiANCj4gPj4gDQo+ID4+IA0KPiA+PiBPbiBU
aHUsIERlYyAxMiwgMjAxMyBhdCA2OjU3IFBNLCA8aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPiB3
cm90ZToNCj4gPj4gDQo+ID4+IEEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9t
IHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmllcy4NCj4gPj4gDQo+ID4+IA0K
PiA+PiAgICAgICAgVGl0bGUgICAgICAgICAgIDogVGhlIFdlYlNvY2tldCBQcm90b2NvbCBhcyBh
IFRyYW5zcG9ydCBmb3IgdGhlIE1lc3NhZ2UgU2Vzc2lvbiBSZWxheSBQcm90b2NvbCAoTVNSUCkN
Cj4gPj4gICAgICAgIEF1dGhvcihzKSAgICAgICA6IFBldGVyIER1bmtsZXkNCj4gPj4gICAgICAg
ICAgICAgICAgICAgICAgICAgIEdhdmluIExsZXdlbGx5bg0KPiA+PiAgICAgICAgICAgICAgICAg
ICAgICAgICAgVmljdG9yIFBhc2N1YWwNCj4gPj4gICAgICAgICAgICAgICAgICAgICAgICAgIEFu
dG9uIFJvbWFuDQo+ID4+ICAgICAgICAgICAgICAgICAgICAgICAgICBHb256YWxvIFNhbGd1ZWly
bw0KPiA+PiAgICAgICAgRmlsZW5hbWUgICAgICAgIDogZHJhZnQtcGQtZGlzcGF0Y2gtbXNycC13
ZWJzb2NrZXQtMDMudHh0DQo+ID4+ICAgICAgICBQYWdlcyAgICAgICAgICAgOiAyMQ0KPiA+PiAg
ICAgICAgRGF0ZSAgICAgICAgICAgIDogMjAxMy0xMi0xMg0KPiA+PiANCj4gPj4gQWJzdHJhY3Q6
DQo+ID4+ICAgVGhlIFdlYlNvY2tldCBwcm90b2NvbCBlbmFibGVzIHR3by13YXkgcmVhbC10aW1l
IGNvbW11bmljYXRpb24NCj4gPj4gICBiZXR3ZWVuIGNsaWVudHMgYW5kIHNlcnZlcnMuICBUaGlz
IGRvY3VtZW50IHNwZWNpZmllcyBhIG5ldyBXZWJTb2NrZXQNCj4gPj4gICBzdWItcHJvdG9jb2wg
YXMgYSByZWxpYWJsZSB0cmFuc3BvcnQgbWVjaGFuaXNtIGJldHdlZW4gTVNSUCAoTWVzc2FnZQ0K
PiA+PiAgIFNlc3Npb24gUmVsYXkgUHJvdG9jb2wpIGNsaWVudHMgYW5kIHJlbGF5cyB0byBlbmFi
bGUgdXNhZ2Ugb2YgTVNSUCBpbg0KPiA+PiAgIG5ldyBzY2VuYXJpb3MuICBUaGlzIGRvY3VtZW50
IG5vcm1hdGl2ZWx5IHVwZGF0ZXMgUkZDIDQ5NzUgYW5kIFJGQw0KPiA+PiAgIDQ5NzYuDQo+ID4+
IA0KPiA+PiANCj4gPj4gVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMg
ZHJhZnQgaXM6DQo+ID4+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXBk
LWRpc3BhdGNoLW1zcnAtd2Vic29ja2V0DQo+ID4+IA0KPiA+PiBUaGVyZSdzIGFsc28gYSBodG1s
aXplZCB2ZXJzaW9uIGF2YWlsYWJsZSBhdDoNCj4gPj4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0
bWwvZHJhZnQtcGQtZGlzcGF0Y2gtbXNycC13ZWJzb2NrZXQtMDMNCj4gPj4gDQo+ID4+IEEgZGlm
ZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCj4gPj4gaHR0cDov
L3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtcGQtZGlzcGF0Y2gtbXNycC13ZWJzb2Nr
ZXQtMDMNCj4gPj4gDQo+ID4+IA0KPiA+PiBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEg
Y291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiANCj4gPj4gc3VibWlzc2lvbiB1bnRp
bCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmll
dGYub3JnLg0KPiA+PiANCj4gPj4gSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBi
eSBhbm9ueW1vdXMgRlRQIGF0Og0KPiA+PiBmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJh
ZnRzLw0KPiA+PiANCj4gPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX18NCj4gPj4gSS1ELUFubm91bmNlIG1haWxpbmcgbGlzdA0KPiA+PiBJLUQtQW5ub3Vu
Y2VAaWV0Zi5vcmcNCj4gPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9p
LWQtYW5ub3VuY2UNCj4gPj4gSW50ZXJuZXQtRHJhZnQgZGlyZWN0b3JpZXM6IGh0dHA6Ly93d3cu
aWV0Zi5vcmcvc2hhZG93Lmh0bWwgb3IgDQo+ID4+IGZ0cDovL2Z0cC5pZXRmLm9yZy9pZXRmLzFz
aGFkb3ctc2l0ZXMudHh0DQo+ID4+IA0KPiA+PiANCj4gPj4gDQo+ID4+IA0KPiA+PiAtLQ0KPiA+
PiBQZXRlciBEdW5rbGV5DQo+ID4+IFRlY2huaWNhbCBEaXJlY3Rvcg0KPiA+PiBDcm9jb2RpbGUg
UkNTIEx0ZA0KPiA+PiANCj4gPj4gDQo+ID4+IA0KPiA+PiAtLQ0KPiA+PiBQZXRlciBEdW5rbGV5
DQo+ID4+IFRlY2huaWNhbCBEaXJlY3Rvcg0KPiA+PiBDcm9jb2RpbGUgUkNTIEx0ZA0KPiA+PiAN
Cj4gPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4g
Pj4gZGlzcGF0Y2ggbWFpbGluZyBsaXN0DQo+ID4+IGRpc3BhdGNoQGlldGYub3JnDQo+ID4+IGh0
dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGlzcGF0Y2gNCj4gPiANCj4gDQoN
Cg==

From mary.ietf.barnes@gmail.com  Sat Jan 25 09:29:40 2014
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 7F94F1A005B; Sat, 25 Jan 2014 09:29:40 -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 q7ITxc6_nACd; Sat, 25 Jan 2014 09:29:37 -0800 (PST)
Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 3B9491A005A; Sat, 25 Jan 2014 09:29:37 -0800 (PST)
Received: by mail-ie0-f180.google.com with SMTP id at1so4199040iec.39 for ; Sat, 25 Jan 2014 09:29:35 -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 :content-type; bh=kgJJh9RuKzFrpELRa5QCKGNLEwfOswIDRUzL2d3yGEY=; b=JZArI/vUGfS1mKc+TTDEpQ3XMN40YTvmWE8O2B8NcThUbMs6S3Slh9lF33Z0O2Sj0R LyNv7vId/ZZsQdT2X17yweqLtw0jfZzPrz5NvaN0pxudwHa/PB/ZaQ9wv0yC4eX6wYDU rSS6hVURnPrkiPV6lWvh978qcnuCg0q5tdIQ738sh5F5NDy8z7oBtyPDs34BiVzPd6/0 DrcMMQweptge5KiDsMFubUULmqv2ivy1OqZmRpJy73K4x+iKeDum+gKFQr7Rxp7dtsGd ndksA35iRcPv+Ajq+eBDi1DTgzHdcMw+hM6n+QhAL4AobHIaS9VD5RQvU5+1k88XC3cd xHCg==
MIME-Version: 1.0
X-Received: by 10.50.114.4 with SMTP id jc4mr10247664igb.0.1390670975274; Sat, 25 Jan 2014 09:29:35 -0800 (PST)
Received: by 10.43.58.137 with HTTP; Sat, 25 Jan 2014 09:29:35 -0800 (PST)
In-Reply-To: <52e18b8a.44668c0a.9b7c.ffffe95cSMTPIN_ADDED_BROKEN@mx.google.com>
References: <52e18b8a.44668c0a.9b7c.ffffe95cSMTPIN_ADDED_BROKEN@mx.google.com>
Date: Sat, 25 Jan 2014 11:29:35 -0600
Message-ID: 
From: Mary Barnes 
To: "rai@ietf.org" , DISPATCH , SIPCORE 
Content-Type: multipart/alternative; boundary=047d7b2e09837b14c504f0ced130
Subject: [dispatch] Fwd: [SIPForum-techwg] There's Still Time to Submit a SIPNOC 2014 Proposal
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: Sat, 25 Jan 2014 17:29:40 -0000

--047d7b2e09837b14c504f0ced130
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

HI all,

The proposed topics for this conference are directly applicable to work in
RAI WGs.  Folks might want to consider submitting a contribution for the
conference.  Many of the attendees are folks that manage and operate the
networks so you'll hear first hand of some of the challenges they have and
it's a good opportunity to share some of the newer work that's happening
that might help address some of their challenges.

Regards,
Mary.


---------- Forwarded message ----------
From: Marc Robins 
Date: Thu, Jan 23, 2014 at 3:33 PM
Subject: [SIPForum-techwg] There's Still Time to Submit a SIPNOC 2014
Proposal
To: techwg@sipforum.org


There=E2=80=99s still time to submit a proposal for SIPNOC 2014 workshops, =
panels,
speaker presentations and =E2=80=9CBirds of a Feather=E2=80=9D sessions add=
ressing the
deployment of SIP in service provider environments.

To view the official call for presentations, which includes instructions on
submitting material and specific SIPNOC policies, please visit
www.sipforum.org/content/view/374/275/. To submit, visit
https://www.easychair.org/conferences/?conf=3Dsipnoc2014.

Topics can include SIP peering, SIP trunking, Emergency Services,
Congestion Control, Scaling and Capacity Issues, SIP-based applications,
Routing, Security, SIP-Network Operations Center Best Practices, IPv6
deployment challenges, User-agent Configuration, Standardization Issues and
Progress, HD voice deployments, Video Interoperability, WebRTC and SIP,
FoIP/T.38 Deployment, Testing or other issues facing SIP network
operations.

SIPNOC 2014 offers several different types of speaking opportunities
including:

   - General Session Talks: A General Session presentation should be on a
   topic of interest to the general SIPNOC audience, and may be up to 30
   minutes long (including time for Q&A).
   - General Session Panels: Panels are sessions with a moderator and a
   team of panelists. The panel moderator should submit an abstract on the
   panel topic, a list of panelists, and how the panel will be organized.
   Panel selection is based on the importance, originality, focus and
   timeliness of the topic, expertise of proposed panelists, as well as the
   potential for informative and controversial discussion.
   - Special Workshops: The SIPNOC 2014 program has been expanded to
   include special workshops that run for 2-3 hours, providing time to focu=
s
   in-depth on a variety of issues important to the SIPNOC community. Topic=
s
   can include a review of SIP RFCs and standards development, the regulato=
ry
   environment, etc.
   - Research Topics: Researchers are invited to present short summaries of
   their work for operator feedback. Topics may include call routing, netwo=
rk
   performance, statistical measurement and analysis and protocol developme=
nt
   and implementation. Studies presented may be works in progress. Research=
ers
   from academia, government, and industry are encouraged to present.
   - BOFs: BOFs (Birds of a Feather sessions) are informal sessions on
   topics which are of interest to a portion of the SIPNOC community. BOFs =
may
   be held in break=E2=80=90out areas or in an unscheduled room. Requests f=
or
   scheduled BOFs can be made at any time, including on site at the confere=
nce.

The following is a complete list of key dates for the SIPNOC 2014 speaking
program:

   - Presentation Abstracts Due =E2=80=93 January 31, 2014
   - Draft Presentations Due -- February 15, 2014
   - Acceptance Decision and Notifications -- February 21, 2014
   - Draft Program Published =E2=80=93 March 1, 2014
   - Final Presentations Due -- April 1, 2014
   - Final Agenda Published -- April 15, 2014
   - Conference Begins -- June 9, 2014

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

*SIPNOC 2014 General Info*

The SIPNOC 2014 event website is located at www.sipnoc.org.

Registration for SIPNOC 2014 is officially open!

Special pricing for SIPNOC 2014 is now in effect! Take advantage of special
early-bird pricing now through March 1, 2014. The regular SIPNOC 2014
conference registration fee is $995, but for a limited time regular
attendees can save $145 and pay only $850 for three days of conference
proceedings. This fee includes a special welcome reception the evening
before the event with food and drink; breakfast, lunch and break
refreshments and snacks; and special networking receptions the first and
second night of the event.

*Individuals from SIP Forum Full Member companies save even more ($295 off
the regular price to be exact with special early-bird pricing)! Please
contact Marc Robins, SIP Forum President and Managing Director, at
marc.robins@sipforum.org  to obtain the exclusive
Full Member discount code.*

Register today at www.regonline.com/sipnoc2014.
------------------------------

*SIPNOC 2014 Sponsorship Information*

For information about corporate sponsorship opportunities at SIPNOC 2014,
please contact Marc Robins, SIP Forum President and Managing Director, at
203-829-6307 or marc.robins@sipforum.org.
------------------------------

*************************

Marc Robins

President and Managing Director

SIP Forum

http://www.sipforum.org

Mobile: 203-829-6307

SkypeMe! marcrobins



*************************





_______________________________________________
techwg mailing list
Send mail to: techwg@sipforum.org
Unsubscribe or edit options at:  http://sipforum.org/mailman/listinfo/techw=
g

--047d7b2e09837b14c504f0ced130
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


HI all,

The proposed topics for this co=
nference are directly applicable to work in RAI WGs. =C2=A0Folks might want=
 to consider submitting a contribution for the conference. =C2=A0Many of th=
e attendees are folks that manage and operate the networks so you'll he=
ar first hand of some of the challenges they have and it's a good oppor=
tunity to share some of the newer work that's happening that might help=
 address some of their challenges.



Regards,
Mary.=C2=A0


---------- Forwarded message ----------
=
From: Marc Robins <<=
a href=3D"mailto:marc.robins@sipforum.org">marc.robins@sipforum.org>=


Date: Thu, Jan 23, 2014 at 3:33 PM
Subject: [SIPForum-techwg] There'=
s Still Time to Submit a SIPNOC 2014 Proposal
To: techwg@sipforum.org




There=E2=80=99s still time to subm=
it a proposal for SIPNOC 2014 workshops, panels, speaker presentations and =
=E2=80=9CBirds of a Feather=E2=80=9D sessions addressing the deployment of =
SIP in service provider environments.


T=
o view the official call for presentations, which includes instructions on =
submitting material and specific SIPNOC policies, please visit www.sipforu=
m.org/content/view/374/275/. To submit, visit https://www.e=
asychair.org/conferences/?conf=3Dsipnoc2014.


T=
opics can include SIP peering, SIP trunking, Emergency Services, Congestion=
 Control, Scaling and Capacity Issues, SIP-based applications, Routing, Sec=
urity, SIP-Network Operations Center Best Practices, IPv6 deployment challe=
nges, User-agent Configuration, Standardization Issues and Progress, HD voi=
ce deployments, Video Interoperability, WebRTC and SIP, FoIP/T.38 Deploymen=
t, Testing or other issues facing SIP network operations. 


S=
IPNOC 2014 offers several different types of speaking opportunities includi=
ng:
  • General Session Talks: A General Session presen=
tation should be on a topic of interest to the general SIPNOC audience, and=
 may be up to 30 minutes long (including time for Q&A). <=
/span>
    • 

  • General Session Pa=
nels: Panels are sessions with a moderator and a team of panelists. The pan=
el moderator should submit an abstract on the panel topic, a list of paneli=
sts, and how the panel will be organized. Panel selection is based on the i=
mportance, originality, focus and timeliness of the topic, expertise of pro=
posed panelists, as well as the potential for informative and controversial=
 discussion.
    • 

  • Special Workshops:=
 The SIPNOC 2014 program has been expanded to include special workshops tha=
t run for 2-3 hours, providing time to focus in-depth on a variety of issue=
s important to the SIPNOC community. Topics can include a review of SIP RFC=
s and standards development, the regulatory environment, etc.=

    • 

  • Research Topics: R=
esearchers are invited to present short summaries of their work for operato=
r feedback. Topics may include call routing, network performance, statistic=
al measurement and analysis and protocol development and implementation. St=
udies presented may be works in progress. Researchers from academia, govern=
ment, and industry are encouraged to present.
    • 

  • BOFs: BOFs (Birds =
of a Feather sessions) are informal sessions on topics which are of interes=
t to a portion of the SIPNOC community. BOFs may be held in break=E2=80=90o=
ut areas or in an unscheduled room. Requests for scheduled BOFs can be made=
 at any time, including on site at the conference.

The following is a complete list of key dates for the SIPNOC 2014 speak=
ing program:
  • 
Presentation Abstracts Due =E2=80=93 Janua=
ry 31, 2014
  • Draft Presentations Due -- February 15, 2014
    • 

  • Acceptance Decisio=
n and Notifications -- February 21, 2014
  • Draft Program Published =E2=
=80=93 March 1, 2014
    • 

  • Final Presentation=
s Due -- April 1, 2014
  • Final Agenda Published -- April 15, 2014
    • 

  • Conference Begins =
-- June 9, 2014


SIPNOC 2014 General Info
The SIPN=
OC 2014 event website is located at www.sipnoc.org.


R=
egistration for SIPNOC 2014 is officially open!
=
Spec=
ial pricing for SIPNOC 2014 is now in effect! Take advantage of special ear=
ly-bird pricing now through March 1, 2014. The regular SIPNOC 2014 conferen=
ce registration fee is $995, but for a limited time regular attendees can s=
ave $145 and pay only $850 for three days of conference proceedings. This f=
ee includes a special welcome reception the evening before the event with f=
ood and drink; breakfast, lunch and break refreshments and snacks; and spec=
ial networking receptions the first and second night of the event.


Individuals from SIP Forum Full Member companies save even m=
ore ($295 off the regular price to be exact with special early-bird pricing=
)! Please contact Marc Robins, SIP Forum President and Managing Director, a=
t marc.robins=
@sipforum.org to obtain the exclusive Full Member discount code.=



R=
egister today at www.regonline.com/sipnoc2014.=C2=A0


SIPNOC 2014 Sponsorship Information


F=
or information about corporate sponsorship opportunities at SIPNOC 2014, pl=
ease contact Marc Robins, SIP Forum President and Managing Director, at 203-829-=
6307 or m=
arc.robins@sipforum.org.


=

*************************

Marc Robins
President and Managing Director<=
u>


SIP Forum
http://www.sipforum.org


Mobile: 203-829-6307<=
/p>

SkypeMe! marcrobins
=C2=A0
**************=
***********


=C2=A0
=C2=A0

________________________________________=
_______

techwg mailing list

Send mail to: techwg@sipforum.org

Unsubscribe or edit options at: =C2=A0http://sipforum.org/mailman/listinfo/t=
echwg


--047d7b2e09837b14c504f0ced130--

From michael@voip.co.uk  Sat Jan 25 14:40:36 2014
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 A51C41A00A4 for ; Sat, 25 Jan 2014 14:40:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.579
X-Spam-Level: 
X-Spam-Status: No, score=-3.579 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-2.3, 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 sqD5mpgYa-zC for ; Sat, 25 Jan 2014 14:40:35 -0800 (PST)
Received: from na3sys009aog130.obsmtp.com (na3sys009aog130.obsmtp.com [74.125.149.143]) by ietfa.amsl.com (Postfix) with SMTP id 1C5161A009D for ; Sat, 25 Jan 2014 14:40:35 -0800 (PST)
Received: from mail-wg0-f41.google.com ([74.125.82.41]) (using TLSv1) by na3sys009aob130.postini.com ([74.125.148.12]) with SMTP ID DSNKUuQ9YeeMIWppBqqvToTX8c0JdsbM5fk7@postini.com; Sat, 25 Jan 2014 14:40:34 PST
Received: by mail-wg0-f41.google.com with SMTP id n12so3017137wgh.2 for ; Sat, 25 Jan 2014 14:40:32 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=kaF3jbAVwOSH6KTcfpq3D21imu7AqDVVTb2t9svopDg=; b=UjDWXY3xMj5WnX608WbuNL00HW5tkB5R/lWKNxYkNQGgJZVbz1bxR5aG9DnVN5wa8F IMm1rRLLsgbLSHpq4q9WtfARqp8kckLXRapYD7wtY+TQQouAW2hty8qzaWzjYorcCyry Aj7dqGE49XHk5aAaEGBv9S2Ve1mwLYHDQ4ANgxtMbZYVPdpUnBdSC0AcH4WWy8itYri9 piUjLF/GutP7cxyXoDh2EAJhTNBC6sxNME8h2LTJLzazxxz1Hv6bVoZEJ+qROs277Bst iKpvX9A9HRS2G068EhZVXL4ict9GTJ6b2IZA0T+5DfYAKhPdYZpkXD6Clmwiu+UpGXmB HBsQ==
X-Gm-Message-State: ALoCoQnDO9X5nTENB5sqY8IolxQ3TZEvYLQQ7gJW7yEd9sQnufFWWsIAZ1QiBMQEJ3+7lWsphTPuXDSkKnqetyjYemczJRUg9pUa1iuHGuCW7jWCb/5s31EjSYIWrn+g+GTxSwce4aUfGDJ7eh5IV0KS8VxxabLV4A==
X-Received: by 10.180.98.42 with SMTP id ef10mr7356891wib.49.1390689632482; Sat, 25 Jan 2014 14:40:32 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.180.98.42 with SMTP id ef10mr7356889wib.49.1390689632390; Sat, 25 Jan 2014 14:40:32 -0800 (PST)
Received: by 10.194.42.195 with HTTP; Sat, 25 Jan 2014 14:40:32 -0800 (PST)
Date: Sat, 25 Jan 2014 22:40:32 +0000
Message-ID: 
From: Michael Procter 
To: Olle E Johansson , IETF Dispatch 
Content-Type: text/plain; charset=ISO-8859-1
Subject: [dispatch] draft-johansson-dispatch-dane-sip-01 - certificate validation
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: Sat, 25 Jan 2014 22:40:36 -0000

Hi Olle,

I have read your draft on DANE for SIP, and have a question about
section 8.  The section starts with the statement:

   When using DANE-based validation the client validates the SRV
   hostname with the certificate using RFC 5922 rules.

I'm not sure we want to use the SRV hostname here.  RFC 5922 uses the
original domain before the NAPTR lookup (the AUS) which is probably
the same as the SRV hostname, but may be different[0].

I think we have to keep the mechanisms aligned to ensure that a
certificate that matches under RFC 5922 rules continues to match after
you add a TLSA RR.

Best regards,

Michael


[0] RFC 3263 Section 4.1, para 10 starts:
   It is not necessary for the domain suffixes in the NAPTR replacement
   field to match the domain of the original query (i.e., example.com
   above).

From oej@edvina.net  Sat Jan 25 23:53:39 2014
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 9902F1A010F for ; Sat, 25 Jan 2014 23:53:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.551
X-Spam-Level: 
X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 CuUrq5S-OCvs for ; Sat, 25 Jan 2014 23:53:37 -0800 (PST)
Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 80A061A010C for ; Sat, 25 Jan 2014 23:53:36 -0800 (PST)
Received: from [192.168.40.13] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id D1D8193C2A1; Sun, 26 Jan 2014 07:53:32 +0000 (UTC)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: "Olle E. Johansson" 
In-Reply-To: 
Date: Sun, 26 Jan 2014 08:53:32 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <03326AC3-4A56-49C6-B68F-3A3F137A78B8@edvina.net>
References: 
To: Michael Procter 
X-Mailer: Apple Mail (2.1827)
Cc: IETF Dispatch 
Subject: Re: [dispatch] draft-johansson-dispatch-dane-sip-01 - certificate validation
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: Sun, 26 Jan 2014 07:53:39 -0000

On 25 Jan 2014, at 23:40, Michael Procter  wrote:

> Hi Olle,
>=20
> I have read your draft on DANE for SIP, and have a question about
> section 8.  The section starts with the statement:
>=20
>   When using DANE-based validation the client validates the SRV
>   hostname with the certificate using RFC 5922 rules.
>=20
> I'm not sure we want to use the SRV hostname here.  RFC 5922 uses the
> original domain before the NAPTR lookup (the AUS) which is probably
> the same as the SRV hostname, but may be different[0].
>=20
> I think we have to keep the mechanisms aligned to ensure that a
> certificate that matches under RFC 5922 rules continues to match after
> you add a TLSA RR.
>=20
One of the reasons to change to host name was to simpify hosting. Having
the domain name in the certificate is not a good thing, especially not =
for sites
that have a large number of domains (hosting). It's well documented
in a few of the DANE drafts. With DNSsec the binding between a domain
and a host is assured by the signed records. The binding between a host
and a service in TLS is assured by the certificate and signed TLSA =
record.
The authority to serve a domain is assured by DNSsec and the identity
of the host is checked in TLS.

Without DNSsec we need a secure binding between the certificate and
the domain and mix authorization and identification in the same
operation. As stated, this is not seen as a good solution today.

You can still have a certificate that matches both standards, with the
host name in the CN and domains in the SAN if you want. A client
compliant with this specification will look for the host name (SRV host)
in the CN and a client following the SIP domain cert RFC will ignore
the CN and only look into the SAN fields.

Thanks for the feedback!
/O=

From michael@voip.co.uk  Sun Jan 26 04:34:19 2014
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 43D0A1A0139 for ; Sun, 26 Jan 2014 04:34:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.579
X-Spam-Level: 
X-Spam-Status: No, score=-3.579 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-2.3, 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 mCmrNLFgCT4J for ; Sun, 26 Jan 2014 04:34:16 -0800 (PST)
Received: from na3sys009aog134.obsmtp.com (na3sys009aog134.obsmtp.com [74.125.149.83]) by ietfa.amsl.com (Postfix) with SMTP id 62B821A0120 for ; Sun, 26 Jan 2014 04:34:16 -0800 (PST)
Received: from mail-wg0-f49.google.com ([74.125.82.49]) (using TLSv1) by na3sys009aob134.postini.com ([74.125.148.12]) with SMTP ID DSNKUuUAxsFAFfF4ly9Urm/vhDGtEg1SBaPc@postini.com; Sun, 26 Jan 2014 04:34:15 PST
Received: by mail-wg0-f49.google.com with SMTP id a1so4667281wgh.16 for ; Sun, 26 Jan 2014 04:34:13 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=mCo5pLSWPKlMciCi9wqGsb5TQTHe6s5dG09kBYs979I=; b=ay/yOPhpG4TGuWu4SKCevNd8i46V8DG/r04PJLWcXiCcr9kh9o0VgSNmoLLxuw27e9 3pAC2vonoFPCOUq7TjO/ARhmdbpDKYR2VqBkqBrT0EjeheYIKR5xgGdL3hYRrU/DOLwn UHvbru8kk5DQD0eHiAz001rsYg5iKqqXgEpkd+L2PyQAUBK+R+k9RPTyyxSCFMT2uSF5 XUulZ33X6DogY0N+R5Q6s0CDdSq5BO8VXwaiAcgNs7alJ1JqBPjakIN/dHtk2mPz9h4u OzwCcWIysOqUS689AaRwJNsyjeATIzjvm7V+KPSDMjs5VTJxWjMFKB5glzhRpzk+1RNC AXzQ==
X-Gm-Message-State: ALoCoQkoiR6bRomBo5x+Ccj4pS591LlWbjx/2Wc9tYlasdIpWF3xpvCBEjTGgOwhrJdQDfgeLuZiPzEyU1R9QOTzX/mr3zOXnAgg0uXxjaYRMiWzXn6rck94OJzGO3F+PqFXMcDYs6BufY0fmLwIbyqlvSvLm+5Q0Q==
X-Received: by 10.180.108.130 with SMTP id hk2mr8968387wib.16.1390739653305; Sun, 26 Jan 2014 04:34:13 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.180.108.130 with SMTP id hk2mr8968380wib.16.1390739653082; Sun, 26 Jan 2014 04:34:13 -0800 (PST)
Received: by 10.194.42.195 with HTTP; Sun, 26 Jan 2014 04:34:13 -0800 (PST)
In-Reply-To: <03326AC3-4A56-49C6-B68F-3A3F137A78B8@edvina.net>
References:  <03326AC3-4A56-49C6-B68F-3A3F137A78B8@edvina.net>
Date: Sun, 26 Jan 2014 12:34:13 +0000
Message-ID: 
From: Michael Procter 
To: "Olle E. Johansson" 
Content-Type: text/plain; charset=ISO-8859-1
Cc: IETF Dispatch 
Subject: Re: [dispatch] draft-johansson-dispatch-dane-sip-01 - certificate validation
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: Sun, 26 Jan 2014 12:34:19 -0000

Rather than saying in section 8 that clients validate the certificate
"using RFC 5922 rules", it might be clearer to explicitly call out
which part of the RFC should be used.  Maybe something like:

   The client MUST
   determine the SIP domain identities in the server certificate using
   the procedure in Section 7.1 of RFC 5922.

   o  If there were no identities found in the server certificate, the
      server is not authenticated.

   o  If the domain extracted from the AUS matches any SIP domain
      identity obtained from the certificate when compared as described
      in Section 7.2 of RFC 5922, the server is authenticated for the domain.

(Text borrowed from RFC 5922 section 7.3 with light edits)

But that doesn't seem to agree with this statement:

On 26 January 2014 07:53, Olle E. Johansson  wrote:
> A client
> compliant with this specification will look for the host name (SRV host)
> in the CN and a client following the SIP domain cert RFC will ignore
> the CN and only look into the SAN fields

RFC 5922 doesn't let you do that.  Section 7.1 bullet 2 states that
you may only examine the CN if there are no subjectAltNames present
(not just no matching subjectAltNames).  It also only permits you to
use a DNS name when there are no SIP URIs listed.

You might be better off not using any of the RFC 5922 rules at all!
Removing the RFC5922 references from the first paragraph of section 8
makes it look like:

   When using DANE-based validation the client validates the SRV
   hostname with the certificate.  A DANE-capable
   SIP implementation looks for the SRV hostname in the list of
   SubjAltName DNSName extension fields.  Only if there are no
   SubjAltName extension fields may the client look in the CN of the
   X.509 certificate.

That approach (not mentioning RFC 5922) seems to make sense and still
defends against the attack outlined in draft-ietf-dane-srv-03 section
10.3.

Best regards,

Michael

From oej@edvina.net  Sun Jan 26 04:50:53 2014
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 7FFF41A013B for ; Sun, 26 Jan 2014 04:50:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.551
X-Spam-Level: 
X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 nqDXYQA_kJLW for ; Sun, 26 Jan 2014 04:50:51 -0800 (PST)
Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 5AE1C1A0136 for ; Sun, 26 Jan 2014 04:50:50 -0800 (PST)
Received: from [192.168.40.13] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id AD1E593C2A1; Sun, 26 Jan 2014 12:50:47 +0000 (UTC)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: "Olle E. Johansson" 
In-Reply-To: 
Date: Sun, 26 Jan 2014 13:50:46 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  <03326AC3-4A56-49C6-B68F-3A3F137A78B8@edvina.net> 
To: Michael Procter 
X-Mailer: Apple Mail (2.1827)
Cc: IETF Dispatch 
Subject: Re: [dispatch] draft-johansson-dispatch-dane-sip-01 - certificate validation
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: Sun, 26 Jan 2014 12:50:53 -0000

On 26 Jan 2014, at 13:34, Michael Procter  wrote:

> Rather than saying in section 8 that clients validate the certificate
> "using RFC 5922 rules", it might be clearer to explicitly call out
> which part of the RFC should be used.  Maybe something like:
>=20
>   The client MUST
>   determine the SIP domain identities in the server certificate using
>   the procedure in Section 7.1 of RFC 5922.
>=20
>   o  If there were no identities found in the server certificate, the
>      server is not authenticated.
>=20
>   o  If the domain extracted from the AUS matches any SIP domain
>      identity obtained from the certificate when compared as described
>      in Section 7.2 of RFC 5922, the server is authenticated for the =
domain.
>=20
> (Text borrowed from RFC 5922 section 7.3 with light edits)
>=20
> But that doesn't seem to agree with this statement:
>=20
> On 26 January 2014 07:53, Olle E. Johansson  wrote:
>> A client
>> compliant with this specification will look for the host name (SRV =
host)
>> in the CN and a client following the SIP domain cert RFC will ignore
>> the CN and only look into the SAN fields
>=20
> RFC 5922 doesn't let you do that.  Section 7.1 bullet 2 states that
> you may only examine the CN if there are no subjectAltNames present
> (not just no matching subjectAltNames).  It also only permits you to
> use a DNS name when there are no SIP URIs listed.
Right. My example was a way to produce one certificate for both. I =
wanted
to totally ignore the SANs in SIPDANE. A certificate with ONLY one
CN and NO SANs will collide as you say. That needs to be mentioned.
In that case SNI may help (if we come up with a draft for SIP and SNI).

>=20
> You might be better off not using any of the RFC 5922 rules at all!
> Removing the RFC5922 references from the first paragraph of section 8
> makes it look like:
>=20
>   When using DANE-based validation the client validates the SRV
>   hostname with the certificate.  A DANE-capable
>   SIP implementation looks for the SRV hostname in the list of
>   SubjAltName DNSName extension fields.  Only if there are no
>   SubjAltName extension fields may the client look in the CN of the
>   X.509 certificate.
This re-adds SANs that I wanted to remove ;-)
>=20
> That approach (not mentioning RFC 5922) seems to make sense and still
> defends against the attack outlined in draft-ietf-dane-srv-03 section
> 10.3.
I will check that part again and possibly come back with more questions.
And remove some references to 5922 to avoid confusion. There was =
questions
earlier about backwards compatibility and that may be moved into a =
separate section.

Thanks again,
/O
>=20
> Best regards,
>=20
> Michael


From fluffy@cisco.com  Wed Jan 29 08:11:43 2014
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 255601A03BF; Wed, 29 Jan 2014 08:11:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -115.036
X-Spam-Level: 
X-Spam-Status: No, score=-115.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] 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 4lXLrZn2Uabs; Wed, 29 Jan 2014 08:11:34 -0800 (PST)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id ADA621A03E8; Wed, 29 Jan 2014 08:11:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1761; q=dns/txt; s=iport; t=1391011888; x=1392221488; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Aanm7d3T4xziWPJycVHoiiYV57PaMbCogtcYwHvWFcQ=; b=eto8kBCIwlKRspX/Mc6toKZhhiFd9tNur0gJLa4SohwT7FucmQ2Sxsow NgDAH2OzSs7KX7KaJgDBK/ofznAYkG27GRiOqyccFr81Ofd/YY3512v39 yWOB4UL/Cqps0v+JKu+6HXOZOK6or2ET6na9irRULxQdjekJArbS0onCt s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ag0FAJwn6VKtJXG+/2dsb2JhbABTBoMMOFa8f4EHFnSCJQEBAQMBAQEBaAMLEAIBCBguJwslAgQOBYd9CA3JeRMEjh0RAQ0QMweDJIEUBJgokh+DLYFxOQ
X-IronPort-AV: E=Sophos;i="4.95,742,1384300800"; d="scan'208";a="300521133"
Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-3.cisco.com with ESMTP; 29 Jan 2014 16:11:27 +0000
Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id s0TGBRd4013026 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 29 Jan 2014 16:11:27 GMT
Received: from xmb-aln-x02.cisco.com ([169.254.5.76]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0123.003; Wed, 29 Jan 2014 10:11:27 -0600
From: "Cullen Jennings (fluffy)" 
To: Ben Campbell 
Thread-Topic: [RAI] MSRP Expert Review of draft-pd-dispatch-msrp-websocket-04
Thread-Index: AQHPHQzD5NPJAZ1BGUCGp1O/NMagzw==
Date: Wed, 29 Jan 2014 16:11:26 +0000
Message-ID: 
References: <45B84D8F-AD8C-4B28-90DF-9B1C40771104@nostrum.com> <6833E320-7B45-4FC2-853B-62311DCF7E7B@nostrum.com>
In-Reply-To: <6833E320-7B45-4FC2-853B-62311DCF7E7B@nostrum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.20.249.164]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <22E36ED91B054E498BEF37DD9EAA9EC4@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: DISPATCH , "draft-pd-dispatch-msrp-websocket.all@tools.ietf.org" , "rai@ietf.org" 
Subject: Re: [dispatch] [RAI] MSRP Expert Review of draft-pd-dispatch-msrp-websocket-04
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, 29 Jan 2014 16:11:43 -0000

I don=92t see why using websockets would require us to get rid of the MUST =
use TLS.=20

The security of relays is a total disaster if you don=92t have this so if t=
he MUST be security authenticated goes away for relays, then I suspect this=
 mechanisms is too broken to publish.

Cullen ( in my individual contributor role just to be clear )


On Jan 11, 2014, at 2:54 PM, Ben Campbell  wrote:

>=20
> On Jan 10, 2014, at 5:34 PM, Ben Campbell  wrote:
>=20
>> --3
>>=20
>> I am not happy with the downgrade of of the TLS requirement between clie=
nt and relay. I recognize that WebSocket
>=20
> Robert pointed out to me that my comments on this section were truncated.=
 Apparently I'm not qualified for this email gizmo. Here's another try:
>=20
> I recognize that the WebSocket API limits the application's ability to co=
ntrol the security parameters of the connection. I think this is a general =
issue for moving application protocols to use WebSocket, that perhaps needs=
 to be addressed in the WebSocket API.  We probably need an whole IETF (or =
at least RAI+APPS) policy for how to handle this. But MSRP is somewhat unus=
ual in having a "MUST use" TLS requirement, and in the current security cli=
mate we need to take a really hard look at anything that weakens the normat=
ive security requirements of a messaging protocol.
>=20
> I don't have an answer for how to proceed, but at a minimum I would like =
to see considerably more discussion of the implications and any potential m=
itigation of this in the Security Considerations sections.
> _______________________________________________
> RAI mailing list
> RAI@ietf.org
> https://www.ietf.org/mailman/listinfo/rai


From ibc@aliax.net  Wed Jan 29 08:42:56 2014
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 193D51A03CB for ; Wed, 29 Jan 2014 08:42:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.678
X-Spam-Level: 
X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] 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 Kd2aFINbd3Gp for ; Wed, 29 Jan 2014 08:42:54 -0800 (PST)
Received: from mail-qa0-f54.google.com (mail-qa0-f54.google.com [209.85.216.54]) by ietfa.amsl.com (Postfix) with ESMTP id AC3EA1A036B for ; Wed, 29 Jan 2014 08:42:54 -0800 (PST)
Received: by mail-qa0-f54.google.com with SMTP id i13so2763925qae.27 for ; Wed, 29 Jan 2014 08:42:51 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=ETudGGDlNWpp44kYQpB4+dq+YL7WkqjGfyr4J5/F3zo=; b=mSM/rO79eGCuVDMJPLQQO995VDf8T9K5aFbXeLxac39wQvYHwtE10Emk2/k/3NBeVS 6iXC3j7bNTO1y86o37C5kAdNPkqd3H70fcjM6eDf6SENHXYJZMOQjv4oXvCWe1B6cOfs gIx6AS3+w60ipuof+U7n01X1hfWmIBX9KxPgijT0mhDoO6dHiT3gDeTIX9GL1Gttmqi+ g04/ReHqRbRMMl5oC4Klejdz5AHxSBf1FMSkOpZazlpsbfOdb4IfWFyryqtseru3mJGI lsLOjtVIy0XfisZvzu1YjP+aJCy/XM8Yf3midwDqeplZatnFzj0/4ZgbBLl/XPBfI2rg MHAg==
X-Gm-Message-State: ALoCoQnwIyEsQDXrINTXNeAzOyNtbDhxdYXxR2GPNs1cg9Wgm6zA3uOaysnXPVKyp8IqjN2eQ63Z
X-Received: by 10.224.7.10 with SMTP id b10mr13955531qab.50.1391013771562; Wed, 29 Jan 2014 08:42:51 -0800 (PST)
MIME-Version: 1.0
Received: by 10.96.101.232 with HTTP; Wed, 29 Jan 2014 08:42:31 -0800 (PST)
In-Reply-To: 
References: <45B84D8F-AD8C-4B28-90DF-9B1C40771104@nostrum.com> <6833E320-7B45-4FC2-853B-62311DCF7E7B@nostrum.com> 
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
Date: Wed, 29 Jan 2014 17:42:31 +0100
Message-ID: 
To: "Cullen Jennings (fluffy)" 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: Ben Campbell , DISPATCH , "rai@ietf.org" , "draft-pd-dispatch-msrp-websocket.all@tools.ietf.org" 
Subject: Re: [dispatch] [RAI] MSRP Expert Review of draft-pd-dispatch-msrp-websocket-04
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, 29 Jan 2014 16:42:56 -0000

2014-01-29 Cullen Jennings (fluffy) :
> I don=E2=80=99t see why using websockets would require us to get rid of t=
he MUST use TLS.
>
> The security of relays is a total disaster if you don=E2=80=99t have this=
 so if the MUST be security authenticated goes away for relays, then I susp=
ect this mechanisms is too broken to publish.

Neither I understand why the "MUST use TLS" should be dropped for MSRP
over WebSocket. I cannot figure out any reasons for getting rid of
that requirement. If it was valid and appropriate for MSRP over TCP
then it should also be for MSRP over WebSocket.

Just my opinion.


--=20
I=C3=B1aki Baz Castillo


From ben@nostrum.com  Wed Jan 29 09:12:46 2014
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 C33391A047D; Wed, 29 Jan 2014 09:12:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.736
X-Spam-Level: 
X-Spam-Status: No, score=-0.736 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, MIME_8BIT_HEADER=0.3] 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 AXU80ZwH6S1z; Wed, 29 Jan 2014 09:12:45 -0800 (PST)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 915E01A03E9; Wed, 29 Jan 2014 09:12:45 -0800 (PST)
Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id s0THCRQf005523 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 29 Jan 2014 11:12:28 -0600 (CST) (envelope-from ben@nostrum.com)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Ben Campbell 
In-Reply-To: 
Date: Wed, 29 Jan 2014 11:12:27 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <009E92F4-DCA2-40A4-8E7A-EF6EB1BB8C06@nostrum.com>
References: <45B84D8F-AD8C-4B28-90DF-9B1C40771104@nostrum.com> <6833E320-7B45-4FC2-853B-62311DCF7E7B@nostrum.com>  
To: =?windows-1252?Q?I=F1aki_Baz_Castillo?= 
X-Mailer: Apple Mail (2.1827)
Received-SPF: pass (shaman.nostrum.com: 173.172.146.58 is authenticated by a trusted mechanism)
Cc: Cullen Jennings , "draft-pd-dispatch-msrp-websocket.all@tools.ietf.org" , DISPATCH , "rai@ietf.org" 
Subject: Re: [dispatch] [RAI] MSRP Expert Review of draft-pd-dispatch-msrp-websocket-04
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, 29 Jan 2014 17:12:47 -0000

On Jan 29, 2014, at 10:42 AM, I=F1aki Baz Castillo  =
wrote:

> 2014-01-29 Cullen Jennings (fluffy) :
>> I don=92t see why using websockets would require us to get rid of the =
MUST use TLS.
>>=20
>> The security of relays is a total disaster if you don=92t have this =
so if the MUST be security authenticated goes away for relays, then I =
suspect this mechanisms is too broken to publish.
>=20
> Neither I understand why the "MUST use TLS" should be dropped for MSRP
> over WebSocket. I cannot figure out any reasons for getting rid of
> that requirement. If it was valid and appropriate for MSRP over TCP
> then it should also be for MSRP over WebSocket.

The argument (I'm just relaying it, not making it) has been that =
Websocket implementations do not give the application that level of =
control over the security aspects of a connection. One could =
counter-argue that this means those implementations are not appropriate =
for MSRP (I'm on the fence on that one.)

Can the authors elaborate on the implementation issues? For example, do =
WebSocket implementations properly handle things like HTTPS URLs?


>=20
> Just my opinion.
>=20
>=20
> --=20
> I=F1aki Baz Castillo
> 


From fluffy@cisco.com  Wed Jan 29 09:16:19 2014
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 C90891A036A; Wed, 29 Jan 2014 09:16:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -115.036
X-Spam-Level: 
X-Spam-Status: No, score=-115.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] 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 hDexQ0-5W-aA; Wed, 29 Jan 2014 09:16:18 -0800 (PST)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 6F45A1A02DD; Wed, 29 Jan 2014 09:16:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=295; q=dns/txt; s=iport; t=1391015776; x=1392225376; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=58FgvBU8bDVFMT1twNnGgb7kifD+dk5fRcyC9U/oRqA=; b=FLUv3Vikg4R1NAeT42/1P/Lht00b3SMIMNWufEUDeRX8EpBBISmyUEVc kuf3oc28c66AoWmP9fJcQV4jhDtWtHjMk7DhWowhIE8F563Yy+kloRN8c TOeyfVmBJgGs8AFKOB5JsPFI0RREQ3uZ0fDRRN4BdWMJ4QkSpQNjaehH6 A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgsFADQ26VKtJV2a/2dsb2JhbABZgwyBDr0CgQcWdIIlAQEBAwFrDgULAgEIRjIlAgQOBYd9CMoHF45MMweDJIEUAQOYKJIfgy2CKg
X-IronPort-AV: E=Sophos;i="4.95,743,1384300800"; d="scan'208";a="300591833"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-4.cisco.com with ESMTP; 29 Jan 2014 17:16:15 +0000
Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s0THGF6J022194 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 29 Jan 2014 17:16:15 GMT
Received: from xmb-aln-x02.cisco.com ([169.254.5.76]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0123.003; Wed, 29 Jan 2014 11:16:15 -0600
From: "Cullen Jennings (fluffy)" 
To: Ben Campbell 
Thread-Topic: [dispatch] [RAI] MSRP Expert Review of draft-pd-dispatch-msrp-websocket-04
Thread-Index: AQHPHREvsOjdfxbdLEen8YpQET53pZqcVQSAgAABC4A=
Date: Wed, 29 Jan 2014 17:16:14 +0000
Message-ID: <21D932E0-32D6-476A-B68E-21ABDEBB21EC@cisco.com>
References: <45B84D8F-AD8C-4B28-90DF-9B1C40771104@nostrum.com> <6833E320-7B45-4FC2-853B-62311DCF7E7B@nostrum.com>   <009E92F4-DCA2-40A4-8E7A-EF6EB1BB8C06@nostrum.com>
In-Reply-To: <009E92F4-DCA2-40A4-8E7A-EF6EB1BB8C06@nostrum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.20.249.164]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <750B2A4400EF5E44986576D34EDA8400@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: DISPATCH , "rai@ietf.org" , "draft-pd-dispatch-msrp-websocket.all@tools.ietf.org" 
Subject: Re: [dispatch] [RAI] MSRP Expert Review of draft-pd-dispatch-msrp-websocket-04
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, 29 Jan 2014 17:16:20 -0000

On Jan 29, 2014, at 10:12 AM, Ben Campbell  wrote:

> he argument (I'm just relaying it, not making it) has been that Websocket=
 implementations do not give the application that level of control over the=
 security aspects of a connection.=20

color me skeptical =85.



From peter.dunkley@crocodilertc.net  Wed Jan 29 09:16:54 2014
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 F0A521A02DD for ; Wed, 29 Jan 2014 09:16:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.078
X-Spam-Level: 
X-Spam-Status: No, score=-1.078 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 UIBdm5FHLvzs for ; Wed, 29 Jan 2014 09:16:51 -0800 (PST)
Received: from mail-vb0-x232.google.com (mail-vb0-x232.google.com [IPv6:2607:f8b0:400c:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id 585991A0355 for ; Wed, 29 Jan 2014 09:16:51 -0800 (PST)
Received: by mail-vb0-f50.google.com with SMTP id w8so1306513vbj.23 for ; Wed, 29 Jan 2014 09:16:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=crocodilertc.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gFJyuor+l0+g/IziGFIo6xYFW5VigiMk6v7VRmhAZ9w=; b=fZJpvhy4X1OGcZae4Yg2jaiw3yq7743LtSWbaEmvSGcnrHcDjpd3O6p2AQPG4df5BA kJOXh3KD3mq6fXzbwcUbkKc37HJ5t5rB72BM3HlY6ngZERt2gH44dljRSzFUbH94H7mW vpQHNADtr4XceLqUju7ECP6yEdXCbCZizhD8s=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=gFJyuor+l0+g/IziGFIo6xYFW5VigiMk6v7VRmhAZ9w=; b=L3jzaZkwkeP4TkXlrez6+cMDaDeeDDRQGwOiqdUX9p83sma0P7qf9WochynZKSWPYk HpnnUlGYu1vMrebrX53UKiWNJLGVhDs3fVU+jkm84qg5CeZVDZ02d4zNCwF0Dmpi1Rx6 FbL+vGywQI1nYsWc0tJfr8BRyYp9tvfJLj2pJSu7OtWq5nqgMp5/lRXuDg4UB2ukwxbC OVphhkFmyRGMZjL9KCfbYNl8uW1jOeJ8KquRLEHqjQMKpp8EC7bdV4IsjJ1LH5oH6xrs T+qzNODdex5SB2qV0ef+FNMp7YcN8fPfff2iP9CTjeI4V8s6b7xSNdnx1oJwHZFu/5lk lioQ==
X-Gm-Message-State: ALoCoQl9K3ahh4KqCeK/myr/mSGcj0M29iE8m2H1BOznaMdnRLc9xSb2QeRR2h7E8nHmxw0pdL96
MIME-Version: 1.0
X-Received: by 10.52.187.232 with SMTP id fv8mr252813vdc.60.1391015808167; Wed, 29 Jan 2014 09:16:48 -0800 (PST)
Received: by 10.58.187.114 with HTTP; Wed, 29 Jan 2014 09:16:48 -0800 (PST)
In-Reply-To: 
References: <45B84D8F-AD8C-4B28-90DF-9B1C40771104@nostrum.com> <6833E320-7B45-4FC2-853B-62311DCF7E7B@nostrum.com>  
Date: Wed, 29 Jan 2014 12:16:48 -0500
Message-ID: 
From: Peter Dunkley 
To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= 
Content-Type: multipart/alternative; boundary=bcaec548a6031f8bbc04f11f1b6c
Cc: "Cullen Jennings \(fluffy\)" , Ben Campbell , DISPATCH , "rai@ietf.org" , "draft-pd-dispatch-msrp-websocket.all@tools.ietf.org" 
Subject: Re: [dispatch] [RAI] MSRP Expert Review of draft-pd-dispatch-msrp-websocket-04
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, 29 Jan 2014 17:16:54 -0000

--bcaec548a6031f8bbc04f11f1b6c
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

We can put back the MUST if you want, but from a client point-of-view it
doesn't seem to make sense as choosing between TLS and not TLS is just a
matter of what WebSocket URI is used in the browser.  Further, unless you
have a trusted CA signed certificate on the server a browser won't allow
the connection - there is no UI to let you accept an exception like you
have with a web-page.

Even if TLS is left as MUST all of the additional checks from the RFC
cannot be enforced on the client because (in a browser) you don't have any
access to that information.

My reason for loosening the MUST to a SHOULD was that, pragmatically, the
security level in the MSRP Relay RFC is not achievable here.  Also, if you
are deploying MSRP internally (and did not require encryption) the
certificate handling in a browser (requiring the organisation to pay for a
certificate or importing something into each browser) is not something that
(realistically) people will do.

So by all means let's put MUST back if you want it there - but (should
anyone actually use this on a private network) that MUST will probably just
be ignored anyway.  Which makes me think SHOULD probably matches how things
will actually be used anyway.

Regards,

Peter



On 29 January 2014 11:42, I=F1aki Baz Castillo  wrote:

> 2014-01-29 Cullen Jennings (fluffy) :
> > I don't see why using websockets would require us to get rid of the MUS=
T
> use TLS.
> >
> > The security of relays is a total disaster if you don't have this so if
> the MUST be security authenticated goes away for relays, then I suspect
> this mechanisms is too broken to publish.
>
> Neither I understand why the "MUST use TLS" should be dropped for MSRP
> over WebSocket. I cannot figure out any reasons for getting rid of
> that requirement. If it was valid and appropriate for MSRP over TCP
> then it should also be for MSRP over WebSocket.
>
> Just my opinion.
>
>
> --
> I=F1aki Baz Castillo
> 
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>



--=20
Peter Dunkley
Technical Director
Crocodile RCS Ltd

--bcaec548a6031f8bbc04f11f1b6c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


We can put back the MUST if you want, but from a client po=
int-of-view it doesn't seem to make sense as choosing between TLS and n=
ot TLS is just a matter of what WebSocket URI is used in the browser.  =
;Further, unless you have a trusted CA signed certificate on the server a b=
rowser won't allow the connection - there is no UI to let you accept an=
 exception like you have with a web-page.


Even if TLS is left as MUST all of the additional checks fro=
m the RFC cannot be enforced on the client because (in a browser) you don&#=
39;t have any access to that information.

My reaso=
n for loosening the MUST to a SHOULD was that, pragmatically, the security =
level in the MSRP Relay RFC is not achievable here.  Also, if you are =
deploying MSRP internally (and did not require encryption) the certificate =
handling in a browser (requiring the organisation to pay for a certificate =
or importing something into each browser) is not something that (realistica=
lly) people will do.



So by all means let's put MUST back if you want it =
there - but (should anyone actually use this on a private network) that MUS=
T will probably just be ignored anyway.  Which makes me think SHOULD p=
robably matches how things will actually be used anyway.



Regards,

Peter

=



On 29 January=
 2014 11:42, I=F1aki Baz Castillo <ibc@aliax.net> wrote:


2014-01-29 Cullen Jennings (fluffy) <fluffy@cisco.com>:


> I don’t see why using websockets would require=
 us to get rid of the MUST use TLS.

>

> The security of relays is a total disaster if you don’t have thi=
s so if the MUST be security authenticated goes away for relays, then I sus=
pect this mechanisms is too broken to publish.




Neither I understand why the "MUST use TLS" should be dropp=
ed for MSRP

over WebSocket. I cannot figure out any reasons for getting rid of

that requirement. If it was valid and appropriate for MSRP over TCP

then it should also be for MSRP over WebSocket.



Just my opinion.





--

I=F1aki Baz Castillo

<ibc@aliax.net>


_____________________=
__________________________

dispatch mailing list

dispatch@ietf.org

https://www.ietf.org/mailman/listinfo/dispatch





-- 
=

Peter Dunkley
Technical Director


Crocodile RCS Ltd




--bcaec548a6031f8bbc04f11f1b6c--

From ibc@aliax.net  Wed Jan 29 09:22:44 2014
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 384991A02C0 for ; Wed, 29 Jan 2014 09:22:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.678
X-Spam-Level: 
X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] 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 KUv8hzbRxYGH for ; Wed, 29 Jan 2014 09:22:43 -0800 (PST)
Received: from mail-qc0-f179.google.com (mail-qc0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id 25EC31A0220 for ; Wed, 29 Jan 2014 09:22:43 -0800 (PST)
Received: by mail-qc0-f179.google.com with SMTP id e16so3173874qcx.24 for ; Wed, 29 Jan 2014 09:22:40 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=Hgo32VTwnAIQhQrVFHsYa1iEumfVzx9twbr8VAhlCPA=; b=Q1szgQey7It742wtlqBGse/qCKFWH6VyNNGQOmaicT4fDNA8qoGlSz3+tBihvCVHX1 qDSlHCPB5Jz7T9x3rlhd3RIiz+2K3/dBacyZcvJrp9MThqeOhBeHG27Ztjqyuj28L7Q4 vDzqvtRQbPai9NU3qR+hmxdvtH0OVFTkTy3kEghkdMHa0RVwQLUew03o/z4JdXrwm7bf AKkcPebezeOFxcZQUPA6e4Vau++irJ23UkTbtXHZ57e4DeGbBkwU/yFsYU0q/fASiNK1 Snr3WdvON1TxVYaVgVwSyxS3czPnKeYRgXDqSLr9u8Oi2dZ1/uQGuqTch438UdofqRK7 l/fg==
X-Gm-Message-State: ALoCoQl6LkaZ/vvxN1ok2vTN0jTW5oI/e/6x7PESu3aEN9pmONOzi3yHpDmiS71sqwA7Fl1Y6lLI
X-Received: by 10.224.156.68 with SMTP id v4mr14148531qaw.66.1391016160031; Wed, 29 Jan 2014 09:22:40 -0800 (PST)
MIME-Version: 1.0
Received: by 10.96.101.232 with HTTP; Wed, 29 Jan 2014 09:22:19 -0800 (PST)
In-Reply-To: <009E92F4-DCA2-40A4-8E7A-EF6EB1BB8C06@nostrum.com>
References: <45B84D8F-AD8C-4B28-90DF-9B1C40771104@nostrum.com> <6833E320-7B45-4FC2-853B-62311DCF7E7B@nostrum.com>   <009E92F4-DCA2-40A4-8E7A-EF6EB1BB8C06@nostrum.com>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
Date: Wed, 29 Jan 2014 18:22:19 +0100
Message-ID: 
To: Ben Campbell 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: Cullen Jennings , "draft-pd-dispatch-msrp-websocket.all@tools.ietf.org" , DISPATCH , "rai@ietf.org" 
Subject: Re: [dispatch] [RAI] MSRP Expert Review of draft-pd-dispatch-msrp-websocket-04
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, 29 Jan 2014 17:22:44 -0000

2014-01-29 Ben Campbell :
> The argument (I'm just relaying it, not making it) has been that Websocke=
t implementations do not give the application that level of control over th=
e security aspects of a connection. One could counter-argue that this means=
 those implementations are not appropriate for MSRP (I'm on the fence on th=
at one.)
>
> Can the authors elaborate on the implementation issues? For example, do W=
ebSocket implementations properly handle things like HTTPS URLs?

Hi, let me please tell something about WebSocket and TLS (so URIs with
scheme "wss://"):

1) Firefox and latest version of Chrome do NOT allow insecure
(non-TLS) WebSocket connections if the web page has "https" schema.

2) When the web page is "https", Firefox and Chrome do NOT allow
WebSocket secure connections ("wss") if the WebSocket server
certificate is not valid (expired, auto-signed...). I mean: the
browser does not even prompt for permissions to the user, it just
fails the WSS connection.



Point 1) is terribly important IMHO. Note that for WebRTC applications
to be "friendly" HTTPS is required (so the user is not prompted by the
browser for permission every time a WebRTC session is requested via
getUserMedia). So let's assume that WebRTC, in fact, requires HTTPS.
Taking into account point 1) above, we also need Secure WebSocket
("wss") for MSRP or for anything.

--=20
I=C3=B1aki Baz Castillo


From peter.dunkley@crocodilertc.net  Wed Jan 29 09:30:42 2014
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 95E081A0276 for ; Wed, 29 Jan 2014 09:30:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.078
X-Spam-Level: 
X-Spam-Status: No, score=-1.078 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 ePrunXX4tA9r for ; Wed, 29 Jan 2014 09:30:41 -0800 (PST)
Received: from mail-ve0-x235.google.com (mail-ve0-x235.google.com [IPv6:2607:f8b0:400c:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 0C9FE1A0216 for ; Wed, 29 Jan 2014 09:30:40 -0800 (PST)
Received: by mail-ve0-f181.google.com with SMTP id cz12so1382421veb.26 for ; Wed, 29 Jan 2014 09:30:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=crocodilertc.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TTBY8u9Tfcgq7RyepmJonohHpiLWMBzR9AncUfJMpTs=; b=KD4q+jXO70EZYYqNTZD4E3WKeSBZBq6ja3M+p7MU0WPOY9d/bfQwsbqsM0yABuO41u Zpm9ypmTUPVQIl01Mp9lXzFZPS9Hjl6dyzl+vG1+WbRVmq9W2n6fjzO3SBRyVqlgSBP7 Cguc/fRNpOlflLSfomgCdJ6UrN85tNAY8Kon8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=TTBY8u9Tfcgq7RyepmJonohHpiLWMBzR9AncUfJMpTs=; b=Th/Ht+m5oEWTLjYkGV4CfSTktIor0JRYGss9G+tlKtrI0OS+iBpqOYubj67daDWXe/ 9Tvz1mfzn4Z2/e6iZ8v1hRrHHV6FRDGAZLOFjjnAP8Sdnhlazw/rezJcqffI4zc+PwFg nOXILTn3z5gqgpQ2fgvK9i85tFddAfQXMSCFYFWkShOzSbWvNCjDrptFM/3pA+In6RW7 Ekar/mek1IYbWthse65PkXoSu38mvIZctgQoCvy82Ed/K+jR77DtFUHya7M+QDD9Qwsm p9fEBtZx0tZEqR/zBNlv9bOuiIJXJff/C/xHM7UE+Cw2rfNkl4BtvXFhfXun7y2UGMhm DN4A==
X-Gm-Message-State: ALoCoQmX1mzRaOCm3JTgCsc0luMLvPnp62jOXilNUj9CzUmNEmFDErkc/y82Vo8qhqRz3pelsn23
MIME-Version: 1.0
X-Received: by 10.58.90.1 with SMTP id bs1mr1657926veb.29.1391016637919; Wed, 29 Jan 2014 09:30:37 -0800 (PST)
Received: by 10.58.187.114 with HTTP; Wed, 29 Jan 2014 09:30:37 -0800 (PST)
In-Reply-To: 
References: <45B84D8F-AD8C-4B28-90DF-9B1C40771104@nostrum.com> <6833E320-7B45-4FC2-853B-62311DCF7E7B@nostrum.com>   <009E92F4-DCA2-40A4-8E7A-EF6EB1BB8C06@nostrum.com> 
Date: Wed, 29 Jan 2014 12:30:37 -0500
Message-ID: 
From: Peter Dunkley 
To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= 
Content-Type: multipart/alternative; boundary=089e0118457494999a04f11f4cc4
Cc: Cullen Jennings , Ben Campbell , DISPATCH , "rai@ietf.org" , "draft-pd-dispatch-msrp-websocket.all@tools.ietf.org" 
Subject: Re: [dispatch] [RAI] MSRP Expert Review of draft-pd-dispatch-msrp-websocket-04
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, 29 Jan 2014 17:30:42 -0000

--089e0118457494999a04f11f4cc4
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 29 January 2014 12:22, I=F1aki Baz Castillo  wrote:

> Hi, let me please tell something about WebSocket and TLS (so URIs with
> scheme "wss://"):
>
> 1) Firefox and latest version of Chrome do NOT allow insecure
> (non-TLS) WebSocket connections if the web page has "https" schema.
>
> 2) When the web page is "https", Firefox and Chrome do NOT allow
> WebSocket secure connections ("wss") if the WebSocket server
> certificate is not valid (expired, auto-signed...). I mean: the
> browser does not even prompt for permissions to the user, it just
> fails the WSS connection.
>
>
>
> Point 1) is terribly important IMHO. Note that for WebRTC applications
> to be "friendly" HTTPS is required (so the user is not prompted by the
> browser for permission every time a WebRTC session is requested via
> getUserMedia). So let's assume that WebRTC, in fact, requires HTTPS.
> Taking into account point 1) above, we also need Secure WebSocket
> ("wss") for MSRP or for anything.
>
>
Which is great on the Internet but a real pain on an internal network where
you don't want to pay for a certificate or import something into every
single device/computer on your network.  That's the same reason people
usually don't use HTTPS on internal networks!

Hence my belief that SHOULD was the right thing here.  People SHOULD use
TLS security, but saying MUST will just mean that this is a MUST people
ignore on certain deployment types.  What is the point of mandating
something when people will just ignore it when it doesn't suit them?

I get that security is important and the IETF is full of security
idealists, and all IETF protocols should be secure, by in this particular
situation it feels like using MUST instead of SHOULD would be done simply
because in the IETF you always say MUST for security (whether people will
use it or not).

Regards,

Peter

--=20
Peter Dunkley
Technical Director
Crocodile RCS Ltd

--089e0118457494999a04f11f4cc4
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



=
On 29 January 2014 12:22, I=F1aki Baz Castillo <ibc@aliax.net> w=
rote:

Hi, let me please tell something about WebSocket and TLS (so URIs with

scheme "wss://"):



1) Firefox and latest version of Chrome do NOT allow insecure

(non-TLS) WebSocket connections if the web page has "https" schem=
a.



2) When the web page is "https", Firefox and Chrome do NOT allow<=
br>
WebSocket secure connections ("wss") if the WebSocket server

certificate is not valid (expired, auto-signed...). I mean: the

browser does not even prompt for permissions to the user, it just

fails the WSS connection.







Point 1) is terribly important IMHO. Note that for WebRTC applications

to be "friendly" HTTPS is required (so the user is not prompted b=
y the

browser for permission every time a WebRTC session is requested via

getUserMedia). So let's assume that WebRTC, in fact, requires HTTPS.
Taking into account point 1) above, we also need Secure WebSocket

("wss") for MSRP or for anything.



<=
br>
Which is great on the Internet but a real pain on an internal=
 network where you don't want to pay for a certificate or import someth=
ing into every single device/computer on your network. =A0That's the sa=
me reason people usually don't use HTTPS on internal networks!



Hence my belief that SHOULD was the right thing here. =
=A0People SHOULD use TLS security, but saying MUST will just mean that this=
 is a MUST people ignore on certain deployment types. =A0What is the point =
of mandating something when people will just ignore it when it doesn't =
suit them?



I get that security is important and the IETF is full o=
f security idealists, and all IETF protocols should be secure, by in this p=
articular situation it feels like using MUST instead of SHOULD would be don=
e simply because in the IETF you always say MUST for security (whether peop=
le will use it or not).



Regards,

Peter
=A0
-- 
Tech=
nical Director


Crocodile RCS Ltd




--089e0118457494999a04f11f4cc4--

From mary.ietf.barnes@gmail.com  Wed Jan 29 09:45:27 2014
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 DE9001A0276; Wed, 29 Jan 2014 09:45:27 -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 rb0SGLVC-y5b; Wed, 29 Jan 2014 09:45:25 -0800 (PST)
Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 5535C1A0146; Wed, 29 Jan 2014 09:45:25 -0800 (PST)
Received: by mail-ie0-f180.google.com with SMTP id at1so2385474iec.39 for ; Wed, 29 Jan 2014 09:45:22 -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=FeMXk/rWfwNrPXdfpA8jSxlaHHbfJF8Z3nptvJKl4Zk=; b=nLJRXDmEArnVE1EwMrMlwnguezMACk7e2J3h7hRLdJ4OnRUEqfSUZz4kNW+lY3YkjM dr9XK1rnyzpUcnZEpBQlf6cucsT5OLKiD8usMiLy+BLh3AcMxhVFX2Jp/tKFZOjPKoYG lKf4MMBtHaTMwrvW58B3LqBSF6zwDRJutDVnQyhIU60eDRV5f6XUi5a1lzaPMbe1A6Yi tqSsuL49vjYJzzK4l4OvlA9Zt0nHjOQ3QGgtjCVQV4YvcZQtIhUYh/EbvKpvIRFhu4xF 7pf9wWjCLXkSdCoBO9eBc/r/6d4sDJumGvgFMQS5FOrBLgVd11EO3bORDVfXnCUjL+vA rnvA==
MIME-Version: 1.0
X-Received: by 10.50.110.3 with SMTP id hw3mr19566924igb.12.1391017522252; Wed, 29 Jan 2014 09:45:22 -0800 (PST)
Received: by 10.43.58.137 with HTTP; Wed, 29 Jan 2014 09:45:22 -0800 (PST)
In-Reply-To: 
References: <45B84D8F-AD8C-4B28-90DF-9B1C40771104@nostrum.com> <6833E320-7B45-4FC2-853B-62311DCF7E7B@nostrum.com>   <009E92F4-DCA2-40A4-8E7A-EF6EB1BB8C06@nostrum.com>  
Date: Wed, 29 Jan 2014 11:45:22 -0600
Message-ID: 
From: Mary Barnes 
To: Peter Dunkley 
Content-Type: multipart/alternative; boundary=089e013cbd504a524b04f11f8108
Cc: Cullen Jennings , DISPATCH , "rai@ietf.org" , Ben Campbell , "draft-pd-dispatch-msrp-websocket.all@tools.ietf.org" 
Subject: Re: [dispatch] [RAI] MSRP Expert Review of draft-pd-dispatch-msrp-websocket-04
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, 29 Jan 2014 17:45:28 -0000

--089e013cbd504a524b04f11f8108
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Peter et al,

This thread of discussion gets back to one of the points I made in my
shepherd review of the document (note that I don't think there's been any
responses from the authors on any of my comments):
http://www.ietf.org/mail-archive/web/dispatch/current/msg05173.html

If TLS is a SHOULD then you need to clearly explain the context in which
one might not use TLS and what the implications and risks are.  There are
still security risks (e.g., malicious actors) in internal networks.

Regards,
Mary.


On Wed, Jan 29, 2014 at 11:30 AM, Peter Dunkley <
peter.dunkley@crocodilertc.net> wrote:

>
> On 29 January 2014 12:22, I=F1aki Baz Castillo  wrote:
>
>> Hi, let me please tell something about WebSocket and TLS (so URIs with
>> scheme "wss://"):
>>
>> 1) Firefox and latest version of Chrome do NOT allow insecure
>> (non-TLS) WebSocket connections if the web page has "https" schema.
>>
>> 2) When the web page is "https", Firefox and Chrome do NOT allow
>> WebSocket secure connections ("wss") if the WebSocket server
>> certificate is not valid (expired, auto-signed...). I mean: the
>> browser does not even prompt for permissions to the user, it just
>> fails the WSS connection.
>>
>>
>>
>> Point 1) is terribly important IMHO. Note that for WebRTC applications
>> to be "friendly" HTTPS is required (so the user is not prompted by the
>> browser for permission every time a WebRTC session is requested via
>> getUserMedia). So let's assume that WebRTC, in fact, requires HTTPS.
>> Taking into account point 1) above, we also need Secure WebSocket
>> ("wss") for MSRP or for anything.
>>
>>
> Which is great on the Internet but a real pain on an internal network
> where you don't want to pay for a certificate or import something into
> every single device/computer on your network.  That's the same reason
> people usually don't use HTTPS on internal networks!
>
> Hence my belief that SHOULD was the right thing here.  People SHOULD use
> TLS security, but saying MUST will just mean that this is a MUST people
> ignore on certain deployment types.  What is the point of mandating
> something when people will just ignore it when it doesn't suit them?
>

> I get that security is important and the IETF is full of security
> idealists, and all IETF protocols should be secure, by in this particular
> situation it feels like using MUST instead of SHOULD would be done simply
> because in the IETF you always say MUST for security (whether people will
> use it or not).
>
[MB] That's not true. But, what is true is that anytime you have a SHOULD
do x, you need to explain the situations in which you wouldn't do x and any
implications and risks associated with not doing x.  [/MB]

>
> Regards,
>
> Peter
>
> --
> Peter Dunkley
> Technical Director
> Crocodile RCS Ltd
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>
>

--089e013cbd504a524b04f11f8108
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


Peter et al,

This thread of discussion =
gets back to one of the points I made in my shepherd review of the document=
 (note that I don't think there's been any responses from the autho=
rs on any of my comments):=A0



If TLS is a SHOULD then you need to cle=
arly explain the context in which one might not use TLS and what the implic=
ations and risks are. =A0There are still security risks (e.g., malicious ac=
tors) in internal networks.



Regards,
Mary.


On Wed, Jan 29, 2014 at 11:30 AM,=
 Peter Dunkley <peter.dunkley@crocodilertc.net>=
 wrote:


=

On 29 January 2014 12:22, =
I=F1aki Baz Castillo <ibc@aliax.net> wrote:



Hi, let me please tell something about WebSocket and TLS (so URIs with

scheme "wss://"):



1) Firefox and latest version of Chrome do NOT allow insecure

(non-TLS) WebSocket connections if the web page has "https" schem=
a.



2) When the web page is "https", Firefox and Chrome do NOT allow<=
br>
WebSocket secure connections ("wss") if the WebSocket server

certificate is not valid (expired, auto-signed...). I mean: the

browser does not even prompt for permissions to the user, it just

fails the WSS connection.







Point 1) is terribly important IMHO. Note that for WebRTC applications

to be "friendly" HTTPS is required (so the user is not prompted b=
y the

browser for permission every time a WebRTC session is requested via

getUserMedia). So let's assume that WebRTC, in fact, requires HTTPS.
Taking into account point 1) above, we also need Secure WebSocket

("wss") for MSRP or for anything.




Which is g=
reat on the Internet but a real pain on an internal network where you don&#=
39;t want to pay for a certificate or import something into every single de=
vice/computer on your network. =A0That's the same reason people usually=
 don't use HTTPS on internal networks!




Hence my belief that SHOULD was the right thing here. =
=A0People SHOULD use TLS security, but saying MUST will just mean that this=
 is a MUST people ignore on certain deployment types. =A0What is the point =
of mandating something when people will just ignore it when it doesn't =
suit them?





I get that security is important and the IETF is full o=
f security idealists, and all IETF protocols should be secure, by in this p=
articular situation it feels like using MUST instead of SHOULD would be don=
e simply because in the IETF you always say MUST for security (whether peop=
le will use it or not).


[MB] That's not true. But, what is =
true is that anytime you have a SHOULD do x, you need to explain the situat=
ions in which you wouldn't do x and any implications and risks associat=
ed with not doing x. =A0[/MB]=A0


=




Regards,

Peter
=A0
-- 
Peter Dunkley
Technical Director



Crocodile RCS Ltd




_______________________________________________

dispatch mailing list

dispatch@ietf.org

https://www.ietf.org/mailman/listinfo/dispatch





--089e013cbd504a524b04f11f8108--

From peter.dunkley@crocodilertc.net  Wed Jan 29 09:48:24 2014
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 58B1C1A0352 for ; Wed, 29 Jan 2014 09:48:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level: 
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=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 IWW1HTantO7o for ; Wed, 29 Jan 2014 09:48:22 -0800 (PST)
Received: from mail-ve0-x236.google.com (mail-ve0-x236.google.com [IPv6:2607:f8b0:400c:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 1A6A11A0276 for ; Wed, 29 Jan 2014 09:48:21 -0800 (PST)
Received: by mail-ve0-f182.google.com with SMTP id jy13so1401317veb.41 for ; Wed, 29 Jan 2014 09:48:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=crocodilertc.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZjQ618CcszHWNOsmW5hngKkISmg5B7JCepWuG7vrcu8=; b=PEs7UbCexarp7ByCKw6kx8RH6If+9Y8kxwaVBAQhUC6ZerEQZmJ5xdavO9OQsW5rc8 WdrwEc4dLPuDqCUxbDqBjGn1hTOXYpcUnI+GNZ1wiDzKI+802KtFj8LVSIcazKrFoB7h SycOQy8YSboGNBHOw7xV4RA5HYTKkYHDjxl28=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ZjQ618CcszHWNOsmW5hngKkISmg5B7JCepWuG7vrcu8=; b=Ys0tEV9mJilomuCDR4VR76PLd9jV3eixUkfMAB+km1roLHdUI1XEkxzRszYuKpa8gi yKpxFWkYy/xPNmoXfoYOyfPijcLQRIFCrr1IilxfaYHuKsXe9sHtY8mDw6h/QOaWyX3H XPwJOq63z9IvUKYjuwcHXvybjkuGeLWm4CBjJ9pNOt4mZz+tKN8Rl138Dsd5i5YvfRHz /f+eDeS2S2pSkXkhgpwFXM25Bq+6LFvFAigfWsthxYZecxfgXXQtLRfczyuhv0N98FFy NpQY/yI4X+zZcGzlkesr+rPTQ1GrYR1Z59Tut4C+PCXKGebR+6H0ssOL2Bs3TGuSCkEi Px2Q==
X-Gm-Message-State: ALoCoQm78Uu5I/MUrPxZvon0wFVDh82p6S1TlZqoc/xGJZ3arRs/RTvblSkvCQq/N+5pcibrvt51
MIME-Version: 1.0
X-Received: by 10.220.103.141 with SMTP id k13mr2100328vco.25.1391017698926; Wed, 29 Jan 2014 09:48:18 -0800 (PST)
Received: by 10.58.187.114 with HTTP; Wed, 29 Jan 2014 09:48:18 -0800 (PST)
In-Reply-To: 
References: <45B84D8F-AD8C-4B28-90DF-9B1C40771104@nostrum.com> <6833E320-7B45-4FC2-853B-62311DCF7E7B@nostrum.com>   <009E92F4-DCA2-40A4-8E7A-EF6EB1BB8C06@nostrum.com>   
Date: Wed, 29 Jan 2014 12:48:18 -0500
Message-ID: 
From: Peter Dunkley 
To: Mary Barnes 
Content-Type: multipart/alternative; boundary=047d7b342d30d2355204f11f8b0a
Cc: Cullen Jennings , DISPATCH , "rai@ietf.org" , Ben Campbell , "draft-pd-dispatch-msrp-websocket.all@tools.ietf.org" 
Subject: Re: [dispatch] [RAI] MSRP Expert Review of draft-pd-dispatch-msrp-websocket-04
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, 29 Jan 2014 17:48:24 -0000

--047d7b342d30d2355204f11f8b0a
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hello Mary,

The document authors have been discussing updates to the documents and plan
to do work on this in the first half of February.  No-one has had time to
properly respond to the comments yet due to other commitments.

Regards,

Peter


On 29 January 2014 12:45, Mary Barnes  wrote:

> Peter et al,
>
> This thread of discussion gets back to one of the points I made in my
> shepherd review of the document (note that I don't think there's been any
> responses from the authors on any of my comments):
> http://www.ietf.org/mail-archive/web/dispatch/current/msg05173.html
>
> If TLS is a SHOULD then you need to clearly explain the context in which
> one might not use TLS and what the implications and risks are.  There are
> still security risks (e.g., malicious actors) in internal networks.
>
> Regards,
> Mary.
>
>
> On Wed, Jan 29, 2014 at 11:30 AM, Peter Dunkley <
> peter.dunkley@crocodilertc.net> wrote:
>
>>
>> On 29 January 2014 12:22, I=F1aki Baz Castillo  wrote:
>>
>>> Hi, let me please tell something about WebSocket and TLS (so URIs with
>>> scheme "wss://"):
>>>
>>> 1) Firefox and latest version of Chrome do NOT allow insecure
>>> (non-TLS) WebSocket connections if the web page has "https" schema.
>>>
>>> 2) When the web page is "https", Firefox and Chrome do NOT allow
>>> WebSocket secure connections ("wss") if the WebSocket server
>>> certificate is not valid (expired, auto-signed...). I mean: the
>>> browser does not even prompt for permissions to the user, it just
>>> fails the WSS connection.
>>>
>>>
>>>
>>> Point 1) is terribly important IMHO. Note that for WebRTC applications
>>> to be "friendly" HTTPS is required (so the user is not prompted by the
>>> browser for permission every time a WebRTC session is requested via
>>> getUserMedia). So let's assume that WebRTC, in fact, requires HTTPS.
>>> Taking into account point 1) above, we also need Secure WebSocket
>>> ("wss") for MSRP or for anything.
>>>
>>>
>> Which is great on the Internet but a real pain on an internal network
>> where you don't want to pay for a certificate or import something into
>> every single device/computer on your network.  That's the same reason
>> people usually don't use HTTPS on internal networks!
>>
>> Hence my belief that SHOULD was the right thing here.  People SHOULD use
>> TLS security, but saying MUST will just mean that this is a MUST people
>> ignore on certain deployment types.  What is the point of mandating
>> something when people will just ignore it when it doesn't suit them?
>>
>
>> I get that security is important and the IETF is full of security
>> idealists, and all IETF protocols should be secure, by in this particula=
r
>> situation it feels like using MUST instead of SHOULD would be done simpl=
y
>> because in the IETF you always say MUST for security (whether people wil=
l
>> use it or not).
>>
> [MB] That's not true. But, what is true is that anytime you have a SHOULD
> do x, you need to explain the situations in which you wouldn't do x and a=
ny
> implications and risks associated with not doing x.  [/MB]
>
>>
>> Regards,
>>
>> Peter
>>
>> --
>> Peter Dunkley
>> Technical Director
>> Crocodile RCS Ltd
>>
>> _______________________________________________
>> dispatch mailing list
>> dispatch@ietf.org
>> https://www.ietf.org/mailman/listinfo/dispatch
>>
>>
>


--=20
Peter Dunkley
Technical Director
Crocodile RCS Ltd

--047d7b342d30d2355204f11f8b0a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


Hello Mary,

The document authors have b=
een discussing updates to the documents and plan to do work on this in the =
first half of February. =A0No-one has had time to properly respond to the c=
omments yet due to other commitments.



Regards,

Peter


On 29 January 201=
4 12:45, Mary Barnes <mary.ietf.barnes@gmail.com> w=
rote:


Peter et al,

=

This thread of discussion gets back to one of the points I made in my =
shepherd review of the document (note that I don't think there's be=
en any responses from the authors on any of my comments):=A0




If TLS is a SHOULD th=
en you need to clearly explain the context in which one might not use TLS a=
nd what the implications and risks are. =A0There are still security risks (=
e.g., malicious actors) in internal networks.




Regards,
Mary.


On Wed, Ja=
n 29, 2014 at 11:30 AM, Peter Dunkley <peter.dunkley@crocodil=
ertc.net> wrote:



=

On 29 January 2014 12:22, I=F1aki Baz C=
astillo <ibc@aliax.net> wrote:




Hi, let me please tell something about WebSocket and TLS (so URIs with

scheme "wss://"):



1) Firefox and latest version of Chrome do NOT allow insecure

(non-TLS) WebSocket connections if the web page has "https" schem=
a.



2) When the web page is "https", Firefox and Chrome do NOT allow<=
br>
WebSocket secure connections ("wss") if the WebSocket server

certificate is not valid (expired, auto-signed...). I mean: the

browser does not even prompt for permissions to the user, it just

fails the WSS connection.







Point 1) is terribly important IMHO. Note that for WebRTC applications

to be "friendly" HTTPS is required (so the user is not prompted b=
y the

browser for permission every time a WebRTC session is requested via

getUserMedia). So let's assume that WebRTC, in fact, requires HTTPS.
Taking into account point 1) above, we also need Secure WebSocket

("wss") for MSRP or for anything.




Which is g=
reat on the Internet but a real pain on an internal network where you don&#=
39;t want to pay for a certificate or import something into every single de=
vice/computer on your network. =A0That's the same reason people usually=
 don't use HTTPS on internal networks!





Hence my belief that SHOULD was the right thing here. =
=A0People SHOULD use TLS security, but saying MUST will just mean that this=
 is a MUST people ignore on certain deployment types. =A0What is the point =
of mandating something when people will just ignore it when it doesn't =
suit them?






I get that security is important and the IETF is full o=
f security idealists, and all IETF protocols should be secure, by in this p=
articular situation it feels like using MUST instead of SHOULD would be don=
e simply because in the IETF you always say MUST for security (whether peop=
le will use it or not).



[MB] That's not true. B=
ut, what is true is that anytime you have a SHOULD do x, you need to explai=
n the situations in which you wouldn't do x and any implications and ri=
sks associated with not doing x. =A0[/MB]=A0






Regards,

Peter
=A0
-- 
Peter Dunkley
Technical Director




Crocodile RCS Ltd




_______________________________________________=


dispatch mailing list

dispatch@ietf.org

https://www.ietf.org/mailman/listinfo/dispatch








-- 
Peter Dunkley
<=
div>Technical Director

Crocodile RCS Ltd




--047d7b342d30d2355204f11f8b0a--

From mary.ietf.barnes@gmail.com  Wed Jan 29 09:59:57 2014
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 6557D1A0216; Wed, 29 Jan 2014 09:59:57 -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 yaV9VDFRgVdU; Wed, 29 Jan 2014 09:59:54 -0800 (PST)
Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001:c05::236]) by ietfa.amsl.com (Postfix) with ESMTP id 96CD41A0146; Wed, 29 Jan 2014 09:59:54 -0800 (PST)
Received: by mail-ig0-f182.google.com with SMTP id uy17so5159729igb.3 for ; Wed, 29 Jan 2014 09:59:51 -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=W5bn1j4+NEXXvTl1Ywvu6PeUWHDrSbzd3eA63g6JaFE=; b=gd0aOClVtCI84jERPpFpZEyl0QCPGfiQRhU0zrJ3q6pGZPG7VJBRk63aGM0ddm2IGr MXCY/t8bQBgwUi+tnsYMRrZvRzGN7WIHxPqohr03I07X2lCfhgpuIdyUu+m5O2BxqP9N +TYpwj7vW+tBibRdM9gtJJ5Nxu/5+HgHzPvoNxPJpvYpwMnXaPyBCW4+EcFaRCSKzjI+ NqwLtPpeu6cbCQ9YKC7K4dIkkn5yT+0VJeSuwWe+ZP/2s13PjdN0KyKvwFXIKOJd8grM AUuKnq9zcEMwgv+ty8+nlReK0VXeHsL5tJXz2VoJfnl/W3I3AkvC6JBFo/uxDGbFbW2j nO5A==
MIME-Version: 1.0
X-Received: by 10.50.110.3 with SMTP id hw3mr19633045igb.12.1391018391590; Wed, 29 Jan 2014 09:59:51 -0800 (PST)
Received: by 10.43.58.137 with HTTP; Wed, 29 Jan 2014 09:59:51 -0800 (PST)
In-Reply-To: 
References: <45B84D8F-AD8C-4B28-90DF-9B1C40771104@nostrum.com> <6833E320-7B45-4FC2-853B-62311DCF7E7B@nostrum.com>   <009E92F4-DCA2-40A4-8E7A-EF6EB1BB8C06@nostrum.com>    
Date: Wed, 29 Jan 2014 11:59:51 -0600
Message-ID: 
From: Mary Barnes 
To: Peter Dunkley 
Content-Type: multipart/alternative; boundary=089e013cbd501bed2504f11fb5b3
Cc: Cullen Jennings , DISPATCH , "rai@ietf.org" , Ben Campbell , "draft-pd-dispatch-msrp-websocket.all@tools.ietf.org" 
Subject: Re: [dispatch] [RAI] MSRP Expert Review of draft-pd-dispatch-msrp-websocket-04
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, 29 Jan 2014 17:59:57 -0000

--089e013cbd501bed2504f11fb5b3
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Peter,

Thanks for the update.

Mary.


On Wed, Jan 29, 2014 at 11:48 AM, Peter Dunkley <
peter.dunkley@crocodilertc.net> wrote:

> Hello Mary,
>
> The document authors have been discussing updates to the documents and
> plan to do work on this in the first half of February.  No-one has had ti=
me
> to properly respond to the comments yet due to other commitments.
>
> Regards,
>
> Peter
>
>
> On 29 January 2014 12:45, Mary Barnes  wrote:
>
>> Peter et al,
>>
>> This thread of discussion gets back to one of the points I made in my
>> shepherd review of the document (note that I don't think there's been an=
y
>> responses from the authors on any of my comments):
>> http://www.ietf.org/mail-archive/web/dispatch/current/msg05173.html
>>
>> If TLS is a SHOULD then you need to clearly explain the context in which
>> one might not use TLS and what the implications and risks are.  There ar=
e
>> still security risks (e.g., malicious actors) in internal networks.
>>
>> Regards,
>> Mary.
>>
>>
>> On Wed, Jan 29, 2014 at 11:30 AM, Peter Dunkley <
>> peter.dunkley@crocodilertc.net> wrote:
>>
>>>
>>> On 29 January 2014 12:22, I=F1aki Baz Castillo  wrote:
>>>
>>>> Hi, let me please tell something about WebSocket and TLS (so URIs with
>>>> scheme "wss://"):
>>>>
>>>> 1) Firefox and latest version of Chrome do NOT allow insecure
>>>> (non-TLS) WebSocket connections if the web page has "https" schema.
>>>>
>>>> 2) When the web page is "https", Firefox and Chrome do NOT allow
>>>> WebSocket secure connections ("wss") if the WebSocket server
>>>> certificate is not valid (expired, auto-signed...). I mean: the
>>>> browser does not even prompt for permissions to the user, it just
>>>> fails the WSS connection.
>>>>
>>>>
>>>>
>>>> Point 1) is terribly important IMHO. Note that for WebRTC applications
>>>> to be "friendly" HTTPS is required (so the user is not prompted by the
>>>> browser for permission every time a WebRTC session is requested via
>>>> getUserMedia). So let's assume that WebRTC, in fact, requires HTTPS.
>>>> Taking into account point 1) above, we also need Secure WebSocket
>>>> ("wss") for MSRP or for anything.
>>>>
>>>>
>>> Which is great on the Internet but a real pain on an internal network
>>> where you don't want to pay for a certificate or import something into
>>> every single device/computer on your network.  That's the same reason
>>> people usually don't use HTTPS on internal networks!
>>>
>>> Hence my belief that SHOULD was the right thing here.  People SHOULD us=
e
>>> TLS security, but saying MUST will just mean that this is a MUST people
>>> ignore on certain deployment types.  What is the point of mandating
>>> something when people will just ignore it when it doesn't suit them?
>>>
>>
>>> I get that security is important and the IETF is full of security
>>> idealists, and all IETF protocols should be secure, by in this particul=
ar
>>> situation it feels like using MUST instead of SHOULD would be done simp=
ly
>>> because in the IETF you always say MUST for security (whether people wi=
ll
>>> use it or not).
>>>
>> [MB] That's not true. But, what is true is that anytime you have a SHOUL=
D
>> do x, you need to explain the situations in which you wouldn't do x and =
any
>> implications and risks associated with not doing x.  [/MB]
>>
>>>
>>> Regards,
>>>
>>> Peter
>>>
>>> --
>>> Peter Dunkley
>>> Technical Director
>>> Crocodile RCS Ltd
>>>
>>> _______________________________________________
>>> dispatch mailing list
>>> dispatch@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dispatch
>>>
>>>
>>
>
>
> --
> Peter Dunkley
> Technical Director
> Crocodile RCS Ltd
>

--089e013cbd501bed2504f11fb5b3
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


Peter,

Thanks for the update. =A0
=


Mary.


On Wed, Jan 29, 2014 at 11:48 AM, Peter Dunkley <peter.dunkley@crocodilertc.net> wrote:


Hello Mary,

<=
div>The document authors have been discussing updates to the documents and =
plan to do work on this in the first half of February. =A0No-one has had ti=
me to properly respond to the comments yet due to other commitments.




Regards,

Peter


On 29 January 2014 12:45, Mary Barnes <mar=
y.ietf.barnes@gmail.com> wrote:



Peter et al,

=

This thread of discussion gets back to one of the points I made in my =
shepherd review of the document (note that I don't think there's be=
en any responses from the authors on any of my comments):=A0





If TLS is a SHOULD th=
en you need to clearly explain the context in which one might not use TLS a=
nd what the implications and risks are. =A0There are still security risks (=
e.g., malicious actors) in internal networks.





Regards,
Mary.


On Wed, Jan 29, 2014 at=
 11:30 AM, Peter Dunkley <peter.dunkley@crocodilertc.net&=
gt; wrote:




=

On 29 January 2014 12:22, I=F1aki Baz C=
astillo <ibc@aliax.net> wrote:





Hi, let me please tell something about WebSocket and TLS (so URIs with

scheme "wss://"):



1) Firefox and latest version of Chrome do NOT allow insecure

(non-TLS) WebSocket connections if the web page has "https" schem=
a.



2) When the web page is "https", Firefox and Chrome do NOT allow<=
br>
WebSocket secure connections ("wss") if the WebSocket server

certificate is not valid (expired, auto-signed...). I mean: the

browser does not even prompt for permissions to the user, it just

fails the WSS connection.







Point 1) is terribly important IMHO. Note that for WebRTC applications

to be "friendly" HTTPS is required (so the user is not prompted b=
y the

browser for permission every time a WebRTC session is requested via

getUserMedia). So let's assume that WebRTC, in fact, requires HTTPS.
Taking into account point 1) above, we also need Secure WebSocket

("wss") for MSRP or for anything.




Which is g=
reat on the Internet but a real pain on an internal network where you don&#=
39;t want to pay for a certificate or import something into every single de=
vice/computer on your network. =A0That's the same reason people usually=
 don't use HTTPS on internal networks!






Hence my belief that SHOULD was the right thing here. =
=A0People SHOULD use TLS security, but saying MUST will just mean that this=
 is a MUST people ignore on certain deployment types. =A0What is the point =
of mandating something when people will just ignore it when it doesn't =
suit them?







I get that security is important and the IETF is full o=
f security idealists, and all IETF protocols should be secure, by in this p=
articular situation it feels like using MUST instead of SHOULD would be don=
e simply because in the IETF you always say MUST for security (whether peop=
le will use it or not).




[MB] That's not true. B=
ut, what is true is that anytime you have a SHOULD do x, you need to explai=
n the situations in which you wouldn't do x and any implications and ri=
sks associated with not doing x. =A0[/MB]=A0







Regards,

Peter
=A0
-- 
Peter Dunkley
Technical Director





Crocodile RCS Ltd




_______________________________________________

dispatch mailing list

dispatch@ietf.org

https://www.ietf.org/mailman/listinfo/dispatch








-- 
Peter Dunkley
<=
div>Technical Director


Crocodile RCS Ltd





--089e013cbd501bed2504f11fb5b3--

From fluffy@cisco.com  Wed Jan 29 10:11:14 2014
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 EBC801A0276; Wed, 29 Jan 2014 10:11:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.036
X-Spam-Level: 
X-Spam-Status: No, score=-110.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] 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 ASjRTOwn7Ugw; Wed, 29 Jan 2014 10:11:07 -0800 (PST)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) by ietfa.amsl.com (Postfix) with ESMTP id 340611A0230; Wed, 29 Jan 2014 10:11:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=364; q=dns/txt; s=iport; t=1391019064; x=1392228664; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=znZZdn5nYCnFtuKIQQEb1G4HLHzgXo6ivL+4LSpU/rI=; b=LWxtYUcbYmEiuuL479Q6yGBG7RzVtFE0o99JFktna2UasvTwGZ+YT/Xt uMEqZtj0gwrZSqM0EC9/t6hRaQsZpGlB9gKD0ZWIX8nrho/PSbeAWRF69 fj7W6KFXKtbsHSnElyw7ngd1+XdMlw/jgrhAyTqoJihxe9pEqH95Wr9Nj 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgsFAMhD6VKtJXHA/2dsb2JhbABZgwyBDr0CgQcWdIIlAQEBAwFrDgULAgEIRjIlAgQOBYd9CMoZF45MMweDJIEUAQOJEY8Xkh+DLYIq
X-IronPort-AV: E=Sophos;i="4.95,743,1384300800"; d="scan'208";a="16448176"
Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by alln-iport-1.cisco.com with ESMTP; 29 Jan 2014 18:11:04 +0000
Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id s0TIB3MK020934 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 29 Jan 2014 18:11:03 GMT
Received: from xmb-aln-x02.cisco.com ([169.254.5.76]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0123.003; Wed, 29 Jan 2014 12:11:03 -0600
From: "Cullen Jennings (fluffy)" 
To: Peter Dunkley 
Thread-Topic: [dispatch] [RAI] MSRP Expert Review of draft-pd-dispatch-msrp-websocket-04
Thread-Index: AQHPHREvsOjdfxbdLEen8YpQET53pZqcVjsAgAAPJQA=
Date: Wed, 29 Jan 2014 18:11:02 +0000
Message-ID: <1E320318-64CE-4F8B-AB76-8C4A5244379A@cisco.com>
References: <45B84D8F-AD8C-4B28-90DF-9B1C40771104@nostrum.com> <6833E320-7B45-4FC2-853B-62311DCF7E7B@nostrum.com>   
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.20.249.164]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <3DEE942E99616D4EBDB89B904ADC02E4@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: DISPATCH , "rai@ietf.org" , "draft-pd-dispatch-msrp-websocket.all@tools.ietf.org" , Ben Campbell 
Subject: Re: [dispatch] [RAI] MSRP Expert Review of draft-pd-dispatch-msrp-websocket-04
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, 29 Jan 2014 18:11:15 -0000

On Jan 29, 2014, at 10:16 AM, Peter Dunkley  wrote:

> Even if TLS is left as MUST all of the additional checks from the RFC can=
not be enforced on the client because (in a browser) you don't have any acc=
ess to that information.

So help educate me on what is missing and lets go get that fixed in web soc=
kets.=20



From fluffy@cisco.com  Wed Jan 29 10:14:46 2014
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 31E921A01E8 for ; Wed, 29 Jan 2014 10:14:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -115.036
X-Spam-Level: 
X-Spam-Status: No, score=-115.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] 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 Gle4B7TgUOrw for ; Wed, 29 Jan 2014 10:14:45 -0800 (PST)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 0B42A1A0146 for ; Wed, 29 Jan 2014 10:14:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=338; q=dns/txt; s=iport; t=1391019282; x=1392228882; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=3pCxFnZpq89GFrxrh8N2BEDUrdscmQBU8BhtK18VtAE=; b=DdExv4rskdlpZKshbnNFDnU+czrBFhWjPAJKKX6Na5jF71HO6RRwV8NL DYGUO1HpsG5v1OtmCNXm+mzYvC2AK68wHGHhlcX27j6yZwT/FPOv0I6hv Sm7xZQ0i2zfevQwdxY+Io2pfnr0hm91+RKLnV+QeAvUcKUS1if9K+wySa 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgsFAAVE6VKtJV2b/2dsb2JhbABZgwyBDr0CgQcWdIIlAQEBAwF5BQsCAQhGMiUCBA4Fh30IyhkXjkwzB4MkgRQBA5gokh+DLYIq
X-IronPort-AV: E=Sophos;i="4.95,743,1384300800"; d="scan'208";a="300334774"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-1.cisco.com with ESMTP; 29 Jan 2014 18:14:42 +0000
Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s0TIEfEn027070 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 29 Jan 2014 18:14:42 GMT
Received: from xmb-aln-x02.cisco.com ([169.254.5.76]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0123.003; Wed, 29 Jan 2014 12:14:41 -0600
From: "Cullen Jennings (fluffy)" 
To: Christer Holmberg 
Thread-Topic: [dispatch] I-D Action: draft-pd-dispatch-msrp-websocket-03.txt
Thread-Index: AQHPHR36q4iEVsMDPU+hfaDrdTWktQ==
Date: Wed, 29 Jan 2014 18:14:41 +0000
Message-ID: <226E40DB-7453-4B4F-B46C-25A152A79BD3@cisco.com>
References: <20131213005747.777.34301.idtracker@ietfa.amsl.com>  <7594FB04B1934943A5C02806D1A2204B1D104D91@ESESSMB209.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D104D91@ESESSMB209.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.20.249.164]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <64B32393AE296740B2BC39C7EC8CF9C9@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: DISPATCH , Ben Campbell , "draft-pd-dispatch-msrp-websocket@tools.ietf.org" 
Subject: Re: [dispatch] I-D Action: draft-pd-dispatch-msrp-websocket-03.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: Wed, 29 Jan 2014 18:14:46 -0000

On Jan 18, 2014, at 1:52 AM, Christer Holmberg  wrote:

> While I do understand that a WS Client has to establish the WebSocket wit=
h the Web Server, I don=92t understand why we need to mandate the WS Server=
 to be an MSRP Relay.=20

Any comments on Christer=92s original question here ? =20



From ben@nostrum.com  Wed Jan 29 10:17:13 2014
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 1A0FD1A0369; Wed, 29 Jan 2014 10:17:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.036
X-Spam-Level: 
X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] 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 U7m32hf_igpH; Wed, 29 Jan 2014 10:17:12 -0800 (PST)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id E9C291A021B; Wed, 29 Jan 2014 10:17:11 -0800 (PST)
Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id s0TIGseM008270 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 29 Jan 2014 12:16:55 -0600 (CST) (envelope-from ben@nostrum.com)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Ben Campbell 
In-Reply-To: 
Date: Wed, 29 Jan 2014 12:16:53 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <45B84D8F-AD8C-4B28-90DF-9B1C40771104@nostrum.com> <6833E320-7B45-4FC2-853B-62311DCF7E7B@nostrum.com>   <009E92F4-DCA2-40A4-8E7A-EF6EB1BB8C06@nostrum.com>  
To: Peter Dunkley 
X-Mailer: Apple Mail (2.1827)
Received-SPF: pass (shaman.nostrum.com: 173.172.146.58 is authenticated by a trusted mechanism)
Cc: Cullen Jennings , DISPATCH , "rai@ietf.org" , "draft-pd-dispatch-msrp-websocket.all@tools.ietf.org" 
Subject: Re: [dispatch] [RAI] MSRP Expert Review of draft-pd-dispatch-msrp-websocket-04
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, 29 Jan 2014 18:17:13 -0000

On Jan 29, 2014, at 11:30 AM, Peter Dunkley =
 wrote:

> Point 1) is terribly important IMHO. Note that for WebRTC applications
> to be "friendly" HTTPS is required (so the user is not prompted by the
> browser for permission every time a WebRTC session is requested via
> getUserMedia). So let's assume that WebRTC, in fact, requires HTTPS.
> Taking into account point 1) above, we also need Secure WebSocket
> ("wss") for MSRP or for anything.
>=20
>=20
> Which is great on the Internet but a real pain on an internal network =
where you don't want to pay for a certificate or import something into =
every single device/computer on your network.  That's the same reason =
people usually don't use HTTPS on internal networks!

I assumed MSRP/WebSocket was intended for the Internet. If not, perhaps =
an applicability statement would be in order, even if just for this =
particular requirement--although I tend to be skeptical of or "MUST use =
unless you are on a private network" constructs. But I can see =
situations where, for example, you've got protection at a lower layer =
(e.g. IPSec, VPNs, etc.) where it might make sense.

(BTW, more and more enterprise networks are moving to use HTTPS =
internally.)

>=20
> Hence my belief that SHOULD was the right thing here.  People SHOULD =
use TLS security, but saying MUST will just mean that this is a MUST =
people ignore on certain deployment types.  What is the point of =
mandating something when people will just ignore it when it doesn't suit =
them?
>=20
> I get that security is important and the IETF is full of security =
idealists, and all IETF protocols should be secure, by in this =
particular situation it feels like using MUST instead of SHOULD would be =
done simply because in the IETF you always say MUST for security =
(whether people will use it or not).

Actually, not so many IETF protocols say "MUST use". "MUST implement" is =
more common. But MSRP was an attempt to move to a more secure model, so =
the authors are going to be sensitive to anything that reduces that. And =
I suspect you will see more "MUST use" requirements these days than you =
might have this time last year.

Again, I think we should consider a wider policy on how to apply =
application protocol security requirements when the application moves to =
WebSocket. MSRP is an interesting test case due to the "MUST use" =
requirement.

>=20


From ibc@aliax.net  Wed Jan 29 10:18:04 2014
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 7349F1A0383 for ; Wed, 29 Jan 2014 10:18:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.678
X-Spam-Level: 
X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] 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 ZgOzww0pMNww for ; Wed, 29 Jan 2014 10:18:03 -0800 (PST)
Received: from mail-qc0-f173.google.com (mail-qc0-f173.google.com [209.85.216.173]) by ietfa.amsl.com (Postfix) with ESMTP id 7C7CA1A02C0 for ; Wed, 29 Jan 2014 10:18:03 -0800 (PST)
Received: by mail-qc0-f173.google.com with SMTP id i8so3295770qcq.18 for ; Wed, 29 Jan 2014 10:18:00 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=yM3WkQMU0vXGa3i1TqYbNWLQiHyKFdyoBrmYr/2OO+8=; b=I7mE1do4F2Cs06/P0Qu3J8/VvpF49p2n+BgnDc0CxNUCPZStFS6VHp7feUDgcgQlz6 G7J/e7dYcY0V3a7aTZbe4NFUxkGPxtZeo8xg1dYnhv1J3+s//15Ze+ouq+v+/j90L3x9 gwwdRQSZ3bM33kJImWbGPNKR2SvVh7BOOlRKnEcBNMt23wlLLVjebD0Dlg0I4FkXLQaZ il6JX7HOL54FZOzZeXq3zzk5sHmTp25dmj5YdfOSrcmPMOnb0pPGjlaht/n6nfh1S2tS EytKjvC3RiX+iIvUk6x6EnZ9HNiPu/xC8AyUwk7/0ToPB/JriwTFc59y3anmTLkesdZa 59BA==
X-Gm-Message-State: ALoCoQl0Xg7whhQVHKCtv19OZ5A/upakV62A1cXJniSav9lckMS1ipSsjstpkE8ewij/3ItpwhEn
X-Received: by 10.140.96.17 with SMTP id j17mr13933965qge.112.1391019480390; Wed, 29 Jan 2014 10:18:00 -0800 (PST)
MIME-Version: 1.0
Received: by 10.96.101.232 with HTTP; Wed, 29 Jan 2014 10:17:40 -0800 (PST)
In-Reply-To: <1E320318-64CE-4F8B-AB76-8C4A5244379A@cisco.com>
References: <45B84D8F-AD8C-4B28-90DF-9B1C40771104@nostrum.com> <6833E320-7B45-4FC2-853B-62311DCF7E7B@nostrum.com>    <1E320318-64CE-4F8B-AB76-8C4A5244379A@cisco.com>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
Date: Wed, 29 Jan 2014 19:17:40 +0100
Message-ID: 
To: "Cullen Jennings (fluffy)" 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: Ben Campbell , DISPATCH , "rai@ietf.org" , "draft-pd-dispatch-msrp-websocket.all@tools.ietf.org" 
Subject: Re: [dispatch] [RAI] MSRP Expert Review of draft-pd-dispatch-msrp-websocket-04
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, 29 Jan 2014 18:18:04 -0000

2014-01-29 Cullen Jennings (fluffy) :
> On Jan 29, 2014, at 10:16 AM, Peter Dunkley  wrote:
>
>> Even if TLS is left as MUST all of the additional checks from the RFC ca=
nnot be enforced on the client because (in a browser) you don't have any ac=
cess to that information.
>
> So help educate me on what is missing and lets go get that fixed in web s=
ockets.


The browser inspects the certificate retrieved from the WS server in
the same way than when the browser connects to a HTTPS site. And the
certificate inspection means matching the server domain with the CN or
SubjectAltNames fields (DNS entries) and others usual checks.

--=20
I=C3=B1aki Baz Castillo


From fluffy@cisco.com  Wed Jan 29 10:29:37 2014
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 D2C841A021B; Wed, 29 Jan 2014 10:29:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -114.736
X-Spam-Level: 
X-Spam-Status: No, score=-114.736 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] 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 TGvWp-2BAfy1; Wed, 29 Jan 2014 10:29:35 -0800 (PST)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id BFBDC1A0216; Wed, 29 Jan 2014 10:29:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=863; q=dns/txt; s=iport; t=1391020173; x=1392229773; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=wfbvWIy6LIWcK390smWjhX6GnlPpdkeP+RIkgaWzR1s=; b=VpsAYrLHmKXWqJj/x7TTVTPdZ0J+PchFJwsr5tzoYhY1fKoGtZniNN4i GbsL3bAvqZAoYxwN8Ekv4doF3zPBWxFslfC1dsxyuZpJmtfI3GrKV7Xrp 3b9yN+cDRDqnN1juVZb671RsN72rdd2M26P/HkC4V4XDeV283oown9ook 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgwFAO1H6VKtJV2c/2dsb2JhbABZgww4Vr0EgQcWdIIlAQEBAwFrDgULAgEIGC4yJQIEDgWHfQjKIReOTDMHgySBFAEDiRGPF5Ifgy2CKg
X-IronPort-AV: E=Sophos;i="4.95,743,1384300800"; d="scan'208";a="297531414"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-9.cisco.com with ESMTP; 29 Jan 2014 18:29:32 +0000
Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s0TITWP5010877 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 29 Jan 2014 18:29:32 GMT
Received: from xmb-aln-x02.cisco.com ([169.254.5.76]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0123.003; Wed, 29 Jan 2014 12:29:32 -0600
From: "Cullen Jennings (fluffy)" 
To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= 
Thread-Topic: [dispatch] [RAI] MSRP Expert Review of draft-pd-dispatch-msrp-websocket-04
Thread-Index: AQHPHREvsOjdfxbdLEen8YpQET53pZqcVjsA//+si3iAAGfDAA==
Date: Wed, 29 Jan 2014 18:29:31 +0000
Message-ID: <8DB45325-9CCA-411C-A809-9B716616CE2F@cisco.com>
References: <45B84D8F-AD8C-4B28-90DF-9B1C40771104@nostrum.com> <6833E320-7B45-4FC2-853B-62311DCF7E7B@nostrum.com>    <1E320318-64CE-4F8B-AB76-8C4A5244379A@cisco.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.20.249.164]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <41D1DF5C5855CC48BA9A6B152025B4A0@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: Ben Campbell , DISPATCH , "rai@ietf.org" , "draft-pd-dispatch-msrp-websocket.all@tools.ietf.org" 
Subject: Re: [dispatch] [RAI] MSRP Expert Review of draft-pd-dispatch-msrp-websocket-04
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, 29 Jan 2014 18:29:38 -0000

On Jan 29, 2014, at 11:17 AM, I=F1aki Baz Castillo  wrote:

> 2014-01-29 Cullen Jennings (fluffy) :
>> On Jan 29, 2014, at 10:16 AM, Peter Dunkley  wrote:
>>=20
>>> Even if TLS is left as MUST all of the additional checks from the RFC c=
annot be enforced on the client because (in a browser) you don't have any a=
ccess to that information.
>>=20
>> So help educate me on what is missing and lets go get that fixed in web =
sockets.
>=20
>=20
> The browser inspects the certificate retrieved from the WS server in
> the same way than when the browser connects to a HTTPS site. And the
> certificate inspection means matching the server domain with the CN or
> SubjectAltNames fields (DNS entries) and others usual checks.


Right - that sounds good - so what is missing ?



From peter.dunkley@crocodilertc.net  Wed Jan 29 11:18:31 2014
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 393C41A0363 for ; Wed, 29 Jan 2014 11:18:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level: 
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=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 lAkAfrBqczBk for ; Wed, 29 Jan 2014 11:18:29 -0800 (PST)
Received: from mail-ve0-x233.google.com (mail-ve0-x233.google.com [IPv6:2607:f8b0:400c:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 49AF61A0240 for ; Wed, 29 Jan 2014 11:18:29 -0800 (PST)
Received: by mail-ve0-f179.google.com with SMTP id jx11so1483307veb.24 for ; Wed, 29 Jan 2014 11:18:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=crocodilertc.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=oL+LcaATe1r4tMtkQHz7HNyL21eQXTyahbUkBVjft8U=; b=J1R95hepdawydt3JwHgNr+bNizvtQWACbBjI6DpTuWMABsZcKYuZE2cLKqrhZ5+Rai jJFi7UpE6mnDj2SxLHQLjIajNV/zVbSY+ohrxmXMK8cGsGWREQmwlei6sOClwrZamiRl 1sARxCix5fnwCODkHvnkOgn3SZmNYJvXJIkzc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=oL+LcaATe1r4tMtkQHz7HNyL21eQXTyahbUkBVjft8U=; b=khCwV1YtaUcIkm9xxFH9kxkNw8iOG/xHk4nEyKbx2t6D3f76ZrfyCIyIQ/DMXpCy4U LC3JDbfLAN7tTrGaGnMmhVVyv23otwsRafJjlDIlp/gJ2iHRbT5KovLW55orULGyexO1 qfvQAuibsrPf2pnsbCdRyo7V7Bv7VmubeeMlbh8ixk7lgql+79zDbfJKgvChtPPBO4ee 1+4a+srBui1ZU5anp+Leq9bbgl25WvFz1ZXL6FIouIJwmdOWq04geU/Qr2QQySS4k5WU pNrPZg1IpcdkgRASiHOzftvuXNFH9U19PVFtkPtxiZ00lI/sOUrXOSAAPxui1r3nHNm2 4vVw==
X-Gm-Message-State: ALoCoQllyP9hWySMyXyfpFzUO3KvZLnnp5RevIMPSHCpiZay+7EHFzgwy1VqCDXrxRSx/SrxDmlK
MIME-Version: 1.0
X-Received: by 10.221.39.138 with SMTP id tm10mr8059485vcb.7.1391023106057; Wed, 29 Jan 2014 11:18:26 -0800 (PST)
Received: by 10.58.187.114 with HTTP; Wed, 29 Jan 2014 11:18:25 -0800 (PST)
In-Reply-To: <8DB45325-9CCA-411C-A809-9B716616CE2F@cisco.com>
References: <45B84D8F-AD8C-4B28-90DF-9B1C40771104@nostrum.com> <6833E320-7B45-4FC2-853B-62311DCF7E7B@nostrum.com>    <1E320318-64CE-4F8B-AB76-8C4A5244379A@cisco.com>  <8DB45325-9CCA-411C-A809-9B716616CE2F@cisco.com>
Date: Wed, 29 Jan 2014 14:18:25 -0500
Message-ID: 
From: Peter Dunkley 
To: "Cullen Jennings (fluffy)" 
Content-Type: multipart/alternative; boundary=001a1133953a1c7fcf04f120ce55
Cc: DISPATCH , "rai@ietf.org" , "draft-pd-dispatch-msrp-websocket.all@tools.ietf.org" , Ben Campbell 
Subject: Re: [dispatch] [RAI] MSRP Expert Review of draft-pd-dispatch-msrp-websocket-04
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, 29 Jan 2014 19:18:31 -0000

--001a1133953a1c7fcf04f120ce55
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

It's really just that using self-signed certificates in a browser is a real
pain.

If you have a good signed certificate it all works out.  On an internal
system many organisations don't buy certificates for internal use, people
are used to making exceptions, seeing warnings, etc.  But right now today
if your certificate is self signed and you haven't imported the right stuff
into each device that might try and make the secure WebSocket connection,
the certificate validation will fail and the connection won't be made.

I do get the argument that people and organisations SHOULD be more secure.
 Telling them they MUST be more secure tends not to work.  I am happy to
change the document to say MUST, but it comes back to the point that doing
this would be because MUST is what we put in these documents rather than
expecting people to actually do that in all situations.




On 29 January 2014 13:29, Cullen Jennings (fluffy)  wrote=
:

>
> On Jan 29, 2014, at 11:17 AM, I=F1aki Baz Castillo  wrote:
>
> > 2014-01-29 Cullen Jennings (fluffy) :
> >> On Jan 29, 2014, at 10:16 AM, Peter Dunkley <
> peter.dunkley@crocodilertc.net> wrote:
> >>
> >>> Even if TLS is left as MUST all of the additional checks from the RFC
> cannot be enforced on the client because (in a browser) you don't have an=
y
> access to that information.
> >>
> >> So help educate me on what is missing and lets go get that fixed in we=
b
> sockets.
> >
> >
> > The browser inspects the certificate retrieved from the WS server in
> > the same way than when the browser connects to a HTTPS site. And the
> > certificate inspection means matching the server domain with the CN or
> > SubjectAltNames fields (DNS entries) and others usual checks.
>
>
> Right - that sounds good - so what is missing ?
>
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>



--=20
Peter Dunkley
Technical Director
Crocodile RCS Ltd

--001a1133953a1c7fcf04f120ce55
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


It's really just that using self-signed certificates i=
n a browser is a real pain.

If you have a good signed ce=
rtificate it all works out. =A0On an internal system many organisations don=
't buy certificates for internal use, people are used to making excepti=
ons, seeing warnings, etc. =A0But right now today if your certificate is se=
lf signed and you haven't imported the right stuff into each device tha=
t might try and make the secure WebSocket connection, the certificate valid=
ation will fail and the connection won't be made.



I do get the argument that people and organisations SHO=
ULD be more secure. =A0Telling them they MUST be more secure tends not to w=
ork. =A0I am happy to change the document to say MUST, but it comes back to=
 the point that doing this would be because MUST is what we put in these do=
cuments rather than expecting people to actually do that in all situations.=







On 29 January 2014 13:29, Cullen Jennings (fluffy) <=
span dir=3D"ltr"><=
fluffy@cisco.com> wrote:




On Jan 29, 2014, at 11:17 AM, I=F1aki Baz Castillo <ibc@aliax.net> wrote:



> 2014-01-29 Cullen Jennings (fluffy) <fluffy@cisco.com>:

>> On Jan 29, 2014, at 10:16 AM, Peter Dunkley <peter.dunkley@crocodilertc.net> wrot=
e:

>>

>>> Even if TLS is left as MUST all of the additional checks from =
the RFC cannot be enforced on the client because (in a browser) you don'=
;t have any access to that information.

>>

>> So help educate me on what is missing and lets go get that fixed i=
n web sockets.

>

>

> The browser inspects the certificate retrieved from the WS server in
> the same way than when the browser connects to a HTTPS site. And the
> certificate inspection means matching the server domain with the CN or=


> SubjectAltNames fields (DNS entries) and others usual checks.






Right - that sounds good - so what is missing ?






_______________________________________________

dispatch mailing list

dispatch@ietf.org

https://www.ietf.org/mailman/listinfo/dispatch





-- 
=

Peter Dunkley
Technical Director


Crocodile RCS Ltd




--001a1133953a1c7fcf04f120ce55--

From fluffy@cisco.com  Wed Jan 29 11:24:37 2014
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 D4B011A03E9; Wed, 29 Jan 2014 11:24:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.036
X-Spam-Level: 
X-Spam-Status: No, score=-110.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] 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 QE6YwV5Cpaeh; Wed, 29 Jan 2014 11:24:35 -0800 (PST)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) by ietfa.amsl.com (Postfix) with ESMTP id B37D01A0346; Wed, 29 Jan 2014 11:24:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2936; q=dns/txt; s=iport; t=1391023473; x=1392233073; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=6nVPrq+XYjWE3NgaJ+7wmhRqqmOYA9AyXXGHlXWNowQ=; b=bgCwXc0Sa5wRHNfQ2Z3tYmG5u51u+zEP8hSM0vPRlFoFkJVfhs9KvHRe 8yBQZy32ihpfJbWuXyEzw8pZ+PmPh/D3ABIVy7NbVpmsymIQardDcRbyd yaYXdGqo46r/tV9xvqqLc3oPVGBLr5lyi6f4z9kli/VQ05yedlgive9De c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ag0FACxU6VKtJXHA/2dsb2JhbABZgww4Vrw5T4EHFnSCJQEBAQMBAQEBaAMLBQsCAQgYLicLJQIEDgWHfQgNyX8TBI5MMweDJIEUBJgokh+DLYFqJBw
X-IronPort-AV: E=Sophos;i="4.95,743,1384300800"; d="scan'208";a="16471525"
Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by alln-iport-1.cisco.com with ESMTP; 29 Jan 2014 19:24:32 +0000
Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id s0TJOUMw004617 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 29 Jan 2014 19:24:30 GMT
Received: from xmb-aln-x02.cisco.com ([169.254.5.76]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0123.003; Wed, 29 Jan 2014 13:24:29 -0600
From: "Cullen Jennings (fluffy)" 
To: Peter Dunkley 
Thread-Topic: [dispatch] [RAI] MSRP Expert Review of draft-pd-dispatch-msrp-websocket-04
Thread-Index: AQHPHSbhsOjdfxbdLEen8YpQET53pZqcebkA
Date: Wed, 29 Jan 2014 19:24:29 +0000
Message-ID: 
References: <45B84D8F-AD8C-4B28-90DF-9B1C40771104@nostrum.com> <6833E320-7B45-4FC2-853B-62311DCF7E7B@nostrum.com>    <1E320318-64CE-4F8B-AB76-8C4A5244379A@cisco.com>  <8DB45325-9CCA-411C-A809-9B716616CE2F@cisco.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.20.249.164]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <20F656351E498247BA9A9B38B573002F@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: DISPATCH , "rai@ietf.org" , "draft-pd-dispatch-msrp-websocket.all@tools.ietf.org" , Ben Campbell 
Subject: Re: [dispatch] [RAI] MSRP Expert Review of draft-pd-dispatch-msrp-websocket-04
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, 29 Jan 2014 19:24:38 -0000

Sure I understand. But understand that MSRP has a really bad downgrade atta=
ck if you allow self signed certs. So if you want to change MSRP so it is c=
an self signed certs for the relay, then I suggest writing a draft to do ma=
te that change to MSRP that is separate from the Websockets draft because t=
his is an orthogonal issue to the web sockets.=20

For people that don=92t want to have to get a signed certificate, I=92d sug=
gest trying to look at how to design the system to not need MSRP relays. Th=
ere is a long list of ways in which MSRP relays are a huge PITA. I wish we =
had never added them and instead had just used TURN, or SOCKS.=20


On Jan 29, 2014, at 12:18 PM, Peter Dunkley  wrote:

> It's really just that using self-signed certificates in a browser is a re=
al pain.
>=20
> If you have a good signed certificate it all works out.  On an internal s=
ystem many organisations don't buy certificates for internal use, people ar=
e used to making exceptions, seeing warnings, etc.  But right now today if =
your certificate is self signed and you haven't imported the right stuff in=
to each device that might try and make the secure WebSocket connection, the=
 certificate validation will fail and the connection won't be made.
>=20
> I do get the argument that people and organisations SHOULD be more secure=
.  Telling them they MUST be more secure tends not to work.  I am happy to =
change the document to say MUST, but it comes back to the point that doing =
this would be because MUST is what we put in these documents rather than ex=
pecting people to actually do that in all situations.
>=20
>=20
>=20
>=20
> On 29 January 2014 13:29, Cullen Jennings (fluffy)  wro=
te:
>=20
> On Jan 29, 2014, at 11:17 AM, I=F1aki Baz Castillo  wrote:
>=20
> > 2014-01-29 Cullen Jennings (fluffy) :
> >> On Jan 29, 2014, at 10:16 AM, Peter Dunkley  wrote:
> >>
> >>> Even if TLS is left as MUST all of the additional checks from the RFC=
 cannot be enforced on the client because (in a browser) you don't have any=
 access to that information.
> >>
> >> So help educate me on what is missing and lets go get that fixed in we=
b sockets.
> >
> >
> > The browser inspects the certificate retrieved from the WS server in
> > the same way than when the browser connects to a HTTPS site. And the
> > certificate inspection means matching the server domain with the CN or
> > SubjectAltNames fields (DNS entries) and others usual checks.
>=20
>=20
> Right - that sounds good - so what is missing ?
>=20
>=20
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>=20
>=20
>=20
> --=20
> Peter Dunkley
> Technical Director
> Crocodile RCS Ltd


From peter.dunkley@crocodilertc.net  Wed Jan 29 11:28:19 2014
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 4431C1A0361 for ; Wed, 29 Jan 2014 11:28:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level: 
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=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 OH6tigIL97bo for ; Wed, 29 Jan 2014 11:28:16 -0800 (PST)
Received: from mail-vb0-x22e.google.com (mail-vb0-x22e.google.com [IPv6:2607:f8b0:400c:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 370411A03C5 for ; Wed, 29 Jan 2014 11:28:16 -0800 (PST)
Received: by mail-vb0-f46.google.com with SMTP id o19so1419829vbm.5 for ; Wed, 29 Jan 2014 11:28:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=crocodilertc.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qXxNGsolaMuQTZdqf6LWaVCiqYWO8H4AJv3ztAGNqGQ=; b=cAjuLJKrOjEh7tMGo0KNHCxcS71XvqaOE1B0OjHZUCeSgYhO1922/uFWi5BBO6tPYy 7bTc9apHI89Ei4wZwsDq6hE1PtxK1mhrgroWtigYI4PnZT0nZJU3r57drTIPSb8uEM3O 58cs0AtqZbSEagfP0OlvIvq1X45HvN646SpSc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=qXxNGsolaMuQTZdqf6LWaVCiqYWO8H4AJv3ztAGNqGQ=; b=IYctWwZUup+X0zWRpEyt5Vdxg1RNppZnla9Qrw/LDRTM7ilKbrLtLjzbfftLtaoVnO IIyDf8pokrWV3SRzrviekXQax4ckkSCszsouZOxl02CZ0scxU/Q6gk2x8nsKUYCMMVDt NdpmlwvkCA7LwrJDniAsyeQ6m8waobXZmEq1oFSxCtfbDK2jhuC8FjQ3f6OG/yipLufU BPKOtVlo9SDaAyUUK7BZ0nHd+yHIWp0acTPjR0geeOFGZ4yLrg3KX799eM1OZRLM58wu ZqyYIVIuzx1tGAhaHCKYtG0ICM1mjw/dj5U0scOmRLMnaXkOkQuvGzMQOtTLBi/8ZPmh MqXg==
X-Gm-Message-State: ALoCoQliDF50wkedeDT0upVowJoB+4Yf64ORaYa6OudnswHTzfYuaWXvgR2QP6e9jhHNaiL8+7vj
MIME-Version: 1.0
X-Received: by 10.58.188.78 with SMTP id fy14mr2929177vec.23.1391023693012; Wed, 29 Jan 2014 11:28:13 -0800 (PST)
Received: by 10.58.187.114 with HTTP; Wed, 29 Jan 2014 11:28:12 -0800 (PST)
In-Reply-To: 
References: <45B84D8F-AD8C-4B28-90DF-9B1C40771104@nostrum.com> <6833E320-7B45-4FC2-853B-62311DCF7E7B@nostrum.com>    <1E320318-64CE-4F8B-AB76-8C4A5244379A@cisco.com>  <8DB45325-9CCA-411C-A809-9B716616CE2F@cisco.com>  
Date: Wed, 29 Jan 2014 14:28:12 -0500
Message-ID: 
From: Peter Dunkley 
To: "Cullen Jennings (fluffy)" 
Content-Type: multipart/alternative; boundary=089e013a12f018c40d04f120f1fd
Cc: DISPATCH , "rai@ietf.org" , "draft-pd-dispatch-msrp-websocket.all@tools.ietf.org" , Ben Campbell 
Subject: Re: [dispatch] [RAI] MSRP Expert Review of draft-pd-dispatch-msrp-websocket-04
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, 29 Jan 2014 19:28:19 -0000

--089e013a12f018c40d04f120f1fd
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

The intention here was to downgrade the security requirement for just MSRP
over WebSockets (still leaving it as a SHOULD) and not to change the
requirements for the existing MSRP relay specification.

Regards,

Peter


On 29 January 2014 14:24, Cullen Jennings (fluffy)  wrote=
:

>
> Sure I understand. But understand that MSRP has a really bad downgrade
> attack if you allow self signed certs. So if you want to change MSRP so i=
t
> is can self signed certs for the relay, then I suggest writing a draft to
> do mate that change to MSRP that is separate from the Websockets draft
> because this is an orthogonal issue to the web sockets.
>
> For people that don't want to have to get a signed certificate, I'd
> suggest trying to look at how to design the system to not need MSRP relay=
s.
> There is a long list of ways in which MSRP relays are a huge PITA. I wish
> we had never added them and instead had just used TURN, or SOCKS.
>
>
> On Jan 29, 2014, at 12:18 PM, Peter Dunkley <
> peter.dunkley@crocodilertc.net> wrote:
>
> > It's really just that using self-signed certificates in a browser is a
> real pain.
> >
> > If you have a good signed certificate it all works out.  On an internal
> system many organisations don't buy certificates for internal use, people
> are used to making exceptions, seeing warnings, etc.  But right now today
> if your certificate is self signed and you haven't imported the right stu=
ff
> into each device that might try and make the secure WebSocket connection,
> the certificate validation will fail and the connection won't be made.
> >
> > I do get the argument that people and organisations SHOULD be more
> secure.  Telling them they MUST be more secure tends not to work.  I am
> happy to change the document to say MUST, but it comes back to the point
> that doing this would be because MUST is what we put in these documents
> rather than expecting people to actually do that in all situations.
> >
> >
> >
> >
> > On 29 January 2014 13:29, Cullen Jennings (fluffy) 
> wrote:
> >
> > On Jan 29, 2014, at 11:17 AM, I=F1aki Baz Castillo  wrot=
e:
> >
> > > 2014-01-29 Cullen Jennings (fluffy) :
> > >> On Jan 29, 2014, at 10:16 AM, Peter Dunkley <
> peter.dunkley@crocodilertc.net> wrote:
> > >>
> > >>> Even if TLS is left as MUST all of the additional checks from the
> RFC cannot be enforced on the client because (in a browser) you don't hav=
e
> any access to that information.
> > >>
> > >> So help educate me on what is missing and lets go get that fixed in
> web sockets.
> > >
> > >
> > > The browser inspects the certificate retrieved from the WS server in
> > > the same way than when the browser connects to a HTTPS site. And the
> > > certificate inspection means matching the server domain with the CN o=
r
> > > SubjectAltNames fields (DNS entries) and others usual checks.
> >
> >
> > Right - that sounds good - so what is missing ?
> >
> >
> > _______________________________________________
> > dispatch mailing list
> > dispatch@ietf.org
> > https://www.ietf.org/mailman/listinfo/dispatch
> >
> >
> >
> > --
> > Peter Dunkley
> > Technical Director
> > Crocodile RCS Ltd
>
>


--=20
Peter Dunkley
Technical Director
Crocodile RCS Ltd

--089e013a12f018c40d04f120f1fd
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


The intention here was to downgrade the security requireme=
nt for just MSRP over WebSockets (still leaving it as a SHOULD) and not to =
change the requirements for the existing MSRP relay specification.



Regards,

Peter


On 29 January 2014 14:24, =
Cullen Jennings (fluffy) <fluffy@cisco.com> wrote:




Sure I understand. But understand that MSRP has a really bad downgrade atta=
ck if you allow self signed certs. So if you want to change MSRP so it is c=
an self signed certs for the relay, then I suggest writing a draft to do ma=
te that change to MSRP that is separate from the Websockets draft because t=
his is an orthogonal issue to the web sockets.




For people that don’t want to have to get a signed certificate, I&rsq=
uo;d suggest trying to look at how to design the system to not need MSRP re=
lays. There is a long list of ways in which MSRP relays are a huge PITA. I =
wish we had never added them and instead had just used TURN, or SOCKS.







On Jan 29, 2014, at 12:18 PM, Peter Dunkley <peter.dunkley@crocodilertc.net> wrote:



> It's really just that using self-signed certificates in a browser =
is a real pain.

>

> If you have a good signed certificate it all works out.  On an in=
ternal system many organisations don't buy certificates for internal us=
e, people are used to making exceptions, seeing warnings, etc.  But ri=
ght now today if your certificate is self signed and you haven't import=
ed the right stuff into each device that might try and make the secure WebS=
ocket connection, the certificate validation will fail and the connection w=
on't be made.


>

> I do get the argument that people and organisations SHOULD be more sec=
ure.  Telling them they MUST be more secure tends not to work.  I=
 am happy to change the document to say MUST, but it comes back to the poin=
t that doing this would be because MUST is what we put in these documents r=
ather than expecting people to actually do that in all situations.


>

>

>

>

> On 29 January 2014 13:29, Cullen Jennings (fluffy) <fluffy@cisco.com> wrote:

>

> On Jan 29, 2014, at 11:17 AM, I=F1aki Baz Castillo <ibc@aliax.net> wrote:

>

> > 2014-01-29 Cullen Jennings (fluffy) <fluffy@cisco.com>:

> >> On Jan 29, 2014, at 10:16 AM, Peter Dunkley <peter.dunkley@crocodilertc.net>=
 wrote:

> >>

> >>> Even if TLS is left as MUST all of the additional checks =
from the RFC cannot be enforced on the client because (in a browser) you do=
n't have any access to that information.

> >>

> >> So help educate me on what is missing and lets go get that fi=
xed in web sockets.

> >

> >

> > The browser inspects the certificate retrieved from the WS server=
 in

> > the same way than when the browser connects to a HTTPS site. And =
the

> > certificate inspection means matching the server domain with the =
CN or

> > SubjectAltNames fields (DNS entries) and others usual checks.

>

>

> Right - that sounds good - so what is missing ?

>

>

> _______________________________________________

> dispatch mailing list

> dispatch@ietf.org

> https://www.ietf.org/mailman/listinfo/dispatch

>

>

>

> --

> Peter Dunkley

> Technical Director

> Crocodile RCS Ltd







-- 
=

Peter Dunkley
Technical Director


Crocodile RCS Ltd




--089e013a12f018c40d04f120f1fd--

From mary.ietf.barnes@gmail.com  Wed Jan 29 11:32:51 2014
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 5182E1A03F0; Wed, 29 Jan 2014 11: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 didev8hmZnzx; Wed, 29 Jan 2014 11:32:46 -0800 (PST)
Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 5FA161A0361; Wed, 29 Jan 2014 11:32:46 -0800 (PST)
Received: by mail-ie0-f174.google.com with SMTP id tp5so2534876ieb.19 for ; Wed, 29 Jan 2014 11:32:43 -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=YZPw+k8+HVYXeER9BbXCVM3yAs+JNPnrbEThAe8nBwY=; b=Pd+MLTGfxHyhUSypL3CWXQfTUq9nIbhYWGfnBc72lPZoWHuo+LRMGaMcLsaSKJdQi8 Ve70yoQ74Ki+1xMzYDJ3YQiHoW5odpH0Cxm/Jyk+Z9pUjFLR4AzR9gMUZ3t18vJfMURO uRzLfpjERqG5BbKJID4dmdYcpHz+GDSAWOFkEOgkJBdESO+vFRj6W7j7VGnMUcFPgfrr 5p6U/OYswHPll2JD0XqL4BCT5c/DNS0MUQKCWVYbnW09smkXTyvFyKWTPGzllt6ACuXt pMM4NVFI/wGF5AAKXzlYhNlc2IYvlvXgcPbTaO0oPrfx0OWSF9G2vLjCEhEiro3cjvVy Ey4Q==
MIME-Version: 1.0
X-Received: by 10.50.110.3 with SMTP id hw3mr20070745igb.12.1391023963309; Wed, 29 Jan 2014 11:32:43 -0800 (PST)
Received: by 10.43.58.137 with HTTP; Wed, 29 Jan 2014 11:32:43 -0800 (PST)
In-Reply-To: 
References: <45B84D8F-AD8C-4B28-90DF-9B1C40771104@nostrum.com> <6833E320-7B45-4FC2-853B-62311DCF7E7B@nostrum.com>    <1E320318-64CE-4F8B-AB76-8C4A5244379A@cisco.com>  <8DB45325-9CCA-411C-A809-9B716616CE2F@cisco.com>   
Date: Wed, 29 Jan 2014 13:32:43 -0600
Message-ID: 
From: Mary Barnes 
To: Peter Dunkley 
Content-Type: multipart/alternative; boundary=089e013cbd50350f9804f12101a4
Cc: "Cullen Jennings \(fluffy\)" , "draft-pd-dispatch-msrp-websocket.all@tools.ietf.org" , DISPATCH , "rai@ietf.org" , Ben Campbell 
Subject: Re: [dispatch] [RAI] MSRP Expert Review of draft-pd-dispatch-msrp-websocket-04
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, 29 Jan 2014 19:32:51 -0000

--089e013cbd50350f9804f12101a4
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Yeah, but you'll need a really strong justification for this to get this
document through the IESG and I will have to sufficiently document that
this concern was raised during the expert and WG review.  You also need to
consider that this doc will be going through the process just after new ADs
are seated.  It is not at all unusual for new ADs to be extremely zealous
about documents that they review early in their term.  Based on my own
recent experiences, that discussion will likely take 10 fold of the time
you've spent in this discussion during that part of the process.

Mary.


On Wed, Jan 29, 2014 at 1:28 PM, Peter Dunkley <
peter.dunkley@crocodilertc.net> wrote:

> The intention here was to downgrade the security requirement for just MSR=
P
> over WebSockets (still leaving it as a SHOULD) and not to change the
> requirements for the existing MSRP relay specification.
>
> Regards,
>
> Peter
>
>
> On 29 January 2014 14:24, Cullen Jennings (fluffy) wrot=
e:
>
>>
>> Sure I understand. But understand that MSRP has a really bad downgrade
>> attack if you allow self signed certs. So if you want to change MSRP so =
it
>> is can self signed certs for the relay, then I suggest writing a draft t=
o
>> do mate that change to MSRP that is separate from the Websockets draft
>> because this is an orthogonal issue to the web sockets.
>>
>> For people that don't want to have to get a signed certificate, I'd
>> suggest trying to look at how to design the system to not need MSRP rela=
ys.
>> There is a long list of ways in which MSRP relays are a huge PITA. I wis=
h
>> we had never added them and instead had just used TURN, or SOCKS.
>>
>>
>> On Jan 29, 2014, at 12:18 PM, Peter Dunkley <
>> peter.dunkley@crocodilertc.net> wrote:
>>
>> > It's really just that using self-signed certificates in a browser is a
>> real pain.
>> >
>> > If you have a good signed certificate it all works out.  On an interna=
l
>> system many organisations don't buy certificates for internal use, peopl=
e
>> are used to making exceptions, seeing warnings, etc.  But right now toda=
y
>> if your certificate is self signed and you haven't imported the right st=
uff
>> into each device that might try and make the secure WebSocket connection=
,
>> the certificate validation will fail and the connection won't be made.
>> >
>> > I do get the argument that people and organisations SHOULD be more
>> secure.  Telling them they MUST be more secure tends not to work.  I am
>> happy to change the document to say MUST, but it comes back to the point
>> that doing this would be because MUST is what we put in these documents
>> rather than expecting people to actually do that in all situations.
>> >
>> >
>> >
>> >
>> > On 29 January 2014 13:29, Cullen Jennings (fluffy) 
>> wrote:
>> >
>> > On Jan 29, 2014, at 11:17 AM, I=F1aki Baz Castillo  wro=
te:
>> >
>> > > 2014-01-29 Cullen Jennings (fluffy) :
>> > >> On Jan 29, 2014, at 10:16 AM, Peter Dunkley <
>> peter.dunkley@crocodilertc.net> wrote:
>> > >>
>> > >>> Even if TLS is left as MUST all of the additional checks from the
>> RFC cannot be enforced on the client because (in a browser) you don't ha=
ve
>> any access to that information.
>> > >>
>> > >> So help educate me on what is missing and lets go get that fixed in
>> web sockets.
>> > >
>> > >
>> > > The browser inspects the certificate retrieved from the WS server in
>> > > the same way than when the browser connects to a HTTPS site. And the
>> > > certificate inspection means matching the server domain with the CN =
or
>> > > SubjectAltNames fields (DNS entries) and others usual checks.
>> >
>> >
>> > Right - that sounds good - so what is missing ?
>> >
>> >
>> > _______________________________________________
>> > dispatch mailing list
>> > dispatch@ietf.org
>> > https://www.ietf.org/mailman/listinfo/dispatch
>> >
>> >
>> >
>> > --
>> > Peter Dunkley
>> > Technical Director
>> > Crocodile RCS Ltd
>>
>>
>
>
> --
> Peter Dunkley
> Technical Director
> Crocodile RCS Ltd
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>
>

--089e013cbd50350f9804f12101a4
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


Yeah, but you'll need a really strong justification fo=
r this to get this document through the IESG and I will have to sufficientl=
y document that this concern was raised during the expert and WG review. &n=
bsp;You also need to consider that this doc will be going through the proce=
ss just after new ADs are seated.  It is not at all unusual for new AD=
s to be extremely zealous about documents that they review early in their t=
erm.  Based on my own recent experiences, that discussion will likely =
take 10 fold of the time you've spent in this discussion during that pa=
rt of the process. 


Mary. 


On Wed, Jan 29, 2014 at 1:28 PM, Peter Dunkley <peter.dunkley@crocodilertc.net> wrote:


The intention here was to d=
owngrade the security requirement for just MSRP over WebSockets (still leav=
ing it as a SHOULD) and not to change the requirements for the existing MSR=
P relay specification.




Regards,

Peter


On 29 January 2014 14:24, Cullen Jennings (fluffy) <fluffy@c=
isco.com> wrote:





Sure I understand. But understand that MSRP has a really bad downgrade atta=
ck if you allow self signed certs. So if you want to change MSRP so it is c=
an self signed certs for the relay, then I suggest writing a draft to do ma=
te that change to MSRP that is separate from the Websockets draft because t=
his is an orthogonal issue to the web sockets.





For people that don’t want to have to get a signed certificate, I&rsq=
uo;d suggest trying to look at how to design the system to not need MSRP re=
lays. There is a long list of ways in which MSRP relays are a huge PITA. I =
wish we had never added them and instead had just used TURN, or SOCKS.








On Jan 29, 2014, at 12:18 PM, Peter Dunkley <peter.dunkley@crocodilertc.net=
> wrote:



> It's really just that using self-signed certificates in a browser =
is a real pain.

>

> If you have a good signed certificate it all works out.  On an in=
ternal system many organisations don't buy certificates for internal us=
e, people are used to making exceptions, seeing warnings, etc.  But ri=
ght now today if your certificate is self signed and you haven't import=
ed the right stuff into each device that might try and make the secure WebS=
ocket connection, the certificate validation will fail and the connection w=
on't be made.



>

> I do get the argument that people and organisations SHOULD be more sec=
ure.  Telling them they MUST be more secure tends not to work.  I=
 am happy to change the document to say MUST, but it comes back to the poin=
t that doing this would be because MUST is what we put in these documents r=
ather than expecting people to actually do that in all situations.



>

>

>

>

> On 29 January 2014 13:29, Cullen Jennings (fluffy) <fluffy@cisco.com> wrote:

>

> On Jan 29, 2014, at 11:17 AM, I=F1aki Baz Castillo <ibc@aliax.net> wrote:

>

> > 2014-01-29 Cullen Jennings (fluffy) <fluffy@cisco.com>:

> >> On Jan 29, 2014, at 10:16 AM, Peter Dunkley <peter.dunkley@crocod=
ilertc.net> wrote:

> >>

> >>> Even if TLS is left as MUST all of the additional checks =
from the RFC cannot be enforced on the client because (in a browser) you do=
n't have any access to that information.

> >>

> >> So help educate me on what is missing and lets go get that fi=
xed in web sockets.

> >

> >

> > The browser inspects the certificate retrieved from the WS server=
 in

> > the same way than when the browser connects to a HTTPS site. And =
the

> > certificate inspection means matching the server domain with the =
CN or

> > SubjectAltNames fields (DNS entries) and others usual checks.

>

>

> Right - that sounds good - so what is missing ?

>

>

> _______________________________________________

> dispatch mailing list

> dispatch@ietf.o=
rg

> https://www.ietf.org/mailman/listinfo/dispatch

>

>

>

> --

> Peter Dunkley

> Technical Director

> Crocodile RCS Ltd







-- 
=

Peter Dunkley
Technical Director



Crocodile RCS Ltd





_______________________________________________

dispatch mailing list

dispatch@ietf.org

https://www.ietf.org/mailman/listinfo/dispatch





--089e013cbd50350f9804f12101a4--

From keith.drage@alcatel-lucent.com  Wed Jan 29 12:50:04 2014
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 E68731A03FE; Wed, 29 Jan 2014 12:50:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level: 
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] 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 ueOOTfPBeMvg; Wed, 29 Jan 2014 12:50:00 -0800 (PST)
Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id 5030F1A027B; Wed, 29 Jan 2014 12:50:00 -0800 (PST)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s0TKnmo4016217 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 29 Jan 2014 14:49:49 -0600 (CST)
Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s0TKnlTN021372 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 29 Jan 2014 21:49:47 +0100
Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.26]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Wed, 29 Jan 2014 21:49:47 +0100
From: "DRAGE, Keith (Keith)" 
To: Mary Barnes , Peter Dunkley 
Thread-Topic: [dispatch] [RAI] MSRP Expert Review of draft-pd-dispatch-msrp-websocket-04
Thread-Index: AQHPHShMmG+GTMZ0DEmjyWZEeE7thZqcBq6AgAAmCsA=
Date: Wed, 29 Jan 2014 20:49:47 +0000
Message-ID: <949EF20990823C4C85C18D59AA11AD8B125547@FR712WXCHMBA11.zeu.alcatel-lucent.com>
References: <45B84D8F-AD8C-4B28-90DF-9B1C40771104@nostrum.com> <6833E320-7B45-4FC2-853B-62311DCF7E7B@nostrum.com>    <1E320318-64CE-4F8B-AB76-8C4A5244379A@cisco.com>  <8DB45325-9CCA-411C-A809-9B716616CE2F@cisco.com>    
In-Reply-To: 
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.239.27.38]
Content-Type: multipart/alternative; boundary="_000_949EF20990823C4C85C18D59AA11AD8B125547FR712WXCHMBA11zeu_"
MIME-Version: 1.0
Cc: "Cullen Jennings \(fluffy\)" , "draft-pd-dispatch-msrp-websocket.all@tools.ietf.org" , DISPATCH , "rai@ietf.org" , Ben Campbell 
Subject: Re: [dispatch] [RAI] MSRP Expert Review of	draft-pd-dispatch-msrp-websocket-04
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, 29 Jan 2014 20:50:05 -0000

--_000_949EF20990823C4C85C18D59AA11AD8B125547FR712WXCHMBA11zeu_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

And it is not clear to me, aside from the possibility that you want to use =
one and not the other, why the downgrade is websocket specific.

regards

Keith

________________________________
From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Mary Barnes
Sent: 29 January 2014 19:33
To: Peter Dunkley
Cc: Cullen Jennings (fluffy); draft-pd-dispatch-msrp-websocket.all@tools.ie=
tf.org; DISPATCH; rai@ietf.org; Ben Campbell
Subject: Re: [dispatch] [RAI] MSRP Expert Review of draft-pd-dispatch-msrp-=
websocket-04

Yeah, but you'll need a really strong justification for this to get this do=
cument through the IESG and I will have to sufficiently document that this =
concern was raised during the expert and WG review.  You also need to consi=
der that this doc will be going through the process just after new ADs are =
seated.  It is not at all unusual for new ADs to be extremely zealous about=
 documents that they review early in their term.  Based on my own recent ex=
periences, that discussion will likely take 10 fold of the time you've spen=
t in this discussion during that part of the process.

Mary.


On Wed, Jan 29, 2014 at 1:28 PM, Peter Dunkley > wrote:
The intention here was to downgrade the security requirement for just MSRP =
over WebSockets (still leaving it as a SHOULD) and not to change the requir=
ements for the existing MSRP relay specification.

Regards,

Peter


On 29 January 2014 14:24, Cullen Jennings (fluffy) > wrote:

Sure I understand. But understand that MSRP has a really bad downgrade atta=
ck if you allow self signed certs. So if you want to change MSRP so it is c=
an self signed certs for the relay, then I suggest writing a draft to do ma=
te that change to MSRP that is separate from the Websockets draft because t=
his is an orthogonal issue to the web sockets.

For people that don't want to have to get a signed certificate, I'd suggest=
 trying to look at how to design the system to not need MSRP relays. There =
is a long list of ways in which MSRP relays are a huge PITA. I wish we had =
never added them and instead had just used TURN, or SOCKS.


On Jan 29, 2014, at 12:18 PM, Peter Dunkley > wrote:

> It's really just that using self-signed certificates in a browser is a re=
al pain.
>
> If you have a good signed certificate it all works out.  On an internal s=
ystem many organisations don't buy certificates for internal use, people ar=
e used to making exceptions, seeing warnings, etc.  But right now today if =
your certificate is self signed and you haven't imported the right stuff in=
to each device that might try and make the secure WebSocket connection, the=
 certificate validation will fail and the connection won't be made.
>
> I do get the argument that people and organisations SHOULD be more secure=
.  Telling them they MUST be more secure tends not to work.  I am happy to =
change the document to say MUST, but it comes back to the point that doing =
this would be because MUST is what we put in these documents rather than ex=
pecting people to actually do that in all situations.
>
>
>
>
> On 29 January 2014 13:29, Cullen Jennings (fluffy) > wrote:
>
> On Jan 29, 2014, at 11:17 AM, I=F1aki Baz Castillo > wrote:
>
> > 2014-01-29 Cullen Jennings (fluffy) >:
> >> On Jan 29, 2014, at 10:16 AM, Peter Dunkley > wrote:
> >>
> >>> Even if TLS is left as MUST all of the additional checks from the RFC=
 cannot be enforced on the client because (in a browser) you don't have any=
 access to that information.
> >>
> >> So help educate me on what is missing and lets go get that fixed in we=
b sockets.
> >
> >
> > The browser inspects the certificate retrieved from the WS server in
> > the same way than when the browser connects to a HTTPS site. And the
> > certificate inspection means matching the server domain with the CN or
> > SubjectAltNames fields (DNS entries) and others usual checks.
>
>
> Right - that sounds good - so what is missing ?
>
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>
>
>
> --
> Peter Dunkley
> Technical Director
> Crocodile RCS Ltd




--
Peter Dunkley
Technical Director
Crocodile RCS Ltd

_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch



--_000_949EF20990823C4C85C18D59AA11AD8B125547FR712WXCHMBA11zeu_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable









And it is not clear to me, aside =
from the possibility that you want to use one and not the other, why the do=
wngrade is websocket specific.


 


regards


 


Keith









From: dispatch [mailto:dispatch-bou=
nces@ietf.org]
On Behalf Of Mary Barnes

Sent: 29 January 2014 19:33

To: Peter Dunkley

Cc: Cullen Jennings (fluffy); draft-pd-dispatch-msrp-websocket.all@t=
ools.ietf.org; DISPATCH; rai@ietf.org; Ben Campbell

Subject: Re: [dispatch] [RAI] MSRP Expert Review of draft-pd-dispatc=
h-msrp-websocket-04








Yeah, but you'll need a really strong justification for th=
is to get this document through the IESG and I will have to sufficiently do=
cument that this concern was raised during the expert and WG review.  =
You also need to consider that this doc
 will be going through the process just after new ADs are seated.  It =
is not at all unusual for new ADs to be extremely zealous about documents t=
hat they review early in their term.  Based on my own recent experienc=
es, that discussion will likely take 10 fold
 of the time you've spent in this discussion during that part of the proces=
s. 






Mary. 









On Wed, Jan 29, 2014 at 1:28 PM, Peter Dunkley <=
span dir=3D"ltr">
<pet=
er.dunkley@crocodilertc.net> wrote:




The intention here was to downgrade the security requireme=
nt for just MSRP over WebSockets (still leaving it as a SHOULD) and not to =
change the requirements for the existing MSRP relay specification.






Regards,







Peter













On 29 January 2014 14:24, Cullen Jennings (fluff=
y) 
<fluffy@cisco.com<=
/a>> wrote:





Sure I understand. But understand that MSRP has a really bad downgrade atta=
ck if you allow self signed certs. So if you want to change MSRP so it is c=
an self signed certs for the relay, then I suggest writing a draft to do ma=
te that change to MSRP that is separate
 from the Websockets draft because this is an orthogonal issue to the web s=
ockets.



For people that don’t want to have to get a signed certificate, IR=
17;d suggest trying to look at how to design the system to not need MSRP re=
lays. There is a long list of ways in which MSRP relays are a huge PITA. I =
wish we had never added them and instead had
 just used TURN, or SOCKS.








On Jan 29, 2014, at 12:18 PM, Peter Dunkley <peter.dunkley@crocodilertc.net=
> wrote:



> It's really just that using self-signed certificates in a browser is a=
 real pain.

>

> If you have a good signed certificate it all works out.  On an in=
ternal system many organisations don't buy certificates for internal use, p=
eople are used to making exceptions, seeing warnings, etc.  But right =
now today if your certificate is self signed
 and you haven't imported the right stuff into each device that might try a=
nd make the secure WebSocket connection, the certificate validation will fa=
il and the connection won't be made.

>

> I do get the argument that people and organisations SHOULD be more sec=
ure.  Telling them they MUST be more secure tends not to work.  I=
 am happy to change the document to say MUST, but it comes back to the poin=
t that doing this would be because MUST is what
 we put in these documents rather than expecting people to actually do that=
 in all situations.

>

>

>

>

> On 29 January 2014 13:29, Cullen Jennings (fluffy) <fluffy@cisco.com> wrote:

>

> On Jan 29, 2014, at 11:17 AM, I=F1aki Baz Castillo <ibc@aliax.net> wrote:

>

> > 2014-01-29 Cullen Jennings (fluffy) <fluffy@cisco.com>:

> >> On Jan 29, 2014, at 10:16 AM, Peter Dunkley <peter.dunkley@crocod=
ilertc.net> wrote:

> >>

> >>> Even if TLS is left as MUST all of the additional checks =
from the RFC cannot be enforced on the client because (in a browser) you do=
n't have any access to that information.

> >>

> >> So help educate me on what is missing and lets go get that fi=
xed in web sockets.

> >

> >

> > The browser inspects the certificate retrieved from the WS server=
 in

> > the same way than when the browser connects to a HTTPS site. And =
the

> > certificate inspection means matching the server domain with the =
CN or

> > SubjectAltNames fields (DNS entries) and others usual checks.

>

>

> Right - that sounds good - so what is missing ?

>

>

> _______________________________________________

> dispatch mailing list

> dispatch@ietf.o=
rg

> https://www.ietf.org/mailman/listinfo/dispatch

>

>

>

> --

> Peter Dunkley

> Technical Director

> Crocodile RCS Ltd




















-- 




Peter Dunkley


Technical Director


Crocodile RCS Ltd











_______________________________________________

dispatch mailing list

dispatch@ietf.org

https://www.ietf.org/mailman/listinfo/dispatch
















--_000_949EF20990823C4C85C18D59AA11AD8B125547FR712WXCHMBA11zeu_--

From oej@edvina.net  Wed Jan 29 23:33:17 2014
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 E10C31A04F8; Wed, 29 Jan 2014 23:33:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.55
X-Spam-Level: 
X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HTML_MESSAGE=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 pRG0YED99Bq1; Wed, 29 Jan 2014 23:33:15 -0800 (PST)
Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 68BF61A0476; Wed, 29 Jan 2014 23:33:13 -0800 (PST)
Received: from [192.168.40.13] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 7F69D93C2A2; Thu, 30 Jan 2014 07:33:09 +0000 (UTC)
Content-Type: multipart/alternative; boundary="Apple-Mail=_7F30C153-A42D-4DD8-A287-6187A6EE9F98"
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: "Olle E. Johansson" 
In-Reply-To: 
Date: Thu, 30 Jan 2014 08:33:09 +0100
Message-Id: <3DE18DC8-CC7D-43A1-BB49-8EA154528391@edvina.net>
References: <45B84D8F-AD8C-4B28-90DF-9B1C40771104@nostrum.com> <6833E320-7B45-4FC2-853B-62311DCF7E7B@nostrum.com>    <1E320318-64CE-4F8B-AB76-8C4A5244379A@cisco.com>  <8DB45325-9CCA-411C-A809-9B716616CE2F@cisco.com> 
To: Peter Dunkley 
X-Mailer: Apple Mail (2.1827)
Cc: "Cullen Jennings \(fluffy\)" , Ben Campbell , DISPATCH , "rai@ietf.org" , "draft-pd-dispatch-msrp-websocket.all@tools.ietf.org" 
Subject: Re: [dispatch] [RAI] MSRP Expert Review of draft-pd-dispatch-msrp-websocket-04
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, 30 Jan 2014 07:33:18 -0000

--Apple-Mail=_7F30C153-A42D-4DD8-A287-6187A6EE9F98
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1

I remember from SIPit WebRTC tests that we had a discussion about error =
codes. I wanted to set up a TLS
test on the WebSocket server but participants claimed that Javascript =
did not have error codes to properly
handle situations like expired cert, unrecognized CA etc etc.

I don't know if that's still the situation, but if it is, we need better =
tools in the browser to handle the
web socket connection.

/O

On 29 Jan 2014, at 20:18, Peter Dunkley  =
wrote:

> It's really just that using self-signed certificates in a browser is a =
real pain.
>=20
> If you have a good signed certificate it all works out.  On an =
internal system many organisations don't buy certificates for internal =
use, people are used to making exceptions, seeing warnings, etc.  But =
right now today if your certificate is self signed and you haven't =
imported the right stuff into each device that might try and make the =
secure WebSocket connection, the certificate validation will fail and =
the connection won't be made.
>=20
> I do get the argument that people and organisations SHOULD be more =
secure.  Telling them they MUST be more secure tends not to work.  I am =
happy to change the document to say MUST, but it comes back to the point =
that doing this would be because MUST is what we put in these documents =
rather than expecting people to actually do that in all situations.
>=20
>=20
>=20
>=20
> On 29 January 2014 13:29, Cullen Jennings (fluffy)  =
wrote:
>=20
> On Jan 29, 2014, at 11:17 AM, I=F1aki Baz Castillo  =
wrote:
>=20
> > 2014-01-29 Cullen Jennings (fluffy) :
> >> On Jan 29, 2014, at 10:16 AM, Peter Dunkley =
 wrote:
> >>
> >>> Even if TLS is left as MUST all of the additional checks from the =
RFC cannot be enforced on the client because (in a browser) you don't =
have any access to that information.
> >>
> >> So help educate me on what is missing and lets go get that fixed in =
web sockets.
> >
> >
> > The browser inspects the certificate retrieved from the WS server in
> > the same way than when the browser connects to a HTTPS site. And the
> > certificate inspection means matching the server domain with the CN =
or
> > SubjectAltNames fields (DNS entries) and others usual checks.
>=20
>=20
> Right - that sounds good - so what is missing ?
>=20
>=20
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>=20
>=20
>=20
> --=20
> Peter Dunkley
> Technical Director
> Crocodile RCS Ltd
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch


--Apple-Mail=_7F30C153-A42D-4DD8-A287-6187A6EE9F98
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=iso-8859-1

I =
remember from SIPit WebRTC tests that we had a discussion about error =
codes. I wanted to set up a TLS
test on the WebSocket server but =
participants claimed that Javascript did not have error codes to =
properly
handle situations like expired cert, unrecognized CA =
etc etc.

I don't know if that's still the =
situation, but if it is, we need better tools in the browser to handle =
the
web socket =
connection.

/O

On 29 =
Jan 2014, at 20:18, Peter Dunkley <peter.dunkley@crocodilertc.=
net> wrote:

It's really just that using self-signed certificates in a =
browser is a real pain.

If you have a good signed =
certificate it all works out.  On an internal system many =
organisations don't buy certificates for internal use, people are used =
to making exceptions, seeing warnings, etc.  But right now today if =
your certificate is self signed and you haven't imported the right stuff =
into each device that might try and make the secure WebSocket =
connection, the certificate validation will fail and the connection =
won't be made.



I do get the argument that people and organisations =
SHOULD be more secure.  Telling them they MUST be more secure tends =
not to work.  I am happy to change the document to say MUST, but it =
comes back to the point that doing this would be because MUST is what we =
put in these documents rather than expecting people to actually do that =
in all situations.






On 29 January =
2014 13:29, Cullen Jennings (fluffy) <fluffy@cisco.com> wrote:




On Jan 29, 2014, at 11:17 AM, I=F1aki Baz Castillo <ibc@aliax.net> wrote:



> 2014-01-29 Cullen Jennings (fluffy) <fluffy@cisco.com>:

>> On Jan 29, 2014, at 10:16 AM, Peter Dunkley <peter.dunkley@crocodilertc.=
net> wrote:

>>

>>> Even if TLS is left as MUST all of the additional checks =
from the RFC cannot be enforced on the client because (in a browser) you =
don't have any access to that information.

>>

>> So help educate me on what is missing and lets go get that =
fixed in web sockets.

>

>

> The browser inspects the certificate retrieved from the WS server =
in

> the same way than when the browser connects to a HTTPS site. And =
the

> certificate inspection means matching the server domain with the CN =
or

> SubjectAltNames fields (DNS entries) and others usual checks.






Right - that sounds good - so what is missing ?






_______________________________________________

dispatch mailing list

dispatch@ietf.org

https://www.ietf.org/mailman/listinfo/dispatch





-- =

Peter =
Dunkley
Technical =
Director


Crocodile RCS =
Ltd



_______________________________________________
dispatch mailing =
list
dispatch@ietf.org
https://www.iet=
f.org/mailman/listinfo/dispatch

=

--Apple-Mail=_7F30C153-A42D-4DD8-A287-6187A6EE9F98--

From oej@edvina.net  Thu Jan 30 01:26:21 2014
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 139CF1A044E; Thu, 30 Jan 2014 01:26:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.551
X-Spam-Level: 
X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 9ZlUmzFy2hvx; Thu, 30 Jan 2014 01:26:19 -0800 (PST)
Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 9475E1A03E9; Thu, 30 Jan 2014 01:26:15 -0800 (PST)
Received: from [192.168.40.68] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id E8C8793C2A1; Thu, 30 Jan 2014 09:26:11 +0000 (UTC)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: "Olle E. Johansson" 
In-Reply-To: <1E320318-64CE-4F8B-AB76-8C4A5244379A@cisco.com>
Date: Thu, 30 Jan 2014 10:26:11 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <02B7636E-68F1-4513-B214-44635162874D@edvina.net>
References: <45B84D8F-AD8C-4B28-90DF-9B1C40771104@nostrum.com> <6833E320-7B45-4FC2-853B-62311DCF7E7B@nostrum.com>    <1E320318-64CE-4F8B-AB76-8C4A5244379A@cisco.com>
To: "Cullen Jennings (fluffy)" 
X-Mailer: Apple Mail (2.1827)
Cc: Ben Campbell , DISPATCH , "rai@ietf.org" , "draft-pd-dispatch-msrp-websocket.all@tools.ietf.org" 
Subject: Re: [dispatch] [RAI] MSRP Expert Review of draft-pd-dispatch-msrp-websocket-04
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, 30 Jan 2014 09:26:21 -0000

On 29 Jan 2014, at 19:11, Cullen Jennings (fluffy)  =
wrote:

>=20
> On Jan 29, 2014, at 10:16 AM, Peter Dunkley =
 wrote:
>=20
>> Even if TLS is left as MUST all of the additional checks from the RFC =
cannot be enforced on the client because (in a browser) you don't have =
any access to that information.
>=20
> So help educate me on what is missing and lets go get that fixed in =
web sockets.=20
>=20

THis is interesting. If I parse the W3C WebSocket API specification =
correctly, the script is not allowed to know WHY a Websocket connection =
failed. It's just a big failure. I would like to understand why they =
made this choice.

I wonder if this mixes TLS authentication with TLS encryption. We are =
not allowed to set up an encrypted WS connection to a self-signed cert =
or in general a server with a cert signed by an unknown CA even if we =
want to.

I just did a quick check - someone else may know ways around this. (I =
hope).

/O

----
User agents must not convey any failure information to scripts in a way =
that would allow a script to distinguish the following situations:

	=95 A server whose host name could not be resolved.
	=95 A server to which packets could not successfully be routed.
	=95 A server that refused the connection on the specified port.
	=95 A server that failed to correctly perform a TLS handshake =
(e.g., the server certificate can't be verified).
	=95 A server that did not complete the opening handshake (e.g. =
because it was not a WebSocket server).
	=95 A WebSocket server that sent a correct opening handshake, =
but that specified options that caused the client to drop the connection =
(e.g. the server specified a subprotocol that the client did not offer).
	=95 A WebSocket server that abruptly closed the connection after =
successfully completing the opening handshake.
In all of these cases, the the WebSocket connection close code would be =
1006, as required by the WebSocket Protocol specification. [WSP]

Allowing a script to distinguish these cases would allow a script to =
probe the user's local network in preparation for an attack.
-----=

From fluffy@cisco.com  Thu Jan 30 05:46:31 2014
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 3023A1A02C8; Thu, 30 Jan 2014 05:46:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.036
X-Spam-Level: 
X-Spam-Status: No, score=-110.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] 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 mdt10fSdVJp1; Thu, 30 Jan 2014 05:46:27 -0800 (PST)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) by ietfa.amsl.com (Postfix) with ESMTP id 0787B1A026C; Thu, 30 Jan 2014 05:46:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4005; q=dns/txt; s=iport; t=1391089584; x=1392299184; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=TxCNdWgi3Kz3NGJ7GzRBLNe5Hf1UnZfrqCJPp0nWk8o=; b=Ye5Z7BZbV/sR0DH8VK6ebuLxIXP5ENWHymfTIDKYUk+jBOS7SyZAePki k+86q3/GHeZPNYy58f46JyyYztE7ZU1bcmiMGMyhWmvtBO5e+qJURLsye hv6jzjfY47+nmmfhNWRKEvMEopB0f1UBnzFZHBOWPP8ndx+Sn9JJ6z9Kj U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgwFAFVX6lKtJV2d/2dsb2JhbABZgwyBD70lgQkWdIIlAQEBAwFrDhACAQgYLjIlAgQOBYd9CMt/F45PMweDJIEUBJgokh+DLYIq
X-IronPort-AV: E=Sophos;i="4.95,750,1384300800"; d="scan'208";a="16695495"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-8.cisco.com with ESMTP; 30 Jan 2014 13:46:21 +0000
Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s0UDkLTN016937 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 30 Jan 2014 13:46:21 GMT
Received: from xmb-aln-x02.cisco.com ([169.254.5.76]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0123.003; Thu, 30 Jan 2014 07:46:21 -0600
From: "Cullen Jennings (fluffy)" 
To: Olle E Johansson 
Thread-Topic: [dispatch] [RAI] MSRP Expert Review of draft-pd-dispatch-msrp-websocket-04
Thread-Index: AQHPHcGoC5imXzrTE0i6MBdPHXvDBQ==
Date: Thu, 30 Jan 2014 13:46:21 +0000
Message-ID: 
References: <45B84D8F-AD8C-4B28-90DF-9B1C40771104@nostrum.com> <6833E320-7B45-4FC2-853B-62311DCF7E7B@nostrum.com>    <1E320318-64CE-4F8B-AB76-8C4A5244379A@cisco.com> <02B7636E-68F1-4513-B214-44635162874D@edvina.net>
In-Reply-To: <02B7636E-68F1-4513-B214-44635162874D@edvina.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.20.249.164]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <6E6F5293E20CFA43BB509C9A8D0469D5@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "draft-pd-dispatch-msrp-websocket.all@tools.ietf.org" , DISPATCH , "rai@ietf.org" , Ben Campbell 
Subject: Re: [dispatch] [RAI] MSRP Expert Review of draft-pd-dispatch-msrp-websocket-04
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, 30 Jan 2014 13:46:31 -0000

Yep, all of that with web sockets is as you say. The JS can=92t figure out =
why the connection is not secure. All it can figure out is that it is not s=
ecure. I=92m not supporting or arguing against that being a good thing but =
the prevalent feeling is that asking the user to make a decisions that they=
 can=92t possibly know the answer to is not secure.

Which brings us back to the key point here. As far as I can tell Websockets=
 current API is *perfect* to implement MSRP.  =20

Now what some people would like to do is change MSRP so that it can run in =
an encrypted but not authenticated mode. This was argued at the time that M=
SRP was done and for a bunch of reasons it was a rally bad idea. It=92s muc=
h worse than you might think. I don=92t really care to redo theses argument=
s and I am not even going to bother to try and explain them because I mostl=
y don=92t think it will make much difference. However, if people want to ch=
ange MSRP to be have this, they need to change MSRP, once that is done, the=
n we have the problem that the Websockets API does not support this.=20

But in the meantime, AFAIC, web sockets does what MSRP needs. You just need=
 to change this draft so it is not changing the basic MSRP protocol and it =
will be all happy.=20

But wait, I hear the howling in the background of I have no idea what it ta=
kes to practically deploy things and it is impossible to get certificates. =
Yah, I get it. What most people are doing that want to use self signed cert=
s for things like this is they are installing their cert in the root trust =
list of the client.=20



On Jan 30, 2014, at 2:26 AM, Olle E. Johansson  wrote:

>=20
> On 29 Jan 2014, at 19:11, Cullen Jennings (fluffy)  wro=
te:
>=20
>>=20
>> On Jan 29, 2014, at 10:16 AM, Peter Dunkley  wrote:
>>=20
>>> Even if TLS is left as MUST all of the additional checks from the RFC c=
annot be enforced on the client because (in a browser) you don't have any a=
ccess to that information.
>>=20
>> So help educate me on what is missing and lets go get that fixed in web =
sockets.=20
>>=20
>=20
> THis is interesting. If I parse the W3C WebSocket API specification corre=
ctly, the script is not allowed to know WHY a Websocket connection failed. =
It's just a big failure. I would like to understand why they made this choi=
ce.
>=20
> I wonder if this mixes TLS authentication with TLS encryption. We are not=
 allowed to set up an encrypted WS connection to a self-signed cert or in g=
eneral a server with a cert signed by an unknown CA even if we want to.
>=20
> I just did a quick check - someone else may know ways around this. (I hop=
e).
>=20
> /O
>=20
> ----
> User agents must not convey any failure information to scripts in a way t=
hat would allow a script to distinguish the following situations:
>=20
> 	=95 A server whose host name could not be resolved.
> 	=95 A server to which packets could not successfully be routed.
> 	=95 A server that refused the connection on the specified port.
> 	=95 A server that failed to correctly perform a TLS handshake (e.g., the=
 server certificate can't be verified).
> 	=95 A server that did not complete the opening handshake (e.g. because i=
t was not a WebSocket server).
> 	=95 A WebSocket server that sent a correct opening handshake, but that s=
pecified options that caused the client to drop the connection (e.g. the se=
rver specified a subprotocol that the client did not offer).
> 	=95 A WebSocket server that abruptly closed the connection after success=
fully completing the opening handshake.
> In all of these cases, the the WebSocket connection close code would be 1=
006, as required by the WebSocket Protocol specification. [WSP]
>=20
> Allowing a script to distinguish these cases would allow a script to prob=
e the user's local network in preparation for an attack.
> -----


From ibc@aliax.net  Thu Jan 30 06:25:36 2014
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 C02D01A0345 for ; Thu, 30 Jan 2014 06:25:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.678
X-Spam-Level: 
X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] 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 NYX5kiEy6SYd for ; Thu, 30 Jan 2014 06:25:35 -0800 (PST)
Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2F47C1A037D for ; Thu, 30 Jan 2014 06:25:35 -0800 (PST)
Received: by mail-qa0-f44.google.com with SMTP id w5so4440478qac.3 for ; Thu, 30 Jan 2014 06:25:31 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=xvw/IQtsNf+bGsPRqqgtZXWEfPZLpL2YJvCYBVyJksQ=; b=ZDuILmW4W566KG6saTVQJq6b6ATSSWpsXhWos5U06XKYho1sf8V2BcRXe61pMK2ucu pbAQgj8oKKNrkKuwK5/h00cOU/RrfSUXvf+znx95CjOrEO/Q+LGn7chWycQAJ7uh0epO 5FA28E0sp0jEgv1vb6YglnyYw3+Kd6OxQlqsHs4f62b/jp9nW5FcGkAYphQSz70z2t7m oI6Zhabx9Zty/raShc7v6mLopirO2YvnJe2dVuy2HmRWF8dczJLO8KFOHkXb6Z5XbYTY MzFKYNomyetBysHoq/Dgi2X4adTvrWb5Zpz0sYkWevS5jRnpQAzwAyXbjNcyfomunOHl tgrA==
X-Gm-Message-State: ALoCoQnyVGPWiR+oZgkzAzRwhj18oxkdXQBLTa5tb+GeEfaY33xVDuEombLl17DRPzTj5Vv4NE9N
X-Received: by 10.224.7.10 with SMTP id b10mr22514058qab.50.1391091931779; Thu, 30 Jan 2014 06:25:31 -0800 (PST)
MIME-Version: 1.0
Received: by 10.96.101.232 with HTTP; Thu, 30 Jan 2014 06:25:11 -0800 (PST)
In-Reply-To: <02B7636E-68F1-4513-B214-44635162874D@edvina.net>
References: <45B84D8F-AD8C-4B28-90DF-9B1C40771104@nostrum.com> <6833E320-7B45-4FC2-853B-62311DCF7E7B@nostrum.com>    <1E320318-64CE-4F8B-AB76-8C4A5244379A@cisco.com> <02B7636E-68F1-4513-B214-44635162874D@edvina.net>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
Date: Thu, 30 Jan 2014 15:25:11 +0100
Message-ID: 
To: "Olle E. Johansson" 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: "Cullen Jennings \(fluffy\)" , Ben Campbell , DISPATCH , "rai@ietf.org" , "draft-pd-dispatch-msrp-websocket.all@tools.ietf.org" 
Subject: Re: [dispatch] [RAI] MSRP Expert Review of draft-pd-dispatch-msrp-websocket-04
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, 30 Jan 2014 14:25:36 -0000

2014-01-30 Olle E. Johansson :
> If I parse the W3C WebSocket API specification correctly, the script is n=
ot allowed to know WHY a Websocket connection failed. It's just a big failu=
re. I would like to understand why they made this choice.

When RFC 6455 (Websocket) was being written I asked for the WebSocket
API [*] to provide more information about the WS connection failure
(specifically a way to know the HTTP error code if the Websocket
handshake fails due to a non HTTP 101 response). No success at all.
The rationale I was provided with is that JavaScript must not be HTTP
or TLS aware. Instead, the browser manages all these rules and errors.
Let's say that JavaScript just can play once the DNS/TCP/TLS/HTTP/WS
layers have succeeded. If they don't, JavaScript cannot figure why; it
just knows that "the connection has failed".

Believe me, that won't change.

[*] http://dev.w3.org/html5/websockets/


--=20
I=C3=B1aki Baz Castillo


From richard@shockey.us  Fri Jan 31 14:42:04 2014
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 AC4E61A05AA for ; Fri, 31 Jan 2014 14:42:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.034
X-Spam-Level: *
X-Spam-Status: No, score=1.034 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, 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 F5GvlnJEGsai for ; Fri, 31 Jan 2014 14:42:03 -0800 (PST)
Received: from oproxy16-pub.mail.unifiedlayer.com (oproxy16-pub.mail.unifiedlayer.com [69.89.22.201]) by ietfa.amsl.com (Postfix) with SMTP id F2D8A1A04E8 for ; Fri, 31 Jan 2014 14:42:02 -0800 (PST)
Received: (qmail 10883 invoked by uid 0); 31 Jan 2014 22:41:57 -0000
Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy16.mail.unifiedlayer.com with SMTP; 31 Jan 2014 22:41:57 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default;  h=Content-Type:MIME-Version:Message-ID:Date:Subject:To:From; bh=+Qy7wY5CDh6pYreUXUC+e3B3JFAbQcjj44ltDh97QgA=;  b=PHLuxSx/KTstMLTJFulL0nYh9U0arLlNg6WEOhm6/wKkCf6eA8y33Rfskmet01Tsp41tfP3DY1WR6NvTsiTBIRJQ4WjcfMMdxfmMWtRBvHzbxiGYI3C+3L7mtgGhjc7B;
Received: from [173.79.179.104] (port=57501 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1W9Mmb-000375-6t; Fri, 31 Jan 2014 15:41:57 -0700
From: "Richard Shockey" 
To: , "'DISPATCH'" , 
Date: Fri, 31 Jan 2014 17:41:54 -0500
Message-ID: <01a201cf1ed5$a57db4e0$f0791ea0$@shockey.us>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_01A3_01CF1EAB.BCA84920"
X-Mailer: Microsoft Outlook 15.0
Thread-Index: Ac8e1RWe7HcGrHocRxuLkODRtsT0WA==
Content-Language: en-us
X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 173.79.179.104 authed with richard@shockey.us}
Subject: [dispatch] If you recall Henning spoke to us at IETF 86 on The end of POTS
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, 31 Jan 2014 22:42:04 -0000

This is a multipart message in MIME format.

------=_NextPart_000_01A3_01CF1EAB.BCA84920
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

 

http://www.ietf.org/proceedings/86/slides/slides-86-iab-techplenary-4.pdf

 

Well now you can see it in action.

 

The FCC Order on the PSTN Transition.

 

http://hraunfoss.fcc.gov/edocs_public/attachmatch/FCC-14-5A1.pdf

 

It's not too bad for an FCC order only 120 pages or so. :)

 

Even ENUM gets a prominent mention.  

 

Cheers 

Richard Shockey
Shockey Consulting
Chairman of the Board of Directors SIP Forum
PSTN Mobile: +1 703.593.2683
<  mailto:richard(at)shockey.us>
skype-linkedin-facebook: rshockey101
http//www.sipforum.org

"Money is the answer, what is the question?" tm 

 

 


------=_NextPart_000_01A3_01CF1EAB.BCA84920
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


 
http://www.ietf.org/proceedings/86/slides/slides-86-iab-techple=
nary-4.pdf
 
Well now you =
can see it in action.
 
The FCC =
Order on the PSTN Transition.
 
http://hraunfoss.fcc.gov/edocs_public/attachmatch/FCC-1=
4-5A1.pdf
 
It’s not too bad for an FCC order only 120 pages =
or so. J
 
Even ENUM =
gets a prominent mention.  
 
Cheers =

Richard =
Shockey
Shockey Consulting
Chairman of the Board of Directors SIP =
Forum
PSTN Mobile: +1 703.593.2683
<mailto:richard(at)shockey.us>
skype=
-linkedin-facebook: =
rshockey101
http//www.sipforum.org
"Money is the answer, what is the question?" =
tm 
 
 

------=_NextPart_000_01A3_01CF1EAB.BCA84920--


Hi Mary,
Ve=
rsion -13 is uploaded. (http://www.iet=
f.org/internet-drafts/draft-drage-sipping-rfc3455bis-13.txt )
I hope I have covered everything now.
-RFC references not used deleted.<=
/span>
-FQDN corrected
-statement that RFC34=
55 is obsolete included in Head and Abstract
 
Best Regards
 
Roland
 
Von:=
 Mary Barnes [mailto:mary.ietf.barnes@gmail.com] 
Gesendet: Freit=
ag, 10. Januar 2014 20:48
An: Andrew Allen
Cc: Jesske, =
Roland; dispatch@ietf.org; dean.willis@softarmor.com
Betreff: Re:=
 [dispatch] PROTO Review: draft-drage-sipping-rfc3455bis-09.txt<=
/span>
 
Thanks Andrew.  So, that needs to be clearly stated in the ab=
stract as well.  In addition, the Overview section states: 
&q=
uot;This document is an update to RFC3455".  So that also needs t=
o be fixed.   Given the number of changes at this point, I would =
now prefer Roland make those changes before we ask Gonzalo to progress it t=
o IETF LC.
 
Mary. 
 
=

On Fri, Jan 10, 2014 at 1:45 PM, Andrew Allen <aallen@blackberry.co=
m> wrote:

I think=
 it obsoletes RFC 3455. It is a complete replacement for the original.
<=
br>Andrew
 
From=
: Mary Barnes [mailto:mary.ietf.barnes@gmail.com] 
<=
p class=3DMsoNormal>Sent: Friday, January 10, 2014 02:37 PM Eastern Standard =
Time
To: R.Jesske@telekom.de <R.Jesske@telekom.de> 
Cc: DISPATCH <dispatch@ietf.org>; =
Dean Willis <dean.willis@softarmor.com> 
Subject: Re: [dispatch] PR=
OTO Review: draft-drage-sipping-rfc3455bis-09.txt 
 
There is yet one more chan=
ge needed.  This document is an Updates to 3455bis (AFAIK, unless Obse=
letes works better for 3GPP usage).  That categorization needs to be i=
ncluded in the document header (3rd line).  
 
Thanks,=

Mary. 
&nb=
sp;
On Fri, Jan 10, 2014 at 1:34 PM, Mar=
y Barnes <mary.ietf.barnes@gmail.com> wrote:
 
On Wed, Jan 8, 2014 at 2:46 AM, <R.Jesske@telekom.de> wrote:
Thank you Marry,
for doing all this review.
So I have now put out the errors.=

There are still some unused refer=
ences which are in our informal reference section. But useful for the reade=
r to know they exist.
Ther=
e are also some warnings with regard to IP addresses and wrong FQDNs which =
I think is some interpretation of strings in the text which are not meant t=
o be a IP address or FQDN at all. 
 
Detail see=
 below.
 <=
/o:p>
So now hopefully everything is ready fo=
r the next step.
 
Best Regards=

 
Roland
 
tmp/draft-drage-sipping-rfc3455bis-12.txt:
 
  Checking boiler=
plate required by RFC 5378 and the IETF Trust (see
  =
http://trustee.ietf.org/license-info):
  =
---------------------------------------------------------------------------=
-
 
  &nbs=
p;  No issues found here.
 <=
/o:p>
  Checking nits according to http://www.ietf.org/id-inf=
o/1id-guidelines.txt:
  ---------------=
-------------------------------------------------------------
 
     No iss=
ues found here.
 
&n=
bsp; Checking nits according to http://www.ietf.org/id-info/checklist :=

  -------------------------------------------------=
---------------------------
 
 =3D=3D There are 4 instances of lines with non-RFC260=
6-compliant FQDNs in the
   &n=
bsp; document.
 
=
&nb=
sp; =3D=3D There are 4 instances of lines with non-RFC5735-compliant IPv4 a=
ddresses
     in the document.=
  If these are example addresses, they should be changed.<=
/o:p>
 
 
  ----------=
------------------------------------------------------------------
 
   &n=
bsp; No issues found here.
 
  Checking references for intended status: Informational
  ----------------------------------------------=
------------------------------
 <=
/o:p>
  =3D=3D Missing Reference: 'RFC XXXX' is mentioned on li=
ne 1662, but not defined
 <=
/p>
  -- Looks like a reference, but probably isn't: '3' on line 19=
43
 
  =3D=
=3D Unused Reference: 'RFC3262' is defined on line 2068, but no explicit
     reference was found in the =
text
 
  =
=3D=3D Unused Reference: 'RFC3311' is defined on line 2072, but no explicit=

     reference was found=
 in the text
 
  =3D=3D Unused Reference: 'RFC3428' is defined on line 2078, but no =
explicit
     reference w=
as found in the text
 
  =3D=3D Unused Reference: 'RFC3903' is defined on line 209=
0, but no explicit
     r=
eference was found in the text
 <=
/o:p>
  =3D=3D Unused Reference: 'RFC6086' is defined on =
line 2101, but no explicit
   =
  reference was found in the text
 
 
  &nbs=
p;  Summary: 0 errors (**), 0 flaws (~~), 8 warnings (=3D=3D), 1 comme=
nt (--).
 
<=
span lang=3DEN-US style=3D'font-size:10.0pt;font-family:"Courier New"'>&nbs=
p;    Run idnits with the --verbose option for more detailed=
 information about
     the items above=
.
-------------------------------------------------------=
-------------------------
 
=
 
 
Von: Mary Barnes [mailto:mary.ietf.barnes@g=
mail.com] 
Gesendet: Dienstag, 7. Januar 2014 18:55

An: Jesske, RolandCc: DISPATCH; Gonzalo Camarillo; Atle Monrad; Dean Willis
Bet=
reff: Re: PROTO Review: draft-drage-sipping-rfc3455bis-09.txt
 
T=
hanks Roland.  I have reviewed that version and all the changes I sugg=
ested have been made.  However, in doing the PROTO write-up I realized=
 that I wasn't certain anyone had reviewed the ABNF. So, I ran the ABNF thr=
ough Bill Fenner's tool: 
 
And, there are a couple things that need to be fixed:
1)  DOT needs to change to "."=
; (we had this same bug in RFC 4244):
transit-ioi-indexed-v=
alue =3D transit-ioi-name DOT transit-ioi-index
=

 
2)  There's an extr=
a space here (between * and parenthesis):
<=
span style=3D'font-size:10.0pt;font-family:"Courier New"'>transit-ioi-name&=
nbsp;         =3D ALPHA * (ALPHA / =
DIGIT)
NEw: transit-ioi-name        &n=
bsp; =3D ALPHA *(ALPHA / DIGIT)
&nbs=
p;
There are also a number of long lines in=
 the ABNF that should be fixed. 
 =
;
In addition, IDNITS identifies other erro=
rs and warnings per the following.  Those should also be addressed inc=
luding considering whether obsolete references need changing:
 =

idnits 2.13.01 
 
tmp/draft-drage-sipping-rfc3455bis-11.txt:
 
  Checking boilerplate required by RFC 53=
78 and the IETF Trust (see
  http://trustee.ietf.org/lice=
nse-info):
  --------------------------------=
--------------------------------------------
 
     No issues found here.
 
  Checking nits according to <=
a href=3D"http://www.ietf.org/id-info/1id-guidelines.txt" target=3D"_blank"=
>http://www.ietf.org/id-info/1id-guidelines.txt:
&=
nbsp; ---------------------------------------------------------------------=
-------
 
   =
  No issues found here.
 
  Checking nits according to http://www.ietf.org/id-info/checklist :
  ------------------------------------------------=
----------------------------
 
  ** There are 9 instances of too long lines in the document, the l=
ongest one
     being 20 character=
s in excess of 72.
 
  =
=3D=3D There are 4 instances of lines with non-RFC2606-compliant FQDNs in t=
he
     document.
=

 
  =3D=3D There are 4 instances of lin=
es with non-RFC5735-compliant IPv4 addresses
 &nb=
sp;   in the document.  If these are example addresses, they=
 should be changed.
 
 =

  Miscellaneous warnings:
&=
nbsp; ---------------------------------------------------------------------=
-------
 
  =3D=3D The =
document seems to contain a disclaimer for pre-RFC5378 work, but was
     first submitted on or after 10 Nove=
mber 2008.  The disclaimer is usually
  =
;   necessary only for documents that revise or obsolete older RF=
Cs, and that
     take significant=
 amounts of text from those RFCs.  If you can contact all
     authors of the source material and they a=
re willing to grant the BCP78
    =
 rights to the IETF Trust, you can and should remove the disclaimer. <=
/o:p>
     Otherwise, the disclaimer is =
needed and you can ignore this comment. 
  &=
nbsp;  (See the Legal Provisions document at
     http://trustee.ietf.org/license-info for more informa=
tion.)
 
 
  Checking references for intended status: Informational=

  ---------------------------------------------------=
-------------------------
 
=
  =3D=3D Missing Reference: 'RFC XXXX' is mentioned on line 1667, but =
not defined
 
  -- Look=
s like a reference, but probably isn't: '3' on line 1948
 
  =3D=3D Unused Reference: 'RFC2976' is=
 defined on line 2065, but no explicit
  &nb=
sp;  reference was found in the text
 <=
/o:p>
  =3D=3D Unused Reference: 'RFC3262' is defined on lin=
e 2068, but no explicit
     refer=
ence was found in the text
 
  =3D=3D Unused Reference: 'RFC3311' is defined on line 2075, but no =
explicit
     reference was found =
in the text
 
  =3D=3D =
Unused Reference: 'RFC3428' is defined on line 2081, but no explicit
     reference was found in the text
 
  =3D=3D Unused Referenc=
e: 'RFC3903' is defined on line 2093, but no explicit
=
     reference was found in the text
 
  ** Obsolete normative reference: RFC =
2234 (Obsoleted by RFC 4234)
 
  -- Obsolete informational reference (is this intentional?): RFC 2=
976
     (Obsoleted by RFC 6086)
 
  -- Obsolete informat=
ional reference (is this intentional?): RFC 3265
 =
;    (Obsoleted by RFC 6665)
 
 
     Summ=
ary: 2 errors (**), 0 flaws (~~), 9 warnings (=3D=3D), 3 comments (--).
 
     Run =
idnits with the --verbose option for more detailed information about
     the items above.
While I apologize for not catching these issues earlier, it=
 really is the responsibility of authors to check idnits (beyond what the s=
ubmission tool requires) for their documents.  I routinely run idnits =
before I submit a document as it can also save time when fixing the  n=
its that the submission tool catches:   https://tools.ietf.org/tools/idni=
ts/
 
Regards,
Mary. 
 
 
<=
/div>
 
On Tue, Jan 7, 2014 at 12=
:35 AM, <R.Jess=
ke@telekom.de> wrote:
Hi Mary,
Now a new rev=
ision is available.
&n=
bsp;
Thank you and Best Reg=
ards
 
Roland
 
Von:=
 Mary Barnes [mailto:mary.ietf.barnes@gmail.com] 
Gesendet:<=
/b> Montag, 6. Januar 2014 20:00

<=
b>An: Jesske, Roland
Cc: DISPATCH; Gonzalo Camarillo; Atle Mo=
nrad; Dean Willis
Betreff: Re: PROTO Review: draft-drage-sipping-=
rfc3455bis-09.txt
 
Hi Roland,
 
One final editorial nit below.  If you can s=
pin a revision, then I'll send the PROTO write-up to the AD.
=

 
Thanks,=

Mary. 
 
On Thu, Jan 2, 2014 at 3:29 AM, <R.Jesske@telekom.de> wrote:=

Hi Mary,
I wish you a happy new year 2014. And the best=
 for the next year.
 <=
/span>
I was looking again on my c=
hanges I made due to your proposal in December.
I realized that if I change the SHOULD to MUST we have=
 now a backward compatibility problem.
We are using the P-Associated-URI also over the IMS user interf=
ace which is not encrypted.
So I propose to add some more words.
…
Section =
6.1
…
         <t>An eavesdropper could possibly collect the list of identiti=
es a user is registered.  
    =
   This can have privacy implications. To mitigate this prob=
lem, this extension SHOULD 
    =
;   only be used in a secured environment, where encryption =
of SIP messages is 
    &nbs=
p;  provided either end-to-end or hop-by-hop.  </t>
   
      <t> Since the P-Associated-URI header field value allows to implicitly re=
gister 
      a bundle of =
URIs with one REGISTER Message the impact of security using the P-Associate=
d-URI header field is not higher than  
<=
span lang=3DEN-US style=3D'background:white'>     =
 using single REGISTER messages when registering all identities explic=
it.</t>
[MB] I just have some editorial suggestions for the above:
NEW:  
<=
span lang=3DEN-US style=3D'color:blue'><t> While the P-Associated-URI header field value al=
lows the implicit registration of 
      a bundle of URIs with one R=
EGISTER Message the impact of security using the P-Associated-URI header fi=
eld is no higher than 
=
      using separate REGISTER messages for ea=
ch of the URIs. </t>
[/MB]
 
=

 
 
 
For the P-Called-Party-Id =
the change should be also done like as follows:
 
 &n=
bsp;      <t>An=
 eavesdropper could possibly collect the list of identities a user is regis=
tered.  
       =
This can have privacy implications.  To mitigate this problem, this ex=
tension SHOULD 
      =
; only be used in a secured environment, where encryption of SIP messa=
ges is 
       provided either end-=
to-end or hop-by-hop.  </t>
 
 &nbs=
p;      <t>Norm=
ally within a 3GPP environment the P-Called-Party-ID is not sent towards en=
d users but may be exchanged between carriers where other security mechanis=
ms than SIP encryption are used.  </t>
 
Sorry coming so late.
=

If this is OK for you I will include it to a new=
 version.
 
Thank you and Best Regards
 
Roland
 
Von: Mary Barnes [mailt=
o:mary.ietf=
.barnes@gmail.com] 
Gesendet: Freitag, 27. Dezember 2013 19:4=
5

An: Jesske, Roland
Cc: DISPATCH; Gonzalo Camarillo; Atle Monrad; Dean Willis
Betref=
f: Re: PROTO Review: draft-drage-sipping-rfc3455bis-09.txt
 
Hi Ro=
land,
 
Than=
ks 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 mor=
e detail is provided on security threats and impacts.   I've extracted=
 these few points from previous review comment threads.
 
Thanks,
<=
/div>
Mary.
 
----Previous point  ------------------------------=
--->
- Section 6.1: this needs some tighter wording.  What is meant=
 by "potentially annoying"  for example?  <=
/o:p>
 [RJ] I d=
o not know. This is original text. So I deleted the words.
-
=

[MB] So, you removed that part o=
f the sentence and are left with:
"Th=
is attack should not have any significant impacts."<=
/pre>
 
 =

I don't think that adds any value and just beg=
s the question "what are the insignificant impacts and are there any p=
rivacy concerns"?  Really, it's the next paragraph that provides =
details of the impacts.  I think you could probably remove that senten=
ce altogether and not lose anything. <=
br>
&nbs=
p;
 
 
 
&nb=
sp;
[/MB]=

 
----Previous point ---------------------------------><=
o:p>
 
=

-  Section 6.2: I think you need to be more specific about the =
"nature" that makes this header not of particular concern with re=
gards to security. Does it reveal additional, unique information about an i=
ndividual that isn't available in other headers.  Also, the 2nd paragr=
aph needs some work - maybe something like:

 
 
 
 
 
OLD:<=
/pre>
 
 
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

 
 
 <=
/o:p>
 
 
hop-by-hop.&nbs=
p;
NEW: <=
/o:p>
 
An eavesdropper could possibly collect the list of identities a user is r=
egistered.  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.&nbs=
p;
----=
End previous point ------------------------------<
 
[M=
B]  The suggested change for the first sentence didn't get into the re=
vision.  And, I believe you still need to identify privacy/security im=
plications by addressing whether or not this header reveals any unique info=
rmation about an individual that isn't available in other headers. &nb=
sp; [/MB]
 
 
 <=
/pre>
 
 
&n=
bsp;
On Tue, Dec 3, 2013 at 7:00 AM, <R.Jesske@telekom.de&g=
t; wrote:
Hi Mary,<=
/p>
Thank you for your comments and proposals.
I have now included all comme=
nts and uploaded a new version.
So we can now proceed.
 
Thank you and =
Best Regards
 <=
o:p>
Roland
 
A new version of I-D, draft-drage-sipping-rfc3455bis-10.txt
has been successfully submitted by Roland Jes=
ske and posted to the IETF repository.
 
Filename: &=
nbsp; draft-drage-sipping-rfc3455bis
Revision:   10
Title:           =
 Private Header (P-Header) Extensions to the Session Initiation Protocol (S=
IP) for the 3rd-Generation Partnership Project (3GPP)
=

Creation date:    2013-12-03
Group:     =
;       Individual Submission
Number of pages: 46
URL:         &=
nbsp;   ht=
tp://www.ietf.org/internet-drafts/draft-drage-sipping-rfc3455bis-10.txt
Status:    =
      =
http://datatracker.ietf.org/doc/draft-drage-sipping-rfc3455bis
Htmlized:     &=
nbsp;  http://tools.ietf.org=
/html/draft-drage-sipping-rfc3455bis-10
Diff:         &nbs=
p;  http://www.ietf.=
org/rfcdiff?url2=3Ddraft-drage-sipping-rfc3455bis-10<=
/p>
 
Abstract:
   This=
 document describes a set of private Session Initiation Protocol
   (SIP) header fields (P-header=
s) used by the 3rd-Generation
&n=
bsp;  Partnership Project (3GPP), along with their applicability, whic=
h is
   limited to par=
ticular environments.  The P-header fields are for a=

   variety of purposes within the netwo=
rks 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 Monr=
ad; Dean Willis
Betreff: Re: PROTO Review=
: draft-drage-sipping-rfc3455bis-09.txt
 
Hi Roland,
&=
nbsp;
Thanks for your response.  Addit=
ional comments below [MB].
 
Thanks,
Mary.
 
On Thu, Nov 21, 2013 a=
t 7:21 AM, <R.J=
esske@telekom.de> wrote:
Hi Mary,
Thank yo=
u for your review.
I have a=
dded now your proposals to the draft.
Other comments please see below.
<=
span lang=3DEN-US style=3D'font-size:11.0pt;font-family:"Calibri","sans-ser=
if";color:#1F497D'> 
I hope now everything is OK.
 
Thank you =
and Best Regards
 
Roland
 
=
Von:<=
/span> 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 Revie=
w: draft-drage-sipping-rfc3455bis-09.txt
=
 
In preparation for the PROTO write-up=
, I have reviewed the document in detail.  My detailed review was orig=
inally based on the -08, but I also reviewed the 09 diff.  There are a=
 few errors that have been introduced in the -09 and many of my -08 comment=
s 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 wo=
n'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 will need to do that before I progr=
ess the document unless the authors can point me to another review that has=
 done that.
 
Regards,
Mary.
<=
p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:=
auto'> 
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" i=
s too soft, so I would suggest some minor rewording something like:
OLD:
   The SIP extensions specif=
ied in this document make certain
 
   assumptions regarding network topology, linkage betwee=
n SIP and lower
   layers, and the availabil=
ity of transitive trust.  These assumptions
 =
;  are generally NOT APPLICABLE in the Internet as a whole. 
 =

NEW: 
 
   The SIP extensions specified in this document make certa=
in
   assumptions regarding network topology=
, linkage between SIP and lower
   layers, a=
nd the availability of transitive trust.  These assumptions=

   apply only to private networks and are not appropri=
ate for use in an Internet environment.
 
 
 
 
- Section 3.  This section needs to be updated.  I don'=
t think that 10 year old background is relevant in the current context. &nb=
sp; You should be able to model this after the text in more recent 3GPP P-h=
eader documents, referring 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 establis=
h and tear down multimedia sessions in the
     context of its=
 IP Multimedia Subsystem (IMS). For more information on
     t=
he IMS, a detailed description can be found in 3GPP TS 23.228 . This docume=
nt is an update of RFC3455   which covers the requirements in RFC=
4083 and describes updates and adds private extensions to address those req=
uirements which are needed in for 3GPP Release 11. Each extension, or set o=
f 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 addi=
ng any new headers 
 <=
/p>
    The Third Generation=
 Partnership Project (3GPP) uses SIP as
     the protocol  to establish and t=
ear 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 t=
he 3GPP specification. Note that the requirements for these extensions
     are documen=
ted in RFC 4083.   This document is an update to RF=
C3455. 
    =
 This document updates existing P-header descriptio=
ns 
     to address =
additional requirements which are needed for 3GPP Release 11. <=
o:p>
     Each of the P-headers is de=
scribed in the sections below.
 =
;
[/MB] 
 
<=
div>
- Section 4.=
1. "registered address-of-record" -> "registered SIP addr=
ess-of-record"
- Section 4.1, 3rd par=
agraph.  "Note that, generally speaking," -> "Note t=
hat in standard SIP usage [RFC3261]"
=
- Section 4.1.2.3.  I don't think this is stated properly.  I thi=
nk the intent is that this header is not applicable to proxies, therefore t=
he proxy MUST relay the header field unchanged.  I would suggest rewor=
ding something like:
OLD: 
   This memo doe=
s 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 heade=
r field unchanged.
&nbs=
p;
NE=
W:
 
   This header is not intended to be used by proxi=
es - a proxy does
   not add, read, modify o=
r delete the header field, and therefore any
 &nb=
sp; proxy MUST relay this header field unchanged.
 
 
 
 <=
/pre>
Se=
ction 4.2, 1st paragraph.  The behavior in this sentence is not normat=
ive from a SIP protocol perspective, thus MAY is not appropriate.  I s=
uggest the MAY be changed to "can".   
  =
; The UAS MAY use the information to render different distinctive audiovisu=
al alerting
   tones, depending on the URI u=
sed to receive the invitation to the
   sess=
ion.
Section 4.2.2.2, 2nd paragraph=
.  The behavior in this sentence is not normative from a SIP protocol =
perspective, thus  I suggest the MAY be changed to "can".&nb=
sp;
 
- 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 ch=
anged from the -08.   I don't know what a "normal User Equipment&=
quot; is and the term "User Equipment" is not defined in this spe=
cification.  I think it would be better to say something 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 received this header.&nb=
sp;
 
OLD:
=
   A normal User Equipment has normally no knowledge of the P-Vis=
ited-
   Network-ID when sending the REGISTE=
R.  Therefore user agent clients
   do =
not insert a P-Visited-Network-ID header field in any SIP message.
 
&nb=
sp;
 
NEW: 
   In the context of the network to which t=
he header fields defined in this document apply, a User Agent has no k=
nowledge of the P-Visited-Network-ID when sending the REGISTER request. &nb=
sp;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" -> &qu=
ot;home network can use"

&nbs=
p;
 
 
=
 
 
 
 
- Section 4.=
3.2.2, last paragraph:  
 
 <=
/o:p>
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 forw=
arded. 
 
Section 4.4.2.1, 2nd paragraph:  "MUST trus=
t the proxy" -> "MUST have a trust relationship with the proxy=
" 
 
Section 4.4.2.1, 3rd paragraph:  &qu=
ot;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 inform=
ation 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 hostnames" 
 
&=
nbsp;
 
Section 4.5.2.1 2nd paragraph: "MAY use t=
he contents" -> "can use the contents" <=
o:p>
 =

- Section=
 4.6.2, 3rd paragraph: "MAY use the values" -> "can use t=
he values" 
- Section 4.6.3=
, 3rd paragraph: needs some editorial work.  Maybe the following chang=
e would work: 
 
 
OLD:
 
&nb=
sp;  Depending on the call scenario it is needed to add for each trans=
it
   network either a transit network name =
or a void value.  Nevertheless
   it ca=
n not be guaranteed that all values will appear within the P-Charging-Vecto=
r header field. 
&=
nbsp;
 
NEW: 
 
   Depending on the call scenario,=
 each transit network can add either a transit network name or a void&=
nbsp;   value.  However, it can not be guaranteed that all t=
he values that are added will appear within the P-Charging-Vector header fi=
eld.
 
- =
Section 4.6.3, next to last paragraph: "which needs to be increme=
nted" -> "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 in=
to consideration" mean. Are you talking about limits on the number of =
entries or are you suggesting that the number of void values must be consid=
ered 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 t=
he index has to be incremented by the number of void entries +1.
 
- Section 4.6.4.2: I don't know wha=
t this means:  "A deletion of the elements could appear depending =
on the network policy and trust rules".  Is it just trying to say that along with th=
e adding and modifying in the previous sentence that the elements can also =
be deleted by the proxy? 
 
[RJ] Yes, I have change=
d the text:
Procedures described within 4.6.2.2 apply. A transit-ioi MAY be
  =
;         added or modified by a pr=
oxy. A deletion of the transit-ioi or a entry within the tranist-ioi could<=
/span>
 &=
nbsp;         appear depending on t=
he network policy and trust rules. This is
           =
also valid by replacing the transit-ioi with a void value.
 
 
 
&nb=
sp;
 <=
/o:p>
 
- 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 verbally state what messages these headers can app=
ear 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 INVIT=
E, OPTIONS, PUBLISH,SUBSCRIBE, MESSAGE methods and all responses, P-Visited=
-Network-ID can appear in all SIP methods except ACK, BYE and CANCEL and al=
l 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 CAN=
CEL and the P-Charging-Function-Addresses can appear in all SIP methods exe=
pt 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-Ass=
ociated-URI header field can appear....2xx responses.   The P-Called-P=
arty-ID header field....
<=
div>
 
<=
pre> 
- Section 6.=
1: this needs some tighter wording.  What is meant by "potentiall=
y annoying"  for example?  
 
[RJ] I do n=
ot know. This is original text. So I deleted the words.
 
- =
Section 6.2: I think you need to be more specific about the "nature&qu=
ot; that makes this header not of particular concern with regards to securi=
ty. 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:
 <=
/pre>
OLD:
An eavesdropper may collect the list of identities=
 a user is registered.  This may have privacy implications.  To m=
itigate this problem, this extension SHOULD only be used in a secured envir=
onment, where encryption of SIP messages is provided either end-to-end or
 
 
 
 
 
 
 
h=
op-by-hop. 
 =
  
 
NEW: 
 
 An =
eavesdropper could possibly collect the list of identities a user is regist=
ered.  This can have privacy implications.  To mitigate this prob=
lem, this extension MUST only be used in a secured environment, where encry=
ption of SIP messages is provided either end-to-end or hop-by-hop. 
<=
p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:=
auto'> 
[MB]  So, I think the fir=
st sentence is trying to say: "An eavesd=
ropper could possibly collect the list of identities a user has registered.=
"
or  "An eavesdropper could possibly collect the list of identiti=
es registered by a user." 
[/MB]  
- Section 6.4, 
--3rd paragr=
aph: "should not" -> "MUST NOT" 
 
-- 7th paragraph:  &quo=
t;SHOULD NOT be sent" -> "MUST NOT be sent" <=
o:p>
 
=

 
 
 
 
-- 8th paragraph: "SHOULD NOT send sensitive informati=
on" -> "MUST NOT send sensitive information"<=
/o:p>
 
=
 
-- 9th paragraph: "is required to delete" -> "is REQUIR=
ED to delete" 
 
-- 10th paragraph:  How does a network ensure the informati=
on 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 scope 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 infor=
mation.  What =
are the implications if the information is used and it's not valid?  <=
/span>
[RJ] Yes I did some c=
hanges as follows.
 
&nbs=
p;       <t>A proxy receiving a message=
 containing the P-Access-Network-Info
       header =
field from a non-trusted entity is not able to guarantee the
       validi=
ty of the contents. Thus this content SHOULD be deleted based on local poli=
cy.</t>
 
- Section 9, item 2.  I think you need =
to add this text with regards to the recommendation to use RFC 4244 (bis) t=
o the body of this document and include a real reference.=

 
[RJ] OK done. I let the reference RFC4244 since =
3GPP uses currently only RFC4244. 
Replaced following text:
With section 9.2
=
       <t>Requirements for a more gener=
al solution are proposed in <xref
         target=3D"R=
FC4244"></xref>. 3GPP will continue to use the
       =
;  P-Called-Party-ID header field even though RFC 4244 <xref=

     &nb=
sp;   target=3D"RFC4244"></xref> has now been =
published.</t>
&nbs=
p;
I think the text in Sect=
ion 9.2 is better.
Nits:
 
 <=
o:p>
 
 
- Section =
4.1, 2nd paragraph.  "has associated to an address-of-record"=
; -> "has associated with an address-of-record"
- Section 4.1.2.2, 2n=
d paragraph, "In case" -> "If",  "shall no=
t" -> 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: &q=
uot;the REGISTRAR" -> "at the REGISTRAR"
 
Section 4.2.2.1, 3rd paragraph:  "there must also be a trans=
itive trust" ->  "there MUST also be a transitive trust&q=
uot; 
 
Section 4.6, 2nd paragraph: "includes,=
 includes but is not limited to" -> "includes, but is not limi=
ted to," 
 
Section 4.6.2.2, 1st paragraph: &q=
uot;one ore more" -> "one or more" 
 
 
 
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 al=
l comments coming from the expert review done by Dean Willis. Also an edito=
rial cleanup was made.

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

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

Thank you and Best Re=
gards

Roland


-----Urspr=FCngliche Nachricht-----
Von: =
internet-draf=
ts@ietf.org [mailto:internet-drafts@ietf.org]
Gesendet: Dienstag, 8. Oktober=
 2013 13:40
An: Christer Holmberg; Keith Drage; Jesske, Roland
Betref=
f: New Version Notification for draft-drage-sipping-rfc3455bis-09.txt

A new version of I-D, draft-drage-sipping-rfc3455bis-09.txt
has be=
en 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 Initiatio=
n Protocol (SIP) for the 3rd-Generation Partnership Project (3GPP)
Creat=
ion date:   2013-10-08
Group:           In=
dividual Submission
Number of pages: 47
URL:       &nb=
sp;     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 Se=
ssion Initiation Protocol
   (SIP) header fields (P-headers) u=
sed by the 3rd-Generation
   Partnership Project (3GPP), along=
 with their applicability, which is
   limited to particular e=
nvironments.  The P-header fields are for a
   variety of=
 purposes within the networks that the partners use,
   includ=
ing charging and information about the networks a call
   trav=
erses.




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

The IETF Secretariat
  -
 
 
 
<=
/div>
 
=

 
 
=

------------------------------------------------=
---------------------
This transmission (including any attachments) may =
contain confidential information, privileged material (including material p=
rotected by the solicitor-client or other applicable privileges), or consti=
tute non-public information. Any use of this information by anyone other th=
an the intended recipient is prohibited. If you have received this transmis=
sion in error, please immediately reply to the sender and delete this infor=
mation from your system. Use, dissemination, distribution, or reproduction =
of this transmission by unintended recipients is not authorized and may be =
unlawful.