From nobody Thu Apr 2 07:00:54 2020 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 3EBED3A12F6; Thu, 2 Apr 2020 07:00:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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 fzOMckTw7v7b; Thu, 2 Apr 2020 07:00:45 -0700 (PDT) Received: from mail-ot1-x335.google.com (mail-ot1-x335.google.com [IPv6:2607:f8b0:4864:20::335]) (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 E5BDF3A12EA; Thu, 2 Apr 2020 07:00:44 -0700 (PDT) Received: by mail-ot1-x335.google.com with SMTP id c9so3427635otl.12; Thu, 02 Apr 2020 07:00:44 -0700 (PDT) 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=YBhjgAKk6unyourTdbnn5j+TKG1Pe0GWInzKKmpC5lE=; b=q/fDb3m0sCS8ZnkXeFV64dVq/w+WFAL8E4DbkogSxWCxRm40gNx9Cdln+VwNCAFdqQ 8x0t65zmOJUx9Gol9qUgJZ2iw1dhpo0km3aIQWGLmllDWOCCxFFG/VHYNabDlSrSSNu5 lATZaK2BurUqP82vdPhRGHo0a1hJnYRjWwU4XbUWVCzvTezl6r09w1fzTv/PURe9q/WH ZMmTFnBg2o1MyVMmBlDNAR8qcsL9XPmdvuHx8E1fxfh/z3C23QlyyLPCpWPaZ4OzMPBm H9wbTiLM1oY2Qz5lNcFom7haR0kjdTTsqDBNPfLXmIigC+HwNhGdaYZdlv5Ywtg5MDCu o61w== 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=YBhjgAKk6unyourTdbnn5j+TKG1Pe0GWInzKKmpC5lE=; b=Gdf3TvvCv0X+4gAw+YS3rYztWgbnQq9goJDLJYIft/BqdN8sZsZRNeP37pq8ELH7uS m0zdKGJYwbL52hjQLoJ6iYJ+Nuc7RBcv5KJLHjoxyHeJ+chpZ1Vmtqq48iUx0gvoAtL6 spCHnl2P8tyICuvg8wNWnMqSaL/zFJJiU443Zy3CTWo9WCBSH9N6OA1PtMBlHmwK3tqx /e9ZEBdg6N8x/rrlrsQ35C3X/spDaMazqdO6it0SvqjVtoIkHz2T/0uqz+uwaq+VrgDb Ca4vwa1rGrDyO/ssZyiC0GNhhH+x/LwnpAvhE84jsJAlPSMQNuQi+0Kzgg6WL5JryKKk hFSA== X-Gm-Message-State: AGi0PuZ7vRZRDMZ4WH2tBcKOXYhGP6/Z8poLnbXxyGUslY5dG951McjD itZxC/mJilvB+eDIEBzHV/TomCf5RMQegk1nvwI= X-Google-Smtp-Source: APiQypKlCVdCtEoaMtQYvvxQOQqODUWP5vFAmlOj/iQYZ6h9hbhxn6uED/42ILKjn5UGtAKv/zRAuI/8Qj/Ww3n4704= X-Received: by 2002:a9d:4802:: with SMTP id c2mr2562877otf.78.1585836043184; Thu, 02 Apr 2020 07:00:43 -0700 (PDT) MIME-Version: 1.0 References: <158534708187.17642.15427344724416293958@ietfa.amsl.com> In-Reply-To: <158534708187.17642.15427344724416293958@ietfa.amsl.com> From: Shumon Huque Date: Thu, 2 Apr 2020 10:00:30 -0400 Message-ID: To: Daniel Migault Cc: secdir@ietf.org, draft-ietf-dnsop-multi-provider-dnssec.all@ietf.org, last-call@ietf.org, "dnsop@ietf.org WG" Content-Type: multipart/alternative; boundary="00000000000006ae9405a24f3a92" Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-dnsop-multi-provider-dnssec-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: Thu, 02 Apr 2020 14:00:51 -0000 --00000000000006ae9405a24f3a92 Content-Type: text/plain; charset="UTF-8" On Fri, Mar 27, 2020 at 6:11 PM Daniel Migault via Datatracker < noreply@ietf.org> wrote: > Reviewer: Daniel Migault > Thank you for your detailed review Daniel. describes > > These models do not > require any changes to the behavior of validating resolvers, nor do > they impose the new key management requirements on authoritative > servers not involved in multi signer configurations. > > > > I am reading the last sentence as no changes are expected for servers not > implementing. Maybe it would be clearer to say that changes are only > expected > on server implementing the multi signer described in this document. Of > course > this is only a suggestion. > Either way works in my opinion, but other reviewers specifically asked us to point out the "no changes for others" characteristic of these models, so I'm inclined to leave this as it is. The following descriptions consider the case of two DNS providers, > but the model is generalizable to any number. > > > The only justification for the use of two is that both is once used. I > think > this is not really needed with the current text. > Yes, I agree. This is probably a remnant of an earlier version of the draft that specifically mentioned 2 signing providers. The current text in Section 2 applies generally to any number. I will remove this sentence. > > 2.1.1. Model 1: Common KSK, Unique ZSK per provider > > > > The term Unique may not be appropriated as it could be interpreted as one > single and not two ZSKs per providers. I think that Unique here means "per > provider independent ZSK." > Yes, that's what it means (unique per provider). I'm thinking about how to clarify and reword that. One note also, I am also balanced by considering there is always multiple > KSKs, > ZSKs as this could be the case between the key roll overs. On the other > hand, I > do not know if it makes the text more complex to read. > Sorry, can you elaborate? For model 2, there are always multiple KSKs (at least 1 per provider). For model 1, there is single KSK (or KSK set, if the zone owner is rolling or pre-publishing). The section 2 description kind of glosses over the fact that providers could have multiple keys for the sake of simplicity, and assumes the reader understands that. The key rollover section describes one multi-key per provider scenario. I guess one possible change that might address this is to replace "KSK" with "KSK set" and "ZSK" with "ZSK set". I am wondering if it makes sense to also consider this model with one > provider > if the content owner wants to keep the ownership/control of the zone. > I had considered mentioning that possibility for model 1. (For model 2, this would just degenerate to a standard configuration, so it isn't worth describing). In the early days of the draft, Dave Blacka pointed out to me that model 1 with a single provider is essentially how the DNS root is operated today (ICANN -> zone owner, Verisign -> signing provider). In the end, I decided the single signing provider configuration is probably an exceptional case that we won't see too often in the field. So I left it out, to avoid overcomplicating the draft. But I'm open to reconsidering. (Or maybe it's already covered implicitly because it is just the degenerate case where N=1). > > o Zone owner holds the KSK, manages the DS record, and is > responsible for signing the DNSKEY RRset and distributing the > signed DNSKEY RRset to the providers. > > o Each provider has their own ZSK which is used to sign data. > > o Providers have an API that owner uses to query the ZSK public key, > and insert a combined DNSKEY RRset that includes both ZSKs and the > KSK, signed by the KSK. > > > > I believe the text could be clearer on who generates the DNSKEY RRset and > describe the outputs in an uniform way - that is using RRsets for both > outputs. > Ok. > The text also seems to indicate the owner directly updates the zone. The "data content" of the zone, yes. > While this > is the resulting outcome, I understood the insertion to the zone as being > performed by the provider as in some cases a signature with the ZSK may > also be > performed. > Can you elaborate on what you mean here? The providers always have to update the zone with new signatures (by their ZSK) for incoming data changes. Explanation may actually be more complex then the actual change. The text I > would propose would be around the lines (assuming I am not missing > anything): > > Providers have an API to enable the owner to retrieve the ZSKs public key > from > the providers, generate and return the appropriated DNSKEY and RRSIG > RRsets. > The DNSKEY RRset contains the ZSKs of the multiple providers and the KSKs. > Its associated RRSIG RRset contains the signature of the DNSKEY RRset with > the > KSKs. > Ok, I'm pondering. Most of this is already covered in different parts of the draft I believe. And the first sentence of your text above is correct for model1, but not for model 2. > > > o Note that even if the contents of the DNSKEY RRset don't change, > the Zone owner of course needs to periodically re-sign it as > signature expiration approaches. The provider API is also used to > thus periodically redistribute the refreshed DNSKEY RRset. > > o Key rollovers need coordinated participation of the zone owner to > update the DNSKEY RRset (for KSK or ZSK), and the DS RRset (for > KSK). > > > Unless I am missing something, I believe that the API operating regularly > could > proceed to a key roll over in an automated way. Yes, for the first bullet point above, the action could be fully automated (and that is what we were expecting would happen). > The only additional step would > consists in the publication of the DS RRSet. I am wondering if one is a > specific key roll over or an emergency key roll over was considered there. > Key roll automation is trickier if it involves the DS, although Section 8 could help if specific conditions allow. We don't specifically call out emergency key rollovers (I'm not sure this document needs to do that, since it should generally be clear to operators what needs to be done). 2.1.2. Model 2: Unique KSK and ZSK per provider > > o Each provider has their own KSK and ZSK. > > o Each provider offers an API that the Zone Owner uses to import the > ZSK of the other provider into their DNSKEY RRset. > > > I think "Zone Owner" was used without capital letter before. > Ok, will address. In this case I believe that the information is the ZSKs public key (as > opposed > as the DNSKEY RRset) and that each provider is responsible of publishing > ZSKs > of other providers and signing those with their own KSKs and eventually > their > own ZSKs. Maybe this could be detailed a bit more. > Yes, but I'm not seeing what is not clear in the current text. I will ponder. It might be clarifying to specify: > "Each provider offers an API that the zone owner to import the ZSKs public > key > and export the ZSKs public keys of all providers. Each provider will > generate > the associated DNSSEY RRset." > > What is unclear to me is who generates the DNSKEY RRset. I have the > impression > each provider is generating its own DNSKEY. It depends. In model 1, is is the zone owner. In model 2, each provider updates their DNSKEY RRset with a ZSK (public key) imported from the other provider(s). Then independently signs the DNSKEY RRset with their own KSK(s). I will review the current text and see if I can make this clearer. > s/both/all/ > Ok. > > > > 3. Validating Resolver Behavior > [...] > > o The resolver will not accept this response. It may still be able > to ultimately authenticate the name by querying other nameservers > for the zone until it elicits a response from one of provider A's > nameservers. But it has incurred the penalty of additional > roundtrips with other nameservers, with the corresponding latency > and processing costs. The exact number of additional roundtrips > depends on details of the resolver's nameserver selection > algorithm and the number of nameservers configured at provider B. > > > > With the use of geographic authoritative DNS for example, I have the > impression we > may also have one provider is only available in from one place and not > from the > other thus making the resolution possible probably only possible after > flushing > the cache. > I assume the other provider(s) would still be reachable, even if they were geographically or topologically more distant. So if a resolver's nameserver selection algorithm in this case tends to prefer the more proximal provider, and none of them return a validatable response, it would eventually move on to the other providers, or fail because of an aggregate timeout or exceeding some retry limit. I'm not sure if we need to call out such special cases explicitly, as we have a more general description that covers many possible cases. > > I have the impression that the resolution does not consider the DS. I think > that some text needs to be added to mention that all KSK must appropriately > delegated. > Do we need to? In the resolver behavior section, it is implied that providers have to have a working secure delegation. I suppose we could mention that, but the section is focussed on what is fundamentally unique in this configuration. The DS configuration requirements for each model are described in the model descriptions earlier in the document. > > > > The Zone Owner deploys a DS RRset at the > parent zone that contains multiple DS records, each referring to a > distinct provider's KSK. Hence it does not matter which provider's > nameservers the resolver obtains the DNSKEY RRset from, the signed DS > record in each model can authenticate the associated KSK. > > 4. Signing Algorithm Considerations > > DNS providers participating in multi-signer models need to use a > common DNSSEC signing algorithm. > > > I think the text is saying that providers needs to have a common algorithm > which does not seem correct. The text also only mentions the use of a > single > algorithms which I believe is maybe too restrictive. I would propose > something > around the following lines: > Yeah, good point. We can expand the text to say that each provider needs to use a common "set" of signing algorithms. The providers MUST use the same algorithms for signing. > As discussed in an earlier thread on dnsop, we decided not to use RFC 2119/8174 keywords. So "must use" or "need to use". Even though the document is informational, I do not think this prevents > using > normative language. Here I would think that a RECOMMENDED might be > appropriated. > See above. But if there is a new consensus on the use of 2119/8174 keywords, we could go there. > methods. This could make caching on the resolver side less efficient > and the authoritative servers may observe higher number of queries. > This aspect should be considered especially in context of Aggresive > > > > Aggressive maybe? > Yes. > > The use of mixed method seems to me outside the design of DNSSEC with the > publication of one zone. The impact on 8198 as well as the additional > burden > provided on resolvers seems to me sufficient to at least strongly > discourage > the mixed method. > I think we do implicitly discourage it, by calling out the deficiencies of this approach. But yes, we could be more explicit about it. 6.1. Model 1: Common KSK, Unique ZSK per provider > > o Key Signing Key Rollover: In this model, the two managed DNS > providers share a common KSK which is held by the Zone Owner. > > > The text seems confusing as the providers do not actually share the KSK but > instead publish a common DNSKEY RRsets with the same public part of the > KSK. > > My understanding of sharing a key means that the private part is shared. > > Ok. I will clarify. > > To > initiate the rollover, the Zone Owner generates a new KSK and > obtains the DNSKEY RRset of each DNS provider using their > respective APIs. The new KSK is added to each provider's DNSKEY > RRset and the RRset is re-signed with both the new and the old > KSK. This new DNSKEY RRset is then transferred to each provider. > > > > At this point the KSK cannot be used so I am wondering if the DS that > corresponds to the new KSK should not need to be added before the new KSK > being > added to the DNSKEY RRset. > There are some caveats here. Our text describes the more common Double Signature KSK rollover model (see RFC 6781 for details). You are describing the "Double DS KSK Rollover". The prefatory text in Section 6 says the following: "The descriptions in this section assume that KSK rollovers employ the commonly used Double Signature KSK Rollover Method, and that ZSK rollovers employ the Pre-Publish ZSK Rollover Method, as described in detail in [RFC6781]. With minor modifications, they can also be easily adapted to other models, such as Double DS KSK Rollover or Double Signature ZSK rollover, if desired. We are trying to avoid repeating lots of text in 6781 and mainly focussing on the deltas needed to work with multi-signer. 12. Security Considerations > > The Zone key import APIs required by these models need to be strongly > authenticated to prevent tampering of key material by malicious third > parties. Many providers today offer REST/HTTPS APIs that utilize a > number of authentication mechanisms (username/password, API keys > etc). If DNS protocol mechanisms like UPDATE are being used for key > insertion and deletion, they should similarly be strongly > authenticated, e.g. by employing Transaction Signatures (TSIG) > [RFC2845]. > > > I believe that some words should be provided on the security implied by > the two > models. For the two models the providers signs and so is able to modify > and > alter the zone. The content is actually under the responsibility of the > provider > not the zone owner. In addition, the zone owner has little mean to check > the > appropriated content is being delivered. > [...] Yes, it should be fairly obvious to most readers that having 3rd-party DNS providers sign your zone data means delegating a huge amount of trust to them. But I agree that this should be explicitly discussed in the Security Considerations section, and contrasted with the "zone owner operated signing master + zone transfer approach". I will work on some text for this. Shumon Huque --00000000000006ae9405a24f3a92 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Mar 27, 2020 at 6:11 PM Daniel Mi= gault via Datatracker <noreply@ietf.= org> wrote:
Reviewer: Daniel Migault

Thank you for your detailed review Daniel.

<mglt>describes</mglt>

=C2=A0 =C2=A0These models do not
=C2=A0 =C2=A0require any changes to the behavior of validating resolvers, n= or do
=C2=A0 =C2=A0they impose the new key management requirements on authoritati= ve
=C2=A0 =C2=A0servers not involved in multi signer configurations.

<mglt>

I am reading the last sentence as no changes are expected for servers not implementing. Maybe it would be clearer to say that changes are only expect= ed
on server implementing the multi signer described in this document. Of cour= se
this is only a suggestion.

Either way w= orks in my opinion, but other reviewers specifically asked us to point out = the "no changes for others" characteristic of these models, so I&= #39;m inclined to leave this as it is.

=C2=A0 =C2=A0The following descriptions consider the case of two DNS provid= ers,
=C2=A0 =C2=A0but the model is generalizable to any number.=C2=A0

<mglt>

The only justification for the use of two is that both is once used. I thin= k
this is not really needed with the current text.

<= /div>
Yes, I agree. This is probably a remnant of an earlier version of= the draft that specifically mentioned 2 signing providers. The current tex= t in Section 2 applies generally to any number. I will remove this sentence= .

</mglt>

2.1.1.=C2=A0 Model 1: Common KSK, Unique ZSK per provider

<mglt>

The term Unique may not be appropriated as it could be interpreted as one single and not two ZSKs per providers. I think that Unique here means "= ;per
provider independent ZSK."

Yes, th= at's what it means (unique per provider). I'm thinking about how to= clarify and reword that.

One note also, I am also balanced by considering there is always multiple K= SKs,
ZSKs as this could be the case between the key roll overs. On the other han= d, I
do not know if it makes the text more complex to read.

Sorry, can you elaborate? For model 2, there are always mul= tiple KSKs (at least 1 per provider). For model 1, there is single KSK (or = KSK set, if the zone owner is rolling or pre-publishing). The section 2 des= cription kind of glosses over the fact that providers could have multiple k= eys for the sake of simplicity,=C2=A0and assumes the reader understands tha= t. The key rollover section describes one multi-key per provider scenario. = I guess one possible change that might address=C2=A0this is to replace &quo= t;KSK" with "KSK set" and "ZSK" with "ZSK set= ".

I am wondering if it makes sense to also consider this model with one provi= der
if the content owner wants to keep the ownership/control of the zone.=C2=A0=

I had considered mentioning that possi= bility for model 1. (For model 2, this would just degenerate to a standard = configuration, so it isn't worth describing).

= In the early days of the draft, Dave Blacka pointed out to me that model 1 = with a single provider is essentially how the DNS root is operated today (I= CANN -> zone owner, Verisign -> signing provider). In the end, I deci= ded the single signing provider configuration is probably an exceptional ca= se that we won't see too often in the field. So I left it out, to avoid= overcomplicating the draft. But I'm open to reconsidering. (Or maybe i= t's already covered implicitly because it is just the degenerate case w= here N=3D1).

</mglt>

=C2=A0 =C2=A0o=C2=A0 Zone owner holds the KSK, manages the DS record, and i= s
=C2=A0 =C2=A0 =C2=A0 responsible for signing the DNSKEY RRset and distribut= ing the
=C2=A0 =C2=A0 =C2=A0 signed DNSKEY RRset to the providers.

=C2=A0 =C2=A0o=C2=A0 Each provider has their own ZSK which is used to sign = data.

=C2=A0 =C2=A0o=C2=A0 Providers have an API that owner uses to query the ZSK= public key,
=C2=A0 =C2=A0 =C2=A0 and insert a combined DNSKEY RRset that includes both = ZSKs and the
=C2=A0 =C2=A0 =C2=A0 KSK, signed by the KSK.

<mglt>

I believe the text could be clearer on who generates the DNSKEY RRset and describe the outputs in an uniform way - that is using RRsets for both outp= uts.

Ok.
=C2=A0
The text also seems to indicate the owner directly updates the zone.

The "data content" of the zone, yes.
=C2=A0
Whil= e this
is the resulting outcome, I understood the insertion to the zone as being performed by the provider as in some cases a signature with the ZSK may als= o be
performed.

Can you elaborate on what y= ou mean here? The providers always have to update the zone with new signatu= res (by their ZSK) for incoming data changes.

Explanation may actually be more complex then the actual change. The text I=
would propose would be around the lines (assuming I am not missing anything= ):

Providers have an API to enable the owner to retrieve the ZSKs public key f= rom
the providers, generate and return the appropriated DNSKEY and RRSIG RRsets= .
The DNSKEY RRset contains the ZSKs of the multiple providers and the KSKs.<= br> Its associated RRSIG RRset contains the signature of the DNSKEY RRset with = the
KSKs.=C2=A0

Ok, I'm pondering. Most= of this is already covered in different parts of the draft I believe. And = the first sentence of your text above is correct for model1, but not for mo= del 2.
=C2=A0

</mglt>
=C2=A0 =C2=A0o=C2=A0 Note that even if the contents of the DNSKEY RRset don= 't change,
=C2=A0 =C2=A0 =C2=A0 the Zone owner of course needs to periodically re-sign= it as
=C2=A0 =C2=A0 =C2=A0 signature expiration approaches.=C2=A0 The provider AP= I is also used to
=C2=A0 =C2=A0 =C2=A0 thus periodically redistribute the refreshed DNSKEY RR= set.

=C2=A0 =C2=A0o=C2=A0 Key rollovers need coordinated participation of the zo= ne owner to
=C2=A0 =C2=A0 =C2=A0 update the DNSKEY RRset (for KSK or ZSK), and the DS R= Rset (for
=C2=A0 =C2=A0 =C2=A0 KSK).

<mglt>
Unless I am missing something, I believe that the API operating regularly c= ould
proceed to a key roll over in an automated way.

=
Yes, for the first bullet point above, the action could be fully autom= ated (and that is what we were expecting would happen).
=C2=A0
The only additional st= ep would
consists in the publication of the DS RRSet. I am wondering if one is a
specific key roll over or an emergency key roll over was considered there.<= br>

Key roll automation is trickier if it i= nvolves the DS, although Section 8 could help if specific conditions allow.=

We don't specifically call out emergency key = rollovers (I'm not sure this document needs to do that, since it should= generally be clear to operators what needs to be done).

2.1.2.=C2=A0 Model 2: Unique KSK and ZSK per provider

=C2=A0 =C2=A0o=C2=A0 Each provider has their own KSK and ZSK.

=C2=A0 =C2=A0o=C2=A0 Each provider offers an API that the Zone Owner uses t= o import the
=C2=A0 =C2=A0 =C2=A0 ZSK of the other provider into their DNSKEY RRset.

<mglt>
I think "Zone Owner" was used without capital letter before.
<= /blockquote>

Ok, will address.

In this case I believe that the information is the ZSKs public key (as oppo= sed
as the DNSKEY RRset) and that each provider is responsible of publishing ZS= Ks
of other providers and signing those with their own KSKs and eventually the= ir
own ZSKs. Maybe this could be detailed a bit more.=C2=A0

Yes, but I'm not seeing what is not clear in the curr= ent text. I will ponder.

It might be clarifying to specify:
"Each provider offers an API that the zone owner to import the ZSKs pu= blic key
and export the ZSKs public keys of all providers. Each provider will genera= te
the associated DNSSEY RRset."

What is unclear to me is who generates the DNSKEY RRset. I have the impress= ion
each provider is generating its own DNSKEY.

It depends.

In model 1, is is the zone owner.

In model 2, each provider=C2=A0 updates their DNSKEY = RRset with a ZSK (public key) imported from the other provider(s). Then ind= ependently signs the DNSKEY RRset with their own KSK(s). I will review the = current text and see if I can make this clearer.
=C2=A0=C2=A0
s/both/all/

Ok.
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex"> </mglt>


3.=C2=A0 Validating Resolver Behavior
[...]

=C2=A0 =C2=A0o=C2=A0 The resolver will not accept this response.=C2=A0 It m= ay still be able
=C2=A0 =C2=A0 =C2=A0 to ultimately authenticate the name by querying other = nameservers
=C2=A0 =C2=A0 =C2=A0 for the zone until it elicits a response from one of p= rovider A's
=C2=A0 =C2=A0 =C2=A0 nameservers.=C2=A0 But it has incurred the penalty of = additional
=C2=A0 =C2=A0 =C2=A0 roundtrips with other nameservers, with the correspond= ing latency
=C2=A0 =C2=A0 =C2=A0 and processing costs.=C2=A0 The exact number of additi= onal roundtrips
=C2=A0 =C2=A0 =C2=A0 depends on details of the resolver's nameserver se= lection
=C2=A0 =C2=A0 =C2=A0 algorithm and the number of nameservers configured at = provider B.

<mglt>

With the use of geographic authoritative DNS for example, I have the impres= sion we
may also have one provider is only available in from one place and not from= the
other thus making the resolution possible probably only possible after flus= hing
the cache.

I assume the other provider(= s) would still be reachable, even if they were geographically or topologica= lly more distant. So if a resolver's nameserver selection algorithm in = this case tends to prefer the more proximal provider, and none of them retu= rn a validatable response, it would eventually move on to the other provide= rs, or fail because of an aggregate timeout or exceeding some retry limit. = I'm not sure if we need to call out such special cases explicitly, as w= e have a more general description that covers many possible cases.

<mglt>

I have the impression that the resolution does not consider the DS. I think=
that some text needs to be added to mention that all KSK must appropriately=
delegated.=C2=A0

Do we need to? In the= =C2=A0resolver behavior section, it is implied that providers have to have = a working secure delegation. I suppose we could mention that, but the secti= on is focussed on what is fundamentally unique in this configuration.
=

The DS configuration requirements for each model are de= scribed in the model descriptions earlier in the document.
=C2=A0=

<mglt>

The Zone Owner deploys a DS RRset at the
=C2=A0 =C2=A0parent zone that contains multiple DS records, each referring = to a
=C2=A0 =C2=A0distinct provider's KSK.=C2=A0 Hence it does not matter wh= ich provider's
=C2=A0 =C2=A0nameservers the resolver obtains the DNSKEY RRset from, the si= gned DS
=C2=A0 =C2=A0record in each model can authenticate the associated KSK.

4.=C2=A0 Signing Algorithm Considerations

=C2=A0 =C2=A0DNS providers participating in multi-signer models need to use= a
=C2=A0 =C2=A0common DNSSEC signing algorithm.

<mglt>
I think the text is saying that providers needs to have a common algorithm<= br> which does not seem correct. The text also only mentions the use of a singl= e
algorithms which I believe is maybe too restrictive. I would propose someth= ing
around the following lines:

Yeah, good = point. We can expand the text to say that each provider needs to use a comm= on "set" of signing algorithms.

The providers MUST use the same algorithms for signing.

As discussed in an earlier thread on dnsop, we decided not= to use RFC 2119/8174 keywords. So "must use" or "need to us= e".

Even though the document is informational, I do not think this prevents usi= ng
normative language. Here I would think that a RECOMMENDED might be
appropriated.

See above. But if there i= s a new consensus on the use of 2119/8174 keywords, we could go there.
=C2=A0
=C2=A0 =C2=A0methods.=C2=A0 This could make caching on the resolver side le= ss efficient
=C2=A0 =C2=A0and the authoritative servers may observe higher number of que= ries.
=C2=A0 =C2=A0This aspect should be considered especially in context of Aggr= esive

<mglt>

Aggressive maybe?

Yes.
=C2=A0=

The use of mixed method seems to me outside the design of DNSSEC with the publication of one zone. The impact on 8198 as well as the additional burde= n
provided on resolvers seems to me sufficient to at least strongly discourag= e
the mixed method.

I think we do implici= tly discourage it, by calling out the deficiencies of this approach. But ye= s, we could be more explicit about it.

6.1.=C2=A0 Model 1: Common KSK, Unique ZSK per provider

=C2=A0 =C2=A0o=C2=A0 Key Signing Key Rollover: In this model, the two manag= ed DNS
=C2=A0 =C2=A0 =C2=A0 providers share a common KSK which is held by the Zone= Owner.

<mglt>
The text seems confusing as the providers do not actually share the KSK but=
instead publish a common DNSKEY RRsets with the same public part of the KSK= .

My understanding of sharing a key means that the private part is shared. </mglt>

Ok. I will clarify.
=
=C2=A0

To
=C2=A0 =C2=A0 =C2=A0 initiate the rollover, the Zone Owner generates a new = KSK and
=C2=A0 =C2=A0 =C2=A0 obtains the DNSKEY RRset of each DNS provider using th= eir
=C2=A0 =C2=A0 =C2=A0 respective APIs.=C2=A0 The new KSK is added to each pr= ovider's DNSKEY
=C2=A0 =C2=A0 =C2=A0 RRset and the RRset is re-signed with both the new and= the old
=C2=A0 =C2=A0 =C2=A0 KSK.=C2=A0 This new DNSKEY RRset is then transferred t= o each provider.

<mglt>

At this point the KSK cannot be used so I am wondering if the DS that
corresponds to the new KSK should not need to be added before the new KSK b= eing
added to the DNSKEY RRset.

There are so= me caveats here. Our text describes the more common Double Signature KSK ro= llover model (see RFC 6781 for details). You are describing the "Doubl= e DS KSK Rollover". The prefatory text in Section 6 says the following= :

=C2=A0"The descriptions in this section ass= ume that KSK rollovers employ the
=C2=A0 =C2=A0commonly used Double Si= gnature KSK Rollover Method, and that ZSK
=C2=A0 =C2=A0rollovers employ = the Pre-Publish ZSK Rollover Method, as described in
=C2=A0 =C2=A0detail= in [RFC6781].=C2=A0 With minor modifications, they can also be
=C2=A0 = =C2=A0easily adapted to other models, such as Double DS KSK Rollover or
= =C2=A0 =C2=A0Double Signature ZSK rollover, if desired.

We are trying to avoid re= peating lots of text in 6781 and mainly focussing on the deltas needed to w= ork with multi-signer.

12.=C2=A0 Security Considerations

=C2=A0 =C2=A0The Zone key import APIs required by these models need to be s= trongly
=C2=A0 =C2=A0authenticated to prevent tampering of key material by maliciou= s third
=C2=A0 =C2=A0parties.=C2=A0 Many providers today offer REST/HTTPS APIs that= utilize a
=C2=A0 =C2=A0number of authentication mechanisms (username/password, API ke= ys
=C2=A0 =C2=A0etc).=C2=A0 If DNS protocol mechanisms like UPDATE are being u= sed for key
=C2=A0 =C2=A0insertion and deletion, they should similarly be strongly
=C2=A0 =C2=A0authenticated, e.g. by employing Transaction Signatures (TSIG)=
=C2=A0 =C2=A0[RFC2845].

<mglt>
I believe that some words should be provided on the security implied by the= two
models.=C2=A0 For the two models the providers signs and so is able to modi= fy and
alter the zone. The content is actually under the responsibility of the pro= vider
not the zone owner. In addition, the zone owner has little mean to check th= e
appropriated content is being delivered.
[...]=C2=A0<= /div>

Yes, it should be fairly obvious to most readers t= hat having 3rd-party DNS providers sign your zone data means delegating a h= uge amount of trust to them. But I agree that this should be explicitly dis= cussed in the Security Considerations section,=C2=A0and contrasted with the= "zone owner operated signing master + zone transfer approach". I= will work on some text for this.

Shumon Huque

--00000000000006ae9405a24f3a92-- From nobody Fri Apr 3 15:55:26 2020 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 47B733A0DC4 for ; Fri, 3 Apr 2020 15:55:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Tero Kivinen via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 6.124.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu, Tero Kivinen Message-ID: <158595452518.23434.10067173822445561385@ietfa.amsl.com> Date: Fri, 03 Apr 2020 15:55:25 -0700 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: Fri, 03 Apr 2020 22:55:25 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2020-04-09 Reviewer LC end Draft John Bradley 2020-02-28 draft-ietf-regext-data-escrow-05 Donald Eastlake R2019-11-14 draft-ietf-hip-dex-18 Stephen Farrell R2020-03-10 draft-ietf-tsvwg-datagram-plpmtud-19 Scott Kelly 2020-03-18 draft-ietf-sidrops-ov-egress-02 Kathleen Moriarty 2020-03-20 draft-ietf-sidrops-rp-06 Takeshi Takahashi 2020-02-06 draft-ietf-mmusic-t140-usage-data-channel-12 Paul Wouters R2019-10-18 draft-ietf-taps-transport-security-11 Dacheng Zhang 2020-03-12 draft-nottingham-how-did-that-get-into-the-repo-01 Last calls: Reviewer LC end Draft John Bradley 2020-02-28 draft-ietf-regext-data-escrow-05 Alan DeKok 2019-06-04 draft-ietf-netvc-testing-09 Donald Eastlake 2020-02-27 draft-ietf-6tisch-msf-16 Donald Eastlake R2019-11-14 draft-ietf-hip-dex-18 Stephen Farrell R2020-03-10 draft-ietf-tsvwg-datagram-plpmtud-19 Daniel Franke 2020-03-09 draft-ietf-regext-dnrd-objects-mapping-06 Scott Kelly 2020-03-18 draft-ietf-sidrops-ov-egress-02 Aanchal Malhotra 2020-03-12 draft-ietf-bess-vpls-multihoming-05 Kathleen Moriarty 2020-03-20 draft-ietf-sidrops-rp-06 Russ Mundy 2020-01-02 draft-ietf-dprive-bcp-op-08 Sandra Murphy 2020-04-08 draft-ietf-dmarc-psd-08 Yoav Nir 2020-04-08 draft-ietf-idr-rfc5575bis-20 Magnus Nystrom 2020-04-30 draft-iesg-nomcom-eligibility-2020-00 Magnus Nystrom 2019-04-10 draft-ietf-avtcore-multiplex-guidelines-11 Hilarie Orman 2020-04-29 draft-hodges-webauthn-registries-05 Francesca Palombini 2020-04-28 draft-ietf-rtcweb-sdp-11 Radia Perlman 2020-04-17 draft-ietf-idr-bgp-ls-segment-routing-msd-16 Derrell Piper 2020-04-15 draft-ietf-sipcore-sip-token-authnz-12 Tirumaleswar Reddy.K 2020-04-09 draft-ietf-sfc-oam-framework-11 Vincent Roca 2020-01-30 draft-ietf-pim-msdp-yang-16 Takeshi Takahashi 2020-02-06 draft-ietf-mmusic-t140-usage-data-channel-12 Sean Turner None draft-ietf-opsawg-sdi-02 Paul Wouters R2019-10-18 draft-ietf-taps-transport-security-11 Dacheng Zhang 2019-11-05 draft-ietf-mpls-ri-rsvp-frr-07 Dacheng Zhang 2020-03-12 draft-nottingham-how-did-that-get-into-the-repo-01 Next in the reviewer rotation: Vincent Roca Kyle Rose Joseph Salowey Rich Salz Stefan Santesson Yaron Sheffer Rifaat Shekh-Yusef Melinda Shore Valery Smyslov Robert Sparks From nobody Sat Apr 4 14:11:18 2020 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 A43413A0C25; Sat, 4 Apr 2020 14:11:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Stephen Farrell via Datatracker To: Cc: last-call@ietf.org, tsvwg@ietf.org, draft-ietf-tsvwg-datagram-plpmtud.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.124.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158603467562.27263.2918619786629536861@ietfa.amsl.com> Reply-To: Stephen Farrell Date: Sat, 04 Apr 2020 14:11:15 -0700 Archived-At: Subject: [secdir] Secdir telechat review of draft-ietf-tsvwg-datagram-plpmtud-19 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, 04 Apr 2020 21:11:16 -0000 Reviewer: Stephen Farrell Review result: Has Nits Thanks for addressing my earlier secdir comments on -15. I think the ones below remain but are, from my POV, nits: - Abstract: This draft aims for proposed standard but is updating a BCP (RFC8085/BCP145). I'm happy to leave the process-lawyering for that to others. - 6.3: I am surprised that the QUIC description here is ready to be an RFC before QUIC itself. I do see there are normative references, but the potential for a breaking change still exists, and seems a bit unwise. (I'd suggest, holding this in the WG 'till the referenced QUIC drafts are in the RFC editor queue, or else taking that bit out and putting it into a new I-D.) From nobody Mon Apr 6 21:21:47 2020 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 C0C973A1528; Mon, 6 Apr 2020 21:21:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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 J8yFpQPEIfW6; Mon, 6 Apr 2020 21:21:44 -0700 (PDT) Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c]) (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 61F113A1524; Mon, 6 Apr 2020 21:21:44 -0700 (PDT) Received: by mail-ed1-x52c.google.com with SMTP id cw6so2290461edb.9; Mon, 06 Apr 2020 21:21:44 -0700 (PDT) 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; bh=9hiUXT1puQLLa+O0ju4KTqvlVXGPaMtbDSqXnr98j/c=; b=LStpseo4a56CDQJA6OwnB2KXIBYCMd8vne5ZdIazdD3QEEqx5hksk3cJQge3JcIPML LfVDcR/kuCpds+wtcPSW+8641okEYz8ZY0qSNuEiCD6NOMBHR7m/xKKvlC7k0VJnlX++ PaBP9ZUW+i03/4XK/B+Fec6S+rKYLCbN2CRxKP9O78T4MWDTnYx759F3iSn2XVToHd8f 09gBuJMp2V/axL/kiIc+MFdGymlR5AyNTHtr1ECt5sSECOyImCpp7cEW8hxdVtf+uLdr Kp+H5WElvF525X59+8dAmOcOhX65qPO+B5zETX3S2uEt8ZFdYBqxH1EtCT7p57QMfLHS qpew== 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; bh=9hiUXT1puQLLa+O0ju4KTqvlVXGPaMtbDSqXnr98j/c=; b=EO0njosqF/AebfEOZ0nlR0w/D+UBN11qDfoiZm1C9sZMVFsmhXQl5p0UFQe+4ZX4Sf T84RyAdPZlQI34YZz1TZUGqLW0zB7ifgpNEKhMUXgFoK22nTbaJxJuvuS11jLO0qNnTF GThvpAHxZog5XLm2NgOKNIxDYyfx7k+78yi2G5DRwdRr7/MnRMlVMlp3LoCQ8neV7Kse Efp75pbNbYlpm+DuGVIrX11l64PamS//0aWkdr7HzQ4mazH1nF5N1np1v3h8t4QUmm+H zX3Od2/4DMwU9mN29W4LxxY7B/7eUJFQ9l58zhL7vHUdvL2g6AP9j9ZSE3i4Ojud0JuO QWig== X-Gm-Message-State: AGi0PuZ9ydT0nlvXwAKLz3Gqd6R7LJKC3JDJhAyCyskfxVHiybQlslKO OdE07AGuK9ChaAObvvXtW5wRcfZEVt76C/r9lBN0UQ== X-Google-Smtp-Source: APiQypJFmcgPQYDARhUNMrngCxollU3Yiu4XbmlU7vrN1F+3TZjuCCfS16PxnSJk8+WZLiYCSCQGAYhjYqHDd5ytl4c= X-Received: by 2002:aa7:cf89:: with SMTP id z9mr331641edx.203.1586233302482; Mon, 06 Apr 2020 21:21:42 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?Q?Magnus_Nystr=C3=B6m?= Date: Mon, 6 Apr 2020 21:21:31 -0700 Message-ID: To: secdir@ietf.org, draft-iesg-nomcom-eligibility-2020@ietf.org Content-Type: multipart/alternative; boundary="0000000000008683fc05a2abb809" Archived-At: Subject: [secdir] Secdir review of draft-iesg-nomcom-eligibility-2020-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: Tue, 07 Apr 2020 04:21:46 -0000 --0000000000008683fc05a2abb809 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 describes procedures for forming the 2021 NomCom between IETF 107 and IETF 108. The document is purely procedural, and as such, pose no security considerations. -- Magnus --0000000000008683fc05a2abb809 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
<= div class=3D"gmail_quote">
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 describes procedures for forming the 2021= NomCom between IETF 107 and IETF 108. The document is purely procedural, a= nd as such, pose no security considerations.
    =
    -- Magnus
    --0000000000008683fc05a2abb809-- From nobody Wed Apr 8 08:48:49 2020 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 25FED3A0BAC; Wed, 8 Apr 2020 08:48:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.102 X-Spam-Level: *** X-Spam-Status: No, score=3.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_SUMOF=5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 qDOUk5e6Hg6u; Wed, 8 Apr 2020 08:48:32 -0700 (PDT) Received: from host105.olm1.com (host105.olm1.com [72.236.255.15]) (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 3D2263A0BA1; Wed, 8 Apr 2020 08:48:29 -0700 (PDT) Received: from HERTELLT (cpe-98-5-223-142.buffalo.res.rr.com [98.5.223.142]) by host105.olm1.com (Postfix) with ESMTPSA id 9DB22B93C3E; Wed, 8 Apr 2020 11:48:27 -0400 (EDT) From: To: "'Benjamin Kaduk'" , "'Barry Leiba'" Cc: "'Roni Even \(A\)'" , "'The IESG'" , "'Catherine Meadows'" , "'IETF SecDir'" , , "'Ali Begen'" , , , "'Dave Satterlee \(Vocal\)'" , "'IETF discussion list'" , , References: <001601d57af9$405efcf0$c11cf6d0$@vocal.com> <6E58094ECC8D8344914996DAD28F1CCD23D79BC0@DGGEMM506-MBX.china.huawei.com> <034a01d58a73$f4d3a1c0$de7ae540$@vocal.com> <037e01d58a92$72287510$56795f30$@vocal.com> <20191101001153.GQ88302@kduck.mit.edu> <06e101d59f15$ee937b30$cbba7190$@vocal.com> <20191125064606.GL32847@mit.edu> <00c601d5e339$965ebd90$c31c38b0$@vocal.com> <20200214194321.GF43385@kduck.mit.edu> In-Reply-To: <20200214194321.GF43385@kduck.mit.edu> Date: Wed, 8 Apr 2020 11:48:26 -0400 Message-ID: <002b01d60dbd$25675f80$70361e80$@vocal.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_002C_01D60D9B.9E56D0F0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQLglFUw/9Hrg4xFnJGl+gKOw+IttgKP/a5DAUK4sQ4C/qBe9QJw6xekAqUwBBcB6AFNSwEOtkf1AdJM/WIBsvGQ0QGhq9LkpYGDUMA= Content-Language: en-us Archived-At: Subject: Re: [secdir] Benjamin Kaduk's Discuss on draft-ietf-payload-tsvcis-03: (with DISCUSS and COMMENT) 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, 08 Apr 2020 15:48:41 -0000 This is a multipart message in MIME format. ------=_NextPart_000_002C_01D60D9B.9E56D0F0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_002D_01D60D9B.9E56D0F0" ------=_NextPart_001_002D_01D60D9B.9E56D0F0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Ben, With this social distancing situation, I'm finally catching up on open = items myself. I have made the changes as we have discussed and = incorporated your suggestions. I believe the changes are fully = contained in the two paragraphs below: Section 2 (last paragraph) - Clarification for octet count (was) In order to accommodate a varying amount of TSVCIS augmented speech data, it is only necessary to specify the number of octets containing the packed TSVCIS parameters. The encoding to do so is presented in Section 3.2. TSVCIS specifically uses the NRL VDR in two configurations using 15 and 35 packed octet parameters [TSVCIS]. =20 (now) In order to accommodate a varying amount of TSVCIS augmented speech data, an octet count specifies the number of octets representing the packed TSVCIS parameters. The encoding to do so is presented in Section 3.2. TSVCIS specifically uses the NRL VDR in two configurations using a fixed set of 15 and 35 packed octet parameters in a standardized order [TSVCIS]. =20 Section 3.1 (first sentence in last paragraph) - Clarification for CODA, = CODB (was) It should be noted that CODB for MELPe 600 bps mode MAY deviate from the value in Table 1 when bit 55 is used as an end-to-end framing bit. (now) It should be noted that CODB for MELPe 600 bps mode MAY deviate from the value in Table 1 when bit 55 is used as an alternating 1/0 end-to-end framing bit. =20 Ben, I believe this addresses your comments and requests for = clarifications as per our email discussion chain below. Thanks for you comments and with your concurrence (and my home = computer's cooperation), I will post a new draft hopefully acceptable = for final approval. Regards to all and stay on the good side of Darwin. Victor -----Original Message----- From: Benjamin Kaduk =20 Sent: Friday, February 14, 2020 2:43 PM To: victor.demjanenko@vocal.com; 'Barry Leiba' Cc: 'Roni Even (A)' ; 'The IESG' ; = 'Catherine Meadows' ; 'IETF SecDir' = ; draft-ietf-payload-tsvcis@ietf.org; 'Ali Begen' = ; avtcore-chairs@ietf.org; avt@ietf.org; = 'Dave Satterlee (Vocal)' ; 'IETF discussion = list' ; draft-ietf-payload-tsvcis.all@ietf.org Subject: Re: Benjamin Kaduk's Discuss on draft-ietf-payload-tsvcis-03: = (with DISCUSS and COMMENT) Hi Barry, As Victor notes, this one was/is waiting on me; he did reply (offlist) = on 15 January but I seem to have missed it amid a deluge of other mail that = arrived at that time. Thanks for the reminder, and thanks Victor for = re-sending the comments. (inline) On Fri, Feb 14, 2020 at 08:20:54AM -0500, victor.demjanenko@vocal.com = wrote: > HI Barry, >=20 > Thanks for recalling this was still outstanding. I had emailed Ben = just after the holidays and did not realize we had no response. The = below is what we suggested to Ben to address concerns he raised. >=20 > -------------------- > Hi Ben, >=20 > Hope your holidays were good. Our were both good and busy. = Deliveries for two NASA projects and the holidays kept us from = responding sooner. But we do want to get this draft completed. >=20 > With your permission, I=E2=80=99d like to address your comments = directly, resolve what changes we should make and then publish a new = version with a summary of our out-of-band discussions. We don=E2=80=99t = have a lot of experience with drafting such documents and would like to = know exactly what is needed to make this draft acceptable. >=20 > I believe there are two comments/issues to address: >=20 > 1) CODA, CODB >=20 > Your comment ends by stating: =E2=80=9C(Or, of course, the use of = CODB as an alternating 1/0 bit as the framing usage could be documented = instead.)=E2=80=9D We can do this as follows: >=20 > (original) > It should be noted that CODB for MELPe 600 bps mode MAY deviate from > the value in Table 1 when bit 55 is used as an end-to-end framing > bit. Frame decoding would remain distinct as CODA being zero on its > own would indicate a 7-byte frame for either 2400 or 600 bps rate = and > the use of 600 bps speech coding could be deduced from the RTP > timestamp (and anticipated by the SDP negotiations). >=20 > (adding =E2=80=9Calternating 1/0=E2=80=9D) > It should be noted that CODB for MELPe 600 bps mode MAY deviate from > the value in Table 1 when bit 55 is used as an alternating 1/0 = end-to-end framing > bit. Frame decoding would remain distinct as CODA being zero on its > own would indicate a 7-byte frame for either 2400 or 600 bps rate = and > the use of 600 bps speech coding could be deduced from the RTP > timestamp (and anticipated by the SDP negotiations). >=20 > I think this change would be sufficient to address your concern about = what to expect for CODB. This looks like the minimal sufficient change, yes. (I use "minimal" because I would say more if I was writing it, but I don't think I can = insist that you write it the way I would -- it's your document after = all!) > 2. Packing and unpacking >=20 > You are correct that I am trying to vaguely describe a middle layer = shim that is neither RTP nor speech coder. So it definitely does need = to be clear. The vagueness comes from the speech coder description = being a FOUO document. Its now unclassified so I can potentially say = more (and I did make some enhancements of the parameter description = already). =20 >=20 > So I am trying to understand exactly what you think is vague in our = current description: >=20 > TSVCIS augmented speech data is derived from the signal processing > and data already performed by the MELPe speech coder. For the > purposes of this specification, only the general parameter nature = of > TSVCIS will be characterized. Depending on the bandwidth available > (and FEC requirements), a varying number of TSVCIS-specific speech > coder parameters need to be transported. These are first = byte-packed > and then conveyed from encoder to decoder. >=20 > Byte packing of TSVCIS speech data into packed parameters is > processed as per the following example: >=20 > Three-bit field: bits A, B, and C (A is MSB, C is LSB) > Five-bit field: bits D, E, F, G, and H (D is MSB, H is LSB) >=20 > MSB LSB > 0 1 2 3 4 5 6 7 > +------+------+------+------+------+------+------+------+ > | H | G | F | E | D | C | B | A |=20 > +------+------+------+------+------+------+------+------+ >=20 > This packing method places the three-bit field "first" in the = lowest > bits followed by the next five-bit field. Parameters may be split > between octets with the most significant bits in the earlier octet. > Any unfilled bits in the last octet MUST be filled with zero. [not actually relevant to the Discuss part, but if there is always = exactly one 3-bit parameter and one 5-bit parameter, then this text = allowing splitting across octets will never be used and is potentially = confusing to mention.] > In order to accommodate a varying amount of TSVCIS augmented speech > data, it is only necessary to specify the number of octets = containing > the packed TSVCIS parameters. The encoding to do so is presented=20 > in I think the "only necessary to specify the number of octets" is the key = stumbling point, for me -- I need to know the number of octets as well = as the order of the parameters within the list, which is more = information than just the number of octets. > Section 3.2. TSVCIS specifically uses the NRL VDR in two > configurations using 15 and 35 packed octet parameters [TSVCIS]. =20 I think I failed to internalize the "two configurations using 15 and 35 = packed octet parameters" the first time I read the document, as this = does help give the reader a clue that [TSVCIS] gives a good picture of = what parameters go where. So it seems like we could easily append to = that, for "using a fixed set of 15 and 35 packed octet parameters in a = fixed order [TSVCIS]" and that would resolve my concerns. > The speech coder description of the parameters is the following: >=20 > =20 >=20 > So the three bit pitch is first (bits 56 to 58), followed by a five = bit amplitude (bits 59 to 63) and then an array of spectral components, = each 8-bit wide (starting at bit 64). [And maybe TSVCIS specifes that the spectral components are derived from = some fundamental harmonic decomposition that naturally quantizes to a = number-of-parameters/accuracy tradeoff with a natural order. If so, we = could also rely on that instead of my proposed change above; let me know = if you want to explore that path further.] > Based on this information, I=E2=80=99m not sure what we should add to = our=20 > draft to make the description of packing/unpacking clearer. Can you=20 > make any suggestions or does this table help you with what you did not = > know? (I don=E2=80=99t think I should put this table into the draft = RFC=20 > however.) Hopefully the above helps to clarify. Thanks, and sorry for the delay. -Ben > Thanks for your attention and comments. >=20 > Victor & Dave >=20 >=20 >=20 > -----Original Message----- > From: Barry Leiba > Sent: Friday, February 14, 2020 7:38 AM > To: Benjamin Kaduk > Cc: victor.demjanenko@vocal.com; Roni Even (A) ; = > The IESG ; Catherine Meadows=20 > ; IETF SecDir ;=20 > draft-ietf-payload-tsvcis@ietf.org; Ali Begen=20 > ; avtcore-chairs@ietf.org; avt@ietf.org;=20 > Dave Satterlee (Vocal) ; IETF discussion=20 > list ; draft-ietf-payload-tsvcis.all@ietf.orgygv=20 > Subject: Re: Benjamin Kaduk's Discuss on draft-ietf-payload-tsvcis-03: = > (with DISCUSS and COMMENT) >=20 > This is still outstanding, since November. Victor, where are we on = this one? >=20 > Barry >=20 > On Mon, Nov 25, 2019 at 1:46 AM Benjamin Kaduk wrote: > > > > Hi Victor, > > > > On Tue, Nov 19, 2019 at 03:14:21PM -0500, = victor.demjanenko@vocal.com wrote: > > > Hi Ben, > > > > > > Sorry I overlooked sending you a response. I would like to=20 > > > address the two concerns you have by explaining what the speech = coders are doing. > > > > Thanks for the extra clarifications. To supply one of my own: I'm=20 > > not concerned that the protocol doesn't work as implemented, but=20 > > just want to make sure that the document includes enough information = > > to admit new implementations without guesswork. That is to say,=20 > > "either tell me how to do it or tell me where to look that tells me = how to do it". > > > > > WRT to 600 bps MELP, there is one TSVCIS mode that uses one bit=20 > > > beyond the 54-bit frame for MELP 600 as a frame sync which = alternates between frames. > > > With two or more MELP 600bps frames in one RTP packet, if any=20 > > > frame indicates 600 bps by CODA being 0 and CODB being 1, then we=20 > > > know the stream is 600bps. If there is a single frame in an RTP=20 > > > packet, you can still deduce this by looking at every other RTP=20 > > > packet (every other MELP 600bps > > > frame) and by the timestamp advance. Most likely the two ends=20 > > > would negotiate 600 bps in SDP anyways so there really should not=20 > > > be a problem. I know it's not pretty but its workable. I hope=20 > > > this explanation helps you with the concerns for this issue. > > > > In this case, the use as an "end-to-end framing bit" (i.e., the=20 > > alternating behavior you describe above) is not explicitly stated;=20 > > one might imagine a scheme where the framing usage is to have the=20 > > bit cycle through 1, 1, 0, and 0, or some other scheme. I'd suggest = > > to note in the document that if any instance of (CODA, CODB) =3D=3D = (0,=20 > > 1) is observed, then the 600bps mode is in use. It might also be=20 > > helpful to include the observation that two successive MELPe=20 > > payloads with CODA =3D=3D CODB =3D=3D 0 indicates the 2400bps mode = (and that=20 > > seeing them in a single RTP packet is decisive, whereas additional=20 > > information about packet non-loss would be needed in the=20 > > one-MELPe-frame-per-RTP-packet case), but that would be a fair bit=20 > > of additional text and might be diminishing returns. (Or, of=20 > > course, the use of CODB as an alternating 1/0 bit as the framing=20 > > usage could be documented > > instead.) > > > > > As for the TSVCIS parameter packing/unpacking, this is really=20 > > > simple. There is exactly on three bit parameter, exactly one five = > > > bit parameter and a variable number of eight bit parameters. In=20 > > > our view, the speech coder itself (or a wrapper for it) is=20 > > > responsible for preparing the block of octets. RTP then just=20 > > > transports it. On receive, the complementary wrapper reverses the = packing operation. > > > I hope this clarifies and explains the simplicity. > > > > That's exactly what I expected to happen; however, it's not what I=20 > > believe the current text of the document is describing. =20 > > Specifically, I think that the current text implies that the=20 > > "preparing the block of octets" and "complementary wrapper reverses=20 > > the packing operation" are supposed to be part of the RTP payload=20 > > format that this document describes, but this document does not have = > > enough information to actually perform those operations reversibly. = > > If the packing is to be done in the speech coder, then this document = > > doesn't need to talk about the packing at all (e.g., at the end of=20 > > Section 2); if we need to keep the packing/wrapper in this document=20 > > then we need to indicate that there's a defined priority order for=20 > > the (8-octet) TSVCIS parameters in the TSVCIS references, to allow = the packing/unpacking to be deterministic. > > > > Thanks, > > > > Ben > > > > > > > > -----Original Message----- > > > From: Benjamin Kaduk > > > Sent: Thursday, October 31, 2019 8:12 PM > > > To: Barry Leiba > > > Cc: victor.demjanenko@vocal.com; Roni Even (A)=20 > > > ; The IESG ; Catherine=20 > > > Meadows ; IETF SecDir=20 > > > ; draft-ietf-payload-tsvcis@ietf.org; Ali Begen=20 > > > ; avtcore-chairs@ietf.org;=20 > > > avt@ietf.org; Dave Satterlee (Vocal) ;=20 > > > IETF discussion list ;=20 > > > draft-ietf-payload-tsvcis.all@ietf.org > > > Subject: Re: Benjamin Kaduk's Discuss on > > > draft-ietf-payload-tsvcis-03: (with DISCUSS and COMMENT) > > > > > > I don't think so, unfortunately. > > > > > > I do see the clarification about CODB's potential for deviation=20 > > > from Table 1, that only the 600 bps MELPe is allowed to deviate,=20 > > > and that CODA gets us to "it's one of 2400 or 600 bps" and the RTP = > > > timestamp disambiguates that > > > 600 bps is in use. But, it seems that this means that the=20 > > > recipient in general should not rely on CODB to differentiate 600=20 > > > from 2400 bps, and instead is more robustly implemented by=20 > > > *always* using the RTP timestamp to detect 600 bps, since that=20 > > > will always work and CODB will sometimes not work under conditions = > > > not fully specified here. So, if we are unwilling or unable to=20 > > > clarify what those conditions are (e.g., whether at a minimum=20 > > > mutual agreement is required), then I think we need to describe=20 > > > this procedure of consulting the RTP timestamp as the default = behavior and avoid giving the impression that CODB should be used to do = so. > > > > > > Additionally, I don't see anything to address my concern about=20 > > > TSVCIS parameter decoding. To be clear, the procedure I see this=20 > > > document describing is that: > > > - TSVCIS gives parameters (and their lengths in bits) to the codec > > > described in this document > > > - this document specifies how to densely encode those parameters = into a > > > byetstream > > > - RTP transmits that encoded bytestream to the peer > > > - the codec specified by this is responsible for turning that = encoded > > > bystream back into a list of TSVCIS parameters (and their length = > > > in bits) > > > > > > I don't see how that last step is attainable with only the=20 > > > information provided by this document. I *assume* that one of the = > > > TSVCIS specifications has a canonical (ordered) listing of=20 > > > parameters, and that the list of parmeters given to this codec in=20 > > > the first step will always be an initial prefix of that list, but=20 > > > that's just me guessing at how to make sense of the stated=20 > > > procedure given insufficient information. I don't think it's=20 > > > appropriate to make the reader of an RFC guess at what to do; we=20 > > > need to either say how to do it or give a pointer to an external = reference that does. > > > > > > -Ben > > > > > > On Tue, Oct 29, 2019 at 02:26:09PM -0400, Barry Leiba wrote: > > > > Ben, does the -04 version address everything? > > > > > > > > Barry > > > > > > > > On Thu, Oct 24, 2019 at 1:42 PM = wrote: > > > > > > > > > > I forgot to address security comments in one email. The = changes are: > > > > > > > > > > Section 8, second paragraph - Suggested edit by reviewer > > > > > > > > > > (was) > > > > > This RTP payload format and the TSVCIS decoder do not = exhibit any > > > > > significant non-uniformity in the receiver-side = computational > > > > > complexity for packet processing and thus are unlikely to = pose a > > > > > denial-of-service threat due to the receipt of pathological = data. > > > > > Additionally, the RTP payload format does not contain any = active > > > > > content. > > > > > > > > > > (now) > > > > > This RTP payload format and the TSVCIS decoder, to the best = of our > > > > > knowledge, do not exhibit any significant non-uniformity in = the > > > > > receiver-side computational complexity for packet = processing and thus > > > > > are unlikely to pose a denial-of-service threat due to the = receipt of > > > > > pathological data. Additionally, the RTP payload format = does not > > > > > contain any active content. > > > > > > > > > > > > > > > Section 8, third paragraph - Suggested edit by reviewer > > > > > > > > > > (was) > > > > > Please see the security considerations discussed in = [RFC6562] > > > > > regarding VAD and its effect on bitrates. > > > > > > > > > > (now) > > > > > Please see the security considerations discussed in = [RFC6562] > > > > > regarding Voice Activity Detect (VAD) and its effect on = bitrates. > > > > > > > > > > Victor > > > > > > > > > > -----Original Message----- > > > > > From: victor.demjanenko@vocal.com=20 > > > > > > > > > > Sent: Thursday, October 24, 2019 10:05 AM > > > > > To: 'Roni Even (A)' ; 'Benjamin Kaduk' > > > > > ; 'The IESG' > > > > > Cc: draft-ietf-payload-tsvcis@ietf.org; 'Ali Begen' > > > > > ; avtcore-chairs@ietf.org;=20 > > > > > avt@ietf.org; 'Dave Satterlee (Vocal)' > > > > > > > > > > Subject: RE: Benjamin Kaduk's Discuss on > > > > > draft-ietf-payload-tsvcis-03: (with DISCUSS and COMMENT) > > > > > > > > > > Hi Everyone, > > > > > > > > > > First we want to thank everyone for their review and comments=20 > > > > > for this > > > draft RFC. We believe we reviewed all the comments and=20 > > > suggestions and incorporated them adequately in the next draft=20 > > > (04). We'd like to send out this list of exact changes in case=20 > > > anyone has additional comments or thinks the clarifications are=20 > > > inadequate. We would be most happy to address concerns before = publishing draft 04 tomorrow. > > > > > > > > > > With so many emails from a half dozen or more reviewers, we=20 > > > > > apologize > > > that we cannot address each sender individually. We hope this=20 > > > detail is sufficient for everyone. > > > > > > > > > > Again, many thanks to all. > > > > > > > > > > Victor & Dave > > > > > > > > > > -------------------------------------------------------------- > > > > > -- > > > > > ---- > > > > > -------------------------- > > > > > > > > > > Section 1.1 - Suggested reference to RFC 8088 added. > > > > > > > > > > (was) > > > > > Best current practices for writing an RTP payload format > > > > > specification were followed [RFC2736]. > > > > > > > > > > (now) > > > > > Best current practices for writing an RTP payload format > > > > > specification were followed [RFC2736] [RFC8088]. > > > > > > > > > > > > > > > Section 2, paragraphs 3 and 4 - Suggested edits by reviewers > > > > > > > > > > (was) > > > > > In addition to the augmented speech data, the TSVCIS = specification > > > > > identifies which speech coder and framing bits are to be = encrypted, > > > > > and how they are protected by forward error correction = (FEC) > > > > > techniques (using block codes). At the RTP transport = layer, only the > > > > > speech coder related bits need to be considered and are = conveyed in > > > > > unencrypted form. In most IP-based network deployments, = standard > > > > > link encryption methods (SRTP, VPNs, FIPS 140 link = encryptors or Type > > > > > 1 Ethernet encryptors) would be used to secure the RTP = speech > > > > > contents. Further, it is desirable to support the highest = voice > > > > > quality between endpoints which is only possible without = the overhead > > > > > of FEC. > > > > > > > > > > TSVCIS augmented speech data is derived from the signal = processing > > > > > and data already performed by the MELPe speech coder. For = the > > > > > purposes of this specification, only the general parameter = nature of > > > > > TSVCIS will be characterized. Depending on the bandwidth = available > > > > > (and FEC requirements), a varying number of TSVCIS specific = speech > > > > > coder parameters need to be transported. These are first = byte-packed > > > > > and then conveyed from encoder to decoder. > > > > > > > > > > (now) > > > > > In addition to the augmented speech data, the TSVCIS = specification > > > > > identifies which speech coder and framing bits are to be = encrypted, > > > > > and how they are protected by forward error correction = (FEC) > > > > > techniques (using block codes). At the RTP transport = layer, only the > > > > > speech-coder-related bits need to be considered and are = conveyed in > > > > > unencrypted form. In most IP-based network deployments, = standard > > > > > link encryption methods (SRTP, VPNs, FIPS 140 link = encryptors or Type > > > > > 1 Ethernet encryptors) would be used to secure the RTP = speech > > > > > contents. > > > > > > > > > > TSVCIS augmented speech data is derived from the signal = processing > > > > > and data already performed by the MELPe speech coder. For = the > > > > > purposes of this specification, only the general parameter = nature of > > > > > TSVCIS will be characterized. Depending on the bandwidth = available > > > > > (and FEC requirements), a varying number of TSVCIS-specific = speech > > > > > coder parameters need to be transported. These are first = byte-packed > > > > > and then conveyed from encoder to decoder. > > > > > > > > > > > > > > > Section 3, last sentence paragraph 3 - Suggested edit by=20 > > > > > reviewer > > > > > > > > > > (was) > > > > > When more than one codec data frame is > > > > > present in a single RTP packet, the timestamp is, as = always, that of > > > > > the oldest data frame represented in the RTP packet. > > > > > > > > > > (now) > > > > > When more than one codec data frame is > > > > > present in a single RTP packet, the timestamp specified is = that of > > > > > the oldest data frame represented in the RTP packet. > > > > > > > > > > > > > > > Section 3.1, last paragraph - Clarified permission for MELP=20 > > > > > 600 end-to-end framing bit > > > > > > > > > > (was) > > > > > It should be noted that CODB for both the 2400 and 600 bps = modes MAY > > > > > deviate from the values in Table 1 when bit 55 is used as = an end-to- > > > > > end framing bit. Frame decoding would remain distinct as = CODA being > > > > > zero on its own would indicate a 7-byte frame for either = rate and the > > > > > use of 600 bps speech coding could be deduced from the RTP = timestamp > > > > > (and anticipated by the SDP negotiations). > > > > > > > > > > (now) > > > > > It should be noted that CODB for MELPe 600 bps mode MAY = deviate from > > > > > the value in Table 1 when bit 55 is used as an end-to-end = framing > > > > > bit. Frame decoding would remain distinct as CODA being = zero on its > > > > > own would indicate a 7-byte frame for either 2400 or 600 = bps rate and > > > > > the use of 600 bps speech coding could be deduced from the = RTP > > > > > timestamp (and anticipated by the SDP negotiations). > > > > > > > > > > > > > > > Section 3.2, first paragraph - Clarifications requested by=20 > > > > > reviewers > > > > > > > > > > (was) > > > > > The TSVCIS augmented speech data as packed parameters MUST = be placed > > > > > immediately after a corresponding MELPe 2400 bps payload in = the same > > > > > RTP packet. The packed parameters are counted in octets = (TC). In > > > > > the preferred placement, shown in Figure 6, a single = trailing octet > > > > > SHALL be appended to include a two-bit rate code, CODA and = CODB, > > > > > (both bits set to one) and a six-bit modified count (MTC). = The > > > > > special modified count value of all ones (representing a = MTC value of > > > > > 63) SHALL NOT be used for this format as it is used as the = indicator > > > > > for the alternate packing format shown next. In a standard > > > > > implementation, the TSVCIS speech coder uses a minimum of = 15 octets > > > > > for parameters in octet packed form. The modified count = (MTC) MUST > > > > > be reduced by 15 from the full octet count (TC). Computed = MTC =3D TC- > > > > > 15. This accommodates a maximum of 77 parameter octets = (maximum > > > > > value of MTC is 62, 77 is the sum of 62+15). > > > > > > > > > > (now) > > > > > The TSVCIS augmented speech data as packed parameters MUST = be placed > > > > > immediately after a corresponding MELPe 2400 bps payload in = the same > > > > > RTP packet. The packed parameters are counted in octets = (TC). The > > > > > preferred placement SHOULD be used for TSVCIS payloads with = TC less > > > > > than or equal to 77 octets, is shown in Figure 6. In the = preferred > > > > > placement, a single trailing octet SHALL be appended to = include a > > > > > two-bit rate code, CODA and CODB, (both bits set to one) = and a six- > > > > > bit modified count (MTC). The special modified count value = of all > > > > > ones (representing a MTC value of 63) SHALL NOT be used for = this > > > > > format as it is used as the indicator for the alternate = packing > > > > > format shown next. In a standard implementation, the = TSVCIS speech > > > > > coder uses a minimum of 15 octets for parameters in octet = packed > > > > > form. The modified count (MTC) MUST be reduced by 15 from = the full > > > > > octet count (TC). Computed MTC =3D TC-15. This = accommodates a maximum > > > > > of 77 parameter octets (maximum value of MTC is 62, 77 is = the sum of > > > > > 62+15). > > > > > > > > > > > > > > > Section 3.3, first paragraph - Suggested edit by reviewer > > > > > > > > > > (was) > > > > > A TSVCIS RTP packet consists of zero or more TSVCIS coder = frames > > > > > (each consisting of MELPe and TSVCIS coder data) followed = by zero or > > > > > one MELPe comfort noise frame. The presence of a comfort = noise frame > > > > > can be determined by its rate code bits in its last octet. > > > > > > > > > > (now) > > > > > A TSVCIS RTP packet payload consists of zero or more = consecutive > > > > > TSVCIS coder frames (each consisting of MELPe 2400 and = TSVCIS coder > > > > > data), with the oldest frame first, followed by zero or one = MELPe > > > > > comfort noise frame. The presence of a comfort noise frame = can be > > > > > determined by its rate code bits in its last octet. > > > > > > > > > > > > > > > Section 3.3, fourth paragraph - Clarification requested by=20 > > > > > reviewers > > > > > > > > > > (was) > > > > > TSVCIS coder frames in a single RTP packet MAY be of = different coder > > > > > bitrates. With the exception for the variable length = TSVCIS > > > > > parameter frames, the coder rate bits in the trailing byte = identify > > > > > the contents and length as per Table 1. > > > > > > > > > > (now) > > > > > TSVCIS coder frames in a single RTP packet MAY have varying = TSVCIS > > > > > parameter octet counts. Its packed parameter octet count = (length) is > > > > > indicated in the trailing byte(s). All MELPe frames in a = single RTP > > > > > packet MUST be of the same coder bitrate. For all MELPe = coder > > > > > frames, the coder rate bits in the trailing byte identify = the > > > > > contents and length as per Table 1. > > > > > > > > > > > > > > > Section 4.1 - Editor note removed > > > > > > > > > > > > > > > Section 4.1 - Change controller is now > > > > > > > > > > (now) > > > > > Change controller: IETF, contact > > > > > > > > > > > > > > > Section 5, first paragraph - Suggested edits by reviewers > > > > > > > > > > (was) > > > > > A primary application of TSVCIS is for radio communications = of voice > > > > > conversations, and discontinuous transmissions are normal. = When > > > > > TSVCIS is used in an IP network, TSVCIS RTP packet = transmissions may > > > > > cease and resume frequently. RTP synchronization source = (SSRC) > > > > > sequence number gaps indicate lost packets to be filled by = PLC, while > > > > > abrupt loss of RTP packets indicates intended discontinuous > > > > > transmissions. > > > > > > > > > > (now) > > > > > A primary application of TSVCIS is for radio communications = of voice > > > > > conversations, and discontinuous transmissions are normal. = When > > > > > TSVCIS is used in an IP network, TSVCIS RTP packet = transmissions may > > > > > cease and resume frequently. RTP synchronization source = (SSRC) > > > > > sequence number gaps indicate lost packets to be filled by = Packet > > > > > Loss Concealment (PLC), while abrupt loss of RTP packets = indicates > > > > > intended discontinuous transmissions. Resumption of voice > > > > > transmission SHOULD be indicated by the RTP marker bit (M) = set to 1. > > > > > > > > > > > > > > > Section 10 - Added reference > > > > > > > > > > (added) > > > > > [RFC8088] Westerlund, M., "How to Write an RTP Payload = Format", > > > > > RFC 8088, DOI 10.17487/RFC8088, May 2017, > > > > > . > > > > > > > > > > -------------------------------------------------------------- > > > > > -- > > > > > ---- > > > > > ----------------------------- > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Roni Even (A) > > > > > Sent: Sunday, October 6, 2019 2:09 AM > > > > > To: victor.demjanenko@vocal.com; 'Benjamin Kaduk'=20 > > > > > ; 'The IESG' > > > > > Cc: draft-ietf-payload-tsvcis@ietf.org; 'Ali Begen' > > > > > ; avtcore-chairs@ietf.org;=20 > > > > > avt@ietf.org; 'Dave Satterlee (Vocal)' > > > > > > > > > > Subject: RE: Benjamin Kaduk's Discuss on > > > > > draft-ietf-payload-tsvcis-03: (with DISCUSS and COMMENT) > > > > > > > > > > Hi, > > > > > About the reference to TSVCIS. > > > > > The RTP payload is about how to encapsulate the payload in an=20 > > > > > RTP > > > packet. The objective is to define how an RTP stack can insert the = > > > tsvcis frames and extract the tsvcis frames from the RTP packet. > > > Typically it is not required to understand the payload structure=20 > > > in order to be able to perform the encapsulation. > > > > > This is why the reference to the payload is Informational and=20 > > > > > we did not require to have it publically available. If there=20 > > > > > is a need to understand the payload itself for the=20 > > > > > encapsulating than we need more information in the RTP payload = > > > > > specification and a publically available normative reference.=20 > > > > > I think this is not the case here > > > > > > > > > > Roni Even > > > > > > > > > > AVTCore co-chair (ex Payload) > > > > > > > > > > -----Original Message----- > > > > > From: victor.demjanenko@vocal.com=20 > > > > > [mailto:victor.demjanenko@vocal.com] > > > > > Sent: Saturday, October 05, 2019 12:18 AM > > > > > To: 'Benjamin Kaduk'; 'The IESG' > > > > > Cc: draft-ietf-payload-tsvcis@ietf.org; 'Ali Begen'; > > > avtcore-chairs@ietf.org; avt@ietf.org; 'Victor Demjanenko, Ph.D.'; = > > > 'Dave Satterlee (Vocal)' > > > > > Subject: RE: Benjamin Kaduk's Discuss on > > > > > draft-ietf-payload-tsvcis-03: (with DISCUSS and COMMENT) > > > > > > > > > > Everyone, > > > > > > > > > > Thanks for the comments. I think I mis-understood the=20 > > > > > ambiguity with > > > respect to to changing rates within a RTP packet. That was not=20 > > > plan. An RTP packet must have MELP speech frames of the same = rate. > > > What is possible is that the amount of augmented TSVCIS speech=20 > > > data may vary from one speech frame to the next. This allows for=20 > > > a dynamic VDR as suggested by the NRL paper. So an RTP packet may = > > > have varying TSVCIS data but must always have MELPe 2400 data. > > > > > > > > > > Again backwards parsing is necessary but the timestamp=20 > > > > > uniformly > > > increments 22.5msec per combined MELP/TSVCIS speech frame. > > > > > > > > > > The NRL is a good public reference on the VDR aspects. The=20 > > > > > actual > > > TSVCIS spec we had was FOUO so we could not replicate its detail. = > > > (I believe a later spec is public or at least partially public. I = > > > am trying to get this.) The opaque data is pretty obvious with = the TSVCIS spec in hand. > > > > > > > > > > We will address the issues/concerns raised next week. Other=20 > > > > > business > > > had priority. > > > > > > > > > > Thank you and enjoy the weekend. > > > > > > > > > > Regards, > > > > > > > > > > Victor & Dave > > > > > > > > > > -----Original Message----- > > > > > From: Benjamin Kaduk via Datatracker > > > > > Sent: Wednesday, October 2, 2019 10:40 PM > > > > > To: The IESG > > > > > Cc: draft-ietf-payload-tsvcis@ietf.org; Ali Begen=20 > > > > > ; avtcore-chairs@ietf.org;=20 > > > > > ali.begen@networked.media; avt@ietf.org > > > > > Subject: Benjamin Kaduk's Discuss on = draft-ietf-payload-tsvcis-03: > > > > > (with DISCUSS and COMMENT) > > > > > > > > > > Benjamin Kaduk has entered the following ballot position for > > > > > draft-ietf-payload-tsvcis-03: Discuss > > > > > > > > > > When responding, please keep the subject line intact and reply = > > > > > to all email addresses included in the To and CC lines. (Feel=20 > > > > > free to cut this introductory paragraph, however.) > > > > > > > > > > > > > > > Please refer to > > > > > https://www.ietf.org/iesg/statement/discuss-criteria.html > > > > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > > > > > > > > > > The document, along with other ballot positions, can be found = here: > > > > > https://datatracker.ietf.org/doc/draft-ietf-payload-tsvcis/ > > > > > > > > > > > > > > > > > > > > -------------------------------------------------------------- > > > > > -- > > > > > ---- > > > > > -- > > > > > DISCUSS: > > > > > -------------------------------------------------------------- > > > > > -- > > > > > ---- > > > > > -- > > > > > > > > > > I support Magnus' point about the time-ordering of adjacent=20 > > > > > frames in a > > > packet. > > > > > > > > > > Additionally, I am not sure that there's quite enough here to=20 > > > > > be > > > interoperably implementable. Specifically, we seem to be lacking=20 > > > a description of how an encoder or decoder knows which TSVCIS=20 > > > parameters, and in what order, to byte-pack or unpack, = respectively. > > > One might surmise that there is a canonical listing in [TSVCIS],=20 > > > but this document does not say that, and furthermore [TSVCIS] is = only listed as an informative reference. > > > (I couldn't get my hands on my copy, at least on short notice.) =20 > > > If we limited ourselves to treating the TSVCIS parameters as an=20 > > > entirely opaque blob (codec, convey these N octets to the peer=20 > > > with the appropriate one- or two-byte trailer for payload type=20 > > > identification and framing), that would be interoperably=20 > > > implementable, since the black-box bits are up to some other codec = to interpret. > > > > > > > > > > In a similar vein, we mention but do not completely specify=20 > > > > > the > > > potential for using CODB as an end-to-end framing bit, in Section > > > 3.1 (see Comment), which is not interoperably implementable = without further details. > > > > > > > > > > > > > > > -------------------------------------------------------------- > > > > > -- > > > > > ---- > > > > > -- > > > > > COMMENT: > > > > > -------------------------------------------------------------- > > > > > -- > > > > > ---- > > > > > -- > > > > > > > > > > Where is [TSVCIS] available? > > > > > > > > > > Is [NRLVDR] the same as > > > > > https://apps.dtic.mil/dtic/tr/fulltext/u2/a588068.pdf ? A URL = > > > > > in the > > > references would be helpful. > > > > > > > > > > Is additional TSVCIS data only present after 2400bps MELPe and = > > > > > the first > > > thing to get dropped under bandwidth pressure? The abstract and=20 > > > introduction imply this by calling out MELPe 2400 bps speech=20 > > > parameters explicitly, but Section 3 says that TSVCIS augments=20 > > > standard 600, 1200, and > > > 2400 bps MELP frames. > > > > > > > > > > It's helpful that Section 3.3 gives some general guidance for=20 > > > > > decoding > > > this payload type ("[t]he way to determine the number of=20 > > > TSVCIS/MELPe frames is to identify each frame type and length"),=20 > > > but I think some generic considerations would be very helpful to=20 > > > the reader much earlier, along the lines of "MELPe and TSVCIS data = > > > payloads are decoded from the end, using the CODA and CODB (and,=20 > > > if necessary, CODC and others) bits to determine the type of = payload. > > > For MELPe payloads the type also indicates the payload length,=20 > > > whereas for TSVCIS data an additional length field is present, in=20 > > > one of two possible formats. A TSVCIS coder frame consists of a=20 > > > MELPe data payload followed by zero or one TSVCIS data payload;=20 > > > after the TSVCIS payload's presence/length is determined, then the = > > > preceding MELPe payload can be determined and decoded. Per=20 > > > Section 3.3, multiple TSVCIS frames can be present in a single RTP = packet." > > > This (or something like it) would also serve to clarify the role = of the COD* bits, which is otherwise only implicitly introduced. > > > > > > > > > > Section 1.1 > > > > > > > > > > RFC 2736 is BCP 36 (but it's updated by RFC 8088 which is for=20 > > > > > some > > > reason an Informational document and not part of BCP 36?!). > > > > > > > > > > Section 2 > > > > > > > > > > In addition to the augmented speech data, the TSVCIS = specification > > > > > identifies which speech coder and framing bits are to be = encrypted, > > > > > and how they are protected by forward error correction = (FEC) > > > > > techniques (using block codes). At the RTP transport = layer, only the > > > > > speech coder related bits need to be considered and are = conveyed in > > > > > unencrypted form. In most IP-based network deployments,=20 > > > > > standard > > > > > > > > > > Am I reading this correctly that this text is just summarizing = > > > > > what's in > > > the TSVCIS spec in terms of what needs to be in unencrypted form,=20 > > > so the "only the speech coder related bits[...]" is not new=20 > > > information from this document? I'm not sure I agree with the=20 > > > conclusion, regardless -- won't the > > > (MELPe) speech coder bits be enough to convey the semantic content = > > > of the audio stream, something that one might desire to keep = confidential? > > > > > > > > > > link encryption methods (SRTP, VPNs, FIPS 140 link = encryptors or Type > > > > > 1 Ethernet encryptors) would be used to secure the RTP = speech > > > > > contents. Further, it is desirable to support the highest = voice > > > > > quality between endpoints which is only possible without = the overhead > > > > > of FEC. > > > > > > > > > > I think I'm missing a step in how this conclusion was reached. > > > > > > > > > > TSVCIS will be characterized. Depending on the bandwidth = available > > > > > (and FEC requirements), a varying number of TSVCIS specific = speech > > > > > coder parameters need to be transported. These are first = byte-packed > > > > > and then conveyed from encoder to decoder. > > > > > > > > > > Per the Discuss point, how do I know which parameters need to=20 > > > > > be > > > transported, and in what order? > > > > > > > > > > Byte packing of TSVCIS speech data into packed parameters = is > > > > > processed as per the following example: > > > > > > > > > > Three-bit field: bits A, B, and C (A is MSB, C is LSB) > > > > > Five-bit field: bits D, E, F, G, and H (D is MSB, H is > > > > > LSB) > > > > > > > > > > MSB = LSB > > > > > 0 1 2 3 4 5 6 7 > > > > > = +------+------+------+------+------+------+------+------+ > > > > > | H | G | F | E | D | C | B | A = | > > > > > =20 > > > > > +------+------+------+------+------+------+------+------+ > > > > > > > > > > This packing method places the three-bit field "first" in = the lowest > > > > > bits followed by the next five-bit field. Parameters may = be split > > > > > between octets with the most significant bits in the = earlier octet. > > > > > Any unfilled bits in the last octet MUST be filled with = zero. > > > > > > > > > > I agree with Adam that this is very unclear. A is the MSB of=20 > > > > > the > > > three-bit field but the LSB of the octet overall? > > > > > We probably need an example of splitting a parameter across=20 > > > > > octets as > > > well, to get the bit ordering right. > > > > > > > > > > Section 3.1 > > > > > > > > > > It should be noted that CODB for both the 2400 and 600 bps = modes MAY > > > > > deviate from the values in Table 1 when bit 55 is used as = an end-to- > > > > > end framing bit. Frame decoding would remain distinct as=20 > > > > > CODA being > > > > > > > > > > Where is the use of CODB as an end-to-end framing bit defined? = =20 > > > > > If we're > > > going to provide neither a complete description of how to do it=20 > > > nor a reference to a better description, we probably shouldn't = mention it at all. > > > > > > > > > > Section 3.2 > > > > > > > > > > RTP packet. The packed parameters are counted in octets = (TC). In > > > > > the preferred placement, shown in Figure 6, a single = trailing octet > > > > > SHALL be appended to include a two-bit rate code, CODA and=20 > > > > > CODB, > > > > > > > > > > I'd consider saying something about this being the preferred=20 > > > > > format > > > > > ("placement") due to its shorter length than the alternative,=20 > > > > > and say > > > that it "SHOULD be used for TSVCIS payloads with TC less than or=20 > > > equal to 77 octetes". > > > > > > > > > > Section 3.3 > > > > > > > > > > When a longer packetization interval is used, is that=20 > > > > > indicated by > > > signaling or RTP timestamps or otherwise? > > > > > > > > > > TSVCIS coder frames in a single RTP packet MAY be of = different coder > > > > > bitrates. With the exception for the variable length = TSVCIS > > > > > parameter frames, the coder rate bits in the trailing byte = identify > > > > > the contents and length as per Table 1. > > > > > > > > > > Maybe also note that the penultimate octet gives the length = there? > > > > > > > > > > Information describing the number of frames contained in an = RTP > > > > > packet is not transmitted as part of the RTP payload. The = way to > > > > > determine the number of TSVCIS/MELPe frames is to identify = each frame > > > > > type and length thereby counting the total number of octets = within > > > > > the RTP packet. > > > > > > > > > > terminology nit: if a frame is the combination of MELPe and=20 > > > > > TSVCIS > > > payload data units then there are two layres of decoding to get a=20 > > > length for the frame, since we have to get the TSVCIS length and = then the MELPe length. > > > > > > > > > > Section 4.2 > > > > > > > > > > Parameter "ptime" cannot be used for the purpose of=20 > > > > > specifying the > > > > > > > > > > nit: missing article ("The parameter") > > > > > > > > > > will be impossible to distinguish which mode is about to be = used > > > > > (e.g., when ptime=3D68, it would be impossible to = distinguish if the > > > > > packet is carrying one frame of 67.5 ms or three frames of = 22.5 ms). > > > > > > > > > > So how is the operating mode determined, then? > > > > > (I think this is the same question I asked above) > > > > > > > > > > Section 4.4 > > > > > > > > > > For example, if offerer bitrates are "2400,600" and answer = bitrates > > > > > are "600,2400", the initial bitrate is 600. If other = bitrates are > > > > > provided by the answerer, any common bitrate between the = offer and > > > > > answer MAY be used at any time in the future. Activation = of these > > > > > other common bitrates is beyond the scope of this document. > > > > > > > > > > It seems important to specify whether this requires a new O/A=20 > > > > > exchange > > > or can be done "spontaneously" by just encoding different frame = types. > > > > > (It seems like the latter is possible, on first glance, and=20 > > > > > this is implied by Section 3.3's discussion of mixing them in=20 > > > > > a single > > > > > packet.) > > > > > > > > > > Section 5 > > > > > > > > > > Please expand PLC at first use (not second). > > > > > > > > > > Section 6 > > > > > > > > > > I don't understand the PLC usage. Is the idea that a=20 > > > > > receiver, on > > > seeing an SSRC gap, constructs fictitious PLC frames to "fill the = gap" > > > > > and passes the resulting stream to the decoder? > > > > > > > > > > Section 8 > > > > > > > > > > and important considerations in [RFC7201]. Applications = SHOULD use > > > > > one or more appropriate strong security mechanisms. The = rest of this > > > > > section discusses the security-impacting properties of the = payload > > > > > format itself. > > > > > > > > > > I thought we described TSVCIS itself (much earlier in the > > > > > document) as > > > requiring encryption for some data; wouldn't that translate to a = "MUST" > > > > > here and not a "SHOULD"? > > > > > > > > > > > > > > > > > > > =20 ------=_NextPart_001_002D_01D60D9B.9E56D0F0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable RE: Benjamin Kaduk's Discuss on draft-ietf-payload-tsvcis-03: = (with DISCUSS and COMMENT)

    Hi = Ben,

    With this = social distancing situation, I'm finally catching up on open = items myself.  I have made the changes as we have discussed and = incorporated your = suggestions.  I believe the changes are fully contained in the two = paragraphs below:

    Section 2 (last = paragraph) - Clarification for octet count

    (was)

    In order to = accommodate a varying amount of TSVCIS augmented = speech

    data, it = is only necessary to specify the number of octets

    containing = the packed TSVCIS parameters.  The encoding to do so = is

    presented in = Section 3.2.  TSVCIS specifically uses the NRL VDR in = two

    configurations = using 15 = and 35 packed octet parameters [TSVCIS].  =

    (now)

    In order to = accommodate a varying amount of TSVCIS augmented = speech

    data, an = octet count specifies the number of octets = representing

    the packed = TSVCIS parameters.  The encoding to do so is presented = in

    Section = 3.2.  TSVCIS specifically uses the NRL VDR in two

    configurations = using a = fixed set of 15 and 35 packed octet

    parameters = in a standardized order [TSVCIS].  =


    Section 3.1 = (first sentence in last paragraph) - Clarification for CODA, = CODB

    (was)

    It should be = noted that CODB for MELPe 600 bps mode MAY deviate = from

    the value in = Table 1 when bit 55 is used as an end-to-end framing = bit.

    (now)

    It should be = noted that CODB for MELPe 600 bps mode MAY deviate = from

    the value in = Table 1 when bit 55 is used as an alternating = 1/0

    end-to-end = framing bit. 

    Ben, I believe = this addresses your comments and requests for clarifications as per our = email discussion chain below.

    Thanks for you = comments and with your concurrence (and my home computer's cooperation), = I will post a new draft hopefully acceptable for final = approval.

    Regards to all = and stay on = the good side of Darwin.

    Victor


    -----Original = Message-----

    From: Benjamin = Kaduk <kaduk@mit.edu>

    Sent: Friday, = February 14, 2020 2:43 PM

    To: = victor.demjanenko@vocal.com; 'Barry Leiba' = <barryleiba@computer.org>

    Cc: 'Roni Even = (A)' <roni.even@huawei.com>; 'The IESG' <iesg@ietf.org>; = 'Catherine Meadows' <catherine.meadows@nrl.navy.mil>; 'IETF = SecDir' <secdir@ietf.org>; draft-ietf-payload-tsvcis@ietf.org; = 'Ali Begen' <ali.begen@networked.media>; avtcore-chairs@ietf.org; = avt@ietf.org; 'Dave Satterlee (Vocal)' <Dave.Satterlee@vocal.com>; = 'IETF discussion list' <ietf@ietf.org>; = draft-ietf-payload-tsvcis.all@ietf.org

    Subject: Re: = Benjamin Kaduk's Discuss on draft-ietf-payload-tsvcis-03: (with DISCUSS = and COMMENT)

    Hi = Barry,

    As Victor = notes, this one was/is waiting on me; he did reply (offlist) = on

    15 January but = I seem to have missed it amid a deluge of other mail that arrived at = that time.  Thanks for the reminder, and thanks Victor for = re-sending the comments.

    (inline)

    On Fri, Feb 14, = 2020 at 08:20:54AM -0500, victor.demjanenko@vocal.com = wrote:

    > HI = Barry,

    > =

    > Thanks for = recalling this was still outstanding.  I had emailed Ben just after = the holidays and did not realize we had no response.  The below is = what we suggested to Ben to address concerns he = raised.

    > =

    > = --------------------

    > Hi = Ben,

    > =

    > Hope your = holidays were good.  Our were both good and busy.  Deliveries = for two NASA projects and the holidays kept us from responding = sooner.  But we do want to get this draft = completed.

    > =

    > With your = permission, I=E2=80=99d like to address your comments directly, resolve = what changes we should make and then publish a new version with a = summary of our out-of-band discussions.  We don=E2=80=99t have a = lot of experience with drafting such documents and would like to know = exactly what is needed to make this draft acceptable.

    > =

    > I believe = there are two comments/issues to address:

    > =

    > = 1)    CODA, CODB

    > =

    > Your = comment ends by stating:  =E2=80=9C(Or, of course, the use of CODB = as an alternating 1/0 bit as the framing usage could be documented = instead.)=E2=80=9D  We can do this as follows:

    > =

    > = (original)

    > It should = be noted that CODB for MELPe 600 bps mode MAY deviate = from

    >    the value in Table 1 when bit 55 = is used as an end-to-end framing

    >    bit. Frame decoding would remain = distinct as CODA being zero on its

    >    own would indicate a 7-byte = frame for either 2400 or 600 bps rate and

    >    the use of 600 bps speech coding = could be deduced from the RTP

    >    timestamp (and anticipated by = the SDP negotiations).

    > =

    > (adding = =E2=80=9Calternating 1/0=E2=80=9D)

    > It should = be noted that CODB for MELPe 600 bps mode MAY deviate = from

    >    the value in Table 1 when bit 55 = is used as an alternating 1/0 end-to-end framing

    >    bit. Frame decoding would remain = distinct as CODA being zero on its

    >    own would indicate a 7-byte = frame for either 2400 or 600 bps rate and

    >    the use of 600 bps speech coding = could be deduced from the RTP

    >    timestamp (and anticipated by = the SDP negotiations).

    > =

    > I think = this change would be sufficient to address your concern about what to = expect for CODB.

    This looks like = the minimal sufficient change, yes.  (I use = "minimal"

    because I would = say more if I was writing it, but I don't think I can insist that you = write it the way I would -- it's your document after = all!)

    > = 2.    Packing and unpacking

    > =

    > You are = correct that I am trying to vaguely describe a middle layer shim that is = neither RTP nor speech coder.  So it definitely does need to be = clear.  The vagueness comes from the speech coder description being = a FOUO document.  Its now unclassified so I can potentially say = more (and I did make some enhancements of the parameter description = already). 

    > =

    > So I am = trying to understand exactly what you think is vague in our current = description:

    > =

    > TSVCIS = augmented speech data is derived from the signal = processing

    >    and data already performed by = the MELPe speech coder.  For the

    >    purposes of this specification, = only the general parameter nature of

    >    TSVCIS will be = characterized.  Depending on the bandwidth = available

    >    (and FEC requirements), a = varying number of TSVCIS-specific speech

    >    coder parameters need to be = transported.  These are first byte-packed

    >    and then conveyed from encoder = to decoder.

    > =

    >    Byte packing of TSVCIS speech = data into packed parameters is

    >    processed as per the following = example:

    > =

    >       Three-bit = field: bits A, B, and C (A is MSB, C is LSB)

    >       Five-bit = field: bits D, E, F, G, and H (D is MSB, H is LSB)

    > =

    >        &nbs= p;   = MSB           &nbs= p;            = ;            =           = LSB

    >        &nbs= p;    0      = 1      2      = 3      4      = 5      6      = 7

    >         = +------+------+------+------+------+------+------+------+

    >         = |   H  |   G  |   F  = |   E  |   D  |   C  = |   B  |   A  |

    >         = +------+------+------+------+------+------+------+------+

    > =

    >    This packing method places the = three-bit field "first" in the lowest

    >    bits followed by the next = five-bit field.  Parameters may be split

    >    between octets with the most = significant bits in the earlier octet.

    >    Any unfilled bits in the last = octet MUST be filled with zero.

    [not actually = relevant to the Discuss part, but if there is always exactly one 3-bit = parameter and one 5-bit parameter, then this text allowing splitting = across octets will never be used and is potentially confusing to = mention.]

    >    In order to accommodate a = varying amount of TSVCIS augmented speech

    >    data, it is only necessary to = specify the number of octets containing

    >    the packed TSVCIS = parameters.  The encoding to do so is presented

    > = in

    I think the = "only necessary to specify the number of octets" is the key = stumbling point, for me -- I need to know the number of octets as well = as the order of the parameters within the list, which is more = information than just the number of octets.

    >    Section 3.2.  TSVCIS = specifically uses the NRL VDR in two

    >    configurations using 15 and 35 = packed octet parameters [TSVCIS]. 

    I think I = failed to internalize the "two configurations using 15 and 35 = packed octet parameters" the first time I read the document, as = this does help give the reader a clue that [TSVCIS] gives a good picture = of what parameters go where.  So it seems like we could easily = append to that, for "using a fixed set of 15 and 35 packed octet = parameters in a fixed order [TSVCIS]" and that would resolve my = concerns.

    > The speech = coder description of the parameters is the following:

    > =

    >  =

    > =

    > So the = three bit pitch is first (bits 56 to 58), followed by a five bit = amplitude (bits 59 to 63) and then an array of spectral components, each = 8-bit wide (starting at bit 64).

    [And maybe = TSVCIS specifes that the spectral components are derived from some = fundamental harmonic decomposition that naturally quantizes to a = number-of-parameters/accuracy tradeoff with a natural order.  If = so, we could also rely on that instead of my proposed change above; let = me know if you want to explore that path further.]

    > Based on = this information, I=E2=80=99m not sure what we should add to our =

    > draft to = make the description of packing/unpacking clearer.  Can you =

    > make any = suggestions or does this table help you with what you did not =

    > = know?  (I don=E2=80=99t think I should put this table into the = draft RFC

    > = however.)

    Hopefully the = above helps to clarify.

    Thanks, and = sorry for the delay.

    -Ben

    > Thanks for = your attention and comments.

    > =

    > Victor = & Dave

    > =

    > =

    > =

    > = -----Original Message-----

    > From: = Barry Leiba <barryleiba@computer.org>

    > Sent: = Friday, February 14, 2020 7:38 AM

    > To: = Benjamin Kaduk <kaduk@mit.edu>

    > Cc: = victor.demjanenko@vocal.com; Roni Even (A) <roni.even@huawei.com>; =

    > The IESG = <iesg@ietf.org>; Catherine Meadows

    > = <catherine.meadows@nrl.navy.mil>; IETF SecDir = <secdir@ietf.org>;

    > = draft-ietf-payload-tsvcis@ietf.org; Ali Begen

    > = <ali.begen@networked.media>; avtcore-chairs@ietf.org; = avt@ietf.org;

    > Dave = Satterlee (Vocal) <Dave.Satterlee@vocal.com>; IETF discussion =

    > list = <ietf@ietf.org>;  draft-ietf-payload-tsvcis.all@ietf.orgygv =

    > Subject: = Re: Benjamin Kaduk's Discuss on draft-ietf-payload-tsvcis-03: =

    > (with = DISCUSS and COMMENT)

    > =

    > This is = still outstanding, since November.  Victor, where are we on this = one?

    > =

    > = Barry

    > =

    > On Mon, = Nov 25, 2019 at 1:46 AM Benjamin Kaduk <kaduk@mit.edu> = wrote:

    > = >

    > > Hi = Victor,

    > = >

    > > On = Tue, Nov 19, 2019 at 03:14:21PM -0500, victor.demjanenko@vocal.com = wrote:

    > > > = Hi Ben,

    > > = >

    > > > = Sorry I overlooked sending you a response.  I would like to =

    > > > = address the two concerns you have by explaining what the speech coders = are doing.

    > = >

    > > = Thanks for the extra clarifications.  To supply one of my own: I'm =

    > > not = concerned that the protocol doesn't work as implemented, but =

    > > just = want to make sure that the document includes enough information =

    > > to = admit new implementations without guesswork.  That is to say, =

    > > = "either tell me how to do it or tell me where to look that tells me = how to do it".

    > = >

    > > > = WRT to 600 bps MELP, there is one TSVCIS mode that uses one bit =

    > > > = beyond the 54-bit frame for MELP 600 as a frame sync which alternates = between frames.

    > > > = With two or more MELP 600bps frames in one RTP packet, if any =

    > > > = frame indicates 600 bps by CODA being 0 and CODB being 1, then we =

    > > > = know the stream is 600bps.  If there is a single frame in an RTP =

    > > > = packet, you can still deduce this by looking at every other RTP =

    > > > = packet (every other MELP 600bps

    > > > = frame) and by the timestamp advance.  Most likely the two ends =

    > > > = would negotiate 600 bps in SDP anyways so there really should not =

    > > > = be a problem.  I know it's not pretty but its workable.  I = hope

    > > > = this explanation helps you with the concerns for this = issue.

    > = >

    > > In = this case, the use as an "end-to-end framing bit" (i.e., the =

    > > = alternating behavior you describe above) is not explicitly stated; =

    > > one = might imagine a scheme where the framing usage is to have the =

    > > bit = cycle through 1, 1, 0, and 0, or some other scheme.  I'd suggest =

    > > to = note in the document that if any instance of (CODA, CODB) =3D=3D (0, =

    > > 1) is = observed, then the 600bps mode is in use.  It might also be =

    > > = helpful to include the observation that two successive MELPe =

    > > = payloads with CODA =3D=3D CODB =3D=3D 0 indicates the 2400bps mode (and = that

    > > = seeing them in a single RTP packet is decisive, whereas additional =

    > > = information about packet non-loss would be needed in the =

    > > = one-MELPe-frame-per-RTP-packet case), but that would be a fair bit =

    > > of = additional text and might be diminishing returns.  (Or, of =

    > > = course, the use of CODB as an alternating 1/0 bit as the framing =

    > > usage = could be documented

    > > = instead.)

    > = >

    > > > = As for the TSVCIS parameter packing/unpacking, this is really =

    > > > = simple.  There is exactly on three bit parameter, exactly one five =

    > > > = bit parameter and a variable number of eight bit parameters.  In =

    > > > = our view, the speech coder itself (or a wrapper for it) is =

    > > > = responsible for preparing the block of octets.  RTP then just =

    > > > = transports it.  On receive, the complementary wrapper reverses the = packing operation.

    > > > = I hope this clarifies and explains the simplicity.

    > = >

    > > = That's exactly what I expected to happen; however, it's not what I =

    > > = believe the current text of the document is describing.  =

    > > = Specifically, I think that the current text implies that the =

    > > = "preparing the block of octets" and "complementary = wrapper reverses

    > > the = packing operation" are supposed to be part of the RTP payload =

    > > = format that this document describes, but this document does not have =

    > > = enough information to actually perform those operations = reversibly. 

    > > If = the packing is to be done in the speech coder, then this document =

    > > = doesn't need to talk about the packing at all (e.g., at the end of =

    > > = Section 2); if we need to keep the packing/wrapper in this document =

    > > then = we need to indicate that there's a defined priority order for =

    > > the = (8-octet) TSVCIS parameters in the TSVCIS references, to allow the = packing/unpacking to be deterministic.

    > = >

    > > = Thanks,

    > = >

    > > = Ben

    > = >

    > > = >

    > > > = -----Original Message-----

    > > > = From: Benjamin Kaduk <kaduk@mit.edu>

    > > > = Sent: Thursday, October 31, 2019 8:12 PM

    > > > = To: Barry Leiba <barryleiba@computer.org>

    > > > = Cc: victor.demjanenko@vocal.com; Roni Even (A)

    > > > = <roni.even@huawei.com>; The IESG <iesg@ietf.org>; Catherine =

    > > > = Meadows <catherine.meadows@nrl.navy.mil>; IETF SecDir =

    > > > = <secdir@ietf.org>; draft-ietf-payload-tsvcis@ietf.org; Ali Begen =

    > > > = <ali.begen@networked.media>; avtcore-chairs@ietf.org; =

    > > > = avt@ietf.org; Dave Satterlee (Vocal) <Dave.Satterlee@vocal.com>; =

    > > > = IETF discussion list <ietf@ietf.org>;

    > > > = draft-ietf-payload-tsvcis.all@ietf.org

    > > > = Subject: Re: Benjamin Kaduk's Discuss on

    > > > = draft-ietf-payload-tsvcis-03: (with DISCUSS and = COMMENT)

    > > = >

    > > > = I don't think so, unfortunately.

    > > = >

    > > > = I do see the clarification about CODB's potential for deviation =

    > > > = from Table 1, that only the 600 bps MELPe is allowed to deviate, =

    > > > = and that CODA gets us to "it's one of 2400 or 600 bps" and the = RTP

    > > > = timestamp disambiguates that

    > > > = 600 bps is in use.  But, it seems that this means that the =

    > > > = recipient in general should not rely on CODB to differentiate 600 =

    > > > = from 2400 bps, and instead is more robustly implemented by =

    > > > = *always* using the RTP timestamp to detect 600 bps, since that =

    > > > = will always work and CODB will sometimes not work under conditions =

    > > > = not fully specified here.  So, if we are unwilling or unable to =

    > > > = clarify what those conditions are (e.g., whether at a minimum =

    > > > = mutual agreement is required), then I think we need to describe =

    > > > = this procedure of consulting the RTP timestamp as the default behavior = and avoid giving the impression that CODB should be used to do = so.

    > > = >

    > > > = Additionally, I don't see anything to address my concern about =

    > > > = TSVCIS parameter decoding.  To be clear, the procedure I see this =

    > > > = document describing is that:

    > > > = - TSVCIS gives parameters (and their lengths in bits) to the = codec

    > > = >   described in this document

    > > > = - this document specifies how to densely encode those parameters into = a

    > > = >   byetstream

    > > > = - RTP transmits that encoded bytestream to the peer

    > > > = - the codec specified by this is responsible for turning that = encoded

    > > = >   bystream back into a list of TSVCIS parameters (and = their length

    > > > = in bits)

    > > = >

    > > > = I don't see how that last step is attainable with only the =

    > > > = information provided by this document.  I *assume* that one of the =

    > > > = TSVCIS specifications has a canonical (ordered) listing of =

    > > > = parameters, and that the list of parmeters given to this codec in =

    > > > = the first step will always be an initial prefix of that list, but =

    > > > = that's just me guessing at how to make sense of the stated =

    > > > = procedure given insufficient information.  I don't think it's =

    > > > = appropriate to make the reader of an RFC guess at what to do; we =

    > > > = need to either say how to do it or give a pointer to an external = reference that does.

    > > = >

    > > > = -Ben

    > > = >

    > > > = On Tue, Oct 29, 2019 at 02:26:09PM -0400, Barry Leiba = wrote:

    > > > = > Ben, does the -04 version address everything?

    > > > = >

    > > > = > Barry

    > > > = >

    > > > = > On Thu, Oct 24, 2019 at 1:42 PM <victor.demjanenko@vocal.com> = wrote:

    > > > = > >

    > > > = > > I forgot to address security comments in one email.  The = changes are:

    > > > = > >

    > > > = > > Section 8, second paragraph - Suggested edit by = reviewer

    > > > = > >

    > > > = > > (was)

    > > > = > >    This RTP payload format and the TSVCIS = decoder do not exhibit any

    > > > = > >    significant non-uniformity in the = receiver-side computational

    > > > = > >    complexity for packet processing and thus = are unlikely to pose a

    > > > = > >    denial-of-service threat due to the receipt = of pathological data.

    > > > = > >    Additionally, the RTP payload format does = not contain any active

    > > > = > >    content.

    > > > = > >

    > > > = > > (now)

    > > > = > >    This RTP payload format and the TSVCIS = decoder, to the best of our

    > > > = > >    knowledge, do not exhibit any significant = non-uniformity in the

    > > > = > >    receiver-side computational complexity for = packet processing and thus

    > > > = > >    are unlikely to pose a denial-of-service = threat due to the receipt of

    > > > = > >    pathological data. Additionally, the RTP = payload format does not

    > > > = > >    contain any active = content.

    > > > = > >

    > > > = > >

    > > > = > > Section 8, third paragraph - Suggested edit by = reviewer

    > > > = > >

    > > > = > > (was)

    > > > = > >    Please see the security considerations = discussed in [RFC6562]

    > > > = > >    regarding VAD and its effect on = bitrates.

    > > > = > >

    > > > = > > (now)

    > > > = > >    Please see the security considerations = discussed in [RFC6562]

    > > > = > >    regarding Voice Activity Detect (VAD) and = its effect on bitrates.

    > > > = > >

    > > > = > > Victor

    > > > = > >

    > > > = > > -----Original Message-----

    > > > = > > From: victor.demjanenko@vocal.com

    > > > = > > <victor.demjanenko@vocal.com>

    > > > = > > Sent: Thursday, October 24, 2019 10:05 AM

    > > > = > > To: 'Roni Even (A)' <roni.even@huawei.com>; 'Benjamin = Kaduk'

    > > > = > > <kaduk@mit.edu>; 'The IESG' = <iesg@ietf.org>

    > > > = > > Cc: draft-ietf-payload-tsvcis@ietf.org; 'Ali = Begen'

    > > > = > > <ali.begen@networked.media>; avtcore-chairs@ietf.org; =

    > > > = > > avt@ietf.org; 'Dave Satterlee (Vocal)'

    > > > = > > <Dave.Satterlee@vocal.com>

    > > > = > > Subject: RE: Benjamin Kaduk's Discuss on

    > > > = > > draft-ietf-payload-tsvcis-03: (with DISCUSS and = COMMENT)

    > > > = > >

    > > > = > > Hi Everyone,

    > > > = > >

    > > > = > > First we want to thank everyone for their review and comments =

    > > > = > > for this

    > > > = draft RFC.  We believe we reviewed all the comments and =

    > > > = suggestions and incorporated them adequately in the next draft =

    > > > = (04).  We'd like to send out this list of exact changes in case =

    > > > = anyone has additional comments or thinks the clarifications are =

    > > > = inadequate.  We would be most happy to address concerns before = publishing draft 04 tomorrow.

    > > > = > >

    > > > = > > With so many emails from a half dozen or more reviewers, we =

    > > > = > > apologize

    > > > = that we cannot address each sender individually.  We hope this =

    > > > = detail is sufficient for everyone.

    > > > = > >

    > > > = > > Again, many thanks to all.

    > > > = > >

    > > > = > > Victor & Dave

    > > > = > >

    > > > = > > = --------------------------------------------------------------

    > > > = > > --

    > > > = > > ----

    > > > = > > --------------------------

    > > > = > >

    > > > = > > Section 1.1 - Suggested reference to RFC 8088 = added.

    > > > = > >

    > > > = > > (was)

    > > > = > >    Best current practices for writing an RTP = payload format

    > > > = > >    specification were followed = [RFC2736].

    > > > = > >

    > > > = > > (now)

    > > > = > >    Best current practices for writing an RTP = payload format

    > > > = > >    specification were followed [RFC2736] = [RFC8088].

    > > > = > >

    > > > = > >

    > > > = > > Section 2, paragraphs 3 and 4 - Suggested edits by = reviewers

    > > > = > >

    > > > = > > (was)

    > > > = > >    In addition to the augmented speech data, = the TSVCIS specification

    > > > = > >    identifies which speech coder and framing = bits are to be encrypted,

    > > > = > >    and how they are protected by forward error = correction (FEC)

    > > > = > >    techniques (using block codes).  At the = RTP transport layer, only the

    > > > = > >    speech coder related bits need to be = considered and are conveyed in

    > > > = > >    unencrypted form.  In most IP-based = network deployments, standard

    > > > = > >    link encryption methods (SRTP, VPNs, FIPS = 140 link encryptors or Type

    > > > = > >    1 Ethernet encryptors) would be used to = secure the RTP speech

    > > > = > >    contents.  Further, it is desirable to = support the highest voice

    > > > = > >    quality between endpoints which is only = possible without the overhead

    > > > = > >    of FEC.

    > > > = > >

    > > > = > >    TSVCIS augmented speech data is derived from = the signal processing

    > > > = > >    and data already performed by the MELPe = speech coder.  For the

    > > > = > >    purposes of this specification, only the = general parameter nature of

    > > > = > >    TSVCIS will be characterized.  = Depending on the bandwidth available

    > > > = > >    (and FEC requirements), a varying number of = TSVCIS specific speech

    > > > = > >    coder parameters need to be = transported.  These are first byte-packed

    > > > = > >    and then conveyed from encoder to = decoder.

    > > > = > >

    > > > = > > (now)

    > > > = > >    In addition to the augmented speech data, = the TSVCIS specification

    > > > = > >    identifies which speech coder and framing = bits are to be encrypted,

    > > > = > >    and how they are protected by forward error = correction (FEC)

    > > > = > >    techniques (using block codes).  At the = RTP transport layer, only the

    > > > = > >    speech-coder-related bits need to be = considered and are conveyed in

    > > > = > >    unencrypted form.  In most IP-based = network deployments, standard

    > > > = > >    link encryption methods (SRTP, VPNs, FIPS = 140 link encryptors or Type

    > > > = > >    1 Ethernet encryptors) would be used to = secure the RTP speech

    > > > = > >    contents.

    > > > = > >

    > > > = > >    TSVCIS augmented speech data is derived from = the signal processing

    > > > = > >    and data already performed by the MELPe = speech coder.  For the

    > > > = > >    purposes of this specification, only the = general parameter nature of

    > > > = > >    TSVCIS will be characterized.  = Depending on the bandwidth available

    > > > = > >    (and FEC requirements), a varying number of = TSVCIS-specific speech

    > > > = > >    coder parameters need to be = transported.  These are first byte-packed

    > > > = > >    and then conveyed from encoder to = decoder.

    > > > = > >

    > > > = > >

    > > > = > > Section 3, last sentence paragraph 3 - Suggested edit by =

    > > > = > > reviewer

    > > > = > >

    > > > = > > (was)

    > > > = > >    When more than one codec data frame = is

    > > > = > >    present in a single RTP packet, the = timestamp is, as always, that of

    > > > = > >    the oldest data frame represented in the RTP = packet.

    > > > = > >

    > > > = > > (now)

    > > > = > >    When more than one codec data frame = is

    > > > = > >    present in a single RTP packet, the = timestamp specified is that of

    > > > = > >    the oldest data frame represented in the RTP = packet.

    > > > = > >

    > > > = > >

    > > > = > > Section 3.1, last paragraph - Clarified permission for MELP =

    > > > = > > 600 end-to-end framing bit

    > > > = > >

    > > > = > > (was)

    > > > = > >    It should be noted that CODB for both the = 2400 and 600 bps modes MAY

    > > > = > >    deviate from the values in Table 1 when bit = 55 is used as an end-to-

    > > > = > >    end framing bit.  Frame decoding would = remain distinct as CODA being

    > > > = > >    zero on its own would indicate a 7-byte = frame for either rate and the

    > > > = > >    use of 600 bps speech coding could be = deduced from the RTP timestamp

    > > > = > >    (and anticipated by the SDP = negotiations).

    > > > = > >

    > > > = > > (now)

    > > > = > >    It should be noted that CODB for MELPe 600 = bps mode MAY deviate from

    > > > = > >    the value in Table 1 when bit 55 is used as = an end-to-end framing

    > > > = > >    bit. Frame decoding would remain distinct as = CODA being zero on its

    > > > = > >    own would indicate a 7-byte frame for either = 2400 or 600 bps rate and

    > > > = > >    the use of 600 bps speech coding could be = deduced from the RTP

    > > > = > >    timestamp (and anticipated by the SDP = negotiations).

    > > > = > >

    > > > = > >

    > > > = > > Section 3.2, first paragraph - Clarifications requested by =

    > > > = > > reviewers

    > > > = > >

    > > > = > > (was)

    > > > = > >    The TSVCIS augmented speech data as packed = parameters MUST be placed

    > > > = > >    immediately after a corresponding MELPe 2400 = bps payload in the same

    > > > = > >    RTP packet.  The packed parameters are = counted in octets (TC).  In

    > > > = > >    the preferred placement, shown in Figure 6, = a single trailing octet

    > > > = > >    SHALL be appended to include a two-bit rate = code, CODA and CODB,

    > > > = > >    (both bits set to one) and a six-bit = modified count (MTC).  The

    > > > = > >    special modified count value of all ones = (representing a MTC value of

    > > > = > >    63) SHALL NOT be used for this format as it = is used as the indicator

    > > > = > >    for the alternate packing format shown = next.  In a standard

    > > > = > >    implementation, the TSVCIS speech coder uses = a minimum of 15 octets

    > > > = > >    for parameters in octet packed form.  = The modified count (MTC) MUST

    > > > = > >    be reduced by 15 from the full octet count = (TC).  Computed MTC =3D TC-

    > > > = > >    15.  This accommodates a maximum of 77 = parameter octets (maximum

    > > > = > >    value of MTC is 62, 77 is the sum of = 62+15).

    > > > = > >

    > > > = > > (now)

    > > > = > >    The TSVCIS augmented speech data as packed = parameters MUST be placed

    > > > = > >    immediately after a corresponding MELPe 2400 = bps payload in the same

    > > > = > >    RTP packet.  The packed parameters are = counted in octets (TC).  The

    > > > = > >    preferred placement SHOULD be used for = TSVCIS payloads with TC less

    > > > = > >    than or equal to 77 octets, is shown in = Figure 6.  In the preferred

    > > > = > >    placement, a single trailing octet SHALL be = appended to include a

    > > > = > >    two-bit rate code, CODA and CODB, (both bits = set to one) and a six-

    > > > = > >    bit modified count (MTC).  The special = modified count value of all

    > > > = > >    ones (representing a MTC value of 63) SHALL = NOT be used for this

    > > > = > >    format as it is used as the indicator for = the alternate packing

    > > > = > >    format shown next.  In a standard = implementation, the TSVCIS speech

    > > > = > >    coder uses a minimum of 15 octets for = parameters in octet packed

    > > > = > >    form.  The modified count (MTC) MUST be = reduced by 15 from the full

    > > > = > >    octet count (TC).  Computed MTC =3D = TC-15.  This accommodates a maximum

    > > > = > >    of 77 parameter octets (maximum value of MTC = is 62, 77 is the sum of

    > > > = > >    62+15).

    > > > = > >

    > > > = > >

    > > > = > > Section 3.3, first paragraph - Suggested edit by = reviewer

    > > > = > >

    > > > = > > (was)

    > > > = > >    A TSVCIS RTP packet consists of zero or more = TSVCIS coder frames

    > > > = > >    (each consisting of MELPe and TSVCIS coder = data) followed by zero or

    > > > = > >    one MELPe comfort noise frame.  The = presence of a comfort noise frame

    > > > = > >    can be determined by its rate code bits in = its last octet.

    > > > = > >

    > > > = > > (now)

    > > > = > >    A TSVCIS RTP packet payload consists of zero = or more consecutive

    > > > = > >    TSVCIS coder frames (each consisting of = MELPe 2400 and TSVCIS coder

    > > > = > >    data), with the oldest frame first, followed = by zero or one MELPe

    > > > = > >    comfort noise frame.  The presence of a = comfort noise frame can be

    > > > = > >    determined by its rate code bits in its last = octet.

    > > > = > >

    > > > = > >

    > > > = > > Section 3.3, fourth paragraph - Clarification requested by =

    > > > = > > reviewers

    > > > = > >

    > > > = > > (was)

    > > > = > >    TSVCIS coder frames in a single RTP packet = MAY be of different coder

    > > > = > >    bitrates.  With the exception for the = variable length TSVCIS

    > > > = > >    parameter frames, the coder rate bits in the = trailing byte identify

    > > > = > >    the contents and length as per Table = 1.

    > > > = > >

    > > > = > > (now)

    > > > = > >    TSVCIS coder frames in a single RTP packet = MAY have varying TSVCIS

    > > > = > >    parameter octet counts.  Its packed = parameter octet count (length) is

    > > > = > >    indicated in the trailing byte(s).  All = MELPe frames in a single RTP

    > > > = > >    packet MUST be of the same coder = bitrate.  For all MELPe coder

    > > > = > >    frames, the coder rate bits in the trailing = byte identify the

    > > > = > >    contents and length as per Table = 1.

    > > > = > >

    > > > = > >

    > > > = > > Section 4.1 - Editor note removed

    > > > = > >

    > > > = > >

    > > > = > > Section 4.1 - Change controller is now

    > > > = > >

    > > > = > > (now)

    > > > = > >    Change controller: IETF, contact = <avt@ietf.org>

    > > > = > >

    > > > = > >

    > > > = > > Section 5, first paragraph - Suggested edits by = reviewers

    > > > = > >

    > > > = > > (was)

    > > > = > >    A primary application of TSVCIS is for radio = communications of voice

    > > > = > >    conversations, and discontinuous = transmissions are normal.  When

    > > > = > >    TSVCIS is used in an IP network, TSVCIS RTP = packet transmissions may

    > > > = > >    cease and resume frequently.  RTP = synchronization source (SSRC)

    > > > = > >    sequence number gaps indicate lost packets = to be filled by PLC, while

    > > > = > >    abrupt loss of RTP packets indicates = intended discontinuous

    > > > = > >    transmissions.

    > > > = > >

    > > > = > > (now)

    > > > = > >    A primary application of TSVCIS is for radio = communications of voice

    > > > = > >    conversations, and discontinuous = transmissions are normal.  When

    > > > = > >    TSVCIS is used in an IP network, TSVCIS RTP = packet transmissions may

    > > > = > >    cease and resume frequently.  RTP = synchronization source (SSRC)

    > > > = > >    sequence number gaps indicate lost packets = to be filled by Packet

    > > > = > >    Loss Concealment (PLC), while abrupt loss of = RTP packets indicates

    > > > = > >    intended discontinuous transmissions.  = Resumption of voice

    > > > = > >    transmission SHOULD be indicated by the RTP = marker bit (M) set to 1.

    > > > = > >

    > > > = > >

    > > > = > > Section 10 - Added reference

    > > > = > >

    > > > = > > (added)

    > > > = > >    [RFC8088]  Westerlund, M., "How to = Write an RTP Payload Format",

    > > > = > = >           &nb= sp;   RFC 8088, DOI 10.17487/RFC8088, May = 2017,

    > > > = > = >           &nb= sp;   <http://www.rfc-editor.org= /info/rfc8088>.

    > > > = > >

    > > > = > > = --------------------------------------------------------------

    > > > = > > --

    > > > = > > ----

    > > > = > > -----------------------------

    > > > = > >

    > > > = > >

    > > > = > > -----Original Message-----

    > > > = > > From: Roni Even (A) = <roni.even@huawei.com>

    > > > = > > Sent: Sunday, October 6, 2019 2:09 AM

    > > > = > > To: victor.demjanenko@vocal.com; 'Benjamin Kaduk' =

    > > > = > > <kaduk@mit.edu>; 'The IESG' = <iesg@ietf.org>

    > > > = > > Cc: draft-ietf-payload-tsvcis@ietf.org; 'Ali = Begen'

    > > > = > > <ali.begen@networked.media>; avtcore-chairs@ietf.org; =

    > > > = > > avt@ietf.org; 'Dave Satterlee (Vocal)'

    > > > = > > <Dave.Satterlee@vocal.com>

    > > > = > > Subject: RE: Benjamin Kaduk's Discuss on

    > > > = > > draft-ietf-payload-tsvcis-03: (with DISCUSS and = COMMENT)

    > > > = > >

    > > > = > > Hi,

    > > > = > > About the reference to TSVCIS.

    > > > = > > The RTP payload is about how to encapsulate the payload in an =

    > > > = > > RTP

    > > > = packet. The objective is to define how an RTP stack can insert the =

    > > > = tsvcis frames and  extract the tsvcis frames from the RTP = packet.

    > > > = Typically it is not required to understand the payload structure =

    > > > = in order to be able to perform the encapsulation.

    > > > = > > This is why the reference to the payload is Informational and =

    > > > = > > we did not require to have it publically available.  If = there

    > > > = > > is a need to understand the payload itself for the =

    > > > = > > encapsulating than we need more information in the RTP payload =

    > > > = > > specification and a publically available normative reference. =

    > > > = > > I think this is not the case here

    > > > = > >

    > > > = > > Roni Even

    > > > = > >

    > > > = > > AVTCore co-chair (ex Payload)

    > > > = > >

    > > > = > > -----Original Message-----

    > > > = > > From: victor.demjanenko@vocal.com

    > > > = > > [mailto:victor.demjanenko@voca= l.com]

    > > > = > > Sent: Saturday, October 05, 2019 12:18 AM

    > > > = > > To: 'Benjamin Kaduk'; 'The IESG'

    > > > = > > Cc: draft-ietf-payload-tsvcis@ietf.org; 'Ali = Begen';

    > > > = avtcore-chairs@ietf.org; avt@ietf.org; 'Victor Demjanenko, Ph.D.'; =

    > > > = 'Dave Satterlee (Vocal)'

    > > > = > > Subject: RE: Benjamin Kaduk's Discuss on

    > > > = > > draft-ietf-payload-tsvcis-03: (with DISCUSS and = COMMENT)

    > > > = > >

    > > > = > > Everyone,

    > > > = > >

    > > > = > > Thanks for the comments.  I think I mis-understood the =

    > > > = > > ambiguity with

    > > > = respect to to changing rates within a RTP packet.  That was not =

    > > > = plan.  An RTP packet must have MELP speech frames of the same = rate.

    > > > = What is possible is that the amount of augmented TSVCIS speech =

    > > > = data may vary from one speech frame to the next.  This allows for =

    > > > = a dynamic VDR as suggested by the NRL paper.  So an RTP packet may =

    > > > = have varying TSVCIS data but must always have MELPe 2400 = data.

    > > > = > >

    > > > = > > Again backwards parsing is necessary but the timestamp =

    > > > = > > uniformly

    > > > = increments 22.5msec per combined MELP/TSVCIS speech = frame.

    > > > = > >

    > > > = > > The NRL is a good public reference on the VDR aspects.  = The

    > > > = > > actual

    > > > = TSVCIS spec we had was FOUO so we could not replicate its detail.  =

    > > > = (I believe a later spec is public or at least partially public.  I =

    > > > = am trying to get this.)  The opaque data is pretty obvious with the = TSVCIS spec in hand.

    > > > = > >

    > > > = > > We will address the issues/concerns raised next week.  = Other

    > > > = > > business

    > > > = had priority.

    > > > = > >

    > > > = > > Thank you and enjoy the weekend.

    > > > = > >

    > > > = > > Regards,

    > > > = > >

    > > > = > > Victor & Dave

    > > > = > >

    > > > = > > -----Original Message-----

    > > > = > > From: Benjamin Kaduk via Datatracker = <noreply@ietf.org>

    > > > = > > Sent: Wednesday, October 2, 2019 10:40 PM

    > > > = > > To: The IESG <iesg@ietf.org>

    > > > = > > Cc: draft-ietf-payload-tsvcis@ietf.org; Ali Begen =

    > > > = > > <ali.begen@networked.media>; avtcore-chairs@ietf.org; =

    > > > = > > ali.begen@networked.media; avt@ietf.org

    > > > = > > Subject: Benjamin Kaduk's Discuss on = draft-ietf-payload-tsvcis-03:

    > > > = > > (with DISCUSS and COMMENT)

    > > > = > >

    > > > = > > Benjamin Kaduk has entered the following ballot position = for

    > > > = > > draft-ietf-payload-tsvcis-03: Discuss

    > > > = > >

    > > > = > > When responding, please keep the subject line intact and reply =

    > > > = > > to all email addresses included in the To and CC lines. (Feel =

    > > > = > > free to cut this introductory paragraph, = however.)

    > > > = > >

    > > > = > >

    > > > = > > Please refer to

    > > > = > > https:= //www.ietf.org/iesg/statement/discuss-criteria.html

    =

    > > > = > > for more information about IESG DISCUSS and COMMENT = positions.

    > > > = > >

    > > > = > >

    > > > = > > The document, along with other ballot positions, can be found = here:

    > > > = > > http= s://datatracker.ietf.org/doc/draft-ietf-payload-tsvcis/=

    > > > = > >

    > > > = > >

    > > > = > >

    > > > = > > = --------------------------------------------------------------

    > > > = > > --

    > > > = > > ----

    > > > = > > --

    > > > = > > DISCUSS:

    > > > = > > = --------------------------------------------------------------

    > > > = > > --

    > > > = > > ----

    > > > = > > --

    > > > = > >

    > > > = > > I support Magnus' point about the time-ordering of adjacent =

    > > > = > > frames in a

    > > > = packet.

    > > > = > >

    > > > = > > Additionally, I am not sure that there's quite enough here to =

    > > > = > > be

    > > > = interoperably implementable.  Specifically, we seem to be lacking =

    > > > = a description of how an encoder or decoder knows which TSVCIS =

    > > > = parameters, and in what order, to byte-pack or unpack, = respectively.

    > > > = One might surmise that there is a canonical listing in [TSVCIS], =

    > > > = but this document does not say that, and furthermore [TSVCIS] is only = listed as an informative reference.

    > > > = (I couldn't get my hands on my copy, at least on short notice.)  =

    > > > = If we limited ourselves to treating the TSVCIS parameters as an =

    > > > = entirely opaque blob (codec, convey these N octets to the peer =

    > > > = with the appropriate one- or two-byte trailer for payload type =

    > > > = identification and framing), that would be interoperably =

    > > > = implementable, since the black-box bits are up to some other codec to = interpret.

    > > > = > >

    > > > = > > In a similar vein, we mention but do not completely specify =

    > > > = > > the

    > > > = potential for using CODB as an end-to-end framing bit, in = Section

    > > > = 3.1 (see Comment), which is not interoperably implementable without = further details.

    > > > = > >

    > > > = > >

    > > > = > > = --------------------------------------------------------------

    > > > = > > --

    > > > = > > ----

    > > > = > > --

    > > > = > > COMMENT:

    > > > = > > = --------------------------------------------------------------

    > > > = > > --

    > > > = > > ----

    > > > = > > --

    > > > = > >

    > > > = > > Where is [TSVCIS] available?

    > > > = > >

    > > > = > > Is [NRLVDR] the same as

    > > > = > > https://ap= ps.dtic.mil/dtic/tr/fulltext/u2/a588068.pdf ?  A URL =

    > > > = > > in the

    > > > = references would be helpful.

    > > > = > >

    > > > = > > Is additional TSVCIS data only present after 2400bps MELPe and =

    > > > = > > the first

    > > > = thing to get dropped under bandwidth pressure?  The abstract and =

    > > > = introduction imply this by calling out MELPe 2400 bps speech =

    > > > = parameters explicitly, but Section 3 says that TSVCIS augments =

    > > > = standard 600, 1200, and

    > > > = 2400 bps MELP frames.

    > > > = > >

    > > > = > > It's helpful that Section 3.3 gives some general guidance for =

    > > > = > > decoding

    > > > = this payload type ("[t]he way to determine the number of =

    > > > = TSVCIS/MELPe frames is to identify each frame type and length"), =

    > > > = but I think some generic considerations would be very helpful to =

    > > > = the reader much earlier, along the lines of "MELPe and TSVCIS data =

    > > > = payloads are decoded from the end, using the CODA and CODB (and, =

    > > > = if necessary, CODC and others) bits to determine the type of = payload.

    > > > = For MELPe payloads the type also indicates the payload length, =

    > > > = whereas for TSVCIS data an additional length field is present, in =

    > > > = one of two possible formats.  A TSVCIS coder frame consists of a =

    > > > = MELPe data payload followed by zero or one TSVCIS data payload; =

    > > > = after the TSVCIS payload's presence/length is determined, then the =

    > > > = preceding MELPe payload can be determined and decoded.  Per =

    > > > = Section 3.3, multiple TSVCIS frames can be present in a single RTP = packet."

    > > > = This (or something like it) would also serve to clarify the role of the = COD* bits, which is otherwise only implicitly = introduced.

    > > > = > >

    > > > = > > Section 1.1

    > > > = > >

    > > > = > > RFC 2736 is BCP 36 (but it's updated by RFC 8088 which is for =

    > > > = > > some

    > > > = reason an Informational document and not part of BCP = 36?!).

    > > > = > >

    > > > = > > Section 2

    > > > = > >

    > > > = > >    In addition to the augmented speech data, = the TSVCIS specification

    > > > = > >    identifies which speech coder and framing = bits are to be encrypted,

    > > > = > >    and how they are protected by forward error = correction (FEC)

    > > > = > >    techniques (using block codes).  At the = RTP transport layer, only the

    > > > = > >    speech coder related bits need to be = considered and are conveyed in

    > > > = > >    unencrypted form.  In most IP-based = network deployments,

    > > > = > > standard

    > > > = > >

    > > > = > > Am I reading this correctly that this text is just summarizing =

    > > > = > > what's in

    > > > = the TSVCIS spec in terms of what needs to be in unencrypted form, =

    > > > = so the "only the speech coder related bits[...]" is not new =

    > > > = information from this document?  I'm not sure I agree with the =

    > > > = conclusion, regardless -- won't the

    > > > = (MELPe) speech coder bits be enough to convey the semantic content =

    > > > = of the audio stream, something that one might desire to keep = confidential?

    > > > = > >

    > > > = > >    link encryption methods (SRTP, VPNs, FIPS = 140 link encryptors or Type

    > > > = > >    1 Ethernet encryptors) would be used to = secure the RTP speech

    > > > = > >    contents.  Further, it is desirable to = support the highest voice

    > > > = > >    quality between endpoints which is only = possible without the overhead

    > > > = > >    of FEC.

    > > > = > >

    > > > = > > I think I'm missing a step in how this conclusion was = reached.

    > > > = > >

    > > > = > >    TSVCIS will be characterized.  = Depending on the bandwidth available

    > > > = > >    (and FEC requirements), a varying number of = TSVCIS specific speech

    > > > = > >    coder parameters need to be = transported.  These are first byte-packed

    > > > = > >    and then conveyed from encoder to = decoder.

    > > > = > >

    > > > = > > Per the Discuss point, how do I know which parameters need to =

    > > > = > > be

    > > > = transported, and in what order?

    > > > = > >

    > > > = > >    Byte packing of TSVCIS speech data into = packed parameters is

    > > > = > >    processed as per the following = example:

    > > > = > >

    > > > = > >       Three-bit field: bits A, = B, and C (A is MSB, C is LSB)

    > > > = > >       Five-bit field: bits D, E, = F, G, and H (D is MSB, H is

    > > > = > > LSB)

    > > > = > >

    > > > = > = >            = MSB           &nbs= p;            = ;            =           = LSB

    > > > = > = >           &nb= sp; 0      1      = 2      3      = 4      5      = 6      7

    > > > = > >         = +------+------+------+------+------+------+------+------+

    > > > = > >         |   = H  |   G  |   F  |   = E  |   D  |   C  |   = B  |   A  |

    > > > = > >         =

    > > > = > > = +------+------+------+------+------+------+------+------+

    > > > = > >

    > > > = > >    This packing method places the three-bit = field "first" in the lowest

    > > > = > >    bits followed by the next five-bit = field.  Parameters may be split

    > > > = > >    between octets with the most significant = bits in the earlier octet.

    > > > = > >    Any unfilled bits in the last octet MUST be = filled with zero.

    > > > = > >

    > > > = > > I agree with Adam that this is very unclear.  A is the = MSB of

    > > > = > > the

    > > > = three-bit field but the LSB of the octet overall?

    > > > = > > We probably need an example of splitting a parameter across =

    > > > = > > octets as

    > > > = well, to get the bit ordering right.

    > > > = > >

    > > > = > > Section 3.1

    > > > = > >

    > > > = > >    It should be noted that CODB for both the = 2400 and 600 bps modes MAY

    > > > = > >    deviate from the values in Table 1 when bit = 55 is used as an end-to-

    > > > = > >    end framing bit.  Frame decoding would = remain distinct as

    > > > = > > CODA being

    > > > = > >

    > > > = > > Where is the use of CODB as an end-to-end framing bit = defined? 

    > > > = > > If we're

    > > > = going to provide neither a complete description of how to do it =

    > > > = nor a reference to a better description, we probably shouldn't mention = it at all.

    > > > = > >

    > > > = > > Section 3.2

    > > > = > >

    > > > = > >    RTP packet.  The packed parameters are = counted in octets (TC).  In

    > > > = > >    the preferred placement, shown in Figure 6, = a single trailing octet

    > > > = > >    SHALL be appended to include a two-bit rate = code, CODA and

    > > > = > > CODB,

    > > > = > >

    > > > = > > I'd consider saying something about this being the preferred =

    > > > = > > format

    > > > = > > ("placement") due to its shorter length than the = alternative,

    > > > = > > and say

    > > > = that it "SHOULD be used for TSVCIS payloads with TC less than or =

    > > > = equal to 77 octetes".

    > > > = > >

    > > > = > > Section 3.3

    > > > = > >

    > > > = > > When a longer packetization interval is used, is that =

    > > > = > > indicated by

    > > > = signaling or RTP timestamps or otherwise?

    > > > = > >

    > > > = > >    TSVCIS coder frames in a single RTP packet = MAY be of different coder

    > > > = > >    bitrates.  With the exception for the = variable length TSVCIS

    > > > = > >    parameter frames, the coder rate bits in the = trailing byte identify

    > > > = > >    the contents and length as per Table = 1.

    > > > = > >

    > > > = > > Maybe also note that the penultimate octet gives the length = there?

    > > > = > >

    > > > = > >    Information describing the number of frames = contained in an RTP

    > > > = > >    packet is not transmitted as part of the RTP = payload.  The way to

    > > > = > >    determine the number of TSVCIS/MELPe frames = is to identify each frame

    > > > = > >    type and length thereby counting the total = number of octets within

    > > > = > >    the RTP packet.

    > > > = > >

    > > > = > > terminology nit: if a frame is the combination of MELPe and =

    > > > = > > TSVCIS

    > > > = payload data units then there are two layres of decoding to get a =

    > > > = length for the frame, since we have to get the TSVCIS length and then = the MELPe length.

    > > > = > >

    > > > = > > Section 4.2

    > > > = > >

    > > > = > >    Parameter "ptime" cannot be used = for the purpose of

    > > > = > > specifying the

    > > > = > >

    > > > = > > nit: missing article ("The = parameter")

    > > > = > >

    > > > = > >    will be impossible to distinguish which mode = is about to be used

    > > > = > >    (e.g., when ptime=3D68, it would be = impossible to distinguish if the

    > > > = > >    packet is carrying one frame of 67.5 ms or = three frames of 22.5 ms).

    > > > = > >

    > > > = > > So how is the operating mode determined, = then?

    > > > = > > (I think this is the same question I asked = above)

    > > > = > >

    > > > = > > Section 4.4

    > > > = > >

    > > > = > >    For example, if offerer bitrates are = "2400,600" and answer bitrates

    > > > = > >    are "600,2400", the initial = bitrate is 600.  If other bitrates are

    > > > = > >    provided by the answerer, any common bitrate = between the offer and

    > > > = > >    answer MAY be used at any time in the = future.  Activation of these

    > > > = > >    other common bitrates is beyond the scope of = this document.

    > > > = > >

    > > > = > > It seems important to specify whether this requires a new O/A =

    > > > = > > exchange

    > > > = or can be done "spontaneously" by just encoding different = frame types.

    > > > = > > (It seems like the latter is possible, on first glance, and =

    > > > = > > this is implied by Section 3.3's discussion of mixing them in =

    > > > = > > a single

    > > > = > > packet.)

    > > > = > >

    > > > = > > Section 5

    > > > = > >

    > > > = > > Please expand PLC at first use (not second).

    > > > = > >

    > > > = > > Section 6

    > > > = > >

    > > > = > > I don't understand the PLC usage.  Is the idea that a =

    > > > = > > receiver, on

    > > > = seeing an SSRC gap, constructs fictitious PLC frames to "fill the = gap"

    > > > = > > and passes the resulting stream to the = decoder?

    > > > = > >

    > > > = > > Section 8

    > > > = > >

    > > > = > >    and important considerations in = [RFC7201].  Applications SHOULD use

    > > > = > >    one or more appropriate strong security = mechanisms.  The rest of this

    > > > = > >    section discusses the security-impacting = properties of the payload

    > > > = > >    format itself.

    > > > = > >

    > > > = > > I thought we described TSVCIS itself (much earlier in = the

    > > > = > > document) as

    > > > = requiring encryption for some data; wouldn't that translate to a = "MUST"

    > > > = > > here and not a "SHOULD"?

    > > > = > >

    > > > = > >

    > > > = > >

    > > = >

    > <<...>>

    ------=_NextPart_001_002D_01D60D9B.9E56D0F0-- ------=_NextPart_000_002C_01D60D9B.9E56D0F0 Content-Type: text/plain; name="changes_04_05.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="changes_04_05.txt" Section 2 (first sentence in last paragraph) - Clarification for octet count (was) In order to accommodate a varying amount of TSVCIS augmented speech data, it is only necessary to specify the number of octets containing the packed TSVCIS parameters. The encoding to do so is presented in Section 3.2. TSVCIS specifically uses the NRL VDR in two configurations using 15 and 35 packed octet parameters [TSVCIS]. (now) In order to accommodate a varying amount of TSVCIS augmented speech data, an octect count specifies the number of octets representing the packed TSVCIS parameters. The encoding to do so is presented in Section 3.2. TSVCIS specifically uses the NRL VDR in two configurations using a fixed set of 15 and 35 packed octet parameters in a fixed order [TSVCIS]. Section 3.1 (first sentence in last paragraph) - Clarification for CODA, CODB (was) It should be noted that CODB for MELPe 600 bps mode MAY deviate from the value in Table 1 when bit 55 is used as an end-to-end framing bit. (now) It should be noted that CODB for MELPe 600 bps mode MAY deviate from the value in Table 1 when bit 55 is used as an alternating 1/0 end-to-end framing bit. ------=_NextPart_000_002C_01D60D9B.9E56D0F0-- From nobody Thu Apr 9 04:41:57 2020 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 47D753A090D; Thu, 9 Apr 2020 04:41:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Yoav Nir via Datatracker To: Cc: last-call@ietf.org, idr@ietf.org, draft-ietf-idr-rfc5575bis.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.125.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158643250722.20996.2687173728603121972@ietfa.amsl.com> Reply-To: Yoav Nir Date: Thu, 09 Apr 2020 04:41:47 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-idr-rfc5575bis-20 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, 09 Apr 2020 11:41:48 -0000 Reviewer: Yoav Nir 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 one is ready, and the Security Considerations section is remarkably well-written. From nobody Thu Apr 9 08:04:56 2020 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 BB86D3A0943; Thu, 9 Apr 2020 08:04:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Sandra Murphy via Datatracker To: Cc: dmarc@ietf.org, draft-ietf-dmarc-psd.all@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.125.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158644469471.21209.9811712342867228933@ietfa.amsl.com> Reply-To: Sandra Murphy Date: Thu, 09 Apr 2020 08:04:54 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-dmarc-psd-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, 09 Apr 2020 15:04:55 -0000 Reviewer: Sandra Murphy Review result: Has Nits This is a secdir review of draft-ietf-dmarc-psd-08 (DMARC (Domain-based Message Authentication, Reporting, and Conformance) Extension For PSDs (Public Suffix Domains)) 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 presents an extension to DMARC for Public Suffix Domains (PSD) (and their operators (PSO)), which are domains that are not organizational domains and are not subject to DMARC processing. In DMARC, these PSD domains can not publish policy or receive feedback for subdomains. The extension allows PSDs to express policy for organizational domain that are not themselves implementing policy. It also provides a new tag that covers non-existing subdomains. I find the document to be well written and well laid out (even in the face of a few comments below). Note: I am not conversant with DMARC and have only read the underlying normative references to the extent necessary to review this document. Consider the source in reading these comments. The security considerations section states that it does not change the security considerations of the base DMARC specification RFC7489. That is common in extensions to existing protocols. But the authors, to their credit, note that this extension increases some of the risks identified in the security considerations of rFC7489. I wish more authors of extensions to existing protocols did similar analysis. The security considerations section points in particular to Section 12.5 of RFC7489, which describes the risks of external reporting addresses. Section 4 of this document describes the privacy concerns of feedback reports leaking information outside an organizational domain. Section 12.5 of RFC7489 of RFC7489 points to a verification mechanism in Section 7.1 of RFC7489. Section 7.1 presents a detailed procedure to verify that a feedback reporting address is safe to report to, particularly for rua or ruf tags. Question to the authors: has the correctness of that procedure in the presence of this extension been considered? I can't tell. Some wordsmithing comments: Section 4.1 page 9 o Multi-organization PSDs (e.g., ".com") that do not mandate DMARC usage: Privacy risks for Organizational Domains that have not deployed DMARC within such PSDs are significant. For non-DMARC Organizational Domains, all DMARC feedback will be directed to the PSO. PSD DMARC is opt-out (by publishing a DMARC record at the Organizational Domain level) vice opt-in, which would be the more desirable characteristic. This means that any non-DMARC organizational domain would have its feedback reports redirected to the PSO. The content of such reports, particularly for existing domains, is privacy sensitive. The sentences "For non-DMARC Organizational Domains, all DMARC feedback will be directed to the PSO. and "This means that any non-DMARC organizational domain would have its feedback reports redirected to the PSO." seem to say the same thing. Are they redundant? Or is there a difference there that I am not seeing? Section A page 11 If the experiment shows that PSD DMARC solves a real problem and can be used at a large scale, the results could prove to be useful in removing constraints outside of the IETF that would permit broader deployment. I would read "removing constraints ... that would permit broader deployment" as meaning constraints that permit deployment are being removed. The "that" would in ordinary reading refer to "contraints". I think the intended meaning is "removing constraints ... where those constraints hamper broader deployment" or "removing constraints ... thereby permitting broader deployment" And I'm not sure whether "outside of the IETF" means that the removing occurs outside the IETF or that the constraints exist outside the IETF. I suspect both, but I don't know that it makes much difference. Section A.1 page 12 This section concerns the privacy concerns arising from the external reporting described in Section 4.1. In Section 4.1, the privacy risk exists for "non-DMARC organizational domains" under a multi-organizational PSD (presumably PSD DMARC participating, right?) that does not mandate DMARC usage for its registrants. Section A.1 states that knowing which PSDs do not present this risk would be beneficial and describes an experiment to produce that knowledge. Desirable attributes for such a mechanism includes the following: o List PSDs that either mandate DMARC for their registrants or for which all lower level domains are controlled by the PSO and that the relevant PSO has indicated a desire for the PSD to participate in PSD DMARC I get the "mandate DMARC" part - the risk exists in the case the PSD does not mandate DMARC - if the PSD mandates DMARC, it does not produce the privacy risk. I do not get the next part: or for which all lower level domains are controlled by the PSO and that the relevant PSO has indicated a desire for the PSD to participate in PSD DMARC" I do not see how the desire of the PSO that the PSD should participate in PSD DMARC would help alleviate the privacy risk for the PSD's registrant organizational domains. In the first place, what does the PSO's desire got to do with alleviating risk? In the second place, this mechanism is supposed to produce a list of PSDs that do not produce the risk. The risk in Section 4.1 assumes (or so I thought) that the PSD participates in PSD DMARC. So if the PSD is not participating in PSD DMARC, then it is therefore not producing risk, but it obeys the PSO desire, then the PSD becomes in the category of producing the risk, not alleviating risk. I suspect I am just confused here. --Sandy Murphy From nobody Thu Apr 9 15:50:53 2020 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 87AD73A11A2; Thu, 9 Apr 2020 15:50:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.101 X-Spam-Level: *** X-Spam-Status: No, score=3.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_SUMOF=5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 wTFUyT8S1ktV; Thu, 9 Apr 2020 15:50:42 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 5F0AC3A11C4; Thu, 9 Apr 2020 15:50:31 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 039MoH0c029093 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 9 Apr 2020 18:50:19 -0400 Date: Thu, 9 Apr 2020 15:50:16 -0700 From: Benjamin Kaduk To: victor.demjanenko@vocal.com Cc: "'Barry Leiba'" , avtcore-chairs@ietf.org, "'Ali Begen'" , "'IETF discussion list'" , "'IETF SecDir'" , avt@ietf.org, "'Roni Even (A)'" , "'The IESG'" , "'Dave Satterlee (Vocal)'" , draft-ietf-payload-tsvcis@ietf.org, "'Catherine Meadows'" , draft-ietf-payload-tsvcis.all@ietf.org Message-ID: <20200409225016.GP88064@kduck.mit.edu> References: <034a01d58a73$f4d3a1c0$de7ae540$@vocal.com> <037e01d58a92$72287510$56795f30$@vocal.com> <20191101001153.GQ88302@kduck.mit.edu> <06e101d59f15$ee937b30$cbba7190$@vocal.com> <20191125064606.GL32847@mit.edu> <00c601d5e339$965ebd90$c31c38b0$@vocal.com> <20200214194321.GF43385@kduck.mit.edu> <002b01d60dbd$25675f80$70361e80$@vocal.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <002b01d60dbd$25675f80$70361e80$@vocal.com> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [secdir] Benjamin Kaduk's Discuss on draft-ietf-payload-tsvcis-03: (with DISCUSS and COMMENT) 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, 09 Apr 2020 22:50:47 -0000 Hi Victor, On Wed, Apr 08, 2020 at 11:48:26AM -0400, victor.demjanenko@vocal.com wrote: > Hi Ben, > > With this social distancing situation, I'm finally catching up on open items myself. I have made the changes as we have discussed and incorporated your suggestions. I believe the changes are fully contained in the two paragraphs below: > > Section 2 (last paragraph) - Clarification for octet count > > (was) > In order to accommodate a varying amount of TSVCIS augmented speech > data, it is only necessary to specify the number of octets > containing the packed TSVCIS parameters. The encoding to do so is > presented in Section 3.2. TSVCIS specifically uses the NRL VDR in two > configurations using 15 and 35 packed octet parameters [TSVCIS]. > > (now) > In order to accommodate a varying amount of TSVCIS augmented speech > data, an octet count specifies the number of octets representing > the packed TSVCIS parameters. The encoding to do so is presented in > Section 3.2. TSVCIS specifically uses the NRL VDR in two > configurations using a fixed set of 15 and 35 packed octet > parameters in a standardized order [TSVCIS]. > > > Section 3.1 (first sentence in last paragraph) - Clarification for CODA, CODB > > (was) > It should be noted that CODB for MELPe 600 bps mode MAY deviate from > the value in Table 1 when bit 55 is used as an end-to-end framing bit. > > (now) > It should be noted that CODB for MELPe 600 bps mode MAY deviate from > the value in Table 1 when bit 55 is used as an alternating 1/0 > end-to-end framing bit. > > Ben, I believe this addresses your comments and requests for clarifications as per our email discussion chain below. I also believe that :) > Thanks for you comments and with your concurrence (and my home computer's cooperation), I will post a new draft hopefully acceptable for final approval. Okay, I'll keep an eye out. > Regards to all and stay on the good side of Darwin. You, too! (And that phrasing brought a smile to my face, which I appreciate especially in these trying times.) Thanks, Ben > > > -----Original Message----- > From: Benjamin Kaduk > Sent: Friday, February 14, 2020 2:43 PM > To: victor.demjanenko@vocal.com; 'Barry Leiba' > Cc: 'Roni Even (A)' ; 'The IESG' ; 'Catherine Meadows' ; 'IETF SecDir' ; draft-ietf-payload-tsvcis@ietf.org; 'Ali Begen' ; avtcore-chairs@ietf.org; avt@ietf.org; 'Dave Satterlee (Vocal)' ; 'IETF discussion list' ; draft-ietf-payload-tsvcis.all@ietf.org > Subject: Re: Benjamin Kaduk's Discuss on draft-ietf-payload-tsvcis-03: (with DISCUSS and COMMENT) > > Hi Barry, > > As Victor notes, this one was/is waiting on me; he did reply (offlist) on > 15 January but I seem to have missed it amid a deluge of other mail that arrived at that time. Thanks for the reminder, and thanks Victor for re-sending the comments. > (inline) > > On Fri, Feb 14, 2020 at 08:20:54AM -0500, victor.demjanenko@vocal.com wrote: > > HI Barry, > > > > Thanks for recalling this was still outstanding. I had emailed Ben just after the holidays and did not realize we had no response. The below is what we suggested to Ben to address concerns he raised. > > > > -------------------- > > Hi Ben, > > > > Hope your holidays were good. Our were both good and busy. Deliveries for two NASA projects and the holidays kept us from responding sooner. But we do want to get this draft completed. > > > > With your permission, I’d like to address your comments directly, resolve what changes we should make and then publish a new version with a summary of our out-of-band discussions. We don’t have a lot of experience with drafting such documents and would like to know exactly what is needed to make this draft acceptable. > > > > I believe there are two comments/issues to address: > > > > 1) CODA, CODB > > > > Your comment ends by stating: “(Or, of course, the use of CODB as an alternating 1/0 bit as the framing usage could be documented instead.)” We can do this as follows: > > > > (original) > > It should be noted that CODB for MELPe 600 bps mode MAY deviate from > > the value in Table 1 when bit 55 is used as an end-to-end framing > > bit. Frame decoding would remain distinct as CODA being zero on its > > own would indicate a 7-byte frame for either 2400 or 600 bps rate and > > the use of 600 bps speech coding could be deduced from the RTP > > timestamp (and anticipated by the SDP negotiations). > > > > (adding “alternating 1/0”) > > It should be noted that CODB for MELPe 600 bps mode MAY deviate from > > the value in Table 1 when bit 55 is used as an alternating 1/0 end-to-end framing > > bit. Frame decoding would remain distinct as CODA being zero on its > > own would indicate a 7-byte frame for either 2400 or 600 bps rate and > > the use of 600 bps speech coding could be deduced from the RTP > > timestamp (and anticipated by the SDP negotiations). > > > > I think this change would be sufficient to address your concern about what to expect for CODB. > > This looks like the minimal sufficient change, yes. (I use "minimal" > because I would say more if I was writing it, but I don't think I can insist that you write it the way I would -- it's your document after all!) > > > 2. Packing and unpacking > > > > You are correct that I am trying to vaguely describe a middle layer shim that is neither RTP nor speech coder. So it definitely does need to be clear. The vagueness comes from the speech coder description being a FOUO document. Its now unclassified so I can potentially say more (and I did make some enhancements of the parameter description already). > > > > So I am trying to understand exactly what you think is vague in our current description: > > > > TSVCIS augmented speech data is derived from the signal processing > > and data already performed by the MELPe speech coder. For the > > purposes of this specification, only the general parameter nature of > > TSVCIS will be characterized. Depending on the bandwidth available > > (and FEC requirements), a varying number of TSVCIS-specific speech > > coder parameters need to be transported. These are first byte-packed > > and then conveyed from encoder to decoder. > > > > Byte packing of TSVCIS speech data into packed parameters is > > processed as per the following example: > > > > Three-bit field: bits A, B, and C (A is MSB, C is LSB) > > Five-bit field: bits D, E, F, G, and H (D is MSB, H is LSB) > > > > MSB LSB > > 0 1 2 3 4 5 6 7 > > +------+------+------+------+------+------+------+------+ > > | H | G | F | E | D | C | B | A | > > +------+------+------+------+------+------+------+------+ > > > > This packing method places the three-bit field "first" in the lowest > > bits followed by the next five-bit field. Parameters may be split > > between octets with the most significant bits in the earlier octet. > > Any unfilled bits in the last octet MUST be filled with zero. > > [not actually relevant to the Discuss part, but if there is always exactly one 3-bit parameter and one 5-bit parameter, then this text allowing splitting across octets will never be used and is potentially confusing to mention.] > > > In order to accommodate a varying amount of TSVCIS augmented speech > > data, it is only necessary to specify the number of octets containing > > the packed TSVCIS parameters. The encoding to do so is presented > > in > > I think the "only necessary to specify the number of octets" is the key stumbling point, for me -- I need to know the number of octets as well as the order of the parameters within the list, which is more information than just the number of octets. > > > Section 3.2. TSVCIS specifically uses the NRL VDR in two > > configurations using 15 and 35 packed octet parameters [TSVCIS]. > > I think I failed to internalize the "two configurations using 15 and 35 packed octet parameters" the first time I read the document, as this does help give the reader a clue that [TSVCIS] gives a good picture of what parameters go where. So it seems like we could easily append to that, for "using a fixed set of 15 and 35 packed octet parameters in a fixed order [TSVCIS]" and that would resolve my concerns. > > > The speech coder description of the parameters is the following: > > > > > > > > So the three bit pitch is first (bits 56 to 58), followed by a five bit amplitude (bits 59 to 63) and then an array of spectral components, each 8-bit wide (starting at bit 64). > > [And maybe TSVCIS specifes that the spectral components are derived from some fundamental harmonic decomposition that naturally quantizes to a number-of-parameters/accuracy tradeoff with a natural order. If so, we could also rely on that instead of my proposed change above; let me know if you want to explore that path further.] > > > Based on this information, I’m not sure what we should add to our > > draft to make the description of packing/unpacking clearer. Can you > > make any suggestions or does this table help you with what you did not > > know? (I don’t think I should put this table into the draft RFC > > however.) > > Hopefully the above helps to clarify. > > Thanks, and sorry for the delay. > > -Ben > > > Thanks for your attention and comments. > > > > Victor & Dave > > > > > > > > -----Original Message----- > > From: Barry Leiba > > Sent: Friday, February 14, 2020 7:38 AM > > To: Benjamin Kaduk > > Cc: victor.demjanenko@vocal.com; Roni Even (A) ; > > The IESG ; Catherine Meadows > > ; IETF SecDir ; > > draft-ietf-payload-tsvcis@ietf.org; Ali Begen > > ; avtcore-chairs@ietf.org; avt@ietf.org; > > Dave Satterlee (Vocal) ; IETF discussion > > list ; draft-ietf-payload-tsvcis.all@ietf.orgygv > > Subject: Re: Benjamin Kaduk's Discuss on draft-ietf-payload-tsvcis-03: > > (with DISCUSS and COMMENT) > > > > This is still outstanding, since November. Victor, where are we on this one? > > > > Barry > > > > On Mon, Nov 25, 2019 at 1:46 AM Benjamin Kaduk wrote: > > > > > > Hi Victor, > > > > > > On Tue, Nov 19, 2019 at 03:14:21PM -0500, victor.demjanenko@vocal.com wrote: > > > > Hi Ben, > > > > > > > > Sorry I overlooked sending you a response. I would like to > > > > address the two concerns you have by explaining what the speech coders are doing. > > > > > > Thanks for the extra clarifications. To supply one of my own: I'm > > > not concerned that the protocol doesn't work as implemented, but > > > just want to make sure that the document includes enough information > > > to admit new implementations without guesswork. That is to say, > > > "either tell me how to do it or tell me where to look that tells me how to do it". > > > > > > > WRT to 600 bps MELP, there is one TSVCIS mode that uses one bit > > > > beyond the 54-bit frame for MELP 600 as a frame sync which alternates between frames. > > > > With two or more MELP 600bps frames in one RTP packet, if any > > > > frame indicates 600 bps by CODA being 0 and CODB being 1, then we > > > > know the stream is 600bps. If there is a single frame in an RTP > > > > packet, you can still deduce this by looking at every other RTP > > > > packet (every other MELP 600bps > > > > frame) and by the timestamp advance. Most likely the two ends > > > > would negotiate 600 bps in SDP anyways so there really should not > > > > be a problem. I know it's not pretty but its workable. I hope > > > > this explanation helps you with the concerns for this issue. > > > > > > In this case, the use as an "end-to-end framing bit" (i.e., the > > > alternating behavior you describe above) is not explicitly stated; > > > one might imagine a scheme where the framing usage is to have the > > > bit cycle through 1, 1, 0, and 0, or some other scheme. I'd suggest > > > to note in the document that if any instance of (CODA, CODB) == (0, > > > 1) is observed, then the 600bps mode is in use. It might also be > > > helpful to include the observation that two successive MELPe > > > payloads with CODA == CODB == 0 indicates the 2400bps mode (and that > > > seeing them in a single RTP packet is decisive, whereas additional > > > information about packet non-loss would be needed in the > > > one-MELPe-frame-per-RTP-packet case), but that would be a fair bit > > > of additional text and might be diminishing returns. (Or, of > > > course, the use of CODB as an alternating 1/0 bit as the framing > > > usage could be documented > > > instead.) > > > > > > > As for the TSVCIS parameter packing/unpacking, this is really > > > > simple. There is exactly on three bit parameter, exactly one five > > > > bit parameter and a variable number of eight bit parameters. In > > > > our view, the speech coder itself (or a wrapper for it) is > > > > responsible for preparing the block of octets. RTP then just > > > > transports it. On receive, the complementary wrapper reverses the packing operation. > > > > I hope this clarifies and explains the simplicity. > > > > > > That's exactly what I expected to happen; however, it's not what I > > > believe the current text of the document is describing. > > > Specifically, I think that the current text implies that the > > > "preparing the block of octets" and "complementary wrapper reverses > > > the packing operation" are supposed to be part of the RTP payload > > > format that this document describes, but this document does not have > > > enough information to actually perform those operations reversibly. > > > If the packing is to be done in the speech coder, then this document > > > doesn't need to talk about the packing at all (e.g., at the end of > > > Section 2); if we need to keep the packing/wrapper in this document > > > then we need to indicate that there's a defined priority order for > > > the (8-octet) TSVCIS parameters in the TSVCIS references, to allow the packing/unpacking to be deterministic. > > > > > > Thanks, > > > > > > Ben > > > > > > > > > > > -----Original Message----- > > > > From: Benjamin Kaduk > > > > Sent: Thursday, October 31, 2019 8:12 PM > > > > To: Barry Leiba > > > > Cc: victor.demjanenko@vocal.com; Roni Even (A) > > > > ; The IESG ; Catherine > > > > Meadows ; IETF SecDir > > > > ; draft-ietf-payload-tsvcis@ietf.org; Ali Begen > > > > ; avtcore-chairs@ietf.org; > > > > avt@ietf.org; Dave Satterlee (Vocal) ; > > > > IETF discussion list ; > > > > draft-ietf-payload-tsvcis.all@ietf.org > > > > Subject: Re: Benjamin Kaduk's Discuss on > > > > draft-ietf-payload-tsvcis-03: (with DISCUSS and COMMENT) > > > > > > > > I don't think so, unfortunately. > > > > > > > > I do see the clarification about CODB's potential for deviation > > > > from Table 1, that only the 600 bps MELPe is allowed to deviate, > > > > and that CODA gets us to "it's one of 2400 or 600 bps" and the RTP > > > > timestamp disambiguates that > > > > 600 bps is in use. But, it seems that this means that the > > > > recipient in general should not rely on CODB to differentiate 600 > > > > from 2400 bps, and instead is more robustly implemented by > > > > *always* using the RTP timestamp to detect 600 bps, since that > > > > will always work and CODB will sometimes not work under conditions > > > > not fully specified here. So, if we are unwilling or unable to > > > > clarify what those conditions are (e.g., whether at a minimum > > > > mutual agreement is required), then I think we need to describe > > > > this procedure of consulting the RTP timestamp as the default behavior and avoid giving the impression that CODB should be used to do so. > > > > > > > > Additionally, I don't see anything to address my concern about > > > > TSVCIS parameter decoding. To be clear, the procedure I see this > > > > document describing is that: > > > > - TSVCIS gives parameters (and their lengths in bits) to the codec > > > > described in this document > > > > - this document specifies how to densely encode those parameters into a > > > > byetstream > > > > - RTP transmits that encoded bytestream to the peer > > > > - the codec specified by this is responsible for turning that encoded > > > > bystream back into a list of TSVCIS parameters (and their length > > > > in bits) > > > > > > > > I don't see how that last step is attainable with only the > > > > information provided by this document. I *assume* that one of the > > > > TSVCIS specifications has a canonical (ordered) listing of > > > > parameters, and that the list of parmeters given to this codec in > > > > the first step will always be an initial prefix of that list, but > > > > that's just me guessing at how to make sense of the stated > > > > procedure given insufficient information. I don't think it's > > > > appropriate to make the reader of an RFC guess at what to do; we > > > > need to either say how to do it or give a pointer to an external reference that does. > > > > > > > > -Ben > > > > > > > > On Tue, Oct 29, 2019 at 02:26:09PM -0400, Barry Leiba wrote: > > > > > Ben, does the -04 version address everything? > > > > > > > > > > Barry > > > > > > > > > > On Thu, Oct 24, 2019 at 1:42 PM wrote: > > > > > > > > > > > > I forgot to address security comments in one email. The changes are: > > > > > > > > > > > > Section 8, second paragraph - Suggested edit by reviewer > > > > > > > > > > > > (was) > > > > > > This RTP payload format and the TSVCIS decoder do not exhibit any > > > > > > significant non-uniformity in the receiver-side computational > > > > > > complexity for packet processing and thus are unlikely to pose a > > > > > > denial-of-service threat due to the receipt of pathological data. > > > > > > Additionally, the RTP payload format does not contain any active > > > > > > content. > > > > > > > > > > > > (now) > > > > > > This RTP payload format and the TSVCIS decoder, to the best of our > > > > > > knowledge, do not exhibit any significant non-uniformity in the > > > > > > receiver-side computational complexity for packet processing and thus > > > > > > are unlikely to pose a denial-of-service threat due to the receipt of > > > > > > pathological data. Additionally, the RTP payload format does not > > > > > > contain any active content. > > > > > > > > > > > > > > > > > > Section 8, third paragraph - Suggested edit by reviewer > > > > > > > > > > > > (was) > > > > > > Please see the security considerations discussed in [RFC6562] > > > > > > regarding VAD and its effect on bitrates. > > > > > > > > > > > > (now) > > > > > > Please see the security considerations discussed in [RFC6562] > > > > > > regarding Voice Activity Detect (VAD) and its effect on bitrates. > > > > > > > > > > > > Victor > > > > > > > > > > > > -----Original Message----- > > > > > > From: victor.demjanenko@vocal.com > > > > > > > > > > > > Sent: Thursday, October 24, 2019 10:05 AM > > > > > > To: 'Roni Even (A)' ; 'Benjamin Kaduk' > > > > > > ; 'The IESG' > > > > > > Cc: draft-ietf-payload-tsvcis@ietf.org; 'Ali Begen' > > > > > > ; avtcore-chairs@ietf.org; > > > > > > avt@ietf.org; 'Dave Satterlee (Vocal)' > > > > > > > > > > > > Subject: RE: Benjamin Kaduk's Discuss on > > > > > > draft-ietf-payload-tsvcis-03: (with DISCUSS and COMMENT) > > > > > > > > > > > > Hi Everyone, > > > > > > > > > > > > First we want to thank everyone for their review and comments > > > > > > for this > > > > draft RFC. We believe we reviewed all the comments and > > > > suggestions and incorporated them adequately in the next draft > > > > (04). We'd like to send out this list of exact changes in case > > > > anyone has additional comments or thinks the clarifications are > > > > inadequate. We would be most happy to address concerns before publishing draft 04 tomorrow. > > > > > > > > > > > > With so many emails from a half dozen or more reviewers, we > > > > > > apologize > > > > that we cannot address each sender individually. We hope this > > > > detail is sufficient for everyone. > > > > > > > > > > > > Again, many thanks to all. > > > > > > > > > > > > Victor & Dave > > > > > > > > > > > > -------------------------------------------------------------- > > > > > > -- > > > > > > ---- > > > > > > -------------------------- > > > > > > > > > > > > Section 1.1 - Suggested reference to RFC 8088 added. > > > > > > > > > > > > (was) > > > > > > Best current practices for writing an RTP payload format > > > > > > specification were followed [RFC2736]. > > > > > > > > > > > > (now) > > > > > > Best current practices for writing an RTP payload format > > > > > > specification were followed [RFC2736] [RFC8088]. > > > > > > > > > > > > > > > > > > Section 2, paragraphs 3 and 4 - Suggested edits by reviewers > > > > > > > > > > > > (was) > > > > > > In addition to the augmented speech data, the TSVCIS specification > > > > > > identifies which speech coder and framing bits are to be encrypted, > > > > > > and how they are protected by forward error correction (FEC) > > > > > > techniques (using block codes). At the RTP transport layer, only the > > > > > > speech coder related bits need to be considered and are conveyed in > > > > > > unencrypted form. In most IP-based network deployments, standard > > > > > > link encryption methods (SRTP, VPNs, FIPS 140 link encryptors or Type > > > > > > 1 Ethernet encryptors) would be used to secure the RTP speech > > > > > > contents. Further, it is desirable to support the highest voice > > > > > > quality between endpoints which is only possible without the overhead > > > > > > of FEC. > > > > > > > > > > > > TSVCIS augmented speech data is derived from the signal processing > > > > > > and data already performed by the MELPe speech coder. For the > > > > > > purposes of this specification, only the general parameter nature of > > > > > > TSVCIS will be characterized. Depending on the bandwidth available > > > > > > (and FEC requirements), a varying number of TSVCIS specific speech > > > > > > coder parameters need to be transported. These are first byte-packed > > > > > > and then conveyed from encoder to decoder. > > > > > > > > > > > > (now) > > > > > > In addition to the augmented speech data, the TSVCIS specification > > > > > > identifies which speech coder and framing bits are to be encrypted, > > > > > > and how they are protected by forward error correction (FEC) > > > > > > techniques (using block codes). At the RTP transport layer, only the > > > > > > speech-coder-related bits need to be considered and are conveyed in > > > > > > unencrypted form. In most IP-based network deployments, standard > > > > > > link encryption methods (SRTP, VPNs, FIPS 140 link encryptors or Type > > > > > > 1 Ethernet encryptors) would be used to secure the RTP speech > > > > > > contents. > > > > > > > > > > > > TSVCIS augmented speech data is derived from the signal processing > > > > > > and data already performed by the MELPe speech coder. For the > > > > > > purposes of this specification, only the general parameter nature of > > > > > > TSVCIS will be characterized. Depending on the bandwidth available > > > > > > (and FEC requirements), a varying number of TSVCIS-specific speech > > > > > > coder parameters need to be transported. These are first byte-packed > > > > > > and then conveyed from encoder to decoder. > > > > > > > > > > > > > > > > > > Section 3, last sentence paragraph 3 - Suggested edit by > > > > > > reviewer > > > > > > > > > > > > (was) > > > > > > When more than one codec data frame is > > > > > > present in a single RTP packet, the timestamp is, as always, that of > > > > > > the oldest data frame represented in the RTP packet. > > > > > > > > > > > > (now) > > > > > > When more than one codec data frame is > > > > > > present in a single RTP packet, the timestamp specified is that of > > > > > > the oldest data frame represented in the RTP packet. > > > > > > > > > > > > > > > > > > Section 3.1, last paragraph - Clarified permission for MELP > > > > > > 600 end-to-end framing bit > > > > > > > > > > > > (was) > > > > > > It should be noted that CODB for both the 2400 and 600 bps modes MAY > > > > > > deviate from the values in Table 1 when bit 55 is used as an end-to- > > > > > > end framing bit. Frame decoding would remain distinct as CODA being > > > > > > zero on its own would indicate a 7-byte frame for either rate and the > > > > > > use of 600 bps speech coding could be deduced from the RTP timestamp > > > > > > (and anticipated by the SDP negotiations). > > > > > > > > > > > > (now) > > > > > > It should be noted that CODB for MELPe 600 bps mode MAY deviate from > > > > > > the value in Table 1 when bit 55 is used as an end-to-end framing > > > > > > bit. Frame decoding would remain distinct as CODA being zero on its > > > > > > own would indicate a 7-byte frame for either 2400 or 600 bps rate and > > > > > > the use of 600 bps speech coding could be deduced from the RTP > > > > > > timestamp (and anticipated by the SDP negotiations). > > > > > > > > > > > > > > > > > > Section 3.2, first paragraph - Clarifications requested by > > > > > > reviewers > > > > > > > > > > > > (was) > > > > > > The TSVCIS augmented speech data as packed parameters MUST be placed > > > > > > immediately after a corresponding MELPe 2400 bps payload in the same > > > > > > RTP packet. The packed parameters are counted in octets (TC). In > > > > > > the preferred placement, shown in Figure 6, a single trailing octet > > > > > > SHALL be appended to include a two-bit rate code, CODA and CODB, > > > > > > (both bits set to one) and a six-bit modified count (MTC). The > > > > > > special modified count value of all ones (representing a MTC value of > > > > > > 63) SHALL NOT be used for this format as it is used as the indicator > > > > > > for the alternate packing format shown next. In a standard > > > > > > implementation, the TSVCIS speech coder uses a minimum of 15 octets > > > > > > for parameters in octet packed form. The modified count (MTC) MUST > > > > > > be reduced by 15 from the full octet count (TC). Computed MTC = TC- > > > > > > 15. This accommodates a maximum of 77 parameter octets (maximum > > > > > > value of MTC is 62, 77 is the sum of 62+15). > > > > > > > > > > > > (now) > > > > > > The TSVCIS augmented speech data as packed parameters MUST be placed > > > > > > immediately after a corresponding MELPe 2400 bps payload in the same > > > > > > RTP packet. The packed parameters are counted in octets (TC). The > > > > > > preferred placement SHOULD be used for TSVCIS payloads with TC less > > > > > > than or equal to 77 octets, is shown in Figure 6. In the preferred > > > > > > placement, a single trailing octet SHALL be appended to include a > > > > > > two-bit rate code, CODA and CODB, (both bits set to one) and a six- > > > > > > bit modified count (MTC). The special modified count value of all > > > > > > ones (representing a MTC value of 63) SHALL NOT be used for this > > > > > > format as it is used as the indicator for the alternate packing > > > > > > format shown next. In a standard implementation, the TSVCIS speech > > > > > > coder uses a minimum of 15 octets for parameters in octet packed > > > > > > form. The modified count (MTC) MUST be reduced by 15 from the full > > > > > > octet count (TC). Computed MTC = TC-15. This accommodates a maximum > > > > > > of 77 parameter octets (maximum value of MTC is 62, 77 is the sum of > > > > > > 62+15). > > > > > > > > > > > > > > > > > > Section 3.3, first paragraph - Suggested edit by reviewer > > > > > > > > > > > > (was) > > > > > > A TSVCIS RTP packet consists of zero or more TSVCIS coder frames > > > > > > (each consisting of MELPe and TSVCIS coder data) followed by zero or > > > > > > one MELPe comfort noise frame. The presence of a comfort noise frame > > > > > > can be determined by its rate code bits in its last octet. > > > > > > > > > > > > (now) > > > > > > A TSVCIS RTP packet payload consists of zero or more consecutive > > > > > > TSVCIS coder frames (each consisting of MELPe 2400 and TSVCIS coder > > > > > > data), with the oldest frame first, followed by zero or one MELPe > > > > > > comfort noise frame. The presence of a comfort noise frame can be > > > > > > determined by its rate code bits in its last octet. > > > > > > > > > > > > > > > > > > Section 3.3, fourth paragraph - Clarification requested by > > > > > > reviewers > > > > > > > > > > > > (was) > > > > > > TSVCIS coder frames in a single RTP packet MAY be of different coder > > > > > > bitrates. With the exception for the variable length TSVCIS > > > > > > parameter frames, the coder rate bits in the trailing byte identify > > > > > > the contents and length as per Table 1. > > > > > > > > > > > > (now) > > > > > > TSVCIS coder frames in a single RTP packet MAY have varying TSVCIS > > > > > > parameter octet counts. Its packed parameter octet count (length) is > > > > > > indicated in the trailing byte(s). All MELPe frames in a single RTP > > > > > > packet MUST be of the same coder bitrate. For all MELPe coder > > > > > > frames, the coder rate bits in the trailing byte identify the > > > > > > contents and length as per Table 1. > > > > > > > > > > > > > > > > > > Section 4.1 - Editor note removed > > > > > > > > > > > > > > > > > > Section 4.1 - Change controller is now > > > > > > > > > > > > (now) > > > > > > Change controller: IETF, contact > > > > > > > > > > > > > > > > > > Section 5, first paragraph - Suggested edits by reviewers > > > > > > > > > > > > (was) > > > > > > A primary application of TSVCIS is for radio communications of voice > > > > > > conversations, and discontinuous transmissions are normal. When > > > > > > TSVCIS is used in an IP network, TSVCIS RTP packet transmissions may > > > > > > cease and resume frequently. RTP synchronization source (SSRC) > > > > > > sequence number gaps indicate lost packets to be filled by PLC, while > > > > > > abrupt loss of RTP packets indicates intended discontinuous > > > > > > transmissions. > > > > > > > > > > > > (now) > > > > > > A primary application of TSVCIS is for radio communications of voice > > > > > > conversations, and discontinuous transmissions are normal. When > > > > > > TSVCIS is used in an IP network, TSVCIS RTP packet transmissions may > > > > > > cease and resume frequently. RTP synchronization source (SSRC) > > > > > > sequence number gaps indicate lost packets to be filled by Packet > > > > > > Loss Concealment (PLC), while abrupt loss of RTP packets indicates > > > > > > intended discontinuous transmissions. Resumption of voice > > > > > > transmission SHOULD be indicated by the RTP marker bit (M) set to 1. > > > > > > > > > > > > > > > > > > Section 10 - Added reference > > > > > > > > > > > > (added) > > > > > > [RFC8088] Westerlund, M., "How to Write an RTP Payload Format", > > > > > > RFC 8088, DOI 10.17487/RFC8088, May 2017, > > > > > > . > > > > > > > > > > > > -------------------------------------------------------------- > > > > > > -- > > > > > > ---- > > > > > > ----------------------------- > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Roni Even (A) > > > > > > Sent: Sunday, October 6, 2019 2:09 AM > > > > > > To: victor.demjanenko@vocal.com; 'Benjamin Kaduk' > > > > > > ; 'The IESG' > > > > > > Cc: draft-ietf-payload-tsvcis@ietf.org; 'Ali Begen' > > > > > > ; avtcore-chairs@ietf.org; > > > > > > avt@ietf.org; 'Dave Satterlee (Vocal)' > > > > > > > > > > > > Subject: RE: Benjamin Kaduk's Discuss on > > > > > > draft-ietf-payload-tsvcis-03: (with DISCUSS and COMMENT) > > > > > > > > > > > > Hi, > > > > > > About the reference to TSVCIS. > > > > > > The RTP payload is about how to encapsulate the payload in an > > > > > > RTP > > > > packet. The objective is to define how an RTP stack can insert the > > > > tsvcis frames and extract the tsvcis frames from the RTP packet. > > > > Typically it is not required to understand the payload structure > > > > in order to be able to perform the encapsulation. > > > > > > This is why the reference to the payload is Informational and > > > > > > we did not require to have it publically available. If there > > > > > > is a need to understand the payload itself for the > > > > > > encapsulating than we need more information in the RTP payload > > > > > > specification and a publically available normative reference. > > > > > > I think this is not the case here > > > > > > > > > > > > Roni Even > > > > > > > > > > > > AVTCore co-chair (ex Payload) > > > > > > > > > > > > -----Original Message----- > > > > > > From: victor.demjanenko@vocal.com > > > > > > [mailto:victor.demjanenko@vocal.com] > > > > > > Sent: Saturday, October 05, 2019 12:18 AM > > > > > > To: 'Benjamin Kaduk'; 'The IESG' > > > > > > Cc: draft-ietf-payload-tsvcis@ietf.org; 'Ali Begen'; > > > > avtcore-chairs@ietf.org; avt@ietf.org; 'Victor Demjanenko, Ph.D.'; > > > > 'Dave Satterlee (Vocal)' > > > > > > Subject: RE: Benjamin Kaduk's Discuss on > > > > > > draft-ietf-payload-tsvcis-03: (with DISCUSS and COMMENT) > > > > > > > > > > > > Everyone, > > > > > > > > > > > > Thanks for the comments. I think I mis-understood the > > > > > > ambiguity with > > > > respect to to changing rates within a RTP packet. That was not > > > > plan. An RTP packet must have MELP speech frames of the same rate. > > > > What is possible is that the amount of augmented TSVCIS speech > > > > data may vary from one speech frame to the next. This allows for > > > > a dynamic VDR as suggested by the NRL paper. So an RTP packet may > > > > have varying TSVCIS data but must always have MELPe 2400 data. > > > > > > > > > > > > Again backwards parsing is necessary but the timestamp > > > > > > uniformly > > > > increments 22.5msec per combined MELP/TSVCIS speech frame. > > > > > > > > > > > > The NRL is a good public reference on the VDR aspects. The > > > > > > actual > > > > TSVCIS spec we had was FOUO so we could not replicate its detail. > > > > (I believe a later spec is public or at least partially public. I > > > > am trying to get this.) The opaque data is pretty obvious with the TSVCIS spec in hand. > > > > > > > > > > > > We will address the issues/concerns raised next week. Other > > > > > > business > > > > had priority. > > > > > > > > > > > > Thank you and enjoy the weekend. > > > > > > > > > > > > Regards, > > > > > > > > > > > > Victor & Dave > > > > > > > > > > > > -----Original Message----- > > > > > > From: Benjamin Kaduk via Datatracker > > > > > > Sent: Wednesday, October 2, 2019 10:40 PM > > > > > > To: The IESG > > > > > > Cc: draft-ietf-payload-tsvcis@ietf.org; Ali Begen > > > > > > ; avtcore-chairs@ietf.org; > > > > > > ali.begen@networked.media; avt@ietf.org > > > > > > Subject: Benjamin Kaduk's Discuss on draft-ietf-payload-tsvcis-03: > > > > > > (with DISCUSS and COMMENT) > > > > > > > > > > > > Benjamin Kaduk has entered the following ballot position for > > > > > > draft-ietf-payload-tsvcis-03: Discuss > > > > > > > > > > > > When responding, please keep the subject line intact and reply > > > > > > to all email addresses included in the To and CC lines. (Feel > > > > > > free to cut this introductory paragraph, however.) > > > > > > > > > > > > > > > > > > Please refer to > > > > > > https://www.ietf.org/iesg/statement/discuss-criteria.html > > > > > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > > > > > > > > > > > > > The document, along with other ballot positions, can be found here: > > > > > > https://datatracker.ietf.org/doc/draft-ietf-payload-tsvcis/ > > > > > > > > > > > > > > > > > > > > > > > > -------------------------------------------------------------- > > > > > > -- > > > > > > ---- > > > > > > -- > > > > > > DISCUSS: > > > > > > -------------------------------------------------------------- > > > > > > -- > > > > > > ---- > > > > > > -- > > > > > > > > > > > > I support Magnus' point about the time-ordering of adjacent > > > > > > frames in a > > > > packet. > > > > > > > > > > > > Additionally, I am not sure that there's quite enough here to > > > > > > be > > > > interoperably implementable. Specifically, we seem to be lacking > > > > a description of how an encoder or decoder knows which TSVCIS > > > > parameters, and in what order, to byte-pack or unpack, respectively. > > > > One might surmise that there is a canonical listing in [TSVCIS], > > > > but this document does not say that, and furthermore [TSVCIS] is only listed as an informative reference. > > > > (I couldn't get my hands on my copy, at least on short notice.) > > > > If we limited ourselves to treating the TSVCIS parameters as an > > > > entirely opaque blob (codec, convey these N octets to the peer > > > > with the appropriate one- or two-byte trailer for payload type > > > > identification and framing), that would be interoperably > > > > implementable, since the black-box bits are up to some other codec to interpret. > > > > > > > > > > > > In a similar vein, we mention but do not completely specify > > > > > > the > > > > potential for using CODB as an end-to-end framing bit, in Section > > > > 3.1 (see Comment), which is not interoperably implementable without further details. > > > > > > > > > > > > > > > > > > -------------------------------------------------------------- > > > > > > -- > > > > > > ---- > > > > > > -- > > > > > > COMMENT: > > > > > > -------------------------------------------------------------- > > > > > > -- > > > > > > ---- > > > > > > -- > > > > > > > > > > > > Where is [TSVCIS] available? > > > > > > > > > > > > Is [NRLVDR] the same as > > > > > > https://apps.dtic.mil/dtic/tr/fulltext/u2/a588068.pdf ? A URL > > > > > > in the > > > > references would be helpful. > > > > > > > > > > > > Is additional TSVCIS data only present after 2400bps MELPe and > > > > > > the first > > > > thing to get dropped under bandwidth pressure? The abstract and > > > > introduction imply this by calling out MELPe 2400 bps speech > > > > parameters explicitly, but Section 3 says that TSVCIS augments > > > > standard 600, 1200, and > > > > 2400 bps MELP frames. > > > > > > > > > > > > It's helpful that Section 3.3 gives some general guidance for > > > > > > decoding > > > > this payload type ("[t]he way to determine the number of > > > > TSVCIS/MELPe frames is to identify each frame type and length"), > > > > but I think some generic considerations would be very helpful to > > > > the reader much earlier, along the lines of "MELPe and TSVCIS data > > > > payloads are decoded from the end, using the CODA and CODB (and, > > > > if necessary, CODC and others) bits to determine the type of payload. > > > > For MELPe payloads the type also indicates the payload length, > > > > whereas for TSVCIS data an additional length field is present, in > > > > one of two possible formats. A TSVCIS coder frame consists of a > > > > MELPe data payload followed by zero or one TSVCIS data payload; > > > > after the TSVCIS payload's presence/length is determined, then the > > > > preceding MELPe payload can be determined and decoded. Per > > > > Section 3.3, multiple TSVCIS frames can be present in a single RTP packet." > > > > This (or something like it) would also serve to clarify the role of the COD* bits, which is otherwise only implicitly introduced. > > > > > > > > > > > > Section 1.1 > > > > > > > > > > > > RFC 2736 is BCP 36 (but it's updated by RFC 8088 which is for > > > > > > some > > > > reason an Informational document and not part of BCP 36?!). > > > > > > > > > > > > Section 2 > > > > > > > > > > > > In addition to the augmented speech data, the TSVCIS specification > > > > > > identifies which speech coder and framing bits are to be encrypted, > > > > > > and how they are protected by forward error correction (FEC) > > > > > > techniques (using block codes). At the RTP transport layer, only the > > > > > > speech coder related bits need to be considered and are conveyed in > > > > > > unencrypted form. In most IP-based network deployments, > > > > > > standard > > > > > > > > > > > > Am I reading this correctly that this text is just summarizing > > > > > > what's in > > > > the TSVCIS spec in terms of what needs to be in unencrypted form, > > > > so the "only the speech coder related bits[...]" is not new > > > > information from this document? I'm not sure I agree with the > > > > conclusion, regardless -- won't the > > > > (MELPe) speech coder bits be enough to convey the semantic content > > > > of the audio stream, something that one might desire to keep confidential? > > > > > > > > > > > > link encryption methods (SRTP, VPNs, FIPS 140 link encryptors or Type > > > > > > 1 Ethernet encryptors) would be used to secure the RTP speech > > > > > > contents. Further, it is desirable to support the highest voice > > > > > > quality between endpoints which is only possible without the overhead > > > > > > of FEC. > > > > > > > > > > > > I think I'm missing a step in how this conclusion was reached. > > > > > > > > > > > > TSVCIS will be characterized. Depending on the bandwidth available > > > > > > (and FEC requirements), a varying number of TSVCIS specific speech > > > > > > coder parameters need to be transported. These are first byte-packed > > > > > > and then conveyed from encoder to decoder. > > > > > > > > > > > > Per the Discuss point, how do I know which parameters need to > > > > > > be > > > > transported, and in what order? > > > > > > > > > > > > Byte packing of TSVCIS speech data into packed parameters is > > > > > > processed as per the following example: > > > > > > > > > > > > Three-bit field: bits A, B, and C (A is MSB, C is LSB) > > > > > > Five-bit field: bits D, E, F, G, and H (D is MSB, H is > > > > > > LSB) > > > > > > > > > > > > MSB LSB > > > > > > 0 1 2 3 4 5 6 7 > > > > > > +------+------+------+------+------+------+------+------+ > > > > > > | H | G | F | E | D | C | B | A | > > > > > > > > > > > > +------+------+------+------+------+------+------+------+ > > > > > > > > > > > > This packing method places the three-bit field "first" in the lowest > > > > > > bits followed by the next five-bit field. Parameters may be split > > > > > > between octets with the most significant bits in the earlier octet. > > > > > > Any unfilled bits in the last octet MUST be filled with zero. > > > > > > > > > > > > I agree with Adam that this is very unclear. A is the MSB of > > > > > > the > > > > three-bit field but the LSB of the octet overall? > > > > > > We probably need an example of splitting a parameter across > > > > > > octets as > > > > well, to get the bit ordering right. > > > > > > > > > > > > Section 3.1 > > > > > > > > > > > > It should be noted that CODB for both the 2400 and 600 bps modes MAY > > > > > > deviate from the values in Table 1 when bit 55 is used as an end-to- > > > > > > end framing bit. Frame decoding would remain distinct as > > > > > > CODA being > > > > > > > > > > > > Where is the use of CODB as an end-to-end framing bit defined? > > > > > > If we're > > > > going to provide neither a complete description of how to do it > > > > nor a reference to a better description, we probably shouldn't mention it at all. > > > > > > > > > > > > Section 3.2 > > > > > > > > > > > > RTP packet. The packed parameters are counted in octets (TC). In > > > > > > the preferred placement, shown in Figure 6, a single trailing octet > > > > > > SHALL be appended to include a two-bit rate code, CODA and > > > > > > CODB, > > > > > > > > > > > > I'd consider saying something about this being the preferred > > > > > > format > > > > > > ("placement") due to its shorter length than the alternative, > > > > > > and say > > > > that it "SHOULD be used for TSVCIS payloads with TC less than or > > > > equal to 77 octetes". > > > > > > > > > > > > Section 3.3 > > > > > > > > > > > > When a longer packetization interval is used, is that > > > > > > indicated by > > > > signaling or RTP timestamps or otherwise? > > > > > > > > > > > > TSVCIS coder frames in a single RTP packet MAY be of different coder > > > > > > bitrates. With the exception for the variable length TSVCIS > > > > > > parameter frames, the coder rate bits in the trailing byte identify > > > > > > the contents and length as per Table 1. > > > > > > > > > > > > Maybe also note that the penultimate octet gives the length there? > > > > > > > > > > > > Information describing the number of frames contained in an RTP > > > > > > packet is not transmitted as part of the RTP payload. The way to > > > > > > determine the number of TSVCIS/MELPe frames is to identify each frame > > > > > > type and length thereby counting the total number of octets within > > > > > > the RTP packet. > > > > > > > > > > > > terminology nit: if a frame is the combination of MELPe and > > > > > > TSVCIS > > > > payload data units then there are two layres of decoding to get a > > > > length for the frame, since we have to get the TSVCIS length and then the MELPe length. > > > > > > > > > > > > Section 4.2 > > > > > > > > > > > > Parameter "ptime" cannot be used for the purpose of > > > > > > specifying the > > > > > > > > > > > > nit: missing article ("The parameter") > > > > > > > > > > > > will be impossible to distinguish which mode is about to be used > > > > > > (e.g., when ptime=68, it would be impossible to distinguish if the > > > > > > packet is carrying one frame of 67.5 ms or three frames of 22.5 ms). > > > > > > > > > > > > So how is the operating mode determined, then? > > > > > > (I think this is the same question I asked above) > > > > > > > > > > > > Section 4.4 > > > > > > > > > > > > For example, if offerer bitrates are "2400,600" and answer bitrates > > > > > > are "600,2400", the initial bitrate is 600. If other bitrates are > > > > > > provided by the answerer, any common bitrate between the offer and > > > > > > answer MAY be used at any time in the future. Activation of these > > > > > > other common bitrates is beyond the scope of this document. > > > > > > > > > > > > It seems important to specify whether this requires a new O/A > > > > > > exchange > > > > or can be done "spontaneously" by just encoding different frame types. > > > > > > (It seems like the latter is possible, on first glance, and > > > > > > this is implied by Section 3.3's discussion of mixing them in > > > > > > a single > > > > > > packet.) > > > > > > > > > > > > Section 5 > > > > > > > > > > > > Please expand PLC at first use (not second). > > > > > > > > > > > > Section 6 > > > > > > > > > > > > I don't understand the PLC usage. Is the idea that a > > > > > > receiver, on > > > > seeing an SSRC gap, constructs fictitious PLC frames to "fill the gap" > > > > > > and passes the resulting stream to the decoder? > > > > > > > > > > > > Section 8 > > > > > > > > > > > > and important considerations in [RFC7201]. Applications SHOULD use > > > > > > one or more appropriate strong security mechanisms. The rest of this > > > > > > section discusses the security-impacting properties of the payload > > > > > > format itself. > > > > > > > > > > > > I thought we described TSVCIS itself (much earlier in the > > > > > > document) as > > > > requiring encryption for some data; wouldn't that translate to a "MUST" > > > > > > here and not a "SHOULD"? > > > > > > > > > > > > > > > > > > > > > > > > > Section 2 (first sentence in last paragraph) - Clarification for octet count > > (was) > In order to accommodate a varying amount of TSVCIS augmented speech > data, it is only necessary to specify the number of octets > containing the packed TSVCIS parameters. The encoding to do so is > presented in Section 3.2. TSVCIS specifically uses the NRL VDR in two > configurations using 15 and 35 packed octet parameters [TSVCIS]. > > (now) > In order to accommodate a varying amount of TSVCIS augmented speech > data, an octect count specifies the number of octets representing > the packed TSVCIS parameters. The encoding to do so is presented in > Section 3.2. TSVCIS specifically uses the NRL VDR in two > configurations using a fixed set of 15 and 35 packed octet > parameters in a fixed order [TSVCIS]. > > > Section 3.1 (first sentence in last paragraph) - Clarification for CODA, CODB > > (was) > It should be noted that CODB for MELPe 600 bps mode MAY deviate from > the value in Table 1 when bit 55 is used as an end-to-end framing bit. > > (now) > It should be noted that CODB for MELPe 600 bps mode MAY deviate from > the value in Table 1 when bit 55 is used as an alternating 1/0 > end-to-end framing bit. > > From nobody Fri Apr 10 04:11:42 2020 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 95C393A20BB for ; Fri, 10 Apr 2020 04:11:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Tero Kivinen via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 6.126.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu, Tero Kivinen Message-ID: <158651710013.20888.13474581389281851299@ietfa.amsl.com> Date: Fri, 10 Apr 2020 04:11:40 -0700 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: Fri, 10 Apr 2020 11:11:41 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2020-04-24 Reviewer LC end Draft Donald Eastlake R2019-11-14 draft-ietf-hip-dex-18 Vincent Roca 2020-01-30 draft-ietf-pim-msdp-yang-17 Last calls: Reviewer LC end Draft John Bradley 2020-02-28 draft-ietf-regext-data-escrow-07 Alan DeKok 2019-06-04 draft-ietf-netvc-testing-09 Donald Eastlake 2020-02-27 draft-ietf-6tisch-msf-16 Donald Eastlake R2019-11-14 draft-ietf-hip-dex-18 Daniel Franke 2020-03-09 draft-ietf-regext-dnrd-objects-mapping-06 Scott Kelly 2020-03-18 draft-ietf-sidrops-ov-egress-04 Aanchal Malhotra 2020-03-12 draft-ietf-bess-vpls-multihoming-05 Kathleen Moriarty 2020-03-20 draft-ietf-sidrops-rp-06 Russ Mundy 2020-01-02 draft-ietf-dprive-bcp-op-08 Magnus Nystrom 2020-04-30 draft-iesg-nomcom-eligibility-2020-00 Magnus Nystrom 2019-04-10 draft-ietf-avtcore-multiplex-guidelines-11 Hilarie Orman 2020-04-29 draft-hodges-webauthn-registries-05 Francesca Palombini 2020-04-28 draft-ietf-rtcweb-sdp-11 Radia Perlman 2020-04-17 draft-ietf-idr-bgp-ls-segment-routing-msd-16 Derrell Piper 2020-04-15 draft-ietf-sipcore-sip-token-authnz-12 Tirumaleswar Reddy.K 2020-04-09 draft-ietf-sfc-oam-framework-11 Vincent Roca 2020-04-23 draft-ietf-detnet-ip-over-mpls-05 Vincent Roca 2020-01-30 draft-ietf-pim-msdp-yang-17 Takeshi Takahashi 2020-02-06 draft-ietf-mmusic-t140-usage-data-channel-13 Sean Turner None draft-ietf-opsawg-sdi-02 Paul Wouters R2019-10-18 draft-ietf-taps-transport-security-11 Dacheng Zhang 2020-03-12 draft-nottingham-how-did-that-get-into-the-repo-01 Dacheng Zhang 2019-11-05 draft-ietf-mpls-ri-rsvp-frr-07 Next in the reviewer rotation: Kyle Rose Joseph Salowey Rich Salz Stefan Santesson Yaron Sheffer Rifaat Shekh-Yusef Melinda Shore Valery Smyslov Robert Sparks Takeshi Takahashi From nobody Fri Apr 10 11:11:18 2020 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 923EF3A0C1A; Fri, 10 Apr 2020 11:11:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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 2KVmggMj5_k3; Fri, 10 Apr 2020 11:11:11 -0700 (PDT) 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 D1FD43A0C17; Fri, 10 Apr 2020 11:11:07 -0700 (PDT) Received: by mail-lj1-x234.google.com with SMTP id z26so2731248ljz.11; Fri, 10 Apr 2020 11:11:07 -0700 (PDT) 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=u0Cyhys75mEkhThuDv0rrSYxSX11quEJvdvdIGc+Sos=; b=Ds9dxJ66QIV0fVYiWLnpkd621ElupRd2iVd8kuvOM37r1I+4NaXQps3aMEKU1Xv3eN 4kDHjt6EJ9o1AtTWtDR+MOWOYVfgaAEA/FlJIIjp1BujcHBMeTSg4Kcw0I0R0YUPluEr epPK4fhdpA5dqV5l1kJmhkJRg2IKeAjHwp9Zz2F/Rv4cSZBbtxdUDHauYKw0RQtpbrfI oFrwnpiG8o+zJbnnyRpQEa2ymDM3mRFWHVmdCsMXbQ5AeYhRww8gfemd9CAex5MKncaa 5+6k3h4bPwnjzprrHM3qVAwDLjozuMZD6XLS/wMtwwbAd0D7tjxMW+cjKCBUS5/JPMwV 79Jw== 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=u0Cyhys75mEkhThuDv0rrSYxSX11quEJvdvdIGc+Sos=; b=qcBagHINt6irZQZcr+JaB9M4ddt+r//eE6oNv1sRlLAAiTREe5PjTQHEBi8FCxT3Hf 1kr4550y7kT48yvZJJ6b2Y+0E/IGrwP58ev+OUE5PTIrMEErj3hwE9W0z9R/s4ZxZlkA scvjEMF+DksFp0dZglfN22HO8GZ6QCjzLAX79vVz8ArsEWEKwLSJfyFkkIyBXQo0eUD0 ADnUV20ZzIujGcB8+vzqrJDXLUivYS7fJ1wydFuEoCKUnAwDyqnkrHXgnPlqtii2m2jS P3urliRkw/hpTMVl0K/OOQ1B558Jsw3Say73sH2UUhqwfzs1TzSzl42RlBqo9qxBdAOT ancg== X-Gm-Message-State: AGi0Pubv3rT7eeW3es1bZPEOJymuqkytvJQO5c6OBYiuwXTjcygI9Zzr +r40+ZfpnL0hEo8LuGb/uGHA6xvZrTKuP/cnUpy/wGPA X-Google-Smtp-Source: APiQypL2w4e3zBchNQyMrXAklfC/IqTm0YjU7tADF0yzTP9RBRCU0QLcs30NFsy3YsXxxk/uWHqaFawfvt7X3xJVm/w= X-Received: by 2002:a2e:8ed9:: with SMTP id e25mr3500154ljl.219.1586542265912; Fri, 10 Apr 2020 11:11:05 -0700 (PDT) MIME-Version: 1.0 From: Radia Perlman Date: Fri, 10 Apr 2020 11:10:54 -0700 Message-ID: To: secdir@ietf.org, The IESG , draft-ietf-idr-bgp-ls-segment-routing-msd.all@ietf.org Content-Type: multipart/alternative; boundary="0000000000002e518405a2f3a89b" Archived-At: Subject: [secdir] Secdir review of draft-ietf-idr-bgp-ls-segment-routing-msd-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: Fri, 10 Apr 2020 18:11:13 -0000 --0000000000002e518405a2f3a89b 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. Summary: I have found no issues with the document. This I-D defines two new code points for encoding information in BGP-LS messages. The code points are for maximum segment depth of nodes and links. BGP-LS can deliver this information to a centralized controller that needs it to compute a segment routing path. Without this information, the centralized controller may compute routes that won't work. As noted in Security Considerations, supplying incorrect information using this protocol could cause a centralized controller to compute non-optimal or non-working routes, but so could errors in many other fields of this information. These new fields don't introduce any new security challenges beyond those already present in BGP-LS. Radia --0000000000002e518405a2f3a89b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

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


    Summary: I have found no iss= ues with the document.

    =C2=A0

    This I-D defines two new code points for encodi= ng information in BGP-LS messages. The code points are for maximum segment dep= th of nodes and links. BGP-LS can deliver this information to a centralized controller that needs it to compute a segment routing path. Without this information, the centralized controller may compute routes that won't w= ork.

    =C2=A0

    As noted in Security Considerations, supplying = incorrect information using this protocol could cause a centralized controller to com= pute non-optimal or non-working routes, but so could errors in many other fields= of this information. These new fields don't introduce any new security cha= llenges beyond those already present in BGP-LS.


    =

    Radia

    --0000000000002e518405a2f3a89b-- From nobody Tue Apr 14 14:07:11 2020 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 11CFF3A0FD9; Tue, 14 Apr 2020 14:07:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Derrell Piper via Datatracker To: Cc: draft-ietf-sipcore-sip-token-authnz.all@ietf.org, last-call@ietf.org, sipcore@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.127.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158689842488.27716.15541584374764439587@ietfa.amsl.com> Reply-To: Derrell Piper Date: Tue, 14 Apr 2020 14:07:04 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-sipcore-sip-token-authnz-12 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, 14 Apr 2020 21:07:05 -0000 Reviewer: Derrell Piper Review result: Has Nits Reviewer: Derrell Piper Review result: Ready With Nits I reviewed this document as part of the security directorate's ongoing effort to review all IETF documents entering the IESG. These comments are directed at the security area director(s). Document editors and WG chairs should treat these comments like any other last call comments. This document defines a third-party token authentication scheme for authentication to SIP services using "bearer" tokens from the OAuth 2.0 framework and the OpenID Connect Core 1.0 to support native application assisted (or proxy-based) token-based authentication and authorization. pp. 3, 1., nit "...enables the single-sign-on features, which allows the user to..." "...enables single sign-on, which allows the user to..." pp. 5, last sentence "previously" means "from the out-of-scope mechanism", just say that. pp. 7, 2.1.1 "(or with invalid credentials)" Why continue when a UAC presents invalid credentials? [See below.] pp. 8, 2.1.3 2.1.1 says if you get invalid credentials to go REGISTER, and here in REGISTER, it says if you get invalid credentials, go to 2.1.1. This seems recursive though I'm assuming this ultimately terminates when all the schemes are exhausted without success. Derrell From nobody Tue Apr 14 15:34:19 2020 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 107DA3A11A2; Tue, 14 Apr 2020 15:34:05 -0700 (PDT) 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, SPF_HELO_NONE=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_Djh6wPjRek; Tue, 14 Apr 2020 15:34:03 -0700 (PDT) Received: from mail.hardakers.net (mail.hardakers.net [168.150.192.181]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69ACA3A11A0; Tue, 14 Apr 2020 15:34:03 -0700 (PDT) Received: from localhost (unknown [10.0.0.3]) by mail.hardakers.net (Postfix) with ESMTPA id AE37B2E022; Tue, 14 Apr 2020 15:34:01 -0700 (PDT) From: Wes Hardaker To: Catherine Meadows Cc: , Catherine Meadows , draft-ietf-dnsop-extended-error.all@ietf.org, dnsop@ietf.org, last-call@ietf.org References: <158566679527.28397.11447221654478370153@ietfa.amsl.com> Date: Tue, 14 Apr 2020 15:34:01 -0700 In-Reply-To: <158566679527.28397.11447221654478370153@ietfa.amsl.com> (Catherine Meadows via Datatracker's message of "Tue, 31 Mar 2020 07:59:55 -0700") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-dnsop-extended-error-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, 14 Apr 2020 22:34:05 -0000 Catherine Meadows via Datatracker writes: > Reviewer: Catherine Meadows > Review result: Has Issues Hi Catherine, Thanks for the review of the dnsop-extended-error draft. [and sorry for the delay in sending this] > The Security Considerations section mentions some valid points, but it > is not made clear how they apply to extended DNS error messages (as > opposed to DNS error messages in general). It first makes the > non-obvious point that a significant number of clients, when receiving > a failure message about a DNS validation issue from a validated > resolver, will seek out an unvalidated server instead. It is not > clear to me though whether you think that extending the types of DNS > error messages available (thus giving more information to the client) > would help address this problem. You should say something about this. > Secondly, it discusses the security implications of the fact that DNS > error messages are unauthenticated. > > In addition, in the paragraph about the security implications of DNS error > messages being unauthenticated, you should say whether or not extending the > types of DNS error messages would improve the situation, make it worse, have > no effect, or is unclear. You're right that we don't specify what to do in the security considerations section, though we do earlier in the document. Specifically it says (at least): Applications MUST continue to follow requirements from applicable specifications on how to process RCODEs no matter what EDE values are also received. So maybe adding the following sentence to the security section addresses your issue? EDE content should be treated only as diagnostic information for network operators and MUST NOT alter DNS protocol processing. We could add a note as well about the scope of the document, though I think it can be derived from the above sentence: EDE content is not attempting to address the lack security in DNS error messages. -- Wes Hardaker USC/ISI From nobody Wed Apr 15 00:58:10 2020 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 EA6BF3A1113; Wed, 15 Apr 2020 00:58:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.268 X-Spam-Level: X-Spam-Status: No, score=-2.268 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.168, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=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 jjLvUExLbp40; Wed, 15 Apr 2020 00:58:07 -0700 (PDT) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60071.outbound.protection.outlook.com [40.107.6.71]) (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 8A1CD3A1111; Wed, 15 Apr 2020 00:58:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LhOwBkw3+Pysue0PdzoWdJUzL3Ei+b+OjrjF1atIXZdnZZyDeNB+NNJOjBRO725244+f5HnuajO2LHbQHr430uAcDBwMhH5FZi2qKBiTGcRNfkbaxCv3MDU3r+nq6qxezKYGqwyFl6cFPAsPqKQ/C26lddk43D0QzZQ4/DZWRoKfK/MRBwsv/rvpovx2Uoelm5ZXtygQbGaDSV17MBOdAmEsW9dyUqm5e5IxU6p1TRA17zs4LIt8pphLrVJeMBRaITEJ6qJfZI1QCal82FKgu2Ub1s1hZtjVTCfX10xgkNFSLJLxVxVKmq8w7w1RqT1vdg5wDQ8mZvDd5oaLikJWoA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=RO+kaMSq7ewAQHaCCC9iUxUSR7/BgnCmepeQ+IRgIRo=; b=g3/gIoL0JtsSEgzDwaf/BwcPed0NraNeht0Ewc9JMLFve18VnxdKPSxoUTC0+nfUH7bCnyA1NYb/osbMN4Y3j3gXRTelJYv/apETDh7lurEMTjzUUUAkBVqMrUdGljdwz8nLmKMsJRroGkzwfyLmLh8HLZj+9FJgvf/nuH3+Z0jVbUeoZk/EWIlNL50poqBygUfU/9jQ28XBSDnXECBWADOuu+T0Hjwv7YT1ifGN/krNIW8cjcichHmaU30I5okM+velCmMpYBT/BtswUDoC9eVS0ElBG7GBVjcfoN1ci8S8ewA5LLPCfmcC7Pb2503INGY2nf5CsqqdgqQrVFd/rQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none 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=RO+kaMSq7ewAQHaCCC9iUxUSR7/BgnCmepeQ+IRgIRo=; b=ML+lbNTTMusdNGFgd28YhmNP+IRhHVMeWmRFlzP6f6HopJ4dts6VWPh2azsDKvkzoDsfQDbe1Izdr0fphlIcUtV458AR2mQfOf7CxmKt04z9ag2oLRVeT6PiR72hyz6IM97NpJUQTJWfFqwLX9RE76GtoNLu5ZgWBM0uwiK1QgQ= Received: from AM0PR07MB3987.eurprd07.prod.outlook.com (2603:10a6:208:46::31) by AM0PR07MB5953.eurprd07.prod.outlook.com (2603:10a6:208:108::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2921.24; Wed, 15 Apr 2020 07:58:01 +0000 Received: from AM0PR07MB3987.eurprd07.prod.outlook.com ([fe80::b929:4e5c:6b46:3ccc]) by AM0PR07MB3987.eurprd07.prod.outlook.com ([fe80::b929:4e5c:6b46:3ccc%7]) with mapi id 15.20.2921.024; Wed, 15 Apr 2020 07:58:01 +0000 From: Christer Holmberg To: Derrell Piper , "secdir@ietf.org" CC: "draft-ietf-sipcore-sip-token-authnz.all@ietf.org" , "last-call@ietf.org" , "sipcore@ietf.org" Thread-Topic: Secdir last call review of draft-ietf-sipcore-sip-token-authnz-12 Thread-Index: AQHWEqCqVuV0L/UOg0qwY4WPA18OQ6h6BDMA Date: Wed, 15 Apr 2020 07:58:01 +0000 Message-ID: <5BABF46F-6BF2-4296-B035-099BF57E0EBE@ericsson.com> References: <158689842488.27716.15541584374764439587@ietfa.amsl.com> In-Reply-To: <158689842488.27716.15541584374764439587@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1e.0.191013 authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [188.127.223.154] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ec9f0c78-5fc6-4ea6-e5e2-08d7e112b84a x-ms-traffictypediagnostic: AM0PR07MB5953: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0374433C81 x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR07MB3987.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(366004)(346002)(396003)(136003)(376002)(39860400002)(2906002)(26005)(44832011)(478600001)(64756008)(2616005)(66556008)(71200400001)(6512007)(8936002)(8676002)(110136005)(81156014)(6486002)(36756003)(33656002)(86362001)(6506007)(4326008)(316002)(54906003)(66446008)(186003)(5660300002)(66946007)(66476007)(76116006); DIR:OUT; SFP:1101; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: XyOsopPx1y5CtV4aI4fvSE1eQ8DXjKwiJtwxadJNudnB7RdcjPwQpdvpBLXgLxlo+qtcUuo8gvw/Z5/7N0rLCcororYiLx+GlXBI1XE+lj9lqZLkj8jYjjgaZT9S4uRDo//BXhok7leGhDee0HGNPuGt5b14Mn7+Jd54ohzE4ozhS5iI1L1RNiSKjblisQ7p31NEnbG0gpbZ8bf0mPKDZnlHwRQjd3rxJzkqNikq/hdmkBXEQrCzGfXNayO3Upfpw7nz/TqLRRbGvL70TKp+Y671Ll6US1TX7ByyzFADCZguG6gzTjnU9M81MLN78Sjl1ng2BNnDPe7bdQmOqbmQ/3MMOltuRLQeZysObKFnRdyPwsCQ5yVZdWvlY/1szI8tEKq6lTymQE/Xzv65ZTPmwWQDE3Mr5i9+nYwmJVwg9C+cPYPot3DO58YPjGuSpEOa x-ms-exchange-antispam-messagedata: 1+6clEOTZ6FWNjhjd2jxo3/vNm4kEi6dx7HwOf7JeVNt8eXf4wyH0HE9BNZhNjDUrjZwm6m2RFz3UonnsUJiQI7L93q6KfDZv5tlI5VwYv/SEc3jcxhQ+tBG+NYj/V6Q+Qt5oI4tC5B4QwUBKRm8ug== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: ec9f0c78-5fc6-4ea6-e5e2-08d7e112b84a X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Apr 2020 07:58:01.2882 (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-CrossTenant-userprincipalname: puKI799SAUQnDNRSwaSP9iQfn+c/zRQIWr5HaGK68IoeIAGQnTNSVMGiylwN5q9fUmLpja1vC0i+TT8NLEJinUHhG1CSD8frImU6ZGSAQnA= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB5953 Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-sipcore-sip-token-authnz-12 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, 15 Apr 2020 07:58:08 -0000 SGkgRGVycmVsbCwNCg0KVGhhbmsgWW91IGZvciB0aGUgcmV2aWV3ISBQbGVhc2Ugc2VlIGlubGlu ZS4NCiAgICANCj4gICAgcHAuIDMsIDEuLCBuaXQNCj4gICAgDQo+ICAgICIuLi5lbmFibGVzIHRo ZSBzaW5nbGUtc2lnbi1vbiBmZWF0dXJlcywgd2hpY2ggYWxsb3dzIHRoZSB1c2VyIHRvLi4uIg0K PiAgICANCj4gICAgIi4uLmVuYWJsZXMgc2luZ2xlIHNpZ24tb24sIHdoaWNoIGFsbG93cyB0aGUg dXNlciB0by4uLiINCiAgDQpXZSBjYW4gZml4IGFzIHN1Z2dlc3RlZC4NCg0KLS0tDQogIA0KPiAg ICBwcC4gNSwgbGFzdCBzZW50ZW5jZQ0KPiAgICANCj4gICAgInByZXZpb3VzbHkiIG1lYW5zICJm cm9tIHRoZSBvdXQtb2Ytc2NvcGUgbWVjaGFuaXNtIiwganVzdCBzYXkgdGhhdC4NCiAgDQpJIHRo aW5rIHRoYXQgc291bmRzIGEgbGl0dGxlICJjbHVtc3kiIHRvIHJlcGVhdCBpdC4gV291bGQgaXQg d29yayBpZiB3ZSBzYWlkICJvYnRhaW5lZCBpbiB0aGUgc3RlcCBhYm92ZSIsIG9yIHNvbWV0aGlu ZyBsaWtlIHRoYXQ/DQoNCi0tLQ0KICANCj4gICAgcHAuIDcsIDIuMS4xDQo+ICAgIA0KPiAgICAi KG9yIHdpdGggaW52YWxpZCBjcmVkZW50aWFscykiDQo+ICAgIA0KPiAgICBXaHkgY29udGludWUg d2hlbiBhIFVBQyBwcmVzZW50cyBpbnZhbGlkIGNyZWRlbnRpYWxzPyAgW1NlZSBiZWxvdy5dDQo+ DQo+ICANCj4gICAgcHAuIDgsIDIuMS4zDQo+ICAgIA0KPiAgICAyLjEuMSBzYXlzIGlmIHlvdSBn ZXQgaW52YWxpZCBjcmVkZW50aWFscyB0byBnbyBSRUdJU1RFUiwgYW5kIGhlcmUgaW4NCj4gICAg UkVHSVNURVIsIGl0IHNheXMgaWYgeW91IGdldCBpbnZhbGlkIGNyZWRlbnRpYWxzLCBnbyB0byAy LjEuMS4gIFRoaXMNCj4gICAgc2VlbXMgcmVjdXJzaXZlIHRob3VnaCBJJ20gYXNzdW1pbmcgdGhp cyB1bHRpbWF0ZWx5IHRlcm1pbmF0ZXMgd2hlbiBhbGwNCj4gICAgdGhlIHNjaGVtZXMgYXJlIGV4 aGF1c3RlZCB3aXRob3V0IHN1Y2Nlc3MuDQogIA0KU2VjdGlvbiAyLjEuMSBkZWZpbmVzIGdlbmVy aWMgcHJvY2VkdXJlcywgd2hpbGUgc2VjdGlvbiAyLjEuMyBkZWZpbmVzIHRoZSBwcm9jZWR1cmVz IHNwZWNpZmljIGZvciB0aGUgUkVHSVNURVIgcmVxdWVzdC4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0 ZXINCg0KICAgIA0KICAgIA0KICAgIA0KICAgIA0KDQo= From nobody Wed Apr 15 03:55:22 2020 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 8DD3C3A0AF8 for ; Wed, 15 Apr 2020 03:55:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Tero Kivinen via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 6.127.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu, Tero Kivinen Message-ID: <158694812156.19962.18072558985386049716@ietfa.amsl.com> Date: Wed, 15 Apr 2020 03:55:21 -0700 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, 15 Apr 2020 10:55:22 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2020-04-24 Reviewer LC end Draft Donald Eastlake R2019-11-14 draft-ietf-hip-dex-18 David Mandelberg R2020-04-02 draft-ietf-core-stateless-06 Vincent Roca 2020-01-30 draft-ietf-pim-msdp-yang-17 Last calls: Reviewer LC end Draft John Bradley 2020-02-28 draft-ietf-regext-data-escrow-07 Alan DeKok 2019-06-04 draft-ietf-netvc-testing-09 Donald Eastlake 2020-02-27 draft-ietf-6tisch-msf-16 Donald Eastlake R2019-11-14 draft-ietf-hip-dex-18 Daniel Franke 2020-03-09 draft-ietf-regext-dnrd-objects-mapping-06 Aanchal Malhotra 2020-03-12 draft-ietf-bess-vpls-multihoming-05 David Mandelberg R2020-04-02 draft-ietf-core-stateless-06 Russ Mundy 2020-01-02 draft-ietf-dprive-bcp-op-08 Magnus Nystrom 2019-04-10 draft-ietf-avtcore-multiplex-guidelines-11 Hilarie Orman 2020-04-29 draft-hodges-webauthn-registries-05 Francesca Palombini 2020-04-28 draft-ietf-rtcweb-sdp-11 Tirumaleswar Reddy.K 2020-04-09 draft-ietf-sfc-oam-framework-13 Vincent Roca 2020-04-23 draft-ietf-detnet-ip-over-mpls-05 Vincent Roca 2020-01-30 draft-ietf-pim-msdp-yang-17 Sean Turner None draft-ietf-opsawg-sdi-02 Paul Wouters R2019-10-18 draft-ietf-taps-transport-security-11 Dacheng Zhang 2020-03-12 draft-nottingham-how-did-that-get-into-the-repo-01 Dacheng Zhang 2019-11-05 draft-ietf-mpls-ri-rsvp-frr-07 Next in the reviewer rotation: Kyle Rose Joseph Salowey Rich Salz Stefan Santesson Yaron Sheffer Rifaat Shekh-Yusef Melinda Shore Valery Smyslov Robert Sparks Takeshi Takahashi From nobody Wed Apr 15 08:49:14 2020 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 02CE43A0B1C; Wed, 15 Apr 2020 08:48:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Paul Wouters via Datatracker To: Cc: draft-ietf-taps-transport-security.all@ietf.org, taps@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.127.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158696570597.6243.17363184130849112053@ietfa.amsl.com> Reply-To: Paul Wouters Date: Wed, 15 Apr 2020 08:48:26 -0700 Archived-At: Subject: [secdir] Secdir telechat review of draft-ietf-taps-transport-security-11 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, 15 Apr 2020 15:48:26 -0000 Reviewer: Paul Wouters 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. The summary of the review is Has Nits Compared to my last review (-09) a lot of text has been removed, reducing the technical details and giving a briefer (but arguably cleaner) overview. I do still have a personal preference of dropping CurveCP and MinimalT as I don't really think these are anything but abandoned research items. I have never seen or heard of these being deployed. I would be more tempted to list openconnect (draft-mavrogiannopoulos-openconnect) which actually does see quite some deployment. If the intent is really to show different kind of API's, than there are other esoteric examples that could be included, such as Off-The-Record(OTR) or Signal, which are mostly encrypted chat programs, but with the ability to generate session keys for encrypted bulk transport (eg for video/audio or file transfer) Section 5.1 "Session Cache Management (CM):" which does not include IKEv2/IPsec, even though it does have session resumption (RFC 5723). I guess this is because the section limits itself to "the application" that can restart the session. But for IKEv2/IPsec the same could be said. An application that after a long idle period sends a packet, triggers a kernel ACQUIRE, which triggers an IKEv2 session resumption. WireGuard does not have this capability as there are no API/hooks for packet trigger tunnel events (AFAIK) "Pre-Shared Key Import (PSKI):" lists WireGuard, but AFAIK it does not support PSK based authentication - only public key based authentication. While I understand the IKEv2 entry (PSKs are used for authentication of peers), I am not sure the ESP entry should be here. ESP does not "authenticate peers", unless you call "being able to decrypt and authenticate packets" as an instance of "authenticating peer" Section 5.2 This states "This can call into the application to offload validation.". This "can" is only not supported by WireGuard, as all of this is happening inside the kernel. Maybe a note could be useful here? "Source Address Validation" - It is a little unclear why TCP based protocols are not listed here. They (implicitly) do source address validation. Perhaps the introduction in this paragraph can state this more explicitly. Eg "for those protocols that do not use TCP and therefor do not have builtin source address validation ......." From nobody Wed Apr 15 11:22:24 2020 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 021A93A0F12; Wed, 15 Apr 2020 11:21:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.398, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no 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 rWQAUVE8AM1K; Wed, 15 Apr 2020 11:21:42 -0700 (PDT) Received: from Mail.Yoyodyne.COM (mail.yoyodyne.com [IPv6:2604:4ec0:0:2::d]) by ietfa.amsl.com (Postfix) with SMTP id 628413A0F0F; Wed, 15 Apr 2020 11:21:42 -0700 (PDT) Received: from [IPv6:2603:3024:1767:6000:549:1025:182e:ed50] ([2603:3024:1767:6000:549:1025:182e:ed50]) by Mail.Yoyodyne.COM via Internet for (and others); Wed, 15 Apr 2020 11:21:35 PDT From: Derrell Piper Message-Id: <43AFD2E4-0486-4CEB-BBBC-8C7C72B84E09@electric-loft.org> Content-Type: multipart/signed; boundary="Apple-Mail=_53DD0931-213C-425A-AD17-CFAC8BA26ECE"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Wed, 15 Apr 2020 11:21:34 -0700 In-Reply-To: <5BABF46F-6BF2-4296-B035-099BF57E0EBE@ericsson.com> Cc: "secdir@ietf.org" , "draft-ietf-sipcore-sip-token-authnz.all@ietf.org" , "last-call@ietf.org" , "sipcore@ietf.org" To: Christer Holmberg References: <158689842488.27716.15541584374764439587@ietfa.amsl.com> <5BABF46F-6BF2-4296-B035-099BF57E0EBE@ericsson.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-sipcore-sip-token-authnz-12 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, 15 Apr 2020 18:21:44 -0000 --Apple-Mail=_53DD0931-213C-425A-AD17-CFAC8BA26ECE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Apr 15, 2020, at 12:58 AM, Christer Holmberg = wrote: >=20 > Hi Derrell, >=20 > Thank You for the review! Please see inline. >=20 >> pp. 3, 1., nit >>=20 >> "...enables the single-sign-on features, which allows the user = to..." >>=20 >> "...enables single sign-on, which allows the user to..." >=20 > We can fix as suggested. >=20 > --- >=20 >> pp. 5, last sentence >>=20 >> "previously" means "from the out-of-scope mechanism", just say = that. >=20 > I think that sounds a little "clumsy" to repeat it. Would it work if = we said "obtained in the step above", or something like that? =E2=80=9Cthe step above=E2=80=9D works too. > --- >=20 >> pp. 7, 2.1.1 >>=20 >> "(or with invalid credentials)" >>=20 >> Why continue when a UAC presents invalid credentials? [See below.] >>=20 >>=20 >> pp. 8, 2.1.3 >>=20 >> 2.1.1 says if you get invalid credentials to go REGISTER, and here = in >> REGISTER, it says if you get invalid credentials, go to 2.1.1. = This >> seems recursive though I'm assuming this ultimately terminates when = all >> the schemes are exhausted without success. >=20 > Section 2.1.1 defines generic procedures, while section 2.1.3 defines = the procedures specific for the REGISTER request. >=20 > Regards, >=20 > Christer Okay. Derrell= --Apple-Mail=_53DD0931-213C-425A-AD17-CFAC8BA26ECE Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCCqUw ggUuMIIEFqADAgECAhBuYWaYcrycMAAAAABR05MeMA0GCSqGSIb3DQEBCwUAMIG+MQswCQYDVQQG EwJVUzEWMBQGA1UEChMNRW50cnVzdCwgSW5jLjEoMCYGA1UECxMfU2VlIHd3dy5lbnRydXN0Lm5l dC9sZWdhbC10ZXJtczE5MDcGA1UECxMwKGMpIDIwMDkgRW50cnVzdCwgSW5jLiAtIGZvciBhdXRo b3JpemVkIHVzZSBvbmx5MTIwMAYDVQQDEylFbnRydXN0IFJvb3QgQ2VydGlmaWNhdGlvbiBBdXRo b3JpdHkgLSBHMjAeFw0xOTA0MTYxNTM1NTJaFw0zMDExMTYxNjA1NTJaMIG3MQswCQYDVQQGEwJV UzEWMBQGA1UEChMNRW50cnVzdCwgSW5jLjEoMCYGA1UECxMfU2VlIHd3dy5lbnRydXN0Lm5ldC9s ZWdhbC10ZXJtczE5MDcGA1UECxMwKGMpIDIwMTUgRW50cnVzdCwgSW5jLiAtIGZvciBhdXRob3Jp emVkIHVzZSBvbmx5MSswKQYDVQQDEyJFbnRydXN0IENsYXNzIDEgQ2xpZW50IENBIC0gU0hBMjU2 MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2DmtXj1lwZOXaWXvERtOSP7QMI+Ts82R Qc2etqDeYwctILXqkwsQrZB6YjKa1BQnBmLHxn3cWxKJtqCT7ZP95YVxc0MXjP5ifP9xD/f59jlY d/7SPIxQUjX1+vsV6aY4tTzPiaOu3VHVGbD70si3WdUvJh367CMOU2o0mXi9MwW1fBwMHK99NKgp wpr4QhyT2aZ+os/hGGQLUYmse5Dfshq79eelXyFC1FIrvM0AhAk+T3NKFPmckKwyk30jkFMElSne TR7ganOTMeT1OEqVomyJsMzJugVaMzuSt4vhJFSt/XXRMPcPT9PEx39X78NNkWeTTkL1Ghq9O2We AStQNwIDAQABo4IBKzCCAScwDgYDVR0PAQH/BAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMDsGA1UdIAQ0MDIwMAYEVR0gADAoMCYGCCsGAQUF BwIBFhpodHRwOi8vd3d3LmVudHJ1c3QubmV0L3JwYTAzBggrBgEFBQcBAQQnMCUwIwYIKwYBBQUH MAGGF2h0dHA6Ly9vY3NwLmVudHJ1c3QubmV0MDAGA1UdHwQpMCcwJaAjoCGGH2h0dHA6Ly9jcmwu ZW50cnVzdC5uZXQvZzJjYS5jcmwwHQYDVR0OBBYEFOJJuewl3rcM3uVQGFtIzAyOFfKmMB8GA1Ud IwQYMBaAFGpyJnrQHu995ztpUdRsjZ+QEmarMA0GCSqGSIb3DQEBCwUAA4IBAQBVuaCwN5r85cQp hcyUe+RXqaYyUmVEqTWG/a98UJdX44vkCgzdD/+Cn4o6wbRun7Ak0kdCR3qfFA17/5QOQ8DLOyR5 X37Ytxby24lTLKKehNlc3japM8XQQFaJqLMq3MXXFYhWlFk4UHwXYLcDR7XyA3hYuaL6HU92h+uG SDEcBeV+nXrk4FRgEfGvilHfd+8ozBjSVKOF6L1+fuJNkaFWYvJ4Qi64nlmXDsk6K9f6P4FT8hXA 2Cn6tQGAqCz8t6bn7ljtaxCMJ10LE+omiZDfWXv4PrkvgWnNqZEzQw+E09HwEc7DjV9/fGqUhLR2 AKkjYE/78rlymYPvOf7bmpSYMIIFbzCCBFegAwIBAgIRAI534qzDm7xdAAAAAFVjsOwwDQYJKoZI hvcNAQELBQAwgbcxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1FbnRydXN0LCBJbmMuMSgwJgYDVQQL Ex9TZWUgd3d3LmVudHJ1c3QubmV0L2xlZ2FsLXRlcm1zMTkwNwYDVQQLEzAoYykgMjAxNSBFbnRy dXN0LCBJbmMuIC0gZm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxKzApBgNVBAMTIkVudHJ1c3QgQ2xh c3MgMSBDbGllbnQgQ0EgLSBTSEEyNTYwHhcNMTkwODE1MTgyMDAyWhcNMjAwODE0MTg1MDAwWjCB nzEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQLEy5FbnRydXN0IENsYXNz IDEgSWRlbnRpdHkgQ2VydGlmaWNhdGlvbiBTZXJ2aWNlMR4wHAYDVQQDDBVkZHBAZWxlY3RyaWMt bG9mdC5vcmcxJDAiBgkqhkiG9w0BCQEWFWRkcEBlbGVjdHJpYy1sb2Z0Lm9yZzCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBANBA7jjvZSATUxJEdJNmz6N1fnajqmdDkVHOxA0yllROaJPo MNM03XQFa24aJ7fJ9wQhq9NXHq2w5xO2KK2PBJW8vxw38wuPdE14bHzuxtGKWnDhJ/SIEWtA7pB0 fFMua7OAtgTMvekxx0st8qw6yKufNtdv7Q2U3OWUYCWNdvZudJxHXkqHdCj6WTBE24sGSL/UrGLj H98ebxfANbX8Wfp/Sg34OtbFe305CyXlwNWplILN4UKg+r4EWRKgJ3ZLsxj2WH/tWdn7KU6eK315 F/PjH2NscqzNTSwZbHcwynAYd6239FQiombVk4PGnHRJq1NOi4n5M1lvl8mnrsQLYNkCAwEAAaOC AYowggGGMA4GA1UdDwEB/wQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwQgYD VR0gBDswOTA3BgtghkgBhvpsCgEEATAoMCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LmVudHJ1c3Qu bmV0L3JwYTAJBgNVHRMEAjAAMGkGCCsGAQUFBwEBBF0wWzAjBggrBgEFBQcwAYYXaHR0cDovL29j c3AuZW50cnVzdC5uZXQwNAYIKwYBBQUHMAKGKGh0dHA6Ly9haWEuZW50cnVzdC5uZXQvY2xhc3Mx LXNoYTI1Ni5jZXIwOQYDVR0fBDIwMDAuoCygKoYoaHR0cDovL2NybC5lbnRydXN0Lm5ldC9jbGFz czEtc2hhMjU2LmNybDAgBgNVHREEGTAXgRVkZHBAZWxlY3RyaWMtbG9mdC5vcmcwHwYDVR0jBBgw FoAU4km57CXetwze5VAYW0jMDI4V8qYwHQYDVR0OBBYEFA3/q3e5a+oKODwIaREHDhpaK0YRMA0G CSqGSIb3DQEBCwUAA4IBAQCPmXPwIGtfjvyqW7WFgrG/mBV1KWgorjrzgDYZmZfI466I6zEurSnI 0pLAbkXrhuTfEYkm4lertjRBSkd9W3iRaBUUfOntAdANX8/3onjQI/WEvszc6tPUTfS/CixsR69M mE0/o5UmYzSBcHzF2ff01ceD8IrsPhyzf87xJvfWonFyGB3gt8kN9K5S1eCAj6WdgC1ZrFMXp8fR ezAA2BHiJCbj4T2e3Zg4xDoTH4r4Y9u+czDikS5InJL+Z0iqsNR50d7YgAEAeU3iYQx5GvO7Dqou vM9JajPccnpqDClNXP1sqIOvAE6GHSopTy6mEUB6phLVeWW342rsUvtgUntVMYIEKjCCBCYCAQEw gc0wgbcxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1FbnRydXN0LCBJbmMuMSgwJgYDVQQLEx9TZWUg d3d3LmVudHJ1c3QubmV0L2xlZ2FsLXRlcm1zMTkwNwYDVQQLEzAoYykgMjAxNSBFbnRydXN0LCBJ bmMuIC0gZm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxKzApBgNVBAMTIkVudHJ1c3QgQ2xhc3MgMSBD bGllbnQgQ0EgLSBTSEEyNTYCEQCOd+Ksw5u8XQAAAABVY7DsMA0GCWCGSAFlAwQCAQUAoIICLTAY BgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDA0MTUxODIxMzRaMC8G CSqGSIb3DQEJBDEiBCCa9evgrGS04kjztTooMYm+NCR34MRSOYwE3FStmixU/TCB3gYJKwYBBAGC NxAEMYHQMIHNMIG3MQswCQYDVQQGEwJVUzEWMBQGA1UEChMNRW50cnVzdCwgSW5jLjEoMCYGA1UE CxMfU2VlIHd3dy5lbnRydXN0Lm5ldC9sZWdhbC10ZXJtczE5MDcGA1UECxMwKGMpIDIwMTUgRW50 cnVzdCwgSW5jLiAtIGZvciBhdXRob3JpemVkIHVzZSBvbmx5MSswKQYDVQQDEyJFbnRydXN0IENs YXNzIDEgQ2xpZW50IENBIC0gU0hBMjU2AhEAjnfirMObvF0AAAAAVWOw7DCB4AYLKoZIhvcNAQkQ AgsxgdCggc0wgbcxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1FbnRydXN0LCBJbmMuMSgwJgYDVQQL Ex9TZWUgd3d3LmVudHJ1c3QubmV0L2xlZ2FsLXRlcm1zMTkwNwYDVQQLEzAoYykgMjAxNSBFbnRy dXN0LCBJbmMuIC0gZm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxKzApBgNVBAMTIkVudHJ1c3QgQ2xh c3MgMSBDbGllbnQgQ0EgLSBTSEEyNTYCEQCOd+Ksw5u8XQAAAABVY7DsMA0GCSqGSIb3DQEBAQUA BIIBABDifBb166R3RTl3EYj+vTPur0yWdBJZ9okp5CRslesTTdQA+tglPTMoNbOCRznW3xWztpFn Va+jcf3lQd33bUPrqS88u1Kx+80/L55sd23k8YB2/WXf52cz99uX6etOxVlhQWbeSTnYbyIKHLPp ZYwaBHE8SGq3V4UUcX5VZ5A6J4ZGuIiQ4UhgHtWf3banODt0mv8+hMcBt0D3Y5HDuydL+dcvAPX9 8gUIyglzNpflcM6rvUevyQ0/GTvuflkq071C9AfbwtS3o9QOdtjv6fjWzdDFVHL8UjZXoCBvyxqc qEEILtJNKZjlVFasl9Xrl4/j10tfJ7XOHoZI/lE7jNEAAAAAAAA= --Apple-Mail=_53DD0931-213C-425A-AD17-CFAC8BA26ECE-- From nobody Thu Apr 16 10:26:24 2020 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 A9E4D3A07F6 for ; Thu, 16 Apr 2020 10:26:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 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, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 lNHE8RqtPnzV for ; Thu, 16 Apr 2020 10:26:20 -0700 (PDT) Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) (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 14F6A3A07EC for ; Thu, 16 Apr 2020 10:26:20 -0700 (PDT) Received: by mail-wr1-x431.google.com with SMTP id x18so5842723wrq.2 for ; Thu, 16 Apr 2020 10:26:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/USPAG+riYl8/Qjinr5IkUA60oWmJmkcFHD8osZeWA0=; b=ajmSmxxqrzcl+D8o+uIk9n83E4s90TvYcnihvyMEMBXZDe9dlFWQMuQvfbwVR4RvzT zB31ipMTxU4GBuqghPbdbDxMAuAK12KJxQZr5q9cYr2xmm7TiJV5ztja2i0miqzi7kuV cRKr5465vF99trNLdURZZ3wwWOohw/2Osnc3XU5fjJ0TCy6F6l9U92kcwCrlLLn3BE/F JAFLaXENBNCQExD2jGXIg0KVRpbx3GMEW88oyi2ZbH1e84tBQYY8Q8KUojSmxhq+I08F JDJ8s3BrcIIX/xuIGHxdDXNjOFbRO9i4yzpLRkXz8Q+of+drLV0GwE9kZY41eCu/Q2VD thqA== 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=/USPAG+riYl8/Qjinr5IkUA60oWmJmkcFHD8osZeWA0=; b=eguNqc1Ey11dl72lz4mjXSDUC7O9iK9uuaNrdeG2JVK+fvNeIuaYsYrtAdHwnwSEdW sGWR9+TC1TkbiVLfXVuET6cgeexF697K9Y0h7y2XLyn0iIf6Jta541nwQS2TG2ADtNCq BBIDiXze2QZF/RwQiF9OUATKPNff0dkgd4+6KHqnQDcCQDcNaGWW9z1+WD0U/rRoL6ew WVH/Eo/XNyzwiDMGtgweyNJdwkSWWvvXnfIuzv36UL7knM96ft+P6XlbZsmWPfpmijVc SEbmW7+4YB9hJqAdPUcfK+Z1GNI31c2kOWnfm/v54nF7n403QsdWrfDJJ0q508qA6KGT vM9w== X-Gm-Message-State: AGi0PuZXfz+JF0NtiY0dcj9no/JtiFX7b26bOU48xzzBCcw2eDSYhNET IXOZV3816suSFWaF+LkO2kybqrR6HeGBy5A0bj4maw== X-Google-Smtp-Source: APiQypLjQz9A8l8gvwmDlKXeuQ6EBiblXl5sAgN8ilmEYJpv/Z9PhmDlUCRrEwYV7cfrJDxZcvgp9Yg9F0+cGxO+DDQ= X-Received: by 2002:a05:6000:162c:: with SMTP id v12mr37887143wrb.313.1587057978280; Thu, 16 Apr 2020 10:26:18 -0700 (PDT) MIME-Version: 1.0 References: <158566679527.28397.11447221654478370153@ietfa.amsl.com> In-Reply-To: From: Eric Orth Date: Thu, 16 Apr 2020 13:26:07 -0400 Message-ID: To: Wes Hardaker Cc: Catherine Meadows , last-call@ietf.org, dnsop , draft-ietf-dnsop-extended-error.all@ietf.org, secdir@ietf.org Content-Type: multipart/alternative; boundary="00000000000008fe0505a36bbbae" Archived-At: Subject: Re: [secdir] [DNSOP] Secdir last call review of draft-ietf-dnsop-extended-error-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: Thu, 16 Apr 2020 17:26:23 -0000 --00000000000008fe0505a36bbbae Content-Type: text/plain; charset="UTF-8" On Tue, Apr 14, 2020 at 6:35 PM Wes Hardaker wrote: > Catherine Meadows via Datatracker writes: > > > Reviewer: Catherine Meadows > > Review result: Has Issues > > Hi Catherine, > > Thanks for the review of the dnsop-extended-error draft. [and sorry > for the delay in sending this] > > > The Security Considerations section mentions some valid points, but it > > is not made clear how they apply to extended DNS error messages (as > > opposed to DNS error messages in general). It first makes the > > non-obvious point that a significant number of clients, when receiving > > a failure message about a DNS validation issue from a validated > > resolver, will seek out an unvalidated server instead. It is not > > clear to me though whether you think that extending the types of DNS > > error messages available (thus giving more information to the client) > > would help address this problem. You should say something about this. > > Secondly, it discusses the security implications of the fact that DNS > > error messages are unauthenticated. > > > > In addition, in the paragraph about the security implications of DNS > error > > messages being unauthenticated, you should say whether or not extending > the > > types of DNS error messages would improve the situation, make it > worse, have > > no effect, or is unclear. > > You're right that we don't specify what to do in the security > considerations section, though we do earlier in the document. > Specifically it says (at least): > > Applications MUST continue to follow requirements from applicable > specifications on how to process RCODEs no matter what EDE values > are also received. > > So maybe adding the following sentence to the security section addresses > your issue? > > EDE content should be treated only as diagnostic information for > network operators and MUST NOT alter DNS protocol processing. > I have similar objections to this as the similar language that was in the draft before it was changed to the "MUST continue to follow" language referenced above. Anything similar to "MUST NOT alter ... processing" is vague over what constitutes an alteration to the processing. I think everybody would agree that you should be able to log EDEs, so it must be unambiguous that doing so is allowed. Lots of discretionary room for implementers (especially stub implementers) to do various things with an EDE while still following the specs on the important handling of the RCODE as the primary error code. > > We could add a note as well about the scope of the document, though I > think it can be derived from the above sentence: > > EDE content is not attempting to address the lack security in DNS > error messages. > > -- > Wes Hardaker > USC/ISI > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > --00000000000008fe0505a36bbbae Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


    =
    On Tue, Apr 14, 2020 at 6:35 PM Wes H= ardaker <wjhns1@hardakers.net> wrote:
    Cat= herine Meadows via Datatracker <noreply@ietf.org> writes:

    > Reviewer: Catherine Meadows
    > Review result: Has Issues

    Hi Catherine,

    Thanks for the review of the dnsop-extended-error draft.=C2=A0 [and sorry for the delay in sending this]

    > The Security Considerations section mentions some valid points, but it=
    > is not made clear how they apply to extended DNS error messages (as > opposed to DNS error messages in general). It first makes the
    > non-obvious point that a significant number of clients, when receiving=
    > a failure message about a DNS validation issue from a validated
    > resolver, will seek out an unvalidated server instead.=C2=A0 It is not=
    > clear to me though whether you think that extending the types of DNS > error messages available (thus giving more information to the client)<= br> > would help address this problem.=C2=A0 You should say something about = this.
    > Secondly, it discusses the security implications of the fact that DNS<= br> > error messages are unauthenticated.
    >
    > In addition, in the paragraph about the security implications of DNS e= rror
    > messages being unauthenticated, you should say whether or not extendin= g the
    > types of DNS error messages would improve the situation,=C2=A0 =C2=A0m= ake it worse, have
    > no effect,=C2=A0 or is unclear.

    You're right that we don't specify what to do in the security
    considerations section, though we do earlier in the document.
    Specifically it says (at least):

    =C2=A0 =C2=A0 =C2=A0 Applications MUST continue to follow requirements from= applicable
    =C2=A0 =C2=A0 =C2=A0 specifications on how to process RCODEs no matter what= EDE values
    =C2=A0 =C2=A0 =C2=A0 are also received.

    So maybe adding the following sentence to the security section addresses your issue?

    =C2=A0 =C2=A0 =C2=A0 EDE content should be treated only as diagnostic infor= mation for
    =C2=A0 =C2=A0 =C2=A0 network operators and MUST NOT alter DNS protocol proc= essing.

    I have similar objections to th= is as the similar language that was in the draft before it was changed to t= he "MUST continue to follow" language referenced above.

    Anything similar to "MUST NOT alter ... processing&quo= t; is vague over what constitutes an alteration to the processing.=C2=A0 I = think everybody would agree that you should be able to log EDEs, so it must= be unambiguous that doing so is allowed.=C2=A0 Lots of discretionary room = for implementers (especially stub implementers) to do various things with a= n EDE while still following the specs on the important handling of the RCOD= E as the primary error code.
    =C2=A0

    We could add a note as well about the scope of the document, though I
    think it can be derived from the above sentence:

    =C2=A0 =C2=A0 =C2=A0 EDE content is not attempting to address the lack secu= rity in DNS
    =C2=A0 =C2=A0 =C2=A0 error messages.

    --
    Wes Hardaker
    USC/ISI

    _______________________________________________
    DNSOP mailing list
    DNSOP@ietf.org
    https://www.ietf.org/mailman/listinfo/dnsop
    --00000000000008fe0505a36bbbae-- From nobody Fri Apr 17 00:45:27 2020 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 005F43A0FB8; Fri, 17 Apr 2020 00:45:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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=tix.at 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 Fz11rBjUN89L; Fri, 17 Apr 2020 00:45:17 -0700 (PDT) Received: from mail.fbsd.host (mail.fbsd.host [IPv6:2001:858:58::22]) (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 018EB3A103B; Fri, 17 Apr 2020 00:44:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tix.at; s=rev1; h=References:To:Cc:In-Reply-To:Date:Subject:Mime-Version:Content-Type :Message-Id:From:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=3AksEctf0aAkRec7xX1ZqOXb0an0sQxFB0KOHRewg5s=; b=hX8HweVbSPvS0tiEZdfqmIw72c pzMeyc3/mT+XOyHz1SkC0lsyKs3znRN8IRKJcxNkX5HZ9aTjhGAa2RHbkZ5bMy6tjF6Lbi1gsuI3+ dZujCAG3Sar1iTwHZCYBlCIviRs5hTQxyAbZQ4i3fJBC/hs3DHTUKo5+PYH0ZnaQkn7h72CW8Qetv oP51BHLEwev0Ipuz9AE4qE0L4sFYipNIaSGHnwL0Y4XuBTlfbqXG5JtZmx4pIkqlqnVmWvkSMkAHD /ncaFDnsjTo98oMOOZH1MtO1vRUsmjEPBQGUu93p89FuBCfxgk6WeZXhGe0/xmboxK2a79MXGiqe6 wJ5PfR4w==; Received: from 213-225-13-127.nat.highway.a1.net ([213.225.13.127] helo=[192.168.88.217]) by mail.fbsd.host with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from ) id 1jPLfj-0001T1-Kz; Fri, 17 Apr 2020 09:44:23 +0200 From: Christoph Loibl Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_73FCF4E2-E692-4080-9245-08C26E53BE6E" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) Date: Fri, 17 Apr 2020 09:44:21 +0200 In-Reply-To: <158643250722.20996.2687173728603121972@ietfa.amsl.com> Cc: secdir@ietf.org, last-call@ietf.org, idr@ietf.org, draft-ietf-idr-rfc5575bis.all@ietf.org To: Yoav Nir References: <158643250722.20996.2687173728603121972@ietfa.amsl.com> X-Mailer: Apple Mail (2.3608.60.0.2.5) X-Scanned-By: primary on mail.fbsd.host (78.142.178.22); Fri, 17 Apr 2020 09:44:23 +0200 Archived-At: Subject: Re: [secdir] [BULK] Secdir last call review of draft-ietf-idr-rfc5575bis-20 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, 17 Apr 2020 07:45:21 -0000 --Apple-Mail=_73FCF4E2-E692-4080-9245-08C26E53BE6E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Yoav, Thank you for your review. Cheers Christoph --=20 Christoph Loibl c@tix.at | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 | http://www.nextlayer.at > On 09.04.2020, at 13:41, Yoav Nir via Datatracker = wrote: >=20 > Reviewer: Yoav Nir > Review result: Ready >=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.=20= > Document editors and WG chairs should treat these comments just like = any other > last call comments. >=20 > This one is ready, and the Security Considerations section is = remarkably > well-written. >=20 >=20 --Apple-Mail=_73FCF4E2-E692-4080-9245-08C26E53BE6E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Yoav,

    Thank you for = your review.

    Cheers
    Christoph
    -- 
    Christoph = Loibl
    c@tix.at | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 = | http://www.nextlayer.at



    On 09.04.2020, at 13:41, Yoav Nir via Datatracker <noreply@ietf.org> = wrote:

    Reviewer: Yoav Nir
    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 one is ready, and the Security Considerations section is = remarkably
    well-written.



    = --Apple-Mail=_73FCF4E2-E692-4080-9245-08C26E53BE6E-- From nobody Fri Apr 17 03:46:25 2020 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 221113A088C for ; Fri, 17 Apr 2020 03:46:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Tero Kivinen via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 6.127.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu, Tero Kivinen Message-ID: <158712038372.2321.15579316807047420869@ietfa.amsl.com> Date: Fri, 17 Apr 2020 03:46:24 -0700 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: Fri, 17 Apr 2020 10:46:24 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2020-04-24 Reviewer LC end Draft Donald Eastlake R2019-11-14 draft-ietf-hip-dex-18 David Mandelberg R2020-04-02 draft-ietf-core-stateless-06 Vincent Roca 2020-01-30 draft-ietf-pim-msdp-yang-18 Last calls: Reviewer LC end Draft John Bradley 2020-02-28 draft-ietf-regext-data-escrow-07 Alan DeKok 2019-06-04 draft-ietf-netvc-testing-09 Donald Eastlake 2020-02-27 draft-ietf-6tisch-msf-16 Donald Eastlake R2019-11-14 draft-ietf-hip-dex-18 Daniel Franke 2020-03-09 draft-ietf-regext-dnrd-objects-mapping-06 Aanchal Malhotra 2020-03-12 draft-ietf-bess-vpls-multihoming-05 David Mandelberg R2020-04-02 draft-ietf-core-stateless-06 Russ Mundy 2020-01-02 draft-ietf-dprive-bcp-op-08 Magnus Nystrom 2019-04-10 draft-ietf-avtcore-multiplex-guidelines-11 Hilarie Orman 2020-04-29 draft-hodges-webauthn-registries-05 Francesca Palombini 2020-04-28 draft-ietf-rtcweb-sdp-11 Tirumaleswar Reddy.K 2020-04-09 draft-ietf-sfc-oam-framework-13 Vincent Roca 2020-04-23 draft-ietf-detnet-ip-over-mpls-05 Vincent Roca 2020-01-30 draft-ietf-pim-msdp-yang-18 Kyle Rose 2020-04-30 draft-ietf-idr-capabilities-registry-change-07 Sean Turner None draft-ietf-opsawg-sdi-02 Dacheng Zhang 2020-03-12 draft-nottingham-how-did-that-get-into-the-repo-01 Dacheng Zhang 2019-11-05 draft-ietf-mpls-ri-rsvp-frr-07 Next in the reviewer rotation: Joseph Salowey Rich Salz Stefan Santesson Yaron Sheffer Rifaat Shekh-Yusef Melinda Shore Valery Smyslov Robert Sparks Takeshi Takahashi Tina Tsou From nobody Fri Apr 17 14:56:35 2020 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 8DFF33A08EF; Fri, 17 Apr 2020 14:56:12 -0700 (PDT) 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, SPF_HELO_NONE=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 doWRs61GUp8K; Fri, 17 Apr 2020 14:56:10 -0700 (PDT) Received: from mail.hardakers.net (mail.hardakers.net [168.150.192.181]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2186F3A08EE; Fri, 17 Apr 2020 14:56:09 -0700 (PDT) Received: from localhost (unknown [10.0.0.3]) by mail.hardakers.net (Postfix) with ESMTPA id 5C7E23112E; Fri, 17 Apr 2020 14:56:09 -0700 (PDT) From: Wes Hardaker To: Eric Orth Cc: Wes Hardaker , Catherine Meadows , last-call@ietf.org, dnsop , draft-ietf-dnsop-extended-error.all@ietf.org, secdir@ietf.org References: <158566679527.28397.11447221654478370153@ietfa.amsl.com> Date: Fri, 17 Apr 2020 14:56:09 -0700 In-Reply-To: (Eric Orth's message of "Thu, 16 Apr 2020 13:26:07 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [secdir] [DNSOP] Secdir last call review of draft-ietf-dnsop-extended-error-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: Fri, 17 Apr 2020 21:56:13 -0000 Eric Orth writes: > I have similar objections to this as the similar language that was in the= draft > before it was changed to the "MUST continue to follow" language referenced > above. >=20 > Anything similar to "MUST NOT alter ... processing" is vague over what > constitutes an alteration to the processing.=C2=A0 I think everybody woul= d agree > that you should be able to log EDEs, so it must be unambiguous that doing= so is > allowed.=C2=A0 Lots of discretionary room for implementers (especially st= ub > implementers) to do various things with an EDE while still following the = specs > on the important handling of the RCODE as the primary error code. > =C2=A0 >=20 Hi Eric, Thanks for the (again) well thought out comments. Do you have a counter proposal sentence? >=20=20=20=20 > -- > Wes Hardaker > USC/ISI >=20=20=20=20 > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop >=20 --=20 Wes Hardaker USC/ISI From nobody Fri Apr 17 14:56:43 2020 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 6262E3A0942; Fri, 17 Apr 2020 14:56:25 -0700 (PDT) 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, SPF_HELO_NONE=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 4doMyQ-NwrRR; Fri, 17 Apr 2020 14:56:23 -0700 (PDT) Received: from mail.hardakers.net (mail.hardakers.net [168.150.192.181]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C5EF3A093A; Fri, 17 Apr 2020 14:56:23 -0700 (PDT) Received: from localhost (unknown [10.0.0.3]) by mail.hardakers.net (Postfix) with ESMTPA id 1E78C3112E; Fri, 17 Apr 2020 14:56:23 -0700 (PDT) From: Wes Hardaker To: Eric Orth Cc: Wes Hardaker , Catherine Meadows , last-call@ietf.org, dnsop , draft-ietf-dnsop-extended-error.all@ietf.org, secdir@ietf.org References: <158566679527.28397.11447221654478370153@ietfa.amsl.com> Date: Fri, 17 Apr 2020 14:56:22 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [secdir] [DNSOP] Secdir last call review of draft-ietf-dnsop-extended-error-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: Fri, 17 Apr 2020 21:56:32 -0000 Eric Orth writes: > I have similar objections to this as the similar language that was in the= draft > before it was changed to the "MUST continue to follow" language referenced > above. >=20 > Anything similar to "MUST NOT alter ... processing" is vague over what > constitutes an alteration to the processing.=C2=A0 I think everybody woul= d agree > that you should be able to log EDEs, so it must be unambiguous that doing= so is > allowed.=C2=A0 Lots of discretionary room for implementers (especially st= ub > implementers) to do various things with an EDE while still following the = specs > on the important handling of the RCODE as the primary error code. > =C2=A0 >=20 Hi Eric, Thanks for the (again) well thought out comments. Do you have a counter proposal sentence that could be added to the security seciton? --=20 Wes Hardaker USC/ISI From nobody Sat Apr 18 11:37:27 2020 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 7BCAE3A0FD3 for ; Sat, 18 Apr 2020 11:37:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.091 X-Spam-Level: X-Spam-Status: No, score=-2.091 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_SPF_HELO_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mandelberg.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 ZxQDQ6mWfHuJ for ; Sat, 18 Apr 2020 11:37:14 -0700 (PDT) Received: from smtp.rcn.com (smtp.rcn.com [69.168.97.78]) (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 428123A0FD7 for ; Sat, 18 Apr 2020 11:37:04 -0700 (PDT) X_CMAE_Category: , , X-CNFS-Analysis: v=2.3 cv=T+HysMCQ c=1 sm=1 tr=0 a=OXtaa+9CFT7WVSERtyqzJw==:117 a=OXtaa+9CFT7WVSERtyqzJw==:17 a=KGjhK52YXX0A:10 a=IkcTkHD0fZMA:10 a=NTnny0joGdQA:10 a=cl8xLZFz6L8A:10 a=bmmO2AaSJ7QA:10 a=iiazv-oawmH03g7Men8A:9 a=QEXdDO2ut3YA:10 X-CM-Score: 0 X-Scanned-by: Cloudmark Authority Engine X-Authed-Username: ZHNlb21uQHJjbi5jb20= Authentication-Results: smtp02.rcn.cmh.synacor.com header.DKIM-Signature=@mandelberg.org; dkim=pass Authentication-Results: smtp02.rcn.cmh.synacor.com header.from=david@mandelberg.org; sender-id=softfail Authentication-Results: smtp02.rcn.cmh.synacor.com smtp.mail=david@mandelberg.org; spf=softfail; sender-id=softfail Authentication-Results: smtp02.rcn.cmh.synacor.com smtp.user=dseomn@rcn.com; auth=pass (LOGIN) Received: from [209.6.43.168] ([209.6.43.168:44902] helo=uriel.mandelberg.org) by smtp.rcn.com (envelope-from ) (ecelerity 3.6.25.56547 r(Core:3.6.25.0)) with ESMTPSA (cipher=DHE-RSA-AES256-GCM-SHA384) id 54/09-63700-3C84B9E5; Sat, 18 Apr 2020 14:36:52 -0400 Received: from [192.168.1.152] (DD-WRT [192.168.1.1]) by uriel.mandelberg.org (Postfix) with ESMTPSA id BBC5F1C604E; Sat, 18 Apr 2020 14:36:48 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mandelberg.org; s=202003; t=1587235008; bh=wBRarqSHNaZozVDb/P2H6QlD/lz7dQZcToN7qXc3OpA=; h=To:From:Subject:Date:From; b=M+B5pn3PAL0RShOgZLDL21euzRqcjHgc3Lq15zCzzKdM+js5VxEeIidI9HshvkIHk A99/3oz4Vj6AZWRSFBLRZCD1Bksc5uQFTfEQj9LAj3BzupqB6iEwNPBKzOwwRs+SvV s/4/L2BgR63Ic998cxSfbxL1ofOpycSip4HLwEep8WkbEyzXjl1gXnab6GzJDyKonW HZuoakwdlgfSD1N6ODsVl6vcw7kT8QugmC+ON7uLJyK+AQVrmGaMUNcGSje1eSh3c6 iD1rlzeAD4KBk4D9y4x4qRRlDAieUBhDWyzqy0sLk4wPKpYSNh8W9r+017SiyVkwRg EgoHz7h5zB5qA== To: iesg@ietf.org, secdir@ietf.org, draft-ietf-core-stateless.all@ietf.org From: David Mandelberg Message-ID: <84a53001-198c-620e-fdac-671619a0a244@mandelberg.org> Date: Sat, 18 Apr 2020 14:36:46 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [secdir] secdir review of draft-ietf-core-stateless-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: Sat, 18 Apr 2020 18:37:26 -0000 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 nits. (nit) In section 3.1, I think "by changing the key used for integration protection" should say "integrity" instead of "integration" From nobody Sun Apr 19 08:48:48 2020 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 64FFD3A0C39; Sun, 19 Apr 2020 08:48:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.201 X-Spam-Level: X-Spam-Status: No, score=-0.201 tagged_above=-999 required=5 tests=[DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=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 B4EPJcZYDeDh; Sun, 19 Apr 2020 08:48:38 -0700 (PDT) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2069.outbound.protection.outlook.com [40.107.20.69]) (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 AED1A3A0C35; Sun, 19 Apr 2020 08:48:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=S41WZCzW4DavBOW4/6sJ8iouHbV1dfomuh2gmLKiwtPFfH4omWYXfUVSmm57ljN57WqWeFRELKdO+FSejJ6EY1H9+rKhFabK+x3ACif+muP5TwFNoZYKWptZ6uWhHv8iXEDR6K4Cr72V9ebTkfNKiogRznJK5G+mCf9Yl/IptB1fcd0vJfRbwbaAl06JgrGnb5Neta3dVBVJicwX3SKfUklLly/Wczb5G7Ib3DbEOG5FFKv6Dqho0IJiumXgNZy7EHCfpjWr4ahVEKMbLSyaMTLkSEgm2Er9S3UXuE9UisQkN5C2qJItJAi1O42yl0DZAt4kg6DOuOXLh+qeW7e47A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=eUa8wtss0grhHQ7oPolR+wAmyQ/6REN/uQvmCr0hKf0=; b=h1REPsNtqLBoG18vQC2ojhidHQiGtKqTy1nvkQXoIeoyL6o1ZKUZFVzZ63SEUbSaKOp4B2H4HlTjKPv8/Or+9mGXY4bCc6u7aBLajVEUbAWqEvibLTa++8CzzMfYNmy0i4EjA3v4v2mjYCWtrDOfUIodWYs1xovQsPCtqFh8E6m5+QhaZngq547/B5UrPIbnnVFRr1ztWmvkuiHO0YgxiqYuUNmPwVCDIVGCVUvvyal8z9Kbzj0w4ISVBdHGfO9PJ9N/FVBp4IvgQHmb25EvQnpVp5F+k+9QT6WXNxECIjWYxt9kNewCU2E5qvSSHe5cR1mksIvHrqhlbcKacnPUFQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none 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=eUa8wtss0grhHQ7oPolR+wAmyQ/6REN/uQvmCr0hKf0=; b=m5oVseDw10hT0jtrwM41B9hwZYhZUOZuI8agdlNoGnkAZJCFuaDBSkn+z59MtDRVrMwSX7uCFBQPFFpgdNDx/QJIAiHPDAjQ4CjyoariTCpVc0Opw4P0QCw7MYKTzMUiLo+L6jsLgDbIIMMpIvwevvwxz1xauLQUdA/Ym0PR+uQ= Received: from HE1PR07MB4346.eurprd07.prod.outlook.com (2603:10a6:7:97::10) by HE1PR07MB3449.eurprd07.prod.outlook.com (2603:10a6:7:38::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.5; Sun, 19 Apr 2020 15:48:33 +0000 Received: from HE1PR07MB4346.eurprd07.prod.outlook.com ([fe80::dd30:592:4d33:3f46]) by HE1PR07MB4346.eurprd07.prod.outlook.com ([fe80::dd30:592:4d33:3f46%5]) with mapi id 15.20.2937.007; Sun, 19 Apr 2020 15:48:33 +0000 From: Klaus Hartke To: David Mandelberg , "iesg@ietf.org" , "secdir@ietf.org" , "draft-ietf-core-stateless.all@ietf.org" Thread-Topic: secdir review of draft-ietf-core-stateless-06 Thread-Index: AQHWFbBla9F+H/79XUCHX94jDiqhPKiAmE3w Date: Sun, 19 Apr 2020 15:48:33 +0000 Message-ID: References: <84a53001-198c-620e-fdac-671619a0a244@mandelberg.org> In-Reply-To: <84a53001-198c-620e-fdac-671619a0a244@mandelberg.org> 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=klaus.hartke@ericsson.com; x-originating-ip: [145.14.112.90] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 1dc96557-964f-4f9d-6576-08d7e4791d70 x-ms-traffictypediagnostic: HE1PR07MB3449: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6430; x-forefront-prvs: 0378F1E47A x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR07MB4346.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(346002)(39860400002)(136003)(376002)(366004)(396003)(55016002)(316002)(110136005)(7696005)(6506007)(26005)(2906002)(33656002)(66476007)(66556008)(64756008)(66446008)(9686003)(71200400001)(76116006)(186003)(66946007)(86362001)(8936002)(5660300002)(558084003)(81156014)(52536014)(8676002)(478600001)(44832011); DIR:OUT; SFP:1101; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Z1BoP5MyDIcU9tTpXXTbtN14VC2oeudBWBxlOojzzA7Ol1jnmp0WOHw0gx0jhI37hITwXuH8mQtbYMaUz7+jkyotX+GWU9FcSghX8OQtkpgDToppR9lU9YTRQgXWZFz7txP6rtFeBiu4GOaYIgwkrhrw1CAhTzevVecttYgj4qQHDP7GrCxjcx3QIx4i0/D0iVoT4cIR5oVU0ab0A/nXCu562e/9kaaBdeVM8aujHluHaLdqK9vs84qJqXGTkeOX+BzKRNRE/Fdggkp7Rcwvx57iTL+EGI/HkCAYLwOZf4EzK6XQnTPlRKlTdpV/Qx5vE9vq/ujBxmLSWllc35j8gsQJ8mtsKgqlLmKnuxy8UCdUjkYiPIqaiitPUL+YPJiin2kOgkh/g9bLXU/W8haKWafvQLoMGiJnL075+nlIU9DiLzGMV2PGOFgmqbm3h3ML x-ms-exchange-antispam-messagedata: uvT3F+1yFTfgq7jlIuLzflcbxyHpnjPfyaVy+1UAfYUR7gvYrJXBBrYFHftR0RazdQcSvKTmTjLu/rzaDFOAyVBVvY8l3s/oa/CRgCx9/hZQs+v69fgt/chtohMmorO0lO1RyHHi8DX3mo59NHBv9qInqjr9d5h9rUu35ho4KyFIh1+I656pMYWuCD3bRPUd8gVjH/NxI6hGtn5olNW6GaosZGGTAItDBLhHjBCdZL48kKlLUIp99jafsxADZPq3JIoZTZKHiDfuGbDvAL1C5KDAu63fmU6WocfqAASjViZ48cMM6NjO1vH+cmm0wjNUiLkwT/Sfgc3MMYEbkAzxjhxLTQgV3mdSh8zNIk5RFPY1nOfNhbKxwqWd0g4M4WATsWpam6C0dJ3rIiOQToCrIV/57bHTsk8iORuO1/fS0QGrCy80EeRH0YnNF6FleOfp1E7OMimWcnqRhA73a0VBQUcaZFwiuU5pZ/lH4Ep2xYHHq/tKT8DZE98uis+8c/9fzlQTqWiWBG4zTNeQHfmkB/4sWlNvodrGs+ksHDLVWEYCcvLxhseYa4Ijx64X8EpoOtkK6OubtPYBise5KS+v2JUFctLwwNkBH597wFildC1uYCqL7DxNl7Nml1nxDY8zMyL1XDtfOSnOTCM/1KN8IadPuFmVEvq8IKVG5gYWS5xiv+NpWxTdfzgkzh5Pf1J+68tX37XQW/UMiFpXd+HUpVyjgwpT56r981yOGuqU/ahNKWUL+GfVKr3dY5DgDqrV59BHi4Ofwjb//IBwgZGONqY1ux6QeurHM//xttdJEzQ= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1dc96557-964f-4f9d-6576-08d7e4791d70 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Apr 2020 15:48:33.1016 (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-CrossTenant-userprincipalname: +6Lw04lv5MmdqRrFtfsjZC8chQdLmvGis12mSlXL5P62wcbK+peqEmv/yTNircuqod2EIhThBAqgID87M1CSrOdEMiN+4Jwb+Bg7ktuq3yg= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3449 Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-core-stateless-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: Sun, 19 Apr 2020 15:48:40 -0000 RGF2aWQgTWFuZGVsYmVyZyB3cm90ZToNCj4gKG5pdCkgSW4gc2VjdGlvbiAzLjEsIEkgdGhpbmsg ImJ5IGNoYW5naW5nIHRoZSBrZXkgdXNlZCBmb3IgaW50ZWdyYXRpb24NCj4gcHJvdGVjdGlvbiIg c2hvdWxkIHNheSAiaW50ZWdyaXR5IiBpbnN0ZWFkIG9mICJpbnRlZ3JhdGlvbiINCg0KRml4ZWQg aW4gdGhlIG5leHQgcmV2aXNpb24uIFRoYW5rcyENCg0KS2xhdXMNCg0K From nobody Mon Apr 20 00:30:58 2020 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 5D9C03A131C for ; Mon, 20 Apr 2020 00:30:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.188 X-Spam-Level: X-Spam-Status: No, score=-0.188 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.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 MmrX6NSlJnXM for ; Mon, 20 Apr 2020 00:30:42 -0700 (PDT) Received: from us-smtp-delivery-140.mimecast.com (us-smtp-delivery-140.mimecast.com [216.205.24.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41FDB3A1332 for ; Mon, 20 Apr 2020 00:30:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=mimecast20190606; t=1587367801; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=fT3cJ/YcErs5bYNFAjaXUhexPXRHSzUsiFMItzUHZwU=; b=ILZ3q5NxDOeyPBGOSQ33Y6mykh4YFk/NlVRxWPsL7nvO5Eca01zJSKxT60OwGk2t5DprAi VY5bRYHFt6jkqlKUz9XqLJnBblE7pm65VE0oHBn+OKR6IhUf7aqOcjymiMjJkomgksU6XI +a8Hf6XoL5idsI8nDFGmyUy0oYHHP54= Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02lp2052.outbound.protection.outlook.com [104.47.36.52]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-472-lSdcVMwWNUCO_QqxtPud5g-1; Mon, 20 Apr 2020 03:28:11 -0400 X-MC-Unique: lSdcVMwWNUCO_QqxtPud5g-1 Received: from CY4PR1601MB1254.namprd16.prod.outlook.com (2603:10b6:903:d4::12) by CY4PR1601MB1112.namprd16.prod.outlook.com (2603:10b6:903:d2::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2921.25; Mon, 20 Apr 2020 07:28:07 +0000 Received: from CY4PR1601MB1254.namprd16.prod.outlook.com ([fe80::8172:432c:9870:d8fc]) by CY4PR1601MB1254.namprd16.prod.outlook.com ([fe80::8172:432c:9870:d8fc%5]) with mapi id 15.20.2921.027; Mon, 20 Apr 2020 07:28:07 +0000 From: "Konda, Tirumaleswar Reddy" To: "secdir@ietf.org" , "sfc@ietf.org" , "draft-ietf-sfc-ioam-nsh.all@ietf.org" Thread-Topic: Secdir last call review of draft-ietf-sfc-oam-framework Thread-Index: AdYW4VRPPDX1YR3aSqa2kbIsbH1Dgg== Date: Mon, 20 Apr 2020 07:28:07 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.5.0.44 dlp-reaction: no-action x-originating-ip: [185.221.69.46] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 3bafca21-96ce-430a-2cc8-08d7e4fc5f63 x-ms-traffictypediagnostic: CY4PR1601MB1112: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 03793408BA x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CY4PR1601MB1254.namprd16.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(136003)(376002)(396003)(366004)(346002)(39860400002)(32952001)(52536014)(66946007)(66556008)(66476007)(66446008)(64756008)(86362001)(81156014)(9686003)(450100002)(76116006)(33656002)(71200400001)(55016002)(8676002)(8936002)(6506007)(5660300002)(316002)(110136005)(2906002)(26005)(7696005)(478600001)(186003)(85282002); DIR:OUT; SFP:1101; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 1wOQLyLEiEWORvmn+tZgaW75Y8pIlPTscM2pt13sw1TNSRjPs9lssYbHU05WcyQ4wJtn+BexYIu2NBKoj4HywHjwZ/3eZQq6Vns/dfsGdW9/QYUEpQYQiiIFNcYFls5/2lLhVRVHkw1ezR2wjyY/GqcfCREWubbRISyaRU2j7rvAYyzZimfrCFnkF7xAMeEDqgUGL+cSx/iePgjtS1jVelCtMykn7RIL6l9FSHtEaSyDijrkrw9XNC+V+biHH6cUxOPFTfjcxHaqmQFPsddtJL0yZG28+wVCOxOKVhBeRsisYMO8h+siKK0k6YkahO0TJvppaK/oD0CcArYrdGJOnB4lxdlagA/YtdseIdN3SKQ01/RL1TmyFb+ub6Jc7ryPrWj5BlD0Nu7w4i0B/FswuJHf0cLottfaQGXHhdfXbNq0iO2YWM0t7+2v1NqAv8Zo1w+G87KkmLnASArVcfhTpu2rwF5N9JitZ/G39pGKprl3AVciaA1VlijwcOUzixGHnS8B7WaePMSBk/NQ5+0yYA== x-ms-exchange-antispam-messagedata: c3hnrbAUDZwiJCOGfTP9FGkV5pzPHmGV/n8DQ/o8ExpsT63X9QtRxV5OKcNMzcF/00EZa06XlfvVypracUdwoipTXShCRMhKriOCcPvLv2Lns10VYGuVpM4HbtFpvTfjAIgOSmDfLI0xTrzJT6Gm1g== x-ms-exchange-transport-forked: True MIME-Version: 1.0 X-OriginatorOrg: mcafee.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3bafca21-96ce-430a-2cc8-08d7e4fc5f63 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Apr 2020 07:28:07.8771 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: WGZTtS0AG6v+YtHGCTWiqeHzhAUoam1BZVVXwjihHvLnjY91BKfkx5BFE7LXfL42ooeTB/+B//zEzgf9OfE47M8zuSKIpZFdSvK5dI5ePrtYF7W1PIiprWaf/0ggvZNy X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR1601MB1112 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: mcafee.com Content-Type: multipart/alternative; boundary="_000_CY4PR1601MB12541726BC79551C2A2EBBF0EAD40CY4PR1601MB1254_" Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-sfc-oam-framework 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, 20 Apr 2020 07:30:57 -0000 --_000_CY4PR1601MB12541726BC79551C2A2EBBF0EAD40CY4PR1601MB1254_ Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Reviewer: Tirumaleswar Reddy Review result: Ready with issues I reviewed this document as part of the security directorate's ongoing effo= rt to review all IETF documents entering the IESG. These comments are dire= cted at the security area director(s). Document editors and WG chairs shou= ld treat these comments like any other last call comments. This document provides a reference framework for OAM for SFC. Comments: 1. The document in Section 8 discusses various attacks (including both secu= rity and privacy) but does not discuss any protection mechanisms other than= proposing rate-limiting. It is suggesting drafts proposing the OAM soluti= on should address the attacks but I don't see any security mechanisms discussed in draft-ietf-sfc-ioam-nsh to address the attacks. 2. More discussion is required on the internal attacks. (a) How are attack packets bypassing SFC detected and blocked ? (b) How is sensitive information protected from eavesdroppers ? (c) How is DoS/DDoS attack of misusing the OAM channel is mitigated ? (d) Rate-limiting blocks both good and bad OAM probes and is a weak mitigat= ion strategy. Anomaly detection (e.g., deep learning techinques) and identi= fying the attacker look like a better strategy. Cheers, -Tiru --_000_CY4PR1601MB12541726BC79551C2A2EBBF0EAD40CY4PR1601MB1254_ Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable

    Reviewer: Tirumaleswar Reddy

    Review result: Ready with issues

     

     

    I reviewed this document as part of the security = directorate's ongoing effort to review all IETF documents entering the IESG= .  These comments are directed at the security area director(s). = Document editors and WG chairs should treat

    these comments like any other last call comments.=

     

    This document provides a reference framework for = OAM for SFC.

     

    Comments:

     

    1. The document in Section 8 discusses various at= tacks (including both security and privacy) but does not discuss any protec= tion mechanisms other than proposing rate-limiting.  It is suggesting = drafts proposing the OAM solution should address the attacks but I don’t see any security

    mechanisms discussed in draft-ietf-sfc-ioam-nsh t= o address the attacks.

     

    2. More discussion is required on the internal at= tacks.

    (a) How are attack packets bypassing SFC detected= and blocked ?

    (b) How is sensitive information protected from e= avesdroppers ?

    (c) How is DoS/DDoS attack of misusing the OAM ch= annel is mitigated ?

    (d) Rate-limiting blocks both good and bad OAM pr= obes and is a weak mitigation strategy. Anomaly detection (e.g., deep learn= ing techinques) and identifying the attacker look like a better strategy.

     

    Cheers,

    -Tiru

    --_000_CY4PR1601MB12541726BC79551C2A2EBBF0EAD40CY4PR1601MB1254_-- From nobody Mon Apr 20 06:20:05 2020 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 61F953A0CBB; Mon, 20 Apr 2020 06:19:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.201 X-Spam-Level: X-Spam-Status: No, score=-0.201 tagged_above=-999 required=5 tests=[DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=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 mDWrEDNZ7nNB; Mon, 20 Apr 2020 06:19:57 -0700 (PDT) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70080.outbound.protection.outlook.com [40.107.7.80]) (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 08CC13A08BE; Mon, 20 Apr 2020 06:19:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=oV1jd5FBYWYoSGAl8j00atZPTcQhRk0qEtoZ/PWaW71M7KGvZWmPjw8VcyaEorpRON7TVaEZ6g3IqOO+D1eTHTls4C0+g8Mat5I2TJAYLkXOz/2xkLUdlDtLnnVkpCSnOow312SdhK458C5zrSo81P9KgUFZuZKPv0ELkcSyoe1rgg/jXZCpFFbCw4hDtbLUOSDXV+L6E0aSaYezNCAiXCxjRDEk7og/b+5ZUPJx5sA1teFCsYhJX4PLADW5qY5JpuaAbUGJ14DTjCN5CkBUFl5FteAGQYAWkrdrA47JnndWnuhZ5TetfxRTWZ5wk/x+alQfYF0GaJJaYxQlF9ETfw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9mmBJBL4CF5hgjYYNIBDZYVUzoC0Ddk6VmPs+Em4FWQ=; b=AeaFFLodMKxGCsFuq/+q/I1N7A6EzBLHu7d4eHQNhy/3OXN6OhR3oXz3T89hscERUutF0urfASjFPbtPqIS6XpwTVyRs4L4oDrUzNYwtuJkl1novkJGS8/ie5axg9g86UBVPst68ZrMpaIdBzm33RZ2U8ddOd3tdqQ67XTbkIrvnCmhZlpftIMEDKtl3I4Tb/L/BKk6mDaaSA59gaRIVnIievy5JL5VbAPIKue6jCJuJmRFVMmJ8rs8jytpNL1b8hq+5giSngURD5pXL4/1DkmGLoimYLG1CRUNOUAAPn2Z/UDPgElprEBAJ8d1MJiAnUfJ5Tw7ugW/cG8Zs4myxdQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none 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=9mmBJBL4CF5hgjYYNIBDZYVUzoC0Ddk6VmPs+Em4FWQ=; b=WH16cBnIXElj0IqzfK3NnxLl92ha5z+jLUfN4flf8/WVfCCY01fpO4Neqrs1wnLHqxwUHuDWnLd4P1GevSOXJZ0lIcZmfQ35znWd9tq7fPoMFiKYD+Y/ZnPY8esKT84TVuWsNmbVAWLCCEOhPUVKmX+SC/lQj6Fu2i6qJZA9d8k= Received: from HE1PR0702MB3772.eurprd07.prod.outlook.com (2603:10a6:7:8e::14) by HE1PR0702MB3788.eurprd07.prod.outlook.com (2603:10a6:7:8a::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2921.14; Mon, 20 Apr 2020 13:19:54 +0000 Received: from HE1PR0702MB3772.eurprd07.prod.outlook.com ([fe80::ec28:2c21:6d78:917a]) by HE1PR0702MB3772.eurprd07.prod.outlook.com ([fe80::ec28:2c21:6d78:917a%2]) with mapi id 15.20.2937.011; Mon, 20 Apr 2020 13:19:54 +0000 From: Magnus Westerlund To: "stephen.farrell@cs.tcd.ie" , "secdir@ietf.org" CC: "tsvwg@ietf.org" , "draft-ietf-tsvwg-datagram-plpmtud.all@ietf.org" , "quic@ietf.org" Thread-Topic: Secdir telechat review of draft-ietf-tsvwg-datagram-plpmtud-19 Thread-Index: AQHWCsWYw97Id1VLoEyzmiYtqjx1D6iCFzQA Date: Mon, 20 Apr 2020 13:19:53 +0000 Message-ID: References: <158603467562.27263.2918619786629536861@ietfa.amsl.com> In-Reply-To: <158603467562.27263.2918619786629536861@ietfa.amsl.com> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Evolution 3.28.5-0ubuntu0.18.04.1 authentication-results: spf=none (sender IP is ) smtp.mailfrom=magnus.westerlund@ericsson.com; x-originating-ip: [98.128.243.69] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5e483291-3bbd-4933-be40-08d7e52d83ab x-ms-traffictypediagnostic: HE1PR0702MB3788: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 03793408BA x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0702MB3772.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(396003)(39860400002)(136003)(376002)(346002)(366004)(478600001)(2906002)(2616005)(6486002)(71200400001)(26005)(186003)(66476007)(66616009)(44832011)(4326008)(64756008)(66556008)(66946007)(6506007)(66446008)(76116006)(36756003)(316002)(110136005)(54906003)(8936002)(296002)(5660300002)(99936003)(6512007)(81156014)(8676002)(86362001)(99106002); DIR:OUT; SFP:1101; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: N1pgPYMk+J0guBzAWT86J/hg3AWl6KCp8BiaQd6u/QLQd356ifuILG9GCbri0GFvF3+HASZsb1Sz+c4Mbfze7SYqYaaEayOtRQdn07Y8iL+NWL7rfOnj7sGOi+IbQtRKraNgrzSpjAIMy8XZNFa3wP8/59vcuOfpeyP6M5YHt3iD4Ma7GI15/7bJ/fM2EsFHmyTU7U0LXdlrUhg3W4uj79X8hx6/nk95HFCG6hNgitEKfgFLec8HGMK+KGY9v1pnbUBli43bnsaHQbSsCmdL1PhGouKwbtjjcAv5ZYktdX4BR5ikqM7mpXCOqZ0UM0DOt2UELAJsjIZe6LKvC+E/zywpwRG5Qq2dW1wFbkFf1HhBtH63pGH24GuXTz1VnUgsI8by4qmbPkLfo/5bczLbGhi2eFDJZ5VYyoQukLlz4fZYb30PkOmX+qZv5D8uyx17NSvixTA/YNwVx+l3GT0sBWjj4P1RPWPv76/zqyqxD4cv9BiZAwcSNQpOnNqOdkhH x-ms-exchange-antispam-messagedata: Y2mYZGX8JYwSa0y2z3THjNMb1nvV0ntiKi4KxVgEDFKBrpkJSyCNLLilbkrvf+LwMksQppo0iuksGZ93BKRUjJE4a19HJ5/F3l1ZNPTXMvEvfmb5e/FmDiLT3OzUAdakYKOyqty7IpliGW7hN8OtV04HjUWOJT7X0Sm0Ud4yfvZLhY0MYw+krcjDJunDrl+TvEkVDloC+388kXBe1m2SwBHeFutmDWfv3lZMNscA0+W4Tzx3nbqIAhVadLlCxqr7cEzxftoOjgWjfsJE17ObRg+QONhDzWOMd1H1yLZgBXZCSD0HLvnC17+TH/NOgAB/B9OCB+wxP6PWkpznOSI8U1IwUeEaZtVOBs8GNiHY4X99dn7JnVhwEOFTT+rjLxITC0RYKTZhKUwayMSUFE90Kqlk1q7GxHPYqz2KM56VzV00SAvMciQqkbOSZbEYVHlRvkpvPm9MyE2cFO99egtDeLDJdN78Q4fq2jFWOoI8/Dv4X8zGI0lUVT5KyI74pSWJEu1xpKIfmOD9RwN0YfPeoEna9k6nbdSLTdqaw01KMtsykrO6v0sO8NP3FuIVHjceIVknoxcYOHNcNj9hc1D1q3R9kkFLzLy4+esk5B/mlyijcbx6WhqzFODxzR8EaPvPteW3fT8iXPjooj3j2yOcf8w8s6bTB9LYSbBr4SJnlZkvbnRx0kkw4dP3z6NXVzu3O4nm8gqA1Kq+qN1rZVkzEXuYRzZsPOFUNLPNL+/hhFg2SVQzyxHUC7N0W5iB1O2QborEMzBKnJjQqz9gEgOy00kq6uSCC/XMIbnQHbg/OMo= x-ms-exchange-transport-forked: True Content-Type: multipart/signed; micalg="sha-256"; protocol="application/x-pkcs7-signature"; boundary="=-IQy8ZSf5Xa92C12qPsto" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5e483291-3bbd-4933-be40-08d7e52d83ab X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Apr 2020 13:19:53.9575 (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-CrossTenant-userprincipalname: Pl7fUzgBk5eHeGjTii/ZVGZ30S+wj95qDwk7io0Xw2AtAcgM8WSz2/kxpnaw22I1w4oKaAeQEyTYE87x0AWVPQA9b/fflGXTbFaS5luM2Q0= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0702MB3788 Archived-At: Subject: Re: [secdir] Secdir telechat review of draft-ietf-tsvwg-datagram-plpmtud-19 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, 20 Apr 2020 13:20:00 -0000 --=-IQy8ZSf5Xa92C12qPsto Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Stephen, (Dropping last-call, adding QUIC WG) You do have a point here. Considering that QUIC transport is not ready, I t= hink the alternative to have this document hang in RFC-editors queue is to actua= lly move Section 6.3 into draft-ietf-quic-transport.=20 QUIC WG what do you think of that solution? It would allow draft-ietf-tsvwg= - datagram-plpmtud to be published without delays.=20 Cheers Magnus Westerlund On Sat, 2020-04-04 at 14:11 -0700, Stephen Farrell via Datatracker wrote: > Reviewer: Stephen Farrell > Review result: Has Nits >=20 >=20 > Thanks for addressing my earlier secdir comments on -15. I think > the ones below remain but are, from my POV, nits: >=20 > - Abstract: This draft aims for proposed standard but is > updating a BCP (RFC8085/BCP145). I'm happy to leave the > process-lawyering for that to others. >=20 > - 6.3: I am surprised that the QUIC description here is ready > to be an RFC before QUIC itself. I do see there are > normative references, but the potential for a breaking change > still exists, and seems a bit unwise. (I'd suggest, holding > this in the WG 'till the referenced QUIC drafts are in the RFC > editor queue, or else taking that bit out and putting it into > a new I-D.) >=20 >=20 --=20 Cheers Magnus Westerlund=20 ---------------------------------------------------------------------- Networks, Ericsson Research ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Torshamnsgatan 23 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- --=-IQy8ZSf5Xa92C12qPsto Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCEtww ggYHMIID76ADAgECAhALRm3NcHtuMGWutmt5cXntMA0GCSqGSIb3DQEBCwUAMEcxCzAJBgNVBAYT AlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBD QSB2MzAeFw0xNzEyMTUwNzIyMjNaFw0yMDEyMTUwNzIyMjJaMHAxETAPBgNVBAoMCEVyaWNzc29u MRowGAYDVQQDDBFNYWdudXMgV2VzdGVybHVuZDEtMCsGCSqGSIb3DQEJARYebWFnbnVzLndlc3Rl cmx1bmRAZXJpY3Nzb24uY29tMRAwDgYDVQQFEwdlcmFtc3dkMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEAsKlHZvB3TsmLEDtPSiFFKAh73S2wApt+laqg5eXTqonqnzT9ykEGL2dx9mBT +2WZiIKxo4w2sisVl3EEYTqXTkctpur7cN29gLC8F3tJHGI2sUVpO9AwpVrN+UuHEVetHt7hdxW9 uYd0LJJ8TP6/wGkIfAFaZxlZUn79O2eHElfih1iVIiTZXLcEe1rBJtzhUNRHWgOm2vQlDJ4sCpig GFq5w+XSRviEQMkQZRvw1CQmb35QS/C/T36ogzIRHDuAdkoSaiUOY/S2dLp4HkwvOOg+tADpaHkr bdmdnjKGrYSnJigmxw14pJugxL/Vb2EeVcgpAfVVst7Lm4POPRI8+wIDAQABo4IBxDCCAcAwSAYD VR0fBEEwPzA9oDugOYY3aHR0cDovL2NybC50cnVzdC50ZWxpYS5jb20vZXJpY3Nzb25ubGluZGl2 aWR1YWxjYXYzLmNybDCBggYIKwYBBQUHAQEEdjB0MCgGCCsGAQUFBzABhhxodHRwOi8vb2NzcDIu dHJ1c3QudGVsaWEuY29tMEgGCCsGAQUFBzAChjxodHRwOi8vY2EudHJ1c3QudGVsaWFzb25lcmEu Y29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5jZXIwKQYDVR0RBCIwIIEebWFnbnVzLndlc3Rl cmx1bmRAZXJpY3Nzb24uY29tMFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQESMDowOAYIKwYBBQUH AgEWLGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMB0GA1UdJQQW MBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4EFgQU5ivuhpU51W4UhBDBWwf8XsU837YwHwYD VR0jBBgwFoAUHHsZnpecdqwgPdjc45Fq49stplMwDgYDVR0PAQH/BAQDAgWgMA0GCSqGSIb3DQEB CwUAA4ICAQBn0FKukg00UN/c/ESpxSIaYTrsd8liHHMu5rLpOBNOacpGNBMGNgUDDt4QihhoQR3c vhYXCrAM59NTvw0HNlgqHZoEeVY7YnJJYnJXDCLUfkK5Dn28E3QrzykkF6giUOXDyF9mhWYbSAkJ yx0Yj0Xc8en3wYNyoFYEqjlKtZrdV0pcgFzEeXVLS8DWrzSy7+KfUtDOEiM6H3zO3nsq++KBmsOi SKkWn4oYERZg5KElEAHis9av+3KIaEPnOAt8QRWRpFfGZ4d89F16qFvElup5n7l864FqxnC2friD o4hLQY6ENaOaYIihXhbl2UYxAGDk89aJm/S5pYyq7wzm+KK3IcUl60rmc8SJlt6QXKw0wXEOE1Mu bauYKMsad2s8jD+rEkXp+agTRl+sezWaRxHBpxuUKDd6MhwDig3SZi1qP7D/Ds4V+JLIjjUJc25l 9tvMGC9+lqI0P+vMI3Zyrou0NNfb55uLQaq18O+7BZ8Kv7jvFdxYyUgbxQ0SPEiyhylcLHAmJeLC QaiZHmCREBkCLKSf0O4lE2TrVzdOD38wjzuQ27U3UddVCD9EQ3tF7o6EVhpxJJUlB6xe/2UWwy4Z la71dKLUhakdVrN5abzxqFWvzOAT9nBa2HzYVBtpbcu6KGh72YJ+M79fa9iIkcQCgUnw3gIAeWd/ /n4YbY2QhDCCBgcwggPvoAMCAQICEAtGbc1we24wZa62a3lxee0wDQYJKoZIhvcNAQELBQAwRzEL MAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRp dmlkdWFsIENBIHYzMB4XDTE3MTIxNTA3MjIyM1oXDTIwMTIxNTA3MjIyMlowcDERMA8GA1UECgwI RXJpY3Nzb24xGjAYBgNVBAMMEU1hZ251cyBXZXN0ZXJsdW5kMS0wKwYJKoZIhvcNAQkBFh5tYWdu dXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20xEDAOBgNVBAUTB2VyYW1zd2QwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCwqUdm8HdOyYsQO09KIUUoCHvdLbACm36VqqDl5dOqieqfNP3K QQYvZ3H2YFP7ZZmIgrGjjDayKxWXcQRhOpdORy2m6vtw3b2AsLwXe0kcYjaxRWk70DClWs35S4cR V60e3uF3Fb25h3QsknxM/r/AaQh8AVpnGVlSfv07Z4cSV+KHWJUiJNlctwR7WsEm3OFQ1EdaA6ba 9CUMniwKmKAYWrnD5dJG+IRAyRBlG/DUJCZvflBL8L9PfqiDMhEcO4B2ShJqJQ5j9LZ0ungeTC84 6D60AOloeStt2Z2eMoathKcmKCbHDXikm6DEv9VvYR5VyCkB9VWy3subg849Ejz7AgMBAAGjggHE MIIBwDBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vY3JsLnRydXN0LnRlbGlhLmNvbS9lcmljc3Nv bm5saW5kaXZpZHVhbGNhdjMuY3JsMIGCBggrBgEFBQcBAQR2MHQwKAYIKwYBBQUHMAGGHGh0dHA6 Ly9vY3NwMi50cnVzdC50ZWxpYS5jb20wSAYIKwYBBQUHMAKGPGh0dHA6Ly9jYS50cnVzdC50ZWxp YXNvbmVyYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYzLmNlcjApBgNVHREEIjAggR5tYWdu dXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20wVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBARIwOjA4 BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMw HQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMB0GA1UdDgQWBBTmK+6GlTnVbhSEEMFbB/xe xTzftjAfBgNVHSMEGDAWgBQcexmel5x2rCA92NzjkWrj2y2mUzAOBgNVHQ8BAf8EBAMCBaAwDQYJ KoZIhvcNAQELBQADggIBAGfQUq6SDTRQ39z8RKnFIhphOux3yWIccy7msuk4E05pykY0EwY2BQMO 3hCKGGhBHdy+FhcKsAzn01O/DQc2WCodmgR5VjtickliclcMItR+QrkOfbwTdCvPKSQXqCJQ5cPI X2aFZhtICQnLHRiPRdzx6ffBg3KgVgSqOUq1mt1XSlyAXMR5dUtLwNavNLLv4p9S0M4SIzoffM7e eyr74oGaw6JIqRafihgRFmDkoSUQAeKz1q/7cohoQ+c4C3xBFZGkV8Znh3z0XXqoW8SW6nmfuXzr gWrGcLZ+uIOjiEtBjoQ1o5pgiKFeFuXZRjEAYOTz1omb9LmljKrvDOb4orchxSXrSuZzxImW3pBc rDTBcQ4TUy5tq5goyxp3azyMP6sSRen5qBNGX6x7NZpHEcGnG5QoN3oyHAOKDdJmLWo/sP8OzhX4 ksiONQlzbmX228wYL36WojQ/68wjdnKui7Q019vnm4tBqrXw77sFnwq/uO8V3FjJSBvFDRI8SLKH KVwscCYl4sJBqJkeYJEQGQIspJ/Q7iUTZOtXN04PfzCPO5DbtTdR11UIP0RDe0XujoRWGnEklSUH rF7/ZRbDLhmVrvV0otSFqR1Ws3lpvPGoVa/M4BP2cFrYfNhUG2lty7ooaHvZgn4zv19r2IiRxAKB SfDeAgB5Z3/+fhhtjZCEMIIGwjCCBKqgAwIBAgIQU7h+g+GcmSiTsJtJHOy46zANBgkqhkiG9w0B AQsFADA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEfMB0GA1UEAwwWVGVsaWFTb25lcmEgUm9vdCBD QSB2MTAeFw0xNTEwMjcxMjE2NDZaFw0yNTEwMjcxMjE2NDZaMEcxCzAJBgNVBAYTAlNFMREwDwYD VQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MzCCAiIw DQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAOzy3wAAuFDyp7vYVLfGk/fjwao71MNGNLSzzl5D tjQtMtl2ZLPZyX6ViqzTN9JOb7uZ6KxuGSpReQvt8XOh7iIhkKH9W5hRpbjTsJmUMJd6zifhOpNK 6iSU3q44+FjsQL1lVtcguUuFG6aZN0N3GFVbgt6jRrASF8t/3wy9bHPAIfMyPybpg6Y2PH5/1Nwk TepoDSmK69LGV+lV2IK6U9OWayZXZFIFIDCoGyFlhFxAEgN+qZ2+Rqg/0TM0oCHvKO2ELSGmAdnJ kwizR42ji/Y9SYTSuG75mzSe6OfCGWM8Db/xvy/20aLEPXNu1PvOgzY63WZ6cmkWnjMlVJ90pWC2 haqDm3Yf8TRdjUvAl7Pz1bTuexwShzIGakL7MkCYrEqHMRaojI/VStloQgW76E76zQ2byw5QxrhO UbisBSKRzlTlOZQgYFFAbG6ViF8DOpJh/ygtQwuTLUM5r15G7eynQV1AMTNCWcX+HUvgArUw6RfW 9L58uA68GjktFTV8s9RlDsUqsNcLqeXaV28S2WMday0YGaq/bloS8AD7KuumUKH+Ri9IGO9mJvP0 5tvDHjKpLvv80c3WLJnJU/aznYHYEt2+jjKHOTqdGTxL/zMdpRSQFSuu+KM8NoYrkU1VJqKga+QL sgqKghMp99gu1P1e6KsqseWHdXORrMbjqkBXAgMBAAGjggG4MIIBtDCBigYIKwYBBQUHAQEEfjB8 MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50cnVzdC50ZWxpYXNvbmVyYS5jb20wSwYIKwYBBQUH MAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJv b3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/AgEAMFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQEC MDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20v Q1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0dHA6Ly9jcmwtMy50cnVzdC50ZWxpYXNvbmVyYS5jb20v dGVsaWFzb25lcmFyb290Y2F2MS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA4G A1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUHHsZnpecdqwgPdjc45Fq49stplMwHwYDVR0jBBgwFoAU 8I9ZOACz9Y+algzV6/p7qhfoExIwDQYJKoZIhvcNAQELBQADggIBAFBYa/HVjDu0LqtXQ8iMp8PL Fpqchf41ksQY6R1AsoZbaBUu0NQlAQ9GzlC1pmI5s0cJnuaZI0xV6TiWS3/R2p9UgW61XD9CTIUb AL31mY3BdJf3P46gzKgQEca/DlFjq9GVmuPS4q90BLNgvgoxoHubc3C6s0OaY1sbnay5EhnvrAE4 Q511FlxmJPLnRmQGpieeXa3cPegFfY1kJDKyyFRypF1RuRLXcdMIgKEy5NX1bS3M9dQ4mgmUmVT2 d33UiKSEYQ6s/B+LFaaz4LywXSv2o3W4kbHoQs86IWst821ww0wxsCpEfClIvF7fBw2QkbG/1Pwu zAuLVStEhDzkAqOrMGctKyNEaBsyAn7Eq2eCa8QDXnkmagp9QPsNFs/oqnXj9j1cVtH9a4OPzhtg 0pd7gd0NzU/5QxibXqbYvouQgihGXHQDmaL4ruN7C4arMUqRo82YnREsKL7h3j/jtmzcMLc9Q07F 04QQd/iSR1Y5pIi6PdNBiE2/4uyAXS6KOIGZrPbNQUNrZtwiQpqQNl8AUzgegfPwrYFlFocpaF3d 1m5r+2VKKqiRQVfYPGYeZnWfkcz06JoAhc/9mjbHXSP9hvWYzeLRuoZqHGUdjOX9DIQb926OneV7 C5WMIjSY8ORkamG/HKqngmjypL3gSc6oG/E6B+1i6Ds5j0Qpj5aQMYICzTCCAskCAQEwWzBHMQsw CQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2 aWR1YWwgQ0EgdjMCEAtGbc1we24wZa62a3lxee0wDQYJYIZIAWUDBAIBBQCgggFDMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTIwMDQyMDEzMTk1MlowLwYJKoZIhvcN AQkEMSIEIHuctY4hEqSVid7KMY9NdWFt447f8mxaUfUo1T1uraj3MGoGCSsGAQQBgjcQBDFdMFsw RzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJ bmRpdmlkdWFsIENBIHYzAhALRm3NcHtuMGWutmt5cXntMGwGCyqGSIb3DQEJEAILMV2gWzBHMQsw CQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2 aWR1YWwgQ0EgdjMCEAtGbc1we24wZa62a3lxee0wDQYJKoZIhvcNAQEBBQAEggEAk9THM+UQHcoP g0zAuolRIA1BdDRv2XPDFP+C20QefIjW+3Sx1czzoSE7XM4javRZxypTrUjtehEQzsaxucqwJwTY 4UIonACzYHCThpRrfphHIVGfGRNjk7hI2c8uSgk9LB7BC6DQSzW+eojXovgz0ySnyJyc2gdXwgb+ b5EqH9PFSkZ04NCLkh0RahtvdF096vJN5ro+/HIgXvpVLqSChT9iyYnJgqLACrEJOivUr7HkmyV6 9kDORLwYaIXdPzB5qjt7jixDTJr4XL/Gf34W42RRLzpNTyhgovbREA6xNTX6J2OV2dJ8qlDYsHjN 9zowfhImki3ry44gAE0EYPx6DAAAAAAAAA== --=-IQy8ZSf5Xa92C12qPsto-- From nobody Mon Apr 20 07:09:57 2020 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 50A1E3A046E; Mon, 20 Apr 2020 07:09:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.053 X-Spam-Level: X-Spam-Status: No, score=0.053 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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 NnquqqTd562E; Mon, 20 Apr 2020 07:09:34 -0700 (PDT) Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) (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 64B823A047F; Mon, 20 Apr 2020 07:09:34 -0700 (PDT) Received: by mail-wr1-x431.google.com with SMTP id g13so10314635wrb.8; Mon, 20 Apr 2020 07:09:34 -0700 (PDT) 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=Av8vaIMv72Iabu9cFx3N5HQ5j8XO4zBxad1HRK4mpCI=; b=c6vM/5GwFB72MuJkWDCef2JrRI9wS1y+PP0srvG73sMD88TMkcMK40/J6nvTR9Oxn6 nVGySuGYAV6Fm6OIqdYn/NvBtVDCrmIEXWign5FYf7q0Mu0rrxElwZPkI0HgBErClkdR esKlYp8Wa11k+04lPo+MI7qUuK8f3pmBbDIdWhWCyxz/QK9iSRs3+EMH/9FAPVyEpU/x isOhR1vRyYMVzrn+dyYdRI9RNQ7L5AgXjqGkOGUlBUDnNc0BRTAB39LpVutQOL/QoL1H WkiHvzWkqWX52U0S9lx3RxlGHpDYYAvwelbnC5sd7rbGUm/8XeLHlG9g2o3D5ikpJV3D 8sNw== 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=Av8vaIMv72Iabu9cFx3N5HQ5j8XO4zBxad1HRK4mpCI=; b=T5zV3tGqQ3pZeU0801crMWtzpQmpmGMnT4Ll0rj2A/8q36NMoPzIjE7rKZhITkFBEX yUB/VCwlPoWeSHSSilnOYPeqo+YSzKvJ25PlQ8plK6z6ioPLf+t+48WRiuDuTyP/85Nd QFtu/yTUSBixFGaYHWb2ZeNh/gsSpFBnB2JYxGGhLLKKpyCSAffkiYY5rwJtvILaLhN3 /yueXnSOa+Z+BSVcNdFFUBxId3RqLr2y2NulSy7VF8UDGpPwnUjH/207/NT0XjD0KPmb f7rTtbKtAXwFs14dBEC9Vg9VXgyKPMSY2gVgVylRXP3KsQEKeavK9cCahRvIU0C+tfFO +OhQ== X-Gm-Message-State: AGi0PuYHv8wc4hXbmE3dS4r8M/Aqc4vpkH7iCFBKrPXsKpH65Hov2MVJ bnwQ738g5kddJ7hKwJPE9JMI/+v2Yte8fl5wwlE= X-Google-Smtp-Source: APiQypJYq1GQ955xD3RWPJYq0Vn9mIAO2LS7TtCGZA28oDFIVTDj2/NOO/pfvKeh0frud+94RMARu/WUex64IIU7Av0= X-Received: by 2002:a5d:6503:: with SMTP id x3mr20831836wru.153.1587391772073; Mon, 20 Apr 2020 07:09:32 -0700 (PDT) MIME-Version: 1.0 References: <158603467562.27263.2918619786629536861@ietfa.amsl.com> In-Reply-To: From: Lucas Pardue Date: Mon, 20 Apr 2020 15:09:20 +0100 Message-ID: To: Magnus Westerlund Cc: "stephen.farrell@cs.tcd.ie" , "secdir@ietf.org" , "quic@ietf.org" , "tsvwg@ietf.org" , "draft-ietf-tsvwg-datagram-plpmtud.all@ietf.org" Content-Type: multipart/alternative; boundary="000000000000b1a3c105a3b97231" Archived-At: Subject: Re: [secdir] Secdir telechat review of draft-ietf-tsvwg-datagram-plpmtud-19 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, 20 Apr 2020 14:09:37 -0000 --000000000000b1a3c105a3b97231 Content-Type: text/plain; charset="UTF-8" Hi Magnus, Speaking as an individual because I have not conferred with other QUIC chairs or list: On Mon, Apr 20, 2020 at 2:21 PM Magnus Westerlund wrote: > Hi Stephen, > (Dropping last-call, adding QUIC WG) > > You do have a point here. Considering that QUIC transport is not ready, I > think > the alternative to have this document hang in RFC-editors queue is to > actually > move Section 6.3 into draft-ietf-quic-transport. > > QUIC WG what do you think of that solution? It would allow > draft-ietf-tsvwg- > datagram-plpmtud to be published without delays. > > My 2c: QUIC says endpoints SHOULD use DPLPMTUD or something else. So I don't see including some more text as being a protocol design change. However, it can't simply be copied verbatim and would need some editorial work (for example, DPLPMTUD Section 6.3.3 includes a MUST NOT, which might need some contextualization in the QUIC document). The migration would also require an editorial pass in DPLPMTUD to make sure remaining use to QUIC outside section 6.3 are correct. The QUIC editors are busy, so the proposal is more palatable if you have a volunteer to put some effort into this. Cheers Lucas --000000000000b1a3c105a3b97231 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi Magnus,

    = Speaking as an individual because I have not conferred with other QUIC chai= rs or list:

    On Mon, Apr 20, 2020 at 2:21 PM Magnus Westerlund <= magnus.westerlund=3D40eric= sson.com@dmarc.ietf.org> wrote:
    Hi Stephen,
    (Dropping last-call, adding QUIC WG)

    You do have a point here. Considering that QUIC transport is not ready, I t= hink
    the alternative to have this document hang in RFC-editors queue is to actua= lly
    move Section 6.3 into draft-ietf-quic-transport.

    QUIC WG what do you think of that solution? It would allow draft-ietf-tsvwg= -
    datagram-plpmtud to be published without delays.


    My 2c: QUIC says endpoints SHOULD use = DPLPMTUD or something else. So I don't see including some more text as = being a protocol design change. However, it can't simply be copied verb= atim and would need some editorial work (for example, DPLPMTUD Section 6.3.= 3 includes a MUST NOT, which might need some contextualization in the QUIC = document). The migration would also require an editorial pass in DPLPMTUD t= o make sure remaining use to QUIC outside section 6.3 are correct. The QUIC= editors are busy, so the proposal is more palatable if you have a voluntee= r to put some effort into this.

    Cheers
    L= ucas
    --000000000000b1a3c105a3b97231-- From nobody Wed Apr 22 05:03:23 2020 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 60F8A3A0A94; Wed, 22 Apr 2020 05:03:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 ln7uBiLXqpwC; Wed, 22 Apr 2020 05:03:20 -0700 (PDT) Received: from vs22.mail.saunalahti.fi (vs22.mail.saunalahti.fi [193.64.193.198]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9C783A0A93; Wed, 22 Apr 2020 05:03:19 -0700 (PDT) Received: from vs22.mail.saunalahti.fi (localhost [127.0.0.1]) by vs22.mail.saunalahti.fi (Postfix) with ESMTP id A6BF220303; Wed, 22 Apr 2020 15:03:17 +0300 (EEST) Received: from gw02.mail.saunalahti.fi (gw02.mail.saunalahti.fi [195.197.172.116]) by vs22.mail.saunalahti.fi (Postfix) with ESMTP id 9B2132027E; Wed, 22 Apr 2020 15:03:17 +0300 (EEST) Received: from eggert.org (unknown [62.248.255.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: eggert@elisanet.fi) by gw02.mail.saunalahti.fi (Postfix) with ESMTPSA id 514FE40003; Wed, 22 Apr 2020 15:03:11 +0300 (EEST) Received: from stickers.eggert.org (stickers.eggert.org [172.21.96.212]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by eggert.org (Postfix) with ESMTPSA id A043F87233F; Wed, 22 Apr 2020 15:03:06 +0300 (EEST) From: Lars Eggert Message-Id: <5CA9F5F9-67F9-4739-9991-E4C9E5F760B8@eggert.org> Content-Type: multipart/signed; boundary="Apple-Mail=_B344FD70-7C7B-4477-9ED8-1E8B4D36EE3D"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Wed, 22 Apr 2020 15:03:06 +0300 In-Reply-To: Cc: Stephen Farrell , "secdir@ietf.org" , "quic@ietf.org" , "tsvwg@ietf.org" , "draft-ietf-tsvwg-datagram-plpmtud.all@ietf.org" To: Magnus Westerlund References: <158603467562.27263.2918619786629536861@ietfa.amsl.com> X-MailScanner-ID: A043F87233F.A6B70 X-MailScanner: Found to be clean X-MailScanner-From: lars@eggert.org Archived-At: Subject: Re: [secdir] Secdir telechat review of draft-ietf-tsvwg-datagram-plpmtud-19 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, 22 Apr 2020 12:03:22 -0000 --Apple-Mail=_B344FD70-7C7B-4477-9ED8-1E8B4D36EE3D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2020-4-20, at 16:19, Magnus Westerlund = wrote: > You do have a point here. Considering that QUIC transport is not = ready, I think > the alternative to have this document hang in RFC-editors queue is to = actually > move Section 6.3 into draft-ietf-quic-transport. >=20 > QUIC WG what do you think of that solution? It would allow = draft-ietf-tsvwg- > datagram-plpmtud to be published without delays. the chairs discussed this for a bit, and we're a bit hesitant to go this = route. IIRC, if both docs have mutual normative references to one another, they = get clustered and published together anyway. Do we need more? If we actually want to WGLC them together, TSVWG can maybe park -plpmtud = for a bit? Thanks, Lars --Apple-Mail=_B344FD70-7C7B-4477-9ED8-1E8B4D36EE3D 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----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAl6gMnoACgkQVLXDCb9w wVfcXg/+M52uoZd8IJeiCHnbjwQKAhVQnT1UfA0WewHA6EmAbPbGDhAUWdb5ktqJ MV4zMzThPFJvqhUfg00+ATK+enDow0QNy95tSfXHaioZuWrIWqwCVeZW7MO2kFGe EQeJLsWgjH4yO69CDe09EMqNxDPsIjWddC//buxtk1SIx/MYdJgRW3+PUYF7u6qR UYP+FxvXvXz0rtpSg1mZrdVLwYljfPb53e2DpsrJSGGLeBiXEU3GB6sYfA3SsRCH AzUDW/SROZ3WL7NM04vZ+qJoL2Cj1sM3OwVS+kTPYdU+GPmU+hpGoVQTHrdxxx58 rOrJ1s3VTV+JOQPn0eG5XkJUQ+bZls8tBXrSJsMhNfWsVMXoWaWAsmHWIhNGE+pU xR0Jkf2JyC0+JLIoN31vwywQf47ZqQU8M/4gqcSfE/igfwHzfJdAKKc/dLsJgwzv AAYc5G8za3j0gMow5OAq1Pl9tqn2UoMJpDVBK9gVB1Njm1FNBXgJzcHKY1e/rNnB 62KWcTxORc9nCpTH2S7/gEWBkMI2aagzjlZpegga7Sj/xLIiyzEfrfdlYjan++CE LoXAFfzq8iapkNXE+1zhZgBiqtP/6JdMVYmZDKsFc2Et+fBq/KgJT0z68V9azGZU 5UBwfDoqy1hVjRBGvhOkSvSqkreJXzcLVsoVDhr/v2d8dXUg8Ms= =jS7H -----END PGP SIGNATURE----- --Apple-Mail=_B344FD70-7C7B-4477-9ED8-1E8B4D36EE3D-- From nobody Wed Apr 22 10:40:55 2020 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 B60523A107A; Wed, 22 Apr 2020 10:40:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.92 X-Spam-Level: X-Spam-Status: No, score=-2.92 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, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.82, 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=apple.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 oIsNYnnfg3Oy; Wed, 22 Apr 2020 10:40:29 -0700 (PDT) Received: from ma1-aaemail-dr-lapp01.apple.com (ma1-aaemail-dr-lapp01.apple.com [17.171.2.60]) (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 A989A3A1085; Wed, 22 Apr 2020 10:40:28 -0700 (PDT) Received: from pps.filterd (ma1-aaemail-dr-lapp01.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp01.apple.com (8.16.0.42/8.16.0.42) with SMTP id 03MHKubf009136; Wed, 22 Apr 2020 10:40:27 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=vJ2b6JqtxWjFG+u9sMDweo9mmEjM58RJYgtSwdMi6j8=; b=MCIsuQViGhsylvm/vHzVxPxJ+kgibuO6VrAYCmxRziXxJqR4np+lqnaqsLBM4hjFKhos ATIWDajEl9HESPGpWLY7f/LqBhrfwzKJnAbtkiTV8tYaC53vNH+iPK5nCoB9nCRVNDqT q8aI2oqCu1D4nmLiCGCTLm8R1oBaFdHP2spTXnAtMS/EW9TYCPbZdtthubciKOCSrhec uiaEy3dwPbB0acrLijVhFtuIPychPwpT/ll3fhy1z2bwXwzig50bd4DVTPZsAqZo4iqj 3vPkzh/4nXDmWbwPbUDZ82H5rNbOLjzjXpOVe5DxizKIYXzr8+Twk26gQWu26QLc1RAA Og== Received: from rn-mailsvcp-mta-lapp03.rno.apple.com (rn-mailsvcp-mta-lapp03.rno.apple.com [10.225.203.151]) by ma1-aaemail-dr-lapp01.apple.com with ESMTP id 30hfm8qg38-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 22 Apr 2020 10:40:27 -0700 Received: from rn-mailsvcp-mmp-lapp03.rno.apple.com (rn-mailsvcp-mmp-lapp03.rno.apple.com [17.179.253.16]) by rn-mailsvcp-mta-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) with ESMTPS id <0Q97007EYAFE4O40@rn-mailsvcp-mta-lapp03.rno.apple.com>; Wed, 22 Apr 2020 10:40:26 -0700 (PDT) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp03.rno.apple.com by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) id <0Q97008009LCHV00@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Wed, 22 Apr 2020 10:40:26 -0700 (PDT) X-Va-A: X-Va-T-CD: 87664f9d82f37ffc26ec7a9e377fbbd0 X-Va-E-CD: 7d5012b5022cd168c2069f5acb778cdc X-Va-R-CD: 7dceb8163aa915c9fea3d2dc5ac00017 X-Va-CD: 0 X-Va-ID: bdeca734-cb6c-49b6-bdc4-53d326a446d7 X-V-A: X-V-T-CD: 87664f9d82f37ffc26ec7a9e377fbbd0 X-V-E-CD: 7d5012b5022cd168c2069f5acb778cdc X-V-R-CD: 7dceb8163aa915c9fea3d2dc5ac00017 X-V-CD: 0 X-V-ID: 7691e565-f993-4609-a630-8f1b3c4d2fa9 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.676 definitions=2020-04-22_06:2020-04-22, 2020-04-22 signatures=0 Received: from [17.232.192.67] (unknown [17.232.192.67]) by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) with ESMTPSA id <0Q9700F9FAFBRC00@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Wed, 22 Apr 2020 10:40:25 -0700 (PDT) From: Tommy Pauly Message-id: <27E233E4-CD15-477C-9FE2-A6191ADB6E0F@apple.com> Content-type: multipart/alternative; boundary="Apple-Mail=_04244C08-F17C-418C-A70D-EF7B04826354" MIME-version: 1.0 (Mac OS X Mail 13.4 \(3608.80.7.2.3\)) Date: Wed, 22 Apr 2020 10:40:23 -0700 In-reply-to: <158696570597.6243.17363184130849112053@ietfa.amsl.com> Cc: secdir@ietf.org, last-call@ietf.org, draft-ietf-taps-transport-security.all@ietf.org, taps@ietf.org To: Paul Wouters References: <158696570597.6243.17363184130849112053@ietfa.amsl.com> X-Mailer: Apple Mail (2.3608.80.7.2.3) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.676 definitions=2020-04-22_06:2020-04-22, 2020-04-22 signatures=0 Archived-At: Subject: Re: [secdir] [Taps] Secdir telechat review of draft-ietf-taps-transport-security-11 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, 22 Apr 2020 17:40:32 -0000 --Apple-Mail=_04244C08-F17C-418C-A70D-EF7B04826354 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Paul, Thanks for the review! You can find an updated version of the document = here: = https://ietf-tapswg.github.io/draft-ietf-taps-transport-security/draft-iet= f-taps-transport-security.html = Responses inline. > On Apr 15, 2020, at 8:48 AM, Paul Wouters via Datatracker = wrote: >=20 > Reviewer: Paul Wouters > Review result: Has Nits >=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 Has Nits >=20 > Compared to my last review (-09) a lot of text has been removed, = reducing the > technical details and giving a briefer (but arguably cleaner) = overview. >=20 > I do still have a personal preference of dropping CurveCP and MinimalT = as I > don't really think these are anything but abandoned research items. I = have > never seen or heard of these being deployed. I would be more tempted = to list > openconnect (draft-mavrogiannopoulos-openconnect) which actually does = see quite > some deployment. If the intent is really to show different kind of = API's, than > there are other esoteric examples that could be included, such as > Off-The-Record(OTR) or Signal, which are mostly encrypted chat = programs, but > with the ability to generate session keys for encrypted bulk transport = (eg for > video/audio or file transfer) We discussed for Signal and OTR. Our sense was that these protocols are = more asynchronous application-layer protocols that are akin to MLS, that = can be more independent from a transport layer. >=20 > Section 5.1 >=20 > "Session Cache Management (CM):" which does not include IKEv2/IPsec, = even > though it does have session resumption (RFC 5723). I guess this is = because the > section limits itself to "the application" that can restart the = session. But > for IKEv2/IPsec the same could be said. An application that after a = long idle > period sends a packet, triggers a kernel ACQUIRE, which triggers an = IKEv2 > session resumption. WireGuard does not have this capability as there = are no > API/hooks for packet trigger tunnel events (AFAIK) Indeed, this refers to an explicit interface for cache management. >=20 > "Pre-Shared Key Import (PSKI):" lists WireGuard, but AFAIK it does not = support > PSK based authentication - only public key based authentication. We discussed that WireGuard uses the IKpsk2 Noise pattern (see = https://www.wireguard.com/protocol/, and = https://noiseexplorer.com/patterns/IKpsk2/), in which a responder uses = its PSK to additionally authenticate a connection. > While I > understand the IKEv2 entry (PSKs are used for authentication of = peers), I am > not sure the ESP entry should be here. ESP does not "authenticate = peers", > unless you call "being able to decrypt and authenticate packets" as an = instance > of "authenticating peer" We=E2=80=99ve changed the reference to be IPsec as a unit for IKEv2 + = ESP in these lists. >=20 > Section 5.2 >=20 > This states "This can call into the application to offload = validation.". This > "can" is only not supported by WireGuard, as all of this is happening = inside > the kernel. Maybe a note could be useful here? Switched to "This can offload validation or occur transparently to the = application." >=20 > "Source Address Validation" - It is a little unclear why TCP based = protocols > are not listed here. They (implicitly) do source address validation. = Perhaps > the introduction in this paragraph can state this more explicitly. Eg = "for > those protocols that do not use TCP and therefor do not have builtin = source > address validation ......." We clarify here that: "Of the protocols listed above that depend on the transport for message = framing, some do have well-defined mappings for sending their messages = over byte-stream transports like TCP.=E2=80=9D Thanks, Tommy >=20 >=20 >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps --Apple-Mail=_04244C08-F17C-418C-A70D-EF7B04826354 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Paul,

    Thanks for the review! You can find an updated version of the = document here:

    https://ietf-tapswg.github.io/draft-ietf-taps-transport-securit= y/draft-ietf-taps-transport-security.html

    Responses inline.


    On Apr 15, 2020, at 8:48 AM, = Paul Wouters via Datatracker <noreply@ietf.org> wrote:

    Reviewer: Paul Wouters
    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.

    The summary of the review is Has = Nits

    Compared to my last review (-09) a lot = of text has been removed, reducing the
    technical details = and giving a briefer (but arguably cleaner) overview.

    I do still have a personal preference of dropping CurveCP and = MinimalT as I
    don't really think these are anything but = abandoned research items. I have
    never seen or heard of = these being deployed. I would be more tempted to list
    openconnect (draft-mavrogiannopoulos-openconnect) which = actually does see quite
    some deployment. If the intent is = really to show different kind of API's, than
    there are = other esoteric examples that could be included, such as
    Off-The-Record(OTR) or Signal, which are mostly encrypted = chat programs, but
    with the ability to generate session = keys for encrypted bulk transport (eg for
    video/audio or = file transfer)

    We discussed for Signal and OTR. Our sense was that = these protocols are more asynchronous application-layer protocols that = are akin to MLS, that can be more independent from a transport layer.

    Section 5.1

    = "Session Cache Management (CM):" which does not include IKEv2/IPsec, = even
    though it does have session resumption (RFC 5723). I = guess this is because the
    section limits itself to "the = application" that can restart the session. But
    for = IKEv2/IPsec the same could be said. An application that after a long = idle
    period sends a packet, triggers a kernel ACQUIRE, = which triggers an IKEv2
    session resumption. WireGuard = does not have this capability as there are no
    API/hooks = for packet trigger tunnel events (AFAIK)

    Indeed,= this refers to an explicit interface for cache = management.


    "Pre-Shared = Key Import (PSKI):" lists WireGuard, but AFAIK it does not support
    PSK based authentication - only public key based = authentication.

    We = discussed that WireGuard uses the IKpsk2 Noise pattern (see https://www.wireguard.com/protocol/, = and https://noiseexplorer.com/patterns/IKpsk2/), in which a = responder uses its PSK to additionally authenticate a = connection.

    While I
    understand the IKEv2 = entry (PSKs are used for authentication of peers), I am
    not = sure the ESP entry should be here. ESP does not "authenticate peers",
    unless you call "being able to decrypt and authenticate = packets" as an instance
    of "authenticating peer"

    We=E2=80= =99ve changed the reference to be IPsec as a unit for IKEv2 + ESP in = these lists.


    Section 5.2

    This states "This can call into the application to offload = validation.".  This
    "can" is only not supported by = WireGuard, as all of this is happening inside
    the kernel. = Maybe a note could be useful here?

    Switched = to "This can offload validation or occur transparently to the = application."

    "Source Address Validation" - = It is a little unclear why TCP based protocols
    are not = listed here. They (implicitly) do source address validation. Perhaps
    the introduction in this paragraph can state this more = explicitly. Eg "for
    those protocols that do not use TCP = and therefor do not have builtin source
    address validation = ......."

    We clarify here that:

    "Of the protocols listed above that depend on the = transport for message framing, some do have well-defined mappings for = sending their messages over byte-stream transports like = TCP.=E2=80=9D

    Thanks,
    Tommy



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

    = --Apple-Mail=_04244C08-F17C-418C-A70D-EF7B04826354-- From nobody Wed Apr 22 11:07:53 2020 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 C3F723A11DF; Wed, 22 Apr 2020 11:07:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 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, DKIM_VALID_EF=-0.1, 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=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 OyQbhzzth6TQ; Wed, 22 Apr 2020 11:07:38 -0700 (PDT) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2062.outbound.protection.outlook.com [40.107.20.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 718AF3A11DE; Wed, 22 Apr 2020 11:07:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=e6CGeFjcI3/22JWN0hL3BO1AlX4DpO35pfSFckSQCthc7C8l5B5OybN9TLnCt+MLKe4R/tJEAY/ITgVdqTglaP8h6tdk2sKL3nUjFxhNBpWs88J3VfV4+jPmB2SCFl37HWRczq4qQ+oBHDefvAcVcL8+GxtDkjrbAnnXfNLzT724F0VZu1q0pmwkjYcGXF2FvzcpUYjm40MCpS1rKlZuyz9R+aPY3daNvk1NBPKEawpNSRJsrg/af0FxZjAx+1n04MjqhVZRixUPQDNlbN/hsfSgEw1Ig7jBdnGKsNdZ635tGQEPHUk3v94nKdPkM897AfeP0hgdAeWDdVfUvc5l2Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=cFdCV3/9CrS8JBpOXcmkBUB2iTAc+3AIYG9fesA+JW4=; b=gOctTIkq8IdMEeIhGtrqsG7dpcvVek2uyvhHmCuMyv89fBNItTO0TDYVVMJ5fxejfcqtHmtlZOQqMx5X15LzPnBEzitI+OK054eNikmFHQo36zWu0zmV7ojeXxVCOoFovcQo76ortHAuQ7lZnrq+yOK4R1q7c25rJHEvrfllHFPoN9p6V/gaSFT1XkxfFndsT73gg/ndW5TFowswXfQYnVE3DNPpc4DVV4+MnrOZzRMtfA9H1QkLCstnuoGqNWz4oeU1W57IMxAF3lPaLamLVTVHKs5/AayPNeUZ+uYz2+SQa6sFJRLFm0VTCaokRLu7x1HKeR7bsdS47NYkQmdWZA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none 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=cFdCV3/9CrS8JBpOXcmkBUB2iTAc+3AIYG9fesA+JW4=; b=k7Dqy9geJu3hUYg8TZ1Y/CkCP9nuyZvMkGgk1kBBA6pqkNspTYGgdJyXHTZasHuPL4d4gOSZxfk+BE6g1HvHlt6xs06t8XnGf9wQuY88jwdmXrQM82NnYG1Nh3SbO3WhwO6PfNj9VHabeqUzzl8DpbbPlEt21WgY6zq1uiaxlYA= Received: from HE1PR0702MB3772.eurprd07.prod.outlook.com (2603:10a6:7:8e::14) by HE1PR0702MB3756.eurprd07.prod.outlook.com (2603:10a6:7:8e::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.10; Wed, 22 Apr 2020 18:07:34 +0000 Received: from HE1PR0702MB3772.eurprd07.prod.outlook.com ([fe80::ec28:2c21:6d78:917a]) by HE1PR0702MB3772.eurprd07.prod.outlook.com ([fe80::ec28:2c21:6d78:917a%2]) with mapi id 15.20.2937.012; Wed, 22 Apr 2020 18:07:34 +0000 From: Magnus Westerlund To: "lars@eggert.org" CC: "stephen.farrell@cs.tcd.ie" , "tsvwg@ietf.org" , "draft-ietf-tsvwg-datagram-plpmtud.all@ietf.org" , "secdir@ietf.org" , "quic@ietf.org" Thread-Topic: Secdir telechat review of draft-ietf-tsvwg-datagram-plpmtud-19 Thread-Index: AQHWCsWYw97Id1VLoEyzmiYtqjx1D6iCFzQAgAMPNwCAAGXeAA== Date: Wed, 22 Apr 2020 18:07:34 +0000 Message-ID: References: <158603467562.27263.2918619786629536861@ietfa.amsl.com> <5CA9F5F9-67F9-4739-9991-E4C9E5F760B8@eggert.org> In-Reply-To: <5CA9F5F9-67F9-4739-9991-E4C9E5F760B8@eggert.org> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Evolution 3.28.5-0ubuntu0.18.04.2 authentication-results: spf=none (sender IP is ) smtp.mailfrom=magnus.westerlund@ericsson.com; x-originating-ip: [98.128.243.69] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d97b6734-1c41-45c6-2012-08d7e6e80899 x-ms-traffictypediagnostic: HE1PR0702MB3756: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 03818C953D x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0702MB3772.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(346002)(39860400002)(376002)(136003)(366004)(396003)(478600001)(36756003)(71200400001)(86362001)(6512007)(4001150100001)(99936003)(2906002)(4326008)(2616005)(186003)(54906003)(44832011)(6916009)(6486002)(76116006)(316002)(66616009)(81156014)(6506007)(66446008)(53546011)(66946007)(66556008)(26005)(8676002)(5660300002)(8936002)(64756008)(66476007)(99106002); DIR:OUT; SFP:1101; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 8fdUzf8hv8tVZzRX8t14pKN4iD1Vk0wGg/Nk6eMkEALg9cvYFZqbZatBpwU9vddtAUbqmkiqST3hSzwVSRl2lit5CZQPTs+NCVGKOrumeBXxwqE2OIk0kcwjmycX2NuGtZcE/yE1nU0Dd0OKqTYIX1z03CS/GKRN4o8P3dQDnjsMyZapVKCXy+Qr4tMvNwMBda0fM6uqeLeAqZ48Uqmc62b/odyRG28Hb8KShogSnEsuiw+bUerUJssf9/pXgRKwQMYtN9x7PQpu8cDrV0P9jhY2OKThOTA0pY+9HELgHl931jWJhjmTrIQMdlokOV9ylZU/AXLL4VvSrGVLhzmI3lOIpg1D519tmSWz67MV97qoII+uIdo2AUCXEqyC7fmqhSoQC/SXKCAUU/30o2ZchUNsoJu9DJ0eD8by5TnuHrpiVB29wXTvTPMA9udw4jeDhaWvNqn87XGQg7XvhmtR8zZygUer49sixPrlrk9uPcqpJa7L0bM8Gfv/K0vgsedV x-ms-exchange-antispam-messagedata: A8FZM/qBWHuQCSqI5lpzh2HK0YMXjXLtjHfWhIJfRX0DeOr8Pv5w5FCquFYgQLLV8OOBbIPbNl6vkumX890elcFoieoTOeOjBxe7zZfe1+swOgsIT1+2u8lkCy63zDyv6PJiTBS2m28MYf4nzbdmoAreD7JTpDVDvPXWe92Ohr6GSSe2AN3S39cOvHHztMmP0uRQfZyFZgz/iYhD1cHyAL7etLn8EpNiS3xLKn2fVWx6bUVf/J+xUl8JsTVQEujpN9LIRhOuv6kBHj7BRZ5Rcanv2/5qY8zM10Pf7LVcD4ByyyPn/4MKmRYCMLDbk6yqnkl0pzfpoZTbIoucqrgrF/ZGG3Cu4Ra2vh3TjXBXCstAtAhd7c4niHY3iaqwCh+R2H53XLeHg6Zkzb/o2RG1Ee8FpxMFxDlYUbvOSVMCJTezXp3lYK1tJA25A4YubA7aO8srePg1ksyL2WQpw9CtX32VTKFwXoM6HwFxYz3O+gmTLUMTJIlcxbo7UtQ1jJcga0OPO4qVIsczoyBsz70J/tPmAxYh5BQN1w5UtNZtz2UekPZPODyOrgC0gyyoJt44i11ExDYkUxm1h93x44rA9W/jgPEyflGSJkIvBEKZrZlL0XwX5SzVDB1lazXpyC3D+UAE3AjFUo8MbcOYME1zX79VL6zsxlUYUanGzDEJfIFvhSnJRvYcu2c4PVOGlKCiPu4EM/u/17g5AtU8qfyH3NKP0PCxvfEMIzXtmiYVHWkbFLueD8ebUrPGtFRp4u+Z7XAhv8YWejVpYdjF8gUZ5kcmXTAaF9mE28Ji5asSHe0= x-ms-exchange-transport-forked: True Content-Type: multipart/signed; micalg="sha-256"; protocol="application/x-pkcs7-signature"; boundary="=-ETEJ6o+bdxvaPjGmtwRT" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: d97b6734-1c41-45c6-2012-08d7e6e80899 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Apr 2020 18:07:34.4450 (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-CrossTenant-userprincipalname: eflUHc6ouzX1yXnILFFdlI5PUIcXyIW1u1fvoBv3Ap/IlW5HSsXAfb7cLllnnfl0WiPiCPYJSqcbqVHATHTdQJe5f7KTJgTnPANIqt6DQvQ= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0702MB3756 Archived-At: Subject: Re: [secdir] Secdir telechat review of draft-ietf-tsvwg-datagram-plpmtud-19 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, 22 Apr 2020 18:07:42 -0000 --=-ETEJ6o+bdxvaPjGmtwRT Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 2020-04-22 at 15:03 +0300, Lars Eggert wrote: > Hi, >=20 > On 2020-4-20, at 16:19, Magnus Westerlund < > magnus.westerlund=3D40ericsson.com@dmarc.ietf.org> wrote: > > You do have a point here. Considering that QUIC transport is not ready,= I > > think > > the alternative to have this document hang in RFC-editors queue is to > > actually > > move Section 6.3 into draft-ietf-quic-transport. > >=20 > > QUIC WG what do you think of that solution? It would allow draft-ietf-t= svwg- > > datagram-plpmtud to be published without delays. >=20 > the chairs discussed this for a bit, and we're a bit hesitant to go this > route. >=20 > IIRC, if both docs have mutual normative references to one another, they = get > clustered and published together anyway. Do we need more? >=20 > If we actually want to WGLC them together, TSVWG can maybe park -plpmtud = for a > bit? So, this is basically the last issue before approving the document as a pro= posed standard. It has already been through IETF last call, IESG Evaluation. This discussion is soley due to a late review.=20 The document do contain specification for other transport protocols I think there are some point in getting it published. However, as long as QUIC WG i= s not gone delay to long I personally can have it hanging in the RFC-editor queue= . I am not expecting any significant change to the QUIC parts (PING and PADDING= (not details) referenced from Section 6.3 in datagram-plpmtud draft.=20 Cheers Magnus Westerlund=20 ---------------------------------------------------------------------- Networks, Ericsson Research ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Torshamnsgatan 23 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- --=-ETEJ6o+bdxvaPjGmtwRT Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCEtww ggYHMIID76ADAgECAhALRm3NcHtuMGWutmt5cXntMA0GCSqGSIb3DQEBCwUAMEcxCzAJBgNVBAYT AlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBD QSB2MzAeFw0xNzEyMTUwNzIyMjNaFw0yMDEyMTUwNzIyMjJaMHAxETAPBgNVBAoMCEVyaWNzc29u MRowGAYDVQQDDBFNYWdudXMgV2VzdGVybHVuZDEtMCsGCSqGSIb3DQEJARYebWFnbnVzLndlc3Rl cmx1bmRAZXJpY3Nzb24uY29tMRAwDgYDVQQFEwdlcmFtc3dkMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEAsKlHZvB3TsmLEDtPSiFFKAh73S2wApt+laqg5eXTqonqnzT9ykEGL2dx9mBT +2WZiIKxo4w2sisVl3EEYTqXTkctpur7cN29gLC8F3tJHGI2sUVpO9AwpVrN+UuHEVetHt7hdxW9 uYd0LJJ8TP6/wGkIfAFaZxlZUn79O2eHElfih1iVIiTZXLcEe1rBJtzhUNRHWgOm2vQlDJ4sCpig GFq5w+XSRviEQMkQZRvw1CQmb35QS/C/T36ogzIRHDuAdkoSaiUOY/S2dLp4HkwvOOg+tADpaHkr bdmdnjKGrYSnJigmxw14pJugxL/Vb2EeVcgpAfVVst7Lm4POPRI8+wIDAQABo4IBxDCCAcAwSAYD VR0fBEEwPzA9oDugOYY3aHR0cDovL2NybC50cnVzdC50ZWxpYS5jb20vZXJpY3Nzb25ubGluZGl2 aWR1YWxjYXYzLmNybDCBggYIKwYBBQUHAQEEdjB0MCgGCCsGAQUFBzABhhxodHRwOi8vb2NzcDIu dHJ1c3QudGVsaWEuY29tMEgGCCsGAQUFBzAChjxodHRwOi8vY2EudHJ1c3QudGVsaWFzb25lcmEu Y29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5jZXIwKQYDVR0RBCIwIIEebWFnbnVzLndlc3Rl cmx1bmRAZXJpY3Nzb24uY29tMFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQESMDowOAYIKwYBBQUH AgEWLGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMB0GA1UdJQQW MBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4EFgQU5ivuhpU51W4UhBDBWwf8XsU837YwHwYD VR0jBBgwFoAUHHsZnpecdqwgPdjc45Fq49stplMwDgYDVR0PAQH/BAQDAgWgMA0GCSqGSIb3DQEB CwUAA4ICAQBn0FKukg00UN/c/ESpxSIaYTrsd8liHHMu5rLpOBNOacpGNBMGNgUDDt4QihhoQR3c vhYXCrAM59NTvw0HNlgqHZoEeVY7YnJJYnJXDCLUfkK5Dn28E3QrzykkF6giUOXDyF9mhWYbSAkJ yx0Yj0Xc8en3wYNyoFYEqjlKtZrdV0pcgFzEeXVLS8DWrzSy7+KfUtDOEiM6H3zO3nsq++KBmsOi SKkWn4oYERZg5KElEAHis9av+3KIaEPnOAt8QRWRpFfGZ4d89F16qFvElup5n7l864FqxnC2friD o4hLQY6ENaOaYIihXhbl2UYxAGDk89aJm/S5pYyq7wzm+KK3IcUl60rmc8SJlt6QXKw0wXEOE1Mu bauYKMsad2s8jD+rEkXp+agTRl+sezWaRxHBpxuUKDd6MhwDig3SZi1qP7D/Ds4V+JLIjjUJc25l 9tvMGC9+lqI0P+vMI3Zyrou0NNfb55uLQaq18O+7BZ8Kv7jvFdxYyUgbxQ0SPEiyhylcLHAmJeLC QaiZHmCREBkCLKSf0O4lE2TrVzdOD38wjzuQ27U3UddVCD9EQ3tF7o6EVhpxJJUlB6xe/2UWwy4Z la71dKLUhakdVrN5abzxqFWvzOAT9nBa2HzYVBtpbcu6KGh72YJ+M79fa9iIkcQCgUnw3gIAeWd/ /n4YbY2QhDCCBgcwggPvoAMCAQICEAtGbc1we24wZa62a3lxee0wDQYJKoZIhvcNAQELBQAwRzEL MAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRp dmlkdWFsIENBIHYzMB4XDTE3MTIxNTA3MjIyM1oXDTIwMTIxNTA3MjIyMlowcDERMA8GA1UECgwI RXJpY3Nzb24xGjAYBgNVBAMMEU1hZ251cyBXZXN0ZXJsdW5kMS0wKwYJKoZIhvcNAQkBFh5tYWdu dXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20xEDAOBgNVBAUTB2VyYW1zd2QwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCwqUdm8HdOyYsQO09KIUUoCHvdLbACm36VqqDl5dOqieqfNP3K QQYvZ3H2YFP7ZZmIgrGjjDayKxWXcQRhOpdORy2m6vtw3b2AsLwXe0kcYjaxRWk70DClWs35S4cR V60e3uF3Fb25h3QsknxM/r/AaQh8AVpnGVlSfv07Z4cSV+KHWJUiJNlctwR7WsEm3OFQ1EdaA6ba 9CUMniwKmKAYWrnD5dJG+IRAyRBlG/DUJCZvflBL8L9PfqiDMhEcO4B2ShJqJQ5j9LZ0ungeTC84 6D60AOloeStt2Z2eMoathKcmKCbHDXikm6DEv9VvYR5VyCkB9VWy3subg849Ejz7AgMBAAGjggHE MIIBwDBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vY3JsLnRydXN0LnRlbGlhLmNvbS9lcmljc3Nv bm5saW5kaXZpZHVhbGNhdjMuY3JsMIGCBggrBgEFBQcBAQR2MHQwKAYIKwYBBQUHMAGGHGh0dHA6 Ly9vY3NwMi50cnVzdC50ZWxpYS5jb20wSAYIKwYBBQUHMAKGPGh0dHA6Ly9jYS50cnVzdC50ZWxp YXNvbmVyYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYzLmNlcjApBgNVHREEIjAggR5tYWdu dXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20wVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBARIwOjA4 BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMw HQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMB0GA1UdDgQWBBTmK+6GlTnVbhSEEMFbB/xe xTzftjAfBgNVHSMEGDAWgBQcexmel5x2rCA92NzjkWrj2y2mUzAOBgNVHQ8BAf8EBAMCBaAwDQYJ KoZIhvcNAQELBQADggIBAGfQUq6SDTRQ39z8RKnFIhphOux3yWIccy7msuk4E05pykY0EwY2BQMO 3hCKGGhBHdy+FhcKsAzn01O/DQc2WCodmgR5VjtickliclcMItR+QrkOfbwTdCvPKSQXqCJQ5cPI X2aFZhtICQnLHRiPRdzx6ffBg3KgVgSqOUq1mt1XSlyAXMR5dUtLwNavNLLv4p9S0M4SIzoffM7e eyr74oGaw6JIqRafihgRFmDkoSUQAeKz1q/7cohoQ+c4C3xBFZGkV8Znh3z0XXqoW8SW6nmfuXzr gWrGcLZ+uIOjiEtBjoQ1o5pgiKFeFuXZRjEAYOTz1omb9LmljKrvDOb4orchxSXrSuZzxImW3pBc rDTBcQ4TUy5tq5goyxp3azyMP6sSRen5qBNGX6x7NZpHEcGnG5QoN3oyHAOKDdJmLWo/sP8OzhX4 ksiONQlzbmX228wYL36WojQ/68wjdnKui7Q019vnm4tBqrXw77sFnwq/uO8V3FjJSBvFDRI8SLKH KVwscCYl4sJBqJkeYJEQGQIspJ/Q7iUTZOtXN04PfzCPO5DbtTdR11UIP0RDe0XujoRWGnEklSUH rF7/ZRbDLhmVrvV0otSFqR1Ws3lpvPGoVa/M4BP2cFrYfNhUG2lty7ooaHvZgn4zv19r2IiRxAKB SfDeAgB5Z3/+fhhtjZCEMIIGwjCCBKqgAwIBAgIQU7h+g+GcmSiTsJtJHOy46zANBgkqhkiG9w0B AQsFADA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEfMB0GA1UEAwwWVGVsaWFTb25lcmEgUm9vdCBD QSB2MTAeFw0xNTEwMjcxMjE2NDZaFw0yNTEwMjcxMjE2NDZaMEcxCzAJBgNVBAYTAlNFMREwDwYD VQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MzCCAiIw DQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAOzy3wAAuFDyp7vYVLfGk/fjwao71MNGNLSzzl5D tjQtMtl2ZLPZyX6ViqzTN9JOb7uZ6KxuGSpReQvt8XOh7iIhkKH9W5hRpbjTsJmUMJd6zifhOpNK 6iSU3q44+FjsQL1lVtcguUuFG6aZN0N3GFVbgt6jRrASF8t/3wy9bHPAIfMyPybpg6Y2PH5/1Nwk TepoDSmK69LGV+lV2IK6U9OWayZXZFIFIDCoGyFlhFxAEgN+qZ2+Rqg/0TM0oCHvKO2ELSGmAdnJ kwizR42ji/Y9SYTSuG75mzSe6OfCGWM8Db/xvy/20aLEPXNu1PvOgzY63WZ6cmkWnjMlVJ90pWC2 haqDm3Yf8TRdjUvAl7Pz1bTuexwShzIGakL7MkCYrEqHMRaojI/VStloQgW76E76zQ2byw5QxrhO UbisBSKRzlTlOZQgYFFAbG6ViF8DOpJh/ygtQwuTLUM5r15G7eynQV1AMTNCWcX+HUvgArUw6RfW 9L58uA68GjktFTV8s9RlDsUqsNcLqeXaV28S2WMday0YGaq/bloS8AD7KuumUKH+Ri9IGO9mJvP0 5tvDHjKpLvv80c3WLJnJU/aznYHYEt2+jjKHOTqdGTxL/zMdpRSQFSuu+KM8NoYrkU1VJqKga+QL sgqKghMp99gu1P1e6KsqseWHdXORrMbjqkBXAgMBAAGjggG4MIIBtDCBigYIKwYBBQUHAQEEfjB8 MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50cnVzdC50ZWxpYXNvbmVyYS5jb20wSwYIKwYBBQUH MAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJv b3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/AgEAMFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQEC MDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20v Q1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0dHA6Ly9jcmwtMy50cnVzdC50ZWxpYXNvbmVyYS5jb20v dGVsaWFzb25lcmFyb290Y2F2MS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA4G A1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUHHsZnpecdqwgPdjc45Fq49stplMwHwYDVR0jBBgwFoAU 8I9ZOACz9Y+algzV6/p7qhfoExIwDQYJKoZIhvcNAQELBQADggIBAFBYa/HVjDu0LqtXQ8iMp8PL Fpqchf41ksQY6R1AsoZbaBUu0NQlAQ9GzlC1pmI5s0cJnuaZI0xV6TiWS3/R2p9UgW61XD9CTIUb AL31mY3BdJf3P46gzKgQEca/DlFjq9GVmuPS4q90BLNgvgoxoHubc3C6s0OaY1sbnay5EhnvrAE4 Q511FlxmJPLnRmQGpieeXa3cPegFfY1kJDKyyFRypF1RuRLXcdMIgKEy5NX1bS3M9dQ4mgmUmVT2 d33UiKSEYQ6s/B+LFaaz4LywXSv2o3W4kbHoQs86IWst821ww0wxsCpEfClIvF7fBw2QkbG/1Pwu zAuLVStEhDzkAqOrMGctKyNEaBsyAn7Eq2eCa8QDXnkmagp9QPsNFs/oqnXj9j1cVtH9a4OPzhtg 0pd7gd0NzU/5QxibXqbYvouQgihGXHQDmaL4ruN7C4arMUqRo82YnREsKL7h3j/jtmzcMLc9Q07F 04QQd/iSR1Y5pIi6PdNBiE2/4uyAXS6KOIGZrPbNQUNrZtwiQpqQNl8AUzgegfPwrYFlFocpaF3d 1m5r+2VKKqiRQVfYPGYeZnWfkcz06JoAhc/9mjbHXSP9hvWYzeLRuoZqHGUdjOX9DIQb926OneV7 C5WMIjSY8ORkamG/HKqngmjypL3gSc6oG/E6B+1i6Ds5j0Qpj5aQMYICzTCCAskCAQEwWzBHMQsw CQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2 aWR1YWwgQ0EgdjMCEAtGbc1we24wZa62a3lxee0wDQYJYIZIAWUDBAIBBQCgggFDMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTIwMDQyMjE4MDc0MlowLwYJKoZIhvcN AQkEMSIEIIlXAVbXwZCouhFDbrX7SI12Gc/fF+ZzHyqasTMbFOdcMGoGCSsGAQQBgjcQBDFdMFsw RzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJ bmRpdmlkdWFsIENBIHYzAhALRm3NcHtuMGWutmt5cXntMGwGCyqGSIb3DQEJEAILMV2gWzBHMQsw CQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2 aWR1YWwgQ0EgdjMCEAtGbc1we24wZa62a3lxee0wDQYJKoZIhvcNAQEBBQAEggEAlAwnDuotVlhu l6HufDbQXf0K3XCvZcH9+Q7Hri5HSNKOYIizo5nsEXjy4EUJh+GQkmTFYgGrNsI48Qghxoo0ozhH igT08jsU+Zk2AlO5kB+GkOm1WAfiNEt25CQWcNmCfe51ncO2C/ZEz93wacp2LGG7HyfKpZ0jW3SW 22tB+n+6RIllATrca959D95pYVjF5DdygY13r0s2WHG0dDfE0WaMIVTOLbACL1o59yoMpwIqw5ia 1ogXrMGXVxaEgk/VVvHbXE0QMqC4lSKyRDm6ZjVUXN0OjMzFZq24caXjSutfE3karbR4bNJji5k5 nXSaXZ8Rw7qi27jt+FFWOQOheAAAAAAAAA== --=-ETEJ6o+bdxvaPjGmtwRT-- From nobody Wed Apr 22 12:14:03 2020 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 8918D3A0B51; Wed, 22 Apr 2020 12:13:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.921 X-Spam-Level: X-Spam-Status: No, score=-2.921 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, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.82, 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=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 vzu_d_UTJ0Xn; Wed, 22 Apr 2020 12:13:55 -0700 (PDT) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2071.outbound.protection.outlook.com [40.107.20.71]) (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 EC7E63A0B59; Wed, 22 Apr 2020 12:13:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=OaTx3SGzNW8fdPZ03gDN0eBT40NjY1AQEisGvIK/mI9yAyo8yA9Xnl3fG4X4di0dH7lRnECSW+ufnYIyoud6GqsBMCBwK+jfHY4rnWbShJrLSnMaj6aaPPhkwKeBxa/KQGcPqXFaVu6syYWtxICRxcG+/KCP/tcf/aDUG8Yr4OvabJPSF7B4cLEqyEnDDZ83PFCbe0OXN9i5dH//+9zntJ6cedBHmUAK/hgtIkMhrkg8XGDdZwbbQih/UMnziQJ+qM1wN3OpFA2hSfC3k7M9FpnIQjOHOQ2GcCs6eotw5L4eerhioe+r43yBzZ6/Iwo0xSEvnKWWK3KOiI27u6SSjw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=EKQhvaEvDJ/30fyU+wMVyB0Xi7jgbZRuazjtABJAY6Y=; b=nj2lQsiftmGRLuUymUgLx3iom8l/QXimEN409ua96ZRPkxCyLodVuCTsks+C0vYqtOtjj/3o6EavmLFOeOD/0L1oexeU1jIxVzL0Bf+/4pa35jtU6tCyIuVBvUAUP2KEWoI65g4n214GanEBTyGSzEGOmOb0BYMGU4tltbZYReNZqtwd4NxU6WhO8ItC7keZPmprEH+NuSV7Mxz8lurv0QP+e78YsTaWj32iMbqMNIRPSpZ+Z4IKVn0gknlyQIIdCrXDOWzlVbd0L028DHkNsJobGIPkGI2J+5nhzQOqypRPxhz9CvMwX4tmjnzLtxV2Ii5egNe1S7bfAnfmnskfeQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none 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=EKQhvaEvDJ/30fyU+wMVyB0Xi7jgbZRuazjtABJAY6Y=; b=n4/fcAvjOYXtF16iIDhYAucaod/HvHw+6AhJfI01H68pSveV/KBXlBTqusJ42RDaQdeHVOlMFJlHqFAPXxET6tLeiVaObENcAlJ6teKYZeAZzw8C1/c1hBJTtWUXSiwXd/Y2rvENXBzPqd44Vhf/KLRpkkpZVt1W+8kJfrRn0EU= Received: from HE1PR0702MB3772.eurprd07.prod.outlook.com (2603:10a6:7:8e::14) by HE1PR0702MB3690.eurprd07.prod.outlook.com (2603:10a6:7:7e::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.11; Wed, 22 Apr 2020 19:13:52 +0000 Received: from HE1PR0702MB3772.eurprd07.prod.outlook.com ([fe80::ec28:2c21:6d78:917a]) by HE1PR0702MB3772.eurprd07.prod.outlook.com ([fe80::ec28:2c21:6d78:917a%2]) with mapi id 15.20.2937.012; Wed, 22 Apr 2020 19:13:52 +0000 From: Magnus Westerlund To: Magnus Westerlund , "lars@eggert.org" CC: "stephen.farrell@cs.tcd.ie" , "tsvwg@ietf.org" , "draft-ietf-tsvwg-datagram-plpmtud.all@ietf.org" , "secdir@ietf.org" , "quic@ietf.org" Thread-Topic: Secdir telechat review of draft-ietf-tsvwg-datagram-plpmtud-19 Thread-Index: AQHWCsWYw97Id1VLoEyzmiYtqjx1D6iCFzQAgAMPNwCAAGXeAIAAEcOg Date: Wed, 22 Apr 2020 19:13:52 +0000 Message-ID: References: <158603467562.27263.2918619786629536861@ietfa.amsl.com> <5CA9F5F9-67F9-4739-9991-E4C9E5F760B8@eggert.org> In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=magnus.westerlund@ericsson.com; x-originating-ip: [192.176.1.105] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 93680f91-ecfd-4f41-cfcb-08d7e6f14ba0 x-ms-traffictypediagnostic: HE1PR0702MB3690:|HE1PR0702MB3690: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 03818C953D x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0702MB3772.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(376002)(396003)(136003)(366004)(346002)(39860400002)(6506007)(53546011)(316002)(66476007)(66616009)(64756008)(66556008)(5660300002)(8676002)(66946007)(66446008)(81156014)(8936002)(4326008)(7696005)(71200400001)(99936003)(186003)(110136005)(54906003)(76116006)(55016002)(9686003)(478600001)(44832011)(4001150100001)(26005)(2906002)(52536014)(86362001)(33656002); DIR:OUT; SFP:1101; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: j7MZAV98UGpc0zYRA9oziqm8HUhIONUKKdpQ4tU5IM4a4xZm1z4+BBljyM423hWtXmMr8CpsZotN7pVSVxfku4MvBmagRKnG0c6MdCuF3VSii2oezs/B4E8qGwu3EodRippK6m3RIFxS+ogRrhKXmkNSp2knd5F6Nfbnj+JwnIe+PhLWpML1ivntXDVT0sLM160xeu3V7fhxMYdpQKq8lRvEF4DKqQ4KbFttWwdoBVeqAnla6HnOap92ddPeafOwpWaxRhKfzh8sB64mZ7+/gyxbz+jmSXuppIJWyqUxNPyV2stjBtUg+QG1W3Xet+nogy3g9AamOMTwkDK6mNnWPiECxOdXwtbf1VYs6yAqdiGAnT+Hg5g3MOgSF3vvHJ0P4gtoBIR99ES5AqIgvRbkTFYmoBvUQGIz0oliBcmXAsSQ89pvUzUB/g6SuciSP1rl x-ms-exchange-antispam-messagedata: t9Aw05pZ/nQ6D06Q8uzx3l74SPjZJIpve8pxzelCfc6WP7aVdliHdl+W19XN9d9RSpSlM+gjqoKPUpFEAFRbZjqHO1DJrvqc672wEN6eyTNrShbQHpvPfQKOqCJM8jZBXAvuquTBXHZw066n22a8sxny4rlB4dkzbC9d2JIHsGPTekar0Agld34YKH3lNIzPtMWar3puOXoJaSGczJjcedIq2OjS4Va5PZCvo2VNm7QuP5m1TUoWjfO/jEG7U4YxDumnsPfbmRcmpVh6xbjK0QM1smHVe2zv0iGpomtZMs0vV6zMDq+NkBbKOQxJgzVzFgGw/08MYJ1Wqwp+xh2wIIftSYk4gKxzm5KXCqtRftjgI3vmTC1TjLw+fe2dvW/HzoJ2w1AZOMZYs/jUHiy9Z4amfy+ZmVK+nG5Qtz2qgZ0zzLad5fy9BAVHV0h7z0zhrNDyPNDgqTuaB6dev9YuqIbXL/TNId1NFdwn/ZzRXiVHOYxdLSHrCQNfi24/b7nUjKIbr7LUQZdjByE61FExl63RNcmKPLYUDO2XPlr1DYDhEYXLzTgVw1XAA09JhZczQ5yxBED/mUxxCz/TpFWHUv4cK0hRLZsMZNundlexXH6pL3K7SABzb9mA3eZCbHlvzg2IqS5drvo8EeMQjlRt+/wWBVQWtrGnxGudwzz8KMPvnpx/1ZqdJ6rpJKELSW7+lhqzdB7th46Y1ZEFC3KklAPkGUY2SycqNFVNyoJSvaDRUhX2wSgLNhn5r/WjWzBFIdSmuMg1VlK2K7M2jwl/fj2tKTf4eQSMMd9LW9QiHNw= Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00BF_01D618EA.F15A9E30" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 93680f91-ecfd-4f41-cfcb-08d7e6f14ba0 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Apr 2020 19:13:52.4832 (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-CrossTenant-userprincipalname: KmqhGnJiB+eA7FnBNpL9k2ETyU7pYzHw36prbvYid25QLo3TKO4S566/LWCJ0M8BHy8dQ+CAzesyY/uuhqNASDviQK5UvEmXGflOn5MD6Js= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0702MB3690 Archived-At: Subject: Re: [secdir] Secdir telechat review of draft-ietf-tsvwg-datagram-plpmtud-19 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, 22 Apr 2020 19:13:58 -0000 ------=_NextPart_000_00BF_01D618EA.F15A9E30 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Hi, I need to apologize to Stephen Farrell for my statement that the review was late. The review was not late. It was my failure to ensure to address that particular aspect in the process to take it to the IESG. Which resurfaced due my desire to get the draft updated before approval. Regards Magnus Westerlund > -----Original Message----- > From: Magnus Westerlund > Sent: den 22 april 2020 20:08 > To: lars@eggert.org > Cc: stephen.farrell@cs.tcd.ie; tsvwg@ietf.org; draft-ietf-tsvwg-datagram- > plpmtud.all@ietf.org; secdir@ietf.org; quic@ietf.org > Subject: Re: Secdir telechat review of draft-ietf-tsvwg-datagram-plpmtud-19 > > On Wed, 2020-04-22 at 15:03 +0300, Lars Eggert wrote: > > Hi, > > > > On 2020-4-20, at 16:19, Magnus Westerlund < > > magnus.westerlund=40ericsson.com@dmarc.ietf.org> wrote: > > > You do have a point here. Considering that QUIC transport is not ready, > > > I > > > think > > > the alternative to have this document hang in RFC-editors queue is to > > > actually > > > move Section 6.3 into draft-ietf-quic-transport. > > > > > > QUIC WG what do you think of that solution? It would allow draft-ietf- > tsvwg- > > > datagram-plpmtud to be published without delays. > > > > the chairs discussed this for a bit, and we're a bit hesitant to go this > > route. > > > > IIRC, if both docs have mutual normative references to one another, they > get > > clustered and published together anyway. Do we need more? > > > > If we actually want to WGLC them together, TSVWG can maybe park - > plpmtud for a > > bit? > > So, this is basically the last issue before approving the document as a > proposed > standard. It has already been through IETF last call, IESG Evaluation. This > discussion is soley due to a late review. > > The document do contain specification for other transport protocols I think > there are some point in getting it published. However, as long as QUIC WG is > not > gone delay to long I personally can have it hanging in the RFC-editor queue. > I > am not expecting any significant change to the QUIC parts (PING and > PADDING (not > details) referenced from Section 6.3 in datagram-plpmtud draft. > > > Cheers > > Magnus Westerlund > > > ---------------------------------------------------------------------- > Networks, Ericsson Research > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > Torshamnsgatan 23 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > ------=_NextPart_000_00BF_01D618EA.F15A9E30 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIVdjCCAyAw ggIIoAMCAQICAR0wDQYJKoZIhvcNAQEFBQAwOTELMAkGA1UEBhMCRkkxDzANBgNVBAoTBlNvbmVy YTEZMBcGA1UEAxMQU29uZXJhIENsYXNzMiBDQTAeFw0wMTA0MDYwNzI5NDBaFw0yMTA0MDYwNzI5 NDBaMDkxCzAJBgNVBAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFz czIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCQF0o1ncrwDZbHRPoWN/xIvb1/ gC01O+FvqGepvwMcTYxvMkfVQWikEwTBNQyahEP8XB3/ibPoFxjNkV/7iePqv05dfBsm03V57eaE 41flrSnE9Doo56V7hDZps/1edr2jLZnTkE4jKH0YY/FUOyaddluXQrL/rvBO7N05lU6DBn/nSUDI xQGyVFpmHT38+ek8Cp6BuHDwAYvkI1R8yK74kB4AlnLUVM9hI7zq+50CldG2uXE6aQg/D7ThQseI 9T+YqKe6HOBxce9YV4FQelxrdEYOgwOYw46obvJ2Mm4ng8Jz89wY6LST6nVEawRgIHFXh53zvqCQ Iz2KJOHaIdvDAgMBAAGjMzAxMA8GA1UdEwEB/wQFMAMBAf8wEQYDVR0OBAoECEqgqliE0148MAsG A1UdDwQEAwIBBjANBgkqhkiG9w0BAQUFAAOCAQEAWs6H+RZyFVdLHdmb56ImMOyTZ9/WLdI0r/c4 pc6rFrmrL3w1y6zQD7RMK/yA72uMkV82dvfbsxsZ6vSyEf1hcUS/KLM6Hb+zQ+ifv9wxCHGwnY3W NEcykMZlJPegSnwEc485bxeMcrW9S8h6+HuDwyhOnAnqZz+yZwQbwxTa+OdJJJHQHWr6YTnva+ch dQYH2BK0ISBwQnGB2jyaNr6mWw1qbJofkXv5+e9Cuk5OnswMjZTc2UWcXuxCUGOu9F3EsRLcyjuo Lp0UWgV1t+zXY+K6NbYECJHo2p2c9ma1GKwKplQmNDPSG8HUfxo6jguqMm7b/E8ln9kyx5ZacKzf TDCCBX0wggRloAMCAQICEQCH7S4aKCZKxRmqOuu5DaLLMA0GCSqGSIb3DQEBCwUAMDkxCzAJBgNV BAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFzczIgQ0EwHhcNMTQx MjA1MDgxOTE1WhcNMjEwNDA1MTAyOTAwWjA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEfMB0GA1UE AwwWVGVsaWFTb25lcmEgUm9vdCBDQSB2MTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIB AMK+6yfwIaPzaSZVfp3FVRaRXP3vIb9TgHot0pGMYzHw7CTww6XScnwQbfQ3t+XmfHnqjLWCi65I tqwA3GV17CpNX8GH9SBlK4GoRz6JI5UwFpB/6FcHSOcZrr9FZ7E3GwYq/t75rH2D+1665I+XZ75L jo1kB1c4VWk0Nj0TSO9P4tNmHqTPGrdeNjPUtAa9GAH9d4RQAEX1jF3oI7x+/jXh7VB7qTCNGdMJ jmhnXb88lxhTuylixcpecsHHltTbLaC0H2kD7OriUPEMPPCs81Mt8Bz17Ww5OXOAFshSsCPN4D7c 3TxHoLs1iuKYaIu+5b9y7tL6pe0S7fyYGKkmdtwoSxAgHNN/Fnct7W+A90m7UwW7XWjH1Mh1Fj+J Wov3F0fUTPHSiXk+TT2YqGHeOh7S+F4D4MHJHIzTjU3TlTazN19jY5szFPAtJmtTfImMMsJu7D0h ADnJoWjiUIMusDor8zagrC/kb2HCUQk5PotTubtn2txTuXZZNp1D5SDgPTJghSJRt8czu90VL6R4 pgd7gUY2BIbdeTXHlSw7sKMXNeVzH7RcWe/a6hBle3rQf5+ztCo3O3CLm1u5K7fsslESl1MpWtTw EhDcTwK7EpIvYtQ/aUN8Ddb8WHUBiJ1YFkveupD/RwGJBmr2X7KQarMCpgKIv7NHfirZ1fpoeDVN AgMBAAGjggGAMIIBfDBOBggrBgEFBQcBAQRCMEAwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jYS50cnVz dC50ZWxpYXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY2VyMA8GA1UdEwEB/wQFMAMBAf8wGQYD VR0gBBIwEDAOBgwrBgEEAYIPAgMBAQIwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBTwj1k4ALP1 j5qWDNXr+nuqF+gTEjCBuQYDVR0fBIGxMIGuMG+gbaBrhmlsZGFwOi8vY3JsLTEudHJ1c3QudGVs aWFzb25lcmEuY29tL2NuPVNvbmVyYSUyMENsYXNzMiUyMENBLG89U29uZXJhLGM9Rkk/Y2VydGlm aWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnkwO6A5oDeGNWh0dHA6Ly9jcmwtMi50cnVzdC50ZWxp YXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY3JsMBMGA1UdIwQMMAqACEqgqliE0148MA0GCSqG SIb3DQEBCwUAA4IBAQAQ1elFTM6fGkQ/aRKdkUZicO3Cb9uzBJOpOtFctw+1El0/17lsjoVvJkZB D3KnUobnrriFdAa+7FAN55KLmZeB/3Y2bG0bB4toSyaVHjOQnQY9M0dv8U852w0Q7GwchKfebLUI bh9TMt2hI3Xc6j4knFTBUo7C1WAfO51K4bn1irmX6/Ej2VTgiOFsvOAny28W6enFSEQpSHw60VhN fSttSqTOxyrRR/7kW7Y8yb/3DZDZ/dH6ZCfx/y+BNIv2NuSd85M9HXUzplXXohti4Ql/qeaMn6by Ius6XlMWZZfkdVRvTuk2PkeC7UmAJ2+/DUWOPpawaytMXVfF4Hvxk34NMIIGBzCCA++gAwIBAgIQ C0ZtzXB7bjBlrrZreXF57TANBgkqhkiG9w0BAQsFADBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwI RXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMwHhcNMTcxMjE1 MDcyMjIzWhcNMjAxMjE1MDcyMjIyWjBwMREwDwYDVQQKDAhFcmljc3NvbjEaMBgGA1UEAwwRTWFn bnVzIFdlc3Rlcmx1bmQxLTArBgkqhkiG9w0BCQEWHm1hZ251cy53ZXN0ZXJsdW5kQGVyaWNzc29u LmNvbTEQMA4GA1UEBRMHZXJhbXN3ZDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALCp R2bwd07JixA7T0ohRSgIe90tsAKbfpWqoOXl06qJ6p80/cpBBi9ncfZgU/tlmYiCsaOMNrIrFZdx BGE6l05HLabq+3DdvYCwvBd7SRxiNrFFaTvQMKVazflLhxFXrR7e4XcVvbmHdCySfEz+v8BpCHwB WmcZWVJ+/TtnhxJX4odYlSIk2Vy3BHtawSbc4VDUR1oDptr0JQyeLAqYoBhaucPl0kb4hEDJEGUb 8NQkJm9+UEvwv09+qIMyERw7gHZKEmolDmP0tnS6eB5MLzjoPrQA6Wh5K23ZnZ4yhq2EpyYoJscN eKSboMS/1W9hHlXIKQH1VbLey5uDzj0SPPsCAwEAAaOCAcQwggHAMEgGA1UdHwRBMD8wPaA7oDmG N2h0dHA6Ly9jcmwudHJ1c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5jcmww gYIGCCsGAQUFBwEBBHYwdDAoBggrBgEFBQcwAYYcaHR0cDovL29jc3AyLnRydXN0LnRlbGlhLmNv bTBIBggrBgEFBQcwAoY8aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS9lcmljc3Nvbm5s aW5kaXZpZHVhbGNhdjMuY2VyMCkGA1UdEQQiMCCBHm1hZ251cy53ZXN0ZXJsdW5kQGVyaWNzc29u LmNvbTBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBEjA6MDgGCCsGAQUFBwIBFixodHRwczovL3Jl cG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzAdBgNVHSUEFjAUBggrBgEFBQcDBAYI KwYBBQUHAwIwHQYDVR0OBBYEFOYr7oaVOdVuFIQQwVsH/F7FPN+2MB8GA1UdIwQYMBaAFBx7GZ6X nHasID3Y3OORauPbLaZTMA4GA1UdDwEB/wQEAwIFoDANBgkqhkiG9w0BAQsFAAOCAgEAZ9BSrpIN NFDf3PxEqcUiGmE67HfJYhxzLuay6TgTTmnKRjQTBjYFAw7eEIoYaEEd3L4WFwqwDOfTU78NBzZY Kh2aBHlWO2JySWJyVwwi1H5CuQ59vBN0K88pJBeoIlDlw8hfZoVmG0gJCcsdGI9F3PHp98GDcqBW BKo5SrWa3VdKXIBcxHl1S0vA1q80su/in1LQzhIjOh98zt57KvvigZrDokipFp+KGBEWYOShJRAB 4rPWr/tyiGhD5zgLfEEVkaRXxmeHfPRdeqhbxJbqeZ+5fOuBasZwtn64g6OIS0GOhDWjmmCIoV4W 5dlGMQBg5PPWiZv0uaWMqu8M5viityHFJetK5nPEiZbekFysNMFxDhNTLm2rmCjLGndrPIw/qxJF 6fmoE0ZfrHs1mkcRwacblCg3ejIcA4oN0mYtaj+w/w7OFfiSyI41CXNuZfbbzBgvfpaiND/rzCN2 cq6LtDTX2+ebi0GqtfDvuwWfCr+47xXcWMlIG8UNEjxIsocpXCxwJiXiwkGomR5gkRAZAiykn9Du JRNk61c3Tg9/MI87kNu1N1HXVQg/REN7Re6OhFYacSSVJQesXv9lFsMuGZWu9XSi1IWpHVazeWm8 8ahVr8zgE/ZwWth82FQbaW3Luihoe9mCfjO/X2vYiJHEAoFJ8N4CAHlnf/5+GG2NkIQwggbCMIIE qqADAgECAhBTuH6D4ZyZKJOwm0kc7LjrMA0GCSqGSIb3DQEBCwUAMDcxFDASBgNVBAoMC1RlbGlh U29uZXJhMR8wHQYDVQQDDBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE1MTAyNzEyMTY0NloX DTI1MTAyNzEyMTY0NlowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQD DBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIIC CgKCAgEA7PLfAAC4UPKnu9hUt8aT9+PBqjvUw0Y0tLPOXkO2NC0y2XZks9nJfpWKrNM30k5vu5no rG4ZKlF5C+3xc6HuIiGQof1bmFGluNOwmZQwl3rOJ+E6k0rqJJTerjj4WOxAvWVW1yC5S4Ubppk3 Q3cYVVuC3qNGsBIXy3/fDL1sc8Ah8zI/JumDpjY8fn/U3CRN6mgNKYrr0sZX6VXYgrpT05ZrJldk UgUgMKgbIWWEXEASA36pnb5GqD/RMzSgIe8o7YQtIaYB2cmTCLNHjaOL9j1JhNK4bvmbNJ7o58IZ YzwNv/G/L/bRosQ9c27U+86DNjrdZnpyaRaeMyVUn3SlYLaFqoObdh/xNF2NS8CXs/PVtO57HBKH MgZqQvsyQJisSocxFqiMj9VK2WhCBbvoTvrNDZvLDlDGuE5RuKwFIpHOVOU5lCBgUUBsbpWIXwM6 kmH/KC1DC5MtQzmvXkbt7KdBXUAxM0JZxf4dS+ACtTDpF9b0vny4DrwaOS0VNXyz1GUOxSqw1wup 5dpXbxLZYx1rLRgZqr9uWhLwAPsq66ZQof5GL0gY72Ym8/Tm28MeMqku+/zRzdYsmclT9rOdgdgS 3b6OMoc5Op0ZPEv/Mx2lFJAVK674ozw2hiuRTVUmoqBr5AuyCoqCEyn32C7U/V7oqyqx5Yd1c5Gs xuOqQFcCAwEAAaOCAbgwggG0MIGKBggrBgEFBQcBAQR+MHwwLQYIKwYBBQUHMAGGIWh0dHA6Ly9v Y3NwLnRydXN0LnRlbGlhc29uZXJhLmNvbTBLBggrBgEFBQcwAoY/aHR0cDovL3JlcG9zaXRvcnku dHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY2VyMBIGA1UdEwEB/wQI MAYBAf8CAQAwVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBAQIwOjA4BggrBgEFBQcCARYsaHR0cHM6 Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwSwYDVR0fBEQwQjBAoD6gPIY6 aHR0cDovL2NybC0zLnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNy bDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQW BBQcexmel5x2rCA92NzjkWrj2y2mUzAfBgNVHSMEGDAWgBTwj1k4ALP1j5qWDNXr+nuqF+gTEjAN BgkqhkiG9w0BAQsFAAOCAgEAUFhr8dWMO7Quq1dDyIynw8sWmpyF/jWSxBjpHUCyhltoFS7Q1CUB D0bOULWmYjmzRwme5pkjTFXpOJZLf9Han1SBbrVcP0JMhRsAvfWZjcF0l/c/jqDMqBARxr8OUWOr 0ZWa49Lir3QEs2C+CjGge5tzcLqzQ5pjWxudrLkSGe+sAThDnXUWXGYk8udGZAamJ55drdw96AV9 jWQkMrLIVHKkXVG5Etdx0wiAoTLk1fVtLcz11DiaCZSZVPZ3fdSIpIRhDqz8H4sVprPgvLBdK/aj dbiRsehCzzohay3zbXDDTDGwKkR8KUi8Xt8HDZCRsb/U/C7MC4tVK0SEPOQCo6swZy0rI0RoGzIC fsSrZ4JrxANeeSZqCn1A+w0Wz+iqdeP2PVxW0f1rg4/OG2DSl3uB3Q3NT/lDGJtepti+i5CCKEZc dAOZoviu43sLhqsxSpGjzZidESwovuHeP+O2bNwwtz1DTsXThBB3+JJHVjmkiLo900GITb/i7IBd Loo4gZms9s1BQ2tm3CJCmpA2XwBTOB6B8/CtgWUWhyloXd3Wbmv7ZUoqqJFBV9g8Zh5mdZ+RzPTo mgCFz/2aNsddI/2G9ZjN4tG6hmocZR2M5f0MhBv3bo6d5XsLlYwiNJjw5GRqYb8cqqeCaPKkveBJ zqgb8ToH7WLoOzmPRCmPlpAxggMCMIIC/gIBATBbMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhF cmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MwIQC0ZtzXB7bjBl rrZreXF57TAJBgUrDgMCGgUAoIIBfDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0yMDA0MjIxOTE0MDBaMCMGCSqGSIb3DQEJBDEWBBQAmDD9vCFvB/7VA4SGcbN9+yy5 eDBDBgkqhkiG9w0BCQ8xNjA0MAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D AgIBQDAHBgUrDgMCGjBqBgkrBgEEAYI3EAQxXTBbMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhF cmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MwIQC0ZtzXB7bjBl rrZreXF57TBsBgsqhkiG9w0BCRACCzFdoFswRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNz c29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhALRm3NcHtuMGWutmt5 cXntMA0GCSqGSIb3DQEBAQUABIIBADcA7TepQOzVG5kamoCo3qBrfQq8z4saK1kcPV6Z2a2v5pKn ToRyA3/RYxeFChY9F+t7SVF2mGzdlL2FBXvy+xwCy0PY6Op416xZUKoZDPw4TDNkBInqpUT28815 cnWnODnQvXxxaoTsB+VymYhzCifa55BBEAHzryHAdJStU1q401hNVQQ6cnEO9tG5TSCIDuVSPPEZ qAoISiIObMcwX3IeEvAEDIp4D0JCvo2SejYjqBEe54E1oui81iS8btmv52rdALzHPNcTqrvCRdJv 4zFzrKiLIkkDjjFp4/lKA1ukKCKWXIaWXQwfYymC8TIdHF90k5RXCBJu/2Np6ahaUZcAAAAAAAA= ------=_NextPart_000_00BF_01D618EA.F15A9E30-- From nobody Wed Apr 22 19:11:21 2020 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 37DF73A10F0; Wed, 22 Apr 2020 19:10:47 -0700 (PDT) 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, 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 w1Y4IBsP7BmB; Wed, 22 Apr 2020 19:10:45 -0700 (PDT) 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 DC7D23A10F2; Wed, 22 Apr 2020 19:10:44 -0700 (PDT) Received: from lhreml702-chm.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id EE2F95C238F15FD511FB; Thu, 23 Apr 2020 03:10:40 +0100 (IST) Received: from lhreml702-chm.china.huawei.com (10.201.108.51) by lhreml702-chm.china.huawei.com (10.201.108.51) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Thu, 23 Apr 2020 03:10:30 +0100 Received: from DGGEML423-HUB.china.huawei.com (10.1.199.40) by lhreml702-chm.china.huawei.com (10.201.108.51) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1913.5 via Frontend Transport; Thu, 23 Apr 2020 03:10:30 +0100 Received: from DGGEML511-MBX.china.huawei.com ([169.254.1.248]) by dggeml423-hub.china.huawei.com ([10.1.199.40]) with mapi id 14.03.0487.000; Thu, 23 Apr 2020 10:10:25 +0800 From: Qin Wu To: Stephen Kent , "secdir@ietf.org" , Benjamin Kaduk CC: "netmod@ietf.org" , "draft-ietf-netmod-factory-default.all@ietf.org" , "last-call@ietf.org" Thread-Topic: Secdir last call review of draft-ietf-netmod-factory-default-14 Thread-Index: AdYZEvwNyq02j8DOS36yuTwtkmNm9Q== Date: Thu, 23 Apr 2020 02:10:25 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.33.123] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-netmod-factory-default-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: Thu, 23 Apr 2020 02:10:48 -0000 VGhhbmtzIFN0ZXBoZW4gZm9yIHZhbHVhYmxlIHJldmlldy4gU2VlIHJlcGx5IGlubGluZSBiZWxv dy4NCi0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCuWPkeS7tuS6ujogU3RlcGhlbiBLZW50IHZpYSBE YXRhdHJhY2tlciBbbWFpbHRvOm5vcmVwbHlAaWV0Zi5vcmddIA0K5Y+R6YCB5pe26Ze0OiAyMDIw 5bm0M+aciDEw5pelIDM6MTUNCuaUtuS7tuS6ujogc2VjZGlyQGlldGYub3JnDQrmioTpgIE6IG5l dG1vZEBpZXRmLm9yZzsgZHJhZnQtaWV0Zi1uZXRtb2QtZmFjdG9yeS1kZWZhdWx0LmFsbEBpZXRm Lm9yZzsgbGFzdC1jYWxsQGlldGYub3JnDQrkuLvpopg6IFNlY2RpciBsYXN0IGNhbGwgcmV2aWV3 IG9mIGRyYWZ0LWlldGYtbmV0bW9kLWZhY3RvcnktZGVmYXVsdC0xNA0KDQpSZXZpZXdlcjogU3Rl cGhlbiBLZW50DQpSZXZpZXcgcmVzdWx0OiBIYXMgSXNzdWVzDQoNClNFQ0RJUiByZXZpZXcgb2Yg ZHJhZnQtaWV0Zi1uZXRtb2QtZmFjdG9yeS1kZWZhdWx0LTE0DQoNCkkgaGF2ZSByZXZpZXdlZCB0 aGlzIGRvY3VtZW50IGFzIHBhcnQgb2YgdGhlIHNlY3VyaXR5IGRpcmVjdG9yYXRlJ3Mgb25nb2lu ZyBlZmZvcnQgdG8gcmV2aWV3IGFsbCBJRVRGIGRvY3VtZW50cyBiZWluZyBwcm9jZXNzZWQgYnkg dGhlIElFU0cuICBUaGVzZSBjb21tZW50cyB3ZXJlIHdyaXR0ZW4gd2l0aCB0aGUgaW50ZW50IG9m IGltcHJvdmluZyBzZWN1cml0eSByZXF1aXJlbWVudHMgYW5kIGNvbnNpZGVyYXRpb25zIGluIElF VEYgZHJhZnRzLiAgQ29tbWVudHMgbm90IGFkZHJlc3NlZCBpbiBsYXN0IGNhbGwgbWF5IGJlIGlu Y2x1ZGVkIGluIEFEIHJldmlld3MgZHVyaW5nIHRoZSBJRVNHIHJldmlldy4gIERvY3VtZW50IGVk aXRvcnMgYW5kIFdHIGNoYWlycyBzaG91bGQgdHJlYXQgdGhlc2UgY29tbWVudHMganVzdCBsaWtl IGFueSBvdGhlciBsYXN0IGNhbGwgY29tbWVudHMuDQoNClRoaXMgaXMgYSB2ZXJ5IGJyaWVmIGRv Y3VtZW50LSBvbmx5IDkgcGFnZXMgKGlnbm9yaW5nIG5vdGVzIHRoYXQgYXJlIHRvIGJlIHJlbW92 ZWQgYmVmb3JlIHB1YmxpY2F0aW9uKSEgSXQgaXMgYSBwcm9wb3NhbCBmb3IgYSBZQU5HIGRhdGEg bW9kZWwgdGhhdCB3aWxsIGFsbG93IGNsaWVudHMgdG8gcmVzZXQgYSBzZXJ2ZXIgdG8gaXRzIGZh Y3RvcnkgZGVmYXVsdCBzZXR0aW5ncy4gSXQgYWxzbyBkZWZpbmVzIGEg4oCcZmFjdG9yeS1kZWZh dWx04oCdIGRhdGFzdG9yZSB0aGF0IGVuYWJsZXMgYSBjbGllbnQgdG8gZGV0ZXJtaW5lIHRoZSB2 YWx1ZXMgZm9yIHRoZSBkZWZhdWx0IHNldHRpbmdzIGZvciBhIHNlcnZlci4gVGhlIGRhdGFtb2Rl bCBpcyBzYWlkIHRvIGNvbmZvcm0gdG8gdGhlIGFyY2hpdGVjdHVyZSBkZWZpbmVkIGluIFJGQyA4 MzQyLg0KDQpSRkMgODM0MiwgYW5kIFJGQyA3OTUwLCBkZWZpbmUgdGhlIHRlcm1zIHVzZWQgaW4g dGhpcyBkb2N1bWVudCwgYW5kIHRoZSB0ZXJtaW5vbG9neSBTZWN0aW9uICgxLjEpIGNpdGVzIHRo ZXNlIFJGQ3Mgd2hlbiBlbnVtZXJhdGluZyB0aGVzZSB0ZXJtcy4gVGhpcyByZWFkZXIgd291bGQg cHJlZmVyIHRvIGhhdmUgdGhlIGRlZmluaXRpb25zIHJlcGxpY2F0ZWQgaGVyZSBmb3IgdGhlIG5p bmUgdGVybXMgaW4gcXVlc3Rpb24uIA0KW1Fpbl06IFJlcGxpY2F0aW5nIGRlZmluaXRpb24gaW4g UkZDODM0MiBhbmQgUkZDNzk1MCBzZWVtcyByZWR1bmRhbnQgYW5kIHJlZmVyZW5jZSB0aGUgZXhp c3RpbmcgZGVmaW5pdGlvbiBtZWFucyBob25vciBleGlzdGluZyB3b3JrIGFuZCBhbHNvIGhlbHAg cmVhZGVyIHRvIGZpbmQgdGhlIHNvdXJjZSBvZiBkZWZpbml0aW9uLDotKQ0KT25seSBvbmUgYWRk aXRpb25hbCB0ZXJtIGlzIGRlZmluZWQgaW4gdGhpcyBkb2N1bWVudCwgdGhlIGZhY3RvcnktZGVm YXVsdCBkYXRhc3RvcmUuIFRoZSBhY3JvbnltIOKAnFJQQ+KAnSAocmVtb3RlIHByb2NlZHVyZSBj YWxsKSBpcyBub3QgZXhwYW5kZWQgdXBvbiBmaXJzdCB1c2UuDQpbUWluXTogT2theSwgdHJ5IHRv IGZpeCB0aGlzLHRoYW5rcy4NCg0KVGhlIGRlc2NyaXB0aW9uIG9mIGhvdyB0byBlZmZlY3QgYSBm YWN0b3ItcmVzZXQgUlBDLCBpbiBTZWN0aW9ucyAyICYgMyBzZWVtcyBwcmV0dHkgdGhvcm91Z2gs IGFuZCBpbmNsdWRlcyBhcHByb3ByaWF0ZSBjb21tZW50cyBhYm91dCBzZWN1cml0eS1yZWxldmFu dCBkYXRhLCBlLmcuLCBwcml2YXRlIGtleXMgYW5kIGNlcnRpZmljYXRlcy4gSSBhbiBub3QgZmFt aWxpYXIgZW5vdWdoIHdpdGggWUFORyB0byBldmFsdWF0ZSB0aGUgbW9kdWxlIGRlZmluaXRpb24g aW4gU2VjdGlvbiA0Lg0KW1Fpbl06dGhlIG1vZHVsZSBkZWZpbml0aW9uIHdpbGwgYmUgZXZhbHVh dGVkIG9yIHZhbGlkYXRlIGJ5IHVzaW5nIHB5YW5nIHRvb2wgd2hpY2ggaGFzIGFscmVhZHkgYmUg cGFydCBvZiBkYXRhdHJhY2tlciB3aXRoIEhlbnJpaydzIHN1cHBvcnQuDQoNClNlY3Rpb24gNiwg U2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMsIGNhbGxzIGZvciB1c2Ugb2YgU1NIIChSRkMgNjI0Mikg d2l0aCBORVRDT05GIGFuZCBIVFRQUyAoUkZDIDg0NDYpIHdpdGggUkVTVENPTkYuIFRoZSBUTFMg cmVmZXJlbmNlIGlzIGN1cnJlbnQsIGNpdGluZyBUTFMgdjEuMy4gSG93ZXZlciwgUkZDIDYyNDIg aXMgYSBkb2N1bWVudCB0aGF0IGRlc2NyaWJlcyBob3cgdG8gdXNlIFNTSCB3aXRoIE5FVENPTkYu IFRoYXQgZG9jdW1lbnQsIGluIHR1cm4sIGNpdGVzIFJGQyA0MjU0LCBhbmQgdGhhdCBSRkMgY2l0 ZXMgUkZDDQo0MjUzIGZvciBhIGRlc2NyaXB0aW9uIG9mIFNTSC4gNDI1MyBpcyBhIHZlcnkgbXVj aCBvdXQgb2YgZGF0ZSBkb2N1bWVudDsgdGhlIGludGVncml0eSBhbmQga2V5IG1hbmFnZW1lbnQg YWxnb3JpdGhtcyBpbiB0aGUgb3JpZ2luYWwgUkZDIGhhdmUgYmVlbiB1cGRhdGVkIDMgdGltZXMg KDY2NjgsIDgyNjgsIGFuZCA4MzMyKS4gVGhlIGVuY3J5cHRpb24gYWxnb3JpdGhtcyBjaXRlZCBp biA0MjUzIGFyZSBhbGwgb3V0ZGF0ZWQuIFRoaXMgZGlzY3Vzc2lvbiBvZiBTU0ggc2VjdXJpdHkg Zm9yIHVzZSB3aXRoIE5FVENPTkYsIGJhc2VkIG9uIHRoZSBvbmUgY2l0YXRpb24sIHNlZW1zIHRv IGJlIGluY29uc2lzdGVudCB3aXRoIGN1cnJlbnQgSUVURiBjcnlwdG8gZ3VpZGVsaW5lcy4NClRo aXMgaXMgYSBwcm9ibGVtIHRoYXQgdGhlIG5ldCBtYW5hZ2VtZW50IGFyZWEgc2hvdWxkIGFkZHJl c3MgYmVmb3JlIHRoaXMgZG9jdW1lbnQgaXMgYXBwcm92ZWQuDQpbUWluXSBTZWUgcmVsZXZhbnQg ZGlzY3Vzc2lvbiBhbmQgcmVzcG9uc2UgaW4gbmV0bW9kIGJlbG93DQpodHRwczovL21haWxhcmNo aXZlLmlldGYub3JnL2FyY2gvbXNnL25ldG1vZC81UkZ4T0VPRFVNTU1WMFlMMlR1b2pMYTIwM2sv DQpodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL25ldG1vZC9zSXRDdHpYenFO dXdLallPbTVfeFdJTmxydkkvDQpodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNn L25ldG1vZC9KRnVyTHBzZjhkMS0zQTlRd2V5a29peGtLcjQvDQoNCg0KVGhlIGRpc2N1c3Npb24g b2YgaG93IGEgZmFjdG9yeS1yZXNldCBSUEMgbWF5IGlzb2xhdGUgYSBkZXZpY2UsIGlzIGdvb2Qs IGFzIGlzIHRoZSB3YXJuaW5nIGFib3V0IG5vdCByZWx5aW5nIG9uIHRoaXMgUlBDIHRvIHByZXZl bnQgcmVjb3Zlcnkgb2Ygc2VjdXJpdHktc2Vuc2l0aXZlIGRhdGEgZnJvbSBOViBzdG9yYWdlLg0K W1Fpbl06IFRoYW5rcywgbWFueSBvZiB5b3VyIGNvbW1lbnRzIGFyZSBzZWxmLWV4cGxhbmF0aW9u IGNvbW1lbnRzLCBubyBuZWVkIGZvciBmdXJ0aGVyIGNsYXJpZmljYXRpb24sIHRoYW5rcy4NCg0K DQo= From nobody Thu Apr 23 14:26:26 2020 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 23E643A13F5 for ; Thu, 23 Apr 2020 14:26:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Tero Kivinen via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 6.127.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu, Tero Kivinen Message-ID: <158767718485.25373.17158044869218192248@ietfa.amsl.com> Date: Thu, 23 Apr 2020 14:26:24 -0700 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, 23 Apr 2020 21:26:25 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2020-04-24 Reviewer LC end Draft Vincent Roca 2020-01-30 draft-ietf-pim-msdp-yang-18 For telechat 2020-05-21 Reviewer LC end Draft Donald Eastlake R2019-11-14 draft-ietf-hip-dex-18 Last calls: Reviewer LC end Draft John Bradley 2020-02-28 draft-ietf-regext-data-escrow-07 Alan DeKok 2019-06-04 draft-ietf-netvc-testing-09 Donald Eastlake 2020-02-27 draft-ietf-6tisch-msf-16 Donald Eastlake R2019-11-14 draft-ietf-hip-dex-18 Daniel Franke 2020-03-09 draft-ietf-regext-dnrd-objects-mapping-06 Aanchal Malhotra 2020-03-12 draft-ietf-bess-vpls-multihoming-05 Russ Mundy 2020-01-02 draft-ietf-dprive-bcp-op-08 Magnus Nystrom 2019-04-10 draft-ietf-avtcore-multiplex-guidelines-11 Hilarie Orman 2020-04-29 draft-hodges-webauthn-registries-05 Francesca Palombini 2020-04-28 draft-ietf-rtcweb-sdp-11 Vincent Roca 2020-04-23 draft-ietf-detnet-ip-over-mpls-05 Vincent Roca 2020-01-30 draft-ietf-pim-msdp-yang-18 Kyle Rose 2020-04-30 draft-ietf-idr-capabilities-registry-change-07 Joseph Salowey 2020-05-05 draft-ietf-ospf-mpls-elc-13 Rich Salz 2020-05-05 draft-ietf-isis-mpls-elc-11 Stefan Santesson 2020-05-04 draft-ietf-httpbis-header-structure-18 Yaron Sheffer None draft-ietf-opsawg-tacacs-yang-03 Sean Turner 2020-05-06 draft-ietf-opsawg-sdi-02 Dacheng Zhang 2020-03-12 draft-nottingham-how-did-that-get-into-the-repo-01 Dacheng Zhang 2019-11-05 draft-ietf-mpls-ri-rsvp-frr-07 Next in the reviewer rotation: Rifaat Shekh-Yusef Melinda Shore Valery Smyslov Robert Sparks Takeshi Takahashi Tina Tsou Sean Turner Mališa Vučinić Carl Wallace Samuel Weiler From nobody Fri Apr 24 06:27:50 2020 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 B1FCE3A0D23; Fri, 24 Apr 2020 06:27:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Francesca Palombini via Datatracker To: Cc: draft-ietf-rtcweb-sdp.all@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.127.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158773486767.10860.13207279734771599599@ietfa.amsl.com> Reply-To: Francesca Palombini Date: Fri, 24 Apr 2020 06:27:47 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-rtcweb-sdp-11 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, 24 Apr 2020 13:27:48 -0000 Reviewer: Francesca Palombini 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 provides an informational reference for examples of the Session Description Protocol (SDP) Offer/Answer exchange mechanism, for the most common Rtcweb use-cases. The security considerations section points to documents describing the security architecture for WebRTC as a whole, which is appropriate for such an informational document. From nobody Fri Apr 24 07:50:07 2020 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 3F4263A0986; Fri, 24 Apr 2020 07:50:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Kyle Rose via Datatracker To: Cc: idr@ietf.org, last-call@ietf.org, draft-ietf-idr-capabilities-registry-change.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.127.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158773980020.30877.3733079568668640715@ietfa.amsl.com> Reply-To: Kyle Rose Date: Fri, 24 Apr 2020 07:50:00 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-idr-capabilities-registry-change-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, 24 Apr 2020 14:50:01 -0000 Reviewer: Kyle Rose 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 is ready. It describes a policy change regarding assignment of BGP capability codes, with no novel security implications. From nobody Fri Apr 24 20:58:56 2020 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 AC2073A0A66; Fri, 24 Apr 2020 20:58:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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=UmSg3sqC; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=Vn/nH/gd 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 lzbrZ4tmQVFd; Fri, 24 Apr 2020 20:58:52 -0700 (PDT) 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 AA27A3A0A65; Fri, 24 Apr 2020 20:58:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4980; q=dns/txt; s=iport; t=1587787132; x=1588996732; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=56P6Sw2Hal6I5BrZVlzhl38u0UyjC1SelghE1GR6v0k=; b=UmSg3sqCM0jTWFgVRb9kRPgLMKMf/vP0IuSjVPwpBAMgxDAExO69Ok4v LhRyY6s2BoUG+DlI5ATCFifX/1oll/8JZG1ago2dv7omobOauDuWmXjbh RIpyZBUVroE0BEkP6aubicqMJzTUXiwIDJhG8kAXZFnr172o5n9UmmUag Y=; IronPort-PHdr: =?us-ascii?q?9a23=3A8rd+3Ra1hn0BlQPx7sBLuAH/LSx94ef9IxIV55?= =?us-ascii?q?w7irlHbqWk+dH4MVfC4el20gabRp3VvvRDjeee87vtX2AN+96giDgDa9QNMn?= =?us-ascii?q?1NksAKh0olCc+BB1f8Kavhdy01Gs1eXXdu/mqwNg5eH8OtL1A=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BaAQDFtKNe/4wNJK1mHAEBAQEBBwE?= =?us-ascii?q?BEQEEBAEBPIE2BAEBCwGBU1EFbFggBAsqCoQVg0YDinGCX5gwglIDVAsBAQE?= =?us-ascii?q?MAQEYCwoCBAEBhEQCF4IPJDcGDgIDAQELAQEFAQEBAgEFBG2FKgclDIVyAQE?= =?us-ascii?q?BAgEBARAREQwBASsBCwEECwIBBgIaAiYCAgIlCxUQAQEEDgUbB4MEAYJLAw4?= =?us-ascii?q?gAQ6VfpBnAoE5iGF2gTKDAAEBBYUrGIIOAwaBDioBgmKHCoEggSwagUE/gRE?= =?us-ascii?q?nHIFPfj6CZwEBgTwoOQKCWDKCLZE3kG+PeQqCRZd8HYJaiFaMIYUgqTSDQgI?= =?us-ascii?q?EAgQFAg4BAQWBaCOBVnAVOyoBgj4+EhgNj16BVgwXg0+FFIVCdDUCBgEHAQE?= =?us-ascii?q?DCXyMAoE1AYEPAQE?= X-IronPort-AV: E=Sophos;i="5.73,314,1583193600"; d="scan'208";a="668944847" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 25 Apr 2020 03:58:50 +0000 Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by alln-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id 03P3wo92021475 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 25 Apr 2020 03:58:50 GMT Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 24 Apr 2020 22:58:50 -0500 Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 24 Apr 2020 22:58:50 -0500 Received: from NAM11-DM6-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Fri, 24 Apr 2020 23:58:50 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=lH5vunlSXX1RVsRI9G3fjhvqxr6ARFmjRWW4n+M/h5SosU/paB466INceDMDmmwbD1S4DmO1u8vQGCvwJB01SaZBhwLtvBoQFz9QxKqIAH3j9RggzQwC9HH6Pgn2ym8sxHKKoFaOLKNT6Y59MJcDDygUCgeWLSg1TgiXjzCGV+AdmHQplrsqCY7zfBOLX99eC4Qm79aTM7PKrQ71iX2PoT1HaEDErMN/QSGniArJJ9vqlEm7fZdRlJhTEu6rTDucjEUnFOvrCoAcDosO0C97YXBsS+Z52LYdn/7fjoFMUrGq99maOY1UoFqdRA1ebc3SSf0OY2wy7nK8JhQpjJAdyw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=56P6Sw2Hal6I5BrZVlzhl38u0UyjC1SelghE1GR6v0k=; b=Oj/HUMGlwlQEGG1sQsHbOhqAbk2VZ1e7TrKKb6SgexpUxXhyQws7CVAlrvCQm2cwtFtqwU9utqH6UsMxQiF5lhc2cd34lNLwitMJBweJyxeftkIQsCnJHDpSRqpXIeAOJXxmXsTLX+JoFKABWU28XW+SwHFTGw8+NbuhmTl7z2z1CzOvUZsOKHDncMoThNA5+Kk8c7ch2jryiXC8AKWH1qJ6KHoRsbgV9AUMWYsQlYN13gWr+uNjhAZRy49FY3z8St23XZNPFr29AUbrsvU11kdoIQtxAy8PJadr7vNswl8wk/AYuLztvWSNM3buvOQaKZ0Nxo6Y1rq6zmrMkz0bvA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=56P6Sw2Hal6I5BrZVlzhl38u0UyjC1SelghE1GR6v0k=; b=Vn/nH/gdEkJC121M/+v8g6/JvCTJsyuCmTaZeseXv/4HUhYRd9P/EpN6hWhBDuYfdza5j0NFInqXY4lKYCuvAeg/Uo/RHWYOLiXSXpFkdkxMWvwMGfeIAo2Bnrh0N5wbLYp5XWnwjRsDzjVMB5nEJyKIE6wFQrXcXrizSwDC7zY= Received: from BN8PR11MB3635.namprd11.prod.outlook.com (2603:10b6:408:86::20) by BN8PR11MB3842.namprd11.prod.outlook.com (2603:10b6:408:82::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2921.29; Sat, 25 Apr 2020 03:58:49 +0000 Received: from BN8PR11MB3635.namprd11.prod.outlook.com ([fe80::9981:86d4:ca20:ff96]) by BN8PR11MB3635.namprd11.prod.outlook.com ([fe80::9981:86d4:ca20:ff96%7]) with mapi id 15.20.2921.030; Sat, 25 Apr 2020 03:58:48 +0000 From: "Carlos Pignataro (cpignata)" To: "Konda, Tirumaleswar Reddy" CC: "secdir@ietf.org" , "sfc@ietf.org" , "draft-ietf-sfc-ioam-nsh.all@ietf.org" Thread-Topic: [sfc] Secdir last call review of draft-ietf-sfc-oam-framework Thread-Index: AdYW4VRPPDX1YR3aSqa2kbIsbH1DggD1H3GA Date: Sat, 25 Apr 2020 03:58:48 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3608.80.23.2.2) authentication-results: spf=none (sender IP is ) smtp.mailfrom=cpignata@cisco.com; x-originating-ip: [108.203.7.63] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a01acc2c-a06f-4d39-9111-08d7e8ccf5bc x-ms-traffictypediagnostic: BN8PR11MB3842: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0384275935 x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN8PR11MB3635.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(346002)(366004)(136003)(376002)(396003)(39860400002)(8936002)(26005)(66476007)(76116006)(64756008)(5660300002)(81156014)(8676002)(186003)(86362001)(316002)(6916009)(66556008)(66446008)(2906002)(4326008)(66946007)(6512007)(966005)(54906003)(33656002)(2616005)(71200400001)(478600001)(6486002)(36756003)(6506007); DIR:OUT; SFP:1101; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: +jRZB2t5j1eaPeI4B0GnAd4dpkQ6OU48gyxBSw42DXbC4IQLYgFDi0v4jK8iB35nfT7xAL7/f/VuTydojTMzXwYNrgxLKEVH8xK1RKssp+mOF8/Ek14WkWdvzEBrsyBH48qx4xFjfBcAtxsVKzdCs79s8mQFFwxki8P/h1Ml4P9YF0YUo5z0pRmtWdZ1Nszc+7kLuVqLfd9SonVYo8ZkkY5KTwCMcKPnhtMZTU8Qs+Yo6dRTVW/p4br4HjpU50j0csd/Dj21iW84GqLxP6ylTBMIaiPe2ghs8Nfr+PKreWV9tbWHK6+duOcOwLNNYT0g8AQdzoty34OW4+inAX1OVXRxcPVfuU+6sMbMynKYBm5nNhOVQNoaZxnYt4EMWOcNRFiGUXvqUXjruF2HZIW6P8U/FLcuJNaz3dGNqdqmDLpcKVSs04PC/f5JfE0DfsHnTABnKDmvi+vUhlHUZP4JjyJkeDCkb64G9r9Fnh70khlh5CS+P1L0mgWRFnwS1vTTOZvQoONV/augp7xRe1ngdw== x-ms-exchange-antispam-messagedata: PzkiCrcQmmlWFBZ3iyL3X/Kx8FfLJOZORChDEwbmFk9KWkhcCZ1yeqZzHFlR0RRV5xoGKOBmuLdz44nbpDgVSIKHkRNBE0zcZkpZmFLgrnjoPYoHxqKzNoB9cPvixZuW5ADp3fZXOJow56c+yFHKwH1DOTEJTJwf7sr+Q3zjp08j3aupE17TR/fiUoV46jl0LwHA1fhZi2y4S2O0umtKKarOi307sc3W5nUSV5leRffb3lgjzujXt+rQDHOtAEW5hAgbihNZ7OMmTGGpRKgMAg68YiNTGBQtp71g8aDvFGFbq9iDOAfvjIIq5OdXqlSziBlGMR2D4+NKey4QZ9bFRqqsmE/AbGT5y+n1HPlnxZRq3EkIl1HtN6hGVil7h2XblL4TAiHZW1L2nHlWpfdFeTmRhGY8wbBNLwSojk4mwpU8zJNC2Ak9+6FV/aIjAoNE1cBCU3lu+/bmohYoaf+IDtR82Pv1FIdp+fj1QOdohcbfHz5g2m2T1j5S2enqo/QYPnVAaRUs6i/wyG1ewQzYSn2Oi62NfteUNvUmY5EgqxHMQ2Q8E+7tQU9Xy4M1wL01CppbUxKCgyBMULQEuB+3ceGB5AvWwADQMC95pTYrjo5YUAY7aeCFc8wZn+ttPnu8Vq4SNfOzwq1oUrrsHiY9aL6w79AZBwiYs7tMV5jhg0J8vFIURef+m5cW/S1t6McIfsP7pWgtdcpuOjkdMmcPwc976Ig3j1sa8wC7iJJRffIbrL8jm5F8KCqbfQE14FZp7xY2V/VMcy5wsBf/3Z8mRYWPH6XzeXBVRFjb0i84/NY= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: a01acc2c-a06f-4d39-9111-08d7e8ccf5bc X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Apr 2020 03:58:48.9393 (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-CrossTenant-userprincipalname: dlgnqyHK6YMNBOz219dMIWNtR5DpjMZ6b8DSFc6hkukifgVUmbfOilon62Llz/8MHDbzFOSvymEd3gtggLZN6A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8PR11MB3842 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.11, xch-aln-001.cisco.com X-Outbound-Node: alln-core-7.cisco.com Archived-At: Subject: Re: [secdir] [sfc] Secdir last call review of draft-ietf-sfc-oam-framework 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, 25 Apr 2020 03:58:55 -0000 SGksIFRpcnUsDQoNCk1hbnkgdGhhbmtzIGZvciB0aGUgcmV2aWV3LCBhbmQgZ3JlYXQgdG8gaGVh ciBmcm9tIHlvdSENCg0KSSBob3BlIGFsbCBpcyB3ZWxsIOKAlCBQbGVhc2Ugc2VlIGlubGluZS4N Cg0KPiAyMDIwLzA0LzIwIOWNiOWJjTM6MjjjgIFLb25kYSwgVGlydW1hbGVzd2FyIFJlZGR5IDxU aXJ1bWFsZXN3YXJSZWRkeV9Lb25kYUBNY0FmZWUuY29tPuOBruODoeODvOODqzoNCj4gDQo+IFJl dmlld2VyOiBUaXJ1bWFsZXN3YXIgUmVkZHkNCj4gUmV2aWV3IHJlc3VsdDogUmVhZHkgd2l0aCBp c3N1ZXMNCj4gIA0KPiAgDQo+IEkgcmV2aWV3ZWQgdGhpcyBkb2N1bWVudCBhcyBwYXJ0IG9mIHRo ZSBzZWN1cml0eSBkaXJlY3RvcmF0ZSdzIG9uZ29pbmcgZWZmb3J0IHRvIHJldmlldyBhbGwgSUVU RiBkb2N1bWVudHMgZW50ZXJpbmcgdGhlIElFU0cuLiAgVGhlc2UgY29tbWVudHMgYXJlIGRpcmVj dGVkIGF0IHRoZSBzZWN1cml0eSBhcmVhIGRpcmVjdG9yKHMpLiAgRG9jdW1lbnQgZWRpdG9ycyBh bmQgV0cgY2hhaXJzIHNob3VsZCB0cmVhdA0KPiB0aGVzZSBjb21tZW50cyBsaWtlIGFueSBvdGhl ciBsYXN0IGNhbGwgY29tbWVudHMuDQo+ICANCj4gVGhpcyBkb2N1bWVudCBwcm92aWRlcyBhIHJl ZmVyZW5jZSBmcmFtZXdvcmsgZm9yIE9BTSBmb3IgU0ZDLg0KPiAgDQo+IENvbW1lbnRzOg0KPiAg DQo+IDEuIFRoZSBkb2N1bWVudCBpbiBTZWN0aW9uIDggZGlzY3Vzc2VzIHZhcmlvdXMgYXR0YWNr cyAoaW5jbHVkaW5nIGJvdGggc2VjdXJpdHkgYW5kIHByaXZhY3kpIGJ1dCBkb2VzIG5vdCBkaXNj dXNzIGFueSBwcm90ZWN0aW9uIG1lY2hhbmlzbXMgb3RoZXIgdGhhbiBwcm9wb3NpbmcgcmF0ZS1s aW1pdGluZy4gIEl0IGlzIHN1Z2dlc3RpbmcgZHJhZnRzIHByb3Bvc2luZyB0aGUgT0FNIHNvbHV0 aW9uIHNob3VsZCBhZGRyZXNzIHRoZSBhdHRhY2tzIGJ1dCBJIGRvbuKAmXQgc2VlIGFueSBzZWN1 cml0eSANCj4gbWVjaGFuaXNtcyBkaXNjdXNzZWQgaW4gZHJhZnQtaWV0Zi1zZmMtaW9hbS1uc2gg dG8gYWRkcmVzcyB0aGUgYXR0YWNrcy4NCj4gIA0KDQpTaW5jZSB0aGUgZG9jdW1lbnQgYWxyZWFk eSBjbGFyaWZpZXMgdGhhdCBpdCBkb2VzIG5vdCBkZWZpbmUgc29sdXRpb25zLCBpdCBjYW5ub3Qg ZGVmaW5lIHNlY3VyaXR5IGNvbnNpZGVyYXRpb24gZm9yIHRob3NlIHNvbHV0aW9ucywgYmV5b25k IHNheWluZyB0aGF0IHRob3NlIHNvbHV0aW9ucyBvdWdodCB0byBhZGRyZXNzIHNlY3VyaXR5IGNv bnNpZGVyYXRpb25zIGluIHRob3NlIGFyZWFzLiBBbnkgc2VjdXJpdHkgbWVhc3VyZXMgbXVzdCBi ZSBpbmNsdWRlZCBhbmQgZXhwbGFpbmVkIGluIHRoZSByZXNwZWN0aXZlIHNvbHV0aW9uIGRvY3Vt ZW50LiBJIGJlbGlldmUgdGhpcyBjb21tZW50IHJlcXVpcmVzIHBvdGVudGlhbGx5IGFjdGlvbiBv biBkcmFmdC1pZXRmLXNmYy1pb2FtLW5zaCBidXQgbm90IG9uIHRoaXMgZHJhZnQuDQoNClRoYXQg c2FpZCB5b3UgYXJlIHJpZ2h0IHJlZ2FyZGluZyB0aGUgc3BlY2lmaWNzIG9mIHRoZSByYXRlLWxp bWluZyByZWNvbW1lbmRhdGlvbi4gU2VlIHRoZSBuZXh0IGFuc3dlciBmb3IgdGV4dC4NCg0KQWxz bywgaW4gcmUtcmVhZGluZyBTZWN0aW9uIDgsIHNlZW1zIGxpa2UgdGhpczoNCg0KICAgVG8gYWRk cmVzcyB0aGUgYWJvdmUgY29uY2VybnMsIFNGQyBhbmQgU0YgT0FNIG1heSBwcm92aWRlIG1lY2hh bmlzbQ0KICAgZm9yOg0KDQoNClNob3VsZCBzYXkNCg0KICAgVG8gYWRkcmVzcyB0aGUgYWJvdmUg Y29uY2VybnMsIFNGQyBhbmQgU0YgT0FNIHNob3VsZCBwcm92aWRlIG1lY2hhbmlzbXMNCiAgIGZv ciBwcmV2ZW50aW5nOg0KDQoNCg0KPiAyLiBNb3JlIGRpc2N1c3Npb24gaXMgcmVxdWlyZWQgb24g dGhlIGludGVybmFsIGF0dGFja3MuIA0KPiAoYSkgSG93IGFyZSBhdHRhY2sgcGFja2V0cyBieXBh c3NpbmcgU0ZDIGRldGVjdGVkIGFuZCBibG9ja2VkID8NCj4gKGIpIEhvdyBpcyBzZW5zaXRpdmUg aW5mb3JtYXRpb24gcHJvdGVjdGVkIGZyb20gZWF2ZXNkcm9wcGVycyA/DQo+IChjKSBIb3cgaXMg RG9TL0REb1MgYXR0YWNrIG9mIG1pc3VzaW5nIHRoZSBPQU0gY2hhbm5lbCBpcyBtaXRpZ2F0ZWQg Pw0KPiAoZCkgUmF0ZS1saW1pdGluZyBibG9ja3MgYm90aCBnb29kIGFuZCBiYWQgT0FNIHByb2Jl cyBhbmQgaXMgYSB3ZWFrIG1pdGlnYXRpb24gc3RyYXRlZ3kuIEFub21hbHkgZGV0ZWN0aW9uIChl LmcuLCBkZWVwIGxlYXJuaW5nIHRlY2hpbnF1ZXMpIGFuZCBpZGVudGlmeWluZyB0aGUgYXR0YWNr ZXIgbG9vayBsaWtlIGEgYmV0dGVyIHN0cmF0ZWd5Lg0KPiAgDQoNCg0KVGhpcyBpcyBhIGdvb2Qg cG9pbnQuIEhvdyBhYm91dC4NCg0KT0xEOg0KDQogICBUaGUgZG9jdW1lbnRzIHByb3Bvc2luZyB0 aGUgT0FNIHNvbHV0aW9uIGZvciBTRiBjb21wb25lbnQgc2hvdWxkDQogICBjb25zaWRlciByYXRl LWxpbWl0aW5nIHRoZSBPQU0gcHJvYmVzIGF0IGEgZnJlcXVlbmN5IGd1aWRlZCBieSB0aGUNCiAg IGltcGxlbWVudGF0aW9uIGNob2ljZS4gIFJhdGUtbGltaXRpbmcgbWF5IGJlIGFwcGxpZWQgYXQg dGhlIFNGRiBvcg0KICAgdGhlIFNGIC4gVGhlIE9BTSBpbml0aWF0b3IgbWF5IG5vdCByZWNlaXZl IGEgcmVzcG9uc2UgZm9yIHRoZSBwcm9iZXMNCiAgIHRoYXQgYXJlIHJhdGUtbGltaXRlZCByZXN1 bHRpbmcgaW4gZmFsc2UgbmVnYXRpdmVzIGFuZCB0aGUNCiAgIGltcGxlbWVudGF0aW9uIHNob3Vs ZCBiZSBhd2FyZSBvZiB0aGlzLg0KDQoNCk5FVzoNCg0KIA0KICAgVGhlIGRvY3VtZW50cyBwcm9w b3NpbmcgdGhlIE9BTSBzb2x1dGlvbiBmb3IgU0YgY29tcG9uZW50IHNob3VsZA0KICAgY29uc2lk ZXIgcmF0ZS1saW1pdGluZyB0aGUgT0FNIHByb2JlcyBhdCBhIGZyZXF1ZW5jeSBndWlkZWQgYnkg dGhlDQogICBpbXBsZW1lbnRhdGlvbiBjaG9pY2UuICBSYXRlLWxpbWl0aW5nIG1heSBiZSBhcHBs aWVkIGF0IHRoZSBTRkYgb3INCiAgIHRoZSBTRi4gIFRoZSBPQU0gaW5pdGlhdG9yIG1heSBub3Qg cmVjZWl2ZSBhIHJlc3BvbnNlIGZvciB0aGUgcHJvYmVzDQogICB0aGF0IGFyZSByYXRlLWxpbWl0 ZWQgcmVzdWx0aW5nIGluIGZhbHNlIG5lZ2F0aXZlcyBhbmQgdGhlDQogICBpbXBsZW1lbnRhdGlv biBzaG91bGQgYmUgYXdhcmUgb2YgdGhpcy4gVG8gbWl0aWdhdGUgYW55IGF0dGFja3MgdGhhdA0K ICAgTGV2ZXJhZ2UgT0FNIHBhY2tldHMsIGZ1dHVyZSBkb2N1bWVudHMgcHJvcG9zaW5nIE9BTSBz b2x1dGlvbnMgIA0KICAgc2hvdWxkIGRlc2NyaWJlIHRoZSB1c2Ugb2YgYW55IHRlY2huaXF1ZXMg dG8gZGV0ZWN0DQogICBhbmQgbWl0aWdhdGUgYW5vbWFsaWVzIGFuZCB2YXJpb3VzIHNlY3VyaXR5 ICBhdHRhY2tzLg0KDQoNCldvdWxkIHRoYXQgd29yaz8NCg0KUGxlYXNlIGZlZWwgZnJlZSB0byBz dWdnZXN0IHRleHR1YWwgaW1wcm92ZW1lbnRzIG9yIGNoYW5nZXMuDQoNClRoYW5rcywNCg0KQ2Fy bG9zLg0KDQo+IENoZWVycywNCj4gLVRpcnUNCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4gc2ZjIG1haWxpbmcgbGlzdA0KPiBzZmNAaWV0Zi5vcmcN Cj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCg0K From nobody Sun Apr 26 00:25:05 2020 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 DEF4E3A0F3F for ; Sun, 26 Apr 2020 00:25:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, 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=mcafee.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 oYjpETbq9ha3 for ; Sun, 26 Apr 2020 00:25:02 -0700 (PDT) Received: from us-smtp-delivery-140.mimecast.com (us-smtp-delivery-140.mimecast.com [216.205.24.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 222933A0F3E for ; Sun, 26 Apr 2020 00:25:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=mimecast20190606; t=1587885901; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=MqCk1Mt+tMI0qWC1dFJinVWKRp1g5hyX/FcrOo8oOHw=; b=bKXwMFL5KDBfDJBWYurtA3QrYrTLxmQ2GtMbyR40YI/6Sx24LjpqAQTbkudrqtXqPc9yOR rKund9NavC8D3wayeFD0a2HX9+1+ZY5wKxn0Ve7pKX0naQiIv9lDARfIlyQa4IXY4f9CXB Kjx2lHYMoSPj7R4VelKcssZtdMJnFr8= Received: from NAM11-CO1-obe.outbound.protection.outlook.com (mail-co1nam11lp2176.outbound.protection.outlook.com [104.47.56.176]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-423-XFGPO1DcOI6eWXj4LS8mWg-1; Sun, 26 Apr 2020 03:23:31 -0400 X-MC-Unique: XFGPO1DcOI6eWXj4LS8mWg-1 Received: from CY4PR1601MB1254.namprd16.prod.outlook.com (2603:10b6:903:d4::12) by CY4PR1601MB1222.namprd16.prod.outlook.com (2603:10b6:903:d4::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.13; Sun, 26 Apr 2020 07:23:28 +0000 Received: from CY4PR1601MB1254.namprd16.prod.outlook.com ([fe80::8172:432c:9870:d8fc]) by CY4PR1601MB1254.namprd16.prod.outlook.com ([fe80::8172:432c:9870:d8fc%5]) with mapi id 15.20.2937.020; Sun, 26 Apr 2020 07:23:28 +0000 From: "Konda, Tirumaleswar Reddy" To: "Carlos Pignataro (cpignata)" CC: "secdir@ietf.org" , "sfc@ietf.org" , "draft-ietf-sfc-ioam-nsh.all@ietf.org" Thread-Topic: [sfc] Secdir last call review of draft-ietf-sfc-oam-framework Thread-Index: AdYW4VRPPDX1YR3aSqa2kbIsbH1DggD1H3GAADj+SVA= Date: Sun, 26 Apr 2020 07:23:28 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.5.0.44 dlp-reaction: no-action x-originating-ip: [49.37.200.98] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 296d98f1-340a-4c0e-a91e-08d7e9b2b756 x-ms-traffictypediagnostic: CY4PR1601MB1222: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 03853D523D x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CY4PR1601MB1254.namprd16.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(346002)(39860400002)(396003)(136003)(366004)(376002)(32952001)(86362001)(2906002)(26005)(478600001)(5660300002)(55016002)(966005)(9686003)(81156014)(4326008)(8676002)(33656002)(54906003)(7696005)(71200400001)(186003)(6916009)(6506007)(53546011)(52536014)(8936002)(66556008)(64756008)(66446008)(316002)(66476007)(66946007)(76116006)(85282002); DIR:OUT; SFP:1101; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: IPHMv/yEZ8x2v0ZuDO+0UYKoAfezoiGcN1VmI7fgFnAzfV33AOUcOcj5wrwMwZBuuNvn4GwBDPg5c73cqFTkjKff4PuGz/4cCYAUCz0IaiqfPftmNZzekO/KII7L9InCnhmKOq72inmKOw7sLsRO9vwwjDGyLn2c9UL6RPNOR7Yy0tF+JfZvCJ9/FqYTTEDn28cQOClCbXbQbMtO11OJxhK8MnYhsuZi0K5JecfspH9aSzf1yPXJzBwWyBORMa9S/5PHf9hASWMvj32n6VSprmxFOoJFMkhGgk0JwP16B1vIm9IF2JVYacG4B31peP3NQg5MLnoWKlmcTrObHRu4RaQNxTOpYrNLKfh3NQNAYlE+XBsZHKxQgdrxtBap33tqbQwouQlNQ750Vf1Jhcv/ie72PdgIXP6PTvVMXKbmzkoKKRKjfbPbABcd7oTzyDKx3hBBELjUZsjxYwGyDiTOqaHq7wMAqJPbPuGAY+AsIbSS8Fh/wG93hQ73TYSBnzmr9Jf1P3NoyGzNlwZqbgVhujcLECk4dfQN0bD04lpyhTv2AjN4LIWNbGa72/URsYHnVOZD6Hxmk18qYlw96b0MH5mOtY+L5aA0q7DZKPb2lr4= x-ms-exchange-antispam-messagedata: f/pk2bjPRowkdBH0TeH5peOmLEkceABmiYw3VlRuKSgbYYvW29MLf9XOaGRRMfxSI014nAE9bqYjCUL0lWEt+7cz4JP3DSOEMOH4OkSa0OfLd7cueFwyWIsjkaY44Tjh6s5yzKDD5Nh4bDPsFhtrswLYevPIZDGNqOjT9cGg/zSE/EPmiHceTNnaTH1XA+rq46jOh/6BC5a9s3+B22HIptEw1uug8nF8GHefIkQikB8bifY1TyRsUeKHb7U9hln3LuiNiDP4wftwyz9PCuV838gzpg0QMMxDZCB6hwUL5XWy8lCu8eyVkR/qn2Z5Wd2QAXcrseN7IVIkmCosJhezpJs6ldlDDJRhQV2Pj+HlSSJ44KOHOkCJC6j8EISjeFcAktfwFF992D7vONcJSj+Nejwyw2sIX083zBWRRSr7+cxMTLOkCHsqBSbdE5Q8koZGSJixoHMmO38j9CJ7aGQ9T9qctHQzkt3/J9pXfYSS/UZ7m3u2yrPn+pHfZjK29H1am5CZz5RqSzhLMI+5eFF9HJjC5CNaxodtI/XadIv9KkwXjA6uVQhC/k3ybFoDpvCvssP+Q2UReHBNclnHuPPcn+ZC6LTfCUzI6k4txeUFzaLRIvetzaYkRbsG+j5Qw1+8ojKyhS2pZWBfUfwT/d9+qRJ9ZMVExPAscl2TX4bHmD39cjwJFyZhb9a9WUWXc0P40sz25tgdy1+I2geTHqAZVZLrZfqctE3bjitAPDhAD0UseELXg4ugvByrCIFZfx0caSvtYncA7v7p2D2cBOSY3NUt3AO/nAeJ4bq0qgmZKSg= x-ms-exchange-transport-forked: True MIME-Version: 1.0 X-OriginatorOrg: mcafee.com X-MS-Exchange-CrossTenant-Network-Message-Id: 296d98f1-340a-4c0e-a91e-08d7e9b2b756 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Apr 2020 07:23:28.2806 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: sVf5NArL+2Wx+u14pYkEj9um70cmzf/NMoteZ02Ughs36yjn+/seCNK/iS8gp985FhqSUnLBeV4TXh47O6lopEqOjkSrlTA7ldluahgjUR3vlhjYHoy8qfZKi+c8lEke X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR1601MB1222 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: mcafee.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [secdir] [sfc] Secdir last call review of draft-ietf-sfc-oam-framework 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, 26 Apr 2020 07:25:04 -0000 SGkgQ2FybG9zLA0KDQpQbGVhc2Ugc2VlIGlubGluZSANCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPiBGcm9tOiBDYXJsb3MgUGlnbmF0YXJvIChjcGlnbmF0YSkgPGNwaWduYXRhQGNp c2NvLmNvbT4NCj4gU2VudDogU2F0dXJkYXksIEFwcmlsIDI1LCAyMDIwIDk6MjkgQU0NCj4gVG86 IEtvbmRhLCBUaXJ1bWFsZXN3YXIgUmVkZHkgPFRpcnVtYWxlc3dhclJlZGR5X0tvbmRhQE1jQWZl ZS5jb20+DQo+IENjOiBzZWNkaXJAaWV0Zi5vcmc7IHNmY0BpZXRmLm9yZzsgZHJhZnQtaWV0Zi1z ZmMtaW9hbS1uc2guYWxsQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbc2ZjXSBTZWNkaXIgbGFz dCBjYWxsIHJldmlldyBvZiBkcmFmdC1pZXRmLXNmYy1vYW0tZnJhbWV3b3JrDQo+IA0KPiBDQVVU SU9OOiBFeHRlcm5hbCBlbWFpbC4gRG8gbm90IGNsaWNrIGxpbmtzIG9yIG9wZW4gYXR0YWNobWVu dHMgdW5sZXNzIHlvdQ0KPiByZWNvZ25pemUgdGhlIHNlbmRlciBhbmQga25vdyB0aGUgY29udGVu dCBpcyBzYWZlLg0KPiANCj4gSGksIFRpcnUsDQo+IA0KPiBNYW55IHRoYW5rcyBmb3IgdGhlIHJl dmlldywgYW5kIGdyZWF0IHRvIGhlYXIgZnJvbSB5b3UhDQo+IA0KPiBJIGhvcGUgYWxsIGlzIHdl bGwg4oCUIFBsZWFzZSBzZWUgaW5saW5lLg0KDQpUaGFua3MsIEnigJltIGZpbmUsIGFuZCBJIGhv cGUgYWxsIGlzIHdlbGwgd2l0aCB5b3UgdG9vLg0KDQo+IA0KPiA+IDIwMjAvMDQvMjAg5Y2I5YmN MzoyOOOAgUtvbmRhLCBUaXJ1bWFsZXN3YXIgUmVkZHkNCj4gPFRpcnVtYWxlc3dhclJlZGR5X0tv bmRhQE1jQWZlZS5jb20+44Gu44Oh44O844OrOg0KPiA+DQo+ID4gUmV2aWV3ZXI6IFRpcnVtYWxl c3dhciBSZWRkeQ0KPiA+IFJldmlldyByZXN1bHQ6IFJlYWR5IHdpdGggaXNzdWVzDQo+ID4NCj4g Pg0KPiA+IEkgcmV2aWV3ZWQgdGhpcyBkb2N1bWVudCBhcyBwYXJ0IG9mIHRoZSBzZWN1cml0eSBk aXJlY3RvcmF0ZSdzIG9uZ29pbmcNCj4gPiBlZmZvcnQgdG8gcmV2aWV3IGFsbCBJRVRGIGRvY3Vt ZW50cyBlbnRlcmluZyB0aGUgSUVTRy4uICBUaGVzZSBjb21tZW50cw0KPiBhcmUgZGlyZWN0ZWQg YXQgdGhlIHNlY3VyaXR5IGFyZWEgZGlyZWN0b3IocykuICBEb2N1bWVudCBlZGl0b3JzIGFuZCBX Rw0KPiBjaGFpcnMgc2hvdWxkIHRyZWF0IHRoZXNlIGNvbW1lbnRzIGxpa2UgYW55IG90aGVyIGxh c3QgY2FsbCBjb21tZW50cy4NCj4gPg0KPiA+IFRoaXMgZG9jdW1lbnQgcHJvdmlkZXMgYSByZWZl cmVuY2UgZnJhbWV3b3JrIGZvciBPQU0gZm9yIFNGQy4NCj4gPg0KPiA+IENvbW1lbnRzOg0KPiA+ DQo+ID4gMS4gVGhlIGRvY3VtZW50IGluIFNlY3Rpb24gOCBkaXNjdXNzZXMgdmFyaW91cyBhdHRh Y2tzIChpbmNsdWRpbmcgYm90aA0KPiA+IHNlY3VyaXR5IGFuZCBwcml2YWN5KSBidXQgZG9lcyBu b3QgZGlzY3VzcyBhbnkgcHJvdGVjdGlvbiBtZWNoYW5pc21zDQo+IG90aGVyIHRoYW4gcHJvcG9z aW5nIHJhdGUtbGltaXRpbmcuICBJdCBpcyBzdWdnZXN0aW5nIGRyYWZ0cyBwcm9wb3NpbmcgdGhl IE9BTQ0KPiBzb2x1dGlvbiBzaG91bGQgYWRkcmVzcyB0aGUgYXR0YWNrcyBidXQgSSBkb27igJl0 IHNlZSBhbnkgc2VjdXJpdHkgbWVjaGFuaXNtcw0KPiBkaXNjdXNzZWQgaW4gZHJhZnQtaWV0Zi1z ZmMtaW9hbS1uc2ggdG8gYWRkcmVzcyB0aGUgYXR0YWNrcy4NCj4gPg0KPiANCj4gU2luY2UgdGhl IGRvY3VtZW50IGFscmVhZHkgY2xhcmlmaWVzIHRoYXQgaXQgZG9lcyBub3QgZGVmaW5lIHNvbHV0 aW9ucywgaXQNCj4gY2Fubm90IGRlZmluZSBzZWN1cml0eSBjb25zaWRlcmF0aW9uIGZvciB0aG9z ZSBzb2x1dGlvbnMsIGJleW9uZCBzYXlpbmcgdGhhdA0KPiB0aG9zZSBzb2x1dGlvbnMgb3VnaHQg dG8gYWRkcmVzcyBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBpbiB0aG9zZSBhcmVhcy4gQW55DQo+ IHNlY3VyaXR5IG1lYXN1cmVzIG11c3QgYmUgaW5jbHVkZWQgYW5kIGV4cGxhaW5lZCBpbiB0aGUg cmVzcGVjdGl2ZSBzb2x1dGlvbg0KPiBkb2N1bWVudC4gSSBiZWxpZXZlIHRoaXMgY29tbWVudCBy ZXF1aXJlcyBwb3RlbnRpYWxseSBhY3Rpb24gb24gZHJhZnQtaWV0Zi0NCj4gc2ZjLWlvYW0tbnNo IGJ1dCBub3Qgb24gdGhpcyBkcmFmdC4NCg0KWXVwLiBJIHNlZSB0aHJlZSBzb2x1dGlvbnMgZnJv bSBTRkMgV0cgYSkgc2ZjLWlvYW0tbnNoIGIpIGlldGYtc2ZjLXByb29mLW9mLXRyYW5zaXQgKEV4 cGVyaW1lbnRhbCkgYykgcGVubm8tc2ZjLXRyYWNlIChFeHBpcmVkKS4gc2ZjLWlvYW0tbnNoIGlz IHRoZSBvbmx5IGN1cnJlbnQgc3RhbmRhcmRzIHRyYWNrIHNwZWNpZmljYXRpb24gYW5kIGl0IHNo b3VsZCBhZGRyZXNzIHRoZXNlIGF0dGFja3MuDQogDQo+IA0KPiBUaGF0IHNhaWQgeW91IGFyZSBy aWdodCByZWdhcmRpbmcgdGhlIHNwZWNpZmljcyBvZiB0aGUgcmF0ZS1saW1pbmcNCj4gcmVjb21t ZW5kYXRpb24uIFNlZSB0aGUgbmV4dCBhbnN3ZXIgZm9yIHRleHQuDQo+IA0KPiBBbHNvLCBpbiBy ZS1yZWFkaW5nIFNlY3Rpb24gOCwgc2VlbXMgbGlrZSB0aGlzOg0KPiANCj4gICAgVG8gYWRkcmVz cyB0aGUgYWJvdmUgY29uY2VybnMsIFNGQyBhbmQgU0YgT0FNIG1heSBwcm92aWRlIG1lY2hhbmlz bQ0KPiAgICBmb3I6DQo+IA0KPiANCj4gU2hvdWxkIHNheQ0KPiANCj4gICAgVG8gYWRkcmVzcyB0 aGUgYWJvdmUgY29uY2VybnMsIFNGQyBhbmQgU0YgT0FNIHNob3VsZCBwcm92aWRlDQo+IG1lY2hh bmlzbXMNCj4gICAgZm9yIHByZXZlbnRpbmc6DQoNClllcy4NCg0KPiANCj4gDQo+IA0KPiA+IDIu IE1vcmUgZGlzY3Vzc2lvbiBpcyByZXF1aXJlZCBvbiB0aGUgaW50ZXJuYWwgYXR0YWNrcy4NCj4g PiAoYSkgSG93IGFyZSBhdHRhY2sgcGFja2V0cyBieXBhc3NpbmcgU0ZDIGRldGVjdGVkIGFuZCBi bG9ja2VkID8NCj4gPiAoYikgSG93IGlzIHNlbnNpdGl2ZSBpbmZvcm1hdGlvbiBwcm90ZWN0ZWQg ZnJvbSBlYXZlc2Ryb3BwZXJzID8NCj4gPiAoYykgSG93IGlzIERvUy9ERG9TIGF0dGFjayBvZiBt aXN1c2luZyB0aGUgT0FNIGNoYW5uZWwgaXMgbWl0aWdhdGVkID8NCj4gPiAoZCkgUmF0ZS1saW1p dGluZyBibG9ja3MgYm90aCBnb29kIGFuZCBiYWQgT0FNIHByb2JlcyBhbmQgaXMgYSB3ZWFrDQo+ IG1pdGlnYXRpb24gc3RyYXRlZ3kuIEFub21hbHkgZGV0ZWN0aW9uIChlLmcuLCBkZWVwIGxlYXJu aW5nIHRlY2hpbnF1ZXMpIGFuZA0KPiBpZGVudGlmeWluZyB0aGUgYXR0YWNrZXIgbG9vayBsaWtl IGEgYmV0dGVyIHN0cmF0ZWd5Lg0KPiA+DQo+IA0KPiANCj4gVGhpcyBpcyBhIGdvb2QgcG9pbnQu IEhvdyBhYm91dC4NCj4gDQo+IE9MRDoNCj4gDQo+ICAgIFRoZSBkb2N1bWVudHMgcHJvcG9zaW5n IHRoZSBPQU0gc29sdXRpb24gZm9yIFNGIGNvbXBvbmVudCBzaG91bGQNCj4gICAgY29uc2lkZXIg cmF0ZS1saW1pdGluZyB0aGUgT0FNIHByb2JlcyBhdCBhIGZyZXF1ZW5jeSBndWlkZWQgYnkgdGhl DQo+ICAgIGltcGxlbWVudGF0aW9uIGNob2ljZS4gIFJhdGUtbGltaXRpbmcgbWF5IGJlIGFwcGxp ZWQgYXQgdGhlIFNGRiBvcg0KPiAgICB0aGUgU0YgLiBUaGUgT0FNIGluaXRpYXRvciBtYXkgbm90 IHJlY2VpdmUgYSByZXNwb25zZSBmb3IgdGhlIHByb2Jlcw0KPiAgICB0aGF0IGFyZSByYXRlLWxp bWl0ZWQgcmVzdWx0aW5nIGluIGZhbHNlIG5lZ2F0aXZlcyBhbmQgdGhlDQo+ICAgIGltcGxlbWVu dGF0aW9uIHNob3VsZCBiZSBhd2FyZSBvZiB0aGlzLg0KPiANCj4gDQo+IE5FVzoNCj4gDQo+IA0K PiAgICBUaGUgZG9jdW1lbnRzIHByb3Bvc2luZyB0aGUgT0FNIHNvbHV0aW9uIGZvciBTRiBjb21w b25lbnQgc2hvdWxkDQo+ICAgIGNvbnNpZGVyIHJhdGUtbGltaXRpbmcgdGhlIE9BTSBwcm9iZXMg YXQgYSBmcmVxdWVuY3kgZ3VpZGVkIGJ5IHRoZQ0KPiAgICBpbXBsZW1lbnRhdGlvbiBjaG9pY2Uu ICBSYXRlLWxpbWl0aW5nIG1heSBiZSBhcHBsaWVkIGF0IHRoZSBTRkYgb3INCj4gICAgdGhlIFNG LiAgVGhlIE9BTSBpbml0aWF0b3IgbWF5IG5vdCByZWNlaXZlIGEgcmVzcG9uc2UgZm9yIHRoZSBw cm9iZXMNCj4gICAgdGhhdCBhcmUgcmF0ZS1saW1pdGVkIHJlc3VsdGluZyBpbiBmYWxzZSBuZWdh dGl2ZXMgYW5kIHRoZQ0KPiAgICBpbXBsZW1lbnRhdGlvbiBzaG91bGQgYmUgYXdhcmUgb2YgdGhp cy4gVG8gbWl0aWdhdGUgYW55IGF0dGFja3MgdGhhdA0KPiAgICBMZXZlcmFnZSBPQU0gcGFja2V0 cywgZnV0dXJlIGRvY3VtZW50cyBwcm9wb3NpbmcgT0FNIHNvbHV0aW9ucw0KPiAgICBzaG91bGQg ZGVzY3JpYmUgdGhlIHVzZSBvZiBhbnkgdGVjaG5pcXVlcyB0byBkZXRlY3QNCj4gICAgYW5kIG1p dGlnYXRlIGFub21hbGllcyBhbmQgdmFyaW91cyBzZWN1cml0eSAgYXR0YWNrcy4NCg0KV29ya3Mg Zm9yIG1lLg0KDQpDaGVlcnMsDQotVGlydQ0KDQo+IA0KPiANCj4gV291bGQgdGhhdCB3b3JrPw0K PiANCj4gUGxlYXNlIGZlZWwgZnJlZSB0byBzdWdnZXN0IHRleHR1YWwgaW1wcm92ZW1lbnRzIG9y IGNoYW5nZXMuDQo+IA0KPiBUaGFua3MsDQo+IA0KPiBDYXJsb3MuDQo+IA0KPiA+IENoZWVycywN Cj4gPiAtVGlydQ0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+ID4gc2ZjIG1haWxpbmcgbGlzdA0KPiA+IHNmY0BpZXRmLm9yZw0KPiA+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQoNCg== From nobody Sun Apr 26 05:53:06 2020 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 B056E3A14E2; Sun, 26 Apr 2020 05:52:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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=XBZJ9ryS; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=vqM6pEsU 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 HGMggvFTqg7J; Sun, 26 Apr 2020 05:52:45 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D269C3A0C8D; Sun, 26 Apr 2020 05:52:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7250; q=dns/txt; s=iport; t=1587905565; x=1589115165; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=y8iqQJKqsv6t3StqtaLa4N5d5dRDvV6lFbr3wKC3d74=; b=XBZJ9rySg8GG5I3cG6CPheWw0Mj3gpPsI4fbyTsO06j15Ay/yHk4IwY+ tkStSFzjR8PDxxrQZCK3nyrwJQ5NWiHPABj5Qkw2oxwc6wyfuteCtaUj8 aKIck5K6vvDDtob/ivYKzSjOpu5jzSp1e5Oj5kzGiQT+A5UWHp8G2ex8X k=; IronPort-PHdr: =?us-ascii?q?9a23=3AXvS5/ROp0IJCi6/Shwkl6mtXPHoupqn0MwgJ65?= =?us-ascii?q?Eul7NJdOG58o//OFDEu6w/l0fHCIPc7f8My/HbtaztQyQh2d6AqzhDFf4ETB?= =?us-ascii?q?oZkYMTlg0kDtSCDBjwNP/laSUmFexJVURu+DewNk0GUMs=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ArAADPg6Ve/4gNJK1mGgEBAQEBAQE?= =?us-ascii?q?BAQMBAQEBEQEBAQICAQEBATyBNgIBAQEBCwGBU1EFbFggBAsqCoQVg0YDinK?= =?us-ascii?q?COiWYL4FCgRADVAsBAQEMAQEYCwoCBAEBhEQCF4IPJDcGDgIDAQELAQEFAQE?= =?us-ascii?q?BAgEFBG2FKgclDIVxAQEBAQIBAQEQEREMAQErAQsBBAcEAgEGAhEEAQEDAiY?= =?us-ascii?q?CAgIlCxUICAEBBA4FGweDBAGCSwMOIAEOlQWQZwKBOYgsNXaBMoMAAQEFhSU?= =?us-ascii?q?Ygg4DBoEOKgGCYocOgSCBLBqBQT+BEScMEIFPfj6CZwEBgSYKAQsHASABBzE?= =?us-ascii?q?Cglgygi2OK4MQiQqHZo97CoJFmAAdgluIV4wlhSSpPYNDAgQCBAUCDgEBBYF?= =?us-ascii?q?oI2ZwcBU7KgGCPj4SGA2PXoFWDBeDT4UUhUJ0NQIGAQcBAQMJfItbgTUBMF8?= =?us-ascii?q?BAQ?= X-IronPort-AV: E=Sophos;i="5.73,320,1583193600"; d="scan'208";a="760279099" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 26 Apr 2020 12:52:43 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by alln-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 03QCqg9N023217 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 26 Apr 2020 12:52:43 GMT Received: from xhs-aln-001.cisco.com (173.37.135.118) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Sun, 26 Apr 2020 07:52:42 -0500 Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Sun, 26 Apr 2020 07:52:42 -0500 Received: from NAM12-MW2-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Sun, 26 Apr 2020 07:52:41 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dDb0ivechm1ioFtFg9qzXsc/kQcYgVymgCJNRZNaKhGRUkizH0Gen4rVyWupBBmm7a0jF4FDn2yS4I2LM18uE6v+UJ/SCyf8PbA5Kawb0g1Yhf4lTdBGx1tTHNVXxA4NgOcDN+Zm20LzOvjbts07xGp+vBHJhezql5ZrrYejtDioqeZ/t5GkNlHIO18nJV3bhRuUDdU71C+71+hcLFb5nSAgiz9kekm2ylcAj6oCkm8fs8gEoN0GMH3kMODylyQnQnd2x39ATTHie0+4/w5teG6GG2LVIOV5Dj6gqivvqYYO/ZboQppSpyAl1beeliiEteWIhhAw7TYjQVsumXXYmQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=y8iqQJKqsv6t3StqtaLa4N5d5dRDvV6lFbr3wKC3d74=; b=CtLPDC7tJzVHnOFxlO8t6V7TXJExUeug1gyJwBrSjaiu182Csvj4QKA09UIkB9Pas+7Vhacu9S/MKbK+f77WSnACQS4U5+rVs205+8ltcMRx+tlYMFsJk+TJdXiVzsRnLT51LRKvq51A9UyQLKT9+2hsXmsOedY8v0XNSC+R2xVWhm6BuNZPVFfYEnpgigVxct/7dH96ReFxoPgdOc1Los3vimw2n7hx3wz/YGpCGozA3fFQ+n7CZAz/r0XtmRTqYgR9TDJDB5GjwQbGGiWJwMdfQsXhYfq77RLsfZ8se1D5oybdN0/oECfZGcl8eOwtTQpGknzT+AdZ/KCT5FkPVg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=y8iqQJKqsv6t3StqtaLa4N5d5dRDvV6lFbr3wKC3d74=; b=vqM6pEsUqvyYh/9gi/UcJLhT11Fmz8qiYoO4pNZn/XuNDgqj1DggkwNbm8gLElEV9sznntV0o6obc5z5wB37R9okMmNT5iKAEloctdTqb9o7b+prgoRdptBQyyGyoLqI+H+zbRKHrT4xDIKCxSvioGAEv9ocrhwac8pMHUgVCA4= Received: from BN8PR11MB3635.namprd11.prod.outlook.com (2603:10b6:408:86::20) by BN8PR11MB3634.namprd11.prod.outlook.com (2603:10b6:408:88::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.22; Sun, 26 Apr 2020 12:52:39 +0000 Received: from BN8PR11MB3635.namprd11.prod.outlook.com ([fe80::9981:86d4:ca20:ff96]) by BN8PR11MB3635.namprd11.prod.outlook.com ([fe80::9981:86d4:ca20:ff96%7]) with mapi id 15.20.2937.020; Sun, 26 Apr 2020 12:52:39 +0000 From: "Carlos Pignataro (cpignata)" To: "Konda, Tirumaleswar Reddy" CC: "secdir@ietf.org" , "sfc@ietf.org" , "draft-ietf-sfc-ioam-nsh.all@ietf.org" Thread-Topic: [sfc] Secdir last call review of draft-ietf-sfc-oam-framework Thread-Index: AdYW4VRPPDX1YR3aSqa2kbIsbH1DggD1H5cAADlwdwAAC36JgA== Date: Sun, 26 Apr 2020 12:52:38 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3608.80.23.2.2) authentication-results: spf=none (sender IP is ) smtp.mailfrom=cpignata@cisco.com; x-originating-ip: [108.203.7.63] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 21d40610-8f45-47bf-ea97-08d7e9e0b386 x-ms-traffictypediagnostic: BN8PR11MB3634: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 03853D523D x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN8PR11MB3635.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(346002)(39860400002)(396003)(136003)(376002)(366004)(6916009)(86362001)(33656002)(6486002)(966005)(8936002)(8676002)(2906002)(81156014)(71200400001)(36756003)(54906003)(2616005)(76116006)(66446008)(64756008)(186003)(26005)(6506007)(5660300002)(478600001)(6512007)(4326008)(53546011)(316002)(66476007)(66556008)(66946007); DIR:OUT; SFP:1101; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: F2u1Gn6UW7tWqKebMIM93f1YQWs6oW9YVQc7Lx+ljlMsEMTWIwbYqTPaQ51S+0DnqARLZOBWaFceMOPoDGduTjybKnuDsE6ZzKT8+IiOLli6MmAzsUEygmJRNidZhGvzDlfoHkV94fJQT5Pl5M7qAluU18l18FJazqmy0yKjeIW8Wy5XsB1PukQ+QEzI0uYV65gI5q62g7UbdsFfLemhJv7E/dUYdl+5ziN/1dovK6gDOzlIlmlswNtStj7cUVFaje0zhJEE3ca0Sp7A0JBYuN0EKmF5LAnCRa9CrHCnuzDCxM1UWukWk8zvB4xV/pQx8fmMd8eKOCNMRfH1c2e4Dvt0f6XXpD4lHD14andx5S2uULYJN8szNopDp/IkdHG8mfhw0msBJMs0uuH89G7PUTsZ/ixxoLZYN0B5TViYuRqPVtD/TtS3H+vwOQm39lY5ngP3G7Yqntbj56uQG1lX89ASatWHcuiRcMI8Snw11jvFoD7+pLoQri+R5f2SUvOzFgWTFnu6592NjrEGBFKBZQ== x-ms-exchange-antispam-messagedata: avLrqziYfuEWnQFvxz+Urk7SesmAdgok8Ln9EBIn0r1HWRWMygTGNzSSO1yCyeRi6v4uyrchPlOPf99Bud54nysoGLw+//fCP5lee17vcBJ08GfxWk/cx/LyACdahochzdBpQqVwA6YikNNdI4k8S+TewIniKxduuTlWv0IzBM7jwnlzZiLKMpS4HYNeavYRPSKd36uJX8SPqMkN1MnF5EztbGkLokrsfAsR1kmBoLJ2/Z1wzYHIi/yb0dSedyGdmMSqIYE21zOQXK10ZxFFKKjD4ei0jVOYEAs/swNRyJ0s+kW/Qf20+ffnYr7nnmQjWfQLhU23WrJAKq9DZlnXL0j3qkPvgJgrjBKp8nSu2n7Xg05rTz01JDS2lkkxzYnM19jKUu+A1yNfBKLZRqKB6SQ63Ywp8KV9+E2nOEe8UckcpsM7hk6bFHEeWCXr2bi9whS816R+yzXUYT7lSh5++HFJXsAn6BTk9z/KjktZDL28xk4JFf6q/YBSf97LFw6XWS8CZLtkeWupYviUUYIzKR+8nlMVZlVBe4Nx9gmJ2NeBdad0OL/+ramZ93mBJ/BQjnmbf16m0a1YiLjQSFMU1h0u+NKkCSf+NAA+hGf8i4ZntoNXSkVq6Ua2Y+E9hZfLJXB44LpAWUg8/ZYeuprbOVxBlt9fEHQLwsV1DFdwAvh0sabneaRfFd5AdBngD3+hPndkKaRhrWyO/EHsZVvl0Qajb4LdA+W1oziKaGyX+lk87WFOcHMBNz9TB3h3BIX8PCxGj6yrbP/O32GWTpeamZgak5UErEt17+MHWeNxxGs= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <8C2FBE49E77CB74A926ABA3E1B861BEE@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 21d40610-8f45-47bf-ea97-08d7e9e0b386 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Apr 2020 12:52:38.8005 (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-CrossTenant-userprincipalname: tDLBwXEkWeea8D77GMx/4+Y3jbG1DbBzPvWBfV3moxYRUgdqpxxhD0DqTjIXsYI7x4aToxsLinpgh3tGRWEYVA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8PR11MB3634 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.12, xch-aln-002.cisco.com X-Outbound-Node: alln-core-3.cisco.com Archived-At: Subject: Re: [secdir] [sfc] Secdir last call review of draft-ietf-sfc-oam-framework 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, 26 Apr 2020 12:52:48 -0000 SGksIFRpcnUsDQoNCkkgdGhpbmsgd2UgYXJlIG9uIHRoZSBzYW1lIHBhZ2Ug4oCUIHNlZSBpbmxp bmUuDQoNCj4gMjAyMC8wNC8yNiDljYjliY0zOjIz44CBS29uZGEsIFRpcnVtYWxlc3dhciBSZWRk eSA8VGlydW1hbGVzd2FyUmVkZHlfS29uZGFATWNBZmVlLmNvbT7jga7jg6Hjg7zjg6s6DQo+IA0K PiBIaSBDYXJsb3MsDQo+IA0KPiBQbGVhc2Ugc2VlIGlubGluZSANCj4gDQo+PiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KPj4gRnJvbTogQ2FybG9zIFBpZ25hdGFybyAoY3BpZ25hdGEpIDxj cGlnbmF0YUBjaXNjby5jb20+DQo+PiBTZW50OiBTYXR1cmRheSwgQXByaWwgMjUsIDIwMjAgOToy OSBBTQ0KPj4gVG86IEtvbmRhLCBUaXJ1bWFsZXN3YXIgUmVkZHkgPFRpcnVtYWxlc3dhclJlZGR5 X0tvbmRhQE1jQWZlZS5jb20+DQo+PiBDYzogc2VjZGlyQGlldGYub3JnOyBzZmNAaWV0Zi5vcmc7 IGRyYWZ0LWlldGYtc2ZjLWlvYW0tbnNoLmFsbEBpZXRmLm9yZw0KPj4gU3ViamVjdDogUmU6IFtz ZmNdIFNlY2RpciBsYXN0IGNhbGwgcmV2aWV3IG9mIGRyYWZ0LWlldGYtc2ZjLW9hbS1mcmFtZXdv cmsNCj4+IA0KPj4gQ0FVVElPTjogRXh0ZXJuYWwgZW1haWwuIERvIG5vdCBjbGljayBsaW5rcyBv ciBvcGVuIGF0dGFjaG1lbnRzIHVubGVzcyB5b3UNCj4+IHJlY29nbml6ZSB0aGUgc2VuZGVyIGFu ZCBrbm93IHRoZSBjb250ZW50IGlzIHNhZmUuDQo+PiANCj4+IEhpLCBUaXJ1LA0KPj4gDQo+PiBN YW55IHRoYW5rcyBmb3IgdGhlIHJldmlldywgYW5kIGdyZWF0IHRvIGhlYXIgZnJvbSB5b3UhDQo+ PiANCj4+IEkgaG9wZSBhbGwgaXMgd2VsbCDigJQgUGxlYXNlIHNlZSBpbmxpbmUuDQo+IA0KPiBU aGFua3MsIEnigJltIGZpbmUsIGFuZCBJIGhvcGUgYWxsIGlzIHdlbGwgd2l0aCB5b3UgdG9vLg0K DQo6LSkNCg0KPiANCj4+IA0KPj4+IDIwMjAvMDQvMjAg5Y2I5YmNMzoyOOOAgUtvbmRhLCBUaXJ1 bWFsZXN3YXIgUmVkZHkNCj4+IDxUaXJ1bWFsZXN3YXJSZWRkeV9Lb25kYUBNY0FmZWUuY29tPuOB ruODoeODvOODqzoNCj4+PiANCj4+PiBSZXZpZXdlcjogVGlydW1hbGVzd2FyIFJlZGR5DQo+Pj4g UmV2aWV3IHJlc3VsdDogUmVhZHkgd2l0aCBpc3N1ZXMNCj4+PiANCj4+PiANCj4+PiBJIHJldmll d2VkIHRoaXMgZG9jdW1lbnQgYXMgcGFydCBvZiB0aGUgc2VjdXJpdHkgZGlyZWN0b3JhdGUncyBv bmdvaW5nDQo+Pj4gZWZmb3J0IHRvIHJldmlldyBhbGwgSUVURiBkb2N1bWVudHMgZW50ZXJpbmcg dGhlIElFU0cuLiAgVGhlc2UgY29tbWVudHMNCj4+IGFyZSBkaXJlY3RlZCBhdCB0aGUgc2VjdXJp dHkgYXJlYSBkaXJlY3RvcihzKS4gIERvY3VtZW50IGVkaXRvcnMgYW5kIFdHDQo+PiBjaGFpcnMg c2hvdWxkIHRyZWF0IHRoZXNlIGNvbW1lbnRzIGxpa2UgYW55IG90aGVyIGxhc3QgY2FsbCBjb21t ZW50cy4NCj4+PiANCj4+PiBUaGlzIGRvY3VtZW50IHByb3ZpZGVzIGEgcmVmZXJlbmNlIGZyYW1l d29yayBmb3IgT0FNIGZvciBTRkMuDQo+Pj4gDQo+Pj4gQ29tbWVudHM6DQo+Pj4gDQo+Pj4gMS4g VGhlIGRvY3VtZW50IGluIFNlY3Rpb24gOCBkaXNjdXNzZXMgdmFyaW91cyBhdHRhY2tzIChpbmNs dWRpbmcgYm90aA0KPj4+IHNlY3VyaXR5IGFuZCBwcml2YWN5KSBidXQgZG9lcyBub3QgZGlzY3Vz cyBhbnkgcHJvdGVjdGlvbiBtZWNoYW5pc21zDQo+PiBvdGhlciB0aGFuIHByb3Bvc2luZyByYXRl LWxpbWl0aW5nLiAgSXQgaXMgc3VnZ2VzdGluZyBkcmFmdHMgcHJvcG9zaW5nIHRoZSBPQU0NCj4+ IHNvbHV0aW9uIHNob3VsZCBhZGRyZXNzIHRoZSBhdHRhY2tzIGJ1dCBJIGRvbuKAmXQgc2VlIGFu eSBzZWN1cml0eSBtZWNoYW5pc21zDQo+PiBkaXNjdXNzZWQgaW4gZHJhZnQtaWV0Zi1zZmMtaW9h bS1uc2ggdG8gYWRkcmVzcyB0aGUgYXR0YWNrcy4NCj4+PiANCj4+IA0KPj4gU2luY2UgdGhlIGRv Y3VtZW50IGFscmVhZHkgY2xhcmlmaWVzIHRoYXQgaXQgZG9lcyBub3QgZGVmaW5lIHNvbHV0aW9u cywgaXQNCj4+IGNhbm5vdCBkZWZpbmUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbiBmb3IgdGhvc2Ug c29sdXRpb25zLCBiZXlvbmQgc2F5aW5nIHRoYXQNCj4+IHRob3NlIHNvbHV0aW9ucyBvdWdodCB0 byBhZGRyZXNzIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIGluIHRob3NlIGFyZWFzLiBBbnkNCj4+ IHNlY3VyaXR5IG1lYXN1cmVzIG11c3QgYmUgaW5jbHVkZWQgYW5kIGV4cGxhaW5lZCBpbiB0aGUg cmVzcGVjdGl2ZSBzb2x1dGlvbg0KPj4gZG9jdW1lbnQuIEkgYmVsaWV2ZSB0aGlzIGNvbW1lbnQg cmVxdWlyZXMgcG90ZW50aWFsbHkgYWN0aW9uIG9uIGRyYWZ0LWlldGYtDQo+PiBzZmMtaW9hbS1u c2ggYnV0IG5vdCBvbiB0aGlzIGRyYWZ0Lg0KPiANCj4gWXVwLiBJIHNlZSB0aHJlZSBzb2x1dGlv bnMgZnJvbSBTRkMgV0cgYSkgc2ZjLWlvYW0tbnNoIGIpIGlldGYtc2ZjLXByb29mLW9mLXRyYW5z aXQgKEV4cGVyaW1lbnRhbCkgYykgcGVubm8tc2ZjLXRyYWNlIChFeHBpcmVkKS4gc2ZjLWlvYW0t bnNoIGlzIHRoZSBvbmx5IGN1cnJlbnQgc3RhbmRhcmRzIHRyYWNrIHNwZWNpZmljYXRpb24gYW5k IGl0IHNob3VsZCBhZGRyZXNzIHRoZXNlIGF0dGFja3MuDQoNCkFncmVlZC4NCg0KQ2hlY2tpbmcg ZHJhZnQtaWV0Zi1zZmMtaW9hbS1uc2gsIGl0IGRvZXMgbm90IGhhdmUgYSBwb2ludGVyIHRvIGRy YWZ0LWlldGYtc2ZjLW9hbS1mcmFtZXdvcmsuIEkgYmVsaWV2ZSBhIFJlZmVyZW5jZSBzaG91bGQg YmUgYWRkZWQsIHdpdGggYSBjaXRhdGlvbiBjYXB0dXJpbmcgeW91ciBjb21tZW50Lg0KDQoNCj4g DQo+PiANCj4+IFRoYXQgc2FpZCB5b3UgYXJlIHJpZ2h0IHJlZ2FyZGluZyB0aGUgc3BlY2lmaWNz IG9mIHRoZSByYXRlLWxpbWluZw0KPj4gcmVjb21tZW5kYXRpb24uIFNlZSB0aGUgbmV4dCBhbnN3 ZXIgZm9yIHRleHQuDQo+PiANCj4+IEFsc28sIGluIHJlLXJlYWRpbmcgU2VjdGlvbiA4LCBzZWVt cyBsaWtlIHRoaXM6DQo+PiANCj4+ICAgVG8gYWRkcmVzcyB0aGUgYWJvdmUgY29uY2VybnMsIFNG QyBhbmQgU0YgT0FNIG1heSBwcm92aWRlIG1lY2hhbmlzbQ0KPj4gICBmb3I6DQo+PiANCj4+IA0K Pj4gU2hvdWxkIHNheQ0KPj4gDQo+PiAgIFRvIGFkZHJlc3MgdGhlIGFib3ZlIGNvbmNlcm5zLCBT RkMgYW5kIFNGIE9BTSBzaG91bGQgcHJvdmlkZQ0KPj4gbWVjaGFuaXNtcw0KPj4gICBmb3IgcHJl dmVudGluZzoNCj4gDQo+IFllcy4NCg0KV2lsbCBtYWtlIHRoaXMgY2hhbmdlLg0KDQo+IA0KPj4g DQo+PiANCj4+IA0KPj4+IDIuIE1vcmUgZGlzY3Vzc2lvbiBpcyByZXF1aXJlZCBvbiB0aGUgaW50 ZXJuYWwgYXR0YWNrcy4NCj4+PiAoYSkgSG93IGFyZSBhdHRhY2sgcGFja2V0cyBieXBhc3Npbmcg U0ZDIGRldGVjdGVkIGFuZCBibG9ja2VkID8NCj4+PiAoYikgSG93IGlzIHNlbnNpdGl2ZSBpbmZv cm1hdGlvbiBwcm90ZWN0ZWQgZnJvbSBlYXZlc2Ryb3BwZXJzID8NCj4+PiAoYykgSG93IGlzIERv Uy9ERG9TIGF0dGFjayBvZiBtaXN1c2luZyB0aGUgT0FNIGNoYW5uZWwgaXMgbWl0aWdhdGVkID8N Cj4+PiAoZCkgUmF0ZS1saW1pdGluZyBibG9ja3MgYm90aCBnb29kIGFuZCBiYWQgT0FNIHByb2Jl cyBhbmQgaXMgYSB3ZWFrDQo+PiBtaXRpZ2F0aW9uIHN0cmF0ZWd5LiBBbm9tYWx5IGRldGVjdGlv biAoZS5nLiwgZGVlcCBsZWFybmluZyB0ZWNoaW5xdWVzKSBhbmQNCj4+IGlkZW50aWZ5aW5nIHRo ZSBhdHRhY2tlciBsb29rIGxpa2UgYSBiZXR0ZXIgc3RyYXRlZ3kuDQo+Pj4gDQo+PiANCj4+IA0K Pj4gVGhpcyBpcyBhIGdvb2QgcG9pbnQuIEhvdyBhYm91dC4NCj4+IA0KPj4gT0xEOg0KPj4gDQo+ PiAgIFRoZSBkb2N1bWVudHMgcHJvcG9zaW5nIHRoZSBPQU0gc29sdXRpb24gZm9yIFNGIGNvbXBv bmVudCBzaG91bGQNCj4+ICAgY29uc2lkZXIgcmF0ZS1saW1pdGluZyB0aGUgT0FNIHByb2JlcyBh dCBhIGZyZXF1ZW5jeSBndWlkZWQgYnkgdGhlDQo+PiAgIGltcGxlbWVudGF0aW9uIGNob2ljZS4g IFJhdGUtbGltaXRpbmcgbWF5IGJlIGFwcGxpZWQgYXQgdGhlIFNGRiBvcg0KPj4gICB0aGUgU0Yg LiBUaGUgT0FNIGluaXRpYXRvciBtYXkgbm90IHJlY2VpdmUgYSByZXNwb25zZSBmb3IgdGhlIHBy b2Jlcw0KPj4gICB0aGF0IGFyZSByYXRlLWxpbWl0ZWQgcmVzdWx0aW5nIGluIGZhbHNlIG5lZ2F0 aXZlcyBhbmQgdGhlDQo+PiAgIGltcGxlbWVudGF0aW9uIHNob3VsZCBiZSBhd2FyZSBvZiB0aGlz Lg0KPj4gDQo+PiANCj4+IE5FVzoNCj4+IA0KPj4gDQo+PiAgIFRoZSBkb2N1bWVudHMgcHJvcG9z aW5nIHRoZSBPQU0gc29sdXRpb24gZm9yIFNGIGNvbXBvbmVudCBzaG91bGQNCj4+ICAgY29uc2lk ZXIgcmF0ZS1saW1pdGluZyB0aGUgT0FNIHByb2JlcyBhdCBhIGZyZXF1ZW5jeSBndWlkZWQgYnkg dGhlDQo+PiAgIGltcGxlbWVudGF0aW9uIGNob2ljZS4gIFJhdGUtbGltaXRpbmcgbWF5IGJlIGFw cGxpZWQgYXQgdGhlIFNGRiBvcg0KPj4gICB0aGUgU0YuICBUaGUgT0FNIGluaXRpYXRvciBtYXkg bm90IHJlY2VpdmUgYSByZXNwb25zZSBmb3IgdGhlIHByb2Jlcw0KPj4gICB0aGF0IGFyZSByYXRl LWxpbWl0ZWQgcmVzdWx0aW5nIGluIGZhbHNlIG5lZ2F0aXZlcyBhbmQgdGhlDQo+PiAgIGltcGxl bWVudGF0aW9uIHNob3VsZCBiZSBhd2FyZSBvZiB0aGlzLiBUbyBtaXRpZ2F0ZSBhbnkgYXR0YWNr cyB0aGF0DQo+PiAgIExldmVyYWdlIE9BTSBwYWNrZXRzLCBmdXR1cmUgZG9jdW1lbnRzIHByb3Bv c2luZyBPQU0gc29sdXRpb25zDQo+PiAgIHNob3VsZCBkZXNjcmliZSB0aGUgdXNlIG9mIGFueSB0 ZWNobmlxdWVzIHRvIGRldGVjdA0KPj4gICBhbmQgbWl0aWdhdGUgYW5vbWFsaWVzIGFuZCB2YXJp b3VzIHNlY3VyaXR5ICBhdHRhY2tzLg0KPiANCj4gV29ya3MgZm9yIG1lLg0KPiANCg0KR3JlYXQu IFdlIHdpbGwgbWFrZSB0aGlzIGNoYW5nZSBhcyB3ZWxsLg0KDQpUaGFua3MhDQoNCkNhcmxvcy4N Cg0KPiBDaGVlcnMsDQo+IC1UaXJ1DQo+IA0KPj4gDQo+PiANCj4+IFdvdWxkIHRoYXQgd29yaz8N Cj4+IA0KPj4gUGxlYXNlIGZlZWwgZnJlZSB0byBzdWdnZXN0IHRleHR1YWwgaW1wcm92ZW1lbnRz IG9yIGNoYW5nZXMuDQo+PiANCj4+IFRoYW5rcywNCj4+IA0KPj4gQ2FybG9zLg0KPj4gDQo+Pj4g Q2hlZXJzLA0KPj4+IC1UaXJ1DQo+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4+PiBzZmMgbWFpbGluZyBsaXN0DQo+Pj4gc2ZjQGlldGYub3JnDQo+ Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4gDQoNCg== From nobody Mon Apr 27 07:35:56 2020 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 E8E733A0BF0; Mon, 27 Apr 2020 07:35:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.198 X-Spam-Level: X-Spam-Status: No, score=-8.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_COMMENT_SAVED_URL=1.391, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_HTML_ATTACH=0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=IF0d63ig; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=XlRZ0eta 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 E6uIb3Y2sQh0; Mon, 27 Apr 2020 07:35:47 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 331453A0B72; Mon, 27 Apr 2020 07:35:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=130382; q=dns/txt; s=iport; t=1587998147; x=1589207747; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=3wm/+k0zjSVm2qOnYrRKii57WX/XiZgAkPfuoz5IVTs=; b=IF0d63iguWPHI+PErO23d2akWPvxlwXljaYAJtXc4yJSP9UDbg77BhJ2 hvCEBVT0kMtvtZByTgynGcJub5aFvTdvQYazgWg7CfmLTE8SuQQogpkYG d+VCuSkSk2HFjh7aqi3HA8wWrvhMY18PTXGYD7abFVKH1E3Je4vwabsU4 M=; X-Files: Diff_ draft-ietf-sfc-oam-framework-13.txt - draft-ietf-sfc-oam-framework-14.txt.html, draft-ietf-sfc-oam-framework-14.txt : 40725, 47705 IronPort-PHdr: =?us-ascii?q?9a23=3AJqtlvxaHW5W0p204PtjI1nX/LSx94ef9IxIV55?= =?us-ascii?q?w7irlHbqWk+dH4MVfC4el20gabRp3VvvRDjeee87vtX2AN+96giDgDa9QNMn?= =?us-ascii?q?1NksAKh0olCc+BB1f8KavsZi05AcFLTndu/mqwNg5eH8OtL1A=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DUAAB77KZe/4MNJK1mGgEBAQEBAQE?= =?us-ascii?q?BAQMBAQEBEQEBAQICAQEBAYIDgVQkBSgFbBNFIAQLKgqEFYFdgWkDinGCOiU?= =?us-ascii?q?MdYc7gTqOOYFCgRADUAQEBwEBAQwBARgBCgoCBAEBgS8BgV4bgRsCF4IRJDg?= =?us-ascii?q?TAgMBAQsBAQUBAQECAQUEbYUqByUMhXEBAQEBAgEBARAIAQgEBhMBASsBBgU?= =?us-ascii?q?BCwQCAQYCEQEDAQEWCwEJAgICHwYLFwYIAQEEAQ0FDg0HgwQBgksDDiABDpZ?= =?us-ascii?q?FkGcCgTmILDV2fzODAAEBBYUlDQuCBwcJgTiCY4cOgSCBLBqCAIEQAScMEIF?= =?us-ascii?q?PSTU+gXsjPgsBAQIBGYECCAIIAQsBBgEoBxgHCweCUzKCLYQYiXsSBgyDBIY?= =?us-ascii?q?UgTaBQIR8BFmCDYNQiy8ySgqCRYQRg36FdIRTY4I6gg0dglszVIdQh1mETIM?= =?us-ascii?q?tgXePeolIgkWNVIMlAgQCBAUCDgEBBYFpIjYwcHAVOyoBgj4JRxgNj16BMiQ?= =?us-ascii?q?MF4EDAQmCQkGEU4VCcwECMwIGAQcBAQMJfItbAQEmB4EGATBfAQE?= X-IronPort-AV: E=Sophos;i="5.73,324,1583193600"; d="txt'?html'217?scan'217,208,217";a="469614997" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 27 Apr 2020 14:35:45 +0000 Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by alln-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 03REZjF0030966 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 27 Apr 2020 14:35:45 GMT Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 27 Apr 2020 09:35:44 -0500 Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 27 Apr 2020 10:35:44 -0400 Received: from NAM02-BL2-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Mon, 27 Apr 2020 09:35:44 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Dnd+OsPyY+sl6b9LtDMDMlfFQjYIL5TlTlGMIZrRKfgQvQUh+oOull1rIlcU8kN5GnXExVP2dmsh1DWcLDeWO5+8crBjVSZcwQRp1XzHNwho0aAi0/QGGVT3OaY/GQxm7mi1pNFVs6uBCx0v3+a5oUfmrlQk9rwtln2VrlzA6tqkqeuR6QAb0KdiVmpLgoHmHnqBfauKwF2tDxOU6MzKtVoa3UQ1yZY/7tIRRCdaIiFSl4pDjZcB0wcGy4lFi482vQmd+wawjTTU0fC0X7eXeq2Z20umPOmYDy28bao1j6naSms9bo9exrtxldPo1ZljoEwIUTPFZ8eJQmafPE1gJQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=bh8Gl9/hV87eNGTOWP5WbiXhJKz9n9bkiQ86WCKcuBQ=; b=mUQNOfcay1HZYJJIl46XQfLcQciQLYF3/NqaRSbtKzPuHpgBunZck1JySeL7GdPOjdVoZp+JmfB+YLMsGbtR9Gck8d/aa+ZvuZoko//Oow7WnNmIeloRR2hj4xGI12gnQA6fYuAQgUR/OlDiQYlhK5box8DmSDIGZRQfps2XlQOXO0aH2JWZInOCx7R7QsKzX0aW19E1VYXfPyRSJ0YCdulpqIY1qZECBtDA46E3zt0feWtzbUoIGs3ufx5GmLOC2v9TmFCoWDd5fYY2xD76XW62cLKn159qjkQKKynSgBkuwJVULK/93R4Ieu0KxkfjMKlJDgMfWamHGWmsZB2+Aw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=bh8Gl9/hV87eNGTOWP5WbiXhJKz9n9bkiQ86WCKcuBQ=; b=XlRZ0eta1hf0m18BgekQ/a8yBRAFcFg82S6S5BcHj3aMY/269swn2+nRVvYUYy5px44mySXe52lHFciqC9qhc6HlgoPhRJK/4b+ZbQ/DLxZ8CHOJjVLgLrGOvG86WsBRtEvBim9d6p5SMRomR8pnu6KdKqIGiFzBkQ0GUB4pi48= Received: from BN6PR11MB4068.namprd11.prod.outlook.com (2603:10b6:405:7c::31) by BN6PR11MB0065.namprd11.prod.outlook.com (2603:10b6:405:65::34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.22; Mon, 27 Apr 2020 14:35:42 +0000 Received: from BN6PR11MB4068.namprd11.prod.outlook.com ([fe80::cb:ae2d:1f21:7263]) by BN6PR11MB4068.namprd11.prod.outlook.com ([fe80::cb:ae2d:1f21:7263%4]) with mapi id 15.20.2937.023; Mon, 27 Apr 2020 14:35:42 +0000 From: "Nagendra Kumar Nainar (naikumar)" To: "Konda, Tirumaleswar Reddy" , "Carlos Pignataro (cpignata)" CC: "secdir@ietf.org" , "draft-ietf-sfc-oam-framework@ietf.org" Thread-Topic: [sfc] Secdir last call review of draft-ietf-sfc-oam-framework Thread-Index: AdYW4VRPPDX1YR3aSqa2kbIsbH1DggD1H3GAADj+SVAAOXNWAA== Date: Mon, 27 Apr 2020 14:35:42 +0000 Message-ID: <760DA3B5-3B10-4786-8EC9-B107BFEBAC28@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.35.20030802 authentication-results: spf=none (sender IP is ) smtp.mailfrom=naikumar@cisco.com; x-originating-ip: [173.38.117.67] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 3815d749-383e-48dd-5880-08d7eab84362 x-ms-traffictypediagnostic: BN6PR11MB0065: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 0386B406AA x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN6PR11MB4068.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(136003)(366004)(39860400002)(376002)(346002)(6512007)(2616005)(99936003)(8676002)(86362001)(5660300002)(478600001)(966005)(6636002)(91956017)(36756003)(6486002)(26005)(316002)(53546011)(71200400001)(8936002)(81156014)(33656002)(66576008)(64756008)(66556008)(66476007)(66946007)(66446008)(76116006)(110136005)(4326008)(6506007)(2906002)(54906003)(186003); DIR:OUT; SFP:1101; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 6s4U5SEpoLUSbnTAJtri72Jl8SDuF43mqw7UG55ThFjbhHB6G3nyGjMfSIHVL2cbiZLQtD312BU84Nq5micdlpzYrz5+VKi8Zg8Wb7NzIG+/7C0h0QDu/T96Mi0xy/Gu5Z7QjrjLTvJTaHKQJbrLQ3bfIFLnOzBbZr7b/knCglvJjryExaB9xAh8R+8YJaP+EUDhWuGkv0Gg81b+zmrYhy8ngXEmIUFXIstyZO7jmmilh3MB37KZQavB1DZVDgaPTk37bs17o+RAWdDInUP/R6d0EK6rlzTPOzr63KjrzDbGEB6mFPxwLOdgLaZ9RRPHBt7YkvYFylnkRH1SVtoMtritQfaLEPYBt+IWIs1Zi8tNyDiGAyf//4PcxDiWzUbdrlwzu59iLke8RRjbryGAdi6OMbs16PWFax18w6bFc1WdMYvsmmyxDszPP6e5NzBN/zClrwTdF11dJQqyTOnAwpYJSbLG9wJztNuR7IsAONuaCI/5c9lXQPLRAd3UMashnD6ocTrao29moSXpNZ6kpg== x-ms-exchange-antispam-messagedata: lSSnoI0hz8MuY1qVFr0eW7PNTJkGYcdbgf+zjqeH7sahsg4cpMRZ1DqZ3uXFSjqhjZzYFj8LvMymjvDn03kDR1yje8Q0chCgWtphQfUTjcdGCuQlb+TslBSPQ5J/hjDxemEHHl8IPrmEjxJnvfaJ3Qkad2VrVZi8Nv+E2LdvcuYr/mNAuGRZgsVIOmBX81c8Ms+nN52CBmX+v1Pg+FLgGk3E/RnU5NWp+keyOr7YDnuqYnArpmZas7pvhvl0QnSuhsbQa+u9amWdxuICAiRnwHK3rIooWCi61FjiAdLfRddzH7UYo3+hBeDTZBQC7uSysgQY6KCF2ATdEY9TZ6Oqt2XSYngdn48slBGdFWvnMDUlF6KBIVEGVOKLY1gwZPMcEj9b/WPmMxh4/Zuz/2+vOn5S8I73cNbH7s8zbXWIaWoVUCgeIC+GMOMOaBOLxTjWAURLfyoB78HIbO25MOnYKfI+Lr3PNllWL1XI93c7nUeXLTjNfjgNFMD3lee6OuBkiFa1Z1s6y7Vu/ZKm5v6Ppv0GS9rzRsJ1GTfuYJ6XejldxYSm6GCxEyNo4isAO3ykiu2gqZ6WidsLp9BMKsDo/yfu+lrlEbsQiAKMX9rSn5Ep/cLt36TEDe71MP28yFw95HqGqzrzJdi083J2s3Gyb9yAMMIZDDaUroev8fQAtS5MOgixdBsE6aKEh9M4LSNkUafNauxWv+XtqKeETTySrH5zDqN5YcwE6ZW/NzBRGmDFpbwvmONglHg9Rc1pPpkP2azE96+nRHKWf/c5LVAKu70iWGMiv+ze+Cc2vZmU2rg= Content-Type: multipart/mixed; boundary="_003_760DA3B53B1047868EC9B107BFEBAC28ciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 3815d749-383e-48dd-5880-08d7eab84362 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Apr 2020 14:35:42.0266 (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-CrossTenant-userprincipalname: KTkyl1t7EzJIw6gv/xldRAoApXGe/UH0aQdCuwB885iLh9tYO0Iwk4W2mOB15zmZSXpNotCEikcaZ98Xi4LLxg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR11MB0065 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.14, xch-rcd-004.cisco.com X-Outbound-Node: alln-core-1.cisco.com Archived-At: Subject: Re: [secdir] [sfc] Secdir last call review of draft-ietf-sfc-oam-framework 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, 27 Apr 2020 14:35:53 -0000 --_003_760DA3B53B1047868EC9B107BFEBAC28ciscocom_ Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 SGkgVGlydW1hbGVzd2FyLA0KDQpIb3BlIHlvdSBhcmUgZG9pbmcgZ29vZC4NCg0KVGhhbmsgeW91 IGZvciB0aGUgcmV2aWV3IGFuZCB0aGUgY29tbWVudHMvc3VnZ2VzdGlvbnMuIFBsZWFzZSBmaW5k IHRoZSBkaWZmIGF0dGFjaGVkIHRoYXQgaW5jb3Jwb3JhdGVzIHRoZSBjb21tZW50cy4NCg0KV2Ug d2lsbCBzdWJtaXQgdGhlIG5ldyB2ZXJzaW9uIHdpdGggdGhlIGNoYW5nZXMuIExldCB1cyBrbm93 IGlmIHlvdSBoYXZlIGFueSBmdXJ0aGVyIGNvbW1lbnRzLg0KDQpUaGFua3MsDQpOYWdlbmRyYSAN Cg0K77u/T24gNC8yNi8yMCwgMzoyNCBBTSwgInNmYyBvbiBiZWhhbGYgb2YgS29uZGEsIFRpcnVt YWxlc3dhciBSZWRkeSIgPHNmYy1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBUaXJ1bWFs ZXN3YXJSZWRkeV9Lb25kYUBNY0FmZWUuY29tPiB3cm90ZToNCg0KICAgIEhpIENhcmxvcywNCiAg ICANCiAgICBQbGVhc2Ugc2VlIGlubGluZSANCiAgICANCiAgICA+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQogICAgPiBGcm9tOiBDYXJsb3MgUGlnbmF0YXJvIChjcGlnbmF0YSkgPGNwaWdu YXRhQGNpc2NvLmNvbT4NCiAgICA+IFNlbnQ6IFNhdHVyZGF5LCBBcHJpbCAyNSwgMjAyMCA5OjI5 IEFNDQogICAgPiBUbzogS29uZGEsIFRpcnVtYWxlc3dhciBSZWRkeSA8VGlydW1hbGVzd2FyUmVk ZHlfS29uZGFATWNBZmVlLmNvbT4NCiAgICA+IENjOiBzZWNkaXJAaWV0Zi5vcmc7IHNmY0BpZXRm Lm9yZzsgZHJhZnQtaWV0Zi1zZmMtaW9hbS1uc2guYWxsQGlldGYub3JnDQogICAgPiBTdWJqZWN0 OiBSZTogW3NmY10gU2VjZGlyIGxhc3QgY2FsbCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1zZmMtb2Ft LWZyYW1ld29yaw0KICAgID4gDQogICAgPiBDQVVUSU9OOiBFeHRlcm5hbCBlbWFpbC4gRG8gbm90 IGNsaWNrIGxpbmtzIG9yIG9wZW4gYXR0YWNobWVudHMgdW5sZXNzIHlvdQ0KICAgID4gcmVjb2du aXplIHRoZSBzZW5kZXIgYW5kIGtub3cgdGhlIGNvbnRlbnQgaXMgc2FmZS4NCiAgICA+IA0KICAg ID4gSGksIFRpcnUsDQogICAgPiANCiAgICA+IE1hbnkgdGhhbmtzIGZvciB0aGUgcmV2aWV3LCBh bmQgZ3JlYXQgdG8gaGVhciBmcm9tIHlvdSENCiAgICA+IA0KICAgID4gSSBob3BlIGFsbCBpcyB3 ZWxsIOKAlCBQbGVhc2Ugc2VlIGlubGluZS4NCiAgICANCiAgICBUaGFua3MsIEnigJltIGZpbmUs IGFuZCBJIGhvcGUgYWxsIGlzIHdlbGwgd2l0aCB5b3UgdG9vLg0KICAgIA0KICAgID4gDQogICAg PiA+IDIwMjAvMDQvMjAg5Y2I5YmNMzoyOOOAgUtvbmRhLCBUaXJ1bWFsZXN3YXIgUmVkZHkNCiAg ICA+IDxUaXJ1bWFsZXN3YXJSZWRkeV9Lb25kYUBNY0FmZWUuY29tPuOBruODoeODvOODqzoNCiAg ICA+ID4NCiAgICA+ID4gUmV2aWV3ZXI6IFRpcnVtYWxlc3dhciBSZWRkeQ0KICAgID4gPiBSZXZp ZXcgcmVzdWx0OiBSZWFkeSB3aXRoIGlzc3Vlcw0KICAgID4gPg0KICAgID4gPg0KICAgID4gPiBJ IHJldmlld2VkIHRoaXMgZG9jdW1lbnQgYXMgcGFydCBvZiB0aGUgc2VjdXJpdHkgZGlyZWN0b3Jh dGUncyBvbmdvaW5nDQogICAgPiA+IGVmZm9ydCB0byByZXZpZXcgYWxsIElFVEYgZG9jdW1lbnRz IGVudGVyaW5nIHRoZSBJRVNHLi4gIFRoZXNlIGNvbW1lbnRzDQogICAgPiBhcmUgZGlyZWN0ZWQg YXQgdGhlIHNlY3VyaXR5IGFyZWEgZGlyZWN0b3IocykuICBEb2N1bWVudCBlZGl0b3JzIGFuZCBX Rw0KICAgID4gY2hhaXJzIHNob3VsZCB0cmVhdCB0aGVzZSBjb21tZW50cyBsaWtlIGFueSBvdGhl ciBsYXN0IGNhbGwgY29tbWVudHMuDQogICAgPiA+DQogICAgPiA+IFRoaXMgZG9jdW1lbnQgcHJv dmlkZXMgYSByZWZlcmVuY2UgZnJhbWV3b3JrIGZvciBPQU0gZm9yIFNGQy4NCiAgICA+ID4NCiAg ICA+ID4gQ29tbWVudHM6DQogICAgPiA+DQogICAgPiA+IDEuIFRoZSBkb2N1bWVudCBpbiBTZWN0 aW9uIDggZGlzY3Vzc2VzIHZhcmlvdXMgYXR0YWNrcyAoaW5jbHVkaW5nIGJvdGgNCiAgICA+ID4g c2VjdXJpdHkgYW5kIHByaXZhY3kpIGJ1dCBkb2VzIG5vdCBkaXNjdXNzIGFueSBwcm90ZWN0aW9u IG1lY2hhbmlzbXMNCiAgICA+IG90aGVyIHRoYW4gcHJvcG9zaW5nIHJhdGUtbGltaXRpbmcuICBJ dCBpcyBzdWdnZXN0aW5nIGRyYWZ0cyBwcm9wb3NpbmcgdGhlIE9BTQ0KICAgID4gc29sdXRpb24g c2hvdWxkIGFkZHJlc3MgdGhlIGF0dGFja3MgYnV0IEkgZG9u4oCZdCBzZWUgYW55IHNlY3VyaXR5 IG1lY2hhbmlzbXMNCiAgICA+IGRpc2N1c3NlZCBpbiBkcmFmdC1pZXRmLXNmYy1pb2FtLW5zaCB0 byBhZGRyZXNzIHRoZSBhdHRhY2tzLg0KICAgID4gPg0KICAgID4gDQogICAgPiBTaW5jZSB0aGUg ZG9jdW1lbnQgYWxyZWFkeSBjbGFyaWZpZXMgdGhhdCBpdCBkb2VzIG5vdCBkZWZpbmUgc29sdXRp b25zLCBpdA0KICAgID4gY2Fubm90IGRlZmluZSBzZWN1cml0eSBjb25zaWRlcmF0aW9uIGZvciB0 aG9zZSBzb2x1dGlvbnMsIGJleW9uZCBzYXlpbmcgdGhhdA0KICAgID4gdGhvc2Ugc29sdXRpb25z IG91Z2h0IHRvIGFkZHJlc3Mgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgaW4gdGhvc2UgYXJlYXMu IEFueQ0KICAgID4gc2VjdXJpdHkgbWVhc3VyZXMgbXVzdCBiZSBpbmNsdWRlZCBhbmQgZXhwbGFp bmVkIGluIHRoZSByZXNwZWN0aXZlIHNvbHV0aW9uDQogICAgPiBkb2N1bWVudC4gSSBiZWxpZXZl IHRoaXMgY29tbWVudCByZXF1aXJlcyBwb3RlbnRpYWxseSBhY3Rpb24gb24gZHJhZnQtaWV0Zi0N CiAgICA+IHNmYy1pb2FtLW5zaCBidXQgbm90IG9uIHRoaXMgZHJhZnQuDQogICAgDQogICAgWXVw LiBJIHNlZSB0aHJlZSBzb2x1dGlvbnMgZnJvbSBTRkMgV0cgYSkgc2ZjLWlvYW0tbnNoIGIpIGll dGYtc2ZjLXByb29mLW9mLXRyYW5zaXQgKEV4cGVyaW1lbnRhbCkgYykgcGVubm8tc2ZjLXRyYWNl IChFeHBpcmVkKS4gc2ZjLWlvYW0tbnNoIGlzIHRoZSBvbmx5IGN1cnJlbnQgc3RhbmRhcmRzIHRy YWNrIHNwZWNpZmljYXRpb24gYW5kIGl0IHNob3VsZCBhZGRyZXNzIHRoZXNlIGF0dGFja3MuDQog ICAgIA0KICAgID4gDQogICAgPiBUaGF0IHNhaWQgeW91IGFyZSByaWdodCByZWdhcmRpbmcgdGhl IHNwZWNpZmljcyBvZiB0aGUgcmF0ZS1saW1pbmcNCiAgICA+IHJlY29tbWVuZGF0aW9uLiBTZWUg dGhlIG5leHQgYW5zd2VyIGZvciB0ZXh0Lg0KICAgID4gDQogICAgPiBBbHNvLCBpbiByZS1yZWFk aW5nIFNlY3Rpb24gOCwgc2VlbXMgbGlrZSB0aGlzOg0KICAgID4gDQogICAgPiAgICBUbyBhZGRy ZXNzIHRoZSBhYm92ZSBjb25jZXJucywgU0ZDIGFuZCBTRiBPQU0gbWF5IHByb3ZpZGUgbWVjaGFu aXNtDQogICAgPiAgICBmb3I6DQogICAgPiANCiAgICA+IA0KICAgID4gU2hvdWxkIHNheQ0KICAg ID4gDQogICAgPiAgICBUbyBhZGRyZXNzIHRoZSBhYm92ZSBjb25jZXJucywgU0ZDIGFuZCBTRiBP QU0gc2hvdWxkIHByb3ZpZGUNCiAgICA+IG1lY2hhbmlzbXMNCiAgICA+ICAgIGZvciBwcmV2ZW50 aW5nOg0KICAgIA0KICAgIFllcy4NCiAgICANCiAgICA+IA0KICAgID4gDQogICAgPiANCiAgICA+ ID4gMi4gTW9yZSBkaXNjdXNzaW9uIGlzIHJlcXVpcmVkIG9uIHRoZSBpbnRlcm5hbCBhdHRhY2tz Lg0KICAgID4gPiAoYSkgSG93IGFyZSBhdHRhY2sgcGFja2V0cyBieXBhc3NpbmcgU0ZDIGRldGVj dGVkIGFuZCBibG9ja2VkID8NCiAgICA+ID4gKGIpIEhvdyBpcyBzZW5zaXRpdmUgaW5mb3JtYXRp b24gcHJvdGVjdGVkIGZyb20gZWF2ZXNkcm9wcGVycyA/DQogICAgPiA+IChjKSBIb3cgaXMgRG9T L0REb1MgYXR0YWNrIG9mIG1pc3VzaW5nIHRoZSBPQU0gY2hhbm5lbCBpcyBtaXRpZ2F0ZWQgPw0K ICAgID4gPiAoZCkgUmF0ZS1saW1pdGluZyBibG9ja3MgYm90aCBnb29kIGFuZCBiYWQgT0FNIHBy b2JlcyBhbmQgaXMgYSB3ZWFrDQogICAgPiBtaXRpZ2F0aW9uIHN0cmF0ZWd5LiBBbm9tYWx5IGRl dGVjdGlvbiAoZS5nLiwgZGVlcCBsZWFybmluZyB0ZWNoaW5xdWVzKSBhbmQNCiAgICA+IGlkZW50 aWZ5aW5nIHRoZSBhdHRhY2tlciBsb29rIGxpa2UgYSBiZXR0ZXIgc3RyYXRlZ3kuDQogICAgPiA+ DQogICAgPiANCiAgICA+IA0KICAgID4gVGhpcyBpcyBhIGdvb2QgcG9pbnQuIEhvdyBhYm91dC4N CiAgICA+IA0KICAgID4gT0xEOg0KICAgID4gDQogICAgPiAgICBUaGUgZG9jdW1lbnRzIHByb3Bv c2luZyB0aGUgT0FNIHNvbHV0aW9uIGZvciBTRiBjb21wb25lbnQgc2hvdWxkDQogICAgPiAgICBj b25zaWRlciByYXRlLWxpbWl0aW5nIHRoZSBPQU0gcHJvYmVzIGF0IGEgZnJlcXVlbmN5IGd1aWRl ZCBieSB0aGUNCiAgICA+ICAgIGltcGxlbWVudGF0aW9uIGNob2ljZS4gIFJhdGUtbGltaXRpbmcg bWF5IGJlIGFwcGxpZWQgYXQgdGhlIFNGRiBvcg0KICAgID4gICAgdGhlIFNGIC4gVGhlIE9BTSBp bml0aWF0b3IgbWF5IG5vdCByZWNlaXZlIGEgcmVzcG9uc2UgZm9yIHRoZSBwcm9iZXMNCiAgICA+ ICAgIHRoYXQgYXJlIHJhdGUtbGltaXRlZCByZXN1bHRpbmcgaW4gZmFsc2UgbmVnYXRpdmVzIGFu ZCB0aGUNCiAgICA+ICAgIGltcGxlbWVudGF0aW9uIHNob3VsZCBiZSBhd2FyZSBvZiB0aGlzLg0K ICAgID4gDQogICAgPiANCiAgICA+IE5FVzoNCiAgICA+IA0KICAgID4gDQogICAgPiAgICBUaGUg ZG9jdW1lbnRzIHByb3Bvc2luZyB0aGUgT0FNIHNvbHV0aW9uIGZvciBTRiBjb21wb25lbnQgc2hv dWxkDQogICAgPiAgICBjb25zaWRlciByYXRlLWxpbWl0aW5nIHRoZSBPQU0gcHJvYmVzIGF0IGEg ZnJlcXVlbmN5IGd1aWRlZCBieSB0aGUNCiAgICA+ICAgIGltcGxlbWVudGF0aW9uIGNob2ljZS4g IFJhdGUtbGltaXRpbmcgbWF5IGJlIGFwcGxpZWQgYXQgdGhlIFNGRiBvcg0KICAgID4gICAgdGhl IFNGLiAgVGhlIE9BTSBpbml0aWF0b3IgbWF5IG5vdCByZWNlaXZlIGEgcmVzcG9uc2UgZm9yIHRo ZSBwcm9iZXMNCiAgICA+ICAgIHRoYXQgYXJlIHJhdGUtbGltaXRlZCByZXN1bHRpbmcgaW4gZmFs c2UgbmVnYXRpdmVzIGFuZCB0aGUNCiAgICA+ICAgIGltcGxlbWVudGF0aW9uIHNob3VsZCBiZSBh d2FyZSBvZiB0aGlzLiBUbyBtaXRpZ2F0ZSBhbnkgYXR0YWNrcyB0aGF0DQogICAgPiAgICBMZXZl cmFnZSBPQU0gcGFja2V0cywgZnV0dXJlIGRvY3VtZW50cyBwcm9wb3NpbmcgT0FNIHNvbHV0aW9u cw0KICAgID4gICAgc2hvdWxkIGRlc2NyaWJlIHRoZSB1c2Ugb2YgYW55IHRlY2huaXF1ZXMgdG8g ZGV0ZWN0DQogICAgPiAgICBhbmQgbWl0aWdhdGUgYW5vbWFsaWVzIGFuZCB2YXJpb3VzIHNlY3Vy aXR5ICBhdHRhY2tzLg0KICAgIA0KICAgIFdvcmtzIGZvciBtZS4NCiAgICANCiAgICBDaGVlcnMs DQogICAgLVRpcnUNCiAgICANCiAgICA+IA0KICAgID4gDQogICAgPiBXb3VsZCB0aGF0IHdvcms/ DQogICAgPiANCiAgICA+IFBsZWFzZSBmZWVsIGZyZWUgdG8gc3VnZ2VzdCB0ZXh0dWFsIGltcHJv dmVtZW50cyBvciBjaGFuZ2VzLg0KICAgID4gDQogICAgPiBUaGFua3MsDQogICAgPiANCiAgICA+ IENhcmxvcy4NCiAgICA+IA0KICAgID4gPiBDaGVlcnMsDQogICAgPiA+IC1UaXJ1DQogICAgPiA+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAgPiA+ IHNmYyBtYWlsaW5nIGxpc3QNCiAgICA+ID4gc2ZjQGlldGYub3JnDQogICAgPiA+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQogICAgDQogICAgX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICBzZmMgbWFpbGluZyBsaXN0 DQogICAgc2ZjQGlldGYub3JnDQogICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9zZmMNCiAgICANCg0K --_003_760DA3B53B1047868EC9B107BFEBAC28ciscocom_ Content-Type: text/html; name="Diff_ draft-ietf-sfc-oam-framework-13.txt - draft-ietf-sfc-oam-framework-14.txt.html" Content-Description: Diff_ draft-ietf-sfc-oam-framework-13.txt - draft-ietf-sfc-oam-framework-14.txt.html Content-Disposition: attachment; filename="Diff_ draft-ietf-sfc-oam-framework-13.txt - draft-ietf-sfc-oam-framework-14.txt.html"; size=40725; creation-date="Mon, 27 Apr 2020 14:35:41 GMT"; modification-date="Mon, 27 Apr 2020 14:35:41 GMT" Content-ID: Content-Transfer-Encoding: base64 PCFET0NUWVBFIGh0bWwgUFVCTElDICItLy9XM0MvL0RURCBYSFRNTCAxLjAgVHJhbnNpdGlvbmFs Ly9FTiIgImh0dHA6Ly93d3cudzMub3JnL1RSL3hodG1sMS9EVEQveGh0bWwxLXRyYW5zaXRpb25h bC5kdGQiPgo8IS0tIHNhdmVkIGZyb20gdXJsPSgwMDMwKWh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv cmZjZGlmZiAtLT4KPGh0bWwgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkveGh0bWwiPjxo ZWFkPjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0idGV4dC9odG1sOyBj aGFyc2V0PVVURi04Ij4gCiAgIAogIDxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtU3R5bGUtVHlw ZSIgY29udGVudD0idGV4dC9jc3MiPiAKICA8dGl0bGU+RGlmZjogZHJhZnQtaWV0Zi1zZmMtb2Ft LWZyYW1ld29yay0xMy50eHQgLSBkcmFmdC1pZXRmLXNmYy1vYW0tZnJhbWV3b3JrLTE0LnR4dDwv dGl0bGU+IAogIDxzdHlsZSB0eXBlPSJ0ZXh0L2NzcyI+IAogICAgYm9keSAgICB7IG1hcmdpbjog MC40ZXg7IG1hcmdpbi1yaWdodDogYXV0bzsgfSAKICAgIHRyICAgICAgeyB9IAogICAgdGQgICAg ICB7IHdoaXRlLXNwYWNlOiBwcmU7IGZvbnQtZmFtaWx5OiBtb25vc3BhY2U7IHZlcnRpY2FsLWFs aWduOiB0b3A7IGZvbnQtc2l6ZTogMC44NmVtO30gCiAgICB0aCAgICAgIHsgZm9udC1zaXplOiAw Ljg2ZW07IH0gCiAgICAuc21hbGwgIHsgZm9udC1zaXplOiAwLjZlbTsgZm9udC1zdHlsZTogaXRh bGljOyBmb250LWZhbWlseTogVmVyZGFuYSwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmOyB9IAogICAg LmxlZnQgICB7IGJhY2tncm91bmQtY29sb3I6ICNFRUU7IH0gCiAgICAucmlnaHQgIHsgYmFja2dy b3VuZC1jb2xvcjogI0ZGRjsgfSAKICAgIC5kaWZmICAgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjQ0NG OyB9IAogICAgLmxibG9jayB7IGJhY2tncm91bmQtY29sb3I6ICNCRkI7IH0gCiAgICAucmJsb2Nr IHsgYmFja2dyb3VuZC1jb2xvcjogI0ZGODsgfSAKICAgIC5pbnNlcnQgeyBiYWNrZ3JvdW5kLWNv bG9yOiAjOEZGOyB9IAogICAgLmRlbGV0ZSB7IGJhY2tncm91bmQtY29sb3I6ICNBQ0Y7IH0gCiAg ICAudm9pZCAgIHsgYmFja2dyb3VuZC1jb2xvcjogI0ZGQjsgfSAKICAgIC5jb250ICAgeyBiYWNr Z3JvdW5kLWNvbG9yOiAjRUVFOyB9IAogICAgLmxpbmViciB7IGJhY2tncm91bmQtY29sb3I6ICNB QUE7IH0gCiAgICAubGluZW5vIHsgY29sb3I6IHJlZDsgYmFja2dyb3VuZC1jb2xvcjogI0ZGRjsg Zm9udC1zaXplOiAwLjdlbTsgdGV4dC1hbGlnbjogcmlnaHQ7IHBhZGRpbmc6IDAgMnB4OyB9IAog ICAgLmVsaXBzaXN7IGJhY2tncm91bmQtY29sb3I6ICNBQUE7IH0gCiAgICAubGVmdCAuY29udCB7 IGJhY2tncm91bmQtY29sb3I6ICNEREQ7IH0gCiAgICAucmlnaHQgLmNvbnQgeyBiYWNrZ3JvdW5k LWNvbG9yOiAjRUVFOyB9IAogICAgLmxibG9jayAuY29udCB7IGJhY2tncm91bmQtY29sb3I6ICM5 RDk7IH0gCiAgICAucmJsb2NrIC5jb250IHsgYmFja2dyb3VuZC1jb2xvcjogI0RENjsgfSAKICAg IC5pbnNlcnQgLmNvbnQgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjMEREOyB9IAogICAgLmRlbGV0ZSAu Y29udCB7IGJhY2tncm91bmQtY29sb3I6ICM4QUQ7IH0gCiAgICAuc3RhdHMsIC5zdGF0cyB0ZCwg LnN0YXRzIHRoIHsgYmFja2dyb3VuZC1jb2xvcjogI0VFRTsgcGFkZGluZzogMnB4IDA7IH0gCiAg ICBzcGFuLmhpZGUgeyBkaXNwbGF5OiBub25lOyBjb2xvcjogI2FhYTt9ICAgIGE6aG92ZXIgc3Bh biB7IGRpc3BsYXk6IGlubGluZTsgfSAgICB0ci5jaGFuZ2UgeyBiYWNrZ3JvdW5kLWNvbG9yOiBn cmF5OyB9IAogICAgdHIuY2hhbmdlIGEgeyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IGNvbG9yOiBi bGFjayB9IAogIDwvc3R5bGU+IAogICAgIDxzY3JpcHQ+CnZhciBjaHVua19pbmRleCA9IDA7CnZh ciBvbGRfY2h1bmsgPSBudWxsOwoKZnVuY3Rpb24gZm9ybWF0X2NodW5rKGluZGV4KSB7CiAgICB2 YXIgcHJlZml4ID0gImRpZmYiOwogICAgdmFyIHN0ciA9IGluZGV4LnRvU3RyaW5nKCk7CiAgICBm b3IgKHg9MDsgeDwoNC1zdHIubGVuZ3RoKTsgKyt4KSB7CiAgICAgICAgcHJlZml4Kz0nMCc7CiAg ICB9CiAgICByZXR1cm4gcHJlZml4ICsgc3RyOwp9CgpmdW5jdGlvbiBmaW5kX2NodW5rKG4pewog ICAgcmV0dXJuIGRvY3VtZW50LnF1ZXJ5U2VsZWN0b3IoJ3RyW2lkJD0iJyArIG4gKyAnIl0nKTsK fQoKZnVuY3Rpb24gY2hhbmdlX2NodW5rKG9mZnNldCkgewogICAgdmFyIGluZGV4ID0gY2h1bmtf aW5kZXggKyBvZmZzZXQ7CiAgICB2YXIgbmV3X3N0cjsKICAgIHZhciBuZXdfY2h1bms7CgogICAg bmV3X3N0ciA9IGZvcm1hdF9jaHVuayhpbmRleCk7CiAgICBuZXdfY2h1bmsgPSBmaW5kX2NodW5r KG5ld19zdHIpOwogICAgaWYgKCFuZXdfY2h1bmspIHsKICAgICAgICByZXR1cm47CiAgICB9CiAg ICBpZiAob2xkX2NodW5rKSB7CiAgICAgICAgb2xkX2NodW5rLnN0eWxlLm91dGxpbmUgPSAiIjsK ICAgIH0KICAgIG9sZF9jaHVuayA9IG5ld19jaHVuazsKICAgIG9sZF9jaHVuay5zdHlsZS5vdXRs aW5lID0gIjFweCBzb2xpZCByZWQiOwogICAgd2luZG93LmxvY2F0aW9uLnJlcGxhY2UoIiMiICsg bmV3X3N0cikKICAgIHdpbmRvdy5zY3JvbGxCeSgwLC0xMDApOwogICAgY2h1bmtfaW5kZXggPSBp bmRleDsKfQoKZG9jdW1lbnQub25rZXlkb3duID0gZnVuY3Rpb24oZSkgewogICAgc3dpdGNoIChl LmtleUNvZGUpIHsKICAgIGNhc2UgNzg6CiAgICAgICAgY2hhbmdlX2NodW5rKDEpOwogICAgICAg IGJyZWFrOwogICAgY2FzZSA4MDoKICAgICAgICBjaGFuZ2VfY2h1bmsoLTEpOwogICAgICAgIGJy ZWFrOwogICAgfQp9OwogICA8L3NjcmlwdD4gCjxsaW5rIGlkPSJub3RlYW55d2hlcmVjc3MiIG1l ZGlhPSJzY3JlZW4iIHR5cGU9InRleHQvY3NzIiByZWw9InN0eWxlc2hlZXQiIGhyZWY9ImRhdGE6 dGV4dC9jc3MsLm5vdGUtYW55d2hlcmUlMjAuY2xvc2VidXR0b24lN0JiYWNrZ3JvdW5kLWltYWdl JTNBJTIwdXJsJTI4Y2hyb21lLWV4dGVuc2lvbiUzQS8vYm9oYWhraWlrbmtlbGZsbmpqbGlwbmFl YXBlZm1qYmgvYXNzZXQvZGVsZXRlQnV0dG9uLnBuZyUyOSUzQiU3RCUwQSI+PHN0eWxlIHR5cGU9 InRleHQvY3NzIiBpZD0iY2U4ODk4NjgtNjcyYS00NDliLTg2YTQtMjY0ODU4MzAwYmYzIj4uZmEz OTA1NzgtNzJlMC00ODk1LTgzNTgtYzQ2NGZjNTljZTYxIHsgcG9zaXRpb246IHJlbGF0aXZlICFp bXBvcnRhbnQ7IGJvcmRlci1yYWRpdXM6IDAuMmVtICFpbXBvcnRhbnQ7IHBhZGRpbmc6IDBweCAh aW1wb3J0YW50OyBtYXJnaW46IDBweCAhaW1wb3J0YW50OyB9CgouYTQ0YjQ2YzktNGRlMS00ZmQz LThlYWYtZjVmNGE3MzI0YmRmIC5zc2gtY2xvc2UgeyBwb3NpdGlvbjogYWJzb2x1dGU7IGxlZnQ6 IC04cHg7IHRvcDogLThweDsgd2lkdGg6IDE2cHg7IGhlaWdodDogMTZweDsgei1pbmRleDogOTk5 OyBib3JkZXI6IG5vbmU7IGJhY2tncm91bmQ6IHVybCgiZGF0YTppbWFnZS9wbmc7YmFzZTY0LGlW Qk9SdzBLR2dvQUFBQU5TVWhFVWdBQUFCQUFBQUFRQ0FZQUFBQWY4LzloQUFBQUNYQklXWE1BQUFz VEFBQUxFd0VBbXB3WUFBQUtUMmxEUTFCUWFHOTBiM05vYjNBZ1NVTkRJSEJ5YjJacGJHVUFBSGph blZOblZGUHBGajMzM3ZSQ1M0aUFsRXR2VWhVSUlGSkNpNEFVa1NZcUlRa1FTb2dob2RrVlVjRVJS VVVFRzhpZ2lBT09qb0NNRlZFc0RJb0syQWZrSWFLT2c2T0lpc3I3NFh1amE5YTg5K2JOL3JYWFB1 ZXM4NTJ6endmQUNBeVdTRE5STllBTXFVSWVFZUNEeDhURzRlUXVRSUVLSkhBQUVBaXpaQ0Z6L1NN QkFQaCtQRHdySXNBSHZnQUJlTk1MQ0FEQVRadkFNQnlIL3cvcVFwbGNBWUNFQWNCMGtUaExDSUFV QUVCNmprS21BRUJHQVlDZG1DWlRBS0FFQUdETFkyTGpBRkF0QUdBbmYrYlRBSUNkK0psN0FRQmJs Q0VWQWFDUkFDQVRaWWhFQUdnN0FLelBWb3BGQUZnd0FCUm1TOFE1QU5ndEFEQkpWMlpJQUxDM0FN RE9FQXV5QUFnTUFEQlJpSVVwQUFSN0FHRElJeU40QUlTWkFCUkc4bGM4OFN1dUVPY3FBQUI0bWJJ OHVTUTVSWUZiQ0MxeEIxZFhMaDRvemtrWEt4UTJZUUpobWtBdXdubVpHVEtCTkEvZzg4d0FBS0NS RlJIZ2cvUDllTTRPcnM3T05vNjJEbDh0NnI4Ry95SmlZdVArNWMrcmNFQUFBT0YwZnRIK0xDK3pH b0E3Qm9CdC9xSWw3Z1JvWGd1Z2RmZUxacklQUUxVQW9PbmFWL053K0g0OFBFV2hrTG5aMmVYazVO aEt4RUpiWWNwWGZmNW53bC9BVi8xcytYNDgvUGYxNEw3aUpJRXlYWUZIQlBqZ3dzejBUS1VjejVJ SmhHTGM1bzlIL0xjTC8vd2QweUxFU1dLNVdDb1U0MUVTY1k1RW1venpNcVVpaVVLU0tjVWwwdjlr NHQ4cyt3TSszelVBc0dvK0FYdVJMYWhkWXdQMlN5Y1FXSFRBNHZjQUFQSzdiOEhVS0FnRGdHaUQ0 YzkzLys4Ly9VZWdKUUNBWmttU2NRQUFYa1FrTGxUS3N6L0hDQUFBUktDQktyQkJHL1RCR0N6QUJo ekJCZHpCQy94Z05vUkNKTVRDUWhCQ0NtU0FISEpnS2F5Q1FpaUd6YkFkS21BdjFFQWROTUJSYUlh VGNBNHV3bFc0RGoxd0QvcGhDSjdCS0x5QkNRUkJ5QWdUWVNIYWlBRmlpbGdqamdnWG1ZWDRJY0ZJ QkJLTEpDREppQlJSSWt1Uk5VZ3hVb3BVSUZWSUhmSTljZ0k1aDF4R3VwRTd5QUF5Z3Z5R3ZFY3hs SUd5VVQzVURMVkR1YWczR29SR29ndlFaSFF4bW84V29KdlFjclFhUFl3Mm9lZlFxMmdQMm84K1E4 Y3d3T2dZQnpQRWJEQXV4c05Dc1Rnc0NaTmp5N0VpckF5cnhocXdWcXdEdTRuMVk4K3hkd1FTZ1VY QUNUWUVkMElnWVI1QlNGaE1XRTdZU0tnZ0hDUTBFZG9KTndrRGhGSENKeUtUcUV1MEpyb1IrY1FZ WWpJeGgxaElMQ1BXRW84VEx4QjdpRVBFTnlRU2lVTXlKN21RQWtteHBGVFNFdEpHMG01U0kra3Nx WnMwU0Jvams4bmFaR3V5QnptVUxDQXJ5SVhrbmVURDVEUGtHK1FoOGxzS25XSkFjYVQ0VStJb1Vz cHFTaG5sRU9VMDVRWmxtREpCVmFPYVV0Mm9vVlFSTlk5YVFxMmh0bEt2VVllb0V6UjFtam5OZ3ha SlM2V3RvcFhUR21nWGFQZHByK2gwdWhIZGxSNU9sOUJYMHN2cFIraVg2QVAwZHd3TmhoV0R4NGhu S0JtYkdBY1laeGwzR0srWVRLWVowNHNaeDFRd056SHJtT2VaRDVsdlZWZ3F0aXA4RlpIS0NwVkts U2FWR3lvdlZLbXFwcXJlcWd0VjgxWExWSStwWGxOOXJrWlZNMVBqcVFuVWxxdFZxcDFRNjFNYlUy ZXBPNmlIcW1lb2IxUS9wSDVaL1lrR1djTk13MDlEcEZHZ3NWL2p2TVlnQzJNWnMzZ3NJV3NOcTRa MWdUWEVKckhOMlh4MktydVkvUjI3aXoycXFhRTVRek5LTTFlelV2T1VaajhINDVoeCtKeDBUZ25u S0tlWDgzNkszaFR2S2VJcEc2WTBUTGt4WlZ4cnFwYVhsbGlyU0t0UnEwZnJ2VGF1N2FlZHByMUZ1 MW43Z1E1Qngwb25YQ2RIWjQvT0JaM25VOWxUM2FjS3B4Wk5QVHIxcmk2cWE2VWJvYnRFZDc5dXAr NllucjVlZ0o1TWI2ZmVlYjNuK2h4OUwvMVUvVzM2cC9WSERGZ0dzd3drQnRzTXpoZzh4VFZ4Ynp3 ZEw4ZmI4VkZEWGNOQVE2VmhsV0dYNFlTUnVkRThvOVZHalVZUGpHbkdYT01rNDIzR2JjYWpKZ1lt SVNaTFRlcE43cHBTVGJtbUthWTdURHRNeDgzTXphTE4xcGsxbXoweDF6TG5tK2ViMTV2ZnQyQmFl Rm9zdHFpMnVHVkpzdVJhcGxudXRyeHVoVm81V2FWWVZWcGRzMGF0bmEwbDFydXR1NmNScDdsT2sw NnJudFpudzdEeHRzbTJxYmNac09YWUJ0dXV0bTIyZldGblloZG50OFd1dys2VHZaTjl1bjJOL1Qw SERZZlpEcXNkV2gxK2M3UnlGRHBXT3Q2YXpwenVQMzNGOUpicEwyZFl6eERQMkRQanRoUExLY1Jw blZPYjAwZG5GMmU1YzRQemlJdUpTNExMTHBjK0xwc2J4dDNJdmVSS2RQVnhYZUY2MHZXZG03T2J3 dTJvMjYvdU51NXA3b2Zjbjh3MG55bWVXVE56ME1QSVErQlI1ZEUvQzUrVk1HdmZySDVQUTArQlo3 WG5JeTlqTDVGWHJkZXd0NlYzcXZkaDd4Yys5ajV5bitNKzR6dzMzakxlV1YvTU44QzN5TGZMVDhO dm5sK0YzME4vSS85ay8zci8wUUNuZ0NVQlp3T0pnVUdCV3dMNytIcDhJYitPUHpyYlpmYXkyZTFC aktDNVFSVkJqNEt0Z3VYQnJTRm95T3lRclNIMzU1ak9rYzVwRG9WUWZ1alcwQWRoNW1HTHczNE1K NFdIaFZlR1A0NXdpRmdhMFRHWE5YZlIzRU56MzBUNlJKWkUzcHRuTVU4NXJ5MUtOU28rcWk1cVBO bzN1alM2UDhZdVpsbk0xVmlkV0Vsc1N4dzVMaXF1Tm01c3Z0Lzg3Zk9INHAzaUMrTjdGNWd2eUYx d2VhSE93dlNGcHhhcExoSXNPcFpBVEloT09KVHdRUkFxcUJhTUpmSVRkeVdPQ25uQ0hjSm5JaS9S TnRHSTJFTmNLaDVPOGtncVRYcVM3Skc4Tlhra3hUT2xMT1c1aENlcGtMeE1EVXpkbXpxZUZwcDJJ RzB5UFRxOU1ZT1NrWkJ4UXFvaFRaTzJaK3BuNW1aMnk2eGxoYkwreFc2THR5OGVsUWZKYTdPUXJB VlpMUXEyUXFib1ZGb28xeW9Ic21kbFYyYS96WW5LT1phcm5pdk43Y3l6eXR1UU41enZuLy90RXNJ UzRaSzJwWVpMVnkwZFdPYTlyR281c2p4eGVkc0s0eFVGSzRaV0Jxdzh1SXEyS20zVlQ2dnRWNWV1 ZnIwbWVrMXJnVjdCeW9MQnRRRnI2d3RWQ3VXRmZldmMxKzFkVDFndldkKzFZZnFHblJzK0ZZbUty aFRiRjVjVmY5Z28zSGpsRzRkdnlyK1ozSlMwcWF2RXVXVFBadEptNmViZUxaNWJEcGFxbCthWERt NE4yZHEwRGQ5V3RPMzE5a1hiTDVmTktOdTdnN1pEdWFPL1BMaThaYWZKenMwN1AxU2tWUFJVK2xR Mjd0TGR0V0hYK0c3UjdodDd2UFkwN05YYlc3ejMvVDdKdnR0VkFWVk4xV2JWWmZ0Sis3UDNQNjZK cXVuNGx2dHRYYTFPYlhIdHh3UFNBLzBISXc2MjE3blUxUjNTUFZSU2o5WXI2MGNPeHgrKy9wM3Zk eTBOTmcxVmpaekc0aU53UkhuazZmY0ozL2NlRFRyYWRveDdyT0VIMHg5MkhXY2RMMnBDbXZLYVJw dFRtdnRiWWx1NlQ4dyswZGJxM25yOFI5c2ZENXcwUEZsNVN2TlV5V25hNllMVGsyZnl6NHlkbFox OWZpNzUzR0Rib3JaNzUyUE8zMm9QYisrNkVIVGgwa1gvaStjN3ZEdk9YUEs0ZFBLeTIrVVRWN2hY bXE4NlgyM3FkT284L3BQVFQ4ZTduTHVhcnJsY2E3bnVlcjIxZTJiMzZSdWVOODdkOUwxNThSYi8x dFdlT1QzZHZmTjZiL2ZGOS9YZkZ0MStjaWY5enN1NzJYY243cTI4VDd4ZjlFRHRRZGxEM1lmVlAx diszTmp2M0g5cXdIZWc4OUhjUi9jR2hZUFAvcEgxanc5REJZK1pqOHVHRFlicm5qZytPVG5pUDNM OTZmeW5RODlrenlhZUYvNmkvc3V1RnhZdmZ2alY2OWZPMFpqUm9aZnlsNU8vYlh5bC9lckE2eG12 MjhiQ3hoNit5WGd6TVY3MFZ2dnR3WGZjZHgzdm85OFBUK1I4SUg4by8yajVzZlZUMEtmN2t4bVRr LzhFQTVqei9HTXpMZHNBQUFBZ1kwaFNUUUFBZWlVQUFJQ0RBQUQ1L3dBQWdPa0FBSFV3QUFEcVlB QUFPcGdBQUJkdmtsL0ZSZ0FBQWVCSlJFRlVlTnFNVTAxckdsRVVQVzlFVUplUjJReVVjWjF1Vkxy cjN6QWJwZGhmRldwaFZnVUZSMXlsTkdSMDRxYUlVQlFYYmFPbW9PUUhaT2JKVzgzSDZVWmZHcTNn V2I3TFBlL2VjODhSMkNHWHl5RkpFa1JSOUE3QWgycTErdDYyN1RjQXNObHNucWJUNlhjQVg3TFo3 STk4UG8vdGRndVNPTVIxczlua1pESmhraVRjSTA0U1RpWVROcHROQXJnR0FDSEVVZk45cDlONWFZ cGpLcVdvbEdJY3gvcTkzVzRUd1AwaHllZGVyOGQvRVFRQnBaU1VVaklJZ2xjMTEzVUpvR1VZQmdE Z3N0Rm82S0xqT1B4MmUwdVNETU9RWVJpU0pNZmpNWDNmWjVxbUpNbDZ2VTRBbHpBTW96V2Z6L1hZ cnV2U05FMk9SaU5OT2hnTWFGa1dmZDluRkVVa3lmbDhUaUhFSjVRcmxkLzc1djF2QTgramFacDgv UFBJeFdMQjRzVUZQYy9UVThVN2djdmw4ay9VcnE2ZVNWSXBSU21sSmxrdGx5elpOdTFTaWF2VlNq ZExLYW1VSWtuV2FyVm5BeWNnaEVDU0pCQUFNcGtNVHFKY3FmdzZYTUc3dTJPeFdPUnl1ZVRpNGVH VkprY3JDQ0cwaUZFVTBSOE9hVmtXQjhQaGk0ZzdUZnI5dnZhRUZoSEEyMGFqVHBKTTA1Uys3M004 SGgrZDhldk5EUjNIMGFUNmpOcElybnUya2JyZExnRzBEclU1YWVYa0RDdnJNSDNjaFNrK00weWFJ cC9QSTQ3ai84WjV2VjQveldZekhlZENvUUFwSlVqaTd3QXFOR3BWWUprZkd3QUFBQUJKUlU1RXJr SmdnZz09Iikgbm8tcmVwZWF0IGJvcmRlci1ib3g7IGFuaW1hdGlvbi1kdXJhdGlvbjogMjc1bXM7 IGFuaW1hdGlvbi10aW1pbmctZnVuY3Rpb246IGVhc2Utb3V0OyBib3gtc2hhZG93OiBub25lOyBh bmltYXRpb24tbmFtZTogYWQyMzBjOGYtYjczOC00MjA2LWJmN2EtZTlhZDQxNmI2ZjRlOyB9Cgou YTQ0YjQ2YzktNGRlMS00ZmQzLThlYWYtZjVmNGE3MzI0YmRmIC5zc2gtY2xvc2U6aG92ZXIsIC5h NDRiNDZjOS00ZGUxLTRmZDMtOGVhZi1mNWY0YTczMjRiZGYgLnNzaC1jbG9zZTpmb2N1cyB7IGJh Y2tncm91bmQtaW1hZ2U6IHVybCgiZGF0YTppbWFnZS9wbmc7YmFzZTY0LGlWQk9SdzBLR2dvQUFB QU5TVWhFVWdBQUFCQUFBQUFRQ0FZQUFBQWY4LzloQUFBQUNYQklXWE1BQUFzVEFBQUxFd0VBbXB3 WUFBQUtUMmxEUTFCUWFHOTBiM05vYjNBZ1NVTkRJSEJ5YjJacGJHVUFBSGphblZOblZGUHBGajMz M3ZSQ1M0aUFsRXR2VWhVSUlGSkNpNEFVa1NZcUlRa1FTb2dob2RrVlVjRVJSVVVFRzhpZ2lBT09q b0NNRlZFc0RJb0syQWZrSWFLT2c2T0lpc3I3NFh1amE5YTg5K2JOL3JYWFB1ZXM4NTJ6endmQUNB eVdTRE5STllBTXFVSWVFZUNEeDhURzRlUXVRSUVLSkhBQUVBaXpaQ0Z6L1NNQkFQaCtQRHdySXNB SHZnQUJlTk1MQ0FEQVRadkFNQnlIL3cvcVFwbGNBWUNFQWNCMGtUaExDSUFVQUVCNmprS21BRUJH QVlDZG1DWlRBS0FFQUdETFkyTGpBRkF0QUdBbmYrYlRBSUNkK0psN0FRQmJsQ0VWQWFDUkFDQVRa WWhFQUdnN0FLelBWb3BGQUZnd0FCUm1TOFE1QU5ndEFEQkpWMlpJQUxDM0FNRE9FQXV5QUFnTUFE QlJpSVVwQUFSN0FHRElJeU40QUlTWkFCUkc4bGM4OFN1dUVPY3FBQUI0bWJJOHVTUTVSWUZiQ0Mx eEIxZFhMaDRvemtrWEt4UTJZUUpobWtBdXdubVpHVEtCTkEvZzg4d0FBS0NSRlJIZ2cvUDllTTRP cnM3T05vNjJEbDh0NnI4Ry95SmlZdVArNWMrcmNFQUFBT0YwZnRIK0xDK3pHb0E3Qm9CdC9xSWw3 Z1JvWGd1Z2RmZUxacklQUUxVQW9PbmFWL053K0g0OFBFV2hrTG5aMmVYazVOaEt4RUpiWWNwWGZm NW53bC9BVi8xcytYNDgvUGYxNEw3aUpJRXlYWUZIQlBqZ3dzejBUS1VjejVJSmhHTGM1bzlIL0xj TC8vd2QweUxFU1dLNVdDb1U0MUVTY1k1RW1venpNcVVpaVVLU0tjVWwwdjlrNHQ4cyt3TSszelVB c0dvK0FYdVJMYWhkWXdQMlN5Y1FXSFRBNHZjQUFQSzdiOEhVS0FnRGdHaUQ0YzkzLys4Ly9VZWdK UUNBWmttU2NRQUFYa1FrTGxUS3N6L0hDQUFBUktDQktyQkJHL1RCR0N6QUJoekJCZHpCQy94Z05v UkNKTVRDUWhCQ0NtU0FISEpnS2F5Q1FpaUd6YkFkS21BdjFFQWROTUJSYUlhVGNBNHV3bFc0RGox d0QvcGhDSjdCS0x5QkNRUkJ5QWdUWVNIYWlBRmlpbGdqamdnWG1ZWDRJY0ZJQkJLTEpDREppQlJS SWt1Uk5VZ3hVb3BVSUZWSUhmSTljZ0k1aDF4R3VwRTd5QUF5Z3Z5R3ZFY3hsSUd5VVQzVURMVkR1 YWczR29SR29ndlFaSFF4bW84V29KdlFjclFhUFl3Mm9lZlFxMmdQMm84K1E4Y3d3T2dZQnpQRWJE QXV4c05Dc1Rnc0NaTmp5N0VpckF5cnhocXdWcXdEdTRuMVk4K3hkd1FTZ1VYQUNUWUVkMElnWVI1 QlNGaE1XRTdZU0tnZ0hDUTBFZG9KTndrRGhGSENKeUtUcUV1MEpyb1IrY1FZWWpJeGgxaElMQ1BX RW84VEx4QjdpRVBFTnlRU2lVTXlKN21RQWtteHBGVFNFdEpHMG01U0kra3NxWnMwU0Jvams4bmFa R3V5QnptVUxDQXJ5SVhrbmVURDVEUGtHK1FoOGxzS25XSkFjYVQ0VStJb1VzcHFTaG5sRU9VMDVR WmxtREpCVmFPYVV0Mm9vVlFSTlk5YVFxMmh0bEt2VVllb0V6UjFtam5OZ3haSlM2V3RvcFhUR21n WGFQZHByK2gwdWhIZGxSNU9sOUJYMHN2cFIraVg2QVAwZHd3TmhoV0R4NGhuS0JtYkdBY1laeGwz R0srWVRLWVowNHNaeDFRd056SHJtT2VaRDVsdlZWZ3F0aXA4RlpIS0NwVktsU2FWR3lvdlZLbXFw cXJlcWd0VjgxWExWSStwWGxOOXJrWlZNMVBqcVFuVWxxdFZxcDFRNjFNYlUyZXBPNmlIcW1lb2Ix US9wSDVaL1lrR1djTk13MDlEcEZHZ3NWL2p2TVlnQzJNWnMzZ3NJV3NOcTRaMWdUWEVKckhOMlh4 MktydVkvUjI3aXoycXFhRTVRek5LTTFlelV2T1VaajhINDVoeCtKeDBUZ25uS0tlWDgzNkszaFR2 S2VJcEc2WTBUTGt4WlZ4cnFwYVhsbGlyU0t0UnEwZnJ2VGF1N2FlZHByMUZ1MW43Z1E1Qngwb25Y Q2RIWjQvT0JaM25VOWxUM2FjS3B4Wk5QVHIxcmk2cWE2VWJvYnRFZDc5dXArNllucjVlZ0o1TWI2 ZmVlYjNuK2h4OUwvMVUvVzM2cC9WSERGZ0dzd3drQnRzTXpoZzh4VFZ4Ynp3ZEw4ZmI4VkZEWGNO QVE2VmhsV0dYNFlTUnVkRThvOVZHalVZUGpHbkdYT01rNDIzR2JjYWpKZ1ltSVNaTFRlcE43cHBT VGJtbUthWTdURHRNeDgzTXphTE4xcGsxbXoweDF6TG5tK2ViMTV2ZnQyQmFlRm9zdHFpMnVHVkpz dVJhcGxudXRyeHVoVm81V2FWWVZWcGRzMGF0bmEwbDFydXR1NmNScDdsT2swNnJudFpudzdEeHRz bTJxYmNac09YWUJ0dXV0bTIyZldGblloZG50OFd1dys2VHZaTjl1bjJOL1QwSERZZlpEcXNkV2gx K2M3UnlGRHBXT3Q2YXpwenVQMzNGOUpicEwyZFl6eERQMkRQanRoUExLY1JwblZPYjAwZG5GMmU1 YzRQemlJdUpTNExMTHBjK0xwc2J4dDNJdmVSS2RQVnhYZUY2MHZXZG03T2J3dTJvMjYvdU51NXA3 b2Zjbjh3MG55bWVXVE56ME1QSVErQlI1ZEUvQzUrVk1HdmZySDVQUTArQlo3WG5JeTlqTDVGWHJk ZXd0NlYzcXZkaDd4Yys5ajV5bitNKzR6dzMzakxlV1YvTU44QzN5TGZMVDhOdm5sK0YzME4vSS85 ay8zci8wUUNuZ0NVQlp3T0pnVUdCV3dMNytIcDhJYitPUHpyYlpmYXkyZTFCaktDNVFSVkJqNEt0 Z3VYQnJTRm95T3lRclNIMzU1ak9rYzVwRG9WUWZ1alcwQWRoNW1HTHczNE1KNFdIaFZlR1A0NXdp RmdhMFRHWE5YZlIzRU56MzBUNlJKWkUzcHRuTVU4NXJ5MUtOU28rcWk1cVBObzN1alM2UDhZdVps bk0xVmlkV0Vsc1N4dzVMaXF1Tm01c3Z0Lzg3Zk9INHAzaUMrTjdGNWd2eUYxd2VhSE93dlNGcHhh cExoSXNPcFpBVEloT09KVHdRUkFxcUJhTUpmSVRkeVdPQ25uQ0hjSm5JaS9STnRHSTJFTmNLaDVP OGtncVRYcVM3Skc4Tlhra3hUT2xMT1c1aENlcGtMeE1EVXpkbXpxZUZwcDJJRzB5UFRxOU1ZT1Nr WkJ4UXFvaFRaTzJaK3BuNW1aMnk2eGxoYkwreFc2THR5OGVsUWZKYTdPUXJBVlpMUXEyUXFib1ZG b28xeW9Ic21kbFYyYS96WW5LT1phcm5pdk43Y3l6eXR1UU41enZuLy90RXNJUzRaSzJwWVpMVnkw ZFdPYTlyR281c2p4eGVkc0s0eFVGSzRaV0Jxdzh1SXEyS20zVlQ2dnRWNWV1ZnIwbWVrMXJnVjdC eW9MQnRRRnI2d3RWQ3VXRmZldmMxKzFkVDFndldkKzFZZnFHblJzK0ZZbUtyaFRiRjVjVmY5Z28z SGpsRzRkdnlyK1ozSlMwcWF2RXVXVFBadEptNmViZUxaNWJEcGFxbCthWERtNE4yZHEwRGQ5V3RP MzE5a1hiTDVmTktOdTdnN1pEdWFPL1BMaThaYWZKenMwN1AxU2tWUFJVK2xRMjd0TGR0V0hYK0c3 UjdodDd2UFkwN05YYlc3ejMvVDdKdnR0VkFWVk4xV2JWWmZ0Sis3UDNQNjZKcXVuNGx2dHRYYTFP YlhIdHh3UFNBLzBISXc2MjE3blUxUjNTUFZSU2o5WXI2MGNPeHgrKy9wM3ZkeTBOTmcxVmpaekc0 aU53UkhuazZmY0ozL2NlRFRyYWRveDdyT0VIMHg5MkhXY2RMMnBDbXZLYVJwdFRtdnRiWWx1NlQ4 dyswZGJxM25yOFI5c2ZENXcwUEZsNVN2TlV5V25hNllMVGsyZnl6NHlkbFoxOWZpNzUzR0Rib3Ja NzUyUE8zMm9QYisrNkVIVGgwa1gvaStjN3ZEdk9YUEs0ZFBLeTIrVVRWN2hYbXE4NlgyM3FkT284 L3BQVFQ4ZTduTHVhcnJsY2E3bnVlcjIxZTJiMzZSdWVOODdkOUwxNThSYi8xdFdlT1QzZHZmTjZi L2ZGOS9YZkZ0MStjaWY5enN1NzJYY243cTI4VDd4ZjlFRHRRZGxEM1lmVlAxdiszTmp2M0g5cXdI ZWc4OUhjUi9jR2hZUFAvcEgxanc5REJZK1pqOHVHRFlicm5qZytPVG5pUDNMOTZmeW5RODlrenlh ZUYvNmkvc3V1RnhZdmZ2alY2OWZPMFpqUm9aZnlsNU8vYlh5bC9lckE2eG12MjhiQ3hoNit5WGd6 TVY3MFZ2dnR3WGZjZHgzdm85OFBUK1I4SUg4by8yajVzZlZUMEtmN2t4bVRrLzhFQTVqei9HTXpM ZHNBQUFBZ1kwaFNUUUFBZWlVQUFJQ0RBQUQ1L3dBQWdPa0FBSFV3QUFEcVlBQUFPcGdBQUJkdmts L0ZSZ0FBQXVkSlJFRlVlTnAwazExb2xYVWN4ei8vLy9QaXpqblBPWUhiUEdOREtHTFBvQzBoOEtL TVlwVzlZVU1JWjlKcGdtdHp0SXZFdWdpeGk2QTN1Z2pLaTBucjJNbzVyRnhkREtFVTBtQW9CTXBR dHdzZmtRTDF1TE56ZW5FK3gzUE84L0wvZDNFeU10d1hmbmMvdmo5KzhQa0lyVFVBOVZxTnlKQkl5 MTZ2WUNDWVczZzB2cks0RnNCWTIzYkZmcWo3bEFHVGNSQ2MwYlVhcVhRYUlRVGlka0VFQkREbVQ4 MjhWc2xQRTh4ZlF0L3dBUkQzT05nOW5UaEQvYVJ5ZmZ1QjBZVFdkeFpVNGVUUzRKNWVmMklTaVlQ UnZnWmhXd0RvSUNRdUxLR29rQjRjb09YQUJ6OG40UW0wUnFyRzlmSGkwTjVlZitJZ3hxcG1oSk5F cGxNZ0pVaUpjRkxJaklPWnlYTHppeThwN1h5N040VFBJcTBSVmEwZnVESDk0MEs1ZndpanFabjBy Z0hpcTR2NFU5OWp1MTBBaE41bEVpODhpVWdscVAwd1M3UzhTT3VSUEprdHozWExXTVc3S21PSGtU Z0kweUMrWG1KMS9sMlNtNTRtOER3Q3p5T3hlU1BOaHo1Q1Y2cUFRT0xnangxRzZmaDFNNWozSGcv UGV4anRXV1E2aVgvd1c5UmZ5N1I4OXluRmg3ZUJsTFI4OHpIbHJXOVNQWG9DeTcwZjRTUUlMM2pV NXk4OVprYS9GZHJVc28vWnNRWWRSdGh1RjdkbWpsSGNrS1AxZUI2MHB2aElqdnJjT1d6WFJVY1J3 clpRNVQrSmZyM1dMZ0VFLzQxb2pOWWdKQWdCU3JGU3BIVnZ4M1dSY2RCQmhEQk5RdTh5eWMzUGtq MDlSZW1aVnlrOVAwTDJsNjlKYnRwSTRGMUVXQ1k2Q0JFWkIvTytqb0swZTl4WmE1MUxYQ2dTTDVa STlEMUY4MWNmVW43cERlcHo1Nm1mbmFPOGRUY3RSejdCeWIzWTJDc3NZVDNZU1ZPUE95dUZsUHRT bzl0US9FTmRzb25mWDNtTDZzeFAySzZMN2JyY21qbkdIeVB2WUhSazBXR013aWMxK2pKQ3lIMGkx b29ZTVg1dGVPOXdKVCtCbVdsdi9OYldDbEhVS0xWTW9xdEZpR1BpV3BuMDhBN2F4dDhibDBxTjNB WGxRMGhTSzZMc0RHNm45Y0Q3LzZKOGQ1aytueVpZdUZNbXE3dVQ5SEEvVHE1dnY0TFI1UDlsdXEy emFkbnJveFYwTm1FeUNvSXpxbHJGeVdRUVF2RDNBR1ZRWUNDbUY4TytBQUFBQUVsRlRrU3VRbUND Iik7IH0KCkBtZWRpYSBwcmludCB7CiAgLmE0NGI0NmM5LTRkZTEtNGZkMy04ZWFmLWY1ZjRhNzMy NGJkZiB7IGJveC1zaGFkb3c6IHVuc2V0ICFpbXBvcnRhbnQ7IC13ZWJraXQtcHJpbnQtY29sb3It YWRqdXN0OiBleGFjdCAhaW1wb3J0YW50OyB9Cn0KCkBrZXlmcmFtZXMgYWQyMzBjOGYtYjczOC00 MjA2LWJmN2EtZTlhZDQxNmI2ZjRlIHsgCiAgMCUgeyBvcGFjaXR5OiAwOyB0cmFuc2Zvcm06IHNj YWxlKDAuNik7IH0KICAxMDAlIHsgb3BhY2l0eTogMTsgdHJhbnNmb3JtOiBzY2FsZSgxKTsgfQp9 CgpAa2V5ZnJhbWVzIGM4M2E5ZjRiLTlhYmItNDNlYS1hOWE0LTE3NWM2ZTg2NWFkZCB7IAogIDEw MCUgeyBvcGFjaXR5OiAwOyB0cmFuc2Zvcm06IHNjYWxlKDAuMyk7IH0KfQoKLmE0NGI0NmM5LTRk ZTEtNGZkMy04ZWFmLWY1ZjRhNzMyNGJkZiB7IGJhY2tncm91bmQtY29sb3I6IHJnYmEoMjM4LCAy MzgsIDIzOCwgMC44KTsgY29sb3I6IHJnYigxNzAsIDE3MCwgMTcwKTsgZm9udDogaW5oZXJpdDsg Ym94LXNoYWRvdzogcmdiKDIzOCwgMjM4LCAyMzgpIDBweCAwcHggMC4zNWVtOyB0ZXh0LXNoYWRv dzogbm9uZSAhaW1wb3J0YW50OyB9CgouZGVmYXVsdC1yZWQtYWE5NGUzZDUtYWIyZi00MjA1LWI3 NGUtMThjZTMxYzdjMGNlIHsgYm94LXNoYWRvdzogcmdiKDI1NSwgMTI4LCAxMjgpIDBweCAwcHgg MC4zNWVtOyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2JhKDI1NSwgMTI4LCAxMjgsIDAuOCkgIWltcG9y dGFudDsgY29sb3I6IHJnYigwLCAwLCAwKSAhaW1wb3J0YW50OyB9CgouZGVmYXVsdC1vcmFuZ2Ut ZGEwMTk0NWUtMTk2NC00ZDI3LThhNmMtMzMzMWUxZmU3ZjE0IHsgYm94LXNoYWRvdzogcmdiKDI1 NSwgMjEwLCAxNzApIDBweCAwcHggMC4zNWVtOyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2JhKDI1NSwg MjEwLCAxNzAsIDAuOCkgIWltcG9ydGFudDsgY29sb3I6IHJnYigwLCAwLCAwKSAhaW1wb3J0YW50 OyB9CgouZGVmYXVsdC15ZWxsb3ctYWFkZGNmNWMtMGU0MS00ZjgzLThhNjQtNThjOTFmN2M2MjUw IHsgYm94LXNoYWRvdzogcmdiKDI1NSwgMjU1LCAxNzApIDBweCAwcHggMC4zNWVtOyBiYWNrZ3Jv dW5kLWNvbG9yOiByZ2JhKDI1NSwgMjU1LCAxNzAsIDAuOCkgIWltcG9ydGFudDsgY29sb3I6IHJn YigwLCAwLCAwKSAhaW1wb3J0YW50OyB9CgouZGVmYXVsdC1ncmVlbi1jNGQ0MWUwYS1lNDBmLTRj M2YtOTFhZC0yZDY2NDgxNjE0YzIgeyBib3gtc2hhZG93OiByZ2IoMTcwLCAyNTUsIDE3MCkgMHB4 IDBweCAwLjM1ZW07IGJhY2tncm91bmQtY29sb3I6IHJnYmEoMTcwLCAyNTUsIDE3MCwgMC44KSAh aW1wb3J0YW50OyBjb2xvcjogcmdiKDAsIDAsIDApICFpbXBvcnRhbnQ7IH0KCi5kZWZhdWx0LWN5 YW4tZjg4ZTg4MjctZTY1Mi00ZDc5LWE5ZDktZjZjOGI4ZWM5ZTJiIHsgYm94LXNoYWRvdzogcmdi KDE3MCwgMjU1LCAyNTUpIDBweCAwcHggMC4zNWVtOyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2JhKDE3 MCwgMjU1LCAyNTUsIDAuOCkgIWltcG9ydGFudDsgY29sb3I6IHJnYigwLCAwLCAwKSAhaW1wb3J0 YW50OyB9CgouZGVmYXVsdC1wdXJwbGUtYzQ3MmRjZGItZjJiOC00MWFiLWJiMWUtMmZiMjkzZGYx NzJhIHsgYm94LXNoYWRvdzogcmdiKDI1NSwgMTcwLCAyNTUpIDBweCAwcHggMC4zNWVtOyBiYWNr Z3JvdW5kLWNvbG9yOiByZ2JhKDI1NSwgMTcwLCAyNTUsIDAuOCkgIWltcG9ydGFudDsgY29sb3I6 IHJnYigwLCAwLCAwKSAhaW1wb3J0YW50OyB9CgouZGVmYXVsdC1ncmV5LWRhN2NiOTAyLTg5YzYt NDZmZS1iMGU3LWQzYjM1YWFmMjM3YSB7IGJveC1zaGFkb3c6IHJnYigxMTksIDExOSwgMTE5KSAw cHggMHB4IDAuMzVlbTsgYmFja2dyb3VuZC1jb2xvcjogcmdiYSgxMTksIDExOSwgMTE5LCAwLjgp ICFpbXBvcnRhbnQ7IGNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSkgIWltcG9ydGFudDsgfTwvc3R5 bGU+PC9oZWFkPiAKPGJvZHkgZGF0YS1nci1jLXMtbG9hZGVkPSJ0cnVlIj4gCiAgPHRhYmxlIGJv cmRlcj0iMCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIwIj4gCiAgPHRib2R5Pjx0ciBp ZD0icGFydC0xIiBiZ2NvbG9yPSJvcmFuZ2UiPjx0aD48L3RoPjx0aD48YSBocmVmPSJodHRwczov L3Rvb2xzLmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLXNmYy1vYW0tZnJhbWV3b3Jr LTEzLnR4dCIgc3R5bGU9ImNvbG9yOiMwMDg7IHRleHQtZGVjb3JhdGlvbjpub25lOyI+Jmx0Ozwv YT4mbmJzcDs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1z ZmMtb2FtLWZyYW1ld29yay0xMy50eHQiIHN0eWxlPSJjb2xvcjojMDA4Ij5kcmFmdC1pZXRmLXNm Yy1vYW0tZnJhbWV3b3JrLTEzLnR4dDwvYT4mbmJzcDs8L3RoPjx0aD4gPC90aD48dGg+Jm5ic3A7 PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtc2ZjLW9hbS1m cmFtZXdvcmstMTQudHh0IiBzdHlsZT0iY29sb3I6IzAwOCI+ZHJhZnQtaWV0Zi1zZmMtb2FtLWZy YW1ld29yay0xNC50eHQ8L2E+Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9y ZmNkaWZmP3VybDE9ZHJhZnQtaWV0Zi1zZmMtb2FtLWZyYW1ld29yay0xNC50eHQiIHN0eWxlPSJj b2xvcjojMDA4OyB0ZXh0LWRlY29yYXRpb246bm9uZTsiPiZndDs8L2E+PC90aD48dGg+PC90aD48 L3RyPiAKICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij5JbnRlcm5ldCBFbmdpbmVlcmluZyBUYXNrIEZvcmNlICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBTLiBBbGRyaW48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij5JbnRl cm5ldCBFbmdpbmVlcmluZyBUYXNrIEZvcmNlICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBTLiBBbGRyaW48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPkludGVybmV0LURyYWZ0ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEdvb2dsZTwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPkludGVybmV0LURyYWZ0ICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEdvb2dsZTwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+SW50ZW5kZWQgc3RhdHVzOiBJbmZvcm1hdGlvbmFsICAgICAgICAg ICAgICAgICAgICAgICAgIEMuIFBpZ25hdGFybywgRWQuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+SW50ZW5kZWQgc3RhdHVzOiBJbmZvcm1hdGlvbmFsICAgICAgICAgICAgICAgICAg ICAgICAgIEMuIFBpZ25hdGFybywgRWQuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry PgogICAgICA8dHIgaWQ9ImRpZmYwMDAxIj48dGQ+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPkV4cGlyZXM6IE9jdG9iZXIgPHNw YW4gY2xhc3M9ImRlbGV0ZSI+MTY8L3NwYW4+LCAyMDIwICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIE4uIEt1bWFyLCBFZC48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ RXhwaXJlczogT2N0b2JlciA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij4yOTwvc3Bhbj4sIDIwMjAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTi4gS3VtYXIsIEVkLjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIENpc2NvPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIENpc2NvPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUi4g S3Jpc2huYW48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUi4gS3Jpc2huYW48 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFZNd2FyZTwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIFZNd2FyZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIEEuIEdoYW53YW5pPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IEEuIEdoYW53YW5pPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIERlbGw8 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIERlbGw8L3RkPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0iZGlmZjAwMDIiPjx0ZD48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9j ayI+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIEFwcmlsIDxzcGFuIGNsYXNzPSJkZWxldGUiPjE0PC9zcGFuPiwgMjAyMDwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgQXByaWwgPHNwYW4gY2xhc3M9Imluc2VydCI+Mjc8L3Nw YW4+LCAyMDIwPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAgICAg ICAgICAgU2VydmljZSBGdW5jdGlvbiBDaGFpbmluZyAoU0ZDKTwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPiAgICAgICAgICAgICAgICAgICAgU2VydmljZSBGdW5jdGlvbiBDaGFpbmlu ZyAoU0ZDKTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgIE9wZXJhdGlvbnMsIEFk bWluaXN0cmF0aW9uIGFuZCBNYWludGVuYW5jZSAoT0FNKSBGcmFtZXdvcms8L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgT3BlcmF0aW9ucywgQWRtaW5pc3RyYXRpb24gYW5k IE1haW50ZW5hbmNlIChPQU0pIEZyYW1ld29yazwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PC90cj4KICAgICAgPHRyIGlkPSJkaWZmMDAwMyI+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAgICAgICAgICAgICAg ICAgIGRyYWZ0LWlldGYtc2ZjLW9hbS1mcmFtZXdvcmstMTxzcGFuIGNsYXNzPSJkZWxldGUiPjM8 L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICAgICAgICAgICAgICAg ICAgZHJhZnQtaWV0Zi1zZmMtb2FtLWZyYW1ld29yay0xPHNwYW4gY2xhc3M9Imluc2VydCI+NDwv c3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+QWJzdHJhY3Q8L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij5BYnN0cmFjdDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij4gICBUaGlzIGRvY3VtZW50IHByb3ZpZGVzIGEgcmVmZXJlbmNlIGZyYW1ld29yayBm b3IgT3BlcmF0aW9ucyw8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBUaGlzIGRv Y3VtZW50IHByb3ZpZGVzIGEgcmVmZXJlbmNlIGZyYW1ld29yayBmb3IgT3BlcmF0aW9ucyw8L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIEFkbWluaXN0cmF0aW9uIGFuZCBNYWludGVuYW5j ZSAoT0FNKSBmb3IgU2VydmljZSBGdW5jdGlvbiBDaGFpbmluZzwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPiAgIEFkbWluaXN0cmF0aW9uIGFuZCBNYWludGVuYW5jZSAoT0FNKSBmb3Ig U2VydmljZSBGdW5jdGlvbiBDaGFpbmluZzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAg KFNGQykuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgKFNGQykuPC90ZD48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPlJlcXVpcmVtZW50cyBMYW5ndWFnZTwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPlJlcXVpcmVtZW50cyBMYW5ndWFnZTwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBUaGUga2V5IHdvcmRzICJNVVNUIiwgIk1VU1QgTk9UIiwg IlJFUVVJUkVEIiwgIlNIQUxMIiwgIlNIQUxMIE5PVCIsPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+ICAgVGhlIGtleSB3b3JkcyAiTVVTVCIsICJNVVNUIE5PVCIsICJSRVFVSVJFRCIs ICJTSEFMTCIsICJTSEFMTCBOT1QiLDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 L3RyPgogICAgICA8dHIgaWQ9InBhcnQtMiIgY2xhc3M9ImNoYW5nZSI+PHRkPjwvdGQ+PHRoPjxz bWFsbD5za2lwcGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvcmZjZGlmZiNwYXJ0LTIiPjxlbT4gcGFnZSAxLCBsaW5lIDQ3PHNwYW4gY2xhc3M9 ImhpZGUiPiDCtjwvc3Bhbj48L2VtPjwvYT48L3RoPjx0aD4gPC90aD48dGg+PHNtYWxsPnNraXBw aW5nIHRvIGNoYW5nZSBhdDwvc21hbGw+PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9y ZmNkaWZmI3BhcnQtMiI+PGVtPiBwYWdlIDEsIGxpbmUgNDc8c3BhbiBjbGFzcz0iaGlkZSI+IMK2 PC9zcGFuPjwvZW0+PC9hPjwvdGg+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgSW50ZXJuZXQtRHJhZnRzIGFyZSB3b3Jr aW5nIGRvY3VtZW50cyBvZiB0aGUgSW50ZXJuZXQgRW5naW5lZXJpbmc8L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij4gICBJbnRlcm5ldC1EcmFmdHMgYXJlIHdvcmtpbmcgZG9jdW1lbnRz IG9mIHRoZSBJbnRlcm5ldCBFbmdpbmVlcmluZzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ ICAgVGFzayBGb3JjZSAoSUVURikuICBOb3RlIHRoYXQgb3RoZXIgZ3JvdXBzIG1heSBhbHNvIGRp c3RyaWJ1dGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBUYXNrIEZvcmNlIChJ RVRGKS4gIE5vdGUgdGhhdCBvdGhlciBncm91cHMgbWF5IGFsc28gZGlzdHJpYnV0ZTwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgd29ya2luZyBkb2N1bWVudHMgYXMgSW50ZXJuZXQtRHJh ZnRzLiAgVGhlIGxpc3Qgb2YgY3VycmVudCBJbnRlcm5ldC08L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij4gICB3b3JraW5nIGRvY3VtZW50cyBhcyBJbnRlcm5ldC1EcmFmdHMuICBUaGUg bGlzdCBvZiBjdXJyZW50IEludGVybmV0LTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAg RHJhZnRzIGlzIGF0IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZHJhZnRzL2N1cnJlbnQv LjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIERyYWZ0cyBpcyBhdCBodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RyYWZ0cy9jdXJyZW50Ly48L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+ICAgSW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFmdCBkb2N1bWVudHMgdmFs aWQgZm9yIGEgbWF4aW11bSBvZiBzaXggbW9udGhzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+ICAgSW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFmdCBkb2N1bWVudHMgdmFsaWQgZm9yIGEg bWF4aW11bSBvZiBzaXggbW9udGhzPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBhbmQg bWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkgb3RoZXIgZG9jdW1lbnRz IGF0IGFueTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGFuZCBtYXkgYmUgdXBk YXRlZCwgcmVwbGFjZWQsIG9yIG9ic29sZXRlZCBieSBvdGhlciBkb2N1bWVudHMgYXQgYW55PC90 ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICB0aW1lLiAgSXQgaXMgaW5hcHByb3ByaWF0ZSB0 byB1c2UgSW50ZXJuZXQtRHJhZnRzIGFzIHJlZmVyZW5jZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPiAgIHRpbWUuICBJdCBpcyBpbmFwcHJvcHJpYXRlIHRvIHVzZSBJbnRlcm5ldC1E cmFmdHMgYXMgcmVmZXJlbmNlPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBtYXRlcmlh bCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAid29yayBpbiBwcm9ncmVzcy4iPC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgbWF0ZXJpYWwgb3IgdG8gY2l0ZSB0aGVtIG90 aGVyIHRoYW4gYXMgIndvcmsgaW4gcHJvZ3Jlc3MuIjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48L3RyPgogICAgICA8dHIgaWQ9ImRpZmYwMDA0Ij48dGQ+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIFRoaXMg SW50ZXJuZXQtRHJhZnQgd2lsbCBleHBpcmUgb24gT2N0b2JlciA8c3BhbiBjbGFzcz0iZGVsZXRl Ij4xNjwvc3Bhbj4sIDIwMjAuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIFRo aXMgSW50ZXJuZXQtRHJhZnQgd2lsbCBleHBpcmUgb24gT2N0b2JlciA8c3BhbiBjbGFzcz0iaW5z ZXJ0Ij4yOTwvc3Bhbj4sIDIwMjAuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPkNv cHlyaWdodCBOb3RpY2U8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij5Db3B5cmlnaHQg Tm90aWNlPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIENvcHlyaWdodCAoYykg MjAyMCBJRVRGIFRydXN0IGFuZCB0aGUgcGVyc29ucyBpZGVudGlmaWVkIGFzIHRoZTwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIENvcHlyaWdodCAoYykgMjAyMCBJRVRGIFRydXN0 IGFuZCB0aGUgcGVyc29ucyBpZGVudGlmaWVkIGFzIHRoZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+ICAgZG9jdW1lbnQgYXV0aG9ycy4gIEFsbCByaWdodHMgcmVzZXJ2ZWQuPC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgZG9jdW1lbnQgYXV0aG9ycy4gIEFsbCByaWdodHMg cmVzZXJ2ZWQuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFRoaXMgZG9jdW1l bnQgaXMgc3ViamVjdCB0byBCQ1AgNzggYW5kIHRoZSBJRVRGIFRydXN0J3MgTGVnYWw8L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBUaGlzIGRvY3VtZW50IGlzIHN1YmplY3QgdG8g QkNQIDc4IGFuZCB0aGUgSUVURiBUcnVzdCdzIExlZ2FsPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij4gICBQcm92aXNpb25zIFJlbGF0aW5nIHRvIElFVEYgRG9jdW1lbnRzPC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgUHJvdmlzaW9ucyBSZWxhdGluZyB0byBJRVRGIERvY3Vt ZW50czwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgKGh0dHBzOi8vdHJ1c3RlZS5pZXRm Lm9yZy9saWNlbnNlLWluZm8pIGluIGVmZmVjdCBvbiB0aGUgZGF0ZSBvZjwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPiAgIChodHRwczovL3RydXN0ZWUuaWV0Zi5vcmcvbGljZW5zZS1p bmZvKSBpbiBlZmZlY3Qgb24gdGhlIGRhdGUgb2Y8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgIHB1YmxpY2F0aW9uIG9mIHRoaXMgZG9jdW1lbnQuICBQbGVhc2UgcmV2aWV3IHRoZXNlIGRv Y3VtZW50czwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHB1YmxpY2F0aW9uIG9m IHRoaXMgZG9jdW1lbnQuICBQbGVhc2UgcmV2aWV3IHRoZXNlIGRvY3VtZW50czwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHIgaWQ9InBhcnQtMyIgY2xhc3M9 ImNoYW5nZSI+PHRkPjwvdGQ+PHRoPjxzbWFsbD5za2lwcGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxs PjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvcmZjZGlmZiNwYXJ0LTMiPjxlbT4gcGFn ZSAzLCBsaW5lIDEzPHNwYW4gY2xhc3M9ImhpZGUiPiDCtjwvc3Bhbj48L2VtPjwvYT48L3RoPjx0 aD4gPC90aD48dGg+PHNtYWxsPnNraXBwaW5nIHRvIGNoYW5nZSBhdDwvc21hbGw+PGEgaHJlZj0i aHR0cHM6Ly90b29scy5pZXRmLm9yZy9yZmNkaWZmI3BhcnQtMyI+PGVtPiBwYWdlIDMsIGxpbmUg MTM8c3BhbiBjbGFzcz0iaGlkZSI+IMK2PC9zcGFuPjwvZW0+PC9hPjwvdGg+PHRkPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAg ICAgIDYuNC4xLiAgSUNNUCAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gIDE1PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgIDYuNC4x LiAgSUNNUCAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g IDE1PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgNi40LjIuICBCRkQvU2VhbWxl c3MtQkZEICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTU8L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgNi40LjIuICBCRkQvU2VhbWxlc3MtQkZEICAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTU8L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPiAgICAgICA2LjQuMy4gIEluLVNpdHUgT0FNIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuICAxNjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PiAgICAgICA2LjQuMy4gIEluLVNpdHUgT0FNIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuICAxNjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgIDYuNC40 LiAgU0ZDIFRyYWNlcm91dGUgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g IDE2PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgIDYuNC40LiAgU0ZDIFRy YWNlcm91dGUgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDE2PC90ZD48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICA3LiAgTWFuYWdlYWJpbGl0eSBDb25zaWRlcmF0aW9u cyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTY8L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij4gICA3LiAgTWFuYWdlYWJpbGl0eSBDb25zaWRlcmF0aW9ucyAgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTY8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgIDguICBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuICAxNzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIDguICBT ZWN1cml0eSBDb25zaWRlcmF0aW9ucyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuICAxNzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgOS4gIElBTkEgQ29uc2lkZXJh dGlvbnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDE4PC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgOS4gIElBTkEgQ29uc2lkZXJhdGlvbnMgLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDE4PC90ZD48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij4gICAxMC4gQWNrbm93bGVkZ2VtZW50cyAgLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTg8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij4gICAxMC4gQWNrbm93bGVkZ2VtZW50cyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAgMTg8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIDExLiBD b250cmlidXRpbmcgQXV0aG9ycyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuICAxODwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIDExLiBDb250cmlidXRp bmcgQXV0aG9ycyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAxODwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgMTIuIFJlZmVyZW5jZXMgIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDE4PC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+ICAgMTIuIFJlZmVyZW5jZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDE4PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48L3RyPgogICAgICA8dHIgaWQ9ImRpZmYwMDA1Ij48dGQ+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgICAgMTIuMS4g IE5vcm1hdGl2ZSBSZWZlcmVuY2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu ICAxPHNwYW4gY2xhc3M9ImRlbGV0ZSI+ODwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJibG9jayI+ICAgICAxMi4xLiAgTm9ybWF0aXZlIFJlZmVyZW5jZXMgLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gIDE8c3BhbiBjbGFzcz0iaW5zZXJ0Ij45PC9zcGFuPjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAxMi4yLiAgSW5mb3JtYXRpdmUgUmVmZXJlbmNl cyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDE5PC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+ICAgICAxMi4yLiAgSW5mb3JtYXRpdmUgUmVmZXJlbmNlcyAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDE5PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij4gICBBdXRob3JzJyBBZGRyZXNzZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAgMjE8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBBdXRo b3JzJyBBZGRyZXNzZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAgMjE8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+MS4gIEludHJvZHVjdGlv bjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjEuICBJbnRyb2R1Y3Rpb248L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgU2VydmljZSBGdW5jdGlvbiBDaGFpbmluZyAo U0ZDKSBlbmFibGVzIHRoZSBjcmVhdGlvbiBvZiBjb21wb3NpdGU8L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij4gICBTZXJ2aWNlIEZ1bmN0aW9uIENoYWluaW5nIChTRkMpIGVuYWJsZXMg dGhlIGNyZWF0aW9uIG9mIGNvbXBvc2l0ZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAg c2VydmljZXMgdGhhdCBjb25zaXN0IG9mIGFuIG9yZGVyZWQgc2V0IG9mIFNlcnZpY2UgRnVuY3Rp b25zIChTRik8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBzZXJ2aWNlcyB0aGF0 IGNvbnNpc3Qgb2YgYW4gb3JkZXJlZCBzZXQgb2YgU2VydmljZSBGdW5jdGlvbnMgKFNGKTwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgdGhhdCBhcmUgdG8gYmUgYXBwbGllZCB0byBwYWNr ZXRzIGFuZC9vciBmcmFtZXMgc2VsZWN0ZWQgYXMgYSByZXN1bHQ8L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij4gICB0aGF0IGFyZSB0byBiZSBhcHBsaWVkIHRvIHBhY2tldHMgYW5kL29y IGZyYW1lcyBzZWxlY3RlZCBhcyBhIHJlc3VsdDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ ICAgb2YgY2xhc3NpZmljYXRpb24gW1JGQzc2NjVdLiAgU0ZDIGlzIGEgY29uY2VwdCB0aGF0IHBy b3ZpZGVzIGZvciBtb3JlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgb2YgY2xh c3NpZmljYXRpb24gW1JGQzc2NjVdLiAgU0ZDIGlzIGEgY29uY2VwdCB0aGF0IHByb3ZpZGVzIGZv ciBtb3JlPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICB0aGFuIGp1c3QgdGhlIGFwcGxp Y2F0aW9uIG9mIGFuIG9yZGVyZWQgc2V0IG9mIFNGcyB0byBzZWxlY3RlZDwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPiAgIHRoYW4ganVzdCB0aGUgYXBwbGljYXRpb24gb2YgYW4gb3Jk ZXJlZCBzZXQgb2YgU0ZzIHRvIHNlbGVjdGVkPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0icGFydC00IiBjbGFzcz0iY2hhbmdlIj48dGQ+PC90ZD48 dGg+PHNtYWxsPnNraXBwaW5nIHRvIGNoYW5nZSBhdDwvc21hbGw+PGEgaHJlZj0iaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9yZmNkaWZmI3BhcnQtNCI+PGVtPiBwYWdlIDE4LCBsaW5lIDk8c3BhbiBj bGFzcz0iaGlkZSI+IMK2PC9zcGFuPjwvZW0+PC9hPjwvdGg+PHRoPiA8L3RoPjx0aD48c21hbGw+ c2tpcHBpbmcgdG8gY2hhbmdlIGF0PC9zbWFsbD48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYu b3JnL3JmY2RpZmYjcGFydC00Ij48ZW0+IHBhZ2UgMTgsIGxpbmUgOTxzcGFuIGNsYXNzPSJoaWRl Ij4gwrY8L3NwYW4+PC9lbT48L2E+PC90aD48dGQ+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBpbmZvcm1hdGlvbiBjb2xsZWN0 ZWQgYXQgYW4gU0ZDIGNvbXBvbmVudCBtYXkgcmV2ZWFsIHRoZSBTRjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPiAgIGluZm9ybWF0aW9uIGNvbGxlY3RlZCBhdCBhbiBTRkMgY29tcG9u ZW50IG1heSByZXZlYWwgdGhlIFNGPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBhc3Nv Y2lhdGVkIHdpdGhpbiBlYWNoIGNoYWluIGFuZCB0aGlzIGluZm9ybWF0aW9uIHRvZ2V0aGVyIHdp dGg8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBhc3NvY2lhdGVkIHdpdGhpbiBl YWNoIGNoYWluIGFuZCB0aGlzIGluZm9ybWF0aW9uIHRvZ2V0aGVyIHdpdGg8L3RkPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPiAgIGNsYXNzaWZpZXIgcnVsZXMgbWF5IGJlIHVzZWQgdG8gbWFuaXB1 bGF0ZSB0aGUgaGVhZGVyIG9mIHN5bnRoZXRpYzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPiAgIGNsYXNzaWZpZXIgcnVsZXMgbWF5IGJlIHVzZWQgdG8gbWFuaXB1bGF0ZSB0aGUgaGVh ZGVyIG9mIHN5bnRoZXRpYzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgYXR0YWNrIHBh Y2tldHMgdGhhdCBtYXkgYmUgdXNlZCB0byBieXBhc3MgdGhlIFNGQyBhbmQgdHJpZ2dlciBhbnk8 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBhdHRhY2sgcGFja2V0cyB0aGF0IG1h eSBiZSB1c2VkIHRvIGJ5cGFzcyB0aGUgU0ZDIGFuZCB0cmlnZ2VyIGFueTwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+ICAgaW50ZXJuYWwgYXR0YWNrcy48L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij4gICBpbnRlcm5hbCBhdHRhY2tzLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij4gICBUaGUgU0YgaW5mb3JtYXRpb24gYXQgdGhlIFNGIGNvbXBvbmVudCBtYXkgYmUg dXNlZCBieSBhIG1hbGljaW91czwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFRo ZSBTRiBpbmZvcm1hdGlvbiBhdCB0aGUgU0YgY29tcG9uZW50IG1heSBiZSB1c2VkIGJ5IGEgbWFs aWNpb3VzPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICB1c2VyIHRvIHRyaWdnZXIgRGVu aWFsIG9mIFNlcnZpY2UgKERvUykgYXR0YWNrIGJ5IG92ZXJsb2FkaW5nIGFueTwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHVzZXIgdG8gdHJpZ2dlciBEZW5pYWwgb2YgU2Vydmlj ZSAoRG9TKSBhdHRhY2sgYnkgb3ZlcmxvYWRpbmcgYW55PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij4gICBzcGVjaWZpYyBTRiB1c2luZyByb2d1ZSBPQU0gdHJhZmZpYy48L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBzcGVjaWZpYyBTRiB1c2luZyByb2d1ZSBPQU0gdHJhZmZp Yy48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGlkPSJk aWZmMDAwNiI+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk Pjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBUbyBhZGRyZXNzIHRoZSBhYm92ZSBjb25jZXJucywgU0ZD IGFuZCBTRiBPQU0gPHNwYW4gY2xhc3M9ImRlbGV0ZSI+bWF5PC9zcGFuPiBwcm92aWRlIDxzcGFu IGNsYXNzPSJkZWxldGUiPm1lY2hhbmlzbTwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJibG9jayI+ICAgVG8gYWRkcmVzcyB0aGUgYWJvdmUgY29uY2VybnMsIFNGQyBhbmQgU0YgT0FN IDxzcGFuIGNsYXNzPSJpbnNlcnQiPnNob3VsZDwvc3Bhbj4gcHJvdmlkZTwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0 ZCBjbGFzcz0ibGJsb2NrIj4gICBmb3I6PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2si PiAgIDxzcGFuIGNsYXNzPSJpbnNlcnQiPm1lY2hhbmlzbXM8L3NwYW4+IGZvcjo8L3RkPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgbyAgTWlzdXNlIG9mIHRoZSBPQU0gY2hhbm5lbCBm b3IgZGVuaWFsLW9mLXNlcnZpY2VzLDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAg IG8gIE1pc3VzZSBvZiB0aGUgT0FNIGNoYW5uZWwgZm9yIGRlbmlhbC1vZi1zZXJ2aWNlcyw8L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgbyAgTGVha2FnZSBvZiBPQU0gcGFja2V0 cyBhY3Jvc3MgU0ZDIGluc3RhbmNlcywgYW5kPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+ICAgbyAgTGVha2FnZSBvZiBPQU0gcGFja2V0cyBhY3Jvc3MgU0ZDIGluc3RhbmNlcywgYW5k PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIG8gIExlYWthZ2Ugb2YgU0ZDIGlu Zm9ybWF0aW9uIGJleW9uZCB0aGUgU0ZDIGRvbWFpbi48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij4gICBvICBMZWFrYWdlIG9mIFNGQyBpbmZvcm1hdGlvbiBiZXlvbmQgdGhlIFNGQyBk b21haW4uPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFRoZSBkb2N1bWVudHMg cHJvcG9zaW5nIHRoZSBPQU0gc29sdXRpb24gZm9yIFNGIGNvbXBvbmVudCBzaG91bGQ8L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBUaGUgZG9jdW1lbnRzIHByb3Bvc2luZyB0aGUg T0FNIHNvbHV0aW9uIGZvciBTRiBjb21wb25lbnQgc2hvdWxkPC90ZD48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij4gICBjb25zaWRlciByYXRlLWxpbWl0aW5nIHRoZSBPQU0gcHJvYmVzIGF0IGEgZnJl cXVlbmN5IGd1aWRlZCBieSB0aGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBj b25zaWRlciByYXRlLWxpbWl0aW5nIHRoZSBPQU0gcHJvYmVzIGF0IGEgZnJlcXVlbmN5IGd1aWRl ZCBieSB0aGU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGltcGxlbWVudGF0aW9uIGNo b2ljZS4gIFJhdGUtbGltaXRpbmcgbWF5IGJlIGFwcGxpZWQgYXQgdGhlIFNGRiBvcjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGltcGxlbWVudGF0aW9uIGNob2ljZS4gIFJhdGUt bGltaXRpbmcgbWF5IGJlIGFwcGxpZWQgYXQgdGhlIFNGRiBvcjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+ICAgdGhlIFNGIC4gVGhlIE9BTSBpbml0aWF0b3IgbWF5IG5vdCByZWNlaXZlIGEg cmVzcG9uc2UgZm9yIHRoZSBwcm9iZXM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4g ICB0aGUgU0YgLiBUaGUgT0FNIGluaXRpYXRvciBtYXkgbm90IHJlY2VpdmUgYSByZXNwb25zZSBm b3IgdGhlIHByb2JlczwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgdGhhdCBhcmUgcmF0 ZS1saW1pdGVkIHJlc3VsdGluZyBpbiBmYWxzZSBuZWdhdGl2ZXMgYW5kIHRoZTwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHRoYXQgYXJlIHJhdGUtbGltaXRlZCByZXN1bHRpbmcg aW4gZmFsc2UgbmVnYXRpdmVzIGFuZCB0aGU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv dHI+CiAgICAgIDx0ciBpZD0iZGlmZjAwMDciPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgaW1wbGVtZW50YXRpb24g c2hvdWxkIGJlIGF3YXJlIG9mIHRoaXMuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2si PiAgIGltcGxlbWVudGF0aW9uIHNob3VsZCBiZSBhd2FyZSBvZiB0aGlzLiAgPHNwYW4gY2xhc3M9 Imluc2VydCI+VG8gbWl0aWdhdGUgYW55IGF0dGFja3MgdGhhdDwvc3Bhbj48L3RkPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFu IGNsYXNzPSJpbnNlcnQiPiAgIGxldmVyYWdlIE9BTSBwYWNrZXRzLCBmdXR1cmUgZG9jdW1lbnRz IHByb3Bvc2luZyBPQU0gc29sdXRpb25zIHNob3VsZDwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNz PSJpbnNlcnQiPiAgIGRlc2NyaWJlIHRoZSB1c2Ugb2YgYW55IHRlY2huaXF1ZSB0byBkZXRlY3Qg YW5kIG1pdGlnYXRlIGFub21hbGllczwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9j ayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQi PiAgIGFuZCB2YXJpb3VzIHNlY3VyaXR5IGF0dGFja3MuPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij4gICBUaGUgZG9jdW1lbnRzIHByb3Bvc2luZyB0aGUgT0FNIHNvbHV0 aW9uIGZvciBhbnkgc2VydmljZSBsYXllcjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PiAgIFRoZSBkb2N1bWVudHMgcHJvcG9zaW5nIHRoZSBPQU0gc29sdXRpb24gZm9yIGFueSBzZXJ2 aWNlIGxheWVyPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBjb21wb25lbnRzIHNob3Vs ZCBjb25zaWRlciBzb21lIGZvcm0gb2YgbWVzc2FnZSBmaWx0ZXJpbmcgdG8gcHJldmVudDwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGNvbXBvbmVudHMgc2hvdWxkIGNvbnNpZGVy IHNvbWUgZm9ybSBvZiBtZXNzYWdlIGZpbHRlcmluZyB0byBwcmV2ZW50PC90ZD48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij4gICBsZWFraW5nIGFueSBpbnRlcm5hbCBzZXJ2aWNlIGxheWVyIGluZm9y bWF0aW9uIG91dHNpZGUgdGhlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgbGVh a2luZyBhbnkgaW50ZXJuYWwgc2VydmljZSBsYXllciBpbmZvcm1hdGlvbiBvdXRzaWRlIHRoZTwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgYWRtaW5pc3RyYXRpdmUgZG9tYWluLjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGFkbWluaXN0cmF0aXZlIGRvbWFpbi48L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+OS4gIElBTkEgQ29uc2lkZXJhdGlvbnM8L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij45LiAgSUFOQSBDb25zaWRlcmF0aW9uczwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBObyBhY3Rpb24gaXMgcmVxdWlyZWQgYnkg SUFOQSBmb3IgdGhpcyBkb2N1bWVudC48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4g ICBObyBhY3Rpb24gaXMgcmVxdWlyZWQgYnkgSUFOQSBmb3IgdGhpcyBkb2N1bWVudC48L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KCiAgICAgPHRyPjx0ZD48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQ+PC90 ZD48L3RyPgogICAgIDx0ciBpZD0iZW5kIiBiZ2NvbG9yPSJncmF5Ij48dGggY29sc3Bhbj0iNSIg YWxpZ249ImNlbnRlciI+Jm5ic3A7RW5kIG9mIGNoYW5nZXMuIDcgY2hhbmdlIGJsb2Nrcy4mbmJz cDs8L3RoPjwvdHI+CiAgICAgPHRyIGNsYXNzPSJzdGF0cyI+PHRkPjwvdGQ+PHRoPjxpPjggbGlu ZXMgY2hhbmdlZCBvciBkZWxldGVkPC9pPjwvdGg+PHRoPjxpPiA8L2k+PC90aD48dGg+PGk+MTEg bGluZXMgY2hhbmdlZCBvciBhZGRlZDwvaT48L3RoPjx0ZD48L3RkPjwvdHI+CiAgICAgPHRyPjx0 ZCBjb2xzcGFuPSI1IiBhbGlnbj0iY2VudGVyIiBjbGFzcz0ic21hbGwiPjxicj5UaGlzIGh0bWwg ZGlmZiB3YXMgcHJvZHVjZWQgYnkgcmZjZGlmZiAxLjQ3LiBUaGUgbGF0ZXN0IHZlcnNpb24gaXMg YXZhaWxhYmxlIGZyb20gPGEgaHJlZj0iaHR0cDovL3d3dy50b29scy5pZXRmLm9yZy90b29scy9y ZmNkaWZmLyI+aHR0cDovL3Rvb2xzLmlldGYub3JnL3Rvb2xzL3JmY2RpZmYvPC9hPiA8L3RkPjwv dHI+CiAgIDwvdGJvZHk+PC90YWJsZT4KICAgCiAgIAo8ZGl2IGlkPSJkRSNlR3NifjE1ODc5ODQ4 OTIzMDAiPjwvZGl2PjwvYm9keT48L2h0bWw+ --_003_760DA3B53B1047868EC9B107BFEBAC28ciscocom_ Content-Type: text/plain; name="draft-ietf-sfc-oam-framework-14.txt" Content-Description: draft-ietf-sfc-oam-framework-14.txt Content-Disposition: attachment; filename="draft-ietf-sfc-oam-framework-14.txt"; size=47705; creation-date="Mon, 27 Apr 2020 14:35:41 GMT"; modification-date="Mon, 27 Apr 2020 14:35:41 GMT" Content-ID: Content-Transfer-Encoding: base64 CgoKCkludGVybmV0IEVuZ2luZWVyaW5nIFRhc2sgRm9yY2UgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIFMuIEFsZHJpbgpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBHb29nbGUKSW50ZW5kZWQgc3RhdHVzOiBJbmZv cm1hdGlvbmFsICAgICAgICAgICAgICAgICAgICAgICAgIEMuIFBpZ25hdGFybywgRWQuCkV4cGly ZXM6IE9jdG9iZXIgMjksIDIwMjAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTi4g S3VtYXIsIEVkLgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgQ2lzY28KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFIuIEtyaXNobmFuCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFZNd2Fy ZQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgQS4gR2hhbndhbmkKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBEZWxsCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBBcHJpbCAyNywgMjAyMAoKCiAgICAg ICAgICAgICAgICAgICAgU2VydmljZSBGdW5jdGlvbiBDaGFpbmluZyAoU0ZDKQogICAgICAgT3Bl cmF0aW9ucywgQWRtaW5pc3RyYXRpb24gYW5kIE1haW50ZW5hbmNlIChPQU0pIEZyYW1ld29yawog ICAgICAgICAgICAgICAgICAgIGRyYWZ0LWlldGYtc2ZjLW9hbS1mcmFtZXdvcmstMTQKCkFic3Ry YWN0CgogICBUaGlzIGRvY3VtZW50IHByb3ZpZGVzIGEgcmVmZXJlbmNlIGZyYW1ld29yayBmb3Ig T3BlcmF0aW9ucywKICAgQWRtaW5pc3RyYXRpb24gYW5kIE1haW50ZW5hbmNlIChPQU0pIGZvciBT ZXJ2aWNlIEZ1bmN0aW9uIENoYWluaW5nCiAgIChTRkMpLgoKUmVxdWlyZW1lbnRzIExhbmd1YWdl CgogICBUaGUga2V5IHdvcmRzICJNVVNUIiwgIk1VU1QgTk9UIiwgIlJFUVVJUkVEIiwgIlNIQUxM IiwgIlNIQUxMIE5PVCIsCiAgICJTSE9VTEQiLCAiU0hPVUxEIE5PVCIsICJSRUNPTU1FTkRFRCIs ICJOT1QgUkVDT01NRU5ERUQiLCAiTUFZIiwgYW5kCiAgICJPUFRJT05BTCIgaW4gdGhpcyBkb2N1 bWVudCBhcmUgdG8gYmUgaW50ZXJwcmV0ZWQgYXMgZGVzY3JpYmVkIGluIFJGQwogICAyMTE5IFtS RkMyMTE5XSBSRkMgODE3NCBbUkZDODE3NF0gd2hlbiBhbmQgb25seSB3aGVuLCB0aGV5IGFwcGVh ciBpbgogICBhbGwgY2FwaXRhbHMsIGFzIHNob3duIGhlcmUuCgpTdGF0dXMgb2YgVGhpcyBNZW1v CgogICBUaGlzIEludGVybmV0LURyYWZ0IGlzIHN1Ym1pdHRlZCBpbiBmdWxsIGNvbmZvcm1hbmNl IHdpdGggdGhlCiAgIHByb3Zpc2lvbnMgb2YgQkNQIDc4IGFuZCBCQ1AgNzkuCgogICBJbnRlcm5l dC1EcmFmdHMgYXJlIHdvcmtpbmcgZG9jdW1lbnRzIG9mIHRoZSBJbnRlcm5ldCBFbmdpbmVlcmlu ZwogICBUYXNrIEZvcmNlIChJRVRGKS4gIE5vdGUgdGhhdCBvdGhlciBncm91cHMgbWF5IGFsc28g ZGlzdHJpYnV0ZQogICB3b3JraW5nIGRvY3VtZW50cyBhcyBJbnRlcm5ldC1EcmFmdHMuICBUaGUg bGlzdCBvZiBjdXJyZW50IEludGVybmV0LQogICBEcmFmdHMgaXMgYXQgaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kcmFmdHMvY3VycmVudC8uCgogICBJbnRlcm5ldC1EcmFmdHMgYXJlIGRy YWZ0IGRvY3VtZW50cyB2YWxpZCBmb3IgYSBtYXhpbXVtIG9mIHNpeCBtb250aHMKICAgYW5kIG1h eSBiZSB1cGRhdGVkLCByZXBsYWNlZCwgb3Igb2Jzb2xldGVkIGJ5IG90aGVyIGRvY3VtZW50cyBh dCBhbnkKICAgdGltZS4gIEl0IGlzIGluYXBwcm9wcmlhdGUgdG8gdXNlIEludGVybmV0LURyYWZ0 cyBhcyByZWZlcmVuY2UKICAgbWF0ZXJpYWwgb3IgdG8gY2l0ZSB0aGVtIG90aGVyIHRoYW4gYXMg IndvcmsgaW4gcHJvZ3Jlc3MuIgoKICAgVGhpcyBJbnRlcm5ldC1EcmFmdCB3aWxsIGV4cGlyZSBv biBPY3RvYmVyIDI5LCAyMDIwLgoKCgoKCkFsZHJpbiwgZXQgYWwuICAgICAgICAgIEV4cGlyZXMg T2N0b2JlciAyOSwgMjAyMCAgICAgICAgICAgICAgICBbUGFnZSAxXQoMCkludGVybmV0LURyYWZ0 ICAgICAgICAgICAgICBTRkMgT0FNIEZyYW1ld29yayAgICAgICAgICAgICAgICAgQXByaWwgMjAy MAoKCkNvcHlyaWdodCBOb3RpY2UKCiAgIENvcHlyaWdodCAoYykgMjAyMCBJRVRGIFRydXN0IGFu ZCB0aGUgcGVyc29ucyBpZGVudGlmaWVkIGFzIHRoZQogICBkb2N1bWVudCBhdXRob3JzLiAgQWxs IHJpZ2h0cyByZXNlcnZlZC4KCiAgIFRoaXMgZG9jdW1lbnQgaXMgc3ViamVjdCB0byBCQ1AgNzgg YW5kIHRoZSBJRVRGIFRydXN0J3MgTGVnYWwKICAgUHJvdmlzaW9ucyBSZWxhdGluZyB0byBJRVRG IERvY3VtZW50cwogICAoaHR0cHM6Ly90cnVzdGVlLmlldGYub3JnL2xpY2Vuc2UtaW5mbykgaW4g ZWZmZWN0IG9uIHRoZSBkYXRlIG9mCiAgIHB1YmxpY2F0aW9uIG9mIHRoaXMgZG9jdW1lbnQuICBQ bGVhc2UgcmV2aWV3IHRoZXNlIGRvY3VtZW50cwogICBjYXJlZnVsbHksIGFzIHRoZXkgZGVzY3Jp YmUgeW91ciByaWdodHMgYW5kIHJlc3RyaWN0aW9ucyB3aXRoIHJlc3BlY3QKICAgdG8gdGhpcyBk b2N1bWVudC4gIENvZGUgQ29tcG9uZW50cyBleHRyYWN0ZWQgZnJvbSB0aGlzIGRvY3VtZW50IG11 c3QKICAgaW5jbHVkZSBTaW1wbGlmaWVkIEJTRCBMaWNlbnNlIHRleHQgYXMgZGVzY3JpYmVkIGlu IFNlY3Rpb24gNC5lIG9mCiAgIHRoZSBUcnVzdCBMZWdhbCBQcm92aXNpb25zIGFuZCBhcmUgcHJv dmlkZWQgd2l0aG91dCB3YXJyYW50eSBhcwogICBkZXNjcmliZWQgaW4gdGhlIFNpbXBsaWZpZWQg QlNEIExpY2Vuc2UuCgpUYWJsZSBvZiBDb250ZW50cwoKICAgMS4gIEludHJvZHVjdGlvbiAgLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICAzCiAgICAgMS4x LiAgRG9jdW1lbnQgU2NvcGUgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuICAgNAogICAgIDEuMi4gIEFjcm9ueW1zIGFuZCBUZXJtaW5vbG9neSAgLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAgIDQKICAgICAgIDEuMi4xLiAgQWNyb255bXMgIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA0CiAgICAgICAxLjIuMi4gIFRl cm1pbm9sb2d5IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNQog ICAyLiAgU0ZDIExheWVyaW5nIE1vZGVsICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAgIDUKICAgMy4gIFNGQyBPQU0gQ29tcG9uZW50cyAgLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA2CiAgICAgMy4xLiAgVGhlIFNGIENvbXBvbmVu dCAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNwogICAgICAgMy4x LjEuICBTRiBBdmFpbGFiaWxpdHkgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAgIDcKICAgICAgIDMuMS4yLiAgU0YgUGVyZm9ybWFuY2UgTWVhc3VyZW1lbnQgIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gICA4CiAgICAgMy4yLiAgVGhlIFNGQyBDb21wb25lbnQgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgOAogICAgICAgMy4yLjEuICBTRkMg QXZhaWxhYmlsaXR5ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDkKICAg ICAgIDMuMi4yLiAgU0ZDIFBlcmZvcm1hbmNlIE1lYXN1cmVtZW50IC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gICA5CiAgICAgMy4zLiAgVGhlIENsYXNzaWZpZXIgQ29tcG9uZW50ICAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgOQogICAgIDMuNC4gIFVuZGVybGF5IE5ldHdvcmsg IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTAKICAgICAzLjUuICBP dmVybGF5IE5ldHdvcmsgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g IDEwCiAgIDQuICBTRkMgT0FNIEZ1bmN0aW9ucyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuICAxMAogICAgIDQuMS4gIENvbm5lY3Rpdml0eSBGdW5jdGlvbnMgIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTAKICAgICA0LjIuICBDb250aW51aXR5 IEZ1bmN0aW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDExCiAgICAg NC4zLiAgVHJhY2UgRnVuY3Rpb25zIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuICAxMQogICAgIDQuNC4gIFBlcmZvcm1hbmNlIE1lYXN1cmVtZW50IEZ1bmN0aW9ucyAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTIKICAgNS4gIEdhcCBBbmFseXNpcyAgLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDEyCiAgICAgNS4xLiAgRXhp c3RpbmcgT0FNIEZ1bmN0aW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAx MgogICAgIDUuMi4gIE1pc3NpbmcgT0FNIEZ1bmN0aW9ucyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAgMTMKICAgICA1LjMuICBSZXF1aXJlZCBPQU0gRnVuY3Rpb25zICAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDEzCiAgIDYuICBDYW5kaWRhdGUgU0ZDIE9B TSBUb29scyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAxMwogICAgIDYu MS4gIFNGQyBPQU0gUGFja2V0IE1hcmtlciAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAgMTMKICAgICA2LjIuICBPQU0gUGFja2V0IFByb2Nlc3NpbmcgYW5kIEZvcndhcmRpbmcg U2VtYW50aWMgLiAuIC4gLiAuIC4gIDE0CiAgICAgNi4zLiAgT0FNIEZ1bmN0aW9uIFR5cGVzICAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAxNAogICAgIDYuNC4gIE9BTSBU b29sc2V0IEFwcGxpY2FiaWxpdHkgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTUK ICAgICAgIDYuNC4xLiAgSUNNUCAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gIDE1CgoKCkFsZHJpbiwgZXQgYWwuICAgICAgICAgIEV4cGlyZXMgT2N0b2Jl ciAyOSwgMjAyMCAgICAgICAgICAgICAgICBbUGFnZSAyXQoMCkludGVybmV0LURyYWZ0ICAgICAg ICAgICAgICBTRkMgT0FNIEZyYW1ld29yayAgICAgICAgICAgICAgICAgQXByaWwgMjAyMAoKCiAg ICAgICA2LjQuMi4gIEJGRC9TZWFtbGVzcy1CRkQgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuICAxNQogICAgICAgNi40LjMuICBJbi1TaXR1IE9BTSAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTYKICAgICAgIDYuNC40LiAgU0ZDIFRyYWNlcm91 dGUgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDE2CiAgIDcuICBNYW5h Z2VhYmlsaXR5IENvbnNpZGVyYXRpb25zICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu ICAxNgogICA4LiAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAgMTcKICAgOS4gIElBTkEgQ29uc2lkZXJhdGlvbnMgLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDE4CiAgIDEwLiBBY2tub3dsZWRnZW1l bnRzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAxOAogICAx MS4gQ29udHJpYnV0aW5nIEF1dGhvcnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAgMTgKICAgMTIuIFJlZmVyZW5jZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDE4CiAgICAgMTIuMS4gIE5vcm1hdGl2ZSBSZWZlcmVu Y2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAxOQogICAgIDEyLjIuICBJ bmZvcm1hdGl2ZSBSZWZlcmVuY2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAg MTkKICAgQXV0aG9ycycgQWRkcmVzc2VzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gIDIxCgoxLiAgSW50cm9kdWN0aW9uCgogICBTZXJ2aWNlIEZ1bmN0aW9u IENoYWluaW5nIChTRkMpIGVuYWJsZXMgdGhlIGNyZWF0aW9uIG9mIGNvbXBvc2l0ZQogICBzZXJ2 aWNlcyB0aGF0IGNvbnNpc3Qgb2YgYW4gb3JkZXJlZCBzZXQgb2YgU2VydmljZSBGdW5jdGlvbnMg KFNGKQogICB0aGF0IGFyZSB0byBiZSBhcHBsaWVkIHRvIHBhY2tldHMgYW5kL29yIGZyYW1lcyBz ZWxlY3RlZCBhcyBhIHJlc3VsdAogICBvZiBjbGFzc2lmaWNhdGlvbiBbUkZDNzY2NV0uICBTRkMg aXMgYSBjb25jZXB0IHRoYXQgcHJvdmlkZXMgZm9yIG1vcmUKICAgdGhhbiBqdXN0IHRoZSBhcHBs aWNhdGlvbiBvZiBhbiBvcmRlcmVkIHNldCBvZiBTRnMgdG8gc2VsZWN0ZWQKICAgdHJhZmZpYzsg cmF0aGVyLCBpdCBkZXNjcmliZXMgYSBtZXRob2QgZm9yIGRlcGxveWluZyBTRnMgaW4gYSB3YXkK ICAgdGhhdCBlbmFibGVzIGR5bmFtaWMgb3JkZXJpbmcgYW5kIHRvcG9sb2dpY2FsIGluZGVwZW5k ZW5jZSBvZiB0aG9zZQogICBTRnMgYXMgd2VsbCBhcyB0aGUgZXhjaGFuZ2Ugb2YgbWV0YWRhdGEg YmV0d2VlbiBwYXJ0aWNpcGF0aW5nCiAgIGVudGl0aWVzLiAgVGhlIGZvdW5kYXRpb25zIG9mIFNG QyBhcmUgZGVzY3JpYmVkIGluIHRoZSBmb2xsb3dpbmcKICAgZG9jdW1lbnRzOgoKICAgbyAgU0ZD IFByb2JsZW0gU3RhdGVtZW50IFtSRkM3NDk4XQoKICAgbyAgU0ZDIEFyY2hpdGVjdHVyZSBbUkZD NzY2NV0KCiAgIFRoZSByZWFkZXIgaXMgYXNzdW1lZCB0byBiZSBmYW1pbGlhciB3aXRoIHRoZSBt YXRlcmlhbCBpbiBbUkZDNzY2NV0uCgogICBUaGlzIGRvY3VtZW50IHByb3ZpZGVzIGEgcmVmZXJl bmNlIGZyYW1ld29yayBmb3IgT3BlcmF0aW9ucywKICAgQWRtaW5pc3RyYXRpb24gYW5kIE1haW50 ZW5hbmNlIChPQU0sIFtSRkM2MjkxXSkgb2YgU0ZDLgogICBTcGVjaWZpY2FsbHksIHRoaXMgZG9j dW1lbnQgcHJvdmlkZXM6CgogICBvICBJbiBTZWN0aW9uIDIsIGFuIFNGQyBsYXllcmluZyBtb2Rl bDsKCiAgIG8gIEluIFNlY3Rpb24gMywgYXNwZWN0cyBtb25pdG9yZWQgYnkgU0ZDIE9BTTsKCiAg IG8gIEluIFNlY3Rpb24gNCwgZnVuY3Rpb25hbCByZXF1aXJlbWVudHMgZm9yIFNGQyBPQU07Cgog ICBvICBJbiBTZWN0aW9uIDUsIGEgZ2FwIGFuYWx5c2lzIGZvciBTRkMgT0FNLgoKICAgbyAgSW4g U2VjdGlvbiA2LCBhcHBsaWNhYmlsaXR5IG9mIHZhcmlvdXMgT0FNIHRvb2xzLgoKICAgbyAgSW4g U2VjdGlvbiA3LCBtYW5hZ2VhYmlsaXR5IGNvbnNpZGVyYXRpb25zIGZvciBTRiBhbmQgU0ZDLgoK CgoKQWxkcmluLCBldCBhbC4gICAgICAgICAgRXhwaXJlcyBPY3RvYmVyIDI5LCAyMDIwICAgICAg ICAgICAgICAgIFtQYWdlIDNdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIFNGQyBPQU0g RnJhbWV3b3JrICAgICAgICAgICAgICAgICBBcHJpbCAyMDIwCgoKICAgU0ZDIE9BTSBzb2x1dGlv biBkb2N1bWVudHMgc2hvdWxkIHJlZmVyIHRvIHRoaXMgZG9jdW1lbnQgdG8gaW5kaWNhdGUKICAg dGhlIFNGQyBPQU0gY29tcG9uZW50IGFuZCB0aGUgZnVuY3Rpb25hbGl0eSB0aGV5IHRhcmdldC4K CiAgIE9BTSBjb250cm9sbGVycyBhcmUgYXNzdW1lZCB0byBiZSB3aXRoaW4gdGhlIHNhbWUgYWRt aW5pc3RyYXRpdmUKICAgZG9tYWluIGFzIHRoZSB0YXJnZXQgU0ZDIGVuYWJsZWQgZG9tYWluLgoK MS4xLiAgRG9jdW1lbnQgU2NvcGUKCiAgIFRoZSBmb2N1cyBvZiB0aGlzIGRvY3VtZW50IGlzIHRv IHByb3ZpZGUgYW4gYXJjaGl0ZWN0dXJhbCBmcmFtZXdvcmsKICAgZm9yIFNGQyBPQU0sIHBhcnRp Y3VsYXJseSBmb2N1c2VkIG9uIHRoZSBhc3BlY3Qgb2YgdGhlIE9wZXJhdGlvbnMKICAgY29tcG9u ZW50IHdpdGhpbiBPQU0uICBBY3R1YWwgc29sdXRpb25zIGFuZCBtZWNoYW5pc21zIGFyZSBvdXRz aWRlCiAgIHRoZSBzY29wZSBvZiB0aGlzIGRvY3VtZW50LgoKMS4yLiAgQWNyb255bXMgYW5kIFRl cm1pbm9sb2d5CgoxLjIuMS4gIEFjcm9ueW1zCgogICBTRkM6IFNlcnZpY2UgRnVuY3Rpb24gQ2hh aW4KCiAgIFNGRjogU2VydmljZSBGdW5jdGlvbiBGb3J3YXJkZXIKCiAgIFNGOiBTZXJ2aWNlIEZ1 bmN0aW9uCgogICBTRlA6IFNlcnZpY2UgRnVuY3Rpb24gUGF0aAoKICAgUlNQOiBSZW5kZXJlZCBT ZXJ2aWNlIFBhdGgKCiAgIE5TSDogTmV0d29yayBTZXJ2aWNlIEhlYWRlcgoKICAgVk06IFZpcnR1 YWwgTWFjaGluZXMKCiAgIE9BTTogT3BlcmF0aW9ucywgQWRtaW5pc3RyYXRpb24gYW5kIE1haW50 ZW5hbmNlCgogICBJUFBNOiBJUCBQZXJmb3JtYW5jZSBNZWFzdXJlbWVudAoKICAgQkZEOiBCaWRp cmVjdGlvbmFsIEZvcndhcmRpbmcgRGV0ZWN0aW9uCgogICBOVk8zOiBOZXR3b3JrIFZpcnR1YWxp emF0aW9uIG92ZXIgTGF5ZXIzCgogICBTTk1QOiBTaW1wbGUgTmV0d29yayBNYW5hZ2VtZW50IFBy b3RvY29sCgogICBORVRDT05GOiBOZXR3b3JrIENvbmZpZ3VyYXRpb24gUHJvdG9jb2wKCiAgIEUt T0FNOiBFdGhlcm5ldCBPQU0KCiAgIE1QTFNfUE06IE1QTFMgUGVyZm9ybWFuY2UgTWVhc3VyZW1l bnQKCgoKCgpBbGRyaW4sIGV0IGFsLiAgICAgICAgICBFeHBpcmVzIE9jdG9iZXIgMjksIDIwMjAg ICAgICAgICAgICAgICAgW1BhZ2UgNF0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgU0ZD IE9BTSBGcmFtZXdvcmsgICAgICAgICAgICAgICAgIEFwcmlsIDIwMjAKCgoxLjIuMi4gIFRlcm1p bm9sb2d5CgogICBUaGlzIGRvY3VtZW50IHVzZXMgdGhlIHRlcm1pbm9sb2dpZXMgZGVmaW5lZCBp biBbUkZDNzY2NV0sIFtSRkM4MzAwXSwKICAgYW5kIHNvIHRoZSByZWFkZXJzIGFyZSBleHBlY3Rl ZCB0byBiZSBmYW1pbGlhciB3aXRoIHRoZQogICB0ZXJtaW5vbG9naWVzLgoKMi4gIFNGQyBMYXll cmluZyBNb2RlbAoKICAgTXVsdGlwbGUgbGF5ZXJzIGNvbWUgaW50byBwbGF5IGZvciBpbXBsZW1l bnRpbmcgdGhlIFNGQy4gIFRoZXNlCiAgIGluY2x1ZGUgdGhlIHNlcnZpY2UgbGF5ZXIgYW5kIHRo ZSB1bmRlcmx5aW5nIGxheWVycyAoTmV0d29yayBMYXllciwKICAgTGluayBMYXllciwgZXRjLiku CgogICBvICBUaGUgc2VydmljZSBsYXllciwgd2hpY2ggY29uc2lzdHMgb2YgU0ZDIGRhdGEgcGxh bmUgZWxlbWVudHMgdGhhdAogICAgICBpbmNsdWRlcyBjbGFzc2lmaWVycywgU2VydmljZSBGdW5j dGlvbnMgKFNGKSwgU2VydmljZSBGdW5jdGlvbgogICAgICBGb3J3YXJkZXJzIChTRkYpLCBhbmQg U0ZDIFByb3hpZXMuICBUaGlzIGxheWVyIHVzZXMgdGhlIG92ZXJsYXkKICAgICAgbmV0d29yayBm b3IgZW5zdXJpbmcgY29ubmVjdGl2aXR5IGJldHdlZW4gU0ZDIGRhdGEgcGxhbmUgZWxlbWVudHMu CgogICBvICBUaGUgb3ZlcmxheSBuZXR3b3JrIGxheWVyLCB3aGljaCBsZXZlcmFnZXMgdmFyaW91 cyBvdmVybGF5IG5ldHdvcmsKICAgICAgdGVjaG5vbG9naWVzIGludGVyY29ubmVjdGluZyBTRkMg ZGF0YSBwbGFuZSBlbGVtZW50cyBhbmQgYWxsb3dzCiAgICAgIGVzdGFibGlzaGluZyBTZXJ2aWNl IEZ1bmN0aW9uIFBhdGhzIChTRlBzKS4gIFRoaXMgbGF5ZXIgaXMgbW9zdGx5CiAgICAgIHRyYW5z cGFyZW50IHRvIHRoZSBTRkMgZGF0YSBwbGFuZSBlbGVtZW50cy4KCiAgIG8gIFRoZSB1bmRlcmxh eSBuZXR3b3JrIGxheWVyLCB3aGljaCBpcyBkaWN0YXRlZCBieSB0aGUgbmV0d29ya2luZwogICAg ICB0ZWNobm9sb2d5IGRlcGxveWVkIHdpdGhpbiBhIG5ldHdvcmsgKGUuZy4sIElQLCBNUExTKQoK ICAgbyAgVGhlIGxpbmsgbGF5ZXIsIHdoaWNoIGlzIHRpZ2h0bHkgY291cGxlZCB3aXRoIHRoZSBw aHlzaWNhbAogICAgICB0ZWNobm9sb2d5IHVzZWQuICBFdGhlcm5ldCBpcyBhIHBvcHVsYXIgY2hv aWNlIGZvciB0aGlzIGxheWVyLCBidXQKICAgICAgb3RoZXIgYWx0ZXJuYXRpdmVzIGFyZSBkZXBs b3llZCAoZS5nLiAgUE9TLCBEV0RNKS4gIFRoZSBzYW1lIG9yCiAgICAgIGRpc3RpbmN0IGxpbmsg bGF5ZXIgdGVjaG5vbG9naWVzIG1heSBiZSB1c2VkIGluIGVhY2ggbGVnIHNob3duIGluCiAgICAg IEZpZ3VyZSAxLgoKICAgICAgby0tLS0tLS0tLS0tLS0tLS0tLS0tLS1TZXJ2aWNlIExheWVyLS0t LS0tLS0tLS0tLS0tLS0tLS0tLW8KCiAgICstLS0tLS0rICAgKy0tLSsgICArLS0tKyAgICstLS0r ICAgKy0tLSsgICArLS0tKyAgICstLS0rICAgKy0tLSsKICAgfENsYXNzaXwtLS18U0YxfC0tLXxT RjJ8LS0tfFNGM3wtLS18U0Y0fC0tLXxTRjV8LS0tfFNGNnwtLS18U0Y3fAogICB8ZmllciAgfCAg ICstLS0rICAgKy0tLSsgICArLS0tKyAgICstLS0rICAgKy0tLSsgICArLS0tKyAgICstLS0rCiAg ICstLS0tLS0rCiAgICAgICAgICAgICAgICA8LS0tLS0tVk0xLS0tLS0tPiAgICAgICA8LS1WTTIt LT4gICAgICAgPC0tVk0zLS0+CgogICAgICBeLS0tLS0tLS0tLS0tLS0tLS1eLS0tLS0tLS0tLS0t LS0tLS0tLV4tLS0tLS0tLS0tLS0tLS1eICBPdmVybGF5CiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE5ldHdvcmsKCiAgICAgIG8t LS0tLS0tLS0tLS0tLS0tLW8tLS0tLS0tLS0tLS0tLS0tLS0tby0tLS0tLS0tLS0tLS0tLW8gIFVu ZGVybGF5CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIE5ldHdvcmsKCiAgICAgIG8tLS0tLS0tLW8tLS0tLS0tLW8tLS0tLS0tLW8t LS0tLS0tLW8tLS0tLS0tLW8tLS0tLS0tLW8gIExpbmsKCiAgICAgICAgICAgICAgICBGaWd1cmUg MTogU0ZDIExheWVyaW5nIEV4YW1wbGUKCgoKQWxkcmluLCBldCBhbC4gICAgICAgICAgRXhwaXJl cyBPY3RvYmVyIDI5LCAyMDIwICAgICAgICAgICAgICAgIFtQYWdlIDVdCgwKSW50ZXJuZXQtRHJh ZnQgICAgICAgICAgICAgIFNGQyBPQU0gRnJhbWV3b3JrICAgICAgICAgICAgICAgICBBcHJpbCAy MDIwCgoKICAgSW4gRmlndXJlIDEsIHRoZSBzZXJ2aWNlIGxheWVyIGVsZW1lbnQgc3VjaCBhcyBj bGFzc2lmaWVyIGFuZCBTRiBhcmUKICAgZGVwaWN0ZWQgYXMgdmlydHVhbCBtYWNoaW5lcyB0aGF0 IGFyZSBpbnRlcmNvbm5lY3RlZCB1c2luZyBhbiBvdmVybGF5CiAgIG5ldHdvcmsuICBUaGUgdW5k ZXJsYXkgbmV0d29yayBtYXkgY29tcHJpc2Ugb2YgbXVsdGlwbGUgaW50ZXJtZWRpYXRlCiAgIG5v ZGVzIGJ1dCBub3Qgc2hvd24gaW4gdGhlIGZpZ3VyZSB0aGF0IHByb3ZpZGVzIHVuZGVybGF5IGNv bm5lY3Rpdml0eQogICBiZXR3ZWVuIHRoZSBzZXJ2aWNlIGxheWVyIGVsZW1lbnRzLgoKICAgV2hp bGUgRmlndXJlIDEgZGVwaWN0cyBhbiBleGFtcGxlIHdoZXJlIFNGcyBhcmUgZW5hYmxlZCBhcyB2 aXJ0dWFsCiAgIGVudGl0aWVzLCB0aGUgU0ZDIGFyY2hpdGVjdHVyZSBkb2VzIG5vdCBtYWtlIGFu eSBhc3N1bXB0aW9ucyBvbiBob3cKICAgdGhlIFNGQyBkYXRhIHBsYW5lIGVsZW1lbnRzIGFyZSBk ZXBsb3llZC4gIFRoZSBTRkMgYXJjaGl0ZWN0dXJlIGlzCiAgIGZsZXhpYmxlIGFuZCBhY2NvbW1v ZGF0ZXMgcGh5c2ljYWwgb3IgdmlydHVhbCBlbnRpdHkgZGVwbG95bWVudC4gIFNGQwogICBPQU0g YWNjb3VudHMgZm9yIHRoaXMgZmxleGliaWxpdHkgYW5kIGFjY29yZGluZ2x5IGl0IGlzIGFwcGxp Y2FibGUKICAgd2hldGhlciBTRkMgZGF0YSBwbGFuZSBlbGVtZW50cyBhcmUgZGVwbG95ZWQgZGly ZWN0bHkgb24gcGh5c2ljYWwKICAgaGFyZHdhcmUsIGFzIG9uZSBvciBtb3JlIFZpcnR1YWwgTWFj aGluZXMsIG9yIGFueSBjb21iaW5hdGlvbgogICB0aGVyZW9mLgoKMy4gIFNGQyBPQU0gQ29tcG9u ZW50cwoKICAgVGhlIFNGQyBvcGVyYXRlcyBhdCB0aGUgc2VydmljZSBsYXllci4gIEZvciB0aGUg cHVycG9zZSBvZiBkZWZpbmluZwogICB0aGUgT0FNIGZyYW1ld29yaywgdGhlIHNlcnZpY2UgbGF5 ZXIgaXMgYnJva2VuIHVwIGludG8gdGhyZWUgZGlzdGluY3QKICAgY29tcG9uZW50czoKCiAgIDEu ICBTRiBjb21wb25lbnQ6IE9BTSBmdW5jdGlvbnMgYXBwbGljYWJsZSBhdCB0aGlzIGNvbXBvbmVu dCBpbmNsdWRlcwogICAgICAgdGVzdGluZyB0aGUgU0ZzIGZyb20gYW55IFNGQy1hd2FyZSBuZXR3 b3JrIGRldmljZXMgKGUuZy4sCiAgICAgICBjbGFzc2lmaWVycywgY29udHJvbGxlcnMsIG90aGVy IHNlcnZpY2Ugbm9kZXMpLiAgVGVzdGluZyBhbiBTRgogICAgICAgbWF5IG5vdCBiZSByZXN0cmlj dGVkIHRvIGNvbm5lY3Rpdml0eSB0byB0aGUgU0YsIGJ1dCBhbHNvIHdoZXRoZXIKICAgICAgIHRo ZSBTRiBpcyBwcm92aWRpbmcgaXRzIGludGVuZGVkIHNlcnZpY2UuICBSZWZlciB0byBTZWN0aW9u IDMuMS4xCiAgICAgICBmb3IgYSBtb3JlIGRldGFpbGVkIGRpc2N1c3Npb24uCgogICAyLiAgU0ZD IGNvbXBvbmVudDogT0FNIGZ1bmN0aW9ucyBhcHBsaWNhYmxlIGF0IHRoaXMgY29tcG9uZW50CiAg ICAgICBpbmNsdWRlcyAoYnV0IGFyZSBub3QgbGltaXRlZCB0bykgdGVzdGluZyB0aGUgc2Vydmlj ZSBmdW5jdGlvbgogICAgICAgY2hhaW5zIGFuZCB0aGUgU0ZQcywgdmFsaWRhdGlvbiBvZiB0aGUg Y29ycmVsYXRpb24gYmV0d2VlbiBhbiBTRkMKICAgICAgIGFuZCB0aGUgYWN0dWFsIGZvcndhcmRp bmcgcGF0aCBmb2xsb3dlZCBieSBhIHBhY2tldCBtYXRjaGluZyB0aGF0CiAgICAgICBTRkMsIGku ZS4gdGhlIFJlbmRlcmVkIFNlcnZpY2UgUGF0aCAoUlNQKS4gIFNvbWUgb2YgdGhlIGhvcHMgb2YK ICAgICAgIGFuIFNGQyBtYXkgbm90IGJlIHZpc2libGUgd2hlbiBIaWVyYXJjaGljYWwgU2Vydmlj ZSBGdW5jdGlvbgogICAgICAgQ2hhaW5pbmcgKGhTRkMpIFtSRkM4NDU5XSBpcyBpbiB1c2UuICBJ biBzdWNoIHNjaGVtZXMsIGl0IGlzIHRoZQogICAgICAgcmVzcG9uc2liaWxpdHkgb2YgdGhlIElu dGVybmFsIEJvdW5kYXJ5IE5vZGUgKElCTikgdG8gZ2x1ZSB0aGUKICAgICAgIGNvbm5lY3Rpdml0 eSBiZXR3ZWVuIGRpZmZlcmVudCBsZXZlbHMgZm9yIGVuZC10by1lbmQgT0FNCiAgICAgICBmdW5j dGlvbmFsaXR5LgoKICAgMy4gIENsYXNzaWZpZXIgY29tcG9uZW50OiBPQU0gZnVuY3Rpb25zIGFw cGxpY2FibGUgYXQgdGhpcyBjb21wb25lbnQKICAgICAgIGluY2x1ZGVzIHRlc3RpbmcgdGhlIHZh bGlkaXR5IG9mIHRoZSBjbGFzc2lmaWNhdGlvbiBydWxlcyBhbmQKICAgICAgIGRldGVjdGluZyBh bnkgaW5jb2hlcmVuY2UgYW1vbmcgdGhlIHJ1bGVzIGluc3RhbGxlZCBpbiBkaWZmZXJlbnQKICAg ICAgIGNsYXNzaWZpZXJzLgoKICAgRmlndXJlIDIgaWxsdXN0cmF0ZXMgYW4gZXhhbXBsZSB3aGVy ZSBPQU0gZm9yIHRoZSB0aHJlZSBkZWZpbmVkCiAgIGNvbXBvbmVudHMgYXJlIHVzZWQgd2l0aGlu IHRoZSBTRkMgZW52aXJvbm1lbnQuCgoKCgoKQWxkcmluLCBldCBhbC4gICAgICAgICAgRXhwaXJl cyBPY3RvYmVyIDI5LCAyMDIwICAgICAgICAgICAgICAgIFtQYWdlIDZdCgwKSW50ZXJuZXQtRHJh ZnQgICAgICAgICAgICAgIFNGQyBPQU0gRnJhbWV3b3JrICAgICAgICAgICAgICAgICBBcHJpbCAy MDIwCgoKICstQ2xhc3NpZmllciAgKy1TZXJ2aWNlIEZ1bmN0aW9uIENoYWluIE9BTQogfCBPQU0g ICAgICAgICB8CiB8ICAgICAgICAgICAgIHwgICAgICAgIF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18KIHwgICAgICAgICAgICAgIFwgICAgICAvXCAgICAgICAgICBT ZXJ2aWNlIEZ1bmN0aW9uIENoYWluICAgICAgICAgIFwKIHwgICAgICAgICAgICAgICBcICAgIC8g IFwgICAgICArLS0tKyAgICAgICstLS0rICAgICArLS0tLS0rICArLS0tKyBcCiB8ICAgICAgICAg ICAgICAgIFwgIC8gICAgXCAgICAgfFNGMXwgICAgICB8U0YyfCAgICAgfFByb3h5fC0tfFNGM3wg IFwKIHwgICAgICArLS0tLS0tKyAgIFwvICAgICAgXCAgICArLS0tKyAgICAgICstLS0rICAgICAr LS0tLS0rICArLS0tKyAgIFwKICstLS0tPiB8ICAgICAgfC4uLi4oKy0+ICAgICkgICAgIHwgICAg ICAgICAgfCAgICAgICAgIHwgICAgICAgICAgICAgICApCiAgICAgICAgfENsYXNzaXwgICAgXCAg ICAgIC8gICArLS0tLS0rICAgICstLS0tLSsgICAgKy0tLS0tKyAgICAgICAgICAvCiAgICAgICAg fGZpZXIgIHwgICAgIFwgICAgLyAgICB8IFNGRjF8LS0tLXwgU0ZGMnwtLS0tfCBTRkYzfCAgICAg ICAgIC8KICAgICAgICB8ICAgICAgfCAgICAgIFwgIC8gICAgICstLV4tLSsgICAgKy0tLS0tKyAg ICArLS0tLS0rICAgICAgICAvCiAgICAgICAgKy0tLS18LSsgICAgICAgXC9fX19fX19fX198X19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18vCiAgICAgICAgICAgICB8ICAgICAgICAgICAg ICAgICAgICB8CiAgICAgICAgICAgICArLS0tLS0tLVNGX09BTS0tLS0tLS0rCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLSsgICArLS0tKwogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICArU0ZfT0FNPnxTRjN8ICAgfFNGNXwKICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgfCAgICAgICArLV4tKyAgICstXi0rCiAgICAgICAgICAgICAgICAgICAgICAgKy0t LS0tLXwtLS0rICAgICB8ICAgICAgIHwKICAgICAgICAgICAgICAgICAgICAgICB8Q29udHJvbGxl cnwgICAgICstU0ZfT0FNKwogICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tKwogICAg ICAgICAgICAgICAgICAgICAgICAgICAgU2VydmljZSBGdW5jdGlvbiBPQU0gKFNGX09BTSkKCiAg ICAgICAgICAgICAgRmlndXJlIDI6IFNGQyBPQU0gQ29tcG9uZW50cwoKICAgSXQgaXMgZXhwZWN0 ZWQgdGhhdCBtdWx0aXBsZSBTRkMgT0FNIHNvbHV0aW9ucyB3aWxsIGJlIGRlZmluZWQsIGVhY2gK ICAgdGFyZ2V0aW5nIG9uZSBzcGVjaWZpYyBjb21wb25lbnQgb2YgdGhlIHNlcnZpY2UgbGF5ZXIu ICBIb3dldmVyLCBpdAogICBpcyBjcml0aWNhbCB0aGF0IFNGQyBPQU0gc29sdXRpb25zIHRvZ2V0 aGVyIHByb3ZpZGUgdGhlIGNvdmVyYWdlIG9mCiAgIGFsbCB0aHJlZSBTRkMgT0FNIGNvbXBvbmVu dHM6IHRoZSBTRiBjb21wb25lbnQsIHRoZSBTRkMgY29tcG9uZW50LAogICBhbmQgdGhlIGNsYXNz aWZpZXIgY29tcG9uZW50LgoKMy4xLiAgVGhlIFNGIENvbXBvbmVudAoKMy4xLjEuICBTRiBBdmFp bGFiaWxpdHkKCiAgIE9uZSBTRkMgT0FNIHJlcXVpcmVtZW50IGZvciB0aGUgU0YgY29tcG9uZW50 IGlzIHRvIGFsbG93IGFuIFNGQy1hd2FyZQogICBuZXR3b3JrIGRldmljZSB0byBjaGVjayB0aGUg YXZhaWxhYmlsaXR5IG9mIGEgc3BlY2lmaWMgU0YgKGluc3RhbmNlKSwKICAgbG9jYXRlZCBvbiB0 aGUgc2FtZSBvciBkaWZmZXJlbnQgbmV0d29yayBkZXZpY2UocykuICBGb3IgY2FzZXMgd2hlcmUK ICAgbXVsdGlwbGUgaW5zdGFuY2VzIG9mIGFuIFNGIGFyZSB1c2VkIHRvIHJlYWxpemUgYSBnaXZl biBTRiBmb3IgdGhlCiAgIHB1cnBvc2Ugb2YgbG9hZCBzaGFyaW5nLCBTRiBhdmFpbGFiaWxpdHkg Y2FuIGJlIHBlcmZvcm1lZCBieSBjaGVja2luZwogICB0aGUgYXZhaWxhYmlsaXR5IG9mIGFueSBv bmUgb2YgdGhvc2UgaW5zdGFuY2VzLCBvciB0aGUgYXZhaWxhYmlsaXR5CiAgIGNoZWNrIG1heSBi ZSB0YXJnZXRlZCBhdCBhIHNwZWNpZmljIGluc3RhbmNlLiAgU0YgYXZhaWxhYmlsaXR5IGlzIGFu CiAgIGFzcGVjdCB0aGF0IHJhaXNlcyBhbiBpbnRlcmVzdGluZyBxdWVzdGlvbiAtLSBIb3cgdG8g ZGV0ZXJtaW5lIHRoYXQgYQogICBzZXJ2aWNlIGZ1bmN0aW9uIGlzIGF2YWlsYWJsZT8uICBPbiBv bmUgZW5kIG9mIHRoZSBzcGVjdHJ1bSwgb25lCiAgIG1pZ2h0IGFyZ3VlIHRoYXQgYW4gU0YgaXMg c3VmZmljaWVudGx5IGF2YWlsYWJsZSBpZiB0aGUgc2VydmljZSBub2RlCiAgIChwaHlzaWNhbCBv ciB2aXJ0dWFsKSBob3N0aW5nIHRoZSBTRiBpcyBhdmFpbGFibGUgYW5kIGlzIGZ1bmN0aW9uYWwu CiAgIE9uIHRoZSBvdGhlciBlbmQgb2YgdGhlIHNwZWN0cnVtLCBvbmUgbWlnaHQgYXJndWUgdGhh dCB0aGUgU0YncwogICBhdmFpbGFiaWxpdHkgY2FuIG9ubHkgYmUgY29uY2x1ZGVkIGlmIHRoZSBw YWNrZXQsIGFmdGVyIHBhc3NpbmcKCgoKCkFsZHJpbiwgZXQgYWwuICAgICAgICAgIEV4cGlyZXMg T2N0b2JlciAyOSwgMjAyMCAgICAgICAgICAgICAgICBbUGFnZSA3XQoMCkludGVybmV0LURyYWZ0 ICAgICAgICAgICAgICBTRkMgT0FNIEZyYW1ld29yayAgICAgICAgICAgICAgICAgQXByaWwgMjAy MAoKCiAgIHRocm91Z2ggdGhlIFNGLCB3YXMgZXhhbWluZWQgYW5kIGl0IHdhcyB2ZXJpZmllZCB0 aGF0IHRoZSBwYWNrZXQgZGlkCiAgIGluZGVlZCBnZXQgdGhlIGdvdCBleHBlY3RlZCBzZXJ2aWNl LgoKICAgVGhlIGZvcm1lciBhcHByb2FjaCB3aWxsIGxpa2VseSBub3QgcHJvdmlkZSBzdWZmaWNp ZW50IGNvbmZpZGVuY2UgdG8KICAgdGhlIGFjdHVhbCBTRiBhdmFpbGFiaWxpdHksIGkuZS4gYSBz ZXJ2aWNlIG5vZGUgYW5kIGEgU0YgYXJlIHR3bwogICBkaWZmZXJlbnQgZW50aXRpZXMuICBUaGUg bGF0dGVyIGFwcHJvYWNoIGlzIGNhcGFibGUgb2YgcHJvdmlkaW5nIGFuCiAgIGV4dGVuc2l2ZSB2 ZXJpZmljYXRpb24sIGJ1dCBjb21lcyBhdCBhIGNvc3QuICBTb21lIFNGcyBtYWtlIGRpcmVjdAog ICBtb2RpZmljYXRpb25zIHRvIHBhY2tldHMsIHdoaWxlIG90aGVycyBkbyBub3QuICBBZGRpdGlv bmFsbHksIHRoZQogICBwdXJwb3NlIG9mIHNvbWUgU0ZzIG1heSBiZSB0bywgY29uZGl0aW9uYWxs eSwgZHJvcCBwYWNrZXRzCiAgIGludGVudGlvbmFsbHkuICBJbiBzdWNoIGNhc2VzLCBpdCBpcyBu b3JtYWwgYmVoYXZpb3IgdGhhdCBjZXJ0YWluCiAgIHBhY2tldHMgd2lsbCBub3QgYmUgZWdyZXNz aW5nIG91dCBmcm9tIHRoZSBzZXJ2aWNlIGZ1bmN0aW9uLiAgVGhlIE9BTQogICBtZWNoYW5pc20g bmVlZHMgdG8gdGFrZSBpbnRvIGFjY291bnQgc3VjaCBTRiBzcGVjaWZpY3Mgd2hlbiBhc3Nlc3Np bmcKICAgU0YgYXZhaWxhYmlsaXR5LiAgTm90ZSB0aGF0IHRoZXJlIGFyZSBtYW55IGZsYXZvcnMg b2YgU0ZzIGF2YWlsYWJsZSwKICAgYW5kIG1hbnkgbW9yZSB0aGF0IGFyZSBsaWtlbHkgYmUgaW50 cm9kdWNlZCBpbiBmdXR1cmUuICBFdmVuIGEgZ2l2ZW4KICAgU0YgbWF5IGludHJvZHVjZSBhIG5l dyBmdW5jdGlvbmFsaXR5IChlLmcuLCBhIG5ldyBzaWduYXR1cmUgaW4gYQogICBmaXJld2FsbCku ICBUaGUgY29zdCBvZiB0aGlzIGFwcHJvYWNoIGlzIHRoYXQgdGhlIE9BTSBtZWNoYW5pc20gZm9y CiAgIHNvbWUgU0Ygd2lsbCBuZWVkIHRvIGJlIGNvbnRpbnVvdXNseSBtb2RpZmllZCBpbiBvcmRl ciB0byAia2VlcCB1cCIKICAgd2l0aCBuZXcgZnVuY3Rpb25hbGl0eSBiZWluZyBpbnRyb2R1Y2Vk OiBsYWNrIG9mIGV4dGVuZGliaWxpdHkuCgogICBUaGUgU0YgYXZhaWxhYmlsaXR5IGNhbiBiZSBw ZXJmb3JtZWQgdXNpbmcgYSBnZW5lcmFsaXplZCBhcHByb2FjaAogICAoaS5lLiwgYW4gYWRlcXVh dGUgZ3JhbnVsYXJpdHkgdG8gcHJvdmlkZSBhIGJhc2ljIFNGIHNlcnZpY2UpLiAgTW9yZQogICBz cGVjaWZpY3Mgb24gdGhlIG1lY2hhbmlzbSB0byBjaGFyYWN0ZXJpemUgU0Ytc3BlY2lmaWMgT0FN IHRvCiAgIHZhbGlkYXRlIHRoZSBzZXJ2aWNlIG9mZmVyaW5nIGFyZSBvdXRzaWRlIHRoZSBzY29w ZSBvZiB0aGlzIGRvY3VtZW50LgogICBUaG9zZSBmaW5lLWdyYWluZWQgbWVjaGFuaXNtcyBhcmUg aW1wbGVtZW50YXRpb24tIGFuZCBkZXBsb3ltZW50LQogICBzcGVjaWZpYy4KCjMuMS4yLiAgU0Yg UGVyZm9ybWFuY2UgTWVhc3VyZW1lbnQKCiAgIFRoZSBzZWNvbmQgU0ZDIE9BTSByZXF1aXJlbWVu dCBmb3IgdGhlIFNGIGNvbXBvbmVudCBpcyB0byBhbGxvdyBhbgogICBTRkMtYXdhcmUgbmV0d29y ayBkZXZpY2UgdG8gY2hlY2sgdGhlIHBlcmZvcm1hbmNlIG1ldHJpY3Mgc3VjaCBhcwogICBsb3Nz IGFuZCBkZWxheSBpbmR1Y2VkIGJ5IGEgc3BlY2lmaWMgU0YgZm9yIHByb2Nlc3NpbmcgbGVnaXRp bWF0ZQogICB0cmFmZmljLiAgVGhlIHBlcmZvcm1hbmNlIGNhbiBiZSBhIHBhc3NpdmUgbWVhc3Vy ZW1lbnQgYnkgdXNpbmcgbGl2ZQogICB0cmFmZmljIG9yIGNhbiBiZSBhY3RpdmUgbWVhc3VyZW1l bnQgYnkgdXNpbmcgc3ludGhldGljIHByb2JlCiAgIHBhY2tldHMuCgogICBPbiB0aGUgb25lIGhh bmQsIHRoZSBwZXJmb3JtYW5jZSBvZiBhbnkgc3BlY2lmaWMgU0YgY2FuIGJlIHF1YW50aWZpZWQK ICAgYnkgbWVhc3VyaW5nIHRoZSBsb3NzIGFuZCBkZWxheSBtZXRyaWNzIG9mIHRoZSB0cmFmZmlj IGZyb20gU0ZGIHRvCiAgIHRoZSByZXNwZWN0aXZlIFNGLCB3aGlsZSBvbiB0aGUgb3RoZXIgaGFu ZCwgdGhlIHBlcmZvcm1hbmNlIGNhbiBiZQogICBtZWFzdXJlZCBieSBsZXZlcmFnaW5nIHRoZSBs b3NzIGFuZCBkZWxheSBtZXRyaWNzIGZyb20gdGhlIHJlc3BlY3RpdmUKICAgU0ZzLiAgVGhlIGxh dHRlciByZXF1aXJlcyBTRiBpbnZvbHZlbWVudCB0byBwZXJmb3JtIHRoZSBtZWFzdXJlbWVudAog ICB3aGlsZSB0aGUgZm9ybWVyIGRvZXMgbm90LgoKMy4yLiAgVGhlIFNGQyBDb21wb25lbnQKCgoK CgoKCgpBbGRyaW4sIGV0IGFsLiAgICAgICAgICBFeHBpcmVzIE9jdG9iZXIgMjksIDIwMjAgICAg ICAgICAgICAgICAgW1BhZ2UgOF0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgU0ZDIE9B TSBGcmFtZXdvcmsgICAgICAgICAgICAgICAgIEFwcmlsIDIwMjAKCgozLjIuMS4gIFNGQyBBdmFp bGFiaWxpdHkKCiAgIEFuIFNGQyBjb3VsZCBiZSBjb21wcmlzZWQgb2YgdmFyeWluZyBTRnMgYW5k IHNvIHRoZSBPQU0gbGF5ZXIgaXMKICAgcmVxdWlyZWQgdG8gcGVyZm9ybSB2YWxpZGF0aW9uIGFu ZCB2ZXJpZmljYXRpb24gb2YgU0ZzIHdpdGhpbiBhbiBTRlAsCiAgIGluIGFkZGl0aW9uIHRvIGNv bm5lY3Rpdml0eSB2ZXJpZmljYXRpb24gYW5kIGZhdWx0IGlzb2xhdGlvbi4KCiAgIEluIG9yZGVy IHRvIHBlcmZvcm0gc2VydmljZSBjb25uZWN0aXZpdHkgdmVyaWZpY2F0aW9uIG9mIGFuIFNGQy9T RlAsCiAgIHRoZSBPQU0gZnVuY3Rpb25zIGNvdWxkIGJlIGluaXRpYXRlZCBmcm9tIGFueSBTRkMt YXdhcmUgbmV0d29yawogICBkZXZpY2VzIG9mIGFuIFNGQy1lbmFibGVkIGRvbWFpbiBmb3IgZW5k LXRvLWVuZCBwYXRocywgb3IgcGFydGlhbAogICBwYXRocyB0ZXJtaW5hdGluZyBvbiBhIHNwZWNp ZmljIFNGLCB3aXRoaW4gdGhlIFNGQy9TRlAuICBUaGUgZ29hbCBvZgogICB0aGlzIE9BTSBmdW5j dGlvbiBpcyB0byBlbnN1cmUgdGhlIFNGcyBjaGFpbmVkIHRvZ2V0aGVyIGhhdmUKICAgY29ubmVj dGl2aXR5IGFzIHdhcyBpbnRlbmRlZCBhdCB0aGUgdGltZSB3aGVuIHRoZSBTRkMgd2FzCiAgIGVz dGFibGlzaGVkLiAgVGhlIG5lY2Vzc2FyeSByZXR1cm4gY29kZXMgc2hvdWxkIGJlIGRlZmluZWQg Zm9yCiAgIHNlbmRpbmcgYmFjayBpbiB0aGUgcmVzcG9uc2UgdG8gdGhlIE9BTSBwYWNrZXQsIGlu IG9yZGVyIHRvIGNvbXBsZXRlCiAgIHRoZSB2ZXJpZmljYXRpb24uCgogICBXaGVuIEVDTVAgaXMg aW4gdXNlIGF0IHRoZSBzZXJ2aWNlIGxheWVyIGZvciBhbnkgZ2l2ZW4gU0ZDLCB0aGVyZQogICBN VVNUIGJlIHRoZSBhYmlsaXR5IHRvIGRpc2NvdmVyIGFuZCB0cmF2ZXJzZSBhbGwgYXZhaWxhYmxl IHBhdGhzLgoKICAgQSBkZXRhaWxlZCBleHBsYW5hdGlvbiBvZiB0aGUgbWVjaGFuaXNtIGlzIG91 dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMKICAgZG9jdW1lbnQgYW5kIGlzIGV4cGVjdGVkIHRvIGJl IGluY2x1ZGVkIGluIHRoZSBhY3R1YWwgc29sdXRpb24KICAgZG9jdW1lbnQuCgozLjIuMi4gIFNG QyBQZXJmb3JtYW5jZSBNZWFzdXJlbWVudAoKICAgQW55IFNGQy1hd2FyZSBuZXR3b3JrIGRldmlj ZSBzaG91bGQgaGF2ZSB0aGUgYWJpbGl0eSB0byBtYWtlCiAgIHBlcmZvcm1hbmNlIG1lYXN1cmVt ZW50cyBvdmVyIHRoZSBlbnRpcmUgU0ZDIChpLmUuLCBlbmQtdG8tZW5kKSBvciB0bwogICBhIHNw ZWNpZmljIHNlZ21lbnQgb2YgU0ZzIHdpdGhpbiB0aGUgU0ZDLgoKMy4zLiAgVGhlIENsYXNzaWZp ZXIgQ29tcG9uZW50CgogICBBIGNsYXNzaWZpZXIgbWFpbnRhaW5zIHRoZSBjbGFzc2lmaWNhdGlv biBydWxlcyB0aGF0IG1hcCBhIGZsb3cgdG8gYQogICBzcGVjaWZpYyBTRkMuICBJdCBpcyB2aXRh bCB0aGF0IHRoZSBjbGFzc2lmaWVyIGlzIGNvcnJlY3RseQogICBjb25maWd1cmVkIHdpdGggdXBk YXRlZCBjbGFzc2lmaWNhdGlvbiBydWxlcyBhbmQgaXMgZnVuY3Rpb25pbmcgYXMKICAgZXhwZWN0 ZWQuICBUaGUgU0ZDIE9BTSBtdXN0IGJlIGFibGUgdG8gdmFsaWRhdGUgdGhlIGNsYXNzaWZpY2F0 aW9uCiAgIHJ1bGVzIGJ5IGFzc2Vzc2luZyB3aGV0aGVyIGEgZmxvdyBpcyBhcHByb3ByaWF0ZWx5 IG1hcHBlZCB0byB0aGUKICAgcmVsZXZhbnQgU0ZDLiAgU2FtcGxlIE9BTSBwYWNrZXRzIGNhbiBi ZSBwcmVzZW50ZWQgdG8gdGhlIGNsYXNzaWZpZXJzCiAgIHRvIGFzc2VzcyB0aGUgYmVoYXZpb3Ig d2l0aCByZWdhcmQgdG8gYSBnaXZlbiBjbGFzc2lmaWNhdGlvbiBlbnRyeS4KCiAgIFRoZSBDbGFz c2lmaWVyIGF2YWlsYWJpbGl0eSBjaGVjayBtYXkgYmUgcGVyZm9ybWVkIHRvIGNoZWNrIHRoZQog ICBhdmFpbGFiaWxpdHkgb2YgdGhlIGNsYXNzaWZpZXIgdG8gYXBwbHkgdGhlIHJ1bGVzIGFuZCBj bGFzc2lmeSB0aGUKICAgdHJhZmZpYyBmbG93cy4gIEFueSBTRkMtYXdhcmUgbmV0d29yayBkZXZp Y2Ugc2hvdWxkIGhhdmUgdGhlIGFiaWxpdHkKICAgdG8gcGVyZm9ybSBhdmFpbGFiaWxpdHkgY2hl Y2sgb2YgdGhlIGNsYXNzaWZpZXIgY29tcG9uZW50IGZvciBlYWNoCiAgIFNGQy4KCiAgIEFueSBT RkMtYXdhcmUgbmV0d29yayBkZXZpY2Ugc2hvdWxkIGhhdmUgdGhlIGFiaWxpdHkgdG8gcGVyZm9y bQogICBwZXJmb3JtYW5jZSBtZWFzdXJlbWVudCBvZiB0aGUgY2xhc3NpZmllciBjb21wb25lbnQg Zm9yIGVhY2ggU0ZDLgoKCgoKQWxkcmluLCBldCBhbC4gICAgICAgICAgRXhwaXJlcyBPY3RvYmVy IDI5LCAyMDIwICAgICAgICAgICAgICAgIFtQYWdlIDldCgwKSW50ZXJuZXQtRHJhZnQgICAgICAg ICAgICAgIFNGQyBPQU0gRnJhbWV3b3JrICAgICAgICAgICAgICAgICBBcHJpbCAyMDIwCgoKMy40 LiAgVW5kZXJsYXkgTmV0d29yawoKICAgVGhlIHVuZGVybGF5IG5ldHdvcmsgcHJvdmlkZXMgY29u bmVjdGl2aXR5IGJldHdlZW4gdGhlIFNGQyBjb21wb25lbnRzCiAgIGFuZCBzbyB0aGUgYXZhaWxh YmlsaXR5IG9yIHRoZSBwZXJmb3JtYW5jZSBvZiB0aGUgdW5kZXJsYXkgbmV0d29yawogICBkaXJl Y3RseSBpbXBhY3RzIHRoZSBTRkMgT0FNLgoKICAgQW55IFNGQy1hd2FyZSBuZXR3b3JrIGRldmlj ZSBtYXkgaGF2ZSB0aGUgYWJpbGl0eSB0byBwZXJmb3JtCiAgIGF2YWlsYWJpbGl0eSBjaGVjayBv ciBwZXJmb3JtYW5jZSBtZWFzdXJlbWVudCBvZiB0aGUgdW5kZXJsYXkKICAgbmV0d29yay4KCjMu NS4gIE92ZXJsYXkgTmV0d29yawoKICAgVGhlIG92ZXJsYXkgbmV0d29yayBlc3RhYmxpc2hlcyB0 aGUgc2VydmljZSBwbGFuZSBiZXR3ZWVuIHRoZSBTRkMKICAgY29tcG9uZW50cyBhbmQgYXJlIG1v c3RseSB0cmFuc3BhcmVudCB0byB0aGUgU0ZDIGRhdGEgcGxhbmUgZWxlbWVudHMuCgogICBBbnkg U0ZDLWF3YXJlIG5ldHdvcmsgZGV2aWNlIG1heSBoYXZlIHRoZSBhYmlsaXR5IHRvIHBlcmZvcm0K ICAgYXZhaWxhYmlsaXR5IGNoZWNrIG9yIHBlcmZvcm1hbmNlIG1lYXN1cmVtZW50IG9mIHRoZSBv dmVybGF5IG5ldHdvcmsuCgo0LiAgU0ZDIE9BTSBGdW5jdGlvbnMKCiAgIFNlY3Rpb24gMyBkZXNj cmliZWQgU0ZDIE9BTSBjb21wb25lbnRzIGFuZCB0aGUgYXNzb2NpYXRlZCBPQU0KICAgb3BlcmF0 aW9ucyBvbiBlYWNoIG9mIHRoZW0uICBUaGlzIHNlY3Rpb24gZXhwbG9yZXMgU0ZDIE9BTSBmdW5j dGlvbnMKICAgdGhhdCBhcmUgYXBwbGljYWJsZSBmb3IgbW9yZSB0aGFuIG9uZSBTRkMgY29tcG9u ZW50cy4KCiAgIFRoZSB2YXJpb3VzIFNGQyBPQU0gcmVxdWlyZW1lbnRzIGxpc3RlZCBpbiBTZWN0 aW9uIDMgaGlnaGxpZ2h0ZWQgdGhlCiAgIG5lZWQgZm9yIHZhcmlvdXMgT0FNIGZ1bmN0aW9ucyBh dCB0aGUgc2VydmljZSBsYXllci4gIEFzIGxpc3RlZCBpbgogICBTZWN0aW9uIDUuMSwgdmFyaW91 cyBPQU0gZnVuY3Rpb25zIGFyZSBpbiBleGlzdGVuY2UgdGhhdCBhcmUgZGVmaW5lZAogICB0byBw ZXJmb3JtIE9BTSBmdW5jdGlvbmFsaXR5IGF0IGRpZmZlcmVudCBsYXllcnMuICBJbiBvcmRlciB0 byBhcHBseQogICBzdWNoIE9BTSBmdW5jdGlvbnMgYXQgdGhlIHNlcnZpY2UgbGF5ZXIsIHRoZXkg bmVlZCB0byBiZSBlbmhhbmNlZCB0bwogICBvcGVyYXRlIGEgc2luZ2xlIFNGL1NGRiB0byBtdWx0 aXBsZSBTRnMvU0ZGcyBpbiBhbiBTRkMgYW5kIGFsc28gaW4KICAgbXVsdGlwbGUgU0ZDcy4KCjQu MS4gIENvbm5lY3Rpdml0eSBGdW5jdGlvbnMKCiAgIENvbm5lY3Rpdml0eSBpcyBtYWlubHkgYW4g b24tZGVtYW5kIGZ1bmN0aW9uIHRvIHZlcmlmeSB0aGF0IHRoZQogICBjb25uZWN0aXZpdHkgZXhp c3RzIGJldHdlZW4gY2VydGFpbiBuZXR3b3JrIGVsZW1lbnRzIGFuZCB0aGF0IHRoZSBTRnMKICAg YXJlIGF2YWlsYWJsZS4gIEZvciBleGFtcGxlLCBMU1AgUGluZyBbUkZDODAyOV0gaXMgYSBjb21t b24gdG9vbCB1c2VkCiAgIHRvIHBlcmZvcm0gdGhpcyBmdW5jdGlvbiBmb3IgYW4gTVBMUyB1bmRl cmxheSBuZXR3b3JrLiAgU29tZSBvZiB0aGUKICAgT0FNIGZ1bmN0aW9ucyBwZXJmb3JtZWQgYnkg Y29ubmVjdGl2aXR5IGZ1bmN0aW9ucyBhcmUgYXMgZm9sbG93czoKCiAgIG8gIFZlcmlmeSB0aGUg UGF0aCBNVFUgZnJvbSBhIHNvdXJjZSB0byB0aGUgZGVzdGluYXRpb24gU0Ygb3IgdGhyb3VnaAog ICAgICB0aGUgU0ZDLiAgVGhpcyByZXF1aXJlcyB0aGUgYWJpbGl0eSBmb3IgdGhlIE9BTSBwYWNr ZXQgdG8gYmUgb2YKICAgICAgdmFyaWFibGUgbGVuZ3RoIHBhY2tldCBzaXplLgoKICAgbyAgVmVy aWZ5IGFueSBwYWNrZXQgcmUtb3JkZXJpbmcgYW5kIGNvcnJ1cHRpb24uCgogICBvICBWZXJpZnkg dGhlIHBvbGljeSBvZiBhbiBTRkMgb3IgU0YuCgoKCgpBbGRyaW4sIGV0IGFsLiAgICAgICAgICBF eHBpcmVzIE9jdG9iZXIgMjksIDIwMjAgICAgICAgICAgICAgICBbUGFnZSAxMF0KDApJbnRlcm5l dC1EcmFmdCAgICAgICAgICAgICAgU0ZDIE9BTSBGcmFtZXdvcmsgICAgICAgICAgICAgICAgIEFw cmlsIDIwMjAKCgogICBvICBWZXJpZmljYXRpb24gYW5kIHZhbGlkYXRpb24gb2YgZm9yd2FyZGlu ZyBwYXRocy4KCiAgIG8gIFByb2FjdGl2ZWx5IHRlc3QgYWx0ZXJuYXRlIG9yIHByb3RlY3RlZCBw YXRocyB0byBlbnN1cmUKICAgICAgcmVsaWFiaWxpdHkgb2YgbmV0d29yayBjb25maWd1cmF0aW9u cy4KCjQuMi4gIENvbnRpbnVpdHkgRnVuY3Rpb25zCgogICBDb250aW51aXR5IGlzIGEgbW9kZWwg d2hlcmUgT0FNIG1lc3NhZ2VzIGFyZSBzZW50IHBlcmlvZGljYWxseSB0bwogICB2YWxpZGF0ZSBv ciB2ZXJpZnkgdGhlIHJlYWNoYWJpbGl0eSB0byBhIGdpdmVuIFNGIHdpdGhpbiBhbiBTRkMgb3IK ICAgZm9yIHRoZSBlbnRpcmUgU0ZDLiAgVGhpcyBhbGxvd3MgYSBtb25pdG9yaW5nIG5ldHdvcmsg ZGV2aWNlIChzdWNoIGFzCiAgIHRoZSBjbGFzc2lmaWVyIG9yIGNvbnRyb2xsZXIpIHRvIHF1aWNr bHkgZGV0ZWN0IGZhaWx1cmVzIHN1Y2ggYXMgbGluawogICBmYWlsdXJlcywgbmV0d29yayBlbGVt ZW50IGZhaWx1cmVzLCBTRiBvdXRhZ2VzLCBvciBTRkMgb3V0YWdlcy4gIEJGRAogICBbUkZDNTg4 MF0gaXMgb25lIHN1Y2ggZnVuY3Rpb24gd2hpY2ggaGVscHMgaW4gZGV0ZWN0aW5nIGZhaWx1cmVz CiAgIHF1aWNrbHkuICBPQU0gZnVuY3Rpb25zIHN1cHBvcnRlZCBieSBjb250aW51aXR5IGZ1bmN0 aW9uIGFyZSBhcwogICBmb2xsb3dzOgoKICAgbyAgQWJpbGl0eSB0byBwcm92aXNpb24gY29udGlu dWl0eSBjaGVjayB0byBhIGdpdmVuIFNGIHdpdGhpbiBhbiBTRkMKICAgICAgb3IgZm9yIHRoZSBl bnRpcmUgU0ZDLgoKICAgbyAgUHJvYWN0aXZlbHkgdGVzdCBhbHRlcm5hdGUgb3IgcHJvdGVjdGVk IHBhdGhzIHRvIGVuc3VyZQogICAgICByZWxpYWJpbGl0eSBvZiBuZXR3b3JrIGNvbmZpZ3VyYXRp b25zLgoKICAgbyAgTm90aWZ5aW5nIHRoZSBkZXRlY3RlZCBmYWlsdXJlcyB0byBvdGhlciBPQU0g ZnVuY3Rpb25zIG9yCiAgICAgIGFwcGxpY2F0aW9ucyB0byB0YWtlIGFwcHJvcHJpYXRlIGFjdGlv bi4KCjQuMy4gIFRyYWNlIEZ1bmN0aW9ucwoKICAgVHJhY2luZyBpcyBhbiBPQU0gZnVuY3Rpb24g dGhhdCBhbGxvd3MgdGhlIG9wZXJhdGlvbiB0byB0cmlnZ2VyIGFuCiAgIGFjdGlvbiAoZS5nLiBy ZXNwb25zZSBnZW5lcmF0aW9uKSBmcm9tIGV2ZXJ5IHRyYW5zaXQgZGV2aWNlIChlLmcuCiAgIFNG RiwgU0YsIFNGQyBQcm94eSkgb24gdGhlIHRlc3RlZCBsYXllci4gIFRoaXMgZnVuY3Rpb24gaXMg dHlwaWNhbGx5CiAgIHVzZWZ1bCBmb3IgZ2F0aGVyaW5nIGluZm9ybWF0aW9uIGZyb20gZXZlcnkg dHJhbnNpdCBkZXZpY2VzIG9yIGZvcgogICBpc29sYXRpbmcgdGhlIGZhaWx1cmUgcG9pbnQgdG8g YSBzcGVjaWZpYyBTRiB3aXRoaW4gYW4gU0ZDIG9yIGZvciBhbgogICBlbnRpcmUgU0ZDLiAgU29t ZSBvZiB0aGUgT0FNIGZ1bmN0aW9ucyBzdXBwb3J0ZWQgYnkgdHJhY2UgZnVuY3Rpb25zCiAgIGFy ZToKCiAgIG8gIEFiaWxpdHkgdG8gdHJpZ2dlciBhY3Rpb24gZnJvbSBldmVyeSB0cmFuc2l0IGRl dmljZSBhdCB0aGUgU0ZDCiAgICAgIGxheWVyLCB1c2luZyBUVEwgb3Igb3RoZXIgbWVhbnMuCgog ICBvICBBYmlsaXR5IHRvIHRyaWdnZXIgZXZlcnkgdHJhbnNpdCBkZXZpY2UgYXQgdGhlIFNGQyBs YXllciB0bwogICAgICBnZW5lcmF0ZSBhIHJlc3BvbnNlIHdpdGggT0FNIGNvZGUocyksIHVzaW5n IFRUTCBvciBvdGhlciBtZWFucy4KCiAgIG8gIEFiaWxpdHkgdG8gZGlzY292ZXIgYW5kIHRyYXZl cnNlIEVDTVAgcGF0aHMgd2l0aGluIGFuIFNGQy4KCiAgIG8gIEFiaWxpdHkgdG8gc2tpcCBTRnMg dGhhdCBkbyBub3Qgc3VwcG9ydCBPQU0gd2hpbGUgdHJhY2luZyBTRnMgaW4KICAgICAgYW4gU0ZD LgoKCgoKCgpBbGRyaW4sIGV0IGFsLiAgICAgICAgICBFeHBpcmVzIE9jdG9iZXIgMjksIDIwMjAg ICAgICAgICAgICAgICBbUGFnZSAxMV0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgU0ZD IE9BTSBGcmFtZXdvcmsgICAgICAgICAgICAgICAgIEFwcmlsIDIwMjAKCgo0LjQuICBQZXJmb3Jt YW5jZSBNZWFzdXJlbWVudCBGdW5jdGlvbnMKCiAgIFBlcmZvcm1hbmNlIG1lYXN1cmVtZW50IGZ1 bmN0aW9ucyBpbnZvbHZlIG1lYXN1cmluZyBvZiBwYWNrZXQgbG9zcywKICAgZGVsYXksIGRlbGF5 IHZhcmlhbmNlLCBldGMuICBUaGVzZSBwZXJmb3JtYW5jZSBtZXRyaWNzIG1heSBiZQogICBtZWFz dXJlZCBwcm8tYWN0aXZlbHkgb3Igb24tZGVtYW5kLgoKICAgU0ZDIE9BTSBzaG91bGQgcHJvdmlk ZSB0aGUgYWJpbGl0eSB0byBtZWFzdXJlIHBhY2tldCBsb3NzIGZvciBhbiBTRkMuCiAgIE9uLWRl bWFuZCBtZWFzdXJlbWVudCBjYW4gYmUgdXNlZCB0byBlc3RpbWF0ZSBwYWNrZXQgbG9zcyB1c2lu ZwogICBzdGF0aXN0aWNhbCBtZXRob2RzLiAgTWVhc3VyaW5nIHRoZSBsb3NzIG9mIE9BTSBwYWNr ZXRzLCBhbgogICBhcHByb3hpbWF0aW9uIG9mIHBhY2tldCBsb3NzIGZvciBhIGdpdmVuIFNGQyBj YW4gYmUgZGVyaXZlZC4KCiAgIERlbGF5IHdpdGhpbiBhbiBTRkMgY291bGQgYmUgbWVhc3VyZWQg YmFzZWQgb24gdGhlIHRpbWUgaXQgdGFrZXMgZm9yCiAgIGEgcGFja2V0IHRvIHRyYXZlcnNlIHRo ZSBTRkMgZnJvbSB0aGUgaW5ncmVzcyBTRkMgbm9kZSB0byB0aGUgZWdyZXNzCiAgIFNGRi4gIEFz IFNGQ3MgYXJlIHVuaWRpcmVjdGlvbmFsIGluIG5hdHVyZSwgbWVhc3VyZW1lbnQgb2Ygb25lLXdh eQogICBkZWxheSBbUkZDNzY3OV0gaXMgaW1wb3J0YW50LiAgSW4gb3JkZXIgdG8gbWVhc3VyZSBv bmUtd2F5IGRlbGF5LAogICB0aW1lIHN5bmNocm9uaXphdGlvbiBNVVNUIGJlIHN1cHBvcnRlZCBi eSBtZWFucyBzdWNoIGFzIE5UUCwgUFRQLAogICBHUFMsIGV0Yy4KCiAgIE9uZS13YXkgZGVsYXkg dmFyaWF0aW9uIFtSRkMzMzkzXSBjb3VsZCBhbHNvIGJlIGNhbGN1bGF0ZWQgYnkgc2VuZGluZwog ICBPQU0gcGFja2V0cyBhbmQgbWVhc3VyaW5nIHRoZSBqaXR0ZXIgYmV0d2VlbiB0aGUgcGFja2V0 cyBwYXNzaW5nCiAgIHRocm91Z2ggYW4gU0ZDLgoKICAgU29tZSBvZiB0aGUgT0FNIGZ1bmN0aW9u cyBzdXBwb3J0ZWQgYnkgdGhlIHBlcmZvcm1hbmNlIG1lYXN1cmVtZW50CiAgIGZ1bmN0aW9ucyBh cmU6CgogICBvICBBYmlsaXR5IHRvIG1lYXN1cmUgdGhlIHBhY2tldCBwcm9jZXNzaW5nIGRlbGF5 IGluZHVjZWQgYnkgYSBzaW5nbGUKICAgICAgU0Ygb3IgdGhlIG9uZS13YXkgZGVsYXkgdG8gdHJh dmVyc2UgYW4gU0ZQIGJvdW5kIHRvIGEgZ2l2ZW4gU0ZDLgoKICAgbyAgQWJpbGl0eSB0byBtZWFz dXJlIHRoZSBwYWNrZXQgbG9zcyBbUkZDNzY4MF0gd2l0aGluIGFuIFNGIG9yIGFuCiAgICAgIFNG UCBib3VuZCB0byBhIGdpdmVuIFNGQy4KCjUuICBHYXAgQW5hbHlzaXMKCiAgIFRoaXMgc2VjdGlv biBpZGVudGlmaWVzIHZhcmlvdXMgT0FNIGZ1bmN0aW9ucyBhdmFpbGFibGUgYXQgZGlmZmVyZW50 CiAgIGxheWVycyBpbnRyb2R1Y2VkIGluIFNlY3Rpb24gMi4gIEl0IGFsc28gaWRlbnRpZmllcyB2 YXJpb3VzIGdhcHMgdGhhdAogICBleGlzdCB3aXRoaW4gdGhlIGN1cnJlbnQgdG9vbHNldCBmb3Ig cGVyZm9ybWluZyBPQU0gZnVuY3Rpb25zCiAgIHJlcXVpcmVkIGZvciBTRkMuCgo1LjEuICBFeGlz dGluZyBPQU0gRnVuY3Rpb25zCgogICBUaGVyZSBhcmUgdmFyaW91cyBPQU0gdG9vbCBzZXRzIGF2 YWlsYWJsZSB0byBwZXJmb3JtIE9BTSBmdW5jdGlvbnMKICAgd2l0aGluIHZhcmlvdXMgbGF5ZXJz LiAgVGhlc2UgT0FNIGZ1bmN0aW9ucyBtYXkgYmUgdXNlZCB0byB2YWxpZGF0ZQogICBzb21lIG9m IHRoZSB1bmRlcmxheSBhbmQgb3ZlcmxheSBuZXR3b3Jrcy4gIFRvb2xzIGxpa2UgcGluZyBhbmQg dHJhY2UKICAgYXJlIGluIGV4aXN0ZW5jZSB0byBwZXJmb3JtIGNvbm5lY3Rpdml0eSBjaGVjayBh bmQgdHJhY2luZyBvZgogICBpbnRlcm1lZGlhdGUgaG9wcyBpbiBhIG5ldHdvcmsuICBUaGVzZSB0 b29scyBzdXBwb3J0IGRpZmZlcmVudAogICBuZXR3b3JrIHR5cGVzIGxpa2UgSVAsIE1QTFMsIFRS SUxMLCBldGMuICBUaGVyZSBpcyBhbHNvIGFuIGVmZm9ydCB0bwogICBleHRlbmQgdGhlIHRvb2wg c2V0IHRvIHByb3ZpZGUgY29ubmVjdGl2aXR5IGFuZCBjb250aW51aXR5IGNoZWNrcwoKCgoKQWxk cmluLCBldCBhbC4gICAgICAgICAgRXhwaXJlcyBPY3RvYmVyIDI5LCAyMDIwICAgICAgICAgICAg ICAgW1BhZ2UgMTJdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIFNGQyBPQU0gRnJhbWV3 b3JrICAgICAgICAgICAgICAgICBBcHJpbCAyMDIwCgoKICAgd2l0aGluIG92ZXJsYXkgbmV0d29y a3MuICBCRkQgaXMgYW5vdGhlciB0b29sIHdoaWNoIGhlbHBzIGluCiAgIGRldGVjdGluZyBkYXRh IGZvcndhcmRpbmcgZmFpbHVyZXMuICBUYWJsZSAzIGJlbG93IGlzIG5vdCBleGhhdXN0aXZlCgog ICAgICAgICAgICAgICAgICAgIFRhYmxlIDM6IE9BTSBUb29sIEdBUCBBbmFseXNpcwogICArLS0t LS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tKy0tLS0tLS0tKy0tLS0t LS0tLS0tLSsKICAgfCBMYXllciAgICAgICAgICB8IENvbm5lY3Rpdml0eSB8ICBDb250aW51aXR5 IHwgIFRyYWNlIHwgUGVyZm9ybWFuY2V8CiAgICstLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0t LS0tKy0tLS0tLS0tLS0tLS0rLS0tLS0tLS0rLS0tLS0tLS0tLS0tKwogICB8IFVuZGVybGF5IE4v dyAgIHwgUGluZyAgICAgICAgIHxFLU9BTSwgQkZEICAgfCAgVHJhY2UgfCAgSVBQTSwgICAgIHwK ICAgfCAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICB8ICAgICAgICAgICAgIHwgICAgICAg IHwgIE1QTFNfUE0gICB8CiAgICstLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tKy0tLS0t LS0tLS0tLS0rLS0tLS0tLS0rLS0tLS0tLS0tLS0tKwogICB8IE92ZXJsYXkgTi93ICAgIHwgUGlu ZyAgICAgICAgIHxCRkQsIE5WbzMgT0FNfCBUcmFjZSAgfCAgSVBQTSAgICAgIHwKICAgKy0tLS0t LS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLSstLS0tLS0tLSstLS0tLS0t LS0tLS0rCiAgIHwgIENsYXNzaWZpZXIgICAgfCBQaW5nICAgICAgICAgfEJGRCAgICAgICAgICB8 IFRyYWNlICB8ICBOb25lICAgICAgfAogICArLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0t LSstLS0tLS0tLS0tLS0tKy0tLS0tLS0tKy0tLS0tLS0tLS0tLSsKICAgfCBTRiAgICAgICAgICAg ICB8IE5vbmUgICAgICAgICB8IE5vbmUgICAgICAgIHwgTm9uZSAgIHwgTm9uZSAgICAgICB8CiAg ICstLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0rLS0tLS0tLS0r LS0tLS0tLS0tLS0tKwogICB8IFNGQyAgICAgICAgICAgIHwgTm9uZSAgICAgICAgIHwgTm9uZSAg ICAgICAgfCBOb25lICAgfCBOb25lICAgICAgIHwKICAgKy0tLS0tLS0tLS0tLS0tLS0rLS0tLS0t LS0tLS0tLS0rLS0tLS0tLS0tLS0tLSstLS0tLS0tLSstLS0tLS0tLS0tLS0rCgoKCjUuMi4gIE1p c3NpbmcgT0FNIEZ1bmN0aW9ucwoKICAgQXMgc2hvd24gaW4gVGFibGUgMywgdGhlcmUgYXJlIG5v IHN0YW5kYXJkcy1iYXNlZCB0b29scyBhdmFpbGFibGUgZm9yCiAgIHRoZSB2ZXJpZmljYXRpb24g b2YgU0ZzIGFuZCBTRkNzLgoKNS4zLiAgUmVxdWlyZWQgT0FNIEZ1bmN0aW9ucwoKICAgUHJpbWFy eSBPQU0gZnVuY3Rpb25zIGV4aXN0IGZvciB1bmRlcmx5aW5nIGxheWVycy4gIFRvb2xzIGxpa2Ug cGluZywKICAgdHJhY2UsIEJGRCwgZXRjLiBleGlzdCBpbiBvcmRlciB0byBwZXJmb3JtIHRoZXNl IE9BTSBmdW5jdGlvbnMuCgogICBBcyBkZXBpY3RlZCBpbiBUYWJsZSAzLCB0b29sc2V0cyBhbmQg c29sdXRpb25zIGFyZSByZXF1aXJlZCB0bwogICBwZXJmb3JtIHRoZSBPQU0gZnVuY3Rpb25zIGF0 IHRoZSBzZXJ2aWNlIGxheWVyLgoKNi4gIENhbmRpZGF0ZSBTRkMgT0FNIFRvb2xzCgogICBUaGlz IHNlY3Rpb24gZGVzY3JpYmVzIHRoZSBvcGVyYXRpb25hbCBhc3BlY3RzIG9mIFNGQyBPQU0gYXQg dGhlCiAgIHNlcnZpY2UgbGF5ZXIgdG8gcGVyZm9ybSB0aGUgU0ZDIE9BTSBmdW5jdGlvbiBkZWZp bmVkIGluIFNlY3Rpb24gNAogICBhbmQgYW5hbHl6ZXMgdGhlIGFwcGxpY2FiaWxpdHkgb2YgdmFy aW91cyBleGlzdGluZyBPQU0gdG9vbHNldHMgaW4KICAgdGhlIHNlcnZpY2UgbGF5ZXIuCgo2LjEu ICBTRkMgT0FNIFBhY2tldCBNYXJrZXIKCiAgIFNGQyBPQU0gbWVzc2FnZXMgU0hPVUxEIGJlIGVu Y2Fwc3VsYXRlZCB3aXRoIG5lY2Vzc2FyeSBTRkMgaGVhZGVyIGFuZAogICB3aXRoIE9BTSBtYXJr aW5ncyB3aGVuIHRlc3RpbmcgdGhlIFNGQyBjb21wb25lbnQuICBTRkMgT0FNIG1lc3NhZ2VzCiAg IE1BWSBiZSBlbmNhcHN1bGF0ZWQgd2l0aCB0aGUgbmVjZXNzYXJ5IFNGQyBoZWFkZXIgYW5kIHdp dGggT0FNCiAgIG1hcmtpbmdzIHdoZW4gdGVzdGluZyB0aGUgU0YgY29tcG9uZW50LgoKCgoKQWxk cmluLCBldCBhbC4gICAgICAgICAgRXhwaXJlcyBPY3RvYmVyIDI5LCAyMDIwICAgICAgICAgICAg ICAgW1BhZ2UgMTNdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIFNGQyBPQU0gRnJhbWV3 b3JrICAgICAgICAgICAgICAgICBBcHJpbCAyMDIwCgoKICAgVGhlIFNGQyBPQU0gZnVuY3Rpb24g ZGVzY3JpYmVkIGluIFNlY3Rpb24gNCBwZXJmb3JtZWQgYXQgdGhlIHNlcnZpY2UKICAgbGF5ZXIg b3Igb3ZlcmxheSBuZXR3b3JrIGxheWVyIG11c3QgbWFyayB0aGUgcGFja2V0IGFzIGFuIE9BTSBw YWNrZXQKICAgc28gdGhhdCByZWxldmFudCBub2RlcyBjYW4gZGlmZmVyZW50aWF0ZSBhbiBPQU0g cGFja2V0IGZyb20gZGF0YQogICBwYWNrZXRzLiAgVGhlIGJhc2UgaGVhZGVyIGRlZmluZWQgaW4g U2VjdGlvbiAyLjIgb2YgW1JGQzgzMDBdIGFzc2lnbnMKICAgYSBiaXQgdG8gaW5kaWNhdGUgT0FN IHBhY2tldHMuICBXaGVuIE5TSCBlbmNhcHN1bGF0aW9uIGlzIHVzZWQgYXQgdGhlCiAgIHNlcnZp Y2UgbGF5ZXIsIHRoZSBPIGJpdCBtdXN0IGJlIHNldCB0byBkaWZmZXJlbnRpYXRlIHRoZSBPQU0g cGFja2V0LgogICBBbnkgb3RoZXIgb3ZlcmxheSBlbmNhcHN1bGF0aW9ucyB1c2VkIGF0IHRoZSBz ZXJ2aWNlIGxheWVyIG11c3QgaGF2ZQogICBhIHdheSB0byBtYXJrIHRoZSBwYWNrZXQgYXMgT0FN IHBhY2tldC4KCjYuMi4gIE9BTSBQYWNrZXQgUHJvY2Vzc2luZyBhbmQgRm9yd2FyZGluZyBTZW1h bnRpYwoKICAgVXBvbiByZWNlaXZpbmcgYW4gT0FNIHBhY2tldCwgU0ZDLWF3YXJlIFNGcyBtYXkg Y2hvb3NlIHRvIGRpc2NhcmQgdGhlCiAgIHBhY2tldCBpZiBpdCBkb2VzIG5vdCBzdXBwb3J0IE9B TSBmdW5jdGlvbmFsaXR5IG9yIGlmIHRoZSBsb2NhbAogICBwb2xpY3kgcHJldmVudHMgdGhlbSBm cm9tIHByb2Nlc3NpbmcgdGhlIE9BTSBwYWNrZXQuICBXaGVuIGFuIFNGCiAgIHN1cHBvcnRzIE9B TSBmdW5jdGlvbmFsaXR5LCBpdCBpcyBkZXNpcmFibGUgdG8gcHJvY2VzcyB0aGUgcGFja2V0IGFu ZAogICBwcm92aWRlIGFuIGFwcHJvcHJpYXRlIHJlc3BvbnNlIHRvIGFsbG93IGVuZC10by1lbmQg dmVyaWZpY2F0aW9uLiAgVG8KICAgbGltaXQgcGVyZm9ybWFuY2UgaW1wYWN0IGR1ZSB0byBPQU0s IFNGQy1hd2FyZSBTRnMgc2hvdWxkIHJhdGUgbGltaXQKICAgdGhlIG51bWJlciBvZiBPQU0gcGFj a2V0cyBwcm9jZXNzZWQuCgogICBBbiBTRkYgbWF5IGNob29zZSBub3QgdG8gZm9yd2FyZCB0aGUg T0FNIHBhY2tldCB0byBhbiBTRiBpZiB0aGUgU0YKICAgZG9lcyBub3Qgc3VwcG9ydCBPQU0gb3Ig aWYgdGhlIHBvbGljeSBkb2VzIG5vdCBhbGxvdyB0byBmb3J3YXJkIE9BTQogICBwYWNrZXQgdG8g YW4gU0YuICBUaGUgU0ZGIG1heSBjaG9vc2UgdG8gc2tpcCB0aGUgU0YsIG1vZGlmeSB0aGUKICAg aGVhZGVyIGFuZCBmb3J3YXJkIHRvIG5leHQgU0ZDIG5vZGUgaW4gdGhlIGNoYWluLiAgSXQgc2hv dWxkIGJlIG5vdGVkCiAgIHRoYXQgc2tpcHBpbmcgYW4gU0YgbWlnaHQgaGF2ZSBpbXBsaWNhdGlv biBvbiBzb21lIE9BTSBmdW5jdGlvbnMKICAgKGUuZy4gdGhlIGRlbGF5IG1lYXN1cmVtZW50IG1h eSBub3QgYmUgYWNjdXJhdGUpLiAgVGhlIG1ldGhvZCBieQogICB3aGljaCBhbiBTRkYgZGV0ZWN0 cyBpZiB0aGUgY29ubmVjdGVkIFNGIHN1cHBvcnRzIG9yIGlzIGFsbG93ZWQgdG8KICAgcHJvY2Vz cyBPQU0gcGFja2V0cyBpcyBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGlzIGRvY3VtZW50LiAgSXQg Y291bGQKICAgYmUgYSBjb25maWd1cmF0aW9uIHBhcmFtZXRlciBpbnN0cnVjdGVkIGJ5IHRoZSBj b250cm9sbGVyIG9yIGl0IGNhbgogICBiZSBkb25lIGJ5IGR5bmFtaWMgbmVnb3RpYXRpb24gYmV0 d2VlbiB0aGUgU0YgYW5kIFNGRi4KCiAgIElmIHRoZSBTRkYgcmVjZWl2aW5nIHRoZSBPQU0gcGFj a2V0IGJvdW5kIHRvIGEgZ2l2ZW4gU0ZDIGlzIHRoZSBsYXN0CiAgIFNGRiBpbiB0aGUgY2hhaW4s IGl0IG11c3Qgc2VuZCBhIHJlbGV2YW50IHJlc3BvbnNlIHRvIHRoZSBpbml0aWF0b3IKICAgb2Yg dGhlIE9BTSBwYWNrZXQuICBEZXBlbmRpbmcgb24gdGhlIHR5cGUgb2YgT0FNIHNvbHV0aW9uIGFu ZCB0b29sCiAgIHNldCB1c2VkLCB0aGUgcmVzcG9uc2UgY291bGQgYmUgYSBzaW1wbGUgcmVzcG9u c2UgKHN1Y2ggYXMgSUNNUAogICByZXBseSkgb3IgY291bGQgaW5jbHVkZSBhZGRpdGlvbmFsIGRh dGEgZnJvbSB0aGUgcmVjZWl2ZWQgT0FNIHBhY2tldAogICAobGlrZSBzdGF0aXN0aWNhbCBkYXRh IGNvbnNvbGlkYXRlZCBhbG9uZyB0aGUgcGF0aCkuICBUaGUgZGV0YWlscyBhcmUKICAgZXhwZWN0 ZWQgdG8gYmUgY292ZXJlZCBpbiB0aGUgc29sdXRpb24gZG9jdW1lbnRzLgoKICAgQW55IFNGQy1h d2FyZSBub2RlIHRoYXQgaW5pdGlhdGVzIGFuIE9BTSBwYWNrZXQgbXVzdCBzZXQgdGhlIE9BTQog ICBtYXJrZXIgaW4gdGhlIG92ZXJsYXkgZW5jYXBzdWxhdGlvbi4KCjYuMy4gIE9BTSBGdW5jdGlv biBUeXBlcwoKICAgQXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gNCwgdGhlcmUgYXJlIGRpZmZlcmVu dCBPQU0gZnVuY3Rpb25zIHRoYXQgbWF5CiAgIHJlcXVpcmUgZGlmZmVyZW50IE9BTSBzb2x1dGlv bnMuICBXaGlsZSB0aGUgcHJlc2VuY2Ugb2YgdGhlIE9BTQogICBtYXJrZXIgaW4gdGhlIG92ZXJs YXkgaGVhZGVyIChlLmcuLCBPIGJpdCBpbiB0aGUgTlNIIGhlYWRlcikKICAgaW5kaWNhdGVzIGl0 IGFzIE9BTSBwYWNrZXQsIGl0IGlzIG5vdCBzdWZmaWNpZW50IHRvIGluZGljYXRlIHdoYXQgT0FN CiAgIGZ1bmN0aW9uIHRoZSBwYWNrZXQgaXMgaW50ZW5kZWQgZm9yLiAgVGhlIE5leHQgUHJvdG9j b2wgZmllbGQgaW4gTlNICgoKCkFsZHJpbiwgZXQgYWwuICAgICAgICAgIEV4cGlyZXMgT2N0b2Jl ciAyOSwgMjAyMCAgICAgICAgICAgICAgIFtQYWdlIDE0XQoMCkludGVybmV0LURyYWZ0ICAgICAg ICAgICAgICBTRkMgT0FNIEZyYW1ld29yayAgICAgICAgICAgICAgICAgQXByaWwgMjAyMAoKCiAg IGhlYWRlciBtYXkgYmUgdXNlZCB0byBpbmRpY2F0ZSB3aGF0IE9BTSBmdW5jdGlvbiBpcyBpbnRl bmRlZCB0byBvcgogICB3aGF0IHRvb2xzZXQgaXMgdXNlZC4KCjYuNC4gIE9BTSBUb29sc2V0IEFw cGxpY2FiaWxpdHkKCiAgIEFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDUuMSwgdGhlcmUgYXJlIGRp ZmZlcmVudCB0b29sIHNldHMgYXZhaWxhYmxlCiAgIHRvIHBlcmZvcm0gT0FNIGZ1bmN0aW9ucyBh dCBkaWZmZXJlbnQgbGF5ZXJzLiAgVGhpcyBzZWN0aW9uIGRlc2NyaWJlcwogICB0aGUgYXBwbGlj YWJpbGl0eSBvZiBzb21lIG9mIHRoZSBhdmFpbGFibGUgdG9vbHNldHMgaW4gdGhlIHNlcnZpY2UK ICAgbGF5ZXIuCgo2LjQuMS4gIElDTVAKCiAgIFtSRkMwNzkyXSBhbmQgW1JGQzQ0NDNdIGRlc2Ny aWJlcyB0aGUgdXNlIG9mIElDTVAgaW4gSVB2NCBhbmQgSVB2NgogICBuZXR3b3JrcyByZXNwZWN0 aXZlbHkuICBJdCBleHBsYWlucyBob3cgSUNNUCBtZXNzYWdlcyBjYW4gYmUgdXNlZCB0bwogICB0 ZXN0IHRoZSBuZXR3b3JrIHJlYWNoYWJpbGl0eSBiZXR3ZWVuIGRpZmZlcmVudCBlbmQgcG9pbnRz IGFuZAogICBwZXJmb3JtIGJhc2ljIG5ldHdvcmsgZGlhZ25vc3RpY3MuCgogICBJQ01QIGNvdWxk IGJlIGxldmVyYWdlZCBmb3IgY29ubmVjdGl2aXR5IGZ1bmN0aW9uIChkZWZpbmVkIGluCiAgIFNl Y3Rpb24gNC4xKSB0byB2ZXJpZnkgdGhlIGF2YWlsYWJpbGl0eSBvZiBTRiBvciBTRkMuICBUaGUg SW5pdGlhdG9yCiAgIGNhbiBnZW5lcmF0ZSBhbiBJQ01QIGVjaG8gcmVxdWVzdCBtZXNzYWdlIGFu ZCBjb250cm9sIHRoZSBzZXJ2aWNlCiAgIGxheWVyIGVuY2Fwc3VsYXRpb24gaGVhZGVyIHRvIGdl dCB0aGUgcmVzcG9uc2UgZnJvbSByZWxldmFudCBub2RlLgogICBGb3IgZXhhbXBsZSwgYSBjbGFz c2lmaWVyIGluaXRpYXRpbmcgT0FNIGNhbiBnZW5lcmF0ZSBJQ01QIGVjaG8KICAgcmVxdWVzdCBt ZXNzYWdlLCBjYW4gc2V0IHRoZSBUVEwgZmllbGQgaW4gTlNIIGhlYWRlciB0byA2MyB0byBnZXQg dGhlCiAgIHJlc3BvbnNlIGZyb20gbGFzdCBTRkYgYW5kIHRoZXJlYnkgdGVzdCB0aGUgU0ZDIGF2 YWlsYWJpbGl0eS4KICAgQWx0ZXJuYXRlbHksIHRoZSBpbml0aWF0b3IgY2FuIHNldCB0aGUgVFRM IHRvIHNvbWUgb3RoZXIgdmFsdWUgdG8gZ2V0CiAgIHRoZSByZXNwb25zZSBmcm9tIGEgc3BlY2lm aWMgU0ZzIGFuZCB0aGVyZWJ5IHBhcnRpYWxseSB0ZXN0IFNGQwogICBhdmFpbGFiaWxpdHkuICBB bHRlcm5hdGVseSwgdGhlIGluaXRpYXRvciBjb3VsZCBzZW5kIE9BTSBwYWNrZXRzIHdpdGgKICAg c2VxdWVudGlhbGx5IGluY3JlbWVudGluZyB0aGUgVFRMIGluIHRoZSBOU0ggdG8gdHJhY2UgdGhl IFNGUC4KCiAgIEl0IGNvdWxkIGJlIG9ic2VydmVkIHRoYXQgSUNNUCBhdCBpdHMgY3VycmVudCBz dGFnZSBtYXkgbm90IGJlIGFibGUKICAgdG8gcGVyZm9ybSBhbGwgcmVxdWlyZWQgU0ZDIE9BTSBm dW5jdGlvbnMsIGJ1dCBhcyBleHBsYWluZWQgYWJvdmUsIGl0CiAgIGNhbiBiZSB1c2VkIGZvciBz b21lIG9mIHRoZSBjb25uZWN0aXZpdHkgZnVuY3Rpb25zLgoKNi40LjIuICBCRkQvU2VhbWxlc3Mt QkZECgogICBbUkZDNTg4MF0gZGVmaW5lcyBCaWRpcmVjdGlvbmFsIEZvcndhcmRpbmcgRGV0ZWN0 aW9uIChCRkQpIG1lY2hhbmlzbQogICBmb3IgZmFpbHVyZSBkZXRlY3Rpb24uICBbUkZDNTg4MV0g YW5kIFtSRkM1ODg0XSBkZWZpbmUgdGhlCiAgIGFwcGxpY2FiaWxpdHkgb2YgQkZEIGluIElQdjQs IElQdjYgYW5kIE1QTFMgbmV0d29ya3MuICBbUkZDNzg4MF0KICAgZGVmaW5lcyBTZWFtbGVzcyBC RkQgKFMtQkZEKSwgYSBzaW1wbGlmaWVkIG1lY2hhbmlzbSBvZiB1c2luZyBCRkQuCiAgIFtSRkM3 ODgxXSBleHBsYWlucyBpdHMgYXBwbGljYWJpbGl0eSBpbiBJUHY0LCBJUHY2IGFuZCBNUExTIG5l dHdvcmsuCgogICBCRkQgb3IgUy1CRkQgY291bGQgYmUgbGV2ZXJhZ2VkIHRvIHBlcmZvcm0gY29u dGludWl0eSBmdW5jdGlvbiBmb3IgU0YKICAgb3IgU0ZDLiAgQW4gaW5pdGlhdG9yIGNvdWxkIGdl bmVyYXRlIGEgQkZEIGNvbnRyb2wgcGFja2V0IGFuZCBzZXQgdGhlCiAgICJZb3VyIERpc2NyaW1p bmF0b3IiIHZhbHVlIGFzIGxhc3QgU0ZGIGluIHRoZSBjb250cm9sIHBhY2tldC4gIFVwb24KICAg cmVjZWl2aW5nIHRoZSBjb250cm9sIHBhY2tldCwgdGhlIGxhc3QgU0ZGIGluIHRoZSBTRkMgd2ls bCByZXBseSBiYWNrCiAgIHdpdGggcmVsZXZhbnQgRElBRyBjb2RlLiAgVGhlIFRUTCBmaWVsZCBp biB0aGUgTlNIIGhlYWRlciBjb3VsZCBiZQogICB1c2VkIHRvIHBlcmZvcm0gcGFydGlhbCBTRkMg YXZhaWxhYmlsaXR5LiAgRm9yIGV4YW1wbGUsIHRoZSBpbml0aWF0b3IKICAgY2FuIHNldCB0aGUg IllvdXIgRGlzY3JpbWluYXRvciIgdmFsdWUgdG8gdGhlIFNGIHRoYXQgaXMgaW50ZW5kZWQgdG8K CgoKQWxkcmluLCBldCBhbC4gICAgICAgICAgRXhwaXJlcyBPY3RvYmVyIDI5LCAyMDIwICAgICAg ICAgICAgICAgW1BhZ2UgMTVdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIFNGQyBPQU0g RnJhbWV3b3JrICAgICAgICAgICAgICAgICBBcHJpbCAyMDIwCgoKICAgYmUgdGVzdGVkIGFuZCBz ZXQgdGhlIFRUTCBmaWVsZCBpbiBOU0ggaGVhZGVyIGluIGEgd2F5IHRoYXQgaXQKICAgZXhwaXJl cyBhdCB0aGUgcmVsZXZhbnQgU0YuICBIb3cgdGhlIGluaXRpYXRvciBnZXRzIHRoZSBEaXNjcmlt aW5hdG9yCiAgIHZhbHVlIG9mIHRoZSBTRiBpcyBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGlzIGRv Y3VtZW50LgoKNi40LjMuICBJbi1TaXR1IE9BTQoKICAgW0ktRC5pZXRmLXNmYy1pb2FtLW5zaF0g ZGVmaW5lcyBob3cgSW4tU2l0dSBPQU0gZGF0YSBmaWVsZHMgYXJlCiAgIHRyYW5zcG9ydGVkIHVz aW5nIE5TSCBoZWFkZXIuICBbSS1ELmlldGYtc2ZjLXByb29mLW9mLXRyYW5zaXRdCiAgIGRlZmlu ZXMgYSBtZWNoYW5pc20gdG8gcGVyZm9ybSBwcm9vZiBvZiB0cmFuc2l0IHRvIHNlY3VyZWx5IHZl cmlmeSBpZgogICBhIHBhY2tldCB0cmF2ZXJzZWQgdGhlIHJlbGV2YW50IFNGUCBvciBTRkMuICBX aGlsZSB0aGUgbWVjaGFuaXNtIGlzCiAgIGRlZmluZWQgaW5iYW5kIChpLmUuLCBpdCB3aWxsIGJl IGluY2x1ZGVkIGluIGRhdGEgcGFja2V0cyksIGl0IG1heSBiZQogICB1c2VkIHRvIHBlcmZvcm0g dmFyaW91cyBTRkMgT0FNIGZ1bmN0aW9ucyBhcyB3ZWxsLgoKICAgSW4tU2l0dSBPQU0gY291bGQg YmUgdXNlZCB3aXRoIE8gYml0IHNldCB0byBwZXJmb3JtIFNGIGF2YWlsYWJpbGl0eQogICBhbmQg U0ZDIGF2YWlsYWJpbGl0eSBvciBwZXJmb3JtYW5jZSBtZWFzdXJlbWVudC4KCjYuNC40LiAgU0ZD IFRyYWNlcm91dGUKCiAgIFtJLUQucGVubm8tc2ZjLXRyYWNlXSBkZWZpbmVzIGEgcHJvdG9jb2wg dGhhdCBjaGVja3MgZm9yIHBhdGgKICAgbGl2ZWxpbmVzcyBhbmQgdHJhY2VzIHRoZSBzZXJ2aWNl IGhvcHMgaW4gYW55IFNGUC4gIFNlY3Rpb24gMyBvZgogICBbSS1ELnBlbm5vLXNmYy10cmFjZV0g ZGVmaW5lcyB0aGUgU0ZDIHRyYWNlIHBhY2tldCBmb3JtYXQgd2hpbGUKICAgU2VjdGlvbnMgNCBh bmQgNSBvZiBbSS1ELnBlbm5vLXNmYy10cmFjZV0gZGVmaW5lcyB0aGUgYmVoYXZpb3Igb2YgU0YK ICAgYW5kIFNGRiByZXNwZWN0aXZlbHkuICBXaGlsZSBbSS1ELnBlbm5vLXNmYy10cmFjZV0gaGFz IGV4cGlyZWQsIHRoZQogICBwcm9wb3NhbCBpcyBpbXBsZW1lbnRlZCBpbiBPcGVuIERheWxpZ2h0 IGFuZCBhdmFpbGFibGUuCgogICBBbiBpbml0aWF0b3IgY2FuIGNvbnRyb2wgdGhlIFNlcnZpY2Ug SW5kZXggTGltaXQgKFNJTCkgaW4gU0ZDIHRyYWNlCiAgIHBhY2tldCB0byBwZXJmb3JtIFNGIGFu ZCBTRkMgYXZhaWxhYmlsaXR5IHRlc3QuCgo3LiAgTWFuYWdlYWJpbGl0eSBDb25zaWRlcmF0aW9u cwoKICAgVGhpcyBkb2N1bWVudCBkb2VzIG5vdCBkZWZpbmUgYW55IG5ldyBtYW5hZ2VhYmlsaXR5 IHRvb2xzIGJ1dAogICBjb25zb2xpZGF0ZXMgdGhlIG1hbmFnZWFiaWxpdHkgdG9vbCBnYXAgYW5h bHlzaXMgZm9yIFNGIGFuZCBTRkMuCiAgIFRhYmxlIDQgYmVsb3cgaXMgbm90IGV4aGF1c3RpdmUu CgoKCgoKCgoKCgoKCgoKCgoKCkFsZHJpbiwgZXQgYWwuICAgICAgICAgIEV4cGlyZXMgT2N0b2Jl ciAyOSwgMjAyMCAgICAgICAgICAgICAgIFtQYWdlIDE2XQoMCkludGVybmV0LURyYWZ0ICAgICAg ICAgICAgICBTRkMgT0FNIEZyYW1ld29yayAgICAgICAgICAgICAgICAgQXByaWwgMjAyMAoKCiAg ICAgICAgICAgICAgICAgICBUYWJsZSA0OiBPQU0gVG9vbCBHQVAgQW5hbHlzaXMKICArLS0tLS0t LS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tKy0tLS0tLS0tKy0tLS0tLS0t LS0tLS0rCiAgfCBMYXllciAgICAgICAgICB8Q29uZmlndXJhdGlvbiB8T3JjaGVzdHJhdGlvbnxU b3BvbG9neXxOb3RpZmljYXRpb24gfAogICstLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0t Ky0tLS0tLS0tLS0tLS0rLS0tLS0tLS0rLS0tLS0tLS0tLS0tLSsKICB8IFVuZGVybGF5IE4vdyAg IHxDTEksIE5FVENPTkYgIHwgQ0xJLCBORVRDT05GfFNOTVAgICAgfFNOTVAsIFN5c2xvZyx8CiAg fCAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICB8ICAgICAgICAgICAgIHwgICAgICAgIHxO RVRDT05GICAgICAgfAogICstLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tKy0tLS0tLS0t LS0tLS0rLS0tLS0tLS0rLS0tLS0tLS0tLS0tLSsKICB8IE92ZXJsYXkgTi93ICAgIHxDTEksIE5F VENPTkYgIHwgQ0xJLCBORVRDT05GfFNOTVAgICAgfFNOTVAsIFN5c2xvZyB8CiAgfCAgICAgICAg ICAgICAgICB8ICAgICAgICAgICAgICB8ICAgICAgICAgICAgIHwgICAgICAgIHxORVRDT05GICAg ICAgfAogICstLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0rLS0t LS0tLS0rLS0tLS0tLS0tLS0tLSsKICB8IENsYXNzaWZpZXIgICAgIHwgQ0xJLCBORVRDT05GIHwg Q0xJLCBORVRDT05GfCBOb25lICAgfCBOb25lICAgICAgICB8CiAgKy0tLS0tLS0tLS0tLS0tLS0r LS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLSstLS0tLS0tLSstLS0tLS0tLS0tLS0tKwogIHwg U0YgICAgICAgICAgICAgfENMSSwgTkVUQ09ORiAgfCBDTEksIE5FVENPTkZ8IE5vbmUgICB8IE5v bmUgICAgICAgIHwKICArLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0t LS0tKy0tLS0tLS0tKy0tLS0tLS0tLS0tLS0rCiAgfCBTRkMgICAgICAgICAgICB8Q0xJLCBORVRD T05GICB8IENMSSwgTkVUQ09ORnwgTm9uZSAgIHwgTm9uZSAgICAgICAgfAogICstLS0tLS0tLS0t LS0tLS0tKy0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0rLS0tLS0tLS0rLS0tLS0tLS0tLS0t LSsKCgogICBDb25maWd1cmF0aW9uLCBvcmNoZXN0cmF0aW9uIGFuZCBvdGhlciBtYW5hZ2VhYmls aXR5IHRhc2tzIG9mIFNGIGFuZAogICBTRkMgY291bGQgYmUgcGVyZm9ybWVkIHVzaW5nIENMSSwg TkVUQ09ORiwgZXRjLgoKICAgQXMgZGVwaWN0ZWQgaW4gVGFibGUgNCwgaW5mb3JtYXRpb24gYW5k IGRhdGEgbW9kZWxzIGFyZSBuZWVkZWQgZm9yCiAgIGNvbmZpZ3VyYXRpb24sIG1hbmFnZWFiaWxp dHkgYW5kIG9yY2hlc3RyYXRpb24gZm9yIFNGQy4gIFdpdGgKICAgdmlydHVhbGl6ZWQgU0YgYW5k IFNGQywgbWFuYWdlYWJpbGl0eSBuZWVkcyB0byBiZSBkb25lCiAgIHByb2dyYW1tYXRpY2FsbHku Cgo4LiAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMKCiAgIEFueSBzZWN1cml0eSBjb25zaWRlcmF0 aW9uIGRlZmluZWQgaW4gW1JGQzc2NjVdIGFuZCBbUkZDODMwMF0gYXJlCiAgIGFwcGxpY2FibGUg Zm9yIHRoaXMgZG9jdW1lbnQuCgogICBUaGUgT0FNIGluZm9ybWF0aW9uIGZyb20gc2VydmljZSBs YXllciBhdCBkaWZmZXJlbnQgY29tcG9uZW50cyBtYXkKICAgY29sbGVjdGl2ZWx5IG9yIGluZGVw ZW5kZW50bHkgcmV2ZWFsIHNlbnNpdGl2ZSBpbmZvcm1hdGlvbi4gIFRoZQogICBpbmZvcm1hdGlv biBtYXkgcmV2ZWFsIHRoZSB0eXBlIG9mIHNlcnZpY2UgZnVuY3Rpb25zIGhvc3RlZCBpbiB0aGUK ICAgbmV0d29yaywgdGhlIGNsYXNzaWZpY2F0aW9uIHJ1bGVzIGFuZCB0aGUgYXNzb2NpYXRlZCBz ZXJ2aWNlIGNoYWlucywKICAgc3BlY2lmaWMgc2VydmljZSBmdW5jdGlvbiBwYXRocyBldGMuICBU aGUgc2Vuc2l0aXZpdHkgb2YgdGhlCiAgIGluZm9ybWF0aW9uIGZyb20gU0ZDIGxheWVyIHJhaXNl cyBhIG5lZWQgZm9yIGNhcmVmdWwgc2VjdXJpdHkKICAgY29uc2lkZXJhdGlvbnMKCiAgIFRoZSBt YXBwaW5nIGFuZCB0aGUgcnVsZXMgaW5mb3JtYXRpb24gYXQgdGhlIGNsYXNzaWZpZXIgY29tcG9u ZW50IG1heQogICByZXZlYWwgdGhlIHRyYWZmaWMgcnVsZXMgYW5kIHRoZSB0cmFmZmljIG1hcHBl ZCB0byB0aGUgU0ZDLiAgVGhlIFNGQwogICBpbmZvcm1hdGlvbiBjb2xsZWN0ZWQgYXQgYW4gU0ZD IGNvbXBvbmVudCBtYXkgcmV2ZWFsIHRoZSBTRgogICBhc3NvY2lhdGVkIHdpdGhpbiBlYWNoIGNo YWluIGFuZCB0aGlzIGluZm9ybWF0aW9uIHRvZ2V0aGVyIHdpdGgKICAgY2xhc3NpZmllciBydWxl cyBtYXkgYmUgdXNlZCB0byBtYW5pcHVsYXRlIHRoZSBoZWFkZXIgb2Ygc3ludGhldGljCiAgIGF0 dGFjayBwYWNrZXRzIHRoYXQgbWF5IGJlIHVzZWQgdG8gYnlwYXNzIHRoZSBTRkMgYW5kIHRyaWdn ZXIgYW55CiAgIGludGVybmFsIGF0dGFja3MuCgoKCgoKQWxkcmluLCBldCBhbC4gICAgICAgICAg RXhwaXJlcyBPY3RvYmVyIDI5LCAyMDIwICAgICAgICAgICAgICAgW1BhZ2UgMTddCgwKSW50ZXJu ZXQtRHJhZnQgICAgICAgICAgICAgIFNGQyBPQU0gRnJhbWV3b3JrICAgICAgICAgICAgICAgICBB cHJpbCAyMDIwCgoKICAgVGhlIFNGIGluZm9ybWF0aW9uIGF0IHRoZSBTRiBjb21wb25lbnQgbWF5 IGJlIHVzZWQgYnkgYSBtYWxpY2lvdXMKICAgdXNlciB0byB0cmlnZ2VyIERlbmlhbCBvZiBTZXJ2 aWNlIChEb1MpIGF0dGFjayBieSBvdmVybG9hZGluZyBhbnkKICAgc3BlY2lmaWMgU0YgdXNpbmcg cm9ndWUgT0FNIHRyYWZmaWMuCgogICBUbyBhZGRyZXNzIHRoZSBhYm92ZSBjb25jZXJucywgU0ZD IGFuZCBTRiBPQU0gc2hvdWxkIHByb3ZpZGUKICAgbWVjaGFuaXNtcyBmb3I6CgogICBvICBNaXN1 c2Ugb2YgdGhlIE9BTSBjaGFubmVsIGZvciBkZW5pYWwtb2Ytc2VydmljZXMsCgogICBvICBMZWFr YWdlIG9mIE9BTSBwYWNrZXRzIGFjcm9zcyBTRkMgaW5zdGFuY2VzLCBhbmQKCiAgIG8gIExlYWth Z2Ugb2YgU0ZDIGluZm9ybWF0aW9uIGJleW9uZCB0aGUgU0ZDIGRvbWFpbi4KCiAgIFRoZSBkb2N1 bWVudHMgcHJvcG9zaW5nIHRoZSBPQU0gc29sdXRpb24gZm9yIFNGIGNvbXBvbmVudCBzaG91bGQK ICAgY29uc2lkZXIgcmF0ZS1saW1pdGluZyB0aGUgT0FNIHByb2JlcyBhdCBhIGZyZXF1ZW5jeSBn dWlkZWQgYnkgdGhlCiAgIGltcGxlbWVudGF0aW9uIGNob2ljZS4gIFJhdGUtbGltaXRpbmcgbWF5 IGJlIGFwcGxpZWQgYXQgdGhlIFNGRiBvcgogICB0aGUgU0YgLiBUaGUgT0FNIGluaXRpYXRvciBt YXkgbm90IHJlY2VpdmUgYSByZXNwb25zZSBmb3IgdGhlIHByb2JlcwogICB0aGF0IGFyZSByYXRl LWxpbWl0ZWQgcmVzdWx0aW5nIGluIGZhbHNlIG5lZ2F0aXZlcyBhbmQgdGhlCiAgIGltcGxlbWVu dGF0aW9uIHNob3VsZCBiZSBhd2FyZSBvZiB0aGlzLiAgVG8gbWl0aWdhdGUgYW55IGF0dGFja3Mg dGhhdAogICBsZXZlcmFnZSBPQU0gcGFja2V0cywgZnV0dXJlIGRvY3VtZW50cyBwcm9wb3Npbmcg T0FNIHNvbHV0aW9ucyBzaG91bGQKICAgZGVzY3JpYmUgdGhlIHVzZSBvZiBhbnkgdGVjaG5pcXVl IHRvIGRldGVjdCBhbmQgbWl0aWdhdGUgYW5vbWFsaWVzCiAgIGFuZCB2YXJpb3VzIHNlY3VyaXR5 IGF0dGFja3MuCgogICBUaGUgZG9jdW1lbnRzIHByb3Bvc2luZyB0aGUgT0FNIHNvbHV0aW9uIGZv ciBhbnkgc2VydmljZSBsYXllcgogICBjb21wb25lbnRzIHNob3VsZCBjb25zaWRlciBzb21lIGZv cm0gb2YgbWVzc2FnZSBmaWx0ZXJpbmcgdG8gcHJldmVudAogICBsZWFraW5nIGFueSBpbnRlcm5h bCBzZXJ2aWNlIGxheWVyIGluZm9ybWF0aW9uIG91dHNpZGUgdGhlCiAgIGFkbWluaXN0cmF0aXZl IGRvbWFpbi4KCjkuICBJQU5BIENvbnNpZGVyYXRpb25zCgogICBObyBhY3Rpb24gaXMgcmVxdWly ZWQgYnkgSUFOQSBmb3IgdGhpcyBkb2N1bWVudC4KCjEwLiAgQWNrbm93bGVkZ2VtZW50cwoKICAg V2Ugd291bGQgbGlrZSB0byB0aGFuayBNb2hhbWVkIEJvdWNhZGFpciwgQWRyaWFuIEZhcnJlbCwg R3JlZyBNaXJza3ksCiAgIFRhbCBNaXpyYWhpIGFuZCBNYXJ0aW4gVmlnb3VyZXV4IGZvciB0aGVp ciByZXZpZXcgYW5kIGNvbW1lbnRzLgoKMTEuICBDb250cmlidXRpbmcgQXV0aG9ycwoKICAgTm9i byBBa2l5YQogICBFcmljc3NvbgogICBFbWFpbDogbm9iby5ha2l5YS5kZXZAZ21haWwuY29tCgox Mi4gIFJlZmVyZW5jZXMKCgoKCgoKCkFsZHJpbiwgZXQgYWwuICAgICAgICAgIEV4cGlyZXMgT2N0 b2JlciAyOSwgMjAyMCAgICAgICAgICAgICAgIFtQYWdlIDE4XQoMCkludGVybmV0LURyYWZ0ICAg ICAgICAgICAgICBTRkMgT0FNIEZyYW1ld29yayAgICAgICAgICAgICAgICAgQXByaWwgMjAyMAoK CjEyLjEuICBOb3JtYXRpdmUgUmVmZXJlbmNlcwoKICAgW1JGQzIxMTldICBCcmFkbmVyLCBTLiwg IktleSB3b3JkcyBmb3IgdXNlIGluIFJGQ3MgdG8gSW5kaWNhdGUKICAgICAgICAgICAgICBSZXF1 aXJlbWVudCBMZXZlbHMiLCBCQ1AgMTQsIFJGQyAyMTE5LAogICAgICAgICAgICAgIERPSSAxMC4x NzQ4Ny9SRkMyMTE5LCBNYXJjaCAxOTk3LAogICAgICAgICAgICAgIDxodHRwczovL3d3dy5yZmMt ZWRpdG9yLm9yZy9pbmZvL3JmYzIxMTk+LgoKICAgW1JGQzc2NjVdICBIYWxwZXJuLCBKLiwgRWQu IGFuZCBDLiBQaWduYXRhcm8sIEVkLiwgIlNlcnZpY2UgRnVuY3Rpb24KICAgICAgICAgICAgICBD aGFpbmluZyAoU0ZDKSBBcmNoaXRlY3R1cmUiLCBSRkMgNzY2NSwKICAgICAgICAgICAgICBET0kg MTAuMTc0ODcvUkZDNzY2NSwgT2N0b2JlciAyMDE1LAogICAgICAgICAgICAgIDxodHRwczovL3d3 dy5yZmMtZWRpdG9yLm9yZy9pbmZvL3JmYzc2NjU+LgoKICAgW1JGQzgxNzRdICBMZWliYSwgQi4s ICJBbWJpZ3VpdHkgb2YgVXBwZXJjYXNlIHZzIExvd2VyY2FzZSBpbiBSRkMKICAgICAgICAgICAg ICAyMTE5IEtleSBXb3JkcyIsIEJDUCAxNCwgUkZDIDgxNzQsIERPSSAxMC4xNzQ4Ny9SRkM4MTc0 LAogICAgICAgICAgICAgIE1heSAyMDE3LCA8aHR0cHM6Ly93d3cucmZjLWVkaXRvci5vcmcvaW5m by9yZmM4MTc0Pi4KCiAgIFtSRkM4MzAwXSAgUXVpbm4sIFAuLCBFZC4sIEVsenVyLCBVLiwgRWQu LCBhbmQgQy4gUGlnbmF0YXJvLCBFZC4sCiAgICAgICAgICAgICAgIk5ldHdvcmsgU2VydmljZSBI ZWFkZXIgKE5TSCkiLCBSRkMgODMwMCwKICAgICAgICAgICAgICBET0kgMTAuMTc0ODcvUkZDODMw MCwgSmFudWFyeSAyMDE4LAogICAgICAgICAgICAgIDxodHRwczovL3d3dy5yZmMtZWRpdG9yLm9y Zy9pbmZvL3JmYzgzMDA+LgoKMTIuMi4gIEluZm9ybWF0aXZlIFJlZmVyZW5jZXMKCiAgIFtJLUQu aWV0Zi1zZmMtaW9hbS1uc2hdCiAgICAgICAgICAgICAgQnJvY2tuZXJzLCBGLiBhbmQgUy4gQmhh bmRhcmksICJOZXR3b3JrIFNlcnZpY2UgSGVhZGVyCiAgICAgICAgICAgICAgKE5TSCkgRW5jYXBz dWxhdGlvbiBmb3IgSW4tc2l0dSBPQU0gKElPQU0pIERhdGEiLCBkcmFmdC0KICAgICAgICAgICAg ICBpZXRmLXNmYy1pb2FtLW5zaC0wMyAod29yayBpbiBwcm9ncmVzcyksIE1hcmNoIDIwMjAuCgog ICBbSS1ELmlldGYtc2ZjLXByb29mLW9mLXRyYW5zaXRdCiAgICAgICAgICAgICAgQnJvY2tuZXJz LCBGLiwgQmhhbmRhcmksIFMuLCBNaXpyYWhpLCBULiwgRGFyYSwgUy4sIGFuZCBTLgogICAgICAg ICAgICAgIFlvdWVsbCwgIlByb29mIG9mIFRyYW5zaXQiLCBkcmFmdC1pZXRmLXNmYy1wcm9vZi1v Zi0KICAgICAgICAgICAgICB0cmFuc2l0LTA0ICh3b3JrIGluIHByb2dyZXNzKSwgTm92ZW1iZXIg MjAxOS4KCiAgIFtJLUQucGVubm8tc2ZjLXRyYWNlXQogICAgICAgICAgICAgIFBlbm5vLCBSLiwg UXVpbm4sIFAuLCBQaWduYXRhcm8sIEMuLCBhbmQgRC4gWmhvdSwKICAgICAgICAgICAgICAiU2Vy dmljZXMgRnVuY3Rpb24gQ2hhaW5pbmcgVHJhY2Vyb3V0ZSIsIGRyYWZ0LXBlbm5vLXNmYy0KICAg ICAgICAgICAgICB0cmFjZS0wMyAod29yayBpbiBwcm9ncmVzcyksIFNlcHRlbWJlciAyMDE1LgoK ICAgW1JGQzA3OTJdICBQb3N0ZWwsIEouLCAiSW50ZXJuZXQgQ29udHJvbCBNZXNzYWdlIFByb3Rv Y29sIiwgU1REIDUsCiAgICAgICAgICAgICAgUkZDIDc5MiwgRE9JIDEwLjE3NDg3L1JGQzA3OTIs IFNlcHRlbWJlciAxOTgxLAogICAgICAgICAgICAgIDxodHRwczovL3d3dy5yZmMtZWRpdG9yLm9y Zy9pbmZvL3JmYzc5Mj4uCgogICBbUkZDMzM5M10gIERlbWljaGVsaXMsIEMuIGFuZCBQLiBDaGlt ZW50bywgIklQIFBhY2tldCBEZWxheSBWYXJpYXRpb24KICAgICAgICAgICAgICBNZXRyaWMgZm9y IElQIFBlcmZvcm1hbmNlIE1ldHJpY3MgKElQUE0pIiwgUkZDIDMzOTMsCiAgICAgICAgICAgICAg RE9JIDEwLjE3NDg3L1JGQzMzOTMsIE5vdmVtYmVyIDIwMDIsCiAgICAgICAgICAgICAgPGh0dHBz Oi8vd3d3LnJmYy1lZGl0b3Iub3JnL2luZm8vcmZjMzM5Mz4uCgoKCgoKQWxkcmluLCBldCBhbC4g ICAgICAgICAgRXhwaXJlcyBPY3RvYmVyIDI5LCAyMDIwICAgICAgICAgICAgICAgW1BhZ2UgMTld CgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIFNGQyBPQU0gRnJhbWV3b3JrICAgICAgICAg ICAgICAgICBBcHJpbCAyMDIwCgoKICAgW1JGQzQ0NDNdICBDb250YSwgQS4sIERlZXJpbmcsIFMu LCBhbmQgTS4gR3VwdGEsIEVkLiwgIkludGVybmV0CiAgICAgICAgICAgICAgQ29udHJvbCBNZXNz YWdlIFByb3RvY29sIChJQ01QdjYpIGZvciB0aGUgSW50ZXJuZXQKICAgICAgICAgICAgICBQcm90 b2NvbCBWZXJzaW9uIDYgKElQdjYpIFNwZWNpZmljYXRpb24iLCBTVEQgODksCiAgICAgICAgICAg ICAgUkZDIDQ0NDMsIERPSSAxMC4xNzQ4Ny9SRkM0NDQzLCBNYXJjaCAyMDA2LAogICAgICAgICAg ICAgIDxodHRwczovL3d3dy5yZmMtZWRpdG9yLm9yZy9pbmZvL3JmYzQ0NDM+LgoKICAgW1JGQzU4 ODBdICBLYXR6LCBELiBhbmQgRC4gV2FyZCwgIkJpZGlyZWN0aW9uYWwgRm9yd2FyZGluZyBEZXRl Y3Rpb24KICAgICAgICAgICAgICAoQkZEKSIsIFJGQyA1ODgwLCBET0kgMTAuMTc0ODcvUkZDNTg4 MCwgSnVuZSAyMDEwLAogICAgICAgICAgICAgIDxodHRwczovL3d3dy5yZmMtZWRpdG9yLm9yZy9p bmZvL3JmYzU4ODA+LgoKICAgW1JGQzU4ODFdICBLYXR6LCBELiBhbmQgRC4gV2FyZCwgIkJpZGly ZWN0aW9uYWwgRm9yd2FyZGluZyBEZXRlY3Rpb24KICAgICAgICAgICAgICAoQkZEKSBmb3IgSVB2 NCBhbmQgSVB2NiAoU2luZ2xlIEhvcCkiLCBSRkMgNTg4MSwKICAgICAgICAgICAgICBET0kgMTAu MTc0ODcvUkZDNTg4MSwgSnVuZSAyMDEwLAogICAgICAgICAgICAgIDxodHRwczovL3d3dy5yZmMt ZWRpdG9yLm9yZy9pbmZvL3JmYzU4ODE+LgoKICAgW1JGQzU4ODRdICBBZ2dhcndhbCwgUi4sIEtv bXBlbGxhLCBLLiwgTmFkZWF1LCBULiwgYW5kIEcuIFN3YWxsb3csCiAgICAgICAgICAgICAgIkJp ZGlyZWN0aW9uYWwgRm9yd2FyZGluZyBEZXRlY3Rpb24gKEJGRCkgZm9yIE1QTFMgTGFiZWwKICAg ICAgICAgICAgICBTd2l0Y2hlZCBQYXRocyAoTFNQcykiLCBSRkMgNTg4NCwgRE9JIDEwLjE3NDg3 L1JGQzU4ODQsCiAgICAgICAgICAgICAgSnVuZSAyMDEwLCA8aHR0cHM6Ly93d3cucmZjLWVkaXRv ci5vcmcvaW5mby9yZmM1ODg0Pi4KCiAgIFtSRkM2MjkxXSAgQW5kZXJzc29uLCBMLiwgdmFuIEhl bHZvb3J0LCBILiwgQm9uaWNhLCBSLiwgUm9tYXNjYW51LAogICAgICAgICAgICAgIEQuLCBhbmQg Uy4gTWFuc2ZpZWxkLCAiR3VpZGVsaW5lcyBmb3IgdGhlIFVzZSBvZiB0aGUgIk9BTSIKICAgICAg ICAgICAgICBBY3JvbnltIGluIHRoZSBJRVRGIiwgQkNQIDE2MSwgUkZDIDYyOTEsCiAgICAgICAg ICAgICAgRE9JIDEwLjE3NDg3L1JGQzYyOTEsIEp1bmUgMjAxMSwKICAgICAgICAgICAgICA8aHR0 cHM6Ly93d3cucmZjLWVkaXRvci5vcmcvaW5mby9yZmM2MjkxPi4KCiAgIFtSRkM3NDk4XSAgUXVp bm4sIFAuLCBFZC4gYW5kIFQuIE5hZGVhdSwgRWQuLCAiUHJvYmxlbSBTdGF0ZW1lbnQgZm9yCiAg ICAgICAgICAgICAgU2VydmljZSBGdW5jdGlvbiBDaGFpbmluZyIsIFJGQyA3NDk4LAogICAgICAg ICAgICAgIERPSSAxMC4xNzQ4Ny9SRkM3NDk4LCBBcHJpbCAyMDE1LAogICAgICAgICAgICAgIDxo dHRwczovL3d3dy5yZmMtZWRpdG9yLm9yZy9pbmZvL3JmYzc0OTg+LgoKICAgW1JGQzc2NzldICBB bG1lcywgRy4sIEthbGlkaW5kaSwgUy4sIFpla2F1c2thcywgTS4sIGFuZCBBLiBNb3J0b24sCiAg ICAgICAgICAgICAgRWQuLCAiQSBPbmUtV2F5IERlbGF5IE1ldHJpYyBmb3IgSVAgUGVyZm9ybWFu Y2UgTWV0cmljcwogICAgICAgICAgICAgIChJUFBNKSIsIFNURCA4MSwgUkZDIDc2NzksIERPSSAx MC4xNzQ4Ny9SRkM3Njc5LCBKYW51YXJ5CiAgICAgICAgICAgICAgMjAxNiwgPGh0dHBzOi8vd3d3 LnJmYy1lZGl0b3Iub3JnL2luZm8vcmZjNzY3OT4uCgogICBbUkZDNzY4MF0gIEFsbWVzLCBHLiwg S2FsaWRpbmRpLCBTLiwgWmVrYXVza2FzLCBNLiwgYW5kIEEuIE1vcnRvbiwKICAgICAgICAgICAg ICBFZC4sICJBIE9uZS1XYXkgTG9zcyBNZXRyaWMgZm9yIElQIFBlcmZvcm1hbmNlIE1ldHJpY3MK ICAgICAgICAgICAgICAoSVBQTSkiLCBTVEQgODIsIFJGQyA3NjgwLCBET0kgMTAuMTc0ODcvUkZD NzY4MCwgSmFudWFyeQogICAgICAgICAgICAgIDIwMTYsIDxodHRwczovL3d3dy5yZmMtZWRpdG9y Lm9yZy9pbmZvL3JmYzc2ODA+LgoKICAgW1JGQzc4ODBdICBQaWduYXRhcm8sIEMuLCBXYXJkLCBE LiwgQWtpeWEsIE4uLCBCaGF0aWEsIE0uLCBhbmQgUy4KICAgICAgICAgICAgICBQYWxsYWdhdHRp LCAiU2VhbWxlc3MgQmlkaXJlY3Rpb25hbCBGb3J3YXJkaW5nIERldGVjdGlvbgogICAgICAgICAg ICAgIChTLUJGRCkiLCBSRkMgNzg4MCwgRE9JIDEwLjE3NDg3L1JGQzc4ODAsIEp1bHkgMjAxNiwK ICAgICAgICAgICAgICA8aHR0cHM6Ly93d3cucmZjLWVkaXRvci5vcmcvaW5mby9yZmM3ODgwPi4K CgoKCgoKQWxkcmluLCBldCBhbC4gICAgICAgICAgRXhwaXJlcyBPY3RvYmVyIDI5LCAyMDIwICAg ICAgICAgICAgICAgW1BhZ2UgMjBdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIFNGQyBP QU0gRnJhbWV3b3JrICAgICAgICAgICAgICAgICBBcHJpbCAyMDIwCgoKICAgW1JGQzc4ODFdICBQ aWduYXRhcm8sIEMuLCBXYXJkLCBELiwgYW5kIE4uIEFraXlhLCAiU2VhbWxlc3MKICAgICAgICAg ICAgICBCaWRpcmVjdGlvbmFsIEZvcndhcmRpbmcgRGV0ZWN0aW9uIChTLUJGRCkgZm9yIElQdjQs IElQdjYsCiAgICAgICAgICAgICAgYW5kIE1QTFMiLCBSRkMgNzg4MSwgRE9JIDEwLjE3NDg3L1JG Qzc4ODEsIEp1bHkgMjAxNiwKICAgICAgICAgICAgICA8aHR0cHM6Ly93d3cucmZjLWVkaXRvci5v cmcvaW5mby9yZmM3ODgxPi4KCiAgIFtSRkM4MDI5XSAgS29tcGVsbGEsIEsuLCBTd2FsbG93LCBH LiwgUGlnbmF0YXJvLCBDLiwgRWQuLCBLdW1hciwgTi4sCiAgICAgICAgICAgICAgQWxkcmluLCBT LiwgYW5kIE0uIENoZW4sICJEZXRlY3RpbmcgTXVsdGlwcm90b2NvbCBMYWJlbAogICAgICAgICAg ICAgIFN3aXRjaGVkIChNUExTKSBEYXRhLVBsYW5lIEZhaWx1cmVzIiwgUkZDIDgwMjksCiAgICAg ICAgICAgICAgRE9JIDEwLjE3NDg3L1JGQzgwMjksIE1hcmNoIDIwMTcsCiAgICAgICAgICAgICAg PGh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2luZm8vcmZjODAyOT4uCgogICBbUkZDODQ1OV0g IERvbHNvbiwgRC4sIEhvbW1hLCBTLiwgTG9wZXosIEQuLCBhbmQgTS4gQm91Y2FkYWlyLAogICAg ICAgICAgICAgICJIaWVyYXJjaGljYWwgU2VydmljZSBGdW5jdGlvbiBDaGFpbmluZyAoaFNGQyki LCBSRkMgODQ1OSwKICAgICAgICAgICAgICBET0kgMTAuMTc0ODcvUkZDODQ1OSwgU2VwdGVtYmVy IDIwMTgsCiAgICAgICAgICAgICAgPGh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2luZm8vcmZj ODQ1OT4uCgpBdXRob3JzJyBBZGRyZXNzZXMKCiAgIFNhbSBLLiBBbGRyaW4KICAgR29vZ2xlCgog ICBFbWFpbDogYWxkcmluLmlldGZAZ21haWwuY29tCgoKICAgQ2FybG9zIFBpZ25hdGFybyAoZWRp dG9yKQogICBDaXNjbyBTeXN0ZW1zLCBJbmMuCgogICBFbWFpbDogY3BpZ25hdGFAY2lzY28uY29t CgoKICAgTmFnZW5kcmEgS3VtYXIgKGVkaXRvcikKICAgQ2lzY28gU3lzdGVtcywgSW5jLgoKICAg RW1haWw6IG5haWt1bWFyQGNpc2NvLmNvbQoKCiAgIFJhbSBLcmlzaG5hbgogICBWTXdhcmUKCiAg IEVtYWlsOiByYW1rcmkxMjNAZ21haWwuY29tCgoKICAgQW5vb3AgR2hhbndhbmkKICAgRGVsbAoK ICAgRW1haWw6IGFub29wQGFsdW1uaS5kdWtlLmVkdQoKCgoKCkFsZHJpbiwgZXQgYWwuICAgICAg ICAgIEV4cGlyZXMgT2N0b2JlciAyOSwgMjAyMCAgICAgICAgICAgICAgIFtQYWdlIDIxXQo= --_003_760DA3B53B1047868EC9B107BFEBAC28ciscocom_-- From nobody Mon Apr 27 21:44:28 2020 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 9005A3A08FD; Mon, 27 Apr 2020 21:44:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 a4JZJmtQHvxJ; Mon, 27 Apr 2020 21:44:24 -0700 (PDT) Received: from out03.mta.xmission.com (out03.mta.xmission.com [166.70.13.233]) (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 19DBC3A08FC; Mon, 27 Apr 2020 21:44:24 -0700 (PDT) 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.90_1) (envelope-from ) id 1jTI6Y-0002Ip-St; Mon, 27 Apr 2020 22:44:23 -0600 Received: from [166.70.232.207] (helo=rumpleteazer.rhmr.com) by in01.mta.xmission.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.87) (envelope-from ) id 1jTI6X-0003Zt-Nq; Mon, 27 Apr 2020 22:44:22 -0600 Received: from rumpleteazer.rhmr.com (localhost [127.0.0.1]) by rumpleteazer.rhmr.com (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id 03S4fn2U001199; Mon, 27 Apr 2020 22:41:49 -0600 Received: (from hilarie@localhost) by rumpleteazer.rhmr.com (8.14.4/8.14.4/Submit) id 03S4fnUE001193; Mon, 27 Apr 2020 22:41:49 -0600 Date: Mon, 27 Apr 2020 22:41:49 -0600 Message-Id: <202004280441.03S4fnUE001193@rumpleteazer.rhmr.com> From: "Hilarie Orman" Reply-To: "Hilarie Orman" To: iesg@ietf.org, secdir@ietf.org Cc: draft-hodges-webauthn-registries.all@ietf.org X-XM-SPF: eid=1jTI6X-0003Zt-Nq; ; ; mid=<202004280441.03S4fnUE001193@rumpleteazer.rhmr.com>; ; ; hst=in01.mta.xmission.com; ; ; ip=166.70.232.207; ; ; frm=hilarie@purplestreak.com; ; ; spf=none X-XM-AID: U2FsdGVkX1/dqlDtCArYPnlN9dl2BXmH X-SA-Exim-Connect-IP: 166.70.232.207 X-SA-Exim-Mail-From: hilarie@purplestreak.com X-Spam-DCC: XMission; sa06 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ****;iesg@ietf.org, secdir@ietf.org X-Spam-Relay-Country: X-Spam-Timing: total 916 ms - load_scoreonly_sql: 0.04 (0.0%), signal_user_changed: 12 (1.3%), b_tie_ro: 10 (1.1%), parse: 0.88 (0.1%), extract_message_metadata: 13 (1.5%), get_uri_detail_list: 1.60 (0.2%), tests_pri_-1000: 3.6 (0.4%), tests_pri_-950: 1.20 (0.1%), tests_pri_-900: 0.98 (0.1%), tests_pri_-90: 512 (56.0%), check_bayes: 500 (54.6%), b_tokenize: 4.9 (0.5%), b_tok_get_all: 314 (34.3%), b_comp_prob: 2.3 (0.2%), b_tok_touch_all: 175 (19.1%), b_finish: 1.07 (0.1%), tests_pri_0: 358 (39.1%), check_dkim_signature: 0.45 (0.0%), check_dkim_adsp: 74 (8.0%), poll_dns_idle: 70 (7.7%), tests_pri_10: 3.1 (0.3%), tests_pri_500: 8 (0.9%), 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: [secdir] Security review of draft-hodges-webauthn-registries-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: Tue, 28 Apr 2020 04:44:26 -0000 Security review of Registries for Web Authentication draft-hodges-webauthn-registries-05 Do not be alarmed. I generated this review of 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 with the intent of improving security requirements and considerations in IETF drafts. Comments not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. This document establishes two registries required for the W3C Web Authentication system. The registries are for the WebAuthn Attestation Statement Format Identifier and the WebAuthn Extension Identifier. When submitted, these entries must be approved by an "expert" based on the specification that defines the parameters of the entry. This includes "security considerations", which is good. I don't quite see how submission of a request for a new entry gets routed to an expert, how experts come into being, etc., but I suppose that is a W3C procedure. A couple of nits. This url is listed twice in the URIs: https://www.iana.org/assignments/webauthn but it does not exist. I expected at least a TBD message, unless the address itself is a placeholder. In 2.1 "The Experts(s) MAY also designate attestation statement formats as proprietary if they lack complete specifications, and will assign a prefix indicating as such to the identifier." It is not clear what the format of that prefix is or how indicates "as such". Is that an indication that it is proprietary or (and?) that it is incomplete? Hilarie From nobody Mon Apr 27 22:26:40 2020 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 31CE33A0A99 for ; Mon, 27 Apr 2020 22:26:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, 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=mcafee.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 3B44XszPSkFJ for ; Mon, 27 Apr 2020 22:26:36 -0700 (PDT) Received: from us-smtp-delivery-140.mimecast.com (us-smtp-delivery-140.mimecast.com [216.205.24.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E5483A0A94 for ; Mon, 27 Apr 2020 22:26:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=mimecast20190606; t=1588051595; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=quk2baeQV+DJBmJ4GU4HW284fGQ6J9AA3RUN/A8YqcM=; b=gT6ou+FyVilsnQ2o7Re+a1Twme+fo2j3tlzNxQx/Ze+fkQK85+e/+4UAORnVUTTkqnZUwI rDVdC8/I+dAKOML8j36BWVBs9XK2Ge7G9e5A/nTQUc9S+7yX8WFKtX9dSmBsPSn+VZ+Md+ iOTF4jb4DYqI4kYXVWSPninPhD4qPy4= Received: from NAM11-DM6-obe.outbound.protection.outlook.com (mail-dm6nam11lp2168.outbound.protection.outlook.com [104.47.57.168]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-249-d7CvDs_UOSi_epbrVGNHpQ-1; Tue, 28 Apr 2020 01:26:33 -0400 X-MC-Unique: d7CvDs_UOSi_epbrVGNHpQ-1 Received: from CY4PR1601MB1254.namprd16.prod.outlook.com (2603:10b6:903:d4::12) by CY4PR1601MB1142.namprd16.prod.outlook.com (2603:10b6:903:d1::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.22; Tue, 28 Apr 2020 05:26:31 +0000 Received: from CY4PR1601MB1254.namprd16.prod.outlook.com ([fe80::8172:432c:9870:d8fc]) by CY4PR1601MB1254.namprd16.prod.outlook.com ([fe80::8172:432c:9870:d8fc%5]) with mapi id 15.20.2937.023; Tue, 28 Apr 2020 05:26:31 +0000 From: "Konda, Tirumaleswar Reddy" To: "Nagendra Kumar Nainar (naikumar)" , "Carlos Pignataro (cpignata)" CC: "secdir@ietf.org" , "draft-ietf-sfc-oam-framework@ietf.org" Thread-Topic: [sfc] Secdir last call review of draft-ietf-sfc-oam-framework Thread-Index: AdYW4VRPPDX1YR3aSqa2kbIsbH1DggD1H3GAADj+SVAAOXNWAAAlebMQ Date: Tue, 28 Apr 2020 05:26:31 +0000 Message-ID: References: <760DA3B5-3B10-4786-8EC9-B107BFEBAC28@cisco.com> In-Reply-To: <760DA3B5-3B10-4786-8EC9-B107BFEBAC28@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.5.0.44 dlp-reaction: no-action x-originating-ip: [49.37.204.18] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: bd357fc3-da6b-4517-8d26-08d7eb34b5db x-ms-traffictypediagnostic: CY4PR1601MB1142: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0387D64A71 x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CY4PR1601MB1254.namprd16.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(346002)(136003)(39860400002)(366004)(396003)(376002)(32952001)(54906003)(6506007)(66476007)(53546011)(4326008)(66446008)(66556008)(64756008)(66946007)(76116006)(110136005)(33656002)(316002)(7696005)(26005)(5660300002)(478600001)(86362001)(186003)(8936002)(71200400001)(55016002)(52536014)(9686003)(966005)(2906002)(81156014)(8676002)(85282002); DIR:OUT; SFP:1101; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Q891CPDkm0lJfS7otFhtgfxAOzYMflWo1hnk7GUqWApsNJdAx/h8vr9og4L0gD2DMbrqVclODTflPTH3WLwBNhoOVBaILs9COt9JyOwROlp2TjrDWUjVaI/2JZ3sNPQZhOC156UEmlsNQqo0nlYuCMMLjIuqfB8d2bKZ9lVvyKDj5lpnD1u6ghQMzAY+CYR2LfMdsBgsPLZC0+ZwJJcFj9pw8GubF68nFschMl3S2uceZxemd2bTFzI5TGSX0riSHm4Is4BlKUocH+NHLL3LMbz9Hh1rIwyViEDiQOYBrji2vuEgw34LaqgfgcqCuvB69d6jQRE09DkTTzBxydfXIwebaJ9yrtGWE+fgdyJUcbTRb+pSPztC2/y20xoHHZ1oJIC+RRvuB1J8+/O6Anc17cesvBq1O7tMnh1CEu0eiRZobGU1hdlg32x2xhzzZWpLZrK5G/5IJ6M+r8kf89haPJN4YKYJHStIZkNgdbeJo+iYleFZqOW2Xv4Eb4Ygr8kXZjulVOMJ9YCV24fAPLiJ3zPQwsT+1LLHUBdxGSxzB4/4nqEtbg3Aj0wGGD/G1CaMmkacSgXql15wUBmNJt1+5ot2EB8DGt8+YwJsmbJL0CU= x-ms-exchange-antispam-messagedata: Bk/J5NsMMoKHtNo/NBg/2s15/LDvVR3furzStq1ILppXEvD0ZjpPtuleyFMSNVYzADB/OtV2RCWHxBFbL1au62f4USsuWE3BDbttQHjFlEffNM+P36ueyPBMviEIBDNFt8Zk714U5lG7MKRra4ld7Y79aTzUJAf5caA/yxaLQJKb8NkE/A1Wt6ZQ7rt2ygS8TaAR/jccxZ6y78oFg8ub/1EUjZlym0qO1n/JlmjUrSs8cxoum0rPcD/iiiFx+ev0Vqh1ijdqIl0IomESxnN7KGNpbVNQzlbjwmKlMrpfEvNvRVp1Cvf1vo8VW/X6+45rHD3plQgiVZ7amUvSS7PVLr4hepvTAqB4bvoCOFgjz0zhOZFcVpBo6GFA13O9HRWwYomsRHi9e6XE8eEmNg0ivmxoD6gmGTUG8XNrBjAt/ozAUO4/pwe0aQKvHeQZjgEKxidzOS/+YJgwQWcDCEfCpuEf7aKs8qGkOyaeJT5H9kTs5qL5YdtPT5Ja9FxFLMxUUupsX0YiMttaUV3RYcehtLjUlStuadMJDfZyhI/KIVg9vfLVn2qvb2P/xFUzE1fa6N4TPopGeIqG5N+GM3KhUSsTzugoje/TqIbDuYzA5lf2dhi2gCADEYmO8Hwa2z5Y2Jg3zE0Fix3rpJ+kDJLC8WOAmY1miAy/07QRZ/iOL0oO9fDehh66EAEOSEIRHHx1IqKFH0VdULW7F+HqGS/TINGkcIEeWEio0h+8twCxZUxIr9Sz/lDhn5qAUtBxK2Hi55d4sZ64DroFBkAlRZ4Zspbw/oWMXo5f9k3XED7LB8M= x-ms-exchange-transport-forked: True MIME-Version: 1.0 X-OriginatorOrg: mcafee.com X-MS-Exchange-CrossTenant-Network-Message-Id: bd357fc3-da6b-4517-8d26-08d7eb34b5db X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Apr 2020 05:26:31.6076 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Wgb1dnEuZ7+MtVZmlAMFHec8nLi95ekoyozxj79dyi9vAmhYeY7tQDv440Yrla92sPC00+mulCnJg1qAoha4ZKZbE/Vb9r6fxrBtWxnzSZ6mL2azxiiaEWVJ3wq5Xv4I X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR1601MB1142 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: mcafee.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [secdir] [sfc] Secdir last call review of draft-ietf-sfc-oam-framework 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, 28 Apr 2020 05:26:39 -0000 SGkgTmFnZW5kcmEsDQoNCllvdSBtYXkgd2FudCB0byB1cGRhdGUgdGhlIGZvbGxvd2luZyBsaW5l Og0KDQpPTEQ6DQpUbyBhZGRyZXNzIHRoZSBhYm92ZSBjb25jZXJucywgU0ZDIGFuZCBTRiBPQU0g c2hvdWxkIHByb3ZpZGUgbWVjaGFuaXNtcyBmb3I6IA0KTkVXOg0KVG8gYWRkcmVzcyB0aGUgYWJv dmUgY29uY2VybnMsIFNGQyBhbmQgU0YgT0FNIHNob3VsZCBwcm92aWRlIG1lY2hhbmlzbXMgZm9y IHByZXZlbnRpbmc6DQoNClJlc3Qgb2YgdGhlIGNoYW5nZXMgbG9vayBnb29kLg0KDQpDaGVlcnMs DQotVGlydQ0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IE5hZ2VuZHJh IEt1bWFyIE5haW5hciAobmFpa3VtYXIpIDxuYWlrdW1hckBjaXNjby5jb20+DQo+IFNlbnQ6IE1v bmRheSwgQXByaWwgMjcsIDIwMjAgODowNiBQTQ0KPiBUbzogS29uZGEsIFRpcnVtYWxlc3dhciBS ZWRkeQ0KPiA8VGlydW1hbGVzd2FyUmVkZHlfS29uZGFATWNBZmVlLmNvbT47IENhcmxvcyBQaWdu YXRhcm8gKGNwaWduYXRhKQ0KPiA8Y3BpZ25hdGFAY2lzY28uY29tPg0KPiBDYzogc2VjZGlyQGll dGYub3JnOyBkcmFmdC1pZXRmLXNmYy1vYW0tZnJhbWV3b3JrQGlldGYub3JnDQo+IFN1YmplY3Q6 IFJlOiBbc2ZjXSBTZWNkaXIgbGFzdCBjYWxsIHJldmlldyBvZiBkcmFmdC1pZXRmLXNmYy1vYW0t ZnJhbWV3b3JrDQo+IA0KPiBDQVVUSU9OOiBFeHRlcm5hbCBlbWFpbC4gRG8gbm90IGNsaWNrIGxp bmtzIG9yIG9wZW4gYXR0YWNobWVudHMgdW5sZXNzIHlvdQ0KPiByZWNvZ25pemUgdGhlIHNlbmRl ciBhbmQga25vdyB0aGUgY29udGVudCBpcyBzYWZlLg0KPiANCj4gSGkgVGlydW1hbGVzd2FyLA0K PiANCj4gSG9wZSB5b3UgYXJlIGRvaW5nIGdvb2QuDQo+IA0KPiBUaGFuayB5b3UgZm9yIHRoZSBy ZXZpZXcgYW5kIHRoZSBjb21tZW50cy9zdWdnZXN0aW9ucy4gUGxlYXNlIGZpbmQgdGhlDQo+IGRp ZmYgYXR0YWNoZWQgdGhhdCBpbmNvcnBvcmF0ZXMgdGhlIGNvbW1lbnRzLg0KPiANCj4gV2Ugd2ls bCBzdWJtaXQgdGhlIG5ldyB2ZXJzaW9uIHdpdGggdGhlIGNoYW5nZXMuIExldCB1cyBrbm93IGlm IHlvdSBoYXZlDQo+IGFueSBmdXJ0aGVyIGNvbW1lbnRzLg0KPiANCj4gVGhhbmtzLA0KPiBOYWdl bmRyYQ0KPiANCj4g77u/T24gNC8yNi8yMCwgMzoyNCBBTSwgInNmYyBvbiBiZWhhbGYgb2YgS29u ZGEsIFRpcnVtYWxlc3dhciBSZWRkeSIgPHNmYy0NCj4gYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhh bGYgb2YgVGlydW1hbGVzd2FyUmVkZHlfS29uZGFATWNBZmVlLmNvbT4NCj4gd3JvdGU6DQo+IA0K PiAgICAgSGkgQ2FybG9zLA0KPiANCj4gICAgIFBsZWFzZSBzZWUgaW5saW5lDQo+IA0KPiAgICAg PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiAgICAgPiBGcm9tOiBDYXJsb3MgUGlnbmF0 YXJvIChjcGlnbmF0YSkgPGNwaWduYXRhQGNpc2NvLmNvbT4NCj4gICAgID4gU2VudDogU2F0dXJk YXksIEFwcmlsIDI1LCAyMDIwIDk6MjkgQU0NCj4gICAgID4gVG86IEtvbmRhLCBUaXJ1bWFsZXN3 YXIgUmVkZHkNCj4gPFRpcnVtYWxlc3dhclJlZGR5X0tvbmRhQE1jQWZlZS5jb20+DQo+ICAgICA+ IENjOiBzZWNkaXJAaWV0Zi5vcmc7IHNmY0BpZXRmLm9yZzsgZHJhZnQtaWV0Zi1zZmMtaW9hbS1u c2guYWxsQGlldGYub3JnDQo+ICAgICA+IFN1YmplY3Q6IFJlOiBbc2ZjXSBTZWNkaXIgbGFzdCBj YWxsIHJldmlldyBvZiBkcmFmdC1pZXRmLXNmYy1vYW0tZnJhbWV3b3JrDQo+ICAgICA+DQo+ICAg ICA+IENBVVRJT046IEV4dGVybmFsIGVtYWlsLiBEbyBub3QgY2xpY2sgbGlua3Mgb3Igb3BlbiBh dHRhY2htZW50cyB1bmxlc3MNCj4geW91DQo+ICAgICA+IHJlY29nbml6ZSB0aGUgc2VuZGVyIGFu ZCBrbm93IHRoZSBjb250ZW50IGlzIHNhZmUuDQo+ICAgICA+DQo+ICAgICA+IEhpLCBUaXJ1LA0K PiAgICAgPg0KPiAgICAgPiBNYW55IHRoYW5rcyBmb3IgdGhlIHJldmlldywgYW5kIGdyZWF0IHRv IGhlYXIgZnJvbSB5b3UhDQo+ICAgICA+DQo+ICAgICA+IEkgaG9wZSBhbGwgaXMgd2VsbCDigJQg UGxlYXNlIHNlZSBpbmxpbmUuDQo+IA0KPiAgICAgVGhhbmtzLCBJ4oCZbSBmaW5lLCBhbmQgSSBo b3BlIGFsbCBpcyB3ZWxsIHdpdGggeW91IHRvby4NCj4gDQo+ICAgICA+DQo+ICAgICA+ID4gMjAy MC8wNC8yMCDljYjliY0zOjI444CBS29uZGEsIFRpcnVtYWxlc3dhciBSZWRkeQ0KPiAgICAgPiA8 VGlydW1hbGVzd2FyUmVkZHlfS29uZGFATWNBZmVlLmNvbT7jga7jg6Hjg7zjg6s6DQo+ICAgICA+ ID4NCj4gICAgID4gPiBSZXZpZXdlcjogVGlydW1hbGVzd2FyIFJlZGR5DQo+ICAgICA+ID4gUmV2 aWV3IHJlc3VsdDogUmVhZHkgd2l0aCBpc3N1ZXMNCj4gICAgID4gPg0KPiAgICAgPiA+DQo+ICAg ICA+ID4gSSByZXZpZXdlZCB0aGlzIGRvY3VtZW50IGFzIHBhcnQgb2YgdGhlIHNlY3VyaXR5IGRp cmVjdG9yYXRlJ3Mgb25nb2luZw0KPiAgICAgPiA+IGVmZm9ydCB0byByZXZpZXcgYWxsIElFVEYg ZG9jdW1lbnRzIGVudGVyaW5nIHRoZSBJRVNHLi4gIFRoZXNlDQo+IGNvbW1lbnRzDQo+ICAgICA+ IGFyZSBkaXJlY3RlZCBhdCB0aGUgc2VjdXJpdHkgYXJlYSBkaXJlY3RvcihzKS4gIERvY3VtZW50 IGVkaXRvcnMgYW5kIFdHDQo+ICAgICA+IGNoYWlycyBzaG91bGQgdHJlYXQgdGhlc2UgY29tbWVu dHMgbGlrZSBhbnkgb3RoZXIgbGFzdCBjYWxsIGNvbW1lbnRzLg0KPiAgICAgPiA+DQo+ICAgICA+ ID4gVGhpcyBkb2N1bWVudCBwcm92aWRlcyBhIHJlZmVyZW5jZSBmcmFtZXdvcmsgZm9yIE9BTSBm b3IgU0ZDLg0KPiAgICAgPiA+DQo+ICAgICA+ID4gQ29tbWVudHM6DQo+ICAgICA+ID4NCj4gICAg ID4gPiAxLiBUaGUgZG9jdW1lbnQgaW4gU2VjdGlvbiA4IGRpc2N1c3NlcyB2YXJpb3VzIGF0dGFj a3MgKGluY2x1ZGluZyBib3RoDQo+ICAgICA+ID4gc2VjdXJpdHkgYW5kIHByaXZhY3kpIGJ1dCBk b2VzIG5vdCBkaXNjdXNzIGFueSBwcm90ZWN0aW9uIG1lY2hhbmlzbXMNCj4gICAgID4gb3RoZXIg dGhhbiBwcm9wb3NpbmcgcmF0ZS1saW1pdGluZy4gIEl0IGlzIHN1Z2dlc3RpbmcgZHJhZnRzIHBy b3Bvc2luZyB0aGUNCj4gT0FNDQo+ICAgICA+IHNvbHV0aW9uIHNob3VsZCBhZGRyZXNzIHRoZSBh dHRhY2tzIGJ1dCBJIGRvbuKAmXQgc2VlIGFueSBzZWN1cml0eQ0KPiBtZWNoYW5pc21zDQo+ICAg ICA+IGRpc2N1c3NlZCBpbiBkcmFmdC1pZXRmLXNmYy1pb2FtLW5zaCB0byBhZGRyZXNzIHRoZSBh dHRhY2tzLg0KPiAgICAgPiA+DQo+ICAgICA+DQo+ICAgICA+IFNpbmNlIHRoZSBkb2N1bWVudCBh bHJlYWR5IGNsYXJpZmllcyB0aGF0IGl0IGRvZXMgbm90IGRlZmluZSBzb2x1dGlvbnMsIGl0DQo+ ICAgICA+IGNhbm5vdCBkZWZpbmUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbiBmb3IgdGhvc2Ugc29s dXRpb25zLCBiZXlvbmQgc2F5aW5nDQo+IHRoYXQNCj4gICAgID4gdGhvc2Ugc29sdXRpb25zIG91 Z2h0IHRvIGFkZHJlc3Mgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgaW4gdGhvc2UgYXJlYXMuDQo+ IEFueQ0KPiAgICAgPiBzZWN1cml0eSBtZWFzdXJlcyBtdXN0IGJlIGluY2x1ZGVkIGFuZCBleHBs YWluZWQgaW4gdGhlIHJlc3BlY3RpdmUNCj4gc29sdXRpb24NCj4gICAgID4gZG9jdW1lbnQuIEkg YmVsaWV2ZSB0aGlzIGNvbW1lbnQgcmVxdWlyZXMgcG90ZW50aWFsbHkgYWN0aW9uIG9uIGRyYWZ0 LQ0KPiBpZXRmLQ0KPiAgICAgPiBzZmMtaW9hbS1uc2ggYnV0IG5vdCBvbiB0aGlzIGRyYWZ0Lg0K PiANCj4gICAgIFl1cC4gSSBzZWUgdGhyZWUgc29sdXRpb25zIGZyb20gU0ZDIFdHIGEpIHNmYy1p b2FtLW5zaCBiKSBpZXRmLXNmYy1wcm9vZi0NCj4gb2YtdHJhbnNpdCAoRXhwZXJpbWVudGFsKSBj KSBwZW5uby1zZmMtdHJhY2UgKEV4cGlyZWQpLiBzZmMtaW9hbS1uc2ggaXMgdGhlDQo+IG9ubHkg Y3VycmVudCBzdGFuZGFyZHMgdHJhY2sgc3BlY2lmaWNhdGlvbiBhbmQgaXQgc2hvdWxkIGFkZHJl c3MgdGhlc2UgYXR0YWNrcy4NCj4gDQo+ICAgICA+DQo+ICAgICA+IFRoYXQgc2FpZCB5b3UgYXJl IHJpZ2h0IHJlZ2FyZGluZyB0aGUgc3BlY2lmaWNzIG9mIHRoZSByYXRlLWxpbWluZw0KPiAgICAg PiByZWNvbW1lbmRhdGlvbi4gU2VlIHRoZSBuZXh0IGFuc3dlciBmb3IgdGV4dC4NCj4gICAgID4N Cj4gICAgID4gQWxzbywgaW4gcmUtcmVhZGluZyBTZWN0aW9uIDgsIHNlZW1zIGxpa2UgdGhpczoN Cj4gICAgID4NCj4gICAgID4gICAgVG8gYWRkcmVzcyB0aGUgYWJvdmUgY29uY2VybnMsIFNGQyBh bmQgU0YgT0FNIG1heSBwcm92aWRlDQo+IG1lY2hhbmlzbQ0KPiAgICAgPiAgICBmb3I6DQo+ICAg ICA+DQo+ICAgICA+DQo+ICAgICA+IFNob3VsZCBzYXkNCj4gICAgID4NCj4gICAgID4gICAgVG8g YWRkcmVzcyB0aGUgYWJvdmUgY29uY2VybnMsIFNGQyBhbmQgU0YgT0FNIHNob3VsZCBwcm92aWRl DQo+ICAgICA+IG1lY2hhbmlzbXMNCj4gICAgID4gICAgZm9yIHByZXZlbnRpbmc6DQo+IA0KPiAg ICAgWWVzLg0KPiANCj4gICAgID4NCj4gICAgID4NCj4gICAgID4NCj4gICAgID4gPiAyLiBNb3Jl IGRpc2N1c3Npb24gaXMgcmVxdWlyZWQgb24gdGhlIGludGVybmFsIGF0dGFja3MuDQo+ICAgICA+ ID4gKGEpIEhvdyBhcmUgYXR0YWNrIHBhY2tldHMgYnlwYXNzaW5nIFNGQyBkZXRlY3RlZCBhbmQg YmxvY2tlZCA/DQo+ICAgICA+ID4gKGIpIEhvdyBpcyBzZW5zaXRpdmUgaW5mb3JtYXRpb24gcHJv dGVjdGVkIGZyb20gZWF2ZXNkcm9wcGVycyA/DQo+ICAgICA+ID4gKGMpIEhvdyBpcyBEb1MvRERv UyBhdHRhY2sgb2YgbWlzdXNpbmcgdGhlIE9BTSBjaGFubmVsIGlzIG1pdGlnYXRlZCA/DQo+ICAg ICA+ID4gKGQpIFJhdGUtbGltaXRpbmcgYmxvY2tzIGJvdGggZ29vZCBhbmQgYmFkIE9BTSBwcm9i ZXMgYW5kIGlzIGEgd2Vhaw0KPiAgICAgPiBtaXRpZ2F0aW9uIHN0cmF0ZWd5LiBBbm9tYWx5IGRl dGVjdGlvbiAoZS5nLiwgZGVlcCBsZWFybmluZyB0ZWNoaW5xdWVzKQ0KPiBhbmQNCj4gICAgID4g aWRlbnRpZnlpbmcgdGhlIGF0dGFja2VyIGxvb2sgbGlrZSBhIGJldHRlciBzdHJhdGVneS4NCj4g ICAgID4gPg0KPiAgICAgPg0KPiAgICAgPg0KPiAgICAgPiBUaGlzIGlzIGEgZ29vZCBwb2ludC4g SG93IGFib3V0Lg0KPiAgICAgPg0KPiAgICAgPiBPTEQ6DQo+ICAgICA+DQo+ICAgICA+ICAgIFRo ZSBkb2N1bWVudHMgcHJvcG9zaW5nIHRoZSBPQU0gc29sdXRpb24gZm9yIFNGIGNvbXBvbmVudCBz aG91bGQNCj4gICAgID4gICAgY29uc2lkZXIgcmF0ZS1saW1pdGluZyB0aGUgT0FNIHByb2JlcyBh dCBhIGZyZXF1ZW5jeSBndWlkZWQgYnkgdGhlDQo+ICAgICA+ICAgIGltcGxlbWVudGF0aW9uIGNo b2ljZS4gIFJhdGUtbGltaXRpbmcgbWF5IGJlIGFwcGxpZWQgYXQgdGhlIFNGRiBvcg0KPiAgICAg PiAgICB0aGUgU0YgLiBUaGUgT0FNIGluaXRpYXRvciBtYXkgbm90IHJlY2VpdmUgYSByZXNwb25z ZSBmb3IgdGhlIHByb2Jlcw0KPiAgICAgPiAgICB0aGF0IGFyZSByYXRlLWxpbWl0ZWQgcmVzdWx0 aW5nIGluIGZhbHNlIG5lZ2F0aXZlcyBhbmQgdGhlDQo+ICAgICA+ICAgIGltcGxlbWVudGF0aW9u IHNob3VsZCBiZSBhd2FyZSBvZiB0aGlzLg0KPiAgICAgPg0KPiAgICAgPg0KPiAgICAgPiBORVc6 DQo+ICAgICA+DQo+ICAgICA+DQo+ICAgICA+ICAgIFRoZSBkb2N1bWVudHMgcHJvcG9zaW5nIHRo ZSBPQU0gc29sdXRpb24gZm9yIFNGIGNvbXBvbmVudCBzaG91bGQNCj4gICAgID4gICAgY29uc2lk ZXIgcmF0ZS1saW1pdGluZyB0aGUgT0FNIHByb2JlcyBhdCBhIGZyZXF1ZW5jeSBndWlkZWQgYnkg dGhlDQo+ICAgICA+ICAgIGltcGxlbWVudGF0aW9uIGNob2ljZS4gIFJhdGUtbGltaXRpbmcgbWF5 IGJlIGFwcGxpZWQgYXQgdGhlIFNGRiBvcg0KPiAgICAgPiAgICB0aGUgU0YuICBUaGUgT0FNIGlu aXRpYXRvciBtYXkgbm90IHJlY2VpdmUgYSByZXNwb25zZSBmb3IgdGhlIHByb2Jlcw0KPiAgICAg PiAgICB0aGF0IGFyZSByYXRlLWxpbWl0ZWQgcmVzdWx0aW5nIGluIGZhbHNlIG5lZ2F0aXZlcyBh bmQgdGhlDQo+ICAgICA+ICAgIGltcGxlbWVudGF0aW9uIHNob3VsZCBiZSBhd2FyZSBvZiB0aGlz LiBUbyBtaXRpZ2F0ZSBhbnkgYXR0YWNrcyB0aGF0DQo+ICAgICA+ICAgIExldmVyYWdlIE9BTSBw YWNrZXRzLCBmdXR1cmUgZG9jdW1lbnRzIHByb3Bvc2luZyBPQU0gc29sdXRpb25zDQo+ICAgICA+ ICAgIHNob3VsZCBkZXNjcmliZSB0aGUgdXNlIG9mIGFueSB0ZWNobmlxdWVzIHRvIGRldGVjdA0K PiAgICAgPiAgICBhbmQgbWl0aWdhdGUgYW5vbWFsaWVzIGFuZCB2YXJpb3VzIHNlY3VyaXR5ICBh dHRhY2tzLg0KPiANCj4gICAgIFdvcmtzIGZvciBtZS4NCj4gDQo+ICAgICBDaGVlcnMsDQo+ICAg ICAtVGlydQ0KPiANCj4gICAgID4NCj4gICAgID4NCj4gICAgID4gV291bGQgdGhhdCB3b3JrPw0K PiAgICAgPg0KPiAgICAgPiBQbGVhc2UgZmVlbCBmcmVlIHRvIHN1Z2dlc3QgdGV4dHVhbCBpbXBy b3ZlbWVudHMgb3IgY2hhbmdlcy4NCj4gICAgID4NCj4gICAgID4gVGhhbmtzLA0KPiAgICAgPg0K PiAgICAgPiBDYXJsb3MuDQo+ICAgICA+DQo+ICAgICA+ID4gQ2hlZXJzLA0KPiAgICAgPiA+IC1U aXJ1DQo+ICAgICA+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4gICAgID4gPiBzZmMgbWFpbGluZyBsaXN0DQo+ICAgICA+ID4gc2ZjQGlldGYub3Jn DQo+ICAgICA+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4g DQo+ICAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PiAgICAgc2ZjIG1haWxpbmcgbGlzdA0KPiAgICAgc2ZjQGlldGYub3JnDQo+ICAgICBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPiANCg0K From nobody Tue Apr 28 02:45:34 2020 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 18CEF3A11F7; Tue, 28 Apr 2020 02:45:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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=EYCm/IjF; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=AELZzjjU 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 S3WpUiYfXkBL; Tue, 28 Apr 2020 02:45:23 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5298A3A11FA; Tue, 28 Apr 2020 02:45:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9192; q=dns/txt; s=iport; t=1588067123; x=1589276723; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=jvo4psHgDPjfegOxvsEwuYpQOroRuqCXxxccWKxReiU=; b=EYCm/IjFOZpxICYaR4dO3F+L4XQO7c8GECeI6jbuNVSQlQFTPE9Jkipb e16hGfLlc3WbbtP3ZYYzlDgFP7dQXdjMv1VbhyQ9GJWeY+xFRjR3gU/Uz 6n6IPerZdJDw1eloHJ3fXGBJD9iiYdimqA5IhyOsXFBjiDnWwJRsTxy6T Q=; IronPort-PHdr: =?us-ascii?q?9a23=3AgRQQ8B/h6Z+OZP9uRHGN82YQeigqvan1NQcJ65?= =?us-ascii?q?0hzqhDabmn44+7ZRCN7vR2h1iPVoLeuLpIiOvT5qbnX2FIoZOMq2sLf5EEUR?= =?us-ascii?q?gZwd4XkAotDI/gawX7IffmYjZ8EJFEU1lorHq6KkNSXs35Yg6arni79zVHHB?= =?us-ascii?q?L5OEJ8Lfj0HYiHicOx2qiy9pTfbh8OiiC6ZOZ5LQ69qkPascxFjA=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ArAABR+qde/5pdJa1mGgEBAQEBAQE?= =?us-ascii?q?BAQMBAQEBEQEBAQICAQEBATyBNgIBAQEBCwGBU1EFbFgvKgqEFYNGA40vJZg?= =?us-ascii?q?vgUKBEANUCwEBAQwBARgLCgIEAQGERAIXghEkNwYOAgMBAQsBAQUBAQECAQU?= =?us-ascii?q?EbYUqByUMhXEBAQEBAgEBARAREQwBASsBCwEEBwQCAQYCEQQBAQECAiYCAgI?= =?us-ascii?q?lCxUICAEBBA4FGweDBAGCSwMOIAEOlwyQZwKBOYgsNXaBMoMAAQEFhTYYgg4?= =?us-ascii?q?DBoEOKgGCYoJDgg+CPIEggSwagUE/gREnDBCBT34+gmcBAYEmCgELBwEoMQK?= =?us-ascii?q?CWDKCLY4rgxCJCpdhCoJFmAAdgluIV4wlgSqDepFQmzACBAIEBQIOAQEFgWg?= =?us-ascii?q?jZnBwFTsqAYI+UBgNj16BVgwXg0+FFIVCdDUCBgEHAQEDCXyLW4E1ATBfAQE?= X-IronPort-AV: E=Sophos;i="5.73,327,1583193600"; d="scan'208";a="754042196" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 28 Apr 2020 09:45:16 +0000 Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by rcdn-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 03S9j4DP009256 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 28 Apr 2020 09:45:15 GMT Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 28 Apr 2020 04:45:03 -0500 Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 28 Apr 2020 05:45:02 -0400 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Tue, 28 Apr 2020 04:45:02 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Xg1zbzgxsvjwp7GhOM+1sQcPCcERdX/mZz6OlFxrLdHowWcc261YW99yF3nWMm+k9GH3oEeYdxQwmxHbdhrSAQNTxQuMHiFAIVGhgHFA2XD6g0EIF83umSF1hM965DXljre08vj8+dJk4BlsM+q7j/5c81duJLzoDeZ2RAA+hJUsmNudVlMy6NhtM/RhlvCmrmTVJO+rgS5C/Kb8F1lVK84M/vgLYuOG1A3QlJViStafcGK0FrAlqfsn8qwiI/bnoHaj9fwY1TQj3A0i4DMxfWyCjy7MMNfMcO+rfA8+qJs71kQ+zOO/0x5p8H3H8AgtktRUkB0v0Bxxsel0A6Tk5w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jvo4psHgDPjfegOxvsEwuYpQOroRuqCXxxccWKxReiU=; b=iofmzZMVeRgRF0UVSrnhBNvGSCPGDh5/D5nXKNYMZliYGt1c4E//Io+sx7C3g/dipG+zNRP84FgxqA5gop4BO0CUHhChKU/VUBG1WWHCUskW+wC9T+/OVouIAYXbXjFMP6yYsdEShFGvZd1+B/ypr8NJOqbi/echESNEvtKNgNf36fYiAxDXdIyPQn9u108QhUdJf1uXv9ZGnbkln4KK71dqBnCjeH2UPkpoN9ghCrB4/LU/krBwV5kEW5lAU3hNifpSSf/chJF7XU6JjbXGyA8J9WYupGi8YDE0YSyWc42Afs3E/8y3S4zBDlbqZ2SQ3LOyh/MjgVRVXYlKZktnMw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jvo4psHgDPjfegOxvsEwuYpQOroRuqCXxxccWKxReiU=; b=AELZzjjUW7p5dG/PgkQvhvSm9FkByWF9ZHxNEp/+DobNb4/WdN3HUkhKLzZFMlvf+nDSY+7madWuzusZYIT+37jlL9SZDR5NSLDOQEwXKmbi+HQx0VhInc5s0ccliRyYqz5fbg17QhMks9Z0y3I4HK06YJugf85KxQOeoE+bjMQ= Received: from BN8PR11MB3635.namprd11.prod.outlook.com (2603:10b6:408:86::20) by BN8PR11MB3617.namprd11.prod.outlook.com (2603:10b6:408:82::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.22; Tue, 28 Apr 2020 09:45:01 +0000 Received: from BN8PR11MB3635.namprd11.prod.outlook.com ([fe80::9981:86d4:ca20:ff96]) by BN8PR11MB3635.namprd11.prod.outlook.com ([fe80::9981:86d4:ca20:ff96%7]) with mapi id 15.20.2937.023; Tue, 28 Apr 2020 09:45:01 +0000 From: "Carlos Pignataro (cpignata)" To: "Konda, Tirumaleswar Reddy" CC: "Nagendra Kumar Nainar (naikumar)" , "secdir@ietf.org" , "draft-ietf-sfc-oam-framework@ietf.org" Thread-Topic: [sfc] Secdir last call review of draft-ietf-sfc-oam-framework Thread-Index: AdYW4VRPPDX1YR3aSqa2kbIsbH1DggD1H5cAADlwdwAAQWMSAAAfHIaAAAkHEqc= Date: Tue, 28 Apr 2020 09:45:01 +0000 Message-ID: <18633362-D237-41A0-8EAB-8B2D604CA677@cisco.com> References: <760DA3B5-3B10-4786-8EC9-B107BFEBAC28@cisco.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [108.203.7.63] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c60f7856-5d7a-486f-a8ff-08d7eb58d281 x-ms-traffictypediagnostic: BN8PR11MB3617: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0387D64A71 x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN8PR11MB3635.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(376002)(346002)(396003)(136003)(366004)(39860400002)(5660300002)(66946007)(64756008)(66556008)(66476007)(66446008)(6486002)(186003)(76116006)(6512007)(6916009)(316002)(4326008)(54906003)(6506007)(478600001)(966005)(53546011)(2906002)(2616005)(26005)(33656002)(81156014)(8676002)(86362001)(8936002)(71200400001)(91956017)(36756003); DIR:OUT; SFP:1101; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: TTyHJQqswu8LEzZqRv+4ZTL4Uuim5K88gUASXaEgWen7EhtBenWmH872TU5NcFRmtDIpU90h8XRAjhm1l1nHRPOMq02UHaAXEcwGVeSYicAlcXJ3Tbjkk092SH7ZArtK8vtiZr4/eT54hWPNO2O7cFLqs6Fi+rKTFicDrYH4CiQ2seVuS4h3FJGydwIXURtfCkRKzNL5FIqtiDy7IDu6QF3I6aw7cNPmY6+ez6qtsFAJlNsIkYU7SahTMSQCqTiqQPvWS1LuYpbrUf5+3CfZRDD0+sa1i2+F5eeEJUarOAX50R+bN9NGUUd5D4nwrHJaRKyoYcDo0ZWnX+hbs7DIPNFBdIbkEfRQfvX7BbkCruW4Ga4PmVH3KUtBTwd4fI79fstDGeWY2N1ThxpWbAkTrnsP+9hkTWk/CzUlbwXLfJuiidPiMxBWEDuljjuc9xd89Qr7XysPWwxcnrGfX6wiJaDD3yAyO2e8WJQGM7RIWt2vNosFCtHD3mGNRZ3jKeKbzZpsISUshejtBdpipeSpgA== x-ms-exchange-antispam-messagedata: 9sajuI1tUQLIXeN5Knl7dTSerGc/5afOPsQ4gbZpa9x2+ZwM0znZdIuruM3xCfFyjNfC9+DhGYg9HRPHX8zLo0NvRHETi1cYFVQkMB3htYiIAuasB+q1s2DAnKAdLYSPpuE3lfSPnJ/o+V0/JlcmRI4TRfkFqStMRcvnONon6i3JCHxy8vvxJYXJup0/V6zhyOZPf65hslaZA9SKDKLoULKkICfjW8EvKQYeSwqy3KO0HNxdwg9bhlfI55KcSMQy+sQQIqYlrZWcGE1piOqbgQ0e/9k+GvDGohrfWnSKegDPvthJtEh8M6IUN4xrtbPdY1NJOdvIvQTw1F1+EDSaX4sEm0GHwY0D1xnsgkOI14tvLrzwEtXYMPhlN2cBIHENpICFiliS4boBpx2Vip9UeZPJHnFhioluCFXI1WrXCJDOLJRlgekxHkIacElMfHhbjY6L8VR9t5+3fLKHhYw6/xv+LADqL1nbO8L6z/hYQCTxomDJh7O4rJBsFzNxVmQIinHZSzYuGUxNRidDMxA+V+B8CorDHnVtB8Xz/Yhns4FJL0ByJATjKg0AECCAvl0mgnTBhjhPciF2GkZjA1xp1a+4Htx0HIA2zfkoLK70PHF2gXfziOY86vGp8inkC3qqveh5Dk10lW0cm97U0tdsli3HvdbT1Mc93+m7lQ8blYSAjHRZHdrbynYitxq0dKxmQa+TcWVK6AUMc4LGl0TxF6brvJirrhTZ4WwWJzUULpBFEbUxInYxL16TCZ1jwkQ7PfADFcI5uwo6Fc7eIL4/4JT5tDo3OQ54x9+GgOwq8jU= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: c60f7856-5d7a-486f-a8ff-08d7eb58d281 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Apr 2020 09:45:01.6977 (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-CrossTenant-userprincipalname: vAwzX1G9T5Id9qiQ0+eoBrZTTlrcUnvL1xBS2DRdvt1JJYsJltn2uJKmYZPCt7Z3h9ioiGNpnvQzesZuFAJcaA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8PR11MB3617 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.11, xch-aln-001.cisco.com X-Outbound-Node: rcdn-core-3.cisco.com Archived-At: Subject: Re: [secdir] [sfc] Secdir last call review of draft-ietf-sfc-oam-framework 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, 28 Apr 2020 09:45:32 -0000 QWdyZWVkLiBUaGFua3MgVGlydS4gDQoNClNlbnQgZnJvbSBteSBpUGFkDQoNCj4gT24gQXByIDI4 LCAyMDIwLCBhdCAxOjI2IEFNLCBLb25kYSwgVGlydW1hbGVzd2FyIFJlZGR5IDxUaXJ1bWFsZXN3 YXJSZWRkeV9Lb25kYUBtY2FmZWUuY29tPiB3cm90ZToNCj4gDQo+IO+7v0hpIE5hZ2VuZHJhLA0K PiANCj4gWW91IG1heSB3YW50IHRvIHVwZGF0ZSB0aGUgZm9sbG93aW5nIGxpbmU6DQo+IA0KPiBP TEQ6DQo+IFRvIGFkZHJlc3MgdGhlIGFib3ZlIGNvbmNlcm5zLCBTRkMgYW5kIFNGIE9BTSBzaG91 bGQgcHJvdmlkZSBtZWNoYW5pc21zIGZvcjogDQo+IE5FVzoNCj4gVG8gYWRkcmVzcyB0aGUgYWJv dmUgY29uY2VybnMsIFNGQyBhbmQgU0YgT0FNIHNob3VsZCBwcm92aWRlIG1lY2hhbmlzbXMgZm9y IHByZXZlbnRpbmc6DQo+IA0KPiBSZXN0IG9mIHRoZSBjaGFuZ2VzIGxvb2sgZ29vZC4NCj4gDQo+ IENoZWVycywNCj4gLVRpcnUNCj4gDQo+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4g RnJvbTogTmFnZW5kcmEgS3VtYXIgTmFpbmFyIChuYWlrdW1hcikgPG5haWt1bWFyQGNpc2NvLmNv bT4NCj4+IFNlbnQ6IE1vbmRheSwgQXByaWwgMjcsIDIwMjAgODowNiBQTQ0KPj4gVG86IEtvbmRh LCBUaXJ1bWFsZXN3YXIgUmVkZHkNCj4+IDxUaXJ1bWFsZXN3YXJSZWRkeV9Lb25kYUBNY0FmZWUu Y29tPjsgQ2FybG9zIFBpZ25hdGFybyAoY3BpZ25hdGEpDQo+PiA8Y3BpZ25hdGFAY2lzY28uY29t Pg0KPj4gQ2M6IHNlY2RpckBpZXRmLm9yZzsgZHJhZnQtaWV0Zi1zZmMtb2FtLWZyYW1ld29ya0Bp ZXRmLm9yZw0KPj4gU3ViamVjdDogUmU6IFtzZmNdIFNlY2RpciBsYXN0IGNhbGwgcmV2aWV3IG9m IGRyYWZ0LWlldGYtc2ZjLW9hbS1mcmFtZXdvcmsNCj4+IA0KPj4gQ0FVVElPTjogRXh0ZXJuYWwg ZW1haWwuIERvIG5vdCBjbGljayBsaW5rcyBvciBvcGVuIGF0dGFjaG1lbnRzIHVubGVzcyB5b3UN Cj4+IHJlY29nbml6ZSB0aGUgc2VuZGVyIGFuZCBrbm93IHRoZSBjb250ZW50IGlzIHNhZmUuDQo+ PiANCj4+IEhpIFRpcnVtYWxlc3dhciwNCj4+IA0KPj4gSG9wZSB5b3UgYXJlIGRvaW5nIGdvb2Qu DQo+PiANCj4+IFRoYW5rIHlvdSBmb3IgdGhlIHJldmlldyBhbmQgdGhlIGNvbW1lbnRzL3N1Z2dl c3Rpb25zLiBQbGVhc2UgZmluZCB0aGUNCj4+IGRpZmYgYXR0YWNoZWQgdGhhdCBpbmNvcnBvcmF0 ZXMgdGhlIGNvbW1lbnRzLg0KPj4gDQo+PiBXZSB3aWxsIHN1Ym1pdCB0aGUgbmV3IHZlcnNpb24g d2l0aCB0aGUgY2hhbmdlcy4gTGV0IHVzIGtub3cgaWYgeW91IGhhdmUNCj4+IGFueSBmdXJ0aGVy IGNvbW1lbnRzLg0KPj4gDQo+PiBUaGFua3MsDQo+PiBOYWdlbmRyYQ0KPj4gDQo+PiDvu79PbiA0 LzI2LzIwLCAzOjI0IEFNLCAic2ZjIG9uIGJlaGFsZiBvZiBLb25kYSwgVGlydW1hbGVzd2FyIFJl ZGR5IiA8c2ZjLQ0KPj4gYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgVGlydW1hbGVzd2Fy UmVkZHlfS29uZGFATWNBZmVlLmNvbT4NCj4+IHdyb3RlOg0KPj4gDQo+PiAgICBIaSBDYXJsb3Ms DQo+PiANCj4+ICAgIFBsZWFzZSBzZWUgaW5saW5lDQo+PiANCj4+PiAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KPj4+IEZyb206IENhcmxvcyBQaWduYXRhcm8gKGNwaWduYXRhKSA8Y3BpZ25h dGFAY2lzY28uY29tPg0KPj4+IFNlbnQ6IFNhdHVyZGF5LCBBcHJpbCAyNSwgMjAyMCA5OjI5IEFN DQo+Pj4gVG86IEtvbmRhLCBUaXJ1bWFsZXN3YXIgUmVkZHkNCj4+IDxUaXJ1bWFsZXN3YXJSZWRk eV9Lb25kYUBNY0FmZWUuY29tPg0KPj4+IENjOiBzZWNkaXJAaWV0Zi5vcmc7IHNmY0BpZXRmLm9y ZzsgZHJhZnQtaWV0Zi1zZmMtaW9hbS1uc2guYWxsQGlldGYub3JnDQo+Pj4gU3ViamVjdDogUmU6 IFtzZmNdIFNlY2RpciBsYXN0IGNhbGwgcmV2aWV3IG9mIGRyYWZ0LWlldGYtc2ZjLW9hbS1mcmFt ZXdvcmsNCj4+PiANCj4+PiBDQVVUSU9OOiBFeHRlcm5hbCBlbWFpbC4gRG8gbm90IGNsaWNrIGxp bmtzIG9yIG9wZW4gYXR0YWNobWVudHMgdW5sZXNzDQo+PiB5b3UNCj4+PiByZWNvZ25pemUgdGhl IHNlbmRlciBhbmQga25vdyB0aGUgY29udGVudCBpcyBzYWZlLg0KPj4+IA0KPj4+IEhpLCBUaXJ1 LA0KPj4+IA0KPj4+IE1hbnkgdGhhbmtzIGZvciB0aGUgcmV2aWV3LCBhbmQgZ3JlYXQgdG8gaGVh ciBmcm9tIHlvdSENCj4+PiANCj4+PiBJIGhvcGUgYWxsIGlzIHdlbGwg4oCUIFBsZWFzZSBzZWUg aW5saW5lLg0KPj4gDQo+PiAgICBUaGFua3MsIEnigJltIGZpbmUsIGFuZCBJIGhvcGUgYWxsIGlz IHdlbGwgd2l0aCB5b3UgdG9vLg0KPj4gDQo+Pj4gDQo+Pj4+IDIwMjAvMDQvMjAg5Y2I5YmNMzoy OOOAgUtvbmRhLCBUaXJ1bWFsZXN3YXIgUmVkZHkNCj4+PiA8VGlydW1hbGVzd2FyUmVkZHlfS29u ZGFATWNBZmVlLmNvbT7jga7jg6Hjg7zjg6s6DQo+Pj4+IA0KPj4+PiBSZXZpZXdlcjogVGlydW1h bGVzd2FyIFJlZGR5DQo+Pj4+IFJldmlldyByZXN1bHQ6IFJlYWR5IHdpdGggaXNzdWVzDQo+Pj4+ IA0KPj4+PiANCj4+Pj4gSSByZXZpZXdlZCB0aGlzIGRvY3VtZW50IGFzIHBhcnQgb2YgdGhlIHNl Y3VyaXR5IGRpcmVjdG9yYXRlJ3Mgb25nb2luZw0KPj4+PiBlZmZvcnQgdG8gcmV2aWV3IGFsbCBJ RVRGIGRvY3VtZW50cyBlbnRlcmluZyB0aGUgSUVTRy4uICBUaGVzZQ0KPj4gY29tbWVudHMNCj4+ PiBhcmUgZGlyZWN0ZWQgYXQgdGhlIHNlY3VyaXR5IGFyZWEgZGlyZWN0b3IocykuICBEb2N1bWVu dCBlZGl0b3JzIGFuZCBXRw0KPj4+IGNoYWlycyBzaG91bGQgdHJlYXQgdGhlc2UgY29tbWVudHMg bGlrZSBhbnkgb3RoZXIgbGFzdCBjYWxsIGNvbW1lbnRzLg0KPj4+PiANCj4+Pj4gVGhpcyBkb2N1 bWVudCBwcm92aWRlcyBhIHJlZmVyZW5jZSBmcmFtZXdvcmsgZm9yIE9BTSBmb3IgU0ZDLg0KPj4+ PiANCj4+Pj4gQ29tbWVudHM6DQo+Pj4+IA0KPj4+PiAxLiBUaGUgZG9jdW1lbnQgaW4gU2VjdGlv biA4IGRpc2N1c3NlcyB2YXJpb3VzIGF0dGFja3MgKGluY2x1ZGluZyBib3RoDQo+Pj4+IHNlY3Vy aXR5IGFuZCBwcml2YWN5KSBidXQgZG9lcyBub3QgZGlzY3VzcyBhbnkgcHJvdGVjdGlvbiBtZWNo YW5pc21zDQo+Pj4gb3RoZXIgdGhhbiBwcm9wb3NpbmcgcmF0ZS1saW1pdGluZy4gIEl0IGlzIHN1 Z2dlc3RpbmcgZHJhZnRzIHByb3Bvc2luZyB0aGUNCj4+IE9BTQ0KPj4+IHNvbHV0aW9uIHNob3Vs ZCBhZGRyZXNzIHRoZSBhdHRhY2tzIGJ1dCBJIGRvbuKAmXQgc2VlIGFueSBzZWN1cml0eQ0KPj4g bWVjaGFuaXNtcw0KPj4+IGRpc2N1c3NlZCBpbiBkcmFmdC1pZXRmLXNmYy1pb2FtLW5zaCB0byBh ZGRyZXNzIHRoZSBhdHRhY2tzLg0KPj4+PiANCj4+PiANCj4+PiBTaW5jZSB0aGUgZG9jdW1lbnQg YWxyZWFkeSBjbGFyaWZpZXMgdGhhdCBpdCBkb2VzIG5vdCBkZWZpbmUgc29sdXRpb25zLCBpdA0K Pj4+IGNhbm5vdCBkZWZpbmUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbiBmb3IgdGhvc2Ugc29sdXRp b25zLCBiZXlvbmQgc2F5aW5nDQo+PiB0aGF0DQo+Pj4gdGhvc2Ugc29sdXRpb25zIG91Z2h0IHRv IGFkZHJlc3Mgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgaW4gdGhvc2UgYXJlYXMuDQo+PiBBbnkN Cj4+PiBzZWN1cml0eSBtZWFzdXJlcyBtdXN0IGJlIGluY2x1ZGVkIGFuZCBleHBsYWluZWQgaW4g dGhlIHJlc3BlY3RpdmUNCj4+IHNvbHV0aW9uDQo+Pj4gZG9jdW1lbnQuIEkgYmVsaWV2ZSB0aGlz IGNvbW1lbnQgcmVxdWlyZXMgcG90ZW50aWFsbHkgYWN0aW9uIG9uIGRyYWZ0LQ0KPj4gaWV0Zi0N Cj4+PiBzZmMtaW9hbS1uc2ggYnV0IG5vdCBvbiB0aGlzIGRyYWZ0Lg0KPj4gDQo+PiAgICBZdXAu IEkgc2VlIHRocmVlIHNvbHV0aW9ucyBmcm9tIFNGQyBXRyBhKSBzZmMtaW9hbS1uc2ggYikgaWV0 Zi1zZmMtcHJvb2YtDQo+PiBvZi10cmFuc2l0IChFeHBlcmltZW50YWwpIGMpIHBlbm5vLXNmYy10 cmFjZSAoRXhwaXJlZCkuIHNmYy1pb2FtLW5zaCBpcyB0aGUNCj4+IG9ubHkgY3VycmVudCBzdGFu ZGFyZHMgdHJhY2sgc3BlY2lmaWNhdGlvbiBhbmQgaXQgc2hvdWxkIGFkZHJlc3MgdGhlc2UgYXR0 YWNrcy4NCj4+IA0KPj4+IA0KPj4+IFRoYXQgc2FpZCB5b3UgYXJlIHJpZ2h0IHJlZ2FyZGluZyB0 aGUgc3BlY2lmaWNzIG9mIHRoZSByYXRlLWxpbWluZw0KPj4+IHJlY29tbWVuZGF0aW9uLiBTZWUg dGhlIG5leHQgYW5zd2VyIGZvciB0ZXh0Lg0KPj4+IA0KPj4+IEFsc28sIGluIHJlLXJlYWRpbmcg U2VjdGlvbiA4LCBzZWVtcyBsaWtlIHRoaXM6DQo+Pj4gDQo+Pj4gICBUbyBhZGRyZXNzIHRoZSBh Ym92ZSBjb25jZXJucywgU0ZDIGFuZCBTRiBPQU0gbWF5IHByb3ZpZGUNCj4+IG1lY2hhbmlzbQ0K Pj4+ICAgZm9yOg0KPj4+IA0KPj4+IA0KPj4+IFNob3VsZCBzYXkNCj4+PiANCj4+PiAgIFRvIGFk ZHJlc3MgdGhlIGFib3ZlIGNvbmNlcm5zLCBTRkMgYW5kIFNGIE9BTSBzaG91bGQgcHJvdmlkZQ0K Pj4+IG1lY2hhbmlzbXMNCj4+PiAgIGZvciBwcmV2ZW50aW5nOg0KPj4gDQo+PiAgICBZZXMuDQo+ PiANCj4+PiANCj4+PiANCj4+PiANCj4+Pj4gMi4gTW9yZSBkaXNjdXNzaW9uIGlzIHJlcXVpcmVk IG9uIHRoZSBpbnRlcm5hbCBhdHRhY2tzLg0KPj4+PiAoYSkgSG93IGFyZSBhdHRhY2sgcGFja2V0 cyBieXBhc3NpbmcgU0ZDIGRldGVjdGVkIGFuZCBibG9ja2VkID8NCj4+Pj4gKGIpIEhvdyBpcyBz ZW5zaXRpdmUgaW5mb3JtYXRpb24gcHJvdGVjdGVkIGZyb20gZWF2ZXNkcm9wcGVycyA/DQo+Pj4+ IChjKSBIb3cgaXMgRG9TL0REb1MgYXR0YWNrIG9mIG1pc3VzaW5nIHRoZSBPQU0gY2hhbm5lbCBp cyBtaXRpZ2F0ZWQgPw0KPj4+PiAoZCkgUmF0ZS1saW1pdGluZyBibG9ja3MgYm90aCBnb29kIGFu ZCBiYWQgT0FNIHByb2JlcyBhbmQgaXMgYSB3ZWFrDQo+Pj4gbWl0aWdhdGlvbiBzdHJhdGVneS4g QW5vbWFseSBkZXRlY3Rpb24gKGUuZy4sIGRlZXAgbGVhcm5pbmcgdGVjaGlucXVlcykNCj4+IGFu ZA0KPj4+IGlkZW50aWZ5aW5nIHRoZSBhdHRhY2tlciBsb29rIGxpa2UgYSBiZXR0ZXIgc3RyYXRl Z3kuDQo+Pj4+IA0KPj4+IA0KPj4+IA0KPj4+IFRoaXMgaXMgYSBnb29kIHBvaW50LiBIb3cgYWJv dXQuDQo+Pj4gDQo+Pj4gT0xEOg0KPj4+IA0KPj4+ICAgVGhlIGRvY3VtZW50cyBwcm9wb3Npbmcg dGhlIE9BTSBzb2x1dGlvbiBmb3IgU0YgY29tcG9uZW50IHNob3VsZA0KPj4+ICAgY29uc2lkZXIg cmF0ZS1saW1pdGluZyB0aGUgT0FNIHByb2JlcyBhdCBhIGZyZXF1ZW5jeSBndWlkZWQgYnkgdGhl DQo+Pj4gICBpbXBsZW1lbnRhdGlvbiBjaG9pY2UuICBSYXRlLWxpbWl0aW5nIG1heSBiZSBhcHBs aWVkIGF0IHRoZSBTRkYgb3INCj4+PiAgIHRoZSBTRiAuIFRoZSBPQU0gaW5pdGlhdG9yIG1heSBu b3QgcmVjZWl2ZSBhIHJlc3BvbnNlIGZvciB0aGUgcHJvYmVzDQo+Pj4gICB0aGF0IGFyZSByYXRl LWxpbWl0ZWQgcmVzdWx0aW5nIGluIGZhbHNlIG5lZ2F0aXZlcyBhbmQgdGhlDQo+Pj4gICBpbXBs ZW1lbnRhdGlvbiBzaG91bGQgYmUgYXdhcmUgb2YgdGhpcy4NCj4+PiANCj4+PiANCj4+PiBORVc6 DQo+Pj4gDQo+Pj4gDQo+Pj4gICBUaGUgZG9jdW1lbnRzIHByb3Bvc2luZyB0aGUgT0FNIHNvbHV0 aW9uIGZvciBTRiBjb21wb25lbnQgc2hvdWxkDQo+Pj4gICBjb25zaWRlciByYXRlLWxpbWl0aW5n IHRoZSBPQU0gcHJvYmVzIGF0IGEgZnJlcXVlbmN5IGd1aWRlZCBieSB0aGUNCj4+PiAgIGltcGxl bWVudGF0aW9uIGNob2ljZS4gIFJhdGUtbGltaXRpbmcgbWF5IGJlIGFwcGxpZWQgYXQgdGhlIFNG RiBvcg0KPj4+ICAgdGhlIFNGLiAgVGhlIE9BTSBpbml0aWF0b3IgbWF5IG5vdCByZWNlaXZlIGEg cmVzcG9uc2UgZm9yIHRoZSBwcm9iZXMNCj4+PiAgIHRoYXQgYXJlIHJhdGUtbGltaXRlZCByZXN1 bHRpbmcgaW4gZmFsc2UgbmVnYXRpdmVzIGFuZCB0aGUNCj4+PiAgIGltcGxlbWVudGF0aW9uIHNo b3VsZCBiZSBhd2FyZSBvZiB0aGlzLiBUbyBtaXRpZ2F0ZSBhbnkgYXR0YWNrcyB0aGF0DQo+Pj4g ICBMZXZlcmFnZSBPQU0gcGFja2V0cywgZnV0dXJlIGRvY3VtZW50cyBwcm9wb3NpbmcgT0FNIHNv bHV0aW9ucw0KPj4+ICAgc2hvdWxkIGRlc2NyaWJlIHRoZSB1c2Ugb2YgYW55IHRlY2huaXF1ZXMg dG8gZGV0ZWN0DQo+Pj4gICBhbmQgbWl0aWdhdGUgYW5vbWFsaWVzIGFuZCB2YXJpb3VzIHNlY3Vy aXR5ICBhdHRhY2tzLg0KPj4gDQo+PiAgICBXb3JrcyBmb3IgbWUuDQo+PiANCj4+ICAgIENoZWVy cywNCj4+ICAgIC1UaXJ1DQo+PiANCj4+PiANCj4+PiANCj4+PiBXb3VsZCB0aGF0IHdvcms/DQo+ Pj4gDQo+Pj4gUGxlYXNlIGZlZWwgZnJlZSB0byBzdWdnZXN0IHRleHR1YWwgaW1wcm92ZW1lbnRz IG9yIGNoYW5nZXMuDQo+Pj4gDQo+Pj4gVGhhbmtzLA0KPj4+IA0KPj4+IENhcmxvcy4NCj4+PiAN Cj4+Pj4gQ2hlZXJzLA0KPj4+PiAtVGlydQ0KPj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPj4+PiBzZmMgbWFpbGluZyBsaXN0DQo+Pj4+IHNmY0Bp ZXRmLm9yZw0KPj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0K Pj4gDQo+PiAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPj4gICAgc2ZjIG1haWxpbmcgbGlzdA0KPj4gICAgc2ZjQGlldGYub3JnDQo+PiAgICBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4gDQo+IA0K From nobody Tue Apr 28 06:53:46 2020 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 AC0E53A0A0F; Tue, 28 Apr 2020 06:53:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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=Qv64U0FE; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=y/7lZH/9 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 HJXzMQDLmykg; Tue, 28 Apr 2020 06:53:41 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 276993A09A0; Tue, 28 Apr 2020 06:53:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10838; q=dns/txt; s=iport; t=1588082021; x=1589291621; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=vXoN43zbfu4AWzmOQ1P5t936oarHMNsiKqS6Qkbd5JI=; b=Qv64U0FE4pyyvB88zXVSvfTb1w/kX0mxPBuZRCNQIRyT+ctsUqt4AgP4 fflxDYXGVi4bLH4+TC8bYLD5J0d5DkA7kozUHe+OaK/srxf2i8FTfKk50 axgLBmuhudbsx+Jne5jyMZ9KF77MQ/iUU0WJOQX647DRSXM7J4A8b2r0a 0=; IronPort-PHdr: =?us-ascii?q?9a23=3A841WHhVVu+A9+hECfYzWDQcLS2DV8LGuZFwc94?= =?us-ascii?q?YnhrRSc6+q45XlOgnF6O5wiEPSBNyFuddPouTbvubrXmlTqZqCsXVXdptKWl?= =?us-ascii?q?dFjMgNhAUvDYaDDlGzN//laSE2XaEgHF9o9n22Kw5ZTcD5YVCBh3ab4zMfXB?= =?us-ascii?q?74MFk9KuH8AIWHicOx2qi78IHSZAMdgj27bPtyIRy6oB+XuNMRhN5pK706zV?= =?us-ascii?q?3CpX4bdg=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AeAADSNKhe/49dJa1mGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBEQEBAQEBAQEBAQEBPIE2AQEBAQEBCwGBU1EFbFgvKgqEFYN?= =?us-ascii?q?GA40xJZgvgUKBEANUCwEBAQwBARgLCgIEAQGERAIXghEkNwYOAgMBAQsBAQU?= =?us-ascii?q?BAQECAQUEbYUqByUMhXEBAQEBAwEBEBERDAEBKwELAQsEAgEGAhEEAQEBAgI?= =?us-ascii?q?mAgICJQsVCAgBAQQBDQUbB4MEAYJLAy4BDpcakGcCgTmILDV2gTKDAAEBBYU?= =?us-ascii?q?rGIIOAwaBDioBgmKHEoEggSwaggCBEScMEIFPfj6CZwEBgSYKAQsHASEHMQK?= =?us-ascii?q?CWDKCLY4sO4JViQqHao9/CoJFmAMdgluIWIwohSSPfoFXmzACBAIEBQIOAQE?= =?us-ascii?q?FgWgjZnBwFTsqAYI+UBgNkFqBYQwXg0+FFIVCdDUCBgEHAQEDCXyPKYE1ATB?= =?us-ascii?q?fAQE?= X-IronPort-AV: E=Sophos;i="5.73,327,1583193600"; d="scan'208";a="506050370" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 28 Apr 2020 13:53:37 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by rcdn-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id 03SDrX0q025580 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 28 Apr 2020 13:53:35 GMT Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 28 Apr 2020 08:53:33 -0500 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.1497.2; Tue, 28 Apr 2020 09:53:32 -0400 Received: from NAM04-BN3-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.1497.2 via Frontend Transport; Tue, 28 Apr 2020 09:53:32 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XCt0M/XyzJGEHRrQ6sGkEt79+KjI4dM/B2vQKuEFd/ypUWoxYD9oYhlehmJILIEumANoyLc4VrXtGO/Ens6FhnQVYKswGizIIKK2XsycXv0KuCH3r7BOJnEGA3WEbGo5GoHMxqQdmMkyez523AFcPLVchjaaUJmNbxuLCc/QoLsx7eREWsUVDmQtesUi5wgqIFO4KLmjoaKZy7M1L727WTZPU/QEqXBYtgc58Z39uZWu7xF4Z8FJC8ixLluyYdzVhbzNet1T2CQWs/Zg9j9OAS5MxxZ9qE/1mh8I01ncczrm7AKDTYM9ADT6/v0P/n5B3zl77+JuXIjTL73It1lYzg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vXoN43zbfu4AWzmOQ1P5t936oarHMNsiKqS6Qkbd5JI=; b=BYddyb+KpFWmoTJDbeVP4F1kTHdgs4g3Se3upViR2l2LBsL0Jvgte9c/42/9t9hn6vYujF6IaSwqQQrEPkRi27+Muu9pT2GiIKGNAz23iUbHgsjg0V5/QiuybjqPhj22gWQwI1nXyGbv3/mwnhIUlTY8rGfOEjeIYJp81wITVscGZSCnmFU2lNrcXsDfat0KUbhV+w7g3eOF8agBYYWlH/5lmgJA9SjUZtuHH2IAOXrHStegK+3vJ6JMjQ4rHfCVZLGzCO7GuaGSVYFEP3PKILFC+QCsNIIHLGyqJfKT6vxLRHLQlUlyocI6HD+57BuYBTvJzxcXyMoWiekTP+Zt4w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vXoN43zbfu4AWzmOQ1P5t936oarHMNsiKqS6Qkbd5JI=; b=y/7lZH/9cSMjjVTWqkdZX98XkPzp7KEJmu3iZcgxZ6Dy3V5FCVz0hiJZUka7Adpg/ShvNBwTNuEDVQaCDG5pTfkeHMHoh/8alB8NNiYu/frJnE3w14LtPh1wLJBHc/UVSKvPmA5PfiiVoDr2Q9wvMXxAExZ0U52TMqvS5zVGxZA= Received: from BN6PR11MB4068.namprd11.prod.outlook.com (2603:10b6:405:7c::31) by BN6PR11MB1505.namprd11.prod.outlook.com (2603:10b6:405:c::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2958.19; Tue, 28 Apr 2020 13:53:32 +0000 Received: from BN6PR11MB4068.namprd11.prod.outlook.com ([fe80::cb:ae2d:1f21:7263]) by BN6PR11MB4068.namprd11.prod.outlook.com ([fe80::cb:ae2d:1f21:7263%4]) with mapi id 15.20.2958.019; Tue, 28 Apr 2020 13:53:31 +0000 From: "Nagendra Kumar Nainar (naikumar)" To: "Konda, Tirumaleswar Reddy" , "Carlos Pignataro (cpignata)" CC: "secdir@ietf.org" , "draft-ietf-sfc-oam-framework@ietf.org" Thread-Topic: [sfc] Secdir last call review of draft-ietf-sfc-oam-framework Thread-Index: AdYW4VRPPDX1YR3aSqa2kbIsbH1DggD1H3GAADj+SVAAOXNWAAAlebMQAAtYDYA= Date: Tue, 28 Apr 2020 13:53:31 +0000 Message-ID: References: <760DA3B5-3B10-4786-8EC9-B107BFEBAC28@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.35.20030802 authentication-results: McAfee.com; dkim=none (message not signed) header.d=none;McAfee.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [136.56.55.90] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b141cfb9-f63f-43c0-148f-08d7eb7b89ad x-ms-traffictypediagnostic: BN6PR11MB1505: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0387D64A71 x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN6PR11MB4068.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(376002)(346002)(366004)(39860400002)(396003)(136003)(91956017)(76116006)(5660300002)(110136005)(66946007)(66556008)(54906003)(64756008)(316002)(66476007)(66446008)(2616005)(2906002)(33656002)(6486002)(26005)(36756003)(8676002)(186003)(8936002)(6506007)(4326008)(81156014)(71200400001)(6512007)(86362001)(53546011)(966005)(6636002)(478600001); DIR:OUT; SFP:1101; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: FAcLobk7OpAyThJI/dVpiuUwYpZfliZ1B77AZ3neRuHZk5HESF4j/V0T82PUnve2qYS/x2BXYcPwk/NJg/uDJQrdV/Nvor3jbnsewhcyDACIKVpAahba+Px35ZmE9rQgnY/zLKKPK96F2jtxV60K/XZ7q9+lWGNIfz8EtV2bQSgeVBSdgHmQ2lksv1yyo/NZ20GS9c4k2N3KZIUH2NQYd3GgE6x+iviEoJAZRWa2z8UiM9/9d0iGYLF5Z+qbt6twajwbW2tI8SfLTY7ypPmk8B/l+eTjwSKqXjfaxAje3wbO5qtOACtshLNidybqkwa3h6+sW35kmxol2ylfe2K4zj8WUFWt0HuR+YtkudqdPYML2vcq0JZht4qd8iajgMBmYNZOEoclgp42L2Ul5RlJAozD8H0tDFLhExl9yXhSsDMychZQL59hePlcf8vpI43gWUIfzNyi51MPPLNkUd7ZfhehZ/7dOKf/NTx4eGCPulTGt0RseVfVGskbvdCBlWMgBT7Go/TdzLITSf6ROg+kJw== x-ms-exchange-antispam-messagedata: dA6RL5Ybl0S3asm+Fq2itZUAoILtPrz1ZshYvMsQLF+O1gO+kzHIqIeaKx45l1PPyqGGEItoohTvtiykZ8mzfsSZghhCS6iNOjjhjEfp1af5EZRuWsKef5uGYC7IIjU8qEbCYJnwYweRfQ9oGEOlVv8KOprEXwxTK52yZpefeytk7YfopRd2kOVKINsLve07vk7bOKbqTtRc4z9htXpvNoLwxmfAj02WwvoJAb1lurvEThFi1e9KEa4Yogn9d9ZsueUE84PAJ/Y6TzOne6Fn63eJEIyI8OFvfyj1Qt8aomulnnPTqz5KFju5QyEuPpE1uBNTHVzfEtuTwavbhidcPM3hltZP4iFbbH7ohbSj+VMt7WT33pf4034QMIf5zI2TFv7P48NBgPSH9/7xrLIfFz4+ClmogzCuoPCSBffYvn7xmpXr5eTDaIwaq4nimWX1BJ2tj3vGD3yyQjE5Y1FSrY3d1HmX+A2kn+M2RR/VUznxSss1eI30OwR6PD5ihB4tjF77tTDkQq2GcOTRKYJqXRGJK6yaMQ8IFZkzTEpcSpc6EyNvlwyPAo1smgqSsTIj31+684HaX8GSg5EGpPiMC8FMX9ZjIjLcCXFfCeA9OBAPKu1ApVHivUJi/Xe+srjKMg24VcP2u9YB8hsUnRN++99IXuUHsxQkpBHEakxd74q50NdIIEB14D+qddGKQTURZbiKKHLTTTgBrYwEI53jF3BkzH/ap7hsE2rHOYWFbrAKwSnWL9XtZfYCLB/72dXkCUbafaOBgpRuV9aWakzcXDuB3JYLnEyHiQuN+IX1tWE= Content-Type: text/plain; charset="utf-8" Content-ID: <8C6F6C242A238741A995F2DAA261FDCB@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: b141cfb9-f63f-43c0-148f-08d7eb7b89ad X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Apr 2020 13:53:31.8701 (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-CrossTenant-userprincipalname: YGkzuOSNlgDWkFTOsYKeDp1SiysO1M6CV7n9H7i0yUE70w7EgFwLJi8O8Ptoi3ojQsuYWAetP5DIQ1IZAslplg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR11MB1505 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.13, xch-rcd-003.cisco.com X-Outbound-Node: rcdn-core-7.cisco.com Archived-At: Subject: Re: [secdir] [sfc] Secdir last call review of draft-ietf-sfc-oam-framework 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, 28 Apr 2020 13:53:44 -0000 SEkgVGlydSwNCg0KVGhhbmsgeW91LiBXZSB3aWxsIHN1Ym1pdCB0aGUgdXBkYXRlZCB2ZXJzaW9u IGJ5IEVPQiB0b2RheS4NCg0KVGhhbmtzLA0KTmFnZW5kcmENCg0K77u/T24gNC8yOC8yMCwgMToy NiBBTSwgIktvbmRhLCBUaXJ1bWFsZXN3YXIgUmVkZHkiIDxUaXJ1bWFsZXN3YXJSZWRkeV9Lb25k YUBNY0FmZWUuY29tPiB3cm90ZToNCg0KICAgIEhpIE5hZ2VuZHJhLA0KICAgIA0KICAgIFlvdSBt YXkgd2FudCB0byB1cGRhdGUgdGhlIGZvbGxvd2luZyBsaW5lOg0KICAgIA0KICAgIE9MRDoNCiAg ICBUbyBhZGRyZXNzIHRoZSBhYm92ZSBjb25jZXJucywgU0ZDIGFuZCBTRiBPQU0gc2hvdWxkIHBy b3ZpZGUgbWVjaGFuaXNtcyBmb3I6IA0KICAgIE5FVzoNCiAgICBUbyBhZGRyZXNzIHRoZSBhYm92 ZSBjb25jZXJucywgU0ZDIGFuZCBTRiBPQU0gc2hvdWxkIHByb3ZpZGUgbWVjaGFuaXNtcyBmb3Ig cHJldmVudGluZzoNCiAgICANCiAgICBSZXN0IG9mIHRoZSBjaGFuZ2VzIGxvb2sgZ29vZC4NCiAg ICANCiAgICBDaGVlcnMsDQogICAgLVRpcnUNCiAgICANCiAgICA+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQogICAgPiBGcm9tOiBOYWdlbmRyYSBLdW1hciBOYWluYXIgKG5haWt1bWFyKSA8 bmFpa3VtYXJAY2lzY28uY29tPg0KICAgID4gU2VudDogTW9uZGF5LCBBcHJpbCAyNywgMjAyMCA4 OjA2IFBNDQogICAgPiBUbzogS29uZGEsIFRpcnVtYWxlc3dhciBSZWRkeQ0KICAgID4gPFRpcnVt YWxlc3dhclJlZGR5X0tvbmRhQE1jQWZlZS5jb20+OyBDYXJsb3MgUGlnbmF0YXJvIChjcGlnbmF0 YSkNCiAgICA+IDxjcGlnbmF0YUBjaXNjby5jb20+DQogICAgPiBDYzogc2VjZGlyQGlldGYub3Jn OyBkcmFmdC1pZXRmLXNmYy1vYW0tZnJhbWV3b3JrQGlldGYub3JnDQogICAgPiBTdWJqZWN0OiBS ZTogW3NmY10gU2VjZGlyIGxhc3QgY2FsbCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1zZmMtb2FtLWZy YW1ld29yaw0KICAgID4gDQogICAgPiBDQVVUSU9OOiBFeHRlcm5hbCBlbWFpbC4gRG8gbm90IGNs aWNrIGxpbmtzIG9yIG9wZW4gYXR0YWNobWVudHMgdW5sZXNzIHlvdQ0KICAgID4gcmVjb2duaXpl IHRoZSBzZW5kZXIgYW5kIGtub3cgdGhlIGNvbnRlbnQgaXMgc2FmZS4NCiAgICA+IA0KICAgID4g SGkgVGlydW1hbGVzd2FyLA0KICAgID4gDQogICAgPiBIb3BlIHlvdSBhcmUgZG9pbmcgZ29vZC4N CiAgICA+IA0KICAgID4gVGhhbmsgeW91IGZvciB0aGUgcmV2aWV3IGFuZCB0aGUgY29tbWVudHMv c3VnZ2VzdGlvbnMuIFBsZWFzZSBmaW5kIHRoZQ0KICAgID4gZGlmZiBhdHRhY2hlZCB0aGF0IGlu Y29ycG9yYXRlcyB0aGUgY29tbWVudHMuDQogICAgPiANCiAgICA+IFdlIHdpbGwgc3VibWl0IHRo ZSBuZXcgdmVyc2lvbiB3aXRoIHRoZSBjaGFuZ2VzLiBMZXQgdXMga25vdyBpZiB5b3UgaGF2ZQ0K ICAgID4gYW55IGZ1cnRoZXIgY29tbWVudHMuDQogICAgPiANCiAgICA+IFRoYW5rcywNCiAgICA+ IE5hZ2VuZHJhDQogICAgPiANCiAgICA+IE9uIDQvMjYvMjAsIDM6MjQgQU0sICJzZmMgb24gYmVo YWxmIG9mIEtvbmRhLCBUaXJ1bWFsZXN3YXIgUmVkZHkiIDxzZmMtDQogICAgPiBib3VuY2VzQGll dGYub3JnIG9uIGJlaGFsZiBvZiBUaXJ1bWFsZXN3YXJSZWRkeV9Lb25kYUBNY0FmZWUuY29tPg0K ICAgID4gd3JvdGU6DQogICAgPiANCiAgICA+ICAgICBIaSBDYXJsb3MsDQogICAgPiANCiAgICA+ ICAgICBQbGVhc2Ugc2VlIGlubGluZQ0KICAgID4gDQogICAgPiAgICAgPiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KICAgID4gICAgID4gRnJvbTogQ2FybG9zIFBpZ25hdGFybyAoY3BpZ25h dGEpIDxjcGlnbmF0YUBjaXNjby5jb20+DQogICAgPiAgICAgPiBTZW50OiBTYXR1cmRheSwgQXBy aWwgMjUsIDIwMjAgOToyOSBBTQ0KICAgID4gICAgID4gVG86IEtvbmRhLCBUaXJ1bWFsZXN3YXIg UmVkZHkNCiAgICA+IDxUaXJ1bWFsZXN3YXJSZWRkeV9Lb25kYUBNY0FmZWUuY29tPg0KICAgID4g ICAgID4gQ2M6IHNlY2RpckBpZXRmLm9yZzsgc2ZjQGlldGYub3JnOyBkcmFmdC1pZXRmLXNmYy1p b2FtLW5zaC5hbGxAaWV0Zi5vcmcNCiAgICA+ICAgICA+IFN1YmplY3Q6IFJlOiBbc2ZjXSBTZWNk aXIgbGFzdCBjYWxsIHJldmlldyBvZiBkcmFmdC1pZXRmLXNmYy1vYW0tZnJhbWV3b3JrDQogICAg PiAgICAgPg0KICAgID4gICAgID4gQ0FVVElPTjogRXh0ZXJuYWwgZW1haWwuIERvIG5vdCBjbGlj ayBsaW5rcyBvciBvcGVuIGF0dGFjaG1lbnRzIHVubGVzcw0KICAgID4geW91DQogICAgPiAgICAg PiByZWNvZ25pemUgdGhlIHNlbmRlciBhbmQga25vdyB0aGUgY29udGVudCBpcyBzYWZlLg0KICAg ID4gICAgID4NCiAgICA+ICAgICA+IEhpLCBUaXJ1LA0KICAgID4gICAgID4NCiAgICA+ICAgICA+ IE1hbnkgdGhhbmtzIGZvciB0aGUgcmV2aWV3LCBhbmQgZ3JlYXQgdG8gaGVhciBmcm9tIHlvdSEN CiAgICA+ICAgICA+DQogICAgPiAgICAgPiBJIGhvcGUgYWxsIGlzIHdlbGwg4oCUIFBsZWFzZSBz ZWUgaW5saW5lLg0KICAgID4gDQogICAgPiAgICAgVGhhbmtzLCBJ4oCZbSBmaW5lLCBhbmQgSSBo b3BlIGFsbCBpcyB3ZWxsIHdpdGggeW91IHRvby4NCiAgICA+IA0KICAgID4gICAgID4NCiAgICA+ ICAgICA+ID4gMjAyMC8wNC8yMCDljYjliY0zOjI444CBS29uZGEsIFRpcnVtYWxlc3dhciBSZWRk eQ0KICAgID4gICAgID4gPFRpcnVtYWxlc3dhclJlZGR5X0tvbmRhQE1jQWZlZS5jb20+44Gu44Oh 44O844OrOg0KICAgID4gICAgID4gPg0KICAgID4gICAgID4gPiBSZXZpZXdlcjogVGlydW1hbGVz d2FyIFJlZGR5DQogICAgPiAgICAgPiA+IFJldmlldyByZXN1bHQ6IFJlYWR5IHdpdGggaXNzdWVz DQogICAgPiAgICAgPiA+DQogICAgPiAgICAgPiA+DQogICAgPiAgICAgPiA+IEkgcmV2aWV3ZWQg dGhpcyBkb2N1bWVudCBhcyBwYXJ0IG9mIHRoZSBzZWN1cml0eSBkaXJlY3RvcmF0ZSdzIG9uZ29p bmcNCiAgICA+ICAgICA+ID4gZWZmb3J0IHRvIHJldmlldyBhbGwgSUVURiBkb2N1bWVudHMgZW50 ZXJpbmcgdGhlIElFU0cuLiAgVGhlc2UNCiAgICA+IGNvbW1lbnRzDQogICAgPiAgICAgPiBhcmUg ZGlyZWN0ZWQgYXQgdGhlIHNlY3VyaXR5IGFyZWEgZGlyZWN0b3IocykuICBEb2N1bWVudCBlZGl0 b3JzIGFuZCBXRw0KICAgID4gICAgID4gY2hhaXJzIHNob3VsZCB0cmVhdCB0aGVzZSBjb21tZW50 cyBsaWtlIGFueSBvdGhlciBsYXN0IGNhbGwgY29tbWVudHMuDQogICAgPiAgICAgPiA+DQogICAg PiAgICAgPiA+IFRoaXMgZG9jdW1lbnQgcHJvdmlkZXMgYSByZWZlcmVuY2UgZnJhbWV3b3JrIGZv ciBPQU0gZm9yIFNGQy4NCiAgICA+ICAgICA+ID4NCiAgICA+ICAgICA+ID4gQ29tbWVudHM6DQog ICAgPiAgICAgPiA+DQogICAgPiAgICAgPiA+IDEuIFRoZSBkb2N1bWVudCBpbiBTZWN0aW9uIDgg ZGlzY3Vzc2VzIHZhcmlvdXMgYXR0YWNrcyAoaW5jbHVkaW5nIGJvdGgNCiAgICA+ICAgICA+ID4g c2VjdXJpdHkgYW5kIHByaXZhY3kpIGJ1dCBkb2VzIG5vdCBkaXNjdXNzIGFueSBwcm90ZWN0aW9u IG1lY2hhbmlzbXMNCiAgICA+ICAgICA+IG90aGVyIHRoYW4gcHJvcG9zaW5nIHJhdGUtbGltaXRp bmcuICBJdCBpcyBzdWdnZXN0aW5nIGRyYWZ0cyBwcm9wb3NpbmcgdGhlDQogICAgPiBPQU0NCiAg ICA+ICAgICA+IHNvbHV0aW9uIHNob3VsZCBhZGRyZXNzIHRoZSBhdHRhY2tzIGJ1dCBJIGRvbuKA mXQgc2VlIGFueSBzZWN1cml0eQ0KICAgID4gbWVjaGFuaXNtcw0KICAgID4gICAgID4gZGlzY3Vz c2VkIGluIGRyYWZ0LWlldGYtc2ZjLWlvYW0tbnNoIHRvIGFkZHJlc3MgdGhlIGF0dGFja3MuDQog ICAgPiAgICAgPiA+DQogICAgPiAgICAgPg0KICAgID4gICAgID4gU2luY2UgdGhlIGRvY3VtZW50 IGFscmVhZHkgY2xhcmlmaWVzIHRoYXQgaXQgZG9lcyBub3QgZGVmaW5lIHNvbHV0aW9ucywgaXQN CiAgICA+ICAgICA+IGNhbm5vdCBkZWZpbmUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbiBmb3IgdGhv c2Ugc29sdXRpb25zLCBiZXlvbmQgc2F5aW5nDQogICAgPiB0aGF0DQogICAgPiAgICAgPiB0aG9z ZSBzb2x1dGlvbnMgb3VnaHQgdG8gYWRkcmVzcyBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBpbiB0 aG9zZSBhcmVhcy4NCiAgICA+IEFueQ0KICAgID4gICAgID4gc2VjdXJpdHkgbWVhc3VyZXMgbXVz dCBiZSBpbmNsdWRlZCBhbmQgZXhwbGFpbmVkIGluIHRoZSByZXNwZWN0aXZlDQogICAgPiBzb2x1 dGlvbg0KICAgID4gICAgID4gZG9jdW1lbnQuIEkgYmVsaWV2ZSB0aGlzIGNvbW1lbnQgcmVxdWly ZXMgcG90ZW50aWFsbHkgYWN0aW9uIG9uIGRyYWZ0LQ0KICAgID4gaWV0Zi0NCiAgICA+ICAgICA+ IHNmYy1pb2FtLW5zaCBidXQgbm90IG9uIHRoaXMgZHJhZnQuDQogICAgPiANCiAgICA+ICAgICBZ dXAuIEkgc2VlIHRocmVlIHNvbHV0aW9ucyBmcm9tIFNGQyBXRyBhKSBzZmMtaW9hbS1uc2ggYikg aWV0Zi1zZmMtcHJvb2YtDQogICAgPiBvZi10cmFuc2l0IChFeHBlcmltZW50YWwpIGMpIHBlbm5v LXNmYy10cmFjZSAoRXhwaXJlZCkuIHNmYy1pb2FtLW5zaCBpcyB0aGUNCiAgICA+IG9ubHkgY3Vy cmVudCBzdGFuZGFyZHMgdHJhY2sgc3BlY2lmaWNhdGlvbiBhbmQgaXQgc2hvdWxkIGFkZHJlc3Mg dGhlc2UgYXR0YWNrcy4NCiAgICA+IA0KICAgID4gICAgID4NCiAgICA+ICAgICA+IFRoYXQgc2Fp ZCB5b3UgYXJlIHJpZ2h0IHJlZ2FyZGluZyB0aGUgc3BlY2lmaWNzIG9mIHRoZSByYXRlLWxpbWlu Zw0KICAgID4gICAgID4gcmVjb21tZW5kYXRpb24uIFNlZSB0aGUgbmV4dCBhbnN3ZXIgZm9yIHRl eHQuDQogICAgPiAgICAgPg0KICAgID4gICAgID4gQWxzbywgaW4gcmUtcmVhZGluZyBTZWN0aW9u IDgsIHNlZW1zIGxpa2UgdGhpczoNCiAgICA+ICAgICA+DQogICAgPiAgICAgPiAgICBUbyBhZGRy ZXNzIHRoZSBhYm92ZSBjb25jZXJucywgU0ZDIGFuZCBTRiBPQU0gbWF5IHByb3ZpZGUNCiAgICA+ IG1lY2hhbmlzbQ0KICAgID4gICAgID4gICAgZm9yOg0KICAgID4gICAgID4NCiAgICA+ICAgICA+ DQogICAgPiAgICAgPiBTaG91bGQgc2F5DQogICAgPiAgICAgPg0KICAgID4gICAgID4gICAgVG8g YWRkcmVzcyB0aGUgYWJvdmUgY29uY2VybnMsIFNGQyBhbmQgU0YgT0FNIHNob3VsZCBwcm92aWRl DQogICAgPiAgICAgPiBtZWNoYW5pc21zDQogICAgPiAgICAgPiAgICBmb3IgcHJldmVudGluZzoN CiAgICA+IA0KICAgID4gICAgIFllcy4NCiAgICA+IA0KICAgID4gICAgID4NCiAgICA+ICAgICA+ DQogICAgPiAgICAgPg0KICAgID4gICAgID4gPiAyLiBNb3JlIGRpc2N1c3Npb24gaXMgcmVxdWly ZWQgb24gdGhlIGludGVybmFsIGF0dGFja3MuDQogICAgPiAgICAgPiA+IChhKSBIb3cgYXJlIGF0 dGFjayBwYWNrZXRzIGJ5cGFzc2luZyBTRkMgZGV0ZWN0ZWQgYW5kIGJsb2NrZWQgPw0KICAgID4g ICAgID4gPiAoYikgSG93IGlzIHNlbnNpdGl2ZSBpbmZvcm1hdGlvbiBwcm90ZWN0ZWQgZnJvbSBl YXZlc2Ryb3BwZXJzID8NCiAgICA+ICAgICA+ID4gKGMpIEhvdyBpcyBEb1MvRERvUyBhdHRhY2sg b2YgbWlzdXNpbmcgdGhlIE9BTSBjaGFubmVsIGlzIG1pdGlnYXRlZCA/DQogICAgPiAgICAgPiA+ IChkKSBSYXRlLWxpbWl0aW5nIGJsb2NrcyBib3RoIGdvb2QgYW5kIGJhZCBPQU0gcHJvYmVzIGFu ZCBpcyBhIHdlYWsNCiAgICA+ICAgICA+IG1pdGlnYXRpb24gc3RyYXRlZ3kuIEFub21hbHkgZGV0 ZWN0aW9uIChlLmcuLCBkZWVwIGxlYXJuaW5nIHRlY2hpbnF1ZXMpDQogICAgPiBhbmQNCiAgICA+ ICAgICA+IGlkZW50aWZ5aW5nIHRoZSBhdHRhY2tlciBsb29rIGxpa2UgYSBiZXR0ZXIgc3RyYXRl Z3kuDQogICAgPiAgICAgPiA+DQogICAgPiAgICAgPg0KICAgID4gICAgID4NCiAgICA+ICAgICA+ IFRoaXMgaXMgYSBnb29kIHBvaW50LiBIb3cgYWJvdXQuDQogICAgPiAgICAgPg0KICAgID4gICAg ID4gT0xEOg0KICAgID4gICAgID4NCiAgICA+ICAgICA+ICAgIFRoZSBkb2N1bWVudHMgcHJvcG9z aW5nIHRoZSBPQU0gc29sdXRpb24gZm9yIFNGIGNvbXBvbmVudCBzaG91bGQNCiAgICA+ICAgICA+ ICAgIGNvbnNpZGVyIHJhdGUtbGltaXRpbmcgdGhlIE9BTSBwcm9iZXMgYXQgYSBmcmVxdWVuY3kg Z3VpZGVkIGJ5IHRoZQ0KICAgID4gICAgID4gICAgaW1wbGVtZW50YXRpb24gY2hvaWNlLiAgUmF0 ZS1saW1pdGluZyBtYXkgYmUgYXBwbGllZCBhdCB0aGUgU0ZGIG9yDQogICAgPiAgICAgPiAgICB0 aGUgU0YgLiBUaGUgT0FNIGluaXRpYXRvciBtYXkgbm90IHJlY2VpdmUgYSByZXNwb25zZSBmb3Ig dGhlIHByb2Jlcw0KICAgID4gICAgID4gICAgdGhhdCBhcmUgcmF0ZS1saW1pdGVkIHJlc3VsdGlu ZyBpbiBmYWxzZSBuZWdhdGl2ZXMgYW5kIHRoZQ0KICAgID4gICAgID4gICAgaW1wbGVtZW50YXRp b24gc2hvdWxkIGJlIGF3YXJlIG9mIHRoaXMuDQogICAgPiAgICAgPg0KICAgID4gICAgID4NCiAg ICA+ICAgICA+IE5FVzoNCiAgICA+ICAgICA+DQogICAgPiAgICAgPg0KICAgID4gICAgID4gICAg VGhlIGRvY3VtZW50cyBwcm9wb3NpbmcgdGhlIE9BTSBzb2x1dGlvbiBmb3IgU0YgY29tcG9uZW50 IHNob3VsZA0KICAgID4gICAgID4gICAgY29uc2lkZXIgcmF0ZS1saW1pdGluZyB0aGUgT0FNIHBy b2JlcyBhdCBhIGZyZXF1ZW5jeSBndWlkZWQgYnkgdGhlDQogICAgPiAgICAgPiAgICBpbXBsZW1l bnRhdGlvbiBjaG9pY2UuICBSYXRlLWxpbWl0aW5nIG1heSBiZSBhcHBsaWVkIGF0IHRoZSBTRkYg b3INCiAgICA+ICAgICA+ICAgIHRoZSBTRi4gIFRoZSBPQU0gaW5pdGlhdG9yIG1heSBub3QgcmVj ZWl2ZSBhIHJlc3BvbnNlIGZvciB0aGUgcHJvYmVzDQogICAgPiAgICAgPiAgICB0aGF0IGFyZSBy YXRlLWxpbWl0ZWQgcmVzdWx0aW5nIGluIGZhbHNlIG5lZ2F0aXZlcyBhbmQgdGhlDQogICAgPiAg ICAgPiAgICBpbXBsZW1lbnRhdGlvbiBzaG91bGQgYmUgYXdhcmUgb2YgdGhpcy4gVG8gbWl0aWdh dGUgYW55IGF0dGFja3MgdGhhdA0KICAgID4gICAgID4gICAgTGV2ZXJhZ2UgT0FNIHBhY2tldHMs IGZ1dHVyZSBkb2N1bWVudHMgcHJvcG9zaW5nIE9BTSBzb2x1dGlvbnMNCiAgICA+ICAgICA+ICAg IHNob3VsZCBkZXNjcmliZSB0aGUgdXNlIG9mIGFueSB0ZWNobmlxdWVzIHRvIGRldGVjdA0KICAg ID4gICAgID4gICAgYW5kIG1pdGlnYXRlIGFub21hbGllcyBhbmQgdmFyaW91cyBzZWN1cml0eSAg YXR0YWNrcy4NCiAgICA+IA0KICAgID4gICAgIFdvcmtzIGZvciBtZS4NCiAgICA+IA0KICAgID4g ICAgIENoZWVycywNCiAgICA+ICAgICAtVGlydQ0KICAgID4gDQogICAgPiAgICAgPg0KICAgID4g ICAgID4NCiAgICA+ICAgICA+IFdvdWxkIHRoYXQgd29yaz8NCiAgICA+ICAgICA+DQogICAgPiAg ICAgPiBQbGVhc2UgZmVlbCBmcmVlIHRvIHN1Z2dlc3QgdGV4dHVhbCBpbXByb3ZlbWVudHMgb3Ig Y2hhbmdlcy4NCiAgICA+ICAgICA+DQogICAgPiAgICAgPiBUaGFua3MsDQogICAgPiAgICAgPg0K ICAgID4gICAgID4gQ2FybG9zLg0KICAgID4gICAgID4NCiAgICA+ICAgICA+ID4gQ2hlZXJzLA0K ICAgID4gICAgID4gPiAtVGlydQ0KICAgID4gICAgID4gPiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgID4gICAgID4gPiBzZmMgbWFpbGluZyBsaXN0 DQogICAgPiAgICAgPiA+IHNmY0BpZXRmLm9yZw0KICAgID4gICAgID4gPiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KICAgID4gDQogICAgPiAgICAgX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICA+ICAgICBzZmMgbWFp bGluZyBsaXN0DQogICAgPiAgICAgc2ZjQGlldGYub3JnDQogICAgPiAgICAgaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCiAgICA+IA0KICAgIA0KICAgIA0KDQo= From nobody Thu Apr 30 05:05:19 2020 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 B06273A005B for ; Thu, 30 Apr 2020 05:05:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Tero Kivinen via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 6.128.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu, Tero Kivinen Message-ID: <158824831669.17008.18231757856167417119@ietfa.amsl.com> Date: Thu, 30 Apr 2020 05:05:16 -0700 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, 30 Apr 2020 12:05:17 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2020-05-21 Reviewer LC end Draft Donald Eastlake R2019-11-14 draft-ietf-hip-dex-18 Last calls: Reviewer LC end Draft John Bradley 2020-02-28 draft-ietf-regext-data-escrow-08 Alan DeKok 2019-06-04 draft-ietf-netvc-testing-09 Donald Eastlake 2020-02-27 draft-ietf-6tisch-msf-16 Donald Eastlake R2019-11-14 draft-ietf-hip-dex-18 Daniel Franke 2020-03-09 draft-ietf-regext-dnrd-objects-mapping-07 Aanchal Malhotra 2020-03-12 draft-ietf-bess-vpls-multihoming-05 Russ Mundy 2020-01-02 draft-ietf-dprive-bcp-op-08 Magnus Nystrom 2019-04-10 draft-ietf-avtcore-multiplex-guidelines-11 Vincent Roca 2020-04-23 draft-ietf-detnet-ip-over-mpls-05 Joseph Salowey 2020-05-05 draft-ietf-ospf-mpls-elc-13 Rich Salz 2020-05-05 draft-ietf-isis-mpls-elc-12 Stefan Santesson 2020-05-04 draft-ietf-httpbis-header-structure-18 Yaron Sheffer None draft-ietf-opsawg-tacacs-yang-03 Rifaat Shekh-Yusef 2020-05-13 draft-ietf-capport-rfc7710bis-04 Melinda Shore 2020-05-13 draft-ietf-secevent-http-poll-09 Valery Smyslov 2020-05-13 draft-ietf-secevent-http-push-10 Robert Sparks 2020-05-11 draft-ietf-capport-api-07 Tina Tsou 2020-05-08 draft-ietf-httpbis-client-hints-13 Sean Turner 2020-05-06 draft-ietf-opsawg-sdi-02 Dacheng Zhang 2020-03-12 draft-nottingham-how-did-that-get-into-the-repo-01 Dacheng Zhang 2019-11-05 draft-ietf-mpls-ri-rsvp-frr-07 Next in the reviewer rotation: Sean Turner Mališa Vučinić Carl Wallace Samuel Weiler Brian Weis Klaas Wierenga Christopher Wood Paul Wouters Liang Xia Dacheng Zhang From nobody Thu Apr 30 08:00:27 2020 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 8169A3A0B25; Thu, 30 Apr 2020 08:00:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Robert Sparks via Datatracker To: Cc: draft-ietf-capport-api.all@ietf.org, captive-portals@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.128.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158825881446.11261.3022047238117789821@ietfa.amsl.com> Reply-To: Robert Sparks Date: Thu, 30 Apr 2020 08:00:14 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-capport-api-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: Thu, 30 Apr 2020 15:00:20 -0000 Reviewer: Robert Sparks 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 is ready for publication as Proposed Standard RFC. The document defines an HTTP json-based API for clients to use with a captive portal API server. Discovery of the API server URL is defined in other capport documents. Connection to the server uses TLS. Server authentication SHOULD use OCSP stapling, and the network SHOULD provide permit connection to NTP servers (or other time-sync mechanisms). The security considerations section calls out the potential risk of look-alike characters being used in the server domain name to mislead the user of the client of this API. From nobody Thu Apr 30 08:41:10 2020 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 06F043A0CDF; Thu, 30 Apr 2020 08:40:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.218 X-Spam-Level: X-Spam-Status: No, score=-2.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_MSPIKE_H2=-0.82, SPF_HELO_NONE=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 ZfJfTVvVA4hl; Thu, 30 Apr 2020 08:40:38 -0700 (PDT) Received: from mail-io1-f41.google.com (mail-io1-f41.google.com [209.85.166.41]) (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 9107D3A0B14; Thu, 30 Apr 2020 08:39:47 -0700 (PDT) Received: by mail-io1-f41.google.com with SMTP id y26so1944944ioj.2; Thu, 30 Apr 2020 08:39:47 -0700 (PDT) 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=4ZPn8oZxRek3r3eFYswS8goQLxk7/Ikc4DUUG3AF61M=; b=RbMorXGeQrU5rIt9bi6QxYTV+os6lQkWDMRzurNzaKNM1IhaLB/77OeGF5ZtKzWWxY wjRlrukASFTRIJF73F6/RZE8Raw1UmKb1r6OgbVdrmRs+vzLyGF1mUCE8lET4ulTmWco hjyllIeyD9eKLuEAkTDBXzgWcLjJm635O2B/KnENvcHhyzYu3q4fwoyla3VLSjRHWJx0 BatKVdVR2blsW5iR15MX7Dds1DtUxIrOIJW1SvGCE9IebBhyaNDzsXmkv3dbNZXnqkTD QBfE5iAP/TjMvzIk7+Rqj1qKsC54ul33GRnfdKbhvpLXdPy424mSxACEcmArYkrFET4A IUiQ== X-Gm-Message-State: AGi0PubNZ+ZMVyCO8tZZmxNjksKvCEl6HGPNATBflImy9sSJd9q1W1x6 jGSz6omeJ38Pyb8UdToEgFpWAdUNRN216quVfAhAnXCl X-Google-Smtp-Source: APiQypIvkwWZsuMah0vY30MVbV99KxoiH2h09C1BQt/UIGgrcqQoi5P6MiQYOnNks3ispvsq+mOayc6FtIj6l7g8HMM= X-Received: by 2002:a5e:8613:: with SMTP id z19mr2430811ioj.84.1588261186591; Thu, 30 Apr 2020 08:39:46 -0700 (PDT) MIME-Version: 1.0 References: <158825881446.11261.3022047238117789821@ietfa.amsl.com> In-Reply-To: <158825881446.11261.3022047238117789821@ietfa.amsl.com> From: Barry Leiba Date: Thu, 30 Apr 2020 11:39:35 -0400 Message-ID: To: Robert Sparks Cc: IETF SecDir , draft-ietf-capport-api.all@ietf.org, captive-portals@ietf.org, last-call@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-capport-api-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, 30 Apr 2020 15:40:46 -0000 Thanks for the review, Robert. Barry On Thu, Apr 30, 2020 at 11:00 AM Robert Sparks via Datatracker wrote: > > Reviewer: Robert Sparks > 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 is ready for publication as Proposed Standard RFC. > > The document defines an HTTP json-based API for clients to use with a captive > portal API server. Discovery of the API server URL is defined in other capport > documents. Connection to the server uses TLS. Server authentication SHOULD use > OCSP stapling, and the network SHOULD provide permit connection to NTP servers > (or other time-sync mechanisms). The security considerations section calls out > the potential risk of look-alike characters being used in the server domain > name to mislead the user of the client of this API. > > > From nobody Thu Apr 30 11:07:01 2020 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 444C23A0E40; Thu, 30 Apr 2020 11:06:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Rich Salz via Datatracker To: Cc: last-call@ietf.org, lsr@ietf.org, draft-ietf-isis-mpls-elc.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.128.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158826997723.18783.269920443288910887@ietfa.amsl.com> Reply-To: Rich Salz Date: Thu, 30 Apr 2020 11:06:17 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-isis-mpls-elc-12 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, 30 Apr 2020 18:06:18 -0000 Reviewer: Rich Salz Review result: Ready I am the SECDIR reviewer for this document; the security directorate tries to review all documents before they go to the IESG. This content is intended primarily for the SecAD's, anyone else should consider this like other last-call comments. This document is READY. This is a short doument. It defines a way for MPLS routers to indicate that they can handle additional meta-data, "entropy labels" and depth of them, to do traffic routing. The security implications of this are well-discussed. From nobody Thu Apr 30 21:58:07 2020 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 7335D3A05A4; Thu, 30 Apr 2020 21:57:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Joseph Salowey via Datatracker To: Cc: last-call@ietf.org, lsr@ietf.org, draft-ietf-ospf-mpls-elc.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.128.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158830906041.22803.13800308434788640436@ietfa.amsl.com> Reply-To: Joseph Salowey Date: Thu, 30 Apr 2020 21:57:40 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-ospf-mpls-elc-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: Fri, 01 May 2020 04:57:47 -0000 Reviewer: Joseph Salowey 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 from a security perspective. The security considerations section is adequate.