From nobody Fri Feb 1 12:22:50 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25174130E91; Fri, 1 Feb 2019 12:22:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 G-GdgZT4JDRW; Fri, 1 Feb 2019 12:22:30 -0800 (PST) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBCA2130E78; Fri, 1 Feb 2019 12:22:29 -0800 (PST) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id DDF8128B004A; Fri, 1 Feb 2019 15:22:27 -0500 (EST) Received: from [127.0.0.1] (nova.tislabs.com [10.66.1.77]) by nova.tislabs.com (Postfix) with ESMTP id 9C8131F804E; Fri, 1 Feb 2019 15:22:27 -0500 (EST) Content-Type: multipart/alternative; boundary="Apple-Mail=_35F69572-A901-4C6E-A1DD-0B7BFFAACBFB" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Russ Mundy In-Reply-To: <055301d4b953$0044f3d0$00cedb70$@olddog.co.uk> Date: Fri, 1 Feb 2019 15:22:27 -0500 Cc: Russ Mundy , secdir@ietf.org, draft-ietf-mpls-sfc.all@ietf.org, ietf@ietf.org X-Mao-Original-Outgoing-Id: 570745346.421443-a8352cab859f2106271305d2750271b5 Message-Id: <303AF160-B911-4B70-83B1-583BB96CEB19@tislabs.com> References: <5920C065-DDDB-4C1A-83FB-E0436C467D3B@tislabs.com> <055301d4b953$0044f3d0$00cedb70$@olddog.co.uk> To: adrian@olddog.co.uk X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [secdir] secdir last call review of draft-ietf-mpls-sfc-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2019 20:22:38 -0000 --Apple-Mail=_35F69572-A901-4C6E-A1DD-0B7BFFAACBFB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jan 31, 2019, at 5:52 AM, Adrian Farrel > wrote: >=20 > Hi Russ, Hi Adrian, >=20 > Thanks for reviewing. You=E2=80=99re welcome. >=20 > A few responses ... >=20 >> Summary: >>=20 >> This document defines defines a methods to achieve Service Function = Chaining (SFC)=20 >> using Network Service Header (NSH) in Multiprotocol Label Switching = (MPLS) networks. >=20 > No, it absolutely does not. > To quote from the Abstract... >=20 > This document describes how Service Function Chaining can be = achieved > in an MPLS network by means of a logical representation of the NSH = in > an MPLS label stack. >=20 > The point of this document is exactly that it does not use the NSH. = Instead it encodes the fields of the NSH in MPLS headers. This is = crucially important because if one wanted to use the NSH in an MPLS = network one would apply RFC 8300 and draft-ietf-mpls-sfc-encapsulation. Okay, thanks for the clarification, I obviously misread what is meant by = 'a logical representation of the NSH'. >=20 >> Issues: >>=20 >> First, the document and in particular the Security Considerations = section points to published RFCs >> for discussions of the security properties. In particular, RFC7665 = and RFC8300 are referenced=20 >> however each of these documents left some significant security = descriptions & definitions to be >> addressed by implementation documents such as this one. = Additionally, the SECDIR reviews of >> the IDs prior to publication of these RFCs point out several security = related issues that, as far as >> I could tell, were primarily addressed by saying that future = implementation specifications will >> address them. Since this ID is such an implementation specification, = referring to the earlier RFCs >> for the security properties results in essentially no security = properties provided in either the=20 >> earlier RFCs or this implementation document - security properties = need to be identified avoided >> via circular references. >=20 > I think you have a good point here that, although the aspects of = security related to SFC are inherited from whatever documents the SFC WG = produces (complete with whatever flaws exist in that set of documents = that need to be patched by that WG), *this* document needs to talk about = the security of the mechanisms that it defines. >=20 > That means some discussion of the security of the MPLS forwarding = plane (with references) and some discussion about what would happen if = someone was able to tamper with a packet (noting that if someone can = successfully tamper with an MPLS packet in flight then they can do a lot = of other bad things as well). I agree, it's important for the WG to think about security aspects of = functions for each of the documents it produces. It's also important to = be able to describe how a documents' security aspects relate to the = security aspects of related other technologies, e.g., RFC5920 describes = an overall security framework - it might contain useful information = (even though it's status is Informational). =20 >=20 >> Next, the Security Considerations section identifies that the certain = elements of the design must >> be a =E2=80=98trusted resource=E2=80=99 and that some functions must = also be trusted. The term =E2=80=9Ctrusted=E2=80=9D in=20 >> relationship to computing and software has a wide range of different = meanings (as shown by >> many years of research in the CS field). In the context of this = document, my guess is that it >> means that some unidentified (but not defined) entity believes = (=E2=80=9Ctrusts=E2=80=9D) that the software >> will do the =E2=80=9Cright thing=E2=80=9D - to me (from a security = perspective) it also means trusting that the >> software will not do the wrong thing. All of this is very abstract = (both the Security=20 >> Considerations text & this critique) which in my view is why the = 'trust' section is very >> inadequate for an implementation document. >=20 > If there is an IETF security definition of "trust" that we could look = at, that would help. Are you referring to RFC4949 or another definition? 4949 might provide = a useful definition, it's worth checking to see if there=E2=80=99s = something useful there or elsewhere. >=20 > "Do the right thing" is probably not quite what we mean.=20 > I think we mean "Not act maliciously so as to wilfully break the = network or send traffic to/via the wrong places.=E2=80=9D This certainly sounds reasonable but I'm not sure where the concept is = described - I wasn't able to find it in RFC5920, RFC7665, or RFC8300. >=20 > But this is all a little like how we "trust" a router.=20 > A malign router could drop or redirect packets contrary to the routing = information it has received. We typically test for that in the lab, and = maybe watch for it in the field, but other procedures (such as checking = software images) are generally out of scope for protocol documents. I agree that this is a difficult concept to describe. Even though = protocol documents don't describe testing requirements and such, section = 14 (Implementation Notes) does lead one to think about what should be = done to implement the specification. Having some security related = implementation notes there would be helpful and appears to be consistent = with information already in the section. WRT the Security Considerations section, it would be useful to review = sections 5 - 12 of the document to identify if there are particular = structures or functions that must work correctly or the SFC design will = "fail" (for some value of "fail"). If there are specific functions or = structures that are crucial to the design, it would be appropriate to = identify them in the Security Considerations section. =20 >=20 >> Additionally, the last paragraph of the Security Considerations = section asserts: >>=20 >> Thus the security vulnerabilities are addressed (or should be >> addressed) in all the underlying technologies used by this design, >> which itself does not introduce any new security vulnerabilities. >>=20 >> As far as I could see, the assertion is not supported anywhere in the = document >> itself or other referenced documents, i.e., what vulnerabilities = should the=20 >> implementation be concerned with (e.g. passive monitoring, active = attacks >> on metadata, etc??) that result from this implementation. Since the=20= >> document does not provide a clear identification of it's security = requirement, >> any security services it does (or might) provide nor require from = underlying >> technologies, the assertion should be clarified, supported by = additional=20 >> information or removed from the section. >=20 > I *do* understand where you are coming from on this, but I'm not sure = where we go with it. >=20 > Let's consider for a moment the case of email being carried over an = MPLS network. There is a security vulnerability that passive monitoring = of MPLS packets would allow inspection of the contents of the email. = There are a number of ways to protect against this including encryption = at the application layer (i.e. of the email) and encryption at the = transport layer, and encryption at the IP layer. There is also the = possibility to encrypt the underlying transport (such as MACsec).=20 >=20 > Now, you are asking about whether this document should discuss the = security of any metadata carried in the MPLS encoding of an SFC system = (I realise this is just one example of the concerns you are raising). = And I would say that it should not. It should observe that metadata is = an SFC concept (SFC is the application using MPLS) and encryption of = that data is a function of the "SFC layer=E2=80=9D. Thanks for these examples, they do clarify how the pieces fit together = (terminology is always hard) - prior to the examples, it was not clear = that the SFC was roughly an application using MPLS. I think that this = also means that every SFC system deployment must determine their own = security requirements and how they will be met _within_ (or by) the = particular SFC system, i.e., neither MPLS nor the Service Function = Chaining provide confidentiality, integrity or other security services = often required by applications. >=20 > So maybe a bolder statement could be added to the document=E2=80=A6 I think text of this nature is much better than the current paragraph. = If my i.e. text above is correct, it should also be part of the = introductory portion (e.g., neither MPLS or SFC provide security = services application functions require). >=20 > "The MPLS forwarding plane does not include any security mechanisms. = That means that procedures described in this document rely on three = basic principles: >=20 > - The MPLS network is often considered to be a closed network such = that insertion, > Modification, or inspection of packets by an outside party is not = possible. Since RFC5920 includes InterCarrier Interconnect (ICI), that seems = difficult to assert that MPLS is a "closed network". Perhaps I'm = misinterpreting 5920 but having different/multiple carriers involved = with MPLS forwarding does not seem to be a "closed network" or perhaps = the functions defined in this document should not be used with MPLS ICI. = I do agree with the sentiment of the statement but think it needs a bit = more clarification. =20 >=20 > - The underlying transport mechanisms (such as Ethernet) between = adjacent MPLS > Nodes may offer security mechanisms that can be used to defend = packets "on the > Wire" >=20 > - The SFC-capable devices participating in the network are responsible = for verifying > And protecting packets and their contents. Would it be clearer if it read: - The SFC-capable devices participating in an SFC system are responsible = for verifying and protecting packets and their contents as well as = providing other security capabilities that might be required in the = particular system. >=20 > Deployments of any SFC system will need to consider these issues, = especially the last point. It is expected that a deployment of the = techniques defined in this document would benefit from the more general = security mechanisms defined for SFC." >=20 > Thanks, > Adrian Thank you for the prompt response, clarifications and explanations.. Russ= --Apple-Mail=_35F69572-A901-4C6E-A1DD-0B7BFFAACBFB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Jan 31, 2019, at 5:52 AM, Adrian Farrel <adrian@olddog.co.uk>= wrote:

Hi = Russ,

Hi = Adrian,


Thanks for = reviewing.

You=E2=80=99re welcome.


A few = responses ...

Summary:

This document defines = defines a methods to achieve Service Function Chaining (SFC) 
using = Network Service Header (NSH) in Multiprotocol Label Switching (MPLS) = networks.

No, it absolutely does not.
To quote from the Abstract...

  This document describes how Service Function = Chaining can be achieved
  in an MPLS network by means of a logical = representation of the NSH in
  an MPLS label stack.

The point of = this document is exactly that it does not use the NSH. Instead it = encodes the fields of the NSH in MPLS headers. This is crucially = important because if one wanted to use the NSH in an MPLS network one = would apply RFC 8300 and draft-ietf-mpls-sfc-encapsulation.

Okay, = thanks for the clarification, I obviously misread what is meant by 'a = logical representation of the NSH'.


Issues:

First, the document and in particular the Security = Considerations section points to published RFCs
for = discussions of the security properties. In particular, RFC7665 and = RFC8300 are referenced 
however each = of these documents left some significant security descriptions & = definitions to be
addressed by implementation documents = such as this one.  Additionally, the SECDIR reviews of
the IDs prior to publication of these RFCs point out several = security related issues that, as far as
I could tell, were = primarily addressed by saying that future implementation specifications = will
address them.  Since this ID is such an = implementation specification, referring to the earlier RFCs
for the security properties results in essentially no = security properties provided in either the 
earlier RFCs = or this  implementation document - security properties need to be = identified avoided
via circular references.

I think you have a good point here that, although the aspects = of security related to SFC are inherited from whatever documents the SFC = WG produces (complete with whatever flaws exist in that set of documents = that need to be patched by that WG), *this* document needs to talk about = the security of the mechanisms that it defines.

That means = some discussion of the security of the MPLS forwarding plane (with = references) and some discussion about what would happen if someone was = able to tamper with a packet (noting that if someone can successfully = tamper with an MPLS packet in flight then they can do a lot of other bad = things as well).

I agree, it's important for the WG to think = about security aspects of functions for each of the documents it = produces. It's also important to be able to describe how a documents' = security aspects relate to the security aspects of related other = technologies, e.g., RFC5920 describes an overall security framework - it = might contain useful information (even though it's status is = Informational).  


Next, the Security Considerations = section identifies that the certain elements of the design must
be a =E2=80=98trusted resource=E2=80=99 and that some = functions must also be trusted.  The term =E2=80=9Ctrusted=E2=80=9D = in 
relationship to computing and software has a wide range of = different meanings (as shown by
many years of research in = the CS field).  In the context of this document, my guess is that = it
means that some unidentified (but not defined) entity = believes (=E2=80=9Ctrusts=E2=80=9D) that the software
will = do the =E2=80=9Cright thing=E2=80=9D - to me (from a security = perspective) it also means trusting that the
software will = not do the wrong thing.  All of this is very abstract (both the = Security 
Considerations text & this critique) which in my view is = why the 'trust' section is very
inadequate for an = implementation document.

If there is = an IETF security definition of "trust" that we could look at, that would = help.

Are = you referring to RFC4949 or another definition?  4949 might provide = a useful definition, it's worth checking to see if there=E2=80=99s = something useful there or elsewhere.


"Do the right thing" is probably not quite what we mean. 
I think we = mean "Not act maliciously so as to wilfully break the network or send = traffic to/via the wrong places.=E2=80=9D
This certainly sounds reasonable but I'm not = sure where the concept is described - I wasn't able to find it in = RFC5920, RFC7665, or RFC8300.


But this is all a little like how we "trust" a router. 
A malign = router could drop or redirect packets contrary to the routing = information it has received. We typically test for that in the lab, and = maybe watch for it in the field, but other procedures (such as checking = software images) are generally out of scope for protocol = documents.

I= agree that this is a difficult concept to describe.  Even though = protocol documents don't describe testing requirements and such, section = 14 (Implementation Notes) does lead one to think about what should be = done to implement the specification.  Having some security related = implementation notes there would be helpful and appears to be consistent = with information already in the section.

WRT the Security Considerations section, it would = be useful to review sections 5 - 12 of the document to identify if there = are particular structures or functions that must work correctly or the = SFC design will "fail" (for some value of "fail"). If there are specific = functions or structures that are crucial to the design, it would be = appropriate to identify them in the Security Considerations section. =   


Additionally, the last paragraph of = the Security Considerations section asserts:

Thus the security vulnerabilities are addressed (or should = be
addressed) in all the underlying technologies used by = this design,
which itself does not introduce any new = security vulnerabilities.

As far as I could = see, the assertion is not supported anywhere in the document
itself or other referenced documents, i.e., what = vulnerabilities should the 
implementation= be concerned with (e.g. passive monitoring, active attacks
on metadata, etc??) that result from this implementation. =  Since the 
document does not provide a clear identification of it's = security requirement,
any security services it does (or = might) provide nor require from underlying
technologies, = the assertion should be clarified, supported by additional 
information = or removed from the section.

I *do* = understand where you are coming from on this, but I'm not sure where we = go with it.

Let's = consider for a moment the case of email being carried over an MPLS = network. There is a security vulnerability that passive monitoring of = MPLS packets would allow inspection of the contents of the email. There = are a number of ways to protect against this including encryption at the = application layer (i.e. of the email) and encryption at the transport = layer, and encryption at the IP layer. There is also the possibility to = encrypt the underlying transport (such as MACsec). 

Now, you are = asking about whether this document should discuss the security of any = metadata carried in the MPLS encoding of an SFC system (I realise this = is just one example of the concerns you are raising). And I would say = that it should not. It should observe that metadata is an SFC concept = (SFC is the application using MPLS) and encryption of that data is a = function of the "SFC layer=E2=80=9D.

Thanks for these examples, they do clarify how the = pieces fit together (terminology is always hard) - prior to the = examples, it was not clear that the SFC was roughly an application using = MPLS.  I think that this also means that every SFC system = deployment must determine their own security requirements and how they = will be met _within_ (or by) the particular SFC system, i.e., neither = MPLS nor the Service Function Chaining provide confidentiality, = integrity or other security services often required by = applications.


So maybe a bolder statement could be added to the = document=E2=80=A6

I think text of this nature is much better = than the current paragraph. If my i.e. text above is correct, it should = also be part of the introductory portion (e.g., neither MPLS or SFC = provide security services application functions require).


"The MPLS = forwarding plane does not include any security mechanisms. That means = that procedures described in this document rely on three basic = principles:

- The MPLS = network is often considered to be a closed network such that = insertion,
 Modification, or inspection of packets by an outside = party is not possible.

Since RFC5920 includes InterCarrier = Interconnect (ICI), that seems difficult to assert that MPLS is a = "closed network".  Perhaps I'm misinterpreting 5920 but having = different/multiple carriers involved with MPLS forwarding does not seem = to be a "closed network" or perhaps the functions defined in this = document should not be used with MPLS ICI.  I do agree with the = sentiment of the statement but think it needs a bit more = clarification.
 

- The underlying transport mechanisms (such as Ethernet) = between adjacent MPLS
  Nodes may offer security mechanisms that can be = used to defend packets "on the
  Wire"

- The SFC-capable devices participating in the network are = responsible for verifying
  And protecting packets and their = contents.

Would it be clearer if it read:
- = The SFC-capable devices participating in an SFC system are responsible = for verifying and protecting packets and their contents as well as = providing other security capabilities that might be required in the = particular system.


Deployments of any SFC system will need to consider these = issues, especially the last point. It is expected that a deployment of = the techniques defined in this document would benefit from the more = general security mechanisms defined for SFC."

Thanks,
Adrian

Thank you for the prompt response, = clarifications and explanations..

Russ
= --Apple-Mail=_35F69572-A901-4C6E-A1DD-0B7BFFAACBFB-- From nobody Fri Feb 1 14:49:20 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5526130ECE; Fri, 1 Feb 2019 14:49:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.679 X-Spam-Level: X-Spam-Status: No, score=-1.679 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.com 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 JN4ScH-Phmqe; Fri, 1 Feb 2019 14:49:10 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 670C1130EBE; Fri, 1 Feb 2019 14:49:10 -0800 (PST) Received: from [10.0.1.29] (cpe-70-122-203-106.tx.res.rr.com [70.122.203.106]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x11Mn4vv009143 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 1 Feb 2019 16:49:09 -0600 (CST) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1549061350; bh=WCNxLYN746xefMws70nLQfng0Sb1MYCQ3uiM7RZFFDc=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=eOM1xDhywwhY20BLQYpVb9TyLStwQH2FZUVODnpm/lYbhRf5PZlNiBMEph1iIV6cI sWHmM9m+XXgiBoMc1EzzJ2XkCM755R5eCokK12nb6N3PsObjVIeHCggW3RL/63loVB sERPdElc/oEi0FO9sVKey1Ps3yALJKf556U6JwBQ= X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-203-106.tx.res.rr.com [70.122.203.106] claimed to be [10.0.1.29] From: Ben Campbell Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_8B4A7818-3703-41D3-9C9D-FFB6A0D3BDEB"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Fri, 1 Feb 2019 16:49:03 -0600 In-Reply-To: <201902010742.x117gdGm030846@rumpleteazer.rhmr.com> Cc: The IESG , secdir@ietf.org, draft-ietf-rtcweb-fec.all@tools.ietf.org To: Hilarie Orman References: <201902010742.x117gdGm030846@rumpleteazer.rhmr.com> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: [secdir] Security review of draft-ietf-rtcweb-fec-08 (was Re: Security review of draft-ietf-perc-srtp-ekt-diet-08) X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2019 22:49:12 -0000 --Apple-Mail=_8B4A7818-3703-41D3-9C9D-FFB6A0D3BDEB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, Please note that this review is for draft-ietf-rtcweb-fec-08, not the = PERC draft referenced in the subject. Thanks! Ben. > On Feb 1, 2019, at 1:42 AM, Hilarie Orman = wrote: >=20 > Security Review of WebRTC Forward Error Correction Requirements > draft-ietf-rtcweb-fec-08 >=20 > Do not be alarmed. I have reviewed this document as part of the > security directorate's ongoing effort to review all IETF documents > being processed by the IESG. These comments were written primarily > for the benefit of the security area directors. Document editors and > WG chairs should treat these comments just like any other last call > comments. >=20 > The document describes the appropriate uses of FEC for web content = when > using WebRTC. It also describes how to indicate that FEC is being = used. >=20 > The Security Considerations mention the possibility of additional = network > congestion when using FEC. Although this can be a problem, I do not = think > it is a security issue, thus it does not belong in this section. >=20 > There is a security-related issue wrt to FEC and encryption. If the > error model is that message blocks may be lost but not altered in > transit, then FEC with encryption is fine. But if FEC is added for > the purpose of correcting corrupted bits in a message block, then it > is important that FEC is done after encryption. The draft seems to > ignore the issue, and it also seems to recommend a processing scheme > that would result in encryption of the FEC data. If there is a body > of practice for other IETF FEC protocols that explains these issues, > an explicit reference to it in the Security Considerations would be > very helpful. >=20 > Hilarie >=20 >=20 --Apple-Mail=_8B4A7818-3703-41D3-9C9D-FFB6A0D3BDEB Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlxUzN8ACgkQgFZKbJXz 1A1INA//Xnlm5o3yTSv3h/p1MGz5F3+i7YL24MkSB3l44KExYtlU0xbIFzDF27a0 U3IFWzu+51YC2xUC1b0/zuESrILg8D/Zeg0fItpczkOiBzetDiBFTgEe7kuZelc4 pv4k2zjcOK1OumtiHuAdiW2nfq0V6eI0apxsbCqVOWBRYLkwiggAsIXx2ONPhE3/ NbOnshLXZVV7wk+Cy6twrUly556ezUFhx49972BoTFp2AWfu1JpYT+xMF5dkPbqL cN0Ns/pRAkQIVzj6FwcCI78JOGwerBnjOhYdp4366UWWuW/1aCV6RkFvdb9AmtMU 4UDDBdNjwq7jgYv/GuyyvN19LbUxH1V2vh9orSbXxnnCPnPn2XZxxLPQUHAedrM0 ZlgQ9Q2a9XRs8e+3aqUKm7O87cV4xTcDw0858iiCXqjde+yrPCwnNiWA7YXyIHWU 2DozPxMe4Wzmafx1uKyf31S4J5eE/QYD0wULqfpDvsCzah5qXnhE2tg+l+/mTAkI d13RAi5SDq6mTUhWGUB9J5I4enyT1BBf7DrUbxTcup847I7Hozh5rbhVgD/tA440 iTBIi/CeSA7hMvaiOuCQwOnxvy1FqPLJGT+YBxtDvD21rdDYMuHnC3z942yyst1n Xlac64dcV1LTqmWnjGKzKSOw5E8sNVDyeYFvvDzZe+Eypn7Xz7w= =yHB8 -----END PGP SIGNATURE----- --Apple-Mail=_8B4A7818-3703-41D3-9C9D-FFB6A0D3BDEB-- From nobody Fri Feb 1 16:40:50 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49B3A1312DF; Fri, 1 Feb 2019 16:40:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 43VpLKXu8oTz; Fri, 1 Feb 2019 16:40:32 -0800 (PST) Received: from mail-pg1-x52b.google.com (mail-pg1-x52b.google.com [IPv6:2607:f8b0:4864:20::52b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D95B91312B9; Fri, 1 Feb 2019 16:40:28 -0800 (PST) Received: by mail-pg1-x52b.google.com with SMTP id z10so3704234pgp.7; Fri, 01 Feb 2019 16:40:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4/33flhkB2g5g3s5OE6Dk9pIHTV4ZtVQF4mlOlkcyIw=; b=HZyW3S9L9H1wQ5MH9tuvYs1BU2xnCPzbwi2WraQqfgKKuvlO/m2LeN6CVOgLH6lgTj xaoM6oQXOl42ohYPWjFdqzwFfru6zROin7V8MFyHDdDmQXko7UQxiZUm9zTAFOxvpmOQ VFvIH4GMTW5fYd64a1JTYQeW8D/M4pg3AZsFOphyTXR3G9Dyek1eKfr8ihOULyc/i5al mM5SVOfl3tl7ec9cepYUCN7p2r/shof//eZzOWLWZ9iW9ADCzmSqvS9fgmXECNAXA4F4 zpT28KtEGQcso8qblaXDPqIxjmbDrec1X7SJcUJ2VwcJFb3tp4k2jkQGH0hVQ/rGTNf5 dxtw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4/33flhkB2g5g3s5OE6Dk9pIHTV4ZtVQF4mlOlkcyIw=; b=q5pHxMEkHkqMkjboPoCGOAwfoeaPgYa2Q/b2cj5msLUzIB0PJEtfIj142StFBc+fna FrWmJelSsDYKxdX3lqbAggsiP6M028Ad0gK+CrN69ZcA5kU1NshqFmsErpOWuOGYPIiG /repdjkxuZGptZ6jzISGJRhZH0g3zW0SsYRsi4aqPwa1R35zJZUFYixvx1feGK9s8TvG 7kztvPadOuJRb2jETEsWYqY8/d3FMF9Y3UPNKAmLhL8SzOtazFoMTqLIa93Z8hoDwKOq CHCkktQn2zksUaBVO9AuVsbGTSaJZnbiKBL7oIJY97pVgHePN4Lgd+cWisavSVjOGauQ nU3A== X-Gm-Message-State: AHQUAuaCdNpxfWkLljpM4HcWpQuT+cMla7j6cWNx3FwqvjWEt9T4LqeT 7KmuQdP23wucyKBBAZKjbLIEnExQEnfQStlxmaAh7lTR X-Google-Smtp-Source: AHgI3IZbw1zapvNJ6/1yJd/Mn813XywLbDfxOFWc7zmus2nooyfDVXmbe7qHPVHUos/hV5ur9nb+zfRU6g8QQZf1Zdk= X-Received: by 2002:a65:6099:: with SMTP id t25mr135342pgu.448.1549068028305; Fri, 01 Feb 2019 16:40:28 -0800 (PST) MIME-Version: 1.0 References: <154881379920.7794.15439486195773911279@ietfa.amsl.com> In-Reply-To: <154881379920.7794.15439486195773911279@ietfa.amsl.com> From: David Schinazi Date: Sat, 2 Feb 2019 09:40:17 +0900 Message-ID: To: Sean Turner Cc: secdir@ietf.org, draft-ietf-babel-dtls.all@ietf.org, ietf@ietf.org, Babel at IETF Content-Type: multipart/alternative; boundary="0000000000008f67190580de815e" Archived-At: Subject: Re: [secdir] Secdir early review of draft-ietf-babel-dtls-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Feb 2019 00:40:41 -0000 --0000000000008f67190580de815e Content-Type: text/plain; charset="UTF-8" Thanks for the review Sean! I've updated the doc with your comments: https://github.com/jech/babel-drafts/commit/e202f664712772a4db2bd88c5665ba3193cd4c99 Detailed responses inline. David On Wed, Jan 30, 2019 at 11:03 AM Sean Turner wrote: > Reviewer: Sean Turner > Review result: Has Nits > > Hi, > > David wanted to make it really easy on me and get as much early input as he > could get by sending a msg to the TLS list asking for comments [0]. > Version > -02 addressed those comments. > > I'm no babel expert, but I did take the time to read/skim the base protocol > document to get more familiar with it as well as re-read the babel-tls > draft. > The tl;dr here is that babel is multicast but DTLS is not so changes to > babel > are needed. > To clarify, the changes to make Babel work over unicast have all gone into the base spec: draft-ietf-babel-rfc6126bis > Here are my comments in no particular order. No show stoppers here. > > 0) Since DTLS is in the RFC Editor's Abbreviations List - I think you can > get > away with: Babel Routing Protocol over DTLS But, that's up to you. > I personally prefer spelling it out, but I don't feel too strongly about it. > 1) (IEGS food fight alert) I see that the updates header updates 6126bis. > Not > sure how this will fly in the face of the draft IESG Statement [1]. > Thanks for pointing this out. We'll follow any guidance the IESG gives us during their review. > 2) (This might just be document organization) The applicability section > kind of > jumped out at me because there's also an applicability draft. Further, it > and > 6126bis says the HMAC mechanism is preferred. I'd just drop the entire > section > ;) > The authors felt we should insist that HMAC is better suited for many deployments as it better fits with the traditional Babel multicast model. The applicability draft focuses on Babel itself. > 3) s2.1 - maybe add a pointer to the IANA considerations section. > Done 4) s2.1 - Because you're doing client authentication do you need say > anything > about the type of cert, whether certificate_authorities, > signature_algorithms_cert, signature_algorithms should be sent (for 1.3 > connections)? > We've had this conversation on the Babel mailing list, and we landed on having the babel-dtls draft not define any of these, punting that to the usage profiles drafts. For example, the Babel Homenet profile draft will define all of these. > 5) s4 - add that IANA is requested to point to this specification for the > reference. > Done 6) AppA - I think you might need to tweak the last sentence in light 1.3? > Unfortunately DTLS 1.3 hasn't been published yet, and I'd rather not make assumptions on what the RFC will say (even though we're pretty sure the handshake won't change between the current draft and RFC). If it gets published as RFC before this document does, I'll make these changes. Cheers, > spt > > [0] https://mailarchive.ietf.org/arch/msg/tls/tIaK0rgm5zCVuYmLm5qsCIvKXKw > [1] https://mailarchive.ietf.org/arch/msg/ietf/-1u_1-peHKAmUDuLyGAJYu0fPCE > > --0000000000008f67190580de815e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for the revi= ew Sean!

I've updated the doc with your commen= ts:

<= div>Detailed responses inline.

David

On Wed, Jan 30, 2019= at 11:03 AM Sean Turner <sean@sn3rd.c= om> wrote:
draf= t-ietf-babel-rfc6126bis
=C2=A0
Here are my comments in no particular order.=C2=A0 No show stoppers here.
0) Since DTLS is in the RFC Editor's Abbreviations List - I think you c= an get
away with: Babel Routing Protocol over DTLS But, that's up to you.
<= /blockquote>

I personally prefer spelling it out, but I = don't feel too strongly about it.
=C2=A0
1) (IEGS food fight alert) I see that the updates header updates 6126bis.= =C2=A0 Not
sure how this will fly in the face of the draft IESG Statement [1].

Thanks for pointing this out. We'll follow= any guidance the IESG gives us
during their review.
= =C2=A0
2) (This might just be document organization) The applicability section kin= d of
jumped out at me because there's also an applicability draft.=C2=A0 Fur= ther, it and
6126bis says the HMAC mechanism is preferred.=C2=A0 I'd just drop the e= ntire section
;)

The authors felt we should insist th= at HMAC is better suited for many deployments
as it better fits w= ith the traditional Babel multicast model. The applicability draft
focuses on Babel itself.
=C2=A0
3) s2.1 - maybe add a pointer to the IANA considerations section.

Done

4) s2.1 - Because you're doing client authentication do you need say an= ything
about the type of cert, whether certificate_authorities,
signature_algorithms_cert, signature_algorithms should be sent (for 1.3
connections)?

We've had this conver= sation on the Babel mailing list, and we landed on having the
bab= el-dtls draft not define any of these, punting that to the usage profiles d= rafts.
For example, the Babel Homenet profile draft will define a= ll of these.
=C2=A0
5) s4 - add that IANA is requested to point to this specification for the reference.

Done=C2=A0

6) AppA - I think you might need to tweak the last sentence in light 1.3?

Unfortunately DTLS 1.3 hasn't been p= ublished yet, and I'd rather not make
assumptions on what the= RFC will say (even though we're pretty sure the
handshake wo= n't change between the current draft and RFC). If it gets
pub= lished as RFC before this document does, I'll make these changes.
=
=C2=A0

Cheers,
spt

[0] https://mailarchive.ietf.or= g/arch/msg/tls/tIaK0rgm5zCVuYmLm5qsCIvKXKw
[1] https://mailarchive.ietf.o= rg/arch/msg/ietf/-1u_1-peHKAmUDuLyGAJYu0fPCE

--0000000000008f67190580de815e-- From nobody Fri Feb 1 17:18:15 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC893131036; Fri, 1 Feb 2019 17:17:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 jY5Mhhsir55K; Fri, 1 Feb 2019 17:17:57 -0800 (PST) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 459DB131032; Fri, 1 Feb 2019 17:17:57 -0800 (PST) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id x121HnD6012907 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 2 Feb 2019 02:17:49 +0100 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/82085) with ESMTP id x121HosV013062; Sat, 2 Feb 2019 02:17:50 +0100 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 80EDC2E1F8; Sat, 2 Feb 2019 02:17:54 +0100 (CET) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id JQeVhys0zzL5; Sat, 2 Feb 2019 02:17:52 +0100 (CET) Received: from pirx.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 4860E2E1F5; Sat, 2 Feb 2019 02:17:52 +0100 (CET) Date: Sat, 02 Feb 2019 02:17:52 +0100 Message-ID: <87imy3c7jz.wl-jch@irif.fr> From: Juliusz Chroboczek To: David Schinazi Cc: Sean Turner , secdir@ietf.org, draft-ietf-babel-dtls.all@ietf.org, ietf@ietf.org, Babel at IETF In-Reply-To: References: <154881379920.7794.15439486195773911279@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Sat, 02 Feb 2019 02:17:49 +0100 (CET) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Sat, 02 Feb 2019 02:17:51 +0100 (CET) X-Miltered: at korolev with ID 5C54EFBD.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5C54EFBE.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5C54EFBD.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5C54EFBE.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5C54EFBD.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5C54EFBE.000 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: Subject: Re: [secdir] Secdir early review of draft-ietf-babel-dtls-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Feb 2019 01:18:00 -0000 > 6) AppA - I think you might need to tweak the last sentence in light 1.3? > Unfortunately DTLS 1.3 hasn't been published yet, May I most humbly request an explanation? Is that about TLS False Start being made obsolete by TLS 1.3? (Note that I'm not particularly convinced about this paragraph, since I don't think that paying one extra RTT at neighbour acquisition is at all prohibitive.) -- Juliusz From nobody Fri Feb 1 17:24:39 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DAFC130EF5; Fri, 1 Feb 2019 17:24:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 BoW_5dq7JvqW; Fri, 1 Feb 2019 17:24:23 -0800 (PST) Received: from mail-pg1-x534.google.com (mail-pg1-x534.google.com [IPv6:2607:f8b0:4864:20::534]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A518130DC9; Fri, 1 Feb 2019 17:24:22 -0800 (PST) Received: by mail-pg1-x534.google.com with SMTP id n2so3749029pgm.3; Fri, 01 Feb 2019 17:24:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=F2nQtUYpicaP94GEXAOVE8GjcZev6wnmMH2jLA2hPzk=; b=RXJ2T1+Qn44lYKSRogl41bvRTJzL5x05QPe+Wm1TJd6WjKZq+e9XOWINzheyLjy0F1 kqe22SmRS1vR3+vBgQvmylsGx6kaNAjy8z13PIVcDm92/+6NUa/Knv8YrxDSsCA97fSV 2kVvu3z43wBi6FG0d3PU14NyynYODGASuzr45WzCqSu6EiSUghWsqQ8+frw+9O9alcXl sSy8QmN9Yni9wddNJxe2dZ32jq6K5r8/So7j8AKVWVwthGSdV0TV0wtnDAigDnLrO0Ug UVPYt8L4RRaLT8kIlMf7TBwSZp35an9k73zLLaNMOW4t6QNzDHmfI87PpLgT1yKeOqFf 9FOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=F2nQtUYpicaP94GEXAOVE8GjcZev6wnmMH2jLA2hPzk=; b=rj1Yzpu3Xy7K5WtQFT+AL+X0Mg7gCUMgArDru1R53O3Y5WErHZM25CuyEaX9r2gpd4 HZn5SwLG4IHOGVEMqSYgENNlC8RjlnqC5SzBCYEB29JiteNlFUgEqT/vXHTkK4MisOAv iDm5CbIc2p2wmpeDT4nwKPBRmbDvIpjw4heCwSA+ocVRKrnD/sdMA9wdRDD8IKluDhBw HuvoN6itluXHz9mWnczoXwFUsb0gzF5uS6qEeVXHrM5ZHQ+Cai9x64j14aGGoJVlcBR1 zWhBlmxuJpmVaag7HfbxBqcbXd+gInA4jHcExP+u90VE7p+mpS3Aw3kFNQxVktPf5fBQ siQQ== X-Gm-Message-State: AJcUukckCMlddKd8ck4tJzufqB5EkkPSMlYlnSOiSfVIpaYhejXOrFE2 ssM+tRL7pjFWZy6CMTDnOyLSJ7Zw52UM8GVbKwg= X-Google-Smtp-Source: ALg8bN7Gfp4RRMHP4T2CW7z6+XbnQmwdkrzft7eZ7mejl69DfW1SlHCwX2NAi3aishpUtPlOThHZdsfA4VfPRMrVmdY= X-Received: by 2002:a63:7e1a:: with SMTP id z26mr36969896pgc.216.1549070661774; Fri, 01 Feb 2019 17:24:21 -0800 (PST) MIME-Version: 1.0 References: <154881379920.7794.15439486195773911279@ietfa.amsl.com> <87imy3c7jz.wl-jch@irif.fr> In-Reply-To: <87imy3c7jz.wl-jch@irif.fr> From: David Schinazi Date: Sat, 2 Feb 2019 10:24:10 +0900 Message-ID: To: Juliusz Chroboczek Cc: Sean Turner , secdir@ietf.org, draft-ietf-babel-dtls.all@ietf.org, ietf@ietf.org, Babel at IETF Content-Type: multipart/alternative; boundary="0000000000008715df0580df1e2b" Archived-At: Subject: Re: [secdir] Secdir early review of draft-ietf-babel-dtls-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Feb 2019 01:24:25 -0000 --0000000000008715df0580df1e2b Content-Type: text/plain; charset="UTF-8" Hi Juliusz, TLS 1.3 changed the handshake, making false start irrelevant. In 1.3, the first flight of server-client packets contains the Finished message, so there is no opportunity to start early as there is in 1.2. https://tools.ietf.org/html/rfc6347#section-4.2.4 https://tools.ietf.org/html/draft-ietf-tls-dtls13-30#section-5.6 David On Sat, Feb 2, 2019 at 10:17 AM Juliusz Chroboczek wrote: > > 6) AppA - I think you might need to tweak the last sentence in light > 1.3? > > > Unfortunately DTLS 1.3 hasn't been published yet, > > May I most humbly request an explanation? Is that about TLS False Start > being made obsolete by TLS 1.3? > > (Note that I'm not particularly convinced about this paragraph, since > I don't think that paying one extra RTT at neighbour acquisition is at all > prohibitive.) > > -- Juliusz > --0000000000008715df0580df1e2b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Juliusz,

TLS 1.3 changed the handshake, making false start irrelevant.
<= div>In 1.3, the first flight of server-client packets contains the Finished= message,
so there is no opportunity to start early as there is i= n 1.2.


David

On Sat, Feb 2, 2019 at 10:17 AM Juli= usz Chroboczek <jch@irif.fr> wrote= :
>=C2=A0 =C2= =A0 =C2=A06) AppA - I think you might need to tweak the last sentence in li= ght 1.3?

> Unfortunately DTLS 1.3 hasn't been published yet,

May I most humbly request an explanation?=C2=A0 Is that about TLS False Sta= rt
being made obsolete by TLS 1.3?

(Note that I'm not particularly convinced about this paragraph, since I don't think that paying one extra RTT at neighbour acquisition is at = all
prohibitive.)

-- Juliusz
--0000000000008715df0580df1e2b-- From nobody Fri Feb 1 20:02:20 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DC09130EB8; Fri, 1 Feb 2019 20:02:06 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Sandra Murphy To: Cc: ccamp@ietf.org, ietf@ietf.org, draft-ietf-ccamp-rsvp-te-bandwidth-availability.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.90.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154908012600.28521.5714645741731093529@ietfa.amsl.com> Date: Fri, 01 Feb 2019 20:02:06 -0800 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-ccamp-rsvp-te-bandwidth-availability-13 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Feb 2019 04:02:06 -0000 Reviewer: Sandra Murphy Review result: Has Issues I have reviewed this document draft-ietf-ccamp-rsvp-te-bandwidth-availability as part of the security directorate’s ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This draft provides a new TLV for the Ethernet SENDER_TSPEC object that will carry availability requirements for RSVP-TE signaling of GMPLS LSPs. The draft is thorough. I do have some comments. I reviewed the normative references RFCs 2205, 3209, 3473, 6003, as well as RFC3945 and RFC5920. I can’t claim that I understood everything in that stack, so the following could easily be wrong. Computing the LSP path: Page 4, section 2 discusses obtaining network topology, calculating the LSP route, RFC8330’s extensions for availability in OSPF TE LSA messages. Does this draft assume that this extension will always be used with an EXPLICIT_ROUTE object? Is this draft not applicable without that explicit LSP route calculation? Availability TLV vs CLASSTYPE objects: The definition in RFC6003 of the Bandwidth Profile TLV has certain constraints on the values of the Index: The Index field value MUST correspond to at least one of the Class-Type values included either in the CLASSTYPE object [RFC4124] or in the EXTENDED_CLASSTYPE object [MCOS]. I am not certain if this means that the presence of an Ethernet SENDER_TSPEC Object with a Bandwidth Profile TLV means there must be a CLASSTYPE object in the RSVP-TE message as well, or that the Index field values are taken from the set of defined Class-Type values. But if the first, does this induce requirements by inclusion of the Availability TLV that these other CLASSTYPE objects must be included as well? Or are you intending to update RFC6003 to eliminate that constraint? If the second, does the RFC6003 constraint also constrain the index values used in the Availability TLV? Should that be mentioned? (Or am I just confused?) Bandwidth TLV to Availability TLV association: Page 4, Section 3.1 says When the Availability TLV is included, it MUST be present along with the Ethernet Bandwidth Profile TLV. If the bandwidth requirements in the multiple Ethernet Bandwidth Profile TLVs have different Availability requirements, multiple Availability TLVs SHOULD be carried. In such a case, the Availability TLV has a one to one correspondence with the Ethernet Bandwidth Profile TLV by having the same value of Index field. If all the bandwidth requirements in the Ethernet Bandwidth Profile have the same Availability requirement, one Availability TLV SHOULD be carried. In this case, the Index field is set to 0. I find that the description is not clear in all cases. I found a message in the working group discussion of this association that the association is either “n:n” or “n:1”. I think this description sounds more like n 1:1 associations or a n:1 association. Is that what is intended? Can the associations be mixed in the same message? Suppose there were 3 Bandwidth TLVs that needed the same availability and one that had a different availability need, could there be 3 Bandwidth TLVs with index 0 and one Availability-TLV with index 0 and also a Bandwidth TLVs - Availability TLV pair with matching index values? error checking: Other documents in the references (RFC2205, 3209, 3473, 6003, etc) have made a point of explicitly describing the error handling - when PathErr and ResvErr and Notify messages are sent, to whom, the error codes, the error value sub-codes, etc. I don’t see that here for the bandwidth-tlv-to-availability-tlv associations. Is a mix of index-zero and index-non-zero bandwidth-tlv-to-availability-tlv associations (like above) an error? is the message dropped? is an error sent? if the message is not dropped, are any of the bandwidth-tlv, availability-tlv associations retained? If there are availability-tlvs with non-zero indexes with no matching index value among the bandwidth-tlvs, that surely is an error? Is the message dropped? Or is the availability tlv dropped? Is a PathErr/ResvErr message sent? Suppose all availability-tlvs have a matching (zero or non-zero) index value among the bandwidth-tlvs, but there are extra bandwidth-tlvs (no availability-tlv with a matching index value). Is that an error? Are the extra bandwidth-tlvs dropped? ignored? propagated? (RFC3209 has several cases where there might be extra objects or sub-objects and the language is “can be/MAY be/SHOULD be/are ignored and SHOULD NOT be /are not/need not be propagated” ) multiplicity: RFC3209 says it does not apply to multicast, but it does talk about multiple parallel LSP tunnels between two nodes, and about multipoint-to-point LSPs for WF and SE style reservations when there are multiple senders, and about the merging rules of WF reservations. Does availability work in those style reservations? availability vs “variable discrete bandwidth”: I believe I understood the discussion of the need to signal availability requirements in order for the system to determine when an LSP was feasible. I can dimly understand that there might be links have “variable discrete bandwidth”. Section 2 says “The Availability TLV can be applicable to any kind of physical links with variable discrete bandwidth, such as microwave or DSL.” Why not other link types? Do only “variable discrete bandwidth” links support availability? calculating availability: In page 9, Appendix A: Perhaps I don’t understand how the availability metric is used. In the following: On a sunny day, the modulation level 3 can be used to achieve 400 Mbps link bandwidth. A light rain with X mm/h rate triggers the system to change the modulation level from level 3 to level 2, with bandwidth changing from 400 Mbps to 200 Mbps. The probability of X mm/h rain in the local area is 52 minutes in a year. Then the dropped 200 Mbps bandwidth has 99.99% availability. I would say that the 400Mbps bandwidth is available whenever it is not raining. It lightly rains 52 min year, which means it is not raining 99.99% of the time, so the 400Mbps availability is 99.99%. The 200Mbps is available during that 52 min, so 99.99% is not the 200Mbps availability. Right? The analogous comment applies to the next two paragraphs. Does that explain why the table shows the 100Mbps bandwidth having two different availabilities? security: The draft (*) security consideration points to RSVP-TE, but without an RFC reference, and to RFC5920. Because this is a GMPLS related feature, it should refer to the GMPLS extensions to RSVP-TE in RFC3473. As an extension to RFC6003, it could refer to that RFC’s security considerations section, but that only gets the reader to RFC3473, RFC3209, and RFC5920. The security considerations for RSVP-TE itself (RFC3209) points to RFC2205. RFC2205 defines an Integrity object (defined in RFC2747) that carries a keyed cryptographic digest based on a shared key, providing hop-by-hop protection between two RSVP nodes. However, PATH messages are directed toward the traffic destination address, not the next RSVP node. There could be clouds of non-RSVP nodes between two RSVP nodes that the PATH encounters. This makes it difficult to share a key between individual pairs of RSVP nodes, and could motivate operators to configure the same key in large numbers of RSVP nodes. RFC3473 points to RFC2747’s protection of RSVP messages. It also notes that it introduces a Notify message that is not sent to the traffic destination address but instead to a node that requested notification. One transmission option is that the NOTIFY is encapsulated in an IP packet and forwarded directly to the requesting node. That complicates the Integrity object protection, unless the shared key is widely shared. RFC3945 notes that authentication in GMPLS systems may use the authentication mechanisms of the component protocols, pointing to RFC2747 (as well as others for LDP, LMP, etc that don’t apply here). RFC5920 discusses threats, attacks, and protections for MPLS/GMPLS data and control planes. Section 7.1.2 in particular talks about “Control-Plane Protection with RSVP-TE”, and could be mentioned here explicitly. It talks about network border configuration to limit external attacks, and mentions RFC2747 authentication protections, making some of the same points about non-RSVP clouds and shared keys configuration. It also points to RFC4230, which is a very detailed look at RSVP security, and probably deserves to be mentioned here. So all told, at the end of all the reference chains, the only defined authentication and integrity protection in 2205, 3209, and 3473 is based on shared keys that are very difficult to configure with fine granularity. However, as was said in reply to a different MPLS related draft review yesterday: The MPLS network is often considered to be a closed network such that insertion, modification, or inspection of packets by an outside party is not possible. So maybe that is accepted as sufficient in deployment. MPLS documents are also typically granted an exception from more rigorous security requirements because MPLS is used only within one routing domain / ISP / provider / etc, under a single administrative control, so errors made would not be global in impact. In particular, errors that might result from one legitimate but faulty/mis-configured/subverted/malicious MPLS node should not propagate out to the general Internet. (**) Nits: floating numbers Page 5, Section 3.1, says “a 32-bit floating number”. I believe you mean a floating-point number. I checked other IETF RFCs (e.g., RFC8330), and it is common to mention the IEEE 754-2008 standard when including a floating point value in the spec. But is a floating point value needed? The draft says that the values are typically in a small set of known values. The intro sounds like a small set of classes are used for “efficient planning”. Just curious. OTOH, RFC8330 uses floating point, and the ITU documents’ calculation of availability make it seem like full floating point is needed. the Availability TLV format: page 5, section 3.1 says: The Availability TLV has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Index | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Availability | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Availability TLV I presume that this is just the Value portion of the TLV format that is defined for the Ethernet SENDER_TSPEC Object in Section 4 of RFC6003. Page 1, Abstract: typically used for describing these links when during network planning “when during” - is that deliberate? It sounds redundant, maybe due to editing. Or maybe it was supposed to be “when doing”? signaling. This extension can be used to set up a Generalized Multi- Protocol Label Switching (GMPLS) Label Switched Path (LSP) using the Ethernet SENDER_TSPEC object. not sure - what is using the SENDER_TSPEC - the LSP or this extension? Page 3, Section 1: bandwidth availability. For example, the bandwidth with 99.999% availability of a link is 100 Mbps; the bandwidth with 99.99% availability is 200 Mbps. maybe: bandwidth availability. Suppose, for example, the bandwidth with 99.999% Page 5, section 3.2: TLVs and one or more Availability TLVs. Each Ethernet Bandwidth Profile TLV corresponds to an availability parameter in the Availability TLV. … “in an Availability TLV”? or “in the associated Availability TLV”? There’s more than one. Page 6, section 3.2 link), it SHOULD reserve the bandwidth resource from each “it” -> “the node” this LSP. Optionally, the higher availability bandwidth can be “the higher” -> “a higher” (there’s more than one, right?) request cannot be satisfied, it SHOULD generate PathErr message “it” -> “the node” generate PathErr message with the error code "Extended Class-Type “PathErr” -> “a PathErr” or “PathErr messages” postscripts: (**) [[[ I will note that RFC3209 includes an AS number subject among the subobjects of the EXPLICIT_ROUTE object. With the idea that you might set up explicit routes that go through multiple ASNs. Ouch. I know there are providers who have different ASNs under single administrative control, from acquisitions or business use cases, but this just makes it possible for an explicit route for an LSP to be misconfigured to include your (external) neighbor ASN. And RFC5920 talks about “ASBR-ASBR communication for inter-AS LSPs”. Better have good outbound filters on your border routers. ]]] (*)As is typical for specifications that extend other published RFCs, this draft says it “does not introduce any new security considerations”. In general, I am skeptical of extension drafts that make such claims. Surely the existing security considerations should be examined to see how they apply to this new feature or object being introduced? Do current protections adequately protect the new feature/object? Does the new feature/object carry new information, produce new behaviors? etc. But this is so very common I could hardly request that more be said here. Just saying. From nobody Sat Feb 2 11:44:19 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F10E12F18C; Sat, 2 Feb 2019 11:44:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=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 SjJ7W7gisyZ6; Sat, 2 Feb 2019 11:44:08 -0800 (PST) Received: from Mail1.Yoyodyne.COM (mail1.yoyodyne.com [IPv6:2604:4ec0:3::7]) by ietfa.amsl.com (Postfix) with SMTP id C0BB112E7C1; Sat, 2 Feb 2019 11:44:08 -0800 (PST) Received: from [10.0.4.30] ([24.5.60.91]) by Mail1.Yoyodyne.COM via Internet for (and others); Sat, 2 Feb 2019 11:44:08 PST From: Derrell Piper Content-Type: multipart/signed; boundary="Apple-Mail=_F14ED133-598B-4153-8B1B-9C11B8E31E1B"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Message-Id: Date: Sat, 2 Feb 2019 11:44:07 -0800 To: draft-hollenbeck-vcarddav-icann-rdap-extensions-00.all@ietf.org, secdir@ietf.org, ietf@ietf.org X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: [secdir] draft-hollenbeck-vcarddav-icann-rdap-extensions-00 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Feb 2019 19:44:11 -0000 --Apple-Mail=_F14ED133-598B-4153-8B1B-9C11B8E31E1B Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Reviewer: Derrell Piper Summary: Ready I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Summary This draft defines one new vCard extension property (CONTACT-URI) and one new vCard extension parameter (CC) for the purpose of satisfying an ICANN requirement. It is a simple extension to vCard to specify a two letter ISO 3166 country code (CC) to specify gTLD registration data. It does not appear to be security relevant. Related documents: vCard [RFC6350], RDAP [RFC7483] --Apple-Mail=_F14ED133-598B-4153-8B1B-9C11B8E31E1B Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCCkkw ggTpMIID0aADAgECAgRMDowbMA0GCSqGSIb3DQEBCwUAMIG0MRQwEgYDVQQKEwtFbnRydXN0Lm5l dDFAMD4GA1UECxQ3d3d3LmVudHJ1c3QubmV0L0NQU18yMDQ4IGluY29ycC4gYnkgcmVmLiAobGlt aXRzIGxpYWIuKTElMCMGA1UECxMcKGMpIDE5OTkgRW50cnVzdC5uZXQgTGltaXRlZDEzMDEGA1UE AxMqRW50cnVzdC5uZXQgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgKDIwNDgpMB4XDTExMTExMTE1 MjU1MVoXDTIxMTExMTIzMjc1MFowgaUxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1FbnRydXN0LCBJ bmMuMTkwNwYDVQQLEzB3d3cuZW50cnVzdC5uZXQvQ1BTIGlzIGluY29ycG9yYXRlZCBieSByZWZl cmVuY2UxHzAdBgNVBAsTFihjKSAyMDEwIEVudHJ1c3QsIEluYy4xIjAgBgNVBAMTGUVudHJ1c3Qg Q2xhc3MgMSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCpYPyALmJw k4z2GWJLrTZYlw5O/p2PAC4//myCDUGGIyPWk82D/o9D4eLrbSgbEbsB+uuATnNe3lrFqjozsYve eNIk+9EUvZRNkl+YNFn/2IY2HHe4YWJWWPuAVQ8DKYR96NCzpt/1Irgkv+QDrHksTX5aqBIPAfjN EJPPLRyzdGuH277CsWcjDujjxxDFAzi3yAVFoIvsJBXdyxw4X2aZCLP315HcX5cHYtxBnI7RxjX2 U6d3rmgUNaRnEz5JjW6+nyCjn6h3Gbw4u1XTYM6g/q+33EwZmpNz6Je+BT9/d/JppfedXvTg+A6w Ivs+qDYabkTEj6Rq1baljNyc87AHAgMBAAGjggEOMIIBCjAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0T AQH/BAgwBgEB/wIBADAzBggrBgEFBQcBAQQnMCUwIwYIKwYBBQUHMAGGF2h0dHA6Ly9vY3NwLmVu dHJ1c3QubmV0MDIGA1UdHwQrMCkwJ6AloCOGIWh0dHA6Ly9jcmwuZW50cnVzdC5uZXQvMjA0OGNh LmNybDA7BgNVHSAENDAyMDAGBFUdIAAwKDAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5lbnRydXN0 Lm5ldC9ycGEwHQYDVR0OBBYEFEeQpKEKQyC/0HRUuJT6xHu1thwFMB8GA1UdIwQYMBaAFFXkgdER gL7YibkIozH5oSQJFrlwMA0GCSqGSIb3DQEBCwUAA4IBAQBRNMJxm4DOQpk8ZWRM0mdOp4ztTrBK BziTwUc5VbZR0WIBIGejvX4gL5Rhj8Y3/xbcABb9RUBAfkGHHIxhIyf12Jj9JTA7oavzcvrNMJ20 wrbKtOLFeUu0cFCRuxdhT0dWMJ0Z3g8bPbWd7Gu7hjIYZ5/Fhc/Hw3duZwZ1t0CpyLtuhIhJhaSO Zez4sXqT0VvgLb0AXWhWd9zzoHrnx23FqW620NhJlH6CTDbMH+JptP6NT5Xr/uGFFJhkVnYDhHx6 wMjd4KBhnYvnbYbSdamln6CWcEXVwBk2ioUtrIHjYEFYxEd7jqvZEtAu20Z5KHvMK67Tgqp0Cqgy kXqbEa+bMIIFWDCCBECgAwIBAgIQEd9X2KIWvBwAAAAATDO9SzANBgkqhkiG9w0BAQsFADCBpTEL MAkGA1UEBhMCVVMxFjAUBgNVBAoTDUVudHJ1c3QsIEluYy4xOTA3BgNVBAsTMHd3dy5lbnRydXN0 Lm5ldC9DUFMgaXMgaW5jb3Jwb3JhdGVkIGJ5IHJlZmVyZW5jZTEfMB0GA1UECxMWKGMpIDIwMTAg RW50cnVzdCwgSW5jLjEiMCAGA1UEAxMZRW50cnVzdCBDbGFzcyAxIENsaWVudCBDQTAeFw0xODEx MTMyMjAxMzBaFw0xOTExMTMyMjMxMjdaMIGfMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0 ZWQxNzA1BgNVBAsTLkVudHJ1c3QgQ2xhc3MgMSBJZGVudGl0eSBDZXJ0aWZpY2F0aW9uIFNlcnZp Y2UxHjAcBgNVBAMMFWRkcEBlbGVjdHJpYy1sb2Z0Lm9yZzEkMCIGCSqGSIb3DQEJARYVZGRwQGVs ZWN0cmljLWxvZnQub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA04HrzV6j2isr QECHjetWFZ771HycrJfmWjXghDOMbHhotvv+Fget4HTze2EPnMtcSxT36MILnmpEDhzXZzMHnom6 M6eqo7QK17Mn1bE9oeOeNiCH0LbHwuqpYQ0EgXul5wwngHN5asgabILySG0ecF+Utuf7+yH8+Ufc OMlLe0MRONJhNCeeGDZiRkG5TrysslzBw/KsGE5w9/DIrPLDZZB1XK2hbmq8RusV9UYPB9zZhETo IOrdaoo0yIDa3e7o8RkmU3cjQxbksNmEuw0lKEnPMmku6vpXgYk/y0TmFmyoyt6hjl8SNWjVMWDs ZQS5Jh/68alzEtidEkxF0KHIwQIDAQABo4IBhjCCAYIwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQW MBQGCCsGAQUFBwMCBggrBgEFBQcDBDBCBgNVHSAEOzA5MDcGC2CGSAGG+mwKAQQBMCgwJgYIKwYB BQUHAgEWGmh0dHA6Ly93d3cuZW50cnVzdC5uZXQvcnBhMDQGA1UdHwQtMCswKaAnoCWGI2h0dHA6 Ly9jcmwuZW50cnVzdC5uZXQvY2xhc3MxY2EuY3JsMGoGCCsGAQUFBwEBBF4wXDAjBggrBgEFBQcw AYYXaHR0cDovL29jc3AuZW50cnVzdC5uZXQwNQYIKwYBBQUHMAKGKWh0dHA6Ly9haWEuZW50cnVz dC5uZXQvMjA0OGNsYXNzMXNoYTIuY2VyMCAGA1UdEQQZMBeBFWRkcEBlbGVjdHJpYy1sb2Z0Lm9y ZzAfBgNVHSMEGDAWgBRHkKShCkMgv9B0VLiU+sR7tbYcBTAdBgNVHQ4EFgQU+J5uDdWXcSluFwxv Z2FeWBJX+HYwCQYDVR0TBAIwADANBgkqhkiG9w0BAQsFAAOCAQEAA5tIRug94hPDaWBEb9Tl/poX gTZjtCtVStEvz7Rs0FL6OqoeBJZhvyrgCvHbIzqMP+VU+7aLs+1DSSkekaCKj80bYFpZ+4qqpZHz AWy80jVdu+N8+GW9zKXNEcOEa3Fm8Wpl2P3agIRygKxAAa/gvqd263C7VeYaS0JX85a/dR1BItHP D/3F4Pe36QO7Te1/EXv+CScdAHR84grEtX6rwGFqzipUBAR2UfpTyBk422X+6t63nUT5FK5xYPgL 0SPHct0cvEosPGaDprzHBfVJQHVvgj0XC2b8zHy/g6tiboB2o0x/x4JQnA1+Yr1dtOmPpTPqeud6 tturBV8skRB2yDGCA/EwggPtAgEBMIG6MIGlMQswCQYDVQQGEwJVUzEWMBQGA1UEChMNRW50cnVz dCwgSW5jLjE5MDcGA1UECxMwd3d3LmVudHJ1c3QubmV0L0NQUyBpcyBpbmNvcnBvcmF0ZWQgYnkg cmVmZXJlbmNlMR8wHQYDVQQLExYoYykgMjAxMCBFbnRydXN0LCBJbmMuMSIwIAYDVQQDExlFbnRy dXN0IENsYXNzIDEgQ2xpZW50IENBAhAR31fYoha8HAAAAABMM71LMA0GCWCGSAFlAwQCAQUAoIIC BzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xOTAyMDIxOTQ0MDha MC8GCSqGSIb3DQEJBDEiBCBEAyDlMYhFTLGNwuSUOMCvUVOxCAKUxDawKual1+1c3TCBywYJKwYB BAGCNxAEMYG9MIG6MIGlMQswCQYDVQQGEwJVUzEWMBQGA1UEChMNRW50cnVzdCwgSW5jLjE5MDcG A1UECxMwd3d3LmVudHJ1c3QubmV0L0NQUyBpcyBpbmNvcnBvcmF0ZWQgYnkgcmVmZXJlbmNlMR8w HQYDVQQLExYoYykgMjAxMCBFbnRydXN0LCBJbmMuMSIwIAYDVQQDExlFbnRydXN0IENsYXNzIDEg Q2xpZW50IENBAhAR31fYoha8HAAAAABMM71LMIHNBgsqhkiG9w0BCRACCzGBvaCBujCBpTELMAkG A1UEBhMCVVMxFjAUBgNVBAoTDUVudHJ1c3QsIEluYy4xOTA3BgNVBAsTMHd3dy5lbnRydXN0Lm5l dC9DUFMgaXMgaW5jb3Jwb3JhdGVkIGJ5IHJlZmVyZW5jZTEfMB0GA1UECxMWKGMpIDIwMTAgRW50 cnVzdCwgSW5jLjEiMCAGA1UEAxMZRW50cnVzdCBDbGFzcyAxIENsaWVudCBDQQIQEd9X2KIWvBwA AAAATDO9SzANBgkqhkiG9w0BAQEFAASCAQBjY+fphojkNxHQypYj+k5vnm7fqDP4Uw/eOTaibZzq GPDAuowVk0/WfMA6co8fFSJVJ4WtLMWzkOLxIsJQh6MQbOF+445UcR6yPqsie6eV5spxJKy3k6HO +kgWTlAnF5aGyypg9WjyhdjA+agIsBN6Kz6c5QVMXzs3xi8OY8rbMNAB1GPjbnLTD5Oypidxc4Qf F22rfShsmZw9ODAE682/9Luv7c6QwpmEA6DOHXn4/5MYaRFP3zJ76f6wZC/O1Mn6hwD+5ONPpBk7 /utaYQdcShBW+3PbTQE7qgcS73LPY0mC1t1RWhg5g9xYmGW6Wf99PHvnGQOuwcJm2vUbYQpuAAAA AAAA --Apple-Mail=_F14ED133-598B-4153-8B1B-9C11B8E31E1B-- From nobody Mon Feb 4 12:51:16 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EF69126DBF; Mon, 4 Feb 2019 12:51:01 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Rifaat Shekh-Yusef To: Cc: ietf@ietf.org, pim@ietf.org, draft-ietf-pim-igmp-mld-yang.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.91.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154931346123.28775.11015526210421953472@ietfa.amsl.com> Date: Mon, 04 Feb 2019 12:51:01 -0800 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-pim-igmp-mld-yang-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2019 20:51:01 -0000 Reviewer: Rifaat Shekh-Yusef Review result: Ready I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The summary of the review is Ready This document defines a YANG data model that can be used to configure and manage Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) devices. The security consideration section seems to follow a well defined template for new YANG modules, and lists sensitive subtrees and data nodes accordingly. Regards, Rifaat From nobody Mon Feb 4 15:31:10 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF53A129A87; Mon, 4 Feb 2019 15:31:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=ZuOSktIy; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=i43yfQ/O 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 wwxWFoHXRlNv; Mon, 4 Feb 2019 15:30:58 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7353A1294FA; Mon, 4 Feb 2019 15:30:55 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 7707F21F85; Mon, 4 Feb 2019 18:30:54 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Mon, 04 Feb 2019 18:30:54 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm1; bh=c bgrPwFVadIjhe8NKE8Mn7wWY+AaF8p+g6Jy6EIxwb4=; b=ZuOSktIy1NGeARg+8 fspt5+pGUkj8LCgnVGIfQswPfwRjXgSJAg0/LOgkdnlmO3uH2T5fyaWWgfuhcUh4 /nzJcmlDX02pRy3PkKv0XS7aedt7LaFC9CTUdhCkthxXjZHwCLdFARZek0MIDSVJ dgiyJCfEMfw5EsmCYwwgr5CJ1DqFa0FhYe+xWZmEJ1pZR0BH5bGFHPTeqakBC6XU BtfCp4tkMTr3HFhSr+C9r+gEjxoXnfA/KZi4qLKGzUNFEChtHJ8OYAnvn6LP0wJK 2/xWAfsY1ddkEsHJNSQQbQcNgcgkvLk/W3LcT5YqxdmF/2g7gAZxmBwAqEYCnpWn shVGQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=cbgrPwFVadIjhe8NKE8Mn7wWY+AaF8p+g6Jy6EIxw b4=; b=i43yfQ/OtMB6rtHUT1OSmC2AoyRu4oMthdCOJCvzhgcku0f2GLZzlVq+g 8jGI6vfqWMxbrtyUvIeN53RKPsFdji/X5up7n1Ki3KOflScoXvdAyPd3Pf0NfMdi dfcUcSVXcFGh6tMmWixdKxk8nwwEF4qWWsqbq0BjiNOMUb7e44rM+jGSdNXT+0Ie 1uFaibAeRyV7oMAC2Frw8LFMdYasIDBwbO8nmFkGbssQ08MG4zrYSl1rNKnG4w3E +/id/8I3j/nOX6DgCAtsE7xX8igqk4mzYihIxAw6I3dvk82Zsh5tglCDAIA1M8CG u8AuunUZs1wCLjRYf6vzP5UTvU8gA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrkeehgdduudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthenuceurghilhhouhhtmecufedt tdenucenucfjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtddvnecuhfhrohhmpe forghrkhcupfhothhtihhnghhhrghmuceomhhnohhtsehmnhhothdrnhgvtheqnecuffho mhgrihhnpehivghtfhdrohhrghdpmhhnohhtrdhnvghtpdhirghnrgdrohhrghenucfkph epudeggedrudefiedrudejhedrvdeknecurfgrrhgrmhepmhgrihhlfhhrohhmpehmnhho thesmhhnohhtrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from attitudadjuster.mnot.net (unknown [144.136.175.28]) by mail.messagingengine.com (Postfix) with ESMTPA id EDA7910310; Mon, 4 Feb 2019 18:30:50 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Mark Nottingham In-Reply-To: <154886569351.10484.4703007670359734409@ietfa.amsl.com> Date: Tue, 5 Feb 2019 10:30:46 +1100 Cc: secdir@ietf.org, draft-nottingham-rfc5785bis.all@ietf.org, ietf@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <154886569351.10484.4703007670359734409@ietfa.amsl.com> To: Kathleen Moriarty X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [secdir] Secdir last call review of draft-nottingham-rfc5785bis-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2019 23:31:02 -0000 Hi Kathleen, Thanks for the thorough review. Responses below. > On 31 Jan 2019, at 3:28 am, Kathleen Moriarty = wrote: >=20 > Reviewer: Kathleen Moriarty > Review result: Has Nits >=20 > Thank you, Mark and others for your work on this document to update = the > specification. My comments are mainly requests for clarity in the = document and > text suggestions are provided to hopefully make this as easy as = possible. >=20 > 1. Section 3: Nit: > In my opinion, the flow would be improved if the third paragraph came = before > the current second paragraph. >=20 > 2. Could you provide a transitional sentence between the current = second > paragraph and the instructions that follow since the current second = paragraph > points to following section 5.1 for instructions, but paragraph 4+ = include > instructions or guidance followed by additional helpful information. = I think a > slight adjustment as follows to accomplish this would be quite helpful = to the > reader: >=20 > Applications that wish to mint new well-known URIs MUST register > them, following the procedures in Section 5.1 and the following = requirements. All of the above incorporated, the latter with a minor adjustment. = Thanks. > 3. Section 3.1 says: > The "Well-Known URIs" registry is located at > "https://www.iana.org/assignments/well-known-uris/". Registration > requests can be made by following the instructions located there or > by sending an email to the "wellknown-uri-review@ietf.org" mailing > list. >=20 > I'm not clear on the instructions as I follow the link to the registry = and > there's a pointer to the RFC that this document will obsolete. I'm = assuming > that the reference will be replaced with this document. Is that the = case or > are there additional instructions than what will be included directly = in the > registry? If they are repeated (I don't see an IANA request for that = action), > that is fine, but I think it's a little confusing to send someone to = that link > if they are already reading this document. This document is also = going through > a review process to update that registry, so if instructions were = maintained at > the registry URL, what would be the review process to alter the = instructions?=20 > I'm assuming that this sentence just should be removed, but if not, = I'd like to > understand the update process for that registry (instructions for = registering > values not adding them). If the sentence should be changed, I suggest > something like: >=20 > The "Well-Known URIs" registry is located at > "https://www.iana.org/assignments/well-known-uris/". Registration > requests can be made by following the instructions in this document = and > sending the email to the "wellknown-uri-review@ietf.org" mailing > list. After extensive consultation with IANA regarding RFC8288's revision of = registration policy, the outcome was that this level of detail / = instruction is unnecessary; the text at the top of a registry page can = be tweaked by the Experts by asking IANA, and if they have concerns they = can take it up with the IESG as necessary. Personally I was a bit surprised by this, but also relieved; getting = this sort of thing *exactly* right in an RFC is difficult, and we need = the flexibility to change things (e.g., we're currently using a Github = issue queue to collect registration requests there, but that might = change in the future). > 4. Question on Change controller: Is it possible to successfully make = a request > through an experimental track RFC or standards track only? If = experimental is > allowed, can it only be provisional? The registry is Specification Required, so an experimental RFC can = indeed make a registry. It can be 'standard' if it meets this bar: = "Other values can also be registered as permanent, if the Experts find = that they are in use, in consultation with the community." > 5. Section 3 has the following sentence: >=20 > General requirements for registered relation types are described in > Section 3. >=20 > Did the document in a previous revision contain something in section 3 = about > registered relation types or am I missing something when reading = section 3 > (which is entirely possible)? If it were there (or maybe was in a = previous > revision), I'd expect to see it in the following paragraph, but could = see the > above text being dropped as an answer to this question as well (unless = I am > missing something): >=20 > It MAY also contain additional information, such as the syntax of > additional path components, query strings and/or fragment = identifiers > to be appended to the well-known URI, or protocol-specific details > (e.g., HTTP [RFC7231] method handling). Section 3 puts requirements on choosing a registered name, both = syntactically and with a more general SHOULD about how to choose a good = name. > 6. Section 3.1: Is the following referring to IETF standards-track = documents > or could other standards from other SDOs (or some other constraint) be = included? >=20 > Standards-defined values have a status of "permanent". Other values > can also be registered as permanent, if the Experts find that they > are in use, in consultation with the community. Other values should > be registered as "provisional". The intent was values defined by Open Standards, in the sense of = RFC2026, 7.1.1. I'll clarify this, thanks. > I'm guessing a standards track RFC is not necessary for standards = track because > of the next paragraph in this section, but maybe some added text would = help to > clarify the above paragraph? >=20 > Provisional entries can be removed by the Experts if - in > consultation with the community - the Experts find that they are not > in use. The Experts can change a provisional entry's status to > permanent at any time. Except for the issue above, I don't see how this is unclear; if a value = is defined by a standard, it is automatically permanent, but other = values can be as well, as per the text. Can you suggest text? > 7. Section 5.1 second paragraph has the following text: >=20 > Well-known URIs are registered on the advice of one or more experts > (appointed by the IESG or their delegate), with a Specification > Required (using terminology from [RFC8126]). >=20 > This should read as follows according to RFC8126 section 5.2.1: > https://tools.ietf.org/html/rfc8126#section-5.2.1 >=20 > Well-known URIs are registered on the advice of one or more experts > (appointed by the IESG), with a Specification > Required (using terminology from [RFC8126]). >=20 > There's no provision for the IESG to delegate assignment of an expert. = IESG > member often consult working group chairs and experts, but the = assignment is > currently performed by the IESG unless RFC8126 gets updated. My understanding is that this level of detail is unnecessary in the = registering document, as the IESG has the power to delegate naturally. = If this needs to be specified explicitly, that should be done in a = revision of RFC8126 section 5.2.1, not here. > 9. Section 5.1: > There may be additional information I am not aware of, hence the = following > clarifying questions. Is there a hold on the registry from now until = this > document is published? Could an expert receive a request prior to = publication > where they feel the right status is "provisional" and is timely = (cannot wait > until after actions for this document are complete)? I'm asking = because of the > following text and the answer may be yes, there is a hold, but I am = not seeing > where one is listed. Since the expert can update the registry at any = time, is > the second bullet necessary (could it cause problems)? >=20 > Upon publication, IANA should: >=20 > o Replace all references to RFC 5988 in that registry have been > replaced with references to this document. >=20 > o Update the status of all existing registrations to "permanent". We've been processing registration requests as normal throughout the = development period of this draft. When a registration request appears to = violate the intent of 5785 but is OK by 5785bis (which we believe = represents emerging consensus), I (wearing the Expert hat) have = escalated them to the ADs to confirm an exception. Part of the urgency in getting this document published is that I'm = uncomfortable with that, and of course it's onerous for all concerned. The second bullet shouldn't interfere with that. Cheers and thanks again, -- Mark Nottingham https://www.mnot.net/ From nobody Tue Feb 5 03:01:02 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6434131095; Tue, 5 Feb 2019 03:00:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=W4N6aaPf; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=a/eSkXqp 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 W91xW1wK8hkB; Tue, 5 Feb 2019 03:00:52 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02261130FF2; Tue, 5 Feb 2019 03:00:52 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 1FE8C21909; Tue, 5 Feb 2019 06:00:51 -0500 (EST) Received: from web2 ([10.202.2.212]) by compute7.internal (MEProxy); Tue, 05 Feb 2019 06:00:51 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= message-id:from:to:cc:mime-version:content-transfer-encoding :content-type:in-reply-to:subject:date:references; s=fm2; bh=2G4 OmPsszZCgnSx+vfcfT1/RP/ATuWFc9anrUXlFjj4=; b=W4N6aaPfdrR4vewFOS6 nLqh1s9JoV1c57Gatw4UOwo30uLgMmcxSNg5ZKs4lk7IRslyzv/QtrQFDFdoPwK8 0sCZUMkcmlYEiNvYFoLpYWuoB5xrD1PlEftxKyzkjpCYwAED0xFt5I5S3CxUuOja 1GQzHH6RCddGwg13qMvO29PG/I6FYpEXJF81P4VixNQIHwG7SQsiEo2Pyki79+Qj RRaaR+/CUBNIcS3B1eo6IHoZCooyqMDrzcWX6YcFPUwNCppRl7+E09X5dgyukYz+ l5+5s3i7wBg1dSb2bWjonw89K+mAah2uh9vM3a2E0AW/5iP2ui50IByCQuo0NhDe lvQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=2G4OmPsszZCgnSx+vfcfT1/RP/ATuWFc9anrUXlFj j4=; b=a/eSkXqpcFFQz52PPGVUMm4u8gspBDl3NgfWawXz1q2c5EFFUjNe7Zy1d kl0HR/tSYLFPIZr0pIUBWElIeDYhYLfSDuwWeERS/jmolOt5xJIKc26ZxY58WMLQ KNQP9iANsUF8hcVuq+4mQUduZ9OGz6X0HYqjpcEM3FPOOCxnL1USFG08ExIZUlAp eGxufyUYvSebo6C6fuhyW8A0sHaDFQDEn7rhrzQB7aEUMMkk9l3Izkaz/fZiZhcW mzrEzb+H6AAuH9B5E/zD5MtRf2NXP1cCZocFFECeSr1yL4D5uJPOBPKEc7mWIsyq bheuXtq0PDF6kZMorsQZMEVSZwj0A== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrkeeigddvtdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthenuceurghilhhouhhtmecufedt tdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepkffhvfgggfgtof gjuffffhesthejredtredtjeenucfhrhhomheptehlvgigvgihucfovghlnhhikhhovhcu oegrrghmvghlnhhikhhovhesfhgrshhtmhgrihhlrdhfmheqnecuffhomhgrihhnpehivg htfhdrohhrghenucfrrghrrghmpehmrghilhhfrhhomheprggrmhgvlhhnihhkohhvsehf rghsthhmrghilhdrfhhmnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 99) id A39576230E; Tue, 5 Feb 2019 06:00:50 -0500 (EST) Message-Id: <1549364450.1066686.1651171416.66DAF9BA@webmail.messagingengine.com> From: Alexey Melnikov To: Mark Nottingham , Kathleen Moriarty Cc: secdir@ietf.org, draft-nottingham-rfc5785bis.all@ietf.org, ietf@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-ec01da05 In-Reply-To: Date: Tue, 05 Feb 2019 11:00:50 +0000 References: <154886569351.10484.4703007670359734409@ietfa.amsl.com> Archived-At: Subject: Re: [secdir] Secdir last call review of draft-nottingham-rfc5785bis-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2019 11:00:54 -0000 Hi all, On one specific issue raised by Kathleen: On Mon, Feb 4, 2019, at 11:30 PM, Mark Nottingham wrote: > Hi Kathleen, > > Thanks for the thorough review. Responses below. > > > > On 31 Jan 2019, at 3:28 am, Kathleen Moriarty wrote: (snip) > > 7. Section 5.1 second paragraph has the following text: > > > > Well-known URIs are registered on the advice of one or more experts > > (appointed by the IESG or their delegate), with a Specification > > Required (using terminology from [RFC8126]). > > > > This should read as follows according to RFC8126 section 5.2.1: > > https://tools.ietf.org/html/rfc8126#section-5.2.1 > > > > Well-known URIs are registered on the advice of one or more experts > > (appointed by the IESG), with a Specification > > Required (using terminology from [RFC8126]). > > > > There's no provision for the IESG to delegate assignment of an expert. IESG > > member often consult working group chairs and experts, but the assignment is > > currently performed by the IESG unless RFC8126 gets updated. > > My understanding is that this level of detail is unnecessary in the > registering document, as the IESG has the power to delegate naturally. > If this needs to be specified explicitly, that should be done in a > revision of RFC8126 section 5.2.1, not here. Mark, I think you are actually agreeing that the part "or their delegate" can be deleted, as this can happen naturally during IESG deliberations. While nothing prevents IESG from asking a third party to pick an expert, IESG has never done this and the final authority to decide stays with IESG. Best Regards, Alexey From nobody Tue Feb 5 14:26:40 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A29613130C; Tue, 5 Feb 2019 14:26:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=Fbka17lC; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=CMzoc0iR 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 SXISp1ULOPG9; Tue, 5 Feb 2019 14:26:27 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8093131317; Tue, 5 Feb 2019 14:26:27 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id EBDC322063; Tue, 5 Feb 2019 17:26:26 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Tue, 05 Feb 2019 17:26:26 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm1; bh=p qZ7Qxz/kd60WR1cpVhWreCGMVfKc22X80rV31oGNHw=; b=Fbka17lCd0BusUOT5 fKnlFvGSmq2Lv8jRsLwNqmCPBlUOMzfzYMnFXBGNzco+vAehWyg0WIdjYNL1zR8C RNqGL1gN1dIYYe7g/Qqw8qTCAFzoRFs9t/ywWY8rpRgoe5PWiia9BOC5dVO+1iZw GJsoDB3ptKTb0R1U+V2kjGxkBj6iubioYykXUrjo4haT95mfmtxWTtQ2B4PiHCts QZPa8mZlqilqQiODrHBwbvx3Js4Ww/iSzAqtd1/9h6I8babZEpU5VgqRaR4t7DjC 8mQ84ZQWnNj67X7XF/rJzzWlO2289SAmi7hPF0UOWmPENM/KgP2zVesKwaWrCYhJ l5g7Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=pqZ7Qxz/kd60WR1cpVhWreCGMVfKc22X80rV31oGN Hw=; b=CMzoc0iRXYq5OeS89p2FOwVEDWqOhLB8FmdpmiVu+1X/K6ugxFAfRewoj JxuSps8/l6+kfeoHMmrF67GnU2dCfwnraEc7aAx8+oFzdKxq8AwAfD30J03KWuAO o0Z7rcA1uGBmfL7vl6oGtj/WJkNdahgCyzPhfQ9EDZJz5+C0V4CEngosk12+ry8I TY1Xb6Y0EQve1fzyEnwkQQwdIezzxSm+baGsH0PeVFmDI+O9xsnZa6l8/Kh24maA q9RiV+fyRpHpBvpCn81jOV1R2ArZHCSanXhKFwYyQnBlx7i9gENeajYm2BdlRFeO oRPSrD/D6if5GS/H/c2+WHSQnuGdg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrkeeigdduheekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfquhhtnecuuegrihhlohhuthemucef tddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpegtggfuhfgjff fgkfhfvffosehtqhhmtdhhtddvnecuhfhrohhmpeforghrkhcupfhothhtihhnghhhrghm uceomhhnohhtsehmnhhothdrnhgvtheqnecuffhomhgrihhnpehmnhhothdrnhgvthenuc fkphepudeggedrudefiedrudejhedrvdeknecurfgrrhgrmhepmhgrihhlfhhrohhmpehm nhhothesmhhnohhtrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from attitudadjuster.mnot.net (unknown [144.136.175.28]) by mail.messagingengine.com (Postfix) with ESMTPA id 8F6B11030F; Tue, 5 Feb 2019 17:26:21 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Mark Nottingham In-Reply-To: <1549364450.1066686.1651171416.66DAF9BA@webmail.messagingengine.com> Date: Wed, 6 Feb 2019 09:26:16 +1100 Cc: secdir@ietf.org, draft-nottingham-rfc5785bis.all@ietf.org, ietf Content-Transfer-Encoding: quoted-printable Message-Id: <263BC646-E027-4E9F-87DC-BCD1D2B36C2C@mnot.net> References: <154886569351.10484.4703007670359734409@ietfa.amsl.com> <1549364450.1066686.1651171416.66DAF9BA@webmail.messagingengine.com> To: Alexey Melnikov , Kathleen Moriarty X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [secdir] Secdir last call review of draft-nottingham-rfc5785bis-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2019 22:26:30 -0000 > On 5 Feb 2019, at 10:00 pm, Alexey Melnikov = wrote: >=20 [snip] >=20 > Mark, I think you are actually agreeing that the part "or their = delegate" can be deleted, as this can happen naturally during IESG = deliberations. While nothing prevents IESG from asking a third party to = pick an expert, IESG has never done this and the final authority to = decide stays with IESG. Ah - I missed that, my apologies. Fixed. -- Mark Nottingham https://www.mnot.net/ From nobody Wed Feb 6 06:50:42 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ED7D128CF3; Wed, 6 Feb 2019 06:47:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1549464450; bh=GlamqbvMD5aBJ5ZigxxSYuhKYbzCuga4GffesSYTxfQ=; h=From:Date:To:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=A2Kcy5wwHCcqqiEZzqU4DnyH2hBVa1htBMgl8aJq2hF1oQqjpozimP5KTFseQTadA +SM15zoaQ0uyIvByo2mACEMYI7lEVA6ZLwL05q+EqK7YzK80W1O3j7BXWlvko0BAMK 0tb7XOLcfhlCV89uLTcPir3YgfhTM2qcAXp4tZNg= X-Mailbox-Line: From new-work-bounces@ietf.org Wed Feb 6 06:47:29 2019 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D5736124BF6; Wed, 6 Feb 2019 06:47:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1549464449; bh=GlamqbvMD5aBJ5ZigxxSYuhKYbzCuga4GffesSYTxfQ=; h=From:Date:To:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=PdcG0EkeD1Mhii/Hkj04CUf6GbKCDbUyynnX0fNr3a9oX/o58iEfXE8k7AzwihEuc 8xKRM0fMIfZs2pUy8wW9qbEszE25bkU0DLK+rbqHxb0jcBWP29ibB2JdasySUX8JHq DK1yWMwyCXGFpzz4zda4tG1d+u9XaTbH0Rpmh+fg= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3AB5124BF6 for ; Wed, 6 Feb 2019 06:47:27 -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 autolearn_force=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 JIK-VpzeV8o3 for ; Wed, 6 Feb 2019 06:47:26 -0800 (PST) Received: from raoul.w3.org (raoul.w3.org [128.30.52.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 018BC124BE5 for ; Wed, 6 Feb 2019 06:47:25 -0800 (PST) Received: from [93.30.120.228] (helo=[192.168.1.20]) by raoul.w3.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1grOU0-0003IM-9P; Wed, 06 Feb 2019 14:47:24 +0000 From: Coralie Mercier Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Wed, 6 Feb 2019 15:47:22 +0100 Message-Id: <18C31056-C212-448A-A447-B5A00466D69A@w3.org> To: new-work@ietf.org X-Mailer: Apple Mail (2.3445.102.3) Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.29 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Wed, 06 Feb 2019 06:50:41 -0800 Subject: [secdir] [new-work] Proposed W3C Charter: Devices and Sensors Working Group (until 2019-03-06) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2019 14:47:32 -0000 Hello, Today W3C Advisory Committee Representatives received a Proposal to review a draft charter for the Devices and Sensors Working Group: https://www.w3.org/2019/02/DeviceAPICharter-ac.html As part of ensuring that the community is aware of proposed work at W3C, this draft charter is public during the Advisory Committee review period. W3C invites public comments through 2019-03-06 on the proposed charter. Please send comments to public-new-work@w3.org, which has a public archive: http://lists.w3.org/Archives/Public/public-new-work/ Other than comments sent in formal responses by W3C Advisory Committee Representatives, W3C cannot guarantee a response to comments. If you work for a W3C Member [1], please coordinate your comments with your Advisory Committee Representative. For example, you may wish to make public comments via this list and have your Advisory Committee Representative refer to it from his or her formal review comments. If you should have any questions or need further information, please contact Fuqiao Xue, Team Contact . Thank you, Coralie Mercier, Head of W3C Marketing & Communications [1] http://www.w3.org/Consortium/Member/List -- Coralie Mercier - W3C Marketing & Communications - https://www.w3.org mailto:coralie@w3.org +337 810 795 22 https://www.w3.org/People/Coralie/ _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Wed Feb 6 13:53:47 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 963BE130ECD; Wed, 6 Feb 2019 13:53:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 QgycOMS8T2Zu; Wed, 6 Feb 2019 13:53:29 -0800 (PST) Received: from mail-ot1-x334.google.com (mail-ot1-x334.google.com [IPv6:2607:f8b0:4864:20::334]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A22D412D4F3; Wed, 6 Feb 2019 13:53:29 -0800 (PST) Received: by mail-ot1-x334.google.com with SMTP id v23so14716746otk.9; Wed, 06 Feb 2019 13:53:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=aL3e9FlL4g1tQTHJ8bXBoWVMpBBe52/FdYjb6XiJpSU=; b=lw9wQHo/PVmPBUwBToZm0PgoMiTvsVEB2gbQ4T0FM8InRv3O/E5t+9uH4jPL68+xsk stet0LaxJBtFB6VdJh855nl3LT3jFUr8m3AAX8JvuoaAG7OkPv2Jl9+6Re/KcD4ojyaC PXFwYEUG9ScDfI8YwuJbsgnGpGNnu3AoVeOwHD+O5kzKbfxFc2vRP95uNrQSgEjiI/Mr jI4gk2p3AKurfekkaYMZ9RR7WlKcORthshDVTL6DlJ0Lytl4bdUdEw3O9CMBwxnHUug7 fJK9jIj5LF7T9+isIuYrB3VpciGGZq7ydjnFHTFyuF8y5Fw5g/YSPEvoibB/Uh/kRLlT LJNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=aL3e9FlL4g1tQTHJ8bXBoWVMpBBe52/FdYjb6XiJpSU=; b=dKBcvzc7m+Yl0ttVbDH9nPLAIyvna2eYRacBZ5gs5fEAYBLLGa8Y0J+9G0bdUSv6Cb a0P7l8hw04jbMXFo1U3fa7djBOMF6Ydnq5kUfbQJ172+DLdknJ2YNLMhgdu9021HdQmE qmPvNzLAxyTVQAxC+3Le9bCsNoqlan7KFXI+5ryIM0VP6grUvJrCBFIqdsTO1bbLFjfc Uh72g4FUWog7wshY2WtRd+LDW98yqdW0EX+bzincS3/bYWMxlmXBdZprzvj8T5a4gvG8 bYVH/FYosqLc4VzUx5kDdkrZogzT526Wk59qZrVOb0UEZ0F1N42/wumvsX6R6FpW11gP Z7Xw== X-Gm-Message-State: AHQUAuaN/Nm5bWYL2lIUUVQ9ipS6eovYLjBOgiOW5LKp+Bo9RjjECTLr Z+9z3mDR83/8SOgNPPoCtNfsWrsD2N2TdhbnOOU= X-Google-Smtp-Source: AHgI3IZE1zeKkDDJ5BhPmU4dZh9dFTRG/m9WdNTeQP0UpD21mqRO5fDrWKhhwZZC2ZVzU3uKDxRVFPefIXjKD03ZxHE= X-Received: by 2002:a54:4e95:: with SMTP id c21mr752379oiy.118.1549490008712; Wed, 06 Feb 2019 13:53:28 -0800 (PST) MIME-Version: 1.0 References: <154881379920.7794.15439486195773911279@ietfa.amsl.com> In-Reply-To: From: Donald Eastlake Date: Wed, 6 Feb 2019 16:53:16 -0500 Message-ID: To: David Schinazi Cc: Sean Turner , secdir@ietf.org, draft-ietf-babel-dtls.all@ietf.org, IETF Discussion , Babel at IETF Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [secdir] Secdir early review of draft-ietf-babel-dtls-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2019 21:53:32 -0000 Hi, See below. On Fri, Feb 1, 2019 at 7:40 PM David Schinazi wrote: > > Thanks for the review Sean! > > I've updated the doc with your comments: > https://github.com/jech/babel-drafts/commit/e202f664712772a4db2bd88c5665ba3193cd4c99 > > Detailed responses inline. > > David > > > On Wed, Jan 30, 2019 at 11:03 AM Sean Turner wrote: >> >> Reviewer: Sean Turner >> Review result: Has Nits >> >> Hi, >> >> David wanted to make it really easy on me and get as much early input as he >> could get by sending a msg to the TLS list asking for comments [0]. Version >> -02 addressed those comments. >> >> I'm no babel expert, but I did take the time to read/skim the base protocol >> document to get more familiar with it as well as re-read the babel-tls draft. >> The tl;dr here is that babel is multicast but DTLS is not so changes to babel >> are needed. > > To clarify, the changes to make Babel work over unicast have all gone into > the base spec: draft-ietf-babel-rfc6126bis > >> Here are my comments in no particular order. No show stoppers here. >> >> 0) Since DTLS is in the RFC Editor's Abbreviations List - I think you can get >> away with: Babel Routing Protocol over DTLS But, that's up to you. > > I personally prefer spelling it out, but I don't feel too strongly about it. While my feeling is not that strong, I also favor spelling it out. >> 1) (IEGS food fight alert) I see that the updates header updates 6126bis. Not >> sure how this will fly in the face of the draft IESG Statement [1]. > > Thanks for pointing this out. We'll follow any guidance the IESG gives us > during their review. I think this draft should not say that it updates 6126bis. However, I am of that opinion not because of IESG policy but because 6126bis normatively references this draft; therefore, readers of 6261bis will be automatically directed to the RFC this draft become when published. >> 2) (This might just be document organization) The applicability section kind of >> jumped out at me because there's also an applicability draft. Further, it and >> 6126bis says the HMAC mechanism is preferred. I'd just drop the entire section >> ;) > > The authors felt we should insist that HMAC is better suited for many deployments > as it better fits with the traditional Babel multicast model. The applicability draft > focuses on Babel itself. > >> 3) s2.1 - maybe add a pointer to the IANA considerations section. > > Done > >> 4) s2.1 - Because you're doing client authentication do you need say anything >> about the type of cert, whether certificate_authorities, >> signature_algorithms_cert, signature_algorithms should be sent (for 1.3 >> connections)? > > We've had this conversation on the Babel mailing list, and we landed on having the > babel-dtls draft not define any of these, punting that to the usage profiles drafts. > For example, the Babel Homenet profile draft will define all of these. > >> 5) s4 - add that IANA is requested to point to this specification for the >> reference. > > Done > >> 6) AppA - I think you might need to tweak the last sentence in light 1.3? > > Unfortunately DTLS 1.3 hasn't been published yet, and I'd rather not make > assumptions on what the RFC will say (even though we're pretty sure the > handshake won't change between the current draft and RFC). If it gets > published as RFC before this document does, I'll make these changes. Given the advanced state of the DTLS 1.3 draft in the IETF process, I suggest consideration be given to referencing that draft rather than RFC 6347 and making corresponding minor changes in this draft... Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 1424 Pro Shop Court, Davenport, FL 33896 USA d3e3e3@gmail.com >> Cheers, >> spt >> >> [0] https://mailarchive.ietf.org/arch/msg/tls/tIaK0rgm5zCVuYmLm5qsCIvKXKw >> [1] https://mailarchive.ietf.org/arch/msg/ietf/-1u_1-peHKAmUDuLyGAJYu0fPCE From nobody Wed Feb 6 14:18:35 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3027D130F3E for ; Wed, 6 Feb 2019 14:18:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.853 X-Spam-Level: X-Spam-Status: No, score=-8.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com 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 akW9A6ySQNCr for ; Wed, 6 Feb 2019 14:18:02 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EDC2130F72 for ; Wed, 6 Feb 2019 14:18:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1549491477; x=1552083477; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=v5zG2X5PCsVrVCH4jlOZtLjNotMiJi4uQYdXpRyRlJQ=; b=Lffukcvni07S/s4LWAM6WVavrIeJZpHkZISjq0OKNH3QWdoXcdDhDf+ku0FuXqQY Nn5G0eykFngo4EnRaeB3TNbTvQm5bCF+/JyrYJ0L5i+0mg9A/6R+q0fxV+N81Rdp 7JRepWY9QvSESTsKgUI0zuwcHshJdOFvCfOoGuQhhEc=; X-AuditID: c1b4fb3a-14fff7000000672c-47-5c5b5d159aa3 Received: from ESESBMB502.ericsson.se (Unknown_Domain [153.88.183.115]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id AE.96.26412.51D5B5C5; Wed, 6 Feb 2019 23:17:57 +0100 (CET) Received: from ESESBMR502.ericsson.se (153.88.183.134) by ESESBMB502.ericsson.se (153.88.183.169) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Wed, 6 Feb 2019 23:17:56 +0100 Received: from ESESSMB503.ericsson.se (153.88.183.164) by ESESBMR502.ericsson.se (153.88.183.134) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Wed, 6 Feb 2019 23:17:56 +0100 Received: from [100.94.32.17] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.191) with Microsoft SMTP Server id 15.1.1466.3 via Frontend Transport; Wed, 6 Feb 2019 23:17:56 +0100 From: =?UTF-8?Q?J=c3=a1nos_Farkas?= To: Daniel Harkins CC: "iesg@ietf.org" , "secdir@ietf.org" , DetNet WG References: Message-ID: <50d31dc2-1f3f-21aa-2e2b-5432816e1425@ericsson.com> Date: Wed, 6 Feb 2019 23:17:56 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------77E3A8F48C7BE9F74D534660" Content-Language: en-US X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpnkeLIzCtJLcpLzFFi42KZGbG9WFc0NjrG4EoXj8XvT7NZLJb++8Ji MePPRGaLDwsfsjiweCxZ8pPJ49nulywBTFFcNimpOZllqUX6dglcGZP6drAXLA+sOHPrDWMD 43m7LkZODgkBE4kXa5+xdzFycQgJHGGU6NwxB8r5yihx8N0mBOfW84UsEM4hRonP818ygfQL C9hLdN2YAGazAdl3L21gBrFFBDQkOrctZuti5OBgFkiXaGgoAwkLCZRKNK5Yygpi8wKVvzmx kA3EZhFQkViyr40FxBYViJX4dGUxM0SNoMTJmU9YQMZwCjhIfFlTABJmFgiTuLF5KiOELS5x 68l8JojxahLvG+4wTmAUmoWkexaSlllIWiBsC4mZ889DxeUlmrfOZoawNSRa58xlRxZfwMi+ ilG0OLW4ODfdyEgvtSgzubg4P08vL7VkEyMweg5u+W21g/Hgc8dDjAIcjEo8vHuio2OEWBPL iitzgWHGwawkwvv2WVSMEG9KYmVValF+fFFpTmrxIUZpDhYlcd4/QoIxQgLpiSWp2ampBalF MFkmDk6pBka781kv9sos751ynkFEL0zkmLvGDabzk+wPnngcUHFXfsZeXq5ve6tnezM1yARP Wvzs+MfywunXj4YeSH4ab/LyLts3jiRmXqlXPXNMj5Z+2HJu6UmhaYyVezKzj0uvczijeDS7 bknWn59/61Q/uj7OOfA4+uByjTuetzKfXlt0L9mk8+nepSc9lViKMxINtZiLihMB8XYOOJoC AAA= Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-detnet-architecture-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2019 22:18:08 -0000 --------------77E3A8F48C7BE9F74D534660 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit Hi Daniel, Thank you very much again for your review! The draft had multiple updates since v08 you reviewed. The latest revision is v 11: https://mailarchive.ietf.org/arch/msg/detnet/SP63CCzi4C2Biy9mk0Qxrehoa_0 The updates address review comments, and comments and discussions on the DetNet WG list. Please let us know if you have further comments. Regards, Janos On 10/17/2018 10:28 AM, János Farkas wrote: > Hi Daniel, > > Thank you very much for your review! > > Please find below how we plan to update the draft to address your > comments. > > Best regards, > Janos > > > On 9/25/2018 2:58 AM, Daniel Harkins wrote: >> >>   Hello, >> I have reviewed this document as part of the security directorate's >> ongoing effort to review all IETF documents being processed by the >> IESG. These comments were written primarily for the benefit of the >> security area directors. Document editors and WG chairs should treat >> these comments just like any other last call comments. >> >> The summary of the review is ready with issues. >> >> This draft describes an architecture for deterministic networking >> that provides for delivery of packet flows with low packet loss and >> with a maximum amount of latency. >> >> A nit first. The terminology seems a bit overblown. We have DetNet >> Intermediate nodes that could be relay nodes or transit nodes; and a >> DetNet system that is a DetNet aware system or transit node or >> relay node; and DetNet edge nodes that are relay nodes; and DetNet >> relay nodes that can be bridges, firewalls, or anything else that >> participates in DetNet. Finally, to translate between 802.1 TSN and >> DetNet we have a "relay system" that is an 802.1 term for a DetNet >> intermediate node which, as we have seen, is a DetNet relay node. This >> can be simplified considerably. > The definition of DetNet relay node will be updated. > "A DetNet relay node can be a bridge, a router, a firewall, or any > other system" will be delated. > > OLD: > A DetNet node including a service layer function that > interconnects different DetNet transport layer paths to > provide service protection. A DetNet relay node can be a > bridge, a router, a firewall, or any other system that > participates in the DetNet service layer. It typically > incorporates DetNet transport layer functions as well, in > which case it is collocated with a transit node. > > NEW: > A DetNet node including a service layer function that > interconnects different DetNet transport layer paths to > provide service protection. A DetNet relay node operates > at the service layer. It typically incorporates DetNet > transport layer functions as well, in which case it is > collocated with a DetNet transit node. > > > >> The Security Considerations is thin, especially for an architecture >> draft that is going to be referred to by subsequent drafts which will >> just say something along the lines of, "as an instance of the DetNet >> FooBar, these Security Considerations are those from [ARCH]", where >> ARCH is the RFC that comes out of this I-D. I think there needs to be >> a description of the various points in the architecture that an attacker >> could exploit, and if a point is not exploitable it should say so. For >> instance: >> >> - is it possible for an attacker to launch a DoS attack by manipulating >> member flows of a DetNet flow in order to force DetNet nodes to >> consume buffers they allocated to deal with the DetNet flow? >> >> - If an end system is not DetNet aware there needs to be a DetNet edge >> node to handle the encaps of the flow into the DetNet system. Can an >> attacker in that case introduce packets that shouldn't be part of the >> DetNet flow into the flow by getting the edge node to encaps them as >> such? >> >> If there are any assumptions being made-- e.g. "insider attacks are not >> being considered"-- they should be mentioned. >> >> regards, >> >> Dan. >> >> > Security issues and considerations are addressed by the DetNet > Security draft: > https://datatracker.ietf.org/doc/draft-ietf-detnet-security. > Reference will be added to the DetNet security document. --------------77E3A8F48C7BE9F74D534660 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit Hi Daniel,

Thank you very much again for your review!

The draft had multiple updates since v08 you reviewed. The latest revision is v 11: https://mailarchive.ietf.org/arch/msg/detnet/SP63CCzi4C2Biy9mk0Qxrehoa_0

The updates address review comments, and comments and discussions on the DetNet WG list.

Please let us know if you have further comments.

Regards,
Janos


On 10/17/2018 10:28 AM, János Farkas wrote:
Hi Daniel,

Thank you very much for your review!

Please find below how we plan to update the draft to address your comments.

Best regards,
Janos


On 9/25/2018 2:58 AM, Daniel Harkins wrote:
 
  Hello,
  I have reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the 
IESG.  These comments were written primarily for the benefit of the 
security area directors.  Document editors and WG chairs should treat 
these comments just like any other last call comments.

  The summary of the review is ready with issues.

  This draft describes an architecture for deterministic networking
that provides for delivery of packet flows with low packet loss and
with a maximum amount of latency. 

  A nit first. The terminology seems a bit overblown. We have DetNet
Intermediate nodes that could be relay nodes or transit nodes; and a
DetNet system that is a DetNet aware system or transit node or
relay node; and DetNet edge nodes that are relay nodes; and DetNet
relay nodes that can be bridges, firewalls, or anything else that
participates in DetNet. Finally, to translate between 802.1 TSN and
DetNet we have a "relay system" that is an 802.1 term for a DetNet
intermediate node which, as we have seen, is a DetNet relay node. This
can be simplified considerably.
The definition of DetNet relay node will be updated.
"A DetNet relay node can be a bridge, a router, a firewall, or any other system" will be delated.

OLD:
A DetNet node including a service layer function that
interconnects different DetNet transport layer paths to
provide service protection. A DetNet relay node can be a
bridge, a router, a firewall, or any other system that
participates in the DetNet service layer. It typically
incorporates DetNet transport layer functions as well, in
which case it is collocated with a transit node.

NEW:
A DetNet node including a service layer function that
interconnects different DetNet transport layer paths to
provide service protection. A DetNet relay node operates
at the service layer. It typically incorporates DetNet
transport layer functions as well, in which case it is
collocated with a DetNet transit node.



  The Security Considerations is thin, especially for an architecture
draft that is going to be referred to by subsequent drafts which will
just say something along the lines of, "as an instance of the DetNet
FooBar, these Security Considerations are those from [ARCH]", where
ARCH is the RFC that comes out of this I-D. I think there needs to be
a description of the various points in the architecture that an attacker
could exploit, and if a point is not exploitable it should say so. For
instance:

  - is it possible for an attacker to launch a DoS attack by manipulating
    member flows of a DetNet flow in order to force DetNet nodes to
    consume buffers they allocated to deal with the DetNet flow?

  - If an end system is not DetNet aware there needs to be a DetNet edge
    node to handle the encaps of the flow into the DetNet system. Can an
    attacker in that case introduce packets that shouldn't be part of the
    DetNet flow into the flow by getting the edge node to encaps them as
    such?

If there are any assumptions being made-- e.g. "insider attacks are not
being considered"-- they should be mentioned. 

  regards,

  Dan.

Security issues and considerations are addressed by the DetNet Security draft: https://datatracker.ietf.org/doc/draft-ietf-detnet-security.
Reference will be added to the DetNet security document.

--------------77E3A8F48C7BE9F74D534660-- From nobody Wed Feb 6 15:29:27 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D03CA130E25 for ; Wed, 6 Feb 2019 15:29:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com 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 O2HlCoDimzNT for ; Wed, 6 Feb 2019 15:29:09 -0800 (PST) Received: from mail-qk1-x734.google.com (mail-qk1-x734.google.com [IPv6:2607:f8b0:4864:20::734]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9ED40130EF1 for ; Wed, 6 Feb 2019 15:29:06 -0800 (PST) Received: by mail-qk1-x734.google.com with SMTP id z18so5404606qkj.10 for ; Wed, 06 Feb 2019 15:29:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=3NBhWI59asL2Hd+Alt0WOXqD8e6ROWqoAvsKq/AXUZA=; b=m+rgTTT+zzgb5rGh+RVAY6UE/YbMoGyMLW9HxAy2BlJWYpL8xy/0K9e3EgNhzmEz9c 61aHCohdRDztUJZZhr2MvFIg+Kt/pRZHILoNENOGIux6MCyh3jOoNwVoFPvFq6qbcBHp pmJDisjD+LhvcoYjU4rW64bZPnoWXTOkEhoo8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=3NBhWI59asL2Hd+Alt0WOXqD8e6ROWqoAvsKq/AXUZA=; b=FBfu3OmcGkg1bXcmd9FgJIFYWJ3p6X1kHj6ciRB6E/H5jzfNM+zqhgfMXPHW0GU55K y9Z/0dRW01neJ0kVqVOKX2tLBSj6ntr4kcZ5gPNRtreFrfXluH5zxb4hjlQ+jG0xX8oo bIuMW4vCJqRdfRgyMUHGKPT7JhrufJczNSiEf6OHUiCbjGFGOwvEfrk/seoXRBCD3UoH oGClJ/DoahLKEM3Sn3KnNwF7KvapuvTx8pDKyISsM3gK5s84OA17dMh2usPBpAEacbnW VUiY8KHa9b/7iUWrNP37mhlKg2c5FzDmh7KZUzni4BVVhDTsyAsYkYbGQjh/gj3ZoXHa Hw4A== X-Gm-Message-State: AHQUAuaKeBjeI9gIsmLKQ8reERX7ixcara/D+JSOscn29soAghuRWt3z QarEvWh5CjjF2zU0STvXm85ErnoyYqM= X-Google-Smtp-Source: AHgI3Ib9/csqKMBd+gQW9iYuALC43Wo50HnRk+cOJZo/+UJrbQRhFAtq+Q5MRUuFdHb3nQ4AIz7JZw== X-Received: by 2002:ae9:d8c2:: with SMTP id u185mr9038663qkf.107.1549495745755; Wed, 06 Feb 2019 15:29:05 -0800 (PST) Received: from [172.16.0.18] ([96.231.217.246]) by smtp.gmail.com with ESMTPSA id m124sm5363696qkc.16.2019.02.06.15.29.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 Feb 2019 15:29:04 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Sean Turner In-Reply-To: Date: Wed, 6 Feb 2019 18:29:02 -0500 Cc: secdir@ietf.org, draft-ietf-babel-dtls.all@ietf.org, ietf@ietf.org, Babel at IETF Content-Transfer-Encoding: quoted-printable Message-Id: <06C98B7B-4D3A-4DF6-AE9F-E82C7B8BF439@sn3rd.com> References: <154881379920.7794.15439486195773911279@ietfa.amsl.com> To: David Schinazi X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [secdir] Secdir early review of draft-ietf-babel-dtls-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2019 23:29:11 -0000 David, Thanks for following up. I am personally happy with your suggested = resolutions. spt > On Feb 1, 2019, at 19:40, David Schinazi = wrote: >=20 > Thanks for the review Sean! >=20 > I've updated the doc with your comments: > = https://github.com/jech/babel-drafts/commit/e202f664712772a4db2bd88c5665ba= 3193cd4c99 >=20 > Detailed responses inline. >=20 > David >=20 >=20 > On Wed, Jan 30, 2019 at 11:03 AM Sean Turner wrote: > Reviewer: Sean Turner > Review result: Has Nits >=20 > Hi, >=20 > David wanted to make it really easy on me and get as much early input = as he > could get by sending a msg to the TLS list asking for comments [0]. = Version > -02 addressed those comments. >=20 > I'm no babel expert, but I did take the time to read/skim the base = protocol > document to get more familiar with it as well as re-read the babel-tls = draft.=20 > The tl;dr here is that babel is multicast but DTLS is not so changes = to babel > are needed. >=20 > To clarify, the changes to make Babel work over unicast have all gone = into > the base spec: draft-ietf-babel-rfc6126bis > =20 > Here are my comments in no particular order. No show stoppers here. >=20 > 0) Since DTLS is in the RFC Editor's Abbreviations List - I think you = can get > away with: Babel Routing Protocol over DTLS But, that's up to you. >=20 > I personally prefer spelling it out, but I don't feel too strongly = about it. > =20 > 1) (IEGS food fight alert) I see that the updates header updates = 6126bis. Not > sure how this will fly in the face of the draft IESG Statement [1]. >=20 > Thanks for pointing this out. We'll follow any guidance the IESG gives = us > during their review. > =20 > 2) (This might just be document organization) The applicability = section kind of > jumped out at me because there's also an applicability draft. = Further, it and > 6126bis says the HMAC mechanism is preferred. I'd just drop the = entire section > ;) >=20 > The authors felt we should insist that HMAC is better suited for many = deployments > as it better fits with the traditional Babel multicast model. The = applicability draft > focuses on Babel itself. > =20 > 3) s2.1 - maybe add a pointer to the IANA considerations section. >=20 > Done >=20 > 4) s2.1 - Because you're doing client authentication do you need say = anything > about the type of cert, whether certificate_authorities, > signature_algorithms_cert, signature_algorithms should be sent (for = 1.3 > connections)? >=20 > We've had this conversation on the Babel mailing list, and we landed = on having the > babel-dtls draft not define any of these, punting that to the usage = profiles drafts. > For example, the Babel Homenet profile draft will define all of these. > =20 > 5) s4 - add that IANA is requested to point to this specification for = the > reference. >=20 > Done=20 >=20 > 6) AppA - I think you might need to tweak the last sentence in light = 1.3? >=20 > Unfortunately DTLS 1.3 hasn't been published yet, and I'd rather not = make > assumptions on what the RFC will say (even though we're pretty sure = the > handshake won't change between the current draft and RFC). If it gets > published as RFC before this document does, I'll make these changes. > =20 >=20 > Cheers, > spt >=20 > [0] = https://mailarchive.ietf.org/arch/msg/tls/tIaK0rgm5zCVuYmLm5qsCIvKXKw > [1] = https://mailarchive.ietf.org/arch/msg/ietf/-1u_1-peHKAmUDuLyGAJYu0fPCE >=20 From nobody Wed Feb 6 15:54:14 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF907130F82; Wed, 6 Feb 2019 15:53:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 FBTAFQUsOtbY; Wed, 6 Feb 2019 15:53:51 -0800 (PST) Received: from mail-pg1-x531.google.com (mail-pg1-x531.google.com [IPv6:2607:f8b0:4864:20::531]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1617130F9D; Wed, 6 Feb 2019 15:53:51 -0800 (PST) Received: by mail-pg1-x531.google.com with SMTP id d9so3681316pgl.1; Wed, 06 Feb 2019 15:53:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6gDTJWv0omRsc/IaSiKe8g8XyzDkn/QiKDSa+Rl0bIA=; b=kaYNZFiVPIQKLF+UpeW2VAuTAnMzNmL/ONwtvI+qdcxmyKZjVNpShjKUpz5bWf70Cb ftZJ16F7tORcL/a+B5u6LzytXQobWxbT/RbJ8z5bzUdpErTe5MkxQrZqNpmgqg4eSgv+ +tIfZeOGR04E8qQ68j9aEilOXpyhl2fqQB9N2dR5AAVXJmgZR0OBy0pyeQuJrNzfW8hq xjRxkyjeBwAF+prFfd5VtOn/wp5UwTeQd4yp2OCIS5oMwaw02zaKs0XMevL1ADbBIt/N O/0fDFoStk3GXk05CNBxYnWJDfY3geVlyj/VSeSGW1Fw1sjDaj2WUNLcxa/OLk8aae5J cjIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6gDTJWv0omRsc/IaSiKe8g8XyzDkn/QiKDSa+Rl0bIA=; b=hlcElXh0L3RG27CEOeC58LD/x8Hh9k1D7NP7J8X1wLDBtjF2jlJTE3Y47OkUfWLjaX 5o75Tw8Yz22yhlg0b5oLZ+HAI9SoJoEWfG+IrKwHZqBvgIEhzU44MhNF/rC+fbZBWvU8 h0VdMcHN8xppNJGXToRoL14tv8agEyR3xAH5LJvI14OZ934G2fofixLft9SWcA67w7TA jQdwsJNfe1bz2yMk8PkFjTQxUfgMigLiZDHoXsIFXh0UiCHz2897g71H/PIwuXKDBuag 1EQ1W/hKwKs6HZkydEzG08BL6D0aJ/jUhqE2iOAiyXaPrzhagnFkcma3NgGqaSaleLZd SR+A== X-Gm-Message-State: AHQUAuY4u8iwRfmElyYI4J+PO9Pzv1x7w6Rb9OIvrmsvE/F2ePk71LDz L3xWzO7xFrL0bqq6wkMYNgfhYDYPllgZookFgAE= X-Google-Smtp-Source: AHgI3IbRQYHZ9yFWvs6+ES3UVuC/wdgRS/Ek5utYAy7RGU3w/wbNcqXN7NZeQNKR/xH+7bB6/AHDv3PYWDeg+LDqFw0= X-Received: by 2002:a62:6ec8:: with SMTP id j191mr13245398pfc.198.1549497231149; Wed, 06 Feb 2019 15:53:51 -0800 (PST) MIME-Version: 1.0 References: <154881379920.7794.15439486195773911279@ietfa.amsl.com> In-Reply-To: From: David Schinazi Date: Wed, 6 Feb 2019 15:53:39 -0800 Message-ID: To: Donald Eastlake Cc: Sean Turner , secdir@ietf.org, draft-ietf-babel-dtls.all@ietf.org, IETF Discussion , Babel at IETF Content-Type: multipart/alternative; boundary="0000000000000b100c05814270a8" Archived-At: Subject: Re: [secdir] Secdir early review of draft-ietf-babel-dtls-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2019 23:54:01 -0000 --0000000000000b100c05814270a8 Content-Type: text/plain; charset="UTF-8" Thanks Donald and Sean. On Wed, Feb 6, 2019 at 1:53 PM Donald Eastlake wrote: > Given the advanced state of the DTLS 1.3 draft in the IETF process, I > suggest consideration be given to referencing that draft rather than > RFC 6347 and making corresponding minor changes in this draft... > I'd rather not create a blocking relationship at this point in time. I personally commit that when babel-dtls makes it to AUTH48, if DTLS 1.3 is published then I'll make the changes to babel-dtls to reference it. Thanks, David --0000000000000b100c05814270a8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Donald and Sean.

On Wed, Feb 6, 2019 at 1:53 PM Donald E= astlake <d3e3e3@gmail.com> wr= ote:
Given the advanced state of the DTLS 1.3 draft in the IETF process, I
suggest consideration be given to referencing that draft rather than
RFC 6347 and making corresponding minor changes in this draft...

I'd rather not create a blocking relationship= at this point in time.
I personally commit that when babel-dtls = makes it to AUTH48, if DTLS 1.3 is
published then I'll make t= he changes to babel-dtls to reference it.

Thanks,<= /div>
David
--0000000000000b100c05814270a8-- From nobody Thu Feb 7 05:34:42 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E3EF12872C for ; Thu, 7 Feb 2019 05:34:40 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Tero Kivinen To: X-Test-IDTracker: no X-IETF-IDTracker: 6.91.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu Message-ID: <154954648064.23447.1991403812511102819.idtracker@ietfa.amsl.com> Date: Thu, 07 Feb 2019 05:34:40 -0800 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2019 13:34:41 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2019-02-07 Reviewer LC end Draft Daniel Gillmor 2018-03-19 draft-gutmann-scep-13 Kyle Rose R2018-08-29 draft-ietf-lisp-rfc6830bis-26 Takeshi Takahashi R2018-08-31 draft-ietf-lisp-rfc6833bis-24 For telechat 2019-02-21 Reviewer LC end Draft Tero Kivinen R2018-12-28 draft-ietf-jmap-core-14 Magnus Nystrom 2019-02-04 draft-ietf-jmap-mail-14 Last calls: Reviewer LC end Draft Tobias Gondrom R2019-02-15 draft-ietf-rtcweb-security-arch-18 Leif Johansson 2018-12-24 draft-ietf-6lo-nfc-12 Russ Mundy 2017-09-14 draft-spinosa-urn-lex-13 Radia Perlman 2019-02-01 draft-ietf-payload-flexible-fec-scheme-16 Tim Polk 2019-02-13 draft-ietf-sipcore-reason-q850-loc-05 Vincent Roca 2019-02-13 draft-ietf-perc-private-media-framework-08 Kyle Rose 2019-02-12 draft-ietf-tsvwg-le-phb-08 Joseph Salowey 2019-02-11 draft-ietf-rmcat-eval-test-08 Stefan Santesson 2019-02-11 draft-ietf-extra-imap-fetch-preview-01 Stefan Santesson R2018-11-20 draft-wilde-service-link-rel-10 Yaron Sheffer 2019-02-08 draft-ietf-uta-smtp-require-tls-07 Valery Smyslov None draft-ietf-cellar-ebml-09 Robert Sparks 2019-03-05 draft-faltstrom-unicode11-07 Takeshi Takahashi 2019-02-17 draft-ietf-kitten-pkinit-alg-agility-04 Sean Turner 2019-02-19 draft-ietf-nfsv4-mv1-msns-update-04 Carl Wallace 2019-02-15 draft-ietf-rtcweb-security-11 David Waltermire 2019-02-15 draft-ietf-rtcweb-ip-handling-11 Taylor Yu 2018-11-28 draft-ietf-alto-cost-calendar-09 Early review requests: Reviewer Due Draft Daniel Franke 2018-01-31 draft-ietf-intarea-provisioning-domains-00 Next in the reviewer rotation: Samuel Weiler Brian Weis Klaas Wierenga Christopher Wood Paul Wouters Liang Xia Taylor Yu Dacheng Zhang Derek Atkins John Bradley From nobody Fri Feb 8 17:21:05 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 052AB131069; Fri, 8 Feb 2019 17:20:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.018, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 nTaJnYpocV80; Fri, 8 Feb 2019 17:20:54 -0800 (PST) Received: from mail-lf1-f51.google.com (mail-lf1-f51.google.com [209.85.167.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61605130EE9; Fri, 8 Feb 2019 17:20:54 -0800 (PST) Received: by mail-lf1-f51.google.com with SMTP id e27so3887990lfj.8; Fri, 08 Feb 2019 17:20:54 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=S+4dh1fFQE5b+xjVzp6thWnWkDWGaOm4t3qlv1cdaiw=; b=EoD7TDcrWErY3XHjLso4Bad4H2FrK4dyYpJZV6ET0KKGh+BK1yq3qxfbUoBCDxF2G+ DIUkIq1RS6NO31eXfauR5BkLAmnjWZL1v8/qRAbRLPkeE8wZ93Wo8OTOQr6RV52Rw92x 1vAnI6ZUTZJrWn5jsKWmSgn0rIa9uiP5+DX0HtL30oESppOPj2zENWT0xWt8yRjIF3RX 5uQlkLVCAmLjqd9kh7ELsffkGS8UxPbT3OFQorDXWdz7HewIoWjsieADwnZpvdZpZfs7 h+0a/aDND5O+E4dODNeXsLN0bfwuL2fHMA54/ORhJsopQtjRqzE+jIhtfH+XBlqqgwJI SWZQ== X-Gm-Message-State: AHQUAuah2kiH4rT8wf4sHNDNXinLzVjgeJeiJigZ4HrOKNN2u9RHuV0b uyj3dVC2bFsvOXFRfC/wruyllZRC2SfrAcZMXU8= X-Google-Smtp-Source: AHgI3IbMyMxx2o2BK02ZwXnMzLaN3iLBjfgybjsuT+qrtoC54AFpHYqnNEv0jwuJdp9fHp4Tjxd9MSljLT/gmvHStrM= X-Received: by 2002:ac2:4474:: with SMTP id y20mr3382017lfl.40.1549675252259; Fri, 08 Feb 2019 17:20:52 -0800 (PST) MIME-Version: 1.0 References: <201902010742.x117gdGm030846@rumpleteazer.rhmr.com> In-Reply-To: From: Justin Uberti Date: Fri, 8 Feb 2019 17:20:41 -0800 Message-ID: To: Ben Campbell Cc: Hilarie Orman , The IESG , secdir@ietf.org, draft-ietf-rtcweb-fec.all@tools.ietf.org Content-Type: multipart/alternative; boundary="000000000000eda39405816be2c0" Archived-At: Subject: Re: [secdir] Security review of draft-ietf-rtcweb-fec-08 (was Re: Security review of draft-ietf-perc-srtp-ekt-diet-08) X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Feb 2019 01:20:57 -0000 --000000000000eda39405816be2c0 Content-Type: text/plain; charset="UTF-8" On Fri, Feb 1, 2019 at 2:49 PM Ben Campbell wrote: > Hi, > > Please note that this review is for draft-ietf-rtcweb-fec-08, not the PERC > draft referenced in the subject. > > Thanks! > > Ben. > > > > On Feb 1, 2019, at 1:42 AM, Hilarie Orman > wrote: > > > > Security Review of WebRTC Forward Error Correction Requirements > > draft-ietf-rtcweb-fec-08 > > > > Do not be alarmed. I have reviewed this document as part of the > > security directorate's ongoing effort to review all IETF documents > > being processed by the IESG. These comments were written primarily > > for the benefit of the security area directors. Document editors and > > WG chairs should treat these comments just like any other last call > > comments. > > > > The document describes the appropriate uses of FEC for web content when > > using WebRTC. It also describes how to indicate that FEC is being used. > > > > The Security Considerations mention the possibility of additional network > > congestion when using FEC. Although this can be a problem, I do not > think > > it is a security issue, thus it does not belong in this section. > Understood. I think this paragraph could easily be moved to the preceding section. > > > > There is a security-related issue wrt to FEC and encryption. If the > > error model is that message blocks may be lost but not altered in > > transit, then FEC with encryption is fine. But if FEC is added for > > the purpose of correcting corrupted bits in a message block, then it > > is important that FEC is done after encryption. The draft seems to > > ignore the issue, and it also seems to recommend a processing scheme > > that would result in encryption of the FEC data. If there is a body > > of practice for other IETF FEC protocols that explains these issues, > > an explicit reference to it in the Security Considerations would be > > very helpful. > > FEC is added specifically to protect against lost blocks. Any corruption of the blocks will be detected by the decryption procedure, and such blocks will be discarded. There is a reference to RFC 3711, which stipulates the fec-then-encrypt ordering. RFC 3711 is admittedly terse on this subject, but it is quite clear about the ordering. --000000000000eda39405816be2c0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Feb 1, 2019 at 2:49 PM Ben Campbell <ben@nostrum.com> wrote:
Hi,

Please note that this review is for draft-ietf-rtcweb-fec-08, not the PERC = draft referenced in the subject.

Thanks!

Ben.


> On Feb 1, 2019, at 1:42 AM, Hilarie Orman <hilarie@purplestreak.com> wrot= e:
>
> Security Review of WebRTC Forward Error Correction Requirements
> draft-ietf-rtcweb-fec-08
>
> Do not be alarmed.=C2=A0 I have reviewed this document as part of the<= br> > security directorate's ongoing effort to review all IETF documents=
> being processed by the IESG.=C2=A0 These comments were written primari= ly
> for the benefit of the security area directors.=C2=A0 Document editors= and
> WG chairs should treat these comments just like any other last call > comments.
>
> The document describes the appropriate uses of FEC for web content whe= n
> using WebRTC.=C2=A0 It also describes how to indicate that FEC is bein= g used.
>
> The Security Considerations mention the possibility of additional netw= ork
> congestion when using FEC.=C2=A0 Although this can be a problem, I do = not think
> it is a security issue, thus it does not belong in this section.

Understood. I think this paragraph could eas= ily be moved to the preceding section.=C2=A0
>
> There is a security-related issue wrt to FEC and encryption.=C2=A0 If = the
> error model is that message blocks may be lost but not altered in
> transit, then FEC with encryption is fine.=C2=A0 But if FEC is added f= or
> the purpose of correcting corrupted bits in a message block, then it > is important that FEC is done after encryption.=C2=A0 The draft seems = to
> ignore the issue, and it also seems to recommend a processing scheme > that would result in encryption of the FEC data.=C2=A0 If there is a b= ody
> of practice for other IETF FEC protocols that explains these issues, > an explicit reference to it in the Security Considerations would be > very helpful.

FEC is added specifically to pr= otect against lost blocks. Any corruption of the blocks will be detected by= the decryption procedure, and such blocks will be discarded.
There is a reference to RFC 3711, which stipulates the fec-then= -encrypt ordering. RFC 3711 is admittedly terse on this subject, but it is = quite clear about the ordering.
--000000000000eda39405816be2c0-- From nobody Fri Feb 8 17:46:29 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EE0B1310B5; Fri, 8 Feb 2019 17:46:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 uGv1tgBwuEWL; Fri, 8 Feb 2019 17:46:19 -0800 (PST) Received: from out02.mta.xmission.com (out02.mta.xmission.com [166.70.13.232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38885130E8B; Fri, 8 Feb 2019 17:46:18 -0800 (PST) Received: from in02.mta.xmission.com ([166.70.13.52]) by out02.mta.xmission.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.87) (envelope-from ) id 1gsHij-0005Tk-SV; Fri, 08 Feb 2019 18:46:17 -0700 Received: from mta1.zcs.xmission.com ([166.70.13.65]) by in02.mta.xmission.com with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.87) (envelope-from ) id 1gsHih-0007B7-LJ; Fri, 08 Feb 2019 18:46:17 -0700 Received: from localhost (localhost [127.0.0.1]) by mta1.zcs.xmission.com (Postfix) with ESMTP id 651E51C426F; Fri, 8 Feb 2019 18:46:15 -0700 (MST) Received: from mta1.zcs.xmission.com ([127.0.0.1]) by localhost (mta1.zcs.xmission.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id PpWY9NKW452O; Fri, 8 Feb 2019 18:46:15 -0700 (MST) Received: from zms04.zcs.xmission.com (zms04.zcs.xmission.com [166.70.13.74]) by mta1.zcs.xmission.com (Postfix) with ESMTP id 346A21C4023; Fri, 8 Feb 2019 18:46:15 -0700 (MST) Date: Fri, 8 Feb 2019 18:46:15 -0700 (MST) From: Hilarie Orman To: Justin Uberti Cc: Ben Campbell , The IESG , secdir@ietf.org, draft-ietf-rtcweb-fec all Message-ID: <240284129.169422738.1549676775109.JavaMail.zimbra@purplestreak.com> In-Reply-To: References: <201902010742.x117gdGm030846@rumpleteazer.rhmr.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [72.250.219.84] X-Mailer: Zimbra 8.8.11_GA_3737 (zclient/8.8.11_GA_3737) Thread-Topic: Security review of draft-ietf-rtcweb-fec-08 (was Re: Security review of draft-ietf-perc-srtp-ekt-diet-08) Thread-Index: DdFd3PqzOZiRYIKogCzHR/HUnmbKXQ== X-XM-SPF: eid=1gsHih-0007B7-LJ; ; ; mid=<240284129.169422738.1549676775109.JavaMail.zimbra@purplestreak.com>; ; ; hst=in02.mta.xmission.com; ; ; ip=166.70.13.65; ; ; frm=hilarie@purplestreak.com; ; ; spf=none X-SA-Exim-Connect-IP: 166.70.13.65 X-SA-Exim-Mail-From: hilarie@purplestreak.com X-Spam-DCC: XMission; sa04 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ******;Justin Uberti X-Spam-Relay-Country: US X-Spam-Timing: total 1935 ms - load_scoreonly_sql: 0.05 (0.0%), signal_user_changed: 3.4 (0.2%), b_tie_ro: 2.3 (0.1%), parse: 1.80 (0.1%), extract_message_metadata: 39 (2.0%), get_uri_detail_list: 4.1 (0.2%), tests_pri_-1000: 21 (1.1%), tests_pri_-950: 1.16 (0.1%), tests_pri_-900: 1.23 (0.1%), tests_pri_-90: 30 (1.5%), check_bayes: 28 (1.4%), b_tokenize: 11 (0.6%), b_tok_get_all: 8 (0.4%), b_comp_prob: 3.6 (0.2%), b_tok_touch_all: 3.5 (0.2%), b_finish: 0.70 (0.0%), tests_pri_0: 839 (43.4%), check_dkim_signature: 0.68 (0.0%), check_dkim_adsp: 164 (8.5%), poll_dns_idle: 1109 (57.3%), tests_pri_10: 1.90 (0.1%), tests_pri_500: 987 (51.0%), rewrite_mail: 0.00 (0.0%) X-SA-Exim-Version: 4.2.1 (built Thu, 05 May 2016 13:38:54 -0600) X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com) Archived-At: Subject: Re: [secdir] Security review of draft-ietf-rtcweb-fec-08 (was Re: Security review of draft-ietf-perc-srtp-ekt-diet-08) X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Feb 2019 01:46:22 -0000 I think that the purpose of the FEC should be explicit, else the interaction with encryption will remain a source of confusion forever. Hilarie ----- Original Message ----- From: Justin Uberti To: Ben Campbell Cc: Hilarie Orman , The IESG , secdir@ietf.org, draft-ietf-rtcweb-fec all Sent: Fri, 08 Feb 2019 18:20:41 -0700 (MST) Subject: Re: Security review of draft-ietf-rtcweb-fec-08 (was Re: Security review of draft-ietf-perc-srtp-ekt-diet-08) On Fri, Feb 1, 2019 at 2:49 PM Ben Campbell wrote: > Hi, > > Please note that this review is for draft-ietf-rtcweb-fec-08, not the PERC > draft referenced in the subject. > > Thanks! > > Ben. > > > > On Feb 1, 2019, at 1:42 AM, Hilarie Orman > wrote: > > > > Security Review of WebRTC Forward Error Correction Requirements > > draft-ietf-rtcweb-fec-08 > > > > Do not be alarmed. I have reviewed this document as part of the > > security directorate's ongoing effort to review all IETF documents > > being processed by the IESG. These comments were written primarily > > for the benefit of the security area directors. Document editors and > > WG chairs should treat these comments just like any other last call > > comments. > > > > The document describes the appropriate uses of FEC for web content when > > using WebRTC. It also describes how to indicate that FEC is being used. > > > > The Security Considerations mention the possibility of additional network > > congestion when using FEC. Although this can be a problem, I do not > think > > it is a security issue, thus it does not belong in this section. > Understood. I think this paragraph could easily be moved to the preceding section. > > > > There is a security-related issue wrt to FEC and encryption. If the > > error model is that message blocks may be lost but not altered in > > transit, then FEC with encryption is fine. But if FEC is added for > > the purpose of correcting corrupted bits in a message block, then it > > is important that FEC is done after encryption. The draft seems to > > ignore the issue, and it also seems to recommend a processing scheme > > that would result in encryption of the FEC data. If there is a body > > of practice for other IETF FEC protocols that explains these issues, > > an explicit reference to it in the Security Considerations would be > > very helpful. > > FEC is added specifically to protect against lost blocks. Any corruption of the blocks will be detected by the decryption procedure, and such blocks will be discarded. There is a reference to RFC 3711, which stipulates the fec-then-encrypt ordering. RFC 3711 is admittedly terse on this subject, but it is quite clear about the ordering. From nobody Fri Feb 8 17:51:58 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD4E91310C4; Fri, 8 Feb 2019 17:51:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.018, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 L--6Vn0yGZDS; Fri, 8 Feb 2019 17:51:46 -0800 (PST) Received: from mail-lj1-f173.google.com (mail-lj1-f173.google.com [209.85.208.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF0861310C1; Fri, 8 Feb 2019 17:51:45 -0800 (PST) Received: by mail-lj1-f173.google.com with SMTP id t9-v6so4557959ljh.6; Fri, 08 Feb 2019 17:51:45 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=gVyCToMRsWFVhW59F189oc2ugbAAEp3+NGa3Eab/9pU=; b=TlFVx8pxNJHxoPpV7DlcbLTcsn/9IBThL1QTQ6As7svvgUwrrbe09LgnPfqt55FBi6 I88mftMEvRfGPLENV76akO2rWtFuEzLM3OrbHdY/pMBA0OkgsWns9z+GyBiQhKe+3j0G 8kWkIdOn7VWmVyN6/w3PbT/OVu5BlFBkcksQ5AvfdGBdcCMok2jilvMMkmzX1mnc/fEn ZYDhXmHdU96Vbe8gTVeM61hrGywgri7V1YP+MNXNWo7hULJI46fKRPIgZfkj4sDZfA+p 2gK3u2dOVB2aCs5uaf7dkAt15y2a2UNUvupI3LQbL3tjO5Fstgwj1Y99FlqrYgLpYGBP NnBA== X-Gm-Message-State: AHQUAuaoXwGf9j1hiKMK1yFmp8Fr64AxIEw7YCGTWBlZY/jGkBje7WZj wvO+AwxdJmHI7BpAn4xintV7q+BGljn5M51PwEc= X-Google-Smtp-Source: AHgI3Ibf7w6IM8PsMUIRS+dkHjZvO8I4aATdVVlRb4Zk1griIN0sGd7tOrXyVrvvHxSF1/acOmbNvasygqKI7BuyEvw= X-Received: by 2002:a2e:884b:: with SMTP id z11-v6mr8411201ljj.68.1549677103839; Fri, 08 Feb 2019 17:51:43 -0800 (PST) MIME-Version: 1.0 References: <201902010742.x117gdGm030846@rumpleteazer.rhmr.com> <240284129.169422738.1549676775109.JavaMail.zimbra@purplestreak.com> In-Reply-To: <240284129.169422738.1549676775109.JavaMail.zimbra@purplestreak.com> From: Justin Uberti Date: Fri, 8 Feb 2019 17:51:32 -0800 Message-ID: To: Hilarie Orman Cc: Ben Campbell , The IESG , secdir@ietf.org, draft-ietf-rtcweb-fec all Content-Type: multipart/alternative; boundary="0000000000004a7e4c05816c51ab" Archived-At: Subject: Re: [secdir] Security review of draft-ietf-rtcweb-fec-08 (was Re: Security review of draft-ietf-perc-srtp-ekt-diet-08) X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Feb 2019 01:51:49 -0000 --0000000000004a7e4c05816c51ab Content-Type: text/plain; charset="UTF-8" Any suggestions on the sort of text you would like to see? e.g. "In the WebRTC context, FEC is specifically concerned with recovering data from lost packets; any corrupted packets will be discarded by the SRTP decryption process. Therefore, as described in [RFC3711], Section 10..." On Fri, Feb 8, 2019 at 5:46 PM Hilarie Orman wrote: > I think that the purpose of the FEC should be explicit, else the > interaction with > encryption will remain a source of confusion forever. > > Hilarie > > ----- Original Message ----- > From: Justin Uberti > To: Ben Campbell > Cc: Hilarie Orman , The IESG , > secdir@ietf.org, draft-ietf-rtcweb-fec all < > draft-ietf-rtcweb-fec.all@tools.ietf.org> > Sent: Fri, 08 Feb 2019 18:20:41 -0700 (MST) > Subject: Re: Security review of draft-ietf-rtcweb-fec-08 (was Re: Security > review of draft-ietf-perc-srtp-ekt-diet-08) > > On Fri, Feb 1, 2019 at 2:49 PM Ben Campbell wrote: > > > Hi, > > > > Please note that this review is for draft-ietf-rtcweb-fec-08, not the > PERC > > draft referenced in the subject. > > > > Thanks! > > > > Ben. > > > > > > > On Feb 1, 2019, at 1:42 AM, Hilarie Orman > > wrote: > > > > > > Security Review of WebRTC Forward Error Correction Requirements > > > draft-ietf-rtcweb-fec-08 > > > > > > Do not be alarmed. I have reviewed this document as part of the > > > security directorate's ongoing effort to review all IETF documents > > > being processed by the IESG. These comments were written primarily > > > for the benefit of the security area directors. Document editors and > > > WG chairs should treat these comments just like any other last call > > > comments. > > > > > > The document describes the appropriate uses of FEC for web content when > > > using WebRTC. It also describes how to indicate that FEC is being > used. > > > > > > The Security Considerations mention the possibility of additional > network > > > congestion when using FEC. Although this can be a problem, I do not > > think > > > it is a security issue, thus it does not belong in this section. > > > > Understood. I think this paragraph could easily be moved to the preceding > section. > > > > > > > There is a security-related issue wrt to FEC and encryption. If the > > > error model is that message blocks may be lost but not altered in > > > transit, then FEC with encryption is fine. But if FEC is added for > > > the purpose of correcting corrupted bits in a message block, then it > > > is important that FEC is done after encryption. The draft seems to > > > ignore the issue, and it also seems to recommend a processing scheme > > > that would result in encryption of the FEC data. If there is a body > > > of practice for other IETF FEC protocols that explains these issues, > > > an explicit reference to it in the Security Considerations would be > > > very helpful. > > > > FEC is added specifically to protect against lost blocks. Any corruption > of the blocks will be detected by the decryption procedure, and such blocks > will be discarded. > > There is a reference to RFC 3711, which stipulates the fec-then-encrypt > ordering. RFC 3711 is admittedly terse on this subject, but it is quite > clear about the ordering. > > --0000000000004a7e4c05816c51ab Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Any suggestions on the sort of text you would like to see?= =C2=A0

e.g. "In the WebRTC context, FEC is specific= ally concerned with recovering data from lost packets; any corrupted packet= s will be discarded by the SRTP decryption process. Therefore, as described= in [RFC3711], Section 10..."

On Fri, Feb 8, 2019 at 5:46 PM Hila= rie Orman <hilarie@purplestr= eak.com> wrote:
I think that= the purpose of the FEC should be explicit, else the interaction with
encryption will remain a source of confusion forever.

Hilarie=C2=A0

----- Original Message -----
From: Justin Uberti <justin@uberti.name>
To: Ben Campbell <b= en@nostrum.com>
Cc: Hilarie Orman <hilarie@purplestreak.com>, The IESG <iesg@ietf.org>, secdir@ietf.org, draft-ietf-rtcweb-fec= all <draft-ietf-rtcweb-fec.all@tools.ietf.org>
Sent: Fri, 08 Feb 2019 18:20:41 -0700 (MST)
Subject: Re: Security review of draft-ietf-rtcweb-fec-08 (was Re: Security = review of draft-ietf-perc-srtp-ekt-diet-08)

On Fri, Feb 1, 2019 at 2:49 PM Ben Campbell <ben@nostrum.com> wrote:

> Hi,
>
> Please note that this review is for draft-ietf-rtcweb-fec-08, not the = PERC
> draft referenced in the subject.
>
> Thanks!
>
> Ben.
>
>
> > On Feb 1, 2019, at 1:42 AM, Hilarie Orman <hilarie@purplestreak.com>=
> wrote:
> >
> > Security Review of WebRTC Forward Error Correction Requirements > > draft-ietf-rtcweb-fec-08
> >
> > Do not be alarmed.=C2=A0 I have reviewed this document as part of= the
> > security directorate's ongoing effort to review all IETF docu= ments
> > being processed by the IESG.=C2=A0 These comments were written pr= imarily
> > for the benefit of the security area directors.=C2=A0 Document ed= itors and
> > WG chairs should treat these comments just like any other last ca= ll
> > comments.
> >
> > The document describes the appropriate uses of FEC for web conten= t when
> > using WebRTC.=C2=A0 It also describes how to indicate that FEC is= being used.
> >
> > The Security Considerations mention the possibility of additional= network
> > congestion when using FEC.=C2=A0 Although this can be a problem, = I do not
> think
> > it is a security issue, thus it does not belong in this section.<= br> >

Understood. I think this paragraph could easily be moved to the preceding section.

> >
> > There is a security-related issue wrt to FEC and encryption.=C2= =A0 If the
> > error model is that message blocks may be lost but not altered in=
> > transit, then FEC with encryption is fine.=C2=A0 But if FEC is ad= ded for
> > the purpose of correcting corrupted bits in a message block, then= it
> > is important that FEC is done after encryption.=C2=A0 The draft s= eems to
> > ignore the issue, and it also seems to recommend a processing sch= eme
> > that would result in encryption of the FEC data.=C2=A0 If there i= s a body
> > of practice for other IETF FEC protocols that explains these issu= es,
> > an explicit reference to it in the Security Considerations would = be
> > very helpful.
>
> FEC is added specifically to protect against lost blocks. Any corrupti= on
of the blocks will be detected by the decryption procedure, and such blocks=
will be discarded.

There is a reference to RFC 3711, which stipulates the fec-then-encrypt
ordering. RFC 3711 is admittedly terse on this subject, but it is quite
clear about the ordering.

--0000000000004a7e4c05816c51ab-- From nobody Fri Feb 8 20:38:49 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEBEB131156; Fri, 8 Feb 2019 20:38:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 SkunHuW-Pir1; Fri, 8 Feb 2019 20:38:42 -0800 (PST) Received: from out03.mta.xmission.com (out03.mta.xmission.com [166.70.13.233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4946E131148; Fri, 8 Feb 2019 20:38:42 -0800 (PST) Received: from in01.mta.xmission.com ([166.70.13.51]) by out03.mta.xmission.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.87) (envelope-from ) id 1gsKPW-0008Ix-Rr; Fri, 08 Feb 2019 21:38:38 -0700 Received: from mta3.zcs.xmission.com ([166.70.13.67]) by in01.mta.xmission.com with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.87) (envelope-from ) id 1gsKPL-0001U8-F6; Fri, 08 Feb 2019 21:38:38 -0700 Received: from localhost (localhost [127.0.0.1]) by mta3.zcs.xmission.com (Postfix) with ESMTP id 33584163645; Fri, 8 Feb 2019 21:38:27 -0700 (MST) Received: from mta3.zcs.xmission.com ([127.0.0.1]) by localhost (mta3.zcs.xmission.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 9nvHAns0QkAO; Fri, 8 Feb 2019 21:38:27 -0700 (MST) Received: from zms04.zcs.xmission.com (zms04.zcs.xmission.com [166.70.13.74]) by mta3.zcs.xmission.com (Postfix) with ESMTP id 00650163624; Fri, 8 Feb 2019 21:38:26 -0700 (MST) Date: Fri, 8 Feb 2019 21:38:26 -0700 (MST) From: Hilarie Orman To: Justin Uberti Cc: Ben Campbell , The IESG , secdir@ietf.org, draft-ietf-rtcweb-fec all Message-ID: <1466140720.170234113.1549687106882.JavaMail.zimbra@purplestreak.com> In-Reply-To: References: <201902010742.x117gdGm030846@rumpleteazer.rhmr.com> <240284129.169422738.1549676775109.JavaMail.zimbra@purplestreak.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [72.250.219.84] X-Mailer: Zimbra 8.8.11_GA_3737 (zclient/8.8.11_GA_3737) Thread-Topic: Security review of draft-ietf-rtcweb-fec-08 (was Re: Security review of draft-ietf-perc-srtp-ekt-diet-08) Thread-Index: xKHbdHurS2H/38kogT3ATntvPG3Nzw== X-XM-SPF: eid=1gsKPL-0001U8-F6; ; ; mid=<1466140720.170234113.1549687106882.JavaMail.zimbra@purplestreak.com>; ; ; hst=in01.mta.xmission.com; ; ; ip=166.70.13.67; ; ; frm=hilarie@purplestreak.com; ; ; spf=none X-SA-Exim-Connect-IP: 166.70.13.67 X-SA-Exim-Mail-From: hilarie@purplestreak.com X-Spam-DCC: XMission; sa02 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ******;Justin Uberti X-Spam-Relay-Country: US X-Spam-Timing: total 11106 ms - load_scoreonly_sql: 0.04 (0.0%), signal_user_changed: 3.2 (0.0%), b_tie_ro: 2.3 (0.0%), parse: 1.33 (0.0%), extract_message_metadata: 23 (0.2%), get_uri_detail_list: 3.8 (0.0%), tests_pri_-1000: 3.3 (0.0%), tests_pri_-950: 0.79 (0.0%), tests_pri_-900: 0.81 (0.0%), tests_pri_-90: 25 (0.2%), check_bayes: 24 (0.2%), b_tokenize: 8 (0.1%), b_tok_get_all: 8 (0.1%), b_comp_prob: 2.2 (0.0%), b_tok_touch_all: 3.4 (0.0%), b_finish: 0.65 (0.0%), tests_pri_0: 4768 (42.9%), check_dkim_signature: 0.46 (0.0%), check_dkim_adsp: 4422 (39.8%), poll_dns_idle: 10667 (96.1%), tests_pri_10: 1.66 (0.0%), tests_pri_500: 6272 (56.5%), rewrite_mail: 0.00 (0.0%) X-SA-Exim-Version: 4.2.1 (built Thu, 05 May 2016 13:38:54 -0600) X-SA-Exim-Scanned: Yes (on in01.mta.xmission.com) Archived-At: Subject: Re: [secdir] Security review of draft-ietf-rtcweb-fec-08 (was Re: Security review of draft-ietf-perc-srtp-ekt-diet-08) X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Feb 2019 04:38:45 -0000 OK, that's good. Hilarie -- ----- Original Message ----- From: Justin Uberti To: Hilarie Orman Cc: Ben Campbell , The IESG , secdir@ietf.org, draft-ietf-rtcweb-fec all Sent: Fri, 08 Feb 2019 18:51:32 -0700 (MST) Subject: Re: Security review of draft-ietf-rtcweb-fec-08 (was Re: Security review of draft-ietf-perc-srtp-ekt-diet-08) Any suggestions on the sort of text you would like to see? e.g. "In the WebRTC context, FEC is specifically concerned with recovering data from lost packets; any corrupted packets will be discarded by the SRTP decryption process. Therefore, as described in [RFC3711], Section 10..." On Fri, Feb 8, 2019 at 5:46 PM Hilarie Orman wrote: > I think that the purpose of the FEC should be explicit, else the > interaction with > encryption will remain a source of confusion forever. > > Hilarie > > ----- Original Message ----- > From: Justin Uberti > To: Ben Campbell > Cc: Hilarie Orman , The IESG , > secdir@ietf.org, draft-ietf-rtcweb-fec all < > draft-ietf-rtcweb-fec.all@tools.ietf.org> > Sent: Fri, 08 Feb 2019 18:20:41 -0700 (MST) > Subject: Re: Security review of draft-ietf-rtcweb-fec-08 (was Re: Security > review of draft-ietf-perc-srtp-ekt-diet-08) > > On Fri, Feb 1, 2019 at 2:49 PM Ben Campbell wrote: > > > Hi, > > > > Please note that this review is for draft-ietf-rtcweb-fec-08, not the > PERC > > draft referenced in the subject. > > > > Thanks! > > > > Ben. > > > > > > > On Feb 1, 2019, at 1:42 AM, Hilarie Orman > > wrote: > > > > > > Security Review of WebRTC Forward Error Correction Requirements > > > draft-ietf-rtcweb-fec-08 > > > > > > Do not be alarmed. I have reviewed this document as part of the > > > security directorate's ongoing effort to review all IETF documents > > > being processed by the IESG. These comments were written primarily > > > for the benefit of the security area directors. Document editors and > > > WG chairs should treat these comments just like any other last call > > > comments. > > > > > > The document describes the appropriate uses of FEC for web content when > > > using WebRTC. It also describes how to indicate that FEC is being > used. > > > > > > The Security Considerations mention the possibility of additional > network > > > congestion when using FEC. Although this can be a problem, I do not > > think > > > it is a security issue, thus it does not belong in this section. > > > > Understood. I think this paragraph could easily be moved to the preceding > section. > > > > > > > There is a security-related issue wrt to FEC and encryption. If the > > > error model is that message blocks may be lost but not altered in > > > transit, then FEC with encryption is fine. But if FEC is added for > > > the purpose of correcting corrupted bits in a message block, then it > > > is important that FEC is done after encryption. The draft seems to > > > ignore the issue, and it also seems to recommend a processing scheme > > > that would result in encryption of the FEC data. If there is a body > > > of practice for other IETF FEC protocols that explains these issues, > > > an explicit reference to it in the Security Considerations would be > > > very helpful. > > > > FEC is added specifically to protect against lost blocks. Any corruption > of the blocks will be detected by the decryption procedure, and such blocks > will be discarded. > > There is a reference to RFC 3711, which stipulates the fec-then-encrypt > ordering. RFC 3711 is admittedly terse on this subject, but it is quite > clear about the ordering. > > From nobody Sat Feb 9 15:18:01 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E5771130F99; Sat, 9 Feb 2019 15:04:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1549753471; bh=ZeryWLjy8kfrv+MU5/jH9OP6zNyNe43dKYgZ7UAaiN8=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:Cc; b=eVGF8dzvXlQREZ1gPB0IYjCWfrYYIPf3tOVNpX8oeHCyMn5+AeLbx1xeSV7ZCZ7LR Xn5IZViFQ6hNG73lb6datwbtMrrf6H9y6Pb1JSlu6CNlhpjsqK0kgGcBmzuY2K1/kv bYzPILs+tyXCF+A3RbNpgvbd/13M7CdatFGlTAqk= X-Mailbox-Line: From new-work-bounces@ietf.org Sat Feb 9 15:04:31 2019 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4267D130F90; Sat, 9 Feb 2019 15:04:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1549753471; bh=ZeryWLjy8kfrv+MU5/jH9OP6zNyNe43dKYgZ7UAaiN8=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:Cc; b=eVGF8dzvXlQREZ1gPB0IYjCWfrYYIPf3tOVNpX8oeHCyMn5+AeLbx1xeSV7ZCZ7LR Xn5IZViFQ6hNG73lb6datwbtMrrf6H9y6Pb1JSlu6CNlhpjsqK0kgGcBmzuY2K1/kv bYzPILs+tyXCF+A3RbNpgvbd/13M7CdatFGlTAqk= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 213D8130E6A for ; Sat, 9 Feb 2019 15:04:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Ja478cTF7ca3 for ; Sat, 9 Feb 2019 15:04:26 -0800 (PST) Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11BD8130F90 for ; Sat, 9 Feb 2019 15:04:26 -0800 (PST) Received: by mail-qt1-x82e.google.com with SMTP id o6so8197564qtk.6 for ; Sat, 09 Feb 2019 15:04:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:mime-version:thread-index :content-language; bh=WaGT40TsEv3VCIDo0J29N6jxyPe4bR438k7AjZnKWWs=; b=RdRFhYJjmcwl8XDc71BBOhqeKnCK/dKcwXH3CnDB6E5d0R9D1g1Vtw2bcFhhbkT85z UBH7mtGTxOhZwIUyZ6p3EMOeb+Yar5Et0G9iUPvtOwu4BMEFrnQZWqXy9AhV6d4OQ8cG nKzDb78bJMg7P8xkp1wo8+VyScS0nEOf5An6ZMQMT2hGtPvV+ibGORTTNhSct3CRN69v FujMaqc4WLKXAqCyF109xp4SK8eezmetN3JLNISSu+ojo4hyJOp2VGVKklNKcDdBGJTC ZI2KgxhgWmzHgrkx/dQJeiGB6ZA59qpJXQakiis5OkuoOg2gMRUPr8UE6R0TTvrDwt8V aAzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :thread-index:content-language; bh=WaGT40TsEv3VCIDo0J29N6jxyPe4bR438k7AjZnKWWs=; b=NdJVtT4oCft0QMwu0rFXdFLxa2dZUb+oNNmpqbObogyWLxkGYd9S5vu8kqpfZV8R9M TRAAwrU7hjhq95QViq8q11yq0fAtNIFQQF8AA9DpQN6n4fHPWIjVjJT+b7ESChzi/obd 7FGsS0EA9tzSfIEs9VFdPKYN2pS2zM8sUO+32GrLKkLw6HqhKU8iwDr/Xd5LebsUgVCc h3FET7q4nvQd5gXLKF/x7hND/U+TSN8RSdZ3IKUPW3QcH7guPZj2CdadFSly60wYKJLc gzyyHxwrBhfuQsPxlirMHAgDWfkVD5u15M4fEOw6Ee14ij6olnAvRdqOKwYThXN9r6ij yP7A== X-Gm-Message-State: AHQUAualPjOj2M52NlqYZPcH8i2QYGRHjnTooIKFw5t3f8eTFMarYU6U LS4GqPg0QE5j+77luEPg4pc= X-Google-Smtp-Source: AHgI3Ib6/vW/f2op0tFT966euEbOUoq2z2NCLlr3RzU6s/oha9DgNcX3Nf5YG9skhKQ/oXGN1q3c9Q== X-Received: by 2002:a0c:8062:: with SMTP id 89mr15915618qva.181.1549753464925; Sat, 09 Feb 2019 15:04:24 -0800 (PST) Received: from DESKTOPGUNUVB7 ([152.208.106.92]) by smtp.gmail.com with ESMTPSA id 12sm19405049qka.83.2019.02.09.15.04.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 09 Feb 2019 15:04:24 -0800 (PST) From: "John DAmbrosia" To: Date: Sat, 9 Feb 2019 18:04:24 -0500 Message-ID: <13c301d4c0cb$ce21c240$6a6546c0$@gmail.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdTAy66722xJ8PF5S2y36ESBzt3+Bg== Content-Language: en-us Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.29 Precedence: list Cc: "'Stanley, Dorothy'" , p.nikolich@ieee.org Content-Type: multipart/mixed; boundary="===============1151100421859368831==" Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Sat, 09 Feb 2019 15:18:00 -0800 Subject: [secdir] [new-work] IEEE 802 Mar 2019 PAR / ICAID Under Consideration X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Feb 2019 23:04:33 -0000 This is a multipart message in MIME format. --===============1151100421859368831== Content-Type: multipart/alternative; boundary="----=_NextPart_000_13C4_01D4C0A1.E54D67F0" Content-Language: en-us This is a multipart message in MIME format. ------=_NextPart_000_13C4_01D4C0A1.E54D67F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit All, The following Project Authorization Request (PAR) and Industry Connections Activity Initiation Document (ICAID) will be considered at the Nov 2018 IEEE 802 Plenary: * 802.1 Industry Connections: Network Enhancements for the Next Decade Industry Connections Activity (Nendica) ICAID Extension and background * 802.3cu - Amendment, 100 Gb/s and 400 Gb/s Operation over Single-Mode Fiber, PAR and CSD The PARs and ICAID can be found at http://www.ieee802.org/PARs.shtml along with the supporting IEEE 802 Criteria for Standards Development, or CSD, (which includes the 5 criteria, i.e. the explanations of how they fit the IEEE 802 criteria for initiating new work). Any comments on a proposed PAR / ICAID should be sent to the Working Group chair identified on the respective document to be received by 6:30 PM PDT, Tuesday, Mar 12 (2:30 am UTC, Mar 13, 2019) Regards, John D'Ambrosia Recording Secretary, IEEE 802 LMSC ------=_NextPart_000_13C4_01D4C0A1.E54D67F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable IEEE 802 Mar 2019 PAR / ICAID Under Consideration

All,

The following = Project Authorization Request (PAR) and Industry Connections Activity = Initiation Document (ICAID) will be considered at the Nov 2018 IEEE 802 = Plenary:

·       802.1 Industry Connections: = Network Enhancements = for the Next Decade Industry Connections Activity = (Nendica) ICAID = Extension = and background

·       802.3cu - Amendment, 100 Gb/s = and 400 Gb/s Operation over Single-Mode Fiber, PAR and = CSD

The PARs and ICAID can be found at http://www.ieee802.org/PARs.shtml along with the supporting IEEE = 802 Criteria for Standards Development, or CSD, (which includes the 5 = criteria, i.e. the explanations of how they fit the IEEE 802 criteria = for initiating new work).

Any comments on = a proposed PAR / ICAID should be sent to the Working Group chair = identified on the respective document to be received by 6:30 = PM PDT, Tuesday, Mar = 12 (2:30 am = UTC, = Mar 13, 2019)

Regards,

John D’Ambrosia

Recording = Secretary, IEEE 802 LMSC

------=_NextPart_000_13C4_01D4C0A1.E54D67F0-- --===============1151100421859368831== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work --===============1151100421859368831==-- From nobody Sat Feb 9 22:23:29 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4EBD128CE4; Sat, 9 Feb 2019 22:23:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 FDgFCnCx6Gko; Sat, 9 Feb 2019 22:23:24 -0800 (PST) Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E73E5130E79; Sat, 9 Feb 2019 22:23:23 -0800 (PST) Received: by mail-lj1-x234.google.com with SMTP id v14-v6so6282628ljv.1; Sat, 09 Feb 2019 22:23:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=J0EWBIdPFU2SKSQD+sGmjdAuvAwtTFRvqFO6ExHLFAw=; b=tNOOPrK2qDHB39Yjct+DUKhdki0PMkVNIAJFcwNBEH7PL2XbrxOx/4exJEzhXKMcCK 5sC4Na2dolY3nEPs8X9IteRZrrPlK2G+1gnZ4SqFfzJjHQ/Mpu4ODJYlhf+p0bNet42m Ipv9vvu8023pNBi6AlesHgcp+F0MHL3CG/NdWsqq9J8hJVEd3wc5oifVMcb106sYXgtX fwatPLDOdP0eTvDxV4yfQlOye6VZyw6U98DHy3sxROMH5VVluDlweuL8TcOlGGiXcyad tOBYNR4VWuaNvhG19bHccGiNGKZaS+bYH3xEvlLceiuhc1eRg+wlr8JLFL7KFuBL0VfG jLHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=J0EWBIdPFU2SKSQD+sGmjdAuvAwtTFRvqFO6ExHLFAw=; b=HSXAzEhIPfeV2dWU71nPicYd4pNCv+jse8E4Ys+Lm+mbHJaP7VqJbSb7h6MVpW39Fa ididiiQBlvMBuCksVh1ZiaAIlVcoJFzfTJ2oKx4EHJclsfq6HFL4qVb4/HHGN5hHiay7 iy9sQuJGVlueG8+DuQ3nvRqlCzgpvunIMjBFnPTMdt/2xfrX/JDdS/buchC1xGZQYAgt 611NUsDbVhANYWJqaroT6ET2+HUPF2NB25oIFTucRwf8FRqk2BCVr+PgxcmNrOoBnmei xKCHv0/di8pvRlLOXwisF+QF41TxkBkt0225wWuHx63OHkq/T1oALB+FzaljQgC994CM xQpw== X-Gm-Message-State: AHQUAuZHGETrOnovyTo7swmDwU70ArYWV8GnaPcOqo8FNPckJ7IS9zW/ Er/SlhGSV1sUYOFXvwDDhPzi6LeWsW3ULSfKsUuox7bY X-Google-Smtp-Source: AHgI3IYFabv8olA1b9vFT5J7ESEY/QLHQ18V1Cz1fwvJAF5YO+i9gqmJ0hGdWb9SGPLy7MMxXOd8aZ8bOblHjSWc3Fc= X-Received: by 2002:a2e:6a13:: with SMTP id f19-v6mr18383355ljc.41.1549779801220; Sat, 09 Feb 2019 22:23:21 -0800 (PST) MIME-Version: 1.0 From: Radia Perlman Date: Sat, 9 Feb 2019 22:23:10 -0800 Message-ID: To: The IESG , secdir@ietf.org, draft-ietf-payload-flexible-fec-scheme.all@ietf.org Content-Type: multipart/alternative; boundary="0000000000008829120581843a1a" Archived-At: Subject: [secdir] Secdir review of draft-ietf-payload-flexible-fec-scheme-16 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Feb 2019 06:23:27 -0000 --0000000000008829120581843a1a Content-Type: text/plain; charset="UTF-8" I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This specification defines a format for sending Forward Error Correction packets to allow occasional lost packets in a Real Time Protocol (RTP) stream to be recovered without retransmission. The format for these packets includes XORs of a series of packets which allows any one of the series to be recovered if the repair packet is received. To support the case of more than a single data packet being lost, it allows both horizontal and vertical parity to be computed over an n*m array of packets. This is important because the most frequent cause of packet loss is congestion, and congestion frequently loses multiple packets in succession. There are more mathematically sophisticated algorithms that would permit recovery of more general sets of lost packets, but they would require more computation to recover and more debate to specify. Most standard FEC algorithms assume that a certain number of bits received are incorrect, where this algorithm assumes that packets are never received incorrectly but are sometimes not received at all. This algorithm is not designed to recover from security attacks or more complex failures. Security Considerations mentions multiple ways that an RTP stream can be protected. I would quibble that the list includes TLS, which is probably not appropriate. TLS requires that all data packets be received and requests retransmission should packets be lost. That would remove any benefit from having FEC packets. Use of DTLS would be an appropriate protocol to use, however. Other thoughts: Given that most packet loss is caused by congestion, and very frequently congestion loses multiple packets from a stream, I'm surprised that sending repair packets based on an adjacent sequence of packets is effective (especially since sending those packets will increase congestion losses). Column based protection is more likely to be effective, but only if the rows are long enough that a sequence of packets lost due to congestion would all fit in a single row. On the other hand, lost packet recovery can take up to the amount of time to receive n*m packets, so that value must be small enough that the recovered packets are still useful given that this is a real time protocol. It would be useful to publish information on losses experienced in actual use in order to help designers tune their parameters. Radia --0000000000008829120581843a1a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I have reviewed this document as par= t of the security directorate's ongoing effort to review all IETF docum= ents being processed by the IESG.=C2=A0 These comments were written primari= ly for the benefit of the security area directors.=C2=A0 Document editors a= nd WG chairs should treat these comments just like any other last call comm= ents.

This specification defines a format for send= ing Forward Error Correction packets to allow occasional lost packets in a = Real Time Protocol (RTP) stream to be recovered without retransmission. The= format for these packets includes XORs of a series of packets which allows= any one of the series to be recovered if the repair packet is received. To= support the case of more than a single data packet being lost, it allows b= oth horizontal and vertical parity to be computed over an n*m array of pack= ets. This is important because the most frequent cause of packet loss is co= ngestion, and congestion frequently loses multiple packets in succession.

There are more mathematically sophisticated algorit= hms that would permit recovery of more general sets of lost packets, but th= ey would require more computation to recover and more debate to specify. Mo= st standard FEC algorithms assume that a certain number of bits received ar= e incorrect, where this algorithm assumes that packets are never received i= ncorrectly but are sometimes not received at all. This algorithm is not des= igned to recover from security attacks or more complex failures.
=
Security Considerations mentions multiple ways that an RTP s= tream can be protected. I would quibble that the list includes TLS, which i= s probably not appropriate. TLS requires that all data packets be received = and requests retransmission should packets be lost. That would remove any b= enefit from having FEC packets. Use of DTLS would be an appropriate protoco= l to use, however.

Other thoughts:

<= /div>
Given that most packet loss is caused by congestion, and very fre= quently congestion loses multiple packets from a stream, I'm surprised = that sending repair packets based on an adjacent sequence of packets is eff= ective (especially since sending those packets will increase congestion los= ses). Column based protection is more likely to be effective, but only if t= he rows are long enough that a sequence of packets lost due to congestion w= ould all fit in a single row. On the other hand, lost packet recovery can t= ake up to the amount of time to receive n*m packets, so that value must be = small enough that the recovered packets are still useful given that this is= a real time protocol. It would be useful to publish information on losses = experienced in actual use in order to help designers tune their parameters.=

Radia
--0000000000008829120581843a1a-- From nobody Sun Feb 10 11:23:52 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AA69128CF2; Sun, 10 Feb 2019 11:23:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=earthlink.net; domainkeys=pass (2048-bit key) header.from=charles.perkins@earthlink.net header.d=earthlink.net 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 NK3tYqQLvX5Q; Sun, 10 Feb 2019 11:23:39 -0800 (PST) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B96FC126C15; Sun, 10 Feb 2019 11:23:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=earthlink.net; s=dk12062016; t=1549826619; bh=ZcTQZjeFQ6q3ALM+X7rOt72ZvJPz8rhLPCd0 zGRso8o=; h=Received:Subject:To:References:From:Message-ID:Date: User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Language: X-ELNK-Trace:X-Originating-IP; b=Z17BviYMvVWL7nv8yzemkSU8+TvAo5MC8 ZhEfLtwfTqa2qqxx7QohtC1w8xYOOvHI9JabOydfX/zg6BX1R4OcVuAZsL5pDgcPCr1 RzK5vFo7wIx0kqOBbGq0VAF9/vze5GP2b7ZX6AAd4lvvT2Y/heRdkvOXhlis1z5Pi+U NNzOEVbRik1btPL0ftKcim22S2oFjmFetd58RcCcXRo7JPciiUDeqPnkeGWWgok9nMd XXznalrgEzOoawU78fxoAgTswR1WjQd6skypF/axsawdFUwYu8uE1AieNPKMLlSKjim 7L2iPzFQQpK8vR+il3yFjP+dtSRURgEEvK/tF8n9Q== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk12062016; d=earthlink.net; b=Z4UBkE4qqz/3tgyDLv1VzCakv+iuGwblLcsEwjMyjlmU01Gg8slp/FrartCWE6BxG/EQdG/CR9vvJjcrCGEu7kohkqQbgDhycbSs87S5757HNLuBmiSmn7Bm2beFKRw28oYHZlr4PrfTRU1+4lyWZ6jXxG1eDY+zy1j5HKRawMFt/raShxvz5P0ZrJUAM9vEXQcSnc5D7luMIN+yqgMHsmLaFtzPrD+nZrxrQkYDauGegzhvaQyG5m53B4CK1EKSNYf75cTVIFNplwboweaAfCe7CDl/KZQUTqQCrN5vcGJw0w8czFkjRzAkxPjfFctakFC8qP8lufagvft9ufchkw==; h=Received:Subject:To:References:From:Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Language:X-ELNK-Trace:X-Originating-IP; Received: from [99.51.72.196] (helo=[192.168.1.82]) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4) (envelope-from ) id 1gsuhV-00046Q-66; Sun, 10 Feb 2019 14:23:37 -0500 To: Charlie Kaufman , "secdir@ietf.org" , "iesg@ietf.org" , "draft-ietf-6lo-deadline-time.all@ietf.org" References: From: Charlie Perkins Message-ID: <96b8684a-1319-7f89-8e1e-28e8bc154e55@earthlink.net> Date: Sun, 10 Feb 2019 11:23:33 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------1B31471C5593DF9BA0EA6D53" Content-Language: en-US X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956846b590522b13c953b9a430e6c29e61fa5f08993193ad228350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.72.196 Archived-At: Subject: Re: [secdir] Secdir review of draft-ietf-6lo-deadline-time-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Feb 2019 19:23:42 -0000 This is a multi-part message in MIME format. --------------1B31471C5593DF9BA0EA6D53 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hello Charlie K., Thanks for your review and comments. I have made some follow-up interspersed with your comments below. On 12/23/2018 8:08 PM, Charlie Kaufman wrote: > > ... > > One of the challenges facing this design is maintaining tight clock > synchronization between packet forwarding devices. The design assumes > that sets of such devices are held in tight synchronization through > unspecified mechanisms. These groupings are called "time zones". It > also calls for the origination time and delivery deadline fields be > updated when a packet transitions between "time zones" (which assumes > that packet forwarding devices on separating two time zones be aware > of the time difference between them so that it can update those fields). > I think the intention was to obey transitions between time zones as we usually think of them (Pacific, Central European, etc.). The border routers could be expected to have the timezone information configured. > > > Section 6 specifies that when one of these packets is encapsulated and > sent through an IPv6 in IPv6 tunnel, and tunnel exit the time fields > must be copied from the outer header to the inner header before the > packet is forwarded on. This would be true of any form of > encapsulation, in particular including IPsec tunnelling. > Would it be O.K. if we simply deleted "IPv6-in-IPv6" from that sentence? > > Many time synchronization protocols - particularly those that target > subsecond synchronization - assume they are running on a secure > network (or that attackers would not be motivated to mess up time > synchronization). If the time synchronization between the packet > forwarding devices were to be broken such that there was substantial > drift between the devices, that could be used as a denial of service > attack if that could be used to cause most or all data packets to be > discarded as expired. > I think that a lot of things go wrong if the synchronization between the networks is broken. As mentioned in the document draft-ietf-ntp-packet-timestamps, we need to consider whether or not to include a new subsection about "Synchronization Aspects". > > > ... I eventually concluded that only the DT field was intended to be > used for this purpose and the OT field was intended to be used to > track delivery performance and is not used in the calculation of > packet lifetime. Assuming I have that right, it would be good if it > were more explicit in the document. > Thanks for this feedback; we will find a way to make the distinction more explicit. > > The bit bummer in me was offended by the fact that the TU and EXP > fields had two different ways of representing 1 second time > granularity (TU=00/EXP=110 and TU=01/EXP=000). Given that time > granularity greater than 10 seconds is never likely to be needed, the > need for the TU=01 code point is questionable, but at the least > perhaps the spec should say which is the preferred encoding. > We are going to rework the time representation to be in accordance with the abovementioned document draft-ietf-ntp-packet-timestamps. I think this will resolve the concern you have raised. > I also could not tell whether the encoding was expected to be constant > within a Time Zone (in which case the fields would not be necessary in > every packet) or whether packet relay nodes were expected to > canonicalize the time representation whenever it parses a packet. But > this is only a matter of taste. > I have always thought that the encoding would be constant from end to end. We should have also made that explicit. Do you think there is a good reason to allow the encoding to be chosen on a hop-by-hop basis? Thanks again! Regards, Charlie P. --------------1B31471C5593DF9BA0EA6D53 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Hello Charlie K.,


Thanks for your review and comments. I have made some follow-up interspersed with your comments below.


On 12/23/2018 8:08 PM, Charlie Kaufman wrote:

...

One of the challenges facing this design is maintaining tight clock synchronization between packet forwarding devices. The design assumes that sets of such devices are held in tight synchronization through unspecified mechanisms. These groupings are called "time zones". It also calls for the origination time and delivery deadline fields be updated when a packet transitions between "time zones" (which assumes that packet forwarding devices on separating two time zones be aware of the time difference between them so that it can update those fields).


I think the intention was to obey transitions between time zones as we usually think of them (Pacific, Central European, etc.). The border routers could be expected to have the timezone information configured.




Section 6 specifies that when one of these packets is encapsulated and sent through an IPv6 in IPv6 tunnel, and tunnel exit the time fields must be copied from the outer header to the inner header before the packet is forwarded on. This would be true of any form of encapsulation, in particular including IPsec tunnelling.


Would it be O.K. if we simply deleted "IPv6-in-IPv6" from that sentence?



Many time synchronization protocols - particularly those that target subsecond synchronization - assume they are running on a secure network (or that attackers would not be motivated to mess up time synchronization). If the time synchronization between the packet forwarding devices were to be broken such that there was substantial drift between the devices, that could be used as a denial of service attack if that could be used to cause most or all data packets to be discarded as expired.


I think that a lot of things go wrong if the synchronization between the networks is broken. As mentioned in the document draft-ietf-ntp-packet-timestamps, we need to consider whether or not to include a new subsection about "Synchronization Aspects".




... I eventually concluded that only the DT field was intended to be used for this purpose and the OT field was intended to be used to track delivery performance and is not used in the calculation of packet lifetime. Assuming I have that right, it would be good if it were more explicit in the document.


Thanks for this feedback; we will find a way to make the distinction more explicit.



The bit bummer in me was offended by the fact that the TU and EXP fields had two different ways of representing 1 second time granularity (TU=00/EXP=110 and TU=01/EXP=000). Given that time granularity greater than 10 seconds is never likely to be needed, the need for the TU=01 code point is questionable, but at the least perhaps the spec should say which is the preferred encoding.


We are going to rework the time representation to be in accordance with the abovementioned document draft-ietf-ntp-packet-timestamps. I think this will resolve the concern you have raised.



I also could not tell whether the encoding was expected to be constant within a Time Zone (in which case the fields would not be necessary in every packet) or whether packet relay nodes were expected to canonicalize the time representation whenever it parses a packet. But this is only a matter of taste.


I have always thought that the encoding would be constant from end to end. We should have also made that explicit. Do you think there is a good reason to allow the encoding to be chosen on a hop-by-hop basis?


Thanks again!


Regards,
Charlie P.

--------------1B31471C5593DF9BA0EA6D53-- From nobody Sun Feb 10 13:38:54 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BA06129524; Sun, 10 Feb 2019 13:38:38 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Joseph Salowey To: Cc: rmcat@ietf.org, iesg@ietf.org, draft-ietf-rmcat-eval-test.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.91.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154983471836.14687.15606048759231374187@ietfa.amsl.com> Date: Sun, 10 Feb 2019 13:38:38 -0800 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-rmcat-eval-test-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Feb 2019 21:38:39 -0000 Reviewer: Joseph Salowey Review result: Has Issues I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The summary of the review is Document has issues. I would like to see Stewart Bryant's Genart comments about emphasizing that tests should be conducted in a controlled environment and not the open Internet. From nobody Mon Feb 11 00:47:04 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58825130E11; Mon, 11 Feb 2019 00:46:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=1.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=smyslov.net 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 h2G2lWVViJZo; Mon, 11 Feb 2019 00:46:48 -0800 (PST) Received: from direct.host-care.com (direct.host-care.com [198.136.54.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92F69128AFB; Mon, 11 Feb 2019 00:46:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=smyslov.net ; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID :Date:Subject:Cc:To:From:Sender:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=JtwQQzqP5qicuBL6htnBwqRcA2AMT/F/sK75hS1mdqc=; b=RikmaSCuN0ngLr82dV6wR8UWDP +d5g76DFNfK20/Whd7BQ3Yx7QdpLNQSIGCcH/3WXuZCrjHXkBxC9KTGUwKSAErsAoskEHbwanG/ff 0ra49aXq8G8DFSmYV/hJWa28yX1PeE43ECpBfMTJLrT4uNecoN6MXKJCwE0TFIfB4PS+ycaSQtu1W Z5KkglBJBEXHsoGHJbvrrt3uLtZXYsSwu6SNjGsnGG07lq46Ouu2op+10nBUI4VdVEA8alMrn6IkB xETpr7pmFNCu1RelcciyXnnOpeWQikqUtOxYVs7jAfqpgtWzY+wW2e1852ptzltGTuCqiMrPWUqaJ J0kJNp7A==; Received: from [82.138.51.4] (port=62884 helo=buildpc) by direct.host-care.com with esmtpsa (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.91) (envelope-from ) id 1gt7Ek-0006KR-25; Mon, 11 Feb 2019 03:46:46 -0500 From: "Valery Smyslov" To: Cc: , , Date: Mon, 11 Feb 2019 11:46:43 +0300 Message-ID: <01b601d4c1e6$525c3340$f71499c0$@smyslov.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdTBKMjRCa04fHCsTzSnxP+tbMt+Jg== Content-Language: ru X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - direct.host-care.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - smyslov.net X-Get-Message-Sender-Via: direct.host-care.com: authenticated_id: valery@smyslov.net X-Authenticated-Sender: direct.host-care.com: valery@smyslov.net X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-cellar-ebml-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2019 08:46:50 -0000 Reviewer: Valery Smyslov Review result: Ready I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The draft describes an Extensible Binary Meta Language (EBML) format as a generalized file format for any type of data. As such the EBML itself doesn't include any mechanisms providing security services, besides marginal integrity check via crc32, that is optional and limited in use. The EBML relies on external mechanisms that would provide security services. The Security Considerations section describes various issues related to security that the EBML implementations should consider even in the presence of external cryptographic protection. The list of issues seems to be quite exhaustive for the EBML. Comment not related to security: Section 2: BCP14 and RFC2119 are essentially the same document, I see no reason why they are referenced as different entities in a single sentence. From nobody Mon Feb 11 08:45:39 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CB471131090; Mon, 11 Feb 2019 08:26:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1549902408; bh=WLYszrPd7oqbppTXMhRwJm/V+7/8OzVBXpacLyZYjYg=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:Cc; b=ZxD+yuSYD8gtg8lD8W/YrSQvcwWHaQYq8Hyu/OSmz/aNhPKHVIewwXCyR5PUy7dGq Lspk18Os7fGtEwadBYd5FZZjneMCU5htgbk0WcVqZznTicJ+UlfeiWZYpVhm3Jdmls YyMBdBVDsfA88sF4NZl+Do8K6gD/i1tBD/jQpuaI= X-Mailbox-Line: From new-work-bounces@ietf.org Mon Feb 11 08:26:47 2019 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CC489131074; Mon, 11 Feb 2019 08:26:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1549902407; bh=f6CtRH4vbyOJSJe0sAcHErefYb4mF2T/sWsDttsSK0Q=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:Cc; b=lingZxt5oiNlDYpwWYqiUGqcfs8IsTTVS0U1Q0/2EXvs0pf9niPT6FmYGtf8Tmn7n OYoWVvvuRK7tB0jHjXszHJb1Tdx6lrT8ibcfbx0mNDcZyWLUtqPGZ8Gir9NQuD4f+8 J5g9rECe0pjrS7Dn1rQKA7o5fhBgRKCXeywsvfjc= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15DEF13104A for ; Mon, 11 Feb 2019 08:26:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 GwZbryJmHVlz for ; Mon, 11 Feb 2019 08:26:43 -0800 (PST) Received: from mail-qk1-x731.google.com (mail-qk1-x731.google.com [IPv6:2607:f8b0:4864:20::731]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5961E13107F for ; Mon, 11 Feb 2019 08:26:43 -0800 (PST) Received: by mail-qk1-x731.google.com with SMTP id a15so6806097qkc.1 for ; Mon, 11 Feb 2019 08:26:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:mime-version:thread-index :content-language; bh=MFwie81gCpKf83AmCLkyGZEpUYhoZtB3hte1/Le+obo=; b=b6sQZW1JX+40ZJ8JWnoWQyQNabLmVPBiBvQDPQsl+60HKtqpdcf3mKHfi7Efk8+xtB 2akSDgMxEP9OkfGUAdzfRwwC/uBz5CAMUMlQ84XAzzXG1i9p0m+viv/RpXho0ifjLFxz 1LEes/dANXv4ussdYupWqlQFYPs/uCxNPe4zwz9AKZ3/f6yjh+u7QHpEw16VZxx/Xv5f /XKU8Ic5boVn03inwVomP7yLEh0jRGfp3suI8HnMVp5kGPObGsNCYT48t5B1nM5q5pjJ ROBeDfm5EEdrErXTMm5YT17I/ffHHp/OFYBEK2duOjHYePbNv3ShejL3FeVrSOIWUhN4 NxmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :thread-index:content-language; bh=MFwie81gCpKf83AmCLkyGZEpUYhoZtB3hte1/Le+obo=; b=M/Bp1ZraUHwmT4cFEl5j8KgTZ3psYRodzK2WDYCPndFfbyp8/E2Xpry/dGKjunSWDi LBcx8UjvYwIvwiLiT+yhRRmxwDP/j9gmIl1jC4MZs3TVoo/rtunpGAGChpyMoXjYvc5X Cg3CUW8v5OKDEx0aQNJRYdEb3sH37g5oNh9HZ7vw9W2GScZWdFa1w1UmKVqC7RBUjWOy tF2s3PTUZzb2ld7LKu52E6P6Cnu0OHFsIhzCAN4ph9a7uJanr2+pgGFuWsLA9Kng8248 eXe1cYoJh2TL0m1KHFAAJr0BS1PxOQRFHbJVtuxrQr0GTkLmLOJuXSfhpMcTRruVAzFr f1pw== X-Gm-Message-State: AHQUAuaoaTS9EJ+E7UxZ4sESIa4jg+ZrxHN11EmKCv5rXpyZTANTh+kN +5Oem3C7mCxw4DmL5QWA/H0= X-Google-Smtp-Source: AHgI3IatPUKSLUPco4qWaFG935jdrE6Y6oYFqC8CT5WkiY930HL0HX0RxzXkqsB33MxkTTN3t85DGA== X-Received: by 2002:a37:884:: with SMTP id 126mr26927018qki.56.1549902402454; Mon, 11 Feb 2019 08:26:42 -0800 (PST) Received: from DESKTOPGUNUVB7 ([152.208.106.92]) by smtp.gmail.com with ESMTPSA id l24sm6395859qtf.27.2019.02.11.08.26.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 11 Feb 2019 08:26:41 -0800 (PST) From: "John DAmbrosia" To: Date: Mon, 11 Feb 2019 11:26:37 -0500 Message-ID: <008001d4c226$9204f050$b60ed0f0$@gmail.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdTCJil5SmQFaICwRriJOh0o6by+IQ== Content-Language: en-us Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.29 Precedence: list Cc: "'Stanley, Dorothy'" , p.nikolich@ieee.org Content-Type: multipart/mixed; boundary="===============0087747156566089532==" Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Mon, 11 Feb 2019 08:45:37 -0800 Subject: [secdir] [new-work] Update - IEEE 802 Mar 2019 PAR / ICAID Under Consideration X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2019 16:26:53 -0000 This is a multipart message in MIME format. --===============0087747156566089532== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0081_01D4C1FC.A92F8490" Content-Language: en-us This is a multipart message in MIME format. ------=_NextPart_000_0081_01D4C1FC.A92F8490 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit All, This is an update to my prior email - The following Project Authorization Request (PAR) and Industry Connections Activity Initiation Document (ICAID) will be considered at the Mar 2019 IEEE 802 Plenary: * 802.1 Industry Connections: Network Enhancements for the Next Decade Industry Connections Activity (Nendica) ICAID Extension and background * 802.3cu - Amendment, 100 Gb/s and 400 Gb/s Operation over Single-Mode Fiber, PAR and CSD * 802.11be- Amendment, Enhancements for Extremely High Throughput (EHT), PAR and CSD The PARs and ICAID can be found at http://www.ieee802.org/PARs.shtml along with the supporting IEEE 802 Criteria for Standards Development, or CSD, (which includes the 5 criteria, i.e. the explanations of how they fit the IEEE 802 criteria for initiating new work). Any comments on a proposed PAR / ICAID should be sent to the Working Group chair identified on the respective document to be received by 6:30 PM PDT, Tuesday, Mar 12 (2:30 am UTC, Mar 13, 2019) Regards, John D'Ambrosia Recording Secretary, IEEE 802 LMSC ------=_NextPart_000_0081_01D4C1FC.A92F8490 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable IEEE 802 Mar 2019 PAR / ICAID Under = Consideration

All,

This = is an update to my prior email -

The = following Project Authorization Request (PAR) and Industry Connections = Activity Initiation Document (ICAID) will be considered at the Mar 2019 = IEEE 802 Plenary:

  • 802.1 = Industry Connections: Network Enhancements for the Next Decade = Industry Connections Activity = (Nendica) ICAID Extension and background
  • 802.3cu - = Amendment, 100 Gb/s and 400 Gb/s Operation over Single-Mode = Fiber, PAR and CSD
  • 802.11be- Amendment, = Enhancements for = Extremely High Throughput (EHT), PAR and CSD

The = PARs and ICAID can be found at http://www.ieee802.org/PARs.shtml = along with the supporting IEEE 802 Criteria for Standards Development, = or CSD, (which includes the 5 criteria, i.e. the explanations of how = they fit the IEEE 802 criteria for initiating new = work).

Any = comments on a proposed PAR / ICAID should be sent to the Working Group = chair identified on the respective document to be received by 6:30 PM = PDT, Tuesday, Mar 12 (2:30 am UTC, Mar 13, 2019)

Regards,

John = D’Ambrosia

Recording Secretary, IEEE 802 LMSC =

------=_NextPart_000_0081_01D4C1FC.A92F8490-- --===============0087747156566089532== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work --===============0087747156566089532==-- From nobody Mon Feb 11 14:34:31 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B42E51228B7; Mon, 11 Feb 2019 14:33:57 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Kyle Rose To: Cc: ietf@ietf.org, draft-ietf-tsvwg-le-phb.all@ietf.org, tsvwg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.91.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154992443765.29641.355119587706336977@ietfa.amsl.com> Date: Mon, 11 Feb 2019 14:33:57 -0800 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-tsvwg-le-phb-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2019 22:33:58 -0000 Reviewer: Kyle Rose Review result: Has Nits I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. I agree that there are no remarkable security or privacy considerations for this draft, but I would wordsmith the privacy paragraph slightly. It says: q( However, this disclosed information is only useful if some form of identification happened at the same time ) glossing over the fact that identification is typically present in every packet: the IP address of the user. It provides at least one bit of information about what the user is doing, which, in conjunction with metadata from other flows to/from that address, can potentially reveal more about user identity and/or behavior. The reason the privacy impact is unremarkable is that it is highly likely the case that such traffic is already classifiable as unimportant via the sort of traffic analysis that troubles privacy advocates, when considering the endpoint, payload length, pacing, etc. Unrelated to secdir, I am also vaguely concerned about the impact on path elements that pass along the LE PHB but treat the traffic as BE: especially for traffic lacking congestion control (e.g., unicast hops for multicast traffic), can they be put in the position of forwarding large volumes of traffic in vain, i.e., traffic that will be dropped later? For CC-managed unicast traffic, it seems that the sender will back off sufficiently following congestion-induced loss to make this no worse than a highly-lossy destination at BE. It might also be the case that multicast congestion-induced loss in LE is no worse than congestion problems with multicast in general, but I'd like to understand this a bit better. From nobody Tue Feb 12 04:54:03 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 600D6130E74; Tue, 12 Feb 2019 04:53:38 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Tero Kivinen To: Cc: jmap@ietf.org, draft-ietf-jmap-core.all@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.91.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154997601829.8330.1953392138178618640@ietfa.amsl.com> Date: Tue, 12 Feb 2019 04:53:38 -0800 Archived-At: Subject: [secdir] Secdir telechat review of draft-ietf-jmap-core-14 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2019 12:53:47 -0000 Reviewer: Tero Kivinen Review result: Ready I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This is rereview of this document, and all my previous issues have been solved, so I think this document is ready. From nobody Tue Feb 12 09:06:59 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD4431292F1; Tue, 12 Feb 2019 09:06:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 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_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=qti.qualcomm.com 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 2hfHVo7TP71o; Tue, 12 Feb 2019 09:06:48 -0800 (PST) Received: from alexa-out-sd-01.qualcomm.com (alexa-out-sd-01.qualcomm.com [199.106.114.38]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AB23128B33; Tue, 12 Feb 2019 09:06:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1549991208; x=1581527208; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=7fmMqPFEb6jLyjKktFs2jI8eeWmCNZVvCpwdrceMRWQ=; b=HIalgYSI4l2tHZOLUhZKGgWam3zscdSrZXQIkM9LTIGJGeCdt3liU3DH z+G5ZfK012VX/qr69xUpsHKMZf92ssCkCt/J9QAfy5IwEqYBvFdrAwdtm NDePysJ2ySxgoobLLQp17ngJaZWY68eAMV2K4Lc/HWU40XK2hNHRk3kKJ c=; X-IronPort-AV: E=Sophos; i="5.58,362,1544515200"; d="scan'208,217"; a="27559373" Received: from unknown (HELO ironmsg01-sd.qualcomm.com) ([10.53.140.141]) by alexa-out-sd-01.qualcomm.com with ESMTP; 12 Feb 2019 09:06:47 -0800 Received: from nasanexm01e.na.qualcomm.com ([10.85.0.31]) by ironmsg01-sd.qualcomm.com with ESMTP/TLS/AES256-SHA; 12 Feb 2019 09:06:47 -0800 Received: from NASANEXM01C.na.qualcomm.com (10.85.0.83) by NASANEXM01E.na.qualcomm.com (10.85.0.31) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 12 Feb 2019 09:06:46 -0800 Received: from NASANEXM01C.na.qualcomm.com ([10.85.0.83]) by NASANEXM01C.na.qualcomm.com ([10.85.0.83]) with mapi id 15.00.1395.000; Tue, 12 Feb 2019 09:06:46 -0800 From: Giridhar Mandyam To: Radia Perlman , The IESG , "secdir@ietf.org" , "draft-ietf-payload-flexible-fec-scheme.all@ietf.org" Thread-Topic: Secdir review of draft-ietf-payload-flexible-fec-scheme-16 Thread-Index: AQHUwQkmOu8lZlcwNEKJvb4cVwdepqXcZhbQ Date: Tue, 12 Feb 2019 17:06:45 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.80.80.8] Content-Type: multipart/alternative; boundary="_000_b34cee8a727a4e249767bfe27ed3b9f6NASANEXM01Cnaqualcommco_" MIME-Version: 1.0 Archived-At: Subject: Re: [secdir] Secdir review of draft-ietf-payload-flexible-fec-scheme-16 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2019 17:06:51 -0000 --_000_b34cee8a727a4e249767bfe27ed3b9f6NASANEXM01Cnaqualcommco_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmsgeW91IGZvciB0aGUgcmV2aWV3Lg0KDQo+IFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIG1l bnRpb25zIG11bHRpcGxlIHdheXMgdGhhdCBhbiBSVFAgc3RyZWFtIGNhbiBiZSBwcm90ZWN0ZWQu IEkgd291bGQgcXVpYmJsZSB0aGF0IHRoZSBsaXN0IGluY2x1ZGVzIFRMUywgd2hpY2ggaXMgcHJv YmFibHkgbm90IGFwcHJvcHJpYXRlLiBUTFMgcmVxdWlyZXMgdGhhdCBhbGwgZGF0YSBwYWNrZXRz IGJlIHJlY2VpdmVkIGFuZCByZXF1ZXN0cyByZXRyYW5zbWlzc2lvbiBzaG91bGQgcGFja2V0cyBi ZSBsb3N0LiBUaGF0IHdvdWxkIHJlbW92ZSBhbnkgYmVuZWZpdCBmcm9tIGhhdmluZyBGRUMgcGFj a2V0cy4gVXNlIG9mIERUTFMgd291bGQgYmUgYW4gYXBwcm9wcmlhdGUgcHJvdG9jb2wgdG8gdXNl LCBob3dldmVyLg0KDQpUaGUgZWRpdG9ycyBhZ3JlZSBhbmQgd2lsbCB1cGRhdGUgdGhlIHRleHQg YWNjb3JkaW5nbHkuDQoNCj4gSXQgd291bGQgYmUgdXNlZnVsIHRvIHB1Ymxpc2ggaW5mb3JtYXRp b24gb24gbG9zc2VzIGV4cGVyaWVuY2VkIGluIGFjdHVhbCB1c2UgaW4gb3JkZXIgdG8gaGVscCBk ZXNpZ25lcnMgdHVuZSB0aGVpciBwYXJhbWV0ZXJzLg0KDQpBcyBleGFtcGxlcyBvZiBzdWNoIHdv cmssIHBsZWFzZSBzZWUgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNpbmdoLXJt Y2F0LWFkYXB0aXZlLWZlYy0wMyBvciBodHRwczovL2llZWV4cGxvcmUuaWVlZS5vcmcvZG9jdW1l bnQvNzg3MDc1Ny4NCg0KLUdpcmkgTWFuZHlhbQ0KDQpGcm9tOiBSYWRpYSBQZXJsbWFuIDxyYWRp YXBlcmxtYW5AZ21haWwuY29tPg0KU2VudDogU2F0dXJkYXksIEZlYnJ1YXJ5IDksIDIwMTkgMTA6 MjMgUE0NClRvOiBUaGUgSUVTRyA8aWVzZ0BpZXRmLm9yZz47IHNlY2RpckBpZXRmLm9yZzsgZHJh ZnQtaWV0Zi1wYXlsb2FkLWZsZXhpYmxlLWZlYy1zY2hlbWUuYWxsQGlldGYub3JnDQpTdWJqZWN0 OiBTZWNkaXIgcmV2aWV3IG9mIGRyYWZ0LWlldGYtcGF5bG9hZC1mbGV4aWJsZS1mZWMtc2NoZW1l LTE2DQoNCg0KQ0FVVElPTjogVGhpcyBlbWFpbCBvcmlnaW5hdGVkIGZyb20gb3V0c2lkZSBvZiB0 aGUgb3JnYW5pemF0aW9uLg0KSSBoYXZlIHJldmlld2VkIHRoaXMgZG9jdW1lbnQgYXMgcGFydCBv ZiB0aGUgc2VjdXJpdHkgZGlyZWN0b3JhdGUncyBvbmdvaW5nIGVmZm9ydCB0byByZXZpZXcgYWxs IElFVEYgZG9jdW1lbnRzIGJlaW5nIHByb2Nlc3NlZCBieSB0aGUgSUVTRy4gIFRoZXNlIGNvbW1l bnRzIHdlcmUgd3JpdHRlbiBwcmltYXJpbHkgZm9yIHRoZSBiZW5lZml0IG9mIHRoZSBzZWN1cml0 eSBhcmVhIGRpcmVjdG9ycy4gIERvY3VtZW50IGVkaXRvcnMgYW5kIFdHIGNoYWlycyBzaG91bGQg dHJlYXQgdGhlc2UgY29tbWVudHMganVzdCBsaWtlIGFueSBvdGhlciBsYXN0IGNhbGwgY29tbWVu dHMuDQoNClRoaXMgc3BlY2lmaWNhdGlvbiBkZWZpbmVzIGEgZm9ybWF0IGZvciBzZW5kaW5nIEZv cndhcmQgRXJyb3IgQ29ycmVjdGlvbiBwYWNrZXRzIHRvIGFsbG93IG9jY2FzaW9uYWwgbG9zdCBw YWNrZXRzIGluIGEgUmVhbCBUaW1lIFByb3RvY29sIChSVFApIHN0cmVhbSB0byBiZSByZWNvdmVy ZWQgd2l0aG91dCByZXRyYW5zbWlzc2lvbi4gVGhlIGZvcm1hdCBmb3IgdGhlc2UgcGFja2V0cyBp bmNsdWRlcyBYT1JzIG9mIGEgc2VyaWVzIG9mIHBhY2tldHMgd2hpY2ggYWxsb3dzIGFueSBvbmUg b2YgdGhlIHNlcmllcyB0byBiZSByZWNvdmVyZWQgaWYgdGhlIHJlcGFpciBwYWNrZXQgaXMgcmVj ZWl2ZWQuIFRvIHN1cHBvcnQgdGhlIGNhc2Ugb2YgbW9yZSB0aGFuIGEgc2luZ2xlIGRhdGEgcGFj a2V0IGJlaW5nIGxvc3QsIGl0IGFsbG93cyBib3RoIGhvcml6b250YWwgYW5kIHZlcnRpY2FsIHBh cml0eSB0byBiZSBjb21wdXRlZCBvdmVyIGFuIG4qbSBhcnJheSBvZiBwYWNrZXRzLiBUaGlzIGlz IGltcG9ydGFudCBiZWNhdXNlIHRoZSBtb3N0IGZyZXF1ZW50IGNhdXNlIG9mIHBhY2tldCBsb3Nz IGlzIGNvbmdlc3Rpb24sIGFuZCBjb25nZXN0aW9uIGZyZXF1ZW50bHkgbG9zZXMgbXVsdGlwbGUg cGFja2V0cyBpbiBzdWNjZXNzaW9uLg0KDQpUaGVyZSBhcmUgbW9yZSBtYXRoZW1hdGljYWxseSBz b3BoaXN0aWNhdGVkIGFsZ29yaXRobXMgdGhhdCB3b3VsZCBwZXJtaXQgcmVjb3Zlcnkgb2YgbW9y ZSBnZW5lcmFsIHNldHMgb2YgbG9zdCBwYWNrZXRzLCBidXQgdGhleSB3b3VsZCByZXF1aXJlIG1v cmUgY29tcHV0YXRpb24gdG8gcmVjb3ZlciBhbmQgbW9yZSBkZWJhdGUgdG8gc3BlY2lmeS4gTW9z dCBzdGFuZGFyZCBGRUMgYWxnb3JpdGhtcyBhc3N1bWUgdGhhdCBhIGNlcnRhaW4gbnVtYmVyIG9m IGJpdHMgcmVjZWl2ZWQgYXJlIGluY29ycmVjdCwgd2hlcmUgdGhpcyBhbGdvcml0aG0gYXNzdW1l cyB0aGF0IHBhY2tldHMgYXJlIG5ldmVyIHJlY2VpdmVkIGluY29ycmVjdGx5IGJ1dCBhcmUgc29t ZXRpbWVzIG5vdCByZWNlaXZlZCBhdCBhbGwuIFRoaXMgYWxnb3JpdGhtIGlzIG5vdCBkZXNpZ25l ZCB0byByZWNvdmVyIGZyb20gc2VjdXJpdHkgYXR0YWNrcyBvciBtb3JlIGNvbXBsZXggZmFpbHVy ZXMuDQoNClNlY3VyaXR5IENvbnNpZGVyYXRpb25zIG1lbnRpb25zIG11bHRpcGxlIHdheXMgdGhh dCBhbiBSVFAgc3RyZWFtIGNhbiBiZSBwcm90ZWN0ZWQuIEkgd291bGQgcXVpYmJsZSB0aGF0IHRo ZSBsaXN0IGluY2x1ZGVzIFRMUywgd2hpY2ggaXMgcHJvYmFibHkgbm90IGFwcHJvcHJpYXRlLiBU TFMgcmVxdWlyZXMgdGhhdCBhbGwgZGF0YSBwYWNrZXRzIGJlIHJlY2VpdmVkIGFuZCByZXF1ZXN0 cyByZXRyYW5zbWlzc2lvbiBzaG91bGQgcGFja2V0cyBiZSBsb3N0LiBUaGF0IHdvdWxkIHJlbW92 ZSBhbnkgYmVuZWZpdCBmcm9tIGhhdmluZyBGRUMgcGFja2V0cy4gVXNlIG9mIERUTFMgd291bGQg YmUgYW4gYXBwcm9wcmlhdGUgcHJvdG9jb2wgdG8gdXNlLCBob3dldmVyLg0KDQpPdGhlciB0aG91 Z2h0czoNCg0KR2l2ZW4gdGhhdCBtb3N0IHBhY2tldCBsb3NzIGlzIGNhdXNlZCBieSBjb25nZXN0 aW9uLCBhbmQgdmVyeSBmcmVxdWVudGx5IGNvbmdlc3Rpb24gbG9zZXMgbXVsdGlwbGUgcGFja2V0 cyBmcm9tIGEgc3RyZWFtLCBJJ20gc3VycHJpc2VkIHRoYXQgc2VuZGluZyByZXBhaXIgcGFja2V0 cyBiYXNlZCBvbiBhbiBhZGphY2VudCBzZXF1ZW5jZSBvZiBwYWNrZXRzIGlzIGVmZmVjdGl2ZSAo ZXNwZWNpYWxseSBzaW5jZSBzZW5kaW5nIHRob3NlIHBhY2tldHMgd2lsbCBpbmNyZWFzZSBjb25n ZXN0aW9uIGxvc3NlcykuIENvbHVtbiBiYXNlZCBwcm90ZWN0aW9uIGlzIG1vcmUgbGlrZWx5IHRv IGJlIGVmZmVjdGl2ZSwgYnV0IG9ubHkgaWYgdGhlIHJvd3MgYXJlIGxvbmcgZW5vdWdoIHRoYXQg YSBzZXF1ZW5jZSBvZiBwYWNrZXRzIGxvc3QgZHVlIHRvIGNvbmdlc3Rpb24gd291bGQgYWxsIGZp dCBpbiBhIHNpbmdsZSByb3cuIE9uIHRoZSBvdGhlciBoYW5kLCBsb3N0IHBhY2tldCByZWNvdmVy eSBjYW4gdGFrZSB1cCB0byB0aGUgYW1vdW50IG9mIHRpbWUgdG8gcmVjZWl2ZSBuKm0gcGFja2V0 cywgc28gdGhhdCB2YWx1ZSBtdXN0IGJlIHNtYWxsIGVub3VnaCB0aGF0IHRoZSByZWNvdmVyZWQg cGFja2V0cyBhcmUgc3RpbGwgdXNlZnVsIGdpdmVuIHRoYXQgdGhpcyBpcyBhIHJlYWwgdGltZSBw cm90b2NvbC4gSXQgd291bGQgYmUgdXNlZnVsIHRvIHB1Ymxpc2ggaW5mb3JtYXRpb24gb24gbG9z c2VzIGV4cGVyaWVuY2VkIGluIGFjdHVhbCB1c2UgaW4gb3JkZXIgdG8gaGVscCBkZXNpZ25lcnMg dHVuZSB0aGVpciBwYXJhbWV0ZXJzLg0KDQpSYWRpYQ0K --_000_b34cee8a727a4e249767bfe27ed3b9f6NASANEXM01Cnaqualcommco_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjoj OTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5t c29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJ bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUyMA0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1z dHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4w aW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0 aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZh dWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86 aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFb ZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxp bms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlRoYW5rIHlvdSBmb3IgdGhlIHJldmlldy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jmd0OyBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyBtZW50aW9ucyBtdWx0aXBsZSB3YXlzIHRoYXQg YW4gUlRQIHN0cmVhbSBjYW4gYmUgcHJvdGVjdGVkLiBJIHdvdWxkIHF1aWJibGUgdGhhdCB0aGUg bGlzdCBpbmNsdWRlcyBUTFMsIHdoaWNoIGlzIHByb2JhYmx5IG5vdCBhcHByb3ByaWF0ZS4gVExT IHJlcXVpcmVzIHRoYXQgYWxsIGRhdGEgcGFja2V0cyBiZSByZWNlaXZlZCBhbmQgcmVxdWVzdHMg cmV0cmFuc21pc3Npb24NCiBzaG91bGQgcGFja2V0cyBiZSBsb3N0LiBUaGF0IHdvdWxkIHJlbW92 ZSBhbnkgYmVuZWZpdCBmcm9tIGhhdmluZyBGRUMgcGFja2V0cy4gVXNlIG9mIERUTFMgd291bGQg YmUgYW4gYXBwcm9wcmlhdGUgcHJvdG9jb2wgdG8gdXNlLCBob3dldmVyLjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5UaGUgZWRpdG9ycyBhZ3JlZSBhbmQgd2lsbCB1cGRhdGUgdGhlIHRleHQgYWNj b3JkaW5nbHkuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsgSXQgd291bGQgYmUgdXNlZnVs IHRvIHB1Ymxpc2ggaW5mb3JtYXRpb24gb24gbG9zc2VzIGV4cGVyaWVuY2VkIGluIGFjdHVhbCB1 c2UgaW4gb3JkZXIgdG8gaGVscCBkZXNpZ25lcnMgdHVuZSB0aGVpciBwYXJhbWV0ZXJzLjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5BcyBleGFtcGxlcyBvZiBzdWNoIHdvcmssIHBsZWFzZSBzZWUg PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNpbmdoLXJtY2F0LWFk YXB0aXZlLWZlYy0wMyI+DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtc2luZ2gt cm1jYXQtYWRhcHRpdmUtZmVjLTAzPC9hPiBvciA8YSBocmVmPSJodHRwczovL2llZWV4cGxvcmUu aWVlZS5vcmcvZG9jdW1lbnQvNzg3MDc1NyI+DQpodHRwczovL2llZWV4cGxvcmUuaWVlZS5vcmcv ZG9jdW1lbnQvNzg3MDc1NzwvYT4uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi1HaXJpIE1hbmR5 YW08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IFJhZGlhIFBlcmxtYW4gJmx0 O3JhZGlhcGVybG1hbkBnbWFpbC5jb20mZ3Q7IDxicj4NCjxiPlNlbnQ6PC9iPiBTYXR1cmRheSwg RmVicnVhcnkgOSwgMjAxOSAxMDoyMyBQTTxicj4NCjxiPlRvOjwvYj4gVGhlIElFU0cgJmx0O2ll c2dAaWV0Zi5vcmcmZ3Q7OyBzZWNkaXJAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtcGF5bG9hZC1mbGV4 aWJsZS1mZWMtc2NoZW1lLmFsbEBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBTZWNkaXIg cmV2aWV3IG9mIGRyYWZ0LWlldGYtcGF5bG9hZC1mbGV4aWJsZS1mZWMtc2NoZW1lLTE2PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw PjxzdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjVwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OyxzYW5zLXNlcmlmO2JhY2tncm91bmQ6I0ZGRUI5QyI+Q0FVVElPTjwvc3Bhbj48 L3N0cm9uZz48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LHNhbnMtc2VyaWY7YmFja2dyb3VuZDojRkZFQjlDIj46IFRoaXMgZW1haWwgb3Jp Z2luYXRlZCBmcm9tIG91dHNpZGUgb2YgdGhlIG9yZ2FuaXphdGlvbi48L3NwYW4+PG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGhhdmUg cmV2aWV3ZWQgdGhpcyBkb2N1bWVudCBhcyBwYXJ0IG9mIHRoZSBzZWN1cml0eSBkaXJlY3RvcmF0 ZSdzIG9uZ29pbmcgZWZmb3J0IHRvIHJldmlldyBhbGwgSUVURiBkb2N1bWVudHMgYmVpbmcgcHJv Y2Vzc2VkIGJ5IHRoZSBJRVNHLiZuYnNwOyBUaGVzZSBjb21tZW50cyB3ZXJlIHdyaXR0ZW4gcHJp bWFyaWx5IGZvciB0aGUgYmVuZWZpdCBvZiB0aGUgc2VjdXJpdHkgYXJlYSBkaXJlY3RvcnMuJm5i c3A7IERvY3VtZW50DQogZWRpdG9ycyBhbmQgV0cgY2hhaXJzIHNob3VsZCB0cmVhdCB0aGVzZSBj b21tZW50cyBqdXN0IGxpa2UgYW55IG90aGVyIGxhc3QgY2FsbCBjb21tZW50cy48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBzcGVjaWZp Y2F0aW9uIGRlZmluZXMgYSBmb3JtYXQgZm9yIHNlbmRpbmcgRm9yd2FyZCBFcnJvciBDb3JyZWN0 aW9uIHBhY2tldHMgdG8gYWxsb3cgb2NjYXNpb25hbCBsb3N0IHBhY2tldHMgaW4gYSBSZWFsIFRp bWUgUHJvdG9jb2wgKFJUUCkgc3RyZWFtIHRvIGJlIHJlY292ZXJlZCB3aXRob3V0IHJldHJhbnNt aXNzaW9uLiBUaGUgZm9ybWF0IGZvciB0aGVzZSBwYWNrZXRzIGluY2x1ZGVzIFhPUnMgb2YNCiBh IHNlcmllcyBvZiBwYWNrZXRzIHdoaWNoIGFsbG93cyBhbnkgb25lIG9mIHRoZSBzZXJpZXMgdG8g YmUgcmVjb3ZlcmVkIGlmIHRoZSByZXBhaXIgcGFja2V0IGlzIHJlY2VpdmVkLiBUbyBzdXBwb3J0 IHRoZSBjYXNlIG9mIG1vcmUgdGhhbiBhIHNpbmdsZSBkYXRhIHBhY2tldCBiZWluZyBsb3N0LCBp dCBhbGxvd3MgYm90aCBob3Jpem9udGFsIGFuZCB2ZXJ0aWNhbCBwYXJpdHkgdG8gYmUgY29tcHV0 ZWQgb3ZlciBhbiBuKm0gYXJyYXkgb2YgcGFja2V0cy4NCiBUaGlzIGlzIGltcG9ydGFudCBiZWNh dXNlIHRoZSBtb3N0IGZyZXF1ZW50IGNhdXNlIG9mIHBhY2tldCBsb3NzIGlzIGNvbmdlc3Rpb24s IGFuZCBjb25nZXN0aW9uIGZyZXF1ZW50bHkgbG9zZXMgbXVsdGlwbGUgcGFja2V0cyBpbiBzdWNj ZXNzaW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5UaGVyZSBhcmUgbW9yZSBtYXRoZW1hdGljYWxseSBzb3BoaXN0aWNhdGVkIGFsZ29yaXRo bXMgdGhhdCB3b3VsZCBwZXJtaXQgcmVjb3Zlcnkgb2YgbW9yZSBnZW5lcmFsIHNldHMgb2YgbG9z dCBwYWNrZXRzLCBidXQgdGhleSB3b3VsZCByZXF1aXJlIG1vcmUgY29tcHV0YXRpb24gdG8gcmVj b3ZlciBhbmQgbW9yZSBkZWJhdGUgdG8gc3BlY2lmeS4gTW9zdCBzdGFuZGFyZCBGRUMgYWxnb3Jp dGhtcyBhc3N1bWUgdGhhdA0KIGEgY2VydGFpbiBudW1iZXIgb2YgYml0cyByZWNlaXZlZCBhcmUg aW5jb3JyZWN0LCB3aGVyZSB0aGlzIGFsZ29yaXRobSBhc3N1bWVzIHRoYXQgcGFja2V0cyBhcmUg bmV2ZXIgcmVjZWl2ZWQgaW5jb3JyZWN0bHkgYnV0IGFyZSBzb21ldGltZXMgbm90IHJlY2VpdmVk IGF0IGFsbC4gVGhpcyBhbGdvcml0aG0gaXMgbm90IGRlc2lnbmVkIHRvIHJlY292ZXIgZnJvbSBz ZWN1cml0eSBhdHRhY2tzIG9yIG1vcmUgY29tcGxleCBmYWlsdXJlcy48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U2VjdXJpdHkgQ29uc2lkZXJh dGlvbnMgbWVudGlvbnMgbXVsdGlwbGUgd2F5cyB0aGF0IGFuIFJUUCBzdHJlYW0gY2FuIGJlIHBy b3RlY3RlZC4gSSB3b3VsZCBxdWliYmxlIHRoYXQgdGhlIGxpc3QgaW5jbHVkZXMgVExTLCB3aGlj aCBpcyBwcm9iYWJseSBub3QgYXBwcm9wcmlhdGUuIFRMUyByZXF1aXJlcyB0aGF0IGFsbCBkYXRh IHBhY2tldHMgYmUgcmVjZWl2ZWQgYW5kIHJlcXVlc3RzIHJldHJhbnNtaXNzaW9uDQogc2hvdWxk IHBhY2tldHMgYmUgbG9zdC4gVGhhdCB3b3VsZCByZW1vdmUgYW55IGJlbmVmaXQgZnJvbSBoYXZp bmcgRkVDIHBhY2tldHMuIFVzZSBvZiBEVExTIHdvdWxkIGJlIGFuIGFwcHJvcHJpYXRlIHByb3Rv Y29sIHRvIHVzZSwgaG93ZXZlci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+T3RoZXIgdGhvdWdodHM6PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkdpdmVuIHRoYXQgbW9zdCBwYWNrZXQgbG9z cyBpcyBjYXVzZWQgYnkgY29uZ2VzdGlvbiwgYW5kIHZlcnkgZnJlcXVlbnRseSBjb25nZXN0aW9u IGxvc2VzIG11bHRpcGxlIHBhY2tldHMgZnJvbSBhIHN0cmVhbSwgSSdtIHN1cnByaXNlZCB0aGF0 IHNlbmRpbmcgcmVwYWlyIHBhY2tldHMgYmFzZWQgb24gYW4gYWRqYWNlbnQgc2VxdWVuY2Ugb2Yg cGFja2V0cyBpcyBlZmZlY3RpdmUgKGVzcGVjaWFsbHkgc2luY2UNCiBzZW5kaW5nIHRob3NlIHBh Y2tldHMgd2lsbCBpbmNyZWFzZSBjb25nZXN0aW9uIGxvc3NlcykuIENvbHVtbiBiYXNlZCBwcm90 ZWN0aW9uIGlzIG1vcmUgbGlrZWx5IHRvIGJlIGVmZmVjdGl2ZSwgYnV0IG9ubHkgaWYgdGhlIHJv d3MgYXJlIGxvbmcgZW5vdWdoIHRoYXQgYSBzZXF1ZW5jZSBvZiBwYWNrZXRzIGxvc3QgZHVlIHRv IGNvbmdlc3Rpb24gd291bGQgYWxsIGZpdCBpbiBhIHNpbmdsZSByb3cuIE9uIHRoZSBvdGhlciBo YW5kLCBsb3N0IHBhY2tldA0KIHJlY292ZXJ5IGNhbiB0YWtlIHVwIHRvIHRoZSBhbW91bnQgb2Yg dGltZSB0byByZWNlaXZlIG4qbSBwYWNrZXRzLCBzbyB0aGF0IHZhbHVlIG11c3QgYmUgc21hbGwg ZW5vdWdoIHRoYXQgdGhlIHJlY292ZXJlZCBwYWNrZXRzIGFyZSBzdGlsbCB1c2VmdWwgZ2l2ZW4g dGhhdCB0aGlzIGlzIGEgcmVhbCB0aW1lIHByb3RvY29sLiBJdCB3b3VsZCBiZSB1c2VmdWwgdG8g cHVibGlzaCBpbmZvcm1hdGlvbiBvbiBsb3NzZXMgZXhwZXJpZW5jZWQgaW4gYWN0dWFsDQogdXNl IGluIG9yZGVyIHRvIGhlbHAgZGVzaWduZXJzIHR1bmUgdGhlaXIgcGFyYW1ldGVycy48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmFkaWE8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9o dG1sPg0K --_000_b34cee8a727a4e249767bfe27ed3b9f6NASANEXM01Cnaqualcommco_-- From nobody Tue Feb 12 10:06:14 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1156E130DBE; Tue, 12 Feb 2019 10:06:05 -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 autolearn_force=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 CJeZRkdPAjNR; Tue, 12 Feb 2019 10:06:03 -0800 (PST) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E761812F1A5; Tue, 12 Feb 2019 10:06:02 -0800 (PST) Received: from [130.209.157.52] (port=42229 helo=glaroam2-159-244.wireless.gla.ac.uk) by balrog.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1gtcRR-0006uK-3g; Tue, 12 Feb 2019 18:06:01 +0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Colin Perkins In-Reply-To: <154983471836.14687.15606048759231374187@ietfa.amsl.com> Date: Tue, 12 Feb 2019 18:05:50 +0000 Cc: secdir@ietf.org, "rmcat@ietf.org WG" , iesg@ietf.org, draft-ietf-rmcat-eval-test.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <154983471836.14687.15606048759231374187@ietfa.amsl.com> To: Joseph Salowey X-Mailer: Apple Mail (2.3273) X-BlackCat-Spam-Score: 4 Archived-At: Subject: Re: [secdir] [rmcat] Secdir last call review of draft-ietf-rmcat-eval-test-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2019 18:06:05 -0000 > On 10 Feb 2019, at 21:38, Joseph Salowey wrote: >=20 > Reviewer: Joseph Salowey > Review result: Has Issues >=20 > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. >=20 > The summary of the review is Document has issues. I would like to = see Stewart > Bryant=E2=80=99s Genart comments about emphasizing that tests should = be conducted in a controlled environment and not the open Internet. This text was strengthened somewhat in -09, in response to the GenART = review of -08. Is this enough, or are further changes needed? --=20 Colin Perkins https://csperkins.org/ From nobody Tue Feb 12 18:38:38 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D164E130F27 for ; Tue, 12 Feb 2019 18:38:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com 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 X00NHB6Rk719 for ; Tue, 12 Feb 2019 18:38:17 -0800 (PST) Received: from mail-qt1-x844.google.com (mail-qt1-x844.google.com [IPv6:2607:f8b0:4864:20::844]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87527130F21 for ; Tue, 12 Feb 2019 18:38:17 -0800 (PST) Received: by mail-qt1-x844.google.com with SMTP id j36so955467qta.7 for ; Tue, 12 Feb 2019 18:38:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=7T3XzyHoqWMoI2E8O5ZaNXjT9RRNcCsj4WltHwJQLMU=; b=LiCnE+jV9m05ZO81BOZvvuSqCM+KoBhN2rLPQO9EKjEMb67h7NDF4A0Eodotu7+Wyf IseVb5+dp6rQrxQ39kjsL+y2pFhR5pJ9bbG0s7ZstzfRmoOvBjO1vYa+lmCaEq5S4j// D1B1H6WhXe+L5Nz6NOezbGLE2nmXMqEUOsqmQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=7T3XzyHoqWMoI2E8O5ZaNXjT9RRNcCsj4WltHwJQLMU=; b=k2xJ2+EmCdBEUHlgxj7gyNDXMul4F4FpTrwlR8EU5ARe/1XaWIvu5vfEkrQ14iqDWp 5lkHvdemTPvta5FgndYFTIAp//TiIHMLJOOLHEMk+UvqGFG9C2K8gKjz2K1ht6J5gg6X O7uiljRtK127x+L7U/R6MPbiD98mYPB5PLtK4GkUghKtPV7H4PMlcOtR5qIqT63mfDQD zzIxA7HOb3XRRgOjvD93Mse3rQQ7YeMsHxSvvO+ZXdDs/j7DfvNe9zUFt7rJa6ZvXXn3 D8J7UDgwCqU4+Xlfrqe6ahS9wuhqgVhjohTlBgr+OX4MJaY222V7d7CwrYVUwXjfNY4t Zt2g== X-Gm-Message-State: AHQUAubpMVz4UahZOmoSfa9jdrT1ye3zeBy2wvtw7G2T1N7fTUrbm3X2 9VOoCoymmNabbng9a+IRmMOxQrSNuUs= X-Google-Smtp-Source: AHgI3IaN713Zv5b7uVWfwUqbev+9AVY3FnsqYuR8LT6IBYmMSDtb+F7ClkJjF5xGUhgtNHgwQipa0g== X-Received: by 2002:a0c:9de0:: with SMTP id p32mr5084874qvf.120.1550025496635; Tue, 12 Feb 2019 18:38:16 -0800 (PST) Received: from [172.16.0.18] ([96.231.217.246]) by smtp.gmail.com with ESMTPSA id q184sm13891220qkb.23.2019.02.12.18.38.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 12 Feb 2019 18:38:15 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Sean Turner In-Reply-To: <1466140720.170234113.1549687106882.JavaMail.zimbra@purplestreak.com> Date: Tue, 12 Feb 2019 21:38:14 -0500 Cc: Justin Uberti , Ben Campbell , draft-ietf-rtcweb-fec all , The IESG , secdir@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <201902010742.x117gdGm030846@rumpleteazer.rhmr.com> <240284129.169422738.1549676775109.JavaMail.zimbra@purplestreak.com> <1466140720.170234113.1549687106882.JavaMail.zimbra@purplestreak.com> To: Hilarie Orman X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [secdir] Security review of draft-ietf-rtcweb-fec-08 (was Re: Security review of draft-ietf-perc-srtp-ekt-diet-08) X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2019 02:38:31 -0000 Hilarie, Justin produced this PR to address this: = https://github.com/juberti/draughts/commit/6e991d1eeaf1e505bb89957319be38d= f4ada56f5 Cheers, spt > On Feb 8, 2019, at 23:38, Hilarie Orman = wrote: >=20 > OK, that's good. >=20 > Hilarie =20 >=20 > --=20 >=20 >=20 > ----- Original Message ----- > From: Justin Uberti > To: Hilarie Orman > Cc: Ben Campbell , The IESG , = secdir@ietf.org, draft-ietf-rtcweb-fec all = > Sent: Fri, 08 Feb 2019 18:51:32 -0700 (MST) > Subject: Re: Security review of draft-ietf-rtcweb-fec-08 (was Re: = Security review of draft-ietf-perc-srtp-ekt-diet-08) >=20 > Any suggestions on the sort of text you would like to see? >=20 > e.g. "In the WebRTC context, FEC is specifically concerned with = recovering > data from lost packets; any corrupted packets will be discarded by the = SRTP > decryption process. Therefore, as described in [RFC3711], Section = 10..." >=20 > On Fri, Feb 8, 2019 at 5:46 PM Hilarie Orman = > wrote: >=20 >> I think that the purpose of the FEC should be explicit, else the >> interaction with >> encryption will remain a source of confusion forever. >>=20 >> Hilarie >>=20 >> ----- Original Message ----- >> From: Justin Uberti >> To: Ben Campbell >> Cc: Hilarie Orman , The IESG = , >> secdir@ietf.org, draft-ietf-rtcweb-fec all < >> draft-ietf-rtcweb-fec.all@tools.ietf.org> >> Sent: Fri, 08 Feb 2019 18:20:41 -0700 (MST) >> Subject: Re: Security review of draft-ietf-rtcweb-fec-08 (was Re: = Security >> review of draft-ietf-perc-srtp-ekt-diet-08) >>=20 >> On Fri, Feb 1, 2019 at 2:49 PM Ben Campbell wrote: >>=20 >>> Hi, >>>=20 >>> Please note that this review is for draft-ietf-rtcweb-fec-08, not = the >> PERC >>> draft referenced in the subject. >>>=20 >>> Thanks! >>>=20 >>> Ben. >>>=20 >>>=20 >>>> On Feb 1, 2019, at 1:42 AM, Hilarie Orman = >>> wrote: >>>>=20 >>>> Security Review of WebRTC Forward Error Correction Requirements >>>> draft-ietf-rtcweb-fec-08 >>>>=20 >>>> Do not be alarmed. I have reviewed this document as part of the >>>> security directorate's ongoing effort to review all IETF documents >>>> being processed by the IESG. These comments were written primarily >>>> for the benefit of the security area directors. Document editors = and >>>> WG chairs should treat these comments just like any other last call >>>> comments. >>>>=20 >>>> The document describes the appropriate uses of FEC for web content = when >>>> using WebRTC. It also describes how to indicate that FEC is being >> used. >>>>=20 >>>> The Security Considerations mention the possibility of additional >> network >>>> congestion when using FEC. Although this can be a problem, I do = not >>> think >>>> it is a security issue, thus it does not belong in this section. >>>=20 >>=20 >> Understood. I think this paragraph could easily be moved to the = preceding >> section. >>=20 >>>>=20 >>>> There is a security-related issue wrt to FEC and encryption. If = the >>>> error model is that message blocks may be lost but not altered in >>>> transit, then FEC with encryption is fine. But if FEC is added for >>>> the purpose of correcting corrupted bits in a message block, then = it >>>> is important that FEC is done after encryption. The draft seems to >>>> ignore the issue, and it also seems to recommend a processing = scheme >>>> that would result in encryption of the FEC data. If there is a = body >>>> of practice for other IETF FEC protocols that explains these = issues, >>>> an explicit reference to it in the Security Considerations would be >>>> very helpful. >>>=20 >>> FEC is added specifically to protect against lost blocks. Any = corruption >> of the blocks will be detected by the decryption procedure, and such = blocks >> will be discarded. >>=20 >> There is a reference to RFC 3711, which stipulates the = fec-then-encrypt >> ordering. RFC 3711 is admittedly terse on this subject, but it is = quite >> clear about the ordering. >>=20 >>=20 >=20 > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview From nobody Wed Feb 13 19:02:35 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9914130EDD; Wed, 13 Feb 2019 19:02:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 qcnKyaDyHFfo; Wed, 13 Feb 2019 19:02:20 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6B04130ECF; Wed, 13 Feb 2019 19:02:20 -0800 (PST) Received: from lhreml706-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 1F7D2A9FCB1644FFFE23; Thu, 14 Feb 2019 03:02:18 +0000 (GMT) Received: from DGGEML405-HUB.china.huawei.com (10.3.17.49) by lhreml706-cah.china.huawei.com (10.201.108.47) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 14 Feb 2019 03:02:17 +0000 Received: from DGGEML510-MBX.china.huawei.com ([169.254.2.6]) by dggeml405-hub.china.huawei.com ([10.3.17.49]) with mapi id 14.03.0415.000; Thu, 14 Feb 2019 11:02:08 +0800 From: Mach Chen To: Benjamin Kaduk CC: Linda Dunbar , "secdir@ietf.org" , "mpls@ietf.org" , "draft-ietf-mpls-lsp-ping-lag-multipath.all@ietf.org" , "ietf@ietf.org" Thread-Topic: [secdir] Secdir last call review of draft-ietf-mpls-lsp-ping-lag-multipath-05 Thread-Index: AQHUkY+Xr7eIQ7lWe0az4uRG6fBCdqV9d+SwgERX9oCAHShNQA== Date: Thu, 14 Feb 2019 03:02:07 +0000 Message-ID: References: <154455986336.13151.8483284555885294015@ietfa.amsl.com> <20190126211729.GJ49072@kduck.mit.edu> In-Reply-To: <20190126211729.GJ49072@kduck.mit.edu> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.194.201] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-mpls-lsp-ping-lag-multipath-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2019 03:02:23 -0000 Hi Benjamin, Sorry for the delayed response! Please see my response inline... > -----Original Message----- > From: Benjamin Kaduk [mailto:kaduk@mit.edu] > Sent: Sunday, January 27, 2019 5:17 AM > To: Mach Chen > Cc: Linda Dunbar ; secdir@ietf.org; > mpls@ietf.org; draft-ietf-mpls-lsp-ping-lag-multipath.all@ietf.org; > ietf@ietf.org > Subject: Re: [secdir] Secdir last call review of draft-ietf-mpls-lsp-ping= -lag- > multipath-05 >=20 > On Fri, Dec 14, 2018 at 02:11:21AM +0000, Mach Chen wrote: > > Hi Linda, > > > > Thanks for the review! > > > > Some responses inline... > > > > > -----Original Message----- > > > From: ietf [mailto:ietf-bounces@ietf.org] On Behalf Of Linda Dunbar > > > Sent: Wednesday, December 12, 2018 4:24 AM > > > To: secdir@ietf.org > > > Cc: mpls@ietf.org; > > > draft-ietf-mpls-lsp-ping-lag-multipath.all@ietf.org; > > > ietf@ietf.org > > > Subject: Secdir last call review of > > > draft-ietf-mpls-lsp-ping-lag-multipath-05 > > > > > > Reviewer: Linda Dunbar > > > Review result: Ready > > > > > > I have reviewed this document as part of the security directorate's > > > ongoing effort to review all IETF documents being processed by the > > > IESG. These comments were written primarily for the benefit of the > > > security area directors. Document editors and WG chairs should > > > treat these comments just like any other last call comments. > > > > > > The summary of the review is Ready with comment > > > > > > The described mechanism for LSP Multipath Ping is very clear. The > > > Security Consideration re-uses the description of RFC8029, which is > > > very comprehensive. > > > It would be better if the draft describes how to prevent > > > intermediate LSRs in between the Initiating LSR and Responding LSR > > > from mis-using the detailed link information (e.g. forwarding to > somewhere else). > > > > The Echo Request and Reply messages are directly exchanged between the > Initiating LSR and the Responding LSR, those intermediate LSRs just forwa= rd > the messages as normal packets, they will not see the detailed link > information unless if they inspect and do DPI on every packet forwarded b= y > them. > > > > The detailed link information is supplied to the Initiating LSR for usi= ng, the > intermediate LSRs will not try to use it even if they received the inform= ation, > because there is no corresponding Echo Request to the received Echo Reply= . >=20 > The intermediate LSRs still will have access to the plaintext information= , even > if in normal operation they do not need to act upon that information. > Generally in this sort of situation we will either explicitly state that = the > intermediate nodes must be trusted to not abuse the information in > question, or provide some mechanism for end-to-end confidentiality > protection. "Intermediate nodes must be trusted to not abuse the information" is normal= ly assumed. For the intermediate nodes, there is no different between the E= cho Reply messages and any other data traffic, control messages. They just = forward the Echo Reply messages as normal packets. I am not sure it needs = to explicitly state this. Do you suggest to add such a statement in the se= curity consideration section? >=20 > Also (noting that I only skimmed the document so this may not make sense)= , > the security considerations seem to suggest using an IP ACL for determini= ng > which messages are trusted; IP ACLs are generally not recommended in favo= r > of cryptographic mechanisms at this point. IP ACLs was introduced in RFC 8029 and is reused in this document, it's jus= t one of the security mechanisms. This document is an extension to RFC 802= 9, as stated in this document, all security considerations defined in RFC 8= 029 apply to this document. Do you have any specific suggestion to the curr= ent security consideration? Best regards, Mach >=20 > -Benjamin From nobody Thu Feb 14 02:39:43 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B8D6012870E; Thu, 14 Feb 2019 02:39:35 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Vincent Roca To: Cc: iesg@ietf.org, draft-ietf-perc-private-media-framework.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.91.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155014077570.26619.9407568904769535504@ietfa.amsl.com> Date: Thu, 14 Feb 2019 02:39:35 -0800 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-perc-private-media-framework-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2019 10:39:36 -0000 Reviewer: Vincent Roca Review result: Has Issues Hello, I have reviewed this document as part of the security directorate’s ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Summary: **Has Issues** I have several significant concerns with respect to the Security Considerations section. ** Section 8.1 Why is it said that: "A successful attacker might be able to get the Media Distributor to forward such packets." Is it really possible? That would be a big design issue! In fact the following sentence suggest the opposite and I think this is essentially an erroneous manner to present things. Please see comments on Section 8.2.4 on saying things the other way round. The same comment applies to the remaining two paragraphs. I suggest the authors explain that the proposal prevents an attacker to claim being a regular Media Distributor and therefore to fool endpoints because ...". ** Section 8.2.2. Is the following sentence correct: The mitigation for a replay attack is to prevent old packets beyond a small-to-modest jitter and network re-ordering sized window to be rejected. Is "prevent [...] to be rejected" correct? I'd say "... to be delivered" instead. Another comment. Replay protection seems to be based on timing considerations rather than on the use of unique sequence numbers that must not be replayed (except if a wrapping to zero occurs of course). Is that correct? Additionally, is this mechanism carefully described in this document? Since it is explained that E2E replay protection MUST be provided, it's essential to be very clear on how to perform this. Failing to do so is a big issue. ** Section 8.2.3 It is said that "a Media Distributor can select to not deliver a particular stream for a while." That's perfectly true, yet is this a "Delayed playout attack"? I'd rather call it a Media Distributor censorship attack, or something along this line. The main idea behind the attack is not to delay a stream but to censor a source. In the second paragraph I don't understand why it is said that: "the receiver believing that it is what was said just now, and only delayed due to transport delay." Any RTP packet contains a timestamp (whose integrity is protected end-to-end if I understand correctly), and this timestamp is used by the receiver to identify timing issues. The fact a packet is delayed (significantly) by a Media Distributor cannot be misinterpreted by a receiver as a "what was said just now". The receiver immediately identifies this delay. I now understand the title ("delayed playout") but I really suspect this is a mistake as (too much) delayed packets will not be played at all. ** Section 8.2.4: I don't like the way this section is written. It first explains what a Media Distributor could do if it could alter a certain header field (in this case SSRC), it details the consequences, to finally explain that this is not possible. This Security Discussion section is essentially meant to discuss remaining security issues or highlight specific aspects, not what could happen with a different, non secure, design. This text could also be written the other way round: "By including the SSR field into the integrity check, PERC prevents splicing attacks where...". ** Missing in 8.2 The RTCP flows are not encrypted end-to-end (unlike data flows) but only hop-by-hop. Consequently, a malicious Media Distributors may corrupt an RTCP packet content (e.g., reception statistics in RR) or forge malicious RTCP packets which may trigger various effects at a sender. There are other types of RTCP packets that may be attacked as well with various consequences. None of this is explained in section 8.2. "Media Distributor Attacks". ** General comments about 8.1 and 8.2 Insider attacks are a powerful form of attacker model with severe consequences. This is not a big surprise. I'd be more interesting in a detailed 8.1 section, more likely to happen (weaker attacker model). Suggestion: ** 8.2. Instead of: "The Media Distributor can attack the session in a number of possible ways." I suggest: "A malicious or compromised Media Distributor can ..." Typos: ** Intro: s/virutalized/virtualized/ ** Section 2: s/and is never allowed have access/and is never allowed to have access/ ** 8. Security Considerations: s/could incorrectly assuming/could incorrectly assume/ s/This attack is be mitigated/This attack is mitigated/ s/when an already received packets/when an already received packet/ Other comments: ** Section 6, intro: (it's a detail, but...) I don't think that the use of "and so forth" is adequate in a specification that aims to be exhaustive. The list of items addressed in section 6 is finished. Cheers, Vincent From nobody Thu Feb 14 04:27:53 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E1EF813106D for ; Thu, 14 Feb 2019 04:27:51 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Tero Kivinen To: X-Test-IDTracker: no X-IETF-IDTracker: 6.91.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu Message-ID: <155014727188.26643.7929349060709662883.idtracker@ietfa.amsl.com> Date: Thu, 14 Feb 2019 04:27:51 -0800 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2019 12:27:52 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2019-02-21 Reviewer LC end Draft Daniel Migault R2019-01-16 draft-ietf-dmm-ondemand-mobility-16 Magnus Nystrom 2019-02-04 draft-ietf-jmap-mail-14 Radia Perlman R2019-02-01 draft-ietf-payload-flexible-fec-scheme-17 Yaron Sheffer 2019-02-08 draft-ietf-uta-smtp-require-tls-07 For telechat 2019-03-07 Reviewer LC end Draft Russ Mundy R2019-01-31 draft-ietf-mpls-sfc-05 Sean Turner 2019-02-19 draft-ietf-nfsv4-mv1-msns-update-04 Liang Xia 2019-02-21 draft-ietf-sipbrandy-rtpsec-07 Last calls: Reviewer LC end Draft Daniel Gillmor 2018-03-19 draft-gutmann-scep-13 Tobias Gondrom R2019-02-15 draft-ietf-rtcweb-security-arch-18 Leif Johansson 2018-12-24 draft-ietf-6lo-nfc-13 Russ Mundy 2017-09-14 draft-spinosa-urn-lex-13 Tim Polk 2019-02-13 draft-ietf-sipcore-reason-q850-loc-05 Kyle Rose R2018-08-29 draft-ietf-lisp-rfc6830bis-26 Stefan Santesson 2019-02-11 draft-ietf-extra-imap-fetch-preview-02 Stefan Santesson R2018-11-20 draft-wilde-service-link-rel-10 Takeshi Takahashi 2019-02-17 draft-ietf-kitten-pkinit-alg-agility-04 Takeshi Takahashi R2018-08-31 draft-ietf-lisp-rfc6833bis-24 Carl Wallace 2019-02-15 draft-ietf-rtcweb-security-11 David Waltermire 2019-02-15 draft-ietf-rtcweb-ip-handling-11 Samuel Weiler 2019-03-05 draft-faltstrom-unicode11-07 Brian Weis 2019-02-27 draft-ietf-dnsop-algorithm-update-05 Klaas Wierenga 2019-02-26 draft-ietf-mpls-sr-over-ip-02 Paul Wouters 2019-02-26 draft-ietf-mpls-sfc-encapsulation-02 Taylor Yu 2018-11-28 draft-ietf-alto-cost-calendar-10 Early review requests: Reviewer Due Draft Daniel Franke 2018-01-31 draft-ietf-intarea-provisioning-domains-00 Next in the reviewer rotation: Taylor Yu Dacheng Zhang Derek Atkins John Bradley Nancy Cam-Winget Shaun Cooley Roman Danyliw Alan DeKok Linda Dunbar Donald Eastlake From nobody Thu Feb 14 08:02:06 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0396131088; Thu, 14 Feb 2019 08:01:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 gC0ez7A-HTZ6; Thu, 14 Feb 2019 08:01:46 -0800 (PST) Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [IPv6:2a00:1398:2::10:81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16A4213104A; Thu, 14 Feb 2019 08:01:45 -0800 (PST) Received: from i72vorta.tm.uni-karlsruhe.de ([141.3.71.26] helo=i72vorta.tm.kit.edu) by iramx2.ira.uni-karlsruhe.de with esmtpsa port 25 iface 141.3.10.8 id 1guJSI-0004uy-1e; Thu, 14 Feb 2019 17:01:42 +0100 Received: from [IPv6:::1] (ip6-localhost [IPv6:::1]) by i72vorta.tm.kit.edu (Postfix) with ESMTPS id E93464200AA; Thu, 14 Feb 2019 17:01:41 +0100 (CET) To: Kyle Rose , secdir@ietf.org Cc: ietf@ietf.org, tsvwg@ietf.org References: <154992443765.29641.355119587706336977@ietfa.amsl.com> From: "Bless, Roland (TM)" Openpgp: preference=signencrypt Autocrypt: addr=roland.bless@kit.edu; prefer-encrypt=mutual; keydata= xsFNBFi0OxABEACy2VohJ7VhSu/xPCt4/6qCrw4Pw2nSklWPfAYEk1QgrbiwgvLAP9WEhAIU w45cojBaDxytIGg8eaYeIKSmsXjHGbV/ZTfo8r11LX8yPYR0WHiMWZpl0SHUd/CZIkv2pChO 88vF/2FKN95HDcp24pwONF4VhxJoSFk6c0mDNf8Em/Glt9BcWX2AAvizTmpQDshaPje18WH3 4++KwPZDd/sJ/hHSXiPg1Gdhs/OG/C0CJguOAlqbgSVAe3qKOr1M4K5M+wVpsk373pXRfxd7 ZAmZ05iBTn+LfgVcz+AfaKKcsWri5CdTT+7JDL6QNQpox+b5FXZFSHnEIST+/qzfG7G2LqqY mml6TYY8XbaNyXZP0QKncfSpRx8uTRWReHUa1YbSuOxXYh6bXpcugD25mlC/Lu0g7tz4ijiK iIwq9+P2H1KfAAfYyYZh6nOoE6ET0TjOjUSa+mA8cqjPWX99kEEgf1Xo+P9fx9QLCLWIY7zc mSM+vjQKgdUFpMSCKcYEKOuwlPuOz8bVECafxaEtJJHjCOK8zowe2eC9OM+G+bmtAO3qYcYZ hQ/PV3sztt/PjgdtnFAYPFLc9189rHRxKsWSOb4xPkRw/YQAI9l15OlUEpsyOehxmAmTsesn tSViCz++PCdeXrQc1BCgl8nDytrxW+n5w1aaE8aL3hn8M0tonQARAQABzShSb2xhbmQgQmxl c3MgKFRNKSA8cm9sYW5kLmJsZXNzQGtpdC5lZHU+wsGABBMBCAAqAhsDBQkSzAMABQsJCAcC BhUICQoLAgQWAgMBAh4BAheABQJYtYdHAhkBAAoJEKON2tlkOJXuzWkP+wfjUnDNzRm4r34a AMWepcQziTgqf4I1crcL6VD44767HhyFsjcKH31E5G5gTDxbpsM4pmkghKeLrpPo30YK3qb7 E9ifIkpJTvMu0StSUmcXq0zPyHZ+HxHeMWkosljG3g/4YekCqgWwrB62T7NMYq0ATQe1MGCZ TAPwSPGCUZT3ioq50800FMI8okkGTXS3h2U922em7k8rv7E349uydv19YEcS7tI78pggMdap ASoP3QWB03tzPKwjqQqSevy64uKDEa0UgvAM3PRbJxOYZlX1c3q/CdWwpwgUiAhMtPWvavWW Tcw6Kkk6e0gw4oFlDQ+hZooLv5rlYR3egdV4DPZ1ugL51u0wQCQG9qKIMXslAdmKbRDkEcWG Oi2bWAdYyIHhhQF5LSuaaxC2P2vOYRHnE5yv5KTV3V7piFgPFjKDW+giCRd7VGfod6DY2b2y zwidCMve1Qsm8+NErH6U+hMpMLeCJDMu1OOvXYbFnTkqjeg5sKipUoSdgXsIo4kl+oArZlpK qComSTPhij7rMyeu/1iOwbNCjtiqgb55ZE7Ekd84mr9sbq4Jm/4QGnVI30q4U2vdGSeNbVjo d1nqjf3UNzP2ZC+H9xjsCFuKYbCX6Yy4SSuEcubtdmdBqm13pxua4ZqPSI0DQST2CHC7nxL1 AaRGRYYh5zo2vRg3ipkEzsFNBFi0OxABEAC2CJNp0/Ivkv4KOiXxitsMXZeK9fI0NU2JU1rW 04dMLF63JF8AFiJ6qeSL2mPHoMiL+fG5jlxy050xMdpMKxnhDVdMxwPtMiGxbByfvrXu18/M B7h+E1DHYVRdFFPaL2jiw+Bvn6wTT31MiuG9Wh0WAhoW8jY8IXxKQrUn7QUOKsWhzNlvVpOo SjMiW4WXksUA0EQVbmlskS/MnFOgCr8q/FqwC81KPy+VLHPB9K/B65uQdpaw78fjAgQVQqpx H7gUF1EYpdZWyojN+V8HtLJx+9yWAZjSFO593OF3/r0nDHEycuOjhefCrqr0DDgTYUNthOdU KO2CzT7MtweRtAf0n27zbwoYvkTviIbR+1lV1vNkxaUtZ6e1rtOxvonRM1O3ddFIzRp/Qufu HfPe0YqhEsrBIGW1aE/pZW8khNQlB6qt20snL9cFDrnB6+8kDG3e//OjK1ICQj9Y/yyrJVaX KfPbdHhLpsgh8TMDPoH+XXQlDJljMD0++/o7ckO3Sfa8Zsyh1WabyKQDYXDmDgi9lCoaQ7Lf uLUpoMvJV+EWo0jE4RW/wBGQbLJp5usy5i0fhBKuDwsKdLG3qOCf4depIcNuja6ZmZHRT+3R FFjvZ/dAhrCWpRTxZANlWlLZz6htToJulAZQJD6lcpVr7EVgDX/y4cNwKF79egWXPDPOvQAR AQABwsFlBBgBCAAPBQJYtDsQAhsMBQkSzAMAAAoJEKON2tlkOJXukMoP/jNeiglj8fenH2We 7SJuyBp8+5L3n8eNwfwY5C5G+etD0E6/lkt/Jj9UddTazxeB154rVFXRzmcN3+hGCOZgGAyV 1N7d8xM6dBqRtHmRMPu5fUxfSqrM9pmqAw2gmzAe0eztVvaM+x5x5xID2WZOiOq8dx9KOKrp Zorekjs3GEA3V1wlZ7Nksx/o8KZ04hLeKcR1r06zEDLN/yA+Fz8IPa0KqpuhrL010bQDgAhe 9o5TA0/cMJpxpLqHhX2As+5cQAhKDDsWJu3oBzZRkN7Hh/HTpWurmTQRRniLGSeiL0zdtilX fowyxGXH6QWi3MZYmpOq+etr7o4EGGbm2inxpVbM+NYmaJs+MAi/z5bsO/rABwdM5ysm8hwb CGt+1oEMORyMcUk/uRjclgTZM1NhGoXm1Un67+Rehu04i7DA6b8dd1H8AFgZSO2H4IKi+5yA Ldmo+ftCJS83Nf6Wi6hJnKG9aWQjKL+qmZqBEct/D2uRJGWAERU5+D0RwNV/i9lQFCYNjG9X Tew0BPYYnBtHFlz9rJTqGhDu4ubulSkbxAK3TIk8XzKdMvef3tV/7mJCmcaVbJ2YoNUtkdKJ goOigJTMBXMRu4Ibyq1Ei+d90lxhojKKlf9yguzpxk5KYFGUizp0dtvdNuXRBtYrwzykS6vB zTlLqHZ0pvGjNfTSvuuN Organization: Institute of Telematics, Karlsruhe Institute of Technology Message-ID: <03bfb567-cc86-56fa-6db1-8a42040a6d97@kit.edu> Date: Thu, 14 Feb 2019 17:01:41 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <154992443765.29641.355119587706336977@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de) X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de esmtpsa 1550160102.109889558 Archived-At: Subject: Re: [secdir] [tsvwg] Secdir last call review of draft-ietf-tsvwg-le-phb-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2019 16:01:50 -0000 Hi Kyle, thanks for the review. See response inline. Am 11.02.19 um 23:33 schrieb Kyle Rose: > I agree that there are no remarkable security or privacy considerations for > this draft, but I would wordsmith the privacy paragraph slightly. It says: > > q( However, this disclosed information is only useful if some form of > identification happened at the same time ) > > glossing over the fact that identification is typically present in every > packet: the IP address of the user. It provides at least one bit of information > about what the user is doing, which, in conjunction with metadata from other > flows to/from that address, can potentially reveal more about user identity > and/or behavior. The reason the privacy impact is unremarkable is that it is > highly likely the case that such traffic is already classifiable as unimportant > via the sort of traffic analysis that troubles privacy advocates, when > considering the endpoint, payload length, pacing, etc. The LE DSCP marking does not say that this traffic is "unimportant", it basically classifies the traffic as being of low priority/urgency. I think that the statement "However, this disclosed information is only useful if some form of identification happened at the same time" is still correct, but probably needs a bit more explanation that this is often given due to the IP addresses in the packet. Compared to the plethora of traffic analysis possibilities and general privacy threats (e.g., see RFC 6973) the impact of disclosed information by the LE DSCP is likely negligible in most cases. So my suggestion is the following text: "However, this disclosed information is only useful if some form of identification happened at the same time, which is often given due to the presence of IP addresses in the packet. Compared to the numerous traffic analysis possibilities and general privacy threats (e.g., see [RFC 6973]) the impact of disclosed information by the LE DSCP is likely negligible in most cases." > Unrelated to secdir, I am also vaguely concerned about the impact on path > elements that pass along the LE PHB but treat the traffic as BE: especially for > traffic lacking congestion control (e.g., unicast hops for multicast traffic), > can they be put in the position of forwarding large volumes of traffic in vain, > i.e., traffic that will be dropped later? For CC-managed unicast traffic, it Yes, but it's a bit in the responsibility of the DS domain operators. If they just remap the LE PHB to BE, it's at their own risk. The recommendation is to use only congestion controlled transport for LE marked traffic (same as for BE in general). However, even a congestion controlled traffic load can be too high if the number of sources is too high (e.g., many flows with a congestion window of 1 MSS could easily overload links). That is a capacity problem that isn't solved by traditional end-to-end congestion control. > seems that the sender will back off sufficiently following congestion-induced > loss to make this no worse than a highly-lossy destination at BE. It might also > be the case that multicast congestion-induced loss in LE is no worse than > congestion problems with multicast in general, but I'd like to understand this > a bit better. I agree that the multicast congestion-induced loss in LE is no worse than congestion problems with multicast in general, but there is a subtle difference. the multicast LE replication problem is covered in section 9. Depending on the implementation replication of LE multicast packets inside a node may impact other traffic in an undesired way: the expectation is that LE packets only scavenge otherwise unused resources. I think that this is covered by the first sentence of the last paragraph in sec.9: While the resource contention problem caused by multicast packet replication is also true for other Diffserv PHBs, LE forwarding is special, because often it is assumed that LE packets get only forwarded in case of available resources at the output ports. So what is missing in your point of view for a better understanding? Regards, Roland From nobody Thu Feb 14 12:22:54 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 986B112EB11 for ; Thu, 14 Feb 2019 12:22:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.org 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 xDWlaGpDWRLH for ; Thu, 14 Feb 2019 12:22:47 -0800 (PST) Received: from mail-yw1-xc33.google.com (mail-yw1-xc33.google.com [IPv6:2607:f8b0:4864:20::c33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5611F12F1AB for ; Thu, 14 Feb 2019 12:22:45 -0800 (PST) Received: by mail-yw1-xc33.google.com with SMTP id n12so2827323ywn.13 for ; Thu, 14 Feb 2019 12:22:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zw0UZvxpBbSuaUrhSQ3QH2WCVZUY4kQhyinOoe5YtMs=; b=l0xXdx+M80O1kl+iLKMQU6kyQ+Z/qRF+lNaQARKsnwBIAd1fiwwBwsW1qzYEPerEN+ Rq2nWD4tbWS9THLt92e96weaSyRLGlHKwW2mSFNmX3Zzw8GspTkzNftz3n5TfcDOfEBl XdtkuBiH/MGrCYzHHUxUQGht8KUvf8BQash4U= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=zw0UZvxpBbSuaUrhSQ3QH2WCVZUY4kQhyinOoe5YtMs=; b=OX+bYGTC8XM1jpQJScVHlGXEeVPtqnha9lVWcjhQRfx+ymV/lPvsvFYqJJRDzhjiu+ TpOdWEA3vw2A6FT9+I/tWUmbRSAP5tR5s3vM656//SU2gbqlI7d5iltPxx/jljNGTz6f tW89mxXsfAA7cNPd6h46Pk7Omad0JkE0kJ7oS5sGLhrN8VDLp2I6M5/EKZekkZ0mirSw RN9YQACnPT4SaUketdwN3d2erB0njmeZPB6wpWE28wrTDjdkcSNoTAC7phecGjOivD8J HdvzR5R3KVNBOW2sxHQQ00hQ5KweKc/kfO2CwLuFZ1hw97W1lw9Bn0tLTnAczF1gvEb9 hmKA== X-Gm-Message-State: AHQUAuasaKVyAp5liUAyt29B1DuOlJiLepbvkLwH8sv44aWImpgX6hBJ JdAtRVi6f0ki9cvcQkZW/6eMeghbNt0lqdaSdgbZ8Q== X-Google-Smtp-Source: AHgI3IaWaSF8a60FVYiN2y6MJZU5hXT7kfjLK1GussDoGUrEMFpVzfu5AUdqplQPp6YmrK/o2UQyvk4O0Fi43AJEk88= X-Received: by 2002:a81:d008:: with SMTP id v8mr4905718ywi.464.1550175764168; Thu, 14 Feb 2019 12:22:44 -0800 (PST) MIME-Version: 1.0 References: <154992443765.29641.355119587706336977@ietfa.amsl.com> <03bfb567-cc86-56fa-6db1-8a42040a6d97@kit.edu> In-Reply-To: <03bfb567-cc86-56fa-6db1-8a42040a6d97@kit.edu> From: Kyle Rose Date: Thu, 14 Feb 2019 15:22:33 -0500 Message-ID: To: "Bless, Roland (TM)" Cc: IETF SecDir , IETF Discussion Mailing List , tsvwg@ietf.org Content-Type: multipart/alternative; boundary="000000000000c357560581e06b67" Archived-At: Subject: Re: [secdir] [tsvwg] Secdir last call review of draft-ietf-tsvwg-le-phb-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2019 20:22:49 -0000 --000000000000c357560581e06b67 Content-Type: text/plain; charset="UTF-8" > > and/or behavior. The reason the privacy impact is unremarkable is that it is > > highly likely the case that such traffic is already classifiable as > unimportant > > via the sort of traffic analysis that troubles privacy advocates, when > > considering the endpoint, payload length, pacing, etc. > > The LE DSCP marking does not say that this traffic is "unimportant", > it basically classifies the traffic as being of low priority/urgency. > Right, "unimportant" is the wrong word. I meant "uninteresting" from the perspective of an observer interested in learning about the user behind some traffic (e.g., a state level actor). Software downloads, for instance, are less likely to be interesting for surveillance purposes than general web traffic, which is not going to be LE. The net effect of marking some packets LE is to reduce the chaff/noise from which wheat/signal can be extracted. > I think that the statement "However, this disclosed information is only > useful if some form of identification happened at the same time" is > still correct, but probably needs a bit more explanation that this > is often given due to the IP addresses in the packet. Compared to the > plethora of traffic analysis possibilities and general privacy threats > (e.g., see RFC 6973) the impact of disclosed information by the LE DSCP > is likely negligible in most cases. So my suggestion is the following > text: > > "However, this disclosed information is only useful if some form of > identification happened at the same time, which is often given due to > the presence of IP addresses in the packet. Compared to the numerous > traffic analysis possibilities and general privacy threats (e.g., see > [RFC 6973]) the impact of disclosed information by the LE DSCP is likely > negligible in most cases." > I think the wording here is a bit awkward, and simultaneity isn't really the limiting factor. I might start with: "However, this disclosed information is useful only if correlation with metadata (such as the user's IP address) and/or other flows reveal user identity. ..." > I agree that the multicast congestion-induced loss in LE is no worse > than congestion problems with multicast in general, but there is a > subtle difference. the multicast LE replication problem is covered in > section 9. Depending on the implementation replication of LE multicast > packets inside a node may impact other traffic in an undesired way: > the expectation is that LE packets only scavenge otherwise unused > resources. I think that this is covered by the first sentence of the > last paragraph in sec.9: > While the resource contention problem caused by multicast packet > replication is also true for other Diffserv PHBs, LE forwarding is > special, because often it is assumed that LE packets get only > forwarded in case of available resources at the output ports. > > So what is missing in your point of view for a better understanding? > Nothing. I think I'm happy with this explanation. Thanks, Kyle --000000000000c357560581e06b67 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> > and/or behavior. The reason the privacy impact i= s unremarkable is that it is
> highly likely the case that such traffic is already classifiable as un= important
> via the sort of traffic analysis that troubles privacy advocates, when=
> considering the endpoint, payload length, pacing, etc.

The LE DSCP marking does not say that this traffic is "unimportant&quo= t;,
it basically classifies the traffic as being of low priority/urgency.

Right, "unimportant" is the wrong = word. I meant "uninteresting" from the perspective of an observer= interested in learning about the user behind some traffic (e.g., a state l= evel actor). Software downloads, for instance, are less likely to be intere= sting for surveillance purposes than general web traffic, which is not goin= g to be LE. The net effect of marking some packets LE is to reduce the chaf= f/noise from which wheat/signal can be extracted.
=C2=A0
I think that the statement "However, this disclosed information is onl= y
useful if some form of identification happened at the same time" is still correct, but probably needs a bit more explanation that this
is often given due to the IP addresses in the packet. Compared to the
plethora of traffic analysis possibilities and general privacy threats
(e.g., see RFC 6973) the impact of disclosed information by the LE DSCP
is likely negligible in most cases. So my suggestion is the following
text:

"However, this disclosed information is only useful if some form of identification happened at the same time, which is often given due to
the presence of IP addresses in the packet. Compared to the numerous
traffic analysis possibilities and general privacy threats (e.g., see
[RFC 6973]) the impact of disclosed information by the LE DSCP is likely negligible in most cases."

I think= the wording here is a bit awkward, and simultaneity isn't really the l= imiting factor. I might start with:

"Howe= ver, this disclosed information is useful only if correlation with metadata= (such as the user's IP address) and/or other flows reveal user identit= y. ..."
=C2=A0
I agree that the multicast congestion-induced loss in LE is no worse
than congestion problems with multicast in general, but there is a
subtle difference. the multicast LE replication problem is covered in
section 9. Depending on the implementation replication of LE multicast
packets inside a node may impact other traffic in an undesired way:
the expectation is that LE packets only scavenge otherwise unused
resources. I think that this is covered by the first sentence of the
last paragraph in sec.9:
=C2=A0 =C2=A0While the resource contention problem caused by multicast pack= et
=C2=A0 =C2=A0replication is also true for other Diffserv PHBs, LE forwardin= g is
=C2=A0 =C2=A0special, because often it is assumed that LE packets get only<= br> =C2=A0 =C2=A0forwarded in case of available resources at the output ports.<= br>
So what is missing in your point of view for a better understanding?

Nothing. I think I'm happy with this expl= anation.

Thanks,
Kyle

--000000000000c357560581e06b67-- From nobody Thu Feb 14 16:21:12 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BA2B130DC0; Thu, 14 Feb 2019 16:21:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 zmoi9H989nSG; Thu, 14 Feb 2019 16:21:01 -0800 (PST) Received: from mail-ot1-x32e.google.com (mail-ot1-x32e.google.com [IPv6:2607:f8b0:4864:20::32e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A723128B36; Thu, 14 Feb 2019 16:21:01 -0800 (PST) Received: by mail-ot1-x32e.google.com with SMTP id 98so13832688oty.1; Thu, 14 Feb 2019 16:21:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=n922hV57y+jskmn52X15GpclegwaH6D8lBZZTCJYE24=; b=Yhrr4U9MeDYsUUwjQl+oMAsav05xrdLeJJAszWVf6MwxY0qNrG3qvr0+0eamRgzP+R EqLNn9+FJdpZDaDxHhDbqQoKgM8EVze6mG38LNT5C78uCZkcL2HkKdIMWfLP9pH00IiH YpuP8hwLxlyTXMmdvFbzZ48ZC/FjX6Mw2JCWqD2WI/Hf29iy4odRLHlPV8kwNcF9hJVE /vKa/qtOG+cFjvjC+tAfZIc6IWRGfgvvwIRMsib9JQ9UFScjq6XZr4GhYXEFSNWQF4Dc 1Xjpm8SgmKsIrkjVyu7Qy+qkGizQcTyYqTvxpxiTlp/MQm2pvGo5cbna1EXrFvPY4pX6 B55A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=n922hV57y+jskmn52X15GpclegwaH6D8lBZZTCJYE24=; b=UWSTWR4WX824ku+5WxE+VSHNY6SApFGc4GonVtt/CJDke4vd6IUkLFE4ycAxqKtYiy 1A6C9TybuPFBha2LeZ/qO9Rp7tGB/6Qk9CjwEKoRhy8y1Q292W63PLISA8sUd5uiPrNj +JsNNghgl5VchnNr1QTdZUEcBlDfZtSC4yj0w/yDRbdoAif7zfxAJ0mZ4Zit/TggiFRN pNMp/sSljPEGAfg5mqgWnFuRHPx0ZOVc71ZP4QLaEjK+rTQn+d6hnIawV/NZoFlrMjZW AwE0004Y1+mG79DZTJamSt4S75QJmhjCugRRdLBzAj2zvqS8THongMf8GwMw9wPQD2MP MGwA== X-Gm-Message-State: AHQUAuZoZeg0lL+lyF5GWeDMsCdJYzUo8i896Vwbxhyo/ecx+/XK6Upe Ao39rqQDQ5nQlf2H7Y9lIM8N235BydGqzUKoV5YumyVt X-Google-Smtp-Source: AHgI3IahxqoxtK7P8N1B76QQHLY876x07NNjw+Llzu8lqLK32LR7JAlf8OefUxsG655XH5LcWB5gn962PYjmtF66tYc= X-Received: by 2002:a54:4391:: with SMTP id u17mr3951416oiv.111.1550190060271; Thu, 14 Feb 2019 16:21:00 -0800 (PST) MIME-Version: 1.0 References: <154886569351.10484.4703007670359734409@ietfa.amsl.com> In-Reply-To: From: Kathleen Moriarty Date: Thu, 14 Feb 2019 19:20:23 -0500 Message-ID: To: Mark Nottingham Cc: IETF SecDir , draft-nottingham-rfc5785bis.all@ietf.org, IETF Content-Type: multipart/alternative; boundary="000000000000e082890581e3bf46" Archived-At: Subject: Re: [secdir] Secdir last call review of draft-nottingham-rfc5785bis-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2019 00:21:05 -0000 --000000000000e082890581e3bf46 Content-Type: text/plain; charset="UTF-8" Hi Mark, Thanks for your response and agreed updates. I'll cut out anything addressed and what was addressed from Alexey's email to simplify. On Mon, Feb 4, 2019 at 6:30 PM Mark Nottingham wrote: > Hi Kathleen, > > Thanks for the thorough review. Responses below. > > > > On 31 Jan 2019, at 3:28 am, Kathleen Moriarty < > kathleen.moriarty.ietf@gmail.com> wrote: > > > > Reviewer: Kathleen Moriarty > > Review result: Has Nits > > > > 3. Section 3.1 says: > > The "Well-Known URIs" registry is located at > > "https://www.iana.org/assignments/well-known-uris/". Registration > > requests can be made by following the instructions located there or > > by sending an email to the "wellknown-uri-review@ietf.org" mailing > > list. > > > > I'm not clear on the instructions as I follow the link to the registry > and > > there's a pointer to the RFC that this document will obsolete. I'm > assuming > > that the reference will be replaced with this document. Is that the > case or > > are there additional instructions than what will be included directly in > the > > registry? If they are repeated (I don't see an IANA request for that > action), > > that is fine, but I think it's a little confusing to send someone to > that link > > if they are already reading this document. This document is also going > through > > a review process to update that registry, so if instructions were > maintained at > > the registry URL, what would be the review process to alter the > instructions? > > I'm assuming that this sentence just should be removed, but if not, I'd > like to > > understand the update process for that registry (instructions for > registering > > values not adding them). If the sentence should be changed, I suggest > > something like: > > > > The "Well-Known URIs" registry is located at > > "https://www.iana.org/assignments/well-known-uris/". Registration > > requests can be made by following the instructions in this document and > > sending the email to the "wellknown-uri-review@ietf.org" mailing > > list. > > After extensive consultation with IANA regarding RFC8288's revision of > registration policy, the outcome was that this level of detail / > instruction is unnecessary; the text at the top of a registry page can be > tweaked by the Experts by asking IANA, and if they have concerns they can > take it up with the IESG as necessary. > > Personally I was a bit surprised by this, but also relieved; getting this > sort of thing *exactly* right in an RFC is difficult, and we need the > flexibility to change things (e.g., we're currently using a Github issue > queue to collect registration requests there, but that might change in the > future). > > What would be helpful here would be some text in the document that asks IANA to add the instructions to the registry. I'm hoping that more clearly states my question/request. > > > 4. Question on Change controller: Is it possible to successfully make a > request > > through an experimental track RFC or standards track only? If > experimental is > > allowed, can it only be provisional? > > The registry is Specification Required, so an experimental RFC can indeed > make a registry. It can be 'standard' if it meets this bar: "Other values > can also be registered as permanent, if the Experts find that they are in > use, in consultation with the community." > > I think the text that had me ask this question was the following: Standards-defined values have a status of "permanent". Other values can also be registered as permanent, if the Experts find that they are in use, in consultation with the community. Other values should be registered as "provisional". By standards-defined, do you mean through specification required in the IETF? > > 5. Section 3 has the following sentence: > > > > General requirements for registered relation types are described in > > Section 3. > > > > Did the document in a previous revision contain something in section 3 > about > > registered relation types or am I missing something when reading section > 3 > > (which is entirely possible)? If it were there (or maybe was in a > previous > > revision), I'd expect to see it in the following paragraph, but could > see the > > above text being dropped as an answer to this question as well (unless I > am > > missing something): > > > > It MAY also contain additional information, such as the syntax of > > additional path components, query strings and/or fragment identifiers > > to be appended to the well-known URI, or protocol-specific details > > (e.g., HTTP [RFC7231] method handling). > > Section 3 puts requirements on choosing a registered name, both > syntactically and with a more general SHOULD about how to choose a good > name. > OK, can you clarify in the text what you mean by registered relation type or have that sentence say registered name instead of relation type since that is the only time registered relation type appears in the document? I think that would help the reader. > > > 6. Section 3.1: Is the following referring to IETF standards-track > documents > > or could other standards from other SDOs (or some other constraint) be > included? > > > > Standards-defined values have a status of "permanent". Other values > > can also be registered as permanent, if the Experts find that they > > are in use, in consultation with the community. Other values should > > be registered as "provisional". > > The intent was values defined by Open Standards, in the sense of RFC2026, > 7.1.1. I'll clarify this, thanks. > Thank you! > > > > I'm guessing a standards track RFC is not necessary for standards track > because > > of the next paragraph in this section, but maybe some added text would > help to > > clarify the above paragraph? > > > > Provisional entries can be removed by the Experts if - in > > consultation with the community - the Experts find that they are not > > in use. The Experts can change a provisional entry's status to > > permanent at any time. > > Except for the issue above, I don't see how this is unclear; if a value is > defined by a standard, it is automatically permanent, but other values can > be as well, as per the text. Can you suggest text? > > > I'm rushing a bit right now, so sorry. I think the adjustment to the text above may help solve this. I'm happy to look at your revised version to see if I think it may not be clear enough for some readers. Thanks. > > 7. Section 5.1 second paragraph has the following text: > > > > Well-known URIs are registered on the advice of one or more experts > > (appointed by the IESG or their delegate), with a Specification > > Required (using terminology from [RFC8126]). > > > > This should read as follows according to RFC8126 section 5.2.1: > > https://tools.ietf.org/html/rfc8126#section-5.2.1 > > > > Well-known URIs are registered on the advice of one or more experts > > (appointed by the IESG), with a Specification > > Required (using terminology from [RFC8126]). > > > > There's no provision for the IESG to delegate assignment of an expert. > IESG > > member often consult working group chairs and experts, but the > assignment is > > currently performed by the IESG unless RFC8126 gets updated. > > My understanding is that this level of detail is unnecessary in the > registering document, as the IESG has the power to delegate naturally. If > this needs to be specified explicitly, that should be done in a revision of > RFC8126 section 5.2.1, not here. > I believe you are addressing this per the message exchange with Alexey. Thank you. > > > 9. Section 5.1: > > There may be additional information I am not aware of, hence the > following > > clarifying questions. Is there a hold on the registry from now until this > > document is published? Could an expert receive a request prior to > publication > > where they feel the right status is "provisional" and is timely (cannot > wait > > until after actions for this document are complete)? I'm asking because > of the > > following text and the answer may be yes, there is a hold, but I am not > seeing > > where one is listed. Since the expert can update the registry at any > time, is > > the second bullet necessary (could it cause problems)? > > > > Upon publication, IANA should: > > > > o Replace all references to RFC 5988 in that registry have been > > replaced with references to this document. > > > > o Update the status of all existing registrations to "permanent". > > We've been processing registration requests as normal throughout the > development period of this draft. When a registration request appears to > violate the intent of 5785 but is OK by 5785bis (which we believe > represents emerging consensus), I (wearing the Expert hat) have escalated > them to the ADs to confirm an exception. > > Part of the urgency in getting this document published is that I'm > uncomfortable with that, and of course it's onerous for all concerned. > > The second bullet shouldn't interfere with that. > Thanks for the clarification here and the updates, that's helpful. Best regards, Kathleen > > > Cheers and thanks again, > > -- > Mark Nottingham https://www.mnot.net/ > > -- Best regards, Kathleen --000000000000e082890581e3bf46 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Mark,

Thanks for yo= ur response and agreed updates.=C2=A0 I'll cut out anything addressed a= nd what was addressed from Alexey's email to simplify.

<= div class=3D"gmail_quote">
On Mon, Feb= 4, 2019 at 6:30 PM Mark Nottingham <mn= ot@mnot.net> wrote:
Hi Kathleen,

Thanks for the thorough review. Responses below.


> On 31 Jan 2019, at 3:28 am, Kathleen Moriarty <kathleen.moriarty.ietf@gm= ail.com> wrote:
>
> Reviewer: Kathleen Moriarty
> Review result: Has Nits


> 3. Section 3.1 says:
> The "Well-Known URIs" registry is located at
>=C2=A0 =C2=A0"https://www.iana.org/assignm= ents/well-known-uris/".=C2=A0 Registration
>=C2=A0 =C2=A0requests can be made by following the instructions located= there or
>=C2=A0 =C2=A0by sending an email to the "wellknown-uri-review@ietf.org= " mailing
>=C2=A0 =C2=A0list.
>
> I'm not clear on the instructions as I follow the link to the regi= stry and
> there's a pointer to the RFC that this document will obsolete.=C2= =A0 I'm assuming
> that the reference will be replaced with this document.=C2=A0 Is that = the case or
> are there additional instructions than what will be included directly = in the
> registry?=C2=A0 If they are repeated (I don't see an IANA request = for that action),
> that is fine, but I think it's a little confusing to send someone = to that link
> if they are already reading this document.=C2=A0 This document is also= going through
> a review process to update that registry, so if instructions were main= tained at
> the registry URL, what would be the review process to alter the instru= ctions?
> I'm assuming that this sentence just should be removed, but if not= , I'd like to
> understand the update process for that registry (instructions for regi= stering
> values not adding them).=C2=A0 If the sentence should be changed, I su= ggest
> something like:
>
>=C2=A0 =C2=A0The "Well-Known URIs" registry is located at
>=C2=A0 =C2=A0"https://www.iana.org/assignm= ents/well-known-uris/".=C2=A0 Registration
>=C2=A0 =C2=A0requests can be made by following the instructions in this= document and
>=C2=A0 =C2=A0sending the email to the "wellknown-uri-review@ietf.org&q= uot; mailing
>=C2=A0 =C2=A0list.

After extensive consultation with IANA regarding RFC8288's revision of = registration policy, the outcome was that this level of detail / instructio= n is unnecessary; the text at the top of a registry page can be tweaked by = the Experts by asking IANA, and if they have concerns they can take it up w= ith the IESG as necessary.

Personally I was a bit surprised by this, but also relieved; getting this s= ort of thing *exactly* right in an RFC is difficult, and we need the flexib= ility to change things (e.g., we're currently using a Github issue queu= e to collect registration requests there, but that might change in the futu= re).


What would be helpful here would be so= me text in the document that asks IANA to add the instructions to the regis= try.=C2=A0 I'm hoping that more clearly states my question/request.=C2= =A0=C2=A0
=C2=A0

> 4. Question on Change controller: Is it possible to successfully make = a request
> through an experimental track RFC or standards track only?=C2=A0 If ex= perimental is
> allowed, can it only be provisional?

The registry is Specification Required, so an experimental RFC can indeed m= ake a registry. It can be 'standard' if it meets this bar: "Ot= her values can also be registered as permanent, if the Experts find that th= ey are in use, in consultation with the community."


I think the text that had me ask this = question was the following:

   Standards-defined values have a status of "=
;permanent".  Other values
   can also be registered as permanent, if the Experts find that they
   are in use, in consultation with the community.  Other values should=C2=
=A0
=C2=A0 = =C2=A0 =C2=A0 =C2=A0be registered as "provisional".=C2=A0 = =C2=A0

By standards-defined, do you mean through s= pecification required in the IETF?


> 5. Section 3 has the following sentence:
>
>=C2=A0 =C2=A0General requirements for registered relation types are des= cribed in
>=C2=A0 =C2=A0Section 3.
>
> Did the document in a previous revision contain something in section 3= about
> registered relation types or am I missing something when reading secti= on 3
> (which is entirely possible)?=C2=A0 If it were there (or maybe was in = a previous
> revision), I'd expect to see it in the following paragraph, but co= uld see the
> above text being dropped as an answer to this question as well (unless= I am
> missing something):
>
>=C2=A0 =C2=A0It MAY also contain additional information, such as the sy= ntax of
>=C2=A0 =C2=A0additional path components, query strings and/or fragment = identifiers
>=C2=A0 =C2=A0to be appended to the well-known URI, or protocol-specific= details
>=C2=A0 =C2=A0(e.g., HTTP [RFC7231] method handling).

Section 3 puts requirements on choosing a registered name, both syntactical= ly and with a more general SHOULD about how to choose a good name.

OK, can you clarify in the text what you mean b= y registered relation type or have that sentence say registered name instea= d of relation type since that is the only time registered relation type app= ears in the document?=C2=A0 I think that would help the reader.
<= br>



> 6. Section 3.1:=C2=A0 Is the following referring to IETF standards-tra= ck documents
> or could other standards from other SDOs (or some other constraint) be= included?
>
>=C2=A0 =C2=A0Standards-defined values have a status of "permanent&= quot;.=C2=A0 Other values
>=C2=A0 =C2=A0can also be registered as permanent, if the Experts find t= hat they
>=C2=A0 =C2=A0are in use, in consultation with the community.=C2=A0 Othe= r values should
>=C2=A0 =C2=A0be registered as "provisional".

The intent was values defined by Open Standards, in the sense of RFC2026, 7= .1.1. I'll clarify this, thanks.

Th= ank you!=C2=A0


> I'm guessing a standards track RFC is not necessary for standards = track because
> of the next paragraph in this section, but maybe some added text would= help to
> clarify the above paragraph?
>
>=C2=A0 =C2=A0Provisional entries can be removed by the Experts if - in<= br> >=C2=A0 =C2=A0consultation with the community - the Experts find that th= ey are not
>=C2=A0 =C2=A0in use.=C2=A0 The Experts can change a provisional entry&#= 39;s status to
>=C2=A0 =C2=A0permanent at any time.

Except for the issue above, I don't see how this is unclear; if a value= is defined by a standard, it is automatically permanent, but other values = can be as well, as per the text. Can you suggest text?


I'm rushing a bit right now, so sorry. I think th= e adjustment to the text above may help solve this.=C2=A0 I'm happy to = look at your revised version to see if I think it may not be clear enough f= or some readers.=C2=A0 Thanks.
=C2=A0
> 7. Section 5.1 second paragraph has the following text:
>
>=C2=A0 =C2=A0Well-known URIs are registered on the advice of one or mor= e experts
>=C2=A0 =C2=A0(appointed by the IESG or their delegate), with a Specific= ation
>=C2=A0 =C2=A0Required (using terminology from [RFC8126]).
>
> This should read as follows according to RFC8126 section 5.2.1:
> https://tools.ietf.org/html/rfc8126#section-5.= 2.1
>
>=C2=A0 =C2=A0Well-known URIs are registered on the advice of one or mor= e experts
>=C2=A0 =C2=A0(appointed by the IESG), with a Specification
>=C2=A0 =C2=A0Required (using terminology from [RFC8126]).
>
> There's no provision for the IESG to delegate assignment of an exp= ert.=C2=A0 IESG
> member often consult working group chairs and experts, but the assignm= ent is
> currently performed by the IESG unless RFC8126 gets updated.

My understanding is that this level of detail is unnecessary in the registe= ring document, as the IESG has the power to delegate naturally. If this nee= ds to be specified explicitly, that should be done in a revision of RFC8126= section 5.2.1, not here.

I believe you= are addressing this per the message exchange with Alexey.=C2=A0 Thank you.=



> 9. Section 5.1:
> There may be additional information I am not aware of, hence the follo= wing
> clarifying questions. Is there a hold on the registry from now until t= his
> document is published?=C2=A0 Could an expert receive a request prior t= o publication
> where they feel the right status is "provisional" and is tim= ely (cannot wait
> until after actions for this document are complete)?=C2=A0 I'm ask= ing because of the
> following text and the answer may be yes, there is a hold, but I am no= t seeing
> where one is listed.=C2=A0 Since the expert can update the registry at= any time, is
> the second bullet necessary (could it cause problems)?
>
>=C2=A0 =C2=A0Upon publication, IANA should:
>
>=C2=A0 =C2=A0o=C2=A0 Replace all references to RFC 5988 in that registr= y have been
>=C2=A0 =C2=A0 =C2=A0 replaced with references to this document.
>
>=C2=A0 =C2=A0o=C2=A0 Update the status of all existing registrations to= "permanent".

We've been processing registration requests as normal throughout the de= velopment period of this draft. When a registration request appears to viol= ate the intent of 5785 but is OK by 5785bis (which we believe represents em= erging consensus), I (wearing the Expert hat) have escalated them to the AD= s to confirm an exception.

Part of the urgency in getting this document published is that I'm unco= mfortable with that, and of course it's onerous for all concerned.

The second bullet shouldn't interfere with that.
<= br>
Thanks for the clarification here and the updates, that's= helpful.

Best regards,
Kathleen=C2=A0


Cheers and thanks again,

--
Mark Nottingham=C2=A0 =C2=A0https://www.mnot.net/



--

Best regards,
Kathleen
--000000000000e082890581e3bf46-- From nobody Thu Feb 14 17:01:35 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BC6D130E1C; Thu, 14 Feb 2019 17:01:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mit.edu 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 TKOawq-jrAxt; Thu, 14 Feb 2019 17:01:31 -0800 (PST) Received: from NAM05-CO1-obe.outbound.protection.outlook.com (mail-eopbgr720112.outbound.protection.outlook.com [40.107.72.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E45B130E3F; Thu, 14 Feb 2019 17:01:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=v3zRiwkkR482GC81Qc8ZYIM2wRaq9TYd6j9IxkHDWIA=; b=HPI3+iBMJNhdErSlBfugim5Oo207owrDq/Mq9CK/i7MyRJ/RSbblCbKTbzMsjKKZKshV8cQu5rdrsrjsQJpbS4JjTdmWyeMOkYK3+yEX8hEY9kLeYN5cVOQthv5mHXFUDgcJCgcOzuMNIsm9s2g09dhlTjBosL503QcR/ZmhvK0= Received: from MWHPR01CA0029.prod.exchangelabs.com (2603:10b6:300:101::15) by DM5PR01MB3289.prod.exchangelabs.com (2603:10b6:3:fd::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1601.19; Fri, 15 Feb 2019 01:01:30 +0000 Received: from CO1NAM03FT060.eop-NAM03.prod.protection.outlook.com (2a01:111:f400:7e48::200) by MWHPR01CA0029.outlook.office365.com (2603:10b6:300:101::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1622.17 via Frontend Transport; Fri, 15 Feb 2019 01:01:30 +0000 Authentication-Results: spf=pass (sender IP is 18.9.28.11) smtp.mailfrom=mit.edu; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=mit.edu; Received-SPF: Pass (protection.outlook.com: domain of mit.edu designates 18.9.28.11 as permitted sender) receiver=protection.outlook.com; client-ip=18.9.28.11; helo=outgoing.mit.edu; Received: from outgoing.mit.edu (18.9.28.11) by CO1NAM03FT060.mail.protection.outlook.com (10.152.81.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1580.10 via Frontend Transport; Fri, 15 Feb 2019 01:01:27 +0000 Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x1F11Nnc017296 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 14 Feb 2019 20:01:25 -0500 Date: Thu, 14 Feb 2019 19:01:23 -0600 From: Benjamin Kaduk To: Vincent Roca CC: , , Message-ID: <20190215010122.GS56447@kduck.mit.edu> References: <155014077570.26619.9407568904769535504@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <155014077570.26619.9407568904769535504@ietfa.amsl.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:18.9.28.11; IPV:CAL; SCL:-1; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(346002)(396003)(376002)(39860400002)(136003)(2980300002)(199004)(51914003)(189003)(23726003)(16586007)(106466001)(786003)(4326008)(58126008)(54906003)(76176011)(106002)(186003)(26005)(86362001)(7696005)(316002)(53416004)(97756001)(33656002)(305945005)(88552002)(2906002)(75432002)(8936002)(486006)(26826003)(6246003)(229853002)(50466002)(956004)(478600001)(11346002)(14444005)(426003)(55016002)(356004)(336012)(126002)(46406003)(446003)(6916009)(476003)(246002)(47776003)(8676002)(1076003)(104016004)(18370500001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR01MB3289; H:outgoing.mit.edu; FPR:; SPF:Pass; LANG:en; PTR:outgoing-auth-1.mit.edu; A:1; MX:1; X-Microsoft-Exchange-Diagnostics: 1; CO1NAM03FT060; 1:83vqzQV99GthvfYvaLpop0V8ldW8PEuknRV1dgeg7aWav6QlI9syr7zO1KDNhXLgnHf1l0x+pc2jVWT/cs6lLqhYoFoWljFI0r47GPr7bwMpYKUoBTsDGCOJBmILfEl3kBsZwDCS0pjwLeexh0mgnp4EbuKVDqVCcz2BBmZ+pgI= X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 117b12d5-ca53-4446-ebf7-08d692e11e79 X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600110)(711020)(4605077)(4608076)(4709027)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060); SRVR:DM5PR01MB3289; X-MS-TrafficTypeDiagnostic: DM5PR01MB3289: X-Microsoft-Exchange-Diagnostics: 1; DM5PR01MB3289; 20:dqNBdMnGyzd4o3PdIz/dC3Xh5Xkzx/mmJcjgibtJGmZ0yc/P0g2IsfERE6g82bwwnuY0QMNi1p8uXUFj+f5gK5AQ3vziyRl3mfsxKhAhUfT+VTQh0Jv9m+OAoo0MA6wZs0jaNfzx+kjDdQzY5Oh/7n0OcUz9A9CMGRWjAOdi+UWTT+15FSr467a+mzNV6HH5Bsl7VrNV+s1BoO5NXUw/C32yMK2ea5i1s+meubbboKXFW94VNY/QIK/0PjMBtQWw+1yn4S73wOQSQObOD3guZWV2KBgCSQ/jmrOK4jcGEZLkoV/JaXQOZNjhpwV+fOe5qnTn9w8hWUasfriskK/TsMlXaD8T4KClbC89O8ukiXiRhCQ4uJtblk63HqacL1rb4Txx27HfPh3fZbPkrzpERIKGcPH9poWX7YQyhkADWkl9AX0fuITJIHNr8UgGEcYrxUFLjXvbgf+mo62aSPCxKhZNmP2tZOjwCOZJBmLDGiFi/7rpANygX5gsOluWteaCzMC3pt2N5+PgmiWa27W8zbWh0dIpNErhUYMAYgAhmtvTo9oJan1AfwdZQmvAMyX92RMcIwejI2pG6DWFd7J0eYZBsZr4w+e+kTqXvuVn+Lo= X-Microsoft-Antispam-PRVS: X-Forefront-PRVS: 09497C15EB X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DM5PR01MB3289; 23:+1SSBVpS7CyRXX1hH/ZefrMvhrLOknaipxh9WChrD?= =?us-ascii?Q?7i0IVaO9IgOmLy9zbSNx16/74Zt/4v4E4e9evTou6g2MEUosYghYA+EYqEIJ?= =?us-ascii?Q?tZnUVkPMfQZH1uZX2jhcxeVLSfqQDmDocTNoqToA75vIGD6q4qTcL+7leVrv?= =?us-ascii?Q?CPDNt3l0Mtt9rw1kLvco9yWxNBL3aubiq714q3BNP3+SjQGqGpTlL7yq1mK4?= =?us-ascii?Q?sdOR5Lwacx8HyUfHimnwN3GOw9/N3A0IZjVCamEcrHG2oIvIFDHsQ5AIoKuQ?= =?us-ascii?Q?pma8s927MPEH7CrCQDz4aURJ3F2A1MtJdKQM5E538S218DRV5MGadSNuiA5E?= =?us-ascii?Q?MN17ydHjXzaUZnx9XOreCslNduGO+XkLlEbKyNK9f8IBAIYQ7NYNlOCo9V1s?= =?us-ascii?Q?oG+JWSStFNEGnf3SC9HFhru1Wsj7iCQsVjCTtIih1VkTOC1DDfzLj+QexuQy?= =?us-ascii?Q?nxKp1ScddZscPvT5i5L1JH2Qjbp6ea1rxxkRfwhd+QO1Daaj2tp8kjDGhuDE?= =?us-ascii?Q?bmTcu7ze6mnEkINlbeYPg91eDj3LKC5HEbHDD7bhkFxc56/FcoynQEmiR8yP?= =?us-ascii?Q?T5GRcev6zMtPeSzesZNwUiI0zIBzeOk3HyzV3yJ4fxpGskVNAQH2UsMYxIZ3?= =?us-ascii?Q?PfS7AJismUtauFojdFPTEZ/QvwtOBJ0azPRack0yxqr+DpF3ajAyj9joADK6?= =?us-ascii?Q?YdfJUL1vFrYAaqEv9AqWUCgHxzGaTlo2hJYNAlRbPPSrrW8hi7hZAZXgzil8?= =?us-ascii?Q?ruLzSRvlnIcmCK3G6qV+ihDSRF3uKYgMOyBp3hD4I6U6Q6xx3OjORld1sz0Z?= =?us-ascii?Q?iY5KWREp0DJNhiEeRmGvD/bLUy9XgjXitCB5e7RCE4n5yFVUEA9P6PJqsY1k?= =?us-ascii?Q?amfuna3cWLezY6GDqj2MH14FIYcmYn9ARAEmt+7KlKvPXuO8+FeJax5Uj+kc?= =?us-ascii?Q?zLmrLervM8VoNHXgnG4iGsYy3MA6ybvlmEkcFlJMH5EZL6qY8/gCIxE1eJxy?= =?us-ascii?Q?n/95tgSkdjI6UI5z8m/FwWtIbQyE9OR8Afj3iyJlLcdyAFtkx1ih/wN4ALmc?= =?us-ascii?Q?44L/4T4jVQHXbbgJhJe1Jx/RtUCVDv3+4945WicF82MRqiLBu5HZKLemtVtl?= =?us-ascii?Q?VNB61A7aRfPjgixg9bYyyukHbYv/wYf85cr0oAJcQ0JcXW36uVB2QlMELlJv?= =?us-ascii?Q?Lrcvox3cVcghNMMMORzl7sQXlV9xid1RNYN?= X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Message-Info: lnSsToHint6zkkM8yiT0BRjE0QPvKg7zCgSNXC9iJxSUivim7fSn3qtbzfg0hlj6LXbu3rjrXeuYJwQVVYM6Ug5lPqWZeY01vYaiAPLajllt/Cqqkrc6LKqYm+jAxTYVn2QOq+dt6QkKxHcV3iC3q8d8F6Qqa4nGn6GrVjq9uIAfQs5jVYrKUno1fgMgtwGaEsfnLYcWzwJTzDcv4Gp15Fb3NqkIrpicO60sPh7tgNBjfz8JafwgwR5j+pemd9JKd9J6rWvAQxu2H7SBClyR/wBP9rz+HdbHIrYA/ZI/ajFuuvJc/3TnZBwdsbeRP7IiG6hInJfe1hmwLfFiOuItKHbmso8EgaK/dJRtSgajc3PzBdcd53JJMIrNy2SJQmspX/iJInGv/IBtECnQfd8N+ooH2UwSuNl4HNgLRrAqeKI= X-OriginatorOrg: mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Feb 2019 01:01:27.8708 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 117b12d5-ca53-4446-ebf7-08d692e11e79 X-MS-Exchange-CrossTenant-Id: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=64afd9ba-0ecf-4acf-bc36-935f6235ba8b; Ip=[18.9.28.11]; Helo=[outgoing.mit.edu] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR01MB3289 Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-perc-private-media-framework-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2019 01:01:33 -0000 Thanks for the review, Vincent! On one specific note... On Thu, Feb 14, 2019 at 02:39:35AM -0800, Vincent Roca wrote: > > ** Section 8.2.4: > I don't like the way this section is written. It first explains what a Media > Distributor could do if it could alter a certain header field (in this case > SSRC), it details the consequences, to finally explain that this is not > possible. This Security Discussion section is essentially meant to discuss > remaining security issues or highlight specific aspects, not what could happen > with a different, non secure, design. This text could also be written the other > way round: "By including the SSR field into the integrity check, PERC prevents > splicing attacks where...". There has been some fairly active discussion on the ietf@ list about topics including SSRC rewriting; my current suggestion to the authors would be to retain discussion of the topic but to reframe it as suggested here, "by including the field into the integrity check, this mechanism avoids splicing attacks wherein ..." -Benjamin From nobody Thu Feb 14 22:53:06 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACB18130E7E; Thu, 14 Feb 2019 22:52:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=E3PQiQG1; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=6yaSYl+D 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 Bqj_CjWIzpXF; Thu, 14 Feb 2019 22:52:53 -0800 (PST) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D2B4129741; Thu, 14 Feb 2019 22:52:53 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 0D4E62FEE; Fri, 15 Feb 2019 01:52:51 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Fri, 15 Feb 2019 01:52:52 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm1; bh=Q VdyvwgP5lJSDMQzSCdoc4SdXstsZM1l3fTZwmur2hI=; b=E3PQiQG128b2oZFbK iW1bWLQQSRKBml0eeu0P14Qpo7v4oPQxQQB2ttAA1PtXplKMxp73a36WCML2FxCZ mGxsxe/xqN1/f8eimoTD2WFOBCNgKhjXegYzTOxhhsGJTqOQKdcemwr41mVWiOV9 H8EGZ8xXO6yVYyFflrEQ+iUT4oXPv4EQGLBbmtktNzvelMC4Z14OR63tEs17zb3a +uZetOHoHhW70LSSIxx9KdLbrIpmOiDDlqcSoH+lNG+uBReq+4St2LfhsUgOzM3e /67YIXQbCsu9S+sK0VqyIXpjykPaDExec5Uvn9SWMsyAuK1hR5RG6MHnAzONf7y+ Q6Euw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=QVdyvwgP5lJSDMQzSCdoc4SdXstsZM1l3fTZwmur2 hI=; b=6yaSYl+DDrCDvZBeWwvgqWS2hCQmoPbhg9AcTn4zbvfqN1X/RnKWWWtf2 RqKCuuWCJigAYqhuTEirNcmYHMhFzCEMKV7+X/nhjlkCW/cs4TDb7JdmPhJY9/BY GFzSC3alUmSy6eW/ru23mz8UE4kAGwOjlZt0hD011FQqapZsl+gvg6BtuB117qXW qNJocq2FA3FAhsQUkMlRZpjK0S7plnAT4Uh/OWhrszynIXmT8oSe6ODvagTcfeOn umHP1xG9p1PudPnbxHgWns5maiuYwv2r2Xwx0py0aQJWn7ISE1aQler8XZMi3LOB 5qU9rvXJGom7/e2DqyodLKRGMdKvw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledruddtiedgleejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfquhhtnecuuegrihhlohhuthemucef tddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpegtggfuhfgjff fgkfhfvffosehtqhhmtdhhtddvnecuhfhrohhmpeforghrkhcupfhothhtihhnghhhrghm uceomhhnohhtsehmnhhothdrnhgvtheqnecuffhomhgrihhnpehmnhhothdrnhgvthdpih grnhgrrdhorhhgnecukfhppedugeegrddufeeirddujeehrddvkeenucfrrghrrghmpehm rghilhhfrhhomhepmhhnohhtsehmnhhothdrnhgvthenucevlhhushhtvghrufhiiigvpe dt X-ME-Proxy: Received: from attitudadjuster.mnot.net (unknown [144.136.175.28]) by mail.messagingengine.com (Postfix) with ESMTPA id 29E3BE4438; Fri, 15 Feb 2019 01:52:47 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Mark Nottingham In-Reply-To: Date: Fri, 15 Feb 2019 17:52:44 +1100 Cc: IETF SecDir , draft-nottingham-rfc5785bis.all@ietf.org, IETF Content-Transfer-Encoding: quoted-printable Message-Id: <1317558B-24DD-4CB7-BBB6-95E5946EF87A@mnot.net> References: <154886569351.10484.4703007670359734409@ietfa.amsl.com> To: Kathleen Moriarty X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [secdir] Secdir last call review of draft-nottingham-rfc5785bis-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2019 06:52:57 -0000 Cutting down to specific replies -- > On 15 Feb 2019, at 11:20 am, Kathleen Moriarty = wrote: >>=20 >> > 3. Section 3.1 says: >> > The "Well-Known URIs" registry is located at >> > "https://www.iana.org/assignments/well-known-uris/". = Registration >> > requests can be made by following the instructions located there = or >> > by sending an email to the "wellknown-uri-review@ietf.org" = mailing >> > list. >> >=20 >> > I'm not clear on the instructions as I follow the link to the = registry and >> > there's a pointer to the RFC that this document will obsolete. I'm = assuming >> > that the reference will be replaced with this document. Is that = the case or >> > are there additional instructions than what will be included = directly in the >> > registry? If they are repeated (I don't see an IANA request for = that action), >> > that is fine, but I think it's a little confusing to send someone = to that link >> > if they are already reading this document. This document is also = going through >> > a review process to update that registry, so if instructions were = maintained at >> > the registry URL, what would be the review process to alter the = instructions?=20 >> > I'm assuming that this sentence just should be removed, but if not, = I'd like to >> > understand the update process for that registry (instructions for = registering >> > values not adding them). If the sentence should be changed, I = suggest >> > something like: >> >=20 >> > The "Well-Known URIs" registry is located at >> > "https://www.iana.org/assignments/well-known-uris/". = Registration >> > requests can be made by following the instructions in this = document and >> > sending the email to the "wellknown-uri-review@ietf.org" mailing >> > list. >>=20 >> After extensive consultation with IANA regarding RFC8288's revision = of registration policy, the outcome was that this level of detail / = instruction is unnecessary; the text at the top of a registry page can = be tweaked by the Experts by asking IANA, and if they have concerns they = can take it up with the IESG as necessary. >>=20 >> Personally I was a bit surprised by this, but also relieved; getting = this sort of thing *exactly* right in an RFC is difficult, and we need = the flexibility to change things (e.g., we're currently using a Github = issue queue to collect registration requests there, but that might = change in the future). >=20 > What would be helpful here would be some text in the document that = asks IANA to add the instructions to the registry. I'm hoping that more = clearly states my question/request. =20 Based on previous interactions with them, my understanding is that they = do *not* want this level of specificity in the defining documents. Also, = your text priorities the mailing list as the submission mechanism, when = the preferred mechanism is likely to be an issue queue (as we've done = for 8288). >> > 4. Question on Change controller: Is it possible to successfully = make a request >> > through an experimental track RFC or standards track only? If = experimental is >> > allowed, can it only be provisional? >>=20 >> The registry is Specification Required, so an experimental RFC can = indeed make a registry. It can be 'standard' if it meets this bar: = "Other values can also be registered as permanent, if the Experts find = that they are in use, in consultation with the community." >>=20 >>=20 >> I think the text that had me ask this question was the following: >>=20 >> Standards-defined values have a status of "permanent". Other = values >> can also be registered as permanent, if the Experts find that they >> are in use, in consultation with the community. Other values = should=20 >>=20 >> be registered as "provisional". =20 >=20 > By standards-defined, do you mean through specification required in = the IETF? The current text is: """ Values defined by standards-track RFCs and other open standards (in the = sense of {{?RFC206, Section 7.1.1}}) have a status of "permanent". """ >> > 5. Section 3 has the following sentence: >> >=20 >> > General requirements for registered relation types are described = in >> > Section 3. >> >=20 >> > Did the document in a previous revision contain something in = section 3 about >> > registered relation types or am I missing something when reading = section 3 >> > (which is entirely possible)? If it were there (or maybe was in a = previous >> > revision), I'd expect to see it in the following paragraph, but = could see the >> > above text being dropped as an answer to this question as well = (unless I am >> > missing something): >> >=20 >> > It MAY also contain additional information, such as the syntax of >> > additional path components, query strings and/or fragment = identifiers >> > to be appended to the well-known URI, or protocol-specific = details >> > (e.g., HTTP [RFC7231] method handling). >>=20 >> Section 3 puts requirements on choosing a registered name, both = syntactically and with a more general SHOULD about how to choose a good = name. >=20 > OK, can you clarify in the text what you mean by registered relation = type or have that sentence say registered name instead of relation type = since that is the only time registered relation type appears in the = document? I think that would help the reader. Sorry, that was a cut-and-paste error; I've updated to say "registered = values." Cheers and thanks again, -- Mark Nottingham https://www.mnot.net/ From nobody Fri Feb 15 00:43:28 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38DA2130F28; Fri, 15 Feb 2019 00:43:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 KVOVNm-awG4J; Fri, 15 Feb 2019 00:43:18 -0800 (PST) Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [IPv6:2a00:1398:2::10:81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52A6A129A87; Fri, 15 Feb 2019 00:43:18 -0800 (PST) Received: from i72vorta.tm.uni-karlsruhe.de ([141.3.71.26] helo=i72vorta.tm.kit.edu) by iramx2.ira.uni-karlsruhe.de with esmtpsa port 25 iface 141.3.10.8 id 1guZ5W-0005kg-El; Fri, 15 Feb 2019 09:43:14 +0100 Received: from [IPv6:::1] (ip6-localhost [IPv6:::1]) by i72vorta.tm.kit.edu (Postfix) with ESMTPS id 5B5564200F7; Fri, 15 Feb 2019 09:43:14 +0100 (CET) To: Kyle Rose Cc: IETF SecDir , IETF Discussion Mailing List , tsvwg@ietf.org References: <154992443765.29641.355119587706336977@ietfa.amsl.com> <03bfb567-cc86-56fa-6db1-8a42040a6d97@kit.edu> From: "Bless, Roland (TM)" Openpgp: preference=signencrypt Autocrypt: addr=roland.bless@kit.edu; prefer-encrypt=mutual; keydata= xsFNBFi0OxABEACy2VohJ7VhSu/xPCt4/6qCrw4Pw2nSklWPfAYEk1QgrbiwgvLAP9WEhAIU w45cojBaDxytIGg8eaYeIKSmsXjHGbV/ZTfo8r11LX8yPYR0WHiMWZpl0SHUd/CZIkv2pChO 88vF/2FKN95HDcp24pwONF4VhxJoSFk6c0mDNf8Em/Glt9BcWX2AAvizTmpQDshaPje18WH3 4++KwPZDd/sJ/hHSXiPg1Gdhs/OG/C0CJguOAlqbgSVAe3qKOr1M4K5M+wVpsk373pXRfxd7 ZAmZ05iBTn+LfgVcz+AfaKKcsWri5CdTT+7JDL6QNQpox+b5FXZFSHnEIST+/qzfG7G2LqqY mml6TYY8XbaNyXZP0QKncfSpRx8uTRWReHUa1YbSuOxXYh6bXpcugD25mlC/Lu0g7tz4ijiK iIwq9+P2H1KfAAfYyYZh6nOoE6ET0TjOjUSa+mA8cqjPWX99kEEgf1Xo+P9fx9QLCLWIY7zc mSM+vjQKgdUFpMSCKcYEKOuwlPuOz8bVECafxaEtJJHjCOK8zowe2eC9OM+G+bmtAO3qYcYZ hQ/PV3sztt/PjgdtnFAYPFLc9189rHRxKsWSOb4xPkRw/YQAI9l15OlUEpsyOehxmAmTsesn tSViCz++PCdeXrQc1BCgl8nDytrxW+n5w1aaE8aL3hn8M0tonQARAQABzShSb2xhbmQgQmxl c3MgKFRNKSA8cm9sYW5kLmJsZXNzQGtpdC5lZHU+wsGABBMBCAAqAhsDBQkSzAMABQsJCAcC BhUICQoLAgQWAgMBAh4BAheABQJYtYdHAhkBAAoJEKON2tlkOJXuzWkP+wfjUnDNzRm4r34a AMWepcQziTgqf4I1crcL6VD44767HhyFsjcKH31E5G5gTDxbpsM4pmkghKeLrpPo30YK3qb7 E9ifIkpJTvMu0StSUmcXq0zPyHZ+HxHeMWkosljG3g/4YekCqgWwrB62T7NMYq0ATQe1MGCZ TAPwSPGCUZT3ioq50800FMI8okkGTXS3h2U922em7k8rv7E349uydv19YEcS7tI78pggMdap ASoP3QWB03tzPKwjqQqSevy64uKDEa0UgvAM3PRbJxOYZlX1c3q/CdWwpwgUiAhMtPWvavWW Tcw6Kkk6e0gw4oFlDQ+hZooLv5rlYR3egdV4DPZ1ugL51u0wQCQG9qKIMXslAdmKbRDkEcWG Oi2bWAdYyIHhhQF5LSuaaxC2P2vOYRHnE5yv5KTV3V7piFgPFjKDW+giCRd7VGfod6DY2b2y zwidCMve1Qsm8+NErH6U+hMpMLeCJDMu1OOvXYbFnTkqjeg5sKipUoSdgXsIo4kl+oArZlpK qComSTPhij7rMyeu/1iOwbNCjtiqgb55ZE7Ekd84mr9sbq4Jm/4QGnVI30q4U2vdGSeNbVjo d1nqjf3UNzP2ZC+H9xjsCFuKYbCX6Yy4SSuEcubtdmdBqm13pxua4ZqPSI0DQST2CHC7nxL1 AaRGRYYh5zo2vRg3ipkEzsFNBFi0OxABEAC2CJNp0/Ivkv4KOiXxitsMXZeK9fI0NU2JU1rW 04dMLF63JF8AFiJ6qeSL2mPHoMiL+fG5jlxy050xMdpMKxnhDVdMxwPtMiGxbByfvrXu18/M B7h+E1DHYVRdFFPaL2jiw+Bvn6wTT31MiuG9Wh0WAhoW8jY8IXxKQrUn7QUOKsWhzNlvVpOo SjMiW4WXksUA0EQVbmlskS/MnFOgCr8q/FqwC81KPy+VLHPB9K/B65uQdpaw78fjAgQVQqpx H7gUF1EYpdZWyojN+V8HtLJx+9yWAZjSFO593OF3/r0nDHEycuOjhefCrqr0DDgTYUNthOdU KO2CzT7MtweRtAf0n27zbwoYvkTviIbR+1lV1vNkxaUtZ6e1rtOxvonRM1O3ddFIzRp/Qufu HfPe0YqhEsrBIGW1aE/pZW8khNQlB6qt20snL9cFDrnB6+8kDG3e//OjK1ICQj9Y/yyrJVaX KfPbdHhLpsgh8TMDPoH+XXQlDJljMD0++/o7ckO3Sfa8Zsyh1WabyKQDYXDmDgi9lCoaQ7Lf uLUpoMvJV+EWo0jE4RW/wBGQbLJp5usy5i0fhBKuDwsKdLG3qOCf4depIcNuja6ZmZHRT+3R FFjvZ/dAhrCWpRTxZANlWlLZz6htToJulAZQJD6lcpVr7EVgDX/y4cNwKF79egWXPDPOvQAR AQABwsFlBBgBCAAPBQJYtDsQAhsMBQkSzAMAAAoJEKON2tlkOJXukMoP/jNeiglj8fenH2We 7SJuyBp8+5L3n8eNwfwY5C5G+etD0E6/lkt/Jj9UddTazxeB154rVFXRzmcN3+hGCOZgGAyV 1N7d8xM6dBqRtHmRMPu5fUxfSqrM9pmqAw2gmzAe0eztVvaM+x5x5xID2WZOiOq8dx9KOKrp Zorekjs3GEA3V1wlZ7Nksx/o8KZ04hLeKcR1r06zEDLN/yA+Fz8IPa0KqpuhrL010bQDgAhe 9o5TA0/cMJpxpLqHhX2As+5cQAhKDDsWJu3oBzZRkN7Hh/HTpWurmTQRRniLGSeiL0zdtilX fowyxGXH6QWi3MZYmpOq+etr7o4EGGbm2inxpVbM+NYmaJs+MAi/z5bsO/rABwdM5ysm8hwb CGt+1oEMORyMcUk/uRjclgTZM1NhGoXm1Un67+Rehu04i7DA6b8dd1H8AFgZSO2H4IKi+5yA Ldmo+ftCJS83Nf6Wi6hJnKG9aWQjKL+qmZqBEct/D2uRJGWAERU5+D0RwNV/i9lQFCYNjG9X Tew0BPYYnBtHFlz9rJTqGhDu4ubulSkbxAK3TIk8XzKdMvef3tV/7mJCmcaVbJ2YoNUtkdKJ goOigJTMBXMRu4Ibyq1Ei+d90lxhojKKlf9yguzpxk5KYFGUizp0dtvdNuXRBtYrwzykS6vB zTlLqHZ0pvGjNfTSvuuN Organization: Institute of Telematics, Karlsruhe Institute of Technology Message-ID: <117af28e-cd29-fb47-a93f-37147b6df6b0@kit.edu> Date: Fri, 15 Feb 2019 09:43:14 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de) X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de esmtpsa 1550220194.512485740 Archived-At: Subject: Re: [secdir] [tsvwg] Secdir last call review of draft-ietf-tsvwg-le-phb-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2019 08:43:21 -0000 Hi Kyle, see inline, please. Am 14.02.19 um 21:22 schrieb Kyle Rose: >> > and/or behavior. The reason the privacy impact is unremarkable is > that it is > > > highly likely the case that such traffic is already classifiable > as unimportant > > via the sort of traffic analysis that troubles privacy advocates, when > > considering the endpoint, payload length, pacing, etc. > > The LE DSCP marking does not say that this traffic is "unimportant", > it basically classifies the traffic as being of low priority/urgency. > > > Right, "unimportant" is the wrong word. I meant "uninteresting" from the > perspective of an observer interested in learning about the user behind > some traffic (e.g., a state level actor). Software downloads, for > instance, are less likely to be interesting for surveillance purposes > than general web traffic, which is not going to be LE. The net effect of > marking some packets LE is to reduce the chaff/noise from which > wheat/signal can be extracted. Thank you for this explanation, now I got your point! > I think that the statement "However, this disclosed information is only > useful if some form of identification happened at the same time" is > still correct, but probably needs a bit more explanation that this > is often given due to the IP addresses in the packet. Compared to the > plethora of traffic analysis possibilities and general privacy threats > (e.g., see RFC 6973) the impact of disclosed information by the LE DSCP > is likely negligible in most cases. So my suggestion is the following > text: > > "However, this disclosed information is only useful if some form of > identification happened at the same time, which is often given due to > the presence of IP addresses in the packet. Compared to the numerous > traffic analysis possibilities and general privacy threats (e.g., see > [RFC 6973]) the impact of disclosed information by the LE DSCP is likely > negligible in most cases." > > > I think the wording here is a bit awkward, and simultaneity isn't really > the limiting factor. I might start with: > > "However, this disclosed information is useful only if correlation with > metadata (such as the user's IP address) and/or other flows reveal user > identity. ..." My apologies, but I'm not a native speaker, so some phrases may be awkward indeed (I think that the RFC editor will catch the most obvious ones). Thanks for the suggestion. I tried to rephrase that paragraph based on the better understanding of your point (will be in the next draft revision). > I agree that the multicast congestion-induced loss in LE is no worse > than congestion problems with multicast in general, but there is a > subtle difference. the multicast LE replication problem is covered in > section 9. Depending on the implementation replication of LE multicast > packets inside a node may impact other traffic in an undesired way: > the expectation is that LE packets only scavenge otherwise unused > resources. I think that this is covered by the first sentence of the > last paragraph in sec.9: >    While the resource contention problem caused by multicast packet >    replication is also true for other Diffserv PHBs, LE forwarding is >    special, because often it is assumed that LE packets get only >    forwarded in case of available resources at the output ports. > > So what is missing in your point of view for a better understanding? > > > Nothing. I think I'm happy with this explanation. Ok, great. Regards, Roland From nobody Fri Feb 15 03:46:11 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8B8D130DC9; Fri, 15 Feb 2019 03:45:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 v1jlaFp26z5W; Fri, 15 Feb 2019 03:45:50 -0800 (PST) Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D557E1275F3; Fri, 15 Feb 2019 03:45:49 -0800 (PST) Received: by mail-wr1-x42d.google.com with SMTP id f14so10066106wrg.1; Fri, 15 Feb 2019 03:45:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=/cIGvllDmj5nyRT5ZiWR3zAOaKaFvhCR0D5R9octLAo=; b=ejXjGyhefczDbu2NhiQnWHOf9+Ih8DvuYyFuzWhPrmZL5sbvtpxDtSZ/r+RJlSfo2H VlXkOnOAiH13fh7Zf1AwxFTGjQ3iWZ01UU446/5Iw2PotsFTiNGHXKsPMSVbZ4Hvrjm1 fnPTrR7R2p0vUPlLhsji/eUouRKhZ3vKQeQhIqWtAAFfxKvZAs1ClxYNbo4/3kvFvRLV KoNM5oKUOjMCztaggMIXBwR9XOQCYvHGojnqB8fmZKjKNy3Rafyv0gWQK3kogFSM5LwD 7MiRPIabZZPLY4NoH5iHNYuZhMy/5eJ6JwrshM/1Jz9rbn15o70h6B2ZYl1PaEvPqixu Mk2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=/cIGvllDmj5nyRT5ZiWR3zAOaKaFvhCR0D5R9octLAo=; b=hwhR9SIdTHE/a6auh8O4vf7zufA8u4SnJ9Pj5hgT4YK8CsTzDWvLo349BK1sR1YLj8 0EMr4bIlElmO/qJ2y4ywCAy1KBBW3jcbjBvqezRfiJ7hnbY0xJ06T/h4mCgM0wsJtWaK SgSbllQTJd84GVc/RBaeS5XJpxAJ/jDnL/4aYnCaeOqlCBA/y+dWNkbt8Cajv5F8T3Gh GJR0qNzWJ+KGM+me0g3b2nH5HIdF64YMwJdVp43kJI6uv0k5Z9AxDZWkmjsUXvGWDWXN pY1CfvblvlSKhu43xQ2Ouza2NeOUJzUrRazj/okIpp2apyZEHH44KGL8GEk+WUdxIy4z //uw== X-Gm-Message-State: AHQUAuZIy+n/wY2WbfYqaBisTNxX1iWudmkHKPVb7Di1hErzlXR4sNYt r8kW3q4JdhcA/VsCg56sg76cYcRw X-Google-Smtp-Source: AHgI3IYhdC+gZTwHcd9obiejt2Un6F+Z6K3s88EyNC4QOXcDKpLL1g55Rd+fV9DU2Gog0zJUs1DvxQ== X-Received: by 2002:adf:f691:: with SMTP id v17mr6784685wrp.66.1550231147802; Fri, 15 Feb 2019 03:45:47 -0800 (PST) Received: from [192.168.178.22] ([62.3.64.16]) by smtp.gmail.com with ESMTPSA id h9sm3357314wrv.11.2019.02.15.03.45.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 15 Feb 2019 03:45:46 -0800 (PST) To: Zaheduzzaman Sarker , "gen-art@ietf.org" Cc: "rmcat@ietf.org" , "ietf@ietf.org" , "draft-ietf-rmcat-eval-test.all@ietf.org" , "secdir@ietf.org" References: <154930852182.28785.5364082865560557648@ietfa.amsl.com> <104FE636-0A18-4E3B-B7BD-F2DA3748161B@ericsson.com> From: Stewart Bryant Message-ID: <04aace0d-805a-406a-b44b-ffdb44a4e9df@gmail.com> Date: Fri, 15 Feb 2019 11:45:45 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.0 MIME-Version: 1.0 In-Reply-To: <104FE636-0A18-4E3B-B7BD-F2DA3748161B@ericsson.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB Archived-At: Subject: Re: [secdir] Genart last call review of draft-ietf-rmcat-eval-test-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2019 11:45:53 -0000 Hi Zahed The work that made me particularly conscious of the security issue in this draft was RFC6815, and although RFC6815 applies to RFC2544, I would imagine that the same considerations apply here. Perhaps a reference to RFC6815 would help the reader of this draft better appreciate the danger of running these tests outside the lab. I note that a statement on the need to run these tests in a controlled environment was not added to the Abstract, something which might be useful in highlighting the danger to someone supervising a lab, but not involved in the detail. It is really for the security directorate to decide their position, but I would have thought that it was better to emphasis (with RFC2119 language) the real danger to production networks (of all flavours, not just the Internet) of this test traffic leaking and causing disruption. I will leave this issue with the security reviewer from here on and take a look at the other text changes. - Stewart On 07/02/2019 13:27, Zaheduzzaman Sarker wrote: > Hi Stewart, > > Thanks for a good review. > > For the security consideration section, we can use stronger words if that is required. This document merely specifies test cases when people are testing their algorithm in a controlled environment and does not specify protocol usage. I was wondering if using normative language is an overkill here. For those reasons we are actually thinking of taking out 2119 usage completely. I have a modified text proposal below. > > Please see inline below for more. > > BR > Zahed > > > On 2019-02-04, 20:29, "Stewart Bryant" wrote: > > Reviewer: Stewart Bryant > Review result: Almost Ready > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. > > For more information, please see the FAQ at > > . > > Document: draft-ietf-rmcat-eval-test-08 > Reviewer: Stewart Bryant > Review Date: 2019-02-04 > IETF LC End Date: 2019-02-11 > IESG Telechat date: Not scheduled for a telechat > > Summary: > > A well written documents an close to being ready for publication. > > I am concerned that the Security section is weak on use outside a > controlled environment. > > There are a fair number of minor issues and nits that need attention, > but most of them are simple to fix. > > One concern that I have that I doubt is readily fixable is that long > multi-nested lists do not work well in paginated ASCII with line spaces > and sometimes it is difficult to be sure of the context of a test element note. > > [ZS] I share the concern here, but I don’t think I have a better alternative now. > > Major issues: > > 8. Security Considerations > > The security considerations in [I-D.ietf-rmcat-eval-criteria] and the > relevant congestion control algorithms apply. The principles for > congestion control are described in [RFC2914], and in particular any > new method MUST implement safeguards to avoid congestion collapse of > the Internet. > > The evaluation of the test cases are intended to be run in a > controlled lab environment. > > SB> I wonder if there shouldn't me a MUST in that sentence? > SB> There have been issues on SP networks with users running unsuitable > SB> performance benchmarks on live networks, including complaints to the > SB> operators concerning the results achieved. > > Hence, the applications, simulators and > network nodes ought to be well-behaved and should not impact the > desired results. It is important to take appropriate caution to > avoid leaking non-responsive traffic from unproven congestion > avoidance techniques onto the open Internet. > > SB> Again I am surprised this is not much stronger in prohibiting > SB> use on the Internet. > > [ZS] what about : > > " The evaluation of the test cases are intended to be run in a > controlled lab environment. Hence, the applications, simulators and > network nodes must be well-behaved and should not impact the > desired results. Moreover, proper measures must be taken to > avoid leaking non-responsive traffic from unproven congestion > avoidance techniques onto the open Internet. " > > ======== > > Minor issues: > > This memo describes a set of test cases for evaluating congestion > control algorithm proposals for real-time interactive media. > > SB> It would be useful to add here the statement in the abstract that > SB> these tests should be done in a controlled environment. > [ZS] The abstract mentions the this "This document describes > the test cases to be used in the performance evaluation of such > congestion control algorithms in a controlled environment." > > We can repeat that in the intro as well. > > =========== > > Expected behavior: depending on the convergence observed in test case > 5.1 and 5.2, the candidate algorithm may be able to avoid congestion > collapse. In the worst case, the media stream will fall to the > minimum media bit rate. > > SB> Do you need to specify the variant of TCP? You do state it later, but some > comment here would be useful. > > [ZS] Not sure what would be useful to describe here more, the expected behaviour is not really coupled to what TCP congestion control is used, the general demand is to avoid congestion collapse here. > > SB> What behaviour do you expect the TCP to show. > It would be bad if SB> an aggressive media application kill the TCP completely. > > [ZS] I don’t think we should say anything about TCP behaviour here. The idea is to test the new congestion control behaviour with available TCP behaviours not vice versa. But TCP can certainly improve its performance from the test results (. > > ============ > the first flow > (S1) MUST arrive at a steady-state rate approximately twice of that > of the other two flows (S2 and S3). > > SB> I am not sure what you mean by priority I assume that you mean > SB> QoS ranking in the routing system. In which case I don't see > SB> how you can expect the result you specify. > > [ZS] no this is not about routing priority on the network nodes, this is at the media sender. When a media sender has multiple flows that shares the same bottleneck then the media sender can use techniques to distribute the available bandwidth to the multiple flows that it is sending. The point here is the media flows should get their share of the available bandwidth as per the priority set by the application. > > ============ > > Expected behavior: the candidate algorithm is expected to achieve > full utilization at both bottleneck links without starving any of the > three congestion controlled media flows. > > SB> I am not sure what you mean by this. Do you mean that the bottlenecks > SB> will saturate, but make no comment about how much of the bottleneck > SB> capacity each flow gets for itself? > > [ZS] bottlenecks will saturate -- yes. The success criteria --- the existence of multiple bottleneck should not result in flow starvation to any flows that is sharing those bottlenecks. Yes, there is no comment on fairness here explicitly. Not sure we need one here, do we? > > ============ > > Nits/editorial comments: > [ZS] thanks for those nits. will take care of them. > > Checking nits according to https://www.ietf.org/id-info/checklist : > ---------------------------------------------------------------------------- > > ** There are 9 instances of too long lines in the document, the longest one > being 4 characters in excess of 72. > > == Outdated reference: A later version (-06) exists of > draft-ietf-rmcat-wireless-tests-05 > > =========== > > 3. Structure of Test cases > > SB> In the text below it was sometimes hard to get the context right in the > SB> triple (or more) nested list. Please consider using subsections or some > other SB> demarcation. > > =========== > > + Bottleneck queue type: for example, Droptail, FQ-CoDel, or > PIE. > > SB> There need references, and by convention expansion on first use. > > ========== > > + Path loss ratio: characterizes the non-congested, additive, > losses to be generated on the end-to-end path. MUST > SB> s/MUST/This MUST/ ? > > ========== > > B. Variation in sending bit rate and goodput. Mainly observing > the frequency and magnitude of oscillations. > > SB> goodput needs a reference or a definition. I don't think it is a > universally known term. > > =========== > > Expected behavior: the candidate algorithm is expected to detect the > path capacity constraint, converges to the bottleneck link's capacity > SB> s/converges/converge/ > > =========== > > Due to asymmetric nature of the link > > SB> s/Due to/Due to the/ > > =========== > > SB> Is there a diagram error in the figure above? > > Figure 6: Testbed Topology for TCP vs congestion controlled media > Flows > > =========== > > have the same bandwidth share on the link. It has to make it's way > SB>s/it's/its/ > > =========== > > The candidate algorithm MUST reflect the relative priorities > assigned to each media flow. In the previous example, > SB> An explicit reference to the test would help the reader > > ========== > > > > From nobody Fri Feb 15 04:10:39 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F2ABC130FB2; Fri, 15 Feb 2019 03:51:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1550231507; bh=7g3zIbezJZc7qgGXZqdK8CUO9lEAyWKvGFFtQ3TlXiY=; h=To:From:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=iAf7JcKGyXA1ZSpXMhk2x4Mx3macWZw0kMlmoVgtQ4nmWPFKtWy4hqp4wKUB4YKWJ OEf5pj5yVVAehNz+VOgqX2xcnAHOyXMRgjNy79y1xg0X/minj3pSGcBtK93j3qC64M u77W3u2213XF/3q6yTf+2oF0kwhVyKm3aL9V7xv0= X-Mailbox-Line: From new-work-bounces@ietf.org Fri Feb 15 03:51:41 2019 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 11A40130FAF; Fri, 15 Feb 2019 03:51:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1550231493; bh=7g3zIbezJZc7qgGXZqdK8CUO9lEAyWKvGFFtQ3TlXiY=; h=To:From:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=cFo5W9NBd8p9RtlZCGg3heUG5nig9nhKVFd+39PhyoWRb3wKy7RzxUaFAiLvL9auk vDuJQ7uru86dSS3fQiHhUk+JNNG8NUOENXXb3THDQ98gBS+eNvyOOalLzE1BIOBgyn Tekxej2CMbOuAr4ysW0N5skagvWW1xsXtMiHMa6g= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9D6E130FCB for ; Fri, 15 Feb 2019 03:51:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 9D9hvrPLwQgu for ; Fri, 15 Feb 2019 03:51:24 -0800 (PST) Received: from raoul.w3.org (raoul.w3.org [128.30.52.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3592D130F82 for ; Fri, 15 Feb 2019 03:51:24 -0800 (PST) Received: from [42.100.7.11] (helo=[192.168.1.3]) by raoul.w3.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from ) id 1guc1Z-0008Cy-RS for new-work@ietf.org; Fri, 15 Feb 2019 11:51:23 +0000 To: new-work@ietf.org From: xueyuan Message-ID: Date: Fri, 15 Feb 2019 19:51:17 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.5.0 MIME-Version: 1.0 Content-Language: en-US Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.29 Precedence: list Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Fri, 15 Feb 2019 04:10:38 -0800 Subject: [secdir] [new-work] Proposed W3C Charter: Web Application Security Working Group (until 2019-03-15) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2019 11:51:48 -0000 CkhlbGxvLAoKVG9kYXkgVzNDIEFkdmlzb3J5IENvbW1pdHRlZSBSZXByZXNlbnRhdGl2ZXMgcmVj ZWl2ZWQgYSBQcm9wb3NhbAp0byByZXZpZXcgYSBkcmFmdCBjaGFydGVyIGZvciB0aGUgV2ViIEFw cGxpY2F0aW9uIFNlY3VyaXR5IFdvcmtpbmcgR3JvdXA6CiDCoCBodHRwczovL3d3dy53My5vcmcv MjAxOS8wMi93ZWJhcHBzZWMtMjAxOS1wcm9wb3NlZC1jaGFydGVyLmh0bWwKCkFzIHBhcnQgb2Yg ZW5zdXJpbmcgdGhhdCB0aGUgY29tbXVuaXR5IGlzIGF3YXJlIG9mIHByb3Bvc2VkIHdvcmsKYXQg VzNDLCB0aGlzIGRyYWZ0IGNoYXJ0ZXIgaXMgcHVibGljIGR1cmluZyB0aGUgQWR2aXNvcnkKQ29t bWl0dGVlIHJldmlldyBwZXJpb2QuCgpXM0MgaW52aXRlcyBwdWJsaWMgY29tbWVudHMgdGhyb3Vn aCAyMDE5LTAzLTE1IG9uIHRoZQpwcm9wb3NlZCBjaGFydGVyLiBQbGVhc2Ugc2VuZCBjb21tZW50 cyB0bwpwdWJsaWMtbmV3LXdvcmtAdzMub3JnLCB3aGljaCBoYXMgYSBwdWJsaWMgYXJjaGl2ZToK IMKgIGh0dHA6Ly9saXN0cy53My5vcmcvQXJjaGl2ZXMvUHVibGljL3B1YmxpYy1uZXctd29yay8K Ck90aGVyIHRoYW4gY29tbWVudHMgc2VudCBpbiBmb3JtYWwgcmVzcG9uc2VzIGJ5IFczQyBBZHZp c29yeQpDb21taXR0ZWUgUmVwcmVzZW50YXRpdmVzLCBXM0MgY2Fubm90IGd1YXJhbnRlZSBhIHJl c3BvbnNlIHRvCmNvbW1lbnRzLiBJZiB5b3Ugd29yayBmb3IgYSBXM0MgTWVtYmVyIFsxXSwgcGxl YXNlIGNvb3JkaW5hdGUKeW91ciBjb21tZW50cyB3aXRoIHlvdXIgQWR2aXNvcnkgQ29tbWl0dGVl IFJlcHJlc2VudGF0aXZlLiBGb3IKZXhhbXBsZSwgeW91IG1heSB3aXNoIHRvIG1ha2UgcHVibGlj IGNvbW1lbnRzIHZpYSB0aGlzIGxpc3QgYW5kCmhhdmUgeW91ciBBZHZpc29yeSBDb21taXR0ZWUg UmVwcmVzZW50YXRpdmUgcmVmZXIgdG8gaXQgZnJvbSBoaXMKb3IgaGVyIGZvcm1hbCByZXZpZXcg Y29tbWVudHMuCgpJZiB5b3Ugc2hvdWxkIGhhdmUgYW55IHF1ZXN0aW9ucyBvciBuZWVkIGZ1cnRo ZXIgaW5mb3JtYXRpb24sIHBsZWFzZQpjb250YWN0IFdlbmR5IFNlbHR6ZXIgPHdzZWx0emVyQHcz Lm9yZz4sIFNhbXVlbCBXZWlsZXIgPHdlaWxlckB3My5vcmc+LApXZWIgQXBwbGljYXRpb24gU2Vj dXJpdHkgV29ya2luZyBHcm91cCBTdGFmZiBDb250YWN0cy4KClRoYW5rIHlvdSwKWHVleXVhbiBK aWEsIFczQyBNYXJrZXRpbmcgJiBDb21tdW5pY2F0aW9ucwoKWzFdIGh0dHA6Ly93d3cudzMub3Jn L0NvbnNvcnRpdW0vTWVtYmVyL0xpc3QKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fCm5ldy13b3JrIG1haWxpbmcgbGlzdApuZXctd29ya0BpZXRmLm9yZwpo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldy13b3JrCg== From nobody Fri Feb 15 05:26:27 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A28612D4E6 for ; Fri, 15 Feb 2019 05:26:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.org 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 so1RcmudFsBn for ; Fri, 15 Feb 2019 05:26:13 -0800 (PST) Received: from mail-yw1-xc31.google.com (mail-yw1-xc31.google.com [IPv6:2607:f8b0:4864:20::c31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB262130FBA for ; Fri, 15 Feb 2019 05:26:09 -0800 (PST) Received: by mail-yw1-xc31.google.com with SMTP id d190so3663395ywd.12 for ; Fri, 15 Feb 2019 05:26:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2ypBK/W9ZfqBarDr/2JX3cZTo7Im+f+aGNN3ExIcIYU=; b=q1NWsSNDUGhJdTJsSz2XlcZ6289o5lNbbJ33zN7vffGhSoLnQ4wXy62fle0kJ37FQT +UTBFXYOu7HiWOQoJOvOqMuLBUp8tJh4Zk0OJaLQNGPgEl/JsnVrVpI4G6pPdTDv20JD V3bta29NwxW+jCN7hI13rOPBlV4vzvSRIGvkA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2ypBK/W9ZfqBarDr/2JX3cZTo7Im+f+aGNN3ExIcIYU=; b=qRuH1fhrkrNnv3Iopfsxf2DQTc9KkPVVATpxyFN8pmA3oTr3VzonuYZFuqhqa3VMXs 5cuXeLm4nqt9/sE5m9F4RodlowwQYh7SUZNuCzHjBs9BcitpqK39sIJTbxdGst1aCQub WQa3ATngS7JyKFQD7GxAFu741N2ycgWyG/X+fJs25KVyc4/TRiJtY5darDGy1x8nmpVP QD3z8oFxIrijOLCJ44MejMD5GQvtUQ6KT1uKh2fZ4ql0lxiCaGf1sFhmTfQOoLcd/TWB U9WetWPfvWakChGxKdHwWlLTqC7Z8lvOI9JTOqLAG2yHPN3YjX7gz7UAVTKje0LR+TW6 98eA== X-Gm-Message-State: AHQUAuazdmIVAWkPKqpxVJfcr+EBwq5pmIDPAvvRp3vMlsKIKSzMbZSP OclP38lZ3BjgL0Y0KnTq+Ut3+8r3xD0aFZhoCSf6FA== X-Google-Smtp-Source: AHgI3IYGP8IiAC5BYml4+1gZw7tQvjV/qj7ILAypZi2W4nBUMFHzsTVO21jLossn3RlHq6StK3O8XOYnLOV2+7mpYhQ= X-Received: by 2002:a81:d008:: with SMTP id v8mr7782650ywi.464.1550237168567; Fri, 15 Feb 2019 05:26:08 -0800 (PST) MIME-Version: 1.0 References: <154992443765.29641.355119587706336977@ietfa.amsl.com> <03bfb567-cc86-56fa-6db1-8a42040a6d97@kit.edu> <117af28e-cd29-fb47-a93f-37147b6df6b0@kit.edu> In-Reply-To: <117af28e-cd29-fb47-a93f-37147b6df6b0@kit.edu> From: Kyle Rose Date: Fri, 15 Feb 2019 08:25:57 -0500 Message-ID: To: "Bless, Roland (TM)" Cc: IETF SecDir , IETF Discussion Mailing List , tsvwg@ietf.org Content-Type: multipart/alternative; boundary="000000000000c02a020581eeb79e" Archived-At: Subject: Re: [secdir] [tsvwg] Secdir last call review of draft-ietf-tsvwg-le-phb-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2019 13:26:15 -0000 --000000000000c02a020581eeb79e Content-Type: text/plain; charset="UTF-8" The wording in draft 9 looks great. Thanks! Kyle On Fri, Feb 15, 2019 at 3:43 AM Bless, Roland (TM) wrote: > Hi Kyle, > > see inline, please. > > Am 14.02.19 um 21:22 schrieb Kyle Rose: > >> > and/or behavior. The reason the privacy impact is unremarkable is > > that it is > > > > > highly likely the case that such traffic is already classifiable > > as unimportant > > > via the sort of traffic analysis that troubles privacy advocates, > when > > > considering the endpoint, payload length, pacing, etc. > > > > The LE DSCP marking does not say that this traffic is "unimportant", > > it basically classifies the traffic as being of low priority/urgency. > > > > > > Right, "unimportant" is the wrong word. I meant "uninteresting" from the > > perspective of an observer interested in learning about the user behind > > some traffic (e.g., a state level actor). Software downloads, for > > instance, are less likely to be interesting for surveillance purposes > > than general web traffic, which is not going to be LE. The net effect of > > marking some packets LE is to reduce the chaff/noise from which > > wheat/signal can be extracted. > > Thank you for this explanation, now I got your point! > > > I think that the statement "However, this disclosed information is > only > > useful if some form of identification happened at the same time" is > > still correct, but probably needs a bit more explanation that this > > is often given due to the IP addresses in the packet. Compared to the > > plethora of traffic analysis possibilities and general privacy > threats > > (e.g., see RFC 6973) the impact of disclosed information by the LE > DSCP > > is likely negligible in most cases. So my suggestion is the following > > text: > > > > "However, this disclosed information is only useful if some form of > > identification happened at the same time, which is often given due to > > the presence of IP addresses in the packet. Compared to the numerous > > traffic analysis possibilities and general privacy threats (e.g., see > > [RFC 6973]) the impact of disclosed information by the LE DSCP is > likely > > negligible in most cases." > > > > > > I think the wording here is a bit awkward, and simultaneity isn't really > > the limiting factor. I might start with: > > > > "However, this disclosed information is useful only if correlation with > > metadata (such as the user's IP address) and/or other flows reveal user > > identity. ..." > > My apologies, but I'm not a native speaker, so some phrases may be > awkward indeed (I think that the RFC editor will catch the most > obvious ones). Thanks for the suggestion. I tried to rephrase > that paragraph based on the better understanding of your point > (will be in the next draft revision). > > > I agree that the multicast congestion-induced loss in LE is no worse > > than congestion problems with multicast in general, but there is a > > subtle difference. the multicast LE replication problem is covered in > > section 9. Depending on the implementation replication of LE > multicast > > packets inside a node may impact other traffic in an undesired way: > > the expectation is that LE packets only scavenge otherwise unused > > resources. I think that this is covered by the first sentence of the > > last paragraph in sec.9: > > While the resource contention problem caused by multicast packet > > replication is also true for other Diffserv PHBs, LE forwarding is > > special, because often it is assumed that LE packets get only > > forwarded in case of available resources at the output ports. > > > > So what is missing in your point of view for a better understanding? > > > > > > Nothing. I think I'm happy with this explanation. > > Ok, great. > > Regards, > Roland > --000000000000c02a020581eeb79e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The wording in draft 9 looks great. Thanks!

Kyle

On Fri, Feb 15, 2019 at 3:43 AM Bless, Roland= (TM) <roland.bless@kit.edu&= gt; wrote:
Hi Ky= le,

see inline, please.

Am 14.02.19 um 21:22 schrieb Kyle Rose:
>> > and/or behavior. The reason the privacy impact is unremarkabl= e is
> that it is
>
>=C2=A0 =C2=A0 =C2=A0> highly likely the case that such traffic is al= ready classifiable
>=C2=A0 =C2=A0 =C2=A0as unimportant
>=C2=A0 =C2=A0 =C2=A0> via the sort of traffic analysis that troubles= privacy advocates, when
>=C2=A0 =C2=A0 =C2=A0> considering the endpoint, payload length, paci= ng, etc.
>
>=C2=A0 =C2=A0 =C2=A0The LE DSCP marking does not say that this traffic = is "unimportant",
>=C2=A0 =C2=A0 =C2=A0it basically classifies the traffic as being of low= priority/urgency.
>
>
> Right, "unimportant" is the wrong word. I meant "uninte= resting" from the
> perspective of an observer interested in learning about the user behin= d
> some traffic (e.g., a state level actor). Software downloads, for
> instance, are less likely to be interesting for surveillance purposes<= br> > than general web traffic, which is not going to be LE. The net effect = of
> marking some packets LE is to reduce the chaff/noise from which
> wheat/signal can be extracted.

Thank you for this explanation, now I got your point!

>=C2=A0 =C2=A0 =C2=A0I think that the statement "However, this disc= losed information is only
>=C2=A0 =C2=A0 =C2=A0useful if some form of identification happened at t= he same time" is
>=C2=A0 =C2=A0 =C2=A0still correct, but probably needs a bit more explan= ation that this
>=C2=A0 =C2=A0 =C2=A0is often given due to the IP addresses in the packe= t. Compared to the
>=C2=A0 =C2=A0 =C2=A0plethora of traffic analysis possibilities and gene= ral privacy threats
>=C2=A0 =C2=A0 =C2=A0(e.g., see RFC 6973) the impact of disclosed inform= ation by the LE DSCP
>=C2=A0 =C2=A0 =C2=A0is likely negligible in most cases. So my suggestio= n is the following
>=C2=A0 =C2=A0 =C2=A0text:
>
>=C2=A0 =C2=A0 =C2=A0"However, this disclosed information is only u= seful if some form of
>=C2=A0 =C2=A0 =C2=A0identification happened at the same time, which is = often given due to
>=C2=A0 =C2=A0 =C2=A0the presence of IP addresses in the packet. Compare= d to the numerous
>=C2=A0 =C2=A0 =C2=A0traffic analysis possibilities and general privacy = threats (e.g., see
>=C2=A0 =C2=A0 =C2=A0[RFC 6973]) the impact of disclosed information by = the LE DSCP is likely
>=C2=A0 =C2=A0 =C2=A0negligible in most cases."
>
>
> I think the wording here is a bit awkward, and simultaneity isn't = really
> the limiting factor. I might start with:
>
> "However, this disclosed information is useful only if correlatio= n with
> metadata (such as the user's IP address) and/or other flows reveal= user
> identity. ..."

My apologies, but I'm not a native speaker, so some phrases may be
awkward indeed (I think that the RFC editor will catch the most
obvious ones). Thanks for the suggestion. I tried to rephrase
that paragraph based on the better understanding of your point
(will be in the next draft revision).

>=C2=A0 =C2=A0 =C2=A0I agree that the multicast congestion-induced loss = in LE is no worse
>=C2=A0 =C2=A0 =C2=A0than congestion problems with multicast in general,= but there is a
>=C2=A0 =C2=A0 =C2=A0subtle difference. the multicast LE replication pro= blem is covered in
>=C2=A0 =C2=A0 =C2=A0section 9. Depending on the implementation replicat= ion of LE multicast
>=C2=A0 =C2=A0 =C2=A0packets inside a node may impact other traffic in a= n undesired way:
>=C2=A0 =C2=A0 =C2=A0the expectation is that LE packets only scavenge ot= herwise unused
>=C2=A0 =C2=A0 =C2=A0resources. I think that this is covered by the firs= t sentence of the
>=C2=A0 =C2=A0 =C2=A0last paragraph in sec.9:
>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0While the resource contention problem = caused by multicast packet
>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0replication is also true for other Dif= fserv PHBs, LE forwarding is
>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0special, because often it is assumed t= hat LE packets get only
>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0forwarded in case of available resourc= es at the output ports.
>
>=C2=A0 =C2=A0 =C2=A0So what is missing in your point of view for a bett= er understanding?
>
>
> Nothing. I think I'm happy with this explanation.

Ok, great.

Regards,
=C2=A0Roland
--000000000000c02a020581eeb79e-- From nobody Fri Feb 15 06:59:55 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5F58130EB3; Fri, 15 Feb 2019 06:59:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.881 X-Spam-Level: X-Spam-Status: No, score=-1.881 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.018, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 9594e4gm0mSb; Fri, 15 Feb 2019 06:59:51 -0800 (PST) Received: from mail-it1-f177.google.com (mail-it1-f177.google.com [209.85.166.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF5DA12D84D; Fri, 15 Feb 2019 06:59:51 -0800 (PST) Received: by mail-it1-f177.google.com with SMTP id f10so1174235ita.4; Fri, 15 Feb 2019 06:59:51 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=psre8j4LLC67/sRvO2nFTITDHxUfQeD3oewda2tCaKA=; b=EBGzf4MnBhCt8txfPLQ2pKbmgCEYNjqzKMFN1psjV7Y5HHu1fl26lPwQvTpYjoqrD2 QQsB86ohJ1kHh1JoFn9W0cAQIsov+SjdoFmMvnypV3G5PsKGsaUDJNRPklxSv7azpeNl Xl8OhhRptrxYn0YdMvbQEVFfAOKtwYoJnqqi8D4inqBrflRro7R2dj18Ib+wc4fif9BZ G1mP6A6rQ9chU63rJsGoTBAtsMUwKufXTzHNeWdVG2xoPIpA9LAbqtMoz7dkpGGfP3cI FmXhBuy43XTv72mJhYDHuDZpY8vWUyAgwKTRYFRDzrahw6Q9o+FP8P8Q8H820fs3mYWK 3CFQ== X-Gm-Message-State: AHQUAuZh6hBI5RBKbMdggOTdrReYj6gzWu2S9TRH1iSS0vUiODRjMyJw dQjsLPR02zPvxuyUxIDAfq+zb+hCr7PFGuDOK60= X-Google-Smtp-Source: AHgI3IZi/He4uZDHuU8bzzSipYfEUNdMgLjeHwo2K+6qOscKfNQ9loMBNEYXT/EoSg0/bVgwAsnsyKRx+ADUgVaYRpM= X-Received: by 2002:a24:dd8d:: with SMTP id t135mr4767617itf.84.1550242790514; Fri, 15 Feb 2019 06:59:50 -0800 (PST) MIME-Version: 1.0 References: <154886569351.10484.4703007670359734409@ietfa.amsl.com> <1317558B-24DD-4CB7-BBB6-95E5946EF87A@mnot.net> In-Reply-To: <1317558B-24DD-4CB7-BBB6-95E5946EF87A@mnot.net> From: Barry Leiba Date: Fri, 15 Feb 2019 09:59:38 -0500 Message-ID: To: Mark Nottingham Cc: IETF , IETF SecDir , Kathleen Moriarty , draft-nottingham-rfc5785bis.all@ietf.org Content-Type: multipart/alternative; boundary="000000000000d824560581f00686" Archived-At: Subject: Re: [secdir] Secdir last call review of draft-nottingham-rfc5785bis-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2019 14:59:54 -0000 --000000000000d824560581f00686 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > > > > What would be helpful here would be some text in the document that asks > IANA to add the instructions to the registry. I'm hoping that more clear= ly > states my question/request. > > Based on previous interactions with them, my understanding is that they d= o > *not* want this level of specificity in the defining documents. Also, you= r > text priorities the mailing list as the submission mechanism, when the > preferred mechanism is likely to be an issue queue (as we've done for 828= 8). What I think Kathleen is asking isn=E2=80=99t to have the document specify = the registration details, but to make sure the registry header does. The document says to use the instructions in the registry, but there are no instructions in the registry. Either the document has to bootstrap that by giving an initial set of instruction to put there, or the registry has to have registration instructions that we can sanity-check now. It doesn=E2= =80=99t. If the document says to see the registry for registration instructions, there had better be instructions there, no? Barry > --000000000000d824560581f00686 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

> What would be helpful here would be some text in the document that ask= s IANA to add the instructions to the registry.=C2=A0 I'm hoping that m= ore clearly states my question/request.=C2=A0

Based on previous interactions with them, my understanding is that they do = *not* want this level of specificity in the defining documents. Also, your = text priorities the mailing list as the submission mechanism, when the pref= erred mechanism is likely to be an issue queue (as we've done for 8288)= .

What I think Ka= thleen is asking isn=E2=80=99t to have the document specify the registratio= n details, but to make sure the registry header does.=C2=A0 The document sa= ys to use the instructions in the registry, but there are no instructions i= n the registry.=C2=A0 Either the document has to bootstrap that by giving a= n initial set of instruction to put there, or the registry has to have regi= stration instructions that we can sanity-check now.=C2=A0 It doesn=E2=80=99= t.

If the document says = to see the registry for registration instructions, there had better be inst= ructions there, no?

Barr= y
--000000000000d824560581f00686-- From nobody Fri Feb 15 15:40:13 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91DD4131205 for ; Fri, 15 Feb 2019 15:40:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.29 X-Spam-Level: X-Spam-Status: No, score=-4.29 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=SeoBBtGJ; dkim=pass (1024-bit key) header.d=ericsson.com header.b=Yrav6J4D 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 h2uUqcLAHbp5 for ; Fri, 15 Feb 2019 15:39:55 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F079131151 for ; Fri, 15 Feb 2019 15:39:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1550273984; x=1552865984; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=jg9Wew5jJ/Roiey28kQHDKc2IqSNOJXo2LSVIScGgk8=; b=SeoBBtGJGXvsW5CnCJ8FTh+Vgl4ruFxhhc6mIrtKmA8rcp4n5cywJM45Y/ir6IN6 PhFZSopQPSzs72k3vU8frnMwE2KDuZGrKzF5KVatLNhDjy2IUG72/GaY/f0FGlMU oF8XIQXwJFv35DouO3RKCxXkhkAodu/BYN8bBsIamWg=; X-AuditID: c1b4fb25-da1ff70000005ff7-91-5c674dc04c45 Received: from ESESSMB505.ericsson.se (Unknown_Domain [153.88.183.123]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id BF.D1.24567.0CD476C5; Sat, 16 Feb 2019 00:39:44 +0100 (CET) Received: from ESESSMR503.ericsson.se (153.88.183.112) by ESESSMB505.ericsson.se (153.88.183.166) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Sat, 16 Feb 2019 00:39:43 +0100 Received: from ESESSMB505.ericsson.se (153.88.183.166) by ESESSMR503.ericsson.se (153.88.183.112) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Sat, 16 Feb 2019 00:39:42 +0100 Received: from NAM02-CY1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB505.ericsson.se (153.88.183.166) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Sat, 16 Feb 2019 00:39:42 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jg9Wew5jJ/Roiey28kQHDKc2IqSNOJXo2LSVIScGgk8=; b=Yrav6J4DDc9hT+70mJ3KH8fofIWi1QdGvbw2QR4HwLoExmlhvcd4GXtD285Y7gc5dVsLi9ylyXi6BtejV7YHEDiDnahCdTp28/WjdMp+yI/a5DgO93AtWHYNjkflxGc2za3OeRF7YTxpakX82nfH3VAGsPo+TRMolzcJDFHEbnY= Received: from BN8PR15MB3090.namprd15.prod.outlook.com (20.178.221.213) by BN8PR15MB3489.namprd15.prod.outlook.com (20.179.76.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1622.16; Fri, 15 Feb 2019 23:39:38 +0000 Received: from BN8PR15MB3090.namprd15.prod.outlook.com ([fe80::592:2ca9:ed41:b420]) by BN8PR15MB3090.namprd15.prod.outlook.com ([fe80::592:2ca9:ed41:b420%4]) with mapi id 15.20.1622.018; Fri, 15 Feb 2019 23:39:38 +0000 From: Daniel Migault To: "Moses, Danny" , "secdir@ietf.org" CC: "draft-ietf-dmm-ondemand-mobility.all@ietf.org" , "ietf@ietf.org" , "dmm@ietf.org" , "mglt.ietf@gmail.com" Thread-Topic: [DMM] Secdir last call review of draft-ietf-dmm-ondemand-mobility-15 Thread-Index: AQHUrqDqIVG+1Oi8y0SXiju3hVFS06XhhbHA Date: Fri, 15 Feb 2019 23:39:37 +0000 Message-ID: References: <154760741387.10854.10303591799017138670@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=daniel.migault@ericsson.com; x-originating-ip: [70.80.131.240] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d0c4e309-bca3-42b8-3ff0-08d6939ed964 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605077)(2017052603328)(7153060)(7193020); SRVR:BN8PR15MB3489; x-ms-traffictypediagnostic: BN8PR15MB3489: x-ms-exchange-purlcount: 12 x-microsoft-exchange-diagnostics: =?utf-8?B?MTtCTjhQUjE1TUIzNDg5OzIzOi9PejhVS09OWDNpMG9kK3YxZ0k2elB2b0lN?= =?utf-8?B?NnZVbUhMWnZvS2NaZlZFUWhTZ2UrdHBtWVlMcHVwRllkcm54R0xibDlKNWhv?= =?utf-8?B?eDN1bUo0MUhUNXgvdUcyYVR2YjJEdVZOTXBzMklrTUFEeS9HM3BQZWwxc3o4?= =?utf-8?B?cnNNRm1MazlvdDlwQW5XRjVTS0hEMy80UUNQVW5DSU5XbklLOXVEYWNmYXNO?= =?utf-8?B?a01zelBiZDQ1UTV3LzVuZGlIUUtZT1dEdEJIeUhkeXgvbHArMVFIRlRCMHpi?= =?utf-8?B?MzZOd21HYUNFNHBZazhleGZGUmpXRWk0K3dxNWZLUUF4K3dKeVNTOC93S0Nj?= =?utf-8?B?ZmFMRDBKUTlNT1lkdDJZckJ2Sm1YanA0My9ZcS9oWWNmYzRteHF6SVMvNHhU?= =?utf-8?B?eUFNQ1gvVjR6dkRNWGlqaTI0Mmh0elpsaWxHQ0VlM3RWOHhJTWQ1VWFvY08y?= =?utf-8?B?dUI1OWEvcnBxVnJ0RHRMWDZEY0xHS3hJSGVtNnlydzdwN1BSeUdVMUFpMDJL?= =?utf-8?B?dkNJMnJmZXFNbjJoMVkvSjRJWHNVSmh1cmNGMTExZFBnVmRpWkNsNGZ4aEJB?= =?utf-8?B?M0haZnpNRlAxVXBZOElyRHN6bjZkaHY4bmY2aERONkYxM3NmODRGY2hZVW0w?= =?utf-8?B?RkxaNnZreTRSeXFJdUQ2SGRHZmxRbmlKWkVxOGp4T2dweUtXNlFDMDJCV2VP?= =?utf-8?B?RTNVdmo0NnFUR3ltbk4xT3dOemRxOU5PcGRTVFVYMVFHYlBQTk9QR09pYzUw?= =?utf-8?B?UnowRkxmbzFnbVpWWGhyY1FhL1hseEV6eWNPdXRtVEdhMWUxWndqQ3VNK2dM?= =?utf-8?B?Q1dlRCtsZmZCMnVKck52RC9Oc0pmcjRYVXNURWVoSXY3S01XNjJuVG1FcjBr?= =?utf-8?B?dkNWSjFXV25vLzVaek4rNXZpQitLOWJNTFRQbGQwZ1hBU3paelhWaDZ1VHBq?= =?utf-8?B?VEd0VW1WRmloVjdwa051Y0lQdzMveHpYZkw4NXpCWUdWdlZsUUROcDZOekdX?= =?utf-8?B?eWF5ZzJKanBiOEc3cGtZNTVCSXRIUCtHZk00WmhESWUyWko4dmtScDJvYTYx?= =?utf-8?B?QU52RlZZMnRVSDlvMUNoK1JRUjNpMnRBODZFOVpLRUVhTGk2cDAya0dENVNS?= =?utf-8?B?ZGM0allLK293MmhRWmhLYlVUckFxbEV5bmVjZCsxRk8rZWg4RmpkeldBdVMz?= =?utf-8?B?R0RBRDE5cm5keGE3RVFCbHlCaEtGZXJjUGdQaDRWKzlNSVJYV1N2dTMzUlJr?= =?utf-8?B?eTRzaXZtaGhvM1Mwb2FuU0dIYm9Gem1NMlR1T1BBZ2xEeHhLQUZCSGRXWVBN?= =?utf-8?B?cFk2am5jd3lteWNQemUva29OWmw0Z1lScXMrZkNLTDIzbjUvbWNwRmNpTzBa?= =?utf-8?B?KzVPNXBCc1dvcHNKR3h0WFUvdjFPcWNJMG1GTU9HZG0vb25sU1I5SS9yNE01?= =?utf-8?B?UHQxRWxkZTJhWFhwWGRZd0MrUUdCMldNQXgrSndwTGt0OUY5dnBIeTRBeEJR?= =?utf-8?B?REw5N0pJOWdiQ0hKZFFselYxMEFCUWx0MUFmNXFXK2ZvWGFsaVR6VyswczFr?= =?utf-8?B?aGNCaHVpd3MxNzZVSTNVN0hPMWlnbzRFWlViQTRobDd1d2c2bDhKRnRvMEds?= =?utf-8?B?SFlFaVNFNGw3ZjZWei9NNElJRHQ1VmI0QVZDRXhTdHV1dmxqMkNjR3p1WjRs?= =?utf-8?B?WWxPei9KRzc4cFBXRnNjUnBEM0swZk1uZkdyVGhDSzA5VjVpemlaU2wvSDcr?= =?utf-8?B?d1dYZGtDNSs2bUs2dnBoRnQ3Vm9kTEdyelJZTXZtWnR4VXh1QTZyWnI5Mllt?= =?utf-8?B?ODRIbVl1RTh4MHlwTENIODYvUU9DVy9SMGVKcUVtdUlrcFUzUTFaUktqY0hV?= =?utf-8?B?ekU3bUtvbndZckdTRnA2L3hZVTZGaG03eUhDaXNoSXRxUENZVTJucEg3NjFa?= =?utf-8?B?YzNjc3VjWm4zRHBuMC9PSFBCQU1qV0VaalUvcnhoN1pZR0lYOU5OS0xvSytB?= =?utf-8?B?TTlVTmZaaU9nWGQ4VHlpenUrNXFsYkd3QnRUZWdQUXdtcG85MVZieXE4YjJl?= =?utf-8?B?S1BFQVpUVTR5SW1nendjd2VLaW4vYjVRL1lZUmpTSmMyK1M4WkJ5VFc2d0dX?= =?utf-8?B?ZjhXa3AvZHBQMUIvYUU3NzJiNGhBUUxCUHdTbnhXVW96MGJSVXMrc1hOeWhQ?= =?utf-8?B?SGJyb0phb0xhQXR3QjNNd1E1VmRBPT0=?= x-microsoft-antispam-prvs: x-forefront-prvs: 09497C15EB x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(396003)(366004)(136003)(39860400002)(346002)(15374003)(51914003)(51444003)(13464003)(199004)(189003)(30864003)(66066001)(486006)(110136005)(316002)(25786009)(99286004)(86362001)(7696005)(102836004)(53546011)(6506007)(26005)(54906003)(71200400001)(71190400001)(6246003)(66574012)(53936002)(4326008)(186003)(44832011)(476003)(11346002)(76176011)(14454004)(478600001)(966005)(106356001)(2501003)(33656002)(9326002)(81166006)(8676002)(8936002)(3846002)(7736002)(74316002)(6116002)(790700001)(81156014)(68736007)(229853002)(446003)(105586002)(606006)(54896002)(236005)(55016002)(6306002)(9686003)(5024004)(6436002)(14444005)(256004)(2906002)(97736004)(114624004)(53946003)(5660300002)(579004)(559001)(569006); DIR:OUT; SFP:1101; SCL:1; SRVR:BN8PR15MB3489; H:BN8PR15MB3090.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: IirkJKMJ7TA5DZiiJHRv2T3lk9TeJDdvyrKMQhEoEKWptIq6IOnXNx1W6QEd/pI/7qcfVPMQM0kdZp1Fz7gUQV7p3WgHOZzC/mnFPsY1XNAeU/dG+kWaSPDNCjIh/Iri19C+xzLs3ZKFkP0q77rKUEOVt+4qDIu2c7111XOX1fQLLvD6oyW1LQCzvDlyRMjzGH9mZdWGXjNyoebsXTDGKpkf/m98xJWRXAmmFkcp649jNoMNAaef5gcHDMmxvzjR1Drrl+Xjrl+hFxmRDjiosR30qcnOfcbcaXL3SLfsdfGyTchSBmIoBP07l5FhEBmJi0ByubbmMNiCEuyxc05zLc/l472Erd8sAsNuEFcek4Uy0ibBOmYwZVCGkBO4DU0ypJs7j+iATR8iKobcFLlBG43AKF/SHpxVpY/BwLW1dqg= Content-Type: multipart/alternative; boundary="_000_BN8PR15MB3090DA22E91DA6E0936493EDE3600BN8PR15MB3090namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: d0c4e309-bca3-42b8-3ff0-08d6939ed964 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Feb 2019 23:39:37.9174 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8PR15MB3489 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrMKsWRmVeSWpSXmKPExsUyM2J7te4B3/QYg5+fxSxunHrBanH/UY3F 33VPmS2ebZzPYrHrsbvFh4UPWRzYPHbOusvusWTJTyaPxXteMgUwR3HZpKTmZJalFunbJXBl LHr1l63gyRyhimONaxkbGF88EOxi5OCQEDCRmPPOpYuRi0NI4AijROuhblYI5xujxKoXHcxw zoz/Z6AyS5gk9nx9D+awCExgluh8+4gdIjOFSWLportsEM4DRomeBxMZuxg5OdgEjCTaDvWz g9giAoESZz/cZAQpYha4xijx4NhaJpCEsECwxMJJjcwQRSESS3rOQtlGEk9uXGIBsVkEVCX6 Th8GG8orECMx6dwaFohtfYwSC05MZQf5iROoedkXG5AaRgExie+n1oDNZxYQl7j1ZD6YLSEg ILFkz3lmCFtU4uXjf6wQ9XES3z72QMUVJd7sXMMKYctKXJrfzQhh+0qcuvkL7EsJgZuMEncn vYcaqiXx7Nk9Vki4SktsPJEMUXNLVOLX5h1QzdkS877/gBoqIzH912rmCYx6s5DcB2HnS+w9 voZ5FtifghInZz5hmQU0lllAU2L9Ln2IEkWJKd0P2SFsDYnWOXPZkcUXMLKvYhQtTi1Oyk03 MtZLLcpMLi7Oz9PLSy3ZxAhMWge3/FbdwXj5jeMhRgEORiUe3s+y6TFCrIllxZW5hxglOJiV RHjDvYFCvCmJlVWpRfnxRaU5qcWHGKU5WJTEef8ICcYICaQnlqRmp6YWpBbBZJk4OKUaGP1P +0wzvBq2oVT/481ihztTzq7P7fr5Ye7dt9XOv3+7bnQw1D51N8r4oM6lQxd0G2+tMJkuOXlp /eN1xi5r9ric5jixaqETX4KNvnXEg9nFStwnkrOmNixvXy2/OlyYPzpnnrbnXm+dOfbHbmz8 0HDxbIaX8IwHcjcN1E/obLkVZZDi2aUi9UaJpTgj0VCLuag4EQCAia+fVgMAAA== Archived-At: Subject: Re: [secdir] [DMM] Secdir last call review of draft-ietf-dmm-ondemand-mobility-15 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2019 23:40:09 -0000 --_000_BN8PR15MB3090DA22E91DA6E0936493EDE3600BN8PR15MB3090namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNClRoYW5rcyBmb3IgdGhlIHJlc3BvbnNlcy4gSSBtaXNzZWQgeW91ciBlbWFpbCBhbmQg ZGlnIGZvciBpdCB3aGlsZSByZXZpZXdpbmcgdmVyc2lvbiAxNi4gUGxlYXNlIGZpbmQgbXkgY29t bWVudHMgaW5saW5lLiBPdmVyYWxsIHlvdXIgcmVzcG9uc2VzIGFkZHJlc3NlZCBteSBjb25jZXJu ZWQsIGJ1dCBJIGFtIHN0aWxsIHRoaW5raW5nIHRoYXQgdGhlIFNlY3VyaXR5IENvbnNpZGVyYXRp b25zIHNlY3Rpb24gY291bGQgYmUgY29tcGxldGVkLiBGZWVsIGZyZWUgdG8gbGV0IG1lIGtub3cg d2hhdCB5b3UgdGhpbmsuDQoNCllvdXJzLA0KRGFuaWVsDQoNCg0KDQpGcm9tOiBNb3NlcywgRGFu bnkgPGRhbm55Lm1vc2VzQGludGVsLmNvbT4NClNlbnQ6IFRodXJzZGF5LCBKYW51YXJ5IDE3LCAy MDE5IDM6MTEgUE0NClRvOiBEYW5pZWwgTWlnYXVsdCA8ZGFuaWVsLm1pZ2F1bHRAZXJpY3Nzb24u Y29tPjsgc2VjZGlyQGlldGYub3JnDQpDYzogZHJhZnQtaWV0Zi1kbW0tb25kZW1hbmQtbW9iaWxp dHkuYWxsQGlldGYub3JnOyBpZXRmQGlldGYub3JnOyBkbW1AaWV0Zi5vcmcNClN1YmplY3Q6IFJF OiBbRE1NXSBTZWNkaXIgbGFzdCBjYWxsIHJldmlldyBvZiBkcmFmdC1pZXRmLWRtbS1vbmRlbWFu ZC1tb2JpbGl0eS0xNQ0KDQoNCkRhbmllbCwNCg0KDQoNClRoYW5rcyBmb3IgYSB2ZXJ5IHRob3Jv dWdoIHJldmlldyBhbmQgdGhlIGRldGFpbGVkIGNvbW1lbnRzLiBJIGFwcHJlY2lhdGUgeW91ciBp bnZlc3RlZCB0aW1lLg0KDQoNCg0KVGhlcmUgd2VyZSBvbmUgb3IgdHdvIGNvbW1lbnRzIEkgZGlk IG5vdCBmdWxseSB1bmRlcnN0YW5kLg0KDQpJIGhhdmUgdXNlZCBtYW55IG9mIHRoZW0gdG8gaW1w cm92ZSB0aGUgZG9jdW1lbnQuIFRoZXJlIHdlcmUgc29tZSB3aGljaCBJIHRob3VnaHQgZGlmZmVy ZW50bHkgYW5kIHByb3ZpZGVkIGJ5IHJlYXNvbmluZy4NCg0KDQoNClBsZWFzZSBzZWUgbXkgZGV0 YWlsZWQgcmVzcG9uc2UgYmVsb3cuDQoNClRoYW5rcyBhbmQgcmVnYXJkcywNCg0KRGFubnkNCg0K DQoNCiAgMS4gIOKAnGluZWZmaWNpZW5jaWVz4oCdIHNlZW0gdG9vIHZhZ3Vl4oCmDQoNCkkgYW0g YWRkaW5nIGEgcmVmZXJlbmNlIHRvIFJGQyA3MzMzIHRoYXQgZGVzY3JpYmUgdGhlc2UgaW5lZmZp Y2llbmNpZXMgaW4gc2VjdGlvbiA0Lg0KDQo8bWdsdD5UaGFua3MgdGhhdCBpcyBjbGVhcmVyIHRv IG1lLjwvbWdsdD4NCg0KICAxLiAgVXNlIOKAnElQIHNlc3Npb24gY29udGludWl0eeKAnSByYXRo ZXIgdGhhbiDigJxzZXNzaW9uIGNvbnRpbnVpdHnigJ0NCg0KVGhlIG9yaWdpbmFsIGRlZmluaXRp b24gd2FzIOKAnElQIHNlc3Npb24gY29udGludWl0eeKAnS4gSG93ZXZlciwgQnJpYW4gSGFiZXJt YW4gaW4gdGhlIGVhcmx5IHJldmlldyBjb21tZW50ZWQgdGhhdCB0aGlzIHRlcm0gaXMgY29uZnVz aW5nIHNpbmNlIHRoZSBJUCBsYXllciBpcyBub3QgYSBzZXNzaW9uIGxheWVyIGFuZCB0aHVzLCDi gJxJUCBTZXNzaW9u4oCdIGlzIG5vdCBkZWZpbmVkLiBUbyByZXNvbHZlIHRoaXMsIHdlIGFncmVl ZCB0byBjaGFuZ2Ug4oCcSVAgc2Vzc2lvbiBjb250aW51aXR54oCdIHRvIOKAnHNlc3Npb24gY29u dGludWl0eeKAnSBpbiB2ZXJzaW9uIDE1IG9mIHRoaXMgZHJhZnQuIEkgZmVlbCBjb21mb3J0YWJs ZSB3aXRoIGFueSBvZiB0aGVzZSBkZWZpbml0aW9ucywgc28gaWYgdGhlIHJldmlld2VycyBjYW4g YWdyZWUgb24gYSB0ZXJtLCBJIHdpbGwgYWRvcHQgaXQuIEluIGFueSBjYXNlLCBJIGJlbGlldmUg dGhlIHRleHQgY2xlYXJseSBkZXNjcmliZSB0aGUgYmVoYXZpb3Igb2YgdGhlIG5ldHdvcmsuDQoN CjxtZ2x0PlRoZSB0ZXh0IGlzIGNsZWFyLjwvbWdsdD4NCg0KICAxLiAgUmVjb21tZW5kZWQgcmVv cmRlcmluZyBvZiB0aGUgdGV4dCBpbiBzZWN0aW9uIDEuDQoNCkkgZGlkIG5vdCB1bmRlcnN0YW5k IHRoZSByZWNvbW1lbmRlZCBvcmRlciwgdGhhdCBpcywgd2hpY2ggcGFyYWdyYXBoIG5lZWRzIHRv IGJlIG1vdmVkIHRvIHdoaWNoIHBsYWNlLiBQbGVhc2UgaGVscCBjbGFyaWZ5IHRoaXMgY29tbWVu dC4NCg0KPG1nbHQ+DQoNCldlbGwgSSB0aGluayB0aGUgaW50cm9kdWN0aW9uIGNvdWxkIGJlIGJl dHRlciBhcnRpY3VsYXRlZC4gQnV0IGFzIGl0IHNlZW1zIEkgYW0gdGhlIG9ubHkgb25lIHJhaXNp bmcgdGhlIGNvbmNlcm4sIEkgZ3Vlc3MgdGhhdCBpcyBmaW5lLg0KDQoNCg0KV2hhdCBJIG1lYW50 IHdhcyB0byBoYXZlIGl0IGFzIGZvbGxvd3M6DQoNCg0KICAgTW9iaWxlIElQIGlzIGRlc2lnbmVk IHRvIHByb3ZpZGUgYm90aCBzZXNzaW9uIGNvbnRpbnVpdHkgYW5kIElQDQogICBhZGRyZXNzIHJl YWNoYWJpbGl0eSB0byBtb2JpbGUgaG9zdHMuICBBcmNoaXRlY3R1cmVzIHV0aWxpemluZyB0aGVz ZQ0KICAgcHJvdG9jb2xzIChlLmcuLCAzR1BQLCAzR1BQMiwgV0lNQVgpIGVuc3VyZSB0aGF0IGFu eSBtb2JpbGUgaG9zdA0KICAgYXR0YWNoZWQgdG8gdGhlIGNvbXBsaWFudCBuZXR3b3JrcyBjYW4g ZW5qb3kgdGhlc2UgYmVuZWZpdHMuICBBbnkNCiAgIGFwcGxpY2F0aW9uIHJ1bm5pbmcgb24gdGhl c2UgbW9iaWxlIGhvc3RzIGlzIHN1YmplY3RlZCB0byB0aGUgc2FtZQ0KICAgdHJlYXRtZW50IHdp dGggcmVzcGVjdCB0byBzZXNzaW9uIGNvbnRpbnVpdHkgYW5kIElQIGFkZHJlc3MNCiAgIHJlYWNo YWJpbGl0eS4NCg0KDQogICBBY2hpZXZpbmcgc2Vzc2lvbiBjb250aW51aXR5IGFuZCBJUCBhZGRy ZXNzIHJlYWNoYWJpbGl0eSB3aXRoIE1vYmlsZQ0KICAgSVAgaW5jdXJzIHNvbWUgY29zdC4gIE1v YmlsZSBJUCBwcm90b2NvbCBmb3JjZXMgdGhlIG1vYmlsZSBob3N0J3MgSVANCiAgIHRyYWZmaWMg dG8gdHJhdmVyc2UgYSBjZW50cmFsbHktbG9jYXRlZCByb3V0ZXIgKEhvbWUgQWdlbnQsIEhBKSwN CiAgIHdoaWNoIGluY3VycyBhZGRpdGlvbmFsIHRyYW5zbWlzc2lvbiBsYXRlbmN5IGFuZCB1c2Ug b2YgYWRkaXRpb25hbA0KICAgbmV0d29yayByZXNvdXJjZXMsIGFkZHMgdG8gdGhlIG5ldHdvcmsg Q0FQRVggYW5kIE9QRVgsIGFuZCBkZWNyZWFzZXMNCiAgIHRoZSByZWxpYWJpbGl0eSBvZiB0aGUg bmV0d29yayBkdWUgdG8gdGhlIGludHJvZHVjdGlvbiBvZiBhIHNpbmdsZQ0KICAgcG9pbnQgb2Yg ZmFpbHVyZSBbUkZDNzMzM10uICBUaGVyZWZvcmUsIHNlc3Npb24gY29udGludWl0eSBhbmQgSVAN CiAgIGFkZHJlc3MgcmVhY2hhYmlsaXR5IFNIT1VMRCBiZSBwcm92aWRlZCBvbmx5IHdoZW4gbmVj ZXNzYXJ5Lg0KDQoNCiAgIEl0IHNob3VsZCBiZSBub3RlZCB0aGF0IGluIHJlYWxpdHkgbm90IGV2 ZXJ5IGFwcGxpY2F0aW9uIG1heSBuZWVkDQogICB0aGVzZSBiZW5lZml0cy4gIElQIGFkZHJlc3Mg cmVhY2hhYmlsaXR5IGlzIHJlcXVpcmVkIGZvciBhcHBsaWNhdGlvbnMNCiAgIHJ1bm5pbmcgYXMg c2VydmVycyAoZS5nLiwgYSB3ZWIgc2VydmVyIHJ1bm5pbmcgb24gdGhlIG1vYmlsZSBob3N0KS4N CiAgIEJ1dCwgYSB0eXBpY2FsIGNsaWVudCBhcHBsaWNhdGlvbiAoZS5nLiwgd2ViIGJyb3dzZXIp IGRvZXMgbm90DQogICBuZWNlc3NhcmlseSByZXF1aXJlIElQIGFkZHJlc3MgcmVhY2hhYmlsaXR5 LiAgU2ltaWxhcmx5LCBzZXNzaW9uDQogICBjb250aW51aXR5IGlzIG5vdCByZXF1aXJlZCBmb3Ig YWxsIHR5cGVzIG9mIGFwcGxpY2F0aW9ucyBlaXRoZXIuDQogICBBcHBsaWNhdGlvbnMgcGVyZm9y bWluZyBicmllZiBjb21tdW5pY2F0aW9uIChlLmcuLCBwaW5nKSBjYW4gc3Vydml2ZQ0KDQogICB3 aXRob3V0IGhhdmluZyBzZXNzaW9uIGNvbnRpbnVpdHkgc3VwcG9ydA0KDQo8L21nbHQ+DQoNCg0K DQogIDEuICBSZXBsYWNlIOKAmHBpbmfigJkgd2l0aCBhIG1vcmUgdXNlZnVsIGFwcGxpY2F0aW9u IGFzIGFuIGV4YW1wbGUuDQoNClVzZSB0ZXh0IG1lc3NhZ2luZyBpbnN0ZWFkLg0KDQo8bWdsdD5J IGJlbGlldmUgdGhhdCBpcyBhIG1vcmUgY29udmluY2luZyBleGFtcGxlLjwvbWdsdD4NCg0KDQoN CiAgMS4gIFNwbGl0IHRoZSBmZWF0dXJlIHZlcnN1cyBpdHMgaW1wbGVtZW50YXRpb24gc2hvdWxk IGJlIGRvbmUgaW4gYSBzaW1pbGFyIG1hbm5lciBmb3IgYm90aCBzZXNzaW9uIGNvbnRpbnVpdHkg YW5kIHJlYWNoYWJpbGl0eSB0byBlYXNlIHJlYWRpbmcuDQoNCkFmdGVyIGdpdmluZyBpdCBzb21l IHRob3VnaHQsIEkgdGVuZCB0byB0aGluayBkaWZmZXJlbnRseS4gVGhpcyBpcyB0aGUgSW50cm9k dWN0aW9uIHNlY3Rpb24gYW5kIGFzIHN1Y2ggc2hvdWxkIGJlIHNob3J0LiBJIGRvIG5vdCB0aGlu ayB0aGUgc3BsaXR0aW5nIGlzIG5lZWRlZCB0byB1bmRlcnN0YW5kIHRoZSByZXN0IG9mIHRoZSBk b2N1bWVudC4gSSBwcmVmZXIgdG8ga2VlcCB0aGlzIHNlY3Rpb24gc2hvcnQuDQoNCjxtZ2x0Pkkg YWdyZWUgd2l0aCB5b3UuIFdoYXQgY29uZnVzZWQgYXQgZmlyc3Qgd2FzIHRoZSBzZXNzaW9uIGNv bnRpbnVpdHkuPC9tZ2x0Pg0KDQoNCg0KICAxLiAgQWRkIGEgcGFyYWdyYXBoIHRoYXQgaW5kaWNh dGVzIHRoZSBhZGRyZXNzIHJlYWNoYWJpbGl0eSBjYW4gYmUgcGVyZm9ybWVkIGJ5IGFwcGxpY2F0 aW9ucyB1c2luZyBvdGhlciBtZWFucyB0aGFuIElQIHJlYWNoYWJpbGl0eS4NCg0KSSBkbyBub3Qg dGhpbmsgdGhpcyBpcyByZXF1aXJlZC4gVGhlIG1vdGl2YXRpb24gb2YgdGhpcyBJbnRyb2R1Y3Rp b24gaXMgdG8gY29udmluY2UgdGhlIHJlYWRlciB0aGF0IHRoZXJlIGlzIGEgYmVuZWZpdCBmcm9t IGVuYWJsaW5nIGFwcGxpY2F0aW9ucyB0byBpbmRpY2F0ZSB0aGVpciByZXF1aXJlbWVudHMgZnJv bSB0aGUgbW9iaWxlIG5ldHdvcmssIHJhdGhlciB0aGFuIGdldHRpbmcgdGhlIGZ1bGwgc2Vydmlj ZSBzdXBwb3J0LiBJIHRoaW5rIHRoZSBtZXNzYWdlIGlzIGNsZWFyIGFzIGl0IGlzLg0KDQo8bWds dD5JIGFncmVlIGZvciB0aGUgc2FtZSBhcyBhYm92ZS4gVG8gbWUgSSBiZWxpZXZlIHdoYXQgd291 bGQgaGF2ZSBiZWVuIHZlcnkgY29udmluY2luZyBpcyBhbiBhcHByb2FjaCB3aGVyZSB3ZSBtZW50 aW9uIHdoYXQgYXBwbGljYXRpb24gbmVlZCByYXRoZXIgdGhhbiB3aGF0IHRoZXkgZG8gbm90IG5l ZWQuIEJ1dCBhZ2FpbiB0aGF0IGlzIG1vcmUgcmVsYXRlZCB0byB0aGUgcHJlc2VudGF0aW9uLjwv bWdsdD4NCg0KDQoNCiAgMS4gIEFkZCBhIHJlZmVyZW5jZSB0byBSRkMgNTAxNCBhbmQgdGhlIHVz YWdlIG9mIGhvbWUgYW5kIGNhcmUtb2YgYWRkcmVzc2VzLg0KDQpBY3R1YWxseSwgZm9yIG1vYmls ZSBJUCwgdGhpcyBkb2N1bWVudCBpcyBub3QgcmVxdWlyZWQuIElmIHRoZSBtb2JpbGUgaG9zdCBz dXBwb3J0cyBtb2JpbGUgSVAsIGl0IGNhbiBlbmFibGUgYXBwbGljYXRpb25zIHRvIHNlbGVjdCBl aXRoZXIgYSBob21lIGFkZHJlc3Mgb3IgYSBjYXJlLW9mIGFkZHJlc3MgdG8gdXNlIGZvciB0aGUg SVAgY29ubmVjdGlvbiBhbmQgYnkgdGhhdCwgdXNlIG9yIGNob29zZSBub3QgdG8gdXNlIG1vYmls aXR5IHNlcnZpY2VzIHByaWRlZCBieSB0aGUgbW9iaWxlIG5ldHdvcmsuDQoNClRoaXMgZG9jdW1l bnQgYWRkcmVzc2VzIHRoZSBjYXNlIHdoZXJlIHRoZSBuZXR3b3JrIHByb3ZpZGUgdGhlc2Ugc2Vy dmljZXMgYnkgcHJveHkgYW5kIHRodXMsIHByb3ZpZGVzIHRoZSBmdWxsIG1vYmlsaXR5IHNlcnZp Y2UgcmVnYXJkbGVzcyBvZiB3aGV0aGVyIG9yIG5vdCB0aGV5IGFyZSBuZWVkZWQuDQoNCkZvciBw cm94eSBzZXJ2aWNlcywgd2UgbmVlZCBhIHdheSBmb3IgYXBwbGljYXRpb25zIHRvIGV4cHJlc3Mg dGhlaXIgdHJ1ZSBuZWVkcyBhbmQgZm9yIHRoZSBuZXR3b3JrIHN0YWNrIHRvIGNvbnZleSB0aGVz ZSBuZWVkcyB0byB0aGUgbmV0d29yay4NCg0KPG1nbHQ+SW4gbXkgb3BpbmlvbiDigJMgYW5kIG5v dCBiZWluZyBhbiBtb2JpbGl0eSBleHBlcnQg4oCTIHRoZSBhZGRpdGlvbiBvZiB0aGUgdGV4dCBp biB0aGUgaW50cm9kdWN0aW9uIHdvdWxkIGJlIGdyZWF0LiA8L21nbHQ+DQoNCg0KDQoNCg0KICAx LiAgSW5kaWNhdGUg4oCYb24gZGVtYW5k4oCZIGluIHRoZSBJbnRyb2R1Y3Rpb24uDQoNCkkgdGhv dWdodCB0aGlzIGlzIGNsZWFyIGZyb20gdGhlIGZhY3QgdGhhdCBlYWNoIGFwcGxpY2F0aW9uIGlu ZGljYXRlcyBpdCBtb2JpbGl0eSBzZXJ2aWNlIHJlcXVpcmVtZW50cy4gQXMgYXBwbGljYXRpb25z IGNvdWxkIGJlIGxhdW5jaGVkIHNlcGFyYXRlbHkgZnJvbSBlYWNoIG90aGVyIHdpdGggcG9zc2li bGUgbGFyZ2UgdGltZSBnYXBzLCBvbi1kZW1hbmQgaXMgZGVkdWN0ZWQuIEJ1dCB0byBiZSBvbiB0 aGUgc2FmZSBzaWRlLCBJIHdpbGwgYWRkIOKAmG9uIGRlbWFuZOKAmS4NCg0KPG1nbHQ+b2suPC9t Z2x0Pg0KDQogIDEuICBJbiB0aGUgc2V2ZXJhbCBkZWZpbml0aW9ucyBvZiB0eXBlcyBJUCBhZGRy ZXNzIGluIHNlY3Rpb24gMyByZXBsYWNlIOKAmGd1YXJhbnRlZeKAmSB3aXRoIOKAmHJlbWFpbnPi gJkNCg0KSSBwcmVmZXIg4oCYZ3VhcmFudGVl4oCZIGJlY2F1c2UgaXQgYmV0dGVyIGluZGljYXRl cyB0aGUgY29tbWl0bWVudCBvZiB0aGUgbmV0d29yayB0byBwcmVzZXJ2ZSB0aGUgYWRkcmVzcy4N Cg0KPG1nbHQ+b2ssIEkgYW0gbm90IEVuZ2xpc2ggbmF0aXZlLCBzbyB5b3VyIGNob2ljZSBpcyBt b3JlIGFwcHJvcHJpYXRlZC4gSG93ZXZlciBJIGdvdCB0aGF0IGd1YXJhbnRlZSBjb21lcyB3aXRo IG1vcmUgY29tbWl0bWVudC48L21nbHQ+DQoNCiAgMS4gIEEgc3VnZ2VzdGlvbiByZWdhcmRpbmcg dGhlIGRlZmluaXRpb24gb2YgTm9uLXBlcnNpc3RlbnQgSVAgYWRkcmVzcy4NCg0KSSBkaWQgbm90 IHF1aXRlIHVuZGVyc3RhbmQgdGhpcyBzdWdnZXN0aW9uLiBTb21ldGhpbmcgdG8gZG8gd2l0aCBI b21lIEFkZHJlc3MgYW5kIG1vYmlsZSBJUC4gSG93ZXZlciwgSSBiZWxpZXZlIHRoZSBkZWZpbml0 aW9uIG9mIE5vbi1wZXJzaXN0ZW50IElQIGFkZHJlc3MgaW4gdGhpcyBzZWN0aW9uIGlzIGdvb2Qg YXMgaXQgaXMuDQoNCjxtZ2x0Pkkgd2FzIHdvbmRlcmluZyBob3cgZGlmZmVyZW50IHRoZSBhZGRy ZXNzIGNvdWxkIGJlIGZyb20gYSBjYXJlLW9mLWFkZHJlc3MuIEFnYWluIG15IGNvbmZ1c2lvbiB3 YXMgdGhhdCBJIGNvbnNpZGVyZWQgdGhlIGhvc3QgYSBNSVAgbm9kZS48L21nbHQ+DQoNCg0KDQog IDEuICBUaGVyZSBhcmUgYWRkaXRpb25hbCBjb21tZW50cyByZWdhcmRpbmcgbW9iaWxlIElQLg0K DQpBcyBJIGluZGljYXRlZCBiZWZvcmUsIHRoaXMgZG9jdW1lbnQgaXMgbm90IGFib3V0IG1vYmls ZSBJUCB3aGVyZSB0aGUgbW9iaWxlIGhvc3QgaGFzIGNvbnRyb2wgb3ZlciB0aGUgc2VsZWN0aW9u IG9mIGNhcmUtb2YgdmVyc3VzIEhvbWUgYWRkcmVzc2VzLiBJdCBpcyBhYm91dCBwcm94eSBzb2x1 dGlvbnMsIGluIHdoaWNoIHRoZSBtb2JpbGUgaG9zdCBkb2VzIG5vdCBoYXZlIGFueSBjb250cm9s IG92ZXIgdGhlIG1vYmlsaXR5IHNlcnZpY2UgYmVjYXVzZSBpdCBpcyBkb25lIGJ5LXByb3h5IGJ5 IHRoZSBuZXR3b3JrLg0KDQo8bWdsdD5FeGFjdGx5LiBJIGFwb2xvZ3kgZm9yIG5vdCBjYXRjaGlu ZyB0aGlzLjwvbWdsdD4NCg0KICAxLiAgTmVlZCB0byBtZW50aW9uIHRoZSBvdmVybGFwcyBvZiB0 aGUgYWRkcmVzcyB0eXBlcy4NCg0KWWVzLCB0aGVyZSBhcmUgb3ZlcmxhcHMgYnV0IEkgZG8gbm90 IHNlZSB3aHkgbWVudGlvbmluZyB0aGVtIGhlbHBzLg0KDQo8bWdsdD50aGF0IHdhcyBtb3JlIGZv ciB0aGUgc2VsZWN0aW9uLjwvbWdsdD4NCg0KICAxLiAgTGlzdCB0aGUgZGlmZmVyZW50IGFkZHJl c3MgdHlwZXMgaW4gdGhlIHNhbWUgb3JkZXIgaW4gYWxsIHNlY3Rpb25zIHRvIGVhc2UgdGhlIHJl YWRpbmcuDQoNCkkgYWdyZWUuIENoYW5naW5nIHRoZSBvcmRlciBpbiBzZWN0aW9uIDMuMy4NCg0K PG1nbHQ+b2ssdGhhdCB3YXMgYSBuaXQuPC9tZ2x0Pg0KDQogIDEuICBBIGNvbW1lbnQgYWJvdXQg aGF2aW5nIHRoZSBhcHBsaWNhdGlvbiByZXF1ZXN0IHRoZSBtaW5pbWFsIGNhcGFiaWxpdHkgYW5k IHRoZSBuZXR3b3JrIGF1dG9tYXRpY2FsbHkgcHJvdmlkaW5nIHRoZSBuZXh0IGxldmVsIGlmIGl0 IGNhbm5vdCBmdWxmaWxsIHRoaXMgbWluaW1hbCBsZXZlbC4NCg0KVGhpcyBpcyBhIHBvaW50IHdl IGNvbnNpZGVyZWQgYWxvbmcgd2l0aCBlbmFibGluZyBhcHBsaWNhdGlvbnMgdG8gcmVxdWVzdCBz ZXZlcmFsIGxldmVscyBpbiBwYXJhbGxlbCBhbmQgbGV0dGluZyB0aGUgbmV0d29yayBzZWxlY3Qg dGhlIG1vc3QgcHJlZmVyYWJsZSBvbmUuIEFmdGVyIHNvbWUgZXZhbHVhdGlvbiwgd2UgZGVjaWRl ZCB0aGF0IHRoaXMgZmxleGliaWxpdHkgaXMgY291bnRlci1wcm9kdWN0aXZlIGFuZCBpdCBpcyBi ZXN0IHRvIHNwZWNpZnkgYSBzcGVjaWZpYyBzZXJ2aWNlIHR5cGUsIGFuZCBleHBlY3QgaXQgdG8g ZWl0aGVyIGJlIGZ1bGZpbGxlZCBvciBoYXZlIHRoZSByZXF1ZXN0IGZhaWwuIFRoaXMgd2F5LCBu byDigJhzbWFydOKAmSBkZWNpc2lvbnMgYXJlIG1hZGUgYXV0b21hdGljYWxseSBieSB0aGUgbmV0 d29yay4gUmVtZW1iZXIgaG93ZXZlciwgdGhhdCB0aGUgYXBwbGljYXRpb24gcmVxdWVzdHMgdGhl IHNlcnZpY2UgZnJvbSB0aGUgbmV0d29yayBzdGFjaywgYW5kIHRoZSBuZXR3b3JrIHN0YWNrIHJl cXVlc3RzIGl0IGZyb20gdGhlIG5ldHdvcmsuIFdlIGRvIG5vdCBwcm92aWRlIGFueSByZXN0cmlj dGlvbnMgb24gdGhlIGltcGxlbWVudGF0aW9ucyBvZiBuZXR3b3JrIHN0YWNrcy4gU29tZSBjb3Vs ZCBwZXJmb3JtIGNhY2hpbmcgb2YgbmV0d29yayBjYXBhYmlsaXRpZXMsIGFuZCBzZWxlY3QgdG8g cmVzcG9uZCB0byBhcHBsaWNhdGlvbnMgd2l0aG91dCBpbnRlcmFjdGluZyB3aXRoIHRoZSBuZXR3 b3JrLg0KDQo8bWdsdD5vay48L21nbHQ+DQoNCiAgMS4gIEFub3RoZXIgY29tbWVudCBhYm91dCB0 aGUgYmVoYXZpb3Igb2YgdGhlIEFQSSwgYXNzdW1pbmcgYSByZXF1ZXN0IG1pZ2h0IG5vdCBiZSBm dWxmaWxsZWQgd2l0aG91dCByZXN1bHRpbmcgaW4gYW4gZXJyb3IgcmVzcG9uc2UuDQoNClNvIGFz IEkgZGVzY3JpYmVkIHByZXZpb3VzbHksIEFQSSByZXF1ZXN0cyB0aGF0IGNhbm5vdCBiZSBmdWxm aWxsZWQgZXhhY3RseSBhcyBzcGVjaWZpZWQsIHJlc3VsdCB3aXRoIGFuIGVycm9yIHJlc3BvbnNl Lg0KDQo8bWdsdD5nb3QgaXQuPC9tZ2x0Pg0KDQogIDEuICBBIHF1ZXN0aW9uIGFib3V0IHRoZSBP Tl9ORVQgZmxhZy4NCg0KWWVzLCB5b3VyIHVuZGVyc3RhbmRpbmcgaXMgY29ycmVjdC4NCg0KPG1n bHQ+8J+YiTwvbWdsdD4NCg0KICAxLiAgUmVxdWVzdCBhbiBleGFtcGxlIHdpdGggdGhlIE9OX05F VCBmbGFnLg0KDQpUaGVyZSBjb3VsZCBiZSBvdGhlciBleGFtcGxlcyBhcyB3ZWxsLiBUaGVyZSBh cmUgYWxsIGtpbmRzIG9mIGNhc2VzIHRoYXQgY291bGQgYmUgcHJlc2VudGVkLiBUaGVyZSBpcyBh IHRyYWRlLW9mZiBiZXR3ZWVuIHRoZSBzaXplIG9mIGFuIFJGQyBhbmQgYSB0ZXh0IGJvb2suIFdl IHRob3VnaHQgaXQgd291bGQgYmUgdXNlZnVsIHRvIHByb3ZpZGUgYW4gZXhhbXBsZSBvZiBhIG5v bi10cml2aWFsIGNhc2UgYW5kIGxlYXZlIG90aGVyIGNhc2VzIHRvIGZ1dHVyZSB0ZXh0IGJvb2tz IGFuZCB0dXRvcmlhbHMuDQoNCjxtZ2x0PmFncmVlPC9tZ2x0Pg0KDQoNCg0KICAxLiAgT25EZW1h biB2ZXJzdXMgT24gRGVtYW5kIHZlcnN1cyBPbi1EZW1hbmQuIEJlIGNvbnNpc3RlbnQuDQoNCkkg YWdyZWUuIFdpbGwgYmUgZml4ZWQuDQoNCjxtZ2x0Pm9rPC9tZ2x0Pg0KDQogIDEuICBJUCB2NiB2 ZXJzdXMgSVB2Ni4gQmUgY29uc2lzdGVudC4NCg0KSSBhZ3JlZS4gV2lsbCBiZSBmaXhlZC4NCg0K PG1nbHQ+b2s8L21nbHQ+DQoNCiAgMS4gIERlc2NyaWJlIHRoZSBtZWNoYW5pc20gaW4gd2hpY2gg dGhlIGFkZHJlc3MgdHlwZSBpcyBpbmRpY2F0ZWQgYnkgdGhlIG5ldHdvcmsgdG8gdGhlIGhvc3Qu DQoNClVuZm9ydHVuYXRlbHkgSSBjYW5ub3QuIFN1Y2ggYSBtZWNoYW5pc20gZG9lcyBub3QgZXhp c3QgYXQgdGhlIG1vbWVudC4gV2UgYXJlIHdvcmtpbmcgb24gdGhhdCBhcyB3ZWxsLg0KDQo8bWds dD5ub3Qgc3VyZSB3ZSBzaG91bGQgbm90IG1lbnRpb24gdGhhdCBpcyBvbmdvaW5nIHdvcmsgYXMg d2VsbCBhcyBwb3NzaWJsZSBkaXJlY3Rpb25zLjwvbWdsdD4NCg0KICAxLiAgSW4gc2VjdGlvbiA1 LjIsIG5lZWQgdG8gZGVzY3JpYmUgaG93IHRoZSBuZXcgSVAgc3RhY2sgbmVlZHMgdG8gYmVoYXZl IHdoZW4gYW4gYXBwbGljYXRpb24gdGhhdCBkb2VzIG5vdCBzdXBwb3J0IE9uLURlbWFuZCBvcGVu cyBpbml0aWF0ZXMgYSBuZXR3b3JrIGNvbm5lY3Rpb24uIOKAmGxlZ2FjeSBtYW5uZXLigJkgaXMg bm90IGEgZ29vZCBkZXNjcmlwdGlvbi4NCg0KVGhlIG5leHQgcGFyYWdyYXBoIGluIHRoaXMgc2Vj dGlvbiBkb2VzIGV4YWN0bHkgdGhhdC4gRGVzY3JpYmVzIGhvdyB0aGUgSVAgc3RhY2sgc2hvdWxk IGludGVyYWN0IHdpdGggdGhlIG5ldHdvcmsuDQoNCjxtZ2x0Pm9rLiBJIGJlbGlldmUgd2hhdCB3 YXMgdW5jbGVhciB0byBtZSB3YXMgdGhhdCBJIGV4cGVjdGVkIGxlZ2FjeSB0byBpbmNsdWRlIE1J UCBub2Rlcy4gPC9tZ2x0Pg0KDQogIDEuICBQbGFjZSB0aGUgc3RhdGVtZW50IGFib3V0IG5ldHdv cmtzIHN1cHBvcnRpbmcgb3Igbm90IHN1cHBvcnRpbmcgT24tRGVtYW5kIGZ1bmN0aW9uYWxpdHkg aW4gdGhlIGludHJvZHVjdGlvbi4NCg0KSSBwcmVmZXIgbm90IHRvIGRvIHRoYXQuIEkgYW0gdHJ5 aW5nIHRvIGtlZXAgdGhlIEludHJvZHVjdGlvbiBzaG9ydCBhbmQgY3Jpc3AuIExpc3RpbmcgYWxs IHVzZS1jYXNlcywgYmFja3dhcmRzIGNvbXBhdGliaWxpdHkgYW5kIG90aGVyIGRldGFpbHMg4oCT IGZvciB0aGF0IHdlIGhhdmUgdGhlIHJlc3Qgb2YgdGhlIGRvY3VtZW50LiBUaGUg4oCYSW50cm9k Y3V0aW9u4oCZIGluIG15IG9waW5pb24gc2hvdWxkIG9ubHkgcHJvdmlkZSBpbmZvcm1hdGlvbiB0 byBoZWxwIHRoZSByZWFkZXIgZGVjaWRlIGl0IGl0IHNob3VsZCBjb250aW51ZSByZWFkaW5nIHRo ZSBkb2N1bWVudCBvciBub3QuDQoNCjxtZ2x0PlRoaXMgaXMgY2xlYXIgdG8gbWUga25vdy48L21n bHQ+DQoNCiAgMS4gIFRoZSBkZXNjcmlwdGlvbiByZWdhcmRpbmcgdGhlIHVzZS1jYXNlIG9mIHVz aW5nIGJvdGggc2V0c29ja29wdCgpIGFuZCBzZXRzYygpL2JpbmQoKSBpcyBoYXJkIHRvIHJlYWQu IENsYXJpZnkuDQoNCk9LLiBJIHdpbGwgdHJ5IHRvIHNpbXBsaWZ5IGl0LiBCeSB0aGUgd2F5LCB5 b3VyIHVuZGVyc3RhbmRpbmcgaXMgY29ycmVjdC4NCg0KPG1nbHQ+VGhhdCB3YXMgYSBuaXQuPC9t Z2x0Pg0KDQogIDEuICBBIGNvbW1lbnQgYWJvdXQgdGhlIHBsYWNlbWVudCBvZiB0aGUgZmxhZ3Mg YW5kIGFkZHJlc3MgdHlwZXMuDQoNCkkgZGlkIG5vdCBxdWl0ZSBnZXQgdGhpcyBjb21tZW50LiBJ IHdvdWxkIGxpa2UgdG8gY2xhcmlmeSB0aGF0IHdlIGFyZSBwcm92aWRpbmcgdGhlIFNvY2tldCBB UEkgYXMgYW4gZXhhbXBsZSB0byBjbGFyaWZ5IHRoZSBjb25jZXB0LiBXZSBleHBlY3Qgb3RoZXIg c3RhbmRhcmQgYm9kaWVzIHRvIHVzZSB0aGlzIGRvY3VtZW50IHRvIHNwZWNpZnkgdGhlIGV4YWN0 IGltcGxlbWVudGF0aW9uIGluIGRpZmZlcmVudCBwcm9ncmFtbWluZyBsYW5ndWFnZXMuDQoNCjxt Z2x0PkkgZW52aXNpb25lZCB0aGF0IEZMQUdTIGFyZSB0aGUgc3RhbmRhcmQgd2F5IGFwcGxpY2F0 aW9ucyB3aWxsIHVzZSB0byBjb21tdW5pY2F0ZSB0aGVpciBuZWVkIHRvIHRoZSBPUy4gVGhpcyBp cyBub3QgYW4gSUFOQSByZWdpc3RyeSwgYnV0IEkgd291bGQgaGF2ZSBleHBlY3RlZCB0byBoYXZl IHRoZSBsaXN0IGRlZmluZWQgaW4gYSBoZWFkZXIgZmlsZS48L21nbHQ+DQoNCiAgMS4gIFNlY3Vy aXR5IHRocmVhdHMuDQoNCkkgd291bGQgbGlrZSBzb21lIGNsYXJpZmljYXRpb24gYWJvdXQgdGhl c2UgdGhyZWF0cy4gTXkgdW5kZXJzdGFuZGluZyBpcyB0aGF0IHRoZXNlIHRocmVhdHMgYXJlIHJl bGV2YW50IHRvIHRoZSBwcm90b2NvbCB1c2UgYnkgdGhlIG1vYmlsZSBob3N0IChvciBzcGVjaWZp Y2FsbHkgaXRzIElQIHN0YWNrKSB0byBpbnRlcmFjdCB3aXRoIHRoZSBuZXR3b3JrIHRvIGNvbnZl eSB0aGUgZGVzaXJlZCBtb2JpbGl0eSBzZXJ2aWNlLCBhbmQgcmVjZWl2ZSB0aGUgZ3JhbnRlZCBz ZXJ2aWNlLg0KDQpCdXQgdGhpcyBkb2N1bWVudCBkb2VzIG5vdCBkZWZpbmUgdGhlc2UgcHJvdG9j b2xzLiBJdCBkZWZpbmVzIHRoZSBPbi1EZW1hbmQgY29uY2VwdCBhbmQgdGhlIGZlYXR1cmVzIG5l ZWRlZCBieSB0aGUgQVBJIGJldHdlZW4gYXBwbGljYXRpb25zIGFuZCB0aGUgbmV0d29yayBzdGFj ay4gU2hvdWxkbuKAmXQgdGhlc2UgdGhyZWF0cyBiZSBkZXNjcmliZWQgaW4gdGhlIHNwZWNpZmlj YXRpb24gb2YgdGhlIHByb3RvY29sIGJldHdlZW4gdGhlIG1vYmlsZSBob3N0IGFuZCBuZXR3b3Jr Pw0KDQoNCg0KPG1nbHQ+SSBiZWxpZXZlIHRoYXQgdGhlIHRocmVhdHMgYXBwbHkgdG8gdGhlIGFi aWxpdHkgdG8gcmVxdWVzdCBkaWZmZXJlbnQgdHlwZXMgb2YgYWRkcmVzc2VzIGFzIHdlbGwgYXMg dGhlIGluZm9ybWF0aW9uIGxlYWtlZCBieSB0aGUgSVAgYWRkcmVzcyByZWdhcmRpbmcgdGhlIGFw cGxpY2F0aW9uLiBUaGUgcHJvdG9jb2wgYmV0d2VlbiB0aGUgbW9iaWxlIGhvc3QgYW5kIHRoZSBu ZXR3b3JrIHdpbGwgYWxzbyBoYXZlIHRvIG1lbnRpb24gc29tZSBvZiB0aGVzZSB0aHJlYXRzLCBi dXQgdGhlc2UgYXJlIHByaW1hcmlseSBhc3NvY2lhdGVkIHRvIHRoZSBhYmlsaXR5IHRvIHNlbGVj dCBzb21lIElQIGFkZHJlc3NlcyB3aXRoIGRpZmZlcmVudCBmdW5jdGlvbmFsaXRpZXMuDQoNCg0K DQpNb3JlIGVzcGVjaWFsbHksDQoNClRoZSBkb2N1bWVudCBkZXNjcmliZXMgaG93IGFwcGxpY2F0 aW9ucyBwcm92aWRlcyB0aGUgT1MgdGhlaXINCnJlcXVpcmVtZW50cyBpbiBvcmRlciB0byBzZWxl Y3QgdGhlIGFwcHJvcHJpYXRlZCBJUCBhZGRyZXNzLiBUaGUNCnJlc291cmNlIGFyZSBhc3NvY2lh dGVkIHRvIGRpZmZlcmVudCBjb3N0cy4gV2hpbGUgdGhlIGNvc3QgaXMgcHJpbWFyaWx5DQpvbiB0 aGUgb3BlcmF0b3Igc2lkZSwgaXQgaXMgbGlrZWx5IHRoYXQgdXNhZ2UgYnkgdGhlIG1vYmlsZSBu b2RlIGNvbWVzDQp3aXRoIHNvbWUgcmVzdHJpY3Rpb25zLCBsaW1pdGF0aW9uIG9yIGRpcmVjdCBj b3N0LiBUeXBpY2FsbHksIHNvbWUgdHlwZQ0Kb2YgSVAgYWRkcmVzcyBtYXkgYmUgcHJvdmlkZWQg YnkgdGhlIG9wZXJhdG9yIGZvciBhIGxpbWl0ZWQgbnVtYmVyIG9mDQpieXRlcyB1cG9uIHdoaWNo IHRoZSBJUCBhZGRyZXNzIHR5cGUgd2lsbCBub3QgYmUgYXZhaWxhYmxlIHRvIHRoZSBtb2JpbGUN Cm5vZGUgb3IgbWF5IGJlIGNoYXJnZWQuIEEgbWFsaWNpb3VzIGFwcGxpY2F0aW9uIG1heSB1c2Ug dGhlc2UNCmxpbWl0YXRpb25zIHRvIGdlbmVyYXRlIGV4dHJhIGJpbGxpbmcgb2YgdGhlIG1vYmls ZSBub2RlIG9yIHRvIHByZXZlbnQNCnRoZSB1c2FnZSBvZiBzb21lIGFwcGxpY2F0aW9ucyBieSBl eGhhdXN0aW5nIHRoZSBleHBlY3RlZCB0eXBlIG9mIElQDQphZGRyZXNzLg0KDQogICAgPG1nbHQ+ SSBiZWxpZXZlIHRoZSB0aHJlYXQgaGVyZSBpcyB0aGF0IGEgbWFsaWNpb3VzIGFwcGxpY2F0aW9u IGNhbiBzZWxlY3QgYW4gSVAgYWRkcmVzcyB3aXRoIG1vcmUgZXhwZW5zaXZlIGNhdGVnb3JpZXMu IFRoaXMgc2VlbXMgdG8gbWUgcmVsYXRlZCB0byB0aGUgIE9uLURlbWFuZCBjb25jZXB0LiBEbyB5 b3UgdGhpbmsgb3RoZXJ3aXNlID88L21nbHQ+DQoNCkluIG9yZGVyIHRvIHByZXZlbnQgc3VjaCBz Y2VuYXJpbywgdGhlIG1vYmlsZSBub2RlIFNIT1VMRCBiZSBhYmxlIHRvDQphdXRob3JpemUgc3Bl Y2lmaWMgUEkgYWRkcmVzcyB0eXBlcyB0byBwcml2aWxlZ2UgYXBwbGljYXRpb24uDQoNCldpdGgg dGhlc2UgbmV3IHR5cGVzIG9mIElQIGFkZHJlc3NlcywgdGhlIElQIGFkZHJlc3MgbGVha3Mgc29t ZQ0KY29ubmVjdGl2aXR5IHJlcXVpcmVtZW50cyBvZiB0aGUgYXBwbGljYXRpb24uIFRoaXMgYWxz byBtZWFucyB0aGF0DQphZGRpdGlvbmFsIGluZm9ybWF0aW9uIGlzIHByb3ZpZGVkIHRvIHRoZSBk ZXN0aW5hdGlvbiB3aGljaCBjb3VsZCByZXZlYWwNCnRvIGEgcGFzc2l2ZSBtb25pdG9yaW5nIGF0 dGFja2VyIHNvbWUgaW5mb3JtYXRpb24gc3VjaCBhcyB0aGUgdHlwZSBvZg0KYXBwbGljYXRpb24g YW5kIHRoZSBhcHBsaWNhdGlvbiBpdHNlbGYgZXZlbiB0aG91Z2ggdGhlIHBhY2tldCBpcw0KcHJv dGVjdGVkIGJ5IElQc2VjIG9yIFRMUy4NCg0KICAgIDxtZ2x0PkkgYmVsaWV2ZSB0aGUgdGhyZWF0 IGhlcmUgaXMgdGhhdCBJUCBhZGRyZXNzIGRvIG5vdCBvbmx5IGNhcnJ5IGluZm9ybWF0aW9uIGFi b3V0IHRoZSBkZXN0aW5hdGlvbiBidXQgYWxzbyBhYm91dCB0aGUgZnVuY3Rpb25hbGl0aWVzIGV4 cGVjdGVkIGJ5IHRoZSBhcHBsaWNhdGlvbi4gVGhpcyBzZWVtcyB0byBtZSByZWxhdGVkIHRvIHRo ZSAgT24tRGVtYW5kIGNvbmNlcHQuIERvIHlvdSB0aGluayBvdGhlcndpc2UgPzwvbWdsdD4NCg0K DQpUbyBhdm9pZCBwcm9maWxpbmcgYW4gYXBwbGljYXRpb24gYWNjb3JkaW5nIHRvIHRoZSB0eXBl IG9mIElQIGFkZHJlc3NlcywNCml0IGlzIGV4cGVjdGVkIHRoYXQgcHJlZml4ZXMgcHJvdmlkZWQg YnkgdGhlIG9wZXJhdG9yIGFyZSBhc3NvY2lhdGVkIHRvDQp2YXJpb3VzIHR5cGUgb2YgYWRkcmVz c2VzIG92ZXIgdGltZS4gQXMgYSByZXN1bHQsIHRoZSB0eXBlIG9mIGFkZHJlc3MNCmNvdWxkIG5v dCBiZSBhc3NvY2lhdGVkIHRvIHRoZSBwcmVmaXgsIG1ha2luZyBhcHBsaWNhdGlvbiBwcm9maWxp bmcNCmJhc2VkIG9uIHRoZSB0eXBlIG9mIGFkZHJlc3MgaGFyZGVyLg0KQXBwbGljYXRpb24gdXNp bmcgbXVsdGlwbGUgdHlwZSBvZiBJUCBhZGRyZXNzZXMgdG8gYXZvaWQgYmVpbmcgcHJvZmlsZWQN CmlzIGxpa2VseSB0byBjcmVhdGUgc29tZSBwYXR0ZXJucy4gU28gdGhhdCByZW1haW5zIGEgaGFy ZCBwcm9ibGVtIHRvDQpzb2x2ZSBieSB0aGUgYXBwbGljYXRpb24uDQoNClRoZSB1c2FnZSBvZiBh IGZpeGVkIElQIGFkZHJlc3MsIGVuYWJsZXMgdHJhY2tpbmcgdGhlIG1vYmlsZSBub2RlLCBvcg0K aXRzIGFwcGxpY2F0aW9uIG92ZXIgdGltZS4gVGhpcyBpcyBhIHNpbWlsYXIgcHJvYmxlbSBhcyB0 aGUgb25lDQplbmNvdW50ZXJlZCB3aXRoIFB1YmxpYyBJUCBhZGRyZXNzZXMuIFRoZSB1c2FnZSBv ZiB0aGUgRml4ZWQgSVANCmFkZHJlc3NlcyBzaG91bGQgYmUgbGltaXRlZC4NCg0KICAgIDxtZ2x0 PkkgYmVsaWV2ZSB0aGUgdGhyZWF0IGhlcmUgaXMgcmVsYXRlZCB0byB0aGUgc2VsZWN0aW9uIG9m IGEgZml4ZWQgSVAgYWRkcmVzcy4gVGhpcyBzZWVtcyB0byBtZSByZWxhdGVkIHRvIHRoZSAgT24t RGVtYW5kIGNvbmNlcHQgaW4gdGhlIHNlbnNlIHRoYXQgaWYgeW91IGNhbiBkZWFsIHdpdGggbm9u IHBlcnNpc3RlbnQgdGhhdCBtYXkgYmUgYmV0dGVyLjwvbWdsdD4NCg0KDQpUbyBsaW1pdCB0aGUg ZWZmZWN0IG9mIElQIHRyYWNraW5nLCB0aGUgYXBwbGljYXRpb24gb3IgdGhlIE9TIHNob3VsZA0K ZW5zdXJlIHRoYXQgSVAgYWRkcmVzc2VzIHJlZ3VsYXJseSBjaGFuZ2UgdG8gbGltaXQgSVAgdHJh Y2tpbmcgYnkgYQ0KcGFzc2l2ZSBvYnNlcnZlci4gIFRoZSBhcHBsaWNhdGlvbiBzaG91bGQgcmVn dWxhcmx5IHNldCB0aGUgT24gRGVtYW5kDQpmbGFnLiBUaGUgYXBwbGljYXRpb24gc2hvdWxkIGJl IGFibGUgdG8gZW5zdXJlIHRoYXQgc2Vzc2lvbiBsYXN0aW5nIElQDQphZGRyZXNzIGFyZSByZWd1 bGFybHkgY2hhbmdlZCBieSBzZXR0aW5nIGEgbGlmZXRpbWUgZm9yIGV4YW1wbGUgaGFuZGxlZA0K YnkgdGhlIGFwcGxpY2F0aW9uLiBJbiBhZGRpdGlvbiwgdGhlIGFwcGxpY2F0aW9uIHNob3VsZCBj b25zaWRlciB0aGUgdXNlDQpvZiBncmFjZWZ1bCByZXBsYWNlbWVudCBJUCBhZGRyZXNzZXMuDQoN ClNpbWlsYXJseSwgdGhlIE9TIG1heSBhbHNvIGFzc29jaWF0ZWQgSVAgYWRkcmVzc2VzIHdpdGgg YSBsaWZldGltZS4gVXBvbg0KcmVjZWl2aW5nIGEgcmVxdWVzdCBmb3IgYSBnaXZlbiB0eXBlIG9m IElQIGFkZHJlc3MsIGFmdGVyIHNvbWUgdGltZSwgdGhlDQpPUyBzaG91bGQgcmVxdWVzdCBhIG5l dyBhZGRyZXNzIHRvIHRoZSBuZXR3b3JrIGV2ZW4gaWYgaXQgYWxyZWFkeSBoYXMNCm9uZSBJUCBh ZGRyZXNzIGF2YWlsYWJsZSB3aXRoIHRoZSByZXF1ZXN0ZWQgdHlwZS4gVGhpcyBpbmNsdWRlcyBh bnkgdHlwZQ0Kb2YgSVAgYWRkcmVzcy4gQWRkcmVzc2VzIG9mIHR5cGUgZ3JhY2VmdWwgcmVwbGFj ZW1lbnQgb3Igbm9uIHBlcnNpc3RlbnQNCklQIGFkZHJlc3NlcyBzaG91bGQgYmUgcmVndWxhcmx5 IHJlbmV3ZWQgYnkgdGhlIE9TLg0KDQpUaGUgbGlmZXRpbWUgb2YgYW4gSVAgYWRkcmVzcyBtYXkg YmUgZXhwcmVzc2VkIGluIG51bWJlciBvZiBzZWNvbmRzIG9yDQppbiBudW1iZXIgb2YgYnl0ZXMg c2VudCB0aHJvdWdoIHRoaXMgSVAgYWRkcmVzcy4NCg0KU2Vzc2lvbiBsYXN0aW5nIElQIGFkZHJl c3MgY291bGQgYmUgdXNlZCB0byBhdm9pZCB0cmFja2luZyBhbmQgc2hvdWxkIGJlDQpwcmVmZXJy ZWQuIEhvd2V2ZXIsIHRoZXJlIHNob3VsZCBiZSBhIHdheSB0byBzcGVjaWZ5IGJldHdlZW4gb25l IHNlc3Npb24NCmxhc3Rpbmcgb3IgaWYgdGhlIElQIGFkZHJlc3MgY2FuIGxhc3QgbXVsdGlwbGUg c2Vzc2lvbnMuDQo8L21nbHQ+DQoNCk9uZSBhZGRpdGlvbmFsIG5pdDogLy8gTEFzdGluZyBzb3Vy Y2UgSVAgYWRkcmVzcw0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQpGcm9tOiBkbW0gW21haWx0bzpkbW0tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxm IE9mIERhbmllbCBNaWdhdWx0DQpTZW50OiBXZWRuZXNkYXksIEphbnVhcnkgMTYsIDIwMTkgMDQ6 NTcNClRvOiBzZWNkaXJAaWV0Zi5vcmc8bWFpbHRvOnNlY2RpckBpZXRmLm9yZz4NCkNjOiBkcmFm dC1pZXRmLWRtbS1vbmRlbWFuZC1tb2JpbGl0eS5hbGxAaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWll dGYtZG1tLW9uZGVtYW5kLW1vYmlsaXR5LmFsbEBpZXRmLm9yZz47IGlldGZAaWV0Zi5vcmc8bWFp bHRvOmlldGZAaWV0Zi5vcmc+OyBkbW1AaWV0Zi5vcmc8bWFpbHRvOmRtbUBpZXRmLm9yZz4NClN1 YmplY3Q6IFtETU1dIFNlY2RpciBsYXN0IGNhbGwgcmV2aWV3IG9mIGRyYWZ0LWlldGYtZG1tLW9u ZGVtYW5kLW1vYmlsaXR5LTE1DQoNCg0KDQpSZXZpZXdlcjogRGFuaWVsIE1pZ2F1bHQNCg0KUmV2 aWV3IHJlc3VsdDogTm90IFJlYWR5DQoNCg0KDQpIaSwNCg0KDQoNCkkgYW0gdGhlIGFzc2lnbmVk IFNlY2RpciByZXZpZXdlciBmb3IgdGhpcyBkcmFmdC4gVGhlIFNlY3VyaXR5IERpcmVjdG9yYXRl DQoNCihTZWNkaXIpIHJldmlld3MgYWxsIElFVEYgZG9jdW1lbnRzIGJlaW5nIHByb2Nlc3NlZCBi eSB0aGUgSUVTRyBmb3IgdGhlIElFVEYgIENoYWlyLiAgUGxlYXNlIHRyZWF0IHRoZXNlIGNvbW1l bnRzIGp1c3QgbGlrZSBhbnkgb3RoZXIgbGFzdCBjYWxsIGNvbW1lbnRzLg0KDQoNCg0KWW91cnMs DQoNCkRhbmllbA0KDQoNCg0KICAgICAgICAgICAgICAgICAgICAgT24gRGVtYW5kIE1vYmlsaXR5 IE1hbmFnZW1lbnQNCg0KICAgICAgICAgICAgICAgICAgZHJhZnQtaWV0Zi1kbW0tb25kZW1hbmQt bW9iaWxpdHktMTUNCg0KDQoNCkFic3RyYWN0DQoNCg0KDQogICBBcHBsaWNhdGlvbnMgZGlmZmVy IHdpdGggcmVzcGVjdCB0byB3aGV0aGVyIHRoZXkgbmVlZCBzZXNzaW9uDQoNCiAgIGNvbnRpbnVp dHkgYW5kL29yIElQIGFkZHJlc3MgcmVhY2hhYmlsaXR5LiAgVGhlIG5ldHdvcmsgcHJvdmlkaW5n IHRoZQ0KDQogICBzYW1lIHR5cGUgb2Ygc2VydmljZSB0byBhbnkgbW9iaWxlIGhvc3QgYW5kIGFu eSBhcHBsaWNhdGlvbiBydW5uaW5nDQoNCiAgIG9uIHRoZSBob3N0IHlpZWxkcyBpbmVmZmljaWVu Y2llcy4NCg0KPG1nbHQ+DQoNCiJpbmVmZmljaWVuY2llcyIgc2VlbXMgdG9vIHZhZ3VlIHRvIG1l IGFuZCBpdCBjb3VsZCBiZSBjbGFyaWZpZWQuDQoNClJlYWRpbmcgdGhlIGFic3RyYWN0LCBpdCBp cyB1bmNsZWFyICh0byBtZSkgaWYgdGhlIGlzc3VlIGlzIG9uIHRoZSBhcHBsaWNhdGlvbiBzaWRl IG9yIHRoZSBuZXR3b3JrIG9wZXJhdG9yIHNpZGUuIEkgZ3Vlc3MgdGhpcyBpcyB0aGUgbmV0d29y ayBzaWRlLiBJdCBpcyBhbHNvIHVuY2xlYXIgdGhlIG5hdHVyZSBvZiB0aGUgaW5lZmZpY2llbmN5 Lg0KDQo8L21nbHQ+DQoNCg0KDQogICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBhDQoNCiAgIHNv bHV0aW9uIGZvciB0YWtpbmcgdGhlIGFwcGxpY2F0aW9uIG5lZWRzIGludG8gYWNjb3VudCBieSBz ZWxlY3RpdmVseQ0KDQogICBwcm92aWRpbmcgc2Vzc2lvbiBjb250aW51aXR5IGFuZCBJUCBhZGRy ZXNzIHJlYWNoYWJpbGl0eSBvbiBhIHBlci0NCg0KICAgc29ja2V0IGJhc2lzLg0KDQoNCg0KU3Rh dHVzIG9mIFRoaXMgTWVtbw0KDQoNCg0KICAgVGhpcyBJbnRlcm5ldC1EcmFmdCBpcyBzdWJtaXR0 ZWQgaW4gZnVsbCBjb25mb3JtYW5jZSB3aXRoIHRoZQ0KDQogICBwcm92aXNpb25zIG9mIEJDUCA3 OCBhbmQgQkNQIDc5Lg0KDQoNCg0KICAgSW50ZXJuZXQtRHJhZnRzIGFyZSB3b3JraW5nIGRvY3Vt ZW50cyBvZiB0aGUgSW50ZXJuZXQgRW5naW5lZXJpbmcNCg0KICAgVGFzayBGb3JjZSAoSUVURiku ICBOb3RlIHRoYXQgb3RoZXIgZ3JvdXBzIG1heSBhbHNvIGRpc3RyaWJ1dGUNCg0KICAgd29ya2lu ZyBkb2N1bWVudHMgYXMgSW50ZXJuZXQtRHJhZnRzLiAgVGhlIGxpc3Qgb2YgY3VycmVudCBJbnRl cm5ldC0NCg0KICAgRHJhZnRzIGlzIGF0IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZHJh ZnRzL2N1cnJlbnQvLg0KDQoNCg0KICAgSW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFmdCBkb2N1bWVu dHMgdmFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXggbW9udGhzDQoNCiAgIGFuZCBtYXkgYmUgdXBk YXRlZCwgcmVwbGFjZWQsIG9yIG9ic29sZXRlZCBieSBvdGhlciBkb2N1bWVudHMgYXQgYW55DQoN CiAgIHRpbWUuICBJdCBpcyBpbmFwcHJvcHJpYXRlIHRvIHVzZSBJbnRlcm5ldC1EcmFmdHMgYXMg cmVmZXJlbmNlDQoNCiAgIG1hdGVyaWFsIG9yIHRvIGNpdGUgdGhlbSBvdGhlciB0aGFuIGFzICJ3 b3JrIGluIHByb2dyZXNzLiINCg0KDQoNCiAgIFRoaXMgSW50ZXJuZXQtRHJhZnQgd2lsbCBleHBp cmUgb24gSmFudWFyeSAyNywgMjAxOS4NCg0KDQoNCkNvcHlyaWdodCBOb3RpY2UNCg0KDQoNCiAg IENvcHlyaWdodCAoYykgMjAxOCBJRVRGIFRydXN0IGFuZCB0aGUgcGVyc29ucyBpZGVudGlmaWVk IGFzIHRoZQ0KDQogICBkb2N1bWVudCBhdXRob3JzLiAgQWxsIHJpZ2h0cyByZXNlcnZlZC4NCg0K DQoNClllZ2luLCBldCBhbC4gICAgICAgICAgIEV4cGlyZXMgSmFudWFyeSAyNywgMjAxOSAgICAg ICAgICAgICAgICBbUGFnZSAxXQ0KDQoNCg0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgT24g RGVtYW5kIE1vYmlsaXR5ICAgICAgICAgICAgICAgICAgSnVseSAyMDE4DQoNCg0KDQogICBUaGlz IGRvY3VtZW50IGlzIHN1YmplY3QgdG8gQkNQIDc4IGFuZCB0aGUgSUVURiBUcnVzdCdzIExlZ2Fs DQoNCiAgIFByb3Zpc2lvbnMgUmVsYXRpbmcgdG8gSUVURiBEb2N1bWVudHMNCg0KICAgKGh0dHBz Oi8vdHJ1c3RlZS5pZXRmLm9yZy9saWNlbnNlLWluZm8pIGluIGVmZmVjdCBvbiB0aGUgZGF0ZSBv Zg0KDQogICBwdWJsaWNhdGlvbiBvZiB0aGlzIGRvY3VtZW50LiAgUGxlYXNlIHJldmlldyB0aGVz ZSBkb2N1bWVudHMNCg0KICAgY2FyZWZ1bGx5LCBhcyB0aGV5IGRlc2NyaWJlIHlvdXIgcmlnaHRz IGFuZCByZXN0cmljdGlvbnMgd2l0aCByZXNwZWN0DQoNCiAgIHRvIHRoaXMgZG9jdW1lbnQuICBD b2RlIENvbXBvbmVudHMgZXh0cmFjdGVkIGZyb20gdGhpcyBkb2N1bWVudCBtdXN0DQoNCiAgIGlu Y2x1ZGUgU2ltcGxpZmllZCBCU0QgTGljZW5zZSB0ZXh0IGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9u IDQuZSBvZg0KDQogICB0aGUgVHJ1c3QgTGVnYWwgUHJvdmlzaW9ucyBhbmQgYXJlIHByb3ZpZGVk IHdpdGhvdXQgd2FycmFudHkgYXMNCg0KICAgZGVzY3JpYmVkIGluIHRoZSBTaW1wbGlmaWVkIEJT RCBMaWNlbnNlLg0KDQoNCg0KVGFibGUgb2YgQ29udGVudHMNCg0KDQoNCiAgIDEuICBJbnRyb2R1 Y3Rpb24gIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAg Mg0KDQogICAyLiAgTm90YXRpb25hbCBDb252ZW50aW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAgIDQNCg0KICAgMy4gIFNvbHV0aW9uICAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA0DQoNCiAgICAgMy4xLiAgVHlw ZXMgb2YgSVAgQWRkcmVzc2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAg NA0KDQogICAgIDMuMi4gIEdyYW51bGFyaXR5IG9mIFNlbGVjdGlvbiAgLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAgIDYNCg0KICAgICAzLjMuICBPbiBEZW1hbmQgTmF0dXJlICAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA2DQoNCiAgICAgMy40LiAgQ29u dmV5aW5nIHRoZSBEZXNpcmVkIEFkZHJlc3MgVHlwZSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAg Nw0KDQogICA0LiAgVXNhZ2UgZXhhbXBsZSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAgIDgNCg0KICAgICA0LjEuICBQc2V1ZG8tY29kZSBleGFtcGxlIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA4DQoNCiAgICAgNC4yLiAgTWVz c2FnZSBGbG93IGV4YW1wbGUgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAx MA0KDQogICA1LiAgQmFja3dhcmRzIENvbXBhdGliaWxpdHkgQ29uc2lkZXJhdGlvbnMgIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAgMTENCg0KICAgICA1LjEuICBBcHBsaWNhdGlvbnMgIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDExDQoNCiAgICAgNS4yLiAgSVAg U3RhY2sgaW4gdGhlIE1vYmlsZSBIb3N0IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAx Mg0KDQogICAgIDUuMy4gIE5ldHdvcmsgSW5mcmFzdHJ1Y3R1cmUgIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAgMTINCg0KICAgICA1LjQuICBNZXJnaW5nIHRoaXMgd29yayB3aXRo IFJGQzUwMTQgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDEyDQoNCiAgIDYuICBTdW1tYXJ5 IG9mIE5ldyBEZWZpbml0aW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAx Mw0KDQogICAgIDYuMS4gIE5ldyBBUElzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAgMTMNCg0KICAgICA2LjIuICBOZXcgRmxhZ3MgLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDEzDQoNCiAgIDcuICBTZWN1cml0 eSBDb25zaWRlcmF0aW9ucyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAx NA0KDQogICA4LiAgSUFOQSBDb25zaWRlcmF0aW9ucyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAgMTQNCg0KICAgOS4gIENvbnRyaWJ1dG9ycyAgLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDE0DQoNCiAgIDEwLiBBY2tub3ds ZWRnZW1lbnRzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAx NA0KDQogICAxMS4gUmVmZXJlbmNlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAgMTQNCg0KICAgICAxMS4xLiAgTm9ybWF0aXZlIFJlZmVyZW5jZXMg LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDE1DQoNCiAgICAgMTEuMi4gIElu Zm9ybWF0aXZlIFJlZmVyZW5jZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAx NQ0KDQogICBBdXRob3JzJyBBZGRyZXNzZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAgMTYNCg0KDQoNCjEuICBJbnRyb2R1Y3Rpb24NCg0KDQoNCiAgIElu IHRoZSBjb250ZXh0IG9mIE1vYmlsZSBJUCBbUkZDNTU2M11bUkZDNjI3NV1bUkZDNTIxM11bUkZD NTk0NF0sIHRoZQ0KDQogICBmb2xsb3dpbmcgdHdvIGF0dHJpYnV0ZXMgYXJlIGRlZmluZWQgZm9y IElQIHNlcnZpY2UgcHJvdmlkZWQgdG8NCg0KICAgbW9iaWxlIGhvc3RzOg0KDQoNCg0KICAgU2Vz c2lvbiBjb250aW51aXR5OiBUaGUgYWJpbGl0eSB0byBtYWludGFpbiBhbiBvbmdvaW5nIHRyYW5z cG9ydA0KDQogICBpbnRlcmFjdGlvbiBieSBrZWVwaW5nIHRoZSBzYW1lIGxvY2FsIGVuZC1wb2lu dCBJUCBhZGRyZXNzIHRocm91Z2hvdXQNCg0KICAgdGhlIGxpZmUtdGltZSBvZiB0aGUgSVAgc29j a2V0IGRlc3BpdGUgdGhlIG1vYmlsZSBob3N0IGNoYW5naW5nIGl0cw0KDQoNCg0KWWVnaW4sIGV0 IGFsLiAgICAgICAgICAgRXhwaXJlcyBKYW51YXJ5IDI3LCAyMDE5ICAgICAgICAgICAgICAgIFtQ YWdlIDJdDQoNCg0KDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICBPbiBEZW1hbmQgTW9iaWxp dHkgICAgICAgICAgICAgICAgICBKdWx5IDIwMTgNCg0KDQoNCiAgIHBvaW50IG9mIGF0dGFjaG1l bnQgd2l0aGluIHRoZSBJUCBuZXR3b3JrIHRvcG9sb2d5LiAgVGhlIElQIGFkZHJlc3MNCg0KICAg b2YgdGhlIGhvc3QgbWF5IGNoYW5nZSBhZnRlciBjbG9zaW5nIHRoZSBJUCBzb2NrZXQgYW5kIGJl Zm9yZSBvcGVuaW5nDQoNCiAgIGEgbmV3IG9uZSwgYnV0IHRoYXQgZG9lcyBub3QgamVvcGFyZGl6 ZSB0aGUgYWJpbGl0eSBvZiBhcHBsaWNhdGlvbnMNCg0KICAgdXNpbmcgdGhlc2UgSVAgc29ja2V0 cyB0byB3b3JrIGZsYXdsZXNzbHkuICBTZXNzaW9uIGNvbnRpbnVpdHkgaXMNCg0KICAgZXNzZW50 aWFsIGZvciBtb2JpbGUgaG9zdHMgdG8gbWFpbnRhaW4gb25nb2luZyBmbG93cyB3aXRob3V0IGFu eQ0KDQogICBpbnRlcnJ1cHRpb24uDQoNCg0KDQo8bWdsdD4NCg0KU2Vzc2lvbiBjb250aW51aXR5 IGNhbiBiZSBwcm92aWRlZCBhdCBtdWx0aXBsZSBsYXllcnMgdGh1cyBJIHdvdWxkIHJlY29tbWVu ZCBmb3IgY2xhcml0eSB0byBjaGFuZ2Ugc2Vzc2lvbiBjb250aW51aXR5IHRvIElQIHNlc3Npb24g Y29udGludWl0eSBhbmQgaW5zaXN0cyB0aGF0IHRoaXMgaXMgYmVpbmcgcHJvdmlkZWQgYXQgdGhl IElQIGxheWVyLg0KDQoNCg0KTm90IHRoYXQgSVAgaXMgc2Vzc2lvbmxlc3MsIHNvIGhlcmUgc2Vz c2lvbiBzZWVtcyBzaW1pbGFyIHRvIHJlYWNoYWJpbGl0eSBidXQgJ29yY2hlc3RyYXRlZCcgYnkg YSBoaWdoZXIgc2Vzc2lvbiBwcm90b2NvbC4NCg0KVGhlIGRpZmZlcmVuY2UgSSBzZWUgaXMgdGhh dCByZWFjaGFiaWxpdHkgaXMgYSBjb21taXRtZW50IChieSB0aGUgSVNQKSBmb3Igbm90IGNoYW5n aW5nIHRoZSBJUCBhZGRyZXNzIHdoaWxlIHdpdGggc2Vzc2lvbiBjb250aW51aXR5IHRoZSBjb21t aXRtZW50IGlzIHJlbGF0ZWQgdG8gdGhlIHVzZSBvZiB0aGUgSVAgYWRkcmVzcy4gSW4gb3RoZXIg d29yZHMsIHdpdGggYSBsaW1pdGVkIHBlcmlvZCBvZiB0aW1lLg0KDQo8L21nbHQ+DQoNCg0KDQog ICBJUCBhZGRyZXNzIHJlYWNoYWJpbGl0eTogVGhlIGFiaWxpdHkgdG8gbWFpbnRhaW4gdGhlIHNh bWUgSVAgYWRkcmVzcw0KDQogICBmb3IgYW4gZXh0ZW5kZWQgcGVyaW9kIG9mIHRpbWUuICBUaGUg SVAgYWRkcmVzcyBzdGF5cyB0aGUgc2FtZSBhY3Jvc3MNCg0KICAgaW5kZXBlbmRlbnQgc2Vzc2lv bnMsIGFuZCBldmVuIGluIHRoZSBhYnNlbmNlIG9mIGFueSBzZXNzaW9uLiAgVGhlIElQDQoNCiAg IGFkZHJlc3MgbWF5IGJlIHB1Ymxpc2hlZCBpbiBhIGxvbmctdGVybSByZWdpc3RyeSAoZS5nLiwg RE5TKSwgYW5kIGlzDQoNCiAgIG1hZGUgYXZhaWxhYmxlIGZvciBzZXJ2aW5nIGluY29taW5nIChl LmcuLCBUQ1ApIGNvbm5lY3Rpb25zLiAgSVANCg0KICAgYWRkcmVzcyByZWFjaGFiaWxpdHkgaXMg ZXNzZW50aWFsIGZvciBtb2JpbGUgaG9zdHMgdG8gdXNlIHNwZWNpZmljLw0KDQogICBwdWJsaXNo ZWQgSVAgYWRkcmVzc2VzLg0KDQoNCg0KICAgTW9iaWxlIElQIGlzIGRlc2lnbmVkIHRvIHByb3Zp ZGUgYm90aCBzZXNzaW9uIGNvbnRpbnVpdHkgYW5kIElQDQoNCiAgIGFkZHJlc3MgcmVhY2hhYmls aXR5IHRvIG1vYmlsZSBob3N0cy4gIEFyY2hpdGVjdHVyZXMgdXRpbGl6aW5nIHRoZXNlDQoNCiAg IHByb3RvY29scyAoZS5nLiwgM0dQUCwgM0dQUDIsIFdJTUFYKSBlbnN1cmUgdGhhdCBhbnkgbW9i aWxlIGhvc3QNCg0KICAgYXR0YWNoZWQgdG8gdGhlIGNvbXBsaWFudCBuZXR3b3JrcyBjYW4gZW5q b3kgdGhlc2UgYmVuZWZpdHMuICBBbnkNCg0KICAgYXBwbGljYXRpb24gcnVubmluZyBvbiB0aGVz ZSBtb2JpbGUgaG9zdHMgaXMgc3ViamVjdGVkIHRvIHRoZSBzYW1lDQoNCiAgIHRyZWF0bWVudCB3 aXRoIHJlc3BlY3QgdG8gc2Vzc2lvbiBjb250aW51aXR5IGFuZCBJUCBhZGRyZXNzDQoNCiAgIHJl YWNoYWJpbGl0eS4NCg0KDQoNCjxtZ2x0Pg0KDQpNeSB1bmRlcnN0YW5kaW5nIG9mIHRoZSB0ZXh0 IGlzIHRoYXQgTW9iaWxlIElQIGlzIGV4cGVuc2l2ZSB0byBkZXBsb3kgYW5kIEkgYmVsaWV2ZSBp dCB3b3VsZCBiZSBlYXNpZXIgZm9yIHRoZSByZWFkZXIgdG8gc3RhdGUgaXQgaGVyZSBiZWZvcmUg ZGV2ZWxvcGluZyBhbGwgbWVjaGFuaXNtcyB0aGF0IGhhdmUgYmVlbiBkZXNpZ25lZCB0byBvdmVy Y29tZSBzZXNzaW9uIGNvbnRpbnVpdHkgaW4gYSBkaWZmZXJlbnQgd2F5LiBUaHVzIEkgd291bGQg cHV0IHRoZSBmb2xsb3dpbmcgdGV4dCByaWdodA0KDQpoZXJlOg0KDQogICBBY2hpZXZpbmcgc2Vz c2lvbiBjb250aW51aXR5IGFuZCBJUCBhZGRyZXNzIHJlYWNoYWJpbGl0eSB3aXRoIE1vYmlsZQ0K DQogICBJUCBpbmN1cnMgc29tZSBjb3N0LiAgTW9iaWxlIElQIHByb3RvY29sIGZvcmNlcyB0aGUg bW9iaWxlIGhvc3QncyBJUA0KDQogICB0cmFmZmljIHRvIHRyYXZlcnNlIGEgY2VudHJhbGx5LWxv Y2F0ZWQgcm91dGVyIChIb21lIEFnZW50LCBIQSksDQoNCiAgIHdoaWNoIGluY3VycyBhZGRpdGlv bmFsIHRyYW5zbWlzc2lvbiBsYXRlbmN5IGFuZCB1c2Ugb2YgYWRkaXRpb25hbA0KDQogICBuZXR3 b3JrIHJlc291cmNlcywgYWRkcyB0byB0aGUgbmV0d29yayBDQVBFWCBhbmQgT1BFWCwgYW5kIGRl Y3JlYXNlcw0KDQogICB0aGUgcmVsaWFiaWxpdHkgb2YgdGhlIG5ldHdvcmsgZHVlIHRvIHRoZSBp bnRyb2R1Y3Rpb24gb2YgYSBzaW5nbGUNCg0KICAgcG9pbnQgb2YgZmFpbHVyZSBbUkZDNzMzM10u ICBUaGVyZWZvcmUsIHNlc3Npb24gY29udGludWl0eSBhbmQgSVANCg0KICAgYWRkcmVzcyByZWFj aGFiaWxpdHkgU0hPVUxEIGJlIHByb3ZpZGVkIG9ubHkgd2hlbiBuZWNlc3NhcnkuDQoNCjwvbWds dD4NCg0KDQoNCiAgIEl0IHNob3VsZCBiZSBub3RlZCB0aGF0IGluIHJlYWxpdHkgbm90IGV2ZXJ5 IGFwcGxpY2F0aW9uIG1heSBuZWVkDQoNCiAgIHRoZXNlIGJlbmVmaXRzLiAgSVAgYWRkcmVzcyBy ZWFjaGFiaWxpdHkgaXMgcmVxdWlyZWQgZm9yIGFwcGxpY2F0aW9ucw0KDQogICBydW5uaW5nIGFz IHNlcnZlcnMgKGUuZy4sIGEgd2ViIHNlcnZlciBydW5uaW5nIG9uIHRoZSBtb2JpbGUgaG9zdCku DQoNCiAgIEJ1dCwgYSB0eXBpY2FsIGNsaWVudCBhcHBsaWNhdGlvbiAoZS5nLiwgd2ViIGJyb3dz ZXIpIGRvZXMgbm90DQoNCiAgIG5lY2Vzc2FyaWx5IHJlcXVpcmUgSVAgYWRkcmVzcyByZWFjaGFi aWxpdHkuICBTaW1pbGFybHksIHNlc3Npb24NCg0KICAgY29udGludWl0eSBpcyBub3QgcmVxdWly ZWQgZm9yIGFsbCB0eXBlcyBvZiBhcHBsaWNhdGlvbnMgZWl0aGVyLg0KDQogICBBcHBsaWNhdGlv bnMgcGVyZm9ybWluZyBicmllZiBjb21tdW5pY2F0aW9uIChlLmcuLCBwaW5nKSBjYW4gc3Vydml2 ZQ0KDQogICB3aXRob3V0IGhhdmluZyBzZXNzaW9uIGNvbnRpbnVpdHkgc3VwcG9ydC4NCg0KDQoN CjxtZ2x0Pg0KDQpJIGJlbGlldmUgdGhhdCBzZXNzaW9uIGNvbnRpbnVpdHkgaXMgdGhlIG1haW4g bW90aXZhdGlvbiBvZiB0aGUgZHJhZnQuDQoNCk1lbnRpb25pbmcgcGluZyBhcyBhbiBleGFtcGxl IGlzIGNvdW50ZXIgcHJvZHVjdGl2ZSBhcyBJIGRvdWJ0IHRoaXMgaXMgdGhlIHRhcmdldCBhcHBs aWNhdGlvbiBvZiB0aGUgZHJhZnQuIFRodXMgY2l0aW5nIGFuIGFwcGxpY2F0aW9uIG5vIG9uZSBy ZWFsbHkgd2FudHMgY291bGQgbWVhbiB0aGF0IHdlIGhhdmUgbm90IGZvdW5kIGFueSBvdGhlciBh cHBsaWNhdGlvbiB0aGF0IGRvIG5vdCBuZWVkIHNlc3Npb24gY29udGludWl0eSwgd2hpY2ggY291 bGQgYmUgaW50ZXJwcmV0ZWQgYXMgZXZlcnkgYXBwbGljYXRpb24gbmVlZHMgc2Vzc2lvbiBjb250 aW51aXR5IGF0IHRoZSBJUCBsYXllci4gVGhpcyBpcyBub3QgdGhlIGludGVudGlvbiBvZiB0aGUg dGV4dCwgc28gd2Ugc2hvdWxkIGZpbmQgYW5vdGhlciBleGFtcGxlLg0KDQoNCg0KV2VsbCBJIHRo aW5rIHJlYWNoYWJpbGl0eSBhbmQgc2Vzc2lvbiBjb250aW51aXR5IGFyZSB0d28gZGlmZmVyZW50 IGZlYXR1cmVzLiBBcHBsaWNhdGlvbnMgbWF5IG9ubHkgbmVlZCBvbmUgb2YgdGhlc2UgZmVhdHVy ZXMgbm90IGJvdGguIEluIGFkZGl0aW9uLCBhcHBsaWNhdGlvbiBjYW4gcHJvdmlkZSB0aGVzZSBm ZWF0dXJlcyBhdCB0aGUgSVAgbGF5ZXIgbGF5ZXIgb3IgdXNpbmcgb3RoZXIgbWVjaGFuaXNtcy4g QXMgYSByZWFzb24gdGhlIHVzZSBvZiBNb2JpbGUgSVAgaXMgbGltaXRlZCB0byBhcHBsaWNhdGlv bnMgdGhhdCBuZWVkcyBib3RoIGZlYXR1cmVzIGJlaW5nIHBlcmZvcm1lZCBhdCB0aGUgSVAgbGF5 ZXIgd2hpY2ggb25seSBjb25jZXJuIGEgc21hbGwgZnJhY3Rpb24gb2YgYXBwbGljYXRpb25zLg0K DQoNCg0KUmVhZGluZyB0aGUgdGV4dCBhYm92ZSBzZWVtcyB0byB0YWtlIGZvciBncmFudGVkIHRo YXQgcmVhY2hhYmlsaXR5IGlzIHBlcmZvcm1lZCBvbmx5IGF0IHRoZSBJUCBsYXllci4gU3BsaXR0 aW5nIHRoZSBmZWF0dXJlIHZlcnN1cyBpdHMgaW1wbGVtZW50YXRpb24gc2hvdWxkIGJlIGRvbmUg aW4gYSBzaW1pbGFyIG1hbm5lciBmb3IgYm90aCBzZXNzaW9uIGNvbnRpbnVpdHkgYW5kIHJlYWNo YWJpbGl0eSB0byBlYXNlIHRoZSByZWFkaW5nLg0KDQo8L21nbHQ+DQoNCg0KDQogICBBY2hpZXZp bmcgc2Vzc2lvbiBjb250aW51aXR5IGFuZCBJUCBhZGRyZXNzIHJlYWNoYWJpbGl0eSB3aXRoIE1v YmlsZQ0KDQogICBJUCBpbmN1cnMgc29tZSBjb3N0LiAgTW9iaWxlIElQIHByb3RvY29sIGZvcmNl cyB0aGUgbW9iaWxlIGhvc3QncyBJUA0KDQogICB0cmFmZmljIHRvIHRyYXZlcnNlIGEgY2VudHJh bGx5LWxvY2F0ZWQgcm91dGVyIChIb21lIEFnZW50LCBIQSksDQoNCiAgIHdoaWNoIGluY3VycyBh ZGRpdGlvbmFsIHRyYW5zbWlzc2lvbiBsYXRlbmN5IGFuZCB1c2Ugb2YgYWRkaXRpb25hbA0KDQog ICBuZXR3b3JrIHJlc291cmNlcywgYWRkcyB0byB0aGUgbmV0d29yayBDQVBFWCBhbmQgT1BFWCwg YW5kIGRlY3JlYXNlcw0KDQogICB0aGUgcmVsaWFiaWxpdHkgb2YgdGhlIG5ldHdvcmsgZHVlIHRv IHRoZSBpbnRyb2R1Y3Rpb24gb2YgYSBzaW5nbGUNCg0KICAgcG9pbnQgb2YgZmFpbHVyZSBbUkZD NzMzM10uICBUaGVyZWZvcmUsIHNlc3Npb24gY29udGludWl0eSBhbmQgSVANCg0KICAgYWRkcmVz cyByZWFjaGFiaWxpdHkgU0hPVUxEIGJlIHByb3ZpZGVkIG9ubHkgd2hlbiBuZWNlc3NhcnkuDQoN Cg0KDQo8bWdsdD4NCg0KVGhpcyBzZWN0aW9uIHNob3VsZCBiZSBtb3ZlZCB1cC4gSGVyZSBpdCBp cyBzcGxpdHRpbmcgdGhlIGRpc2N1c3Npb24gb24gc2Vzc2lvbiBjb250aW51aXR5IGFuZCByZWFj aGFiaWxpdHksIHdoaWNoIGlzIGNvbmZ1c2luZy4NCg0KPC9tZ2x0Pg0KDQoNCg0KICAgRnVydGhl cm1vcmUsIHdoZW4gYW4gYXBwbGljYXRpb24gbmVlZHMgc2Vzc2lvbiBjb250aW51aXR5LCBpdCBt YXkgYmUNCg0KICAgYWJsZSB0byBzYXRpc2Z5IHRoYXQgbmVlZCBieSB1c2luZyBhIHNvbHV0aW9u IGFib3ZlIHRoZSBJUCBsYXllciwNCg0KICAgc3VjaCBhcyBNUFRDUCBbUkZDNjgyNF0sIFNJUCBt b2JpbGl0eSBbUkZDMzI2MV0sIG9yIGFuIGFwcGxpY2F0aW9uLQ0KDQogICBsYXllciBtb2JpbGl0 eSBzb2x1dGlvbi4gIFRoZXNlIGhpZ2hlci1sYXllciBzb2x1dGlvbnMgYXJlIG5vdA0KDQogICBz dWJqZWN0IHRvIHRoZSBzYW1lIGlzc3VlcyB0aGF0IGFyaXNlIHdpdGggdGhlIHVzZSBvZiBNb2Jp bGUgSVAgc2luY2UNCg0KICAgdGhleSBjYW4gdXRpbGl6ZSB0aGUgbW9zdCBkaXJlY3QgZGF0YSBw YXRoIGJldHdlZW4gdGhlIGVuZC1wb2ludHMuDQoNCiAgIEJ1dCwgaWYgTW9iaWxlIElQIGlzIGJl aW5nIGFwcGxpZWQgdG8gdGhlIG1vYmlsZSBob3N0LCB0aGUgaGlnaGVyLQ0KDQoNCg0KWWVnaW4s IGV0IGFsLiAgICAgICAgICAgRXhwaXJlcyBKYW51YXJ5IDI3LCAyMDE5ICAgICAgICAgICAgICAg IFtQYWdlIDNdDQoNCg0KDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICBPbiBEZW1hbmQgTW9i aWxpdHkgICAgICAgICAgICAgICAgICBKdWx5IDIwMTgNCg0KDQoNCiAgIGxheWVyIHByb3RvY29s cyBhcmUgcmVuZGVyZWQgdXNlbGVzcyBiZWNhdXNlIHRoZWlyIG9wZXJhdGlvbiBpcw0KDQogICBp bmhpYml0ZWQgYnkgTW9iaWxlIElQLiAgU2luY2UgTW9iaWxlIElQIGVuc3VyZXMgdGhhdCB0aGUg SVAgYWRkcmVzcw0KDQogICBvZiB0aGUgbW9iaWxlIGhvc3QgcmVtYWlucyBmaXhlZCAoZGVzcGl0 ZSB0aGUgbG9jYXRpb24gYW5kIG1vdmVtZW50DQoNCiAgIG9mIHRoZSBtb2JpbGUgaG9zdCksIHRo ZSBoaWdoZXItbGF5ZXIgcHJvdG9jb2xzIG5ldmVyIGRldGVjdCB0aGUgSVAtDQoNCiAgIGxheWVy IGNoYW5nZSBhbmQgbmV2ZXIgZW5nYWdlIGluIG1vYmlsaXR5IG1hbmFnZW1lbnQuDQoNCg0KDQo8 bWdsdD4NCg0KVGhlIHNhbWUgcGFyYWdyYXBoIHNob3VsZCBzYXkgdGhlIHJlYWNoYWJpbGl0eSBj YW4gYmUgcGVyZm9ybWVkIGJ5IGFwcGxpY2F0aW9uIHVzaW5nIG90aGVyIG1lYW5zIHRoYW4gSVAg cmVhY2hhYmlsaXR5Lg0KDQo8L21nbHQ+DQoNCg0KDQogICBUaGlzIGRvY3VtZW50IHByb3Bvc2Vz IGEgc29sdXRpb24gZm9yIGFwcGxpY2F0aW9ucyBydW5uaW5nIG9uIG1vYmlsZQ0KDQogICBob3N0 cyB0byBpbmRpY2F0ZSB3aGV0aGVyIHRoZXkgbmVlZCBzZXNzaW9uIGNvbnRpbnVpdHkgb3IgSVAg YWRkcmVzcw0KDQogICByZWFjaGFiaWxpdHkuICBUaGUgbmV0d29yayBwcm90b2NvbCBzdGFjayBv biB0aGUgbW9iaWxlIGhvc3QsIGluDQoNCiAgIGNvbmp1bmN0aW9uIHdpdGggdGhlIG5ldHdvcmsg aW5mcmFzdHJ1Y3R1cmUsIHByb3ZpZGVzIHRoZSByZXF1aXJlZA0KDQogICB0eXBlIG9mIHNlcnZp Y2UuDQoNCg0KDQo8bWdsdD4NCg0KSSBhc3N1bWUgdGhhdCBzZXNzaW9uIGNvbnRpbnVpdHkgaXMg b25seSB1bmRlcnN0b29kIGFzIElQIHNlc3Npb24gY29udGludWl0eSBhbmQgbm90IHRoZSB0cmFu c3BvcnQgbGF5ZXIuDQoNCjwvbWdsdD4NCg0KDQoNCiAgIEl0IGlzIGZvciB0aGUgYmVuZWZpdCBv ZiBib3RoIHRoZSB1c2VycyBhbmQgdGhlDQoNCiAgIG5ldHdvcmsgb3BlcmF0b3JzIG5vdCB0byBl bmdhZ2UgYW4gZXh0cmEgbGV2ZWwgb2Ygc2VydmljZSB1bmxlc3MgaXQNCg0KICAgaXMgYWJzb2x1 dGVseSBuZWNlc3NhcnkuICBJdCBpcyBleHBlY3RlZCB0aGF0IGFwcGxpY2F0aW9ucyBhbmQNCg0K ICAgbmV0d29ya3MgY29tcGxpYW50IHdpdGggdGhpcyBzcGVjaWZpY2F0aW9uIHdpbGwgdXRpbGl6 ZSB0aGlzIHNvbHV0aW9uDQoNCiAgIHRvIHVzZSBuZXR3b3JrIHJlc291cmNlcyBtb3JlIGVmZmlj aWVudGx5Lg0KDQoNCg0KPG1nbHQ+DQoNClRoZSBpbnRyb2R1Y3Rpb24gc2hvdWxkIGFsc28gcG9z aXRpb24gaXQgd29yayByZWdhcmRpbmcgNTAxNC4gQXQgdGhlIHBvaW50IGl0IGlzIG5vdCBjbGVh ciB3aHkgdGhlIHJlY29tbWVuZGF0aW9ucyBjb3VsZCBub3QgYmUgc3VjaCBhczoNCg0KKiB3aGVu IElQIHNlc3Npb24gcmVhY2hhYmlsaXR5IG9ubHkgaXMgcmVxdWlyZXMgdGhlIGFwcGxpY2F0aW9u IGluZGljYXRlcyBhIHByZWZlcmVuY2UgZm9yIFB1YmxpYyBJUCBhZGRyZXNzZXMNCg0KKiB3aGVu IElQIHNlc3Npb24gY29udGludWl0eSBpcyBuZWVkZWQgdGhlIGFwcGxpY2F0aW9uIHNlbmRzIGEg cHJlZmVyZW5jZSBmb3IgaG9tZSBvZiBhZGRyZXNzLg0KDQoqIHdoZW4gbm9uZSBpcyByZXF1aXJl ZCB0aGUgYXBwbGljYXRpb24gc2VuZHMgYSBwcmVmZXJlbmNlIGZvciBDYXJlIG9mIEFkZHJlc3Mu DQoNCjwvbWdsdD4NCg0KDQoNCjxtZ2x0Pg0KDQpXaGlsZSBvbiBkZW1hbmQgaXMgbWVudGlvbmVk IGluIHRoZSB0aXRsZSwgaXQgZG9lcyBub3QgYXBwZWFyIGluIHRoZSBpbnRyb2R1Y3Rpb24uIEkg YmVsaWV2ZSB0aGUgaW50cm9kdWN0aW9uIHNob3VsZCBleHBvc2Ugd2h5IHRoZXJlIGlzIGEgbmVl ZCB0byBoYXZlIHRoaXMgZmVhdHVyZS4NCg0KPC9tZ2x0Pg0KDQoNCg0KMi4gIE5vdGF0aW9uYWwg Q29udmVudGlvbnMNCg0KDQoNCiAgIFRoZSBrZXkgd29yZHMgIk1VU1QiLCAiTVVTVCBOT1QiLCAi UkVRVUlSRUQiLCAiU0hBTEwiLCAiU0hBTEwgTk9UIiwNCg0KICAgIlNIT1VMRCIsICJTSE9VTEQg Tk9UIiwgIlJFQ09NTUVOREVEIiwgIk1BWSIsIGFuZCAiT1BUSU9OQUwiIGluIHRoaXMNCg0KICAg ZG9jdW1lbnQgYXJlIHRvIGJlIGludGVycHJldGVkIGFzIGRlc2NyaWJlZCBpbiBbUkZDMjExOV0u DQoNCg0KDQozLiAgU29sdXRpb24NCg0KDQoNCjMuMS4gIFR5cGVzIG9mIElQIEFkZHJlc3Nlcw0K DQoNCg0KICAgRm91ciB0eXBlcyBvZiBJUCBhZGRyZXNzZXMgYXJlIGRlZmluZWQgd2l0aCByZXNw ZWN0IHRvIG1vYmlsaXR5DQoNCiAgIG1hbmFnZW1lbnQuDQoNCg0KDQogICAtIEZpeGVkIElQIEFk ZHJlc3MNCg0KDQoNCiAgIEEgRml4ZWQgSVAgYWRkcmVzcyBpcyBhbiBhZGRyZXNzIHdpdGggYSBn dWFyYW50ZWUgdG8gYmUgdmFsaWQgZm9yIGENCg0KICAgdmVyeSBsb25nIHRpbWUsIHJlZ2FyZGxl c3Mgb2Ygd2hldGhlciBpdCBpcyBiZWluZyB1c2VkIGluIGFueSBwYWNrZXQNCg0KICAgdG8vZnJv bSB0aGUgbW9iaWxlIGhvc3QsIG9yIHdoZXRoZXIgb3Igbm90IHRoZSBtb2JpbGUgaG9zdCBpcw0K DQogICBjb25uZWN0ZWQgdG8gdGhlIG5ldHdvcmssIG9yIHdoZXRoZXIgaXQgbW92ZXMgZnJvbSBv bmUgcG9pbnQtb2YtDQoNCiAgIGF0dGFjaG1lbnQgdG8gYW5vdGhlciAod2l0aCBhIGRpZmZlcmVu dCBJUCBwcmVmaXgpIHdoaWxlIGl0IGlzDQoNCiAgIGNvbm5lY3RlZC4NCg0KDQoNCjxtZ2x0Pg0K DQpUaG91Z2h0IGVuZ2xpc2ggaXMgbm90IG15IGZpcnN0IGxhbmd1YWdlLCAiZ3VhcmFudGVlIiBz b3VuZHMgYSBiaXQgaW5hcHByb3ByaWF0ZS4gSSBtaWdodCBiZSB3cm9uZyBidXQgdGhlIGZvbGxv d2luZyB0ZXh0IHNlZW1zIGNsZWFyZXIgdG8NCg0KbWU6DQoNCg0KDQpPTEQ6DQoNCkEgRml4ZWQg SVAgYWRkcmVzcyBpcyBhbiBhZGRyZXNzIHdpdGggYSBndWFyYW50ZWUgdG8gYmUgdmFsaWQgZm9y IGENCg0KICAgdmVyeSBsb25nIHRpbWUNCg0KDQoNCk5FVzoNCg0KQSBGaXhlZCBJUCBhZGRyZXNz IGlzIGFuIGFkZHJlc3MgdGhhdCByZW1haW5zIHZhbGlkIGZvciBhDQoNCiAgIHZlcnkgbG9uZyB0 aW1lDQoNCg0KDQo8L21nbHQ+DQoNCg0KDQogICBGaXhlZCBJUCBhZGRyZXNzZXMgYXJlIHJlcXVp cmVkIGJ5IGFwcGxpY2F0aW9ucyB0aGF0IG5lZWQgYm90aA0KDQogICBzZXNzaW9uIGNvbnRpbnVp dHkgYW5kIElQIGFkZHJlc3MgcmVhY2hhYmlsaXR5Lg0KDQoNCg0KPG1nbHQ+DQoNCkkgdGhpbmsg dGhlIGRvY3VtZW50IHNob3VsZCBjbGFyaWZ5IGhvdyB0aGlzIGlzIGRpZmZlcmVudCBmcm9tIGEg cHVibGljIGFkZHJlc3MgNTAxNC4NCg0KPC9tZ2x0Pg0KDQoNCg0KICAgLSBTZXNzaW9uLWxhc3Rp bmcgSVAgQWRkcmVzcw0KDQoNCg0KICAgQSBzZXNzaW9uLWxhc3RpbmcgSVAgYWRkcmVzcyBpcyBh biBhZGRyZXNzIHdpdGggYSBndWFyYW50ZWUgdG8gYmUNCg0KICAgdmFsaWQgdGhyb3VnaG91dCB0 aGUgbGlmZS10aW1lIG9mIHRoZSBzb2NrZXQocykgZm9yIHdoaWNoIGl0IHdhcw0KDQogICByZXF1 ZXN0ZWQuICBJdCBpcyBndWFyYW50ZWVkIHRvIGJlIHZhbGlkIGV2ZW4gYWZ0ZXIgdGhlIG1vYmls ZSBob3N0DQoNCiAgIGhhZCBtb3ZlZCBmcm9tIG9uZSBwb2ludC1vZi1hdHRhY2htZW50IHRvIGFu b3RoZXIgKHdpdGggYSBkaWZmZXJlbnQNCg0KICAgSVAgcHJlZml4KS4NCg0KDQoNCjxtZ2x0Pg0K DQpTaW1pbGFybHkgSSB3b3VsZCBwcm9wb3NlIHRoZSBmb2xsb3dpbmcgdGV4dDoNCg0KDQoNCk9M RDoNCg0KICBBIHNlc3Npb24tbGFzdGluZyBJUCBhZGRyZXNzIGlzIGFuIGFkZHJlc3Mgd2l0aCBh IGd1YXJhbnRlZSB0byBiZQ0KDQogICB2YWxpZCB0aHJvdWdob3V0IHRoZSBsaWZlLXRpbWUgb2Yg dGhlIHNvY2tldChzKQ0KDQoNCg0KTkVXOg0KDQogIEEgc2Vzc2lvbi1sYXN0aW5nIElQIGFkZHJl c3MgaXMgYW4gYWRkcmVzcw0KDQogICB2YWxpZCB0aHJvdWdob3V0IHRoZSBsaWZlLXRpbWUgb2Yg dGhlIHNvY2tldChzKQ0KDQoNCg0KT0xEOg0KDQpJdCBpcyBndWFyYW50ZWVkIHRvIGJlIHZhbGlk IGV2ZW4gYWZ0ZXINCg0KDQoNCk5FVzoNCg0KSXQgcmVtYWlucyB2YWxpZCBldmVuIGFmdGVyDQoN CjwvbWdsdD4NCg0KDQoNClllZ2luLCBldCBhbC4gICAgICAgICAgIEV4cGlyZXMgSmFudWFyeSAy NywgMjAxOSAgICAgICAgICAgICAgICBbUGFnZSA0XQ0KDQoNCg0KSW50ZXJuZXQtRHJhZnQgICAg ICAgICAgICAgT24gRGVtYW5kIE1vYmlsaXR5ICAgICAgICAgICAgICAgICAgSnVseSAyMDE4DQoN Cg0KDQogICBTZXNzaW9uLWxhc3RpbmcgSVAgYWRkcmVzc2VzIGFyZSByZXF1aXJlZCBieSBhcHBs aWNhdGlvbnMgdGhhdCBuZWVkDQoNCiAgIHNlc3Npb24gY29udGludWl0eSBidXQgZG8gbm90IG5l ZWQgSVAgYWRkcmVzcyByZWFjaGFiaWxpdHkuDQoNCg0KDQo8bWdsdD4NCg0KSG9tZSBvZiBBZGRy ZXNzIHByb3ZpZGVzIElQIHJlYWNoYWJpbGl0eSwgYnV0IGl0IGlzIHVuY2xlYXIgaWYgSVAgc2Vz c2lvbiBjb250aW51aXR5IGNhbiBiZSBwcm92aWRlZCBieSBvdGhlciBtZWNoYW5pc21zIHRoYXQg TW9iaWxlIElQLg0KDQpJZiB0aGF0IHdlcmUgdGhlIGNhc2UsIGl0IHdvdWxkIGJlIGdvb2QgdG8g c3BlY2lmeSBob3cgdGhpcyBjb3VkbCBiZSBwcm92aWRlZCB3aXRob3V0IElQIHJlYWNoYWJpbGl0 eS4NCg0KPC9tZ2x0Pg0KDQoNCg0KICAgLSBOb24tcGVyc2lzdGVudCBJUCBBZGRyZXNzDQoNCg0K DQogICBUaGlzIHR5cGUgb2YgSVAgYWRkcmVzcyBoYXMgbm8gZ3VhcmFudGVlIHRvIGV4aXN0IGFm dGVyIGEgbW9iaWxlIGhvc3QNCg0KICAgbW92ZXMgZnJvbSBvbmUgcG9pbnQtb2YtYXR0YWNobWVu dCB0byBhbm90aGVyLCBhbmQgdGhlcmVmb3JlLCBubw0KDQogICBzZXNzaW9uIGNvbnRpbnVpdHkg bm9yIElQIGFkZHJlc3MgcmVhY2hhYmlsaXR5IGFyZSBwcm92aWRlZC4gIFRoZSBJUA0KDQogICBh ZGRyZXNzIGlzIGNyZWF0ZWQgZnJvbSBhbiBJUCBwcmVmaXggdGhhdCBpcyBvYnRhaW5lZCBmcm9t IHRoZQ0KDQogICBzZXJ2aW5nIElQIGdhdGV3YXkgYW5kIGlzIG5vdCBtYWludGFpbmVkIGFjcm9z cyBnYXRld2F5IGNoYW5nZXMuICBJbg0KDQogICBvdGhlciB3b3JkcywgdGhlIElQIHByZWZpeCBt YXkgYmUgcmVsZWFzZWQgYW5kIHJlcGxhY2VkIGJ5IGEgbmV3IG9uZQ0KDQogICB3aGVuIHRoZSBJ UCBnYXRld2F5IGNoYW5nZXMgZHVlIHRvIHRoZSBtb3ZlbWVudCBvZiB0aGUgbW9iaWxlIGhvc3QN Cg0KICAgZm9yY2luZyB0aGUgY3JlYXRpb24gb2YgYSBuZXcgc291cmNlIElQIGFkZHJlc3Mgd2l0 aCB0aGUgdXBkYXRlZA0KDQogICBhbGxvY2F0ZWQgSVAgcHJlZml4Lg0KDQoNCg0KPG1nbHQ+DQoN Ckl0IHdvdWRsIGJlIGdvb2QgdG8gcG9zaXRpb24gdGhpcyB0b3dhcmQgdGhlIGNhcmUgb2YgYWRk cmVzcy4NCg0KPC9tZ2x0Pg0KDQoNCg0KICAgLSBHcmFjZWZ1bCBSZXBsYWNlbWVudCBJUCBBZGRy ZXNzDQoNCg0KDQogICBJbiBzb21lIGNhc2VzLCB0aGUgbmV0d29yayBjYW5ub3QgZ3VhcmFudGVl IHRoZSB2YWxpZGl0eSBvZiB0aGUNCg0KICAgcHJvdmlkZWQgSVAgcHJlZml4IHRocm91Z2hvdXQg dGhlIGR1cmF0aW9uIG9mIHRoZSBvcGVuZWQgc29ja2V0LCBidXQNCg0KICAgY2FuIHByb3ZpZGUg YSBsaW1pdGVkIGdyYWNlZnVsIHBlcmlvZCBvZiB0aW1lIGluIHdoaWNoIGJvdGggdGhlDQoNCiAg IG9yaWdpbmFsIElQIHByZWZpeCBhbmQgYSBuZXcgb25lIGFyZSB2YWxpZC4gIFRoaXMgZW5hYmxl cyB0aGUNCg0KICAgYXBwbGljYXRpb24gc29tZSBmbGV4aWJpbGl0eSBpbiB0aGUgdHJhbnNpdGlv biBmcm9tIHRoZSBleGlzdGluZw0KDQogICBzb3VyY2UgSVAgYWRkcmVzcyB0byB0aGUgbmV3IG9u ZS4NCg0KDQoNCiAgIFRoaXMgZ3JhY2VmdWxuZXNzIGlzIHN0aWxsIGJldHRlciB0aGFuIHRoZSBu b24tcGVyc2lzdGVuY2UgdHlwZSBvZg0KDQogICBhZGRyZXNzIGZvciBhcHBsaWNhdGlvbnMgdGhh dCBjYW4gaGFuZGxlIGEgY2hhbmdlIGluIHRoZWlyIHNvdXJjZSBJUA0KDQogICBhZGRyZXNzIGJ1 dCByZXF1aXJlIHRoYXQgZXh0cmEgZmxleGliaWxpdHkuDQoNCg0KDQo8bWdsdD4NCg0KVGhlIGNs YXNzZXMgZGVmaW5lZCBhYm92ZSBoYXZlIG92ZXJsYXBzLiBJIGJlbGlldmUgdGhhdCB3ZSBoYXZl Og0KDQpGaXhlZCBJUCBBZGRyZXNzIFxpbiBTZXNzaW9uLWxhc3RpbmcgSVAgQWRkcmVzcyBcaW4g R3JhY2VmdWwgUmVwbGFjZW1lbnQgSVAgQWRkcmVzcyBcaW4gTm9uLXBlcnNpc3RlbnQgSVAgQWRk cmVzcw0KDQoNCg0KSSB0aGluayB0aGF0IHNob3VsZCBiZSBzdGF0ZWQgaW4gdGhlIHNlY3Rpb24u DQoNCg0KDQo8L21nbHQ+DQoNCg0KDQogICBBcHBsaWNhdGlvbnMgcnVubmluZyBhcyBzZXJ2ZXJz IGF0IGEgcHVibGlzaGVkIElQIGFkZHJlc3MgcmVxdWlyZSBhDQoNCiAgIEZpeGVkIElQIEFkZHJl c3MuICBMb25nLXN0YW5kaW5nIGFwcGxpY2F0aW9ucyAoZS5nLiwgYW4gU1NIIHNlc3Npb24pDQoN CiAgIG1heSBhbHNvIHJlcXVpcmUgdGhpcyB0eXBlIG9mIGFkZHJlc3MuICBFbnRlcnByaXNlIGFw cGxpY2F0aW9ucyB0aGF0DQoNCiAgIGNvbm5lY3QgdG8gYW4gZW50ZXJwcmlzZSBuZXR3b3JrIHZp YSB2aXJ0dWFsIExBTiByZXF1aXJlIGEgRml4ZWQgSVANCg0KICAgQWRkcmVzcy4NCg0KDQoNCiAg IEFwcGxpY2F0aW9ucyB3aXRoIHNob3J0LWxpdmVkIHRyYW5zaWVudCBzZXNzaW9ucyBjYW4gdXNl IFNlc3Npb24tDQoNCiAgIGxhc3RpbmcgSVAgQWRkcmVzc2VzLiAgRm9yIGV4YW1wbGU6IFdlYiBi cm93c2Vycy4NCg0KDQoNCiAgIEFwcGxpY2F0aW9ucyB3aXRoIHZlcnkgc2hvcnQgc2Vzc2lvbnMs IHN1Y2ggYXMgRE5TIGNsaWVudHMgYW5kDQoNCiAgIGluc3RhbnQgbWVzc2VuZ2VycywgY2FuIHV0 aWxpemUgTm9uLXBlcnNpc3RlbnQgSVAgQWRkcmVzc2VzLiAgRXZlbg0KDQogICB0aG91Z2ggdGhl eSBjb3VsZCB2ZXJ5IHdlbGwgdXNlIEZpeGVkIG9yIFNlc3Npb24tbGFzdGluZyBJUA0KDQogICBB ZGRyZXNzZXMsIHRoZSB0cmFuc21pc3Npb24gbGF0ZW5jeSB3b3VsZCBiZSBtaW5pbWl6ZWQgd2hl biBhIE5vbi0NCg0KICAgcGVyc2lzdGVudCBJUCBBZGRyZXNzZXMgYXJlIHVzZWQuDQoNCg0KDQog ICBBcHBsaWNhdGlvbnMgdGhhdCBjYW4gdG9sZXJhdGUgYSBzaG9ydCBpbnRlcnJ1cHRpb24gaW4g Y29ubmVjdGl2aXR5DQoNCiAgIGNhbiB1c2UgdGhlIEdyYWNlZnVsLXJlcGxhY2VtZW50IElQIGFk ZHJlc3Nlcy4gIEZvciBleGFtcGxlLCBhDQoNCiAgIHN0cmVhbWluZyBjbGllbnQgdGhhdCBoYXMg YnVmZmVyaW5nIGNhcGFiaWxpdGllcy4NCg0KDQoNClllZ2luLCBldCBhbC4gICAgICAgICAgIEV4 cGlyZXMgSmFudWFyeSAyNywgMjAxOSAgICAgICAgICAgICAgICBbUGFnZSA1XQ0KDQoNCg0KSW50 ZXJuZXQtRHJhZnQgICAgICAgICAgICAgT24gRGVtYW5kIE1vYmlsaXR5ICAgICAgICAgICAgICAg ICAgSnVseSAyMDE4DQoNCg0KDQozLjIuICBHcmFudWxhcml0eSBvZiBTZWxlY3Rpb24NCg0KDQoN CiAgIElQIGFkZHJlc3MgdHlwZSBzZWxlY3Rpb24gaXMgbWFkZSBvbiBhIHBlci1zb2NrZXQgZ3Jh bnVsYXJpdHkuDQoNCiAgIERpZmZlcmVudCBwYXJ0cyBvZiB0aGUgc2FtZSBhcHBsaWNhdGlvbiBt YXkgaGF2ZSBkaWZmZXJlbnQgbmVlZHMuDQoNCiAgIEZvciBleGFtcGxlLCB0aGUgY29udHJvbC1w bGFuZSBvZiBhbiBhcHBsaWNhdGlvbiBtYXkgcmVxdWlyZSBhIEZpeGVkDQoNCiAgIElQIEFkZHJl c3MgaW4gb3JkZXIgdG8gc3RheSByZWFjaGFibGUsIHdoZXJlYXMgdGhlIGRhdGEtcGxhbmUgb2Yg dGhlDQoNCiAgIHNhbWUgYXBwbGljYXRpb24gbWF5IGJlIHNhdGlzZmllZCB3aXRoIGEgU2Vzc2lv bi1sYXN0aW5nIElQIEFkZHJlc3MuDQoNCg0KDQozLjMuICBPbiBEZW1hbmQgTmF0dXJlDQoNCg0K DQogICBBdCBhbnkgcG9pbnQgaW4gdGltZSwgYSBtb2JpbGUgaG9zdCBtYXkgaGF2ZSBhIGNvbWJp bmF0aW9uIG9mIElQDQoNCiAgIGFkZHJlc3NlcyBjb25maWd1cmVkLiAgWmVybyBvciBtb3JlIE5v bi1wZXJzaXN0ZW50LCB6ZXJvIG9yIG1vcmUNCg0KICAgU2Vzc2lvbi1sYXN0aW5nLCB6ZXJvIG9y IG1vcmUgRml4ZWQgYW5kIHplcm8gb3IgbW9yZSBHcmFjZWZ1bC0NCg0KICAgUmVwbGFjZW1lbnQg SVAgYWRkcmVzc2VzIG1heSBiZSBjb25maWd1cmVkIGJ5IHRoZSBJUCBzdGFjayBvZiB0aGUNCg0K ICAgaG9zdC4gIFRoZSBjb21iaW5hdGlvbiBtYXkgYmUgYXMgYSByZXN1bHQgb2YgdGhlIGhvc3Qg cG9saWN5LA0KDQogICBhcHBsaWNhdGlvbiBkZW1hbmQsIG9yIGEgbWl4IG9mIHRoZSB0d28uDQoN Cg0KDQo8bWdsdD4NCg0KTGlzdGluZyB0aGUgZGlmZmVyZW50IGNsYXNzZXMgaW4gdGhlIHNhbWUg b3JkZXIgYXMgdGhlIG9uZSBvZiB0aGUgZGVmaW5pdGlvbnMgbWF5IGVhc2UgdGhlIHJlYWRpbmcu DQoNCjwvbWdsdD4NCg0KDQoNCiAgIFdoZW4gYW4gYXBwbGljYXRpb24gcmVxdWlyZXMgYSBzcGVj aWZpYyB0eXBlIG9mIElQIGFkZHJlc3MgYW5kIHN1Y2gNCg0KICAgYW4gYWRkcmVzcyBpcyBub3Qg YWxyZWFkeSBjb25maWd1cmVkIG9uIHRoZSBob3N0LCB0aGUgSVAgc3RhY2sgU0hBTEwNCg0KICAg YXR0ZW1wdCB0byBjb25maWd1cmUgb25lLiAgRm9yIGV4YW1wbGUsIGEgaG9zdCBtYXkgbm90IGFs d2F5cyBoYXZlIGENCg0KICAgU2Vzc2lvbi1sYXN0aW5nIElQIGFkZHJlc3MgYXZhaWxhYmxlLiAg V2hlbiBhbiBhcHBsaWNhdGlvbiByZXF1ZXN0cw0KDQogICBvbmUsIHRoZSBJUCBzdGFjayBTSEFM TCBtYWtlIGFuIGF0dGVtcHQgdG8gY29uZmlndXJlIG9uZSBieSBpc3N1aW5nIGENCg0KICAgcmVx dWVzdCB0byB0aGUgbmV0d29yayAoc2VlIFNlY3Rpb24gMy40IGJlbG93IGZvciBtb3JlIGRldGFp bHMpLiAgSWYNCg0KICAgdGhlIG9wZXJhdGlvbiBmYWlscywgdGhlIElQIHN0YWNrIFNIQUxMIGZh aWwgdGhlIGFzc29jaWF0ZWQgc29ja2V0DQoNCiAgIHJlcXVlc3QgYW5kIHJldHVybiBhbiBlcnJv ci4gIElmIHN1Y2Nlc3NmdWwsIGEgU2Vzc2lvbi1sYXN0aW5nIElQDQoNCiAgIEFkZHJlc3MgZ2V0 cyBjb25maWd1cmVkIG9uIHRoZSBtb2JpbGUgaG9zdC4gIElmIGFub3RoZXIgc29ja2V0DQoNCiAg IHJlcXVlc3RzIGEgU2Vzc2lvbi1sYXN0aW5nIElQIGFkZHJlc3MgYXQgYSBsYXRlciB0aW1lLCB0 aGUgc2FtZSBJUA0KDQogICBhZGRyZXNzIG1heSBiZSBzZXJ2ZWQgdG8gdGhhdCBzb2NrZXQgYXMg d2VsbC4gIFdoZW4gdGhlIGxhc3Qgc29ja2V0DQoNCiAgIHVzaW5nIHRoZSBzYW1lIGNvbmZpZ3Vy ZWQgSVAgYWRkcmVzcyBpcyBjbG9zZWQsIHRoZSBJUCBhZGRyZXNzIG1heSBiZQ0KDQogICByZWxl YXNlZCBvciBrZXB0IGZvciBmdXR1cmUgYXBwbGljYXRpb25zIHRoYXQgbWF5IGJlIGxhdW5jaGVk IGFuZA0KDQogICByZXF1aXJlIGEgU2Vzc2lvbi1sYXN0aW5nIElQIGFkZHJlc3MuDQoNCg0KDQo8 bWdsdD4NCg0KSSBzdXNwZWN0IHRoZSBhcHBsaWNhdGlvbiBpcyBleHBlY3RlZCB0byByZXF1ZXN0 IHRoZSB0eXBlIG9mIElQIHdpdGggbWluaW1hbCBjYXBhYmlsaXRpZXMuIEluIHNvbWUgY2FzZXMg dGhlIE9TIG1heSBub3QgaGF2ZSB0aGUgcmVxdWVzdGVkIHR5cGUgb2YgYWRkcmVzcyBidSBtYXkg aGF2ZSBhbm90aGVyIHR5cGUgb2YgYWRkcmVzc2VzIHRoYXQgY291bGQgZnVsZmlsbCB0aGUgYXBw bGljYXRpb24gcmVxdWlyZW1lbnRzLiBJIGJlbGlldmUgdGhlIHRleHQgc2hvdWxkIHNwZWNpZnkg d2hhdCBzaG91bGQgYmUgZG9uZSBpbiB0aGlzIHNpdHVhdGlvbi4gSSBzdXBwb3NlIHRoZSB0ZXh0 IHdpbGwgc2F5IHRoYXQgdGhlIGhvc3Qgc2VuZHMgYSByZXF1ZXN0IHRvIHRoZSBuZXR3b3JrLg0K DQoNCg0KSG93ZXZlciwgSSBzdXNwZWN0IHRoYXQgYWxsb3dpbmcgdGhlIE9TIHRvIHJldHVybiBo aWdoZXIgY2FwYWJpbGl0aWVzIHdvdWxkIGVuY291cmFnZSB0aGUgYXBwbGljYXRpb25zIHRvIHNl bmQgYSBtaW5pbWFsIGxldmVsIG9mIGV4cGVjdGF0aW9uIHNvIHRvIG1heGltaXplIHRoZSBwcm9i YWJpbGl0eSBvZiBhdm9pZGluZyBhIGludGVyYWN0aW9uIGJldHdlZW4gdGhlIGhvc3QgYW5kIHRo ZSBuZXR3b3JrIHRvIHJlcXVlc3QgdGhlIHNwZWNpZmljIHR5cGUgb2YgSVAgYWRkcmVzcy4NCg0K PC9tZ2x0Pg0KDQoNCg0KICAgSW4gc29tZSBjYXNlcyBpdCBtaWdodCBiZSBwcmVmZXJhYmxlIGZv ciB0aGUgbW9iaWxlIGhvc3QgdG8gcmVxdWVzdCBhDQoNCiAgIG5ldyBTZXNzaW9uLWxhc3Rpbmcg SVAgYWRkcmVzcyBmb3IgYSBuZXcgb3BlbmluZyBvZiBhbiBJUCBzb2NrZXQNCg0KICAgKGV2ZW4g dGhvdWdoIG9uZSB3YXMgYWxyZWFkeSBhc3NpZ25lZCB0byB0aGUgbW9iaWxlIGhvc3QgYnkgdGhl DQoNCiAgIG5ldHdvcmsgYW5kIG1pZ2h0IGJlIGluIHVzZSBpbiBhIGRpZmZlcmVudCwgYWxyZWFk eSBhY3RpdmUgSVANCg0KICAgc29ja2V0cykuICBJdCBpcyBvdXRzaWRlIHRoZSBzY29wZSBvZiB0 aGlzIHNwZWNpZmljYXRpb24gdG8gZGVmaW5lDQoNCiAgIGNyaXRlcmlhIGZvciBjaG9vc2luZyB0 byB1c2UgYXZhaWxhYmxlIGFkZHJlc3NlcyBvciBjaG9vc2luZyB0bw0KDQogICByZXF1ZXN0IG5l dyBvbmVzLiAgSXQgc3VwcG9ydHMgYm90aCBhbHRlcm5hdGl2ZXMgKGFuZCBhbnkNCg0KICAgY29t YmluYXRpb24pLg0KDQoNCg0KICAgSXQgaXMgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyBzcGVj aWZpY2F0aW9uIHRvIGRlZmluZSBob3cgdGhlIGhvc3QNCg0KICAgcmVxdWVzdHMgYSBzcGVjaWZp YyB0eXBlIG9mIHByZWZpeCBhbmQgaG93IHRoZSBuZXR3b3JrIGluZGljYXRlcyB0aGUNCg0KICAg dHlwZSBvZiBwcmVmaXggaW4gaXRzIGFkdmVydGlzZW1lbnQgb3IgaW4gaXRzIHJlcGx5IHRvIGEg cmVxdWVzdCkuDQoNCg0KDQogICBUaGUgZm9sbG93aW5nIGFyZSBtYXR0ZXJzIG9mIHBvbGljeSwg d2hpY2ggbWF5IGJlIGRpY3RhdGVkIGJ5IHRoZQ0KDQogICBob3N0IGl0c2VsZiwgdGhlIG5ldHdv cmsgb3BlcmF0b3IsIG9yIHRoZSBzeXN0ZW0gYXJjaGl0ZWN0dXJlDQoNCiAgIHN0YW5kYXJkOg0K DQoNCg0KWWVnaW4sIGV0IGFsLiAgICAgICAgICAgRXhwaXJlcyBKYW51YXJ5IDI3LCAyMDE5ICAg ICAgICAgICAgICAgIFtQYWdlIDZdDQoNCg0KDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICBP biBEZW1hbmQgTW9iaWxpdHkgICAgICAgICAgICAgICAgICBKdWx5IDIwMTgNCg0KDQoNCiAgIC0g VGhlIGluaXRpYWwgc2V0IG9mIElQIGFkZHJlc3NlcyBjb25maWd1cmVkIG9uIHRoZSBob3N0IGF0 IGJvb3QNCg0KICAgdGltZS4NCg0KDQoNCiAgIC0gUGVybWlzc2lvbiB0byBncmFudCB2YXJpb3Vz IHR5cGVzIG9mIElQIGFkZHJlc3NlcyB0byBhIHJlcXVlc3RpbmcNCg0KICAgYXBwbGljYXRpb24u DQoNCg0KDQogICAtIERldGVybWluYXRpb24gb2YgYSBkZWZhdWx0IGFkZHJlc3MgdHlwZSB3aGVu IGFuIGFwcGxpY2F0aW9uIGRvZXMNCg0KICAgbm90IG1ha2UgYW55IGV4cGxpY2l0IGluZGljYXRp b24sIHdoZXRoZXIgaXQgYWxyZWFkeSBzdXBwb3J0cyB0aGUNCg0KICAgcmVxdWlyZWQgQVBJIG9y IGl0IGlzIGp1c3QgYSBsZWdhY3kgYXBwbGljYXRpb24uDQoNCg0KDQozLjQuICBDb252ZXlpbmcg dGhlIERlc2lyZWQgQWRkcmVzcyBUeXBlDQoNCg0KDQogICBbUkZDNTAxNF0gaW50cm9kdWNlZCB0 aGUgYWJpbGl0eSBvZiBhcHBsaWNhdGlvbnMgdG8gaW5mbHVlbmNlIHRoZQ0KDQogICBzb3VyY2Ug YWRkcmVzcyBzZWxlY3Rpb24gd2l0aCB0aGUgSVBWNl9BRERSX1BSRUZFUkVOQ0Ugb3B0aW9uIGF0 IHRoZQ0KDQogICBJUFBST1RPX0lQVjYgbGV2ZWwuICBUaGlzIG9wdGlvbiBpcyB1c2VkIHdpdGgg c2V0c29ja29wdCgpIGFuZA0KDQogICBnZXRzb2Nrb3B0KCkgY2FsbHMgdG8gc2V0L2dldCBhZGRy ZXNzIHNlbGVjdGlvbiBwcmVmZXJlbmNlcy4NCg0KDQoNCiAgIEV4dGVuZGluZyB0aGlzIGZ1cnRo ZXIgYnkgYWRkaW5nIG1vcmUgZmxhZ3MgZG9lcyBub3Qgd29yayB3aGVuIGENCg0KICAgcmVxdWVz dCBmb3IgYW4gYWRkcmVzcyBvZiBhIGNlcnRhaW4gdHlwZSByZXN1bHRzIGluIHJlcXVpcmluZyB0 aGUgSVANCg0KICAgc3RhY2sgdG8gd2FpdCBmb3IgdGhlIG5ldHdvcmsgdG8gcHJvdmlkZSB0aGUg ZGVzaXJlZCBzb3VyY2UgSVAgcHJlZml4DQoNCiAgIGFuZCBoZW5jZSBjYXVzaW5nIHRoZSBzZXRz b2Nrb3B0KCkgY2FsbCB0byBibG9jayB1bnRpbCB0aGUgcHJlZml4IGlzDQoNCiAgIGFsbG9jYXRl ZCAob3IgYW4gZXJyb3IgaW5kaWNhdGlvbiBmcm9tIHRoZSBuZXR3b3JrIGlzIHJlY2VpdmVkKS4N Cg0KDQoNCjxtZ2x0Pg0KDQpPbmUgdGhpbmcgaXMgdGhlIHZhbHVlIG9mIHRoZSBmbGFncywgYW5v dGhlciB0aGluZyBpcyB0aGUgYmVoYXZpb3VyIG9mIHRoZSBBUEkuIFNvIEkgdW5kZXJzdGFuZCB0 aGF0IHRoZSBuZXcgQVBJIHByb3ZpZGVzIG1vcmUgZmxleGliaWxpdHkgaW4gdGhlIHNlbnNlIHRo YXQgYSByZXF1aXJlbWVudCB0aGF0IGNhbm5vdCBiZSBmdWxmaWxsZWQgZG9lcyBub3QgbmVjZXNz YXJpbHkgZW5kIHVwIGluIGFuIGVycm9yLiBJbnN0ZWFkIGl0IGNhbiBsZWFkIGluIGFuIElQIGFk ZHJlc3MgdGhhdCBkb2VzIG5vdCBmdWxmaWxsIHRoZSBhcHBsaWNhdGlvbiByZXF1aXJlbWVudC4g SWYgdGhhdCBpcyBjb3JyZWN0LCB0aGlzIGlzIHN0aWxsIHNvbWV0aGluZyB0aGUgYXBwbGljYXRp b24gd2lsbCBoYXZlIHRvIGRlYWwgd2l0aC4gSU4gb25lIGNhc2UsIGl0IHdpbGwgbmVlZCB0byBk ZWFsIHdpdGggYW4gZXJyb3IsIGluIHRoZSBvdGhlciBjYXNlLCB3aXRoIHNvbWV0aGluZyB0aGF0 IGRvZXMgbm90IGZ1bGZpbGwgdGhlIHJlcXVpcmVtZW50cy4gSWYgdGhhdCBpcyBjb3JyZWN0LCBJ IGJlbGlldmUgdGhlIGJlbmVmaXQgb2YgaXQgc2hvdWxkIGJlIGhpZ2hsaWdodGVkLg0KDQo8L21n bHQ+DQoNCg0KDQogICBBbHRlcm5hdGl2ZWx5IGEgbmV3IHNvY2tldCBBUEkgaXMgZGVmaW5lZCAt IGdldHNjKCkgd2hpY2ggYWxsb3dzDQoNCiAgIGFwcGxpY2F0aW9ucyB0byBleHByZXNzIHRoZWly IGRlc2lyZWQgdHlwZSBvZiBzZXNzaW9uIGNvbnRpbnVpdHkNCg0KICAgc2VydmljZS4gIFRoZSBu ZXcgZ2V0c2MoKSBBUEkgd2lsbCByZXR1cm4gYW4gSVB2NiBhZGRyZXNzIHRoYXQgaXMNCg0KICAg YXNzb2NpYXRlZCB3aXRoIHRoZSBkZXNpcmVkIHNlc3Npb24gY29udGludWl0eSBzZXJ2aWNlIGFu ZCB3aXRoDQoNCiAgIHN0YXR1cyBpbmZvcm1hdGlvbiBpbmRpY2F0aW5nIHdoZXRoZXIgb3Igbm90 IHRoZSBkZXNpcmVkIHNlcnZpY2Ugd2FzDQoNCiAgIHByb3ZpZGVkLg0KDQoNCg0KICAgQW4gYXBw bGljYXRpb24gdGhhdCB3aXNoZXMgdG8gc2VjdXJlIGEgZGVzaXJlZCBzZXJ2aWNlIHdpbGwgY2Fs bA0KDQogICBnZXRzYygpIHdpdGggdGhlIHNlcnZpY2UgdHlwZSBkZWZpbml0aW9uIGFuZCBhIHBs YWNlIHRvIGNvbnRhaW4gdGhlDQoNCiAgIHByb3ZpZGVkIElQIGFkZHJlc3MsIGFuZCBjYWxsIGJp bmQoKSB0byBhc3NvY2lhdGUgdGhhdCBJUCBhZGRyZXNzDQoNCiAgIHdpdGggdGhlIHNvY2tldCAo U2VlIHBzZXVkby1jb2RlIGV4YW1wbGUgaW4gU2VjdGlvbiA0IGJlbG93KS4NCg0KDQoNCiAgIFdo ZW4gdGhlIElQIHN0YWNrIGlzIHJlcXVpcmVkIHRvIHVzZSBhIHNvdXJjZSBJUCBhZGRyZXNzIG9m IGENCg0KICAgc3BlY2lmaWVkIHR5cGUsIGl0IGNhbiB1c2UgYW4gZXhpc3RpbmcgYWRkcmVzcywg b3IgcmVxdWVzdCBhIG5ldyBJUA0KDQogICBwcmVmaXggKG9mIHRoZSBzYW1lIHR5cGUpIGZyb20g dGhlIG5ldHdvcmsgYW5kIGNyZWF0ZSBhIG5ldyBvbmUuICBJZg0KDQogICB0aGUgaG9zdCBkb2Vz IG5vdCBhbHJlYWR5IGhhdmUgYW4gSVB2NiBwcmVmaXggb2YgdGhhdCBzcGVjaWZpYyB0eXBlLA0K DQogICBpdCBNVVNUIHJlcXVlc3Qgb25lIGZyb20gdGhlIG5ldHdvcmsuDQoNCg0KDQogICBVc2lu ZyBhbiBleGlzdGluZyBhZGRyZXNzIGZyb20gYW4gZXhpc3RpbmcgcHJlZml4IGlzIGZhc3RlciBi dXQgbWlnaHQNCg0KICAgeWllbGQgYSBsZXNzIG9wdGltYWwgcm91dGUgKGlmIGEgaGFuZC1vZmYg ZXZlbnQgb2NjdXJyZWQgYWZ0ZXIgaXRzDQoNCiAgIGNvbmZpZ3VyYXRpb24pLiAgT24gdGhlIG90 aGVyIGhhbmQsIGFjcXVpcmluZyBhIG5ldyBJUCBwcmVmaXggZnJvbQ0KDQogICB0aGUgbmV0d29y ayBtYXkgYmUgc2xvd2VyIGR1ZSB0byBzaWduYWxpbmcgZXhjaGFuZ2Ugd2l0aCB0aGUgbmV0d29y ay4NCg0KDQoNCiAgIEFwcGxpY2F0aW9ucyBjYW4gY29udHJvbCB0aGUgc3RhY2sncyBvcGVyYXRp b24gYnkgc2V0dGluZyBhIG5ldyBmbGFnDQoNCiAgIC0gT05fTkVUIGZsYWcgLSB3aGljaCBkaXJl Y3RzIHRoZSBJUCBzdGFjayB3aGV0aGVyIHRvIHVzZSBhDQoNCg0KDQpZZWdpbiwgZXQgYWwuICAg ICAgICAgICBFeHBpcmVzIEphbnVhcnkgMjcsIDIwMTkgICAgICAgICAgICAgICAgW1BhZ2UgN10N Cg0KDQoNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgIE9uIERlbWFuZCBNb2JpbGl0eSAgICAg ICAgICAgICAgICAgIEp1bHkgMjAxOA0KDQoNCg0KICAgcHJlY29uZmlndXJlZCBzb3VyY2UgSVAg YWRkcmVzcyAoaWYgZXhpc3RzKSBvciB0byByZXF1ZXN0IGEgbmV3IElQdjYNCg0KICAgcHJlZml4 IGZyb20gdGhlIGN1cnJlbnQgc2VydmluZyBuZXR3b3JrIGFuZCBjb25maWd1cmUgYSBuZXcgSVAN Cg0KICAgYWRkcmVzcy4NCg0KDQoNCiAgIFRoaXMgbmV3IGZsYWcgaXMgYWRkZWQgdG8gdGhlIHNl dCBvZiBmbGFncyBpbiB0aGUNCg0KICAgSVBWNl9BRERSX1BSRUZFUkVOQ0VTIG9wdGlvbiBhdCB0 aGUgSVBQUk9UT19JUFY2IGxldmVsLiAgSXQgaXMgdXNlZA0KDQogICBpbiBzZXRzb2Nrb3B0KCkg dG8gc2V0IHRoZSBkZXNpcmVkIGJlaGF2aW9yLg0KDQoNCg0KPG1nbHQ+DQoNCk15IHVuZGVyc3Rh bmRpbmcgb2YgdGhlIGZsYWcgaXMgdGhhdCBpdCBmb3JjZXMgdGhlIE9TIHRvIHJlcXVlc3QgdGhl IG5ldHdvcmsuIFRoaXMgbWVhbnMgdGhhdCBldmVuIGlmIGl0IGFscmVhZHkgaGFzIHRlaCBkZXNp cmVkIElQIGFkZHJlc3MgdGhlIE9OX05FVCBmbGFnIHNldCB3aWxsIGZvcmNlIHRoZSBPUyB0byBy ZS1hc2suIFdoZW4gdW5zZXQsIHRoZSBkZWNpc2lvbiB0byByZS1hc2sgb3Igbm90IGlzIGxldCB0 byB0aGUgT1MuIElTIHRoYXQgY29ycmVjdCA/DQoNCjwvbWdsdD4NCg0KDQoNCjQuICBVc2FnZSBl eGFtcGxlDQoNCg0KDQo0LjEuICBQc2V1ZG8tY29kZSBleGFtcGxlDQoNCg0KDQo8bWdsdD4NCg0K SXQgd291bGQgYmUgZ29vZCB0aGUgZXhhbXBsZSBhbHNvIHNob3dzIHRoZSBPTl9ORVQgZmxhZy4N Cg0KPC9tZ2x0Pg0KDQoNCg0KICAgVGhlIGZvbGxvd2luZyBleGFtcGxlIHNob3dzIHBzZXVkby1j b2RlIGZvciBjcmVhdGluZyBhIFN0cmVhbSBzb2NrZXQNCg0KICAgKFRDUCkgd2l0aCBhIFNlc3Np b24tTGFzdGluZyBzb3VyY2UgSVAgYWRkcmVzczoNCg0KDQoNCiAgICNpbmNsdWRlIDxzeXMvc29j a2V0Lmg+DQoNCiAgICNpbmNsdWRlIDxuZXRpbm5ldC9pbi5oPg0KDQoNCg0KICAgICAvLyBTb2Nr ZXQgaW5mb3JtYXRpb24NCg0KICAgaW50ICAgICAgICAgICAgICBzIDsgICAgICAgICAgICAvLyBz b2NrZXQgaWQNCg0KDQoNCiAgICAgLy8gU291cmNlIGluZm9ybWF0aW9uIChmb3Igc2Vjc2MoKSBh bmQgYmluZCgpKQ0KDQogICBzb2NrYWRkcl9pbjYgICAgIHNvdXJjZUluZm8gICAgIC8vIG15IGFk ZHJlc3MgYW5kIHBvcnQgZm9yIGJpbmQoKQ0KDQogICBpbjZfYWRkciAgICAgICAgIHNvdXJjZUFk ZHJlc3MgIC8vIHdpbGwgY29udGFpbiB0aGUgcHJvdmlzaW9uZWQNCg0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAvLyBzb3VyY2UgSVAgYWRkcmVzcw0KDQogICB1aW50OF90ICAg ICAgICAgIHNjX3R5cGUgPSBJUFY2X1JFUVVJUkVfU0VTU0lPTl9MQVNUSU5HX0lQIDsNCg0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAvLyBGb3IgcmVxdWVzdGluZyBhIFNlc3Np b24tTGFzdGluZw0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC8vIHNvdXJj ZSBJUCBhZGRyZXNzDQoNCg0KDQogICAgIC8vIERlc3RpbmF0aW9uIGluZm9ybWF0aW9uIChmb3Ig Y29ubmVjdCgpKQ0KDQogICBzb2NrYWRkcl9pbjYgICAgIHNlcnZlckluZm8gOyAgIC8vIHNlcnZl ciBpbmZvIGZvciBjb25uZWN0KCkNCg0KDQoNCiAgICAgLy8gQ3JlYXRlIGFuIElQdjYgVENQIHNv Y2tldA0KDQogICBzID0gc29ja2V0KEFGX0lORVQ2LCBTT0NLX1NUUkVBTSwgMCkgOw0KDQogICBp ZiAocyE9MCkgew0KDQogICAgICAgICAvLyBIYW5kbGUgc29ja2V0IGNyZWF0aW9uIGVycm9yDQoN CiAgICAgICAgIC8vIC4uLg0KDQogICB9IC8vIGlmIHNvY2tldCBjcmVhdGlvbiBmYWlsZWQNCg0K ICAgZWxzZSB7DQoNCiAgICAgICAgICAvLyBTb2NrZXQgY3JlYXRpb24gaXMgc3VjY2Vzc2Z1bA0K DQogICAgICAgICAgLy8gVGhlIGFwcGxpY2F0aW9uIGNhbm5vdCBjb25uZWN0IHlldCwgc2luY2Ug aXQgd2FudHMgdG8gdXNlDQoNCiAgICAgICAgICAvLyBhIFNlc3Npb24tTGFzdGluZyBzb3VyY2Ug SVAgYWRkcmVzcyBJdCBuZWVkcyB0byByZXF1ZXN0DQoNCiAgICAgICAgICAvLyB0aGUgU2Vzc2lv bi1MYXN0aW5nIHNvdXJjZSBJUCBiZWZvcmUgY29ubmVjdGluZw0KDQogICAgICAgIGlmIChzZXRz YyhzLCAmc291cmNlQWRkcmVzcywgJnNjX3R5cGUpKSA9PSAwKXsNCg0KICAgICAgICAgICAgIC8v IHNldHRpbmcgc2Vzc2lvbiBjb250aW51aXR5IHRvIFNlc3Npb24gTGFzdGluZyBpcw0KDQogICAg ICAgICAgICAgLy8gU3VjY2Vzc2Z1bC4gc291cmNlQWRkcmVzcyBub3cgY29udGFpbnMgdGhlIFNl c3Npb24tDQoNCiAgICAgICAgICAgICAvLyBMQXN0aW5nIHNvdXJjZSBJUCBhZGRyZXNzIDxtZ2x0 PnMvTEFzdGluZy9MYXN0aW5nL2djPC9tZ2x0Pg0KDQoNCg0KWWVnaW4sIGV0IGFsLiAgICAgICAg ICAgRXhwaXJlcyBKYW51YXJ5IDI3LCAyMDE5ICAgICAgICAgICAgICAgIFtQYWdlIDhdDQoNCg0K DQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICBPbiBEZW1hbmQgTW9iaWxpdHkgICAgICAgICAg ICAgICAgICBKdWx5IDIwMTgNCg0KDQoNCiAgICAgICAgICAgICAvLyBCaW5kIHRvIHRoYXQgc291 cmNlIElQIGFkZHJlc3MNCg0KICAgICAgICAgICBzb3VyY2VJbmZvLnNpbjZfZmFtaWx5ID0gQUZf SU5FVDYgOw0KDQogICAgICAgICAgIHNvdXJjZUluZm8uc2luNl9wb3J0ID0gMCAgLy8gbGV0IHRo ZSBzdGFjayBjaG9vc2UgdGhlIHBvcnQNCg0KICAgICAgICAgICBzb3VyY2VJbmZvLnNpbjZfYWRk cmVzcyA9IHNvdXJjZUFkZHJlc3MgOw0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIC8vIFVzZSB0aGUgc291cmNlIGFkZHJlc3MgdGhhdCB3YXMNCg0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAvLyBnZW5lcmF0ZWQgYnkgdGhlIHNldHNjKCkgY2FsbA0KDQog ICAgICAgICAgIGlmIChiaW5kKHMsICZzb3VyY2VJbmZvLCBzaXplb2Yoc291cmNlSW5mbykpPT0w KXsNCg0KICAgICAgICAgICAgICAgIC8vIFNldCB0aGUgZGVzaXJlZCBzZXJ2ZXIncyBpbmZvcm1h dGlvbiBmb3IgY29ubmVjdCgpDQoNCiAgICAgICAgICAgICAgc2VydmVySW5mby5zaW42X2ZhbWls eSA9IEFGX0lORVQ2IDsNCg0KICAgICAgICAgICAgICBzZXJ2ZXJJbmZvLnNpbjZfcG9ydCA9IFNF UlZFUl9QT1JUX05VTSA7DQoNCiAgICAgICAgICAgICAgc2VydmVyQWRkcmVzcy5zaW42X2FkZHIg PSBTRVJWRVJfSVBWNl9BRERSRVNTIDsNCg0KDQoNCiAgICAgICAgICAgICAgICAvLyBDb25uZWN0 IHRvIHRoZSBzZXJ2ZXINCg0KICAgICAgICAgICAgICBpZiAoY29ubmVjdChzLCAmc2VydmVySW5m bywgc2l6ZW9mKHNlcnZlckluZm8pKT09MCkgew0KDQogICAgICAgICAgICAgICAgICAvLyBjb25u ZWN0IHN1Y2Nlc3NmdWwgKDMtd2F5IGhhbmRzaGFrZSBoYXMgYmVlbg0KDQogICAgICAgICAgICAg ICAgICAvLyBjb21wbGV0ZWQgd2l0aCBTZXNzaW9uLUxhc3Rpbmcgc291cmNlIGFkZHJlc3MuDQoN CiAgICAgICAgICAgICAgICAgIC8vIENvbnRpbnVlIGFwcGxpY2F0aW9uIGZ1bmN0aW9uYWxpdHkN Cg0KICAgICAgICAgICAgICAgICAgLy8gLi4uDQoNCiAgICAgICAgICAgICAgfSAgLy8gaWYgY29u bmVjdCgpIGlzIHN1Y2Nlc3NmdWwNCg0KICAgICAgICAgICAgICBlbHNlIHsNCg0KICAgICAgICAg ICAgICAgICAgLy8gY29ubmVjdCBmYWlsZWQNCg0KICAgICAgICAgICAgICAgICAgLy8gLi4uDQoN CiAgICAgICAgICAgICAgICAgIC8vIEFwcGxpY2F0aW9uIGNvZGUgdGhhdCBoYW5kbGVzIGNvbm5l Y3QgZmFpbHVyZSBhbmQNCg0KICAgICAgICAgICAgICAgICAgLy8gY2xvc2VzIHRoZSBzb2NrZXQN Cg0KICAgICAgICAgICAgICAgICAgLy8gLi4uDQoNCiAgICAgICAgICAgICAgfSAvLyBpZiBjb25u ZWN0KCkgZmFpbGVkDQoNCiAgICAgICAgICAgfSAvLyBpZiBiaW5kKCkgc3VjY2Vzc2Z1bA0KDQog ICAgICAgICAgIGVsc2Ugew0KDQogICAgICAgICAgICAgICAgICAvLyBiaW5kKCkgZmFpbGVkDQoN CiAgICAgICAgICAgICAgICAgIC8vIC4uLg0KDQogICAgICAgICAgICAgICAgICAvLyBBcHBsaWNh dGlvbiBjb2RlIHRoYXQgaGFuZGxlcyBiaW5kIGZhaWx1cmUgYW5kDQoNCiAgICAgICAgICAgICAg ICAgIC8vIGNsb3NlcyB0aGUgc29ja2V0DQoNCiAgICAgICAgICAgICAgICAgIC8vIC4uLg0KDQog ICAgICAgICAgIH0gLy8gaWYgYmluZCgpIGZhaWxlZA0KDQogICAgICAgIH0gIC8vIGlmIHNldHNj KCkgd2FzIHN1Y2Nlc3NmdWwgYW5kIG9mIGEgU2Vzc2lvbi1MYXN0aW5nDQoNCiAgICAgICAgICAg Ly8gc291cmNlIElQIGFkZHJlc3Mgd2FzIHByb3ZpZGVkDQoNCiAgICAgICAgZWxzZSB7DQoNCiAg ICAgICAgICAgICAvLyBhcHBsaWNhdGlvbiBjb2RlIHRoYXQgZG9lcyBub3QgdXNlIFNlc3Npb24t bGFzdGluZyBJUA0KDQogICAgICAgICAgICAgLy8gYWRkcmVzcy4gVGhlIGFwcGxpY2F0aW9uIG1h eSBlaXRoZXIgY29ubmVjdCB3aXRob3V0DQoNCiAgICAgICAgICAgICAvLyB0aGUgZGVzaXJlZCBT ZXNzaW9uLWxhc3Rpbmcgc2VydmljZSwgb3IgY2xvc2UgdGhlDQoNCiAgICAgICAgICAgICAvLyBz b2NrZXQuLi4NCg0KICAgICAgICB9IC8vIGlmIHNldHNjKCkgZmFpbGVkDQoNCiAgIH0gIC8vIGlm IHNvY2tldCB3YXMgY3JlYXRlZCBzdWNjZXNzZnVsbHkNCg0KDQoNCiAgICAgLy8gVGhlIHJlc3Qg b2YgdGhlIGFwcGxpY2F0aW9uJ3MgY29kZQ0KDQogICAgIC8vIC4uLg0KDQoNCg0KWWVnaW4sIGV0 IGFsLiAgICAgICAgICAgRXhwaXJlcyBKYW51YXJ5IDI3LCAyMDE5ICAgICAgICAgICAgICAgIFtQ YWdlIDldDQoNCg0KDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICBPbiBEZW1hbmQgTW9iaWxp dHkgICAgICAgICAgICAgICAgICBKdWx5IDIwMTgNCg0KDQoNCjQuMi4gIE1lc3NhZ2UgRmxvdyBl eGFtcGxlDQoNCg0KDQogICBUaGUgZm9sbG93aW5nIG1lc3NhZ2UgZmxvdyBpbGx1c3RyYXRlcyBh IHBvc3NpYmxlIGludGVyYWN0aW9uIGZvcg0KDQogICBhY2hpZXZpbmcgT25EZW1hbmQgZnVuY3Rp b25hbGl0eS4gIEl0IGlzIGFuIGV4YW1wbGUgb2Ygb25lIHNjZW5hcmlvDQoNCiAgIGFuZCBzaG91 bGQgbm90IGJlIHJlZ2FyZGVkIGFzIHRoZSBvbmx5IHNjZW5hcmlvIG9yIHRoZSBwcmVmZXJyZWQg b25lLg0KDQoNCg0KPG1nbHQ+T25EZW1hbmQgdmVyc3VzIE9uIERlbWFuZCB2ZXJzdXMgT24tRGVt YW5kLiBUaGUgdGV4dCBzaG91bGQgYmUgY29uc2lzdGVudC4gPC9tZ2x0Pg0KDQogICBUaGlzIGZs b3cgZGVzY3JpYmVzIHRoZSBpbnRlcmFjdGlvbiBiZXR3ZWVuIHRoZSBmb2xsb3dpbmcgZW50aXRp ZXM6DQoNCg0KDQogICAtIEFwcGxpY2F0aW9ucyByZXF1aXJpbmcgZGlmZmVyZW50IHR5cGVzIG9m IE9uRGVtYW5kIHNlcnZpY2UuDQoNCg0KDQogICAtIFRoZSBtb2JpbGUgaG9zdCdzIElQIHN0YWNr Lg0KDQoNCg0KICAgLSBUaGUgbmV0d29yayBpbmZyYXN0cnVjdHVyZSBwcm92aWRpbmcgdGhlIHNl cnZpY2VzLg0KDQoNCg0KICAgSW4gdGhpcyBleGFtcGxlLCB0aGUgbmV0d29yayBpbmZyYXN0cnVj dHVyZSBwcm92aWRlcyAyIElQdjYgcHJlZml4ZXMNCg0KICAgdXBvbiBhdHRhY2htZW50IG9mIHRo ZSBtb2JpbGUgaG9zdCB0byB0aGUgbmV0d29yazogQSBTZXNzaW9uLWxhc3RpbmcNCg0KICAgSVB2 NiBwcmVmaXggYW5kIGEgTm9uLXBlcnNpc3RlbnQgSVB2NiBwcmVmaXguICBXaGVuZXZlciB0aGUg bW9iaWxlDQoNCiAgIGhvc3QgbW92ZXMgdG8gYSBkaWZmZXJlbnQgcG9pbnQtb2YtYXR0YWNobWVu dCwgdGhlIG5ldHdvcmsNCg0KICAgaW5mcmFzdHJ1Y3R1cmUgcHJvdmlkZXMgYSBuZXcgTm9uLXBl cnNpc3RlbnQgSVB2NiBhZGRyZXNzLg0KDQoNCg0KICAgSW4gdGhpcyBleGFtcGxlLCB0aGUgbmV0 d29yayBpbmZyYXN0cnVjdHVyZSBkb2VzIG5vdCBzdXBwb3J0IEZpeGVkIElQDQoNCiAgIGFkZHJl c3NlcyBub3IgR3JhY2VmdWwtcmVwbGFjZW1lbnQgSVAgYWRkcmVzc2VzLg0KDQoNCg0KICAgV2hl bmV2ZXIgYW4gYXBwbGljYXRpb24gb3BlbnMgYW4gSVAgc29ja2V0IGFuZCByZXF1ZXN0cyBhIHNw ZWNpZmljDQoNCiAgIElQdjYgYWRkcmVzcyB0eXBlLCB0aGUgSVAgc3RhY2sgd2lsbCBwcm92aWRl IG9uZSBmcm9tIGl0cyBhdmFpbGFibGUNCg0KICAgSVB2NiBwcmVmaXhlcyBvciByZXR1cm4gYW4g ZXJyb3IgbWVzc2FnZSBpZiB0aGUgcmVxdWVzdCBjYW5ub3QgYmUNCg0KICAgZnVsZmlsbGVkLg0K DQoNCg0KICAgTWVzc2FnZSBGbG93Og0KDQoNCg0KICAgLSBUaGUgbW9iaWxlIGRldmljZSBhdHRh Y2hlcyB0byB0aGUgbmV0d29yay4NCg0KDQoNCiAgIC0gVGhlIE5ldHdvcmsgcHJvdmlkZXMgdHdv IElQdjYgcHJlZml4ZXM6IFBSRUZzbDEgLSBhIFNlc3Npb24tbGFzdGluZw0KDQogICBJUHY2IHBy ZWZpeCBhbmQgUFJFRm5wMSAtIGEgTm9uLXBlcnNpc3RlbnQgSVAgdjYgcHJlZml4Lg0KDQoNCg0K PG1nbHQ+SVAgdjYvSVB2Ni9nYzwvbWdsdD4NCg0KPG1nbHQ+SXQgd291bGQgZWFzZSB0aGUgcmVh ZGluZyBpZiB0aGUgbWVjaGFuaXNtIHVzZWQgdG8gc3BlY2lmeSB0aGUgVHlwZSBvZiB0aGUgYWRk cmVzcyBieSB0aGUgb3BlcmF0b3IgdG8gdGhlIGhvc3QgYmVpbmcgZGVzY3JpYmVkIC0gYXQgbGVh c3QgYW4gZXhhbXBsZS4NCg0KPC9tZ2x0Pg0KDQoNCg0KICAgLSBBbiBhcHBsaWNhdGlvbiBvbiB0 aGUgbW9iaWxlIGhvc3QgaXMgbGF1bmNoZWQuICBJdCBvcGVucyBhbiBJUA0KDQogICBzb2NrZXQg YW5kIHJlcXVlc3RzIGEgTm9uLXBlcnNpc3RlbnQgSVB2NiBhZGRyZXNzLg0KDQoNCg0KICAgLSBU aGUgSVAgc3RhY2sgcHJvdmlkZXMgSVBucDEgd2hpY2ggaXMgZ2VuZXJhdGVkIGZyb20gUFJFRm5w MS4NCg0KDQoNCiAgIC0gQW5vdGhlciBhcHBsaWNhdGlvbiBpcyBsYXVuY2hlZCwgcmVxdWVzdGlu ZyBhIE5vbi1wZXJzaXN0ZW50IElQdjYNCg0KICAgYWRkcmVzcy4NCg0KDQoNCiAgIC0gVGhlIElQ IHN0YWNrIHByb3ZpZGVzIElQbnAxIGFnYWluLg0KDQoNCg0KICAgLSBBIHRoaXJkIGFwcGxpY2F0 aW9uIGlzIGxhdW5jaGVkLiAgVGhpcyB0aW1lLCBpdCByZXF1aXJlcyBhIFNlc3Npb24tDQoNCiAg IGxhc3RpbmcgSVB2NiBhZGRyZXNzLg0KDQoNCg0KPG1nbHQ+c2Vjb25kID88L21nbHQ+DQoNCg0K DQpZZWdpbiwgZXQgYWwuICAgICAgICAgICBFeHBpcmVzIEphbnVhcnkgMjcsIDIwMTkgICAgICAg ICAgICAgICBbUGFnZSAxMF0NCg0KDQoNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgIE9uIERl bWFuZCBNb2JpbGl0eSAgICAgICAgICAgICAgICAgIEp1bHkgMjAxOA0KDQoNCg0KICAgLSBUaGUg SVAgc3RhY2sgcHJvdmlkZXMgSVBzbDEgd2hpY2ggaXMgZ2VuZXJhdGVkIGZyb20gUFJFRnNsMS4N Cg0KDQoNCiAgIC0gVGhlIG1vYmlsZSBob3N0cyBtb3ZlcyB0byBhIG5ldyBwb2ludC1vZi1hdHRh Y2htZW50Lg0KDQoNCg0KICAgLSBUaGUgbmV0d29yayBwcm92aWRlcyBhIG5ldyBOb24tcGVyc2lz dGVudCBJUHY2IHByZWZpeCAtIFBSRUZucDIuDQoNCiAgIFBSRUZucDEgaXMgbm8gbG9uZ2VyIHZh bGlkLg0KDQoNCg0KICAgLSBUaGUgYXBwbGljYXRpb25zIHRoYXQgd2VyZSBnaXZlbiBJUG5wMSBy ZS1lc3RhYmxpc2ggdGhlIHNvY2tldCBhbmQNCg0KICAgcmVjZWl2ZSBhIG5ldyBJUHY2IGFkZHJl c3MgLSBJUG5wMiB3aGljaCBpcyBnZW5lcmF0ZWQgZnJvbSBQUkVGbnAyDQoNCg0KDQogICAtIFRo ZSBhcHBsaWNhdGlvbiB0aGF0IGlzIHVzaW5nIElQc2wxIGNhbiBzdGlsbCB1c2UgaXQgc2luY2Ug dGhlDQoNCiAgIG5ldHdvcmsgZ3VhcmFudGVlZCB0aGF0IFBSRUZzbDEgd2lsbCBiZSB2YWxpZCBl dmVuIGFmdGVyIG1vdmluZyB0byBhDQoNCiAgIG5ldyBwb2ludC1vZi1hdHRhY2htZW50Lg0KDQoN Cg0KICAgLSBBIG5ldyBhcHBsaWNhdGlvbiBpcyBsYXVuY2hlZCwgdGhpcyB0aW1lIHJlcXVpcmlu ZyBhIEdyYWNlZnVsLQ0KDQogICByZXBsYWNlbWVudCBJUHY2IGFkZHJlc3MuDQoNCg0KDQogICAt IFRoZSBJUCBzdGFjayByZXR1cm5zIHNldHNjKCkgd2l0aCBhbiBlcnJvciBzaW5jZSB0aGUgbmV0 d29yayBkb2VzDQoNCiAgIG5vdCBzdXBwb3J0IHRoaXMgc2VydmljZS4NCg0KDQoNCiAgLSBUaGUg YXBwbGljYXRpb24gcmUtYXR0ZW1wdHMgdG8gb3BlbiBhIHNvY2tldCwgdGhpcyB0aW1lIHJlcXVl c3RpbmcNCg0KICAgYSBTZXNzaW9uLWxhc3RpbmcgSVB2NiBhZGRyZXNzLg0KDQoNCg0KICAgLSBU aGUgSVAgc3RhY2sgcHJvdmlkZXMgSVBzbDEuDQoNCg0KDQo1LiAgQmFja3dhcmRzIENvbXBhdGli aWxpdHkgQ29uc2lkZXJhdGlvbnMNCg0KDQoNCiAgIEJhY2t3YXJkcyBjb21wYXRpYmlsaXR5IHN1 cHBvcnQgaXMgUkVRVUlSRUQgYnkgdGhlIGZvbGxvd2luZyAzIHR5cGVzDQoNCiAgIG9mIGVudGl0 aWVzOg0KDQoNCg0KICAgLSBUaGUgQXBwbGljYXRpb25zIG9uIHRoZSBtb2JpbGUgaG9zdA0KDQoN Cg0KICAgLSBUaGUgSVAgc3RhY2sgaW4gdGhlIG1vYmlsZSBob3N0DQoNCg0KDQogICAtIFRoZSBu ZXR3b3JrIGluZnJhc3RydWN0dXJlDQoNCg0KDQo1LjEuICBBcHBsaWNhdGlvbnMNCg0KDQoNCiAg IExlZ2FjeSBhcHBsaWNhdGlvbnMgdGhhdCBkbyBub3Qgc3VwcG9ydCB0aGUgT25EZW1hbmQgZnVu Y3Rpb25hbGl0eQ0KDQogICB3aWxsIHVzZSB0aGUgbGVnYWN5IEFQSSBhbmQgd2lsbCBub3QgYmUg YWJsZSB0byB0YWtlIGFkdmFudGFnZSBvZiB0aGUNCg0KICAgT24tRGVtYW5kIE1vYmlsaXR5IGZl YXR1cmUuDQoNCg0KDQogICBBcHBsaWNhdGlvbnMgdXNpbmcgdGhlIG5ldyBPbkRlbWFuZCBmdW5j dGlvbmFsaXR5IE1VU1QgYmUgYXdhcmUgdGhhdA0KDQogICB0aGV5IG1heSBiZSBleGVjdXRlZCBp biBsZWdhY3kgZW52aXJvbm1lbnRzIHRoYXQgZG8gbm90IHN1cHBvcnQgaXQuDQoNCiAgIFN1Y2gg ZW52aXJvbm1lbnRzIG1heSBpbmNsdWRlIGEgbGVnYWN5IElQIHN0YWNrIG9uIHRoZSBtb2JpbGUg aG9zdCwNCg0KICAgbGVnYWN5IG5ldHdvcmsgaW5mcmFzdHJ1Y3R1cmUsIG9yIGJvdGguICBJbiBl aXRoZXIgY2FzZSwgdGhlIEFQSSB3aWxsDQoNCiAgIHJldHVybiBhbiBlcnJvciBjb2RlIGFuZCB0 aGUgaW52b2tpbmcgYXBwbGljYXRpb25zIG1heSBqdXN0IGdpdmUgdXANCg0KICAgYW5kIHVzZSBs ZWdhY3kgY2FsbHMuDQoNCg0KDQpZZWdpbiwgZXQgYWwuICAgICAgICAgICBFeHBpcmVzIEphbnVh cnkgMjcsIDIwMTkgICAgICAgICAgICAgICBbUGFnZSAxMV0NCg0KDQoNCkludGVybmV0LURyYWZ0 ICAgICAgICAgICAgIE9uIERlbWFuZCBNb2JpbGl0eSAgICAgICAgICAgICAgICAgIEp1bHkgMjAx OA0KDQoNCg0KNS4yLiAgSVAgU3RhY2sgaW4gdGhlIE1vYmlsZSBIb3N0DQoNCg0KDQogICBOZXcg SVAgc3RhY2tzIE1VU1QgY29udGludWUgdG8gc3VwcG9ydCBhbGwgbGVnYWN5IG9wZXJhdGlvbnMu ICBJZiBhbg0KDQogICBhcHBsaWNhdGlvbiBkb2VzIG5vdCB1c2UgT24tRGVtYW5kIGZ1bmN0aW9u YWxpdHksIHRoZSBJUCBzdGFjayBNVVNUDQoNCiAgIHJlc3BvbmQgaW4gYSBsZWdhY3kgbWFubmVy Lg0KDQoNCg0KPG1nbHQ+DQoNClRoZSBsZWdhY3kgbWFubmVyIGRvZXMgbm90IHNlZW1zIHRvIGJl IGEgc3RhbmRhcmQgd2F5IG9mIGJlaGF2aW9yLiBJdCBzZWVtcyB0byBtZSBhcyB0aGUgd2F5IHRo ZSBPUyB1c2VkIHRvIGJlaGF2ZS4gSSBiZWxpZXZlIHRoZSBkcmFmdCBzaG91ZGwgYmUgYSBiaXQg bW9yZSBzcGVjaWZpYyBoZXJlLg0KDQo8L21nbHQ+DQoNCg0KDQogICBJZiB0aGUgbmV0d29yayBp bmZyYXN0cnVjdHVyZSBzdXBwb3J0cyBPbi1EZW1hbmQgZnVuY3Rpb25hbGl0eSwgdGhlDQoNCiAg IElQIHN0YWNrIFNIT1VMRCBmb2xsb3cgdGhlIGFwcGxpY2F0aW9uIHJlcXVlc3Q6IElmIHRoZSBh cHBsaWNhdGlvbg0KDQogICByZXF1ZXN0cyBhIHNwZWNpZmljIGFkZHJlc3MgdHlwZSwgdGhlIHN0 YWNrIFNIT1VMRCBmb3J3YXJkIHRoaXMNCg0KICAgcmVxdWVzdCB0byB0aGUgbmV0d29yay4gIElm IHRoZSBhcHBsaWNhdGlvbiBkb2VzIG5vdCByZXF1ZXN0IGFuDQoNCiAgIGFkZHJlc3MgdHlwZSwg dGhlIElQIHN0YWNrIE1VU1QgTk9UIHJlcXVlc3QgYW4gYWRkcmVzcyB0eXBlIGFuZCBsZWF2ZQ0K DQogICBpdCB0byB0aGUgbmV0d29yaydzIGRlZmF1bHQgYmVoYXZpb3IgdG8gY2hvb3NlIHRoZSB0 eXBlIG9mIHRoZQ0KDQogICBhbGxvY2F0ZWQgSVAgcHJlZml4LiAgSWYgYW4gSVAgcHJlZml4IHdh cyBhbHJlYWR5IGFsbG9jYXRlZCB0byB0aGUNCg0KICAgaG9zdCwgdGhlIElQIHN0YWNrIHVzZXMg aXQgYW5kIG1heSBub3QgcmVxdWVzdCBhIG5ldyBvbmUgZnJvbSB0aGUNCg0KICAgbmV0d29yay4N Cg0KDQoNCjUuMy4gIE5ldHdvcmsgSW5mcmFzdHJ1Y3R1cmUNCg0KDQoNCiAgIFRoZSBuZXR3b3Jr IGluZnJhc3RydWN0dXJlIG1heSBvciBtYXkgbm90IHN1cHBvcnQgdGhlIE9uLURlbWFuZA0KDQog ICBmdW5jdGlvbmFsaXR5LiAgSG93IHRoZSBJUCBzdGFjayBvbiB0aGUgaG9zdCBhbmQgdGhlIG5l dHdvcmsNCg0KICAgaW5mcmFzdHJ1Y3R1cmUgYmVoYXZlIGluIGNhc2Ugb2YgYSBjb21wYXRpYmls aXR5IGlzc3VlIGlzIG91dHNpZGUgdGhlDQoNCiAgIHNjb3BlIG9mIHRoaXMgQVBJIHNwZWNpZmlj YXRpb24uDQoNCg0KDQo8bWdsdD4NCg0KSSBiZWxpZXZlIHRoYXQgc3VjaCBzdGF0ZW1lbnQgc2hv dWxkIGJlIG1hZGUgaW4gdGhlIGludHJvZHVjdGlvbiB3aXRoIHRoZSBhZGRpdGlvbiBvZiBhIGxp c3Qgb2YgcG90ZW50aWFsIG1lY2hhbmlzbSB0byBwcm92aWRlIHRoZSB0eXBlIG9mIElQIGFkZHJl c3NlcyBieSB0aGUgbmV0d29yay4gVGhlcmUgaXMgYSBuZWVkIHRvIGhhdmUgc3VjaCBtZWNoYW5p c21zIHNpbmNlIHRoZSBPUyBjYW5ub3QgZGVyaXZlIHRoZSBwcm9wZXJ0aWVzIGZyb20gdGhlIElQ IGFkZHJlc3MgaXRzZWxmLiBXaGljaCB3YXMgdGVoIGNhc2Ugd2l0aCBIb21lIG9mIGFkZHJlc3Ms IGNhcmUgb2YgYWRkcmVzcywgY2dhLi4uLg0KDQo8L21nbHQ+DQoNCg0KDQo1LjQuICBNZXJnaW5n IHRoaXMgd29yayB3aXRoIFJGQzUwMTQNCg0KDQoNCiAgIFtSRkM1MDE0XSBkZWZpbmVzIG5ldyBm bGFncyB0aGF0IG1heSBiZSB1c2VkIHdpdGggc2V0c29ja29wdCgpIHRvDQoNCiAgIGluZmx1ZW5j ZSBzb3VyY2UgSVAgYWRkcmVzcyBzZWxlY3Rpb24gZm9yIGEgc29ja2V0LiAgVGhlIGxpc3Qgb2YN Cg0KICAgZmxhZ3MgaW5jbHVkZTogc291cmNlIGhvbWUgYWRkcmVzcywgY2FyZS1vZiBhZGRyZXNz LCB0ZW1wb3JhcnkNCg0KICAgYWRkcmVzcywgcHVibGljIGFkZHJlc3MgQ0dBIChDcnlwdG9ncmFw aGljYWxseSBDcmVhdGVkIEFkZHJlc3MpIGFuZA0KDQogICBub24tQ0dBLiAgV2hlbiBhcHBsaWNh dGlvbnMgcmVxdWlyZSBzZXNzaW9uIGNvbnRpbnVpdHkgc2VydmljZSBhbmQNCg0KICAgdXNlIHNl dHNjKCkgYW5kIGJpbmQoKSwgdGhleSBTSE9VTEQgTk9UIHNldCB0aGUgZmxhZ3Mgc3BlY2lmaWVk IGluDQoNCiAgIFtSRkM1MDE0XS4NCg0KDQoNCiAgIEhvd2V2ZXIsIGlmIGFuIGFwcGxpY2F0aW9u IHNldHMgYSBzcGVjaWZpYyBvcHRpb24gdXNpbmcgc2V0c29ja29wdCgpDQoNCiAgIHdpdGggb25l IG9mIHRoZSBmbGFncyBzcGVjaWZpZWQgaW4gW1JGQzUwMTRdIGFuZCBhbHNvIHNlbGVjdHMgYQ0K DQogICBzb3VyY2UgSVAgYWRkcmVzcyB1c2luZyBzZXRzYygpIGFuZCBiaW5kKCkgdGhlIElQIGFk ZHJlc3MgdGhhdCB3YXMNCg0KICAgZ2VuZXJhdGVkIGJ5IHNldHNjKCkgYW5kIGJvdW5kIHVzaW5n IGJpbmQoKSB3aWxsIGJlIHRoZSBvbmUgdXNlZCBieQ0KDQogICB0cmFmZmljIGdlbmVyYXRlZCB1 c2luZyB0aGF0IHNvY2tldCBhbmQgb3B0aW9ucyBzZXQgYnkgc2V0c29ja29wdCgpDQoNCiAgIHdp bGwgYmUgaWdub3JlZC4NCg0KDQoNCjxtZ2x0PlRoZSBzZW50ZW5jZSBhYm92ZSBpcyBoYXJkIHRv IHJlYWQgLSBhdCBsZWFzdCB0byBtZS4gSSBzdXNwZWN0ICJ0aGUiIGlzIG1pc3NpbmcgYWZ0ZXIg ImJ5Ii4gV2hhdCB0aGUgdGV4dCBzYXlzIGlzIHRoYXQgYWZ0ZXIgYmluZCBzZXRzb2Nrb3B0IHdp bGwgYmUgaWdub3JlZC4gQ29ycmVjdCA/DQoNCjwvbWdsdD4NCg0KDQoNCiAgIElmIGJpbmQoKSB3 YXMgbm90IGludm9rZWQgYWZ0ZXIgc2V0c2MoKSBieSB0aGUgYXBwbGljYXRpb24sIHRoZSBJUA0K DQogICBhZGRyZXNzIGdlbmVyYXRlZCBieSBzZXRzYygpIHdpbGwgbm90IGJlIHVzZWQgYW5kIHRy YWZmaWMgZ2VuZXJhdGVkDQoNCiAgIGJ5IHRoZSBzb2NrZXQgd2lsbCB1c2UgYSBzb3VyY2UgSVAg YWRkcmVzcyB0aGF0IGNvbXBsaWVzIHdpdGggdGhlDQoNCiAgIG9wdGlvbnMgc2VsZWN0ZWQgYnkg c2V0c29ja29wdCgpLg0KDQoNCg0KWWVnaW4sIGV0IGFsLiAgICAgICAgICAgRXhwaXJlcyBKYW51 YXJ5IDI3LCAyMDE5ICAgICAgICAgICAgICAgW1BhZ2UgMTJdDQoNCg0KDQpJbnRlcm5ldC1EcmFm dCAgICAgICAgICAgICBPbiBEZW1hbmQgTW9iaWxpdHkgICAgICAgICAgICAgICAgICBKdWx5IDIw MTgNCg0KDQoNCjYuICBTdW1tYXJ5IG9mIE5ldyBEZWZpbml0aW9ucw0KDQoNCg0KPG1nbHQ+DQoN CkZsYWdzIGFuZCBhZGRyZXNzIHR5cGVzIHNob3VsZCBpbiBteSBvcGluaW9uIGJlIHBsYWNlZCBp biBldmlkZW5jZS4gKC5oKSA8L21nbHQ+DQoNCg0KDQo2LjEuICBOZXcgQVBJcw0KDQoNCg0KICAg c2V0c2MoKSBlbmFibGVzIGFwcGxpY2F0aW9ucyB0byByZXF1ZXN0IGEgc3BlY2lmaWMgdHlwZSBv ZiBzb3VyY2UgSVANCg0KICAgYWRkcmVzcyBpbiB0ZXJtcyBvZiBzZXNzaW9uIGNvbnRpbnVpdHku ICBJdHMgZGVmaW5pdGlvbiBpczoNCg0KDQoNCiAgIGludCBzZXRzYyhpbnQgc29ja2ZkLCBpbjZf YWRkciAqc291cmNlQWRkcmVzcywgc2NfdHlwZSBhZGRyZXNzVHlwZSk7DQoNCg0KDQogICBXaGVy ZToNCg0KICAgIC0gc29ja2ZkIC0gICAgICAgIGlzIHRoZSBzb2NrZXQgZGVzY3JpcHRvciBvZiB0 aGUgc29ja2V0IHdpdGggd2hpY2gNCg0KICAgICAgICAgICAgICAgICAgICAgIGEgc3BlY2lmaWMg YWRkcmVzcyB0eXBlIGlzIGFzc29jaWF0ZWQNCg0KICAgIC0gc291cmNlQWRkcmVzcyAtIGlzIGEg cG9pbnRlciB0byBhbiBhcmVhIGFsbG9jYXRlZCBmb3Igc2V0c2MoKSB0bw0KDQogICAgICAgICAg ICAgICAgICAgICAgcGxhY2UgdGhlIGdlbmVyYXRlZCBzb3VyY2UgSVAgYWRkcmVzcyBvZiB0aGUN Cg0KICAgICAgICAgICAgICAgICAgICAgIGRlc2lyZWQgc2Vzc2lvbiBjb250aW51aXR5IHR5cGUN Cg0KICAgIC0gYWRkcmVzc1R5cGUgLSAgIElzIHRoZSBkZXNpcmVkIHR5cGUgb2Ygc2Vzc2lvbiBj b250aW51aXR5IHNlcnZpY2UuDQoNCiAgICAgICAgICAgICAgICAgICAgICBJdCBpcyBhIDMtYml0 IGZpZWxkIGNvbnRhaW5pbmcgb25lIG9mIHRoZQ0KDQogICAgICAgICAgICAgICAgICAgICAgZm9s bG93aW5nIHZhbHVlczoNCg0KICAgICAgICAgICAgICAgICAgICAgIDAgLSBSZXNlcnZlZA0KDQog ICAgICAgICAgICAgICAgICAgICAgMSAtIEZJWEVEX0lQVjZfQUREUkVTUw0KDQogICAgICAgICAg ICAgICAgICAgICAgMiAtIFNFU1NJT05fTEFTVElOR19JUFY2X0FERFJFU1MNCg0KICAgICAgICAg ICAgICAgICAgICAgIDMgLSBOT05fUEVSU0lTVEVOVF9JUFY2X0FERFJFU1MNCg0KICAgICAgICAg ICAgICAgICAgICAgIDQgLSBHUkFDRUZVTF9SRVBMQUNFTUVOVF9JUFY2X0FERFJFU1MNCg0KICAg ICAgICAgICAgICAgICAgICAgIDUtNyAtIFJlc2VydmVkDQoNCg0KDQogICBzZXRzYygpIHJldHVy bnMgdGhlIHN0YXR1cyBvZiB0aGUgb3BlcmF0aW9uOg0KDQogICAgLSAwIC0gQWRkcmVzcyB3YXMg c3VjY2Vzc2Z1bGx5IGdlbmVyYXRlZA0KDQogICAgLSBFQUlfUkVRVUlSRURJUE5PVFNVUFBPUlRF RCAtIHRoZSByZXF1aXJlZCBzZXJ2aWNlIHR5cGUgaXMgbm90DQoNCiAgICAgIHN1cHBvcnRlZA0K DQogICAgLSBFQUlfUkVRVUlSRURJUEZBSUxFRCAtIHRoZSBuZXR3b3JrIGNvdWxkIG5vdCBmdWxm aWxsIHRoZSBkZXNpcmVkDQoNCiAgICAgIHJlcXVlc3QNCg0KDQoNCiAgIHNldHNjKCkgTUFZIGJs b2NrIHRoZSBpbnZva2luZyB0aHJlYWQgaWYgaXQgdHJpZ2dlcnMgdGhlIFRDUC9JUCBzdGFjaw0K DQogICB0byByZXF1ZXN0IGEgbmV3IElQIHByZWZpeCBmcm9tIHRoZSBuZXR3b3JrIHRvIGNvbnN0 cnVjdCB0aGUgZGVzaXJlZA0KDQogICBzb3VyY2UgSVAgYWRkcmVzcy4gIElmIGFuIElQIHByZWZp eCB3aXRoIHRoZSBkZXNpcmVkIHNlc3Npb24NCg0KICAgY29udGludWl0eSBmZWF0dXJlcyBhbHJl YWR5IGV4aXN0cyAod2FzIHByZXZpb3VzbHkgYWxsb2NhdGVkIHRvIHRoZQ0KDQogICBtb2JpbGUg aG9zdCkgYW5kIHRoZSBzdGFjayBpcyBub3QgcmVxdWlyZWQgdG8gcmVxdWVzdCBhIG5ldyBvbmUg YXMgYQ0KDQogICByZXN1bHQgb2Ygc2V0dGluZyB0aGUgSVBWNl9SRVFVSVJFX1NSQ19PTl9ORVQg ZmxhZyAoZGVmaW5lZCBiZWxvdyksDQoNCiAgIHNldHNjKCkgTUFZIHJldHVybiBpbW1lZGlhdGVs eSB3aXRoIHRoZSBjb25zdHJ1Y3RlZCBJUCBhZGRyZXNzIGFuZA0KDQogICB3aWxsIG5vdCBibG9j ayB0aGUgdGhyZWFkLg0KDQoNCg0KNi4yLiAgTmV3IEZsYWdzDQoNCg0KDQogICBUaGUgZm9sbG93 aW5nIGZsYWcgaXMgYWRkZWQgdG8gdGhlIGxpc3Qgb2YgZmxhZ3MgaW4gdGhlDQoNCiAgIElQVjZf QUREUl9QUkVGRVJFTkNFIG9wdGlvbiBhdCB0aGUgSVBQUk9UTzYgbGV2ZWw6DQoNCg0KDQogICBJ UFY2X1JFUVVJUkVfU1JDX09OX05FVCAtIHNldCBJUCBzdGFjayBhZGRyZXNzIGFsbG9jYXRpb24g YmVoYXZpb3INCg0KDQoNClllZ2luLCBldCBhbC4gICAgICAgICAgIEV4cGlyZXMgSmFudWFyeSAy NywgMjAxOSAgICAgICAgICAgICAgIFtQYWdlIDEzXQ0KDQoNCg0KSW50ZXJuZXQtRHJhZnQgICAg ICAgICAgICAgT24gRGVtYW5kIE1vYmlsaXR5ICAgICAgICAgICAgICAgICAgSnVseSAyMDE4DQoN Cg0KDQogICBJZiBzZXQsIHRoZSBJUCBzdGFjayB3aWxsIHJlcXVlc3QgYSBuZXcgSVB2NiBwcmVm aXggb2YgdGhlIGRlc2lyZWQNCg0KICAgdHlwZSBmcm9tIHRoZSBjdXJyZW50IHNlcnZpbmcgbmV0 d29yayBhbmQgY29uZmlndXJlIGEgbmV3IHNvdXJjZSBJUA0KDQogICBhZGRyZXNzLiAgSWYgcmVz ZXQsIHRoZSBJUCBzdGFjayB3aWxsIHVzZSBhIHByZWNvbmZpZ3VyZWQgb25lIGlmIGl0DQoNCiAg IGV4aXN0cy4gIElmIHRoZXJlIGlzIG5vIHByZWNvbmZpZ3VyZWQgSVAgYWRkcmVzcyBvZiB0aGUg ZGVzaXJlZCB0eXBlLA0KDQogICBhIG5ldyBwcmVmaXggd2lsbCBiZSByZXF1ZXN0ZWQgYW5kIHVz ZWQgZm9yIGNyZWF0aW5nIHRoZSBJUCBhZGRyZXNzLg0KDQoNCg0KNy4gIFNlY3VyaXR5IENvbnNp ZGVyYXRpb25zDQoNCg0KDQogICBUaGUgc2V0dGluZyBvZiBjZXJ0YWluIElQIGFkZHJlc3MgdHlw ZSBvbiBhIGdpdmVuIHNvY2tldCBtYXkgYmUNCg0KICAgcmVzdHJpY3RlZCB0byBwcml2aWxlZ2Vk IGFwcGxpY2F0aW9ucy4gIEZvciBleGFtcGxlLCBhIEZpeGVkIElQDQoNCiAgIEFkZHJlc3MgbWF5 IGJlIHByb3ZpZGVkIGFzIGEgcHJlbWl1bSBzZXJ2aWNlIGFuZCBvbmx5IGNlcnRhaW4NCg0KICAg YXBwbGljYXRpb25zIG1heSBiZSBhbGxvd2VkIHRvIHVzZSB0aGVtLiAgU2V0dGluZyBhbmQgZW5m b3JjZW1lbnQgb2YNCg0KICAgc3VjaCBwcml2aWxlZ2VzIGFyZSBvdXRzaWRlIHRoZSBzY29wZSBv ZiB0aGlzIGRvY3VtZW50Lg0KDQoNCg0KPG1nbHQ+DQoNCkkgYmVsaWV2ZSB0aGUgdGV4dCBjb3Vs ZCBkZXNjcmliZSB0aGUgdGhyZWF0IHN1Y2ggcmVjb21tZW5kYXRpb24gaXMgYWRkcmVzc2luZy4N Cg0KDQoNClRoZSBkb2N1bWVudCBkZXNjcmliZXMgaG93IGFwcGxpY2F0aW9ucyBwcm92aWRlcyB0 aGUgT1MgdGhlaXIgcmVxdWlyZW1lbnRzIGluIG9yZGVyIHRvIHNlbGVjdCB0aGUgYXBwcm9wcmlh dGVkIElQIGFkZHJlc3MuIFRoZSByZXNvdXJjZSBhcmUgYXNzb2NpYXRlZCB0byBkaWZmZXJlbnQg Y29zdHMuIFdoaWxlIHRoZSBjb3N0IGlzIHByaW1hcmlseSBvbiB0aGUgb3BlcmF0b3Igc2lkZSwg aXQgaXMgbGlrZWx5IHRoYXQgdXNhZ2UgYnkgdGhlIG1vYmlsZSBub2RlIGNvbWVzIHdpdGggc29t ZSByZXN0cmljdGlvbnMsIGxpbWl0YXRpb24gb3IgZGlyZWN0IGNvc3QuIFR5cGljYWxseSwgc29t ZSB0eXBlIG9mIElQIGFkZHJlc3MgbWF5IGJlIHByb3ZpZGVkIGJ5IHRoZSBvcGVyYXRvciBmb3Ig YSBsaW1pdGVkIG51bWJlciBvZiBieXRlcyB1cG9uIHdoaWNoIHRoZSBJUCBhZGRyZXNzIHR5cGUg d2lsbCBub3QgYmUgYXZhaWxhYmxlIHRvIHRoZSBtb2JpbGUgbm9kZSBvciBtYXkgYmUgY2hhcmdl ZC4gQSBtYWxpY2lvdXMgYXBwbGljYXRpb24gbWF5IHVzZSB0aGVzZSBsaW1pdGF0aW9ucyB0byBn ZW5lcmF0ZSBleHRyYSBiaWxsaW5nIG9mIHRoZSBtb2JpbGUgbm9kZSBvciB0byBwcmV2ZW50IHRo ZSB1c2FnZSBvZiBzb21lIGFwcGxpY2F0aW9ucyBieSBleGhhdXN0aW5nIHRoZSBleHBlY3RlZCB0 eXBlIG9mIElQIGFkZHJlc3MuDQoNCg0KDQpJbiBvcmRlciB0byBwcmV2ZW50IHN1Y2ggc2NlbmFy aW8sIHRoZSBtb2JpbGUgbm9kZSBTSE9VTEQgYmUgYWJsZSB0byBhdXRob3JpemUgc3BlY2lmaWMg UEkgYWRkcmVzcyB0eXBlcyB0byBwcml2aWxlZ2UgYXBwbGljYXRpb24uDQoNCg0KDQpXaXRoIHRo ZXNlIG5ldyB0eXBlcyBvZiBJUCBhZGRyZXNzZXMsIHRoZSBJUCBhZGRyZXNzIGxlYWtzIHNvbWUg Y29ubmVjdGl2aXR5IHJlcXVpcmVtZW50cyBvZiB0aGUgYXBwbGljYXRpb24uIFRoaXMgYWxzbyBt ZWFucyB0aGF0IGFkZGl0aW9uYWwgaW5mb3JtYXRpb24gaXMgcHJvdmlkZWQgdG8gdGhlIGRlc3Rp bmF0aW9uIHdoaWNoIGNvdWxkIHJldmVhbCB0byBhIHBhc3NpdmUgbW9uaXRvcmluZyBhdHRhY2tl ciBzb21lIGluZm9ybWF0aW9uIHN1Y2ggYXMgdGhlIHR5cGUgb2YgYXBwbGljYXRpb24gYW5kIHRo ZSBhcHBsaWNhdGlvbiBpdHNlbGYgZXZlbiB0aG91Z2ggdGhlIHBhY2tldCBpcyBwcm90ZWN0ZWQg YnkgSVBzZWMgb3IgVExTLg0KDQoNCg0KVG8gYXZvaWQgcHJvZmlsaW5nIGFuIGFwcGxpY2F0aW9u IGFjY29yZGluZyB0byB0aGUgdHlwZSBvZiBJUCBhZGRyZXNzZXMsIGl0IGlzIGV4cGVjdGVkIHRo YXQgcHJlZml4ZXMgcHJvdmlkZWQgYnkgdGhlIG9wZXJhdG9yIGFyZSBhc3NvY2lhdGVkIHRvIHZh cmlvdXMgdHlwZSBvZiBhZGRyZXNzZXMgb3ZlciB0aW1lLiBBcyBhIHJlc3VsdCwgdGhlIHR5cGUg b2YgYWRkcmVzcyBjb3VsZCBub3QgYmUgYXNzb2NpYXRlZCB0byB0aGUgcHJlZml4LCBtYWtpbmcg YXBwbGljYXRpb24gcHJvZmlsaW5nIGJhc2VkIG9uIHRoZSB0eXBlIG9mIGFkZHJlc3MgaGFyZGVy Lg0KDQpBcHBsaWNhdGlvbiB1c2luZyBtdWx0aXBsZSB0eXBlIG9mIElQIGFkZHJlc3NlcyB0byBh dm9pZCBiZWluZyBwcm9maWxlZCBpcyBsaWtlbHkgdG8gY3JlYXRlIHNvbWUgcGF0dGVybnMuIFNv IHRoYXQgcmVtYWlucyBhIGhhcmQgcHJvYmxlbSB0byBzb2x2ZSBieSB0aGUgYXBwbGljYXRpb24u DQoNCg0KDQpUaGUgdXNhZ2Ugb2YgYSBmaXhlZCBJUCBhZGRyZXNzLCBlbmFibGVzIHRyYWNraW5n IHRoZSBtb2JpbGUgbm9kZSwgb3IgaXRzIGFwcGxpY2F0aW9uIG92ZXIgdGltZS4gVGhpcyBpcyBh IHNpbWlsYXIgcHJvYmxlbSBhcyB0aGUgb25lIGVuY291bnRlcmVkIHdpdGggUHVibGljIElQIGFk ZHJlc3Nlcy4gVGhlIHVzYWdlIG9mIHRoZSBGaXhlZCBJUCBhZGRyZXNzZXMgc2hvdWxkIGJlIGxp bWl0ZWQuDQoNCg0KDQpUbyBsaW1pdCB0aGUgZWZmZWN0IG9mIElQIHRyYWNraW5nLCB0aGUgYXBw bGljYXRpb24gb3IgdGhlIE9TIHNob3VsZCBlbnN1cmUgdGhhdCBJUCBhZGRyZXNzZXMgcmVndWxh cmx5IGNoYW5nZSB0byBsaW1pdCBJUCB0cmFja2luZyBieSBhIHBhc3NpdmUgb2JzZXJ2ZXIuICBU aGUgYXBwbGljYXRpb24gc2hvdWxkIHJlZ3VsYXJseSBzZXQgdGhlIE9uIERlbWFuZCBmbGFnLiBU aGUgYXBwbGljYXRpb24gc2hvdWxkIGJlIGFibGUgdG8gZW5zdXJlIHRoYXQgc2Vzc2lvbiBsYXN0 aW5nIElQIGFkZHJlc3MgYXJlIHJlZ3VsYXJseSBjaGFuZ2VkIGJ5IHNldHRpbmcgYSBsaWZldGlt ZSBmb3IgZXhhbXBsZSBoYW5kbGVkIGJ5IHRoZSBhcHBsaWNhdGlvbi4gSW4gYWRkaXRpb24sIHRo ZSBhcHBsaWNhdGlvbiBzaG91bGQgY29uc2lkZXIgdGhlIHVzZSBvZiBncmFjZWZ1bCByZXBsYWNl bWVudCBJUCBhZGRyZXNzZXMuDQoNCg0KDQpTaW1pbGFybHksIHRoZSBPUyBtYXkgYWxzbyBhc3Nv Y2lhdGVkIElQIGFkZHJlc3NlcyB3aXRoIGEgbGlmZXRpbWUuIFVwb24gcmVjZWl2aW5nIGEgcmVx dWVzdCBmb3IgYSBnaXZlbiB0eXBlIG9mIElQIGFkZHJlc3MsIGFmdGVyIHNvbWUgdGltZSwgdGhl IE9TIHNob3VsZCByZXF1ZXN0IGEgbmV3IGFkZHJlc3MgdG8gdGhlIG5ldHdvcmsgZXZlbiBpZiBp dCBhbHJlYWR5IGhhcyBvbmUgSVAgYWRkcmVzcyBhdmFpbGFibGUgd2l0aCB0aGUgcmVxdWVzdGVk IHR5cGUuIFRoaXMgaW5jbHVkZXMgYW55IHR5cGUgb2YgSVAgYWRkcmVzcy4gQWRkcmVzc2VzIG9m IHR5cGUgZ3JhY2VmdWwgcmVwbGFjZW1lbnQgb3Igbm9uIHBlcnNpc3RlbnQgSVAgYWRkcmVzc2Vz IHNob3VsZCBiZSByZWd1bGFybHkgcmVuZXdlZCBieSB0aGUgT1MuDQoNCg0KDQpUaGUgbGlmZXRp bWUgb2YgYW4gSVAgYWRkcmVzcyBtYXkgYmUgZXhwcmVzc2VkIGluIG51bWJlciBvZiBzZWNvbmRz IG9yIGluIHVtYmVyIG9mIGJ5dGVzIHNlbnQgdGhyb3VnaCB0aGlzIElQIGFkZHJlc3MuDQoNCjwv bWdsdD4NCg0KDQoNClNlc3Npb24gbGFzdGluZyBJUCBhZGRyZXNzIGNvdWxkIGJlIHVzZWQgdG8g YXZvaWQgdHJhY2tpbmcgYW5kIHNob3VsZCBiZSBwcmVmZXJyZWQuIEhvd2V2ZXIsIHRoZXJlIHNo b3VsZCBiZSBhIHdheSB0byBzcGVjaWZ5IGJldHdlZW4gb25lIHNlc3Npb24gbGFzdGluZyBvciBp ZiB0aGUgSVAgYWRkcmVzcyBjYW4gbGFzdCBtdWx0aXBsZSBzZXNzaW9ucy4NCg0KDQoNCjwvbWds dD4NCg0KDQoNCjguICBJQU5BIENvbnNpZGVyYXRpb25zDQoNCg0KDQogICBUaGlzIGRvY3VtZW50 IGhhcyBubyBJQU5BIGNvbnNpZGVyYXRpb25zLg0KDQoNCg0KOS4gIENvbnRyaWJ1dG9ycw0KDQoN Cg0KICAgVGhpcyBkb2N1bWVudCB3YXMgbWVyZ2VkIHdpdGggW0ktRC5zaWplb24tZG1tLXVzZS1j YXNlcy1hcGktc291cmNlXS4NCg0KICAgV2Ugd291bGQgbGlrZSB0byBhY2tub3dsZWRnZSB0aGUg Y29udHJpYnV0aW9uIG9mIHRoZSBmb2xsb3dpbmcgcGVvcGxlDQoNCiAgIHRvIHRoYXQgZG9jdW1l bnQgYXMgd2VsbDoNCg0KDQoNCiAgIFNlcmdpbyBGaWd1ZWlyZWRvDQoNCiAgIEFsdHJhbiBSZXNl YXJjaCwgRnJhbmNlDQoNCiAgIEVtYWlsOiBzZXJnaW8uZmlndWVpcmVkb0BhbHRyYW4uY29tPG1h aWx0bzpzZXJnaW8uZmlndWVpcmVkb0BhbHRyYW4uY29tPg0KDQoNCg0KICAgWW91bmdoYW4gS2lt DQoNCiAgIFNvb25nc2lsIFVuaXZlcnNpdHksIEtvcmVhDQoNCiAgIEVtYWlsOiB5b3VuZ2hha0Bz c3UuYWMua3I8bWFpbHRvOnlvdW5naGFrQHNzdS5hYy5rcj4NCg0KDQoNCiAgIEpvaG4gS2FpcHBh bGxpbWFsaWwNCg0KICAgSHVhd2VpLCBVU0ENCg0KICAgRW1haWw6IGpvaG4ua2FpcHBhbGxpbWFs aWxAaHVhd2VpLmNvbTxtYWlsdG86am9obi5rYWlwcGFsbGltYWxpbEBodWF3ZWkuY29tPg0KDQoN Cg0KMTAuICBBY2tub3dsZWRnZW1lbnRzDQoNCg0KDQogICBXZSB3b3VsZCBsaWtlIHRvIHRoYW5r IFd1LWNoaSBGZW5nLCBBbGV4YW5kcnUgUGV0cmVzY3UsIEpvdW5pDQoNCiAgIEtvcmhvbmVuLCBT cmkgR3VuZGF2ZWxsaSwgRGF2ZSBEb2xzb24gYW5kIExvcmVuem8gQ29saXR0aSBmb3IgdGhlaXIN Cg0KICAgdmFsdWFibGUgY29tbWVudHMgYW5kIHN1Z2dlc3Rpb25zIG9uIHRoaXMgd29yay4NCg0K DQoNCjExLiAgUmVmZXJlbmNlcw0KDQoNCg0KWWVnaW4sIGV0IGFsLiAgICAgICAgICAgRXhwaXJl cyBKYW51YXJ5IDI3LCAyMDE5ICAgICAgICAgICAgICAgW1BhZ2UgMTRdDQoNCg0KDQpJbnRlcm5l dC1EcmFmdCAgICAgICAgICAgICBPbiBEZW1hbmQgTW9iaWxpdHkgICAgICAgICAgICAgICAgICBK dWx5IDIwMTgNCg0KDQoNCjExLjEuICBOb3JtYXRpdmUgUmVmZXJlbmNlcw0KDQoNCg0KICAgW1JG QzIxMTldICBCcmFkbmVyLCBTLiwgIktleSB3b3JkcyBmb3IgdXNlIGluIFJGQ3MgdG8gSW5kaWNh dGUNCg0KICAgICAgICAgICAgICBSZXF1aXJlbWVudCBMZXZlbHMiLCBCQ1AgMTQsIFJGQyAyMTE5 LA0KDQogICAgICAgICAgICAgIERPSSAxMC4xNzQ4Ny9SRkMyMTE5LCBNYXJjaCAxOTk3LA0KDQog ICAgICAgICAgICAgIDxodHRwczovL3d3dy5yZmMtZWRpdG9yLm9yZy9pbmZvL3JmYzIxMTk+Lg0K DQoNCg0KICAgW1JGQzUwMTRdICBOb3JkbWFyaywgRS4sIENoYWtyYWJhcnRpLCBTLiwgYW5kIEou IExhZ2FuaWVyLCAiSVB2Ng0KDQogICAgICAgICAgICAgIFNvY2tldCBBUEkgZm9yIFNvdXJjZSBB ZGRyZXNzIFNlbGVjdGlvbiIsIFJGQyA1MDE0LA0KDQogICAgICAgICAgICAgIERPSSAxMC4xNzQ4 Ny9SRkM1MDE0LCBTZXB0ZW1iZXIgMjAwNywNCg0KICAgICAgICAgICAgICA8aHR0cHM6Ly93d3cu cmZjLWVkaXRvci5vcmcvaW5mby9yZmM1MDE0Pi4NCg0KDQoNCjExLjIuICBJbmZvcm1hdGl2ZSBS ZWZlcmVuY2VzDQoNCg0KDQogICBbSS1ELnNpamVvbi1kbW0tdXNlLWNhc2VzLWFwaS1zb3VyY2Vd DQoNCiAgICAgICAgICAgICAgSmVvbiwgUy4sIEZpZ3VlaXJlZG8sIFMuLCBLaW0sIFkuLCBhbmQg Si4gS2FpcHBhbGxpbWFsaWwsDQoNCiAgICAgICAgICAgICAgIlVzZSBDYXNlcyBhbmQgQVBJIEV4 dGVuc2lvbiBmb3IgU291cmNlIElQIEFkZHJlc3MNCg0KICAgICAgICAgICAgICBTZWxlY3Rpb24i LCBkcmFmdC1zaWplb24tZG1tLXVzZS1jYXNlcy1hcGktc291cmNlLTA3ICh3b3JrDQoNCiAgICAg ICAgICAgICAgaW4gcHJvZ3Jlc3MpLCBTZXB0ZW1iZXIgMjAxNy4NCg0KDQoNCiAgIFtSRkMzMjYx XSAgUm9zZW5iZXJnLCBKLiwgU2NodWx6cmlubmUsIEguLCBDYW1hcmlsbG8sIEcuLCBKb2huc3Rv biwNCg0KICAgICAgICAgICAgICBBLiwgUGV0ZXJzb24sIEouLCBTcGFya3MsIFIuLCBIYW5kbGV5 LCBNLiwgYW5kIEUuDQoNCiAgICAgICAgICAgICAgU2Nob29sZXIsICJTSVA6IFNlc3Npb24gSW5p dGlhdGlvbiBQcm90b2NvbCIsIFJGQyAzMjYxLA0KDQogICAgICAgICAgICAgIERPSSAxMC4xNzQ4 Ny9SRkMzMjYxLCBKdW5lIDIwMDIsDQoNCiAgICAgICAgICAgICAgPGh0dHBzOi8vd3d3LnJmYy1l ZGl0b3Iub3JnL2luZm8vcmZjMzI2MT4uDQoNCg0KDQogICBbUkZDNTIxM10gIEd1bmRhdmVsbGks IFMuLCBFZC4sIExldW5nLCBLLiwgRGV2YXJhcGFsbGksIFYuLA0KDQogICAgICAgICAgICAgIENo b3dkaHVyeSwgSy4sIGFuZCBCLiBQYXRpbCwgIlByb3h5IE1vYmlsZSBJUHY2IiwNCg0KICAgICAg ICAgICAgICBSRkMgNTIxMywgRE9JIDEwLjE3NDg3L1JGQzUyMTMsIEF1Z3VzdCAyMDA4LA0KDQog ICAgICAgICAgICAgIDxodHRwczovL3d3dy5yZmMtZWRpdG9yLm9yZy9pbmZvL3JmYzUyMTM+Lg0K DQoNCg0KICAgW1JGQzU1NjNdICBMZXVuZywgSy4sIERvbW1ldHksIEcuLCBZZWdhbmksIFAuLCBh bmQgSy4gQ2hvd2RodXJ5LA0KDQogICAgICAgICAgICAgICJXaU1BWCBGb3J1bSAvIDNHUFAyIFBy b3h5IE1vYmlsZSBJUHY0IiwgUkZDIDU1NjMsDQoNCiAgICAgICAgICAgICAgRE9JIDEwLjE3NDg3 L1JGQzU1NjMsIEZlYnJ1YXJ5IDIwMTAsDQoNCiAgICAgICAgICAgICAgPGh0dHBzOi8vd3d3LnJm Yy1lZGl0b3Iub3JnL2luZm8vcmZjNTU2Mz4uDQoNCg0KDQogICBbUkZDNTk0NF0gIFBlcmtpbnMs IEMuLCBFZC4sICJJUCBNb2JpbGl0eSBTdXBwb3J0IGZvciBJUHY0LCBSZXZpc2VkIiwNCg0KICAg ICAgICAgICAgICBSRkMgNTk0NCwgRE9JIDEwLjE3NDg3L1JGQzU5NDQsIE5vdmVtYmVyIDIwMTAs DQoNCiAgICAgICAgICAgICAgPGh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2luZm8vcmZjNTk0 ND4uDQoNCg0KDQogICBbUkZDNjI3NV0gIFBlcmtpbnMsIEMuLCBFZC4sIEpvaG5zb24sIEQuLCBh bmQgSi4gQXJra28sICJNb2JpbGl0eQ0KDQogICAgICAgICAgICAgIFN1cHBvcnQgaW4gSVB2NiIs IFJGQyA2Mjc1LCBET0kgMTAuMTc0ODcvUkZDNjI3NSwgSnVseQ0KDQogICAgICAgICAgICAgIDIw MTEsIDxodHRwczovL3d3dy5yZmMtZWRpdG9yLm9yZy9pbmZvL3JmYzYyNzU+Lg0KDQoNCg0KICAg W1JGQzY4MjRdICBGb3JkLCBBLiwgUmFpY2l1LCBDLiwgSGFuZGxleSwgTS4sIGFuZCBPLiBCb25h dmVudHVyZSwNCg0KICAgICAgICAgICAgICAiVENQIEV4dGVuc2lvbnMgZm9yIE11bHRpcGF0aCBP cGVyYXRpb24gd2l0aCBNdWx0aXBsZQ0KDQogICAgICAgICAgICAgIEFkZHJlc3NlcyIsIFJGQyA2 ODI0LCBET0kgMTAuMTc0ODcvUkZDNjgyNCwgSmFudWFyeSAyMDEzLA0KDQogICAgICAgICAgICAg IDxodHRwczovL3d3dy5yZmMtZWRpdG9yLm9yZy9pbmZvL3JmYzY4MjQ+Lg0KDQoNCg0KWWVnaW4s IGV0IGFsLiAgICAgICAgICAgRXhwaXJlcyBKYW51YXJ5IDI3LCAyMDE5ICAgICAgICAgICAgICAg W1BhZ2UgMTVdDQoNCg0KDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICBPbiBEZW1hbmQgTW9i aWxpdHkgICAgICAgICAgICAgICAgICBKdWx5IDIwMTgNCg0KDQoNCiAgIFtSRkM3MzMzXSAgQ2hh biwgSC4sIEVkLiwgTGl1LCBELiwgU2VpdGUsIFAuLCBZb2tvdGEsIEguLCBhbmQgSi4NCg0KICAg ICAgICAgICAgICBLb3Job25lbiwgIlJlcXVpcmVtZW50cyBmb3IgRGlzdHJpYnV0ZWQgTW9iaWxp dHkNCg0KICAgICAgICAgICAgICBNYW5hZ2VtZW50IiwgUkZDIDczMzMsIERPSSAxMC4xNzQ4Ny9S RkM3MzMzLCBBdWd1c3QgMjAxNCwNCg0KICAgICAgICAgICAgICA8aHR0cHM6Ly93d3cucmZjLWVk aXRvci5vcmcvaW5mby9yZmM3MzMzPi4NCg0KDQoNCkF1dGhvcnMnIEFkZHJlc3Nlcw0KDQoNCg0K ICAgQWxwZXIgWWVnaW4NCg0KICAgQWN0aWxpdHkNCg0KICAgSXN0YW5idWwNCg0KICAgVHVya2V5 DQoNCg0KDQogICBFbWFpbDogYWxwZXIueWVnaW5AYWN0aWxpdHkuY29tPG1haWx0bzphbHBlci55 ZWdpbkBhY3RpbGl0eS5jb20+DQoNCg0KDQogICBEYW5ueSBNb3Nlcw0KDQogICBJbnRlbCBDb3Jw b3JhdGlvbg0KDQogICBQZXRhaCBUaWt2YQ0KDQogICBJc3JhZWwNCg0KDQoNCiAgIEVtYWlsOiBk YW5ueS5tb3Nlc0BpbnRlbC5jb208bWFpbHRvOmRhbm55Lm1vc2VzQGludGVsLmNvbT4NCg0KDQoN CiAgIEtpc3VrIEt3ZW9uDQoNCiAgIFNhbXN1bmcNCg0KICAgU3V3b24NCg0KICAgU291dGggS29y ZWENCg0KDQoNCiAgIEVtYWlsOiBraXN1ay5rd2VvbkBzYW1zdW5nLmNvbTxtYWlsdG86a2lzdWsu a3dlb25Ac2Ftc3VuZy5jb20+DQoNCg0KDQogICBKaW5zdW5nIExlZQ0KDQogICBTYW1zdW5nDQoN CiAgIFN1d29uDQoNCiAgIFNvdXRoIEtvcmVhDQoNCg0KDQogICBFbWFpbDoganM4MS5sZWVAc2Ft c3VuZy5jb208bWFpbHRvOmpzODEubGVlQHNhbXN1bmcuY29tPg0KDQoNCg0KICAgSnVuZ3NoaW4g UGFyaw0KDQogICBTYW1zdW5nDQoNCiAgIFN1d29uDQoNCiAgIFNvdXRoIEtvcmVhDQoNCg0KDQog ICBFbWFpbDogc2hpbjAyLnBhcmtAc2Ftc3VuZy5jb208bWFpbHRvOnNoaW4wMi5wYXJrQHNhbXN1 bmcuY29tPg0KDQoNCg0KWWVnaW4sIGV0IGFsLiAgICAgICAgICAgRXhwaXJlcyBKYW51YXJ5IDI3 LCAyMDE5ICAgICAgICAgICAgICAgW1BhZ2UgMTZdDQoNCg0KDQpJbnRlcm5ldC1EcmFmdCAgICAg ICAgICAgICBPbiBEZW1hbmQgTW9iaWxpdHkgICAgICAgICAgICAgICAgICBKdWx5IDIwMTgNCg0K DQoNCiAgIFNlaWwgSmVvbg0KDQogICBTdW5na3l1bmt3YW4gVW5pdmVyc2l0eQ0KDQogICBTdXdv bg0KDQogICBTb3V0aCBLb3JlYQ0KDQoNCg0KICAgRW1haWw6IHNlaWxqZW9uQHNra3UuZWR1PG1h aWx0bzpzZWlsamVvbkBza2t1LmVkdT4NCg0KDQoNClllZ2luLCBldCBhbC4gICAgICAgICAgIEV4 cGlyZXMgSmFudWFyeSAyNywgMjAxOSAgICAgICAgICAgICAgIFtQYWdlIDE3XQ0KDQoNCg0KDQoN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCmRtbSBt YWlsaW5nIGxpc3QNCg0KZG1tQGlldGYub3JnPG1haWx0bzpkbW1AaWV0Zi5vcmc+DQoNCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG1tDQoNCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KQSBt ZW1iZXIgb2YgdGhlIEludGVsIENvcnBvcmF0aW9uIGdyb3VwIG9mIGNvbXBhbmllcw0KDQpUaGlz IGUtbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBtYXRl cmlhbCBmb3INCnRoZSBzb2xlIHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50KHMpLiBBbnkg cmV2aWV3IG9yIGRpc3RyaWJ1dGlvbg0KYnkgb3RoZXJzIGlzIHN0cmljdGx5IHByb2hpYml0ZWQu IElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZA0KcmVjaXBpZW50LCBwbGVhc2UgY29udGFjdCB0 aGUgc2VuZGVyIGFuZCBkZWxldGUgYWxsIGNvcGllcy4NCg== --_000_BN8PR15MB3090DA22E91DA6E0936493EDE3600BN8PR15MB3090namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1z b1BsYWluVGV4dCwgbGkuTXNvUGxhaW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCBDaGFyIjsNCgltYXJn aW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGku TXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9y aXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJv dHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ bXNvLWFkZC1zcGFjZTphdXRvOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLHNhbnMtc2VyaWY7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoQ3hTcEZpcnN0LCBsaS5Nc29M aXN0UGFyYWdyYXBoQ3hTcEZpcnN0LCBkaXYuTXNvTGlzdFBhcmFncmFwaEN4U3BGaXJzdA0KCXtt c28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJbWFy Z2luLXRvcDowaW47DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCglt YXJnaW4tbGVmdDouNWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCgltc28tYWRkLXNwYWNl OmF1dG87DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjt9DQpwLk1zb0xpc3RQYXJhZ3JhcGhDeFNwTWlkZGxlLCBsaS5Nc29MaXN0UGFyYWdyYXBo Q3hTcE1pZGRsZSwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGhDeFNwTWlkZGxlDQoJe21zby1zdHlsZS1w cmlvcml0eTozNDsNCgltc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltYXJnaW4tdG9wOjBp bjsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0 Oi41aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCW1zby1hZGQtc3BhY2U6YXV0bzsNCglm b250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAu TXNvTGlzdFBhcmFncmFwaEN4U3BMYXN0LCBsaS5Nc29MaXN0UGFyYWdyYXBoQ3hTcExhc3QsIGRp di5Nc29MaXN0UGFyYWdyYXBoQ3hTcExhc3QNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1z by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdo dDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJbXNvLWFkZC1zcGFjZTphdXRvOw0KCWZvbnQtc2l6ZToxMS4wcHQ7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KcC5tc29ub3JtYWwwLCBsaS5t c29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJ bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLlBsYWluVGV4dENoYXIN Cgl7bXNvLXN0eWxlLW5hbWU6IlBsYWluIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0IjsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUyMw0KCXttc28tc3R5bGUtdHlwZTpwZXJz b25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0 ZXh0O30NCnNwYW4uRW1haWxTdHlsZTI0DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLWNvbXBv c2U7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4 dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250 LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsN CgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtw YWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXtt c28tbGlzdC1pZDoxNTg2MjYwNjk0Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0 LXRlbXBsYXRlLWlkczotMjUyNTYxMTQwIC01NDQwNDkxNjYgNjc2OTg2OTEgNjc2OTg2OTMgNjc2 OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxp c3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDowOw0KCW1zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2Fs aWJyaTsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBs MDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBO ZXciO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1m YW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw2 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxp c3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1i b2w7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1pZDox ODc5ODU4MTg4Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlk czoxODIxNzkxODQyIDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEz IDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1O30NCkBsaXN0IGwxOmxldmVsMQ0K CXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwxOmxldmVsMg0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBs aXN0IGwxOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0 Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMTpsZXZlbDQNCgl7bXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjt9DQpAbGlzdCBsMTpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMTpsZXZlbDYN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVu dDotOS4wcHQ7fQ0KQGxpc3QgbDE6bGV2ZWw3DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0K QGxpc3QgbDE6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDE6bGV2ZWw5DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCm9s DQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwv c3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJl ZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0i ZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwv aGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGksIDxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3MgZm9yIHRoZSByZXNwb25zZXMuIEkgbWlzc2Vk IHlvdXIgZW1haWwgYW5kIGRpZyBmb3IgaXQgd2hpbGUgcmV2aWV3aW5nIHZlcnNpb24gMTYuIFBs ZWFzZSBmaW5kIG15IGNvbW1lbnRzIGlubGluZS4gT3ZlcmFsbCB5b3VyIHJlc3BvbnNlcyBhZGRy ZXNzZWQgbXkgY29uY2VybmVkLCBidXQgSSBhbSBzdGlsbCB0aGlua2luZyB0aGF0IHRoZSBTZWN1 cml0eSBDb25zaWRlcmF0aW9ucyBzZWN0aW9uIGNvdWxkDQogYmUgY29tcGxldGVkLiBGZWVsIGZy ZWUgdG8gbGV0IG1lIGtub3cgd2hhdCB5b3UgdGhpbmsuIDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5Zb3VycywgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5EYW5pZWw8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGlu IDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gTW9zZXMsIERhbm55ICZs dDtkYW5ueS5tb3Nlc0BpbnRlbC5jb20mZ3Q7IDxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwg SmFudWFyeSAxNywgMjAxOSAzOjExIFBNPGJyPg0KPGI+VG86PC9iPiBEYW5pZWwgTWlnYXVsdCAm bHQ7ZGFuaWVsLm1pZ2F1bHRAZXJpY3Nzb24uY29tJmd0Ozsgc2VjZGlyQGlldGYub3JnPGJyPg0K PGI+Q2M6PC9iPiBkcmFmdC1pZXRmLWRtbS1vbmRlbWFuZC1tb2JpbGl0eS5hbGxAaWV0Zi5vcmc7 IGlldGZAaWV0Zi5vcmc7IGRtbUBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogW0RN TV0gU2VjZGlyIGxhc3QgY2FsbCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1kbW0tb25kZW1hbmQtbW9i aWxpdHktMTU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkRhbmll bCw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+VGhhbmtzIGZvciBhIHZlcnkgdGhvcm91 Z2ggcmV2aWV3IGFuZCB0aGUgZGV0YWlsZWQgY29tbWVudHMuIEkgYXBwcmVjaWF0ZSB5b3VyIGlu dmVzdGVkIHRpbWUuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlRoZXJlIHdlcmUgb25l IG9yIHR3byBjb21tZW50cyBJIGRpZCBub3QgZnVsbHkgdW5kZXJzdGFuZC4NCjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+SSBoYXZlIHVzZWQgbWFueSBvZiB0aGVtIHRv IGltcHJvdmUgdGhlIGRvY3VtZW50LiBUaGVyZSB3ZXJlIHNvbWUgd2hpY2ggSSB0aG91Z2h0IGRp ZmZlcmVudGx5IGFuZCBwcm92aWRlZCBieSByZWFzb25pbmcuPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPlBsZWFzZSBzZWUgbXkgZGV0YWlsZWQgcmVzcG9uc2UgYmVsb3cuPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5UaGFua3MgYW5kIHJlZ2FyZHMsPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5EYW5ueTxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8b2wgc3R5bGU9 Im1hcmdpbi10b3A6MGluIiBzdGFydD0iMSIgdHlwZT0iMSI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQ YXJhZ3JhcGhDeFNwRmlyc3QiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWFkZC1zcGFjZTph dXRvO21zby1saXN0OmwxIGxldmVsMSBsZm8yIj4NCuKAnGluZWZmaWNpZW5jaWVz4oCdIHNlZW0g dG9vIHZhZ3Vl4oCmPG86cD48L286cD48L2xpPjwvb2w+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFn cmFwaEN4U3BNaWRkbGUiPkkgYW0gYWRkaW5nIGEgcmVmZXJlbmNlIHRvIFJGQyA3MzMzIHRoYXQg ZGVzY3JpYmUgdGhlc2UgaW5lZmZpY2llbmNpZXMgaW4gc2VjdGlvbiA0LjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGhDeFNwTWlkZGxlIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MGluO21zby1hZGQtc3BhY2U6YXV0byI+DQombHQ7bWdsdCZndDtUaGFua3MgdGhhdCBpcyBj bGVhcmVyIHRvIG1lLiZsdDsvbWdsdCZndDs8bzpwPjwvbzpwPjwvcD4NCjxvbCBzdHlsZT0ibWFy Z2luLXRvcDowaW4iIHN0YXJ0PSIyIiB0eXBlPSIxIj4NCjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFn cmFwaEN4U3BNaWRkbGUiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWFkZC1zcGFjZTphdXRv O21zby1saXN0OmwxIGxldmVsMSBsZm8yIj4NClVzZSDigJxJUCBzZXNzaW9uIGNvbnRpbnVpdHni gJ0gcmF0aGVyIHRoYW4g4oCcc2Vzc2lvbiBjb250aW51aXR54oCdPG86cD48L286cD48L2xpPjwv b2w+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaEN4U3BNaWRkbGUiPlRoZSBvcmlnaW5hbCBk ZWZpbml0aW9uIHdhcyDigJxJUCBzZXNzaW9uIGNvbnRpbnVpdHnigJ0uIEhvd2V2ZXIsIEJyaWFu IEhhYmVybWFuIGluIHRoZSBlYXJseSByZXZpZXcgY29tbWVudGVkIHRoYXQgdGhpcyB0ZXJtIGlz IGNvbmZ1c2luZyBzaW5jZSB0aGUgSVAgbGF5ZXIgaXMgbm90IGEgc2Vzc2lvbiBsYXllciBhbmQg dGh1cywg4oCcSVAgU2Vzc2lvbuKAnSBpcyBub3QgZGVmaW5lZC4gVG8NCiByZXNvbHZlIHRoaXMs IHdlIGFncmVlZCB0byBjaGFuZ2Ug4oCcSVAgc2Vzc2lvbiBjb250aW51aXR54oCdIHRvIOKAnHNl c3Npb24gY29udGludWl0eeKAnSBpbiB2ZXJzaW9uIDE1IG9mIHRoaXMgZHJhZnQuIEkgZmVlbCBj b21mb3J0YWJsZSB3aXRoIGFueSBvZiB0aGVzZSBkZWZpbml0aW9ucywgc28gaWYgdGhlIHJldmll d2VycyBjYW4gYWdyZWUgb24gYSB0ZXJtLCBJIHdpbGwgYWRvcHQgaXQuIEluIGFueSBjYXNlLCBJ IGJlbGlldmUgdGhlIHRleHQgY2xlYXJseQ0KIGRlc2NyaWJlIHRoZSBiZWhhdmlvciBvZiB0aGUg bmV0d29yay48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoQ3hTcE1p ZGRsZSIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tYWRkLXNwYWNlOmF1dG8iPg0KJmx0O21n bHQmZ3Q7VGhlIHRleHQgaXMgY2xlYXIuJmx0Oy9tZ2x0Jmd0OzxvOnA+PC9vOnA+PC9wPg0KPG9s IHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgc3RhcnQ9IjMiIHR5cGU9IjEiPg0KPGxpIGNsYXNzPSJN c29MaXN0UGFyYWdyYXBoQ3hTcE1pZGRsZSIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tYWRk LXNwYWNlOmF1dG87bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzIiPg0KUmVjb21tZW5kZWQgcmVvcmRl cmluZyBvZiB0aGUgdGV4dCBpbiBzZWN0aW9uIDEuPG86cD48L286cD48L2xpPjwvb2w+DQo8cCBj bGFzcz0iTXNvTGlzdFBhcmFncmFwaEN4U3BNaWRkbGUiPkkgZGlkIG5vdCB1bmRlcnN0YW5kIHRo ZSByZWNvbW1lbmRlZCBvcmRlciwgdGhhdCBpcywgd2hpY2ggcGFyYWdyYXBoIG5lZWRzIHRvIGJl IG1vdmVkIHRvIHdoaWNoIHBsYWNlLiBQbGVhc2UgaGVscCBjbGFyaWZ5IHRoaXMgY29tbWVudC48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoQ3hTcE1pZGRsZSIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tYWRkLXNwYWNlOmF1dG8iPg0KJmx0O21nbHQmZ3Q7PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaEN4U3BNaWRkbGUiIHN0eWxl PSJtYXJnaW4tbGVmdDowaW47bXNvLWFkZC1zcGFjZTphdXRvIj4NCldlbGwgSSB0aGluayB0aGUg aW50cm9kdWN0aW9uIGNvdWxkIGJlIGJldHRlciBhcnRpY3VsYXRlZC4gQnV0IGFzIGl0IHNlZW1z IEkgYW0gdGhlIG9ubHkgb25lIHJhaXNpbmcgdGhlIGNvbmNlcm4sIEkgZ3Vlc3MgdGhhdCBpcyBm aW5lLg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaEN4U3BNaWRk bGUiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWFkZC1zcGFjZTphdXRvIj4NCjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGhDeFNwTWlkZGxlIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MGluO21zby1hZGQtc3BhY2U6YXV0byI+DQpXaGF0IEkgbWVhbnQgd2Fz IHRvIGhhdmUgaXQgYXMgZm9sbG93czo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0 UGFyYWdyYXBoQ3hTcExhc3QiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWFkZC1zcGFjZTph dXRvIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAm bmJzcDtNb2JpbGUgSVAgaXMgZGVzaWduZWQgdG8gcHJvdmlkZSBib3RoIHNlc3Npb24gY29udGlu dWl0eSBhbmQgSVA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAm bmJzcDthZGRyZXNzIHJlYWNoYWJpbGl0eSB0byBtb2JpbGUgaG9zdHMuJm5ic3A7IEFyY2hpdGVj dHVyZXMgdXRpbGl6aW5nIHRoZXNlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDsgJm5ic3A7cHJvdG9jb2xzIChlLmcuLCAzR1BQLCAzR1BQMiwgV0lNQVgpIGVuc3Vy ZSB0aGF0IGFueSBtb2JpbGUgaG9zdDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7ICZuYnNwO2F0dGFjaGVkIHRvIHRoZSBjb21wbGlhbnQgbmV0d29ya3MgY2FuIGVu am95IHRoZXNlIGJlbmVmaXRzLiZuYnNwOyBBbnk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOyAmbmJzcDthcHBsaWNhdGlvbiBydW5uaW5nIG9uIHRoZXNlIG1vYmls ZSBob3N0cyBpcyBzdWJqZWN0ZWQgdG8gdGhlIHNhbWU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDt0cmVhdG1lbnQgd2l0aCByZXNwZWN0IHRvIHNlc3Np b24gY29udGludWl0eSBhbmQgSVAgYWRkcmVzczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7ICZuYnNwO3JlYWNoYWJpbGl0eS48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1hZGQtc3Bh Y2U6YXV0byI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDsgJm5ic3A7QWNoaWV2aW5nIHNlc3Npb24gY29udGludWl0eSBhbmQgSVAgYWRkcmVzcyByZWFj aGFiaWxpdHkgd2l0aCBNb2JpbGU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOyAmbmJzcDtJUCBpbmN1cnMgc29tZSBjb3N0LiZuYnNwOyBNb2JpbGUgSVAgcHJvdG9j b2wgZm9yY2VzIHRoZSBtb2JpbGUgaG9zdCdzIElQPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7dHJhZmZpYyB0byB0cmF2ZXJzZSBhIGNlbnRyYWxseS1s b2NhdGVkIHJvdXRlciAoSG9tZSBBZ2VudCwgSEEpLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwO3doaWNoIGluY3VycyBhZGRpdGlvbmFsIHRyYW5zbWlz c2lvbiBsYXRlbmN5IGFuZCB1c2Ugb2YgYWRkaXRpb25hbDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwO25ldHdvcmsgcmVzb3VyY2VzLCBhZGRzIHRvIHRo ZSBuZXR3b3JrIENBUEVYIGFuZCBPUEVYLCBhbmQgZGVjcmVhc2VzPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7dGhlIHJlbGlhYmlsaXR5IG9mIHRoZSBu ZXR3b3JrIGR1ZSB0byB0aGUgaW50cm9kdWN0aW9uIG9mIGEgc2luZ2xlPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7cG9pbnQgb2YgZmFpbHVyZSBbUkZD NzMzM10uJm5ic3A7IFRoZXJlZm9yZSwgc2Vzc2lvbiBjb250aW51aXR5IGFuZCBJUDxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwO2FkZHJlc3MgcmVhY2hh YmlsaXR5IFNIT1VMRCBiZSBwcm92aWRlZCBvbmx5IHdoZW4gbmVjZXNzYXJ5LjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47 bXNvLWFkZC1zcGFjZTphdXRvIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOyAmbmJzcDtJdCBzaG91bGQgYmUgbm90ZWQgdGhhdCBpbiByZWFsaXR5IG5v dCBldmVyeSBhcHBsaWNhdGlvbiBtYXkgbmVlZDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7ICZuYnNwO3RoZXNlIGJlbmVmaXRzLiZuYnNwOyBJUCBhZGRyZXNzIHJl YWNoYWJpbGl0eSBpcyByZXF1aXJlZCBmb3IgYXBwbGljYXRpb25zPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7cnVubmluZyBhcyBzZXJ2ZXJzIChlLmcu LCBhIHdlYiBzZXJ2ZXIgcnVubmluZyBvbiB0aGUgbW9iaWxlIGhvc3QpLjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwO0J1dCwgYSB0eXBpY2FsIGNsaWVu dCBhcHBsaWNhdGlvbiAoZS5nLiwgd2ViIGJyb3dzZXIpIGRvZXMgbm90PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7bmVjZXNzYXJpbHkgcmVxdWlyZSBJ UCBhZGRyZXNzIHJlYWNoYWJpbGl0eS4mbmJzcDsgU2ltaWxhcmx5LCBzZXNzaW9uPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7Y29udGludWl0eSBpcyBu b3QgcmVxdWlyZWQgZm9yIGFsbCB0eXBlcyBvZiBhcHBsaWNhdGlvbnMgZWl0aGVyLjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwO0FwcGxpY2F0aW9ucyBw ZXJmb3JtaW5nIGJyaWVmIGNvbW11bmljYXRpb24gKGUuZy4sIHBpbmcpIGNhbiBzdXJ2aXZlPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaEN4U3BGaXJzdCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjBpbjttc28tYWRkLXNwYWNlOmF1dG8iPiZuYnNwOyAmbmJzcDt3aXRob3V0 IGhhdmluZyBzZXNzaW9uIGNvbnRpbnVpdHkgc3VwcG9ydDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb0xpc3RQYXJhZ3JhcGhDeFNwTWlkZGxlIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21z by1hZGQtc3BhY2U6YXV0byI+DQombHQ7L21nbHQmZ3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTGlzdFBhcmFncmFwaEN4U3BNaWRkbGUiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNv LWFkZC1zcGFjZTphdXRvIj4NCjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPG9sIHN0eWxlPSJtYXJn aW4tdG9wOjBpbiIgc3RhcnQ9IjQiIHR5cGU9IjEiPg0KPGxpIGNsYXNzPSJNc29MaXN0UGFyYWdy YXBoQ3hTcE1pZGRsZSIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tYWRkLXNwYWNlOmF1dG87 bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzIiPg0KUmVwbGFjZSDigJhwaW5n4oCZIHdpdGggYSBtb3Jl IHVzZWZ1bCBhcHBsaWNhdGlvbiBhcyBhbiBleGFtcGxlLjxvOnA+PC9vOnA+PC9saT48L29sPg0K PHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGhDeFNwTWlkZGxlIj5Vc2UgdGV4dCBtZXNzYWdpbmcg aW5zdGVhZC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoQ3hTcE1p ZGRsZSIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tYWRkLXNwYWNlOmF1dG8iPg0KJmx0O21n bHQmZ3Q7SSBiZWxpZXZlIHRoYXQgaXMgYSBtb3JlIGNvbnZpbmNpbmcgZXhhbXBsZS4mbHQ7L21n bHQmZ3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaEN4U3BNaWRk bGUiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWFkZC1zcGFjZTphdXRvIj4NCjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPG9sIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgc3RhcnQ9IjUiIHR5cGU9 IjEiPg0KPGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoQ3hTcE1pZGRsZSIgc3R5bGU9Im1hcmdp bi1sZWZ0OjBpbjttc28tYWRkLXNwYWNlOmF1dG87bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzIiPg0K U3BsaXQgdGhlIGZlYXR1cmUgdmVyc3VzIGl0cyBpbXBsZW1lbnRhdGlvbiBzaG91bGQgYmUgZG9u ZSBpbiBhIHNpbWlsYXIgbWFubmVyIGZvciBib3RoIHNlc3Npb24gY29udGludWl0eSBhbmQgcmVh Y2hhYmlsaXR5IHRvIGVhc2UgcmVhZGluZy48bzpwPjwvbzpwPjwvbGk+PC9vbD4NCjxwIGNsYXNz PSJNc29MaXN0UGFyYWdyYXBoQ3hTcE1pZGRsZSI+QWZ0ZXIgZ2l2aW5nIGl0IHNvbWUgdGhvdWdo dCwgSSB0ZW5kIHRvIHRoaW5rIGRpZmZlcmVudGx5LiBUaGlzIGlzIHRoZSBJbnRyb2R1Y3Rpb24g c2VjdGlvbiBhbmQgYXMgc3VjaCBzaG91bGQgYmUgc2hvcnQuIEkgZG8gbm90IHRoaW5rIHRoZSBz cGxpdHRpbmcgaXMgbmVlZGVkIHRvIHVuZGVyc3RhbmQgdGhlIHJlc3Qgb2YgdGhlIGRvY3VtZW50 LiBJIHByZWZlciB0byBrZWVwIHRoaXMNCiBzZWN0aW9uIHNob3J0LjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGhDeFNwTWlkZGxlIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MGluO21zby1hZGQtc3BhY2U6YXV0byI+DQombHQ7bWdsdCZndDtJIGFncmVlIHdpdGggeW91LiBX aGF0IGNvbmZ1c2VkIGF0IGZpcnN0IHdhcyB0aGUgc2Vzc2lvbiBjb250aW51aXR5LiZsdDsvbWds dCZndDsNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGhDeFNwTWlk ZGxlIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1hZGQtc3BhY2U6YXV0byI+DQo8bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxvbCBzdHlsZT0ibWFyZ2luLXRvcDowaW4iIHN0YXJ0PSI2IiB0eXBl PSIxIj4NCjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaEN4U3BNaWRkbGUiIHN0eWxlPSJtYXJn aW4tbGVmdDowaW47bXNvLWFkZC1zcGFjZTphdXRvO21zby1saXN0OmwxIGxldmVsMSBsZm8yIj4N CkFkZCBhIHBhcmFncmFwaCB0aGF0IGluZGljYXRlcyB0aGUgYWRkcmVzcyByZWFjaGFiaWxpdHkg Y2FuIGJlIHBlcmZvcm1lZCBieSBhcHBsaWNhdGlvbnMgdXNpbmcgb3RoZXIgbWVhbnMgdGhhbiBJ UCByZWFjaGFiaWxpdHkuPG86cD48L286cD48L2xpPjwvb2w+DQo8cCBjbGFzcz0iTXNvTGlzdFBh cmFncmFwaEN4U3BNaWRkbGUiPkkgZG8gbm90IHRoaW5rIHRoaXMgaXMgcmVxdWlyZWQuIFRoZSBt b3RpdmF0aW9uIG9mIHRoaXMgSW50cm9kdWN0aW9uIGlzIHRvIGNvbnZpbmNlIHRoZSByZWFkZXIg dGhhdCB0aGVyZSBpcyBhIGJlbmVmaXQgZnJvbSBlbmFibGluZyBhcHBsaWNhdGlvbnMgdG8gaW5k aWNhdGUgdGhlaXIgcmVxdWlyZW1lbnRzIGZyb20gdGhlIG1vYmlsZSBuZXR3b3JrLCByYXRoZXIg dGhhbiBnZXR0aW5nDQogdGhlIGZ1bGwgc2VydmljZSBzdXBwb3J0LiBJIHRoaW5rIHRoZSBtZXNz YWdlIGlzIGNsZWFyIGFzIGl0IGlzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQ YXJhZ3JhcGhDeFNwTWlkZGxlIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1hZGQtc3BhY2U6 YXV0byI+DQombHQ7bWdsdCZndDtJIGFncmVlIGZvciB0aGUgc2FtZSBhcyBhYm92ZS4gVG8gbWUg SSBiZWxpZXZlIHdoYXQgd291bGQgaGF2ZSBiZWVuIHZlcnkgY29udmluY2luZyBpcyBhbiBhcHBy b2FjaCB3aGVyZSB3ZSBtZW50aW9uIHdoYXQgYXBwbGljYXRpb24gbmVlZCByYXRoZXIgdGhhbiB3 aGF0IHRoZXkgZG8gbm90IG5lZWQuIEJ1dCBhZ2FpbiB0aGF0IGlzIG1vcmUgcmVsYXRlZCB0byB0 aGUgcHJlc2VudGF0aW9uLiZsdDsvbWdsdCZndDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29MaXN0UGFyYWdyYXBoQ3hTcE1pZGRsZSIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tYWRk LXNwYWNlOmF1dG8iPg0KPG86cD4mbmJzcDs8L286cD48L3A+DQo8b2wgc3R5bGU9Im1hcmdpbi10 b3A6MGluIiBzdGFydD0iNyIgdHlwZT0iMSI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGhD eFNwTWlkZGxlIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1hZGQtc3BhY2U6YXV0bzttc28t bGlzdDpsMSBsZXZlbDEgbGZvMiI+DQpBZGQgYSByZWZlcmVuY2UgdG8gUkZDIDUwMTQgYW5kIHRo ZSB1c2FnZSBvZiBob21lIGFuZCBjYXJlLW9mIGFkZHJlc3Nlcy48bzpwPjwvbzpwPjwvbGk+PC9v bD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoQ3hTcE1pZGRsZSI+QWN0dWFsbHksIGZvciBt b2JpbGUgSVAsIHRoaXMgZG9jdW1lbnQgaXMgbm90IHJlcXVpcmVkLiBJZiB0aGUgbW9iaWxlIGhv c3Qgc3VwcG9ydHMgbW9iaWxlIElQLCBpdCBjYW4gZW5hYmxlIGFwcGxpY2F0aW9ucyB0byBzZWxl Y3QgZWl0aGVyIGEgaG9tZSBhZGRyZXNzIG9yIGEgY2FyZS1vZiBhZGRyZXNzIHRvIHVzZSBmb3Ig dGhlIElQIGNvbm5lY3Rpb24gYW5kIGJ5IHRoYXQsIHVzZQ0KIG9yIGNob29zZSBub3QgdG8gdXNl IG1vYmlsaXR5IHNlcnZpY2VzIHByaWRlZCBieSB0aGUgbW9iaWxlIG5ldHdvcmsuPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaEN4U3BNaWRkbGUiPlRoaXMgZG9jdW1l bnQgYWRkcmVzc2VzIHRoZSBjYXNlIHdoZXJlIHRoZSBuZXR3b3JrIHByb3ZpZGUgdGhlc2Ugc2Vy dmljZXMgYnkgcHJveHkgYW5kIHRodXMsIHByb3ZpZGVzIHRoZSBmdWxsIG1vYmlsaXR5IHNlcnZp Y2UgcmVnYXJkbGVzcyBvZiB3aGV0aGVyIG9yIG5vdCB0aGV5IGFyZSBuZWVkZWQuPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaEN4U3BNaWRkbGUiPkZvciBwcm94eSBz ZXJ2aWNlcywgd2UgbmVlZCBhIHdheSBmb3IgYXBwbGljYXRpb25zIHRvIGV4cHJlc3MgdGhlaXIg dHJ1ZSBuZWVkcyBhbmQgZm9yIHRoZSBuZXR3b3JrIHN0YWNrIHRvIGNvbnZleSB0aGVzZSBuZWVk cyB0byB0aGUgbmV0d29yay48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdy YXBoQ3hTcE1pZGRsZSIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tYWRkLXNwYWNlOmF1dG8i Pg0KJmx0O21nbHQmZ3Q7SW4gbXkgb3BpbmlvbiDigJMgYW5kIG5vdCBiZWluZyBhbiBtb2JpbGl0 eSBleHBlcnQg4oCTIHRoZSBhZGRpdGlvbiBvZiB0aGUgdGV4dCBpbiB0aGUgaW50cm9kdWN0aW9u IHdvdWxkIGJlIGdyZWF0LiAmbHQ7L21nbHQmZ3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTGlzdFBhcmFncmFwaEN4U3BNaWRkbGUiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWFk ZC1zcGFjZTphdXRvIj4NCjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQ YXJhZ3JhcGhDeFNwTWlkZGxlIj4mbmJzcDsgPG86cD48L286cD48L3A+DQo8b2wgc3R5bGU9Im1h cmdpbi10b3A6MGluIiBzdGFydD0iOCIgdHlwZT0iMSI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJh Z3JhcGhDeFNwTWlkZGxlIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1hZGQtc3BhY2U6YXV0 bzttc28tbGlzdDpsMSBsZXZlbDEgbGZvMiI+DQpJbmRpY2F0ZSDigJhvbiBkZW1hbmTigJkgaW4g dGhlIEludHJvZHVjdGlvbi48bzpwPjwvbzpwPjwvbGk+PC9vbD4NCjxwIGNsYXNzPSJNc29MaXN0 UGFyYWdyYXBoQ3hTcE1pZGRsZSI+SSB0aG91Z2h0IHRoaXMgaXMgY2xlYXIgZnJvbSB0aGUgZmFj dCB0aGF0IGVhY2ggYXBwbGljYXRpb24gaW5kaWNhdGVzIGl0IG1vYmlsaXR5IHNlcnZpY2UgcmVx dWlyZW1lbnRzLiBBcyBhcHBsaWNhdGlvbnMgY291bGQgYmUgbGF1bmNoZWQgc2VwYXJhdGVseSBm cm9tIGVhY2ggb3RoZXIgd2l0aCBwb3NzaWJsZSBsYXJnZSB0aW1lIGdhcHMsIG9uLWRlbWFuZCBp cyBkZWR1Y3RlZC4NCiBCdXQgdG8gYmUgb24gdGhlIHNhZmUgc2lkZSwgSSB3aWxsIGFkZCDigJhv biBkZW1hbmTigJkuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaEN4 U3BNaWRkbGUiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWFkZC1zcGFjZTphdXRvIj4NCiZs dDttZ2x0Jmd0O29rLiZsdDsvbWdsdCZndDs8bzpwPjwvbzpwPjwvcD4NCjxvbCBzdHlsZT0ibWFy Z2luLXRvcDowaW4iIHN0YXJ0PSI5IiB0eXBlPSIxIj4NCjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFn cmFwaEN4U3BNaWRkbGUiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWFkZC1zcGFjZTphdXRv O21zby1saXN0OmwxIGxldmVsMSBsZm8yIj4NCkluIHRoZSBzZXZlcmFsIGRlZmluaXRpb25zIG9m IHR5cGVzIElQIGFkZHJlc3MgaW4gc2VjdGlvbiAzIHJlcGxhY2Ug4oCYZ3VhcmFudGVl4oCZIHdp dGgg4oCYcmVtYWluc+KAmTxvOnA+PC9vOnA+PC9saT48L29sPg0KPHAgY2xhc3M9Ik1zb0xpc3RQ YXJhZ3JhcGhDeFNwTWlkZGxlIj5JIHByZWZlciDigJhndWFyYW50ZWXigJkgYmVjYXVzZSBpdCBi ZXR0ZXIgaW5kaWNhdGVzIHRoZSBjb21taXRtZW50IG9mIHRoZSBuZXR3b3JrIHRvIHByZXNlcnZl IHRoZSBhZGRyZXNzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGhD eFNwTWlkZGxlIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1hZGQtc3BhY2U6YXV0byI+DQom bHQ7bWdsdCZndDtvaywgSSBhbSBub3QgRW5nbGlzaCBuYXRpdmUsIHNvIHlvdXIgY2hvaWNlIGlz IG1vcmUgYXBwcm9wcmlhdGVkLiBIb3dldmVyIEkgZ290IHRoYXQgZ3VhcmFudGVlIGNvbWVzIHdp dGggbW9yZSBjb21taXRtZW50LiZsdDsvbWdsdCZndDs8bzpwPjwvbzpwPjwvcD4NCjxvbCBzdHls ZT0ibWFyZ2luLXRvcDowaW4iIHN0YXJ0PSIxMCIgdHlwZT0iMSI+DQo8bGkgY2xhc3M9Ik1zb0xp c3RQYXJhZ3JhcGhDeFNwTWlkZGxlIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1hZGQtc3Bh Y2U6YXV0bzttc28tbGlzdDpsMSBsZXZlbDEgbGZvMiI+DQpBIHN1Z2dlc3Rpb24gcmVnYXJkaW5n IHRoZSBkZWZpbml0aW9uIG9mIE5vbi1wZXJzaXN0ZW50IElQIGFkZHJlc3MuPG86cD48L286cD48 L2xpPjwvb2w+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaEN4U3BNaWRkbGUiPkkgZGlkIG5v dCBxdWl0ZSB1bmRlcnN0YW5kIHRoaXMgc3VnZ2VzdGlvbi4gU29tZXRoaW5nIHRvIGRvIHdpdGgg SG9tZSBBZGRyZXNzIGFuZCBtb2JpbGUgSVAuIEhvd2V2ZXIsIEkgYmVsaWV2ZSB0aGUgZGVmaW5p dGlvbiBvZiBOb24tcGVyc2lzdGVudCBJUCBhZGRyZXNzIGluIHRoaXMgc2VjdGlvbiBpcyBnb29k IGFzIGl0IGlzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGhDeFNw TWlkZGxlIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1hZGQtc3BhY2U6YXV0byI+DQombHQ7 bWdsdCZndDtJIHdhcyB3b25kZXJpbmcgaG93IGRpZmZlcmVudCB0aGUgYWRkcmVzcyBjb3VsZCBi ZSBmcm9tIGEgY2FyZS1vZi1hZGRyZXNzLiBBZ2FpbiBteSBjb25mdXNpb24gd2FzIHRoYXQgSSBj b25zaWRlcmVkIHRoZSBob3N0IGEgTUlQIG5vZGUuJmx0Oy9tZ2x0Jmd0OzxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGhDeFNwTWlkZGxlIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MGluO21zby1hZGQtc3BhY2U6YXV0byI+DQo8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxvbCBz dHlsZT0ibWFyZ2luLXRvcDowaW4iIHN0YXJ0PSIxMSIgdHlwZT0iMSI+DQo8bGkgY2xhc3M9Ik1z b0xpc3RQYXJhZ3JhcGhDeFNwTWlkZGxlIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1hZGQt c3BhY2U6YXV0bzttc28tbGlzdDpsMSBsZXZlbDEgbGZvMiI+DQpUaGVyZSBhcmUgYWRkaXRpb25h bCBjb21tZW50cyByZWdhcmRpbmcgbW9iaWxlIElQLjxvOnA+PC9vOnA+PC9saT48L29sPg0KPHAg Y2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGhDeFNwTWlkZGxlIj5BcyBJIGluZGljYXRlZCBiZWZvcmUs IHRoaXMgZG9jdW1lbnQgaXMgbm90IGFib3V0IG1vYmlsZSBJUCB3aGVyZSB0aGUgbW9iaWxlIGhv c3QgaGFzIGNvbnRyb2wgb3ZlciB0aGUgc2VsZWN0aW9uIG9mIGNhcmUtb2YgdmVyc3VzIEhvbWUg YWRkcmVzc2VzLiBJdCBpcyBhYm91dCBwcm94eSBzb2x1dGlvbnMsIGluIHdoaWNoIHRoZSBtb2Jp bGUgaG9zdCBkb2VzIG5vdCBoYXZlIGFueQ0KIGNvbnRyb2wgb3ZlciB0aGUgbW9iaWxpdHkgc2Vy dmljZSBiZWNhdXNlIGl0IGlzIGRvbmUgYnktcHJveHkgYnkgdGhlIG5ldHdvcmsuPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaEN4U3BNaWRkbGUiIHN0eWxlPSJtYXJn aW4tbGVmdDowaW47bXNvLWFkZC1zcGFjZTphdXRvIj4NCiZsdDttZ2x0Jmd0O0V4YWN0bHkuIEkg YXBvbG9neSBmb3Igbm90IGNhdGNoaW5nIHRoaXMuJmx0Oy9tZ2x0Jmd0OzxvOnA+PC9vOnA+PC9w Pg0KPG9sIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgc3RhcnQ9IjEyIiB0eXBlPSIxIj4NCjxsaSBj bGFzcz0iTXNvTGlzdFBhcmFncmFwaEN4U3BNaWRkbGUiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47 bXNvLWFkZC1zcGFjZTphdXRvO21zby1saXN0OmwxIGxldmVsMSBsZm8yIj4NCk5lZWQgdG8gbWVu dGlvbiB0aGUgb3ZlcmxhcHMgb2YgdGhlIGFkZHJlc3MgdHlwZXMuPG86cD48L286cD48L2xpPjwv b2w+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaEN4U3BNaWRkbGUiPlllcywgdGhlcmUgYXJl IG92ZXJsYXBzIGJ1dCBJIGRvIG5vdCBzZWUgd2h5IG1lbnRpb25pbmcgdGhlbSBoZWxwcy4NCjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGhDeFNwTWlkZGxlIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MGluO21zby1hZGQtc3BhY2U6YXV0byI+DQombHQ7bWdsdCZndDt0aGF0 IHdhcyBtb3JlIGZvciB0aGUgc2VsZWN0aW9uLiZsdDsvbWdsdCZndDs8bzpwPjwvbzpwPjwvcD4N CjxvbCBzdHlsZT0ibWFyZ2luLXRvcDowaW4iIHN0YXJ0PSIxMyIgdHlwZT0iMSI+DQo8bGkgY2xh c3M9Ik1zb0xpc3RQYXJhZ3JhcGhDeFNwTWlkZGxlIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21z by1hZGQtc3BhY2U6YXV0bzttc28tbGlzdDpsMSBsZXZlbDEgbGZvMiI+DQpMaXN0IHRoZSBkaWZm ZXJlbnQgYWRkcmVzcyB0eXBlcyBpbiB0aGUgc2FtZSBvcmRlciBpbiBhbGwgc2VjdGlvbnMgdG8g ZWFzZSB0aGUgcmVhZGluZy48bzpwPjwvbzpwPjwvbGk+PC9vbD4NCjxwIGNsYXNzPSJNc29MaXN0 UGFyYWdyYXBoQ3hTcE1pZGRsZSI+SSBhZ3JlZS4gQ2hhbmdpbmcgdGhlIG9yZGVyIGluIHNlY3Rp b24gMy4zLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGhDeFNwTWlk ZGxlIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1hZGQtc3BhY2U6YXV0byI+DQombHQ7bWds dCZndDtvayx0aGF0IHdhcyBhIG5pdC4mbHQ7L21nbHQmZ3Q7PG86cD48L286cD48L3A+DQo8b2wg c3R5bGU9Im1hcmdpbi10b3A6MGluIiBzdGFydD0iMTQiIHR5cGU9IjEiPg0KPGxpIGNsYXNzPSJN c29MaXN0UGFyYWdyYXBoQ3hTcE1pZGRsZSIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tYWRk LXNwYWNlOmF1dG87bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzIiPg0KQSBjb21tZW50IGFib3V0IGhh dmluZyB0aGUgYXBwbGljYXRpb24gcmVxdWVzdCB0aGUgbWluaW1hbCBjYXBhYmlsaXR5IGFuZCB0 aGUgbmV0d29yayBhdXRvbWF0aWNhbGx5IHByb3ZpZGluZyB0aGUgbmV4dCBsZXZlbCBpZiBpdCBj YW5ub3QgZnVsZmlsbCB0aGlzIG1pbmltYWwgbGV2ZWwuPG86cD48L286cD48L2xpPjwvb2w+DQo8 cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaEN4U3BNaWRkbGUiPlRoaXMgaXMgYSBwb2ludCB3ZSBj b25zaWRlcmVkIGFsb25nIHdpdGggZW5hYmxpbmcgYXBwbGljYXRpb25zIHRvIHJlcXVlc3Qgc2V2 ZXJhbCBsZXZlbHMgaW4gcGFyYWxsZWwgYW5kIGxldHRpbmcgdGhlIG5ldHdvcmsgc2VsZWN0IHRo ZSBtb3N0IHByZWZlcmFibGUgb25lLiBBZnRlciBzb21lIGV2YWx1YXRpb24sIHdlIGRlY2lkZWQg dGhhdCB0aGlzIGZsZXhpYmlsaXR5IGlzIGNvdW50ZXItcHJvZHVjdGl2ZQ0KIGFuZCBpdCBpcyBi ZXN0IHRvIHNwZWNpZnkgYSBzcGVjaWZpYyBzZXJ2aWNlIHR5cGUsIGFuZCBleHBlY3QgaXQgdG8g ZWl0aGVyIGJlIGZ1bGZpbGxlZCBvciBoYXZlIHRoZSByZXF1ZXN0IGZhaWwuIFRoaXMgd2F5LCBu byDigJhzbWFydOKAmSBkZWNpc2lvbnMgYXJlIG1hZGUgYXV0b21hdGljYWxseSBieSB0aGUgbmV0 d29yay4gUmVtZW1iZXIgaG93ZXZlciwgdGhhdCB0aGUgYXBwbGljYXRpb24gcmVxdWVzdHMgdGhl IHNlcnZpY2UgZnJvbSB0aGUgbmV0d29yaw0KIHN0YWNrLCBhbmQgdGhlIG5ldHdvcmsgc3RhY2sg cmVxdWVzdHMgaXQgZnJvbSB0aGUgbmV0d29yay4gV2UgZG8gbm90IHByb3ZpZGUgYW55IHJlc3Ry aWN0aW9ucyBvbiB0aGUgaW1wbGVtZW50YXRpb25zIG9mIG5ldHdvcmsgc3RhY2tzLiBTb21lIGNv dWxkIHBlcmZvcm0gY2FjaGluZyBvZiBuZXR3b3JrIGNhcGFiaWxpdGllcywgYW5kIHNlbGVjdCB0 byByZXNwb25kIHRvIGFwcGxpY2F0aW9ucyB3aXRob3V0IGludGVyYWN0aW5nIHdpdGggdGhlIG5l dHdvcmsuJm5ic3A7DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBo Q3hTcE1pZGRsZSIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tYWRkLXNwYWNlOmF1dG8iPg0K Jmx0O21nbHQmZ3Q7b2suJmx0Oy9tZ2x0Jmd0OzxvOnA+PC9vOnA+PC9wPg0KPG9sIHN0eWxlPSJt YXJnaW4tdG9wOjBpbiIgc3RhcnQ9IjE1IiB0eXBlPSIxIj4NCjxsaSBjbGFzcz0iTXNvTGlzdFBh cmFncmFwaEN4U3BNaWRkbGUiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWFkZC1zcGFjZTph dXRvO21zby1saXN0OmwxIGxldmVsMSBsZm8yIj4NCkFub3RoZXIgY29tbWVudCBhYm91dCB0aGUg YmVoYXZpb3Igb2YgdGhlIEFQSSwgYXNzdW1pbmcgYSByZXF1ZXN0IG1pZ2h0IG5vdCBiZSBmdWxm aWxsZWQgd2l0aG91dCByZXN1bHRpbmcgaW4gYW4gZXJyb3IgcmVzcG9uc2UuPG86cD48L286cD48 L2xpPjwvb2w+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaEN4U3BNaWRkbGUiPlNvIGFzIEkg ZGVzY3JpYmVkIHByZXZpb3VzbHksIEFQSSByZXF1ZXN0cyB0aGF0IGNhbm5vdCBiZSBmdWxmaWxs ZWQgZXhhY3RseSBhcyBzcGVjaWZpZWQsIHJlc3VsdCB3aXRoIGFuIGVycm9yIHJlc3BvbnNlLjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGhDeFNwTWlkZGxlIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MGluO21zby1hZGQtc3BhY2U6YXV0byI+DQombHQ7bWdsdCZndDtnb3Qg aXQuJmx0Oy9tZ2x0Jmd0OzxvOnA+PC9vOnA+PC9wPg0KPG9sIHN0eWxlPSJtYXJnaW4tdG9wOjBp biIgc3RhcnQ9IjE2IiB0eXBlPSIxIj4NCjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaEN4U3BN aWRkbGUiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWFkZC1zcGFjZTphdXRvO21zby1saXN0 OmwxIGxldmVsMSBsZm8yIj4NCkEgcXVlc3Rpb24gYWJvdXQgdGhlIE9OX05FVCBmbGFnLjxvOnA+ PC9vOnA+PC9saT48L29sPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGhDeFNwTWlkZGxlIj5Z ZXMsIHlvdXIgdW5kZXJzdGFuZGluZyBpcyBjb3JyZWN0LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb0xpc3RQYXJhZ3JhcGhDeFNwTWlkZGxlIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21z by1hZGQtc3BhY2U6YXV0byI+DQombHQ7bWdsdCZndDs8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7U2Vnb2UgVUkgRW1vamkmcXVvdDssc2Fucy1zZXJpZiI+JiMxMjg1MjE7PC9zcGFuPiZs dDsvbWdsdCZndDs8bzpwPjwvbzpwPjwvcD4NCjxvbCBzdHlsZT0ibWFyZ2luLXRvcDowaW4iIHN0 YXJ0PSIxNyIgdHlwZT0iMSI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGhDeFNwTWlkZGxl IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1hZGQtc3BhY2U6YXV0bzttc28tbGlzdDpsMSBs ZXZlbDEgbGZvMiI+DQpSZXF1ZXN0IGFuIGV4YW1wbGUgd2l0aCB0aGUgT05fTkVUIGZsYWcuPG86 cD48L286cD48L2xpPjwvb2w+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaEN4U3BNaWRkbGUi PlRoZXJlIGNvdWxkIGJlIG90aGVyIGV4YW1wbGVzIGFzIHdlbGwuIFRoZXJlIGFyZSBhbGwga2lu ZHMgb2YgY2FzZXMgdGhhdCBjb3VsZCBiZSBwcmVzZW50ZWQuIFRoZXJlIGlzIGEgdHJhZGUtb2Zm IGJldHdlZW4gdGhlIHNpemUgb2YgYW4gUkZDIGFuZCBhIHRleHQgYm9vay4gV2UgdGhvdWdodCBp dCB3b3VsZCBiZSB1c2VmdWwgdG8gcHJvdmlkZSBhbiBleGFtcGxlIG9mIGEgbm9uLXRyaXZpYWwN CiBjYXNlIGFuZCBsZWF2ZSBvdGhlciBjYXNlcyB0byBmdXR1cmUgdGV4dCBib29rcyBhbmQgdHV0 b3JpYWxzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGhDeFNwTWlk ZGxlIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1hZGQtc3BhY2U6YXV0byI+DQombHQ7bWds dCZndDthZ3JlZSZsdDsvbWdsdCZndDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0 UGFyYWdyYXBoQ3hTcE1pZGRsZSI+Jm5ic3A7IDxvOnA+PC9vOnA+PC9wPg0KPG9sIHN0eWxlPSJt YXJnaW4tdG9wOjBpbiIgc3RhcnQ9IjE4IiB0eXBlPSIxIj4NCjxsaSBjbGFzcz0iTXNvTGlzdFBh cmFncmFwaEN4U3BNaWRkbGUiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWFkZC1zcGFjZTph dXRvO21zby1saXN0OmwxIGxldmVsMSBsZm8yIj4NCk9uRGVtYW4gdmVyc3VzIE9uIERlbWFuZCB2 ZXJzdXMgT24tRGVtYW5kLiBCZSBjb25zaXN0ZW50LjxvOnA+PC9vOnA+PC9saT48L29sPg0KPHAg Y2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGhDeFNwTWlkZGxlIj5JIGFncmVlLiBXaWxsIGJlIGZpeGVk LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGhDeFNwTWlkZGxlIiBz dHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1hZGQtc3BhY2U6YXV0byI+DQombHQ7bWdsdCZndDtv ayZsdDsvbWdsdCZndDs8bzpwPjwvbzpwPjwvcD4NCjxvbCBzdHlsZT0ibWFyZ2luLXRvcDowaW4i IHN0YXJ0PSIxOSIgdHlwZT0iMSI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGhDeFNwTWlk ZGxlIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1hZGQtc3BhY2U6YXV0bzttc28tbGlzdDps MSBsZXZlbDEgbGZvMiI+DQpJUCB2NiB2ZXJzdXMgSVB2Ni4gQmUgY29uc2lzdGVudC48bzpwPjwv bzpwPjwvbGk+PC9vbD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoQ3hTcE1pZGRsZSI+SSBh Z3JlZS4gV2lsbCBiZSBmaXhlZC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFy YWdyYXBoQ3hTcE1pZGRsZSIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tYWRkLXNwYWNlOmF1 dG8iPg0KJmx0O21nbHQmZ3Q7b2smbHQ7L21nbHQmZ3Q7PG86cD48L286cD48L3A+DQo8b2wgc3R5 bGU9Im1hcmdpbi10b3A6MGluIiBzdGFydD0iMjAiIHR5cGU9IjEiPg0KPGxpIGNsYXNzPSJNc29M aXN0UGFyYWdyYXBoQ3hTcE1pZGRsZSIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tYWRkLXNw YWNlOmF1dG87bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzIiPg0KRGVzY3JpYmUgdGhlIG1lY2hhbmlz bSBpbiB3aGljaCB0aGUgYWRkcmVzcyB0eXBlIGlzIGluZGljYXRlZCBieSB0aGUgbmV0d29yayB0 byB0aGUgaG9zdC48bzpwPjwvbzpwPjwvbGk+PC9vbD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdy YXBoQ3hTcE1pZGRsZSI+VW5mb3J0dW5hdGVseSBJIGNhbm5vdC4gU3VjaCBhIG1lY2hhbmlzbSBk b2VzIG5vdCBleGlzdCBhdCB0aGUgbW9tZW50LiBXZSBhcmUgd29ya2luZyBvbiB0aGF0IGFzIHdl bGwuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaEN4U3BNaWRkbGUi IHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWFkZC1zcGFjZTphdXRvIj4NCiZsdDttZ2x0Jmd0 O25vdCBzdXJlIHdlIHNob3VsZCBub3QgbWVudGlvbiB0aGF0IGlzIG9uZ29pbmcgd29yayBhcyB3 ZWxsIGFzIHBvc3NpYmxlIGRpcmVjdGlvbnMuJmx0Oy9tZ2x0Jmd0OzxvOnA+PC9vOnA+PC9wPg0K PG9sIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgc3RhcnQ9IjIxIiB0eXBlPSIxIj4NCjxsaSBjbGFz cz0iTXNvTGlzdFBhcmFncmFwaEN4U3BNaWRkbGUiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNv LWFkZC1zcGFjZTphdXRvO21zby1saXN0OmwxIGxldmVsMSBsZm8yIj4NCkluIHNlY3Rpb24gNS4y LCBuZWVkIHRvIGRlc2NyaWJlIGhvdyB0aGUgbmV3IElQIHN0YWNrIG5lZWRzIHRvIGJlaGF2ZSB3 aGVuIGFuIGFwcGxpY2F0aW9uIHRoYXQgZG9lcyBub3Qgc3VwcG9ydCBPbi1EZW1hbmQgb3BlbnMg aW5pdGlhdGVzIGEgbmV0d29yayBjb25uZWN0aW9uLiDigJhsZWdhY3kgbWFubmVy4oCZIGlzIG5v dCBhIGdvb2QgZGVzY3JpcHRpb24uPG86cD48L286cD48L2xpPjwvb2w+DQo8cCBjbGFzcz0iTXNv TGlzdFBhcmFncmFwaEN4U3BNaWRkbGUiPlRoZSBuZXh0IHBhcmFncmFwaCBpbiB0aGlzIHNlY3Rp b24gZG9lcyBleGFjdGx5IHRoYXQuIERlc2NyaWJlcyBob3cgdGhlIElQIHN0YWNrIHNob3VsZCBp bnRlcmFjdCB3aXRoIHRoZSBuZXR3b3JrLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb0xp c3RQYXJhZ3JhcGhDeFNwTWlkZGxlIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1hZGQtc3Bh Y2U6YXV0byI+DQombHQ7bWdsdCZndDtvay4gSSBiZWxpZXZlIHdoYXQgd2FzIHVuY2xlYXIgdG8g bWUgd2FzIHRoYXQgSSBleHBlY3RlZCBsZWdhY3kgdG8gaW5jbHVkZSBNSVAgbm9kZXMuICZsdDsv bWdsdCZndDs8bzpwPjwvbzpwPjwvcD4NCjxvbCBzdHlsZT0ibWFyZ2luLXRvcDowaW4iIHN0YXJ0 PSIyMiIgdHlwZT0iMSI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGhDeFNwTWlkZGxlIiBz dHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1hZGQtc3BhY2U6YXV0bzttc28tbGlzdDpsMSBsZXZl bDEgbGZvMiI+DQpQbGFjZSB0aGUgc3RhdGVtZW50IGFib3V0IG5ldHdvcmtzIHN1cHBvcnRpbmcg b3Igbm90IHN1cHBvcnRpbmcgT24tRGVtYW5kIGZ1bmN0aW9uYWxpdHkgaW4gdGhlIGludHJvZHVj dGlvbi48bzpwPjwvbzpwPjwvbGk+PC9vbD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoQ3hT cE1pZGRsZSI+SSBwcmVmZXIgbm90IHRvIGRvIHRoYXQuIEkgYW0gdHJ5aW5nIHRvIGtlZXAgdGhl IEludHJvZHVjdGlvbiBzaG9ydCBhbmQgY3Jpc3AuIExpc3RpbmcgYWxsIHVzZS1jYXNlcywgYmFj a3dhcmRzIGNvbXBhdGliaWxpdHkgYW5kIG90aGVyIGRldGFpbHMg4oCTIGZvciB0aGF0IHdlIGhh dmUgdGhlIHJlc3Qgb2YgdGhlIGRvY3VtZW50LiBUaGUg4oCYSW50cm9kY3V0aW9u4oCZIGluIG15 IG9waW5pb24NCiBzaG91bGQgb25seSBwcm92aWRlIGluZm9ybWF0aW9uIHRvIGhlbHAgdGhlIHJl YWRlciBkZWNpZGUgaXQgaXQgc2hvdWxkIGNvbnRpbnVlIHJlYWRpbmcgdGhlIGRvY3VtZW50IG9y IG5vdC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoQ3hTcE1pZGRs ZSIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tYWRkLXNwYWNlOmF1dG8iPg0KJmx0O21nbHQm Z3Q7VGhpcyBpcyBjbGVhciB0byBtZSBrbm93LiZsdDsvbWdsdCZndDs8bzpwPjwvbzpwPjwvcD4N CjxvbCBzdHlsZT0ibWFyZ2luLXRvcDowaW4iIHN0YXJ0PSIyMyIgdHlwZT0iMSI+DQo8bGkgY2xh c3M9Ik1zb0xpc3RQYXJhZ3JhcGhDeFNwTWlkZGxlIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21z by1hZGQtc3BhY2U6YXV0bzttc28tbGlzdDpsMSBsZXZlbDEgbGZvMiI+DQpUaGUgZGVzY3JpcHRp b24gcmVnYXJkaW5nIHRoZSB1c2UtY2FzZSBvZiB1c2luZyBib3RoIHNldHNvY2tvcHQoKSBhbmQg c2V0c2MoKS9iaW5kKCkgaXMgaGFyZCB0byByZWFkLiBDbGFyaWZ5LjxvOnA+PC9vOnA+PC9saT48 L29sPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGhDeFNwTWlkZGxlIj5PSy4gSSB3aWxsIHRy eSB0byBzaW1wbGlmeSBpdC4gQnkgdGhlIHdheSwgeW91ciB1bmRlcnN0YW5kaW5nIGlzIGNvcnJl Y3QuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaEN4U3BNaWRkbGUi IHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWFkZC1zcGFjZTphdXRvIj4NCiZsdDttZ2x0Jmd0 O1RoYXQgd2FzIGEgbml0LiZsdDsvbWdsdCZndDs8bzpwPjwvbzpwPjwvcD4NCjxvbCBzdHlsZT0i bWFyZ2luLXRvcDowaW4iIHN0YXJ0PSIyNCIgdHlwZT0iMSI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQ YXJhZ3JhcGhDeFNwTWlkZGxlIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1hZGQtc3BhY2U6 YXV0bzttc28tbGlzdDpsMSBsZXZlbDEgbGZvMiI+DQpBIGNvbW1lbnQgYWJvdXQgdGhlIHBsYWNl bWVudCBvZiB0aGUgZmxhZ3MgYW5kIGFkZHJlc3MgdHlwZXMuPG86cD48L286cD48L2xpPjwvb2w+ DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaEN4U3BNaWRkbGUiPkkgZGlkIG5vdCBxdWl0ZSBn ZXQgdGhpcyBjb21tZW50LiBJIHdvdWxkIGxpa2UgdG8gY2xhcmlmeSB0aGF0IHdlIGFyZSBwcm92 aWRpbmcgdGhlIFNvY2tldCBBUEkgYXMgYW4gZXhhbXBsZSB0byBjbGFyaWZ5IHRoZSBjb25jZXB0 LiBXZSBleHBlY3Qgb3RoZXIgc3RhbmRhcmQgYm9kaWVzIHRvIHVzZSB0aGlzIGRvY3VtZW50IHRv IHNwZWNpZnkgdGhlIGV4YWN0IGltcGxlbWVudGF0aW9uDQogaW4gZGlmZmVyZW50IHByb2dyYW1t aW5nIGxhbmd1YWdlcy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBo Q3hTcE1pZGRsZSIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tYWRkLXNwYWNlOmF1dG8iPg0K Jmx0O21nbHQmZ3Q7SSBlbnZpc2lvbmVkIHRoYXQgRkxBR1MgYXJlIHRoZSBzdGFuZGFyZCB3YXkg YXBwbGljYXRpb25zIHdpbGwgdXNlIHRvIGNvbW11bmljYXRlIHRoZWlyIG5lZWQgdG8gdGhlIE9T LiBUaGlzIGlzIG5vdCBhbiBJQU5BIHJlZ2lzdHJ5LCBidXQgSSB3b3VsZCBoYXZlIGV4cGVjdGVk IHRvIGhhdmUgdGhlIGxpc3QgZGVmaW5lZCBpbiBhIGhlYWRlciBmaWxlLiZsdDsvbWdsdCZndDs8 bzpwPjwvbzpwPjwvcD4NCjxvbCBzdHlsZT0ibWFyZ2luLXRvcDowaW4iIHN0YXJ0PSIyNSIgdHlw ZT0iMSI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGhDeFNwTWlkZGxlIiBzdHlsZT0ibWFy Z2luLWxlZnQ6MGluO21zby1hZGQtc3BhY2U6YXV0bzttc28tbGlzdDpsMSBsZXZlbDEgbGZvMiI+ DQpTZWN1cml0eSB0aHJlYXRzLjxvOnA+PC9vOnA+PC9saT48L29sPg0KPHAgY2xhc3M9Ik1zb0xp c3RQYXJhZ3JhcGhDeFNwTWlkZGxlIj5JIHdvdWxkIGxpa2Ugc29tZSBjbGFyaWZpY2F0aW9uIGFi b3V0IHRoZXNlIHRocmVhdHMuIE15IHVuZGVyc3RhbmRpbmcgaXMgdGhhdCB0aGVzZSB0aHJlYXRz IGFyZSByZWxldmFudCB0byB0aGUgcHJvdG9jb2wgdXNlIGJ5IHRoZSBtb2JpbGUgaG9zdCAob3Ig c3BlY2lmaWNhbGx5IGl0cyBJUCBzdGFjaykgdG8gaW50ZXJhY3Qgd2l0aCB0aGUgbmV0d29yayB0 byBjb252ZXkgdGhlIGRlc2lyZWQNCiBtb2JpbGl0eSBzZXJ2aWNlLCBhbmQgcmVjZWl2ZSB0aGUg Z3JhbnRlZCBzZXJ2aWNlLiA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdy YXBoQ3hTcExhc3QiPkJ1dCB0aGlzIGRvY3VtZW50IGRvZXMgbm90IGRlZmluZSB0aGVzZSBwcm90 b2NvbHMuIEl0IGRlZmluZXMgdGhlIE9uLURlbWFuZCBjb25jZXB0IGFuZCB0aGUgZmVhdHVyZXMg bmVlZGVkIGJ5IHRoZSBBUEkgYmV0d2VlbiBhcHBsaWNhdGlvbnMgYW5kIHRoZSBuZXR3b3JrIHN0 YWNrLiBTaG91bGRu4oCZdCB0aGVzZSB0aHJlYXRzIGJlIGRlc2NyaWJlZCBpbiB0aGUgc3BlY2lm aWNhdGlvbg0KIG9mIHRoZSBwcm90b2NvbCBiZXR3ZWVuIHRoZSBtb2JpbGUgaG9zdCBhbmQgbmV0 d29yaz88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmx0O21nbHQmZ3Q7SSBiZWxpZXZl IHRoYXQgdGhlIHRocmVhdHMgYXBwbHkgdG8gdGhlIGFiaWxpdHkgdG8gcmVxdWVzdCBkaWZmZXJl bnQgdHlwZXMgb2YgYWRkcmVzc2VzIGFzIHdlbGwgYXMgdGhlIGluZm9ybWF0aW9uIGxlYWtlZCBi eSB0aGUgSVAgYWRkcmVzcyByZWdhcmRpbmcgdGhlIGFwcGxpY2F0aW9uLiBUaGUgcHJvdG9jb2wg YmV0d2VlbiB0aGUgbW9iaWxlIGhvc3QgYW5kIHRoZSBuZXR3b3JrIHdpbGwgYWxzbw0KIGhhdmUg dG8gbWVudGlvbiBzb21lIG9mIHRoZXNlIHRocmVhdHMsIGJ1dCB0aGVzZSBhcmUgcHJpbWFyaWx5 IGFzc29jaWF0ZWQgdG8gdGhlIGFiaWxpdHkgdG8gc2VsZWN0IHNvbWUgSVAgYWRkcmVzc2VzIHdp dGggZGlmZmVyZW50IGZ1bmN0aW9uYWxpdGllcy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+TW9yZSBlc3BlY2lhbGx5LCA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIGRvY3VtZW50 IGRlc2NyaWJlcyBob3cgYXBwbGljYXRpb25zIHByb3ZpZGVzIHRoZSBPUyB0aGVpcjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+cmVxdWlyZW1lbnRzIGluIG9yZGVyIHRvIHNl bGVjdCB0aGUgYXBwcm9wcmlhdGVkIElQIGFkZHJlc3MuIFRoZTxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+cmVzb3VyY2UgYXJlIGFzc29jaWF0ZWQgdG8gZGlmZmVyZW50IGNv c3RzLiBXaGlsZSB0aGUgY29zdCBpcyBwcmltYXJpbHk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPm9uIHRoZSBvcGVyYXRvciBzaWRlLCBpdCBpcyBsaWtlbHkgdGhhdCB1c2Fn ZSBieSB0aGUgbW9iaWxlIG5vZGUgY29tZXM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPndpdGggc29tZSByZXN0cmljdGlvbnMsIGxpbWl0YXRpb24gb3IgZGlyZWN0IGNvc3Qu IFR5cGljYWxseSwgc29tZSB0eXBlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5vZiBJUCBhZGRyZXNzIG1heSBiZSBwcm92aWRlZCBieSB0aGUgb3BlcmF0b3IgZm9yIGEgbGlt aXRlZCBudW1iZXIgb2Y8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmJ5dGVz IHVwb24gd2hpY2ggdGhlIElQIGFkZHJlc3MgdHlwZSB3aWxsIG5vdCBiZSBhdmFpbGFibGUgdG8g dGhlIG1vYmlsZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+bm9kZSBvciBt YXkgYmUgY2hhcmdlZC4gQSBtYWxpY2lvdXMgYXBwbGljYXRpb24gbWF5IHVzZSB0aGVzZTxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+bGltaXRhdGlvbnMgdG8gZ2VuZXJhdGUg ZXh0cmEgYmlsbGluZyBvZiB0aGUgbW9iaWxlIG5vZGUgb3IgdG8gcHJldmVudDxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+dGhlIHVzYWdlIG9mIHNvbWUgYXBwbGljYXRpb25z IGJ5IGV4aGF1c3RpbmcgdGhlIGV4cGVjdGVkIHR5cGUgb2YgSVA8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPmFkZHJlc3MuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OyZuYnNwOyZuYnNwOyAmbHQ7bWdsdCZndDtJIGJlbGlldmUgdGhlIHRocmVhdCBoZXJlIGlzIHRo YXQgYSBtYWxpY2lvdXMgYXBwbGljYXRpb24gY2FuIHNlbGVjdCBhbiBJUCBhZGRyZXNzIHdpdGgg bW9yZSBleHBlbnNpdmUgY2F0ZWdvcmllcy4gVGhpcyBzZWVtcyB0byBtZSByZWxhdGVkIHRvIHRo ZSAmbmJzcDtPbi1EZW1hbmQgY29uY2VwdC4gRG8geW91IHRoaW5rIG90aGVyd2lzZSA/Jmx0Oy9t Z2x0Jmd0OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbiBvcmRlciB0byBwcmV2ZW50IHN1Y2gg c2NlbmFyaW8sIHRoZSBtb2JpbGUgbm9kZSBTSE9VTEQgYmUgYWJsZSB0bzxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+YXV0aG9yaXplIHNwZWNpZmljIFBJIGFkZHJlc3MgdHlw ZXMgdG8gcHJpdmlsZWdlIGFwcGxpY2F0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaXRo IHRoZXNlIG5ldyB0eXBlcyBvZiBJUCBhZGRyZXNzZXMsIHRoZSBJUCBhZGRyZXNzIGxlYWtzIHNv bWU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmNvbm5lY3Rpdml0eSByZXF1 aXJlbWVudHMgb2YgdGhlIGFwcGxpY2F0aW9uLiBUaGlzIGFsc28gbWVhbnMgdGhhdDxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+YWRkaXRpb25hbCBpbmZvcm1hdGlvbiBpcyBw cm92aWRlZCB0byB0aGUgZGVzdGluYXRpb24gd2hpY2ggY291bGQgcmV2ZWFsPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj50byBhIHBhc3NpdmUgbW9uaXRvcmluZyBhdHRhY2tl ciBzb21lIGluZm9ybWF0aW9uIHN1Y2ggYXMgdGhlIHR5cGUgb2Y8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPmFwcGxpY2F0aW9uIGFuZCB0aGUgYXBwbGljYXRpb24gaXRzZWxm IGV2ZW4gdGhvdWdoIHRoZSBwYWNrZXQgaXM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPnByb3RlY3RlZCBieSBJUHNlYyBvciBUTFMuPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7bWdsdCZndDtJIGJlbGlldmUgdGhlIHRocmVhdCBoZXJl IGlzIHRoYXQgSVAgYWRkcmVzcyBkbyBub3Qgb25seSBjYXJyeSBpbmZvcm1hdGlvbiBhYm91dCB0 aGUgZGVzdGluYXRpb24gYnV0IGFsc28gYWJvdXQgdGhlIGZ1bmN0aW9uYWxpdGllcyBleHBlY3Rl ZCBieSB0aGUgYXBwbGljYXRpb24uIFRoaXMgc2VlbXMgdG8gbWUgcmVsYXRlZCB0byB0aGUgJm5i c3A7T24tRGVtYW5kIGNvbmNlcHQuIERvIHlvdSB0aGluaw0KIG90aGVyd2lzZSA/Jmx0Oy9tZ2x0 Jmd0OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPlRvIGF2b2lkIHByb2ZpbGluZyBhbiBhcHBsaWNhdGlvbiBhY2NvcmRp bmcgdG8gdGhlIHR5cGUgb2YgSVAgYWRkcmVzc2VzLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+aXQgaXMgZXhwZWN0ZWQgdGhhdCBwcmVmaXhlcyBwcm92aWRlZCBieSB0aGUg b3BlcmF0b3IgYXJlIGFzc29jaWF0ZWQgdG88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPnZhcmlvdXMgdHlwZSBvZiBhZGRyZXNzZXMgb3ZlciB0aW1lLiBBcyBhIHJlc3VsdCwg dGhlIHR5cGUgb2YgYWRkcmVzczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Y291bGQgbm90IGJlIGFzc29jaWF0ZWQgdG8gdGhlIHByZWZpeCwgbWFraW5nIGFwcGxpY2F0aW9u IHByb2ZpbGluZzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+YmFzZWQgb24g dGhlIHR5cGUgb2YgYWRkcmVzcyBoYXJkZXIuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5BcHBsaWNhdGlvbiB1c2luZyBtdWx0aXBsZSB0eXBlIG9mIElQIGFkZHJlc3NlcyB0 byBhdm9pZCBiZWluZyBwcm9maWxlZDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+aXMgbGlrZWx5IHRvIGNyZWF0ZSBzb21lIHBhdHRlcm5zLiBTbyB0aGF0IHJlbWFpbnMgYSBo YXJkIHByb2JsZW0gdG88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnNvbHZl IGJ5IHRoZSBhcHBsaWNhdGlvbi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIHVzYWdlIG9m IGEgZml4ZWQgSVAgYWRkcmVzcywgZW5hYmxlcyB0cmFja2luZyB0aGUgbW9iaWxlIG5vZGUsIG9y PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5pdHMgYXBwbGljYXRpb24gb3Zl ciB0aW1lLiBUaGlzIGlzIGEgc2ltaWxhciBwcm9ibGVtIGFzIHRoZSBvbmU8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmVuY291bnRlcmVkIHdpdGggUHVibGljIElQIGFkZHJl c3Nlcy4gVGhlIHVzYWdlIG9mIHRoZSBGaXhlZCBJUDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+YWRkcmVzc2VzIHNob3VsZCBiZSBsaW1pdGVkLjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsgJmx0O21nbHQmZ3Q7SSBiZWxpZXZlIHRoZSB0aHJl YXQgaGVyZSBpcyByZWxhdGVkIHRvIHRoZSBzZWxlY3Rpb24gb2YgYSBmaXhlZCBJUCBhZGRyZXNz LiBUaGlzIHNlZW1zIHRvIG1lIHJlbGF0ZWQgdG8gdGhlICZuYnNwO09uLURlbWFuZCBjb25jZXB0 IGluIHRoZSBzZW5zZSB0aGF0IGlmIHlvdSBjYW4gZGVhbCB3aXRoIG5vbiBwZXJzaXN0ZW50IHRo YXQgbWF5IGJlIGJldHRlci4mbHQ7L21nbHQmZ3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VG8gbGltaXQgdGhlIGVm ZmVjdCBvZiBJUCB0cmFja2luZywgdGhlIGFwcGxpY2F0aW9uIG9yIHRoZSBPUyBzaG91bGQ8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmVuc3VyZSB0aGF0IElQIGFkZHJlc3Nl cyByZWd1bGFybHkgY2hhbmdlIHRvIGxpbWl0IElQIHRyYWNraW5nIGJ5IGE8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnBhc3NpdmUgb2JzZXJ2ZXIuJm5ic3A7IFRoZSBhcHBs aWNhdGlvbiBzaG91bGQgcmVndWxhcmx5IHNldCB0aGUgT24gRGVtYW5kPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5mbGFnLiBUaGUgYXBwbGljYXRpb24gc2hvdWxkIGJlIGFi bGUgdG8gZW5zdXJlIHRoYXQgc2Vzc2lvbiBsYXN0aW5nIElQPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5hZGRyZXNzIGFyZSByZWd1bGFybHkgY2hhbmdlZCBieSBzZXR0aW5n IGEgbGlmZXRpbWUgZm9yIGV4YW1wbGUgaGFuZGxlZDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+YnkgdGhlIGFwcGxpY2F0aW9uLiBJbiBhZGRpdGlvbiwgdGhlIGFwcGxpY2F0 aW9uIHNob3VsZCBjb25zaWRlciB0aGUgdXNlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5vZiBncmFjZWZ1bCByZXBsYWNlbWVudCBJUCBhZGRyZXNzZXMuPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPlNpbWlsYXJseSwgdGhlIE9TIG1heSBhbHNvIGFzc29jaWF0ZWQgSVAgYWRk cmVzc2VzIHdpdGggYSBsaWZldGltZS4gVXBvbjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+cmVjZWl2aW5nIGEgcmVxdWVzdCBmb3IgYSBnaXZlbiB0eXBlIG9mIElQIGFkZHJl c3MsIGFmdGVyIHNvbWUgdGltZSwgdGhlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5PUyBzaG91bGQgcmVxdWVzdCBhIG5ldyBhZGRyZXNzIHRvIHRoZSBuZXR3b3JrIGV2ZW4g aWYgaXQgYWxyZWFkeSBoYXM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPm9u ZSBJUCBhZGRyZXNzIGF2YWlsYWJsZSB3aXRoIHRoZSByZXF1ZXN0ZWQgdHlwZS4gVGhpcyBpbmNs dWRlcyBhbnkgdHlwZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+b2YgSVAg YWRkcmVzcy4gQWRkcmVzc2VzIG9mIHR5cGUgZ3JhY2VmdWwgcmVwbGFjZW1lbnQgb3Igbm9uIHBl cnNpc3RlbnQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklQIGFkZHJlc3Nl cyBzaG91bGQgYmUgcmVndWxhcmx5IHJlbmV3ZWQgYnkgdGhlIE9TLjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5UaGUgbGlmZXRpbWUgb2YgYW4gSVAgYWRkcmVzcyBtYXkgYmUgZXhwcmVzc2VkIGlu IG51bWJlciBvZiBzZWNvbmRzIG9yPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5pbiBudW1iZXIgb2YgYnl0ZXMgc2VudCB0aHJvdWdoIHRoaXMgSVAgYWRkcmVzcy48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+U2Vzc2lvbiBsYXN0aW5nIElQIGFkZHJlc3MgY291bGQgYmUgdXNl ZCB0byBhdm9pZCB0cmFja2luZyBhbmQgc2hvdWxkIGJlPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5wcmVmZXJyZWQuIEhvd2V2ZXIsIHRoZXJlIHNob3VsZCBiZSBhIHdheSB0 byBzcGVjaWZ5IGJldHdlZW4gb25lIHNlc3Npb248bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPmxhc3Rpbmcgb3IgaWYgdGhlIElQIGFkZHJlc3MgY2FuIGxhc3QgbXVsdGlwbGUg c2Vzc2lvbnMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbHQ7L21nbHQm Z3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uZSBhZGRpdGlvbmFsIG5pdDogLy8gTEFzdGlu ZyBzb3VyY2UgSVAgYWRkcmVzczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPjxhIG5hbWU9Il9fX19fcmVwbHlzZXBhcmF0b3IiPjwvYT4tLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLTxicj4NCkZyb206IGRtbSBbPGEgaHJlZj0ibWFpbHRvOmRtbS1ib3VuY2Vz QGlldGYub3JnIj5tYWlsdG86ZG1tLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2Yg RGFuaWVsIE1pZ2F1bHQ8YnI+DQpTZW50OiBXZWRuZXNkYXksIEphbnVhcnkgMTYsIDIwMTkgMDQ6 NTc8YnI+DQpUbzogPGEgaHJlZj0ibWFpbHRvOnNlY2RpckBpZXRmLm9yZyI+c2VjZGlyQGlldGYu b3JnPC9hPjxicj4NCkNjOiA8YSBocmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi1kbW0tb25kZW1hbmQt bW9iaWxpdHkuYWxsQGlldGYub3JnIj5kcmFmdC1pZXRmLWRtbS1vbmRlbWFuZC1tb2JpbGl0eS5h bGxAaWV0Zi5vcmc8L2E+Ow0KPGEgaHJlZj0ibWFpbHRvOmlldGZAaWV0Zi5vcmciPmlldGZAaWV0 Zi5vcmc8L2E+OyA8YSBocmVmPSJtYWlsdG86ZG1tQGlldGYub3JnIj5kbW1AaWV0Zi5vcmc8L2E+ PGJyPg0KU3ViamVjdDogW0RNTV0gU2VjZGlyIGxhc3QgY2FsbCByZXZpZXcgb2YgZHJhZnQtaWV0 Zi1kbW0tb25kZW1hbmQtbW9iaWxpdHktMTU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ UmV2aWV3ZXI6IERhbmllbCBNaWdhdWx0PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij5SZXZpZXcgcmVzdWx0OiBOb3QgUmVhZHk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+SGksPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkkgYW0gdGhlIGFzc2lnbmVk IFNlY2RpciByZXZpZXdlciBmb3IgdGhpcyBkcmFmdC4gVGhlIFNlY3VyaXR5IERpcmVjdG9yYXRl PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4oU2VjZGlyKSByZXZpZXdz IGFsbCBJRVRGIGRvY3VtZW50cyBiZWluZyBwcm9jZXNzZWQgYnkgdGhlIElFU0cgZm9yIHRoZSBJ RVRGJm5ic3A7IENoYWlyLiZuYnNwOyBQbGVhc2UgdHJlYXQgdGhlc2UgY29tbWVudHMganVzdCBs aWtlIGFueSBvdGhlciBsYXN0IGNhbGwgY29tbWVudHMuPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPllvdXJzLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+RGFu aWVsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBPbiBEZW1hbmQgTW9iaWxp dHkgTWFuYWdlbWVudDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRyYWZ0LWlldGYtZG1t LW9uZGVtYW5kLW1vYmlsaXR5LTE1PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkFic3Ry YWN0PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyBBcHBsaWNhdGlv bnMgZGlmZmVyIHdpdGggcmVzcGVjdCB0byB3aGV0aGVyIHRoZXkgbmVlZCBzZXNzaW9uPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgY29udGludWl0 eSBhbmQvb3IgSVAgYWRkcmVzcyByZWFjaGFiaWxpdHkuJm5ic3A7IFRoZSBuZXR3b3JrIHByb3Zp ZGluZyB0aGU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZu YnNwOyBzYW1lIHR5cGUgb2Ygc2VydmljZSB0byBhbnkgbW9iaWxlIGhvc3QgYW5kIGFueSBhcHBs aWNhdGlvbiBydW5uaW5nPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m bmJzcDsmbmJzcDsgb24gdGhlIGhvc3QgeWllbGRzIGluZWZmaWNpZW5jaWVzLjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmx0O21nbHQmZ3Q7PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mcXVvdDtpbmVmZmljaWVuY2llcyZxdW90OyBzZWVt cyB0b28gdmFndWUgdG8gbWUgYW5kIGl0IGNvdWxkIGJlIGNsYXJpZmllZC48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlJlYWRpbmcgdGhlIGFic3RyYWN0LCBpdCBpcyB1 bmNsZWFyICh0byBtZSkgaWYgdGhlIGlzc3VlIGlzIG9uIHRoZSBhcHBsaWNhdGlvbiBzaWRlIG9y IHRoZSBuZXR3b3JrIG9wZXJhdG9yIHNpZGUuIEkgZ3Vlc3MgdGhpcyBpcyB0aGUgbmV0d29yayBz aWRlLiBJdCBpcyBhbHNvIHVuY2xlYXIgdGhlIG5hdHVyZSBvZiB0aGUgaW5lZmZpY2llbmN5Ljxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmx0Oy9tZ2x0Jmd0OzxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgVGhpcyBkb2N1bWVudCBkZXNj cmliZXMgYTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5i c3A7IHNvbHV0aW9uIGZvciB0YWtpbmcgdGhlIGFwcGxpY2F0aW9uIG5lZWRzIGludG8gYWNjb3Vu dCBieSBzZWxlY3RpdmVseTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jm5ic3A7Jm5ic3A7IHByb3ZpZGluZyBzZXNzaW9uIGNvbnRpbnVpdHkgYW5kIElQIGFkZHJlc3Mg cmVhY2hhYmlsaXR5IG9uIGEgcGVyLTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jm5ic3A7Jm5ic3A7IHNvY2tldCBiYXNpcy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+U3RhdHVzIG9mIFRoaXMgTWVtbzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m bmJzcDsmbmJzcDsgVGhpcyBJbnRlcm5ldC1EcmFmdCBpcyBzdWJtaXR0ZWQgaW4gZnVsbCBjb25m b3JtYW5jZSB3aXRoIHRoZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jm5ic3A7Jm5ic3A7IHByb3Zpc2lvbnMgb2YgQkNQIDc4IGFuZCBCQ1AgNzkuPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyBJbnRlcm5ldC1EcmFmdHMgYXJlIHdvcmtp bmcgZG9jdW1lbnRzIG9mIHRoZSBJbnRlcm5ldCBFbmdpbmVlcmluZzxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IFRhc2sgRm9yY2UgKElFVEYpLiZu YnNwOyBOb3RlIHRoYXQgb3RoZXIgZ3JvdXBzIG1heSBhbHNvIGRpc3RyaWJ1dGU8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyB3b3JraW5nIGRvY3Vt ZW50cyBhcyBJbnRlcm5ldC1EcmFmdHMuJm5ic3A7IFRoZSBsaXN0IG9mIGN1cnJlbnQgSW50ZXJu ZXQtPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsg RHJhZnRzIGlzIGF0IDxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZHJhZnRz L2N1cnJlbnQvIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlv bjpub25lIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RyYWZ0cy9jdXJyZW50Lzwvc3Bh bj48L2E+LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgSW50ZXJu ZXQtRHJhZnRzIGFyZSBkcmFmdCBkb2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXgg bW9udGhzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJz cDsgYW5kIG1heSBiZSB1cGRhdGVkLCByZXBsYWNlZCwgb3Igb2Jzb2xldGVkIGJ5IG90aGVyIGRv Y3VtZW50cyBhdCBhbnk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZu YnNwOyZuYnNwOyB0aW1lLiZuYnNwOyBJdCBpcyBpbmFwcHJvcHJpYXRlIHRvIHVzZSBJbnRlcm5l dC1EcmFmdHMgYXMgcmVmZXJlbmNlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mbmJzcDsmbmJzcDsgbWF0ZXJpYWwgb3IgdG8gY2l0ZSB0aGVtIG90aGVyIHRoYW4gYXMg JnF1b3Q7d29yayBpbiBwcm9ncmVzcy4mcXVvdDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jm5ic3A7Jm5ic3A7IFRoaXMgSW50ZXJuZXQtRHJhZnQgd2lsbCBleHBpcmUgb24gSmFudWFy eSAyNywgMjAxOS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Q29weXJpZ2h0IE5vdGlj ZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgQ29weXJpZ2h0IChj KSAyMDE4IElFVEYgVHJ1c3QgYW5kIHRoZSBwZXJzb25zIGlkZW50aWZpZWQgYXMgdGhlPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgZG9jdW1lbnQg YXV0aG9ycy4mbmJzcDsgQWxsIHJpZ2h0cyByZXNlcnZlZC48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+WWVnaW4sIGV0IGFsLiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBFeHBpcmVzIEphbnVhcnkgMjcsIDIwMTkmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgW1BhZ2UgMV08bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+SW50ZXJuZXQtRHJhZnQmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgT24gRGVtYW5kIE1vYmlsaXR5 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEp1bHkgMjAxODxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgVGhpcyBkb2N1bWVudCBp cyBzdWJqZWN0IHRvIEJDUCA3OCBhbmQgdGhlIElFVEYgVHJ1c3QncyBMZWdhbDxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IFByb3Zpc2lvbnMgUmVs YXRpbmcgdG8gSUVURiBEb2N1bWVudHM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZuYnNwOyZuYnNwOyAoPGEgaHJlZj0iaHR0cHM6Ly90cnVzdGVlLmlldGYub3JnL2xp Y2Vuc2UtaW5mbyI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9u Om5vbmUiPmh0dHBzOi8vdHJ1c3RlZS5pZXRmLm9yZy9saWNlbnNlLWluZm88L3NwYW4+PC9hPikg aW4gZWZmZWN0IG9uIHRoZSBkYXRlIG9mPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mbmJzcDsmbmJzcDsgcHVibGljYXRpb24gb2YgdGhpcyBkb2N1bWVudC4mbmJzcDsg UGxlYXNlIHJldmlldyB0aGVzZSBkb2N1bWVudHM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyBjYXJlZnVsbHksIGFzIHRoZXkgZGVzY3JpYmUgeW91 ciByaWdodHMgYW5kIHJlc3RyaWN0aW9ucyB3aXRoIHJlc3BlY3Q8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyB0byB0aGlzIGRvY3VtZW50LiZuYnNw OyBDb2RlIENvbXBvbmVudHMgZXh0cmFjdGVkIGZyb20gdGhpcyBkb2N1bWVudCBtdXN0PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgaW5jbHVkZSBT aW1wbGlmaWVkIEJTRCBMaWNlbnNlIHRleHQgYXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gNC5lIG9m PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgdGhl IFRydXN0IExlZ2FsIFByb3Zpc2lvbnMgYW5kIGFyZSBwcm92aWRlZCB3aXRob3V0IHdhcnJhbnR5 IGFzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsg ZGVzY3JpYmVkIGluIHRoZSBTaW1wbGlmaWVkIEJTRCBMaWNlbnNlLjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij5UYWJsZSBvZiBDb250ZW50czxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mbmJzcDsmbmJzcDsgMS4mbmJzcDsgSW50cm9kdWN0aW9uJm5ic3A7IC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuJm5ic3A7Jm5ic3A7IDI8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyAyLiZuYnNwOyBO b3RhdGlvbmFsIENvbnZlbnRpb25zJm5ic3A7IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4mbmJzcDsmbmJzcDsgNDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jm5ic3A7Jm5ic3A7IDMuJm5ic3A7IFNvbHV0aW9uJm5ic3A7IC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiZuYnNwOyZuYnNwOyA0PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgMy4xLiZuYnNwOyBUeXBlcyBvZiBJUCBBZGRyZXNzZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4mbmJzcDsmbmJzcDsgNDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDMuMi4mbmJzcDsgR3JhbnVsYXJp dHkgb2YgU2VsZWN0aW9uJm5ic3A7IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4mbmJz cDsmbmJzcDsgNjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IDMuMy4mbmJzcDsgT24gRGVtYW5kIE5hdHVyZSZuYnNwOyAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4mbmJzcDsmbmJzcDsgNjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNw OzMuNC4mbmJzcDsgQ29udmV5aW5nIHRoZSBEZXNpcmVkIEFkZHJlc3MgVHlwZSZuYnNwOyAuIC4g LiAuIC4gLiAuIC4gLiAuIC4mbmJzcDsmbmJzcDsgNzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IDQuJm5ic3A7IFVzYWdlIGV4YW1wbGUgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4mbmJzcDsmbmJzcDsgODxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IDQuMS4mbmJzcDsgUHNldWRvLWNvZGUgZXhhbXBsZSAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuJm5ic3A7Jm5ic3A7IDg8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA0LjIuJm5ic3A7IE1lc3Nh Z2UgRmxvdyBleGFtcGxlJm5ic3A7IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu Jm5ic3A7IDEwPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsm bmJzcDsgNS4mbmJzcDsgQmFja3dhcmRzIENvbXBhdGliaWxpdHkgQ29uc2lkZXJhdGlvbnMmbmJz cDsgLiAuIC4gLiAuIC4gLiAuIC4gLiAuJm5ic3A7IDExPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgNS4xLiZuYnNwOyBBcHBs aWNhdGlvbnMmbmJzcDsgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiZuYnNwOyAxMTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IDUuMi4mbmJzcDsgSVAgU3RhY2sgaW4gdGhlIE1vYmlsZSBIb3N0 IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuJm5ic3A7IDEyPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7NS4zLiZuYnNw OyBOZXR3b3JrIEluZnJhc3RydWN0dXJlJm5ic3A7IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiZuYnNwOyAxMjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDUuNC4mbmJzcDsgTWVyZ2luZyB0aGlzIHdvcmsgd2l0 aCBSRkM1MDE0Jm5ic3A7IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4mbmJzcDsgMTI8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyA2LiZuYnNwOyBT dW1tYXJ5IG9mIE5ldyBEZWZpbml0aW9ucyZuYnNwOyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4mbmJzcDsgMTM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA2LjEuJm5ic3A7IE5ldyBBUElzJm5ic3A7IC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuJm5ic3A7IDEzPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgNi4yLiZuYnNwOyBOZXcgRmxhZ3MgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4mbmJzcDsgMTM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZuYnNwOyZuYnNwOyA3LiZuYnNwOyBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuJm5ic3A7IDE0PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgOC4mbmJzcDsgSUFOQSBDb25z aWRlcmF0aW9ucyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiZuYnNw OyAxNDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7 IDkuJm5ic3A7IENvbnRyaWJ1dG9ycyZuYnNwOyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiZuYnNwOyAxNDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IDEwLiBBY2tub3dsZWRnZW1lbnRzJm5ic3A7IC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4mbmJzcDsgMTQ8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyAxMS4gUmVmZXJlbmNl cyZuYnNwOyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu Jm5ic3A7IDE0PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgMTEuMS4mbmJzcDsgTm9ybWF0aXZlIFJlZmVyZW5jZXMgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4mbmJzcDsgMTU8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAxMS4yLiZuYnNw OyBJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiZuYnNwOyAxNTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7 Jm5ic3A7IEF1dGhvcnMnIEFkZHJlc3NlcyZuYnNwOyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4mbmJzcDsgMTY8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+MS4mbmJzcDsgSW50cm9kdWN0aW9uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZu YnNwOyZuYnNwOyBJbiB0aGUgY29udGV4dCBvZiBNb2JpbGUgSVAgW1JGQzU1NjNdW1JGQzYyNzVd W1JGQzUyMTNdW1JGQzU5NDRdLCB0aGU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZuYnNwOyZuYnNwOyBmb2xsb3dpbmcgdHdvIGF0dHJpYnV0ZXMgYXJlIGRlZmluZWQg Zm9yIElQIHNlcnZpY2UgcHJvdmlkZWQgdG88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZuYnNwOyZuYnNwOyBtb2JpbGUgaG9zdHM6PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZuYnNwOyZuYnNwOyBTZXNzaW9uIGNvbnRpbnVpdHk6IFRoZSBhYmlsaXR5IHRv IG1haW50YWluIGFuIG9uZ29pbmcgdHJhbnNwb3J0PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgaW50ZXJhY3Rpb24gYnkga2VlcGluZyB0aGUgc2Ft ZSBsb2NhbCBlbmQtcG9pbnQgSVAgYWRkcmVzcyB0aHJvdWdob3V0PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgdGhlIGxpZmUtdGltZSBvZiB0aGUg SVAgc29ja2V0IGRlc3BpdGUgdGhlIG1vYmlsZSBob3N0IGNoYW5naW5nIGl0czxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij5ZZWdpbiwgZXQgYWwuJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEV4cGlyZXMgSmFudWFyeSAyNywg MjAxOSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBbUGFnZSAyXTxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij5JbnRlcm5ldC1EcmFmdCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBPbiBEZW1h bmQgTW9iaWxpdHkmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg SnVseSAyMDE4PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyBwb2lu dCBvZiBhdHRhY2htZW50IHdpdGhpbiB0aGUgSVAgbmV0d29yayB0b3BvbG9neS4mbmJzcDsgVGhl IElQIGFkZHJlc3M8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNw OyZuYnNwOyBvZiB0aGUgaG9zdCBtYXkgY2hhbmdlIGFmdGVyIGNsb3NpbmcgdGhlIElQIHNvY2tl dCBhbmQgYmVmb3JlIG9wZW5pbmc8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZuYnNwOyZuYnNwOyBhIG5ldyBvbmUsIGJ1dCB0aGF0IGRvZXMgbm90IGplb3BhcmRpemUg dGhlIGFiaWxpdHkgb2YgYXBwbGljYXRpb25zPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgdXNpbmcgdGhlc2UgSVAgc29ja2V0cyB0byB3b3JrIGZs YXdsZXNzbHkuJm5ic3A7IFNlc3Npb24gY29udGludWl0eSBpczxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IGVzc2VudGlhbCBmb3IgbW9iaWxlIGhv c3RzIHRvIG1haW50YWluIG9uZ29pbmcgZmxvd3Mgd2l0aG91dCBhbnk8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyBpbnRlcnJ1cHRpb24uPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZsdDttZ2x0Jmd0OzxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+U2Vzc2lvbiBjb250aW51aXR5IGNhbiBiZSBwcm92aWRlZCBh dCBtdWx0aXBsZSBsYXllcnMgdGh1cyBJIHdvdWxkIHJlY29tbWVuZCBmb3IgY2xhcml0eSB0byBj aGFuZ2Ugc2Vzc2lvbiBjb250aW51aXR5IHRvIElQIHNlc3Npb24gY29udGludWl0eSBhbmQgaW5z aXN0cyB0aGF0IHRoaXMgaXMgYmVpbmcgcHJvdmlkZWQgYXQgdGhlIElQIGxheWVyLjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5Ob3QgdGhhdCBJUCBpcyBzZXNzaW9ubGVzcywgc28gaGVy ZSBzZXNzaW9uIHNlZW1zIHNpbWlsYXIgdG8gcmVhY2hhYmlsaXR5IGJ1dCAnb3JjaGVzdHJhdGVk JyBieSBhIGhpZ2hlciBzZXNzaW9uIHByb3RvY29sLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+VGhlIGRpZmZlcmVuY2UgSSBzZWUgaXMgdGhhdCByZWFjaGFiaWxpdHkg aXMgYSBjb21taXRtZW50IChieSB0aGUgSVNQKSBmb3Igbm90IGNoYW5naW5nIHRoZSBJUCBhZGRy ZXNzIHdoaWxlIHdpdGggc2Vzc2lvbiBjb250aW51aXR5IHRoZSBjb21taXRtZW50IGlzIHJlbGF0 ZWQgdG8gdGhlIHVzZSBvZiB0aGUgSVAgYWRkcmVzcy4gSW4gb3RoZXIgd29yZHMsIHdpdGggYSBs aW1pdGVkIHBlcmlvZCBvZiB0aW1lLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jmx0Oy9tZ2x0Jmd0OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsm bmJzcDsgSVAgYWRkcmVzcyByZWFjaGFiaWxpdHk6IFRoZSBhYmlsaXR5IHRvIG1haW50YWluIHRo ZSBzYW1lIElQIGFkZHJlc3M8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZuYnNwOyZuYnNwOyBmb3IgYW4gZXh0ZW5kZWQgcGVyaW9kIG9mIHRpbWUuJm5ic3A7IFRoZSBJ UCBhZGRyZXNzIHN0YXlzIHRoZSBzYW1lIGFjcm9zczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IGluZGVwZW5kZW50IHNlc3Npb25zLCBhbmQgZXZl biBpbiB0aGUgYWJzZW5jZSBvZiBhbnkgc2Vzc2lvbi4mbmJzcDsgVGhlIElQPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgYWRkcmVzcyBtYXkgYmUg cHVibGlzaGVkIGluIGEgbG9uZy10ZXJtIHJlZ2lzdHJ5IChlLmcuLCBETlMpLCBhbmQgaXM8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyBtYWRlIGF2 YWlsYWJsZSBmb3Igc2VydmluZyBpbmNvbWluZyAoZS5nLiwgVENQKSBjb25uZWN0aW9ucy4mbmJz cDsgSVA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNw OyBhZGRyZXNzIHJlYWNoYWJpbGl0eSBpcyBlc3NlbnRpYWwgZm9yIG1vYmlsZSBob3N0cyB0byB1 c2Ugc3BlY2lmaWMvPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJz cDsmbmJzcDsgcHVibGlzaGVkIElQIGFkZHJlc3Nlcy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jm5ic3A7Jm5ic3A7IE1vYmlsZSBJUCBpcyBkZXNpZ25lZCB0byBwcm92aWRlIGJvdGgg c2Vzc2lvbiBjb250aW51aXR5IGFuZCBJUDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jm5ic3A7Jm5ic3A7IGFkZHJlc3MgcmVhY2hhYmlsaXR5IHRvIG1vYmlsZSBob3N0 cy4mbmJzcDsgQXJjaGl0ZWN0dXJlcyB1dGlsaXppbmcgdGhlc2U8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyBwcm90b2NvbHMgKGUuZy4sIDNHUFAs IDNHUFAyLCBXSU1BWCkgZW5zdXJlIHRoYXQgYW55IG1vYmlsZSBob3N0PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgYXR0YWNoZWQgdG8gdGhlIGNv bXBsaWFudCBuZXR3b3JrcyBjYW4gZW5qb3kgdGhlc2UgYmVuZWZpdHMuJm5ic3A7IEFueTxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IGFwcGxpY2F0 aW9uIHJ1bm5pbmcgb24gdGhlc2UgbW9iaWxlIGhvc3RzIGlzIHN1YmplY3RlZCB0byB0aGUgc2Ft ZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IHRy ZWF0bWVudCB3aXRoIHJlc3BlY3QgdG8gc2Vzc2lvbiBjb250aW51aXR5IGFuZCBJUCBhZGRyZXNz PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgcmVh Y2hhYmlsaXR5LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbHQ7bWdsdCZndDs8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPk15IHVuZGVyc3RhbmRpbmcgb2Yg dGhlIHRleHQgaXMgdGhhdCBNb2JpbGUgSVAgaXMgZXhwZW5zaXZlIHRvIGRlcGxveSBhbmQgSSBi ZWxpZXZlIGl0IHdvdWxkIGJlIGVhc2llciBmb3IgdGhlIHJlYWRlciB0byBzdGF0ZSBpdCBoZXJl IGJlZm9yZSBkZXZlbG9waW5nIGFsbCBtZWNoYW5pc21zIHRoYXQgaGF2ZSBiZWVuIGRlc2lnbmVk IHRvIG92ZXJjb21lIHNlc3Npb24gY29udGludWl0eSBpbiBhIGRpZmZlcmVudA0KIHdheS4gVGh1 cyBJIHdvdWxkIHB1dCB0aGUgZm9sbG93aW5nIHRleHQgcmlnaHQ8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPmhlcmU6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgQWNoaWV2aW5nIHNlc3Npb24gY29udGludWl0eSBhbmQg SVAgYWRkcmVzcyByZWFjaGFiaWxpdHkgd2l0aCBNb2JpbGU8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyBJUCBpbmN1cnMgc29tZSBjb3N0LiZuYnNw OyBNb2JpbGUgSVAgcHJvdG9jb2wgZm9yY2VzIHRoZSBtb2JpbGUgaG9zdCdzIElQPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgdHJhZmZpYyB0byB0 cmF2ZXJzZSBhIGNlbnRyYWxseS1sb2NhdGVkIHJvdXRlciAoSG9tZSBBZ2VudCwgSEEpLDxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IHdoaWNoIGlu Y3VycyBhZGRpdGlvbmFsIHRyYW5zbWlzc2lvbiBsYXRlbmN5IGFuZCB1c2Ugb2YgYWRkaXRpb25h bDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IG5l dHdvcmsgcmVzb3VyY2VzLCBhZGRzIHRvIHRoZSBuZXR3b3JrIENBUEVYIGFuZCBPUEVYLCBhbmQg ZGVjcmVhc2VzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsm bmJzcDsgdGhlIHJlbGlhYmlsaXR5IG9mIHRoZSBuZXR3b3JrIGR1ZSB0byB0aGUgaW50cm9kdWN0 aW9uIG9mIGEgc2luZ2xlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m bmJzcDsmbmJzcDsgcG9pbnQgb2YgZmFpbHVyZSBbUkZDNzMzM10uJm5ic3A7IFRoZXJlZm9yZSwg c2Vzc2lvbiBjb250aW51aXR5IGFuZCBJUDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jm5ic3A7Jm5ic3A7IGFkZHJlc3MgcmVhY2hhYmlsaXR5IFNIT1VMRCBiZSBwcm92 aWRlZCBvbmx5IHdoZW4gbmVjZXNzYXJ5LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jmx0Oy9tZ2x0Jmd0OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJz cDsmbmJzcDsgSXQgc2hvdWxkIGJlIG5vdGVkIHRoYXQgaW4gcmVhbGl0eSBub3QgZXZlcnkgYXBw bGljYXRpb24gbWF5IG5lZWQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZuYnNwOyZuYnNwOyB0aGVzZSBiZW5lZml0cy4mbmJzcDsgSVAgYWRkcmVzcyByZWFjaGFiaWxp dHkgaXMgcmVxdWlyZWQgZm9yIGFwcGxpY2F0aW9uczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IHJ1bm5pbmcgYXMgc2VydmVycyAoZS5nLiwgYSB3 ZWIgc2VydmVyIHJ1bm5pbmcgb24gdGhlIG1vYmlsZSBob3N0KS48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyBCdXQsIGEgdHlwaWNhbCBjbGllbnQg YXBwbGljYXRpb24gKGUuZy4sIHdlYiBicm93c2VyKSBkb2VzIG5vdDxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IG5lY2Vzc2FyaWx5IHJlcXVpcmUg SVAgYWRkcmVzcyByZWFjaGFiaWxpdHkuJm5ic3A7IFNpbWlsYXJseSwgc2Vzc2lvbjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IGNvbnRpbnVpdHkg aXMgbm90IHJlcXVpcmVkIGZvciBhbGwgdHlwZXMgb2YgYXBwbGljYXRpb25zIGVpdGhlci48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyBBcHBsaWNh dGlvbnMgcGVyZm9ybWluZyBicmllZiBjb21tdW5pY2F0aW9uIChlLmcuLCBwaW5nKSBjYW4gc3Vy dml2ZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7 IHdpdGhvdXQgaGF2aW5nIHNlc3Npb24gY29udGludWl0eSBzdXBwb3J0LjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mbHQ7bWdsdCZndDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPkkgYmVsaWV2ZSB0aGF0IHNlc3Npb24gY29udGludWl0eSBpcyB0aGUgbWFp biBtb3RpdmF0aW9uIG9mIHRoZSBkcmFmdC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPk1lbnRpb25pbmcgcGluZyBhcyBhbiBleGFtcGxlIGlzIGNvdW50ZXIgcHJvZHVj dGl2ZSBhcyBJIGRvdWJ0IHRoaXMgaXMgdGhlIHRhcmdldCBhcHBsaWNhdGlvbiBvZiB0aGUgZHJh ZnQuIFRodXMgY2l0aW5nIGFuIGFwcGxpY2F0aW9uIG5vIG9uZSByZWFsbHkgd2FudHMgY291bGQg bWVhbiB0aGF0IHdlIGhhdmUgbm90IGZvdW5kIGFueSBvdGhlciBhcHBsaWNhdGlvbiB0aGF0IGRv IG5vdCBuZWVkIHNlc3Npb24NCiBjb250aW51aXR5LCB3aGljaCBjb3VsZCBiZSBpbnRlcnByZXRl ZCBhcyBldmVyeSBhcHBsaWNhdGlvbiBuZWVkcyBzZXNzaW9uIGNvbnRpbnVpdHkgYXQgdGhlIElQ IGxheWVyLiBUaGlzIGlzIG5vdCB0aGUgaW50ZW50aW9uIG9mIHRoZSB0ZXh0LCBzbyB3ZSBzaG91 bGQgZmluZCBhbm90aGVyIGV4YW1wbGUuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPldl bGwgSSB0aGluayByZWFjaGFiaWxpdHkgYW5kIHNlc3Npb24gY29udGludWl0eSBhcmUgdHdvIGRp ZmZlcmVudCBmZWF0dXJlcy4gQXBwbGljYXRpb25zIG1heSBvbmx5IG5lZWQgb25lIG9mIHRoZXNl IGZlYXR1cmVzIG5vdCBib3RoLiBJbiBhZGRpdGlvbiwgYXBwbGljYXRpb24gY2FuIHByb3ZpZGUg dGhlc2UgZmVhdHVyZXMgYXQgdGhlIElQIGxheWVyIGxheWVyIG9yIHVzaW5nIG90aGVyIG1lY2hh bmlzbXMuDQogQXMgYSByZWFzb24gdGhlIHVzZSBvZiBNb2JpbGUgSVAgaXMgbGltaXRlZCB0byBh cHBsaWNhdGlvbnMgdGhhdCBuZWVkcyBib3RoIGZlYXR1cmVzIGJlaW5nIHBlcmZvcm1lZCBhdCB0 aGUgSVAgbGF5ZXIgd2hpY2ggb25seSBjb25jZXJuIGEgc21hbGwgZnJhY3Rpb24gb2YgYXBwbGlj YXRpb25zLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5SZWFkaW5nIHRoZSB0ZXh0IGFi b3ZlIHNlZW1zIHRvIHRha2UgZm9yIGdyYW50ZWQgdGhhdCByZWFjaGFiaWxpdHkgaXMgcGVyZm9y bWVkIG9ubHkgYXQgdGhlIElQIGxheWVyLiBTcGxpdHRpbmcgdGhlIGZlYXR1cmUgdmVyc3VzIGl0 cyBpbXBsZW1lbnRhdGlvbiBzaG91bGQgYmUgZG9uZSBpbiBhIHNpbWlsYXIgbWFubmVyIGZvciBi b3RoIHNlc3Npb24gY29udGludWl0eSBhbmQgcmVhY2hhYmlsaXR5IHRvDQogZWFzZSB0aGUgcmVh ZGluZy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZsdDsvbWdsdCZn dDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IEFjaGlldmluZyBz ZXNzaW9uIGNvbnRpbnVpdHkgYW5kIElQIGFkZHJlc3MgcmVhY2hhYmlsaXR5IHdpdGggTW9iaWxl PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgSVAg aW5jdXJzIHNvbWUgY29zdC4mbmJzcDsgTW9iaWxlIElQIHByb3RvY29sIGZvcmNlcyB0aGUgbW9i aWxlIGhvc3QncyBJUDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5i c3A7Jm5ic3A7IHRyYWZmaWMgdG8gdHJhdmVyc2UgYSBjZW50cmFsbHktbG9jYXRlZCByb3V0ZXIg KEhvbWUgQWdlbnQsIEhBKSw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZuYnNwOyZuYnNwOyB3aGljaCBpbmN1cnMgYWRkaXRpb25hbCB0cmFuc21pc3Npb24gbGF0ZW5j eSBhbmQgdXNlIG9mIGFkZGl0aW9uYWw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZuYnNwOyZuYnNwOyBuZXR3b3JrIHJlc291cmNlcywgYWRkcyB0byB0aGUgbmV0d29y ayBDQVBFWCBhbmQgT1BFWCwgYW5kIGRlY3JlYXNlczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IHRoZSByZWxpYWJpbGl0eSBvZiB0aGUgbmV0d29y ayBkdWUgdG8gdGhlIGludHJvZHVjdGlvbiBvZiBhIHNpbmdsZTxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IHBvaW50IG9mIGZhaWx1cmUgW1JGQzcz MzNdLiZuYnNwOyBUaGVyZWZvcmUsIHNlc3Npb24gY29udGludWl0eSBhbmQgSVA8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyBhZGRyZXNzIHJlYWNo YWJpbGl0eSBTSE9VTEQgYmUgcHJvdmlkZWQgb25seSB3aGVuIG5lY2Vzc2FyeS48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmx0O21nbHQmZ3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij5UaGlzIHNlY3Rpb24gc2hvdWxkIGJlIG1vdmVkIHVwLiBIZXJlIGl0 IGlzIHNwbGl0dGluZyB0aGUgZGlzY3Vzc2lvbiBvbiBzZXNzaW9uIGNvbnRpbnVpdHkgYW5kIHJl YWNoYWJpbGl0eSwgd2hpY2ggaXMgY29uZnVzaW5nLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jmx0Oy9tZ2x0Jmd0OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mbmJzcDsmbmJzcDsgRnVydGhlcm1vcmUsIHdoZW4gYW4gYXBwbGljYXRpb24gbmVlZHMgc2Vz c2lvbiBjb250aW51aXR5LCBpdCBtYXkgYmU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZuYnNwOyZuYnNwOyBhYmxlIHRvIHNhdGlzZnkgdGhhdCBuZWVkIGJ5IHVzaW5n IGEgc29sdXRpb24gYWJvdmUgdGhlIElQIGxheWVyLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IHN1Y2ggYXMgTVBUQ1AgW1JGQzY4MjRdLCBTSVAg bW9iaWxpdHkgW1JGQzMyNjFdLCBvciBhbiBhcHBsaWNhdGlvbi08bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyBsYXllciBtb2JpbGl0eSBzb2x1dGlv bi4mbmJzcDsgVGhlc2UgaGlnaGVyLWxheWVyIHNvbHV0aW9ucyBhcmUgbm90PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgc3ViamVjdCB0byB0aGUg c2FtZSBpc3N1ZXMgdGhhdCBhcmlzZSB3aXRoIHRoZSB1c2Ugb2YgTW9iaWxlIElQIHNpbmNlPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgdGhleSBj YW4gdXRpbGl6ZSB0aGUgbW9zdCBkaXJlY3QgZGF0YSBwYXRoIGJldHdlZW4gdGhlIGVuZC1wb2lu dHMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsg QnV0LCBpZiBNb2JpbGUgSVAgaXMgYmVpbmcgYXBwbGllZCB0byB0aGUgbW9iaWxlIGhvc3QsIHRo ZSBoaWdoZXItPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlllZ2luLCBldCBhbC4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg RXhwaXJlcyBKYW51YXJ5IDI3LCAyMDE5Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IFtQYWdlIDNdPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkludGVybmV0LURyYWZ0Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IE9uIERlbWFuZCBNb2JpbGl0eSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBKdWx5IDIwMTg8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jm5ic3A7Jm5ic3A7IGxheWVyIHByb3RvY29scyBhcmUgcmVuZGVyZWQgdXNlbGVzcyBiZWNh dXNlIHRoZWlyIG9wZXJhdGlvbiBpczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jm5ic3A7Jm5ic3A7IGluaGliaXRlZCBieSBNb2JpbGUgSVAuJm5ic3A7IFNpbmNlIE1v YmlsZSBJUCBlbnN1cmVzIHRoYXQgdGhlIElQIGFkZHJlc3M8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyBvZiB0aGUgbW9iaWxlIGhvc3QgcmVtYWlu cyBmaXhlZCAoZGVzcGl0ZSB0aGUgbG9jYXRpb24gYW5kIG1vdmVtZW50PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgb2YgdGhlIG1vYmlsZSBob3N0 KSwgdGhlIGhpZ2hlci1sYXllciBwcm90b2NvbHMgbmV2ZXIgZGV0ZWN0IHRoZSBJUC08bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyBsYXllciBjaGFu Z2UgYW5kIG5ldmVyIGVuZ2FnZSBpbiBtb2JpbGl0eSBtYW5hZ2VtZW50LjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mbHQ7bWdsdCZndDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPlRoZSBzYW1lIHBhcmFncmFwaCBzaG91bGQgc2F5IHRoZSByZWFjaGFiaWxp dHkgY2FuIGJlIHBlcmZvcm1lZCBieSBhcHBsaWNhdGlvbiB1c2luZyBvdGhlciBtZWFucyB0aGFu IElQIHJlYWNoYWJpbGl0eS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZsdDsvbWdsdCZndDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7 IFRoaXMgZG9jdW1lbnQgcHJvcG9zZXMgYSBzb2x1dGlvbiBmb3IgYXBwbGljYXRpb25zIHJ1bm5p bmcgb24gbW9iaWxlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJz cDsmbmJzcDsgaG9zdHMgdG8gaW5kaWNhdGUgd2hldGhlciB0aGV5IG5lZWQgc2Vzc2lvbiBjb250 aW51aXR5IG9yIElQIGFkZHJlc3M8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZuYnNwOyZuYnNwOyByZWFjaGFiaWxpdHkuJm5ic3A7IFRoZSBuZXR3b3JrIHByb3RvY29s IHN0YWNrIG9uIHRoZSBtb2JpbGUgaG9zdCwgaW48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyBjb25qdW5jdGlvbiB3aXRoIHRoZSBuZXR3b3JrIGlu ZnJhc3RydWN0dXJlLCBwcm92aWRlcyB0aGUgcmVxdWlyZWQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyB0eXBlIG9mIHNlcnZpY2UuPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZsdDttZ2x0Jmd0OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+SSBhc3N1bWUgdGhhdCBzZXNzaW9uIGNvbnRpbnVpdHkgaXMgb25s eSB1bmRlcnN0b29kIGFzIElQIHNlc3Npb24gY29udGludWl0eSBhbmQgbm90IHRoZSB0cmFuc3Bv cnQgbGF5ZXIuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbHQ7L21n bHQmZ3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyBJdCBpcyBm b3IgdGhlIGJlbmVmaXQgb2YgYm90aCB0aGUgdXNlcnMgYW5kIHRoZTxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IG5ldHdvcmsgb3BlcmF0b3JzIG5v dCB0byBlbmdhZ2UgYW4gZXh0cmEgbGV2ZWwgb2Ygc2VydmljZSB1bmxlc3MgaXQ8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyBpcyBhYnNvbHV0ZWx5 IG5lY2Vzc2FyeS4mbmJzcDsgSXQgaXMgZXhwZWN0ZWQgdGhhdCBhcHBsaWNhdGlvbnMgYW5kPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgbmV0d29y a3MgY29tcGxpYW50IHdpdGggdGhpcyBzcGVjaWZpY2F0aW9uIHdpbGwgdXRpbGl6ZSB0aGlzIHNv bHV0aW9uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJz cDsgdG8gdXNlIG5ldHdvcmsgcmVzb3VyY2VzIG1vcmUgZWZmaWNpZW50bHkuPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZsdDttZ2x0Jmd0OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+VGhlIGludHJvZHVjdGlvbiBzaG91bGQgYWxzbyBwb3NpdGlvbiBpdCB3 b3JrIHJlZ2FyZGluZyA1MDE0LiBBdCB0aGUgcG9pbnQgaXQgaXMgbm90IGNsZWFyIHdoeSB0aGUg cmVjb21tZW5kYXRpb25zIGNvdWxkIG5vdCBiZSBzdWNoIGFzOjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+KiB3aGVuIElQIHNlc3Npb24gcmVhY2hhYmlsaXR5IG9ubHkg aXMgcmVxdWlyZXMgdGhlIGFwcGxpY2F0aW9uIGluZGljYXRlcyBhIHByZWZlcmVuY2UgZm9yIFB1 YmxpYyBJUCBhZGRyZXNzZXM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi Piogd2hlbiBJUCBzZXNzaW9uIGNvbnRpbnVpdHkgaXMgbmVlZGVkIHRoZSBhcHBsaWNhdGlvbiBz ZW5kcyBhIHByZWZlcmVuY2UgZm9yIGhvbWUgb2YgYWRkcmVzcy48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiogd2hlbiBub25lIGlzIHJlcXVpcmVkIHRoZSBhcHBsaWNh dGlvbiBzZW5kcyBhIHByZWZlcmVuY2UgZm9yIENhcmUgb2YgQWRkcmVzcy48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZsdDsvbWdsdCZndDs8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jmx0O21nbHQmZ3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij5XaGlsZSBvbiBkZW1hbmQgaXMgbWVudGlvbmVkIGluIHRoZSB0aXRsZSwgaXQg ZG9lcyBub3QgYXBwZWFyIGluIHRoZSBpbnRyb2R1Y3Rpb24uIEkgYmVsaWV2ZSB0aGUgaW50cm9k dWN0aW9uIHNob3VsZCBleHBvc2Ugd2h5IHRoZXJlIGlzIGEgbmVlZCB0byBoYXZlIHRoaXMgZmVh dHVyZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZsdDsvbWdsdCZn dDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Mi4mbmJzcDsgTm90YXRpb25hbCBDb252 ZW50aW9uczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgVGhlIGtl eSB3b3JkcyAmcXVvdDtNVVNUJnF1b3Q7LCAmcXVvdDtNVVNUIE5PVCZxdW90OywgJnF1b3Q7UkVR VUlSRUQmcXVvdDssICZxdW90O1NIQUxMJnF1b3Q7LCAmcXVvdDtTSEFMTCBOT1QmcXVvdDssPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgJnF1b3Q7 U0hPVUxEJnF1b3Q7LCAmcXVvdDtTSE9VTEQgTk9UJnF1b3Q7LCAmcXVvdDtSRUNPTU1FTkRFRCZx dW90OywgJnF1b3Q7TUFZJnF1b3Q7LCBhbmQgJnF1b3Q7T1BUSU9OQUwmcXVvdDsgaW4gdGhpczxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IGRvY3Vt ZW50IGFyZSB0byBiZSBpbnRlcnByZXRlZCBhcyBkZXNjcmliZWQgaW4gW1JGQzIxMTldLjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4zLiZuYnNwOyBTb2x1dGlvbjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4zLjEuJm5ic3A7IFR5cGVzIG9mIElQIEFkZHJlc3NlczxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgRm91ciB0eXBlcyBvZiBJUCBhZGRy ZXNzZXMgYXJlIGRlZmluZWQgd2l0aCByZXNwZWN0IHRvIG1vYmlsaXR5PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgbWFuYWdlbWVudC48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IC0gRml4ZWQgSVAgQWRkcmVzczxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgQSBGaXhlZCBJUCBhZGRy ZXNzIGlzIGFuIGFkZHJlc3Mgd2l0aCBhIGd1YXJhbnRlZSB0byBiZSB2YWxpZCBmb3IgYTxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IHZlcnkgbG9u ZyB0aW1lLCByZWdhcmRsZXNzIG9mIHdoZXRoZXIgaXQgaXMgYmVpbmcgdXNlZCBpbiBhbnkgcGFj a2V0PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsg dG8vZnJvbSB0aGUgbW9iaWxlIGhvc3QsIG9yIHdoZXRoZXIgb3Igbm90IHRoZSBtb2JpbGUgaG9z dCBpczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7 IGNvbm5lY3RlZCB0byB0aGUgbmV0d29yaywgb3Igd2hldGhlciBpdCBtb3ZlcyBmcm9tIG9uZSBw b2ludC1vZi08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZu YnNwOyBhdHRhY2htZW50IHRvIGFub3RoZXIgKHdpdGggYSBkaWZmZXJlbnQgSVAgcHJlZml4KSB3 aGlsZSBpdCBpczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7 Jm5ic3A7IGNvbm5lY3RlZC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmx0O21nbHQm Z3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5UaG91Z2h0IGVuZ2xp c2ggaXMgbm90IG15IGZpcnN0IGxhbmd1YWdlLCAmcXVvdDtndWFyYW50ZWUmcXVvdDsgc291bmRz IGEgYml0IGluYXBwcm9wcmlhdGUuIEkgbWlnaHQgYmUgd3JvbmcgYnV0IHRoZSBmb2xsb3dpbmcg dGV4dCBzZWVtcyBjbGVhcmVyIHRvPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij5tZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+T0xEOjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+QSBGaXhlZCBJUCBhZGRyZXNzIGlzIGFuIGFkZHJl c3Mgd2l0aCBhIGd1YXJhbnRlZSB0byBiZSB2YWxpZCBmb3IgYTxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IHZlcnkgbG9uZyB0aW1lPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPk5FVzo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPkEgRml4ZWQgSVAgYWRkcmVzcyBpcyBhbiBhZGRyZXNzIHRoYXQgcmVtYWlucyB2 YWxpZCBmb3IgYTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7 Jm5ic3A7IHZlcnkgbG9uZyB0aW1lPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZsdDsv bWdsdCZndDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IEZpeGVk IElQIGFkZHJlc3NlcyBhcmUgcmVxdWlyZWQgYnkgYXBwbGljYXRpb25zIHRoYXQgbmVlZCBib3Ro PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgc2Vz c2lvbiBjb250aW51aXR5IGFuZCBJUCBhZGRyZXNzIHJlYWNoYWJpbGl0eS48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jmx0O21nbHQmZ3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij5JIHRoaW5rIHRoZSBkb2N1bWVudCBzaG91bGQgY2xhcmlmeSBob3cgdGhp cyBpcyBkaWZmZXJlbnQgZnJvbSBhIHB1YmxpYyBhZGRyZXNzIDUwMTQuPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbHQ7L21nbHQmZ3Q7PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyAtIFNlc3Npb24tbGFzdGluZyBJUCBBZGRyZXNzPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyBBIHNlc3Npb24tbGFzdGlu ZyBJUCBhZGRyZXNzIGlzIGFuIGFkZHJlc3Mgd2l0aCBhIGd1YXJhbnRlZSB0byBiZTxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IHZhbGlkIHRocm91 Z2hvdXQgdGhlIGxpZmUtdGltZSBvZiB0aGUgc29ja2V0KHMpIGZvciB3aGljaCBpdCB3YXM8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyByZXF1ZXN0 ZWQuJm5ic3A7IEl0IGlzIGd1YXJhbnRlZWQgdG8gYmUgdmFsaWQgZXZlbiBhZnRlciB0aGUgbW9i aWxlIGhvc3Q8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZu YnNwOyBoYWQgbW92ZWQgZnJvbSBvbmUgcG9pbnQtb2YtYXR0YWNobWVudCB0byBhbm90aGVyICh3 aXRoIGEgZGlmZmVyZW50PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m bmJzcDsmbmJzcDsgSVAgcHJlZml4KS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmx0 O21nbHQmZ3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5TaW1pbGFy bHkgSSB3b3VsZCBwcm9wb3NlIHRoZSBmb2xsb3dpbmcgdGV4dDo8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+T0xEOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jm5ic3A7IEEgc2Vzc2lvbi1sYXN0aW5nIElQIGFkZHJlc3MgaXMgYW4gYWRkcmVzcyB3aXRoIGEg Z3VhcmFudGVlIHRvIGJlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m bmJzcDsmbmJzcDsgdmFsaWQgdGhyb3VnaG91dCB0aGUgbGlmZS10aW1lIG9mIHRoZSBzb2NrZXQo cyk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+TkVXOjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7IEEgc2Vzc2lvbi1sYXN0aW5nIElQIGFkZHJlc3Mg aXMgYW4gYWRkcmVzczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5i c3A7Jm5ic3A7IHZhbGlkIHRocm91Z2hvdXQgdGhlIGxpZmUtdGltZSBvZiB0aGUgc29ja2V0KHMp PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPk9MRDo8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPkl0IGlzIGd1YXJhbnRlZWQgdG8gYmUgdmFsaWQgZXZlbiBhZnRl cjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5ORVc6PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij5JdCByZW1haW5zIHZhbGlkIGV2ZW4gYWZ0ZXI8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZsdDsvbWdsdCZndDs8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+WWVnaW4sIGV0IGFsLiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBFeHBpcmVzIEphbnVhcnkgMjcsIDIw MTkmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgW1BhZ2UgNF08bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+SW50ZXJuZXQtRHJhZnQmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgT24gRGVtYW5k IE1vYmlsaXR5Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEp1 bHkgMjAxODxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgU2Vzc2lv bi1sYXN0aW5nIElQIGFkZHJlc3NlcyBhcmUgcmVxdWlyZWQgYnkgYXBwbGljYXRpb25zIHRoYXQg bmVlZDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7 IHNlc3Npb24gY29udGludWl0eSBidXQgZG8gbm90IG5lZWQgSVAgYWRkcmVzcyByZWFjaGFiaWxp dHkuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZsdDttZ2x0Jmd0OzxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+SG9tZSBvZiBBZGRyZXNzIHByb3ZpZGVzIElQ IHJlYWNoYWJpbGl0eSwgYnV0IGl0IGlzIHVuY2xlYXIgaWYgSVAgc2Vzc2lvbiBjb250aW51aXR5 IGNhbiBiZSBwcm92aWRlZCBieSBvdGhlciBtZWNoYW5pc21zIHRoYXQgTW9iaWxlIElQLjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+SWYgdGhhdCB3ZXJlIHRoZSBjYXNl LCBpdCB3b3VsZCBiZSBnb29kIHRvIHNwZWNpZnkgaG93IHRoaXMgY291ZGwgYmUgcHJvdmlkZWQg d2l0aG91dCBJUCByZWFjaGFiaWxpdHkuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mbHQ7L21nbHQmZ3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNw OyZuYnNwOyAtIE5vbi1wZXJzaXN0ZW50IElQIEFkZHJlc3M8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jm5ic3A7Jm5ic3A7IFRoaXMgdHlwZSBvZiBJUCBhZGRyZXNzIGhhcyBubyBndWFy YW50ZWUgdG8gZXhpc3QgYWZ0ZXIgYSBtb2JpbGUgaG9zdDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IG1vdmVzIGZyb20gb25lIHBvaW50LW9mLWF0 dGFjaG1lbnQgdG8gYW5vdGhlciwgYW5kIHRoZXJlZm9yZSwgbm88bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyBzZXNzaW9uIGNvbnRpbnVpdHkgbm9y IElQIGFkZHJlc3MgcmVhY2hhYmlsaXR5IGFyZSBwcm92aWRlZC4mbmJzcDsgVGhlIElQPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgYWRkcmVzcyBp cyBjcmVhdGVkIGZyb20gYW4gSVAgcHJlZml4IHRoYXQgaXMgb2J0YWluZWQgZnJvbSB0aGU8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyBzZXJ2aW5n IElQIGdhdGV3YXkgYW5kIGlzIG5vdCBtYWludGFpbmVkIGFjcm9zcyBnYXRld2F5IGNoYW5nZXMu Jm5ic3A7IEluPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsm bmJzcDsgb3RoZXIgd29yZHMsIHRoZSBJUCBwcmVmaXggbWF5IGJlIHJlbGVhc2VkIGFuZCByZXBs YWNlZCBieSBhIG5ldyBvbmU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZuYnNwOyZuYnNwOyB3aGVuIHRoZSBJUCBnYXRld2F5IGNoYW5nZXMgZHVlIHRvIHRoZSBtb3Zl bWVudCBvZiB0aGUgbW9iaWxlIGhvc3Q8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZuYnNwOyZuYnNwOyBmb3JjaW5nIHRoZSBjcmVhdGlvbiBvZiBhIG5ldyBzb3VyY2Ug SVAgYWRkcmVzcyB3aXRoIHRoZSB1cGRhdGVkPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgYWxsb2NhdGVkIElQIHByZWZpeC48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jmx0O21nbHQmZ3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij5JdCB3b3VkbCBiZSBnb29kIHRvIHBvc2l0aW9uIHRoaXMgdG93YXJkIHRo ZSBjYXJlIG9mIGFkZHJlc3MuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mbHQ7L21nbHQmZ3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNw OyAtIEdyYWNlZnVsIFJlcGxhY2VtZW50IElQIEFkZHJlc3M8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jm5ic3A7Jm5ic3A7IEluIHNvbWUgY2FzZXMsIHRoZSBuZXR3b3JrIGNhbm5vdCBn dWFyYW50ZWUgdGhlIHZhbGlkaXR5IG9mIHRoZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IHByb3ZpZGVkIElQIHByZWZpeCB0aHJvdWdob3V0IHRo ZSBkdXJhdGlvbiBvZiB0aGUgb3BlbmVkIHNvY2tldCwgYnV0PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgY2FuIHByb3ZpZGUgYSBsaW1pdGVkIGdy YWNlZnVsIHBlcmlvZCBvZiB0aW1lIGluIHdoaWNoIGJvdGggdGhlPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgb3JpZ2luYWwgSVAgcHJlZml4IGFu ZCBhIG5ldyBvbmUgYXJlIHZhbGlkLiZuYnNwOyBUaGlzIGVuYWJsZXMgdGhlPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgYXBwbGljYXRpb24gc29t ZSBmbGV4aWJpbGl0eSBpbiB0aGUgdHJhbnNpdGlvbiBmcm9tIHRoZSBleGlzdGluZzxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IHNvdXJjZSBJUCBh ZGRyZXNzIHRvIHRoZSBuZXcgb25lLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJz cDsmbmJzcDsgVGhpcyBncmFjZWZ1bG5lc3MgaXMgc3RpbGwgYmV0dGVyIHRoYW4gdGhlIG5vbi1w ZXJzaXN0ZW5jZSB0eXBlIG9mPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mbmJzcDsmbmJzcDsgYWRkcmVzcyBmb3IgYXBwbGljYXRpb25zIHRoYXQgY2FuIGhhbmRsZSBh IGNoYW5nZSBpbiB0aGVpciBzb3VyY2UgSVA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZuYnNwOyZuYnNwOyBhZGRyZXNzIGJ1dCByZXF1aXJlIHRoYXQgZXh0cmEgZmxl eGliaWxpdHkuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZsdDttZ2x0Jmd0OzxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+VGhlIGNsYXNzZXMgZGVmaW5lZCBh Ym92ZSBoYXZlIG92ZXJsYXBzLiBJIGJlbGlldmUgdGhhdCB3ZSBoYXZlOjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Rml4ZWQgSVAgQWRkcmVzcyBcaW4gU2Vzc2lvbi1s YXN0aW5nIElQIEFkZHJlc3MgXGluIEdyYWNlZnVsIFJlcGxhY2VtZW50IElQIEFkZHJlc3MgXGlu IE5vbi1wZXJzaXN0ZW50IElQIEFkZHJlc3M8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ SSB0aGluayB0aGF0IHNob3VsZCBiZSBzdGF0ZWQgaW4gdGhlIHNlY3Rpb24uPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZsdDsvbWdsdCZndDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jm5ic3A7Jm5ic3A7IEFwcGxpY2F0aW9ucyBydW5uaW5nIGFzIHNlcnZlcnMgYXQgYSBw dWJsaXNoZWQgSVAgYWRkcmVzcyByZXF1aXJlIGE8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyBGaXhlZCBJUCBBZGRyZXNzLiZuYnNwOyBMb25nLXN0 YW5kaW5nIGFwcGxpY2F0aW9ucyAoZS5nLiwgYW4gU1NIIHNlc3Npb24pPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgbWF5IGFsc28gcmVxdWlyZSB0 aGlzIHR5cGUgb2YgYWRkcmVzcy4mbmJzcDsgRW50ZXJwcmlzZSBhcHBsaWNhdGlvbnMgdGhhdDxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IGNvbm5l Y3QgdG8gYW4gZW50ZXJwcmlzZSBuZXR3b3JrIHZpYSB2aXJ0dWFsIExBTiByZXF1aXJlIGEgRml4 ZWQgSVA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNw OyBBZGRyZXNzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgQXBw bGljYXRpb25zIHdpdGggc2hvcnQtbGl2ZWQgdHJhbnNpZW50IHNlc3Npb25zIGNhbiB1c2UgU2Vz c2lvbi08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNw OyBsYXN0aW5nIElQIEFkZHJlc3Nlcy4mbmJzcDsgRm9yIGV4YW1wbGU6IFdlYiBicm93c2Vycy48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IEFwcGxpY2F0aW9ucyB3 aXRoIHZlcnkgc2hvcnQgc2Vzc2lvbnMsIHN1Y2ggYXMgRE5TIGNsaWVudHMgYW5kPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgaW5zdGFudCBtZXNz ZW5nZXJzLCBjYW4gdXRpbGl6ZSBOb24tcGVyc2lzdGVudCBJUCBBZGRyZXNzZXMuJm5ic3A7IEV2 ZW48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyB0 aG91Z2ggdGhleSBjb3VsZCB2ZXJ5IHdlbGwgdXNlIEZpeGVkIG9yIFNlc3Npb24tbGFzdGluZyBJ UDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IEFk ZHJlc3NlcywgdGhlIHRyYW5zbWlzc2lvbiBsYXRlbmN5IHdvdWxkIGJlIG1pbmltaXplZCB3aGVu IGEgTm9uLTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5i c3A7IHBlcnNpc3RlbnQgSVAgQWRkcmVzc2VzIGFyZSB1c2VkLjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgQXBwbGljYXRpb25zIHRoYXQgY2FuIHRvbGVyYXRlIGEg c2hvcnQgaW50ZXJydXB0aW9uIGluIGNvbm5lY3Rpdml0eTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IGNhbiB1c2UgdGhlIEdyYWNlZnVsLXJlcGxh Y2VtZW50IElQIGFkZHJlc3Nlcy4mbmJzcDsgRm9yIGV4YW1wbGUsIGE8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyBzdHJlYW1pbmcgY2xpZW50IHRo YXQgaGFzIGJ1ZmZlcmluZyBjYXBhYmlsaXRpZXMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPlllZ2luLCBldCBhbC4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgRXhwaXJlcyBKYW51YXJ5IDI3LCAyMDE5Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFtQYWdlIDVdPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPkludGVybmV0LURyYWZ0Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE9uIERlbWFuZCBNb2JpbGl0eSZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBKdWx5IDIwMTg8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+My4yLiZuYnNwOyBHcmFudWxhcml0eSBvZiBTZWxlY3Rp b248bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IElQIGFkZHJlc3Mg dHlwZSBzZWxlY3Rpb24gaXMgbWFkZSBvbiBhIHBlci1zb2NrZXQgZ3JhbnVsYXJpdHkuPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgRGlmZmVyZW50 IHBhcnRzIG9mIHRoZSBzYW1lIGFwcGxpY2F0aW9uIG1heSBoYXZlIGRpZmZlcmVudCBuZWVkcy48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyBGb3Ig ZXhhbXBsZSwgdGhlIGNvbnRyb2wtcGxhbmUgb2YgYW4gYXBwbGljYXRpb24gbWF5IHJlcXVpcmUg YSBGaXhlZDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5i c3A7IElQIEFkZHJlc3MgaW4gb3JkZXIgdG8gc3RheSByZWFjaGFibGUsIHdoZXJlYXMgdGhlIGRh dGEtcGxhbmUgb2YgdGhlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m bmJzcDsmbmJzcDsgc2FtZSBhcHBsaWNhdGlvbiBtYXkgYmUgc2F0aXNmaWVkIHdpdGggYSBTZXNz aW9uLWxhc3RpbmcgSVAgQWRkcmVzcy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+My4z LiZuYnNwOyBPbiBEZW1hbmQgTmF0dXJlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZu YnNwOyZuYnNwOyBBdCBhbnkgcG9pbnQgaW4gdGltZSwgYSBtb2JpbGUgaG9zdCBtYXkgaGF2ZSBh IGNvbWJpbmF0aW9uIG9mIElQPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mbmJzcDsmbmJzcDsgYWRkcmVzc2VzIGNvbmZpZ3VyZWQuJm5ic3A7IFplcm8gb3IgbW9yZSBO b24tcGVyc2lzdGVudCwgemVybyBvciBtb3JlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgU2Vzc2lvbi1sYXN0aW5nLCB6ZXJvIG9yIG1vcmUgRml4 ZWQgYW5kIHplcm8gb3IgbW9yZSBHcmFjZWZ1bC08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyBSZXBsYWNlbWVudCBJUCBhZGRyZXNzZXMgbWF5IGJl IGNvbmZpZ3VyZWQgYnkgdGhlIElQIHN0YWNrIG9mIHRoZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IGhvc3QuJm5ic3A7IFRoZSBjb21iaW5hdGlv biBtYXkgYmUgYXMgYSByZXN1bHQgb2YgdGhlIGhvc3QgcG9saWN5LDxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IGFwcGxpY2F0aW9uIGRlbWFuZCwg b3IgYSBtaXggb2YgdGhlIHR3by48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmx0O21n bHQmZ3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5MaXN0aW5nIHRo ZSBkaWZmZXJlbnQgY2xhc3NlcyBpbiB0aGUgc2FtZSBvcmRlciBhcyB0aGUgb25lIG9mIHRoZSBk ZWZpbml0aW9ucyBtYXkgZWFzZSB0aGUgcmVhZGluZy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZsdDsvbWdsdCZndDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jm5ic3A7Jm5ic3A7IFdoZW4gYW4gYXBwbGljYXRpb24gcmVxdWlyZXMgYSBzcGVjaWZpYyB0 eXBlIG9mIElQIGFkZHJlc3MgYW5kIHN1Y2g8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZuYnNwOyZuYnNwOyBhbiBhZGRyZXNzIGlzIG5vdCBhbHJlYWR5IGNvbmZpZ3Vy ZWQgb24gdGhlIGhvc3QsIHRoZSBJUCBzdGFjayBTSEFMTDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IGF0dGVtcHQgdG8gY29uZmlndXJlIG9uZS4m bmJzcDsgRm9yIGV4YW1wbGUsIGEgaG9zdCBtYXkgbm90IGFsd2F5cyBoYXZlIGE8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyBTZXNzaW9uLWxhc3Rp bmcgSVAgYWRkcmVzcyBhdmFpbGFibGUuJm5ic3A7IFdoZW4gYW4gYXBwbGljYXRpb24gcmVxdWVz dHM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyBv bmUsIHRoZSBJUCBzdGFjayBTSEFMTCBtYWtlIGFuIGF0dGVtcHQgdG8gY29uZmlndXJlIG9uZSBi eSBpc3N1aW5nIGE8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNw OyZuYnNwOyByZXF1ZXN0IHRvIHRoZSBuZXR3b3JrIChzZWUgU2VjdGlvbiAzLjQgYmVsb3cgZm9y IG1vcmUgZGV0YWlscykuJm5ic3A7IElmPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mbmJzcDsmbmJzcDsgdGhlIG9wZXJhdGlvbiBmYWlscywgdGhlIElQIHN0YWNrIFNI QUxMIGZhaWwgdGhlIGFzc29jaWF0ZWQgc29ja2V0PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgcmVxdWVzdCBhbmQgcmV0dXJuIGFuIGVycm9yLiZu YnNwOyBJZiBzdWNjZXNzZnVsLCBhIFNlc3Npb24tbGFzdGluZyBJUDxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IEFkZHJlc3MgZ2V0cyBjb25maWd1 cmVkIG9uIHRoZSBtb2JpbGUgaG9zdC4mbmJzcDsgSWYgYW5vdGhlciBzb2NrZXQ8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyByZXF1ZXN0cyBhIFNl c3Npb24tbGFzdGluZyBJUCBhZGRyZXNzIGF0IGEgbGF0ZXIgdGltZSwgdGhlIHNhbWUgSVA8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyBhZGRyZXNz IG1heSBiZSBzZXJ2ZWQgdG8gdGhhdCBzb2NrZXQgYXMgd2VsbC4mbmJzcDsgV2hlbiB0aGUgbGFz dCBzb2NrZXQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZu YnNwOyB1c2luZyB0aGUgc2FtZSBjb25maWd1cmVkIElQIGFkZHJlc3MgaXMgY2xvc2VkLCB0aGUg SVAgYWRkcmVzcyBtYXkgYmU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZuYnNwOyZuYnNwOyByZWxlYXNlZCBvciBrZXB0IGZvciBmdXR1cmUgYXBwbGljYXRpb25zIHRo YXQgbWF5IGJlIGxhdW5jaGVkIGFuZDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jm5ic3A7Jm5ic3A7IHJlcXVpcmUgYSBTZXNzaW9uLWxhc3RpbmcgSVAgYWRkcmVzcy48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmx0O21nbHQmZ3Q7PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5JIHN1c3BlY3QgdGhlIGFwcGxpY2F0aW9uIGlzIGV4 cGVjdGVkIHRvIHJlcXVlc3QgdGhlIHR5cGUgb2YgSVAgd2l0aCBtaW5pbWFsIGNhcGFiaWxpdGll cy4gSW4gc29tZSBjYXNlcyB0aGUgT1MgbWF5IG5vdCBoYXZlIHRoZSByZXF1ZXN0ZWQgdHlwZSBv ZiBhZGRyZXNzIGJ1IG1heSBoYXZlIGFub3RoZXIgdHlwZSBvZiBhZGRyZXNzZXMgdGhhdCBjb3Vs ZCBmdWxmaWxsIHRoZSBhcHBsaWNhdGlvbiByZXF1aXJlbWVudHMuDQogSSBiZWxpZXZlIHRoZSB0 ZXh0IHNob3VsZCBzcGVjaWZ5IHdoYXQgc2hvdWxkIGJlIGRvbmUgaW4gdGhpcyBzaXR1YXRpb24u IEkgc3VwcG9zZSB0aGUgdGV4dCB3aWxsIHNheSB0aGF0IHRoZSBob3N0IHNlbmRzIGEgcmVxdWVz dCB0byB0aGUgbmV0d29yay48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+SG93ZXZlciwg SSBzdXNwZWN0IHRoYXQgYWxsb3dpbmcgdGhlIE9TIHRvIHJldHVybiBoaWdoZXIgY2FwYWJpbGl0 aWVzIHdvdWxkIGVuY291cmFnZSB0aGUgYXBwbGljYXRpb25zIHRvIHNlbmQgYSBtaW5pbWFsIGxl dmVsIG9mIGV4cGVjdGF0aW9uIHNvIHRvIG1heGltaXplIHRoZSBwcm9iYWJpbGl0eSBvZiBhdm9p ZGluZyBhIGludGVyYWN0aW9uIGJldHdlZW4gdGhlIGhvc3QgYW5kIHRoZSBuZXR3b3JrIHRvDQog cmVxdWVzdCB0aGUgc3BlY2lmaWMgdHlwZSBvZiBJUCBhZGRyZXNzLjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmx0Oy9tZ2x0Jmd0OzxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgSW4gc29tZSBjYXNlcyBpdCBtaWdodCBiZSBwcmVmZXJh YmxlIGZvciB0aGUgbW9iaWxlIGhvc3QgdG8gcmVxdWVzdCBhPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgbmV3IFNlc3Npb24tbGFzdGluZyBJUCBh ZGRyZXNzIGZvciBhIG5ldyBvcGVuaW5nIG9mIGFuIElQIHNvY2tldDxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IChldmVuIHRob3VnaCBvbmUgd2Fz IGFscmVhZHkgYXNzaWduZWQgdG8gdGhlIG1vYmlsZSBob3N0IGJ5IHRoZTxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IG5ldHdvcmsgYW5kIG1pZ2h0 IGJlIGluIHVzZSBpbiBhIGRpZmZlcmVudCwgYWxyZWFkeSBhY3RpdmUgSVA8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyBzb2NrZXRzKS4mbmJzcDsg SXQgaXMgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyBzcGVjaWZpY2F0aW9uIHRvIGRlZmluZTxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IGNyaXRl cmlhIGZvciBjaG9vc2luZyB0byB1c2UgYXZhaWxhYmxlIGFkZHJlc3NlcyBvciBjaG9vc2luZyB0 bzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IHJl cXVlc3QgbmV3IG9uZXMuJm5ic3A7IEl0IHN1cHBvcnRzIGJvdGggYWx0ZXJuYXRpdmVzIChhbmQg YW55PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsg Y29tYmluYXRpb24pLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsg SXQgaXMgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyBzcGVjaWZpY2F0aW9uIHRvIGRlZmluZSBo b3cgdGhlIGhvc3Q8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNw OyZuYnNwOyByZXF1ZXN0cyBhIHNwZWNpZmljIHR5cGUgb2YgcHJlZml4IGFuZCBob3cgdGhlIG5l dHdvcmsgaW5kaWNhdGVzIHRoZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jm5ic3A7Jm5ic3A7IHR5cGUgb2YgcHJlZml4IGluIGl0cyBhZHZlcnRpc2VtZW50IG9yIGlu IGl0cyByZXBseSB0byBhIHJlcXVlc3QpLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m bmJzcDsmbmJzcDsgVGhlIGZvbGxvd2luZyBhcmUgbWF0dGVycyBvZiBwb2xpY3ksIHdoaWNoIG1h eSBiZSBkaWN0YXRlZCBieSB0aGU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZuYnNwOyZuYnNwOyBob3N0IGl0c2VsZiwgdGhlIG5ldHdvcmsgb3BlcmF0b3IsIG9yIHRo ZSBzeXN0ZW0gYXJjaGl0ZWN0dXJlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mbmJzcDsmbmJzcDsgc3RhbmRhcmQ6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PlllZ2luLCBldCBhbC4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgRXhwaXJlcyBKYW51YXJ5IDI3LCAyMDE5Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IFtQYWdlIDZdPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PkludGVybmV0LURyYWZ0Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE9uIERlbWFuZCBNb2JpbGl0eSZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBKdWx5IDIwMTg8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IC0gVGhlIGluaXRpYWwgc2V0IG9mIElQ IGFkZHJlc3NlcyBjb25maWd1cmVkIG9uIHRoZSBob3N0IGF0IGJvb3Q8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyB0aW1lLjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgLSBQZXJtaXNzaW9uIHRvIGdyYW50IHZhcmlv dXMgdHlwZXMgb2YgSVAgYWRkcmVzc2VzIHRvIGEgcmVxdWVzdGluZzxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IGFwcGxpY2F0aW9uLjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgLSBEZXRlcm1pbmF0aW9uIG9mIGEg ZGVmYXVsdCBhZGRyZXNzIHR5cGUgd2hlbiBhbiBhcHBsaWNhdGlvbiBkb2VzPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgbm90IG1ha2UgYW55IGV4 cGxpY2l0IGluZGljYXRpb24sIHdoZXRoZXIgaXQgYWxyZWFkeSBzdXBwb3J0cyB0aGU8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyByZXF1aXJlZCBB UEkgb3IgaXQgaXMganVzdCBhIGxlZ2FjeSBhcHBsaWNhdGlvbi48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+My40LiZuYnNwOyBDb252ZXlpbmcgdGhlIERlc2lyZWQgQWRkcmVzcyBUeXBl PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyBbUkZDNTAxNF0gaW50 cm9kdWNlZCB0aGUgYWJpbGl0eSBvZiBhcHBsaWNhdGlvbnMgdG8gaW5mbHVlbmNlIHRoZTxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IHNvdXJjZSBh ZGRyZXNzIHNlbGVjdGlvbiB3aXRoIHRoZSBJUFY2X0FERFJfUFJFRkVSRU5DRSBvcHRpb24gYXQg dGhlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsg SVBQUk9UT19JUFY2IGxldmVsLiZuYnNwOyBUaGlzIG9wdGlvbiBpcyB1c2VkIHdpdGggc2V0c29j a29wdCgpIGFuZDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7 Jm5ic3A7IGdldHNvY2tvcHQoKSBjYWxscyB0byBzZXQvZ2V0IGFkZHJlc3Mgc2VsZWN0aW9uIHBy ZWZlcmVuY2VzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgRXh0 ZW5kaW5nIHRoaXMgZnVydGhlciBieSBhZGRpbmcgbW9yZSBmbGFncyBkb2VzIG5vdCB3b3JrIHdo ZW4gYTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7 IHJlcXVlc3QgZm9yIGFuIGFkZHJlc3Mgb2YgYSBjZXJ0YWluIHR5cGUgcmVzdWx0cyBpbiByZXF1 aXJpbmcgdGhlIElQPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJz cDsmbmJzcDsgc3RhY2sgdG8gd2FpdCBmb3IgdGhlIG5ldHdvcmsgdG8gcHJvdmlkZSB0aGUgZGVz aXJlZCBzb3VyY2UgSVAgcHJlZml4PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mbmJzcDsmbmJzcDsgYW5kIGhlbmNlIGNhdXNpbmcgdGhlIHNldHNvY2tvcHQoKSBjYWxs IHRvIGJsb2NrIHVudGlsIHRoZSBwcmVmaXggaXM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyBhbGxvY2F0ZWQgKG9yIGFuIGVycm9yIGluZGljYXRp b24gZnJvbSB0aGUgbmV0d29yayBpcyByZWNlaXZlZCkuPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZsdDttZ2x0Jmd0OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+T25lIHRoaW5nIGlzIHRoZSB2YWx1ZSBvZiB0aGUgZmxhZ3MsIGFub3RoZXIgdGhpbmcgaXMg dGhlIGJlaGF2aW91ciBvZiB0aGUgQVBJLiBTbyBJIHVuZGVyc3RhbmQgdGhhdCB0aGUgbmV3IEFQ SSBwcm92aWRlcyBtb3JlIGZsZXhpYmlsaXR5IGluIHRoZSBzZW5zZSB0aGF0IGEgcmVxdWlyZW1l bnQgdGhhdCBjYW5ub3QgYmUgZnVsZmlsbGVkIGRvZXMgbm90IG5lY2Vzc2FyaWx5IGVuZCB1cCBp biBhbiBlcnJvci4NCiBJbnN0ZWFkIGl0IGNhbiBsZWFkIGluIGFuIElQIGFkZHJlc3MgdGhhdCBk b2VzIG5vdCBmdWxmaWxsIHRoZSBhcHBsaWNhdGlvbiByZXF1aXJlbWVudC4gSWYgdGhhdCBpcyBj b3JyZWN0LCB0aGlzIGlzIHN0aWxsIHNvbWV0aGluZyB0aGUgYXBwbGljYXRpb24gd2lsbCBoYXZl IHRvIGRlYWwgd2l0aC4gSU4gb25lIGNhc2UsIGl0IHdpbGwgbmVlZCB0byBkZWFsIHdpdGggYW4g ZXJyb3IsIGluIHRoZSBvdGhlciBjYXNlLCB3aXRoIHNvbWV0aGluZyB0aGF0DQogZG9lcyBub3Qg ZnVsZmlsbCB0aGUgcmVxdWlyZW1lbnRzLiBJZiB0aGF0IGlzIGNvcnJlY3QsIEkgYmVsaWV2ZSB0 aGUgYmVuZWZpdCBvZiBpdCBzaG91bGQgYmUgaGlnaGxpZ2h0ZWQuPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbHQ7L21nbHQmZ3Q7PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZuYnNwOyZuYnNwOyBBbHRlcm5hdGl2ZWx5IGEgbmV3IHNvY2tldCBBUEkgaXMg ZGVmaW5lZCAtIGdldHNjKCkgd2hpY2ggYWxsb3dzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgYXBwbGljYXRpb25zIHRvIGV4cHJlc3MgdGhlaXIg ZGVzaXJlZCB0eXBlIG9mIHNlc3Npb24gY29udGludWl0eTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IHNlcnZpY2UuJm5ic3A7IFRoZSBuZXcgZ2V0 c2MoKSBBUEkgd2lsbCByZXR1cm4gYW4gSVB2NiBhZGRyZXNzIHRoYXQgaXM8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyBhc3NvY2lhdGVkIHdpdGgg dGhlIGRlc2lyZWQgc2Vzc2lvbiBjb250aW51aXR5IHNlcnZpY2UgYW5kIHdpdGg8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyBzdGF0dXMgaW5mb3Jt YXRpb24gaW5kaWNhdGluZyB3aGV0aGVyIG9yIG5vdCB0aGUgZGVzaXJlZCBzZXJ2aWNlIHdhczxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IHByb3Zp ZGVkLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgQW4gYXBwbGlj YXRpb24gdGhhdCB3aXNoZXMgdG8gc2VjdXJlIGEgZGVzaXJlZCBzZXJ2aWNlIHdpbGwgY2FsbDxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IGdldHNj KCkgd2l0aCB0aGUgc2VydmljZSB0eXBlIGRlZmluaXRpb24gYW5kIGEgcGxhY2UgdG8gY29udGFp biB0aGU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNw OyBwcm92aWRlZCBJUCBhZGRyZXNzLCBhbmQgY2FsbCBiaW5kKCkgdG8gYXNzb2NpYXRlIHRoYXQg SVAgYWRkcmVzczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7 Jm5ic3A7IHdpdGggdGhlIHNvY2tldCAoU2VlIHBzZXVkby1jb2RlIGV4YW1wbGUgaW4gU2VjdGlv biA0IGJlbG93KS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IFdo ZW4gdGhlIElQIHN0YWNrIGlzIHJlcXVpcmVkIHRvIHVzZSBhIHNvdXJjZSBJUCBhZGRyZXNzIG9m IGE8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyBz cGVjaWZpZWQgdHlwZSwgaXQgY2FuIHVzZSBhbiBleGlzdGluZyBhZGRyZXNzLCBvciByZXF1ZXN0 IGEgbmV3IElQPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsm bmJzcDsgcHJlZml4IChvZiB0aGUgc2FtZSB0eXBlKSBmcm9tIHRoZSBuZXR3b3JrIGFuZCBjcmVh dGUgYSBuZXcgb25lLiZuYnNwOyBJZjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jm5ic3A7Jm5ic3A7IHRoZSBob3N0IGRvZXMgbm90IGFscmVhZHkgaGF2ZSBhbiBJUHY2 IHByZWZpeCBvZiB0aGF0IHNwZWNpZmljIHR5cGUsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgaXQgTVVTVCByZXF1ZXN0IG9uZSBmcm9tIHRoZSBu ZXR3b3JrLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgVXNpbmcg YW4gZXhpc3RpbmcgYWRkcmVzcyBmcm9tIGFuIGV4aXN0aW5nIHByZWZpeCBpcyBmYXN0ZXIgYnV0 IG1pZ2h0PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJz cDsgeWllbGQgYSBsZXNzIG9wdGltYWwgcm91dGUgKGlmIGEgaGFuZC1vZmYgZXZlbnQgb2NjdXJy ZWQgYWZ0ZXIgaXRzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJz cDsmbmJzcDsgY29uZmlndXJhdGlvbikuJm5ic3A7IE9uIHRoZSBvdGhlciBoYW5kLCBhY3F1aXJp bmcgYSBuZXcgSVAgcHJlZml4IGZyb208bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZuYnNwOyZuYnNwOyB0aGUgbmV0d29yayBtYXkgYmUgc2xvd2VyIGR1ZSB0byBzaWdu YWxpbmcgZXhjaGFuZ2Ugd2l0aCB0aGUgbmV0d29yay48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jm5ic3A7Jm5ic3A7IEFwcGxpY2F0aW9ucyBjYW4gY29udHJvbCB0aGUgc3RhY2sncyBv cGVyYXRpb24gYnkgc2V0dGluZyBhIG5ldyBmbGFnPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgLSBPTl9ORVQgZmxhZyAtIHdoaWNoIGRpcmVjdHMg dGhlIElQIHN0YWNrIHdoZXRoZXIgdG8gdXNlIGE8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+WWVnaW4sIGV0IGFsLiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBFeHBpcmVzIEphbnVhcnkgMjcsIDIwMTkmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgW1BhZ2UgN108bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+SW50ZXJuZXQtRHJhZnQmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgT24gRGVtYW5kIE1vYmlsaXR5Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEp1bHkgMjAxODxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgcHJlY29uZmlndXJlZCBzb3VyY2Ug SVAgYWRkcmVzcyAoaWYgZXhpc3RzKSBvciB0byByZXF1ZXN0IGEgbmV3IElQdjY8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyBwcmVmaXggZnJvbSB0 aGUgY3VycmVudCBzZXJ2aW5nIG5ldHdvcmsgYW5kIGNvbmZpZ3VyZSBhIG5ldyBJUDxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IGFkZHJlc3MuPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyBUaGlzIG5ldyBmbGFnIGlz IGFkZGVkIHRvIHRoZSBzZXQgb2YgZmxhZ3MgaW4gdGhlPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgSVBWNl9BRERSX1BSRUZFUkVOQ0VTIG9wdGlv biBhdCB0aGUgSVBQUk9UT19JUFY2IGxldmVsLiZuYnNwOyBJdCBpcyB1c2VkPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgaW4gc2V0c29ja29wdCgp IHRvIHNldCB0aGUgZGVzaXJlZCBiZWhhdmlvci48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jmx0O21nbHQmZ3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5N eSB1bmRlcnN0YW5kaW5nIG9mIHRoZSBmbGFnIGlzIHRoYXQgaXQgZm9yY2VzIHRoZSBPUyB0byBy ZXF1ZXN0IHRoZSBuZXR3b3JrLiBUaGlzIG1lYW5zIHRoYXQgZXZlbiBpZiBpdCBhbHJlYWR5IGhh cyB0ZWggZGVzaXJlZCBJUCBhZGRyZXNzIHRoZSBPTl9ORVQgZmxhZyBzZXQgd2lsbCBmb3JjZSB0 aGUgT1MgdG8gcmUtYXNrLiBXaGVuIHVuc2V0LCB0aGUgZGVjaXNpb24gdG8gcmUtYXNrIG9yIG5v dCBpcw0KIGxldCB0byB0aGUgT1MuIElTIHRoYXQgY29ycmVjdCA/PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbHQ7L21nbHQmZ3Q7PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPjQuJm5ic3A7IFVzYWdlIGV4YW1wbGU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+NC4xLiZuYnNwOyBQc2V1ZG8tY29kZSBleGFtcGxlPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZsdDttZ2x0Jmd0OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+SXQgd291bGQgYmUgZ29vZCB0aGUgZXhhbXBsZSBhbHNvIHNob3dzIHRoZSBPTl9ORVQg ZmxhZy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZsdDsvbWdsdCZn dDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IFRoZSBmb2xsb3dp bmcgZXhhbXBsZSBzaG93cyBwc2V1ZG8tY29kZSBmb3IgY3JlYXRpbmcgYSBTdHJlYW0gc29ja2V0 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgKFRD UCkgd2l0aCBhIFNlc3Npb24tTGFzdGluZyBzb3VyY2UgSVAgYWRkcmVzczo8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7ICNpbmNsdWRlICZsdDtzeXMvc29ja2V0Lmgm Z3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsg I2luY2x1ZGUgJmx0O25ldGlubmV0L2luLmgmZ3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAvLyBTb2NrZXQgaW5mb3JtYXRpb248bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyBpbnQmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgcyA7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC8vIHNvY2tldCBpZDxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLy8gU291cmNlIGluZm9ybWF0 aW9uIChmb3Igc2Vjc2MoKSBhbmQgYmluZCgpKTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IHNvY2thZGRyX2luNiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBzb3VyY2VJbmZvJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC8vIG15IGFkZHJlc3MgYW5k IHBvcnQgZm9yIGJpbmQoKTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jm5ic3A7Jm5ic3A7IGluNl9hZGRyJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IHNvdXJjZUFkZHJlc3MmbmJzcDsgLy8gd2lsbCBjb250YWluIHRoZSBwcm92 aXNpb25lZDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC8vIHNvdXJjZSBJUCBhZGRyZXNzPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgdWludDhfdCZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBzY190eXBlID0g SVBWNl9SRVFVSVJFX1NFU1NJT05fTEFTVElOR19JUCA7PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLy8gRm9y IHJlcXVlc3RpbmcgYSBTZXNzaW9uLUxhc3Rpbmc8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAvLyBzb3VyY2Ug SVAgYWRkcmVzczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgLy8gRGVzdGluYXRpb24gaW5mb3JtYXRpb24gKGZvciBjb25uZWN0KCkpPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgc29ja2FkZHJf aW42Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHNlcnZlckluZm8gOyZuYnNwOyZuYnNwOyAvLyBz ZXJ2ZXIgaW5mbyBmb3IgY29ubmVjdCgpPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAvLyBDcmVhdGUgYW4gSVB2NiBUQ1Agc29ja2V0PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgcyA9IHNvY2tl dChBRl9JTkVUNiwgU09DS19TVFJFQU0sIDApIDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyBpZiAocyE9MCkgezxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IC8vIEhhbmRsZSBzb2NrZXQgY3JlYXRpb24gZXJyb3I8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAvLyAuLi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZuYnNwOyZuYnNwOyB9IC8vIGlmIHNvY2tldCBjcmVhdGlvbiBmYWlsZWQ8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyBlbHNlIHs8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAvLyBTb2NrZXQgY3JlYXRpb24g aXMgc3VjY2Vzc2Z1bDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC8vIFRo ZSBhcHBsaWNhdGlvbiBjYW5ub3QgY29ubmVjdCB5ZXQsIHNpbmNlIGl0IHdhbnRzIHRvIHVzZTxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC8vIGEgU2Vzc2lvbi1MYXN0aW5n IHNvdXJjZSBJUCBhZGRyZXNzIEl0IG5lZWRzIHRvIHJlcXVlc3Q8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAvLyB0aGUgU2Vzc2lvbi1MYXN0aW5nIHNvdXJjZSBJUCBiZWZv cmUgY29ubmVjdGluZzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGlmIChzZXRzYyhzLCAmYW1w O3NvdXJjZUFkZHJlc3MsICZhbXA7c2NfdHlwZSkpID09IDApezxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC8vIHNldHRpbmcgc2Vzc2lvbiBj b250aW51aXR5IHRvIFNlc3Npb24gTGFzdGluZyBpczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC8vIFN1Y2Nlc3NmdWwuIHNvdXJjZUFkZHJl c3Mgbm93IGNvbnRhaW5zIHRoZSBTZXNzaW9uLTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC8vIExBc3Rpbmcgc291cmNlIElQIGFkZHJlc3Mg Jmx0O21nbHQmZ3Q7cy9MQXN0aW5nL0xhc3RpbmcvZ2MmbHQ7L21nbHQmZ3Q7PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPlllZ2luLCBldCBhbC4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgRXhwaXJlcyBKYW51YXJ5IDI3LCAy MDE5Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFtQYWdlIDhdPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPkludGVybmV0LURyYWZ0Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE9uIERlbWFu ZCBNb2JpbGl0eSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBK dWx5IDIwMTg8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC8v IEJpbmQgdG8gdGhhdCBzb3VyY2UgSVAgYWRkcmVzczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IHNvdXJjZUluZm8uc2luNl9mYW1pbHkgPSBBRl9JTkVUNiA7PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc291cmNlSW5mby5zaW42 X3BvcnQgPSAwJm5ic3A7IC8vIGxldCB0aGUgc3RhY2sgY2hvb3NlIHRoZSBwb3J0PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc291cmNlSW5mby5zaW42X2FkZHJl c3MgPSBzb3VyY2VBZGRyZXNzIDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAvLyBVc2UgdGhlIHNvdXJjZSBh ZGRyZXNzIHRoYXQgd2FzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLy8gZ2VuZXJhdGVkIGJ5IHRoZSBzZXRz YygpIGNhbGw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBpZiAo YmluZChzLCAmYW1wO3NvdXJjZUluZm8sIHNpemVvZihzb3VyY2VJbmZvKSk9PTApezxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IC8vIFNldCB0aGUgZGVzaXJlZCBzZXJ2ZXIncyBpbmZvcm1hdGlvbiBmb3IgY29u bmVjdCgpPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgc2VydmVySW5mby5zaW42X2ZhbWlseSA9IEFGX0lORVQ2IDs8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBzZXJ2 ZXJJbmZvLnNpbjZfcG9ydCA9IFNFUlZFUl9QT1JUX05VTSA7PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc2VydmVyQWRkcmVzcy5z aW42X2FkZHIgPSBTRVJWRVJfSVBWNl9BRERSRVNTIDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC8vIENvbm5lY3QgdG8gdGhl IHNlcnZlcjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IGlmIChjb25uZWN0KHMsICZhbXA7c2VydmVySW5mbywgc2l6ZW9mKHNlcnZl ckluZm8pKT09MCkgezxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOy8vIGNvbm5lY3Qgc3Vj Y2Vzc2Z1bCAoMy13YXkgaGFuZHNoYWtlIGhhcyBiZWVuPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgLy8gY29tcGxldGVkIHdpdGggU2Vzc2lvbi1MYXN0aW5nIHNvdXJjZSBhZGRyZXNzLjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC8vIENvbnRpbnVlIGFwcGxpY2F0aW9uIGZ1bmN0 aW9uYWxpdHk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAvLyAuLi48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB9Jm5ic3A7 IC8vIGlmIGNvbm5lY3QoKSBpcyBzdWNjZXNzZnVsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZWxzZSB7PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgLy8gY29ubmVjdCBmYWlsZWQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAvLyAuLi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAvLyBBcHBsaWNhdGlvbiBj b2RlIHRoYXQgaGFuZGxlcyBjb25uZWN0IGZhaWx1cmUgYW5kPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgLy8gY2xvc2VzIHRoZSBzb2NrZXQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAvLyAuLi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyB9IC8vIGlmIGNvbm5lY3QoKSBmYWlsZWQ8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB9IC8vIGlmIGJpbmQoKSBzdWNjZXNzZnVsPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZWxzZSB7PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgLy8gYmluZCgpIGZhaWxlZDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IC8vIC4uLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC8vIEFwcGxpY2F0aW9u IGNvZGUgdGhhdCBoYW5kbGVzIGJpbmQgZmFpbHVyZSBhbmQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAvLyBjbG9zZXMgdGhlIHNvY2tldDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IC8vIC4uLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IH0gLy8g aWYgYmluZCgpIGZhaWxlZDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IH0mbmJzcDsgLy8gaWYg c2V0c2MoKSB3YXMgc3VjY2Vzc2Z1bCBhbmQgb2YgYSBTZXNzaW9uLUxhc3Rpbmc8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAvLyBzb3VyY2UgSVAgYWRkcmVzcyB3 YXMgcHJvdmlkZWQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBlbHNlIHs8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAvLyBhcHBsaWNhdGlv biBjb2RlIHRoYXQgZG9lcyBub3QgdXNlIFNlc3Npb24tbGFzdGluZyBJUDxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC8vIGFkZHJlc3MuIFRo ZSBhcHBsaWNhdGlvbiBtYXkgZWl0aGVyIGNvbm5lY3Qgd2l0aG91dDxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC8vIHRoZSBkZXNpcmVkIFNl c3Npb24tbGFzdGluZyBzZXJ2aWNlLCBvciBjbG9zZSB0aGU8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAvLyBzb2NrZXQuLi48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyB9IC8vIGlmIHNldHNjKCkgZmFpbGVkPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgfSZuYnNwOyAvLyBpZiBzb2NrZXQg d2FzIGNyZWF0ZWQgc3VjY2Vzc2Z1bGx5PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAvLyBUaGUgcmVzdCBvZiB0aGUgYXBwbGljYXRpb24ncyBj b2RlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgLy8gLi4uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlllZ2luLCBl dCBhbC4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgRXhwaXJlcyBKYW51YXJ5IDI3LCAyMDE5Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IFtQYWdlIDldPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkludGVybmV0 LURyYWZ0Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE9uIERlbWFuZCBNb2JpbGl0eSZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBKdWx5IDIwMTg8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+NC4yLiZuYnNwOyBNZXNzYWdlIEZsb3cgZXhhbXBsZTxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgVGhlIGZvbGxvd2luZyBtZXNzYWdlIGZsb3cg aWxsdXN0cmF0ZXMgYSBwb3NzaWJsZSBpbnRlcmFjdGlvbiBmb3I8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyBhY2hpZXZpbmcgT25EZW1hbmQgZnVu Y3Rpb25hbGl0eS4mbmJzcDsgSXQgaXMgYW4gZXhhbXBsZSBvZiBvbmUgc2NlbmFyaW88bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyBhbmQgc2hvdWxk IG5vdCBiZSByZWdhcmRlZCBhcyB0aGUgb25seSBzY2VuYXJpbyBvciB0aGUgcHJlZmVycmVkIG9u ZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmx0O21nbHQmZ3Q7T25EZW1hbmQgdmVy c3VzIE9uIERlbWFuZCB2ZXJzdXMgT24tRGVtYW5kLiBUaGUgdGV4dCBzaG91bGQgYmUgY29uc2lz dGVudC4gJmx0Oy9tZ2x0Jmd0OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jm5ic3A7Jm5ic3A7IFRoaXMgZmxvdyBkZXNjcmliZXMgdGhlIGludGVyYWN0aW9uIGJldHdl ZW4gdGhlIGZvbGxvd2luZyBlbnRpdGllczo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jm5ic3A7Jm5ic3A7IC0gQXBwbGljYXRpb25zIHJlcXVpcmluZyBkaWZmZXJlbnQgdHlwZXMgb2Yg T25EZW1hbmQgc2VydmljZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5i c3A7IC0gVGhlIG1vYmlsZSBob3N0J3MgSVAgc3RhY2suPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZuYnNwOyZuYnNwOyAtIFRoZSBuZXR3b3JrIGluZnJhc3RydWN0dXJlIHByb3ZpZGlu ZyB0aGUgc2VydmljZXMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNw OyBJbiB0aGlzIGV4YW1wbGUsIHRoZSBuZXR3b3JrIGluZnJhc3RydWN0dXJlIHByb3ZpZGVzIDIg SVB2NiBwcmVmaXhlczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5i c3A7Jm5ic3A7IHVwb24gYXR0YWNobWVudCBvZiB0aGUgbW9iaWxlIGhvc3QgdG8gdGhlIG5ldHdv cms6IEEgU2Vzc2lvbi1sYXN0aW5nPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mbmJzcDsmbmJzcDsgSVB2NiBwcmVmaXggYW5kIGEgTm9uLXBlcnNpc3RlbnQgSVB2NiBw cmVmaXguJm5ic3A7IFdoZW5ldmVyIHRoZSBtb2JpbGU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyBob3N0IG1vdmVzIHRvIGEgZGlmZmVyZW50IHBv aW50LW9mLWF0dGFjaG1lbnQsIHRoZSBuZXR3b3JrPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgaW5mcmFzdHJ1Y3R1cmUgcHJvdmlkZXMgYSBuZXcg Tm9uLXBlcnNpc3RlbnQgSVB2NiBhZGRyZXNzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mbmJzcDsmbmJzcDsgSW4gdGhpcyBleGFtcGxlLCB0aGUgbmV0d29yayBpbmZyYXN0cnVjdHVy ZSBkb2VzIG5vdCBzdXBwb3J0IEZpeGVkIElQPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgYWRkcmVzc2VzIG5vciBHcmFjZWZ1bC1yZXBsYWNlbWVu dCBJUCBhZGRyZXNzZXMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNw OyBXaGVuZXZlciBhbiBhcHBsaWNhdGlvbiBvcGVucyBhbiBJUCBzb2NrZXQgYW5kIHJlcXVlc3Rz IGEgc3BlY2lmaWM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNw OyZuYnNwOyBJUHY2IGFkZHJlc3MgdHlwZSwgdGhlIElQIHN0YWNrIHdpbGwgcHJvdmlkZSBvbmUg ZnJvbSBpdHMgYXZhaWxhYmxlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mbmJzcDsmbmJzcDsgSVB2NiBwcmVmaXhlcyBvciByZXR1cm4gYW4gZXJyb3IgbWVzc2FnZSBp ZiB0aGUgcmVxdWVzdCBjYW5ub3QgYmU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZuYnNwOyZuYnNwOyBmdWxmaWxsZWQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZuYnNwOyZuYnNwOyBNZXNzYWdlIEZsb3c6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZuYnNwOyZuYnNwOyAtIFRoZSBtb2JpbGUgZGV2aWNlIGF0dGFjaGVzIHRvIHRoZSBuZXR3 b3JrLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgLSBUaGUgTmV0 d29yayBwcm92aWRlcyB0d28gSVB2NiBwcmVmaXhlczogUFJFRnNsMSAtIGEgU2Vzc2lvbi1sYXN0 aW5nPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsg SVB2NiBwcmVmaXggYW5kIFBSRUZucDEgLSBhIE5vbi1wZXJzaXN0ZW50IElQIHY2IHByZWZpeC48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmx0O21nbHQmZ3Q7SVAgdjYvSVB2Ni9nYyZs dDsvbWdsdCZndDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZsdDtt Z2x0Jmd0O0l0IHdvdWxkIGVhc2UgdGhlIHJlYWRpbmcgaWYgdGhlIG1lY2hhbmlzbSB1c2VkIHRv IHNwZWNpZnkgdGhlIFR5cGUgb2YgdGhlIGFkZHJlc3MgYnkgdGhlIG9wZXJhdG9yIHRvIHRoZSBo b3N0IGJlaW5nIGRlc2NyaWJlZCAtIGF0IGxlYXN0IGFuIGV4YW1wbGUuPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbHQ7L21nbHQmZ3Q7PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyAtIEFuIGFwcGxpY2F0aW9uIG9uIHRoZSBtb2JpbGUg aG9zdCBpcyBsYXVuY2hlZC4mbmJzcDsgSXQgb3BlbnMgYW4gSVA8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyBzb2NrZXQgYW5kIHJlcXVlc3RzIGEg Tm9uLXBlcnNpc3RlbnQgSVB2NiBhZGRyZXNzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mbmJzcDsmbmJzcDsgLSBUaGUgSVAgc3RhY2sgcHJvdmlkZXMgSVBucDEgd2hpY2ggaXMgZ2Vu ZXJhdGVkIGZyb20gUFJFRm5wMS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7 Jm5ic3A7IC0gQW5vdGhlciBhcHBsaWNhdGlvbiBpcyBsYXVuY2hlZCwgcmVxdWVzdGluZyBhIE5v bi1wZXJzaXN0ZW50IElQdjY8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZuYnNwOyZuYnNwOyBhZGRyZXNzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJz cDsmbmJzcDsgLSBUaGUgSVAgc3RhY2sgcHJvdmlkZXMgSVBucDEgYWdhaW4uPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyAtIEEgdGhpcmQgYXBwbGljYXRpb24gaXMg bGF1bmNoZWQuJm5ic3A7IFRoaXMgdGltZSwgaXQgcmVxdWlyZXMgYSBTZXNzaW9uLTxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IGxhc3RpbmcgSVB2 NiBhZGRyZXNzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbHQ7bWdsdCZndDtzZWNv bmQgPyZsdDsvbWdsdCZndDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+WWVnaW4sIGV0 IGFsLiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBFeHBpcmVzIEphbnVhcnkgMjcsIDIwMTkmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgW1BhZ2UgMTBdPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkludGVybmV0LURyYWZ0 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IE9uIERlbWFuZCBNb2JpbGl0eSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBKdWx5IDIwMTg8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jm5ic3A7Jm5ic3A7IC0gVGhlIElQIHN0YWNrIHByb3ZpZGVzIElQc2wxIHdoaWNoIGlz IGdlbmVyYXRlZCBmcm9tIFBSRUZzbDEuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZu YnNwOyZuYnNwOyAtIFRoZSBtb2JpbGUgaG9zdHMgbW92ZXMgdG8gYSBuZXcgcG9pbnQtb2YtYXR0 YWNobWVudC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IC0gVGhl IG5ldHdvcmsgcHJvdmlkZXMgYSBuZXcgTm9uLXBlcnNpc3RlbnQgSVB2NiBwcmVmaXggLSBQUkVG bnAyLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7 IFBSRUZucDEgaXMgbm8gbG9uZ2VyIHZhbGlkLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mbmJzcDsmbmJzcDsgLSBUaGUgYXBwbGljYXRpb25zIHRoYXQgd2VyZSBnaXZlbiBJUG5wMSBy ZS1lc3RhYmxpc2ggdGhlIHNvY2tldCBhbmQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZuYnNwOyZuYnNwOyByZWNlaXZlIGEgbmV3IElQdjYgYWRkcmVzcyAtIElQbnAy IHdoaWNoIGlzIGdlbmVyYXRlZCBmcm9tIFBSRUZucDI8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jm5ic3A7Jm5ic3A7IC0gVGhlIGFwcGxpY2F0aW9uIHRoYXQgaXMgdXNpbmcgSVBzbDEg Y2FuIHN0aWxsIHVzZSBpdCBzaW5jZSB0aGU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZuYnNwOyZuYnNwOyBuZXR3b3JrIGd1YXJhbnRlZWQgdGhhdCBQUkVGc2wxIHdp bGwgYmUgdmFsaWQgZXZlbiBhZnRlciBtb3ZpbmcgdG8gYTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IG5ldyBwb2ludC1vZi1hdHRhY2htZW50Ljxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgLSBBIG5ldyBhcHBsaWNh dGlvbiBpcyBsYXVuY2hlZCwgdGhpcyB0aW1lIHJlcXVpcmluZyBhIEdyYWNlZnVsLTxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IHJlcGxhY2VtZW50 IElQdjYgYWRkcmVzcy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7 IC0gVGhlIElQIHN0YWNrIHJldHVybnMgc2V0c2MoKSB3aXRoIGFuIGVycm9yIHNpbmNlIHRoZSBu ZXR3b3JrIGRvZXM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNw OyZuYnNwOyBub3Qgc3VwcG9ydCB0aGlzIHNlcnZpY2UuPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZuYnNwOyZuYnNwOy0gVGhlIGFwcGxpY2F0aW9uIHJlLWF0dGVtcHRzIHRvIG9wZW4g YSBzb2NrZXQsIHRoaXMgdGltZSByZXF1ZXN0aW5nPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgYSBTZXNzaW9uLWxhc3RpbmcgSVB2NiBhZGRyZXNz LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgLSBUaGUgSVAgc3Rh Y2sgcHJvdmlkZXMgSVBzbDEuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjUuJm5ic3A7 IEJhY2t3YXJkcyBDb21wYXRpYmlsaXR5IENvbnNpZGVyYXRpb25zPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyBCYWNrd2FyZHMgY29tcGF0aWJpbGl0eSBzdXBwb3J0 IGlzIFJFUVVJUkVEIGJ5IHRoZSBmb2xsb3dpbmcgMyB0eXBlczxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IG9mIGVudGl0aWVzOjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgLSBUaGUgQXBwbGljYXRpb25zIG9uIHRo ZSBtb2JpbGUgaG9zdDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsg LSBUaGUgSVAgc3RhY2sgaW4gdGhlIG1vYmlsZSBob3N0PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZuYnNwOyZuYnNwOyAtIFRoZSBuZXR3b3JrIGluZnJhc3RydWN0dXJlPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjUuMS4mbmJzcDsgQXBwbGljYXRpb25zPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyBMZWdhY3kgYXBwbGljYXRpb25zIHRoYXQg ZG8gbm90IHN1cHBvcnQgdGhlIE9uRGVtYW5kIGZ1bmN0aW9uYWxpdHk8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyB3aWxsIHVzZSB0aGUgbGVnYWN5 IEFQSSBhbmQgd2lsbCBub3QgYmUgYWJsZSB0byB0YWtlIGFkdmFudGFnZSBvZiB0aGU8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyBPbi1EZW1hbmQg TW9iaWxpdHkgZmVhdHVyZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5i c3A7IEFwcGxpY2F0aW9ucyB1c2luZyB0aGUgbmV3IE9uRGVtYW5kIGZ1bmN0aW9uYWxpdHkgTVVT VCBiZSBhd2FyZSB0aGF0PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m bmJzcDsmbmJzcDsgdGhleSBtYXkgYmUgZXhlY3V0ZWQgaW4gbGVnYWN5IGVudmlyb25tZW50cyB0 aGF0IGRvIG5vdCBzdXBwb3J0IGl0LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jm5ic3A7Jm5ic3A7IFN1Y2ggZW52aXJvbm1lbnRzIG1heSBpbmNsdWRlIGEgbGVnYWN5 IElQIHN0YWNrIG9uIHRoZSBtb2JpbGUgaG9zdCw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyBsZWdhY3kgbmV0d29yayBpbmZyYXN0cnVjdHVyZSwg b3IgYm90aC4mbmJzcDsgSW4gZWl0aGVyIGNhc2UsIHRoZSBBUEkgd2lsbDxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IHJldHVybiBhbiBlcnJvciBj b2RlIGFuZCB0aGUgaW52b2tpbmcgYXBwbGljYXRpb25zIG1heSBqdXN0IGdpdmUgdXA8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyBhbmQgdXNlIGxl Z2FjeSBjYWxscy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+WWVnaW4sIGV0IGFsLiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJz cDtFeHBpcmVzIEphbnVhcnkgMjcsIDIwMTkmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgW1Bh Z2UgMTFdPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkludGVybmV0LURyYWZ0Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IE9uIERlbWFuZCBNb2JpbGl0eSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBKdWx5IDIwMTg8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ NS4yLiZuYnNwOyBJUCBTdGFjayBpbiB0aGUgTW9iaWxlIEhvc3Q8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IE5ldyBJUCBzdGFja3MgTVVTVCBjb250aW51ZSB0byBz dXBwb3J0IGFsbCBsZWdhY3kgb3BlcmF0aW9ucy4mbmJzcDsgSWYgYW48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyBhcHBsaWNhdGlvbiBkb2VzIG5v dCB1c2UgT24tRGVtYW5kIGZ1bmN0aW9uYWxpdHksIHRoZSBJUCBzdGFjayBNVVNUPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgcmVzcG9uZCBpbiBh IGxlZ2FjeSBtYW5uZXIuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZsdDttZ2x0Jmd0 OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+VGhlIGxlZ2FjeSBtYW5u ZXIgZG9lcyBub3Qgc2VlbXMgdG8gYmUgYSBzdGFuZGFyZCB3YXkgb2YgYmVoYXZpb3IuIEl0IHNl ZW1zIHRvIG1lIGFzIHRoZSB3YXkgdGhlIE9TIHVzZWQgdG8gYmVoYXZlLiBJIGJlbGlldmUgdGhl IGRyYWZ0IHNob3VkbCBiZSBhIGJpdCBtb3JlIHNwZWNpZmljIGhlcmUuPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbHQ7L21nbHQmZ3Q7PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyBJZiB0aGUgbmV0d29yayBpbmZyYXN0cnVjdHVyZSBz dXBwb3J0cyBPbi1EZW1hbmQgZnVuY3Rpb25hbGl0eSwgdGhlPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgSVAgc3RhY2sgU0hPVUxEIGZvbGxvdyB0 aGUgYXBwbGljYXRpb24gcmVxdWVzdDogSWYgdGhlIGFwcGxpY2F0aW9uPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgcmVxdWVzdHMgYSBzcGVjaWZp YyBhZGRyZXNzIHR5cGUsIHRoZSBzdGFjayBTSE9VTEQgZm9yd2FyZCB0aGlzPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgcmVxdWVzdCB0byB0aGUg bmV0d29yay4mbmJzcDsgSWYgdGhlIGFwcGxpY2F0aW9uIGRvZXMgbm90IHJlcXVlc3QgYW48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyBhZGRyZXNz IHR5cGUsIHRoZSBJUCBzdGFjayBNVVNUIE5PVCByZXF1ZXN0IGFuIGFkZHJlc3MgdHlwZSBhbmQg bGVhdmU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNw OyBpdCB0byB0aGUgbmV0d29yaydzIGRlZmF1bHQgYmVoYXZpb3IgdG8gY2hvb3NlIHRoZSB0eXBl IG9mIHRoZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5i c3A7IGFsbG9jYXRlZCBJUCBwcmVmaXguJm5ic3A7IElmIGFuIElQIHByZWZpeCB3YXMgYWxyZWFk eSBhbGxvY2F0ZWQgdG8gdGhlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mbmJzcDsmbmJzcDsgaG9zdCwgdGhlIElQIHN0YWNrIHVzZXMgaXQgYW5kIG1heSBub3QgcmVx dWVzdCBhIG5ldyBvbmUgZnJvbSB0aGU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZuYnNwOyZuYnNwOyBuZXR3b3JrLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij41LjMuJm5ic3A7IE5ldHdvcmsgSW5mcmFzdHJ1Y3R1cmU8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jm5ic3A7Jm5ic3A7IFRoZSBuZXR3b3JrIGluZnJhc3RydWN0dXJlIG1heSBvciBt YXkgbm90IHN1cHBvcnQgdGhlIE9uLURlbWFuZDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IGZ1bmN0aW9uYWxpdHkuJm5ic3A7IEhvdyB0aGUgSVAg c3RhY2sgb24gdGhlIGhvc3QgYW5kIHRoZSBuZXR3b3JrPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgaW5mcmFzdHJ1Y3R1cmUgYmVoYXZlIGluIGNh c2Ugb2YgYSBjb21wYXRpYmlsaXR5IGlzc3VlIGlzIG91dHNpZGUgdGhlPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgc2NvcGUgb2YgdGhpcyBBUEkg c3BlY2lmaWNhdGlvbi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmx0O21nbHQmZ3Q7 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5JIGJlbGlldmUgdGhhdCBz dWNoIHN0YXRlbWVudCBzaG91bGQgYmUgbWFkZSBpbiB0aGUgaW50cm9kdWN0aW9uIHdpdGggdGhl IGFkZGl0aW9uIG9mIGEgbGlzdCBvZiBwb3RlbnRpYWwgbWVjaGFuaXNtIHRvIHByb3ZpZGUgdGhl IHR5cGUgb2YgSVAgYWRkcmVzc2VzIGJ5IHRoZSBuZXR3b3JrLiBUaGVyZSBpcyBhIG5lZWQgdG8g aGF2ZSBzdWNoIG1lY2hhbmlzbXMgc2luY2UgdGhlIE9TIGNhbm5vdCBkZXJpdmUNCiB0aGUgcHJv cGVydGllcyBmcm9tIHRoZSBJUCBhZGRyZXNzIGl0c2VsZi4gV2hpY2ggd2FzIHRlaCBjYXNlIHdp dGggSG9tZSBvZiBhZGRyZXNzLCBjYXJlIG9mIGFkZHJlc3MsIGNnYS4uLi48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZsdDsvbWdsdCZndDs8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+NS40LiZuYnNwOyBNZXJnaW5nIHRoaXMgd29yayB3aXRoIFJGQzUwMTQ8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IFtSRkM1MDE0XSBkZWZp bmVzIG5ldyBmbGFncyB0aGF0IG1heSBiZSB1c2VkIHdpdGggc2V0c29ja29wdCgpIHRvPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgaW5mbHVlbmNl IHNvdXJjZSBJUCBhZGRyZXNzIHNlbGVjdGlvbiBmb3IgYSBzb2NrZXQuJm5ic3A7IFRoZSBsaXN0 IG9mPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsg ZmxhZ3MgaW5jbHVkZTogc291cmNlIGhvbWUgYWRkcmVzcywgY2FyZS1vZiBhZGRyZXNzLCB0ZW1w b3Jhcnk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNw OyBhZGRyZXNzLCBwdWJsaWMgYWRkcmVzcyBDR0EgKENyeXB0b2dyYXBoaWNhbGx5IENyZWF0ZWQg QWRkcmVzcykgYW5kPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJz cDsmbmJzcDsgbm9uLUNHQS4mbmJzcDsgV2hlbiBhcHBsaWNhdGlvbnMgcmVxdWlyZSBzZXNzaW9u IGNvbnRpbnVpdHkgc2VydmljZSBhbmQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZuYnNwOyZuYnNwOyB1c2Ugc2V0c2MoKSBhbmQgYmluZCgpLCB0aGV5IFNIT1VMRCBO T1Qgc2V0IHRoZSBmbGFncyBzcGVjaWZpZWQgaW48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyBbUkZDNTAxNF0uPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZuYnNwOyZuYnNwOyBIb3dldmVyLCBpZiBhbiBhcHBsaWNhdGlvbiBzZXRzIGEg c3BlY2lmaWMgb3B0aW9uIHVzaW5nIHNldHNvY2tvcHQoKTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IHdpdGggb25lIG9mIHRoZSBmbGFncyBzcGVj aWZpZWQgaW4gW1JGQzUwMTRdIGFuZCBhbHNvIHNlbGVjdHMgYTxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IHNvdXJjZSBJUCBhZGRyZXNzIHVzaW5n IHNldHNjKCkgYW5kIGJpbmQoKSB0aGUgSVAgYWRkcmVzcyB0aGF0IHdhczxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IGdlbmVyYXRlZCBieSBzZXRz YygpIGFuZCBib3VuZCB1c2luZyBiaW5kKCkgd2lsbCBiZSB0aGUgb25lIHVzZWQgYnk8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyB0cmFmZmljIGdl bmVyYXRlZCB1c2luZyB0aGF0IHNvY2tldCBhbmQgb3B0aW9ucyBzZXQgYnkgc2V0c29ja29wdCgp PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgd2ls bCBiZSBpZ25vcmVkLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbHQ7bWdsdCZndDtU aGUgc2VudGVuY2UgYWJvdmUgaXMgaGFyZCB0byByZWFkIC0gYXQgbGVhc3QgdG8gbWUuIEkgc3Vz cGVjdCAmcXVvdDt0aGUmcXVvdDsgaXMgbWlzc2luZyBhZnRlciAmcXVvdDtieSZxdW90Oy4gV2hh dCB0aGUgdGV4dCBzYXlzIGlzIHRoYXQgYWZ0ZXIgYmluZCBzZXRzb2Nrb3B0IHdpbGwgYmUgaWdu b3JlZC4gQ29ycmVjdCA/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m bHQ7L21nbHQmZ3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyBJ ZiBiaW5kKCkgd2FzIG5vdCBpbnZva2VkIGFmdGVyIHNldHNjKCkgYnkgdGhlIGFwcGxpY2F0aW9u LCB0aGUgSVA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZu YnNwOyBhZGRyZXNzIGdlbmVyYXRlZCBieSBzZXRzYygpIHdpbGwgbm90IGJlIHVzZWQgYW5kIHRy YWZmaWMgZ2VuZXJhdGVkPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m bmJzcDsmbmJzcDsgYnkgdGhlIHNvY2tldCB3aWxsIHVzZSBhIHNvdXJjZSBJUCBhZGRyZXNzIHRo YXQgY29tcGxpZXMgd2l0aCB0aGU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZuYnNwOyZuYnNwOyBvcHRpb25zIHNlbGVjdGVkIGJ5IHNldHNvY2tvcHQoKS48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+WWVnaW4sIGV0IGFsLiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBFeHBpcmVzIEphbnVhcnkg MjcsIDIwMTkmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgW1BhZ2UgMTJdPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPkludGVybmV0LURyYWZ0Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE9uIERlbWFu ZCBNb2JpbGl0eSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDtK dWx5IDIwMTg8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Ni4mbmJzcDsgU3VtbWFyeSBv ZiBOZXcgRGVmaW5pdGlvbnM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmx0O21nbHQm Z3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5GbGFncyBhbmQgYWRk cmVzcyB0eXBlcyBzaG91bGQgaW4gbXkgb3BpbmlvbiBiZSBwbGFjZWQgaW4gZXZpZGVuY2UuICgu aCkgJmx0Oy9tZ2x0Jmd0OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij42LjEuJm5ic3A7 IE5ldyBBUElzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyBzZXRz YygpIGVuYWJsZXMgYXBwbGljYXRpb25zIHRvIHJlcXVlc3QgYSBzcGVjaWZpYyB0eXBlIG9mIHNv dXJjZSBJUDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5i c3A7IGFkZHJlc3MgaW4gdGVybXMgb2Ygc2Vzc2lvbiBjb250aW51aXR5LiZuYnNwOyBJdHMgZGVm aW5pdGlvbiBpczo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IGlu dCBzZXRzYyhpbnQgc29ja2ZkLCBpbjZfYWRkciAqc291cmNlQWRkcmVzcywgc2NfdHlwZSBhZGRy ZXNzVHlwZSk7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyBXaGVy ZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZu YnNwOyAtIHNvY2tmZCAtJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IGlzIHRoZSBzb2NrZXQgZGVzY3JpcHRvciBvZiB0aGUgc29ja2V0IHdpdGggd2hpY2g8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhIHNwZWNpZmlj IGFkZHJlc3MgdHlwZSBpcyBhc3NvY2lhdGVkPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgLSBzb3VyY2VBZGRyZXNzIC0gaXMgYSBwb2lu dGVyIHRvIGFuIGFyZWEgYWxsb2NhdGVkIGZvciBzZXRzYygpIHRvPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgcGxhY2UgdGhlIGdlbmVyYXRlZCBz b3VyY2UgSVAgYWRkcmVzcyBvZiB0aGU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBkZXNpcmVkIHNlc3Npb24gY29udGludWl0eSB0eXBlPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgLSBh ZGRyZXNzVHlwZSAtJm5ic3A7Jm5ic3A7IElzIHRoZSBkZXNpcmVkIHR5cGUgb2Ygc2Vzc2lvbiBj b250aW51aXR5IHNlcnZpY2UuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgSXQgaXMgYSAzLWJpdCBmaWVsZCBjb250YWluaW5nIG9uZSBvZiB0aGU8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBmb2xs b3dpbmcgdmFsdWVzOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IDAgLSBSZXNlcnZlZDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IDEgLSBGSVhFRF9JUFY2X0FERFJFU1M8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAyIC0gU0VTU0lPTl9MQVNUSU5H X0lQVjZfQUREUkVTUzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IDMgLSBOT05fUEVSU0lTVEVOVF9JUFY2X0FERFJFU1M8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA0IC0gR1JBQ0VGVUxfUkVQTEFD RU1FTlRfSVBWNl9BRERSRVNTPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgNS03IC0gUmVzZXJ2ZWQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jm5ic3A7Jm5ic3A7IHNldHNjKCkgcmV0dXJucyB0aGUgc3RhdHVzIG9mIHRoZSBvcGVyYXRp b246PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsm bmJzcDsgLSAwIC0gQWRkcmVzcyB3YXMgc3VjY2Vzc2Z1bGx5IGdlbmVyYXRlZDxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0gRUFJX1JF UVVJUkVESVBOT1RTVVBQT1JURUQgLSB0aGUgcmVxdWlyZWQgc2VydmljZSB0eXBlIGlzIG5vdDxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IHN1cHBvcnRlZDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0gRUFJX1JFUVVJUkVESVBGQUlMRUQgLSB0aGUgbmV0 d29yayBjb3VsZCBub3QgZnVsZmlsbCB0aGUgZGVzaXJlZDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHJlcXVlc3Q8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IHNldHNjKCkgTUFZIGJs b2NrIHRoZSBpbnZva2luZyB0aHJlYWQgaWYgaXQgdHJpZ2dlcnMgdGhlIFRDUC9JUCBzdGFjazxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IHRvIHJl cXVlc3QgYSBuZXcgSVAgcHJlZml4IGZyb20gdGhlIG5ldHdvcmsgdG8gY29uc3RydWN0IHRoZSBk ZXNpcmVkPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJz cDsgc291cmNlIElQIGFkZHJlc3MuJm5ic3A7IElmIGFuIElQIHByZWZpeCB3aXRoIHRoZSBkZXNp cmVkIHNlc3Npb248bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNw OyZuYnNwOyBjb250aW51aXR5IGZlYXR1cmVzIGFscmVhZHkgZXhpc3RzICh3YXMgcHJldmlvdXNs eSBhbGxvY2F0ZWQgdG8gdGhlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mbmJzcDsmbmJzcDsgbW9iaWxlIGhvc3QpIGFuZCB0aGUgc3RhY2sgaXMgbm90IHJlcXVpcmVk IHRvIHJlcXVlc3QgYSBuZXcgb25lIGFzIGE8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZuYnNwOyZuYnNwOyByZXN1bHQgb2Ygc2V0dGluZyB0aGUgSVBWNl9SRVFVSVJF X1NSQ19PTl9ORVQgZmxhZyAoZGVmaW5lZCBiZWxvdyksPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgc2V0c2MoKSBNQVkgcmV0dXJuIGltbWVkaWF0 ZWx5IHdpdGggdGhlIGNvbnN0cnVjdGVkIElQIGFkZHJlc3MgYW5kPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgd2lsbCBub3QgYmxvY2sgdGhlIHRo cmVhZC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Ni4yLiZuYnNwOyBOZXcgRmxhZ3M8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IFRoZSBmb2xsb3dpbmcg ZmxhZyBpcyBhZGRlZCB0byB0aGUgbGlzdCBvZiBmbGFncyBpbiB0aGU8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyBJUFY2X0FERFJfUFJFRkVSRU5D RSBvcHRpb24gYXQgdGhlIElQUFJPVE82IGxldmVsOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mbmJzcDsmbmJzcDsgSVBWNl9SRVFVSVJFX1NSQ19PTl9ORVQgLSBzZXQgSVAgc3RhY2sg YWRkcmVzcyBhbGxvY2F0aW9uIGJlaGF2aW9yPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PlllZ2luLCBldCBhbC4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgRXhwaXJlcyBKYW51YXJ5IDI3LCAyMDE5Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IFtQYWdlIDEzXTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5JbnRl cm5ldC1EcmFmdCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBPbiBEZW1hbmQgTW9iaWxpdHkmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSnVseSAyMDE4PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyBJZiBzZXQsIHRoZSBJUCBzdGFjayB3aWxsIHJl cXVlc3QgYSBuZXcgSVB2NiBwcmVmaXggb2YgdGhlIGRlc2lyZWQ8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyB0eXBlIGZyb20gdGhlIGN1cnJlbnQg c2VydmluZyBuZXR3b3JrIGFuZCBjb25maWd1cmUgYSBuZXcgc291cmNlIElQPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgYWRkcmVzcy4mbmJzcDsg SWYgcmVzZXQsIHRoZSBJUCBzdGFjayB3aWxsIHVzZSBhIHByZWNvbmZpZ3VyZWQgb25lIGlmIGl0 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgZXhp c3RzLiAmbmJzcDtJZiB0aGVyZSBpcyBubyBwcmVjb25maWd1cmVkIElQIGFkZHJlc3Mgb2YgdGhl IGRlc2lyZWQgdHlwZSw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZu YnNwOyZuYnNwOyBhIG5ldyBwcmVmaXggd2lsbCBiZSByZXF1ZXN0ZWQgYW5kIHVzZWQgZm9yIGNy ZWF0aW5nIHRoZSBJUCBhZGRyZXNzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij43LiZu YnNwOyBTZWN1cml0eSBDb25zaWRlcmF0aW9uczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mbmJzcDsmbmJzcDsgVGhlIHNldHRpbmcgb2YgY2VydGFpbiBJUCBhZGRyZXNzIHR5cGUgb24g YSBnaXZlbiBzb2NrZXQgbWF5IGJlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mbmJzcDsmbmJzcDsgcmVzdHJpY3RlZCB0byBwcml2aWxlZ2VkIGFwcGxpY2F0aW9ucy4m bmJzcDsgRm9yIGV4YW1wbGUsIGEgRml4ZWQgSVA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyBBZGRyZXNzIG1heSBiZSBwcm92aWRlZCBhcyBhIHBy ZW1pdW0gc2VydmljZSBhbmQgb25seSBjZXJ0YWluPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgYXBwbGljYXRpb25zIG1heSBiZSBhbGxvd2VkIHRv IHVzZSB0aGVtLiZuYnNwOyBTZXR0aW5nIGFuZCBlbmZvcmNlbWVudCBvZjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IHN1Y2ggcHJpdmlsZWdlcyBh cmUgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVudC48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jmx0O21nbHQmZ3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij5JIGJlbGlldmUgdGhlIHRleHQgY291bGQgZGVzY3JpYmUgdGhlIHRocmVhdCBzdWNo IHJlY29tbWVuZGF0aW9uIGlzIGFkZHJlc3NpbmcuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPlRoZSBkb2N1bWVudCBkZXNjcmliZXMgaG93IGFwcGxpY2F0aW9ucyBwcm92aWRlcyB0aGUg T1MgdGhlaXIgcmVxdWlyZW1lbnRzIGluIG9yZGVyIHRvIHNlbGVjdCB0aGUgYXBwcm9wcmlhdGVk IElQIGFkZHJlc3MuIFRoZSByZXNvdXJjZSBhcmUgYXNzb2NpYXRlZCB0byBkaWZmZXJlbnQgY29z dHMuIFdoaWxlIHRoZSBjb3N0IGlzIHByaW1hcmlseSBvbiB0aGUgb3BlcmF0b3Igc2lkZSwgaXQg aXMgbGlrZWx5DQogdGhhdCB1c2FnZSBieSB0aGUgbW9iaWxlIG5vZGUgY29tZXMgd2l0aCBzb21l IHJlc3RyaWN0aW9ucywgbGltaXRhdGlvbiBvciBkaXJlY3QgY29zdC4gVHlwaWNhbGx5LCBzb21l IHR5cGUgb2YgSVAgYWRkcmVzcyBtYXkgYmUgcHJvdmlkZWQgYnkgdGhlIG9wZXJhdG9yIGZvciBh IGxpbWl0ZWQgbnVtYmVyIG9mIGJ5dGVzIHVwb24gd2hpY2ggdGhlIElQIGFkZHJlc3MgdHlwZSB3 aWxsIG5vdCBiZSBhdmFpbGFibGUgdG8gdGhlIG1vYmlsZSBub2RlDQogb3IgbWF5IGJlIGNoYXJn ZWQuIEEgbWFsaWNpb3VzIGFwcGxpY2F0aW9uIG1heSB1c2UgdGhlc2UgbGltaXRhdGlvbnMgdG8g Z2VuZXJhdGUgZXh0cmEgYmlsbGluZyBvZiB0aGUgbW9iaWxlIG5vZGUgb3IgdG8gcHJldmVudCB0 aGUgdXNhZ2Ugb2Ygc29tZSBhcHBsaWNhdGlvbnMgYnkgZXhoYXVzdGluZyB0aGUgZXhwZWN0ZWQg dHlwZSBvZiBJUCBhZGRyZXNzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5JbiBvcmRl ciB0byBwcmV2ZW50IHN1Y2ggc2NlbmFyaW8sIHRoZSBtb2JpbGUgbm9kZSBTSE9VTEQgYmUgYWJs ZSB0byBhdXRob3JpemUgc3BlY2lmaWMgUEkgYWRkcmVzcyB0eXBlcyB0byBwcml2aWxlZ2UgYXBw bGljYXRpb24uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPldpdGggdGhlc2UgbmV3IHR5 cGVzIG9mIElQIGFkZHJlc3NlcywgdGhlIElQIGFkZHJlc3MgbGVha3Mgc29tZSBjb25uZWN0aXZp dHkgcmVxdWlyZW1lbnRzIG9mIHRoZSBhcHBsaWNhdGlvbi4gVGhpcyBhbHNvIG1lYW5zIHRoYXQg YWRkaXRpb25hbCBpbmZvcm1hdGlvbiBpcyBwcm92aWRlZCB0byB0aGUgZGVzdGluYXRpb24gd2hp Y2ggY291bGQgcmV2ZWFsIHRvIGEgcGFzc2l2ZSBtb25pdG9yaW5nIGF0dGFja2VyDQogc29tZSBp bmZvcm1hdGlvbiBzdWNoIGFzIHRoZSB0eXBlIG9mIGFwcGxpY2F0aW9uIGFuZCB0aGUgYXBwbGlj YXRpb24gaXRzZWxmIGV2ZW4gdGhvdWdoIHRoZSBwYWNrZXQgaXMgcHJvdGVjdGVkIGJ5IElQc2Vj IG9yIFRMUy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+VG8gYXZvaWQgcHJvZmlsaW5n IGFuIGFwcGxpY2F0aW9uIGFjY29yZGluZyB0byB0aGUgdHlwZSBvZiBJUCBhZGRyZXNzZXMsIGl0 IGlzIGV4cGVjdGVkIHRoYXQgcHJlZml4ZXMgcHJvdmlkZWQgYnkgdGhlIG9wZXJhdG9yIGFyZSBh c3NvY2lhdGVkIHRvIHZhcmlvdXMgdHlwZSBvZiBhZGRyZXNzZXMgb3ZlciB0aW1lLiBBcyBhIHJl c3VsdCwgdGhlIHR5cGUgb2YgYWRkcmVzcyBjb3VsZCBub3QgYmUgYXNzb2NpYXRlZA0KIHRvIHRo ZSBwcmVmaXgsIG1ha2luZyBhcHBsaWNhdGlvbiBwcm9maWxpbmcgYmFzZWQgb24gdGhlIHR5cGUg b2YgYWRkcmVzcyBoYXJkZXIuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij5BcHBsaWNhdGlvbiB1c2luZyBtdWx0aXBsZSB0eXBlIG9mIElQIGFkZHJlc3NlcyB0byBhdm9p ZCBiZWluZyBwcm9maWxlZCBpcyBsaWtlbHkgdG8gY3JlYXRlIHNvbWUgcGF0dGVybnMuIFNvIHRo YXQgcmVtYWlucyBhIGhhcmQgcHJvYmxlbSB0byBzb2x2ZSBieSB0aGUgYXBwbGljYXRpb24uPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlRoZSB1c2FnZSBvZiBhIGZpeGVkIElQIGFkZHJl c3MsIGVuYWJsZXMgdHJhY2tpbmcgdGhlIG1vYmlsZSBub2RlLCBvciBpdHMgYXBwbGljYXRpb24g b3ZlciB0aW1lLiBUaGlzIGlzIGEgc2ltaWxhciBwcm9ibGVtIGFzIHRoZSBvbmUgZW5jb3VudGVy ZWQgd2l0aCBQdWJsaWMgSVAgYWRkcmVzc2VzLiBUaGUgdXNhZ2Ugb2YgdGhlIEZpeGVkIElQIGFk ZHJlc3NlcyBzaG91bGQgYmUgbGltaXRlZC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ VG8gbGltaXQgdGhlIGVmZmVjdCBvZiBJUCB0cmFja2luZywgdGhlIGFwcGxpY2F0aW9uIG9yIHRo ZSBPUyBzaG91bGQgZW5zdXJlIHRoYXQgSVAgYWRkcmVzc2VzIHJlZ3VsYXJseSBjaGFuZ2UgdG8g bGltaXQgSVAgdHJhY2tpbmcgYnkgYSBwYXNzaXZlIG9ic2VydmVyLiZuYnNwOyBUaGUgYXBwbGlj YXRpb24gc2hvdWxkIHJlZ3VsYXJseSBzZXQgdGhlIE9uIERlbWFuZCBmbGFnLiBUaGUgYXBwbGlj YXRpb24gc2hvdWxkDQogYmUgYWJsZSB0byBlbnN1cmUgdGhhdCBzZXNzaW9uIGxhc3RpbmcgSVAg YWRkcmVzcyBhcmUgcmVndWxhcmx5IGNoYW5nZWQgYnkgc2V0dGluZyBhIGxpZmV0aW1lIGZvciBl eGFtcGxlIGhhbmRsZWQgYnkgdGhlIGFwcGxpY2F0aW9uLiBJbiBhZGRpdGlvbiwgdGhlIGFwcGxp Y2F0aW9uIHNob3VsZCBjb25zaWRlciB0aGUgdXNlIG9mIGdyYWNlZnVsIHJlcGxhY2VtZW50IElQ IGFkZHJlc3Nlcy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+U2ltaWxhcmx5LCB0aGUg T1MgbWF5IGFsc28gYXNzb2NpYXRlZCBJUCBhZGRyZXNzZXMgd2l0aCBhIGxpZmV0aW1lLiBVcG9u IHJlY2VpdmluZyBhIHJlcXVlc3QgZm9yIGEgZ2l2ZW4gdHlwZSBvZiBJUCBhZGRyZXNzLCBhZnRl ciBzb21lIHRpbWUsIHRoZSBPUyBzaG91bGQgcmVxdWVzdCBhIG5ldyBhZGRyZXNzIHRvIHRoZSBu ZXR3b3JrIGV2ZW4gaWYgaXQgYWxyZWFkeSBoYXMgb25lIElQIGFkZHJlc3MgYXZhaWxhYmxlDQog d2l0aCB0aGUgcmVxdWVzdGVkIHR5cGUuIFRoaXMgaW5jbHVkZXMgYW55IHR5cGUgb2YgSVAgYWRk cmVzcy4gQWRkcmVzc2VzIG9mIHR5cGUgZ3JhY2VmdWwgcmVwbGFjZW1lbnQgb3Igbm9uIHBlcnNp c3RlbnQgSVAgYWRkcmVzc2VzIHNob3VsZCBiZSByZWd1bGFybHkgcmVuZXdlZCBieSB0aGUgT1Mu PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlRoZSBsaWZldGltZSBvZiBhbiBJUCBhZGRy ZXNzIG1heSBiZSBleHByZXNzZWQgaW4gbnVtYmVyIG9mIHNlY29uZHMgb3IgaW4gdW1iZXIgb2Yg Ynl0ZXMgc2VudCB0aHJvdWdoIHRoaXMgSVAgYWRkcmVzcy48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZsdDsvbWdsdCZndDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+U2Vzc2lvbiBsYXN0aW5nIElQIGFkZHJlc3MgY291bGQgYmUgdXNlZCB0byBhdm9pZCB0 cmFja2luZyBhbmQgc2hvdWxkIGJlIHByZWZlcnJlZC4gSG93ZXZlciwgdGhlcmUgc2hvdWxkIGJl IGEgd2F5IHRvIHNwZWNpZnkgYmV0d2VlbiBvbmUgc2Vzc2lvbiBsYXN0aW5nIG9yIGlmIHRoZSBJ UCBhZGRyZXNzIGNhbiBsYXN0IG11bHRpcGxlIHNlc3Npb25zLjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mbHQ7L21nbHQmZ3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjgu Jm5ic3A7IElBTkEgQ29uc2lkZXJhdGlvbnM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jm5ic3A7Jm5ic3A7IFRoaXMgZG9jdW1lbnQgaGFzIG5vIElBTkEgY29uc2lkZXJhdGlvbnMuPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjkuJm5ic3A7IENvbnRyaWJ1dG9yczxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgVGhpcyBkb2N1bWVudCB3YXMgbWVy Z2VkIHdpdGggW0ktRC5zaWplb24tZG1tLXVzZS1jYXNlcy1hcGktc291cmNlXS48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyBXZSB3b3VsZCBsaWtl IHRvIGFja25vd2xlZGdlIHRoZSBjb250cmlidXRpb24gb2YgdGhlIGZvbGxvd2luZyBwZW9wbGU8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyB0byB0 aGF0IGRvY3VtZW50IGFzIHdlbGw6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNw OyZuYnNwOyBTZXJnaW8gRmlndWVpcmVkbzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jm5ic3A7Jm5ic3A7IEFsdHJhbiBSZXNlYXJjaCwgRnJhbmNlPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgRW1haWw6IDxhIGhyZWY9 Im1haWx0bzpzZXJnaW8uZmlndWVpcmVkb0BhbHRyYW4uY29tIj48c3BhbiBzdHlsZT0iY29sb3I6 d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+c2VyZ2lvLmZpZ3VlaXJlZG9AYWx0cmFu LmNvbTwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNw OyBZb3VuZ2hhbiBLaW08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZu YnNwOyZuYnNwOyBTb29uZ3NpbCBVbml2ZXJzaXR5LCBLb3JlYTxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IEVtYWlsOiA8YSBocmVmPSJtYWlsdG86 eW91bmdoYWtAc3N1LmFjLmtyIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRl Y29yYXRpb246bm9uZSI+eW91bmdoYWtAc3N1LmFjLmtyPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IEpvaG4gS2FpcHBhbGxpbWFsaWw8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyBIdWF3ZWksIFVT QTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IEVt YWlsOiA8YSBocmVmPSJtYWlsdG86am9obi5rYWlwcGFsbGltYWxpbEBodWF3ZWkuY29tIj4NCjxz cGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5qb2huLmth aXBwYWxsaW1hbGlsQGh1YXdlaS5jb208L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4xMC4mbmJzcDsgQWNrbm93bGVkZ2VtZW50czxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mbmJzcDsmbmJzcDsgV2Ugd291bGQgbGlrZSB0byB0aGFuayBXdS1jaGkgRmVuZywg QWxleGFuZHJ1IFBldHJlc2N1LCBKb3VuaTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jm5ic3A7Jm5ic3A7IEtvcmhvbmVuLCBTcmkgR3VuZGF2ZWxsaSwgRGF2ZSBEb2xz b24gYW5kIExvcmVuem8gQ29saXR0aSBmb3IgdGhlaXI8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyB2YWx1YWJsZSBjb21tZW50cyBhbmQgc3VnZ2Vz dGlvbnMgb24gdGhpcyB3b3JrLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4xMS4mbmJz cDsgUmVmZXJlbmNlczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5ZZWdpbiwgZXQgYWwu Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IEV4cGlyZXMgSmFudWFyeSAyNywgMjAxOSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBb UGFnZSAxNF08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+SW50ZXJuZXQtRHJhZnQmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgT24gRGVtYW5kIE1vYmlsaXR5Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IEp1bHkgMjAxODxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4xMS4xLiZuYnNwOyBOb3JtYXRpdmUgUmVmZXJlbmNlczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mbmJzcDsmbmJzcDsgW1JGQzIxMTldJm5ic3A7IEJyYWRuZXIsIFMuLCAmcXVvdDtL ZXkgd29yZHMgZm9yIHVzZSBpbiBSRkNzIHRvIEluZGljYXRlPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgUmVxdWlyZW1lbnQgTGV2 ZWxzJnF1b3Q7LCBCQ1AgMTQsIFJGQyAyMTE5LDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IERPSSAxMC4xNzQ4Ny9SRkMyMTE5LCBN YXJjaCAxOTk3LDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7ICZsdDs8YSBocmVmPSJodHRwczovL3d3dy5yZmMtZWRpdG9yLm9yZy9p bmZvL3JmYzIxMTkiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlv bjpub25lIj5odHRwczovL3d3dy5yZmMtZWRpdG9yLm9yZy9pbmZvL3JmYzIxMTk8L3NwYW4+PC9h PiZndDsuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyBbUkZDNTAx NF0mbmJzcDsgTm9yZG1hcmssIEUuLCBDaGFrcmFiYXJ0aSwgUy4sIGFuZCBKLiBMYWdhbmllciwg JnF1b3Q7SVB2NjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IFNvY2tldCBBUEkgZm9yIFNvdXJjZSBBZGRyZXNzIFNlbGVjdGlvbiZx dW90OywgUkZDIDUwMTQsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgRE9JIDEwLjE3NDg3L1JGQzUwMTQsIFNlcHRlbWJlciAyMDA3 LDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7ICZsdDs8YSBocmVmPSJodHRwczovL3d3dy5yZmMtZWRpdG9yLm9yZy9pbmZvL3JmYzUw MTQiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5o dHRwczovL3d3dy5yZmMtZWRpdG9yLm9yZy9pbmZvL3JmYzUwMTQ8L3NwYW4+PC9hPiZndDsuPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjExLjIuJm5ic3A7IEluZm9ybWF0aXZlIFJlZmVy ZW5jZXM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IFtJLUQuc2lq ZW9uLWRtbS11c2UtY2FzZXMtYXBpLXNvdXJjZV08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBKZW9uLCBTLiwgRmlndWVpcmVkbywg Uy4sIEtpbSwgWS4sIGFuZCBKLiBLYWlwcGFsbGltYWxpbCw8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDtVc2UgQ2FzZXMg YW5kIEFQSSBFeHRlbnNpb24gZm9yIFNvdXJjZSBJUCBBZGRyZXNzPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgU2VsZWN0aW9uJnF1 b3Q7LCBkcmFmdC1zaWplb24tZG1tLXVzZS1jYXNlcy1hcGktc291cmNlLTA3ICh3b3JrPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg aW4gcHJvZ3Jlc3MpLCBTZXB0ZW1iZXIgMjAxNy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jm5ic3A7Jm5ic3A7IFtSRkMzMjYxXSZuYnNwOyBSb3NlbmJlcmcsIEouLCBTY2h1bHpyaW5u ZSwgSC4sIENhbWFyaWxsbywgRy4sIEpvaG5zdG9uLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEEuLCBQZXRlcnNvbiwgSi4sIFNw YXJrcywgUi4sIEhhbmRsZXksIE0uLCBhbmQgRS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBTY2hvb2xlciwgJnF1b3Q7U0lQOiBT ZXNzaW9uIEluaXRpYXRpb24gUHJvdG9jb2wmcXVvdDssIFJGQyAzMjYxLDxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IERPSSAxMC4x NzQ4Ny9SRkMzMjYxLCBKdW5lIDIwMDIsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0OzxhIGhyZWY9Imh0dHBzOi8vd3d3LnJm Yy1lZGl0b3Iub3JnL2luZm8vcmZjMzI2MSI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7 dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2luZm8vcmZj MzI2MTwvc3Bhbj48L2E+Jmd0Oy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7 Jm5ic3A7IFtSRkM1MjEzXSZuYnNwOyBHdW5kYXZlbGxpLCBTLiwgRWQuLCBMZXVuZywgSy4sIERl dmFyYXBhbGxpLCBWLiw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBDaG93ZGh1cnksIEsuLCBhbmQgQi4gUGF0aWwsICZxdW90O1By b3h5IE1vYmlsZSBJUHY2JnF1b3Q7LDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFJGQyA1MjEzLCBET0kgMTAuMTc0ODcvUkZDNTIx MywgQXVndXN0IDIwMDgsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0OzxhIGhyZWY9Imh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iu b3JnL2luZm8vcmZjNTIxMyI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNv cmF0aW9uOm5vbmUiPmh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2luZm8vcmZjNTIxMzwvc3Bh bj48L2E+Jmd0Oy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IFtS RkM1NTYzXSZuYnNwOyBMZXVuZywgSy4sIERvbW1ldHksIEcuLCBZZWdhbmksIFAuLCBhbmQgSy4g Q2hvd2RodXJ5LDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZxdW90O1dpTUFYIEZvcnVtIC8gM0dQUDIgUHJveHkgTW9iaWxlIElQ djQmcXVvdDssIFJGQyA1NTYzLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IERPSSAxMC4xNzQ4Ny9SRkM1NTYzLCBGZWJydWFyeSAy MDEwLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICZsdDs8YSBocmVmPSJodHRwczovL3d3dy5yZmMtZWRpdG9yLm9yZy9pbmZvL3Jm YzU1NjMiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25l Ij5odHRwczovL3d3dy5yZmMtZWRpdG9yLm9yZy9pbmZvL3JmYzU1NjM8L3NwYW4+PC9hPiZndDsu PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyBbUkZDNTk0NF0mbmJz cDsgUGVya2lucywgQy4sIEVkLiwgJnF1b3Q7SVAgTW9iaWxpdHkgU3VwcG9ydCBmb3IgSVB2NCwg UmV2aXNlZCZxdW90Oyw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBSRkMgNTk0NCwgRE9JIDEwLjE3NDg3L1JGQzU5NDQsIE5vdmVt YmVyIDIwMTAsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgJmx0OzxhIGhyZWY9Imh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2lu Zm8vcmZjNTk0NCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9u Om5vbmUiPmh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2luZm8vcmZjNTk0NDwvc3Bhbj48L2E+ Jmd0Oy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IFtSRkM2Mjc1 XSZuYnNwOyBQZXJraW5zLCBDLiwgRWQuLCBKb2huc29uLCBELiwgYW5kIEouIEFya2tvLCAmcXVv dDtNb2JpbGl0eTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IFN1cHBvcnQgaW4gSVB2NiZxdW90OywgUkZDIDYyNzUsIERPSSAxMC4x NzQ4Ny9SRkM2Mjc1LCBKdWx5PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMjAxMSwgJmx0OzxhIGhyZWY9Imh0dHBzOi8vd3d3LnJm Yy1lZGl0b3Iub3JnL2luZm8vcmZjNjI3NSI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7 dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2luZm8vcmZj NjI3NTwvc3Bhbj48L2E+Jmd0Oy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7 Jm5ic3A7IFtSRkM2ODI0XSZuYnNwOyBGb3JkLCBBLiwgUmFpY2l1LCBDLiwgSGFuZGxleSwgTS4s IGFuZCBPLiBCb25hdmVudHVyZSw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDtUQ1AgRXh0ZW5zaW9ucyBmb3IgTXVsdGlw YXRoIE9wZXJhdGlvbiB3aXRoIE11bHRpcGxlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQWRkcmVzc2VzJnF1b3Q7LCBSRkMgNjgy NCwgRE9JIDEwLjE3NDg3L1JGQzY4MjQsIEphbnVhcnkgMjAxMyw8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7PGEgaHJlZj0i aHR0cHM6Ly93d3cucmZjLWVkaXRvci5vcmcvaW5mby9yZmM2ODI0Ij48c3BhbiBzdHlsZT0iY29s b3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+aHR0cHM6Ly93d3cucmZjLWVkaXRv ci5vcmcvaW5mby9yZmM2ODI0PC9zcGFuPjwvYT4mZ3Q7LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij5ZZWdpbiwgZXQgYWwuJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEV4cGlyZXMgSmFudWFyeSAyNywgMjAxOSZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBbUGFnZSAxNV08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+SW50ZXJuZXQtRHJhZnQmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgT24gRGVtYW5kIE1vYmlsaXR5Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEp1bHkgMjAxODxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgW1JGQzczMzNdJm5ic3A7IENoYW4s IEguLCBFZC4sIExpdSwgRC4sIFNlaXRlLCBQLiwgWW9rb3RhLCBILiwgYW5kIEouPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgS29y aG9uZW4sICZxdW90O1JlcXVpcmVtZW50cyBmb3IgRGlzdHJpYnV0ZWQgTW9iaWxpdHk8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBN YW5hZ2VtZW50JnF1b3Q7LCBSRkMgNzMzMywgRE9JIDEwLjE3NDg3L1JGQzczMzMsIEF1Z3VzdCAy MDE0LDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICZsdDs8YSBocmVmPSJodHRwczovL3d3dy5yZmMtZWRpdG9yLm9yZy9pbmZvL3Jm YzczMzMiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25l Ij5odHRwczovL3d3dy5yZmMtZWRpdG9yLm9yZy9pbmZvL3JmYzczMzM8L3NwYW4+PC9hPiZndDsu PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkF1dGhvcnMnIEFkZHJlc3NlczxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgQWxwZXIgWWVnaW48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyBBY3RpbGl0eTxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IElzdGFuYnVs PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgVHVy a2V5PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyBFbWFpbDogPGEg aHJlZj0ibWFpbHRvOmFscGVyLnllZ2luQGFjdGlsaXR5LmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9y OndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmFscGVyLnllZ2luQGFjdGlsaXR5LmNv bTwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyBE YW5ueSBNb3NlczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7 Jm5ic3A7IEludGVsIENvcnBvcmF0aW9uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mbmJzcDsmbmJzcDsgUGV0YWggVGlrdmE8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyBJc3JhZWw8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jm5ic3A7Jm5ic3A7IEVtYWlsOiA8YSBocmVmPSJtYWlsdG86ZGFubnkubW9zZXNA aW50ZWwuY29tIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246 bm9uZSI+ZGFubnkubW9zZXNAaW50ZWwuY29tPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IEtpc3VrIEt3ZW9uPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgU2Ftc3VuZzxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IFN1d29uPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgU291dGggS29yZWE8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IEVtYWlsOiA8YSBocmVmPSJtYWls dG86a2lzdWsua3dlb25Ac2Ftc3VuZy5jb20iPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0 O3RleHQtZGVjb3JhdGlvbjpub25lIj5raXN1ay5rd2VvbkBzYW1zdW5nLmNvbTwvc3Bhbj48L2E+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyBKaW5zdW5nIExlZTxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IFNhbXN1 bmc8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyBT dXdvbjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7 IFNvdXRoIEtvcmVhPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyBF bWFpbDogPGEgaHJlZj0ibWFpbHRvOmpzODEubGVlQHNhbXN1bmcuY29tIj48c3BhbiBzdHlsZT0i Y29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+anM4MS5sZWVAc2Ftc3VuZy5j b208L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsg SnVuZ3NoaW4gUGFyazxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5i c3A7Jm5ic3A7IFNhbXN1bmc8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZuYnNwOyZuYnNwOyBTdXdvbjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jm5ic3A7Jm5ic3A7IFNvdXRoIEtvcmVhPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZuYnNwOyZuYnNwOyBFbWFpbDogPGEgaHJlZj0ibWFpbHRvOnNoaW4wMi5wYXJrQHNhbXN1bmcu Y29tIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+ c2hpbjAyLnBhcmtAc2Ftc3VuZy5jb208L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij5ZZWdpbiwgZXQgYWwuJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEV4cGlyZXMgSmFudWFyeSAyNywgMjAxOSZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBbUGFnZSAxNl08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+SW50ZXJuZXQtRHJhZnQmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgT24gRGVtYW5kIE1vYmlsaXR5Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEp1bHkgMjAxODxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgU2VpbCBKZW9uPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgU3VuZ2t5dW5rd2FuIFVu aXZlcnNpdHk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZu YnNwOyBTdXdvbjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7 Jm5ic3A7IFNvdXRoIEtvcmVhPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZu YnNwOyBFbWFpbDogPGEgaHJlZj0ibWFpbHRvOnNlaWxqZW9uQHNra3UuZWR1Ij48c3BhbiBzdHls ZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+c2VpbGplb25Ac2trdS5l ZHU8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5ZZWdpbiwgZXQgYWwu ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwO0V4cGlyZXMgSmFudWFyeSAyNywgMjAxOSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBb UGFnZSAxN108bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+ZG1tIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+PGEgaHJlZj0ibWFpbHRvOmRtbUBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRv d3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmRtbUBpZXRmLm9yZzwvc3Bhbj48L2E+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48YSBocmVmPSJodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RtbSI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3Rl eHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vZG1tPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjxwPi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4N CkEgbWVtYmVyIG9mIHRoZSBJbnRlbCBDb3Jwb3JhdGlvbiBncm91cCBvZiBjb21wYW5pZXM8bzpw PjwvbzpwPjwvcD4NCjxwPlRoaXMgZS1tYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgbWF5IGNvbnRh aW4gY29uZmlkZW50aWFsIG1hdGVyaWFsIGZvcjxicj4NCnRoZSBzb2xlIHVzZSBvZiB0aGUgaW50 ZW5kZWQgcmVjaXBpZW50KHMpLiBBbnkgcmV2aWV3IG9yIGRpc3RyaWJ1dGlvbjxicj4NCmJ5IG90 aGVycyBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQ8 YnI+DQpyZWNpcGllbnQsIHBsZWFzZSBjb250YWN0IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSBhbGwg Y29waWVzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_BN8PR15MB3090DA22E91DA6E0936493EDE3600BN8PR15MB3090namp_-- From nobody Fri Feb 15 22:58:07 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B1F8129C6A; Fri, 15 Feb 2019 22:57:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=packetizer.com 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 eNSdCMsYL3Ey; Fri, 15 Feb 2019 22:57:57 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [IPv6:2600:1f18:24d6:2e01:e842:9b2b:72a2:d2c6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AD7B1277D2; Fri, 15 Feb 2019 22:57:57 -0800 (PST) Received: from authuser (localhost [127.0.0.1]) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1550300273; bh=/Sr6mslsGSy0tqZXigj9I9KE/GR7+YUa2gnRygxaeQc=; h=From:To:Subject:Cc:Date:In-Reply-To:References:Reply-To; b=S3jK+aoSyEFSDnMBdi4EgNmu9XSi9d0IIPOUgL541F9HSdXK3oC1qG/G2hGSFBuNS FqM2pQolbaUW0RSlhVGwmlJvT62z7xkkkFlErTw8tayn3JX5A1EV+Q44GtRIEAp7oT /IAib5RHBgm3PJa6euYbTM6lNe3kJwsZBwdXcEOo= From: "Paul E. Jones" To: "Vincent Roca" , secdir@ietf.org Cc: iesg@ietf.org, draft-ietf-perc-private-media-framework.all@ietf.org Date: Sat, 16 Feb 2019 06:57:49 +0000 Message-Id: In-Reply-To: <155014077570.26619.9407568904769535504@ietfa.amsl.com> References: <155014077570.26619.9407568904769535504@ietfa.amsl.com> Reply-To: "Paul E. Jones" User-Agent: eM_Client/7.2.34208.0 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-perc-private-media-framework-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Feb 2019 06:57:59 -0000 Vincent, Thanks for the review. Please see comments inline. >** Section 8.1 >Why is it said that: > "A successful attacker might be able to get the Media Distributor = to > forward such packets." >Is it really possible? That would be a big design issue! In fact the follo= wing >sentence suggest the opposite and I think this is essentially an erroneous >manner to present things. Please see comments on Section 8.2.4 on saying t= hings >the other way round. Indeed, this kind of attack would not be possible since the Media=20 Distributor must perform HBH authentication. I'll re-word this. >The same comment applies to the remaining two paragraphs. I suggest the au= thors >explain that the proposal prevents an attacker to claim being a regular Me= dia >Distributor and therefore to fool endpoints because ...". The "false Media Distributor" example could happen. For example, if a=20 hacker had access to the network where the Media Distributor is located=20 and claims the Media Distributor's address while the conference is=20 operating, the endpoints might not know. However, the worst result of=20 such an attack is similar to just unplugging the box: packets just don't=20 flow. The fake box could attempt to forward packets it receives, but=20 they would fail to authenticate at the receiving endpoints and be=20 discarded. However, this false device could never gain access to the=20 media and would not be given HBH keys since it could not authenticate=20 with the Key Distributor. >** Section 8.2.2. >Is the following sentence correct: > The mitigation for a replay attack is to prevent old packets beyond a > small-to-modest jitter and network re-ordering sized window to be > rejected. >Is "prevent [...] to be rejected" correct? I'd say "... to be delivered" >instead. "prevent... rejected" is definitely an error. However, we cannot stop=20 delivery. If replayed packets are received by either the Media=20 Distributor or the endpoint, they should be discarded. So, perhaps this=20 is better: "The mitigation for a replay attack is to discard old packets beyond a small-to-modest jitter and network re-ordering sized window." >Another comment. Replay protection seems to be based on timing considerati= ons >rather than on the use of unique sequence numbers that must not be replaye= d >(except if a wrapping to zero occurs of course). Is that correct? Addition= ally, >is this mechanism carefully described in this document? Since it is explai= ned >that E2E replay protection MUST be provided, it's essential to be very cle= ar on >how to perform this. Failing to do so is a big issue. The mechanism underlying this is SRTP, which defines in 3.3.2/RFC3711 an=20 "SRTP window size". We felt it was best to not introduce conflicting=20 language. Perhaps we should just change the paragraph more substantially=20 and refer to SRTP. Would you prefer this as the second paragraph? "The mitigation for a replay attack is to implement replay protection as described in Section 3.3.2 of [RFC3711]. End-to-end replay protection **MUST** be provided for the whole duration of the conference." >** Section 8.2.3 >It is said that "a Media Distributor can select to not deliver a particula= r >stream for a while." That's perfectly true, yet is this a "Delayed playout >attack"? I'd rather call it a Media Distributor censorship attack, or some= thing >along this line. The main idea behind the attack is not to delay a stream= but >to censor a source. This attack is not to censor, but to delay. For example, at time "T" Bob=20 might say "I agree with your proposal". However, the "evil" Media=20 Distributor could opt to not forward those packets and hold them. At=20 some time "T+delta", the Media Distributor then forwards them. The=20 receiving endpoint might not know that the packets were an hour old, so=20 the receiver Alice thinks Bob is agreeing with a proposal that Bob=20 actually doesn't agree with. However, a censorship attack is also possible. But I think we covered=20 that in the Denial of Service section. The Media Distributor could=20 always elect to not forward, which is in effect censoring the=20 conversation. > >In the second paragraph I don't understand why it is said that: > "the receiver believing that it is what was said just now, and on= ly > delayed due to transport delay." >Any RTP packet contains a timestamp (whose integrity is protected end-to-e= nd if >I understand correctly), and this timestamp is used by the receiver to ide= ntify >timing issues. The fact a packet is delayed (significantly) by a Media >Distributor cannot be misinterpreted by a receiver as a "what was said jus= t >now". The receiver immediately identifies this delay. While that might be true, I'd guess most implementations would not=20 maintain this timing information for media held for a substantial period=20 of time. And media held for a short duration really might be considered=20 late only due to network delays. That actually does happen when network=20 congestion builds. So, short delays might easily be attributed to=20 network delays and long delays likely result in a "reset" of the flow at=20 the endpoint. I think all we can do here is provide a warning about=20 this, but I'm happy to make adjustments if you have specific words you=20 think would make this clearer. >I now understand the title ("delayed playout") but I really suspect this i= s a >mistake as (too much) delayed packets will not be played at all. I bet they would :) Seriously, I have seen far stranger things. And=20 implementers might consider doing that as a "resilient" implementation. >** Section 8.2.4: >I don't like the way this section is written. It first explains what a Med= ia >Distributor could do if it could alter a certain header field (in this cas= e >SSRC), it details the consequences, to finally explain that this is not >possible. This Security Discussion section is essentially meant to discuss >remaining security issues or highlight specific aspects, not what could ha= ppen >with a different, non secure, design. This text could also be written the= other >way round: "By including the SSR field into the integrity check, PERC prev= ents >splicing attacks where...". I assume you (and Ben) are looking to change that last sentence from=20 "not allowing" to "by including"? I'll change it that way, but if that=20 wasn't your meaning, please let me know. > >** Missing in 8.2 >The RTCP flows are not encrypted end-to-end (unlike data flows) but only >hop-by-hop. Consequently, a malicious Media Distributors may corrupt an RT= CP >packet content (e.g., reception statistics in RR) or forge malicious RTCP >packets which may trigger various effects at a sender. There are other typ= es of >RTCP packets that may be attacked as well with various consequences. None= of >this is explained in section 8.2. "Media Distributor Attacks". This is true, though it wasn't a concern since the objective of PERC was=20 to secure the media E2E. Nonetheless, you're correct. How about this as=20 a new section called "RTCP attacks" under the Media Distributor attacks=20 section? PERC does not provide end-to-end protection of RTCP messages. This=20 allows a malicious Media Distributor to impact any message that might be=20 transmitted via RTCP, including media statistics, picture requests, os loss=20 indication. It is also possible for the Media Distributor to forge requests, such as requests to the endpoint to send a new picture. Such requests can=20 consume significant bandwidth and impair conference performance. > >** General comments about 8.1 and 8.2 >Insider attacks are a powerful form of attacker model with severe conseque= nces. >This is not a big surprise. I'd be more interesting in a detailed 8.1 sect= ion, >more likely to happen (weaker attacker model). I'm not sure exactly what you're looking for. You want a new section=20 (e.g., 8.3) that details insider attacks or something related to each of=20 the existing 8.1/8.2 sections? Insider attacks could be disastrous,=20 definitely. They could range from anything from turning off the power to=20 stealing the KEKs stored in the Key Distributor. The latter is "scary"=20 in that, if a rogue individual were to steal the KEKs, he or she could=20 decrypt media off-line and at a later date. And, if the Key Distributor=20 stored the keys for a long time (e.g., so as to enable conference=20 recording and playback -- something not really considered on PERC, but=20 certainly implementable), then they could first capture the media flows=20 and then decrypt them a year later once they have access to the KEKs.=20 The two attacks do not have to carried out concurrently and there would=20 be no defense against theft of KEKs. We could scare people with some words about keeping the Key Distributor=20 secure, but I'm not sure what we need to convey. >Suggestion: > >** 8.2. Instead of: > "The Media Distributor can attack the session in a number of poss= ible > ways." >I suggest: > "A malicious or compromised Media Distributor can ..." Changed as suggested. >Typos: > >** Intro: s/virutalized/virtualized/ Wow. I think that typo has been for a very long time. >** Section 2: s/and is never allowed have access/and is never allowed to h= ave >access/ Fixed. >** 8. Security Considerations: > s/could incorrectly assuming/could incorrectly assume/ Fixed. > s/This attack is be mitigated/This attack is mitigated/ Fixed. > s/when an already received packets/when an already received packe= t/ Fixed. > >Other comments: > >** Section 6, intro: (it's a detail, but...) >I don't think that the use of "and so forth" is adequate in a specificatio= n >that aims to be exhaustive. The list of items addressed in section 6 is >finished. Agreed. I'm just cut the sentence short: "This section describes the various keys employed by PERC." The sub-section titles are sufficient, I think. Thanks! Paul From nobody Sat Feb 16 12:28:40 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59BE2130EBA; Sat, 16 Feb 2019 12:28:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mit.edu 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 fLByxz6dWhPJ; Sat, 16 Feb 2019 12:28:23 -0800 (PST) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-eopbgr810097.outbound.protection.outlook.com [40.107.81.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79AE212F1A2; Sat, 16 Feb 2019 12:28:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=I+EPbpnhttHUaGa0RAwEfEOuyyrPZyO9OVcIEK2oulc=; b=E9mRYZqM4mwgaaKG/bwe90jIursUIBKF3vYTYGwWW4TFPd6Yfw9E9D1hu6ShBNUO9v8Gpakxmui4ModwZ9U/pIBFh361ovFqhkix6DHc3eiQAZI+xrYphQ2sQNyYOJGtfAIq1LVmVzbTlep7WuC0E2e8mqIYgahbTiywtZTuaPc= Received: from DM5PR0101CA0001.prod.exchangelabs.com (2603:10b6:4:28::14) by CY4PR01MB3287.prod.exchangelabs.com (2603:10b6:903:e9::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1622.16; Sat, 16 Feb 2019 20:28:21 +0000 Received: from BY2NAM03FT039.eop-NAM03.prod.protection.outlook.com (2a01:111:f400:7e4a::209) by DM5PR0101CA0001.outlook.office365.com (2603:10b6:4:28::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1622.16 via Frontend Transport; Sat, 16 Feb 2019 20:28:21 +0000 Authentication-Results: spf=pass (sender IP is 18.9.28.11) smtp.mailfrom=mit.edu; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=mit.edu; Received-SPF: Pass (protection.outlook.com: domain of mit.edu designates 18.9.28.11 as permitted sender) receiver=protection.outlook.com; client-ip=18.9.28.11; helo=outgoing.mit.edu; Received: from outgoing.mit.edu (18.9.28.11) by BY2NAM03FT039.mail.protection.outlook.com (10.152.85.205) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1580.10 via Frontend Transport; Sat, 16 Feb 2019 20:28:20 +0000 Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x1GKSGPW032739 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 16 Feb 2019 15:28:18 -0500 Date: Sat, 16 Feb 2019 14:28:16 -0600 From: Benjamin Kaduk To: Mach Chen CC: Linda Dunbar , "secdir@ietf.org" , "mpls@ietf.org" , "draft-ietf-mpls-lsp-ping-lag-multipath.all@ietf.org" , "ietf@ietf.org" Message-ID: <20190216202815.GD82217@kduck.mit.edu> References: <154455986336.13151.8483284555885294015@ietfa.amsl.com> <20190126211729.GJ49072@kduck.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:18.9.28.11; IPV:CAL; SCL:-1; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(376002)(39860400002)(136003)(346002)(396003)(2980300002)(13464003)(199004)(51914003)(189003)(356004)(88552002)(8676002)(106466001)(246002)(26826003)(478600001)(8936002)(2906002)(54906003)(53416004)(104016004)(106002)(36906005)(58126008)(16586007)(75432002)(86362001)(786003)(46406003)(50466002)(316002)(97756001)(33656002)(6916009)(26005)(53546011)(14444005)(1076003)(47776003)(5660300002)(76176011)(7696005)(55016002)(305945005)(23726003)(4326008)(446003)(426003)(93886005)(336012)(126002)(486006)(476003)(6246003)(956004)(229853002)(11346002)(186003)(18370500001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR01MB3287; H:outgoing.mit.edu; FPR:; SPF:Pass; LANG:en; PTR:outgoing-auth-1.mit.edu; A:1; MX:1; X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: b1c14253-d078-4302-a92f-08d6944d4aeb X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605104)(4608103)(4709054)(2017052603328)(7153060); SRVR:CY4PR01MB3287; X-MS-TrafficTypeDiagnostic: CY4PR01MB3287: X-Microsoft-Exchange-Diagnostics: 1; CY4PR01MB3287; 20:+2VnjcvkH67Tx0Sm+biV/6KradzTFjE7zggikFI/N1ODnIMiJx3ueH4EUf6FtcqgkIp/JBLpXzoU4foGJELxG1Qkoclwx//0AgRXbeElDLBaQv5ehNQJY5/6CddJvsSIgAUpgrQAylJUf5mqrXrY0twK6I5lfqh1TBr5Y+V6nvsv6370aELC+Y++ekOS2Zpw8jjqGpbmms9O3LVau5ix+dG1Rh/BSdd5CbbBoe5rmApLWUmQxLnOugRhrVepDgGC95RoHRpZA5tUDnQKVGSNmPEJBgC7irBodR9i2Wn1QFcmroHDMdRmU5Iss/RT8QVBZ6GkkMCDsE/H/E/Z/udOBdAAx6VD/ElgNjW819IH21x+3VAd/C2olUqtDnBQBci/Vi5li0Loe7X77uMmAQEIpm5j5uqpqVcaG5r8OX7gVdPkbhh9hMBHv4IlwxiMpjE8RATomMOmbYpiLtJAl8D8ZSIhtUvxioPpY9rCoOMzWfE9977TOpNQgS+gv+hw87VgmtUaiedh/tJabBS7IwazBFX8zwWLP+OVH4lqY//XzT4Sd+XTc+ZcU2EbAoAB4QMvQhkkBSdGslXRgnUnCvt/xl9W4HkVAIlZZSeCWl7buoU= X-Microsoft-Antispam-PRVS: X-Forefront-PRVS: 0950706AC1 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY4PR01MB3287; 23:QnQzhMrBSbRtj96yz7pvan1g9x2PFxZtv17kFUsYD?= =?us-ascii?Q?02fUeLa4P1cWL88Eqdd0lM9+P7JfoP2Cowvw7sWtsw9xTWGNc/Yxm+3uOQQJ?= =?us-ascii?Q?gWGdYx++f+TnMDnB2vbmzLl7720Scmv6wfTWAm9fynRmYvBxN5GHJJJUozyV?= =?us-ascii?Q?jgeffd7qtjzgD4Lo/Jb8Cg/9KhqI2wm9Gw/ts65kIUTZj+yhQGsTL4eJz5Dw?= =?us-ascii?Q?71mPivqaTXDbUGNk1GmzOfnjcF9SrvV6hPDfu9LpTm/WLE8WERjD+LMFprEF?= =?us-ascii?Q?G7shiDHn6XWMIe/ktFpqZ9BSl9c7GYfAXRRviN6q5uuAyh4sxy9kqf9FYZ7w?= =?us-ascii?Q?3JPb0k/GdTr0sMfLjSexUzgSwNwCWxgA5s/ZPV0pybL8sIekMvDGOwmCFKPn?= =?us-ascii?Q?gUkrYTaFMcWBP+q6/4qA30kjiN8xVBWo9xb/mklA3+oP0hr/iCnU21qYERXB?= =?us-ascii?Q?xarawwAwJZuKqHU1p/9NAKr+RNLu1kRMbO4VTyTJKNegEsRqeEosrNuMhlMy?= =?us-ascii?Q?WPhMJ5eZ1gTvdgfNRh36sirPCOahUedKJp+1xUvFE7zrpz+kbvpQp+jF8SMq?= =?us-ascii?Q?KDrbLr4JyxXRLhu1jvKPxfJO5g0pQP84d48kRpvonzKZA010JlBLQj+qCpMd?= =?us-ascii?Q?qAwTXudV0rxXCjmVfTdjmRVVMRGBG05VW2yv0iEDjweTjYJASBU71PYTD6la?= =?us-ascii?Q?mUaDKkGNW8xtjR2kF8SOCUKtN6FIEbUm+/M+lpezg7sUcG/CShkIswdEokk7?= =?us-ascii?Q?q5f6y5K0Lqbu1CG/jFuMn3J/tEcrza+HuePqdMj3mtn8VNU3gWavB/FLdUlh?= =?us-ascii?Q?YrdrNFTOmJGE/Gz5elH7JoDjxlkdH5dAlVv4shAdu484ZMBqBPqMGdMH1xVC?= =?us-ascii?Q?WenQwEQ8wHWN6tOCx3JapEgEz72fNQistCmjKI62Ipm+LjZWpfXocoGU89gm?= =?us-ascii?Q?DoByMALwZ5nwA91PesrKpvbmlKZQ4gWl3JtrgmcIv0xtZt0TZv5jUnz5BfrB?= =?us-ascii?Q?OqVOglrBf5p+LsPPEU38pqcfTu4R2et48A6coY1S/Yjlha7EE4lIGL6tWOQT?= =?us-ascii?Q?u9vKEU4gVxDjh4H4O1XuYvjNyCo86DcnHRMuoG4JixdPm9w5O9LWbDPa2OR1?= =?us-ascii?Q?1voaMfG2wfUkjXOlEx+BGw9Y4daI+5Q9jx1amIIOTaLnzChDEsu3OjFmTcXU?= =?us-ascii?Q?jdhtKdwlnFXTcFkN3txoFaAu5HmdjLuVzh/XHtrVDk1aOfiU5i1FRV68SjZw?= =?us-ascii?Q?OodiNHX7Sp0oK4XKHLdWOYNZvW8cxePYdYAoOMEEpoI/DfXkTOFKPA8jhdp8?= =?us-ascii?Q?BPrjTqoUtyFcRlbbMi/d6I=3D?= X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Message-Info: TFfZj69soQ3eX0ccf8qMO2ZGHhbdzvYC5gQsJFOd45icJK6883Rj5SveiEMSwVz8aSvuNXsZNnWXi9Pgc2P16jLNG0wBHJlOTJWTBpucKpxJfrU38b3JaNxrERHpwJfivifjvRt5/7szg6UoxFlp37y1NwCr80Kk+ydSbJdUWcU1k5khA1nR4hMzrOOSs6i0a87Y/WSNkLNEURF0ljif1QM8/WmDq0sWDT7y9/l5P4r2gnL68dseGZVSBzrCF4VLuMqwdoEoLIaw1djtuk49rRWGcTFL3pimVSWsNsQ+1iu4tiP4RwAzkgk0Vxs+s6f0tglSXWiFV8toBW/PJJw3Jn2Jbdk3LMnZivilPUNLCBo2RW3tBsrNty6w4JtaQjVOdVSXwtZEoMBfucpyZhRqnMjFhNH1dYlOtWLf3UJyAgc= X-OriginatorOrg: mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Feb 2019 20:28:20.5701 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: b1c14253-d078-4302-a92f-08d6944d4aeb X-MS-Exchange-CrossTenant-Id: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=64afd9ba-0ecf-4acf-bc36-935f6235ba8b; Ip=[18.9.28.11]; Helo=[outgoing.mit.edu] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR01MB3287 Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-mpls-lsp-ping-lag-multipath-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Feb 2019 20:28:27 -0000 Hi Mach, My apologies as well for the delay. On Thu, Feb 14, 2019 at 03:02:07AM +0000, Mach Chen wrote: > Hi Benjamin, > > Sorry for the delayed response! > > Please see my response inline... > > > -----Original Message----- > > From: Benjamin Kaduk [mailto:kaduk@mit.edu] > > Sent: Sunday, January 27, 2019 5:17 AM > > To: Mach Chen > > Cc: Linda Dunbar ; secdir@ietf.org; > > mpls@ietf.org; draft-ietf-mpls-lsp-ping-lag-multipath.all@ietf.org; > > ietf@ietf.org > > Subject: Re: [secdir] Secdir last call review of draft-ietf-mpls-lsp-ping-lag- > > multipath-05 > > > > On Fri, Dec 14, 2018 at 02:11:21AM +0000, Mach Chen wrote: > > > Hi Linda, > > > > > > Thanks for the review! > > > > > > Some responses inline... > > > > > > > -----Original Message----- > > > > From: ietf [mailto:ietf-bounces@ietf.org] On Behalf Of Linda Dunbar > > > > Sent: Wednesday, December 12, 2018 4:24 AM > > > > To: secdir@ietf.org > > > > Cc: mpls@ietf.org; > > > > draft-ietf-mpls-lsp-ping-lag-multipath.all@ietf.org; > > > > ietf@ietf.org > > > > Subject: Secdir last call review of > > > > draft-ietf-mpls-lsp-ping-lag-multipath-05 > > > > > > > > Reviewer: Linda Dunbar > > > > Review result: Ready > > > > > > > > I have reviewed this document as part of the security directorate's > > > > ongoing effort to review all IETF documents being processed by the > > > > IESG. These comments were written primarily for the benefit of the > > > > security area directors. Document editors and WG chairs should > > > > treat these comments just like any other last call comments. > > > > > > > > The summary of the review is Ready with comment > > > > > > > > The described mechanism for LSP Multipath Ping is very clear. The > > > > Security Consideration re-uses the description of RFC8029, which is > > > > very comprehensive. > > > > It would be better if the draft describes how to prevent > > > > intermediate LSRs in between the Initiating LSR and Responding LSR > > > > from mis-using the detailed link information (e.g. forwarding to > > somewhere else). > > > > > > The Echo Request and Reply messages are directly exchanged between the > > Initiating LSR and the Responding LSR, those intermediate LSRs just forward > > the messages as normal packets, they will not see the detailed link > > information unless if they inspect and do DPI on every packet forwarded by > > them. > > > > > > The detailed link information is supplied to the Initiating LSR for using, the > > intermediate LSRs will not try to use it even if they received the information, > > because there is no corresponding Echo Request to the received Echo Reply. > > > > The intermediate LSRs still will have access to the plaintext information, even > > if in normal operation they do not need to act upon that information. > > Generally in this sort of situation we will either explicitly state that the > > intermediate nodes must be trusted to not abuse the information in > > question, or provide some mechanism for end-to-end confidentiality > > protection. > > "Intermediate nodes must be trusted to not abuse the information" is normally assumed. For the intermediate nodes, there is no different between the Echo Reply messages and any other data traffic, control messages. They just forward the Echo Reply messages as normal packets. I am not sure it needs to explicitly state this. Do you suggest to add such a statement in the security consideration section? The concern is not about the normal operation, but rather about abnormal operation, e.g., if an intermediate node gets compromised by an attacker. We need to document the new abilities an attacker gets, when comparing the original case of "an attacker compromises an intermediate node that is using MPLS without this mechanism" to the new case of "an attacker compromises an intermediate node that is using MPLS with this mechanism". So, while I do suggest adding a statement to the security considerations section, the statement I want does not relate to the normal operation case (when intermediate nodes ignore the contents of the message). > > > > Also (noting that I only skimmed the document so this may not make sense), > > the security considerations seem to suggest using an IP ACL for determining > > which messages are trusted; IP ACLs are generally not recommended in favor > > of cryptographic mechanisms at this point. > > IP ACLs was introduced in RFC 8029 and is reused in this document, it's I did not find a clear and explicit declaration in RFC 8029 of the concept of an IP ACL; I assume you are referring to: To protect against unauthorized sources using MPLS echo request messages to obtain network information, it is RECOMMENDED that implementations provide a means of checking the source addresses of MPLS echo request messages against an access list before accepting the message. I do not think anyone is going to say "do not filter based on IP source address", but there would be general skepticism about relying upon it as a sole security mechanism. > just one of the security mechanisms. This document is an extension to (Could you remind me of the other mechanisms? I don't think I have a good handle on them.) > RFC 8029, as stated in this document, all security considerations defined > in RFC 8029 apply to this document. Do you have any specific suggestion > to the current security consideration? I am mostly just lamenting the state of affairs; this is a sufficiently incremental change that it is inappropriate to require dramatic changes in the security mechanisms. -Ben From nobody Sun Feb 17 15:57:54 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B01F2128D52; Sun, 17 Feb 2019 15:57:46 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Paul Wouters To: Cc: mpls@ietf.org, draft-ietf-mpls-sfc-encapsulation.all@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.91.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155044786665.4047.16182077722084116649@ietfa.amsl.com> Date: Sun, 17 Feb 2019 15:57:46 -0800 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-mpls-sfc-encapsulation-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Feb 2019 23:57:47 -0000 Reviewer: Paul Wouters Review result: Ready I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The summary of the review is Ready While I'm not familiar with the Service Function Chaining (SFC) architecture and the Network Service Header (NSH), the Security Considerations in this document seem to be correct in pointing out that: This document simply defines one additional transport encapsulation. The NSH was specially constructed to be agnostic to its transport encapsulation. As as result, in general this additional encapsulation is no more or less secure than carrying the NSH in any other encapsulation. From nobody Sun Feb 17 16:08:46 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69996124D68; Sun, 17 Feb 2019 16:08:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001] autolearn=ham autolearn_force=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 prBpk-qasiFN; Sun, 17 Feb 2019 16:08:42 -0800 (PST) Received: from mta5.iomartmail.com (mta5.iomartmail.com [62.128.193.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1BFA1286D8; Sun, 17 Feb 2019 16:08:38 -0800 (PST) Received: from vs3.iomartmail.com (vs3.iomartmail.com [10.12.10.124]) by mta5.iomartmail.com (8.14.4/8.14.4) with ESMTP id x1I08a48022598; Mon, 18 Feb 2019 00:08:36 GMT Received: from vs3.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 93E9B2203D; Mon, 18 Feb 2019 00:08:36 +0000 (GMT) Received: from asmtp3.iomartmail.com (unknown [10.12.10.224]) by vs3.iomartmail.com (Postfix) with ESMTPS id 7D38C2203C; Mon, 18 Feb 2019 00:08:36 +0000 (GMT) Received: from LAPTOPK7AS653V ([59.37.21.226]) (authenticated bits=0) by asmtp3.iomartmail.com (8.14.4/8.14.4) with ESMTP id x1I08WRo007527 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 18 Feb 2019 00:08:34 GMT Reply-To: From: "Adrian Farrel" To: "'Paul Wouters'" , Cc: , , References: <155044786665.4047.16182077722084116649@ietfa.amsl.com> In-Reply-To: <155044786665.4047.16182077722084116649@ietfa.amsl.com> Date: Mon, 18 Feb 2019 00:08:30 -0000 Organization: Old Dog Consulting Message-ID: <011a01d4c71e$16d9dd30$448d9790$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQF5B8APV/6zAJCJLq3MOjIgukEp0qacKyZg Content-Language: en-gb X-Originating-IP: 59.37.21.226 X-Thinkmail-Auth: adrian@olddog.co.uk X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-24434.007 X-TM-AS-Result: No--8.253-10.0-31-10 X-imss-scan-details: No--8.253-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-24434.007 X-TMASE-Result: 10--8.252600-10.000000 X-TMASE-MatchedRID: oTBA/+sdKabxIbpQ8BhdbKlXXrpOy3q0JPNIV6GF8mvOxDyJFXIPjuV0 5r5vXH4sv8qe8eDZGElC65348+oZgVdI3z1FMme36Zzj+kMRBrZR3sGN+j7mNMz1fqX318VP0u5 faGP8ztRV/mZWautsNz95I71UPSkOzsxad8fKloYF8rFt9xmDKTIaJpKzSfrsUCgEErrUGFwHn+ RaCrVBs4SaYXP5EhtmCOtlGomeL41qxgfCZhqtfAI0yP/uoH+DfS0Ip2eEHnwa2S8rkvtFcbDsz p3K5gqDjoczmuoPCq22oIhiAsKJgJS5x7cNmK0Fjy77szn26nqiQGmmwblmDsUufy2PLnHz X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-mpls-sfc-encapsulation-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2019 00:08:44 -0000 Hi Paul, Should we make the observation that, since the MPLS forwarding plane = does not offer any security features, if security is required it must be = provided by the SFC layer using some mechanisms inherent in the NSH. We = could/should probably also observe that, as yet, no NSH security = mechanisms have been defined. Cheers, Adrian -----Original Message----- From: ietf On Behalf Of Paul Wouters Sent: 17 February 2019 23:58 To: secdir@ietf.org Cc: mpls@ietf.org; draft-ietf-mpls-sfc-encapsulation.all@ietf.org; = ietf@ietf.org Subject: Secdir last call review of draft-ietf-mpls-sfc-encapsulation-02 Reviewer: Paul Wouters Review result: Ready I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The summary of the review is Ready While I'm not familiar with the Service Function Chaining (SFC) = architecture and the Network Service Header (NSH), the Security Considerations in = this document seem to be correct in pointing out that: This document simply defines one additional transport encapsulation. The NSH was specially constructed to be agnostic to its transport encapsulation. As as result, in general this additional encapsulation is no more or less secure than carrying the NSH in any other encapsulation. From nobody Sun Feb 17 18:16:52 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DCB31295EC; Sun, 17 Feb 2019 18:16:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=czo0HOCI; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=xypUnxw0 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 2D25Uhd717SV; Sun, 17 Feb 2019 18:16:41 -0800 (PST) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB6AA130EAB; Sun, 17 Feb 2019 18:16:41 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 6981A16C2; Sun, 17 Feb 2019 21:16:40 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Sun, 17 Feb 2019 21:16:40 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm2; bh=l +HzuSJZ1bREpsNv4Z4evrAaQJT+IXLCYtNvyv9zOlQ=; b=czo0HOCIPL2s2Hn/a Z3yS1VRcd8owiacn5GPJ/esktR+Mo++h+Q73NDPiixF495JjtxcW/NxwuNk+2fjp /P/b4XStyEeOynEvAO423ID67XB1ewh7yUPZdLiCY1EqMfW3DQY4y31wwvlWb41G BhheL9auBYyGtUd/zEtBG7ZEWjEoqLbvIXm+LkK9Mip4eRP5jLgE9byXFhuuO6XR 5isb6pqzP8uDxAGSo2y0pSky2F0QK+rwfKXd0KHDFGySDj8xvJ1yMp078bJUBEcS JCHO038bo4WoWky/5qgPLyliTomNglNx/ZhHB25lm/mhQ2zuxuhpmdgCyMXiSZf3 Dp6DA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=l+HzuSJZ1bREpsNv4Z4evrAaQJT+IXLCYtNvyv9zO lQ=; b=xypUnxw08rrtVz0Kok2Mhits4fFGNvmUAWWMVYPeZT+GlpM8m3UClW3Og Jcgj2ik4ZCR+jzfx8hJAjqxaElj/cbwNPLj7fWnNUWFxy/rGoLC+pSnGtjVG/Jpp YfGa2/WiuxIv5aZpT9+/swJSi/pZ9y8GUG/D2FaqtKU/FXkBtb9yjUhFKUYswVK5 OCN3fCrz9uSHUaXVQxK7v6aMpc2NJL3+NF2QTNHQS1/sRODfLdGtLV+hhc+mLL4p 3I/8Dc5EZXzUcSo3JLnEs3I84Mybt0lGVhNvZwIhlu+wijkrc/McSnMlUnNhW4ji ierjlmGfoOqRG0c+fLYT/HxYGSLfw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrudduvddggeekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfquhhtnecuuegrihhlohhuthemucef tddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpegtggfuhfgjff fgkfhfvffosehtqhhmtdhhtdejnecuhfhrohhmpeforghrkhcupfhothhtihhnghhhrghm uceomhhnohhtsehmnhhothdrnhgvtheqnecuffhomhgrihhnpehivghtfhdrohhrghdpmh hnohhtrdhnvghtnecukfhppedugeegrddufeeirddujeehrddvkeenucfrrghrrghmpehm rghilhhfrhhomhepmhhnohhtsehmnhhothdrnhgvthenucevlhhushhtvghrufhiiigvpe dt X-ME-Proxy: Received: from attitudadjuster.mnot.net (unknown [144.136.175.28]) by mail.messagingengine.com (Postfix) with ESMTPA id B73AE10316; Sun, 17 Feb 2019 21:16:36 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Mark Nottingham In-Reply-To: Date: Mon, 18 Feb 2019 13:16:31 +1100 Cc: IETF , IETF SecDir , Kathleen Moriarty , draft-nottingham-rfc5785bis.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <154886569351.10484.4703007670359734409@ietfa.amsl.com> <1317558B-24DD-4CB7-BBB6-95E5946EF87A@mnot.net> To: Barry Leiba X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [secdir] Secdir last call review of draft-nottingham-rfc5785bis-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2019 02:16:45 -0000 > On 16 Feb 2019, at 1:59 am, Barry Leiba = wrote: >=20 >=20 > > What would be helpful here would be some text in the document that = asks IANA to add the instructions to the registry. I'm hoping that more = clearly states my question/request. =20 >=20 > Based on previous interactions with them, my understanding is that = they do *not* want this level of specificity in the defining documents. = Also, your text priorities the mailing list as the submission mechanism, = when the preferred mechanism is likely to be an issue queue (as we've = done for 8288). >=20 > What I think Kathleen is asking isn=E2=80=99t to have the document = specify the registration details, but to make sure the registry header = does. The document says to use the instructions in the registry, but = there are no instructions in the registry. Either the document has to = bootstrap that by giving an initial set of instruction to put there, or = the registry has to have registration instructions that we can = sanity-check now. It doesn=E2=80=99t. >=20 > If the document says to see the registry for registration = instructions, there had better be instructions there, no? Yes, but if we put the instructions in the RFC, people are likely to = follow them -- even when they have been changed down the line. Also, it = creates confusion as to whether it's necessary to update the RFC if they = change. The text we're discussing is sourced from RC8288: https://tools.ietf.org/html/rfc8288#section-4.2 ... which didn't have any such discussion around it. If we're going to = continue this, I'd like to hear from IANA itself about what level of = instruction it'd like. As I've said, the last time around (8288), I got = feedback from them that such a level of detail in the RFC was = counterproductive, and that we could trust folks -- and our process -- = to do the right thing. Regards, -- Mark Nottingham https://www.mnot.net/ From nobody Sun Feb 17 18:35:56 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D16512DD85; Sun, 17 Feb 2019 18:35:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.881 X-Spam-Level: X-Spam-Status: No, score=-1.881 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.018, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 qia7W5ECxQpo; Sun, 17 Feb 2019 18:35:52 -0800 (PST) Received: from mail-it1-f169.google.com (mail-it1-f169.google.com [209.85.166.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42A711295EC; Sun, 17 Feb 2019 18:35:52 -0800 (PST) Received: by mail-it1-f169.google.com with SMTP id m137so7960871ita.0; Sun, 17 Feb 2019 18:35:52 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5HqE8A1OCApYcSNaeoqfRusUAXY5F+9z044nRYkqadc=; b=JNCNnw2hjVfuYcT8vWCvhb/UGVS8hJCf04XW79lneBq1lb6ybkBLbDSrn2A679OvAa tk7KmtNKva1dYxFEol5kpFy2J/VnjArgk4Va9Zj531XLERKmFYBA/AAeNd68CJfSRdrA zqFoh0b0+hrIvgTujJ7RuR16FTJCPW3AjhYq7eIlz7kH5XWnl08nkU5poWcyBMcbWy5t ODdUZDsvbnpQIevdeP5G+up91fTnuK4qJRVMswMlvGmm0fWkQTXXNNplIlBEmItlO4nL 02lS5bAD7mcaNQWXma1/RkLVCbnWDE1sY+a1TFxUaVDCiNISfdWKdW172bx6VmTZ1Ohk 7Lmw== X-Gm-Message-State: AHQUAuaMiETw3+zJzASroSjXEiyyWRzg2jbjUfLjzcO27HlsRszfKPyf bFlYdkQ4oa09Bv9Lc0QTBgN4CEGEcedlazwl6Oc= X-Google-Smtp-Source: AHgI3IasvJEmZ0sNuxa+cWwEteZ32N+/aO/h1mY5i6E1fzrGIHBC3IzxqA+45aB1Zx9fOVyY5JqeH/VHE8sb3LIn3qQ= X-Received: by 2002:a24:dd0a:: with SMTP id t10mr10544335itf.122.1550457351104; Sun, 17 Feb 2019 18:35:51 -0800 (PST) MIME-Version: 1.0 References: <154886569351.10484.4703007670359734409@ietfa.amsl.com> <1317558B-24DD-4CB7-BBB6-95E5946EF87A@mnot.net> In-Reply-To: From: Barry Leiba Date: Sun, 17 Feb 2019 21:35:39 -0500 Message-ID: To: Mark Nottingham Cc: IETF , IETF SecDir , Kathleen Moriarty , draft-nottingham-rfc5785bis.all@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [secdir] Secdir last call review of draft-nottingham-rfc5785bis-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2019 02:35:55 -0000 > > If the document says to see the registry for registration instructions, there had better be instructions there, no? > > Yes, but if we put the instructions in the RFC, people are likely to follow them -- even when they have been > changed down the line. Also, it creates confusion as to whether it's necessary to update the RFC if they change. > > The text we're discussing is sourced from RC8288: > https://tools.ietf.org/html/rfc8288#section-4.2 > ... which didn't have any such discussion around it. If we're going to continue this, I'd like to hear from IANA > itself about what level of instruction it'd like. As I've said, the last time around (8288), I got feedback from them > that such a level of detail in the RFC was counterproductive, and that we could trust folks -- and our > process -- to do the right thing. I agree with all that, but that still misses the point: When someone reads in the RFC that they should follow the instructions in the registry, and they go look at the registry and see nothing, what are they to do? b From nobody Sun Feb 17 18:37:37 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46B7512DD85; Sun, 17 Feb 2019 18:37:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=ELRl1Ow0; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Rx4r17Pd 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 GIg-pJTy0YpT; Sun, 17 Feb 2019 18:37:33 -0800 (PST) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C117D1295EC; Sun, 17 Feb 2019 18:37:33 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 69A3A2F54; Sun, 17 Feb 2019 21:37:32 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Sun, 17 Feb 2019 21:37:32 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm2; bh=w 4rSkpLVJcedddPfth0Uy7XtNa6ols7ScCx4otBwAbQ=; b=ELRl1Ow0GxRxIRd9I aEG4VWxl2vK3mChN+Bz48pLmyaVE6AJozIMc0jEZe5TzBZamjV3h6HhRTOW/BeQO YBAbJZGjv7wDF7HtENe//rRU6VhoWnnEo7Tab0MLhfnFHcPd9rzsFRswUuFHo8LV 7n1AbdbANXpaYJMnGgQvT1ziTX3s6Of5fLZcqOBLarHXtkmLAqW8DOZrS6R9D6d+ u9aYiYzHrbT82wKVrct6ZwonrnCUWw5LFEgEdiFdQw4P8E8GVuNY2bV5tDsnE6UG 8FrBFPL0ROrZyCRWx6dyICb+dOkzUNR1KIEaONlgId3FCkjniS9nCocDCrDnAUsH SQtfA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=w4rSkpLVJcedddPfth0Uy7XtNa6ols7ScCx4otBwA bQ=; b=Rx4r17PdS1ZF1vvWzyQoPwMRT9uhSpzNL5N1gmgyFzbTuuyP8kcfVqDX7 1h23EICmQqxUguIQQx3tE3JqsLjK+bX8YdV9DmkJirSIgYqQ2gyR1Efw2QtyETnA ngDbIM9kCe/4gPBpwIKhuBn1KkSBWUJxXfnkyw4P3IcQnU87Fe4DRCuT3hR6EN/j sjIRytzTiTrEvRBifdjkdkNRVatLCz+07DXO0DC5ShPtlZNgzcIZKNj708UaOCI2 Er943NICBh3Awo9wJpB++xAIHPOvFWWOq1s3ZpkhcXqN+HV9MXD7hzywqFy7RfCW d6M5RjLru1vZ/e9LcCiCilGGPbJSA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrudduvddghedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfquhhtnecuuegrihhlohhuthemucef tddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpegtggfuhfgjff fgkfhfvffosehtqhhmtdhhtddvnecuhfhrohhmpeforghrkhcupfhothhtihhnghhhrghm uceomhhnohhtsehmnhhothdrnhgvtheqnecuffhomhgrihhnpehivghtfhdrohhrghdpmh hnohhtrdhnvghtnecukfhppedugeegrddufeeirddujeehrddvkeenucfrrghrrghmpehm rghilhhfrhhomhepmhhnohhtsehmnhhothdrnhgvthenucevlhhushhtvghrufhiiigvpe dt X-ME-Proxy: Received: from attitudadjuster.mnot.net (unknown [144.136.175.28]) by mail.messagingengine.com (Postfix) with ESMTPA id 0006510314; Sun, 17 Feb 2019 21:37:28 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Mark Nottingham In-Reply-To: Date: Mon, 18 Feb 2019 13:37:24 +1100 Cc: IETF , IETF SecDir , Kathleen Moriarty , draft-nottingham-rfc5785bis.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <79B2F684-4CD4-4715-AED0-5D5A6E1DC612@mnot.net> References: <154886569351.10484.4703007670359734409@ietfa.amsl.com> <1317558B-24DD-4CB7-BBB6-95E5946EF87A@mnot.net> To: Barry Leiba X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [secdir] Secdir last call review of draft-nottingham-rfc5785bis-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2019 02:37:36 -0000 > On 18 Feb 2019, at 1:35 pm, Barry Leiba = wrote: >=20 >>> If the document says to see the registry for registration = instructions, there had better be instructions there, no? >>=20 >> Yes, but if we put the instructions in the RFC, people are likely to = follow them -- even when they have been >> changed down the line. Also, it creates confusion as to whether it's = necessary to update the RFC if they change. >>=20 >> The text we're discussing is sourced from RC8288: >> https://tools.ietf.org/html/rfc8288#section-4.2 >> ... which didn't have any such discussion around it. If we're going = to continue this, I'd like to hear from IANA >> itself about what level of instruction it'd like. As I've said, the = last time around (8288), I got feedback from them >> that such a level of detail in the RFC was counterproductive, and = that we could trust folks -- and our >> process -- to do the right thing. >=20 > I agree with all that, but that still misses the point: > When someone reads in the RFC that they should follow the instructions > in the registry, and they go look at the registry and see nothing, > what are they to do? Because, by the time this becomes an RFC, I (the expert of the registry, = IESG still willing), will work with IANA to get that set up. Probably = during AUTH48. -- Mark Nottingham https://www.mnot.net/ From nobody Sun Feb 17 18:50:27 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63070130EB0; Sun, 17 Feb 2019 18:50:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.881 X-Spam-Level: X-Spam-Status: No, score=-1.881 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.018, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 Q8j3k4VlceiT; Sun, 17 Feb 2019 18:50:17 -0800 (PST) Received: from mail-it1-f172.google.com (mail-it1-f172.google.com [209.85.166.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D8391295EC; Sun, 17 Feb 2019 18:50:17 -0800 (PST) Received: by mail-it1-f172.google.com with SMTP id v72so37794428itc.0; Sun, 17 Feb 2019 18:50:17 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=LHcW7m2wXwLEhfRAGn+AQFU0tth+BeA+GO7qytfa5Ag=; b=XT2gwsYReH4MJ3oPpjUXalVzITEZ5YhuHN3PNykj/pj1bHjbsTVXLiD85G/jW8BILL QSTtyxaY2A6YKPJ9RGp7t/+EwStrisAFptSBH0f4TlQWZVsMp92dSTaOkcQ6H9cleY2t YygMuRk9uFcQwV78lergmyg8WMVlsVe2ApylmBh1uX/ADn/RzjDwpN6phRc6EXaIO+iA aDzEB99v6Eh/jo/L5BAEm9bEjOIgDlKxkLQioeGMO9sj0GIwloQecrVDv4EQFf2HV9eR oeqqHVEq6/uUad/iUcTtTzuXSU6XZcj95GlwyhtPsgXV5oT/NWbJGW+z71nw7yyRe3fL ql2A== X-Gm-Message-State: AHQUAuYUS3GydyQuWk/F6LL1aG8lSkco7nvYvI7ljEAiUx70cZ0V3HyZ V6CxDI0ZroUJFX8WRFhQvTLWMAEG0ZMaUcSgRHo= X-Google-Smtp-Source: AHgI3IYLcgrdw1pimIWaqcdsW6sFG+BHYc2M3feEvgNKtfdV8N66HTK3Z+PfPna15SI1V1Po56drVRK2rrmOysfHPts= X-Received: by 2002:a24:dd8d:: with SMTP id t135mr10119975itf.84.1550458216577; Sun, 17 Feb 2019 18:50:16 -0800 (PST) MIME-Version: 1.0 References: <154886569351.10484.4703007670359734409@ietfa.amsl.com> <1317558B-24DD-4CB7-BBB6-95E5946EF87A@mnot.net> <79B2F684-4CD4-4715-AED0-5D5A6E1DC612@mnot.net> In-Reply-To: <79B2F684-4CD4-4715-AED0-5D5A6E1DC612@mnot.net> From: Barry Leiba Date: Sun, 17 Feb 2019 21:50:05 -0500 Message-ID: To: Mark Nottingham Cc: IETF , IETF SecDir , Kathleen Moriarty , draft-nottingham-rfc5785bis.all@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [secdir] Secdir last call review of draft-nottingham-rfc5785bis-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2019 02:50:20 -0000 > Because, by the time this becomes an RFC, I (the expert of the registry, IESG still willing), will > work with IANA to get that set up. Probably during AUTH48. It would be nice if that were already done, but I'm good with that assurance. Kathleen? b From nobody Sun Feb 17 18:58:26 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03345130EB1; Sun, 17 Feb 2019 18:58:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=jOpr+R8h; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=NVg3FWoZ 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 BewqC_QLhHLn; Sun, 17 Feb 2019 18:58:14 -0800 (PST) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3D9D130EB0; Sun, 17 Feb 2019 18:58:13 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id C49F12D81; Sun, 17 Feb 2019 21:58:12 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Sun, 17 Feb 2019 21:58:13 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm2; bh=T bOj4vrvz3oxsLixji2DmHcx2EcmwwTLVnzkdG34HQM=; b=jOpr+R8h6HM1IjNP4 KMelGxOZRWEn3KPjz9GnqisV9bSzaPT5oWb3s+FQo9ML0D5fldgiZTHGqFP54rpW yF8/ywRBvBBlG56c5/JmLDwUTR3BnvPWRX2HV8p412fHhcI/7XEgjqMDfss97YkA BjbmbMy1tJD9ifLh+FVJ4M5YyRYwPTcE47QQlq2VtNj0gKkgLl40i9ynPQGTXMAa Z5r+gAEcsPN2ddxk+pkRsFAa6ixEJXAghJ+b+vq0fuktSDP8kHuQjyPrLXjBjF5G Thsdko0OQu5qc3T4pATYtFQawhPOKYyIApIARGfExt0w6DN86lSqpjt1ZQPDgHN+ NBcLQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=TbOj4vrvz3oxsLixji2DmHcx2EcmwwTLVnzkdG34H QM=; b=NVg3FWoZKHcFmHsM4RlxJHqjPeFzaXgIh+7Lr7OJXfSmgKpog64y7Yux5 pNA8SbrcH10hwSRrNrQ1ZzFG19AM7qBH8WsvIkAmkaTQGZtUzueKfkjj6BDK4fxZ lhgndHyH5XeWIGSZpc9NNUWuAohhLHdtZR2aVNVpVOm4zEMnCvJByFNZ3S2UUqpY 31z9mcyFHr3HImxuAzBk6I7y7VCEOHW4T+xUMLvnvWlXECPO7koWWSjRE5adu0In c7/x6XXFVSCjdWicPAxDDLsZIc+sH8Dt/FbyOnoyOsrUoUNFTTIVPX9hiISo0Hmu oRhFfnrEHouvfwvEr2Ean0ri8TdyA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrudduvddgheeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfquhhtnecuuegrihhlohhuthemucef tddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpegtggfuhfgjff fgkfhfvffosehtqhhmtdhhtddvnecuhfhrohhmpeforghrkhcupfhothhtihhnghhhrghm uceomhhnohhtsehmnhhothdrnhgvtheqnecuffhomhgrihhnpehmnhhothdrnhgvthenuc fkphepudeggedrudefiedrudejhedrvdeknecurfgrrhgrmhepmhgrihhlfhhrohhmpehm nhhothesmhhnohhtrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from attitudadjuster.mnot.net (unknown [144.136.175.28]) by mail.messagingengine.com (Postfix) with ESMTPA id 58464E4068; Sun, 17 Feb 2019 21:58:09 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Mark Nottingham In-Reply-To: Date: Mon, 18 Feb 2019 13:58:04 +1100 Cc: IETF , IETF SecDir , Kathleen Moriarty , draft-nottingham-rfc5785bis.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <20C12D43-1FB6-4EA4-BAAD-C50B9F73E75E@mnot.net> References: <154886569351.10484.4703007670359734409@ietfa.amsl.com> <1317558B-24DD-4CB7-BBB6-95E5946EF87A@mnot.net> <79B2F684-4CD4-4715-AED0-5D5A6E1DC612@mnot.net> To: Barry Leiba X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [secdir] Secdir last call review of draft-nottingham-rfc5785bis-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2019 02:58:16 -0000 On 18 Feb 2019, at 1:50 pm, Barry Leiba wrote: >=20 >> Because, by the time this becomes an RFC, I (the expert of the = registry, IESG still willing), will >> work with IANA to get that set up. Probably during AUTH48. >=20 > It would be nice if that were already done, but I'm good with that > assurance. Kathleen? It seemed rash to set up the new process before the document was = approved. Cheers, -- Mark Nottingham https://www.mnot.net/ From nobody Sun Feb 17 22:12:57 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DE83E124B0C; Sun, 17 Feb 2019 22:12:49 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Takeshi Takahashi To: Cc: kitten@ietf.org, ietf@ietf.org, draft-ietf-kitten-pkinit-alg-agility.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.91.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155047036985.3948.13609799438850064569@ietfa.amsl.com> Date: Sun, 17 Feb 2019 22:12:49 -0800 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-kitten-pkinit-alg-agility-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2019 06:12:50 -0000 Reviewer: Takeshi Takahashi Review result: Ready I do not see any serious issues on this draft and enjoyed reading it. I have only minor questions for the purpose of deepening my understanding of the draft. 1. In section 5, regarding the The TD-CERT-DIGEST-ALGORITHMS-Data message, who embed the rejectedAlgorithm field? If it will be the KDC, why does the KDC need to fill and distribute this information to the others? 2. In section 8 (security consideration), it is stated that "to do otherwise allows an active attacker to perform a downgrade attack". In my understanding of the draft, arbitrary algorithm could be used (if the negotiation reaches agreements). I wonder if there is any mechanism that discourages the negotiation of using insecure algorithms. For instance, the list of algorithms that must be treated with care could be listed somewhere? Thank you, and kind regards, Take From nobody Mon Feb 18 02:11:54 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8B23130EEF; Mon, 18 Feb 2019 02:11:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 Wrqx0-ZKzI1m; Mon, 18 Feb 2019 02:11:38 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2734A130EEC; Mon, 18 Feb 2019 02:11:38 -0800 (PST) Received: from lhreml703-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 5B44719CC5C6C19F10FE; Mon, 18 Feb 2019 10:11:36 +0000 (GMT) Received: from DGGEML423-HUB.china.huawei.com (10.1.199.40) by lhreml703-cah.china.huawei.com (10.201.108.44) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 18 Feb 2019 10:11:35 +0000 Received: from DGGEML510-MBX.china.huawei.com ([169.254.2.6]) by dggeml423-hub.china.huawei.com ([10.1.199.40]) with mapi id 14.03.0415.000; Mon, 18 Feb 2019 18:11:24 +0800 From: Mach Chen To: Benjamin Kaduk CC: Linda Dunbar , "secdir@ietf.org" , "mpls@ietf.org" , "draft-ietf-mpls-lsp-ping-lag-multipath.all@ietf.org" , "ietf@ietf.org" Thread-Topic: [secdir] Secdir last call review of draft-ietf-mpls-lsp-ping-lag-multipath-05 Thread-Index: AQHUkY+Xr7eIQ7lWe0az4uRG6fBCdqV9d+SwgERX9oCAHShNQIADyugAgALw4PA= Date: Mon, 18 Feb 2019 10:11:24 +0000 Message-ID: References: <154455986336.13151.8483284555885294015@ietfa.amsl.com> <20190126211729.GJ49072@kduck.mit.edu> <20190216202815.GD82217@kduck.mit.edu> In-Reply-To: <20190216202815.GD82217@kduck.mit.edu> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.194.201] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-mpls-lsp-ping-lag-multipath-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2019 10:11:41 -0000 Hi Benjamin, > -----Original Message----- > From: Benjamin Kaduk [mailto:kaduk@mit.edu] > Sent: Sunday, February 17, 2019 4:28 AM > To: Mach Chen > Cc: Linda Dunbar ; secdir@ietf.org; > mpls@ietf.org; draft-ietf-mpls-lsp-ping-lag-multipath.all@ietf.org; > ietf@ietf.org > Subject: Re: [secdir] Secdir last call review of draft-ietf-mpls-lsp-ping= -lag- > multipath-05 >=20 > Hi Mach, >=20 > My apologies as well for the delay. >=20 > On Thu, Feb 14, 2019 at 03:02:07AM +0000, Mach Chen wrote: > > Hi Benjamin, > > > > Sorry for the delayed response! > > > > Please see my response inline... > > > > > -----Original Message----- > > > From: Benjamin Kaduk [mailto:kaduk@mit.edu] > > > Sent: Sunday, January 27, 2019 5:17 AM > > > To: Mach Chen > > > Cc: Linda Dunbar ; secdir@ietf.org; > > > mpls@ietf.org; draft-ietf-mpls-lsp-ping-lag-multipath.all@ietf.org; > > > ietf@ietf.org > > > Subject: Re: [secdir] Secdir last call review of > > > draft-ietf-mpls-lsp-ping-lag- > > > multipath-05 > > > > > > On Fri, Dec 14, 2018 at 02:11:21AM +0000, Mach Chen wrote: > > > > Hi Linda, > > > > > > > > Thanks for the review! > > > > > > > > Some responses inline... > > > > > > > > > -----Original Message----- > > > > > From: ietf [mailto:ietf-bounces@ietf.org] On Behalf Of Linda > > > > > Dunbar > > > > > Sent: Wednesday, December 12, 2018 4:24 AM > > > > > To: secdir@ietf.org > > > > > Cc: mpls@ietf.org; > > > > > draft-ietf-mpls-lsp-ping-lag-multipath.all@ietf.org; > > > > > ietf@ietf.org > > > > > Subject: Secdir last call review of > > > > > draft-ietf-mpls-lsp-ping-lag-multipath-05 > > > > > > > > > > Reviewer: Linda Dunbar > > > > > Review result: Ready > > > > > > > > > > I have reviewed this document as part of the security > > > > > directorate's ongoing effort to review all IETF documents being > > > > > processed by the IESG. These comments were written primarily > > > > > for the benefit of the security area directors. Document > > > > > editors and WG chairs should treat these comments just like any > other last call comments. > > > > > > > > > > The summary of the review is Ready with comment > > > > > > > > > > The described mechanism for LSP Multipath Ping is very clear. > > > > > The Security Consideration re-uses the description of RFC8029, > > > > > which is very comprehensive. > > > > > It would be better if the draft describes how to prevent > > > > > intermediate LSRs in between the Initiating LSR and Responding > > > > > LSR from mis-using the detailed link information (e.g. > > > > > forwarding to > > > somewhere else). > > > > > > > > The Echo Request and Reply messages are directly exchanged between > > > > the > > > Initiating LSR and the Responding LSR, those intermediate LSRs just > > > forward the messages as normal packets, they will not see the > > > detailed link information unless if they inspect and do DPI on every > > > packet forwarded by them. > > > > > > > > The detailed link information is supplied to the Initiating LSR > > > > for using, the > > > intermediate LSRs will not try to use it even if they received the > > > information, because there is no corresponding Echo Request to the > received Echo Reply. > > > > > > The intermediate LSRs still will have access to the plaintext > > > information, even if in normal operation they do not need to act upon > that information. > > > Generally in this sort of situation we will either explicitly state > > > that the intermediate nodes must be trusted to not abuse the > > > information in question, or provide some mechanism for end-to-end > > > confidentiality protection. > > > > "Intermediate nodes must be trusted to not abuse the information" is > normally assumed. For the intermediate nodes, there is no different > between the Echo Reply messages and any other data traffic, control > messages. They just forward the Echo Reply messages as normal packets. I > am not sure it needs to explicitly state this. Do you suggest to add suc= h a > statement in the security consideration section? >=20 > The concern is not about the normal operation, but rather about abnormal > operation, e.g., if an intermediate node gets compromised by an attacker. > We need to document the new abilities an attacker gets, when comparing > the original case of "an attacker compromises an intermediate node that i= s > using MPLS without this mechanism" to the new case of "an attacker > compromises an intermediate node that is using MPLS with this mechanism". > So, while I do suggest adding a statement to the security considerations > section, the statement I want does not relate to the normal operation cas= e > (when intermediate nodes ignore the contents of the message). OK, will add such a statement in the security considerations section.=20 >=20 > > > > > > Also (noting that I only skimmed the document so this may not make > > > sense), the security considerations seem to suggest using an IP ACL > > > for determining which messages are trusted; IP ACLs are generally > > > not recommended in favor of cryptographic mechanisms at this point. > > > > IP ACLs was introduced in RFC 8029 and is reused in this document, > > it's >=20 > I did not find a clear and explicit declaration in RFC 8029 of the concep= t of an > IP ACL; I assume you are referring to: >=20 > To protect against unauthorized sources using MPLS echo request > messages to obtain network information, it is RECOMMENDED that > implementations provide a means of checking the source addresses of > MPLS echo request messages against an access list before accepting > the message. Yes, this is that I am referring to. >=20 > I do not think anyone is going to say "do not filter based on IP source > address", but there would be general skepticism about relying upon it as = a > sole security mechanism. >=20 > > just one of the security mechanisms. This document is an extension to >=20 > (Could you remind me of the other mechanisms? I don't think I have a goo= d > handle on them.) You are right, for protecting against unauthorized sources, IP ACL is the o= nly way proposed in RFC 8029 and this document.=20 >=20 > > RFC 8029, as stated in this document, all security considerations > > defined in RFC 8029 apply to this document. Do you have any specific > > suggestion to the current security consideration? >=20 > I am mostly just lamenting the state of affairs; this is a sufficiently > incremental change that it is inappropriate to require dramatic changes i= n the > security mechanisms. I agree with you. Does it mean that you are OK with the current security co= nsiderations, given that a statement regarding the intermediate node's proc= ess will be added. Best regards, Mach >=20 > -Ben From nobody Mon Feb 18 06:52:07 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DD7C1293B1; Mon, 18 Feb 2019 06:51:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mit.edu 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 Cz5U-ZOLzokx; Mon, 18 Feb 2019 06:51:51 -0800 (PST) Received: from NAM05-CO1-obe.outbound.protection.outlook.com (mail-eopbgr720097.outbound.protection.outlook.com [40.107.72.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FA1A128B01; Mon, 18 Feb 2019 06:51:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lVYPbnYPkpm/bwDCOEPn0B1t8qnyLYO4Y6dxuGmnqS0=; b=aEP/0P+4/bAV94OakfTNRvahNI4bG4Y7LzHKEbO4aUgE96bAm5FbC+IsDIgBKLzwLNtxzKAbnmCcp4RTgAkmRg51nxh+rFKadFzST4gxjq06Zd2jUZlyQmPraX9pV+c94lhw8VSlmrbt2eX20eaP/JpM9TtXFqWo1Gjcx6wqCbI= Received: from CY4PR01CA0024.prod.exchangelabs.com (2603:10b6:903:1f::34) by SN6PR01MB4863.prod.exchangelabs.com (2603:10b6:805:d8::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1622.18; Mon, 18 Feb 2019 14:51:49 +0000 Received: from CO1NAM03FT023.eop-NAM03.prod.protection.outlook.com (2a01:111:f400:7e48::201) by CY4PR01CA0024.outlook.office365.com (2603:10b6:903:1f::34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1622.16 via Frontend Transport; Mon, 18 Feb 2019 14:51:49 +0000 Authentication-Results: spf=pass (sender IP is 18.9.28.11) smtp.mailfrom=mit.edu; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=mit.edu; Received-SPF: Pass (protection.outlook.com: domain of mit.edu designates 18.9.28.11 as permitted sender) receiver=protection.outlook.com; client-ip=18.9.28.11; helo=outgoing.mit.edu; Received: from outgoing.mit.edu (18.9.28.11) by CO1NAM03FT023.mail.protection.outlook.com (10.152.80.157) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1643.13 via Frontend Transport; Mon, 18 Feb 2019 14:51:48 +0000 Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x1IEpiIl031107 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 18 Feb 2019 09:51:46 -0500 Date: Mon, 18 Feb 2019 08:51:44 -0600 From: Benjamin Kaduk To: Mach Chen CC: Linda Dunbar , "secdir@ietf.org" , "mpls@ietf.org" , "draft-ietf-mpls-lsp-ping-lag-multipath.all@ietf.org" , "ietf@ietf.org" Message-ID: <20190218145144.GG24387@kduck.mit.edu> References: <154455986336.13151.8483284555885294015@ietfa.amsl.com> <20190126211729.GJ49072@kduck.mit.edu> <20190216202815.GD82217@kduck.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:18.9.28.11; IPV:CAL; SCL:-1; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(346002)(39860400002)(136003)(396003)(376002)(2980300002)(13464003)(189003)(199004)(55016002)(8936002)(305945005)(8676002)(229853002)(7696005)(14444005)(76176011)(93886005)(53416004)(47776003)(50466002)(88552002)(5660300002)(356004)(1076003)(97756001)(246002)(2906002)(478600001)(26826003)(106466001)(956004)(446003)(6916009)(86362001)(6246003)(36906005)(46406003)(336012)(486006)(126002)(426003)(4326008)(476003)(11346002)(186003)(23726003)(26005)(53546011)(104016004)(58126008)(54906003)(16586007)(75432002)(106002)(786003)(316002)(33656002)(18370500001); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR01MB4863; H:outgoing.mit.edu; FPR:; SPF:Pass; LANG:en; PTR:outgoing-auth-1.mit.edu; MX:1; A:1; X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: be2d71d8-ad48-4ebb-e147-08d695b09c53 X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605104)(4608103)(4709054)(2017052603328)(7153060); SRVR:SN6PR01MB4863; X-MS-TrafficTypeDiagnostic: SN6PR01MB4863: X-Microsoft-Exchange-Diagnostics: 1; SN6PR01MB4863; 20:ym0GVIZcxbl/bnNQVTKyq9Qkuf91nUNkTgV2HhhgSFHbtxZC5ceiMpHCkoWV8lxYPwtEdDGUPphqdKu+gYJk/rl5Sc4xqEJwb/zLA45c7A2o0mZ/iae+4J+D7TiMsYfTw/3HYQUAT2O9ceDH6yPywTZMcd2Od5/esPjTjUMBkeOKofaKC+vjgjwik13IwpvY4Tghp6fvU/C3UN8VZSThEhLvLzw7D45TBFep0xt2J3655KAr3IFU+IkYgXZ2zmEljvzDuSEdnmf0QU4Rv3QT0pbe6DaT4t/0vVFS/7OR4ZnpDpGeDgzUtKsKIYx86KAhwvtmJw0rYMnGDUkW3nzqZv2ZA1I75YrW/lVrMCK42eMHyT0jwrilLaztS0SMh9inymgz2Z1eLJPTw4Sp/28ETqg/jb1PiUhq+A2UN02KWXSqwqTzJ7IIu+fxZ9k0tr7epQr+UGaQ7hdPPpZDmo26FqgxtJ0iSUUsTzqtzY2/RXDUwQDHLqbbcjbf52q0cl3CRi7LXPaBBJ7mMRwM5K8V+/DsJgotE8leZnohIUArm+TULHg5mixpIn8s0TM8uAz3VANWtiKSs7dXBkEGKa0sWmS8jEHsnXMgPLkzD3tqMnk= X-Microsoft-Antispam-PRVS: X-Forefront-PRVS: 09525C61DB X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; SN6PR01MB4863; 23:RlpfaBZzEPRXK8P9ARlMbNAqMLnUBDd5GSD4ol+T+?= =?us-ascii?Q?Zp58+rzdsfnWJ2ELub1Gm47E2kEbTRPriWs44thxxDplN/FKUgIEcUSjYHLU?= =?us-ascii?Q?bsPnyVOOEulZo3BGMTnuSq2c8cPNttOn64zdR8PsXjvwvyf8+NBQUKZx16Vh?= =?us-ascii?Q?b3a6ItuK3LABwvlyT3wwhN17ucXHWf7UOsfYPoEertFKUagmwNfn+MgUuFUB?= =?us-ascii?Q?0k00A5Ts2+BRYhJrUzm/SGmd2z/hvU/y0ZUbS015s444QDBaHaPWHJJITVK8?= =?us-ascii?Q?USSYixoo8AwBpuNrEBbc7kKqeW5BsusQbT+mlTOwB+2v0qEiZCB3SDdOl6+M?= =?us-ascii?Q?d8uKxZLt9ViFWWW0QkjxSnjgeNFHy37TgHP+cQuxsfu+71mVelNt607805ol?= =?us-ascii?Q?gcMyxzmqeHelwFexRT7JIqcEmYq8sXlN64dnnk7KtRQMWM6Mu5JAmk0ZtFrg?= =?us-ascii?Q?y3nFuSwfS34nUt2Hp5PgMLRNyNSujCWFoFqxVHPNvDjbYX+9zqKWlh9NMQY6?= =?us-ascii?Q?yTKT4zlCTv6uUPGIBwn9bKjJiDPvd1hGRRTTOs+mk4LMWTGCE/X6ihg93DL8?= =?us-ascii?Q?Yu0m5hwEF4+aoH1q3kKJhbTyWHlUEghzvjiyvN1kKaX2Oc36kL2Zwb0ykWgM?= =?us-ascii?Q?D5p3WGC0upuL1I0+cNAQ4/jbVe2NO0oY3jKPATJX9tj28ol8T5dkFLtJkML2?= =?us-ascii?Q?czH4W8KweIhSfWX3UWtslk2uf1QAwuSLVOawfYqVod/FL9ANtpyQFxJcE+NO?= =?us-ascii?Q?5L7lZU83CBZXE+udtqfnIWDM2xO25WM08N1gc6hiT4gMmldRvLZBoLJ2ZZFv?= =?us-ascii?Q?mwacEQwmc1P5Rdk5DnluMNHl6JCRdUW9siL3F9JhF/UpvI57HnZSwdf1/zCZ?= =?us-ascii?Q?DUUMOaqq5xqboUk3V5mQaC7PF8UDH8uq8slHRWvTQo7iDdj0gCHo2DQbiAU8?= =?us-ascii?Q?ng3tj/fLdBYBZSaYIbW7CQC1zGXeXCpwgOL91KCl8nsQCI0wR/nnxzE9SRof?= =?us-ascii?Q?YjwLMsNRqqTVbCeOY+VRCG5GgsPXLSm1UapIVvEq3N89LBbIuf5Ry0bqjKS6?= =?us-ascii?Q?WZKl7X3D4TOI3x51R7jGm6kCKhPsyLzsrbO/0pl/FSgs7sW3sdIcCtERe8VZ?= =?us-ascii?Q?eM3cc/Ytk2hojNd9QvW/JJzO3+ex36C7KQgVIH7y+vWH9sThHMLjAJ+tdjJp?= =?us-ascii?Q?6W7yxzsYMDI7sZ5FlUps+kvpcoVSI4kChQVE4Upy5tpeNFiFMpioJLCkfeUm?= =?us-ascii?Q?rDjblOa5P8MM3OEzx/wOZ19NOPm4He7i8gtCskHzoQlJEUIotHooLbzC1gJh?= =?us-ascii?B?Zz09?= X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Message-Info: WGuFwtGUsdiMOeUxAOx5S9pwVIQYyR5QusLdVhqekwUtynGHckmKTG0YIE3BWyW34dWTzUpJr1rGuMnzGQP7nTtZFyTIH7K8jwUOlZepDtXRJ7S+nmiBqD+ytUfWxVbvIZgw5hpkfQtGJq8NwZD98JdS7ASzmGyFxAnzuHJwtBis18kkrLhfsT90jdOtGlOqHyI5Zegdgu5ckQs7dz6f16ll++2k5mcEoHjpe/ggvTipdYgAMgVgRYPy1ybUSFGa2YyAlHruGbZ3wbvsbEEwEQPIO0kG58NRGv1Hd9oASntmhjyu/5m8hInwhp/cRPq8fEqKHOuYickAcsOUtfSBqq0YYA5Z+G19sEbphFHkGl87feqJ1cGnfMgez6btjj/8HPtB5fVSvjUmfdF4+C94y4EMGAk9gb8oLROEB22LhZc= X-OriginatorOrg: mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Feb 2019 14:51:48.4495 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: be2d71d8-ad48-4ebb-e147-08d695b09c53 X-MS-Exchange-CrossTenant-Id: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=64afd9ba-0ecf-4acf-bc36-935f6235ba8b; Ip=[18.9.28.11]; Helo=[outgoing.mit.edu] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR01MB4863 Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-mpls-lsp-ping-lag-multipath-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2019 14:51:54 -0000 On Mon, Feb 18, 2019 at 10:11:24AM +0000, Mach Chen wrote: > Hi Benjamin, > > > -----Original Message----- > > From: Benjamin Kaduk [mailto:kaduk@mit.edu] > > Sent: Sunday, February 17, 2019 4:28 AM > > To: Mach Chen > > Cc: Linda Dunbar ; secdir@ietf.org; > > mpls@ietf.org; draft-ietf-mpls-lsp-ping-lag-multipath.all@ietf.org; > > ietf@ietf.org > > Subject: Re: [secdir] Secdir last call review of draft-ietf-mpls-lsp-ping-lag- > > multipath-05 > > > > Hi Mach, > > > > My apologies as well for the delay. > > > > On Thu, Feb 14, 2019 at 03:02:07AM +0000, Mach Chen wrote: > > > Hi Benjamin, > > > > > > Sorry for the delayed response! > > > > > > > > > "Intermediate nodes must be trusted to not abuse the information" is > > normally assumed. For the intermediate nodes, there is no different > > between the Echo Reply messages and any other data traffic, control > > messages. They just forward the Echo Reply messages as normal packets. I > > am not sure it needs to explicitly state this. Do you suggest to add such a > > statement in the security consideration section? > > > > The concern is not about the normal operation, but rather about abnormal > > operation, e.g., if an intermediate node gets compromised by an attacker. > > We need to document the new abilities an attacker gets, when comparing > > the original case of "an attacker compromises an intermediate node that is > > using MPLS without this mechanism" to the new case of "an attacker > > compromises an intermediate node that is using MPLS with this mechanism". > > So, while I do suggest adding a statement to the security considerations > > section, the statement I want does not relate to the normal operation case > > (when intermediate nodes ignore the contents of the message). > > OK, will add such a statement in the security considerations section. Thanks! > > > > > > > > > > Also (noting that I only skimmed the document so this may not make > > > > sense), the security considerations seem to suggest using an IP ACL > > > > for determining which messages are trusted; IP ACLs are generally > > > > not recommended in favor of cryptographic mechanisms at this point. > > > > > > IP ACLs was introduced in RFC 8029 and is reused in this document, > > > it's > > > > I did not find a clear and explicit declaration in RFC 8029 of the concept of an > > IP ACL; I assume you are referring to: > > > > To protect against unauthorized sources using MPLS echo request > > messages to obtain network information, it is RECOMMENDED that > > implementations provide a means of checking the source addresses of > > MPLS echo request messages against an access list before accepting > > the message. > > Yes, this is that I am referring to. > > > > > I do not think anyone is going to say "do not filter based on IP source > > address", but there would be general skepticism about relying upon it as a > > sole security mechanism. > > > > > just one of the security mechanisms. This document is an extension to > > > > (Could you remind me of the other mechanisms? I don't think I have a good > > handle on them.) > > You are right, for protecting against unauthorized sources, IP ACL is the only way proposed in RFC 8029 and this document. > > > > > > RFC 8029, as stated in this document, all security considerations > > > defined in RFC 8029 apply to this document. Do you have any specific > > > suggestion to the current security consideration? > > > > I am mostly just lamenting the state of affairs; this is a sufficiently > > incremental change that it is inappropriate to require dramatic changes in the > > security mechanisms. > > I agree with you. Does it mean that you are OK with the current security considerations, given that a statement regarding the intermediate node's process will be added. Given what I've seen so far, yes. (I only skimmed the document as part of this thread, and will do a full review as it comes up on an IESG telechat.) -Benjamin From nobody Mon Feb 18 09:08:16 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D6DC1277CC; Mon, 18 Feb 2019 09:08:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 F4kMEZGiFis0; Mon, 18 Feb 2019 09:08:05 -0800 (PST) Received: from mail-ot1-x331.google.com (mail-ot1-x331.google.com [IPv6:2607:f8b0:4864:20::331]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96ACA129A87; Mon, 18 Feb 2019 09:08:05 -0800 (PST) Received: by mail-ot1-x331.google.com with SMTP id c18so7863262otl.13; Mon, 18 Feb 2019 09:08:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7zoCXliJbJOMF+NfVcO9W7wJJzJZEkCOOiD/aHhVits=; b=RSvlxKXs016UdNnSIVo/QBARgS5vQQkvsxBZtJ16aZFcSlrDLhTmGwn1mNdfR5LwfD XIcqV9fb1cY3FbeDAuuObyW49+vp+SucKS/F7rx5iGH84PWW7/gZF/0LsC0TxDQUtUOV fAvUTG88ina+YlgCp0wxWqJLmrOuYG6yz4w+dy6cTXIqeUCAZMZPqAp+oN36HTloiVh5 eI+obI4HVrsCcuBj0QwQGJO4zdJ9E1UuoT2WggtaYlcF+g7xSnB7Q/8wroY7iOMgTwyZ jcI7LsnZCuRHes7vPq8fihk4Hh71XuNvnZBuDFSRKrsW64o0OwpsbUV9hVkeaqDFyFVK cU2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7zoCXliJbJOMF+NfVcO9W7wJJzJZEkCOOiD/aHhVits=; b=nr0ra2WaQD72vLBckVcfNNoO1DY3cpBPwWGbff928r+hgmmWX/Yp9cfdGE+50YJZXq LQcIsXQ6IwMrFJhajMWueqjyUMp/mrIjhnDvtPWlEbqgIMJ/J3cmX24+UY1WJ3+RaH7S XvgPGxLQyeEhdy0rRaYDyUA/D4WDk0N44MTD4l7K9G1tL7dD8B1xTYyERvUaODSmlVRP JsbPUUQE5LPQ1p25+0YtiT11lkPI23wSNAK8GnqihbdaxmqkKpXcfAyTNDcsbRHuYrOQ lpyoPmY/4hbvcPZemWPbMc+fPUw+NuS6UMAyxbcujKRe+xag9Jl28+nJtut1gStm/zhi /eGw== X-Gm-Message-State: AHQUAuZc36Bod7V7c5/3tq83ue17lkJy+Vk1NxOAFC1fUuOP8c3/jZAq sbDvPALtrWlAEZ6vjgaRAtur11IQe8NcVcn8xzo= X-Google-Smtp-Source: AHgI3IZae646toAn17Pvaa7fwYmj6mhrQZdJpHpaCDGBFGWtAJQLgOYMdDVyA/FAUDYXGhPWE7XMjMe3EqYCj8wnPSA= X-Received: by 2002:a54:4391:: with SMTP id u17mr14165207oiv.111.1550509684825; Mon, 18 Feb 2019 09:08:04 -0800 (PST) MIME-Version: 1.0 References: <154886569351.10484.4703007670359734409@ietfa.amsl.com> <1317558B-24DD-4CB7-BBB6-95E5946EF87A@mnot.net> <79B2F684-4CD4-4715-AED0-5D5A6E1DC612@mnot.net> <20C12D43-1FB6-4EA4-BAAD-C50B9F73E75E@mnot.net> In-Reply-To: <20C12D43-1FB6-4EA4-BAAD-C50B9F73E75E@mnot.net> From: Kathleen Moriarty Date: Mon, 18 Feb 2019 12:07:28 -0500 Message-ID: To: Mark Nottingham Cc: Barry Leiba , IETF , IETF SecDir , draft-nottingham-rfc5785bis.all@ietf.org Content-Type: multipart/alternative; boundary="000000000000fc270205822e2aa9" Archived-At: Subject: Re: [secdir] Secdir last call review of draft-nottingham-rfc5785bis-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2019 17:08:08 -0000 --000000000000fc270205822e2aa9 Content-Type: text/plain; charset="UTF-8" On Sun, Feb 17, 2019 at 9:58 PM Mark Nottingham wrote: > On 18 Feb 2019, at 1:50 pm, Barry Leiba wrote: > > > >> Because, by the time this becomes an RFC, I (the expert of the > registry, IESG still willing), will > >> work with IANA to get that set up. Probably during AUTH48. > > > > It would be nice if that were already done, but I'm good with that > > assurance. Kathleen? > > It seemed rash to set up the new process before the document was approved. > I'll leave it up to the current ADs, but having text that says something like: "The instructions included below are the initial set to be used by IANA and entered on the registry. Subsequent updates will be made directly to the registry, therefore that set is considered authoritative." Would be helpful to avoid confusion. Best regards, Kathleen > > Cheers, > > > -- > Mark Nottingham https://www.mnot.net/ > > -- Best regards, Kathleen --000000000000fc270205822e2aa9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Feb 17, 2019 at 9:58 PM Mark = Nottingham <mnot@mnot.net> wrote= :
On 18 Feb 2019= , at 1:50 pm, Barry Leiba <barryleiba@computer.org> wrote:
>
>> Because, by the time this becomes an RFC, I (the expert of the reg= istry, IESG still willing), will
>> work with IANA to get that set up. Probably during AUTH48.
>
> It would be nice if that were already done, but I'm good with that=
> assurance.=C2=A0 Kathleen?

It seemed rash to set up the new process before the document was approved.<= br>

I'll leave it up to the current ADs= , but having text that says something like:

"= The instructions included below are the initial set=C2=A0 to be used by IAN= A and entered on the registry.=C2=A0 Subsequent updates will be made direct= ly to the registry, therefore that set is considered authoritative."

Would be helpful to avoid confusion.

=
Best regards,
Kathleen

Cheers,


--
Mark Nottingham=C2=A0 =C2=A0https://www.mnot.net/



--

Best regards,
Kathleen
--000000000000fc270205822e2aa9-- From nobody Mon Feb 18 10:14:39 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83BCD130F01; Mon, 18 Feb 2019 10:14:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 fBfnzfEa6Dea; Mon, 18 Feb 2019 10:14:36 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7731B12F295; Mon, 18 Feb 2019 10:14:35 -0800 (PST) Received: from [192.168.178.124] ([84.171.150.173]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MAQMg-1gkDeq32DK-00BdIh; Mon, 18 Feb 2019 19:14:26 +0100 To: Kathleen Moriarty , Mark Nottingham Cc: draft-nottingham-rfc5785bis.all@ietf.org, Barry Leiba , IETF , IETF SecDir References: <154886569351.10484.4703007670359734409@ietfa.amsl.com> <1317558B-24DD-4CB7-BBB6-95E5946EF87A@mnot.net> <79B2F684-4CD4-4715-AED0-5D5A6E1DC612@mnot.net> <20C12D43-1FB6-4EA4-BAAD-C50B9F73E75E@mnot.net> From: Julian Reschke Message-ID: Date: Mon, 18 Feb 2019 19:14:26 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K1:8H7LtuX08umrCFjIIB2ZCJOmu0g6isodO6PmBC8tvPu5EwRXhKy EjqSqmfJrsg6kH3CrO9HG9zSayjFvWjbL62qqgVNMOZWNVI6pjNNn0lQJKNauv0wfa+xtNT UZCogGmpz7rxxHanv/yunciK2ZDmadXkOrX28aq4WgRFQQEji2WUHRSkOlbS+Z/TJKl4iZZ xb3S9qHV48FKL5RtackCg== X-UI-Out-Filterresults: notjunk:1;V03:K0:vEVaC8S8X4I=:FirSGGfVFjCH/EamsX8YoS N1UqFNVS56dclxoSin8gf6Obs26DOS2/nyMrPZr6YvDjGw8zRLhdTiweq7eV373QBQvKMPyJJ P6XFJ8sAGE3d4Ntve5nBLXsaTissG/AXh6+KP2bWYX0dT1pzEznrOrHGSaNvNe1BUDEuzM8BT aqciq2uzztjprDztcfLqhHHnXxHUC7L+0vi13UP+rIRnhj1ICB5XFNY8CiS2PgksaDspE8Dq4 tvFiouqG22PNdFy0D0fiTOyiB/DfmILU+PjhaPwf6n6j9OFXgxdStjHIbYPWhktVudKU8YLz8 8iRh4F60Xrz00FJBGMjHcLNA80+Sfc78PJQ9amIGkcPnILYiT2A9LmkD7UsnIAfZgx6vqo06y cTDI5gdkac+jxuO5NznkHiZj2NXApnBVmBDkwuJS0SSRjzuVfwelwqZsFC57EXBGqV0DJD1FJ E4jWVnfVnkxyQzAh0tVKWZcNCnzvOIzgt63F0rFwlD3F+CMPSGUw2bIFEx+Usi2fb3Dw8ixB7 bn1NhY4VBYE7LBNEGU1OSB85tEQqHPbkw2WaydazcMHeYyT5LaGKCl3nvzK7jzU//4rPTQWVI WjSEgb+1oxOJ5J/2UGWQ7kaVcUXrbGZWC+igj8S7ThdqAfVInJozVyr8wTOiJ6WYJx1J+fOLO zpd2ZuVIbFxIbYIxMQRU4IX61plwdcLDQtJTnQLRgHHgspwgPy09XfNo0JwzhuW4GOvrUv2P8 HSSwv0GAILTYkwFGGaTf5uIN0kw01pOANHeXi/D3jZ+lxXHBT14VMVsIT97vuxfONfXmTHv6L DhWPArMmHHv6ap9AJTtTL7zbvdZkI8gLB/HnylGNccw5d0kuEyysBy+vIbwu1v4WWXVUih0gU QOvzyux3iW5vATtpwNUCxLEy3J/drupFivMQKU3BjwUB/sgH14J5JNSLNvJdzwr6EqEMnRaSx vVwJwWCssTg== Archived-At: Subject: Re: [secdir] Secdir last call review of draft-nottingham-rfc5785bis-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2019 18:14:38 -0000 On 18.02.2019 18:07, Kathleen Moriarty wrote: > > > On Sun, Feb 17, 2019 at 9:58 PM Mark Nottingham > wrote: > > On 18 Feb 2019, at 1:50 pm, Barry Leiba > wrote: > > > >> Because, by the time this becomes an RFC, I (the expert of the > registry, IESG still willing), will > >> work with IANA to get that set up. Probably during AUTH48. > > > > It would be nice if that were already done, but I'm good with that > > assurance.  Kathleen? > > It seemed rash to set up the new process before the document was > approved. > > > I'll leave it up to the current ADs, but having text that says something > like: > > "The instructions included below are the initial set  to be used by IANA > and entered on the registry.  Subsequent updates will be made directly > to the registry, therefore that set is considered authoritative." > > Would be helpful to avoid confusion. > > Best regards, > Kathleen ...and mark that section for removal before publication as RFC. Best regards, Julian From nobody Mon Feb 18 10:16:50 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B6CD8130F58; Mon, 18 Feb 2019 10:16:41 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Daniel Migault To: Cc: draft-ietf-dmm-ondemand-mobility.all@ietf.org, ietf@ietf.org, dmm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.91.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155051380167.25913.15655026458944323422@ietfa.amsl.com> Date: Mon, 18 Feb 2019 10:16:41 -0800 Archived-At: Subject: [secdir] Secdir telechat review of draft-ietf-dmm-ondemand-mobility-16 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2019 18:16:42 -0000 Reviewer: Daniel Migault Review result: Has Nits Reviewer: Daniel Migault Review result: Ready with Nits Hi, I am the assigned Secdir reviewer for this draft. The Security Directorate (Secdir) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. Overall my concerns for version 15 have been addressed / clarified. I do not have major concerns, but I believe the security consideration section might provide more details. Though I do not see this as blocking. Yours, Daniel From nobody Mon Feb 18 11:04:29 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C27C128AFB; Mon, 18 Feb 2019 11:04:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 f_-y6GZWTKh4; Mon, 18 Feb 2019 11:04:17 -0800 (PST) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4643D12894E; Mon, 18 Feb 2019 11:04:16 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.58,385,1544482800"; d="scan'208";a="369918887" Received: from unknown (HELO [172.20.10.4]) ([80.214.216.51]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Feb 2019 20:04:03 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Vincent Roca In-Reply-To: Date: Mon, 18 Feb 2019 20:03:35 +0100 Cc: Vincent Roca , secdir@ietf.org, iesg@ietf.org, draft-ietf-perc-private-media-framework.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <6882A552-80DF-4322-9683-13D8E655F2DB@inria.fr> References: <155014077570.26619.9407568904769535504@ietfa.amsl.com> To: "Paul E. Jones" X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-perc-private-media-framework-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2019 19:04:21 -0000 Hello Paul, all, > Thanks for the review. Please see comments inline. You=E2=80=99re welcome. >> ** Section 8.1 >> Why is it said that: >> "A successful attacker might be able to get the Media = Distributor to >> forward such packets." >> Is it really possible? That would be a big design issue! In fact the = following >> sentence suggest the opposite and I think this is essentially an = erroneous >> manner to present things. Please see comments on Section 8.2.4 on = saying things >> the other way round. >=20 > Indeed, this kind of attack would not be possible since the Media = Distributor must perform HBH authentication. I'll re-word this. VR: thanks. >> The same comment applies to the remaining two paragraphs. I suggest = the authors >> explain that the proposal prevents an attacker to claim being a = regular Media >> Distributor and therefore to fool endpoints because ...". >=20 > The "false Media Distributor" example could happen. For example, if a = hacker had access to the network where the Media Distributor is located = and claims the Media Distributor's address while the conference is = operating, the endpoints might not know. However, the worst result of = such an attack is similar to just unplugging the box: packets just don't = flow. The fake box could attempt to forward packets it receives, but = they would fail to authenticate at the receiving endpoints and be = discarded. However, this false device could never gain access to the = media and would not be given HBH keys since it could not authenticate = with the Key Distributor. VR: you=E2=80=99ve said that a false Media Distributor will fail to get = access to the media and fail to forward the traffic. In the original text, you also say = that: "They Key Distributor will fail to establish the secure association with the endpoint if the Media Distributor cannot be authenticated." I agree that an attacker may try to impersonate a valid MD, but this = attempt will fail. And when you say that: =C2=AB false Media Distributor may cascade to another legitimate Media Distributor creating a false version of the real conference" this is just wrong. The attacker won=E2=80=99t succeed.=20 This is why I=E2=80=99m saying that you should re-write this part to say = that clearly that thanks to the provided security mechanism, an attacker will fail to = impersonate a MD. Don=E2=80=99t pretend attacks can succeed if this is not the case. >> ** Section 8.2.2. >> Is the following sentence correct: >> The mitigation for a replay attack is to prevent old packets beyond = a >> small-to-modest jitter and network re-ordering sized window to be >> rejected. >> Is "prevent [...] to be rejected" correct? I'd say "... to be = delivered" >> instead. >=20 > "prevent... rejected" is definitely an error. However, we cannot stop = delivery. If replayed packets are received by either the Media = Distributor or the endpoint, they should be discarded. So, perhaps this = is better: >=20 > "The mitigation for a replay attack is to discard old packets beyond a > small-to-modest jitter and network re-ordering sized window. =C2=BB VR: Better, if we assume there's a timing based replay protection = mechanism. But the following item bellow indicates a totally different approach to = replay protection (ID based rather than time based), hence a major contradiction in this = text. Please fix it. >> Another comment. Replay protection seems to be based on timing = considerations >> rather than on the use of unique sequence numbers that must not be = replayed >> (except if a wrapping to zero occurs of course). Is that correct? = Additionally, >> is this mechanism carefully described in this document? Since it is = explained >> that E2E replay protection MUST be provided, it's essential to be = very clear on >> how to perform this. Failing to do so is a big issue. >=20 > The mechanism underlying this is SRTP, which defines in 3.3.2/RFC3711 = an "SRTP window size". We felt it was best to not introduce conflicting = language. Perhaps we should just change the paragraph more substantially = and refer to SRTP. >=20 > Would you prefer this as the second paragraph? >=20 > "The mitigation for a replay attack is to implement replay protection = as > described in Section 3.3.2 of [RFC3711]. > End-to-end replay protection **MUST** be provided for the > whole duration of the conference. =C2=BB VR: You cannot mandate replay protection without giving details on the = replay protection mechanism to use. Here you mention SRTP replay protection. If = you read the section you mention you=E2=80=99ll see that this replay = protection is not based on packet timing but a packet sequence number:=20 "When message authentication is provided, SRTP protects against = such attacks through a Replay List. =C2=BB and: "Packet indices which lag behind the packet index in the context by more than SRTP-WINDOW-SIZE can be assumed to have = been received=E2=80=A6 =C2=BB That=E2=80=99s totally different. If replay protection is a MUST, you = need to be very clear on what you expect from developers. >> ** Section 8.2.3 >> It is said that "a Media Distributor can select to not deliver a = particular >> stream for a while." That's perfectly true, yet is this a "Delayed = playout >> attack"? I'd rather call it a Media Distributor censorship attack, or = something >> along this line. The main idea behind the attack is not to delay a = stream but >> to censor a source. >=20 > This attack is not to censor, but to delay. For example, at time "T" = Bob might say "I agree with your proposal". However, the "evil" Media = Distributor could opt to not forward those packets and hold them. At = some time "T+delta", the Media Distributor then forwards them. The = receiving endpoint might not know that the packets were an hour old, so = the receiver Alice thinks Bob is agreeing with a proposal that Bob = actually doesn't agree with. >=20 > However, a censorship attack is also possible. But I think we covered = that in the Denial of Service section. The Media Distributor could = always elect to not forward, which is in effect censoring the = conversation. VR: delaying a packet when at the same time it is mandatory (i.e., MUST) = to "discard old packets beyond a small-to-modest jitter and network = re-ordering sized window =C2=BB means it will never be used. Hence the idea of =C2=AB censoring a source = =C2=BB. That being said, I don=E2=80=99t absolutely insist on using this term (censor) if you = feel uncomfortable with it. >> In the second paragraph I don't understand why it is said that: >> "the receiver believing that it is what was said just now, and = only >> delayed due to transport delay." >> Any RTP packet contains a timestamp (whose integrity is protected = end-to-end if >> I understand correctly), and this timestamp is used by the receiver = to identify >> timing issues. The fact a packet is delayed (significantly) by a = Media >> Distributor cannot be misinterpreted by a receiver as a "what was = said just >> now". The receiver immediately identifies this delay. >=20 > While that might be true, I'd guess most implementations would not = maintain this timing information for media held for a substantial period = of time. And media held for a short duration really might be considered = late only due to network delays. That actually does happen when network = congestion builds. So, short delays might easily be attributed to = network delays and long delays likely result in a "reset" of the flow at = the endpoint. I think all we can do here is provide a warning about = this, but I'm happy to make adjustments if you have specific words you = think would make this clearer. VR: please propose something, this is your document. >> I now understand the title ("delayed playout") but I really suspect = this is a >> mistake as (too much) delayed packets will not be played at all. >=20 > I bet they would :) Seriously, I have seen far stranger things. And = implementers might consider doing that as a "resilient" implementation. VR: you may be right if all packets are delayed, I agree. >> ** Section 8.2.4: >> I don't like the way this section is written. It first explains what = a Media >> Distributor could do if it could alter a certain header field (in = this case >> SSRC), it details the consequences, to finally explain that this is = not >> possible. This Security Discussion section is essentially meant to = discuss >> remaining security issues or highlight specific aspects, not what = could happen >> with a different, non secure, design. This text could also be written = the other >> way round: "By including the SSR field into the integrity check, PERC = prevents >> splicing attacks where...". >=20 > I assume you (and Ben) are looking to change that last sentence from = "not allowing" to "by including"? I'll change it that way, but if that = wasn't your meaning, please let me know. VR: no, I just don=E2=80=99t like (and I did the same comment above) the = way you introduce things, by explaining there=E2=80=99s a problem, and later explaining = there=E2=80=99s in fact no problem because it=E2=80=99s not possible. Please change it as suggested. >> ** Missing in 8.2 >> The RTCP flows are not encrypted end-to-end (unlike data flows) but = only >> hop-by-hop. Consequently, a malicious Media Distributors may corrupt = an RTCP >> packet content (e.g., reception statistics in RR) or forge malicious = RTCP >> packets which may trigger various effects at a sender. There are = other types of >> RTCP packets that may be attacked as well with various consequences. = None of >> this is explained in section 8.2. "Media Distributor Attacks". >=20 > This is true, though it wasn't a concern since the objective of PERC = was to secure the media E2E. Nonetheless, you're correct. How about this = as a new section called "RTCP attacks" under the Media Distributor = attacks section? >=20 > PERC does not provide end-to-end protection of RTCP messages. This = allows > a malicious Media Distributor to impact any message that might be = transmitted > via RTCP, including media statistics, picture requests, os loss = indication. > It is also possible for the Media Distributor to forge requests, such = as > requests to the endpoint to send a new picture. Such requests can = consume > significant bandwidth and impair conference performance. VR: yes, please add it. This is a significant limit of PERC and it needs = to be clarified. That=E2=80=99s also the goal of any Security Considerations section to = highlight limits. If you have another limit in mind, this is where it should go. That being said, can RTCP request the endpoint to send a new picture? Isn=E2=80=99t it an RTP packet rather than picture (I=E2=80=99m not = totally sure of it)? Additionally =C2=AB picture =C2=BB is anyway not appropriate here, =C2=AB = video frame =C2=BB is probably more adapted to video flows.=20 >> ** General comments about 8.1 and 8.2 >> Insider attacks are a powerful form of attacker model with severe = consequences. >> This is not a big surprise. I'd be more interesting in a detailed 8.1 = section, >> more likely to happen (weaker attacker model). >=20 > I'm not sure exactly what you're looking for. You want a new section = (e.g., 8.3) that details insider attacks or something related to each of = the existing 8.1/8.2 sections? Insider attacks could be disastrous, = definitely. They could range from anything from turning off the power to = stealing the KEKs stored in the Key Distributor. The latter is "scary" = in that, if a rogue individual were to steal the KEKs, he or she could = decrypt media off-line and at a later date. And, if the Key Distributor = stored the keys for a long time (e.g., so as to enable conference = recording and playback -- something not really considered on PERC, but = certainly implementable), then they could first capture the media flows = and then decrypt them a year later once they have access to the KEKs. = The two attacks do not have to carried out concurrently and there would = be no defense against theft of KEKs. >=20 > We could scare people with some words about keeping the Key = Distributor secure, but I'm not sure what we need to convey. VR: no, this is not what I mean. Attacks of section 8.1 seems more realistic to me than attacks of = section 8.2 because of a weaker attacker model: the attacker is outside of the systems, and = not necessarily on the path. Section 8.2 are all about attacks that are launched from a corrupted MD, = i.e., they are all some form of insider attacks. This is less likely. Therefore I would have liked to see more details in section 8.1, = that=E2=80=99s all.=20 [=E2=80=A6] >> Other comments: >>=20 >> ** Section 6, intro: (it's a detail, but...) >> I don't think that the use of "and so forth" is adequate in a = specification >> that aims to be exhaustive. The list of items addressed in section 6 = is >> finished. >=20 > Agreed. I'm just cut the sentence short: >=20 > "This section describes the various keys employed by PERC." >=20 > The sub-section titles are sufficient, I think. VR: Yes. Cheers, Vincent= From nobody Mon Feb 18 14:28:14 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81034131083; Mon, 18 Feb 2019 14:28:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mit.edu 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 Z5X7dLgd4Htw; Mon, 18 Feb 2019 14:28:01 -0800 (PST) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-eopbgr780109.outbound.protection.outlook.com [40.107.78.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7C1B131067; Mon, 18 Feb 2019 14:28:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Qigp7GQyQg67BsnYNrtsAJm70nAdE8JnndT/KaoUChk=; b=iJUu479yUWAInhKSyqLu9zcVyuBMO5tVhLDrY/qyGvuLtHpA7EJW0JVH3/DVysUvZyQwfpcVz8MZgGtu0IrwXXr9hyQOSHhK9s3UgsCgt08sc3Adn+yNTZAjuPcnRsTtpbsAD0fNt3QhHxGoMYHnMP2uaTpy42Sgt+ziNILwv9A= Received: from BYAPR01CA0031.prod.exchangelabs.com (2603:10b6:a02:80::44) by MN2PR01MB5614.prod.exchangelabs.com (2603:10b6:208:11c::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1622.16; Mon, 18 Feb 2019 22:27:59 +0000 Received: from DM3NAM03FT003.eop-NAM03.prod.protection.outlook.com (2a01:111:f400:7e49::203) by BYAPR01CA0031.outlook.office365.com (2603:10b6:a02:80::44) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1622.16 via Frontend Transport; Mon, 18 Feb 2019 22:27:59 +0000 Authentication-Results: spf=pass (sender IP is 18.9.28.11) smtp.mailfrom=mit.edu; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=mit.edu; Received-SPF: Pass (protection.outlook.com: domain of mit.edu designates 18.9.28.11 as permitted sender) receiver=protection.outlook.com; client-ip=18.9.28.11; helo=outgoing.mit.edu; Received: from outgoing.mit.edu (18.9.28.11) by DM3NAM03FT003.mail.protection.outlook.com (10.152.82.87) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1643.13 via Frontend Transport; Mon, 18 Feb 2019 22:27:58 +0000 Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x1IMRsJP027643 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 18 Feb 2019 17:27:56 -0500 Date: Mon, 18 Feb 2019 16:27:54 -0600 From: Benjamin Kaduk To: Richard Barnes CC: Hilarie Orman , , The IESG , secdir Message-ID: <20190218222754.GO24387@kduck.mit.edu> References: <201810312038.w9VKcZmV013489@rumpleteazer.rhmr.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:18.9.28.11; IPV:CAL; SCL:-1; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(136003)(346002)(376002)(396003)(39860400002)(2980300002)(51444003)(189003)(199004)(51914003)(356004)(336012)(16586007)(54906003)(8676002)(786003)(26005)(97756001)(58126008)(46406003)(106002)(36906005)(246002)(316002)(305945005)(186003)(76176011)(8936002)(7696005)(33656002)(126002)(53546011)(23726003)(426003)(956004)(476003)(446003)(2906002)(104016004)(53416004)(75432002)(1076003)(47776003)(14444005)(11346002)(6246003)(486006)(15650500001)(50466002)(88552002)(6916009)(4326008)(5660300002)(106466001)(229853002)(55016002)(86362001)(26826003)(478600001)(18370500001); DIR:OUT; SFP:1102; SCL:1; SRVR:MN2PR01MB5614; H:outgoing.mit.edu; FPR:; SPF:Pass; LANG:en; PTR:outgoing-auth-1.mit.edu; MX:1; A:1; X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 5e6c2ce6-c11c-4047-d306-08d695f05612 X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605104)(4608103)(4709054)(2017052603328)(7153060); SRVR:MN2PR01MB5614; X-MS-TrafficTypeDiagnostic: MN2PR01MB5614: X-Microsoft-Exchange-Diagnostics: 1; MN2PR01MB5614; 20:cG+9bvcFmlhib/z4EF6wm7/TcAGn7HoPjDkkEN0PYiOxX9871tfEYLz7Hk7cgzMs/nSrQtv91k5/L8sPakqHLr6XHODonVfBpknEOyjPY0a76Y5QyLL3CfxDCMuQX92P9A7n4kgYuvbskaSAuSSEQ7aBheUZNi1ZFBXuWvrz9h7hldk1TutbN+249or/mLCZyQUg7Ksx3EwNYa5SXRDFjSpqKQmnfJMszOIGc7j0DGiH/0Ap0mFm/Z8a7gZkhBEF2sSesOVp8F0/AgvMtlDCPzFbd2d6+n0CYrZBzC6wQIgWMEt5mLnXZxfe0Q+jEiawnzt/KLBo7smqregJFGmi1w/a+KyYm6IoiQvCiWqYEX20fnc306FD4iE4/4krR6Q400ZlYju71ao0HswrLioYkdM9JrvTb3yM4h1bgpi5EWoJAdjzJ9BsRM/5eOQvgp4R6O9tc8AgX4P6q5U/QhEqUtOCwc5wE1AYaCFAJ7m8o94yWeyDyoGsKgakwwFvSKPfoMVRBxh+p5f+wixOv1Ke6i3XNmxvPkXbQbAu5kkAQ6hc5RR7brCkch7PPwctpka6C8KoMSwhyQAJ+nESWKCYlaDZErZJ+SEbyve2xtS9ngg= X-Microsoft-Antispam-PRVS: X-Forefront-PRVS: 09525C61DB X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; MN2PR01MB5614; 23:FiJSbsSaao2y3F4w2t8JXFrLkoRHR3f1d3iu1ssza?= =?us-ascii?Q?Q2NxSpfq4bvLMFKzv+HWYmTl4KLWxP7wQK/IoD1+tSOqKiBbEjltkU/V2xRV?= =?us-ascii?Q?LySydtadxaeoXj+7eP/DVaUnFWVaMEgOKTr0Acw9ycEFwFEJIgj67LhfHAGa?= =?us-ascii?Q?rzyb0v9+Hj9CdD1SRunvCX9tpDyqgFSMuio4lo2C/ZhpLrdY2q3pKzFEJsdt?= =?us-ascii?Q?MSm6Uv+QyoKsxwn7qROhiNKmw3iAM19+av54u8EveOCBLdsIN9LCoUdq+G7N?= =?us-ascii?Q?zU+smAHCgkAj9s/06Q4O9NMTbrelJclZysG+sv3PJBZEf1PbsBGVr3GqKVxQ?= =?us-ascii?Q?2s2vFIuBwLzVb/gkPksqzq6/zNel9omNWBFxWQbMD3HuXAdKda1c/Fe46au3?= =?us-ascii?Q?J4h6S84AOhk7rlFdRnOF5X9vmifV6u283BZVn4h90bA3WnFIkgh0B2B29/eU?= =?us-ascii?Q?TDurqOmZZYKsDtwI3tRYtgyQ41Yn26xg8zzwhmU+Xd/sZAY75fn11OILc3wy?= =?us-ascii?Q?lSsfWSAPJ2KldRh1x+HZe+oa82edB5sGtFe60w5tFkNSUfYP+Ao89WzyKs0Y?= =?us-ascii?Q?U3LSRlJ5mHGN+EDS0VPPt7ZWhgthu3XeSHH8570dgubIDKGdk6PKkwblCoah?= =?us-ascii?Q?dooAoeGoUuyToa3Oa8NrGMTjPviHZ2UIBjZ6fcap4OEiwQfaWkJS3DyrgfZr?= =?us-ascii?Q?1hk1XimuprzCuQ32PBm7N80w4mSxIeE6oe6dDo0FmpiOKAVStifcq/eeUXH4?= =?us-ascii?Q?Jeiu10XxIYAYjyovraGSscT9uDM7of0rHJlSb9Hyl1g+tQQeo4StWMjtMMVT?= =?us-ascii?Q?AWZfXSDGtyx6QnYkgNcBHMvjNwjdpaSLtXVfY3C+r8p119Kt9f+PigiMDE8a?= =?us-ascii?Q?iod/LiCPUwbdQnNlxD0eOiG7tntr+k7pnZ/xed6ShTC9xGTdHRzZuTO4UDlk?= =?us-ascii?Q?60y4iT6d2lC4+v+Yr/p8zUFUz/efD+pndvy69dBBAe7Ffl97p39Ej4JrQWrV?= =?us-ascii?Q?f4oaJPfw7fHsOQj+an55RiJuEVbxseDpYoP6VBTfjcqQzXC1/JIjU4mur7QT?= =?us-ascii?Q?t7wCBwelbP9Zj2vGFQ3+qCXMch9pto4S+ERqzrNwielauPtDum2fT9IO7u/K?= =?us-ascii?Q?08hYJR6o03JBqJCWxUoSWMtwvnybZxmLtxRo7Zc7A5Jmu4rzwnJnbNeUtHfP?= =?us-ascii?Q?CQyz35m3SeZ6wsh9KrlvibDd9/uaXmW/EJl6SAQHSQqLOjLYN1O3pEYZeGl7?= =?us-ascii?Q?BV2VUmf9lhK29qc5z7F1LqTa2pNjCEEE7ZFbVYuOAGfmRZABPrbZU1G0nFRQ?= =?us-ascii?Q?lgFYOf5ECs3vjV7TLmhRf4=3D?= X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Message-Info: 6j0CFOi0PlWkQvYoOD3xlelrF8DOkpYOZX43Vg2/ltacIJFCRumBxYRoAV+x8QH39+VkF0x5a2rWljWAnW9QWAKj8gJbCgUnbwhcgVmaTcNlj39F2Y6irc8kfr23Vk3iVhwwndmon14QPEf11waxPmxavbBVUi2aVCWXpL61yOSPAh6jGT7X0vfUUuWcPHLd1oAduhELYWGtf75KIC8l4PFoERKuj/LmPpJBEGDUHlMNr0qRa7hc/76E52O+W4K8KBBq7URS5Ae9p9acPwkt7Dm8Y07ahitQUEHjwgkeTXZ+oA/Zpiy/IOIpZrVVjYJdn+WzWZGFlVEmpInXQAxMQ+psCd5U1K92n6GQBIjni66+DA/yL48pD8zO9aKYk2lVDe3h/hUtWQGzbvLbnE2SaezYTpnRKiIHH5WFA6leCQM= X-OriginatorOrg: mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Feb 2019 22:27:58.4562 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 5e6c2ce6-c11c-4047-d306-08d695f05612 X-MS-Exchange-CrossTenant-Id: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=64afd9ba-0ecf-4acf-bc36-935f6235ba8b; Ip=[18.9.28.11]; Helo=[outgoing.mit.edu] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR01MB5614 Archived-At: Subject: Re: [secdir] Security review of draft-ietf-perc-srtp-ekt-diet-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2019 22:28:07 -0000 On Wed, Dec 19, 2018 at 11:15:08AM -0500, Richard Barnes wrote: > Hi Hilarie, > > Thanks for the review. Sorry for the delay in responding. Responses > inline. > > On Wed, Oct 31, 2018 at 4:39 PM Hilarie Orman > wrote: > > > Security review of Encrypted Key Transport for DTLS and Secure RTP > > draft-ietf-perc-srtp-ekt-diet-08 > > > > Do not be alarmed. I have reviewed this document as part of the > > security directorate's ongoing effort to review all IETF documents > > being processed by the IESG. These comments were written primarily > > for the benefit of the security area directors. Document editors and > > WG chairs should treat these comments just like any other last call > > comments. > > > > The draft defines a way by which each sender in a multi-participant > > session can communicate its encrypting key (called a "master key") to > > the other participants. In this scheme, all participants learn a > > key encrypting key (EKTKey) that is used to protect sender's > > encrypting keys during transit. > > > > "This specification also defines a way to send the encrypted SRTP > > master key (with the EKTKey) along with the SRTP packet ... > > Endpoints that receive this and know the EKTKey can use the EKTKey > > to decrypt the SRTP master key which can then be used to decrypt > > the SRTP packet." > > > > I think that the paragraph above would be clearer if "(with the > > EKTkey)" were changed to "(encrypted with the EKTkey)". > > > > Ack, queued pending resolution of other topics here. (I don't see this in the -09; am I looking in the wrong place?) > > > > I do not understand the security model. If all participants know the > > EKTkey, then why do senders need to separately select their own > > individual keys? Cannot all participants use something derived from > > the EKTkey? Is this a legacy thing? > > > > Yes, it's precisely a legacy thing, in a couple of ways. The most > important one is that in the SRTP conferencing context, there's not really > an identifier that you can rely on being distinct per participant, so > basically you don't have a label to put into the KDF. A secondary > consideration (not required for PERC AFAIK) is that this allows keys from > external systems to be bridged into an EKT-enabled conference. > > If there were only the first concern, you could do something like use the > random value the endpoints make up as a KDF input (together with the master > key) instead of a key. But that would cut off the second use case, which I > would hesitate to do without some list discussion. > > Do you have a security concern here, or is this just a question for > understanding? I agree that there's some risk that endpoints will generate > bad keys, but it seems like if you're unable to generate good keys, you > have bigger problems. I guess there's a little bit more overhead in schlepping around more key material, but it's probably in the noise here. > > > > > Section 4.4 states that > > "EKT uses an authenticated cipher to encrypt and authenticate the > > EKTPlaintext." > > > > Also section 6 (security considerations) states: > > The EKT Cipher includes its own authentication/integrity check. For > > an attacker to successfully forge a FullEKTField, it would need to > > defeat the authentication mechanisms of the EKT Cipher authentication > > mechanism. > > > > Section 4.4.1 state "The default EKT Cipher is the Advanced Encryption > > Standard (AES) Key Wrap with Padding [RFC5649] algorithm." > > > > RFC5649 does not purport to define an authenticated cipher. I am not > > sure what properties of RFC5649 are the ones that are considered > > important, so I cannot recommend appropriate wording, though I suspect > > that "integrity" is the right word, not "authentication". > > > > What do you consider the difference between "integrity" and > "authentication" here? ISTM that these two are usually are very commonly > conflated at the crypto layer (vs. higher layers of authentication like > PKIs). For example, message *authentication* codes are a commonly used for > integrity protection. Yes ... but an "authentication mechanism" I would tend to expect to provide authentication that's strong enough to be useful for an authorization decision (i.e., binding to some name or other identity). > > > > I have one concern about the requirement that all senders change their > > keys when the EKTKey changes. Suppose a malicious participant manages > > to create a replay attack that sends a EKTkey message with a key that > > was previously used, perhaps even the same one that is currently used. > > This would force all participants to change their keys, perhaps at a > > very high rate, and this might lead to denial of service. > > Participants might be advised to ignore EKTkey messages that repeat > > the current EKTkey. > > > > This is a good idea. Queued pending resolution of other topics here. Thanks for that. -Benjamin From nobody Mon Feb 18 18:30:25 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00D70130E5D; Mon, 18 Feb 2019 18:30:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 46oC6nBCL3_w; Mon, 18 Feb 2019 18:30:22 -0800 (PST) Received: from mail-yw1-xc2d.google.com (mail-yw1-xc2d.google.com [IPv6:2607:f8b0:4864:20::c2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 948A2130E2E; Mon, 18 Feb 2019 18:30:19 -0800 (PST) Received: by mail-yw1-xc2d.google.com with SMTP id c67so7209972ywa.7; Mon, 18 Feb 2019 18:30:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=+Xxz5aDmgh7aDKNYeZfrsqtSV7Vlybzazjjkrc9YIZ4=; b=Uw5O/sFzU5tAZ5Ptbz/xbRrHsxlFlMwbfhx1KL2Y6cE6PkTqKju466nsXK07KGqsS+ R+a176T8HYFtkaMX6qPKQ9B26U3fAE/vEm0d5CHfIQn0lG3lxex4hhntFATXfV7gZ8GG qO1uEBhEqRPrkgf9egLqDNtcKjX4Kkwr7NSO6E3hKULIbWMB/JylusxDR8r/L9Ec7/WF qH/HFFu76K95ZkwjTFg7VGTSQ57L4IBxQsJcp4WcG0chlMWk125hV/uJ+dx4s0a+ZJmp sQP3zB+7Dl5mmK0aWDU55CCGjXzWPS/RpNSbMPLP9vHftDX8xcke1dC3w2olQm1uKQ3r n2zw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=+Xxz5aDmgh7aDKNYeZfrsqtSV7Vlybzazjjkrc9YIZ4=; b=oLcx//+S0fSF9PMAovu1GVuIiaXoPpEW860D4VvrUXMfON41PMGJUUKR8/Mi2Vyyf8 ZWacCifnkCsXkE1sSzRNbedJQGfYQzHj1Jpc+JqBfKoQqnT/BINYwthU0UIdaoJ+EFit aWpMKHLNRGvpaYoZZifN3sDGA7tKkTrWAYTYwAcB8y9m9nmfW+P1tWQfUHf//tlfnLbT PHoka2SxMxJECfL5VEQnJbYSt9y/DGaxC36U7sLXSrx7uhn8iu9DL5KcM/AIjonQH3KW xD5UAdAyKLU5DsNH9akrXb6h4sDZlPOTxY3cknz4on6uCUyZRdpt3SJ0ddf4ytCGHnj0 aa8Q== X-Gm-Message-State: AHQUAuYEDV3hMFnulaSXOPxHMAms+8Ah65xY0NAE8aOVgixOo2SX0Chk Bw211aA5YJGfsdhwskcEuPNiI4DzbTCa8cJPc4ebsQ== X-Google-Smtp-Source: AHgI3IZJxWMRPCEfxMCDKDvm9rrdfhmWat0L4wh26X/JpAXkbC8ov96iPjYGa1MoxLi3vHgc+UZnYnXeD/cDioz3yfw= X-Received: by 2002:a0d:d4c4:: with SMTP id w187mr21555643ywd.41.1550543418608; Mon, 18 Feb 2019 18:30:18 -0800 (PST) MIME-Version: 1.0 From: =?UTF-8?Q?Magnus_Nystr=C3=B6m?= Date: Mon, 18 Feb 2019 18:30:07 -0800 Message-ID: To: secdir@ietf.org, draft-ietf-jmap-mail@ietf.org Content-Type: multipart/alternative; boundary="000000000000acd203058236055b" Archived-At: Subject: [secdir] Secdir review of draft-ietf-jmap-mail-14 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2019 02:30:24 -0000 --000000000000acd203058236055b Content-Type: text/plain; charset="UTF-8" I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document defines a data model for mail over JMAP. JMAP is a JSON-based protocol for synchronization of data between clients and servers. - Section 9, the Security Considerations section, generally refers to draft-ietf-jmap-core for security considerations. I would agree with this. I wonder for a new protocol like this though, if TLS 1.3 should be required? - Also, for draft-ietf-jmap-core, it would be nice if Basic Auth could be disallowed for a new protocol like this - trying to move away from passwords - The rest of the Security Considerations section seems fine to me. - Editorial; Section 9.3: "Milter protocol" - I understand this is short-hand for "mail filter protocol," but perhaps this should be written out, maybe with some reference? I also could not find the term defined in draft-ietf-jmap-core. - Also in 9.3, should "the Milter protocol" be "a Milter protocol"? Not sure. Thanks. -- Magnus --000000000000acd203058236055b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I have reviewed this document as part of the security directorate's ong= oing effort to review all IETF documents being processed by the IESG. These= comments were written primarily for the benefit of the security area direc= tors.=C2=A0 Document editors and WG chairs should treat these comments just= like any other last call comments.

This document defines a data model for mail over JMAP. = JMAP is a JSON-based protocol for synchronization of data between clients a= nd servers.=20 
  • Section 9, the Security Consideratio=
ns section, generally refers to draft-ietf-jmap-core for security considera=
tions. I would agree with this. I wonder for a 
    new protocol like this t=
hough, if TLS 1.3 should be required?
  • Also, for draft-ietf-jmap-core, it would be nice if Basic Auth could be d=
isallowed for a new protocol like this - trying to move away from passwords=
  • The rest of the Security Considerations section seems fine to me. 
  • Editorial; Section 9.3: "M=
ilter protocol" - I understand this is short-hand for "mail filte=
r protocol," but perhaps this should be written out, maybe with somereference? I also could not find the term defined in draft-ietf-jmap-core=
.
  • Also in 9.3, should "the Milter protocol" be "a Milter pr= otocol"? Not sure.
Thanks.
-- Magnus

--000000000000acd203058236055b-- From nobody Mon Feb 18 22:50:56 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 624A2130E82; Mon, 18 Feb 2019 22:50:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.982 X-Spam-Level: X-Spam-Status: No, score=-1.982 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, MIME_HEADER_CTYPE_ONLY=0.717, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=dTQ9A/sZ; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=GAgggdKV 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 7QNWFhezgLeV; Mon, 18 Feb 2019 22:50:51 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9D8D130E7E; Mon, 18 Feb 2019 22:50:50 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 6D66523185; Tue, 19 Feb 2019 01:50:49 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Tue, 19 Feb 2019 01:50:49 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=message-id:in-reply-to:references:date:from :to:subject:content-type; s=fm2; bh=gYGohA0MR91crbbgF5qlLsxhs38o D7FcMUUwnY/I9mA=; b=dTQ9A/sZUk/9iTocffHtrvbb+8MC+eTziVYFSXdZxJlj f3KzRGrfjIJazzewRTN7ctfelweXLBpUk9b5Dzuqul9jhi6xm4+uSLrRI3V4osJH 2yKKOFuYKGwzYzyS/9TEWXfY8Ub4BUWoi/oNeFCIbSl913Q5ORN0SUS0bl/OQ43b UIAE8YEGV5W4F16baIM6R79ZEhLO6Iju/7J+rZVrwaJklLOEQFp3dAwH4Ip9os9A fC3ViGoxUe62iBypWSRf6HYPKcaODeiF7BWcSKELRdFubrf14q8kTnrjvSMOpPfY QNwdjBm2JQs6X5kGldI0ELND4jf/fvJCmw25231PKA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:references:subject:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=gYGohA0MR91crbbgF 5qlLsxhs38oD7FcMUUwnY/I9mA=; b=GAgggdKVxaz8Xhg1VEBpMRpNfPf5he6H0 6ey1V5Kr/jhukXLMCaZbWGPF8CqlAs5U22CrTYUokW/FA/r6/qUrmYSfqNwhgIwn 639SpsLqboomBQhARukf2LssO8Lj5If8fnZM49rXeruQroZ9pPozC1mQgh65g7KC 4c+WQc+f3USeWtHNjZOodmIbeqZVx5DRERyzhi9oHpWAnIa2L29lIfnf0UEvaI96 WDLIZb0fNDSP+92YaFlmMvHOfts36PvHglY1F2PSju2xDLNNMWosuGSwg1TMnown MLccgX/Eba8fd3yi4P+8K9VqG4/F8nlj93xdRM9vDrglnsCc2QZnQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedutddrtdefgddvfeculddtuddrgedtledrtddtmd cutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfkfgjfhffhffvufgtsegrtderreerreejnecuhfhrohhmpedfpfgvihhl ucflvghnkhhinhhsfdcuoehnvghilhhjsehfrghsthhmrghilhhtvggrmhdrtghomheqne cuffhomhgrihhnpehpohhsthhfihigrdhorhhgnecurfgrrhgrmhepmhgrihhlfhhrohhm pehnvghilhhjsehfrghsthhmrghilhhtvggrmhdrtghomhenucevlhhushhtvghrufhiii gvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 82FC92031F; Tue, 19 Feb 2019 01:50:48 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.5-895-g0d23ba6-fmstable-20190213v1 X-Me-Personality: 64588216 Message-Id: <8fbf4033-cf6b-407f-8d85-3b2d44ffc834@beta.fastmail.com> In-Reply-To: References: Date: Tue, 19 Feb 2019 01:50:47 -0500 From: "Neil Jenkins" To: secdir@ietf.org, draft-ietf-jmap-mail@ietf.org, =?UTF-8?Q?Magnus_Nystr=C3=B6m?= Content-Type: multipart/alternative; boundary=7259cc4cffff412e80742dcafdeefd14 Archived-At: Subject: Re: [secdir] Secdir review of draft-ietf-jmap-mail-14 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2019 06:50:53 -0000 --7259cc4cffff412e80742dcafdeefd14 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable On Tue, 19 Feb 2019, at 13:30, Magnus Nystr=C3=B6m wrote: > * Section 9, the Security Considerations section, generally refers to= draft-ietf-jmap-core for security considerations. I would agree with th= is. I wonder for a new protocol like this though, if TLS 1.3 should be r= equired? In response to Eric Rescorla's review, the draft has been updated to req= uire a minimum of TLS 1.2 and recommend at least TLS 1.3 =E2=80=93 I thi= nk this is reasonable given the current situation. > * Also, for draft-ietf-jmap-core, it would be nice if Basic Auth coul= d be disallowed for a new protocol like this - trying to move away from = passwords Nice in theory, but in practice it's really up to the vendors, and will = be used regardless of what you say in the spec. > * Editorial; Section 9.3: "Milter protocol" - I understand this is sh= ort-hand for "mail filter protocol," but perhaps this should be written = out, maybe with some reference? I've added an informative reference to http://www.postfix.org/MILTER_REA= DME.html. > * I also could not find the term defined in draft-ietf-jmap-core. This is a mail-specific thing, so not relevant to core. > * Also in 9.3, should "the Milter protocol" be "a Milter protocol"? N= ot sure. No, it's referring to a specific de-facto protocol; I think this is more= clear with the added reference. Cheers, Neil. --7259cc4cffff412e80742dcafdeefd14 Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
On Tue, 19= Feb 2019, at 13:30, Magnus Nystr=C3=B6m wrote:
  • Section 9, the Security Con=
siderations section, generally refers to draft-ietf-jmap-core for securi=
ty considerations. I would agree with this. I wonder for a new protocol =
like this though, if TLS 1.3 should be required?

In response = to Eric Rescorla's review, the draft has been updated to require a minim= um of TLS 1.2 and recommend at least TLS 1.3 =E2=80=93 I think this is r= easonable given the current situation.

  • Also, for draf=
t-ietf-jmap-core, it would be nice if Basic Auth could be disallowed for=
 a new protocol like this - trying to move away from passwords

Nice in theory, but in practice it's really up to the vendors, and wil= l be used regardless of what you say in the spec.

  • Edi= torial; Section 9.3: "Milter protocol" - I understand this is short-hand= for "mail filter protocol," but perhaps this should be written out, may= be with some reference?

I've added an informative reference to = ;http://www.postfi= x.org/MILTER_README.html.

  • I also could not find = the term defined in draft-ietf-jmap-core.

This is a mail-specific t= hing, so not relevant to core.

  • Also in 9.3, should "t= he Milter protocol" be "a Milter protocol"? Not sure.

No, it's refe= rring to a specific de-facto protocol; I think this is more clear with t= he added reference.

Cheers,
N= eil.
--7259cc4cffff412e80742dcafdeefd14-- From nobody Tue Feb 19 00:26:05 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E717124B0C; Tue, 19 Feb 2019 00:25:50 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Liang Xia To: Cc: sipbrandy@ietf.org, draft-ietf-sipbrandy-rtpsec.all@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.91.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155056475055.20764.380303220978816166@ietfa.amsl.com> Date: Tue, 19 Feb 2019 00:25:50 -0800 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-sipbrandy-rtpsec-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2019 08:25:51 -0000 Reviewer: Liang Xia Review result: Ready nits: 1. in Abstract: s/ media to SIP-layer identities / media layer to SIP layer identities / 2. in Section 4: User Agent Server (UAS) comments: Security Considerations: I suggest there can be more contents in this part, but it is not a blocking issue. From nobody Tue Feb 19 08:04:55 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A4A0130E77; Mon, 18 Feb 2019 20:49:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1550551761; bh=fLM4GiDy+mII/ZfmVEFZZBtJq/4enmKYcaH5aOeFne0=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=qwoqAq+EFzS/o6PJTQVoQbUOvB6PELUXB+OF4WacqekkmJ7S7RGeFLZ4h+psQG5LM prLiX9ztMu9FQjej68kfSzqOPLkGcPB1cdmObLORu6Njc08M5OkA64Xw69E+edJ+ux xxMeaCWs3mWq0o9Fwy9078cMBsliYyTvXEiopqIo= X-Mailbox-Line: From new-work-bounces@ietf.org Mon Feb 18 20:49:17 2019 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A4D6C131027; Mon, 18 Feb 2019 20:49:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1550551756; bh=fLM4GiDy+mII/ZfmVEFZZBtJq/4enmKYcaH5aOeFne0=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=guVzjBMXvJPU3+wv/b9p9geqKVao/eqNuS5itr3MKawUkqRI5ek1v/WtLfc7PE69Y 4wz7w38XS6Vg+XupHXPsMDTiR5QYdd6IOTXNe2wsT9ePw+mxVNdzC8wo6T8RttH/9E Q60V5SmYcl8UjhMlTtOT+bJ7V4zcUZZIzy2EOsnM= X-Original-To: new-work@ietf.org Delivered-To: new-work@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ABDD130E6D for ; Mon, 18 Feb 2019 20:49:08 -0800 (PST) MIME-Version: 1.0 From: The IESG To: X-Test-IDTracker: no X-IETF-IDTracker: 6.91.0 Auto-Submitted: auto-generated Precedence: bulk MIME-Version: 1.0 Reply_to: Message-ID: <155055174823.25950.11953954322952379120.idtracker@ietfa.amsl.com> Date: Mon, 18 Feb 2019 20:49:08 -0800 Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.29 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Tue, 19 Feb 2019 08:04:54 -0800 Subject: [secdir] [new-work] WG Review: Remote ATtestation ProcedureS (rats) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2019 04:49:26 -0000 A new IETF WG has been proposed in the Security Area. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by 2019-02-28. Remote ATtestation ProcedureS (rats) ----------------------------------------------------------------------- Current status: BOF WG Chairs: Nancy Cam-Winget Roman Danyliw Assigned Area Director: Benjamin Kaduk Security Area Directors: Eric Rescorla Benjamin Kaduk Mailing list: Address: rats@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/rats Archive: https://mailarchive.ietf.org/arch/browse/rats/ Group page: https://datatracker.ietf.org/group/rats/ Charter: https://datatracker.ietf.org/doc/charter-ietf-rats/ Introduction ========== In network protocol exchanges, it is often the case that one entity (a relying party) requires evidence about the remote peer (and system components [RFC4949] thereof), in order to assess the trustworthiness of the peer. Remote attestation procedures (RATS) enable relying parties to establish a level of confidence in the trustworthiness of remote system components through the creation of attestation evidence by remote system components and a processing chain towards the relying party. A relying party can then decide whether to consider a remote system component trustworthy or not. To improve the confidence in a system component's trustworthiness, a relying party may require evidence about: * system component identity, * composition of system components, including nested components, * roots of trust, * assertion/claim origination or provenance, * manufacturing origin, * system component integrity, * system component configuration, * operational state and measurements of steps which led to the operational state, or * other factors that could influence trust decisions. While domain-specific attestation mechanisms such as Trusted Computing Group (TCG) Trusted Platform Module (TPM)/Trusted Software Stack (TSS), Fast Identity Online (FIDO) Alliance attestation, and Android Keystore attestation exist, there is no interoperable way to create and process attestation evidence to make determinations about system components among relying parties of different manufactures and origins. Goals ===== This WG will standardize formats for describing assertions/claims about system components and associated evidence; and procedures and protocols to convey these assertions/claims to relying parties. Given the security and privacy sensitive nature of these assertions/claims, the WG will specify approaches to protect this exchanged data. While a relying party may use reference, known, or expected values or thresholds to assess the assertions/claims, the procedures for this activity are out of scope for this WG (without rechartering). The working group will cooperate and coordinate with other IETF WGs such as TEEP, SUIT, and SACM, and work with organizations in the community, such as the TCG and the FIDO Alliance, as appropriate. The WG will also evaluate prior work such as NEA and proprietary attestation technologies like the Android Keystore. Program of Work ============== The working group will develop standards supporting interoperable remote attestation procedures for system components. The main deliverables are as follows: 1. Specify use cases for remote attestation (to document and achieve WG consensus but not expected to be published as an RFC). 2. Specify terminology and architecture that enable attestation techniques. The architecture may include a system security model for the signing key material and involve at least the system component, system component provider, and the relying authority. 3. Standardize an information model for assertions/claims which provide information about system components characteristics scoped by the specified use-cases. 4. Standardize data models that implement and secure the defined information model (e.g., CBOR Web Token structures [RFC8392], JSON Web Token structures [RFC7519]). 5. Standardize interoperable protocols to securely convey assertions/claims. Milestones: TBD _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Tue Feb 19 19:58:54 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1F3212008F; Tue, 19 Feb 2019 19:58:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=packetizer.com 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 IrT9T7EWL0JN; Tue, 19 Feb 2019 19:58:32 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [IPv6:2600:1f18:24d6:2e01:e842:9b2b:72a2:d2c6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D28B412E7C1; Tue, 19 Feb 2019 19:58:26 -0800 (PST) Received: from authuser (localhost [127.0.0.1]) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1550635103; bh=VhjIrm8F9gBBDQCeqWxDZm4373SgaIW0EANYBIMT8MQ=; h=From:To:Subject:Cc:Date:In-Reply-To:References:Reply-To; b=JVPnQMbQ8OozXtDzi4SMY6+9ftoSiwdnYsq6278X1U7WzWPXF5LpRDKYSf14/6/M6 MYcLzM4mrz+yh+rTe6fU59rK/M5AAnNWlyZRyAiRsZpFNLyJj1pDBUF2J+gdgyLEAA M9HK+f0+/t1vkUOJpx43ERHPKYhvh3j6OjtVZOHM= From: "Paul E. Jones" To: "Vincent Roca" Cc: "Vincent Roca" , secdir@ietf.org, iesg@ietf.org, draft-ietf-perc-private-media-framework.all@ietf.org Date: Wed, 20 Feb 2019 03:58:20 +0000 Message-Id: In-Reply-To: <6882A552-80DF-4322-9683-13D8E655F2DB@inria.fr> References: <155014077570.26619.9407568904769535504@ietfa.amsl.com> <6882A552-80DF-4322-9683-13D8E655F2DB@inria.fr> Reply-To: "Paul E. Jones" User-Agent: eM_Client/7.2.34711.0 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------=_MB2EF963F0-AE1A-48B8-B3AD-1782977FA7D7" Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-perc-private-media-framework-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2019 03:58:38 -0000 --------=_MB2EF963F0-AE1A-48B8-B3AD-1782977FA7D7 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable Vincent, >>> The same comment applies to the remaining two paragraphs. I suggest th= e authors >>> explain that the proposal prevents an attacker to claim being a regula= r Media >>> Distributor and therefore to fool endpoints because ...". >> >> The "false Media Distributor" example could happen. For example, if a h= acker had access to the network where the Media Distributor is located and= claims the Media Distributor's address while the conference is operating, t= he endpoints might not know. However, the worst result of such an attack is = similar to just unplugging the box: packets just don't flow. The fake box= could attempt to forward packets it receives, but they would fail to authen= ticate at the receiving endpoints and be discarded. However, this false dev= ice could never gain access to the media and would not be given HBH keys si= nce it could not authenticate with the Key Distributor. > >VR: you=E2=80=99ve said that a false Media Distributor will fail to get ac= cess to the media >and fail to forward the traffic. In the original text, you also say that: > "They Key Distributor will fail > to establish the secure association with the endpoint if the Media > Distributor cannot be authenticated." >I agree that an attacker may try to impersonate a valid MD, but this attem= pt will >fail. And when you say that: > =C2=AB false Media Distributor may cascade to another legitimate Media > Distributor creating a false version of the real conference" >this is just wrong. The attacker won=E2=80=99t succeed. > >This is why I=E2=80=99m saying that you should re-write this part to say t= hat clearly that >thanks to the provided security mechanism, an attacker will fail to impers= onate >a MD. Don=E2=80=99t pretend attacks can succeed if this is not the case. OK, I've substantially re-worked this section. When version -09 is=20 published, hopefully it will look better. I'll try to get that out soon=20 and welcome further comments on that text. >>> ** Section 8.2.2. >>> Is the following sentence correct: >>> The mitigation for a replay attack is to prevent old packets beyond= a >>> small-to-modest jitter and network re-ordering sized window to be >>> rejected. >>> Is "prevent [...] to be rejected" correct? I'd say "... to be delivere= d" >>> instead. >> >> "prevent... rejected" is definitely an error. However, we cannot stop d= elivery. If replayed packets are received by either the Media Distributor o= r the endpoint, they should be discarded. So, perhaps this is better: >> >> "The mitigation for a replay attack is to discard old packets beyond a >> small-to-modest jitter and network re-ordering sized window. =C2=BB > >VR: Better, if we assume there's a timing based replay protection mechanis= m. >But the following item bellow indicates a totally different approach to re= play protection >(ID based rather than time based), hence a major contradiction in this tex= t. Please fix it. > >>> Another comment. Replay protection seems to be based on timing conside= rations >>> rather than on the use of unique sequence numbers that must not be rep= layed >>> (except if a wrapping to zero occurs of course). Is that correct? Addi= tionally, >>> is this mechanism carefully described in this document? Since it is ex= plained >>> that E2E replay protection MUST be provided, it's essential to be very = clear on >>> how to perform this. Failing to do so is a big issue. >> >> The mechanism underlying this is SRTP, which defines in 3.3.2/RFC3711 a= n "SRTP window size". We felt it was best to not introduce conflicting lang= uage. Perhaps we should just change the paragraph more substantially and re= fer to SRTP. >> >> Would you prefer this as the second paragraph? >> >> "The mitigation for a replay attack is to implement replay protection a= s >> described in Section 3.3.2 of [RFC3711]. >> End-to-end replay protection **MUST** be provided for the >> whole duration of the conference. =C2=BB > >VR: You cannot mandate replay protection without giving details on the rep= lay >protection mechanism to use. Here you mention SRTP replay protection. If y= ou >read the section you mention you=E2=80=99ll see that this replay protectio= n is not based >on packet timing but a packet sequence number: > "When message authentication is provided, SRTP protects against such atta= cks through a Replay List. =C2=BB >and: > "Packet indices which lag behind the packet index in the > context by more than SRTP-WINDOW-SIZE can be assumed to have bee= n > received=E2=80=A6 =C2=BB > >That=E2=80=99s totally different. If replay protection is a MUST, you need = to be very clear >on what you expect from developers. The previous text (that you referred to as timing-based) didn't go into=20 the document, but the text just above did. Rather than prescribe how to=20 do it, I think it's best to defer to 3.2.2 of RFC 3711. That is the way=20 to do it with SRTP, and PERC utilizes SRTP. We are not inventing any new=20 mechanisms. >>> ** Section 8.2.3 >>> It is said that "a Media Distributor can select to not deliver a parti= cular >>> stream for a while." That's perfectly true, yet is this a "Delayed pla= yout >>> attack"? I'd rather call it a Media Distributor censorship attack, or= something >>> along this line. The main idea behind the attack is not to delay a str= eam but >>> to censor a source. >> >> This attack is not to censor, but to delay. For example, at time "T" Bo= b might say "I agree with your proposal". However, the "evil" Media Distrib= utor could opt to not forward those packets and hold them. At some time "T+= delta", the Media Distributor then forwards them. The receiving endpoint mi= ght not know that the packets were an hour old, so the receiver Alice think= s Bob is agreeing with a proposal that Bob actually doesn't agree with. >> >> However, a censorship attack is also possible. But I think we covered t= hat in the Denial of Service section. The Media Distributor could always el= ect to not forward, which is in effect censoring the conversation. > >VR: delaying a packet when at the same time it is mandatory (i.e., MUST) t= o >"discard old packets beyond a small-to-modest jitter and network re-orderi= ng sized window =C2=BB >means it will never be used. Hence the idea of =C2=AB censoring a source = =C2=BB. That being said, >I don=E2=80=99t absolutely insist on using this term (censor) if you feel= uncomfortable with it. I prefer the current language (which I didn't author), as i find it very=20 descriptive. >>> In the second paragraph I don't understand why it is said that: >>> "the receiver believing that it is what was said just now, and= only >>> delayed due to transport delay." >>> Any RTP packet contains a timestamp (whose integrity is protected end-= to-end if >>> I understand correctly), and this timestamp is used by the receiver to = identify >>> timing issues. The fact a packet is delayed (significantly) by a Media >>> Distributor cannot be misinterpreted by a receiver as a "what was said = just >>> now". The receiver immediately identifies this delay. >> >> While that might be true, I'd guess most implementations would not main= tain this timing information for media held for a substantial period of tim= e. And media held for a short duration really might be considered late only = due to network delays. That actually does happen when network congestion b= uilds. So, short delays might easily be attributed to network delays and lo= ng delays likely result in a "reset" of the flow at the endpoint. I think a= ll we can do here is provide a warning about this, but I'm happy to make ad= justments if you have specific words you think would make this clearer. > >VR: please propose something, this is your document. I'm not really sure what to add. There's really nothing different here=20 than with any other RTP conference-- nothing unique to PERC, per se. If=20 I were to propose a solution, I think it's dangerous. Some codecs don't=20 necessarily create monotonically increasing timestamps. Some endpoints=20 don't have accurate clocks (sender or receiver), so drift can result in=20 miscalculations over time. I think it's good to note this issue, but=20 leave it for implementation. >>> ** Section 8.2.4: >>> I don't like the way this section is written. It first explains what a = Media >>> Distributor could do if it could alter a certain header field (in this = case >>> SSRC), it details the consequences, to finally explain that this is no= t >>> possible. This Security Discussion section is essentially meant to dis= cuss >>> remaining security issues or highlight specific aspects, not what coul= d happen >>> with a different, non secure, design. This text could also be written= the other >>> way round: "By including the SSR field into the integrity check, PERC= prevents >>> splicing attacks where...". >> >> I assume you (and Ben) are looking to change that last sentence from "n= ot allowing" to "by including"? I'll change it that way, but if that wasn't = your meaning, please let me know. > >VR: no, I just don=E2=80=99t like (and I did the same comment above) the w= ay you introduce >things, by explaining there=E2=80=99s a problem, and later explaining ther= e=E2=80=99s in fact no problem >because it=E2=80=99s not possible. Please change it as suggested. I did change it to include the sentence you suggested (it will be in the=20 -09), but we can come back to this if you want. This particular issue=20 could be ignored entirely, but as Ben noted this one getting a lot of=20 discussion. Yes, splicing attacks are mitigated, but the splicing attack=20 concept was introduced the way it was introduced, because the meaning=20 isn't immediately obvious. This text was originally authored by John=20 Mattsson: https://tools.ietf.org/html/draft-mattsson-perc-srtp-cloud-01#section-7.2.4 Of course, it changed a little as the entity names and solution to the=20 problem changed. It still has things in reverse order from what you=20 want, I think, but look at -09 when it is published shortly and tell me=20 if that's still objectionable. >>> ** Missing in 8.2 >>> The RTCP flows are not encrypted end-to-end (unlike data flows) but on= ly >>> hop-by-hop. Consequently, a malicious Media Distributors may corrupt a= n RTCP >>> packet content (e.g., reception statistics in RR) or forge malicious R= TCP >>> packets which may trigger various effects at a sender. There are other = types of >>> RTCP packets that may be attacked as well with various consequences. N= one of >>> this is explained in section 8.2. "Media Distributor Attacks". >> >> This is true, though it wasn't a concern since the objective of PERC wa= s to secure the media E2E. Nonetheless, you're correct. How about this as a = new section called "RTCP attacks" under the Media Distributor attacks sect= ion? >> >> PERC does not provide end-to-end protection of RTCP messages. This allo= ws >> a malicious Media Distributor to impact any message that might be trans= mitted >> via RTCP, including media statistics, picture requests, os loss indicat= ion. >> It is also possible for the Media Distributor to forge requests, such a= s >> requests to the endpoint to send a new picture. Such requests can consu= me >> significant bandwidth and impair conference performance. > >VR: yes, please add it. This is a significant limit of PERC and it needs t= o be clarified. >That=E2=80=99s also the goal of any Security Considerations section to hig= hlight limits. >If you have another limit in mind, this is where it should go. OK. I've added some text in a new section titled "RTCP attacks". >That being said, can RTCP request the endpoint to send a new picture? Yes >Isn=E2=80=99t it an RTP packet rather than picture (I=E2=80=99m not totall= y sure of it)? If a receiving device lost key packets and cannot reproduce an accurate=20 image, it will send a request for a new picture. On reception of a=20 picture request, the sender will send a new picture (i.e., the full=20 image that should be displayed on the screen), which will consume=20 several RTP packets for large images. >Additionally =C2=AB picture =C2=BB is anyway not appropriate here, =C2=AB= video frame =C2=BB is >probably more adapted to video flows. Years ago, this was called "video fast update" in H.323. In SIP, that=20 term is used, as is "Full Intra-frame Request" (FIR). Both avoided the=20 use of "frame" or "picture". On this subject, I was talking with Gary=20 Sullivan (chair of the group standardizing H.264, H.265, etc.) and he=20 suggested using the terms "I-picture" and "P-picture" (for another=20 document I was writing). Indeed, the term "picture" is used throughout=20 H.265, as is frame -- but they have different meaning. As he was=20 explaining, he also said: I did not use the word =E2=80=9Cframe=E2=80=9D above. It has a different me= aning than=20 =E2=80=9Cpicture=E2=80=9D. The difference is becoming less important over time, but if we want to be strict, we=20 should not use the terms casually. And with that, I was left perplexed as to what to use when. However, I=20 think we should take queues from the latest specs. In the H.265 RTP=20 payload format spec, there is a "picture loss indicator": https://tools.ietf.org/html/rfc7798#section-8.1 In section 8.4 of that spec it says, "Upon reception of a FIR, a sender=20 MUST send an IDR picture." And in https://tools.ietf.org/html/rfc4585#section-6.3.1.1 (from 2006)=20 the authors used "intra-picture". Anyway, that's the reason I used "picture". I think the issue is that=20 the meaning of these words have changed over time. That, or some folks=20 just prefer "picture" now. I don't know. >>> ** General comments about 8.1 and 8.2 >>> Insider attacks are a powerful form of attacker model with severe cons= equences. >>> This is not a big surprise. I'd be more interesting in a detailed 8.1= section, >>> more likely to happen (weaker attacker model). >> >> I'm not sure exactly what you're looking for. You want a new section (e= .g., 8.3) that details insider attacks or something related to each of the= existing 8.1/8.2 sections? Insider attacks could be disastrous, definitely. = They could range from anything from turning off the power to stealing the= KEKs stored in the Key Distributor. The latter is "scary" in that, if a rog= ue individual were to steal the KEKs, he or she could decrypt media off-lin= e and at a later date. And, if the Key Distributor stored the keys for a lo= ng time (e.g., so as to enable conference recording and playback -- somethi= ng not really considered on PERC, but certainly implementable), then they c= ould first capture the media flows and then decrypt them a year later once= they have access to the KEKs. The two attacks do not have to carried out co= ncurrently and there would be no defense against theft of KEKs. >> >> We could scare people with some words about keeping the Key Distributor = secure, but I'm not sure what we need to convey. > >VR: no, this is not what I mean. >Attacks of section 8.1 seems more realistic to me than attacks of section= 8.2 because >of a weaker attacker model: the attacker is outside of the systems, and no= t necessarily on >the path. >Section 8.2 are all about attacks that are launched from a corrupted MD, i= .e., they are >all some form of insider attacks. This is less likely. >Therefore I would have liked to see more details in section 8.1, that=E2= =80=99s all. In the interest of getting a new revision published so folks can provide=20 more input, I didn't add anything here. However, I'm happy to do so, but=20 I'm at a loss for what to add. If by "insider" you mean a rogue=20 individual manging the service elements (e.g., key distributor), I=20 definitely can see issues. However, I don't understand how that would=20 apply to third-party attacks. Maybe you mean something different for=20 "insider" than what I have in mind? If we share the same meaning, then=20 are you wondering what third parties can do if an insider helps=20 facilitate an attack (e.g., by stealing keys out of the KD and sending=20 them to some third-party hacker)? Paul --------=_MB2EF963F0-AE1A-48B8-B3AD-1782977FA7D7 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Vincent,

The same comment applies to the remaining tw= o paragraphs. I suggest the authors
explain that the proposal prevents an attacker t= o claim being a regular Media
Distributor and therefore to fool endpoints beca= use ...".
=C2=A0
The "false Media Distributor" example could happ= en. For example, if a hacker had access to the network where the Media Dist= ributor is located and claims the Media Distributor's address while the con= ference is operating, the endpoints might not know. However, the worst resu= lt of such an attack is similar to just unplugging the box: packets just do= n't flow. The fake box could attempt to forward packets it receives, but th= ey would fail to authenticate at the receiving endpoints and be discarded.= However, this false device could never gain access to the media and would n= ot be given HBH keys since it could not authenticate with the Key Distribut= or.
=C2=A0
VR: you=E2=80=99ve said that a false Media Distri= butor will fail to get access to the media
and fail to forward the traffic. In the original= text, you also say that:
"They Key Distributor will fail
to establish the secure association with the e= ndpoint if the Media
Distributor cannot be authenticated."
I agree that an attacker may try to impersonate a = valid MD, but this attempt will
fail. And when you say that:
=C2=AB false Media Distributor may cascade to a= nother legitimate Media
Distributor creating a false version of the re= al conference"
this is just wrong. The attacker won=E2=80=99t su= cceed.
=C2=A0
This is why I=E2=80=99m saying that you should re= -write this part to say that clearly that
thanks to the provided security mechanism, an att= acker will fail to impersonate
a MD. Don=E2=80=99t pretend attacks can succeed i= f this is not the case.
OK, I've substantially re-worked this= section. When version -09 is published, hopefully it will look better. I'= ll try to get that out soon and welcome further comments on that text.

** Section 8.2.2.
Is the following sentence correct:
The mitigation for a replay attack is to preve= nt old packets beyond a
small-to-modest jitter and network re-ordering = sized window to be
rejected.
Is "prevent [...] to be rejected" correct? I'd s= ay "... to be delivered"
instead.
=C2=A0
"prevent... rejected" is definitely an error. Ho= wever, we cannot stop delivery. If replayed packets are received by either= the Media Distributor or the endpoint, they should be discarded. So, perhap= s this is better:
=C2=A0
"The mitigation for a replay attack is to discar= d old packets beyond a
small-to-modest jitter and network re-ordering s= ized window. =C2=BB
=C2=A0
VR: Better, if we assume there's a timing based r= eplay protection mechanism.
But the following item bellow indicates a totally = different approach to replay protection
(ID based rather than time based), hence a major= contradiction in this text. Please fix it.
=C2=A0
Another comment. Replay protection seems to be b= ased on timing considerations
rather than on the use of unique sequence number= s that must not be replayed
(except if a wrapping to zero occurs of course). = Is that correct? Additionally,
is this mechanism carefully described in this do= cument? Since it is explained
that E2E replay protection MUST be provided, it'= s essential to be very clear on
how to perform this. Failing to do so is a big i= ssue.
=C2=A0
The mechanism underlying this is SRTP, which def= ines in 3.3.2/RFC3711 an "SRTP window size". We felt it was best to not int= roduce conflicting language. Perhaps we should just change the paragraph mo= re substantially and refer to SRTP.
=C2=A0
Would you prefer this as the second paragraph?
=C2=A0
"The mitigation for a replay attack is to implem= ent replay protection as
described in Section 3.3.2 of [RFC3711].
End-to-end replay protection **MUST** be provide= d for the
whole duration of the conference. =C2=BB
=C2=A0
VR: You cannot mandate replay protection without= giving details on the replay
protection mechanism to use. Here you mention SRT= P replay protection. If you
read the section you mention you=E2=80=99ll see t= hat this replay protection is not based
on packet timing but a packet sequence number:
"When message authentication is provided, SRTP p= rotects against such attacks through a Replay List. =C2=BB
and:
"Packet indices which lag behind the packet inde= x in the
context by more than SRTP-WINDOW-SIZE ca= n be assumed to have been
received=E2=80=A6 =C2=BB
=C2=A0
That=E2=80=99s totally different. If replay prote= ction is a MUST, you need to be very clear
on what you expect from developers.

= The previous text (that you referred to as timing-based) didn't go into the = document, but the text just above did. Rather than prescribe how to do it= , I think it's best to defer to 3.2.2 of RFC 3711. That is the way to do i= t with SRTP, and PERC utilizes SRTP. We are not inventing any new mechani= sms.

** Section 8.2.3
It is said that "a Media Distributor can select= to not deliver a particular
stream for a while." That's perfectly true, yet= is this a "Delayed playout
attack"? I'd rather call it a Media Distributor= censorship attack, or something
along this line. The main idea behind the attack = is not to delay a stream but
to censor a source.
=C2=A0
This attack is not to censor, but to delay. For= example, at time "T" Bob might say "I agree with your proposal". However, t= he "evil" Media Distributor could opt to not forward those packets and hold = them. At some time "T+delta", the Media Distributor then forwards them. Th= e receiving endpoint might not know that the packets were an hour old, so t= he receiver Alice thinks Bob is agreeing with a proposal that Bob actually= doesn't agree with.
=C2=A0
However, a censorship attack is also possible. B= ut I think we covered that in the Denial of Service section. The Media Dist= ributor could always elect to not forward, which is in effect censoring the = conversation.
=C2=A0
VR: delaying a packet when at the same time it is = mandatory (i.e., MUST) to
"discard old packets beyond a small-to-modest jit= ter and network re-ordering sized window =C2=BB
means it will never be used. Hence the idea of= =C2=AB censoring a source =C2=BB. That being said,
I don=E2=80=99t absolutely insist on using this t= erm (censor) if you feel uncomfortable with it.

I prefer the = current language (which I didn't author), as i find it very descriptive.
In the second paragraph I don't understand why it is said that:=
"the receiver believing that it is what w= as said just now, and only
delayed due to transport delay."
Any RTP packet contains a timestamp (whose integ= rity is protected end-to-end if
I understand correctly), and this timestamp is u= sed by the receiver to identify
timing issues. The fact a packet is delayed (sig= nificantly) by a Media
Distributor cannot be misinterpreted by a receiv= er as a "what was said just
now". The receiver immediately identifies this d= elay.
=C2=A0
While that might be true, I'd guess most impleme= ntations would not maintain this timing information for media held for a su= bstantial period of time. And media held for a short duration really might= be considered late only due to network delays. That actually does happen wh= en network congestion builds. So, short delays might easily be attributed t= o network delays and long delays likely result in a "reset" of the flow at= the endpoint. I think all we can do here is provide a warning about this, b= ut I'm happy to make adjustments if you have specific words you think would = make this clearer.
=C2=A0
VR: please propose something, this is your docume= nt.

I'm not really sure what to add. There's really nothing di= fferent here than with any other RTP conference-- nothing unique to PERC, p= er se. If I were to propose a solution, I think it's dangerous. Some codec= s don't necessarily create monotonically increasing timestamps. Some endpo= ints don't have accurate clocks (sender or receiver), so drift can result i= n miscalculations over time. I think it's good to note this issue, but le= ave it for implementation.

<= /div>
** Section 8.2.4:
I don't like the way this section is written. It = first explains what a Media
Distributor could do if it could alter a certain = header field (in this case
SSRC), it details the consequences, to finally e= xplain that this is not
possible. This Security Discussion section is es= sentially meant to discuss
remaining security issues or highlight specific= aspects, not what could happen
with a different, non secure, design. This text= could also be written the other
way round: "By including the SSR field into the= integrity check, PERC prevents
splicing attacks where...".
=C2=A0
I assume you (and Ben) are looking to change tha= t last sentence from "not allowing" to "by including"? I'll change it that= way, but if that wasn't your meaning, please let me know.
=C2=A0
VR: no, I just don=E2=80=99t like (and I did the= same comment above) the way you introduce
things, by explaining there=E2=80=99s a problem,= and later explaining there=E2=80=99s in fact no problem
because it=E2=80=99s not possible. Please change= it as suggested.

I did change it to include the sentence you s= uggested (it will be in the -09), but we can come back to this if you want= . This particular issue could be ignored entirely, but as Ben noted this o= ne getting a lot of discussion. Yes, splicing attacks are mitigated, but t= he splicing attack concept was introduced the way it was introduced, becaus= e the meaning isn't immediately obvious. This text was originally authored = by John Mattsson:
https://t= ools.ietf.org/html/draft-mattsson-perc-srtp-cloud-01#section-7.2.4
Of course= , it changed a little as the entity names and solution to the problem chang= ed. It still has things in reverse order from what you want, I think, but= look at -09 when it is published shortly and tell me if that's still object= ionable.

** Missing in 8.2<= /div>
The RTCP flows are not encrypted end-to-end (unl= ike data flows) but only
hop-by-hop. Consequently, a malicious Media Dist= ributors may corrupt an RTCP
packet content (e.g., reception statistics in RR= ) or forge malicious RTCP
packets which may trigger various effects at a s= ender. There are other types of
RTCP packets that may be attacked as well with v= arious consequences. None of
this is explained in section 8.2. "Media Distrib= utor Attacks".
=C2=A0
This is true, though it wasn't a concern since t= he objective of PERC was to secure the media E2E. Nonetheless, you're corre= ct. How about this as a new section called "RTCP attacks" under the Media D= istributor attacks section?
=C2=A0
PERC does not provide end-to-end protection of R= TCP messages. This allows
a malicious Media Distributor to impact any mess= age that might be transmitted
via RTCP, including media statistics, picture re= quests, os loss indication.
It is also possible for the Media Distributor to = forge requests, such as
requests to the endpoint to send a new picture.= Such requests can consume
significant bandwidth and impair conference perf= ormance.
=C2=A0
VR: yes, please add it. This is a significant lim= it of PERC and it needs to be clarified.
That=E2=80=99s also the goal of any Security Cons= iderations section to highlight limits.
If you have another limit in mind, this is where= it should go.

OK. I've added some text in a new section titled = "RTCP attacks".

That being said, can RTCP request the endpoint to send = a new picture?

=
Yes

Isn=E2=80=99t it an RTP packet rather= than picture (I=E2=80=99m not totally sure of it)?

If a receiv= ing device lost key packets and cannot reproduce an accurate image, it will = send a request for a new picture. On reception of a picture request, the= sender will send a new picture (i.e., the full image that should be display= ed on the screen), which will consume several RTP packets for large images.=

Additionally =C2=AB picture =C2=BB is anyway not appropriate here, =C2= =AB video frame =C2=BB is
probably more adapted to video flows.

Years ago, this was called "video fast update" in H.323. In SIP, that te= rm is used, as is "Full Intra-frame Request" (FIR). Both avoided the use o= f "frame" or "picture". On this subject, I was talking with Gary Sullivan = (chair of the group standardizing H.264, H.265, etc.) and he suggested usi= ng the terms "I-picture" and "P-picture" (for another document I was writin= g). Indeed, the term "picture" is used throughout H.265, as is frame -- bu= t they have different meaning. As he was explaining, he also said:

I d= id not use the word =E2=80=9Cframe=E2=80=9D above. It has a different meani= ng than =E2=80=9Cpicture=E2=80=9D. The difference
is becoming less important over time, but if we want=C2=A0 to= be strict, we should not use the terms
= casually.

And with that, I was left perplexed as to what to use when. Ho= wever, I think we should take queues from the latest specs. In the H.265 R= TP payload format spec, there is a "picture loss indicator":

In section 8.4 o= f that spec it says, "Upon reception of a FIR, a sender MUST send an IDR pi= cture."

And in https://tools.ietf.org/html/rfc4585#section-= 6.3.1.1 (from 2006) the authors used "intra-picture".

Anyway, that's th= e reason I used "picture". I think the issue is that the meaning of these= words have changed over time. That, or some folks just prefer "picture" no= w. I don't know.

** General = comments about 8.1 and 8.2
Insider attacks are a powerful form of attacker= model with severe consequences.
This is not a big surprise. I'd be more interest= ing in a detailed 8.1 section,
more likely to happen (weaker attacker model).
=C2=A0
I'm not sure exactly what you're looking for. Yo= u want a new section (e.g., 8.3) that details insider attacks or something= related to each of the existing 8.1/8.2 sections? Insider attacks could be= disastrous, definitely. They could range from anything from turning off the = power to stealing the KEKs stored in the Key Distributor. The latter is "s= cary" in that, if a rogue individual were to steal the KEKs, he or she coul= d decrypt media off-line and at a later date. And, if the Key Distributor s= tored the keys for a long time (e.g., so as to enable conference recording= and playback -- something not really considered on PERC, but certainly impl= ementable), then they could first capture the media flows and then decrypt= them a year later once they have access to the KEKs. The two attacks do not = have to carried out concurrently and there would be no defense against the= ft of KEKs.
=C2=A0
We could scare people with some words about keep= ing the Key Distributor secure, but I'm not sure what we need to convey.
=C2=A0
VR: no, this is not what I mean.
Attacks of section 8.1 seems more realistic to me = than attacks of section 8.2 because
of a weaker attacker model: the attacker is outsi= de of the systems, and not necessarily on
the path.
Section 8.2 are all about attacks that are launch= ed from a corrupted MD, i.e., they are
all some form of insider attacks. This is less li= kely.
Therefore I would have liked to see more details= in section 8.1, that=E2=80=99s all.

In the interest of getting = a new revision published so folks can provide more input, I didn't add any= thing here. However, I'm happy to do so, but I'm at a loss for what to add= . If by "insider" you mean a rogue individual manging the service elements = (e.g., key distributor), I definitely can see issues. However, I don't un= derstand how that would apply to third-party attacks. Maybe you mean somet= hing different for "insider" than what I have in mind? If we share the sam= e meaning, then are you wondering what third parties can do if an insider h= elps facilitate an attack (e.g., by stealing keys out of the KD and sending = them to some third-party hacker)?

=
Paul
<= br />
--------=_MB2EF963F0-AE1A-48B8-B3AD-1782977FA7D7-- From nobody Tue Feb 19 23:13:57 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61B1112DD85; Tue, 19 Feb 2019 23:13:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 KlyHlZy7OZQi; Tue, 19 Feb 2019 23:13:45 -0800 (PST) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 763C6127287; Tue, 19 Feb 2019 23:13:44 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.58,388,1544482800"; d="scan'208,217";a="370117659" Received: from dom38-1-82-236-155-50.fbx.proxad.net (HELO [192.168.1.111]) ([82.236.155.50]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Feb 2019 08:13:42 +0100 From: Vincent Roca Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_14CEBCAF-E510-416B-B875-098F0C576BFF" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Wed, 20 Feb 2019 08:13:41 +0100 In-Reply-To: Cc: Vincent Roca , secdir@ietf.org, iesg@ietf.org, draft-ietf-perc-private-media-framework.all@ietf.org To: "Paul E. Jones" References: <155014077570.26619.9407568904769535504@ietfa.amsl.com> <6882A552-80DF-4322-9683-13D8E655F2DB@inria.fr> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-perc-private-media-framework-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2019 07:13:49 -0000 --Apple-Mail=_14CEBCAF-E510-416B-B875-098F0C576BFF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello Paul, Thanks for your answer and long explanations on the use of term =C2=AB = picture =C2=BB. I was not aware of this evolution of vocabulary. Yes, please submit -09 version and I=E2=80=99ll = have a new look at it. Cheers, Vincent > Le 20 f=C3=A9vr. 2019 =C3=A0 04:58, Paul E. Jones = a =C3=A9crit : >=20 > Vincent, >=20 >>>> The same comment applies to the remaining two paragraphs. I suggest = the authors >>>> explain that the proposal prevents an attacker to claim being a = regular Media >>>> Distributor and therefore to fool endpoints because ...". >>> =20 >>> The "false Media Distributor" example could happen. For example, if = a hacker had access to the network where the Media Distributor is = located and claims the Media Distributor's address while the conference = is operating, the endpoints might not know. However, the worst result of = such an attack is similar to just unplugging the box: packets just don't = flow. The fake box could attempt to forward packets it receives, but = they would fail to authenticate at the receiving endpoints and be = discarded. However, this false device could never gain access to the = media and would not be given HBH keys since it could not authenticate = with the Key Distributor. >> =20 >> VR: you=E2=80=99ve said that a false Media Distributor will fail to = get access to the media >> and fail to forward the traffic. In the original text, you also say = that: >> "They Key Distributor will fail >> to establish the secure association with the endpoint if the Media >> Distributor cannot be authenticated." >> I agree that an attacker may try to impersonate a valid MD, but this = attempt will >> fail. And when you say that: >> =C2=AB false Media Distributor may cascade to another legitimate = Media >> Distributor creating a false version of the real conference" >> this is just wrong. The attacker won=E2=80=99t succeed. >> =20 >> This is why I=E2=80=99m saying that you should re-write this part to = say that clearly that >> thanks to the provided security mechanism, an attacker will fail to = impersonate >> a MD. Don=E2=80=99t pretend attacks can succeed if this is not the = case. >=20 > OK, I've substantially re-worked this section. When version -09 is = published, hopefully it will look better. I'll try to get that out soon = and welcome further comments on that text. >=20 >=20 >>>> ** Section 8.2.2. >>>> Is the following sentence correct: >>>> The mitigation for a replay attack is to prevent old packets beyond = a >>>> small-to-modest jitter and network re-ordering sized window to be >>>> rejected. >>>> Is "prevent [...] to be rejected" correct? I'd say "... to be = delivered" >>>> instead. >>> =20 >>> "prevent... rejected" is definitely an error. However, we cannot = stop delivery. If replayed packets are received by either the Media = Distributor or the endpoint, they should be discarded. So, perhaps this = is better: >>> =20 >>> "The mitigation for a replay attack is to discard old packets beyond = a >>> small-to-modest jitter and network re-ordering sized window. =C2=BB >> =20 >> VR: Better, if we assume there's a timing based replay protection = mechanism. >> But the following item bellow indicates a totally different approach = to replay protection >> (ID based rather than time based), hence a major contradiction in = this text. Please fix it. >> =20 >>>> Another comment. Replay protection seems to be based on timing = considerations >>>> rather than on the use of unique sequence numbers that must not be = replayed >>>> (except if a wrapping to zero occurs of course). Is that correct? = Additionally, >>>> is this mechanism carefully described in this document? Since it is = explained >>>> that E2E replay protection MUST be provided, it's essential to be = very clear on >>>> how to perform this. Failing to do so is a big issue. >>> =20 >>> The mechanism underlying this is SRTP, which defines in = 3.3.2/RFC3711 an "SRTP window size". We felt it was best to not = introduce conflicting language. Perhaps we should just change the = paragraph more substantially and refer to SRTP. >>> =20 >>> Would you prefer this as the second paragraph? >>> =20 >>> "The mitigation for a replay attack is to implement replay = protection as >>> described in Section 3.3.2 of [RFC3711]. >>> End-to-end replay protection **MUST** be provided for the >>> whole duration of the conference. =C2=BB >> =20 >> VR: You cannot mandate replay protection without giving details on = the replay >> protection mechanism to use. Here you mention SRTP replay protection. = If you >> read the section you mention you=E2=80=99ll see that this replay = protection is not based >> on packet timing but a packet sequence number: >> "When message authentication is provided, SRTP protects against such = attacks through a Replay List. =C2=BB >> and: >> "Packet indices which lag behind the packet index in the >> context by more than SRTP-WINDOW-SIZE can be assumed to have been >> received=E2=80=A6 =C2=BB >> =20 >> That=E2=80=99s totally different. If replay protection is a MUST, you = need to be very clear >> on what you expect from developers. >=20 > The previous text (that you referred to as timing-based) didn't go = into the document, but the text just above did. Rather than prescribe = how to do it, I think it's best to defer to 3.2.2 of RFC 3711. That is = the way to do it with SRTP, and PERC utilizes SRTP. We are not inventing = any new mechanisms. >=20 >>>> ** Section 8.2.3 >>>> It is said that "a Media Distributor can select to not deliver a = particular >>>> stream for a while." That's perfectly true, yet is this a "Delayed = playout >>>> attack"? I'd rather call it a Media Distributor censorship attack, = or something >>>> along this line. The main idea behind the attack is not to delay a = stream but >>>> to censor a source. >>> =20 >>> This attack is not to censor, but to delay. For example, at time "T" = Bob might say "I agree with your proposal". However, the "evil" Media = Distributor could opt to not forward those packets and hold them. At = some time "T+delta", the Media Distributor then forwards them. The = receiving endpoint might not know that the packets were an hour old, so = the receiver Alice thinks Bob is agreeing with a proposal that Bob = actually doesn't agree with. >>> =20 >>> However, a censorship attack is also possible. But I think we = covered that in the Denial of Service section. The Media Distributor = could always elect to not forward, which is in effect censoring the = conversation. >> =20 >> VR: delaying a packet when at the same time it is mandatory (i.e., = MUST) to >> "discard old packets beyond a small-to-modest jitter and network = re-ordering sized window =C2=BB >> means it will never be used. Hence the idea of =C2=AB censoring a = source =C2=BB. That being said, >> I don=E2=80=99t absolutely insist on using this term (censor) if you = feel uncomfortable with it. >=20 > I prefer the current language (which I didn't author), as i find it = very descriptive. >=20 >>>> In the second paragraph I don't understand why it is said that: >>>> "the receiver believing that it is what was said just now, and only >>>> delayed due to transport delay." >>>> Any RTP packet contains a timestamp (whose integrity is protected = end-to-end if >>>> I understand correctly), and this timestamp is used by the receiver = to identify >>>> timing issues. The fact a packet is delayed (significantly) by a = Media >>>> Distributor cannot be misinterpreted by a receiver as a "what was = said just >>>> now". The receiver immediately identifies this delay. >>> =20 >>> While that might be true, I'd guess most implementations would not = maintain this timing information for media held for a substantial period = of time. And media held for a short duration really might be considered = late only due to network delays. That actually does happen when network = congestion builds. So, short delays might easily be attributed to = network delays and long delays likely result in a "reset" of the flow at = the endpoint. I think all we can do here is provide a warning about = this, but I'm happy to make adjustments if you have specific words you = think would make this clearer. >> =20 >> VR: please propose something, this is your document. >=20 > I'm not really sure what to add. There's really nothing different here = than with any other RTP conference-- nothing unique to PERC, per se. If = I were to propose a solution, I think it's dangerous. Some codecs don't = necessarily create monotonically increasing timestamps. Some endpoints = don't have accurate clocks (sender or receiver), so drift can result in = miscalculations over time. I think it's good to note this issue, but = leave it for implementation. >=20 >>>> ** Section 8.2.4: >>>> I don't like the way this section is written. It first explains = what a Media >>>> Distributor could do if it could alter a certain header field (in = this case >>>> SSRC), it details the consequences, to finally explain that this is = not >>>> possible. This Security Discussion section is essentially meant to = discuss >>>> remaining security issues or highlight specific aspects, not what = could happen >>>> with a different, non secure, design. This text could also be = written the other >>>> way round: "By including the SSR field into the integrity check, = PERC prevents >>>> splicing attacks where...". >>> =20 >>> I assume you (and Ben) are looking to change that last sentence from = "not allowing" to "by including"? I'll change it that way, but if that = wasn't your meaning, please let me know. >> =20 >> VR: no, I just don=E2=80=99t like (and I did the same comment above) = the way you introduce >> things, by explaining there=E2=80=99s a problem, and later explaining = there=E2=80=99s in fact no problem >> because it=E2=80=99s not possible. Please change it as suggested. >=20 > I did change it to include the sentence you suggested (it will be in = the -09), but we can come back to this if you want. This particular = issue could be ignored entirely, but as Ben noted this one getting a lot = of discussion. Yes, splicing attacks are mitigated, but the splicing = attack concept was introduced the way it was introduced, because the = meaning isn't immediately obvious. This text was originally authored by = John Mattsson: > = https://tools.ietf.org/html/draft-mattsson-perc-srtp-cloud-01#section-7.2.= 4 = > Of course, it changed a little as the entity names and solution to the = problem changed. It still has things in reverse order from what you = want, I think, but look at -09 when it is published shortly and tell me = if that's still objectionable. >=20 >>>> ** Missing in 8.2 >>>> The RTCP flows are not encrypted end-to-end (unlike data flows) but = only >>>> hop-by-hop. Consequently, a malicious Media Distributors may = corrupt an RTCP >>>> packet content (e.g., reception statistics in RR) or forge = malicious RTCP >>>> packets which may trigger various effects at a sender. There are = other types of >>>> RTCP packets that may be attacked as well with various = consequences. None of >>>> this is explained in section 8.2. "Media Distributor Attacks". >>> =20 >>> This is true, though it wasn't a concern since the objective of PERC = was to secure the media E2E. Nonetheless, you're correct. How about this = as a new section called "RTCP attacks" under the Media Distributor = attacks section? >>> =20 >>> PERC does not provide end-to-end protection of RTCP messages. This = allows >>> a malicious Media Distributor to impact any message that might be = transmitted >>> via RTCP, including media statistics, picture requests, os loss = indication. >>> It is also possible for the Media Distributor to forge requests, = such as >>> requests to the endpoint to send a new picture. Such requests can = consume >>> significant bandwidth and impair conference performance. >> =20 >> VR: yes, please add it. This is a significant limit of PERC and it = needs to be clarified. >> That=E2=80=99s also the goal of any Security Considerations section = to highlight limits. >> If you have another limit in mind, this is where it should go. >=20 > OK. I've added some text in a new section titled "RTCP attacks". >=20 >> That being said, can RTCP request the endpoint to send a new picture? >=20 > Yes >=20 >> Isn=E2=80=99t it an RTP packet rather than picture (I=E2=80=99m not = totally sure of it)? >=20 > If a receiving device lost key packets and cannot reproduce an = accurate image, it will send a request for a new picture. On reception = of a picture request, the sender will send a new picture (i.e., the full = image that should be displayed on the screen), which will consume = several RTP packets for large images. >=20 >> Additionally =C2=AB picture =C2=BB is anyway not appropriate here, =C2=AB= video frame =C2=BB is >> probably more adapted to video flows. >=20 > Years ago, this was called "video fast update" in H.323. In SIP, that = term is used, as is "Full Intra-frame Request" (FIR). Both avoided the = use of "frame" or "picture". On this subject, I was talking with Gary = Sullivan (chair of the group standardizing H.264, H.265, etc.) and he = suggested using the terms "I-picture" and "P-picture" (for another = document I was writing). Indeed, the term "picture" is used throughout = H.265, as is frame -- but they have different meaning. As he was = explaining, he also said: >=20 > I did not use the word =E2=80=9Cframe=E2=80=9D above. It has a = different meaning than =E2=80=9Cpicture=E2=80=9D. The difference > is becoming less important over time, but if we want to be strict, we = should not use the terms > casually. >=20 > And with that, I was left perplexed as to what to use when. However, I = think we should take queues from the latest specs. In the H.265 RTP = payload format spec, there is a "picture loss indicator": > https://tools.ietf.org/html/rfc7798#section-8.1 = >=20 > In section 8.4 of that spec it says, "Upon reception of a FIR, a = sender MUST send an IDR picture." >=20 > And in https://tools.ietf.org/html/rfc4585#section-6.3.1.1 = (from 2006) the = authors used "intra-picture". >=20 > Anyway, that's the reason I used "picture". I think the issue is that = the meaning of these words have changed over time. That, or some folks = just prefer "picture" now. I don't know. >=20 >>>> ** General comments about 8.1 and 8.2 >>>> Insider attacks are a powerful form of attacker model with severe = consequences. >>>> This is not a big surprise. I'd be more interesting in a detailed = 8.1 section, >>>> more likely to happen (weaker attacker model). >>> =20 >>> I'm not sure exactly what you're looking for. You want a new section = (e.g., 8.3) that details insider attacks or something related to each of = the existing 8.1/8.2 sections? Insider attacks could be disastrous, = definitely. They could range from anything from turning off the power to = stealing the KEKs stored in the Key Distributor. The latter is "scary" = in that, if a rogue individual were to steal the KEKs, he or she could = decrypt media off-line and at a later date. And, if the Key Distributor = stored the keys for a long time (e.g., so as to enable conference = recording and playback -- something not really considered on PERC, but = certainly implementable), then they could first capture the media flows = and then decrypt them a year later once they have access to the KEKs. = The two attacks do not have to carried out concurrently and there would = be no defense against theft of KEKs. >>> =20 >>> We could scare people with some words about keeping the Key = Distributor secure, but I'm not sure what we need to convey. >> =20 >> VR: no, this is not what I mean. >> Attacks of section 8.1 seems more realistic to me than attacks of = section 8.2 because >> of a weaker attacker model: the attacker is outside of the systems, = and not necessarily on >> the path. >> Section 8.2 are all about attacks that are launched from a corrupted = MD, i.e., they are >> all some form of insider attacks. This is less likely. >> Therefore I would have liked to see more details in section 8.1, = that=E2=80=99s all. >=20 > In the interest of getting a new revision published so folks can = provide more input, I didn't add anything here. However, I'm happy to do = so, but I'm at a loss for what to add. If by "insider" you mean a rogue = individual manging the service elements (e.g., key distributor), I = definitely can see issues. However, I don't understand how that would = apply to third-party attacks. Maybe you mean something different for = "insider" than what I have in mind? If we share the same meaning, then = are you wondering what third parties can do if an insider helps = facilitate an attack (e.g., by stealing keys out of the KD and sending = them to some third-party hacker)? >=20 > Paul --Apple-Mail=_14CEBCAF-E510-416B-B875-098F0C576BFF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hello= Paul,

Thanks for = your answer and long explanations on the use of term = =C2=AB picture =C2=BB. I was not aware of this
evolution of vocabulary. Yes, please submit -09 version and = I=E2=80=99ll have a new look at it.

  Cheers,

  Vincent

Le 20 f=C3=A9vr. 2019 =C3=A0 04:58, Paul E. = Jones <paulej@packetizer.com> a =C3=A9crit :

Vincent,

The same comment applies to the remaining two = paragraphs. I suggest the authors
explain = that the proposal prevents an attacker to claim being a regular = Media
Distributor and therefore to fool = endpoints because ...".
 
The "false = Media Distributor" example could happen. For example, if a hacker had = access to the network where the Media Distributor is located and claims = the Media Distributor's address while the conference is operating, the = endpoints might not know. However, the worst result of such an attack is = similar to just unplugging the box: packets just don't flow. The fake = box could attempt to forward packets it receives, but they would fail to = authenticate at the receiving endpoints and be discarded. However, this = false device could never gain access to the media and would not be given = HBH keys since it could not authenticate with the Key = Distributor.
 
VR: you=E2=80=99ve said that a false Media = Distributor will fail to get access to the media
and fail to forward the traffic. In the original = text, you also say that:
"They Key = Distributor will fail
to establish the = secure association with the endpoint if the Media
Distributor cannot be authenticated."
I agree that an attacker may try to impersonate a = valid MD, but this attempt will
fail. And = when you say that:
=C2=AB false Media = Distributor may cascade to another legitimate Media
Distributor creating a false version of the real = conference"
this is just wrong. The = attacker won=E2=80=99t succeed.
 
This is why = I=E2=80=99m saying that you should re-write this part to say that = clearly that
thanks to the provided = security mechanism, an attacker will fail to impersonate
a MD. Don=E2=80=99t pretend attacks can succeed if = this is not the case.

OK, I've substantially re-worked this section. When version = -09 is published, hopefully it will look better. I'll try to get that = out soon and welcome further comments on that text.


** Section 8.2.2.
Is = the following sentence correct:
The = mitigation for a replay attack is to prevent old packets beyond = a
small-to-modest jitter and network = re-ordering sized window to be
rejected.
Is = "prevent [...] to be rejected" correct? I'd say "... to be = delivered"
instead.
 
"prevent... = rejected" is definitely an error. However, we cannot stop delivery. If = replayed packets are received by either the Media Distributor or the = endpoint, they should be discarded. So, perhaps this is = better:
 
"The mitigation for a replay attack is to discard = old packets beyond a
small-to-modest = jitter and network re-ordering sized window. =C2=BB
 
VR: Better, = if we assume there's a timing based replay protection = mechanism.
But the following item bellow = indicates a totally different approach to replay protection
(ID based rather than time based), hence a major = contradiction in this text. Please fix it.
 
Another comment. Replay = protection seems to be based on timing considerations
rather than on the use of unique sequence numbers = that must not be replayed
(except if a = wrapping to zero occurs of course). Is that correct? = Additionally,
is this mechanism carefully = described in this document? Since it is explained
that E2E replay protection MUST be provided, it's = essential to be very clear on
how to = perform this. Failing to do so is a big issue.
 
The mechanism = underlying this is SRTP, which defines in 3.3.2/RFC3711 an "SRTP window = size". We felt it was best to not introduce conflicting language. = Perhaps we should just change the paragraph more substantially and refer = to SRTP.
 
Would you prefer this as the second = paragraph?
 
"The mitigation for a replay attack is to implement = replay protection as
described in Section = 3.3.2 of [RFC3711].
End-to-end replay = protection **MUST** be provided for the
whole duration of the conference. = =C2=BB
 
VR: You cannot mandate replay protection without = giving details on the replay
protection = mechanism to use. Here you mention SRTP replay protection. If = you
read the section you mention you=E2=80=99= ll see that this replay protection is not based
on packet timing but a packet sequence = number:
"When message authentication is = provided, SRTP protects against such attacks through a Replay List. = =C2=BB
and:
"Packet indices which lag behind the packet index = in the
context by more than = SRTP-WINDOW-SIZE can be assumed to have been
received=E2=80=A6 =C2=BB
 
That=E2=80=99s = totally different. If replay protection is a MUST, you need to be very = clear
on what you expect from = developers.

The previous = text (that you referred to as timing-based) didn't go into the document, = but the text just above did. Rather than prescribe how to do it, I think = it's best to defer to 3.2.2 of RFC 3711. That is the way to do it with = SRTP, and PERC utilizes SRTP. We are not inventing any new = mechanisms.

** Section 8.2.3
It = is said that "a Media Distributor can select to not deliver a = particular
stream for a while." That's = perfectly true, yet is this a "Delayed playout
attack"? I'd rather call it a Media Distributor = censorship attack, or something
along = this line. The main idea behind the attack is not to delay a stream = but
to censor a = source.
 
This attack is not to censor, but to delay. For = example, at time "T" Bob might say "I agree with your proposal". = However, the "evil" Media Distributor could opt to not forward those = packets and hold them. At some time "T+delta", the Media Distributor = then forwards them. The receiving endpoint might not know that the = packets were an hour old, so the receiver Alice thinks Bob is agreeing = with a proposal that Bob actually doesn't agree with.
 
However, a = censorship attack is also possible. But I think we covered that in the = Denial of Service section. The Media Distributor could always elect to = not forward, which is in effect censoring the = conversation.
 
VR: delaying a packet when at the same time it is = mandatory (i.e., MUST) to
"discard old = packets beyond a small-to-modest jitter and network re-ordering sized = window =C2=BB
means it will never be = used. Hence the idea of =C2=AB censoring a source =C2=BB. That being = said,
I don=E2=80=99t absolutely insist = on using this term (censor) if you feel uncomfortable with = it.

I prefer the = current language (which I didn't author), as i find it very = descriptive.

In the second paragraph I don't understand why it = is said that:
"the receiver believing = that it is what was said just now, and only
delayed due to transport delay."
Any RTP packet contains a timestamp (whose = integrity is protected end-to-end if
I = understand correctly), and this timestamp is used by the receiver to = identify
timing issues. The fact a packet = is delayed (significantly) by a Media
Distributor cannot be misinterpreted by a receiver = as a "what was said just
now". The = receiver immediately identifies this delay.
 
While that = might be true, I'd guess most implementations would not maintain this = timing information for media held for a substantial period of time. And = media held for a short duration really might be considered late only due = to network delays. That actually does happen when network congestion = builds. So, short delays might easily be attributed to network delays = and long delays likely result in a "reset" of the flow at the endpoint. = I think all we can do here is provide a warning about this, but I'm = happy to make adjustments if you have specific words you think would = make this clearer.
 
VR: please = propose something, this is your document.

I'm not really sure what to add. = There's really nothing different here than with any other RTP = conference-- nothing unique to PERC, per se. If I were to propose a = solution, I think it's dangerous. Some codecs don't necessarily create = monotonically increasing timestamps. Some endpoints don't have accurate = clocks (sender or receiver), so drift can result in miscalculations over = time. I think it's good to note this issue, but leave it for = implementation.

** Section 8.2.4:
I = don't like the way this section is written. It first explains what a = Media
Distributor could do if it could = alter a certain header field (in this case
SSRC), it details the consequences, to finally = explain that this is not
possible. This = Security Discussion section is essentially meant to discuss
remaining security issues or highlight specific = aspects, not what could happen
with a = different, non secure, design. This text could also be written the = other
way round: "By including the SSR = field into the integrity check, PERC prevents
splicing attacks where...".
 
I assume you = (and Ben) are looking to change that last sentence from "not allowing" = to "by including"? I'll change it that way, but if that wasn't your = meaning, please let me know.
 
VR: no, I = just don=E2=80=99t like (and I did the same comment above) the way you = introduce
things, by explaining there=E2=80= =99s a problem, and later explaining there=E2=80=99s in fact no = problem
because it=E2=80=99s not = possible. Please change it as suggested.

I did change it to include the = sentence you suggested (it will be in the -09), but we can come back to = this if you want. This particular issue could be ignored entirely, but = as Ben noted this one getting a lot of discussion. Yes, splicing attacks = are mitigated, but the splicing attack concept was introduced the way it = was introduced, because the meaning isn't immediately obvious. This text = was originally authored by John Mattsson:
Of course, it changed a little as the = entity names and solution to the problem changed. It still has things in = reverse order from what you want, I think, but look at -09 when it is = published shortly and tell me if that's still objectionable.

** Missing in 8.2
The = RTCP flows are not encrypted end-to-end (unlike data flows) but = only
hop-by-hop. Consequently, a = malicious Media Distributors may corrupt an RTCP
packet content (e.g., reception statistics in RR) = or forge malicious RTCP
packets which may = trigger various effects at a sender. There are other types of
RTCP packets that may be attacked as well with = various consequences. None of
this is = explained in section 8.2. "Media Distributor = Attacks".
 
This is true, though it wasn't a concern since the = objective of PERC was to secure the media E2E. Nonetheless, you're = correct. How about this as a new section called "RTCP attacks" under the = Media Distributor attacks section?
 
PERC does not = provide end-to-end protection of RTCP messages. This allows
a malicious Media Distributor to impact any message = that might be transmitted
via RTCP, = including media statistics, picture requests, os loss = indication.
It is also possible for the = Media Distributor to forge requests, such as
requests to the endpoint to send a new picture. = Such requests can consume
significant = bandwidth and impair conference performance.
 
VR: yes, = please add it. This is a significant limit of PERC and it needs to be = clarified.
That=E2=80=99s also the goal = of any Security Considerations section to highlight limits.
If you have another limit in mind, this is where it = should go.

OK. I've added = some text in a new section titled "RTCP attacks".

That being said, can RTCP request the endpoint to = send a new picture?

Yes

Isn=E2=80=99= t it an RTP packet rather than picture (I=E2=80=99m not totally sure of = it)?

If a receiving = device lost key packets and cannot reproduce an accurate image, it will = send a request for a new picture. On reception of a picture request, the = sender will send a new picture (i.e., the full image that should be = displayed on the screen), which will consume several RTP packets for = large images.

Additionally= =C2=AB picture =C2=BB is anyway not appropriate here, =C2=AB video = frame =C2=BB is
probably more adapted to = video flows.
Years ago, = this was called "video fast update" in H.323. In SIP, that term is used, = as is "Full Intra-frame Request" (FIR). Both avoided the use of "frame" = or "picture". On this subject, I was talking with Gary Sullivan (chair = of the group standardizing H.264, H.265, etc.) and he suggested using = the terms "I-picture" and "P-picture" (for another document I was = writing). Indeed, the term "picture" is used throughout H.265, as is = frame -- but they have different meaning. As he was explaining, he also = said:

I did not use = the word =E2=80=9Cframe=E2=80=9D above. It has a different meaning than = =E2=80=9Cpicture=E2=80=9D. The difference
is becoming less important over time, = but if we want  to be strict, we should not use the terms
casually.

And with that, I was left perplexed = as to what to use when. However, I think we should take queues from the = latest specs. In the H.265 RTP payload format spec, there is a "picture = loss indicator":

In section 8.4 of that spec it says, = "Upon reception of a FIR, a sender MUST send an IDR picture."

And in https://tools.ietf.org/html/rfc4585#section-6.3.1.1 (from 2006) the authors = used "intra-picture".

Anyway, that's = the reason I used "picture". I think the issue is that the meaning of = these words have changed over time. That, or some folks just prefer = "picture" now. I don't know.

** General comments about 8.1 and 8.2
Insider attacks are a powerful form of attacker = model with severe consequences.
This is = not a big surprise. I'd be more interesting in a detailed 8.1 = section,
more likely to happen (weaker = attacker model).
 
I'm not sure = exactly what you're looking for. You want a new section (e.g., 8.3) that = details insider attacks or something related to each of the existing = 8.1/8.2 sections? Insider attacks could be disastrous, definitely. They = could range from anything from turning off the power to stealing the = KEKs stored in the Key Distributor. The latter is "scary" in that, if a = rogue individual were to steal the KEKs, he or she could decrypt media = off-line and at a later date. And, if the Key Distributor stored the = keys for a long time (e.g., so as to enable conference recording and = playback -- something not really considered on PERC, but certainly = implementable), then they could first capture the media flows and then = decrypt them a year later once they have access to the KEKs. The two = attacks do not have to carried out concurrently and there would be no = defense against theft of KEKs.
 
We could = scare people with some words about keeping the Key Distributor secure, = but I'm not sure what we need to convey.
 
VR: no, this = is not what I mean.
Attacks of section = 8.1 seems more realistic to me than attacks of section 8.2 = because
of a weaker attacker model: the = attacker is outside of the systems, and not necessarily on
the path.
Section = 8.2 are all about attacks that are launched from a corrupted MD, i.e., = they are
all some form of insider = attacks. This is less likely.
Therefore I = would have liked to see more details in section 8.1, that=E2=80=99s = all.

In the interest = of getting a new revision published so folks can provide more input, I = didn't add anything here. However, I'm happy to do so, but I'm at a loss = for what to add. If by "insider" you mean a rogue individual manging the = service elements (e.g., key distributor), I definitely can see issues. = However, I don't understand how that would apply to third-party attacks. = Maybe you mean something different for "insider" than what I have in = mind? If we share the same meaning, then are you wondering what third = parties can do if an insider helps facilitate an attack (e.g., by = stealing keys out of the KD and sending them to some third-party = hacker)?

Paul

= --Apple-Mail=_14CEBCAF-E510-416B-B875-098F0C576BFF-- From nobody Wed Feb 20 06:08:45 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FC2A1286E7; Wed, 20 Feb 2019 06:08:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.899 X-Spam-Level: X-Spam-Status: No, score=-0.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=packetizer.com 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 aifdwHZiwMkm; Wed, 20 Feb 2019 06:08:32 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [IPv6:2600:1f18:24d6:2e01:e842:9b2b:72a2:d2c6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD765124408; Wed, 20 Feb 2019 06:08:31 -0800 (PST) Received: from authuser (localhost [127.0.0.1]) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1550671708; bh=ryRq0zhVJZE8l88oNRye7nj1J5IrucGh7+mDgxPwWmw=; h=Date:In-Reply-To:References:Subject:To:CC:From; b=WoU1bLKOTMRcVejZJYnoA4TGVmUFcuT3A0hYQz81ElqVYiGYdMHuYLCCTJg6p/Sm7 1waX1qdhERPqPeg3TGXzoryt/tw3geh+jWJMHYTgKkN6InYQ5wwvVwvD74r93mq6Ah bKvUF4RlpXWgtaZMyIr/d8bNHAsTg6ddZiClVCmw= Date: Wed, 20 Feb 2019 09:08:24 -0500 User-Agent: K-9 Mail for Android In-Reply-To: References: <155014077570.26619.9407568904769535504@ietfa.amsl.com> <6882A552-80DF-4322-9683-13D8E655F2DB@inria.fr> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----5WENIXVG1Y2EZM48U7XNTXO6U2UWZR" Content-Transfer-Encoding: 7bit Autocrypt: addr=paulej@packetizer.com; keydata= mQQNBFHlwHIBIADPBuXxiC7IP3Acolod+D4BWYKBDGgyX90mexkDt6Wi6D2LJlpadGp99NgG9Oc4 m9QDEPPuhRHKvgexNAxAeILUZlOX6m/30n83VuwGNZagxjawN9/Kv4WrLlDI+HSZeKwfVf8GBus/ jB6c5WQtV6/L7LYCQLU08dWng8NlBi6dupyWC1rhtNWnPCqS4C3nINWJRx4grfIvkI5PbDMPca/B iluZxy0XntHuNWf51Gj4IIIAK2QNWQwDLaDnZ774Q1HfMTt4u4UwivsOt9Z49w92Q6FuN7/3sve7 DwrEVtp0xCKqaBQOX2354VVOTMh0bhHGLprQ1BL3QAWlyg/ZkTs+kopd3h+mJ0Mkg3Es66umcG8U YbH+edmZ7mHWqHuWmNieEycZgmah6kfrb7lUZeJnkkLfZ6SS3fhJIhJq3RwTKfvyF9LNvnZ7XXsO VSBKvVFPHWuDe3tbglTZCEYIcdFotgMcpZatdJF0ZPdLPGECc/XCZOgQpICGZ6b0dt/uJKOPC1OY RlFfIWc9bDgRCQY0MCqTsYiGevMNdQTlZHgTactm4h886bETFdbSoDniPls7LuI3cAr++iHmF56o hwh9Hl8KVzsv+uSL1mmrfE/X+lEaJnPUrQopByFQySE4D+hvOFLNh2iv7BHyXX9G0Dv9jDB6hW+6 1RYBf23GRZWSEVMyoYfbbU7Tg5JNrVRLU7nUMVbla2fGIKz9K3ejtCy/35QAjt7DIrVVe9k9J54r Z1yD8ZXfQXv869/q/mHGVzxdtgO+PcrIXJYck8R7jSDB2wIo3g5z+2P3Lt2gvB4w9UUSNZ4deE95 MNc6FvqqTMlBzoxzBf2E+SoUZKTl4i48XJhKI+Bk71NnMug2ER2NbyQIg6aH7l4t4t38mK6yt/cd 00f8UtKxp7z2EnqXJ+/kx0pq9zECp76oAPv9JlInntbcl89jRS4qMAMgZFEy6sYOMftfhVgDkci/ JR+2s4V65aUxcR6PLtXRHg3ZZ2F4hEBkBxJQt4LZ6lWzMXuWkCfjca032WOq/Zl+RMrs18dywVoh DXqSaYoSCzkfeCbzTE4cCuE8o9FUx7B/nS6g+h0wvrGDcLeGIwVWYO+Q0gf+vbLq2ZfykWjS5Fa3 ZKLdEOWaNas/8UlW33lU3u9nj84dJgMcP/VAugd8N9QWJ9NKszL8689NmwQnzoIU43+ucRd0WgCA WgXtV6MmG2WUpKN6y/ARqis6NvKTpl/t7SMznBxZGg2ZUC7pBpT/cq6vi18+tWP1ghRGJgJJ4t6v D64fBQTAaaN9MxU46OIlcWtjvf5zzL0pwebYOdInN/wA7YOOK3Q/wQsPaD5dvY+6H9yrCLMBwGyR l3TB/bsaYqtFABEBAAG0JVBhdWwgRS4gSm9uZXMgPHBhdWxlakBwYWNrZXRpemVyLmNvbT6JBDgE EwECACIFAlOH4kACGy8GCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEHropU4WcvKlpF4gAI34 iWlJY84nB8y12sqLldU0d9rSnk6euOYf7HIIJ8yHGCHVkQJUksjcwPOAr/zw4XjftSEv8JN3PDLp khvQ2snEIZ7UPFafUmbq3BQLPkN0Mpamx7br7vpLwpRMwbPyWYc4Z0+Ag4t6p/01troi++v3DLDN AjAov/Q526pL7qFkIJpadMcVcTEgr5XEsVVxw5TbGrqyDwam+aNIVcxDNxzOG4nFJ1bjUGAeoRcV Jnz0X0CQUFzxgMceyjuqI3Qyj5kp3gZkoibJyfZ6/6FFVV5dGAlHluL52H6KiUAkWPf0qbGo6ELu xsnSX9JPVUtr14B6HfZP8kWX740Hu2yBQTAxhsfhhsR4LNUxKcdNFSJ/Ozpo3i7fvek3CF+ash7l 25JAkI+1TH4kh7dYpndwTWwXDNqTMQR+I+JtsKgATpx/pBWaNK0zvWKuxjoM/CVn4NPWf9aqfdF3 wvTq5EMDarQ8Leou0LsKLKZsJHYYxFlMlD37/+q4UsIy5iPatNl8qm4YM4LykjvB+Ozsd3OZ3z+b uSdJ+6QwOnje21tPLhSI8dEIw8S+DKl+80I/2bEd3+wKptHcB0NU3OF9B3N1ClOp7wFIrgsQ0pTH A2pchxWyC9pngYhErJS6nZaQeWwrN7VH9RkS2SPPkAzf5N27ayky2rF8nDZrkO1OuXCaH9gyi2CQ fJEtbAPMXfAJo5Ls0trEMqQGDAW3/GxCo5NoX70bXjPd+NXBIYBaC9dc6Iyqei3xQJNsE2vtPEo3 glJaE3mFMpUOILqQkU8hjs3+J1rNkpkmaoenlvbDVUqM0TVGzHFJlPtLXR/DsDjgjk1uaS+xIlD0 exwLp3/Bgs4nXAQ1UYlPOLC/BokUPwAuSuUrCAYHfAzwsynIgI8j/EHeKgyjyuQ4f1uIlzy63rVd 8QVvGt6qV2hO0Bj4FzIMG9xG4KZ7cPziHmAh5tR0PbV35vJLww3HbmL6LzC5CaB2cYkLuOL4BuhU D+b20GiThhtYaPBQr49NBNViCB+RlhojKIS4Ou9+ngg2L4EWe6rY0yzR+BWPBvNtZNantozb49Pu IcYhfxzWFjK7Gt6zlQeUfsBGtdjR1p4emdH4c/VFdzj4bNPtKv56mkUrcFQpE1vym/PPYyvG3wBz UXF/d/W5NqojZmuQLO+GfMPo2sbT3V0LTELlfRfzOstA7SpdQgYpMoRQwErxIwn2lUVjt6DjXeaR oOkQgYAgQqHYLrWef6gYLy05xHEN6Ow6t7VDxuZOtjrJqQ3oyfcyR9EsyAET8CvSSaHABOaqWOiw E+TzU9/42ei0Qph08xL8BQMQVsnOJZLM8DMNWzWB3wVxCaVil+unNTnmw7mjClcPFuBjFyc= To: Vincent Roca CC: secdir@ietf.org, iesg@ietf.org, draft-ietf-perc-private-media-framework.all@ietf.org From: "Paul E. Jones" Message-ID: Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-perc-private-media-framework-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2019 14:08:37 -0000 ------5WENIXVG1Y2EZM48U7XNTXO6U2UWZR Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Vincent, I have submitted it=2E Feel free to provide additional comments you might = have=2E Paul -------- Original Message -------- From: Vincent Roca Sent: February 20, 2019 2:13:41 AM EST To: "Paul E=2E Jones" Cc: Vincent Roca , secdir@ietf=2Eorg, iesg@ietf= =2Eorg, draft-ietf-perc-private-media-framework=2Eall@ietf=2Eorg Subject: Re: Secdir last call review of draft-ietf-perc-private-media-fram= ework-08 Hello Paul, Thanks for your answer and long explanations on the use of term =C2=AB pic= ture =C2=BB=2E I was not aware of this evolution of vocabulary=2E Yes, please submit -09 version and I=E2=80=99ll= have a new look at it=2E Cheers, Vincent > Le 20 f=C3=A9vr=2E 2019 =C3=A0 04:58, Paul E=2E Jones a =C3=A9crit : >=20 > Vincent, >=20 >>>> The same comment applies to the remaining two paragraphs=2E I suggest= the authors >>>> explain that the proposal prevents an attacker to claim being a regul= ar Media >>>> Distributor and therefore to fool endpoints because =2E=2E=2E"=2E >>> =20 >>> The "false Media Distributor" example could happen=2E For example, if = a hacker had access to the network where the Media Distributor is located a= nd claims the Media Distributor's address while the conference is operating= , the endpoints might not know=2E However, the worst result of such an atta= ck is similar to just unplugging the box: packets just don't flow=2E The fa= ke box could attempt to forward packets it receives, but they would fail to= authenticate at the receiving endpoints and be discarded=2E However, this = false device could never gain access to the media and would not be given HB= H keys since it could not authenticate with the Key Distributor=2E >> =20 >> VR: you=E2=80=99ve said that a false Media Distributor will fail to get= access to the media >> and fail to forward the traffic=2E In the original text, you also say t= hat: >> "They Key Distributor will fail >> to establish the secure association with the endpoint if the Media >> Distributor cannot be authenticated=2E" >> I agree that an attacker may try to impersonate a valid MD, but this at= tempt will >> fail=2E And when you say that: >> =C2=AB false Media Distributor may cascade to another legitimate Media >> Distributor creating a false version of the real conference" >> this is just wrong=2E The attacker won=E2=80=99t succeed=2E >> =20 >> This is why I=E2=80=99m saying that you should re-write this part to sa= y that clearly that >> thanks to the provided security mechanism, an attacker will fail to imp= ersonate >> a MD=2E Don=E2=80=99t pretend attacks can succeed if this is not the ca= se=2E >=20 > OK, I've substantially re-worked this section=2E When version -09 is pub= lished, hopefully it will look better=2E I'll try to get that out soon and = welcome further comments on that text=2E >=20 >=20 >>>> ** Section 8=2E2=2E2=2E >>>> Is the following sentence correct: >>>> The mitigation for a replay attack is to prevent old packets beyond a >>>> small-to-modest jitter and network re-ordering sized window to be >>>> rejected=2E >>>> Is "prevent [=2E=2E=2E] to be rejected" correct? I'd say "=2E=2E=2E t= o be delivered" >>>> instead=2E >>> =20 >>> "prevent=2E=2E=2E rejected" is definitely an error=2E However, we cann= ot stop delivery=2E If replayed packets are received by either the Media Di= stributor or the endpoint, they should be discarded=2E So, perhaps this is = better: >>> =20 >>> "The mitigation for a replay attack is to discard old packets beyond a >>> small-to-modest jitter and network re-ordering sized window=2E =C2=BB >> =20 >> VR: Better, if we assume there's a timing based replay protection mecha= nism=2E >> But the following item bellow indicates a totally different approach to= replay protection >> (ID based rather than time based), hence a major contradiction in this = text=2E Please fix it=2E >> =20 >>>> Another comment=2E Replay protection seems to be based on timing cons= iderations >>>> rather than on the use of unique sequence numbers that must not be re= played >>>> (except if a wrapping to zero occurs of course)=2E Is that correct? A= dditionally, >>>> is this mechanism carefully described in this document? Since it is e= xplained >>>> that E2E replay protection MUST be provided, it's essential to be ver= y clear on >>>> how to perform this=2E Failing to do so is a big issue=2E >>> =20 >>> The mechanism underlying this is SRTP, which defines in 3=2E3=2E2/RFC3= 711 an "SRTP window size"=2E We felt it was best to not introduce conflicti= ng language=2E Perhaps we should just change the paragraph more substantial= ly and refer to SRTP=2E >>> =20 >>> Would you prefer this as the second paragraph? >>> =20 >>> "The mitigation for a replay attack is to implement replay protection = as >>> described in Section 3=2E3=2E2 of [RFC3711]=2E >>> End-to-end replay protection **MUST** be provided for the >>> whole duration of the conference=2E =C2=BB >> =20 >> VR: You cannot mandate replay protection without giving details on the = replay >> protection mechanism to use=2E Here you mention SRTP replay protection= =2E If you >> read the section you mention you=E2=80=99ll see that this replay protec= tion is not based >> on packet timing but a packet sequence number: >> "When message authentication is provided, SRTP protects against such at= tacks through a Replay List=2E =C2=BB >> and: >> "Packet indices which lag behind the packet index in the >> context by more than SRTP-WINDOW-SIZE can be assumed to have been >> received=E2=80=A6 =C2=BB >> =20 >> That=E2=80=99s totally different=2E If replay protection is a MUST, you= need to be very clear >> on what you expect from developers=2E >=20 > The previous text (that you referred to as timing-based) didn't go into = the document, but the text just above did=2E Rather than prescribe how to d= o it, I think it's best to defer to 3=2E2=2E2 of RFC 3711=2E That is the wa= y to do it with SRTP, and PERC utilizes SRTP=2E We are not inventing any ne= w mechanisms=2E >=20 >>>> ** Section 8=2E2=2E3 >>>> It is said that "a Media Distributor can select to not deliver a part= icular >>>> stream for a while=2E" That's perfectly true, yet is this a "Delayed = playout >>>> attack"? I'd rather call it a Media Distributor censorship attack, or= something >>>> along this line=2E The main idea behind the attack is not to delay a = stream but >>>> to censor a source=2E >>> =20 >>> This attack is not to censor, but to delay=2E For example, at time "T"= Bob might say "I agree with your proposal"=2E However, the "evil" Media Di= stributor could opt to not forward those packets and hold them=2E At some t= ime "T+delta", the Media Distributor then forwards them=2E The receiving en= dpoint might not know that the packets were an hour old, so the receiver Al= ice thinks Bob is agreeing with a proposal that Bob actually doesn't agree = with=2E >>> =20 >>> However, a censorship attack is also possible=2E But I think we covere= d that in the Denial of Service section=2E The Media Distributor could alwa= ys elect to not forward, which is in effect censoring the conversation=2E >> =20 >> VR: delaying a packet when at the same time it is mandatory (i=2Ee=2E, = MUST) to >> "discard old packets beyond a small-to-modest jitter and network re-ord= ering sized window =C2=BB >> means it will never be used=2E Hence the idea of =C2=AB censoring a sou= rce =C2=BB=2E That being said, >> I don=E2=80=99t absolutely insist on using this term (censor) if you fe= el uncomfortable with it=2E >=20 > I prefer the current language (which I didn't author), as i find it very= descriptive=2E >=20 >>>> In the second paragraph I don't understand why it is said that: >>>> "the receiver believing that it is what was said just now, and only >>>> delayed due to transport delay=2E" >>>> Any RTP packet contains a timestamp (whose integrity is protected end= -to-end if >>>> I understand correctly), and this timestamp is used by the receiver t= o identify >>>> timing issues=2E The fact a packet is delayed (significantly) by a Me= dia >>>> Distributor cannot be misinterpreted by a receiver as a "what was sai= d just >>>> now"=2E The receiver immediately identifies this delay=2E >>> =20 >>> While that might be true, I'd guess most implementations would not mai= ntain this timing information for media held for a substantial period of ti= me=2E And media held for a short duration really might be considered late o= nly due to network delays=2E That actually does happen when network congest= ion builds=2E So, short delays might easily be attributed to network delays= and long delays likely result in a "reset" of the flow at the endpoint=2E = I think all we can do here is provide a warning about this, but I'm happy t= o make adjustments if you have specific words you think would make this cle= arer=2E >> =20 >> VR: please propose something, this is your document=2E >=20 > I'm not really sure what to add=2E There's really nothing different here= than with any other RTP conference-- nothing unique to PERC, per se=2E If = I were to propose a solution, I think it's dangerous=2E Some codecs don't n= ecessarily create monotonically increasing timestamps=2E Some endpoints don= 't have accurate clocks (sender or receiver), so drift can result in miscal= culations over time=2E I think it's good to note this issue, but leave it f= or implementation=2E >=20 >>>> ** Section 8=2E2=2E4: >>>> I don't like the way this section is written=2E It first explains wha= t a Media >>>> Distributor could do if it could alter a certain header field (in thi= s case >>>> SSRC), it details the consequences, to finally explain that this is n= ot >>>> possible=2E This Security Discussion section is essentially meant to = discuss >>>> remaining security issues or highlight specific aspects, not what cou= ld happen >>>> with a different, non secure, design=2E This text could also be writt= en the other >>>> way round: "By including the SSR field into the integrity check, PERC= prevents >>>> splicing attacks where=2E=2E=2E"=2E >>> =20 >>> I assume you (and Ben) are looking to change that last sentence from "= not allowing" to "by including"? I'll change it that way, but if that wasn'= t your meaning, please let me know=2E >> =20 >> VR: no, I just don=E2=80=99t like (and I did the same comment above) th= e way you introduce >> things, by explaining there=E2=80=99s a problem, and later explaining t= here=E2=80=99s in fact no problem >> because it=E2=80=99s not possible=2E Please change it as suggested=2E >=20 > I did change it to include the sentence you suggested (it will be in the= -09), but we can come back to this if you want=2E This particular issue co= uld be ignored entirely, but as Ben noted this one getting a lot of discuss= ion=2E Yes, splicing attacks are mitigated, but the splicing attack concept= was introduced the way it was introduced, because the meaning isn't immedi= ately obvious=2E This text was originally authored by John Mattsson: > https://tools=2Eietf=2Eorg/html/draft-mattsson-perc-srtp-cloud-01#sectio= n-7=2E2=2E4 > Of course, it changed a little as the entity names and solution to the p= roblem changed=2E It still has things in reverse order from what you want, = I think, but look at -09 when it is published shortly and tell me if that's= still objectionable=2E >=20 >>>> ** Missing in 8=2E2 >>>> The RTCP flows are not encrypted end-to-end (unlike data flows) but o= nly >>>> hop-by-hop=2E Consequently, a malicious Media Distributors may corrup= t an RTCP >>>> packet content (e=2Eg=2E, reception statistics in RR) or forge malici= ous RTCP >>>> packets which may trigger various effects at a sender=2E There are ot= her types of >>>> RTCP packets that may be attacked as well with various consequences= =2E None of >>>> this is explained in section 8=2E2=2E "Media Distributor Attacks"=2E >>> =20 >>> This is true, though it wasn't a concern since the objective of PERC w= as to secure the media E2E=2E Nonetheless, you're correct=2E How about this= as a new section called "RTCP attacks" under the Media Distributor attacks= section? >>> =20 >>> PERC does not provide end-to-end protection of RTCP messages=2E This a= llows >>> a malicious Media Distributor to impact any message that might be tran= smitted >>> via RTCP, including media statistics, picture requests, os loss indica= tion=2E >>> It is also possible for the Media Distributor to forge requests, such = as >>> requests to the endpoint to send a new picture=2E Such requests can co= nsume >>> significant bandwidth and impair conference performance=2E >> =20 >> VR: yes, please add it=2E This is a significant limit of PERC and it ne= eds to be clarified=2E >> That=E2=80=99s also the goal of any Security Considerations section to = highlight limits=2E >> If you have another limit in mind, this is where it should go=2E >=20 > OK=2E I've added some text in a new section titled "RTCP attacks"=2E >=20 >> That being said, can RTCP request the endpoint to send a new picture? >=20 > Yes >=20 >> Isn=E2=80=99t it an RTP packet rather than picture (I=E2=80=99m not tot= ally sure of it)? >=20 > If a receiving device lost key packets and cannot reproduce an accurate = image, it will send a request for a new picture=2E On reception of a pictur= e request, the sender will send a new picture (i=2Ee=2E, the full image tha= t should be displayed on the screen), which will consume several RTP packet= s for large images=2E >=20 >> Additionally =C2=AB picture =C2=BB is anyway not appropriate here, =C2= =AB video frame =C2=BB is >> probably more adapted to video flows=2E >=20 > Years ago, this was called "video fast update" in H=2E323=2E In SIP, tha= t term is used, as is "Full Intra-frame Request" (FIR)=2E Both avoided the = use of "frame" or "picture"=2E On this subject, I was talking with Gary Sul= livan (chair of the group standardizing H=2E264, H=2E265, etc=2E) and he su= ggested using the terms "I-picture" and "P-picture" (for another document I= was writing)=2E Indeed, the term "picture" is used throughout H=2E265, as = is frame -- but they have different meaning=2E As he was explaining, he als= o said: >=20 > I did not use the word =E2=80=9Cframe=E2=80=9D above=2E It has a differe= nt meaning than =E2=80=9Cpicture=E2=80=9D=2E The difference > is becoming less important over time, but if we want to be strict, we s= hould not use the terms > casually=2E >=20 > And with that, I was left perplexed as to what to use when=2E However, I= think we should take queues from the latest specs=2E In the H=2E265 RTP pa= yload format spec, there is a "picture loss indicator": > https://tools=2Eietf=2Eorg/html/rfc7798#section-8=2E1 >=20 > In section 8=2E4 of that spec it says, "Upon reception of a FIR, a sende= r MUST send an IDR picture=2E" >=20 > And in https://tools=2Eietf=2Eorg/html/rfc4585#section-6=2E3=2E1=2E1 (from 2006) th= e authors used "intra-picture"=2E >=20 > Anyway, that's the reason I used "picture"=2E I think the issue is that = the meaning of these words have changed over time=2E That, or some folks ju= st prefer "picture" now=2E I don't know=2E >=20 >>>> ** General comments about 8=2E1 and 8=2E2 >>>> Insider attacks are a powerful form of attacker model with severe con= sequences=2E >>>> This is not a big surprise=2E I'd be more interesting in a detailed 8= =2E1 section, >>>> more likely to happen (weaker attacker model)=2E >>> =20 >>> I'm not sure exactly what you're looking for=2E You want a new section= (e=2Eg=2E, 8=2E3) that details insider attacks or something related to eac= h of the existing 8=2E1/8=2E2 sections? Insider attacks could be disastrous= , definitely=2E They could range from anything from turning off the power t= o stealing the KEKs stored in the Key Distributor=2E The latter is "scary" = in that, if a rogue individual were to steal the KEKs, he or she could decr= ypt media off-line and at a later date=2E And, if the Key Distributor store= d the keys for a long time (e=2Eg=2E, so as to enable conference recording = and playback -- something not really considered on PERC, but certainly impl= ementable), then they could first capture the media flows and then decrypt = them a year later once they have access to the KEKs=2E The two attacks do n= ot have to carried out concurrently and there would be no defense against t= heft of KEKs=2E >>> =20 >>> We could scare people with some words about keeping the Key Distributo= r secure, but I'm not sure what we need to convey=2E >> =20 >> VR: no, this is not what I mean=2E >> Attacks of section 8=2E1 seems more realistic to me than attacks of sec= tion 8=2E2 because >> of a weaker attacker model: the attacker is outside of the systems, and= not necessarily on >> the path=2E >> Section 8=2E2 are all about attacks that are launched from a corrupted = MD, i=2Ee=2E, they are >> all some form of insider attacks=2E This is less likely=2E >> Therefore I would have liked to see more details in section 8=2E1, that= =E2=80=99s all=2E >=20 > In the interest of getting a new revision published so folks can provide= more input, I didn't add anything here=2E However, I'm happy to do so, but= I'm at a loss for what to add=2E If by "insider" you mean a rogue individu= al manging the service elements (e=2Eg=2E, key distributor), I definitely c= an see issues=2E However, I don't understand how that would apply to third-= party attacks=2E Maybe you mean something different for "insider" than what= I have in mind? If we share the same meaning, then are you wondering what = third parties can do if an insider helps facilitate an attack (e=2Eg=2E, by= stealing keys out of the KD and sending them to some third-party hacker)? >=20 > Paul ------5WENIXVG1Y2EZM48U7XNTXO6U2UWZR Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Vincent,

I have sub= mitted it=2E Feel free to provide additional comments you might have=2E
=
Paul

From: Vincent Roca <vincent=2Eroca@inria=2Efr>
Sent: February 20, 2019 2:13:41 AM EST
To: "Paul E=2E Jones" <paulej@packetizer=2Ecom>
Cc: Vincent Roca <vincent=2Eroca@inria=2Efr>, secdir@ietf=2Eo= rg, iesg@ietf=2Eorg, draft-ietf-perc-private-media-framework=2Eall@ietf=2Eo= rg
Subject: Re: Secdir last call review of draft-ietf-perc-private-med= ia-framework-08

Hello Paul,

Thanks for= your answer and long explanations on the use of term =C2=AB picture&n= bsp;=C2=BB=2E I was not aware of this
evolution of voc= abulary=2E Yes, please submit -09 version and I=E2=80=99ll have a new look = at it=2E

  C= heers,

  Vin= cent

Le 20 f=C3=A9vr=2E 2019 =C3= =A0 04:58, Paul E=2E Jones <paulej@packetizer=2Ecom> a =C3=A9crit :

Vincent,

<= blockquote type=3D"cite" class=3D"cite2" style=3D"margin-left: 5px; margin-= right: 0px; padding-left: 10px; padding-right: 0px; border-left-width: 1px;= border-left-style: solid; border-left-color: rgb(204, 204, 204); margin-to= p: 3px; padding-top: 0px;">
The same comment applies to = the remaining two paragraphs=2E I suggest the authors
explain that the proposal prevents an attacker to claim being a r= egular Media
Distributor and therefore to fo= ol endpoints because =2E=2E=2E"=2E
 
The "false Media Distributor" exa= mple could happen=2E For example, if a hacker had access to the network whe= re the Media Distributor is located and claims the Media Distributor's addr= ess while the conference is operating, the endpoints might not know=2E Howe= ver, the worst result of such an attack is similar to just unplugging the b= ox: packets just don't flow=2E The fake box could attempt to forward packet= s it receives, but they would fail to authenticate at the receiving endpoin= ts and be discarded=2E However, this false device could never gain access t= o the media and would not be given HBH keys since it could not authenticate= with the Key Distributor=2E
&n= bsp;
VR: you=E2=80=99ve said that a false Me= dia Distributor will fail to get access to the media
and fail to forward the traffic=2E In the original text, you also = say that:
"They Key Distributor will fail
to establish the secure association with the e= ndpoint if the Media
Distributor cannot be a= uthenticated=2E"
I agree that an attacker ma= y try to impersonate a valid MD, but this attempt will
fail=2E And when you say that:
= =C2=AB false Media Distributor may cascade to another legitimate Media
Distributor creating a false version of the real= conference"
this is just wrong=2E The attac= ker won=E2=80=99t succeed=2E
 
This is why I=E2=80=99m saying that you should re-wr= ite this part to say that clearly that
thank= s to the provided security mechanism, an attacker will fail to impersonate<= /div>
a MD=2E Don=E2=80=99t pretend attacks can su= cceed if this is not the case=2E

OK, I've substantially re-worked this section=2E When version -09 is publ= ished, hopefully it will look better=2E I'll try to get that out soon and w= elcome further comments on that text=2E


** Section 8=2E2=2E2=2E
Is t= he following sentence correct:
The mitigatio= n for a replay attack is to prevent old packets beyond a
small-to-modest jitter and network re-ordering sized window to= be
rejected=2E
Is "prevent [=2E=2E=2E] to be rejected" correct? I'd say "=2E=2E=2E to b= e delivered"
instead=2E
 
"prevent=2E= =2E=2E rejected" is definitely an error=2E However, we cannot stop delivery= =2E If replayed packets are received by either the Media Distributor or the= endpoint, they should be discarded=2E So, perhaps this is better:
 
"The mitigatio= n for a replay attack is to discard old packets beyond a
small-to-modest jitter and network re-ordering sized window=2E= =C2=BB
 
VR: Better, if we assume there's a timing based replay prot= ection mechanism=2E
But the following item b= ellow indicates a totally different approach to replay protection
(ID based rather than time based), hence a major cont= radiction in this text=2E Please fix it=2E
&= nbsp;
Another comment=2E= Replay protection seems to be based on timing considerations
rather than on the use of unique sequence numbers that mu= st not be replayed
(except if a wrapping to = zero occurs of course)=2E Is that correct? Additionally,
is this mechanism carefully described in this document? Since = it is explained
that E2E replay protection M= UST be provided, it's essential to be very clear on
how to perform this=2E Failing to do so is a big issue=2E
 
Th= e mechanism underlying this is SRTP, which defines in 3=2E3=2E2/RFC3711 an = "SRTP window size"=2E We felt it was best to not introduce conflicting lang= uage=2E Perhaps we should just change the paragraph more substantially and = refer to SRTP=2E
 
Would you prefer this as the second paragraph?
 
"The mitigation for a= replay attack is to implement replay protection as
described in Section 3=2E3=2E2 of [RFC3711]=2E
End-to-end replay protection **MUST** be provided for the
<= div class=3D"plain_line">whole duration of the conference=2E =C2=BB
 
= VR: You cannot mandate replay protection without giving details on the repl= ay
protection mechanism to use=2E Here you m= ention SRTP replay protection=2E If you
read= the section you mention you=E2=80=99ll see that this replay protection is = not based
on packet timing but a packet sequ= ence number:
"When message authentication is= provided, SRTP protects against such attacks through a Replay List=2E =C2= =BB
and:
"Pac= ket indices which lag behind the packet index in the
context by more than SRTP-WINDOW-SIZE can be assumed to have been<= /div>
received=E2=80=A6 =C2=BB
 
That=E2=80=99s totally di= fferent=2E If replay protection is a MUST, you need to be very clear
<= div class=3D"plain_line">on what you expect from developers=2E

The previous text (that you referred to as= timing-based) didn't go into the document, but the text just above did=2E = Rather than prescribe how to do it, I think it's best to defer to 3=2E2=2E2= of RFC 3711=2E That is the way to do it with SRTP, and PERC utilizes SRTP= =2E We are not inventing any new mechanisms=2E

** Section 8=2E2=2E3
It is said that "a Media Distributor can select to not deli= ver a particular
stream for a while=2E" That= 's perfectly true, yet is this a "Delayed playout
attack"? I'd rather call it a Media Distributor censorship attack, or= something
along this line=2E The main idea = behind the attack is not to delay a stream but
to censor a source=2E
 =
This attack is not to censor, but to delay= =2E For example, at time "T" Bob might say "I agree with your proposal"=2E = However, the "evil" Media Distributor could opt to not forward those packet= s and hold them=2E At some time "T+delta", the Media Distributor then forwa= rds them=2E The receiving endpoint might not know that the packets were an = hour old, so the receiver Alice thinks Bob is agreeing with a proposal that= Bob actually doesn't agree with=2E
 
However, a censorship attack is also possible= =2E But I think we covered that in the Denial of Service section=2E The Med= ia Distributor could always elect to not forward, which is in effect censor= ing the conversation=2E
 <= /div>
VR: delaying a packet when at the same time = it is mandatory (i=2Ee=2E, MUST) to
"discard= old packets beyond a small-to-modest jitter and network re-ordering sized = window =C2=BB
means it will never be used=2E= Hence the idea of =C2=AB censoring a source =C2=BB=2E That being said,
I don=E2=80=99t absolutely insist on using this= term (censor) if you feel uncomfortable with it=2E

I prefer the current language (which I didn't author),= as i find it very descriptive=2E

In the second paragrap= h I don't understand why it is said that:
"t= he receiver believing that it is what was said just now, and only
delayed due to transport delay=2E"
Any RTP packet contains a timestamp (whose integrity is protec= ted end-to-end if
I understand correctly), a= nd this timestamp is used by the receiver to identify
timing issues=2E The fact a packet is delayed (significantly) by = a Media
Distributor cannot be misinterpreted= by a receiver as a "what was said just
now"= =2E The receiver immediately identifies this delay=2E
 
While that mig= ht be true, I'd guess most implementations would not maintain this timing i= nformation for media held for a substantial period of time=2E And media hel= d for a short duration really might be considered late only due to network = delays=2E That actually does happen when network congestion builds=2E So, s= hort delays might easily be attributed to network delays and long delays li= kely result in a "reset" of the flow at the endpoint=2E I think all we can = do here is provide a warning about this, but I'm happy to make adjustments = if you have specific words you think would make this clearer=2E
 
VR: = please propose something, this is your document=2E

I'm not really sure what to add=2E There's really nothi= ng different here than with any other RTP conference-- nothing unique to PE= RC, per se=2E If I were to propose a solution, I think it's dangerous=2E So= me codecs don't necessarily create monotonically increasing timestamps=2E S= ome endpoints don't have accurate clocks (sender or receiver), so drift can= result in miscalculations over time=2E I think it's good to note this issu= e, but leave it for implementation=2E

** Section 8=2E2=2E4:
I don't like the way this section is written=2E It first explain= s what a Media
Distributor could do if it co= uld alter a certain header field (in this case
SSRC), it details the consequences, to finally explain that this is not<= /div>
possible=2E This Security Discussion section= is essentially meant to discuss
remaining s= ecurity issues or highlight specific aspects, not what could happen
with a different, non secure, design=2E This text c= ould also be written the other
way round: "B= y including the SSR field into the integrity check, PERC prevents
splicing attacks where=2E=2E=2E"=2E
 
I assume y= ou (and Ben) are looking to change that last sentence from "not allowing" t= o "by including"? I'll change it that way, but if that wasn't your meaning,= please let me know=2E
 
VR: no, I just don=E2=80=99t like (and I did = the same comment above) the way you introduce
things, by explaining there=E2=80=99s a problem, and later explaining the= re=E2=80=99s in fact no problem
because it= =E2=80=99s not possible=2E Please change it as suggested=2E

I did change it to include the sentence you su= ggested (it will be in the -09), but we can come back to this if you want= =2E This particular issue could be ignored entirely, but as Ben noted this = one getting a lot of discussion=2E Yes, splicing attacks are mitigated, but= the splicing attack concept was introduced the way it was introduced, beca= use the meaning isn't immediately obvious=2E This text was originally autho= red by John Mattsson:
Of course, it changed= a little as the entity names and solution to the problem changed=2E It sti= ll has things in reverse order from what you want, I think, but look at -09= when it is published shortly and tell me if that's still objectionable=2E<= /div>

** Missing= in 8=2E2
The RTCP flows are not encrypted e= nd-to-end (unlike data flows) but only
hop-b= y-hop=2E Consequently, a malicious Media Distributors may corrupt an RTCP
packet content (e=2Eg=2E, reception statistic= s in RR) or forge malicious RTCP
packets whi= ch may trigger various effects at a sender=2E There are other types of
RTCP packets that may be attacked as well with v= arious consequences=2E None of
this is expla= ined in section 8=2E2=2E "Media Distributor Attacks"=2E
<= div class=3D"plain_line"> 
This is true= , though it wasn't a concern since the objective of PERC was to secure the = media E2E=2E Nonetheless, you're correct=2E How about this as a new section= called "RTCP attacks" under the Media Distributor attacks section?
 
PERC does not= provide end-to-end protection of RTCP messages=2E This allows
a malicious Media Distributor to impact any message that= might be transmitted
via RTCP, including me= dia statistics, picture requests, os loss indication=2E
It is also possible for the Media Distributor to forge requests= , such as
requests to the endpoint to send a= new picture=2E Such requests can consume
si= gnificant bandwidth and impair conference performance=2E
=
 
VR: yes, pl= ease add it=2E This is a significant limit of PERC and it needs to be clari= fied=2E
That=E2=80=99s also the goal of any = Security Considerations section to highlight limits=2E
If you have another limit in mind, this is where it should go=2E=

<= /div>
OK=2E I've added some text in = a new section titled "RTCP attacks"=2E

That being said, can RTCP request the= endpoint to send a new picture?

Yes

Isn=E2=80=99t it an RTP packet rather than picture (I=E2=80=99m not = totally sure of it)?

If a rec= eiving device lost key packets and cannot reproduce an accurate image, it w= ill send a request for a new picture=2E On reception of a picture request, = the sender will send a new picture (i=2Ee=2E, the full image that should be= displayed on the screen), which will consume several RTP packets for large= images=2E

Additionally =C2=AB picture =C2=BB is anyway not appropriate here= , =C2=AB video frame =C2=BB is
probably more= adapted to video flows=2E

Year= s ago, this was called "video fast update" in H=2E323=2E In SIP, that term = is used, as is "Full Intra-frame Request" (FIR)=2E Both avoided the use of = "frame" or "picture"=2E On this subject, I was talking with Gary Sullivan (= chair of the group standardizing H=2E264, H=2E265, etc=2E) and he suggested= using the terms "I-picture" and "P-picture" (for another document I was wr= iting)=2E Indeed, the term "picture" is used throughout H=2E265, as is fram= e -- but they have different meaning=2E As he was explaining, he also said:=

I did not use the word =E2=80=9Cframe=E2= =80=9D above=2E It has a different meaning than =E2=80=9Cpicture=E2=80=9D= =2E The difference
is becoming= less important over time, but if we want  to be strict, we should not= use the terms
casually=2E

And with that, I was left perplexed as to what = to use when=2E However, I think we should take queues from the latest specs= =2E In the H=2E265 RTP payload format spec, there is a "picture loss indica= tor":

In sec= tion 8=2E4 of that spec it says, "Upon reception of a FIR, a sender MUST se= nd an IDR picture=2E"

And in htt= ps://tools=2Eietf=2Eorg/html/rfc4585#section-6=2E3=2E1=2E1 (from 2006) the authors used "intra= -picture"=2E

Anyway, that's the reason I use= d "picture"=2E I think the issue is that the meaning of these words have ch= anged over time=2E That, or some folks just prefer "picture" now=2E I don't= know=2E

=
*= * General comments about 8=2E1 and 8=2E2
Ins= ider attacks are a powerful form of attacker model with severe consequences= =2E
This is not a big surprise=2E I'd be mor= e interesting in a detailed 8=2E1 section,
m= ore likely to happen (weaker attacker model)=2E
 
I'm not sure exactly= what you're looking for=2E You want a new section (e=2Eg=2E, 8=2E3) that d= etails insider attacks or something related to each of the existing 8=2E1/8= =2E2 sections? Insider attacks could be disastrous, definitely=2E They coul= d range from anything from turning off the power to stealing the KEKs store= d in the Key Distributor=2E The latter is "scary" in that, if a rogue indiv= idual were to steal the KEKs, he or she could decrypt media off-line and at= a later date=2E And, if the Key Distributor stored the keys for a long tim= e (e=2Eg=2E, so as to enable conference recording and playback -- something= not really considered on PERC, but certainly implementable), then they cou= ld first capture the media flows and then decrypt them a year later once th= ey have access to the KEKs=2E The two attacks do not have to carried out co= ncurrently and there would be no defense against theft of KEKs=2E
 
We could scare = people with some words about keeping the Key Distributor secure, but I'm no= t sure what we need to convey=2E
 
VR: no, this is not what I mean=2E<= /div>
Attacks of section 8=2E1 seems more realisti= c to me than attacks of section 8=2E2 because
of a weaker attacker model: the attacker is outside of the systems, and n= ot necessarily on
the path=2E
Section 8=2E2 are all about attacks that are launched from= a corrupted MD, i=2Ee=2E, they are
all some= form of insider attacks=2E This is less likely=2E
Therefore I would have liked to see more details in section 8=2E1, t= hat=E2=80=99s all=2E

In the i= nterest of getting a new revision published so folks can provide more input= , I didn't add anything here=2E However, I'm happy to do so, but I'm at a l= oss for what to add=2E If by "insider" you mean a rogue individual manging = the service elements (e=2Eg=2E, key distributor), I definitely can see issu= es=2E However, I don't understand how that would apply to third-party attac= ks=2E Maybe you mean something different for "insider" than what I have in = mind? If we share the same meaning, then are you wondering what third parti= es can do if an insider helps facilitate an attack (e=2Eg=2E, by stealing k= eys out of the KD and sending them to some third-party hacker)?

Paul

------5WENIXVG1Y2EZM48U7XNTXO6U2UWZR-- From nobody Wed Feb 20 12:56:47 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE5CB12950A; Wed, 20 Feb 2019 12:56:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 7yuLpdZ5nydu; Wed, 20 Feb 2019 12:56:35 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 570A912D4E7; Wed, 20 Feb 2019 12:56:35 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 66682C057F2F; Wed, 20 Feb 2019 20:47:52 +0000 (UTC) Received: from localhost (ovpn-112-77.rdu2.redhat.com [10.10.112.77]) by smtp.corp.redhat.com (Postfix) with ESMTP id 180041001DC1; Wed, 20 Feb 2019 20:47:51 +0000 (UTC) From: Robbie Harwood To: Takeshi Takahashi , secdir@ietf.org Cc: ietf@ietf.org, kitten@ietf.org, draft-ietf-kitten-pkinit-alg-agility.all@ietf.org In-Reply-To: <155047036985.3948.13609799438850064569@ietfa.amsl.com> References: <155047036985.3948.13609799438850064569@ietfa.amsl.com> Date: Wed, 20 Feb 2019 15:47:49 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Wed, 20 Feb 2019 20:47:52 +0000 (UTC) Archived-At: Subject: Re: [secdir] [kitten] Secdir last call review of draft-ietf-kitten-pkinit-alg-agility-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2019 20:56:38 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Takeshi Takahashi writes: > Reviewer: Takeshi Takahashi > Review result: Ready > > I do not see any serious issues on this draft and enjoyed reading it. > I have only minor questions for the purpose of deepening my > understanding of the draft. Awesome, thanks for taking a look! Let me see if I can help. > 1. In section 5, regarding the The TD-CERT-DIGEST-ALGORITHMS-Data > message, who embed the rejectedAlgorithm field? If it will be the KDC, > why does the KDC need to fill and distribute this information to the > others? It has to be the KDC. I believe the purpose of sending TD-CERT-DIGEST-ALGORITHMS-DATA is to enable clients that have multiple certificates to retry, to enable debugging without KDC access, and worst-case to allow the user to request re-issuance of the certificate in question. rfc4556 section 3.2.2 (PKINIT's specification for how to handle client requests) states: If the digest algorithm used in generating the CA signature for the public key in any certificate of the request is not acceptable by the KDC, the KDC MUST return a KRB-ERROR [RFC4120] message with the code KDC_ERR_DIGEST_IN_CERT_NOT_ACCEPTED. The accompanying e-data MUST be encoded in TYPED-DATA, although none is defined at this point. The important part here is that it applies to *any* certificate in the request. Sending the rejectedAlgorithm helps figure out which cert is problematic. There are other ways this could have been accomplished, but that ship has sailed. (Finally, the KDC doesn't technically "need" to send this structure; if it wishes for some reason to be mysterious, the draft specifies that the KDC "can OPTIONALLY send a list of digest algorithms".) > 2. In section 8 (security consideration), it is stated that "to do > otherwise allows an active attacker to perform a downgrade attack". In > my understanding of the draft, arbitrary algorithm could be used (if > the negotiation reaches agreements). I wonder if there is any > mechanism that discourages the negotiation of using insecure > algorithms. For instance, the list of algorithms that must be treated > with care could be listed somewhere? The security properties we're counting on from underling algorithms (like SHA1) here are pretty normal. Personally, I don't think we should be tracking algorithm security for Kerberos separately than from the rest of the crypto ecosystem - for instance, sha1 weakening affects TLS and everyone else just as it does us. That said, there have been two RFCs so far about removing algorithms from Kerberos: 6649 (1DES and export-strength RC4) and 8429 (3DES and the rest of RC4). Adoption of these is difficult, however, since some sites require interop with older setups (such as Windows Server 2003) that don't support AES. The result is that Kerberos implementations tend to enable by default only a subset of the algorithms they fully support. Making the tradeoff between security and interoperability is left as a policy decision. On the management side, Linux distros have been working to tie all these different configuration knobs together in one place. I'm sure there are others, but in Fedora we use the crypto-policies [1] project to handle weakenings/deprecations of various algorithms across the software in the distribution. Thanks, =2D-Robbie 1: https://gitlab.com/redhat-crypto/fedora-crypto-policies --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEA5qc6hnelQjDaHWqJTL5F2qVpEIFAlxtvPUACgkQJTL5F2qV pEJw0Q//aZjr+KbQ876poRK6gknx9zOFALto1eX6EBBww9Si8BiLrkaI9WClWZdi 79Gg01oUXbDfDZyy/DvQiu70KRMGDqsLSttHfdxZOg4x4l9un4185c0FRDCNat3I RoUGpSxmuOQTNNjDTffJQgQ/tq3U38dDqA6E/VXjmyrW0JM404jHeNx7r73kGg9r tbp68hhuBbY/zOzKRvX9MEFfDnoMx0MhYjWlc3/XtPcwmxbHHS4gge8VH7CGrERm 3h5a+WOCkscUZgAom2hRZd0uJ65Ufrv3K9WgJv25XvNoP+PLd5eJ84OH/3uHd9DP gfVvopbR4AhGSexgbrG2/FPXuv59SdRe3MaDDBvx2yfRa7dcZHJR5AfRNxBVphcP Tq8PEZ0x2Py8rdu9kO56D5xqJollhmBZn4n/GYGAmZS5TanLhYvdGYrywVQTKNqj LqhFTzwCoWa57PPDu/P8DSBvY/mYuLTCe6gm+BpLta6QYmDkpRnfT41Wgbs6wCe8 dvScdFgCAwbz1ZC2LdEnyiYmcxDYV60LHreCje4MGgRf2Jbb0LzRxOKO7kiubb/+ aoSW6pIzNTFHUTcdl/ziO+mpTKcn1EVn8nz9HQly7EI8MVQaJkOWHATBsAOb85Gc Nv0CYIlGlAms/Ho0Eml94dwGZN5M1o4JkAGRNIVclf5m0idBq0w= =Xufk -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Feb 21 05:47:31 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F1D401279E6 for ; Thu, 21 Feb 2019 05:47:29 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Tero Kivinen To: X-Test-IDTracker: no X-IETF-IDTracker: 6.91.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu Message-ID: <155075684998.8747.2552006699967474610.idtracker@ietfa.amsl.com> Date: Thu, 21 Feb 2019 05:47:29 -0800 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2019 13:47:30 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2019-02-21 Reviewer LC end Draft Radia Perlman R2019-02-01 draft-ietf-payload-flexible-fec-scheme-17 Yaron Sheffer 2019-02-08 draft-ietf-uta-smtp-require-tls-07 For telechat 2019-03-07 Reviewer LC end Draft Russ Mundy R2019-01-31 draft-ietf-mpls-sfc-05 Sean Turner 2019-02-19 draft-ietf-nfsv4-mv1-msns-update-04 Last calls: Reviewer LC end Draft Derek Atkins 2019-03-03 draft-ietf-netmod-module-tags-05 Nancy Cam-Winget 2019-02-15 draft-ietf-rtcweb-security-11 Daniel Gillmor 2018-03-19 draft-gutmann-scep-13 Leif Johansson 2018-12-24 draft-ietf-6lo-nfc-13 Russ Mundy 2017-09-14 draft-spinosa-urn-lex-13 Tim Polk 2019-02-13 draft-ietf-sipcore-reason-q850-loc-05 Stefan Santesson 2019-02-11 draft-ietf-extra-imap-fetch-preview-03 Stefan Santesson R2018-11-20 draft-wilde-service-link-rel-10 Takeshi Takahashi R2018-08-31 draft-ietf-lisp-rfc6833bis-24 David Waltermire 2019-02-15 draft-ietf-rtcweb-ip-handling-11 Samuel Weiler 2019-03-05 draft-faltstrom-unicode11-07 Brian Weis 2019-02-27 draft-ietf-dnsop-algorithm-update-06 Klaas Wierenga 2019-02-26 draft-ietf-mpls-sr-over-ip-02 Taylor Yu 2019-02-15 draft-ietf-rtcweb-security-arch-18 Taylor Yu 2018-11-28 draft-ietf-alto-cost-calendar-10 Early review requests: Reviewer Due Draft Daniel Franke 2018-01-31 draft-ietf-intarea-provisioning-domains-00 Next in the reviewer rotation: Shaun Cooley Roman Danyliw Alan DeKok Linda Dunbar Donald Eastlake Shawn Emery Stephen Farrell Daniel Franke Daniel Gillmor Tobias Gondrom From nobody Thu Feb 21 09:05:37 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3280A130F96; Thu, 21 Feb 2019 09:05:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=FX0VfZFW; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=Cs3jHdjR 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 4ReGcCPF0A9s; Thu, 21 Feb 2019 09:05:33 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B668C130EEA; Thu, 21 Feb 2019 09:05:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5452; q=dns/txt; s=iport; t=1550768732; x=1551978332; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=+MOhbNm3wtvRA+hho0mGFojXs2E06+3gvuPhrL5TpK0=; b=FX0VfZFWHWveTAx+ZfOrJ1nkofbMFdGzrIHJ8hIUMDGmc8aszjEJGvbM JneWydRtvos7sUPCTtLXrdUbrfVUDVWkg7mJoNjvsmYCqdloZ6158URXX XLI3o3WF2g0D7XdY/OUkKkmKwwUCIQWPZi0QxtByH/kSW877XdNUkQ4DK o=; IronPort-PHdr: =?us-ascii?q?9a23=3AubWxvx9FVLRZ7/9uRHGN82YQeigqvan1NQcJ65?= =?us-ascii?q?0hzqhDabmn44+8ZR7E/fs4iljPUM2b8P9Ch+fM+4HYEW0bqdfk0jgZdYBUER?= =?us-ascii?q?oMiMEYhQslVd6EAEriPv73Ryc7B89FElRi+iLzPA=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AEAADn2W5c/49dJa1kGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUQUBAQEBCwGBMCknA2d0BAsnhAeDRwOEUIsLgjIliS2OcRS?= =?us-ascii?q?BEANUCwEBGxGEQAIXg2MiNAkNAQMBAQIBAQJtHAyFSgEBAQMBIxEMAQE3AQ8?= =?us-ascii?q?CAQgOCgICJgICAh8RFRACBAENBYMgAYFaAw0IAaFrAooUcYEvgngBAQWFAw0?= =?us-ascii?q?LggsDBYELhHCGTReBQD+BEScME4JMgleBdwESAR+DCTGCJqJ5BSQzCQKGd0W?= =?us-ascii?q?DMoQygzwZgXGFWotAihovhU6BLYsMAgQCBAUCDQEBBYFHOGVxcBVlAYJBghy?= =?us-ascii?q?BIwEJgkGFFIU/coEojCWCPgEB?= X-IronPort-AV: E=Sophos;i="5.58,396,1544486400"; d="scan'208";a="437490319" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Feb 2019 17:05:31 +0000 Received: from XCH-ALN-011.cisco.com (xch-aln-011.cisco.com [173.36.7.21]) by rcdn-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id x1LH5VZi011098 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 21 Feb 2019 17:05:31 GMT Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-ALN-011.cisco.com (173.36.7.21) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 21 Feb 2019 11:05:30 -0600 Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 21 Feb 2019 12:05:29 -0500 Received: from NAM02-CY1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Thu, 21 Feb 2019 12:05:29 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector1-cisco-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+MOhbNm3wtvRA+hho0mGFojXs2E06+3gvuPhrL5TpK0=; b=Cs3jHdjRVG1emiFscFFhVg+Jy1e6rAp8gsIUHokE+DJk6V7Ob8iTDph6rLMq92wbsIx9qr+1HV2t+KI94dcW96n4E+FYExZVEyRtIoLYeKBDzIvdDMs5tOKlpFwhYTrX/B81rUV2j1HeEGMI1NzcNGYmAh1PeI5bTeTgp+GMjMg= Received: from CY4PR11MB1559.namprd11.prod.outlook.com (10.172.70.138) by CY4PR11MB2022.namprd11.prod.outlook.com (10.173.16.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1643.15; Thu, 21 Feb 2019 17:05:28 +0000 Received: from CY4PR11MB1559.namprd11.prod.outlook.com ([fe80::d540:fdd4:ed72:856b]) by CY4PR11MB1559.namprd11.prod.outlook.com ([fe80::d540:fdd4:ed72:856b%7]) with mapi id 15.20.1643.014; Thu, 21 Feb 2019 17:05:28 +0000 From: "Xiaoqing Zhu (xiaoqzhu)" To: Colin Perkins , Yoav Nir CC: "secdir@ietf.org" , "rmcat@ietf.org" , "draft-ietf-rmcat-video-traffic-model.all@ietf.org" , "ietf@ietf.org" Thread-Topic: Secdir last call review of draft-ietf-rmcat-video-traffic-model-06 Thread-Index: AQHUtBpSU4CXq0B8J0mNm5Q/WldUeqW/NX6AgCsNAIA= Date: Thu, 21 Feb 2019 17:05:28 +0000 Message-ID: <1F131783-6786-4D6D-BDE4-A33DFFDF56CE@cisco.com> References: <154835782178.29376.11315332570255821000@ietfa.amsl.com> <4474F01B-D594-485D-BAC5-E64703406A34@csperkins.org> In-Reply-To: <4474F01B-D594-485D-BAC5-E64703406A34@csperkins.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.16.1.190220 x-originating-ip: [2001:420:c0cc:1006::fb] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 6afe1a04-f5f0-43d0-f94f-08d6981ec789 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600110)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:CY4PR11MB2022; x-ms-traffictypediagnostic: CY4PR11MB2022: x-ms-exchange-purlcount: 1 x-microsoft-exchange-diagnostics: =?utf-8?B?MTtDWTRQUjExTUIyMDIyOzIzOktDUjd2Wk9nd2o0MGRjNUxEUWg4c3VmYXFU?= =?utf-8?B?RFRsbEk5cnJFNVlYdTVzZkw2WEg0bVMyY2Y0N3RsODdnNWx3Qk91SkJTZkcr?= =?utf-8?B?cU9Ya1FJWTBZUWlDQ0o3a3phZTl3TE1yQ2VTNjFNOWtoQURuWEZQRE4zVjZ2?= =?utf-8?B?Wnl2UHBKM0NER0tVTENOdXo5Vis2Rm9VL3Z2STZHVVFxZk9GUGhOSWlzN3h5?= =?utf-8?B?cGFxS3IvdHlib1BpMDRmcW1KRDdzWlQ4WWpmUVRHdmJQaUg2MDFNTTR5ME5a?= =?utf-8?B?S1JZOFRHZlJyUXZOOEtoanUzRUF6cDBrVWlQYWdNcUM5MEtyVUtocGNoZDhH?= =?utf-8?B?cHRXcmdlTjdzWSthRTZRdUtkaTZQWWZBL0F3SFdJWEpzYURLM09kSVhXN00v?= =?utf-8?B?UGE2dFBTMDhhUE1NTDd0WG5VdVFBcis5eGtVbzJ5Tmx3VVl4ek4rQ2E3L2M1?= =?utf-8?B?bmRTSEN2Qy9MZTVmcElOOWRNM3NXQklIdk81b3psSE1VZ0E0VWZPR3pRTjB6?= =?utf-8?B?MFRpenF5eEt1dVUxeDd5Nk5wSXE2M1NIRHNHQmpRNlQ0Y0NLOUxUVFUraDBE?= =?utf-8?B?MkhzeVVrWGFqM2wzb0NPRldEUUtreWZ6RGFhQk04ODdOeGpuTU9nSFZxYVUz?= =?utf-8?B?aW4rRjNld0trdUFiNGJTa0Z1RWpsSXZiYjVLbG5Ybmw2c1RaZEZmVlkxb2Vq?= =?utf-8?B?bHFNUm5ZYnRjY2Q2VDRMMkJXSEtYTjhPUisra2xnOWdhNVN3WmdUWm9tTjBH?= =?utf-8?B?ajNEV0h3UFVSR3ZRNUYvcDZoTXFsUVVlajFxeXRwbXRUaEhoUjJ4ZXJMMXVS?= =?utf-8?B?RlZLbnh4K1ZWOTlrMTB5VTVYQmQxUEhVRG1HeXoyUzV3aFROdGRONnJuSG5t?= =?utf-8?B?ai9xcGp4SExFT1g5c0FBbXhsTjgySENZakJxWUk5NEtmWlJnRUxaTXk5RHNl?= =?utf-8?B?Y3dpYVYzUDFvNHpSekkveGNMckNaSHhrYlVEalNMcEVjNkJjSWw4Sk1LZnZX?= =?utf-8?B?V3ZvdjBCenBFNWtycCtEZVRoNy9IZXorZDlBVlFLVXRWMzc3cU9DekZsVEZR?= =?utf-8?B?QmUzRDJnVWZtL09tOHpCWFlxdElDZk1MM2FNUE9aYmV3aWdhd05MaWVwQzVM?= =?utf-8?B?citzL2RzV3FxUnRZaEo2MWNML2ZER0lRd3NoNmRCS3NtWVJMRk1EWlJKeXJt?= =?utf-8?B?RlFkd3RsMjVHQUMvWld3MDVCb2NHdUdWcnBnME41MEJuRjlHTElaNG8rRmZo?= =?utf-8?B?VmZpYnBST0M3RVBlOStieXk4Wm85dEpYTWRmMmZYdUdZWi96UC80ZnRqazFD?= =?utf-8?B?REJZK3NKeFphQy9ZcEo5Y3hyM2dxbHlzZEJPTVpudkR0RW5BaXBkS2ZlSlMr?= =?utf-8?B?d3lPdC9RVnZ5RFlJSS8ybzR3bjYzdkx2YXVHYndnNTVZc0taK2dIK1RTVUM2?= =?utf-8?B?akdlNFdjWTM2azZlV0Fzb2E4OUs0R3dnRXRCenFjeXVyTlV4eUl4MXMwUVBO?= =?utf-8?B?cFVjUUhwSzRtOHVpVTh1aUM2MHRjdkU2bTlqd2F4bGU0dFZLRUZLbkg3aHNG?= =?utf-8?B?MTVvVHFMRGdGaXhsWFJ5dWUvYmxLTDVVaWlXUUN3NFA0L1pZUTNFOFpaU1VI?= =?utf-8?B?ZTJxL0xOMXBxbnMwbXdXNGN1cWovWS9vRllmMGhEaEhYMWlEYm5QQ242Ulg3?= =?utf-8?B?WTBvdjdpWXlqbGdBR0NkcUsrN2taeE1JcjQ4VWE3b1l6REJGVDlQcWY1WkZN?= =?utf-8?B?QVM3cTYva3ZRL0ErU2NhaXMxOWFzRExCOVJaQ2FyM0hLNXMwRzAvNVh2SVZW?= =?utf-8?Q?ZdqDzH+uTpGKS?= x-microsoft-antispam-prvs: x-forefront-prvs: 09555FB1AD x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(376002)(346002)(136003)(39860400002)(366004)(199004)(189003)(6436002)(97736004)(446003)(5660300002)(186003)(86362001)(6306002)(106356001)(11346002)(83716004)(105586002)(476003)(6486002)(53936002)(478600001)(7736002)(305945005)(2616005)(46003)(6512007)(486006)(2906002)(53546011)(6116002)(82746002)(8676002)(966005)(102836004)(8936002)(256004)(33656002)(68736007)(76176011)(71190400001)(71200400001)(4326008)(6506007)(36756003)(6246003)(66574012)(81156014)(229853002)(316002)(99286004)(6346003)(14454004)(14444005)(54906003)(110136005)(58126008)(25786009)(81166006); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR11MB2022; H:CY4PR11MB1559.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=xiaoqzhu@cisco.com; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 0C80SQxhPYeKy8uNAvn9XXSFLGn9YD0XxH/pH3ALg6e3wDGjaghpI6UkEkI//+tX3yPGSiJNbgxjDfi70T9kkwP6yDbk3fyBL6uLjz3aU02JQXsE1PBiko4uowEGTK0nLOQ4aN/Omw/P0wwCkwL5/CxroPbNvNqJvnL+2+680A4ahVTpGOQH1B51BVgs7EZxY+JBiJiQKEBGV4vFScmMaqsE+x09EB89BaxRpxYxJttINaMNZPBp+P9HPdxxNt1rXyi/8TjDGCx26yaHhPXjxmibZeNxvCycJCn5T/S5C4t5oEHN/qsP/yGr7PGZREGeuxMx3zh35rsND/WeA1y05bdkVEn/zTFdI1PlXtdMELuZTx/xcE93WLay3zUYbT5df6tMn1vjAXrAxwfxD//5Kix79qWRNUJ6CP2hsQJO9n4= Content-Type: text/plain; charset="utf-8" Content-ID: <0FC37502C744FE4592EAFD3242E9C27F@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 6afe1a04-f5f0-43d0-f94f-08d6981ec789 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Feb 2019 17:05:28.2822 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR11MB2022 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.21, xch-aln-011.cisco.com X-Outbound-Node: rcdn-core-7.cisco.com Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-rmcat-video-traffic-model-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2019 17:05:35 -0000 SGVsbG8sIA0KDQpUaGFua3MgdG8gWW9hdiBmb3IgeW91ciByZXZpZXcgYW5kIHRvIENvbGluIGZv ciBjaGltaW5nIGluIHdpdGggeW91ciBjb21tZW50cy4gDQoNCldlIGF1dGhvcnMgaGF2ZSBkaXNj dXNzZWQgb3ZlciBlbWFpbCByZWdhcmRpbmcgdGhpcyBzZWN0aW9uLiBXZSByZWNlbnRseSBzdWJt aXR0ZWQgdGhlDQp1cGRhdGVkIGRyYWZ0ICh2ZXJzaW9uIC0wNykuICBUaGUgdGV4dCBoYXMgYmVl biByZXZpc2VkIGFzIGJlbG93IHRvIGNsYXJpZnkgdGhhdCB0aGlzIGRyYWZ0DQppdHNlbGYgZG9l cyBub3QgaW1wb3NlIHNlY3VyaXR5IGNvbmNlcm5zLiBJbnN0ZWFkLCBpdCBjYW4gYmUgdXNlZCBm b3IgZXZhbHVhdGluZyBjYW5kaWRhdGUNCmFsZ29yaXRobXMgdG8gcHJldmVudCB0aGVtIGZyb20g aHVydGluZyB0aGUgSW50ZXJuZXQ6IA0KDQpUaGUgc3ludGhldGljIHZpZGVvIHRyYWZmaWMgbW9k ZWxzIGFzIGRlc2NyaWJlZCBpbiB0aGlzIGRyYWZ0IGRvIG5vdA0KICAgaW1wb3NlIGFueSBzZWN1 cml0eSB0aHJlYXRzLiAgVGhleSBhcmUgZGVzaWduZWQgdG8gbWltaWMgcmVhbGlzdGljDQogICB0 cmFmZmljIHBhdHRlcm5zIGZvciBldmFsdWF0aW5nIGNhbmRpZGF0ZSBSVFAtYmFzZWQgY29uZ2Vz dGlvbg0KICAgY29udHJvbCBhbGdvcml0aG1zLCBzbyBhcyB0byBlbnN1cmUgc3RhYmxlIG9wZXJh dGlvbnMgb2YgdGhlIG5ldHdvcmsuDQogICBJdCBpcyBSRUNPTU1FTkRFRCB0aGF0IGNhbmRpZGF0 ZSBhbGdvcml0aG1zIGJlIHRlc3RlZCB1c2luZyB0aGUgdmlkZW8NCiAgIHRyYWZmaWMgbW9kZWxz IHByZXNlbnRlZCBpbiB0aGlzIGRyYWZ0IGJlZm9yZSB3aWRlIGRlcGxveW1lbnQgb3Zlcg0KICAg dGhlIEludGVybmV0LiAgSWYgdGhlIGdlbmVyYXRlZCBzeW50aGV0aWMgdHJhZmZpYyBmbG93cyBh cmUgc2VudCBvdmVyDQogICB0aGUgSW50ZXJuZXQsIHRoZXkgYWxzbyBuZWVkIHRvIGJlIGNvbmdl c3Rpb24gY29udHJvbGxlZC4NCg0KUGxlYXNlIGxldCB1cyBrbm93IGlmIHRoZSBhYm92ZSByZXZp c2VkIHZlcnNpb24gaXMgc3VmZmljaWVudCBpbiBhZGRyZXNzaW5nIHlvdXIgY29uY2VybnMuIEZ1 cnRoZXINCmRpc2N1c3Npb25zL3N1Z2dlc3Rpb25zIGFyZSB3ZWxjb21lLiANCg0KQmVzdCByZWdh cmRzLA0KWGlhb3FpbmcgKG9uIGJlaGFsZiBvZiBhbGwgYXV0aG9ycykuIA0KDQoNCg0K77u/T24g MS8yNC8xOSwgMTo0MCBQTSwgIkNvbGluIFBlcmtpbnMiIDxjc3BAY3NwZXJraW5zLm9yZz4gd3Jv dGU6DQoNCiAgICA+IE9uIDI0IEphbiAyMDE5LCBhdCAxOToyMywgWW9hdiBOaXIgPHluaXIuaWV0 ZkBnbWFpbC5jb20+IHdyb3RlOg0KICAgID4gDQogICAgPiBSZXZpZXdlcjogWW9hdiBOaXINCiAg ICA+IFJldmlldyByZXN1bHQ6IEhhcyBOaXRzDQogICAgPiANCiAgICA+IEkgaGF2ZSByZXZpZXdl ZCB0aGlzIGRvY3VtZW50IGFzIHBhcnQgb2YgdGhlIHNlY3VyaXR5IGRpcmVjdG9yYXRlJ3Mgb25n b2luZw0KICAgID4gZWZmb3J0IHRvIHJldmlldyBhbGwgSUVURiBkb2N1bWVudHMgYmVpbmcgcHJv Y2Vzc2VkIGJ5IHRoZSBJRVNHLiAgRG9jdW1lbnQNCiAgICA+IGVkaXRvcnMgYW5kIFdHIGNoYWly cyBzaG91bGQgdHJlYXQgdGhlc2UgY29tbWVudHMganVzdCBsaWtlIGFueSBvdGhlciBsYXN0IGNh bGwNCiAgICA+IGNvbW1lbnRzLg0KICAgID4gDQogICAgPiBUbyBxdW90ZSBmcm9tIHRoZSBhYnN0 cmFjdCwgdGhlIGRvY3VtZW50ICJkZXNjcmliZXMgdHdvIHJlZmVyZW5jZSB2aWRlbyB0cmFmZmlj DQogICAgPiBtb2RlbHMgZm9yIGV2YWx1YXRpbmcgUlRQIGNvbmdlc3Rpb24gY29udHJvbCBhbGdv cml0aG1zIi4gSW5kZWVkIGl0IGRvZXMgbm90DQogICAgPiBkZXNjcmliZSBhbnkgcHJvdG9jb2wg b3IgYWxnb3JpdGhtIHRoYXQgaXMgZ29pbmcgdG8gZ2V0IGRlcGxveWVkIG9uIHRoZQ0KICAgID4g SW50ZXJuZXQsIGJ1dCByYXRoZXIgYSBtb2RlbCBmb3IgZXZhbHVhdGluZyBjb25nZXN0aW9uIGNv bnRyb2wgYWxnb3JpdGhtIGJlZm9yZQ0KICAgID4gdGhleSBhcmUgc3RhbmRhcmRpemVkIG9yIGRl cGxveWVkLiBBcyBzdWNoLCBJIHdvdWxkIG5vdCBleHBlY3QgaXQgdG8gaGF2ZSBtdWNoDQogICAg PiB0byBzYXkgb24gc2VjdXJpdHksIGVpdGhlciBnb29kIG9yIGJhZC4NCiAgICA+IA0KICAgID4g SXQgaXMgY29uY2VpdmFibGUgdGhhdCBhIGNvbmdlc3Rpb24gY29udHJvbCBhbGdvcml0aG0gd291 bGQgYmUgZXhwbG9pdGFibGUgYnkNCiAgICA+IGFuIGF0dGFja2VyLiBGb3IgZXhhbXBsZSwgc29t ZSBwYXR0ZXJuIG9mIHRyYWZmaWMgbWlnaHQgdHJpZ2dlciBzdWNoIGFuDQogICAgPiBhbGdvcml0 aG0gdG8gYmxvY2sgb3Igc2xvdyBkb3duIHRyYWZmaWMgZm9yIGEgdmljdGltLiBJdCBtYXkgYmUg YSBnb29kIGlkZWEgdG8NCiAgICA+IGV2YWx1YXRlIHdoZXRoZXIgc3VjaCBhbGdvcml0aG1zIGFy ZSBjb25kdWNpdmUgdG8gc3VjaCBhdHRhY2tzLiBCdXQgc3BlY3VsYXRpb24NCiAgICA+IHN1Y2gg YXMgdGhpcyBhcmUgbm90IHJlbGF0ZWQgdG8gdGhlIGRyYWZ0LiBUaGlzIGRyYWZ0IGlzIGFib3V0 IGV2YWx1YXRpbmcNCiAgICA+IGNvbmdlc3Rpb24gY29udHJvbCBhbGdvcml0aG1zIGZvciB0aGVp ciBlZmZlY3Qgb24gdmlkZW8gcXVhbGl0eSBhbmQgZnJhbWUgcmF0ZXMuDQogICAgPiANCiAgICA+ IFNvIHdoYXQgaXMgbXkgbml0IHdpdGggdGhpcz8gIFdoeSBkb2VzIHRoZSBTZWN1cml0eSBDb25z aWRlcmF0aW9ucyBzZWN0aW9uDQogICAgPiBjb250YWlucyB3aGF0IGl0IGRvZXM/DQogICAgPiAN CiAgICA+ICAgSXQgaXMgaW1wb3J0YW50IHRvIGV2YWx1YXRlIFJUUC1iYXNlZCBjb25nZXN0aW9u IGNvbnRyb2wgc2NoZW1lcw0KICAgID4gICB1c2luZyByZWFsaXN0aWMgdHJhZmZpYyBwYXR0ZXJu cywgc28gYXMgdG8gZW5zdXJlIHN0YWJsZSBvcGVyYXRpb25zDQogICAgPiAgIG9mIHRoZSBuZXR3 b3JrLiAgVGhlcmVmb3JlLCBpdCBpcyBSRUNPTU1FTkRFRCB0aGF0IGNhbmRpZGF0ZSBSVFAtDQog ICAgPiAgIGJhc2VkIGNvbmdlc3Rpb24gY29udHJvbCBhbGdvcml0aG1zIGJlIHRlc3RlZCB1c2lu ZyB0aGUgdmlkZW8gdHJhZmZpYw0KICAgID4gICBtb2RlbHMgcHJlc2VudGVkIGluIHRoaXMgZHJh ZnQgYmVmb3JlIHdpZGUgZGVwbG95bWVudCBvdmVyIHRoZQ0KICAgID4gICBJbnRlcm5ldC4NCiAg ICA+IA0KICAgID4gVGhpcyBpcyBpbnRlcmVzdGluZywgYnV0IEkgZG9uJ3QgdGhpbmsgaXQgaGFz IG11Y2ggdG8gZG8gd2l0aCBzZWN1cml0eS4gSU1PIGl0DQogICAgPiB3b3VsZCBiZSBlbm91Z2gg dG8gc2F5IHRoYXQgdGhpcyBkb2N1bWVudCBpbnRyb2R1Y2VzIG1vZGVscyBmb3IgZXZhbHVhdGlv biBhbmQNCiAgICA+IGRvZXNuJ3QgaGF2ZSBhbnkgc2VjdXJpdHkgaW1wbGljYXRpb25zLiAgVGhl IGV4aXN0aW5nIHRleHQgc2hvdWxkIGdvIHNvbWV3aGVyZQ0KICAgID4gZWxzZS4NCiAgICANCiAg ICBUbyBteSBtaW5kLCB0aGUgc2VjdXJpdHkgaW1wbGljYXRpb24gaXMgdGhhdCB0aGUgYWxnb3Jp dGhtIGJlIHRlc3RlZCB0byBkZW1vbnN0cmF0ZSB0aGF0IGl0IGRvZXNu4oCZdCBjYXVzZSBkZW5p YWwtb2Ytc2VydmljZSB3aGVuIG9wZXJhdGluZyB3aXRoIHJlYWxpc3RpYyB0cmFmZmljLiBUaGlz IGNvdWxkIGJlLCBhcyB5b3Ugbm90ZSBhYm92ZSwgdGhhdCBpdCBkaXNydXB0cyB0aGUgdmlkZW8g YXBwbGljYXRpb24gYnkgZm9yY2luZyB0aGUgc2VuZGluZyByYXRlIHRvIHplcm87IGJ1dCBpdOKA mXMgYWxzbyBpbXBvcnRhbnQgdG8gY2hlY2sgdGhhdCBpdCBkb2VzbuKAmXQgc2VuZCBvdmVybHkg cXVpY2tseSBhbmQgY29uZ2VzdCB0aGUgbmV0d29yaywgc28gZGVueWluZyBzZXJ2aWNlIHRvIG90 aGVyIGZsb3dzLiANCiAgICANCiAgICAtLSANCiAgICBDb2xpbiBQZXJraW5zDQogICAgaHR0cHM6 Ly9jc3BlcmtpbnMub3JnLw0KICAgIA0KICAgIA0KICAgIA0KICAgIA0KICAgIA0KDQo= From nobody Fri Feb 22 01:58:43 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EB45124BF6; Fri, 22 Feb 2019 01:58:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 JJd6MojXkx4W; Fri, 22 Feb 2019 01:58:36 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21573124D68; Fri, 22 Feb 2019 01:58:35 -0800 (PST) Received: from lhreml708-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 87217FD0604ADCFB3C26; Fri, 22 Feb 2019 09:58:32 +0000 (GMT) Received: from lhreml709-chm.china.huawei.com (10.201.108.58) by lhreml708-cah.china.huawei.com (10.201.108.49) with Microsoft SMTP Server (TLS) id 14.3.408.0; Fri, 22 Feb 2019 09:58:32 +0000 Received: from lhreml709-chm.china.huawei.com (10.201.108.58) by lhreml709-chm.china.huawei.com (10.201.108.58) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1591.10; Fri, 22 Feb 2019 09:58:31 +0000 Received: from DGGEMM421-HUB.china.huawei.com (10.1.198.38) by lhreml709-chm.china.huawei.com (10.201.108.58) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1591.10 via Frontend Transport; Fri, 22 Feb 2019 09:58:31 +0000 Received: from DGGEMM528-MBX.china.huawei.com ([169.254.8.114]) by dggemm421-hub.china.huawei.com ([10.1.198.38]) with mapi id 14.03.0415.000; Fri, 22 Feb 2019 17:58:25 +0800 From: "Yemin (Amy)" To: Sandra Murphy , "secdir@ietf.org" CC: "ccamp@ietf.org" , "draft-ietf-ccamp-rsvp-te-bandwidth-availability.all@ietf.org" Thread-Topic: Secdir last call review of draft-ietf-ccamp-rsvp-te-bandwidth-availability-13 Thread-Index: AQHUuqwWHpLws/0qnkGGhYcJXbfKyaXk9tGggAa5hMA= Date: Fri, 22 Feb 2019 09:58:25 +0000 Message-ID: <9C5FD3EFA72E1740A3D41BADDE0B461FCFB598CD@DGGEMM528-MBX.china.huawei.com> References: <154908012600.28521.5714645741731093529@ietfa.amsl.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.169.30.234] Content-Type: multipart/alternative; boundary="_000_9C5FD3EFA72E1740A3D41BADDE0B461FCFB598CDDGGEMM528MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-ccamp-rsvp-te-bandwidth-availability-13 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2019 09:58:40 -0000 --_000_9C5FD3EFA72E1740A3D41BADDE0B461FCFB598CDDGGEMM528MBXchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgU2FuZHJhLA0KDQpNYW55IHRoYW5rcyBmb3IgdGhlIGRldGFpbCByZXZpZXcgY29tbWVudHMs IHBsZWFzZSBzZWUgcmVwbHkgaW5saW5lIGJlbG93Lg0KQW5kIEnigJltIHZlcnkgc29ycnkgZm9y IHRoZSBsYXRlIHJlcGx5Lg0KDQpCUiwNCkFteQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KRnJvbTogU2FuZHJhIE11cnBoeSBbbWFpbHRvOnNhbmR5QHRpc2xhYnMuY29tXQ0KU2VudDog U2F0dXJkYXksIEZlYnJ1YXJ5IDAyLCAyMDE5IDEyOjAyIFBNDQpUbzogc2VjZGlyQGlldGYub3Jn PG1haWx0bzpzZWNkaXJAaWV0Zi5vcmc+DQpDYzogY2NhbXBAaWV0Zi5vcmc8bWFpbHRvOmNjYW1w QGlldGYub3JnPjsgaWV0ZkBpZXRmLm9yZzxtYWlsdG86aWV0ZkBpZXRmLm9yZz47IGRyYWZ0LWll dGYtY2NhbXAtcnN2cC10ZS1iYW5kd2lkdGgtYXZhaWxhYmlsaXR5LmFsbEBpZXRmLm9yZzxtYWls dG86ZHJhZnQtaWV0Zi1jY2FtcC1yc3ZwLXRlLWJhbmR3aWR0aC1hdmFpbGFiaWxpdHkuYWxsQGll dGYub3JnPg0KU3ViamVjdDogU2VjZGlyIGxhc3QgY2FsbCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1j Y2FtcC1yc3ZwLXRlLWJhbmR3aWR0aC1hdmFpbGFiaWxpdHktMTMNCg0KDQoNClJldmlld2VyOiBT YW5kcmEgTXVycGh5DQoNClJldmlldyByZXN1bHQ6IEhhcyBJc3N1ZXMNCg0KDQoNCkkgaGF2ZSBy ZXZpZXdlZCB0aGlzIGRvY3VtZW50IGRyYWZ0LWlldGYtY2NhbXAtcnN2cC10ZS1iYW5kd2lkdGgt YXZhaWxhYmlsaXR5DQoNCmFzIHBhcnQgb2YgdGhlIHNlY3VyaXR5IGRpcmVjdG9yYXRl4oCZcyBv bmdvaW5nIGVmZm9ydCB0byByZXZpZXcgYWxsIElFVEYgZG9jdW1lbnRzIGJlaW5nIHByb2Nlc3Nl ZCBieSB0aGUgSUVTRy4gVGhlc2UgY29tbWVudHMgd2VyZSB3cml0dGVuIHByaW1hcmlseSBmb3Ig dGhlIGJlbmVmaXQgb2YgdGhlIHNlY3VyaXR5IGFyZWEgZGlyZWN0b3JzLiAgRG9jdW1lbnQgZWRp dG9ycyBhbmQgV0cgY2hhaXJzIHNob3VsZCB0cmVhdCB0aGVzZSBjb21tZW50cyBqdXN0IGxpa2Ug YW55IG90aGVyIGxhc3QgY2FsbCBjb21tZW50cy4NCg0KDQoNClRoaXMgZHJhZnQgcHJvdmlkZXMg YSBuZXcgVExWIGZvciB0aGUgRXRoZXJuZXQgU0VOREVSX1RTUEVDIG9iamVjdCB0aGF0IHdpbGwg Y2FycnkgYXZhaWxhYmlsaXR5IHJlcXVpcmVtZW50cyBmb3IgUlNWUC1URSBzaWduYWxpbmcgb2Yg R01QTFMgTFNQcy4NCg0KDQoNClRoZSBkcmFmdCBpcyB0aG9yb3VnaC4gIEkgZG8gaGF2ZSBzb21l IGNvbW1lbnRzLiAgSSByZXZpZXdlZCB0aGUgbm9ybWF0aXZlIHJlZmVyZW5jZXMgUkZDcyAyMjA1 LCAzMjA5LCAzNDczLCA2MDAzLCBhcyB3ZWxsIGFzIFJGQzM5NDUgYW5kIFJGQzU5MjAuICBJIGNh buKAmXQgY2xhaW0gdGhhdCBJIHVuZGVyc3Rvb2QgZXZlcnl0aGluZyBpbiB0aGF0IHN0YWNrLCBz byB0aGUgZm9sbG93aW5nIGNvdWxkIGVhc2lseSBiZSB3cm9uZy4NCg0KDQoNCkNvbXB1dGluZyB0 aGUgTFNQIHBhdGg6DQoNCg0KDQpQYWdlIDQsIHNlY3Rpb24gMiBkaXNjdXNzZXMgb2J0YWluaW5n IG5ldHdvcmsgdG9wb2xvZ3ksIGNhbGN1bGF0aW5nIHRoZSBMU1Agcm91dGUsIFJGQzgzMzDigJlz IGV4dGVuc2lvbnMgZm9yIGF2YWlsYWJpbGl0eSBpbiBPU1BGIFRFIExTQSBtZXNzYWdlcy4gIERv ZXMgdGhpcyBkcmFmdCBhc3N1bWUgdGhhdCB0aGlzIGV4dGVuc2lvbiB3aWxsIGFsd2F5cyBiZSB1 c2VkIHdpdGggYW4gRVhQTElDSVRfUk9VVEUgb2JqZWN0PyAgSXMgdGhpcyBkcmFmdCBub3QgYXBw bGljYWJsZSB3aXRob3V0IHRoYXQgZXhwbGljaXQgTFNQIHJvdXRlIGNhbGN1bGF0aW9uPw0KDQpb QW15XSBObywgdGhlcmUncyBubyBhc3N1bXB0aW9uIHRoYXQgdGhlIGV4dGVuc2lvbiBjYW4gYmUg b25seSB1c2VkIHdpdGggYW4gRVhQTElDSVRfUk9VVEUgb2JqZWN0LiAgVGhlIG5vZGUgd2hvIG9i dGFpbnMgbmV0d29yayB0b3BvbG9neSwgY2FsY3VsYXRlcyB0aGUgTFNQIHJvdXRlLCBjb3VsZCBi ZSBhIHNvdXJjZSBub2RlIGFuZCBpbnRlcm1lZGlhdGUgbm9kZXMuDQoNCkF2YWlsYWJpbGl0eSBU TFYgdnMgQ0xBU1NUWVBFIG9iamVjdHM6DQoNCg0KDQpUaGUgZGVmaW5pdGlvbiBpbiBSRkM2MDAz IG9mIHRoZSBCYW5kd2lkdGggUHJvZmlsZSBUTFYgaGFzIGNlcnRhaW4gY29uc3RyYWludHMgb24g dGhlIHZhbHVlcyBvZiB0aGUgSW5kZXg6DQoNCiAgICAgICAgICAgICAgICAgICAgICAgICBUaGUg SW5kZXggZmllbGQgdmFsdWUgTVVTVCBjb3JyZXNwb25kIHRvIGF0IGxlYXN0IG9uZQ0KDQogICAg ICBvZiB0aGUgQ2xhc3MtVHlwZSB2YWx1ZXMgaW5jbHVkZWQgZWl0aGVyIGluIHRoZSBDTEFTU1RZ UEUgb2JqZWN0DQoNCiAgICAgIFtSRkM0MTI0XSBvciBpbiB0aGUgRVhURU5ERURfQ0xBU1NUWVBF IG9iamVjdCBbTUNPU10uDQoNCg0KDQpJIGFtIG5vdCBjZXJ0YWluIGlmIHRoaXMgbWVhbnMgdGhh dCB0aGUgcHJlc2VuY2Ugb2YgYW4gRXRoZXJuZXQgU0VOREVSX1RTUEVDIE9iamVjdCB3aXRoIGEg QmFuZHdpZHRoIFByb2ZpbGUgVExWIG1lYW5zIHRoZXJlIG11c3QgYmUgYSBDTEFTU1RZUEUgb2Jq ZWN0IGluIHRoZSBSU1ZQLVRFIG1lc3NhZ2UgYXMgd2VsbCwgb3IgdGhhdCB0aGUgSW5kZXggZmll bGQgdmFsdWVzIGFyZSB0YWtlbiBmcm9tIHRoZSBzZXQgb2YgZGVmaW5lZCBDbGFzcy1UeXBlIHZh bHVlcy4NCg0KDQoNCkJ1dCBpZiB0aGUgZmlyc3QsIGRvZXMgdGhpcyBpbmR1Y2UgcmVxdWlyZW1l bnRzIGJ5IGluY2x1c2lvbiBvZiB0aGUgQXZhaWxhYmlsaXR5IFRMViB0aGF0IHRoZXNlIG90aGVy IENMQVNTVFlQRSBvYmplY3RzIG11c3QgYmUgaW5jbHVkZWQgYXMgd2VsbD8NCg0KT3IgYXJlIHlv dSBpbnRlbmRpbmcgdG8gdXBkYXRlIFJGQzYwMDMgdG8gZWxpbWluYXRlIHRoYXQgY29uc3RyYWlu dD8gIElmIHRoZSBzZWNvbmQsIGRvZXMgdGhlIFJGQzYwMDMgY29uc3RyYWludCBhbHNvIGNvbnN0 cmFpbiB0aGUgaW5kZXggdmFsdWVzIHVzZWQgaW4gdGhlIEF2YWlsYWJpbGl0eSBUTFY/ICBTaG91 bGQgdGhhdCBiZSBtZW50aW9uZWQ/ICAoT3IgYW0gSSBqdXN0IGNvbmZ1c2VkPykNCg0KW0FteV0g SXTigJlzIHRoZSBzZWNvbmQgY2FzZS4gVGhlIFJGQzYwMDMgY29uc3RyYWludCBzaG91bGQgYWxz byBhcHBseSB0byB0aGUgaW5kZXggdmFsdWVzIHVzZWQgaW4gdGhlIEF2YWlsYWJpbGl0eSBUTFYu IFRoZSBjdXJyZW50IHRleHQgc3RhdGVzIHRoYXQg4oCcaGF2aW5nIHRoZSBzYW1lIHZhbHVlIG9m IEluZGV4IGZpZWxk4oCdLCB3aGljaCBpbXBsaWVzIHRoZSBzYW1lIGNvbnN0cmFpbnQuDQoNCg0K DQpCYW5kd2lkdGggVExWIHRvIEF2YWlsYWJpbGl0eSBUTFYgYXNzb2NpYXRpb246DQoNCg0KDQpQ YWdlIDQsIFNlY3Rpb24gMy4xIHNheXMNCg0KDQoNCiAgICAgIFdoZW4gdGhlIEF2YWlsYWJpbGl0 eSBUTFYgaXMgaW5jbHVkZWQsIGl0IE1VU1QgYmUgcHJlc2VudCBhbG9uZw0KDQogICAgICB3aXRo IHRoZSBFdGhlcm5ldCBCYW5kd2lkdGggUHJvZmlsZSBUTFYuIElmIHRoZSBiYW5kd2lkdGgNCg0K ICAgICAgcmVxdWlyZW1lbnRzIGluIHRoZSBtdWx0aXBsZSBFdGhlcm5ldCBCYW5kd2lkdGggUHJv ZmlsZSBUTFZzIGhhdmUNCg0KICAgICAgZGlmZmVyZW50IEF2YWlsYWJpbGl0eSByZXF1aXJlbWVu dHMsIG11bHRpcGxlIEF2YWlsYWJpbGl0eSBUTFZzDQoNCiAgICAgIFNIT1VMRCBiZSBjYXJyaWVk LiBJbiBzdWNoIGEgY2FzZSwgdGhlIEF2YWlsYWJpbGl0eSBUTFYgaGFzIGEgb25lDQoNCiAgICAg IHRvIG9uZSBjb3JyZXNwb25kZW5jZSB3aXRoIHRoZSBFdGhlcm5ldCBCYW5kd2lkdGggUHJvZmls ZSBUTFYgYnkNCg0KICAgICAgaGF2aW5nIHRoZSBzYW1lIHZhbHVlIG9mIEluZGV4IGZpZWxkLiBJ ZiBhbGwgdGhlIGJhbmR3aWR0aA0KDQogICAgICByZXF1aXJlbWVudHMgaW4gdGhlIEV0aGVybmV0 IEJhbmR3aWR0aCBQcm9maWxlIGhhdmUgdGhlIHNhbWUNCg0KICAgICAgQXZhaWxhYmlsaXR5IHJl cXVpcmVtZW50LCBvbmUgQXZhaWxhYmlsaXR5IFRMViBTSE9VTEQgYmUgY2FycmllZC4NCg0KICAg ICAgSW4gdGhpcyBjYXNlLCB0aGUgSW5kZXggZmllbGQgaXMgc2V0IHRvIDAuDQoNCg0KDQpJIGZp bmQgdGhhdCB0aGUgZGVzY3JpcHRpb24gaXMgbm90IGNsZWFyIGluIGFsbCBjYXNlcy4gIEkgZm91 bmQgYSBtZXNzYWdlIGluIHRoZSB3b3JraW5nIGdyb3VwIGRpc2N1c3Npb24gb2YgdGhpcyBhc3Nv Y2lhdGlvbiB0aGF0IHRoZSBhc3NvY2lhdGlvbiBpcyBlaXRoZXIg4oCcbjpu4oCdIG9yIOKAnG46 MeKAnS4gIEkgdGhpbmsgdGhpcyBkZXNjcmlwdGlvbiBzb3VuZHMgbW9yZSBsaWtlIG4gMToxIGFz c29jaWF0aW9ucw0KDQpvciBhICBuOjEgYXNzb2NpYXRpb24uICAgSXMgdGhhdCB3aGF0IGlzIGlu dGVuZGVkPyAgQ2FuIHRoZSBhc3NvY2lhdGlvbnMgYmUNCg0KbWl4ZWQgaW4gdGhlIHNhbWUgbWVz c2FnZT8gIFN1cHBvc2UgdGhlcmUgd2VyZSAzIEJhbmR3aWR0aCBUTFZzIHRoYXQgbmVlZGVkIHRo ZSBzYW1lIGF2YWlsYWJpbGl0eSBhbmQgb25lIHRoYXQgaGFkIGEgZGlmZmVyZW50IGF2YWlsYWJp bGl0eSBuZWVkLCBjb3VsZCB0aGVyZSBiZSAzIEJhbmR3aWR0aCBUTFZzIHdpdGggaW5kZXggMCBh bmQgb25lIEF2YWlsYWJpbGl0eS1UTFYgd2l0aCBpbmRleCAwIGFuZCBhbHNvIGEgQmFuZHdpZHRo IFRMVnMgLSBBdmFpbGFiaWxpdHkgVExWIHBhaXIgd2l0aCBtYXRjaGluZyBpbmRleCB2YWx1ZXM/ DQoNCltBbXldIFRoYW5rcyBmb3IgbG9va2luZyBpbnRvIHRoZSBwYXN0IGRpc2N1c3Npb24uIFRo ZSBpbnRlbnNpb24gd2FzIG4qKDE6MSkgYXNzb2NpYXRpb24gb3IgbjoxIGFzc29jaWF0aW9uLiBJ dCB3YXMgbm90IHNvIGFjY3VyYXRlIGJ5IHVzaW5nIOKAnG46buKAnSBhc3NvY2lhdGlvbiBpbiB0 aGUgcGFzdC4NCg0KUmVnYXJkaW5nIHRoZSBleGFtcGxlIHlvdSBsaXN0LCBpZiB0aGUgZm91ciBC YW5kd2lkdGggVExWcyBhcmUgc2VudCBpbiB0aGUgc2FtZSBtZXNzYWdlLCBpdOKAmXMgYmV0dGVy IHRvIHVzZSBmb3VyIGRpZmZlcmVudCBpbmRleCB2YWx1ZXMgYXMgdGhleSBhcmUg4oCcbXVsdGlw bGUgRXRoZXJuZXQgQmFuZHdpZHRoIFByb2ZpbGUgVExWcyBoYXZlIGRpZmZlcmVudCBBdmFpbGFi aWxpdHkgcmVxdWlyZW1lbnRz4oCdLg0KDQpPZiBjb3Vyc2Ugd2hhdCB5b3UgcHJvcG9zZWQgY291 bGQgYWxzbyB3b3JrIHRlY2huaWNhbGx5Lg0KDQoNCg0KZXJyb3IgY2hlY2tpbmc6DQoNCg0KDQpP dGhlciBkb2N1bWVudHMgaW4gdGhlIHJlZmVyZW5jZXMgKFJGQzIyMDUsIDMyMDksIDM0NzMsIDYw MDMsIGV0YykgaGF2ZSBtYWRlIGEgcG9pbnQgb2YgZXhwbGljaXRseSBkZXNjcmliaW5nIHRoZSBl cnJvciBoYW5kbGluZyAtIHdoZW4gUGF0aEVyciBhbmQgUmVzdkVyciBhbmQgTm90aWZ5IG1lc3Nh Z2VzIGFyZSBzZW50LCB0byB3aG9tLCB0aGUgZXJyb3IgY29kZXMsIHRoZSBlcnJvciB2YWx1ZSBz dWItY29kZXMsIGV0Yy4gIEkgZG9u4oCZdCBzZWUgdGhhdCBoZXJlIGZvciB0aGUgYmFuZHdpZHRo LXRsdi10by1hdmFpbGFiaWxpdHktdGx2IGFzc29jaWF0aW9ucy4NCg0KW0FteV0gVGhhbmtzIGZv ciB0aGUgY29tbWVudCwgSSBhZ3JlZSB0aGUgZXJyb3IgcHJvY2VzcyBzaG91bGQgYmUgY2xlYXJl ci4NCg0KSXMgYSBtaXggb2YgaW5kZXgtemVybyBhbmQgaW5kZXgtbm9uLXplcm8gYmFuZHdpZHRo LXRsdi10by1hdmFpbGFiaWxpdHktdGx2IGFzc29jaWF0aW9ucyAobGlrZSBhYm92ZSkgYW4gZXJy b3I/IGlzIHRoZSBtZXNzYWdlIGRyb3BwZWQ/ICBpcyBhbiBlcnJvciBzZW50Pw0KDQppZiB0aGUg bWVzc2FnZSBpcyBub3QgZHJvcHBlZCwgYXJlIGFueSBvZiB0aGUgYmFuZHdpZHRoLXRsdiwgYXZh aWxhYmlsaXR5LXRsdiBhc3NvY2lhdGlvbnMgcmV0YWluZWQ/DQoNCltBbXldIFRoZSBtZXNzYWdl IE1BWSBiZSBpZ25vcmVkIGFuZCBTSE9VTEQgTk9UIGJlIHByb3BhZ2F0ZWQuDQoNCklmIHRoZXJl IGFyZSBhdmFpbGFiaWxpdHktdGx2cyB3aXRoIG5vbi16ZXJvIGluZGV4ZXMgd2l0aCBubyBtYXRj aGluZyBpbmRleCB2YWx1ZSBhbW9uZyB0aGUgYmFuZHdpZHRoLXRsdnMsIHRoYXQgc3VyZWx5IGlz IGFuIGVycm9yPyAgSXMgdGhlIG1lc3NhZ2UgZHJvcHBlZD8gIE9yIGlzIHRoZSBhdmFpbGFiaWxp dHkgdGx2IGRyb3BwZWQ/ICBJcyBhIFBhdGhFcnIvUmVzdkVyciBtZXNzYWdlIHNlbnQ/DQoNCltB bXldIHllcywgdGhpcyBpcyBhbiBlcnJvci4gSXTigJlzIHByZWZlcnJlZCB0byBkcm9wIHRoZSBh dmFpbGFiaWxpdHkgdGx2Lg0KDQpTdXBwb3NlIGFsbCBhdmFpbGFiaWxpdHktdGx2cyBoYXZlIGEg bWF0Y2hpbmcgKHplcm8gb3Igbm9uLXplcm8pIGluZGV4IHZhbHVlIGFtb25nIHRoZSBiYW5kd2lk dGgtdGx2cywgYnV0IHRoZXJlIGFyZSBleHRyYSBiYW5kd2lkdGgtdGx2cyAobm8gYXZhaWxhYmls aXR5LXRsdiB3aXRoIGEgbWF0Y2hpbmcgaW5kZXggdmFsdWUpLiAgSXMgdGhhdCBhbiBlcnJvcj8g IEFyZSB0aGUgZXh0cmEgYmFuZHdpZHRoLXRsdnMgZHJvcHBlZD8gaWdub3JlZD8gcHJvcGFnYXRl ZD8NCg0KW0FteV1UaGUgZXh0cmEgYmFuZHdpZHRoLXRsdnMgTUFZIGJlIGlnbm9yZWQgYW5kIFNI T1VMRCBOT1QgYmUgcHJvcGFnYXRlZC4NCg0KKFJGQzMyMDkgaGFzIHNldmVyYWwgY2FzZXMgd2hl cmUgdGhlcmUgbWlnaHQgYmUgZXh0cmEgb2JqZWN0cyBvciBzdWItb2JqZWN0cyBhbmQgdGhlIGxh bmd1YWdlIGlzIOKAnGNhbiBiZS9NQVkgYmUvU0hPVUxEIGJlL2FyZSBpZ25vcmVkIGFuZCBTSE9V TEQgTk9UIGJlIC9hcmUgbm90L25lZWQgbm90IGJlIHByb3BhZ2F0ZWTigJ0gKQ0KDQoNCg0KDQoN Cm11bHRpcGxpY2l0eToNCg0KDQoNClJGQzMyMDkgc2F5cyBpdCBkb2VzIG5vdCBhcHBseSB0byBt dWx0aWNhc3QsIGJ1dCBpdCBkb2VzIHRhbGsgYWJvdXQgbXVsdGlwbGUgcGFyYWxsZWwgTFNQIHR1 bm5lbHMgYmV0d2VlbiB0d28gbm9kZXMsIGFuZCBhYm91dCBtdWx0aXBvaW50LXRvLXBvaW50IExT UHMgZm9yIFdGIGFuZCBTRSBzdHlsZSByZXNlcnZhdGlvbnMgd2hlbiB0aGVyZSBhcmUgbXVsdGlw bGUgc2VuZGVycywgYW5kIGFib3V0IHRoZSBtZXJnaW5nIHJ1bGVzIG9mIFdGIHJlc2VydmF0aW9u cy4gIERvZXMgYXZhaWxhYmlsaXR5IHdvcmsgaW4gdGhvc2Ugc3R5bGUgcmVzZXJ2YXRpb25zPw0K DQpbQW15XSBDb25zaWRlcmluZyB0aGF0IHRoZSB0cmFmZmljIGZyb20gc2VuZGVycyBpcyBtb3Jl IGxpa2VseSB0byBiZSBjb25jdXJyZW50IGFuZCBpbmRlcGVuZGVudCwgdGhlIGF2YWlsYWJpbGl0 eSBUTFYgY2FuIGJlIGxpbWl0ZWQgdG8gRml4ZWQgRmlsdGVyIChGRikgU3R5bGUgb25seS4NCg0K YXZhaWxhYmlsaXR5IHZzIOKAnHZhcmlhYmxlIGRpc2NyZXRlIGJhbmR3aWR0aOKAnToNCg0KDQoN CkkgYmVsaWV2ZSBJIHVuZGVyc3Rvb2QgdGhlIGRpc2N1c3Npb24gb2YgdGhlIG5lZWQgdG8gc2ln bmFsIGF2YWlsYWJpbGl0eSByZXF1aXJlbWVudHMgaW4gb3JkZXIgZm9yIHRoZSBzeXN0ZW0gdG8g ZGV0ZXJtaW5lIHdoZW4gYW4gTFNQIHdhcyBmZWFzaWJsZS4gIEkgY2FuIGRpbWx5IHVuZGVyc3Rh bmQgdGhhdCB0aGVyZSBtaWdodCBiZSBsaW5rcyBoYXZlIOKAnHZhcmlhYmxlIGRpc2NyZXRlIGJh bmR3aWR0aOKAnS4gIFNlY3Rpb24gMiBzYXlzIOKAnFRoZSBBdmFpbGFiaWxpdHkgVExWIGNhbiBi ZSBhcHBsaWNhYmxlIHRvIGFueSBraW5kIG9mIHBoeXNpY2FsIGxpbmtzIHdpdGggdmFyaWFibGUg ZGlzY3JldGUgYmFuZHdpZHRoLCBzdWNoIGFzIG1pY3Jvd2F2ZSBvciBEU0wu4oCdDQoNCldoeSBu b3Qgb3RoZXIgbGluayB0eXBlcz8gRG8gb25seSDigJx2YXJpYWJsZSBkaXNjcmV0ZSBiYW5kd2lk dGjigJ0gbGlua3Mgc3VwcG9ydCBhdmFpbGFiaWxpdHk/DQoNCltBbXldIFRvIG91ciBjdXJyZW50 IGtub3dsZWRnZSwgb25seeKAnHZhcmlhYmxlIGRpc2NyZXRlIGJhbmR3aWR0aOKAnSBsaW5rcyBz dXBwb3J0IGF2YWlsYWJpbGl0eS4NCg0KDQoNCmNhbGN1bGF0aW5nIGF2YWlsYWJpbGl0eToNCg0K DQoNCkluIHBhZ2UgOSwgQXBwZW5kaXggQToNCg0KDQoNClBlcmhhcHMgSSBkb27igJl0IHVuZGVy c3RhbmQgaG93IHRoZSBhdmFpbGFiaWxpdHkgbWV0cmljIGlzIHVzZWQuICBJbiB0aGUNCg0KZm9s bG93aW5nOg0KDQoNCg0KICAgT24gYSBzdW5ueSBkYXksIHRoZSBtb2R1bGF0aW9uIGxldmVsIDMg Y2FuIGJlIHVzZWQgdG8gYWNoaWV2ZSA0MDANCg0KICAgTWJwcyBsaW5rIGJhbmR3aWR0aC4NCg0K DQoNCiAgIEEgbGlnaHQgcmFpbiB3aXRoIFggbW0vaCByYXRlIHRyaWdnZXJzIHRoZSBzeXN0ZW0g dG8gY2hhbmdlIHRoZQ0KDQogICBtb2R1bGF0aW9uIGxldmVsIGZyb20gbGV2ZWwgMyB0byBsZXZl bCAyLCB3aXRoIGJhbmR3aWR0aCBjaGFuZ2luZw0KDQogICBmcm9tIDQwMCBNYnBzIHRvIDIwMCBN YnBzLiBUaGUgcHJvYmFiaWxpdHkgb2YgWCBtbS9oIHJhaW4gaW4gdGhlDQoNCiAgIGxvY2FsIGFy ZWEgaXMgNTIgbWludXRlcyBpbiBhIHllYXIuIFRoZW4gdGhlIGRyb3BwZWQgMjAwIE1icHMNCg0K ICAgYmFuZHdpZHRoIGhhcyA5OS45OSUgYXZhaWxhYmlsaXR5Lg0KDQoNCg0KSSB3b3VsZCBzYXkg dGhhdCB0aGUgNDAwTWJwcyBiYW5kd2lkdGggaXMgYXZhaWxhYmxlIHdoZW5ldmVyIGl0IGlzIG5v dCByYWluaW5nLg0KDQpJdCBsaWdodGx5IHJhaW5zIDUyIG1pbiB5ZWFyLCB3aGljaCBtZWFucyBp dCBpcyBub3QgcmFpbmluZyA5OS45OSUgb2YgdGhlIHRpbWUsIHNvIHRoZSA0MDBNYnBzIGF2YWls YWJpbGl0eSBpcyA5OS45OSUuICBUaGUgMjAwTWJwcyBpcyBhdmFpbGFibGUgZHVyaW5nIHRoYXQg NTIgbWluLCBzbyA5OS45OSUgaXMgbm90IHRoZSAyMDBNYnBzIGF2YWlsYWJpbGl0eS4gUmlnaHQ/ DQoNCg0KDQpUaGUgYW5hbG9nb3VzIGNvbW1lbnQgYXBwbGllcyB0byB0aGUgbmV4dCB0d28gcGFy YWdyYXBocy4NCg0KDQoNCkRvZXMgdGhhdCBleHBsYWluIHdoeSB0aGUgdGFibGUgc2hvd3MgdGhl IDEwME1icHMgYmFuZHdpZHRoIGhhdmluZyB0d28gZGlmZmVyZW50IGF2YWlsYWJpbGl0aWVzPw0K DQpbQW15XVlvdXIgdW5kZXJzdGFuZGluZyBpcyBhbHNvIGNvcnJlY3QuIFRoYXQgaXMganVzdCBh IGRpZmZlcmVudCB3YXkgdG8gcHJlc2VudCB0aGUgcmVzdWx0LiBUYWtlIHRoZSB2YWx1ZXMgZnJv bSB0aGUgdGFibGUsIDEwME1icHMgd2l0aCA5OS45OTUlIGFuZCAxMDBNYnBzIHdpdGggOTkuOTk5 JSBjYW4gYmUgYWxzbyBjb25zaWRlcmVkIGFzIGJhbmR3aWR0aCB3aXRoIDk5Ljk5JSBhdmFpbGFi aWxpdHkuDQoNClRodXMgaXQgd2lsbCByZXN1bHQgdGhlIHRvdGFsIGJ3IHdpdGggOTkuOTklIGF2 YWlsYWJpbGl0eSA9IDIwMCsxMDArMTAwPTQwME1icHMNCg0KDQoNCg0KDQpzZWN1cml0eToNCg0K DQoNClRoZSBkcmFmdCAoKikgc2VjdXJpdHkgY29uc2lkZXJhdGlvbiBwb2ludHMgdG8gUlNWUC1U RSwgYnV0IHdpdGhvdXQgYW4gUkZDIHJlZmVyZW5jZSwgYW5kIHRvIFJGQzU5MjAuICBCZWNhdXNl IHRoaXMgaXMgYSBHTVBMUyByZWxhdGVkIGZlYXR1cmUsIGl0IHNob3VsZCByZWZlciB0byB0aGUg R01QTFMgZXh0ZW5zaW9ucyB0byBSU1ZQLVRFIGluIFJGQzM0NzMuICBBcyBhbiBleHRlbnNpb24g dG8gUkZDNjAwMywgaXQgY291bGQgcmVmZXIgdG8gdGhhdCBSRkPigJlzIHNlY3VyaXR5IGNvbnNp ZGVyYXRpb25zIHNlY3Rpb24sIGJ1dCB0aGF0IG9ubHkgZ2V0cyB0aGUgcmVhZGVyIHRvIFJGQzM0 NzMsIFJGQzMyMDksIGFuZCBSRkM1OTIwLg0KDQoNCg0KVGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRp b25zIGZvciBSU1ZQLVRFIGl0c2VsZiAoUkZDMzIwOSkgcG9pbnRzIHRvIFJGQzIyMDUuDQoNClJG QzIyMDUgZGVmaW5lcyBhbiBJbnRlZ3JpdHkgb2JqZWN0IChkZWZpbmVkIGluIFJGQzI3NDcpIHRo YXQgY2FycmllcyBhIGtleWVkIGNyeXB0b2dyYXBoaWMgZGlnZXN0IGJhc2VkIG9uIGEgc2hhcmVk IGtleSwgcHJvdmlkaW5nIGhvcC1ieS1ob3AgcHJvdGVjdGlvbiBiZXR3ZWVuIHR3byBSU1ZQIG5v ZGVzLiAgSG93ZXZlciwgUEFUSCBtZXNzYWdlcyBhcmUgZGlyZWN0ZWQgdG93YXJkIHRoZSB0cmFm ZmljIGRlc3RpbmF0aW9uIGFkZHJlc3MsIG5vdCB0aGUgbmV4dCBSU1ZQIG5vZGUuICBUaGVyZSBj b3VsZCBiZSBjbG91ZHMgb2Ygbm9uLVJTVlAgbm9kZXMgYmV0d2VlbiB0d28gUlNWUCBub2RlcyB0 aGF0IHRoZSBQQVRIIGVuY291bnRlcnMuICBUaGlzIG1ha2VzIGl0IGRpZmZpY3VsdCB0byBzaGFy ZSBhIGtleSBiZXR3ZWVuIGluZGl2aWR1YWwgcGFpcnMgb2YgUlNWUCBub2RlcywgYW5kIGNvdWxk IG1vdGl2YXRlIG9wZXJhdG9ycyB0byBjb25maWd1cmUgdGhlIHNhbWUga2V5IGluIGxhcmdlIG51 bWJlcnMgb2YgUlNWUCBub2Rlcy4NCg0KDQoNClJGQzM0NzMgcG9pbnRzIHRvIFJGQzI3NDfigJlz IHByb3RlY3Rpb24gb2YgUlNWUCBtZXNzYWdlcy4gIEl0IGFsc28gbm90ZXMgdGhhdCBpdCBpbnRy b2R1Y2VzIGEgTm90aWZ5IG1lc3NhZ2UgdGhhdCBpcyBub3Qgc2VudCB0byB0aGUgdHJhZmZpYyBk ZXN0aW5hdGlvbiBhZGRyZXNzIGJ1dCBpbnN0ZWFkIHRvIGEgbm9kZSB0aGF0IHJlcXVlc3RlZCBu b3RpZmljYXRpb24uICBPbmUgdHJhbnNtaXNzaW9uIG9wdGlvbiBpcyB0aGF0IHRoZSBOT1RJRlkg aXMgZW5jYXBzdWxhdGVkIGluIGFuIElQIHBhY2tldCBhbmQgZm9yd2FyZGVkIGRpcmVjdGx5IHRv IHRoZSByZXF1ZXN0aW5nIG5vZGUuICBUaGF0IGNvbXBsaWNhdGVzIHRoZSBJbnRlZ3JpdHkgb2Jq ZWN0IHByb3RlY3Rpb24sIHVubGVzcyB0aGUgc2hhcmVkIGtleSBpcyB3aWRlbHkgc2hhcmVkLg0K DQoNCg0KUkZDMzk0NSBub3RlcyB0aGF0IGF1dGhlbnRpY2F0aW9uIGluIEdNUExTIHN5c3RlbXMg bWF5IHVzZSB0aGUgYXV0aGVudGljYXRpb24gbWVjaGFuaXNtcyBvZiB0aGUgY29tcG9uZW50IHBy b3RvY29scywgcG9pbnRpbmcgdG8gUkZDMjc0NyAoYXMgd2VsbCBhcyBvdGhlcnMgZm9yIExEUCwg TE1QLCBldGMgdGhhdCBkb27igJl0IGFwcGx5IGhlcmUpLg0KDQoNCg0KUkZDNTkyMCBkaXNjdXNz ZXMgdGhyZWF0cywgYXR0YWNrcywgYW5kIHByb3RlY3Rpb25zIGZvciBNUExTL0dNUExTIGRhdGEg YW5kIGNvbnRyb2wgcGxhbmVzLiAgU2VjdGlvbiA3LjEuMiBpbiBwYXJ0aWN1bGFyIHRhbGtzIGFi b3V0IOKAnENvbnRyb2wtUGxhbmUgUHJvdGVjdGlvbiB3aXRoIFJTVlAtVEXigJ0sIGFuZCBjb3Vs ZCBiZSBtZW50aW9uZWQgaGVyZSBleHBsaWNpdGx5LiAgSXQgdGFsa3MgYWJvdXQgbmV0d29yayBi b3JkZXIgY29uZmlndXJhdGlvbiB0byBsaW1pdCBleHRlcm5hbCBhdHRhY2tzLCBhbmQgbWVudGlv bnMNCg0KUkZDMjc0NyBhdXRoZW50aWNhdGlvbiBwcm90ZWN0aW9ucywgbWFraW5nIHNvbWUgb2Yg dGhlIHNhbWUgcG9pbnRzIGFib3V0IG5vbi1SU1ZQIGNsb3VkcyBhbmQgc2hhcmVkIGtleXMgY29u ZmlndXJhdGlvbi4gIEl0IGFsc28gcG9pbnRzIHRvIFJGQzQyMzAsIHdoaWNoIGlzIGEgdmVyeSBk ZXRhaWxlZCBsb29rIGF0IFJTVlAgc2VjdXJpdHksIGFuZCBwcm9iYWJseSBkZXNlcnZlcyB0byBi ZSBtZW50aW9uZWQgaGVyZS4NCg0KDQoNClNvIGFsbCB0b2xkLCBhdCB0aGUgZW5kIG9mIGFsbCB0 aGUgcmVmZXJlbmNlIGNoYWlucywgdGhlIG9ubHkgZGVmaW5lZCBhdXRoZW50aWNhdGlvbiBhbmQg aW50ZWdyaXR5IHByb3RlY3Rpb24gaW4gMjIwNSwgMzIwOSwgYW5kIDM0NzMgaXMgYmFzZWQgb24g c2hhcmVkIGtleXMgdGhhdCBhcmUgdmVyeSBkaWZmaWN1bHQgdG8gY29uZmlndXJlIHdpdGggZmlu ZSBncmFudWxhcml0eS4NCg0KDQoNCkhvd2V2ZXIsIGFzIHdhcyBzYWlkIGluIHJlcGx5IHRvIGEg ZGlmZmVyZW50IE1QTFMgcmVsYXRlZCBkcmFmdCByZXZpZXcNCg0KeWVzdGVyZGF5Og0KDQoNCg0K ICAgIFRoZSBNUExTIG5ldHdvcmsgaXMgb2Z0ZW4gY29uc2lkZXJlZCB0byBiZSBhIGNsb3NlZCBu ZXR3b3JrIHN1Y2ggdGhhdA0KDQogICAgaW5zZXJ0aW9uLCBtb2RpZmljYXRpb24sIG9yIGluc3Bl Y3Rpb24gb2YgcGFja2V0cyBieSBhbiBvdXRzaWRlIHBhcnR5IGlzDQoNCiAgICBub3QgcG9zc2li bGUuDQoNCg0KDQpTbyBtYXliZSB0aGF0IGlzIGFjY2VwdGVkIGFzIHN1ZmZpY2llbnQgaW4gZGVw bG95bWVudC4NCg0KDQoNCk1QTFMgZG9jdW1lbnRzIGFyZSBhbHNvIHR5cGljYWxseSBncmFudGVk IGFuIGV4Y2VwdGlvbiBmcm9tIG1vcmUgcmlnb3JvdXMgc2VjdXJpdHkgcmVxdWlyZW1lbnRzIGJl Y2F1c2UgTVBMUyBpcyB1c2VkIG9ubHkgd2l0aGluIG9uZSByb3V0aW5nIGRvbWFpbiAvIElTUCAv IHByb3ZpZGVyIC8gZXRjLCB1bmRlciBhIHNpbmdsZSBhZG1pbmlzdHJhdGl2ZSBjb250cm9sLCBz byBlcnJvcnMgbWFkZSB3b3VsZCBub3QgYmUgZ2xvYmFsIGluIGltcGFjdC4gIEluIHBhcnRpY3Vs YXIsIGVycm9ycyB0aGF0IG1pZ2h0IHJlc3VsdCBmcm9tIG9uZSBsZWdpdGltYXRlIGJ1dCBmYXVs dHkvbWlzLWNvbmZpZ3VyZWQvc3VidmVydGVkL21hbGljaW91cyBNUExTIG5vZGUgc2hvdWxkIG5v dCBwcm9wYWdhdGUgb3V0IHRvIHRoZSBnZW5lcmFsIEludGVybmV0LiAgKCoqKQ0KDQpbQW15XSBU aGFua3MgZm9yIHRoZSBkZXRhaWwgZXhwbGFuYXRpb24gb24gdGhlIHNlY3VyaXR5IGNvbnNpZGVy YXRpb24sIGl04oCZcyBxdWlldCBlZHVjYXRpb25hbC4gQXMgdGhlIG9wZXJhdGluZyBlbnZpcm9u bWVudCBvZiBHTVBMUyBpcyBzaW1pbGFyIHRvIE1QTFMgbmV0d29yaywgd2Ugd2lsbCBhZG9wdCB0 aGUgc2ltaWxhciB0ZXh0Lg0KDQoNCg0KTml0czoNCg0KDQoNCmZsb2F0aW5nIG51bWJlcnMNCg0K DQoNClBhZ2UgNSwgU2VjdGlvbiAzLjEsIHNheXMg4oCcYSAzMi1iaXQgZmxvYXRpbmcgbnVtYmVy 4oCdLiAgSSBiZWxpZXZlIHlvdSBtZWFuIGEgZmxvYXRpbmctcG9pbnQgbnVtYmVyLiAgSSBjaGVj a2VkIG90aGVyIElFVEYgUkZDcyAoZS5nLiwgUkZDODMzMCksIGFuZCBpdCBpcyBjb21tb24gdG8g bWVudGlvbiB0aGUgSUVFRSA3NTQtMjAwOCBzdGFuZGFyZCB3aGVuIGluY2x1ZGluZyBhIGZsb2F0 aW5nIHBvaW50IHZhbHVlIGluIHRoZSBzcGVjLg0KDQoNCg0KQnV0IGlzIGEgZmxvYXRpbmcgcG9p bnQgdmFsdWUgbmVlZGVkPyAgVGhlIGRyYWZ0IHNheXMgdGhhdCB0aGUgdmFsdWVzIGFyZSB0eXBp Y2FsbHkgaW4gYSBzbWFsbCBzZXQgb2Yga25vd24gdmFsdWVzLiAgVGhlIGludHJvIHNvdW5kcyBs aWtlIGEgc21hbGwgc2V0IG9mIGNsYXNzZXMgYXJlIHVzZWQgZm9yIOKAnGVmZmljaWVudCBwbGFu bmluZ+KAnS4gIEp1c3QgY3VyaW91cy4gIE9UT0gsIFJGQzgzMzAgdXNlcyBmbG9hdGluZyBwb2lu dCwgYW5kIHRoZSBJVFUgZG9jdW1lbnRz4oCZIGNhbGN1bGF0aW9uIG9mIGF2YWlsYWJpbGl0eSBt YWtlIGl0IHNlZW0gbGlrZSBmdWxsIGZsb2F0aW5nIHBvaW50IGlzIG5lZWRlZC4NCg0KW0FteV0g d2lsbCB1cGRhdGUgdG8g4oCcZmxvYXRpbmctcG9pbnQgbnVtYmVy4oCdLg0KDQoNCg0KdGhlIEF2 YWlsYWJpbGl0eSBUTFYgZm9ybWF0Og0KDQoNCg0KcGFnZSA1LCBzZWN0aW9uIDMuMSBzYXlzOg0K DQoNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBUaGUg QXZhaWxhYmlsaXR5IFRMViBoYXMNCg0KICAgdGhlIGZvbGxvd2luZyBmb3JtYXQ6DQoNCg0KDQog ICAgICAgMCAgICAgICAgICAgICAgICAgICAxICAgICAgICAgICAgICAgICAgIDIgICAgICAgICAg ICAgICAgICAgMw0KDQogICAgICAgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcg OCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxDQoNCiAgICAgICstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQoNCiAgICAgIHwg ICAgSW5kZXggICAgICB8ICAgICAgICAgICAgICAgICBSZXNlcnZlZCAgICAgICAgICAgICAgICAg ICAgICB8DQoNCiAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rDQoNCiAgICAgIHwgICAgICAgICAgICAgICAgICAgICAg ICAgIEF2YWlsYWJpbGl0eSAgICAgICAgICAgICAgICAgICAgICAgICB8DQoNCiAgICAgICstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rDQoNCg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgIEZpZ3VyZSAxOiBBdmFpbGFiaWxp dHkgVExWDQoNCg0KDQpJIHByZXN1bWUgdGhhdCB0aGlzIGlzIGp1c3QgdGhlIFZhbHVlIHBvcnRp b24gb2YgdGhlIFRMViBmb3JtYXQgdGhhdCBpcyBkZWZpbmVkIGZvciB0aGUgRXRoZXJuZXQgU0VO REVSX1RTUEVDIE9iamVjdCBpbiBTZWN0aW9uIDQgb2YgUkZDNjAwMy4NCg0KW0FteV0gWWVzLCBp dCBpcy4NCg0KDQoNClBhZ2UgMSwgQWJzdHJhY3Q6DQoNCg0KDQogICB0eXBpY2FsbHkgdXNlZCBm b3IgZGVzY3JpYmluZyB0aGVzZSBsaW5rcyB3aGVuIGR1cmluZyBuZXR3b3JrDQoNCiAgIHBsYW5u aW5nDQoNCg0KDQrigJx3aGVuIGR1cmluZ+KAnSAtIGlzIHRoYXQgZGVsaWJlcmF0ZT8gIEl0IHNv dW5kcyByZWR1bmRhbnQsIG1heWJlIGR1ZSB0byBlZGl0aW5nLg0KDQpPciBtYXliZSBpdCB3YXMg c3VwcG9zZWQgdG8gYmUg4oCcd2hlbiBkb2luZ+KAnT8NCg0KW0FteV0gV2lsbCB1cGRhdGUgdG8g 4oCcd2hlbiBkb2luZ+KAnS4NCg0KDQoNCiAgIHNpZ25hbGluZy4gVGhpcyBleHRlbnNpb24gY2Fu IGJlIHVzZWQgdG8gc2V0IHVwIGEgR2VuZXJhbGl6ZWQgTXVsdGktDQoNCiAgIFByb3RvY29sIExh YmVsIFN3aXRjaGluZyAoR01QTFMpIExhYmVsIFN3aXRjaGVkIFBhdGggKExTUCkgdXNpbmcgdGhl DQoNCiAgIEV0aGVybmV0IFNFTkRFUl9UU1BFQyBvYmplY3QuDQoNCg0KDQpub3Qgc3VyZSAtIHdo YXQgaXMgdXNpbmcgdGhlIFNFTkRFUl9UU1BFQyAtIHRoZSBMU1Agb3IgdGhpcyBleHRlbnNpb24/ DQoNCltBbXldIEhvdyBhYm91dCBjaGFuZ2UgdG8g4oCcaW4gY29uanVuY3Rpb24gd2l0aCBTRU5E RVJfVFNQRUPigJ0uDQoNCg0KDQpQYWdlIDMsIFNlY3Rpb24gMToNCg0KDQoNCiAgIGJhbmR3aWR0 aCBhdmFpbGFiaWxpdHkuIEZvciBleGFtcGxlLCB0aGUgYmFuZHdpZHRoIHdpdGggOTkuOTk5JQ0K DQogICBhdmFpbGFiaWxpdHkgb2YgYSBsaW5rIGlzIDEwMCBNYnBzOyB0aGUgYmFuZHdpZHRoIHdp dGggOTkuOTklDQoNCiAgIGF2YWlsYWJpbGl0eSBpcyAyMDAgTWJwcy4NCg0KDQoNCm1heWJlOg0K DQoNCg0KICAgYmFuZHdpZHRoIGF2YWlsYWJpbGl0eS4gU3VwcG9zZSwgZm9yIGV4YW1wbGUsIHRo ZSBiYW5kd2lkdGggd2l0aCA5OS45OTklDQoNCltBbXldIHdpbGwgdXBkYXRlIHRoZSB0ZXh0Lg0K DQoNCg0KUGFnZSA1LCBzZWN0aW9uIDMuMjoNCg0KDQoNCiAgIFRMVnMgYW5kIG9uZSBvciBtb3Jl IEF2YWlsYWJpbGl0eSBUTFZzLiBFYWNoIEV0aGVybmV0IEJhbmR3aWR0aA0KDQogICBQcm9maWxl IFRMViBjb3JyZXNwb25kcyB0byBhbiBhdmFpbGFiaWxpdHkgcGFyYW1ldGVyIGluIHRoZQ0KDQog ICBBdmFpbGFiaWxpdHkgVExWLg0KDQoNCg0K4oCmIOKAnGluIGFuIEF2YWlsYWJpbGl0eSBUTFbi gJ0/IG9yIOKAnGluIHRoZSBhc3NvY2lhdGVkIEF2YWlsYWJpbGl0eSBUTFbigJ0/IFRoZXJl4oCZ cyBtb3JlIHRoYW4gb25lLg0KDQpbQW15XSB3aWxsIHVwZGF0ZSB0byDigJxpbiB0aGUgYXNzb2Np YXRlZCBBdmFpbGFiaWxpdHkgVExW4oCdLg0KDQoNCg0KUGFnZSA2LCBzZWN0aW9uIDMuMg0KDQoN Cg0KICAgICAgICBsaW5rKSwgaXQgU0hPVUxEIHJlc2VydmUgdGhlIGJhbmR3aWR0aCByZXNvdXJj ZSBmcm9tIGVhY2gNCg0KDQoNCuKAnGl04oCdIC0+IOKAnHRoZSBub2Rl4oCdDQoNCg0KDQogICAg ICAgdGhpcyBMU1AuIE9wdGlvbmFsbHksIHRoZSBoaWdoZXIgYXZhaWxhYmlsaXR5IGJhbmR3aWR0 aCBjYW4gYmUNCg0KDQoNCuKAnHRoZSBoaWdoZXLigJ0gLT4g4oCcYSBoaWdoZXLigJ0gICh0aGVy ZeKAmXMgbW9yZSB0aGFuIG9uZSwgcmlnaHQ/KQ0KDQoNCg0KICAgICAgICByZXF1ZXN0IGNhbm5v dCBiZSBzYXRpc2ZpZWQsIGl0IFNIT1VMRCBnZW5lcmF0ZSBQYXRoRXJyIG1lc3NhZ2UNCg0KDQoN CuKAnGl04oCdIC0+IOKAnHRoZSBub2Rl4oCdDQoNCg0KDQogICBnZW5lcmF0ZSBQYXRoRXJyIG1l c3NhZ2Ugd2l0aCB0aGUgZXJyb3IgY29kZSAiRXh0ZW5kZWQgQ2xhc3MtVHlwZQ0KDQoNCg0K4oCc UGF0aEVycuKAnSAtPiDigJxhIFBhdGhFcnLigJ0gb3Ig4oCcUGF0aEVyciBtZXNzYWdlc+KAnQ0K DQpbQW15XSB3aWxsIHVwZGF0ZSB0aGUgZHJhZnQgYWNjb3JkaW5nbHkuDQoNCnBvc3RzY3JpcHRz Og0KDQoNCg0KKCoqKSBbW1sgSSB3aWxsIG5vdGUgdGhhdCBSRkMzMjA5IGluY2x1ZGVzIGFuIEFT IG51bWJlciBzdWJqZWN0IGFtb25nIHRoZSBzdWJvYmplY3RzIG9mIHRoZSBFWFBMSUNJVF9ST1VU RSBvYmplY3QuICBXaXRoIHRoZSBpZGVhIHRoYXQgeW91IG1pZ2h0IHNldCB1cCBleHBsaWNpdCBy b3V0ZXMgdGhhdCBnbyB0aHJvdWdoIG11bHRpcGxlIEFTTnMuICBPdWNoLiAgSSBrbm93IHRoZXJl IGFyZSBwcm92aWRlcnMgd2hvIGhhdmUgZGlmZmVyZW50IEFTTnMgdW5kZXIgc2luZ2xlIGFkbWlu aXN0cmF0aXZlIGNvbnRyb2wsIGZyb20gYWNxdWlzaXRpb25zIG9yIGJ1c2luZXNzIHVzZSBjYXNl cywgYnV0IHRoaXMganVzdCBtYWtlcyBpdCBwb3NzaWJsZSBmb3IgYW4gZXhwbGljaXQgcm91dGUg Zm9yIGFuIExTUCB0byBiZSBtaXNjb25maWd1cmVkIHRvIGluY2x1ZGUgeW91ciAoZXh0ZXJuYWwp IG5laWdoYm9yIEFTTi4gIEFuZCBSRkM1OTIwIHRhbGtzIGFib3V0IOKAnEFTQlItQVNCUiBjb21t dW5pY2F0aW9uIGZvciBpbnRlci1BUyBMU1Bz4oCdLiAgQmV0dGVyIGhhdmUgZ29vZCBvdXRib3Vu ZCBmaWx0ZXJzIG9uIHlvdXIgYm9yZGVyIHJvdXRlcnMuIF1dXQ0KDQoNCg0KKCopQXMgaXMgdHlw aWNhbCBmb3Igc3BlY2lmaWNhdGlvbnMgdGhhdCBleHRlbmQgb3RoZXIgcHVibGlzaGVkIFJGQ3Ms IHRoaXMgZHJhZnQgc2F5cyBpdCDigJxkb2VzIG5vdCBpbnRyb2R1Y2UgYW55IG5ldyBzZWN1cml0 eSBjb25zaWRlcmF0aW9uc+KAnS4NCg0KDQoNCjxiZWdpbiBzb2FwYm94PiBJbiBnZW5lcmFsLCBJ IGFtIHNrZXB0aWNhbCBvZiBleHRlbnNpb24gZHJhZnRzIHRoYXQgbWFrZSBzdWNoIGNsYWltcy4g IFN1cmVseSB0aGUgZXhpc3Rpbmcgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgc2hvdWxkIGJlIGV4 YW1pbmVkIHRvIHNlZSBob3cgdGhleSBhcHBseSB0byB0aGlzIG5ldyBmZWF0dXJlIG9yIG9iamVj dCBiZWluZyBpbnRyb2R1Y2VkPyAgRG8gY3VycmVudCBwcm90ZWN0aW9ucyBhZGVxdWF0ZWx5IHBy b3RlY3QgdGhlIG5ldyBmZWF0dXJlL29iamVjdD8gIERvZXMgdGhlIG5ldyBmZWF0dXJlL29iamVj dCBjYXJyeSBuZXcgaW5mb3JtYXRpb24sIHByb2R1Y2UgbmV3IGJlaGF2aW9ycz8gIGV0Yy4gQnV0 IHRoaXMgaXMgc28gdmVyeSBjb21tb24gSSBjb3VsZCBoYXJkbHkgcmVxdWVzdCB0aGF0IG1vcmUg YmUgc2FpZCBoZXJlLiBKdXN0IHNheWluZy4gPGVuZA0KDQpzb2FwYm94Pg0KDQpbQW15XSBUaGFu a3MgYWdhaW4gZm9yIHRoZSBkZXRhaWwgcmV2aWV3Lg0KDQoNCg== --_000_9C5FD3EFA72E1740A3D41BADDE0B461FCFB598CDDGGEMM528MBXchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl bnQ9Ik1pY3Jvc29mdCBXb3JkIDE1IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OuWui+S9kzsN CglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9u dC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEDlrovkvZMiOw0KCXBhbm9zZS0x OjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9y bWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7 fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K cC5Nc29QbGFpblRleHQsIGxpLk1zb1BsYWluVGV4dCwgZGl2Lk1zb1BsYWluVGV4dA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6Iue6r+aWh+acrCBDaGFyIjsNCglt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uQ2hhcg0KCXttc28tc3R5 bGUtbmFtZToi57qv5paH5pysIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28t c3R5bGUtbGluazrnuq/mlofmnKw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNv Q2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAu MHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJn aW46NzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtl bmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJl ZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0 PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9IiMw NTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+SGkgU2FuZHJhLDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+TWFueSB0aGFua3MgZm9yIHRoZSBk ZXRhaWwgcmV2aWV3IGNvbW1lbnRzLCBwbGVhc2Ugc2VlIHJlcGx5IGlubGluZSBiZWxvdy48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29s b3I6IzFGNDk3RCI+QW5kIEnigJltIHZlcnkgc29ycnkgZm9yIHRoZSBsYXRlIHJlcGx5Lg0KPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5CUiw8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+QW15 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+LS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS08YnI+DQpGcm9tOiBTYW5kcmEgTXVycGh5IFs8YSBocmVmPSJtYWls dG86c2FuZHlAdGlzbGFicy5jb20iPm1haWx0bzpzYW5keUB0aXNsYWJzLmNvbTwvYT5dDQo8YnI+ DQpTZW50OiBTYXR1cmRheSwgRmVicnVhcnkgMDIsIDIwMTkgMTI6MDIgUE08YnI+DQpUbzogPGEg aHJlZj0ibWFpbHRvOnNlY2RpckBpZXRmLm9yZyI+c2VjZGlyQGlldGYub3JnPC9hPjxicj4NCkNj OiA8YSBocmVmPSJtYWlsdG86Y2NhbXBAaWV0Zi5vcmciPmNjYW1wQGlldGYub3JnPC9hPjsgPGEg aHJlZj0ibWFpbHRvOmlldGZAaWV0Zi5vcmciPg0KaWV0ZkBpZXRmLm9yZzwvYT47IDxhIGhyZWY9 Im1haWx0bzpkcmFmdC1pZXRmLWNjYW1wLXJzdnAtdGUtYmFuZHdpZHRoLWF2YWlsYWJpbGl0eS5h bGxAaWV0Zi5vcmciPg0KZHJhZnQtaWV0Zi1jY2FtcC1yc3ZwLXRlLWJhbmR3aWR0aC1hdmFpbGFi aWxpdHkuYWxsQGlldGYub3JnPC9hPjxicj4NClN1YmplY3Q6IFNlY2RpciBsYXN0IGNhbGwgcmV2 aWV3IG9mIGRyYWZ0LWlldGYtY2NhbXAtcnN2cC10ZS1iYW5kd2lkdGgtYXZhaWxhYmlsaXR5LTEz PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlJldmlld2VyOiBTYW5kcmEgTXVycGh5PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5SZXZpZXcgcmVzdWx0OiBIYXMg SXNzdWVzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkkgaGF2ZSByZXZpZXdlZCB0aGlz IGRvY3VtZW50IGRyYWZ0LWlldGYtY2NhbXAtcnN2cC10ZS1iYW5kd2lkdGgtYXZhaWxhYmlsaXR5 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5hcyBwYXJ0IG9mIHRoZSBz ZWN1cml0eSBkaXJlY3RvcmF0ZeKAmXMgb25nb2luZyBlZmZvcnQgdG8gcmV2aWV3IGFsbCBJRVRG IGRvY3VtZW50cyBiZWluZyBwcm9jZXNzZWQgYnkgdGhlIElFU0cuIFRoZXNlIGNvbW1lbnRzIHdl cmUgd3JpdHRlbiBwcmltYXJpbHkgZm9yIHRoZSBiZW5lZml0IG9mIHRoZSBzZWN1cml0eSBhcmVh IGRpcmVjdG9ycy4mbmJzcDsgRG9jdW1lbnQgZWRpdG9ycyBhbmQgV0cgY2hhaXJzIHNob3VsZA0K IHRyZWF0IHRoZXNlIGNvbW1lbnRzIGp1c3QgbGlrZSBhbnkgb3RoZXIgbGFzdCBjYWxsIGNvbW1l bnRzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5UaGlzIGRyYWZ0IHByb3ZpZGVzIGEg bmV3IFRMViBmb3IgdGhlIEV0aGVybmV0IFNFTkRFUl9UU1BFQyBvYmplY3QgdGhhdCB3aWxsIGNh cnJ5IGF2YWlsYWJpbGl0eSByZXF1aXJlbWVudHMgZm9yIFJTVlAtVEUgc2lnbmFsaW5nIG9mIEdN UExTIExTUHMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlRoZSBkcmFmdCBpcyB0aG9y b3VnaC4mbmJzcDsgSSBkbyBoYXZlIHNvbWUgY29tbWVudHMuJm5ic3A7IEkgcmV2aWV3ZWQgdGhl IG5vcm1hdGl2ZSByZWZlcmVuY2VzIFJGQ3MgMjIwNSwgMzIwOSwgMzQ3MywgNjAwMywgYXMgd2Vs bCBhcyBSRkMzOTQ1IGFuZCBSRkM1OTIwLiZuYnNwOyBJIGNhbuKAmXQgY2xhaW0gdGhhdCBJIHVu ZGVyc3Rvb2QgZXZlcnl0aGluZyBpbiB0aGF0IHN0YWNrLCBzbyB0aGUgZm9sbG93aW5nIGNvdWxk IGVhc2lseQ0KIGJlIHdyb25nLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5Db21wdXRp bmcgdGhlIExTUCBwYXRoOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5QYWdlIDQsIHNl Y3Rpb24gMiBkaXNjdXNzZXMgb2J0YWluaW5nIG5ldHdvcmsgdG9wb2xvZ3ksIGNhbGN1bGF0aW5n IHRoZSBMU1Agcm91dGUsIFJGQzgzMzDigJlzIGV4dGVuc2lvbnMgZm9yIGF2YWlsYWJpbGl0eSBp biBPU1BGIFRFIExTQSBtZXNzYWdlcy4mbmJzcDsgRG9lcyB0aGlzIGRyYWZ0IGFzc3VtZSB0aGF0 IHRoaXMgZXh0ZW5zaW9uIHdpbGwgYWx3YXlzIGJlIHVzZWQgd2l0aCBhbiBFWFBMSUNJVF9ST1VU RQ0KIG9iamVjdD8mbmJzcDsgSXMgdGhpcyBkcmFmdCBub3QgYXBwbGljYWJsZSB3aXRob3V0IHRo YXQgZXhwbGljaXQgTFNQIHJvdXRlIGNhbGN1bGF0aW9uPzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM0NDcyQzQiPltBbXldIE5vLCB0 aGVyZSdzIG5vIGFzc3VtcHRpb24gdGhhdCB0aGUgZXh0ZW5zaW9uIGNhbiBiZSBvbmx5IHVzZWQg d2l0aCBhbiBFWFBMSUNJVF9ST1VURSBvYmplY3QuPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjoj MUY0OTdEIj4gJm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojNDQ3MkM0Ij5UaGUgbm9k ZSB3aG8gb2J0YWlucyBuZXR3b3JrIHRvcG9sb2d5LA0KIGNhbGN1bGF0ZXMgdGhlIExTUCByb3V0 ZSwgY291bGQgYmUgYSBzb3VyY2Ugbm9kZSBhbmQgaW50ZXJtZWRpYXRlIG5vZGVzLiA8L3NwYW4+ DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkF2YWlsYWJpbGl0eSBU TFYgdnMgQ0xBU1NUWVBFIG9iamVjdHM6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlRo ZSBkZWZpbml0aW9uIGluIFJGQzYwMDMgb2YgdGhlIEJhbmR3aWR0aCBQcm9maWxlIFRMViBoYXMg Y2VydGFpbiBjb25zdHJhaW50cyBvbiB0aGUgdmFsdWVzIG9mIHRoZSBJbmRleDo8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBUaGUgSW5kZXggZmllbGQgdmFsdWUgTVVTVCBjb3JyZXNwb25kIHRvIGF0IGxlYXN0IG9u ZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IG9mIHRoZSBDbGFzcy1UeXBlIHZhbHVlcyBpbmNsdWRlZCBlaXRoZXIg aW4gdGhlIENMQVNTVFlQRSBvYmplY3Q8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBbUkZDNDEyNF0gb3IgaW4gdGhl IEVYVEVOREVEX0NMQVNTVFlQRSBvYmplY3QgW01DT1NdLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij5JIGFtIG5vdCBjZXJ0YWluIGlmIHRoaXMgbWVhbnMgdGhhdCB0aGUgcHJlc2VuY2Ug b2YgYW4gRXRoZXJuZXQgU0VOREVSX1RTUEVDIE9iamVjdCB3aXRoIGEgQmFuZHdpZHRoIFByb2Zp bGUgVExWIG1lYW5zIHRoZXJlIG11c3QgYmUgYSBDTEFTU1RZUEUgb2JqZWN0IGluIHRoZSBSU1ZQ LVRFIG1lc3NhZ2UgYXMgd2VsbCwgb3IgdGhhdCB0aGUgSW5kZXggZmllbGQgdmFsdWVzIGFyZSB0 YWtlbiBmcm9tIHRoZQ0KIHNldCBvZiBkZWZpbmVkIENsYXNzLVR5cGUgdmFsdWVzLjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5CdXQgaWYgdGhlIGZpcnN0LCBkb2VzIHRoaXMgaW5kdWNl IHJlcXVpcmVtZW50cyBieSBpbmNsdXNpb24gb2YgdGhlIEF2YWlsYWJpbGl0eSBUTFYgdGhhdCB0 aGVzZSBvdGhlciBDTEFTU1RZUEUgb2JqZWN0cyBtdXN0IGJlIGluY2x1ZGVkIGFzIHdlbGw/DQo8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPk9yIGFyZSB5b3UgaW50ZW5k aW5nIHRvIHVwZGF0ZSBSRkM2MDAzIHRvIGVsaW1pbmF0ZSB0aGF0IGNvbnN0cmFpbnQ/Jm5ic3A7 IElmIHRoZSBzZWNvbmQsIGRvZXMgdGhlIFJGQzYwMDMgY29uc3RyYWludCBhbHNvIGNvbnN0cmFp biB0aGUgaW5kZXggdmFsdWVzIHVzZWQgaW4gdGhlIEF2YWlsYWJpbGl0eSBUTFY/Jm5ic3A7IFNo b3VsZCB0aGF0IGJlIG1lbnRpb25lZD8mbmJzcDsgKE9yIGFtIEkganVzdCBjb25mdXNlZD8pPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6 IzQ0NzJDNCI+W0FteV0gSXTigJlzIHRoZSBzZWNvbmQgY2FzZS4gVGhlIFJGQzYwMDMgY29uc3Ry YWludCBzaG91bGQgYWxzbyBhcHBseSB0byB0aGUgaW5kZXggdmFsdWVzIHVzZWQgaW4gdGhlIEF2 YWlsYWJpbGl0eSBUTFYuIFRoZSBjdXJyZW50IHRleHQgc3RhdGVzIHRoYXQg4oCcaGF2aW5nIHRo ZSBzYW1lIHZhbHVlIG9mIEluZGV4IGZpZWxk4oCdLCB3aGljaCBpbXBsaWVzIHRoZQ0KIHNhbWUg Y29uc3RyYWludC4gPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5CYW5kd2lkdGggVExWIHRvIEF2YWlsYWJpbGl0eSBU TFYgYXNzb2NpYXRpb246PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlBhZ2UgNCwgU2Vj dGlvbiAzLjEgc2F5czxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgV2hlbiB0aGUgQXZhaWxhYmlsaXR5IFRMViBpcyBpbmNsdWRlZCwg aXQgTVVTVCBiZSBwcmVzZW50IGFsb25nPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgd2l0aCB0aGUgRXRoZXJuZXQg QmFuZHdpZHRoIFByb2ZpbGUgVExWLiBJZiB0aGUgYmFuZHdpZHRoPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgcmVx dWlyZW1lbnRzIGluIHRoZSBtdWx0aXBsZSBFdGhlcm5ldCBCYW5kd2lkdGggUHJvZmlsZSBUTFZz IGhhdmU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBkaWZmZXJlbnQgQXZhaWxhYmlsaXR5IHJlcXVpcmVtZW50cywg bXVsdGlwbGUgQXZhaWxhYmlsaXR5IFRMVnM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBTSE9VTEQgYmUgY2Fycmll ZC4gSW4gc3VjaCBhIGNhc2UsIHRoZSBBdmFpbGFiaWxpdHkgVExWIGhhcyBhIG9uZTxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IHRvIG9uZSBjb3JyZXNwb25kZW5jZSB3aXRoIHRoZSBFdGhlcm5ldCBCYW5kd2lkdGgg UHJvZmlsZSBUTFYgYnk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBoYXZpbmcgdGhlIHNhbWUgdmFsdWUgb2YgSW5k ZXggZmllbGQuIElmIGFsbCB0aGUgYmFuZHdpZHRoPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgcmVxdWlyZW1lbnRz IGluIHRoZSBFdGhlcm5ldCBCYW5kd2lkdGggUHJvZmlsZSBoYXZlIHRoZSBzYW1lPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgQXZhaWxhYmlsaXR5IHJlcXVpcmVtZW50LCBvbmUgQXZhaWxhYmlsaXR5IFRMViBTSE9V TEQgYmUgY2FycmllZC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBJbiB0aGlzIGNhc2UsIHRoZSBJbmRleCBmaWVs ZCBpcyBzZXQgdG8gMC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+SSBmaW5kIHRoYXQg dGhlIGRlc2NyaXB0aW9uIGlzIG5vdCBjbGVhciBpbiBhbGwgY2FzZXMuJm5ic3A7IEkgZm91bmQg YSBtZXNzYWdlIGluIHRoZSB3b3JraW5nIGdyb3VwIGRpc2N1c3Npb24gb2YgdGhpcyBhc3NvY2lh dGlvbiB0aGF0IHRoZSBhc3NvY2lhdGlvbiBpcyBlaXRoZXIg4oCcbjpu4oCdIG9yIOKAnG46MeKA nS4mbmJzcDsgSSB0aGluayB0aGlzIGRlc2NyaXB0aW9uIHNvdW5kcyBtb3JlIGxpa2UgbiAxOjEg YXNzb2NpYXRpb25zPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5vciBh Jm5ic3A7IG46MSBhc3NvY2lhdGlvbi4mbmJzcDsmbmJzcDsgSXMgdGhhdCB3aGF0IGlzIGludGVu ZGVkPyZuYnNwOyBDYW4gdGhlIGFzc29jaWF0aW9ucyBiZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+bWl4ZWQgaW4gdGhlIHNhbWUgbWVzc2FnZT8mbmJzcDsgU3VwcG9z ZSB0aGVyZSB3ZXJlIDMgQmFuZHdpZHRoIFRMVnMgdGhhdCBuZWVkZWQgdGhlIHNhbWUgYXZhaWxh YmlsaXR5IGFuZCBvbmUgdGhhdCBoYWQgYSBkaWZmZXJlbnQgYXZhaWxhYmlsaXR5IG5lZWQsIGNv dWxkIHRoZXJlIGJlIDMgQmFuZHdpZHRoIFRMVnMgd2l0aCBpbmRleCAwIGFuZCBvbmUgQXZhaWxh YmlsaXR5LVRMViB3aXRoIGluZGV4IDAgYW5kDQogYWxzbyBhIEJhbmR3aWR0aCBUTFZzIC0gQXZh aWxhYmlsaXR5IFRMViBwYWlyIHdpdGggbWF0Y2hpbmcgaW5kZXggdmFsdWVzPzxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM0NDcyQzQi PltBbXldIFRoYW5rcyBmb3IgbG9va2luZyBpbnRvIHRoZSBwYXN0IGRpc2N1c3Npb24uIFRoZSBp bnRlbnNpb24gd2FzIG4qKDE6MSkgYXNzb2NpYXRpb24gb3IgbjoxIGFzc29jaWF0aW9uLiBJdCB3 YXMgbm90IHNvIGFjY3VyYXRlIGJ5IHVzaW5nIOKAnG46buKAnSBhc3NvY2lhdGlvbiBpbiB0aGUg cGFzdC4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxz cGFuIHN0eWxlPSJjb2xvcjojNDQ3MkM0Ij5SZWdhcmRpbmcgdGhlIGV4YW1wbGUgeW91IGxpc3Qs IGlmIHRoZSBmb3VyIEJhbmR3aWR0aCBUTFZzIGFyZSBzZW50IGluIHRoZSBzYW1lIG1lc3NhZ2Us IGl04oCZcyBiZXR0ZXIgdG8gdXNlIGZvdXIgZGlmZmVyZW50IGluZGV4IHZhbHVlcyBhcyB0aGV5 IGFyZSDigJxtdWx0aXBsZSBFdGhlcm5ldCBCYW5kd2lkdGggUHJvZmlsZSBUTFZzIGhhdmUgZGlm ZmVyZW50DQogQXZhaWxhYmlsaXR5IHJlcXVpcmVtZW50c+KAnS48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzQ0NzJDNCI+ T2YgY291cnNlIHdoYXQgeW91IHByb3Bvc2VkIGNvdWxkIGFsc28gd29yayB0ZWNobmljYWxseS4N CjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+ZXJyb3IgY2hlY2tpbmc6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPk90aGVyIGRvY3VtZW50cyBpbiB0aGUgcmVmZXJlbmNlcyAoUkZDMjIwNSwgMzIwOSwgMzQ3 MywgNjAwMywgZXRjKSBoYXZlIG1hZGUgYSBwb2ludCBvZiBleHBsaWNpdGx5IGRlc2NyaWJpbmcg dGhlIGVycm9yIGhhbmRsaW5nIC0gd2hlbiBQYXRoRXJyIGFuZCBSZXN2RXJyIGFuZCBOb3RpZnkg bWVzc2FnZXMgYXJlIHNlbnQsIHRvIHdob20sIHRoZSBlcnJvciBjb2RlcywgdGhlIGVycm9yIHZh bHVlIHN1Yi1jb2RlcywNCiBldGMuJm5ic3A7IEkgZG9u4oCZdCBzZWUgdGhhdCBoZXJlIGZvciB0 aGUgYmFuZHdpZHRoLXRsdi10by1hdmFpbGFiaWxpdHktdGx2IGFzc29jaWF0aW9ucy48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojNDQ3 MkM0Ij5bQW15XSBUaGFua3MgZm9yIHRoZSBjb21tZW50LCBJIGFncmVlIHRoZSBlcnJvciBwcm9j ZXNzIHNob3VsZCBiZSBjbGVhcmVyLg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+SXMgYSBtaXggb2YgaW5kZXgtemVybyBhbmQgaW5kZXgtbm9uLXplcm8g YmFuZHdpZHRoLXRsdi10by1hdmFpbGFiaWxpdHktdGx2IGFzc29jaWF0aW9ucyAobGlrZSBhYm92 ZSkgYW4gZXJyb3I/IGlzIHRoZSBtZXNzYWdlIGRyb3BwZWQ/Jm5ic3A7IGlzIGFuIGVycm9yIHNl bnQ/DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPmlmIHRoZSBtZXNz YWdlIGlzIG5vdCBkcm9wcGVkLCBhcmUgYW55IG9mIHRoZSBiYW5kd2lkdGgtdGx2LCBhdmFpbGFi aWxpdHktdGx2IGFzc29jaWF0aW9ucyByZXRhaW5lZD88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojNDQ3MkM0Ij5bQW15XSBUaGUgbWVz c2FnZSBNQVkgYmUgaWdub3JlZCBhbmQgU0hPVUxEIE5PVCBiZSBwcm9wYWdhdGVkLjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPklmIHRoZXJlIGFyZSBhdmFp bGFiaWxpdHktdGx2cyB3aXRoIG5vbi16ZXJvIGluZGV4ZXMgd2l0aCBubyBtYXRjaGluZyBpbmRl eCB2YWx1ZSBhbW9uZyB0aGUgYmFuZHdpZHRoLXRsdnMsIHRoYXQgc3VyZWx5IGlzIGFuIGVycm9y PyZuYnNwOyBJcyB0aGUgbWVzc2FnZSBkcm9wcGVkPyZuYnNwOyBPciBpcyB0aGUgYXZhaWxhYmls aXR5IHRsdiBkcm9wcGVkPyZuYnNwOyBJcyBhIFBhdGhFcnIvUmVzdkVyciBtZXNzYWdlIHNlbnQ/ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29s b3I6IzQ0NzJDNCI+W0FteV0geWVzLCB0aGlzIGlzIGFuIGVycm9yLiBJdOKAmXMgcHJlZmVycmVk IHRvIGRyb3AgdGhlPC9zcGFuPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiM0NDcyQzQiPmF2YWlsYWJp bGl0eSB0bHYuICZuYnNwOyZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPlN1cHBvc2UgYWxsIGF2YWlsYWJpbGl0eS10bHZzIGhhdmUgYSBtYXRjaGlu ZyAoemVybyBvciBub24temVybykgaW5kZXggdmFsdWUgYW1vbmcgdGhlIGJhbmR3aWR0aC10bHZz LCBidXQgdGhlcmUgYXJlIGV4dHJhIGJhbmR3aWR0aC10bHZzIChubyBhdmFpbGFiaWxpdHktdGx2 IHdpdGggYSBtYXRjaGluZyBpbmRleCB2YWx1ZSkuJm5ic3A7IElzIHRoYXQgYW4gZXJyb3I/Jm5i c3A7IEFyZSB0aGUgZXh0cmEgYmFuZHdpZHRoLXRsdnMNCiBkcm9wcGVkPyBpZ25vcmVkPyBwcm9w YWdhdGVkPzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5 bGU9ImNvbG9yOiM0NDcyQzQiPltBbXldVGhlIGV4dHJhIGJhbmR3aWR0aC10bHZzIE1BWSBiZSBp Z25vcmVkIGFuZCBTSE9VTEQgTk9UIGJlIHByb3BhZ2F0ZWQuPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+KFJGQzMyMDkgaGFzIHNldmVyYWwgY2FzZXMgd2hl cmUgdGhlcmUgbWlnaHQgYmUgZXh0cmEgb2JqZWN0cyBvciBzdWItb2JqZWN0cyBhbmQgdGhlIGxh bmd1YWdlIGlzIOKAnGNhbiBiZS9NQVkgYmUvU0hPVUxEIGJlL2FyZSBpZ25vcmVkIGFuZCBTSE9V TEQgTk9UIGJlIC9hcmUgbm90L25lZWQgbm90IGJlIHByb3BhZ2F0ZWTigJ0gKTxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM0NDcyQzQi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+bXVsdGlwbGljaXR5OjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij5SRkMzMjA5IHNheXMgaXQgZG9lcyBub3QgYXBwbHkgdG8gbXVsdGljYXN0LCBidXQg aXQgZG9lcyB0YWxrIGFib3V0IG11bHRpcGxlIHBhcmFsbGVsIExTUCB0dW5uZWxzIGJldHdlZW4g dHdvIG5vZGVzLCBhbmQgYWJvdXQgbXVsdGlwb2ludC10by1wb2ludCBMU1BzIGZvciBXRiBhbmQg U0Ugc3R5bGUgcmVzZXJ2YXRpb25zIHdoZW4gdGhlcmUgYXJlIG11bHRpcGxlIHNlbmRlcnMsIGFu ZCBhYm91dCB0aGUgbWVyZ2luZw0KIHJ1bGVzIG9mIFdGIHJlc2VydmF0aW9ucy4mbmJzcDsgRG9l cyBhdmFpbGFiaWxpdHkgd29yayBpbiB0aG9zZSBzdHlsZSByZXNlcnZhdGlvbnM/PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzQ0NzJD NCI+W0FteV0gQ29uc2lkZXJpbmcgdGhhdCB0aGUgdHJhZmZpYyBmcm9tIHNlbmRlcnMgaXMgbW9y ZSBsaWtlbHkgdG8gYmUgY29uY3VycmVudCBhbmQgaW5kZXBlbmRlbnQsIHRoZSBhdmFpbGFiaWxp dHkgVExWIGNhbiBiZSBsaW1pdGVkIHRvIEZpeGVkIEZpbHRlciAoRkYpIFN0eWxlIG9ubHkuDQo8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5hdmFpbGFiaWxp dHkgdnMg4oCcdmFyaWFibGUgZGlzY3JldGUgYmFuZHdpZHRo4oCdOjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij5JIGJlbGlldmUgSSB1bmRlcnN0b29kIHRoZSBkaXNjdXNzaW9uIG9mIHRo ZSBuZWVkIHRvIHNpZ25hbCBhdmFpbGFiaWxpdHkgcmVxdWlyZW1lbnRzIGluIG9yZGVyIGZvciB0 aGUgc3lzdGVtIHRvIGRldGVybWluZSB3aGVuIGFuIExTUCB3YXMgZmVhc2libGUuJm5ic3A7IEkg Y2FuIGRpbWx5IHVuZGVyc3RhbmQgdGhhdCB0aGVyZSBtaWdodCBiZSBsaW5rcyBoYXZlIOKAnHZh cmlhYmxlIGRpc2NyZXRlIGJhbmR3aWR0aOKAnS4mbmJzcDsNCiBTZWN0aW9uIDIgc2F5cyDigJxU aGUgQXZhaWxhYmlsaXR5IFRMViBjYW4gYmUgYXBwbGljYWJsZSB0byBhbnkga2luZCBvZiBwaHlz aWNhbCBsaW5rcyB3aXRoIHZhcmlhYmxlIGRpc2NyZXRlIGJhbmR3aWR0aCwgc3VjaCBhcyBtaWNy b3dhdmUgb3IgRFNMLuKAnTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ V2h5IG5vdCBvdGhlciBsaW5rIHR5cGVzPyBEbyBvbmx5IOKAnHZhcmlhYmxlIGRpc2NyZXRlIGJh bmR3aWR0aOKAnSBsaW5rcyBzdXBwb3J0IGF2YWlsYWJpbGl0eT88bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojNDQ3MkM0Ij5bQW15XSBU byBvdXIgY3VycmVudCBrbm93bGVkZ2UsIG9ubHk8L3NwYW4+PHNwYW4gbGFuZz0iWkgtQ04iIHN0 eWxlPSJmb250LWZhbWlseTrlrovkvZM7Y29sb3I6IzQ0NzJDNCI+4oCcPC9zcGFuPjxzcGFuIHN0 eWxlPSJjb2xvcjojNDQ3MkM0Ij52YXJpYWJsZSBkaXNjcmV0ZSBiYW5kd2lkdGjigJ0gbGlua3Mg c3VwcG9ydCBhdmFpbGFiaWxpdHkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5jYWxjdWxhdGluZyBhdmFpbGFiaWxp dHk6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkluIHBhZ2UgOSwgQXBwZW5kaXggQTo8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+UGVyaGFwcyBJIGRvbuKAmXQgdW5kZXJzdGFu ZCBob3cgdGhlIGF2YWlsYWJpbGl0eSBtZXRyaWMgaXMgdXNlZC4mbmJzcDsgSW4gdGhlPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5mb2xsb3dpbmc6PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyBPbiBhIHN1bm55IGRheSwgdGhlIG1vZHVs YXRpb24gbGV2ZWwgMyBjYW4gYmUgdXNlZCB0byBhY2hpZXZlIDQwMDxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IE1icHMgbGluayBiYW5kd2lkdGgu PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyBBIGxpZ2h0IHJhaW4g d2l0aCBYIG1tL2ggcmF0ZSB0cmlnZ2VycyB0aGUgc3lzdGVtIHRvIGNoYW5nZSB0aGU8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyBtb2R1bGF0aW9u IGxldmVsIGZyb20gbGV2ZWwgMyB0byBsZXZlbCAyLCB3aXRoIGJhbmR3aWR0aCBjaGFuZ2luZzxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IGZyb20g NDAwIE1icHMgdG8gMjAwIE1icHMuIFRoZSBwcm9iYWJpbGl0eSBvZiBYIG1tL2ggcmFpbiBpbiB0 aGU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyBs b2NhbCBhcmVhIGlzIDUyIG1pbnV0ZXMgaW4gYSB5ZWFyLiBUaGVuIHRoZSBkcm9wcGVkIDIwMCBN YnBzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsg YmFuZHdpZHRoIGhhcyA5OS45OSUgYXZhaWxhYmlsaXR5LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij5JIHdvdWxkIHNheSB0aGF0IHRoZSA0MDBNYnBzIGJhbmR3aWR0aCBpcyBhdmFpbGFi bGUgd2hlbmV2ZXIgaXQgaXMgbm90IHJhaW5pbmcuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij5JdCBsaWdodGx5IHJhaW5zIDUyIG1pbiB5ZWFyLCB3aGljaCBtZWFucyBp dCBpcyBub3QgcmFpbmluZyA5OS45OSUgb2YgdGhlIHRpbWUsIHNvIHRoZSA0MDBNYnBzIGF2YWls YWJpbGl0eSBpcyA5OS45OSUuJm5ic3A7IFRoZSAyMDBNYnBzIGlzIGF2YWlsYWJsZSBkdXJpbmcg dGhhdCA1MiBtaW4sIHNvIDk5Ljk5JSBpcyBub3QgdGhlIDIwME1icHMgYXZhaWxhYmlsaXR5LiBS aWdodD88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+VGhlIGFuYWxvZ291cyBjb21tZW50 IGFwcGxpZXMgdG8gdGhlIG5leHQgdHdvIHBhcmFncmFwaHMuPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPkRvZXMgdGhhdCBleHBsYWluIHdoeSB0aGUgdGFibGUgc2hvd3MgdGhlIDEwME1i cHMgYmFuZHdpZHRoIGhhdmluZyB0d28gZGlmZmVyZW50IGF2YWlsYWJpbGl0aWVzPzxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM0NDcy QzQiPltBbXldWW91ciB1bmRlcnN0YW5kaW5nIGlzIGFsc28gY29ycmVjdC4gVGhhdCBpcyBqdXN0 IGEgZGlmZmVyZW50IHdheSB0byBwcmVzZW50IHRoZSByZXN1bHQuIFRha2UgdGhlIHZhbHVlcyBm cm9tIHRoZSB0YWJsZSwgMTAwTWJwcyB3aXRoIDk5Ljk5NSUgYW5kIDEwME1icHMgd2l0aCA5OS45 OTklIGNhbiBiZSBhbHNvIGNvbnNpZGVyZWQgYXMgYmFuZHdpZHRoDQogd2l0aCA5OS45OSUgYXZh aWxhYmlsaXR5LiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48c3BhbiBzdHlsZT0iY29sb3I6IzQ0NzJDNCI+VGh1cyBpdCB3aWxsIHJlc3VsdCB0aGUgdG90 YWwgYncgd2l0aCA5OS45OSUgYXZhaWxhYmlsaXR5ID0gMjAwJiM0MzsxMDAmIzQzOzEwMD00MDBN YnBzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4g c3R5bGU9ImNvbG9yOiM0NDcyQzQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+c2VjdXJpdHk6PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlRoZSBkcmFmdCAoKikgc2VjdXJpdHkgY29uc2lkZXJh dGlvbiBwb2ludHMgdG8gUlNWUC1URSwgYnV0IHdpdGhvdXQgYW4gUkZDIHJlZmVyZW5jZSwgYW5k IHRvIFJGQzU5MjAuJm5ic3A7IEJlY2F1c2UgdGhpcyBpcyBhIEdNUExTIHJlbGF0ZWQgZmVhdHVy ZSwgaXQgc2hvdWxkIHJlZmVyIHRvIHRoZSBHTVBMUyBleHRlbnNpb25zIHRvIFJTVlAtVEUgaW4g UkZDMzQ3My4mbmJzcDsgQXMgYW4gZXh0ZW5zaW9uIHRvIFJGQzYwMDMsDQogaXQgY291bGQgcmVm ZXIgdG8gdGhhdCBSRkPigJlzIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHNlY3Rpb24sIGJ1dCB0 aGF0IG9ubHkgZ2V0cyB0aGUgcmVhZGVyIHRvIFJGQzM0NzMsIFJGQzMyMDksIGFuZCBSRkM1OTIw LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5UaGUgc2VjdXJpdHkgY29uc2lkZXJhdGlv bnMgZm9yIFJTVlAtVEUgaXRzZWxmIChSRkMzMjA5KSBwb2ludHMgdG8gUkZDMjIwNS4NCjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+UkZDMjIwNSBkZWZpbmVzIGFuIElu dGVncml0eSBvYmplY3QgKGRlZmluZWQgaW4gUkZDMjc0NykgdGhhdCBjYXJyaWVzIGEga2V5ZWQg Y3J5cHRvZ3JhcGhpYyBkaWdlc3QgYmFzZWQgb24gYSBzaGFyZWQga2V5LCBwcm92aWRpbmcgaG9w LWJ5LWhvcCBwcm90ZWN0aW9uIGJldHdlZW4gdHdvIFJTVlAgbm9kZXMuJm5ic3A7IEhvd2V2ZXIs IFBBVEggbWVzc2FnZXMgYXJlIGRpcmVjdGVkIHRvd2FyZCB0aGUgdHJhZmZpYw0KIGRlc3RpbmF0 aW9uIGFkZHJlc3MsIG5vdCB0aGUgbmV4dCBSU1ZQIG5vZGUuJm5ic3A7IFRoZXJlIGNvdWxkIGJl IGNsb3VkcyBvZiBub24tUlNWUCBub2RlcyBiZXR3ZWVuIHR3byBSU1ZQIG5vZGVzIHRoYXQgdGhl IFBBVEggZW5jb3VudGVycy4mbmJzcDsgVGhpcyBtYWtlcyBpdCBkaWZmaWN1bHQgdG8gc2hhcmUg YSBrZXkgYmV0d2VlbiBpbmRpdmlkdWFsIHBhaXJzIG9mIFJTVlAgbm9kZXMsIGFuZCBjb3VsZCBt b3RpdmF0ZSBvcGVyYXRvcnMgdG8gY29uZmlndXJlDQogdGhlIHNhbWUga2V5IGluIGxhcmdlIG51 bWJlcnMgb2YgUlNWUCBub2Rlcy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+UkZDMzQ3 MyBwb2ludHMgdG8gUkZDMjc0N+KAmXMgcHJvdGVjdGlvbiBvZiBSU1ZQIG1lc3NhZ2VzLiZuYnNw OyBJdCBhbHNvIG5vdGVzIHRoYXQgaXQgaW50cm9kdWNlcyBhIE5vdGlmeSBtZXNzYWdlIHRoYXQg aXMgbm90IHNlbnQgdG8gdGhlIHRyYWZmaWMgZGVzdGluYXRpb24gYWRkcmVzcyBidXQgaW5zdGVh ZCB0byBhIG5vZGUgdGhhdCByZXF1ZXN0ZWQgbm90aWZpY2F0aW9uLiZuYnNwOyBPbmUgdHJhbnNt aXNzaW9uIG9wdGlvbg0KIGlzIHRoYXQgdGhlIE5PVElGWSBpcyBlbmNhcHN1bGF0ZWQgaW4gYW4g SVAgcGFja2V0IGFuZCBmb3J3YXJkZWQgZGlyZWN0bHkgdG8gdGhlIHJlcXVlc3Rpbmcgbm9kZS4m bmJzcDsgVGhhdCBjb21wbGljYXRlcyB0aGUgSW50ZWdyaXR5IG9iamVjdCBwcm90ZWN0aW9uLCB1 bmxlc3MgdGhlIHNoYXJlZCBrZXkgaXMgd2lkZWx5IHNoYXJlZC48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+UkZDMzk0NSBub3RlcyB0aGF0IGF1dGhlbnRpY2F0aW9uIGluIEdNUExTIHN5 c3RlbXMgbWF5IHVzZSB0aGUgYXV0aGVudGljYXRpb24gbWVjaGFuaXNtcyBvZiB0aGUgY29tcG9u ZW50IHByb3RvY29scywgcG9pbnRpbmcgdG8gUkZDMjc0NyAoYXMgd2VsbCBhcyBvdGhlcnMgZm9y IExEUCwgTE1QLCBldGMgdGhhdCBkb27igJl0IGFwcGx5IGhlcmUpLjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij5SRkM1OTIwIGRpc2N1c3NlcyB0aHJlYXRzLCBhdHRhY2tzLCBhbmQgcHJv dGVjdGlvbnMgZm9yIE1QTFMvR01QTFMgZGF0YSBhbmQgY29udHJvbCBwbGFuZXMuJm5ic3A7IFNl Y3Rpb24gNy4xLjIgaW4gcGFydGljdWxhciB0YWxrcyBhYm91dCDigJxDb250cm9sLVBsYW5lIFBy b3RlY3Rpb24gd2l0aCBSU1ZQLVRF4oCdLCBhbmQgY291bGQgYmUgbWVudGlvbmVkIGhlcmUgZXhw bGljaXRseS4mbmJzcDsgSXQgdGFsa3MgYWJvdXQgbmV0d29yaw0KIGJvcmRlciBjb25maWd1cmF0 aW9uIHRvIGxpbWl0IGV4dGVybmFsIGF0dGFja3MsIGFuZCBtZW50aW9uczxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+UkZDMjc0NyBhdXRoZW50aWNhdGlvbiBwcm90ZWN0 aW9ucywgbWFraW5nIHNvbWUgb2YgdGhlIHNhbWUgcG9pbnRzIGFib3V0IG5vbi1SU1ZQIGNsb3Vk cyBhbmQgc2hhcmVkIGtleXMgY29uZmlndXJhdGlvbi4mbmJzcDsgSXQgYWxzbyBwb2ludHMgdG8g UkZDNDIzMCwgd2hpY2ggaXMgYSB2ZXJ5IGRldGFpbGVkIGxvb2sgYXQgUlNWUCBzZWN1cml0eSwg YW5kIHByb2JhYmx5IGRlc2VydmVzIHRvIGJlIG1lbnRpb25lZA0KIGhlcmUuPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPlNvIGFsbCB0b2xkLCBhdCB0aGUgZW5kIG9mIGFsbCB0aGUgcmVm ZXJlbmNlIGNoYWlucywgdGhlIG9ubHkgZGVmaW5lZCBhdXRoZW50aWNhdGlvbiBhbmQgaW50ZWdy aXR5IHByb3RlY3Rpb24gaW4gMjIwNSwgMzIwOSwgYW5kIDM0NzMgaXMgYmFzZWQgb24gc2hhcmVk IGtleXMgdGhhdCBhcmUgdmVyeSBkaWZmaWN1bHQgdG8gY29uZmlndXJlIHdpdGggZmluZSBncmFu dWxhcml0eS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+SG93ZXZlciwgYXMgd2FzIHNh aWQgaW4gcmVwbHkgdG8gYSBkaWZmZXJlbnQgTVBMUyByZWxhdGVkIGRyYWZ0IHJldmlldzxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+eWVzdGVyZGF5OjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgVGhlIE1QTFMgbmV0d29yayBp cyBvZnRlbiBjb25zaWRlcmVkIHRvIGJlIGEgY2xvc2VkIG5ldHdvcmsgc3VjaCB0aGF0PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgaW5z ZXJ0aW9uLCBtb2RpZmljYXRpb24sIG9yIGluc3BlY3Rpb24gb2YgcGFja2V0cyBieSBhbiBvdXRz aWRlIHBhcnR5IGlzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJz cDsmbmJzcDsmbmJzcDsgbm90IHBvc3NpYmxlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij5TbyBtYXliZSB0aGF0IGlzIGFjY2VwdGVkIGFzIHN1ZmZpY2llbnQgaW4gZGVwbG95bWVudC48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+TVBMUyBkb2N1bWVudHMgYXJlIGFsc28gdHlw aWNhbGx5IGdyYW50ZWQgYW4gZXhjZXB0aW9uIGZyb20gbW9yZSByaWdvcm91cyBzZWN1cml0eSBy ZXF1aXJlbWVudHMgYmVjYXVzZSBNUExTIGlzIHVzZWQgb25seSB3aXRoaW4gb25lIHJvdXRpbmcg ZG9tYWluIC8gSVNQIC8gcHJvdmlkZXIgLyBldGMsIHVuZGVyIGEgc2luZ2xlIGFkbWluaXN0cmF0 aXZlIGNvbnRyb2wsIHNvIGVycm9ycyBtYWRlIHdvdWxkIG5vdA0KIGJlIGdsb2JhbCBpbiBpbXBh Y3QuJm5ic3A7IEluIHBhcnRpY3VsYXIsIGVycm9ycyB0aGF0IG1pZ2h0IHJlc3VsdCBmcm9tIG9u ZSBsZWdpdGltYXRlIGJ1dCBmYXVsdHkvbWlzLWNvbmZpZ3VyZWQvc3VidmVydGVkL21hbGljaW91 cyBNUExTIG5vZGUgc2hvdWxkIG5vdCBwcm9wYWdhdGUgb3V0IHRvIHRoZSBnZW5lcmFsIEludGVy bmV0LiZuYnNwOyAoKiopPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 c3BhbiBzdHlsZT0iY29sb3I6IzQ0NzJDNCI+W0FteV0gVGhhbmtzIGZvciB0aGUgZGV0YWlsIGV4 cGxhbmF0aW9uIG9uIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9uLCBpdOKAmXMgcXVpZXQgZWR1 Y2F0aW9uYWwuIEFzIHRoZSBvcGVyYXRpbmcgZW52aXJvbm1lbnQgb2YgR01QTFMgaXMgc2ltaWxh ciB0byBNUExTIG5ldHdvcmssIHdlIHdpbGwgYWRvcHQgdGhlIHNpbWlsYXIgdGV4dC48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPk5pdHM6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPmZsb2F0aW5nIG51bWJl cnM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+UGFnZSA1LCBTZWN0aW9uIDMuMSwgc2F5 cyDigJxhIDMyLWJpdCBmbG9hdGluZyBudW1iZXLigJ0uJm5ic3A7IEkgYmVsaWV2ZSB5b3UgbWVh biBhIGZsb2F0aW5nLXBvaW50IG51bWJlci4mbmJzcDsgSSBjaGVja2VkIG90aGVyIElFVEYgUkZD cyAoZS5nLiwgUkZDODMzMCksIGFuZCBpdCBpcyBjb21tb24gdG8gbWVudGlvbiB0aGUgSUVFRSA3 NTQtMjAwOCBzdGFuZGFyZCB3aGVuIGluY2x1ZGluZyBhIGZsb2F0aW5nIHBvaW50IHZhbHVlDQog aW4gdGhlIHNwZWMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkJ1dCBpcyBhIGZsb2F0 aW5nIHBvaW50IHZhbHVlIG5lZWRlZD8mbmJzcDsgVGhlIGRyYWZ0IHNheXMgdGhhdCB0aGUgdmFs dWVzIGFyZSB0eXBpY2FsbHkgaW4gYSBzbWFsbCBzZXQgb2Yga25vd24gdmFsdWVzLiZuYnNwOyBU aGUgaW50cm8gc291bmRzIGxpa2UgYSBzbWFsbCBzZXQgb2YgY2xhc3NlcyBhcmUgdXNlZCBmb3Ig 4oCcZWZmaWNpZW50IHBsYW5uaW5n4oCdLiZuYnNwOyBKdXN0IGN1cmlvdXMuJm5ic3A7IE9UT0gs IFJGQzgzMzAgdXNlcyBmbG9hdGluZw0KIHBvaW50LCBhbmQgdGhlIElUVSBkb2N1bWVudHPigJkg Y2FsY3VsYXRpb24gb2YgYXZhaWxhYmlsaXR5IG1ha2UgaXQgc2VlbSBsaWtlIGZ1bGwgZmxvYXRp bmcgcG9pbnQgaXMgbmVlZGVkLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM0NDcyQzQiPltBbXldIHdpbGwgdXBkYXRlIHRvIOKAnGZs b2F0aW5nLXBvaW50IG51bWJlcuKAnS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPnRoZSBBdmFpbGFiaWxpdHkgVExW IGZvcm1hdDo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+cGFnZSA1LCBzZWN0aW9uIDMu MSBzYXlzOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVGhlIEF2YWlsYWJpbGl0eSBUTFYgaGFzPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgdGhlIGZv bGxvd2luZyBmb3JtYXQ6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAwJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDEmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgMiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMCAxIDIgMyA0IDUgNiA3IDggOSAw IDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzst JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5i c3A7IEluZGV4Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgUmVzZXJ2ZWQmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7ICYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBBdmFpbGFiaWxpdHkmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7fDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBGaWd1cmUgMTogQXZhaWxhYmlsaXR5IFRMVjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij5JIHByZXN1bWUgdGhhdCB0aGlzIGlzIGp1c3QgdGhlIFZhbHVlIHBvcnRpb24gb2Yg dGhlIFRMViBmb3JtYXQgdGhhdCBpcyBkZWZpbmVkIGZvciB0aGUgRXRoZXJuZXQgU0VOREVSX1RT UEVDIE9iamVjdCBpbiBTZWN0aW9uIDQgb2YgUkZDNjAwMy48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojNDQ3MkM0Ij5bQW15XSBZZXMs IGl0IGlzLiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPlBhZ2UgMSwgQWJzdHJhY3Q6PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyB0eXBpY2FsbHkgdXNlZCBmb3IgZGVzY3JpYmluZyB0 aGVzZSBsaW5rcyB3aGVuIGR1cmluZyBuZXR3b3JrPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgcGxhbm5pbmc8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PHNwYW4gbGFuZz0iWkgtQ04iIHN0eWxlPSJmb250LWZhbWlseTrlrovkvZMiPuKA nDwvc3Bhbj53aGVuIGR1cmluZ+KAnSAtIGlzIHRoYXQgZGVsaWJlcmF0ZT8mbmJzcDsgSXQgc291 bmRzIHJlZHVuZGFudCwgbWF5YmUgZHVlIHRvIGVkaXRpbmcuPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij5PciBtYXliZSBpdCB3YXMgc3VwcG9zZWQgdG8gYmUg4oCcd2hl biBkb2luZ+KAnT88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFu IHN0eWxlPSJjb2xvcjojNDQ3MkM0Ij5bQW15XSBXaWxsIHVwZGF0ZSB0byA8L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OuWui+S9kztjb2xvcjojMUY0OTdEIj7igJw8L3NwYW4+PHNwYW4g c3R5bGU9ImNvbG9yOiM0NDcyQzQiPndoZW4gZG9pbmfigJ0uPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgc2lnbmFsaW5nLiBUaGlzIGV4dGVuc2lvbiBj YW4gYmUgdXNlZCB0byBzZXQgdXAgYSBHZW5lcmFsaXplZCBNdWx0aS08bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyBQcm90b2NvbCBMYWJlbCBTd2l0 Y2hpbmcgKEdNUExTKSBMYWJlbCBTd2l0Y2hlZCBQYXRoIChMU1ApIHVzaW5nIHRoZTxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IEV0aGVybmV0IFNF TkRFUl9UU1BFQyBvYmplY3QuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPm5vdCBzdXJl IC0gd2hhdCBpcyB1c2luZyB0aGUgU0VOREVSX1RTUEVDIC0gdGhlIExTUCBvciB0aGlzIGV4dGVu c2lvbj88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxl PSJjb2xvcjojNDQ3MkM0Ij5bQW15XSBIb3cgYWJvdXQgY2hhbmdlIHRvPC9zcGFuPjxzcGFuIHN0 eWxlPSJjb2xvcjojMUY0OTdEIj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6IzQ0NzJDNCI+ 4oCcaW4gY29uanVuY3Rpb24gd2l0aCBTRU5ERVJfVFNQRUPigJ0uPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5QYWdl IDMsIFNlY3Rpb24gMTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7 IGJhbmR3aWR0aCBhdmFpbGFiaWxpdHkuIEZvciBleGFtcGxlLCB0aGUgYmFuZHdpZHRoIHdpdGgg OTkuOTk5JTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5i c3A7IGF2YWlsYWJpbGl0eSBvZiBhIGxpbmsgaXMgMTAwIE1icHM7IHRoZSBiYW5kd2lkdGggd2l0 aCA5OS45OSU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZu YnNwOyBhdmFpbGFiaWxpdHkgaXMgMjAwIE1icHMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPm1heWJlOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgYmFu ZHdpZHRoIGF2YWlsYWJpbGl0eS4gU3VwcG9zZSwgZm9yIGV4YW1wbGUsIHRoZSBiYW5kd2lkdGgg d2l0aCA5OS45OTklPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3Bh biBzdHlsZT0iY29sb3I6IzQ0NzJDNCI+W0FteV0gd2lsbCB1cGRhdGUgdGhlIHRleHQuIDxvOnA+ DQo8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9 ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij5QYWdlIDUsIHNlY3Rpb24gMy4yOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4mbmJzcDsmbmJzcDsgVExWcyBhbmQgb25lIG9yIG1vcmUgQXZhaWxhYmlsaXR5IFRMVnMu IEVhY2ggRXRoZXJuZXQgQmFuZHdpZHRoPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mbmJzcDsmbmJzcDsgUHJvZmlsZSBUTFYgY29ycmVzcG9uZHMgdG8gYW4gYXZhaWxh YmlsaXR5IHBhcmFtZXRlciBpbiB0aGU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZuYnNwOyZuYnNwOyBBdmFpbGFiaWxpdHkgVExWLjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJaSC1DTiIgc3R5bGU9ImZvbnQtZmFtaWx5OuWui+S9kyI+ 4oCmPC9zcGFuPiDigJxpbiBhbiBBdmFpbGFiaWxpdHkgVExW4oCdPyBvciDigJxpbiB0aGUgYXNz b2NpYXRlZCBBdmFpbGFiaWxpdHkgVExW4oCdPyBUaGVyZeKAmXMgbW9yZSB0aGFuIG9uZS48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjoj NDQ3MkM0Ij5bQW15XSB3aWxsIHVwZGF0ZSB0byA8L3NwYW4+PHNwYW4gbGFuZz0iWkgtQ04iIHN0 eWxlPSJmb250LWZhbWlseTrlrovkvZM7Y29sb3I6IzQ0NzJDNCI+4oCcPC9zcGFuPjxzcGFuIHN0 eWxlPSJjb2xvcjojNDQ3MkM0Ij5pbiB0aGUgYXNzb2NpYXRlZCBBdmFpbGFiaWxpdHkgVExW4oCd LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+UGFnZSA2LCBzZWN0aW9uIDMuMjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgbGluayks IGl0IFNIT1VMRCByZXNlcnZlIHRoZSBiYW5kd2lkdGggcmVzb3VyY2UgZnJvbSBlYWNoPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IlpILUNOIiBzdHlsZT0iZm9udC1m YW1pbHk65a6L5L2TIj7igJw8L3NwYW4+aXTigJ0gLSZndDsg4oCcdGhlIG5vZGXigJ08bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IHRoaXMgTFNQLiBPcHRpb25hbGx5LCB0aGUgaGlnaGVyIGF2YWlsYWJpbGl0eSBiYW5kd2lk dGggY2FuIGJlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IlpILUNO IiBzdHlsZT0iZm9udC1mYW1pbHk65a6L5L2TIj7igJw8L3NwYW4+dGhlIGhpZ2hlcuKAnSAtJmd0 OyDigJxhIGhpZ2hlcuKAnSZuYnNwOyAodGhlcmXigJlzIG1vcmUgdGhhbiBvbmUsIHJpZ2h0Pyk8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IHJlcXVlc3QgY2Fubm90IGJlIHNhdGlzZmllZCwgaXQgU0hPVUxEIGdl bmVyYXRlIFBhdGhFcnIgbWVzc2FnZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3Bh biBsYW5nPSJaSC1DTiIgc3R5bGU9ImZvbnQtZmFtaWx5OuWui+S9kyI+4oCcPC9zcGFuPml04oCd IC0mZ3Q7IOKAnHRoZSBub2Rl4oCdPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNw OyZuYnNwOyBnZW5lcmF0ZSBQYXRoRXJyIG1lc3NhZ2Ugd2l0aCB0aGUgZXJyb3IgY29kZSAmcXVv dDtFeHRlbmRlZCBDbGFzcy1UeXBlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFu IGxhbmc9IlpILUNOIiBzdHlsZT0iZm9udC1mYW1pbHk65a6L5L2TIj7igJw8L3NwYW4+UGF0aEVy cuKAnSAtJmd0OyDigJxhIFBhdGhFcnLigJ0gb3Ig4oCcUGF0aEVyciBtZXNzYWdlc+KAnTxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM0 NDcyQzQiPltBbXldIHdpbGwgdXBkYXRlIHRoZSBkcmFmdCBhY2NvcmRpbmdseS4NCjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPnBvc3RzY3JpcHRzOjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4oKiopIFtbWyBJIHdpbGwgbm90ZSB0aGF0IFJGQzMy MDkgaW5jbHVkZXMgYW4gQVMgbnVtYmVyIHN1YmplY3QgYW1vbmcgdGhlIHN1Ym9iamVjdHMgb2Yg dGhlIEVYUExJQ0lUX1JPVVRFIG9iamVjdC4mbmJzcDsgV2l0aCB0aGUgaWRlYSB0aGF0IHlvdSBt aWdodCBzZXQgdXAgZXhwbGljaXQgcm91dGVzIHRoYXQgZ28gdGhyb3VnaCBtdWx0aXBsZSBBU05z LiZuYnNwOyBPdWNoLiZuYnNwOyBJIGtub3cgdGhlcmUgYXJlIHByb3ZpZGVycw0KIHdobyBoYXZl IGRpZmZlcmVudCBBU05zIHVuZGVyIHNpbmdsZSBhZG1pbmlzdHJhdGl2ZSBjb250cm9sLCBmcm9t IGFjcXVpc2l0aW9ucyBvciBidXNpbmVzcyB1c2UgY2FzZXMsIGJ1dCB0aGlzIGp1c3QgbWFrZXMg aXQgcG9zc2libGUgZm9yIGFuIGV4cGxpY2l0IHJvdXRlIGZvciBhbiBMU1AgdG8gYmUgbWlzY29u ZmlndXJlZCB0byBpbmNsdWRlIHlvdXIgKGV4dGVybmFsKSBuZWlnaGJvciBBU04uJm5ic3A7IEFu ZCBSRkM1OTIwIHRhbGtzIGFib3V0IOKAnEFTQlItQVNCUg0KIGNvbW11bmljYXRpb24gZm9yIGlu dGVyLUFTIExTUHPigJ0uJm5ic3A7IEJldHRlciBoYXZlIGdvb2Qgb3V0Ym91bmQgZmlsdGVycyBv biB5b3VyIGJvcmRlciByb3V0ZXJzLiBdXV08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ KCopQXMgaXMgdHlwaWNhbCBmb3Igc3BlY2lmaWNhdGlvbnMgdGhhdCBleHRlbmQgb3RoZXIgcHVi bGlzaGVkIFJGQ3MsIHRoaXMgZHJhZnQgc2F5cyBpdCDigJxkb2VzIG5vdCBpbnRyb2R1Y2UgYW55 IG5ldyBzZWN1cml0eSBjb25zaWRlcmF0aW9uc+KAnS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jmx0O2JlZ2luIHNvYXBib3gmZ3Q7IEluIGdlbmVyYWwsIEkgYW0gc2tlcHRpY2FsIG9m IGV4dGVuc2lvbiBkcmFmdHMgdGhhdCBtYWtlIHN1Y2ggY2xhaW1zLiZuYnNwOyBTdXJlbHkgdGhl IGV4aXN0aW5nIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHNob3VsZCBiZSBleGFtaW5lZCB0byBz ZWUgaG93IHRoZXkgYXBwbHkgdG8gdGhpcyBuZXcgZmVhdHVyZSBvciBvYmplY3QgYmVpbmcgaW50 cm9kdWNlZD8mbmJzcDsgRG8gY3VycmVudCBwcm90ZWN0aW9ucw0KIGFkZXF1YXRlbHkgcHJvdGVj dCB0aGUgbmV3IGZlYXR1cmUvb2JqZWN0PyZuYnNwOyBEb2VzIHRoZSBuZXcgZmVhdHVyZS9vYmpl Y3QgY2FycnkgbmV3IGluZm9ybWF0aW9uLCBwcm9kdWNlIG5ldyBiZWhhdmlvcnM/Jm5ic3A7IGV0 Yy4gQnV0IHRoaXMgaXMgc28gdmVyeSBjb21tb24gSSBjb3VsZCBoYXJkbHkgcmVxdWVzdCB0aGF0 IG1vcmUgYmUgc2FpZCBoZXJlLiBKdXN0IHNheWluZy4gJmx0O2VuZDxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+c29hcGJveCZndDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojNDQ3MkM0Ij5bQW15XSBUaGFu a3MgYWdhaW4gZm9yIHRoZSBkZXRhaWwgcmV2aWV3Lg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwv Ym9keT4NCjwvaHRtbD4NCg== --_000_9C5FD3EFA72E1740A3D41BADDE0B461FCFB598CDDGGEMM528MBXchi_-- From nobody Fri Feb 22 10:43:55 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E9DA11279E6; Fri, 22 Feb 2019 10:43:34 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Yaron Sheffer To: Cc: uta@ietf.org, ietf@ietf.org, draft-ietf-uta-smtp-require-tls.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.91.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155086101448.5343.14630075460582755101@ietfa.amsl.com> Date: Fri, 22 Feb 2019 10:43:34 -0800 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-uta-smtp-require-tls-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2019 18:43:37 -0000 Reviewer: Yaron Sheffer Review result: Has Nits [Apologies for the late review.] * Intro: To avoid confusion, please mention the header parameter "No" to clarify why the header is named RequireTLS when its semantics is the exact opposite, "prioritize delivery over ability to negotiate TLS"? The same confusion already arises in the abstract. * Sec. 2: it seems to be implied that when REQUIRETLS is used, STARTTLS MUST also be sent. Is this the case? If so, please mention it (it's obvious to you but not to a first time reader). * I would have expected a parameter to be associated with REQUIRETLS to indicate whether DANE is required throughout the forwarding path, or MTA-STS, or either one will do. Although RFC 8461 takes care to not use the "opportunistic" word, it is in fact opportunistic to some degree (because an attacker can block the initial policy lookup with DNS) and so has different security properties than DANE. I am sure you've already beaten this horse to death, but if you have not, I think this is a real issue. The thing is, if ever we have widespread deployment of DANE (which I do NOT expect), this mechanism will not be as secure as it could have been. * Sec. 2 security requirements: the session must employ TLS: does this include pre-negotiation of TLS before starting SMTP, or only session upgrade with STARTTLS? This is common in Submission, I'm not sure about MTA-to-MTA use. * RequireTLS header field: I believe that the REQUIRETLS parameter MUST NOT be used when the header field is there, why not mention it? * If we define a case where MTA-STS policy is to be ignored (when using RequireTLS: No), shouldn't this document be marked as Updates RFC 8461? * The word "no" appears twice in Sec. 3, capitalized as "NO" or "No". Are parameters case insensitive? * The case of REQUIRETLS+RequireTLS on receipt is interesting, and the MAY requirement (Sec. 4.1) makes it non-deterministic. Why don't we simply disallow it and reject the message? * The textual name is mentioned twice, once with and once without a space. * 8.2 (active attacks): this solution is still vulnerable to the DNS blocking attack associated with MTA-STS (RFC 8461, Sec. 10.2), and this should be mentioned here. From nobody Fri Feb 22 14:32:06 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7442E130E85; Fri, 22 Feb 2019 14:32:04 -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 autolearn_force=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 e5ECjGxREnjr; Fri, 22 Feb 2019 14:32:02 -0800 (PST) Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3540C130E83; Fri, 22 Feb 2019 14:31:59 -0800 (PST) Received: by straasha.imrryr.org (Postfix, from userid 1001) id 0A2D32BA447; Fri, 22 Feb 2019 17:31:58 -0500 (EST) Date: Fri, 22 Feb 2019 17:31:57 -0500 From: Viktor Dukhovni To: secdir@ietf.org Cc: uta@ietf.org, ietf@ietf.org, draft-ietf-uta-smtp-require-tls.all@ietf.org Message-ID: <20190222223157.GB916@straasha.imrryr.org> Reply-To: uta@ietf.org References: <155086101448.5343.14630075460582755101@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <155086101448.5343.14630075460582755101@ietfa.amsl.com> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [secdir] [Uta] Secdir last call review of draft-ietf-uta-smtp-require-tls-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2019 22:32:05 -0000 On Fri, Feb 22, 2019 at 10:43:34AM -0800, Yaron Sheffer wrote: > I would have expected a parameter to be associated with REQUIRETLS to indicate > whether DANE is required throughout the forwarding path, or MTA-STS, or either > one will do. Leaving the security mechanism unspecified was a deliberate choice discussed in the WG. The "REQUIRETLS = yes" case is fragile enough as is, without the user imposing fine-grained constraints on the security mechanisms available on all the MTAs along the delivery path. > Although RFC 8461 takes care to not use the "opportunistic" word, > it is in fact opportunistic to some degree (because an attacker can block the > initial policy lookup with DNS) and so has different security properties than > DANE. Yes, and by theh way "opportunistic security" (RFC7435) does not mean "weak" or "unauthenticated", it just means not required a-priori at the origin, and so applied on a case by case basis based on discovered peer capabilities. In the case of DANE the policy discovery mechanism is resistant to downgrades at first contact, and in the case of MTA-STS it is not. And yet, despite my obvious enthusiasm for DANE, I don't think it is (at least in the near-term) realistic for users to require DANE along the entire path beyond what might happen naturally because some of the receiving systems publish TLSA records and the sending system supports DANE. > I am sure you've already beaten this horse to death, but if you have not, > I think this is a real issue. Yes, this was discussed. > The thing is, if ever we have widespread deployment of DANE (which I do NOT expect), It is not about to happen for HTTPS any time soon, but much progress has happened in that direction on the SMTP front. Out of over 9.3 million DNSSEC domains surveyed (out of an estimated ~10 million world-wide total), there are 1.07 million DANE-enabled domains. Momentum is building in Northern Europe, but the U.S. has the second highest number of DANE MX hosts by GeoIP after Germany. Also mx[1-4].smtp.goog are DNSSEC signed, and could easily have TLSA records which makes DANE possible for over 500k DNSSEC-signed domains MX-hosted by Google, if they update their MX RRset to point to these hostnames (signed aliases for the usual Google MX hosts). I would not surprised to see Google actually publish the TLSA records some time in the next 12 months. > this mechanism will not be as secure as it could have been. It won't be secure at all, if it never gets used, and making it overly specific reduces the already marginal usability. * Sec. 2 security requirements: the session must > employ TLS: does this include pre-negotiation of TLS before starting SMTP, or > only session upgrade with STARTTLS? This is common in Submission, I'm not sure > about MTA-to-MTA use. (MTA-to-MTA) SMTP *only* uses STARTTLS. "Implicit TLS" is only for SUBMIT and IMAP. > * RequireTLS header field: I believe that the REQUIRETLS > parameter MUST NOT be used when the header field is there, why not mention it? This is certainly a reasonably observation. > * If we define a case where MTA-STS policy is to be ignored (when using > RequireTLS: No), shouldn't this document be marked as Updates RFC 8461? IMHO that's just local policy. -- Viktor. From nobody Fri Feb 22 16:22:02 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98FCA130DE4; Fri, 22 Feb 2019 16:21:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 PWkZpsAa4j_3; Fri, 22 Feb 2019 16:21:52 -0800 (PST) Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86320126C7E; Fri, 22 Feb 2019 16:21:51 -0800 (PST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga006.jf.intel.com ([10.7.209.51]) by orsmga106.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Feb 2019 16:21:50 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.58,401,1544515200"; d="scan'208,217";a="118411657" Received: from orsmsx106.amr.corp.intel.com ([10.22.225.133]) by orsmga006.jf.intel.com with ESMTP; 22 Feb 2019 16:21:50 -0800 Received: from orsmsx116.amr.corp.intel.com ([169.254.7.135]) by ORSMSX106.amr.corp.intel.com ([169.254.1.35]) with mapi id 14.03.0415.000; Fri, 22 Feb 2019 16:21:50 -0800 From: "Ganga, Ilango S" To: =?utf-8?B?TWFnbnVzIE55c3Ryw7Zt?= , "secdir@ietf.org" CC: "draft-ietf-nvo3-geneve@ietf.org" , "nvo3-chairs@ietf.org" , "nvo3@ietf.org" Thread-Topic: Secdir review (early review) of draft-ietf-nvo3-geneve Thread-Index: AQHUa05O1lkJPkWghUmTeaMFlyPdI6U4khKAgAGdQICACXZEUIAA3nKAgABDMiCAqHvjsA== Date: Sat, 23 Feb 2019 00:21:49 +0000 Message-ID: References: <5bd9f599.1c69fb81.4fed7.d7cd@mx.google.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMGMyNDEyMzctOThjZC00NjQ5LTk4MTUtM2VmZDI2YjQ5Y2FhIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiXC81cDkzVDRYVVR5Ullrejc2QkkwVjJ3WXI1azhIZ1dFYVV3MkU1eXpnSVwvTGFqSVdqbHFvUDBZb0t2UzJmd2o5In0= x-ctpclassification: CTP_NT x-originating-ip: [10.22.254.138] Content-Type: multipart/alternative; boundary="_000_C5A274B25007804B800CB5B289727E3583D6B5E7ORSMSX116amrcor_" MIME-Version: 1.0 Archived-At: Subject: Re: [secdir] Secdir review (early review) of draft-ietf-nvo3-geneve X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Feb 2019 00:21:56 -0000 --_000_C5A274B25007804B800CB5B289727E3583D6B5E7ORSMSX116amrcor_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTWFnbnVzLA0KDQpNYW55IHRoYW5rcyBmb3IgeW91ciByZXZpZXcgYW5kIGZlZWRiYWNrLiBX ZSBoYXZlIHBvc3RlZCBhIG5ldyB2ZXJzaW9uIG9mIHRoZSBkb2N1bWVudCB0aGF0IGFkZHJlc3Nl cyBhbGwgeW91ciBjb21tZW50cyBmcm9tIHRoZSBTRUNESVIgZWFybHkgcmV2aWV3LiBUaGlzIHZl cnNpb24gaW5jbHVkZXMgYWxsIHRoZSBXRyBMYXN0IENhbGwgY29tbWVudHMgaW5jbHVkaW5nIFRT VkFSVCBhbmQgU0VDRElSIGVhcmx5IHJldmlld3MuDQoNCg0KaHR0cHM6Ly9tYWlsYXJjaGl2ZS5p ZXRmLm9yZy9hcmNoL21zZy9udm8zL29UWThlNlhUUlA2N01zbzctZEtvcFdOcW80WQ0KDQpSZWdh cmRzLA0KSWxhbmdvIEdhbmdhDQpFZGl0b3IsIEdlbmV2ZQ0KDQoNCkZyb206IEdhbmdhLCBJbGFu Z28gUyBbbWFpbHRvOmlsYW5nby5zLmdhbmdhQGludGVsLmNvbV0NClNlbnQ6IFdlZG5lc2RheSwg Tm92ZW1iZXIgNywgMjAxOCAxMTozMCBBTQ0KVG86IE1hZ251cyBOeXN0csO2bSA8bWFnbnVzbkBn bWFpbC5jb20+DQpDYzogc2VjZGlyQGlldGYub3JnOyBkcmFmdC1pZXRmLW52bzMtZ2VuZXZlQGll dGYub3JnOyBudm8zLWNoYWlyc0BpZXRmLm9yZw0KU3ViamVjdDogUkU6IFNlY2RpciByZXZpZXcg KGVhcmx5IHJldmlldykgb2YgZHJhZnQtaWV0Zi1udm8zLWdlbmV2ZQ0KDQpIaSBNYWdudXMsDQpU aGFua3MgZm9yIHlvdXIgcmV2aWV3IGFuZCBmZWVkYmFjay4gV2UgaGF2ZSBhZGRyZXNzZWQgYWxs IDMgb2YgeW91ciBjb21tZW50cy4gV2Ugd2lsbCBiZSB1cGRhdGluZyB0aGUgZHJhZnQgdG8gYWRk cmVzcyB0aGVzZSBhbmQgV0cgTEMgY29tbWVudHMsIGluIHRoZSBuZXh0IHdlZWsgb3IgdHdvLg0K UmVnYXJkcywNCklsYW5nbw0KDQpGcm9tOiBNYWdudXMgTnlzdHLDtm0gW21haWx0bzptYWdudXNu QGdtYWlsLmNvbV0NClNlbnQ6IFR1ZXNkYXksIE5vdmVtYmVyIDYsIDIwMTggMTE6MjAgUE0NClRv OiBHYW5nYSwgSWxhbmdvIFMgPGlsYW5nby5zLmdhbmdhQGludGVsLmNvbTxtYWlsdG86aWxhbmdv LnMuZ2FuZ2FAaW50ZWwuY29tPj4NCkNjOiBzZWNkaXJAaWV0Zi5vcmc8bWFpbHRvOnNlY2RpckBp ZXRmLm9yZz47IGRyYWZ0LWlldGYtbnZvMy1nZW5ldmVAaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWll dGYtbnZvMy1nZW5ldmVAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogU2VjZGlyIHJldmlldyAoZWFy bHkgcmV2aWV3KSBvZiBkcmFmdC1pZXRmLW52bzMtZ2VuZXZlDQoNCkhpIElsYW5nbywNClRoYW5r cyBmb3IgeW91ciB0aG9yb3VnaCBmb2xsb3ctdXAuIFRvIG1lLCB0aGUgbmV3IHRleHQgbG9va3Mg dmVyeSBnb29kLiBZb3UgY291bGQgc2hvcnRlbiAoYW5kIHBlcmhhcHMgYWRkIGNsYXJpdHkpIGJ5 IHJlcGxhY2luZyAiSGVuY2UgYW4gb3B0aW9uLi4uIiB3aXRoIGp1c3QgIkFuIG9wdGlvbiAuLi4i DQo8SWxhbmdvPiBZZXMsIHRoaXMgc2hvdWxkIGJlIGZpbmUuDQoNClRoYW5rcywNCi9NDQoNCk9u IFR1ZSwgTm92IDYsIDIwMTggYXQgNzoxMSBQTSBHYW5nYSwgSWxhbmdvIFMgPGlsYW5nby5zLmdh bmdhQGludGVsLmNvbTxtYWlsdG86aWxhbmdvLnMuZ2FuZ2FAaW50ZWwuY29tPj4gd3JvdGU6DQpI aSBNYWdudXMsDQoNCkhlcmUgaXMgb3VyIHByb3Bvc2VkIHRleHQgdGhhdCB3ZSBiZWxpZXZlIHdp bGwgc2F0aXNmeSB5b3VyIGNvbW1lbnQgb24gMy41LjE6DQoNCkluIFNlY3Rpb24gMi4yLjEgYWRk IG5ldyBoaWdobGlnaHRlZCB0ZXh0IGluIHBhcmFncmFwaCB0aGF0IGJlZ2FuIHdpdGgg4oCcVHJh bnNpdCBkZXZpY2VzLi7igJ0NCk9wdGlvbnMsIGlmIHByZXNlbnQgaW4gdGhlIHBhY2tldCwgTVVT VCBiZSBnZW5lcmF0ZWQgYW5kIHRlcm1pbmF0ZWQgYnkgZW5kIHBvaW50cy4gVHJhbnNpdCBkZXZp Y2VzIE1BWSBiZSBhYmxlIHRvIGludGVycHJldCB0aGUgb3B0aW9ucywgaG93ZXZlciwgYXMNCiAg IG5vbi10ZXJtaW5hdGluZyBkZXZpY2VzLCB0cmFuc2l0IGRldmljZXMgZG8gbm90IG9yaWdpbmF0 ZSBvcg0KICAgdGVybWluYXRlIHRoZSBHZW5ldmUgcGFja2V0LCBoZW5jZSBNVVNUIE5PVCBpbnNl cnQgb3IgZGVsZXRlIG9wdGlvbnMsDQogICB3aGljaCBpcyB0aGUgcmVzcG9uc2liaWxpdHkgb2Yg R2VuZXZlIGVuZHBvaW50cy4gIFRoZSBwYXJ0aWNpcGF0aW9uDQogICBvZiB0cmFuc2l0IGRldmlj ZXMgaW4gaW50ZXJwcmV0aW5nIG9wdGlvbnMgaXMgT1BUSU9OQUwuDQoNCg0KU2VjdGlvbiAzLjUu MSAtIFJlbW92ZSB0aGUgaGlnaGxpZ2h0ZWQgdGV4dDoNCm8gIFNvbWUgb3B0aW9ucyBtYXkgYmUg ZGVmaW5lZCBpbiBzdWNoIGEgd2F5IHRoYXQgdGhlIHBvc2l0aW9uIGluIHRoZQ0KICAgICAgb3B0 aW9uIGxpc3QgaXMgc2lnbmlmaWNhbnQuICBPcHRpb25zIG9yIHRoZWlyIG9yZGVyaW5nLCBNVVNU IE5PVA0KICAgICAgYmUgY2hhbmdlZCBieSB0cmFuc2l0IGRldmljZXMuDQoNClNlY3Rpb24gMy41 LjEgLSBBZGQgaGlnaGxpZ2h0ZWQgdGV4dCB0byB0aGUgbGFzdCBidWxsZXQ6DQogICBvICBBbiBv cHRpb24gU0hPVUxEIE5PVCBiZSBkZXBlbmRlbnQgdXBvbiBhbnkgb3RoZXIgb3B0aW9uIGluIHRo ZSBwYWNrZXQsDQogaS5lLiwgb3B0aW9ucyBjYW4gYmUgcHJvY2Vzc2VkIGluZGVwZW5kZW50IG9m IG9uZSBhbm90aGVyLiBIZW5jZSBhbiBvcHRpb24gTVVTVCBOT1QgYWZmZWN0IHRoZSBwYXJzaW5n IG9yIGludGVycHJldGF0aW9uIG9mIGFueSBvdGhlciBvcHRpb24uDQoNClJlbW92ZSB0aGUgZm9s bG93aW5nIHBhcmFncmFwaCBmcm9tIDYuMjoNCkdlbmV2ZSBzdXBwb3J0cyBHZW5ldmUgT3B0aW9u cywgc28gYW4gb3BlcmF0b3IgbWF5IGNob29zZSB0byB1c2UgYQ0KICAgR2VuZXZlIG9wdGlvbiBU TFYgdG8gcHJvdmlkZSBhIGNyeXB0b2dyYXBoaWMgZGF0YSBwcm90ZWN0aW9uDQogICBtZWNoYW5p c20sIHRvIHZlcmlmeSB0aGUgZGF0YSBpbnRlZ3JpdHkgb2YgdGhlIEdlbmV2ZSBoZWFkZXIsIEdl bmV2ZQ0KICAgb3B0aW9ucyBvciB0aGUgZW50aXJlIEdlbmV2ZSBwYWNrZXQgaW5jbHVkaW5nIHRo ZSBwYXlsb2FkLg0KICAgSW1wbGVtZW50YXRpb24gb2Ygc3VjaCBhIG1lY2hhbmlzbSBpcyBiZXlv bmQgdGhlIHNjb3BlIG9mIHRoaXMNCiAgIGRvY3VtZW50Lg0KDQpJbnRyb2R1Y2UgbmV3IHNlY3Rp b24gYWZ0ZXIgNi4zIGFzIGZvbGxvd3M6DQo2LjQgIE9wdGlvbnMgSW50ZXJwcmV0YXRpb24gYnkg VHJhbnNpdCBEZXZpY2VzDQoNCk9wdGlvbnMsIGlmIHByZXNlbnQgaW4gdGhlIHBhY2tldCwgYXJl IGdlbmVyYXRlZCBhbmQgdGVybWluYXRlZCBieSBlbmQgcG9pbnRzLiBBcyBpbmRpY2F0ZWQgaW4g Mi4yLjEsIHRyYW5zaXQgZGV2aWNlcyBtYXkgaW50ZXJwcmV0IHRoZSBvcHRpb25zLiBIb3dldmVy LCBpZiB0aGUgcGFja2V0IGlzIHByb3RlY3RlZCBieSBlbmQgcG9pbnQgdG8gZW5kIHBvaW50IGVu Y3J5cHRpb24sIGZvciBleGFtcGxlIHRocm91Z2ggSVBzZWMsIHRyYW5zaXQgZGV2aWNlcyB3aWxs IG5vdCBoYXZlIHZpc2liaWxpdHkgaW50byB0aGUgR2VuZXZlIGhlYWRlciBvciBvcHRpb25zIGlu IHRoZSBwYWNrZXQuIEluIGNhc2VzIHdoZXJlIG9wdGlvbnMgYXJlIGludGVycHJldGVkIGJ5IHRy YW5zaXQgZGV2aWNlcywgdGhlIG9wZXJhdG9yIE1VU1QgZW5zdXJlIHRoYXQgdHJhbnNpdCBkZXZp Y2VzIGFyZSB0cnVzdGVkIGFuZCBub3QgY29tcHJvbWlzZWQuIEltcGxlbWVudGF0aW9uIG9mIGEg bWVjaGFuaXNtIHRvIGVuc3VyZSB0aGlzIHRydXN0IGlzIGJleW9uZCB0aGUgc2NvcGUgb2YgdGhp cyBkb2N1bWVudC4NCg0KUGxlYXNlIGxldCB1cyBrbm93IGlmIHRoaXMgYWRkcmVzc2VzIHlvdXIg Y29tbWVudCBvbiAzLjUuMS4gIFRoZSBvdGhlciB0d28gY29tbWVudHMgaGF2ZSBiZWVuIHNhdGlz ZmllZCBhcyBub3RlZCBiZWxvdy4NCg0KVGhhbmtzLA0KSWxhbmdvDQoNCg0KRnJvbTogTWFnbnVz IE55c3Ryw7ZtIFttYWlsdG86bWFnbnVzbkBnbWFpbC5jb208bWFpbHRvOm1hZ251c25AZ21haWwu Y29tPl0NClNlbnQ6IFdlZG5lc2RheSwgT2N0b2JlciAzMSwgMjAxOCAxMTozNCBBTQ0KVG86IEdh bmdhLCBJbGFuZ28gUyA8aWxhbmdvLnMuZ2FuZ2FAaW50ZWwuY29tPG1haWx0bzppbGFuZ28ucy5n YW5nYUBpbnRlbC5jb20+Pjsgc2VjZGlyQGlldGYub3JnPG1haWx0bzpzZWNkaXJAaWV0Zi5vcmc+ OyBkcmFmdC1pZXRmLW52bzMtZ2VuZXZlQGlldGYub3JnPG1haWx0bzpkcmFmdC1pZXRmLW52bzMt Z2VuZXZlQGlldGYub3JnPg0KU3ViamVjdDogUkU6IFNlY2RpciByZXZpZXcgKGVhcmx5IHJldmll dykgb2YgZHJhZnQtaWV0Zi1udm8zLWdlbmV2ZQ0KDQpIaSBJbGFuZ28sDQpGb3IgMy40LCBJIHRo aW5rIHRoaXMgbWF5IGJlIHN1ZmZpY2llbnQuDQoNCkZvciA2LjIsIEkgd2lsbCBkZWZlciB0byB0 aGUgSUVURiBkaXJlY3Rvci90ZWxlY2hhdCBkaXNjdXNzaW9uIHRoYXQgd2lsbCBvY2N1ciBhdCBz b21lIHBvaW50IGZvciB0aGlzIGRyYWZ0LiBJZiB0aGUgaW50ZW50IGlzIGludGVyb3BlcmFiaWxp dHkgYW5kIHJvYnVzdG5lc3Mgb2Ygc3VjaCBhbiBvcHRpb24sIHRoZW4gSSB3b3VsZCByZWNvbW1l bmQgaXQgdG8gYmUgc3BlY2lmaWVkIGluIHRoZSBJRVRGLCBidXQgSSBjYW4gYWxzbyBzZWUgaG93 IHlvdSB3b3VsZCBwcmVmZXIgdGhhdCBzdWNoIHNwZWNpZmljYXRpb24gd29yayBvY2N1cnMgb3V0 c2lkZSB0aGlzIHBhcnRpY3VsYXIgZHJhZnQg4oCTIHdoaWNoIHNob3VsZCBiZSBkb2FibGUuIFBl cmhhcHMgc3RheWluZyBzaWxlbnQgb24gdGhlIG9wdGlvbiBhbHRlcm5hdGl2ZSBhbmQganVzdCBy ZWNvbW1lbmQgbGV2ZXJhZ2luZyBsYXllci1wcm92aWRlZCBpbmZyYXN0cnVjdHVyZSBzdWNoIGFz IGlwc2VjIG1heSBiZSBiZXN0IGZvciBub3c/DQoNCkknbGwgYXdhaXQgeW91ciBzdWdnZXN0ZWQg dXBkYXRlZCBsYW5ndWFnZSBmb3IgMy41LjEuDQoNClRoYW5rcywNCg0KU2VudCBmcm9tIG15IFdp bmRvd3MgMTAgcGhvbmUNCg0KRnJvbTogR2FuZ2EsIElsYW5nbyBTPG1haWx0bzppbGFuZ28ucy5n YW5nYUBpbnRlbC5jb20+DQpTZW50OiBUdWVzZGF5LCBPY3RvYmVyIDMwLCAyMDE4IDE4OjEyDQpU bzogTWFnbnVzIE55c3Ryw7ZtPG1haWx0bzptYWdudXNuQGdtYWlsLmNvbT47IHNlY2RpckBpZXRm Lm9yZzxtYWlsdG86c2VjZGlyQGlldGYub3JnPjsgZHJhZnQtaWV0Zi1udm8zLWdlbmV2ZUBpZXRm Lm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi1udm8zLWdlbmV2ZUBpZXRmLm9yZz4NClN1YmplY3Q6IFJF OiBTZWNkaXIgcmV2aWV3IChlYXJseSByZXZpZXcpIG9mIGRyYWZ0LWlldGYtbnZvMy1nZW5ldmUN Cg0KSGkgTWFnbnVzLA0KDQpUaGFua3MgZm9yIHlvdXIgcmV2aWV3IGFuZCBmZWVkYmFjay4gUGxl YXNlIHNlZSBpbmxpbmUgZm9yIG15IHJlc3BvbnNlcy4NCg0KUmVnYXJkcywNCklsYW5nbw0KDQoN CkZyb206IE1hZ251cyBOeXN0csO2bSBbbWFpbHRvOm1hZ251c25AZ21haWwuY29tXQ0KU2VudDog VHVlc2RheSwgT2N0b2JlciAyMywgMjAxOCA5OjAxIFBNDQpUbzogc2VjZGlyQGlldGYub3JnPG1h aWx0bzpzZWNkaXJAaWV0Zi5vcmc+OyBkcmFmdC1pZXRmLW52bzMtZ2VuZXZlQGlldGYub3JnPG1h aWx0bzpkcmFmdC1pZXRmLW52bzMtZ2VuZXZlQGlldGYub3JnPg0KU3ViamVjdDogU2VjZGlyIHJl dmlldyAoZWFybHkgcmV2aWV3KSBvZiBkcmFmdC1pZXRmLW52bzMtZ2VuZXZlDQoNCkkgaGF2ZSBy ZXZpZXdlZCB0aGlzIGRvY3VtZW50IGFzIHBhcnQgb2YgdGhlIHNlY3VyaXR5IGRpcmVjdG9yYXRl J3MNCm9uZ29pbmcgZWZmb3J0IHRvIHJldmlldyBhbGwgSUVURiBkb2N1bWVudHMgYmVpbmcgcHJv Y2Vzc2VkIGJ5IHRoZQ0KSUVTRy4gVGhlc2UgY29tbWVudHMgd2VyZSB3cml0dGVuIHByaW1hcmls eSBmb3IgdGhlIGJlbmVmaXQgb2YgdGhlDQpzZWN1cml0eSBhcmVhIGRpcmVjdG9ycy4gIERvY3Vt ZW50IGVkaXRvcnMgYW5kIFdHIGNoYWlycyBzaG91bGQgdHJlYXQNCnRoZXNlIGNvbW1lbnRzIGp1 c3QgbGlrZSBhbnkgb3RoZXIgbGFzdCBjYWxsIGNvbW1lbnRzLg0KDQpUaGlzIGRvY3VtZW50IGRl c2NyaWJlcyAiR2VuZXZlLCIgYSBwcm90b2NvbCBmb3IgR0VuZXJpYyBORXR3b3JrIFZpcnR1YWxp emF0aW9uIEVuY2Fwc3VsYXRpb24uIFRoZSBkb2N1bWVudCBpcyB3cml0dGVuIGluIGEgY2xlYXIg bWFubmVyIGFuZCB3aXRoIGEgdGhvcm91Z2ggU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgc2VjdGlv bi4gSSBoYXZlIGp1c3QgYSBmZXcgcXVlc3Rpb25zL2NvbW1lbnRzOg0KDQotIFNlY3Rpb24gMy40 OiBUaGUgIk1VU1QgaWdub3JlIiBmb3IgdGhlIHJlc2VydmVkIGJpdHMgc2hvdWxkIHByZXN1bWFi bHkgc3RhdGUgIlNIQUxMIGJlIGlnbm9yZWQgZm9yIHRoaXMgdmVyc2lvbiBvZiB0aGUgR2VuZXZl IHByb3RvY29sLiIgLSBhcyBJIGltYWdpbmUgdGhhdCBpbiBhIGZ1dHVyZSB2ZXJzaW9uLCB0aGVz ZSBiaXRzIG1heSBub3QgYmUgaWdub3JlZD8NCg0KPElsYW5nbz4gSW4gdGhlb3J5LCBhIGZ1dHVy ZSB2ZXJzaW9uIG1heSBjaGFuZ2UgdGhlIGJlaGF2aW9yIG9mIGFueSBvZiB0aGUgaGVhZGVyIGZp ZWxkcyBpbmNsdWRpbmcgdGhlIHJlc2VydmVkIGJpdHMuICBUaGUgaGVhZGVyIGRlZmluaXRpb24g aXMgZm9yIHRoaXMgdmVyc2lvbiBvZiB0aGUgcHJvdG9jb2wuDQoNClBsZWFzZSBzZWUgaWYgdGhl IGZvbGxvd2luZyB0ZXh0IHdvdWxkIHNhdGlzZnkgdGhlIGludGVudCBvZiB5b3VyIGNvbW1lbnQu DQrigJxSZXNlcnZlZCBmaWVsZCB3aGljaCBNVVNUIGJlIHplcm8gb24gdHJhbnNtaXNzaW9uIGFu ZCBNVVNUIGJlIGlnbm9yZWQgb24gcmVjZWlwdC7igJ0NCg0KT3IgbGV0IHVzIGtub3cgaWYgeW91 IHN0aWxsIHdhbnQgdG8gaGF2ZSB0aGlzIHF1YWxpZmllZCB3aXRoIOKAnGZvciB0aGlzIHZlcnNp b24gb2YgdGhlIHByb3RvY29s4oCdDQo8Lz4NCg0KLSBTZWN0aW9uIDMuNS4xOiBJIHdvbmRlciBh Ym91dCB0aGUgc2ltdWx0YW5lb3VzIHJlcXVpcmVtZW50IHRoYXQgb25lIG9wdGlvbiBtdXN0IG5v dCBhZmZlY3QgdGhlIHBhcnNpbmcgb3IgaW50ZXJwcmV0YXRpb24gb2YgYW5vdGhlciBvcHRpb24g YnV0IHRoYXQgdGhlIHNlcXVlbmNpbmcgKG9yZGVyKSBvZiBvcHRpb25zIG1heSBiZSBzaWduaWZp Y2FudCAtIHRoZXkgc2VlbSB0byBiZSBjb250cmFkaWN0b3J5IHNpbmNlIGlmIHRoZSBzZXF1ZW5j aW5nICppcyogc2lnbmlmaWNhbnQsIHRoZW4gc29tZSBvcHRpb24gbXVzdCBiZSBpbXBhY3RlZCBi eSBhIHByZXZpb3VzIG9uZSdzIHZhbHVlPyBGcm9tIGEgc2VjdXJpdHkgcGVyc3BlY3RpdmUsIEkg YWxzbyB3b25kZXIgaWYgdGhlcmUgY291bGQgYmUgc2VjdXJpdHkgY29uc2VxdWVuY2VzIG9mIHJl LW9yZGVyaW5nIG9wdGlvbnMgKGFuZCBob3cgdG8gdGVsbCBpZiBzb21lb25lIGRpZCByZS1vcmRl ciAtIHNlZSBiZWxvdyk/DQoNCjxJbGFuZ28+IFlvdSByYWlzZSBhIGdvb2QgcG9pbnQuIFRoZSBp bnRlbnQgb2YgdGhpcyBzdGF0ZW1lbnQgaXMsIHBhcnNpbmcgYW5kIGludGVycHJldGF0aW9uIG9m IG9wdGlvbnMgc2hvdWxkIG5vdCBiZSBkZXBlbmRlbnQgb24gb25lIGFub3RoZXIuIFdlIGFyZSBk aXNjdXNzaW5nIGFtb25nIHRoZSBhdXRob3JzIHRvIHNlZSBob3cgd2UgY2FuIGluY2x1ZGUgYXBw cm9wcmlhdGUgY2xhcmlmeWluZyBzdGF0ZW1lbnRzIHRvIGFkZHJlc3MgeW91ciBwb2ludC4gSSB3 aWxsIHVwZGF0ZSB5b3Ugc2hvcnRseS4NCjwvPg0KDQotIFNlY3Rpb24gNi4yLCBzaG91bGRuJ3Qg c3VjaCBhbiBPcHRpb24gYmUgZGVmaW5lZCB0byByZWR1Y2UgdGhlIHJpc2sgb2YgdW5kZXItc3Bl Y2lmaWVkIG9yIHN1YnBhciBzcGVjaWZpY2F0aW9ucyBvZiBzdWNoIGludGVncml0eSBtZWNoYW5p c21zPyBPciBhbHNvIGZyb20gYW4gaW50ZXJvcCBwZXJzcGVjdGl2ZT8NCg0KPElsYW5nbz4gVXNp bmcgYSBHZW5ldmUgb3B0aW9uIGZvciB0aGUgcHVycG9zZSBvZiBkYXRhIGludGVncml0eSBpcyBt b3JlIG9mIGFuIG9wdGltaXphdGlvbi4gT3RoZXJ3aXNlIGRhdGEgaW50ZWdyaXR5IGNvdWxkIGJl IHByb3ZpZGVkIGJ5IHVzaW5nIGV4aXN0aW5nIG1lY2hhbmlzbXMgbGlrZSBJUHNlYyAoYXMgc3Rh dGVkIGluIHNlY29uZCBwYXJhZ3JhcGggb2YgNi4yKS4gV2UgaW5jbHVkZWQgdGhlIGxhc3QgcGFy YWdyYXBoIHRvIHNob3cgb3RoZXIgcG9zc2liaWxpdGllcy4gV2UgY291bGQgcmVtb3ZlIHRoaXMg cGFyYWdyYXBoIGlmIGl0IG1heSBjYXVzZSBhbnkgY29uZnVzaW9uLg0KDQpXZSB3b3VsZCBsaWtl IHRvIGtlZXAgdGhlIEdlbmV2ZSBiYXNlIHNwZWNpZmljYXRpb24gaW5kZXBlbmRlbnQgb2Ygb3B0 aW9ucyBzcGVjaWZpY2F0aW9ucywgb3B0aW9ucyBjb3VsZCBiZSBhIGRlZmluZWQgaW4gYSBmdXR1 cmUgc3RhbmRhcmRzIGFjdGlvbi4NCjwvPg0KDQoNClRoYW5rcy4NCi0tIE1hZ251cw0KDQoNCg0K LS0NCi0tIE1hZ251cw0K --_000_C5A274B25007804B800CB5B289727E3583D6B5E7ORSMSX116amrcor_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb1BsYWluVGV4dCwgbGku TXNvUGxhaW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdp bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFw aCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdp bi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFy Z2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBw dDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLkVtYWlsU3R5 bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1z dHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5QbGFpblRleHRDaGFyDQoJe21zby1zdHlsZS1u YW1lOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5 bGUtbGluazoiUGxhaW4gVGV4dCI7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1z aXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJ bWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtl bmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJl ZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0 PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJs dWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5IaSBNYWdudXMsPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5NYW55IHRoYW5rcyBmb3Ig eW91ciByZXZpZXcgYW5kIGZlZWRiYWNrLiBXZSBoYXZlIHBvc3RlZCBhIG5ldyB2ZXJzaW9uIG9m IHRoZSBkb2N1bWVudCB0aGF0IGFkZHJlc3NlcyBhbGwgeW91ciBjb21tZW50cyBmcm9tIHRoZSBT RUNESVIgZWFybHkgcmV2aWV3LiBUaGlzIHZlcnNpb24NCiBpbmNsdWRlcyBhbGwgdGhlIFdHIExh c3QgQ2FsbCBjb21tZW50cyBpbmNsdWRpbmcgVFNWQVJUIGFuZCBTRUNESVIgZWFybHkgcmV2aWV3 cy4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48YSBocmVmPSJodHRwczovL21haWxhcmNoaXZlLmlldGYub3Jn L2FyY2gvbXNnL252bzMvb1RZOGU2WFRSUDY3TXNvNy1kS29wV05xbzRZIj5odHRwczovL21haWxh cmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL252bzMvb1RZOGU2WFRSUDY3TXNvNy1kS29wV05xbzRZ PC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5SZWdhcmRzLDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj5JbGFuZ28gR2FuZ2E8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+RWRpdG9yLCBHZW5ldmU8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGEgbmFtZT0iX01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9hPjwvcD4NCjxkaXY+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfX19f X3JlcGx5c2VwYXJhdG9yIj48L2E+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj4gR2FuZ2EsIElsYW5nbyBTIFttYWlsdG86aWxhbmdvLnMuZ2FuZ2FA aW50ZWwuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgTm92ZW1iZXIgNywgMjAx OCAxMTozMCBBTTxicj4NCjxiPlRvOjwvYj4gTWFnbnVzIE55c3Ryw7ZtICZsdDttYWdudXNuQGdt YWlsLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IHNlY2RpckBpZXRmLm9yZzsgZHJhZnQtaWV0Zi1u dm8zLWdlbmV2ZUBpZXRmLm9yZzsgbnZvMy1jaGFpcnNAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0 OjwvYj4gUkU6IFNlY2RpciByZXZpZXcgKGVhcmx5IHJldmlldykgb2YgZHJhZnQtaWV0Zi1udm8z LWdlbmV2ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5IaSBNYWdudXMsPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PlRoYW5rcyBmb3IgeW91ciByZXZpZXcgYW5kIGZlZWRiYWNrLiBXZSBoYXZlIGFkZHJlc3NlZCBh bGwgMyBvZiB5b3VyIGNvbW1lbnRzLiBXZSB3aWxsIGJlIHVwZGF0aW5nIHRoZSBkcmFmdCB0byBh ZGRyZXNzIHRoZXNlIGFuZCBXRyBMQyBjb21tZW50cywgaW4gdGhlIG5leHQNCiB3ZWVrIG9yIHR3 by4gPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPklsYW5nbzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPiBNYWdudXMgTnlzdHLDtm0gWzxhIGhyZWY9Im1haWx0bzptYWdudXNuQGdtYWlsLmNv bSI+bWFpbHRvOm1hZ251c25AZ21haWwuY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUdWVz ZGF5LCBOb3ZlbWJlciA2LCAyMDE4IDExOjIwIFBNPGJyPg0KPGI+VG86PC9iPiBHYW5nYSwgSWxh bmdvIFMgJmx0OzxhIGhyZWY9Im1haWx0bzppbGFuZ28ucy5nYW5nYUBpbnRlbC5jb20iPmlsYW5n by5zLmdhbmdhQGludGVsLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiA8YSBocmVmPSJtYWls dG86c2VjZGlyQGlldGYub3JnIj5zZWNkaXJAaWV0Zi5vcmc8L2E+OyA8YSBocmVmPSJtYWlsdG86 ZHJhZnQtaWV0Zi1udm8zLWdlbmV2ZUBpZXRmLm9yZyI+DQpkcmFmdC1pZXRmLW52bzMtZ2VuZXZl QGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogU2VjZGlyIHJldmlldyAoZWFy bHkgcmV2aWV3KSBvZiBkcmFmdC1pZXRmLW52bzMtZ2VuZXZlPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIElsYW5nbyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcyBmb3IgeW91ciB0aG9yb3VnaCBm b2xsb3ctdXAuIFRvIG1lLCB0aGUgbmV3IHRleHQgbG9va3MgdmVyeSBnb29kLiBZb3UgY291bGQg c2hvcnRlbiAoYW5kIHBlcmhhcHMgYWRkIGNsYXJpdHkpIGJ5IHJlcGxhY2luZyAmcXVvdDtIZW5j ZSBhbiBvcHRpb24uLi4mcXVvdDsgd2l0aCBqdXN0ICZxdW90O0FuIG9wdGlvbiAuLi4mcXVvdDs8 c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7DQo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+Jmx0O0lsYW5nbyZndDsgWWVzLCB0aGlzIHNob3VsZCBiZSBmaW5l LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3MsPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4vTTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUdWUsIE5vdiA2LCAyMDE4IGF0IDc6 MTEgUE0gR2FuZ2EsIElsYW5nbyBTICZsdDs8YSBocmVmPSJtYWlsdG86aWxhbmdvLnMuZ2FuZ2FA aW50ZWwuY29tIj5pbGFuZ28ucy5nYW5nYUBpbnRlbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4t bGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImNvbG9yOiMxRjQ5N0QiPkhpIE1hZ251cyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJj b2xvcjojMUY0OTdEIj5IZXJlIGlzIG91ciBwcm9wb3NlZCB0ZXh0IHRoYXQgd2UgYmVsaWV2ZSB3 aWxsIHNhdGlzZnkgeW91ciBjb21tZW50IG9uIDMuNS4xOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGk+PHNwYW4g c3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkluIFNlY3Rpb24gMi4yLjEgYWRkIG5ldyBoaWdobGlnaHRl ZCB0ZXh0IGluIHBhcmFncmFwaCB0aGF0IGJlZ2FuIHdpdGgg4oCcVHJhbnNpdCBkZXZpY2VzLi7i gJ08L3NwYW4+PC9pPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+T3B0aW9ucywgaWYgcHJlc2VudCBpbiB0aGUgcGFja2V0LCBNVVNUIGJlIGdlbmVyYXRlZCBh bmQgdGVybWluYXRlZCBieSBlbmQgcG9pbnRzLiBUcmFuc2l0IGRldmljZXMgTUFZIGJlIGFibGUg dG8gaW50ZXJwcmV0DQogdGhlIG9wdGlvbnMsIGhvd2V2ZXIsIGFzPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7IG5vbi10ZXJt aW5hdGluZyBkZXZpY2VzLCB0cmFuc2l0IGRldmljZXMgZG8gbm90IG9yaWdpbmF0ZSBvcjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZu YnNwOyB0ZXJtaW5hdGUgdGhlIEdlbmV2ZSBwYWNrZXQsIGhlbmNlIE1VU1QgTk9UIGluc2VydCBv ciBkZWxldGUgb3B0aW9ucyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztj b2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsgd2hpY2ggaXMgdGhlIHJlc3BvbnNpYmlsaXR5IG9m IEdlbmV2ZSBlbmRwb2ludHMuJm5ic3A7IFRoZSBwYXJ0aWNpcGF0aW9uPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7IG9mIHRy YW5zaXQgZGV2aWNlcyBpbiBpbnRlcnByZXRpbmcgb3B0aW9ucyBpcyBPUFRJT05BTC48L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxpPjxzcGFuIHN0 eWxlPSJjb2xvcjojMUY0OTdEIj5TZWN0aW9uIDMuNS4xIC0gUmVtb3ZlIHRoZSBoaWdobGlnaHRl ZCB0ZXh0Ojwvc3Bhbj48L2k+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjoj MUY0OTdEIj5vJm5ic3A7IFNvbWUgb3B0aW9ucyBtYXkgYmUgZGVmaW5lZCBpbiBzdWNoIGEgd2F5 IHRoYXQgdGhlIHBvc2l0aW9uIGluIHRoZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBvcHRp b24gbGlzdCBpcyBzaWduaWZpY2FudC4mbmJzcDsgT3B0aW9ucw0KPC9zcGFuPjxzPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpyZWQiPm9yIHRo ZWlyIG9yZGVyaW5nLDwvc3Bhbj48L3M+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiBNVVNUIE5PVDwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBiZSBjaGFuZ2VkIGJ5IHRyYW5zaXQgZGV2aWNlcy48L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxpPjxzcGFuIHN0eWxlPSJjb2xvcjoj MUY0OTdEIj5TZWN0aW9uIDMuNS4xIC0gQWRkIGhpZ2hsaWdodGVkIHRleHQgdG8gdGhlIGxhc3Qg YnVsbGV0Ojwvc3Bhbj48L2k+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjoj MUY0OTdEIj4mbmJzcDsmbmJzcDsgbyZuYnNwOw0KPC9zcGFuPjx1PjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMDBCMDUwIj5BbiBvcHRpb24g U0hPVUxEIE5PVCBiZSBkZXBlbmRlbnQgdXBvbiBhbnkgb3RoZXIgb3B0aW9uIGluIHRoZSBwYWNr ZXQsDQo8L3NwYW4+PC91PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 dT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6 IzAwQjA1MCI+Jm5ic3A7aS5lLiwgb3B0aW9ucyBjYW4gYmUgcHJvY2Vzc2VkIGluZGVwZW5kZW50 IG9mIG9uZSBhbm90aGVyLiBIZW5jZTwvc3Bhbj48L3U+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPg0KIGFuIG9wdGlvbiBNVVNU IE5PVCBhZmZlY3QgdGhlIHBhcnNpbmcgb3IgaW50ZXJwcmV0YXRpb24gb2YgYW55IG90aGVyIG9w dGlvbi48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdE Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxp PjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5SZW1vdmUgdGhlIGZvbGxvd2luZyBwYXJhZ3Jh cGggZnJvbSA2LjI6PC9zcGFuPjwvaT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHM+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPkdlbmV2ZSBzdXBwb3J0cyBHZW5ldmUgT3B0aW9ucywgc28gYW4gb3Bl cmF0b3IgbWF5IGNob29zZSB0byB1c2UgYTwvc3Bhbj48L3M+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsgR2VuZXZlIG9wdGlvbiBU TFYgdG8gcHJvdmlkZSBhIGNyeXB0b2dyYXBoaWMgZGF0YSBwcm90ZWN0aW9uPC9zcGFuPjwvcz48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHM+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZu YnNwOyBtZWNoYW5pc20sIHRvIHZlcmlmeSB0aGUgZGF0YSBpbnRlZ3JpdHkgb2YgdGhlIEdlbmV2 ZSBoZWFkZXIsIEdlbmV2ZTwvc3Bhbj48L3M+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsgb3B0aW9ucyBvciB0aGUgZW50aXJlIEdl bmV2ZSBwYWNrZXQgaW5jbHVkaW5nIHRoZSBwYXlsb2FkLjwvc3Bhbj48L3M+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsgSW1wbGVt ZW50YXRpb24gb2Ygc3VjaCBhIG1lY2hhbmlzbSBpcyBiZXlvbmQgdGhlIHNjb3BlIG9mIHRoaXM8 L3NwYW4+PC9zPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48cz48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+Jm5ic3A7Jm5ic3A7IGRvY3VtZW50Ljwvc3Bhbj48L3M+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxhIG5hbWU9Im1fLTg0NjIzNjg0Nzg1MDIxMzExMDhfX01haWxF bmRDb21wb3NlIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjwvYT48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGk+PHNwYW4gc3R5bGU9ImNv bG9yOiMxRjQ5N0QiPkludHJvZHVjZSBuZXcgc2VjdGlvbiBhZnRlciA2LjMgYXMgZm9sbG93czo8 L3NwYW4+PC9pPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ Ni40Jm5ic3A7IE9wdGlvbnMgSW50ZXJwcmV0YXRpb24gYnkgVHJhbnNpdCBEZXZpY2VzPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+T3B0aW9u cywgaWYgcHJlc2VudCBpbiB0aGUgcGFja2V0LCBhcmUgZ2VuZXJhdGVkIGFuZCB0ZXJtaW5hdGVk IGJ5IGVuZCBwb2ludHMuIEFzIGluZGljYXRlZCBpbiAyLjIuMSwgdHJhbnNpdCBkZXZpY2VzIG1h eSBpbnRlcnByZXQNCiB0aGUgb3B0aW9ucy4gSG93ZXZlciwgaWYgdGhlIHBhY2tldCBpcyBwcm90 ZWN0ZWQgYnkgZW5kIHBvaW50IHRvIGVuZCBwb2ludCBlbmNyeXB0aW9uLCBmb3IgZXhhbXBsZSB0 aHJvdWdoIElQc2VjLCB0cmFuc2l0IGRldmljZXMgd2lsbCBub3QgaGF2ZSB2aXNpYmlsaXR5IGlu dG8gdGhlIEdlbmV2ZSBoZWFkZXIgb3Igb3B0aW9ucyBpbiB0aGUgcGFja2V0LiBJbiBjYXNlcyB3 aGVyZSBvcHRpb25zIGFyZSBpbnRlcnByZXRlZCBieSB0cmFuc2l0IGRldmljZXMsDQogdGhlIG9w ZXJhdG9yIE1VU1QgZW5zdXJlIHRoYXQgdHJhbnNpdCBkZXZpY2VzIGFyZSB0cnVzdGVkIGFuZCBu b3QgY29tcHJvbWlzZWQuIEltcGxlbWVudGF0aW9uIG9mIGEgbWVjaGFuaXNtIHRvIGVuc3VyZSB0 aGlzIHRydXN0IGlzIGJleW9uZCB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVudC48L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjoj MUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5QbGVhc2UgbGV0IHVzIGtub3cgaWYgdGhp cyBhZGRyZXNzZXMgeW91ciBjb21tZW50IG9uIDMuNS4xLiZuYnNwOyBUaGUgb3RoZXIgdHdvIGNv bW1lbnRzIGhhdmUgYmVlbiBzYXRpc2ZpZWQgYXMgbm90ZWQgYmVsb3cuDQo8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0 OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5UaGFua3MsPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+SWxh bmdvPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10 b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PGEgbmFtZT0ibV8tODQ2MjM2ODQ3ODUwMjEzMTEwOF9fX19fX3Jl cGx5c2VwYXJhdCI+PC9hPjxiPkZyb206PC9iPiBNYWdudXMgTnlzdHLDtm0gW21haWx0bzo8YSBo cmVmPSJtYWlsdG86bWFnbnVzbkBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5tYWdudXNuQGdt YWlsLmNvbTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBPY3RvYmVyIDMxLCAy MDE4IDExOjM0IEFNPGJyPg0KPGI+VG86PC9iPiBHYW5nYSwgSWxhbmdvIFMgJmx0OzxhIGhyZWY9 Im1haWx0bzppbGFuZ28ucy5nYW5nYUBpbnRlbC5jb20iIHRhcmdldD0iX2JsYW5rIj5pbGFuZ28u cy5nYW5nYUBpbnRlbC5jb208L2E+Jmd0OzsNCjxhIGhyZWY9Im1haWx0bzpzZWNkaXJAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj5zZWNkaXJAaWV0Zi5vcmc8L2E+OyA8YSBocmVmPSJtYWlsdG86 ZHJhZnQtaWV0Zi1udm8zLWdlbmV2ZUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPg0KZHJhZnQt aWV0Zi1udm8zLWdlbmV2ZUBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IFNl Y2RpciByZXZpZXcgKGVhcmx5IHJldmlldykgb2YgZHJhZnQtaWV0Zi1udm8zLWdlbmV2ZTxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkhpIElsYW5nbyw8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Rm9yIDMuNCwgSSB0aGluayB0aGlzIG1h eSBiZSBzdWZmaWNpZW50Lg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5Gb3IgNi4yLCBJ IHdpbGwgZGVmZXIgdG8gdGhlIElFVEYgZGlyZWN0b3IvdGVsZWNoYXQgZGlzY3Vzc2lvbiB0aGF0 IHdpbGwgb2NjdXIgYXQgc29tZSBwb2ludCBmb3IgdGhpcyBkcmFmdC4gSWYgdGhlIGludGVudCBp cyBpbnRlcm9wZXJhYmlsaXR5IGFuZCByb2J1c3RuZXNzIG9mIHN1Y2ggYW4gb3B0aW9uLA0KIHRo ZW4gSSB3b3VsZCByZWNvbW1lbmQgaXQgdG8gYmUgc3BlY2lmaWVkIGluIHRoZSBJRVRGLCBidXQg SSBjYW4gYWxzbyBzZWUgaG93IHlvdSB3b3VsZCBwcmVmZXIgdGhhdCBzdWNoIHNwZWNpZmljYXRp b24gd29yayBvY2N1cnMgb3V0c2lkZSB0aGlzIHBhcnRpY3VsYXIgZHJhZnQg4oCTIHdoaWNoIHNo b3VsZCBiZSBkb2FibGUuIFBlcmhhcHMgc3RheWluZyBzaWxlbnQgb24gdGhlIG9wdGlvbiBhbHRl cm5hdGl2ZSBhbmQganVzdCByZWNvbW1lbmQgbGV2ZXJhZ2luZw0KIGxheWVyLXByb3ZpZGVkIGlu ZnJhc3RydWN0dXJlIHN1Y2ggYXMgaXBzZWMgbWF5IGJlIGJlc3QgZm9yIG5vdz88bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPkknbGwgYXdhaXQgeW91ciBzdWdnZXN0ZWQgdXBkYXRlZCBsYW5n dWFnZSBmb3IgMy41LjEuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGFua3MsPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj5TZW50IGZyb20gbXkgV2luZG93cyAxMCBwaG9uZTxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtw YWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+RnJv bToNCjwvYj48YSBocmVmPSJtYWlsdG86aWxhbmdvLnMuZ2FuZ2FAaW50ZWwuY29tIiB0YXJnZXQ9 Il9ibGFuayI+R2FuZ2EsIElsYW5nbyBTPC9hPjxicj4NCjxiPlNlbnQ6IDwvYj5UdWVzZGF5LCBP Y3RvYmVyIDMwLCAyMDE4IDE4OjEyPGJyPg0KPGI+VG86IDwvYj48YSBocmVmPSJtYWlsdG86bWFn bnVzbkBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5NYWdudXMgTnlzdHLDtm08L2E+Ow0KPGEg aHJlZj0ibWFpbHRvOnNlY2RpckBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNlY2RpckBpZXRm Lm9yZzwvYT47IDxhIGhyZWY9Im1haWx0bzpkcmFmdC1pZXRmLW52bzMtZ2VuZXZlQGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+DQpkcmFmdC1pZXRmLW52bzMtZ2VuZXZlQGlldGYub3JnPC9hPjxi cj4NCjxiPlN1YmplY3Q6IDwvYj5SRTogU2VjZGlyIHJldmlldyAoZWFybHkgcmV2aWV3KSBvZiBk cmFmdC1pZXRmLW52bzMtZ2VuZXZlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5IaSBNYWdudXMsPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iY29sb3I6IzFGNDk3RCI+VGhhbmtzIGZvciB5b3VyIHJldmlldyBhbmQgZmVlZGJh Y2suIFBsZWFzZSBzZWUgaW5saW5lIGZvciBteSByZXNwb25zZXMuPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iY29sb3I6IzFGNDk3RCI+UmVnYXJkcyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5JbGFuZ288 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPkZyb206PC9iPiBNYWdudXMg TnlzdHLDtm0gWzxhIGhyZWY9Im1haWx0bzptYWdudXNuQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxh bmsiPm1haWx0bzptYWdudXNuQGdtYWlsLmNvbTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gVHVl c2RheSwgT2N0b2JlciAyMywgMjAxOCA5OjAxIFBNPGJyPg0KPGI+VG86PC9iPiA8YSBocmVmPSJt YWlsdG86c2VjZGlyQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c2VjZGlyQGlldGYub3JnPC9h PjsgPGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYtbnZvMy1nZW5ldmVAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj4NCmRyYWZ0LWlldGYtbnZvMy1nZW5ldmVAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+ U3ViamVjdDo8L2I+IFNlY2RpciByZXZpZXcgKGVhcmx5IHJldmlldykgb2YgZHJhZnQtaWV0Zi1u dm8zLWdlbmV2ZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkgaGF2ZSByZXZp ZXdlZCB0aGlzIGRvY3VtZW50IGFzIHBhcnQgb2YgdGhlIHNlY3VyaXR5IGRpcmVjdG9yYXRlJ3M8 YnI+DQpvbmdvaW5nIGVmZm9ydCB0byByZXZpZXcgYWxsIElFVEYgZG9jdW1lbnRzIGJlaW5nIHBy b2Nlc3NlZCBieSB0aGU8YnI+DQpJRVNHLiBUaGVzZSBjb21tZW50cyB3ZXJlIHdyaXR0ZW4gcHJp bWFyaWx5IGZvciB0aGUgYmVuZWZpdCBvZiB0aGU8YnI+DQpzZWN1cml0eSBhcmVhIGRpcmVjdG9y cy4mbmJzcDsgRG9jdW1lbnQgZWRpdG9ycyBhbmQgV0cgY2hhaXJzIHNob3VsZCB0cmVhdDxicj4N CnRoZXNlIGNvbW1lbnRzIGp1c3QgbGlrZSBhbnkgb3RoZXIgbGFzdCBjYWxsIGNvbW1lbnRzLjxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoaXMgZG9j dW1lbnQgZGVzY3JpYmVzICZxdW90O0dlbmV2ZSwmcXVvdDsgYSBwcm90b2NvbCBmb3IgR0VuZXJp YyBORXR3b3JrIFZpcnR1YWxpemF0aW9uIEVuY2Fwc3VsYXRpb24uIFRoZSBkb2N1bWVudCBpcyB3 cml0dGVuIGluIGEgY2xlYXIgbWFubmVyIGFuZCB3aXRoIGEgdGhvcm91Z2ggU2VjdXJpdHkgQ29u c2lkZXJhdGlvbnMNCiBzZWN0aW9uLiBJIGhhdmUganVzdCBhIGZldyBxdWVzdGlvbnMvY29tbWVu dHM6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4tIFNlY3Rpb24gMy40OiBUaGUgJnF1b3Q7TVVTVCBpZ25vcmUmcXVvdDsgZm9yIHRoZSBy ZXNlcnZlZCBiaXRzIHNob3VsZCBwcmVzdW1hYmx5IHN0YXRlICZxdW90O1NIQUxMIGJlIGlnbm9y ZWQgZm9yIHRoaXMgdmVyc2lvbiBvZiB0aGUgR2VuZXZlIHByb3RvY29sLiZxdW90OyAtIGFzIEkg aW1hZ2luZSB0aGF0IGluIGEgZnV0dXJlIHZlcnNpb24sDQogdGhlc2UgYml0cyBtYXkgbm90IGJl IGlnbm9yZWQ/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbHQ7SWxhbmdvJmd0 OyBJbiB0aGVvcnksIGEgZnV0dXJlIHZlcnNpb24gbWF5IGNoYW5nZSB0aGUgYmVoYXZpb3Igb2Yg YW55IG9mIHRoZSBoZWFkZXIgZmllbGRzIGluY2x1ZGluZyB0aGUgcmVzZXJ2ZWQgYml0cy4mbmJz cDsgVGhlIGhlYWRlciBkZWZpbml0aW9uIGlzIGZvciB0aGlzDQogdmVyc2lvbiBvZiB0aGUgcHJv dG9jb2wuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+UGxlYXNlIHNl ZSBpZiB0aGUgZm9sbG93aW5nIHRleHQgd291bGQgc2F0aXNmeSB0aGUgaW50ZW50IG9mIHlvdXIg Y29tbWVudC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0 OTdEIj7igJxSZXNlcnZlZCBmaWVsZCB3aGljaCBNVVNUIGJlIHplcm8gb24gdHJhbnNtaXNzaW9u IGFuZA0KPC9zcGFuPjx1PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90Oztjb2xvcjojMDBCMDUwIj5NVVNUIGJlPC9zcGFuPjwvdT48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+IGlnbm9yZWQg b24gcmVjZWlwdC7igJ08L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xv cjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5PciBsZXQgdXMga25vdyBpZiB5b3Ug c3RpbGwgd2FudCB0byBoYXZlIHRoaXMgcXVhbGlmaWVkIHdpdGgg4oCcZm9yIHRoaXMgdmVyc2lv biBvZiB0aGUgcHJvdG9jb2zigJ08L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbHQ7LyZndDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjoj MUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPi0gU2VjdGlvbiAzLjUuMTogSSB3b25kZXIgYWJvdXQgdGhlIHNp bXVsdGFuZW91cyByZXF1aXJlbWVudCB0aGF0IG9uZSBvcHRpb24gbXVzdCBub3QgYWZmZWN0IHRo ZSBwYXJzaW5nIG9yIGludGVycHJldGF0aW9uIG9mIGFub3RoZXIgb3B0aW9uIGJ1dCB0aGF0IHRo ZSBzZXF1ZW5jaW5nIChvcmRlcikgb2Ygb3B0aW9ucw0KIG1heSBiZSBzaWduaWZpY2FudCAtIHRo ZXkgc2VlbSB0byBiZSBjb250cmFkaWN0b3J5IHNpbmNlIGlmIHRoZSBzZXF1ZW5jaW5nICppcyog c2lnbmlmaWNhbnQsIHRoZW4gc29tZSBvcHRpb24gbXVzdCBiZSBpbXBhY3RlZCBieSBhIHByZXZp b3VzIG9uZSdzIHZhbHVlPyBGcm9tIGEgc2VjdXJpdHkgcGVyc3BlY3RpdmUsIEkgYWxzbyB3b25k ZXIgaWYgdGhlcmUgY291bGQgYmUgc2VjdXJpdHkgY29uc2VxdWVuY2VzIG9mIHJlLW9yZGVyaW5n IG9wdGlvbnMNCiAoYW5kIGhvdyB0byB0ZWxsIGlmIHNvbWVvbmUgZGlkIHJlLW9yZGVyIC0gc2Vl IGJlbG93KT88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZsdDtJbGFuZ28mZ3Q7 IFlvdSByYWlzZSBhIGdvb2QgcG9pbnQuIFRoZSBpbnRlbnQgb2YgdGhpcyBzdGF0ZW1lbnQgaXMs IHBhcnNpbmcgYW5kIGludGVycHJldGF0aW9uIG9mIG9wdGlvbnMgc2hvdWxkIG5vdCBiZSBkZXBl bmRlbnQgb24gb25lIGFub3RoZXIuIFdlIGFyZQ0KIGRpc2N1c3NpbmcgYW1vbmcgdGhlIGF1dGhv cnMgdG8gc2VlIGhvdyB3ZSBjYW4gaW5jbHVkZSBhcHByb3ByaWF0ZSBjbGFyaWZ5aW5nIHN0YXRl bWVudHMgdG8gYWRkcmVzcyB5b3VyIHBvaW50LiBJIHdpbGwgdXBkYXRlIHlvdSBzaG9ydGx5Ljwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImNvbG9yOiMxRjQ5N0QiPiZsdDsvJmd0Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+LSBT ZWN0aW9uIDYuMiwgc2hvdWxkbid0IHN1Y2ggYW4gT3B0aW9uIGJlIGRlZmluZWQgdG8gcmVkdWNl IHRoZSByaXNrIG9mIHVuZGVyLXNwZWNpZmllZCBvciBzdWJwYXIgc3BlY2lmaWNhdGlvbnMgb2Yg c3VjaCBpbnRlZ3JpdHkgbWVjaGFuaXNtcz8gT3IgYWxzbyBmcm9tIGFuIGludGVyb3AgcGVyc3Bl Y3RpdmU/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbHQ7SWxhbmdvJmd0OyBV c2luZyBhIEdlbmV2ZSBvcHRpb24gZm9yIHRoZSBwdXJwb3NlIG9mIGRhdGEgaW50ZWdyaXR5IGlz IG1vcmUgb2YgYW4gb3B0aW1pemF0aW9uLiBPdGhlcndpc2UgZGF0YSBpbnRlZ3JpdHkgY291bGQg YmUgcHJvdmlkZWQgYnkgdXNpbmcgZXhpc3RpbmcNCiBtZWNoYW5pc21zIGxpa2UgSVBzZWMgKGFz IHN0YXRlZCBpbiBzZWNvbmQgcGFyYWdyYXBoIG9mIDYuMikuIFdlIGluY2x1ZGVkIHRoZSBsYXN0 IHBhcmFncmFwaCB0byBzaG93IG90aGVyIHBvc3NpYmlsaXRpZXMuIFdlIGNvdWxkIHJlbW92ZSB0 aGlzIHBhcmFncmFwaCBpZiBpdCBtYXkgY2F1c2UgYW55IGNvbmZ1c2lvbi48L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0 OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5XZSB3b3VsZCBsaWtlIHRvIGtlZXAgdGhlIEdl bmV2ZSBiYXNlIHNwZWNpZmljYXRpb24gaW5kZXBlbmRlbnQgb2Ygb3B0aW9ucyBzcGVjaWZpY2F0 aW9ucywgb3B0aW9ucyBjb3VsZCBiZSBhIGRlZmluZWQgaW4gYSBmdXR1cmUgc3RhbmRhcmRzIGFj dGlvbi4gJm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jmx0Oy8mZ3Q7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+VGhhbmtzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+LS0gTWFnbnVzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyIGNsZWFyPSJhbGwiPg0K PGJyPg0KLS0gPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS0g TWFnbnVzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_C5A274B25007804B800CB5B289727E3583D6B5E7ORSMSX116amrcor_-- From nobody Fri Feb 22 18:39:30 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D16EF13102D; Fri, 22 Feb 2019 18:39:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 FvXKdbXfPt9b; Fri, 22 Feb 2019 18:39:28 -0800 (PST) Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB677130EAF; Fri, 22 Feb 2019 18:39:27 -0800 (PST) Received: by mail-lf1-x131.google.com with SMTP id v7so3161317lfd.2; Fri, 22 Feb 2019 18:39:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=cWIRIvc7EUhF+JhdtpIli0SvzJfw+P7Pem9j1dwBXiQ=; b=NUMU5KjZfI83cbsD44hRJO2QN/qHVA8cNpCFflMkKwx5citd3t7yeb5mYEs+3srWvI 3E4+cZOVaI3S9jerj72Gh4xmr2QeJ8ouNc6nHe9PAnlz2FOsnLV8ixQj7yUgtugPelyk QO8ed2yiy9SEXT3oYN8OguC/y2Y3DRc1w548ce/YsrrnQ2uYYs1eidvONDqoGMJjAj+8 HVhg+U0KbfrMjJioMwEqfYrgTPP4YMW7/eeEtPyUEmPoav7haTfIwON4TrY0UiZGNy7m 0W4jx7gweFXxqy8/ST0yX8nB7w/m6xSErkreQDf5kmZTy1hebchRntFd00kRl+JJ0/9l KkFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=cWIRIvc7EUhF+JhdtpIli0SvzJfw+P7Pem9j1dwBXiQ=; b=dYIuFT59BxhC2mG+/IJvR8rIviPW1O8wNtrAlwFu8BYewCogjxCrx3blyWwNurl55Z CmKIoeoDx0kFTImnYcQUkpikgl3kg1S0N+NZCdEJRDJxDB8iLy1473jPiHAG8XqKuBs9 C7B5a1Fqk1sD1QHnMgvXL8hnsvbF0oImtsNZaKMdIYtkdNOw18FRXKu/8HowOqNK6K17 kQKC8BaNQqRay0c07hYD5vneZ2Zy2NtalZbIZrJkx2Uhc86245VRQUIdol1OMt+jJ6Q0 XMudwUaa82HTKfIOjxanoFlBieW28GioUlcIRQfJtyB0xLEOqopbvnsz4p4UrZJWLtDi hllw== X-Gm-Message-State: AHQUAuanm0v4cznSn6xnK0ymeuk2zNz6gkggNZEBNn1hBazyHHh5pYXU 2QvDcv6fdrbMOIyzKoM/EpDOVdyvXC67RBcP0eL3+Q== X-Google-Smtp-Source: AHgI3IZfz6AK1xZrjZIuFmsR8GOhy4A5h7FE/Ja/1zHSsmhcosjaztEJNIElGUdGUFTXZ61WVBeVrvO9JJSmPR2Gpmg= X-Received: by 2002:ac2:43c3:: with SMTP id u3mr4199596lfl.114.1550889565510; Fri, 22 Feb 2019 18:39:25 -0800 (PST) MIME-Version: 1.0 From: Radia Perlman Date: Fri, 22 Feb 2019 18:39:14 -0800 Message-ID: To: secdir@ietf.org, The IESG , draft-ietf-payload-flexible-fec-scheme.all@ietf.org Content-Type: multipart/alternative; boundary="000000000000a363970582869d47" Archived-At: Subject: [secdir] Secdir review of draft-ietf-payload-flexible-fec-scheme-17 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Feb 2019 02:39:30 -0000 --000000000000a363970582869d47 Content-Type: text/plain; charset="UTF-8" I had previously reviewed version 16, and the authors have addressed all my comments in this version, so I have no further comments. As far as I'm concerned, this is ready. Radia --000000000000a363970582869d47 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I had previously reviewed version 16, and the authors have= addressed all my comments in this version, so I have no further comments.= =C2=A0 As far as I'm concerned, this is ready.

Radia=
--000000000000a363970582869d47-- From nobody Tue Feb 26 21:33:55 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E633C130E2E; Tue, 26 Feb 2019 21:33:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Fvz7owjMh_xy; Tue, 26 Feb 2019 21:33:43 -0800 (PST) Received: from mail-yw1-xc29.google.com (mail-yw1-xc29.google.com [IPv6:2607:f8b0:4864:20::c29]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22B8812D4EC; Tue, 26 Feb 2019 21:33:40 -0800 (PST) Received: by mail-yw1-xc29.google.com with SMTP id k14so7169880ywe.4; Tue, 26 Feb 2019 21:33:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=d1PRIgTVME4dLtjoPufWhRCZNNYWoTIfO7kQHxKjirQ=; b=AMi6JvyiVG8gn5bBriwD3I+4nOns8gLrXMGCWGQpjJxkufFtVg1vpQUr2jq9ub3Su3 QUefIHohbYBOjFYcJF3vYEJaS3xr7AofbyMPl6r4hijaCCtDGoh/ResoePoAMjmfdkIP ACXMnWXUVsgpcUYoG2j3B3czJo3dLmw2b9BtLdoI6Tl8QUSiO1rI/C3BMqDFEyZqQ504 8HntodNJCgBrwJ7Sr5C56ds1Oz8nukVMfNxVU/dn6VYJYWphRZm9HSXh9MZYoQn3Me5E T8r3ZoDZhbtZOB7y+85EFYvQMmlGdO1AM6WDjhC3dw0NVdRCqoWivoA0YlmeuwM36RHM p/jw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=d1PRIgTVME4dLtjoPufWhRCZNNYWoTIfO7kQHxKjirQ=; b=saUpNvJ+f1wtFV6UKGQGFoypx3Tp9cAigm0JOPl9HdFVj2oQB7tjnNCF38oHux7YMq 1LRonByAOr4JcTAvNU76klWWzhDPa/sVD8jqD8ZUk8j0/L1B99ukOdWDSyGzq/saCpkL fF87I16qOsRIXZKj/wEA03ngEEfyluSqxdGkvwCSsxNeARYmpwNK9miLJy6o6dCFvOsc YPKKrYC4uCF2Ni8k7qeWjg557wHGkJqCydtoQ1WzCbE5YCSnbd7icmshSDcLUKkbTWPq H4Y68p3fXAnW0pyRSLXr3HKg20PJ/GblsGXzawDCjDiNFNy/03+V5acjSLa331EiqQeo 2S6Q== X-Gm-Message-State: AHQUAuadSN8NDAXL/mmwpnddIqwyFK0a+GYn0lCA4BEBxiA+fGaUMYMb Gsnbk3QrB1QtVNW0Q4aoSaSC2rTQeEI1zfE7Cic7Is/w X-Google-Smtp-Source: AHgI3IaT6N1Hi07uqA+URfVilYQsqxskDxGqLALTLD1js/YsLsWTDH4IbHZOkveaEhB5LHOH03yXb33kG44aaR29Myo= X-Received: by 2002:a81:83c1:: with SMTP id t184mr21543529ywf.350.1551245619057; Tue, 26 Feb 2019 21:33:39 -0800 (PST) MIME-Version: 1.0 References: <154321083813.24275.4373340388504093292@ietfa.amsl.com> <03808BD3-11AA-4010-9B8D-7E33EC1FE39B@gmail.com> In-Reply-To: <03808BD3-11AA-4010-9B8D-7E33EC1FE39B@gmail.com> From: Christopher Wood Date: Tue, 26 Feb 2019 21:33:27 -0800 Message-ID: To: Paul Wouters Cc: secdir@ietf.org, draft-ietf-taps-transport-security.all@ietf.org, taps WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [secdir] [Taps] Secdir early review of draft-ietf-taps-transport-security-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2019 05:33:47 -0000 Hi Paul, We just posted a revision to this document incorporating updates based on your comments [1]. (Thanks again for your careful review!) If you have time to check the diffs, we would greatly appreciate any more feedback you may have. Best, Chris [1] https://datatracker.ietf.org/doc/draft-ietf-taps-transport-security/ On Mon, Dec 3, 2018 at 7:56 AM Christopher Wood wrote: > > (ietf to bcc to minimize spam) > > Hi Paul, > > Thanks for the feedback! Please see inline below. > > On 25 Nov 2018, at 21:40, Paul Wouters wrote: > > > Reviewer: Paul Wouters > > Review result: Has Issues > > > > Review of draft-ietf-taps-transport-security-04 > > > > I have reviewed this document as part of the security directorate's > > ongoing effort to review all IETF documents being processed by the > > IESG. These comments were written primarily for the benefit of the > > security area directors. Document editors and WG chairs should treat > > these comments just like any other last call comments. > > > > The summary of the review is HAS ISSUES. > > > > SecDir tools note: The secdir review link refers to an abstract > > containing the > > text: > > > > This draft summarizes a number of IETF transport security > > protocols a > > > > Note the word "IETF ... protocols". I don't actually see that in any > > of the > > revisions 00 to 04? Where did this comment/text come from? > > As Spencer noted, it likely originated from the early review request. > > > > > Reading the introduction, this draft's goal is: > > > > This document provides a survey of commonly used or notable network > > security protocols, with a focus on how they interact and integrate > > with applications and transport protocols. Its goal is to > > supplement > > efforts to define and catalog transport services [RFC8095] by > > describing the interfaces required to add security protocols. > > > > My first comment is regarding "commonly used or notable". Especially > > the latter one is odd. Why should the IETF reader be aware of > > "notable" but "not commonly used" protocols? And the reason I > > say this is because it lists CurveCP and MinimalT, which as far > > as I know are not deployed at all. While openvpn, which has a > > serious userbase, is not mentioned at all. And openconnect, an open > > specification compatible with Cisco Anyconnect, which even has a > > draft, > > draft-mavrogiannopoulos-openconnect-02, is not mentioned at all. In my > > opinion, the document would be improved by adding Openvpn and > > Openconnect, > > and removing CurveCP and MinimalT. > > > > My second comment is regarding IETF vs non-IETF protocols. Or even > > "specified in a draft or RFC" versus "there is an academic paper and > > some > > implementation and it's not clear what's what". The reason I am saying > > this is that for instance the protocol "specification" of WireGuard > > keeps > > changing. Their website lists a "whitepaper" that is changing over > > time > > with no changelog, and wild claims that I've spend time in the last > > few > > years to counter, upon which it gets rewritten with new misleading or > > wrong claims. > > > > It is kind of hard to do an IETF style summary of protocols when the > > "specification" includes phrases like: > > > > the tunnel simply works. Key exchanges, connections, > > disconnections, > > reconnections, discovery, and so forth happen behind the > > scenes > > transparently and reliably, and the administrator does not > > need to > > worry about these details. In other words, from the > > perspective of > > administration, the WireGuard interface appears to be > > stateless. > > > > This is not a white paper but a Public Relations document. > > > > None of the other discussed protocols in this document require > > administrators to "worry" about those "details" either. > > > > At the IETF, we recommend IETF protocols. If someone comes up with an > > alternative protocol that accomplishes the same as an existing one, we > > tend to tell people to use the existing IETF protocol instead. Or, we > > think their new protocol merits further standarization, and we ask > > them > > to produce either a ISE or IETF stream document that people can > > reference, > > comment, improve and discuss openly on its technical merits. > > > > It is also clear the white paper is not a good complete formal > > specification like we do at IETF. For example, if there is packetloss, > > the "specification" does not at all specify which of the parties (or > > both?) are responsible for retransmission. Can one spoofed packet lead > > a WireGuard endpoint to retransmit its response repeatedly? > > > > This further weakens their "stateless" claim. (and if it sounds like I > > am being harsh, I know I am. It is because previously, I had to > > counter > > false claims about IPsec speed, and IKE "being noisy" where as having > > looked again at "the whitepaper" (which keeps changing every time I > > look > > at it) it seems to now have a new hobby horse in the word "stateless". > > the > > openvpn tun0: is also "stateless", so is the VTI IPsec based interface > > vti0: > > > > Because of these reasons, I am a bit worried that an IETF document is > > making any claims about WireGuard features, as there is no way to know > > what the protocol will be like by the time this document is published, > > and this document cannot even point to a stable reference of te > > specification > > at the time of review. > > > > If this document wants to mention WireGuard as a protocol to take note > > of, > > I would like to see at least some text there urging WireGuard to write > > up > > (and version) their protocol in an IETF draft/RFC or other > > proper/formal > > specification. > > > > Now, having said all of this about WireGuard, I do agree with > > mentioning > > WireGuard in this document as it does have an actual userbase. Let's > > just urge and help them with their specification. (and If the > > author(s) > > of WireGuard are reading this, I am more than happy to help you with > > this) > > > > As for CurveCP and MinimalT, as far as I can see, these are just > > academic > > exercises with no serious deployment. While the IRTF might be > > discussing > > the these, I don't think an IETF document should reference these two > > proof of concept ideas until they have matured more. > > Protocol selection criteria was admittedly sort of ad-hoc in the > beginning. For starters, we included CurveCP and MinimalT because they > are unique in one way or another in contrast to the other protocols > considered. We then included WireGuard specifically because of its > (growing) popularity. And while it continues to grow, we are careful to > ensure the core feature set described remains stable. The informal > criteria we=E2=80=99ve established now is that any new protocol must brin= g > something new to the table. For example, we added protocols such as SRTP > because they had features not yet covered by other protocols. > > That said, we can certainly add OpenVPN and OpenConnect to round things > out. Though I see no issue with including CurveCP and MinimalT. As > stated in the introduction, this document is not restricted to IETF > protocols. Rather, it aims to survey any protocol that might influence > the API surface exposed. It is our opinion that the set of protocols > included meets this goal. If necessary, we can move the more esoteric > protocols to the appendix, though we should certainly not remove them > for lack of a specification. > > > > > Introduction / Abstract: > > > > Expand/explain TAPS on first use? > > > > Section 4.4.1.1: > > > > IKEv2 is a control protocol that runs on UDP port 500 > > > > Change to: > > > > IKEv2 is a control protocol that runs on UDP or TCP port 4500 and UDP > > port 500. > > > > Note you don't mention the one big drawback, that it cannot be run on > > any UDP > > port (although at least now we can run on any TCP port) which is an > > important > > problem when networks block IKE/IPsec on purpose compared to non-IETF > > VPN > > protocols. > > > > It then > > goes through a phase of authentication in which both peers > > present > > blobs signed by a shared secret or private key, after which > > another > > set of keys is derived, referred to as the "Child SA". These > > Child > > SA keys are used by ESP. > > > > This text makes it appear only the blob's are authenticated, but the > > entire > > IKE exchange is authenticated. Also sessions keys are not all that is > > a > > Child SA. So perhaps: > > > > IKE then > > performs a phase of authentication in which both peers present > > blobs signed by a shared secret or private key that authenticates > > the entire IKE exchange and the IKE identities. IKE then derives > > further sets of keys on demand, which together with traffic policies > > are referred to as the "Child SA". These Child SA keys are used by > > ESP. > > > > Each proposal may contain an encryption algorithm, an > > authentication > > algorithm > > > > This is a bit misleading with both the "may" and the lack of AEAD > > discussion? > > Perhaps: > > > > Each proposal contains an encryption with authentication algorithm or > > an AEAD > > algorithm, > > > > Any SA used by IKEv2 can be rekeyed upon expiration, > > > > Rekeying happens before expiration, not upon (which would imply > > trafficflow > > interuption) Similarly to how it is described for tcpcrypt in the > > document. So > > perhaps just change "upon" to "before" ? Or go in a little more detail > > with: > > > > Any SA used by IKE/IPsec can be rekeyed before expiration. It does so > > by > > negotiating a second SA, and once confirmed up and running, the old SA > > is > > deleted. This guarantees there is no slowdown or halt of traffic flow > > during > > rekeying. > > > > that allows a set of Security Associations to migrate over > > different > > addresses and interfaces > > > > I would say "different outer IP addresses and interfaces" > > > > Each SA is > > identified by a Security Parameter Index (SPI), which is > > marked on > > each encrypted ESP packet. > > > > I would avoid the word "mark" here, since to me that more presents > > internal > > state inside a kernel (eg iptables MARK) and not something that goes > > over the > > wire. So perhaps: > > > > The SA of an encrypted packet is identified by its Security Parameter > > Index > > (SPI) [which is send as part of the ESP header) > > These are all great suggestions! We will include them. > > > > > an anti-replay service (a form of partial sequence integrity) > > > > What is partial about this? Perhaps you meant to say ESP, like UDP, > > does not > > provide guaranteed delivery? Anyway, a "partial" security function > > reads odd :) > > This is quoted text from RFC4303. > > > > > and limited traffic flow confidentiality. > > > > What is "limited" about it? You can generate bogus traffic and pad > > traffic to > > any size (most common max mtu). What would you want in additional to > > make it > > not "limited" ? > > This text is also quoted from RFC4303, so we left it as is. Though I > think your suggestions point to what the authors are leading towards: > traffic analysis. > > > > > One thing I would add to the ESP section is mentioning it acts like > > UDP. It > > cannot be reset by a single TCP RST packet, and you don't have two > > layers of > > netflows doing retransmission. This feature of ESP (and some UDP based > > protocols in this document) is fairly important. > > > > Section 4.4.2.1: > > > > Mutual Authentication > > > > It is possible to do server-only or opportunistic/anonymous IKE as > > well. Maybe > > add "Usually" ? > > ACK =E2=80=94 will do. > > > > > 4.6.1: > > > > Tcpcrypt exposes a universally-unique connection-specific > > session ID > > to the application, suitable for application-level endpoint > > authentication either in-band or out-of-band. > > > > This kind of conflicts with the introduction that claims this is only > > an > > opportunistic encryption protocol? Maybe merge this part into the > > description > > text? > > Good observation. Yes, that is misleading. We=E2=80=99ll try to fix it. > > > > > 4.6.2: > > > > I might say here something about only passive attacker protection? > > That seems > > like an important difference compared to the other protocols. Or > > perhaps make > > this clear in the introduction text when mentioning opportunistic > > encryption. > > Yes, good point. We=E2=80=99ll fix that. > > > > > 4.7: > > > > WireGuard is a layer 3 protocol designed to complement or > > replace > > IPsec [WireGuard] for certain use cases. > > > > I am confused about how it "complements" IPsec? Perhaps you mean it is > > an > > "alternative" (and perhaps a non-IETF alternative) ? > > > > I think "replace" is very misleading, as IPsec has a vast number of > > different > > use cases compared to WireGuard's "static VPN configuration". > > Yes, we should drop =E2=80=9Cto complement or replace=E2=80=9D and say th= at it=E2=80=99s > an alternative. > > > > > WireGuard is designed to be entirely stateless, modulo the > > CryptoKey > > routing table, > > > > Wouldn't you be able to say the same about the ESP SPD/SAD table? I'm > > not sure > > how different the ESP/wireguard statelessness is on a scale or truly > > stateless > > to NFS > > > > You don't mention anything about port preconfiguartion and the "port > > knocking" > > thing? > > > > o Record replay prevention (Stateful, timestamp-based). > > > > I thought it was stateless module CryptoKey routing? :) > > > > You do not mention mobility or session resumption for WireGuard. Since > > it is > > all about static inner IP addresses over arbitrary outer addresses, it > > has > > mobility. And I guess the 1RTT means it has session resumption? > > > > Can you add a description of rekeying for WireGuard similar to > > IKEv2/ESP? I > > thought there was an issue there that during rekey, there is no > > continued data > > flow possible, so connections briefly slow down or halt when the > > channel is > > being rekeyed. > > I=E2=80=99m on the fence about this suggestion (and about keeping the > IKEv2/ESP rekeying text). Some of the feedback we=E2=80=99ve received thu= s far > is that the internal protocol details are irrelevant to the overall > story. Rekeying might fall in that category. We=E2=80=99ll play with it a= nd > see if we can find a happy medium. > > > > > Does WireGuard not offer padding or any other kind of Traffic > > Confidentiality > > options ? > > As far as I know, it does not. > > > > > 4.8: > > > > The MinimalT section seems to lack some information bullet points > > compared to > > the other sections? eg shouldn't it have things like: o Datagram > > Transport ? > > Indeed! This section needs some improvement. > > > > > Misc: > > > > Should tor be added to the list of protocols? > > We hadn=E2=80=99t considered it, though it might be worth including. If w= e can > find a new feature not yet exposed by the others, then yes, by our > criteria outlined above. > > > > > Why are MinimalT and CurveCP part of this list? Is there any actual > > deployment > > out there? I thought this document described actual transport security > > protocols people can pick. I don't see CurveCP as a real candidate for > > this. I > > don't know about MinimalT. > > As stated above, ease of use or popularity in practice is not the only > filter we used. I=E2=80=99m therefore inclined to keep these. > > > > > 5: > > > > I'm a little confused by the term Application in this section. Is this > > the > > enduser application or the userland part of the security protocol (eg > > IKE). I > > think you mean the application of the enduser? > > Yes, the application of the enduser. > > > > > > 5.1: > > > > Listed as mandatory feature is: > > > > o Public-key certificate based authentication. > > > > Yet you have mentioned that neither WireGuard or CurveCP can do > > authentication > > based on certificates? > > Indeed. This should read, =E2=80=9CPublic-key (raw or certificate) based > authentication.=E2=80=9D > > > > > 5.2: > > > > o Length-hiding padding (LHP): > > > > * Application dependency: Knowledge of desired padding > > policies. > > > > This is not (always?) true? For example ESP can do padding after IKE > > negotiated > > it, and do it based on MTU ? The (end user) application does not have > > to be > > aware of anything? > > That=E2=80=99s a fair point, though (in my view) padding without applicat= ion > input seems incomplete. Perhaps we can rephrase this to: > > =E2=80=9C(Optional) Application dependency: Knowledge of desired paddi= ng > policies. Some protocols, such as IKE, can negotiate > application-agnostic padding policies.=E2=80=9D > > > > > 5.3: > > > > The definition of "Mandatory" within this section is confusing. Maybe > > use > > another word like "Core" to indicate it is part of the core of the > > protocol and > > cannot be disabled? > > We used mandatory to be consistent with the section above. > > > > > NITS: > > > > spelling error: defailt > > Oops. Will fix! > > Thanks again for your careful review and feedback. We greatly appreciate > it. > > Best, > Chris et al. From nobody Wed Feb 27 07:29:51 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE64F130E71; Wed, 27 Feb 2019 07:29:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 QbpCOdfxGjK0; Wed, 27 Feb 2019 07:29:48 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47CAA128CE4; Wed, 27 Feb 2019 07:29:48 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 448fkK3LKkzCg1; Wed, 27 Feb 2019 16:29:45 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1551281385; bh=Qb+o0RP13xCIrNfXz4k5c4WRkjyZWnAEySpGwVNZ8jU=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=iHjG3WoY7BHNGNj/WItz7XvI9G8qTqMk8rXmbfsJI30B6FATOw3jetjXSmirDiss0 I8v4yu0SOK27QhReiapoW++UXm4Gkyx1avS+KRCuYVRK4EsWKSZCZBd9NtpRIgXPfg oRdY07PPuGFCqBA1pzb9+83oe4qdYtYqdh1VKznk= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id F_EQq6YB9K63; Wed, 27 Feb 2019 16:29:43 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 27 Feb 2019 16:29:43 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 362EFA7E0C; Wed, 27 Feb 2019 10:29:42 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 362EFA7E0C Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 2CB9940D358A; Wed, 27 Feb 2019 10:29:42 -0500 (EST) Date: Wed, 27 Feb 2019 10:29:42 -0500 (EST) From: Paul Wouters To: Christopher Wood cc: secdir , draft-ietf-taps-transport-security.all@ietf.org, taps WG In-Reply-To: Message-ID: References: <154321083813.24275.4373340388504093292@ietfa.amsl.com> <03808BD3-11AA-4010-9B8D-7E33EC1FE39B@gmail.com> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Subject: Re: [secdir] [Taps] Secdir early review of draft-ietf-taps-transport-security-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2019 15:29:51 -0000 On Tue, 26 Feb 2019, Christopher Wood wrote: > We just posted a revision to this document incorporating updates based > on your comments [1]. (Thanks again for your careful review!) If you > have time to check the diffs, we would greatly appreciate any more > feedback you may have. In general, the changes look good to me, although I still have reservations about some of the toy protocols mentioned which just gives them too much credibility. Thanks for adding openvpn. I see you did not add openconnect/anyconnect, and kept in curvecp/minimalt. Not my preference but if that's what the WG wants, I'm okay with it. Note that the latest openvpn version now uses AES-GCM per default, so perhaps you can excorsise blowfish from the document because Bruce said not to use it like over a decade ago. If you do mention blowfish, I think it should come with a big disclaimer to ensure people don't think IETF belives it's okay to use. And I don't think we need to point people to blowfish in the reference section. (see https://openvpn.net/community-downloads/) Just a few remaining questionts/comments left: >>> WireGuard is designed to be entirely stateless, modulo the >>> CryptoKey >>> routing table, >>> >>> Wouldn't you be able to say the same about the ESP SPD/SAD table? I'm >>> not sure >>> how different the ESP/wireguard statelessness is on a scale or truly >>> stateless >>> to NFS I'm still a bit concerned about the "designed to be entirely stateless". As I said before, that's more of a marketing gimmick than an actual technical property. Every VPN like protocol is stateless except for the state it needs (a rule database, counters, crypto keys). I would suggest removing this entire sentence: WireGuard is designed to be entirely stateless, modulo the CryptoKey routing table, which has size linear with the number of trusted peers. >>> You do not mention mobility or session resumption for WireGuard. Since >>> it is >>> all about static inner IP addresses over arbitrary outer addresses, it >>> has >>> mobility. And I guess the 1RTT means it has session resumption? You did not add these to the wireguard feature list. >>> 5.1: >>> >>> Listed as mandatory feature is: >>> >>> o Public-key certificate based authentication. >>> >>> Yet you have mentioned that neither WireGuard or CurveCP can do >>> authentication >>> based on certificates? >> >> Indeed. This should read, “Public-key (raw or certificate) based >> authentication.” It seems you decided to completely remove the mandatory requirement? What that on purpose or by accident? Paul From nobody Wed Feb 27 07:48:59 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1135131023; Wed, 27 Feb 2019 07:48:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Bw_ZfavhSN8F; Wed, 27 Feb 2019 07:48:37 -0800 (PST) Received: from mail-yw1-xc2e.google.com (mail-yw1-xc2e.google.com [IPv6:2607:f8b0:4864:20::c2e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F8DE130FE9; Wed, 27 Feb 2019 07:48:37 -0800 (PST) Received: by mail-yw1-xc2e.google.com with SMTP id k14so8436586ywe.4; Wed, 27 Feb 2019 07:48:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=0gm1MZ+OidvCx0F6JPOEA4VUppThM82emWOOoB3LTgw=; b=cW05JHvv6GY/UoCHXvU6SZDwoGCOmnbgnKoc0RNky5oeXzzSx1HX0+GQ7ghIJctpWp 5b4AnguREaansjdiGhe0QSqFGi+W30DyxcjrBydwIRoM38KQ4naBHztwrOnRIbJ8sEY7 uUxiA3a8T6nyJZR1o45DKgQwu2kQBXivzWtG8+s0msSWDEW076wuWIwzt6uAzyrdF/PE kZxf+L0akWewPs4HT82WGzX3okvgNjpQajtSsQm8aT92A66WeMS3CK228n6M20Z61ijo JVGIjWI2o6mpY7WGS0kDFbJZFHaN5ZS1cGeEhj8sQcivWYl0ocVVW2+tPaRJEOcJ12V8 Livg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=0gm1MZ+OidvCx0F6JPOEA4VUppThM82emWOOoB3LTgw=; b=jLxpkFBYeF4qQpaXqFN+cFB8mncsp5HQSa1klTeuCk96fodlwt/W1UlsBzblELkjCm b2UcdUqERN3Tm63F0jnCOpFodtwozql0hLBXa2IUCVRYzKaoFCfQr2i6t2NDB00+3thn XMWAuCdDqdxPgtg7vZoZQPlyOdW8GAHNXi8lIwJJ8s6VDY5SAPNMw2JYzqWk2RWD9+RQ 3nf5rxblVZdLyY90xbd8iER8d5U/xEzV/1scp56Zg5mvDlDePex4RMnuB3uvZ4QwlW6Y eC8UkVS1e7OERCYyqdk3MVvjig+VHDemhslEoPqHZKfjQiGeWD8dSm+epwWzBcWDCDTv hthw== X-Gm-Message-State: AHQUAuYawn5xttWB0pP93Fd3buGFHB67uOX387XRBO2pfeTJ1ihxON5f lkAUjXgi5gPnaI1Ox3aD/vfw+Vrqg7VGvqsvTrs= X-Google-Smtp-Source: AHgI3IY/7b8EpWev6dZJSMh+U7ZgNkEna/oNa/zZC4HxHD0iryUOZcl9AI3jQbbSul6e+1+iSZyD/w/xlxMC0K2jau4= X-Received: by 2002:a25:d64e:: with SMTP id n75mr2424522ybg.199.1551282516499; Wed, 27 Feb 2019 07:48:36 -0800 (PST) MIME-Version: 1.0 References: <154321083813.24275.4373340388504093292@ietfa.amsl.com> <03808BD3-11AA-4010-9B8D-7E33EC1FE39B@gmail.com> In-Reply-To: From: Christopher Wood Date: Wed, 27 Feb 2019 07:48:25 -0800 Message-ID: To: Paul Wouters Cc: secdir , draft-ietf-taps-transport-security.all@ietf.org, taps WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [secdir] [Taps] Secdir early review of draft-ietf-taps-transport-security-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2019 15:48:47 -0000 On Wed, Feb 27, 2019 at 7:29 AM Paul Wouters wrote: > > On Tue, 26 Feb 2019, Christopher Wood wrote: > > > We just posted a revision to this document incorporating updates based > > on your comments [1]. (Thanks again for your careful review!) If you > > have time to check the diffs, we would greatly appreciate any more > > feedback you may have. > > In general, the changes look good to me, although I still have > reservations about some of the toy protocols mentioned which just gives > them too much credibility. Thanks for adding openvpn. I see you did not > add openconnect/anyconnect, and kept in curvecp/minimalt. Not my > preference but if that's what the WG wants, I'm okay with it. > > Note that the latest openvpn version now uses AES-GCM per default, so > perhaps you can excorsise blowfish from the document because Bruce > said not to use it like over a decade ago. If you do mention blowfish, > I think it should come with a big disclaimer to ensure people don't > think IETF belives it's okay to use. And I don't think we need to > point people to blowfish in the reference section. > (see https://openvpn.net/community-downloads/) Good to know. Consider blowfish gone. > Just a few remaining questionts/comments left: > > >>> WireGuard is designed to be entirely stateless, modulo the > >>> CryptoKey > >>> routing table, > >>> > >>> Wouldn't you be able to say the same about the ESP SPD/SAD table? I'm > >>> not sure > >>> how different the ESP/wireguard statelessness is on a scale or truly > >>> stateless > >>> to NFS > > I'm still a bit concerned about the "designed to be entirely stateless". > As I said before, that's more of a marketing gimmick than an actual > technical property. Every VPN like protocol is stateless except for the > state it needs (a rule database, counters, crypto keys). I would suggest > removing this entire sentence: > > WireGuard is designed to be entirely stateless, modulo the CryptoKey > routing table, which has size linear with the number of trusted > peers. Good suggestion! I'll take it for the next update. > > >>> You do not mention mobility or session resumption for WireGuard. Sinc= e > >>> it is > >>> all about static inner IP addresses over arbitrary outer addresses, i= t > >>> has > >>> mobility. And I guess the 1RTT means it has session resumption? > > You did not add these to the wireguard feature list. Whoops -- missed this. I'll add mobility (they call it roaming), though there is no session resumption, if I understand correctly. I'll work with Jason afterwards to make sure this section is accurate. > > >>> 5.1: > >>> > >>> Listed as mandatory feature is: > >>> > >>> o Public-key certificate based authentication. > >>> > >>> Yet you have mentioned that neither WireGuard or CurveCP can do > >>> authentication > >>> based on certificates? > >> > >> Indeed. This should read, =E2=80=9CPublic-key (raw or certificate) bas= ed > >> authentication.=E2=80=9D > > It seems you decided to completely remove the mandatory requirement? > What that on purpose or by accident? Intentional! We felt that unilateral responder authentication was more fitting here. Thanks again, Chris From nobody Wed Feb 27 09:38:11 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 796CD1200ED; Wed, 27 Feb 2019 09:38:02 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Sean Turner To: Cc: ietf@ietf.org, nfsv4@ietf.org, draft-ietf-nfsv4-mv1-msns-update.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.92.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155128908237.14053.17188619727012241844@ietfa.amsl.com> Date: Wed, 27 Feb 2019 09:38:02 -0800 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-nfsv4-mv1-msns-update-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2019 17:38:03 -0000 Reviewer: Sean Turner Review result: Has Issues This draft updates NFSv4.1 to correct handling of the fs_locations and fs_locations_info attributes; NFSv4.1 weighs in at 617 pages and this draft weighs in a relatively spry 106; let’s say I was really, really hoping for some multi-page ASCII art, but also no pretty much all text. The draft does a good job of explaining what’s being replaced and why, but I have to say that I did not check all of section pointers. These instructions will really help when work on a fully revised NFS RFC gets going. Unfortunately for me, I do not have NFSv4.1 in my head so let’s just say that I did my best … Summary: This draft is probably worthy of some type of DISCUSS based on the following: 0) The big issue being addressed in the security considerations is the fact that RPSEC_GSS is must support not must use and the other mechanism referred to by RFC 5661 are: - AUTH_NONE - nada authentication - AUTH_SYS as described in Appendix A is known to be insecure due to the lack of a verifier to permit the credential to be validated. AUTH_SYS SHOULD NOT be used for services that permit clients to modify data. AUTH_SYS MUST NOT be specified as RECOMMENDED or REQUIRED for any Standards Track RPC service. - AUTH_DH as mentioned in Sections 8.2 and 13.4.2 is considered obsolete and insecure; see [RFC2695]. AUTH_DH SHOULD NOT be used for services that permit clients to modify data. AUTH_DH MUST NOT be specified as RECOMMENDED or REQUIRED for any Standards Track RPC service. So what do you do when RFC 5661 says: The fetching of attributes containing file system location information SHOULD be performed using RPCSEC_GSS with integrity protection, And, you don’t now change to MUST use RPSEC_GSS? Well I think at a minimum you should do some 2119 language: 0) s16 (after the bullets): 2119 this should: In light of the above, a server should present file system location entries that correspond to file systems on other servers using a host name. 1) s16 (2nd para after the bullets): 2199 this SHOULD NOT: As a result, the client should not use such unverified location entries as a basis for migration, even though RPCSEC_GSS might be available on the destination. 2) s16 (last bullet): 2119 this should: Where the use of the returned information cannot be avoided, it should be subject to filtering to eliminate the possibility that the client would treat an invalid address as if it were a NFSv4 server. And, I guess since AUTH_SYS is insecure can I suggest a friendly amendment to the following sentence: OLD:
 The use of requests issued without RPCSEC_GSS (i.e. using AUTH_SYS), while undesirable, may not be avoidable in all cases. NEW: The use of requests issued without RPCSEC_GSS (i.e. using the known to be insecure AUTH_SYS), while undesirable and Insecure, may not be avoidable in all cases. It’s probably also worth discussing whether s14.3 should drop support for includes id-sha1. These are the nits: 0) Update to use new 2119 paragraph: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 1) s3.1 (wordy): r/since the ports to be used for various types of connections might be required to be different/since the ports to be used for various types of connections might be different. 2) s3.1 (missing period): r/Two such addresses support the use of clientid ID trunking, as described in [RFC5661]/Two such addresses support the use of clientid ID trunking, as described in [RFC5661]. 3) s4.2 (missing word): r/which may accessed/which may be accessed 4) s4.3 (1st sentence): Not sure the 2119-RECOMMENDED is needed. 5) s4.3 (penultimate para): Seems like r/should/SHOULD. 6) s4.5: r/present , is/present, is 7) s4.5: Note sure you need the parenthetical in the following: a server may (but is not required to) 8) s4.5.4: r/In the event that server failures,/In the event that server fails, or r/In the event that server failures,/In the event of server failures, 9) s12.2.3: replace ietf.org with example.org (not supposed to use real domains even if it is “ours”). 10) s16 (3rd bullet): Why is requirement is caps? From nobody Wed Feb 27 14:44:25 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 060D61311A3 for ; Wed, 27 Feb 2019 14:44:24 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Tero Kivinen To: X-Test-IDTracker: no X-IETF-IDTracker: 6.92.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu Message-ID: <155130746401.14119.6179046412052527691.idtracker@ietfa.amsl.com> Date: Wed, 27 Feb 2019 14:44:24 -0800 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2019 22:44:24 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2019-03-07 Reviewer LC end Draft Nancy Cam-Winget 2019-02-15 draft-ietf-rtcweb-security-11 Russ Mundy R2019-01-31 draft-ietf-mpls-sfc-05 Tim Polk 2019-02-13 draft-ietf-sipcore-reason-q850-loc-06 Vincent Roca R2019-02-13 draft-ietf-perc-private-media-framework-09 David Waltermire 2019-02-15 draft-ietf-rtcweb-ip-handling-11 Samuel Weiler 2019-03-05 draft-faltstrom-unicode11-07 Taylor Yu 2019-02-15 draft-ietf-rtcweb-security-arch-18 For telechat 2019-04-11 Reviewer LC end Draft Stefan Santesson 2019-02-11 draft-ietf-extra-imap-fetch-preview-03 Last calls: Reviewer LC end Draft Derek Atkins 2019-03-03 draft-ietf-netmod-module-tags-05 Shaun Cooley 2019-03-13 draft-ietf-dots-data-channel-27 Roman Danyliw 2019-03-07 draft-ietf-spring-segment-routing-mpls-18 Daniel Gillmor 2018-03-19 draft-gutmann-scep-13 Leif Johansson 2018-12-24 draft-ietf-6lo-nfc-13 Russ Mundy 2017-09-14 draft-spinosa-urn-lex-13 Stefan Santesson R2018-11-20 draft-wilde-service-link-rel-10 Takeshi Takahashi R2018-08-31 draft-ietf-lisp-rfc6833bis-24 Brian Weis 2019-02-27 draft-ietf-dnsop-algorithm-update-06 Klaas Wierenga 2019-02-26 draft-ietf-mpls-sr-over-ip-02 Taylor Yu 2018-11-28 draft-ietf-alto-cost-calendar-11 Early review requests: Reviewer Due Draft Alan DeKok 2019-03-18 draft-cel-nfsv4-rpc-tls-02 Daniel Franke 2018-01-31 draft-ietf-intarea-provisioning-domains-00 Next in the reviewer rotation: Linda Dunbar Donald Eastlake Shawn Emery Stephen Farrell Daniel Franke Daniel Gillmor Tobias Gondrom Ólafur Guðmundsson Phillip Hallam-Baker Steve Hanna From nobody Thu Feb 28 07:44:10 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6876130EC5; Thu, 28 Feb 2019 07:44:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 17ZmGblNJzlm; Thu, 28 Feb 2019 07:44:01 -0800 (PST) Received: from mail-ua1-x934.google.com (mail-ua1-x934.google.com [IPv6:2607:f8b0:4864:20::934]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BEF7130E27; Thu, 28 Feb 2019 07:44:01 -0800 (PST) Received: by mail-ua1-x934.google.com with SMTP id d4so8172515uap.5; Thu, 28 Feb 2019 07:44:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Uu/B/q2aEwr0Vy1lnT3nB3gfU8wevGGVCWKY3Z/pmxk=; b=nNa3YMNm/XlkeJ+94oBgRN/di2RrT4l4Vt7kp2zMnPjzx+Ya1EBC3iNLNIf2tQC20n H0sRFoeGguCwDJrdbO2Qaz1hE7Ndhh1EJ6PcveZhy+xQzRarbYJij4hVEneWffyILfye MGUcMIvh9Y+1GXueghtJERNaQBoBjEePzZsmz29Xq6UQey9PZ9EpXg2LcqCMVhLfm0wy KbnngUwqqlcey3EKjj7MFZQ+I3JCy7Rh/UmsocnDrXzBjoxHsVNI0VOhtLBWNA74BYPA n/TAD45IX+cNg3vks2wdbFfF4VnMJxJWE45W4v1POn7m8gLQlLJ7MVgBCBPPLWoyLvUy QnWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Uu/B/q2aEwr0Vy1lnT3nB3gfU8wevGGVCWKY3Z/pmxk=; b=GnH9WM7mKFnIiKgfj4gEuXPnDYQVkuPA/qsTcAtFJ8D+hl0QxWJjCzX/bRgN+nV3Jf SJZQk/DxVt+vo/YGFF7/3JGa2W3+vhg88bj66ND+RbENObHNv4ub2bj7Bw2vhAOYkhbi K1JI3ndVWp5eLOicxL4MKH7A/f2r77588EUkDBY5fP0skCQ0IJ7eJdt6FMTJLaqkbjr+ v5RYslcJu/98URLVrh7QfjIuBXh/iivxpBvQ/P2W5GV5yCiT3L5Dsk0Pz4svbRCxZWwJ B1iZ+bu5tm6CuO1JzDzr9ddruVZCynoWxXlr7irncB/ER3O5zq7Z4aMeZgxp7q5Z7SkJ 1hDA== X-Gm-Message-State: AHQUAuYrsFGEIv2TAKsJZHmqrRfFWr+5JLpsCU2cImkYojXvTKVDXrlh 8tbPgcdTWP8OsQtmS7q6sRlyFj6wcWTL2v6Ssun2PQHcs30= X-Google-Smtp-Source: AHgI3IY840oUo+bJcP64rwSC4XrQmRFyXaztMnNkgza/JB4Il6ZvZKZK+b2FXnZWeCAGefQpyGXRiqtXQaTAB6q+cB4= X-Received: by 2002:a67:db89:: with SMTP id f9mr5169374vsk.143.1551368640143; Thu, 28 Feb 2019 07:44:00 -0800 (PST) MIME-Version: 1.0 References: <155044786665.4047.16182077722084116649@ietfa.amsl.com> <011a01d4c71e$16d9dd30$448d9790$@olddog.co.uk> In-Reply-To: <011a01d4c71e$16d9dd30$448d9790$@olddog.co.uk> From: "Andrew G. Malis" Date: Thu, 28 Feb 2019 10:43:48 -0500 Message-ID: To: Adrian Farrel Cc: Paul Wouters , secdir@ietf.org, mpls , draft-ietf-mpls-sfc-encapsulation.all@ietf.org Content-Type: multipart/alternative; boundary="000000000000b626b60582f628b1" Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-mpls-sfc-encapsulation-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2019 15:44:04 -0000 --000000000000b626b60582f628b1 Content-Type: text/plain; charset="UTF-8" Paul, Thanks for your review! Adrian, I don't think I agree with your statement that the MPLS forwarding plane doesn't offer any security features. As I discuss in the last paragraph in the security considerations in the draft, it's resistant to some classes of attacks such as injecting unexpected packets unless the attacker was an insider or had specific inside knowledge, such as valid SFF labels that would be accepted by a receiving node. But then, it's difficult to defend against any sort of attack on a router by an insider, starting with having access to the physical box and the CLI. While there are no specific NSH security mechanisms, I don't think this draft is the place to have that discussion, as it's an MPLS WG draft. The draft does say that this encapsulation is no more or less secure than carrying the NSH in any other encapsulation. It's up to the SFC WG to figure out NSH security elsewhere. Cheers, Andy On Sun, Feb 17, 2019 at 7:08 PM Adrian Farrel wrote: > Hi Paul, > > Should we make the observation that, since the MPLS forwarding plane does > not offer any security features, if security is required it must be > provided by the SFC layer using some mechanisms inherent in the NSH. We > could/should probably also observe that, as yet, no NSH security mechanisms > have been defined. > > Cheers, > Adrian > > -----Original Message----- > From: ietf On Behalf Of Paul Wouters > Sent: 17 February 2019 23:58 > To: secdir@ietf.org > Cc: mpls@ietf.org; draft-ietf-mpls-sfc-encapsulation.all@ietf.org; > ietf@ietf.org > Subject: Secdir last call review of draft-ietf-mpls-sfc-encapsulation-02 > > Reviewer: Paul Wouters > Review result: Ready > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > The summary of the review is Ready > > While I'm not familiar with the Service Function Chaining (SFC) > architecture > and the Network Service Header (NSH), the Security Considerations in this > document seem to be correct in pointing out that: > > This document simply > defines one additional transport encapsulation. The NSH was > specially constructed to be agnostic to its transport encapsulation. > As as result, in general this additional encapsulation is no more or > less secure than carrying the NSH in any other encapsulation. > > > --000000000000b626b60582f628b1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Paul,

Thanks for your review!

Adrian,

I don't think I agree = with your statement that the MPLS forwarding plane doesn't offer any se= curity features. As I discuss in the last paragraph in the security conside= rations in the draft, it's resistant to some classes of attacks such as= injecting unexpected packets unless the attacker was an insider or had spe= cific inside knowledge, such as valid SFF labels that would be accepted by = a receiving node. But then, it's difficult to defend against any sort o= f attack on a router by an insider, starting with having access to the phys= ical box and the CLI.

While there are no specific = NSH security=C2=A0mechanisms, I don't think this draft is the place to = have that discussion, as it's an MPLS WG draft. The draft does say that= this=C2=A0encapsulation=C2=A0is no more or= less secure than carrying the NSH in any other=C2=A0encapsulation. It's up to the SFC WG to figure out NSH securi= ty elsewhere.

Cheers,
Andy


On Sun, Feb 17, 2019 at 7:08 PM Adrian Farrel <adrian@olddog.co.uk> wrote:
<= /div>
Hi Paul,

Should we make the observation that, since the MPLS forwarding plane does n= ot offer any security features, if security is required it must be provided= by the SFC layer using some mechanisms inherent in the NSH. We could/shoul= d probably also observe that, as yet, no NSH security mechanisms have been = defined.

Cheers,
Adrian

-----Original Message-----
From: ietf <i= etf-bounces@ietf.org> On Behalf Of Paul Wouters
Sent: 17 February 2019 23:58
To: secdir@ietf.org
Cc: mpls@ietf.org; <= a href=3D"mailto:draft-ietf-mpls-sfc-encapsulation.all@ietf.org" target=3D"= _blank">draft-ietf-mpls-sfc-encapsulation.all@ietf.org; ietf@ietf.org
Subject: Secdir last call review of draft-ietf-mpls-sfc-encapsulation-02
Reviewer: Paul Wouters
Review result: Ready

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.=C2=A0 These comments were written primarily for the benefit of the security area directors.=C2=A0 Document editors and WG chairs should treat<= br> these comments just like any other last call comments.

The summary of the review is Ready

While I'm not familiar with the Service Function Chaining (SFC) archite= cture
and the Network Service Header (NSH), the Security Considerations in this document seem to be correct in pointing out that:

=C2=A0 This document simply
=C2=A0 =C2=A0defines one additional transport encapsulation.=C2=A0 The NSH = was
=C2=A0 =C2=A0specially constructed to be agnostic to its transport encapsul= ation.
=C2=A0 =C2=A0As as result, in general this additional encapsulation is no m= ore or
=C2=A0 =C2=A0less secure than carrying the NSH in any other encapsulation.<= br>

--000000000000b626b60582f628b1-- From nobody Thu Feb 28 14:02:53 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 31F96128AFB; Thu, 28 Feb 2019 14:02:51 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Brian Weis To: Cc: draft-ietf-dnsop-algorithm-update.all@ietf.org, dnsop@ietf.org, iesg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.92.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155139137116.28679.2329019149187176312@ietfa.amsl.com> Date: Thu, 28 Feb 2019 14:02:51 -0800 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-dnsop-algorithm-update-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2019 22:02:51 -0000 Reviewer: Brian Weis Review result: Ready I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document specifies updated DNSSEC algorithm recommendations. It includes updates on DNSKEY, DS and CDS algorithms. The recommendations are similar to the methodology defined for IPSec algorithm recommendations, which have been useful to implementors and users. The actual algorithm recommendations (MUST, RECOMMENDED, NOT RECOMMENDED, MAY, MUST NOT) are in line with current general algorithm guidance, and match the goals set forth in the document. I make no further comment on them as the details of the recommendations have likely to have been finely honed through debate within the working group. I believe the document is ready to publish. From nobody Thu Feb 28 15:19:53 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6886613106F; Thu, 28 Feb 2019 15:19:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bluepopcorn.net 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 9QOy6ot-vb3Z; Thu, 28 Feb 2019 15:19:38 -0800 (PST) Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6C2D130E96; Thu, 28 Feb 2019 15:19:37 -0800 (PST) Received: from steel.local ([IPv6:2601:647:4300:2290:214e:1bd0:ac50:a2ec]) (authenticated bits=0) by v2.bluepopcorn.net (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id x1SNJY2D028256 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 28 Feb 2019 15:19:35 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1551395975; bh=uf/dkvqjuRv6zda3OKwv1BXTevndr8O24+iH6CsMZJ8=; h=From:Subject:To:Cc:References:Date:In-Reply-To; b=mcPiw22TCTu6ld8mw2PfzS0wTUbaa8ALW+dCppYMAZltBPC9zQGwl6zZuVL7MRZe0 ZnHSJlKU4dOQNPzEGmLkHe7d+I6asAJy9ywQjx6LT1nslC4EXw6WWwYLxRsl6/2H3l 6uaWWsTaIMTHABNihOYL3eArgoykbwmcDH8rhHKw= From: Jim Fenton To: Yaron Sheffer , secdir@ietf.org Cc: uta@ietf.org, ietf@ietf.org, draft-ietf-uta-smtp-require-tls.all@ietf.org References: <155086101448.5343.14630075460582755101@ietfa.amsl.com> Openpgp: preference=signencrypt Autocrypt: addr=fenton@bluepopcorn.net; prefer-encrypt=mutual; keydata= mQINBFJNz0MBEADME6UoNSsTvSDJOdzL4yWfH4HTTOOZZPUcM/at38j4joeBb2PdatlwCBtk 9ZjupxFK+Qh5NZC19Oa6CHo0vlqw7V1hx1MUhmSPbzKRcNFhJu0KcQdniI8qmsqoG50IELXN BPI5OEZ3chYHpoXXi2+VCkjXJyeoqRNwNdv6QPGg6O1FMbB+AcIZj3x5U18LnJnXv1i+1vBq CxbMP43VmryPf8BLufcEciXpMEHydHbrEBZb/r7SBkUhdQXjxRNcWOLeYvOVUOOrr1c+jvqm DEbTWUJVRnUro/WpZQBffFnymR0jjkdAa8eOVl/nF2oMLbaBsOMvxCRSSEcGhuqwbEappNVT 1nuBTbkJT/GGcXxc+lEx9uNj86oYC4384VZJMTd1BRI4qPXImNZCIdmpKegK743B6xxN6Qh1 Tg167pn9429JENQE/AFIVX5B/gpsg7Aq+3rmz9H6GbfovPvFV3TBTgsHCHAMC8XU+S4fhcqN PN0lbUeyb7g6wxaE+dYqC7TExx7G3prw4v66y0qS7ow/Cfw8XXOEkaFQ4XwP7nvfILT+9CcU yS8I40vlDFU9Wnt56CbGz0ZVQgHnwyPXL+S9kCcIwRLFx1M79s6T6qwX1TXadfpbi1uIw7XG TiPDT8Pk6i2y22oSSROyYD4D+wOhVkkvO0S8iZ3+LhAYUx86nwARAQABtCNKaW0gRmVudG9u IDxmZW50b25AYmx1ZXBvcGNvcm4ubmV0PokCVQQTAQIAPwIbAwYLCQgHAwIGFQgCCQoLBBYC AwECHgECF4AWIQS1nUkJe2fEXbvBaacbJaiwFdCfvgUCW4RXswUJCxkNcAAKCRAbJaiwFdCf vjdyD/wNUBktyTqGVI5JGE8TJX6+6bmq5HHJ/I+CgGNtyvjriNZdxZJ86L5Z7MIidBeUOXvl /DZK+1zvS/hq8oMe7rPMbSepHHdhMyVTBuWnUG3n48dYOMqQjttBxisauC9GXrejhDJeGP+y WDLRdkMs1h5M48MKpEHf69pvkb+CCewbJeJH3kpPc5Iv9lJEOM/SrGlR72RUsMHeBcc3ykPR CeW0MpXGKAo5QCRw51uvuy7jZdlxOrLMMvMSyqCVanaW2Iz8mXQKufahkDfjff/eBUgXSfxS L1H2ZUN8XeyLttn6iei0Jqs1aSTmU1y0XxMM5k0rgA+3PoZrkgYTSvVBQMhE+sIyeoiB9oat 5h7M7nZBXc4LQTEwMFCamE4GIaSkpLFwBBwZwPa487XKnPbGV6zr7sYEzDaCvkQGJdfw6NqA 5IxLgmAoCAWnp3h26OtUJ0lmgpRy/Vy4yinbVAvkBq1CB1gRlNDYn0Ton06Bz0ltSpBTWTzj m6zvnA2JLzyFrTc30PR22WD/m18/qgua7YCiP1xu88AsnY5HPgxDj88PDiiyuFftYHhSY0Dy nV+iz+NEPal/LaklqVmA1+l8qj/SPAdycbD/s2X6MHjPBamdBmzytuEZnv+LImPTkdswExLD AORVDaH2SYuznhFs7xZ/t1rB5Yo1l5eDGdTQ6KLsDLkCDQRSTc9DARAAwZaXYs3OzGlpqvSH 3HR9GjSzIeP0EmsBCjpfIdZbQBwQ3ZREiMGInNxV+xkdjLDg0ctrWzUCUe3plWe5NJkpjqm+ KMc7GKhyeWJ5MZRtVrh0VpFTqi8UwYPWumAYqE1y/U1me/zHpfG9EDwdSYqMkPF76Fy5W+vh ZP2ILKaY8qWSLyH8TPl5mFGBypfT8Q6UuzlRs2aTbsTtBX/qwH7gztMRJSjQtYo20AqCgBBH IA/0xV5qDH7CVYyKyPQ4tJLQ8/xyTysUS5fewrj8lZo/G9SaNtC3CEvrJYwyA0nvYB6+hJPM qMP/tyRXM/9XY3qO4Vxuc+m5fYbTZa5GYAZNNuB5dvqI1U0sFTWBEbpAeabqCQ40ZnFSj+t1 tBuwfj4ey/oJ78WRyg5+VTvPKRRubOmZcnzj5yfTS3VGxAZb4Nsj1S2f3KLP0Z+Cv4dt893I 2JWTChw7jA1omF0QTQaBq140n084PFndBHudrZ3cz+APC89iie2HQ4jGQldXZXnGySHnHlA+ WUyZ9wgOplW9F4Q/Lps1bnuh5VttPVpNfjX8hiV48al+b+ut4nfzXAripIRWF3TL72/6JqgE KNhRKyRn0S6BidieSyHWzqJR3Roi/YNTvyXyLh6i6jtByb3FbnhYf/9olobDpj0E+kTemLrw owre85gwupSphqlzVSUAEQEAAYkCPAQYAQIAJgIbDBYhBLWdSQl7Z8Rdu8FppxslqLAV0J++ BQJbhFZUBQkLF7qRAAoJEBslqLAV0J++wvgP/jPjfjH3zEGYhdv89B0vFsRIBDDZzJuMxZZL EW/FyqKqswTHt6HD2ScuiGNEsNWebKEZbj2+Y673KqWnBGMFuJovAzlLeNNxQToJq03pzm/9 4A0ePYk9xzrMgtW+DEUemWElvMbSwZYid8Zj4lAx+U/X6Dh7HPSTx8DO4BKRA4cLrASOaUuS /w8/2eTXNEJssqc8Shwq6bNO5cPXrjb/qJgbb/MOLp0Nn1vNIPjoi/88910pyOV9chYJJFRX zOofGwaRjvcO55X57lveBrNEgH453EHa7QAHL4wD2dbCd445YOPkn0mBNJe3Un5JTsi6IQaK NHUMfwTWrVWN8RapFaPv6YXVBEvpA13G88TFkR5UHlz6YEUMATmgJQpmTFRkPYT0DTEbL4/O ywFgqMzmY1ojKV/Z6iWCAHqVnyFr6NtTFmT/qkOtb933YWJZW6Pg/Us2rZHro7uvQ/bf7Uxb vkn4lX+VneDBjsk3RPnHO/6k8lY2xQ343O7QOedSkM6rJpB9IbgXvHJNJfAWV+L89ElZeKJr VNaQqAw/1uXM7s8MVc+qwoT+DN0jsdqkBcuBxnbYeyM/8X6wcZHopV74r7SAbH4TrtjcBft5 nyM0UroVaEXvJxLzL3kQTsHIiDtGVuYwDTHzVl9591fuyEe0cYZVP2WckXcuM7EUn4CPBUYJ Message-ID: <1ff22763-bf46-2b89-aa09-ca55e979975f@bluepopcorn.net> Date: Thu, 28 Feb 2019 15:19:28 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.5.0 MIME-Version: 1.0 In-Reply-To: <155086101448.5343.14630075460582755101@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Archived-At: Subject: Re: [secdir] [Uta] Secdir last call review of draft-ietf-uta-smtp-require-tls-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2019 23:19:40 -0000 On 2/22/19 10:43 AM, Yaron Sheffer wrote: > Reviewer: Yaron Sheffer > Review result: Has Nits > > [Apologies for the late review.] [And for the late response.] > > * Intro: To avoid confusion, please mention the header parameter "No" t= o > clarify why the header is named RequireTLS when its semantics is the ex= act > opposite, "prioritize delivery over ability to negotiate TLS"? The same= > confusion already arises in the abstract. OK. > * Sec. 2: it seems to be implied that > when REQUIRETLS is used, STARTTLS MUST also be sent. Is this the case? = If so, > please mention it (it's obvious to you but not to a first time reader).= STARTTLS is normally needed, but wouldn't be if implicit TLS (i.e., on submission port 465) is used. > * I > would have expected a parameter to be associated with REQUIRETLS to ind= icate > whether DANE is required throughout the forwarding path, or MTA-STS, or= either > one will do. Although RFC 8461 takes care to not use the "opportunistic= " word, > it is in fact opportunistic to some degree (because an attacker can blo= ck the > initial policy lookup with DNS) and so has different security propertie= s than > DANE. I am sure you've already beaten this horse to death, but if you h= ave not, > I think this is a real issue. The thing is, if ever we have widespread > deployment of DANE (which I do NOT expect), this mechanism will not be = as > secure as it could have been.=20 In earlier drafts, the REQUIRETLS SMTP parameter had options that allowed the sender to specify whether DANE or certificate chain verification of certificates (or either) should be used. That isn't exactly the same as what you're suggesting, but it's close. The WG consensus was to eliminate the option because it was considered to be unnecessarily complex. > * Sec. 2 security requirements: the session must > employ TLS: does this include pre-negotiation of TLS before starting SM= TP, or > only session upgrade with STARTTLS? This is common in Submission, I'm n= ot sure > about MTA-to-MTA use. Pre-negotiation of TLS or STARTTLS can be used with submission, and REQUIRETLS can be specified at submission. There is no standard port for MTA-to-MTA use. > * RequireTLS header field: I believe that the REQUIRETLS > parameter MUST NOT be used when the header field is there, why not ment= ion it? We have gotten other comments that this case should throw an error. We will probably be doing this. > * If we define a case where MTA-STS policy is to be ignored (when using= > RequireTLS: No), shouldn't this document be marked as Updates RFC 8461?= Alexey is researching this. > * The > word "no" appears twice in Sec. 3, capitalized as "NO" or "No". Are par= ameters > case insensitive?=20 Yes. > * The case of REQUIRETLS+RequireTLS on receipt is > interesting, and the MAY requirement (Sec. 4.1) makes it non-determinis= tic. Why > don't we simply disallow it and reject the message?=20 See above; this will probably be disallowed and cause it to throw an erro= r. > * The textual name is > mentioned twice, once with and once without a space.=20 Will be corrected. > * 8.2 (active attacks): > this solution is still vulnerable to the DNS blocking attack associated= with > MTA-STS (RFC 8461, Sec. 10.2), and this should be mentioned here. If the REQUIRETLS SMTP option is used, either MTA-STS or DNSSEC confirmation of the MX host is required. If DNS is blocked (and DNSSEC is not used), transmission of messages requiring TLS fail. So I would consider REQUIRETLS to be less vulnerable to that attack than MTA-STS by itself, except possibly as a denial-of-service attack on REQUIRETLS-tagged messages. There are much better ways to DOS a mail server than this. Does it warrant mentioning? Thanks for your review. -Jim From nobody Thu Feb 28 16:21:28 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 60978130FE5; Thu, 28 Feb 2019 16:21:14 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Linda Dunbar To: Cc: spring@ietf.org, draft-ietf-spring-segment-routing-mpls.all@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.92.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155139967435.28679.14505997897302676815@ietfa.amsl.com> Date: Thu, 28 Feb 2019 16:21:14 -0800 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-spring-segment-routing-mpls-18 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2019 00:21:15 -0000 Reviewer: Linda Dunbar Review result: Ready Reviewer: Linda Dunbar Review result: Ready I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The document provides the detailed explanation of SR-MPLS processing in addition to RFC 8402. Since SR-MPLS are in the trusted domain, it is assumed that there is no malicious attacks to the nodes for the data plane and control plane. RFC8402 already has the good description on the Security Consideration for both SR-MPLS & SRv6. Linda Dunbar From nobody Thu Feb 28 17:31:06 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BEC6131101; Thu, 28 Feb 2019 17:30:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 7L9TzZyHsz7n; Thu, 28 Feb 2019 17:30:47 -0800 (PST) Received: from mail-ot1-x32e.google.com (mail-ot1-x32e.google.com [IPv6:2607:f8b0:4864:20::32e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 189A3131100; Thu, 28 Feb 2019 17:30:47 -0800 (PST) Received: by mail-ot1-x32e.google.com with SMTP id q24so19623031otk.0; Thu, 28 Feb 2019 17:30:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=B9h4E7SOLQapPZ4Fw/KWTvac6weQEUiix3WOB6hgAlU=; b=oPveZYe1aqkV9DWsg1bK3QJOFqvUJ6bbWaT9KIFY6kDxC7Gas+Ms1PnRqpXx3/c8rM Ckw+uyFACG3GZ7nIdeH/FFO1EydpnpJCcc3ToB7t0xL4nHHQ46ZeSpBqmwTnHgwR6DB2 NO/NCpHGsu7Z+YLVruMVABX9nKXUYFGhRUz7saPHVB0WQmU0fxyIbDXD6MqOed8i7AUR hrzcjpsOVW+JUPupikDvVR/Cqjg+mOgmosNFtz2XhrfDahtfBMjtDBaeqqREVS4MuQjK zB2GOcgUJke9r8zk9tuaU5hTk2B4BWrJvf3Dl5lBFkMpp7y8bKvNgY8KWuj1H9y56C9B vMPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=B9h4E7SOLQapPZ4Fw/KWTvac6weQEUiix3WOB6hgAlU=; b=A9RpkE/pjo4g2nXTt+adU+4CuricsswCK9da1bpb8n45sXMQAOV9QQnWdW1ExTznIC jdP/7JqvSVp40NXr2gy0e8w4AvVExfnE+VPvLopA5leTv+bZm2nmcLIe0LGSoDw5b2br Cr9hH8odGJKN+nE5dRwuu68Hv+U89v6XiaxA9JIRRIB5eZbFRzQm7XsgRYDZbIjEJkBa 9Qj2H5GjYWHi/msgDSUfdcUh7I6VGW40BeC+UhlOs0Kmw9eWaarBXIFmg70pl4QKMS3M siLNkk1lAScPg81Of4WPQKZKlBGTl1uJMWyB23v2uP5lD1rDsUUj0JWwUI4uP3k5p/eQ ctjw== X-Gm-Message-State: APjAAAVAqQRor2/eGozizkDBCykhEheGzsr6Hf4N2XbFWV8q5K/mYxsQ eEmoY/Gr/KsQWZQFJMhXeXbX9SFXI7Fi9nMo60k= X-Google-Smtp-Source: APXvYqy2WNBjlZ3EB8OyB0ZLozWU19QTNtgK1DapGnu45Wdla6WWkALnj32mBWI5KlRBf59ODx9CErZAYbsITk3Pwh0= X-Received: by 2002:a05:6830:1193:: with SMTP id u19mr1737581otq.221.1551403846034; Thu, 28 Feb 2019 17:30:46 -0800 (PST) MIME-Version: 1.0 References: <155128908237.14053.17188619727012241844@ietfa.amsl.com> In-Reply-To: <155128908237.14053.17188619727012241844@ietfa.amsl.com> From: David Noveck Date: Thu, 28 Feb 2019 20:30:35 -0500 Message-ID: To: Sean Turner Cc: secdir@ietf.org, ietf@ietf.org, NFSv4 , draft-ietf-nfsv4-mv1-msns-update.all@ietf.org Content-Type: multipart/alternative; boundary="000000000000256c000582fe5b8d" Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-nfsv4-mv1-msns-update-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2019 01:30:50 -0000 --000000000000256c000582fe5b8d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > These > instructions will really help when work on a fully revised NFS RFC gets > going. That's the intention. The working group is now discussing the possibility of an rfc5661bis that would use those instructions. Note that the current document would be the source of a large set of the changes but there are also others: The internationalization section needs to be updated as it was in RFC7530. Section 12 needs to be updated to reflect the work done by RFC8434. Also, there are a lot of erratta that would need to be applied. > 0) The big issue being addressed in the security considerations is the fact > that RPSEC_GSS is must support not must use That reflects choices made for RFC3530 and carried over until now. This has resulted in a situation in which AUTH_SYS is very commonly used despite its obvious security weaknesses. > So what do you do when RFC 5661 says: > The fetching of attributes containing file system location > information SHOULD be performed using RPCSEC_GSS with integrity > protection, Not much, since there is not much I can do about that. > And, you don=E2=80=99t now change to MUST use RPSEC_GSS? No I don't. Currently use of AUTH_SYS is allowed and the working group has not made any decision to change that. > Well I think at a minimum you should do some 2119 language: OK, but note that this is a widely-deployed protocol and we are not in a position to invalidate deployment choices made in line with RFC5661, even if we think they were ill-advised. > 0) s16 (after the bullets): 2119 this should: If you are suggesting changing "should" to "SHOULD" in this parapgraph, I'm OK with making that change in -05, although I will raise the issue with the working group to check about existing implemtations. > 1) s16 (2nd para after the bullets): 2199 this SHOULD NOT: I intend to shift this to "SHOULD NOT" in -05. > 2) s16 (last bullet): 2119 this should: Given that this bullet appears in a summary, I think the "should" is misleading. Converting it to "SHOULD" would lead to recommemmending filtering without specifying the filtering to be done. What I propose to do in -05 is replace "should be subect to filtering" by "is made subject to filtering as described above". > The use of requests issued without RPCSEC_GSS (i.e. using > the known to be insecure AUTH_SYS), while undesirable and > Insecure, may not be avoidable in all cases. While I approve of drawing more attention to the weaknesses of AUTH_SYS, I feel the use of the word "insecure" is too vague. "Insecure" covers a range of problems whereby traffic is either exposed to prying eyes, subject to corruption in transit, or acted upon without authentiction. Given the context, I think we need to be clear about what the actual problem is even though AUTH_SYS, in what has to be considered a virtuoso performance :-), manages to acomplish the hat trick of protocol insecurity. So I propose writing this as follows: The use of requests issued without RPCSEC_GSS (i.e. using AUTH_SYS which has no provision to avoid corruption of data in flight), while undesirable and a potential security exposure, may not be avoidable in all cases. > It=E2=80=99s probably also worth discussing whether s14.3 should drop > support for includes id-sha1 The text you are referring to was carried over from RFC5661 as-is since there was no issue known with it. Regarding the potential deletion of id-sha1, the issue, given that server support is currently REQUIRED, is whether there are clients using this who might be impacted by a change. I'll check with the working group. > 4) s4.3 (1st sentence): Not sure the 2119-RECOMMENDED is needed. These are really OPTIONAL althouh the word "RECOMMENDED" is (confusingly) used. Will delete. > 5) s4.3 (penultimate para): Seems like r/should/SHOULD. It is probably the case that RFC5661 made a poor choice here. However, I don't think we can change it now. > 10) s16 (3rd bullet): Why is requirement is caps? It's because I was under the misapprehension that statement that things were REQUIRED or RECOMMENDED could be referred to as "REQUIREMENTS" or "RECOMMENDATIONS". It turns out not to be so. Will address nits 0)-4) and 6)-10) in -05. On Wed, Feb 27, 2019 at 12:38 PM Sean Turner wrote: > Reviewer: Sean Turner > Review result: Has Issues > > This draft updates NFSv4.1 to correct handling of the fs_locations and > fs_locations_info attributes; NFSv4.1 weighs in at 617 pages and this > draft weighs in a relatively spry 106; let=E2=80=99s say I was really, re= ally > hoping > for some multi-page ASCII art, but also no pretty much all text. The > draft does a good job of explaining what=E2=80=99s being replaced and why= , but > I have to say that I did not check all of section pointers. These > instructions will really help when work on a fully revised NFS RFC gets > going. Unfortunately for me, I do not have NFSv4.1 in my head so let=E2= =80=99s > just say that I did my best =E2=80=A6 > > Summary: This draft is probably worthy of some type of DISCUSS based > on the following: > > 0) The big issue being addressed in the security considerations is the fa= ct > that RPSEC_GSS is must support not must use and the other mechanism > referred to by RFC 5661 are: > > - AUTH_NONE - nada authentication > > - AUTH_SYS as described in Appendix A is known to be insecure due to > the lack of a verifier to permit the credential to be validated. > AUTH_SYS SHOULD NOT be used for services that permit clients to > modify data. AUTH_SYS MUST NOT be specified as RECOMMENDED or > REQUIRED for any Standards Track RPC service. > > - AUTH_DH as mentioned in Sections 8.2 and 13.4.2 is considered > obsolete and insecure; see [RFC2695]. AUTH_DH SHOULD NOT be used for > services that permit clients to modify data. AUTH_DH MUST NOT be > specified as RECOMMENDED or REQUIRED for any Standards Track RPC > service. > > So what do you do when RFC 5661 says: > The fetching of attributes containing file system location > information SHOULD be performed using RPCSEC_GSS with integrity > protection, > And, you don=E2=80=99t now change to MUST use RPSEC_GSS? Well I think at= a > minimum you should do some 2119 language: > > 0) s16 (after the bullets): 2119 this should: > > In light of the above, a server should present file system > location entries that correspond to file systems on other servers > using a host name. > > 1) s16 (2nd para after the bullets): 2199 this SHOULD NOT: > > As a > result, the client should not use such unverified location entries > as a basis for migration, even though RPCSEC_GSS might be > available on the destination. > > 2) s16 (last bullet): 2119 this should: > > Where the use of the returned information cannot be > avoided, it should be subject to filtering to eliminate the > possibility that the client would treat an invalid address as > if it were a NFSv4 server. > > And, I guess since AUTH_SYS is insecure can I suggest a friendly > amendment to the following sentence: > > OLD: > The use of requests issued without RPCSEC_GSS (i.e. using > AUTH_SYS), while undesirable, may not be avoidable in all > cases. > > NEW: > > The use of requests issued without RPCSEC_GSS (i.e. using > the known to be insecure AUTH_SYS), while undesirable and > Insecure, may not be avoidable in all cases. > > It=E2=80=99s probably also worth discussing whether s14.3 should drop > support for includes id-sha1. > > > These are the nits: > > 0) Update to use new 2119 paragraph: > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and > "OPTIONAL" in this document are to be interpreted as described in BCP > 14 [RFC2119] [RFC8174] when, and only when, they appear in all > capitals, as shown here. > > 1) s3.1 (wordy): r/since the > ports to be used for various types of connections might be > required to be different/since the > ports to be used for various types of connections might be > different. > > 2) s3.1 (missing period): r/Two such addresses support the use of clienti= d > ID trunking, as described in [RFC5661]/Two such addresses support the > use of clientid > ID trunking, as described in [RFC5661]. > > 3) s4.2 (missing word): r/which may accessed/which may be accessed > > 4) s4.3 (1st sentence): Not sure the 2119-RECOMMENDED is needed. > > 5) s4.3 (penultimate para): Seems like r/should/SHOULD. > > 6) s4.5: r/present , is/present, is > > 7) s4.5: Note sure you need the parenthetical in the following: > a server may (but is not required to) > > 8) s4.5.4: r/In the event that server failures,/In the event that > server fails, > or > r/In the event that server failures,/In the event of server failures, > > 9) s12.2.3: replace ietf.org with example.org (not supposed to use > real domains even if it is =E2=80=9Cours=E2=80=9D). > > 10) s16 (3rd bullet): Why is requirement is caps? > > --000000000000256c000582fe5b8d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> These
> instructions will really help when work= on a fully revised NFS RFC gets
> going.

That'= ;s the intention.=C2=A0 The working group is now discussing the possibility= of an rfc5661bis
that would use those instructions.=C2=A0 =C2=A0= Note that the current document would be the source of
a large set= of the changes but there are also others: The internationalization section= needs to
be updated as it was in RFC7530.=C2=A0 Section 12 needs= to be updated to reflect the work done by=C2=A0
RFC8434.=C2=A0 A= lso, there are a lot of erratta that would need to be applied.
> 0) The big issue being addressed in the security consider= ations is the fact
> that RPSEC_GSS is must support not must use

That reflects choices made for RFC3530 and carried ove= r until now.=C2=A0 =C2=A0This has resulted in
a situation in whic= h AUTH_SYS is very commonly used despite its obvious security weaknesses.

> So what do you do when RFC 5661 says:

>=C2=A0 The fetching of attributes containing file system location=
>=C2=A0 information SHOULD be performed using RPCSEC_GSS with integr= ity
>=C2=A0 protection,

Not much, since ther= e is not much I can do about that.

> And, you don=E2=80=99= t now change to MUST use RPSEC_GSS?=C2=A0

No I don= 't.=C2=A0 =C2=A0Currently use of AUTH_SYS is allowed and the working
group has not made any decision to change that.=C2=A0 =C2=A0=C2=A0<= /div>

> Well I think at a minimum you should do some = 2119 language:

OK, but note that this is a widely-= deployed protocol and we are not
in a position to invalidate depl= oyment choices made in line with RFC5661,
even if we think they w= ere ill-advised.

> 0) s16 (after the bullets): = 2119 this should:

If you are suggesting changing &= quot;should" to "SHOULD" in this parapgraph,
I'= ;m OK with making that change in -05, although I will raise the issue with<= br>
the working group to check about existing implemtations.

> 1) s16 (2nd para after the bullets): 2199 this SH= OULD NOT:=C2=A0=C2=A0

I intend to shift this t= o "SHOULD NOT"=C2=A0 in -05.

> 2) s16= (last bullet): 2119 this should:

Given that t= his bullet appears in a summary, I think the "should" is misleadi= ng.=C2=A0 =C2=A0Converting it to "SHOULD" would lead to recommemm= ending filtering without specifying the filtering to be done.=C2=A0 What I = propose to do in -05 is replace "should be subect to filtering" b= y "is made subject to filtering as described above".
> The use of requests issued without RPCSEC_GSS (i.e. using=
>=C2=A0 the known to be insecure AUTH_SYS), while undesirable and>=C2=A0 Insecure, may not be avoidable in all cases.=C2=A0=C2=A0

While I approve of drawing more attention to the wea= knesses of=C2=A0
AUTH_SYS, I feel the use of the word "insec= ure" is too vague.=C2=A0 =C2=A0
"Insecure" covers = a range of problems whereby traffic is either=C2=A0
exposed to pr= ying eyes, subject to corruption in transit, or acted=C2=A0
upon = without authentiction.=C2=A0 =C2=A0Given the context, I think we need to=C2= =A0
be clear about what the actual problem is even though AUTH_SY= S,=C2=A0
in what has to be considered a virtuoso performance :-),= manages=C2=A0
to acomplish the hat trick of protocol insecurity.=

So I propose writing this as follows:
<= br>
The use of requests issued without RPCSEC_GSS (i.e. using AUTH_SYS = which has no provision to avoid corruption of data in flight), while undesi= rable and a potential security exposure, may not be avoidable in all cases.= =C2=A0=C2=A0=C2=A0

> It= =E2=80=99s probably also worth discussing whether s14.3 should drop
> support for includes id-sha1

The text you a= re referring to was carried over from RFC5661 as-is since there was no issu= e known with it.

Regarding the potential deletion = of id-sha1, the issue, given that server support is currently REQUIRED, is = whether there are clients using this who might be impacted by a change.=C2= =A0 =C2=A0I'll check with the working group.

&= gt; 4) s4.3 (1st sentence): Not sure the 2119-RECOMMENDED is needed.
<= div>
These are really OPTIONAL althouh the word "RECOMME= NDED" is (confusingly) used.
Will delete.

> 5) s4.3 (penultimate para): Seems like r/should/SHOULD.

It is probably the case that RFC5661 made a poor choice h= ere.=C2=A0 However, I don't think we can change it now.

<= /div>
> 10) s16 (3rd bullet): Why is requirement is caps?=C2=A0=

It's because I was under the misapprehension = that statement that things were REQUIRED or RECOMMENDED could be referred t= o as "REQUIREMENTS" or "RECOMMENDATIONS".=C2=A0 It turn= s out not to be so.=C2=A0
=C2=A0=C2=A0
Will a= ddress nits 0)-4) and 6)-10) in -05.

On Wed, Feb 27, 2019 at 12:38 PM = Sean Turner <sean@sn= 3rd.com> wrote:
Reviewer: Sean Turner
Review result: Has Issues

This draft updates NFSv4.1 to correct handling of the fs_locations and
fs_locations_info attributes; NFSv4.1 weighs in at 617 pages and this
draft weighs in a relatively spry 106; let=E2=80=99s say I was really, real= ly hoping
for some multi-page ASCII art, but also no pretty much all text.=C2=A0 The<= br> draft does a good job of explaining what=E2=80=99s being replaced and why, = but
I have to say that I did not check all of section pointers.=C2=A0 These
instructions will really help when work on a fully revised NFS RFC gets
going.=C2=A0 Unfortunately for me, I do not have NFSv4.1 in my head so let= =E2=80=99s
just say that I did my best =E2=80=A6

Summary: This draft is probably worthy of some type of DISCUSS based
on the following:

0) The big issue being addressed in the security considerations is the fact=
that RPSEC_GSS is must support not must use and the other mechanism
referred to by RFC 5661 are:

- AUTH_NONE - nada authentication

- AUTH_SYS as described in Appendix A is known to be insecure due to
=C2=A0 =C2=A0the lack of a verifier to permit the credential to be validate= d.
=C2=A0 =C2=A0AUTH_SYS SHOULD NOT be used for services that permit clients t= o
=C2=A0 =C2=A0modify data.=C2=A0 AUTH_SYS MUST NOT be specified as RECOMMEND= ED or
=C2=A0 =C2=A0REQUIRED for any Standards Track RPC service.

- AUTH_DH as mentioned in Sections 8.2 and 13.4.2 is considered
=C2=A0 =C2=A0obsolete and insecure; see [RFC2695].=C2=A0 AUTH_DH SHOULD NOT= be used for
=C2=A0 =C2=A0services that permit clients to modify data.=C2=A0 AUTH_DH MUS= T NOT be
=C2=A0 =C2=A0specified as RECOMMENDED or REQUIRED for any Standards Track R= PC
=C2=A0 =C2=A0service.

So what do you do when RFC 5661 says:
=C2=A0 The fetching of attributes containing file system location
=C2=A0 information SHOULD be performed using RPCSEC_GSS with integrity
=C2=A0 protection,
And, you don=E2=80=99t now change to MUST use RPSEC_GSS?=C2=A0 Well I think= at a
minimum you should do some 2119 language:

0) s16 (after the bullets): 2119 this should:

=C2=A0 In light of the above, a server should present file system
=C2=A0 location entries that correspond to file systems on other servers =C2=A0 using a host name.

1) s16 (2nd para after the bullets): 2199 this SHOULD NOT:

=C2=A0 =C2=A0As a
=C2=A0 =C2=A0result, the client should not use such unverified location ent= ries
=C2=A0 =C2=A0as a basis for migration, even though RPCSEC_GSS might be
=C2=A0 =C2=A0available on the destination.

2) s16 (last bullet): 2119 this should:

=C2=A0 Where the use of the returned information cannot be
=C2=A0 avoided, it should be subject to filtering to eliminate the
=C2=A0 possibility that the client would treat an invalid address as
=C2=A0 if it were a NFSv4 server.

And, I guess since AUTH_SYS is insecure can I suggest a friendly
amendment to the following sentence:

OLD:=E2=80=A8
=C2=A0 The use of requests issued without RPCSEC_GSS (i.e. using
=C2=A0 AUTH_SYS), while undesirable, may not be avoidable in all
=C2=A0 cases.

NEW:

=C2=A0 The use of requests issued without RPCSEC_GSS (i.e. using
=C2=A0 the known to be insecure AUTH_SYS), while undesirable and
=C2=A0 Insecure, may not be avoidable in all cases.

It=E2=80=99s probably also worth discussing whether s14.3 should drop
support for includes id-sha1.


These are the nits:

0) Update to use new 2119 paragraph:

=C2=A0 The key words "MUST", "MUST NOT", "REQUIRED= ", "SHALL", "SHALL NOT",
=C2=A0 "SHOULD", "SHOULD NOT", "RECOMMENDED",= "NOT RECOMMENDED", "MAY", and
=C2=A0 "OPTIONAL" in this document are to be interpreted as descr= ibed in BCP
=C2=A0 14 [RFC2119] [RFC8174] when, and only when, they appear in all
=C2=A0 capitals, as shown here.

1) s3.1 (wordy): r/since the
=C2=A0 ports to be used for various types of connections might be
=C2=A0 required to be different/since the
=C2=A0 ports to be used for various types of connections might be
=C2=A0 different.

2) s3.1 (missing period): r/Two such addresses support the use of clientid<= br> =C2=A0 ID trunking, as described in [RFC5661]/Two such addresses support th= e use of clientid
=C2=A0 ID trunking, as described in [RFC5661].

3) s4.2 (missing word): r/which may accessed/which may be accessed

4) s4.3 (1st sentence): Not sure the 2119-RECOMMENDED is needed.

5) s4.3 (penultimate para): Seems like r/should/SHOULD.

6) s4.5: r/present , is/present, is

7) s4.5: Note sure you need the parenthetical in the following:
=C2=A0 a server may (but is not required to)

8) s4.5.4: r/In the event that server failures,/In the event that
server fails,
or
r/In the event that server failures,/In the event of server failures,

9) s12.2.3: replace ietf.org with example.org (not supposed to use
real domains even if it is =E2=80=9Cours=E2=80=9D).

10) s16 (3rd bullet): Why is requirement is caps?

--000000000000256c000582fe5b8d--