From naveen.sarma@gmail.com Thu Apr 1 06:02:01 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28B0D3A6A36 for ; Thu, 1 Apr 2010 06:02:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.818 X-Spam-Level: X-Spam-Status: No, score=-0.818 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cwdfZnw2oIhK for ; Thu, 1 Apr 2010 06:02:00 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 234923A6A0F for ; Thu, 1 Apr 2010 06:01:13 -0700 (PDT) Received: by vws9 with SMTP id 9so543738vws.31 for ; Thu, 01 Apr 2010 06:01:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:received:message-id:subject:to:cc:content-type; bh=ZVitZK1cxRtsTyrJwvCSWI8+WZxpJs5J6Wqx46P2cHA=; b=Eq3Tl/TCA9TSjwcb25hHukRec5y6CAKRYJYX31fXBfYBKKtk+VMe7492vQilBz3cDE aCWlFWo/Fy3dZhQAAFlTfESs+olrSwotgecaGBkJJiqrToJUifn6BvL9YL/6bXvsMKI/ Aen6SV83j1KtAr3S4C0E4YJOC49F8MPAKsjbQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=vw+WbIVB8OuxEElMuNkdeo1cVJDq1dKerNi8UdpaCM9w8UanHE0oenZM1E18o8Jx+X F3oIH/6usYkDZjatEz246Da9DtQSzUBNg2wjRv2pG3kwQ+WN6/tmhtkb6foCDkxrD6PN g3bSWQ9C+nh9JEuxJZvJcn2vCx6xsMxBH9Hzo= MIME-Version: 1.0 Received: by 10.220.125.78 with HTTP; Thu, 1 Apr 2010 06:01:25 -0700 (PDT) In-Reply-To: <000001cad162$297b3120$7c719360$@com> References: <20100401165042.ac842ead.suckfish@ihug.co.nz> <000001cad162$297b3120$7c719360$@com> From: Naveen Kottapalli Date: Thu, 1 Apr 2010 14:01:25 +0100 Received: by 10.220.61.137 with SMTP id t9mr173526vch.19.1270126905125; Thu, 01 Apr 2010 06:01:45 -0700 (PDT) Message-ID: To: Nilanjan Content-Type: multipart/alternative; boundary=e0cb4e887f19ffeb0f04832c76dd Cc: dime@ietf.org Subject: Re: [Dime] Message mis-sequencing over SCTP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2010 13:02:01 -0000 --e0cb4e887f19ffeb0f04832c76dd Content-Type: text/plain; charset=ISO-8859-1 I feel it'll be good to add a caution note about this and the leave the rest to the implementors. This is because, even if we allocate the separately streams for diameter base protocol messages and user messages, still the problem persits. An example is, if the CEA is sent on stream 0 and the rest of user messages on other streams, the delivery of messages is not guaranteed by SCTP. Yours, Naveen. On 1 April 2010 07:11, Nilanjan wrote: > I think, this mis-sequencing can only happen CEA followed by new request > using different stream-id in case of SCTP. > > 1) This is because CEA does not have any Confirmation defined in protocol, > so peer does not have any knowledge of whether CEA is reached and accepted, > before issuing a request. This may have implementation solution like > forcing > all initial REQ immediately after sending CEA to use same stream-id of CEA > until any msg from peer received (any REQ/RES). > > I am thinking this mis-sequencing is limited to only very small scenario, > since > a) Generally CER is sent by Diameter Client, who likes to send REQ > to Diameter server, even though Diameter is Peer-to-peer protocol. > b) This is only when we need to send REQ immediately after sending > CEA, and not giving enough time to reach CEA packet to peer (max time to > live) or to see whether peer disconnects to Diameter connection (in case of > CEA is not accepted) > c) Sending application request before starting watch-dog message > > So, this may be required to keep in protocol, and can be left to > implementation. > > 2) In case of Diameter session application, some AVP defined like > (CC-Request-Number in case of CCA), which can be used to reordering any > messages using different stream-id in case of SCTP. > > Kind Regards, > Nilanjan > > -----Original Message----- > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of > Ralph Loader > Sent: Thursday, April 01, 2010 9:21 AM > To: Tom Taylor > Cc: dime@ietf.org > Subject: Re: [Dime] Message mis-sequencing over SCTP > > > Sounds like a good point. Seems to me the rules should be: > > > > - use only stream 0 until the Diameter connection has been set up > > - all messages relating to the same session must use the same stream. > > Is the second suggested rule (same session must use the same stream) > actually of any use? > > IIRC, in principal, messages on the same session may take different routes > to their destination (where multiple Diameter proxies are available) and > that makes enforcing ordering on a single hop irrelevant to the session? > > The Diameter application must either enforce ordering or cope with > reordering, anyway? > > Cheers, > Ralph. > > > > > That should be added to section 2.1.1. > > > > > > Naveen Kottapalli wrote: > > > Hi, > > > > > > Am just wondering whether the mis-sequencing in the delivery of packets > when > > > SCTP is being used as transport layer would cause any problem. For > example, > > > take an association with 5 out-streams to send out the Diameter > messages. > > > Immediately after sending CEA on stream 0, all other messages are sent > over > > > other streams like 1, 2, 3, and 4. > > > > > > There is a chance that the other Diameter messages will reach the peer > > > before the CEA is processed? Does the existing draft miss the > sequencing > > > problem over SCTP? > > > > > > Yours, > > > Naveen. > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > _______________________________________________ > > > DiME mailing list > > > DiME@ietf.org > > > https://www.ietf.org/mailman/listinfo/dime > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www.ietf.org/mailman/listinfo/dime > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > --e0cb4e887f19ffeb0f04832c76dd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I feel it'll be good to=A0add a caution note=A0about this and the = leave the rest to the implementors.
=A0
This is because, even if we allocate the separately streams for diamet= er base protocol messages and user messages, still the problem persits.=A0 = An example is, if the CEA is sent on stream 0 and the rest of user messages= on other streams, the delivery of messages is not guaranteed by SCTP.

Yours,
Naveen.


On 1 April 2010 07:11, Nilanjan <nilanjan@mavenir.com><= /span> wrote:
I think, this mis-sequencing can= only happen CEA followed by new request
using different stream-id in ca= se of SCTP.

1) This is because CEA does not have any Confirmation defined in protoc= ol,
so peer does not have any knowledge of whether CEA is reached and ac= cepted,
before issuing a request. This may have implementation solution = like forcing
all initial REQ immediately after sending CEA to use same stream-id of CEA<= br>until any msg from peer received (any REQ/RES).

I am thinking thi= s mis-sequencing is limited to only very small scenario,
since
=A0 = =A0 =A0 =A0a) Generally CER is sent by Diameter Client, who likes to send R= EQ
to Diameter server, even though Diameter is Peer-to-peer protocol.
=A0 = =A0 =A0 =A0b) This is only when we need to send REQ immediately after sendi= ng
CEA, and not giving enough time to reach CEA packet to peer (max time= to
live) or to see whether peer disconnects to Diameter connection (in case of=
CEA is not accepted)
=A0 =A0 =A0 =A0c) Sending application request b= efore starting watch-dog message

So, this may be required to keep in= protocol, and can be left to
implementation.

2) In case of Diameter session application, some AVP= defined like
(CC-Request-Number in case of CCA), which can be used to r= eordering any
messages using different stream-id in case of SCTP.

Kind Regards,
Nilanjan

-----Original Message-----
From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of
Ralph Lo= ader
Sent: Thursday, April 01, 2010 9:21 AM
To: Tom Taylor
Cc: dime@ietf.org
Subject: Re: [Dime] Message mis-= sequencing over SCTP

> Sounds like a good point. Seems to me the = rules should be:
>
> =A0 - use only stream 0 until the Diameter connection has been= set up
> =A0 - all messages relating to the same session must use th= e same stream.

Is the second suggested rule (same session must use t= he same stream)
actually of any use?

IIRC, in principal, messages on the same sessio= n may take different routes
to their destination (where multiple Diamete= r proxies are available) and
that makes enforcing ordering on a single h= op irrelevant to the session?

The Diameter application must either enforce ordering or cope with
r= eordering, anyway?

Cheers,
Ralph.

>
> That should= be added to section 2.1.1.
>
>
> Naveen Kottapalli wrote= :
> > Hi,
> >
> > Am just wondering whether the mis-s= equencing in the delivery of packets
when
> > SCTP is being use= d as transport layer would cause any problem. =A0For
example,
> &g= t; take an association with 5 out-streams to send out the Diameter
messages.
> > Immediately after sending CEA on stream 0, all other= messages are sent
over
> > other streams like 1, 2, 3, and 4.<= br>> >
> > There is a chance that the other Diameter message= s will reach the peer
> > before the CEA is processed? =A0 Does the existing draft miss the=
sequencing
> > problem over SCTP?
> >
> > Yo= urs,
> > Naveen.
> >
> >
> >
> &g= t; ------------------------------------------------------------------------=
> >
> > _______________________________________________
&= gt; > DiME mailing list
> > Di= ME@ietf.org
> > https://www.ietf.org/mailman/listinfo/dime > _______________________________________________
> DiME mailing l= ist
> DiME@ietf.org
> https:= //www.ietf.org/mailman/listinfo/dime
_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailm= an/listinfo/dime

_______________________________________________
DiME mailing listDiME@ietf.org
https://www.ietf.org/m= ailman/listinfo/dime

--e0cb4e887f19ffeb0f04832c76dd-- From suckfish@ihug.co.nz Thu Apr 1 12:17:26 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DFF13A69BA for ; Thu, 1 Apr 2010 12:17:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.454 X-Spam-Level: X-Spam-Status: No, score=0.454 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74, DNS_FROM_OPENWHOIS=1.13, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SdJtDQGklsGL for ; Thu, 1 Apr 2010 12:17:25 -0700 (PDT) Received: from mailfilter68.ihug.co.nz (mailfilter68.ihug.co.nz [203.109.136.68]) by core3.amsl.com (Postfix) with ESMTP id 1D4B73A696A for ; Thu, 1 Apr 2010 12:17:24 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmQFAEeOtEt2XKYT/2dsb2JhbACPS4txcrYuhQEEiyY X-IronPort-AV: E=Sophos;i="4.51,350,1267354800"; d="scan'208";a="270341564" Received: from 118-92-166-19.dsl.dyn.ihug.co.nz (HELO i.geek.nz) ([118.92.166.19]) by smtp.mailfilter5.ihug.co.nz with SMTP; 02 Apr 2010 08:20:15 +1300 Date: Fri, 2 Apr 2010 08:17:55 +1300 From: Ralph Loader To: dime@ietf.org Message-Id: <20100402081755.4a20de02.suckfish@ihug.co.nz> In-Reply-To: References: X-Mailer: Sylpheed 3.0.0 (GTK+ 2.20.0; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [Dime] Message mis-sequencing over SCTP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2010 19:17:26 -0000 > - use only stream 0 until the Diameter connection has been set up How is the end-point that sends the CEA meant to know when the connection set-up is complete? The connection set-up is complete when the other end-point processes the CEA, and the end-point sending the CEA doesn't know when that happens. Ralph. > - all messages relating to the same session must use the same stream. > > That should be added to section 2.1.1. > > > Naveen Kottapalli wrote: > > Hi, > > > > Am just wondering whether the mis-sequencing in the delivery of packets when > > SCTP is being used as transport layer would cause any problem. For example, > > take an association with 5 out-streams to send out the Diameter messages. > > Immediately after sending CEA on stream 0, all other messages are sent over > > other streams like 1, 2, 3, and 4. > > > > There is a chance that the other Diameter messages will reach the peer > > before the CEA is processed? Does the existing draft miss the sequencing > > problem over SCTP? > > > > Yours, > > Naveen. > > > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www.ietf.org/mailman/listinfo/dime > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From naveen.sarma@gmail.com Thu Apr 1 13:41:37 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56EA53A696A for ; Thu, 1 Apr 2010 13:41:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.035 X-Spam-Level: X-Spam-Status: No, score=-1.035 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 36MubA4txtxs for ; Thu, 1 Apr 2010 13:41:36 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 244153A692E for ; Thu, 1 Apr 2010 13:41:36 -0700 (PDT) Received: by vws9 with SMTP id 9so793143vws.31 for ; Thu, 01 Apr 2010 13:42:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:received:message-id:subject:to:cc:content-type; bh=H5UraqJzAnsZ0Is9Hp5rrbtpZFXFpWz4V0D9BTMqJ6I=; b=niD80xss6odGZTzQyr+tzmVYT8rUtwRjIT4DjXCh5I8KbW9Cc1L0Ax1OBQfZkpXIms aG/AGUfQ7IopjFyPOtTplMVpgh4B7Lfuf8CB/pni8/7xKQDbdnXkHj34OIVWeY0daOa+ hVAxlQm5no+gNDP/jcbv3XDQ8WMDqGbf/vXsk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=pmW4MakxGKTgZvzmWIHtCgpyzPo+i/QQexAaM1CtiG9XBlIyMrynLEXuU9YmMdbyuA o1x+qDZKi7wTBiNnRRgqAcb4ucmOEanEj3jr0Dx2OB5ZiDABZ03jHZVvhwcU2Cjz0J8p hO03NKo3F2LGLIFznFuYZXY03M76cUpn8LnTM= MIME-Version: 1.0 Received: by 10.220.125.78 with HTTP; Thu, 1 Apr 2010 13:41:46 -0700 (PDT) In-Reply-To: <20100402081755.4a20de02.suckfish@ihug.co.nz> References: <20100402081755.4a20de02.suckfish@ihug.co.nz> From: Naveen Kottapalli Date: Thu, 1 Apr 2010 21:41:46 +0100 Received: by 10.220.107.219 with SMTP id c27mr726698vcp.207.1270154526126; Thu, 01 Apr 2010 13:42:06 -0700 (PDT) Message-ID: To: Ralph Loader Content-Type: multipart/alternative; boundary=00c09f8a4e3356f4e2048332e5d4 Cc: dime@ietf.org Subject: Re: [Dime] Message mis-sequencing over SCTP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2010 20:41:37 -0000 --00c09f8a4e3356f4e2048332e5d4 Content-Type: text/plain; charset=ISO-8859-1 As a request-response kind of protocol, there is no acknowledgement defined for any answer message. An answer message will be treated as a confirmation to the request message. And this is the implicit behavior of Diameter protocol. The sender of CEA knows the result of capability negotiation before the CEA is being processed by peer. This enables the sender of CEA to move the peer either to OPEN / CLOSED states, before the CEA is processed by peer. So, there is no provision left for the sender in delaying the message transfer to a peer in OPEN state. Yours, Naveen. On 1 April 2010 20:17, Ralph Loader wrote: > > - use only stream 0 until the Diameter connection has been set up > > How is the end-point that sends the CEA meant to know when the connection > set-up is complete? > > The connection set-up is complete when the other end-point processes the > CEA, and the end-point sending the CEA doesn't know when that happens. > > Ralph. > > > > - all messages relating to the same session must use the same stream. > > > > That should be added to section 2.1.1. > > > > > > Naveen Kottapalli wrote: > > > Hi, > > > > > > Am just wondering whether the mis-sequencing in the delivery of packets > when > > > SCTP is being used as transport layer would cause any problem. For > example, > > > take an association with 5 out-streams to send out the Diameter > messages. > > > Immediately after sending CEA on stream 0, all other messages are sent > over > > > other streams like 1, 2, 3, and 4. > > > > > > There is a chance that the other Diameter messages will reach the peer > > > before the CEA is processed? Does the existing draft miss the > sequencing > > > problem over SCTP? > > > > > > Yours, > > > Naveen. > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > _______________________________________________ > > > DiME mailing list > > > DiME@ietf.org > > > https://www.ietf.org/mailman/listinfo/dime > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www.ietf.org/mailman/listinfo/dime > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > --00c09f8a4e3356f4e2048332e5d4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
As a request-response kind of protocol, there is no acknowledgement de= fined for any answer message.=A0 An answer message will be treated as a con= firmation to the request message.=A0 And this is the=A0implicit behavior of= Diameter protocol.
=A0
The sender of CEA knows the result of capability negotiation before th= e CEA is being processed by peer.=A0 This enables the=A0sender of CEA=A0to = move the peer either to OPEN / CLOSED states, before the CEA is processed b= y peer.=A0 So, there is no provision left for the sender in delaying the me= ssage transfer to=A0a peer in OPEN state.

Yours,
Naveen.


On 1 April 2010 20:17, Ralph Loader <suckfish@ihug.co.nz>= ; wrote:
> =A0 - use only stream 0 until the Diameter connectio= n has been set up

How is the end-point that sends the CEA mean= t to know when the connection set-up is complete?

The connection set= -up is complete when the other end-point processes the CEA, and the end-poi= nt sending the CEA doesn't know when that happens.

Ralph.


> =A0 - all messages relating to the same sess= ion must use the same stream.
>
> That should be added to secti= on 2.1.1.
>
>
> Naveen Kottapalli wrote:
> > Hi,=
> >
> > Am just wondering whether the mis-sequencing in the = delivery of packets when
> > SCTP is being used as transport layer= would cause any problem. =A0For example,
> > take an association = with 5 out-streams to send out the Diameter messages.
> > Immediately after sending CEA on stream 0, all other messages are= sent over
> > other streams like 1, 2, 3, and 4.
> >
= > > There is a chance that the other Diameter messages will reach the= peer
> > before the CEA is processed? =A0 Does the existing draft miss the= sequencing
> > problem over SCTP?
> >
> > Yours= ,
> > Naveen.
> >
> >
> >
> > = ------------------------------------------------------------------------ > >
> > _______________________________________________
&= gt; > DiME mailing list
> > Di= ME@ietf.org
> > https://www.ietf.org/mailman/listinfo/dime > _______________________________________________
> DiME mailing l= ist
> DiME@ietf.org
> https:= //www.ietf.org/mailman/listinfo/dime
_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailm= an/listinfo/dime

--00c09f8a4e3356f4e2048332e5d4-- From jouni.nospam@gmail.com Thu Apr 1 14:43:50 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DA843A68E6 for ; Thu, 1 Apr 2010 14:43:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.869 X-Spam-Level: X-Spam-Status: No, score=-0.869 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IjDpTOJC5IEq for ; Thu, 1 Apr 2010 14:43:49 -0700 (PDT) Received: from mail-bw0-f217.google.com (mail-bw0-f217.google.com [209.85.218.217]) by core3.amsl.com (Postfix) with ESMTP id 758D13A68B8 for ; Thu, 1 Apr 2010 14:43:49 -0700 (PDT) Received: by bwz9 with SMTP id 9so1241875bwz.29 for ; Thu, 01 Apr 2010 14:44:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:content-type :content-transfer-encoding:subject:date:message-id:to:mime-version :x-mailer; bh=4BLa8cyYI0K8fBQk7YuDKkROCsIQTdlBjKh29l+Q9PI=; b=Q75DTeGsoXj7Yc6ut19rCIyr3pvwnVVfzyEpVmIsVhGaAXxWdvMzAuXdOAJC39tbXG yqzYHwU2P4f+mOfluQ6uAc4+65gHfkZyjtuR8APgOMxtlSR8TTlzM7HImQXlL6fHe4h1 eqzzhTYyAg7IWh/9QaeV06L3XEIlOBUIMJuSk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; b=alNCz2EHHM/yKS1sYn88tmW9brB2Z2BFjhWbNinsSUh+68kqNmFxHASDI4UwVEExQH FHXXnjPyOzv1F3N7Lf6UTbybDIGRV/21GECHmPTgD/7E0gDNsQx40YZt4pXmQTmEnRQ+ yzuURCOG0awb9nIOZDFqDa8ddY/IxidGX7XWg= Received: by 10.204.74.77 with SMTP id t13mr2157459bkj.7.1270158258728; Thu, 01 Apr 2010 14:44:18 -0700 (PDT) Received: from a88-114-167-158.elisa-laajakaista.fi (a88-114-167-158.elisa-laajakaista.fi [88.114.167.158]) by mx.google.com with ESMTPS id 15sm4451006bwz.4.2010.04.01.14.44.17 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 01 Apr 2010 14:44:18 -0700 (PDT) From: jouni korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 2 Apr 2010 00:44:17 +0300 Message-Id: <20470FD8-CA0F-4D60-966A-033F72CEE344@gmail.com> To: dime@ietf.org Mime-Version: 1.0 (Apple Message framework v1077) X-Mailer: Apple Mail (2.1077) Subject: [Dime] Meeting notes uploaded X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2010 21:43:50 -0000 Can be found at: http://www.ietf.org/proceedings/10mar/minutes/dime.txt - Jouni From gwz@net-zen.net Sun Apr 4 22:12:41 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0908D3A68B3 for ; Sun, 4 Apr 2010 22:12:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.201 X-Spam-Level: * X-Spam-Status: No, score=1.201 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_83=0.6, J_CHICKENPOX_84=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xs+F9SLNsLmW for ; Sun, 4 Apr 2010 22:12:36 -0700 (PDT) Received: from smtpauth05.prod.mesa1.secureserver.net (smtpauth05.prod.mesa1.secureserver.net [64.202.165.99]) by core3.amsl.com (Postfix) with SMTP id 406473A68C7 for ; Sun, 4 Apr 2010 22:12:36 -0700 (PDT) Received: (qmail 25880 invoked from network); 5 Apr 2010 05:12:34 -0000 Received: from unknown (58.8.10.253) by smtpauth05.prod.mesa1.secureserver.net (64.202.165.99) with ESMTP; 05 Apr 2010 05:12:33 -0000 From: "Glen Zorn" To: "'Mark Jones'" , "'jouni korhonen'" References: <082F9E86-364B-4535-A54D-F6759B33E023@gmail.com> In-Reply-To: Date: Sun, 4 Apr 2010 22:12:30 -0700 Organization: Network Zen Message-ID: <01c101cad47e$991b6e40$cb524ac0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrQ7lmZpnDp2WD3Qoa3CaP20gcAJgADGixQAODsYBA= Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] NAPTR fix for 3588bis X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2010 05:12:41 -0000 If the problem will be fixed in 3588bis then there is no need to file an erratum. Hope this helps. ~gwz > -----Original Message----- > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of > Mark Jones > Sent: Wednesday, March 31, 2010 11:32 AM > To: jouni korhonen > Cc: dime@ietf.org > Subject: Re: [Dime] NAPTR fix for 3588bis > > Thanks for the feedback, Jouni. Responses inline. > > > -----Original Message----- > > From: jouni korhonen [mailto:jouni.nospam@gmail.com] > > Sent: March 31, 2010 12:20 PM > > To: Mark Jones > > Cc: dime@ietf.org > > Subject: Re: [Dime] NAPTR fix for 3588bis > > > > Hi, > > > > Thanks Mark for initiating the discussion and proposing text. My > > initial comments inline. > > > > On Mar 31, 2010, at 4:48 PM, Mark Jones wrote: > > > > > Here are the proposed changes to 3588bis to implement the fix for > the > > NAPTR issues discussed at IETF#77 (see > > http://www.ietf.org/proceedings/10mar/slides/dime-5.pdf). > > > > > > Comments appreciated. > > > > > > There was some discussion at the meeting of creating S-NAPTR > > Application Service Tag entries for the unregistered NAPTR values in > > RFC3588 ("AAA+D2x"). No consensus was reached but my impression was > > that we were leaning towards NOT creating these entries. That would be > > my preference too but are there any objections on the list? > > > > Would be ok I think.. However, I really would like to see even some > > discussion related to them _somewhere_. Any ideas? Would an errata be > > enough to cover that? > > > > I do agree this change needs to be discussed but I assumed we were going > to have that discussion _here_ on this list. If the errata review > procedure is likely to generate more discussion then I'm all for it. > > > > > > > > > Regards > > > Mark > > > > > > ************************* FIRST CHANGE ************************* > > > > > > Section 5.2 Diameter Peer Discovery > > > > > > => Replace step 2 with the following text: > > > > > > 2. The Diameter implementation performs a NAPTR query for a > server > > > in a particular realm. The Diameter implementation has to > know > > > in advance which realm to look for a Diameter agent in. This > > > could be deduced, for example, from the 'realm' in a NAI that > a > > > Diameter implementation needed to perform a Diameter operation > > > on. > > > > > > The NAPTR usage in Diameter follows the S-NAPTR DDDS > > application > > > [RFC3958] which means that the SERVICE field includes tags for > > the > > > desired application and supported application protocol. > > > The application service tag for a Diameter application is > 'aaa' > > and > > > the supported application protocol tags are 'diameter.tcp', > > > 'diameter.sctp' or 'diameter.tls'. > > > > RFC3958 ABNF does not allow "." in iana-registered-protocol, so the > > application protocol has to be changed, like "diametertcp" or "dtcp" > > etc.. > > > > Lucky for us that IANA is ignoring the RFC3958 ABNF then :) > > http://www.iana.org/assignments/s-naptr-parameters/s-naptr- > parameters.xhtml > > Another errata perhaps? > > iana-registered-protocol = ALPHA *31ALPHANUMSYM > > > > > > > The client follows the resolution process defined by the S- > > NAPTR > > > DDDS [RFC3958] application to find a matching SRV or A record > > of > > > a suitable peer. The domain suffixes in the NAPTR replacement > > field > > > SHOULD match the domain of the original query. > > > > > > > > > ************************* SECOND CHANGE ************************* > > > > > > Section 11.6 NAPTR Service Fields > > > > > > => Rename this section to S-NAPTR Parameters and replace content > > with: > > > > > > This document registers a S-NAPTR Application Service Tag value of > > "aaa". > > > > > > This document also registers the following S-NAPTR Application > > Protocol Tags: > > > > > > Tag | Protocol > > > ---------------|--------- > > > diameter.tcp | TCP > > > diameter.sctp | SCTP > > > diameter.tls | TLS > > > > See my note above regarding the application protocol. > > > > > > > > > > ************************* THIRD CHANGE ************************** > > > > > > Appendix B. NAPTR Example > > > > > > => Rename section to S-NAPTR Example and modify as follows. > > > > > > As an example, consider a client that wishes to resolve aaa: > > > example.com. The client performs a NAPTR query for that domain, > > and > > > the following NAPTR records are returned: > > > > > > ;; order pref flags service regexp replacement > > > IN NAPTR 50 50 "s" "aaa:diameter.tls" "" > > _diameter._tls.example.com > > > IN NAPTR 100 50 "s" "aaa:diameter.tcp" "" > > _aaa._tcp.example.com > > > IN NAPTR 150 50 "s" "aaa:diameter.sctp" "" > > _diameter._sctp.example.com > > > > And lets have an example of "a" flag as well: > > > > IN NAPTR 150 50 "a" "aaa:diametertls" "" > server1.example.com > > IN NAPTR 150 50 "a" "aaa:diametertls" "" > server2.example.com > > > > Fine by me. > > > > > > > > > This indicates that the server supports TLS, TCP and SCTP in that > > > order. If the client supports TLS, TLS will be used, targeted to > a > > > host determined by an SRV lookup of _diameter._tls.example.com. > > That > > > lookup would return: > > > > > > ;; Priority Weight Port Target > > > IN SRV 0 1 5060 server1.example.com > > > IN SRV 0 2 5060 server2.example.com > > > > > > > > > ************************* FOURTH CHANGE ************************** > > > > > > 14.1. Normative References > > > > > > => Add new reference to S-NAPTR DDDS RFC3958. > > > > > > ************************* END OF CHANGES *********************** > > > > - Jouni > > > > > > > > > > > > _______________________________________________ > > > DiME mailing list > > > DiME@ietf.org > > > https://www.ietf.org/mailman/listinfo/dime > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From lionel.morand@orange-ftgroup.com Thu Apr 8 03:42:16 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09C5328C0EC for ; Thu, 8 Apr 2010 03:42:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.049 X-Spam-Level: X-Spam-Status: No, score=-2.049 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_83=0.6, J_CHICKENPOX_84=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xKj9f31H9rve for ; Thu, 8 Apr 2010 03:42:14 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by core3.amsl.com (Postfix) with ESMTP id 21F6A3A67AD for ; Thu, 8 Apr 2010 03:42:14 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 8B23D8B8002; Thu, 8 Apr 2010 12:42:11 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id 46FAA8B8003; Thu, 8 Apr 2010 12:42:10 +0200 (CEST) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Thu, 8 Apr 2010 12:41:49 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 8 Apr 2010 12:41:48 +0200 Message-ID: In-Reply-To: <01c101cad47e$991b6e40$cb524ac0$@net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] NAPTR fix for 3588bis thread-index: AcrQ7lmZpnDp2WD3Qoa3CaP20gcAJgADGixQAODsYBAAodFJYA== References: <082F9E86-364B-4535-A54D-F6759B33E023@gmail.com> <01c101cad47e$991b6e40$cb524ac0$@net> From: To: , , X-OriginalArrivalTime: 08 Apr 2010 10:41:49.0652 (UTC) FILETIME=[180A5140:01CAD708] Cc: dime@ietf.org Subject: Re: [Dime] NAPTR fix for 3588bis X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 10:42:16 -0000 Hi All, I'm fine with the proposal, as said furing the meeting. About the ABNF issue, i think it is solved now and and we can go on with = "diameter.x" (cf. = http://www.rfc-editor.org/errata_search.php?rfc=3D3958) About registry issue in the RFC 3588, my understanding is that existing = Diameter deployments (i.e. based on the RFC3588) rely somehow on = "specific" implementation if they want to use DNS for Diameter peer = discovery (as the actual content of the RFC 3588 is "not correct"). After the publication of the RFC 3588bis, the exiting RFC3588 will = become obsolete. New Diameter deployment will be based on the new RFC. = Pre-existing Diameter deployment will either still rely on their = "specific" DNS procedures (if already deployed and there is no need to = interwork with new external networks i.e. "do what you want in your = walled garden") or update their implementation to cope with the solution = defined in the RFC 3588bis. If my understanding is correct, there is no need for Erratum for = existing RFC 3588 if the "bis" version is (at last) published! BR, Lionel > -----Message d'origine----- > De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De=20 > la part de Glen Zorn > Envoy=E9 : lundi 5 avril 2010 07:13 > =C0 : 'Mark Jones'; 'jouni korhonen' > Cc : dime@ietf.org > Objet : Re: [Dime] NAPTR fix for 3588bis >=20 > If the problem will be fixed in 3588bis then there is no need=20 > to file an erratum. >=20 > Hope this helps. >=20 > ~gwz >=20 >=20 > > -----Original Message----- > > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org]=20 > On Behalf=20 > > Of Mark Jones > > Sent: Wednesday, March 31, 2010 11:32 AM > > To: jouni korhonen > > Cc: dime@ietf.org > > Subject: Re: [Dime] NAPTR fix for 3588bis > >=20 > > Thanks for the feedback, Jouni. Responses inline. > >=20 > > > -----Original Message----- > > > From: jouni korhonen [mailto:jouni.nospam@gmail.com] > > > Sent: March 31, 2010 12:20 PM > > > To: Mark Jones > > > Cc: dime@ietf.org > > > Subject: Re: [Dime] NAPTR fix for 3588bis > > > > > > Hi, > > > > > > Thanks Mark for initiating the discussion and proposing text. My=20 > > > initial comments inline. > > > > > > On Mar 31, 2010, at 4:48 PM, Mark Jones wrote: > > > > > > > Here are the proposed changes to 3588bis to implement=20 > the fix for > > the > > > NAPTR issues discussed at IETF#77 (see=20 > > > http://www.ietf.org/proceedings/10mar/slides/dime-5.pdf). > > > > > > > > Comments appreciated. > > > > > > > > There was some discussion at the meeting of creating S-NAPTR > > > Application Service Tag entries for the unregistered=20 > NAPTR values in > > > RFC3588 ("AAA+D2x"). No consensus was reached but my=20 > impression was=20 > > > that we were leaning towards NOT creating these entries.=20 > That would=20 > > > be my preference too but are there any objections on the list? > > > > > > Would be ok I think.. However, I really would like to see=20 > even some=20 > > > discussion related to them _somewhere_. Any ideas? Would=20 > an errata=20 > > > be enough to cover that? > > > > >=20 > > I do agree this change needs to be discussed but I assumed we were=20 > > going to have that discussion _here_ on this list. If the errata=20 > > review procedure is likely to generate more discussion then=20 > I'm all for it. > >=20 > > > > > > > > > > > Regards > > > > Mark > > > > > > > > ************************* FIRST CHANGE ************************* > > > > > > > > Section 5.2 Diameter Peer Discovery > > > > > > > > =3D> Replace step 2 with the following text: > > > > > > > > 2. The Diameter implementation performs a NAPTR query for a > > server > > > > in a particular realm. The Diameter implementation has to > > know > > > > in advance which realm to look for a Diameter=20 > agent in. This > > > > could be deduced, for example, from the 'realm' in a NAI=20 > > > > that > > a > > > > Diameter implementation needed to perform a=20 > Diameter operation > > > > on. > > > > > > > > The NAPTR usage in Diameter follows the S-NAPTR DDDS > > > application > > > > [RFC3958] which means that the SERVICE field=20 > includes tags=20 > > > > for > > > the > > > > desired application and supported application protocol. > > > > The application service tag for a Diameter application is > > 'aaa' > > > and > > > > the supported application protocol tags are=20 > 'diameter.tcp', > > > > 'diameter.sctp' or 'diameter.tls'. > > > > > > RFC3958 ABNF does not allow "." in=20 > iana-registered-protocol, so the=20 > > > application protocol has to be changed, like=20 > "diametertcp" or "dtcp" > > > etc.. > > > > >=20 > > Lucky for us that IANA is ignoring the RFC3958 ABNF then :) > >=20 > > http://www.iana.org/assignments/s-naptr-parameters/s-naptr- > > parameters.xhtml > >=20 > > Another errata perhaps? > >=20 > > iana-registered-protocol =3D ALPHA *31ALPHANUMSYM > >=20 > > > > > > > > The client follows the resolution process defined=20 > by the S- > > > NAPTR > > > > DDDS [RFC3958] application to find a matching SRV or A=20 > > > > record > > > of > > > > a suitable peer. The domain suffixes in the NAPTR=20 > > > > replacement > > > field > > > > SHOULD match the domain of the original query. > > > > > > > > > > > > ************************* SECOND CHANGE=20 > ************************* > > > > > > > > Section 11.6 NAPTR Service Fields > > > > > > > > =3D> Rename this section to S-NAPTR Parameters and replace = content > > > with: > > > > > > > > This document registers a S-NAPTR Application Service=20 > Tag value of > > > "aaa". > > > > > > > > This document also registers the following S-NAPTR Application > > > Protocol Tags: > > > > > > > > Tag | Protocol > > > > ---------------|--------- > > > > diameter.tcp | TCP > > > > diameter.sctp | SCTP > > > > diameter.tls | TLS > > > > > > See my note above regarding the application protocol. > > > > > > > > > > > > > > ************************* THIRD CHANGE=20 > ************************** > > > > > > > > Appendix B. NAPTR Example > > > > > > > > =3D> Rename section to S-NAPTR Example and modify as follows. > > > > > > > > As an example, consider a client that wishes to resolve aaa: > > > > example.com. The client performs a NAPTR query for=20 > that domain, > > > and > > > > the following NAPTR records are returned: > > > > > > > > ;; order pref flags service regexp=20 > replacement > > > > IN NAPTR 50 50 "s" "aaa:diameter.tls" "" > > > _diameter._tls.example.com > > > > IN NAPTR 100 50 "s" "aaa:diameter.tcp" "" > > > _aaa._tcp.example.com > > > > IN NAPTR 150 50 "s" "aaa:diameter.sctp" "" > > > _diameter._sctp.example.com > > > > > > And lets have an example of "a" flag as well: > > > > > > IN NAPTR 150 50 "a" "aaa:diametertls" "" > > server1.example.com > > > IN NAPTR 150 50 "a" "aaa:diametertls" "" > > server2.example.com > > > > >=20 > > Fine by me. > >=20 > > > > > > > > > > > This indicates that the server supports TLS, TCP and=20 > SCTP in that > > > > order. If the client supports TLS, TLS will be used,=20 > targeted=20 > > > > to > > a > > > > host determined by an SRV lookup of=20 > _diameter._tls.example.com. > > > That > > > > lookup would return: > > > > > > > > ;; Priority Weight Port Target > > > > IN SRV 0 1 5060 server1.example.com > > > > IN SRV 0 2 5060 server2.example.com > > > > > > > > > > > > ************************* FOURTH CHANGE=20 > ************************** > > > > > > > > 14.1. Normative References > > > > > > > > =3D> Add new reference to S-NAPTR DDDS RFC3958. > > > > > > > > ************************* END OF CHANGES *********************** > > > > > > - Jouni > > > > > > > > > > > > > > > > > _______________________________________________ > > > > DiME mailing list > > > > DiME@ietf.org > > > > https://www.ietf.org/mailman/listinfo/dime > >=20 > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www.ietf.org/mailman/listinfo/dime >=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime >=20 From Mark.Jones@bridgewatersystems.com Thu Apr 8 13:03:06 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A6DB3A6A8C for ; Thu, 8 Apr 2010 13:03:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.985 X-Spam-Level: X-Spam-Status: No, score=-2.985 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, J_CHICKENPOX_83=0.6, J_CHICKENPOX_84=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QSJooziObCss for ; Thu, 8 Apr 2010 13:03:05 -0700 (PDT) Received: from mail201.messagelabs.com (mail201.messagelabs.com [216.82.254.211]) by core3.amsl.com (Postfix) with ESMTP id B2C633A6835 for ; Thu, 8 Apr 2010 13:02:59 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: Mark.Jones@bridgewatersystems.com X-Msg-Ref: server-9.tower-201.messagelabs.com!1270756974!70377673!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [72.35.6.119] Received: (qmail 27910 invoked from network); 8 Apr 2010 20:02:55 -0000 Received: from mail.bridgewatersystems.com (HELO webmail.bridgewatersystems.com) (72.35.6.119) by server-9.tower-201.messagelabs.com with RC4-SHA encrypted SMTP; 8 Apr 2010 20:02:55 -0000 Received: from m679t05.fpmis.bridgewatersys.com ([10.52.81.148]) by m679t01.fpmis.bridgewatersys.com ([10.52.81.144]) with mapi; Thu, 8 Apr 2010 16:02:54 -0400 From: Mark Jones To: Sebastien Decugis Date: Thu, 8 Apr 2010 16:02:52 -0400 Thread-Topic: [Dime] NAPTR fix for 3588bis Thread-Index: AcrRXb1oYr1v6452QtC5yn/LXctL/QF94WRA Message-ID: References: <4BB43191.5000505@nict.go.jp> In-Reply-To: <4BB43191.5000505@nict.go.jp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dime@ietf.org" Subject: Re: [Dime] NAPTR fix for 3588bis X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 20:03:06 -0000 > -----Original Message----- > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of > Sebastien Decugis > Sent: April 1, 2010 1:39 AM > To: dime@ietf.org > Subject: Re: [Dime] NAPTR fix for 3588bis >=20 > Hi, >=20 > > diameter.tcp | TCP > > diameter.sctp | SCTP > > diameter.tls | TLS > > >=20 > I still don't understand why TLS is at the same level as TCP and SCTP, > while it is actually TLS over TCP or TLS over SCTP. I think that either > "secure diameter" (diameters?) or "secure tcp / secure sctp" (tcps / > sctps) would make more sense. >=20 Thanks for the feedback, Sebastien. Now the tag ABNF issue is resolved, how about: Tag | Protocol ------------------|--------- diameter.tcp | TCP diameter.sctp | SCTP diameter.tls.tcp | TLS/TCP diameter.tls.sctp | TLS/SCTP > By the way, the document lacks a reference on how TLSoverSCTP is > supposed to be implemented... (RFC3436?) >=20 Agreed. Regards Mark > Best regards, > Sebastien. >=20 > -- > Sebastien Decugis > Research fellow > Network Architecture Group > NICT (nict.go.jp) >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From vf0213@gmail.com Thu Apr 8 13:22:51 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6F5E3A69B5 for ; Thu, 8 Apr 2010 13:22:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_83=0.6, J_CHICKENPOX_84=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nisBgNd98dPo for ; Thu, 8 Apr 2010 13:22:47 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id D2A663A697A for ; Thu, 8 Apr 2010 13:22:46 -0700 (PDT) Received: by wyb29 with SMTP id 29so168769wyb.31 for ; Thu, 08 Apr 2010 13:22:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=4wDvQUbvZFNmI46wCWQZX48ljbUUhBgBACu4DWw9rvk=; b=pxeGZaQuBZg/NATzVrGABJFh7ouicd0gtotzARhm4IaTzESfxa5KZk0T4LhRDFIPfA Qy8CePFlatnIz4WCsfkJxb9uIo0IxsZNKa+XJg4ttHAFMTTq4IS8F3LGP7cyorvh6bw+ uXoqmmjAXfaKJrVVUDMvqywtb+M1sKnDXMIbI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=rABb2ZycJLHGNkbFRhjiXBNO4ABWRYkdC1f+pFMabEKKRNd74q0auqogPVeLg5crFT REeVQWVVG4UrOU5zoQnHVmvykBTsmCfkhsMlFceFQmgarXfzhUlYfAf3b9HhZcm/X5vi WnKRJ+6uga+dZTuDeKcv/boX24AYNDmG2IM/E= MIME-Version: 1.0 Received: by 10.216.170.73 with HTTP; Thu, 8 Apr 2010 13:22:38 -0700 (PDT) In-Reply-To: References: <4BB43191.5000505@nict.go.jp> Date: Thu, 8 Apr 2010 15:22:38 -0500 Received: by 10.216.90.1 with SMTP id d1mr289016wef.200.1270758158615; Thu, 08 Apr 2010 13:22:38 -0700 (PDT) Message-ID: From: Victor Fajardo To: Mark Jones Content-Type: multipart/alternative; boundary=0016e6d99f26a3c4170483bf7083 Cc: "dime@ietf.org" Subject: Re: [Dime] NAPTR fix for 3588bis X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 20:22:51 -0000 --0016e6d99f26a3c4170483bf7083 Content-Type: text/plain; charset=ISO-8859-1 Hi Mark, Are there any other open issues with this thread ? Do we have an agreed upon solution ? regards, victor On Thu, Apr 8, 2010 at 3:02 PM, Mark Jones < Mark.Jones@bridgewatersystems.com> wrote: > > -----Original Message----- > > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of > > Sebastien Decugis > > Sent: April 1, 2010 1:39 AM > > To: dime@ietf.org > > Subject: Re: [Dime] NAPTR fix for 3588bis > > > > Hi, > > > > > diameter.tcp | TCP > > > diameter.sctp | SCTP > > > diameter.tls | TLS > > > > > > > I still don't understand why TLS is at the same level as TCP and SCTP, > > while it is actually TLS over TCP or TLS over SCTP. I think that either > > "secure diameter" (diameters?) or "secure tcp / secure sctp" (tcps / > > sctps) would make more sense. > > > > > Thanks for the feedback, Sebastien. > > Now the tag ABNF issue is resolved, how about: > > Tag | Protocol > ------------------|--------- > diameter.tcp | TCP > diameter.sctp | SCTP > diameter.tls.tcp | TLS/TCP > diameter.tls.sctp | TLS/SCTP > > > By the way, the document lacks a reference on how TLSoverSCTP is > > supposed to be implemented... (RFC3436?) > > > > Agreed. > > Regards > Mark > > > Best regards, > > Sebastien. > > > > -- > > Sebastien Decugis > > Research fellow > > Network Architecture Group > > NICT (nict.go.jp) > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www.ietf.org/mailman/listinfo/dime > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > --0016e6d99f26a3c4170483bf7083 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Mark,

Are there any other open issues with this thread ? Do we ha= ve an agreed upon solution ?

regards,
victor


On Thu, Apr 8, 2010 at 3:02 PM, Mark Jones <Mark.Jones@bri= dgewatersystems.com> wrote:
> -----Original Message-----
> From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of
> Sebastien Decugis
> Sent: April 1, 2010 1:39 AM
> To: dime@ietf.org
> Subject: Re: [Dime] NAPTR fix for 3588bis
>
> Hi,
>
> > =A0 =A0diameter.tcp =A0 | TCP
> > =A0 =A0diameter.sctp =A0| SCTP
> > =A0 =A0diameter.tls =A0 | TLS
> >
>
> I still don't understand why TLS is at the same level as TCP and S= CTP,
> while it is actually TLS over TCP or TLS over SCTP. I think that eithe= r
> "secure diameter" (diameters?) or "secure tcp / secure = sctp" (tcps /
> sctps) would make more sense.
>


Thanks for the feedback, Sebastien.

Now the tag ABNF issue is resolved, how about:

=A0 Tag =A0 =A0 =A0 =A0 =A0 =A0 =A0 | Protocol
=A0 ------------------|---------
=A0 diameter.tcp =A0 =A0 =A0| TCP
=A0 diameter.sctp =A0 =A0 | SCTP
=A0 diameter.tls.tcp =A0| TLS/TCP
=A0 diameter.tls.sctp | TLS/SCTP

> By the way, the document lacks a reference on how TLSoverSCTP is
> supposed to be implemented... (RFC3436?)
>

Agreed.

Regards
Mark

> Best regards,
> Sebastien.
>
> --
> Sebastien Decugis
> Research fellow
> Network Architecture Group
> NICT (nict.go.jp)<= br> >
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
_______________________________________________
DiME mailing list
DiME@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/dime

--0016e6d99f26a3c4170483bf7083-- From Mark.Jones@bridgewatersystems.com Thu Apr 8 15:03:14 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76EE628C188 for ; Thu, 8 Apr 2010 15:03:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.192 X-Spam-Level: X-Spam-Status: No, score=-4.192 tagged_above=-999 required=5 tests=[AWL=1.206, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_83=0.6, J_CHICKENPOX_84=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hja6K1QQX1wJ for ; Thu, 8 Apr 2010 15:03:08 -0700 (PDT) Received: from mail28.messagelabs.com (mail28.messagelabs.com [216.82.249.131]) by core3.amsl.com (Postfix) with ESMTP id 2FDBD28C187 for ; Thu, 8 Apr 2010 15:03:08 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: Mark.Jones@bridgewatersystems.com X-Msg-Ref: server-11.tower-28.messagelabs.com!1270764172!85701067!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [72.35.6.119] Received: (qmail 9954 invoked from network); 8 Apr 2010 22:02:53 -0000 Received: from mail.bridgewatersystems.com (HELO webmail.bridgewatersystems.com) (72.35.6.119) by server-11.tower-28.messagelabs.com with RC4-SHA encrypted SMTP; 8 Apr 2010 22:02:53 -0000 Received: from m679t05.fpmis.bridgewatersys.com ([10.52.81.148]) by m679t01.fpmis.bridgewatersys.com ([10.52.81.144]) with mapi; Thu, 8 Apr 2010 18:02:52 -0400 From: Mark Jones To: Victor Fajardo Date: Thu, 8 Apr 2010 18:02:50 -0400 Thread-Topic: [Dime] NAPTR fix for 3588bis Thread-Index: AcrXWT+9tZb/8WgeS1eNC39+laH6AgACXbUQ Message-ID: References: <4BB43191.5000505@nict.go.jp> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_B4B762B06D90774E9E8016C89B66AF87561322BBm679t05fpmisbri_" MIME-Version: 1.0 Cc: "dime@ietf.org" Subject: Re: [Dime] NAPTR fix for 3588bis X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 22:03:14 -0000 --_000_B4B762B06D90774E9E8016C89B66AF87561322BBm679t05fpmisbri_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Victor, I counted six issues raised by the proposed NAPTR fix: 1) Resolve what to do about existing NAPTR entries in RFC3588 (Jouni). Conclusion: Let them die with RFC3588 (when obsoleted by 35= 88bis). 2) Application protocol tags do not confirm to the ABNF in RFC3958 (Jouni) Conclusion: RFC3958 errata updated so the protocol tags now= do conform to the new ABNF. 3) Add a TLS record to the S-NAPTR example (Jouni). Conclusion: Include Jouni's TLS example text in this fix. 4) Application protocol tag for TLS does not differentiate TLS/TCP vs TLS/S= CTP (Sebastian). Conclusion: New TLS tags proposed to Sebastian. Still open. 5) Missing ref to TLS/SCTP - RFC3436 (Sebastian). Conclusion: Add the missing reference to 3588bis. Unrelated= to this fix though. 6) Should this be handled as an errata to 3588 and/or added to 3588bis. Conclusion: Fix in 3588bis is preferred approach (Thanks Gl= en & Lionel for feedback). If Sebastian is OK with the new application protocol tags for TLS, I think = we have an agreed solution. Did I miss anything? Regards Mark From: Victor Fajardo [mailto:vf0213@gmail.com] Sent: April 8, 2010 4:23 PM To: Mark Jones Cc: Sebastien Decugis; dime@ietf.org Subject: Re: [Dime] NAPTR fix for 3588bis Hi Mark, Are there any other open issues with this thread ? Do we have an agreed upo= n solution ? regards, victor On Thu, Apr 8, 2010 at 3:02 PM, Mark Jones > wrote: > -----Original Message----- > From: dime-bounces@ietf.org [mailto:dime-bo= unces@ietf.org] On Behalf Of > Sebastien Decugis > Sent: April 1, 2010 1:39 AM > To: dime@ietf.org > Subject: Re: [Dime] NAPTR fix for 3588bis > > Hi, > > > diameter.tcp | TCP > > diameter.sctp | SCTP > > diameter.tls | TLS > > > > I still don't understand why TLS is at the same level as TCP and SCTP, > while it is actually TLS over TCP or TLS over SCTP. I think that either > "secure diameter" (diameters?) or "secure tcp / secure sctp" (tcps / > sctps) would make more sense. > Thanks for the feedback, Sebastien. Now the tag ABNF issue is resolved, how about: Tag | Protocol ------------------|--------- diameter.tcp | TCP diameter.sctp | SCTP diameter.tls.tcp | TLS/TCP diameter.tls.sctp | TLS/SCTP > By the way, the document lacks a reference on how TLSoverSCTP is > supposed to be implemented... (RFC3436?) > Agreed. Regards Mark > Best regards, > Sebastien. > > -- > Sebastien Decugis > Research fellow > Network Architecture Group > NICT (nict.go.jp) > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --_000_B4B762B06D90774E9E8016C89B66AF87561322BBm679t05fpmisbri_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Victor,

 

I counted six issues raised by the proposed NAPTR fix:<= /o:p>

 

1) Resolve what to do about existing NAPTR entries in RFC358= 8 (Jouni).

          =       Conclusion: Let them die with RFC3588 (when obsoleted by 3588bis).

 

2) Application protocol tags do not confirm to the ABNF in R= FC3958 (Jouni)

          =       Conclusion: RFC3958 errata updated so the protocol tags now do conform to the new ABNF.=

 

3) Add a TLS record to the S-NAPTR example (Jouni).

          =       Conclusion: Include Jouni’s TLS example text in this fix.

 

4) Application protocol tag for TLS does not differentiate TLS/TCP vs TLS/SCTP (Sebastian).

          =       Conclusion: New TLS tags proposed to Sebastian. Still open.

 

5) Missing ref to TLS/SCTP - RFC3436 (Sebastian).=

          =       Conclusion: Add the missing reference to 3588bis. Unrelated to this fix though.

 

6) Should this be handled as an errata to 3588 and/or added = to 3588bis.

          =       Conclusion: Fix in 3588bis is preferred approach (Thanks Glen & Lionel for feedback= ).

 

If Sebastian is OK with the new application protocol tags fo= r TLS, I think we have an agreed solution.

 

Did I miss anything?

 

Regards

Mark

 

From: Victor Fajard= o [mailto:vf0213@gmail.com]
Sent: April 8, 2010 4:23 PM
To: Mark Jones
Cc: Sebastien Decugis; dime@ietf.org
Subject: Re: [Dime] NAPTR fix for 3588bis

 

Hi Mark,

Are there any other open issues with this thread ? Do we have an agreed upo= n solution ?

regards,
victor

On Thu, Apr 8, 2010 at 3:02 PM, Mark Jones <Mark.Jones@bridgewatersys= tems.com> wrote:

> -----Original Message-----
> From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org]= On Behalf Of

> Sebastien Decugis
> Sent: April 1, 2010 1:39 AM
> To: dime@ietf.org
> Subject: Re: [Dime] NAPTR fix for 3588bis
>

> Hi,
>
> >    diameter.tcp   | TCP
> >    diameter.sctp  | SCTP
> >    diameter.tls   | TLS
> >
>
> I still don't understand why TLS is at the same level as TCP and SCTP,=
> while it is actually TLS over TCP or TLS over SCTP. I think that eithe= r
> "secure diameter" (diameters?) or "secure tcp / secure sctp" (tcps /
> sctps) would make more sense.
>

Thanks for the feedback, Sebastien.

Now the tag ABNF issue is resolved, how about:

  Tag               | Protocol
  ------------------|---------

  diameter.tcp      | TCP
  diameter.sctp     | SCTP

  diameter.tls.tcp  | TLS/TCP
  diameter.tls.sctp | TLS/SCTP


> By the way, the document lacks a reference on how TLSoverSCTP is
> supposed to be implemented... (RFC3436?)
>

Agreed.

Regards
Mark


> Best regards,
> Sebastien.
>
> --
> Sebastien Decugis
> Research fellow
> Network Architecture Group
> NICT (nict.go.jp)<= br> >
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
_______________________________________________
DiME mailing list
DiME@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/dime

 

--_000_B4B762B06D90774E9E8016C89B66AF87561322BBm679t05fpmisbri_-- From lionel.morand@orange-ftgroup.com Fri Apr 9 09:49:16 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14E723A6924 for ; Fri, 9 Apr 2010 09:49:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.049 X-Spam-Level: X-Spam-Status: No, score=-1.049 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_83=0.6, J_CHICKENPOX_84=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mTrNIfAytiQB for ; Fri, 9 Apr 2010 09:49:15 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by core3.amsl.com (Postfix) with ESMTP id B875E3A68DE for ; Fri, 9 Apr 2010 09:49:14 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id F2241A00658; Fri, 9 Apr 2010 18:42:25 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id E7E69A0061D; Fri, 9 Apr 2010 18:42:25 +0200 (CEST) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Fri, 9 Apr 2010 18:42:13 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 9 Apr 2010 18:42:07 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] NAPTR fix for 3588bis thread-index: AcrRXb1oYr1v6452QtC5yn/LXctL/QF94WRAACtjO9A= References: <4BB43191.5000505@nict.go.jp> From: To: , X-OriginalArrivalTime: 09 Apr 2010 16:42:13.0833 (UTC) FILETIME=[9B783B90:01CAD803] Cc: dime@ietf.org Subject: Re: [Dime] NAPTR fix for 3588bis X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 16:49:16 -0000 Mark, S=E9bastien, I don't have a specific issue with TLS over SCTP but if we rae referring = to the current version of the RFC3588bis, there is the following = limitation in section 2.1: " It is assumed that TLS is run on top of TCP when it is used. The remainder of this document uses the term TLS to abbreviate the use of TLS over TCP." Before going further on this area, I would like to know why such a = limitation was put. Regards, Lionel > -----Message d'origine----- > De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De=20 > la part de Mark Jones > Envoy=E9 : jeudi 8 avril 2010 22:03 > =C0 : Sebastien Decugis > Cc : dime@ietf.org > Objet : Re: [Dime] NAPTR fix for 3588bis >=20 > > -----Original Message----- > > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org]=20 > On Behalf=20 > > Of Sebastien Decugis > > Sent: April 1, 2010 1:39 AM > > To: dime@ietf.org > > Subject: Re: [Dime] NAPTR fix for 3588bis > >=20 > > Hi, > >=20 > > > diameter.tcp | TCP > > > diameter.sctp | SCTP > > > diameter.tls | TLS > > > > >=20 > > I still don't understand why TLS is at the same level as=20 > TCP and SCTP,=20 > > while it is actually TLS over TCP or TLS over SCTP. I think that=20 > > either "secure diameter" (diameters?) or "secure tcp / secure sctp"=20 > > (tcps / > > sctps) would make more sense. > >=20 >=20 >=20 > Thanks for the feedback, Sebastien. >=20 > Now the tag ABNF issue is resolved, how about: >=20 > Tag | Protocol > ------------------|--------- > diameter.tcp | TCP > diameter.sctp | SCTP > diameter.tls.tcp | TLS/TCP > diameter.tls.sctp | TLS/SCTP >=20 > > By the way, the document lacks a reference on how TLSoverSCTP is=20 > > supposed to be implemented... (RFC3436?) > >=20 >=20 > Agreed. >=20 > Regards > Mark >=20 > > Best regards, > > Sebastien. > >=20 > > -- > > Sebastien Decugis > > Research fellow > > Network Architecture Group > > NICT (nict.go.jp) > >=20 > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www.ietf.org/mailman/listinfo/dime > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime >=20 From vf0213@gmail.com Fri Apr 9 10:01:38 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADD893A690F for ; Fri, 9 Apr 2010 10:01:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_83=0.6, J_CHICKENPOX_84=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Pp4+nL98v0g for ; Fri, 9 Apr 2010 10:01:37 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id BBA6F3A6452 for ; Fri, 9 Apr 2010 10:01:36 -0700 (PDT) Received: by wyb35 with SMTP id 35so44347wyb.31 for ; Fri, 09 Apr 2010 10:01:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=mvC0zORv1omSXCO8O5Kxe3YTvdNx2F2n9amVAsKD0CM=; b=gdVEVVm6FRnpaHhYg26UkGqDSuuj3k4DZwy7aY/c9DB3pAvPdOh7In7nHn6lBpJiZH ecQbWQIPbaDtt1VyN73E6iYf3GkbqJxOvnoboSkyMoshzlZ453bIsiurRyZt5hyV1Y8t OPbAvjezP0hVcVJX8SPa7BV8gJsJl08UgyGY0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=uFbljfDRHpAxEsj6wSisrPoTsWFBCLwPn/x+glgPLiUveSsaIhYqAFuynQ5XhPLEcF Wh97HSIk6CE1GXsquqZRFiUh+a/e2KXXvbVTCPGXR712r9RYcwMA0/3IsegNreE8pX45 xTAT/AQQWQPPe5FQBsVXDbXsk1e75MrT4adRs= MIME-Version: 1.0 Received: by 10.216.170.73 with HTTP; Fri, 9 Apr 2010 10:01:28 -0700 (PDT) In-Reply-To: References: <4BB43191.5000505@nict.go.jp> Date: Fri, 9 Apr 2010 12:01:28 -0500 Received: by 10.216.160.213 with SMTP id u63mr180986wek.128.1270832488765; Fri, 09 Apr 2010 10:01:28 -0700 (PDT) Message-ID: From: Victor Fajardo To: lionel.morand@orange-ftgroup.com Content-Type: multipart/alternative; boundary=0016e6541b040fdc890483d0bf80 Cc: Mark.Jones@bridgewatersystems.com, dime@ietf.org Subject: Re: [Dime] NAPTR fix for 3588bis X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 17:01:38 -0000 --0016e6541b040fdc890483d0bf80 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Lionel, I guess it was added there because in practice, TLS is most often run over TCP. Although, SCTP can be used, simplification of the process was the goal= . This is also reinforced when we cleaned up the inband-security in CER/CEA and give way to specific listener port for TLS over TCP. We are treating TL= S over TCP as a unique secure transport for diameter and this is the reason why we have TLS over TCP as the same level as TCP and SCTP. regards, victor On Fri, Apr 9, 2010 at 11:42 AM, wrote: > Mark, S=E9bastien, > > I don't have a specific issue with TLS over SCTP but if we rae referring = to > the current version of the RFC3588bis, there is the following limitation = in > section 2.1: > > " It is assumed that TLS is run on top of TCP when it is used. > The remainder of this document uses the term TLS to abbreviate the > use of TLS over TCP." > > Before going further on this area, I would like to know why such a > limitation was put. > > Regards, > > Lionel > > > -----Message d'origine----- > > De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De > > la part de Mark Jones > > Envoy=E9 : jeudi 8 avril 2010 22:03 > > =C0 : Sebastien Decugis > > Cc : dime@ietf.org > > Objet : Re: [Dime] NAPTR fix for 3588bis > > > > > -----Original Message----- > > > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] > > On Behalf > > > Of Sebastien Decugis > > > Sent: April 1, 2010 1:39 AM > > > To: dime@ietf.org > > > Subject: Re: [Dime] NAPTR fix for 3588bis > > > > > > Hi, > > > > > > > diameter.tcp | TCP > > > > diameter.sctp | SCTP > > > > diameter.tls | TLS > > > > > > > > > > I still don't understand why TLS is at the same level as > > TCP and SCTP, > > > while it is actually TLS over TCP or TLS over SCTP. I think that > > > either "secure diameter" (diameters?) or "secure tcp / secure sctp" > > > (tcps / > > > sctps) would make more sense. > > > > > > > > > Thanks for the feedback, Sebastien. > > > > Now the tag ABNF issue is resolved, how about: > > > > Tag | Protocol > > ------------------|--------- > > diameter.tcp | TCP > > diameter.sctp | SCTP > > diameter.tls.tcp | TLS/TCP > > diameter.tls.sctp | TLS/SCTP > > > > > By the way, the document lacks a reference on how TLSoverSCTP is > > > supposed to be implemented... (RFC3436?) > > > > > > > Agreed. > > > > Regards > > Mark > > > > > Best regards, > > > Sebastien. > > > > > > -- > > > Sebastien Decugis > > > Research fellow > > > Network Architecture Group > > > NICT (nict.go.jp) > > > > > > _______________________________________________ > > > DiME mailing list > > > DiME@ietf.org > > > https://www.ietf.org/mailman/listinfo/dime > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www.ietf.org/mailman/listinfo/dime > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > --0016e6541b040fdc890483d0bf80 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Lionel,

I guess it was added there because in practice, TLS is mo= st often run over TCP. Although, SCTP can be used, simplification of the pr= ocess was the goal. This is also reinforced when we cleaned up the inband-s= ecurity in CER/CEA and give way to specific listener port for TLS over TCP.= We are treating TLS over TCP as a unique secure transport for diameter and= this is the reason why we have TLS over TCP as the same level as TCP and S= CTP.

regards,
victor


On Fri, Apr 9,= 2010 at 11:42 AM, <lionel.morand@orange-ftgroup.com> wrote:
Mark, S=E9bastien= ,

I don't have a specific issue with TLS over SCTP but if we rae referrin= g to the current version of the RFC3588bis, there is the following limitati= on in section 2.1:

" =A0It is assumed that TLS is run on top of TCP when it is used.
=A0 The remainder of this document uses the term TLS to abbreviate the
=A0 use of TLS over TCP."

Before going further on this area, I would like to know why such a limitati= on was put.

Regards,

Lionel

> -----Message d'origine-----
> De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De
> la part de Mark Jones
> Envoy=E9 : jeudi 8 avril 2010 22:03
> =C0 : Sebastien Decugis
> Cc : dime@ietf.org
> Objet : Re: [Dime] NAPTR fix for 3588bis
>
> > -----Original Message-----
> > From: dime-bounces@ietf.= org [mailto:dime-bounces@ietf.= org]
> On Behalf
> > Of Sebastien Decugis
> > Sent: April 1, 2010 1:39 AM
> > To: dime@ietf.org
> > Subject: Re: [Dime] NAPTR fix for 3588bis
> >
> > Hi,
> >
> > > =A0 =A0diameter.tcp =A0 | TCP
> > > =A0 =A0diameter.sctp =A0| SCTP
> > > =A0 =A0diameter.tls =A0 | TLS
> > >
> >
> > I still don't understand why TLS is at the same level as
> TCP and SCTP,
> > while it is actually TLS over TCP or TLS over SCTP. I think that<= br> > > either "secure diameter" (diameters?) or "secure t= cp / secure sctp"
> > (tcps /
> > sctps) would make more sense.
> >
>
>
> Thanks for the feedback, Sebastien.
>
> Now the tag ABNF issue is resolved, how about:
>
> =A0 =A0Tag =A0 =A0 =A0 =A0 =A0 =A0 =A0 | Protocol
> =A0 =A0------------------|---------
> =A0 =A0diameter.tcp =A0 =A0 =A0| TCP
> =A0 =A0diameter.sctp =A0 =A0 | SCTP
> =A0 =A0diameter.tls.tcp =A0| TLS/TCP
> =A0 =A0diameter.tls.sctp | TLS/SCTP
>
> > By the way, the document lacks a reference on how TLSoverSCTP is<= br> > > supposed to be implemented... (RFC3436?)
> >
>
> Agreed.
>
> Regards
> Mark
>
> > Best regards,
> > Sebastien.
> >
> > --
> > Sebastien Decugis
> > Research fellow
> > Network Architecture Group
> > NICT (nict.go.jp<= /a>)
> >
> > _______________________________________________
> > DiME mailing list
> > DiME@ietf.org
> > https://www.ietf.org/mailman/listinfo/dime
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
>
_______________________________________________
DiME mailing list
DiME@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/dime

--0016e6541b040fdc890483d0bf80-- From lionel.morand@orange-ftgroup.com Fri Apr 9 10:10:28 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C218B3A68AA for ; Fri, 9 Apr 2010 10:10:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.049 X-Spam-Level: X-Spam-Status: No, score=-1.049 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_83=0.6, J_CHICKENPOX_84=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gaCtyNV+CPqE for ; Fri, 9 Apr 2010 10:10:27 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by core3.amsl.com (Postfix) with ESMTP id 883CA3A688E for ; Fri, 9 Apr 2010 10:10:26 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id CDB7357C348; Fri, 9 Apr 2010 19:10:23 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id BF4F457D108; Fri, 9 Apr 2010 19:10:23 +0200 (CEST) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Fri, 9 Apr 2010 19:10:18 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CAD807.866CB68E" Date: Fri, 9 Apr 2010 19:10:12 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] NAPTR fix for 3588bis thread-index: AcrYBl5X6yV0pEH6SZe+hSfDqo3bCQAAGcug References: <4BB43191.5000505@nict.go.jp> From: To: X-OriginalArrivalTime: 09 Apr 2010 17:10:18.0476 (UTC) FILETIME=[87985AC0:01CAD807] Cc: Mark.Jones@bridgewatersystems.com, dime@ietf.org Subject: Re: [Dime] NAPTR fix for 3588bis X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 17:10:28 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAD807.866CB68E Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thx Victor for the clarification. =20 It was also my recollection but I was not deeply involved in this = discussion. That means that, whatever the exact wording (i.e. = diameter.tls.tcp, diameter.tls), only TCP over TLS is added as = alternative to ipsec. And only three tags have to be defined i.e. TCP, = SCTP and TLS/TCP. =20 I'm fine with "diameter.tls.tcp" for the last one. =20 regards, =20 lionel ________________________________ De : Victor Fajardo [mailto:vf0213@gmail.com]=20 Envoy=E9 : vendredi 9 avril 2010 19:01 =C0 : MORAND Lionel RD-CORE-ISS Cc : Mark.Jones@bridgewatersystems.com; sdecugis@nict.go.jp; = dime@ietf.org Objet : Re: [Dime] NAPTR fix for 3588bis =09 =09 Hi Lionel, =09 I guess it was added there because in practice, TLS is most often run = over TCP. Although, SCTP can be used, simplification of the process was = the goal. This is also reinforced when we cleaned up the inband-security = in CER/CEA and give way to specific listener port for TLS over TCP. We = are treating TLS over TCP as a unique secure transport for diameter and = this is the reason why we have TLS over TCP as the same level as TCP and = SCTP. =09 regards, victor =09 =09 =09 On Fri, Apr 9, 2010 at 11:42 AM, = wrote: =09 Mark, S=E9bastien, =09 I don't have a specific issue with TLS over SCTP but if we rae = referring to the current version of the RFC3588bis, there is the = following limitation in section 2.1: =09 " It is assumed that TLS is run on top of TCP when it is used. The remainder of this document uses the term TLS to abbreviate the use of TLS over TCP." =09 Before going further on this area, I would like to know why such a = limitation was put. =09 Regards, =09 Lionel =09 > -----Message d'origine----- > De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De > la part de Mark Jones > Envoy=E9 : jeudi 8 avril 2010 22:03 > =C0 : Sebastien Decugis > Cc : dime@ietf.org > Objet : Re: [Dime] NAPTR fix for 3588bis =09 > > > -----Original Message----- > > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] > On Behalf > > Of Sebastien Decugis > > Sent: April 1, 2010 1:39 AM > > To: dime@ietf.org > > Subject: Re: [Dime] NAPTR fix for 3588bis > > > > Hi, > > > > > diameter.tcp | TCP > > > diameter.sctp | SCTP > > > diameter.tls | TLS > > > > > > > I still don't understand why TLS is at the same level as > TCP and SCTP, > > while it is actually TLS over TCP or TLS over SCTP. I think that > > either "secure diameter" (diameters?) or "secure tcp / secure = sctp" > > (tcps / > > sctps) would make more sense. > > > > > Thanks for the feedback, Sebastien. > > Now the tag ABNF issue is resolved, how about: > > Tag | Protocol > ------------------|--------- > diameter.tcp | TCP > diameter.sctp | SCTP > diameter.tls.tcp | TLS/TCP > diameter.tls.sctp | TLS/SCTP > > > By the way, the document lacks a reference on how TLSoverSCTP is > > supposed to be implemented... (RFC3436?) > > > > Agreed. > > Regards > Mark > > > Best regards, > > Sebastien. > > > > -- > > Sebastien Decugis > > Research fellow > > Network Architecture Group > > NICT (nict.go.jp) > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www.ietf.org/mailman/listinfo/dime > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime =09 ------_=_NextPart_001_01CAD807.866CB68E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Thx Victor for the = clarification.
 
It=20 was also my recollection but I was not deeply involved in this = discussion. That=20 means that, whatever the exact wording (i.e. diameter.tls.tcp, diameter.tls), only = TCP over TLS=20 is added as alternative to ipsec. And only three tags have to be defined = i.e.=20 TCP, SCTP and TLS/TCP.
 
I'm fine with "diameter.tls.tcp" for the last=20 one.
 
regards,
 
lionel

De : Victor Fajardo=20 [mailto:vf0213@gmail.com]
Envoy=E9 : vendredi 9 avril = 2010=20 19:01
=C0 : MORAND Lionel = RD-CORE-ISS
Cc :=20 Mark.Jones@bridgewatersystems.com; sdecugis@nict.go.jp;=20 dime@ietf.org
Objet : Re: [Dime] NAPTR fix for=20 3588bis

Hi Lionel,

I guess it was added there because in = practice,=20 TLS is most often run over TCP. Although, SCTP can be used, = simplification of=20 the process was the goal. This is also reinforced when we cleaned up = the=20 inband-security in CER/CEA and give way to specific listener port for = TLS over=20 TCP. We are treating TLS over TCP as a unique secure transport for = diameter=20 and this is the reason why we have TLS over TCP as the same level as = TCP and=20 SCTP.

regards,
victor


On Fri, Apr 9, 2010 at 11:42 AM, <lionel.morand@orange-ftg= roup.com>=20 wrote:
Mark,=20 S=E9bastien,

I don't have a specific issue with TLS over SCTP = but if we=20 rae referring to the current version of the RFC3588bis, there is the = following limitation in section 2.1:

"  It is assumed = that TLS=20 is run on top of TCP when it is used.
  The remainder of = this=20 document uses the term TLS to abbreviate the
  use of TLS = over=20 TCP."

Before going further on this area, I would like to know = why=20 such a limitation was put.

Regards,

Lionel

> = -----Message d'origine-----
> De : dime-bounces@ietf.org = [mailto:dime-bounces@ietf.org] = De
> la=20 part de Mark Jones
> Envoy=E9 : jeudi 8 avril 2010 = 22:03
> =C0 :=20 Sebastien Decugis
> Cc : dime@ietf.org
> Objet : Re: = [Dime]=20 NAPTR fix for 3588bis
>
> > -----Original Message-----
> = >=20 From: dime-bounces@ietf.org=20 [mailto:dime-bounces@ietf.org]
> = On=20 Behalf
> > Of Sebastien Decugis
> > Sent: April 1, = 2010=20 1:39 AM
> > To: dime@ietf.org
> > = Subject: Re:=20 [Dime] NAPTR fix for 3588bis
> >
> > Hi,
>=20 >
> > >    diameter.tcp   | = TCP
> >=20 >    diameter.sctp  | SCTP
> > > =  =20  diameter.tls   | TLS
> > >
> = >
> >=20 I still don't understand why TLS is at the same level as
> TCP = and=20 SCTP,
> > while it is actually TLS over TCP or TLS over = SCTP. I=20 think that
> > either "secure diameter" (diameters?) or = "secure tcp=20 / secure sctp"
> > (tcps /
> > sctps) would make = more=20 sense.
> >
>
>
> Thanks for the feedback, = Sebastien.
>
> Now the tag ABNF issue is resolved, how=20 about:
>
>    Tag         =  =20     | Protocol
>  =20  ------------------|---------
>    diameter.tcp =  =20    | TCP
>    diameter.sctp     = |=20 SCTP
>    diameter.tls.tcp  | TLS/TCP
> =  =20  diameter.tls.sctp | TLS/SCTP
>
> > By the way, = the=20 document lacks a reference on how TLSoverSCTP is
> > = supposed to be=20 implemented... (RFC3436?)
> >
>
>=20 Agreed.
>
> Regards
> Mark
>
> > = Best=20 regards,
> > Sebastien.
> >
> > = --
> >=20 Sebastien Decugis
> > Research fellow
> > Network=20 Architecture Group
> > NICT (nict.go.jp)
> >
> >=20 _______________________________________________
> > DiME = mailing=20 list
> > DiME@ietf.org
>=20 > https://www.ietf.org/mailman/listinfo/dime
>=20 _______________________________________________
> DiME mailing = list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
>_______________________________________________
DiME=20 mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime
<= /DIV>

------_=_NextPart_001_01CAD807.866CB68E-- From dromasca@avaya.com Sun Apr 11 03:02:19 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E911A3A69A4 for ; Sun, 11 Apr 2010 03:02:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.762 X-Spam-Level: X-Spam-Status: No, score=-1.762 tagged_above=-999 required=5 tests=[AWL=0.837, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fxmM0TCnuCIa for ; Sun, 11 Apr 2010 03:02:19 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 1D9E03A69A0 for ; Sun, 11 Apr 2010 03:02:19 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.52,184,1270440000"; d="scan'208";a="212967042" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 11 Apr 2010 06:02:14 -0400 X-IronPort-AV: E=Sophos;i="4.52,184,1270440000"; d="scan'208";a="450535716" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.15]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 11 Apr 2010 06:02:13 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 11 Apr 2010 12:01:52 +0200 Message-ID: In-Reply-To: <00F70B04-0BDF-44FA-87FA-356872F3B323@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Draft notes from IETF#77 Dime WG meeting. Thread-Index: AcrQx+keTC1et+kRSN22H/fQdDhcCAIldH5Q References: <00F70B04-0BDF-44FA-87FA-356872F3B323@gmail.com> From: "Romascanu, Dan (Dan)" To: "jouni korhonen" , Subject: Re: [Dime] Draft notes from IETF#77 Dime WG meeting. X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Apr 2010 10:02:20 -0000 I apologize for the delay in commenting, but I was on vacation for the two weeks following the Anaheim meeting.=20 I have one clarification to make:=20 > Dan: this does not solve any problems related to access. Sees little chance for this to be accepted as a DIME work item. If you want to do it, there is another WG (?) As I remember the discussion the intent in the last sentence was rather 'If you want to do it you may need to charter another WG'.=20 Dan =20 > -----Original Message----- > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On=20 > Behalf Of jouni korhonen > Sent: Wednesday, March 31, 2010 2:47 PM > To: dime@ietf.org > Subject: [Dime] Draft notes from IETF#77 Dime WG meeting. >=20 > Hi all, >=20 > First, thanks to Sebastien and Tom for detailed notes! Here=20 > are what we combined out of them. Have a look at it and if=20 > you think something has been captured incorrectly, please let=20 > us know asap. The final notes will have a slightly better=20 > layout.. hopefully ;) >=20 > - Jouni & Lionel >=20 >=20 From jouni.nospam@gmail.com Sun Apr 11 12:40:35 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3C973A6839 for ; Sun, 11 Apr 2010 12:40:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fPZaz0KI8j3p for ; Sun, 11 Apr 2010 12:40:34 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.155]) by core3.amsl.com (Postfix) with ESMTP id D2BE93A67B4 for ; Sun, 11 Apr 2010 12:40:33 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id l26so937832fgb.13 for ; Sun, 11 Apr 2010 12:40:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=3PrWD8FQpKBtQ7LYBuYveL0cIr+3+Z7G3g+G0UqlL+Q=; b=SRx8L5f7HnaiY/LTn8qAuObNm8BxBgZaGCwkVOmybuDdWW7WfhWSp7hBteNaXMJq9o FpmW/HryI890JuCHVz51BQXtErUi14APCllOEsQm86MA6ca0yrJKThuGm8VUHRr3J/qX 15tU6I5gIOjvLJyNkAuVw8IWTuR0V+sxwqsN4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=kb0Nd77nJABISBRYGps8QH8acO8wzw6lUlYvSSi2bLHF+PqX1uYWtKU9XYXR9ket+i FJ7RAmpoJldD9dKOLiCL939vCAo3hsIFOvBAhYsWAYUeAZQ6p+iL8HMHUTynI+8uGw0g Z/JTi2bs0Wj5W8dduILNPC6be2FuvqodTIeYk= Received: by 10.223.117.164 with SMTP id r36mr2188891faq.28.1271014822784; Sun, 11 Apr 2010 12:40:22 -0700 (PDT) Received: from a88-112-141-231.elisa-laajakaista.fi (a88-112-141-231.elisa-laajakaista.fi [88.112.141.231]) by mx.google.com with ESMTPS id c28sm7061801fka.14.2010.04.11.12.40.21 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 11 Apr 2010 12:40:22 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: Date: Sun, 11 Apr 2010 22:40:20 +0300 Content-Transfer-Encoding: 7bit Message-Id: <137E1A7D-03AE-4C66-B8DE-7931072CEF90@gmail.com> References: <00F70B04-0BDF-44FA-87FA-356872F3B323@gmail.com> To: "Romascanu, Dan (Dan)" X-Mailer: Apple Mail (2.1077) Cc: dime@ietf.org Subject: Re: [Dime] Draft notes from IETF#77 Dime WG meeting. X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Apr 2010 19:40:35 -0000 Hi Dan, Thanks for the clarification. I have updated the minutes. - Jouni On Apr 11, 2010, at 1:01 PM, Romascanu, Dan (Dan) wrote: > I apologize for the delay in commenting, but I was on vacation for the > two weeks following the Anaheim meeting. > > I have one clarification to make: > >> Dan: this does not solve any problems related to access. Sees little > chance for > this to be accepted as a DIME work item. If you want to do it, > there is > another WG (?) > > As I remember the discussion the intent in the last sentence was rather > 'If you want to do it you may need to charter another WG'. > > Dan > > >> -----Original Message----- >> From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On >> Behalf Of jouni korhonen >> Sent: Wednesday, March 31, 2010 2:47 PM >> To: dime@ietf.org >> Subject: [Dime] Draft notes from IETF#77 Dime WG meeting. >> >> Hi all, >> >> First, thanks to Sebastien and Tom for detailed notes! Here >> are what we combined out of them. Have a look at it and if >> you think something has been captured incorrectly, please let >> us know asap. The final notes will have a slightly better >> layout.. hopefully ;) >> >> - Jouni & Lionel >> >> From sdecugis@nict.go.jp Sun Apr 11 19:43:45 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B017A3A68C0 for ; Sun, 11 Apr 2010 19:43:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.134 X-Spam-Level: X-Spam-Status: No, score=0.134 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HELO_EQ_JP=1.244] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9uhVeSYc-lw3 for ; Sun, 11 Apr 2010 19:43:44 -0700 (PDT) Received: from ns1.nict.go.jp (ns1.nict.go.jp [IPv6:2001:2f8:29::2]) by core3.amsl.com (Postfix) with ESMTP id C2C343A67B2 for ; Sun, 11 Apr 2010 19:43:43 -0700 (PDT) Received: from gw1.nict.go.jp (gw1 [133.243.18.250]) by ns1.nict.go.jp with ESMTP id o3C2hWSK029705; Mon, 12 Apr 2010 11:43:32 +0900 (JST) Received: from gw1.nict.go.jp (localhost [127.0.0.1]) by gw1.nict.go.jp with ESMTP id o3C2hWPZ001926; Mon, 12 Apr 2010 11:43:32 +0900 (JST) Received: from mail1.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw1.nict.go.jp with ESMTP id o3C2hWbg001922; Mon, 12 Apr 2010 11:43:32 +0900 (JST) Received: from mail1.nict.go.jp (localhost [127.0.0.1]) by mail1.nict.go.jp (NICT Mail) with ESMTP id 3D85216AAC; Mon, 12 Apr 2010 11:43:32 +0900 (JST) Received: from [133.243.146.171] (5gou2f-dhcp11.nict.go.jp [133.243.146.171]) by mail1.nict.go.jp (NICT Mail) with ESMTP id 329E4169C1; Mon, 12 Apr 2010 11:43:32 +0900 (JST) Message-ID: <4BC288CB.9030002@nict.go.jp> Date: Mon, 12 Apr 2010 11:43:23 +0900 From: Sebastien Decugis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Mark Jones References: <4BB43191.5000505@nict.go.jp> In-Reply-To: X-Enigmail-Version: 1.0.1 OpenPGP: id=33D9F61D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: "dime@ietf.org" Subject: Re: [Dime] NAPTR fix for 3588bis X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Apr 2010 02:43:45 -0000 Hi, Sorry for the delay, I was on vacation. Le 09/04/2010 07:02, Mark Jones a écrit : > 4) Application protocol tag for TLS does not differentiate TLS/TCP vs > TLS/SCTP (Sebastian). > > Conclusion: New TLS tags proposed to Sebastian. Still > open. > I am perfectly fine with the resolution you proposed, thank you! > 5) Missing ref to TLS/SCTP - RFC3436 (Sebastian). > > Conclusion: Add the missing reference to 3588bis. > Unrelated to this fix though. > I guess this resolution will require a bit more feedback from the group, there may be other ways to implement TLS over SCTP... Can the chairs give direction on this issue? Thanks! Sebastien. -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) From sdecugis@nict.go.jp Sun Apr 11 19:55:32 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF8693A67B2 for ; Sun, 11 Apr 2010 19:55:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, HELO_EQ_JP=1.244, J_CHICKENPOX_83=0.6, J_CHICKENPOX_84=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O9OfroRgPZ1t for ; Sun, 11 Apr 2010 19:55:31 -0700 (PDT) Received: from ns1.nict.go.jp (ns1.nict.go.jp [IPv6:2001:2f8:29::2]) by core3.amsl.com (Postfix) with ESMTP id C66BB3A659C for ; Sun, 11 Apr 2010 19:55:30 -0700 (PDT) Received: from gw1.nict.go.jp (gw1 [133.243.18.250]) by ns1.nict.go.jp with ESMTP id o3C2tLhl000719; Mon, 12 Apr 2010 11:55:21 +0900 (JST) Received: from gw1.nict.go.jp (localhost [127.0.0.1]) by gw1.nict.go.jp with ESMTP id o3C2tLjx004874; Mon, 12 Apr 2010 11:55:21 +0900 (JST) Received: from mail3.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw1.nict.go.jp with ESMTP id o3C2tK30004871; Mon, 12 Apr 2010 11:55:21 +0900 (JST) Received: from mail3.nict.go.jp (localhost [127.0.0.1]) by mail3.nict.go.jp (NICT Mail) with ESMTP id DC9EA16946; Mon, 12 Apr 2010 11:55:20 +0900 (JST) Received: from [133.243.146.171] (5gou2f-dhcp11.nict.go.jp [133.243.146.171]) by mail3.nict.go.jp (NICT Mail) with ESMTP id D46491680C; Mon, 12 Apr 2010 11:55:20 +0900 (JST) Message-ID: <4BC28B90.4090807@nict.go.jp> Date: Mon, 12 Apr 2010 11:55:12 +0900 From: Sebastien Decugis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: lionel.morand@orange-ftgroup.com References: <4BB43191.5000505@nict.go.jp> In-Reply-To: X-Enigmail-Version: 1.0.1 OpenPGP: id=33D9F61D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: Mark.Jones@bridgewatersystems.com, dime@ietf.org Subject: Re: [Dime] NAPTR fix for 3588bis X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Apr 2010 02:55:32 -0000 Hi, I personally see no point in limiting the ability to use TLS over SCTP. In several places, the document describes SCTP as a "better" transport for Diameter than TCP (for the reasons described in RFC3539). It also recommends the use of TLS to protect the connection -- and it is quite straight-forward with a dedicated TLS port. It is easy to listen on this TLS-dedicated port in SCTP in addition to TCP. BTW I think the document should have a reference to RFC3554 (SCTP over IPsec) as well... Best regards, Sebastien. Le 10/04/2010 02:10, lionel.morand@orange-ftgroup.com a écrit : > Thx Victor for the clarification. > > It was also my recollection but I was not deeply involved in this > discussion. That means that, whatever the exact wording (i.e. > diameter.tls.tcp, diameter.tls), only TCP over TLS is added as > alternative to ipsec. And only three tags have to be defined i.e. TCP, > SCTP and TLS/TCP. > > I'm fine with "diameter.tls.tcp" for the last one. > > regards, > > lionel > > ------------------------------------------------------------------------ > *De :* Victor Fajardo [mailto:vf0213@gmail.com] > *Envoyé :* vendredi 9 avril 2010 19:01 > *À :* MORAND Lionel RD-CORE-ISS > *Cc :* Mark.Jones@bridgewatersystems.com; sdecugis@nict.go.jp; > dime@ietf.org > *Objet :* Re: [Dime] NAPTR fix for 3588bis > > Hi Lionel, > > I guess it was added there because in practice, TLS is most often > run over TCP. Although, SCTP can be used, simplification of the > process was the goal. This is also reinforced when we cleaned up > the inband-security in CER/CEA and give way to specific listener > port for TLS over TCP. We are treating TLS over TCP as a unique > secure transport for diameter and this is the reason why we have > TLS over TCP as the same level as TCP and SCTP. > > regards, > victor > > > On Fri, Apr 9, 2010 at 11:42 AM, > wrote: > > Mark, Sébastien, > > I don't have a specific issue with TLS over SCTP but if we rae > referring to the current version of the RFC3588bis, there is > the following limitation in section 2.1: > > " It is assumed that TLS is run on top of TCP when it is used. > The remainder of this document uses the term TLS to > abbreviate the > use of TLS over TCP." > > Before going further on this area, I would like to know why > such a limitation was put. > > Regards, > > Lionel > > > -----Message d'origine----- > > De : dime-bounces@ietf.org > [mailto:dime-bounces@ietf.org ] De > > la part de Mark Jones > > Envoyé : jeudi 8 avril 2010 22:03 > > À : Sebastien Decugis > > Cc : dime@ietf.org > > Objet : Re: [Dime] NAPTR fix for 3588bis > > > > > -----Original Message----- > > > From: dime-bounces@ietf.org > [mailto:dime-bounces@ietf.org ] > > On Behalf > > > Of Sebastien Decugis > > > Sent: April 1, 2010 1:39 AM > > > To: dime@ietf.org > > > Subject: Re: [Dime] NAPTR fix for 3588bis > > > > > > Hi, > > > > > > > diameter.tcp | TCP > > > > diameter.sctp | SCTP > > > > diameter.tls | TLS > > > > > > > > > > I still don't understand why TLS is at the same level as > > TCP and SCTP, > > > while it is actually TLS over TCP or TLS over SCTP. I > think that > > > either "secure diameter" (diameters?) or "secure tcp / > secure sctp" > > > (tcps / > > > sctps) would make more sense. > > > > > > > > > Thanks for the feedback, Sebastien. > > > > Now the tag ABNF issue is resolved, how about: > > > > Tag | Protocol > > ------------------|--------- > > diameter.tcp | TCP > > diameter.sctp | SCTP > > diameter.tls.tcp | TLS/TCP > > diameter.tls.sctp | TLS/SCTP > > > > > By the way, the document lacks a reference on how > TLSoverSCTP is > > > supposed to be implemented... (RFC3436?) > > > > > > > Agreed. > > > > Regards > > Mark > > > > > Best regards, > > > Sebastien. > > > > > > -- > > > Sebastien Decugis > > > Research fellow > > > Network Architecture Group > > > NICT (nict.go.jp ) > > > > > > _______________________________________________ > > > DiME mailing list > > > DiME@ietf.org > > > https://www.ietf.org/mailman/listinfo/dime > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www.ietf.org/mailman/listinfo/dime > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > > -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) From vf0213@gmail.com Mon Apr 12 05:28:00 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD4033A6A1B for ; Mon, 12 Apr 2010 05:28:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EbuNPTKFx4un for ; Mon, 12 Apr 2010 05:27:59 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 656233A691A for ; Mon, 12 Apr 2010 05:27:57 -0700 (PDT) Received: by wwb34 with SMTP id 34so1871259wwb.31 for ; Mon, 12 Apr 2010 05:27:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=PFaFAYM4NCwtg/QcHqylWJznppoxEoSRzemQP6vpaDU=; b=sP2zIVf+lYrEKK9eTV6DdFH8lfvJjwOIcXBR0+gqfiJhUwhwSkcJHyR7q0pTQMESNH sQh8DmZYUiC+QGRZEHaUv3sU7Dpk2fdtuHUfzz739ucdAxAGA0Xm0NNTbPFTwlX0PXIj dSf6yEbjSFu/U33ZSGMtjXlmpWcwNi4F+v6nY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=E6sUZdT89E5eSWKD2HO/DB9YvfI+Hy+vk6nAq1/tdsBZMWvj7Y/hHUOnzk21O7o8Z8 uFLneh+wHHTVQ6gRFtegr41IVITrFd9JBM/9YMqH937hOf1NFTh+If6AupRdzJcVnMv5 EkpoNG5PfcQvvBS4MQZGW69gAXjjqBJIYdKZE= MIME-Version: 1.0 Received: by 10.216.169.207 with HTTP; Mon, 12 Apr 2010 05:27:48 -0700 (PDT) In-Reply-To: <4BC288CB.9030002@nict.go.jp> References: <4BB43191.5000505@nict.go.jp> <4BC288CB.9030002@nict.go.jp> Date: Mon, 12 Apr 2010 07:27:48 -0500 Received: by 10.216.157.1 with SMTP id n1mr1237769wek.141.1271075268302; Mon, 12 Apr 2010 05:27:48 -0700 (PDT) Message-ID: From: Victor Fajardo To: Sebastien Decugis Content-Type: multipart/alternative; boundary=0016367fb6c1d99a6404840945c2 Cc: Mark Jones , "dime@ietf.org" Subject: Re: [Dime] NAPTR fix for 3588bis X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Apr 2010 12:28:00 -0000 --0016367fb6c1d99a6404840945c2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Sebastien, On Sun, Apr 11, 2010 at 9:43 PM, Sebastien Decugis wro= te: > Hi, > > Sorry for the delay, I was on vacation. > > Le 09/04/2010 07:02, Mark Jones a =E9crit : > > 4) Application protocol tag for TLS does not differentiate TLS/TCP vs > > TLS/SCTP (Sebastian). > > > > Conclusion: New TLS tags proposed to Sebastian. Still > > open. > > > > I am perfectly fine with the resolution you proposed, thank you! > > > 5) Missing ref to TLS/SCTP - RFC3436 (Sebastian). > > > > Conclusion: Add the missing reference to 3588bis. > > Unrelated to this fix though. > > > I guess this resolution will require a bit more feedback from the group, > there may be other ways to implement TLS over SCTP... Can the chairs > give direction on this issue? > For all practical purpose, is there really a strong deployable reason to support TLS over SCTP ? I'm just hesitant to delay bis publication to support an academic exercise. regards, victor > > Thanks! > Sebastien. > > -- > Sebastien Decugis > Research fellow > Network Architecture Group > NICT (nict.go.jp) > > --0016367fb6c1d99a6404840945c2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Sebastien,

On Sun, Apr 11, 2010 at 9:4= 3 PM, Sebastien Decugis <sdecugis@nict.go.jp> wrote:
Hi,

Sorry for the delay, I was on vacation.

Le 09/04/2010 07:02, Mark Jones a =E9crit :
> 4) Application protocol tag for TLS does not differentiate TLS/TCP vs<= br> > TLS/SCTP (Sebastian).
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Conclusion: New TLS tags proposed to S= ebastian. Still
> open.
>

I am perfectly fine with the resolution you proposed, thank you!

> 5) Missing ref to TLS/SCTP - RFC3436 (Sebastian).
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Conclusion: Add the missing reference = to 3588bis.
> Unrelated to this fix though.
>
I guess this resolution will require a bit more feedback from the group, there may be other ways to implement TLS over SCTP... Can the chairs
give direction on this issue?


For all practica= l purpose, is there really a strong deployable reason to support TLS over S= CTP ? I'm just hesitant to delay bis publication to support an academic= exercise.

regards,
victor
=A0

=A0

Thanks!
Sebastien.

--
Sebastien Decugis
Research fellow
Network Architecture Group
NICT (nict.go.jp)


--0016367fb6c1d99a6404840945c2-- From lionel.morand@orange-ftgroup.com Mon Apr 12 09:01:36 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E0EA3A6A65 for ; Mon, 12 Apr 2010 09:01:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.648 X-Spam-Level: X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x3giVDcOEWrd for ; Mon, 12 Apr 2010 09:01:34 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by core3.amsl.com (Postfix) with ESMTP id 833643A690B for ; Mon, 12 Apr 2010 09:01:15 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 2D6B5A00600; Mon, 12 Apr 2010 17:59:37 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id 1DA97A005FA; Mon, 12 Apr 2010 17:59:37 +0200 (CEST) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 Apr 2010 17:59:14 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CADA59.18BF51B8" Date: Mon, 12 Apr 2010 17:59:13 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] NAPTR fix for 3588bis thread-index: AcraO5brqmW8eFIpSu6LMDfWj08HgwAEDgQQ References: <4BB43191.5000505@nict.go.jp><4BC288CB.9030002@nict.go.jp> From: To: , X-OriginalArrivalTime: 12 Apr 2010 15:59:14.0716 (UTC) FILETIME=[196F75C0:01CADA59] Cc: Mark.Jones@bridgewatersystems.com, dime@ietf.org Subject: Re: [Dime] NAPTR fix for 3588bis X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Apr 2010 16:01:36 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CADA59.18BF51B8 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, =20 Taking account that this topic came quite late in the revision process = and to not delay the publication of the RFC3588bis, we could maybe = consider to address TLS over SCTP in a separete draft in a latter phase = if there is a WG interest of the WG to support this option. =20 Would it be acceptable? =20 Regards, =20 Lionel =20 ________________________________ De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part de = Victor Fajardo Envoy=E9 : lundi 12 avril 2010 14:28 =C0 : Sebastien Decugis Cc : Mark Jones; dime@ietf.org Objet : Re: [Dime] NAPTR fix for 3588bis =09 =09 Hi Sebastien, =09 =09 On Sun, Apr 11, 2010 at 9:43 PM, Sebastien Decugis = wrote: =09 Hi, =09 Sorry for the delay, I was on vacation. =09 Le 09/04/2010 07:02, Mark Jones a =E9crit : > 4) Application protocol tag for TLS does not differentiate TLS/TCP = vs > TLS/SCTP (Sebastian). > > Conclusion: New TLS tags proposed to Sebastian. = Still > open. > =09 I am perfectly fine with the resolution you proposed, thank you! =09 > 5) Missing ref to TLS/SCTP - RFC3436 (Sebastian). > > Conclusion: Add the missing reference to 3588bis. > Unrelated to this fix though. > I guess this resolution will require a bit more feedback from the = group, there may be other ways to implement TLS over SCTP... Can the chairs give direction on this issue? =09 For all practical purpose, is there really a strong deployable reason = to support TLS over SCTP ? I'm just hesitant to delay bis publication to = support an academic exercise. =09 regards, victor =20 =09 =20 Thanks! Sebastien. =09 -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) =09 =09 ------_=_NextPart_001_01CADA59.18BF51B8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
Taking account that this topic came quite late = in the=20 revision process and to not delay the publication of the = RFC3588bis, we=20 could maybe consider to address TLS over SCTP in a separete draft = in a=20 latter phase if there is a WG interest of the WG to support this=20 option.
 
Would it be acceptable?
 
Regards,
 
Lionel
 

De : dime-bounces@ietf.org=20 [mailto:dime-bounces@ietf.org] De la part de Victor=20 Fajardo
Envoy=E9 : lundi 12 avril 2010 = 14:28
=C0 :=20 Sebastien Decugis
Cc : Mark Jones;=20 dime@ietf.org
Objet : Re: [Dime] NAPTR fix for=20 3588bis

Hi Sebastien,

On Sun, Apr 11, 2010 at 9:43 PM, Sebastien = Decugis=20 <sdecugis@nict.go.jp> = wrote:
Hi,

Sorry=20 for the delay, I was on vacation.

Le 09/04/2010 07:02, Mark = Jones a=20 =E9crit :
> 4) Application protocol tag for TLS does not = differentiate=20 TLS/TCP vs
> TLS/SCTP (Sebastian).
>
>   =  =20             Conclusion: New TLS tags = proposed=20 to Sebastian. Still
> open.
>

I am perfectly fine = with=20 the resolution you proposed, thank you!

> 5) Missing ref = to=20 TLS/SCTP - RFC3436 (Sebastian).
>
>       =  =20         Conclusion: Add the missing reference to = 3588bis.
> Unrelated to this fix though.
>
I guess = this=20 resolution will require a bit more feedback from the group,
there = may be=20 other ways to implement TLS over SCTP... Can the chairs
give = direction on=20 this issue?


For all practical purpose, is there really a strong = deployable=20 reason to support TLS over SCTP ? I'm just hesitant to delay bis = publication=20 to support an academic=20 exercise.

regards,
victor
 

 

Thanks!
Sebastien.

--
Sebastien Decugis
Research = fellow
Network=20 Architecture Group
NICT (nict.go.jp)


------_=_NextPart_001_01CADA59.18BF51B8-- From Mark.Jones@bridgewatersystems.com Mon Apr 12 13:08:50 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 523CD3A6AC3 for ; Mon, 12 Apr 2010 13:08:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.395 X-Spam-Level: X-Spam-Status: No, score=-5.395 tagged_above=-999 required=5 tests=[AWL=1.203, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id waEFeE+9V-zf for ; Mon, 12 Apr 2010 13:08:44 -0700 (PDT) Received: from mail29.messagelabs.com (mail29.messagelabs.com [216.82.249.147]) by core3.amsl.com (Postfix) with ESMTP id 3B6463A684B for ; Mon, 12 Apr 2010 13:08:43 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: Mark.Jones@bridgewatersystems.com X-Msg-Ref: server-9.tower-29.messagelabs.com!1271102902!67819812!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [72.35.6.119] Received: (qmail 18939 invoked from network); 12 Apr 2010 20:08:23 -0000 Received: from mail.bridgewatersystems.com (HELO webmail.bridgewatersystems.com) (72.35.6.119) by server-9.tower-29.messagelabs.com with RC4-SHA encrypted SMTP; 12 Apr 2010 20:08:23 -0000 Received: from m679t05.fpmis.bridgewatersys.com ([10.52.81.148]) by m679t01.fpmis.bridgewatersys.com ([10.52.81.144]) with mapi; Mon, 12 Apr 2010 16:08:21 -0400 From: Mark Jones To: "lionel.morand@orange-ftgroup.com" , "vf0213@gmail.com" , "sdecugis@nict.go.jp" Date: Mon, 12 Apr 2010 16:08:19 -0400 Thread-Topic: [Dime] NAPTR fix for 3588bis Thread-Index: AcraO5brqmW8eFIpSu6LMDfWj08HgwAEDgQQAAvvMKA= Message-ID: References: <4BB43191.5000505@nict.go.jp><4BC288CB.9030002@nict.go.jp> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_B4B762B06D90774E9E8016C89B66AF87561323C0m679t05fpmisbri_" MIME-Version: 1.0 Cc: "dime@ietf.org" Subject: Re: [Dime] NAPTR fix for 3588bis X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Apr 2010 20:08:50 -0000 --_000_B4B762B06D90774E9E8016C89B66AF87561323C0m679t05fpmisbri_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Works for me. I assume we'd still keep "diameter.tls.tcp" as the tag format= so that "diameter.tls.sctp" can be used in the separate draft. Mark From: lionel.morand@orange-ftgroup.com [mailto:lionel.morand@orange-ftgroup= .com] Sent: April 12, 2010 11:59 AM To: vf0213@gmail.com; sdecugis@nict.go.jp Cc: Mark Jones; dime@ietf.org Subject: RE: [Dime] NAPTR fix for 3588bis Hi, Taking account that this topic came quite late in the revision process and = to not delay the publication of the RFC3588bis, we could maybe consider to = address TLS over SCTP in a separete draft in a latter phase if there is a W= G interest of the WG to support this option. Would it be acceptable? Regards, Lionel ________________________________ De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part de Vic= tor Fajardo Envoy=E9 : lundi 12 avril 2010 14:28 =C0 : Sebastien Decugis Cc : Mark Jones; dime@ietf.org Objet : Re: [Dime] NAPTR fix for 3588bis Hi Sebastien, On Sun, Apr 11, 2010 at 9:43 PM, Sebastien Decugis > wrote: Hi, Sorry for the delay, I was on vacation. Le 09/04/2010 07:02, Mark Jones a =E9crit : > 4) Application protocol tag for TLS does not differentiate TLS/TCP vs > TLS/SCTP (Sebastian). > > Conclusion: New TLS tags proposed to Sebastian. Still > open. > I am perfectly fine with the resolution you proposed, thank you! > 5) Missing ref to TLS/SCTP - RFC3436 (Sebastian). > > Conclusion: Add the missing reference to 3588bis. > Unrelated to this fix though. > I guess this resolution will require a bit more feedback from the group, there may be other ways to implement TLS over SCTP... Can the chairs give direction on this issue? For all practical purpose, is there really a strong deployable reason to su= pport TLS over SCTP ? I'm just hesitant to delay bis publication to support= an academic exercise. regards, victor Thanks! Sebastien. -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) --_000_B4B762B06D90774E9E8016C89B66AF87561323C0m679t05fpmisbri_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Works for me. I assume we’d still keep “diameter= .tls.tcp” as the tag format so that “diameter.tls.sctp” can be used in the separ= ate draft.

 

Mark

 

From: lionel.morand@orange-ftgroup.com [mailto:lionel.morand@orange-ftgroup.com] =
Sent: April 12, 2010 11:59 AM
To: vf0213@gmail.com; sdecugis@nict.go.jp
Cc: Mark Jones; dime@ietf.org
Subject: RE: [Dime] NAPTR fix for 3588bis

 

Hi,

 

Taking account that this topic came quite late in the revision process and to not delay the publication of the RFC3588bis, we could m= aybe consider to address TLS over SCTP in a separete draft in a latter phas= e if there is a WG interest of the WG to support this option.<= /p>

 

Would it be acceptable?

 

Regards,

 

Lionel

 

 

De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part de Victor Fajardo
Envoy=E9 : lundi 12 avril 2010 14:28
=C0 : Sebastien Decugis
Cc : Mark Jones; dime@ietf.org
Objet : Re: [Dime] NAPTR fix for 3588bis=

Hi Sebastien,

On Sun, Apr 11, 2010 at 9:43 PM, Sebastien Decugis <= ;sdecugis@nict.go.jp> wrote:=

Hi,

Sorry for the delay, I was on vacation.

Le 09/04/2010 07:02, Mark Jones a =E9crit :
> 4) Application protocol tag for TLS does not differentiate TLS/TCP vs<= br> > TLS/SCTP (Sebastian).
>
>                 Conclusion: Ne= w TLS tags proposed to Sebastian. Still
> open.
>

I am perfectly fine with the resolution you proposed, thank you!

> 5) Missing ref to TLS/SCTP - RFC3436 (Sebastian).
>
>                 Conclusion: Ad= d the missing reference to 3588bis.
> Unrelated to this fix though.
>
I guess this resolution will require a bit more feedback from the group, there may be other ways to implement TLS over SCTP... Can the chairs
give direction on this issue?



For all practical purpose, is there really a strong deployable reason to support TLS over SCTP ? I'm just hesitant to delay bis publication to suppo= rt an academic exercise.

regards,
victor
 

 


Thanks!
Sebastien.

--
Sebastien Decugis
Research fellow
Network Architecture Group
NICT (nict.go.jp)

 

--_000_B4B762B06D90774E9E8016C89B66AF87561323C0m679t05fpmisbri_-- From sdecugis@nict.go.jp Mon Apr 12 22:14:21 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D8973A68B5 for ; Mon, 12 Apr 2010 22:14:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.683 X-Spam-Level: X-Spam-Status: No, score=-0.683 tagged_above=-999 required=5 tests=[AWL=0.672, BAYES_00=-2.599, HELO_EQ_JP=1.244] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d5xKtijDjhxQ for ; Mon, 12 Apr 2010 22:14:19 -0700 (PDT) Received: from ns2.nict.go.jp (ns2.nict.go.jp [IPv6:2001:2f8:29::3]) by core3.amsl.com (Postfix) with ESMTP id A687E3A68A9 for ; Mon, 12 Apr 2010 22:14:18 -0700 (PDT) Received: from gw2.nict.go.jp (gw2 [133.243.18.251]) by ns2.nict.go.jp with ESMTP id o3D5E6f6010333; Tue, 13 Apr 2010 14:14:06 +0900 (JST) Received: from gw2.nict.go.jp (localhost [127.0.0.1]) by gw2.nict.go.jp with ESMTP id o3D5E6tC001243; Tue, 13 Apr 2010 14:14:06 +0900 (JST) Received: from mail3.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw2.nict.go.jp with ESMTP id o3D5E6n3001240; Tue, 13 Apr 2010 14:14:06 +0900 (JST) Received: from mail3.nict.go.jp (localhost [127.0.0.1]) by mail3.nict.go.jp (NICT Mail) with ESMTP id 6570516A18; Tue, 13 Apr 2010 14:14:06 +0900 (JST) Received: from [133.243.146.171] (5gou2f-dhcp11.nict.go.jp [133.243.146.171]) by mail3.nict.go.jp (NICT Mail) with ESMTP id 5F99C169FC; Tue, 13 Apr 2010 14:14:06 +0900 (JST) Message-ID: <4BC3FD95.70803@nict.go.jp> Date: Tue, 13 Apr 2010 14:13:57 +0900 From: Sebastien Decugis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Mark Jones References: <4BB43191.5000505@nict.go.jp><4BC288CB.9030002@nict.go.jp> In-Reply-To: X-Enigmail-Version: 1.0.1 OpenPGP: id=33D9F61D Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: "dime@ietf.org" Subject: Re: [Dime] NAPTR fix for 3588bis X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2010 05:14:21 -0000 Hi, I am fine with this approach as well. My initial intention was just to highlight that having TLS at the same level as TCP and SCTP is very confusing. The tag "diameter.tls.tcp" is perfectly fine for me. And it will be quite easy to figure what to do, should (TLS over) SCTP become more popular. Best regards, Sebastien. Le 13/04/2010 05:08, Mark Jones a écrit : > > Works for me. I assume we’d still keep “diameter.tls.tcp” as the tag > format so that “diameter.tls.sctp” can be used in the separate draft. > > Mark > > *From:* lionel.morand@orange-ftgroup.com > [mailto:lionel.morand@orange-ftgroup.com] > *Sent:* April 12, 2010 11:59 AM > *To:* vf0213@gmail.com; sdecugis@nict.go.jp > *Cc:* Mark Jones; dime@ietf.org > *Subject:* RE: [Dime] NAPTR fix for 3588bis > > Hi, > > Taking account that this topic came quite late in the revision process > and to not delay the publication of the RFC3588bis, we could maybe > consider to address TLS over SCTP in a separete draft in a latter > phase if there is a WG interest of the WG to support this option. > > Would it be acceptable? > > Regards, > > Lionel > > ------------------------------------------------------------------------ > > *De :* dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] *De la > part de* Victor Fajardo > *Envoyé :* lundi 12 avril 2010 14:28 > *À :* Sebastien Decugis > *Cc :* Mark Jones; dime@ietf.org > *Objet :* Re: [Dime] NAPTR fix for 3588bis > > Hi Sebastien, > > On Sun, Apr 11, 2010 at 9:43 PM, Sebastien Decugis > > wrote: > > Hi, > > Sorry for the delay, I was on vacation. > > Le 09/04/2010 07:02, Mark Jones a écrit : > > 4) Application protocol tag for TLS does not differentiate > TLS/TCP vs > > TLS/SCTP (Sebastian). > > > > Conclusion: New TLS tags proposed to Sebastian. Still > > open. > > > > I am perfectly fine with the resolution you proposed, thank you! > > > 5) Missing ref to TLS/SCTP - RFC3436 (Sebastian). > > > > Conclusion: Add the missing reference to 3588bis. > > Unrelated to this fix though. > > > I guess this resolution will require a bit more feedback from the > group, > there may be other ways to implement TLS over SCTP... Can the chairs > give direction on this issue? > > > > For all practical purpose, is there really a strong deployable > reason to support TLS over SCTP ? I'm just hesitant to delay bis > publication to support an academic exercise. > > regards, > victor > > > > Thanks! > Sebastien. > > -- > Sebastien Decugis > Research fellow > Network Architecture Group > NICT (nict.go.jp ) > -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) From lionel.morand@orange-ftgroup.com Tue Apr 13 07:47:57 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5DE928C1F4 for ; Tue, 13 Apr 2010 07:47:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.249 X-Spam-Level: X-Spam-Status: No, score=-1.249 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_83=0.6, J_CHICKENPOX_84=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3H-n29BR16l0 for ; Tue, 13 Apr 2010 07:47:56 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by core3.amsl.com (Postfix) with ESMTP id EEFB728C14D for ; Tue, 13 Apr 2010 07:47:55 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 8A86157D115; Tue, 13 Apr 2010 16:47:36 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id 326E857D123; Tue, 13 Apr 2010 16:47:36 +0200 (CEST) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 Apr 2010 16:46:11 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 13 Apr 2010 16:46:11 +0200 Message-ID: In-Reply-To: <4BC3FD95.70803@nict.go.jp> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] NAPTR fix for 3588bis thread-index: AcrayCt4nUEjXAMsSxCTQTMznBSxPAAP9DJQ References: <4BB43191.5000505@nict.go.jp><4BC288CB.9030002@nict.go.jp> <4BC3FD95.70803@nict.go.jp> From: To: , X-OriginalArrivalTime: 13 Apr 2010 14:46:11.0109 (UTC) FILETIME=[0F03DD50:01CADB18] Cc: dime@ietf.org Subject: Re: [Dime] NAPTR fix for 3588bis X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2010 14:47:57 -0000 Thx S=E9bastien. So to sum up, all the existing issues are now closed. Any other feedback from the WG on the proposed modification? Hereafter the modification proposed by Mark with corrections based on = the agreement reached after email discussion: ************************* FIRST CHANGE ************************* Section 5.2 Diameter Peer Discovery =3D> Replace step 2 with the following text: 2. The Diameter implementation performs a NAPTR query for a server in a particular realm. The Diameter implementation has to know in advance which realm to look for a Diameter agent in. This could be deduced, for example, from the 'realm' in a NAI that a Diameter implementation needed to perform a Diameter operation on. The NAPTR usage in Diameter follows the S-NAPTR DDDS application=20 [RFC3958] which means that the SERVICE field includes tags for = the=20 desired application and supported application protocol. The application service tag for a Diameter application is 'aaa' = and=20 the supported application protocol tags are 'diameter.tcp',=20 'diameter.sctp' or 'diameter.tls'.=20 The client follows the resolution process defined by the S-NAPTR=20 DDDS [RFC3958] application to find a matching SRV or A record of=20 a suitable peer. The domain suffixes in the NAPTR replacement = field SHOULD match the domain of the original query. ************************* SECOND CHANGE ************************* Section 11.6 NAPTR Service Fields =3D> Rename this section to S-NAPTR Parameters and replace content with: This document registers a S-NAPTR Application Service Tag value of = "aaa". This document also registers the following S-NAPTR Application Protocol = Tags: Tag | Protocol -------------------|--------- diameter.tcp | TCP diameter.sctp | SCTP diameter.tls.tcp | TLS/TCP ************************* THIRD CHANGE ************************** Appendix B. NAPTR Example =3D> Rename section to S-NAPTR Example and modify as follows. As an example, consider a client that wishes to resolve aaa: example.com. The client performs a NAPTR query for that domain, and the following NAPTR records are returned: ;; order pref flags service regexp replacement IN NAPTR 50 50 "s" "aaa:diameter.tls.tcp" "" = _diameter._tls.tcp.example.com IN NAPTR 100 50 "s" "aaa:diameter.tcp" "" = _diameter._tcp.example.com IN NAPTR 150 50 "s" "aaa:diameter.sctp" "" = _diameter._sctp.example.com This indicates that the server supports TLS/TCP, TCP and SCTP in that order. If the client supports TLS/TCP, TLS/TCP will be used, = targeted to a host determined by an SRV lookup of _diameter._tls.tcp.example.com. = That lookup would return: ;; Priority Weight Port Target IN SRV 0 1 5060 server1.example.com IN SRV 0 2 5060 server2.example.com =3D>addition of an example with "a" flag required such as: IN NAPTR 150 50 "a" "aaa:diameter.tls.tcp" "" = server1.example.com IN NAPTR 150 50 "a" "aaa:diameter.tls.tcp" "" = server2.example.com ************************* FOURTH CHANGE ************************** 14.1. Normative References =3D> Add new reference to S-NAPTR DDDS RFC3958. ************************* END OF CHANGES *********************** > -----Message d'origine----- > De : Sebastien Decugis [mailto:sdecugis@nict.go.jp]=20 > Envoy=E9 : mardi 13 avril 2010 07:14 > =C0 : Mark Jones > Cc : MORAND Lionel RD-CORE-ISS; vf0213@gmail.com; dime@ietf.org > Objet : Re: [Dime] NAPTR fix for 3588bis >=20 > Hi, >=20 > I am fine with this approach as well. My initial intention=20 > was just to highlight that having TLS at the same level as=20 > TCP and SCTP is very confusing. > The tag "diameter.tls.tcp" is perfectly fine for me. And it=20 > will be quite easy to figure what to do, should (TLS over)=20 > SCTP become more popular. >=20 > Best regards, > Sebastien. >=20 > Le 13/04/2010 05:08, Mark Jones a =E9crit : > > > > Works for me. I assume we'd still keep "diameter.tls.tcp"=20 > as the tag=20 > > format so that "diameter.tls.sctp" can be used in the=20 > separate draft. > > > > Mark > > > > *From:* lionel.morand@orange-ftgroup.com=20 > > [mailto:lionel.morand@orange-ftgroup.com] > > *Sent:* April 12, 2010 11:59 AM > > *To:* vf0213@gmail.com; sdecugis@nict.go.jp > > *Cc:* Mark Jones; dime@ietf.org > > *Subject:* RE: [Dime] NAPTR fix for 3588bis > > > > Hi, > > > > Taking account that this topic came quite late in the=20 > revision process=20 > > and to not delay the publication of the RFC3588bis, we could maybe=20 > > consider to address TLS over SCTP in a separete draft in a latter=20 > > phase if there is a WG interest of the WG to support this option. > > > > Would it be acceptable? > > > > Regards, > > > > Lionel > > > > =20 > >=20 > ---------------------------------------------------------------------- > > -- > > > > *De :* dime-bounces@ietf.org=20 > [mailto:dime-bounces@ietf.org] *De la > > part de* Victor Fajardo > > *Envoy=E9 :* lundi 12 avril 2010 14:28 > > *=C0 :* Sebastien Decugis > > *Cc :* Mark Jones; dime@ietf.org > > *Objet :* Re: [Dime] NAPTR fix for 3588bis > > > > Hi Sebastien, > > > > On Sun, Apr 11, 2010 at 9:43 PM, Sebastien Decugis > > > wrote: > > > > Hi, > > > > Sorry for the delay, I was on vacation. > > > > Le 09/04/2010 07:02, Mark Jones a =E9crit : > > > 4) Application protocol tag for TLS does not differentiate > > TLS/TCP vs > > > TLS/SCTP (Sebastian). > > > > > > Conclusion: New TLS tags proposed to Sebastian. Still > > > open. > > > > > > > I am perfectly fine with the resolution you proposed, thank you! > > > > > 5) Missing ref to TLS/SCTP - RFC3436 (Sebastian). > > > > > > Conclusion: Add the missing reference to 3588bis. > > > Unrelated to this fix though. > > > > > I guess this resolution will require a bit more=20 > feedback from the > > group, > > there may be other ways to implement TLS over SCTP...=20 > Can the chairs > > give direction on this issue? > > > > > > > > For all practical purpose, is there really a strong deployable > > reason to support TLS over SCTP ? I'm just hesitant to delay bis > > publication to support an academic exercise. > > > > regards, > > victor > > > > > > > > Thanks! > > Sebastien. > > > > -- > > Sebastien Decugis > > Research fellow > > Network Architecture Group > > NICT (nict.go.jp ) > > >=20 > -- > Sebastien Decugis > Research fellow > Network Architecture Group > NICT (nict.go.jp) >=20 >=20 From vf0213@gmail.com Tue Apr 13 10:50:54 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB5163A69BE for ; Tue, 13 Apr 2010 10:50:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.598 X-Spam-Level: X-Spam-Status: No, score=-1.598 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_83=0.6, J_CHICKENPOX_84=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gLApUSB+YEp8 for ; Tue, 13 Apr 2010 10:50:50 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id B74753A6407 for ; Tue, 13 Apr 2010 10:50:49 -0700 (PDT) Received: by wwb24 with SMTP id 24so706815wwb.31 for ; Tue, 13 Apr 2010 10:50:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=mTnpRyzZ62ZwMqVxxGGQe1SGAOGA87ahfL2o8uDO2Ig=; b=cpLacr4HXi+5JdKG5tAB6NpZAdndoBR7rAHg1ii0rZm5vQiMLA6y/OfrSTF83OtkwT WePGCCdnDRoEEp1So/b1XPYpQg6wdwDrOYRUoP9u3tE7pqwbWqLHtXwWx/1uBSjGF4dC qeJlioMxLLQBAMWk41XYU5PzOw4JJuSm+k0F0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=AhmnzKF5MFRHI36ub3u9yao7gQz4No4egxyUUmV5nM8RWwj7/elHrF2UREqZ8nD33B N8fVV5yImEpE2vegc7k/2yo1FLGUJCDlBXmpBljOwP55K+DaeHusZtZKWLvZaKJ5aaNA gtWHWIwTCwqhXkkrxM2jpZL5khgEj1HHPxBRc= MIME-Version: 1.0 Received: by 10.216.169.207 with HTTP; Tue, 13 Apr 2010 10:50:40 -0700 (PDT) In-Reply-To: References: <4BC288CB.9030002@nict.go.jp> <4BC3FD95.70803@nict.go.jp> Date: Tue, 13 Apr 2010 12:50:40 -0500 Received: by 10.216.180.202 with SMTP id j52mr3557913wem.214.1271181040504; Tue, 13 Apr 2010 10:50:40 -0700 (PDT) Message-ID: From: Victor Fajardo To: lionel.morand@orange-ftgroup.com Content-Type: multipart/alternative; boundary=0016e656b5985d5155048421e694 Cc: Mark.Jones@bridgewatersystems.com, dime@ietf.org Subject: Re: [Dime] NAPTR fix for 3588bis X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2010 17:50:55 -0000 --0016e656b5985d5155048421e694 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Looks good. I'll send out a bis version with the changes below. On Tue, Apr 13, 2010 at 9:46 AM, wrote: > Thx S=E9bastien. > > So to sum up, all the existing issues are now closed. > > Any other feedback from the WG on the proposed modification? > > Hereafter the modification proposed by Mark with corrections based on the > agreement reached after email discussion: > > ************************* FIRST CHANGE ************************* > > Section 5.2 Diameter Peer Discovery > > =3D> Replace step 2 with the following text: > > 2. The Diameter implementation performs a NAPTR query for a server > in a particular realm. The Diameter implementation has to know > in advance which realm to look for a Diameter agent in. This > could be deduced, for example, from the 'realm' in a NAI that a > Diameter implementation needed to perform a Diameter operation > on. > > The NAPTR usage in Diameter follows the S-NAPTR DDDS application > [RFC3958] which means that the SERVICE field includes tags for the > desired application and supported application protocol. > The application service tag for a Diameter application is 'aaa' and > the supported application protocol tags are 'diameter.tcp', > 'diameter.sctp' or 'diameter.tls'. > > The client follows the resolution process defined by the S-NAPTR > DDDS [RFC3958] application to find a matching SRV or A record of > a suitable peer. The domain suffixes in the NAPTR replacement fiel= d > SHOULD match the domain of the original query. > > > ************************* SECOND CHANGE ************************* > > Section 11.6 NAPTR Service Fields > > =3D> Rename this section to S-NAPTR Parameters and replace content with: > > This document registers a S-NAPTR Application Service Tag value of "aaa". > > This document also registers the following S-NAPTR Application Protocol > Tags: > > Tag | Protocol > -------------------|--------- > diameter.tcp | TCP > diameter.sctp | SCTP > diameter.tls.tcp | TLS/TCP > > ************************* THIRD CHANGE ************************** > > Appendix B. NAPTR Example > > =3D> Rename section to S-NAPTR Example and modify as follows. > > As an example, consider a client that wishes to resolve aaa: > example.com. The client performs a NAPTR query for that domain, and > the following NAPTR records are returned: > > ;; order pref flags service regexp replacement > IN NAPTR 50 50 "s" "aaa:diameter.tls.tcp" "" _diameter._ > tls.tcp.example.com > IN NAPTR 100 50 "s" "aaa:diameter.tcp" "" _diameter._ > tcp.example.com > IN NAPTR 150 50 "s" "aaa:diameter.sctp" "" _diameter._ > sctp.example.com > > This indicates that the server supports TLS/TCP, TCP and SCTP in that > order. If the client supports TLS/TCP, TLS/TCP will be used, targeted = to > a > host determined by an SRV lookup of _diameter._tls.tcp.example.com. > That > lookup would return: > > ;; Priority Weight Port Target > IN SRV 0 1 5060 server1.example.com > IN SRV 0 2 5060 server2.example.com > > =3D>addition of an example with "a" flag required such as: > > IN NAPTR 150 50 "a" "aaa:diameter.tls.tcp" "" > server1.example.com > IN NAPTR 150 50 "a" "aaa:diameter.tls.tcp" "" > server2.example.com > > ************************* FOURTH CHANGE ************************** > > 14.1. Normative References > > =3D> Add new reference to S-NAPTR DDDS RFC3958. > > ************************* END OF CHANGES *********************** > > > > > > > -----Message d'origine----- > > De : Sebastien Decugis [mailto:sdecugis@nict.go.jp] > > Envoy=E9 : mardi 13 avril 2010 07:14 > > =C0 : Mark Jones > > Cc : MORAND Lionel RD-CORE-ISS; vf0213@gmail.com; dime@ietf.org > > Objet : Re: [Dime] NAPTR fix for 3588bis > > > > Hi, > > > > I am fine with this approach as well. My initial intention > > was just to highlight that having TLS at the same level as > > TCP and SCTP is very confusing. > > The tag "diameter.tls.tcp" is perfectly fine for me. And it > > will be quite easy to figure what to do, should (TLS over) > > SCTP become more popular. > > > > Best regards, > > Sebastien. > > > > Le 13/04/2010 05:08, Mark Jones a =E9crit : > > > > > > Works for me. I assume we'd still keep "diameter.tls.tcp" > > as the tag > > > format so that "diameter.tls.sctp" can be used in the > > separate draft. > > > > > > Mark > > > > > > *From:* lionel.morand@orange-ftgroup.com > > > [mailto:lionel.morand@orange-ftgroup.com] > > > *Sent:* April 12, 2010 11:59 AM > > > *To:* vf0213@gmail.com; sdecugis@nict.go.jp > > > *Cc:* Mark Jones; dime@ietf.org > > > *Subject:* RE: [Dime] NAPTR fix for 3588bis > > > > > > Hi, > > > > > > Taking account that this topic came quite late in the > > revision process > > > and to not delay the publication of the RFC3588bis, we could maybe > > > consider to address TLS over SCTP in a separete draft in a latter > > > phase if there is a WG interest of the WG to support this option. > > > > > > Would it be acceptable? > > > > > > Regards, > > > > > > Lionel > > > > > > > > > > > ---------------------------------------------------------------------- > > > -- > > > > > > *De :* dime-bounces@ietf.org > > [mailto:dime-bounces@ietf.org] *De la > > > part de* Victor Fajardo > > > *Envoy=E9 :* lundi 12 avril 2010 14:28 > > > *=C0 :* Sebastien Decugis > > > *Cc :* Mark Jones; dime@ietf.org > > > *Objet :* Re: [Dime] NAPTR fix for 3588bis > > > > > > Hi Sebastien, > > > > > > On Sun, Apr 11, 2010 at 9:43 PM, Sebastien Decugis > > > > wrote: > > > > > > Hi, > > > > > > Sorry for the delay, I was on vacation. > > > > > > Le 09/04/2010 07:02, Mark Jones a =E9crit : > > > > 4) Application protocol tag for TLS does not differentiate > > > TLS/TCP vs > > > > TLS/SCTP (Sebastian). > > > > > > > > Conclusion: New TLS tags proposed to Sebastian. Still > > > > open. > > > > > > > > > > I am perfectly fine with the resolution you proposed, thank you! > > > > > > > 5) Missing ref to TLS/SCTP - RFC3436 (Sebastian). > > > > > > > > Conclusion: Add the missing reference to 3588bis. > > > > Unrelated to this fix though. > > > > > > > I guess this resolution will require a bit more > > feedback from the > > > group, > > > there may be other ways to implement TLS over SCTP... > > Can the chairs > > > give direction on this issue? > > > > > > > > > > > > For all practical purpose, is there really a strong deployable > > > reason to support TLS over SCTP ? I'm just hesitant to delay bis > > > publication to support an academic exercise. > > > > > > regards, > > > victor > > > > > > > > > > > > Thanks! > > > Sebastien. > > > > > > -- > > > Sebastien Decugis > > > Research fellow > > > Network Architecture Group > > > NICT (nict.go.jp ) > > > > > > > -- > > Sebastien Decugis > > Research fellow > > Network Architecture Group > > NICT (nict.go.jp) > > > > > --0016e656b5985d5155048421e694 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Looks good. I'll send out a bis version with the changes below.

=
On Tue, Apr 13, 2010 at 9:46 AM, <lionel.mor= and@orange-ftgroup.com> wrote:
Thx S=E9bastien.<= br>
So to sum up, all the existing issues are now closed.

Any other feedback from the WG on the proposed modification?

Hereafter the modification proposed by Mark with corrections based on the a= greement reached after email discussion:

************************* FIRST CHANGE *************************

Section 5.2 Diameter Peer Discovery

=3D> Replace step 2 with the following text:

=A0 2. =A0The Diameter implementation performs a NAPTR query for a server<= br> =A0 =A0 =A0 in a particular realm. =A0The Diameter implementation has to k= now
=A0 =A0 =A0 in advance which realm to look for a Diameter agent in. =A0Thi= s
=A0 =A0 =A0 could be deduced, for example, from the 'realm' in a N= AI that a
=A0 =A0 =A0 Diameter implementation needed to perform a Diameter operation=
=A0 =A0 =A0 on.

=A0 =A0 =A0 The NAPTR usage in Diameter follows the S-NAPTR DDDS applicati= on
=A0 =A0 =A0 [RFC3958] which means that the SERVICE field includes tags for= the
=A0 =A0 =A0 desired application and supported application protocol.
=A0 =A0 =A0 The application service tag for a Diameter application is '= ;aaa' and
=A0 =A0 =A0 the supported =A0application protocol tags are 'diameter.t= cp',
=A0 =A0 =A0 'diameter.sctp' or 'diameter.tls'.

=A0 =A0 =A0 The client follows the resolution process defined by the S-NAP= TR
=A0 =A0 =A0 DDDS [RFC3958] application to find a matching SRV or A record = of
=A0 =A0 =A0 a suitable peer. =A0The domain suffixes in the NAPTR replaceme= nt field
=A0 =A0 =A0 SHOULD match the domain of the original query.


************************* SECOND CHANGE *************************

Section 11.6 NAPTR Service Fields

=3D> Rename this section to S-NAPTR Parameters and replace content with:=

This document registers a S-NAPTR Application Service Tag value of "aa= a".

This document also registers the following S-NAPTR Application Protocol Tag= s:

=A0 Tag =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Protocol
=A0 -------------------|---------
=A0 diameter.tcp =A0 =A0 =A0 | TCP
=A0 diameter.sctp =A0 =A0 =A0| SCTP
=A0 diameter.tls.tcp =A0 | TLS/TCP

************************* THIRD CHANGE **************************

Appendix B. =A0NAPTR Example

=3D> Rename section to S-NAPTR Example and modify as follows.

=A0 As an example, consider a client that wishes to resolve aaa:
=A0 example.com. =A0T= he client performs a NAPTR query for that domain, and
=A0 the following NAPTR records are returned:

=A0;; =A0 =A0 =A0 =A0order pref flags service =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0regexp replacement
=A0IN NAPTR =A050 =A0 =A050 =A0 "s" =A0 "aaa:diameter.tls.tc= p" =A0"" =A0 =A0 _diameter._tls.tcp.example.com
=A0IN NAPTR =A0100 =A0 50 =A0 "s" =A0 "aaa:diameter.tcp"= ; =A0 =A0 =A0"" =A0 =A0 _diameter._tcp.example.com
=A0IN NAPTR =A0150 =A0 50 =A0 "s" =A0 "aaa:diameter.sctp&quo= t; =A0 =A0 "" =A0 =A0 _diameter._sctp.example.com

=A0 This indicates that the server supports TLS/TCP, TCP and SCTP in that<= br> =A0 order. =A0If the client supports TLS/TCP, TLS/TCP will be used, target= ed to a
=A0 host determined by an SRV lookup of _diameter._tls.tcp.example.com. =A0That
=A0 lookup would return:

=A0 =A0;; =A0 =A0 =A0 Priority =A0Weight =A0Port =A0 =A0Target
=A0 =A0IN SRV =A0 0 =A0 =A0 =A0 =A0 1 =A0 =A0 =A0 5060 =A0 =A0server1.example.com
=A0 =A0IN SRV =A0 0 =A0 =A0 =A0 =A0 2 =A0 =A0 =A0 5060 =A0 =A0server2.example.com

=3D>addition of an example with "a" flag required such as:

=A0IN NAPTR =A0150 =A0 50 =A0 "a" =A0 "aaa:diameter.tls.tcp&= quot; =A0"" =A0 =A0 server1.example.com
=A0IN NAPTR =A0150 =A0 50 =A0 "a" =A0 "aaa:diameter.tls.tcp&= quot; =A0"" =A0 =A0 server2.example.com

************************* FOURTH CHANGE **************************

14.1. =A0Normative References

=3D> Add new reference to S-NAPTR DDDS RFC3958.

************************* END OF CHANGES ***********************





> -----Message d'origine-----
> De : Sebastien Decugis [mailto:= sdecugis@nict.go.jp]
> Envoy=E9 : mardi 13 avril 2010 07:14
> =C0 : Mark Jones
> Cc : MORAND Lionel RD-CORE-ISS; vf= 0213@gmail.com; dime@ietf.org
> Objet : Re: [Dime] NAPTR fix for 358= 8bis
>
> Hi,
>
> I am fine with this approach as well. My initial intention
> was just to highlight that having TLS at the same level as
> TCP and SCTP is very confusing.
> The tag "diameter.tls.tcp" is perfectly fine for me. And it<= br> > will be quite easy to figure what to do, should (TLS over)
> SCTP become more popular.
>
> Best regards,
> Sebastien.
>
> Le 13/04/2010 05:08, Mark Jones a =E9crit :
> >
> > Works for me. I assume we'd still keep "diameter.tls.tcp= "
> as the tag
> > format so that "diameter.tls.sctp" can be used in the > separate draft.
> >
> > Mark
> >
> > *From:* lione= l.morand@orange-ftgroup.com
> > [mailto:lione= l.morand@orange-ftgroup.com]
> > *Sent:* April 12, 2010 11:59 AM
> > *To:* vf0213@gmail.com; <= a href=3D"mailto:sdecugis@nict.go.jp">sdecugis@nict.go.jp
> > *Cc:* Mark Jones; dime@ietf.org<= /a>
> > *Subject:* RE: [Dime] NAPTR fix for 3588bis
> >
> > Hi,
> >
> > Taking account that this topic came quite late in the
> revision process
> > and to not delay the publication of the RFC3588bis, we could mayb= e
> > consider to address TLS over SCTP in a separete draft in a latter=
> > phase if there is a WG interest of the WG to support this option.=
> >
> > Would it be acceptable?
> >
> > Regards,
> >
> > Lionel
> >
> >
> >
> ----------------------------------------------------------------------=
> > --
> >
> > =A0 =A0 *De :* dime-boun= ces@ietf.org
> [mailto:dime-bounces@ietf.org= ] *De la
> > =A0 =A0 part de* Victor Fajardo
> > =A0 =A0 *Envoy=E9 :* lundi 12 avril 2010 14:28
> > =A0 =A0 *=C0 :* Sebastien Decugis
> > =A0 =A0 *Cc :* Mark Jones; dime@= ietf.org
> > =A0 =A0 *Objet :* Re: [Dime] NAPTR fix for 3588bis
> >
> > =A0 =A0 Hi Sebastien,
> >
> > =A0 =A0 On Sun, Apr 11, 2010 at 9:43 PM, Sebastien Decugis
> > =A0 =A0 <sdecugis@nict.= go.jp <mailto:sdecugis@nict.g= o.jp>> wrote:
> >
> > =A0 =A0 Hi,
> >
> > =A0 =A0 Sorry for the delay, I was on vacation.
> >
> > =A0 =A0 Le 09/04/2010 07:02, Mark Jones a =E9crit :
> > =A0 =A0 > 4) Application protocol tag for TLS does not differe= ntiate
> > =A0 =A0 TLS/TCP vs
> > =A0 =A0 > TLS/SCTP (Sebastian).
> > =A0 =A0 >
> > =A0 =A0 > Conclusion: New TLS tags proposed to Sebastian. Stil= l
> > =A0 =A0 > open.
> > =A0 =A0 >
> >
> > =A0 =A0 I am perfectly fine with the resolution you proposed, tha= nk you!
> >
> > =A0 =A0 > 5) Missing ref to TLS/SCTP - RFC3436 (Sebastian). > > =A0 =A0 >
> > =A0 =A0 > Conclusion: Add the missing reference to 3588bis. > > =A0 =A0 > Unrelated to this fix though.
> > =A0 =A0 >
> > =A0 =A0 I guess this resolution will require a bit more
> feedback from the
> > =A0 =A0 group,
> > =A0 =A0 there may be other ways to implement TLS over SCTP...
> Can the chairs
> > =A0 =A0 give direction on this issue?
> >
> >
> >
> > =A0 =A0 For all practical purpose, is there really a strong deplo= yable
> > =A0 =A0 reason to support TLS over SCTP ? I'm just hesitant t= o delay bis
> > =A0 =A0 publication to support an academic exercise.
> >
> > =A0 =A0 regards,
> > =A0 =A0 victor
> >
> >
> >
> > =A0 =A0 =A0 =A0 Thanks!
> > =A0 =A0 =A0 =A0 Sebastien.
> >
> > =A0 =A0 =A0 =A0 --
> > =A0 =A0 =A0 =A0 Sebastien Decugis
> > =A0 =A0 =A0 =A0 Research fellow
> > =A0 =A0 =A0 =A0 Network Architecture Group
> > =A0 =A0 =A0 =A0 NICT (nict.go.jp <htt= p://nict.go.jp>)
> >
>
> --
> Sebastien Decugis
> Research fellow
> Network Architecture Group
> NICT (nict.go.jp)<= br> >
>

--0016e656b5985d5155048421e694-- From sunseawq@huawei.com Tue Apr 13 19:47:26 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBF5F3A6B8D for ; Tue, 13 Apr 2010 19:47:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.324 X-Spam-Level: * X-Spam-Status: No, score=1.324 tagged_above=-999 required=5 tests=[AWL=-2.619, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, J_CHICKENPOX_83=0.6, J_CHICKENPOX_84=0.6, MIME_BASE64_TEXT=1.753, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xPmcQvBG1kUj for ; Tue, 13 Apr 2010 19:47:24 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 601F73A6B8C for ; Tue, 13 Apr 2010 19:47:24 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L0U009G1IEKI3@szxga03-in.huawei.com> for dime@ietf.org; Wed, 14 Apr 2010 10:47:08 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L0U00D3BIEJ50@szxga03-in.huawei.com> for dime@ietf.org; Wed, 14 Apr 2010 10:47:07 +0800 (CST) Received: from w53375 ([10.138.84.35]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L0U00A4FIEICT@szxml04-in.huawei.com> for dime@ietf.org; Wed, 14 Apr 2010 10:47:07 +0800 (CST) Date: Wed, 14 Apr 2010 10:47:06 +0800 From: Qin Wu To: Victor Fajardo , lionel.morand@orange-ftgroup.com Message-id: <00f101cadb7c$c59a4590$23548a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3598 Content-type: multipart/alternative; boundary="Boundary_(ID_8mQ+dKX8SjdZhbof8QR06w)" X-Priority: 3 X-MSMail-priority: Normal References: <4BC288CB.9030002@nict.go.jp> <4BC3FD95.70803@nict.go.jp> Cc: Mark.Jones@bridgewatersystems.com, dime@ietf.org Subject: Re: [Dime] NAPTR fix for 3588bis X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Apr 2010 02:47:26 -0000 This is a multi-part message in MIME format. --Boundary_(ID_8mQ+dKX8SjdZhbof8QR06w) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: base64 SGksDQpTb3JyeSBmb3IgbXkgbGF0ZSByZXBseS4gDQpHbyB0aHJvdWdoIHRoZSBwcm9wb3NlZCBD aGFuZ2VzIHRvIHRoZSBiaXMgdmVyc2lvbi4gDQpJIGZvdW5kICAiZGlhbWV0ZXIudGxzIiBhcyB0 aGUgc3VwcG9ydGVkIGFwcGxpY2F0aW9uIHByb3RvY29sIGluIHRoZSAqRklSU1QgQ0hBTkdFKiBp cyBzdGlsbCB1c2VkIHRoZXJlIA0Kd2hpY2ggaXMgbm90IGNvbnNpc3RlbnQgd2l0aCAiZGlhbWV0 ZXIudGxzLnRjcCIgc3BlY2lmaWVkIGluIHRoZSAqU0VDT05EIENIQU5HRSouDQoNCkFsc28gc29t ZSBxdWVzdGlvbnMgdG8gdGhlIGNoYW5nZXM6DQoxLiBJZiB0aGUgRGlhbWV0ZXIgc2VydmVyIGlu ZGljYXRlcyB0byB0aGUgRGlhbWV0ZXIgY2xpZW50IHRoYXQgaXQgc3VwcG9ydCBib3RoIFRDUCBh bmQgVExTL1RDUA0KICBhbmQgdGhlIERpYW1ldGVyIGNsaWVudCBhbHNvIHN1cHBvcnQgYm90aCwg d2hldGhlciB0aGUgRGlhbWV0ZXIgY2xpZW50IGNhbiBzdGlsbCBjaG9vc2UgVENQIGFzIHRyYW5z cG9ydA0KICBwcm90Y29sPyBJbiBvdGhlciB3b3JkcywgaW4gd2hpY2ggY29uZGl0aW9uIGRvZXMg dGhlIGNsaWVudCBjaG9vc2UgVENQIGFuZCBpbiB3aGljaCBjb25kaXRpb24gZG9lcyB0aGUgY2xp ZW50IGNob29zZSBUTFMvVENQPw0Kb3IgQ2FuIHdlIHNheSBUTFMvVENQIHRyYW5zcG9ydCBpcyBt b3JlIHJlbGlhYmxlIGFuZCBzZWN1cmUgdGhhbiBUQ1AgdHJhbnNwb3J0IGZvciBEaWFtZXRlcj8g VGhhdCdzIHdoeSB3ZSBjaG9vc2UgVExTIG92ZXIgVENQIGluc3RlYWQgb2YgVENQPw0KMi4gSSBh bSB3b25kZXJpbmcgV2hldGhlciBUTFMvVENQIHRyYW5zcG9ydCBjYW4gd29yayBpbiB0aGUgcm9h bWluZyBzY2VuYXJpbz8gSW4gb3JkZXIgd29yZHMsIHdoZXRoZXIgd2UgY2FuIA0KYWxsb3cgc2V2 ZXJhbCBEaWFtZXRlciBwZWVycyBsb2NhdGVkIGJldHdlZW4gRGlhbWV0ZXIgQ2xpZW50IGFuZCBE aWFtZXRlciBTZXJ2ZXI/IHdoZXRoZXIgVExTL1RDUCBjYW4gd29yayBhY3Jvc3MgcmVhbG1zPw0K My5XaGVuIHRoZSBEaWFtZXRlciBDbGllbnQgY2hvb3NlIFRMUy9UQ1AgYXMgdHJhbnNwb3J0LCB3 aGF0IHRyYW5zcG9ydCBwb3J0IHdpbGwgYmUgdXNlZCA/IFNhbWUgYXMgcG9ydCBmb3IgVENQIG9y IFNDVFAgb3Igbm90ID8gaWYgbm90LHdoYXQgaXMgaXQ/DQpIb3BlIHNvbWVib2R5IGNhbiBjbGFy aWZ5LiBUaGFua3MhDQoNClJlZ2FyZHMhDQotUWluDQogIC0tLS0tIE9yaWdpbmFsIE1lc3NhZ2Ug LS0tLS0gDQogIEZyb206IFZpY3RvciBGYWphcmRvIA0KICBUbzogbGlvbmVsLm1vcmFuZEBvcmFu Z2UtZnRncm91cC5jb20gDQogIENjOiBNYXJrLkpvbmVzQGJyaWRnZXdhdGVyc3lzdGVtcy5jb20g OyBkaW1lQGlldGYub3JnIA0KICBTZW50OiBXZWRuZXNkYXksIEFwcmlsIDE0LCAyMDEwIDE6NTAg QU0NCiAgU3ViamVjdDogUmU6IFtEaW1lXSBOQVBUUiBmaXggZm9yIDM1ODhiaXMNCg0KDQogIExv b2tzIGdvb2QuIEknbGwgc2VuZCBvdXQgYSBiaXMgdmVyc2lvbiB3aXRoIHRoZSBjaGFuZ2VzIGJl bG93Lg0KDQoNCg0KICBPbiBUdWUsIEFwciAxMywgMjAxMCBhdCA5OjQ2IEFNLCA8bGlvbmVsLm1v cmFuZEBvcmFuZ2UtZnRncm91cC5jb20+IHdyb3RlOg0KDQogICAgVGh4IFPpYmFzdGllbi4NCg0K ICAgIFNvIHRvIHN1bSB1cCwgYWxsIHRoZSBleGlzdGluZyBpc3N1ZXMgYXJlIG5vdyBjbG9zZWQu DQoNCiAgICBBbnkgb3RoZXIgZmVlZGJhY2sgZnJvbSB0aGUgV0cgb24gdGhlIHByb3Bvc2VkIG1v ZGlmaWNhdGlvbj8NCg0KICAgIEhlcmVhZnRlciB0aGUgbW9kaWZpY2F0aW9uIHByb3Bvc2VkIGJ5 IE1hcmsgd2l0aCBjb3JyZWN0aW9ucyBiYXNlZCBvbiB0aGUgYWdyZWVtZW50IHJlYWNoZWQgYWZ0 ZXIgZW1haWwgZGlzY3Vzc2lvbjoNCg0KICAgICoqKioqKioqKioqKioqKioqKioqKioqKiogRklS U1QgQ0hBTkdFICoqKioqKioqKioqKioqKioqKioqKioqKioNCg0KICAgIFNlY3Rpb24gNS4yIERp YW1ldGVyIFBlZXIgRGlzY292ZXJ5DQoNCiAgICA9PiBSZXBsYWNlIHN0ZXAgMiB3aXRoIHRoZSBm b2xsb3dpbmcgdGV4dDoNCg0KICAgICAgMi4gIFRoZSBEaWFtZXRlciBpbXBsZW1lbnRhdGlvbiBw ZXJmb3JtcyBhIE5BUFRSIHF1ZXJ5IGZvciBhIHNlcnZlcg0KICAgICAgICAgIGluIGEgcGFydGlj dWxhciByZWFsbS4gIFRoZSBEaWFtZXRlciBpbXBsZW1lbnRhdGlvbiBoYXMgdG8ga25vdw0KICAg ICAgICAgIGluIGFkdmFuY2Ugd2hpY2ggcmVhbG0gdG8gbG9vayBmb3IgYSBEaWFtZXRlciBhZ2Vu dCBpbi4gIFRoaXMNCiAgICAgICAgICBjb3VsZCBiZSBkZWR1Y2VkLCBmb3IgZXhhbXBsZSwgZnJv bSB0aGUgJ3JlYWxtJyBpbiBhIE5BSSB0aGF0IGENCiAgICAgICAgICBEaWFtZXRlciBpbXBsZW1l bnRhdGlvbiBuZWVkZWQgdG8gcGVyZm9ybSBhIERpYW1ldGVyIG9wZXJhdGlvbg0KICAgICAgICAg IG9uLg0KDQogICAgICAgICAgVGhlIE5BUFRSIHVzYWdlIGluIERpYW1ldGVyIGZvbGxvd3MgdGhl IFMtTkFQVFIgREREUyBhcHBsaWNhdGlvbg0KICAgICAgICAgIFtSRkMzOTU4XSB3aGljaCBtZWFu cyB0aGF0IHRoZSBTRVJWSUNFIGZpZWxkIGluY2x1ZGVzIHRhZ3MgZm9yIHRoZQ0KICAgICAgICAg IGRlc2lyZWQgYXBwbGljYXRpb24gYW5kIHN1cHBvcnRlZCBhcHBsaWNhdGlvbiBwcm90b2NvbC4N CiAgICAgICAgICBUaGUgYXBwbGljYXRpb24gc2VydmljZSB0YWcgZm9yIGEgRGlhbWV0ZXIgYXBw bGljYXRpb24gaXMgJ2FhYScgYW5kDQogICAgICAgICAgdGhlIHN1cHBvcnRlZCAgYXBwbGljYXRp b24gcHJvdG9jb2wgdGFncyBhcmUgJ2RpYW1ldGVyLnRjcCcsDQogICAgICAgICAgJ2RpYW1ldGVy LnNjdHAnIG9yICdkaWFtZXRlci50bHMnLg0KDQogICAgICAgICAgVGhlIGNsaWVudCBmb2xsb3dz IHRoZSByZXNvbHV0aW9uIHByb2Nlc3MgZGVmaW5lZCBieSB0aGUgUy1OQVBUUg0KICAgICAgICAg IERERFMgW1JGQzM5NThdIGFwcGxpY2F0aW9uIHRvIGZpbmQgYSBtYXRjaGluZyBTUlYgb3IgQSBy ZWNvcmQgb2YNCiAgICAgICAgICBhIHN1aXRhYmxlIHBlZXIuICBUaGUgZG9tYWluIHN1ZmZpeGVz IGluIHRoZSBOQVBUUiByZXBsYWNlbWVudCBmaWVsZA0KICAgICAgICAgIFNIT1VMRCBtYXRjaCB0 aGUgZG9tYWluIG9mIHRoZSBvcmlnaW5hbCBxdWVyeS4NCg0KDQogICAgKioqKioqKioqKioqKioq KioqKioqKioqKiBTRUNPTkQgQ0hBTkdFICoqKioqKioqKioqKioqKioqKioqKioqKioNCg0KICAg IFNlY3Rpb24gMTEuNiBOQVBUUiBTZXJ2aWNlIEZpZWxkcw0KDQogICAgPT4gUmVuYW1lIHRoaXMg c2VjdGlvbiB0byBTLU5BUFRSIFBhcmFtZXRlcnMgYW5kIHJlcGxhY2UgY29udGVudCB3aXRoOg0K DQogICAgVGhpcyBkb2N1bWVudCByZWdpc3RlcnMgYSBTLU5BUFRSIEFwcGxpY2F0aW9uIFNlcnZp Y2UgVGFnIHZhbHVlIG9mICJhYWEiLg0KDQogICAgVGhpcyBkb2N1bWVudCBhbHNvIHJlZ2lzdGVy cyB0aGUgZm9sbG93aW5nIFMtTkFQVFIgQXBwbGljYXRpb24gUHJvdG9jb2wgVGFnczoNCg0KDQog ICAgICBUYWcgICAgICAgICAgICAgICAgfCBQcm90b2NvbA0KICAgICAgLS0tLS0tLS0tLS0tLS0t LS0tLXwtLS0tLS0tLS0NCiAgICAgIGRpYW1ldGVyLnRjcCAgICAgICB8IFRDUA0KICAgICAgZGlh bWV0ZXIuc2N0cCAgICAgIHwgU0NUUA0KICAgICAgZGlhbWV0ZXIudGxzLnRjcCAgIHwgVExTL1RD UA0KDQoNCiAgICAqKioqKioqKioqKioqKioqKioqKioqKioqIFRISVJEIENIQU5HRSAqKioqKioq KioqKioqKioqKioqKioqKioqKg0KDQogICAgQXBwZW5kaXggQi4gIE5BUFRSIEV4YW1wbGUNCg0K ICAgID0+IFJlbmFtZSBzZWN0aW9uIHRvIFMtTkFQVFIgRXhhbXBsZSBhbmQgbW9kaWZ5IGFzIGZv bGxvd3MuDQoNCiAgICAgIEFzIGFuIGV4YW1wbGUsIGNvbnNpZGVyIGEgY2xpZW50IHRoYXQgd2lz aGVzIHRvIHJlc29sdmUgYWFhOg0KICAgICAgZXhhbXBsZS5jb20uICBUaGUgY2xpZW50IHBlcmZv cm1zIGEgTkFQVFIgcXVlcnkgZm9yIHRoYXQgZG9tYWluLCBhbmQNCiAgICAgIHRoZSBmb2xsb3dp bmcgTkFQVFIgcmVjb3JkcyBhcmUgcmV0dXJuZWQ6DQoNCiAgICAgOzsgICAgICAgIG9yZGVyIHBy ZWYgZmxhZ3Mgc2VydmljZSAgICAgICAgICAgICAgICByZWdleHAgcmVwbGFjZW1lbnQNCiAgICAg SU4gTkFQVFIgIDUwICAgIDUwICAgInMiICAgImFhYTpkaWFtZXRlci50bHMudGNwIiAgIiIgICAg IF9kaWFtZXRlci5fdGxzLnRjcC5leGFtcGxlLmNvbQ0KICAgICBJTiBOQVBUUiAgMTAwICAgNTAg ICAicyIgICAiYWFhOmRpYW1ldGVyLnRjcCIgICAgICAiIiAgICAgX2RpYW1ldGVyLl90Y3AuZXhh bXBsZS5jb20NCiAgICAgSU4gTkFQVFIgIDE1MCAgIDUwICAgInMiICAgImFhYTpkaWFtZXRlci5z Y3RwIiAgICAgIiIgICAgIF9kaWFtZXRlci5fc2N0cC5leGFtcGxlLmNvbQ0KDQogICAgICBUaGlz IGluZGljYXRlcyB0aGF0IHRoZSBzZXJ2ZXIgc3VwcG9ydHMgVExTL1RDUCwgVENQIGFuZCBTQ1RQ IGluIHRoYXQNCiAgICAgIG9yZGVyLiAgSWYgdGhlIGNsaWVudCBzdXBwb3J0cyBUTFMvVENQLCBU TFMvVENQIHdpbGwgYmUgdXNlZCwgdGFyZ2V0ZWQgdG8gYQ0KICAgICAgaG9zdCBkZXRlcm1pbmVk IGJ5IGFuIFNSViBsb29rdXAgb2YgX2RpYW1ldGVyLl90bHMudGNwLmV4YW1wbGUuY29tLiAgVGhh dA0KICAgICAgbG9va3VwIHdvdWxkIHJldHVybjoNCg0KICAgICAgIDs7ICAgICAgIFByaW9yaXR5 ICBXZWlnaHQgIFBvcnQgICAgVGFyZ2V0DQogICAgICAgSU4gU1JWICAgMCAgICAgICAgIDEgICAg ICAgNTA2MCAgICBzZXJ2ZXIxLmV4YW1wbGUuY29tDQogICAgICAgSU4gU1JWICAgMCAgICAgICAg IDIgICAgICAgNTA2MCAgICBzZXJ2ZXIyLmV4YW1wbGUuY29tDQoNCiAgICA9PmFkZGl0aW9uIG9m IGFuIGV4YW1wbGUgd2l0aCAiYSIgZmxhZyByZXF1aXJlZCBzdWNoIGFzOg0KDQogICAgIElOIE5B UFRSICAxNTAgICA1MCAgICJhIiAgICJhYWE6ZGlhbWV0ZXIudGxzLnRjcCIgICIiICAgICBzZXJ2 ZXIxLmV4YW1wbGUuY29tDQogICAgIElOIE5BUFRSICAxNTAgICA1MCAgICJhIiAgICJhYWE6ZGlh bWV0ZXIudGxzLnRjcCIgICIiICAgICBzZXJ2ZXIyLmV4YW1wbGUuY29tDQoNCiAgICAqKioqKioq KioqKioqKioqKioqKioqKioqIEZPVVJUSCBDSEFOR0UgKioqKioqKioqKioqKioqKioqKioqKioq KioNCg0KICAgIDE0LjEuICBOb3JtYXRpdmUgUmVmZXJlbmNlcw0KDQogICAgPT4gQWRkIG5ldyBy ZWZlcmVuY2UgdG8gUy1OQVBUUiBERERTIFJGQzM5NTguDQoNCiAgICAqKioqKioqKioqKioqKioq KioqKioqKioqIEVORCBPRiBDSEFOR0VTICoqKioqKioqKioqKioqKioqKioqKioqDQoNCg0KDQoN Cg0KICAgID4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQogICAgPiBEZSA6IFNlYmFzdGll biBEZWN1Z2lzIFttYWlsdG86c2RlY3VnaXNAbmljdC5nby5qcF0NCiAgICA+IEVudm956SA6IG1h cmRpIDEzIGF2cmlsIDIwMTAgMDc6MTQNCiAgICA+IMAgOiBNYXJrIEpvbmVzDQogICAgPiBDYyA6 IE1PUkFORCBMaW9uZWwgUkQtQ09SRS1JU1M7IHZmMDIxM0BnbWFpbC5jb207IGRpbWVAaWV0Zi5v cmcNCg0KICAgID4gT2JqZXQgOiBSZTogW0RpbWVdIE5BUFRSIGZpeCBmb3IgMzU4OGJpcw0KICAg ID4NCiAgICA+IEhpLA0KICAgID4NCiAgICA+IEkgYW0gZmluZSB3aXRoIHRoaXMgYXBwcm9hY2gg YXMgd2VsbC4gTXkgaW5pdGlhbCBpbnRlbnRpb24NCiAgICA+IHdhcyBqdXN0IHRvIGhpZ2hsaWdo dCB0aGF0IGhhdmluZyBUTFMgYXQgdGhlIHNhbWUgbGV2ZWwgYXMNCiAgICA+IFRDUCBhbmQgU0NU UCBpcyB2ZXJ5IGNvbmZ1c2luZy4NCiAgICA+IFRoZSB0YWcgImRpYW1ldGVyLnRscy50Y3AiIGlz IHBlcmZlY3RseSBmaW5lIGZvciBtZS4gQW5kIGl0DQogICAgPiB3aWxsIGJlIHF1aXRlIGVhc3kg dG8gZmlndXJlIHdoYXQgdG8gZG8sIHNob3VsZCAoVExTIG92ZXIpDQogICAgPiBTQ1RQIGJlY29t ZSBtb3JlIHBvcHVsYXIuDQogICAgPg0KICAgID4gQmVzdCByZWdhcmRzLA0KICAgID4gU2ViYXN0 aWVuLg0KICAgID4NCiAgICA+IExlIDEzLzA0LzIwMTAgMDU6MDgsIE1hcmsgSm9uZXMgYSDpY3Jp dCA6DQogICAgPiA+DQogICAgPiA+IFdvcmtzIGZvciBtZS4gSSBhc3N1bWUgd2UnZCBzdGlsbCBr ZWVwICJkaWFtZXRlci50bHMudGNwIg0KICAgID4gYXMgdGhlIHRhZw0KICAgID4gPiBmb3JtYXQg c28gdGhhdCAiZGlhbWV0ZXIudGxzLnNjdHAiIGNhbiBiZSB1c2VkIGluIHRoZQ0KICAgID4gc2Vw YXJhdGUgZHJhZnQuDQogICAgPiA+DQogICAgPiA+IE1hcmsNCiAgICA+ID4NCiAgICA+ID4gKkZy b206KiBsaW9uZWwubW9yYW5kQG9yYW5nZS1mdGdyb3VwLmNvbQ0KICAgID4gPiBbbWFpbHRvOmxp b25lbC5tb3JhbmRAb3JhbmdlLWZ0Z3JvdXAuY29tXQ0KICAgID4gPiAqU2VudDoqIEFwcmlsIDEy LCAyMDEwIDExOjU5IEFNDQogICAgPiA+ICpUbzoqIHZmMDIxM0BnbWFpbC5jb207IHNkZWN1Z2lz QG5pY3QuZ28uanANCiAgICA+ID4gKkNjOiogTWFyayBKb25lczsgZGltZUBpZXRmLm9yZw0KICAg ID4gPiAqU3ViamVjdDoqIFJFOiBbRGltZV0gTkFQVFIgZml4IGZvciAzNTg4YmlzDQogICAgPiA+ DQogICAgPiA+IEhpLA0KICAgID4gPg0KICAgID4gPiBUYWtpbmcgYWNjb3VudCB0aGF0IHRoaXMg dG9waWMgY2FtZSBxdWl0ZSBsYXRlIGluIHRoZQ0KICAgID4gcmV2aXNpb24gcHJvY2Vzcw0KICAg ID4gPiBhbmQgdG8gbm90IGRlbGF5IHRoZSBwdWJsaWNhdGlvbiBvZiB0aGUgUkZDMzU4OGJpcywg d2UgY291bGQgbWF5YmUNCiAgICA+ID4gY29uc2lkZXIgdG8gYWRkcmVzcyBUTFMgb3ZlciBTQ1RQ IGluIGEgc2VwYXJldGUgZHJhZnQgaW4gYSBsYXR0ZXINCiAgICA+ID4gcGhhc2UgaWYgdGhlcmUg aXMgYSBXRyBpbnRlcmVzdCBvZiB0aGUgV0cgdG8gc3VwcG9ydCB0aGlzIG9wdGlvbi4NCiAgICA+ ID4NCiAgICA+ID4gV291bGQgaXQgYmUgYWNjZXB0YWJsZT8NCiAgICA+ID4NCiAgICA+ID4gUmVn YXJkcywNCiAgICA+ID4NCiAgICA+ID4gTGlvbmVsDQogICAgPiA+DQogICAgPiA+DQogICAgPiA+ DQogICAgPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogICAgPiA+IC0tDQogICAgPiA+DQogICAgPiA+ICAgICAq RGUgOiogZGltZS1ib3VuY2VzQGlldGYub3JnDQogICAgPiBbbWFpbHRvOmRpbWUtYm91bmNlc0Bp ZXRmLm9yZ10gKkRlIGxhDQogICAgPiA+ICAgICBwYXJ0IGRlKiBWaWN0b3IgRmFqYXJkbw0KICAg ID4gPiAgICAgKkVudm956SA6KiBsdW5kaSAxMiBhdnJpbCAyMDEwIDE0OjI4DQogICAgPiA+ICAg ICAqwCA6KiBTZWJhc3RpZW4gRGVjdWdpcw0KICAgID4gPiAgICAgKkNjIDoqIE1hcmsgSm9uZXM7 IGRpbWVAaWV0Zi5vcmcNCiAgICA+ID4gICAgICpPYmpldCA6KiBSZTogW0RpbWVdIE5BUFRSIGZp eCBmb3IgMzU4OGJpcw0KICAgID4gPg0KICAgID4gPiAgICAgSGkgU2ViYXN0aWVuLA0KICAgID4g Pg0KICAgID4gPiAgICAgT24gU3VuLCBBcHIgMTEsIDIwMTAgYXQgOTo0MyBQTSwgU2ViYXN0aWVu IERlY3VnaXMNCiAgICA+ID4gICAgIDxzZGVjdWdpc0BuaWN0LmdvLmpwIDxtYWlsdG86c2RlY3Vn aXNAbmljdC5nby5qcD4+IHdyb3RlOg0KICAgID4gPg0KICAgID4gPiAgICAgSGksDQogICAgPiA+ DQogICAgPiA+ICAgICBTb3JyeSBmb3IgdGhlIGRlbGF5LCBJIHdhcyBvbiB2YWNhdGlvbi4NCiAg ICA+ID4NCiAgICA+ID4gICAgIExlIDA5LzA0LzIwMTAgMDc6MDIsIE1hcmsgSm9uZXMgYSDpY3Jp dCA6DQogICAgPiA+ICAgICA+IDQpIEFwcGxpY2F0aW9uIHByb3RvY29sIHRhZyBmb3IgVExTIGRv ZXMgbm90IGRpZmZlcmVudGlhdGUNCiAgICA+ID4gICAgIFRMUy9UQ1AgdnMNCiAgICA+ID4gICAg ID4gVExTL1NDVFAgKFNlYmFzdGlhbikuDQogICAgPiA+ICAgICA+DQogICAgPiA+ICAgICA+IENv bmNsdXNpb246IE5ldyBUTFMgdGFncyBwcm9wb3NlZCB0byBTZWJhc3RpYW4uIFN0aWxsDQogICAg PiA+ICAgICA+IG9wZW4uDQogICAgPiA+ICAgICA+DQogICAgPiA+DQogICAgPiA+ICAgICBJIGFt IHBlcmZlY3RseSBmaW5lIHdpdGggdGhlIHJlc29sdXRpb24geW91IHByb3Bvc2VkLCB0aGFuayB5 b3UhDQogICAgPiA+DQogICAgPiA+ICAgICA+IDUpIE1pc3NpbmcgcmVmIHRvIFRMUy9TQ1RQIC0g UkZDMzQzNiAoU2ViYXN0aWFuKS4NCiAgICA+ID4gICAgID4NCiAgICA+ID4gICAgID4gQ29uY2x1 c2lvbjogQWRkIHRoZSBtaXNzaW5nIHJlZmVyZW5jZSB0byAzNTg4YmlzLg0KICAgID4gPiAgICAg PiBVbnJlbGF0ZWQgdG8gdGhpcyBmaXggdGhvdWdoLg0KICAgID4gPiAgICAgPg0KICAgID4gPiAg ICAgSSBndWVzcyB0aGlzIHJlc29sdXRpb24gd2lsbCByZXF1aXJlIGEgYml0IG1vcmUNCiAgICA+ IGZlZWRiYWNrIGZyb20gdGhlDQogICAgPiA+ICAgICBncm91cCwNCiAgICA+ID4gICAgIHRoZXJl IG1heSBiZSBvdGhlciB3YXlzIHRvIGltcGxlbWVudCBUTFMgb3ZlciBTQ1RQLi4uDQogICAgPiBD YW4gdGhlIGNoYWlycw0KICAgID4gPiAgICAgZ2l2ZSBkaXJlY3Rpb24gb24gdGhpcyBpc3N1ZT8N CiAgICA+ID4NCiAgICA+ID4NCiAgICA+ID4NCiAgICA+ID4gICAgIEZvciBhbGwgcHJhY3RpY2Fs IHB1cnBvc2UsIGlzIHRoZXJlIHJlYWxseSBhIHN0cm9uZyBkZXBsb3lhYmxlDQogICAgPiA+ICAg ICByZWFzb24gdG8gc3VwcG9ydCBUTFMgb3ZlciBTQ1RQID8gSSdtIGp1c3QgaGVzaXRhbnQgdG8g ZGVsYXkgYmlzDQogICAgPiA+ICAgICBwdWJsaWNhdGlvbiB0byBzdXBwb3J0IGFuIGFjYWRlbWlj IGV4ZXJjaXNlLg0KICAgID4gPg0KICAgID4gPiAgICAgcmVnYXJkcywNCiAgICA+ID4gICAgIHZp Y3Rvcg0KICAgID4gPg0KICAgID4gPg0KICAgID4gPg0KICAgID4gPiAgICAgICAgIFRoYW5rcyEN CiAgICA+ID4gICAgICAgICBTZWJhc3RpZW4uDQogICAgPiA+DQogICAgPiA+ICAgICAgICAgLS0N CiAgICA+ID4gICAgICAgICBTZWJhc3RpZW4gRGVjdWdpcw0KICAgID4gPiAgICAgICAgIFJlc2Vh cmNoIGZlbGxvdw0KICAgID4gPiAgICAgICAgIE5ldHdvcmsgQXJjaGl0ZWN0dXJlIEdyb3VwDQog ICAgPiA+ICAgICAgICAgTklDVCAobmljdC5nby5qcCA8aHR0cDovL25pY3QuZ28uanA+KQ0KICAg ID4gPg0KICAgID4NCiAgICA+IC0tDQogICAgPiBTZWJhc3RpZW4gRGVjdWdpcw0KICAgID4gUmVz ZWFyY2ggZmVsbG93DQogICAgPiBOZXR3b3JrIEFyY2hpdGVjdHVyZSBHcm91cA0KICAgID4gTklD VCAobmljdC5nby5qcCkNCiAgICA+DQogICAgPg0KDQoNCg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KDQoNCiAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCiAgRGlNRSBtYWlsaW5nIGxpc3QNCiAgRGlNRUBpZXRmLm9yZw0KICBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RpbWUNCg== --Boundary_(ID_8mQ+dKX8SjdZhbof8QR06w) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWlz by04ODU5LTEiIGh0dHAtZXF1aXY9Q29udGVudC1UeXBlPg0KPE1FVEEgbmFtZT1HRU5FUkFUT1Ig Y29udGVudD0iTVNIVE1MIDguMDAuNjAwMS4xODkwNCI+DQo8U1RZTEU+PC9TVFlMRT4NCjwvSEVB RD4NCjxCT0RZIGJnQ29sb3I9I2NjZThjZj4NCjxESVY+SGksPC9ESVY+DQo8RElWPlNvcnJ5IGZv ciBteSBsYXRlIHJlcGx5LiA8L0RJVj4NCjxESVY+R28gdGhyb3VnaCB0aGUgcHJvcG9zZWQgQ2hh bmdlcyB0byB0aGUgYmlzIHZlcnNpb24uIDwvRElWPg0KPERJVj5JIGZvdW5kJm5ic3A7ICJkaWFt ZXRlci50bHMiIGFzJm5ic3A7dGhlIHN1cHBvcnRlZCBhcHBsaWNhdGlvbiBwcm90b2NvbCBpbiAN CnRoZSAqRklSU1QgQ0hBTkdFKiBpcyBzdGlsbCB1c2VkIHRoZXJlIDwvRElWPg0KPERJVj53aGlj aCBpcyBub3QgY29uc2lzdGVudCB3aXRoICJkaWFtZXRlci50bHMudGNwIiZuYnNwO3NwZWNpZmll ZCBpbiB0aGUgDQoqU0VDT05EIENIQU5HRSouPC9ESVY+DQo8RElWPjxGT05UIHNpemU9MiBmYWNl PSYjMjM0MzU7JiMyMDMwNzs+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTIg ZmFjZT0mIzIzNDM1OyYjMjAzMDc7PjxGT05UIHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4i PkFsc28mbmJzcDtzb21lIA0KcXVlc3Rpb25zJm5ic3A7dG8gdGhlIGNoYW5nZXM6PC9GT05UPjwv Rk9OVD48L0RJVj4NCjxESVY+MS4gSWYgdGhlIERpYW1ldGVyIHNlcnZlciBpbmRpY2F0ZXMgdG8g dGhlIERpYW1ldGVyIGNsaWVudCB0aGF0IGl0IHN1cHBvcnQgDQpib3RoIFRDUCBhbmQgVExTL1RD UDwvRElWPg0KPERJVj4mbmJzcDsgYW5kIHRoZSBEaWFtZXRlciBjbGllbnQgYWxzbyBzdXBwb3J0 IGJvdGgsJm5ic3A7d2hldGhlciB0aGUgRGlhbWV0ZXIgDQpjbGllbnQgY2FuIHN0aWxsIGNob29z ZSZuYnNwO1RDUCBhcyB0cmFuc3BvcnQ8L0RJVj4NCjxESVY+Jm5ic3A7IHByb3Rjb2w/Jm5ic3A7 SW4gb3RoZXIgd29yZHMsJm5ic3A7aW4gd2hpY2ggY29uZGl0aW9uJm5ic3A7ZG9lcyB0aGUgDQpj bGllbnQgY2hvb3NlIFRDUCBhbmQmbmJzcDtpbiB3aGljaCBjb25kaXRpb24mbmJzcDtkb2VzIHRo ZSBjbGllbnQgY2hvb3NlIA0KVExTL1RDUD88L0RJVj4NCjxESVY+b3ImbmJzcDtDYW4gd2Ugc2F5 IFRMUy9UQ1AgdHJhbnNwb3J0IGlzIG1vcmUgcmVsaWFibGUmbmJzcDthbmQgc2VjdXJlIHRoYW4g DQpUQ1AmbmJzcDt0cmFuc3BvcnQgZm9yIERpYW1ldGVyPyBUaGF0J3Mgd2h5IHdlIGNob29zZSBU TFMgb3ZlciBUQ1AgaW5zdGVhZCBvZiANClRDUD88L0RJVj4NCjxESVY+Mi4gSSBhbSB3b25kZXJp bmcgV2hldGhlciBUTFMvVENQIHRyYW5zcG9ydCBjYW4gd29yayBpbiB0aGUgcm9hbWluZyANCnNj ZW5hcmlvPyBJbiBvcmRlciB3b3Jkcywgd2hldGhlciB3ZSBjYW4gPC9ESVY+DQo8RElWPmFsbG93 IHNldmVyYWwgRGlhbWV0ZXIgcGVlcnMgbG9jYXRlZCBiZXR3ZWVuIERpYW1ldGVyIENsaWVudCBh bmQgRGlhbWV0ZXIgDQpTZXJ2ZXI/IHdoZXRoZXIgVExTL1RDUCBjYW4gd29yayBhY3Jvc3MgcmVh bG1zPzwvRElWPg0KPERJVj4zLldoZW4mbmJzcDt0aGUgRGlhbWV0ZXImbmJzcDtDbGllbnQgY2hv b3NlIFRMUy9UQ1AgYXMgdHJhbnNwb3J0LCB3aGF0IA0KdHJhbnNwb3J0IHBvcnQgd2lsbCBiZSB1 c2VkJm5ic3A7PyBTYW1lIGFzIHBvcnQgZm9yIFRDUCBvciBTQ1RQIG9yIG5vdCA/IGlmIA0Kbm90 LHdoYXQgaXMgaXQ/PC9ESVY+DQo8RElWPkhvcGUgc29tZWJvZHkgY2FuIGNsYXJpZnkuIFRoYW5r cyE8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yIGZhY2U9JiMyMzQzNTsmIzIwMzA3Oz48L0ZPTlQ+ Jm5ic3A7PC9ESVY+DQo8RElWPlJlZ2FyZHMhPC9ESVY+DQo8RElWPi1RaW48L0RJVj4NCjxCTE9D S1FVT1RFIA0Kc3R5bGU9IkJPUkRFUi1MRUZUOiAjMDAwMDAwIDJweCBzb2xpZDsgUEFERElORy1M RUZUOiA1cHg7IFBBRERJTkctUklHSFQ6IDBweDsgTUFSR0lOLUxFRlQ6IDVweDsgTUFSR0lOLVJJ R0hUOiAwcHgiPg0KICA8RElWIHN0eWxlPSJGT05UOiA5cHQgJiMyMzQzNTsmIzIwMzA3OyI+LS0t LS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSA8L0RJVj4NCiAgPERJViBzdHlsZT0iRk9OVDogOXB0 ICYjMjM0MzU7JiMyMDMwNzs7IEJBQ0tHUk9VTkQ6ICNlNGU0ZTQ7IGZvbnQtY29sb3I6IGJsYWNr Ij48Qj5Gcm9tOjwvQj4gDQogIDxBIHRpdGxlPXZmMDIxM0BnbWFpbC5jb20gaHJlZj0ibWFpbHRv OnZmMDIxM0BnbWFpbC5jb20iPlZpY3RvciBGYWphcmRvPC9BPiANCiAgPC9ESVY+DQogIDxESVYg c3R5bGU9IkZPTlQ6IDlwdCAmIzIzNDM1OyYjMjAzMDc7Ij48Qj5Ubzo8L0I+IDxBIHRpdGxlPWxp b25lbC5tb3JhbmRAb3JhbmdlLWZ0Z3JvdXAuY29tIA0KICBocmVmPSJtYWlsdG86bGlvbmVsLm1v cmFuZEBvcmFuZ2UtZnRncm91cC5jb20iPmxpb25lbC5tb3JhbmRAb3JhbmdlLWZ0Z3JvdXAuY29t PC9BPiANCiAgPC9ESVY+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDlwdCAmIzIzNDM1OyYjMjAzMDc7 Ij48Qj5DYzo8L0I+IDxBIA0KICB0aXRsZT1NYXJrLkpvbmVzQGJyaWRnZXdhdGVyc3lzdGVtcy5j b20gDQogIGhyZWY9Im1haWx0bzpNYXJrLkpvbmVzQGJyaWRnZXdhdGVyc3lzdGVtcy5jb20iPk1h cmsuSm9uZXNAYnJpZGdld2F0ZXJzeXN0ZW1zLmNvbTwvQT4gDQogIDsgPEEgdGl0bGU9ZGltZUBp ZXRmLm9yZyBocmVmPSJtYWlsdG86ZGltZUBpZXRmLm9yZyI+ZGltZUBpZXRmLm9yZzwvQT4gPC9E SVY+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDlwdCAmIzIzNDM1OyYjMjAzMDc7Ij48Qj5TZW50Ojwv Qj4gV2VkbmVzZGF5LCBBcHJpbCAxNCwgMjAxMCAxOjUwIEFNPC9ESVY+DQogIDxESVYgc3R5bGU9 IkZPTlQ6IDlwdCAmIzIzNDM1OyYjMjAzMDc7Ij48Qj5TdWJqZWN0OjwvQj4gUmU6IFtEaW1lXSBO QVBUUiBmaXggZm9yIA0KICAzNTg4YmlzPC9ESVY+DQogIDxESVY+PEJSPjwvRElWPkxvb2tzIGdv b2QuIEknbGwgc2VuZCBvdXQgYSBiaXMgdmVyc2lvbiB3aXRoIHRoZSBjaGFuZ2VzIA0KICBiZWxv dy48QlI+PEJSPjxCUj4NCiAgPERJViBjbGFzcz1nbWFpbF9xdW90ZT5PbiBUdWUsIEFwciAxMywg MjAxMCBhdCA5OjQ2IEFNLCA8U1BBTiBkaXI9bHRyPiZsdDs8QSANCiAgaHJlZj0ibWFpbHRvOmxp b25lbC5tb3JhbmRAb3JhbmdlLWZ0Z3JvdXAuY29tIj5saW9uZWwubW9yYW5kQG9yYW5nZS1mdGdy b3VwLmNvbTwvQT4mZ3Q7PC9TUEFOPiANCiAgd3JvdGU6PEJSPg0KICA8QkxPQ0tRVU9URSANCiAg c3R5bGU9IkJPUkRFUi1MRUZUOiByZ2IoMjA0LDIwNCwyMDQpIDFweCBzb2xpZDsgTUFSR0lOOiAw cHQgMHB0IDBwdCAwLjhleDsgUEFERElORy1MRUZUOiAxZXgiIA0KICBjbGFzcz1nbWFpbF9xdW90 ZT5UaHggU+liYXN0aWVuLjxCUj48QlI+U28gdG8gc3VtIHVwLCBhbGwgdGhlIGV4aXN0aW5nIA0K ICAgIGlzc3VlcyBhcmUgbm93IGNsb3NlZC48QlI+PEJSPkFueSBvdGhlciBmZWVkYmFjayBmcm9t IHRoZSBXRyBvbiB0aGUgcHJvcG9zZWQgDQogICAgbW9kaWZpY2F0aW9uPzxCUj48QlI+SGVyZWFm dGVyIHRoZSBtb2RpZmljYXRpb24gcHJvcG9zZWQgYnkgTWFyayB3aXRoIA0KICAgIGNvcnJlY3Rp b25zIGJhc2VkIG9uIHRoZSBhZ3JlZW1lbnQgcmVhY2hlZCBhZnRlciBlbWFpbCANCiAgICBkaXNj dXNzaW9uOjxCUj48QlI+KioqKioqKioqKioqKioqKioqKioqKioqKiBGSVJTVCBDSEFOR0UgDQog ICAgKioqKioqKioqKioqKioqKioqKioqKioqKjxCUj48QlI+U2VjdGlvbiA1LjIgRGlhbWV0ZXIg UGVlciANCiAgICBEaXNjb3Zlcnk8QlI+PEJSPj0mZ3Q7IFJlcGxhY2Ugc3RlcCAyIHdpdGggdGhl IGZvbGxvd2luZyB0ZXh0OjxCUj48QlI+Jm5ic3A7IA0KICAgIDIuICZuYnNwO1RoZSBEaWFtZXRl ciBpbXBsZW1lbnRhdGlvbiBwZXJmb3JtcyBhIE5BUFRSIHF1ZXJ5IGZvciBhIA0KICAgIHNlcnZl cjxCUj4mbmJzcDsgJm5ic3A7ICZuYnNwOyBpbiBhIHBhcnRpY3VsYXIgcmVhbG0uICZuYnNwO1Ro ZSBEaWFtZXRlciANCiAgICBpbXBsZW1lbnRhdGlvbiBoYXMgdG8ga25vdzxCUj4mbmJzcDsgJm5i c3A7ICZuYnNwOyBpbiBhZHZhbmNlIHdoaWNoIHJlYWxtIHRvIA0KICAgIGxvb2sgZm9yIGEgRGlh bWV0ZXIgYWdlbnQgaW4uICZuYnNwO1RoaXM8QlI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgY291bGQg YmUgDQogICAgZGVkdWNlZCwgZm9yIGV4YW1wbGUsIGZyb20gdGhlICdyZWFsbScgaW4gYSBOQUkg dGhhdCBhPEJSPiZuYnNwOyAmbmJzcDsgDQogICAgJm5ic3A7IERpYW1ldGVyIGltcGxlbWVudGF0 aW9uIG5lZWRlZCB0byBwZXJmb3JtIGEgRGlhbWV0ZXIgDQogICAgb3BlcmF0aW9uPEJSPiZuYnNw OyAmbmJzcDsgJm5ic3A7IG9uLjxCUj48QlI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgVGhlIE5BUFRS IA0KICAgIHVzYWdlIGluIERpYW1ldGVyIGZvbGxvd3MgdGhlIFMtTkFQVFIgREREUyBhcHBsaWNh dGlvbjxCUj4mbmJzcDsgJm5ic3A7IA0KICAgICZuYnNwOyBbUkZDMzk1OF0gd2hpY2ggbWVhbnMg dGhhdCB0aGUgU0VSVklDRSBmaWVsZCBpbmNsdWRlcyB0YWdzIGZvciANCiAgICB0aGU8QlI+Jm5i c3A7ICZuYnNwOyAmbmJzcDsgZGVzaXJlZCBhcHBsaWNhdGlvbiBhbmQgc3VwcG9ydGVkIGFwcGxp Y2F0aW9uIA0KICAgIHByb3RvY29sLjxCUj4mbmJzcDsgJm5ic3A7ICZuYnNwOyBUaGUgYXBwbGlj YXRpb24gc2VydmljZSB0YWcgZm9yIGEgRGlhbWV0ZXIgDQogICAgYXBwbGljYXRpb24gaXMgJ2Fh YScgYW5kPEJSPiZuYnNwOyAmbmJzcDsgJm5ic3A7IHRoZSBzdXBwb3J0ZWQgDQogICAgJm5ic3A7 YXBwbGljYXRpb24gcHJvdG9jb2wgdGFncyBhcmUgJ2RpYW1ldGVyLnRjcCcsPEJSPiZuYnNwOyAm bmJzcDsgJm5ic3A7IA0KICAgICdkaWFtZXRlci5zY3RwJyBvciAnZGlhbWV0ZXIudGxzJy48QlI+ PEJSPiZuYnNwOyAmbmJzcDsgJm5ic3A7IFRoZSBjbGllbnQgDQogICAgZm9sbG93cyB0aGUgcmVz b2x1dGlvbiBwcm9jZXNzIGRlZmluZWQgYnkgdGhlIFMtTkFQVFI8QlI+Jm5ic3A7ICZuYnNwOyAN CiAgICAmbmJzcDsgREREUyBbUkZDMzk1OF0gYXBwbGljYXRpb24gdG8gZmluZCBhIG1hdGNoaW5n IFNSViBvciBBIHJlY29yZCANCiAgICBvZjxCUj4mbmJzcDsgJm5ic3A7ICZuYnNwOyBhIHN1aXRh YmxlIHBlZXIuICZuYnNwO1RoZSBkb21haW4gc3VmZml4ZXMgaW4gdGhlIA0KICAgIE5BUFRSIHJl cGxhY2VtZW50IGZpZWxkPEJSPiZuYnNwOyAmbmJzcDsgJm5ic3A7IFNIT1VMRCBtYXRjaCB0aGUg ZG9tYWluIG9mIA0KICAgIHRoZSBvcmlnaW5hbCBxdWVyeS48QlI+PEJSPjxCUj4qKioqKioqKioq KioqKioqKioqKioqKioqIFNFQ09ORCBDSEFOR0UgDQogICAgKioqKioqKioqKioqKioqKioqKioq KioqKjxCUj48QlI+U2VjdGlvbiAxMS42IE5BUFRSIFNlcnZpY2UgDQogICAgRmllbGRzPEJSPjxC Uj49Jmd0OyBSZW5hbWUgdGhpcyBzZWN0aW9uIHRvIFMtTkFQVFIgUGFyYW1ldGVycyBhbmQgcmVw bGFjZSANCiAgICBjb250ZW50IHdpdGg6PEJSPjxCUj5UaGlzIGRvY3VtZW50IHJlZ2lzdGVycyBh IFMtTkFQVFIgQXBwbGljYXRpb24gU2VydmljZSANCiAgICBUYWcgdmFsdWUgb2YgImFhYSIuPEJS PjxCUj5UaGlzIGRvY3VtZW50IGFsc28gcmVnaXN0ZXJzIHRoZSBmb2xsb3dpbmcgDQogICAgUy1O QVBUUiBBcHBsaWNhdGlvbiBQcm90b2NvbCBUYWdzOjxCUj4NCiAgICA8RElWIGNsYXNzPWltPjxC Uj4mbmJzcDsgVGFnICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IA0K ICAgICZuYnNwOyAmbmJzcDt8IFByb3RvY29sPEJSPiZuYnNwOyAtLS0tLS0tLS0tLS0tLS0tLS0t fC0tLS0tLS0tLTxCUj4mbmJzcDsgDQogICAgZGlhbWV0ZXIudGNwICZuYnNwOyAmbmJzcDsgJm5i c3A7IHwgVENQPEJSPiZuYnNwOyBkaWFtZXRlci5zY3RwICZuYnNwOyANCiAgICAmbmJzcDsgJm5i c3A7fCBTQ1RQPEJSPiZuYnNwOyBkaWFtZXRlci50bHMudGNwICZuYnNwOyB8IA0KICAgIFRMUy9U Q1A8QlI+PEJSPjwvRElWPioqKioqKioqKioqKioqKioqKioqKioqKiogVEhJUkQgQ0hBTkdFIA0K ICAgICoqKioqKioqKioqKioqKioqKioqKioqKioqPEJSPjxCUj5BcHBlbmRpeCBCLiAmbmJzcDtO QVBUUiANCiAgICBFeGFtcGxlPEJSPjxCUj49Jmd0OyBSZW5hbWUgc2VjdGlvbiB0byBTLU5BUFRS IEV4YW1wbGUgYW5kIG1vZGlmeSBhcyANCiAgICBmb2xsb3dzLjxCUj48QlI+Jm5ic3A7IEFzIGFu IGV4YW1wbGUsIGNvbnNpZGVyIGEgY2xpZW50IHRoYXQgd2lzaGVzIHRvIA0KICAgIHJlc29sdmUg YWFhOjxCUj4mbmJzcDsgPEEgaHJlZj0iaHR0cDovL2V4YW1wbGUuY29tIiANCiAgICB0YXJnZXQ9 X2JsYW5rPmV4YW1wbGUuY29tPC9BPi4gJm5ic3A7VGhlIGNsaWVudCBwZXJmb3JtcyBhIE5BUFRS IHF1ZXJ5IGZvciANCiAgICB0aGF0IGRvbWFpbiwgYW5kPEJSPiZuYnNwOyB0aGUgZm9sbG93aW5n IE5BUFRSIHJlY29yZHMgYXJlIA0KICAgIHJldHVybmVkOjxCUj48QlI+Jm5ic3A7OzsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7b3JkZXIgcHJlZiBmbGFncyANCiAgICBzZXJ2aWNlICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtyZWdleHAg DQogICAgcmVwbGFjZW1lbnQ8QlI+Jm5ic3A7SU4gTkFQVFIgJm5ic3A7NTAgJm5ic3A7ICZuYnNw OzUwICZuYnNwOyAicyIgJm5ic3A7IA0KICAgICJhYWE6ZGlhbWV0ZXIudGxzLnRjcCIgJm5ic3A7 IiIgJm5ic3A7ICZuYnNwOyBfZGlhbWV0ZXIuXzxBIA0KICAgIGhyZWY9Imh0dHA6Ly90bHMudGNw LmV4YW1wbGUuY29tIiANCiAgICB0YXJnZXQ9X2JsYW5rPnRscy50Y3AuZXhhbXBsZS5jb208L0E+ PEJSPiZuYnNwO0lOIE5BUFRSICZuYnNwOzEwMCAmbmJzcDsgNTAgDQogICAgJm5ic3A7ICJzIiAm bmJzcDsgImFhYTpkaWFtZXRlci50Y3AiICZuYnNwOyAmbmJzcDsgJm5ic3A7IiIgJm5ic3A7ICZu YnNwOyANCiAgICBfZGlhbWV0ZXIuXzxBIGhyZWY9Imh0dHA6Ly90Y3AuZXhhbXBsZS5jb20iIA0K ICAgIHRhcmdldD1fYmxhbms+dGNwLmV4YW1wbGUuY29tPC9BPjxCUj4mbmJzcDtJTiBOQVBUUiAm bmJzcDsxNTAgJm5ic3A7IDUwIA0KICAgICZuYnNwOyAicyIgJm5ic3A7ICJhYWE6ZGlhbWV0ZXIu c2N0cCIgJm5ic3A7ICZuYnNwOyAiIiAmbmJzcDsgJm5ic3A7IA0KICAgIF9kaWFtZXRlci5fPEEg aHJlZj0iaHR0cDovL3NjdHAuZXhhbXBsZS5jb20iIA0KICAgIHRhcmdldD1fYmxhbms+c2N0cC5l eGFtcGxlLmNvbTwvQT48QlI+PEJSPiZuYnNwOyBUaGlzIGluZGljYXRlcyB0aGF0IHRoZSANCiAg ICBzZXJ2ZXIgc3VwcG9ydHMgVExTL1RDUCwgVENQIGFuZCBTQ1RQIGluIHRoYXQ8QlI+Jm5ic3A7 IG9yZGVyLiAmbmJzcDtJZiB0aGUgDQogICAgY2xpZW50IHN1cHBvcnRzIFRMUy9UQ1AsIFRMUy9U Q1Agd2lsbCBiZSB1c2VkLCB0YXJnZXRlZCB0byBhPEJSPiZuYnNwOyBob3N0IA0KICAgIGRldGVy bWluZWQgYnkgYW4gU1JWIGxvb2t1cCBvZiBfZGlhbWV0ZXIuXzxBIA0KICAgIGhyZWY9Imh0dHA6 Ly90bHMudGNwLmV4YW1wbGUuY29tIiB0YXJnZXQ9X2JsYW5rPnRscy50Y3AuZXhhbXBsZS5jb208 L0E+LiANCiAgICAmbmJzcDtUaGF0PEJSPiZuYnNwOyBsb29rdXAgd291bGQgcmV0dXJuOjxCUj48 QlI+Jm5ic3A7ICZuYnNwOzs7ICZuYnNwOyANCiAgICAmbmJzcDsgJm5ic3A7IFByaW9yaXR5ICZu YnNwO1dlaWdodCAmbmJzcDtQb3J0ICZuYnNwOyAmbmJzcDtUYXJnZXQ8QlI+Jm5ic3A7IA0KICAg ICZuYnNwO0lOIFNSViAmbmJzcDsgMCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgMSAmbmJz cDsgJm5ic3A7ICZuYnNwOyANCiAgICA1MDYwICZuYnNwOyAmbmJzcDs8QSBocmVmPSJodHRwOi8v c2VydmVyMS5leGFtcGxlLmNvbSIgDQogICAgdGFyZ2V0PV9ibGFuaz5zZXJ2ZXIxLmV4YW1wbGUu Y29tPC9BPjxCUj4mbmJzcDsgJm5ic3A7SU4gU1JWICZuYnNwOyAwICZuYnNwOyANCiAgICAmbmJz cDsgJm5ic3A7ICZuYnNwOyAyICZuYnNwOyAmbmJzcDsgJm5ic3A7IDUwNjAgJm5ic3A7ICZuYnNw OzxBIA0KICAgIGhyZWY9Imh0dHA6Ly9zZXJ2ZXIyLmV4YW1wbGUuY29tIiANCiAgICB0YXJnZXQ9 X2JsYW5rPnNlcnZlcjIuZXhhbXBsZS5jb208L0E+PEJSPjxCUj49Jmd0O2FkZGl0aW9uIG9mIGFu IGV4YW1wbGUgDQogICAgd2l0aCAiYSIgZmxhZyByZXF1aXJlZCBzdWNoIGFzOjxCUj48QlI+Jm5i c3A7SU4gTkFQVFIgJm5ic3A7MTUwICZuYnNwOyA1MCANCiAgICAmbmJzcDsgImEiICZuYnNwOyAi YWFhOmRpYW1ldGVyLnRscy50Y3AiICZuYnNwOyIiICZuYnNwOyAmbmJzcDsgPEEgDQogICAgaHJl Zj0iaHR0cDovL3NlcnZlcjEuZXhhbXBsZS5jb20iIA0KICAgIHRhcmdldD1fYmxhbms+c2VydmVy MS5leGFtcGxlLmNvbTwvQT48QlI+Jm5ic3A7SU4gTkFQVFIgJm5ic3A7MTUwICZuYnNwOyA1MCAN CiAgICAmbmJzcDsgImEiICZuYnNwOyAiYWFhOmRpYW1ldGVyLnRscy50Y3AiICZuYnNwOyIiICZu YnNwOyAmbmJzcDsgPEEgDQogICAgaHJlZj0iaHR0cDovL3NlcnZlcjIuZXhhbXBsZS5jb20iIA0K ICAgIHRhcmdldD1fYmxhbms+c2VydmVyMi5leGFtcGxlLmNvbTwvQT48QlI+PEJSPioqKioqKioq KioqKioqKioqKioqKioqKiogDQogICAgRk9VUlRIIENIQU5HRSAqKioqKioqKioqKioqKioqKioq KioqKioqKjxCUj48QlI+MTQuMS4gJm5ic3A7Tm9ybWF0aXZlIA0KICAgIFJlZmVyZW5jZXM8QlI+ PEJSPj0mZ3Q7IEFkZCBuZXcgcmVmZXJlbmNlIHRvIFMtTkFQVFIgREREUyANCiAgICBSRkMzOTU4 LjxCUj48QlI+KioqKioqKioqKioqKioqKioqKioqKioqKiBFTkQgT0YgQ0hBTkdFUyANCiAgICAq KioqKioqKioqKioqKioqKioqKioqKjxCUj48QlI+PEJSPjxCUj48QlI+PEJSPiZndDsgLS0tLS1N ZXNzYWdlIA0KICAgIGQnb3JpZ2luZS0tLS0tPEJSPiZndDsgRGUgOiBTZWJhc3RpZW4gRGVjdWdp cyBbbWFpbHRvOjxBIA0KICAgIGhyZWY9Im1haWx0bzpzZGVjdWdpc0BuaWN0LmdvLmpwIj5zZGVj dWdpc0BuaWN0LmdvLmpwPC9BPl08QlI+Jmd0OyBFbnZveekgOiANCiAgICBtYXJkaSAxMyBhdnJp bCAyMDEwIDA3OjE0PEJSPiZndDsgwCA6IE1hcmsgSm9uZXM8QlI+Jmd0OyBDYyA6IE1PUkFORCBM aW9uZWwgDQogICAgUkQtQ09SRS1JU1M7IDxBIGhyZWY9Im1haWx0bzp2ZjAyMTNAZ21haWwuY29t Ij52ZjAyMTNAZ21haWwuY29tPC9BPjsgPEEgDQogICAgaHJlZj0ibWFpbHRvOmRpbWVAaWV0Zi5v cmciPmRpbWVAaWV0Zi5vcmc8L0E+PEJSPg0KICAgIDxESVY+DQogICAgPERJVj48L0RJVj4NCiAg ICA8RElWIGNsYXNzPWg1PiZndDsgT2JqZXQgOiBSZTogW0RpbWVdIE5BUFRSIGZpeCBmb3IgMzU4 OGJpczxCUj4mZ3Q7PEJSPiZndDsgDQogICAgSGksPEJSPiZndDs8QlI+Jmd0OyBJIGFtIGZpbmUg d2l0aCB0aGlzIGFwcHJvYWNoIGFzIHdlbGwuIE15IGluaXRpYWwgDQogICAgaW50ZW50aW9uPEJS PiZndDsgd2FzIGp1c3QgdG8gaGlnaGxpZ2h0IHRoYXQgaGF2aW5nIFRMUyBhdCB0aGUgc2FtZSBs ZXZlbCANCiAgICBhczxCUj4mZ3Q7IFRDUCBhbmQgU0NUUCBpcyB2ZXJ5IGNvbmZ1c2luZy48QlI+ Jmd0OyBUaGUgdGFnIA0KICAgICJkaWFtZXRlci50bHMudGNwIiBpcyBwZXJmZWN0bHkgZmluZSBm b3IgbWUuIEFuZCBpdDxCUj4mZ3Q7IHdpbGwgYmUgcXVpdGUgDQogICAgZWFzeSB0byBmaWd1cmUg d2hhdCB0byBkbywgc2hvdWxkIChUTFMgb3Zlcik8QlI+Jmd0OyBTQ1RQIGJlY29tZSBtb3JlIA0K ICAgIHBvcHVsYXIuPEJSPiZndDs8QlI+Jmd0OyBCZXN0IHJlZ2FyZHMsPEJSPiZndDsgU2ViYXN0 aWVuLjxCUj4mZ3Q7PEJSPiZndDsgTGUgDQogICAgMTMvMDQvMjAxMCAwNTowOCwgTWFyayBKb25l cyBhIOljcml0IDo8QlI+Jmd0OyAmZ3Q7PEJSPiZndDsgJmd0OyBXb3JrcyBmb3IgDQogICAgbWUu IEkgYXNzdW1lIHdlJ2Qgc3RpbGwga2VlcCAiZGlhbWV0ZXIudGxzLnRjcCI8QlI+Jmd0OyBhcyB0 aGUgdGFnPEJSPiZndDsgDQogICAgJmd0OyBmb3JtYXQgc28gdGhhdCAiZGlhbWV0ZXIudGxzLnNj dHAiIGNhbiBiZSB1c2VkIGluIHRoZTxCUj4mZ3Q7IHNlcGFyYXRlIA0KICAgIGRyYWZ0LjxCUj4m Z3Q7ICZndDs8QlI+Jmd0OyAmZ3Q7IE1hcms8QlI+Jmd0OyAmZ3Q7PEJSPiZndDsgJmd0OyAqRnJv bToqIDxBIA0KICAgIGhyZWY9Im1haWx0bzpsaW9uZWwubW9yYW5kQG9yYW5nZS1mdGdyb3VwLmNv bSI+bGlvbmVsLm1vcmFuZEBvcmFuZ2UtZnRncm91cC5jb208L0E+PEJSPiZndDsgDQogICAgJmd0 OyBbbWFpbHRvOjxBIA0KICAgIGhyZWY9Im1haWx0bzpsaW9uZWwubW9yYW5kQG9yYW5nZS1mdGdy b3VwLmNvbSI+bGlvbmVsLm1vcmFuZEBvcmFuZ2UtZnRncm91cC5jb208L0E+XTxCUj4mZ3Q7IA0K ICAgICZndDsgKlNlbnQ6KiBBcHJpbCAxMiwgMjAxMCAxMTo1OSBBTTxCUj4mZ3Q7ICZndDsgKlRv OiogPEEgDQogICAgaHJlZj0ibWFpbHRvOnZmMDIxM0BnbWFpbC5jb20iPnZmMDIxM0BnbWFpbC5j b208L0E+OyA8QSANCiAgICBocmVmPSJtYWlsdG86c2RlY3VnaXNAbmljdC5nby5qcCI+c2RlY3Vn aXNAbmljdC5nby5qcDwvQT48QlI+Jmd0OyAmZ3Q7ICpDYzoqIA0KICAgIE1hcmsgSm9uZXM7IDxB IGhyZWY9Im1haWx0bzpkaW1lQGlldGYub3JnIj5kaW1lQGlldGYub3JnPC9BPjxCUj4mZ3Q7ICZn dDsgDQogICAgKlN1YmplY3Q6KiBSRTogW0RpbWVdIE5BUFRSIGZpeCBmb3IgMzU4OGJpczxCUj4m Z3Q7ICZndDs8QlI+Jmd0OyAmZ3Q7IA0KICAgIEhpLDxCUj4mZ3Q7ICZndDs8QlI+Jmd0OyAmZ3Q7 IFRha2luZyBhY2NvdW50IHRoYXQgdGhpcyB0b3BpYyBjYW1lIHF1aXRlIGxhdGUgDQogICAgaW4g dGhlPEJSPiZndDsgcmV2aXNpb24gcHJvY2VzczxCUj4mZ3Q7ICZndDsgYW5kIHRvIG5vdCBkZWxh eSB0aGUgDQogICAgcHVibGljYXRpb24gb2YgdGhlIFJGQzM1ODhiaXMsIHdlIGNvdWxkIG1heWJl PEJSPiZndDsgJmd0OyBjb25zaWRlciB0byANCiAgICBhZGRyZXNzIFRMUyBvdmVyIFNDVFAgaW4g YSBzZXBhcmV0ZSBkcmFmdCBpbiBhIGxhdHRlcjxCUj4mZ3Q7ICZndDsgcGhhc2UgaWYgDQogICAg dGhlcmUgaXMgYSBXRyBpbnRlcmVzdCBvZiB0aGUgV0cgdG8gc3VwcG9ydCB0aGlzIG9wdGlvbi48 QlI+Jmd0OyANCiAgICAmZ3Q7PEJSPiZndDsgJmd0OyBXb3VsZCBpdCBiZSBhY2NlcHRhYmxlPzxC Uj4mZ3Q7ICZndDs8QlI+Jmd0OyAmZ3Q7IA0KICAgIFJlZ2FyZHMsPEJSPiZndDsgJmd0OzxCUj4m Z3Q7ICZndDsgTGlvbmVsPEJSPiZndDsgJmd0OzxCUj4mZ3Q7ICZndDs8QlI+Jmd0OyANCiAgICAm Z3Q7PEJSPiZndDsgDQogICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxCUj4mZ3Q7IA0KICAgICZndDsgLS08QlI+ Jmd0OyAmZ3Q7PEJSPiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICpEZSA6KiA8QSANCiAgICBocmVm PSJtYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnIj5kaW1lLWJvdW5jZXNAaWV0Zi5vcmc8L0E+ PEJSPiZndDsgDQogICAgW21haWx0bzo8QSBocmVmPSJtYWlsdG86ZGltZS1ib3VuY2VzQGlldGYu b3JnIj5kaW1lLWJvdW5jZXNAaWV0Zi5vcmc8L0E+XSANCiAgICAqRGUgbGE8QlI+Jmd0OyAmZ3Q7 ICZuYnNwOyAmbmJzcDsgcGFydCBkZSogVmljdG9yIEZhamFyZG88QlI+Jmd0OyAmZ3Q7IA0KICAg ICZuYnNwOyAmbmJzcDsgKkVudm956SA6KiBsdW5kaSAxMiBhdnJpbCAyMDEwIDE0OjI4PEJSPiZn dDsgJmd0OyAmbmJzcDsgDQogICAgJm5ic3A7ICrAIDoqIFNlYmFzdGllbiBEZWN1Z2lzPEJSPiZn dDsgJmd0OyAmbmJzcDsgJm5ic3A7ICpDYyA6KiBNYXJrIEpvbmVzOyANCiAgICA8QSBocmVmPSJt YWlsdG86ZGltZUBpZXRmLm9yZyI+ZGltZUBpZXRmLm9yZzwvQT48QlI+Jmd0OyAmZ3Q7ICZuYnNw OyAmbmJzcDsgDQogICAgKk9iamV0IDoqIFJlOiBbRGltZV0gTkFQVFIgZml4IGZvciAzNTg4Ymlz PEJSPiZndDsgJmd0OzxCUj4mZ3Q7ICZndDsgJm5ic3A7IA0KICAgICZuYnNwOyBIaSBTZWJhc3Rp ZW4sPEJSPiZndDsgJmd0OzxCUj4mZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyBPbiBTdW4sIEFwciAx MSwgDQogICAgMjAxMCBhdCA5OjQzIFBNLCBTZWJhc3RpZW4gRGVjdWdpczxCUj4mZ3Q7ICZndDsg Jm5ic3A7ICZuYnNwOyAmbHQ7PEEgDQogICAgaHJlZj0ibWFpbHRvOnNkZWN1Z2lzQG5pY3QuZ28u anAiPnNkZWN1Z2lzQG5pY3QuZ28uanA8L0E+ICZsdDttYWlsdG86PEEgDQogICAgaHJlZj0ibWFp bHRvOnNkZWN1Z2lzQG5pY3QuZ28uanAiPnNkZWN1Z2lzQG5pY3QuZ28uanA8L0E+Jmd0OyZndDsg DQogICAgd3JvdGU6PEJSPiZndDsgJmd0OzxCUj4mZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyBIaSw8 QlI+Jmd0OyAmZ3Q7PEJSPiZndDsgJmd0OyANCiAgICAmbmJzcDsgJm5ic3A7IFNvcnJ5IGZvciB0 aGUgZGVsYXksIEkgd2FzIG9uIHZhY2F0aW9uLjxCUj4mZ3Q7ICZndDs8QlI+Jmd0OyANCiAgICAm Z3Q7ICZuYnNwOyAmbmJzcDsgTGUgMDkvMDQvMjAxMCAwNzowMiwgTWFyayBKb25lcyBhIOljcml0 IDo8QlI+Jmd0OyAmZ3Q7IA0KICAgICZuYnNwOyAmbmJzcDsgJmd0OyA0KSBBcHBsaWNhdGlvbiBw cm90b2NvbCB0YWcgZm9yIFRMUyBkb2VzIG5vdCANCiAgICBkaWZmZXJlbnRpYXRlPEJSPiZndDsg Jmd0OyAmbmJzcDsgJm5ic3A7IFRMUy9UQ1AgdnM8QlI+Jmd0OyAmZ3Q7ICZuYnNwOyANCiAgICAm bmJzcDsgJmd0OyBUTFMvU0NUUCAoU2ViYXN0aWFuKS48QlI+Jmd0OyAmZ3Q7ICZuYnNwOyAmbmJz cDsgJmd0OzxCUj4mZ3Q7IA0KICAgICZndDsgJm5ic3A7ICZuYnNwOyAmZ3Q7IENvbmNsdXNpb246 IE5ldyBUTFMgdGFncyBwcm9wb3NlZCB0byBTZWJhc3RpYW4uIA0KICAgIFN0aWxsPEJSPiZndDsg Jmd0OyAmbmJzcDsgJm5ic3A7ICZndDsgb3Blbi48QlI+Jmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsg DQogICAgJmd0OzxCUj4mZ3Q7ICZndDs8QlI+Jmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgSSBhbSBw ZXJmZWN0bHkgZmluZSB3aXRoIHRoZSANCiAgICByZXNvbHV0aW9uIHlvdSBwcm9wb3NlZCwgdGhh bmsgeW91ITxCUj4mZ3Q7ICZndDs8QlI+Jmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgDQogICAgJmd0 OyA1KSBNaXNzaW5nIHJlZiB0byBUTFMvU0NUUCAtIFJGQzM0MzYgKFNlYmFzdGlhbikuPEJSPiZn dDsgJmd0OyAmbmJzcDsgDQogICAgJm5ic3A7ICZndDs8QlI+Jmd0OyAmZ3Q7ICZuYnNwOyAmbmJz cDsgJmd0OyBDb25jbHVzaW9uOiBBZGQgdGhlIG1pc3NpbmcgDQogICAgcmVmZXJlbmNlIHRvIDM1 ODhiaXMuPEJSPiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZndDsgVW5yZWxhdGVkIHRvIHRoaXMg Zml4IA0KICAgIHRob3VnaC48QlI+Jmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJmd0OzxCUj4mZ3Q7 ICZndDsgJm5ic3A7ICZuYnNwOyBJIGd1ZXNzIA0KICAgIHRoaXMgcmVzb2x1dGlvbiB3aWxsIHJl cXVpcmUgYSBiaXQgbW9yZTxCUj4mZ3Q7IGZlZWRiYWNrIGZyb20gdGhlPEJSPiZndDsgDQogICAg Jmd0OyAmbmJzcDsgJm5ic3A7IGdyb3VwLDxCUj4mZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyB0aGVy ZSBtYXkgYmUgb3RoZXIgd2F5cyANCiAgICB0byBpbXBsZW1lbnQgVExTIG92ZXIgU0NUUC4uLjxC Uj4mZ3Q7IENhbiB0aGUgY2hhaXJzPEJSPiZndDsgJmd0OyAmbmJzcDsgDQogICAgJm5ic3A7IGdp dmUgZGlyZWN0aW9uIG9uIHRoaXMgaXNzdWU/PEJSPiZndDsgJmd0OzxCUj4mZ3Q7ICZndDs8QlI+ Jmd0OyANCiAgICAmZ3Q7PEJSPiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7IEZvciBhbGwgcHJhY3Rp Y2FsIHB1cnBvc2UsIGlzIHRoZXJlIHJlYWxseSBhIA0KICAgIHN0cm9uZyBkZXBsb3lhYmxlPEJS PiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7IHJlYXNvbiB0byBzdXBwb3J0IFRMUyBvdmVyIFNDVFAg DQogICAgPyBJJ20ganVzdCBoZXNpdGFudCB0byBkZWxheSBiaXM8QlI+Jmd0OyAmZ3Q7ICZuYnNw OyAmbmJzcDsgcHVibGljYXRpb24gdG8gDQogICAgc3VwcG9ydCBhbiBhY2FkZW1pYyBleGVyY2lz ZS48QlI+Jmd0OyAmZ3Q7PEJSPiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7IA0KICAgIHJlZ2FyZHMs PEJSPiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7IHZpY3RvcjxCUj4mZ3Q7ICZndDs8QlI+Jmd0OyAm Z3Q7PEJSPiZndDsgDQogICAgJmd0OzxCUj4mZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7IFRoYW5rcyE8QlI+Jmd0OyAmZ3Q7ICZuYnNwOyANCiAgICAmbmJzcDsgJm5ic3A7ICZu YnNwOyBTZWJhc3RpZW4uPEJSPiZndDsgJmd0OzxCUj4mZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAN CiAgICAmbmJzcDsgJm5ic3A7IC0tPEJSPiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgU2ViYXN0aWVuIA0KICAgIERlY3VnaXM8QlI+Jmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyBSZXNlYXJjaCBmZWxsb3c8QlI+Jmd0OyANCiAgICAmZ3Q7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyBOZXR3b3JrIEFyY2hpdGVjdHVyZSBHcm91cDxCUj4mZ3Q7ICZn dDsgDQogICAgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IE5JQ1QgKDxBIGhyZWY9Imh0dHA6 Ly9uaWN0LmdvLmpwIiANCiAgICB0YXJnZXQ9X2JsYW5rPm5pY3QuZ28uanA8L0E+ICZsdDs8QSBo cmVmPSJodHRwOi8vbmljdC5nby5qcCIgDQogICAgdGFyZ2V0PV9ibGFuaz5odHRwOi8vbmljdC5n by5qcDwvQT4mZ3Q7KTxCUj4mZ3Q7ICZndDs8QlI+Jmd0OzxCUj4mZ3Q7IA0KICAgIC0tPEJSPiZn dDsgU2ViYXN0aWVuIERlY3VnaXM8QlI+Jmd0OyBSZXNlYXJjaCBmZWxsb3c8QlI+Jmd0OyBOZXR3 b3JrIA0KICAgIEFyY2hpdGVjdHVyZSBHcm91cDxCUj4mZ3Q7IE5JQ1QgKDxBIGhyZWY9Imh0dHA6 Ly9uaWN0LmdvLmpwIiANCiAgICB0YXJnZXQ9X2JsYW5rPm5pY3QuZ28uanA8L0E+KTxCUj4mZ3Q7 PEJSPiZndDs8QlI+PC9ESVY+PC9ESVY+PC9CTE9DS1FVT1RFPjwvRElWPjxCUj4NCiAgPFA+DQog IDxIUj4NCg0KICA8UD48L1A+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188QlI+RGlNRSBtYWlsaW5nIA0KICBsaXN0PEJSPkRpTUVAaWV0Zi5vcmc8QlI+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaW1lPEJSPjwvQkxPQ0tRVU9URT48 L0JPRFk+PC9IVE1MPg0K --Boundary_(ID_8mQ+dKX8SjdZhbof8QR06w)-- From vf0213@gmail.com Wed Apr 14 05:47:11 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FDF53A6A58 for ; Wed, 14 Apr 2010 05:47:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.806 X-Spam-Level: X-Spam-Status: No, score=-0.806 tagged_above=-999 required=5 tests=[AWL=-0.892, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, J_CHICKENPOX_83=0.6, J_CHICKENPOX_84=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TnqyMojLxAPS for ; Wed, 14 Apr 2010 05:47:08 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 9C99D28C0E9 for ; Wed, 14 Apr 2010 05:42:34 -0700 (PDT) Received: by wyb35 with SMTP id 35so29540wyb.31 for ; Wed, 14 Apr 2010 05:42:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=46dwPG2e6KqVYwp21qCfTRB2F8EgKemeq7RBxkiEsz4=; b=vtgCcZYOJqkszXFQTV66+KhPAlYWovWkumM0WC4EPkvwwI5y6eYhZ9hsNF+SviLSO8 5AY1K8UtPe+E69RelkiKQopQa3PTSh9Y+pQjpHZ7JmXgKlU1U50NDKxEjc8m/AyaoGFE oKHXiTBH3Y8EzoJk+uVIB882T9yZh/4ryOsX4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=n8bbEvqhXtJ58qTFQwIBebpeZ2LaUlQ5qKWhsJ3IRHptRNs3QqqLwztx9XaPQBHVZp jIzyng/njeUkhgWgP1xBZ5KhezfkaGWLVy23zsLSattUWTqHwvHsNcqXRix4s4Oy4u3M qX5OE2Nw6zY9KsHl4UePIypfgbvECrCTqB4B8= MIME-Version: 1.0 Received: by 10.216.169.207 with HTTP; Wed, 14 Apr 2010 05:42:24 -0700 (PDT) In-Reply-To: <00f101cadb7c$c59a4590$23548a0a@china.huawei.com> References: <4BC288CB.9030002@nict.go.jp> <4BC3FD95.70803@nict.go.jp> <00f101cadb7c$c59a4590$23548a0a@china.huawei.com> Date: Wed, 14 Apr 2010 07:42:24 -0500 Received: by 10.216.174.129 with SMTP id x1mr1399105wel.140.1271248944522; Wed, 14 Apr 2010 05:42:24 -0700 (PDT) Message-ID: From: Victor Fajardo To: Qin Wu Content-Type: multipart/alternative; boundary=0016e65ae682c26788048431b538 Cc: Mark.Jones@bridgewatersystems.com, dime@ietf.org Subject: Re: [Dime] NAPTR fix for 3588bis X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Apr 2010 12:47:11 -0000 --0016e65ae682c26788048431b538 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Qun, Comments inline: On Tue, Apr 13, 2010 at 9:47 PM, Qin Wu wrote: > Hi, > Sorry for my late reply. > Go through the proposed Changes to the bis version. > I found "diameter.tls" as the supported application protocol in the *FIR= ST > CHANGE* is still used there > which is not consistent with "diameter.tls.tcp" specified in the *SECOND > CHANGE*. > > Also some questions to the changes: > 1. If the Diameter server indicates to the Diameter client that it suppor= t > both TCP and TLS/TCP > and the Diameter client also support both, whether the Diameter client > can still choose TCP as transport > protcol? In other words, in which condition does the client choose TCP > and in which condition does the client choose TLS/TCP? > That depends on the security policy during deployment of the diameter node. Its not something that the document should specify. > or Can we say TLS/TCP transport is more reliable and secure than > TCP transport for Diameter? That's why we choose TLS over TCP instead of > TCP? > I'm not exactly sure what you mean here. Additional security would be the only criteria for using TLS/TCP. > 2. I am wondering Whether TLS/TCP transport can work in the roaming > scenario? In order words, whether we can > allow several Diameter peers located between Diameter Client and Diameter > Server? whether TLS/TCP can work across realms? > Hmmm ... I think your forgetting the fact that diameter transport are peering transports, i.e. transport connections are negotiated/configured on a per peer connection basis. So the question does not seem to make sense to me. > 3.When the Diameter Client choose TLS/TCP as transport, what transport po= rt > will be used ? Same as port for TCP or SCTP or not ? if not,what is it? > TLS/TCP is going to be on a different port than just plain TCP. Port assignments for TCP is in to current doc while TLS is still to be allocated= . regards, victor > Hope somebody can clarify. Thanks! > > Regards! > -Qin > > ----- Original Message ----- > *From:* Victor Fajardo > *To:* lionel.morand@orange-ftgroup.com > *Cc:* Mark.Jones@bridgewatersystems.com ; dime@ietf.org > *Sent:* Wednesday, April 14, 2010 1:50 AM > *Subject:* Re: [Dime] NAPTR fix for 3588bis > > Looks good. I'll send out a bis version with the changes below. > > > On Tue, Apr 13, 2010 at 9:46 AM, wrote= : > >> Thx S=E9bastien. >> >> So to sum up, all the existing issues are now closed. >> >> Any other feedback from the WG on the proposed modification? >> >> Hereafter the modification proposed by Mark with corrections based on th= e >> agreement reached after email discussion: >> >> ************************* FIRST CHANGE ************************* >> >> Section 5.2 Diameter Peer Discovery >> >> =3D> Replace step 2 with the following text: >> >> 2. The Diameter implementation performs a NAPTR query for a server >> in a particular realm. The Diameter implementation has to know >> in advance which realm to look for a Diameter agent in. This >> could be deduced, for example, from the 'realm' in a NAI that a >> Diameter implementation needed to perform a Diameter operation >> on. >> >> The NAPTR usage in Diameter follows the S-NAPTR DDDS application >> [RFC3958] which means that the SERVICE field includes tags for the >> desired application and supported application protocol. >> The application service tag for a Diameter application is 'aaa' an= d >> the supported application protocol tags are 'diameter.tcp', >> 'diameter.sctp' or 'diameter.tls'. >> >> The client follows the resolution process defined by the S-NAPTR >> DDDS [RFC3958] application to find a matching SRV or A record of >> a suitable peer. The domain suffixes in the NAPTR replacement fie= ld >> SHOULD match the domain of the original query. >> >> >> ************************* SECOND CHANGE ************************* >> >> Section 11.6 NAPTR Service Fields >> >> =3D> Rename this section to S-NAPTR Parameters and replace content with: >> >> This document registers a S-NAPTR Application Service Tag value of "aaa"= . >> >> This document also registers the following S-NAPTR Application Protocol >> Tags: >> >> Tag | Protocol >> -------------------|--------- >> diameter.tcp | TCP >> diameter.sctp | SCTP >> diameter.tls.tcp | TLS/TCP >> >> ************************* THIRD CHANGE ************************** >> >> Appendix B. NAPTR Example >> >> =3D> Rename section to S-NAPTR Example and modify as follows. >> >> As an example, consider a client that wishes to resolve aaa: >> example.com. The client performs a NAPTR query for that domain, and >> the following NAPTR records are returned: >> >> ;; order pref flags service regexp replacement >> IN NAPTR 50 50 "s" "aaa:diameter.tls.tcp" "" _diameter._ >> tls.tcp.example.com >> IN NAPTR 100 50 "s" "aaa:diameter.tcp" "" _diameter._ >> tcp.example.com >> IN NAPTR 150 50 "s" "aaa:diameter.sctp" "" _diameter._ >> sctp.example.com >> >> This indicates that the server supports TLS/TCP, TCP and SCTP in that >> order. If the client supports TLS/TCP, TLS/TCP will be used, targeted >> to a >> host determined by an SRV lookup of _diameter._tls.tcp.example.com. >> That >> lookup would return: >> >> ;; Priority Weight Port Target >> IN SRV 0 1 5060 server1.example.com >> IN SRV 0 2 5060 server2.example.com >> >> =3D>addition of an example with "a" flag required such as: >> >> IN NAPTR 150 50 "a" "aaa:diameter.tls.tcp" "" >> server1.example.com >> IN NAPTR 150 50 "a" "aaa:diameter.tls.tcp" "" >> server2.example.com >> >> ************************* FOURTH CHANGE ************************** >> >> 14.1. Normative References >> >> =3D> Add new reference to S-NAPTR DDDS RFC3958. >> >> ************************* END OF CHANGES *********************** >> >> >> >> >> >> > -----Message d'origine----- >> > De : Sebastien Decugis [mailto:sdecugis@nict.go.jp] >> > Envoy=E9 : mardi 13 avril 2010 07:14 >> > =C0 : Mark Jones >> > Cc : MORAND Lionel RD-CORE-ISS; vf0213@gmail.com; dime@ietf.org >> > Objet : Re: [Dime] NAPTR fix for 3588bis >> > >> > Hi, >> > >> > I am fine with this approach as well. My initial intention >> > was just to highlight that having TLS at the same level as >> > TCP and SCTP is very confusing. >> > The tag "diameter.tls.tcp" is perfectly fine for me. And it >> > will be quite easy to figure what to do, should (TLS over) >> > SCTP become more popular. >> > >> > Best regards, >> > Sebastien. >> > >> > Le 13/04/2010 05:08, Mark Jones a =E9crit : >> > > >> > > Works for me. I assume we'd still keep "diameter.tls.tcp" >> > as the tag >> > > format so that "diameter.tls.sctp" can be used in the >> > separate draft. >> > > >> > > Mark >> > > >> > > *From:* lionel.morand@orange-ftgroup.com >> > > [mailto:lionel.morand@orange-ftgroup.com] >> > > *Sent:* April 12, 2010 11:59 AM >> > > *To:* vf0213@gmail.com; sdecugis@nict.go.jp >> > > *Cc:* Mark Jones; dime@ietf.org >> > > *Subject:* RE: [Dime] NAPTR fix for 3588bis >> > > >> > > Hi, >> > > >> > > Taking account that this topic came quite late in the >> > revision process >> > > and to not delay the publication of the RFC3588bis, we could maybe >> > > consider to address TLS over SCTP in a separete draft in a latter >> > > phase if there is a WG interest of the WG to support this option. >> > > >> > > Would it be acceptable? >> > > >> > > Regards, >> > > >> > > Lionel >> > > >> > > >> > > >> > ---------------------------------------------------------------------- >> > > -- >> > > >> > > *De :* dime-bounces@ietf.org >> > [mailto:dime-bounces@ietf.org] *De la >> > > part de* Victor Fajardo >> > > *Envoy=E9 :* lundi 12 avril 2010 14:28 >> > > *=C0 :* Sebastien Decugis >> > > *Cc :* Mark Jones; dime@ietf.org >> > > *Objet :* Re: [Dime] NAPTR fix for 3588bis >> > > >> > > Hi Sebastien, >> > > >> > > On Sun, Apr 11, 2010 at 9:43 PM, Sebastien Decugis >> > > > wrote: >> > > >> > > Hi, >> > > >> > > Sorry for the delay, I was on vacation. >> > > >> > > Le 09/04/2010 07:02, Mark Jones a =E9crit : >> > > > 4) Application protocol tag for TLS does not differentiate >> > > TLS/TCP vs >> > > > TLS/SCTP (Sebastian). >> > > > >> > > > Conclusion: New TLS tags proposed to Sebastian. Still >> > > > open. >> > > > >> > > >> > > I am perfectly fine with the resolution you proposed, thank you! >> > > >> > > > 5) Missing ref to TLS/SCTP - RFC3436 (Sebastian). >> > > > >> > > > Conclusion: Add the missing reference to 3588bis. >> > > > Unrelated to this fix though. >> > > > >> > > I guess this resolution will require a bit more >> > feedback from the >> > > group, >> > > there may be other ways to implement TLS over SCTP... >> > Can the chairs >> > > give direction on this issue? >> > > >> > > >> > > >> > > For all practical purpose, is there really a strong deployable >> > > reason to support TLS over SCTP ? I'm just hesitant to delay bis >> > > publication to support an academic exercise. >> > > >> > > regards, >> > > victor >> > > >> > > >> > > >> > > Thanks! >> > > Sebastien. >> > > >> > > -- >> > > Sebastien Decugis >> > > Research fellow >> > > Network Architecture Group >> > > NICT (nict.go.jp ) >> > > >> > >> > -- >> > Sebastien Decugis >> > Research fellow >> > Network Architecture Group >> > NICT (nict.go.jp) >> > >> > >> > > ------------------------------ > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > > --0016e65ae682c26788048431b538 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Qun,

Comments inline:

On Tue, A= pr 13, 2010 at 9:47 PM, Qin Wu <sunseawq@huawei.com> wrote:
Hi,
Sorry for my late reply.
Go through the proposed Changes to the bis version.
I found=C2=A0 "diameter.tls" as=C2=A0the supported applicati= on protocol in=20 the *FIRST CHANGE* is still used there
which is not consistent with "diameter.tls.tcp"=C2=A0specifi= ed in the=20 *SECOND CHANGE*.
=C2=A0
Also=C2=A0some=20 questions=C2=A0to the changes:
1. If the Diameter server indicates to the Diameter client that it sup= port=20 both TCP and TLS/TCP
=C2=A0 and the Diameter client also support both,=C2=A0whether the Dia= meter=20 client can still choose=C2=A0TCP as transport
=C2=A0 protcol?=C2=A0In other words,=C2=A0in which condition=C2=A0does= the=20 client choose TCP and=C2=A0in which condition=C2=A0does the client choose= =20 TLS/TCP?


That depends on the security = policy during deployment of the diameter node. Its not something that the d= ocument should specify.

=C2=A0
or=C2=A0Can we say TLS/TCP transport is more reliable=C2=A0and secure = than=20 TCP=C2=A0transport for Diameter? That's why we choose TLS over TCP inst= ead of=20 TCP?


I'm not exactly sure what you= mean here. Additional security would be the only criteria for using TLS/TC= P.

=C2=A0
2. I am wondering Whether TLS/TCP transport can work in the roaming=20 scenario? In order words, whether we can
allow several Diameter peers located between Diameter Client and Diame= ter=20 Server? whether TLS/TCP can work across realms?


Hmmm ... I think your forgetting the fact that diameter transport= are peering transports, i.e. transport connections are negotiated/configur= ed on a per peer connection basis. So the question does not seem to make se= nse to me.

=C2=A0
<= div bgcolor=3D"#cce8cf">
3.When=C2=A0the Diameter=C2=A0Client choose TLS/TCP as transport, what= =20 transport port will be used=C2=A0? Same as port for TCP or SCTP or not ? if= =20 not,what is it?


TLS/TCP is going to be= on a different port than just plain TCP. Port assignments for TCP is in to= current doc while TLS is still to be allocated.

regards,
victor<= br>

=C2=A0
Hope somebody can clarify. Thanks!
=C2=A0
Regards!
-Qin
----- Original Message -----
From:=20 Victor Fajardo=20
Sent: Wednesday, April 14, 2010 1:50 AM
Subject: Re: [Dime] NAPTR fix for=20 3588bis

Looks good. I'll send out a bis version with the chang= es=20 below.


On Tue, Apr 13, 2010 at 9:46 AM, <lionel.morand@orange-ftgroup.com>=20 wrote:
Thx S=C3=A9bast= ien.

So to sum up, all the existing=20 issues are now closed.

Any other feedback from the WG on the pro= posed=20 modification?

Hereafter the modification proposed by Mark with= =20 corrections based on the agreement reached after email=20 discussion:

************************* FIRST CHANGE=20 *************************

Section 5.2 Diameter Peer=20 Discovery

=3D> Replace step 2 with the following text:
=C2=A0=20 2. =C2=A0The Diameter implementation performs a NAPTR query for a=20 server
=C2=A0 =C2=A0 =C2=A0 in a particular realm. =C2=A0The Diamete= r=20 implementation has to know
=C2=A0 =C2=A0 =C2=A0 in advance which rea= lm to=20 look for a Diameter agent in. =C2=A0This
=C2=A0 =C2=A0 =C2=A0 could = be=20 deduced, for example, from the 'realm' in a NAI that a
=C2= =A0 =C2=A0=20 =C2=A0 Diameter implementation needed to perform a Diameter=20 operation
=C2=A0 =C2=A0 =C2=A0 on.

=C2=A0 =C2=A0 =C2=A0 The N= APTR=20 usage in Diameter follows the S-NAPTR DDDS application
=C2=A0 =C2=A0= =20 =C2=A0 [RFC3958] which means that the SERVICE field includes tags for= =20 the
=C2=A0 =C2=A0 =C2=A0 desired application and supported applicati= on=20 protocol.
=C2=A0 =C2=A0 =C2=A0 The application service tag for a Dia= meter=20 application is 'aaa' and
=C2=A0 =C2=A0 =C2=A0 the supported= =20 =C2=A0application protocol tags are 'diameter.tcp',
=C2=A0 = =C2=A0 =C2=A0=20 'diameter.sctp' or 'diameter.tls'.

=C2=A0 =C2=A0= =C2=A0 The client=20 follows the resolution process defined by the S-NAPTR
=C2=A0 =C2=A0= =20 =C2=A0 DDDS [RFC3958] application to find a matching SRV or A record=20 of
=C2=A0 =C2=A0 =C2=A0 a suitable peer. =C2=A0The domain suffixes i= n the=20 NAPTR replacement field
=C2=A0 =C2=A0 =C2=A0 SHOULD match the domain= of=20 the original query.


************************* SECOND CHANGE= =20 *************************

Section 11.6 NAPTR Service=20 Fields

=3D> Rename this section to S-NAPTR Parameters and rep= lace=20 content with:

This document registers a S-NAPTR Application Serv= ice=20 Tag value of "aaa".

This document also registers the f= ollowing=20 S-NAPTR Application Protocol Tags:

=C2=A0 Tag =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=20 =C2=A0 =C2=A0| Protocol
=C2=A0 -------------------|---------
=C2= =A0=20 diameter.tcp =C2=A0 =C2=A0 =C2=A0 | TCP
=C2=A0 diameter.sctp =C2=A0= =20 =C2=A0 =C2=A0| SCTP
=C2=A0 diameter.tls.tcp =C2=A0 |=20 TLS/TCP

************************* THIRD CHANGE=20 **************************

Appendix B. =C2=A0NAPTR=20 Example

=3D> Rename section to S-NAPTR Example and modify as= =20 follows.

=C2=A0 As an example, consider a client that wishes to= =20 resolve aaa:
=C2=A0 example.com. =C2=A0The client performs a NAPTR query for=20 that domain, and
=C2=A0 the following NAPTR records are=20 returned:

=C2=A0;; =C2=A0 =C2=A0 =C2=A0 =C2=A0order pref flags= =20 service =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0regexp= =20 replacement
=C2=A0IN NAPTR =C2=A050 =C2=A0 =C2=A050 =C2=A0 "s&q= uot; =C2=A0=20 "aaa:diameter.tls.tcp" =C2=A0"" =C2=A0 =C2=A0 _diam= eter._tls.tcp.exam= ple.com
=C2=A0IN NAPTR =C2=A0100 =C2=A0 50=20 =C2=A0 "s" =C2=A0 "aaa:diameter.tcp" =C2=A0 =C2=A0 = =C2=A0"" =C2=A0 =C2=A0=20 _diameter._tcp.exa= mple.com
=C2=A0IN NAPTR =C2=A0150 =C2=A0 50=20 =C2=A0 "s" =C2=A0 "aaa:diameter.sctp" =C2=A0 =C2=A0= "" =C2=A0 =C2=A0=20 _diameter._sctp.e= xample.com

=C2=A0 This indicates that the=20 server supports TLS/TCP, TCP and SCTP in that
=C2=A0 order. =C2=A0If= the=20 client supports TLS/TCP, TLS/TCP will be used, targeted to a
=C2=A0 = host=20 determined by an SRV lookup of _diameter._tls.tcp.example.com.=20 =C2=A0That
=C2=A0 lookup would return:

=C2=A0 =C2=A0;; =C2=A0= =20 =C2=A0 =C2=A0 Priority =C2=A0Weight =C2=A0Port =C2=A0 =C2=A0Target
= =C2=A0=20 =C2=A0IN SRV =C2=A0 0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 1 =C2=A0 =C2=A0 =C2= =A0=20 5060 =C2=A0 =C2=A0server1.example.com
=C2=A0 =C2=A0IN SRV =C2=A0 0 =C2=A0=20 =C2=A0 =C2=A0 =C2=A0 2 =C2=A0 =C2=A0 =C2=A0 5060 =C2=A0 =C2=A0server2.example.com
=3D>addition of an example=20 with "a" flag required such as:

=C2=A0IN NAPTR =C2=A01= 50 =C2=A0 50=20 =C2=A0 "a" =C2=A0 "aaa:diameter.tls.tcp" =C2=A0&quo= t;" =C2=A0 =C2=A0 server1.example.com
=C2=A0IN NAPTR =C2=A0150 =C2=A0 50=20 =C2=A0 "a" =C2=A0 "aaa:diameter.tls.tcp" =C2=A0&quo= t;" =C2=A0 =C2=A0 server2.example.com

*************************=20 FOURTH CHANGE **************************

14.1. =C2=A0Normative= =20 References

=3D> Add new reference to S-NAPTR DDDS=20 RFC3958.

************************* END OF CHANGES=20 ***********************





> -----Message=20 d'origine-----
> De : Sebastien Decugis [mailto:sdecugis@nict.go.jp]
>= ; Envoy=C3=A9 :=20 mardi 13 avril 2010 07:14
> =C3=80 : Mark Jones
> Cc : MORA= ND Lionel=20 RD-CORE-ISS; vf02= 13@gmail.com; dime@i= etf.org
> Objet : Re: [Dime] NAPTR fix for 3588bis
>
>=20 Hi,
>
> I am fine with this approach as well. My initial=20 intention
> was just to highlight that having TLS at the same lev= el=20 as
> TCP and SCTP is very confusing.
> The tag=20 "diameter.tls.tcp" is perfectly fine for me. And it
> w= ill be quite=20 easy to figure what to do, should (TLS over)
> SCTP become more= =20 popular.
>
> Best regards,
> Sebastien.
>
&g= t; Le=20 13/04/2010 05:08, Mark Jones a =C3=A9crit :
> >
> > W= orks for=20 me. I assume we'd still keep "diameter.tls.tcp"
> a= s the tag
>=20 > format so that "diameter.tls.sctp" can be used in the> separate=20 draft.
> >
> > Mark
> >
> > *From:*= lion= el.morand@orange-ftgroup.com
>=20 > [mailto:lionel.morand@orange-ftgroup.com]
>=20 > *Sent:* April 12, 2010 11:59 AM
> > *To:* vf0213@gmail.com; sdecugis@nict.go.jp
> = > *Cc:*=20 Mark Jones; dime@iet= f.org
> >=20 *Subject:* RE: [Dime] NAPTR fix for 3588bis
> >
> >= =20 Hi,
> >
> > Taking account that this topic came quite= late=20 in the
> revision process
> > and to not delay the=20 publication of the RFC3588bis, we could maybe
> > consider to= =20 address TLS over SCTP in a separete draft in a latter
> > phas= e if=20 there is a WG interest of the WG to support this option.
>=20 >
> > Would it be acceptable?
> >
> >=20 Regards,
> >
> > Lionel
> >
> >
= >=20 >
>=20 ----------------------------------------------------------------------<= br>>=20 > --
> >
> > =C2=A0 =C2=A0 *De :* dime-bounces@ietf.org
>= ;=20 [mailto:dime= -bounces@ietf.org]=20 *De la
> > =C2=A0 =C2=A0 part de* Victor Fajardo
> >= =20 =C2=A0 =C2=A0 *Envoy=C3=A9 :* lundi 12 avril 2010 14:28
> > = =C2=A0=20 =C2=A0 *=C3=80 :* Sebastien Decugis
> > =C2=A0 =C2=A0 *Cc :* M= ark Jones;=20 dime@ietf.org> > =C2=A0 =C2=A0=20 *Objet :* Re: [Dime] NAPTR fix for 3588bis
> >
> > = =C2=A0=20 =C2=A0 Hi Sebastien,
> >
> > =C2=A0 =C2=A0 On Sun, Ap= r 11,=20 2010 at 9:43 PM, Sebastien Decugis
> > =C2=A0 =C2=A0 <sdecugis@nict.go.jp= <mailto:sdecug= is@nict.go.jp>>=20 wrote:
> >
> > =C2=A0 =C2=A0 Hi,
> >
>= >=20 =C2=A0 =C2=A0 Sorry for the delay, I was on vacation.
> >
&= gt;=20 > =C2=A0 =C2=A0 Le 09/04/2010 07:02, Mark Jones a =C3=A9crit :
&g= t; >=20 =C2=A0 =C2=A0 > 4) Application protocol tag for TLS does not=20 differentiate
> > =C2=A0 =C2=A0 TLS/TCP vs
> > =C2=A0= =20 =C2=A0 > TLS/SCTP (Sebastian).
> > =C2=A0 =C2=A0 >
&g= t;=20 > =C2=A0 =C2=A0 > Conclusion: New TLS tags proposed to Sebastian.= =20 Still
> > =C2=A0 =C2=A0 > open.
> > =C2=A0 =C2=A0= =20 >
> >
> > =C2=A0 =C2=A0 I am perfectly fine with t= he=20 resolution you proposed, thank you!
> >
> > =C2=A0 = =C2=A0=20 > 5) Missing ref to TLS/SCTP - RFC3436 (Sebastian).
> > =C2= =A0=20 =C2=A0 >
> > =C2=A0 =C2=A0 > Conclusion: Add the missing= =20 reference to 3588bis.
> > =C2=A0 =C2=A0 > Unrelated to this= fix=20 though.
> > =C2=A0 =C2=A0 >
> > =C2=A0 =C2=A0 I gu= ess=20 this resolution will require a bit more
> feedback from the
&g= t;=20 > =C2=A0 =C2=A0 group,
> > =C2=A0 =C2=A0 there may be other= ways=20 to implement TLS over SCTP...
> Can the chairs
> > =C2= =A0=20 =C2=A0 give direction on this issue?
> >
> >
>= =20 >
> > =C2=A0 =C2=A0 For all practical purpose, is there rea= lly a=20 strong deployable
> > =C2=A0 =C2=A0 reason to support TLS over= SCTP=20 ? I'm just hesitant to delay bis
> > =C2=A0 =C2=A0 publica= tion to=20 support an academic exercise.
> >
> > =C2=A0 =C2=A0= =20 regards,
> > =C2=A0 =C2=A0 victor
> >
> >>=20 >
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 Thanks!
> > =C2= =A0=20 =C2=A0 =C2=A0 =C2=A0 Sebastien.
> >
> > =C2=A0 =C2=A0= =20 =C2=A0 =C2=A0 --
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 Sebastien=20 Decugis
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 Research fellow
>= ;=20 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 Network Architecture Group
> >= ;=20 =C2=A0 =C2=A0 =C2=A0 =C2=A0 NICT (nict.go.jp <http://nict.go.jp>)
> >
>
>=20 --
> Sebastien Decugis
> Research fellow
> Network=20 Architecture Group
> NICT (nict.go.jp)
>
>

_______________________________________________
DiME mailing=20 list
DiME@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/dime=

--0016e65ae682c26788048431b538-- From jouni.nospam@gmail.com Wed Apr 14 09:25:18 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B83CC3A67A3 for ; Wed, 14 Apr 2010 09:25:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.799 X-Spam-Level: X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_34=0.6, J_CHICKENPOX_83=0.6, J_CHICKENPOX_84=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KY6qPM01+DDD for ; Wed, 14 Apr 2010 09:25:16 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.155]) by core3.amsl.com (Postfix) with ESMTP id EC8603A69A2 for ; Wed, 14 Apr 2010 09:25:13 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id 22so92920fge.13 for ; Wed, 14 Apr 2010 09:25:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:x-priority:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=jHJ3A54vmFhJ3QtXWi3kyJfY/kEIOhk2hSjb6jqre3c=; b=qnx6ucZeyElW5IhTZDLoz44eoSiOw/A3p5TX/vlBJXCxuxEiGrcXJhpnWwqUnT4Kuh Qkg/u3MXlzFgf9oys3nihuQYVVkis1AfFsfdcMaqzCi1HcCqukuYqovr8hwO+iqH3TkX gawOZ7Hl3cA3m5WRcp5oMJ3OxpVyutFNuRJ60= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:x-priority:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; b=ESSo9Wri8gF+8haM7HLRzzrSdFeHKMt4DjA5aGJgkooozw3jEXXkKFoBwyqRVbQTNC XR+dzIa5qmx6TxdPJLfD6cBqzLlwJ9vYfB/iA/+hAWklN0kvbTDIcl7YjkMZr8iUSA0+ K1Vyb3cnrkIpVrx8P6B4wIepGjCTS3SEYTAJg= Received: by 10.87.73.30 with SMTP id a30mr5921819fgl.64.1271262302827; Wed, 14 Apr 2010 09:25:02 -0700 (PDT) Received: from a83-245-212-219.elisa-laajakaista.fi (a83-245-212-219.elisa-laajakaista.fi [83.245.212.219]) by mx.google.com with ESMTPS id 28sm911740fkx.36.2010.04.14.09.25.01 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 14 Apr 2010 09:25:02 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=iso-8859-1 From: jouni korhonen X-Priority: 3 In-Reply-To: <00f101cadb7c$c59a4590$23548a0a@china.huawei.com> Date: Wed, 14 Apr 2010 19:24:59 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4BC288CB.9030002@nict.go.jp> <4BC3FD95.70803@nict.go.jp> <00f101cadb7c$c59a4590$23548a0a@china.huawei.com> To: Qin Wu X-Mailer: Apple Mail (2.1078) Cc: Mark.Jones@bridgewatersystems.com, dime@ietf.org Subject: Re: [Dime] NAPTR fix for 3588bis X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Apr 2010 16:25:18 -0000 Hi Qin, On Apr 14, 2010, at 5:47 AM, Qin Wu wrote: > Hi, > Sorry for my late reply. > Go through the proposed Changes to the bis version. > I found "diameter.tls" as the supported application protocol in the = *FIRST CHANGE* is still used there > which is not consistent with "diameter.tls.tcp" specified in the = *SECOND CHANGE*. > =20 > Also some questions to the changes: > 1. If the Diameter server indicates to the Diameter client that it = support both TCP and TLS/TCP > and the Diameter client also support both, whether the Diameter = client can still choose TCP as transport > protcol? In other words, in which condition does the client choose = TCP and in which condition does the client choose TLS/TCP? An operator can actually set the preference using NAPTR order and = preference fields when doing DNS provisioning. So the mechanism is = there. > or Can we say TLS/TCP transport is more reliable and secure than TCP = transport for Diameter? That's why we choose TLS over TCP instead of = TCP? Up to an operator to set the preference. > 2. I am wondering Whether TLS/TCP transport can work in the roaming = scenario? In order words, whether we can > allow several Diameter peers located between Diameter Client and = Diameter Server? whether TLS/TCP can work across realms? Such deployment issues are usually handled by e.g. a consortium that = mandates the use of Diameter in the first place. > 3.When the Diameter Client choose TLS/TCP as transport, what transport = port will be used ? Same as port for TCP or SCTP or not ? if not,what is = it? When using SVRs (i.e. a NAPTR points to a SRV), an operator can define = the used port number. So, this can again be solved by proper = provisioning. A predefined port number could be useful but imho really = not needed. The draft could though say something about this. - Jouni > Hope somebody can clarify. Thanks! > =20 > Regards! > -Qin > ----- Original Message ----- > From: Victor Fajardo > To: lionel.morand@orange-ftgroup.com > Cc: Mark.Jones@bridgewatersystems.com ; dime@ietf.org > Sent: Wednesday, April 14, 2010 1:50 AM > Subject: Re: [Dime] NAPTR fix for 3588bis >=20 > Looks good. I'll send out a bis version with the changes below. >=20 >=20 > On Tue, Apr 13, 2010 at 9:46 AM, = wrote: > Thx S=E9bastien. >=20 > So to sum up, all the existing issues are now closed. >=20 > Any other feedback from the WG on the proposed modification? >=20 > Hereafter the modification proposed by Mark with corrections based on = the agreement reached after email discussion: >=20 > ************************* FIRST CHANGE ************************* >=20 > Section 5.2 Diameter Peer Discovery >=20 > =3D> Replace step 2 with the following text: >=20 > 2. The Diameter implementation performs a NAPTR query for a server > in a particular realm. The Diameter implementation has to know > in advance which realm to look for a Diameter agent in. This > could be deduced, for example, from the 'realm' in a NAI that a > Diameter implementation needed to perform a Diameter operation > on. >=20 > The NAPTR usage in Diameter follows the S-NAPTR DDDS application > [RFC3958] which means that the SERVICE field includes tags for = the > desired application and supported application protocol. > The application service tag for a Diameter application is 'aaa' = and > the supported application protocol tags are 'diameter.tcp', > 'diameter.sctp' or 'diameter.tls'. >=20 > The client follows the resolution process defined by the S-NAPTR > DDDS [RFC3958] application to find a matching SRV or A record of > a suitable peer. The domain suffixes in the NAPTR replacement = field > SHOULD match the domain of the original query. >=20 >=20 > ************************* SECOND CHANGE ************************* >=20 > Section 11.6 NAPTR Service Fields >=20 > =3D> Rename this section to S-NAPTR Parameters and replace content = with: >=20 > This document registers a S-NAPTR Application Service Tag value of = "aaa". >=20 > This document also registers the following S-NAPTR Application = Protocol Tags: >=20 > Tag | Protocol > -------------------|--------- > diameter.tcp | TCP > diameter.sctp | SCTP > diameter.tls.tcp | TLS/TCP >=20 > ************************* THIRD CHANGE ************************** >=20 > Appendix B. NAPTR Example >=20 > =3D> Rename section to S-NAPTR Example and modify as follows. >=20 > As an example, consider a client that wishes to resolve aaa: > example.com. The client performs a NAPTR query for that domain, and > the following NAPTR records are returned: >=20 > ;; order pref flags service regexp replacement > IN NAPTR 50 50 "s" "aaa:diameter.tls.tcp" "" = _diameter._tls.tcp.example.com > IN NAPTR 100 50 "s" "aaa:diameter.tcp" "" = _diameter._tcp.example.com > IN NAPTR 150 50 "s" "aaa:diameter.sctp" "" = _diameter._sctp.example.com >=20 > This indicates that the server supports TLS/TCP, TCP and SCTP in = that > order. If the client supports TLS/TCP, TLS/TCP will be used, = targeted to a > host determined by an SRV lookup of _diameter._tls.tcp.example.com. = That > lookup would return: >=20 > ;; Priority Weight Port Target > IN SRV 0 1 5060 server1.example.com > IN SRV 0 2 5060 server2.example.com >=20 > =3D>addition of an example with "a" flag required such as: >=20 > IN NAPTR 150 50 "a" "aaa:diameter.tls.tcp" "" = server1.example.com > IN NAPTR 150 50 "a" "aaa:diameter.tls.tcp" "" = server2.example.com >=20 > ************************* FOURTH CHANGE ************************** >=20 > 14.1. Normative References >=20 > =3D> Add new reference to S-NAPTR DDDS RFC3958. >=20 > ************************* END OF CHANGES *********************** >=20 >=20 >=20 >=20 >=20 > > -----Message d'origine----- > > De : Sebastien Decugis [mailto:sdecugis@nict.go.jp] > > Envoy=E9 : mardi 13 avril 2010 07:14 > > =C0 : Mark Jones > > Cc : MORAND Lionel RD-CORE-ISS; vf0213@gmail.com; dime@ietf.org > > Objet : Re: [Dime] NAPTR fix for 3588bis > > > > Hi, > > > > I am fine with this approach as well. My initial intention > > was just to highlight that having TLS at the same level as > > TCP and SCTP is very confusing. > > The tag "diameter.tls.tcp" is perfectly fine for me. And it > > will be quite easy to figure what to do, should (TLS over) > > SCTP become more popular. > > > > Best regards, > > Sebastien. > > > > Le 13/04/2010 05:08, Mark Jones a =E9crit : > > > > > > Works for me. I assume we'd still keep "diameter.tls.tcp" > > as the tag > > > format so that "diameter.tls.sctp" can be used in the > > separate draft. > > > > > > Mark > > > > > > *From:* lionel.morand@orange-ftgroup.com > > > [mailto:lionel.morand@orange-ftgroup.com] > > > *Sent:* April 12, 2010 11:59 AM > > > *To:* vf0213@gmail.com; sdecugis@nict.go.jp > > > *Cc:* Mark Jones; dime@ietf.org > > > *Subject:* RE: [Dime] NAPTR fix for 3588bis > > > > > > Hi, > > > > > > Taking account that this topic came quite late in the > > revision process > > > and to not delay the publication of the RFC3588bis, we could maybe > > > consider to address TLS over SCTP in a separete draft in a latter > > > phase if there is a WG interest of the WG to support this option. > > > > > > Would it be acceptable? > > > > > > Regards, > > > > > > Lionel > > > > > > > > > > > = ---------------------------------------------------------------------- > > > -- > > > > > > *De :* dime-bounces@ietf.org > > [mailto:dime-bounces@ietf.org] *De la > > > part de* Victor Fajardo > > > *Envoy=E9 :* lundi 12 avril 2010 14:28 > > > *=C0 :* Sebastien Decugis > > > *Cc :* Mark Jones; dime@ietf.org > > > *Objet :* Re: [Dime] NAPTR fix for 3588bis > > > > > > Hi Sebastien, > > > > > > On Sun, Apr 11, 2010 at 9:43 PM, Sebastien Decugis > > > > wrote: > > > > > > Hi, > > > > > > Sorry for the delay, I was on vacation. > > > > > > Le 09/04/2010 07:02, Mark Jones a =E9crit : > > > > 4) Application protocol tag for TLS does not differentiate > > > TLS/TCP vs > > > > TLS/SCTP (Sebastian). > > > > > > > > Conclusion: New TLS tags proposed to Sebastian. Still > > > > open. > > > > > > > > > > I am perfectly fine with the resolution you proposed, thank = you! > > > > > > > 5) Missing ref to TLS/SCTP - RFC3436 (Sebastian). > > > > > > > > Conclusion: Add the missing reference to 3588bis. > > > > Unrelated to this fix though. > > > > > > > I guess this resolution will require a bit more > > feedback from the > > > group, > > > there may be other ways to implement TLS over SCTP... > > Can the chairs > > > give direction on this issue? > > > > > > > > > > > > For all practical purpose, is there really a strong deployable > > > reason to support TLS over SCTP ? I'm just hesitant to delay = bis > > > publication to support an academic exercise. > > > > > > regards, > > > victor > > > > > > > > > > > > Thanks! > > > Sebastien. > > > > > > -- > > > Sebastien Decugis > > > Research fellow > > > Network Architecture Group > > > NICT (nict.go.jp ) > > > > > > > -- > > Sebastien Decugis > > Research fellow > > Network Architecture Group > > NICT (nict.go.jp) > > > > >=20 >=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From sunseawq@huawei.com Wed Apr 14 21:52:19 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9651A3A68C0 for ; Wed, 14 Apr 2010 21:52:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.011 X-Spam-Level: ** X-Spam-Status: No, score=2.011 tagged_above=-999 required=5 tests=[AWL=-1.047, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_34=0.6, J_CHICKENPOX_83=0.6, J_CHICKENPOX_84=0.6, MIME_BASE64_TEXT=1.753, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FSx5jnvmGCMc for ; Wed, 14 Apr 2010 21:52:18 -0700 (PDT) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id D26FF3A6B0E for ; Wed, 14 Apr 2010 21:52:16 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L0W00K3WIUNPT@szxga02-in.huawei.com> for dime@ietf.org; Thu, 15 Apr 2010 12:52:00 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L0W00KRBIUN10@szxga02-in.huawei.com> for dime@ietf.org; Thu, 15 Apr 2010 12:51:59 +0800 (CST) Received: from w53375 ([10.138.84.35]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L0W002W2IUNQM@szxml06-in.huawei.com> for dime@ietf.org; Thu, 15 Apr 2010 12:51:59 +0800 (CST) Date: Thu, 15 Apr 2010 12:51:59 +0800 From: Qin Wu To: jouni korhonen Message-id: <006901cadc57$61dd9ee0$23548a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3598 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: base64 X-Priority: 3 X-MSMail-priority: Normal References: <4BC288CB.9030002@nict.go.jp> <4BC3FD95.70803@nict.go.jp> <00f101cadb7c$c59a4590$23548a0a@china.huawei.com> Cc: Mark.Jones@bridgewatersystems.com, dime@ietf.org Subject: Re: [Dime] NAPTR fix for 3588bis X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2010 04:52:19 -0000 SGksIEpvdW5pOg0KUGxlYXNlIHNlZSBteSBmZWVkYmFjayBiZWxvdy4NCi0tLS0tIE9yaWdpbmFs IE1lc3NhZ2UgLS0tLS0gDQpGcm9tOiAiam91bmkga29yaG9uZW4iIDxqb3VuaS5ub3NwYW1AZ21h aWwuY29tPg0KVG86ICJRaW4gV3UiIDxzdW5zZWF3cUBodWF3ZWkuY29tPg0KQ2M6ICJWaWN0b3Ig RmFqYXJkbyIgPHZmMDIxM0BnbWFpbC5jb20+OyA8bGlvbmVsLm1vcmFuZEBvcmFuZ2UtZnRncm91 cC5jb20+OyA8TWFyay5Kb25lc0BicmlkZ2V3YXRlcnN5c3RlbXMuY29tPjsgPGRpbWVAaWV0Zi5v cmc+DQpTZW50OiBUaHVyc2RheSwgQXByaWwgMTUsIDIwMTAgMTI6MjQgQU0NClN1YmplY3Q6IFJl OiBbRGltZV0gTkFQVFIgZml4IGZvciAzNTg4YmlzDQoNCg0KSGkgUWluLA0KDQpPbiBBcHIgMTQs IDIwMTAsIGF0IDU6NDcgQU0sIFFpbiBXdSB3cm90ZToNCg0KPiBIaSwNCj4gU29ycnkgZm9yIG15 IGxhdGUgcmVwbHkuDQo+IEdvIHRocm91Z2ggdGhlIHByb3Bvc2VkIENoYW5nZXMgdG8gdGhlIGJp cyB2ZXJzaW9uLg0KPiBJIGZvdW5kICAiZGlhbWV0ZXIudGxzIiBhcyB0aGUgc3VwcG9ydGVkIGFw cGxpY2F0aW9uIHByb3RvY29sIGluIHRoZSAqRklSU1QgQ0hBTkdFKiBpcyBzdGlsbCB1c2VkIHRo ZXJlDQo+IHdoaWNoIGlzIG5vdCBjb25zaXN0ZW50IHdpdGggImRpYW1ldGVyLnRscy50Y3AiIHNw ZWNpZmllZCBpbiB0aGUgKlNFQ09ORCBDSEFOR0UqLg0KPiAgDQo+IEFsc28gc29tZSBxdWVzdGlv bnMgdG8gdGhlIGNoYW5nZXM6DQo+IDEuIElmIHRoZSBEaWFtZXRlciBzZXJ2ZXIgaW5kaWNhdGVz IHRvIHRoZSBEaWFtZXRlciBjbGllbnQgdGhhdCBpdCBzdXBwb3J0IGJvdGggVENQIGFuZCBUTFMv VENQDQo+ICAgYW5kIHRoZSBEaWFtZXRlciBjbGllbnQgYWxzbyBzdXBwb3J0IGJvdGgsIHdoZXRo ZXIgdGhlIERpYW1ldGVyIGNsaWVudCBjYW4gc3RpbGwgY2hvb3NlIFRDUCBhcyB0cmFuc3BvcnQN Cj4gICBwcm90Y29sPyBJbiBvdGhlciB3b3JkcywgaW4gd2hpY2ggY29uZGl0aW9uIGRvZXMgdGhl IGNsaWVudCBjaG9vc2UgVENQIGFuZCBpbiB3aGljaCBjb25kaXRpb24gZG9lcyB0aGUgY2xpZW50 IGNob29zZSBUTFMvVENQPw0KDQpBbiBvcGVyYXRvciBjYW4gYWN0dWFsbHkgc2V0IHRoZSBwcmVm ZXJlbmNlIHVzaW5nIE5BUFRSIG9yZGVyIGFuZCBwcmVmZXJlbmNlIGZpZWxkcyB3aGVuIGRvaW5n IEROUyBwcm92aXNpb25pbmcuIFNvIHRoZSBtZWNoYW5pc20gaXMgdGhlcmUuDQoNCltRaW5dOiBB Z3JlZSB0aGlzIGlzIGRlcGxveW1lbnQgc3BlY2lmaWMgaXNzdWUuDQoNCj4gb3IgQ2FuIHdlIHNh eSBUTFMvVENQIHRyYW5zcG9ydCBpcyBtb3JlIHJlbGlhYmxlIGFuZCBzZWN1cmUgdGhhbiBUQ1Ag dHJhbnNwb3J0IGZvciBEaWFtZXRlcj8gVGhhdCdzIHdoeSB3ZSBjaG9vc2UgVExTIG92ZXIgVENQ IGluc3RlYWQgb2YgVENQPw0KDQpVcCB0byBhbiBvcGVyYXRvciB0byBzZXQgdGhlIHByZWZlcmVu Y2UuDQoNCltRaW5dOiBBcyBJIGRpc2N1c3NlZCB3aXRoIFZpY3RvciwgSSBidXkgaXQuOi0pDQoN Cj4gMi4gSSBhbSB3b25kZXJpbmcgV2hldGhlciBUTFMvVENQIHRyYW5zcG9ydCBjYW4gd29yayBp biB0aGUgcm9hbWluZyBzY2VuYXJpbz8gSW4gb3JkZXIgd29yZHMsIHdoZXRoZXIgd2UgY2FuDQo+ IGFsbG93IHNldmVyYWwgRGlhbWV0ZXIgcGVlcnMgbG9jYXRlZCBiZXR3ZWVuIERpYW1ldGVyIENs aWVudCBhbmQgRGlhbWV0ZXIgU2VydmVyPyB3aGV0aGVyIFRMUy9UQ1AgY2FuIHdvcmsgYWNyb3Nz IHJlYWxtcz8NCg0KU3VjaCBkZXBsb3ltZW50IGlzc3VlcyBhcmUgdXN1YWxseSBoYW5kbGVkIGJ5 IGUuZy4gYSBjb25zb3J0aXVtIHRoYXQgbWFuZGF0ZXMgdGhlIHVzZSBvZiBEaWFtZXRlciBpbiB0 aGUgZmlyc3QgcGxhY2UuDQoNCltRaW5dOiBPa2F5LCBidXQgYXMgSSBtZW50aW9uZWQgdG8gVmlj dG9yLCB0aGUgb25seSBkaWZmaWN1bHQgZm9yIG1lIGlzIHdoZXRoZXIgVExTL1RDUCB0cmFuc3Bv cnQgd29ya3MgaW4gdGhlIGNhc2Ugd2hlbiB0aGUgaW50ZXJtZWlkYXRlIHBlZXIoZS5nLiwgUHJv eHkpIGRvZXMgbm90IHN1cHBvcnQgVExTL1RDUCBiZXR3ZWVuIHRoZSBjbGllbnQgYW5kIHNlcnZl cj8NCg0KPiAzLldoZW4gdGhlIERpYW1ldGVyIENsaWVudCBjaG9vc2UgVExTL1RDUCBhcyB0cmFu c3BvcnQsIHdoYXQgdHJhbnNwb3J0IHBvcnQgd2lsbCBiZSB1c2VkID8gU2FtZSBhcyBwb3J0IGZv ciBUQ1Agb3IgU0NUUCBvciBub3QgPyBpZiBub3Qsd2hhdCBpcyBpdD8NCg0KV2hlbiB1c2luZyBT VlJzIChpLmUuIGEgTkFQVFIgcG9pbnRzIHRvIGEgU1JWKSwgYW4gb3BlcmF0b3IgY2FuIGRlZmlu ZSB0aGUgdXNlZCBwb3J0IG51bWJlci4gU28sIHRoaXMgY2FuIGFnYWluIGJlIHNvbHZlZCBieSBw cm9wZXIgcHJvdmlzaW9uaW5nLiBBIHByZWRlZmluZWQgcG9ydCBudW1iZXIgY291bGQgYmUgdXNl ZnVsIGJ1dCBpbWhvIHJlYWxseSBub3QgbmVlZGVkLiBUaGUgZHJhZnQgY291bGQgdGhvdWdoIHNh eSBzb21ldGhpbmcgYWJvdXQgdGhpcy4NCg0KW1Fpbl06IEFncmVlLiBUaGFuayBmb3IgeW91ciBj bGFyaWZpY2F0aW9uLg0KDQotIEpvdW5pDQoNCj4gSG9wZSBzb21lYm9keSBjYW4gY2xhcmlmeS4g VGhhbmtzIQ0KPiAgDQo+IFJlZ2FyZHMhDQo+IC1RaW4NCj4gLS0tLS0gT3JpZ2luYWwgTWVzc2Fn ZSAtLS0tLQ0KPiBGcm9tOiBWaWN0b3IgRmFqYXJkbw0KPiBUbzogbGlvbmVsLm1vcmFuZEBvcmFu Z2UtZnRncm91cC5jb20NCj4gQ2M6IE1hcmsuSm9uZXNAYnJpZGdld2F0ZXJzeXN0ZW1zLmNvbSA7 IGRpbWVAaWV0Zi5vcmcNCj4gU2VudDogV2VkbmVzZGF5LCBBcHJpbCAxNCwgMjAxMCAxOjUwIEFN DQo+IFN1YmplY3Q6IFJlOiBbRGltZV0gTkFQVFIgZml4IGZvciAzNTg4YmlzDQo+IA0KPiBMb29r cyBnb29kLiBJJ2xsIHNlbmQgb3V0IGEgYmlzIHZlcnNpb24gd2l0aCB0aGUgY2hhbmdlcyBiZWxv dy4NCj4gDQo+IA0KPiBPbiBUdWUsIEFwciAxMywgMjAxMCBhdCA5OjQ2IEFNLCA8bGlvbmVsLm1v cmFuZEBvcmFuZ2UtZnRncm91cC5jb20+IHdyb3RlOg0KPiBUaHggU+liYXN0aWVuLg0KPiANCj4g U28gdG8gc3VtIHVwLCBhbGwgdGhlIGV4aXN0aW5nIGlzc3VlcyBhcmUgbm93IGNsb3NlZC4NCj4g DQo+IEFueSBvdGhlciBmZWVkYmFjayBmcm9tIHRoZSBXRyBvbiB0aGUgcHJvcG9zZWQgbW9kaWZp Y2F0aW9uPw0KPiANCj4gSGVyZWFmdGVyIHRoZSBtb2RpZmljYXRpb24gcHJvcG9zZWQgYnkgTWFy ayB3aXRoIGNvcnJlY3Rpb25zIGJhc2VkIG9uIHRoZSBhZ3JlZW1lbnQgcmVhY2hlZCBhZnRlciBl bWFpbCBkaXNjdXNzaW9uOg0KPiANCj4gKioqKioqKioqKioqKioqKioqKioqKioqKiBGSVJTVCBD SEFOR0UgKioqKioqKioqKioqKioqKioqKioqKioqKg0KPiANCj4gU2VjdGlvbiA1LjIgRGlhbWV0 ZXIgUGVlciBEaXNjb3ZlcnkNCj4gDQo+ID0+IFJlcGxhY2Ugc3RlcCAyIHdpdGggdGhlIGZvbGxv d2luZyB0ZXh0Og0KPiANCj4gICAyLiAgVGhlIERpYW1ldGVyIGltcGxlbWVudGF0aW9uIHBlcmZv cm1zIGEgTkFQVFIgcXVlcnkgZm9yIGEgc2VydmVyDQo+ICAgICAgIGluIGEgcGFydGljdWxhciBy ZWFsbS4gIFRoZSBEaWFtZXRlciBpbXBsZW1lbnRhdGlvbiBoYXMgdG8ga25vdw0KPiAgICAgICBp biBhZHZhbmNlIHdoaWNoIHJlYWxtIHRvIGxvb2sgZm9yIGEgRGlhbWV0ZXIgYWdlbnQgaW4uICBU aGlzDQo+ICAgICAgIGNvdWxkIGJlIGRlZHVjZWQsIGZvciBleGFtcGxlLCBmcm9tIHRoZSAncmVh bG0nIGluIGEgTkFJIHRoYXQgYQ0KPiAgICAgICBEaWFtZXRlciBpbXBsZW1lbnRhdGlvbiBuZWVk ZWQgdG8gcGVyZm9ybSBhIERpYW1ldGVyIG9wZXJhdGlvbg0KPiAgICAgICBvbi4NCj4gDQo+ICAg ICAgIFRoZSBOQVBUUiB1c2FnZSBpbiBEaWFtZXRlciBmb2xsb3dzIHRoZSBTLU5BUFRSIERERFMg YXBwbGljYXRpb24NCj4gICAgICAgW1JGQzM5NThdIHdoaWNoIG1lYW5zIHRoYXQgdGhlIFNFUlZJ Q0UgZmllbGQgaW5jbHVkZXMgdGFncyBmb3IgdGhlDQo+ICAgICAgIGRlc2lyZWQgYXBwbGljYXRp b24gYW5kIHN1cHBvcnRlZCBhcHBsaWNhdGlvbiBwcm90b2NvbC4NCj4gICAgICAgVGhlIGFwcGxp Y2F0aW9uIHNlcnZpY2UgdGFnIGZvciBhIERpYW1ldGVyIGFwcGxpY2F0aW9uIGlzICdhYWEnIGFu ZA0KPiAgICAgICB0aGUgc3VwcG9ydGVkICBhcHBsaWNhdGlvbiBwcm90b2NvbCB0YWdzIGFyZSAn ZGlhbWV0ZXIudGNwJywNCj4gICAgICAgJ2RpYW1ldGVyLnNjdHAnIG9yICdkaWFtZXRlci50bHMn Lg0KPiANCj4gICAgICAgVGhlIGNsaWVudCBmb2xsb3dzIHRoZSByZXNvbHV0aW9uIHByb2Nlc3Mg ZGVmaW5lZCBieSB0aGUgUy1OQVBUUg0KPiAgICAgICBERERTIFtSRkMzOTU4XSBhcHBsaWNhdGlv biB0byBmaW5kIGEgbWF0Y2hpbmcgU1JWIG9yIEEgcmVjb3JkIG9mDQo+ICAgICAgIGEgc3VpdGFi bGUgcGVlci4gIFRoZSBkb21haW4gc3VmZml4ZXMgaW4gdGhlIE5BUFRSIHJlcGxhY2VtZW50IGZp ZWxkDQo+ICAgICAgIFNIT1VMRCBtYXRjaCB0aGUgZG9tYWluIG9mIHRoZSBvcmlnaW5hbCBxdWVy eS4NCj4gDQo+IA0KPiAqKioqKioqKioqKioqKioqKioqKioqKioqIFNFQ09ORCBDSEFOR0UgKioq KioqKioqKioqKioqKioqKioqKioqKg0KPiANCj4gU2VjdGlvbiAxMS42IE5BUFRSIFNlcnZpY2Ug RmllbGRzDQo+IA0KPiA9PiBSZW5hbWUgdGhpcyBzZWN0aW9uIHRvIFMtTkFQVFIgUGFyYW1ldGVy cyBhbmQgcmVwbGFjZSBjb250ZW50IHdpdGg6DQo+IA0KPiBUaGlzIGRvY3VtZW50IHJlZ2lzdGVy cyBhIFMtTkFQVFIgQXBwbGljYXRpb24gU2VydmljZSBUYWcgdmFsdWUgb2YgImFhYSIuDQo+IA0K PiBUaGlzIGRvY3VtZW50IGFsc28gcmVnaXN0ZXJzIHRoZSBmb2xsb3dpbmcgUy1OQVBUUiBBcHBs aWNhdGlvbiBQcm90b2NvbCBUYWdzOg0KPiANCj4gICBUYWcgICAgICAgICAgICAgICAgfCBQcm90 b2NvbA0KPiAgIC0tLS0tLS0tLS0tLS0tLS0tLS18LS0tLS0tLS0tDQo+ICAgZGlhbWV0ZXIudGNw ICAgICAgIHwgVENQDQo+ICAgZGlhbWV0ZXIuc2N0cCAgICAgIHwgU0NUUA0KPiAgIGRpYW1ldGVy LnRscy50Y3AgICB8IFRMUy9UQ1ANCj4gDQo+ICoqKioqKioqKioqKioqKioqKioqKioqKiogVEhJ UkQgQ0hBTkdFICoqKioqKioqKioqKioqKioqKioqKioqKioqDQo+IA0KPiBBcHBlbmRpeCBCLiAg TkFQVFIgRXhhbXBsZQ0KPiANCj4gPT4gUmVuYW1lIHNlY3Rpb24gdG8gUy1OQVBUUiBFeGFtcGxl IGFuZCBtb2RpZnkgYXMgZm9sbG93cy4NCj4gDQo+ICAgQXMgYW4gZXhhbXBsZSwgY29uc2lkZXIg YSBjbGllbnQgdGhhdCB3aXNoZXMgdG8gcmVzb2x2ZSBhYWE6DQo+ICAgZXhhbXBsZS5jb20uICBU aGUgY2xpZW50IHBlcmZvcm1zIGEgTkFQVFIgcXVlcnkgZm9yIHRoYXQgZG9tYWluLCBhbmQNCj4g ICB0aGUgZm9sbG93aW5nIE5BUFRSIHJlY29yZHMgYXJlIHJldHVybmVkOg0KPiANCj4gIDs7ICAg ICAgICBvcmRlciBwcmVmIGZsYWdzIHNlcnZpY2UgICAgICAgICAgICAgICAgcmVnZXhwIHJlcGxh Y2VtZW50DQo+ICBJTiBOQVBUUiAgNTAgICAgNTAgICAicyIgICAiYWFhOmRpYW1ldGVyLnRscy50 Y3AiICAiIiAgICAgX2RpYW1ldGVyLl90bHMudGNwLmV4YW1wbGUuY29tDQo+ICBJTiBOQVBUUiAg MTAwICAgNTAgICAicyIgICAiYWFhOmRpYW1ldGVyLnRjcCIgICAgICAiIiAgICAgX2RpYW1ldGVy Ll90Y3AuZXhhbXBsZS5jb20NCj4gIElOIE5BUFRSICAxNTAgICA1MCAgICJzIiAgICJhYWE6ZGlh bWV0ZXIuc2N0cCIgICAgICIiICAgICBfZGlhbWV0ZXIuX3NjdHAuZXhhbXBsZS5jb20NCj4gDQo+ ICAgVGhpcyBpbmRpY2F0ZXMgdGhhdCB0aGUgc2VydmVyIHN1cHBvcnRzIFRMUy9UQ1AsIFRDUCBh bmQgU0NUUCBpbiB0aGF0DQo+ICAgb3JkZXIuICBJZiB0aGUgY2xpZW50IHN1cHBvcnRzIFRMUy9U Q1AsIFRMUy9UQ1Agd2lsbCBiZSB1c2VkLCB0YXJnZXRlZCB0byBhDQo+ICAgaG9zdCBkZXRlcm1p bmVkIGJ5IGFuIFNSViBsb29rdXAgb2YgX2RpYW1ldGVyLl90bHMudGNwLmV4YW1wbGUuY29tLiAg VGhhdA0KPiAgIGxvb2t1cCB3b3VsZCByZXR1cm46DQo+IA0KPiAgICA7OyAgICAgICBQcmlvcml0 eSAgV2VpZ2h0ICBQb3J0ICAgIFRhcmdldA0KPiAgICBJTiBTUlYgICAwICAgICAgICAgMSAgICAg ICA1MDYwICAgIHNlcnZlcjEuZXhhbXBsZS5jb20NCj4gICAgSU4gU1JWICAgMCAgICAgICAgIDIg ICAgICAgNTA2MCAgICBzZXJ2ZXIyLmV4YW1wbGUuY29tDQo+IA0KPiA9PmFkZGl0aW9uIG9mIGFu IGV4YW1wbGUgd2l0aCAiYSIgZmxhZyByZXF1aXJlZCBzdWNoIGFzOg0KPiANCj4gIElOIE5BUFRS ICAxNTAgICA1MCAgICJhIiAgICJhYWE6ZGlhbWV0ZXIudGxzLnRjcCIgICIiICAgICBzZXJ2ZXIx LmV4YW1wbGUuY29tDQo+ICBJTiBOQVBUUiAgMTUwICAgNTAgICAiYSIgICAiYWFhOmRpYW1ldGVy LnRscy50Y3AiICAiIiAgICAgc2VydmVyMi5leGFtcGxlLmNvbQ0KPiANCj4gKioqKioqKioqKioq KioqKioqKioqKioqKiBGT1VSVEggQ0hBTkdFICoqKioqKioqKioqKioqKioqKioqKioqKioqDQo+ IA0KPiAxNC4xLiAgTm9ybWF0aXZlIFJlZmVyZW5jZXMNCj4gDQo+ID0+IEFkZCBuZXcgcmVmZXJl bmNlIHRvIFMtTkFQVFIgREREUyBSRkMzOTU4Lg0KPiANCj4gKioqKioqKioqKioqKioqKioqKioq KioqKiBFTkQgT0YgQ0hBTkdFUyAqKioqKioqKioqKioqKioqKioqKioqKg0KPiANCj4gDQo+IA0K PiANCj4gDQo+ID4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+ID4gRGUgOiBTZWJhc3Rp ZW4gRGVjdWdpcyBbbWFpbHRvOnNkZWN1Z2lzQG5pY3QuZ28uanBdDQo+ID4gRW52b3npIDogbWFy ZGkgMTMgYXZyaWwgMjAxMCAwNzoxNA0KPiA+IMAgOiBNYXJrIEpvbmVzDQo+ID4gQ2MgOiBNT1JB TkQgTGlvbmVsIFJELUNPUkUtSVNTOyB2ZjAyMTNAZ21haWwuY29tOyBkaW1lQGlldGYub3JnDQo+ ID4gT2JqZXQgOiBSZTogW0RpbWVdIE5BUFRSIGZpeCBmb3IgMzU4OGJpcw0KPiA+DQo+ID4gSGks DQo+ID4NCj4gPiBJIGFtIGZpbmUgd2l0aCB0aGlzIGFwcHJvYWNoIGFzIHdlbGwuIE15IGluaXRp YWwgaW50ZW50aW9uDQo+ID4gd2FzIGp1c3QgdG8gaGlnaGxpZ2h0IHRoYXQgaGF2aW5nIFRMUyBh dCB0aGUgc2FtZSBsZXZlbCBhcw0KPiA+IFRDUCBhbmQgU0NUUCBpcyB2ZXJ5IGNvbmZ1c2luZy4N Cj4gPiBUaGUgdGFnICJkaWFtZXRlci50bHMudGNwIiBpcyBwZXJmZWN0bHkgZmluZSBmb3IgbWUu IEFuZCBpdA0KPiA+IHdpbGwgYmUgcXVpdGUgZWFzeSB0byBmaWd1cmUgd2hhdCB0byBkbywgc2hv dWxkIChUTFMgb3ZlcikNCj4gPiBTQ1RQIGJlY29tZSBtb3JlIHBvcHVsYXIuDQo+ID4NCj4gPiBC ZXN0IHJlZ2FyZHMsDQo+ID4gU2ViYXN0aWVuLg0KPiA+DQo+ID4gTGUgMTMvMDQvMjAxMCAwNTow OCwgTWFyayBKb25lcyBhIOljcml0IDoNCj4gPiA+DQo+ID4gPiBXb3JrcyBmb3IgbWUuIEkgYXNz dW1lIHdlJ2Qgc3RpbGwga2VlcCAiZGlhbWV0ZXIudGxzLnRjcCINCj4gPiBhcyB0aGUgdGFnDQo+ ID4gPiBmb3JtYXQgc28gdGhhdCAiZGlhbWV0ZXIudGxzLnNjdHAiIGNhbiBiZSB1c2VkIGluIHRo ZQ0KPiA+IHNlcGFyYXRlIGRyYWZ0Lg0KPiA+ID4NCj4gPiA+IE1hcmsNCj4gPiA+DQo+ID4gPiAq RnJvbToqIGxpb25lbC5tb3JhbmRAb3JhbmdlLWZ0Z3JvdXAuY29tDQo+ID4gPiBbbWFpbHRvOmxp b25lbC5tb3JhbmRAb3JhbmdlLWZ0Z3JvdXAuY29tXQ0KPiA+ID4gKlNlbnQ6KiBBcHJpbCAxMiwg MjAxMCAxMTo1OSBBTQ0KPiA+ID4gKlRvOiogdmYwMjEzQGdtYWlsLmNvbTsgc2RlY3VnaXNAbmlj dC5nby5qcA0KPiA+ID4gKkNjOiogTWFyayBKb25lczsgZGltZUBpZXRmLm9yZw0KPiA+ID4gKlN1 YmplY3Q6KiBSRTogW0RpbWVdIE5BUFRSIGZpeCBmb3IgMzU4OGJpcw0KPiA+ID4NCj4gPiA+IEhp LA0KPiA+ID4NCj4gPiA+IFRha2luZyBhY2NvdW50IHRoYXQgdGhpcyB0b3BpYyBjYW1lIHF1aXRl IGxhdGUgaW4gdGhlDQo+ID4gcmV2aXNpb24gcHJvY2Vzcw0KPiA+ID4gYW5kIHRvIG5vdCBkZWxh eSB0aGUgcHVibGljYXRpb24gb2YgdGhlIFJGQzM1ODhiaXMsIHdlIGNvdWxkIG1heWJlDQo+ID4g PiBjb25zaWRlciB0byBhZGRyZXNzIFRMUyBvdmVyIFNDVFAgaW4gYSBzZXBhcmV0ZSBkcmFmdCBp biBhIGxhdHRlcg0KPiA+ID4gcGhhc2UgaWYgdGhlcmUgaXMgYSBXRyBpbnRlcmVzdCBvZiB0aGUg V0cgdG8gc3VwcG9ydCB0aGlzIG9wdGlvbi4NCj4gPiA+DQo+ID4gPiBXb3VsZCBpdCBiZSBhY2Nl cHRhYmxlPw0KPiA+ID4NCj4gPiA+IFJlZ2FyZHMsDQo+ID4gPg0KPiA+ID4gTGlvbmVsDQo+ID4g Pg0KPiA+ID4NCj4gPiA+DQo+ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+ID4gLS0NCj4gPiA+DQo+ID4g PiAgICAgKkRlIDoqIGRpbWUtYm91bmNlc0BpZXRmLm9yZw0KPiA+IFttYWlsdG86ZGltZS1ib3Vu Y2VzQGlldGYub3JnXSAqRGUgbGENCj4gPiA+ICAgICBwYXJ0IGRlKiBWaWN0b3IgRmFqYXJkbw0K PiA+ID4gICAgICpFbnZveekgOiogbHVuZGkgMTIgYXZyaWwgMjAxMCAxNDoyOA0KPiA+ID4gICAg ICrAIDoqIFNlYmFzdGllbiBEZWN1Z2lzDQo+ID4gPiAgICAgKkNjIDoqIE1hcmsgSm9uZXM7IGRp bWVAaWV0Zi5vcmcNCj4gPiA+ICAgICAqT2JqZXQgOiogUmU6IFtEaW1lXSBOQVBUUiBmaXggZm9y IDM1ODhiaXMNCj4gPiA+DQo+ID4gPiAgICAgSGkgU2ViYXN0aWVuLA0KPiA+ID4NCj4gPiA+ICAg ICBPbiBTdW4sIEFwciAxMSwgMjAxMCBhdCA5OjQzIFBNLCBTZWJhc3RpZW4gRGVjdWdpcw0KPiA+ ID4gICAgIDxzZGVjdWdpc0BuaWN0LmdvLmpwIDxtYWlsdG86c2RlY3VnaXNAbmljdC5nby5qcD4+ IHdyb3RlOg0KPiA+ID4NCj4gPiA+ICAgICBIaSwNCj4gPiA+DQo+ID4gPiAgICAgU29ycnkgZm9y IHRoZSBkZWxheSwgSSB3YXMgb24gdmFjYXRpb24uDQo+ID4gPg0KPiA+ID4gICAgIExlIDA5LzA0 LzIwMTAgMDc6MDIsIE1hcmsgSm9uZXMgYSDpY3JpdCA6DQo+ID4gPiAgICAgPiA0KSBBcHBsaWNh dGlvbiBwcm90b2NvbCB0YWcgZm9yIFRMUyBkb2VzIG5vdCBkaWZmZXJlbnRpYXRlDQo+ID4gPiAg ICAgVExTL1RDUCB2cw0KPiA+ID4gICAgID4gVExTL1NDVFAgKFNlYmFzdGlhbikuDQo+ID4gPiAg ICAgPg0KPiA+ID4gICAgID4gQ29uY2x1c2lvbjogTmV3IFRMUyB0YWdzIHByb3Bvc2VkIHRvIFNl YmFzdGlhbi4gU3RpbGwNCj4gPiA+ICAgICA+IG9wZW4uDQo+ID4gPiAgICAgPg0KPiA+ID4NCj4g PiA+ICAgICBJIGFtIHBlcmZlY3RseSBmaW5lIHdpdGggdGhlIHJlc29sdXRpb24geW91IHByb3Bv c2VkLCB0aGFuayB5b3UhDQo+ID4gPg0KPiA+ID4gICAgID4gNSkgTWlzc2luZyByZWYgdG8gVExT L1NDVFAgLSBSRkMzNDM2IChTZWJhc3RpYW4pLg0KPiA+ID4gICAgID4NCj4gPiA+ICAgICA+IENv bmNsdXNpb246IEFkZCB0aGUgbWlzc2luZyByZWZlcmVuY2UgdG8gMzU4OGJpcy4NCj4gPiA+ICAg ICA+IFVucmVsYXRlZCB0byB0aGlzIGZpeCB0aG91Z2guDQo+ID4gPiAgICAgPg0KPiA+ID4gICAg IEkgZ3Vlc3MgdGhpcyByZXNvbHV0aW9uIHdpbGwgcmVxdWlyZSBhIGJpdCBtb3JlDQo+ID4gZmVl ZGJhY2sgZnJvbSB0aGUNCj4gPiA+ICAgICBncm91cCwNCj4gPiA+ICAgICB0aGVyZSBtYXkgYmUg b3RoZXIgd2F5cyB0byBpbXBsZW1lbnQgVExTIG92ZXIgU0NUUC4uLg0KPiA+IENhbiB0aGUgY2hh aXJzDQo+ID4gPiAgICAgZ2l2ZSBkaXJlY3Rpb24gb24gdGhpcyBpc3N1ZT8NCj4gPiA+DQo+ID4g Pg0KPiA+ID4NCj4gPiA+ICAgICBGb3IgYWxsIHByYWN0aWNhbCBwdXJwb3NlLCBpcyB0aGVyZSBy ZWFsbHkgYSBzdHJvbmcgZGVwbG95YWJsZQ0KPiA+ID4gICAgIHJlYXNvbiB0byBzdXBwb3J0IFRM UyBvdmVyIFNDVFAgPyBJJ20ganVzdCBoZXNpdGFudCB0byBkZWxheSBiaXMNCj4gPiA+ICAgICBw dWJsaWNhdGlvbiB0byBzdXBwb3J0IGFuIGFjYWRlbWljIGV4ZXJjaXNlLg0KPiA+ID4NCj4gPiA+ ICAgICByZWdhcmRzLA0KPiA+ID4gICAgIHZpY3Rvcg0KPiA+ID4NCj4gPiA+DQo+ID4gPg0KPiA+ ID4gICAgICAgICBUaGFua3MhDQo+ID4gPiAgICAgICAgIFNlYmFzdGllbi4NCj4gPiA+DQo+ID4g PiAgICAgICAgIC0tDQo+ID4gPiAgICAgICAgIFNlYmFzdGllbiBEZWN1Z2lzDQo+ID4gPiAgICAg ICAgIFJlc2VhcmNoIGZlbGxvdw0KPiA+ID4gICAgICAgICBOZXR3b3JrIEFyY2hpdGVjdHVyZSBH cm91cA0KPiA+ID4gICAgICAgICBOSUNUIChuaWN0LmdvLmpwIDxodHRwOi8vbmljdC5nby5qcD4p DQo+ID4gPg0KPiA+DQo+ID4gLS0NCj4gPiBTZWJhc3RpZW4gRGVjdWdpcw0KPiA+IFJlc2VhcmNo IGZlbGxvdw0KPiA+IE5ldHdvcmsgQXJjaGl0ZWN0dXJlIEdyb3VwDQo+ID4gTklDVCAobmljdC5n by5qcCkNCj4gPg0KPiA+DQo+IA0KPiANCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+IERpTUUgbWFpbGluZyBsaXN0DQo+IERpTUVAaWV0Zi5v cmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaW1lDQo+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IERpTUUgbWFpbGlu ZyBsaXN0DQo+IERpTUVAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9kaW1lDQo= From sunseawq@huawei.com Wed Apr 14 21:53:30 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E64D3A6B0E for ; Wed, 14 Apr 2010 21:53:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.716 X-Spam-Level: ** X-Spam-Status: No, score=2.716 tagged_above=-999 required=5 tests=[AWL=-1.334, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, J_CHICKENPOX_83=0.6, J_CHICKENPOX_84=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Y--BPMSkfGJ for ; Wed, 14 Apr 2010 21:53:28 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 51AE43A68C0 for ; Wed, 14 Apr 2010 21:53:27 -0700 (PDT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L0W003RYIWMRC@szxga01-in.huawei.com> for dime@ietf.org; Thu, 15 Apr 2010 12:53:10 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L0W00ACLIWMJB@szxga01-in.huawei.com> for dime@ietf.org; Thu, 15 Apr 2010 12:53:10 +0800 (CST) Received: from w53375 ([10.138.84.35]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L0W002G6IWLQM@szxml06-in.huawei.com> for dime@ietf.org; Thu, 15 Apr 2010 12:53:10 +0800 (CST) Date: Thu, 15 Apr 2010 12:53:09 +0800 From: Qin Wu To: Victor Fajardo Message-id: <006d01cadc57$8bbcc470$23548a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3598 Content-type: multipart/alternative; boundary="Boundary_(ID_dMSq9FK2vFYz2F3tr3fJRw)" X-Priority: 3 X-MSMail-priority: Normal References: <4BC288CB.9030002@nict.go.jp> <4BC3FD95.70803@nict.go.jp> <00f101cadb7c$c59a4590$23548a0a@china.huawei.com> Cc: Mark.Jones@bridgewatersystems.com, dime@ietf.org Subject: Re: [Dime] NAPTR fix for 3588bis X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2010 04:53:30 -0000 This is a multi-part message in MIME format. --Boundary_(ID_dMSq9FK2vFYz2F3tr3fJRw) Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: base64 SGksIFZpY3RvcjoNClRoYW5rIGZvciB5b3VyIHJlcGx5LiBJIGhhdmUgbm8gb2JqZWN0aW9uIGZv ciB0aGVzZSBjaGFuZ2VzIHRvIHRoZSBiaXMgdmVyc2lvbi4NCkp1c3Qgd2FudCB0byBsb29rIGRl ZXBlciBpbnRvIFRMUy9UQ1AgYXMgdHJhbnNwb3J0LiBQbGVhc2Ugc2VlIG15IGZlZWRiYWNrDQpi ZWxvdy4NCg0KUmVnYXJkcyENCi1RaW4NCiAgLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSAN CiAgRnJvbTogVmljdG9yIEZhamFyZG8gDQogIFRvOiBRaW4gV3UgDQogIENjOiBsaW9uZWwubW9y YW5kQG9yYW5nZS1mdGdyb3VwLmNvbSA7IE1hcmsuSm9uZXNAYnJpZGdld2F0ZXJzeXN0ZW1zLmNv bSA7IGRpbWVAaWV0Zi5vcmcgDQogIFNlbnQ6IFdlZG5lc2RheSwgQXByaWwgMTQsIDIwMTAgODo0 MiBQTQ0KICBTdWJqZWN0OiBSZTogW0RpbWVdIE5BUFRSIGZpeCBmb3IgMzU4OGJpcw0KDQoNCiAg SGkgUXVuLA0KDQogIENvbW1lbnRzIGlubGluZToNCg0KDQogIE9uIFR1ZSwgQXByIDEzLCAyMDEw IGF0IDk6NDcgUE0sIFFpbiBXdSA8c3Vuc2Vhd3FAaHVhd2VpLmNvbT4gd3JvdGU6DQoNCiAgICBI aSwNCiAgICBTb3JyeSBmb3IgbXkgbGF0ZSByZXBseS4gDQogICAgR28gdGhyb3VnaCB0aGUgcHJv cG9zZWQgQ2hhbmdlcyB0byB0aGUgYmlzIHZlcnNpb24uIA0KICAgIEkgZm91bmTDgiAgImRpYW1l dGVyLnRscyIgYXPDgiB0aGUgc3VwcG9ydGVkIGFwcGxpY2F0aW9uIHByb3RvY29sIGluIHRoZSAq RklSU1QgQ0hBTkdFKiBpcyBzdGlsbCB1c2VkIHRoZXJlIA0KICAgIHdoaWNoIGlzIG5vdCBjb25z aXN0ZW50IHdpdGggImRpYW1ldGVyLnRscy50Y3Aiw4Igc3BlY2lmaWVkIGluIHRoZSAqU0VDT05E IENIQU5HRSouDQogICAgw4IgDQogICAgQWxzb8OCIHNvbWUgcXVlc3Rpb25zw4IgdG8gdGhlIGNo YW5nZXM6DQogICAgMS4gSWYgdGhlIERpYW1ldGVyIHNlcnZlciBpbmRpY2F0ZXMgdG8gdGhlIERp YW1ldGVyIGNsaWVudCB0aGF0IGl0IHN1cHBvcnQgYm90aCBUQ1AgYW5kIFRMUy9UQ1ANCiAgICDD giAgYW5kIHRoZSBEaWFtZXRlciBjbGllbnQgYWxzbyBzdXBwb3J0IGJvdGgsw4Igd2hldGhlciB0 aGUgRGlhbWV0ZXIgY2xpZW50IGNhbiBzdGlsbCBjaG9vc2XDgiBUQ1AgYXMgdHJhbnNwb3J0DQog ICAgw4IgIHByb3Rjb2w/w4IgSW4gb3RoZXIgd29yZHMsw4IgaW4gd2hpY2ggY29uZGl0aW9uw4Ig ZG9lcyB0aGUgY2xpZW50IGNob29zZSBUQ1AgYW5kw4IgaW4gd2hpY2ggY29uZGl0aW9uw4IgZG9l cyB0aGUgY2xpZW50IGNob29zZSBUTFMvVENQPw0KDQoNCiAgVGhhdCBkZXBlbmRzIG9uIHRoZSBz ZWN1cml0eSBwb2xpY3kgZHVyaW5nIGRlcGxveW1lbnQgb2YgdGhlIGRpYW1ldGVyIG5vZGUuIEl0 cyBub3Qgc29tZXRoaW5nIHRoYXQgdGhlIGRvY3VtZW50IHNob3VsZCBzcGVjaWZ5LiANCg0KICBb UWluXTogSSBhZ3JlZSB0aGlzIGlzIGRlcGxveW1lbnQgc3BlY2lmaWMgaXNzdWUsIGFjdHVhbGx5 IG15IGludGVudGlvbiBpcyB0byB0cnkgdG8gZmlndXJlIG91dCBob3cgbWFueSBjcml0ZXJpYWxz IGZvciBjaG9vc2luZyBkaWZmZXJlbnQgdHJhbnNwb3J0IGZvciBEaWFtZXRlci4NCg0KICDDgiAN CiAgICBvcsOCIENhbiB3ZSBzYXkgVExTL1RDUCB0cmFuc3BvcnQgaXMgbW9yZSByZWxpYWJsZcOC IGFuZCBzZWN1cmUgdGhhbiBUQ1DDgiB0cmFuc3BvcnQgZm9yIERpYW1ldGVyPyBUaGF0J3Mgd2h5 IHdlIGNob29zZSBUTFMgb3ZlciBUQ1AgaW5zdGVhZCBvZiBUQ1A/DQoNCg0KICBJJ20gbm90IGV4 YWN0bHkgc3VyZSB3aGF0IHlvdSBtZWFuIGhlcmUuIEFkZGl0aW9uYWwgc2VjdXJpdHkgd291bGQg YmUgdGhlIG9ubHkgY3JpdGVyaWEgZm9yIHVzaW5nIFRMUy9UQ1AuDQoNCiAgW1Fpbl06IFRoYXQn cyB3aGF0IEkgdHJ5IHRvIGFuc3dlciBieSBteXNlbGYgaW4gcmVzcG9uc2UgdG8gd2hhdCB0cmFu c3BvcnQgcHJvdG9jb2wgd2lsbCBiZSBjaG9zZW4uIDotKSBCdXQgSSBzdGlsbCB3YW50IHRvIGZp Z3VyZSBvdXQgd2hhdCB0aGUgbGltaXRhdGlvbnMgb2YgY2hvb3NpbmcgVExTL1RDUCBpcy4NCiAg SW4gdGhhdCBjYXNlLCB3aGVuIERpYW1ldGVyIENsaWVudCBzdXBwb3J0IGJvdGggVENQIGFuZCBU TFMvVENQLCB0aGUgRGlhbWV0ZXIgQ2xpZW50IG1heSBzdGlsbCBjaG9vc2UgVENQIGFzIHRyYW5z cG9ydC4gQW55d2F5IGl0IGlzIGp1c3QgZGVwbG95bWVudCBzcGVjaWZpYyBpc3N1ZSBhbmQgZGVw ZW5kDQogIG9uIHRoZSBvcGVyYXRvcidzIG93biBjaG9pY2UuDQoNCiAgw4IgDQogICAgMi4gSSBh bSB3b25kZXJpbmcgV2hldGhlciBUTFMvVENQIHRyYW5zcG9ydCBjYW4gd29yayBpbiB0aGUgcm9h bWluZyBzY2VuYXJpbz8gSW4gb3JkZXIgd29yZHMsIHdoZXRoZXIgd2UgY2FuIA0KICAgIGFsbG93 IHNldmVyYWwgRGlhbWV0ZXIgcGVlcnMgbG9jYXRlZCBiZXR3ZWVuIERpYW1ldGVyIENsaWVudCBh bmQgRGlhbWV0ZXIgU2VydmVyPyB3aGV0aGVyIFRMUy9UQ1AgY2FuIHdvcmsgYWNyb3NzIHJlYWxt cz8NCg0KDQogIEhtbW0gLi4uIEkgdGhpbmsgeW91ciBmb3JnZXR0aW5nIHRoZSBmYWN0IHRoYXQg ZGlhbWV0ZXIgdHJhbnNwb3J0IGFyZSBwZWVyaW5nIHRyYW5zcG9ydHMsIGkuZS4gdHJhbnNwb3J0 IGNvbm5lY3Rpb25zIGFyZSBuZWdvdGlhdGVkL2NvbmZpZ3VyZWQgb24gYSBwZXIgcGVlciBjb25u ZWN0aW9uIGJhc2lzLiBTbyB0aGUgcXVlc3Rpb24gZG9lcyBub3Qgc2VlbSB0byBtYWtlIHNlbnNl IHRvIG1lLg0KDQogIFtRaW5dOiBZb3UgZ2V0IHRvIHRoZSBwb2ludC4gRGlhbWV0ZXIgdHJhbnNw b3J0IGlzIHBlZXJpbmcgdHJhbnNwb3J0LiBJIGJ1eSBpdC4gQnV0IHN1cHBvc2UgRGlhbWV0ZXIg d29ya3MgYWNyb3NzIHR3byByZWFsbXMsIHRoZXJlIGFyZSBvbmUgRGlhbWV0ZXIgcGVlciBBIHdp dGhvdXQgVExTIHN1cHBvcnQgYmV0d2VlbiBEaWFtZXRlciBDbGllbnQgYW5kIERpYW1ldGVyIFNl cnZlciwgYWxzbyBib3RoIERpYW1ldGVyIENsaWVudCBhbmQgRGlhbWV0ZXIgU2VydmVyIHN1cHBv cnQgVExTL1RDUCB0cmFuc3BvcnQsIENhbiBEaWFtZXRlciBDbGllbnQgY2hvb3NlIFRMUy9UQ1Ag YXMgdHJhbnNwb3J0DQogIGJldHdlZW4gaXRzZWxmIGFuZCBEaWFtZXRlciBTZXJ2ZXI/IFRoYXQn cyB0aGUgb25seSBkaWZmaWN1bHQgSSBoYXZlLg0KDQogIMOCIA0KICAgIDMuV2hlbsOCIHRoZSBE aWFtZXRlcsOCIENsaWVudCBjaG9vc2UgVExTL1RDUCBhcyB0cmFuc3BvcnQsIHdoYXQgdHJhbnNw b3J0IHBvcnQgd2lsbCBiZSB1c2Vkw4IgPyBTYW1lIGFzIHBvcnQgZm9yIFRDUCBvciBTQ1RQIG9y IG5vdCA/IGlmIG5vdCx3aGF0IGlzIGl0Pw0KDQoNCiAgVExTL1RDUCBpcyBnb2luZyB0byBiZSBv biBhIGRpZmZlcmVudCBwb3J0IHRoYW4ganVzdCBwbGFpbiBUQ1AuIFBvcnQgYXNzaWdubWVudHMg Zm9yIFRDUCBpcyBpbiB0byBjdXJyZW50IGRvYyB3aGlsZSBUTFMgaXMgc3RpbGwgdG8gYmUgYWxs b2NhdGVkLg0KDQogIFtRaW5dOiBJIHRoaW5rIGl0IGlzIGJldHRlciB0byBjaG9vc2UgdGhlIHNh bWUgcG9ydCBudW1iZXIgZm9yIHRyYW5zcG9ydCBsaWtlIDM4NjgsIGluIHRoYXQgd2F5LCBpdCBp cyBlYXN5IHRvIGZpbHRlciBEaWFtZXRlciBwcm90b2NvbCB3aGVuIGNhcHR1cmluZy4gQnV0IHRo YXQgaXMgbm90IGltcG9ydGFudCBhbnkgbW9yZS4NCg0KICByZWdhcmRzLA0KICB2aWN0b3INCg0K DQogIMOCIA0KICAgIEhvcGUgc29tZWJvZHkgY2FuIGNsYXJpZnkuIFRoYW5rcyENCiAgICDDgiAN CiAgICBSZWdhcmRzIQ0KICAgIC1RaW4NCiAgICAgIC0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0t LS0gDQogICAgICBGcm9tOiBWaWN0b3IgRmFqYXJkbyANCiAgICAgIFRvOiBsaW9uZWwubW9yYW5k QG9yYW5nZS1mdGdyb3VwLmNvbSANCiAgICAgIENjOiBNYXJrLkpvbmVzQGJyaWRnZXdhdGVyc3lz dGVtcy5jb20gOyBkaW1lQGlldGYub3JnIA0KICAgICAgU2VudDogV2VkbmVzZGF5LCBBcHJpbCAx NCwgMjAxMCAxOjUwIEFNDQogICAgICBTdWJqZWN0OiBSZTogW0RpbWVdIE5BUFRSIGZpeCBmb3Ig MzU4OGJpcw0KDQoNCiAgICAgIExvb2tzIGdvb2QuIEknbGwgc2VuZCBvdXQgYSBiaXMgdmVyc2lv biB3aXRoIHRoZSBjaGFuZ2VzIGJlbG93Lg0KDQoNCg0KICAgICAgT24gVHVlLCBBcHIgMTMsIDIw MTAgYXQgOTo0NiBBTSwgPGxpb25lbC5tb3JhbmRAb3JhbmdlLWZ0Z3JvdXAuY29tPiB3cm90ZToN Cg0KICAgICAgICBUaHggU8ODwqliYXN0aWVuLg0KDQogICAgICAgIFNvIHRvIHN1bSB1cCwgYWxs IHRoZSBleGlzdGluZyBpc3N1ZXMgYXJlIG5vdyBjbG9zZWQuDQoNCiAgICAgICAgQW55IG90aGVy IGZlZWRiYWNrIGZyb20gdGhlIFdHIG9uIHRoZSBwcm9wb3NlZCBtb2RpZmljYXRpb24/DQoNCiAg ICAgICAgSGVyZWFmdGVyIHRoZSBtb2RpZmljYXRpb24gcHJvcG9zZWQgYnkgTWFyayB3aXRoIGNv cnJlY3Rpb25zIGJhc2VkIG9uIHRoZSBhZ3JlZW1lbnQgcmVhY2hlZCBhZnRlciBlbWFpbCBkaXNj dXNzaW9uOg0KDQogICAgICAgICoqKioqKioqKioqKioqKioqKioqKioqKiogRklSU1QgQ0hBTkdF ICoqKioqKioqKioqKioqKioqKioqKioqKioNCg0KICAgICAgICBTZWN0aW9uIDUuMiBEaWFtZXRl ciBQZWVyIERpc2NvdmVyeQ0KDQogICAgICAgID0+IFJlcGxhY2Ugc3RlcCAyIHdpdGggdGhlIGZv bGxvd2luZyB0ZXh0Og0KDQogICAgICAgIMOCICAyLiDDgiBUaGUgRGlhbWV0ZXIgaW1wbGVtZW50 YXRpb24gcGVyZm9ybXMgYSBOQVBUUiBxdWVyeSBmb3IgYSBzZXJ2ZXINCiAgICAgICAgw4IgIMOC ICDDgiAgaW4gYSBwYXJ0aWN1bGFyIHJlYWxtLiDDgiBUaGUgRGlhbWV0ZXIgaW1wbGVtZW50YXRp b24gaGFzIHRvIGtub3cNCiAgICAgICAgw4IgIMOCICDDgiAgaW4gYWR2YW5jZSB3aGljaCByZWFs bSB0byBsb29rIGZvciBhIERpYW1ldGVyIGFnZW50IGluLiDDgiBUaGlzDQogICAgICAgIMOCICDD giAgw4IgIGNvdWxkIGJlIGRlZHVjZWQsIGZvciBleGFtcGxlLCBmcm9tIHRoZSAncmVhbG0nIGlu IGEgTkFJIHRoYXQgYQ0KICAgICAgICDDgiAgw4IgIMOCICBEaWFtZXRlciBpbXBsZW1lbnRhdGlv biBuZWVkZWQgdG8gcGVyZm9ybSBhIERpYW1ldGVyIG9wZXJhdGlvbg0KICAgICAgICDDgiAgw4Ig IMOCICBvbi4NCg0KICAgICAgICDDgiAgw4IgIMOCICBUaGUgTkFQVFIgdXNhZ2UgaW4gRGlhbWV0 ZXIgZm9sbG93cyB0aGUgUy1OQVBUUiBERERTIGFwcGxpY2F0aW9uDQogICAgICAgIMOCICDDgiAg w4IgIFtSRkMzOTU4XSB3aGljaCBtZWFucyB0aGF0IHRoZSBTRVJWSUNFIGZpZWxkIGluY2x1ZGVz IHRhZ3MgZm9yIHRoZQ0KICAgICAgICDDgiAgw4IgIMOCICBkZXNpcmVkIGFwcGxpY2F0aW9uIGFu ZCBzdXBwb3J0ZWQgYXBwbGljYXRpb24gcHJvdG9jb2wuDQogICAgICAgIMOCICDDgiAgw4IgIFRo ZSBhcHBsaWNhdGlvbiBzZXJ2aWNlIHRhZyBmb3IgYSBEaWFtZXRlciBhcHBsaWNhdGlvbiBpcyAn YWFhJyBhbmQNCiAgICAgICAgw4IgIMOCICDDgiAgdGhlIHN1cHBvcnRlZCDDgiBhcHBsaWNhdGlv biBwcm90b2NvbCB0YWdzIGFyZSAnZGlhbWV0ZXIudGNwJywNCiAgICAgICAgw4IgIMOCICDDgiAg J2RpYW1ldGVyLnNjdHAnIG9yICdkaWFtZXRlci50bHMnLg0KDQogICAgICAgIMOCICDDgiAgw4Ig IFRoZSBjbGllbnQgZm9sbG93cyB0aGUgcmVzb2x1dGlvbiBwcm9jZXNzIGRlZmluZWQgYnkgdGhl IFMtTkFQVFINCiAgICAgICAgw4IgIMOCICDDgiAgREREUyBbUkZDMzk1OF0gYXBwbGljYXRpb24g dG8gZmluZCBhIG1hdGNoaW5nIFNSViBvciBBIHJlY29yZCBvZg0KICAgICAgICDDgiAgw4IgIMOC ICBhIHN1aXRhYmxlIHBlZXIuIMOCIFRoZSBkb21haW4gc3VmZml4ZXMgaW4gdGhlIE5BUFRSIHJl cGxhY2VtZW50IGZpZWxkDQogICAgICAgIMOCICDDgiAgw4IgIFNIT1VMRCBtYXRjaCB0aGUgZG9t YWluIG9mIHRoZSBvcmlnaW5hbCBxdWVyeS4NCg0KDQogICAgICAgICoqKioqKioqKioqKioqKioq KioqKioqKiogU0VDT05EIENIQU5HRSAqKioqKioqKioqKioqKioqKioqKioqKioqDQoNCiAgICAg ICAgU2VjdGlvbiAxMS42IE5BUFRSIFNlcnZpY2UgRmllbGRzDQoNCiAgICAgICAgPT4gUmVuYW1l IHRoaXMgc2VjdGlvbiB0byBTLU5BUFRSIFBhcmFtZXRlcnMgYW5kIHJlcGxhY2UgY29udGVudCB3 aXRoOg0KDQogICAgICAgIFRoaXMgZG9jdW1lbnQgcmVnaXN0ZXJzIGEgUy1OQVBUUiBBcHBsaWNh dGlvbiBTZXJ2aWNlIFRhZyB2YWx1ZSBvZiAiYWFhIi4NCg0KICAgICAgICBUaGlzIGRvY3VtZW50 IGFsc28gcmVnaXN0ZXJzIHRoZSBmb2xsb3dpbmcgUy1OQVBUUiBBcHBsaWNhdGlvbiBQcm90b2Nv bCBUYWdzOg0KDQoNCiAgICAgICAgw4IgIFRhZyDDgiAgw4IgIMOCICDDgiAgw4IgIMOCICDDgiAg w4IgfCBQcm90b2NvbA0KICAgICAgICDDgiAgLS0tLS0tLS0tLS0tLS0tLS0tLXwtLS0tLS0tLS0N CiAgICAgICAgw4IgIGRpYW1ldGVyLnRjcCDDgiAgw4IgIMOCICB8IFRDUA0KICAgICAgICDDgiAg ZGlhbWV0ZXIuc2N0cCDDgiAgw4IgIMOCIHwgU0NUUA0KICAgICAgICDDgiAgZGlhbWV0ZXIudGxz LnRjcCDDgiAgfCBUTFMvVENQDQoNCg0KICAgICAgICAqKioqKioqKioqKioqKioqKioqKioqKioq IFRISVJEIENIQU5HRSAqKioqKioqKioqKioqKioqKioqKioqKioqKg0KDQogICAgICAgIEFwcGVu ZGl4IEIuIMOCIE5BUFRSIEV4YW1wbGUNCg0KICAgICAgICA9PiBSZW5hbWUgc2VjdGlvbiB0byBT LU5BUFRSIEV4YW1wbGUgYW5kIG1vZGlmeSBhcyBmb2xsb3dzLg0KDQogICAgICAgIMOCICBBcyBh biBleGFtcGxlLCBjb25zaWRlciBhIGNsaWVudCB0aGF0IHdpc2hlcyB0byByZXNvbHZlIGFhYToN CiAgICAgICAgw4IgIGV4YW1wbGUuY29tLiDDgiBUaGUgY2xpZW50IHBlcmZvcm1zIGEgTkFQVFIg cXVlcnkgZm9yIHRoYXQgZG9tYWluLCBhbmQNCiAgICAgICAgw4IgIHRoZSBmb2xsb3dpbmcgTkFQ VFIgcmVjb3JkcyBhcmUgcmV0dXJuZWQ6DQoNCiAgICAgICAgw4IgOzsgw4IgIMOCICDDgiAgw4Ig b3JkZXIgcHJlZiBmbGFncyBzZXJ2aWNlIMOCICDDgiAgw4IgIMOCICDDgiAgw4IgIMOCICDDgiBy ZWdleHAgcmVwbGFjZW1lbnQNCiAgICAgICAgw4IgSU4gTkFQVFIgw4IgNTAgw4IgIMOCIDUwIMOC ICAicyIgw4IgICJhYWE6ZGlhbWV0ZXIudGxzLnRjcCIgw4IgIiIgw4IgIMOCICBfZGlhbWV0ZXIu X3Rscy50Y3AuZXhhbXBsZS5jb20NCiAgICAgICAgw4IgSU4gTkFQVFIgw4IgMTAwIMOCICA1MCDD giAgInMiIMOCICAiYWFhOmRpYW1ldGVyLnRjcCIgw4IgIMOCICDDgiAiIiDDgiAgw4IgIF9kaWFt ZXRlci5fdGNwLmV4YW1wbGUuY29tDQogICAgICAgIMOCIElOIE5BUFRSIMOCIDE1MCDDgiAgNTAg w4IgICJzIiDDgiAgImFhYTpkaWFtZXRlci5zY3RwIiDDgiAgw4IgICIiIMOCICDDgiAgX2RpYW1l dGVyLl9zY3RwLmV4YW1wbGUuY29tDQoNCiAgICAgICAgw4IgIFRoaXMgaW5kaWNhdGVzIHRoYXQg dGhlIHNlcnZlciBzdXBwb3J0cyBUTFMvVENQLCBUQ1AgYW5kIFNDVFAgaW4gdGhhdA0KICAgICAg ICDDgiAgb3JkZXIuIMOCIElmIHRoZSBjbGllbnQgc3VwcG9ydHMgVExTL1RDUCwgVExTL1RDUCB3 aWxsIGJlIHVzZWQsIHRhcmdldGVkIHRvIGENCiAgICAgICAgw4IgIGhvc3QgZGV0ZXJtaW5lZCBi eSBhbiBTUlYgbG9va3VwIG9mIF9kaWFtZXRlci5fdGxzLnRjcC5leGFtcGxlLmNvbS4gw4IgVGhh dA0KICAgICAgICDDgiAgbG9va3VwIHdvdWxkIHJldHVybjoNCg0KICAgICAgICDDgiAgw4IgOzsg w4IgIMOCICDDgiAgUHJpb3JpdHkgw4IgV2VpZ2h0IMOCIFBvcnQgw4IgIMOCIFRhcmdldA0KICAg ICAgICDDgiAgw4IgSU4gU1JWIMOCICAwIMOCICDDgiAgw4IgIMOCICAxIMOCICDDgiAgw4IgIDUw NjAgw4IgIMOCIHNlcnZlcjEuZXhhbXBsZS5jb20NCiAgICAgICAgw4IgIMOCIElOIFNSViDDgiAg MCDDgiAgw4IgIMOCICDDgiAgMiDDgiAgw4IgIMOCICA1MDYwIMOCICDDgiBzZXJ2ZXIyLmV4YW1w bGUuY29tDQoNCiAgICAgICAgPT5hZGRpdGlvbiBvZiBhbiBleGFtcGxlIHdpdGggImEiIGZsYWcg cmVxdWlyZWQgc3VjaCBhczoNCg0KICAgICAgICDDgiBJTiBOQVBUUiDDgiAxNTAgw4IgIDUwIMOC ICAiYSIgw4IgICJhYWE6ZGlhbWV0ZXIudGxzLnRjcCIgw4IgIiIgw4IgIMOCICBzZXJ2ZXIxLmV4 YW1wbGUuY29tDQogICAgICAgIMOCIElOIE5BUFRSIMOCIDE1MCDDgiAgNTAgw4IgICJhIiDDgiAg ImFhYTpkaWFtZXRlci50bHMudGNwIiDDgiAiIiDDgiAgw4IgIHNlcnZlcjIuZXhhbXBsZS5jb20N Cg0KICAgICAgICAqKioqKioqKioqKioqKioqKioqKioqKioqIEZPVVJUSCBDSEFOR0UgKioqKioq KioqKioqKioqKioqKioqKioqKioNCg0KICAgICAgICAxNC4xLiDDgiBOb3JtYXRpdmUgUmVmZXJl bmNlcw0KDQogICAgICAgID0+IEFkZCBuZXcgcmVmZXJlbmNlIHRvIFMtTkFQVFIgREREUyBSRkMz OTU4Lg0KDQogICAgICAgICoqKioqKioqKioqKioqKioqKioqKioqKiogRU5EIE9GIENIQU5HRVMg KioqKioqKioqKioqKioqKioqKioqKioNCg0KDQoNCg0KDQogICAgICAgID4gLS0tLS1NZXNzYWdl IGQnb3JpZ2luZS0tLS0tDQogICAgICAgID4gRGUgOiBTZWJhc3RpZW4gRGVjdWdpcyBbbWFpbHRv OnNkZWN1Z2lzQG5pY3QuZ28uanBdDQogICAgICAgID4gRW52b3nDg8KpIDogbWFyZGkgMTMgYXZy aWwgMjAxMCAwNzoxNA0KICAgICAgICA+IMOD4oKsIDogTWFyayBKb25lcw0KICAgICAgICA+IENj IDogTU9SQU5EIExpb25lbCBSRC1DT1JFLUlTUzsgdmYwMjEzQGdtYWlsLmNvbTsgZGltZUBpZXRm Lm9yZw0KDQogICAgICAgID4gT2JqZXQgOiBSZTogW0RpbWVdIE5BUFRSIGZpeCBmb3IgMzU4OGJp cw0KICAgICAgICA+DQogICAgICAgID4gSGksDQogICAgICAgID4NCiAgICAgICAgPiBJIGFtIGZp bmUgd2l0aCB0aGlzIGFwcHJvYWNoIGFzIHdlbGwuIE15IGluaXRpYWwgaW50ZW50aW9uDQogICAg ICAgID4gd2FzIGp1c3QgdG8gaGlnaGxpZ2h0IHRoYXQgaGF2aW5nIFRMUyBhdCB0aGUgc2FtZSBs ZXZlbCBhcw0KICAgICAgICA+IFRDUCBhbmQgU0NUUCBpcyB2ZXJ5IGNvbmZ1c2luZy4NCiAgICAg ICAgPiBUaGUgdGFnICJkaWFtZXRlci50bHMudGNwIiBpcyBwZXJmZWN0bHkgZmluZSBmb3IgbWUu IEFuZCBpdA0KICAgICAgICA+IHdpbGwgYmUgcXVpdGUgZWFzeSB0byBmaWd1cmUgd2hhdCB0byBk bywgc2hvdWxkIChUTFMgb3ZlcikNCiAgICAgICAgPiBTQ1RQIGJlY29tZSBtb3JlIHBvcHVsYXIu DQogICAgICAgID4NCiAgICAgICAgPiBCZXN0IHJlZ2FyZHMsDQogICAgICAgID4gU2ViYXN0aWVu Lg0KICAgICAgICA+DQogICAgICAgID4gTGUgMTMvMDQvMjAxMCAwNTowOCwgTWFyayBKb25lcyBh IMODwqljcml0IDoNCiAgICAgICAgPiA+DQogICAgICAgID4gPiBXb3JrcyBmb3IgbWUuIEkgYXNz dW1lIHdlJ2Qgc3RpbGwga2VlcCAiZGlhbWV0ZXIudGxzLnRjcCINCiAgICAgICAgPiBhcyB0aGUg dGFnDQogICAgICAgID4gPiBmb3JtYXQgc28gdGhhdCAiZGlhbWV0ZXIudGxzLnNjdHAiIGNhbiBi ZSB1c2VkIGluIHRoZQ0KICAgICAgICA+IHNlcGFyYXRlIGRyYWZ0Lg0KICAgICAgICA+ID4NCiAg ICAgICAgPiA+IE1hcmsNCiAgICAgICAgPiA+DQogICAgICAgID4gPiAqRnJvbToqIGxpb25lbC5t b3JhbmRAb3JhbmdlLWZ0Z3JvdXAuY29tDQogICAgICAgID4gPiBbbWFpbHRvOmxpb25lbC5tb3Jh bmRAb3JhbmdlLWZ0Z3JvdXAuY29tXQ0KICAgICAgICA+ID4gKlNlbnQ6KiBBcHJpbCAxMiwgMjAx MCAxMTo1OSBBTQ0KICAgICAgICA+ID4gKlRvOiogdmYwMjEzQGdtYWlsLmNvbTsgc2RlY3VnaXNA bmljdC5nby5qcA0KICAgICAgICA+ID4gKkNjOiogTWFyayBKb25lczsgZGltZUBpZXRmLm9yZw0K ICAgICAgICA+ID4gKlN1YmplY3Q6KiBSRTogW0RpbWVdIE5BUFRSIGZpeCBmb3IgMzU4OGJpcw0K ICAgICAgICA+ID4NCiAgICAgICAgPiA+IEhpLA0KICAgICAgICA+ID4NCiAgICAgICAgPiA+IFRh a2luZyBhY2NvdW50IHRoYXQgdGhpcyB0b3BpYyBjYW1lIHF1aXRlIGxhdGUgaW4gdGhlDQogICAg ICAgID4gcmV2aXNpb24gcHJvY2Vzcw0KICAgICAgICA+ID4gYW5kIHRvIG5vdCBkZWxheSB0aGUg cHVibGljYXRpb24gb2YgdGhlIFJGQzM1ODhiaXMsIHdlIGNvdWxkIG1heWJlDQogICAgICAgID4g PiBjb25zaWRlciB0byBhZGRyZXNzIFRMUyBvdmVyIFNDVFAgaW4gYSBzZXBhcmV0ZSBkcmFmdCBp biBhIGxhdHRlcg0KICAgICAgICA+ID4gcGhhc2UgaWYgdGhlcmUgaXMgYSBXRyBpbnRlcmVzdCBv ZiB0aGUgV0cgdG8gc3VwcG9ydCB0aGlzIG9wdGlvbi4NCiAgICAgICAgPiA+DQogICAgICAgID4g PiBXb3VsZCBpdCBiZSBhY2NlcHRhYmxlPw0KICAgICAgICA+ID4NCiAgICAgICAgPiA+IFJlZ2Fy ZHMsDQogICAgICAgID4gPg0KICAgICAgICA+ID4gTGlvbmVsDQogICAgICAgID4gPg0KICAgICAg ICA+ID4NCiAgICAgICAgPiA+DQogICAgICAgID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KICAgICAgICA+ID4g LS0NCiAgICAgICAgPiA+DQogICAgICAgID4gPiDDgiAgw4IgICpEZSA6KiBkaW1lLWJvdW5jZXNA aWV0Zi5vcmcNCiAgICAgICAgPiBbbWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZ10gKkRlIGxh DQogICAgICAgID4gPiDDgiAgw4IgIHBhcnQgZGUqIFZpY3RvciBGYWphcmRvDQogICAgICAgID4g PiDDgiAgw4IgICpFbnZvecODwqkgOiogbHVuZGkgMTIgYXZyaWwgMjAxMCAxNDoyOA0KICAgICAg ICA+ID4gw4IgIMOCICAqw4PigqwgOiogU2ViYXN0aWVuIERlY3VnaXMNCiAgICAgICAgPiA+IMOC ICDDgiAgKkNjIDoqIE1hcmsgSm9uZXM7IGRpbWVAaWV0Zi5vcmcNCiAgICAgICAgPiA+IMOCICDD giAgKk9iamV0IDoqIFJlOiBbRGltZV0gTkFQVFIgZml4IGZvciAzNTg4YmlzDQogICAgICAgID4g Pg0KICAgICAgICA+ID4gw4IgIMOCICBIaSBTZWJhc3RpZW4sDQogICAgICAgID4gPg0KICAgICAg ICA+ID4gw4IgIMOCICBPbiBTdW4sIEFwciAxMSwgMjAxMCBhdCA5OjQzIFBNLCBTZWJhc3RpZW4g RGVjdWdpcw0KICAgICAgICA+ID4gw4IgIMOCICA8c2RlY3VnaXNAbmljdC5nby5qcCA8bWFpbHRv OnNkZWN1Z2lzQG5pY3QuZ28uanA+PiB3cm90ZToNCiAgICAgICAgPiA+DQogICAgICAgID4gPiDD giAgw4IgIEhpLA0KICAgICAgICA+ID4NCiAgICAgICAgPiA+IMOCICDDgiAgU29ycnkgZm9yIHRo ZSBkZWxheSwgSSB3YXMgb24gdmFjYXRpb24uDQogICAgICAgID4gPg0KICAgICAgICA+ID4gw4Ig IMOCICBMZSAwOS8wNC8yMDEwIDA3OjAyLCBNYXJrIEpvbmVzIGEgw4PCqWNyaXQgOg0KICAgICAg ICA+ID4gw4IgIMOCICA+IDQpIEFwcGxpY2F0aW9uIHByb3RvY29sIHRhZyBmb3IgVExTIGRvZXMg bm90IGRpZmZlcmVudGlhdGUNCiAgICAgICAgPiA+IMOCICDDgiAgVExTL1RDUCB2cw0KICAgICAg ICA+ID4gw4IgIMOCICA+IFRMUy9TQ1RQIChTZWJhc3RpYW4pLg0KICAgICAgICA+ID4gw4IgIMOC ICA+DQogICAgICAgID4gPiDDgiAgw4IgID4gQ29uY2x1c2lvbjogTmV3IFRMUyB0YWdzIHByb3Bv c2VkIHRvIFNlYmFzdGlhbi4gU3RpbGwNCiAgICAgICAgPiA+IMOCICDDgiAgPiBvcGVuLg0KICAg ICAgICA+ID4gw4IgIMOCICA+DQogICAgICAgID4gPg0KICAgICAgICA+ID4gw4IgIMOCICBJIGFt IHBlcmZlY3RseSBmaW5lIHdpdGggdGhlIHJlc29sdXRpb24geW91IHByb3Bvc2VkLCB0aGFuayB5 b3UhDQogICAgICAgID4gPg0KICAgICAgICA+ID4gw4IgIMOCICA+IDUpIE1pc3NpbmcgcmVmIHRv IFRMUy9TQ1RQIC0gUkZDMzQzNiAoU2ViYXN0aWFuKS4NCiAgICAgICAgPiA+IMOCICDDgiAgPg0K ICAgICAgICA+ID4gw4IgIMOCICA+IENvbmNsdXNpb246IEFkZCB0aGUgbWlzc2luZyByZWZlcmVu Y2UgdG8gMzU4OGJpcy4NCiAgICAgICAgPiA+IMOCICDDgiAgPiBVbnJlbGF0ZWQgdG8gdGhpcyBm aXggdGhvdWdoLg0KICAgICAgICA+ID4gw4IgIMOCICA+DQogICAgICAgID4gPiDDgiAgw4IgIEkg Z3Vlc3MgdGhpcyByZXNvbHV0aW9uIHdpbGwgcmVxdWlyZSBhIGJpdCBtb3JlDQogICAgICAgID4g ZmVlZGJhY2sgZnJvbSB0aGUNCiAgICAgICAgPiA+IMOCICDDgiAgZ3JvdXAsDQogICAgICAgID4g PiDDgiAgw4IgIHRoZXJlIG1heSBiZSBvdGhlciB3YXlzIHRvIGltcGxlbWVudCBUTFMgb3ZlciBT Q1RQLi4uDQogICAgICAgID4gQ2FuIHRoZSBjaGFpcnMNCiAgICAgICAgPiA+IMOCICDDgiAgZ2l2 ZSBkaXJlY3Rpb24gb24gdGhpcyBpc3N1ZT8NCiAgICAgICAgPiA+DQogICAgICAgID4gPg0KICAg ICAgICA+ID4NCiAgICAgICAgPiA+IMOCICDDgiAgRm9yIGFsbCBwcmFjdGljYWwgcHVycG9zZSwg aXMgdGhlcmUgcmVhbGx5IGEgc3Ryb25nIGRlcGxveWFibGUNCiAgICAgICAgPiA+IMOCICDDgiAg cmVhc29uIHRvIHN1cHBvcnQgVExTIG92ZXIgU0NUUCA/IEknbSBqdXN0IGhlc2l0YW50IHRvIGRl bGF5IGJpcw0KICAgICAgICA+ID4gw4IgIMOCICBwdWJsaWNhdGlvbiB0byBzdXBwb3J0IGFuIGFj YWRlbWljIGV4ZXJjaXNlLg0KICAgICAgICA+ID4NCiAgICAgICAgPiA+IMOCICDDgiAgcmVnYXJk cywNCiAgICAgICAgPiA+IMOCICDDgiAgdmljdG9yDQogICAgICAgID4gPg0KICAgICAgICA+ID4N CiAgICAgICAgPiA+DQogICAgICAgID4gPiDDgiAgw4IgIMOCICDDgiAgVGhhbmtzIQ0KICAgICAg ICA+ID4gw4IgIMOCICDDgiAgw4IgIFNlYmFzdGllbi4NCiAgICAgICAgPiA+DQogICAgICAgID4g PiDDgiAgw4IgIMOCICDDgiAgLS0NCiAgICAgICAgPiA+IMOCICDDgiAgw4IgIMOCICBTZWJhc3Rp ZW4gRGVjdWdpcw0KICAgICAgICA+ID4gw4IgIMOCICDDgiAgw4IgIFJlc2VhcmNoIGZlbGxvdw0K ICAgICAgICA+ID4gw4IgIMOCICDDgiAgw4IgIE5ldHdvcmsgQXJjaGl0ZWN0dXJlIEdyb3VwDQog ICAgICAgID4gPiDDgiAgw4IgIMOCICDDgiAgTklDVCAobmljdC5nby5qcCA8aHR0cDovL25pY3Qu Z28uanA+KQ0KICAgICAgICA+ID4NCiAgICAgICAgPg0KICAgICAgICA+IC0tDQogICAgICAgID4g U2ViYXN0aWVuIERlY3VnaXMNCiAgICAgICAgPiBSZXNlYXJjaCBmZWxsb3cNCiAgICAgICAgPiBO ZXR3b3JrIEFyY2hpdGVjdHVyZSBHcm91cA0KICAgICAgICA+IE5JQ1QgKG5pY3QuZ28uanApDQog ICAgICAgID4NCiAgICAgICAgPg0KDQoNCg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCg0KICAg ICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICAg IERpTUUgbWFpbGluZyBsaXN0DQogICAgICBEaU1FQGlldGYub3JnDQoNCiAgICAgIGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGltZQ0KDQoNCg== --Boundary_(ID_dMSq9FK2vFYz2F3tr3fJRw) Content-type: text/html; charset=UTF-8 Content-transfer-encoding: base64 77u/PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u YWwvL0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0 PXV0Zi04IiBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZT4NCjxNRVRBIG5hbWU9R0VORVJBVE9SIGNv bnRlbnQ9Ik1TSFRNTCA4LjAwLjYwMDEuMTg5MDQiPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+ DQo8Qk9EWSBiZ0NvbG9yPSNjY2U4Y2Y+DQo8RElWPkhpLCBWaWN0b3I6PC9ESVY+DQo8RElWPlRo YW5rIGZvciB5b3VyIHJlcGx5LiBJIGhhdmUgbm8gb2JqZWN0aW9uJm5ic3A7Zm9yIHRoZXNlIGNo YW5nZXMgdG8gdGhlIGJpcyANCnZlcnNpb24uPC9ESVY+DQo8RElWPkp1c3QmbmJzcDt3YW50IHRv IGxvb2sgZGVlcGVyIGludG8mbmJzcDtUTFMvVENQIGFzIHRyYW5zcG9ydC4gUGxlYXNlIHNlZSBt eSANCmZlZWRiYWNrPC9ESVY+DQo8RElWPmJlbG93LjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4N CjxESVY+UmVnYXJkcyE8L0RJVj4NCjxESVY+LVFpbjwvRElWPg0KPEJMT0NLUVVPVEUgDQpzdHls ZT0iQk9SREVSLUxFRlQ6ICMwMDAwMDAgMnB4IHNvbGlkOyBQQURESU5HLUxFRlQ6IDVweDsgUEFE RElORy1SSUdIVDogMHB4OyBNQVJHSU4tTEVGVDogNXB4OyBNQVJHSU4tUklHSFQ6IDBweCI+DQog IDxESVYgc3R5bGU9IkZPTlQ6IDlwdCDlrovkvZMiPi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0t LS0gPC9ESVY+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDlwdCDlrovkvZM7IEJBQ0tHUk9VTkQ6ICNl NGU0ZTQ7IGZvbnQtY29sb3I6IGJsYWNrIj48Qj5Gcm9tOjwvQj4gDQogIDxBIHRpdGxlPXZmMDIx M0BnbWFpbC5jb20gaHJlZj0ibWFpbHRvOnZmMDIxM0BnbWFpbC5jb20iPlZpY3RvciBGYWphcmRv PC9BPiANCiAgPC9ESVY+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDlwdCDlrovkvZMiPjxCPlRvOjwv Qj4gPEEgdGl0bGU9c3Vuc2Vhd3FAaHVhd2VpLmNvbSANCiAgaHJlZj0ibWFpbHRvOnN1bnNlYXdx QGh1YXdlaS5jb20iPlFpbiBXdTwvQT4gPC9ESVY+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDlwdCDl rovkvZMiPjxCPkNjOjwvQj4gPEEgdGl0bGU9bGlvbmVsLm1vcmFuZEBvcmFuZ2UtZnRncm91cC5j b20gDQogIGhyZWY9Im1haWx0bzpsaW9uZWwubW9yYW5kQG9yYW5nZS1mdGdyb3VwLmNvbSI+bGlv bmVsLm1vcmFuZEBvcmFuZ2UtZnRncm91cC5jb208L0E+IA0KICA7IDxBIHRpdGxlPU1hcmsuSm9u ZXNAYnJpZGdld2F0ZXJzeXN0ZW1zLmNvbSANCiAgaHJlZj0ibWFpbHRvOk1hcmsuSm9uZXNAYnJp ZGdld2F0ZXJzeXN0ZW1zLmNvbSI+TWFyay5Kb25lc0BicmlkZ2V3YXRlcnN5c3RlbXMuY29tPC9B PiANCiAgOyA8QSB0aXRsZT1kaW1lQGlldGYub3JnIGhyZWY9Im1haWx0bzpkaW1lQGlldGYub3Jn Ij5kaW1lQGlldGYub3JnPC9BPiA8L0RJVj4NCiAgPERJViBzdHlsZT0iRk9OVDogOXB0IOWui+S9 kyI+PEI+U2VudDo8L0I+IFdlZG5lc2RheSwgQXByaWwgMTQsIDIwMTAgODo0MiBQTTwvRElWPg0K ICA8RElWIHN0eWxlPSJGT05UOiA5cHQg5a6L5L2TIj48Qj5TdWJqZWN0OjwvQj4gUmU6IFtEaW1l XSBOQVBUUiBmaXggZm9yIA0KICAzNTg4YmlzPC9ESVY+DQogIDxESVY+PEJSPjwvRElWPkhpIFF1 biw8QlI+PEJSPkNvbW1lbnRzIGlubGluZTo8QlI+PEJSPg0KICA8RElWIGNsYXNzPWdtYWlsX3F1 b3RlPk9uIFR1ZSwgQXByIDEzLCAyMDEwIGF0IDk6NDcgUE0sIFFpbiBXdSA8U1BBTiANCiAgZGly PWx0cj4mbHQ7PEEgDQogIGhyZWY9Im1haWx0bzpzdW5zZWF3cUBodWF3ZWkuY29tIj5zdW5zZWF3 cUBodWF3ZWkuY29tPC9BPiZndDs8L1NQQU4+IA0Kd3JvdGU6PEJSPg0KICA8QkxPQ0tRVU9URSAN CiAgc3R5bGU9IkJPUkRFUi1MRUZUOiByZ2IoMjA0LDIwNCwyMDQpIDFweCBzb2xpZDsgTUFSR0lO OiAwcHQgMHB0IDBwdCAwLjhleDsgUEFERElORy1MRUZUOiAxZXgiIA0KICBjbGFzcz1nbWFpbF9x dW90ZT4NCiAgICA8RElWIGJnY29sb3I9IiNjY2U4Y2YiPg0KICAgIDxESVY+SGksPC9ESVY+DQog ICAgPERJVj5Tb3JyeSBmb3IgbXkgbGF0ZSByZXBseS4gPC9ESVY+DQogICAgPERJVj5HbyB0aHJv dWdoIHRoZSBwcm9wb3NlZCBDaGFuZ2VzIHRvIHRoZSBiaXMgdmVyc2lvbi4gPC9ESVY+DQogICAg PERJVj5JIGZvdW5kw4ImbmJzcDsgImRpYW1ldGVyLnRscyIgYXPDgiZuYnNwO3RoZSBzdXBwb3J0 ZWQgYXBwbGljYXRpb24gDQogICAgcHJvdG9jb2wgaW4gdGhlICpGSVJTVCBDSEFOR0UqIGlzIHN0 aWxsIHVzZWQgdGhlcmUgPC9ESVY+DQogICAgPERJVj53aGljaCBpcyBub3QgY29uc2lzdGVudCB3 aXRoICJkaWFtZXRlci50bHMudGNwIsOCJm5ic3A7c3BlY2lmaWVkIGluIHRoZSANCiAgICAqU0VD T05EIENIQU5HRSouPC9ESVY+DQogICAgPERJVj48Rk9OVCBzaXplPTIgZmFjZT3DpcKu4oC5w6TC veKAnD48L0ZPTlQ+w4ImbmJzcDs8L0RJVj4NCiAgICA8RElWPjxGT05UIHNpemU9MiBmYWNlPcOl wq7igLnDpMK94oCcPjxGT05UIHNpemU9MyANCiAgICBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPkFs c2/DgiZuYnNwO3NvbWUgcXVlc3Rpb25zw4ImbmJzcDt0byB0aGUgDQogICAgY2hhbmdlczo8L0ZP TlQ+PC9GT05UPjwvRElWPg0KICAgIDxESVY+MS4gSWYgdGhlIERpYW1ldGVyIHNlcnZlciBpbmRp Y2F0ZXMgdG8gdGhlIERpYW1ldGVyIGNsaWVudCB0aGF0IGl0IA0KICAgIHN1cHBvcnQgYm90aCBU Q1AgYW5kIFRMUy9UQ1A8L0RJVj4NCiAgICA8RElWPsOCJm5ic3A7IGFuZCB0aGUgRGlhbWV0ZXIg Y2xpZW50IGFsc28gc3VwcG9ydCBib3RoLMOCJm5ic3A7d2hldGhlciB0aGUgDQogICAgRGlhbWV0 ZXIgY2xpZW50IGNhbiBzdGlsbCBjaG9vc2XDgiZuYnNwO1RDUCBhcyB0cmFuc3BvcnQ8L0RJVj4N CiAgICA8RElWPsOCJm5ic3A7IHByb3Rjb2w/w4ImbmJzcDtJbiBvdGhlciB3b3JkcyzDgiZuYnNw O2luIHdoaWNoIA0KICAgIGNvbmRpdGlvbsOCJm5ic3A7ZG9lcyB0aGUgY2xpZW50IGNob29zZSBU Q1AgYW5kw4ImbmJzcDtpbiB3aGljaCANCiAgICBjb25kaXRpb27DgiZuYnNwO2RvZXMgdGhlIGNs aWVudCBjaG9vc2UgVExTL1RDUD88L0RJVj48L0RJVj48L0JMT0NLUVVPVEU+DQogIDxESVY+PEJS PjxCUj5UaGF0IGRlcGVuZHMgb24gdGhlIHNlY3VyaXR5IHBvbGljeSBkdXJpbmcgZGVwbG95bWVu dCBvZiB0aGUgDQogIGRpYW1ldGVyIG5vZGUuIEl0cyBub3Qgc29tZXRoaW5nIHRoYXQgdGhlIGRv Y3VtZW50IHNob3VsZCBzcGVjaWZ5LiA8QlI+PC9ESVY+DQogIDxESVY+W1Fpbl06IEkgYWdyZWUg dGhpcyBpcyBkZXBsb3ltZW50IHNwZWNpZmljIGlzc3VlLCBhY3R1YWxseSBteSANCiAgaW50ZW50 aW9uJm5ic3A7aXMgdG8gdHJ5IHRvIGZpZ3VyZSBvdXQgaG93IG1hbnkgY3JpdGVyaWFscyBmb3Ig Y2hvb3NpbmcgDQogIGRpZmZlcmVudCB0cmFuc3BvcnQgZm9yIERpYW1ldGVyLjwvRElWPg0KICA8 RElWPjxGT05UIHNpemU9MiBmYWNlPeWui+S9kz48L0ZPTlQ+PEJSPsOCJm5ic3A7PC9ESVY+DQog IDxCTE9DS1FVT1RFIA0KICBzdHlsZT0iQk9SREVSLUxFRlQ6IHJnYigyMDQsMjA0LDIwNCkgMXB4 IHNvbGlkOyBNQVJHSU46IDBwdCAwcHQgMHB0IDAuOGV4OyBQQURESU5HLUxFRlQ6IDFleCIgDQog IGNsYXNzPWdtYWlsX3F1b3RlPg0KICAgIDxESVYgYmdjb2xvcj0iI2NjZThjZiI+DQogICAgPERJ Vj5vcsOCJm5ic3A7Q2FuIHdlIHNheSBUTFMvVENQIHRyYW5zcG9ydCBpcyBtb3JlIHJlbGlhYmxl w4ImbmJzcDthbmQgc2VjdXJlIA0KICAgIHRoYW4gVENQw4ImbmJzcDt0cmFuc3BvcnQgZm9yIERp YW1ldGVyPyBUaGF0J3Mgd2h5IHdlIGNob29zZSBUTFMgb3ZlciBUQ1AgDQogICAgaW5zdGVhZCBv ZiBUQ1A/PC9ESVY+PC9ESVY+PC9CTE9DS1FVT1RFPg0KICA8RElWPjxCUj48QlI+SSdtIG5vdCBl eGFjdGx5IHN1cmUgd2hhdCB5b3UgbWVhbiBoZXJlLiBBZGRpdGlvbmFsIHNlY3VyaXR5IA0KICB3 b3VsZCBiZSB0aGUgb25seSBjcml0ZXJpYSBmb3IgdXNpbmcgVExTL1RDUC48L0RJVj4NCiAgPERJ Vj4mbmJzcDs8L0RJVj4NCiAgPERJVj5bUWluXTogVGhhdCdzIHdoYXQgSSB0cnkgdG8gYW5zd2Vy IGJ5IG15c2VsZiBpbiByZXNwb25zZSB0byB3aGF0IA0KICB0cmFuc3BvcnQgcHJvdG9jb2wgd2ls bCBiZSBjaG9zZW4uIDotKSBCdXQgSSBzdGlsbCB3YW50IHRvJm5ic3A7ZmlndXJlIA0KICBvdXQm bmJzcDt3aGF0IHRoZSBsaW1pdGF0aW9ucyBvZiBjaG9vc2luZyBUTFMvVENQIGlzLjwvRElWPg0K ICA8RElWPkluIHRoYXQgY2FzZSwgd2hlbiBEaWFtZXRlciBDbGllbnQgc3VwcG9ydCBib3RoIFRD UCBhbmQgVExTL1RDUCwgdGhlIA0KICBEaWFtZXRlciBDbGllbnQgbWF5IHN0aWxsIGNob29zZSBU Q1AgYXMgdHJhbnNwb3J0LiBBbnl3YXkmbmJzcDtpdCBpcyZuYnNwO2p1c3QgDQogIGRlcGxveW1l bnQgc3BlY2lmaWMgaXNzdWUgYW5kIGRlcGVuZDwvRElWPg0KICA8RElWPm9uIHRoZSBvcGVyYXRv cidzIG93biBjaG9pY2UuPEJSPjxCUj7DgiZuYnNwOzwvRElWPg0KICA8QkxPQ0tRVU9URSANCiAg c3R5bGU9IkJPUkRFUi1MRUZUOiByZ2IoMjA0LDIwNCwyMDQpIDFweCBzb2xpZDsgTUFSR0lOOiAw cHQgMHB0IDBwdCAwLjhleDsgUEFERElORy1MRUZUOiAxZXgiIA0KICBjbGFzcz1nbWFpbF9xdW90 ZT4NCiAgICA8RElWIGJnY29sb3I9IiNjY2U4Y2YiPg0KICAgIDxESVY+Mi4gSSBhbSB3b25kZXJp bmcgV2hldGhlciBUTFMvVENQIHRyYW5zcG9ydCBjYW4gd29yayBpbiB0aGUgcm9hbWluZyANCiAg ICBzY2VuYXJpbz8gSW4gb3JkZXIgd29yZHMsIHdoZXRoZXIgd2UgY2FuIDwvRElWPg0KICAgIDxE SVY+YWxsb3cgc2V2ZXJhbCBEaWFtZXRlciBwZWVycyBsb2NhdGVkIGJldHdlZW4gRGlhbWV0ZXIg Q2xpZW50IGFuZCANCiAgICBEaWFtZXRlciBTZXJ2ZXI/IHdoZXRoZXIgVExTL1RDUCBjYW4gd29y ayBhY3Jvc3MgDQogIHJlYWxtcz88L0RJVj48L0RJVj48L0JMT0NLUVVPVEU+PEZPTlQgc2l6ZT0y IGZhY2U95a6L5L2TPjwvRk9OVD48Rk9OVCBzaXplPTIgDQogIGZhY2U95a6L5L2TPjwvRk9OVD4N CiAgPERJVj48QlI+PEJSPkhtbW0gLi4uIEkgdGhpbmsgeW91ciBmb3JnZXR0aW5nIHRoZSBmYWN0 IHRoYXQgZGlhbWV0ZXIgdHJhbnNwb3J0IA0KICBhcmUgcGVlcmluZyB0cmFuc3BvcnRzLCBpLmUu IHRyYW5zcG9ydCBjb25uZWN0aW9ucyBhcmUgbmVnb3RpYXRlZC9jb25maWd1cmVkIA0KICBvbiBh IHBlciBwZWVyIGNvbm5lY3Rpb24gYmFzaXMuIFNvIHRoZSBxdWVzdGlvbiBkb2VzIG5vdCBzZWVt IHRvIG1ha2Ugc2Vuc2UgdG8gDQogIG1lLjwvRElWPg0KICA8RElWPiZuYnNwOzwvRElWPg0KICA8 RElWPltRaW5dOiBZb3UgZ2V0IHRvIHRoZSBwb2ludC4gRGlhbWV0ZXIgdHJhbnNwb3J0IGlzIHBl ZXJpbmcgdHJhbnNwb3J0LiBJIA0KICBidXkgaXQuIEJ1dCBzdXBwb3NlIERpYW1ldGVyIHdvcmtz IGFjcm9zcyB0d28gcmVhbG1zLCB0aGVyZSBhcmUgb25lIERpYW1ldGVyIA0KICBwZWVyIEEgd2l0 aG91dCBUTFMgc3VwcG9ydCBiZXR3ZWVuIERpYW1ldGVyIENsaWVudCBhbmQgRGlhbWV0ZXIgU2Vy dmVyLCBhbHNvIA0KICBib3RoIERpYW1ldGVyIENsaWVudCBhbmQgRGlhbWV0ZXIgU2VydmVyIHN1 cHBvcnQgVExTL1RDUCB0cmFuc3BvcnQsIENhbiANCiAgRGlhbWV0ZXIgQ2xpZW50IGNob29zZSBU TFMvVENQIGFzIHRyYW5zcG9ydDwvRElWPg0KICA8RElWPmJldHdlZW4gaXRzZWxmIGFuZCBEaWFt ZXRlciBTZXJ2ZXI/IFRoYXQncyB0aGUgb25seSBkaWZmaWN1bHQgSSANCiAgaGF2ZS48QlI+PEJS PsOCJm5ic3A7PC9ESVY+DQogIDxCTE9DS1FVT1RFIA0KICBzdHlsZT0iQk9SREVSLUxFRlQ6IHJn YigyMDQsMjA0LDIwNCkgMXB4IHNvbGlkOyBNQVJHSU46IDBwdCAwcHQgMHB0IDAuOGV4OyBQQURE SU5HLUxFRlQ6IDFleCIgDQogIGNsYXNzPWdtYWlsX3F1b3RlPg0KICAgIDxESVYgYmdjb2xvcj0i I2NjZThjZiI+DQogICAgPERJVj4zLldoZW7DgiZuYnNwO3RoZSBEaWFtZXRlcsOCJm5ic3A7Q2xp ZW50IGNob29zZSBUTFMvVENQIGFzIHRyYW5zcG9ydCwgDQogICAgd2hhdCB0cmFuc3BvcnQgcG9y dCB3aWxsIGJlIHVzZWTDgiZuYnNwOz8gU2FtZSBhcyBwb3J0IGZvciBUQ1Agb3IgU0NUUCBvciBu b3QgDQogICAgPyBpZiBub3Qsd2hhdCBpcyBpdD88L0RJVj48L0RJVj48L0JMT0NLUVVPVEU+DQog IDxESVY+PEZPTlQgc2l6ZT0yIGZhY2U95a6L5L2TPjwvRk9OVD48QlI+PEJSPlRMUy9UQ1AgaXMg Z29pbmcgdG8gYmUgb24gYSBkaWZmZXJlbnQgDQogIHBvcnQgdGhhbiBqdXN0IHBsYWluIFRDUC4g UG9ydCBhc3NpZ25tZW50cyBmb3IgVENQIGlzIGluIHRvIGN1cnJlbnQgZG9jIHdoaWxlIA0KICBU TFMgaXMgc3RpbGwgdG8gYmUgYWxsb2NhdGVkLjwvRElWPg0KICA8RElWPiZuYnNwOzwvRElWPg0K ICA8RElWPltRaW5dOiBJIHRoaW5rIGl0IGlzIGJldHRlciB0byBjaG9vc2UgdGhlIHNhbWUgcG9y dCBudW1iZXIgZm9yIHRyYW5zcG9ydCANCiAgbGlrZSAzODY4LCBpbiB0aGF0IHdheSwgaXQgaXMg ZWFzeSB0byBmaWx0ZXIgRGlhbWV0ZXIgcHJvdG9jb2wgd2hlbiBjYXB0dXJpbmcuIA0KICBCdXQm bmJzcDt0aGF0IGlzIG5vdCBpbXBvcnRhbnQgYW55IA0KICBtb3JlLjxCUj48QlI+cmVnYXJkcyw8 QlI+dmljdG9yPEJSPjxCUj48QlI+w4ImbmJzcDs8L0RJVj4NCiAgPEJMT0NLUVVPVEUgDQogIHN0 eWxlPSJCT1JERVItTEVGVDogcmdiKDIwNCwyMDQsMjA0KSAxcHggc29saWQ7IE1BUkdJTjogMHB0 IDBwdCAwcHQgMC44ZXg7IFBBRERJTkctTEVGVDogMWV4IiANCiAgY2xhc3M9Z21haWxfcXVvdGU+ DQogICAgPERJViBiZ2NvbG9yPSIjY2NlOGNmIj4NCiAgICA8RElWPkhvcGUgc29tZWJvZHkgY2Fu IGNsYXJpZnkuIFRoYW5rcyE8L0RJVj4NCiAgICA8RElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+w4Im bmJzcDs8L0RJVj4NCiAgICA8RElWPlJlZ2FyZHMhPC9ESVY+DQogICAgPERJVj4tUWluPC9ESVY+ PEZPTlQgY29sb3I9Izg4ODg4OD48L0ZPTlQ+DQogICAgPEJMT0NLUVVPVEUgDQogICAgc3R5bGU9 IkJPUkRFUi1MRUZUOiByZ2IoMCwwLDApIDJweCBzb2xpZDsgUEFERElORy1MRUZUOiA1cHg7IFBB RERJTkctUklHSFQ6IDBweDsgTUFSR0lOLUxFRlQ6IDVweDsgTUFSR0lOLVJJR0hUOiAwcHgiPg0K ICAgICAgPERJVj4NCiAgICAgIDxESVY+PC9ESVY+DQogICAgICA8RElWIGNsYXNzPWg1Pg0KICAg ICAgPERJVj4tLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIDwvRElWPg0KICAgICAgPERJViAN CiAgICAgIHN0eWxlPSJCQUNLR1JPVU5EOiByZ2IoMjI4LDIyOCwyMjgpOyAtbW96LWJhY2tncm91 bmQtY2xpcDogYm9yZGVyOyAtbW96LWJhY2tncm91bmQtb3JpZ2luOiBwYWRkaW5nOyAtbW96LWJh Y2tncm91bmQtaW5saW5lLXBvbGljeTogY29udGludW91cyI+PEI+RnJvbTo8L0I+IA0KICAgICAg PEEgdGl0bGU9dmYwMjEzQGdtYWlsLmNvbSBocmVmPSJtYWlsdG86dmYwMjEzQGdtYWlsLmNvbSIg DQogICAgICB0YXJnZXQ9X2JsYW5rPlZpY3RvciBGYWphcmRvPC9BPiA8L0RJVj4NCiAgICAgIDxE SVY+PEI+VG86PC9CPiA8QSB0aXRsZT1saW9uZWwubW9yYW5kQG9yYW5nZS1mdGdyb3VwLmNvbSAN CiAgICAgIGhyZWY9Im1haWx0bzpsaW9uZWwubW9yYW5kQG9yYW5nZS1mdGdyb3VwLmNvbSIgDQog ICAgICB0YXJnZXQ9X2JsYW5rPmxpb25lbC5tb3JhbmRAb3JhbmdlLWZ0Z3JvdXAuY29tPC9BPiA8 L0RJVj4NCiAgICAgIDxESVY+PEI+Q2M6PC9CPiA8QSB0aXRsZT1NYXJrLkpvbmVzQGJyaWRnZXdh dGVyc3lzdGVtcy5jb20gDQogICAgICBocmVmPSJtYWlsdG86TWFyay5Kb25lc0BicmlkZ2V3YXRl cnN5c3RlbXMuY29tIiANCiAgICAgIHRhcmdldD1fYmxhbms+TWFyay5Kb25lc0BicmlkZ2V3YXRl cnN5c3RlbXMuY29tPC9BPiA7IDxBIA0KICAgICAgdGl0bGU9ZGltZUBpZXRmLm9yZyBocmVmPSJt YWlsdG86ZGltZUBpZXRmLm9yZyIgDQogICAgICB0YXJnZXQ9X2JsYW5rPmRpbWVAaWV0Zi5vcmc8 L0E+IDwvRElWPg0KICAgICAgPERJVj48Qj5TZW50OjwvQj4gV2VkbmVzZGF5LCBBcHJpbCAxNCwg MjAxMCAxOjUwIEFNPC9ESVY+DQogICAgICA8RElWPjxCPlN1YmplY3Q6PC9CPiBSZTogW0RpbWVd IE5BUFRSIGZpeCBmb3IgMzU4OGJpczwvRElWPg0KICAgICAgPERJVj48QlI+PC9ESVY+TG9va3Mg Z29vZC4gSSdsbCBzZW5kIG91dCBhIGJpcyB2ZXJzaW9uIHdpdGggdGhlIGNoYW5nZXMgDQogICAg ICBiZWxvdy48QlI+PEJSPjxCUj4NCiAgICAgIDxESVYgY2xhc3M9Z21haWxfcXVvdGU+T24gVHVl LCBBcHIgMTMsIDIwMTAgYXQgOTo0NiBBTSwgPFNQQU4gDQogICAgICBkaXI9bHRyPiZsdDs8QSBo cmVmPSJtYWlsdG86bGlvbmVsLm1vcmFuZEBvcmFuZ2UtZnRncm91cC5jb20iIA0KICAgICAgdGFy Z2V0PV9ibGFuaz5saW9uZWwubW9yYW5kQG9yYW5nZS1mdGdyb3VwLmNvbTwvQT4mZ3Q7PC9TUEFO PiB3cm90ZTo8QlI+DQogICAgICA8QkxPQ0tRVU9URSANCiAgICAgIHN0eWxlPSJCT1JERVItTEVG VDogcmdiKDIwNCwyMDQsMjA0KSAxcHggc29saWQ7IE1BUkdJTjogMHB0IDBwdCAwcHQgMC44ZXg7 IFBBRERJTkctTEVGVDogMWV4IiANCiAgICAgIGNsYXNzPWdtYWlsX3F1b3RlPlRoeCBTw4PCqWJh c3RpZW4uPEJSPjxCUj5TbyB0byBzdW0gdXAsIGFsbCB0aGUgZXhpc3RpbmcgDQogICAgICAgIGlz c3VlcyBhcmUgbm93IGNsb3NlZC48QlI+PEJSPkFueSBvdGhlciBmZWVkYmFjayBmcm9tIHRoZSBX RyBvbiB0aGUgDQogICAgICAgIHByb3Bvc2VkIG1vZGlmaWNhdGlvbj88QlI+PEJSPkhlcmVhZnRl ciB0aGUgbW9kaWZpY2F0aW9uIHByb3Bvc2VkIGJ5IA0KICAgICAgICBNYXJrIHdpdGggY29ycmVj dGlvbnMgYmFzZWQgb24gdGhlIGFncmVlbWVudCByZWFjaGVkIGFmdGVyIGVtYWlsIA0KICAgICAg ICBkaXNjdXNzaW9uOjxCUj48QlI+KioqKioqKioqKioqKioqKioqKioqKioqKiBGSVJTVCBDSEFO R0UgDQogICAgICAgICoqKioqKioqKioqKioqKioqKioqKioqKio8QlI+PEJSPlNlY3Rpb24gNS4y IERpYW1ldGVyIFBlZXIgDQogICAgICAgIERpc2NvdmVyeTxCUj48QlI+PSZndDsgUmVwbGFjZSBz dGVwIDIgd2l0aCB0aGUgZm9sbG93aW5nIA0KICAgICAgICB0ZXh0OjxCUj48QlI+w4ImbmJzcDsg Mi4gw4ImbmJzcDtUaGUgRGlhbWV0ZXIgaW1wbGVtZW50YXRpb24gcGVyZm9ybXMgYSANCiAgICAg ICAgTkFQVFIgcXVlcnkgZm9yIGEgc2VydmVyPEJSPsOCJm5ic3A7IMOCJm5ic3A7IMOCJm5ic3A7 IGluIGEgcGFydGljdWxhciANCiAgICAgICAgcmVhbG0uIMOCJm5ic3A7VGhlIERpYW1ldGVyIGlt cGxlbWVudGF0aW9uIGhhcyB0byBrbm93PEJSPsOCJm5ic3A7IMOCJm5ic3A7IA0KICAgICAgICDD giZuYnNwOyBpbiBhZHZhbmNlIHdoaWNoIHJlYWxtIHRvIGxvb2sgZm9yIGEgRGlhbWV0ZXIgYWdl bnQgaW4uIA0KICAgICAgICDDgiZuYnNwO1RoaXM8QlI+w4ImbmJzcDsgw4ImbmJzcDsgw4ImbmJz cDsgY291bGQgYmUgZGVkdWNlZCwgZm9yIGV4YW1wbGUsIA0KICAgICAgICBmcm9tIHRoZSAncmVh bG0nIGluIGEgTkFJIHRoYXQgYTxCUj7DgiZuYnNwOyDDgiZuYnNwOyDDgiZuYnNwOyBEaWFtZXRl ciANCiAgICAgICAgaW1wbGVtZW50YXRpb24gbmVlZGVkIHRvIHBlcmZvcm0gYSBEaWFtZXRlciBv cGVyYXRpb248QlI+w4ImbmJzcDsgw4ImbmJzcDsgDQogICAgICAgIMOCJm5ic3A7IG9uLjxCUj48 QlI+w4ImbmJzcDsgw4ImbmJzcDsgw4ImbmJzcDsgVGhlIE5BUFRSIHVzYWdlIGluIERpYW1ldGVy IA0KICAgICAgICBmb2xsb3dzIHRoZSBTLU5BUFRSIERERFMgYXBwbGljYXRpb248QlI+w4ImbmJz cDsgw4ImbmJzcDsgw4ImbmJzcDsgDQogICAgICAgIFtSRkMzOTU4XSB3aGljaCBtZWFucyB0aGF0 IHRoZSBTRVJWSUNFIGZpZWxkIGluY2x1ZGVzIHRhZ3MgZm9yIA0KICAgICAgICB0aGU8QlI+w4Im bmJzcDsgw4ImbmJzcDsgw4ImbmJzcDsgZGVzaXJlZCBhcHBsaWNhdGlvbiBhbmQgc3VwcG9ydGVk IA0KICAgICAgICBhcHBsaWNhdGlvbiBwcm90b2NvbC48QlI+w4ImbmJzcDsgw4ImbmJzcDsgw4Im bmJzcDsgVGhlIGFwcGxpY2F0aW9uIHNlcnZpY2UgDQogICAgICAgIHRhZyBmb3IgYSBEaWFtZXRl ciBhcHBsaWNhdGlvbiBpcyAnYWFhJyBhbmQ8QlI+w4ImbmJzcDsgw4ImbmJzcDsgw4ImbmJzcDsg DQogICAgICAgIHRoZSBzdXBwb3J0ZWQgw4ImbmJzcDthcHBsaWNhdGlvbiBwcm90b2NvbCB0YWdz IGFyZSANCiAgICAgICAgJ2RpYW1ldGVyLnRjcCcsPEJSPsOCJm5ic3A7IMOCJm5ic3A7IMOCJm5i c3A7ICdkaWFtZXRlci5zY3RwJyBvciANCiAgICAgICAgJ2RpYW1ldGVyLnRscycuPEJSPjxCUj7D giZuYnNwOyDDgiZuYnNwOyDDgiZuYnNwOyBUaGUgY2xpZW50IGZvbGxvd3MgdGhlIA0KICAgICAg ICByZXNvbHV0aW9uIHByb2Nlc3MgZGVmaW5lZCBieSB0aGUgUy1OQVBUUjxCUj7DgiZuYnNwOyDD giZuYnNwOyDDgiZuYnNwOyANCiAgICAgICAgREREUyBbUkZDMzk1OF0gYXBwbGljYXRpb24gdG8g ZmluZCBhIG1hdGNoaW5nIFNSViBvciBBIHJlY29yZCANCiAgICAgICAgb2Y8QlI+w4ImbmJzcDsg w4ImbmJzcDsgw4ImbmJzcDsgYSBzdWl0YWJsZSBwZWVyLiDDgiZuYnNwO1RoZSBkb21haW4gDQog ICAgICAgIHN1ZmZpeGVzIGluIHRoZSBOQVBUUiByZXBsYWNlbWVudCBmaWVsZDxCUj7DgiZuYnNw OyDDgiZuYnNwOyDDgiZuYnNwOyANCiAgICAgICAgU0hPVUxEIG1hdGNoIHRoZSBkb21haW4gb2Yg dGhlIG9yaWdpbmFsIA0KICAgICAgICBxdWVyeS48QlI+PEJSPjxCUj4qKioqKioqKioqKioqKioq KioqKioqKioqIFNFQ09ORCBDSEFOR0UgDQogICAgICAgICoqKioqKioqKioqKioqKioqKioqKioq Kio8QlI+PEJSPlNlY3Rpb24gMTEuNiBOQVBUUiBTZXJ2aWNlIA0KICAgICAgICBGaWVsZHM8QlI+ PEJSPj0mZ3Q7IFJlbmFtZSB0aGlzIHNlY3Rpb24gdG8gUy1OQVBUUiBQYXJhbWV0ZXJzIGFuZCAN CiAgICAgICAgcmVwbGFjZSBjb250ZW50IHdpdGg6PEJSPjxCUj5UaGlzIGRvY3VtZW50IHJlZ2lz dGVycyBhIFMtTkFQVFIgDQogICAgICAgIEFwcGxpY2F0aW9uIFNlcnZpY2UgVGFnIHZhbHVlIG9m ICJhYWEiLjxCUj48QlI+VGhpcyBkb2N1bWVudCBhbHNvIA0KICAgICAgICByZWdpc3RlcnMgdGhl IGZvbGxvd2luZyBTLU5BUFRSIEFwcGxpY2F0aW9uIFByb3RvY29sIFRhZ3M6PEJSPg0KICAgICAg ICA8RElWPjxCUj7DgiZuYnNwOyBUYWcgw4ImbmJzcDsgw4ImbmJzcDsgw4ImbmJzcDsgw4ImbmJz cDsgw4ImbmJzcDsgw4ImbmJzcDsgDQogICAgICAgIMOCJm5ic3A7IMOCJm5ic3A7fCBQcm90b2Nv bDxCUj7DgiZuYnNwOyANCiAgICAgICAgLS0tLS0tLS0tLS0tLS0tLS0tLXwtLS0tLS0tLS08QlI+ w4ImbmJzcDsgZGlhbWV0ZXIudGNwIMOCJm5ic3A7IMOCJm5ic3A7IA0KICAgICAgICDDgiZuYnNw OyB8IFRDUDxCUj7DgiZuYnNwOyBkaWFtZXRlci5zY3RwIMOCJm5ic3A7IMOCJm5ic3A7IMOCJm5i c3A7fCANCiAgICAgICAgU0NUUDxCUj7DgiZuYnNwOyBkaWFtZXRlci50bHMudGNwIMOCJm5ic3A7 IHwgDQogICAgICAgIFRMUy9UQ1A8QlI+PEJSPjwvRElWPioqKioqKioqKioqKioqKioqKioqKioq KiogVEhJUkQgQ0hBTkdFIA0KICAgICAgICAqKioqKioqKioqKioqKioqKioqKioqKioqKjxCUj48 QlI+QXBwZW5kaXggQi4gw4ImbmJzcDtOQVBUUiANCiAgICAgICAgRXhhbXBsZTxCUj48QlI+PSZn dDsgUmVuYW1lIHNlY3Rpb24gdG8gUy1OQVBUUiBFeGFtcGxlIGFuZCBtb2RpZnkgYXMgDQogICAg ICAgIGZvbGxvd3MuPEJSPjxCUj7DgiZuYnNwOyBBcyBhbiBleGFtcGxlLCBjb25zaWRlciBhIGNs aWVudCB0aGF0IHdpc2hlcyB0byANCiAgICAgICAgcmVzb2x2ZSBhYWE6PEJSPsOCJm5ic3A7IDxB IGhyZWY9Imh0dHA6Ly9leGFtcGxlLmNvbSIgDQogICAgICAgIHRhcmdldD1fYmxhbms+ZXhhbXBs ZS5jb208L0E+LiDDgiZuYnNwO1RoZSBjbGllbnQgcGVyZm9ybXMgYSBOQVBUUiBxdWVyeSANCiAg ICAgICAgZm9yIHRoYXQgZG9tYWluLCBhbmQ8QlI+w4ImbmJzcDsgdGhlIGZvbGxvd2luZyBOQVBU UiByZWNvcmRzIGFyZSANCiAgICAgICAgcmV0dXJuZWQ6PEJSPjxCUj7DgiZuYnNwOzs7IMOCJm5i c3A7IMOCJm5ic3A7IMOCJm5ic3A7IMOCJm5ic3A7b3JkZXIgcHJlZiANCiAgICAgICAgZmxhZ3Mg c2VydmljZSDDgiZuYnNwOyDDgiZuYnNwOyDDgiZuYnNwOyDDgiZuYnNwOyDDgiZuYnNwOyDDgiZu YnNwOyDDgiZuYnNwOyANCiAgICAgICAgw4ImbmJzcDtyZWdleHAgcmVwbGFjZW1lbnQ8QlI+w4Im bmJzcDtJTiBOQVBUUiDDgiZuYnNwOzUwIMOCJm5ic3A7IMOCJm5ic3A7NTAgDQogICAgICAgIMOC Jm5ic3A7ICJzIiDDgiZuYnNwOyAiYWFhOmRpYW1ldGVyLnRscy50Y3AiIMOCJm5ic3A7IiIgw4Im bmJzcDsgw4ImbmJzcDsgDQogICAgICAgIF9kaWFtZXRlci5fPEEgaHJlZj0iaHR0cDovL3Rscy50 Y3AuZXhhbXBsZS5jb20iIA0KICAgICAgICB0YXJnZXQ9X2JsYW5rPnRscy50Y3AuZXhhbXBsZS5j b208L0E+PEJSPsOCJm5ic3A7SU4gTkFQVFIgw4ImbmJzcDsxMDAgDQogICAgICAgIMOCJm5ic3A7 IDUwIMOCJm5ic3A7ICJzIiDDgiZuYnNwOyAiYWFhOmRpYW1ldGVyLnRjcCIgw4ImbmJzcDsgw4Im bmJzcDsgDQogICAgICAgIMOCJm5ic3A7IiIgw4ImbmJzcDsgw4ImbmJzcDsgX2RpYW1ldGVyLl88 QSBocmVmPSJodHRwOi8vdGNwLmV4YW1wbGUuY29tIiANCiAgICAgICAgdGFyZ2V0PV9ibGFuaz50 Y3AuZXhhbXBsZS5jb208L0E+PEJSPsOCJm5ic3A7SU4gTkFQVFIgw4ImbmJzcDsxNTAgw4ImbmJz cDsgDQogICAgICAgIDUwIMOCJm5ic3A7ICJzIiDDgiZuYnNwOyAiYWFhOmRpYW1ldGVyLnNjdHAi IMOCJm5ic3A7IMOCJm5ic3A7ICIiIMOCJm5ic3A7IA0KICAgICAgICDDgiZuYnNwOyBfZGlhbWV0 ZXIuXzxBIGhyZWY9Imh0dHA6Ly9zY3RwLmV4YW1wbGUuY29tIiANCiAgICAgICAgdGFyZ2V0PV9i bGFuaz5zY3RwLmV4YW1wbGUuY29tPC9BPjxCUj48QlI+w4ImbmJzcDsgVGhpcyBpbmRpY2F0ZXMg dGhhdCANCiAgICAgICAgdGhlIHNlcnZlciBzdXBwb3J0cyBUTFMvVENQLCBUQ1AgYW5kIFNDVFAg aW4gdGhhdDxCUj7DgiZuYnNwOyBvcmRlci4gDQogICAgICAgIMOCJm5ic3A7SWYgdGhlIGNsaWVu dCBzdXBwb3J0cyBUTFMvVENQLCBUTFMvVENQIHdpbGwgYmUgdXNlZCwgdGFyZ2V0ZWQgdG8gDQog ICAgICAgIGE8QlI+w4ImbmJzcDsgaG9zdCBkZXRlcm1pbmVkIGJ5IGFuIFNSViBsb29rdXAgb2Yg X2RpYW1ldGVyLl88QSANCiAgICAgICAgaHJlZj0iaHR0cDovL3Rscy50Y3AuZXhhbXBsZS5jb20i IHRhcmdldD1fYmxhbms+dGxzLnRjcC5leGFtcGxlLmNvbTwvQT4uIA0KICAgICAgICDDgiZuYnNw O1RoYXQ8QlI+w4ImbmJzcDsgbG9va3VwIHdvdWxkIHJldHVybjo8QlI+PEJSPsOCJm5ic3A7IMOC Jm5ic3A7OzsgDQogICAgICAgIMOCJm5ic3A7IMOCJm5ic3A7IMOCJm5ic3A7IFByaW9yaXR5IMOC Jm5ic3A7V2VpZ2h0IMOCJm5ic3A7UG9ydCDDgiZuYnNwOyANCiAgICAgICAgw4ImbmJzcDtUYXJn ZXQ8QlI+w4ImbmJzcDsgw4ImbmJzcDtJTiBTUlYgw4ImbmJzcDsgMCDDgiZuYnNwOyDDgiZuYnNw OyDDgiZuYnNwOyANCiAgICAgICAgw4ImbmJzcDsgMSDDgiZuYnNwOyDDgiZuYnNwOyDDgiZuYnNw OyA1MDYwIMOCJm5ic3A7IMOCJm5ic3A7PEEgDQogICAgICAgIGhyZWY9Imh0dHA6Ly9zZXJ2ZXIx LmV4YW1wbGUuY29tIiANCiAgICAgICAgdGFyZ2V0PV9ibGFuaz5zZXJ2ZXIxLmV4YW1wbGUuY29t PC9BPjxCUj7DgiZuYnNwOyDDgiZuYnNwO0lOIFNSViDDgiZuYnNwOyAwIA0KICAgICAgICDDgiZu YnNwOyDDgiZuYnNwOyDDgiZuYnNwOyDDgiZuYnNwOyAyIMOCJm5ic3A7IMOCJm5ic3A7IMOCJm5i c3A7IDUwNjAgw4ImbmJzcDsgDQogICAgICAgIMOCJm5ic3A7PEEgaHJlZj0iaHR0cDovL3NlcnZl cjIuZXhhbXBsZS5jb20iIA0KICAgICAgICB0YXJnZXQ9X2JsYW5rPnNlcnZlcjIuZXhhbXBsZS5j b208L0E+PEJSPjxCUj49Jmd0O2FkZGl0aW9uIG9mIGFuIGV4YW1wbGUgDQogICAgICAgIHdpdGgg ImEiIGZsYWcgcmVxdWlyZWQgc3VjaCBhczo8QlI+PEJSPsOCJm5ic3A7SU4gTkFQVFIgw4ImbmJz cDsxNTAgDQogICAgICAgIMOCJm5ic3A7IDUwIMOCJm5ic3A7ICJhIiDDgiZuYnNwOyAiYWFhOmRp YW1ldGVyLnRscy50Y3AiIMOCJm5ic3A7IiIgw4ImbmJzcDsgDQogICAgICAgIMOCJm5ic3A7IDxB IGhyZWY9Imh0dHA6Ly9zZXJ2ZXIxLmV4YW1wbGUuY29tIiANCiAgICAgICAgdGFyZ2V0PV9ibGFu az5zZXJ2ZXIxLmV4YW1wbGUuY29tPC9BPjxCUj7DgiZuYnNwO0lOIE5BUFRSIMOCJm5ic3A7MTUw IA0KICAgICAgICDDgiZuYnNwOyA1MCDDgiZuYnNwOyAiYSIgw4ImbmJzcDsgImFhYTpkaWFtZXRl ci50bHMudGNwIiDDgiZuYnNwOyIiIMOCJm5ic3A7IA0KICAgICAgICDDgiZuYnNwOyA8QSBocmVm PSJodHRwOi8vc2VydmVyMi5leGFtcGxlLmNvbSIgDQogICAgICAgIHRhcmdldD1fYmxhbms+c2Vy dmVyMi5leGFtcGxlLmNvbTwvQT48QlI+PEJSPioqKioqKioqKioqKioqKioqKioqKioqKiogDQog ICAgICAgIEZPVVJUSCBDSEFOR0UgKioqKioqKioqKioqKioqKioqKioqKioqKio8QlI+PEJSPjE0 LjEuIMOCJm5ic3A7Tm9ybWF0aXZlIA0KICAgICAgICBSZWZlcmVuY2VzPEJSPjxCUj49Jmd0OyBB ZGQgbmV3IHJlZmVyZW5jZSB0byBTLU5BUFRSIERERFMgDQogICAgICAgIFJGQzM5NTguPEJSPjxC Uj4qKioqKioqKioqKioqKioqKioqKioqKioqIEVORCBPRiBDSEFOR0VTIA0KICAgICAgICAqKioq KioqKioqKioqKioqKioqKioqKjxCUj48QlI+PEJSPjxCUj48QlI+PEJSPiZndDsgLS0tLS1NZXNz YWdlIA0KICAgICAgICBkJ29yaWdpbmUtLS0tLTxCUj4mZ3Q7IERlIDogU2ViYXN0aWVuIERlY3Vn aXMgW21haWx0bzo8QSANCiAgICAgICAgaHJlZj0ibWFpbHRvOnNkZWN1Z2lzQG5pY3QuZ28uanAi IA0KICAgICAgICB0YXJnZXQ9X2JsYW5rPnNkZWN1Z2lzQG5pY3QuZ28uanA8L0E+XTxCUj4mZ3Q7 IEVudm95w4PCqSA6IG1hcmRpIDEzIGF2cmlsIA0KICAgICAgICAyMDEwIDA3OjE0PEJSPiZndDsg w4PigqwgOiBNYXJrIEpvbmVzPEJSPiZndDsgQ2MgOiBNT1JBTkQgTGlvbmVsIA0KICAgICAgICBS RC1DT1JFLUlTUzsgPEEgaHJlZj0ibWFpbHRvOnZmMDIxM0BnbWFpbC5jb20iIA0KICAgICAgICB0 YXJnZXQ9X2JsYW5rPnZmMDIxM0BnbWFpbC5jb208L0E+OyA8QSBocmVmPSJtYWlsdG86ZGltZUBp ZXRmLm9yZyIgDQogICAgICAgIHRhcmdldD1fYmxhbms+ZGltZUBpZXRmLm9yZzwvQT48QlI+DQog ICAgICAgIDxESVY+DQogICAgICAgIDxESVY+PC9ESVY+DQogICAgICAgIDxESVY+Jmd0OyBPYmpl dCA6IFJlOiBbRGltZV0gTkFQVFIgZml4IGZvciAzNTg4YmlzPEJSPiZndDs8QlI+Jmd0OyANCiAg ICAgICAgSGksPEJSPiZndDs8QlI+Jmd0OyBJIGFtIGZpbmUgd2l0aCB0aGlzIGFwcHJvYWNoIGFz IHdlbGwuIE15IGluaXRpYWwgDQogICAgICAgIGludGVudGlvbjxCUj4mZ3Q7IHdhcyBqdXN0IHRv IGhpZ2hsaWdodCB0aGF0IGhhdmluZyBUTFMgYXQgdGhlIHNhbWUgDQogICAgICAgIGxldmVsIGFz PEJSPiZndDsgVENQIGFuZCBTQ1RQIGlzIHZlcnkgY29uZnVzaW5nLjxCUj4mZ3Q7IFRoZSB0YWcg DQogICAgICAgICJkaWFtZXRlci50bHMudGNwIiBpcyBwZXJmZWN0bHkgZmluZSBmb3IgbWUuIEFu ZCBpdDxCUj4mZ3Q7IHdpbGwgYmUgDQogICAgICAgIHF1aXRlIGVhc3kgdG8gZmlndXJlIHdoYXQg dG8gZG8sIHNob3VsZCAoVExTIG92ZXIpPEJSPiZndDsgU0NUUCBiZWNvbWUgDQogICAgICAgIG1v cmUgcG9wdWxhci48QlI+Jmd0OzxCUj4mZ3Q7IEJlc3QgcmVnYXJkcyw8QlI+Jmd0OyANCiAgICAg ICAgU2ViYXN0aWVuLjxCUj4mZ3Q7PEJSPiZndDsgTGUgMTMvMDQvMjAxMCAwNTowOCwgTWFyayBK b25lcyBhIMODwqljcml0IA0KICAgICAgICA6PEJSPiZndDsgJmd0OzxCUj4mZ3Q7ICZndDsgV29y a3MgZm9yIG1lLiBJIGFzc3VtZSB3ZSdkIHN0aWxsIGtlZXAgDQogICAgICAgICJkaWFtZXRlci50 bHMudGNwIjxCUj4mZ3Q7IGFzIHRoZSB0YWc8QlI+Jmd0OyAmZ3Q7IGZvcm1hdCBzbyB0aGF0IA0K ICAgICAgICAiZGlhbWV0ZXIudGxzLnNjdHAiIGNhbiBiZSB1c2VkIGluIHRoZTxCUj4mZ3Q7IHNl cGFyYXRlIGRyYWZ0LjxCUj4mZ3Q7IA0KICAgICAgICAmZ3Q7PEJSPiZndDsgJmd0OyBNYXJrPEJS PiZndDsgJmd0OzxCUj4mZ3Q7ICZndDsgKkZyb206KiA8QSANCiAgICAgICAgaHJlZj0ibWFpbHRv Omxpb25lbC5tb3JhbmRAb3JhbmdlLWZ0Z3JvdXAuY29tIiANCiAgICAgICAgdGFyZ2V0PV9ibGFu az5saW9uZWwubW9yYW5kQG9yYW5nZS1mdGdyb3VwLmNvbTwvQT48QlI+Jmd0OyAmZ3Q7IA0KICAg ICAgICBbbWFpbHRvOjxBIGhyZWY9Im1haWx0bzpsaW9uZWwubW9yYW5kQG9yYW5nZS1mdGdyb3Vw LmNvbSIgDQogICAgICAgIHRhcmdldD1fYmxhbms+bGlvbmVsLm1vcmFuZEBvcmFuZ2UtZnRncm91 cC5jb208L0E+XTxCUj4mZ3Q7ICZndDsgKlNlbnQ6KiANCiAgICAgICAgQXByaWwgMTIsIDIwMTAg MTE6NTkgQU08QlI+Jmd0OyAmZ3Q7ICpUbzoqIDxBIA0KICAgICAgICBocmVmPSJtYWlsdG86dmYw MjEzQGdtYWlsLmNvbSIgdGFyZ2V0PV9ibGFuaz52ZjAyMTNAZ21haWwuY29tPC9BPjsgPEEgDQog ICAgICAgIGhyZWY9Im1haWx0bzpzZGVjdWdpc0BuaWN0LmdvLmpwIiANCiAgICAgICAgdGFyZ2V0 PV9ibGFuaz5zZGVjdWdpc0BuaWN0LmdvLmpwPC9BPjxCUj4mZ3Q7ICZndDsgKkNjOiogTWFyayBK b25lczsgPEEgDQogICAgICAgIGhyZWY9Im1haWx0bzpkaW1lQGlldGYub3JnIiB0YXJnZXQ9X2Js YW5rPmRpbWVAaWV0Zi5vcmc8L0E+PEJSPiZndDsgJmd0OyANCiAgICAgICAgKlN1YmplY3Q6KiBS RTogW0RpbWVdIE5BUFRSIGZpeCBmb3IgMzU4OGJpczxCUj4mZ3Q7ICZndDs8QlI+Jmd0OyAmZ3Q7 IA0KICAgICAgICBIaSw8QlI+Jmd0OyAmZ3Q7PEJSPiZndDsgJmd0OyBUYWtpbmcgYWNjb3VudCB0 aGF0IHRoaXMgdG9waWMgY2FtZSBxdWl0ZSANCiAgICAgICAgbGF0ZSBpbiB0aGU8QlI+Jmd0OyBy ZXZpc2lvbiBwcm9jZXNzPEJSPiZndDsgJmd0OyBhbmQgdG8gbm90IGRlbGF5IHRoZSANCiAgICAg ICAgcHVibGljYXRpb24gb2YgdGhlIFJGQzM1ODhiaXMsIHdlIGNvdWxkIG1heWJlPEJSPiZndDsg Jmd0OyBjb25zaWRlciB0byANCiAgICAgICAgYWRkcmVzcyBUTFMgb3ZlciBTQ1RQIGluIGEgc2Vw YXJldGUgZHJhZnQgaW4gYSBsYXR0ZXI8QlI+Jmd0OyAmZ3Q7IHBoYXNlIA0KICAgICAgICBpZiB0 aGVyZSBpcyBhIFdHIGludGVyZXN0IG9mIHRoZSBXRyB0byBzdXBwb3J0IHRoaXMgb3B0aW9uLjxC Uj4mZ3Q7IA0KICAgICAgICAmZ3Q7PEJSPiZndDsgJmd0OyBXb3VsZCBpdCBiZSBhY2NlcHRhYmxl PzxCUj4mZ3Q7ICZndDs8QlI+Jmd0OyAmZ3Q7IA0KICAgICAgICBSZWdhcmRzLDxCUj4mZ3Q7ICZn dDs8QlI+Jmd0OyAmZ3Q7IExpb25lbDxCUj4mZ3Q7ICZndDs8QlI+Jmd0OyANCiAgICAgICAgJmd0 OzxCUj4mZ3Q7ICZndDs8QlI+Jmd0OyANCiAgICAgICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxCUj4mZ3Q7IA0K ICAgICAgICAmZ3Q7IC0tPEJSPiZndDsgJmd0OzxCUj4mZ3Q7ICZndDsgw4ImbmJzcDsgw4ImbmJz cDsgKkRlIDoqIDxBIA0KICAgICAgICBocmVmPSJtYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3Jn IiANCiAgICAgICAgdGFyZ2V0PV9ibGFuaz5kaW1lLWJvdW5jZXNAaWV0Zi5vcmc8L0E+PEJSPiZn dDsgW21haWx0bzo8QSANCiAgICAgICAgaHJlZj0ibWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9y ZyIgDQogICAgICAgIHRhcmdldD1fYmxhbms+ZGltZS1ib3VuY2VzQGlldGYub3JnPC9BPl0gKkRl IGxhPEJSPiZndDsgJmd0OyDDgiZuYnNwOyANCiAgICAgICAgw4ImbmJzcDsgcGFydCBkZSogVmlj dG9yIEZhamFyZG88QlI+Jmd0OyAmZ3Q7IMOCJm5ic3A7IMOCJm5ic3A7ICpFbnZvecODwqkgOiog DQogICAgICAgIGx1bmRpIDEyIGF2cmlsIDIwMTAgMTQ6Mjg8QlI+Jmd0OyAmZ3Q7IMOCJm5ic3A7 IMOCJm5ic3A7ICrDg+KCrCA6KiBTZWJhc3RpZW4gDQogICAgICAgIERlY3VnaXM8QlI+Jmd0OyAm Z3Q7IMOCJm5ic3A7IMOCJm5ic3A7ICpDYyA6KiBNYXJrIEpvbmVzOyA8QSANCiAgICAgICAgaHJl Zj0ibWFpbHRvOmRpbWVAaWV0Zi5vcmciIHRhcmdldD1fYmxhbms+ZGltZUBpZXRmLm9yZzwvQT48 QlI+Jmd0OyAmZ3Q7IA0KICAgICAgICDDgiZuYnNwOyDDgiZuYnNwOyAqT2JqZXQgOiogUmU6IFtE aW1lXSBOQVBUUiBmaXggZm9yIDM1ODhiaXM8QlI+Jmd0OyANCiAgICAgICAgJmd0OzxCUj4mZ3Q7 ICZndDsgw4ImbmJzcDsgw4ImbmJzcDsgSGkgU2ViYXN0aWVuLDxCUj4mZ3Q7ICZndDs8QlI+Jmd0 OyANCiAgICAgICAgJmd0OyDDgiZuYnNwOyDDgiZuYnNwOyBPbiBTdW4sIEFwciAxMSwgMjAxMCBh dCA5OjQzIFBNLCBTZWJhc3RpZW4gDQogICAgICAgIERlY3VnaXM8QlI+Jmd0OyAmZ3Q7IMOCJm5i c3A7IMOCJm5ic3A7ICZsdDs8QSANCiAgICAgICAgaHJlZj0ibWFpbHRvOnNkZWN1Z2lzQG5pY3Qu Z28uanAiIHRhcmdldD1fYmxhbms+c2RlY3VnaXNAbmljdC5nby5qcDwvQT4gDQogICAgICAgICZs dDttYWlsdG86PEEgaHJlZj0ibWFpbHRvOnNkZWN1Z2lzQG5pY3QuZ28uanAiIA0KICAgICAgICB0 YXJnZXQ9X2JsYW5rPnNkZWN1Z2lzQG5pY3QuZ28uanA8L0E+Jmd0OyZndDsgd3JvdGU6PEJSPiZn dDsgDQogICAgICAgICZndDs8QlI+Jmd0OyAmZ3Q7IMOCJm5ic3A7IMOCJm5ic3A7IEhpLDxCUj4m Z3Q7ICZndDs8QlI+Jmd0OyAmZ3Q7IMOCJm5ic3A7IA0KICAgICAgICDDgiZuYnNwOyBTb3JyeSBm b3IgdGhlIGRlbGF5LCBJIHdhcyBvbiB2YWNhdGlvbi48QlI+Jmd0OyAmZ3Q7PEJSPiZndDsgDQog ICAgICAgICZndDsgw4ImbmJzcDsgw4ImbmJzcDsgTGUgMDkvMDQvMjAxMCAwNzowMiwgTWFyayBK b25lcyBhIMODwqljcml0IDo8QlI+Jmd0OyANCiAgICAgICAgJmd0OyDDgiZuYnNwOyDDgiZuYnNw OyAmZ3Q7IDQpIEFwcGxpY2F0aW9uIHByb3RvY29sIHRhZyBmb3IgVExTIGRvZXMgbm90IA0KICAg ICAgICBkaWZmZXJlbnRpYXRlPEJSPiZndDsgJmd0OyDDgiZuYnNwOyDDgiZuYnNwOyBUTFMvVENQ IHZzPEJSPiZndDsgJmd0OyANCiAgICAgICAgw4ImbmJzcDsgw4ImbmJzcDsgJmd0OyBUTFMvU0NU UCAoU2ViYXN0aWFuKS48QlI+Jmd0OyAmZ3Q7IMOCJm5ic3A7IMOCJm5ic3A7IA0KICAgICAgICAm Z3Q7PEJSPiZndDsgJmd0OyDDgiZuYnNwOyDDgiZuYnNwOyAmZ3Q7IENvbmNsdXNpb246IE5ldyBU TFMgdGFncyBwcm9wb3NlZCANCiAgICAgICAgdG8gU2ViYXN0aWFuLiBTdGlsbDxCUj4mZ3Q7ICZn dDsgw4ImbmJzcDsgw4ImbmJzcDsgJmd0OyBvcGVuLjxCUj4mZ3Q7ICZndDsgDQogICAgICAgIMOC Jm5ic3A7IMOCJm5ic3A7ICZndDs8QlI+Jmd0OyAmZ3Q7PEJSPiZndDsgJmd0OyDDgiZuYnNwOyDD giZuYnNwOyBJIGFtIA0KICAgICAgICBwZXJmZWN0bHkgZmluZSB3aXRoIHRoZSByZXNvbHV0aW9u IHlvdSBwcm9wb3NlZCwgdGhhbmsgeW91ITxCUj4mZ3Q7IA0KICAgICAgICAmZ3Q7PEJSPiZndDsg Jmd0OyDDgiZuYnNwOyDDgiZuYnNwOyAmZ3Q7IDUpIE1pc3NpbmcgcmVmIHRvIFRMUy9TQ1RQIC0g DQogICAgICAgIFJGQzM0MzYgKFNlYmFzdGlhbikuPEJSPiZndDsgJmd0OyDDgiZuYnNwOyDDgiZu YnNwOyAmZ3Q7PEJSPiZndDsgJmd0OyANCiAgICAgICAgw4ImbmJzcDsgw4ImbmJzcDsgJmd0OyBD b25jbHVzaW9uOiBBZGQgdGhlIG1pc3NpbmcgcmVmZXJlbmNlIHRvIA0KICAgICAgICAzNTg4Ymlz LjxCUj4mZ3Q7ICZndDsgw4ImbmJzcDsgw4ImbmJzcDsgJmd0OyBVbnJlbGF0ZWQgdG8gdGhpcyBm aXggDQogICAgICAgIHRob3VnaC48QlI+Jmd0OyAmZ3Q7IMOCJm5ic3A7IMOCJm5ic3A7ICZndDs8 QlI+Jmd0OyAmZ3Q7IMOCJm5ic3A7IMOCJm5ic3A7IEkgDQogICAgICAgIGd1ZXNzIHRoaXMgcmVz b2x1dGlvbiB3aWxsIHJlcXVpcmUgYSBiaXQgbW9yZTxCUj4mZ3Q7IGZlZWRiYWNrIGZyb20gDQog ICAgICAgIHRoZTxCUj4mZ3Q7ICZndDsgw4ImbmJzcDsgw4ImbmJzcDsgZ3JvdXAsPEJSPiZndDsg Jmd0OyDDgiZuYnNwOyDDgiZuYnNwOyANCiAgICAgICAgdGhlcmUgbWF5IGJlIG90aGVyIHdheXMg dG8gaW1wbGVtZW50IFRMUyBvdmVyIFNDVFAuLi48QlI+Jmd0OyBDYW4gdGhlIA0KICAgICAgICBj aGFpcnM8QlI+Jmd0OyAmZ3Q7IMOCJm5ic3A7IMOCJm5ic3A7IGdpdmUgZGlyZWN0aW9uIG9uIHRo aXMgDQogICAgICAgIGlzc3VlPzxCUj4mZ3Q7ICZndDs8QlI+Jmd0OyAmZ3Q7PEJSPiZndDsgJmd0 OzxCUj4mZ3Q7ICZndDsgw4ImbmJzcDsgDQogICAgICAgIMOCJm5ic3A7IEZvciBhbGwgcHJhY3Rp Y2FsIHB1cnBvc2UsIGlzIHRoZXJlIHJlYWxseSBhIHN0cm9uZyANCiAgICAgICAgZGVwbG95YWJs ZTxCUj4mZ3Q7ICZndDsgw4ImbmJzcDsgw4ImbmJzcDsgcmVhc29uIHRvIHN1cHBvcnQgVExTIG92 ZXIgU0NUUCANCiAgICAgICAgPyBJJ20ganVzdCBoZXNpdGFudCB0byBkZWxheSBiaXM8QlI+Jmd0 OyAmZ3Q7IMOCJm5ic3A7IMOCJm5ic3A7IA0KICAgICAgICBwdWJsaWNhdGlvbiB0byBzdXBwb3J0 IGFuIGFjYWRlbWljIGV4ZXJjaXNlLjxCUj4mZ3Q7ICZndDs8QlI+Jmd0OyAmZ3Q7IA0KICAgICAg ICDDgiZuYnNwOyDDgiZuYnNwOyByZWdhcmRzLDxCUj4mZ3Q7ICZndDsgw4ImbmJzcDsgw4ImbmJz cDsgdmljdG9yPEJSPiZndDsgDQogICAgICAgICZndDs8QlI+Jmd0OyAmZ3Q7PEJSPiZndDsgJmd0 OzxCUj4mZ3Q7ICZndDsgw4ImbmJzcDsgw4ImbmJzcDsgw4ImbmJzcDsgDQogICAgICAgIMOCJm5i c3A7IFRoYW5rcyE8QlI+Jmd0OyAmZ3Q7IMOCJm5ic3A7IMOCJm5ic3A7IMOCJm5ic3A7IMOCJm5i c3A7IA0KICAgICAgICBTZWJhc3RpZW4uPEJSPiZndDsgJmd0OzxCUj4mZ3Q7ICZndDsgw4ImbmJz cDsgw4ImbmJzcDsgw4ImbmJzcDsgw4ImbmJzcDsgDQogICAgICAgIC0tPEJSPiZndDsgJmd0OyDD giZuYnNwOyDDgiZuYnNwOyDDgiZuYnNwOyDDgiZuYnNwOyBTZWJhc3RpZW4gDQogICAgICAgIERl Y3VnaXM8QlI+Jmd0OyAmZ3Q7IMOCJm5ic3A7IMOCJm5ic3A7IMOCJm5ic3A7IMOCJm5ic3A7IFJl c2VhcmNoIA0KICAgICAgICBmZWxsb3c8QlI+Jmd0OyAmZ3Q7IMOCJm5ic3A7IMOCJm5ic3A7IMOC Jm5ic3A7IMOCJm5ic3A7IE5ldHdvcmsgQXJjaGl0ZWN0dXJlIA0KICAgICAgICBHcm91cDxCUj4m Z3Q7ICZndDsgw4ImbmJzcDsgw4ImbmJzcDsgw4ImbmJzcDsgw4ImbmJzcDsgTklDVCAoPEEgDQog ICAgICAgIGhyZWY9Imh0dHA6Ly9uaWN0LmdvLmpwIiB0YXJnZXQ9X2JsYW5rPm5pY3QuZ28uanA8 L0E+ICZsdDs8QSANCiAgICAgICAgaHJlZj0iaHR0cDovL25pY3QuZ28uanAiIA0KICAgICAgICB0 YXJnZXQ9X2JsYW5rPmh0dHA6Ly9uaWN0LmdvLmpwPC9BPiZndDspPEJSPiZndDsgJmd0OzxCUj4m Z3Q7PEJSPiZndDsgDQogICAgICAgIC0tPEJSPiZndDsgU2ViYXN0aWVuIERlY3VnaXM8QlI+Jmd0 OyBSZXNlYXJjaCBmZWxsb3c8QlI+Jmd0OyBOZXR3b3JrIA0KICAgICAgICBBcmNoaXRlY3R1cmUg R3JvdXA8QlI+Jmd0OyBOSUNUICg8QSBocmVmPSJodHRwOi8vbmljdC5nby5qcCIgDQogICAgICAg IHRhcmdldD1fYmxhbms+bmljdC5nby5qcDwvQT4pPEJSPiZndDs8QlI+Jmd0OzxCUj48L0RJVj48 L0RJVj48L0JMT0NLUVVPVEU+PC9ESVY+PEJSPjwvRElWPjwvRElWPg0KICAgICAgPFA+PC9QPg0K ICAgICAgPEhSPg0KDQogICAgICA8RElWIGNsYXNzPWltPg0KICAgICAgPFA+PC9QPl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPEJSPkRpTUUgbWFpbGluZyAN CiAgICAgIGxpc3Q8QlI+PEEgaHJlZj0ibWFpbHRvOkRpTUVAaWV0Zi5vcmciIA0KICAgICAgdGFy Z2V0PV9ibGFuaz5EaU1FQGlldGYub3JnPC9BPjxCUj48L0RJVj4NCiAgICAgIDxESVYgY2xhc3M9 aW0+PEEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaW1lIiAN CiAgICAgIHRhcmdldD1fYmxhbms+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9kaW1lPC9BPjxCUj48L0RJVj48L0JMT0NLUVVPVEU+PC9ESVY+PC9CTE9DS1FVT1RFPjwvRElW PjxCUj48L0JMT0NLUVVPVEU+PC9CT0RZPjwvSFRNTD4NCg== --Boundary_(ID_dMSq9FK2vFYz2F3tr3fJRw)-- From vf0213@gmail.com Thu Apr 15 14:09:04 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FB5D3A6A2F for ; Thu, 15 Apr 2010 14:09:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.97 X-Spam-Level: X-Spam-Status: No, score=-1.97 tagged_above=-999 required=5 tests=[AWL=0.628, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08qgN7yZSx2m for ; Thu, 15 Apr 2010 14:09:03 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 033E63A6A72 for ; Thu, 15 Apr 2010 14:07:30 -0700 (PDT) Received: by wwi18 with SMTP id 18so787223wwi.31 for ; Thu, 15 Apr 2010 14:07:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:content-type; bh=EEtNObjWaWlQAK7pjt+o1ETvo4UM9nIOcweptQ/ytl0=; b=A+r7hdXs5trNmQyJ9tmvdUfuh0WaTIEXoXZSCeuJAUIuc5eHLdRxBokzzbekGDdh82 vCi8Ln69QBfYG68tuVJkBAECNl86W4Rv27AhuzBAv4NoFp6X9vAMzf9J7WyYNr4mDaQa 5prYN7XEz5c3W5mBIy09vwmG4rUhrdvHnsPTE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=Ajbz709Pq7f4IUkCAKUueJB07EJQ0piy4giKsAARX6KxOJCEyCS+A0FFPuPTVLfVk1 DDh9LJc28OHV+a6uRpvkvbP/tdCI4HwQCUKW0dyqvBTrU+o0tuxvmLH/R01NfzYk8RtL bJ/V9xuVzgpNgf/7BTnHR1t9zvt8wUdnyNbiw= MIME-Version: 1.0 Received: by 10.216.159.131 with HTTP; Thu, 15 Apr 2010 14:07:21 -0700 (PDT) In-Reply-To: <20100415210501.A3CA83A6A72@core3.amsl.com> References: <20100415210501.A3CA83A6A72@core3.amsl.com> Date: Thu, 15 Apr 2010 16:07:21 -0500 Received: by 10.216.87.134 with SMTP id y6mr675287wee.20.1271365641356; Thu, 15 Apr 2010 14:07:21 -0700 (PDT) Message-ID: From: Victor Fajardo To: dime@ietf.org Content-Type: multipart/alternative; boundary=0016e6d77e886ed62604844ce146 Subject: Re: [Dime] New Version Notification for draft-ietf-dime-rfc3588bis-20 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2010 21:09:04 -0000 --0016e6d77e886ed62604844ce146 Content-Type: text/plain; charset=ISO-8859-1 Hi Lionel/Jouni, I've just publish an updated rev of bis. Do you think we can proceed with a writeup and send it on its way ? regards, victor On Thu, Apr 15, 2010 at 4:05 PM, IETF I-D Submission Tool < idsubmission@ietf.org> wrote: > > A new version of I-D, draft-ietf-dime-rfc3588bis-20.txt has been > successfully submitted by Victor Fajardo and posted to the IETF repository. > > Filename: draft-ietf-dime-rfc3588bis > Revision: 20 > Title: Diameter Base Protocol > Creation_date: 2010-04-15 > WG ID: dime > Number_of_pages: 159 > > Abstract: > The Diameter base protocol is intended to provide an Authentication, > Authorization and Accounting (AAA) framework for applications such as > network access or IP mobility in both local and roaming situations. > This document specifies the message format, transport, error > reporting, accounting and security services used by all Diameter > applications. The Diameter base protocol as defined in this document > must be supported by all Diameter implementations. > > > > The IETF Secretariat. > > > --0016e6d77e886ed62604844ce146 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Lionel/Jouni,

I've just publish an updated rev of bis. Do you= think we can proceed with a writeup and send it on its way ?

regard= s,
victor


On Thu, Apr 15, 2010 at = 4:05 PM, IETF I-D Submission Tool <idsubmission@ietf.org> wrote:

A new version of I-D, draft-ietf-dime-rfc3588bis-20.txt has been successful= ly submitted by Victor Fajardo and posted to the IETF repository.

Filename: =A0 =A0 =A0 =A0draft-ietf-dime-rfc3588bis
Revision: =A0 =A0 =A0 =A020
Title: =A0 =A0 =A0 =A0 =A0 Diameter Base Protocol
Creation_date: =A0 2010-04-15
WG ID: =A0 =A0 =A0 =A0 =A0 dime
Number_of_pages: 159

Abstract:
The Diameter base protocol is intended to provide an Authentication,
Authorization and Accounting (AAA) framework for applications such as
network access or IP mobility in both local and roaming situations.
This document specifies the message format, transport, error
reporting, accounting and security services used by all Diameter
applications. =A0The Diameter base protocol as defined in this document
must be supported by all Diameter implementations.



The IETF Secretariat.



--0016e6d77e886ed62604844ce146-- From root@core3.amsl.com Thu Apr 15 14:15:03 2010 Return-Path: X-Original-To: dime@ietf.org Delivered-To: dime@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 78FDA3A6BAA; Thu, 15 Apr 2010 14:15:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100415211502.78FDA3A6BAA@core3.amsl.com> Date: Thu, 15 Apr 2010 14:15:02 -0700 (PDT) Cc: dime@ietf.org Subject: [Dime] I-D Action:draft-ietf-dime-rfc3588bis-20.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2010 21:15:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Diameter Maintenance and Extensions Working Group of the IETF. Title : Diameter Base Protocol Author(s) : V. Fajardo, et al. Filename : draft-ietf-dime-rfc3588bis-20.txt Pages : 159 Date : 2010-04-15 The Diameter base protocol is intended to provide an Authentication, Authorization and Accounting (AAA) framework for applications such as network access or IP mobility in both local and roaming situations. This document specifies the message format, transport, error reporting, accounting and security services used by all Diameter applications. The Diameter base protocol as defined in this document must be supported by all Diameter implementations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dime-rfc3588bis-20.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-dime-rfc3588bis-20.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-04-15140501.I-D@ietf.org> --NextPart-- From gerardo.giaretta@gmail.com Tue Apr 20 05:29:51 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 705463A6889; Tue, 20 Apr 2010 05:29:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.12 X-Spam-Level: X-Spam-Status: No, score=0.12 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RAZOR2_CHECK=0.5, TVD_SPACE_RATIO=2.219] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sTwWd8fMAvux; Tue, 20 Apr 2010 05:29:50 -0700 (PDT) Received: from mail-qy0-f181.google.com (mail-qy0-f181.google.com [209.85.221.181]) by core3.amsl.com (Postfix) with ESMTP id 230C33A6BDA; Tue, 20 Apr 2010 05:28:24 -0700 (PDT) Received: by qyk11 with SMTP id 11so6419784qyk.13 for ; Tue, 20 Apr 2010 05:28:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:received:message-id :subject:from:to:content-type; bh=v2VUnpvW8aywfiRaAMDP9rESBw5F3eMAyl7Jre33JGE=; b=HggteO37ujqfvfEint26YGJ2fnlfnkvCMnELQsw16ylvGWsLx+hrtnJ1oF3sNUcNVK 3I29a3kQaptDNk+nxqiZ7rkOz8wcQqOZIS8oZepdpfO2Dbk0b0m6iv0Oi2Vb/jjwfTsf 3Jm2m4LnofWWb84XSCgbe+HHdutqyDkKm03aE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=DBAIuwRRNHV9/Gk817Jvh45aeHRIGLYQWdhW4Em9Yutm/43aYP13Gwjq7mTpujkz0o sfOX5TAcapORFHiw9v+ifLclSkyn7Cx5mVpWjqBUXyeYkjsX51Pxvc7S1cRUDJOJMFa0 MIPoCxvP9YMf6IcdLjJe9fadp0BYQpErMmqB8= MIME-Version: 1.0 Received: by 10.229.212.135 with HTTP; Tue, 20 Apr 2010 05:28:11 -0700 (PDT) Date: Tue, 20 Apr 2010 05:28:11 -0700 Received: by 10.229.97.207 with SMTP id m15mr2654965qcn.6.1271766491774; Tue, 20 Apr 2010 05:28:11 -0700 (PDT) Message-ID: From: Gerardo Giaretta To: denhollander.c.j@samsung.com, paola.destefanis@telecomitalia.it, dhcwg@ietf.org, dime@ietf.org, dime-ads@tools.ietf.org, dime-chairs@tools.ietf.org, Document_Services@hilton.com, eap-request@frascone.com Content-Type: text/plain; charset=ISO-8859-1 Subject: [Dime] peter urbaneck X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2010 12:29:51 -0000 http://jaintirth.net/home/index.php From sdecugis@nict.go.jp Tue Apr 20 21:59:05 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 079463A689D for ; Tue, 20 Apr 2010 21:59:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.933 X-Spam-Level: X-Spam-Status: No, score=0.933 tagged_above=-999 required=5 tests=[AWL=-1.391, BAYES_40=-0.185, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pJ7KBHKlW2Uv for ; Tue, 20 Apr 2010 21:59:04 -0700 (PDT) Received: from ns1.nict.go.jp (ns1.nict.go.jp [133.243.3.1]) by core3.amsl.com (Postfix) with ESMTP id 0BBDA3A6877 for ; Tue, 20 Apr 2010 21:59:03 -0700 (PDT) Received: from gw1.nict.go.jp (gw1 [133.243.18.250]) by ns1.nict.go.jp with ESMTP id o3L4wsAF021469 for ; Wed, 21 Apr 2010 13:58:54 +0900 (JST) Received: from gw1.nict.go.jp (localhost [127.0.0.1]) by gw1.nict.go.jp with ESMTP id o3L4wsBo004165 for ; Wed, 21 Apr 2010 13:58:54 +0900 (JST) Received: from mail1.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw1.nict.go.jp with ESMTP id o3L4wsT1004162 for ; Wed, 21 Apr 2010 13:58:54 +0900 (JST) Received: from mail1.nict.go.jp (localhost [127.0.0.1]) by mail1.nict.go.jp (NICT Mail) with ESMTP id 37BA82C5D3 for ; Wed, 21 Apr 2010 13:58:54 +0900 (JST) Received: from [133.243.146.171] (5gou2f-dhcp11.nict.go.jp [133.243.146.171]) by mail1.nict.go.jp (NICT Mail) with ESMTP id 33FD12C583 for ; Wed, 21 Apr 2010 13:58:54 +0900 (JST) Message-ID: <4BCE85FE.1000401@nict.go.jp> Date: Wed, 21 Apr 2010 13:58:38 +0900 From: Sebastien Decugis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: dime@ietf.org X-Enigmail-Version: 1.0.1 OpenPGP: id=33D9F61D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Dime] Termination-Cause IANA registry missing RFC4005 entries X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 04:59:05 -0000 Hello, I just noticed that the IANA registry for Termination-Cause AVP enumerated values [1] is missing the codes assigned from RFC4005 (NASREQ) in section 9.3.5. This RFC reserves the values 11 to 32 for mapping of RADIUS Acct-Terminate-Cause values. I am not sure if this should be reported to IANA or here? Is there a known reason why these values are not in the registry? Thank you! Sebastien. [1] http://www.iana.org/assignments/aaa-parameters/aaa-parameters.xml#aaa-parameters-16 -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) From dromasca@avaya.com Wed Apr 21 01:15:45 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A40BB28B23E for ; Wed, 21 Apr 2010 01:15:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.237 X-Spam-Level: X-Spam-Status: No, score=-2.237 tagged_above=-999 required=5 tests=[AWL=0.362, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XY5qJ7qneIqD for ; Wed, 21 Apr 2010 01:15:44 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 39D8E3A6AA6 for ; Wed, 21 Apr 2010 01:15:12 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.52,249,1270440000"; d="scan'208";a="214497875" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 21 Apr 2010 04:15:02 -0400 X-IronPort-AV: E=Sophos;i="4.52,249,1270440000"; d="scan'208";a="466453228" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.16]) by co300216-co-erhwest-out.avaya.com with ESMTP; 21 Apr 2010 04:15:02 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 21 Apr 2010 10:14:43 +0200 Message-ID: In-Reply-To: <4BCE85FE.1000401@nict.go.jp> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Termination-Cause IANA registry missing RFC4005 entries Thread-Index: AcrhD1ufDJPVzJ+eQn2LQSQS0oPN4QAG0PlQ References: <4BCE85FE.1000401@nict.go.jp> From: "Romascanu, Dan (Dan)" To: "Sebastien Decugis" , Subject: Re: [Dime] Termination-Cause IANA registry missing RFC4005 entries X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 08:15:45 -0000 Unless a good reason is found or remembered by somebody - this should be reported to IANA.=20 Dan =20 > -----Original Message----- > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On=20 > Behalf Of Sebastien Decugis > Sent: Wednesday, April 21, 2010 7:59 AM > To: dime@ietf.org > Subject: [Dime] Termination-Cause IANA registry missing=20 > RFC4005 entries >=20 > Hello, >=20 > I just noticed that the IANA registry for Termination-Cause=20 > AVP enumerated values [1] is missing the codes assigned from RFC4005 > (NASREQ) in section 9.3.5. This RFC reserves the values 11 to=20 > 32 for mapping of RADIUS Acct-Terminate-Cause values. I am=20 > not sure if this should be reported to IANA or here? Is there=20 > a known reason why these values are not in the registry? >=20 > Thank you! > Sebastien. >=20 > [1] > http://www.iana.org/assignments/aaa-parameters/aaa-parameters. > xml#aaa-parameters-16 >=20 > -- > Sebastien Decugis > Research fellow > Network Architecture Group > NICT (nict.go.jp) >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime >=20 From mark@azu.ca Thu Apr 22 06:05:50 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B805C28C0DB for ; Thu, 22 Apr 2010 06:05:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.253 X-Spam-Level: X-Spam-Status: No, score=0.253 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_20=-0.74, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 221oetUNTBfn for ; Thu, 22 Apr 2010 06:05:46 -0700 (PDT) Received: from mail-bw0-f225.google.com (mail-bw0-f225.google.com [209.85.218.225]) by core3.amsl.com (Postfix) with ESMTP id 6822D3A6AA0 for ; Thu, 22 Apr 2010 06:05:45 -0700 (PDT) Received: by bwz25 with SMTP id 25so9604782bwz.28 for ; Thu, 22 Apr 2010 06:05:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.239.131.134 with HTTP; Thu, 22 Apr 2010 06:05:31 -0700 (PDT) In-Reply-To: References: <20100415210501.A3CA83A6A72@core3.amsl.com> Date: Thu, 22 Apr 2010 09:05:31 -0400 Received: by 10.239.131.211 with SMTP id 19mr887623hbo.63.1271941531447; Thu, 22 Apr 2010 06:05:31 -0700 (PDT) Message-ID: From: Mark Jones To: Victor Fajardo Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dime@ietf.org Subject: Re: [Dime] New Version Notification for draft-ietf-dime-rfc3588bis-20 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 13:05:50 -0000 Hi Victor, On Thu, Apr 15, 2010 at 5:07 PM, Victor Fajardo wrote: > Hi Lionel/Jouni, > > I've just publish an updated rev of bis. Do you think we can proceed with= a > writeup and send it on its way ? > Thanks for providing the new rev. I reviewed the diff from -19 and noticed a minor typo: Section 5.2 Diameter Peer Discovery. Third paragraph in step 2: s/diameter.tls/diameter.tls.tcp/ Regarding your question to the chairs, I see no reason why this can not be progressed. It is probably not perfect but I feel the major errors have been addressed and we have the errata process to clean up any remaining minor issues. Though I'm responsible for a few of those 20 revs to 3588bis, I hope we can get it on the fast track to publication because the major errors in 3588 are being propagated into new Diameter applications as I type. If 3588bis stalls then I'm submitting the mother of all errata on 3588 instead. ;) Regards Mark > regards, > victor > > > On Thu, Apr 15, 2010 at 4:05 PM, IETF I-D Submission Tool > wrote: >> >> A new version of I-D, draft-ietf-dime-rfc3588bis-20.txt has been >> successfully submitted by Victor Fajardo and posted to the IETF reposito= ry. >> >> Filename: =A0 =A0 =A0 =A0draft-ietf-dime-rfc3588bis >> Revision: =A0 =A0 =A0 =A020 >> Title: =A0 =A0 =A0 =A0 =A0 Diameter Base Protocol >> Creation_date: =A0 2010-04-15 >> WG ID: =A0 =A0 =A0 =A0 =A0 dime >> Number_of_pages: 159 >> >> Abstract: >> The Diameter base protocol is intended to provide an Authentication, >> Authorization and Accounting (AAA) framework for applications such as >> network access or IP mobility in both local and roaming situations. >> This document specifies the message format, transport, error >> reporting, accounting and security services used by all Diameter >> applications. =A0The Diameter base protocol as defined in this document >> must be supported by all Diameter implementations. >> >> >> >> The IETF Secretariat. >> >> > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > > From vf0213@gmail.com Thu Apr 22 06:14:38 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C11B63A6AFC for ; Thu, 22 Apr 2010 06:14:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.074 X-Spam-Level: X-Spam-Status: No, score=-2.074 tagged_above=-999 required=5 tests=[AWL=0.524, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AUJBZ7t8CqBh for ; Thu, 22 Apr 2010 06:14:36 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 46F1F3A6AAD for ; Thu, 22 Apr 2010 06:14:24 -0700 (PDT) Received: by wwb24 with SMTP id 24so1232653wwb.31 for ; Thu, 22 Apr 2010 06:14:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=hUqZ8aQn2xw93wxVl7tCJzKbYDAkqUnEMdx0Wwggmgc=; b=TW0HXBk3XSJhr3oB5wnCzZxPCoeRzGKlVT5ffzdgPHwYSSyFHwa1o8S0yirMMr+N0y v4S+Z0jtteIAu+5sfyTeBSKPUNncgC7rxRwKlY6cCy4dQRcJeJnIi1VT2ohvv7WfBqKf uk7D2P4dfbsH10frqySfggPQxWLrWQIQGLMHg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=NOGZy8Kaf3RCMFGH+xN37PD+KUBP36b3rs8jpRzPMhpcGiGNIPp7TtW3US3K7bccxw Wv6fK4oOkk6oAEPqDcyl54MSYsMMI0s8TCPwIkHdgTmS88FjBmCtjmg6UZXuRGodxA+j tfZ+5XytCQkFLCwgRT8QXIeg027AziGC9qVxA= MIME-Version: 1.0 Received: by 10.216.159.131 with HTTP; Thu, 22 Apr 2010 06:14:08 -0700 (PDT) In-Reply-To: References: <20100415210501.A3CA83A6A72@core3.amsl.com> Date: Thu, 22 Apr 2010 08:14:08 -0500 Received: by 10.216.154.145 with SMTP id h17mr2589966wek.103.1271942048570; Thu, 22 Apr 2010 06:14:08 -0700 (PDT) Message-ID: From: Victor Fajardo To: Mark Jones Content-Type: multipart/alternative; boundary=0016e6563b78fb19fe0484d315b0 Cc: dime@ietf.org Subject: Re: [Dime] New Version Notification for draft-ietf-dime-rfc3588bis-20 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 13:14:38 -0000 --0016e6563b78fb19fe0484d315b0 Content-Type: text/plain; charset=ISO-8859-1 Hi Mark, Thanks. I'll update those typo's as we move along the submission process. I would ask the chairs if we can do a write-up for bis and submit it as soon as possible. regards, victor On Thu, Apr 22, 2010 at 8:05 AM, Mark Jones wrote: > Hi Victor, > > On Thu, Apr 15, 2010 at 5:07 PM, Victor Fajardo wrote: > > Hi Lionel/Jouni, > > > > I've just publish an updated rev of bis. Do you think we can proceed with > a > > writeup and send it on its way ? > > > > Thanks for providing the new rev. I reviewed the diff from -19 and > noticed a minor typo: > > Section 5.2 Diameter Peer Discovery. > Third paragraph in step 2: > s/diameter.tls/diameter.tls.tcp/ > > Regarding your question to the chairs, I see no reason why this can > not be progressed. It is probably not perfect but I feel the major > errors have been addressed and we have the errata process to clean up > any remaining minor issues. > > Though I'm responsible for a few of those 20 revs to 3588bis, I hope > we can get it on the fast track to publication because the major > errors in 3588 are being propagated into new Diameter applications as > I type. If 3588bis stalls then I'm submitting the mother of all errata > on 3588 instead. ;) > > Regards > Mark > > > regards, > > victor > > > > > > On Thu, Apr 15, 2010 at 4:05 PM, IETF I-D Submission Tool > > wrote: > >> > >> A new version of I-D, draft-ietf-dime-rfc3588bis-20.txt has been > >> successfully submitted by Victor Fajardo and posted to the IETF > repository. > >> > >> Filename: draft-ietf-dime-rfc3588bis > >> Revision: 20 > >> Title: Diameter Base Protocol > >> Creation_date: 2010-04-15 > >> WG ID: dime > >> Number_of_pages: 159 > >> > >> Abstract: > >> The Diameter base protocol is intended to provide an Authentication, > >> Authorization and Accounting (AAA) framework for applications such as > >> network access or IP mobility in both local and roaming situations. > >> This document specifies the message format, transport, error > >> reporting, accounting and security services used by all Diameter > >> applications. The Diameter base protocol as defined in this document > >> must be supported by all Diameter implementations. > >> > >> > >> > >> The IETF Secretariat. > >> > >> > > > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www.ietf.org/mailman/listinfo/dime > > > > > --0016e6563b78fb19fe0484d315b0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Mark,

Thanks. I'll update those typo's as we move along t= he submission process. I would ask the chairs if we can do a write-up for b= is and submit it as soon as possible.

regards,
victor


On Thu, Apr 22, 2010 at 8:05 AM, Mark Jones <mark@azu.ca>= wrote:
Hi Victor,

On Thu, Apr 15, 2010 at 5:07 PM, Victor Fajardo <vf0213@gmail.com> wrote:
> Hi Lionel/Jouni,
>
> I've just publish an updated rev of bis. Do you think we can proce= ed with a
> writeup and send it on its way ?
>

Thanks for providing the new rev. I reviewed the diff from -19 and noticed a minor typo:

Section 5.2 Diameter Peer Discovery.
Third paragraph in step 2:
s/diameter.tls/diameter.tls.tcp/

Regarding your question to the chairs, I see no reason why this can
not be progressed. It is probably not perfect but I feel the major
errors have been addressed and we have the errata process to clean up
any remaining minor issues.

Though I'm responsible for a few of those 20 revs to 3588bis, I hope we can get it on the fast track to publication because the major
errors in 3588 are being propagated into new Diameter applications as
I type. If 3588bis stalls then I'm submitting the mother of all errata<= br> on 3588 instead. ;)

Regards
Mark

> regards,
> victor
>
>
> On Thu, Apr 15, 2010 at 4:05 PM, IETF I-D Submission Tool
> <idsubmission@ietf.org= > wrote:
>>
>> A new version of I-D, draft-ietf-dime-rfc3588bis-20.txt has been >> successfully submitted by Victor Fajardo and posted to the IETF re= pository.
>>
>> Filename: =A0 =A0 =A0 =A0draft-ietf-dime-rfc3588bis
>> Revision: =A0 =A0 =A0 =A020
>> Title: =A0 =A0 =A0 =A0 =A0 Diameter Base Protocol
>> Creation_date: =A0 2010-04-15
>> WG ID: =A0 =A0 =A0 =A0 =A0 dime
>> Number_of_pages: 159
>>
>> Abstract:
>> The Diameter base protocol is intended to provide an Authenticatio= n,
>> Authorization and Accounting (AAA) framework for applications such= as
>> network access or IP mobility in both local and roaming situations= .
>> This document specifies the message format, transport, error
>> reporting, accounting and security services used by all Diameter >> applications. =A0The Diameter base protocol as defined in this doc= ument
>> must be supported by all Diameter implementations.
>>
>>
>>
>> The IETF Secretariat.
>>
>>
>
>
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
>
>

--0016e6563b78fb19fe0484d315b0-- From sdecugis@nict.go.jp Thu Apr 22 18:30:40 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 166293A6841 for ; Thu, 22 Apr 2010 18:30:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.073 X-Spam-Level: X-Spam-Status: No, score=0.073 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lf3027-7Bpty for ; Thu, 22 Apr 2010 18:30:38 -0700 (PDT) Received: from ns1.nict.go.jp (ns1.nict.go.jp [133.243.3.1]) by core3.amsl.com (Postfix) with ESMTP id 3AD973A67F4 for ; Thu, 22 Apr 2010 18:30:38 -0700 (PDT) Received: from gw1.nict.go.jp (gw1 [133.243.18.250]) by ns1.nict.go.jp with ESMTP id o3N1ULWV014683; Fri, 23 Apr 2010 10:30:21 +0900 (JST) Received: from gw1.nict.go.jp (localhost [127.0.0.1]) by gw1.nict.go.jp with ESMTP id o3N1ULTF015770; Fri, 23 Apr 2010 10:30:21 +0900 (JST) Received: from mail3.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw1.nict.go.jp with ESMTP id o3N1ULV6015767; Fri, 23 Apr 2010 10:30:21 +0900 (JST) Received: from mail3.nict.go.jp (localhost [127.0.0.1]) by mail3.nict.go.jp (NICT Mail) with ESMTP id 75ECB15F5A; Fri, 23 Apr 2010 10:30:21 +0900 (JST) Received: from [133.243.146.171] (5gou2f-dhcp11.nict.go.jp [133.243.146.171]) by mail3.nict.go.jp (NICT Mail) with ESMTP id 7064015F34; Fri, 23 Apr 2010 10:30:21 +0900 (JST) Message-ID: <4BD0F81C.2020801@nict.go.jp> Date: Fri, 23 Apr 2010 10:30:04 +0900 From: Sebastien Decugis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" References: <4BCE85FE.1000401@nict.go.jp> In-Reply-To: X-Enigmail-Version: 1.0.1 OpenPGP: id=33D9F61D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: dime@ietf.org Subject: Re: [Dime] Termination-Cause IANA registry missing RFC4005 entries X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Apr 2010 01:30:40 -0000 Thank you Dan for your answer. Since there has been no other comment, I will go forward and contact IANA about this issue. Best regards, Sebastien. Le 21/04/2010 17:14, Romascanu, Dan (Dan) a écrit : > Unless a good reason is found or remembered by somebody - this should be > reported to IANA. > > Dan > > > >> -----Original Message----- >> From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On >> Behalf Of Sebastien Decugis >> Sent: Wednesday, April 21, 2010 7:59 AM >> To: dime@ietf.org >> Subject: [Dime] Termination-Cause IANA registry missing >> RFC4005 entries >> >> Hello, >> >> I just noticed that the IANA registry for Termination-Cause >> AVP enumerated values [1] is missing the codes assigned from RFC4005 >> (NASREQ) in section 9.3.5. This RFC reserves the values 11 to >> 32 for mapping of RADIUS Acct-Terminate-Cause values. I am >> not sure if this should be reported to IANA or here? Is there >> a known reason why these values are not in the registry? >> >> Thank you! >> Sebastien. >> >> [1] >> http://www.iana.org/assignments/aaa-parameters/aaa-parameters. >> xml#aaa-parameters-16 >> >> -- >> Sebastien Decugis >> Research fellow >> Network Architecture Group >> NICT (nict.go.jp) >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >> >> > -- Sebastien Decugis Research fellow Network Architecture Group NICT (nict.go.jp) From victor.pascual.avila@gmail.com Mon Apr 26 00:54:44 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 949CE3A6869 for ; Mon, 26 Apr 2010 00:54:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UD3-msQEKurJ for ; Mon, 26 Apr 2010 00:54:40 -0700 (PDT) Received: from mail-bw0-f217.google.com (mail-bw0-f217.google.com [209.85.218.217]) by core3.amsl.com (Postfix) with ESMTP id 619A73A6907 for ; Mon, 26 Apr 2010 00:54:38 -0700 (PDT) Received: by bwz9 with SMTP id 9so1665613bwz.29 for ; Mon, 26 Apr 2010 00:54:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type:content-transfer-encoding; bh=O0c+4gNI/ywFcsFIxa+Qw2LU1pigwnlPsj6sONx+Uy0=; b=eeaqgIQSyzlZbWFuXH5+g7Ze1RYaLuijfp9FQ89TZrL/d6AaJyqimrkK2r0H1uLoEJ nFXF6bs+1eqRZCPckqZSMqJQYjOBfTP6SWCTu9htqpaT/NeOw/QB+FT9u2TW/aP1/ODm MiAy1HTXdDHhQOUEJQJOomt+spJVCP5ZJoufc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=t34CiGRxhpW8VEtAb72Zh5P2F79S/FN3D+aLB/C/pJZxjD7ypfJkUHc6E9E/YanHVy mwMp06NE8WQtBBwM/UuF0KOZ72C2mzAF/Awfunm7gtf1SnByj8KmnMzEiCfe+WCNf+Bc z/1GtkqSCB8kMftrpEUFTd3flA8ONEuBqyvZA= MIME-Version: 1.0 Received: by 10.204.162.199 with SMTP id w7mr2305167bkx.211.1272268463121; Mon, 26 Apr 2010 00:54:23 -0700 (PDT) Received: by 10.204.71.9 with HTTP; Mon, 26 Apr 2010 00:54:23 -0700 (PDT) Date: Mon, 26 Apr 2010 09:54:23 +0200 Message-ID: From: Victor Pascual Avila To: dime@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: [Dime] RFC 3588 (Diameter Base Protocol) - Section 2.1.1. SCTP Guidelines X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2010 07:54:44 -0000 Hi, Apologies in case this is not the appropriate list for the question below-- I'd appreciate pointers to any other list. RFC 3588 - Section 2.1.1 (SCTP Guidelines) states the following: "To prevent blocking: All Diameter nodes SHOULD utilize all SCTP streams available to the association to prevent head-of-the-line blocking." While RFC 3539 - Section 3.8.1 (Using SCTP Streams to Prevent Head of Line Blocking) also addresses multi-streaming, it's not clear to me whether: a) Diameter transactions need to be mapped into SCTP streams (ie; send Diameter messages belonging to the same transaction over the same SCTP stream and messages belonging to different transactions over different SCTP streams-- as long as there are enough available streams) b) Ordered vs unordered delivery: for the above mechanism, I understand TLS would require ordered delivery. When TLS is not used (say, IPSec is used instead), do we really need ordered delivery? Thanks in advance for any clarification, --=20 Victor Pascual =C3=81vila From jouni.nospam@gmail.com Mon Apr 26 04:29:58 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F1123A6B83 for ; Mon, 26 Apr 2010 04:29:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.407 X-Spam-Level: X-Spam-Status: No, score=-0.407 tagged_above=-999 required=5 tests=[AWL=-0.408, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6mVIiTpjCmFD for ; Mon, 26 Apr 2010 04:29:57 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.152]) by core3.amsl.com (Postfix) with ESMTP id 639FE3A6B87 for ; Mon, 26 Apr 2010 04:29:47 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id l26so259578fgb.13 for ; Mon, 26 Apr 2010 04:29:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:content-type :content-transfer-encoding:subject:date:message-id:cc:to :mime-version:x-mailer; bh=BDw/iRtYstleVubtWyW4W5VkbKLqpohdWromUs1qbD4=; b=eqU+uIzQXmzhQqH5gLI8quMTf0ZinGuG14OMuaxKYUakoXwYt1xB8B68wIp46v4poZ RajMCgrITC2FZ7hvBv7YjeGizbhTP1uDwqJnsY/mj0jkoSkP0q5Ud5B0T0Awfu2g0S9z 3Wg9oL01kJ0fg+bFE6w94++0XDFVilwHJOv3k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version:x-mailer; b=S9qznLbV2FfXw6KGfPCNA6aPCIs72Jlz8WKbwzrm5zKjIoskT+hec9FxsCb7PfRYTv umtzNDGPtviO71ptVo2vL/NicIjVO9E+PElpSr72SU+TexOjD/ZRqzD54rQDFOrKHORQ ZICWXKJgsSKXAZmlM5teBHe5SIyLs8gDgeO5I= Received: by 10.87.5.30 with SMTP id h30mr1947283fgi.3.1272281371488; Mon, 26 Apr 2010 04:29:31 -0700 (PDT) Received: from a88-114-71-96.elisa-laajakaista.fi (a88-114-71-96.elisa-laajakaista.fi [88.114.71.96]) by mx.google.com with ESMTPS id 9sm8208247fks.56.2010.04.26.04.29.29 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 26 Apr 2010 04:29:30 -0700 (PDT) From: jouni korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 26 Apr 2010 14:29:31 +0300 Message-Id: <10A80F70-2ED3-4A02-9711-7A5ED6C702D1@gmail.com> To: dime@ietf.org Mime-Version: 1.0 (Apple Message framework v1078) X-Mailer: Apple Mail (2.1078) Subject: [Dime] Another round of WGLCs and WG status X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2010 11:29:58 -0000 Hi all, The following drafts have been in kind of a limbo for quite some time. 1) draft-ietf-dime-priority-avps WGLC ended 16th Mar 2) draft-ietf-dime-capablities-update WGLC ended 23rd Jan 3) draft-ietf-dime-local-keytran WGLC ended 7th Mar 4) draft-ietf-dime-rfc3588bis WGLC ended 5th July=20 5) draft-ietf-dime-app-design-guide The WGLC for draft-ietf-dime-local-keytran-01 ended 7th Match. We = received only *one* review and a subsequent draft revision. Although, a = WGLC stands for the "last call", we decided to run one quick more due = the low number of reviews. Please, review the document and give any = indication whether you are fine with it or not. The WGLC#2 ends 10th = May. The WGLC for draft-ietf-dime-priority-avps ended 16th March. We received = *one* comment and decided to run one more based on the same reasons as = above. Please, review the document and give any indication whether you = are fine with it or not. The WGLC#2 ends 10th May. Although it may not look like it, we definitely intend to move above two = documents forward as soon as possible. I encourage respective authors to = work offline to get people to review their documents. Lionel and I will have a look at draft-ietf-dime-app-design-guide, and = hopefully get the document move forward soon. Jouni will write a proto write-up and shepherd the rfc3588bis (after I = actually have read latest revision). Lionel will write a proto write-up and shepherd the capablities-update. Jouni & Lionel= From xiayangsong@huawei.com Thu Apr 29 16:05:39 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F40E3A6899 for ; Thu, 29 Apr 2010 16:05:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.277 X-Spam-Level: * X-Spam-Status: No, score=1.277 tagged_above=-999 required=5 tests=[AWL=-0.829, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ghZfeYEZ-zRj for ; Thu, 29 Apr 2010 16:05:36 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 634533A6844 for ; Thu, 29 Apr 2010 16:05:36 -0700 (PDT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L1N00AFTUSOJD@szxga01-in.huawei.com> for dime@ietf.org; Fri, 30 Apr 2010 07:05:12 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L1N00ELYUSOXA@szxga01-in.huawei.com> for dime@ietf.org; Fri, 30 Apr 2010 07:05:12 +0800 (CST) Received: from X24512z ([10.124.12.81]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L1N003AOUSMWO@szxml04-in.huawei.com> for dime@ietf.org; Fri, 30 Apr 2010 07:05:12 +0800 (CST) Date: Thu, 29 Apr 2010 18:05:09 -0500 From: Frank Xia To: dime@ietf.org Message-id: <001c01cae7f0$6b746d40$510c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_95g6JKYGu37USLNoGz+Apg)" Thread-index: Acrn8GohdewvN1TVQHCid0NJ77Jnrg== Subject: [Dime] comments on draft-ietf-dime-local-keytran-02 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Apr 2010 23:05:39 -0000 This is a multi-part message in MIME format. --Boundary_(ID_95g6JKYGu37USLNoGz+Apg) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi all Per Qin's request, I have reviewed the draft which is simple and clear. However, I did observe that there is no "Attribute Value Pair Occurrence Tables" section which is very useful for implementation. There is also a typo in section 3.1.5 which says ".The Key-SPI AVP (AVP Code ) is of is of type Unsigned32" BR Frank --Boundary_(ID_95g6JKYGu37USLNoGz+Apg) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

Hi = all

 

Per Qin’s request, I have reviewed =

the draft which is simple and = clear.

 

However, I did observe that there is = no

“Attribute Value Pair Occurrence = Tables” section

which is very useful for = implementation.

 

There is also a typo in section 3.1.5  = which

says “…The Key-SPI AVP (AVP Code <AC5>)

is of is of type = Unsigned32”

 

BR

Frank

--Boundary_(ID_95g6JKYGu37USLNoGz+Apg)-- From gwz@net-zen.net Fri Apr 30 22:17:32 2010 Return-Path: X-Original-To: dime@core3.amsl.com Delivered-To: dime@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 722F03A6A55 for ; Fri, 30 Apr 2010 22:17:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.494 X-Spam-Level: X-Spam-Status: No, score=-0.494 tagged_above=-999 required=5 tests=[AWL=-0.496, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ovU0DqliDgss for ; Fri, 30 Apr 2010 22:17:18 -0700 (PDT) Received: from p3plsmtpa01-02.prod.phx3.secureserver.net (p3plsmtpa01-02.prod.phx3.secureserver.net [72.167.82.82]) by core3.amsl.com (Postfix) with SMTP id 0B3543A69E9 for ; Fri, 30 Apr 2010 22:17:12 -0700 (PDT) Received: (qmail 13812 invoked from network); 1 May 2010 05:16:56 -0000 Received: from unknown (115.67.139.220) by p3plsmtpa01-02.prod.phx3.secureserver.net (72.167.82.82) with ESMTP; 01 May 2010 05:16:50 -0000 From: "Glen Zorn" To: "'Frank Xia'" References: <001c01cae7f0$6b746d40$510c7c0a@china.huawei.com> In-Reply-To: <001c01cae7f0$6b746d40$510c7c0a@china.huawei.com> Date: Sat, 1 May 2010 12:16:40 +0700 Organization: Network Zen Message-ID: <023201cae8ed$7fa4f250$7eeed6f0$@net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0233_01CAE928.2C03CA50" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acrn8GohdewvN1TVQHCid0NJ77JnrgA+7P/w Content-Language: en-us Cc: dime@ietf.org Subject: Re: [Dime] comments on draft-ietf-dime-local-keytran-02 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 May 2010 05:17:32 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0233_01CAE928.2C03CA50 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Frank Xia [mailto://xiayangsong@huawei.com] writes: Hi all Per Qin's request, I have reviewed the draft which is simple and clear. However, I did observe that there is no "Attribute Value Pair Occurrence Tables" section which is very useful for implementation. That was present in -00 but was removed in response to a comment by Hannes. There is also a typo in section 3.1.5 which says ".The Key-SPI AVP (AVP Code ) is of is of type Unsigned32" Fixed, thanks! BR Frank ------=_NextPart_000_0233_01CAE928.2C03CA50 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Frank Xia [mailto://xiayangsong@huawei.com] writes:

 

Hi all

 

Per Qin’s request, I have reviewed

the draft which is simple and clear.

 

However, I did observe that there is no

“Attribu= te Value Pair Occurrence Tables” section

which is very useful for implementation.

That was present in -00 but was removed in response to a = comment by Hannes.

 

There is also a typo in section 3.1.5  which

says “…The Key-SPI AVP (AVP Code <AC5>) =

is of is of type Unsigned32”

Fixed, thanks!

 

BR<= /span>

Frank

------=_NextPart_000_0233_01CAE928.2C03CA50--