From nobody Mon Dec 8 11:59:33 2014 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E2061A8873 for ; Mon, 8 Dec 2014 11:59:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 967RZWdmn7i3 for ; Mon, 8 Dec 2014 11:59:28 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACE261A885D for ; Mon, 8 Dec 2014 11:59:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13751; q=dns/txt; s=iport; t=1418068768; x=1419278368; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=IH5KiI99SKbU9hqhwQoRDP085hHDBGJoYK4MjrksPHw=; b=QKW3aXF4OJB4UyuYJDnE4KIL74e8AdUWvDJ4DQd4syBQqmGEPDI/XB5C ORbYl1JaP3ALV+Mk8ECKXVKX1kl7rpTgN004Za7t3pVdM5o7F8KWMlNi5 qV6QAsTOrtR8UMRGQw0oswC6TtSy0VOGSP6onF21VIBS/b576b1Bizgff 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FAEMChlStJA2I/2dsb2JhbABZgkNDUlzEBIFshgcCgTMWAQEBAQF9hAIBAQEELUwQAgEIEQMBAigHMhQJCAEBBAENBYg4DdYmAQEBAQEBAQEBAQEBAQEBAQEBAQEBF5ArDQQHhDYFjDOBWoNZhTyBDTCMT4Neg25vgUV+AQEB X-IronPort-AV: E=Sophos;i="5.07,540,1413244800"; d="scan'208,217";a="103770101" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-8.cisco.com with ESMTP; 08 Dec 2014 19:59:25 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id sB8JxOfA027472 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 8 Dec 2014 19:59:24 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.252]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0195.001; Mon, 8 Dec 2014 13:59:24 -0600 From: "Charles Eckel (eckelcu)" To: Christer Holmberg , "bfcpbis@ietf.org" Thread-Topic: Comments on draft-ietf-bfcpbis-rfc4583bis-10 Thread-Index: AdARgmEI5ESuyJkDTsuliRtAbu7OYQBjlDwA Date: Mon, 8 Dec 2014 19:59:23 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D582373@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D582373@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.154.176.39] Content-Type: multipart/alternative; boundary="_000_D0AB3DF138C20eckelcuciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/bfcpbis/m9zSephowS7InfUAYUnfANrej6g Cc: "Tom Kristensen \(tomkrist\)" Subject: Re: [bfcpbis] Comments on draft-ietf-bfcpbis-rfc4583bis-10 X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Dec 2014 19:59:30 -0000 --_000_D0AB3DF138C20eckelcuciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Christer, Thanks for the thorough review and insightful comments. I=92ve forwarded to= the BFCP list, adding a few comments (as an individual) inline. I expect o= thers to comment as well. More inline. From: Christer Holmberg > Date: Sunday, December 7, 2014 at 3:42 AM To: Charles Eckel > Subject: Comments on draft-ietf-bfcpbis-rfc4583bis-10 Hi Charles, My comments on RFC4583bis. Q1: There is a new =93template=94 for defining SDP attributes. It has been disc= ussed on the MMUSIC list, and Paul K can give more information if needed. A ptr to that would be helpful. I scanned the MMUSIC list quickly but must = have missed it. Q2: Most SDP attributes are defined in their own sections =96 which is good. Bu= t, sometimes the section name contains the name of the attribute, and somet= imes not. I think it would be good to be consistent, and always call the se= ction =93SDP xxx attribute=94. Q3: There is no dedicated SDP Offer/Answer procedure section (instead, each sec= tion defining an SDP attribute include a few sentences about Offer/Answer). I think it would be good to have a dedicated SDP Offer/Answer procedure sec= tion, following the structure in RFC 3264. I=92ve had to do that e.g. for B= UNDLE and SCTP-SDP. I had a look at http://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-neg= otiation-13 as an example. I see how we could rename and reorganize the exi= sting content along these lines. I struggle with this a bit because I am co= mfortable with the existing document structure and my familiarity with it m= ake it straightforward for me to understand. For a new reader, I think your= suggested change will help, so I=92m in favor of it. Q4: For DTLS and Offer/Answer, there are a few references to RFC 5763 here and = there. But, I think it would be good to have explicit text on the Offer/Ans= wer considerations regarding DTLS =96 especially since there have been quit= e a bit of discussions about that lately. Are you suggesting a copy/paste of the relevant text from RFC 5763 in addit= ional to a reference, or is there an calcification of what is provided in R= FC 5763 that you added for SCTP that would be helpful for this draft? Q5: The draft does not define how to use BFCP within a BUNDLE group. That is fi= ne, but I think it would be good to explicitly indicate that. Yes. I=92m thinking we need to point to https://tools.ietf.org/html/draft-i= etf-mmusic-sdp-mux-attributes-05#page-28 for attributes defined in RFC 4583= , and define the mux category for new attributes defined within this draf= t. Cheers, Charles Regards, Christer --_000_D0AB3DF138C20eckelcuciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Christer,

Thanks for the thorough review and i= nsightful comments. I=92ve forwarded to the BFCP list, adding a few comment= s (as an individual) inline. I expect others to comment as well. = More inline.

From: Christer Holmberg <christer.holmberg@ericsson.com>
Date: Sunday, December 7, 2014 at 3= :42 AM
To: Charles Eckel <
eckelcu@cisco.com>
Subject: Comments on draft-ietf-bfc= pbis-rfc4583bis-10

Hi Charles,

 

My comments on RFC4583bis.

 

 

Q1:

 

There is a new =93template=94 for defining SDP attri= butes. It has been discussed on the MMUSIC list, and Paul K can give more i= nformation if needed.


A ptr to that would be helpful. I scanned the MMUSIC list quickly but = must have missed it.

 

 

Q2:

 

Most SDP attributes are defined in their own section= s =96 which is good. But, sometimes the section name contains the name of t= he attribute, and sometimes not. I think it would be good to be consistent,= and always call the section =93SDP xxx attribute=94.

 

 

Q3:

 

There is no dedicated SDP Offer/Answer procedure sec= tion (instead, each section defining an SDP attribute include a few sentenc= es about Offer/Answer).

 

I think it would be good to have a dedicated SDP Off= er/Answer procedure section, following the structure in RFC 3264. I=92ve ha= d to do that e.g. for BUNDLE and SCTP-SDP.


I had a look at http://tools.ietf.org/html/draft-ietf-mmu= sic-sdp-bundle-negotiation-13 as an example. I see how we could re= name and reorganize the existing content along these lines. I struggle with this a bit because I am comfortable with the = existing document structure and my familiarity with it make it straightforw= ard for me to understand. For a new reader, I think your suggested change w= ill help, so I=92m in favor of it.


 

 

Q4:

 

For DTLS and Offer/Answer, there are a few reference= s to RFC 5763 here and there. But, I think it would be good to have explici= t text on the Offer/Answer considerations regarding DTLS =96 especially sin= ce there have been quite a bit of discussions about that lately.

 


Are you suggesting a copy/paste of the relevant text from RFC 5763 in = additional to a reference, or is there an calcification of what is provided= in RFC 5763 that you added for SCTP that would be helpful for this draft?&= nbsp;


 

Q5:

 

The draft does not define how to use BFCP within a B= UNDLE group. That is fine, but I think it would be good to explicitly indic= ate that.


Yes. I=92m thinking we need to point to https://tools.ietf.org/html/draft-ietf-mmusic-sdp-mux-attributes-05#page-28=  for attributes defined in RFC 4583, and  define  the mu= x category for new attributes defined within this draft.

Cheers,
Charles

 

 

Regards,

 

Christer

 

--_000_D0AB3DF138C20eckelcuciscocom_-- From nobody Tue Dec 9 00:17:12 2014 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B9931A6F3C for ; Tue, 9 Dec 2014 00:17:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9bQUNV7q88U0 for ; Tue, 9 Dec 2014 00:17:06 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29B0C1A6F41 for ; Tue, 9 Dec 2014 00:17:05 -0800 (PST) X-AuditID: c1b4fb2d-f79fc6d000001087-1c-5486afffeb77 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 40.65.04231.FFFA6845; Tue, 9 Dec 2014 09:17:04 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.189]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0195.001; Tue, 9 Dec 2014 09:17:03 +0100 From: Christer Holmberg To: "Charles Eckel (eckelcu)" , "bfcpbis@ietf.org" Thread-Topic: Comments on draft-ietf-bfcpbis-rfc4583bis-10 Thread-Index: AdARgmEI5ESuyJkDTsuliRtAbu7OYQBjlDwAABy8dMA= Date: Tue, 9 Dec 2014 08:17:03 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D588C28@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D582373@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrALMWRmVeSWpSXmKPExsUyM+JvjS7DhrYQgw9T2Sz+rTvKZLFp1hc2 iytHfrE5MHtM+b2R1WPJkp9MAUxRXDYpqTmZZalF+nYJXBn7FioWvPCrmPbkH1MD4xObLkZO DgkBE4nls3qZIGwxiQv31rN1MXJxCAkcYZT4sWUTK4SzmFHiy7xVQA4HB5uAhUT3P20QU0Qg SmLjNiGQXmagOfvu/gebIyxgKTF581swW0TASmLd8c9wdsu8U6wgNouAisTah9tZQGxeAV+J KdsbwWqEBIok/l06wQZicwroS8xveAwWZwS67fupNUwQu8Qlbj2ZD3WzgMSSPeeZIWxRiZeP /7FC2EoSPzZcYoGo15O4MXUKG4StLbFs4WtmiL2CEidnPmGZwCg2C8nYWUhaZiFpmYWkZQEj yypG0eLU4uLcdCNjvdSizOTi4vw8vbzUkk2MwCg6uOW37g7G1a8dDzEKcDAq8fBuSG0LEWJN LCuuzD3EKM3BoiTOu+jcvGAhgfTEktTs1NSC1KL4otKc1OJDjEwcnFINjFbz/T4+zN3574tJ Zle4/LQzy37++CPFIDt99sr0BN9NP3R/ajVIyn+M0DB8WT993tMz8hofvqqYGT87EiMZ8cns UMCZmIWLdVj6PG7qHd3UKvre94xb9IQQxwdzHW84Hn9jtL2570do9uncHu3c8LcN33sreeyb WhgDp77yLe9anOld/nirnhJLcUaioRZzUXEiAHPe1nmDAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/bfcpbis/fzEqmAYPctY2zqVNV1SVskD8dXA Cc: "Tom Kristensen \(tomkrist\)" Subject: Re: [bfcpbis] Comments on draft-ietf-bfcpbis-rfc4583bis-10 X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2014 08:17:09 -0000 Hi, =A0 >> Q1: >>=A0 >> There is a new "template" for defining SDP attributes. It has been discu= ssed on the MMUSIC list, and Paul K can give more information if needed. > > A ptr to that would be helpful. I scanned the MMUSIC list quickly but mus= t have missed it. Please look at section 6 in https://tools.ietf.org/id/draft-ietf-mmusic-rfc= 4566bis-12.txt =A0 =A0 >> Q2: >> >> Most SDP attributes are defined in their own sections - which is good. B= ut, sometimes the section name contains the name of the attribute, and some= times not. I think it would be good to be consistent, and always call the s= ection "SDP xxx attribute". >>=A0 >> Q3: =A0> > There is no dedicated SDP Offer/Answer procedure section (instead, each s= ection defining an SDP attribute include a few sentences about Offer/Answer= ). >=A0 > I think it would be good to have a dedicated SDP Offer/Answer procedure s= ection, following the structure in RFC 3264. I've had to do that e.g. for B= UNDLE and SCTP-SDP. > > I had a look at=A0http://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle= -negotiation-13=A0as an example. I see how we could rename and reorganize t= he existing > content along these lines. I struggle with this a bit because I am comfor= table with the existing document structure and my familiarity with it make = it straightforward=20 > for me to understand. For a new reader, I think your suggested change wil= l help, so I'm in favor of it. I took the text from the SCTP-SDP draft (note that the text may still chang= e), and tried to convert it into BFCP. Some parts are probably still missin= g (for example, I realized that I forgot to add text regarding the SDP 'flo= orctrl' attribute) , and maybe the BFCP draft uses different terminology, b= ut feel free to use it as a base: -------- 9. SDP Offer/Answer Procedures 9.1. General This section defines the SDP Offer/Answer [RFC3264] procedures for negotiating and establishing an BFCP connection. =20 If the m- line proto value is ' TCP/TLS/BFCP ' or ' UDP/TLS/BFCP ', each endpoint MUST provide a certificate fingerprint, using the SDP 'fingerprint' attribute [RFC4145], if the endpoint supports, and is willing to use, a cipher suite with an associated certificate. The authentication certificates are interpreted and validated as defined in [RFC4572]. Self-signed certificates can be used securely, provided that the integrity of the SDP description is assured as defined in [RFC4572]. NOTE: The procedures apply to a specific m- line describing an BFCP connection. If an offer or answer contains multiple m- line describing BFCP connections, the procedures are applied separately to each m- line. 9.2. Generating the Initial SDP Offer When the offerer creates an initial offer, the offerer: o MUST, if the m- line proto value is 'TCP/BFCP', 'TCP/TLS/BFCP' or 'UDP/TLS/BFCP', associate an SDP setup attribute [Section X], with a= n 'actpass' value, with the m- line; o MUST, if the m- line proto value is 'TCP/BFCP' or 'TCP/TLS/BFCP', associate an SDP 'connection' attribute [Section 8.4], with a 'new' value, with the m- line; and In addition, if the offerer acts as the floor control server, the offere= r: o MUST associate an SDP 'confid' attribute [Section X], with the m- lin= e; o MUST associate an SDP 'userid' attribute [Section X], with the m- lin= e; o MUST associate an SDP 'floorid' attribute [Section X], with the m- li= ne; and o MUST associate an SDP 'label' attribute [Section X], with the m- line= . 9.3. Generating the SDP Answer When the answerer receives an offer, which contains an m- line describing a BFCP connection, if the answerer accepts the m- line it: o MUST insert a corresponding m- line in the answer, with an identical m- line proto value [RFC3264]; and o MUST, if the m- line proto value is 'TCP/BFCP', 'TCP/TLS/BFCP' or 'UDP/TLS/BFCP', associate an SDP setup attribute [Section X], with a= n 'active' or 'passive' value, with the m- line; In addition, if the answerer acts as the floor control server, the answe= rer: o MUST associate an SDP 'confid' attribute [Section X], with the m- lin= e; o MUST associate an SDP 'userid' attribute [Section X], with the m- lin= e; o MUST associate an SDP 'floorid' attribute [Section X], with the m- li= ne; and o MUST associate an SDP 'label' attribute [Section X], with the m- line= . Once the answerer has sent the answer, the answerer: o MUST, if the answerer is the 'active' endpoint, and if a TCP connecti= on associated with the m- line is to be established (or re-established)= ,=20 initiate the establishing of the TCP connection; and=20 o MUST, if the answerer is the 'active' endpoint, and if an TLS/DTLS connection associated with the m- line is to be established (or re-established), initiate the establishing of the TLS/DTLS connection (by sending a ClientHello message). If the answerer does not accept the m- line in the offer, it MUST assign a zero port value to the corresponding m- line in the answer. In addition, the answerer MUST NOT establish an SCTP association, or a DTLS connection, associated with the m- line. 9.4. Offerer Processing of the SDP Answer When the offerer receives an answer, which contains an m- line with a non-zero port value, describing a BFCP connection, the offerer: o MUST, if the offer is the 'active' endpoint, and if a TCP connection= =20 associated with the m- line is to be established (or re-established)= ,=20 initiate the establishing of the TCP connection; and o MUST, if the offerer is the 'active' endpoint, and if an TLS/DTLS connection associated with the m- line is to be established (or re-established), initiate the establishing of the TLS/DTLS connection (by sending a ClientHello message). If the m- line in the answer contains a zero port value, the offerer MUST NOT establish an TCP connection, or a TLS/DTLS connection, associated with the m- line. 9.5. Modifying the Session When an offerer sends an updated offer, in order to modify a previously established BFCP connection, it follows the procedures in Section 9.2, with the following exceptions: o If the BFCP connection is carried on top of TCP, and unless the=20 offerer wants to re-establish an existing TCP connection, the=20 offerer MUST associate an SDP connection attribute, with=20 an 'existing' value, with the m- line; and o If the offerer wants to disable a previously established BFCP connection, it MUST assign a zero port value to the m- line associated with the BFCP connection, following the procedures in [RFC3264]. =A0 --------------- Q3b: The following sentence in 4583bis is a little confusing: "If the 'floorctrl' attribute is not used in an offer/answer exchange, by default the offerer and the answerer will act as a floor control client and as a floor control server, respectively." Does this mean that the role may change every time an endpoint - for whatev= er reason - sends an updated offer? =A0 >> Q4: >>=A0 >> For DTLS and Offer/Answer, there are a few references to RFC 5763 here a= nd there. But, I think it would be good to have explicit text on the=20 >> Offer/Answer considerations regarding DTLS - especially since there have= been quite a bit of discussions about that lately. > > Are you suggesting a copy/paste of the relevant text from RFC 5763 in add= itional to a reference, or is there an calcification of what is provided in= RFC 5763 that you added for SCTP that would be helpful for this draft?=A0 In the SCTP-SDP draft I have the following text, which is aligned with RFC = 5763, but provides a little more details. You could probably use the text just by replacing the proto field values wi= th the ones used for BFCP. ------------- 8.3.3. TLS Role Determination If the m- line proto value is 'SCTP/DTLS' or 'DTLS/SCTP', the 'active/passive' status is used to determine the TLS roles. Following the procedures in [RFC4572], the 'active' endpoint will take the TLS client role. Once a DTLS connection has been established, if the 'active/passive' status of the endpoints change during a session, a new DTLS connection MUST be established. Therefore, endpoints SHOULD NOT change the 'active/passive' status in subsequent offers and answers, unless they want to establish a new DTLS connection. If the transport parameters or the key fingerprints change, the endpoints MUST establish a new DTLS connection. In such case the 'active/passive' status of the endpoints will again be determined following the procedures in [RFC4145], and the new status will be used to determine the TLS roles associated with the new DTLS connection. NOTE: The procedure above is identical to the one defined for SRTP- DTLS in [RFC5763]. NOTE: A new DTLS connection needs to be established if the transport parameters or the key fingerprints change. ------------ =A0 > Q5: >=A0 > The draft does not define how to use BFCP within a BUNDLE group. That is = fine, but I think it would be good to explicitly indicate that. > > Yes. I'm thinking we need to point to https://tools.ietf.org/html/draft-i= etf-mmusic-sdp-mux-attributes-05#page-28=A0for attributes defined in RFC 45= 83, and =A0define =A0the mux category for new attributes defined within thi= s draft. Defining the mux category is one thing. But, if you want to define usage of BFCP within a BUNDLE group, you also ne= ed to describe how BFCP is identified when bundled with other protocols (RT= P etc). Regards, Christer From nobody Tue Dec 9 15:53:56 2014 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA0021A1B06 for ; Tue, 9 Dec 2014 15:53:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z98OhZa6NYzy for ; Tue, 9 Dec 2014 15:53:50 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3A511A01C6 for ; Tue, 9 Dec 2014 15:53:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12461; q=dns/txt; s=iport; t=1418169230; x=1419378830; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=DKtVjIIw2Mr1neLjHfZf4WuLJQST2JSGJHUsrdyaTVg=; b=WntdJqPTi2psg3bbqIbx+0JuaVRNEpkxaQrbtDqyLxLNKeGHXg2jx90f oPxHtVCWbNkhDy45PExITy58YTLKElp8p160CuONJinGoZy2TFsJ/T4ef sQKVDonoFxyDC+bDrQxRVPSG92kITD8XeacmxQov5hZHqEPZDLlYlFsAz 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhcFAO2Kh1StJA2N/2dsb2JhbABXAoMGUlgExhCGBwKBKBYBAQEBAX2EAwEBAwFnEhACAQguGDIlAQEEAQ0FiDAIDddTAQEBAQEBAQEBAQEBAQEBAQEBAQEBF49QMwcSC4QZBYUiiGaDVoF9gzuBDTCCLYoWg16Dbm8BgQQHFwYcfgEBAQ X-IronPort-AV: E=Sophos;i="5.07,548,1413244800"; d="scan'208";a="104210664" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-6.cisco.com with ESMTP; 09 Dec 2014 23:53:49 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id sB9Nrnuo003384 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 9 Dec 2014 23:53:49 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.252]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0195.001; Tue, 9 Dec 2014 17:53:49 -0600 From: "Charles Eckel (eckelcu)" To: Christer Holmberg , "bfcpbis@ietf.org" Thread-Topic: Comments on draft-ietf-bfcpbis-rfc4583bis-10 Thread-Index: AdARgmEI5ESuyJkDTsuliRtAbu7OYQBjlDwAABy8dMAAHb3ZAA== Date: Tue, 9 Dec 2014 23:53:49 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D582373@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D588C28@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D588C28@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.154.176.40] Content-Type: text/plain; charset="Windows-1252" Content-ID: <077DB5B77BB47F49AC5FA6417E8D7BEA@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/bfcpbis/9o9zCHfqTaksev5BQ9Lz5wCfp1Q Cc: "Tom Kristensen \(tomkrist\)" Subject: Re: [bfcpbis] Comments on draft-ietf-bfcpbis-rfc4583bis-10 X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2014 23:53:53 -0000 On 12/9/14, 12:17 AM, "Christer Holmberg" wrote: >Hi, >=20 >>> Q1: >>>=20 >>> There is a new "template" for defining SDP attributes. It has been >>>discussed on the MMUSIC list, and Paul K can give more information if >>>needed. >> >> A ptr to that would be helpful. I scanned the MMUSIC list quickly but >>must have missed it. > >Please look at section 6 in >https://tools.ietf.org/id/draft-ietf-mmusic-rfc4566bis-12.txt This section makes consistent use of the following template (using =B3cat= =B2 as an example): --- Name: cat Value: cat-value Usage Level: session Charset Dependent: no Syntax: cat-value =3D category category =3D byte-string ; Note: syntax is vague because usage is not understood Example: a=3Dcat:foo.bar This attribute gives the dot-separated hierarchical category of the session. This is to enable a receiver to filter unwanted sessions by category. There is no central registry of categories. =8B I don=B9t believe draft-ietf-bfcpbis-rfc4583bis-10 should include such info for each attribute because similar information is already captured in the IANA considerations sections in for the format appropriate for IANA considerations. > >=20 >=20 >>> Q2: >>> >>> Most SDP attributes are defined in their own sections - which is good. >>>But, sometimes the section name contains the name of the attribute, and >>>sometimes not. I think it would be good to be consistent, and always >>>call the section "SDP xxx attribute". The IANA considerations section does this (i.e. SDP attribute name in section title). Sections 4-7 are organized by functionality rather than by SDP attribute. As such, I think the existing names are appropriate. We could add subsections for each attribute within these sections that are named according to the name of the corresponding SDP attribute. That said, I do think such additions would be all that useful. >>>=20 >>> Q3: > > >> There is no dedicated SDP Offer/Answer procedure section (instead, each >>section defining an SDP attribute include a few sentences about >>Offer/Answer). >>=20 >> I think it would be good to have a dedicated SDP Offer/Answer procedure >>section, following the structure in RFC 3264. I've had to do that e.g. >>for BUNDLE and SCTP-SDP. >> >> I had a look at=20 >>http://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-negotiation-13 >>as an example. I see how we could rename and reorganize the existing >> content along these lines. I struggle with this a bit because I am >>comfortable with the existing document structure and my familiarity with >>it make it straightforward >> for me to understand. For a new reader, I think your suggested change >>will help, so I'm in favor of it. > >I took the text from the SCTP-SDP draft (note that the text may still >change), and tried to convert it into BFCP. Some parts are probably still >missing (for example, I realized that I forgot to add text regarding the >SDP 'floorctrl' attribute) , and maybe the BFCP draft uses different >terminology, but feel free to use it as a base: > >-------- > >9. SDP Offer/Answer Procedures > >9.1. General > > This section defines the SDP Offer/Answer [RFC3264] procedures for > negotiating and establishing an BFCP connection. > > If the m- line proto value is ' TCP/TLS/BFCP ' or ' UDP/TLS/BFCP ', >each > endpoint MUST provide a certificate fingerprint, using the SDP > 'fingerprint' attribute [RFC4145], if the endpoint supports, and is > willing to use, a cipher suite with an associated certificate. > > The authentication certificates are interpreted and validated as > defined in [RFC4572]. Self-signed certificates can be used securely, > provided that the integrity of the SDP description is assured as > defined in [RFC4572]. > > NOTE: The procedures apply to a specific m- line describing an BFCP > connection. If an offer or answer contains multiple m- line > describing BFCP connections, the procedures are applied separately > to each m- line. > >9.2. Generating the Initial SDP Offer > > When the offerer creates an initial offer, the offerer: > > o MUST, if the m- line proto value is 'TCP/BFCP', 'TCP/TLS/BFCP' or > 'UDP/TLS/BFCP', associate an SDP setup attribute [Section X], with >an > 'actpass' value, with the m- line; > > o MUST, if the m- line proto value is 'TCP/BFCP' or 'TCP/TLS/BFCP', > associate an SDP 'connection' attribute [Section 8.4], with a > 'new' value, with the m- line; and > > In addition, if the offerer acts as the floor control server, the >offerer: > > o MUST associate an SDP 'confid' attribute [Section X], with the m- >line; > > o MUST associate an SDP 'userid' attribute [Section X], with the m- >line; > > o MUST associate an SDP 'floorid' attribute [Section X], with the m- >line; and > > o MUST associate an SDP 'label' attribute [Section X], with the m- >line. > >9.3. Generating the SDP Answer > > When the answerer receives an offer, which contains an m- line > describing a BFCP connection, if the answerer accepts the m- line > it: > > o MUST insert a corresponding m- line in the answer, with an > identical m- line proto value [RFC3264]; and > > o MUST, if the m- line proto value is 'TCP/BFCP', 'TCP/TLS/BFCP' or > 'UDP/TLS/BFCP', associate an SDP setup attribute [Section X], with >an > 'active' or 'passive' value, with the m- line; > > In addition, if the answerer acts as the floor control server, the >answerer: > > o MUST associate an SDP 'confid' attribute [Section X], with the m- >line; > > o MUST associate an SDP 'userid' attribute [Section X], with the m- >line; > > o MUST associate an SDP 'floorid' attribute [Section X], with the m- >line; and > > o MUST associate an SDP 'label' attribute [Section X], with the m- >line. > > Once the answerer has sent the answer, the answerer: > > o MUST, if the answerer is the 'active' endpoint, and if a TCP >connection > associated with the m- line is to be established (or >re-established),=20 > initiate the establishing of the TCP connection; and > > o MUST, if the answerer is the 'active' endpoint, and if an TLS/DTLS > connection associated with the m- line is to be established (or > re-established), initiate the establishing of the TLS/DTLS >connection > (by sending a ClientHello message). > > If the answerer does not accept the m- line in the offer, it MUST > assign a zero port value to the corresponding m- line in the answer. > In addition, the answerer MUST NOT establish an SCTP association, or > a DTLS connection, associated with the m- line. > >9.4. Offerer Processing of the SDP Answer > > When the offerer receives an answer, which contains an m- line with a > non-zero port value, describing a BFCP connection, the offerer: > > o MUST, if the offer is the 'active' endpoint, and if a TCP >connection=20 > associated with the m- line is to be established (or >re-established),=20 > initiate the establishing of the TCP connection; and > > o MUST, if the offerer is the 'active' endpoint, and if an TLS/DTLS > connection associated with the m- line is to be established (or > re-established), initiate the establishing of the TLS/DTLS >connection > (by sending a ClientHello message). > > If the m- line in the answer contains a zero port value, the offerer > MUST NOT establish an TCP connection, or a TLS/DTLS connection, > associated with the m- line. > >9.5. Modifying the Session > > When an offerer sends an updated offer, in order to modify a > previously established BFCP connection, it follows the procedures in > Section 9.2, with the following exceptions: > > o If the BFCP connection is carried on top of TCP, and unless the > offerer wants to re-establish an existing TCP connection, the > offerer MUST associate an SDP connection attribute, with > an 'existing' value, with the m- line; and > > o If the offerer wants to disable a previously established BFCP > connection, it MUST assign a zero port value to the m- line > associated with the BFCP connection, following the procedures in > [RFC3264]. > >=20 >--------------- That looks pretty straightforward and clear to me. Adding the floorctrl attribute will complicate it some, but I think its still manageable. > >Q3b: > >The following sentence in 4583bis is a little confusing: > > "If the 'floorctrl' attribute is not used in an offer/answer exchange, > by default the offerer and the answerer will act as a floor control > client and as a floor control server, respectively." > >Does this mean that the role may change every time an endpoint - for >whatever reason - sends an updated offer? Yes. This was inherited from RFC 4583, and it is the consequence of the lenient normative language immediately before it. "Endpoints that use the offer/answer model to establish BFCP connections MUST support the 'floorctrl' attribute. A floor control server acting as an offerer or as an answerer SHOULD include this attribute in its session descriptions.=B2 > > > >=20 >>> Q4: >>>=20 >>> For DTLS and Offer/Answer, there are a few references to RFC 5763 here >>>and there. But, I think it would be good to have explicit text on the >>> Offer/Answer considerations regarding DTLS - especially since there >>>have been quite a bit of discussions about that lately. >> >> Are you suggesting a copy/paste of the relevant text from RFC 5763 in >>additional to a reference, or is there an calcification of what is >>provided in RFC 5763 that you added for SCTP that would be helpful for >>this draft?=20 > >In the SCTP-SDP draft I have the following text, which is aligned with >RFC 5763, but provides a little more details. > >You could probably use the text just by replacing the proto field values >with the ones used for BFCP. > >------------- > >8.3.3. TLS Role Determination > > If the m- line proto value is 'SCTP/DTLS' or 'DTLS/SCTP', the > 'active/passive' status is used to determine the TLS roles. > Following the procedures in [RFC4572], the 'active' endpoint will > take the TLS client role. > > Once a DTLS connection has been established, if the 'active/passive' > status of the endpoints change during a session, a new DTLS > connection MUST be established. Therefore, endpoints SHOULD NOT > change the 'active/passive' status in subsequent offers and answers, > unless they want to establish a new DTLS connection. > > If the transport parameters or the key fingerprints change, the > endpoints MUST establish a new DTLS connection. In such case the > 'active/passive' status of the endpoints will again be determined > following the procedures in [RFC4145], and the new status will be > used to determine the TLS roles associated with the new DTLS > connection. > > NOTE: The procedure above is identical to the one defined for SRTP- > DTLS in [RFC5763]. > > NOTE: A new DTLS connection needs to be established if the transport > parameters or the key fingerprints change. > >------------ I am okay with this. Its a nice summary. Our previous reference to RFC 5763, section 5, did not address session modification. This fixes that. >=20 >> Q5: >>=20 >> The draft does not define how to use BFCP within a BUNDLE group. That >>is fine, but I think it would be good to explicitly indicate that. >> >> Yes. I'm thinking we need to point to >>https://tools.ietf.org/html/draft-ietf-mmusic-sdp-mux-attributes-05#page- >>28 for attributes defined in RFC 4583, and define the mux category for >>new attributes defined within this draft. > >Defining the mux category is one thing. > >But, if you want to define usage of BFCP within a BUNDLE group, you also >need to describe how BFCP is identified when bundled with other protocols >(RTP etc). I think this goes beyond what is needed for this draft. If someone wants to use BFCP with BUNDLE, they can define that usage. Sounds reasonable? Cheers, Charles > >Regards, > >Christer > From nobody Wed Dec 10 03:03:42 2014 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A20651A6F8D for ; Wed, 10 Dec 2014 03:03:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fbc9VPBJJf6n for ; Wed, 10 Dec 2014 03:03:39 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEA821A6F91 for ; Wed, 10 Dec 2014 03:03:38 -0800 (PST) X-AuditID: c1b4fb2d-f79fc6d000001087-10-548828880a51 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 3F.60.04231.88828845; Wed, 10 Dec 2014 12:03:36 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.189]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0195.001; Wed, 10 Dec 2014 12:03:36 +0100 From: Christer Holmberg To: "Charles Eckel (eckelcu)" , "bfcpbis@ietf.org" Thread-Topic: Comments on draft-ietf-bfcpbis-rfc4583bis-10 Thread-Index: AdARgmEI5ESuyJkDTsuliRtAbu7OYQBjlDwAABy8dMAAHb3ZAAAawZEg Date: Wed, 10 Dec 2014 11:03:35 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D58BE5C@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D582373@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D588C28@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrELMWRmVeSWpSXmKPExsUyM+JvjW6HRkeIwcP31hb/1h1lstg06wub xZUjv9gcmD2m/N7I6rFkyU+mAKYoLpuU1JzMstQifbsEroxHjTPYChaYVUy+1czUwLhCu4uR k0NCwETi3oylTBC2mMSFe+vZuhi5OIQEjjBKrPrfwwjhLGGUODHxA2sXIwcHm4CFRPc/bRBT RCBKYuM2IZBeZqA5++7+B5sjLGApMXnzWzBbRMBKYt3xz1C2m8S6U1/YQGwWAVWJL0+mMIPY vAK+Et8vTILae5tRYufeJSwgCU4BfYnjU5rAmhmBjvt+ag0TxDJxiVtP5kMdLSCxZM95Zghb VOLl43+sELaixNXpy6Hq9SRuTJ3CBmFrSyxb+BpqsaDEyZlPWCYwis1CMnYWkpZZSFpmIWlZ wMiyilG0OLW4ODfdyFgvtSgzubg4P08vL7VkEyMwkg5u+a27g3H1a8dDjAIcjEo8vAXv20OE WBPLiitzDzFKc7AoifMuOjcvWEggPbEkNTs1tSC1KL6oNCe1+BAjEwenVANjt/G8OXk7z64P nt32R+dMW5/sG9cbqdNOvtAVv8yWeettcekzdofuk5qR9/t7Z7258NrZ+wArp9hcre558l6c P/58iNz8+Yazsce2JyU2M6SKmG8t3HTWbppF4Nw9J9+IbGYq3fj84MW/GtU9npOrwhZk9U+Z 5hgRaL79asxvN4abEcycrRwPlViKMxINtZiLihMB3ZPuCYUCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/bfcpbis/OjLI8ewU-BDQh8riBXuPxEiqsaQ Cc: "Tom Kristensen \(tomkrist\)" Subject: Re: [bfcpbis] Comments on draft-ietf-bfcpbis-rfc4583bis-10 X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2014 11:03:41 -0000 Hi, >>>> Q1: >>>>=20 >>>> There is a new "template" for defining SDP attributes. It has been=20 >>>>discussed on the MMUSIC list, and Paul K can give more information if=20 >>>>needed. >>> >>> A ptr to that would be helpful. I scanned the MMUSIC list quickly but=20 >>>must have missed it. >> >>Please look at section 6 in >>https://tools.ietf.org/id/draft-ietf-mmusic-rfc4566bis-12.txt > > This section makes consistent use of the following template (using =B3cat= =B2 as an example): > > --- > Name: cat > > Value: cat-value > > Usage Level: session > > Charset Dependent: no > > Syntax: > > cat-value =3D category > category =3D byte-string > ; Note: syntax is vague because usage is not understood > > Example: > > a=3Dcat:foo.bar > > This attribute gives the dot-separated hierarchical category of the > session. This is to enable a receiver to filter unwanted sessions by > category. There is no central registry of categories. > > > I don=B9t believe draft-ietf-bfcpbis-rfc4583bis-10 should include such in= fo for each attribute because similar information is already captured in th= e IANA considerations sections in for the format appropriate for IANA consi= derations. That is how SDP attributes currently are supposed to be defined and registe= red, and I think everyone defining/registering attributes should be aligned= .=20 If someone has issues with the current proposal, I think it should be raise= d on the MMUSIC list. -------------- >>> Q2: >>> >>> Most SDP attributes are defined in their own sections - which is good. >>>But, sometimes the section name contains the name of the attribute,=20 >>>and sometimes not. I think it would be good to be consistent, and=20 >>>always call the section "SDP xxx attribute". > > The IANA considerations section does this (i.e. SDP attribute name in sec= tion title). Sections 4-7 are organized by functionality rather than by SDP= attribute.=20 > As such, I think the existing names are appropriate. We could add subsect= ions for each attribute within these sections that are named according to t= he name=20 > of the corresponding SDP attribute. That said, I do think such additions = would be all that useful. I would be ok with subsections. -------------- >>> Q3: > > >> There is no dedicated SDP Offer/Answer procedure section (instead,=20 >>each section defining an SDP attribute include a few sentences about=20 >>Offer/Answer). >>=20 >> I think it would be good to have a dedicated SDP Offer/Answer=20 >>procedure section, following the structure in RFC 3264. I've had to do th= at e.g. >>for BUNDLE and SCTP-SDP. >> >> I had a look at >>http://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-negotiation-13 >>as an example. I see how we could rename and reorganize the existing =20 >>content along these lines. I struggle with this a bit because I am=20 >>comfortable with the existing document structure and my familiarity=20 >>with it make it straightforward for me to understand. For a new=20 >>reader, I think your suggested change will help, so I'm in favor of=20 >>it. > >I took the text from the SCTP-SDP draft (note that the text may still=20 >change), and tried to convert it into BFCP. Some parts are probably=20 >still missing (for example, I realized that I forgot to add text=20 >regarding the SDP 'floorctrl' attribute) , and maybe the BFCP draft=20 >uses different terminology, but feel free to use it as a base: ... > That looks pretty straightforward and clear to me. Adding the floorctrl a= ttribute will complicate it some, but I think its still manageable. Good. -------------- >>Q3b: >> >>The following sentence in 4583bis is a little confusing: >> >> "If the 'floorctrl' attribute is not used in an offer/answer exchange, >> by default the offerer and the answerer will act as a floor control >> client and as a floor control server, respectively." >> >>Does this mean that the role may change every time an endpoint - for=20 >>whatever reason - sends an updated offer? > > Yes. This was inherited from RFC 4583, and it is the consequence of the l= enient normative language immediately before it. > > "Endpoints that use the offer/answer model to establish BFCP > connections MUST support the 'floorctrl' attribute. A floor control > server acting as an offerer or as an answerer SHOULD include this > attribute in its session descriptions.=B2 If the role will change whenever the other peer is sending an offer, I thin= k you should add some text to make that clear. But, is that really what you want? Another option would be to say that the roles are determined only when the = BFCP connection is established/re-established. But, I'll let it up to you to decide what you want :) -------------- >>>> Q4: >>>>=20 >>>> For DTLS and Offer/Answer, there are a few references to RFC 5763=20 >>>>here and there. But, I think it would be good to have explicit text=20 >>>>on the Offer/Answer considerations regarding DTLS - especially since=20 >>>>there have been quite a bit of discussions about that lately. >>> >>> Are you suggesting a copy/paste of the relevant text from RFC 5763 in=20 >>>additional to a reference, or is there an calcification of what is=20 >>>provided in RFC 5763 that you added for SCTP that would be helpful for=20 >>>this draft? >> >>In the SCTP-SDP draft I have the following text, which is aligned with=20 >>RFC 5763, but provides a little more details. >> >>You could probably use the text just by replacing the proto field=20 >>values with the ones used for BFCP. ... > I am okay with this. Its a nice summary. Our previous reference to RFC 57= 63, section 5, did not address session modification. This fixes that. Good. -------------- >>> Q5: >>>=20 >>> The draft does not define how to use BFCP within a BUNDLE group. That=20 >>>is fine, but I think it would be good to explicitly indicate that. >>> >>> Yes. I'm thinking we need to point to >>>https://tools.ietf.org/html/draft-ietf-mmusic-sdp-mux-attributes-05#pa >>>ge- >>>28 for attributes defined in RFC 4583, and define the mux category=20 >>>for new attributes defined within this draft. >> >>Defining the mux category is one thing. >> >>But, if you want to define usage of BFCP within a BUNDLE group, you=20 >>also need to describe how BFCP is identified when bundled with other=20 >>protocols (RTP etc). > > I think this goes beyond what is needed for this draft. If someone wants = to use BFCP with BUNDLE, they can define that usage. Sounds reasonable? That is fine. But, if it goes beyond the scope of the draft, I think it wou= ld be good to explicitly indicate it, so that anyone who might want to use = BFCP with BUNDLE knows that a separate definition is needed. Regards, Christer From nobody Wed Dec 10 06:56:32 2014 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58E931A6F99 for ; Wed, 10 Dec 2014 06:56:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NSVweq5Q_rwH for ; Wed, 10 Dec 2014 06:56:11 -0800 (PST) Received: from resqmta-ch2-03v.sys.comcast.net (resqmta-ch2-03v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:35]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 085DC1A6F93 for ; Wed, 10 Dec 2014 06:56:10 -0800 (PST) Received: from resomta-ch2-13v.sys.comcast.net ([69.252.207.109]) by resqmta-ch2-03v.sys.comcast.net with comcast id RqvX1p0062N9P4d01qwABG; Wed, 10 Dec 2014 14:56:10 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-13v.sys.comcast.net with comcast id Rqw91p00L3Ge9ey01qw9zD; Wed, 10 Dec 2014 14:56:10 +0000 Message-ID: <54885F09.6010706@alum.mit.edu> Date: Wed, 10 Dec 2014 09:56:09 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: bfcpbis@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D582373@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D588C28@ESESSMB209.ericsson.se> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1418223370; bh=kdUwrFvUf7LX7aZLhCZd0CEqDDnzy/QiamkY5hUsdx8=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=PZiKTctOG5UW2rSvsFqAkiBOvP9HqjB8bBGWZOhfzXwZY6WZRFK0TD+xXPCNdP3cQ NS3VC/phf9inZlWWzeOSuyxc18FendyzuqzKAaa7q8zj6KMP8+RsrA0zedWBnco0PR bQ0gCUB2ak7UKUwYtajgKcttXCinX4N2fuVYlPfTGE19i+DH0YAx5CHFcJ4x+zDY6O MEZgASRuhThCsp+RNuBMRDrWpjI0ZXU4rxOfk34ShEtbnmf935+tWyhWHhIN8Cn8kB H+C660Lnu0MADkwAIQocLPHQcMDXSeCsLOKY6rSm+trsrK+JXqZriRwzSXr80fzKed Df5MY4k59vLCQ== Archived-At: http://mailarchive.ietf.org/arch/msg/bfcpbis/3Kipl8KxSWkFdv7Gg3JglFx5C3c Subject: Re: [bfcpbis] Comments on draft-ietf-bfcpbis-rfc4583bis-10 X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2014 14:56:17 -0000 I'm here to discuss how I think the attribute declaration updates to 4566bis should apply here. (Note that I haven't been closely following this draft. I noted Christer's comments, and then scanned the draft to find relevant sections.) First, the template I have introduced in 4566bis is new, and hasn't been thoroughly reviewed. It is good to "debug" it and fine tune it. Second, I have *some* sympathy for bis drafts in general. It is hard to decide how much to change, and what to leave alone. OTOH, I set out specifically to improve the mechanism for definition of attributes, and did update all the definitions in 4566bis. My goal is to ensure that there is clarity in the syntax of attributes, and that developers reading those will know what they are expected to do to parse them. I find that what is in this document now does at least define the syntax unambiguously. OTOH, it does imply that the attribute names it defines should be matched in a case-insensitive way, which is contrary to what 4566 says. I think it would be "nice" if the attribute declarations here were updated to the new format - a help in getting on the new path. My inclination would be to convert to the new format, inline in the sections where the attribute syntax is currently defined, and then simply cross reference those definitions from the IANA Considerations section. Thanks, Paul On 12/9/14 6:53 PM, Charles Eckel (eckelcu) wrote: > On 12/9/14, 12:17 AM, "Christer Holmberg" > wrote: > >> Hi, >> >>>> Q1: >>>> >>>> There is a new "template" for defining SDP attributes. It has been >>>> discussed on the MMUSIC list, and Paul K can give more information if >>>> needed. >>> >>> A ptr to that would be helpful. I scanned the MMUSIC list quickly but >>> must have missed it. >> >> Please look at section 6 in >> https://tools.ietf.org/id/draft-ietf-mmusic-rfc4566bis-12.txt > > This section makes consistent use of the following template (using ³cat² > as an example): > > --- > Name: cat > > Value: cat-value > > Usage Level: session > > Charset Dependent: no > > Syntax: > > cat-value = category > category = byte-string > ; Note: syntax is vague because usage is not understood > > Example: > > a=cat:foo.bar > > This attribute gives the dot-separated hierarchical category of the > session. This is to enable a receiver to filter unwanted sessions by > category. There is no central registry of categories. > > ‹ > > I don¹t believe draft-ietf-bfcpbis-rfc4583bis-10 should include such info > for each attribute because similar information is already captured in the > IANA considerations sections in for the format appropriate for IANA > considerations. > >> >> >> >>>> Q2: >>>> >>>> Most SDP attributes are defined in their own sections - which is good. >>>> But, sometimes the section name contains the name of the attribute, and >>>> sometimes not. I think it would be good to be consistent, and always >>>> call the section "SDP xxx attribute". > > The IANA considerations section does this (i.e. SDP attribute name in > section title). Sections 4-7 are organized by functionality rather than by > SDP attribute. As such, I think the existing names are appropriate. We > could add subsections for each attribute within these sections that are > named according to the name of the corresponding SDP attribute. That said, > I do think such additions would be all that useful. > >>>> >>>> Q3: >>> >>> There is no dedicated SDP Offer/Answer procedure section (instead, each >>> section defining an SDP attribute include a few sentences about >>> Offer/Answer). >>> >>> I think it would be good to have a dedicated SDP Offer/Answer procedure >>> section, following the structure in RFC 3264. I've had to do that e.g. >>> for BUNDLE and SCTP-SDP. >>> >>> I had a look at >>> http://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-negotiation-13 >>> as an example. I see how we could rename and reorganize the existing >>> content along these lines. I struggle with this a bit because I am >>> comfortable with the existing document structure and my familiarity with >>> it make it straightforward >>> for me to understand. For a new reader, I think your suggested change >>> will help, so I'm in favor of it. >> >> I took the text from the SCTP-SDP draft (note that the text may still >> change), and tried to convert it into BFCP. Some parts are probably still >> missing (for example, I realized that I forgot to add text regarding the >> SDP 'floorctrl' attribute) , and maybe the BFCP draft uses different >> terminology, but feel free to use it as a base: >> >> -------- >> >> 9. SDP Offer/Answer Procedures >> >> 9.1. General >> >> This section defines the SDP Offer/Answer [RFC3264] procedures for >> negotiating and establishing an BFCP connection. >> >> If the m- line proto value is ' TCP/TLS/BFCP ' or ' UDP/TLS/BFCP ', >> each >> endpoint MUST provide a certificate fingerprint, using the SDP >> 'fingerprint' attribute [RFC4145], if the endpoint supports, and is >> willing to use, a cipher suite with an associated certificate. >> >> The authentication certificates are interpreted and validated as >> defined in [RFC4572]. Self-signed certificates can be used securely, >> provided that the integrity of the SDP description is assured as >> defined in [RFC4572]. >> >> NOTE: The procedures apply to a specific m- line describing an BFCP >> connection. If an offer or answer contains multiple m- line >> describing BFCP connections, the procedures are applied separately >> to each m- line. >> >> 9.2. Generating the Initial SDP Offer >> >> When the offerer creates an initial offer, the offerer: >> >> o MUST, if the m- line proto value is 'TCP/BFCP', 'TCP/TLS/BFCP' or >> 'UDP/TLS/BFCP', associate an SDP setup attribute [Section X], with >> an >> 'actpass' value, with the m- line; >> >> o MUST, if the m- line proto value is 'TCP/BFCP' or 'TCP/TLS/BFCP', >> associate an SDP 'connection' attribute [Section 8.4], with a >> 'new' value, with the m- line; and >> >> In addition, if the offerer acts as the floor control server, the >> offerer: >> >> o MUST associate an SDP 'confid' attribute [Section X], with the m- >> line; >> >> o MUST associate an SDP 'userid' attribute [Section X], with the m- >> line; >> >> o MUST associate an SDP 'floorid' attribute [Section X], with the m- >> line; and >> >> o MUST associate an SDP 'label' attribute [Section X], with the m- >> line. >> >> 9.3. Generating the SDP Answer >> >> When the answerer receives an offer, which contains an m- line >> describing a BFCP connection, if the answerer accepts the m- line >> it: >> >> o MUST insert a corresponding m- line in the answer, with an >> identical m- line proto value [RFC3264]; and >> >> o MUST, if the m- line proto value is 'TCP/BFCP', 'TCP/TLS/BFCP' or >> 'UDP/TLS/BFCP', associate an SDP setup attribute [Section X], with >> an >> 'active' or 'passive' value, with the m- line; >> >> In addition, if the answerer acts as the floor control server, the >> answerer: >> >> o MUST associate an SDP 'confid' attribute [Section X], with the m- >> line; >> >> o MUST associate an SDP 'userid' attribute [Section X], with the m- >> line; >> >> o MUST associate an SDP 'floorid' attribute [Section X], with the m- >> line; and >> >> o MUST associate an SDP 'label' attribute [Section X], with the m- >> line. >> >> Once the answerer has sent the answer, the answerer: >> >> o MUST, if the answerer is the 'active' endpoint, and if a TCP >> connection >> associated with the m- line is to be established (or >> re-established), >> initiate the establishing of the TCP connection; and >> >> o MUST, if the answerer is the 'active' endpoint, and if an TLS/DTLS >> connection associated with the m- line is to be established (or >> re-established), initiate the establishing of the TLS/DTLS >> connection >> (by sending a ClientHello message). >> >> If the answerer does not accept the m- line in the offer, it MUST >> assign a zero port value to the corresponding m- line in the answer. >> In addition, the answerer MUST NOT establish an SCTP association, or >> a DTLS connection, associated with the m- line. >> >> 9.4. Offerer Processing of the SDP Answer >> >> When the offerer receives an answer, which contains an m- line with a >> non-zero port value, describing a BFCP connection, the offerer: >> >> o MUST, if the offer is the 'active' endpoint, and if a TCP >> connection >> associated with the m- line is to be established (or >> re-established), >> initiate the establishing of the TCP connection; and >> >> o MUST, if the offerer is the 'active' endpoint, and if an TLS/DTLS >> connection associated with the m- line is to be established (or >> re-established), initiate the establishing of the TLS/DTLS >> connection >> (by sending a ClientHello message). >> >> If the m- line in the answer contains a zero port value, the offerer >> MUST NOT establish an TCP connection, or a TLS/DTLS connection, >> associated with the m- line. >> >> 9.5. Modifying the Session >> >> When an offerer sends an updated offer, in order to modify a >> previously established BFCP connection, it follows the procedures in >> Section 9.2, with the following exceptions: >> >> o If the BFCP connection is carried on top of TCP, and unless the >> offerer wants to re-establish an existing TCP connection, the >> offerer MUST associate an SDP connection attribute, with >> an 'existing' value, with the m- line; and >> >> o If the offerer wants to disable a previously established BFCP >> connection, it MUST assign a zero port value to the m- line >> associated with the BFCP connection, following the procedures in >> [RFC3264]. >> >> >> --------------- > > That looks pretty straightforward and clear to me. Adding the floorctrl > attribute will complicate it some, but I think its still manageable. > >> >> Q3b: >> >> The following sentence in 4583bis is a little confusing: >> >> "If the 'floorctrl' attribute is not used in an offer/answer exchange, >> by default the offerer and the answerer will act as a floor control >> client and as a floor control server, respectively." >> >> Does this mean that the role may change every time an endpoint - for >> whatever reason - sends an updated offer? > > Yes. This was inherited from RFC 4583, and it is the consequence of the > lenient normative language immediately before it. > > "Endpoints that use the offer/answer model to establish BFCP > connections MUST support the 'floorctrl' attribute. A floor control > server acting as an offerer or as an answerer SHOULD include this > attribute in its session descriptions.² > >> >> >> >> >>>> Q4: >>>> >>>> For DTLS and Offer/Answer, there are a few references to RFC 5763 here >>>> and there. But, I think it would be good to have explicit text on the >>>> Offer/Answer considerations regarding DTLS - especially since there >>>> have been quite a bit of discussions about that lately. >>> >>> Are you suggesting a copy/paste of the relevant text from RFC 5763 in >>> additional to a reference, or is there an calcification of what is >>> provided in RFC 5763 that you added for SCTP that would be helpful for >>> this draft? >> >> In the SCTP-SDP draft I have the following text, which is aligned with >> RFC 5763, but provides a little more details. >> >> You could probably use the text just by replacing the proto field values >> with the ones used for BFCP. >> >> ------------- >> >> 8.3.3. TLS Role Determination >> >> If the m- line proto value is 'SCTP/DTLS' or 'DTLS/SCTP', the >> 'active/passive' status is used to determine the TLS roles. >> Following the procedures in [RFC4572], the 'active' endpoint will >> take the TLS client role. >> >> Once a DTLS connection has been established, if the 'active/passive' >> status of the endpoints change during a session, a new DTLS >> connection MUST be established. Therefore, endpoints SHOULD NOT >> change the 'active/passive' status in subsequent offers and answers, >> unless they want to establish a new DTLS connection. >> >> If the transport parameters or the key fingerprints change, the >> endpoints MUST establish a new DTLS connection. In such case the >> 'active/passive' status of the endpoints will again be determined >> following the procedures in [RFC4145], and the new status will be >> used to determine the TLS roles associated with the new DTLS >> connection. >> >> NOTE: The procedure above is identical to the one defined for SRTP- >> DTLS in [RFC5763]. >> >> NOTE: A new DTLS connection needs to be established if the transport >> parameters or the key fingerprints change. >> >> ------------ > > I am okay with this. Its a nice summary. Our previous reference to RFC > 5763, section 5, did not address session modification. This fixes that. > >> >>> Q5: >>> >>> The draft does not define how to use BFCP within a BUNDLE group. That >>> is fine, but I think it would be good to explicitly indicate that. >>> >>> Yes. I'm thinking we need to point to >>> https://tools.ietf.org/html/draft-ietf-mmusic-sdp-mux-attributes-05#page- >>> 28 for attributes defined in RFC 4583, and define the mux category for >>> new attributes defined within this draft. >> >> Defining the mux category is one thing. >> >> But, if you want to define usage of BFCP within a BUNDLE group, you also >> need to describe how BFCP is identified when bundled with other protocols >> (RTP etc). > > I think this goes beyond what is needed for this draft. If someone wants > to use BFCP with BUNDLE, they can define that usage. Sounds reasonable? > > Cheers, > Charles > >> >> Regards, >> >> Christer >> > > _______________________________________________ > bfcpbis mailing list > bfcpbis@ietf.org > https://www.ietf.org/mailman/listinfo/bfcpbis > From nobody Thu Dec 11 03:42:49 2014 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CA321ACE18 for ; Thu, 11 Dec 2014 03:42:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.501 X-Spam-Level: X-Spam-Status: No, score=-1.501 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DTdSwhKpAvTI for ; Thu, 11 Dec 2014 03:42:43 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 877501ACE0A for ; Thu, 11 Dec 2014 03:42:42 -0800 (PST) X-AuditID: c1b4fb25-f791c6d00000617b-2a-54898330d759 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 26.CE.24955.03389845; Thu, 11 Dec 2014 12:42:40 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.189]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.03.0195.001; Thu, 11 Dec 2014 12:42:39 +0100 From: Christer Holmberg To: Paul Kyzivat , "bfcpbis@ietf.org" Thread-Topic: [bfcpbis] Comments on draft-ietf-bfcpbis-rfc4583bis-10 Thread-Index: AdARgmEI5ESuyJkDTsuliRtAbu7OYQBjlDwAABy8dMAAHb3ZAAAhnGGAAC2RQ2A= Date: Thu, 11 Dec 2014 11:42:38 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D58E6C7@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D582373@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D588C28@ESESSMB209.ericsson.se> <54885F09.6010706@alum.mit.edu> In-Reply-To: <54885F09.6010706@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrILMWRmVeSWpSXmKPExsUyM+Jvja5Bc2eIwbpj0hb/1h1lslix4QCr A5PH3/cfmDyWLPnJFMAUxWWTkpqTWZZapG+XwJUx88xe9oIvFRW/jlxma2BcFNfFyMkhIWAi cfraMyYIW0ziwr31bF2MXBxCAkcYJdY+WAjlLGGU6Fr3jrmLkYODTcBCovufNkiDiECgxKF9 08CahQWcJb5cf8UEEXeRePzpNzOE7Sex8eM6dhCbRUBV4sfaZkYQm1fAV6LjyjkmiPm/GSX2 /u1iA5nPKaAj8fBVFkgNI9BB30+tAZvJLCAucevJfKhDBSSW7DnPDGGLSrx8/I8VwlaU2Hm2 nRmiXk/ixtQpbBC2tsSyha+ZIfYKSpyc+YRlAqPoLCRjZyFpmYWkZRaSlgWMLKsYRYtTi5Ny 042M9VKLMpOLi/Pz9PJSSzYxAuPk4JbfqjsYL79xPMQowMGoxMNrUNkZIsSaWFZcmXuIUZqD RUmcd+G5ecFCAumJJanZqakFqUXxRaU5qcWHGJk4OKUaGFu4Wc7vdGtd9PiuYfjBiin3/A7x 2wtNVq7l6FEJnnvXbvHvLdo3lj5h0DZ2PnKV90u5QJ71Ute327nO2IQ+s/8mphv66tmtr6af agrX5O6Y/5klMuxXisW0OSINrFx5GQ9WXhQ0mxE/2XN79xsLvZQvOpx330s0rluqHj3fzeKi aHRBfv7LCUosxRmJhlrMRcWJAKYwvVJ0AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/bfcpbis/iqLMGpvuVr_tXyLReo_GDcqK6PU Subject: Re: [bfcpbis] Comments on draft-ietf-bfcpbis-rfc4583bis-10 X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2014 11:42:46 -0000 Hi, In order to figure out whether Paul's suggestion works, someone needs to us= e it - before the SDP-bis draft is published as RFC :) It's a very small task to change it. I could do it, but I'd like others to = also try it out, and provide feedback. Regards, Christer -----Original Message----- From: bfcpbis [mailto:bfcpbis-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: 10. joulukuuta 2014 16:56 To: bfcpbis@ietf.org Subject: Re: [bfcpbis] Comments on draft-ietf-bfcpbis-rfc4583bis-10 I'm here to discuss how I think the attribute declaration updates to 4566bi= s should apply here. (Note that I haven't been closely following this draft. I noted Christer's = comments, and then scanned the draft to find relevant sections.) First, the template I have introduced in 4566bis is new, and hasn't been th= oroughly reviewed. It is good to "debug" it and fine tune it. Second, I have *some* sympathy for bis drafts in general. It is hard to dec= ide how much to change, and what to leave alone. OTOH, I set out specifical= ly to improve the mechanism for definition of attributes, and did update al= l the definitions in 4566bis. My goal is to ensure that there is clarity in= the syntax of attributes, and that developers reading those will know what= they are expected to do to parse them. I find that what is in this document now does at least define the syntax un= ambiguously. OTOH, it does imply that the attribute names it defines should be matched i= n a case-insensitive way, which is contrary to what 4566 says. I think it would be "nice" if the attribute declarations here were updated = to the new format - a help in getting on the new path. My inclination would be to convert to the new format, inline in the section= s where the attribute syntax is currently defined, and then simply cross re= ference those definitions from the IANA Considerations section. Thanks, Paul On 12/9/14 6:53 PM, Charles Eckel (eckelcu) wrote: > On 12/9/14, 12:17 AM, "Christer Holmberg"=20 > > wrote: > >> Hi, >> >>>> Q1: >>>> >>>> There is a new "template" for defining SDP attributes. It has been=20 >>>> discussed on the MMUSIC list, and Paul K can give more information=20 >>>> if needed. >>> >>> A ptr to that would be helpful. I scanned the MMUSIC list quickly=20 >>> but must have missed it. >> >> Please look at section 6 in >> https://tools.ietf.org/id/draft-ietf-mmusic-rfc4566bis-12.txt > > This section makes consistent use of the following template (using=20 > =B3cat=B2 as an example): > > --- > Name: cat > > Value: cat-value > > Usage Level: session > > Charset Dependent: no > > Syntax: > > cat-value =3D category > category =3D byte-string > ; Note: syntax is vague because usage is not understood > > Example: > > a=3Dcat:foo.bar > > This attribute gives the dot-separated hierarchical category of the > session. This is to enable a receiver to filter unwanted sessions by > category. There is no central registry of categories. > > < > > I don=B9t believe draft-ietf-bfcpbis-rfc4583bis-10 should include such=20 > info for each attribute because similar information is already=20 > captured in the IANA considerations sections in for the format=20 > appropriate for IANA considerations. > >> >> >> >>>> Q2: >>>> >>>> Most SDP attributes are defined in their own sections - which is good. >>>> But, sometimes the section name contains the name of the attribute,=20 >>>> and sometimes not. I think it would be good to be consistent, and=20 >>>> always call the section "SDP xxx attribute". > > The IANA considerations section does this (i.e. SDP attribute name in=20 > section title). Sections 4-7 are organized by functionality rather=20 > than by SDP attribute. As such, I think the existing names are=20 > appropriate. We could add subsections for each attribute within these=20 > sections that are named according to the name of the corresponding SDP=20 > attribute. That said, I do think such additions would be all that useful. > >>>> >>>> Q3: >>> >>> There is no dedicated SDP Offer/Answer procedure section (instead,=20 >>> each section defining an SDP attribute include a few sentences about=20 >>> Offer/Answer). >>> >>> I think it would be good to have a dedicated SDP Offer/Answer=20 >>> procedure section, following the structure in RFC 3264. I've had to do = that e.g. >>> for BUNDLE and SCTP-SDP. >>> >>> I had a look at >>> http://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-negotiation- >>> 13 as an example. I see how we could rename and reorganize the=20 >>> existing content along these lines. I struggle with this a bit=20 >>> because I am comfortable with the existing document structure and my=20 >>> familiarity with it make it straightforward for me to understand.=20 >>> For a new reader, I think your suggested change will help, so I'm in=20 >>> favor of it. >> >> I took the text from the SCTP-SDP draft (note that the text may still=20 >> change), and tried to convert it into BFCP. Some parts are probably=20 >> still missing (for example, I realized that I forgot to add text=20 >> regarding the SDP 'floorctrl' attribute) , and maybe the BFCP draft=20 >> uses different terminology, but feel free to use it as a base: >> >> -------- >> >> 9. SDP Offer/Answer Procedures >> >> 9.1. General >> >> This section defines the SDP Offer/Answer [RFC3264] procedures for >> negotiating and establishing an BFCP connection. >> >> If the m- line proto value is ' TCP/TLS/BFCP ' or ' UDP/TLS/BFCP=20 >> ', each >> endpoint MUST provide a certificate fingerprint, using the SDP >> 'fingerprint' attribute [RFC4145], if the endpoint supports, and is >> willing to use, a cipher suite with an associated certificate. >> >> The authentication certificates are interpreted and validated as >> defined in [RFC4572]. Self-signed certificates can be used securely, >> provided that the integrity of the SDP description is assured as >> defined in [RFC4572]. >> >> NOTE: The procedures apply to a specific m- line describing an BFCP >> connection. If an offer or answer contains multiple m- line >> describing BFCP connections, the procedures are applied separately >> to each m- line. >> >> 9.2. Generating the Initial SDP Offer >> >> When the offerer creates an initial offer, the offerer: >> >> o MUST, if the m- line proto value is 'TCP/BFCP', 'TCP/TLS/BFCP' or >> 'UDP/TLS/BFCP', associate an SDP setup attribute [Section X],=20 >> with an >> 'actpass' value, with the m- line; >> >> o MUST, if the m- line proto value is 'TCP/BFCP' or 'TCP/TLS/BFCP', >> associate an SDP 'connection' attribute [Section 8.4], with a >> 'new' value, with the m- line; and >> >> In addition, if the offerer acts as the floor control server, the >> offerer: >> >> o MUST associate an SDP 'confid' attribute [Section X], with the=20 >> m- line; >> >> o MUST associate an SDP 'userid' attribute [Section X], with the=20 >> m- line; >> >> o MUST associate an SDP 'floorid' attribute [Section X], with the=20 >> m- line; and >> >> o MUST associate an SDP 'label' attribute [Section X], with the=20 >> m- line. >> >> 9.3. Generating the SDP Answer >> >> When the answerer receives an offer, which contains an m- line >> describing a BFCP connection, if the answerer accepts the m- line >> it: >> >> o MUST insert a corresponding m- line in the answer, with an >> identical m- line proto value [RFC3264]; and >> >> o MUST, if the m- line proto value is 'TCP/BFCP', 'TCP/TLS/BFCP' or >> 'UDP/TLS/BFCP', associate an SDP setup attribute [Section X],=20 >> with an >> 'active' or 'passive' value, with the m- line; >> >> In addition, if the answerer acts as the floor control server, the >> answerer: >> >> o MUST associate an SDP 'confid' attribute [Section X], with the=20 >> m- line; >> >> o MUST associate an SDP 'userid' attribute [Section X], with the=20 >> m- line; >> >> o MUST associate an SDP 'floorid' attribute [Section X], with the=20 >> m- line; and >> >> o MUST associate an SDP 'label' attribute [Section X], with the=20 >> m- line. >> >> Once the answerer has sent the answer, the answerer: >> >> o MUST, if the answerer is the 'active' endpoint, and if a TCP=20 >> connection >> associated with the m- line is to be established (or=20 >> re-established), >> initiate the establishing of the TCP connection; and >> >> o MUST, if the answerer is the 'active' endpoint, and if an TLS/DTLS >> connection associated with the m- line is to be established (or >> re-established), initiate the establishing of the TLS/DTLS=20 >> connection >> (by sending a ClientHello message). >> >> If the answerer does not accept the m- line in the offer, it MUST >> assign a zero port value to the corresponding m- line in the answer. >> In addition, the answerer MUST NOT establish an SCTP association, or >> a DTLS connection, associated with the m- line. >> >> 9.4. Offerer Processing of the SDP Answer >> >> When the offerer receives an answer, which contains an m- line with a >> non-zero port value, describing a BFCP connection, the offerer: >> >> o MUST, if the offer is the 'active' endpoint, and if a TCP=20 >> connection >> associated with the m- line is to be established (or=20 >> re-established), >> initiate the establishing of the TCP connection; and >> >> o MUST, if the offerer is the 'active' endpoint, and if an TLS/DTLS >> connection associated with the m- line is to be established (or >> re-established), initiate the establishing of the TLS/DTLS=20 >> connection >> (by sending a ClientHello message). >> >> If the m- line in the answer contains a zero port value, the offerer >> MUST NOT establish an TCP connection, or a TLS/DTLS connection, >> associated with the m- line. >> >> 9.5. Modifying the Session >> >> When an offerer sends an updated offer, in order to modify a >> previously established BFCP connection, it follows the procedures in >> Section 9.2, with the following exceptions: >> >> o If the BFCP connection is carried on top of TCP, and unless the >> offerer wants to re-establish an existing TCP connection, the >> offerer MUST associate an SDP connection attribute, with >> an 'existing' value, with the m- line; and >> >> o If the offerer wants to disable a previously established BFCP >> connection, it MUST assign a zero port value to the m- line >> associated with the BFCP connection, following the procedures in >> [RFC3264]. >> >> >> --------------- > > That looks pretty straightforward and clear to me. Adding the=20 > floorctrl attribute will complicate it some, but I think its still manage= able. > >> >> Q3b: >> >> The following sentence in 4583bis is a little confusing: >> >> "If the 'floorctrl' attribute is not used in an offer/answer exchange= , >> by default the offerer and the answerer will act as a floor control >> client and as a floor control server, respectively." >> >> Does this mean that the role may change every time an endpoint - for=20 >> whatever reason - sends an updated offer? > > Yes. This was inherited from RFC 4583, and it is the consequence of=20 > the lenient normative language immediately before it. > > "Endpoints that use the offer/answer model to establish BFCP > connections MUST support the 'floorctrl' attribute. A floor control > server acting as an offerer or as an answerer SHOULD include this > attribute in its session descriptions.=B2 > >> >> >> >> >>>> Q4: >>>> >>>> For DTLS and Offer/Answer, there are a few references to RFC 5763=20 >>>> here and there. But, I think it would be good to have explicit text=20 >>>> on the Offer/Answer considerations regarding DTLS - especially=20 >>>> since there have been quite a bit of discussions about that lately. >>> >>> Are you suggesting a copy/paste of the relevant text from RFC 5763=20 >>> in additional to a reference, or is there an calcification of what=20 >>> is provided in RFC 5763 that you added for SCTP that would be=20 >>> helpful for this draft? >> >> In the SCTP-SDP draft I have the following text, which is aligned=20 >> with RFC 5763, but provides a little more details. >> >> You could probably use the text just by replacing the proto field=20 >> values with the ones used for BFCP. >> >> ------------- >> >> 8.3.3. TLS Role Determination >> >> If the m- line proto value is 'SCTP/DTLS' or 'DTLS/SCTP', the >> 'active/passive' status is used to determine the TLS roles. >> Following the procedures in [RFC4572], the 'active' endpoint will >> take the TLS client role. >> >> Once a DTLS connection has been established, if the 'active/passive' >> status of the endpoints change during a session, a new DTLS >> connection MUST be established. Therefore, endpoints SHOULD NOT >> change the 'active/passive' status in subsequent offers and answers, >> unless they want to establish a new DTLS connection. >> >> If the transport parameters or the key fingerprints change, the >> endpoints MUST establish a new DTLS connection. In such case the >> 'active/passive' status of the endpoints will again be determined >> following the procedures in [RFC4145], and the new status will be >> used to determine the TLS roles associated with the new DTLS >> connection. >> >> NOTE: The procedure above is identical to the one defined for SRTP- >> DTLS in [RFC5763]. >> >> NOTE: A new DTLS connection needs to be established if the transport >> parameters or the key fingerprints change. >> >> ------------ > > I am okay with this. Its a nice summary. Our previous reference to RFC=20 > 5763, section 5, did not address session modification. This fixes that. > >> >>> Q5: >>> >>> The draft does not define how to use BFCP within a BUNDLE group.=20 >>> That is fine, but I think it would be good to explicitly indicate that. >>> >>> Yes. I'm thinking we need to point to >>> https://tools.ietf.org/html/draft-ietf-mmusic-sdp-mux-attributes-05# >>> page- >>> 28 for attributes defined in RFC 4583, and define the mux category=20 >>> for new attributes defined within this draft. >> >> Defining the mux category is one thing. >> >> But, if you want to define usage of BFCP within a BUNDLE group, you=20 >> also need to describe how BFCP is identified when bundled with other=20 >> protocols (RTP etc). > > I think this goes beyond what is needed for this draft. If someone=20 > wants to use BFCP with BUNDLE, they can define that usage. Sounds reasona= ble? > > Cheers, > Charles > >> >> Regards, >> >> Christer >> > > _______________________________________________ > bfcpbis mailing list > bfcpbis@ietf.org > https://www.ietf.org/mailman/listinfo/bfcpbis > _______________________________________________ bfcpbis mailing list bfcpbis@ietf.org https://www.ietf.org/mailman/listinfo/bfcpbis From nobody Thu Dec 11 10:28:01 2014 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3319B1A87EB for ; Thu, 11 Dec 2014 10:27:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hnsf3zvdPqfI for ; Thu, 11 Dec 2014 10:27:54 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D498D1A87BD for ; Thu, 11 Dec 2014 10:27:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22634; q=dns/txt; s=iport; t=1418322473; x=1419532073; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=MQVkq6UbQF8i0zfJr7Jt44ydSc6TJzSFB/uhH+kjCAw=; b=bO8s4SPbAs3kxz+8g+cnNKbrjqptu4+snhEMUzw1X67XB8MfS4LX90/Z WzO3hm3wZe/lmxEP8/NaVSinCiNeoNKnQi0supzgZp58oXtTyaS0eSrRZ ZyGYzuJwMJkk+A89fXPa81P+A693ngQYcjmVkioEIILFBof1GeUdf3ohL o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak0HAIThiVStJA2D/2dsb2JhbABXAg6CeFJYBIMBwmcKhSRKAhyBARYBAQEBAX2EDAEBAQQBAQExMwcXBAIBCBEEAQEBBBIRBQICJQsUCQgCBAESiCwNpSCcVQaWPAEBAQEBAQEBAQEBAQEBAQEBAQEBAReBG45eBgwLgkWBRwWFHYhigz6BfoMzgQwwgi2HQoJRgzcigy89bgGBBAcXBhx+AQEB X-IronPort-AV: E=Sophos;i="5.07,558,1413244800"; d="scan'208";a="104873320" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-4.cisco.com with ESMTP; 11 Dec 2014 18:27:52 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id sBBIRq59012717 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 11 Dec 2014 18:27:52 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.252]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0195.001; Thu, 11 Dec 2014 12:27:52 -0600 From: "Charles Eckel (eckelcu)" To: Christer Holmberg , Paul Kyzivat , "bfcpbis@ietf.org" Thread-Topic: [bfcpbis] Comments on draft-ietf-bfcpbis-rfc4583bis-10 Thread-Index: AdARgmEI5ESuyJkDTsuliRtAbu7OYQBjlDwAABy8dMAAHb3ZAAAwR3iAACuIbgD//+sbgA== Date: Thu, 11 Dec 2014 18:27:51 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D582373@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D588C28@ESESSMB209.ericsson.se> <54885F09.6010706@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D58E6C7@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D58E6C7@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.24.104.128] Content-Type: text/plain; charset="euc-kr" Content-ID: <35BDF84694D7054D84444B0695F4EEDC@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/bfcpbis/jnkk0UBaX7tDKzah0BwLcOqvreY Subject: Re: [bfcpbis] Comments on draft-ietf-bfcpbis-rfc4583bis-10 X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2014 18:27:59 -0000 KGFzIGFuIGluZGl2aWR1YWwpDQoNCkkgYWdyZWUgaW4gZ2VuZXJhbCwgYnV0IHNwZWNpZmljYWxs eSBpbiB0aGUgY2FzZSBvZiB0aGlzIGRyYWZ0LCBpdCBzaG91bGQNCmhhdmUgYmVlbiBjb21wbGV0 ZWQgbG9uZyBhZ28gYW5kIGl0IGlzIHZlcnkgY2xvc2UgdG8gYmVpbmcgc2VudCB0byB0aGUNCklF U0cgbm93LiBJIGRvIG5vdCB0aGluayBpdCBzaG91bGQgYmUgdXNlZCB0byB0ZXN0IHRoZSBuZXcg dGVtcGxhdGUuIE9ubHkNCm9uZSBvZiBpdHMgYXR0cmlidXRlcyBhcmUgbmV3IGFuZCB0aGUgcmVz dCBvZiBmcm9tIHJmYzQ1ODMuIENoYW5jZXMgYXJlLA0KdGhlcmUgd2lsbCBiZSBzb21lIGFkZGl0 aW9uYWwgY2hhbmdlcyB0byB0aGUgdGVtcGxhdGUgYmVmb3JlIDQ1NjZiaXMgaXMNCmZpbmlzaGVk LCBhbmQgZWl0aGVyIDQ1ODNiaXMgd2lsbCBuZWVkIHRvIGJlIHVwZGF0ZWQgYWdhaW4gb3IgaXQg d2lsbA0Kc3RpbGwgZGV2aWF0ZSBmcm9tIHRoZSB0ZW1wbGF0ZS4gV291bGRuoa90IGl0IGJlIG1v cmUgcmVhc29uYWJsZSB0byB1c2UgYQ0KbmV3IGRyYWZ0IGRlZmluaW5nIG5ldyBTRFAgYXR0cmli dXRlcyBhcyBhIHRlc3QgdmVoaWNsZT8NCg0KQ2hlZXJzLA0KQ2hhcmxlcw0KDQpPbiAxMi8xMS8x NCwgMzo0MiBBTSwgIkNocmlzdGVyIEhvbG1iZXJnIiA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nz b24uY29tPg0Kd3JvdGU6DQoNCj5IaSwNCj4NCj5JbiBvcmRlciB0byBmaWd1cmUgb3V0IHdoZXRo ZXIgUGF1bCdzIHN1Z2dlc3Rpb24gd29ya3MsIHNvbWVvbmUgbmVlZHMgdG8NCj51c2UgaXQgLSBi ZWZvcmUgdGhlIFNEUC1iaXMgZHJhZnQgaXMgcHVibGlzaGVkIGFzIFJGQyA6KQ0KPg0KPkl0J3Mg YSB2ZXJ5IHNtYWxsIHRhc2sgdG8gY2hhbmdlIGl0LiBJIGNvdWxkIGRvIGl0LCBidXQgSSdkIGxp a2Ugb3RoZXJzDQo+dG8gYWxzbyB0cnkgaXQgb3V0LCBhbmQgcHJvdmlkZSBmZWVkYmFjay4NCj4N Cj5SZWdhcmRzLA0KPg0KPkNocmlzdGVyDQo+DQo+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N Cj5Gcm9tOiBiZmNwYmlzIFttYWlsdG86YmZjcGJpcy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh bGYgT2YgUGF1bCBLeXppdmF0DQo+U2VudDogMTAuIGpvdWx1a3V1dGEgMjAxNCAxNjo1Ng0KPlRv OiBiZmNwYmlzQGlldGYub3JnDQo+U3ViamVjdDogUmU6IFtiZmNwYmlzXSBDb21tZW50cyBvbiBk cmFmdC1pZXRmLWJmY3BiaXMtcmZjNDU4M2Jpcy0xMA0KPg0KPkknbSBoZXJlIHRvIGRpc2N1c3Mg aG93IEkgdGhpbmsgdGhlIGF0dHJpYnV0ZSBkZWNsYXJhdGlvbiB1cGRhdGVzIHRvDQo+NDU2NmJp cyBzaG91bGQgYXBwbHkgaGVyZS4NCj4NCj4oTm90ZSB0aGF0IEkgaGF2ZW4ndCBiZWVuIGNsb3Nl bHkgZm9sbG93aW5nIHRoaXMgZHJhZnQuIEkgbm90ZWQNCj5DaHJpc3RlcidzIGNvbW1lbnRzLCBh bmQgdGhlbiBzY2FubmVkIHRoZSBkcmFmdCB0byBmaW5kIHJlbGV2YW50DQo+c2VjdGlvbnMuKQ0K Pg0KPkZpcnN0LCB0aGUgdGVtcGxhdGUgSSBoYXZlIGludHJvZHVjZWQgaW4gNDU2NmJpcyBpcyBu ZXcsIGFuZCBoYXNuJ3QgYmVlbg0KPnRob3JvdWdobHkgcmV2aWV3ZWQuIEl0IGlzIGdvb2QgdG8g ImRlYnVnIiBpdCBhbmQgZmluZSB0dW5lIGl0Lg0KPg0KPlNlY29uZCwgSSBoYXZlICpzb21lKiBz eW1wYXRoeSBmb3IgYmlzIGRyYWZ0cyBpbiBnZW5lcmFsLiBJdCBpcyBoYXJkIHRvDQo+ZGVjaWRl IGhvdyBtdWNoIHRvIGNoYW5nZSwgYW5kIHdoYXQgdG8gbGVhdmUgYWxvbmUuIE9UT0gsIEkgc2V0 IG91dA0KPnNwZWNpZmljYWxseSB0byBpbXByb3ZlIHRoZSBtZWNoYW5pc20gZm9yIGRlZmluaXRp b24gb2YgYXR0cmlidXRlcywgYW5kDQo+ZGlkIHVwZGF0ZSBhbGwgdGhlIGRlZmluaXRpb25zIGlu IDQ1NjZiaXMuIE15IGdvYWwgaXMgdG8gZW5zdXJlIHRoYXQNCj50aGVyZSBpcyBjbGFyaXR5IGlu IHRoZSBzeW50YXggb2YgYXR0cmlidXRlcywgYW5kIHRoYXQgZGV2ZWxvcGVycyByZWFkaW5nDQo+ dGhvc2Ugd2lsbCBrbm93IHdoYXQgdGhleSBhcmUgZXhwZWN0ZWQgdG8gZG8gdG8gcGFyc2UgdGhl bS4NCj4NCj5JIGZpbmQgdGhhdCB3aGF0IGlzIGluIHRoaXMgZG9jdW1lbnQgbm93IGRvZXMgYXQg bGVhc3QgZGVmaW5lIHRoZSBzeW50YXgNCj51bmFtYmlndW91c2x5Lg0KPg0KPk9UT0gsIGl0IGRv ZXMgaW1wbHkgdGhhdCB0aGUgYXR0cmlidXRlIG5hbWVzIGl0IGRlZmluZXMgc2hvdWxkIGJlIG1h dGNoZWQNCj5pbiBhIGNhc2UtaW5zZW5zaXRpdmUgd2F5LCB3aGljaCBpcyBjb250cmFyeSB0byB3 aGF0IDQ1NjYgc2F5cy4NCj4NCj5JIHRoaW5rIGl0IHdvdWxkIGJlICJuaWNlIiBpZiB0aGUgYXR0 cmlidXRlIGRlY2xhcmF0aW9ucyBoZXJlIHdlcmUNCj51cGRhdGVkIHRvIHRoZSBuZXcgZm9ybWF0 IC0gYSBoZWxwIGluIGdldHRpbmcgb24gdGhlIG5ldyBwYXRoLg0KPg0KPk15IGluY2xpbmF0aW9u IHdvdWxkIGJlIHRvIGNvbnZlcnQgdG8gdGhlIG5ldyBmb3JtYXQsIGlubGluZSBpbiB0aGUNCj5z ZWN0aW9ucyB3aGVyZSB0aGUgYXR0cmlidXRlIHN5bnRheCBpcyBjdXJyZW50bHkgZGVmaW5lZCwg YW5kIHRoZW4gc2ltcGx5DQo+Y3Jvc3MgcmVmZXJlbmNlIHRob3NlIGRlZmluaXRpb25zIGZyb20g dGhlIElBTkEgQ29uc2lkZXJhdGlvbnMgc2VjdGlvbi4NCj4NCj4JVGhhbmtzLA0KPglQYXVsDQo+ DQo+T24gMTIvOS8xNCA2OjUzIFBNLCBDaGFybGVzIEVja2VsIChlY2tlbGN1KSB3cm90ZToNCj4+ IE9uIDEyLzkvMTQsIDEyOjE3IEFNLCAiQ2hyaXN0ZXIgSG9sbWJlcmciDQo+PiA8Y2hyaXN0ZXIu aG9sbWJlcmdAZXJpY3Nzb24uY29tPg0KPj4gd3JvdGU6DQo+Pg0KPj4+IEhpLA0KPj4+DQo+Pj4+ PiBRMToNCj4+Pj4+DQo+Pj4+PiBUaGVyZSBpcyBhIG5ldyAidGVtcGxhdGUiIGZvciBkZWZpbmlu ZyBTRFAgYXR0cmlidXRlcy4gSXQgaGFzIGJlZW4NCj4+Pj4+IGRpc2N1c3NlZCBvbiB0aGUgTU1V U0lDIGxpc3QsIGFuZCBQYXVsIEsgY2FuIGdpdmUgbW9yZSBpbmZvcm1hdGlvbg0KPj4+Pj4gaWYg bmVlZGVkLg0KPj4+Pg0KPj4+PiBBIHB0ciB0byB0aGF0IHdvdWxkIGJlIGhlbHBmdWwuIEkgc2Nh bm5lZCB0aGUgTU1VU0lDIGxpc3QgcXVpY2tseQ0KPj4+PiBidXQgbXVzdCBoYXZlIG1pc3NlZCBp dC4NCj4+Pg0KPj4+IFBsZWFzZSBsb29rIGF0IHNlY3Rpb24gNiBpbg0KPj4+IGh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaWQvZHJhZnQtaWV0Zi1tbXVzaWMtcmZjNDU2NmJpcy0xMi50eHQNCj4+DQo+ PiBUaGlzIHNlY3Rpb24gbWFrZXMgY29uc2lzdGVudCB1c2Ugb2YgdGhlIGZvbGxvd2luZyB0ZW1w bGF0ZSAodXNpbmcNCj4+IKn4Y2F0qfcgYXMgYW4gZXhhbXBsZSk6DQo+Pg0KPj4gLS0tDQo+PiAg ICAgTmFtZTogY2F0DQo+Pg0KPj4gICAgIFZhbHVlOiBjYXQtdmFsdWUNCj4+DQo+PiAgICAgVXNh Z2UgTGV2ZWw6IHNlc3Npb24NCj4+DQo+PiAgICAgQ2hhcnNldCBEZXBlbmRlbnQ6IG5vDQo+Pg0K Pj4gICAgIFN5bnRheDoNCj4+DQo+PiAgICAgICAgY2F0LXZhbHVlID0gY2F0ZWdvcnkNCj4+ICAg ICAgICBjYXRlZ29yeSA9IGJ5dGUtc3RyaW5nDQo+PiAgICAgICAgICA7IE5vdGU6IHN5bnRheCBp cyB2YWd1ZSBiZWNhdXNlIHVzYWdlIGlzIG5vdCB1bmRlcnN0b29kDQo+Pg0KPj4gICAgIEV4YW1w bGU6DQo+Pg0KPj4gICAgICAgIGE9Y2F0OmZvby5iYXINCj4+DQo+PiAgICAgVGhpcyBhdHRyaWJ1 dGUgZ2l2ZXMgdGhlIGRvdC1zZXBhcmF0ZWQgaGllcmFyY2hpY2FsIGNhdGVnb3J5IG9mIHRoZQ0K Pj4gICAgIHNlc3Npb24uICBUaGlzIGlzIHRvIGVuYWJsZSBhIHJlY2VpdmVyIHRvIGZpbHRlciB1 bndhbnRlZCBzZXNzaW9ucw0KPj5ieQ0KPj4gICAgIGNhdGVnb3J5LiAgVGhlcmUgaXMgbm8gY2Vu dHJhbCByZWdpc3RyeSBvZiBjYXRlZ29yaWVzLg0KPj4NCj4+IDwNCj4+DQo+PiBJIGRvbqn2dCBi ZWxpZXZlIGRyYWZ0LWlldGYtYmZjcGJpcy1yZmM0NTgzYmlzLTEwIHNob3VsZCBpbmNsdWRlIHN1 Y2gNCj4+IGluZm8gZm9yIGVhY2ggYXR0cmlidXRlIGJlY2F1c2Ugc2ltaWxhciBpbmZvcm1hdGlv biBpcyBhbHJlYWR5DQo+PiBjYXB0dXJlZCBpbiB0aGUgSUFOQSBjb25zaWRlcmF0aW9ucyBzZWN0 aW9ucyBpbiBmb3IgdGhlIGZvcm1hdA0KPj4gYXBwcm9wcmlhdGUgZm9yIElBTkEgY29uc2lkZXJh dGlvbnMuDQo+Pg0KPj4+DQo+Pj4NCj4+Pg0KPj4+Pj4gUTI6DQo+Pj4+Pg0KPj4+Pj4gTW9zdCBT RFAgYXR0cmlidXRlcyBhcmUgZGVmaW5lZCBpbiB0aGVpciBvd24gc2VjdGlvbnMgLSB3aGljaCBp cw0KPj4+Pj5nb29kLg0KPj4+Pj4gQnV0LCBzb21ldGltZXMgdGhlIHNlY3Rpb24gbmFtZSBjb250 YWlucyB0aGUgbmFtZSBvZiB0aGUgYXR0cmlidXRlLA0KPj4+Pj4gYW5kIHNvbWV0aW1lcyBub3Qu IEkgdGhpbmsgaXQgd291bGQgYmUgZ29vZCB0byBiZSBjb25zaXN0ZW50LCBhbmQNCj4+Pj4+IGFs d2F5cyBjYWxsIHRoZSBzZWN0aW9uICJTRFAgeHh4IGF0dHJpYnV0ZSIuDQo+Pg0KPj4gVGhlIElB TkEgY29uc2lkZXJhdGlvbnMgc2VjdGlvbiBkb2VzIHRoaXMgKGkuZS4gU0RQIGF0dHJpYnV0ZSBu YW1lIGluDQo+PiBzZWN0aW9uIHRpdGxlKS4gU2VjdGlvbnMgNC03IGFyZSBvcmdhbml6ZWQgYnkg ZnVuY3Rpb25hbGl0eSByYXRoZXINCj4+IHRoYW4gYnkgU0RQIGF0dHJpYnV0ZS4gQXMgc3VjaCwg SSB0aGluayB0aGUgZXhpc3RpbmcgbmFtZXMgYXJlDQo+PiBhcHByb3ByaWF0ZS4gV2UgY291bGQg YWRkIHN1YnNlY3Rpb25zIGZvciBlYWNoIGF0dHJpYnV0ZSB3aXRoaW4gdGhlc2UNCj4+IHNlY3Rp b25zIHRoYXQgYXJlIG5hbWVkIGFjY29yZGluZyB0byB0aGUgbmFtZSBvZiB0aGUgY29ycmVzcG9u ZGluZyBTRFANCj4+IGF0dHJpYnV0ZS4gVGhhdCBzYWlkLCBJIGRvIHRoaW5rIHN1Y2ggYWRkaXRp b25zIHdvdWxkIGJlIGFsbCB0aGF0DQo+PnVzZWZ1bC4NCj4+DQo+Pj4+Pg0KPj4+Pj4gUTM6DQo+ Pj4+DQo+Pj4+IFRoZXJlIGlzIG5vIGRlZGljYXRlZCBTRFAgT2ZmZXIvQW5zd2VyIHByb2NlZHVy ZSBzZWN0aW9uIChpbnN0ZWFkLA0KPj4+PiBlYWNoIHNlY3Rpb24gZGVmaW5pbmcgYW4gU0RQIGF0 dHJpYnV0ZSBpbmNsdWRlIGEgZmV3IHNlbnRlbmNlcyBhYm91dA0KPj4+PiBPZmZlci9BbnN3ZXIp Lg0KPj4+Pg0KPj4+PiBJIHRoaW5rIGl0IHdvdWxkIGJlIGdvb2QgdG8gaGF2ZSBhIGRlZGljYXRl ZCBTRFAgT2ZmZXIvQW5zd2VyDQo+Pj4+IHByb2NlZHVyZSBzZWN0aW9uLCBmb2xsb3dpbmcgdGhl IHN0cnVjdHVyZSBpbiBSRkMgMzI2NC4gSSd2ZSBoYWQgdG8NCj4+Pj5kbyB0aGF0IGUuZy4NCj4+ Pj4gZm9yIEJVTkRMRSBhbmQgU0NUUC1TRFAuDQo+Pj4+DQo+Pj4+IEkgaGFkIGEgbG9vayBhdA0K Pj4+PiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW1tdXNpYy1zZHAtYnVu ZGxlLW5lZ290aWF0aW9uLQ0KPj4+PiAxMyBhcyBhbiBleGFtcGxlLiBJIHNlZSBob3cgd2UgY291 bGQgcmVuYW1lIGFuZCByZW9yZ2FuaXplIHRoZQ0KPj4+PiBleGlzdGluZyBjb250ZW50IGFsb25n IHRoZXNlIGxpbmVzLiBJIHN0cnVnZ2xlIHdpdGggdGhpcyBhIGJpdA0KPj4+PiBiZWNhdXNlIEkg YW0gY29tZm9ydGFibGUgd2l0aCB0aGUgZXhpc3RpbmcgZG9jdW1lbnQgc3RydWN0dXJlIGFuZCBt eQ0KPj4+PiBmYW1pbGlhcml0eSB3aXRoIGl0IG1ha2UgaXQgc3RyYWlnaHRmb3J3YXJkIGZvciBt ZSB0byB1bmRlcnN0YW5kLg0KPj4+PiBGb3IgYSBuZXcgcmVhZGVyLCBJIHRoaW5rIHlvdXIgc3Vn Z2VzdGVkIGNoYW5nZSB3aWxsIGhlbHAsIHNvIEknbSBpbg0KPj4+PiBmYXZvciBvZiBpdC4NCj4+ Pg0KPj4+IEkgdG9vayB0aGUgdGV4dCBmcm9tIHRoZSBTQ1RQLVNEUCBkcmFmdCAobm90ZSB0aGF0 IHRoZSB0ZXh0IG1heSBzdGlsbA0KPj4+IGNoYW5nZSksIGFuZCB0cmllZCB0byBjb252ZXJ0IGl0 IGludG8gQkZDUC4gU29tZSBwYXJ0cyBhcmUgcHJvYmFibHkNCj4+PiBzdGlsbCBtaXNzaW5nIChm b3IgZXhhbXBsZSwgSSByZWFsaXplZCB0aGF0IEkgZm9yZ290IHRvIGFkZCB0ZXh0DQo+Pj4gcmVn YXJkaW5nIHRoZSBTRFAgJ2Zsb29yY3RybCcgYXR0cmlidXRlKSAsIGFuZCBtYXliZSB0aGUgQkZD UCBkcmFmdA0KPj4+IHVzZXMgZGlmZmVyZW50IHRlcm1pbm9sb2d5LCBidXQgZmVlbCBmcmVlIHRv IHVzZSBpdCBhcyBhIGJhc2U6DQo+Pj4NCj4+PiAtLS0tLS0tLQ0KPj4+DQo+Pj4gOS4gIFNEUCBP ZmZlci9BbnN3ZXIgUHJvY2VkdXJlcw0KPj4+DQo+Pj4gOS4xLiAgR2VuZXJhbA0KPj4+DQo+Pj4g ICAgVGhpcyBzZWN0aW9uIGRlZmluZXMgdGhlIFNEUCBPZmZlci9BbnN3ZXIgW1JGQzMyNjRdIHBy b2NlZHVyZXMgZm9yDQo+Pj4gICAgbmVnb3RpYXRpbmcgYW5kIGVzdGFibGlzaGluZyBhbiBCRkNQ IGNvbm5lY3Rpb24uDQo+Pj4NCj4+PiAgICBJZiB0aGUgbS0gbGluZSBwcm90byB2YWx1ZSBpcyAn IFRDUC9UTFMvQkZDUCAnIG9yICcgVURQL1RMUy9CRkNQDQo+Pj4gJywgZWFjaA0KPj4+ICAgIGVu ZHBvaW50IE1VU1QgcHJvdmlkZSBhIGNlcnRpZmljYXRlIGZpbmdlcnByaW50LCB1c2luZyB0aGUg U0RQDQo+Pj4gICAgJ2ZpbmdlcnByaW50JyBhdHRyaWJ1dGUgW1JGQzQxNDVdLCBpZiB0aGUgZW5k cG9pbnQgc3VwcG9ydHMsIGFuZCBpcw0KPj4+ICAgIHdpbGxpbmcgdG8gdXNlLCBhIGNpcGhlciBz dWl0ZSB3aXRoIGFuIGFzc29jaWF0ZWQgY2VydGlmaWNhdGUuDQo+Pj4NCj4+PiAgICBUaGUgYXV0 aGVudGljYXRpb24gY2VydGlmaWNhdGVzIGFyZSBpbnRlcnByZXRlZCBhbmQgdmFsaWRhdGVkIGFz DQo+Pj4gICAgZGVmaW5lZCBpbiBbUkZDNDU3Ml0uICBTZWxmLXNpZ25lZCBjZXJ0aWZpY2F0ZXMg Y2FuIGJlIHVzZWQNCj4+PnNlY3VyZWx5LA0KPj4+ICAgIHByb3ZpZGVkIHRoYXQgdGhlIGludGVn cml0eSBvZiB0aGUgU0RQIGRlc2NyaXB0aW9uIGlzIGFzc3VyZWQgYXMNCj4+PiAgICBkZWZpbmVk IGluIFtSRkM0NTcyXS4NCj4+Pg0KPj4+ICAgIE5PVEU6IFRoZSBwcm9jZWR1cmVzIGFwcGx5IHRv IGEgc3BlY2lmaWMgbS0gbGluZSBkZXNjcmliaW5nIGFuIEJGQ1ANCj4+PiAgICBjb25uZWN0aW9u LiAgSWYgYW4gb2ZmZXIgb3IgYW5zd2VyIGNvbnRhaW5zIG11bHRpcGxlIG0tIGxpbmUNCj4+PiAg ICBkZXNjcmliaW5nIEJGQ1AgY29ubmVjdGlvbnMsIHRoZSBwcm9jZWR1cmVzIGFyZSBhcHBsaWVk IHNlcGFyYXRlbHkNCj4+PiAgICB0byBlYWNoIG0tIGxpbmUuDQo+Pj4NCj4+PiA5LjIuICBHZW5l cmF0aW5nIHRoZSBJbml0aWFsIFNEUCBPZmZlcg0KPj4+DQo+Pj4gICBXaGVuIHRoZSBvZmZlcmVy IGNyZWF0ZXMgYW4gaW5pdGlhbCBvZmZlciwgdGhlIG9mZmVyZXI6DQo+Pj4NCj4+PiAgICBvICBN VVNULCBpZiB0aGUgbS0gbGluZSBwcm90byB2YWx1ZSBpcyAnVENQL0JGQ1AnLCAnVENQL1RMUy9C RkNQJyBvcg0KPj4+ICAgICAgICAnVURQL1RMUy9CRkNQJywgYXNzb2NpYXRlIGFuIFNEUCBzZXR1 cCBhdHRyaWJ1dGUgW1NlY3Rpb24gWF0sDQo+Pj4gd2l0aCBhbg0KPj4+ICAgICAgICdhY3RwYXNz JyB2YWx1ZSwgd2l0aCB0aGUgbS0gbGluZTsNCj4+Pg0KPj4+ICAgIG8gIE1VU1QsIGlmIHRoZSBt LSBsaW5lIHByb3RvIHZhbHVlIGlzICdUQ1AvQkZDUCcgb3IgJ1RDUC9UTFMvQkZDUCcsDQo+Pj4g ICAgICAgIGFzc29jaWF0ZSBhbiBTRFAgJ2Nvbm5lY3Rpb24nIGF0dHJpYnV0ZSBbU2VjdGlvbiA4 LjRdLCB3aXRoIGENCj4+PiAgICAgICAgJ25ldycgdmFsdWUsIHdpdGggdGhlIG0tIGxpbmU7IGFu ZA0KPj4+DQo+Pj4gICAgSW4gYWRkaXRpb24sIGlmIHRoZSBvZmZlcmVyIGFjdHMgYXMgdGhlIGZs b29yIGNvbnRyb2wgc2VydmVyLCB0aGUNCj4+PiBvZmZlcmVyOg0KPj4+DQo+Pj4gICAgbyAgTVVT VCBhc3NvY2lhdGUgYW4gU0RQICdjb25maWQnIGF0dHJpYnV0ZSBbU2VjdGlvbiBYXSwgd2l0aCB0 aGUNCj4+PiBtLSBsaW5lOw0KPj4+DQo+Pj4gICAgbyAgTVVTVCBhc3NvY2lhdGUgYW4gU0RQICd1 c2VyaWQnIGF0dHJpYnV0ZSBbU2VjdGlvbiBYXSwgd2l0aCB0aGUNCj4+PiBtLSBsaW5lOw0KPj4+ DQo+Pj4gICAgbyAgTVVTVCBhc3NvY2lhdGUgYW4gU0RQICdmbG9vcmlkJyBhdHRyaWJ1dGUgW1Nl Y3Rpb24gWF0sIHdpdGggdGhlDQo+Pj4gbS0gbGluZTsgYW5kDQo+Pj4NCj4+PiAgICBvICBNVVNU IGFzc29jaWF0ZSBhbiBTRFAgJ2xhYmVsJyBhdHRyaWJ1dGUgW1NlY3Rpb24gWF0sIHdpdGggdGhl DQo+Pj4gbS0gbGluZS4NCj4+Pg0KPj4+IDkuMy4gIEdlbmVyYXRpbmcgdGhlIFNEUCBBbnN3ZXIN Cj4+Pg0KPj4+ICAgIFdoZW4gdGhlIGFuc3dlcmVyIHJlY2VpdmVzIGFuIG9mZmVyLCB3aGljaCBj b250YWlucyBhbiBtLSBsaW5lDQo+Pj4gICAgZGVzY3JpYmluZyBhIEJGQ1AgY29ubmVjdGlvbiwg aWYgdGhlIGFuc3dlcmVyIGFjY2VwdHMgdGhlIG0tIGxpbmUNCj4+PiAgICBpdDoNCj4+Pg0KPj4+ ICAgIG8gIE1VU1QgaW5zZXJ0IGEgY29ycmVzcG9uZGluZyBtLSBsaW5lIGluIHRoZSBhbnN3ZXIs IHdpdGggYW4NCj4+PiAgICAgICBpZGVudGljYWwgbS0gbGluZSBwcm90byB2YWx1ZSBbUkZDMzI2 NF07IGFuZA0KPj4+DQo+Pj4gICAgbyAgTVVTVCwgaWYgdGhlIG0tIGxpbmUgcHJvdG8gdmFsdWUg aXMgJ1RDUC9CRkNQJywgJ1RDUC9UTFMvQkZDUCcgb3INCj4+PiAgICAgICAgJ1VEUC9UTFMvQkZD UCcsIGFzc29jaWF0ZSBhbiBTRFAgc2V0dXAgYXR0cmlidXRlIFtTZWN0aW9uIFhdLA0KPj4+IHdp dGggYW4NCj4+PiAgICAgICAnYWN0aXZlJyBvciAncGFzc2l2ZScgdmFsdWUsIHdpdGggdGhlIG0t IGxpbmU7DQo+Pj4NCj4+PiAgICBJbiBhZGRpdGlvbiwgaWYgdGhlIGFuc3dlcmVyIGFjdHMgYXMg dGhlIGZsb29yIGNvbnRyb2wgc2VydmVyLCB0aGUNCj4+PiBhbnN3ZXJlcjoNCj4+Pg0KPj4+ICAg IG8gIE1VU1QgYXNzb2NpYXRlIGFuIFNEUCAnY29uZmlkJyBhdHRyaWJ1dGUgW1NlY3Rpb24gWF0s IHdpdGggdGhlDQo+Pj4gbS0gbGluZTsNCj4+Pg0KPj4+ICAgIG8gIE1VU1QgYXNzb2NpYXRlIGFu IFNEUCAndXNlcmlkJyBhdHRyaWJ1dGUgW1NlY3Rpb24gWF0sIHdpdGggdGhlDQo+Pj4gbS0gbGlu ZTsNCj4+Pg0KPj4+ICAgIG8gIE1VU1QgYXNzb2NpYXRlIGFuIFNEUCAnZmxvb3JpZCcgYXR0cmli dXRlIFtTZWN0aW9uIFhdLCB3aXRoIHRoZQ0KPj4+IG0tIGxpbmU7IGFuZA0KPj4+DQo+Pj4gICAg byAgTVVTVCBhc3NvY2lhdGUgYW4gU0RQICdsYWJlbCcgYXR0cmlidXRlIFtTZWN0aW9uIFhdLCB3 aXRoIHRoZQ0KPj4+IG0tIGxpbmUuDQo+Pj4NCj4+PiAgICBPbmNlIHRoZSBhbnN3ZXJlciBoYXMg c2VudCB0aGUgYW5zd2VyLCB0aGUgYW5zd2VyZXI6DQo+Pj4NCj4+PiAgICBvICBNVVNULCBpZiB0 aGUgYW5zd2VyZXIgaXMgdGhlICdhY3RpdmUnIGVuZHBvaW50LCBhbmQgaWYgYSBUQ1ANCj4+PiBj b25uZWN0aW9uDQo+Pj4gICAgICAgIGFzc29jaWF0ZWQgd2l0aCB0aGUgbS0gbGluZSBpcyB0byBi ZSBlc3RhYmxpc2hlZCAob3INCj4+PiByZS1lc3RhYmxpc2hlZCksDQo+Pj4gICAgICAgIGluaXRp YXRlIHRoZSBlc3RhYmxpc2hpbmcgb2YgdGhlIFRDUCBjb25uZWN0aW9uOyBhbmQNCj4+Pg0KPj4+ ICAgIG8gIE1VU1QsIGlmIHRoZSBhbnN3ZXJlciBpcyB0aGUgJ2FjdGl2ZScgZW5kcG9pbnQsIGFu ZCBpZiBhbg0KPj4+VExTL0RUTFMNCj4+PiAgICAgICBjb25uZWN0aW9uIGFzc29jaWF0ZWQgd2l0 aCB0aGUgbS0gbGluZSBpcyB0byBiZSBlc3RhYmxpc2hlZCAob3INCj4+PiAgICAgICByZS1lc3Rh Ymxpc2hlZCksIGluaXRpYXRlIHRoZSBlc3RhYmxpc2hpbmcgb2YgdGhlIFRMUy9EVExTDQo+Pj4g Y29ubmVjdGlvbg0KPj4+ICAgICAgIChieSBzZW5kaW5nIGEgQ2xpZW50SGVsbG8gbWVzc2FnZSku DQo+Pj4NCj4+PiAgICBJZiB0aGUgYW5zd2VyZXIgZG9lcyBub3QgYWNjZXB0IHRoZSBtLSBsaW5l IGluIHRoZSBvZmZlciwgaXQgTVVTVA0KPj4+ICAgIGFzc2lnbiBhIHplcm8gcG9ydCB2YWx1ZSB0 byB0aGUgY29ycmVzcG9uZGluZyBtLSBsaW5lIGluIHRoZSBhbnN3ZXIuDQo+Pj4gICAgSW4gYWRk aXRpb24sIHRoZSBhbnN3ZXJlciBNVVNUIE5PVCBlc3RhYmxpc2ggYW4gU0NUUCBhc3NvY2lhdGlv biwgb3INCj4+PiAgICBhIERUTFMgY29ubmVjdGlvbiwgYXNzb2NpYXRlZCB3aXRoIHRoZSBtLSBs aW5lLg0KPj4+DQo+Pj4gOS40LiAgT2ZmZXJlciBQcm9jZXNzaW5nIG9mIHRoZSBTRFAgQW5zd2Vy DQo+Pj4NCj4+PiAgICBXaGVuIHRoZSBvZmZlcmVyIHJlY2VpdmVzIGFuIGFuc3dlciwgd2hpY2gg Y29udGFpbnMgYW4gbS0gbGluZSB3aXRoDQo+Pj5hDQo+Pj4gICAgbm9uLXplcm8gcG9ydCB2YWx1 ZSwgZGVzY3JpYmluZyBhIEJGQ1AgY29ubmVjdGlvbiwgdGhlIG9mZmVyZXI6DQo+Pj4NCj4+PiAg ICBvICBNVVNULCBpZiB0aGUgb2ZmZXIgaXMgdGhlICdhY3RpdmUnIGVuZHBvaW50LCBhbmQgaWYg YSBUQ1ANCj4+PiBjb25uZWN0aW9uDQo+Pj4gICAgICAgIGFzc29jaWF0ZWQgd2l0aCB0aGUgbS0g bGluZSBpcyB0byBiZSBlc3RhYmxpc2hlZCAob3INCj4+PiByZS1lc3RhYmxpc2hlZCksDQo+Pj4g ICAgICAgIGluaXRpYXRlIHRoZSBlc3RhYmxpc2hpbmcgb2YgdGhlIFRDUCBjb25uZWN0aW9uOyBh bmQNCj4+Pg0KPj4+ICAgIG8gIE1VU1QsIGlmIHRoZSBvZmZlcmVyIGlzIHRoZSAnYWN0aXZlJyBl bmRwb2ludCwgYW5kIGlmIGFuIFRMUy9EVExTDQo+Pj4gICAgICAgY29ubmVjdGlvbiBhc3NvY2lh dGVkIHdpdGggdGhlIG0tIGxpbmUgaXMgdG8gYmUgZXN0YWJsaXNoZWQgKG9yDQo+Pj4gICAgICAg cmUtZXN0YWJsaXNoZWQpLCBpbml0aWF0ZSB0aGUgZXN0YWJsaXNoaW5nIG9mIHRoZSBUTFMvRFRM Uw0KPj4+IGNvbm5lY3Rpb24NCj4+PiAgICAgICAoYnkgc2VuZGluZyBhIENsaWVudEhlbGxvIG1l c3NhZ2UpLg0KPj4+DQo+Pj4gICAgSWYgdGhlIG0tIGxpbmUgaW4gdGhlIGFuc3dlciBjb250YWlu cyBhIHplcm8gcG9ydCB2YWx1ZSwgdGhlIG9mZmVyZXINCj4+PiAgICBNVVNUIE5PVCBlc3RhYmxp c2ggYW4gVENQIGNvbm5lY3Rpb24sIG9yIGEgVExTL0RUTFMgY29ubmVjdGlvbiwNCj4+PiAgICBh c3NvY2lhdGVkIHdpdGggdGhlIG0tIGxpbmUuDQo+Pj4NCj4+PiA5LjUuICBNb2RpZnlpbmcgdGhl IFNlc3Npb24NCj4+Pg0KPj4+ICAgIFdoZW4gYW4gb2ZmZXJlciBzZW5kcyBhbiB1cGRhdGVkIG9m ZmVyLCBpbiBvcmRlciB0byBtb2RpZnkgYQ0KPj4+ICAgIHByZXZpb3VzbHkgZXN0YWJsaXNoZWQg QkZDUCBjb25uZWN0aW9uLCBpdCBmb2xsb3dzIHRoZSBwcm9jZWR1cmVzIGluDQo+Pj4gICAgU2Vj dGlvbiA5LjIsIHdpdGggdGhlIGZvbGxvd2luZyBleGNlcHRpb25zOg0KPj4+DQo+Pj4gICAgbyAg SWYgdGhlIEJGQ1AgY29ubmVjdGlvbiBpcyBjYXJyaWVkIG9uIHRvcCBvZiBUQ1AsIGFuZCB1bmxl c3MgdGhlDQo+Pj4gICAgICAgIG9mZmVyZXIgd2FudHMgdG8gcmUtZXN0YWJsaXNoIGFuIGV4aXN0 aW5nIFRDUCBjb25uZWN0aW9uLCB0aGUNCj4+PiAgICAgICAgb2ZmZXJlciBNVVNUIGFzc29jaWF0 ZSBhbiBTRFAgY29ubmVjdGlvbiBhdHRyaWJ1dGUsIHdpdGgNCj4+PiAgICAgICBhbiAnZXhpc3Rp bmcnIHZhbHVlLCB3aXRoIHRoZSBtLSBsaW5lOyBhbmQNCj4+Pg0KPj4+ICAgIG8gIElmIHRoZSBv ZmZlcmVyIHdhbnRzIHRvIGRpc2FibGUgYSBwcmV2aW91c2x5IGVzdGFibGlzaGVkIEJGQ1ANCj4+ PiAgICAgICBjb25uZWN0aW9uLCBpdCBNVVNUIGFzc2lnbiBhIHplcm8gcG9ydCB2YWx1ZSB0byB0 aGUgbS0gbGluZQ0KPj4+ICAgICAgIGFzc29jaWF0ZWQgd2l0aCB0aGUgQkZDUCBjb25uZWN0aW9u LCBmb2xsb3dpbmcgdGhlIHByb2NlZHVyZXMgaW4NCj4+PiAgICAgICBbUkZDMzI2NF0uDQo+Pj4N Cj4+Pg0KPj4+IC0tLS0tLS0tLS0tLS0tLQ0KPj4NCj4+IFRoYXQgbG9va3MgcHJldHR5IHN0cmFp Z2h0Zm9yd2FyZCBhbmQgY2xlYXIgdG8gbWUuIEFkZGluZyB0aGUNCj4+IGZsb29yY3RybCBhdHRy aWJ1dGUgd2lsbCBjb21wbGljYXRlIGl0IHNvbWUsIGJ1dCBJIHRoaW5rIGl0cyBzdGlsbA0KPj5t YW5hZ2VhYmxlLg0KPj4NCj4+Pg0KPj4+IFEzYjoNCj4+Pg0KPj4+IFRoZSBmb2xsb3dpbmcgc2Vu dGVuY2UgaW4gNDU4M2JpcyBpcyBhIGxpdHRsZSBjb25mdXNpbmc6DQo+Pj4NCj4+PiAgICAiSWYg dGhlICdmbG9vcmN0cmwnIGF0dHJpYnV0ZSBpcyBub3QgdXNlZCBpbiBhbiBvZmZlci9hbnN3ZXIN Cj4+PmV4Y2hhbmdlLA0KPj4+ICAgIGJ5IGRlZmF1bHQgdGhlIG9mZmVyZXIgYW5kIHRoZSBhbnN3 ZXJlciB3aWxsIGFjdCBhcyBhIGZsb29yIGNvbnRyb2wNCj4+PiAgICBjbGllbnQgYW5kIGFzIGEg Zmxvb3IgY29udHJvbCBzZXJ2ZXIsIHJlc3BlY3RpdmVseS4iDQo+Pj4NCj4+PiBEb2VzIHRoaXMg bWVhbiB0aGF0IHRoZSByb2xlIG1heSBjaGFuZ2UgZXZlcnkgdGltZSBhbiBlbmRwb2ludCAtIGZv cg0KPj4+IHdoYXRldmVyIHJlYXNvbiAtIHNlbmRzIGFuIHVwZGF0ZWQgb2ZmZXI/DQo+Pg0KPj4g WWVzLiBUaGlzIHdhcyBpbmhlcml0ZWQgZnJvbSBSRkMgNDU4MywgYW5kIGl0IGlzIHRoZSBjb25z ZXF1ZW5jZSBvZg0KPj4gdGhlIGxlbmllbnQgbm9ybWF0aXZlIGxhbmd1YWdlIGltbWVkaWF0ZWx5 IGJlZm9yZSBpdC4NCj4+DQo+PiAJIkVuZHBvaW50cyB0aGF0IHVzZSB0aGUgb2ZmZXIvYW5zd2Vy IG1vZGVsIHRvIGVzdGFibGlzaCBCRkNQDQo+PiAJY29ubmVjdGlvbnMgTVVTVCBzdXBwb3J0IHRo ZSAnZmxvb3JjdHJsJyBhdHRyaWJ1dGUuICBBIGZsb29yIGNvbnRyb2wNCj4+IAlzZXJ2ZXIgYWN0 aW5nIGFzIGFuIG9mZmVyZXIgb3IgYXMgYW4gYW5zd2VyZXIgU0hPVUxEIGluY2x1ZGUgdGhpcw0K Pj4gCWF0dHJpYnV0ZSBpbiBpdHMgc2Vzc2lvbiBkZXNjcmlwdGlvbnMuqfcNCj4+DQo+Pj4NCj4+ Pg0KPj4+DQo+Pj4NCj4+Pj4+IFE0Og0KPj4+Pj4NCj4+Pj4+IEZvciBEVExTIGFuZCBPZmZlci9B bnN3ZXIsIHRoZXJlIGFyZSBhIGZldyByZWZlcmVuY2VzIHRvIFJGQyA1NzYzDQo+Pj4+PiBoZXJl IGFuZCB0aGVyZS4gQnV0LCBJIHRoaW5rIGl0IHdvdWxkIGJlIGdvb2QgdG8gaGF2ZSBleHBsaWNp dCB0ZXh0DQo+Pj4+PiBvbiB0aGUgT2ZmZXIvQW5zd2VyIGNvbnNpZGVyYXRpb25zIHJlZ2FyZGlu ZyBEVExTIC0gZXNwZWNpYWxseQ0KPj4+Pj4gc2luY2UgdGhlcmUgaGF2ZSBiZWVuIHF1aXRlIGEg Yml0IG9mIGRpc2N1c3Npb25zIGFib3V0IHRoYXQgbGF0ZWx5Lg0KPj4+Pg0KPj4+PiBBcmUgeW91 IHN1Z2dlc3RpbmcgYSBjb3B5L3Bhc3RlIG9mIHRoZSByZWxldmFudCB0ZXh0IGZyb20gUkZDIDU3 NjMNCj4+Pj4gaW4gYWRkaXRpb25hbCB0byBhIHJlZmVyZW5jZSwgb3IgaXMgdGhlcmUgYW4gY2Fs Y2lmaWNhdGlvbiBvZiB3aGF0DQo+Pj4+IGlzIHByb3ZpZGVkIGluIFJGQyA1NzYzIHRoYXQgeW91 IGFkZGVkIGZvciBTQ1RQIHRoYXQgd291bGQgYmUNCj4+Pj4gaGVscGZ1bCBmb3IgdGhpcyBkcmFm dD8NCj4+Pg0KPj4+IEluIHRoZSBTQ1RQLVNEUCBkcmFmdCBJIGhhdmUgdGhlIGZvbGxvd2luZyB0 ZXh0LCB3aGljaCBpcyBhbGlnbmVkDQo+Pj4gd2l0aCBSRkMgNTc2MywgYnV0IHByb3ZpZGVzIGEg bGl0dGxlIG1vcmUgZGV0YWlscy4NCj4+Pg0KPj4+IFlvdSBjb3VsZCBwcm9iYWJseSB1c2UgdGhl IHRleHQganVzdCBieSByZXBsYWNpbmcgdGhlIHByb3RvIGZpZWxkDQo+Pj4gdmFsdWVzIHdpdGgg dGhlIG9uZXMgdXNlZCBmb3IgQkZDUC4NCj4+Pg0KPj4+IC0tLS0tLS0tLS0tLS0NCj4+Pg0KPj4+ IDguMy4zLiAgVExTIFJvbGUgRGV0ZXJtaW5hdGlvbg0KPj4+DQo+Pj4gICAgSWYgdGhlIG0tIGxp bmUgcHJvdG8gdmFsdWUgaXMgJ1NDVFAvRFRMUycgb3IgJ0RUTFMvU0NUUCcsIHRoZQ0KPj4+ICAg ICdhY3RpdmUvcGFzc2l2ZScgc3RhdHVzIGlzIHVzZWQgdG8gZGV0ZXJtaW5lIHRoZSBUTFMgcm9s ZXMuDQo+Pj4gICAgRm9sbG93aW5nIHRoZSBwcm9jZWR1cmVzIGluIFtSRkM0NTcyXSwgdGhlICdh Y3RpdmUnIGVuZHBvaW50IHdpbGwNCj4+PiAgICB0YWtlIHRoZSBUTFMgY2xpZW50IHJvbGUuDQo+ Pj4NCj4+PiAgICBPbmNlIGEgRFRMUyBjb25uZWN0aW9uIGhhcyBiZWVuIGVzdGFibGlzaGVkLCBp ZiB0aGUgJ2FjdGl2ZS9wYXNzaXZlJw0KPj4+ICAgIHN0YXR1cyBvZiB0aGUgZW5kcG9pbnRzIGNo YW5nZSBkdXJpbmcgYSBzZXNzaW9uLCBhIG5ldyBEVExTDQo+Pj4gICAgY29ubmVjdGlvbiBNVVNU IGJlIGVzdGFibGlzaGVkLiAgVGhlcmVmb3JlLCBlbmRwb2ludHMgU0hPVUxEIE5PVA0KPj4+ICAg IGNoYW5nZSB0aGUgJ2FjdGl2ZS9wYXNzaXZlJyBzdGF0dXMgaW4gc3Vic2VxdWVudCBvZmZlcnMg YW5kIGFuc3dlcnMsDQo+Pj4gICAgdW5sZXNzIHRoZXkgd2FudCB0byBlc3RhYmxpc2ggYSBuZXcg RFRMUyBjb25uZWN0aW9uLg0KPj4+DQo+Pj4gICAgSWYgdGhlIHRyYW5zcG9ydCBwYXJhbWV0ZXJz IG9yIHRoZSBrZXkgZmluZ2VycHJpbnRzIGNoYW5nZSwgdGhlDQo+Pj4gICAgZW5kcG9pbnRzIE1V U1QgZXN0YWJsaXNoIGEgbmV3IERUTFMgY29ubmVjdGlvbi4gIEluIHN1Y2ggY2FzZSB0aGUNCj4+ PiAgICAnYWN0aXZlL3Bhc3NpdmUnIHN0YXR1cyBvZiB0aGUgZW5kcG9pbnRzIHdpbGwgYWdhaW4g YmUgZGV0ZXJtaW5lZA0KPj4+ICAgIGZvbGxvd2luZyB0aGUgcHJvY2VkdXJlcyBpbiBbUkZDNDE0 NV0sIGFuZCB0aGUgbmV3IHN0YXR1cyB3aWxsIGJlDQo+Pj4gICAgdXNlZCB0byBkZXRlcm1pbmUg dGhlIFRMUyByb2xlcyBhc3NvY2lhdGVkIHdpdGggdGhlIG5ldyBEVExTDQo+Pj4gICAgY29ubmVj dGlvbi4NCj4+Pg0KPj4+ICAgIE5PVEU6IFRoZSBwcm9jZWR1cmUgYWJvdmUgaXMgaWRlbnRpY2Fs IHRvIHRoZSBvbmUgZGVmaW5lZCBmb3IgU1JUUC0NCj4+PiAgICBEVExTIGluIFtSRkM1NzYzXS4N Cj4+Pg0KPj4+ICAgIE5PVEU6IEEgbmV3IERUTFMgY29ubmVjdGlvbiBuZWVkcyB0byBiZSBlc3Rh Ymxpc2hlZCBpZiB0aGUgdHJhbnNwb3J0DQo+Pj4gICAgcGFyYW1ldGVycyBvciB0aGUga2V5IGZp bmdlcnByaW50cyBjaGFuZ2UuDQo+Pj4NCj4+PiAtLS0tLS0tLS0tLS0NCj4+DQo+PiBJIGFtIG9r YXkgd2l0aCB0aGlzLiBJdHMgYSBuaWNlIHN1bW1hcnkuIE91ciBwcmV2aW91cyByZWZlcmVuY2Ug dG8gUkZDDQo+PiA1NzYzLCBzZWN0aW9uIDUsIGRpZCBub3QgYWRkcmVzcyBzZXNzaW9uIG1vZGlm aWNhdGlvbi4gVGhpcyBmaXhlcyB0aGF0Lg0KPj4NCj4+Pg0KPj4+PiBRNToNCj4+Pj4NCj4+Pj4g VGhlIGRyYWZ0IGRvZXMgbm90IGRlZmluZSBob3cgdG8gdXNlIEJGQ1Agd2l0aGluIGEgQlVORExF IGdyb3VwLg0KPj4+PiBUaGF0IGlzIGZpbmUsIGJ1dCBJIHRoaW5rIGl0IHdvdWxkIGJlIGdvb2Qg dG8gZXhwbGljaXRseSBpbmRpY2F0ZQ0KPj4+PnRoYXQuDQo+Pj4+DQo+Pj4+IFllcy4gSSdtIHRo aW5raW5nIHdlIG5lZWQgdG8gcG9pbnQgdG8NCj4+Pj4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWlldGYtbW11c2ljLXNkcC1tdXgtYXR0cmlidXRlcy0wNSMNCj4+Pj4gcGFnZS0N Cj4+Pj4gMjggZm9yIGF0dHJpYnV0ZXMgZGVmaW5lZCBpbiBSRkMgNDU4MywgYW5kICBkZWZpbmUg IHRoZSBtdXggY2F0ZWdvcnkNCj4+Pj4gZm9yIG5ldyBhdHRyaWJ1dGVzIGRlZmluZWQgd2l0aGlu IHRoaXMgZHJhZnQuDQo+Pj4NCj4+PiBEZWZpbmluZyB0aGUgbXV4IGNhdGVnb3J5IGlzIG9uZSB0 aGluZy4NCj4+Pg0KPj4+IEJ1dCwgaWYgeW91IHdhbnQgdG8gZGVmaW5lIHVzYWdlIG9mIEJGQ1Ag d2l0aGluIGEgQlVORExFIGdyb3VwLCB5b3UNCj4+PiBhbHNvIG5lZWQgdG8gZGVzY3JpYmUgaG93 IEJGQ1AgaXMgaWRlbnRpZmllZCB3aGVuIGJ1bmRsZWQgd2l0aCBvdGhlcg0KPj4+IHByb3RvY29s cyAoUlRQIGV0YykuDQo+Pg0KPj4gSSB0aGluayB0aGlzIGdvZXMgYmV5b25kIHdoYXQgaXMgbmVl ZGVkIGZvciB0aGlzIGRyYWZ0LiBJZiBzb21lb25lDQo+PiB3YW50cyB0byB1c2UgQkZDUCB3aXRo IEJVTkRMRSwgdGhleSBjYW4gZGVmaW5lIHRoYXQgdXNhZ2UuIFNvdW5kcw0KPj5yZWFzb25hYmxl Pw0KPj4NCj4+IENoZWVycywNCj4+IENoYXJsZXMNCj4+DQo+Pj4NCj4+PiBSZWdhcmRzLA0KPj4+ DQo+Pj4gQ2hyaXN0ZXINCj4+Pg0KPj4NCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+PiBiZmNwYmlzIG1haWxpbmcgbGlzdA0KPj4gYmZjcGJpc0Bp ZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9iZmNwYmlz DQo+Pg0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+YmZjcGJpcyBtYWlsaW5nIGxpc3QNCj5iZmNwYmlzQGlldGYub3JnDQo+aHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9iZmNwYmlzDQo+DQo+X19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5iZmNwYmlzIG1haWxpbmcgbGlzdA0KPmJm Y3BiaXNAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Jm Y3BiaXMNCg0K From nobody Thu Dec 11 10:34:35 2014 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DDF61A87C8 for ; Thu, 11 Dec 2014 10:34:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VtZG09SeuyIF for ; Thu, 11 Dec 2014 10:34:31 -0800 (PST) Received: from resqmta-ch2-07v.sys.comcast.net (resqmta-ch2-07v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:39]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 326EF1A6FC0 for ; Thu, 11 Dec 2014 10:34:31 -0800 (PST) Received: from resomta-ch2-18v.sys.comcast.net ([69.252.207.114]) by resqmta-ch2-07v.sys.comcast.net with comcast id SJZ91p00E2Udklx01JaWdp; Thu, 11 Dec 2014 18:34:30 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-18v.sys.comcast.net with comcast id SJaV1p00Y3Ge9ey01JaVQ5; Thu, 11 Dec 2014 18:34:30 +0000 Message-ID: <5489E3B5.9020300@alum.mit.edu> Date: Thu, 11 Dec 2014 13:34:29 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Charles Eckel (eckelcu)" , Christer Holmberg , "bfcpbis@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B1D582373@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D588C28@ESESSMB209.ericsson.se> <54885F09.6010706@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D58E6C7@ESESSMB209.ericsson.se> In-Reply-To: Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1418322870; bh=ody0GRZwlDx1pGLVqm+8xmbQEHgsWOeJ3xpvuRonzFQ=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=eoOjWNFJeM4wVKIAua5dMumf+xq+C1qj9sMh98HbOHEdCrASXB6iFpEdPkbY/0kAJ aecN9fjBienzGTcLwRSmmfIfwgxZEa2KHOv93PFrNr+dpoDD3dJaYFVuVgnf9GC5SO 8gMsq/qIZJmeQReV9N9TalSruPXzn2EpXYXhyl2e5PRW38lzLsKbAHQSPkkIpXZk1M xZMF8+Irmhg3z7UgjH15AQuqiCjDIS1PaduHn5XF/O1gFkqMA1PZl23QJB2YozoGJ1 qcze0iAb8hSW4lbjxHdC4lHJ9C/947VLQLHo65sJk/06k6cvWT4f+7hAXxMtH/B+T+ A8jfpUK2+rjlg== Archived-At: http://mailarchive.ietf.org/arch/msg/bfcpbis/lFCl1rFPWjfbcqWf6Efb0yvSt1A Subject: Re: [bfcpbis] Comments on draft-ietf-bfcpbis-rfc4583bis-10 X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2014 18:34:34 -0000 On 12/11/14 1:27 PM, Charles Eckel (eckelcu) wrote: > (as an individual) > > I agree in general, but specifically in the case of this draft, it should > have been completed long ago and it is very close to being sent to the > IESG now. I do not think it should be used to test the new template. Only > one of its attributes are new and the rest of from rfc4583. Chances are, > there will be some additional changes to the template before 4566bis is > finished, and either 4583bis will need to be updated again or it will > still deviate from the template. Wouldn¡¯t it be more reasonable to use a > new draft defining new SDP attributes as a test vehicle? Given what you say I certainly won't press the issue. While it would be nice, I don't see it as essential. Thanks, Paul > Cheers, > Charles > > On 12/11/14, 3:42 AM, "Christer Holmberg" > wrote: > >> Hi, >> >> In order to figure out whether Paul's suggestion works, someone needs to >> use it - before the SDP-bis draft is published as RFC :) >> >> It's a very small task to change it. I could do it, but I'd like others >> to also try it out, and provide feedback. >> >> Regards, >> >> Christer >> >> -----Original Message----- >> From: bfcpbis [mailto:bfcpbis-bounces@ietf.org] On Behalf Of Paul Kyzivat >> Sent: 10. joulukuuta 2014 16:56 >> To: bfcpbis@ietf.org >> Subject: Re: [bfcpbis] Comments on draft-ietf-bfcpbis-rfc4583bis-10 >> >> I'm here to discuss how I think the attribute declaration updates to >> 4566bis should apply here. >> >> (Note that I haven't been closely following this draft. I noted >> Christer's comments, and then scanned the draft to find relevant >> sections.) >> >> First, the template I have introduced in 4566bis is new, and hasn't been >> thoroughly reviewed. It is good to "debug" it and fine tune it. >> >> Second, I have *some* sympathy for bis drafts in general. It is hard to >> decide how much to change, and what to leave alone. OTOH, I set out >> specifically to improve the mechanism for definition of attributes, and >> did update all the definitions in 4566bis. My goal is to ensure that >> there is clarity in the syntax of attributes, and that developers reading >> those will know what they are expected to do to parse them. >> >> I find that what is in this document now does at least define the syntax >> unambiguously. >> >> OTOH, it does imply that the attribute names it defines should be matched >> in a case-insensitive way, which is contrary to what 4566 says. >> >> I think it would be "nice" if the attribute declarations here were >> updated to the new format - a help in getting on the new path. >> >> My inclination would be to convert to the new format, inline in the >> sections where the attribute syntax is currently defined, and then simply >> cross reference those definitions from the IANA Considerations section. >> >> Thanks, >> Paul >> >> On 12/9/14 6:53 PM, Charles Eckel (eckelcu) wrote: >>> On 12/9/14, 12:17 AM, "Christer Holmberg" >>> >>> wrote: >>> >>>> Hi, >>>> >>>>>> Q1: >>>>>> >>>>>> There is a new "template" for defining SDP attributes. It has been >>>>>> discussed on the MMUSIC list, and Paul K can give more information >>>>>> if needed. >>>>> >>>>> A ptr to that would be helpful. I scanned the MMUSIC list quickly >>>>> but must have missed it. >>>> >>>> Please look at section 6 in >>>> https://tools.ietf.org/id/draft-ietf-mmusic-rfc4566bis-12.txt >>> >>> This section makes consistent use of the following template (using >>> ©øcat©÷ as an example): >>> >>> --- >>> Name: cat >>> >>> Value: cat-value >>> >>> Usage Level: session >>> >>> Charset Dependent: no >>> >>> Syntax: >>> >>> cat-value = category >>> category = byte-string >>> ; Note: syntax is vague because usage is not understood >>> >>> Example: >>> >>> a=cat:foo.bar >>> >>> This attribute gives the dot-separated hierarchical category of the >>> session. This is to enable a receiver to filter unwanted sessions >>> by >>> category. There is no central registry of categories. >>> >>> < >>> >>> I don©öt believe draft-ietf-bfcpbis-rfc4583bis-10 should include such >>> info for each attribute because similar information is already >>> captured in the IANA considerations sections in for the format >>> appropriate for IANA considerations. >>> >>>> >>>> >>>> >>>>>> Q2: >>>>>> >>>>>> Most SDP attributes are defined in their own sections - which is >>>>>> good. >>>>>> But, sometimes the section name contains the name of the attribute, >>>>>> and sometimes not. I think it would be good to be consistent, and >>>>>> always call the section "SDP xxx attribute". >>> >>> The IANA considerations section does this (i.e. SDP attribute name in >>> section title). Sections 4-7 are organized by functionality rather >>> than by SDP attribute. As such, I think the existing names are >>> appropriate. We could add subsections for each attribute within these >>> sections that are named according to the name of the corresponding SDP >>> attribute. That said, I do think such additions would be all that >>> useful. >>> >>>>>> >>>>>> Q3: >>>>> >>>>> There is no dedicated SDP Offer/Answer procedure section (instead, >>>>> each section defining an SDP attribute include a few sentences about >>>>> Offer/Answer). >>>>> >>>>> I think it would be good to have a dedicated SDP Offer/Answer >>>>> procedure section, following the structure in RFC 3264. I've had to >>>>> do that e.g. >>>>> for BUNDLE and SCTP-SDP. >>>>> >>>>> I had a look at >>>>> http://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-negotiation- >>>>> 13 as an example. I see how we could rename and reorganize the >>>>> existing content along these lines. I struggle with this a bit >>>>> because I am comfortable with the existing document structure and my >>>>> familiarity with it make it straightforward for me to understand. >>>>> For a new reader, I think your suggested change will help, so I'm in >>>>> favor of it. >>>> >>>> I took the text from the SCTP-SDP draft (note that the text may still >>>> change), and tried to convert it into BFCP. Some parts are probably >>>> still missing (for example, I realized that I forgot to add text >>>> regarding the SDP 'floorctrl' attribute) , and maybe the BFCP draft >>>> uses different terminology, but feel free to use it as a base: >>>> >>>> -------- >>>> >>>> 9. SDP Offer/Answer Procedures >>>> >>>> 9.1. General >>>> >>>> This section defines the SDP Offer/Answer [RFC3264] procedures for >>>> negotiating and establishing an BFCP connection. >>>> >>>> If the m- line proto value is ' TCP/TLS/BFCP ' or ' UDP/TLS/BFCP >>>> ', each >>>> endpoint MUST provide a certificate fingerprint, using the SDP >>>> 'fingerprint' attribute [RFC4145], if the endpoint supports, and is >>>> willing to use, a cipher suite with an associated certificate. >>>> >>>> The authentication certificates are interpreted and validated as >>>> defined in [RFC4572]. Self-signed certificates can be used >>>> securely, >>>> provided that the integrity of the SDP description is assured as >>>> defined in [RFC4572]. >>>> >>>> NOTE: The procedures apply to a specific m- line describing an BFCP >>>> connection. If an offer or answer contains multiple m- line >>>> describing BFCP connections, the procedures are applied separately >>>> to each m- line. >>>> >>>> 9.2. Generating the Initial SDP Offer >>>> >>>> When the offerer creates an initial offer, the offerer: >>>> >>>> o MUST, if the m- line proto value is 'TCP/BFCP', 'TCP/TLS/BFCP' or >>>> 'UDP/TLS/BFCP', associate an SDP setup attribute [Section X], >>>> with an >>>> 'actpass' value, with the m- line; >>>> >>>> o MUST, if the m- line proto value is 'TCP/BFCP' or 'TCP/TLS/BFCP', >>>> associate an SDP 'connection' attribute [Section 8.4], with a >>>> 'new' value, with the m- line; and >>>> >>>> In addition, if the offerer acts as the floor control server, the >>>> offerer: >>>> >>>> o MUST associate an SDP 'confid' attribute [Section X], with the >>>> m- line; >>>> >>>> o MUST associate an SDP 'userid' attribute [Section X], with the >>>> m- line; >>>> >>>> o MUST associate an SDP 'floorid' attribute [Section X], with the >>>> m- line; and >>>> >>>> o MUST associate an SDP 'label' attribute [Section X], with the >>>> m- line. >>>> >>>> 9.3. Generating the SDP Answer >>>> >>>> When the answerer receives an offer, which contains an m- line >>>> describing a BFCP connection, if the answerer accepts the m- line >>>> it: >>>> >>>> o MUST insert a corresponding m- line in the answer, with an >>>> identical m- line proto value [RFC3264]; and >>>> >>>> o MUST, if the m- line proto value is 'TCP/BFCP', 'TCP/TLS/BFCP' or >>>> 'UDP/TLS/BFCP', associate an SDP setup attribute [Section X], >>>> with an >>>> 'active' or 'passive' value, with the m- line; >>>> >>>> In addition, if the answerer acts as the floor control server, the >>>> answerer: >>>> >>>> o MUST associate an SDP 'confid' attribute [Section X], with the >>>> m- line; >>>> >>>> o MUST associate an SDP 'userid' attribute [Section X], with the >>>> m- line; >>>> >>>> o MUST associate an SDP 'floorid' attribute [Section X], with the >>>> m- line; and >>>> >>>> o MUST associate an SDP 'label' attribute [Section X], with the >>>> m- line. >>>> >>>> Once the answerer has sent the answer, the answerer: >>>> >>>> o MUST, if the answerer is the 'active' endpoint, and if a TCP >>>> connection >>>> associated with the m- line is to be established (or >>>> re-established), >>>> initiate the establishing of the TCP connection; and >>>> >>>> o MUST, if the answerer is the 'active' endpoint, and if an >>>> TLS/DTLS >>>> connection associated with the m- line is to be established (or >>>> re-established), initiate the establishing of the TLS/DTLS >>>> connection >>>> (by sending a ClientHello message). >>>> >>>> If the answerer does not accept the m- line in the offer, it MUST >>>> assign a zero port value to the corresponding m- line in the answer. >>>> In addition, the answerer MUST NOT establish an SCTP association, or >>>> a DTLS connection, associated with the m- line. >>>> >>>> 9.4. Offerer Processing of the SDP Answer >>>> >>>> When the offerer receives an answer, which contains an m- line with >>>> a >>>> non-zero port value, describing a BFCP connection, the offerer: >>>> >>>> o MUST, if the offer is the 'active' endpoint, and if a TCP >>>> connection >>>> associated with the m- line is to be established (or >>>> re-established), >>>> initiate the establishing of the TCP connection; and >>>> >>>> o MUST, if the offerer is the 'active' endpoint, and if an TLS/DTLS >>>> connection associated with the m- line is to be established (or >>>> re-established), initiate the establishing of the TLS/DTLS >>>> connection >>>> (by sending a ClientHello message). >>>> >>>> If the m- line in the answer contains a zero port value, the offerer >>>> MUST NOT establish an TCP connection, or a TLS/DTLS connection, >>>> associated with the m- line. >>>> >>>> 9.5. Modifying the Session >>>> >>>> When an offerer sends an updated offer, in order to modify a >>>> previously established BFCP connection, it follows the procedures in >>>> Section 9.2, with the following exceptions: >>>> >>>> o If the BFCP connection is carried on top of TCP, and unless the >>>> offerer wants to re-establish an existing TCP connection, the >>>> offerer MUST associate an SDP connection attribute, with >>>> an 'existing' value, with the m- line; and >>>> >>>> o If the offerer wants to disable a previously established BFCP >>>> connection, it MUST assign a zero port value to the m- line >>>> associated with the BFCP connection, following the procedures in >>>> [RFC3264]. >>>> >>>> >>>> --------------- >>> >>> That looks pretty straightforward and clear to me. Adding the >>> floorctrl attribute will complicate it some, but I think its still >>> manageable. >>> >>>> >>>> Q3b: >>>> >>>> The following sentence in 4583bis is a little confusing: >>>> >>>> "If the 'floorctrl' attribute is not used in an offer/answer >>>> exchange, >>>> by default the offerer and the answerer will act as a floor control >>>> client and as a floor control server, respectively." >>>> >>>> Does this mean that the role may change every time an endpoint - for >>>> whatever reason - sends an updated offer? >>> >>> Yes. This was inherited from RFC 4583, and it is the consequence of >>> the lenient normative language immediately before it. >>> >>> "Endpoints that use the offer/answer model to establish BFCP >>> connections MUST support the 'floorctrl' attribute. A floor control >>> server acting as an offerer or as an answerer SHOULD include this >>> attribute in its session descriptions.©÷ >>> >>>> >>>> >>>> >>>> >>>>>> Q4: >>>>>> >>>>>> For DTLS and Offer/Answer, there are a few references to RFC 5763 >>>>>> here and there. But, I think it would be good to have explicit text >>>>>> on the Offer/Answer considerations regarding DTLS - especially >>>>>> since there have been quite a bit of discussions about that lately. >>>>> >>>>> Are you suggesting a copy/paste of the relevant text from RFC 5763 >>>>> in additional to a reference, or is there an calcification of what >>>>> is provided in RFC 5763 that you added for SCTP that would be >>>>> helpful for this draft? >>>> >>>> In the SCTP-SDP draft I have the following text, which is aligned >>>> with RFC 5763, but provides a little more details. >>>> >>>> You could probably use the text just by replacing the proto field >>>> values with the ones used for BFCP. >>>> >>>> ------------- >>>> >>>> 8.3.3. TLS Role Determination >>>> >>>> If the m- line proto value is 'SCTP/DTLS' or 'DTLS/SCTP', the >>>> 'active/passive' status is used to determine the TLS roles. >>>> Following the procedures in [RFC4572], the 'active' endpoint will >>>> take the TLS client role. >>>> >>>> Once a DTLS connection has been established, if the 'active/passive' >>>> status of the endpoints change during a session, a new DTLS >>>> connection MUST be established. Therefore, endpoints SHOULD NOT >>>> change the 'active/passive' status in subsequent offers and answers, >>>> unless they want to establish a new DTLS connection. >>>> >>>> If the transport parameters or the key fingerprints change, the >>>> endpoints MUST establish a new DTLS connection. In such case the >>>> 'active/passive' status of the endpoints will again be determined >>>> following the procedures in [RFC4145], and the new status will be >>>> used to determine the TLS roles associated with the new DTLS >>>> connection. >>>> >>>> NOTE: The procedure above is identical to the one defined for SRTP- >>>> DTLS in [RFC5763]. >>>> >>>> NOTE: A new DTLS connection needs to be established if the transport >>>> parameters or the key fingerprints change. >>>> >>>> ------------ >>> >>> I am okay with this. Its a nice summary. Our previous reference to RFC >>> 5763, section 5, did not address session modification. This fixes that. >>> >>>> >>>>> Q5: >>>>> >>>>> The draft does not define how to use BFCP within a BUNDLE group. >>>>> That is fine, but I think it would be good to explicitly indicate >>>>> that. >>>>> >>>>> Yes. I'm thinking we need to point to >>>>> https://tools.ietf.org/html/draft-ietf-mmusic-sdp-mux-attributes-05# >>>>> page- >>>>> 28 for attributes defined in RFC 4583, and define the mux category >>>>> for new attributes defined within this draft. >>>> >>>> Defining the mux category is one thing. >>>> >>>> But, if you want to define usage of BFCP within a BUNDLE group, you >>>> also need to describe how BFCP is identified when bundled with other >>>> protocols (RTP etc). >>> >>> I think this goes beyond what is needed for this draft. If someone >>> wants to use BFCP with BUNDLE, they can define that usage. Sounds >>> reasonable? >>> >>> Cheers, >>> Charles >>> >>>> >>>> Regards, >>>> >>>> Christer >>>> >>> >>> _______________________________________________ >>> bfcpbis mailing list >>> bfcpbis@ietf.org >>> https://www.ietf.org/mailman/listinfo/bfcpbis >>> >> >> _______________________________________________ >> bfcpbis mailing list >> bfcpbis@ietf.org >> https://www.ietf.org/mailman/listinfo/bfcpbis >> >> _______________________________________________ >> bfcpbis mailing list >> bfcpbis@ietf.org >> https://www.ietf.org/mailman/listinfo/bfcpbis > From nobody Thu Dec 11 10:38:20 2014 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8173F1A8865 for ; Thu, 11 Dec 2014 10:38:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K-R0fYVeZnOq for ; Thu, 11 Dec 2014 10:38:05 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D1251A87E2 for ; Thu, 11 Dec 2014 10:38:04 -0800 (PST) X-AuditID: c1b4fb30-f79d66d00000744c-e5-5489e48a7ef7 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 7B.37.29772.A84E9845; Thu, 11 Dec 2014 19:38:02 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.189]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0195.001; Thu, 11 Dec 2014 19:38:02 +0100 From: Christer Holmberg To: Paul Kyzivat , "Charles Eckel (eckelcu)" , "bfcpbis@ietf.org" Thread-Topic: [bfcpbis] Comments on draft-ietf-bfcpbis-rfc4583bis-10 Thread-Index: AdARgmEI5ESuyJkDTsuliRtAbu7OYQBjlDwAABy8dMAAHb3ZAAAhnGGAAC2RQ2AADB4WgAAAO0+AAAIqT+A= Date: Thu, 11 Dec 2014 18:38:02 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D58F83A@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D582373@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D588C28@ESESSMB209.ericsson.se> <54885F09.6010706@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D58E6C7@ESESSMB209.ericsson.se> <5489E3B5.9020300@alum.mit.edu> In-Reply-To: <5489E3B5.9020300@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNLMWRmVeSWpSXmKPExsUyM+JvjW7Xk84Qg70L1C3+rTvKZLFp1hc2 ixUbDrA6MHv8ff+ByWPK742sHkuW/GQKYI7isklJzcksSy3St0vgyrj2TrPgXTdjxYOVF1kb GE/mdjFyckgImEgsejaFFcIWk7hwbz1bFyMXh5DAEUaJD7u/AyU4gJwljBLTi0BMNgELie5/ 2iAlIgINjBL/rqxiBOkVFnCW+HL9FROILSLgIvH4029mCDtJon3PX7D5LAKqEmseTwWzeQV8 JS7cusUOsauFWWLb/MVsIAlOAR2JOwu/gg1iBDro+6k1YDazgLjErSfzmSAOFZBYsuc8M4Qt KvHy8T+oB5Qk1h7ezgJRrydxY+oUNghbW2LZwtfMEIsFJU7OfMIygVF0FpKxs5C0zELSMgtJ ywJGllWMosWpxUm56UZGeqlFmcnFxfl5enmpJZsYgbFzcMtvgx2ML587HmIU4GBU4uE1qOwM EWJNLCuuzD3EKM3BoiTOu/DcvGAhgfTEktTs1NSC1KL4otKc1OJDjEwcnFINjBnT5/Zd+tIl GN6WdFF8z4EJ+2esvi5ssuyg1JYaz1u5sSnTr72d8Ko5+OmmQlVnz6b1V4+tSj43aad8aJc7 V8SR+18TpOI+fmeVb3PndtX/xl9Xuf2X1x/PTQvKt+3m8ej666aY6Oe6l6k964/mDHNdNv9v GxmeLRAoX5/7onw/n8DMleGrzyixFGckGmoxFxUnAgA4zCRGfgIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/bfcpbis/3IBalNsS4bdWyN26VjicopF6Sko Subject: Re: [bfcpbis] Comments on draft-ietf-bfcpbis-rfc4583bis-10 X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2014 18:38:13 -0000 Hi, >> I agree in general, but specifically in the case of this draft, it=20 >> should have been completed long ago and it is very close to being sent=20 >> to the IESG now. I do not think it should be used to test the new=20 >> template. Only one of its attributes are new and the rest of from=20 >> rfc4583. Chances are, there will be some additional changes to the=20 >> template before 4566bis is finished, and either 4583bis will need to=20 >> be updated again or it will still deviate from the template. Wouldn't=20 >> it be more reasonable to use a new draft defining new SDP attributes as = a test vehicle? > > Given what you say I certainly won't press the issue. > While it would be nice, I don't see it as essential. I'm fine having the current structure too :) (However, as I indicated in another comment, I still think the attributes s= hould be defined in dedicated (sub-) sections.) Regards Christer > On 12/11/14, 3:42 AM, "Christer Holmberg"=20 > > wrote: >=20 >> Hi, >> >> In order to figure out whether Paul's suggestion works, someone needs=20 >> to use it - before the SDP-bis draft is published as RFC :) >> >> It's a very small task to change it. I could do it, but I'd like=20 >> others to also try it out, and provide feedback. >> >> Regards, >> >> Christer >> >> -----Original Message----- >> From: bfcpbis [mailto:bfcpbis-bounces@ietf.org] On Behalf Of Paul=20 >> Kyzivat >> Sent: 10. joulukuuta 2014 16:56 >> To: bfcpbis@ietf.org >> Subject: Re: [bfcpbis] Comments on draft-ietf-bfcpbis-rfc4583bis-10 >> >> I'm here to discuss how I think the attribute declaration updates to=20 >> 4566bis should apply here. >> >> (Note that I haven't been closely following this draft. I noted=20 >> Christer's comments, and then scanned the draft to find relevant >> sections.) >> >> First, the template I have introduced in 4566bis is new, and hasn't=20 >> been thoroughly reviewed. It is good to "debug" it and fine tune it. >> >> Second, I have *some* sympathy for bis drafts in general. It is hard=20 >> to decide how much to change, and what to leave alone. OTOH, I set=20 >> out specifically to improve the mechanism for definition of=20 >> attributes, and did update all the definitions in 4566bis. My goal is=20 >> to ensure that there is clarity in the syntax of attributes, and that=20 >> developers reading those will know what they are expected to do to parse= them. >> >> I find that what is in this document now does at least define the=20 >> syntax unambiguously. >> >> OTOH, it does imply that the attribute names it defines should be=20 >> matched in a case-insensitive way, which is contrary to what 4566 says. >> >> I think it would be "nice" if the attribute declarations here were=20 >> updated to the new format - a help in getting on the new path. >> >> My inclination would be to convert to the new format, inline in the=20 >> sections where the attribute syntax is currently defined, and then=20 >> simply cross reference those definitions from the IANA Considerations se= ction. >> >> Thanks, >> Paul >> >> On 12/9/14 6:53 PM, Charles Eckel (eckelcu) wrote: >>> On 12/9/14, 12:17 AM, "Christer Holmberg" >>> >>> wrote: >>> >>>> Hi, >>>> >>>>>> Q1: >>>>>> >>>>>> There is a new "template" for defining SDP attributes. It has=20 >>>>>> been discussed on the MMUSIC list, and Paul K can give more=20 >>>>>> information if needed. >>>>> >>>>> A ptr to that would be helpful. I scanned the MMUSIC list quickly=20 >>>>> but must have missed it. >>>> >>>> Please look at section 6 in >>>> https://tools.ietf.org/id/draft-ietf-mmusic-rfc4566bis-12.txt >>> >>> This section makes consistent use of the following template (using=20 >>> =B3cat=B2 as an example): >>> >>> --- >>> Name: cat >>> >>> Value: cat-value >>> >>> Usage Level: session >>> >>> Charset Dependent: no >>> >>> Syntax: >>> >>> cat-value =3D category >>> category =3D byte-string >>> ; Note: syntax is vague because usage is not understood >>> >>> Example: >>> >>> a=3Dcat:foo.bar >>> >>> This attribute gives the dot-separated hierarchical category of th= e >>> session. This is to enable a receiver to filter unwanted=20 >>> sessions by >>> category. There is no central registry of categories. >>> >>> < >>> >>> I don=B9t believe draft-ietf-bfcpbis-rfc4583bis-10 should include such= =20 >>> info for each attribute because similar information is already=20 >>> captured in the IANA considerations sections in for the format=20 >>> appropriate for IANA considerations. >>> >>>> >>>> >>>> >>>>>> Q2: >>>>>> >>>>>> Most SDP attributes are defined in their own sections - which is=20 >>>>>> good. >>>>>> But, sometimes the section name contains the name of the=20 >>>>>> attribute, and sometimes not. I think it would be good to be=20 >>>>>> consistent, and always call the section "SDP xxx attribute". >>> >>> The IANA considerations section does this (i.e. SDP attribute name=20 >>> in section title). Sections 4-7 are organized by functionality=20 >>> rather than by SDP attribute. As such, I think the existing names=20 >>> are appropriate. We could add subsections for each attribute within=20 >>> these sections that are named according to the name of the=20 >>> corresponding SDP attribute. That said, I do think such additions=20 >>> would be all that useful. >>> >>>>>> >>>>>> Q3: >>>>> >>>>> There is no dedicated SDP Offer/Answer procedure section (instead,=20 >>>>> each section defining an SDP attribute include a few sentences=20 >>>>> about Offer/Answer). >>>>> >>>>> I think it would be good to have a dedicated SDP Offer/Answer=20 >>>>> procedure section, following the structure in RFC 3264. I've had=20 >>>>> to do that e.g. >>>>> for BUNDLE and SCTP-SDP. >>>>> >>>>> I had a look at >>>>> http://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-negotiatio >>>>> n- >>>>> 13 as an example. I see how we could rename and reorganize the=20 >>>>> existing content along these lines. I struggle with this a bit=20 >>>>> because I am comfortable with the existing document structure and=20 >>>>> my familiarity with it make it straightforward for me to understand. >>>>> For a new reader, I think your suggested change will help, so I'm=20 >>>>> in favor of it. >>>> >>>> I took the text from the SCTP-SDP draft (note that the text may=20 >>>> still change), and tried to convert it into BFCP. Some parts are=20 >>>> probably still missing (for example, I realized that I forgot to=20 >>>> add text regarding the SDP 'floorctrl' attribute) , and maybe the=20 >>>> BFCP draft uses different terminology, but feel free to use it as a ba= se: >>>> >>>> -------- >>>> >>>> 9. SDP Offer/Answer Procedures >>>> >>>> 9.1. General >>>> >>>> This section defines the SDP Offer/Answer [RFC3264] procedures for >>>> negotiating and establishing an BFCP connection. >>>> >>>> If the m- line proto value is ' TCP/TLS/BFCP ' or '=20 >>>> UDP/TLS/BFCP ', each >>>> endpoint MUST provide a certificate fingerprint, using the SDP >>>> 'fingerprint' attribute [RFC4145], if the endpoint supports, and i= s >>>> willing to use, a cipher suite with an associated certificate. >>>> >>>> The authentication certificates are interpreted and validated as >>>> defined in [RFC4572]. Self-signed certificates can be used=20 >>>> securely, >>>> provided that the integrity of the SDP description is assured as >>>> defined in [RFC4572]. >>>> >>>> NOTE: The procedures apply to a specific m- line describing an BFC= P >>>> connection. If an offer or answer contains multiple m- line >>>> describing BFCP connections, the procedures are applied separately >>>> to each m- line. >>>> >>>> 9.2. Generating the Initial SDP Offer >>>> >>>> When the offerer creates an initial offer, the offerer: >>>> >>>> o MUST, if the m- line proto value is 'TCP/BFCP', 'TCP/TLS/BFCP' = or >>>> 'UDP/TLS/BFCP', associate an SDP setup attribute [Section=20 >>>> X], with an >>>> 'actpass' value, with the m- line; >>>> >>>> o MUST, if the m- line proto value is 'TCP/BFCP' or 'TCP/TLS/BFCP= ', >>>> associate an SDP 'connection' attribute [Section 8.4], with a >>>> 'new' value, with the m- line; and >>>> >>>> In addition, if the offerer acts as the floor control server,=20 >>>> the >>>> offerer: >>>> >>>> o MUST associate an SDP 'confid' attribute [Section X], with=20 >>>> the >>>> m- line; >>>> >>>> o MUST associate an SDP 'userid' attribute [Section X], with=20 >>>> the >>>> m- line; >>>> >>>> o MUST associate an SDP 'floorid' attribute [Section X], with=20 >>>> the >>>> m- line; and >>>> >>>> o MUST associate an SDP 'label' attribute [Section X], with=20 >>>> the >>>> m- line. >>>> >>>> 9.3. Generating the SDP Answer >>>> >>>> When the answerer receives an offer, which contains an m- line >>>> describing a BFCP connection, if the answerer accepts the m- line >>>> it: >>>> >>>> o MUST insert a corresponding m- line in the answer, with an >>>> identical m- line proto value [RFC3264]; and >>>> >>>> o MUST, if the m- line proto value is 'TCP/BFCP', 'TCP/TLS/BFCP' = or >>>> 'UDP/TLS/BFCP', associate an SDP setup attribute [Section=20 >>>> X], with an >>>> 'active' or 'passive' value, with the m- line; >>>> >>>> In addition, if the answerer acts as the floor control server,=20 >>>> the >>>> answerer: >>>> >>>> o MUST associate an SDP 'confid' attribute [Section X], with=20 >>>> the >>>> m- line; >>>> >>>> o MUST associate an SDP 'userid' attribute [Section X], with=20 >>>> the >>>> m- line; >>>> >>>> o MUST associate an SDP 'floorid' attribute [Section X], with=20 >>>> the >>>> m- line; and >>>> >>>> o MUST associate an SDP 'label' attribute [Section X], with=20 >>>> the >>>> m- line. >>>> >>>> Once the answerer has sent the answer, the answerer: >>>> >>>> o MUST, if the answerer is the 'active' endpoint, and if a TCP=20 >>>> connection >>>> associated with the m- line is to be established (or=20 >>>> re-established), >>>> initiate the establishing of the TCP connection; and >>>> >>>> o MUST, if the answerer is the 'active' endpoint, and if an=20 >>>> TLS/DTLS >>>> connection associated with the m- line is to be established (or >>>> re-established), initiate the establishing of the TLS/DTLS=20 >>>> connection >>>> (by sending a ClientHello message). >>>> >>>> If the answerer does not accept the m- line in the offer, it MUST >>>> assign a zero port value to the corresponding m- line in the answe= r. >>>> In addition, the answerer MUST NOT establish an SCTP association, = or >>>> a DTLS connection, associated with the m- line. >>>> >>>> 9.4. Offerer Processing of the SDP Answer >>>> >>>> When the offerer receives an answer, which contains an m- line=20 >>>> with a >>>> non-zero port value, describing a BFCP connection, the offerer: >>>> >>>> o MUST, if the offer is the 'active' endpoint, and if a TCP=20 >>>> connection >>>> associated with the m- line is to be established (or=20 >>>> re-established), >>>> initiate the establishing of the TCP connection; and >>>> >>>> o MUST, if the offerer is the 'active' endpoint, and if an TLS/DT= LS >>>> connection associated with the m- line is to be established (or >>>> re-established), initiate the establishing of the TLS/DTLS=20 >>>> connection >>>> (by sending a ClientHello message). >>>> >>>> If the m- line in the answer contains a zero port value, the offer= er >>>> MUST NOT establish an TCP connection, or a TLS/DTLS connection, >>>> associated with the m- line. >>>> >>>> 9.5. Modifying the Session >>>> >>>> When an offerer sends an updated offer, in order to modify a >>>> previously established BFCP connection, it follows the procedures = in >>>> Section 9.2, with the following exceptions: >>>> >>>> o If the BFCP connection is carried on top of TCP, and unless the >>>> offerer wants to re-establish an existing TCP connection, the >>>> offerer MUST associate an SDP connection attribute, with >>>> an 'existing' value, with the m- line; and >>>> >>>> o If the offerer wants to disable a previously established BFCP >>>> connection, it MUST assign a zero port value to the m- line >>>> associated with the BFCP connection, following the procedures i= n >>>> [RFC3264]. >>>> >>>> >>>> --------------- >>> >>> That looks pretty straightforward and clear to me. Adding the=20 >>> floorctrl attribute will complicate it some, but I think its still=20 >>> manageable. >>> >>>> >>>> Q3b: >>>> >>>> The following sentence in 4583bis is a little confusing: >>>> >>>> "If the 'floorctrl' attribute is not used in an offer/answer=20 >>>> exchange, >>>> by default the offerer and the answerer will act as a floor contro= l >>>> client and as a floor control server, respectively." >>>> >>>> Does this mean that the role may change every time an endpoint -=20 >>>> for whatever reason - sends an updated offer? >>> >>> Yes. This was inherited from RFC 4583, and it is the consequence of=20 >>> the lenient normative language immediately before it. >>> >>> "Endpoints that use the offer/answer model to establish BFCP >>> connections MUST support the 'floorctrl' attribute. A floor control >>> server acting as an offerer or as an answerer SHOULD include this >>> attribute in its session descriptions.=B2 >>> >>>> >>>> >>>> >>>> >>>>>> Q4: >>>>>> >>>>>> For DTLS and Offer/Answer, there are a few references to RFC 5763=20 >>>>>> here and there. But, I think it would be good to have explicit=20 >>>>>> text on the Offer/Answer considerations regarding DTLS -=20 >>>>>> especially since there have been quite a bit of discussions about th= at lately. >>>>> >>>>> Are you suggesting a copy/paste of the relevant text from RFC 5763=20 >>>>> in additional to a reference, or is there an calcification of what=20 >>>>> is provided in RFC 5763 that you added for SCTP that would be=20 >>>>> helpful for this draft? >>>> >>>> In the SCTP-SDP draft I have the following text, which is aligned=20 >>>> with RFC 5763, but provides a little more details. >>>> >>>> You could probably use the text just by replacing the proto field=20 >>>> values with the ones used for BFCP. >>>> >>>> ------------- >>>> >>>> 8.3.3. TLS Role Determination >>>> >>>> If the m- line proto value is 'SCTP/DTLS' or 'DTLS/SCTP', the >>>> 'active/passive' status is used to determine the TLS roles. >>>> Following the procedures in [RFC4572], the 'active' endpoint will >>>> take the TLS client role. >>>> >>>> Once a DTLS connection has been established, if the 'active/passiv= e' >>>> status of the endpoints change during a session, a new DTLS >>>> connection MUST be established. Therefore, endpoints SHOULD NOT >>>> change the 'active/passive' status in subsequent offers and answer= s, >>>> unless they want to establish a new DTLS connection. >>>> >>>> If the transport parameters or the key fingerprints change, the >>>> endpoints MUST establish a new DTLS connection. In such case the >>>> 'active/passive' status of the endpoints will again be determined >>>> following the procedures in [RFC4145], and the new status will be >>>> used to determine the TLS roles associated with the new DTLS >>>> connection. >>>> >>>> NOTE: The procedure above is identical to the one defined for SRTP= - >>>> DTLS in [RFC5763]. >>>> >>>> NOTE: A new DTLS connection needs to be established if the transpo= rt >>>> parameters or the key fingerprints change. >>>> >>>> ------------ >>> >>> I am okay with this. Its a nice summary. Our previous reference to=20 >>> RFC 5763, section 5, did not address session modification. This fixes t= hat. >>> >>>> >>>>> Q5: >>>>> >>>>> The draft does not define how to use BFCP within a BUNDLE group. >>>>> That is fine, but I think it would be good to explicitly indicate=20 >>>>> that. >>>>> >>>>> Yes. I'm thinking we need to point to=20 >>>>> https://tools.ietf.org/html/draft-ietf-mmusic-sdp-mux-attributes-0 >>>>> 5# >>>>> page- >>>>> 28 for attributes defined in RFC 4583, and define the mux=20 >>>>> category for new attributes defined within this draft. >>>> >>>> Defining the mux category is one thing. >>>> >>>> But, if you want to define usage of BFCP within a BUNDLE group, you=20 >>>> also need to describe how BFCP is identified when bundled with=20 >>>> other protocols (RTP etc). >>> >>> I think this goes beyond what is needed for this draft. If someone=20 >>> wants to use BFCP with BUNDLE, they can define that usage. Sounds=20 >>> reasonable? >>> >>> Cheers, >>> Charles >>> >>>> >>>> Regards, >>>> >>>> Christer >>>> >>> >>> _______________________________________________ >>> bfcpbis mailing list >>> bfcpbis@ietf.org >>> https://www.ietf.org/mailman/listinfo/bfcpbis >>> >> >> _______________________________________________ >> bfcpbis mailing list >> bfcpbis@ietf.org >> https://www.ietf.org/mailman/listinfo/bfcpbis >> >> _______________________________________________ >> bfcpbis mailing list >> bfcpbis@ietf.org >> https://www.ietf.org/mailman/listinfo/bfcpbis >=20 From nobody Thu Dec 11 10:50:42 2014 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0CC01A8822 for ; Thu, 11 Dec 2014 10:50:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2SJoLeK4b5Wz for ; Thu, 11 Dec 2014 10:50:27 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A37441A1A31 for ; Thu, 11 Dec 2014 10:50:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25022; q=dns/txt; s=iport; t=1418323827; x=1419533427; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=PkeX5lYt0eoplsBhkzXpyFC0b+Mpqol/S190TU5yshM=; b=bsPKw0bBUMTKkiAkglLj3xJdkDJO257nBO8EDCAkgvGssOhqzqzH6Nqu WQ4kGkLIe9bnYh5O5ZUN6NmpXd8iJfkmKoYKwPjw01YgozeSPSDS9P3xo H52Z7tSUT4EH19f9xqYD+kk92+jFP4jlF1mbSggjvARIji8GdPiGe6NM/ I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak0HAFbkiVStJA2K/2dsb2JhbABXAg6CeFJYBIMBwmcKhSRKAhyBARYBAQEBAX2EDAEBAQQBAQExMwcXBAIBCBEEAQEBBBIRBQICJQsUCQgCBAESiCwNpSecVQaWPAEBAQEBAQEBAQEBAQEBAQEBAQEBAReBG44kGCIGDAuCRYFHBYUdhw2BVYM+gX6DM4EMMIIth0KCUYM3IoMvPW4BgQQHFwYcfgEBAQ X-IronPort-AV: E=Sophos;i="5.07,559,1413244800"; d="scan'208";a="379598020" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-4.cisco.com with ESMTP; 11 Dec 2014 18:50:26 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id sBBIoQJv009924 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 11 Dec 2014 18:50:26 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.252]) by xhc-rcd-x04.cisco.com ([::1]) with mapi id 14.03.0195.001; Thu, 11 Dec 2014 12:50:26 -0600 From: "Charles Eckel (eckelcu)" To: Christer Holmberg , Paul Kyzivat , "bfcpbis@ietf.org" Thread-Topic: [bfcpbis] Comments on draft-ietf-bfcpbis-rfc4583bis-10 Thread-Index: AdARgmEI5ESuyJkDTsuliRtAbu7OYQBjlDwAABy8dMAAHb3ZAAAwR3iAACuIbgD//+sbgIAAh/aAgAAA/gD//31agA== Date: Thu, 11 Dec 2014 18:50:25 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D582373@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D588C28@ESESSMB209.ericsson.se> <54885F09.6010706@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D58E6C7@ESESSMB209.ericsson.se> <5489E3B5.9020300@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D58F83A@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D58F83A@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.24.104.128] Content-Type: text/plain; charset="euc-kr" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/bfcpbis/ZQMGhBF7XmSZ9C3g0AGuXXH_Lig Subject: Re: [bfcpbis] Comments on draft-ietf-bfcpbis-rfc4583bis-10 X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2014 18:50:40 -0000 T24gMTIvMTEvMTQsIDEwOjM4IEFNLCAiQ2hyaXN0ZXIgSG9sbWJlcmciDQo8Y2hyaXN0ZXIuaG9s bWJlcmdAZXJpY3Nzb24uY29tPiB3cm90ZToNCg0KPkhpLA0KPg0KPj4+IEkgYWdyZWUgaW4gZ2Vu ZXJhbCwgYnV0IHNwZWNpZmljYWxseSBpbiB0aGUgY2FzZSBvZiB0aGlzIGRyYWZ0LCBpdA0KPj4+ IHNob3VsZCBoYXZlIGJlZW4gY29tcGxldGVkIGxvbmcgYWdvIGFuZCBpdCBpcyB2ZXJ5IGNsb3Nl IHRvIGJlaW5nIHNlbnQNCj4+PiB0byB0aGUgSUVTRyBub3cuIEkgZG8gbm90IHRoaW5rIGl0IHNo b3VsZCBiZSB1c2VkIHRvIHRlc3QgdGhlIG5ldw0KPj4+IHRlbXBsYXRlLiBPbmx5IG9uZSBvZiBp dHMgYXR0cmlidXRlcyBhcmUgbmV3IGFuZCB0aGUgcmVzdCBvZiBmcm9tDQo+Pj4gcmZjNDU4My4g Q2hhbmNlcyBhcmUsIHRoZXJlIHdpbGwgYmUgc29tZSBhZGRpdGlvbmFsIGNoYW5nZXMgdG8gdGhl DQo+Pj4gdGVtcGxhdGUgYmVmb3JlIDQ1NjZiaXMgaXMgZmluaXNoZWQsIGFuZCBlaXRoZXIgNDU4 M2JpcyB3aWxsIG5lZWQgdG8NCj4+PiBiZSB1cGRhdGVkIGFnYWluIG9yIGl0IHdpbGwgc3RpbGwg ZGV2aWF0ZSBmcm9tIHRoZSB0ZW1wbGF0ZS4gV291bGRuJ3QNCj4+PiBpdCBiZSBtb3JlIHJlYXNv bmFibGUgdG8gdXNlIGEgbmV3IGRyYWZ0IGRlZmluaW5nIG5ldyBTRFAgYXR0cmlidXRlcw0KPj4+ YXMgYSB0ZXN0IHZlaGljbGU/DQo+Pg0KPj4gR2l2ZW4gd2hhdCB5b3Ugc2F5IEkgY2VydGFpbmx5 IHdvbid0IHByZXNzIHRoZSBpc3N1ZS4NCj4+IFdoaWxlIGl0IHdvdWxkIGJlIG5pY2UsIEkgZG9u J3Qgc2VlIGl0IGFzIGVzc2VudGlhbC4NCj4NCj5JJ20gZmluZSBoYXZpbmcgdGhlIGN1cnJlbnQg c3RydWN0dXJlIHRvbyA6KQ0KPg0KPihIb3dldmVyLCBhcyBJIGluZGljYXRlZCBpbiBhbm90aGVy IGNvbW1lbnQsIEkgc3RpbGwgdGhpbmsgdGhlIGF0dHJpYnV0ZXMNCj5zaG91bGQgYmUgZGVmaW5l ZCBpbiBkZWRpY2F0ZWQgKHN1Yi0pIHNlY3Rpb25zLikNCg0KU291bmRzIGdvb2QhDQoNCkNoZWVy cywNCkNoYXJsZXMNCg0KDQo+DQo+UmVnYXJkcw0KPg0KPkNocmlzdGVyDQo+DQo+DQo+DQo+DQo+ PiBPbiAxMi8xMS8xNCwgMzo0MiBBTSwgIkNocmlzdGVyIEhvbG1iZXJnIg0KPj4gPGNocmlzdGVy LmhvbG1iZXJnQGVyaWNzc29uLmNvbT4NCj4+IHdyb3RlOg0KPj4gDQo+Pj4gSGksDQo+Pj4NCj4+ PiBJbiBvcmRlciB0byBmaWd1cmUgb3V0IHdoZXRoZXIgUGF1bCdzIHN1Z2dlc3Rpb24gd29ya3Ms IHNvbWVvbmUgbmVlZHMNCj4+PiB0byB1c2UgaXQgLSBiZWZvcmUgdGhlIFNEUC1iaXMgZHJhZnQg aXMgcHVibGlzaGVkIGFzIFJGQyA6KQ0KPj4+DQo+Pj4gSXQncyBhIHZlcnkgc21hbGwgdGFzayB0 byBjaGFuZ2UgaXQuIEkgY291bGQgZG8gaXQsIGJ1dCBJJ2QgbGlrZQ0KPj4+IG90aGVycyB0byBh bHNvIHRyeSBpdCBvdXQsIGFuZCBwcm92aWRlIGZlZWRiYWNrLg0KPj4+DQo+Pj4gUmVnYXJkcywN Cj4+Pg0KPj4+IENocmlzdGVyDQo+Pj4NCj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K Pj4+IEZyb206IGJmY3BiaXMgW21haWx0bzpiZmNwYmlzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl aGFsZiBPZiBQYXVsDQo+Pj4gS3l6aXZhdA0KPj4+IFNlbnQ6IDEwLiBqb3VsdWt1dXRhIDIwMTQg MTY6NTYNCj4+PiBUbzogYmZjcGJpc0BpZXRmLm9yZw0KPj4+IFN1YmplY3Q6IFJlOiBbYmZjcGJp c10gQ29tbWVudHMgb24gZHJhZnQtaWV0Zi1iZmNwYmlzLXJmYzQ1ODNiaXMtMTANCj4+Pg0KPj4+ IEknbSBoZXJlIHRvIGRpc2N1c3MgaG93IEkgdGhpbmsgdGhlIGF0dHJpYnV0ZSBkZWNsYXJhdGlv biB1cGRhdGVzIHRvDQo+Pj4gNDU2NmJpcyBzaG91bGQgYXBwbHkgaGVyZS4NCj4+Pg0KPj4+IChO b3RlIHRoYXQgSSBoYXZlbid0IGJlZW4gY2xvc2VseSBmb2xsb3dpbmcgdGhpcyBkcmFmdC4gSSBu b3RlZA0KPj4+IENocmlzdGVyJ3MgY29tbWVudHMsIGFuZCB0aGVuIHNjYW5uZWQgdGhlIGRyYWZ0 IHRvIGZpbmQgcmVsZXZhbnQNCj4+PiBzZWN0aW9ucy4pDQo+Pj4NCj4+PiBGaXJzdCwgdGhlIHRl bXBsYXRlIEkgaGF2ZSBpbnRyb2R1Y2VkIGluIDQ1NjZiaXMgaXMgbmV3LCBhbmQgaGFzbid0DQo+ Pj4gYmVlbiB0aG9yb3VnaGx5IHJldmlld2VkLiBJdCBpcyBnb29kIHRvICJkZWJ1ZyIgaXQgYW5k IGZpbmUgdHVuZSBpdC4NCj4+Pg0KPj4+IFNlY29uZCwgSSBoYXZlICpzb21lKiBzeW1wYXRoeSBm b3IgYmlzIGRyYWZ0cyBpbiBnZW5lcmFsLiBJdCBpcyBoYXJkDQo+Pj4gdG8gZGVjaWRlIGhvdyBt dWNoIHRvIGNoYW5nZSwgYW5kIHdoYXQgdG8gbGVhdmUgYWxvbmUuIE9UT0gsIEkgc2V0DQo+Pj4g b3V0IHNwZWNpZmljYWxseSB0byBpbXByb3ZlIHRoZSBtZWNoYW5pc20gZm9yIGRlZmluaXRpb24g b2YNCj4+PiBhdHRyaWJ1dGVzLCBhbmQgZGlkIHVwZGF0ZSBhbGwgdGhlIGRlZmluaXRpb25zIGlu IDQ1NjZiaXMuIE15IGdvYWwgaXMNCj4+PiB0byBlbnN1cmUgdGhhdCB0aGVyZSBpcyBjbGFyaXR5 IGluIHRoZSBzeW50YXggb2YgYXR0cmlidXRlcywgYW5kIHRoYXQNCj4+PiBkZXZlbG9wZXJzIHJl YWRpbmcgdGhvc2Ugd2lsbCBrbm93IHdoYXQgdGhleSBhcmUgZXhwZWN0ZWQgdG8gZG8gdG8NCj4+ PnBhcnNlIHRoZW0uDQo+Pj4NCj4+PiBJIGZpbmQgdGhhdCB3aGF0IGlzIGluIHRoaXMgZG9jdW1l bnQgbm93IGRvZXMgYXQgbGVhc3QgZGVmaW5lIHRoZQ0KPj4+IHN5bnRheCB1bmFtYmlndW91c2x5 Lg0KPj4+DQo+Pj4gT1RPSCwgaXQgZG9lcyBpbXBseSB0aGF0IHRoZSBhdHRyaWJ1dGUgbmFtZXMg aXQgZGVmaW5lcyBzaG91bGQgYmUNCj4+PiBtYXRjaGVkIGluIGEgY2FzZS1pbnNlbnNpdGl2ZSB3 YXksIHdoaWNoIGlzIGNvbnRyYXJ5IHRvIHdoYXQgNDU2NiBzYXlzLg0KPj4+DQo+Pj4gSSB0aGlu ayBpdCB3b3VsZCBiZSAibmljZSIgaWYgdGhlIGF0dHJpYnV0ZSBkZWNsYXJhdGlvbnMgaGVyZSB3 ZXJlDQo+Pj4gdXBkYXRlZCB0byB0aGUgbmV3IGZvcm1hdCAtIGEgaGVscCBpbiBnZXR0aW5nIG9u IHRoZSBuZXcgcGF0aC4NCj4+Pg0KPj4+IE15IGluY2xpbmF0aW9uIHdvdWxkIGJlIHRvIGNvbnZl cnQgdG8gdGhlIG5ldyBmb3JtYXQsIGlubGluZSBpbiB0aGUNCj4+PiBzZWN0aW9ucyB3aGVyZSB0 aGUgYXR0cmlidXRlIHN5bnRheCBpcyBjdXJyZW50bHkgZGVmaW5lZCwgYW5kIHRoZW4NCj4+PiBz aW1wbHkgY3Jvc3MgcmVmZXJlbmNlIHRob3NlIGRlZmluaXRpb25zIGZyb20gdGhlIElBTkEgQ29u c2lkZXJhdGlvbnMNCj4+PnNlY3Rpb24uDQo+Pj4NCj4+PiAJVGhhbmtzLA0KPj4+IAlQYXVsDQo+ Pj4NCj4+PiBPbiAxMi85LzE0IDY6NTMgUE0sIENoYXJsZXMgRWNrZWwgKGVja2VsY3UpIHdyb3Rl Og0KPj4+PiBPbiAxMi85LzE0LCAxMjoxNyBBTSwgIkNocmlzdGVyIEhvbG1iZXJnIg0KPj4+PiA8 Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPg0KPj4+PiB3cm90ZToNCj4+Pj4NCj4+Pj4+ IEhpLA0KPj4+Pj4NCj4+Pj4+Pj4gUTE6DQo+Pj4+Pj4+DQo+Pj4+Pj4+IFRoZXJlIGlzIGEgbmV3 ICJ0ZW1wbGF0ZSIgZm9yIGRlZmluaW5nIFNEUCBhdHRyaWJ1dGVzLiBJdCBoYXMNCj4+Pj4+Pj4g YmVlbiBkaXNjdXNzZWQgb24gdGhlIE1NVVNJQyBsaXN0LCBhbmQgUGF1bCBLIGNhbiBnaXZlIG1v cmUNCj4+Pj4+Pj4gaW5mb3JtYXRpb24gaWYgbmVlZGVkLg0KPj4+Pj4+DQo+Pj4+Pj4gQSBwdHIg dG8gdGhhdCB3b3VsZCBiZSBoZWxwZnVsLiBJIHNjYW5uZWQgdGhlIE1NVVNJQyBsaXN0IHF1aWNr bHkNCj4+Pj4+PiBidXQgbXVzdCBoYXZlIG1pc3NlZCBpdC4NCj4+Pj4+DQo+Pj4+PiBQbGVhc2Ug bG9vayBhdCBzZWN0aW9uIDYgaW4NCj4+Pj4+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaWQvZHJh ZnQtaWV0Zi1tbXVzaWMtcmZjNDU2NmJpcy0xMi50eHQNCj4+Pj4NCj4+Pj4gVGhpcyBzZWN0aW9u IG1ha2VzIGNvbnNpc3RlbnQgdXNlIG9mIHRoZSBmb2xsb3dpbmcgdGVtcGxhdGUgKHVzaW5nDQo+ Pj4+IKn4Y2F0qfcgYXMgYW4gZXhhbXBsZSk6DQo+Pj4+DQo+Pj4+IC0tLQ0KPj4+PiAgICAgIE5h bWU6IGNhdA0KPj4+Pg0KPj4+PiAgICAgIFZhbHVlOiBjYXQtdmFsdWUNCj4+Pj4NCj4+Pj4gICAg ICBVc2FnZSBMZXZlbDogc2Vzc2lvbg0KPj4+Pg0KPj4+PiAgICAgIENoYXJzZXQgRGVwZW5kZW50 OiBubw0KPj4+Pg0KPj4+PiAgICAgIFN5bnRheDoNCj4+Pj4NCj4+Pj4gICAgICAgICBjYXQtdmFs dWUgPSBjYXRlZ29yeQ0KPj4+PiAgICAgICAgIGNhdGVnb3J5ID0gYnl0ZS1zdHJpbmcNCj4+Pj4g ICAgICAgICAgIDsgTm90ZTogc3ludGF4IGlzIHZhZ3VlIGJlY2F1c2UgdXNhZ2UgaXMgbm90IHVu ZGVyc3Rvb2QNCj4+Pj4NCj4+Pj4gICAgICBFeGFtcGxlOg0KPj4+Pg0KPj4+PiAgICAgICAgIGE9 Y2F0OmZvby5iYXINCj4+Pj4NCj4+Pj4gICAgICBUaGlzIGF0dHJpYnV0ZSBnaXZlcyB0aGUgZG90 LXNlcGFyYXRlZCBoaWVyYXJjaGljYWwgY2F0ZWdvcnkgb2YNCj4+Pj50aGUNCj4+Pj4gICAgICBz ZXNzaW9uLiAgVGhpcyBpcyB0byBlbmFibGUgYSByZWNlaXZlciB0byBmaWx0ZXIgdW53YW50ZWQN Cj4+Pj4gc2Vzc2lvbnMgYnkNCj4+Pj4gICAgICBjYXRlZ29yeS4gIFRoZXJlIGlzIG5vIGNlbnRy YWwgcmVnaXN0cnkgb2YgY2F0ZWdvcmllcy4NCj4+Pj4NCj4+Pj4gPA0KPj4+Pg0KPj4+PiBJIGRv bqn2dCBiZWxpZXZlIGRyYWZ0LWlldGYtYmZjcGJpcy1yZmM0NTgzYmlzLTEwIHNob3VsZCBpbmNs dWRlIHN1Y2gNCj4+Pj4gaW5mbyBmb3IgZWFjaCBhdHRyaWJ1dGUgYmVjYXVzZSBzaW1pbGFyIGlu Zm9ybWF0aW9uIGlzIGFscmVhZHkNCj4+Pj4gY2FwdHVyZWQgaW4gdGhlIElBTkEgY29uc2lkZXJh dGlvbnMgc2VjdGlvbnMgaW4gZm9yIHRoZSBmb3JtYXQNCj4+Pj4gYXBwcm9wcmlhdGUgZm9yIElB TkEgY29uc2lkZXJhdGlvbnMuDQo+Pj4+DQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+DQo+Pj4+Pj4+IFEy Og0KPj4+Pj4+Pg0KPj4+Pj4+PiBNb3N0IFNEUCBhdHRyaWJ1dGVzIGFyZSBkZWZpbmVkIGluIHRo ZWlyIG93biBzZWN0aW9ucyAtIHdoaWNoIGlzDQo+Pj4+Pj4+IGdvb2QuDQo+Pj4+Pj4+IEJ1dCwg c29tZXRpbWVzIHRoZSBzZWN0aW9uIG5hbWUgY29udGFpbnMgdGhlIG5hbWUgb2YgdGhlDQo+Pj4+ Pj4+IGF0dHJpYnV0ZSwgYW5kIHNvbWV0aW1lcyBub3QuIEkgdGhpbmsgaXQgd291bGQgYmUgZ29v ZCB0byBiZQ0KPj4+Pj4+PiBjb25zaXN0ZW50LCBhbmQgYWx3YXlzIGNhbGwgdGhlIHNlY3Rpb24g IlNEUCB4eHggYXR0cmlidXRlIi4NCj4+Pj4NCj4+Pj4gVGhlIElBTkEgY29uc2lkZXJhdGlvbnMg c2VjdGlvbiBkb2VzIHRoaXMgKGkuZS4gU0RQIGF0dHJpYnV0ZSBuYW1lDQo+Pj4+IGluIHNlY3Rp b24gdGl0bGUpLiBTZWN0aW9ucyA0LTcgYXJlIG9yZ2FuaXplZCBieSBmdW5jdGlvbmFsaXR5DQo+ Pj4+IHJhdGhlciB0aGFuIGJ5IFNEUCBhdHRyaWJ1dGUuIEFzIHN1Y2gsIEkgdGhpbmsgdGhlIGV4 aXN0aW5nIG5hbWVzDQo+Pj4+IGFyZSBhcHByb3ByaWF0ZS4gV2UgY291bGQgYWRkIHN1YnNlY3Rp b25zIGZvciBlYWNoIGF0dHJpYnV0ZSB3aXRoaW4NCj4+Pj4gdGhlc2Ugc2VjdGlvbnMgdGhhdCBh cmUgbmFtZWQgYWNjb3JkaW5nIHRvIHRoZSBuYW1lIG9mIHRoZQ0KPj4+PiBjb3JyZXNwb25kaW5n IFNEUCBhdHRyaWJ1dGUuIFRoYXQgc2FpZCwgSSBkbyB0aGluayBzdWNoIGFkZGl0aW9ucw0KPj4+ PiB3b3VsZCBiZSBhbGwgdGhhdCB1c2VmdWwuDQo+Pj4+DQo+Pj4+Pj4+DQo+Pj4+Pj4+IFEzOg0K Pj4+Pj4+DQo+Pj4+Pj4gVGhlcmUgaXMgbm8gZGVkaWNhdGVkIFNEUCBPZmZlci9BbnN3ZXIgcHJv Y2VkdXJlIHNlY3Rpb24gKGluc3RlYWQsDQo+Pj4+Pj4gZWFjaCBzZWN0aW9uIGRlZmluaW5nIGFu IFNEUCBhdHRyaWJ1dGUgaW5jbHVkZSBhIGZldyBzZW50ZW5jZXMNCj4+Pj4+PiBhYm91dCBPZmZl ci9BbnN3ZXIpLg0KPj4+Pj4+DQo+Pj4+Pj4gSSB0aGluayBpdCB3b3VsZCBiZSBnb29kIHRvIGhh dmUgYSBkZWRpY2F0ZWQgU0RQIE9mZmVyL0Fuc3dlcg0KPj4+Pj4+IHByb2NlZHVyZSBzZWN0aW9u LCBmb2xsb3dpbmcgdGhlIHN0cnVjdHVyZSBpbiBSRkMgMzI2NC4gSSd2ZSBoYWQNCj4+Pj4+PiB0 byBkbyB0aGF0IGUuZy4NCj4+Pj4+PiBmb3IgQlVORExFIGFuZCBTQ1RQLVNEUC4NCj4+Pj4+Pg0K Pj4+Pj4+IEkgaGFkIGEgbG9vayBhdA0KPj4+Pj4+IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWlldGYtbW11c2ljLXNkcC1idW5kbGUtbmVnb3RpYXRpbw0KPj4+Pj4+IG4tDQo+Pj4+ Pj4gMTMgYXMgYW4gZXhhbXBsZS4gSSBzZWUgaG93IHdlIGNvdWxkIHJlbmFtZSBhbmQgcmVvcmdh bml6ZSB0aGUNCj4+Pj4+PiBleGlzdGluZyBjb250ZW50IGFsb25nIHRoZXNlIGxpbmVzLiBJIHN0 cnVnZ2xlIHdpdGggdGhpcyBhIGJpdA0KPj4+Pj4+IGJlY2F1c2UgSSBhbSBjb21mb3J0YWJsZSB3 aXRoIHRoZSBleGlzdGluZyBkb2N1bWVudCBzdHJ1Y3R1cmUgYW5kDQo+Pj4+Pj4gbXkgZmFtaWxp YXJpdHkgd2l0aCBpdCBtYWtlIGl0IHN0cmFpZ2h0Zm9yd2FyZCBmb3IgbWUgdG8gdW5kZXJzdGFu ZC4NCj4+Pj4+PiBGb3IgYSBuZXcgcmVhZGVyLCBJIHRoaW5rIHlvdXIgc3VnZ2VzdGVkIGNoYW5n ZSB3aWxsIGhlbHAsIHNvIEknbQ0KPj4+Pj4+IGluIGZhdm9yIG9mIGl0Lg0KPj4+Pj4NCj4+Pj4+ IEkgdG9vayB0aGUgdGV4dCBmcm9tIHRoZSBTQ1RQLVNEUCBkcmFmdCAobm90ZSB0aGF0IHRoZSB0 ZXh0IG1heQ0KPj4+Pj4gc3RpbGwgY2hhbmdlKSwgYW5kIHRyaWVkIHRvIGNvbnZlcnQgaXQgaW50 byBCRkNQLiBTb21lIHBhcnRzIGFyZQ0KPj4+Pj4gcHJvYmFibHkgc3RpbGwgbWlzc2luZyAoZm9y IGV4YW1wbGUsIEkgcmVhbGl6ZWQgdGhhdCBJIGZvcmdvdCB0bw0KPj4+Pj4gYWRkIHRleHQgcmVn YXJkaW5nIHRoZSBTRFAgJ2Zsb29yY3RybCcgYXR0cmlidXRlKSAsIGFuZCBtYXliZSB0aGUNCj4+ Pj4+IEJGQ1AgZHJhZnQgdXNlcyBkaWZmZXJlbnQgdGVybWlub2xvZ3ksIGJ1dCBmZWVsIGZyZWUg dG8gdXNlIGl0IGFzIGENCj4+Pj4+YmFzZToNCj4+Pj4+DQo+Pj4+PiAtLS0tLS0tLQ0KPj4+Pj4N Cj4+Pj4+IDkuICBTRFAgT2ZmZXIvQW5zd2VyIFByb2NlZHVyZXMNCj4+Pj4+DQo+Pj4+PiA5LjEu ICBHZW5lcmFsDQo+Pj4+Pg0KPj4+Pj4gICAgIFRoaXMgc2VjdGlvbiBkZWZpbmVzIHRoZSBTRFAg T2ZmZXIvQW5zd2VyIFtSRkMzMjY0XSBwcm9jZWR1cmVzDQo+Pj4+PmZvcg0KPj4+Pj4gICAgIG5l Z290aWF0aW5nIGFuZCBlc3RhYmxpc2hpbmcgYW4gQkZDUCBjb25uZWN0aW9uLg0KPj4+Pj4NCj4+ Pj4+ICAgICBJZiB0aGUgbS0gbGluZSBwcm90byB2YWx1ZSBpcyAnIFRDUC9UTFMvQkZDUCAnIG9y ICcNCj4+Pj4+IFVEUC9UTFMvQkZDUCAnLCBlYWNoDQo+Pj4+PiAgICAgZW5kcG9pbnQgTVVTVCBw cm92aWRlIGEgY2VydGlmaWNhdGUgZmluZ2VycHJpbnQsIHVzaW5nIHRoZSBTRFANCj4+Pj4+ICAg ICAnZmluZ2VycHJpbnQnIGF0dHJpYnV0ZSBbUkZDNDE0NV0sIGlmIHRoZSBlbmRwb2ludCBzdXBw b3J0cywgYW5kDQo+Pj4+PmlzDQo+Pj4+PiAgICAgd2lsbGluZyB0byB1c2UsIGEgY2lwaGVyIHN1 aXRlIHdpdGggYW4gYXNzb2NpYXRlZCBjZXJ0aWZpY2F0ZS4NCj4+Pj4+DQo+Pj4+PiAgICAgVGhl IGF1dGhlbnRpY2F0aW9uIGNlcnRpZmljYXRlcyBhcmUgaW50ZXJwcmV0ZWQgYW5kIHZhbGlkYXRl ZCBhcw0KPj4+Pj4gICAgIGRlZmluZWQgaW4gW1JGQzQ1NzJdLiAgU2VsZi1zaWduZWQgY2VydGlm aWNhdGVzIGNhbiBiZSB1c2VkDQo+Pj4+PiBzZWN1cmVseSwNCj4+Pj4+ICAgICBwcm92aWRlZCB0 aGF0IHRoZSBpbnRlZ3JpdHkgb2YgdGhlIFNEUCBkZXNjcmlwdGlvbiBpcyBhc3N1cmVkIGFzDQo+ Pj4+PiAgICAgZGVmaW5lZCBpbiBbUkZDNDU3Ml0uDQo+Pj4+Pg0KPj4+Pj4gICAgIE5PVEU6IFRo ZSBwcm9jZWR1cmVzIGFwcGx5IHRvIGEgc3BlY2lmaWMgbS0gbGluZSBkZXNjcmliaW5nIGFuDQo+ Pj4+PkJGQ1ANCj4+Pj4+ICAgICBjb25uZWN0aW9uLiAgSWYgYW4gb2ZmZXIgb3IgYW5zd2VyIGNv bnRhaW5zIG11bHRpcGxlIG0tIGxpbmUNCj4+Pj4+ICAgICBkZXNjcmliaW5nIEJGQ1AgY29ubmVj dGlvbnMsIHRoZSBwcm9jZWR1cmVzIGFyZSBhcHBsaWVkDQo+Pj4+PnNlcGFyYXRlbHkNCj4+Pj4+ ICAgICB0byBlYWNoIG0tIGxpbmUuDQo+Pj4+Pg0KPj4+Pj4gOS4yLiAgR2VuZXJhdGluZyB0aGUg SW5pdGlhbCBTRFAgT2ZmZXINCj4+Pj4+DQo+Pj4+PiAgICBXaGVuIHRoZSBvZmZlcmVyIGNyZWF0 ZXMgYW4gaW5pdGlhbCBvZmZlciwgdGhlIG9mZmVyZXI6DQo+Pj4+Pg0KPj4+Pj4gICAgIG8gIE1V U1QsIGlmIHRoZSBtLSBsaW5lIHByb3RvIHZhbHVlIGlzICdUQ1AvQkZDUCcsDQo+Pj4+PidUQ1Av VExTL0JGQ1AnIG9yDQo+Pj4+PiAgICAgICAgICdVRFAvVExTL0JGQ1AnLCBhc3NvY2lhdGUgYW4g U0RQIHNldHVwIGF0dHJpYnV0ZSBbU2VjdGlvbg0KPj4+Pj4gWF0sIHdpdGggYW4NCj4+Pj4+ICAg ICAgICAnYWN0cGFzcycgdmFsdWUsIHdpdGggdGhlIG0tIGxpbmU7DQo+Pj4+Pg0KPj4+Pj4gICAg IG8gIE1VU1QsIGlmIHRoZSBtLSBsaW5lIHByb3RvIHZhbHVlIGlzICdUQ1AvQkZDUCcgb3INCj4+ Pj4+J1RDUC9UTFMvQkZDUCcsDQo+Pj4+PiAgICAgICAgIGFzc29jaWF0ZSBhbiBTRFAgJ2Nvbm5l Y3Rpb24nIGF0dHJpYnV0ZSBbU2VjdGlvbiA4LjRdLCB3aXRoIGENCj4+Pj4+ICAgICAgICAgJ25l dycgdmFsdWUsIHdpdGggdGhlIG0tIGxpbmU7IGFuZA0KPj4+Pj4NCj4+Pj4+ICAgICBJbiBhZGRp dGlvbiwgaWYgdGhlIG9mZmVyZXIgYWN0cyBhcyB0aGUgZmxvb3IgY29udHJvbCBzZXJ2ZXIsDQo+ Pj4+PiB0aGUNCj4+Pj4+IG9mZmVyZXI6DQo+Pj4+Pg0KPj4+Pj4gICAgIG8gIE1VU1QgYXNzb2Np YXRlIGFuIFNEUCAnY29uZmlkJyBhdHRyaWJ1dGUgW1NlY3Rpb24gWF0sIHdpdGgNCj4+Pj4+IHRo ZQ0KPj4+Pj4gbS0gbGluZTsNCj4+Pj4+DQo+Pj4+PiAgICAgbyAgTVVTVCBhc3NvY2lhdGUgYW4g U0RQICd1c2VyaWQnIGF0dHJpYnV0ZSBbU2VjdGlvbiBYXSwgd2l0aA0KPj4+Pj4gdGhlDQo+Pj4+ PiBtLSBsaW5lOw0KPj4+Pj4NCj4+Pj4+ICAgICBvICBNVVNUIGFzc29jaWF0ZSBhbiBTRFAgJ2Zs b29yaWQnIGF0dHJpYnV0ZSBbU2VjdGlvbiBYXSwgd2l0aA0KPj4+Pj4gdGhlDQo+Pj4+PiBtLSBs aW5lOyBhbmQNCj4+Pj4+DQo+Pj4+PiAgICAgbyAgTVVTVCBhc3NvY2lhdGUgYW4gU0RQICdsYWJl bCcgYXR0cmlidXRlIFtTZWN0aW9uIFhdLCB3aXRoDQo+Pj4+PiB0aGUNCj4+Pj4+IG0tIGxpbmUu DQo+Pj4+Pg0KPj4+Pj4gOS4zLiAgR2VuZXJhdGluZyB0aGUgU0RQIEFuc3dlcg0KPj4+Pj4NCj4+ Pj4+ICAgICBXaGVuIHRoZSBhbnN3ZXJlciByZWNlaXZlcyBhbiBvZmZlciwgd2hpY2ggY29udGFp bnMgYW4gbS0gbGluZQ0KPj4+Pj4gICAgIGRlc2NyaWJpbmcgYSBCRkNQIGNvbm5lY3Rpb24sIGlm IHRoZSBhbnN3ZXJlciBhY2NlcHRzIHRoZSBtLSBsaW5lDQo+Pj4+PiAgICAgaXQ6DQo+Pj4+Pg0K Pj4+Pj4gICAgIG8gIE1VU1QgaW5zZXJ0IGEgY29ycmVzcG9uZGluZyBtLSBsaW5lIGluIHRoZSBh bnN3ZXIsIHdpdGggYW4NCj4+Pj4+ICAgICAgICBpZGVudGljYWwgbS0gbGluZSBwcm90byB2YWx1 ZSBbUkZDMzI2NF07IGFuZA0KPj4+Pj4NCj4+Pj4+ICAgICBvICBNVVNULCBpZiB0aGUgbS0gbGlu ZSBwcm90byB2YWx1ZSBpcyAnVENQL0JGQ1AnLA0KPj4+Pj4nVENQL1RMUy9CRkNQJyBvcg0KPj4+ Pj4gICAgICAgICAnVURQL1RMUy9CRkNQJywgYXNzb2NpYXRlIGFuIFNEUCBzZXR1cCBhdHRyaWJ1 dGUgW1NlY3Rpb24NCj4+Pj4+IFhdLCB3aXRoIGFuDQo+Pj4+PiAgICAgICAgJ2FjdGl2ZScgb3Ig J3Bhc3NpdmUnIHZhbHVlLCB3aXRoIHRoZSBtLSBsaW5lOw0KPj4+Pj4NCj4+Pj4+ICAgICBJbiBh ZGRpdGlvbiwgaWYgdGhlIGFuc3dlcmVyIGFjdHMgYXMgdGhlIGZsb29yIGNvbnRyb2wgc2VydmVy LA0KPj4+Pj4gdGhlDQo+Pj4+PiBhbnN3ZXJlcjoNCj4+Pj4+DQo+Pj4+PiAgICAgbyAgTVVTVCBh c3NvY2lhdGUgYW4gU0RQICdjb25maWQnIGF0dHJpYnV0ZSBbU2VjdGlvbiBYXSwgd2l0aA0KPj4+ Pj4gdGhlDQo+Pj4+PiBtLSBsaW5lOw0KPj4+Pj4NCj4+Pj4+ICAgICBvICBNVVNUIGFzc29jaWF0 ZSBhbiBTRFAgJ3VzZXJpZCcgYXR0cmlidXRlIFtTZWN0aW9uIFhdLCB3aXRoDQo+Pj4+PiB0aGUN Cj4+Pj4+IG0tIGxpbmU7DQo+Pj4+Pg0KPj4+Pj4gICAgIG8gIE1VU1QgYXNzb2NpYXRlIGFuIFNE UCAnZmxvb3JpZCcgYXR0cmlidXRlIFtTZWN0aW9uIFhdLCB3aXRoDQo+Pj4+PiB0aGUNCj4+Pj4+ IG0tIGxpbmU7IGFuZA0KPj4+Pj4NCj4+Pj4+ICAgICBvICBNVVNUIGFzc29jaWF0ZSBhbiBTRFAg J2xhYmVsJyBhdHRyaWJ1dGUgW1NlY3Rpb24gWF0sIHdpdGgNCj4+Pj4+IHRoZQ0KPj4+Pj4gbS0g bGluZS4NCj4+Pj4+DQo+Pj4+PiAgICAgT25jZSB0aGUgYW5zd2VyZXIgaGFzIHNlbnQgdGhlIGFu c3dlciwgdGhlIGFuc3dlcmVyOg0KPj4+Pj4NCj4+Pj4+ICAgICBvICBNVVNULCBpZiB0aGUgYW5z d2VyZXIgaXMgdGhlICdhY3RpdmUnIGVuZHBvaW50LCBhbmQgaWYgYSBUQ1ANCj4+Pj4+IGNvbm5l Y3Rpb24NCj4+Pj4+ICAgICAgICAgYXNzb2NpYXRlZCB3aXRoIHRoZSBtLSBsaW5lIGlzIHRvIGJl IGVzdGFibGlzaGVkIChvcg0KPj4+Pj4gcmUtZXN0YWJsaXNoZWQpLA0KPj4+Pj4gICAgICAgICBp bml0aWF0ZSB0aGUgZXN0YWJsaXNoaW5nIG9mIHRoZSBUQ1AgY29ubmVjdGlvbjsgYW5kDQo+Pj4+ Pg0KPj4+Pj4gICAgIG8gIE1VU1QsIGlmIHRoZSBhbnN3ZXJlciBpcyB0aGUgJ2FjdGl2ZScgZW5k cG9pbnQsIGFuZCBpZiBhbg0KPj4+Pj4gVExTL0RUTFMNCj4+Pj4+ICAgICAgICBjb25uZWN0aW9u IGFzc29jaWF0ZWQgd2l0aCB0aGUgbS0gbGluZSBpcyB0byBiZSBlc3RhYmxpc2hlZA0KPj4+Pj4o b3INCj4+Pj4+ICAgICAgICByZS1lc3RhYmxpc2hlZCksIGluaXRpYXRlIHRoZSBlc3RhYmxpc2hp bmcgb2YgdGhlIFRMUy9EVExTDQo+Pj4+PiBjb25uZWN0aW9uDQo+Pj4+PiAgICAgICAgKGJ5IHNl bmRpbmcgYSBDbGllbnRIZWxsbyBtZXNzYWdlKS4NCj4+Pj4+DQo+Pj4+PiAgICAgSWYgdGhlIGFu c3dlcmVyIGRvZXMgbm90IGFjY2VwdCB0aGUgbS0gbGluZSBpbiB0aGUgb2ZmZXIsIGl0IE1VU1QN Cj4+Pj4+ICAgICBhc3NpZ24gYSB6ZXJvIHBvcnQgdmFsdWUgdG8gdGhlIGNvcnJlc3BvbmRpbmcg bS0gbGluZSBpbiB0aGUNCj4+Pj4+YW5zd2VyLg0KPj4+Pj4gICAgIEluIGFkZGl0aW9uLCB0aGUg YW5zd2VyZXIgTVVTVCBOT1QgZXN0YWJsaXNoIGFuIFNDVFANCj4+Pj4+YXNzb2NpYXRpb24sIG9y DQo+Pj4+PiAgICAgYSBEVExTIGNvbm5lY3Rpb24sIGFzc29jaWF0ZWQgd2l0aCB0aGUgbS0gbGlu ZS4NCj4+Pj4+DQo+Pj4+PiA5LjQuICBPZmZlcmVyIFByb2Nlc3Npbmcgb2YgdGhlIFNEUCBBbnN3 ZXINCj4+Pj4+DQo+Pj4+PiAgICAgV2hlbiB0aGUgb2ZmZXJlciByZWNlaXZlcyBhbiBhbnN3ZXIs IHdoaWNoIGNvbnRhaW5zIGFuIG0tIGxpbmUNCj4+Pj4+IHdpdGggYQ0KPj4+Pj4gICAgIG5vbi16 ZXJvIHBvcnQgdmFsdWUsIGRlc2NyaWJpbmcgYSBCRkNQIGNvbm5lY3Rpb24sIHRoZSBvZmZlcmVy Og0KPj4+Pj4NCj4+Pj4+ICAgICBvICBNVVNULCBpZiB0aGUgb2ZmZXIgaXMgdGhlICdhY3RpdmUn IGVuZHBvaW50LCBhbmQgaWYgYSBUQ1ANCj4+Pj4+IGNvbm5lY3Rpb24NCj4+Pj4+ICAgICAgICAg YXNzb2NpYXRlZCB3aXRoIHRoZSBtLSBsaW5lIGlzIHRvIGJlIGVzdGFibGlzaGVkIChvcg0KPj4+ Pj4gcmUtZXN0YWJsaXNoZWQpLA0KPj4+Pj4gICAgICAgICBpbml0aWF0ZSB0aGUgZXN0YWJsaXNo aW5nIG9mIHRoZSBUQ1AgY29ubmVjdGlvbjsgYW5kDQo+Pj4+Pg0KPj4+Pj4gICAgIG8gIE1VU1Qs IGlmIHRoZSBvZmZlcmVyIGlzIHRoZSAnYWN0aXZlJyBlbmRwb2ludCwgYW5kIGlmIGFuDQo+Pj4+ PlRMUy9EVExTDQo+Pj4+PiAgICAgICAgY29ubmVjdGlvbiBhc3NvY2lhdGVkIHdpdGggdGhlIG0t IGxpbmUgaXMgdG8gYmUgZXN0YWJsaXNoZWQNCj4+Pj4+KG9yDQo+Pj4+PiAgICAgICAgcmUtZXN0 YWJsaXNoZWQpLCBpbml0aWF0ZSB0aGUgZXN0YWJsaXNoaW5nIG9mIHRoZSBUTFMvRFRMUw0KPj4+ Pj4gY29ubmVjdGlvbg0KPj4+Pj4gICAgICAgIChieSBzZW5kaW5nIGEgQ2xpZW50SGVsbG8gbWVz c2FnZSkuDQo+Pj4+Pg0KPj4+Pj4gICAgIElmIHRoZSBtLSBsaW5lIGluIHRoZSBhbnN3ZXIgY29u dGFpbnMgYSB6ZXJvIHBvcnQgdmFsdWUsIHRoZQ0KPj4+Pj5vZmZlcmVyDQo+Pj4+PiAgICAgTVVT VCBOT1QgZXN0YWJsaXNoIGFuIFRDUCBjb25uZWN0aW9uLCBvciBhIFRMUy9EVExTIGNvbm5lY3Rp b24sDQo+Pj4+PiAgICAgYXNzb2NpYXRlZCB3aXRoIHRoZSBtLSBsaW5lLg0KPj4+Pj4NCj4+Pj4+ IDkuNS4gIE1vZGlmeWluZyB0aGUgU2Vzc2lvbg0KPj4+Pj4NCj4+Pj4+ICAgICBXaGVuIGFuIG9m ZmVyZXIgc2VuZHMgYW4gdXBkYXRlZCBvZmZlciwgaW4gb3JkZXIgdG8gbW9kaWZ5IGENCj4+Pj4+ ICAgICBwcmV2aW91c2x5IGVzdGFibGlzaGVkIEJGQ1AgY29ubmVjdGlvbiwgaXQgZm9sbG93cyB0 aGUNCj4+Pj4+cHJvY2VkdXJlcyBpbg0KPj4+Pj4gICAgIFNlY3Rpb24gOS4yLCB3aXRoIHRoZSBm b2xsb3dpbmcgZXhjZXB0aW9uczoNCj4+Pj4+DQo+Pj4+PiAgICAgbyAgSWYgdGhlIEJGQ1AgY29u bmVjdGlvbiBpcyBjYXJyaWVkIG9uIHRvcCBvZiBUQ1AsIGFuZCB1bmxlc3MNCj4+Pj4+dGhlDQo+ Pj4+PiAgICAgICAgIG9mZmVyZXIgd2FudHMgdG8gcmUtZXN0YWJsaXNoIGFuIGV4aXN0aW5nIFRD UCBjb25uZWN0aW9uLCB0aGUNCj4+Pj4+ICAgICAgICAgb2ZmZXJlciBNVVNUIGFzc29jaWF0ZSBh biBTRFAgY29ubmVjdGlvbiBhdHRyaWJ1dGUsIHdpdGgNCj4+Pj4+ICAgICAgICBhbiAnZXhpc3Rp bmcnIHZhbHVlLCB3aXRoIHRoZSBtLSBsaW5lOyBhbmQNCj4+Pj4+DQo+Pj4+PiAgICAgbyAgSWYg dGhlIG9mZmVyZXIgd2FudHMgdG8gZGlzYWJsZSBhIHByZXZpb3VzbHkgZXN0YWJsaXNoZWQgQkZD UA0KPj4+Pj4gICAgICAgIGNvbm5lY3Rpb24sIGl0IE1VU1QgYXNzaWduIGEgemVybyBwb3J0IHZh bHVlIHRvIHRoZSBtLSBsaW5lDQo+Pj4+PiAgICAgICAgYXNzb2NpYXRlZCB3aXRoIHRoZSBCRkNQ IGNvbm5lY3Rpb24sIGZvbGxvd2luZyB0aGUgcHJvY2VkdXJlcw0KPj4+Pj5pbg0KPj4+Pj4gICAg ICAgIFtSRkMzMjY0XS4NCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4gLS0tLS0tLS0tLS0tLS0tDQo+Pj4+ DQo+Pj4+IFRoYXQgbG9va3MgcHJldHR5IHN0cmFpZ2h0Zm9yd2FyZCBhbmQgY2xlYXIgdG8gbWUu IEFkZGluZyB0aGUNCj4+Pj4gZmxvb3JjdHJsIGF0dHJpYnV0ZSB3aWxsIGNvbXBsaWNhdGUgaXQg c29tZSwgYnV0IEkgdGhpbmsgaXRzIHN0aWxsDQo+Pj4+IG1hbmFnZWFibGUuDQo+Pj4+DQo+Pj4+ Pg0KPj4+Pj4gUTNiOg0KPj4+Pj4NCj4+Pj4+IFRoZSBmb2xsb3dpbmcgc2VudGVuY2UgaW4gNDU4 M2JpcyBpcyBhIGxpdHRsZSBjb25mdXNpbmc6DQo+Pj4+Pg0KPj4+Pj4gICAgICJJZiB0aGUgJ2Zs b29yY3RybCcgYXR0cmlidXRlIGlzIG5vdCB1c2VkIGluIGFuIG9mZmVyL2Fuc3dlcg0KPj4+Pj4g ZXhjaGFuZ2UsDQo+Pj4+PiAgICAgYnkgZGVmYXVsdCB0aGUgb2ZmZXJlciBhbmQgdGhlIGFuc3dl cmVyIHdpbGwgYWN0IGFzIGEgZmxvb3INCj4+Pj4+Y29udHJvbA0KPj4+Pj4gICAgIGNsaWVudCBh bmQgYXMgYSBmbG9vciBjb250cm9sIHNlcnZlciwgcmVzcGVjdGl2ZWx5LiINCj4+Pj4+DQo+Pj4+ PiBEb2VzIHRoaXMgbWVhbiB0aGF0IHRoZSByb2xlIG1heSBjaGFuZ2UgZXZlcnkgdGltZSBhbiBl bmRwb2ludCAtDQo+Pj4+PiBmb3Igd2hhdGV2ZXIgcmVhc29uIC0gc2VuZHMgYW4gdXBkYXRlZCBv ZmZlcj8NCj4+Pj4NCj4+Pj4gWWVzLiBUaGlzIHdhcyBpbmhlcml0ZWQgZnJvbSBSRkMgNDU4Mywg YW5kIGl0IGlzIHRoZSBjb25zZXF1ZW5jZSBvZg0KPj4+PiB0aGUgbGVuaWVudCBub3JtYXRpdmUg bGFuZ3VhZ2UgaW1tZWRpYXRlbHkgYmVmb3JlIGl0Lg0KPj4+Pg0KPj4+PiAJIkVuZHBvaW50cyB0 aGF0IHVzZSB0aGUgb2ZmZXIvYW5zd2VyIG1vZGVsIHRvIGVzdGFibGlzaCBCRkNQDQo+Pj4+IAlj b25uZWN0aW9ucyBNVVNUIHN1cHBvcnQgdGhlICdmbG9vcmN0cmwnIGF0dHJpYnV0ZS4gIEEgZmxv b3IgY29udHJvbA0KPj4+PiAJc2VydmVyIGFjdGluZyBhcyBhbiBvZmZlcmVyIG9yIGFzIGFuIGFu c3dlcmVyIFNIT1VMRCBpbmNsdWRlIHRoaXMNCj4+Pj4gCWF0dHJpYnV0ZSBpbiBpdHMgc2Vzc2lv biBkZXNjcmlwdGlvbnMuqfcNCj4+Pj4NCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+DQo+Pj4+ Pj4+IFE0Og0KPj4+Pj4+Pg0KPj4+Pj4+PiBGb3IgRFRMUyBhbmQgT2ZmZXIvQW5zd2VyLCB0aGVy ZSBhcmUgYSBmZXcgcmVmZXJlbmNlcyB0byBSRkMgNTc2Mw0KPj4+Pj4+PiBoZXJlIGFuZCB0aGVy ZS4gQnV0LCBJIHRoaW5rIGl0IHdvdWxkIGJlIGdvb2QgdG8gaGF2ZSBleHBsaWNpdA0KPj4+Pj4+ PiB0ZXh0IG9uIHRoZSBPZmZlci9BbnN3ZXIgY29uc2lkZXJhdGlvbnMgcmVnYXJkaW5nIERUTFMg LQ0KPj4+Pj4+PiBlc3BlY2lhbGx5IHNpbmNlIHRoZXJlIGhhdmUgYmVlbiBxdWl0ZSBhIGJpdCBv ZiBkaXNjdXNzaW9ucyBhYm91dA0KPj4+Pj4+PnRoYXQgbGF0ZWx5Lg0KPj4+Pj4+DQo+Pj4+Pj4g QXJlIHlvdSBzdWdnZXN0aW5nIGEgY29weS9wYXN0ZSBvZiB0aGUgcmVsZXZhbnQgdGV4dCBmcm9t IFJGQyA1NzYzDQo+Pj4+Pj4gaW4gYWRkaXRpb25hbCB0byBhIHJlZmVyZW5jZSwgb3IgaXMgdGhl cmUgYW4gY2FsY2lmaWNhdGlvbiBvZiB3aGF0DQo+Pj4+Pj4gaXMgcHJvdmlkZWQgaW4gUkZDIDU3 NjMgdGhhdCB5b3UgYWRkZWQgZm9yIFNDVFAgdGhhdCB3b3VsZCBiZQ0KPj4+Pj4+IGhlbHBmdWwg Zm9yIHRoaXMgZHJhZnQ/DQo+Pj4+Pg0KPj4+Pj4gSW4gdGhlIFNDVFAtU0RQIGRyYWZ0IEkgaGF2 ZSB0aGUgZm9sbG93aW5nIHRleHQsIHdoaWNoIGlzIGFsaWduZWQNCj4+Pj4+IHdpdGggUkZDIDU3 NjMsIGJ1dCBwcm92aWRlcyBhIGxpdHRsZSBtb3JlIGRldGFpbHMuDQo+Pj4+Pg0KPj4+Pj4gWW91 IGNvdWxkIHByb2JhYmx5IHVzZSB0aGUgdGV4dCBqdXN0IGJ5IHJlcGxhY2luZyB0aGUgcHJvdG8g ZmllbGQNCj4+Pj4+IHZhbHVlcyB3aXRoIHRoZSBvbmVzIHVzZWQgZm9yIEJGQ1AuDQo+Pj4+Pg0K Pj4+Pj4gLS0tLS0tLS0tLS0tLQ0KPj4+Pj4NCj4+Pj4+IDguMy4zLiAgVExTIFJvbGUgRGV0ZXJt aW5hdGlvbg0KPj4+Pj4NCj4+Pj4+ICAgICBJZiB0aGUgbS0gbGluZSBwcm90byB2YWx1ZSBpcyAn U0NUUC9EVExTJyBvciAnRFRMUy9TQ1RQJywgdGhlDQo+Pj4+PiAgICAgJ2FjdGl2ZS9wYXNzaXZl JyBzdGF0dXMgaXMgdXNlZCB0byBkZXRlcm1pbmUgdGhlIFRMUyByb2xlcy4NCj4+Pj4+ICAgICBG b2xsb3dpbmcgdGhlIHByb2NlZHVyZXMgaW4gW1JGQzQ1NzJdLCB0aGUgJ2FjdGl2ZScgZW5kcG9p bnQgd2lsbA0KPj4+Pj4gICAgIHRha2UgdGhlIFRMUyBjbGllbnQgcm9sZS4NCj4+Pj4+DQo+Pj4+ PiAgICAgT25jZSBhIERUTFMgY29ubmVjdGlvbiBoYXMgYmVlbiBlc3RhYmxpc2hlZCwgaWYgdGhl DQo+Pj4+PidhY3RpdmUvcGFzc2l2ZScNCj4+Pj4+ICAgICBzdGF0dXMgb2YgdGhlIGVuZHBvaW50 cyBjaGFuZ2UgZHVyaW5nIGEgc2Vzc2lvbiwgYSBuZXcgRFRMUw0KPj4+Pj4gICAgIGNvbm5lY3Rp b24gTVVTVCBiZSBlc3RhYmxpc2hlZC4gIFRoZXJlZm9yZSwgZW5kcG9pbnRzIFNIT1VMRCBOT1QN Cj4+Pj4+ICAgICBjaGFuZ2UgdGhlICdhY3RpdmUvcGFzc2l2ZScgc3RhdHVzIGluIHN1YnNlcXVl bnQgb2ZmZXJzIGFuZA0KPj4+Pj5hbnN3ZXJzLA0KPj4+Pj4gICAgIHVubGVzcyB0aGV5IHdhbnQg dG8gZXN0YWJsaXNoIGEgbmV3IERUTFMgY29ubmVjdGlvbi4NCj4+Pj4+DQo+Pj4+PiAgICAgSWYg dGhlIHRyYW5zcG9ydCBwYXJhbWV0ZXJzIG9yIHRoZSBrZXkgZmluZ2VycHJpbnRzIGNoYW5nZSwg dGhlDQo+Pj4+PiAgICAgZW5kcG9pbnRzIE1VU1QgZXN0YWJsaXNoIGEgbmV3IERUTFMgY29ubmVj dGlvbi4gIEluIHN1Y2ggY2FzZSB0aGUNCj4+Pj4+ICAgICAnYWN0aXZlL3Bhc3NpdmUnIHN0YXR1 cyBvZiB0aGUgZW5kcG9pbnRzIHdpbGwgYWdhaW4gYmUgZGV0ZXJtaW5lZA0KPj4+Pj4gICAgIGZv bGxvd2luZyB0aGUgcHJvY2VkdXJlcyBpbiBbUkZDNDE0NV0sIGFuZCB0aGUgbmV3IHN0YXR1cyB3 aWxsIGJlDQo+Pj4+PiAgICAgdXNlZCB0byBkZXRlcm1pbmUgdGhlIFRMUyByb2xlcyBhc3NvY2lh dGVkIHdpdGggdGhlIG5ldyBEVExTDQo+Pj4+PiAgICAgY29ubmVjdGlvbi4NCj4+Pj4+DQo+Pj4+ PiAgICAgTk9URTogVGhlIHByb2NlZHVyZSBhYm92ZSBpcyBpZGVudGljYWwgdG8gdGhlIG9uZSBk ZWZpbmVkIGZvcg0KPj4+Pj5TUlRQLQ0KPj4+Pj4gICAgIERUTFMgaW4gW1JGQzU3NjNdLg0KPj4+ Pj4NCj4+Pj4+ICAgICBOT1RFOiBBIG5ldyBEVExTIGNvbm5lY3Rpb24gbmVlZHMgdG8gYmUgZXN0 YWJsaXNoZWQgaWYgdGhlDQo+Pj4+PnRyYW5zcG9ydA0KPj4+Pj4gICAgIHBhcmFtZXRlcnMgb3Ig dGhlIGtleSBmaW5nZXJwcmludHMgY2hhbmdlLg0KPj4+Pj4NCj4+Pj4+IC0tLS0tLS0tLS0tLQ0K Pj4+Pg0KPj4+PiBJIGFtIG9rYXkgd2l0aCB0aGlzLiBJdHMgYSBuaWNlIHN1bW1hcnkuIE91ciBw cmV2aW91cyByZWZlcmVuY2UgdG8NCj4+Pj4gUkZDIDU3NjMsIHNlY3Rpb24gNSwgZGlkIG5vdCBh ZGRyZXNzIHNlc3Npb24gbW9kaWZpY2F0aW9uLiBUaGlzIGZpeGVzDQo+Pj4+dGhhdC4NCj4+Pj4N Cj4+Pj4+DQo+Pj4+Pj4gUTU6DQo+Pj4+Pj4NCj4+Pj4+PiBUaGUgZHJhZnQgZG9lcyBub3QgZGVm aW5lIGhvdyB0byB1c2UgQkZDUCB3aXRoaW4gYSBCVU5ETEUgZ3JvdXAuDQo+Pj4+Pj4gVGhhdCBp cyBmaW5lLCBidXQgSSB0aGluayBpdCB3b3VsZCBiZSBnb29kIHRvIGV4cGxpY2l0bHkgaW5kaWNh dGUNCj4+Pj4+PiB0aGF0Lg0KPj4+Pj4+DQo+Pj4+Pj4gWWVzLiBJJ20gdGhpbmtpbmcgd2UgbmVl ZCB0byBwb2ludCB0bw0KPj4+Pj4+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1p ZXRmLW1tdXNpYy1zZHAtbXV4LWF0dHJpYnV0ZXMtMA0KPj4+Pj4+IDUjDQo+Pj4+Pj4gcGFnZS0N Cj4+Pj4+PiAyOCBmb3IgYXR0cmlidXRlcyBkZWZpbmVkIGluIFJGQyA0NTgzLCBhbmQgIGRlZmlu ZSAgdGhlIG11eA0KPj4+Pj4+IGNhdGVnb3J5IGZvciBuZXcgYXR0cmlidXRlcyBkZWZpbmVkIHdp dGhpbiB0aGlzIGRyYWZ0Lg0KPj4+Pj4NCj4+Pj4+IERlZmluaW5nIHRoZSBtdXggY2F0ZWdvcnkg aXMgb25lIHRoaW5nLg0KPj4+Pj4NCj4+Pj4+IEJ1dCwgaWYgeW91IHdhbnQgdG8gZGVmaW5lIHVz YWdlIG9mIEJGQ1Agd2l0aGluIGEgQlVORExFIGdyb3VwLCB5b3UNCj4+Pj4+IGFsc28gbmVlZCB0 byBkZXNjcmliZSBob3cgQkZDUCBpcyBpZGVudGlmaWVkIHdoZW4gYnVuZGxlZCB3aXRoDQo+Pj4+ PiBvdGhlciBwcm90b2NvbHMgKFJUUCBldGMpLg0KPj4+Pg0KPj4+PiBJIHRoaW5rIHRoaXMgZ29l cyBiZXlvbmQgd2hhdCBpcyBuZWVkZWQgZm9yIHRoaXMgZHJhZnQuIElmIHNvbWVvbmUNCj4+Pj4g d2FudHMgdG8gdXNlIEJGQ1Agd2l0aCBCVU5ETEUsIHRoZXkgY2FuIGRlZmluZSB0aGF0IHVzYWdl LiBTb3VuZHMNCj4+Pj4gcmVhc29uYWJsZT8NCj4+Pj4NCj4+Pj4gQ2hlZXJzLA0KPj4+PiBDaGFy bGVzDQo+Pj4+DQo+Pj4+Pg0KPj4+Pj4gUmVnYXJkcywNCj4+Pj4+DQo+Pj4+PiBDaHJpc3Rlcg0K Pj4+Pj4NCj4+Pj4NCj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4+Pj4gYmZjcGJpcyBtYWlsaW5nIGxpc3QNCj4+Pj4gYmZjcGJpc0BpZXRmLm9y Zw0KPj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2JmY3BiaXMNCj4+ Pj4NCj4+Pg0KPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+Pj4gYmZjcGJpcyBtYWlsaW5nIGxpc3QNCj4+PiBiZmNwYmlzQGlldGYub3JnDQo+Pj4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9iZmNwYmlzDQo+Pj4NCj4+PiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+IGJmY3Bi aXMgbWFpbGluZyBsaXN0DQo+Pj4gYmZjcGJpc0BpZXRmLm9yZw0KPj4+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vYmZjcGJpcw0KPj4gDQo+DQoNCg==