From sm@resistor.net Tue Oct 1 02:57:33 2013 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3907221F92B9 for ; Tue, 1 Oct 2013 02:57:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.631 X-Spam-Level: X-Spam-Status: No, score=-102.631 tagged_above=-999 required=5 tests=[AWL=-0.032, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id roKVaPhbMnjr for ; Tue, 1 Oct 2013 02:57:31 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BFE821F90FD for ; Tue, 1 Oct 2013 02:57:12 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r919v2xS017737; Tue, 1 Oct 2013 02:57:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1380621427; bh=92V43jO4arJT8VvsCGIDndBSMlgN1HPYiFq4kcy2Jhc=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=IN4lT5Ogu6u/mINlAfFZxJjCPX7me6Cy4Vg5NuBnjaadpjYf83J77KJMoNIETON33 SEun19bqi1d0YHFSotrIiGIOT2B+R70DKMhmUQl18NOFCRQDfnS3sTGv1tVRI6RAgs SKGhI3GDG19MenBd9niZpfAya03DgjdbGjJ1F62E= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1380621427; i=@resistor.net; bh=92V43jO4arJT8VvsCGIDndBSMlgN1HPYiFq4kcy2Jhc=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=4r47/IMfaq4mv54Om+fQktrOtrkkbA6bkLcD0/+YgAhPcMKJFxwGLtTJIZ7Yfs0X7 pUuoZFkT3CkXaep2JLeyqDLcxkip8VSsP4jrbszip1HpX78nfXacoLd3fqjqnrDfoh AuioqgEXyzWXk62ClJVCQTdaZJDoCLbMNLQhZlx8= Message-Id: <6.2.5.6.2.20131001021008.0afd1f90@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 01 Oct 2013 02:25:02 -0700 To: "DRAGE, Keith (Keith)" , Gonzalo Camarillo From: SM In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B0AD63E@FR712WXCHMBA11.zeu. alcatel-lucent.com> References: <20130927160805.11230.12046.idtracker@ietfa.amsl.com> <5248289C.6070003@ericsson.com> <6.2.5.6.2.20130929064034.0c3bda30@resistor.net> <949EF20990823C4C85C18D59AA11AD8B0AD63E@FR712WXCHMBA11.zeu.alcatel-lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mailman-Approved-At: Tue, 01 Oct 2013 03:01:33 -0700 Cc: insipid@ietf.org Subject: Re: [Insipid] WG Review: INtermediary-safe SIP session ID (insipid) X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2013 09:57:33 -0000 Hi Keith, At 18:11 30-09-2013, DRAGE, Keith (Keith) wrote: >This seems to be more a comment on the existing charter rather than >the additional new bits. Ok. >In that respect, comments against that might be better made against >the requirements document that is with IESG at the moment. > >https://datatracker.ietf.org/doc/draft-ietf-insipid-session-id-reqts/ > >In regard to the extended charter, my understanding at least is that >it adds nothing to the correlation aspects. What gets added is an >extra indicator that goes with the session-id as defined, and >indicates the the network entities involved that they should create >a log of the information contained in all messages with this session i-d. > >How those logs are collected together and analysed does not form >part of the charter. It is certainly not expected that those logs >would be available to an end user or indeed to another operator, as >part of any work performed under this charter. That does not >preclude the indicator being passed between operators or to the end >user, rather than removed, but I am not sure I see a privacy concern with that. I said okay to the Responsible Area Director based on the following in his message ( http://www.ietf.org/mail-archive/web/insipid/current/msg00796.html ): "Regarding privacy, the WG will of course consider privacy whenever it is relevant. The charter just identifies certain areas explicitly because it is very clear that they will have privacy implications." My reading of the above message is that the working group will only consider privacy within the scope mentioned at http://www.ietf.org/mail-archive/web/insipid/current/msg00798.html In my humble opinion the scope is different from what the Responsible Area Director mentioned. Regards, -sm From paulej@packetizer.com Wed Oct 2 02:59:43 2013 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94D5321E80F1 for ; Wed, 2 Oct 2013 02:59:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bHi+k1GgBY9w for ; Wed, 2 Oct 2013 02:59:32 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 73E9311E8192 for ; Wed, 2 Oct 2013 02:59:32 -0700 (PDT) Received: from [192.168.1.20] (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id r929xSqK017883 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 2 Oct 2013 05:59:29 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1380707969; bh=9Xtavb/EA40WxmaTEESxVR6eBc6sENVohgr4rGhDHkQ=; h=From:To:Subject:Date:Content-Type:In-Reply-To:Message-Id: Mime-Version:Reply-To; b=Jcbw87IwKU6Njmb8OvsRIdr1SCeg2Cjw7gvd1Bf353+onTlBsgjK9kZNO4fi/uWFu ysXdB+W+ndBqDP8b8t8pVQ81o1nQg3UpeK06dEw0qLTQlkJ4Ob+2OemXCltm/+wF9r fQ0RbNmjlbq+qphL0RHIN6geuC8w27nR9yLNIwQ8= From: "Paul E. Jones" To: "Christer Holmberg" , "Paul Kyzivat" , "insipid@ietf.org" Date: Wed, 02 Oct 2013 09:59:49 +0000 Content-Type: multipart/alternative; boundary="------=_MBBB13E2E8-C599-488F-BEAA-089072BDD7EE" In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C4AEA97@ESESSMB209.ericsson.se> Message-Id: Mime-Version: 1.0 User-Agent: eM_Client/5.0.18661.0 Subject: Re: [Insipid] Addressing security-related comments / requirements spec X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "Paul E. Jones" List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Oct 2013 09:59:43 -0000 --------=_MBBB13E2E8-C599-488F-BEAA-089072BDD7EE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; format=flowed; charset=utf-8 Christer, I would expect use of the Session ID to be broader than just debugging. = =20 I mentioned at least one application previously, such as associating=20 call signaling and media flows. This may still fall into the category=20 of troubleshooting, but there may be uses that are beyond that. So, I=20 do not want to assume that once we complete the work, it will only be=20 used for troubleshooting. Even in that limited use case, we still want to ensure that it did not=20 change end-to-end. My thought was that over any untrusted link, we=20 would utilize TLS. However, I did not think we need to spell that out=20 in the requirements document. That said, Vijay definitely felt there=20 was more we needed to say. Do others agree that we need to say more in the Security Considerations=20 section or shall just publish the document as-is. I'll note his=20 comments are non-blocking. Paul ------ Original Message ------ From: "Christer Holmberg" To: "Paul Kyzivat" ; "insipid@ietf.org"=20 Sent: 9/28/2013 2:13:59 PM Subject: Re: [Insipid] Addressing security-related comments /=20 requirements spec >Hi, > > > >If it's used for trouble shooting, the only harm that someone can do by= =20 >removing/modifying the header field is to make the trouble shooting a=20 >little more difficult. I don't see any security threat in that. > > > >Regards, > > > >Christer > > > > > >--------------------------------------------------------------------------= ------ >From:insipid-bounces@ietf.org [insipid-bounces@ietf.org] on behalf of=20 >Paul Kyzivat [pkyzivat@alum.mit.edu] >Sent: Saturday, 28 September 2013 7:04 PM >To:insipid@ietf.org >Subject: Re: [Insipid] Addressing security-related comments /=20 >requirements spec > >On 9/27/13 11:38 AM, Paul E. Jones wrote: > > Paul, > > > > The impact of an attack depends on the use of the Session ID. If=20 >it's > > used only for troubleshooting a call, then it hinders the ability to > > troubleshoot calls. If someone were to use this to correlate call=20 >legs > > in an effort to do billing (which is explicitly forbidden in the > > solution spec), then the operator would have a horrible billing mess= =20 >on > > their hands. > > > > I expected the solution spec would have more in terms of security > > considerations, since we can speak more concretely. We should make > > decisions about whether we want to mandate use of TLS, how trust=20 >might > > be established, etc. We spell out procedures so that we minimize=20 >the > > probability that two devices will have the same UUID, for example. =20 >This > > meets part of the requirements, but does not fully address the=20 >security > > issues. > > > > In any case, we do have some known threats (e.g., spoofing, re-play,= =20 >bad > > implementation, malicious SBCs). We know the impact of any=20 >successful > > attack (basically rendering it useless, misleading applications that= =20 >use > > it, etc). And so that's why we have the language in the requirements > > document now that requires a random, long value, verification by > > applications using the session identifier, secure transport, > > authentication, etc. I thought what we had written was sufficient=20 >for a > > requirements document, but Vijay disagreed. > > > > So, what do we add? > >I don't know. > > > Paul > > > > ------ Original Message ------ > > From: "Paul Kyzivat" > > To: insipid@ietf.org > > Sent: 9/26/2013 11:23:07 AM > > Subject: Re: [Insipid] Addressing security-related comments / > > requirements spec > >> ISTM that what is lacking is a threat analysis. What bad things=20 >could > >> happen if an adversary was able to change/remove/add a Session-ID > >> header in a malicious way? Maybe nothing sufficiently bad can happen > >> to justify anyone bothering to do so. > >> > >> Thanks, > >> Paul K > >> > >> On 9/25/13 9:58 PM, Paul E. Jones wrote: > >>> Folks, > >>> Vijay Gurbani provided feedback suggesting some improvements might= =20 >be > >>> needed in the requirements document. See this message: > >>>=20 >http://www.ietf.org/mail-archive/web/apps-discuss/current/msg10419.html. > >>> I'm > >>> referring specifically to his comment on Section 7. > >>> We had a couple of follow-up messages that you should probably also > >>> read: > >>>=20 >http://www.ietf.org/mail-archive/web/apps-discuss/current/msg10437.html > >>>=20 >http://www.ietf.org/mail-archive/web/apps-discuss/current/msg10507.html > >>> After reviewing his comments, I would like to ask the group what,=20 >if > >>> any, changes the group feels we should make to the requirements > >>> document. > >>> Thanks! > >>> Paul > >>> > >>> > >>> _______________________________________________ > >>> insipid mailing list > >>> insipid@ietf.org > >>> https://www.ietf.org/mailman/listinfo/insipid > >>> > >> > >> _______________________________________________ > >> insipid mailing list > >> insipid@ietf.org > >> https://www.ietf.org/mailman/listinfo/insipid > > > > _______________________________________________ > > insipid mailing list > > insipid@ietf.org > > https://www.ietf.org/mailman/listinfo/insipid > > > >_______________________________________________ >insipid mailing list >insipid@ietf.org >https://www.ietf.org/mailman/listinfo/insipid --------=_MBBB13E2E8-C599-488F-BEAA-089072BDD7EE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Christer,
 
I would expect use of the Session ID to be broader than just debu= gging.  I mentioned at least one application previously, = such as associating call signaling and media flows.  This may still= fall into the category of troubleshooting, but there may be uses that are= beyond that.  So, I do not want to assume that once we complete the= work, it will only be used for troubleshooting.
 
Even in that limited use case, we still want to ensure that it did = not change end-to-end.  My thought was that over any untrusted link,= we would utilize TLS.  However, I did not think we need to spell that= out in the requirements document.  That said, Vijay definitely felt= there was more we needed to say.
 
Do others agree that we need to say more in the Security Consideration= s section or shall just publish the document as-is.  I'll note his = comments are non-blocking.
 
Paul
 
------ Original Message ------
From: "Christer Holmberg" <christer.holmberg@ericsson.com>
To: "Paul Kyzivat" <pkyziv= at@alum.mit.edu>; "insipid@ietf.org" <insipid@ietf.org>
Sent: 9/28/2013 2:13:59 PM
Subject: Re: [Insipid] Addressing security-related comments / requirem= ents spec

Hi,

 

If it's used for trouble shooting, the only harm that someone can do = by removing/modifying the header field is to make the trouble shooting a= little more difficult. I don't see any security threat in that.

 

Regards,

 

Christer

 

 

F= rom: insipid-bounces@ietf.o= rg [insipid-bounces@ietf.or= g] on behalf of Paul Kyzivat [= pkyzivat@alum.mit.edu]
Sent: Saturday, 28 September 2013 7:04= PM
To: insipid@ietf.org<= BR>Subject: Re: [Insipid] Addressing security-related comments / = requirements spec

On 9/27/13 11:38 AM, Paul E. Jones wrote:
>= Paul,
>
> The impact of an attack depends on the use of the= Session ID.  If it's
> used only for troubleshooting a call,= then it hinders the ability to
> troubleshoot calls.  If someon= e were to use this to correlate call legs
> in an effort to do billin= g (which is explicitly forbidden in the
> solution spec), then the= operator would have a horrible billing mess on
> their hands.
>= ;
> I expected the solution spec would have more in terms of security=
> considerations, since we can speak more concretely.  We shoul= d make
> decisions about whether we want to mandate use of TLS, how= trust might
> be established, etc.   We spell out procedur= es so that we minimize the
> probability that two devices will have= the same UUID, for example.  This
> meets part of the requireme= nts, but does not fully address the security
> issues.
>
>= ; In any case, we do have some known threats (e.g., spoofing, re-play, bad<= BR>> implementation, malicious SBCs).  We know the impact of any= successful
> attack (basically rendering it useless, misleading appl= ications that use
> it, etc).  And so that's why we have the = language in the requirements
> document now that requires a random,= long value, verification by
> applications using the session identif= ier, secure transport,
> authentication, etc.  I thought what= we had written was sufficient for a
> requirements document, but = Vijay disagreed.
>
> So, what do we add?

I don't know.
> Paul
>
> ------ Original Message ------
> From= : "Paul Kyzivat" <pkyzivat@alum= .mit.edu>
> To: insipid@ie= tf.org
> Sent: 9/26/2013 11:23:07 AM
> Subject: Re: [Insipi= d] Addressing security-related comments /
> requirements spec
>= > ISTM that what is lacking is a threat analysis. What bad things could<= BR>>> happen if an adversary was able to change/remove/add a Session-= ID
>> header in a malicious way? Maybe nothing sufficiently bad= can happen
>> to justify anyone bothering to do so.
>>>>  Thanks,
>>  Paul K
>>
>>= On 9/25/13 9:58 PM, Paul E. Jones wrote:
>>> Folks,
>>= ;> Vijay Gurbani provided feedback suggesting some improvements might= be
>>> needed in the requirements document. See this message:<= BR>>>> http://www.ietf.org/mail-archive/web/apps-discuss/= current/msg10419.html.
>>> I'm
>>> referring= specifically to his comment on Section 7.
>>> We had a couple= of follow-up messages that you should probably also
>>> read:<= BR>>>> http://www.ietf.org/mail-archive/web/apps-discuss/= current/msg10437.html
>>> http://www.ietf.org/mail= -archive/web/apps-discuss/current/msg10507.html
>>> After= reviewing his comments, I would like to ask the group what, if
>>= > any, changes the group feels we should make to the requirements
>= ;>> document.
>>> Thanks!
>>> Paul
>>= ;>
>>>
>>> _____________________________________= __________
>>> insipid mailing list
>>> insipid@ietf.org
>>> https://www.ietf.org/mailma= n/listinfo/insipid
>>>
>>
>> ____________= ___________________________________
>> insipid mailing list
>= ;> insipid@ietf.org
>>= https://www.ietf= .org/mailman/listinfo/insipid
>
> _________________________= ______________________
> insipid mailing list
> insipid@ietf.org
> https://www.ietf.org/mailman/listinfo/insi= pid
>

_______________________________________________
i= nsipid mailing list
insipid@ietf.org=
https://w= ww.ietf.org/mailman/listinfo/insipid
--------=_MBBB13E2E8-C599-488F-BEAA-089072BDD7EE-- From christer.holmberg@ericsson.com Wed Oct 2 03:46:49 2013 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 206BC21F9BA4 for ; Wed, 2 Oct 2013 03:46:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.336 X-Spam-Level: X-Spam-Status: No, score=-5.336 tagged_above=-999 required=5 tests=[AWL=0.912, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yDCcwfltkTX1 for ; Wed, 2 Oct 2013 03:46:34 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 81B6721F8EEA for ; Wed, 2 Oct 2013 03:46:30 -0700 (PDT) X-AuditID: c1b4fb2d-b7f738e000003ee3-8b-524bf9818f1d Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 0D.66.16099.189FB425; Wed, 2 Oct 2013 12:46:26 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.146]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.02.0328.009; Wed, 2 Oct 2013 12:46:25 +0200 From: Christer Holmberg To: "Paul E. Jones" , Paul Kyzivat , "insipid@ietf.org" Thread-Topic: [Insipid] Addressing security-related comments / requirements spec Thread-Index: AQHOvGRrw2ZRqjhEmEqYd2mSXHdWOZnbUrGAgAW/QoCAAC2bEA== Date: Wed, 2 Oct 2013 10:46:24 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4B1EF8@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C4AEA97@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C4B1EF8ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrPLMWRmVeSWpSXmKPExsUyM+JvrW7TT+8gg4tL2Szm33/GZHH+wgYm ixUbDrA6MHv8ff+ByWPJkp9MHg37jrIHMEdx2aSk5mSWpRbp2yVwZRw74FFw5ytjxdtJSQ2M C94zdjFyckgImEjsnnmSFcIWk7hwbz1bFyMXh5DAYUaJ7kv9rBDOYkaJPW8+M3UxcnCwCVhI dP/TBmkQEaiSOLFhM9ggYYFAiRkPupkg4kESH/vXQtlOEp0325lBWlkEVCRmfogBCfMK+Eq0 /14ANlFIoF7ia6cWSJhTwEbi8fMbYBMZgc75fmoN2BRmAXGJW0/mM0GcKSCxZM95ZghbVOLl 439Q5ytKfHy1jxGiPl9i3fmDzBCrBCVOznzCMoFRZBaSUbOQlM1CUjYL6CJmAU2J9bv0IUoU JaZ0P2SHsDUkWufMZUcWX8DIvoqRPTcxMye93HATIzCSDm75rbuD8dQ5kUOM0hwsSuK8H946 BwkJpCeWpGanphakFsUXleakFh9iZOLglGpgNDeQyDmTn58RZ3eS0Yhz21zVPvYryWFfxHcn Z0z6adOrzjX5+s1J7zS+RZeUTM64emTNxzccJk3TygoOLViqrtMUGf6cPTt27r1HnAGd75Mv se5/3Jh6zU96uVhIT9TlXb2v70dHzYvdc2SSJf/a5NNsYpsrK15tcVbZNuMu0+wupi8i32e1 KrEUZyQaajEXFScCAPny1TpyAgAA Subject: Re: [Insipid] Addressing security-related comments / requirements spec X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Oct 2013 10:46:49 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C4B1EF8ESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCldlbGwsIHRoZW4gSSBndWVzcyB0aGUgc2VjdXJpdHkgYXNwZWN0cyBkZXBlbmRzIG9u IHdoYXQgdGhlIGhlYWRlciBmaWVsZCBpcyBhY3R1YWxseSB1c2VkIGZvci4gSSBzZWUgbm8gcmVh c29uIHRvIGUuZy4gbWFuZGF0ZSBlbmNyeXB0aW9uIGluIHB1cmUgdHJvdWJsZSBzaG9vdGluZyBz Y2VuYXJpb3MuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCkZyb206IFBhdWwgRS4gSm9uZXMg W21haWx0bzpwYXVsZWpAcGFja2V0aXplci5jb21dDQpTZW50OiAyLiBsb2tha3V1dGEgMjAxMyAx MzowMA0KVG86IENocmlzdGVyIEhvbG1iZXJnOyBQYXVsIEt5eml2YXQ7IGluc2lwaWRAaWV0Zi5v cmcNClN1YmplY3Q6IFJlOiBbSW5zaXBpZF0gQWRkcmVzc2luZyBzZWN1cml0eS1yZWxhdGVkIGNv bW1lbnRzIC8gcmVxdWlyZW1lbnRzIHNwZWMNCg0KQ2hyaXN0ZXIsDQoNCkkgd291bGQgZXhwZWN0 IHVzZSBvZiB0aGUgU2Vzc2lvbiBJRCB0byBiZSBicm9hZGVyIHRoYW4ganVzdCBkZWJ1Z2dpbmcu ICBJIG1lbnRpb25lZCBhdCBsZWFzdCBvbmUgYXBwbGljYXRpb24gcHJldmlvdXNseSwgc3VjaCBh cyBhc3NvY2lhdGluZyBjYWxsIHNpZ25hbGluZyBhbmQgbWVkaWEgZmxvd3MuICBUaGlzIG1heSBz dGlsbCBmYWxsIGludG8gdGhlIGNhdGVnb3J5IG9mIHRyb3VibGVzaG9vdGluZywgYnV0IHRoZXJl IG1heSBiZSB1c2VzIHRoYXQgYXJlIGJleW9uZCB0aGF0LiAgU28sIEkgZG8gbm90IHdhbnQgdG8g YXNzdW1lIHRoYXQgb25jZSB3ZSBjb21wbGV0ZSB0aGUgd29yaywgaXQgd2lsbCBvbmx5IGJlIHVz ZWQgZm9yIHRyb3VibGVzaG9vdGluZy4NCg0KRXZlbiBpbiB0aGF0IGxpbWl0ZWQgdXNlIGNhc2Us IHdlIHN0aWxsIHdhbnQgdG8gZW5zdXJlIHRoYXQgaXQgZGlkIG5vdCBjaGFuZ2UgZW5kLXRvLWVu ZC4gIE15IHRob3VnaHQgd2FzIHRoYXQgb3ZlciBhbnkgdW50cnVzdGVkIGxpbmssIHdlIHdvdWxk IHV0aWxpemUgVExTLiAgSG93ZXZlciwgSSBkaWQgbm90IHRoaW5rIHdlIG5lZWQgdG8gc3BlbGwg dGhhdCBvdXQgaW4gdGhlIHJlcXVpcmVtZW50cyBkb2N1bWVudC4gIFRoYXQgc2FpZCwgVmlqYXkg ZGVmaW5pdGVseSBmZWx0IHRoZXJlIHdhcyBtb3JlIHdlIG5lZWRlZCB0byBzYXkuDQoNCkRvIG90 aGVycyBhZ3JlZSB0aGF0IHdlIG5lZWQgdG8gc2F5IG1vcmUgaW4gdGhlIFNlY3VyaXR5IENvbnNp ZGVyYXRpb25zIHNlY3Rpb24gb3Igc2hhbGwganVzdCBwdWJsaXNoIHRoZSBkb2N1bWVudCBhcy1p cy4gIEknbGwgbm90ZSBoaXMgY29tbWVudHMgYXJlIG5vbi1ibG9ja2luZy4NCg0KUGF1bA0KDQot LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLS0NCkZyb206ICJDaHJpc3RlciBIb2xtYmVyZyIg PGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTxtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdA ZXJpY3Nzb24uY29tPj4NClRvOiAiUGF1bCBLeXppdmF0IiA8cGt5eml2YXRAYWx1bS5taXQuZWR1 PG1haWx0bzpwa3l6aXZhdEBhbHVtLm1pdC5lZHU+PjsgImluc2lwaWRAaWV0Zi5vcmc8bWFpbHRv Omluc2lwaWRAaWV0Zi5vcmc+IiA8aW5zaXBpZEBpZXRmLm9yZzxtYWlsdG86aW5zaXBpZEBpZXRm Lm9yZz4+DQpTZW50OiA5LzI4LzIwMTMgMjoxMzo1OSBQTQ0KU3ViamVjdDogUmU6IFtJbnNpcGlk XSBBZGRyZXNzaW5nIHNlY3VyaXR5LXJlbGF0ZWQgY29tbWVudHMgLyByZXF1aXJlbWVudHMgc3Bl Yw0KSGksDQoNCklmIGl0J3MgdXNlZCBmb3IgdHJvdWJsZSBzaG9vdGluZywgdGhlIG9ubHkgaGFy bSB0aGF0IHNvbWVvbmUgY2FuIGRvIGJ5IHJlbW92aW5nL21vZGlmeWluZyB0aGUgaGVhZGVyIGZp ZWxkIGlzIHRvIG1ha2UgdGhlIHRyb3VibGUgc2hvb3RpbmcgYSBsaXR0bGUgbW9yZSBkaWZmaWN1 bHQuIEkgZG9uJ3Qgc2VlIGFueSBzZWN1cml0eSB0aHJlYXQgaW4gdGhhdC4NCg0KUmVnYXJkcywN Cg0KQ2hyaXN0ZXINCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJvbTog aW5zaXBpZC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzppbnNpcGlkLWJvdW5jZXNAaWV0Zi5vcmc+ IFtpbnNpcGlkLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmluc2lwaWQtYm91bmNlc0BpZXRmLm9y Zz5dIG9uIGJlaGFsZiBvZiBQYXVsIEt5eml2YXQgW3BreXppdmF0QGFsdW0ubWl0LmVkdTxtYWls dG86cGt5eml2YXRAYWx1bS5taXQuZWR1Pl0NClNlbnQ6IFNhdHVyZGF5LCAyOCBTZXB0ZW1iZXIg MjAxMyA3OjA0IFBNDQpUbzogaW5zaXBpZEBpZXRmLm9yZzxtYWlsdG86aW5zaXBpZEBpZXRmLm9y Zz4NClN1YmplY3Q6IFJlOiBbSW5zaXBpZF0gQWRkcmVzc2luZyBzZWN1cml0eS1yZWxhdGVkIGNv bW1lbnRzIC8gcmVxdWlyZW1lbnRzIHNwZWMNCk9uIDkvMjcvMTMgMTE6MzggQU0sIFBhdWwgRS4g Sm9uZXMgd3JvdGU6DQo+IFBhdWwsDQo+DQo+IFRoZSBpbXBhY3Qgb2YgYW4gYXR0YWNrIGRlcGVu ZHMgb24gdGhlIHVzZSBvZiB0aGUgU2Vzc2lvbiBJRC4gIElmIGl0J3MNCj4gdXNlZCBvbmx5IGZv ciB0cm91Ymxlc2hvb3RpbmcgYSBjYWxsLCB0aGVuIGl0IGhpbmRlcnMgdGhlIGFiaWxpdHkgdG8N Cj4gdHJvdWJsZXNob290IGNhbGxzLiAgSWYgc29tZW9uZSB3ZXJlIHRvIHVzZSB0aGlzIHRvIGNv cnJlbGF0ZSBjYWxsIGxlZ3MNCj4gaW4gYW4gZWZmb3J0IHRvIGRvIGJpbGxpbmcgKHdoaWNoIGlz IGV4cGxpY2l0bHkgZm9yYmlkZGVuIGluIHRoZQ0KPiBzb2x1dGlvbiBzcGVjKSwgdGhlbiB0aGUg b3BlcmF0b3Igd291bGQgaGF2ZSBhIGhvcnJpYmxlIGJpbGxpbmcgbWVzcyBvbg0KPiB0aGVpciBo YW5kcy4NCj4NCj4gSSBleHBlY3RlZCB0aGUgc29sdXRpb24gc3BlYyB3b3VsZCBoYXZlIG1vcmUg aW4gdGVybXMgb2Ygc2VjdXJpdHkNCj4gY29uc2lkZXJhdGlvbnMsIHNpbmNlIHdlIGNhbiBzcGVh ayBtb3JlIGNvbmNyZXRlbHkuICBXZSBzaG91bGQgbWFrZQ0KPiBkZWNpc2lvbnMgYWJvdXQgd2hl dGhlciB3ZSB3YW50IHRvIG1hbmRhdGUgdXNlIG9mIFRMUywgaG93IHRydXN0IG1pZ2h0DQo+IGJl IGVzdGFibGlzaGVkLCBldGMuICAgV2Ugc3BlbGwgb3V0IHByb2NlZHVyZXMgc28gdGhhdCB3ZSBt aW5pbWl6ZSB0aGUNCj4gcHJvYmFiaWxpdHkgdGhhdCB0d28gZGV2aWNlcyB3aWxsIGhhdmUgdGhl IHNhbWUgVVVJRCwgZm9yIGV4YW1wbGUuICBUaGlzDQo+IG1lZXRzIHBhcnQgb2YgdGhlIHJlcXVp cmVtZW50cywgYnV0IGRvZXMgbm90IGZ1bGx5IGFkZHJlc3MgdGhlIHNlY3VyaXR5DQo+IGlzc3Vl cy4NCj4NCj4gSW4gYW55IGNhc2UsIHdlIGRvIGhhdmUgc29tZSBrbm93biB0aHJlYXRzIChlLmcu LCBzcG9vZmluZywgcmUtcGxheSwgYmFkDQo+IGltcGxlbWVudGF0aW9uLCBtYWxpY2lvdXMgU0JD cykuICBXZSBrbm93IHRoZSBpbXBhY3Qgb2YgYW55IHN1Y2Nlc3NmdWwNCj4gYXR0YWNrIChiYXNp Y2FsbHkgcmVuZGVyaW5nIGl0IHVzZWxlc3MsIG1pc2xlYWRpbmcgYXBwbGljYXRpb25zIHRoYXQg dXNlDQo+IGl0LCBldGMpLiAgQW5kIHNvIHRoYXQncyB3aHkgd2UgaGF2ZSB0aGUgbGFuZ3VhZ2Ug aW4gdGhlIHJlcXVpcmVtZW50cw0KPiBkb2N1bWVudCBub3cgdGhhdCByZXF1aXJlcyBhIHJhbmRv bSwgbG9uZyB2YWx1ZSwgdmVyaWZpY2F0aW9uIGJ5DQo+IGFwcGxpY2F0aW9ucyB1c2luZyB0aGUg c2Vzc2lvbiBpZGVudGlmaWVyLCBzZWN1cmUgdHJhbnNwb3J0LA0KPiBhdXRoZW50aWNhdGlvbiwg ZXRjLiAgSSB0aG91Z2h0IHdoYXQgd2UgaGFkIHdyaXR0ZW4gd2FzIHN1ZmZpY2llbnQgZm9yIGEN Cj4gcmVxdWlyZW1lbnRzIGRvY3VtZW50LCBidXQgVmlqYXkgZGlzYWdyZWVkLg0KPg0KPiBTbywg d2hhdCBkbyB3ZSBhZGQ/DQoNCkkgZG9uJ3Qga25vdy4NCg0KPiBQYXVsDQo+DQo+IC0tLS0tLSBP cmlnaW5hbCBNZXNzYWdlIC0tLS0tLQ0KPiBGcm9tOiAiUGF1bCBLeXppdmF0IiA8cGt5eml2YXRA YWx1bS5taXQuZWR1PG1haWx0bzpwa3l6aXZhdEBhbHVtLm1pdC5lZHU+Pg0KPiBUbzogaW5zaXBp ZEBpZXRmLm9yZzxtYWlsdG86aW5zaXBpZEBpZXRmLm9yZz4NCj4gU2VudDogOS8yNi8yMDEzIDEx OjIzOjA3IEFNDQo+IFN1YmplY3Q6IFJlOiBbSW5zaXBpZF0gQWRkcmVzc2luZyBzZWN1cml0eS1y ZWxhdGVkIGNvbW1lbnRzIC8NCj4gcmVxdWlyZW1lbnRzIHNwZWMNCj4+IElTVE0gdGhhdCB3aGF0 IGlzIGxhY2tpbmcgaXMgYSB0aHJlYXQgYW5hbHlzaXMuIFdoYXQgYmFkIHRoaW5ncyBjb3VsZA0K Pj4gaGFwcGVuIGlmIGFuIGFkdmVyc2FyeSB3YXMgYWJsZSB0byBjaGFuZ2UvcmVtb3ZlL2FkZCBh IFNlc3Npb24tSUQNCj4+IGhlYWRlciBpbiBhIG1hbGljaW91cyB3YXk/IE1heWJlIG5vdGhpbmcg c3VmZmljaWVudGx5IGJhZCBjYW4gaGFwcGVuDQo+PiB0byBqdXN0aWZ5IGFueW9uZSBib3RoZXJp bmcgdG8gZG8gc28uDQo+Pg0KPj4gIFRoYW5rcywNCj4+ICBQYXVsIEsNCj4+DQo+PiBPbiA5LzI1 LzEzIDk6NTggUE0sIFBhdWwgRS4gSm9uZXMgd3JvdGU6DQo+Pj4gRm9sa3MsDQo+Pj4gVmlqYXkg R3VyYmFuaSBwcm92aWRlZCBmZWVkYmFjayBzdWdnZXN0aW5nIHNvbWUgaW1wcm92ZW1lbnRzIG1p Z2h0IGJlDQo+Pj4gbmVlZGVkIGluIHRoZSByZXF1aXJlbWVudHMgZG9jdW1lbnQuIFNlZSB0aGlz IG1lc3NhZ2U6DQo+Pj4gaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2FwcHMt ZGlzY3Vzcy9jdXJyZW50L21zZzEwNDE5Lmh0bWwuDQo+Pj4gSSdtDQo+Pj4gcmVmZXJyaW5nIHNw ZWNpZmljYWxseSB0byBoaXMgY29tbWVudCBvbiBTZWN0aW9uIDcuDQo+Pj4gV2UgaGFkIGEgY291 cGxlIG9mIGZvbGxvdy11cCBtZXNzYWdlcyB0aGF0IHlvdSBzaG91bGQgcHJvYmFibHkgYWxzbw0K Pj4+IHJlYWQ6DQo+Pj4gaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2FwcHMt ZGlzY3Vzcy9jdXJyZW50L21zZzEwNDM3Lmh0bWwNCj4+PiBodHRwOi8vd3d3LmlldGYub3JnL21h aWwtYXJjaGl2ZS93ZWIvYXBwcy1kaXNjdXNzL2N1cnJlbnQvbXNnMTA1MDcuaHRtbA0KPj4+IEFm dGVyIHJldmlld2luZyBoaXMgY29tbWVudHMsIEkgd291bGQgbGlrZSB0byBhc2sgdGhlIGdyb3Vw IHdoYXQsIGlmDQo+Pj4gYW55LCBjaGFuZ2VzIHRoZSBncm91cCBmZWVscyB3ZSBzaG91bGQgbWFr ZSB0byB0aGUgcmVxdWlyZW1lbnRzDQo+Pj4gZG9jdW1lbnQuDQo+Pj4gVGhhbmtzIQ0KPj4+IFBh dWwNCj4+Pg0KPj4+DQo+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4+PiBpbnNpcGlkIG1haWxpbmcgbGlzdA0KPj4+IGluc2lwaWRAaWV0Zi5vcmc8 bWFpbHRvOmluc2lwaWRAaWV0Zi5vcmc+DQo+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9pbnNpcGlkDQo+Pj4NCj4+DQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPj4gaW5zaXBpZCBtYWlsaW5nIGxpc3QNCj4+IGluc2lw aWRAaWV0Zi5vcmc8bWFpbHRvOmluc2lwaWRAaWV0Zi5vcmc+DQo+PiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2luc2lwaWQNCj4NCj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gaW5zaXBpZCBtYWlsaW5nIGxpc3QNCj4gaW5z aXBpZEBpZXRmLm9yZzxtYWlsdG86aW5zaXBpZEBpZXRmLm9yZz4NCj4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pbnNpcGlkDQo+DQoNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQppbnNpcGlkIG1haWxpbmcgbGlzdA0KaW5zaXBp ZEBpZXRmLm9yZzxtYWlsdG86aW5zaXBpZEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vaW5zaXBpZA0K --_000_7594FB04B1934943A5C02806D1A2204B1C4B1EF8ESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQg MyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5v c2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5N c29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJU aW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCglt YXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIiwic2VyaWYiO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv LXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFy Z2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNv dXJpZXIgTmV3Ijt9DQp0dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJZm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3Ijt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0 YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBU ZXh0IENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5I VE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQg Q2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFBy ZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7fQ0KcC5lbWFpbHF1b3RlLCBsaS5l bWFpbHF1b3RlLCBkaXYuZW1haWxxdW90ZQ0KCXttc28tc3R5bGUtbmFtZTplbWFpbHF1b3RlOw0K CW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMi4wcHQ7 DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpwLmVtYWlscXVvdGUx LCBsaS5lbWFpbHF1b3RlMSwgZGl2LmVtYWlscXVvdGUxDQoJe21zby1zdHlsZS1uYW1lOmVtYWls cXVvdGUxOw0KCW1hcmdpbi10b3A6MGNtOw0KCW1hcmdpbi1yaWdodDowY207DQoJbWFyZ2luLWJv dHRvbTowY207DQoJbWFyZ2luLWxlZnQ6MS4wcHQ7DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0K CWJvcmRlcjpub25lOw0KCXBhZGRpbmc6MGNtOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1m YW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0K CXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFo b21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjUNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCglj b2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v bmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEy LjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2 LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0i MTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEi IC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBs YW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3Jk U2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+V2VsbCwgdGhlbiBJIGd1ZXNzIHRoZSBz ZWN1cml0eSBhc3BlY3RzIGRlcGVuZHMgb24gd2hhdCB0aGUgaGVhZGVyIGZpZWxkIGlzIGFjdHVh bGx5IHVzZWQgZm9yLiBJIHNlZSBubyByZWFzb24gdG8gZS5nLiBtYW5kYXRlIGVuY3J5cHRpb24g aW4gcHVyZSB0cm91YmxlIHNob290aW5nDQogc2NlbmFyaW9zLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UmVnYXJkcyw8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPkNocmlzdGVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8 L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gUGF1bCBFLiBKb25lcyBbbWFp bHRvOnBhdWxlakBwYWNrZXRpemVyLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiAyLiBsb2tha3V1 dGEgMjAxMyAxMzowMDxicj4NCjxiPlRvOjwvYj4gQ2hyaXN0ZXIgSG9sbWJlcmc7IFBhdWwgS3l6 aXZhdDsgaW5zaXBpZEBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW0luc2lwaWRd IEFkZHJlc3Npbmcgc2VjdXJpdHktcmVsYXRlZCBjb21tZW50cyAvIHJlcXVpcmVtZW50cyBzcGVj PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Q2hyaXN0ZXIsPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkkgd291bGQg ZXhwZWN0IHVzZSBvZiB0aGUgU2Vzc2lvbiBJRCZuYnNwO3RvIGJlIGJyb2FkZXIgdGhhbiBqdXN0 IGRlYnVnZ2luZy4mbmJzcDsmbmJzcDtJJm5ic3A7bWVudGlvbmVkIGF0IGxlYXN0IG9uZSBhcHBs aWNhdGlvbiBwcmV2aW91c2x5LCBzdWNoIGFzIGFzc29jaWF0aW5nIGNhbGwgc2lnbmFsaW5nIGFu ZCBtZWRpYSBmbG93cy4mbmJzcDsNCiBUaGlzIG1heSBzdGlsbCBmYWxsIGludG8gdGhlIGNhdGVn b3J5IG9mIHRyb3VibGVzaG9vdGluZywgYnV0IHRoZXJlIG1heSBiZSB1c2VzIHRoYXQgYXJlIGJl eW9uZCB0aGF0LiZuYnNwOyBTbywgSSBkbyBub3Qgd2FudCB0byBhc3N1bWUgdGhhdCBvbmNlIHdl IGNvbXBsZXRlIHRoZSB3b3JrLCBpdCB3aWxsIG9ubHkgYmUgdXNlZCBmb3IgdHJvdWJsZXNob290 aW5nLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij5FdmVuIGluIHRoYXQgbGltaXRlZCB1c2UgY2FzZSwgd2Ugc3RpbGwg d2FudCB0byBlbnN1cmUgdGhhdCBpdCBkaWQgbm90IGNoYW5nZSBlbmQtdG8tZW5kLiZuYnNwOyBN eSB0aG91Z2h0IHdhcyB0aGF0IG92ZXIgYW55IHVudHJ1c3RlZCBsaW5rLCB3ZSB3b3VsZCB1dGls aXplIFRMUy4mbmJzcDsgSG93ZXZlciwgSQ0KIGRpZCBub3QgdGhpbmsgd2UgbmVlZCB0byBzcGVs bCB0aGF0IG91dCBpbiB0aGUgcmVxdWlyZW1lbnRzIGRvY3VtZW50LiZuYnNwOyBUaGF0IHNhaWQs IFZpamF5IGRlZmluaXRlbHkgZmVsdCB0aGVyZSB3YXMgbW9yZSB3ZSBuZWVkZWQgdG8gc2F5Ljxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij5EbyBvdGhlcnMgYWdyZWUgdGhhdCB3ZSBuZWVkIHRvIHNheSBtb3JlIGluIHRo ZSBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyBzZWN0aW9uIG9yIHNoYWxsIGp1c3QgcHVibGlzaCB0 aGUgZG9jdW1lbnQgYXMtaXMuJm5ic3A7IEknbGwgbm90ZSBoaXMgY29tbWVudHMgYXJlIG5vbi1i bG9ja2luZy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+UGF1bDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4tLS0tLS0gT3JpZ2luYWwgTWVz c2FnZSAtLS0tLS08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206ICZxdW90O0No cmlzdGVyIEhvbG1iZXJnJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86Y2hyaXN0ZXIuaG9sbWJl cmdAZXJpY3Nzb24uY29tIj5jaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208L2E+Jmd0Ozxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+VG86ICZxdW90O1BhdWwgS3l6aXZhdCZxdW90 OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBreXppdmF0QGFsdW0ubWl0LmVkdSI+cGt5eml2YXRAYWx1 bS5taXQuZWR1PC9hPiZndDs7ICZxdW90OzxhIGhyZWY9Im1haWx0bzppbnNpcGlkQGlldGYub3Jn Ij5pbnNpcGlkQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmluc2lwaWRA aWV0Zi5vcmciPmluc2lwaWRAaWV0Zi5vcmc8L2E+Jmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+U2VudDogOS8yOC8yMDEzIDI6MTM6NTkgUE08bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPlN1YmplY3Q6IFJlOiBbSW5zaXBpZF0gQWRkcmVzc2luZyBzZWN1cml0eS1yZWxh dGVkIGNvbW1lbnRzIC8gcmVxdWlyZW1lbnRzIHNwZWM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBi bGFjayAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDguMHB0O21hcmdpbi1sZWZ0OjMuNzVwdDtt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 ZGl2IGlkPSI0MTI0M2JjYTA5NTY0MTk0YTZhM2RjZTFiOTBhNjM0YSI+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkhp LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpi bGFjayI+SWYgaXQncyB1c2VkIGZvciB0cm91YmxlIHNob290aW5nLCB0aGUgb25seSBoYXJtIHRo YXQgc29tZW9uZSBjYW4gZG8gYnkgcmVtb3ZpbmcvbW9kaWZ5aW5nIHRoZSBoZWFkZXIgZmllbGQg aXMgdG8gbWFrZSB0aGUgdHJvdWJsZSBzaG9vdGluZyBhIGxpdHRsZSBtb3JlIGRpZmZpY3VsdC4N CiBJIGRvbid0IHNlZSBhbnkgc2VjdXJpdHkgdGhyZWF0IGluIHRoYXQuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5SZWdhcmRzLDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFj ayI+Q2hyaXN0ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGln bjpjZW50ZXIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4NCjxociBz aXplPSIyIiB3aWR0aD0iMTAwJSIgYWxpZ249ImNlbnRlciI+DQo8L3NwYW4+PC9kaXY+DQo8L2Rp dj4NCjxkaXYgaWQ9InhfZGl2UnBseUZ3ZE1zZyI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOmJsYWNrIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6YmxhY2siPg0KPGEgaHJlZj0ibWFpbHRvOmluc2lwaWQtYm91bmNlc0BpZXRmLm9yZyI+aW5z aXBpZC1ib3VuY2VzQGlldGYub3JnPC9hPiBbPGEgaHJlZj0ibWFpbHRvOmluc2lwaWQtYm91bmNl c0BpZXRmLm9yZyI+aW5zaXBpZC1ib3VuY2VzQGlldGYub3JnPC9hPl0gb24gYmVoYWxmIG9mIFBh dWwgS3l6aXZhdCBbPGEgaHJlZj0ibWFpbHRvOnBreXppdmF0QGFsdW0ubWl0LmVkdSI+cGt5eml2 YXRAYWx1bS5taXQuZWR1PC9hPl08YnI+DQo8Yj5TZW50OjwvYj4gU2F0dXJkYXksIDI4IFNlcHRl bWJlciAyMDEzIDc6MDQgUE08YnI+DQo8Yj5Ubzo8L2I+IDxhIGhyZWY9Im1haWx0bzppbnNpcGlk QGlldGYub3JnIj5pbnNpcGlkQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTog W0luc2lwaWRdIEFkZHJlc3Npbmcgc2VjdXJpdHktcmVsYXRlZCBjb21tZW50cyAvIHJlcXVpcmVt ZW50cyBzcGVjPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFj ayI+T24gOS8yNy8xMyAxMTozOCBBTSwgUGF1bCBFLiBKb25lcyB3cm90ZTo8YnI+DQomZ3Q7IFBh dWwsPGJyPg0KJmd0Ozxicj4NCiZndDsgVGhlIGltcGFjdCBvZiBhbiBhdHRhY2sgZGVwZW5kcyBv biB0aGUgdXNlIG9mIHRoZSBTZXNzaW9uIElELiZuYnNwOyBJZiBpdCdzPGJyPg0KJmd0OyB1c2Vk IG9ubHkgZm9yIHRyb3VibGVzaG9vdGluZyBhIGNhbGwsIHRoZW4gaXQgaGluZGVycyB0aGUgYWJp bGl0eSB0bzxicj4NCiZndDsgdHJvdWJsZXNob290IGNhbGxzLiZuYnNwOyBJZiBzb21lb25lIHdl cmUgdG8gdXNlIHRoaXMgdG8gY29ycmVsYXRlIGNhbGwgbGVnczxicj4NCiZndDsgaW4gYW4gZWZm b3J0IHRvIGRvIGJpbGxpbmcgKHdoaWNoIGlzIGV4cGxpY2l0bHkgZm9yYmlkZGVuIGluIHRoZTxi cj4NCiZndDsgc29sdXRpb24gc3BlYyksIHRoZW4gdGhlIG9wZXJhdG9yIHdvdWxkIGhhdmUgYSBo b3JyaWJsZSBiaWxsaW5nIG1lc3Mgb248YnI+DQomZ3Q7IHRoZWlyIGhhbmRzLjxicj4NCiZndDs8 YnI+DQomZ3Q7IEkgZXhwZWN0ZWQgdGhlIHNvbHV0aW9uIHNwZWMgd291bGQgaGF2ZSBtb3JlIGlu IHRlcm1zIG9mIHNlY3VyaXR5PGJyPg0KJmd0OyBjb25zaWRlcmF0aW9ucywgc2luY2Ugd2UgY2Fu IHNwZWFrIG1vcmUgY29uY3JldGVseS4mbmJzcDsgV2Ugc2hvdWxkIG1ha2U8YnI+DQomZ3Q7IGRl Y2lzaW9ucyBhYm91dCB3aGV0aGVyIHdlIHdhbnQgdG8gbWFuZGF0ZSB1c2Ugb2YgVExTLCBob3cg dHJ1c3QgbWlnaHQ8YnI+DQomZ3Q7IGJlIGVzdGFibGlzaGVkLCBldGMuJm5ic3A7Jm5ic3A7IFdl IHNwZWxsIG91dCBwcm9jZWR1cmVzIHNvIHRoYXQgd2UgbWluaW1pemUgdGhlPGJyPg0KJmd0OyBw cm9iYWJpbGl0eSB0aGF0IHR3byBkZXZpY2VzIHdpbGwgaGF2ZSB0aGUgc2FtZSBVVUlELCBmb3Ig ZXhhbXBsZS4mbmJzcDsgVGhpczxicj4NCiZndDsgbWVldHMgcGFydCBvZiB0aGUgcmVxdWlyZW1l bnRzLCBidXQgZG9lcyBub3QgZnVsbHkgYWRkcmVzcyB0aGUgc2VjdXJpdHk8YnI+DQomZ3Q7IGlz c3Vlcy48YnI+DQomZ3Q7PGJyPg0KJmd0OyBJbiBhbnkgY2FzZSwgd2UgZG8gaGF2ZSBzb21lIGtu b3duIHRocmVhdHMgKGUuZy4sIHNwb29maW5nLCByZS1wbGF5LCBiYWQ8YnI+DQomZ3Q7IGltcGxl bWVudGF0aW9uLCBtYWxpY2lvdXMgU0JDcykuJm5ic3A7IFdlIGtub3cgdGhlIGltcGFjdCBvZiBh bnkgc3VjY2Vzc2Z1bDxicj4NCiZndDsgYXR0YWNrIChiYXNpY2FsbHkgcmVuZGVyaW5nIGl0IHVz ZWxlc3MsIG1pc2xlYWRpbmcgYXBwbGljYXRpb25zIHRoYXQgdXNlPGJyPg0KJmd0OyBpdCwgZXRj KS4mbmJzcDsgQW5kIHNvIHRoYXQncyB3aHkgd2UgaGF2ZSB0aGUgbGFuZ3VhZ2UgaW4gdGhlIHJl cXVpcmVtZW50czxicj4NCiZndDsgZG9jdW1lbnQgbm93IHRoYXQgcmVxdWlyZXMgYSByYW5kb20s IGxvbmcgdmFsdWUsIHZlcmlmaWNhdGlvbiBieTxicj4NCiZndDsgYXBwbGljYXRpb25zIHVzaW5n IHRoZSBzZXNzaW9uIGlkZW50aWZpZXIsIHNlY3VyZSB0cmFuc3BvcnQsPGJyPg0KJmd0OyBhdXRo ZW50aWNhdGlvbiwgZXRjLiZuYnNwOyBJIHRob3VnaHQgd2hhdCB3ZSBoYWQgd3JpdHRlbiB3YXMg c3VmZmljaWVudCBmb3IgYTxicj4NCiZndDsgcmVxdWlyZW1lbnRzIGRvY3VtZW50LCBidXQgVmlq YXkgZGlzYWdyZWVkLjxicj4NCiZndDs8YnI+DQomZ3Q7IFNvLCB3aGF0IGRvIHdlIGFkZD88YnI+ DQo8YnI+DQpJIGRvbid0IGtub3cuPGJyPg0KPGJyPg0KJmd0OyBQYXVsPGJyPg0KJmd0Ozxicj4N CiZndDsgLS0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0tPGJyPg0KJmd0OyBGcm9tOiAmcXVv dDtQYXVsIEt5eml2YXQmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpwa3l6aXZhdEBhbHVtLm1p dC5lZHUiPnBreXppdmF0QGFsdW0ubWl0LmVkdTwvYT4mZ3Q7PGJyPg0KJmd0OyBUbzogPGEgaHJl Zj0ibWFpbHRvOmluc2lwaWRAaWV0Zi5vcmciPmluc2lwaWRAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0 OyBTZW50OiA5LzI2LzIwMTMgMTE6MjM6MDcgQU08YnI+DQomZ3Q7IFN1YmplY3Q6IFJlOiBbSW5z aXBpZF0gQWRkcmVzc2luZyBzZWN1cml0eS1yZWxhdGVkIGNvbW1lbnRzIC88YnI+DQomZ3Q7IHJl cXVpcmVtZW50cyBzcGVjPGJyPg0KJmd0OyZndDsgSVNUTSB0aGF0IHdoYXQgaXMgbGFja2luZyBp cyBhIHRocmVhdCBhbmFseXNpcy4gV2hhdCBiYWQgdGhpbmdzIGNvdWxkPGJyPg0KJmd0OyZndDsg aGFwcGVuIGlmIGFuIGFkdmVyc2FyeSB3YXMgYWJsZSB0byBjaGFuZ2UvcmVtb3ZlL2FkZCBhIFNl c3Npb24tSUQ8YnI+DQomZ3Q7Jmd0OyBoZWFkZXIgaW4gYSBtYWxpY2lvdXMgd2F5PyBNYXliZSBu b3RoaW5nIHN1ZmZpY2llbnRseSBiYWQgY2FuIGhhcHBlbjxicj4NCiZndDsmZ3Q7IHRvIGp1c3Rp ZnkgYW55b25lIGJvdGhlcmluZyB0byBkbyBzby48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7 Jm5ic3A7IFRoYW5rcyw8YnI+DQomZ3Q7Jmd0OyZuYnNwOyBQYXVsIEs8YnI+DQomZ3Q7Jmd0Ozxi cj4NCiZndDsmZ3Q7IE9uIDkvMjUvMTMgOTo1OCBQTSwgUGF1bCBFLiBKb25lcyB3cm90ZTo8YnI+ DQomZ3Q7Jmd0OyZndDsgRm9sa3MsPGJyPg0KJmd0OyZndDsmZ3Q7IFZpamF5IEd1cmJhbmkgcHJv dmlkZWQgZmVlZGJhY2sgc3VnZ2VzdGluZyBzb21lIGltcHJvdmVtZW50cyBtaWdodCBiZTxicj4N CiZndDsmZ3Q7Jmd0OyBuZWVkZWQgaW4gdGhlIHJlcXVpcmVtZW50cyBkb2N1bWVudC4gU2VlIHRo aXMgbWVzc2FnZTo8YnI+DQomZ3Q7Jmd0OyZndDsgPGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9y Zy9tYWlsLWFyY2hpdmUvd2ViL2FwcHMtZGlzY3Vzcy9jdXJyZW50L21zZzEwNDE5Lmh0bWwiPg0K aHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2FwcHMtZGlzY3Vzcy9jdXJyZW50 L21zZzEwNDE5Lmh0bWw8L2E+Ljxicj4NCiZndDsmZ3Q7Jmd0OyBJJ208YnI+DQomZ3Q7Jmd0OyZn dDsgcmVmZXJyaW5nIHNwZWNpZmljYWxseSB0byBoaXMgY29tbWVudCBvbiBTZWN0aW9uIDcuPGJy Pg0KJmd0OyZndDsmZ3Q7IFdlIGhhZCBhIGNvdXBsZSBvZiBmb2xsb3ctdXAgbWVzc2FnZXMgdGhh dCB5b3Ugc2hvdWxkIHByb2JhYmx5IGFsc288YnI+DQomZ3Q7Jmd0OyZndDsgcmVhZDo8YnI+DQom Z3Q7Jmd0OyZndDsgPGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2Vi L2FwcHMtZGlzY3Vzcy9jdXJyZW50L21zZzEwNDM3Lmh0bWwiPg0KaHR0cDovL3d3dy5pZXRmLm9y Zy9tYWlsLWFyY2hpdmUvd2ViL2FwcHMtZGlzY3Vzcy9jdXJyZW50L21zZzEwNDM3Lmh0bWw8L2E+ PGJyPg0KJmd0OyZndDsmZ3Q7IDxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNo aXZlL3dlYi9hcHBzLWRpc2N1c3MvY3VycmVudC9tc2cxMDUwNy5odG1sIj4NCmh0dHA6Ly93d3cu aWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9hcHBzLWRpc2N1c3MvY3VycmVudC9tc2cxMDUwNy5o dG1sPC9hPjxicj4NCiZndDsmZ3Q7Jmd0OyBBZnRlciByZXZpZXdpbmcgaGlzIGNvbW1lbnRzLCBJ IHdvdWxkIGxpa2UgdG8gYXNrIHRoZSBncm91cCB3aGF0LCBpZjxicj4NCiZndDsmZ3Q7Jmd0OyBh bnksIGNoYW5nZXMgdGhlIGdyb3VwIGZlZWxzIHdlIHNob3VsZCBtYWtlIHRvIHRoZSByZXF1aXJl bWVudHM8YnI+DQomZ3Q7Jmd0OyZndDsgZG9jdW1lbnQuPGJyPg0KJmd0OyZndDsmZ3Q7IFRoYW5r cyE8YnI+DQomZ3Q7Jmd0OyZndDsgUGF1bDxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7 Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXzxicj4NCiZndDsmZ3Q7Jmd0OyBpbnNpcGlkIG1haWxpbmcgbGlzdDxicj4N CiZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJtYWlsdG86aW5zaXBpZEBpZXRmLm9yZyI+aW5zaXBpZEBp ZXRmLm9yZzwvYT48YnI+DQomZ3Q7Jmd0OyZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9pbnNpcGlkIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2luc2lwaWQ8L2E+PGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+ DQomZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xzxicj4NCiZndDsmZ3Q7IGluc2lwaWQgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyZndDsgPGEgaHJl Zj0ibWFpbHRvOmluc2lwaWRAaWV0Zi5vcmciPmluc2lwaWRAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0 OyZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pbnNp cGlkIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2luc2lwaWQ8L2E+PGJy Pg0KJmd0Ozxicj4NCiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188YnI+DQomZ3Q7IGluc2lwaWQgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyA8YSBocmVm PSJtYWlsdG86aW5zaXBpZEBpZXRmLm9yZyI+aW5zaXBpZEBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7 IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaW5zaXBpZCI+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pbnNpcGlkPC9hPjxicj4NCiZn dDs8YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXzxicj4NCmluc2lwaWQgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOmluc2lw aWRAaWV0Zi5vcmciPmluc2lwaWRAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pbnNpcGlkIj5odHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2luc2lwaWQ8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_7594FB04B1934943A5C02806D1A2204B1C4B1EF8ESESSMB209erics_-- From paulej@packetizer.com Wed Oct 2 09:18:42 2013 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E58921F90CF for ; Wed, 2 Oct 2013 09:18:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zM4QJeNd0aYg for ; Wed, 2 Oct 2013 09:18:31 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 0964D21F9926 for ; Wed, 2 Oct 2013 09:16:34 -0700 (PDT) Received: from [192.168.1.20] (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id r92GGVMF015676 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 2 Oct 2013 12:16:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1380730592; bh=BVskmikWcaaK56UsnC64hHtlWwDwQuGweFcTXEH2s4U=; h=From:To:Subject:Date:Content-Type:In-Reply-To:Message-Id: Mime-Version:Reply-To; b=awXFsT4wKQDw1nDpFEuszPjyoyBko4NsNXYjOxKufjTM+P3cszVQRkYTqY2btQC5Q O3dVYaZZ+oy9cfwEoAlSFEbi06JSTR69RY97t/STiN/lRlpIZ9faw6m2/kLt1OsMW7 7pn8mh7jWLVhvS9vdhcrxtKZxeJoeXGt6g/i6oEI= From: "Paul E. Jones" To: "Christer Holmberg" , "Paul Kyzivat" , "insipid@ietf.org" Date: Wed, 02 Oct 2013 16:16:52 +0000 Content-Type: multipart/alternative; boundary="------=_MB6805CB1E-24FA-4E9D-9ED8-26C8C2C1A7FA" In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C4B1EF8@ESESSMB209.ericsson.se> Message-Id: Mime-Version: 1.0 User-Agent: eM_Client/5.0.18661.0 Subject: Re: [Insipid] Addressing security-related comments / requirements spec X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "Paul E. Jones" List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Oct 2013 16:18:42 -0000 --------=_MB6805CB1E-24FA-4E9D-9ED8-26C8C2C1A7FA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; format=flowed; charset=utf-8 Christer, I would assume that we do need to ensure what was specified in the=20 security considerations, i.e., we need to use long, random identifiers,=20 provide sufficient security to prevent rogue entities from re-using=20 identifiers, etc. I believe it's reasonable to assume this is as=20 valuable as the Call-ID, for example. But, what I need is to know how to answer Vijay's comments. Do you or=20 others think we should add or change the requirements draft as it's=20 written now? Paul ------ Original Message ------ From: "Christer Holmberg" To: "Paul E. Jones" ; "Paul Kyzivat"=20 ; "insipid@ietf.org" Sent: 10/2/2013 6:46:24 AM Subject: RE: [Insipid] Addressing security-related comments /=20 requirements spec >Hi, > > > >Well, then I guess the security aspects depends on what the header=20 >field is actually used for. I see no reason to e.g. mandate encryption=20 >in pure trouble shooting scenarios. > > > >Regards, > > > >Christer > > > >From: Paul E. Jones [mailto:paulej@packetizer.com] >Sent: 2. lokakuuta 2013 13:00 >To: Christer Holmberg; Paul Kyzivat; insipid@ietf.org >Subject: Re: [Insipid] Addressing security-related comments /=20 >requirements spec > > > >Christer, > > > >I would expect use of the Session ID to be broader than just debugging.= =20 > I mentioned at least one application previously, such as associating=20 >call signaling and media flows. This may still fall into the category=20 >of troubleshooting, but there may be uses that are beyond that. So, I=20 >do not want to assume that once we complete the work, it will only be=20 >used for troubleshooting. > > > >Even in that limited use case, we still want to ensure that it did not=20 >change end-to-end. My thought was that over any untrusted link, we=20 >would utilize TLS. However, I did not think we need to spell that out=20 >in the requirements document. That said, Vijay definitely felt there=20 >was more we needed to say. > > > >Do others agree that we need to say more in the Security Considerations= =20 >section or shall just publish the document as-is. I'll note his=20 >comments are non-blocking. > > > >Paul > > > >------ Original Message ------ > >From: "Christer Holmberg" > >To: "Paul Kyzivat" ; "insipid@ietf.org"=20 > > >Sent: 9/28/2013 2:13:59 PM > >Subject: Re: [Insipid] Addressing security-related comments /=20 >requirements spec > >>Hi, >> >> >> >>If it's used for trouble shooting, the only harm that someone can do=20 >>by removing/modifying the header field is to make the trouble shooting= =20 >>a little more difficult. I don't see any security threat in that. >> >> >> >>Regards, >> >> >> >>Christer >> >> >> >> >> >>-------------------------------------------------------------------------= ------- >>From:insipid-bounces@ietf.org [insipid-bounces@ietf.org] on behalf of=20 >>Paul Kyzivat [pkyzivat@alum.mit.edu] >>Sent: Saturday, 28 September 2013 7:04 PM >>To:insipid@ietf.org >>Subject: Re: [Insipid] Addressing security-related comments /=20 >>requirements spec >> >>On 9/27/13 11:38 AM, Paul E. Jones wrote: >> > Paul, >> > >> > The impact of an attack depends on the use of the Session ID. If=20 >>it's >> > used only for troubleshooting a call, then it hinders the ability to >> > troubleshoot calls. If someone were to use this to correlate call=20 >>legs >> > in an effort to do billing (which is explicitly forbidden in the >> > solution spec), then the operator would have a horrible billing mess= =20 >>on >> > their hands. >> > >> > I expected the solution spec would have more in terms of security >> > considerations, since we can speak more concretely. We should make >> > decisions about whether we want to mandate use of TLS, how trust=20 >>might >> > be established, etc. We spell out procedures so that we minimize=20 >>the >> > probability that two devices will have the same UUID, for example. = =20 >>This >> > meets part of the requirements, but does not fully address the=20 >>security >> > issues. >> > >> > In any case, we do have some known threats (e.g., spoofing, re-play,= =20 >>bad >> > implementation, malicious SBCs). We know the impact of any=20 >>successful >> > attack (basically rendering it useless, misleading applications that= =20 >>use >> > it, etc). And so that's why we have the language in the=20 >>requirements >> > document now that requires a random, long value, verification by >> > applications using the session identifier, secure transport, >> > authentication, etc. I thought what we had written was sufficient=20 >>for a >> > requirements document, but Vijay disagreed. >> > >> > So, what do we add? >> >>I don't know. >> >> > Paul >> > >> > ------ Original Message ------ >> > From: "Paul Kyzivat" >> > To: insipid@ietf.org >> > Sent: 9/26/2013 11:23:07 AM >> > Subject: Re: [Insipid] Addressing security-related comments / >> > requirements spec >> >> ISTM that what is lacking is a threat analysis. What bad things=20 >>could >> >> happen if an adversary was able to change/remove/add a Session-ID >> >> header in a malicious way? Maybe nothing sufficiently bad can=20 >>happen >> >> to justify anyone bothering to do so. >> >> >> >> Thanks, >> >> Paul K >> >> >> >> On 9/25/13 9:58 PM, Paul E. Jones wrote: >> >>> Folks, >> >>> Vijay Gurbani provided feedback suggesting some improvements might= =20 >>be >> >>> needed in the requirements document. See this message: >> >>>=20 >>http://www.ietf.org/mail-archive/web/apps-discuss/current/msg10419.html. >> >>> I'm >> >>> referring specifically to his comment on Section 7. >> >>> We had a couple of follow-up messages that you should probably=20 >>also >> >>> read: >> >>>=20 >>http://www.ietf.org/mail-archive/web/apps-discuss/current/msg10437.html >> >>>=20 >>http://www.ietf.org/mail-archive/web/apps-discuss/current/msg10507.html >> >>> After reviewing his comments, I would like to ask the group what,= =20 >>if >> >>> any, changes the group feels we should make to the requirements >> >>> document. >> >>> Thanks! >> >>> Paul >> >>> >> >>> >> >>> _______________________________________________ >> >>> insipid mailing list >> >>> insipid@ietf.org >> >>> https://www.ietf.org/mailman/listinfo/insipid >> >>> >> >> >> >> _______________________________________________ >> >> insipid mailing list >> >> insipid@ietf.org >> >> https://www.ietf.org/mailman/listinfo/insipid >> > >> > _______________________________________________ >> > insipid mailing list >> > insipid@ietf.org >> > https://www.ietf.org/mailman/listinfo/insipid >> > >> >>_______________________________________________ >>insipid mailing list >>insipid@ietf.org >>https://www.ietf.org/mailman/listinfo/insipid >> --------=_MB6805CB1E-24FA-4E9D-9ED8-26C8C2C1A7FA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Christer,
 
I would assume that we do need to ensure what was specified in the = security considerations, i.e., we need to use long, random identifiers, = provide sufficient security to prevent rogue entities from re-using identif= iers, etc.  I believe it's reasonable to assume this is as valuable= as the Call-ID, for example.
 
But, what I need is to know how to answer Vijay's comments.  Do= you or others think we should add or change the requirements draft as it's= written now?
 
Paul
 
------ Original Message ------
From: "Christer Holmberg" <christer.holmberg@ericsson.com>
To: "Paul E. Jones" <paule= j@packetizer.com>; "Paul Kyzivat" <pkyzivat@alum.mit.edu>; "insipid@ietf.org" <insipid@ietf.org>
Sent: 10/2/2013 6:46:24 AM
Subject: RE: [Insipid] Addressing security-related comments / requirem= ents spec

Hi,

 

Well, then I guess the security aspects depe= nds on what the header field is actually used for. I see no reason to e.g.= mandate encryption in pure trouble shooting scenarios.

 

Regards,

 

Christer

 

From: Paul E. Jones [mailto:paulej@packetizer.com]
Sent: 2. lokakuuta = 2013 13:00
To: Christer Holmberg; Paul Kyzivat; insipid@ietf.org
Subject: Re: [Insipid]= Addressing security-related comments / requirements spec=

 

Christer,

 

I would expect use of the Session ID to be broader than= just debugging.  I mentioned at least one application previ= ously, such as associating call signaling and media flows.  This may= still fall into the category of troubleshooting, but there may be uses = that are beyond that.  So, I do not want to assume that once we comple= te the work, it will only be used for troubleshooting.

 

Even in that limited use case, we still want to ensure that= it did not change end-to-end.  My thought was that over any untrusted= link, we would utilize TLS.  However, I did not think we need to spel= l that out in the requirements document.  That said, Vijay definitely= felt there was more we needed to say.

 

Do others agree that we need to say more in the Security = Considerations section or shall just publish the document as-is.  I'll= note his comments are non-blocking.

 

Paul

 

------ Original Message ------

From: "Christer Holmberg" <christer.holmberg@ericsson.com>

Sent: 9/28/2013 2:13:59 PM

Subject: Re: [Insipid] Addressing security-related comments= / requirements spec

Hi,

 

If it's used for trouble shooting, the only = harm that someone can do by removing/modifying the header field is to make= the trouble shooting a little more difficult. I don't see any security = threat in that.

 

Regards,

 

Christer

 

 

On 9/27/13 11:38 AM, Paul E. Jones wrote:
&g= t; Paul,
>
> The impact of an attack depends on the use of the= Session ID.  If it's
> used only for troubleshooting a call,= then it hinders the ability to
> troubleshoot calls.  If someon= e were to use this to correlate call legs
> in an effort to do billin= g (which is explicitly forbidden in the
> solution spec), then the= operator would have a horrible billing mess on
> their hands.
>= ;
> I expected the solution spec would have more in terms of security=
> considerations, since we can speak more concretely.  We shoul= d make
> decisions about whether we want to mandate use of TLS, how= trust might
> be established, etc.   We spell out procedur= es so that we minimize the
> probability that two devices will have= the same UUID, for example.  This
> meets part of the requireme= nts, but does not fully address the security
> issues.
>
>= ; In any case, we do have some known threats (e.g., spoofing, re-play, bad<= BR>> implementation, malicious SBCs).  We know the impact of any= successful
> attack (basically rendering it useless, misleading appl= ications that use
> it, etc).  And so that's why we have the = language in the requirements
> document now that requires a random,= long value, verification by
> applications using the session identif= ier, secure transport,
> authentication, etc.  I thought what= we had written was sufficient for a
> requirements document, but = Vijay disagreed.
>
> So, what do we add?

I don't know.
> Paul
>
> ------ Original Message ------
> From= : "Paul Kyzivat" <pkyzivat@alum= .mit.edu>
> To: insipid@ie= tf.org
> Sent: 9/26/2013 11:23:07 AM
> Subject: Re: [Insipi= d] Addressing security-related comments /
> requirements spec
>= > ISTM that what is lacking is a threat analysis. What bad things could<= BR>>> happen if an adversary was able to change/remove/add a Session-= ID
>> header in a malicious way? Maybe nothing sufficiently bad= can happen
>> to justify anyone bothering to do so.
>>>>  Thanks,
>>  Paul K
>>
>>= On 9/25/13 9:58 PM, Paul E. Jones wrote:
>>> Folks,
>>= ;> Vijay Gurbani provided feedback suggesting some improvements might= be
>>> needed in the requirements document. See this message:<= BR>>>> http://www.ietf.org/mail-archive/web/apps-discuss/= current/msg10419.html.
>>> I'm
>>> referring= specifically to his comment on Section 7.
>>> We had a couple= of follow-up messages that you should probably also
>>> read:<= BR>>>> http://www.ietf.org/mail-archive/web/apps-discuss/= current/msg10437.html
>>> http://www.ietf.org/mail= -archive/web/apps-discuss/current/msg10507.html
>>> After= reviewing his comments, I would like to ask the group what, if
>>= > any, changes the group feels we should make to the requirements
>= ;>> document.
>>> Thanks!
>>> Paul
>>= ;>
>>>
>>> _____________________________________= __________
>>> insipid mailing list
>>> insipid@ietf.org
>>> https://www.ietf.org/mailma= n/listinfo/insipid
>>>
>>
>> ____________= ___________________________________
>> insipid mailing list
>= ;> insipid@ietf.org
>>= https://www.ietf= .org/mailman/listinfo/insipid
>
> _________________________= ______________________
> insipid mailing list
> insipid@ietf.org
> https://www.ietf.org/mailman/listinfo/insi= pid
>

_______________________________________________
i= nsipid mailing list
insipid@ietf.org=
https://w= ww.ietf.org/mailman/listinfo/insipid

<= /DIV>
--------=_MB6805CB1E-24FA-4E9D-9ED8-26C8C2C1A7FA-- From ietf-ipr@ietf.org Mon Oct 7 09:49:02 2013 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98E1C11E814F; Mon, 7 Oct 2013 09:49:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.263 X-Spam-Level: X-Spam-Status: No, score=-102.263 tagged_above=-999 required=5 tests=[AWL=0.337, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xLRIl6tqOSj0; Mon, 7 Oct 2013 09:49:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E093911E810B; Mon, 7 Oct 2013 09:48:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: chrep@cisco.com,paulej@packetizer.com,jmpolk@cisco.com,gsalguei@cisco.com X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131007164855.9508.14215.idtracker@ietfa.amsl.com> Date: Mon, 07 Oct 2013 09:48:55 -0700 X-Mailman-Approved-At: Tue, 08 Oct 2013 08:03:21 -0700 Cc: rlb@ipv.sx, keith.drage@alcatel-lucent.com, gonzalo.camarillo@ericsson.com, gsalguei@cisco.com, insipid@ietf.org, ipr-announce@ietf.org Subject: [Insipid] IPR Disclosure: Tekelec, Inc. (Now a wholly owned subsidiary of Oracle Corporation)'s Statement about IPR related to draft-jones-ipmc-session-id-03, draft-ietf-insipid-session-id-02, and draft-kaplan-insipid-session-id-03 X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 16:49:02 -0000 Dear Chris Pearce, Paul Jones, James Polk, Gonzalo Salgueiro: An IPR disclosure that pertains to your Internet-Draft entitled "End-to-End Session Identification in IP-Based Multimedia Communication Networks" (draf= t- ietf-insipid-session-id) was submitted to the IETF Secretariat on 2013-09-3= 0 and has been posted on the "IETF Page of Intellectual Property Rights Disclosur= es" (https://datatracker.ietf.org/ipr/2205/). The title of the IPR disclosure is "Tekelec, Inc. (Now a wholly owned subsidiary of Oracle Corporation)'s Stat= ement about IPR related to draft-jones-ipmc-session-id-03, draft-ietf-insipid-ses= sion- id-02, and draft-kaplan-insipid-session-id-03.""); The IETF Secretariat From paulej@packetizer.com Tue Oct 8 14:24:19 2013 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC9B021F92B5 for ; Tue, 8 Oct 2013 14:24:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.529 X-Spam-Level: X-Spam-Status: No, score=-1.529 tagged_above=-999 required=5 tests=[AWL=-0.419, BAYES_05=-1.11, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NXRodJHudezc for ; Tue, 8 Oct 2013 14:24:15 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 6659621E80B7 for ; Tue, 8 Oct 2013 14:24:07 -0700 (PDT) Received: from [192.168.1.20] (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id r98LO3rc020351 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 8 Oct 2013 17:24:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1381267443; bh=WkqK/SNyBvZxdEADqiFSkpv6Lu2Hh5a5DkKmdGE4HOY=; h=From:To:Subject:Date:Content-Type:In-Reply-To:Message-Id: Mime-Version:Reply-To; b=ij3GhsVFfuwXolX8ufvD44ruMwGsHW1rKIX/TTR/4l94b7qABNO8VH/tjb1Eo2wSX 0IB2vthxYY0/aC2mXa7DcuSr7pfE3QJMWRB+EgrQYKbhB+OOoeWHv8vSuZCpZdjZzU hS60ItHL5fYQprdMJyzej+5+buzcuBjCqehLlMzI= From: "Paul E. Jones" To: "insipid@ietf.org" Date: Tue, 08 Oct 2013 21:24:20 +0000 Content-Type: multipart/alternative; boundary="------=_MB6D700FCF-1C90-4B9B-B6A8-368E385BFEB9" In-Reply-To: Message-Id: Mime-Version: 1.0 User-Agent: eM_Client/5.0.18661.0 Subject: Re: [Insipid] Addressing security-related comments / requirements spec X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "Paul E. Jones" List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 21:24:19 -0000 --------=_MB6D700FCF-1C90-4B9B-B6A8-368E385BFEB9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; format=flowed; charset=utf-8 Folks, Coming back to this. I did receive a few replies, but no concrete=20 suggestion on what to change. I suppose the question is, for the requirements document are we=20 satisfied with the language in the security considerations section or is= =20 there more people feel we should add? I have other changes to incorporate into the text and will publish a new= =20 revision for review, but I would like to get a final word on the=20 comments from Vijay. Paul ------ Original Message ------ From: "Paul E. Jones" To: "insipid@ietf.org" Sent: 9/25/2013 9:58:05 PM Subject: [Insipid] Addressing security-related comments / requirements=20 spec >Folks, > >Vijay Gurbani provided feedback suggesting some improvements might be=20 >needed in the requirements document. See this message:=20 >http://www.ietf.org/mail-archive/web/apps-discuss/current/msg10419.html.= =20 > I'm referring specifically to his comment on Section 7. > >We had a couple of follow-up messages that you should probably also=20 >read: >http://www.ietf.org/mail-archive/web/apps-discuss/current/msg10437.html >http://www.ietf.org/mail-archive/web/apps-discuss/current/msg10507.html > >After reviewing his comments, I would like to ask the group what, if=20 >any, changes the group feels we should make to the requirements=20 >document. > >Thanks! >Paul > > --------=_MB6D700FCF-1C90-4B9B-B6A8-368E385BFEB9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Folks,
 
Coming back to this.  I did receive a few replies, but no concret= e suggestion on what to change.
 
I suppose the question is, for the requirements document are we satisf= ied with the language in the security considerations section or is there= more people feel we should add?
 
I have other changes to incorporate into the text and will publish = a new revision for review, but I would like to get a final word on the comm= ents from Vijay.
 
Paul
 
------ Original Message ------
From: "Paul E. Jones" <pau= lej@packetizer.com>
To: "insipid@ietf.org" <insipid= @ietf.org>
Sent: 9/25/2013 9:58:05 PM
Subject: [Insipid] Addressing security-related comments / requirements= spec
Folks,
 
Vijay Gurbani provided feedback suggesting some improvements might = be needed in the requirements document.  See this message: h= ttp://www.ietf.org/mail-archive/web/apps-discuss/current/msg10419.html.=   I'm referring specifically to his comment on Section 7.
 
We had a couple of follow-up messages that you should probably also= read:
 
After reviewing his comments, I would like to ask the group what, if= any, changes the group feels we should make to the requirements document.<= /DIV>
 
Thanks!
Paul
 
 
--------=_MB6D700FCF-1C90-4B9B-B6A8-368E385BFEB9-- From gsalguei@cisco.com Fri Oct 11 00:05:22 2013 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0838721E8143 for ; Fri, 11 Oct 2013 00:05:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SXwwzv5EYaIV for ; Fri, 11 Oct 2013 00:05:16 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 4D8A821F9FB5 for ; Fri, 11 Oct 2013 00:05:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8390; q=dns/txt; s=iport; t=1381475116; x=1382684716; h=from:to:subject:date:message-id:references:content-id: content-transfer-encoding:mime-version; bh=f7BLodO+VMUDUlCZHJglBscHWkJWpwnQURmKNcvlRQA=; b=hNd+YsrhjGmG4v0ycfc9odinxyaa8lhjoFljXZ6uMSjd6PVecAQ4REIO 5j8a8Gn/mLLcpCUY1D1hDph/5mseQLunzFUjWV7EaE6r7baX8rp57dpEl nHJmrI7NbbueqJL27jQtNfe9qVLKVrFf0Cn4kb6krUlp6LJw91aVTud9y 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkkFAOuiV1KtJXG9/2dsb2JhbABagwc4UsFKgSEWbQeCJQEBAQMBAQEBGk4BAhAHBAIBGQMBAgsLGSEGCxQHAggCBBMIDIdgAwkGDLBfDYlrjFqBJIEYBjQEBIMVgQQDiQSLJIF0gxiLHYU2gySBcTk X-IronPort-AV: E=Sophos;i="4.90,1078,1371081600"; d="scan'208";a="270837199" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-7.cisco.com with ESMTP; 11 Oct 2013 07:05:10 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r9B759ZN020073 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 11 Oct 2013 07:05:09 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.27]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.004; Fri, 11 Oct 2013 02:05:09 -0500 From: "Gonzalo Salgueiro (gsalguei)" To: "insipid@ietf.org" Thread-Topic: [RAI] NOMCOM 2013 - UPDATED 2nd Call for Nominations - APP, OAM, RAI, TSV Thread-Index: AQHOxlA45Bpgmwh9RUS/rGpnIVkWmw== Date: Fri, 11 Oct 2013 07:05:08 +0000 Message-ID: References: <5257A241.7060607@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.132.54] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Insipid] Fwd: [RAI] NOMCOM 2013 - UPDATED 2nd Call for Nominations - APP, OAM, RAI, TSV X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Oct 2013 07:05:22 -0000 If interested, please consider volunteering for RAI AD. Cheers, Gonzalo Begin forwarded message: > Resent-From: > From: Gonzalo Camarillo > Subject: Fwd: [RAI] Fwd: NOMCOM 2013 - UPDATED 2nd Call for Nominations -= APP, OAM, RAI, TSV > Date: October 11, 2013 3:01:21 AM EDT > Resent-To: , , , , , , , , , , , , , , , , , , ,= , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , > To: >=20 > Chairs, >=20 > please, distribute this message to your respective WGs. >=20 > Thanks, >=20 > Gonzalo >=20 > -------- Original Message -------- > Subject: [RAI] Fwd: NOMCOM 2013 - UPDATED 2nd Call for Nominations - > APP, OAM, RAI, TSV > Date: Fri, 11 Oct 2013 09:44:23 +0300 > From: Gonzalo Camarillo > To: >=20 > Folks, >=20 > we need more volunteers (see email below). If you are thinking of > running but still have some doubts about it, feel free to talk with me > (or with any of the former RAI ADs) and we will be happy to clarify > everything for you. >=20 > Cheers, >=20 > Gonzalo >=20 >=20 > -------- Original Message -------- > Subject: NOMCOM 2013 - UPDATED 2nd Call for Nominations - APP, OAM, RAI, = TSV > Date: Tue, 8 Oct 2013 11:45:14 -0700 > From: NomCom Chair > Reply-To: > To: IETF Announcement List > CC: >=20 > UPDATE: nominations are too sparse in several of the IESG areas: APP, OA= M, > RAI, and TSV. If you know one or more of those areas, exercise your soci= al > network and submit nominations. We'll be very grateful! >=20 > Is there someone you work with at IETF who has leadership potential and a > growing track record? Please read this Nomcom call for nominations and > consider > nominating her or him. Or several folks! Deadline for nominations is > October 18. > Nominate soon to give your nominee(s) plenty time to fill in the > questionnaire. >=20 > If you're nominated, even if you support the present incumbent, being > reviewed > by Nomcom is great IETF experience. The questionnaire offers a chance to > think about IETF and about your area. Whether or not your candidacy > progresses > this time, you'll have gained some valuable insights, and you'll have > contributed > greatly. This process only works because many IETFers take part; please > join in. >=20 > Lots more, including which positions are open, how to make a nomination > (including nomination of yourself), and how to send us your feedback on > the desired expertise, follows. >=20 > IETFers, let's hear from you! Make nominations, accept nominations! >=20 > If you have any questions about the process, feel free to get in touch > with me. >=20 > Best regards, >=20 > Allison for the Nomcom >=20 > Allison Mankin > Nomcom Chair 2013-14 >=20 > ----- The Info You Need for Nominating ----- >=20 > The 2013-14 Nominating Committee (Nomcom) is seeking nominations > from now until October 18, 2013. The open positions being considered > by this year's Nomcom can be found later in this section, and also on > this year's Nomcom website: >=20 > https://datatracker.ietf.org/nomcom/2013/ >=20 > Information about the desired expertise for positions is here: > https://datatracker.ietf.org/nomcom/2013/expertise >=20 > Nominations may be made by selecting the Nominate link at the top of > the Nomcom 2013 home page, or by visiting the following URL: >=20 > https://datatracker.ietf.org/nomcom/2013/nominate/ >=20 > Note that nominations made using the web tool require an ietf.org > datatracker account. You can create a datatracker ietf.org account > if you don't have one already by visiting the following URL: >=20 > https://datatracker.ietf.org/accounts/create/ >=20 > Nominations may also be made by email to nomcom13 at ietf.org. > If you nominate by email, please include the word "Nominate" in the Subje= ct > and indicate in the email who is being nominated, their email address (to > confirm acceptance of the nomination), and the position for which you > are making the nomination. If you use email, please use a separate email = for > each person you nominate, and for each position (if you are nominating on= e > person for multiple positions). >=20 > Self-nomination is welcome! No need to be shy. >=20 > Nomcom 2013-14 will follow the policy for "Open Disclosure of Willing > Nominees" described in RFC 5680. As stated in RFC 5680: "The list of > nominees willing to be considered for positions under review in the > current Nomcom cycle is not confidential". Willing nominees for each > position will be listed in a publicly accessible way - anyone with a > datatracker account may access the lists. In all other ways, the > confidentiality requirements of RFC 3777/BCP10 remain in effect. All > feedback and all Nomcom deliberations will remain confidential and will > not be disclosed. >=20 > In order to ensure time to collect sufficient community feedback about > each of the willing nominees, nominations must be received by the > Nomcom on or before October 18, 2013. Please submit your nominations > as early as possible for the sake of your nominees, as we've set the > questionnaire submission deadline for October 25, 2013. >=20 > The list of people and posts whose terms end with the March 2014 IETF > meeting, > and thus the positions for which we are accepting nominations: >=20 > IAOC > Chris Griffiths >=20 > IAB > Bernard Aboba > Marc Blanchet > Ross Callon > Eliot Lear > Hannes Tschofenig >=20 > IESG > Barry Leiba (Applications) > Brian Haberman (Internet) > Benoit Claise (Operations and Management) > Gonzalo Camarillo (RAI) > Stewart Bryant (Routing) > Sean Turner (Security) > Martin Stiemerling (Transport) >=20 > Please be resourceful in identifying possible candidates for these > positions, as developing our talent is a very crucial requirement for > the IETF. Also, please give serious consideration to accepting nominatio= ns > you receive. >=20 > The summaries of the desired expertise for the positions, developed by th= e > respective bodies, are found at: >=20 > https://datatracker.ietf.org/nomcom/2013/expertise/ >=20 > In addition to nominations, the Nomcom seeks community input on > the positions themselves. We need and welcome the community's > views and input on the jobs within each organization. If you > have ideas on the positions' responsibilities (more, less, > different), please let us know. You can send us email about this to > nomcom13 at ietf.org, and we will use this feedback actively. >=20 > Thank you for your help in nominating a great pool of strong and interest= ing > nominees! >=20 >=20 >=20 > _______________________________________________ > RAI mailing list > RAI@ietf.org > https://www.ietf.org/mailman/listinfo/rai >=20 >=20 From iesg-secretary@ietf.org Fri Oct 11 09:48:38 2013 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACA1421F9223; Fri, 11 Oct 2013 09:48:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.428 X-Spam-Level: X-Spam-Status: No, score=-102.428 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 90fxr8dKNtN7; Fri, 11 Oct 2013 09:48:38 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BAA621F9A6C; Fri, 11 Oct 2013 09:47:59 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131011164759.4968.64749.idtracker@ietfa.amsl.com> Date: Fri, 11 Oct 2013 09:47:59 -0700 Cc: insipid WG Subject: [Insipid] WG Action: Rechartered INtermediary-safe SIP session ID (insipid) X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Oct 2013 16:48:38 -0000 The INtermediary-safe SIP session ID (insipid) working group in the Real-time Applications and Infrastructure Area of the IETF has been rechartered. For additional information please contact the Area Directors or the WG Chairs. INtermediary-safe SIP session ID (insipid) ------------------------------------------------ Current Status: Active WG Chairs: Gonzalo Salgueiro Keith Drage Assigned Area Director: Gonzalo Camarillo Mailing list Address: insipid@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/insipid Archive: http://www.ietf.org/mail-archive/web/insipid/ Charter: An end-to-end session identifier in SIP-based multimedia communication networks refers to the ability for endpoints, intermediate devices, and management and monitoring system to identify and correlate SIP messages and dialogs of the same higher-level end-to-end "communication session" across multiple SIP devices, hops, and administrative domains. Unfortunately, there are a number of factors that contribute to the fact that the current dialog identifiers defined in SIP are not suitable for end-to-end session identification. Perhaps the most important factor worth describing is that in real-world deployments of Back-to-Back User Agents (B2BUAs) devices like Session Border Controllers (SBC) often change the call identifiers (e.g., the From-tag and To-tag that are used in conjunction with the Call-ID header to make the dialog-id) as the session signaling passes through. An end-to-end session identifier should allow the possibility to identify the communication session from the point of origin, passing through any number of intermediaries, to the ultimate point of termination. It should have the same aim as the From-tag, To-tag and Call-ID conjunction, but should not be mangled by intermediaries. A SIP end-to-end session identifier has been considered as possible solution of different use cases like troubleshooting, billing, session recording, media and signaling correlation, and so forth. Some of these requirements come from other working groups within the RAI area (e.g., SIPRec). Moreover, other standards organizations have identified the need for SIP and H.323 to carry the same "session ID" value so that it is possible to identify a call end-to-end even when performing inter working between protocols. Troubleshooting SIP signalling end-to-end becomes impractical as networks grow and become interconnected, including connection via transit networks, because the path that SIP signalling will take between clients cannot be predicted and the signalling volume and geographical spread are too large. This group will focus on two documents: The first document will specify a SIP identifier that has the same aim as the From-tag, To-tag and Call-ID conjunction, but is less likely to be mangled by intermediaries. In doing this work, the group will pay attention to the privacy implications of a "session ID", for example considering the possibility to make it intractable for nodes to correlate "session IDs" generated by the same user for different sessions. The second document will define an indicator that can be added to the SIP protocol to indicate that signalling should be logged. The indicator will typically be applied as part of network testing controlled by the network operator and not used in regular client signalling. However, such marking can be carried end-to-end including the SIP terminals, even if a session originates and terminates in different networks. Milestones: Dec 2012 - Requirements and use cases for new identifier sent to IESG (as informational) Feb 2013 - Specification of the new identifier sent to the IESG (PS) From gsalguei@cisco.com Fri Oct 11 20:56:07 2013 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3E2711E8100 for ; Fri, 11 Oct 2013 20:56:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ub9C2nEOD7fs for ; Fri, 11 Oct 2013 20:56:02 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 51F4711E8102 for ; Fri, 11 Oct 2013 20:56:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=245; q=dns/txt; s=iport; t=1381550162; x=1382759762; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=2YqPVYSvzx5ihzudDt/ah0pusFMdVRUpXEwnL34cQ2U=; b=ZIFRLVNxQUZHKhf1B21TaSqHR4XeX6WWhDnuzY0OArvfphyKEjFNCOJd bcfaaAwcFOqJiMosRoAjZClKkzyV40pDwAiK0/t6NvOpFgWKvUgMxJYll V5czR9y3QdTiZeLVB+AfWOFyhfOdbw7ysmRn4CpCipChj89UXfWhT/1Qr g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiEFAPHGWFKtJXG+/2dsb2JhbABagweBCsFegR0WbQeCJwEEOjQLEgEqFEInBA4Nh368Mo8cMYMmgQQDqgeDJIIp X-IronPort-AV: E=Sophos;i="4.93,479,1378857600"; d="scan'208";a="271234782" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-7.cisco.com with ESMTP; 12 Oct 2013 03:56:01 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r9C3u0bj016163 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 12 Oct 2013 03:56:01 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.27]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0318.004; Fri, 11 Oct 2013 22:56:00 -0500 From: "Gonzalo Salgueiro (gsalguei)" To: "insipid@ietf.org" Thread-Topic: Please send agenda items and requests to chairs Thread-Index: AQHOxv72ojTfXwdFxkGwZURgIajPkg== Date: Sat, 12 Oct 2013 03:55:59 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.132.54] Content-Type: text/plain; charset="us-ascii" Content-ID: <89FFB7D4741D7F498C872C69110C263D@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "insipid-chairs@tools.ietf.org" Subject: [Insipid] Please send agenda items and requests to chairs X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Oct 2013 03:56:08 -0000 INSIPID will be meeting on Monday Nov 4 from 17:40 to 19:40 in Plaza C. Please send both Keith and I any agenda items and requests. =20 Issues discussed on the mailing list will, of course, be given preference. Regards, Gonzalo & Keith From Peter.Dawes@vodafone.com Fri Oct 18 04:14:32 2013 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBA7121F9AED for ; Fri, 18 Oct 2013 04:14:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.372 X-Spam-Level: X-Spam-Status: No, score=-2.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nDzxvoAsN2mt for ; Fri, 18 Oct 2013 04:14:27 -0700 (PDT) Received: from mailout09.vodafone.com (mailout09.vodafone.com [195.232.224.78]) by ietfa.amsl.com (Postfix) with ESMTP id 8B5E511E81F5 for ; Fri, 18 Oct 2013 04:14:27 -0700 (PDT) Received: from mailint09.vodafone.com (localhost [127.0.0.1]) by mailout09.vodafone.com (Postfix) with ESMTP id 7D877E1417 for ; Fri, 18 Oct 2013 13:14:24 +0200 (CEST) Received: from VOEXC06W.internal.vodafone.com (voexc06w.dc-ratingen.de [145.230.101.26]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailint09.vodafone.com (Postfix) with ESMTPS id 0C78AE1543; Fri, 18 Oct 2013 13:14:24 +0200 (CEST) Received: from VOEXC12W.internal.vodafone.com (145.230.101.14) by VOEXC06W.internal.vodafone.com (145.230.101.26) with Microsoft SMTP Server (TLS) id 14.3.146.2; Fri, 18 Oct 2013 13:14:22 +0200 Received: from VOEXM31W.internal.vodafone.com ([169.254.7.164]) by voexc12w.internal.vodafone.com ([145.230.101.14]) with mapi id 14.03.0146.002; Fri, 18 Oct 2013 13:14:21 +0200 From: "Dawes, Peter, Vodafone Group" To: Paul Kyzivat , "insipid@ietf.org" Thread-Topic: [Insipid] draft-dawes-dispatch-logme-reqs-02 (repost to insipid) Thread-Index: AQHOh090Gf3fTJI8hUe/mT1XtHhuh5l9lmLQgH062eA= Date: Fri, 18 Oct 2013 11:14:20 +0000 Message-ID: <4A4F136CBD0E0D44AE1EDE36C4CD9D996EEA5E3A@VOEXM31W.internal.vodafone.com> References: <51EDEF82.3060908@alum.mit.edu> <4A4F136CBD0E0D44AE1EDE36C4CD9D996EE917CA@VOEXM31W.internal.vodafone.com> In-Reply-To: <4A4F136CBD0E0D44AE1EDE36C4CD9D996EE917CA@VOEXM31W.internal.vodafone.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Insipid] draft-dawes-dispatch-logme-reqs-02 (repost to insipid) X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 11:14:33 -0000 Hi Paul, I have now updated the requirements draft to -03 (http://www.ietf.org/id/dr= aft-dawes-dispatch-logme-reqs-03.txt) to include the following: 1) For when servers are expected to be stateful and when logging stops, add= ed a new clause for functionality that is common to all solutions 7.1. Functionality Common to all Solutions=20 7.1.1. Starting and Stopping log-me marking 7.1.1.1. General 7.1.1.2. Configuration for log-me marking 7.1.1.3. Maintaining State 3) For protocol to transmit the logs, I can't think of any consideration th= at is specific to transmitting logged information so transmission can pick = from the same protocol options that are available to transmit any file (ftp= , mailto, http...) 4) For " trust by the server doing the logging of the log server, and autho= rization by the log server of those sending logs " I have added some sub-cl= auses (6.2.2, 6.2.3) to the Security Considerations clause. I guess that ft= p, mailto, http etc. already have defined security solutions for authentica= tion and encryption so I didn't add much detail at this stage to avoid just= copying descriptions. 6. Security Considerations=20 6.1. Trust Domain =20 6.2. Security Threats =20 6.2.1. Log-me marking =20 6.2.2. Debug server address =20 6.2.3. Sending logged information =20 5) For where the test case goes in the Call-Info: header field solution in = 7.3 (was in 7.2 in version -02) I have stated that using Session-ID is the = only possibility and I have corrected the syntax of the Call-Info: header f= ield in Figure 3 to make the domain name a URL. =20 Regards, Peter -----Original Message----- From: Dawes, Peter, Vodafone Group=20 Sent: 31 July 2013 13:32 To: 'Paul Kyzivat'; insipid@ietf.org Subject: RE: [Insipid] draft-dawes-dispatch-logme-reqs-02 (repost to insipi= d) Hello Paul, Thanks for the questions, I can add some discussion of these points by expa= nding on the potential solutions clause 7 in the next version of the draft.= Extra text will be along the lines of the answers below. =20 1) For "when some servers are expected to be dialog stateful. Also if loggi= ng is to stop after some period of time." The stateful entities can be the sending and receiving UA, and a SIP proxy = if the UAs do not insert and echo the log-me marker (REQ5, REQ6). I can des= cribe this behaviour in the potential solutions. How logging stops is hinted at in clause 4 but I can give examples in the p= otential solutions. I do not propose that the draft specifies how logging i= s configured to be started and stopped though, the main focus of the draft = is to add a marker for sessions of interest to logging.=20 2) For " Is free text good enough for identifying test cases? Isn't there p= ossibility of collision? Since there is likely to be resistance to meaningf= ul names that might tunnel information, perhaps these should be random numb= ers." These are good questions, it might well be that the Session-ID: value becom= es the test case identifier.=20 3) For protocol to transmit the logs, RFC 6872 "The Common Log Format (CLF)= for the Session Initiation Protocol (SIP): Framework and Information Model= " has been suggested so I will look into this.=20 4) For " trust by the server doing the logging of the log server, and autho= rization by the log server of those sending logs " I think mechanisms exist= for mutual authentication of sender and receiver so I can add something. I will also try to ensure that the descriptions of proposed solutions cover= all aspects of the draft (log server, test case id) and thanks for spottin= g the syntax error in Fig. 3. Regards, Peter -----Original Message----- From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behalf = Of Paul Kyzivat Sent: 23 July 2013 04:51 To: insipid@ietf.org Subject: [Insipid] draft-dawes-dispatch-logme-reqs-02 (repost to insipid) Some questions about this draft: The requirements and other discussion imply certain behavior by servers tha= t support this. I'd like to hear more explicit discussion of what that expe= cted behavior is, within the potential solutions. E.g., when some servers are expected to be dialog stateful. Also if logging= is to stop after some period of time. Section 7.1: This says the header is first inserted by the UAC. There might be reason to= have it inserted by the UAS in some cases, or even a proxy or B2BUA based = on policy for debugging a UA that can't be controlled. Is free text good enough for identifying test cases? Isn't there possibilit= y of collision? Since there is likely to be resistance to meaningful names = that might tunnel information, perhaps these should be random numbers. I want to hear more about sending the address of the server collecting logs= . For this to be useful there must be an explicit or implicit protocol used= to transmit the logs. Is there one such protocol or many?=20 If many, how do you know which will be supported? What about trust by the s= erver doing the logging of the log server, and authorization by the log ser= ver of those sending logs? Will all servers doing logging want to use a ser= ver chosen by the one inserting the logme request? Section 7.2: Where does the test case id go with this solution? In Figure 3 the call-info in the figure is syntactically incorrect. The par= ameter is a domain name, but it is required to be a URL. Thanks, Paul _______________________________________________ insipid mailing list insipid@ietf.org https://www.ietf.org/mailman/listinfo/insipid From keith.drage@alcatel-lucent.com Fri Oct 18 04:31:06 2013 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7101F21F9CA4 for ; Fri, 18 Oct 2013 04:31:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.485 X-Spam-Level: X-Spam-Status: No, score=-110.485 tagged_above=-999 required=5 tests=[AWL=-0.113, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fxFWUmHO6vkF for ; Fri, 18 Oct 2013 04:30:57 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id DF35921F99CE for ; Fri, 18 Oct 2013 04:30:56 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id r9IBUss0004089 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 18 Oct 2013 06:30:55 -0500 (CDT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id r9IBUr14003809 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 18 Oct 2013 13:30:53 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.239]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Fri, 18 Oct 2013 13:30:53 +0200 From: "DRAGE, Keith (Keith)" To: "Dawes, Peter, Vodafone Group" , "insipid@ietf.org" Thread-Topic: [Insipid] draft-dawes-dispatch-logme-reqs-02 (repost to insipid) Thread-Index: AQHOh090Gf3fTJI8hUe/mT1XtHhuh5l9lmLQgH062eCAAAqOcA== Date: Fri, 18 Oct 2013 11:30:53 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B0BAFAA@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <51EDEF82.3060908@alum.mit.edu> <4A4F136CBD0E0D44AE1EDE36C4CD9D996EE917CA@VOEXM31W.internal.vodafone.com> <4A4F136CBD0E0D44AE1EDE36C4CD9D996EEA5E3A@VOEXM31W.internal.vodafone.com> In-Reply-To: <4A4F136CBD0E0D44AE1EDE36C4CD9D996EEA5E3A@VOEXM31W.internal.vodafone.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.39] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Subject: Re: [Insipid] draft-dawes-dispatch-logme-reqs-02 (repost to insipid) X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 11:31:06 -0000 The INSIPID charter has been extended to include this work. It would be good to see discussion of this draft on the list, or alternativ= ely, if any of you think you can better this with an alternative, the submi= ssion of your own draft. We haven't decided when yet, but at some point we will have a call to make = a requirements draft a working group document. Regards Keith=20 > -----Original Message----- > From: insipid-bounces@ietf.org=20 > [mailto:insipid-bounces@ietf.org] On Behalf Of Dawes, Peter,=20 > Vodafone Group > Sent: 18 October 2013 12:14 > To: Paul Kyzivat; insipid@ietf.org > Subject: Re: [Insipid] draft-dawes-dispatch-logme-reqs-02=20 > (repost to insipid) >=20 > Hi Paul, > I have now updated the requirements draft to -03=20 > (http://www.ietf.org/id/draft-dawes-dispatch-logme-reqs-03.txt > ) to include the following: >=20 > 1) For when servers are expected to be stateful and when=20 > logging stops, added a new clause for functionality that is=20 > common to all solutions > 7.1. Functionality Common to all Solutions=20 > 7.1.1. Starting and Stopping log-me marking > 7.1.1.1. General > 7.1.1.2. Configuration for=20 > log-me marking > 7.1.1.3. Maintaining State >=20 > 3) For protocol to transmit the logs, I can't think of any=20 > consideration that is specific to transmitting logged=20 > information so transmission can pick from the same protocol=20 > options that are available to transmit any file (ftp, mailto, http...) >=20 > 4) For " trust by the server doing the logging of the log=20 > server, and authorization by the log server of those sending=20 > logs " I have added some sub-clauses (6.2.2, 6.2.3) to the=20 > Security Considerations clause. I guess that ftp, mailto,=20 > http etc. already have defined security solutions for=20 > authentication and encryption so I didn't add much detail at=20 > this stage to avoid just copying descriptions. >=20 > 6. Security Considerations=20 > 6.1. Trust Domain =20 > 6.2. Security Threats =20 > 6.2.1. Log-me marking =20 > 6.2.2. Debug server address =20 > 6.2.3. Sending logged information =20 >=20 > 5) For where the test case goes in the Call-Info: header=20 > field solution in 7.3 (was in 7.2 in version -02) I have=20 > stated that using Session-ID is the only possibility and I=20 > have corrected the syntax of the Call-Info: header field in=20 > Figure 3 to make the domain name a URL. =20 >=20 > Regards, > Peter >=20 >=20 > -----Original Message----- > From: Dawes, Peter, Vodafone Group > Sent: 31 July 2013 13:32 > To: 'Paul Kyzivat'; insipid@ietf.org > Subject: RE: [Insipid] draft-dawes-dispatch-logme-reqs-02=20 > (repost to insipid) >=20 > Hello Paul, > Thanks for the questions, I can add some discussion of these=20 > points by expanding on the potential solutions clause 7 in=20 > the next version of the draft. Extra text will be along the=20 > lines of the answers below. > =20 > 1) For "when some servers are expected to be dialog stateful.=20 > Also if logging is to stop after some period of time." > The stateful entities can be the sending and receiving UA,=20 > and a SIP proxy if the UAs do not insert and echo the log-me=20 > marker (REQ5, REQ6). I can describe this behaviour in the=20 > potential solutions. > How logging stops is hinted at in clause 4 but I can give=20 > examples in the potential solutions. I do not propose that=20 > the draft specifies how logging is configured to be started=20 > and stopped though, the main focus of the draft is to add a=20 > marker for sessions of interest to logging.=20 >=20 > 2) For " Is free text good enough for identifying test cases?=20 > Isn't there possibility of collision? Since there is likely=20 > to be resistance to meaningful names that might tunnel=20 > information, perhaps these should be random numbers." > These are good questions, it might well be that the=20 > Session-ID: value becomes the test case identifier.=20 >=20 > 3) For protocol to transmit the logs, RFC 6872 "The Common=20 > Log Format (CLF) for the Session Initiation Protocol (SIP):=20 > Framework and Information Model" has been suggested so I will=20 > look into this.=20 >=20 > 4) For " trust by the server doing the logging of the log=20 > server, and authorization by the log server of those sending=20 > logs " I think mechanisms exist for mutual authentication of=20 > sender and receiver so I can add something. >=20 > I will also try to ensure that the descriptions of proposed=20 > solutions cover all aspects of the draft (log server, test=20 > case id) and thanks for spotting the syntax error in Fig. 3. >=20 > Regards, > Peter >=20 > -----Original Message----- > From: insipid-bounces@ietf.org=20 > [mailto:insipid-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: 23 July 2013 04:51 > To: insipid@ietf.org > Subject: [Insipid] draft-dawes-dispatch-logme-reqs-02 (repost=20 > to insipid) >=20 > Some questions about this draft: >=20 > The requirements and other discussion imply certain behavior=20 > by servers that support this. I'd like to hear more explicit=20 > discussion of what that expected behavior is, within the=20 > potential solutions. >=20 > E.g., when some servers are expected to be dialog stateful.=20 > Also if logging is to stop after some period of time. >=20 > Section 7.1: >=20 > This says the header is first inserted by the UAC. There=20 > might be reason to have it inserted by the UAS in some cases,=20 > or even a proxy or B2BUA based on policy for debugging a UA=20 > that can't be controlled. >=20 > Is free text good enough for identifying test cases? Isn't=20 > there possibility of collision? Since there is likely to be=20 > resistance to meaningful names that might tunnel information,=20 > perhaps these should be random numbers. >=20 > I want to hear more about sending the address of the server=20 > collecting logs. For this to be useful there must be an=20 > explicit or implicit protocol used to transmit the logs. Is=20 > there one such protocol or many?=20 > If many, how do you know which will be supported? What about=20 > trust by the server doing the logging of the log server, and=20 > authorization by the log server of those sending logs? Will=20 > all servers doing logging want to use a server chosen by the=20 > one inserting the logme request? >=20 > Section 7.2: >=20 > Where does the test case id go with this solution? >=20 > In Figure 3 the call-info in the figure is syntactically=20 > incorrect. The parameter is a domain name, but it is required=20 > to be a URL. >=20 > Thanks, > Paul > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid > = From pkyzivat@alum.mit.edu Fri Oct 18 10:00:26 2013 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39C1311E826F for ; Fri, 18 Oct 2013 10:00:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.156 X-Spam-Level: X-Spam-Status: No, score=-0.156 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xQJnniLmEI0p for ; Fri, 18 Oct 2013 10:00:21 -0700 (PDT) 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 D68AF11E8302 for ; Fri, 18 Oct 2013 09:59:16 -0700 (PDT) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta12.westchester.pa.mail.comcast.net with comcast id ecAL1m0051c6gX85Cgz03G; Fri, 18 Oct 2013 16:59:00 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta23.westchester.pa.mail.comcast.net with comcast id egyz1m00M3ZTu2S3jgz0uF; Fri, 18 Oct 2013 16:59:00 +0000 Message-ID: <526168D3.7050200@alum.mit.edu> Date: Fri, 18 Oct 2013 12:58:59 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "Dawes, Peter, Vodafone Group" References: <51EDEF82.3060908@alum.mit.edu> <4A4F136CBD0E0D44AE1EDE36C4CD9D996EE917CA@VOEXM31W.internal.vodafone.com> In-Reply-To: <4A4F136CBD0E0D44AE1EDE36C4CD9D996EE917CA@VOEXM31W.internal.vodafone.com> 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=1382115540; bh=cHqzRPO2n7CKohGQdmLmPt5/0/VlGefSgqIDThf8oYo=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=MS3NNg9ultwgRTO9lrDKbAyAxPQhcDL5WEQZt8wHNXh6vyrxkY0buuERGtGA/o9wV WqwbYMjM3ldx5h31Z0iM3bts1FJmmIl8n6dMV7LN5JR0Mp7dbz+xdchpcXS4wLLZeJ probHTgJhKJ0JSnFVj/VIb7IinOv6/wVqlbVYoF/udM+0y8+Ye/Q/m3N1ohS/KUdYI 7hTM5GZrW+/KHEiY7MOfyZAN/1Gi+rvP6YoIwSP4Gn46jtUPecpMbZ+JwghU3z/hgR AIHsHTUL9ay6FRLX1bCoARFj4rqHzvfBlmVqrGjMe4+Rbm7V7I+/z2vhRPb2ptCSpW Qjj69R5SSWNKA== Cc: "insipid@ietf.org" Subject: Re: [Insipid] draft-dawes-dispatch-logme-reqs-02 (repost to insipid) X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 17:00:26 -0000 Hi Peter, A few followups. On 7/31/13 8:31 AM, Dawes, Peter, Vodafone Group wrote: > Hello Paul, > Thanks for the questions, I can add some discussion of these points by expanding on the potential solutions clause 7 in the next version of the draft. Extra text will be along the lines of the answers below. > > 1) For "when some servers are expected to be dialog stateful. Also if logging is to stop after some period of time." > The stateful entities can be the sending and receiving UA, and a SIP proxy if the UAs do not insert and echo the log-me marker (REQ5, REQ6). I can describe this behaviour in the potential solutions. OK. The issue is new state that must be retained to support this draft. And its more of an issue for proxies, because proxies usually hold less state. (Many are not dialog stateful.) > How logging stops is hinted at in clause 4 but I can give examples in the potential solutions. I do not propose that the draft specifies how logging is configured to be started and stopped though, the main focus of the draft is to add a marker for sessions of interest to logging. I don't recall why I mentioned this. > 2) For " Is free text good enough for identifying test cases? Isn't there possibility of collision? Since there is likely to be resistance to meaningful names that might tunnel information, perhaps these should be random numbers." > These are good questions, it might well be that the Session-ID: value becomes the test case identifier. > > 3) For protocol to transmit the logs, RFC 6872 "The Common Log Format (CLF) for the Session Initiation Protocol (SIP): Framework and Information Model" has been suggested so I will look into this. That defines a file format, not a protocol. You could potentially specify a protocol that can carry a file in CLF format. > 4) For " trust by the server doing the logging of the log server, and authorization by the log server of those sending logs " I think mechanisms exist for mutual authentication of sender and receiver so I can add something. This is entangled with choosing the protocol for transmission. > I will also try to ensure that the descriptions of proposed solutions cover all aspects of the draft (log server, test case id) and thanks for spotting the syntax error in Fig. 3. Thanks, Paul > Regards, > Peter > > -----Original Message----- > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: 23 July 2013 04:51 > To: insipid@ietf.org > Subject: [Insipid] draft-dawes-dispatch-logme-reqs-02 (repost to insipid) > > Some questions about this draft: > > The requirements and other discussion imply certain behavior by servers that support this. I'd like to hear more explicit discussion of what that expected behavior is, within the potential solutions. > > E.g., when some servers are expected to be dialog stateful. Also if logging is to stop after some period of time. > > Section 7.1: > > This says the header is first inserted by the UAC. There might be reason to have it inserted by the UAS in some cases, or even a proxy or B2BUA based on policy for debugging a UA that can't be controlled. > > Is free text good enough for identifying test cases? Isn't there possibility of collision? Since there is likely to be resistance to meaningful names that might tunnel information, perhaps these should be random numbers. > > I want to hear more about sending the address of the server collecting logs. For this to be useful there must be an explicit or implicit protocol used to transmit the logs. Is there one such protocol or many? > If many, how do you know which will be supported? What about trust by the server doing the logging of the log server, and authorization by the log server of those sending logs? Will all servers doing logging want to use a server chosen by the one inserting the logme request? > > Section 7.2: > > Where does the test case id go with this solution? > > In Figure 3 the call-info in the figure is syntactically incorrect. The parameter is a domain name, but it is required to be a URL. > > Thanks, > Paul > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid > From gsalguei@cisco.com Fri Oct 18 10:31:35 2013 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04DA611E8231 for ; Fri, 18 Oct 2013 10:31:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.41 X-Spam-Level: X-Spam-Status: No, score=-10.41 tagged_above=-999 required=5 tests=[AWL=-0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jnmBxQZBW3lt for ; Fri, 18 Oct 2013 10:31:30 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 6CBA311E826F for ; Fri, 18 Oct 2013 10:31:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3275; q=dns/txt; s=iport; t=1382117486; x=1383327086; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=KNwPvMPWlh0TNh3k7CKu2mDK/54oFONiTsGCMQGV0A8=; b=Q8FIz+ZezoNGCWqWN4pAqbewx6/a95UN/adQvFwzFkI5YnAHMrw8kr6q X+S09K/o3591whlhazpuxikizIC0IAiX30TEEEjSBFDoqvm4asVE9LJ0V DCnqS2MR/c+BJPyQGjz9F2DZeSdgee68JP+0XDobIz7KDOxDlwzYYEzqF g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAEFvYVKtJXG8/2dsb2JhbABaDoJ5OFK9WUuBIRZ0giUBAQEDAQEBATc0CwwEAgEIDgMEAQELFAkHJwsUCQgCBA4FCBOHZQYMwRYEjyMCMQcGgxmBCgOqEIJlP4Ip X-IronPort-AV: E=Sophos;i="4.93,524,1378857600"; d="scan'208";a="273826886" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-2.cisco.com with ESMTP; 18 Oct 2013 17:31:01 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r9IHV1K6030994 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 18 Oct 2013 17:31:01 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.27]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.004; Fri, 18 Oct 2013 12:31:01 -0500 From: "Gonzalo Salgueiro (gsalguei)" To: Paul Kyzivat Thread-Topic: [Insipid] draft-dawes-dispatch-logme-reqs-02 (repost to insipid) Thread-Index: AQHOzCNWGf3fTJI8hUe/mT1XtHhuh5n7CyoA Date: Fri, 18 Oct 2013 17:31:00 +0000 Message-ID: References: <51EDEF82.3060908@alum.mit.edu> <4A4F136CBD0E0D44AE1EDE36C4CD9D996EE917CA@VOEXM31W.internal.vodafone.com> <526168D3.7050200@alum.mit.edu> In-Reply-To: <526168D3.7050200@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.132.54] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Dawes, Peter, Vodafone Group" , "insipid@ietf.org" Subject: Re: [Insipid] draft-dawes-dispatch-logme-reqs-02 (repost to insipid) X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 17:31:35 -0000 >>=20 >> 3) For protocol to transmit the logs, RFC 6872 "The Common Log Format (C= LF) for the Session Initiation Protocol (SIP): Framework and Information Mo= del" has been suggested so I will look into this. >=20 > That defines a file format, not a protocol. You could potentially specify= a protocol that can carry a file in CLF format. Just a nit: 6872 defines the Information Model, whereas 6873 defines the a= ctual file format. Cheers, Gonzalo >=20 >> 4) For " trust by the server doing the logging of the log server, and au= thorization by the log server of those sending logs " I think mechanisms ex= ist for mutual authentication of sender and receiver so I can add something= . >=20 > This is entangled with choosing the protocol for transmission. >=20 >> I will also try to ensure that the descriptions of proposed solutions co= ver all aspects of the draft (log server, test case id) and thanks for spot= ting the syntax error in Fig. 3. >=20 > Thanks, > Paul >=20 >> Regards, >> Peter >>=20 >> -----Original Message----- >> From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Beha= lf Of Paul Kyzivat >> Sent: 23 July 2013 04:51 >> To: insipid@ietf.org >> Subject: [Insipid] draft-dawes-dispatch-logme-reqs-02 (repost to insipid= ) >>=20 >> Some questions about this draft: >>=20 >> The requirements and other discussion imply certain behavior by servers = that support this. I'd like to hear more explicit discussion of what that e= xpected behavior is, within the potential solutions. >>=20 >> E.g., when some servers are expected to be dialog stateful. Also if logg= ing is to stop after some period of time. >>=20 >> Section 7.1: >>=20 >> This says the header is first inserted by the UAC. There might be reason= to have it inserted by the UAS in some cases, or even a proxy or B2BUA bas= ed on policy for debugging a UA that can't be controlled. >>=20 >> Is free text good enough for identifying test cases? Isn't there possibi= lity of collision? Since there is likely to be resistance to meaningful nam= es that might tunnel information, perhaps these should be random numbers. >>=20 >> I want to hear more about sending the address of the server collecting l= ogs. For this to be useful there must be an explicit or implicit protocol u= sed to transmit the logs. Is there one such protocol or many? >> If many, how do you know which will be supported? What about trust by th= e server doing the logging of the log server, and authorization by the log = server of those sending logs? Will all servers doing logging want to use a = server chosen by the one inserting the logme request? >>=20 >> Section 7.2: >>=20 >> Where does the test case id go with this solution? >>=20 >> In Figure 3 the call-info in the figure is syntactically incorrect. The = parameter is a domain name, but it is required to be a URL. >>=20 >> Thanks, >> Paul >> _______________________________________________ >> insipid mailing list >> insipid@ietf.org >> https://www.ietf.org/mailman/listinfo/insipid >>=20 >=20 > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid From pkyzivat@alum.mit.edu Fri Oct 18 10:53:29 2013 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA6B221F9AD2 for ; Fri, 18 Oct 2013 10:53:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.157 X-Spam-Level: X-Spam-Status: No, score=-0.157 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wkrymnIC+prX for ; Fri, 18 Oct 2013 10:53:25 -0700 (PDT) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id E47F421F9433 for ; Fri, 18 Oct 2013 10:53:24 -0700 (PDT) Received: from omta03.westchester.pa.mail.comcast.net ([76.96.62.27]) by qmta02.westchester.pa.mail.comcast.net with comcast id edYl1m0040bG4ec51htQiS; Fri, 18 Oct 2013 17:53:24 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta03.westchester.pa.mail.comcast.net with comcast id ehtP1m0113ZTu2S3PhtPBk; Fri, 18 Oct 2013 17:53:23 +0000 Message-ID: <52617592.7090000@alum.mit.edu> Date: Fri, 18 Oct 2013 13:53:22 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: insipid@ietf.org References: <51EDEF82.3060908@alum.mit.edu> <4A4F136CBD0E0D44AE1EDE36C4CD9D996EE917CA@VOEXM31W.internal.vodafone.com> <4A4F136CBD0E0D44AE1EDE36C4CD9D996EEA5E3A@VOEXM31W.internal.vodafone.com> In-Reply-To: <4A4F136CBD0E0D44AE1EDE36C4CD9D996EEA5E3A@VOEXM31W.internal.vodafone.com> 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=1382118804; bh=DEqD0j/pB4TrdqcC28cR1yOaFjnYy9Lcmj3rl57uXlI=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=jdetsooWk4X/57xM4m8rPDTyOdXVFgZXgRRCRQWwkkXOlG3JVk/ZLzsXgv6IUIQjZ kmMFYNyaMLi0Jpd1ithA9CTzucvICZnzkMYy0QJFE1IiEe0IwxnYfyYE826Q1D3lPU pYZSI6FsBJJ4/3iXEGNm2hCSafoL1WR+slZeREKU1LkED3GgFxhgrse2hf5I4mbFqk DLwddUYtVMVj5AMMlUkV6khGnT4WoFz7VpXU6uHN0MpprXkcbUIM9+rm7LPiZQ87xV 76FTh8lw5DGtvdORB15cMFYX32HSh/LxLJUXdniiNYZPKHapGo0ihty9PsusrL2qVY t3GGRIDdd4LbA== Subject: Re: [Insipid] draft-dawes-dispatch-logme-reqs-02 (repost to insipid) X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 17:53:29 -0000 On 10/18/13 7:14 AM, Dawes, Peter, Vodafone Group wrote: > Hi Paul, > I have now updated the requirements draft to -03 (http://www.ietf.org/id/draft-dawes-dispatch-logme-reqs-03.txt) to include the following: > > 1) For when servers are expected to be stateful and when logging stops, added a new clause for functionality that is common to all solutions > 7.1. Functionality Common to all Solutions > 7.1.1. Starting and Stopping log-me marking > 7.1.1.1. General > 7.1.1.2. Configuration for log-me marking > 7.1.1.3. Maintaining State Thanks, this is better. > 3) For protocol to transmit the logs, I can't think of any consideration that is specific to transmitting logged information so transmission can pick from the same protocol options that are available to transmit any file (ftp, mailto, http...) IIUC, your intent is to put a URL into requests that will be used by multiple elements to send their logs. That means: - it must be a protocol that has a URL - the URL must not identify a destination that will be overwritten each time another server uploads to it. - the element inserting the URL must have reason to expect that all the servers that are doing logging will support that URL format. - the servers doing the uploading must understand *how* to use the protocol of the URL for uploading a file. (E.g., if it is an http url, then is a POST used? How is the log file packaged in it?) I think this means that it will be necessary to specify one or more URL formats, and how they should be used for this purpose. How does this relate to the test name? I would think that maybe the place you want to put the test name is in the URL, because its main use is probably to identify where it is deposited. > 4) For " trust by the server doing the logging of the log server, and authorization by the log server of those sending logs " I have added some sub-clauses (6.2.2, 6.2.3) to the Security Considerations clause. I guess that ftp, mailto, http etc. already have defined security solutions for authentication and encryption so I didn't add much detail at this stage to avoid just copying descriptions. > > 6. Security Considerations > 6.1. Trust Domain > 6.2. Security Threats > 6.2.1. Log-me marking > 6.2.2. Debug server address > 6.2.3. Sending logged information > > 5) For where the test case goes in the Call-Info: header field solution in 7.3 (was in 7.2 in version -02) I have stated that using Session-ID is the only possibility and I have corrected the syntax of the Call-Info: header field in Figure 3 to make the domain name a URL. Other comments, by section: Section 6.2.2: What about change of log server? What should happen if the request that initiated logging had one log server URL, and then a subsequent request has a different URL? Does the new one just replace the old one, with the last one in effect when logging stops being the one that is used? Or are changes ignored? Or does a change cause the log to date to be sent to the old server and then a new log started that will be sent to the new server? Section 7.1.1: Another question re ending of logging: Consider a case where a server has been getting a LogMe in a particular dialog. Then it stops getting it. Should this be an indication that logging should be stopped? Or is it to be treated as a case where the upstream element forgot to include it? Section 7.2.6, Figure 4: In (1) there is 'debugServer-"d2.foocorp.com"'. There is also a Debug Server of d1.foocorp.com in the signaling path. Multiple issues with this: - it's potentially confusing. Is it intended to imply that the presence of this address in the LogMe *caused" the debug server to be in the signaling path? I don't think so. I think it is just a coincidence of names. - 'd1.foocorp.com' is not a URL. - the flow doesn't show the log being sent when logging ends. It would be good to show that. Section 7.3: a mailto URL does seem like it could serve the purpose better than most I can think of. But the logs could easily become too big to be accepted by many mail servers. Conceivably the test id could be encoded in the mailbox address. Otherwise I guess you would probably put the session id in the subject line of the mail. Thanks, Paul > Regards, > Peter > > > -----Original Message----- > From: Dawes, Peter, Vodafone Group > Sent: 31 July 2013 13:32 > To: 'Paul Kyzivat'; insipid@ietf.org > Subject: RE: [Insipid] draft-dawes-dispatch-logme-reqs-02 (repost to insipid) > > Hello Paul, > Thanks for the questions, I can add some discussion of these points by expanding on the potential solutions clause 7 in the next version of the draft. Extra text will be along the lines of the answers below. > > 1) For "when some servers are expected to be dialog stateful. Also if logging is to stop after some period of time." > The stateful entities can be the sending and receiving UA, and a SIP proxy if the UAs do not insert and echo the log-me marker (REQ5, REQ6). I can describe this behaviour in the potential solutions. > How logging stops is hinted at in clause 4 but I can give examples in the potential solutions. I do not propose that the draft specifies how logging is configured to be started and stopped though, the main focus of the draft is to add a marker for sessions of interest to logging. > > 2) For " Is free text good enough for identifying test cases? Isn't there possibility of collision? Since there is likely to be resistance to meaningful names that might tunnel information, perhaps these should be random numbers." > These are good questions, it might well be that the Session-ID: value becomes the test case identifier. > > 3) For protocol to transmit the logs, RFC 6872 "The Common Log Format (CLF) for the Session Initiation Protocol (SIP): Framework and Information Model" has been suggested so I will look into this. > > 4) For " trust by the server doing the logging of the log server, and authorization by the log server of those sending logs " I think mechanisms exist for mutual authentication of sender and receiver so I can add something. > > I will also try to ensure that the descriptions of proposed solutions cover all aspects of the draft (log server, test case id) and thanks for spotting the syntax error in Fig. 3. > > Regards, > Peter > > -----Original Message----- > From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: 23 July 2013 04:51 > To: insipid@ietf.org > Subject: [Insipid] draft-dawes-dispatch-logme-reqs-02 (repost to insipid) > > Some questions about this draft: > > The requirements and other discussion imply certain behavior by servers that support this. I'd like to hear more explicit discussion of what that expected behavior is, within the potential solutions. > > E.g., when some servers are expected to be dialog stateful. Also if logging is to stop after some period of time. > > Section 7.1: > > This says the header is first inserted by the UAC. There might be reason to have it inserted by the UAS in some cases, or even a proxy or B2BUA based on policy for debugging a UA that can't be controlled. > > Is free text good enough for identifying test cases? Isn't there possibility of collision? Since there is likely to be resistance to meaningful names that might tunnel information, perhaps these should be random numbers. > > I want to hear more about sending the address of the server collecting logs. For this to be useful there must be an explicit or implicit protocol used to transmit the logs. Is there one such protocol or many? > If many, how do you know which will be supported? What about trust by the server doing the logging of the log server, and authorization by the log server of those sending logs? Will all servers doing logging want to use a server chosen by the one inserting the logme request? > > Section 7.2: > > Where does the test case id go with this solution? > > In Figure 3 the call-info in the figure is syntactically incorrect. The parameter is a domain name, but it is required to be a URL. > > Thanks, > Paul > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid > From gsalguei@cisco.com Thu Oct 24 07:21:05 2013 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B9E911E8279 for ; Thu, 24 Oct 2013 07:21:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YlSEMpcvmXEE for ; Thu, 24 Oct 2013 07:21:00 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 82B9B11E8179 for ; Thu, 24 Oct 2013 07:21:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=351; q=dns/txt; s=iport; t=1382624460; x=1383834060; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=EHsjD3wpaSYVMT+uGORCvTkylsjTsBaJhVahcK6GK5o=; b=X3QoMSeVdWitwQZNnDAdJwC0BNSOcp6irbH30SQmpmYD3U7KvzSkWzTl 3aZI+P05vUe7RowOpT8UOIUsZk5PUWH96b6MaxbMmILdfbZ8RQ4JRrDNW 5ndAVbwH4/iqNv+LidrPthPp4Faw4v8jg/cc4x9/Z+HmLIUIFNKCGPwYf 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkgGAK8raVKtJV2Z/2dsb2JhbABZgwc4VL5YgRsWbQeCJwEEOj8SASoUQhQTBA4FCId/DbogBI8cMYMmgQ0DqhGDJIIq X-IronPort-AV: E=Sophos;i="4.93,562,1378857600"; d="scan'208";a="276127576" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-7.cisco.com with ESMTP; 24 Oct 2013 14:21:00 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r9OEKxkf008678 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 24 Oct 2013 14:20:59 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.27]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0318.004; Thu, 24 Oct 2013 09:20:59 -0500 From: "Gonzalo Salgueiro (gsalguei)" To: "insipid@ietf.org" Thread-Topic: IETF88 INSIPID Draft Agenda Posted Thread-Index: AQHO0MRCByFR+CaHlEyjhTVL1lrvTw== Date: Thu, 24 Oct 2013 14:20:58 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.132.55] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "insipid-chairs@tools.ietf.org" Subject: [Insipid] IETF88 INSIPID Draft Agenda Posted X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2013 14:21:05 -0000 Hi Folks -=20 We have posted the draft agenda for INSIPID here: https://datatracker.ietf.= org/meeting/88/agenda/insipid/ Please send the chairs (insipid-chairs@tools.ietf.org)any comments or reque= sts for changes/additions before Monday October 28th (when the revised WG a= genda is due). Thanks,=20 Gonzalo & Keith (as co-chairs)= From jmpolk@cisco.com Thu Oct 24 15:26:14 2013 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4201511E8242 for ; Thu, 24 Oct 2013 15:26:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RAKfq7hiWE3I for ; Thu, 24 Oct 2013 15:26:08 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id A256311E81C7 for ; Thu, 24 Oct 2013 15:26:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=664; q=dns/txt; s=iport; t=1382653564; x=1383863164; h=message-id:date:to:from:subject:cc:mime-version; bh=V0VSkVWqAVQLSg5aSI3OWqyxgS54zNeZcbp9hgai9F8=; b=Dwfty9mkSwvPKE14ITTmUNlnTSg527cbSKT5dzEZnJNj473MmKyiUcng AEDjTEbxqS73SXiALKIjEaWn1RHj1HIriG0ypmCnIjVsEv2uOgJF3tRwH VQPWF4QV8WOKWATv7KzlVYzBkkcBO7h0ky6p22qespww1c9R7HkY6Lw0J E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AngGABOeaVKtJXG8/2dsb2JhbABZgwc4vyeBHxZtB4JkAj8XJRUfCkQch34NujSPTYQzA4k/oFKDQh4 X-IronPort-AV: E=Sophos;i="4.93,565,1378857600"; d="scan'208";a="276441687" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-4.cisco.com with ESMTP; 24 Oct 2013 22:26:03 +0000 Received: from jmpolk-WS.cisco.com (rcdn-vpn-client-10-89-1-86.cisco.com [10.89.1.86]) (authenticated bits=0) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r9OMQ2Pv004316 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 Oct 2013 22:26:02 GMT Message-Id: <201310242226.r9OMQ2Pv004316@rcdn-core2-1.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 24 Oct 2013 17:26:02 -0500 To: "insipid@ietf.org" From: James Polk Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authenticated-User: jmpolk Cc: "Paul E. Jones" Subject: [Insipid] Next version of the backwards compatibility proposal X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2013 22:26:14 -0000 INSIPID Here is the next version of the proposal for backwards compatibility between the insipid and kaplan versions of the Session-ID header. http://www.ietf.org/internet-drafts/draft-polk-insipid-bkwds-compatibility-proposal-03.txt There is a new section dealing with alternative proposals for a 'flag' to indicate which implementation an endpoint is, namely either a new option tag or a Contact header feature tag. I list the reasons why I don't think either will work. I'd like to get this draft discussed, as well as the two alternative flags on the list before we have our face2face in Vancouver on Monday evening, Nov 4th. James From pkyzivat@alum.mit.edu Fri Oct 25 08:36:59 2013 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D0E411E832E for ; Fri, 25 Oct 2013 08:36:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.304 X-Spam-Level: X-Spam-Status: No, score=-0.304 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RpibHhAkRfUb for ; Fri, 25 Oct 2013 08:36:53 -0700 (PDT) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:211]) by ietfa.amsl.com (Postfix) with ESMTP id 3D28C11E8329 for ; Fri, 25 Oct 2013 08:36:12 -0700 (PDT) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by QMTA11.westchester.pa.mail.comcast.net with comcast id hP3c1m0071vXlb85BTc7nJ; Fri, 25 Oct 2013 15:36:07 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta17.westchester.pa.mail.comcast.net with comcast id hTc71m00P3ZTu2S3dTc7dJ; Fri, 25 Oct 2013 15:36:07 +0000 Message-ID: <526A8FE7.3070203@alum.mit.edu> Date: Fri, 25 Oct 2013 11:36:07 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: insipid@ietf.org References: <201310242226.r9OMQ2Pv004316@rcdn-core2-1.cisco.com> In-Reply-To: <201310242226.r9OMQ2Pv004316@rcdn-core2-1.cisco.com> 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=1382715367; bh=SBAlMJMaWjofesk4VTrZAGL7twKzNTNXo3dgzaGAi18=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=m/OMTuvgJhMhMGa0N1xJ4qXWE2lLRqU++0jT6SN0Ovvlpa3wX4rL5K1fTQuZCNKEB 4XPeUFYSQTJyVWdp3KBDblyWFg6nS71cmv1OmlNGCM/OOYHy8WMvuWarnxp+YhiL8x O3GLgNLQKeOTkLBqVPuKOplnoLt9woGjU5kW3skNkxkZg92xgCCf4TmKUGLoa7PCr4 JbUDKsLzipj6sk6IUeS38ZmvDFCc6Pnsk/n17M3FFqC/kA0fOY8RBpGI8OO3eKZQWY 9qIG/ZAeW45/si+wMrYkw4tIxKBdxLGoeVkl6ri9iNPnHaTVEfvOzpVJdLExKQtmo5 IgWOx/Pv31qig== Subject: Re: [Insipid] Next version of the backwards compatibility proposal X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 15:36:59 -0000 James, This draft is a little hard to follow because the examples all use Alice, Bob, Carol, but sometimes they are Kaplan implementations and sometimes they are Jones implementations. It would be easier to read if a name always corresponded to the same type of implementation. (E.g., Katy, Jan, Jerry.) But since its transient, it may not be worth changing. Otherwise, I think you make your point that other indicators aren't needed. Thanks, Paul On 10/24/13 6:26 PM, James Polk wrote: > INSIPID > > Here is the next version of the proposal for backwards compatibility > between the insipid and kaplan versions of the Session-ID header. > > http://www.ietf.org/internet-drafts/draft-polk-insipid-bkwds-compatibility-proposal-03.txt > > > There is a new section dealing with alternative proposals for a 'flag' > to indicate which implementation an endpoint is, namely either a new > option tag or a Contact header feature tag. I list the reasons why I > don't think either will work. > > I'd like to get this draft discussed, as well as the two alternative > flags on the list before we have our face2face in Vancouver on Monday > evening, Nov 4th. > > James > > _______________________________________________ > insipid mailing list > insipid@ietf.org > https://www.ietf.org/mailman/listinfo/insipid > From jmpolk@cisco.com Fri Oct 25 11:51:18 2013 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 370EC11E81CB for ; Fri, 25 Oct 2013 11:51:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S+xDaAi7ziCp for ; Fri, 25 Oct 2013 11:51:09 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 4EC8111E813A for ; Fri, 25 Oct 2013 11:51:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1830; q=dns/txt; s=iport; t=1382727069; x=1383936669; h=message-id:date:to:from:subject:in-reply-to:references: mime-version; bh=wexoyJ+XtHQyXnX0eyVHeW3w8Dtu5j2yJEKX+hhCM4E=; b=VLjVwxjdYkIvmYbfq6GtN4rKFGwqbn5yZWy7nFSfNEiTP8NGbraLXAAU 34/8GFWKbMlnDj7Q+ZDB9G/o8CgvaTDm8Ts0IYM7jUHtl/zJsPYaj5mKU N1q3RBlnRJqFh3HMSsBIx/fCiltlXs1HTzlSHxI94Wuw8LPgNzIjTKVHW Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FACe9alKtJXG+/2dsb2JhbABZDoJ5OL5SS4EiFnSCJQEBAQMBAQEBNQI0EAsHBA4KCRUQDwoOMAYBEgmHeAYNuVKPWoQsA4k/oFKCZ10e X-IronPort-AV: E=Sophos;i="4.93,572,1378857600"; d="scan'208";a="276738321" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-7.cisco.com with ESMTP; 25 Oct 2013 18:51:08 +0000 Received: from jmpolk-WS.cisco.com (rcdn-vpn-client-10-89-1-86.cisco.com [10.89.1.86]) (authenticated bits=0) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r9PIp84X023380 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 25 Oct 2013 18:51:08 GMT Message-Id: <201310251851.r9PIp84X023380@rcdn-core2-3.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 25 Oct 2013 13:51:08 -0500 To: Paul Kyzivat , From: James Polk In-Reply-To: <526A8FE7.3070203@alum.mit.edu> References: <201310242226.r9OMQ2Pv004316@rcdn-core2-1.cisco.com> <526A8FE7.3070203@alum.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authenticated-User: jmpolk Subject: Re: [Insipid] Next version of the backwards compatibility proposal X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 18:51:18 -0000 Thanks for reviewing and commenting Paul At 10:36 AM 10/25/2013, Paul Kyzivat wrote: >James, > >This draft is a little hard to follow because the examples all use >Alice, Bob, Carol, but sometimes they are Kaplan implementations and >sometimes they are Jones implementations. It would be easier to read >if a name always corresponded to the same type of implementation. >(E.g., Katy, Jan, Jerry.) I thought about doing this (where one 'name', e.g., Alice) is always a certain version of implementation, but it didn't make it into this rev. >But since its transient, it may not be worth changing. > >Otherwise, I think you make your point that other indicators aren't needed. Thanks for understanding (and agreeing ;-) ) James > Thanks, > Paul > >On 10/24/13 6:26 PM, James Polk wrote: >>INSIPID >> >>Here is the next version of the proposal for backwards compatibility >>between the insipid and kaplan versions of the Session-ID header. >> >>http://www.ietf.org/internet-drafts/draft-polk-insipid-bkwds-compatibility-proposal-03.txt >> >> >>There is a new section dealing with alternative proposals for a 'flag' >>to indicate which implementation an endpoint is, namely either a new >>option tag or a Contact header feature tag. I list the reasons why I >>don't think either will work. >> >>I'd like to get this draft discussed, as well as the two alternative >>flags on the list before we have our face2face in Vancouver on Monday >>evening, Nov 4th. >> >>James >> >>_______________________________________________ >>insipid mailing list >>insipid@ietf.org >>https://www.ietf.org/mailman/listinfo/insipid > >_______________________________________________ >insipid mailing list >insipid@ietf.org >https://www.ietf.org/mailman/listinfo/insipid From christer.holmberg@ericsson.com Fri Oct 25 11:58:49 2013 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7CB511E81C5 for ; Fri, 25 Oct 2013 11:58:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.595 X-Spam-Level: X-Spam-Status: No, score=-5.595 tagged_above=-999 required=5 tests=[AWL=0.653, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W1Ln4iGESUmV for ; Fri, 25 Oct 2013 11:58:44 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 841C411E81D4 for ; Fri, 25 Oct 2013 11:58:35 -0700 (PDT) X-AuditID: c1b4fb2d-b7f738e000003ee3-63-526abf478c36 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 83.67.16099.74FBA625; Fri, 25 Oct 2013 20:58:15 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.201]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.02.0328.009; Fri, 25 Oct 2013 20:58:14 +0200 From: Christer Holmberg To: James Polk , Paul Kyzivat , "insipid@ietf.org" Thread-Topic: [Insipid] Next version of the backwards compatibility proposal Thread-Index: AQHO0Qgh6Wzevava8Uqwr+3C+92rvZoFbECAgAA2fQCAACNNvIAAADg8 Date: Fri, 25 Oct 2013 18:58:13 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4F7111@ESESSMB209.ericsson.se> References: <201310242226.r9OMQ2Pv004316@rcdn-core2-1.cisco.com> <526A8FE7.3070203@alum.mit.edu>, <201310251851.r9PIp84X023380@rcdn-core2-3.cisco.com> In-Reply-To: <201310251851.r9PIp84X023380@rcdn-core2-3.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C4F7111ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDLMWRmVeSWpSXmKPExsUyM+Jvja77/qwgg5uz5S3m33/GZLFjTaHF ig0HWB2YPf6+/8DkMeX3RlaPJUt+MgUwR3HZpKTmZJalFunbJXBlzD58nbngoHnFsqPTWRsY z+h3MXJySAiYSPw+N4sJwhaTuHBvPVsXIxeHkMBhRolvK76CJYQEljBKnJvi18XIwcEmYCHR /U8bJCwiUCBxddtxdhBbWMBbovdWGytE3Efi3L7vLBC2m0R380E2EJtFQFVi4svpzCBjeAV8 JSa9DYFYNZ1R4u23TWD1nAKOErvndDOD2IxA93w/tQbsBGYBcYlbT+ZD3SkgsWTPeWYIW1Ti 5eN/rBC2ksSPDZdYIOrzJY5NWwl2G6+AoMTJmU9YJjCKzEIyahaSsllIyiDiehI3pk5hg7C1 JZYtfM0MYetKzPh3CKrGWmLWwR2MyGoWMHKsYmTPTczMSS833MQIjLGDW37r7mA8dU7kEKM0 B4uSOO+Ht85BQgLpiSWp2ampBalF8UWlOanFhxiZODilGhhDHBVY/209wiVU3HL59Q9XzR/V ftHvDBRFDY2/fHo1d/5TxgDNmcaSGzuktrAIhTf3zFksOzfllTP/2pO1V/w4HKcoitZ3nt6e 1On9dtIWFpljzM+/e4su7jUMkZ///MDbgg33735srZbu/vnYLO15zQ6bd0FeHXpLi+23GGbN OBf1bL1b/XclluKMREMt5qLiRAAX0ZQCfwIAAA== Subject: Re: [Insipid] Next version of the backwards compatibility proposal X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 18:58:50 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C4F7111ESESSMB209erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Alice could have different family names, depending on what type of entity s= he represents: Alice Kaplan and Alice Jones :) Regards, Christer ________________________________ From: insipid-bounces@ietf.org [insipid-bounces@ietf.org] on behalf of Jame= s Polk [jmpolk@cisco.com] Sent: Friday, 25 October 2013 9:51 PM To: Paul Kyzivat; insipid@ietf.org Subject: Re: [Insipid] Next version of the backwards compatibility proposal Thanks for reviewing and commenting Paul At 10:36 AM 10/25/2013, Paul Kyzivat wrote: >James, > >This draft is a little hard to follow because the examples all use >Alice, Bob, Carol, but sometimes they are Kaplan implementations and >sometimes they are Jones implementations. It would be easier to read >if a name always corresponded to the same type of implementation. >(E.g., Katy, Jan, Jerry.) I thought about doing this (where one 'name', e.g., Alice) is always a certain version of implementation, but it didn't make it into this rev. >But since its transient, it may not be worth changing. > >Otherwise, I think you make your point that other indicators aren't needed= . Thanks for understanding (and agreeing ;-) ) James > Thanks, > Paul > >On 10/24/13 6:26 PM, James Polk wrote: >>INSIPID >> >>Here is the next version of the proposal for backwards compatibility >>between the insipid and kaplan versions of the Session-ID header. >> >>http://www.ietf.org/internet-drafts/draft-polk-insipid-bkwds-compatibilit= y-proposal-03.txt >> >> >>There is a new section dealing with alternative proposals for a 'flag' >>to indicate which implementation an endpoint is, namely either a new >>option tag or a Contact header feature tag. I list the reasons why I >>don't think either will work. >> >>I'd like to get this draft discussed, as well as the two alternative >>flags on the list before we have our face2face in Vancouver on Monday >>evening, Nov 4th. >> >>James >> >>_______________________________________________ >>insipid mailing list >>insipid@ietf.org >>https://www.ietf.org/mailman/listinfo/insipid > >_______________________________________________ >insipid mailing list >insipid@ietf.org >https://www.ietf.org/mailman/listinfo/insipid _______________________________________________ insipid mailing list insipid@ietf.org https://www.ietf.org/mailman/listinfo/insipid --_000_7594FB04B1934943A5C02806D1A2204B1C4F7111ESESSMB209erics_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <7723BE32DEBF8346AD76748F1A5FDF27@ericsson.com> Content-Transfer-Encoding: quoted-printable

Alice could have different family names, depending on what type of entit= y she represents: Alice Kaplan and Alice Jones :)

 

Regards,

 

Christer

 

 

 

From: insipid-bounces@ietf.org [insipid-bounces@ietf.org] on beh= alf of James Polk [jmpolk@cisco.com]
Sent: Friday, 25 October 2013 9:51 PM
To: Paul Kyzivat; insipid@ietf.org
Subject: Re: [Insipid] Next version of the backwards compatibility p= roposal

Thanks for reviewing and commenting Paul

At 10:36 AM 10/25/2013, Paul Kyzivat wrote:
>James,
>
>This draft is a little hard to follow because the examples all use
>Alice, Bob, Carol, but sometimes they are Kaplan implementations and >sometimes they are Jones implementations. It would be easier to read >if a name always corresponded to the same type of implementation.
>(E.g., Katy, Jan, Jerry.)

I thought about doing this (where one 'name', e.g., Alice) is always
a certain version of implementation, but it didn't make it into this rev.

>But since its transient, it may not be worth changing.
>
>Otherwise, I think you make your point that other indicators aren't nee= ded.

Thanks for understanding (and agreeing  ;-) )

James


>         Thanks,
>         Paul
>
>On 10/24/13 6:26 PM, James Polk wrote:
>>INSIPID
>>
>>Here is the next version of the proposal for backwards compatibilit= y
>>between the insipid and kaplan versions of the Session-ID header. >>
>>http://www.ietf.org/i= nternet-drafts/draft-polk-insipid-bkwds-compatibility-proposal-03.txt >>
>>
>>There is a new section dealing with alternative proposals for a 'fl= ag'
>>to indicate which implementation an endpoint is, namely either a ne= w
>>option tag or a Contact header feature tag. I list the reasons why = I
>>don't think either will work.
>>
>>I'd like to get this draft discussed, as well as the two alternativ= e
>>flags on the list before we have our face2face in Vancouver on Mond= ay
>>evening, Nov 4th.
>>
>>James
>>
>>_______________________________________________
>>insipid mailing list
>>insipid@ietf.org
>>https://www.ietf.org/mailman/listinfo/insipid
>
>_______________________________________________
>insipid mailing list
>insipid@ietf.org
>https://www.ietf.org/mailman/listinfo/insipid

_______________________________________________
insipid mailing list
insipid@ietf.org
https://www.ietf.org/mailman/listinfo/insipid
--_000_7594FB04B1934943A5C02806D1A2204B1C4F7111ESESSMB209erics_-- From jmpolk@cisco.com Fri Oct 25 12:47:29 2013 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02F8121F9FC6 for ; Fri, 25 Oct 2013 12:47:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.537 X-Spam-Level: X-Spam-Status: No, score=-110.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Brxt8Mb8scQN for ; Fri, 25 Oct 2013 12:47:24 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id D26EC11E8178 for ; Fri, 25 Oct 2013 12:47:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2987; q=dns/txt; s=iport; t=1382730444; x=1383940044; h=message-id:date:to:from:subject:in-reply-to:references: mime-version; bh=v6Mv+yIvNz6WvAfyR968rgftDbWNN6tNZ9lww5K9jSQ=; b=Ha+uNnpPM2aiCyt3aeT10Cp4lpE7kV/t6Tf1xc+5tvWTUvVZ+LIfS3+9 6hKwj/BinjpBfFpy3xnefBw4NO5/i2ZjMJ+41tCeuMaf4A8g50HBRwloq VTqU7WUMT1dYwMvi0Rl8qpC7GCIHPRx3xCcSMCetsh5WgWSdOCXEvtYkP o=; X-IronPort-AV: E=Sophos;i="4.93,572,1378857600"; d="scan'208";a="276763450" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-7.cisco.com with ESMTP; 25 Oct 2013 19:47:23 +0000 Received: from jmpolk-WS.cisco.com (rcdn-vpn-client-10-89-1-86.cisco.com [10.89.1.86]) (authenticated bits=0) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r9PJlMXA028171 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 25 Oct 2013 19:47:22 GMT Message-Id: <201310251947.r9PJlMXA028171@rcdn-core2-2.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 25 Oct 2013 14:47:22 -0500 To: Christer Holmberg , James Polk , Paul Kyzivat , "insipid@ietf.org" From: James Polk In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C4F7111@ESESSMB209.ericss on.se> References: <201310242226.r9OMQ2Pv004316@rcdn-core2-1.cisco.com> <526A8FE7.3070203@alum.mit.edu> <201310251851.r9PIp84X023380@rcdn-core2-3.cisco.com> <7594FB04B1934943A5C02806D1A2204B1C4F7111@ESESSMB209.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authenticated-User: jmpolk Subject: Re: [Insipid] Next version of the backwards compatibility proposal X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 19:47:29 -0000 That's an interesting suggestion. If others think this solves any confusion, and doesn't create more - I can use this in my slide deck in YVR... -j At 01:58 PM 10/25/2013, Christer Holmberg wrote: >Alice could have different family names, depending on what type of >entity she represents: Alice Kaplan and Alice Jones :) > > > >Regards, > > > >Christer > > > > > > > >---------- >From: insipid-bounces@ietf.org [insipid-bounces@ietf.org] on behalf >of James Polk [jmpolk@cisco.com] >Sent: Friday, 25 October 2013 9:51 PM >To: Paul Kyzivat; insipid@ietf.org >Subject: Re: [Insipid] Next version of the backwards compatibility proposal > >Thanks for reviewing and commenting Paul > >At 10:36 AM 10/25/2013, Paul Kyzivat wrote: > >James, > > > >This draft is a little hard to follow because the examples all use > >Alice, Bob, Carol, but sometimes they are Kaplan implementations and > >sometimes they are Jones implementations. It would be easier to read > >if a name always corresponded to the same type of implementation. > >(E.g., Katy, Jan, Jerry.) > >I thought about doing this (where one 'name', e.g., Alice) is always >a certain version of implementation, but it didn't make it into this rev. > > > >But since its transient, it may not be worth changing. > > > >Otherwise, I think you make your point that other indicators aren't needed. > >Thanks for understanding (and agreeing ;-) ) > >James > > > > Thanks, > > Paul > > > >On 10/24/13 6:26 PM, James Polk wrote: > >>INSIPID > >> > >>Here is the next version of the proposal for backwards compatibility > >>between the insipid and kaplan versions of the Session-ID header. > >> > >> atibility-proposal-03.txt>http://www.ietf.org/internet-drafts/draft-polk-insipid-bkwds-compatibility-proposal-03.txt > >> > >> > >>There is a new section dealing with alternative proposals for a 'flag' > >>to indicate which implementation an endpoint is, namely either a new > >>option tag or a Contact header feature tag. I list the reasons why I > >>don't think either will work. > >> > >>I'd like to get this draft discussed, as well as the two alternative > >>flags on the list before we have our face2face in Vancouver on Monday > >>evening, Nov 4th. > >> > >>James > >> > >>_______________________________________________ > >>insipid mailing list > >>insipid@ietf.org > >>https://www.ietf.or > g/mailman/listinfo/insipid > > > >_______________________________________________ > >insipid mailing list > >insipid@ietf.org > >https://www.ietf.org > /mailman/listinfo/insipid > >_______________________________________________ >insipid mailing list >insipid@ietf.org >https://www.ietf.org/mailman/listinfo/insipid From pkyzivat@alum.mit.edu Tue Oct 29 13:37:53 2013 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ACE711E814C for ; Tue, 29 Oct 2013 13:37:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.24 X-Spam-Level: X-Spam-Status: No, score=-0.24 tagged_above=-999 required=5 tests=[AWL=0.197, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y7d4eKG-gdXM for ; Tue, 29 Oct 2013 13:37:39 -0700 (PDT) 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 4092921E8090 for ; Tue, 29 Oct 2013 13:37:38 -0700 (PDT) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta01.westchester.pa.mail.comcast.net with comcast id izaC1m0021c6gX8518dddv; Tue, 29 Oct 2013 20:37:37 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta23.westchester.pa.mail.comcast.net with comcast id j8dd1m00N3ZTu2S3j8ddMM; Tue, 29 Oct 2013 20:37:37 +0000 Message-ID: <52701C91.2030200@alum.mit.edu> Date: Tue, 29 Oct 2013 16:37:37 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: "insipid@ietf.org" 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=1383079057; bh=ivbjMrBYjHp8yeFMyycK6I2ZNSU8K0yft5VLNn5oWIg=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=DCjy/fRU7AuxGdtxwC5Afnacu/ZxsIvmHOFYFR7bZBCHm+s3WE56yPFg4oczLYeU6 X2KTW1ezKjH2HZF1+NOacpbvbqv2W3tmI6OaBK1QW5kvyn6tCRgm9zepR1cM6P3fVh 23PeC7JQvW786yLl3xeVQs/FOGZC+rf462mpOH+9LwH5n8/sbQxw4ccrA8PJ9ofzKo lG5pttjJmNkmAO4kndzRTjlr8/Cw02NIZ5s0Mo8wOLS6gv6jHU5wHKB2hHhPh4BYQX isIsMSdLrYW3kL9QTSfrB+M7j1nlKE83/moVO+h/4vcGcb0rRwJk+TXACBvecYk9bj +dAgvM6yDnY5Q== Subject: [Insipid] comments on draft-ietf-insipid-session-id-02 X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 20:37:53 -0000 I just went through the latest version and have some comments: Section 6: The exception to including the UUID of the transmitting entity mentioned above is in the case of provisional responses that occur before the destination UA has generated its UUID. The 100 (Trying) response and the 181 (Call Forwarding) response are examples of such provisional responses. In these cases, the sending intermediary places the one known UUID in the remote-uuid field, and leaves the "local-uuid" blank. This placement is always where a UA expects to receive its UUID value in SIP responses. The above calls for a syntactically incorrect header field. If you want to allow the local-uuid to be omitted then the syntax needs to be updated. Or else specify that the local-uuid must be set to the NULL value. For any purpose the UA has for the Session Identifier, it MUST assume that the Session Identifier is {A,B} where "A" is the UUID value of this endpoint (i.e., "local-uuid") and "B" is the UUID value of the peer endpoint (i.e., "remote-uuid"), taken from the most recently received message within this session. Note that when comparing Session Identifiers for equivalence, the identifier {A,B} is equal to the set {B,A}. s/the set/the identifier/ The last paragraph of Section 6 says: Cascading MCUs all utilize the same UUID value ("local-uuid" portion of the Session-ID header-value) for all participants of the cascaded conference. An MCU conveys the UUID value to utilize via the "local- uuid" portion of the Session-ID header-value in an INVITE to a second MCU. Then Section 8 says more about MCUs. But there is nothing normative. If you want to say anything about this then I think it would be better to make it normative, even if it is optional to use. Is the intent that when a conference focus (MCU-2) receives an INVITE, and the caller (MCU-1) indicates isFocus, that MCU-2 SHOULD adopt the uuid received in that INVITE as its own for the duration of that dialog? Section 9.1: The general operation description makes a distinction between "the originating transmitter" and "UA-Alice". These seem to be the same. Is there a point to the distinction? Section 9.2: o UA-Bob reINVITEs Alice to call Carol, using a REFER transaction, as described in [RFC3515]. UA-Alice is initially put on hold, then told in the REFER who to contact with a new INVITE, in this case UA-Carol. This Alice-to-Carol dialog will have a new Call- ID, therefore it requires a new Session-ID header-value. The wrinkle here is we can, and will, use Alice's UUID from her existing dialog with Bob in the new INVITE to Carol. The phrasing above is misleading. I suggest: s/reINVITEs/requests/ Section 9.3: o Bob sends a reINVITE to Alice (with the Session-ID "local-uuid" = Bob's UUID and "remote-uuid" = Alice's UUID), informing her to transfer her existing call to Carol. I've mentioned this before... There is nothing standard that you can put in a reINVITE that will tell the receiver to transfer the call. I'm inclined to suggest you just drop this example. But if you want it, then you must explain what magic you are assuming that triggers the transfer. Section 9.6: I presume that after the initial INVITE from MCU-1 to MCU-2 that MCU-2 SHOULD use M' as its local UUID. If so, why doesn't it use M' as its own in the response to that invite, resulting in {M',M'}? The examples also don't go far enough to show the effect they want. For this you should show two callers calling in, to two different MCUs and both getting M' back. Section 9.9: The "(Target-Dialog:Carol)" must be wrong since there is no dialog with Carol at that point. I think what you want is "(Refer-To:Carol)". There will be a Target-Dialog, but it isn't especially interesting here. If you want to mention it, then you might call it "(Target-Dialog:Bob-Alice)". Is there a reason for using X & Y rather than reusing B & A? E.g.: {B} |--REFER------------>|(Refer-To:Carol) | {A,B} |<-202 Accepted------| | | | | {A,B} || | ISTM this is at least as justified as an MCU using the same uuid for all the dialogs in the same conference. Thanks, Paul From gsalguei@cisco.com Thu Oct 31 12:32:54 2013 Return-Path: X-Original-To: insipid@ietfa.amsl.com Delivered-To: insipid@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2E4911E8241 for ; Thu, 31 Oct 2013 12:32:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.566 X-Spam-Level: X-Spam-Status: No, score=-10.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qLjHAt2GexQL for ; Thu, 31 Oct 2013 12:32:44 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 58DEA11E823D for ; Thu, 31 Oct 2013 12:32:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=147; q=dns/txt; s=iport; t=1383247963; x=1384457563; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=XxRPA+PQinDIbN/SpuHI7HMus74poIJApZp+p7cHzfc=; b=JXkGAa+uqI2tA6rQNk2EDYObsjtU1yT5zpD6G8T8V6QcSDCDLsHOU+Dk yo+8bSbcUVUvixs/OCl0ZHqUbqkXcv5+NJyN2SFzPxvD0lb3cGN2SUi2t 7DOfuMvHUHYEFexR6ubEr5zb4afQt6K09Bwcc0yvdIWTWzGGpoU1o4I0n w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhkGAFKvclKtJXHA/2dsb2JhbABZgwc4VL9qgSgWbQeCJwEEOj8SASoUQicEDg2Hfw28YQSPHjGDJ4EOA6oTgyaCKg X-IronPort-AV: E=Sophos;i="4.93,611,1378857600"; d="scan'208";a="279183791" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-5.cisco.com with ESMTP; 31 Oct 2013 19:32:43 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r9VJWgph008981 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 31 Oct 2013 19:32:42 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.27]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0318.004; Thu, 31 Oct 2013 14:32:42 -0500 From: "Gonzalo Salgueiro (gsalguei)" To: "insipid@ietf.org" Thread-Topic: Revised IETF 88 INSIPID Agenda Posted Thread-Index: AQHO1m/3uQj6F1uVsE2/rw+/qt4grw== Date: Thu, 31 Oct 2013 19:32:41 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.132.55] Content-Type: text/plain; charset="us-ascii" Content-ID: <75A30577AE6C844B8719E5E47039906D@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "insipid-chairs@tools.ietf.org" Subject: [Insipid] Revised IETF 88 INSIPID Agenda Posted X-BeenThere: insipid@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Session-ID discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2013 19:32:55 -0000 https://datatracker.ietf.org/meeting/88/agenda/insipid/ This should now be final. See you all there! Gonzalo & Keith =20 (as co-chairs)