From nobody Mon Aug 2 06:40:36 2021 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F01423A1E9F for ; Mon, 2 Aug 2021 06:40:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=fugue-com.20150623.gappssmtp.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 m0zNYEfeVPcv for ; Mon, 2 Aug 2021 06:40:28 -0700 (PDT) Received: from mail-ot1-x32b.google.com (mail-ot1-x32b.google.com [IPv6:2607:f8b0:4864:20::32b]) (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 465FD3A1E9D for ; Mon, 2 Aug 2021 06:40:28 -0700 (PDT) Received: by mail-ot1-x32b.google.com with SMTP id 68-20020a9d0f4a0000b02904b1f1d7c5f4so17487750ott.9 for ; Mon, 02 Aug 2021 06:40:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:in-reply-to:references:date:message-id:subject:to :cc; bh=lBjPsoGZSMLB1Fwp/9dQ7mhhdSw2x9JSYDHxxv9lqO4=; b=lXeyzar+kU3qJx5L5ZFHqPHcCEnkL64jnlLfIa9Sagopr5ehhX44H5i1JR8vQclX2P aeuCX4Ku4RqpnUplgIccYTA4e/rYWtslA06ZJDqV4PcBtXy/CeJMCcSEWVUoTabI53Ko 2pb4rgo9kmymiE71duoxfz1ftgSGLPiSFvvb1axKPgt3YVj6XcpCcrUL4YFbEQntKem9 2DvGMm1Jx9JDxSpluDvQB7UH8+POUiJ99N6xUaJ9Iz7J1az3WamNHn/NZyveGcYLfSC2 Z0+K6PaBN1eb2+V0wLmBXOZKquU7cEbO1CAFYGaHx74CN5OxqRG7eVy1UmM+RGfDHXTE 93rA== 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:in-reply-to:references:date :message-id:subject:to:cc; bh=lBjPsoGZSMLB1Fwp/9dQ7mhhdSw2x9JSYDHxxv9lqO4=; b=AiAeungKagNJNFbQ1MthWIkfEFaRnpC9mwny0LKl/kjuhtma6BVCTOUQiqIaYU5/hH RKhN8ZCFeiESnHxW9YMqgiImGXniO7Lc/7KWUusQwWn7ZowpmX9g/3xjPF2vw2eo0VhH 7K4lSP2sxSMF1QQZVyazbang3P3naTXQ5b7JxA562SNzXOPJ6C1AT+QRaEYXsi6aed7p TrY4qVBRkBup++OZ/LrcEFkyheACbx/OfsOzR3XLgJM/p0/hGicOGHq3NL6DMmIftwCc Wipl9nmX1UDmlHSfmtCLS20Xz647PtSEgPiFwZnJfKKm4KQY8sJM2guSvbblxT33uNRc AEKw== X-Gm-Message-State: AOAM532RrhOxr3BobcMzmKHTBOajE2D9TEr3tFXfC+UuBeG8MCfyUZE1 xOia3mQIIEZzDoWAXGo6hVTCUjrW3HowU9pakdxW2w== X-Google-Smtp-Source: ABdhPJw1BWj70nD1rZi08qc/kuTzkMZCx9IOFbyfp2CY6gJ9xyKis7LDtMX1pFYxQNTE2/rMPmMc9JBmXdeTT10wJGc= X-Received: by 2002:a9d:d53:: with SMTP id 77mr11960943oti.18.1627911625975; Mon, 02 Aug 2021 06:40:25 -0700 (PDT) Received: from 649336022844 named unknown by gmailapi.google.com with HTTPREST; Mon, 2 Aug 2021 06:40:25 -0700 Mime-Version: 1.0 X-Mailer: Superhuman Desktop (2021-07-30T22:05:55Z) X-Superhuman-ID: kruojcqd.9abd8b61-8afa-4e58-afca-0ab6d20ee98c From: Ted Lemon X-Superhuman-Draft-ID: draft002a42d239535aa4 In-Reply-To: References: Date: Mon, 2 Aug 2021 06:40:25 -0700 Message-ID: To: Chris Box Cc: dnssd Content-Type: multipart/alternative; boundary="00000000000031699a05c893b6ff" Archived-At: Subject: Re: [dnssd] draft-sekar-dns-ul X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2021 13:40:34 -0000 --00000000000031699a05c893b6ff Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for the thorough review, Chris! On Thu, Jul 29, 2021 at 8:04 PM, Chris Box wrote= : > *Questions and comments* > The -01 version of this draft has an associated patent. The IPR disclosur= e > is https://datatracker.ietf.org/ipr/1236/. What does this mean for -03? > The IPR has been around since <2009, so I'd say it's there to stay. You can look at the IPR declaration for Apple's position on what to do if it gets used in an RFC. Before I worked at Apple, I would have considered this declaration Mostly Harmless, but since I'm now working at Apple, I think it doesn't make sense to count my opinion since I'm not disinterested, so the WG needs to make that call. In Section 4, it strikes me as odd that KEY RRtype is treated specially > here. I know why, because that's what SRP needs. But in the context of th= is > single draft, is there a rationale as to why KEY, and only KEY, needs a > different lease time? > The reason for the KEY having a different lease time is so that the domain name can be claimed without being usable for service discovery. When the other records expire, the KEY remains to hold the name until it expires, so if the host renews before then, no other host can claim the name. We could do this for some other record, but the KEY record has the virtue that it's useful for authentication. It's true that this is currently only used by SRP, though. We could make this apply to more records, but I don't know of a use case for that, and if we come up with one later we can add another EDNS0 option=E2=80=94the number space is not small. Is it worth looking at the draft through the lens of the EDM program? For > example should it be extensible to separate out other RRtypes? Should > greasing come into the picture? The answer might be "not in this case", b= ut > I thought it worth at least thinking about. > I have no idea what this means=E2=80=94can you elaborate? Either section 4 or 5 should be explicit about what the client > MUST/SHOULD/MAY do when the server insists on a different lease period to > the one the client requested. It is not currently clear to me if the serv= er > is always right, or if the client can impose bounds on what is acceptable= . > Good point. I think the server has to be in charge of this, but more text about what that should look like would be good. E.g., in a constrained environment, you might have devices that really only ought to check in every day or even every week, and if the server limits leases to an hour, that's not going to work out well. In Section 5.2, refresh messages are asked to set a prerequisite of "RRSet > exists (value dependent)". I don't have much experience of prerequisites. > It sounds like it creates a risk that in some situations the prerequisite > will be unsatisified, resulting in the failure to refresh and the record > ultimately being deleted on expiry. Is this a genuine risk or am I missin= g > something? > I'll have to discuss this with Stuart. My personal opinion is that less prescriptive text is better, because we don't actually have a use case other than SRP, and SRP already specifies constraints that contradict this. Section 5.3 would benefit from adding a sentence along the lines of "If at > least one record in the Refresh Request has completed at least 50% of its > lease, the server SHOULD refresh all of the records.".This is because > implementors might misinterpret "If no records", as "If any records ", > creating problems with coalescing. > That sounds good. In Section 7, do we need to ask IANA to update the status of Option Code 2 > from on-hold to standard? > Sounds like a good idea. *Editorial suggestions* > > Section 4 > Personally I would drop the part in brackets here: > Leases are expected to be sufficiently long as to make timer discrepancie= s > (due to transmission latency, etc.) between a client and server negligibl= e. > It's probably at least worth mentioning that issue, though. Section 5 > Don't we normally use the spelling "retry" rather than "re-try"? > That's a hyphenation thing, which apparently xml2rfcv3 doesn't support. I think it should be taken out=E2=80=94text is no longer the canonical format= , so hyphenation specifically to support that format probably doesn't add much incremental value. That's all. Overall it's clearly a useful capability, so I would support > eventual publication. > Thanks! On Thu, Jul 29, 2021 at 8:04 PM, Chris Box wrote= : > Ted, > > As promised in the meeting, I've now reviewed the draft. Here's my > thoughts. > > *Questions and comments* > The -01 version of this draft has an associated patent. The IPR disclosur= e > is https://datatracker.ietf.org/ipr/1236/. What does this mean for -03? > > In Section 4, it strikes me as odd that KEY RRtype is treated specially > here. I know why, because that's what SRP needs. But in the context of th= is > single draft, is there a rationale as to why KEY, and only KEY, needs a > different lease time? > > Is it worth looking at the draft through the lens of the EDM program? For > example should it be extensible to separate out other RRtypes? Should > greasing come into the picture? The answer might be "not in this case", b= ut > I thought it worth at least thinking about. > > Either section 4 or 5 should be explicit about what the client > MUST/SHOULD/MAY do when the server insists on a different lease period to > the one the client requested. It is not currently clear to me if the serv= er > is always right, or if the client can impose bounds on what is acceptable= . > > In Section 5.2, refresh messages are asked to set a prerequisite of "RRSe= t > exists (value dependent)". I don't have much experience of prerequisites. > It sounds like it creates a risk that in some situations the prerequisite > will be unsatisified, resulting in the failure to refresh and the record > ultimately being deleted on expiry. Is this a genuine risk or am I missin= g > something? > > Section 5.3 would benefit from adding a sentence along the lines of "If > at least one record in the Refresh Request has completed at least 50% of > its lease, the server SHOULD refresh all of the records.".This is because > implementors might misinterpret "If no records", as "If any records ", > creating problems with coalescing. > > In Section 7, do we need to ask IANA to update the status of Option Code = 2 > from on-hold to standard? > > *Editorial suggestions* > > Section 4 > Personally I would drop the part in brackets here: > Leases are expected to be sufficiently long as to make timer discrepancie= s > (due to transmission latency, etc.) between a client and server negligibl= e. > > Section 5 > Don't we normally use the spelling "retry" rather than "re-try"? > > > That's all. Overall it's clearly a useful capability, so I would support > eventual publication. > > Chris > > On Wed, 28 Jul 2021 at 00:01, Ted Lemon wrote: > > As was discussed in the meeting today, one of the normative references > in the Service Registration Protocol document is to draft-sekar-dns-ul, > which describes the DNS Update Lease option. For those who are challenged > by parsing this, as I tend to be, that's the EDNS0 option for declaring a > lease on a DNS Update. > > There was some question as to whether this was an appropriate document fo= r > the working group, so that's one question. However, whether it is or not, > it would be good if it got some review, and this working group probably h= as > a lot of the most qualified people to look at it. > > So, please take a look at the document and comment here. You can find a > copy of the document here: https://www.ietf.org/archive/id/ > draft-sekar-dns-ul-03.html > > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd > > --00000000000031699a05c893b6ff Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
=
Thanks for the thorough review, Chris!

On Thu, Jul 29, 2021 at 8:04 PM, Chris Box <chris.box.ietf@gmail.com> wrote:
Questions and comments
The -01 version= of this draft has an associated patent. The IPR disclosure is https://datatracker.ietf.org/ipr/1236/. What does this mean= for -03?

The IPR has been around since <2009, so I'd say it'= ;s there to stay. You can look at the IPR declaration for Apple's posit= ion on what to do if it gets used in an RFC. Before I worked at Apple, I wo= uld have considered this declaration Mostly Harmless, but since I'm now= working at Apple, I think it doesn't make sense to count my opinion si= nce I'm not disinterested, so=C2=A0the WG needs to make that call.
<= /div>

<= div class=3D"" dir=3D"ltr">
<= div class=3D"" dir=3D"ltr">
In Section 4, it strikes me as o= dd that KEY RRtype is treated specially here. I know why, because that'= s what SRP needs. But in the context of this single draft, is there a ratio= nale as to why KEY, and only KEY, needs a different lease time?

The rea= son for the KEY having a different lease time is so that the domain name ca= n be claimed without being usable for service discovery. When the other rec= ords expire, the KEY remains to hold the name until it expires, so if the h= ost renews before then, no other host can claim the name. We could do this = for some other record, but the KEY record has the virtue that it's usef= ul for authentication. It's true that this is currently only used by SR= P, though. We could make this apply to more records, but I don't know o= f a use case for that, and if we come up with one later we can add another = EDNS0 option=E2=80=94the number space is not small.

=
<= div class=3D"" dir=3D"ltr">
Is it worth looking at the draft through the lens = of the EDM program? For example should it be extensible to separate out oth= er RRtypes? Should greasing come into the picture? The answer might be &quo= t;not in this case", but I thought it worth at least thinking about.
<= /div>

I have no idea what this means=E2=80=94can you elaborate?
=

<= div class=3D"" dir=3D"ltr">
Either section 4 or 5 should be explicit = about what the client MUST/SHOULD/MAY do when the server insists on a diffe= rent lease period to the one the client requested. It is not currently clea= r to me if the server is always right, or if the client can impose bounds o= n what is acceptable.
=

Good point. I think the server has to be in charg= e of this, but more text about what that should look like would be good. E.= g., in a constrained environment, you might have devices that really only o= ught to check in every day or even every week, and if the server limits lea= ses to an hour, that's not going to work out well.
<= br>
In Section 5.2, refresh m= essages are asked to set a prerequisite of "RRSet exists (value depend= ent)". I don't have much experience of prerequisites. It sounds li= ke it creates a risk that in some situations the prerequisite will be unsat= isified, resulting in the failure to refresh and the record ultimately bein= g deleted on expiry. Is this a genuine risk or am I missing something?
<= /div>

= I'll have to discuss this with Stuart. My personal opinion is that less= prescriptive text is better, because we don't actually have a use case= other than SRP, and SRP already specifies constraints that contradict this= .

=
Section 5.3 would benefit f= rom adding a sentence along the lines of=C2=A0 "If at= least one record in the Refresh Request has completed at least 50% of its = lease, the server SHOULD refresh all of the records.".This is b= ecause implementors might misinterpret "If no records= ", as "If any records=C2=A0",= creating problems with coalescing.
=

That sounds good.

In Section 7, do we need to ask IANA to update= the status of Option Code 2 from on-hold to standard?
<= /div>

Sounds like a go= od idea.

Editorial suggestions

Section 4
Personally I would drop the part in brackets here:
Leases are expected to be sufficiently long as to = make timer discrepancies (due to transmission latency, etc.) between a clie= nt and server negligible.

It's probably at least worth= mentioning that issue, though.

<= div class=3D"" dir=3D"ltr">
<= div class=3D"" dir=3D"ltr">
Section 5
Don't we normally use the spelling "retry" rather than &qu= ot;re-try"?
<= /div>

That's a hyphenation thing, which apparently= xml2rfcv3 doesn't support. I think it should be taken out=E2=80=94text= is no longer the canonical format, so hyphenation specifically to support = that format probably doesn't add much incremental value.
=

=
<= div class=3D"" dir=3D"ltr">
That= 's all. Overall it's clearly a useful capability, so I would suppor= t eventual publication.
=

Thanks!




On Thu, Jul 29= , 2021 at 8:04 PM, Chris Box <chris.box.ietf@gmail.com> wrote:
<= div dir=3D"ltr" class=3D"sh-color-black sh-color">
Ted,

As promised in the meeting, I've now reviewed the draft. Here= 9;s my thoughts.
Questions and comments
The -01 version of this draft has an associated patent. The IPR disclo= sure is https://datatracker.ietf.= org/ipr/1236/. What does this mean for -03?

In Section 4, it strikes me as odd that KEY RRtype is treated spe= cially here. I know why, because that's what SRP needs. But in the cont= ext of this single draft, is there a rationale as to why KEY, and only KEY,= needs a different lease time?
=
Is it worth looking at the= draft through the lens of the EDM program? For example should it be extens= ible to separate out other RRtypes? Should greasing come into the picture? = The answer might be "not in this case", but I thought it worth at= least thinking about.

Either section 4 or 5 = should be explicit about what the client MUST/SHOULD/MAY do when the server= insists on a different lease period to the one the client requested. It is= not currently clear to me if the server is always right, or if the client = can impose bounds on what is acceptable.

In S= ection 5.2, refresh messages are asked to set a prerequisite of "RRSet= exists (value dependent)". I don't have much experience of prereq= uisites. It sounds like it creates a risk that in some situations the prere= quisite will be unsatisified, resulting in the failure to refresh and the r= ecord ultimately being deleted on expiry. Is this a genuine risk or am I mi= ssing something?

S= ection 5.3 would benefit from adding a sentence along the lines of=C2=A0 &q= uot;If at least one reco= rd in the Refresh Request has completed at least 50% of its lease, the serv= er SHOULD refresh all of the records.".This is because implemen= tors might misinterpret "If no records", as "If any records=C2=A0", creating problems with coalescing.

In Section 7, do we need to ask IANA to update the sta= tus of Option Code 2 from on-hold to standard?

Editorial suggestions

Section 4
Personally I would= drop the part in brackets here:
Leases are expected to= be sufficiently long as to make timer discrepancies (due to transmission l= atency, etc.) between a client and server negligible.

Section 5
Don't we = normally use the spelling "retry" rather than "re-try"?=


That= 9;s all. Overall it's clearly a useful capability, so I would support e= ventual publication.

=
Chris
<= /div>

On Wed, 28 Jul 2021 at 00:01, Ted Lemon <mellon@fug= ue.com> wrote:
<= div class=3D"sh-color-black sh-color">
As was discussed in the meeting today<= /span>,=C2=A0 one of the normative references in the Service Registration P= rotocol document is to draft-sekar-dns-ul, which describes the DNS Update L= ease option. For those who are challenged by parsing this, as I tend to be,= that's the EDNS0 option for declaring a lease on a DNS Update.

There was some question as to whether this was an appropriat= e document for the working group, so that's one question. However, whet= her it is or not, it would be good if it got some review, and this working = group probably has a lot of the most qualified people to look at it.

So, please take a look at the document and comment here. Yo= u can find a copy of the document here:=C2=A0https://www.ietf.org/archive/id/<= wbr>draft-sekar-dns-ul-03.html

<= /div>
_______________________________________________
dnssd mailing list
dnssd@ietf.org
https://www.ietf.org/ma= ilman/listinfo/dnssd

--00000000000031699a05c893b6ff-- From nobody Mon Aug 2 11:16:23 2021 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A95803A1406 for ; Mon, 2 Aug 2021 11:16:21 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 ejL6vMN2fdI9 for ; Mon, 2 Aug 2021 11:16:17 -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 1283F3A1405 for ; Mon, 2 Aug 2021 11:16:16 -0700 (PDT) Received: by mail-lj1-x234.google.com with SMTP id m9so25006625ljp.7 for ; Mon, 02 Aug 2021 11:16:16 -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=j3wULy8cv3VqZ34mVvHvKmnfaOEmpepYuwOcGaWZ+YI=; b=SEgbPR0uf98GzbuSlurSbfNcYIP5zHWkR3iDHOBxq7Q6ZQApOmzZYyqjtnvWpxHEru LExgd7CG7bcBJ9xuLZ5UE5TYRT1GV1KZYIrLR4uzU9cjEsZsCMfWODRmE+KSOwCVLcSh AoxFedIY4NHTHPHjFL4khhm4zPeIfUoNdweQc4WN6CDE8/pEnQZDTxX+nYvHXEWrPixa jiU7JLOYVQNQ89Fndj/z79D6OQyUqDif8s3B24WCHCSuPDnZ8A39kb+0WEp5jucNvLC8 As2Hk6IpYyU3w6F7Mx2zN4ZRNnaF0+1xEyxPEUsilLUBy21Cx5GgvqHyiwlOB+PEJIgG FDhw== 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=j3wULy8cv3VqZ34mVvHvKmnfaOEmpepYuwOcGaWZ+YI=; b=mu3Wb6tPafxFpiSdBzJCTEDvCVBjUdYMcMoVcIIjjPpqxIgIfZJXUupEKLzGOUrIVa JkjSec1HlhBBOQeG4clio9Q11mOOGKvbE+Ji0uZRhlXFL4xaipO86dyWbsQYdE86t3SV HOAEUZkH2ppCz8qmRIV6ud4LKdFj0zM2VtSFssBC1N5xmKuUhBykEqPN2HLN44PMZ6TT gQ3ayEsrNAyXWkMvg4mdV0TTvNLn5wrN37ZIJs9o+pN2eUV5+aqnAERIujROz3+U4opE J7yGm5F6BJkMtVSqZmw0DiMDsU4+kjDm/7dIKSwFEi0QY/9HeO9eSCoExzstzfQQo7bT IV4w== X-Gm-Message-State: AOAM532Of4Zq4tI7wzETZe7sBE3JVVRDI08PJIAKEq48agLfRyzoTEnP pt/iExKP0zaTZaUFq3AtRiyPPQPsJ0OnA813nyY= X-Google-Smtp-Source: ABdhPJwZSTm7OH5poCiTaZj3DPmj9syNABgmr8nlFSd9v9sn1KMAFJ+7cfaTq0z/rSJRO0nzGwOkY4YATiMUHj7/r04= X-Received: by 2002:a2e:b610:: with SMTP id r16mr12075403ljn.363.1627928172241; Mon, 02 Aug 2021 11:16:12 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Tim Wicinski Date: Mon, 2 Aug 2021 14:16:01 -0400 Message-ID: To: David Schinazi Cc: DNSSD Content-Type: multipart/alternative; boundary="0000000000006d25c605c8979081" Archived-At: Subject: Re: [dnssd] WGLC for draft-ietf-dnssd-srp X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2021 18:16:22 -0000 --0000000000006d25c605c8979081 Content-Type: text/plain; charset="UTF-8" I've read the document and I think it is ready to be published. My one nit before moving forward is the authors run the nits tool and address the messages about updating references. tim On Wed, Jul 28, 2021 at 5:57 PM David Schinazi wrote: > Hi DNSSD enthusiasts, > > This email starts an official Working Group Last Call > for draft-ietf-dnssd-srp. This call asks whether we believe the document is > ready for publication. As such we are asking two questions: > > 1) if you believe this document is not ready to publish, please speak up > now > > 2) if you have read the document and think it is ready, please say so as > well > > For this call to succeed, we'll need statements of explicit support from > people who have read the draft. Please send statements in either direction > as responses to this email. This call will be open until 2021-08-15 23:59 > UTC. > > Thanks, > David > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd > --0000000000006d25c605c8979081 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I= 've read the document and I think it is ready to be published.

My one nit before mov= ing forward is the authors=C2=A0run the nits tool and address the messages = about=C2=A0updating references.

tim


On Wed, Jul 28, 2021 at 5:57 PM David Schinazi <= dschinazi.ietf@gmail.com>= ; wrote:
Hi DNSSD enthusiasts,

This emai= l starts an official Working Group Last Call for=C2=A0draft-ietf-dnssd-srp.= This call asks whether we believe the document is ready for publication. A= s such we are asking two questions:

1) if you beli= eve this document is not ready to publish, please speak up now
2) if you have read the document and think it is ready, please= say so as well

For this call to succeed, we'l= l need statements of explicit support from people who have read the draft. = Please send statements in either direction as responses to this email. This= call will be open until 2021-08-15 23:59 UTC.

Tha= nks,
David
_______________________________________________
dnssd mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/listinfo/dnssd
--0000000000006d25c605c8979081-- From nobody Wed Aug 4 10:43:01 2021 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBAF13A0D7C for ; Wed, 4 Aug 2021 10:42:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, 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 0q4kjj_oxtB3 for ; Wed, 4 Aug 2021 10:42:53 -0700 (PDT) Received: from mail-qv1-xf30.google.com (mail-qv1-xf30.google.com [IPv6:2607:f8b0:4864:20::f30]) (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 762193A0D7B for ; Wed, 4 Aug 2021 10:42:53 -0700 (PDT) Received: by mail-qv1-xf30.google.com with SMTP id d17so1457968qvn.13 for ; Wed, 04 Aug 2021 10:42:53 -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=hLcNCWUBD167n/AfSe6MoOiE2NqCfBYwxB3SMK8eG24=; b=Dc7BbDhfmSYkBzw24NfOvI+i18USRVC7aHqYOIXCsIaJaYRUccxG5weqf03saipzG4 OjSFVFuicSzp8+5RsW6sJH8TS3hV3F5wjAY/vFJ0WPmEmNNBUzz0s83LNBJtkTZfHrAf QjFHXKK5poTBp39B5UeH6CocjX5OtTjqT5z4zyH0xhgjQBnu/piVbOBjqQxPRoyK/mXs yn5TfjvfJ+Cl1p3fuTKhQflpU8u8ax9EZGFmyq+BLsiT5JirUG2qcgcGC5K1fMG61O9k lGkjNguXJNAGMKVueJqyGsAvZ69bUAXBwYrLEv9QhSETbb3HKGt9TnggiLM1qo9l6lIT Z4og== 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=hLcNCWUBD167n/AfSe6MoOiE2NqCfBYwxB3SMK8eG24=; b=AY/tToy6srClsvtCaaprw1VUiphdxDKA9QlATWgw2znCMJylUpCkXg4e+R6uhCB4w8 O9+UbWgh0oyW5Mksmq3EA9H9mBUXFlP+e5K0hJ5SPdjOFy5Ts8Xjib43fBMiiT3a8cU1 ZHOGkjbeqoET9zm7Tzymj4g8ZBm9dPUDbgGkWhn8CobIrRRGfj5HhvH2n4bJwkIq/U1a lUFBZicCXIgdPlKeErjfNHh8LDHVG7NU8z+DTcTo3WD3AedzWYmpg1UR6dXru/idRqIF M4SHuP9lrtfKf5/8uYzcV0CFX6mgHk5GQsrxVKAq8OvKFx8uRo7p5uj54JybEkTbVHi8 9Cdg== X-Gm-Message-State: AOAM533VtNYBz61XA0RXUh8Pr8wFM5zeDRCqNXtLPVXtz6FrsRvg7mkp gYi6HNdoCEUQ9qWPGr2A2olndIPpoJePjISekNqeQfMlXso= X-Google-Smtp-Source: ABdhPJxT+wGzW1kQwnFoffO2AfnIB3/QTfMWDq/upr01tfWP9DhfOTyzIk9SXp0a11HFaWp9LYYXsocUVemLUiUPs4k= X-Received: by 2002:a0c:ed21:: with SMTP id u1mr588064qvq.6.1628098972126; Wed, 04 Aug 2021 10:42:52 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Chris Box Date: Wed, 4 Aug 2021 18:42:41 +0100 Message-ID: To: Ted Lemon Cc: dnssd Content-Type: multipart/alternative; boundary="000000000000e48f4305c8bf5449" Archived-At: Subject: Re: [dnssd] draft-sekar-dns-ul X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Aug 2021 17:42:59 -0000 --000000000000e48f4305c8bf5449 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Ted, Just picking up on some of the key points. On Mon, 2 Aug 2021 at 14:40, Ted Lemon wrote: > > The reason for the KEY having a different lease time is so that the domai= n > name can be claimed without being usable for service discovery. When the > other records expire, the KEY remains to hold the name until it expires, = so > if the host renews before then, no other host can claim the name. We coul= d > do this for some other record, but the KEY record has the virtue that it'= s > useful for authentication. It's true that this is currently only used by > SRP, though. We could make this apply to more records, but I don't know o= f > a use case for that, and if we come up with one later we can add another > EDNS0 option=E2=80=94the number space is not small. > Understood. I don't have a strong opinion; it's one for the working group to ponder (along with the IPR). > Is it worth looking at the draft through the lens of the EDM program? For >> example should it be extensible to separate out other RRtypes? Should >> greasing come into the picture? The answer might be "not in this case", = but >> I thought it worth at least thinking about. >> > > I have no idea what this means=E2=80=94can you elaborate? > This is https://www.iab.org/activities/programs/evolvability-deployability-maintain= ability-edm-program/ . I was particularly thinking of the "E" part: Evolvability: Encourage protocols to design for extensibility and greasing, and promote the use of extension points to prevent ossification. Make it easy for people, especially those who aren=E2=80=99t steeped in IETF proces= s, to know which extension points are the right ones to use for a given protocol (and which ones should be considered more stable/ossified), and make sure there aren=E2=80=99t high allocation barriers to use those extension points= . This draft elaborates: https://datatracker.ietf.org/doc/html/draft-iab-use-it-or-lose-it-01 Chris --000000000000e48f4305c8bf5449 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Te= d,

Just picking up on some of the key points.
On Mo= n, 2 Aug 2021 at 14:40, Ted Lemon <m= ellon@fugue.com> wrote:

The reason for the= KEY having a different lease time is so that the domain name can be claime= d without being usable for service discovery. When the other records expire= , the KEY remains to hold the name until it expires, so if the host renews = before then, no other host can claim the name. We could do this for some ot= her record, but the KEY record has the virtue that it's useful for auth= entication. It's true that this is currently only used by SRP, though. = We could make this apply to more records, but I don't know of a use cas= e for that, and if we come up with one later we can add another EDNS0 optio= n=E2=80=94the number space is not small.
<= /div>

Understood. I= don't have a strong opinion; it's one for the working group to pon= der (along with the IPR).
=C2=A0
Is it worth looking at the = draft through the lens of the EDM program? For example should it be extensi= ble to separate out other RRtypes? Should greasing come into the picture? T= he answer might be "not in this case", but I thought it worth at = least thinking about.
=

I have no idea what this means=E2=80=94can you el= aborate?


I was particularly thinking = of the "E" part:
Evolvability: Encourage protocols to de= sign for extensibility and=20 greasing, and promote the use of extension points to prevent=20 ossification. Make it easy for people, especially those who aren=E2=80=99t= =20 steeped in IETF process, to know which extension points are the right=20 ones to use for a given protocol (and which ones should be considered=20 more stable/ossified), and make sure there aren=E2=80=99t high allocation= =20 barriers to use those extension points.
--000000000000e48f4305c8bf5449-- From nobody Wed Aug 4 13:16:48 2021 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 992B43A0845 for ; Wed, 4 Aug 2021 13:16:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=fugue-com.20150623.gappssmtp.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 8FHuKp8N1k6X for ; Wed, 4 Aug 2021 13:16:41 -0700 (PDT) Received: from mail-oi1-x22c.google.com (mail-oi1-x22c.google.com [IPv6:2607:f8b0:4864:20::22c]) (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 1B6DD3A0844 for ; Wed, 4 Aug 2021 13:16:40 -0700 (PDT) Received: by mail-oi1-x22c.google.com with SMTP id q6so4263553oiw.7 for ; Wed, 04 Aug 2021 13:16:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ZptNo5Y37Tx/Avhs2ZFKHdt4xbdVlBh6IYEOhc+8lFU=; b=xALUcLg0E8HP7P1MpRgZ0HkjSAXTWMoXx/Fj3q5Nq/lkHqOfHqjdnZEMyoFVyUQbd2 164SzjEG6BVnVXVvFAxh0gnYoHuBUf06smx+RZb4/0T8gGtkmMqLOXWRKPTe07JlSIdu cl1IUPOTwaDR6eEcAGosEeteifGAHi8VpKtiz/sBh0U5Bc1WOmUcphUWSJHeeABYQbiF PMMXxSou7yI5Jpkmd2C+Z7In11bvyULabfi2MX351I3Qm0awkAgq6+3ksnDhaV2ZYL+E QS/XdlOgHeSIsQT/BpURlesUTkCPCZ2YqMBbnqaU2gYBsnbs0Shk93xzdeM9r6PKdG1h POSQ== 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=ZptNo5Y37Tx/Avhs2ZFKHdt4xbdVlBh6IYEOhc+8lFU=; b=FRV7DWC9LHQdjQo18oU4OegOohmg52PwceUOxGzC7iUjWWl4Q1uxOd4ZHi6dsVHRaT HtlZBNJgCayG6sWltZu4UhqmTtmRgToUy00sO5feQD+2IxX5dCz1DGKV7OXySqhAOHf6 +kvswIAzr4yXRufnRd2JU+V/VsTvUnvAXz5vILncaM0QA3F92+PjgD66OLRY+vP3+McP nkjbSmFl1wH16+7GaLgTXF+13JIraE9mpkmbiYsr0HfNTzi0osO6fj1nuMM9cFvAz2gW Fj5/6XE/FvY9J69hPzBheACYM0fBrDVYu0DNI6bNaU7EgB+r1jOMM7huTrbaRHbfIFxf jEUA== X-Gm-Message-State: AOAM5319/RiuA8aefT3d8kgMVqiwrTTmpPfTwhNRRtrV1/vSnXEMrrS3 5ReSdLMnD6QmwJMCttPcgbTP6H1r+MqEcxQL94nNwg== X-Google-Smtp-Source: ABdhPJzo/YPxBYv+MaqOtayOJSzwfxAyaV2PoKCk8hmn9jVkV5IultcGy/zgYu+ElduwbL9ExE696l0gafLsxV3WvIo= X-Received: by 2002:aca:2102:: with SMTP id 2mr1071749oiz.67.1628108199507; Wed, 04 Aug 2021 13:16:39 -0700 (PDT) Received: from 649336022844 named unknown by gmailapi.google.com with HTTPREST; Wed, 4 Aug 2021 13:16:39 -0700 Mime-Version: 1.0 X-Mailer: Superhuman iOS 9294 X-Superhuman-Draft-ID: draft009ade2b23e0fe44 References: In-Reply-To: From: Ted Lemon X-Superhuman-ID: krxxkmit.090095f8-66a8-4f89-8a74-1f9642d02bc6 Date: Wed, 4 Aug 2021 13:16:39 -0700 Message-ID: To: Chris Box Cc: dnssd Content-Type: multipart/alternative; boundary="000000000000e34e6505c8c17aa1" Archived-At: Subject: Re: [dnssd] draft-sekar-dns-ul X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Aug 2021 20:16:47 -0000 --000000000000e34e6505c8c17aa1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Ah, okay. Thanks! I think we are covered: the availability of additional edns0 options addresses the requirement stated in the iab document. On Wed, Aug 4 2021 at 13:42, Chris Box wrote: > Ted, > > Just picking up on some of the key points. > > On Mon, 2 Aug 2021 at 14:40, Ted Lemon wrote: > >> >> The reason for the KEY having a different lease time is so that the >> domain name can be claimed without being usable for service discovery. W= hen >> the other records expire, the KEY remains to hold the name until it >> expires, so if the host renews before then, no other host can claim the >> name. We could do this for some other record, but the KEY record has the >> virtue that it's useful for authentication. It's true that this is >> currently only used by SRP, though. We could make this apply to more >> records, but I don't know of a use case for that, and if we come up with >> one later we can add another EDNS0 option=E2=80=94the number space is no= t small. >> > > Understood. I don't have a strong opinion; it's one for the working group > to ponder (along with the IPR). > > >> Is it worth looking at the draft through the lens of the EDM program? Fo= r >>> example should it be extensible to separate out other RRtypes? Should >>> greasing come into the picture? The answer might be "not in this case",= but >>> I thought it worth at least thinking about. >>> >> >> I have no idea what this means=E2=80=94can you elaborate? >> > > This is > https://www.iab.org/activities/programs/evolvability-deployability-mainta= inability-edm-program/ > . > > I was particularly thinking of the "E" part: > > Evolvability: Encourage protocols to design for extensibility and > greasing, and promote the use of extension points to prevent ossification= . > Make it easy for people, especially those who aren=E2=80=99t steeped in I= ETF > process, to know which extension points are the right ones to use for a > given protocol (and which ones should be considered more stable/ossified)= , > and make sure there aren=E2=80=99t high allocation barriers to use those = extension > points. > > > This draft elaborates: > https://datatracker.ietf.org/doc/html/draft-iab-use-it-or-lose-it-01 > > Chris > --000000000000e34e6505c8c17aa1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Ah, okay. Thanks! I think we are covered: the availability of= additional edns0 options addresses the requirement stated in the iab docum= ent.

=20 =20

On Wed, Aug 4 2021 at 13:42, Chris Box <c= hris.box.ietf@gmail.com> wrote:
Ted,

Just picking up on some of the key= points.

On Mon, 2 Aug 2021 at 14:40, Ted Lemon <mellon@fugue.com> wrote:

The r= eason for the KEY having a different lease time is so that the domain name = can be claimed without being usable for service discovery. When the other r= ecords expire, the KEY remains to hold the name until it expires, so if the= host renews before then, no other host can claim the name. We could do thi= s for some other record, but the KEY record has the virtue that it's us= eful for authentication. It's true that this is currently only used by = SRP, though. We could make this apply to more records, but I don't know= of a use case for that, and if we come up with one later we can add anothe= r EDNS0 option=E2=80=94the number space is not small.
=

= Understood. I don't have a strong opinion; it's one for the working= group to ponder (along with the IPR).
=C2=A0
=
Is it worth loo= king at the draft through the lens of the EDM program? For example should i= t be extensible to separate out other RRtypes? Should greasing come into th= e picture? The answer might be "not in this case", but I thought = it worth at least thinking about.

I have no idea what this means=E2=80= =94can you elaborate?


I was particula= rly thinking of the "E" part:
=
Evolvability: Encourage pr= otocols to design for extensibility and=20 greasing, and promote the use of extension points to prevent=20 ossification. Make it easy for people, especially those who aren=E2=80=99t= =20 steeped in IETF process, to know which extension points are the right=20 ones to use for a given protocol (and which ones should be considered=20 more stable/ossified), and make sure there aren=E2=80=99t high allocation= =20 barriers to use those extension points.
--000000000000e34e6505c8c17aa1-- From nobody Wed Aug 4 18:15:37 2021 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F16CE3A0DD9 for ; Wed, 4 Aug 2021 18:15:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.847 X-Spam-Level: X-Spam-Status: No, score=-1.847 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_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 zzWm2vrC2S2k for ; Wed, 4 Aug 2021 18:15:31 -0700 (PDT) Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) (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 B7E8D3A0DCE for ; Wed, 4 Aug 2021 18:15:30 -0700 (PDT) Received: by mail-lj1-x235.google.com with SMTP id x7so4776152ljn.10 for ; Wed, 04 Aug 2021 18:15:30 -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=46feKQbUQjsq23V84krGU0D2YxNKvvCokfmYX+Dea68=; b=orwl8fhw9R2XMuMk4Xi/oz+pUoIcK1SGsrLzKU5wVM91AhagWc2KWqyeAQ4YqUroku PYFLCKYnoHd1fESeCGBsBvHq+tqocZ6A/bPEQGi1d4YeHBN4S6PvDO3LFH1OASI+rEsm tmbp9+4ctKMpLyJ4mqoZ76Tj5p03dtgCzbv5/7ZUkS3/kJd+9N72kT6s79edcy+ckhY4 peQSIp44+AKZr7eks8KMC76LwAru5Z9gMJVEeYRwj3qfoe3ewYJp6PYHCLFlvt1uj9WQ J2kmDzOlTl4ncblnebQxN2xcfweE5PoWZ91dzbZ9jM7m13Ax5l7BC1Cli/IF2WoxfVQs dngA== 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=46feKQbUQjsq23V84krGU0D2YxNKvvCokfmYX+Dea68=; b=l/3mBnNPGzCyStJIZITD/wyW8AlKp4rtMeI+WMJa+ENPXSwHuBfHxxD9UVR+NESzNY hl19gO38dgQ9Z9tnzJoCDJEHZ3jljCZNFgVzXz+jD+3HKV5zzccqlULvIHJh7BkZIcxR JH3SDKcZxHZD5RBn8ZfqYHVY23rFAJwWsk6iKZNfqzxTstWnzl10oPyVR6x7mC/X/koN OV6+ieM57kHdvZGs5tRlkPZFeIHRjuLxbUXAUChzSdClwzx/foJ9OcnVyOju11FEtZMq iCUatscdLs8H/TFm2/ZMF7MO3PYi1bMrxB84uWQxiGxFtP9ElTxHwJ8P8h838U4sV5bP oyng== X-Gm-Message-State: AOAM533khyz0S4oeWXkMcwdXKc5dhngH6dZyWqdANwXwi0uREW1Dh70Q O+aOgPvAj9gqVvvv+zA6enRpz58gTwVdRKS4asU= X-Google-Smtp-Source: ABdhPJyXvWWpVgtny8bVCkVAHqAquVceBr84LBuYnO7WsdSqKN9MYvZmEXGkypKQX3jiCvAOlWN0Kh+ndQRErL2CFhU= X-Received: by 2002:a05:651c:516:: with SMTP id o22mr1332711ljp.152.1628126126835; Wed, 04 Aug 2021 18:15:26 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Nathan Dyck Date: Wed, 4 Aug 2021 21:15:15 -0400 Message-ID: To: Tim Wicinski Cc: David Schinazi , DNSSD Content-Type: multipart/alternative; boundary="000000000000708d3c05c8c5a77b" Archived-At: Subject: Re: [dnssd] WGLC for draft-ietf-dnssd-srp X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2021 01:15:36 -0000 --000000000000708d3c05c8c5a77b Content-Type: text/plain; charset="UTF-8" Hi All, I have read the document and while I am brand new to IETF operations, I believe it is largely ready to publish. A few smaller issues. I had to re-read section 2.1.1 a few times to understand all the details. One wording that threw me off a bit was "updates its local idea of the SRP namespace". This could be improved by unifying terms from earlier in the document, which outline this process as "registers the SRP client hostname locally". Further, the section itself feels somewhat non-specific as to how these types of records should be identified so that Advertising Proxy can distinguish when to use the different conflict behaviours. Section 3: "may made" should be "may make" I think. Echoing Jonathan and Abtin's use-cases in Thread Border Routing, Nanoleaf will be using this technology in our Thread Border routing feature as part of our Shapes and Elements product lines. https://www.techhive.com/article/3619639/nanoleafs-shapes-and-new-wood-like-elements-panels-will-include-thread-border-routers.html Best Regards, Nathan Chief Product Officer Nanoleaf On Mon, Aug 2, 2021 at 2:16 PM Tim Wicinski wrote: > > I've read the document and I think it is ready to be published. > > My one nit before moving forward is the authors run the nits tool and > address the messages about updating references. > > tim > > > On Wed, Jul 28, 2021 at 5:57 PM David Schinazi > wrote: > >> Hi DNSSD enthusiasts, >> >> This email starts an official Working Group Last Call >> for draft-ietf-dnssd-srp. This call asks whether we believe the document is >> ready for publication. As such we are asking two questions: >> >> 1) if you believe this document is not ready to publish, please speak up >> now >> >> 2) if you have read the document and think it is ready, please say so as >> well >> >> For this call to succeed, we'll need statements of explicit support from >> people who have read the draft. Please send statements in either direction >> as responses to this email. This call will be open until 2021-08-15 23:59 >> UTC. >> >> Thanks, >> David >> _______________________________________________ >> dnssd mailing list >> dnssd@ietf.org >> https://www.ietf.org/mailman/listinfo/dnssd >> > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd > --000000000000708d3c05c8c5a77b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi All,

I have read the document and wh= ile I am brand new to IETF operations, I believe it is largely ready to pub= lish. A few smaller issues.

I had to re-read secti= on=C2=A02.1.1 a few times to understand all the details. One wording that t= hrew me off a bit was "updates its local idea of the SRP namespace&quo= t;. This could be improved by unifying terms from earlier in the document, = which outline this process as "registers the SRP client hostname local= ly". Further, the section itself feels somewhat non-specific as to how= these types of records should be identified so that Advertising Proxy can = distinguish when to use the different conflict behaviours.

Section 3: "may made" should be "may make" I t= hink.

Echoing Jonathan and Abtin's use-cases i= n Thread Border Routing, Nanoleaf will be using this technology in our Thre= ad Border routing feature as part of our Shapes and Elements product lines.= https= ://www.techhive.com/article/3619639/nanoleafs-shapes-and-new-wood-like-elem= ents-panels-will-include-thread-border-routers.html

Best Regards,

Nathan

Chief Product Officer
Nanoleaf

On Mon, Aug 2, 2021 at 2:16= PM Tim Wicinski <tjw.ietf@gmail.c= om> wrote:

I've read the document and I think it is ready to be published.
<= div class=3D"gmail_default" style=3D"font-family:monospace">
My one nit before m= oving forward is the authors=C2=A0run the nits tool and address the message= s about=C2=A0updating references.

tim


On Wed, Jul 28, 2021 at 5:57 PM David Schinaz= i <dschina= zi.ietf@gmail.com> wrote:
Hi DNSSD enthusiasts,
=
This email starts an official Working Group Last Call for=C2= =A0draft-ietf-dnssd-srp. This call asks whether we believe the document is = ready for publication. As such we are asking two questions:

<= /div>
1) if you believe this document is not ready to publish, please s= peak up now

2) if you have read the document and t= hink it is ready, please say so as well

For this c= all to succeed, we'll need statements of explicit support from people w= ho have read the draft. Please send statements in either direction as respo= nses to this email. This call will be open until 2021-08-15 23:59 UTC.

Thanks,
David
_______________________________________________
dnssd mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/listinfo/dnssd
_______________________________________________
dnssd mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/listinfo/dnssd
--000000000000708d3c05c8c5a77b-- From nobody Tue Aug 10 09:10:34 2021 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B6E33A12D4 for ; Tue, 10 Aug 2021 09:10:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.595 X-Spam-Level: X-Spam-Status: No, score=-9.595 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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=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=Xm3xfSGz; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=XyGdTESq 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 Xj4qFIu_rlIx for ; Tue, 10 Aug 2021 09:10:19 -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 31E193A12D9 for ; Tue, 10 Aug 2021 09:10:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5789; q=dns/txt; s=iport; t=1628611819; x=1629821419; h=from:to:cc:subject:date:message-id:mime-version; bh=QbJoBuho+qxGlAz2LF3wCnuQPn+9MsgL6LZxOKnK/Ww=; b=Xm3xfSGz2bAvGkYQiGMmnXOqzR7VcHE2yN7UehFvpVQnhgnPB/N6kLM7 DgGXgDIDdtUoknhu7RlasO9/4Ckvo1QeIl+40mh/VBs2fbNhANXzOiv4M PPJh8mQuNutwLAVZapa1CUFi9ORfqbXq40HPX9HgQ2ZqevG8ZPj+GMbjJ Y=; IronPort-PHdr: =?us-ascii?q?A9a23=3AYc1sCxPBHLzRWl7TGuEl6ncfWUAX0o4cdiYU5?= =?us-ascii?q?4YpzbVUfffr85fjORnZ4vNgxB/MUJ7A4v1Jw+zRr+j7WGMG7JrA1RJKcJFFW?= =?us-ascii?q?xIfz8lDmQsmDZ2EBFH1avnwYH9yEMFLTlQw+Xa9PABcE9r/YFuHpHq04HYSF?= =?us-ascii?q?xzzOBAzKP7yH9vZjt+80Ka5/JiACzg=3D?= IronPort-HdrOrdr: =?us-ascii?q?A9a23=3Af2mrzq7iFSRW+hH2NwPXwWWBI+orL9Y04l?= =?us-ascii?q?Q7vn2ZFiY1TiXIra6TdaoguiMc0AxhJU3Jmbi7Sc69qADnhOJICOgqTPmftW?= =?us-ascii?q?zd2FdAQ7sSlrcKrweQfhEWldQtlJuIEZIOcuEYZGIS5a2RjWXIcKdD/DDtyt?= =?us-ascii?q?HPuQ6q9QYUcegcUdAY0+4WMHf+LmRGAC19QbYpHpuV4cRK4xC6f24MU8i9Dn?= =?us-ascii?q?4ZG8DeutzijvvdEF47Li9izDPLoSKj6bb8HRTd9AwZSSlzzbAr9nWAuxDl55?= =?us-ascii?q?+kr+qwxnbnpizuBtVt6ZncI+l4dYixY/suW3LRY8GTFcJcsoi5zXUISSeUmQ?= =?us-ascii?q?8XeZf30k8d1o9ImgzslymO0GXQMk/boW0TA7uI8y7EvZMlyvaJHg7SQvAx9b?= =?us-ascii?q?6wOHHimjsdlcA536RR022DsZ1LSRvGgSTm/tDNEwpnj0yuvBMZ4KQuZlFkIM?= =?us-ascii?q?MjgYVq3MciFYJuYeM9NTO/7JpiHPhlDcna6voTeVSGb2rBtm0qxNC3RHw8Eh?= =?us-ascii?q?qPX0BH46WuonRrtWE8y1FdyN0Un38G+p54Q55Y5/7cOqAtkL1VVMcZYa90Ge?= =?us-ascii?q?9ES8qqDW7GRw7KLQupUBnaPbBCP2iIp4/84b0z6u3vcJsUzIEqkJCES19cvX?= =?us-ascii?q?5aQTOmNSRP5uw8zvnpehTzYd3A8LAt23FJgMyKeFOwC1zxdLkHqbrUn8ki?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BCCwCCoxJh/5hdJa1agmKBIzBRB3d?= =?us-ascii?q?aNzGER4NIA4U5nh2FAYFCgREDVAsBAQENAQFBBAEBg1iBABmCSwIlNwYOAQI?= =?us-ascii?q?EAQEBEgEBBQEBAQIBBgSBEROFaA2GRRYRHQEBKwwBEQEMPgIEMCcEDhkOgk8?= =?us-ascii?q?BgX5XAy8BnHABgToCih96gTGBAYIHAQEGBASFExiCNAmBOoJ8hA0BAYcLHIF?= =?us-ascii?q?JRIEVJxyCMoR4g1E2gi6CYYJBG4JIkUApAoJJR4hKn1cKgygFkXGMVQUmg2W?= =?us-ascii?q?LYJcqtiuEfwIEAgQFAg4BAQaBdiWBWXAVZQGCPlAZDpIQil5zOAIGAQoBAQM?= =?us-ascii?q?JiHgBAQ?= X-IronPort-AV: E=Sophos;i="5.84,310,1620691200"; d="scan'208,217";a="919768486" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 10 Aug 2021 16:10:17 +0000 Received: from mail.cisco.com (xbe-aln-001.cisco.com [173.36.7.16]) by rcdn-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 17AGAHip017324 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Tue, 10 Aug 2021 16:10:17 GMT Received: from xfe-rtp-001.cisco.com (64.101.210.231) by xbe-aln-001.cisco.com (173.36.7.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Tue, 10 Aug 2021 11:10:17 -0500 Received: from xfe-rcd-001.cisco.com (173.37.227.249) by xfe-rtp-001.cisco.com (64.101.210.231) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Tue, 10 Aug 2021 12:10:16 -0400 Received: from NAM12-MW2-obe.outbound.protection.outlook.com (72.163.14.9) by xfe-rcd-001.cisco.com (173.37.227.249) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15 via Frontend Transport; Tue, 10 Aug 2021 11:10:16 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hNwM+E5TuOsp00PeWKQzhXS73aB2pAJcHUKWIQu/+39GDXQUpxq14+PfqcES6a8UB6kk6fADk3u4r7x5MTaM8vhtA+036Ii9vgWxgkRL1jhBKBke67ebYyCqLwfkxxZiDKGemjM3Y2WDWs1dG1jL+JYF9vnEsQrU1t1o1tlZBR210gVwLgMrmvmVlU+j8x7RzeN2Obu4PSwvkjMbPQSWD004MfeJcBCU7qjcWGGFqGvlZLgoVE9o++3JmkFSGtuj8IOECV6EdQCFMzkbkUvKoKoOwYT+CnyifRyaqxoxYKPguW2uPH8MeVL41v62QtqZL/dxCSLkINlbALp5BUt3+g== 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=QbJoBuho+qxGlAz2LF3wCnuQPn+9MsgL6LZxOKnK/Ww=; b=jGH/0trp7fwyhF/SOI26ij77tBHUFLtmWTEPOevxzu4fh9vsih6yH0j9StZJ5wOShpMsnBW0uktTu64FYzopA25q3pUY2HDawPrMeHwZElgUDnHmK1opUHZalpvEeMd0oaM0DO9trmnLYV2Kq5xn95vwlnQxdwimzyxueB1zBMxC4oAKMTxdKhcLeyIDiuKbkvhczDJoPqfgWeejg+0qg0Po97DJauqpWga8OH0tdAl8gB5xVFtcqWrrNv71c/YSPjBSYvafbzysnatBIBeyOihSuD//nE7pHq9lS0C3bH595T/scwyUyqpERpCZ/LszesW97dmSRqWh62/dHguAYg== 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=QbJoBuho+qxGlAz2LF3wCnuQPn+9MsgL6LZxOKnK/Ww=; b=XyGdTESq2AcaJSSKQWQmnKo4nCD+RHqAMfTUvG7pobOFED1AtNBbNptQ2ZoVH9MGTgK7NsXQvf++xdzFP52PdU1uXKOyC7k3DUxGFjGOg95bgQFTT9pv3G9DG4/2A9xURERL7feMSJvnAeoYJWNUzxyeKQukyEDTQAzJUweYpGk= Received: from PH0PR11MB4966.namprd11.prod.outlook.com (2603:10b6:510:42::21) by PH0PR11MB5208.namprd11.prod.outlook.com (2603:10b6:510:3b::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4394.21; Tue, 10 Aug 2021 16:10:15 +0000 Received: from PH0PR11MB4966.namprd11.prod.outlook.com ([fe80::6d61:c160:def1:bc64]) by PH0PR11MB4966.namprd11.prod.outlook.com ([fe80::6d61:c160:def1:bc64%3]) with mapi id 15.20.4394.023; Tue, 10 Aug 2021 16:10:15 +0000 From: "Eric Vyncke (evyncke)" To: dnssd CC: "'Chris Box'" , "STARK, BARBARA H" , "'David Schinazi'" , "'Erik Kline'" Thread-Topic: Please welcome Chris Box as the new DNSSD WG co-chair Thread-Index: AQHXjgI0q+Wlm8htykqAnr8r1tONLA== Date: Tue, 10 Aug 2021 16:10:15 +0000 Message-ID: Accept-Language: fr-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.51.21071101 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=cisco.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 899ea21c-6bce-4b55-22e3-08d95c195710 x-ms-traffictypediagnostic: PH0PR11MB5208: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: H+6AJ65f+JUUcM6Pv16bZwOnNPQltzOq16KzvRPS/Wp4jMaBxG7f3yMdLyeJja5MEPxgJrzc39/wdsusNUOwAk7dt23t2TdyLpIEhGbBU0ZWIyiboDReCaXGmvj1Nb9l1/raGgtQJKaKumCWi50l0dww55V4IgJkT3TPrkRCRDDzlS8qM1Tgdip3pvDdS6FqwkZ8pDBjfgX5DcDwMw4eT5dXtZMV65NY/YI5mnNucoA2bZ1hF2xaI5xpUjBlKY6CuOkkDc+oqTHLDTQ/gDhBSEU9c2qhBYj8Y90nyMsRio8/gBl56YoJGI6nl6Wd3kTa2Ylo0sCzJtfMG8DcDAI+zlZGSKPZGprvMuLpbIbAwuwkVNCrFcCh0XfdNm9LifPt2e63a1e1Y3ouSVToMHJepQcdnstqHriTQxOUcg9C1jwUlJS0BfvK9EKkoJF5WPIuOCbyJ4zqWo16jLoNnd68Zf57dCflA0Wh6IWGVwXK46sjACHuDGutcVh8SQ5yIyBZVyPcbqfKlRqTH4N84j+7vpAe2o9S4BurBd4uAKp140yaJms8ImKS7FpNAUj/+BZ0eEN1TWQBTuikmd52/jGUMiCqMedcBXnu2NhzB30g5zU01FK6GcCz//x26Eweh800qcIQUMsDzshbx7agdIQ018kl/mR9JMIRwWUmcD5/vThOJDt6r15/AZ5JHb055RjrsjMriNphuUKe7fRxhFR9wycQiFyCL1sqvO2JdHFeLSI= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR11MB4966.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(376002)(396003)(136003)(346002)(39860400002)(316002)(83380400001)(4744005)(5660300002)(2906002)(6512007)(186003)(54906003)(6486002)(478600001)(66556008)(2616005)(122000001)(38100700002)(66574015)(71200400001)(86362001)(38070700005)(8936002)(8676002)(66476007)(33656002)(76116006)(36756003)(64756008)(66446008)(4326008)(6506007)(6916009)(91956017)(66946007)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?UmxMK1U0UzJPa1VCL0t4SjE4TE5QRGM1d2xSKzZiUnV6TG4xTndJb1BIYjUw?= =?utf-8?B?MUhIMlNkeUJQbXZBK1BPWDZ5cGhWU3EvYXpyR2pYR25YVWlJdlg0cnJGMDRC?= =?utf-8?B?Mm5DbXUzcUVJUUE0b1d3VUlTUmgvbVJINCswT2p6bGMxTVJSazlacFZNQzN0?= =?utf-8?B?QmNZeWRSajBDMUdFTXVKSmlSTitoV1k3ZmlGTVhQTXo3ckVzRnY3c3BNWHlB?= =?utf-8?B?SVdoa3ZHZjJpYXVObGpCYm1oVGtXYloyYkptK09UWThuUnJnR09xRUhlWmo3?= =?utf-8?B?cCtHZDNlOHREYUhnc2JkenZHNmxTazRRUG5oT0Z4cWI2Y1NVcDZ0bloyVWdu?= =?utf-8?B?QW8rd3RhQUFhVW9YaS92eFZ0RHlNQ0U5Z1JnY1dCV1NpNGFNaTltcFlQK3V1?= =?utf-8?B?eWxKNVY2eU0wa2YyQWFuTVhyZXJ2U2VUbUdCUldmVVZ2dnNudXprQzdBRWJC?= =?utf-8?B?Y1o2MmhjYnhYVjFmUVVQRXlvR05qYzVrM0kxRHI0UmhsL1JubCtRZ0xOY0F0?= =?utf-8?B?Q0tyd3EvODRlS1VGc3BLbjBBelJmanhTMmFNdWFmek9LK242NEcydmZwVzQx?= =?utf-8?B?dE9SZUk0WXRBbUZpa2tHRjNEZnV4RU9xb3ltMEpHMDUyMkRqbnFiK2Vyd0FN?= =?utf-8?B?SlpMWDh3V1lPQnRBU3pBT3dSb3Y4M3pjRnlVZ0EzMC9qekRCZU02dE9CWlRK?= =?utf-8?B?cFFYTUdEOUtWLzBxaXI3eEJmZFAxd3VuVHNxSDFQNjVONnprSndNSU9YNmFR?= =?utf-8?B?RUd4d05kS0tNU09tV2JOa2pka09wZnpuamJ5Ky9MOW50a0t1QzJCN2lQb0NF?= =?utf-8?B?ZjF0ZDc0TzU4czhxWGwzOFZPZjRnc3poeTUzL0k4WEJqbmVBM1VYa2NaZ3Fk?= =?utf-8?B?YmNBajd4WEZ3a0RPZnZ1NldqRGpBZDZnK01aRzNxRTFPU0R6MnZiaHNjelB3?= =?utf-8?B?dU1hcnRwZURwM05oV1JKeTRKQUN6NU9GUFF5Y0s2REN3cTg2a083V0t6VVlk?= =?utf-8?B?bjJIUU1DWEwwRGdzOEMvWlcvZWxZY1FiWDRtSVltUU84U3h4b2ZyMTdDYVVo?= =?utf-8?B?SkxSQ3QwVVkrY2pHWWUvZ0QvSzJaWVBCSFdXQmtiSGJUSkJoSlNUdDN4Q1Ey?= =?utf-8?B?RFYzdzI4MDZiY3lKZG5BZXBRTEJGSFI0VFhtZ09EbU1VLzNhbDZXekMyL3Fm?= =?utf-8?B?bmRpL1VoLzFTZElOcytZVVdleVJISnJxUkRIVUhPaE84RE5pc245UXF3VDJI?= =?utf-8?B?V2kzdytIc3VTcm1tVFcyeHBNaUgxZkRKTjFjYzlNSGoxdFNiamhRbmI5STRD?= =?utf-8?B?TWcwN2lkNjduQmk5VmlQM3dCeHJPeWZhTDNLNzJ2bXVqYk5xTkU0dU0zZzYw?= =?utf-8?B?dUJNdmRFNXUvOXZ5SUN5UHIydW9vei9CZHVjRW9kM05lcHpoSmR6a2hmSW5W?= =?utf-8?B?VytwRDJ6L205dVk3QVpreno3aW5zVFhlUkMzMkd4Ymg3bG83NG1PNUQvTGFR?= =?utf-8?B?MzRXeTVqRzRWb3cvR2NVMmR0cWZiMmRkMVdyLzlLRTd1aG9MaHJEWmpCd3o0?= =?utf-8?B?dkJNMTlieXRSaXRuUHZ5YnZyLzNnYllRNzZwZk1XWjhTOWl5QlhnVEZJUzVH?= =?utf-8?B?UTJPdWJKRlBsTEJzS25sbk5qNUFZWm5xTndlY1VPekJacWNXZEhIR0dKRWdP?= =?utf-8?B?WDE4MWh3WnMvZ2dOaFg3Tjh2bFdSZzRHc3ZsVzlVS2FQUkFFZ3BhekVnTFhi?= =?utf-8?B?STdhTzlnbU5IYkxiblUwaVdnMCtmZTBoSmUweUtqd25kOTRtdjZGcmxEenpG?= =?utf-8?B?cnRSSmhqVFoxbFdxdXBpQXdJTTR1cmc5UTRkM1UyRHpLNEV5UmN5WkhqZXFs?= =?utf-8?Q?eMfr/AGWy6jrE?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_F1E375B86F90456083DCFABEF6662378ciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PH0PR11MB4966.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 899ea21c-6bce-4b55-22e3-08d95c195710 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Aug 2021 16:10:15.3263 (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: 8uHOom9P/fg2Xy/GuakaXBHtOj8afKly9zqwgBL3wjONkOipbpXpT0oNfPDS+uRrOu+8Eb7FLXLSvFGrsocCxQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR11MB5208 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.16, xbe-aln-001.cisco.com X-Outbound-Node: rcdn-core-1.cisco.com Archived-At: Subject: [dnssd] Please welcome Chris Box as the new DNSSD WG co-chair X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2021 16:10:32 -0000 --_000_F1E375B86F90456083DCFABEF6662378ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBETlNTRCB3b3JraW5nIGdyb3VwLA0KDQpQbGVhc2Ugd2VsY29tZSBDaHJpcyBCb3ggYXMg dGhlIDNyZCBjby1jaGFpciBmb3IgdGhlIEROU1NEIFdHIGFzIG9mIHRvZGF5Lg0KDQpDaHJpcyBp cyBmcm9tIEJyaXN0b2wsIFVLIGFuZCBoYXMgc3BlbnQgdGhlIGxhc3QgMjAgeWVhcnMgZGVsaXZl cmluZyBtb2JpbGUgaW50ZXJuZXQgc2VydmljZSwgaW5pdGlhbGx5IG9uIE9yYW5nZSwgd2hpY2gg YmVjYW1lIEVFLCBub3cgcGFydCBvZiBCVC4NCkhlIGhhcyBvbmx5IGJlZW4gaW4gdGhlIElFVEYg Y29tbXVuaXR5IGZvciB0d28geWVhcnMgc28gaXMgc3RpbGwgcmFwaWRseSBsZWFybmluZzsgeW91 IG1heSBoYXZlIHNlZW4gaGltIGluIEFERCwgUVVJQyBvciBNQVNRVUUuIEhlJ3MgYWxzbyBpbiB0 aGlzIHllYXIncyBOb21Db20uDQpBdCB3b3JrIGhlIG1hbmFnZXMgYSBzbWFsbCB0ZWFtIG9mIGRl c2lnbmVycywgYW5kIGF0IGhvbWUgaGUncyByYWlzaW5nIGEgdGVlbmFnZSBkYXVnaHRlciB3aXRo IGFuIGludGVyZXN0IGluIGFsbCBhc3BlY3RzIG9mIFNURU0uDQoNCkJhcmJhcmEgU3RhcmsgaGFz IGJlZW4ga2luZCBlbm91Z2ggdG8gYWNjZXB0IHRvIGtlZXAgaGVyIGNvLWNoYWlyIHBvc2l0aW9u IHVudGlsIElFVEYtMTEyIGluIG9yZGVyIHRvIGhlbHAgQ2hyaXMgaW4gaGlzIG5ldyByb2xlLiBJ IGFtIHJlYWxseSBncmF0ZWZ1bCB0byBoZXIgZm9yIHRoaXMgbmljZSBnZXN0dXJlIGFuZCBmb3Ig dGhlIGFkZGl0aW9uYWwgd29yayB0byBiZSBkb25lIGluIHRoZSBjb21pbmcgbW9udGhzIDstKQ0K DQpEYXZpZCBTY2hpbmF6aeKAmXMgcm9sZSBpcyB1bmNoYW5nZWQgYXMgaGUgc3RheXMgdGhlIGNv LWNoYWlyIGZvciB0aGUgZm9yZXNlZWFibGUgZnV0dXJlLg0KDQpMZXTigJlzIGFsbCBrZWVwIHdv cmtpbmcgb24gRE5TU0QgOy0pDQoNCi3DqXJpYyAocmVzcG9uc2libGUgQUQpDQo= --_000_F1E375B86F90456083DCFABEF6662378ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCWZvbnQtc2l6 ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFp bFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZh dWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBw dDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlv bjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxh bmc9ImVuLUJFIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiIgc3R5bGU9IndvcmQtd3Jh cDpicmVhay13b3JkIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJGUiI+RGVhciBETlNTRCB3b3JraW5nIGdyb3VwLDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkZSIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+UGxlYXNlIHdlbGNvbWUgQ2hyaXMgQm94IGFzIHRoZSAzPHN1cD5yZDwvc3VwPiBj by1jaGFpciBmb3IgdGhlIEROU1NEIFdHIGFzIG9mIHRvZGF5Lg0KPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNocmlzIGlzIGZyb20gQnJp c3RvbCwgVUsgYW5kIGhhcyBzcGVudCB0aGUgbGFzdCAyMCB5ZWFycyBkZWxpdmVyaW5nIG1vYmls ZSBpbnRlcm5ldCBzZXJ2aWNlLCBpbml0aWFsbHkgb24gT3JhbmdlLCB3aGljaCBiZWNhbWUgRUUs IG5vdyBwYXJ0IG9mIEJULjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGUg aGFzIG9ubHkgYmVlbiBpbiB0aGUgSUVURiBjb21tdW5pdHkgZm9yIHR3byB5ZWFycyBzbyBpcyBz dGlsbCByYXBpZGx5IGxlYXJuaW5nOyB5b3UgbWF5IGhhdmUgc2VlbiBoaW0gaW4gQURELCBRVUlD IG9yIE1BU1FVRS4gSGUncyBhbHNvIGluIHRoaXMgeWVhcidzIE5vbUNvbS48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkF0IHdvcmsgaGUgbWFuYWdlcyBhIHNtYWxsIHRlYW0g b2YgZGVzaWduZXJzLCBhbmQgYXQgaG9tZSBoZSdzIHJhaXNpbmcgYSB0ZWVuYWdlIGRhdWdodGVy IHdpdGggYW4gaW50ZXJlc3QgaW4gYWxsIGFzcGVjdHMgb2YgU1RFTS48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkJhcmJhcmEgU3RhcmsgaGFzIGJlZW4ga2luZCBl bm91Z2ggdG8gYWNjZXB0IHRvIGtlZXAgaGVyIGNvLWNoYWlyIHBvc2l0aW9uIHVudGlsIElFVEYt MTEyIGluIG9yZGVyIHRvIGhlbHAgQ2hyaXMgaW4gaGlzIG5ldyByb2xlLiBJIGFtIHJlYWxseSBn cmF0ZWZ1bCB0byBoZXIgZm9yIHRoaXMgbmljZSBnZXN0dXJlIGFuZCBmb3IgdGhlIGFkZGl0aW9u YWwgd29yayB0byBiZSBkb25lDQogaW4gdGhlIGNvbWluZyBtb250aHMgOy0pPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj5EYXZpZCBTY2hpbmF6aeKAmXMgcm9sZSBpcyB1bmNoYW5nZWQgYXMgaGUgc3RheXMg dGhlIGNvLWNoYWlyIGZvciB0aGUgZm9yZXNlZWFibGUgZnV0dXJlLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+TGV04oCZcyBhbGwga2VlcCB3b3JraW5nIG9uIEROU1NEIDstKTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+LcOpcmljIChyZXNwb25zaWJsZSBBRCk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvYm9keT4NCjwvaHRtbD4NCg== --_000_F1E375B86F90456083DCFABEF6662378ciscocom_-- From nobody Tue Aug 10 09:58:43 2021 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF6443A145F for ; Tue, 10 Aug 2021 09:58:41 -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, HTML_MESSAGE=0.001, MSGID_FROM_MTA_HEADER=0.001, 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 EkBpi2lXFYAQ for ; Tue, 10 Aug 2021 09:58:36 -0700 (PDT) Received: from jax4mhob04.registeredsite.com (jax4mhob04.myregisteredsite.com [64.69.218.84]) (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 2C0BC3A145D for ; Tue, 10 Aug 2021 09:58:35 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.210]) by jax4mhob04.registeredsite.com (8.14.4/8.14.4) with ESMTP id 17AGwXpk002249 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Tue, 10 Aug 2021 12:58:33 -0400 Message-Id: <202108101658.17AGwXpk002249@jax4mhob04.registeredsite.com> Received: (qmail 24331 invoked by uid 0); 10 Aug 2021 16:58:33 -0000 X-TCPREMOTEIP: 73.251.233.169 X-Authenticated-UID: jw@pcthink.com Received: from unknown (HELO ?10.2.1.116?) (jw@pcthink.com@73.251.233.169) by 0 with ESMTPA; 10 Aug 2021 16:58:32 -0000 SavedFromEmail: jw@pcthink.com Date: Tue, 10 Aug 2021 12:58:28 -0400 In-Reply-To: Importance: normal From: =?UTF-8?Q?JW_=CE=BB_John_Woodworth?= To: "Eric Vyncke (evyncke)" , dnssd Cc: jw@pcthink.com, "'David Schinazi'" , "'Chris Box'" , "'Erik Kline'" , "STARK, BARBARA H" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.samsung.android.email_1899040286319330" Archived-At: Subject: Re: [dnssd] Please welcome Chris Box as the new DNSSD WG co-chair X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2021 16:58:42 -0000 ----_com.samsung.android.email_1899040286319330 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Q29uZ3JhdHVsYXRpb25zIGFuZCBXZWxjb21lIQotLS0tLS0tLSBPcmlnaW5hbCBtZXNzYWdlIC0t LS0tLS0tRnJvbTogIkVyaWMgVnluY2tlIChldnluY2tlKSIgPGV2eW5ja2U9NDBjaXNjby5jb21A ZG1hcmMuaWV0Zi5vcmc+CgpEZWFyIEROU1NEIHdvcmtpbmcgZ3JvdXAsCsKgClBsZWFzZSB3ZWxj b21lIENocmlzIEJveCBhcyB0aGUgM3JkIGNvLWNoYWlyIGZvciB0aGUgRE5TU0QgV0cgYXMgb2Yg dG9kYXkuCgrCoApDaHJpcyBpcyBmcm9tIEJyaXN0b2wsIFVLIGFuZCBoYXMgc3BlbnQgdGhlIGxh c3QgMjAgeWVhcnMgZGVsaXZlcmluZyBtb2JpbGUgaW50ZXJuZXQgc2VydmljZSwgaW5pdGlhbGx5 IG9uIE9yYW5nZSwgd2hpY2ggYmVjYW1lIEVFLCBub3cgcGFydCBvZiBCVC4KSGUgaGFzIG9ubHkg YmVlbiBpbiB0aGUgSUVURiBjb21tdW5pdHkgZm9yIHR3byB5ZWFycyBzbyBpcyBzdGlsbCByYXBp ZGx5IGxlYXJuaW5nOyB5b3UgbWF5IGhhdmUgc2VlbiBoaW0gaW4gQURELCBRVUlDIG9yIE1BU1FV RS4gSGUncyBhbHNvIGluIHRoaXMgeWVhcidzIE5vbUNvbS4KQXQgd29yayBoZSBtYW5hZ2VzIGEg c21hbGwgdGVhbSBvZiBkZXNpZ25lcnMsIGFuZCBhdCBob21lIGhlJ3MgcmFpc2luZyBhIHRlZW5h Z2UgZGF1Z2h0ZXIgd2l0aCBhbiBpbnRlcmVzdCBpbiBhbGwgYXNwZWN0cyBvZiBTVEVNLgrCoApC YXJiYXJhIFN0YXJrIGhhcyBiZWVuIGtpbmQgZW5vdWdoIHRvIGFjY2VwdCB0byBrZWVwIGhlciBj by1jaGFpciBwb3NpdGlvbiB1bnRpbCBJRVRGLTExMiBpbiBvcmRlciB0byBoZWxwIENocmlzIGlu IGhpcyBuZXcgcm9sZS4gSSBhbSByZWFsbHkgZ3JhdGVmdWwgdG8gaGVyIGZvciB0aGlzIG5pY2Ug Z2VzdHVyZSBhbmQgZm9yIHRoZSBhZGRpdGlvbmFsIHdvcmsgdG8gYmUgZG9uZQogaW4gdGhlIGNv bWluZyBtb250aHMgOy0pCsKgCkRhdmlkIFNjaGluYXpp4oCZcyByb2xlIGlzIHVuY2hhbmdlZCBh cyBoZSBzdGF5cyB0aGUgY28tY2hhaXIgZm9yIHRoZSBmb3Jlc2VlYWJsZSBmdXR1cmUuCsKgCkxl dOKAmXMgYWxsIGtlZXAgd29ya2luZyBvbiBETlNTRCA7LSkKwqAKLcOpcmljIChyZXNwb25zaWJs ZSBBRCkKCgoK ----_com.samsung.android.email_1899040286319330 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keSBkaXI9ImF1dG8iPkNvbmdyYXR1bGF0 aW9ucyBhbmQgV2VsY29tZSE8ZGl2Pjxicj48L2Rpdj48ZGl2IGFsaWduPSJsZWZ0IiBkaXI9ImF1 dG8iIHN0eWxlPSJmb250LXNpemU6MTAwJTtjb2xvcjojMDAwMDAwIj48ZGl2Pi0tLS0tLS0tIE9y aWdpbmFsIG1lc3NhZ2UgLS0tLS0tLS08L2Rpdj48ZGl2PkZyb206ICJFcmljIFZ5bmNrZSAoZXZ5 bmNrZSkiICZsdDtldnluY2tlPTQwY2lzY28uY29tQGRtYXJjLmlldGYub3JnJmd0OzwvZGl2Pjxk aXY+PGJyPjwvZGl2PjwvZGl2Pgo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiIGRpcj0iYXV0byI+ CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkZSIj5EZWFyIEROU1NEIHdvcmtpbmcg Z3JvdXAsPC9zcGFuPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRlIiPiZu YnNwOzwvc3Bhbj48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5Q bGVhc2Ugd2VsY29tZSBDaHJpcyBCb3ggYXMgdGhlIDM8c3VwPnJkPC9zdXA+IGNvLWNoYWlyIGZv ciB0aGUgRE5TU0QgV0cgYXMgb2YgdG9kYXkuCjwvc3Bhbj48L3A+CjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PC9wPgo8cCBjbGFzcz0iTXNvTm9y bWFsIj5DaHJpcyBpcyBmcm9tIEJyaXN0b2wsIFVLIGFuZCBoYXMgc3BlbnQgdGhlIGxhc3QgMjAg eWVhcnMgZGVsaXZlcmluZyBtb2JpbGUgaW50ZXJuZXQgc2VydmljZSwgaW5pdGlhbGx5IG9uIE9y YW5nZSwgd2hpY2ggYmVjYW1lIEVFLCBub3cgcGFydCBvZiBCVC48L3A+CjxwIGNsYXNzPSJNc29O b3JtYWwiPkhlIGhhcyBvbmx5IGJlZW4gaW4gdGhlIElFVEYgY29tbXVuaXR5IGZvciB0d28geWVh cnMgc28gaXMgc3RpbGwgcmFwaWRseSBsZWFybmluZzsgeW91IG1heSBoYXZlIHNlZW4gaGltIGlu IEFERCwgUVVJQyBvciBNQVNRVUUuIEhlJ3MgYWxzbyBpbiB0aGlzIHllYXIncyBOb21Db20uPC9w Pgo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BdCB3b3JrIGhlIG1hbmFnZXMgYSBzbWFsbCB0ZWFtIG9m IGRlc2lnbmVycywgYW5kIGF0IGhvbWUgaGUncyByYWlzaW5nIGEgdGVlbmFnZSBkYXVnaHRlciB3 aXRoIGFuIGludGVyZXN0IGluIGFsbCBhc3BlY3RzIG9mIFNURU0uPC9wPgo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDs8L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij5CYXJiYXJhIFN0YXJrIGhhcyBiZWVuIGtpbmQgZW5vdWdoIHRvIGFjY2VwdCB0byBrZWVwIGhl ciBjby1jaGFpciBwb3NpdGlvbiB1bnRpbCBJRVRGLTExMiBpbiBvcmRlciB0byBoZWxwIENocmlz IGluIGhpcyBuZXcgcm9sZS4gSSBhbSByZWFsbHkgZ3JhdGVmdWwgdG8gaGVyIGZvciB0aGlzIG5p Y2UgZ2VzdHVyZSBhbmQgZm9yIHRoZSBhZGRpdGlvbmFsIHdvcmsgdG8gYmUgZG9uZQogaW4gdGhl IGNvbWluZyBtb250aHMgOy0pPC9zcGFuPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj5EYXZpZCBTY2hpbmF6aeKAmXMgcm9sZSBpcyB1bmNoYW5nZWQgYXMgaGUg c3RheXMgdGhlIGNvLWNoYWlyIGZvciB0aGUgZm9yZXNlZWFibGUgZnV0dXJlLjwvc3Bhbj48L3A+ CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PC9w Pgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+TGV04oCZcyBhbGwga2Vl cCB3b3JraW5nIG9uIEROU1NEIDstKTwvc3Bhbj48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+LcOpcmljIChyZXNwb25zaWJsZSBBRCk8L3NwYW4+PC9wPgo8L2Rp dj4KCgo8L2JvZHk+PC9odG1sPg== ----_com.samsung.android.email_1899040286319330-- From nobody Tue Aug 10 13:34:03 2021 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A6403A1B71 for ; Tue, 10 Aug 2021 13:34:00 -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 HLV-qOh5zetE for ; Tue, 10 Aug 2021 13:33:54 -0700 (PDT) Received: from mail-qt1-x82d.google.com (mail-qt1-x82d.google.com [IPv6:2607:f8b0:4864:20::82d]) (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 BE4DF3A1B6E for ; Tue, 10 Aug 2021 13:33:54 -0700 (PDT) Received: by mail-qt1-x82d.google.com with SMTP id t16so158728qta.9 for ; Tue, 10 Aug 2021 13:33:54 -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=Zk8nak+s6KMKu3atutrA85zS8KCV5hOzRzqBTgYXKbc=; b=gQ4nltsTbDyeh6n6H2fEonRXRQbATud5GLGD9CvsGEPpDzdXGG3umNnCkzuVD+KPwt EIyqBdDpp0iElu0pqV1qW/tN9TqG8lIhYEH3W6dJ573GsFUW+dolnPyvoIAaPLIfk7IZ 26eGhishir+fJUl9S1+tHRZYW9QaJ3oRsu8lxc6SBYgw88GwDUQ+9JR9WW1TvcDO6dJo bNsRhM+KQKCUrge0VH2VKatyszv6IxJxXQ/RQtqujkO3U0XHuAIlTANTxzQ8b+qqO2wO l167KrDHMl+ZJO7nvBbLGTMyPWzfcTQEUuS6Z/Rd2ixKGlmONhKdA//6MeTzE4kBts4E eGWw== 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=Zk8nak+s6KMKu3atutrA85zS8KCV5hOzRzqBTgYXKbc=; b=LbZ+DMUUyPJu5GD6PDTd5KKDbbIj5Wmwk0bZCqp88qem2210CV4h7JdkCRaYklwox8 W4Zpb3a5yc7B5HXVLv2ZFWBSQEHhpE1w034gSbbsux0Kbjcm6VEzvjsEA5Y/BX3JOFgh 5tw4Rjl28a8l4rEavlatKF2Ud9FSEsUp5L4xNbMWKHKqAo8rAS1G+tsAe3TqXfgNDmSR IWr4QJv/k7OozaLqodC6ZFRo4DaKqW/yRuw8Vc6iDVa2QDHedyqA01Vmcf013Yc6ewEG RxA3bv0s5xulIsCh9leYfM5aWgP+3quCBFar5uEwoXf6zxpL2zcVtnueT1WZm0d6wgdI VF7g== X-Gm-Message-State: AOAM530S90BXhuzY2NVd8AjotGUJr7GSyI5piBm53f2bcBFMALEMlhf2 3r2bnfuwNP+PvrPkQBKWT4buWhqFx2HjBCU154A= X-Google-Smtp-Source: ABdhPJxGogo8vY9E044qGZZXjZNxNrN58o+xQB7Fl5YC96Qu8kNiUQmuNFSeIrThmPBdS857xOdsIPgzG+lI+7pJxcc= X-Received: by 2002:ac8:588f:: with SMTP id t15mr26817563qta.367.1628627632755; Tue, 10 Aug 2021 13:33:52 -0700 (PDT) MIME-Version: 1.0 References: <202108101658.17AGwXpk002249@jax4mhob04.registeredsite.com> In-Reply-To: <202108101658.17AGwXpk002249@jax4mhob04.registeredsite.com> From: Chris Box Date: Tue, 10 Aug 2021 21:33:41 +0100 Message-ID: To: =?UTF-8?Q?JW_=CE=BB_John_Woodworth?= Cc: David Schinazi , "Eric Vyncke (evyncke)" , Erik Kline , "STARK, BARBARA H" , dnssd Content-Type: multipart/alternative; boundary="00000000000085961e05c93a6b92" Archived-At: Subject: Re: [dnssd] Please welcome Chris Box as the new DNSSD WG co-chair X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2021 20:34:01 -0000 --00000000000085961e05c93a6b92 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thank you. Please bear with me while I learn the ropes. This is a long-standing working group with an important problem to solve so I will do my best to assist with that. Chris On Tue, 10 Aug 2021 at 17:58, JW =CE=BB John Woodworth wro= te: > Congratulations and Welcome! > > -------- Original message -------- > From: "Eric Vyncke (evyncke)" > > Dear DNSSD working group, > > > > Please welcome Chris Box as the 3rd co-chair for the DNSSD WG as of > today. > > > > Chris is from Bristol, UK and has spent the last 20 years delivering > mobile internet service, initially on Orange, which became EE, now part o= f > BT. > > He has only been in the IETF community for two years so is still rapidly > learning; you may have seen him in ADD, QUIC or MASQUE. He's also in this > year's NomCom. > > At work he manages a small team of designers, and at home he's raising a > teenage daughter with an interest in all aspects of STEM. > > > > Barbara Stark has been kind enough to accept to keep her co-chair positio= n > until IETF-112 in order to help Chris in his new role. I am really gratef= ul > to her for this nice gesture and for the additional work to be done in th= e > coming months ;-) > > > > David Schinazi=E2=80=99s role is unchanged as he stays the co-chair for t= he > foreseeable future. > > > > Let=E2=80=99s all keep working on DNSSD ;-) > > > > -=C3=A9ric (responsible AD) > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd > --00000000000085961e05c93a6b92 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you.

Please bear with me while I learn the ropes. This is a long-standing w= orking group with an important problem to solve so I will do my best to ass= ist with that.

Chris

On Tue, 10 Aug 2021 at 17:58, JW =CE=BB John Woodworth <jw@pcthink.com> wrote:
Congratulations and Welcome!

-------- Original message --------
Fro= m: "Eric Vyncke (evyncke)" <evyncke=3D40cisco.com@dmarc.ietf.org><= /div>

Dear DNSSD working group,

=C2=A0

Please welcome Chris Box as the= 3rd co-chair for the DNSSD WG as of today.

=C2=A0

Chris is from Bristol, UK and has spent the last 20 = years delivering mobile internet service, initially on Orange, which became= EE, now part of BT.

He has only been in the IETF community for two years= so is still rapidly learning; you may have seen him in ADD, QUIC or MASQUE= . He's also in this year's NomCom.

At work he manages a small team of designers, and at= home he's raising a teenage daughter with an interest in all aspects o= f STEM.

=C2=A0

Barbara Stark has been kind eno= ugh to accept to keep her co-chair position until IETF-112 in order to help= Chris in his new role. I am really grateful to her for this nice gesture a= nd for the additional work to be done in the coming months ;-)

=C2=A0

David Schinazi=E2=80=99s role i= s unchanged as he stays the co-chair for the foreseeable future.

=C2=A0

Let=E2=80=99s all keep working = on DNSSD ;-)

=C2=A0

-=C3=A9ric (responsible AD)

_____________________________________________= __
dnssd mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/listinfo/dnssd
--00000000000085961e05c93a6b92-- From nobody Wed Aug 11 13:24:47 2021 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F0503A2333 for ; Wed, 11 Aug 2021 13:24:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eero.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 DU-mAcEovKM6 for ; Wed, 11 Aug 2021 13:24:37 -0700 (PDT) Received: from mail-yb1-xb32.google.com (mail-yb1-xb32.google.com [IPv6:2607:f8b0:4864:20::b32]) (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 9632F3A2330 for ; Wed, 11 Aug 2021 13:24:37 -0700 (PDT) Received: by mail-yb1-xb32.google.com with SMTP id z18so7078758ybg.8 for ; Wed, 11 Aug 2021 13:24:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eero.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=K6EhTalF23K7ijYbj89NeyPYLMrwcNazUZFfMYJ16qk=; b=YjwXmpTsTKv0KrU5m5HbMduWSpGzlecufQIVTbc2j99S1PSGR31oi7/N1Gdjf/NMaJ 5JkTmZCIFvcyiu54Kyho3c9AzBaPJ0qyb0GeKZrAt/FLQX8VmYwMoE2TwbMPTc80Q+yJ 8ppez50SfdmGDVQUytj9c3kjUmgFv0ex/0G0A= 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=K6EhTalF23K7ijYbj89NeyPYLMrwcNazUZFfMYJ16qk=; b=tnOI4rqYOVaefSoXGeYVK27rjePN9Dbih/PvwcfWeu7uYTCjw42I+2uX5CO3BZtbna TNVY3qfBZtHMo8d0pbRyMChTnzcMnVIcoyrIao1PkRb/HSk3kkYaH1q8hI5+o+SxUzVT OsxU7AhFyyXnSQ/7vnZ1QdXHOdrc6qM9uqWRF6HIu/ykB/uQoK4QNT7M3+mObUzxjJUq sSF1vfofL3rHjUloxGWkmElziLe4BP9p4464bLe9UYykAHlCuDhUEjA++j9a8rB9++1E 1NPezswwMZFnQDDuYqGPraeBOY61551XGXIhMy5aq7ky/6uWbrTmBq+sO5iXJCdaIYT4 DyZA== X-Gm-Message-State: AOAM5329pMnSv/fV5dht9Wl/gdDEcnPszjNicyyW3fFftYMzf6J27WnF zs/FYTN9fWmP+Wec597HwMRBlT5aTes0DesXBq9NEWaWExE2ROWh X-Google-Smtp-Source: ABdhPJzZ5z2ZpPQoZLO+u8kqEz711nKvZx9mLCmODFZotjnB8x428rYtxkPBZ3uiVJ/FKg/WmE/8D1a1ZrvL639TN7c= X-Received: by 2002:a25:9386:: with SMTP id a6mr351541ybm.218.1628713474818; Wed, 11 Aug 2021 13:24:34 -0700 (PDT) MIME-Version: 1.0 From: Gabe Kassel Date: Wed, 11 Aug 2021 13:24:24 -0700 Message-ID: To: dnssd@ietf.org Content-Type: multipart/alternative; boundary="0000000000001b967c05c94e68dc" Archived-At: Subject: Re: [dnssd] WGLC for draft-ietf-dnssd-srp X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2021 20:24:44 -0000 --0000000000001b967c05c94e68dc Content-Type: text/plain; charset="UTF-8" Hi, I'd like to add my support in favor of publishing the draft-ietf-dnssd-srp. I I have read and reviewed the draft in detail (including the latest version) and I think it is good and ready to be published. I've experienced this proposal in practice through the OpenThread implementation mentioned by Abtin and Jonathan of Google, and can attest it's a fundamentally good and useful tool for product makers and end customers. Thanks -- _______ *Gabe Kassel* Technology Strategist | Office of the CTO *m* 770.490.0431 *e* gabe@eero.com --0000000000001b967c05c94e68dc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I'd like to add my support in favor of publ= ishing the draft-ietf-dnssd-srp. I

I=C2=A0have read and = reviewed the draft in detail (including the latest version) and I think it = is good and ready to be published.

I've experi= enced this proposal in practice through the OpenThread implementation menti= oned by Abtin and Jonathan of Google, and can attest it's a fundamental= ly good and useful tool for product makers and end customers.=C2=A0

Thanks

--
__= _____

Gabe Kassel
Technology Strategist | Office of the CTO

m=C2=A0= 770.490.0431
e=C2=A0=C2=A0gabe@eero.com<= /a>
--0000000000001b967c05c94e68dc-- From nobody Wed Aug 11 13:26:01 2021 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 880B83A2339 for ; Wed, 11 Aug 2021 13:25:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eero.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 RkOfObGc671M for ; Wed, 11 Aug 2021 13:25:04 -0700 (PDT) Received: from mail-yb1-xb29.google.com (mail-yb1-xb29.google.com [IPv6:2607:f8b0:4864:20::b29]) (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 E9B8F3A233F for ; Wed, 11 Aug 2021 13:25:03 -0700 (PDT) Received: by mail-yb1-xb29.google.com with SMTP id e186so7109231ybf.5 for ; Wed, 11 Aug 2021 13:25:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eero.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=kTQEsB6MO8GV8kD3bNE44Bvs5sAgO/kPQXRIw7M5/sA=; b=auaIJLsGvRKTU1QBsVK5wE6aqyLvJUwBTVIvKJ4CA8amsyuDPIoKJ+LSgpnB0mNkhV 1lNniTQx9l2Ii/uxX0plk+GWFqrGHzxa1JhK811Nn0iKRilMEhLS2mglOSTDwoutjle2 4cAKTN4ZuM1W8B89ul4CQ1hYXKf2JUQTjLCRg= 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=kTQEsB6MO8GV8kD3bNE44Bvs5sAgO/kPQXRIw7M5/sA=; b=DvFHZLm2fmaUQkM1inLfVmCLxwV+ZvUdpL3U6S850RnkRjYH6DaA/QwIMwRnCQQvVi DTJ/q0ywTYlx7PSfI/enZMS7WkzhzhQz/icpS3l5eoX5Ln8DVMcliTRxPbCHF2zLLDbP 06q54jWt1DEuYAc7gXOs3C8ZgvKUw/pFNugEOnL77IyVblL+9no4n6Sgm7lPdxSH0THp XV7LMJ5nB34b1ZZq66aV9KPE9YEiEYojjwpyOOj5aDBjoLhbRaKoV/yOf6tZZHX+0HiY 5hbOKQps8RdD0sfCdcr4vE2KxUy8fuiH0LGdtEir02FkvlEPwcSXgXiLRAzjmNZ6nCfZ /Bjg== X-Gm-Message-State: AOAM532qdwWYIDS4NqmfyOO3gOy1OQ3r9zanTaqTbLLt+jqlJbZl0p8z U65unHgTHBQREHRvoIMwAFggfxwHrbmK/1sq2pBG5Am6Rb2UMUXF X-Google-Smtp-Source: ABdhPJyDa6tV306/4dS44Q5rH07x4i6E3wZ++9XySwyhxd41C5Na4TWaozg52e5h3IouekY0XbjnHpjFmJgcuUP2t+o= X-Received: by 2002:a25:5cc:: with SMTP id 195mr355594ybf.304.1628713501684; Wed, 11 Aug 2021 13:25:01 -0700 (PDT) MIME-Version: 1.0 From: Gabe Kassel Date: Wed, 11 Aug 2021 13:24:51 -0700 Message-ID: To: dnssd@ietf.org Content-Type: multipart/alternative; boundary="000000000000b58e9a05c94e69d2" Archived-At: Subject: Re: [dnssd] Adoption call for draft-sctl-advertising-proxy X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2021 20:25:11 -0000 --000000000000b58e9a05c94e69d2 Content-Type: text/plain; charset="UTF-8" I'd like to add my support in favor of publishing the draft-sctl-advertising-proxy. I have read and reviewed the draft in detail (including the latest version) and I think it is good and ready to be published. Echoing my comment on dnssd-srp, this is valuable for device makers and customers and already has clear applications turning the premise into working code. Thanks to Ted and Stuart for driving this forward. -- _______ *Gabe Kassel* Technology Strategist | Office of the CTO *m* 770.490.0431 *e* gabe@eero.com --000000000000b58e9a05c94e69d2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'd like to add my support in favor of publishing the = draft-sctl-advertising-proxy.=C2=A0

I=C2=A0have read and= reviewed the draft in detail (including the latest version) and I think it= is good and ready to be published.

Echoing my com= ment on dnssd-srp, this is valuable for device makers and customers and alr= eady has clear applications turning the premise into=C2=A0working code.=C2= =A0

Thanks to Ted and Stuart for driving this forw= ard.=C2=A0

--
--000000000000b58e9a05c94e69d2-- From nobody Wed Aug 11 13:53:00 2021 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 969583A248C for ; Wed, 11 Aug 2021 13:52:57 -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, 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.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=nanoleaf.me 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 U8SzwDfNiGFq for ; Wed, 11 Aug 2021 13:52:51 -0700 (PDT) Received: from APC01-SG2-obe.outbound.protection.outlook.com (mail-eopbgr1310059.outbound.protection.outlook.com [40.107.131.59]) (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 3FC7E3A248F for ; Wed, 11 Aug 2021 13:52:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=T6F+FmFUKzU5fxIJ3keKwtyPvAWAyqCUsy+DeUTECu1iQWmZdcaeZK2qMuCd73nADqZxq8wpnLyzlIVCfwiaeds5p0dPyHNbdawG6bJ/c8TdaLleeXX7jiuP57rnCMi8PywO1ad4aUvwBL2C3YSgIwPYfrhml3YL8jL+yTABT/y5M3EGYKOEijvpGQxLKAmldPSnJfiQa+Y3yE9MgjDUsWssZcAnm6+Jzxab0OqjOsDTPWk7zV+IitQNzqnDIc/E+TbGJN/zbE2R4OqA/bpR6zcCcLdfAuM2XZeWRZj+xS1PqPCQ4KKgGg2cEibyrrRlE7qukXItSxZshWRYNw4VfA== 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=N6VukMLi5xUr6n/NGUsqLnIy5aViKwXRFRMP4IVxdRA=; b=U3P/iZhYlOh/qYs7tplXGcg8NWoArxJRMzNVPjcZrh6MHHAkzBVuTH+1T0hV9p+mtk4ljTYlMdoDm1nas6Q4jdndeA0romJOOiRT/Alh9TRM8ZkCLuDwaLbRtoPVG1WYPECQZpto+RDWPbpyBoo06Tgtx5ZsYCsHTNEZ2fFz7FOxrFD8pkOAYuB0uqUmCYT+xGl12DN1HMzY1w8i3TIDRbNEtEKN3DrfeSf780D9wRF9ujhoDe8iFbJa+ijht/vafWxgLamhur131JKlTaWNnH4Z0X/j23fvqehHYRE1TF0uPMHA0t8nLpLPKdNbL+XTq8DgliP+LAloHZpLWBi29Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nanoleaf.me; dmarc=pass action=none header.from=nanoleaf.me; dkim=pass header.d=nanoleaf.me; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nanoleaf.me; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=N6VukMLi5xUr6n/NGUsqLnIy5aViKwXRFRMP4IVxdRA=; b=iONv4jOA0tJy1RsvlphD66aULxC48kug7Rnpt9LiK+bHTZoLoxEkc0NWfwWs4O3Emya3CjwX++m5mJPQ+WUFi1x80IaWg+zx3qAnVGkPoFp06oBuc9v0AnS9obVqJ4pAL1OEc523kTEa0+JbRu9Aeg1tA1/bHfoBO+rP0tQUQTk= Received: from SG2PR02MB3782.apcprd02.prod.outlook.com (2603:1096:4:3a::18) by SG2PR02MB4298.apcprd02.prod.outlook.com (2603:1096:0:8::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4415.16; Wed, 11 Aug 2021 20:52:44 +0000 Received: from SG2PR02MB3782.apcprd02.prod.outlook.com ([fe80::79ac:1985:1d74:10b7]) by SG2PR02MB3782.apcprd02.prod.outlook.com ([fe80::79ac:1985:1d74:10b7%7]) with mapi id 15.20.4394.023; Wed, 11 Aug 2021 20:52:44 +0000 From: Nathan Dyck To: Jonathan Hui , David Schinazi CC: DNSSD Thread-Topic: [dnssd] Adoption call for draft-sctl-advertising-proxy Thread-Index: AQHXg/xePoTQL1fYRkyjLdqTrUyhL6taZ7MAgBR1X+g= Date: Wed, 11 Aug 2021 20:52:44 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-CA, en-US Content-Language: en-CA X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none; dmarc.ietf.org; dmarc=none action=none header.from=nanoleaf.me; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 8e690c96-2228-4cb1-deb2-08d95d09f7eb x-ms-traffictypediagnostic: SG2PR02MB4298: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: vJSX/VYkb56ClXi0JwKEOhcwOeTNojFsLNAlWHaz9H9nk1414fE6S7/irSPOOHPcGHJRxYTDD/Ob3EYDNBfvWRx5faDQpu3nlPx2wTtYsXrlY0ZqjoHVayVuTZLwONxbr9cnNYFLCN41u7yoLH/yvL/gY61uqFTFbeguLnhcllYAFLAH1qLEpjubMAZhV4nAy0SnJiS991IoRCYItQFk6Y6FgUOSXxX7nI2yWjm7l91fGkVKOjvgQEnMc1SpqOFU5axRcDVtsyo0Zr6+itdETyXyaacezc6XOhlWUxxVQmgJu4tQMCU/USgWAXgkOF34xo2X+rvVvUf4NlJxq9qCUWtqJiqKM10uiIaBCw3K03qPxtpjzOOMKPDFGt/0G35GrQMzZaM676Ip+OKQiI2HL6Iq/a/ZT+oz8UuLCN7bFCMgHI5/GxLhpKKPtKoSSwJzAKd9qPSv68RVCHdqJG0cgBx7N9N2trDrP8h0Xwp6II94nYmDdm4gJSmPhUH0AzDjCm9iZ8/yUKN6qd7b4ai4bv3im66mPIAY8R0EkES78RgCBeA/9KBRlJxK8J2LtvpUV3O7BZTLAUQKQRDN9/irZMYW+FxsNOZH2FlRrGOkg9rJ0GJEFhCaF1C0MhfRD4ML+WcNBEgk/CvigEz7H5QrZ9WQ68fqTwlS/xKdQkYCH1frdv6z6TLObOTCgMHukd/b7KaBeubzf2DpNa3DWX5uSRdhaGM5VMR3SFytFCIZ+t2+kkmrg+JnfqlBsQfi2X45Q4Y8Pf0sOBQ5bUzvdO8ACTWyc8pi7F/uKHmIdsm/TbQ= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SG2PR02MB3782.apcprd02.prod.outlook.com; PTR:; CAT:NONE; SFS:(376002)(366004)(136003)(346002)(39830400003)(396003)(91956017)(966005)(52536014)(7696005)(4326008)(186003)(2906002)(166002)(26005)(71200400001)(508600001)(110136005)(9326002)(66556008)(66476007)(64756008)(6506007)(8936002)(5660300002)(83380400001)(8676002)(55016002)(53546011)(66946007)(9686003)(38070700005)(33656002)(38100700002)(66574015)(86362001)(122000001)(66446008)(76116006); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?LuBl67KkHocaoxu1VTN14yVKuQQ2zAFfIE+lnTshNshVYmdRIEQw7z8xhfN+?= =?us-ascii?Q?AgqUoNo/Vjp/9VsOwjj8JW8ApJno7GaWBvdAbHLvKqV43si5SKwDS9FwpfwP?= =?us-ascii?Q?/waOHIA++XbLbrGNQd1IhG7tAFpFKM9s06y2j0Q/GslcR+y6zbiTUwlvzlaY?= =?us-ascii?Q?QSu1z3q7bUKl0AbK//qRcV0lQL2XKk8qEae8gc8rUnfIpFa78c6vP8fg/TOO?= =?us-ascii?Q?sW1ZkblaepGLzMiNFWaHJjaYqbPHzgCLxSBADOAzPY79Pt1b33y+R/Hn/Fk3?= =?us-ascii?Q?/VQkGs6pPf+b+1OSvHgGrZrJNNK4q6hTi/QGGO7DXLhNp1uI40POgB2RNGeK?= =?us-ascii?Q?pDcLJuP6x4lGPJsTqRr+te4d1ur7CYfs4gOlh/C66UaPo5sm9RajLuL2b1dI?= =?us-ascii?Q?bUP5HQ9PighSRh0TIun+Ta8bNIQBl9bEIMHlACbRV8LmOirDnpbFYtJfrPqY?= =?us-ascii?Q?X3dYtR1dClg6v4LisgpK1OCxcoOpIHMeSnskLcblCPQwe8D0Z347v4TuP60B?= =?us-ascii?Q?66c/xKWTSJZJsyJDPgipQ/D6ORHWx8Odjot5Akdxjrc+pErfpyaTnCsZNpnb?= =?us-ascii?Q?ny6FbXYTRLx8uyup/LeJLgZcA6bFhTwJx6c5lICNCMfsuJUKeAMtBIpQYH20?= =?us-ascii?Q?aWS+0Ss/g8eJQfkdYNlOlIMkf0dR3fZWAnIAMqcGcqgze5B3BuH1GqXmc4Jr?= =?us-ascii?Q?1olsESOsq9v7VB0qIQuO1sZhxSrymVQAjW9q7b10DGap82gCYNbHiSIejRG6?= =?us-ascii?Q?pxoACyXgxPjB+wPOh51Ddq/YtQKUeAoXxC/KXJAq29YiUt/a0P+BbE7yvFki?= =?us-ascii?Q?+Ir5nS8sLP6fRP4Rko885QJLrech9fz8Ml6pnjF3XTxba+SwnI3zt2ihIafH?= =?us-ascii?Q?oUXkyZ7W3gc7+95/JHjZmgA2WGB5Vu7wKhvM2j8K6Md9gL3J+thCgZBXs32E?= =?us-ascii?Q?zjLsOBnL8ExVPPrMp1GMZzdNsl1NjEJFP+8ARJDga/Wj2q3SK8CCcWSazOQm?= =?us-ascii?Q?hS7DGjswewbWh25p7/gsl9dN+Qu+SuxYR/tbrisP7qB9onamKhOwCLLsh+oL?= =?us-ascii?Q?z4SLrP0jeWK5OXXvnsCYe//OKtm4txNEUUCAeCqK5vsc56TzNp1rLMBxHg3V?= =?us-ascii?Q?HRQF6URD3Zw/hAcLF8zOLMit9V0sdcC0TGqsSsERrYATf4YXcqhrshhapivB?= =?us-ascii?Q?bykThcNtDZTv1tsiWUB/JXLca+wTKeugkOuLz+qu/0DmQtY7sKGNxqf7DBCb?= =?us-ascii?Q?nJylF6qUe9FOf444522k84vE/+TNNYWRc+M3IWtKvnFOUuxY2R+VHFrQoVzR?= =?us-ascii?Q?zb4pmnQm7pfbKjQlpuPc+AX86pJJFUy25JDDQlOgpjgFuw=3D=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_SG2PR02MB378272DF158245211F19D283C0F89SG2PR02MB3782apcp_" MIME-Version: 1.0 X-OriginatorOrg: nanoleaf.me X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SG2PR02MB3782.apcprd02.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8e690c96-2228-4cb1-deb2-08d95d09f7eb X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Aug 2021 20:52:44.2596 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 7d5e26c7-79f4-48a7-a1ce-69187b990cf1 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: slCpugpsFwB4XKzk/kSfU9l6bl2cgZCPC7aeC1OiU1rBq/qFqh+dNg+ZrmNNKnx18JnSTkknR4TEm9OBphx9eQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SG2PR02MB4298 Archived-At: Subject: Re: [dnssd] Adoption call for draft-sctl-advertising-proxy X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2021 20:52:58 -0000 --_000_SG2PR02MB378272DF158245211F19D283C0F89SG2PR02MB3782apcp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, I have read the document and I believe it is largely ready to publish. A f= ew smaller issues (note I previously sent these incorrectly referencing the= separate call for draft-ietf-dnssd-srp). I had to re-read section 2.1.1 a few times to understand all the details. O= ne wording that threw me off a bit was "updates its local idea of the SRP n= amespace". This could be improved by unifying terms from earlier in the doc= ument, which outline this process as "registers the SRP client hostname loc= ally". Further, the section itself feels somewhat non-specific as to how th= ese types of records should be identified so that Advertising Proxy can dis= tinguish when to use the different conflict behaviours. Section 3: "may made" should be "may make" I think. -- Nathan Dyck Chief Product Officer e: nathan@nanoleaf.me | c: +1 (289) 242-0016 The Nanoleaf Team www.nanoleaf.me follow us on twitter @nanoleaf like us on facebook: fb.com/thenanoleaf follow us on instagram @nanoleaf From: dnssd on behalf of Jonathan Hui Date: Thursday, July 29, 2021 at 4:25 PM To: David Schinazi Cc: DNSSD Subject: Re: [dnssd] Adoption call for draft-sctl-advertising-proxy I have reviewed the latest version of this document (draft-sctl-advertising= -proxy-02) and believe this work should be adopted by this working group. The advertising proxy addresses important use cases for Matter and Thread a= nd makes it possible to discover services registered via SRP via mDNS. OpenThread includes an open source implementation of the advertising proxy = - anyone interested in playing with it, see the Thread Border Router Codela= b. Thanks to Ted and Stuart for driving this effort. -- Jonathan Hui On Wed, Jul 28, 2021 at 3:03 PM David Schinazi > wrote: Hi DNSSD enthusiasts, This email starts an official adoption call for draft-sctl-advertising-prox= y by the DNSSD working group. This call asks whether we think that this doc= ument is a good starting point for working group discussion. That means tha= t it is still possible to adopt a document with issues if we believe we'll = be able to solve those issues together as a working group. As such we are a= sking two questions: 1) if you believe that this document is not something the working group sho= uld be working on, please speak up now 2) if you have read the document and would like to discuss it further insid= e the DNSSD working group, please say so as well For this call to succeed, we'll need statements of explicit support from pe= ople who have read the draft. Please send statements in either direction as= responses to this email. This call will be open until 2021-08-15 23:59 UTC= . Thanks, David _______________________________________________ dnssd mailing list dnssd@ietf.org https://www.ietf.org/mailman/listinfo/dnssd --_000_SG2PR02MB378272DF158245211F19D283C0F89SG2PR02MB3782apcp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi All,

 

I have read the document and  I believe it is l= argely ready to publish. A few smaller issues (note I previously sent these= incorrectly referencing the separate call for draft-ietf-dnssd-srp).<= /o:p>

 

I had to re-read section 2.1.1 a few times to u= nderstand all the details. One wording that threw me off a bit was "up= dates its local idea of the SRP namespace". This could be improved by = unifying terms from earlier in the document, which outline this process as "registers the SRP client hostname locally&qu= ot;. Further, the section itself feels somewhat non-specific as to how thes= e types of records should be identified so that Advertising Proxy can disti= nguish when to use the different conflict behaviours.

 

Section 3: "may made" should be "may = make" I think.

 

 

--

Nathan Dyck
Chief Product Officer

e: nathan@nanoleaf.me | c: +1 (289) 2= 42-0016

The Nanoleaf Team
www.nanole= af.me
follow us on twitter @nanoleaf
like us on facebook: fb.com/thenanoleaf
follow us on instagram @nanoleaf

 

From: dnssd <dnssd-bou= nces@ietf.org> on behalf of Jonathan Hui <jonhui=3D40google.com@dmarc= .ietf.org>
Date: Thursday, July 29, 2021 at 4:25 PM
To: David Schinazi <dschinazi.ietf@gmail.com>
Cc: DNSSD <dnssd@ietf.org>
Subject: Re: [dnssd] Adoption call for draft-sctl-advertising-proxy<= o:p>

I have reviewed the latest version of this document = (draft-sctl-advertising-proxy-02) and believe this work should be adopted b= y this working group.

 

The advertising proxy addresses important use cases = for Matter and Thread and makes it possible to discover services regis= tered via SRP via mDNS.

 

OpenThread includes an open source implementation of= the advertising proxy - anyone interested in playing with it, see the = ;Thre= ad Border Router Codelab.

 

Thanks to Ted and Stuart for driving this effort.


--

Jonathan Hui

 

 

 

On Wed, Jul 28, 2021 at 3:03 PM David Schinazi <<= a href=3D"mailto:dschinazi.ietf@gmail.com">dschinazi.ietf@gmail.com>= wrote:

Hi DNSSD enthusiasts,

 

This email starts an official adoption call for = ;draft-sctl-advertising-proxy by the DNSSD working group. This call asks wh= ether we think that this document is a good starting point for working grou= p discussion. That means that it is still possible to adopt a document with issues if we believe we'll be able to so= lve those issues together as a working group. As such we are asking two que= stions:

 

1) if you believe that this document is not som= ething the working group should be working on, please speak up now

 

2) if you have read the document and would like to d= iscuss it further inside the DNSSD working group, please say so as wel= l

 

For this call to succeed, we'll need statements of e= xplicit support from people who have read the draft. Please send statements= in either direction as responses to this email. This call will be open unt= il 2021-08-15 23:59 UTC.

 

Thanks,

David

_______________________________________________
dnssd mailing list
dnssd@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/dnssd

--_000_SG2PR02MB378272DF158245211F19D283C0F89SG2PR02MB3782apcp_-- From m_roman@apple.com Wed Aug 11 17:35:14 2021 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 296CE3A2B49 for ; Wed, 11 Aug 2021 17:35:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, 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_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=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 Q7dzb9a7tGjo for ; Wed, 11 Aug 2021 17:35:11 -0700 (PDT) Received: from rn-mailsvcp-ppex-lapp44.apple.com (rn-mailsvcp-ppex-lapp44.rno.apple.com [17.179.253.48]) (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 A38963A2B3B for ; Wed, 11 Aug 2021 17:35:11 -0700 (PDT) Received: from pps.filterd (rn-mailsvcp-ppex-lapp44.rno.apple.com [127.0.0.1]) by rn-mailsvcp-ppex-lapp44.rno.apple.com (8.16.1.2/8.16.1.2) with SMTP id 17C0X1je001068 for ; Wed, 11 Aug 2021 17:35:11 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : content-type : content-transfer-encoding : mime-version : subject : message-id : date : to; s=20180706; bh=H+MbD2EFMNEkIdSMuzEB7s54y1TWyUaHG18c5t03olg=; b=D9X+V2fZY+PSEa3GSOoG5wWLI71ptWphEmU8LuwMjCZt6hLto1GVVtJn9CVKEjxMJYlL yTsBU0V/lHkT3ib4EvHshfxh8tZbpIK/05LPGSDKNNf04dZevXjYBhrkj1S6EdkxKt0I nWltO64Gw0OHHf4VEs2ZSVTK0MO1a6ruC0xHbsmGv0EqbsQViv7pTAQ3JiSx6VVM8amx 2z+908DtKrD074CjJgm8tT5DcuomJEMANm62mZBaNE5Krl1W/72Ld9MdcbSPqlPqMaug WvefiQK7II4lk8zZnruy6ppzYrgKN2IQ4O4g5YcvROIoze58mrHREwgMmSRhE3MlqNVB Qg== Received: from rn-mailsvcp-mta-lapp01.rno.apple.com (rn-mailsvcp-mta-lapp01.rno.apple.com [10.225.203.149]) by rn-mailsvcp-ppex-lapp44.rno.apple.com with ESMTP id 3a9np9yhc1-5 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Wed, 11 Aug 2021 17:35:11 -0700 Received: from rn-mailsvcp-mmp-lapp04.rno.apple.com (rn-mailsvcp-mmp-lapp04.rno.apple.com [17.179.253.17]) by rn-mailsvcp-mta-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.9.20210415 64bit (built Apr 15 2021)) with ESMTPS id <0QXP00LWVAYN4AH0@rn-mailsvcp-mta-lapp01.rno.apple.com> for dnssd@ietf.org; Wed, 11 Aug 2021 17:35:11 -0700 (PDT) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp04.rno.apple.com by rn-mailsvcp-mmp-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.9.20210415 64bit (built Apr 15 2021)) id <0QXP00C00AW6FR00@rn-mailsvcp-mmp-lapp04.rno.apple.com> for dnssd@ietf.org; Wed, 11 Aug 2021 17:35:11 -0700 (PDT) X-Va-A: X-Va-T-CD: 9cb739ef05cf90679a21e4dc783575a9 X-Va-E-CD: 23823fc4808a3f98775afae3777cf319 X-Va-R-CD: c0cfb04f709012e3716ba1c6e9960d32 X-Va-CD: 0 X-Va-ID: 872a13f2-5d55-4746-acd1-3b5f85db9f5c X-V-A: X-V-T-CD: 9cb739ef05cf90679a21e4dc783575a9 X-V-E-CD: 23823fc4808a3f98775afae3777cf319 X-V-R-CD: c0cfb04f709012e3716ba1c6e9960d32 X-V-CD: 0 X-V-ID: 030089d6-486a-4030-8612-ce16f6403469 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-08-11_08:2021-08-11, 2021-08-11 signatures=0 Received: from smtpclient.apple (unknown [17.11.88.88]) by rn-mailsvcp-mmp-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.9.20210415 64bit (built Apr 15 2021)) with ESMTPSA id <0QXP00Z91AYM0700@rn-mailsvcp-mmp-lapp04.rno.apple.com> for dnssd@ietf.org; Wed, 11 Aug 2021 17:35:10 -0700 (PDT) From: Manuel Roman Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable MIME-version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Message-id: Date: Wed, 11 Aug 2021 17:35:10 -0700 To: dnssd@ietf.org X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-08-11_08:2021-08-11, 2021-08-11 signatures=0 Archived-At: Subject: [dnssd] WGLC for draft-ietf-dnssd-srp X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2021 00:36:34 -0000 Hi, I have read the latest version of this document = (draft-ietf-dnssd-srp-10) and I believe it is ready for publication. I have been exposed to this protocol by means of the mDNSResponder = implementation. The functionality provided is key to the success of any = application protocol built on top of Thread that requires service = discovery such as CHIP Regards, Manuel= From nobody Wed Aug 11 17:53:53 2021 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F48F3A2D39 for ; Wed, 11 Aug 2021 17:53:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.554 X-Spam-Level: X-Spam-Status: No, score=-2.554 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, 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] 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 30XiWeqndrR3 for ; Wed, 11 Aug 2021 17:53:46 -0700 (PDT) Received: from ma1-aaemail-dr-lapp03.apple.com (ma1-aaemail-dr-lapp03.apple.com [17.171.2.72]) (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 A9E063A2D36 for ; Wed, 11 Aug 2021 17:53:46 -0700 (PDT) Received: from pps.filterd (ma1-aaemail-dr-lapp03.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp03.apple.com (8.16.0.42/8.16.0.42) with SMTP id 17C0irb1018908 for ; Wed, 11 Aug 2021 17:53:45 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : content-type : content-transfer-encoding : mime-version : subject : message-id : date : to; s=20180706; bh=qEY2vw6fUmXbjX/QTKGyv8pVaowLdAvZhujGcwunEYw=; b=pCri3bRX0VsQkYZyfpzf9OUbTTF1QRGo3J0E91D87EKhrl4/bMclDr4OMlDpaOe6Di7h wqLZV4s37KcLX1oD2eU9Qv3Kxy9ZBn0/6+DCGlkpp/8lMEQoIqnMMrXVK5f55o+nZ6zs gKX2lD9JPai740wniAXgJPsCXltjf2Zp59DwSAJN4mQkV+Vqoi2k5o6MXQBi/NKdOv91 jQFQ22N7/Z3MWjwskuuQgTrwijSe/cJk4ugluc0G2mjcIVazuti54G49+CWiFXcka8/P 0YkSaelRCjctPkhYjIBHgGsWcrWMMylsuVWZx+jwPSfcGG0lOw2unzoCBdrqz+5BBO1g kg== Received: from rn-mailsvcp-mta-lapp03.rno.apple.com (rn-mailsvcp-mta-lapp03.rno.apple.com [10.225.203.151]) by ma1-aaemail-dr-lapp03.apple.com with ESMTP id 3a9s5wfj7q-9 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Wed, 11 Aug 2021 17:53:45 -0700 Received: from rn-mailsvcp-mmp-lapp04.rno.apple.com (rn-mailsvcp-mmp-lapp04.rno.apple.com [17.179.253.17]) by rn-mailsvcp-mta-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.9.20210415 64bit (built Apr 15 2021)) with ESMTPS id <0QXP00GYKBTJ4D00@rn-mailsvcp-mta-lapp03.rno.apple.com> for dnssd@ietf.org; Wed, 11 Aug 2021 17:53:43 -0700 (PDT) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp04.rno.apple.com by rn-mailsvcp-mmp-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.9.20210415 64bit (built Apr 15 2021)) id <0QXP00S00BRWM000@rn-mailsvcp-mmp-lapp04.rno.apple.com> for dnssd@ietf.org; Wed, 11 Aug 2021 17:53:43 -0700 (PDT) X-Va-A: X-Va-T-CD: 9cb739ef05cf90679a21e4dc783575a9 X-Va-E-CD: acaed2c78d1734af853dd13a36dce8df X-Va-R-CD: 43f366e4da647888607e91b66b0f0a26 X-Va-CD: 0 X-Va-ID: 9fb9a547-31c5-4c6c-b062-7f69b608c428 X-V-A: X-V-T-CD: 9cb739ef05cf90679a21e4dc783575a9 X-V-E-CD: acaed2c78d1734af853dd13a36dce8df X-V-R-CD: 43f366e4da647888607e91b66b0f0a26 X-V-CD: 0 X-V-ID: 16953f13-f492-45e6-b94c-b7bb4eaaf501 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-08-11_08:2021-08-11, 2021-08-11 signatures=0 Received: from smtpclient.apple (unknown [17.11.88.88]) by rn-mailsvcp-mmp-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.9.20210415 64bit (built Apr 15 2021)) with ESMTPSA id <0QXP004B8BTJL400@rn-mailsvcp-mmp-lapp04.rno.apple.com> for dnssd@ietf.org; Wed, 11 Aug 2021 17:53:43 -0700 (PDT) From: Manuel Roman Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable MIME-version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Message-id: Date: Wed, 11 Aug 2021 17:53:43 -0700 To: dnssd@ietf.org X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-08-11_08:2021-08-11, 2021-08-11 signatures=0 Archived-At: Subject: [dnssd] Adoption call for draft-sctl-advertising-proxy X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2021 00:53:52 -0000 I have read this document in detail (draft-sctl-advertising-proxy-02) = and I would like to support its publication. The advertising proxy is a key element to support service registration = and discovery in Thread networks. I am familiar with the functionality as I have been using the = mDNSResponder implementation for several months Regards, Manuel Roman From nobody Thu Aug 12 00:34:03 2021 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00CAA3A3A96 for ; Thu, 12 Aug 2021 00:34:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.098 X-Spam-Level: X-Spam-Status: No, score=-17.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.499, 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, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=no 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 AN2CUkpBeod3 for ; Thu, 12 Aug 2021 00:33:59 -0700 (PDT) Received: from mail-pj1-x102b.google.com (mail-pj1-x102b.google.com [IPv6:2607:f8b0:4864:20::102b]) (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 CA2E53A3A8F for ; Thu, 12 Aug 2021 00:33:59 -0700 (PDT) Received: by mail-pj1-x102b.google.com with SMTP id cp15-20020a17090afb8fb029017891959dcbso13855623pjb.2 for ; Thu, 12 Aug 2021 00:33:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=pY4bmulg160CAmKMtY2+tNPC9i0lKg3aX9D5jxftIM4=; b=TAU2062rcTMXY45VuL5i+VXj5RbM4B8FnXVhe5/R+sgTKGoeSxfHnQ7NMrjylJ/TZ6 2tiv/Q+8XE3YxQjxatNF+D++BNFk7zs9NjVReIA1hviECeiiopAUaFnYZCfiRH5FnSu1 KV+hDtLxsUhLEMUGMkdRIgTFDt65/Q6qR+kIg5NHNEdsF0E/6PNSCewPBI0kZTIesIYm sI13x/kC34V6dKh+flYjpD16Q1hmSSICCglklfU/hOFW16ldMkuuQ9TQW5tpW7tG/WMa dxQbf/JOd7qKTdqgTb2/j9XsFTHqo5Vsdb79DZ7NeLav/b5luPZiQXnCDB9OGUfE/Cfg O82g== 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=pY4bmulg160CAmKMtY2+tNPC9i0lKg3aX9D5jxftIM4=; b=KEx+BmJCVML23anIAKgQLckdiAojaTBFka5X+Wf35d8d2RNw1copsifidfZKL133hi kDhINqhwvsn4qCIA2RPEKHevUpmkM4cCzVFNnw2G7XzB9sCYg3TuIrgFgK7l3HDvTS/J Mc1JeyFyyPFXwYcuqRkWre3dHI1KsjdOD2skHi3TernANK82nlayLdR1LsmdP0P3ga3q qot2g1A+e0TKBEU0bR4cq7TvC60pv8plh0BcKoOBljTBmtd5yCEmwdY7UZf/e0f1bJp8 2z3y2xUadytIGJHgQasip4yHYv+Eo8HuYFBehfM+WwoOAbpQbyPO99TM6juZCNh4i4aE ijQg== X-Gm-Message-State: AOAM530jP4TQJ0JtgfHQpp++Ztcs75RzP+u5yC08GhmHyXLQp7Ag8kZH QpffNtzu9Hs83ub86LkqKTKx/FzoMCXLK2TcYMwGXf9weMkEoQ== X-Google-Smtp-Source: ABdhPJwhLiOT9UFwn8PIJr/zz/hWRmRIR6/mF6W3iEWXsPYj52uJvLjo/3bDX751JxvXN8vY+z9yAaObfZinq0lYRwQ= X-Received: by 2002:a17:902:a50f:b029:11a:b033:e158 with SMTP id s15-20020a170902a50fb029011ab033e158mr2467950plq.26.1628753637160; Thu, 12 Aug 2021 00:33:57 -0700 (PDT) MIME-Version: 1.0 From: Kangping Dong Date: Thu, 12 Aug 2021 15:33:20 +0800 Message-ID: To: DNSSD Content-Type: multipart/alternative; boundary="000000000000f8ebab05c957c139" Archived-At: Subject: [dnssd] WGLC for draft-ietf-dnssd-srp X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2021 07:34:01 -0000 --000000000000f8ebab05c957c139 Content-Type: text/plain; charset="UTF-8" Hi, I read the latest version of the SRP draft (draft-ietf-dnssd-srp-10) and I think it is ready for publication. I did make very detailed review of earlier version of this document and created a server side implementation in OpenThread code base ( https://github.com/openthread/openthread/blob/main/src/core/net/srp_server.hpp ). Current SRP draft includes feedbacks and enhancements that we found during the implementation and I believe it is now providing great scalability and improving performance on at least Thread networks. This is one of the key technologies for application protocols that relies on service discovery across Thread and Wi-Fi/Ethernet works. BRs, Kangping --000000000000f8ebab05c957c139 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I read the latest version of the SR= P draft (draft-ietf-dnssd-srp-10) and I think it is ready for publication.<= /div>

I did make very detailed review of earlier version= of this document and created a server side implementation
Current SRP draft in= cludes feedbacks and enhancements that we found during=C2=A0the=C2=A0implem= entation=C2=A0and I believe
it is now providing great scalability= and improving performance on at least Thread networks. This is one of the = key
technologies for application protocols that relies on service= discovery across=C2=A0Thread and Wi-Fi/Ethernet works.


BRs,
Kangping


<= /div>

--000000000000f8ebab05c957c139-- From nobody Thu Aug 12 00:45:28 2021 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B4F13A3B0F for ; Thu, 12 Aug 2021 00:45:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.097 X-Spam-Level: X-Spam-Status: No, score=-17.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.499, 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, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, 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=no 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 7cQJVs52WuOa for ; Thu, 12 Aug 2021 00:45:22 -0700 (PDT) Received: from mail-pl1-x62c.google.com (mail-pl1-x62c.google.com [IPv6:2607:f8b0:4864:20::62c]) (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 0F0743A3B10 for ; Thu, 12 Aug 2021 00:45:22 -0700 (PDT) Received: by mail-pl1-x62c.google.com with SMTP id e19so6176281pla.10 for ; Thu, 12 Aug 2021 00:45:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=LaEZNkQiwzF2WXGHN5B4wDl4OPaq6bES26OHWDryRCs=; b=Kl2mxqHojHqA5Mo3/2uU7nuPWI4ZBpSQaLururWOoVgz1MCz/h+bjn+FrTroxmbv0F uPcsXF5z2WyOipj4/5dMHndUX32PBm8qxon+HPZvBC4fovnzPE7jltTILNchKix3EhsG 6yXHv47PRG7b5ClassuHGTWfLVqvyPAS6euK0g5hUX9mlbmkvRWXTdj+fg2sEO1GVhj1 Q4PrOc8tVrfoP314MnZwMM6HRyL6YEvMCPkBTQc+PJH6fIpn+OEXsE4BBbQ+2GdtByAi Du1V4VwXQZRGS6/fJQgH02EMfLjE5kO9N2lyQd55e5QN6oWymKbLe4ZryQpoW36KUCgA a5QA== 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=LaEZNkQiwzF2WXGHN5B4wDl4OPaq6bES26OHWDryRCs=; b=kK/BJ9I7tVszlHNOG3Xaemx+Gzof8p6kzY9G6azckd7IO/fL1BjqQeI8teyqrMRo0C 97TYdyOY7zlPNLjhSeqtrTolW4RQ5B9RL/4fbS9KSKCmo88p6ZtZqGv80k3DIaKz1KFe IdgwdfSqfZUS+KIhiS5o85WGNSlKjqxuNqhCriq27rXauqqQ/oGp/abr4vqS68l6iWQz +LLEQdj4YYiQRYZKugtXx9cax3ggicpxF37Gezz8FoNOK/gS4iHeSAzJy3yclWZoCtdb WI89D1xXoaVD54zYpl3OORR2GVibDWk4bggBPAPqHCNqq4xadOoKtxA/Ob3cAZdkiDoV wV5w== X-Gm-Message-State: AOAM5317JKDK5vvDlfNEqC/GJlnZv2PVyAY8mfYnyB/ibHQtz7Gs+2H3 AvvaYITG5ZUvQtIO8N9bGOreOZFaL4DFLEvUSva83aB5qUDhZw== X-Google-Smtp-Source: ABdhPJyZBR3VBDRHKXjw54U3d21Gi7WYv7yLVuOvPCmRVDSh4+E1M6vmIcYGFfxa/x1U2eD6/jqWhJQ+/wIg7NVyS7s= X-Received: by 2002:a62:584:0:b029:32e:3b57:a1c6 with SMTP id 126-20020a6205840000b029032e3b57a1c6mr2888120pff.13.1628754319661; Thu, 12 Aug 2021 00:45:19 -0700 (PDT) MIME-Version: 1.0 From: Kangping Dong Date: Thu, 12 Aug 2021 15:44:43 +0800 Message-ID: To: DNSSD Content-Type: multipart/alternative; boundary="000000000000a6fa2305c957ea6a" Archived-At: Subject: [dnssd] Adoption call for draft-sctl-advertising-proxy X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2021 07:45:27 -0000 --000000000000a6fa2305c957ea6a Content-Type: text/plain; charset="UTF-8" Hi, I read the latest version of draft-sctl-advertising-proxy (i.e. draft-sctl-advertising-proxy-02) and I'd like to support the adoption of this document. We had an implementation of the advertising proxy in the OpenThread Border Router codebase ( https://github.com/openthread/ot-br-posix/blob/main/src/agent/advertising_proxy.hpp) and it works great to publish unicast SRP services from Thread networks on the adjacent Wi-Fi links. This is one of the key technology that provides mDNS service discovery for DNS services registered from Thread networks. It is also key to success of applications that relies on mDNS service discovery, for example, the matter project . BRs, Kangping --000000000000a6fa2305c957ea6a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I read the latest version of=C2=A0d= raft-sctl-advertising-proxy (i.e.=C2=A0draft-sctl-advertising-proxy-02) and= I'd like to
support the adoption=C2=A0of this document.

We had an implementation of the advertising proxy in t= he OpenThread Border Router
great to publish unicast SRP services from T= hread networks on the adjacent Wi-Fi links. This is one of the key
technology that provides mDNS service discovery for DNS services register= ed from Thread networks. It is also
key to success of application= s that relies on mDNS service discovery, for example, the matter project.


BRs,
Kangping
--000000000000a6fa2305c957ea6a-- From nobody Thu Aug 12 03:31:55 2021 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EA703A03F2 for ; Thu, 12 Aug 2021 03:31:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.097 X-Spam-Level: X-Spam-Status: No, score=-18.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.499, 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 AkGJBT40fJJM for ; Thu, 12 Aug 2021 03:31:38 -0700 (PDT) Received: from mail-yb1-xb32.google.com (mail-yb1-xb32.google.com [IPv6:2607:f8b0:4864:20::b32]) (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 17C813A061B for ; Thu, 12 Aug 2021 03:31:38 -0700 (PDT) Received: by mail-yb1-xb32.google.com with SMTP id z18so10698159ybg.8 for ; Thu, 12 Aug 2021 03:31:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=2wbN1BTiPCwEvbxTe7APQ9SEP5S9t/Qk/EOy31WZvGo=; b=nwo59v0xTxHXVpl4ExUXQfCYz8e/u1Zxl1Vuf7i/DYNpZY+fCCZ3UuTO5261R+ertT L3xuglGxa2TlukwXJHF5A2XjYewKrOa53uCCZhRD1GYSUXKGVyZGn/89mT9bbftQpRYh MzjdSspH5g2FFxuRZ7HT+qDB277PawJ3lcMFmC5SjJoFqOieqfyMlmCV+uKtQrVP7La2 htq6vgs+bFk9ukK2RnjFsVF0RbzMOadS5qszuJx9Ku1YZTe44Imu0hgpY9iy32kWCPAm irhiyix1PZDEYsT2KKZzpLcBWhIppgE1yJhl8toV8cwyCy4lKtUrXbH0VKmVPf07A31i WWZQ== 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=2wbN1BTiPCwEvbxTe7APQ9SEP5S9t/Qk/EOy31WZvGo=; b=rrglXL5h/vrfhWWXm6bUvj/dpQIzFSx1+G/S843cVRopLIUWuQzou3iQQ2nvExuQKL WfXV0bM1wErXiySezm2SaVyHl53w+RxYJVIbzn3naLl46I0lsHLmgHhSbDHXFqYIBXdZ 3J8wFHaL0vfy/qIgzIxFZLr6/9+dd4unoNjYMEugH4ABylmRQzuocZ9/nCgD5BpuAPzT 7jFjxbERAHrQL2LwClpNjv/EpXJkb6vtxWPnmJwvaMiHGAQQJZDCfVxhTdkKthXWIAXJ JEvhhiTDQ2bnPctgRXfW8PAK6gL66wRVQ6J1xG0XFMNyokXTdgTZ9uSOQDP+SD6xhtFy 7jZg== X-Gm-Message-State: AOAM532EhmWouca68ACd+ucLf2bOeEShgM4A0E6rZ+Da588NVWMum+iO DK+x4U9k7p6B6IGYtpfuGObOqpP5x3U51/BgNEmdo9JRAczIOQ== X-Google-Smtp-Source: ABdhPJyRq4/xVJO7VTs6zz+5lRA48Jvqylu3LWYqxoOZI/0wWd3kxWaVvQOCNiIWFvNswjxoAF9CMqrguGERrQI+JMI= X-Received: by 2002:a25:aaa4:: with SMTP id t33mr3488411ybi.256.1628764296044; Thu, 12 Aug 2021 03:31:36 -0700 (PDT) MIME-Version: 1.0 From: Martin Turon Date: Thu, 12 Aug 2021 03:31:24 -0700 Message-ID: To: dnssd@ietf.org Content-Type: multipart/alternative; boundary="0000000000004ad47b05c95a3d27" Archived-At: Subject: Re: [dnssd] Adoption call for draft-sctl-advertising-proxy X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2021 10:31:54 -0000 --0000000000004ad47b05c95a3d27 Content-Type: text/plain; charset="UTF-8" Hi All, I'm writing to offer my support for adopting draft-sctl-advertising-proxy-02 by the workgroup. I have read and reviewed the document and view it as ready to publish. The advertising proxy provides an important optimization for a foundational IoT use case -- bridging legacy multicast DNS clients on WiFi with unicast SRP clients on a stub network such as Thread, and allowing seamless service discovery across both scopes. As mentioned by others, the Matter standard is planning to leverage this work heavily, and an open source implementation of the work based on this draft is underway now in that forum. A few minor comments to note from this final review: 1) *Editorial*: "provide with" is awkward phrasing. Remove "with" or possibly add a word/object. In order to address this problem, it may be advisable to *provide with* a way for the advertising proxy to inform the mDNS service that it should continue to advertise the name that is in conflict, rather than ceasing to do so when the conflict is detected. 2) *Editorial*: as Nathan mentioned, "may made" should be "may make" in the Security Considerations section: An Advertising Proxy *may made* data visible to eavesdroppers on the configured multicast-capable link(s). 3) *Question:* Regarding "2.1.1 . Name Conflicts in Managed Namespaces" Is the case of a device conflicting with itself handled? Specifically, imagine a dual-radio device (WiFi and Thread) which for some reason migrates from being an SRP client to an mDNS client or vice versa. When the device tries to re-register its services to direct to its new, renumbered IP addresses, could its own stale records on the proxy possibly lock it out? Thank you for the good work here, Stuart and Ted! Regards, Martin _____________________________ Martin Turon | Google --0000000000004ad47b05c95a3d27 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 
Hi All,

I'm writing to offer my support for adopting=C2=A0draft-sctl-advertising-proxy-02=C2=A0by the workgroup.=C2=A0 I hav=
e read and reviewed the document and view it as ready to publish.

The advertising proxy provides =
an important optimization for a foundational IoT use case -- bridging legac=
y multicast DNS clients on WiFi with unicast SRP clients on a stub network =
such as Thread, and allowing seamless service discovery across both scopes.=
=C2=A0 As mentioned by others, the Matter standard is planning to leverage this work heavily, and an=C2=
=A0open source =
implementation of the work based on this draft is underway now in that =
forum.

A few minor com=
ments to note from this final review:

1) Editorial:=C2=
=A0"provide with" is awkw=
ard phrasing. Remove "with" o=
r possibly add a word/object.

In order to address this problem, it may be advisable to provide with=

  =
 a way for the advertising proxy to inform the mDNS service that it<=
/pre>
   should c=
ontinue to advertise the name that is in conflict, rather
   than ceasing to do=
 so when the conflict is detected.

2)  Editorial:=C2=A0as Nathan mentioned, "may made" should be "may make=
" in the Security Considerations section:

   An Advertising Proxy may ma=
de data visible to eavesdroppers on the
   configured multicast-capable link(s).

3) Question:=
 Regarding "2.1.1.  Name Conflicts in Managed Namespace=
s"


Is the case of a device conflicting with itself handled? Specifica=
lly, imagine a dual-radio device (WiFi and Thread) which for some reason mi=
grates from being an SRP client to an mDNS client or vice versa.=C2=A0 When=
 the device tries to re-register its services to direct to its new, renumbe=
red IP addresses, could its own stale records on the proxy possibly lock it=
 out?
=


<=
/span>
Thank you for the good work here, Stuart and Ted!

=

Regards,
Martin









_____________________________
Martin Turon =C2=A0| =C2=A0Google

=
--0000000000004ad47b05c95a3d27-- From simonlin@google.com Thu Aug 12 01:33:15 2021 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62E5D3A3CBA for ; Thu, 12 Aug 2021 01:33:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.098 X-Spam-Level: X-Spam-Status: No, score=-18.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.499, 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, 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 Cuo-tjuO7mx2 for ; Thu, 12 Aug 2021 01:33:13 -0700 (PDT) Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (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 8466C3A3CB4 for ; Thu, 12 Aug 2021 01:33:13 -0700 (PDT) Received: by mail-lf1-x12e.google.com with SMTP id p38so12173430lfa.0 for ; Thu, 12 Aug 2021 01:33:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=Wpp2G+o59xANxQ0a06OZdvZRcyeJ89clZsEzCclM3Bo=; b=pwztyvPDDlpDXmK/xyzJGN5elTk5EvjXVYx8RUV+AMXZCCC7/CBnALuni/53iN6wbx E5TJXHO9FLT7ZeifIiUiSklbL7dN3Wp8wyy5e7yceLb64njCQtj5RoSIzmksFcpfvIso J15fenPvX86O9bcoj2Bx5Z8P2jQ/Wkad34QQ4WKTlIwDTF+Bvg7y6HlOD3PaiESbSPrn VpvHMyclZOBI3e5d4nVSXoIjB2eiCaHp78BOiSAjIhIAArbXFTaKQ8WwEB7nGx0i4zll d9j2bNO5oXH8EF4RWrOVKcUhQW0zfcUinACftHYsCJQnUegdijewP7gtJUF8pU/EY5CM Lz8w== 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=Wpp2G+o59xANxQ0a06OZdvZRcyeJ89clZsEzCclM3Bo=; b=aA8aD+mel/jzchoeMJs9Ql+YuppUc2wvd6l2quCyg+Pm8hCW4CkuJA+tTwPsH05AG8 7cMKIcUvDPPuYW6VV9cHCM/OyDpjwkvhZ76EpZe8bzD1sl4VshkkS8X4rx4XWMKHnz6r ftp37Kf4VuFsIOWJjIXpJcfhnu0J3O+bivbYGbfZbEbOS8Mil0PS3Xt7IDccVPT8cqha RGqZGvk2Wi3PE3jLmGmwAKu674G4nu03s313SYc4x36QhdtNwasFeUGw71AktII/68ce pLVjAicxmUeFPGalSslUsT58X8pbn5STKDXJStFQSpM07r8HWJ2hzOzpYGS7lJQhRXsT KE0A== X-Gm-Message-State: AOAM533Ia3hjC8aofuVEFRIJoMYSL/snnkuocjjSYD/G/o4617hU9myV c+OUkk6m4dTg5rmjUi1xcx4YiRXxcz7dIXGtN/AAu9wFKTPI+MZG X-Google-Smtp-Source: ABdhPJxKDtkULT1fDUk45w/BLcSZZWKY6kaqLgk6xiFGXRXi+8E0zHKgJqOT/Ad6cgnfX4eOmDbRFrPW/9Zykt3J5Ro= X-Received: by 2002:ac2:5dc1:: with SMTP id x1mr1683932lfq.209.1628757189567; Thu, 12 Aug 2021 01:33:09 -0700 (PDT) MIME-Version: 1.0 From: Simon Lin Date: Thu, 12 Aug 2021 16:32:58 +0800 Message-ID: To: dnssd@ietf.org Content-Type: multipart/alternative; boundary="000000000000b65e0905c9589599" Archived-At: X-Mailman-Approved-At: Thu, 12 Aug 2021 05:42:06 -0700 Subject: Re: [dnssd] WGLC for draft-ietf-dnssd-srp X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2021 08:35:21 -0000 --000000000000b65e0905c9589599 Content-Type: text/plain; charset="UTF-8" Hi, I'd like to add my support for publishing the draft-ietf-dnssd-srp. We have been using the OpenThread SRP implementation for Thread Border Routers for a period of time and found that this technique is vital for bridging the gap between Thread networks and the Infrastructure network. We can also see the potential of utilizing SRP within the WiFi networks to reduce inefficient multicast traffic. Regards, Simon --000000000000b65e0905c9589599 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,=C2=A0

I'd like to add my suppor= t for publishing the=C2=A0draft-ietf-dnssd-srp.=C2=A0

<= div>We have been using the OpenThread SRP implementation for Thread Border = Routers for a period of time and found that this technique is vital for bri= dging the gap between Thread networks and the Infrastructure network.
=

We can also see the potential of utilizing SRP within t= he WiFi networks to reduce inefficient multicast traffic.=C2=A0
<= br>
Regards,=C2=A0
Simon
--000000000000b65e0905c9589599-- From nobody Thu Aug 12 07:58:22 2021 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC8D63A15D7 for ; Thu, 12 Aug 2021 07:58:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 IFUvtqCDNJHw for ; Thu, 12 Aug 2021 07:58:08 -0700 (PDT) Received: from mail-ot1-x32d.google.com (mail-ot1-x32d.google.com [IPv6:2607:f8b0:4864:20::32d]) (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 608A23A156F for ; Thu, 12 Aug 2021 07:58:03 -0700 (PDT) Received: by mail-ot1-x32d.google.com with SMTP id v10-20020a9d604a0000b02904fa9613b53dso8057325otj.6 for ; Thu, 12 Aug 2021 07:58:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:in-reply-to:references:mime-version:date:message-id:subject:to; bh=KwXLFHf4g2zevCC+y7W49iJ/2pzHzNV6AMW/5wBEeq8=; b=ue5kWDBdcsuh9zQFXVvOS0XxzmXP9OSxsR2XOgnlDfd6+7PSfeWhDMxaJULi3US/Dj sxuMQ6cqInB9tERkO0OoozQ9nvYgb6IYcKzKHW+aSkvJMMtI1j+43q5RM/UrpdYc3IYm 27iDcA7rQg5hvDFTEn3nX3EdWzqz+J/o5I1Esx699E8wY9mWd3TQWZZfIkcg0zp8AEEO E3AhSPNPHDPJ32Jnvsd6kvwnrvCOE6hzyKvx5/I7YpmaBbVlPOc+OW2ZzQnKvqKSEUFo YCwTNwtsvShEom5xwfWTjyCOMJ1wlAaWxaM0D2wn+5XPI9Xy+1BgeF9htrk6EMHOIdqg hdBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to; bh=KwXLFHf4g2zevCC+y7W49iJ/2pzHzNV6AMW/5wBEeq8=; b=BuJzj370MVrtWe1g19aouKMQ72jBEoCf3nlWyEehHJqpvrGU9UhVqwYtVa954DPJhW fjYQFGFJe4cEX4UB2OD8jLFnjSf74Mg2UuWlqmtOq41qzDlgkVT06RKpDtBZMkxM0Roc 8jfXeQOlMoi8MOK/trtdRhi1Vq89R4rcUhhVt28hIc42er0Xry/yvrPFRXY/M4cs76Zx tI07e1TiX2KOYSKFWcbyfbjCHWu//UIjr9kcpDPu6fuuN6zDkUhuL6CILSj+rHNtsuL5 THPx8UpPygy0UEBHYI3/NUUKLl8m2bhPaFyoD+Lpsil5KmcNorNHpHvu4tEYKqRTDiGP 4m0w== X-Gm-Message-State: AOAM533asieCabHtQE2dU5/sXOUVTpliGHBPEMMJ2hrThGxLcPR5GkN2 V1jQokRrk4eMdHBrhEB/Z5wG4pUz7eV3vHdA2GI4ndjf9Rj1Lg== X-Google-Smtp-Source: ABdhPJyXD4025RNIHetV7SJ/FuorWur1DZkIxP6yWyQRiyIDusoI9C2VXhjKgpi1P6F5ZpmxNBazlUbJeaztOp8yhIY= X-Received: by 2002:a9d:450c:: with SMTP id w12mr168015ote.18.1628780282054; Thu, 12 Aug 2021 07:58:02 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 12 Aug 2021 07:58:01 -0700 From: Ted Lemon In-Reply-To: References: MIME-Version: 1.0 Date: Thu, 12 Aug 2021 07:58:01 -0700 Message-ID: To: Martin Turon , dnssd@ietf.org Content-Type: multipart/alternative; boundary="000000000000211d5405c95df606" Archived-At: Subject: Re: [dnssd] Adoption call for draft-sctl-advertising-proxy X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2021 14:58:21 -0000 --000000000000211d5405c95df606 Content-Type: text/plain; charset="UTF-8" On August 12, 2021 at 6:32:47 AM, Martin Turon ( mturon=40google.com@dmarc.ietf.org) wrote: Is the case of a device conflicting with itself handled? Specifically, imagine a dual-radio device (WiFi and Thread) which for some reason migrates from being an SRP client to an mDNS client or vice versa. When the device tries to re-register its services to direct to its new, renumbered IP addresses, could its own stale records on the proxy possibly lock it out? This is exactly the discussion I think we want to have. With a single SRP server, this is a non-problem: the SRP First-Come, First-Served Naming mechanism guarantees that if the same client registers twice, it will be recognized the second time and its update will supersede the previous registration, rather than conflicting with it. With multiple SRP servers, we have a problem because the SRP client might register with a different SRP server the second time, since it has no idea it's connected to the same infrastructure (and indeed the SRP server contact mechanism may be different, so that which server is updated is non-deterministic or just not under the client's control). In this case, we'll see a conflict when the second update comes in. The way I'm currently proposing to address this is by requiring SRP replication when there is more than one SRP server, and by not renaming, but rather waiting for the conflict to resolve. With SRP replication, we can use FCFS naming to see that it's actually the same client doing the update, so there's no conflict at the SRP level. The only conflict is in mDNS. When the SRP update propagates to the SRP server with the conflicting data, that SRP server will remove the old data and replace it with the new, which eliminates the conflict. I think this is pretty tight; the only problem is that it does rely on SRP replication working well. If SRP replication gets wedged, then the conflict won't be resolved until the old data expires. This is not great, of course. An additional mitigation strategy is to not actually detect conflicts. If we have two conflicting registrations, and SRP replication doesn't resolve them, then they just coexist until one goes away. This should happen when the old SRP lease expires. This means that the consumer of the data has to be smart about it: if there are conflicting TXT records, it needs to have a strategy for choosing which one to trust. If there are conflicting address records, it needs to do happy eyeballs. The only other alternative is to rename. I think this is too heavy of a solution, but I'm open to debate. The problem is that if we rename, we now have two advertisements for the same accessory, so we're pretty much in the same place we'd be with the "don't detect conflicts" strategy, except that we have a gratuitous extra name. So consumers of the data now have to use some other identifier than the name to uniquely identify the device, and if there are two advertisements under two different names that present the same identifier, we now have to have a browse going to detect that, whereas if we don't change the name, dealing with an unresolved conflict is a lot simpler. With that said, that's just my thinking on this, and I'd really like to get more eyes on this problem. --000000000000211d5405c95df606 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
On A= ugust 12, 2021 at 6:32:47 AM, Martin Turon (mturon=3D40google.com@dmarc.ietf.org) wrote:
Is the case of a device conflicting with itself handled? Specifical= ly, imagine a dual-radio device (WiFi and Thread) which for some reason mig= rates from being an SRP client to an mDNS client or vice versa.=C2=A0 When = the device tries to re-register its services to direct to its new, renumber= ed IP addresses, could its own stale records on the proxy possibly lock it = out?

This is exactly the discussio= n I think we want to have.

With a single SRP server, this is a non-pr= oblem: the SRP First-Come, First-Served Naming mechanism guarantees that if= the same client registers twice, it will be recognized the second time and= its update will supersede the previous registration, rather than conflicti= ng with it.

With multiple SRP servers, we have a problem because the = SRP client might register with a different SRP server the second time, sinc= e it has no idea it's connected to the same infrastructure (and indeed = the SRP server contact mechanism may be different, so that which server is = updated is non-deterministic or just not under the client's control). I= n this case, we'll see a conflict when the second update comes in.

<= p>The way I'm currently proposing to address this is by requiring SRP r= eplication when there is more than one SRP server, and by not renaming, but= rather waiting for the conflict to resolve. With SRP replication, we can u= se FCFS naming to see that it's actually the same client doing the upda= te, so there's no conflict at the SRP level. The only conflict is in mD= NS. When the SRP update propagates to the SRP server with the conflicting d= ata, that SRP server will remove the old data and replace it with the new, = which eliminates the conflict.

I think this is pretty tight; the only= problem is that it does rely on SRP replication working well. If SRP repli= cation gets wedged, then the conflict won't be resolved until the old d= ata expires. This is not great, of course.

An additional mitigation s= trategy is to not actually detect conflicts. If we have two conflicting reg= istrations, and SRP replication doesn't resolve them, then they just co= exist until one goes away. This should happen when the old SRP lease expire= s. This means that the consumer of the data has to be smart about it: if th= ere are conflicting TXT records, it needs to have a strategy for choosing w= hich one to trust. If there are conflicting address records, it needs to do= happy eyeballs.

The only other alternative is to rename. I think thi= s is too heavy of a solution, but I'm open to debate. The problem is th= at if we rename, we now have two advertisements for the same accessory, so = we're pretty much in the same place we'd be with the "don'= t detect conflicts" strategy, except that we have a gratuitous extra n= ame.

So consumers of the data now have to use some other identifier t= han the name to uniquely identify the device, and if there are two advertis= ements under two different names that present the same identifier, we now h= ave to have a browse going to detect that, whereas if we don't change t= he name, dealing with an unresolved conflict is a lot simpler.

With t= hat said, that's just my thinking on this, and I'd really like to g= et more eyes on this problem.

--000000000000211d5405c95df606-- From nobody Thu Aug 12 08:01:15 2021 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 787FB3A1578 for ; Thu, 12 Aug 2021 07:59:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.098 X-Spam-Level: X-Spam-Status: No, score=-18.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.499, 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, 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 XdzBoMjVHlTR for ; Thu, 12 Aug 2021 07:59:14 -0700 (PDT) Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (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 AB6B43A164F for ; Thu, 12 Aug 2021 07:58:49 -0700 (PDT) Received: by mail-lf1-x12a.google.com with SMTP id n17so13915034lft.13 for ; Thu, 12 Aug 2021 07:58:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=RLLT8P2jv4cYskxsegC7jCLiX925uMASKZ3W1VlRu6M=; b=dpQe1/44Mes1Yh48WL7y6+72qdnOQxIaBF8seB6CGITvML374dDDoOy5X3yPYbxjk2 1U3T8IkHXKbRh/4Z1SIuKd1zDaNDEq/QsTtAQga7rEGhJMfEUFx4k1bkwHqfTmE225Zd h+94bT2iN/zDSYizRbh/GUD/0/Q6Y+CH90xOd+V3v7eavHfZ5Xf/xAaeDGecxjFhZ8gi /wEWYCwx2wrFLR96h0n6aHm3iUdlOGOza2J8tF+AHDjZLNT2Z0rgk5nrfuT3Uklin/CD D5mMPp/Nr1CEgvWgrGHbeUvGJ0+8thDe+6JhnNlTulgRmBFNw0g9DUkZFICcLvSQJ+JN m3OA== 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=RLLT8P2jv4cYskxsegC7jCLiX925uMASKZ3W1VlRu6M=; b=tgx4lBBaMLXSLk+2fxPrL7mNqCsEU9lxvIaKhB6/dQxfPJm/kxM7a9Dv/nT4Uk5dl1 K1t9V9/h+psUrqgAUoQ8UdTvJ0gun/i4XCUXe7k/3IXckmzWBAiz0B3rO7HqM54gapOx PYV3Z2AnEGRe3yiWlY2V8GT6PzNn+jwqeR4njN0PF/0jKcvS54gWLlWoyMkReIGKx3Ut 2A4+req0A03eMNd/tCiREg/OuH7AssT1d3nguokcj6ibH/NQVbOht79qswX78KGhisio fqINZb1owdorXWonVdF9EYMCShiL2WWOlTlB1ATgwaTGG1by+D7oo6scI/M1200sw244 qnVw== X-Gm-Message-State: AOAM532gEHAYalJkfIMsNHVgfIF2fwPqUPPaSqjebextXu6XqDcnD5eb rF0cqv3ckj0G8EwUA9CvYibz5NHqSfKc7VWI9s9r3Hoa/Llx3ue6 X-Google-Smtp-Source: ABdhPJxZbC31M0xkwKqfDYmnBKaoWnDuXGpwMCpBAfPlXivo5KNN8Hj0ftgfgWEqlKijc6UBERoxqdMrOkFKBGawMas= X-Received: by 2002:a05:6512:152a:: with SMTP id bq42mr2805733lfb.68.1628780326257; Thu, 12 Aug 2021 07:58:46 -0700 (PDT) MIME-Version: 1.0 From: Simon Lin Date: Thu, 12 Aug 2021 22:58:35 +0800 Message-ID: To: dnssd@ietf.org Content-Type: multipart/alternative; boundary="000000000000c45d6c05c95df85d" Archived-At: X-Mailman-Approved-At: Thu, 12 Aug 2021 08:01:14 -0700 Subject: Re: [dnssd] Adoption call for draft-sctl-advertising-proxy X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2021 14:59:16 -0000 --000000000000c45d6c05c95df85d Content-Type: text/plain; charset="UTF-8" Hi, I have reviewed this document (draft-sctl-advertising-proxy-02) and want to support its publication. Most parts of the document make good sense to me, even though I am still not totally clear how to handle late name conflicts. The advertising proxy proposed by this document is very useful to bridge devices in sub networks (e.g. Thread) to the home network. Actually we have implemented an advertising proxy in OpenThread ( https://github.com/openthread/openthread) to work with multiple mDNS implementations including mDNSResponder and Avahi. Regards, Simon --000000000000c45d6c05c95df85d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I have reviewed this= document (draft-sctl-advertising-proxy= -02) and want to support its publication. Most parts of the document make g= ood sense to me, even though I am still not totally clear how to handle lat= e name conflicts.
The advertising proxy proposed by thi= s document is very useful to bridge devices in sub networks (e.g. Thread) t= o the home network. Actually we have implemented an advertising proxy in Op= enThread (https://github.com/openthread/openthread) to work with multiple mDNS implementations including mDNSResponder= and Avahi.

Regards,
= Simon
--000000000000c45d6c05c95df85d-- From nobody Thu Aug 12 08:19:11 2021 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 208EA3A162E for ; Thu, 12 Aug 2021 08:19:10 -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, 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.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=nanoleaf.me 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 vfYilwmYmFNU for ; Thu, 12 Aug 2021 08:19:04 -0700 (PDT) Received: from APC01-SG2-obe.outbound.protection.outlook.com (mail-eopbgr1310089.outbound.protection.outlook.com [40.107.131.89]) (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 A2E423A1623 for ; Thu, 12 Aug 2021 08:19:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=g3KqEJDQtoNALTUrOSxndjsqd9LJC2siD95DWzvpOz1hKMfUiiUZWOTVqvpfXqKBdONpeynu1Jy+gX005HpKkMvJpJ8AD634A1k/EcDkzveuULh0fmxW6lRL35X+BuIllwdhZQfli734RI91cFpee8z/ef3tSxgHtqB3HPk94pwEbDDWDaJjHrHYzA8MD/gmLEYe0R3UN7jAZ0vum/gPqlcXT+/rsKoI7XAziXra5hCrNVd7CzyJVsfXst6BiXXnkVwotXLb6t/qGYUs/j71VqlFfpkRoyDAbW6J9KkQNGzfUVp31BuEuCd7yXuTKuHazf0WfXayGVMK7AOsdAqu5w== 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=16V2djnVq2WVfvwQkDGva3zkBP0bXuTxvHWPy2hIgfU=; b=VxJKQfSulh5M5oI3Fg5sC1bOXpMynp4rxcRAyb+jA3x3XDXNXt5QATnp0PDx42A2JrkZlkt9YaSkwpjSxy0qXFD51vXGe/eJoAGKtFS4+krjbBnnCF1EjzNqdKOu7v3CJmpyd+zZ9PKA/1xnCFPfuK5NMBjmq2TFBLfgbPaQEudvTSoPf8l28E80KC/LFtBM/dD9GrNxCErrcGxhVICBnZ37FeWQ7aBs10rLpLEDEwVbvQWtsMC6m/5nZC+EwIEZfEMQLwlYmdoCBv1nwDUmlmbm95rX2JPjOm/qBTK4vhzwjf7KMdSruMR3gWFCQ02BGI1Dz1AihZ6+TJMdRRvc9Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nanoleaf.me; dmarc=pass action=none header.from=nanoleaf.me; dkim=pass header.d=nanoleaf.me; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nanoleaf.me; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=16V2djnVq2WVfvwQkDGva3zkBP0bXuTxvHWPy2hIgfU=; b=AxUSbwPFU70qRsdCGJ486AcrVGLcuBo8A3oOPjjXZDfOjwaAqXojymqiMibd+0jP6p0aPBld7rMJJHRntzkJ6iGt7uvvOdTppc4ssOA1Nepssn0+I3H2PJp4NUGVSBSzfq2fq9nrYNqzlEgcLbFKOr5mRgSVUUNRH+aW7xeAIx4= Received: from SG2PR02MB3782.apcprd02.prod.outlook.com (2603:1096:4:3a::18) by SG2PR02MB2447.apcprd02.prod.outlook.com (2603:1096:3:24::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4394.17; Thu, 12 Aug 2021 15:18:58 +0000 Received: from SG2PR02MB3782.apcprd02.prod.outlook.com ([fe80::79ac:1985:1d74:10b7]) by SG2PR02MB3782.apcprd02.prod.outlook.com ([fe80::79ac:1985:1d74:10b7%7]) with mapi id 15.20.4394.023; Thu, 12 Aug 2021 15:18:57 +0000 From: Nathan Dyck To: Simon Lin , "dnssd@ietf.org" Thread-Topic: [dnssd] WGLC for draft-ietf-dnssd-srp Thread-Index: AQHXj3eBeT8dM6apNkiWtquAA386gKtv+JWU Date: Thu, 12 Aug 2021 15:18:57 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-CA, en-US Content-Language: en-CA X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none; dmarc.ietf.org; dmarc=none action=none header.from=nanoleaf.me; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: dccb5eda-c157-42a0-d0c4-08d95da48175 x-ms-traffictypediagnostic: SG2PR02MB2447: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 5eICfw328OLmupnlBhAlxF7+J4xi3LiEDN1lp7HDmFpXe7GEG+3dTwlT6LRE83f8wzV9EzIBAgAD7EK+kkidDen/HsKEazkFmWl3Qa+BDYO9eslNagzaMKRsF8mk8o8taMPI8XLAgW+/DmJ5dkF5NBnB3acZrqggZ2IVepwAiZtjewgYr1RnAz/Ao4Qvj4d56QxDBO5ZglIZDWX+od6YKmjmGnDWZVVPjQeLII0uGTRzex/dpVRlWAq7+8ibZOuSrcAhIUR1brw68PScUKzwy3R3FOFsIQyYFL6ITZSuYwSdBgBwPbscA8De80rHk7+WPop90e3AKXCeOV3G3GuR014iBuoxv3wCgO/URYGpDKM2fN6xmKzW0X9mng9nqGZBkb3Ggl3HjBWKa42OP7ngJvaBcgB+c2mhzNzPEi88hHp3CwEMWr5iqzYhyj+ojHRkrolXmxzFL+r4ehvSg2y1G2ncbCLFQD7P7Iz62cmXcaPpkzCgMSjf+PgnXrv1AHJGDaALHV2t1W3sSYVAf0vrL6ulTaShqE0GCEN/dEI77qNF628nC1wYiqWzENAPiAJQZJDm+JHwh+Yfdr0k9Q5ucwwSUqEauI+E8ndm2sPg70fEgjOSEsUAj3Is8ltm4Gdog6a2BLAZBIRQhVxpfuLDGdybq2YlXb3iVMsUhgBEMRq20ds7qIbp8U4sreb9jj4lTaiV0N/8w2fstmWVq7CRNnIbg+Bf96vw+ICqaqK+aMZY4RNo25tUYaF87HCU0bMX6olTjQw0JOlRcFp1L8R3ene95AzvOwrf8pwXe+RoL94= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SG2PR02MB3782.apcprd02.prod.outlook.com; PTR:; CAT:NONE; SFS:(136003)(39830400003)(346002)(376002)(366004)(396003)(55016002)(9686003)(186003)(53546011)(6506007)(2906002)(86362001)(26005)(8676002)(83380400001)(110136005)(38100700002)(8936002)(478600001)(66556008)(52536014)(66446008)(33656002)(166002)(9326002)(71200400001)(122000001)(66476007)(64756008)(66946007)(5660300002)(76116006)(316002)(91956017)(38070700005)(7696005); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?k5O8nCFWcC2DMB5PSurq789IBmzVfo0y5xTGarUo8PMH7FWZaXJn28KV?= =?Windows-1252?Q?Pib0NeP20SqjqFyc4Mu0Is+WuQI4LOTZVOPL6fJGHP31ayZgNez7mBd0?= =?Windows-1252?Q?wkJE8jLDQkF5y831mHg/j8qwWXxmsnMo+KRpR771HWJ9AukcieQD5iF6?= =?Windows-1252?Q?pMv9OL2QxyP2BqzcrcasTmyAbieqeroQYyPyDFLAV0KENGmreq1HAgeR?= =?Windows-1252?Q?Sn2PRwz66jWviGffOg6vR7EAuUy1gSHkXguFWE54b/ZU7D/hYdJxWCVz?= =?Windows-1252?Q?n54rhBKvenrTCM1UfD+SIxUvukq6ZJwKcOt9oyCkDK0CgLyx7e42RGTQ?= =?Windows-1252?Q?MSvuig0ao0AW7C7KRI7NapMo9UaOF+IEWV8twg9qoydIkFClUQtvYtqk?= =?Windows-1252?Q?9Esxf1LdOn1on9Ahq9Rux8jhAm5Pqy6UvifXJiFjgVrzC1dd0dF2Thii?= =?Windows-1252?Q?VpvxcRZnPK0FmalT+0l/LrmOL9VdNR6TtjWnTtX+aytOzeZeu7rubcAn?= =?Windows-1252?Q?QTxZDeUX0f4S1g4qCF2vBgoRVaQ51EEatu0V4NMcIiJntUgBQ9dvo9Li?= =?Windows-1252?Q?RbBp7o6E96zxy28I/BwiW++OqnfjWfa3J3b6iuZKjH5Gu9SpEUhWWc49?= =?Windows-1252?Q?wIlW6Qa7YSSRDtobvAdEGQ1/SKgBeQPTDcnMX4oQBQWEtFPWQvG/Ts8v?= =?Windows-1252?Q?Gnch4/tV+3r6NA00Dd4NVmMsu4sEjj/hOgO84S+fespK3drwMGzssHFx?= =?Windows-1252?Q?Q2AkdlfVOE9YpFt4yWLFnKqg0OFdlaurqeflSr1ODRQOxG92EhS1zfO/?= =?Windows-1252?Q?5/ToaQS/HoO/519RZeuiq8UTk0+zESyfbYAnaWNdvYzzW5AujMiZwo+1?= =?Windows-1252?Q?D53SNOdJHx1THmxnjILzAVkLouzPlLA2w4hUksuymRjeSRLgpxmK5uCY?= =?Windows-1252?Q?tzrTLugWogLkL8unS1mSt/U76M6wY4pKFFOQaifDAp/312JdjiwBv6k9?= =?Windows-1252?Q?+qnCQpnkk1EZ9MD1GUM1vmfjdpp0xePvtxbYBh8GAKEgx/EVrnU/BLnG?= =?Windows-1252?Q?2iklWZ0JWpYtXXFNnlfXz/tlqxFDK7cE+RRtb62lSiLzwBm5kCfQu0zM?= =?Windows-1252?Q?bv5Y0vRdI8t7ApYZkUonouTiyFABgvLJBhW//Y5yVNcU/H+rSBbBiaKk?= =?Windows-1252?Q?rDR9R5d9oM0xf0+ol1lT9fAhynS61R617z1/an2klyTJ2nXMzkQFpqKt?= =?Windows-1252?Q?kZCxVTFmFTa+aMAw4BwaRrTh2o4+fZS/dKTgYuM3sQBEcDRVW7fCaDYi?= =?Windows-1252?Q?KArfMuq++bY+4BSd1CEZMh8wytG4XphsvnwyCoTjXwj3J10t+KBAmDyQ?= =?Windows-1252?Q?pMJeGBfQ6SurCzkyl8V/BAeko3gjXllRpaJToykZCF69qm3tth4AyXI0?= =?Windows-1252?Q?Ge8h+1aGPrOwKjEQQ29j0w=3D=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_SG2PR02MB3782DB8B99F471732E87AFBEC0F99SG2PR02MB3782apcp_" MIME-Version: 1.0 X-OriginatorOrg: nanoleaf.me X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SG2PR02MB3782.apcprd02.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: dccb5eda-c157-42a0-d0c4-08d95da48175 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Aug 2021 15:18:57.5808 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 7d5e26c7-79f4-48a7-a1ce-69187b990cf1 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: +Zi83rq+6gv9VOjFh0fAw9xGwUGHU4zAFNMPzcCyNCCmOgWkzBwys7BbDXIU779fVNlU8LspJWE6116V7Wmzqw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SG2PR02MB2447 Archived-At: Subject: Re: [dnssd] WGLC for draft-ietf-dnssd-srp X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2021 15:19:10 -0000 --_000_SG2PR02MB3782DB8B99F471732E87AFBEC0F99SG2PR02MB3782apcp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi All, I have now properly read the draft-ietf-dnssd-srp in addition to the draft-= sctl-advertising-proxy document, which my previous comments were aimed. I s= upport it being published. I have two smaller recommendations on draft-ietf-dnssd-srp: 1. The document specifies that clients must retain their key pairs in st= able storage, although the equivalent requirement is not explicitly require= d for servers (KEY + lease time especially) as far as I could read. I belie= ve it should be, likely somewhere in 2.3. It is not clear to me whether the= records themselves are critical or just the KEY + lease. In current Thread= implementations, I do not believe records are stored in stable storage. 2. The order of delete vs. add is specified in 2.3.1 and seems important= . Is it worth also recommending a =93should=94 case for clients in section = 2.2.5.5.2.? * =93=85in the old service being replaced by the new service.=94 * Append: =93The sequence of these instructions in the SRP update sh= ould include the delete before the add.=94 Thanks, Nathan -- Nathan Dyck Chief Product Officer e: nathan@nanoleaf.me | c: +1 (289) 242-0016 The Nanoleaf Team www.nanoleaf.me follow us on twitter @nanoleaf like us on facebook: fb.com/thenanoleaf follow us on instagram @nanoleaf From: dnssd on behalf of Simon Lin Date: Thursday, August 12, 2021 at 8:42 AM To: dnssd@ietf.org Subject: Re: [dnssd] WGLC for draft-ietf-dnssd-srp Hi, I'd like to add my support for publishing the draft-ietf-dnssd-srp. We have been using the OpenThread SRP implementation for Thread Border Rout= ers for a period of time and found that this technique is vital for bridgin= g the gap between Thread networks and the Infrastructure network. We can also see the potential of utilizing SRP within the WiFi networks to = reduce inefficient multicast traffic. Regards, Simon --_000_SG2PR02MB3782DB8B99F471732E87AFBEC0F99SG2PR02MB3782apcp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Hi All,

 

I have now properly read the draft-ietf-dnssd-srp in= addition to the draft-sctl-advertising-proxy document, which my previous c= omments were aimed. I support it being published.

 

I have two smaller recommendations on draft-ietf-dns= sd-srp:

  1. The document specifies that clients must retain their key pairs in st= able storage, although the equivalent requirement is not explicitly require= d for servers (KEY + lease time especially) as far as I could read. I believe it should be, likely somewhere in 2.3. I= t is not clear to me whether the records themselves are critical or just th= e KEY + lease. In current Thread implementations, I do not believe records = are stored in stable storage.
  2. The order of delete vs. = add is specified in 2.3.1 and seems important. Is it worth also recommendin= g a =93should=94 case for clients in section 2.2.5.5.2.?
  3. =93=85in the old service being replaced by the new service.=94
  4. Append: =93The sequence of these instructions in the SRP upd= ate should include the delete before the add.=94

 

Thanks,

 

Nathan

 

--

Nathan Dyck
Chief Product Officer

e: nathan@nanoleaf.me | c: +1 (289) 2= 42-0016

The Nanoleaf Team
www.nanole= af.me
follow us on twitter @nanoleaf
like us on facebook: fb.com/thenanoleaf
follow us on instagram @nanoleaf

 

From: dnssd <dnssd-bou= nces@ietf.org> on behalf of Simon Lin <simonlin=3D40google.com@dmarc.= ietf.org>
Date: Thursday, August 12, 2021 at 8:42 AM
To: dnssd@ietf.org <dnssd@ietf.org>
Subject: Re: [dnssd] WGLC for draft-ietf-dnssd-srp=

Hi, 

 

I'd like to add my support for publishing the d= raft-ietf-dnssd-srp. 

 

We have been using the OpenThread SRP implementation= for Thread Border Routers for a period of time and found that this techniq= ue is vital for bridging the gap between Thread networks and the Infrastruc= ture network.

 

We can also see the potential of utilizing SRP withi= n the WiFi networks to reduce inefficient multicast traffic. 

 

Regards, 

Simon

--_000_SG2PR02MB3782DB8B99F471732E87AFBEC0F99SG2PR02MB3782apcp_-- From nobody Thu Aug 12 10:44:02 2021 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EE5D3A443C for ; Thu, 12 Aug 2021 10:44:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.097 X-Spam-Level: X-Spam-Status: No, score=-18.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.499, 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 z7aJOKNAg8o1 for ; Thu, 12 Aug 2021 10:43:54 -0700 (PDT) Received: from mail-ot1-x336.google.com (mail-ot1-x336.google.com [IPv6:2607:f8b0:4864:20::336]) (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 C2BB73A4438 for ; Thu, 12 Aug 2021 10:43:54 -0700 (PDT) Received: by mail-ot1-x336.google.com with SMTP id a7-20020a9d5c870000b029050333abe08aso8653469oti.13 for ; Thu, 12 Aug 2021 10:43:54 -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=nSGWrh9sO7zV2ATuyFFcFnP4aqjvFYe1TlRNXyL2LAw=; b=ctxG+vatdOwK3IxisY+pC1dSBfi288Wo8atGCYx+7gTFId+xe29kP5K3zt4dkkV/Uk aKkUJaFiJVgV3+qNP4eABRHiATSTAqxNcAidElRBI/p62nADpl1MwM+fFZRST7tAn2Hf Pv7RxBeqLNVtCmX8XuMgP/eoaDNWFA18gjlk4Y7SGzh1ghitR/cgOWJ5aYXvD2ofXfDL TdsoEmR9K4Fv++uI5pl9ewHGkMhTX2PpEqe39yZg1IKX18UizYchi4zAZDDRreVwbCtA mYnMHbjYwLW84ztmHnTpxnsERGMXKnObUro8uM6whGw+7sk6TQMYT7Xljus+HBho57nt mQBw== 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=nSGWrh9sO7zV2ATuyFFcFnP4aqjvFYe1TlRNXyL2LAw=; b=FCPtJVZBYaxqSqIK3QvRZGvbKKuMkn1Ri/yvfKvvzWFX3zRlmVj4mntgbVfNBF9XW1 VqbI89NcI45UIwKXzrDcKsiUbIqQbxL6zEBIDsa9JLMkiGcdhIMnHjmy+yM300a3Xh/+ XFo5kAMRbmR3ppmAUgAzslmtiD7JoZXBLgaOJgZ4h3aJh9K/RmcrwzqF4PGeZHsJpAQG U/9t0MT19F1U0HxsGLHEOcqpgkIxd72L4+HySWvKlneOjKgiIWz2pYvEmPG+abcLK+D1 fa/ATTD8WtCPOJazkvifLfOwmmPkQnPvi5fupY6va+r/9e03A+c6P90icBKbS0cntX66 e/YA== X-Gm-Message-State: AOAM5322c8y544Wjbx+aX1fQ0dsvBJmIJPnTbcYbAg0yczyLYy3ZbZv+ Bb7pORkaIs8GXexjvn2+LnvzYOH1T2cIckwel0/otw== X-Google-Smtp-Source: ABdhPJyH5iYIpaA1covWoaRXVtS1zaY3F9eZJSEdBJ8fu2aHNl+J0YVAx0vdZrlRKtOtbtze3nhVHByDJuxQgYAFIuE= X-Received: by 2002:a05:6830:2646:: with SMTP id f6mr4470651otu.129.1628790232092; Thu, 12 Aug 2021 10:43:52 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Jonathan Hui Date: Thu, 12 Aug 2021 10:43:40 -0700 Message-ID: To: Ted Lemon Cc: dnssd@ietf.org Content-Type: multipart/alternative; boundary="00000000000032e7c905c9604714" Archived-At: Subject: Re: [dnssd] Adoption call for draft-sctl-advertising-proxy X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2021 17:44:00 -0000 --00000000000032e7c905c9604714 Content-Type: text/plain; charset="UTF-8" On Thu, Aug 12, 2021 at 7:59 AM Ted Lemon wrote: > This is exactly the discussion I think we want to have. > > With a single SRP server, this is a non-problem: the SRP First-Come, > First-Served Naming mechanism guarantees that if the same client registers > twice, it will be recognized the second time and its update will supersede > the previous registration, rather than conflicting with it. > To address the case where a device may transition between Thread and Wi-Fi networks, having the device leverage SRP regardless of whether the device is connected via Thread or Wi-Fi would also resolve any conflicts that might occur. Fortunately, SRP on Wi-Fi is something that you're already addressing with draft-tljd-dnssd-zone-discover. > With multiple SRP servers, we have a problem because the SRP client might > register with a different SRP server the second time, since it has no idea > it's connected to the same infrastructure (and indeed the SRP server > contact mechanism may be different, so that which server is updated is > non-deterministic or just not under the client's control). In this case, > we'll see a conflict when the second update comes in. > > The way I'm currently proposing to address this is by requiring SRP > replication when there is more than one SRP server, and by not renaming, > but rather waiting for the conflict to resolve. With SRP replication, we > can use FCFS naming to see that it's actually the same client doing the > update, so there's no conflict at the SRP level. The only conflict is in > mDNS. When the SRP update propagates to the SRP server with the conflicting > data, that SRP server will remove the old data and replace it with the new, > which eliminates the conflict. > > I think this is pretty tight; the only problem is that it does rely on SRP > replication working well. If SRP replication gets wedged, then the conflict > won't be resolved until the old data expires. This is not great, of course. > I agree that SRP replication is an elegant solution in concept. I'd like to get some implementation/operational experience on how well it works in practice. > An additional mitigation strategy is to not actually detect conflicts. If > we have two conflicting registrations, and SRP replication doesn't resolve > them, then they just coexist until one goes away. This should happen when > the old SRP lease expires. This means that the consumer of the data has to > be smart about it: if there are conflicting TXT records, it needs to have a > strategy for choosing which one to trust. If there are conflicting address > records, it needs to do happy eyeballs. > If there's no good way to invalidate the old entry, then I think presenting both is the next best solution - it at least makes it possible to continue communicating with the service. Although, as you noted, it requires extra work by the consumer of the service data. > The only other alternative is to rename. I think this is too heavy of a > solution, but I'm open to debate. The problem is that if we rename, we now > have two advertisements for the same accessory, so we're pretty much in the > same place we'd be with the "don't detect conflicts" strategy, except that > we have a gratuitous extra name. > > So consumers of the data now have to use some other identifier than the > name to uniquely identify the device, and if there are two advertisements > under two different names that present the same identifier, we now have to > have a browse going to detect that, whereas if we don't change the name, > dealing with an unresolved conflict is a lot simpler. > I agree. I don't see much value in renaming to address these self-conflict scenarios. -- Jonathan Hui --00000000000032e7c905c9604714 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Thu, Aug 12, 2021 at 7:59 AM Ted Lemon= <mellon@fugue.com> wrote:
This is exactly the discussion I t= hink we want to have.

With a single SRP server, this is = a non-problem: the SRP First-Come, First-Served Naming mechanism guarantees= that if the same client registers twice, it will be recognized the second = time and its update will supersede the previous registration, rather than c= onflicting with it.

To address the case where a = device may transition between Thread and Wi-Fi networks, having the device = leverage SRP regardless of whether the device is connected via Thread or Wi= -Fi would also resolve any conflicts that might occur. Fortunately, SRP on = Wi-Fi is something that you're already addressing with=C2=A0draft-tljd-= dnssd-zone-discover.

With multiple SRP servers, we have a problem because the SRP c= lient might register with a different SRP server the second time, since it = has no idea it's connected to the same infrastructure (and indeed the S= RP server contact mechanism may be different, so that which server is updat= ed is non-deterministic or just not under the client's control). In thi= s case, we'll see a conflict when the second update comes in.

The= way I'm currently proposing to address this is by requiring SRP replic= ation when there is more than one SRP server, and by not renaming, but rath= er waiting for the conflict to resolve. With SRP replication, we can use FC= FS naming to see that it's actually the same client doing the update, s= o there's no conflict at the SRP level. The only conflict is in mDNS. W= hen the SRP update propagates to the SRP server with the conflicting data, = that SRP server will remove the old data and replace it with the new, which= eliminates the conflict.

I think this is pretty tight; the only prob= lem is that it does rely on SRP replication working well. If SRP replicatio= n gets wedged, then the conflict won't be resolved until the old data e= xpires. This is not great, of course.

I agree th= at SRP replication is an elegant solution in concept. I'd like to get s= ome implementation/operational experience on how well it works in practice.= =C2=A0

A= n additional mitigation strategy is to not actually detect conflicts. If we= have two conflicting registrations, and SRP replication doesn't resolv= e them, then they just coexist until one goes away. This should happen when= the old SRP lease expires. This means that the consumer of the data has to= be smart about it: if there are conflicting TXT records, it needs to have = a strategy for choosing which one to trust. If there are conflicting addres= s records, it needs to do happy eyeballs.

If the= re's no good way to invalidate the old entry, then I think presenting b= oth is the next best solution - it at least makes it possible to continue c= ommunicating with the service. Although, as you noted, it requires extra wo= rk by the consumer of the service data.=C2=A0

The only other alternative is to rena= me. I think this is too heavy of a solution, but I'm open to debate. Th= e problem is that if we rename, we now have two advertisements for the same= accessory, so we're pretty much in the same place we'd be with the= "don't detect conflicts" strategy, except that we have a gra= tuitous extra name.

So consumers of the data now have to use some oth= er identifier than the name to uniquely identify the device, and if there a= re two advertisements under two different names that present the same ident= ifier, we now have to have a browse going to detect that, whereas if we don= 't change the name, dealing with an unresolved conflict is a lot simple= r.

I agree. I don't see much value in renami= ng to address these self-conflict scenarios.

--
Jonathan Hui
=C2=A0
--00000000000032e7c905c9604714-- From nobody Thu Aug 12 20:08:38 2021 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37DC23A19E3 for ; Thu, 12 Aug 2021 20:08:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.099 X-Spam-Level: X-Spam-Status: No, score=-18.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.499, 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, SPF_HELO_NONE=0.001, SPF_PASS=-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 tdt3qadE_1kz for ; Thu, 12 Aug 2021 20:08:35 -0700 (PDT) Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0041D3A19E2 for ; Thu, 12 Aug 2021 20:08:34 -0700 (PDT) Received: by mail-lj1-x232.google.com with SMTP id m17so9900631ljp.7 for ; Thu, 12 Aug 2021 20:08:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=5EhZgUQ1aQmcVYd2qsS4UPzZXGyj9d2VT4efskWhtJg=; b=uXYsdENa+3LHtVsfV2TtipFFTbj2YJMHuAYnyC5v+ykAP5lf3EyVNRzTMIl+NXPsYI nQNGLaPYnqA757AZ2hmdG/fAWEc8oUjlfTe6Y+wjw6jSfNo2rPcq0DWSRo+C+6jjDk+e MMrNMCwF/tf+ozupRZIZLDfoRZG9BUwWVJaI/ZBNP33z0edHytM8Z4MPrGmq6eFUEi6V EMMhHp62kXHwVCrJafbObon9fbovuOUK+zU/XjdoLLE13WdSLsp443UUFYFNmwEkewkM I5LtNphbpl8QonBap/dgDzJuHpdDcErtHRM4hVKBP/WYtqoIOPRQpPSi3vfNNxTnX3Ox qY/w== 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=5EhZgUQ1aQmcVYd2qsS4UPzZXGyj9d2VT4efskWhtJg=; b=Cg0p5ENi06ykL634SARVYMLCrQEhET5PwLfGUX9iy/aSDDav5it7pTqGylC+MyUrSK Lhpe1FBSiOl7XUUTygq6f0Mo/nT39cVBC7r8MNQPHje2UAP4/4MaGlY9TaK5/YJXqwvn v6G4AkIso8JYLtAm9C5s2UEQ+XO8Ax4vUg3f1LkClOmulW3VXSIPVRZxFdoQI/SKCk9T jyE4qSAJl1cFIMF7nxoJwAYf84Y5tnoOsdwX4nq1ftYbVpDC4XjFPwVuSlllDzVRNLQQ QRB4V1soQF0ghHMjaZp3N409+b3gPkMEXd+cClJm1IKmkEvr95IHLp0kp2XJbRtrjVzr Zj6g== X-Gm-Message-State: AOAM530KearGSw1p0F/xZr0wHRgYmc0rhgCVaboTFkM6lg1gk55YbaRz HWFJ853JhAQnAvEKctpBN/osaGnUBgJ0YU6TWFsFrYKCN0u5VGos X-Google-Smtp-Source: ABdhPJxN3GQ6WO+KyiJ4rFqYSiPTOkt5uiE3/r1PUcJuiJTjSNQ9RRRfZO72eJow+qiRqaIfGwz0uBTGlZyYHPlCv2o= X-Received: by 2002:a2e:9ac7:: with SMTP id p7mr222425ljj.96.1628824111532; Thu, 12 Aug 2021 20:08:31 -0700 (PDT) MIME-Version: 1.0 From: Simon Lin Date: Fri, 13 Aug 2021 11:08:20 +0800 Message-ID: To: dnssd@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [dnssd] Adoption call for draft-sctl-advertising-proxy X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Aug 2021 03:08:37 -0000 > Specifically, > imagine a dual-radio device (WiFi and Thread) which for some reason > migrates from being an SRP client to an mDNS client or vice versa. What's the solution to resolve the case where an SRP client migrates to be an mDNS client. When the mDNS client tries to advertise its DNS service, it will conflict with the SRP server of the original SRP client. I don't think SRP replication can solve this problem. As Jonathan said, always using SRP regardless of whether the device is connected via Thread or WiFi can solve this problem. Also maybe the device can unregister itself from SRP when it has migrated to WiFi, which requires the device to remember the IP address of the SRP server, or to use draft-tljd-dnssd-zone-discover. > The way I'm currently proposing to address this is by requiring SRP > replication when there is more than one SRP server, and by not renaming, > but rather waiting for the conflict to resolve. Agree that SRP replication is the most user-friendly way of addressing this problem. > An additional mitigation strategy is to not actually detect conflicts. If > we have two conflicting registrations, and SRP replication doesn't resolve > them, then they just coexist until one goes away. Does this strategy violate mDNS protocol? Moreover, if two different devices register their service on different SRP servers using the same name, it's not a good idea to not resolve the conflict since the conflict will last for a long time. > The only other alternative is to rename. I think this is too heavy of a > solution, but I'm open to debate. It increases the complexity on every device that needs to browse for mDNS services. I would prefer SRP replication to renaming. -- Simon Lin From nobody Fri Aug 13 04:19:47 2021 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E122D3A13F5 for ; Fri, 13 Aug 2021 04:19:45 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 aRJsyLNTpM9x for ; Fri, 13 Aug 2021 04:19:41 -0700 (PDT) Received: from mail-ot1-x334.google.com (mail-ot1-x334.google.com [IPv6:2607:f8b0:4864:20::334]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFFD73A1427 for ; Fri, 13 Aug 2021 04:19:40 -0700 (PDT) Received: by mail-ot1-x334.google.com with SMTP id 61-20020a9d0d430000b02903eabfc221a9so11717708oti.0 for ; Fri, 13 Aug 2021 04:19:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:in-reply-to:references:mime-version:date:message-id:subject:to; bh=HGFsFhHkP2Yt9mNr2GuoUpvoxDBPT1nx+OU4sLnKRjI=; b=UUH5TuG6c36iy3I8JrgZ1V3FtyE6S1lMPNEXEL/fKNY/xrIJL5Ycjvkk3ojMxU6MEJ SLeCFYuOsYeGsA08Swaz+KhpU0mL5sZSN/VhK2CFZcwrEUlnwR1hFeixmaG+0lVwXAN/ 3Q6YKYXPoQ1gF5gHdME1lF1VZ3Zrx0jAGxhOIgM4KdRY+/l3iABs55GZ2v7MymVgx3O7 2bYbwxS5KPWWTEsrnSDnPZmLkdQVJoNSlF0FWfdjyDiV/WxQEPg2pYzAWR3TtcKTcybH 4I2QLLonjG3pltQnDSHfD06/h2sz0+Ji9zAUhl0rtfQENUuaBOph0W6JZouxhqcZm+u8 Gswg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to; bh=HGFsFhHkP2Yt9mNr2GuoUpvoxDBPT1nx+OU4sLnKRjI=; b=n4rMJX+NB+iEmFxRuGne/35hANUbevao4/BuBCoPKE3V++e3fUUy7+Jpd85DZMkw68 25/PkdTffhRi1rhky0+Bvlt62ZaSslGrjrRyXjP9fUpB3IMVg33UFsvVNYgAPXf2kZLI 8kmwB1B48hXtX4djwo/94tLG/LJ1jmkZ5WThHBcggJ1uQw0Bro0VLZc/boAv1g6Qyber vxkgJSxo9cKOQJRVECcRHtZS+TNJSJprC52GXD6JEl+zcgdvANnRQsWzD3Y3/TY8RL2V qwui/3ZNKvp98a2UBtuWU1UjVBrkf5zg53NidIkxgdp5myF3bR9l6tyQGHLssIqhVSbb XlBg== X-Gm-Message-State: AOAM530r7ncd1SXeWFNPsWpStCyPtLk5CaEILRgq15+BPfhI+z9k0nG7 bOFmLnFANXbUURU9JsKIt0qLlQCtf/ph8cRZbRpXq1IFzJXopA== X-Google-Smtp-Source: ABdhPJzp39QUmrNI1JoS3Bce9cFlWW7HpiEexS2cJ6JyKbDxRTiGGOAW+uunaHw1qYMrx/2efmQh0KYlfIY/U1uxegc= X-Received: by 2002:a9d:68d4:: with SMTP id i20mr1710017oto.63.1628853578337; Fri, 13 Aug 2021 04:19:38 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Fri, 13 Aug 2021 04:19:37 -0700 From: Ted Lemon In-Reply-To: References: MIME-Version: 1.0 Date: Fri, 13 Aug 2021 04:19:37 -0700 Message-ID: To: Simon Lin , dnssd@ietf.org Content-Type: multipart/alternative; boundary="000000000000eda08905c96f063f" Archived-At: Subject: Re: [dnssd] Adoption call for draft-sctl-advertising-proxy X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Aug 2021 11:19:46 -0000 --000000000000eda08905c96f063f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On August 12, 2021 at 11:08:44 PM, Simon Lin ( simonlin=3D40google.com@dmarc.ietf.org) wrote: > Specifically, > imagine a dual-radio device (WiFi and Thread) which for some reason > migrates from being an SRP client to an mDNS client or vice versa. Interesting=E2=80=94I'm realizing I completely misread Martin's question. I= was assuming that this client would continue to be an SRP client, not switch between SRP and mDNS. What's the solution to resolve the case where an SRP client migrates to be an mDNS client. When the mDNS client tries to advertise its DNS service, it will conflict with the SRP server of the original SRP client. I don't think SRP replication can solve this problem. As Jonathan said, always using SRP regardless of whether the device is connected via Thread or WiFi can solve this problem. Also maybe the device can unregister itself from SRP when it has migrated to WiFi, which requires the device to remember the IP address of the SRP server, or to use draft-tljd-dnssd-zone-discover. I don't think dnssd-zone-discover helps with this. I think the client needs to either unregister itself with SRP before migrating, or follow the same protocol I mentioned earlier with respect to its service advertisement: advertise without asserting uniqueness. > The way I'm currently proposing to address this is by requiring SRP > replication when there is more than one SRP server, and by not renaming, > but rather waiting for the conflict to resolve. Agree that SRP replication is the most user-friendly way of addressing this problem. > An additional mitigation strategy is to not actually detect conflicts. If > we have two conflicting registrations, and SRP replication doesn't resolve > them, then they just coexist until one goes away. Does this strategy violate mDNS protocol? Moreover, if two different devices register their service on different SRP servers using the same name, it's not a good idea to not resolve the conflict since the conflict will last for a long time. No, it's allowed. If two devices claim the same name, we're now assuming that this conflict will be resolved out of band rather than through mDNS conflict detection. TBH, the only time I've ever actually seen an mDNS conflict happen outside of deliberate testing was when a single device was connected through two interfaces to the same link and didn't know it. On the other hand we see conflicts all the time with SRP because of the two-SRP-server mDNS conflict detection algorithm, so it's pretty clear that SRP + mDNS conflict detection is a recipe for creating conflicts. > The only other alternative is to rename. I think this is too heavy of a > solution, but I'm open to debate. It increases the complexity on every device that needs to browse for mDNS services. I would prefer SRP replication to renaming. This is a good point=E2=80=94SRP replication also increases complexity, but= it constrains it nicely to the more capable nodes on the network=E2=80=94the o= nes that are acting as ad-hoc infrastructure and not as end nodes. --000000000000eda08905c96f063f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
On August 12, 202= 1 at 11:08:44 PM, Simon Lin (simonlin=3D40google.com@dmarc.ietf.org) wrote:
=
>= Specifically,=C2=A0
> imagine a dual-radio device (WiFi and Thread) = which for some reason=C2=A0
> migrates from being an SRP client to an= mDNS client or vice versa.=C2=A0

Interesting=E2= =80=94I'm realizing I completely misread Martin's question. I was a= ssuming that this client would continue to be an SRP client, not switch bet= ween SRP and mDNS.

What's the solution to resolve the case where an SRP client migrates= =C2=A0
to be an mDNS client. When the mDNS client tries to advertise its= DNS=C2=A0
service, it will conflict with the SRP server of the original= SRP=C2=A0
client. I don't think SRP replication can solve this prob= lem.=C2=A0

As Jonathan said, always using SRP regardless of whether = the device is=C2=A0
connected via Thread or WiFi can solve this problem.= Also maybe the=C2=A0
device can unregister itself from SRP when it has = migrated to WiFi,=C2=A0
which requires the device to remember the IP add= ress of the SRP=C2=A0
server, or to use draft-tljd-dnssd-zone-discover.= =C2=A0

I don't think dnssd-zone-discover helps wit= h this. I think the client needs to either unregister itself with SRP befor= e migrating, or follow the same protocol I mentioned earlier with respect t= o its service advertisement: advertise without asserting uniqueness.

> The way I'm cu= rrently proposing to address this is by requiring SRP=C2=A0
> replica= tion when there is more than one SRP server, and by not renaming,=C2=A0
= > but rather waiting for the conflict to resolve.=C2=A0

Agree tha= t SRP replication is the most user-friendly way of addressing=C2=A0
this= problem.=C2=A0

> An additional mitigation strategy is to not act= ually detect conflicts. If=C2=A0
> we have two conflicting registrati= ons, and SRP replication doesn't resolve=C2=A0
> them, then they = just coexist until one goes away.=C2=A0

Does this strategy violate m= DNS protocol? Moreover, if two different=C2=A0
devices register their se= rvice on different SRP servers using the same=C2=A0
name, it's not a= good idea to not resolve the conflict since the=C2=A0
conflict will las= t for a long time.=C2=A0

No, it's allowed. If two = devices claim the same name, we're now assuming that this conflict will= be resolved out of band rather than through mDNS conflict detection. TBH, = the only time I've ever actually seen an mDNS conflict happen outside o= f deliberate testing was when a single device was connected through two int= erfaces to the same link and didn't know it.

On the other hand we= see conflicts all the time with SRP because of the two-SRP-server mDNS con= flict detection algorithm, so it's pretty clear that SRP + mDNS conflic= t detection is a recipe for creating conflicts.

> The only other alternative is to rename= . I think this is too heavy of a=C2=A0
> solution, but I'm open t= o debate.=C2=A0

It increases the complexity on every device that nee= ds to browse for=C2=A0
mDNS services. I would prefer SRP replication to = renaming.=C2=A0

This is a good point=E2=80=94SRP repli= cation also increases complexity, but it constrains it nicely to the more c= apable nodes on the network=E2=80=94the ones that are acting as ad-hoc infr= astructure and not as end nodes.

--000000000000eda08905c96f063f-- From Hubert.Mis@nordicsemi.no Fri Aug 13 07:10:00 2021 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ADA63A1A32 for ; Fri, 13 Aug 2021 07:10:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-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=nordicsemi.onmicrosoft.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 gdm0Bp5wMHua for ; Fri, 13 Aug 2021 07:09:56 -0700 (PDT) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2054.outbound.protection.outlook.com [40.107.20.54]) (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 1A7EF3A13AD for ; Fri, 13 Aug 2021 07:09:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=G/X90V6wh+OyvHSMAqnzbJtvEDybJusI+K2IK6MI6UFSFombHn1JptpHVmleLEYGNY1wuW8F2gyo9+PJ9bNH8eFdievfswyjIRo16bhozPmqIi1YD1syUPTLJ23Fzdqnh9GPBokmE0Nw/HxN5vma1gQbx3LSnPN6FAHhbsVlQpe0Rk2HydhOq2t63EEtTKbtNEL9p0Yag6LU/QWlNaBRVPW80QLlCH2CCeCv7DO0DgvMwBRJqha2uflaionsz5r1GfD1kn4dkR4uSUP/YYijisEx4/4z1IMCPIr8myZqWANvfPM2ziebseLWQr4Qr/IcK1LhFfihDGy7A3Nrys3U8g== 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=PxuHxoTLRs5rantD8mH9Y0deGiTIERz+2gcBhkFOwEY=; b=QggtOfHD0LcAfx0qISEoRcPFiEqrMDG0agdCyT/ydVDMHTlwab06DOjeeWwpx6zufkBFNo9sa95hnpw8SbtvPZ6+hiLUwSkjx/aP7iNUAQIneCxSfZ7wyysrAHZW6geW9Vt9xMBmCcYrOPBlRJ/PjOA8A9tmlhf+yNLh9OjWvN+SE9XeoUnLN5f/RxExMLTTcMhkYwH36x9HmrYP3rPFfrChQxQrxyM88FQnOirpmKL4mFxDQRy8v9jwbbzwreqZTDTMM1iNAg0RjBjH7zQIRFh7QVpLAxKHeTOj4wDYHhNOM+QnSIfsnC242RlM8rbLBam+TpflX6xiH/JRDSm53A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nordicsemi.no; dmarc=pass action=none header.from=nordicsemi.no; dkim=pass header.d=nordicsemi.no; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nordicsemi.onmicrosoft.com; s=selector2-nordicsemi-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=PxuHxoTLRs5rantD8mH9Y0deGiTIERz+2gcBhkFOwEY=; b=dT9ixwXsqCPwO2EtkhwlNrgifbksz6CmItPLHgriGxqtdojv7CNv3GDdpNQd0NEmGOX4UIP2b5b2TG0c0KbVcFi9UZFQrpU0r7XA9CYe5EuHwZSNDk6M+PzaAw9EApW1E8Y2riBAzKEUutP3IPfseOT+cLjR2H9gOJobgjNr1XI= Received: from AM0PR05MB5873.eurprd05.prod.outlook.com (2603:10a6:208:125::25) by AM8PR05MB7890.eurprd05.prod.outlook.com (2603:10a6:20b:355::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4415.17; Fri, 13 Aug 2021 14:09:53 +0000 Received: from AM0PR05MB5873.eurprd05.prod.outlook.com ([fe80::e944:715d:8287:d820]) by AM0PR05MB5873.eurprd05.prod.outlook.com ([fe80::e944:715d:8287:d820%6]) with mapi id 15.20.4415.019; Fri, 13 Aug 2021 14:09:53 +0000 From: =?utf-8?B?TWnFmywgSHViZXJ0?= To: "dschinazi.ietf@gmail.com" CC: "dnssd@ietf.org" Thread-Topic: [dnssd] WGLC for draft-ietf-dnssd-srp Thread-Index: AQHXkEzj097Py0yx0kG6xKf0SRM66g== Date: Fri, 13 Aug 2021 14:09:53 +0000 Message-ID: <17c8ae29ba052ac13b75b625997365da51af89ac.camel@nordicsemi.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=nordicsemi.no; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: fbf80885-084b-4b39-e1f3-08d95e6405e7 x-ms-traffictypediagnostic: AM8PR05MB7890: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: F+rl+XspNJQnEiZFfsSV/AJZp5nBkC5/T4ZUmBT7WOj7KUmUFWe1nyNTMlgEycC4dtCyx2T+cDFrIBNQARqzk0Me7EK4xbO5R7CpUVrNNuzGjlF7bg/1sdDrL5z2G4rUGxoyjjCYOg3gPq6BvToaDMIZkp28+1YzEShdViLWEkZHVVko5sjBdf+nvJ40FHuRvOelZkdfJvt/s7Ff05h2cierFGA/4+Ys+rMjYLmNDquONqqEggExnBd9/yHFNLFhBH0L8kY7XQh2WBG4hc2gsMveuTI3Vzbj1/IqE34gHTEsy0EQ15OKAMmsFxrFbEth4UD3puzfm/4GVPpZa1pNe2e92OyaDXlu4K409p3r7EHCoWrJZjjeg0CTUzOsu66QFta5hFzsrFJf0C6NspT4VdlsBI0j1LCfLpjn2agn9Hja9zxRj5638CwmPplk+BTXTE+bJfRQuILAV5EuXmCF4haF71no6UipxlB0sZKYANGlnyDSi7V2Bd596gIcf8i+v32gqKsoPeJZRsuf/jCh3IhPaD2jchrprNNbUa7d/9bvwGv4LqB8i2gHRwjLRSE6As+/3IwBGuPwsLLbah6ps4hcoccIfHlxDPJ5MMElbcpDf8CM4Z5pSavvMIDVT4e7oaOx92HaAT/dlpR3I4fcNKcWzFNRNpCHYRrIEFcb7Ttx5dPGLQEUclVKDc08hf7dQNWWInuf0FTtSpZX2WjaRdHv3qIgKPIX9MnU9GKGbXZaYalUYUQdp13TYi64WpogdNgNuq9CtWMBsKWeZ9PTmtDs4XRDlb0CMM9mDlfsxZs= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR05MB5873.eurprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(396003)(136003)(376002)(346002)(39840400004)(122000001)(66556008)(6916009)(38100700002)(66476007)(83380400001)(66946007)(36756003)(2906002)(64756008)(66446008)(6506007)(966005)(5660300002)(85182001)(8936002)(478600001)(71200400001)(186003)(8676002)(91956017)(38070700005)(2616005)(6486002)(316002)(6512007)(86362001)(4326008)(76116006); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?TEtKMDVsQmJHU21NeEhxeCtXWW5DTCtJUWpuM0I4bDJkUG9GSGxZeVc3L0xr?= =?utf-8?B?Nnc5aTB1MkQ4Q2ExdGlSOEhGL04wRWpWeFAvU1I4WmxJR0J4ZzRCeEEySjdD?= =?utf-8?B?MTZmRGg2ZlRGa3ZsU3hKWWJUMnQ3Y0JMNXIxU2NwNjZQT3FtVkdPNEs4Z3lB?= =?utf-8?B?MFZlTDQwdXdJemhrdXlvYVJjRVc4citCeVhkY3RJN2pZYnh2RG1CY1BlVWtt?= =?utf-8?B?d3phdDdaYnRNUmNOK3VFTTlzUUhlSHFzRUwrbTM0VDR3S0pkeWljaDRmQ1Rx?= =?utf-8?B?S1ZoSWRvaGpvaFlIbUhXTzhlaFpBSzU1SkNBa05qVHhENWhXc25MUXl5L0xx?= =?utf-8?B?ZmtFQldqd1AvNHJVSkJqT05XMGFxQ0MvMzZ5ZEp5UzZjRWhDN1gzcys3b2VO?= =?utf-8?B?ZDN5LzU2dWQ4VFhqcER5SDU4b0dNanh4Q1pFeVRhV2ZGQlNCSFJHZGJpbFAx?= =?utf-8?B?TFRCenV5Zk5UMGFYRzBneGVQUThWUThzaElEK1pLWnpDSTNEa1VuMlZIMHdP?= =?utf-8?B?Nm9LRWltZC91bENFRFlxNDFocWZTZTBObXRyUmxPaHAybmF3WEhVVEZvdTl4?= =?utf-8?B?US9zdi95RTI2M3BwajF2NGFmbDVOWGl2ZFlDcVV0bGtLbUIveU1JRFN6N0lh?= =?utf-8?B?ZlFTVHNXUEU2QTVVU1JxTHdQOUtiSFZtdElIRHlyWUtyZmxIRGlCR3JOWlFS?= =?utf-8?B?eVcvQUorc1kydUhRMWx3QkNZaER2endiQWNFOGhKOGRlcGZzWGtPbTZhby9i?= =?utf-8?B?M0lPYk1OTGVKNHQ1TlR4WlVuTG1JWEZ3ZkFJc1FJR2Q5Q3hveTh5RlUrTlkz?= =?utf-8?B?TUtvOEdCMDdZRlppeUVZOXlrcEtmS2dEQnFsZ1NaYUJkSzNLb1NUQVl0aVlx?= =?utf-8?B?VEJsK3lXOWhFM0w0Ly9va0l5aGovcGdBZVpKVXhMeHJpeFp1TW9tREN3OUIr?= =?utf-8?B?MlJJaDN5Z0hwZ0Rrd2ZUbzNDRlBhdUJKNDh1dkdEYmEwaGlUWWNjK1Q5UzVS?= =?utf-8?B?cWswc1FqeEJxQTBhZ0VGVW1EZ200bnlMUjl2T1A3dW4xSVJXKzJ5ZGIyK1gr?= =?utf-8?B?RFJ5ZGpRYllKL1BrZGFDZzhlY1E5UzhFK1JCODFYZ1VPSDJEUHlic0piS0dn?= =?utf-8?B?c2pqQlpCZGlTcnk3bnU0VE9FL0IybVc2d1NNS1NsSytnUVRQL1JOZWdKblBm?= =?utf-8?B?WG1leW5TeitneGwrZTAwNlc0aTZpVS9pR09GRlloRVZJbThlVldxNjJWVE5y?= =?utf-8?B?dlhRUVlRT3FXWlJFbzNWeFNSTWNPOElHOTZsaGwrUHlwU2VSQklzSlk3YWZj?= =?utf-8?B?dGFmaml5LzYzZ0ZjdXZuaW5HdWpJMkY0b2pmd3ZOSitVNW5oWWZXZUg5cGl0?= =?utf-8?B?WDc4Szd3TVhzZHRUdkJTSStYWkxaV1o0bXhvNWI0S1haeC91RnNmenJObk9r?= =?utf-8?B?K1QxQ3U3NnJjcStQTVZ1NDczdDJzMHNFc2hEWjdmaVpMbW5Za1o1T1lFckpy?= =?utf-8?B?NC8yV1NHd1NNWWtDc01iTkE2Yi9USXpaRy8vNjNoNXZlWkRxV2MwOTJQREQ3?= =?utf-8?B?bmR0d2ZDS3RsTitJVzdJVkdjN0xocHNJSXEyYWRnVjlwNjNJYlE1czB2NXdO?= =?utf-8?B?eUtvSTMrcUNRdzZZYWRxVld1QTNSbFdIMGVvTXBQbkdQeXJGMFJZaS9KbENP?= =?utf-8?B?dWNTRzRocXZvT2JVSGFhaFdxdWtFeFlPZmY0UjlKVFZtWUF6Qy9kVG82MTF1?= =?utf-8?B?T1NCT01vZFN2VjFiVVlha0Q5RW0rVWtOYUFna0dueURoWjBLVlh2Tm00NnNF?= =?utf-8?B?K010b3hPRTNLY1VEb2ZMenFBcWtodDkxZmF2SjNLRFVRR0hwNlBXNmxXancx?= =?utf-8?Q?0ikISLJexlq+F?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <35D0B058B9E5194381B33EFEC7035DF2@eurprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nordicsemi.no X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM0PR05MB5873.eurprd05.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: fbf80885-084b-4b39-e1f3-08d95e6405e7 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Aug 2021 14:09:53.7079 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 28e5afa2-bf6f-419a-8cf6-b31c6e9e5e8d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: wAVKRvhtph6vkZQlbvg8gsTTwl7woNrEOQOPp6ze89pkMAObY6hDGZc8br9no9JDfwyDWEG3ObQ3btMe4H8MMTIoQ7Fafz6QrObhO7qPINs= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM8PR05MB7890 Archived-At: X-Mailman-Approved-At: Fri, 13 Aug 2021 10:32:42 -0700 Subject: Re: [dnssd] WGLC for draft-ietf-dnssd-srp X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Aug 2021 14:11:27 -0000 SGksDQoNCkkgc3VwcG9ydCBwdWJsaXNoaW5nIGRyYWZ0LWlldGYtZG5zc2Qtc3JwLg0KDQpUaGUg b25seSBuaXQgSSBzcG90dGVkIGlzIHJlcGVhdGVkICJUaGlzIGtleSBwYWlyIE1VU1QgYmUgdW5p cXVlIHRvIHRoZQ0KZGV2aWNlIiBzZW50ZW5jZSBpbiAyLjIuNS4xLiBzZWN0aW9uLg0KDQpJIGJl bGlldmUgdGhpcyBwcm90b2NvbCB3aWxsIGltcHJvdmUgcGVyZm9ybWFuY2Ugb2YgaG9tZSBhdXRv bWF0aW9uDQpzZXJ2aWNlcy4NCg0KQmVzdCBSZWdhcmRzLA0KLS0gDQpIdWJlcnQNCg0KPiBIaSBE TlNTRCBlbnRodXNpYXN0cywNCj4NCj4gVGhpcyBlbWFpbCBzdGFydHMgYW4gb2ZmaWNpYWwgV29y a2luZyBHcm91cCBMYXN0IENhbGwNCj4gZm9yIGRyYWZ0LWlldGYtZG5zc2Qtc3JwLiBUaGlzIGNh bGwgYXNrcyB3aGV0aGVyIHdlIGJlbGlldmUgdGhlDQpkb2N1bWVudCBpcw0KPiByZWFkeSBmb3Ig cHVibGljYXRpb24uIEFzIHN1Y2ggd2UgYXJlIGFza2luZyB0d28gcXVlc3Rpb25zOg0KPg0KPiAx KSBpZiB5b3UgYmVsaWV2ZSB0aGlzIGRvY3VtZW50IGlzIG5vdCByZWFkeSB0byBwdWJsaXNoLCBw bGVhc2Ugc3BlYWsNCnVwDQo+IG5vdw0KPg0KPiAyKSBpZiB5b3UgaGF2ZSByZWFkIHRoZSBkb2N1 bWVudCBhbmQgdGhpbmsgaXQgaXMgcmVhZHksIHBsZWFzZSBzYXkgc28NCmFzDQo+IHdlbGwNCj4N Cj4gRm9yIHRoaXMgY2FsbCB0byBzdWNjZWVkLCB3ZSdsbCBuZWVkIHN0YXRlbWVudHMgb2YgZXhw bGljaXQgc3VwcG9ydA0KZnJvbQ0KPiBwZW9wbGUgd2hvIGhhdmUgcmVhZCB0aGUgZHJhZnQuIFBs ZWFzZSBzZW5kIHN0YXRlbWVudHMgaW4gZWl0aGVyDQpkaXJlY3Rpb24NCj4gYXMgcmVzcG9uc2Vz IHRvIHRoaXMgZW1haWwuIFRoaXMgY2FsbCB3aWxsIGJlIG9wZW4gdW50aWwgMjAyMS0wOC0xNQ0K MjM6NTkNCj4gVVRDLg0KPg0KPiBUaGFua3MsDQo+IERhdmlkDQo+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IGRuc3NkIG1haWxpbmcgbGlzdA0KPiBk bnNzZEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Ru c3NkDQo+DQo= From nobody Fri Aug 13 10:49:47 2021 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8DD33A20B4 for ; Fri, 13 Aug 2021 10:49:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.097 X-Spam-Level: X-Spam-Status: No, score=-18.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.499, 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 zGEvPZUMD091 for ; Fri, 13 Aug 2021 10:49:39 -0700 (PDT) Received: from mail-oi1-x22d.google.com (mail-oi1-x22d.google.com [IPv6:2607:f8b0:4864:20::22d]) (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 0A5543A20B7 for ; Fri, 13 Aug 2021 10:49:38 -0700 (PDT) Received: by mail-oi1-x22d.google.com with SMTP id w6so16959628oiv.11 for ; Fri, 13 Aug 2021 10:49:38 -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=UvuHlvydZwD66KOHqqHb1cmSAjdJThUxeGcb59PKVZI=; b=mgcsDHNHnj57f/6Ck8yyJ2qZ6FvELhiL7Mi5IqnZd+Qzt/Y60jCLUIbZb6uapxKxbW uSZSUE+OcMOoAQvitjZthJZnvMdHMVC/0MO5WHRoXvMyPXbCZSC3z6TAYHBT2CLFRiCj xWdYWyB1LQtC4kbRYDPSi75JfhqPFWcJzRec8P8vRt3zN1d2cm6xBg+KbrUhVGyxi5CL cqe/i9VFHKXeTpkueGHApq2c8XKblkB2/mHNu142LyUURvxkUt8Dw+NXjtozdTNnGXfW yr/R46xSfrCOlXMJ8cDFeDkEJPWw3hnrQlo53IjrFuNNbg8AbVlJgiKcG1ahzwROJT6B g0mg== 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=UvuHlvydZwD66KOHqqHb1cmSAjdJThUxeGcb59PKVZI=; b=eFGkTjPyALAhJOY46lYOd/AG2bGLRaenhOoj1Aerb9W/XzWPJIDM0MMwF+aiccXr/V 5ta3IRz4Xe8Ov9hfw9DQRhx/atipfKXeYgHh5ElOLDsU+8mAdeaQlKJx48JUspf7LAJp BkheSCQvIox79rlLBcCeFxZvXgbylBSp/zn6NduSbx20c1E6T1jgpZr5lW7UY6czPf4+ TRWkobmpxkMMO+Wp4mCrvqmR1XC/WrY28ni8S+gHr5S7v1HgMQXJ5OLWFe1JBtxr0Fq/ nHoIMMv0lcdAKZNTZ6K+O7WHQn3WWVLJKtESgX5P+NB+G41d63MVAHkrNJg3bOpV4X8o IpRw== X-Gm-Message-State: AOAM530e876WA1jFoD1ySCE5CoiT+TqFI3LD5zaq6NkQMNxn0bekhYWZ tMQlVh6hrd8TJbbGxPLZNfktUAa4hiUzcJaFGugPeLNbiIw= X-Google-Smtp-Source: ABdhPJwebnI+ZErB9jNLO9qJkqoILY0qm5gQyY8camvxzY+24yeDwksaAvq+hFpAeRCGWCpSca+rdKsJ15STsoBKdiU= X-Received: by 2002:a54:489a:: with SMTP id r26mr3117947oic.168.1628876976916; Fri, 13 Aug 2021 10:49:36 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Jonathan Hui Date: Fri, 13 Aug 2021 10:49:25 -0700 Message-ID: To: Ted Lemon Cc: dnssd@ietf.org Content-Type: multipart/alternative; boundary="00000000000097e4df05c974792a" Archived-At: Subject: Re: [dnssd] Adoption call for draft-sctl-advertising-proxy X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Aug 2021 17:49:45 -0000 --00000000000097e4df05c974792a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Aug 13, 2021 at 4:19 AM Ted Lemon wrote: > On August 12, 2021 at 11:08:44 PM, Simon Lin ( > simonlin=3D40google.com@dmarc.ietf.org) wrote: > > As Jonathan said, always using SRP regardless of whether the device is > connected via Thread or WiFi can solve this problem. Also maybe the > device can unregister itself from SRP when it has migrated to WiFi, > which requires the device to remember the IP address of the SRP > server, or to use draft-tljd-dnssd-zone-discover. > > I don't think dnssd-zone-discover helps with this. I think the client > needs to either unregister itself with SRP before migrating, or follow th= e > same protocol I mentioned earlier with respect to its service > advertisement: advertise without asserting uniqueness. > On Wi-Fi, the device needs to discover the SRP server. Why can't dnssd-zone-discover help with that? If there is a single SRP server in the network and it is servicing both Wi-Fi and Thread networks, we don't need to deal with conflicts. If there are multiple SRP servers, then I hope SRP replication will address the vast majority of cases. > > The only other alternative is to rename. I think this is too heavy of a > > > solution, but I'm open to debate. > > It increases the complexity on every device that needs to browse for > mDNS services. I would prefer SRP replication to renaming. > > This is a good point=E2=80=94SRP replication also increases complexity, b= ut it > constrains it nicely to the more capable nodes on the network=E2=80=94the= ones that > are acting as ad-hoc infrastructure and not as end nodes. > I hope SRP replication will eliminate the need for end devices to handle conflicts directly. Hopefully we can get some operational experience as to whether other mitigations are necessary. -- Jonathan Hui --00000000000097e4df05c974792a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Fri, Aug 13, 2021 at 4:19 AM Ted Lemon= <mellon@fugue.com> wrote:
On August 12, 2021 at 11:08:44 PM, Simon Lin (simonlin=3D40go= ogle.com@dmarc.ietf.org) wrote:
As Jonathan said, always using SRP regardless of whether the = device is=C2=A0
connected via Thread or WiFi can solve this problem. Als= o maybe the=C2=A0
device can unregister itself from SRP when it has migr= ated to WiFi,=C2=A0
which requires the device to remember the IP address= of the SRP=C2=A0
server, or to use draft-tljd-dnssd-zone-discover.=C2= =A0

I don't think dnssd-zone-discover helps with t= his. I think the client needs to either unregister itself with SRP before m= igrating, or follow the same protocol I mentioned earlier with respect to i= ts service advertisement: advertise without asserting uniqueness.

=
On Wi-Fi, the device needs to discover the SR= P server. Why can't dnssd-zone-discover help with that? If there is a s= ingle SRP server in the network and it is servicing both Wi-Fi and Thread n= etworks, we don't need to deal with conflicts. If there are multiple SR= P servers, then I hope SRP replication will address the vast majority of ca= ses.
<= div>
> The only other alternative is = to rename. I think this is too heavy of a=C2=A0
=
> solution, but I'm open to debate.= =C2=A0

It increases the complexity on every device that needs to bro= wse for=C2=A0
mDNS services. I would prefer SRP replication to renaming.= =C2=A0

This is a good point=E2=80=94SRP replication al= so increases complexity, but it constrains it nicely to the more capable no= des on the network=E2=80=94the ones that are acting as ad-hoc infrastructur= e and not as end nodes.

= I hope SRP replication will eliminate the need for end devices to handle co= nflicts directly. Hopefully we can get some operational experience as=C2=A0= to whether other mitigations=C2=A0are necessary.

-= -
Jonathan Hui
=C2=A0
--00000000000097e4df05c974792a-- From nobody Fri Aug 13 13:07:19 2021 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 661393A24C1 for ; Fri, 13 Aug 2021 13:07:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 YxRB6k0NJnhl for ; Fri, 13 Aug 2021 13:07:13 -0700 (PDT) Received: from mail-oi1-x236.google.com (mail-oi1-x236.google.com [IPv6:2607:f8b0:4864:20::236]) (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 990433A24BC for ; Fri, 13 Aug 2021 13:07:13 -0700 (PDT) Received: by mail-oi1-x236.google.com with SMTP id t35so17575173oiw.9 for ; Fri, 13 Aug 2021 13:07:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=rJWyypvg6mgwGFMJj9/9thFtzhnI8JuoUdAsBfVn26c=; b=aG5mnGAFs4UW6NnUv3TXph7MlUH/LAEkQ1L5Nvcn4L2fTdO51Ejzi8eeEjCc9vOnPd ERIa/j9sTUkuaL0WUu0WyjziFrHNmw2wPEsRXpbfmQc98Y4eR7QtNh3hjzsSkbmJLi8S bksRJmvHfdHCW3hGj1DM9cz1W56FxFvMWkkVY2Q77Z3+zNa0YrTVjPYTNENwKVKJ9MX8 mk/DUBh9gSeclhqeBAM4UianPwr8FVYgdTx+/bqKlKUVRMwxXf152x9xJ+djAaqtxB8v SirMClV9i6i/Jf0J8GqCd82S09JB9QlF3GHXZiGmF5TLmBabbMdcS2WhAKyVhNS3fv3N UXSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=rJWyypvg6mgwGFMJj9/9thFtzhnI8JuoUdAsBfVn26c=; b=ItkAwTjUldisLcmpk2/KlTNLnouEI5cMh/la5CoFibUWn7d2LNc8W8VON6GCEqL6vv 6WCBGbrQsi7CMceQWKxsmNsRZcmIsIuY8wJTUdRhvTz9vDhgsgDufGgw+ARgZKF8uRm5 Ui8oUGUwNDCr7kvC80vEaEwYyttlg6fH0p8/Z910BY5iK12b1MUdCaCykbFY8pwz0KdY aKgbs6s5fvroyBrQP0U6lbaAFhzW2FuQB1aLXYs57++/IWBaONsKCf9Dc2gfVZo4fN/e mNHtNajNT2VajbyNDqf4BDMX63VnMC5JfGP9IJC/Ng0nNJ9gG275anYGvLD43ugQNqQ+ VHTw== X-Gm-Message-State: AOAM533eNV5bVhkW+NvEY1yj4cnxpGX1vTrpFkhsEMXIt0Vp03cR/UeQ 7dpbNwJQ5VfD51ZJH+DsvwHGqid63XGgnyDfNuWHhg== X-Google-Smtp-Source: ABdhPJxbZGVpULeP8ohkFLBX/90oSUUnzf4tsmieZvMlYir+JcVMqglfhtHyFx6mM5Enn1NLJ8weUGgmyKZHoIzbqys= X-Received: by 2002:aca:2b05:: with SMTP id i5mr3459081oik.55.1628885231851; Fri, 13 Aug 2021 13:07:11 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Fri, 13 Aug 2021 13:07:11 -0700 From: Ted Lemon In-Reply-To: References: MIME-Version: 1.0 Date: Fri, 13 Aug 2021 13:07:11 -0700 Message-ID: To: Jonathan Hui Cc: dnssd@ietf.org Content-Type: multipart/alternative; boundary="0000000000009feca605c976651c" Archived-At: Subject: Re: [dnssd] Adoption call for draft-sctl-advertising-proxy X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Aug 2021 20:07:18 -0000 --0000000000009feca605c976651c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On August 13, 2021 at 1:49:37 PM, Jonathan Hui (jonhui@google.com) wrote: On Wi-Fi, the device needs to discover the SRP server. Why can't dnssd-zone-discover help with that? If there is a single SRP server in the network and it is servicing both Wi-Fi and Thread networks, we don't need to deal with conflicts. If there are multiple SRP servers, then I hope SRP replication will address the vast majority of cases. dnssd-zone-discover lets you discover DNSSD zones that you can browse. It doesn't tell you about the SRP server. We need a different DNSSD advertisement for that. Not a big deal. > > The only other alternative is to rename. I think this is too heavy of a > > > solution, but I'm open to debate. > > It increases the complexity on every device that needs to browse for > mDNS services. I would prefer SRP replication to renaming. > > This is a good point=E2=80=94SRP replication also increases complexity, b= ut it > constrains it nicely to the more capable nodes on the network=E2=80=94the= ones that > are acting as ad-hoc infrastructure and not as end nodes. > I hope SRP replication will eliminate the need for end devices to handle conflicts directly. Hopefully we can get some operational experience as to whether other mitigations are necessary. Yes. Well, FWIW, my current code does both SRP replication _and_ doesn't defend names, so we may be getting operational experience on both. :) Another thing to be aware of is that because of the way mDNS works, if you are using mDNS for discovery, a name conflict when names aren't being defended will sit around in the cache for a few minutes. If names are defended, this doesn't happen; one alternative is to just defend names and count on SRP to deal with conflicts, but the downside of this is that now there is a delay before the new information appears. This delay could potentially be minimized by retrying to register as soon as the SRP replication update has been acknowledged by all SRP replication peers=E2=80=94right now my code (when name defense is enabled) just waits t= wo minutes before re-attempting, which is a lot longer than should be necessary. --0000000000009feca605c976651c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
On A= ugust 13, 2021 at 1:49:37 PM, Jonathan Hui (jonhui@google.com) wrote:
On Wi-Fi, the device needs to discover the SRP server. Why can't dnssd= -zone-discover help with that? If there is a single SRP server in the netwo= rk and it is servicing both Wi-Fi and Thread networks, we don't need to= deal with conflicts. If there are multiple SRP servers, then I hope SRP re= plication will address the vast majority of cases.
=

dnssd-zone-discover lets you discover DNSSD zones tha= t you can browse. It doesn't tell you about the SRP server. We need a d= ifferent DNSSD advertisement for that. Not a big deal.


> The only other alternative is= to rename. I think this is too heavy of a=C2=A0
> solution, but I'm open to debate.= =C2=A0

It increases the complexity on every device that needs to bro= wse for=C2=A0
mDNS services. I would prefer SRP replication to renaming.= =C2=A0

This is a good point=E2=80=94SRP replication al= so increases complexity, but it constrains it nicely to the more capable no= des on the network=E2=80=94the ones that are acting as ad-hoc infrastructur= e and not as end nodes.

= I hope SRP replication will eliminate the need for end devices to handle co= nflicts directly. Hopefully we can get some operational experience as=C2=A0= to whether other mitigations=C2=A0are necessary.

Yes. Well, FWIW, my current code does both SRP replicat= ion _and_ doesn't defend names, so we may be getting operational experi= ence on both. :)

Another thing to be aware of is that because of the = way mDNS works, if you are using mDNS for discovery, a name conflict when n= ames aren't being defended will sit around in the cache for a few minut= es. If names are defended, this doesn't happen; one alternative is to j= ust defend names and count on SRP to deal with conflicts, but the downside = of this is that now there is a delay before the new information appears.

This delay could potentially be minimized by retrying to register as so= on as the SRP replication update has been acknowledged by all SRP replicati= on peers=E2=80=94right now my code (when name defense is enabled) just wait= s two minutes before re-attempting, which is a lot longer than should be ne= cessary.

--0000000000009feca605c976651c-- From nobody Fri Aug 13 13:41:04 2021 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B2393A2594 for ; Fri, 13 Aug 2021 13:41:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.54 X-Spam-Level: X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, 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, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=smartthings.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 C1yuwM8-KpDc for ; Fri, 13 Aug 2021 13:40:56 -0700 (PDT) Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com [IPv6:2a00:1450:4864:20::62f]) (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 8380B3A2592 for ; Fri, 13 Aug 2021 13:40:56 -0700 (PDT) Received: by mail-ej1-x62f.google.com with SMTP id u3so20516180ejz.1 for ; Fri, 13 Aug 2021 13:40:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=smartthings.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=28KGkDZojPIkmIBJTkjLlUOdZffrBax+9ROXz8hWBSk=; b=UZiM2lOssivC5dREsxcL3kifREYkJIKP0u2Q5xCJ8mpcGpAwqIAW9z98UjfpiCXs4c QECsfAGtxLTS31CUEqncV+5n5bCP4bP62WCQm3T2XtTBGI0vhsqHHIL6Q0/iPTUbsPtq dSHg+nrRfyBjfjdZQ3014cEUz0I03j9eygcvDoFhgeueDdyo9OpVuCgYEotQzyuyhlxy fRjkhEOvUoJbRAxhotUoLXp8B6ff8mKJkAN/1OvfCQIvR35HCfC+qYHDANb3VmmCNelK NzhzZrdbsSD+cutgGkEFsOsoECHzmEupX9NXdHrfzRMIrHskmpoAtJjZnG4oonbBcDbw wWig== 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=28KGkDZojPIkmIBJTkjLlUOdZffrBax+9ROXz8hWBSk=; b=jR9z2COfkROaZ/XOYhVlPspteyGyTWct/2Fjn0WVnMkFJbgdnJ7Kq0mN1M+3efjPTr Gv9A4WBzOOiMRRo5XZtjIAqVvEfz0oShU6M40ik2dQEyLWorV3mhNHTK2pRu7jDSB9F+ hNLFwEdGW2l+ubDkaOjwjWCVmR3DkOGKAwRYp7l1q9cTzugA5Sf5AWRzlQzYekTY0Tbx MCmsCErbtVBJk514Cd2Msza6GaLeqcSTT7S8jc24jR2S7Tusn1AzB2ZrXNzuJlJh2Nx3 HoSaNEmngNllXOMKymSTpPBNeX9UEq5EzjTsqPhtQW62Kufz/ZxVhniSo7XiIGeZR8A0 orGQ== X-Gm-Message-State: AOAM530nfvlGcWJDetT8FnekhjJl0M8jF/KpcF4bOxksSZaLrFW2yYmm +XbWOFR/3CIxxsyX8/6Iqj2wKDjcuUhQPz2MGEXRV/zLXJbYlw== X-Google-Smtp-Source: ABdhPJyJOOvLcu+SUcTCklL6QV9Ctpdrxe46/JxrYaCw2rHlCqNp6Ui1JV7NV5DM+gDs8WBxsYOcvl1Za3C/2yU8j0w= X-Received: by 2002:a17:907:3e05:: with SMTP id hp5mr4289511ejc.527.1628887252243; Fri, 13 Aug 2021 13:40:52 -0700 (PDT) MIME-Version: 1.0 From: Saurabh Kumar Date: Fri, 13 Aug 2021 13:40:41 -0700 Message-ID: To: dnssd@ietf.org Content-Type: multipart/alternative; boundary="0000000000000cb78505c976deaf" Archived-At: Subject: Re: [dnssd] WGLC for draft-ietf-dnssd-srp X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Aug 2021 20:41:03 -0000 --0000000000000cb78505c976deaf Content-Type: text/plain; charset="UTF-8" Hi, I'd like to add my support for publishing the draft-ietf-dnssd-srp. We have been experimenting and getting familiar with the OpenThread SRP implementation for Thread Border Routers and found that this technique is critical for bridging the gap between Thread networks and the Infrastructure network. The OpenThread SRP implementation is also being used in Matter and is already integrated into the Matter SDK. regards Saurabh | Samsung SmartThings --0000000000000cb78505c976deaf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable --0000000000000cb78505c976deaf-- From nobody Fri Aug 13 13:50:28 2021 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 875053A25DA for ; Fri, 13 Aug 2021 13:50:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, 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=smartthings.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 rwjZ1v8lqAzN for ; Fri, 13 Aug 2021 13:50:13 -0700 (PDT) Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) (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 8CF633A25DB for ; Fri, 13 Aug 2021 13:50:13 -0700 (PDT) Received: by mail-ed1-x533.google.com with SMTP id dj8so9337587edb.2 for ; Fri, 13 Aug 2021 13:50:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=smartthings.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=iNThJpcMipYupxHHvPWVK6N9Fsg/edwiQi3oen09WYg=; b=fxmOyYMcOz8Je317/N8N9tl54adpG1LXwxMLb1Rb0JGT2UKdGgbQO3yFF67ngptCqc YNy8V2N86tw/9Yw/su7PPHcaSJdQX+k4P0Oyi0bl3YvqDF9nUgsclsWF8SmvqcdWaOEM 8ajx6b0PfwInmPD/8SthzVEuV4D/lStd1+ATxO1Xtp8PW1QRvCLsLpHaJjUKOBKlk7q9 ADChLGt1RcObOmVTWODGozSlurTGmeFOQdguvdY/HZ753GvLtYuzl1tuiuW1ONrohe1y sKD2wqTM7NxIX5+HN9A16CESNvTZRLqatVVvGmU9fh1RO+tC9AHdpym7gEOFMngVcD1f p1Pw== 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=iNThJpcMipYupxHHvPWVK6N9Fsg/edwiQi3oen09WYg=; b=NzSddeE/j+WTEei+m4lAfBGijjLvyTy9QCpyE/2iWhLzIRO8tV73854BwoJEfCtVLe 8tZTLyOCBDPGSNIGv3E9YttD2hNATk8io30M7fQyuWMxH0f8N72xmIr6swgZdaDmOWK6 Cw7I4OOZPHyj4VZHEzu82jl2Si/Yj7CNcx65/4Hb6E3sqmrgjCQWXWzq3wPnex7CWDeX VRUycKVRs+zet8Bt7FYlkzFWkOQRVS5tfGfdb3/Ozb8Q60mcGxulF8EbuWkbw9piqEXp cwrO/+eVBnBJU/3ox7OL8n1JE+XE+Taf+HRsNTzW+EM2OB8HuK58m9BS6c/Xw+l/iq2A Jqdg== X-Gm-Message-State: AOAM530LENY9kOxq5qKgl7nd4CvsmSGSIc6S8W0n2JN4bnqkYzx1aQaX UPE88T2KrfNfFPQGThTfqNzr/Um2sIRRqDc/GRtFogFrXWyFMw== X-Google-Smtp-Source: ABdhPJxEu751ZOOlvbQZrgxBvqesdKtiuYk2msbunPwqxvadJDYzYfDu+NY3tMXMnsGqAAFK8pwIjPimGkp328fmoMk= X-Received: by 2002:aa7:df03:: with SMTP id c3mr5318683edy.348.1628887811002; Fri, 13 Aug 2021 13:50:11 -0700 (PDT) MIME-Version: 1.0 From: Saurabh Kumar Date: Fri, 13 Aug 2021 13:50:00 -0700 Message-ID: To: dnssd@ietf.org Content-Type: multipart/alternative; boundary="0000000000005aaacb05c976ff14" Archived-At: Subject: Re: [dnssd] Adoption call for draft-sctl-advertising-proxy X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Aug 2021 20:50:20 -0000 --0000000000005aaacb05c976ff14 Content-Type: text/plain; charset="UTF-8" Hi, I'd like to add my support for adopting draft-sctl-advertising-proxy-02 by the workgroup. I have read this document in detail and I would like to support its publication.The advertising proxy is a key enabler of service registration and seamless discovery in Thread Networks. Advertising proxy connects legacy multicast DNS clients on Wifi with Unicast SRP clients on the Thread network. Matter standard that relies on mDNS service discovery is planning to use this mechanism and the implementation of the mechanism based on this draft document is currently underway in matter WG. Comments -> Sec 2.5 of the draft spec uses the word reconfirm in quotes ( " reconfirm") as well as in bold letters (RECONFIRM). Is there any significance of using this word in different forms ? regards Saurabh | Samsung SmartThings --0000000000005aaacb05c976ff14 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,
I'd like to add my support for=
 adopting draft-sctl-advertising-proxy-02
<https://datatracker.ietf.org/doc/html/draft-sctl-advertising-pro=
xy-02>
by the workgroup.
I have read this document in detail and I would like to support=
 its publication.The advertising proxy is a key enabler of service registra=
tion and seamless discovery in Thread Networks. Advertising proxy connects =
legacy multicast DNS clients on Wifi with Unicast SRP clients on the Thread=
 network. 
Matter standard <https://b=
uildwithmatter.com/> that relies on mDNS service discovery is planni=
ng to use this mechanism and the implementation of the mechanism based on t=
his draft document is currently underway in matter WG.
Comments -> 
<Editorial>=
; Sec 2.5 of the draft spec uses the word reconfirm in quotes ( " reco=
nfirm") as well as in bold letters (RECONFIRM). Is there any significa=
nce of using this word in different forms ? 
regards
Saurabh | Samsung SmartThings


--0000000000005aaacb05c976ff14-- From nobody Fri Aug 13 15:25:00 2021 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 312AE3A28AA for ; Fri, 13 Aug 2021 15:24:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.097 X-Spam-Level: X-Spam-Status: No, score=-18.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.499, 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 fGUm245WeBNa for ; Fri, 13 Aug 2021 15:24:52 -0700 (PDT) Received: from mail-oi1-x22e.google.com (mail-oi1-x22e.google.com [IPv6:2607:f8b0:4864:20::22e]) (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 79D373A28A3 for ; Fri, 13 Aug 2021 15:24:52 -0700 (PDT) Received: by mail-oi1-x22e.google.com with SMTP id w6so18020240oiv.11 for ; Fri, 13 Aug 2021 15:24:52 -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=/r4NGcL5k+fiNeheeN8uBdqBtgh/d9587eRdaIqGj64=; b=MSJ8kGNYam64WnLiL1Kj7cmsGsgLKCJVk5OO6+bE8ZQDblNmFRTcznMEF/8lWKcOyH R8LcWdx5MrtCEX0RAGJdlj56nlum8+7931HhYCn5J+pnx1OjbrW25NKzEs5YMF76zIuH Uhf/PqkGptT1dlR1Ir1jy7cdM0+k+DetdB8/o/kZI8XFvJpd9pI4AKtV0+LqclYmcf3U G7ifPNt3gWOusLyxsntSCHgnWAQPiUYPk5+pLMDHhBys+VvRDoM4bHniPDOT72tc/i1O adP0354QZaWn4Pa345VqiQUH9flbf5wpRY+bHAHw7A9NtQP2TEM3/GmkkS7hkFWyr/Pe vIYw== 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=/r4NGcL5k+fiNeheeN8uBdqBtgh/d9587eRdaIqGj64=; b=knKUMBSnHqgIwAhU6prjrcuQayCRJpUIvzkDLZ87A9Q+eCVgZOb/H9lHLYgfXT8Y5Q r8ALhOQ52X+cwMXpPfid/JZUYlhsxKyVPh2NYmMhFK8cWTW//Pas2tvZjNHWNVUK/Pkw qtb+QAoYM7IQmE1GKYnCPeykj9DPLIZgJ4lrp5Je6aC0lrkpCSNWQrexSTundPlrCkLt FlfcO9s5/l/seEqH0klBG0jiDHj3V4nV46GSBA0TvKRB3HC1u7NCMN7MpkZzu5LkqQ+O 1UtNvrGuhw6mBh6gFxAbgsnlnZi5zdLwIj0NTXzPz/aacM2orFJneACQE9eQGtgx0Qhy jRrQ== X-Gm-Message-State: AOAM532akZ4NfSdyza+wac8hmEGXuHi3XKCZCvMJGDiEEdCta3X0vo31 1on+j6hJhsEf9kZeDG0SijAsowIvO96ISrenOfC9HwouFJ0= X-Google-Smtp-Source: ABdhPJxttz7DSII3MVnOcFEsChmXOmTrtqOrtDGTDNFRCAYooA3++n5V1VIxHQ3b8naeTVzoO3kpE+6zt4ggZlTdGtY= X-Received: by 2002:a05:6808:d53:: with SMTP id w19mr3869332oik.24.1628893490726; Fri, 13 Aug 2021 15:24:50 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Jonathan Hui Date: Fri, 13 Aug 2021 15:24:39 -0700 Message-ID: To: Ted Lemon Cc: dnssd@ietf.org Content-Type: multipart/alternative; boundary="000000000000e49acf05c9785182" Archived-At: Subject: Re: [dnssd] Adoption call for draft-sctl-advertising-proxy X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Aug 2021 22:24:58 -0000 --000000000000e49acf05c9785182 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Aug 13, 2021 at 1:07 PM Ted Lemon wrote: > On August 13, 2021 at 1:49:37 PM, Jonathan Hui (jonhui@google.com) wrote: > > On Wi-Fi, the device needs to discover the SRP server. Why can't > dnssd-zone-discover help with that? If there is a single SRP server in th= e > network and it is servicing both Wi-Fi and Thread networks, we don't need > to deal with conflicts. If there are multiple SRP servers, then I hope SR= P > replication will address the vast majority of cases. > > dnssd-zone-discover lets you discover DNSSD zones that you can browse. It > doesn't tell you about the SRP server. > Ah, yes, I was confused. Thanks for clarifying. > We need a different DNSSD advertisement for that. Not a big deal. > Yes, agreed. > Yes. Well, FWIW, my current code does both SRP replication _and_ doesn't > defend names, so we may be getting operational experience on both. :) > That's great to hear! > Another thing to be aware of is that because of the way mDNS works, if yo= u > are using mDNS for discovery, a name conflict when names aren't being > defended will sit around in the cache for a few minutes. If names are > defended, this doesn't happen; one alternative is to just defend names an= d > count on SRP to deal with conflicts, but the downside of this is that now > there is a delay before the new information appears. > > This delay could potentially be minimized by retrying to register as soon > as the SRP replication update has been acknowledged by all SRP replicatio= n > peers=E2=80=94right now my code (when name defense is enabled) just waits= two > minutes before re-attempting, which is a lot longer than should be > necessary. > Sounds like a good idea to explore. My initial concern is that waiting for positive confirmation from all peers can lead to other failure modes resulting from poor implementation or connectivity. At the same time, those same assumptions are what would lead us back to needing other mitigations. -- Jonathan Hui --000000000000e49acf05c9785182 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Fri, Aug 1= 3, 2021 at 1:07 PM Ted Lemon <mellon@fugue.com> wrote:
On August 13, 2021 at 1:49:37 PM, Jonathan Hui (jonhui@google.com) wrote:
On W= i-Fi, the device needs to discover the SRP server. Why can't dnssd-zone= -discover help with that? If there is a single SRP server in the network an= d it is servicing both Wi-Fi and Thread networks, we don't need to deal= with conflicts. If there are multiple SRP servers, then I hope SRP replica= tion will address the vast majority of cases.

dnssd-zone-discover lets you discover DNSSD zones that you= can browse. It doesn't tell you about the SRP server.

Ah, yes, I was confused. Thanks for clarifying.=C2=A0

We need a different DN= SSD advertisement for that. Not a big deal.

Yes,= agreed.=C2=A0
=
Yes. Well, FWIW, my current code does both SRP replication _and_ doesn'= ;t defend names, so we may be getting operational experience on both. :)
That's great to hear!=C2=A0

Another thing to be aware = of is that because of the way mDNS works, if you are using mDNS for discove= ry, a name conflict when names aren't being defended will sit around in= the cache for a few minutes. If names are defended, this doesn't happe= n; one alternative is to just defend names and count on SRP to deal with co= nflicts, but the downside of this is that now there is a delay before the n= ew information appears.

This delay could potentially be minimized by = retrying to register as soon as the SRP replication update has been acknowl= edged by all SRP replication peers=E2=80=94right now my code (when name def= ense is enabled) just waits two minutes before re-attempting, which is a lo= t longer than should be necessary.

Sounds like a= good idea to explore. My initial concern is that waiting for positive conf= irmation from all peers can lead to other failure modes resulting from poor= implementation or connectivity. At the same time, those same assumptions a= re what would lead us back to needing other mitigations.

--
Jonathan Hui

--000000000000e49acf05c9785182-- From nobody Fri Aug 13 15:40:40 2021 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 304493A2923 for ; Fri, 13 Aug 2021 15:40:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 p2iELRaWmC0K for ; Fri, 13 Aug 2021 15:40:37 -0700 (PDT) Received: from mail-ot1-x332.google.com (mail-ot1-x332.google.com [IPv6:2607:f8b0:4864:20::332]) (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 9D62B3A2922 for ; Fri, 13 Aug 2021 15:40:37 -0700 (PDT) Received: by mail-ot1-x332.google.com with SMTP id d10-20020a9d4f0a0000b02904f51c5004e3so13856655otl.9 for ; Fri, 13 Aug 2021 15:40:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=iCZlNhQF22Jn6KWkF8Heb8x9CnnF9ll29+aNkw3j5zM=; b=s8Md3W126eosAppzrsWo1bnDWowUrMVoPM6/BRy1PajvNLwomIn0O4wbdA3WsBlkvL lZsEOmIHsQETHP3lCUsJe8JxTaqqya2p9V7gFiKOUb9+7Tmtj+dYbSb23+y1z/p90dnL c+9iZjBb7RcxcxsgldwS9WSe28u13rQ6e61WbfjFUrenPrZ8gd3SXzMbCwY1kid4f7OA DxCFHb4Bh8he57HDTw9NcboykNOJQqe5SvhsoSDlSzAjJFqIuqtq8pUgelKHPW6i0oeZ rdBbtPmI5/KaxK7Ne6IEgAqy1zry7n2zOxPDzJre7IUcYiUb/wbnxthC2kxOb5gDXNuk zjvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=iCZlNhQF22Jn6KWkF8Heb8x9CnnF9ll29+aNkw3j5zM=; b=DqwBPe9u9O8BzQ7RkCcs49wodYG/Bg+Mn7Yp09jT40K10Ew+4GEGu6Ruf9+oApbItg kmwrKhCbI57TCnKWYPipZXXNk0H9+qIistMwwnE9cZhy0aqoYYe/Ed8opqt3u19OlHc0 8RGu+yTUnBMSuAAFsYaXCuq7oGiv9B7DYIqPGYAClF4cdFUX/hQNKLPIVMMic2Q4Frnn 1jkkERFkxDvvyruXA5S/psiganD35oZjy8tt5xwHxsOIa+uVLsVfUsmyN3JYMUDjlqIV dwP48IZrZ+p7c139suaIZdz94HoF/ZNPihGzeJyVDrCzGngfAJP5a+YbmsGFc5ai+dyv wPEg== X-Gm-Message-State: AOAM531zlmodROKHsuVI437Pcd5h4W8ukksomdmaP+eYJ77cTBo9UfGQ 0Xv0c6uSxV8Y04QXDVnc22GNFzzYI1FHSfFduXcMkg== X-Google-Smtp-Source: ABdhPJz/68Dg+arUzgFoy9ycbB2T7QblkQx8fJEIWGMP4vo8faFcx7bKq72fb/lNtgOaKVNRPBffCREcsj/C5wkHxTw= X-Received: by 2002:a9d:491c:: with SMTP id e28mr3812509otf.342.1628894435266; Fri, 13 Aug 2021 15:40:35 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Sat, 14 Aug 2021 00:40:34 +0200 From: Ted Lemon In-Reply-To: References: MIME-Version: 1.0 Date: Sat, 14 Aug 2021 00:40:34 +0200 Message-ID: To: Jonathan Hui Cc: dnssd@ietf.org Content-Type: multipart/alternative; boundary="00000000000030ecf305c9788a89" Archived-At: Subject: Re: [dnssd] Adoption call for draft-sctl-advertising-proxy X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Aug 2021 22:40:39 -0000 --00000000000030ecf305c9788a89 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On August 13, 2021 at 6:24:51 PM, Jonathan Hui (jonhui@google.com) wrote: Another thing to be aware of is that because of the way mDNS works, if you > are using mDNS for discovery, a name conflict when names aren't being > defended will sit around in the cache for a few minutes. If names are > defended, this doesn't happen; one alternative is to just defend names an= d > count on SRP to deal with conflicts, but the downside of this is that now > there is a delay before the new information appears. > > This delay could potentially be minimized by retrying to register as soon > as the SRP replication update has been acknowledged by all SRP replicatio= n > peers=E2=80=94right now my code (when name defense is enabled) just waits= two > minutes before re-attempting, which is a lot longer than should be > necessary. > Sounds like a good idea to explore. My initial concern is that waiting for positive confirmation from all peers can lead to other failure modes resulting from poor implementation or connectivity. At the same time, those same assumptions are what would lead us back to needing other mitigations. The problem with anything that's ad-hoc and not integrated into the infrastructure is that there's no model that guarantees success. It's always going to be best effort. The goal has to be to make "best" as good as possible, but have a backup strategy for when it's not quite good enough= . --00000000000030ecf305c9788a89 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =

=
On August 13, 2021 at 6:24:51 PM, Jon= athan Hui (jonhui@google.com) wrot= e:
<= div class=3D"gmail_quote">

Another thing to be awar= e of is that because of the way mDNS works, if you are using mDNS for disco= very, a name conflict when names aren't being defended will sit around = in the cache for a few minutes. If names are defended, this doesn't hap= pen; one alternative is to just defend names and count on SRP to deal with = conflicts, but the downside of this is that now there is a delay before the= new information appears.

This delay could potentially be minimized b= y retrying to register as soon as the SRP replication update has been ackno= wledged by all SRP replication peers=E2=80=94right now my code (when name d= efense is enabled) just waits two minutes before re-attempting, which is a = lot longer than should be necessary.

Sounds like= a good idea to explore. My initial concern is that waiting for positive co= nfirmation from all peers can lead to other failure modes resulting from po= or implementation or connectivity. At the same time, those same assumptions= are what would lead us back to needing other mitigations.

The problem with anything that= 9;s ad-hoc and not integrated into the infrastructure is that there's n= o model that guarantees success. It's always going to be best effort. T= he goal has to be to make "best" as good as possible, but have a = backup strategy for when it's not quite good enough.


--00000000000030ecf305c9788a89-- From deng.qiaoyu@gmail.com Fri Aug 13 16:30:45 2021 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 815013A2A90 for ; Fri, 13 Aug 2021 16:30:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.097 X-Spam-Level: X-Spam-Status: No, score=-1.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, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XDAFeAOlhLKX for ; Fri, 13 Aug 2021 16:30:40 -0700 (PDT) Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) (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 556213A09E8 for ; Fri, 13 Aug 2021 16:30:40 -0700 (PDT) Received: by mail-lf1-x129.google.com with SMTP id g30so22875253lfv.4 for ; Fri, 13 Aug 2021 16:30:40 -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=U9JA38tH1Ubvq/aiao3+ej2h70FFObKaXyv0JqZ0q6o=; b=EMg8ukRwssu5wPpv1/MGYN6oRKmtHLzxec7bc3Fd8C92A/Zd/wGpctZXNhYFCEAvs5 ysl7Jdp1HHqByUkG0D7kwCoapLAQLWEEvrgXpL0tvGyyC5JbeFp9kuxawNXRCcdQTX7/ AbHOhq8JypzruLHWxdFP4hl4h9FFeCGys5RpRr37yFybL9SgcYKZryIsGJ/bUFPXQrMh 2//6njjyyVYIz4FfS0bh2+tEmTMfp0Sx+lplrwXvV/A+nrfaRgxILlzJJ2bF28W3A816 eldt6LJEqvyiyHxxuuGk+F36vfsdDnfVoZq2COucAAHlk00QkssDzyJrHSzBFHOhSQEK /i7Q== 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=U9JA38tH1Ubvq/aiao3+ej2h70FFObKaXyv0JqZ0q6o=; b=S2nT0iaB5ABtGZhZLRKwXHYnXwnBs03c3/w6O7fSK2NoDAYCzMKYUHjRN7CWC31HEE bQRAFoNApaUSHxuu59b6EYHYzOTptJX2ARvVRDlp+lQlY5JbWApKljUETs7Lq8DLSn7G 38sXa1+rkQ6DVQUbwwIjjfPsuD/2tNjRhLjumYuOs6CFrxq3BI/0DF2J5PPClfMLTSwB 9pVvIuoLkq3Dyi4F1KDXoDgwEZNHVAehyDCLIAtuame0B/Ad9Oj8p/j/GOlaoQB/wFT7 vfVapwTFNRG5TAn1sUfS2NVu5YUSaHvuJxjLFDUu8CVY8bmf5wQT9o6SwVYKvdl8AbTG mO1w== X-Gm-Message-State: AOAM532YMcSnNMd7pg2SH/iRUBj76OJQa6GNBB9tqR1SqE6Q1n+5jzdP TefQazexhgNy5Ixdeo2E4OFy11+ZzPubfywMQmFCHLgg0c4OIw== X-Google-Smtp-Source: ABdhPJwsdK2vmoqyn1/8h/t8awep0oWCjcoOJQ9PS8VI8vaBt98u/yh/gGudvWMe+fbmHj/3Be5UozWLBwg68HvfIjg= X-Received: by 2002:a05:6512:4010:: with SMTP id br16mr476591lfb.70.1628897433391; Fri, 13 Aug 2021 16:30:33 -0700 (PDT) MIME-Version: 1.0 From: Qiaoyu Deng Date: Fri, 13 Aug 2021 16:29:57 -0700 Message-ID: To: dnssd@ietf.org Content-Type: multipart/alternative; boundary="000000000000e496ef05c9793c43" Archived-At: Subject: [dnssd] Supporting draft-sctl-advertising-proxy X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Aug 2021 23:33:44 -0000 --000000000000e496ef05c9793c43 Content-Type: text/plain; charset="UTF-8" Hello, I'd like to add my support for adopting draft-sctl-advertising-proxy-02 < https://datatracker.ietf.org/doc/html/draft-sctl-advertising-proxy-02>. I have read this document carefully and would like to support it. Over the last year, I have been working with Ted and the implementation of SRP proxy, and it really solves the problem of allowing old mDNS-capable-only devices to discover those services that are advertised with unicast-based SRP. Comments: 1. ---------- 2.1. Name Conflicts ... If any of them fail, they must all be removed and the client* is *notified of the failure. ... ---------- 2. Since the entire document uses terminology "Advertising Proxy" instead of "advertising proxy", here: ---------- 2.1.1. Name Conflicts in Managed Namespaces ... a way for the advertising proxy to inform the mDNS service that it ... ---------- "advertising proxy" should be "Advertising Proxy". Thanks. --- Qiaoyu(Joey) Deng --000000000000e496ef05c9793c43 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,

I'd like to add my support f= or adopting draft-sctl-advertising-proxy-02 <https://datatracker.= ietf.org/doc/html/draft-sctl-advertising-proxy-02>.
I have read this document carefully and would like to support = it. Over the last year, I have been working with Ted and the implementation= of SRP proxy, and it really solves the problem of allowing=C2=A0old mDNS-c= apable-only devices to discover those services that are advertised with uni= cast-based SRP.

Comments:
1.
-= ---------
2.1.=C2=A0 Name Conflicts
...
I= f any of them fail, they must all be removed and the client is notified of the failure.
...
----------

2.
S= ince the entire document uses terminology "Advertising Proxy" ins= tead of "advertising proxy", here:
----------
=
2.1.1.=C2=A0 Name Conflicts in Managed Namespaces
...
a way for the advertising proxy to inform the mDNS service that it<= br>
...
----------
"advertising prox= y" should be "Advertising Proxy".

T= hanks.

---
Qiaoyu(Joey) Deng
<= br>
--000000000000e496ef05c9793c43-- From nobody Sun Aug 15 13:37:30 2021 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 075643A0865 for ; Sun, 15 Aug 2021 13:37:28 -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, 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.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=iotconsultancy.nl 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 lD1Xv9WjIY00 for ; Sun, 15 Aug 2021 13:37:21 -0700 (PDT) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2101.outbound.protection.outlook.com [40.107.20.101]) (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 9B2273A0860 for ; Sun, 15 Aug 2021 13:37:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JdKVtVRJ0LhMDZpeSV+g7/PSE2GLFipgRztXBpNk9Z4sJl1s8hGgtugs/cOg7XTLqfi+P0lmTkXA60WUtzD6keZTUMX2dAyJk6/PXsUrSlXbCZ72XdyXcdrxS+mCaeTwv1hJUQVPQNYMg8fhxBll2QQDnEbId2PRIgxnP9zuSrlRdt5G32sgeFc8wSO1IVN+6huptaLe5BxK2BHBHLRTnV/6NkoHK1JgRNjsfB77v+5w21xfkucGM0pvdKktOyTgNoranHG4CCjqtshI8dHZEgfJZGwNXjJiITF/P7SUgK0KEHTHogF+UHkJnO2VnBRJ+2r4tK6yPDgm2kQHuThZSQ== 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=yAnrQQHtvUZoH7z+cx7t2TuJo4cPR08LCkEZOqQfU6c=; b=SBCZzFPN5SW9DS1P/EDjUM24ESWc54Ns+slP3lcZWcDv+s/kWOgvAVk6NNr7AQ+ptm2cP+KdFpChWufaOK9hpbBJgTvXOWs8E9qQ/3i6JK6fb1/xS1REwndaslLVAFTLh01Wd7m7D5nGwF9p3V+sKaEMyvhPLzhmbnjqveprCPFcHHR1vwLd1LaMJ35/Q6KGdRbw2KheJ/iBzWM0bJtlbYih061q473qeHHLGhtBIViox53IKADP5YEYb9kmJKcP6GhjRHzgE0rqvdAroN/YFkYacfiUImljP8bvijThSAU3FhojhzOM/M7W794pgJQKzLE0lttTVWFOJWVoqxrwcA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=iotconsultancy.nl; dmarc=pass action=none header.from=iotconsultancy.nl; dkim=pass header.d=iotconsultancy.nl; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iotconsultancy.nl; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=yAnrQQHtvUZoH7z+cx7t2TuJo4cPR08LCkEZOqQfU6c=; b=hwUTZhdIISHQ/CndFvP7GdE5gCIKtpUgZcP3AWAuRdE8eXfusSbz0/gj8xjEGQBeVaiICgH4YjKnvho67gRRwaFZcgjWGQgMnBglZiYcYpWQ0UgNFSxXhpjgvgfAJjHj/ZVXvIJLSHjA14w4N0e+9xkrKliGFG0y6WqFfg3w7Eg= Received: from AM8P190MB0979.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:1d3::8) by AM9P190MB1251.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:26d::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4415.16; Sun, 15 Aug 2021 20:37:18 +0000 Received: from AM8P190MB0979.EURP190.PROD.OUTLOOK.COM ([fe80::44fa:5ced:a434:f7e8]) by AM8P190MB0979.EURP190.PROD.OUTLOOK.COM ([fe80::44fa:5ced:a434:f7e8%9]) with mapi id 15.20.4415.023; Sun, 15 Aug 2021 20:37:18 +0000 From: Esko Dijk To: David Schinazi CC: DNSSD Thread-Topic: [dnssd] WGLC for draft-ietf-dnssd-srp Thread-Index: AQHXg/uXpHkdwfwTxUqdaLXgBnemG6t1Iisg Date: Sun, 15 Aug 2021 20:37:17 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=iotconsultancy.nl; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: afe9da02-e43c-4a78-f041-08d9602c7959 x-ms-traffictypediagnostic: AM9P190MB1251: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: y36xr5IL2TDQ6typ6Lq9S5ap6DROC5v21utbwCN6OTvlfH6p8mZ9RVsIm9Bdm0WJkX4RvW7u99glNkFJshHOaXXjsyiIOjznA4j5ci2AwIugOv+NIgPLycrAgBapbkYdUQ3vXsvz1502As0AW7ieZd14Nk9XNVXhzkzFm4w923rOEQTrrsyl7DdXYwUl1fhpzd2KHDIcmd5FGFBOe5pRg0pKrD/Rf2kGCPc8q9iPbda9Cgj54SgiOiUasB1LDCplRAiirmoascNUjO2/qoU9fDX/D5d4/irS0S7u3pj3eFi2gbj821zv6MLL0mm6t4CWnfwkYcivJM1D6twVBRJDDTSkA/VHM1NkGHDVnmBV4NM95XPBmL2TNv7R+VH9H7pzDGMXbBuffX9NNam/JzYJyYnysweJIu/ApJKdB7ytW7Y59V3wGzxNt3Vkk9+TIHPeZ50L+DpBRXcJ3N4zPR9N89+nNxfjp9vLl7nlo0MCKPDMTvkd3AEctT7SFvcmXxoCKQ2IJZsTWHhBhMEChlR57v6LIWCFsFXQNIUm/KxWjK9rgN3yyduoPO8BoEvwa6aBBPiC9qKnKLCeUkjhlqa4INZt4L/QJHm6inKoKeDQpwml6/nuyQNV87qAjQq9ayvDtWpXFXjBlt7et4fYm/qgZwZcHDiItT5awHjsOL85I5yqIH5wF6O9fI9Pf0FOLTga/TfSq1sER8+WP64iCEJZqg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM8P190MB0979.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(39830400003)(366004)(396003)(136003)(346002)(376002)(478600001)(44832011)(6506007)(53546011)(55016002)(186003)(8936002)(9326002)(7696005)(316002)(52536014)(6916009)(83380400001)(71200400001)(8676002)(122000001)(66946007)(4326008)(38100700002)(38070700005)(9686003)(33656002)(2906002)(66476007)(66556008)(64756008)(66446008)(76116006)(5660300002)(86362001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?WGs5TllYWDAxci9FLzN6ZU9NK1dyTm9md2o1djAwdGc5L2xsRmNjeWp2cmU5?= =?utf-8?B?dnJ5SW9tKzd4bDhLM211SmI3eng0MGx5SElnSXhFWVFGaWFDNWFoUzZaeDI2?= =?utf-8?B?ZkJjcnFzbTFUc2hrMjdkVFdYUmhmM2l1YXZ0YytqUThka1h0cGdTcTFncEF4?= =?utf-8?B?VXlCbFJWMHhWemxncE8vV0Zua2c1b1htenJoaDdqSDFnNUhnVXJFL0o4RlJo?= =?utf-8?B?QTNDcU01eFRsQlpwVWlXY2RzSDhUTFZoK29KcVlMZ1BmYXZHNzVDUW5oYml0?= =?utf-8?B?cHBWekhkYmJnRitnZG1VenY5R3E0Ujc1Ui9BbmYrM0VPaXRGamVPS1BSSTZE?= =?utf-8?B?d2RRWXdlMmE3c3RFZE50WVRScjlKVGhNTFVld0J1R1oraTlMeGRPVEZxUWlS?= =?utf-8?B?YlAvai96NXhGTUViNFRtNDNUUDBVV1BYTXVsMlhOanpyTWI1MFRjRDdSZE1O?= =?utf-8?B?YmFKdWxhUnJ3amE4N3FudzNBRmgyNWFsdGtXSVhpRHJCam0wcUtNNU1MVGRq?= =?utf-8?B?REJVeHFQUXg2YnN5dnlFYkJ0bjB2TEc3S1Q0RkZqRFE5Z0VaYmpXeUpmQTN0?= =?utf-8?B?OTVENnRGNWFQNkFCUVZoaldCeDkxYW9BZ0xQWXFlU2pmQzMzN3RONnI5RC9w?= =?utf-8?B?RjMxTXYrQjhYY280UExwSVplWDNvVDJLMGgvbjRVOFBwd2xmemN6QXpUenov?= =?utf-8?B?cG9jUjR5NnI4WG5wUFNyV3BqM1p0NUtUbmJvRGVyYmJkVWlkYlY5c3BmeHpu?= =?utf-8?B?ME1WYTBPQ1NCZHlhVGErWFBWNGt0Qm12dVNlWHZjRUVCOHJKYlNuVnF5ODdY?= =?utf-8?B?enY5TTd4L3FtUXpZdFdrdlR4VDlnSlNzQkxXY2puVGg3bjNkS1VnZ3JDTUsx?= =?utf-8?B?VFVYV2pVZ2Y1MCs0S0gxZDFIMCtMTFMyL1EwMGJWWnJ5MVM4akhVS2ZGb1FN?= =?utf-8?B?bEN2T1ZpaTV3UmthTURHZ3BJTElvWDJwQy9zajV3MWVZdHlqQkVrUlB0UDRm?= =?utf-8?B?eFQ0VWw4YW9sMG9Lc3E2U0lDaVhnbFlPS09jZnJ2YzZyZXVvMnlFdUUydStG?= =?utf-8?B?Q3NwZnJYQnJLcTA1ZERWSFgwR2RFdHpwemhiakFiL3hkMHdsajFPTWxHaVRG?= =?utf-8?B?WlJkVlFnbG1URjRZd2ZYV1lLMnBVQ05lZXBNQ0NhbmRJbEozc0wwT1o5MnMz?= =?utf-8?B?cG5IMUhhVDNCaGFjY2pOLzY1eXNNYnZ0NExWYjFtZWJkLzFrcExOTjhHQXN1?= =?utf-8?B?R0t2aDBIaVRnTVNqZm9zSkpJT041S2ZJQTZuZFZZaDVTSmpNKzBJaVhIOGRF?= =?utf-8?B?di9pQ0Rrb2o2Q1FjVkZXaHdKNWQwYit0WUpEcFdISFdWdElTQjZwS3BRUGcr?= =?utf-8?B?MUViRkxZNVRCYkFOVllrbHFOdUZydGNDQmgyNkZmTkN4NUNJMzFuMlVKaTMx?= =?utf-8?B?bU5nQ0VvSUtKaFhJTUMvdXo5c0lMaW9EbmEvODJOVGt6ZGhteDdxcmwzY25a?= =?utf-8?B?MFdFYmVNMWdCeitTc0dZeWpBSkdZVTViSDZKZHlhb2FsUlpmRjJCaDhzaWty?= =?utf-8?B?NUdLOW5yRnkveXNwWDF4UnltVzNZZ3NXOHM3alg1R1psbE5JV1FLSmFQY3hu?= =?utf-8?B?WWxFQ3FCejMzQngrN1hnR2hES0owZVVtZU54WXdlN0pWV2ZNMDV1MDhja2RL?= =?utf-8?B?MjN4S2VPU1QxUGJzWHNQS2pHenZaaE9lNVJqaGlqM3lJaVFwY0dtMmk5V2V0?= =?utf-8?B?ZE44YTJ6UzEvNWxGbkFHRkZEL2hZSWVQOHY4RVlaNzQ1T3MrcnRTS1VtUVQy?= =?utf-8?B?aFI5MDhnSmQ1VHArNXpyUnB5Wi9XTS9Xa1lxTXY0ZEFQNXJzU3UwSWQ0clU0?= =?utf-8?Q?EIUcgGmxeL92A?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_AM8P190MB0979675CE008E7E97DFCFADEFDFC9AM8P190MB0979EURP_" MIME-Version: 1.0 X-OriginatorOrg: iotconsultancy.nl X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM8P190MB0979.EURP190.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: afe9da02-e43c-4a78-f041-08d9602c7959 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Aug 2021 20:37:17.9196 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 58bbf628-15d2-46bc-820b-863b6774d44b X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: +MU3XBUK3GMOLe7wII1s8n1LXPwjLJDCPq7G3lsw/IIoHB1MbufnquWpGODrF3Ba2cbkeNyuaPM219ctkcno0F3Pc7s1HmHlA3qCWwUWYb0= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9P190MB1251 Archived-At: Subject: Re: [dnssd] WGLC for draft-ietf-dnssd-srp X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Aug 2021 20:37:28 -0000 --_000_AM8P190MB0979675CE008E7E97DFCFADEFDFC9AM8P190MB0979EURP_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gRGF2aWQsDQoNCkR1ZSB0byBob2xpZGF5IEkgbWlzc2VkIHRoaXMgbGFzdCBjYWxsLiBI YXZpbmcgcmV2aWV3ZWQgYW4gZWFybGllciB2ZXJzaW9uIEkgd291bGQgbGlrZSB0byBjaGVjayBp ZiB0aGUgaXNzdWVzIGFyZSBzb2x2ZWQgbm93OyBhbmQgY2FuIGFuc3dlciB0aGUgcXVlc3Rpb24g YnkgVHVlc2RheSBvciBXZWRuZXNkYXkgaWYgdGhhdOKAmXMgb2suIChJbnN0ZWFkIG9mIHRvZGF5 KQ0KDQpCZXN0IHJlZ2FyZHMNCkVza28NCg0KRnJvbTogZG5zc2QgPGRuc3NkLWJvdW5jZXNAaWV0 Zi5vcmc+IE9uIEJlaGFsZiBPZiBEYXZpZCBTY2hpbmF6aQ0KU2VudDogV2VkbmVzZGF5LCBKdWx5 IDI4LCAyMDIxIDIzOjU3DQpUbzogRE5TU0QgPGRuc3NkQGlldGYub3JnPg0KU3ViamVjdDogW2Ru c3NkXSBXR0xDIGZvciBkcmFmdC1pZXRmLWRuc3NkLXNycA0KDQpIaSBETlNTRCBlbnRodXNpYXN0 cywNCg0KVGhpcyBlbWFpbCBzdGFydHMgYW4gb2ZmaWNpYWwgV29ya2luZyBHcm91cCBMYXN0IENh bGwgZm9yIGRyYWZ0LWlldGYtZG5zc2Qtc3JwLiBUaGlzIGNhbGwgYXNrcyB3aGV0aGVyIHdlIGJl bGlldmUgdGhlIGRvY3VtZW50IGlzIHJlYWR5IGZvciBwdWJsaWNhdGlvbi4gQXMgc3VjaCB3ZSBh cmUgYXNraW5nIHR3byBxdWVzdGlvbnM6DQoNCjEpIGlmIHlvdSBiZWxpZXZlIHRoaXMgZG9jdW1l bnQgaXMgbm90IHJlYWR5IHRvIHB1Ymxpc2gsIHBsZWFzZSBzcGVhayB1cCBub3cNCg0KMikgaWYg eW91IGhhdmUgcmVhZCB0aGUgZG9jdW1lbnQgYW5kIHRoaW5rIGl0IGlzIHJlYWR5LCBwbGVhc2Ug c2F5IHNvIGFzIHdlbGwNCg0KRm9yIHRoaXMgY2FsbCB0byBzdWNjZWVkLCB3ZSdsbCBuZWVkIHN0 YXRlbWVudHMgb2YgZXhwbGljaXQgc3VwcG9ydCBmcm9tIHBlb3BsZSB3aG8gaGF2ZSByZWFkIHRo ZSBkcmFmdC4gUGxlYXNlIHNlbmQgc3RhdGVtZW50cyBpbiBlaXRoZXIgZGlyZWN0aW9uIGFzIHJl c3BvbnNlcyB0byB0aGlzIGVtYWlsLiBUaGlzIGNhbGwgd2lsbCBiZSBvcGVuIHVudGlsIDIwMjEt MDgtMTUgMjM6NTkgVVRDLg0KDQpUaGFua3MsDQpEYXZpZA0K --_000_AM8P190MB0979675CE008E7E97DFCFADEFDFC9AM8P190MB0979EURP_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1z dHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5 cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBh Z2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBp biAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30N Ci0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6 ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2 OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0t LT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1 NEY3MiIgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3JkIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IZWxsbyBEYXZpZCw8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+RHVlIHRvIGhvbGlkYXkgSSBtaXNzZWQgdGhpcyBsYXN0IGNhbGwuIEhhdmluZyBy ZXZpZXdlZCBhbiBlYXJsaWVyIHZlcnNpb24gSSB3b3VsZCBsaWtlIHRvIGNoZWNrIGlmIHRoZSBp c3N1ZXMgYXJlIHNvbHZlZCBub3c7IGFuZCBjYW4gYW5zd2VyIHRoZSBxdWVzdGlvbiBieSBUdWVz ZGF5IG9yIFdlZG5lc2RheSBpZiB0aGF04oCZcyBvay4gKEluc3RlYWQgb2YgdG9kYXkpPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkJlc3QgcmVnYXJkczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+RXNrbzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNv bGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gZG5zc2QgJmx0O2Ruc3NkLWJvdW5jZXNAaWV0Zi5vcmcm Z3Q7IDxiPk9uIEJlaGFsZiBPZiA8L2I+DQpEYXZpZCBTY2hpbmF6aTxicj4NCjxiPlNlbnQ6PC9i PiBXZWRuZXNkYXksIEp1bHkgMjgsIDIwMjEgMjM6NTc8YnI+DQo8Yj5Ubzo8L2I+IEROU1NEICZs dDtkbnNzZEBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW2Ruc3NkXSBXR0xDIGZv ciBkcmFmdC1pZXRmLWRuc3NkLXNycDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+SGkgRE5TU0QgZW50aHVzaWFzdHMsPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgZW1haWwgc3RhcnRzIGFuIG9mZmlj aWFsIFdvcmtpbmcgR3JvdXAgTGFzdCBDYWxsIGZvciZuYnNwO2RyYWZ0LWlldGYtZG5zc2Qtc3Jw LiBUaGlzIGNhbGwgYXNrcyB3aGV0aGVyIHdlIGJlbGlldmUgdGhlIGRvY3VtZW50IGlzIHJlYWR5 IGZvciBwdWJsaWNhdGlvbi4gQXMgc3VjaCB3ZSBhcmUgYXNraW5nIHR3byBxdWVzdGlvbnM6PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjEpIGlm IHlvdSBiZWxpZXZlIHRoaXMgZG9jdW1lbnQgaXMgbm90IHJlYWR5IHRvIHB1Ymxpc2gsIHBsZWFz ZSBzcGVhayB1cCBub3c8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+MikgaWYgeW91IGhhdmUgcmVhZCB0aGUgZG9jdW1lbnQgYW5kIHRoaW5rIGl0 IGlzIHJlYWR5LCBwbGVhc2Ugc2F5IHNvIGFzIHdlbGw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Rm9yIHRoaXMgY2FsbCB0byBzdWNjZWVkLCB3 ZSdsbCBuZWVkIHN0YXRlbWVudHMgb2YgZXhwbGljaXQgc3VwcG9ydCBmcm9tIHBlb3BsZSB3aG8g aGF2ZSByZWFkIHRoZSBkcmFmdC4gUGxlYXNlIHNlbmQgc3RhdGVtZW50cyBpbiBlaXRoZXIgZGly ZWN0aW9uIGFzIHJlc3BvbnNlcyB0byB0aGlzIGVtYWlsLiBUaGlzIGNhbGwgd2lsbCBiZSBvcGVu IHVudGlsIDIwMjEtMDgtMTUgMjM6NTkgVVRDLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3MsPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5EYXZpZDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_AM8P190MB0979675CE008E7E97DFCFADEFDFC9AM8P190MB0979EURP_-- From nobody Mon Aug 16 00:41:03 2021 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ED123A07BB for ; Mon, 16 Aug 2021 00:40:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.098 X-Spam-Level: X-Spam-Status: No, score=-18.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.499, 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, 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 8J7gwmTn1PSz for ; Mon, 16 Aug 2021 00:40:50 -0700 (PDT) Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (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 A4AB63A077E for ; Mon, 16 Aug 2021 00:40:50 -0700 (PDT) Received: by mail-lf1-x130.google.com with SMTP id i28so5870575lfl.2 for ; Mon, 16 Aug 2021 00:40:50 -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:content-transfer-encoding; bh=C/XPVtqGfq1kt4Hu5WFSp5ObcJteYWsrtbB2VIxxiso=; b=f2xt1+b1evT94NMHAIOYW3LJQ1ELu8a7+yOPSUpFIQAqzTVkp8z75+Wh/F+P7A5d0D Yxbcy4Uj9fEDVeGKRGRt/JGY63ufl94hnmuM8JBb+fyrrzx+SHmp40dG04lJhZyZLJFS xQ9HDBlxwGha/dXxQHdXPM2d12j3zV2dsRHzPzr6OAAi+SyIHX3ar9QWq+d0X2w31N5e 7BeXMnrkyKRYWUXh0+4uxlsjZXzKlEj9Eun12lFPbUsF24+OPffedCMO7dYdVqqHmmrp HmvkcUeMGlAZVmJ5O/y75XMAkiyunp92Mx+XEpGT9oNZZcDLc2eUnMtwUE7z7EWRst+V yZYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=C/XPVtqGfq1kt4Hu5WFSp5ObcJteYWsrtbB2VIxxiso=; b=HId/KUzmZLH8puWrTGbSHd1YMAge2C8VpS0JqGRyae1UAWQyjs7QqygHnbJjL76A9d POPL1BZzfJHI8DZx2Qj7fCXdQCKonxMCSt7OmYlpfl+vG455yixWwo17Mm5/sFECyhzs vUvef3FdLj62fmfgouVNBJfv+5CxOPIAGaTTXxDr5qGXvZMCCnqiJ0PbSc1woh8LfLGP sJ7PIEWO9a2keCAuraS2wG0thms6sqBdnPWq2b/vjtQ5qPu6xcFvl9NK9rBEIZCtkNC6 e5fCnSu/7n4ORR57AKZMBbNVU82jaJU4mxv8UUnWhOsYF/GSJYKdPYfKeXdblKAkdopT jTjg== X-Gm-Message-State: AOAM531r3gg4Wmn4GXEBkKrc4vzowjDRmwFYVdwhGaORAGymqCl68tcS 7M8+1N0t4ILXiOjMoBadDDvJLMshUj1Gs/YFFwp25A== X-Google-Smtp-Source: ABdhPJxfNACuuxH6OitZhOHO1l2Ei7FvRnZ1AbXswQx/yrCBIlcRetBA8Qwi14Payoir+PT3m3PwcB1r8Eija6VaeQE= X-Received: by 2002:a05:6512:2625:: with SMTP id bt37mr1462789lfb.255.1629099643382; Mon, 16 Aug 2021 00:40:43 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Simon Lin Date: Mon, 16 Aug 2021 15:40:32 +0800 Message-ID: To: Ted Lemon Cc: Jonathan Hui , dnssd@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [dnssd] Adoption call for draft-sctl-advertising-proxy X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2021 07:40:59 -0000 > On the other hand we see conflicts all the time with SRP because of the t= wo-SRP-server mDNS conflict detection algorithm, so it's pretty clear that = SRP + mDNS conflict detection is a recipe for creating conflicts. Could you explain why there are so many conflicts because of two-SRP-server mDNS conflict detection algorithm? Are the SRP servers using SRP Anycast TLV or Unicast TLV? I would expect name conflicts to happen more often if SRP servers are using Anycast TLVs because a SRP client can change SRP server for each registration or renewing. When SRP servers are using Unicast TLV, a SRP client should stick to the same SRP server for registration and renewing, even after the SRP client is rebooted. A SRP client may change SRP server when there are multiple request failures, but I would expect it to be less often. So, I would not expect many name conflicts for SRP servers using Unicast TL= Vs. On Sat, Aug 14, 2021 at 6:40 AM Ted Lemon wrote: > > > On August 13, 2021 at 6:24:51 PM, Jonathan Hui (jonhui@google.com) wrote: >> >> Another thing to be aware of is that because of the way mDNS works, if y= ou are using mDNS for discovery, a name conflict when names aren't being de= fended will sit around in the cache for a few minutes. If names are defende= d, this doesn't happen; one alternative is to just defend names and count o= n SRP to deal with conflicts, but the downside of this is that now there is= a delay before the new information appears. >> >> This delay could potentially be minimized by retrying to register as soo= n as the SRP replication update has been acknowledged by all SRP replicatio= n peers=E2=80=94right now my code (when name defense is enabled) just waits= two minutes before re-attempting, which is a lot longer than should be nec= essary. > > Sounds like a good idea to explore. My initial concern is that waiting fo= r positive confirmation from all peers can lead to other failure modes resu= lting from poor implementation or connectivity. At the same time, those sam= e assumptions are what would lead us back to needing other mitigations. > > The problem with anything that's ad-hoc and not integrated into the infra= structure is that there's no model that guarantees success. It's always goi= ng to be best effort. The goal has to be to make "best" as good as possible= , but have a backup strategy for when it's not quite good enough. > > > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd From nobody Mon Aug 16 08:17:46 2021 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AD113A08CE for ; Mon, 16 Aug 2021 08:17:35 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=fugue-com.20150623.gappssmtp.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 CzMcrIhw7cI5 for ; Mon, 16 Aug 2021 08:17:29 -0700 (PDT) Received: from mail-oi1-x22e.google.com (mail-oi1-x22e.google.com [IPv6:2607:f8b0:4864:20::22e]) (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 218FA3A096F for ; Mon, 16 Aug 2021 08:17:23 -0700 (PDT) Received: by mail-oi1-x22e.google.com with SMTP id t35so27148920oiw.9 for ; Mon, 16 Aug 2021 08:17:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=yLXXIUEn9WwryHOnOKAUsvDsou7Bo5VABjtomhboc6I=; b=GIDCKiUud8ijC15Nm7tkPVM3suFPFJo/tTqWq15dEVQs3y35mjNALzoVHDQhDYMGat E/8TgngYo8lLvzhDU/KB+IqPenpf3t/MdzTw4mjnNtCOAUeOqP7cMhDqhUELXybGNi1j +/aGcA4r+OqhkA8s8Qbru9x7tQyOHnesqnoSUsKCemjOWQRALd7gJ+KhaKpuLBlP+uOK cqoWILKBOAseSu6K5vjKhLm1t/sxoy71ICHlS7mP01Idamu5OHMkxyi4xVJFjfu03XM6 MNkvPNKlbhPko/Sx0HZGlr40uNmzfdstCOMcF9LNn8V+d+UF3h2e1J7l5MZLK9594sTf JH5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=yLXXIUEn9WwryHOnOKAUsvDsou7Bo5VABjtomhboc6I=; b=Rudz8peadhPkMX+VUKZKU4ihzaMyxwOclXqE3yAshCe2LoljsVqW8+ApMyCMsxN1ds UcuX40Lp/NFV/DTypZTqz9cpKiQekdv493iwOZEgTvpqUSHYCfG4pcx/jSzKANC6+PSC 5QEwW/DlrM6GLXaT0vT7CbMSJ8n9HGqZRGAUSFhpGFFmkYE4dpneu580ZY9hbjDgMz6z R/sJcYgl4ru9iEKeNw/82BBnHfjY9OPzBb1NxRkKXl/85AJHJ8NLAl3hlnaTb8kNhO2x wb0S0mlC3V9e/cJidD1JDGpZbUCNCixRSlD8Qtv2/636Q8PfENQng6pYTLOy0r9BbhSP IzWQ== X-Gm-Message-State: AOAM532vqMuNg1c+dEE1HJ65Kpe8l6glhyJw5KuxZWJ2fZfJgxR4CRC3 tAJV/ily3VXKamahxJ+C6o0P90pATPmwnZd1hBAMuQ== X-Google-Smtp-Source: ABdhPJxHi1r4Zv3CTRCdFbbU8iA6W/8Jlj6eQ9XRBku8RuKIbQdTguMtwGE5WcLOlfrmapbe+YWz9KzuvPNXZuHJrKw= X-Received: by 2002:aca:2b05:: with SMTP id i5mr12149119oik.55.1629127041018; Mon, 16 Aug 2021 08:17:21 -0700 (PDT) Received: from 115155811104 named unknown by gmailapi.google.com with HTTPREST; Mon, 16 Aug 2021 08:17:20 -0700 From: mellon@fugue.com In-Reply-To: References: MIME-Version: 1.0 Date: Mon, 16 Aug 2021 08:17:20 -0700 Message-ID: To: Simon Lin Cc: Jonathan Hui , dnssd@ietf.org Content-Type: multipart/alternative; boundary="00000000000092ff0e05c9aeb2e3" Archived-At: Subject: Re: [dnssd] Adoption call for draft-sctl-advertising-proxy X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2021 15:17:44 -0000 --00000000000092ff0e05c9aeb2e3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable It generally only happens when the thread omr prefix changes. So in production network it should be rare. But the thread network can fluctuate a bit on startup as the mesh settles, and this can result in changes to the omr prefix. So although this shouldn=E2=80=99t happen much, the time when i= s is most likely is right after a power outage or right when the devices are first installed. --=20 mellon@fugue.com On August 16, 2021 at 03:40:32, Simon Lin (simonlin@google.com) wrote: > On the other hand we see conflicts all the time with SRP because of the > two-SRP-server mDNS conflict detection algorithm, so it's pretty clear th= at > SRP + mDNS conflict detection is a recipe for creating conflicts. > > > Could you explain why there are so many conflicts because of > two-SRP-server mDNS conflict detection algorithm? > > Are the SRP servers using SRP Anycast TLV or Unicast TLV? > > I would expect name conflicts to happen more often if SRP servers are > using Anycast TLVs because a SRP client can change SRP server for each > registration or renewing. > > When SRP servers are using Unicast TLV, a SRP client should stick to > the same SRP server for registration and renewing, even after the SRP > client is rebooted. > A SRP client may change SRP server when there are multiple request > failures, but I would expect it to be less often. > So, I would not expect many name conflicts for SRP servers using Unicast > TLVs. > > On Sat, Aug 14, 2021 at 6:40 AM Ted Lemon wrote: > > > > On August 13, 2021 at 6:24:51 PM, Jonathan Hui (jonhui@google.com) wrote: > > > Another thing to be aware of is that because of the way mDNS works, if yo= u > are using mDNS for discovery, a name conflict when names aren't being > defended will sit around in the cache for a few minutes. If names are > defended, this doesn't happen; one alternative is to just defend names an= d > count on SRP to deal with conflicts, but the downside of this is that now > there is a delay before the new information appears. > > This delay could potentially be minimized by retrying to register as soon > as the SRP replication update has been acknowledged by all SRP replicatio= n > peers=E2=80=94right now my code (when name defense is enabled) just waits= two > minutes before re-attempting, which is a lot longer than should be > necessary. > > > Sounds like a good idea to explore. My initial concern is that waiting fo= r > positive confirmation from all peers can lead to other failure modes > resulting from poor implementation or connectivity. At the same time, tho= se > same assumptions are what would lead us back to needing other mitigations= . > > The problem with anything that's ad-hoc and not integrated into the > infrastructure is that there's no model that guarantees success. It's > always going to be best effort. The goal has to be to make "best" as good > as possible, but have a backup strategy for when it's not quite good > enough. > > > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd > > --00000000000092ff0e05c9aeb2e3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable It generally only happens when the thread omr pref= ix changes. So in production network it should be rare. But the thread netw= ork can fluctuate a bit on startup as the mesh settles, and this can result= in changes to the omr prefix. So although this shouldn=E2=80=99t happen mu= ch, the time when is is most likely is right after a power outage or right = when the devices are first installed.=C2=A0

On August 16, 2021 at 03:40:32, Simon Lin (simonlin@google.com) wrote:

On t= he other hand we see conflicts all the time with SRP because of the two-SRP= -server mDNS conflict detection algorithm, so it's pretty clear that SR= P + mDNS conflict detection is a recipe for creating conflicts.

Could you explain why there are so many conflicts because of
two-SRP-server mDNS conflict detection algorithm?

Are the SRP servers using SRP Anycast TLV or Unicast TLV?

I would expect name conflicts to happen more often if SRP servers are
using Anycast TLVs because a SRP client can change SRP server for each
registration or renewing.

When SRP servers are using Unicast TLV, a SRP client should stick to
the same SRP server for registration and renewing, even after the SRP
client is rebooted.
A SRP client may change SRP server when there are multiple request
failures, but I would expect it to be less often.
So, I would not expect many name conflicts for SRP servers using Unicas= t TLVs.

On Sat, Aug 14, 2021 at 6:40 AM Ted Lemon <mellon@fugue.com> wrote:


On August 13, 2021 at 6:24:51 PM, Jonathan Hui (jonhui@google.com) wrote:

Another thing to be aware of is that because of the way mDNS works, if = you are using mDNS for discovery, a name conflict when names aren't bei= ng defended will sit around in the cache for a few minutes. If names are de= fended, this doesn't happen; one alternative is to just defend names an= d count on SRP to deal with conflicts, but the downside of this is that now= there is a delay before the new information appears.

This delay could potentially be minimized by retrying to register as so= on as the SRP replication update has been acknowledged by all SRP replicati= on peers=E2=80=94right now my code (when name defense is enabled) just wait= s two minutes before re-attempting, which is a lot longer than should be ne= cessary.

Sounds like a good idea to explore. My initial concern is that waiting = for positive confirmation from all peers can lead to other failure modes re= sulting from poor implementation or connectivity. At the same time, those s= ame assumptions are what would lead us back to needing other mitigations.

The problem with anything that's ad-hoc and not integrated into the= infrastructure is that there's no model that guarantees success. It= 9;s always going to be best effort. The goal has to be to make "best&q= uot; as good as possible, but have a backup strategy for when it's not = quite good enough.


_______________________________________________
dnssd mailing list
dnssd@ietf.org
https://www.iet= f.org/mailman/listinfo/dnssd
--00000000000092ff0e05c9aeb2e3-- From nobody Mon Aug 16 10:31:49 2021 Return-Path: X-Original-To: dnssd@ietf.org Delivered-To: dnssd@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BF51A3A143B; Mon, 16 Aug 2021 10:31:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: chris.box.ietf@gmail.com, dnssd-chairs@ietf.org, dnssd@ietf.org, evyncke@cisco.com X-Test-IDTracker: no X-IETF-IDTracker: 7.36.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <162913510366.7431.3945544190956452209@ietfa.amsl.com> Date: Mon, 16 Aug 2021 10:31:43 -0700 Archived-At: Subject: [dnssd] dnssd - New Meeting Session Request for IETF 112 X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2021 17:31:44 -0000 A new meeting session request has just been submitted by Chris Box, a Chair of the dnssd working group. --------------------------------------------------------- Working Group Name: Extensions for Scalable DNS Service Discovery Area Name: Internet Area Session Requester: Chris Box Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 60 Conflicts to Avoid: People who must be present: Ted Lemon Eric Vyncke Stuart Cheshire Barbara Stark David Schinazi Chris Box Resources Requested: Special Requests: --------------------------------------------------------- From nobody Mon Aug 16 11:06:59 2021 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC0CC3A0AC4 for ; Mon, 16 Aug 2021 11:06:47 -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 9YmWcnyXoFQL for ; Mon, 16 Aug 2021 11:06:45 -0700 (PDT) Received: from mail-pj1-x1030.google.com (mail-pj1-x1030.google.com [IPv6:2607:f8b0:4864:20::1030]) (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 818453A0ACD for ; Mon, 16 Aug 2021 11:06:45 -0700 (PDT) Received: by mail-pj1-x1030.google.com with SMTP id j1so27830610pjv.3 for ; Mon, 16 Aug 2021 11:06:45 -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=H9U/cSyYlxzmOVolbsu5tswBdkfbC2aXfzd6HPDXJZI=; b=fS17VA11UlMPhBGIdUo9GCnKxRAkhfn+ZDivURxrqT8Wn+1dT4WVF2gJJhW00erNs4 eXYgAEU2UxMu3GJt0CU853eFULDZw21WyLckVPeMFU1Xus0jxN1WVMoCQaKL7uDxReEk xsU3tgZ3IMNPMitYaSotTaPk+qUDjYAG01w+J9Wb8xYh4tRrspLd3kwhm5xtGOZTX7Zo XbpFU0wahe8qigXoAhlSFoG3Ra2nhGdl8gEdk58k0wUhLxxMVW2SdJWI7tZr9gk90nqN X7kVDT5StTfmZRJd4FyiPehQhIRcg6Qof+1AecJTw1HLoDpvsOc2qL/WSXyo67Qocr48 AmQg== 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=H9U/cSyYlxzmOVolbsu5tswBdkfbC2aXfzd6HPDXJZI=; b=DYqhf3fWyJ65klmIFOrEgE/ul721uk0vqpD8D8gWyVRSOIlkNcmZseOkYNtQ0xf24w lOuTk8XXuqBcVjVP8D2TEzJxqJMbMsazXjHWHnzVaJaDipIEgNXLWAeMANxUTc6/8mBD ST2f9bBh/1kLWwzmQ5qurHMfG7BBklhkHn2johkH5emAKisB7P3E2Zv5bUDyjXt8hgXo rsgPVgowEWiOHnbKKdRsE/ZFabpipiYOIyn5OKv18PBbtCiPYPkJdK42HHhDtdeZDkGN GLznv9CGnbFPdLRaZyzp8R+y8XeGgu4Ln7GVoUQfKGUEYVqn2ECleG+RfgR/8+AnL3Tz u18w== X-Gm-Message-State: AOAM533qIwNY7/jJM/Sct/5/IdPox5zy+VD8dWAGmbU//a6/C85vDl0r +0AQlSyn9EVV5WNBnQOgxpYqOylLndOaZnsh/sSuBBc79DM= X-Google-Smtp-Source: ABdhPJwUEV9VUsFUxgbetKLRi7xtGhZGDwH15nZZPxeLJ9G9vwtM1qAQkWby6c1D6CIrx8ajTvxh9GUHK2AzE0dwzBA= X-Received: by 2002:a65:41c6:: with SMTP id b6mr88222pgq.206.1629137203377; Mon, 16 Aug 2021 11:06:43 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: David Schinazi Date: Mon, 16 Aug 2021 11:06:30 -0700 Message-ID: To: DNSSD Content-Type: multipart/alternative; boundary="0000000000004c376905c9b110fb" Archived-At: Subject: Re: [dnssd] Adoption call for draft-sctl-advertising-proxy X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2021 18:06:59 -0000 --0000000000004c376905c9b110fb Content-Type: text/plain; charset="UTF-8" Hi everyone, During this adoption call, the chairs received statements of support from 9 people, and no objections. We therefore declare this adoption call a success. The chairs want to thank everyone who responded, in particular the newest members of DNSSD! On procedural note since this wasn't necessarily clear based on everyone's responses: this was a call for adoption, not publication. This means that the document is now an official working group document, but we will determine whether it's ready for publication at a later date. Folks have raised some interesting questions on the list, so let's keep discussing! Ted & Stuart, please upload a draft-ietf-advertising-proxy-00 with the same contents as draft-sctl-advertising-proxy-02. We also encourage you to move the document to GitHub to simplify tracking discussions. Thanks, David On Wed, Jul 28, 2021 at 3:02 PM David Schinazi wrote: > Hi DNSSD enthusiasts, > > This email starts an official adoption call > for draft-sctl-advertising-proxy by the DNSSD working group. This call asks > whether we think that this document is a good starting point for working > group discussion. That means that it is still possible to adopt a document > with issues if we believe we'll be able to solve those issues together as a > working group. As such we are asking two questions: > > 1) if you believe that this document is not something the working > group should be working on, please speak up now > > 2) if you have read the document and would like to discuss it further > inside the DNSSD working group, please say so as well > > For this call to succeed, we'll need statements of explicit support from > people who have read the draft. Please send statements in either direction > as responses to this email. This call will be open until 2021-08-15 23:59 > UTC. > > Thanks, > David > --0000000000004c376905c9b110fb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi everyone,

During this adoption c= all, the chairs received statements
of support from 9 people,=C2= =A0and no objections. We therefore
declare this adoption call a s= uccess. The chairs want to
thank everyone who responded, in parti= cular the newest
members of DNSSD! On procedural note since this = wasn't
necessarily clear based on everyone's responses: t= his was
a call for adoption, not publication. This means that the=
document is now an official working group document, but we
=
will determine whether it's ready for publication at a later date.=
Folks have raised some interesting questions on the list, so
let's keep discussing!

Ted & Stuart= , please upload a=C2=A0draft-ietf-advertising-proxy-00
with the s= ame contents=C2=A0as=C2=A0draft-sctl-advertising-proxy-02. We
als= o encourage you to move the document to GitHub to simplify
tracki= ng discussions.

Thanks,
David
=

On Wed, Jul 28, 2021 at 3:02 PM David Schinazi <dschinazi.ietf@gmail.com> wrote:
Hi D= NSSD enthusiasts,

This email starts an official adop= tion call for=C2=A0draft-sctl-advertising-proxy by the DNSSD working group.= This call asks whether we think that this document is a good starting poin= t for working group discussion. That means that it is still possible to ado= pt a document with issues if we believe we'll be able to solve those is= sues together as a working group. As such we are asking two questions:

1) if you believe=C2=A0that this document is not somet= hing the working group=C2=A0should be working on, please speak up now
=

2) if you have read the document and would like to disc= uss it=C2=A0further inside the DNSSD working group, please say so as well

For this call to succeed, we'll need state= ments of explicit support from people who have read the draft. Please send = statements in either direction as responses to this email. This call will b= e open until 2021-08-15 23:59 UTC.

Thanks,
David
--0000000000004c376905c9b110fb-- From nobody Mon Aug 16 11:09:37 2021 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77E1E3A0BB3 for ; Mon, 16 Aug 2021 11:09:36 -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 JJApv1o5EZYz for ; Mon, 16 Aug 2021 11:09:30 -0700 (PDT) Received: from mail-pj1-x1036.google.com (mail-pj1-x1036.google.com [IPv6:2607:f8b0:4864:20::1036]) (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 BA4D13A0BA9 for ; Mon, 16 Aug 2021 11:09:30 -0700 (PDT) Received: by mail-pj1-x1036.google.com with SMTP id u13-20020a17090abb0db0290177e1d9b3f7so42062pjr.1 for ; Mon, 16 Aug 2021 11:09:30 -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=66sa3B14YTZhGNtS+HTYfU28dB3miMPe4aT0Im2i6QY=; b=KBJG9noa8Ed7mewqvusqiMK9L7z84/gVdGa+FH4wAze9Eog/lTHYYqJP/XU0qzJGi7 YnMAaI7LHSs6pGhCFAWR2R6amRqWChm4xsqEpXglBGxOSSuKAnLdOi6WFaqEyrGWME/8 PWjDfnqpLv17vfnZy+xvF8N977uqVfFQgJ4rIKLVuIQkUakBosWq8rCN97MjX+Sk0Put T7tOKNdNRKQy7nY86JBD4eEgm0iZsdsBzsblGq16kHYa0NsRx9jz3B4x8JPLlXfE2zbj aGWHdLRUjIGodWBOiEBONMrMX696pg+6XgnAdolgmDeI+YTy72bDjAWRTfLL8VpWlqy+ nVew== 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=66sa3B14YTZhGNtS+HTYfU28dB3miMPe4aT0Im2i6QY=; b=oB/+OV1UA02uQfB6aIYIxt0H77IAajtGngNwgpssrKHRO3rFdDoRU2gZMynvlpHAPe tKyE7r61weKvy1L6VqSb+0cT6DTFjzrQ1k8brfIAJ6D2YLEao6oAHXun8azlYBtXha+D b3qcX7IZORWCXd5n63HVtbYXqPV4K6GAsy+nIi6oV256p3IFG2HZeCWltFjBtoFomjZV X3/33n8n28XKVSTpr/yXUYytlf7nnTbd4xyzPKMyVpiAX3XSfG3QCwWAiF+b75/ZCZH5 FMx7daJy/b/8R+EfqVmbSJnoP+JtScVNDyxTA0f9LAjiDhZ95VGu0dCnZDxJC8aBlFgC Y+dg== X-Gm-Message-State: AOAM531hH5mLvZp2TgU8dE2m3XsjCJoKYydukpHhIKo7C0mBhY5OP6l2 Mjz9+Zj84hmp069Sy67zpbTqedhCNyujx37kf27X1pIN X-Google-Smtp-Source: ABdhPJx20o+wEGPA0IjJ4MTetewwSUVfRITE4YHhDyV87DHFgQeNRyASJelPyl9ViYBColcjaFogr6e8EyEPb39UbEY= X-Received: by 2002:a17:90a:eb08:: with SMTP id j8mr412205pjz.94.1629137369356; Mon, 16 Aug 2021 11:09:29 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: David Schinazi Date: Mon, 16 Aug 2021 11:09:17 -0700 Message-ID: To: Esko Dijk Cc: DNSSD Content-Type: multipart/alternative; boundary="00000000000030e2c505c9b11a40" Archived-At: Subject: Re: [dnssd] WGLC for draft-ietf-dnssd-srp X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2021 18:09:37 -0000 --00000000000030e2c505c9b11a40 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Esko, That's reasonable, we can wait a few more days for you to review. David On Sun, Aug 15, 2021 at 1:37 PM Esko Dijk wrote: > Hello David, > > > > Due to holiday I missed this last call. Having reviewed an earlier versio= n > I would like to check if the issues are solved now; and can answer the > question by Tuesday or Wednesday if that=E2=80=99s ok. (Instead of today) > > > > Best regards > > Esko > > > > *From:* dnssd *On Behalf Of * David Schinazi > *Sent:* Wednesday, July 28, 2021 23:57 > *To:* DNSSD > *Subject:* [dnssd] WGLC for draft-ietf-dnssd-srp > > > > Hi DNSSD enthusiasts, > > > > This email starts an official Working Group Last Call > for draft-ietf-dnssd-srp. This call asks whether we believe the document = is > ready for publication. As such we are asking two questions: > > > > 1) if you believe this document is not ready to publish, please speak up > now > > > > 2) if you have read the document and think it is ready, please say so as > well > > > > For this call to succeed, we'll need statements of explicit support from > people who have read the draft. Please send statements in either directio= n > as responses to this email. This call will be open until 2021-08-15 23:59 > UTC. > > > > Thanks, > > David > --00000000000030e2c505c9b11a40 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Esko,

That's reasonable, we can = wait a few more days for you to review.

David

On Sun, Aug 15, 2021 at 1:37 PM Esko Dijk <esko.dijk@iotconsultancy.nl> wrote:

Hello David,

=C2=A0

Due to holiday I missed this last call. Having revie= wed an earlier version I would like to check if the issues are solved now; = and can answer the question by Tuesday or Wednesday if that=E2=80=99s ok. (= Instead of today)

=C2=A0

Best regards

Esko

=C2=A0

From: dnssd <dnssd-bounces@ietf.org> On Behalf = Of David Schinazi
Sent: Wednesday, July 28, 2021 23:57
To: DNSSD <dn= ssd@ietf.org>
Subject: [dnssd] WGLC for draft-ietf-dnssd-srp

=C2=A0

Hi DNSSD enthusiasts,

=C2=A0

This email starts an official Working Group Last Cal= l for=C2=A0draft-ietf-dnssd-srp. This call asks whether we believe the docu= ment is ready for publication. As such we are asking two questions:<= u>

=C2=A0

1) if you believe this document is not ready to publ= ish, please speak up now

=C2=A0

2) if you have read the document and think it is rea= dy, please say so as well

=C2=A0

For this call to succeed, we'll need statements = of explicit support from people who have read the draft. Please send statem= ents in either direction as responses to this email. This call will be open= until 2021-08-15 23:59 UTC.

=C2=A0

Thanks,

David

--00000000000030e2c505c9b11a40-- From nobody Mon Aug 16 19:11:10 2021 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 520933A10DA for ; Mon, 16 Aug 2021 19:11:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.098 X-Spam-Level: X-Spam-Status: No, score=-18.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.499, 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, 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 AUGbifop2HHg for ; Mon, 16 Aug 2021 19:11:02 -0700 (PDT) Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87FED3A10D8 for ; Mon, 16 Aug 2021 19:11:02 -0700 (PDT) Received: by mail-lf1-x131.google.com with SMTP id z2so38398438lft.1 for ; Mon, 16 Aug 2021 19:11:02 -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:content-transfer-encoding; bh=Z/h359g0FwHWNptEizUjRPcicWVk2hHdYV9PcBp/lgQ=; b=sP0pfEpno1lltV+wd8C79QdypXgtmwNNDCSEucPCk5Eum/CsFgGkqiNhPddjaJDxz5 cJhb23jBJXdbAYBJqkV/yCtH8ArNrJc+rbb4V9QU0lw/mEbRH1LTl6KlUEeQN0ILY408 alGUkNG+tnxpzJkuuZcTeGmvD+VSy9qpA6mcMAp/qru+7ypPy0vwm6d2xzvTMxrZWj9f vzkcMFA5iYukCpSPO+glcbAgSX4cOfdXLYvGb32rrddUPZVFzo4T0abiQpcHZNgu6nRD LaQPyp9igciSmIcWopfj+FosUV3C4jVFlvZaVRXcB6u9m7Rv7re8vKctdOEua00ecYkd PnaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Z/h359g0FwHWNptEizUjRPcicWVk2hHdYV9PcBp/lgQ=; b=DMRrsL5BIRmIWKDlNbr6igVdOIsTSy5hjZfe8OkK0WkZ91gw1S9y/MmkX4tA5QaSV7 cEBwYrGHr5G8NkE+Q5Nai6FcX0toFx5m+okY8Ko8S0dDYpg26L7n7TT6MI9uHdnlNlDJ Q/b1p/zkFFRt+D+Gz9wXPda7Rf0PWZgMHcJlOIeLsSbc/FQBep2yxqDRouza8RQgh3aY rNPH4oWIxISjpUVHkaMfBQLIOdvUTqETqs+C7VCODk7tlr5Xa16oQAG5grhnJV9nogEN aMR1/m91m6x7pL+WVx0vLpOEfc1ruu9Kog7EgmU/zsk1yl9mx5jBTVyEgmG1RN6LITOM uyUg== X-Gm-Message-State: AOAM530s5vk9n91IOQnPbpmDWLV+YGLS4rBUMcWWKYraXHFAZjuFCB9y Q/cfpPcw5S60rw6hBK/b5ChmEyhlRLSNW+PxQwtAqQ== X-Google-Smtp-Source: ABdhPJxHn6+u5TX587z3s6ubTIQ7ua055ewObNIouPNJKEXFS9dMzuO60cGR3FZAYO8NxHdh9ztf9+JILEsgH984BYQ= X-Received: by 2002:a05:6512:152a:: with SMTP id bq42mr609830lfb.68.1629166259251; Mon, 16 Aug 2021 19:10:59 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Simon Lin Date: Tue, 17 Aug 2021 10:10:47 +0800 Message-ID: To: mellon@fugue.com Cc: Jonathan Hui , dnssd@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [dnssd] Adoption call for draft-sctl-advertising-proxy X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2021 02:11:09 -0000 > It generally only happens when the thread omr prefix changes. So in produ= ction network it should be rare. But the thread network can fluctuate a bit= on startup as the mesh settles, and this can result in changes to > the om= r prefix. So although this shouldn=E2=80=99t happen much, the time when is = is most likely is right after a power outage or right when the devices are = first installed. Agree that OMR prefix can change for Thread devices of one partition when two partitions converge. Are you implying that the SRP server IP address in the SRP Unicast Dataset is using the OMR address of the SRP server? In such a case, an OMR prefix change would lead to SRP server IP change in Unicast Dataset, which further lead to SRP clients having to switch SRP server IP. However if the SRP servers are using ML-EIDs in Unicast Dataset, the SRP server IP won't change when partitions merge, which will lead to less SRP server switches on SRP clients. Nevertheless, if a SRP client migrates from one partition to another and each partition has a different SRP server, the SRP client will have to reregister, which will cause name conflicts (assuming no SRP replication). So, it's foreseeable that partitioning may cause many SRP name conflicts when SRP replication is not adopted. That being said, can we argue that SRP replication is less useful when TREL can significantly reduce the chance of partitioning? -- Simon Lin Simon Lin | Software Engineer, Nest Shanghai | simonlin@google.com | +86 13656630312 On Mon, Aug 16, 2021 at 11:17 PM wrote: > > It generally only happens when the thread omr prefix changes. So in produ= ction network it should be rare. But the thread network can fluctuate a bit= on startup as the mesh settles, and this can result in changes to the omr = prefix. So although this shouldn=E2=80=99t happen much, the time when is is= most likely is right after a power outage or right when the devices are fi= rst installed. > > -- > mellon@fugue.com > > On August 16, 2021 at 03:40:32, Simon Lin (simonlin@google.com) wrote: >> >> On the other hand we see conflicts all the time with SRP because of the = two-SRP-server mDNS conflict detection algorithm, so it's pretty clear that= SRP + mDNS conflict detection is a recipe for creating conflicts. >> >> >> Could you explain why there are so many conflicts because of >> two-SRP-server mDNS conflict detection algorithm? >> >> Are the SRP servers using SRP Anycast TLV or Unicast TLV? >> >> I would expect name conflicts to happen more often if SRP servers are >> using Anycast TLVs because a SRP client can change SRP server for each >> registration or renewing. >> >> When SRP servers are using Unicast TLV, a SRP client should stick to >> the same SRP server for registration and renewing, even after the SRP >> client is rebooted. >> A SRP client may change SRP server when there are multiple request >> failures, but I would expect it to be less often. >> So, I would not expect many name conflicts for SRP servers using Unicast= TLVs. >> >> On Sat, Aug 14, 2021 at 6:40 AM Ted Lemon wrote: >> >> >> >> On August 13, 2021 at 6:24:51 PM, Jonathan Hui (jonhui@google.com) wrote= : >> >> >> Another thing to be aware of is that because of the way mDNS works, if y= ou are using mDNS for discovery, a name conflict when names aren't being de= fended will sit around in the cache for a few minutes. If names are defende= d, this doesn't happen; one alternative is to just defend names and count o= n SRP to deal with conflicts, but the downside of this is that now there is= a delay before the new information appears. >> >> This delay could potentially be minimized by retrying to register as soo= n as the SRP replication update has been acknowledged by all SRP replicatio= n peers=E2=80=94right now my code (when name defense is enabled) just waits= two minutes before re-attempting, which is a lot longer than should be nec= essary. >> >> >> Sounds like a good idea to explore. My initial concern is that waiting f= or positive confirmation from all peers can lead to other failure modes res= ulting from poor implementation or connectivity. At the same time, those sa= me assumptions are what would lead us back to needing other mitigations. >> >> The problem with anything that's ad-hoc and not integrated into the infr= astructure is that there's no model that guarantees success. It's always go= ing to be best effort. The goal has to be to make "best" as good as possibl= e, but have a backup strategy for when it's not quite good enough. >> >> >> _______________________________________________ >> dnssd mailing list >> dnssd@ietf.org >> https://www.ietf.org/mailman/listinfo/dnssd From nobody Mon Aug 16 19:37:14 2021 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 135363A060A for ; Mon, 16 Aug 2021 19:37:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.098 X-Spam-Level: X-Spam-Status: No, score=-18.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.499, 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, 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 qMtCwPU5vX3w for ; Mon, 16 Aug 2021 19:37:09 -0700 (PDT) Received: from mail-oo1-xc2e.google.com (mail-oo1-xc2e.google.com [IPv6:2607:f8b0:4864:20::c2e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97CFB3A0542 for ; Mon, 16 Aug 2021 19:37:09 -0700 (PDT) Received: by mail-oo1-xc2e.google.com with SMTP id w2-20020a4a9e420000b02902859adadf0fso5526772ook.1 for ; Mon, 16 Aug 2021 19:37:09 -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=fdKodc/TolxyS4nKkGfpeKUtkc0aoCvTVf8F96uK1e4=; b=NSWZk3+cRtDYdXjsjnnXlfd4p59R0DvvFoOmn3DLklU2ZeUmlJ3Wi7psICf6pRZt1O xxvW9sxlye3+dNxe1uHE5kZb9DddQIjnnRQUzP1tjt8ubwkeCC0IVAD6gbKIgLr/XHla 3M+Roi58pffURVHF0KntnK087pY6b3BsWTnlLVijxRpKyXHepaxMyiTdiV2JIZAMq0HH 2MAnDk91FJJXk3mxSJskCI3bPQkjXd5jqqm8pEJFfoMRKv5Rb+CabJActfB03eDVILhO C00kUb0hhDzG/2Rskb4bdi3/3e14HvZOjycKutRsE9Lw6uRNVt9PAwcwhB8HW7ro5vTH /yrg== 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=fdKodc/TolxyS4nKkGfpeKUtkc0aoCvTVf8F96uK1e4=; b=ld88M62AL+3SRG33W7mxEj38j4llZJqbpsxBZarX7NskXMdgUHEdMc7cCz7etIlYzq ZiutyaGJuimqeIPFKcLsXZv0YcY9G7fxTo6OMIHseMaikUJgCrXn4sSTeGRvkXZuhAv9 U8xSawc84xH7NMM21DNds+9YM9J+kQzvLYNjO7ZCR8faW5QktMBj9H36LYnFC+hn4KHo 3y3KtTKzpEcNBg0aRYoQ4dU/5Ax/V1PvCpYoqE3xEtnFQrqT+if71IpDCV6OyilHUVYU JY8wSv/jK81g2F69w2n7xrr3qe+wBpYudKnX+a7FP6IavhpEjGK3cuzWEw6rPTfFTbPZ +8Cw== X-Gm-Message-State: AOAM532Hl5xqHYNpua66mLZuvw9fQoSRZ9Gx1KihQNvvrx17FYCXN31R Q2tAj4U5/5x15ddyT3TgmexpcqxUkMHYDxjkSw2/ng== X-Google-Smtp-Source: ABdhPJzfXQnB7o9GSnrcAR45a36CnuxC9+U0C7dwZaKi8MlZCi5o/ISbj6ndqlzV0jmac0nBegs1i1q6fM1nrGDH5/w= X-Received: by 2002:a4a:98e1:: with SMTP id b30mr946897ooj.34.1629167827529; Mon, 16 Aug 2021 19:37:07 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Jonathan Hui Date: Mon, 16 Aug 2021 19:36:56 -0700 Message-ID: To: Simon Lin Cc: mellon@fugue.com, dnssd@ietf.org Content-Type: multipart/alternative; boundary="000000000000a4367a05c9b83143" Archived-At: Subject: Re: [dnssd] Adoption call for draft-sctl-advertising-proxy X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2021 02:37:12 -0000 --000000000000a4367a05c9b83143 Content-Type: text/plain; charset="UTF-8" On Mon, Aug 16, 2021 at 7:11 PM Simon Lin wrote: > > So, it's foreseeable that partitioning may cause many SRP name > conflicts when SRP replication is not adopted. That being said, can we > argue that SRP replication is less useful when TREL can significantly > reduce the chance of partitioning? > It's not clear to me whether TREL would eliminate partitioning/merging during network formation (e.g. after a power outage). Regardless, SRP replication provides other benefits beyond avoiding name collisions when SRP clients change servers. -- Jonathan Hui --000000000000a4367a05c9b83143 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Mon, Aug 16, 2021 at 7:11 PM Simon Lin= <simonlin@google.com> wro= te:

So, it's foreseeable that partitioning may cause many SRP name
conflicts when SRP replication is not adopted. That being said, can we
argue that SRP replication is less useful when TREL can significantly
reduce the chance of partitioning?

It&#= 39;s not clear to me whether TREL would eliminate partitioning/merging duri= ng network formation (e.g. after a power outage).

= Regardless, SRP replication=C2=A0provides other benefits beyond avoiding na= me collisions=C2=A0when SRP clients change servers.

--
Jonathan Hui
=C2=A0
--000000000000a4367a05c9b83143-- From nobody Tue Aug 17 07:33:09 2021 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7393F3A17D8 for ; Tue, 17 Aug 2021 07:33:07 -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=unavailable 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 wK5xvrHMSkvy for ; Tue, 17 Aug 2021 07:33:02 -0700 (PDT) Received: from mail-qk1-x729.google.com (mail-qk1-x729.google.com [IPv6:2607:f8b0:4864:20::729]) (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 60EAA3A17DF for ; Tue, 17 Aug 2021 07:33:02 -0700 (PDT) Received: by mail-qk1-x729.google.com with SMTP id m21so5349440qkm.13 for ; Tue, 17 Aug 2021 07:33:02 -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=kdcFY4jw7Ah6GxIRd1cAUPCK49VqZuusvQT7TdlwidU=; b=q6bbcTmWhi210tPr2IwqBdtb5y74ZpMNHwvh1TZjj3ygi2IZiiIgvZZRZ4GO879QJx rM8clVf1ln0gciz6xlnPf9zqjbcu9DxmtbOKFgTeZv+vVwHg1BC/IyO0ylzwi+LYywp+ nQ8p4b8roSJZ+ym1fCspsF1jQsRZlHZd/n0vygTDBK/GjpwFSsKGeBOQfbI7T3/RGbzN 7kzat1Bhr0TPoj+xT9kgyXmeXJSedRKZUGC8ogFJN0owEak/qjBJKX+N/n3UeDEhDU8L Bnoc5ieaprVbdZTLJsRUkKeWHeLDluXBKniUzRWkOVxC4XBQsglNSoUQJFsBv3oQ7OUq dVLA== 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=kdcFY4jw7Ah6GxIRd1cAUPCK49VqZuusvQT7TdlwidU=; b=ZW8+BiETHP+fGXlk0crIMfRwx1mdxUWCGdHv9lLRr9E35NrcVhZdP8x3q60kyXLZ1V FOGYWjhtkf70/yHUnz2CkJzxRpy86JFg6UqzvqbQ1jRZi0/KbBzeFubUyQ5DqHXmtAem A7XrIhp+VbrgmnX1iUcRwb4cEtuaePSabU7Cr9n77cfQwHepCB8ARCoQmZed6zaQUzCN auG0U3USdaZR6qeKOz5YYE4o9jU806TYYDqaYRJ1Sacubjdq2LqWumLzCOYSYZaAlwnM 5GofyGFAteVBG+WB+upltuoe08CFHSc9ELE5BBEtuh947tuHuZZyPvbo55selL88/OYg E/9A== X-Gm-Message-State: AOAM532vIXo76awZmCnMOWvEs3kObXt7fE3bdJyNFrh5PLI6h7Qhg4MJ CLyrFBl8JSNVHVZVelIvkBsyS/zsKD7H+XLa4UygdhrbGKU= X-Google-Smtp-Source: ABdhPJyEKkdqZVtP0X1myQ1SvuZu3gLKu5BGqa5xTyjh/3oc9O4aWkvAwYsFxKbnmmFfY8w0VFi2LU7w3NdPL4judKU= X-Received: by 2002:a05:620a:15a5:: with SMTP id f5mr4183866qkk.80.1629210780236; Tue, 17 Aug 2021 07:33:00 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Lanlan Pan Date: Tue, 17 Aug 2021 22:32:48 +0800 Message-ID: To: Ted Lemon Cc: Simon Lin , dnssd Content-Type: multipart/alternative; boundary="000000000000d1fe5105c9c231a4" Archived-At: Subject: Re: [dnssd] Adoption call for draft-sctl-advertising-proxy X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2021 14:33:08 -0000 --000000000000d1fe5105c9c231a4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Ted Lemon =E4=BA=8E2021=E5=B9=B48=E6=9C=8813=E6=97=A5=E5= =91=A8=E4=BA=94 =E4=B8=8B=E5=8D=887:19=E5=86=99=E9=81=93=EF=BC=9A > On August 12, 2021 at 11:08:44 PM, Simon Lin ( > simonlin=3D40google.com@dmarc.ietf.org) wrote: > > > Specifically, > > imagine a dual-radio device (WiFi and Thread) which for some reason > > migrates from being an SRP client to an mDNS client or vice versa. > > Interesting=E2=80=94I'm realizing I completely misread Martin's question.= I was > assuming that this client would continue to be an SRP client, not switch > between SRP and mDNS. > > What's the solution to resolve the case where an SRP client migrates > to be an mDNS client. When the mDNS client tries to advertise its DNS > service, it will conflict with the SRP server of the original SRP > client. I don't think SRP replication can solve this problem. > > As Jonathan said, always using SRP regardless of whether the device is > connected via Thread or WiFi can solve this problem. Also maybe the > device can unregister itself from SRP when it has migrated to WiFi, > which requires the device to remember the IP address of the SRP > server, or to use draft-tljd-dnssd-zone-discover. > > I don't think dnssd-zone-discover helps with this. I think the client > needs to either unregister itself with SRP before migrating, or follow th= e > same protocol I mentioned earlier with respect to its service > advertisement: advertise without asserting uniqueness. > +1, advertise without asserting uniqueness. To join in a Thread zone, srp client should be authenticated through J-PAKE or other protocols. the srp client only its own the srp server, the srp server can only ensure the uniqueness in its zone, but not asserting the uniqueness with other zones. If srp client migrating to a mdns client, just follow the mdns conflicts policy. > > The way I'm currently proposing to address this is by requiring SRP > > replication when there is more than one SRP server, and by not renaming= , > > but rather waiting for the conflict to resolve. > > Agree that SRP replication is the most user-friendly way of addressing > this problem. > > > An additional mitigation strategy is to not actually detect conflicts. > If > > we have two conflicting registrations, and SRP replication doesn't > resolve > > them, then they just coexist until one goes away. > > Does this strategy violate mDNS protocol? Moreover, if two different > devices register their service on different SRP servers using the same > name, it's not a good idea to not resolve the conflict since the > conflict will last for a long time. > > No, it's allowed. If two devices claim the same name, we're now assuming > that this conflict will be resolved out of band rather than through mDNS > conflict detection. TBH, the only time I've ever actually seen an mDNS > conflict happen outside of deliberate testing was when a single device wa= s > connected through two interfaces to the same link and didn't know it. > > On the other hand we see conflicts all the time with SRP because of the > two-SRP-server mDNS conflict detection algorithm, so it's pretty clear th= at > SRP + mDNS conflict detection is a recipe for creating conflicts. > > > The only other alternative is to rename. I think this is too heavy of a > > solution, but I'm open to debate. > > It increases the complexity on every device that needs to browse for > mDNS services. I would prefer SRP replication to renaming. > > This is a good point=E2=80=94SRP replication also increases complexity, b= ut it > constrains it nicely to the more capable nodes on the network=E2=80=94the= ones that > are acting as ad-hoc infrastructure and not as end nodes. > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd > --000000000000d1fe5105c9c231a4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
Ted Lemon <mellon@fugue.com> =E4=BA=8E2021=E5=B9=B48=E6=9C=8813=E6= =97=A5=E5=91=A8=E4=BA=94 =E4=B8=8B=E5=8D=887:19=E5=86=99=E9=81=93=EF=BC=9A<= br>
On August 12, 2021 at 11:08:44 PM, Simon Lin (simonlin=3D40= google.com@dmarc.ietf.org) wrote:
> Specifically,=C2=A0
> imagine a dual-= radio device (WiFi and Thread) which for some reason=C2=A0
> migrates= from being an SRP client to an mDNS client or vice versa.=C2=A0

Interesting=E2=80=94I'm realizing I completely misread= Martin's question. I was assuming that this client would continue to b= e an SRP client, not switch between SRP and mDNS.

What's the solution to resolve the case where an SRP clie= nt migrates=C2=A0
to be an mDNS client. When the mDNS client tries to ad= vertise its DNS=C2=A0
service, it will conflict with the SRP server of t= he original SRP=C2=A0
client. I don't think SRP replication can solv= e this problem.=C2=A0

As Jonathan said, always using SRP regardless = of whether the device is=C2=A0
connected via Thread or WiFi can solve th= is problem. Also maybe the=C2=A0
device can unregister itself from SRP w= hen it has migrated to WiFi,=C2=A0
which requires the device to remember= the IP address of the SRP=C2=A0
server, or to use draft-tljd-dnssd-zone= -discover.=C2=A0

I don't think dnssd-zone-discover= helps with this. I think the client needs to either unregister itself with= SRP before migrating, or follow the same protocol I mentioned earlier with= respect to its service advertisement: advertise without asserting uniquene= ss.

+1,=C2=A0 advertise without asse= rting uniqueness.
To join in a Thread zone,=C2=A0 srp client shou= ld be authenticated through J-PAKE or other protocols. the srp client only = its own the srp server, the srp server can only ensure the uniqueness in it= s zone, but not asserting the uniqueness with other zones.
If= srp client migrating to a mdns client, just follow the mdns conflicts poli= cy.
> The way I'm currently propo= sing to address this is by requiring SRP=C2=A0
> replication when the= re is more than one SRP server, and by not renaming,=C2=A0
> but rath= er waiting for the conflict to resolve.=C2=A0

Agree that SRP replica= tion is the most user-friendly way of addressing=C2=A0
this problem.=C2= =A0

> An additional mitigation strategy is to not actually detect= conflicts. If=C2=A0
> we have two conflicting registrations, and SRP= replication doesn't resolve=C2=A0
> them, then they just coexist= until one goes away.=C2=A0

Does this strategy violate mDNS protocol= ? Moreover, if two different=C2=A0
devices register their service on dif= ferent SRP servers using the same=C2=A0
name, it's not a good idea t= o not resolve the conflict since the=C2=A0
conflict will last for a long= time.=C2=A0

No, it's allowed. If two devices clai= m the same name, we're now assuming that this conflict will be resolved= out of band rather than through mDNS conflict detection. TBH, the only tim= e I've ever actually seen an mDNS conflict happen outside of deliberate= testing was when a single device was connected through two interfaces to t= he same link and didn't know it.

On the other hand we see conflic= ts all the time with SRP because of the two-SRP-server mDNS conflict detect= ion algorithm, so it's pretty clear that SRP + mDNS conflict detection = is a recipe for creating conflicts.

= > The only other alternative is to rename. I think this is too heavy of = a=C2=A0
> solution, but I'm open to debate.=C2=A0

It incre= ases the complexity on every device that needs to browse for=C2=A0
mDNS = services. I would prefer SRP replication to renaming.=C2=A0

This is a good point=E2=80=94SRP replication also increases complexit= y, but it constrains it nicely to the more capable nodes on the network=E2= =80=94the ones that are acting as ad-hoc infrastructure and not as end node= s.

_______________________________________________
dnssd mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/listinfo/dnssd
--000000000000d1fe5105c9c231a4-- From nobody Tue Aug 17 15:46:28 2021 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97C273A0DB3 for ; Tue, 17 Aug 2021 15:46:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 hWWxp6GgzwgR for ; Tue, 17 Aug 2021 15:46:24 -0700 (PDT) Received: from mail-oi1-x235.google.com (mail-oi1-x235.google.com [IPv6:2607:f8b0:4864:20::235]) (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 F3FA93A0DBA for ; Tue, 17 Aug 2021 15:46:23 -0700 (PDT) Received: by mail-oi1-x235.google.com with SMTP id u25so1585895oiv.5 for ; Tue, 17 Aug 2021 15:46:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=VoKLKmaJbGhNlegbseMm3oYNps4VUCWfbFjLG6/68a4=; b=QfxYB2BmsBs34TUdQvDJiSeCg1RxQq+UEY2GYSEOT78OSM9fA6wbiPNwmdhsVGkbfP d+KXwMFQwTHDxcPfmjSEbOBXTjtLd+e2NRwFDvSuoPd/h3qpX6DTSCPqNF/CEZQZslf6 BNrifNRAAEl9VOuTgyInW0QVWkjivMPsQw/cQJOt2XYIZ97eMnWrLvb7USdTEyouowfD K/11jDoffp1Nv4DelyLiuSeSw9VBy8j9E0/VJ4FQwoT3TOQeWIsZbINoZlmkojXsgZfM 8GUFBW5+u4lLJq2n3lKfTg8fNeyoLKY2o1FdvBDBG/g3xclEzWeVG7+UNbzpiEnJJvcI DdEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=VoKLKmaJbGhNlegbseMm3oYNps4VUCWfbFjLG6/68a4=; b=WJJKEdQYDCA9jOxdfjXQiPnSUK05xdD+hwQ6vZtGZr1VYXNH3VGwQbHsOjfiddyHIb Z1DhcE4uOvCoBwbKcDiN0tfEiYKhFxy/jT0XQjj4JPPNIkWNT1pHx1Rh342c1o7/6/vZ xxdX0o9afiR74uRL8lM82+shkA+B+zeUg8hfIghe1PR1y0em1wy0oGryc88ii73zHRzD 1IGshipN7UOVxkMdtT1Yg9bumJASKW1CXS3bgGeQUFxkzNaeGDWeuYnFOzn+zOocS1df P1fRvu0JzoJSFObmF7w51gcuSda6keh7MR6V9krkN3QIGQsFOw8xv4ZFWO9zBWbLnJrJ zGQw== X-Gm-Message-State: AOAM531178oSpxDiWVp1NX8GdyFCFq6ufF+FS7e41eymyRFEOqnKlY+h CfNzevnXEIr+3KUBpynPXvMlmB+zneo14H0bhye1NA== X-Google-Smtp-Source: ABdhPJyGRjPBKx4tucTPBirGrTFbrdb4DAhWiCKur5A4n8tH0k/xZRfljIAQI0n8RQPRcHwe8sSnxwwQMQQ2Dqqja20= X-Received: by 2002:aca:2b05:: with SMTP id i5mr4406138oik.55.1629240381002; Tue, 17 Aug 2021 15:46:21 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Tue, 17 Aug 2021 15:46:20 -0700 From: Ted Lemon In-Reply-To: References: MIME-Version: 1.0 Date: Tue, 17 Aug 2021 15:46:20 -0700 Message-ID: To: Lanlan Pan Cc: Simon Lin , dnssd Content-Type: multipart/alternative; boundary="0000000000002a084205c9c91695" Archived-At: Subject: Re: [dnssd] Adoption call for draft-sctl-advertising-proxy X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2021 22:46:27 -0000 --0000000000002a084205c9c91695 Content-Type: text/plain; charset="UTF-8" On August 17, 2021 at 10:33:00 AM, Lanlan Pan (abbypan@gmail.com) wrote: I don't think dnssd-zone-discover helps with this. I think the client needs to either unregister itself with SRP before migrating, or follow the same protocol I mentioned earlier with respect to its service advertisement: advertise without asserting uniqueness. +1, advertise without asserting uniqueness. To join in a Thread zone, srp client should be authenticated through J-PAKE or other protocols. the srp client only its own the srp server, the srp server can only ensure the uniqueness in its zone, but not asserting the uniqueness with other zones. If srp client migrating to a mdns client, just follow the mdns conflicts policy. Actually that's not really an issue we address. Yes, on a network like Thread, the commissioning process guarantees that the client has the right to connect, but it doesn't guarantee a unique hostname. Some other part of the onboarding process might do that, or might not, but SRP doesn't really pay attention to that. Rather, devices are expected to have a unique public/private key pair that's used to claim the name, and conflicts are detected by noticing that the client making a claim to a name has signed their claim with the wrong key (wrong meaning not the key that was used last time). And then that client doesn't get the name. This is FCFS naming. As long as there is a single SRP namespace, it's fine for it to span more than one network link, because the FCFS naming process ensures that there will be no duplicate names. If a device moves from Thread to WiFi, we want it to keep the same name. The problem is that mDNS currently lacks the capability to defend names using FCFS, and so when this roaming occurs, if there is an overlap between the lifetime of the SRP registration and the lifetime of the mDNS advertisement, we need a strategy for dealing with that. The strategy I'm proposing is that we allow the conflict to exist, and let the application figure out which information to use. Ultimately though we want WiFi clients to use SRP, with FCFS naming, and that solves the problem. We could do what the Discovery Proxy does and give each link its own name, but I didn't suggest going that route because I think it's confusing. Is a device with the same name in a different domain the same device that's moved to a different network, or a different device? The application still has to figure this out, so we haven't gained anything. Additionally, the app needs to do more work, because now it has to have a list of domains to query (or the API for finding names has to know to query multiple domains). Also, with that model, when a device roams to a new link, until it's discovered to have roamed, there is no name the app can use to immediately reference the device, because now the name changes from link to link. So the app has to always be doing discovery just to find the device when it roams, even if it isn't interested in other devices that have the same service type. So that's why I tend to prefer the model where we do our best to avoid conflicts, but when we have duplicate information, we allow it to coexist. The app should be able to fairly easily figure out which information to use, and the period of coexistence should be brief, so if there is a cost to disambiguating, it will be paid only infrequently. --0000000000002a084205c9c91695 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =

=
On August 17, 2021 at 10:33:00 AM, Lanlan Pan (abbypan@gmail.com) wrote:

= I don't think dnssd-zone-discover helps with this. I think the client n= eeds to either unregister itself with SRP before migrating, or follow the s= ame protocol I mentioned earlier with respect to its service advertisement:= advertise without asserting uniqueness.

=
+1,=C2=A0 a= dvertise without asserting uniqueness.
To join in a Thread zone,=C2=A0 srp client= should be authenticated through J-PAKE or other protocols. the srp client = only its own the srp server, the srp server can only ensure the uniqueness = in its zone, but not asserting the uniqueness with other zones.
If srp client= migrating to a mdns client, just follow the mdns conflicts policy.

Actually that's not really an issue we address. Yes= , on a network like Thread, the commissioning process guarantees that the c= lient has the right to connect, but it doesn't guarantee a unique hostn= ame. Some other part of the onboarding process might do that, or might not,= but SRP doesn't really pay attention to that. Rather, devices are expe= cted to have a unique public/private key pair that's used to claim the = name, and conflicts are detected by noticing that the client making a claim= to a name has signed their claim with the wrong key (wrong meaning not the= key that was used last time). And then that client doesn't get the nam= e. This is FCFS naming.

As long as there is a single SRP namespace, i= t's fine for it to span more than one network link, because the FCFS na= ming process ensures that there will be no duplicate names. If a device mov= es from Thread to WiFi, we want it to keep the same name.

The problem= is that mDNS currently lacks the capability to defend names using FCFS, an= d so when this roaming occurs, if there is an overlap between the lifetime = of the SRP registration and the lifetime of the mDNS advertisement, we need= a strategy for dealing with that.

The strategy I'm proposing is = that we allow the conflict to exist, and let the application figure out whi= ch information to use. Ultimately though we want WiFi clients to use SRP, w= ith FCFS naming, and that solves the problem.

We could do what the Di= scovery Proxy does and give each link its own name, but I didn't sugges= t going that route because I think it's confusing. Is a device with the= same name in a different domain the same device that's moved to a diff= erent network, or a different device? The application still has to figure t= his out, so we haven't gained anything. Additionally, the app needs to = do more work, because now it has to have a list of domains to query (or the= API for finding names has to know to query multiple domains).

Also, = with that model, when a device roams to a new link, until it's discover= ed to have roamed, there is no name the app can use to immediately referenc= e the device, because now the name changes from link to link. So the app ha= s to always be doing discovery just to find the device when it roams, even = if it isn't interested in other devices that have the same service type= .

So that's why I tend to prefer the model where we do our best t= o avoid conflicts, but when we have duplicate information, we allow it to c= oexist. The app should be able to fairly easily figure out which informatio= n to use, and the period of coexistence should be brief, so if there is a c= ost to disambiguating, it will be paid only infrequently.

<= /html> --0000000000002a084205c9c91695-- From nobody Wed Aug 18 06:25:17 2021 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88F893A193A for ; Wed, 18 Aug 2021 06: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, 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.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=iotconsultancy.nl 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 Mpl8oFjT4KXV for ; Wed, 18 Aug 2021 06:24:57 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40115.outbound.protection.outlook.com [40.107.4.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2092F3A1964 for ; Wed, 18 Aug 2021 06:24:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=lOZk4BBWmVd0uw/As7NJWTvDWYCOTEf1iI47dzhKWvGjg7qeV2n4Kaf4KgCdgSNoV90P7SJovWZ4ok3EiT6hxx24WHYMVettG1P+0NJwIfELP80Tuin0DCK1xset5m8kB4y18dWzFwIyB/8FrTJLVP8c60qUEm6CgaYC7yWytJHPXBFIWzHSfNvoc77xtEbrbkDQhcQNCtllBs/Z2qUW59aEcRqwhE8Blo0dVDdpnyJPnTmUmh9kU3t+OcJXKJaWW8GLwe84rAe9EvCZb7LXsOLoKj4bKy0t+7EAIlYtw/f+QJVGUd87fhkEHMyhRj7pelZ35cAqfGIeHph2O+U61Q== 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=xl3fhk2L2X9vW2P2NgesFRLk71dCAA/NDM3NpFoY1xM=; b=HxZF8FXbZIyqPMZEmE5FLPnNwrS2JBHerBlYP5BrF3G2q1tiyt+VFR6Z22RLy1ZYT+FwYv4lyVPxg4HiFKeA5dtRBNG4J6DMT+7PlSfmNGMH2CE+5HzEdSUSaWOqyYLsbrTG/xKlf7lHUFhwYHdzTeceVs07PzwUjn/Ie0Dg2/KSjikJJ3S2LhpZM5OoPZRqJQ+hSCc6EnZnrU66ov4OtiTxXLnsnIaQk34+3lGMMtUOPslGi1z4BZ0XMmOvLgNfYo7PejlWYAgVae15LEe42cxOZkXAl3OSLDuyInh3ExceL7WTZy1ZQLvjRgc7s4sqdDz01lqIyGx2X+hGvQxjig== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=iotconsultancy.nl; dmarc=pass action=none header.from=iotconsultancy.nl; dkim=pass header.d=iotconsultancy.nl; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iotconsultancy.nl; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xl3fhk2L2X9vW2P2NgesFRLk71dCAA/NDM3NpFoY1xM=; b=ohmWrgfahu8BhC4oasTLNahfRGA4uuL3zegz1kBLHtUYV4phvaaSz05wZcdURGf86eef//52lUxDBJ9kfWfWskZhboiVDB6MGnyZgQ8ZwEYIVHSc0XdzTgG1Em8xvRd2GzExdG52IPGLtQWjErfp/wTqXxEpWyF0eRcgLUS2aDU= Received: from AM8P190MB0979.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:1d3::8) by AM0P190MB0673.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:197::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4436.19; Wed, 18 Aug 2021 13:24:53 +0000 Received: from AM8P190MB0979.EURP190.PROD.OUTLOOK.COM ([fe80::44fa:5ced:a434:f7e8]) by AM8P190MB0979.EURP190.PROD.OUTLOOK.COM ([fe80::44fa:5ced:a434:f7e8%9]) with mapi id 15.20.4436.019; Wed, 18 Aug 2021 13:24:53 +0000 From: Esko Dijk To: DNSSD CC: Ted Lemon Thread-Topic: Parsing Service Discovery Instruction for SRP (2.3.1.1) Thread-Index: AdeUMwjaRIocQMs/T761taAG+UH0Ow== Date: Wed, 18 Aug 2021 13:24:53 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none; ietf.org; dmarc=none action=none header.from=iotconsultancy.nl; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: fa2e8cbe-cf69-4a79-3fca-08d9624b90ac x-ms-traffictypediagnostic: AM0P190MB0673: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Spnxr+xydEIcVNVXgF9KHM9D44RlhW3GlVebLJCMW/TFBVbpuc+JgD/b5xx0gdhBc01TFOxLdvE9wRqZZJpEVMZPoZkl7a0xFnyRgZ6Y2QXGzfI2Pvp9hid837std4gJKIx2btfJpwnoGHEiKcYaPR6kQnBi7fAjgeOBljqONF4QvjUUIhSLO/9P/C/zewGNUFR1JHxI9Noy8wlsKYL92ONMy83we3SyfgQ3Vpn+0E9R+k0/tr4ypWCsu7r9oYZ6LBrrRFohjlngxOMOfERa1AhKsM5oza8V+ViPd5AbLyYaUEp/D2RuVQhKi4DEQGKd+kPNg+cyoNpED2N9YNAny0HneT2RC6G9K5qNXToRwrFF/bxhhVlUvdaJ2FOwa6b4X7tpV4MDDBESQAKvz3cVyp8cq+TMZ1pUPrFTrl/S67n277giFgkbdQ5ZCsNTxwNfWxuOtTjqmVW4soQO7jIJZo2K/6e9fN5wUnp18XFyruCdul2H+0QkvLPjuHEwJKqRonXXADth6/EOvWNiN0vN8plJXB5+s7zaUMcc/tg8fxvZvd6XEqwitYpl67K89GLQrG+f2rWJ2ChLbyoL4ygzGt4Y7ouf2+LvqxFJEGdPaQomfHQ2J+eRnLG3zE5+KHNsFw7s1B6/uBshDyI1RkKTl5NbH36+Ffb1FuuWiHHkUlKYMWeIfo2zyEtIiyewhR5mXulyrXZz5mOMHFWdIev/6pdykN2zaT2O+SgqtBu+hYmDXwOD4seCxEabL9B3XfhEpr1Cw1gUg7f4FroqjfOVoLmRfB/pP6IQgUxwbpxLTNc= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM8P190MB0979.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(396003)(39830400003)(376002)(346002)(136003)(366004)(83380400001)(316002)(86362001)(6916009)(33656002)(38070700005)(55016002)(122000001)(9686003)(38100700002)(478600001)(71200400001)(166002)(186003)(66946007)(66556008)(66446008)(6506007)(66476007)(76116006)(52536014)(4326008)(5660300002)(44832011)(7696005)(8936002)(2906002)(8676002)(64756008); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?bk02Mkc4QUZEZW0yL0t0UXZ0RzZmQ01IRHNxZ3F1QkZwUmJUbVVIWmtFdE1B?= =?utf-8?B?eWdacDZzdCttZHhjUjBIS2JLV1AvUTJHNENjdHNzQThqS2d6YllaS2luQldr?= =?utf-8?B?WXV5dkpUWU9vL1VlY0h3RVVPOHBmbW5RRTErL2ZhdmlER1lkdlZ3VUw3bWFC?= =?utf-8?B?YmZxOFpEa1FiZnJsaGRXUUFmZVdqNVp2d21la2Mwd2k1L0I2QVIzSEZRUjRj?= =?utf-8?B?WkNHVUZNZTZLdVZia0o1TGl0alNSOG4reVNrNGxsc1hxYVNqTU1NdzhHeVRo?= =?utf-8?B?aXgyK2NzcGRjZDA3dUxqWERSRnFJZHQrblJFZEVPV1h6NitkN1NpOVhkcUZH?= =?utf-8?B?VkFJMFVyREh6dkV4RWtKdDNQakVYWklVWmlwV1ZLVHNlMThUTHlaeXVjbVZj?= =?utf-8?B?NHZTL2FMc1FWU0V3eVB2OENZWDJqVkRyYU1uUjZrTTdpMHczOCtkYzVyUXVv?= =?utf-8?B?WG54R2lLQTBDTUwxRkZ1dG43ZEMxbHJYeVg2anNMb2dCQm1xZGhoRFJFZzUy?= =?utf-8?B?dUM1dVZIV0lwdXk2aGJOVmNOckRTVWtJMXpkeGtKYjdoUStwT21FZjF4WHZK?= =?utf-8?B?R0tkdDEvd1V5ZzRYZU5CYWxPSnNVcmVFTFI3anZtd2dCYUdOeUVGNnB2cVh1?= =?utf-8?B?ek1YM2FlT3VJRUpjRkhsN3d6anNCL0Izd3hZUUFoSE5zdU1jQTlZZnMzc092?= =?utf-8?B?Y0RGM2prSWwwVkVhelJtbXVhSCsyMDhtZFBjYTFnN0IrMzZuTytjOGZPbWE2?= =?utf-8?B?eklDazdlekxWdUthUnM0RENZeC94V2xDMzg0YmYyMm9VTmUyS1ZldjgxUk16?= =?utf-8?B?cVB6MDJNNnZ4dlFjcDMvT2g2U2JYSWZ2Q0ZOWU56bk4xbkNPZUlyYkNOYUIz?= =?utf-8?B?MWFCcHVDeSt3TmcxYXRwQmt0YUdnMnRxek9WTVB4d1FVb01FTnNaRm12TndO?= =?utf-8?B?Smd6UjB1Z3ZFWEJNY0FxZ2g4SVMrcVZlaXRKOUp4QzlLMmFZU3BnUDVlUzVQ?= =?utf-8?B?MlluZ2lTU2RQd052MTJqZTBQSWh5SzhtWk1Za1RMR2lSNjdkY0hhUzZBR09n?= =?utf-8?B?RUt2QzNhMnplTHNYdXUvMGRNTTVseGNWUERIYVI4VGpZM0xUdGEyU1FFejRn?= =?utf-8?B?ODFMMjg5ZTVJL1ZaQm80bnpCUHpqMnlpcHVhWm5JdXRteWxZUENXczNtZXN1?= =?utf-8?B?VTFMN21Gck15UWdxZnNXNXpJN3BGZHFDWG9qZTRlTXc4YTdOang2Y0VYVTh6?= =?utf-8?B?djZBMTdvMXI2bUFJVXNZSnh5a0NGOEV4NlN3eGs3dkh0TWNla0tBZzR4ZTd4?= =?utf-8?B?U2RTN2Z0SDdKSkxEd3hkZHgycCtZL2NaR2l1L21TNXJIRlhZZ0dseGNxMXZB?= =?utf-8?B?Um1UalhkNEhtVUY4STFZZUJDQjQxb0xMb2FxbTB0ZGtmbTE3SFJHZ2tvc1lp?= =?utf-8?B?M29EK25Ga2lJeVlVRzhuMUEyQnJycUhMQklqNnZQYTREZnoxS2I5ZzVSTTdp?= =?utf-8?B?Y01IM1REanZTMC9LMU1IellIMzRHemVnTS94dm5XRHE3eUNrT0E4Y0JQc3BQ?= =?utf-8?B?T0lZNFBXTXc2TlZ4TlpKOXFkZS9mZTJTRlZISlJmQ2k0MmJjVmdYOElHdWVm?= =?utf-8?B?eUZHS1RwNy9QRDJtUldrUTVqcTNnZWFxYWhaNmNkcm4yaXB4cS9odWJhdy9x?= =?utf-8?B?bUpQK25VQlpBckhsUSs3WEhVZ3N0VnFKd0FHcStrZTVXcWVEaTFBSjBVY3Nm?= =?utf-8?B?V1JVQWg0TlB6V1ZxU1RPNUU5OVhoQnJ5REgvMEtCTm1iRENEOUpSeVdUVit0?= =?utf-8?B?cWxoUTNaa3NVTGdhTktjc3dQNEJ1dE1Vb2Q2L2N0WlkxNjhTOEJvWnhKYis3?= =?utf-8?Q?TwQD1Nx+NCX8L?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_AM8P190MB097971C9F383D3283261F47EFDFF9AM8P190MB0979EURP_" MIME-Version: 1.0 X-OriginatorOrg: iotconsultancy.nl X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM8P190MB0979.EURP190.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: fa2e8cbe-cf69-4a79-3fca-08d9624b90ac X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Aug 2021 13:24:53.7717 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 58bbf628-15d2-46bc-820b-863b6774d44b X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: GLAgyNzcXVmfXmZI5jGKVlGgZN98qmHOZ4pVrshRftxSy02QwTXSn+jQEGWIdWe3dbvZA6/rm/Lg9azrYkYS/C7NxSv5hZWAHXwrFPuGV58= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0P190MB0673 Archived-At: Subject: [dnssd] Parsing Service Discovery Instruction for SRP (2.3.1.1) X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2021 13:25:15 -0000 --_000_AM8P190MB097971C9F383D3283261F47EFDFF9AM8P190MB0979EURP_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgYWxsLCBUZWQsDQoNCldoaWxlIGRvaW5nIG15IFNSUCByZXZpZXcgSSBmb3VuZCBTZWN0aW9u IDIuMy4xLjEgb24gU2VydmljZSBEaXNjb3ZlcnkgSW5zdHJ1Y3Rpb24gYSBiaXQgZGlmZmljdWx0 IHRvIHBhcnNlOg0KDQoNCiJpZiB0aGUgU2VydmljZSBEaXNjb3ZlcnkgdXBkYXRlIGlzIGFuICJB ZGQgdG8gYW4gUlJTZXQiIGluc3RydWN0aW9uLCB0aGUgU2VydmljZSBEZXNjcmlwdGlvbiBJbnN0 cnVjdGlvbiBkb2VzIG5vdCBtYXRjaCBpZiINCg0KLT4gZm9yIG1lIHVuY2xlYXIgd2hhdCB0aGUg J2RvZXMgbm90IG1hdGNoJyByZWZlcnMgdG8uICBXaGF0IGlzIG1hdGNoZWQgd2l0aCB3aGF0Pw0K DQpXaHkgaXMgU2VydmljZSBEaXNjb3ZlcnkgSW5zdHJ1Y3Rpb24gbWVudGlvbmluZyDigJx0aGXi gJ0gU2VydmljZSBEZXNjcmlwdGlvbiBJbnN0cnVjdGlvbj8gKFdoaWNoIG9uZT8pDQoNCg0KDQoi IGlmIHRoZSBTZXJ2aWNlIERpc2NvdmVyeSBJbnN0cnVjdGlvbiBpcyBhbiAiRGVsZXRlIGFuIFJS IGZyb20gYW4gIFJSU2V0IiB1cGRhdGUsICINCg0KLT4gdGhlIGJ1bGxldCBsaXN0IHRyaWVzIHRv IGRlZmluZSB3aGF0IGNvbnN0aXR1dGVzIGEgU2VydmljZSBEaXNjb3ZlcnkgSW5zdHJ1Y3Rpb24u IE5vdyB0aGlzIGJ1bGxldCBwb2ludCBtZW50aW9ucyBhIFNlcnZpY2UgRGlzY292ZXJ5IEluc3Ry dWN0aW9uLCBldmVuIHRob3VnaCB3ZSBkb24ndCBrbm93IHlldCB3aGV0aGVyIHRoaXMgaW5zdHJ1 Y3Rpb24gY29uc3RpdHV0ZXMgYSBTZXJ2aWNlIERpc2NvdmVyeSBJbnN0cnVjdGlvbiBvciBub3Qh IFRoZSBidWxsZXQgbGlzdCB3YXMgdGhlcmUgaW4gdGhlIGZpcnN0IHBsYWNlIHRvIGZpbmQgdGhp cyBvdXQgc28gdGhlIGluc3RydWN0aW9uIGF0IHRoaXMgcG9pbnQgbWF5IG9yIG1heSBub3QgYmUg b2YgdGhlIFNlcnZpY2UgRGlzY292ZXJ5IEluc3RyIHR5cGUuDQoNCg0KDQpCZWxvdyAgaXMgYW4g YXR0ZW1wdGVkIHJld29yZGluZyBvZiB0aGUgZW50aXJlIHNlY3Rpb24sIHRvIHNpbXBsaWZ5IGFu ZCBjbGFyaWZ5IOKAkyBzb21lIHBhcnRzIEkgaGF2ZSBwcm9iYWJseSB3cm9uZyBidXQgSSBuZWVk IHRoaXMgdG8gdW5kZXJzdGFuZCB3aGF0IHRoZSBpbnRlbmRlZCBkZWZpbml0aW9uIGlzIHNvIEkg Y2FuIGdpdmUgcmV3b3JkaW5nIHN1Z2dlc3Rpb25zLg0KDQoNCg0KQW4gaW5zdHJ1Y3Rpb24gd2l0 aGluIGFuIFNSUCBVcGRhdGUgaXMgYSBTZXJ2aWNlIERpc2NvdmVyeSBJbnN0cnVjdGlvbiBpZg0K DQoNCg0KICAgKiAgaXQgY29udGFpbnMgZXhhY3RseSBvbmUgIkFkZCB0byBhbiBSUlNldCIgKFtS RkMyMTM2XSwgU2VjdGlvbiAyLjUuMTxodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9o dG1sL3JmYzIxMzYjc2VjdGlvbi0yLjUuMT4pIG9yIGV4YWN0bHkgb25lICJEZWxldGUgYW4gUlIg ZnJvbSBhbiBSUlNldCIgKFtSRkMyMTM2XSwgU2VjdGlvbiAyLjUuNDxodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9odG1sL3JmYzIxMzYjc2VjdGlvbi0yLjUuMT4pIFJSIHVwZGF0ZSBi dXQgbm8gYWRkaXRpb25hbCBSUiBVUERBVEVzLA0KICAgKiAgd2hpY2ggdXBkYXRlcyBhIFBUUiB0 eXBlIFJSLA0KICAgKiAgd2hpY2ggcG9pbnRzIHRvIGEgU2VydmljZSBJbnN0YW5jZSBOYW1lLA0K ICAgKiAgZm9yIHdoaWNoIFNlcnZpY2UgSW5zdGFuY2UgTmFtZSBhbHNvIGEgU2VydmljZSBEZXNj cmlwdGlvbiBJbnN0cnVjdGlvbiBpcyBwcmVzZW50IGluIHRoZSBzYW1lIFNSUCBVcGRhdGUsDQog ICAqICBhbmQgaW4gY2FzZSB0aGUgc2luZ2xlIGNvbnRhaW5lZCBSUiB1cGRhdGUgaXMgIkFkZCB0 byBhbiBSUlNldCIsIHRoZSBTUlAgVXBkYXRlIGFsc28gY29udGFpbnMgYSBTZXJ2aWNlIERlc2Ny aXB0aW9uIEluc3RydWN0aW9uIGluY2x1ZGluZyBvbmUgIkFkZCB0byBhbiBSUnNldCIgUlIgdXBk YXRlIGZvciB0aGUgU1JWIHR5cGUgUlINCiAgICAgIGRlZmluaW5nIHRoZSBzYW1lIFNlcnZpY2Ug SW5zdGFuY2UgTmFtZTsNCiAgICogb3IgaW4gY2FzZSB0aGUgc2luZ2xlIGNvbnRhaW5lZCBSUiB1 cGRhdGUgaXMgIkRlbGV0ZSBhbiBSUiBmcm9tIGFuIFJSU2V0IiwgdGhlIFNSUCBVcGRhdGUgY29u dGFpbnMgbm8gU2VydmljZSBEZXNjcmlwdGlvbiBJbnN0cnVjdGlvbiBpbmNsdWRpbmcgYW4gIkFk ZCB0byBhbiBSUnNldCIgdXBkYXRlIGZvciB0aGUgc2FtZSBTZXJ2aWNlIEluc3RhbmNlIE5hbWUu DQoNCg0KDQpDb3JyZWN0aW9ucy9mZWVkYmFjayBpcyB3ZWxjb21lIQ0KDQoNCkJlc3QgcmVnYXJk cw0KRXNrbw0KDQpJb1Rjb25zdWx0YW5jeS5ubCAgfCAgRW1haWwvVGVhbXM6IGVza28uZGlqa0Bp b3Rjb25zdWx0YW5jeS5ubDxtYWlsdG86ZXNrby5kaWprQGlvdGNvbnN1bHRhbmN5Lm5sPiAgICB8 ICAgKzMxIDYgMjM4NSA4MzM5DQoNCg== --_000_AM8P190MB097971C9F383D3283261F47EFDFF9AM8P190MB0979EURP_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVC My0xMWQxLUEyOUYtMDBBQTAwQzE0ODgyIiB4bWxuczptPSJodHRwOi8vc2NoZW1hcy5taWNyb3Nv ZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9S RUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250 ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBj b250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8c3R5bGU+PCEt LQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2Ft YnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9 DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2 Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6IzA1NjNDMTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs LWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2lu ZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9 DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGlu IDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlv bjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVs dHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlk bWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2Vu ZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZsaW5r PSIjOTU0RjcyIiBzdHlsZT0id29yZC13cmFwOmJyZWFrLXdvcmQiPg0KPGRpdiBjbGFzcz0iV29y ZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIGFsbCwgVGVkLDxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5XaGlsZSBkb2luZyBteSBTUlAgcmV2aWV3IEkgZm91bmQgU2VjdGlvbiAy LjMuMS4xIG9uIFNlcnZpY2UgRGlzY292ZXJ5IEluc3RydWN0aW9uIGEgYml0IGRpZmZpY3VsdCB0 byBwYXJzZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW4iPiZxdW90O2lmIHRoZSBTZXJ2aWNlIERp c2NvdmVyeSB1cGRhdGUgaXMgYW4gJnF1b3Q7QWRkIHRvIGFuIFJSU2V0JnF1b3Q7IGluc3RydWN0 aW9uLCB0aGUgU2VydmljZSBEZXNjcmlwdGlvbiBJbnN0cnVjdGlvbiBkb2VzIG5vdCBtYXRjaCBp ZiZxdW90OzxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW4iPi0mZ3Q7IGZvciBt ZSB1bmNsZWFyIHdoYXQgdGhlICdkb2VzIG5vdCBtYXRjaCcgcmVmZXJzIHRvLiZuYnNwOyBXaGF0 IGlzIG1hdGNoZWQgd2l0aCB3aGF0Pw0KPG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2lu OjBpbiI+V2h5IGlzIFNlcnZpY2UgRGlzY292ZXJ5IEluc3RydWN0aW9uIG1lbnRpb25pbmcg4oCc dGhl4oCdIFNlcnZpY2UgRGVzY3JpcHRpb24gSW5zdHJ1Y3Rpb24/IChXaGljaCBvbmU/KTxvOnA+ PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW4iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PHAgc3R5bGU9Im1hcmdpbjowaW4iPiZxdW90OyBpZiB0aGUgU2VydmljZSBEaXNjb3ZlcnkgSW5z dHJ1Y3Rpb24gaXMgYW4gJnF1b3Q7RGVsZXRlIGFuIFJSIGZyb20gYW4mbmJzcDsgUlJTZXQmcXVv dDsgdXBkYXRlLCAmcXVvdDs8bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluIj4t Jmd0OyB0aGUgYnVsbGV0IGxpc3QgdHJpZXMgdG8gZGVmaW5lIHdoYXQgY29uc3RpdHV0ZXMgYSBT ZXJ2aWNlIERpc2NvdmVyeSBJbnN0cnVjdGlvbi4gTm93IHRoaXMgYnVsbGV0IHBvaW50IG1lbnRp b25zIGEgU2VydmljZSBEaXNjb3ZlcnkgSW5zdHJ1Y3Rpb24sIGV2ZW4gdGhvdWdoIHdlIGRvbid0 IGtub3cgeWV0IHdoZXRoZXIgdGhpcyBpbnN0cnVjdGlvbiBjb25zdGl0dXRlcyBhIFNlcnZpY2Ug RGlzY292ZXJ5DQogSW5zdHJ1Y3Rpb24gb3Igbm90ISBUaGUgYnVsbGV0IGxpc3Qgd2FzIHRoZXJl IGluIHRoZSBmaXJzdCBwbGFjZSB0byBmaW5kIHRoaXMgb3V0IHNvIHRoZSBpbnN0cnVjdGlvbiBh dCB0aGlzIHBvaW50IG1heSBvciBtYXkgbm90IGJlIG9mIHRoZSBTZXJ2aWNlIERpc2NvdmVyeSBJ bnN0ciB0eXBlLjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW4iPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW4iPkJlbG93ICZuYnNwO2lzIGFuIGF0 dGVtcHRlZCByZXdvcmRpbmcgb2YgdGhlIGVudGlyZSBzZWN0aW9uLCB0byBzaW1wbGlmeSBhbmQg Y2xhcmlmeSDigJMgc29tZSBwYXJ0cyBJIGhhdmUgcHJvYmFibHkgd3JvbmcgYnV0IEkgbmVlZCB0 aGlzIHRvIHVuZGVyc3RhbmQgd2hhdCB0aGUgaW50ZW5kZWQgZGVmaW5pdGlvbiBpcyBzbyBJIGNh biBnaXZlIHJld29yZGluZyBzdWdnZXN0aW9ucy48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJt YXJnaW46MGluIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6MGluO21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTowaW47bWFyZ2luLWxlZnQ6 LjVpbiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+QW4gaW5z dHJ1Y3Rpb24gd2l0aGluIGFuIFNSUCBVcGRhdGUgaXMgYSBTZXJ2aWNlIERpc2NvdmVyeSBJbnN0 cnVjdGlvbiBpZg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDowaW47bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjBpbjttYXJnaW4tbGVm dDouNWluIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj4mbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjBp bjttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206MGluO21hcmdpbi1sZWZ0Oi41aW4iPg0K PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyAq Jm5ic3A7IGl0IGNvbnRhaW5zIGV4YWN0bHkgb25lICZxdW90O0FkZCB0byBhbiBSUlNldCZxdW90 OyAoPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48YSBocmVmPSJodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL3JmYzIxMzYjc2VjdGlvbi0yLjUuMSI+W1JG QzIxMzZdLCBTZWN0aW9uJm5ic3A7Mi41LjE8L2E+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4p IG9yDQogZXhhY3RseSBvbmUgJnF1b3Q7RGVsZXRlIGFuIFJSIGZyb20gYW4gUlJTZXQmcXVvdDsg KDwvc3Bhbj48YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL3Jm YzIxMzYjc2VjdGlvbi0yLjUuMSI+W1JGQzIxMzZdLCBTZWN0aW9uJm5ic3A7Mi41LjQ8L2E+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4pIFJSIHVwZGF0ZSBidXQgbm8gYWRkaXRpb25hbCBSUiBV UERBVEVzLDxicj4NCiZuYnNwOyZuYnNwOyAqJm5ic3A7IHdoaWNoIHVwZGF0ZXMgYSBQVFIgdHlw ZSBSUiw8YnI+DQombmJzcDsmbmJzcDsgKiZuYnNwOyB3aGljaCBwb2ludHMgdG8gYSBTZXJ2aWNl IEluc3RhbmNlIE5hbWUsPGJyPg0KJm5ic3A7Jm5ic3A7ICombmJzcDsgZm9yIHdoaWNoIFNlcnZp Y2UgSW5zdGFuY2UgTmFtZSBhbHNvIGEgU2VydmljZSBEZXNjcmlwdGlvbiBJbnN0cnVjdGlvbiBp cyBwcmVzZW50IGluIHRoZSBzYW1lIFNSUCBVcGRhdGUsPGJyPg0KJm5ic3A7Jm5ic3A7ICombmJz cDsgYW5kIGluIGNhc2UgdGhlIHNpbmdsZSBjb250YWluZWQgUlIgdXBkYXRlIGlzICZxdW90O0Fk ZCB0byBhbiBSUlNldCZxdW90OywgdGhlIFNSUCBVcGRhdGUgYWxzbyBjb250YWlucyBhIFNlcnZp Y2UgRGVzY3JpcHRpb24gSW5zdHJ1Y3Rpb24gaW5jbHVkaW5nIG9uZSAmcXVvdDtBZGQgdG8gYW4g UlJzZXQmcXVvdDsgUlIgdXBkYXRlIGZvciB0aGUgU1JWIHR5cGUgUlI8YnI+DQombmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgZGVmaW5pbmcgdGhlIHNhbWUgU2VydmljZSBJbnN0YW5jZSBO YW1lOzxicj4NCiZuYnNwOyZuYnNwOyAqIG9yIGluIGNhc2UgdGhlIHNpbmdsZSBjb250YWluZWQg UlIgdXBkYXRlIGlzICZxdW90O0RlbGV0ZSBhbiBSUiBmcm9tIGFuIFJSU2V0JnF1b3Q7LCB0aGUg U1JQIFVwZGF0ZSBjb250YWlucyBubyBTZXJ2aWNlIERlc2NyaXB0aW9uIEluc3RydWN0aW9uIGlu Y2x1ZGluZyBhbiAmcXVvdDtBZGQgdG8gYW4gUlJzZXQmcXVvdDsgdXBkYXRlIGZvciB0aGUgc2Ft ZSBTZXJ2aWNlIEluc3RhbmNlIE5hbWUuPC9zcGFuPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6MGluO21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJv dHRvbTowaW47bWFyZ2luLWxlZnQ6LjVpbiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dDtjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Im1h cmdpbjowaW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5Db3Jy ZWN0aW9ucy9mZWVkYmFjayBpcyB3ZWxjb21lITxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0 eWxlPSJtYXJnaW46MGluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFj ayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QmVz dCByZWdhcmRzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Fc2tvPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpF Ti1HQiI+SW9UY29uc3VsdGFuY3kubmw8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFz dC1sYW5ndWFnZTpFTi1HQiI+Jm5ic3A7IHwmbmJzcDsgRW1haWwvVGVhbXM6DQo8YSBocmVmPSJt YWlsdG86ZXNrby5kaWprQGlvdGNvbnN1bHRhbmN5Lm5sIj48c3BhbiBzdHlsZT0iY29sb3I6IzA1 NjNDMSI+ZXNrby5kaWprQGlvdGNvbnN1bHRhbmN5Lm5sPC9zcGFuPjwvYT4mbmJzcDsmbmJzcDsm bmJzcDsgfCZuYnNwOyZuYnNwOyArMzEgNg0KPC9zcGFuPjIzODUgODMzOTxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwv Ym9keT4NCjwvaHRtbD4NCg== --_000_AM8P190MB097971C9F383D3283261F47EFDFF9AM8P190MB0979EURP_-- From nobody Wed Aug 18 08:05:40 2021 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB6043A1DB9 for ; Wed, 18 Aug 2021 08:05:38 -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=unavailable 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 PK-W5MC-p1Fk for ; Wed, 18 Aug 2021 08:05:33 -0700 (PDT) Received: from mail-qv1-xf2d.google.com (mail-qv1-xf2d.google.com [IPv6:2607:f8b0:4864:20::f2d]) (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 769EA3A1DAB for ; Wed, 18 Aug 2021 08:05:33 -0700 (PDT) Received: by mail-qv1-xf2d.google.com with SMTP id dt3so1816055qvb.6 for ; Wed, 18 Aug 2021 08:05:33 -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=WAjeGq/Z4cvFj+ngreIClKZW9G0xVi0vpQPtxX0sswk=; b=R80guHbtAefjakXnH6GZnHI1UgV1V6HEUvuoijHlZxcVU+KRfZxEuwMrD7xIbpRYVR /MJIp7IO2NCnoDPa8ioc9d8tfK0JHh5pf5kuLWnQLlLPTtXbbBzCjKZ7JZdtSWw8XIJ5 liAE6S7gOavXVNpzWMzIBOoFrWLejvcVDQi54li3a65jAaCvcFtQi5inFKYfymmzvepS akY3kHMKLr72rny3QDY+JbV8Cyhvb3mhiR81TwANWTWUS+TccoLayCFJ8BgsJeq6Ih2o KL/uciGX3YOLGxRY/97ylkrza1KziRwhZD+4NEo4lXUvZHqm6/7o5AYsjHCBJ2k46zNd XVEg== 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=WAjeGq/Z4cvFj+ngreIClKZW9G0xVi0vpQPtxX0sswk=; b=doaeLvnISEX4wF8W6gPxTMQMo0g68giCzqvBxUT1toz7i9IA3nc8QDK2XSTTViap3D +HNQ07vrR6PlTbSm31z8Xn3t/j4iuAlLpxuhid5k0z0JPUe6T5iylumfsiPZie0N83Yw NlkHX9t+VOSAnQYYDzpcA7xrl2B9yKooXff4SnFuqObRBCIrrjf0cgoNFpZqUMBwiT/B zCMvy60ubyC9o3JT2iv8SV3N6NdL1SEcJm5tJPF52Y5JBQtOa4xCL83ObNXvFysiWU5X p2WzdxA1EUxd1OykJeu2Niyk8Musvdm2wDRqgpRZNuL3xFt3fOmpm7Q4Gs5zgqT4sk6Q cAcA== X-Gm-Message-State: AOAM533OSUNtZgYRMH6CLkM5KABJhTmQhaFCj/MffYmTuZbPKwG/otDA i5EnOUcE0ywzTapKG79hdcOWRDy/qCi+YuMPCoQ= X-Google-Smtp-Source: ABdhPJyiLLVEBX3dwg8NMyI/9n1eljcZnZVKwM2YiI4lIlNnQRJY7ZyCvZ3Iy4btoPdi/0ROffoqSlJuatCWB3B6IFg= X-Received: by 2002:ad4:46cb:: with SMTP id g11mr9430287qvw.45.1629299131353; Wed, 18 Aug 2021 08:05:31 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Lanlan Pan Date: Wed, 18 Aug 2021 23:05:19 +0800 Message-ID: To: Ted Lemon Cc: Simon Lin , dnssd Content-Type: multipart/alternative; boundary="000000000000f5108605c9d6c31c" Archived-At: Subject: Re: [dnssd] Adoption call for draft-sctl-advertising-proxy X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2021 15:05:39 -0000 --000000000000f5108605c9d6c31c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Ted Lemon =E4=BA=8E2021=E5=B9=B48=E6=9C=8818=E6=97=A5=E5= =91=A8=E4=B8=89 =E4=B8=8A=E5=8D=886:46=E5=86=99=E9=81=93=EF=BC=9A > > On August 17, 2021 at 10:33:00 AM, Lanlan Pan (abbypan@gmail.com) wrote: > > I don't think dnssd-zone-discover helps with this. I think the client > needs to either unregister itself with SRP before migrating, or follow th= e > same protocol I mentioned earlier with respect to its service > advertisement: advertise without asserting uniqueness. > > +1, advertise without asserting uniqueness. > To join in a Thread zone, srp client should be authenticated through > J-PAKE or other protocols. the srp client only its own the srp server, th= e > srp server can only ensure the uniqueness in its zone, but not asserting > the uniqueness with other zones. > If srp client migrating to a mdns client, just follow the mdns conflicts > policy. > > Actually that's not really an issue we address. Yes, on a network like > Thread, the commissioning process guarantees that the client has the righ= t > to connect, but it doesn't guarantee a unique hostname. Some other part o= f > the onboarding process might do that, or might not, but SRP doesn't reall= y > pay attention to that. Rather, devices are expected to have a unique > public/private key pair that's used to claim the name, and conflicts are > detected by noticing that the client making a claim to a name has signed > their claim with the wrong key (wrong meaning not the key that was used > last time). And then that client doesn't get the name. This is FCFS namin= g. > > As long as there is a single SRP namespace, it's fine for it to span more > than one network link, because the FCFS naming process ensures that there > will be no duplicate names. If a device moves from Thread to WiFi, we wan= t > it to keep the same name. > Thank you for the clarification. > The problem is that mDNS currently lacks the capability to defend names > using FCFS, and so when this roaming occurs, if there is an overlap betwe= en > the lifetime of the SRP registration and the lifetime of the mDNS > advertisement, we need a strategy for dealing with that. > > The strategy I'm proposing is that we allow the conflict to exist, and le= t > the application figure out which information to use. Ultimately though we > want WiFi clients to use SRP, with FCFS naming, and that solves the probl= em. > allowing conflict at Public WiFi may be better for user privacy ? or WiFi clients using SRP with FCFS naming is an opt-in in a smart home environment ? > We could do what the Discovery Proxy does and give each link its own name= , > but I didn't suggest going that route because I think it's confusing. Is = a > device with the same name in a different domain the same device that's > moved to a different network, or a different device? The application stil= l > has to figure this out, so we haven't gained anything. Additionally, the > app needs to do more work, because now it has to have a list of domains t= o > query (or the API for finding names has to know to query multiple domains= ). > > Also, with that model, when a device roams to a new link, until it's > discovered to have roamed, there is no name the app can use to immediatel= y > reference the device, because now the name changes from link to link. So > the app has to always be doing discovery just to find the device when it > roams, even if it isn't interested in other devices that have the same > service type. > So that's why I tend to prefer the model where we do our best to avoid > conflicts, but when we have duplicate information, we allow it to coexist= . > The app should be able to fairly easily figure out which information to > use, and the period of coexistence should be brief, so if there is a cost > to disambiguating, it will be paid only infrequently. > Yes, the discovery is the base cost. If the app and the device exchanged some trust credentials (TOFU public key/psk/...), it can know the real device when it finds two devices with the same name. If the app trusts anything without authentication, then there may be some problem. --000000000000f5108605c9d6c31c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Ted Lemon <mellon@fugue.com> =E4=BA=8E2021=E5=B9=B48=E6=9C=8818=E6=97=A5=E5= =91=A8=E4=B8=89 =E4=B8=8A=E5=8D=886:46=E5=86=99=E9=81=93=EF=BC=9A
=

On August 17, 2021 at 10:33:00 AM, Lanl= an Pan (abbypan@gmai= l.com) wrote:

I don't think dnssd-zone-discover helps with this. I think the cli= ent needs to either unregister itself with SRP before migrating, or follow = the same protocol I mentioned earlier with respect to its service advertise= ment: advertise without asserting uniqueness.

+1,=C2= =A0 advertise without asserting uniqueness.
To join in a Thread zone,=C2=A0 srp c= lient should be authenticated through J-PAKE or other protocols. the srp cl= ient only its own the srp server, the srp server can only ensure the unique= ness in its zone, but not asserting the uniqueness with other zones.
If srp c= lient migrating to a mdns client, just follow the mdns conflicts policy.

Actually that's not really an issue we address= . Yes, on a network like Thread, the commissioning process guarantees that = the client has the right to connect, but it doesn't guarantee a unique = hostname. Some other part of the onboarding process might do that, or might= not, but SRP doesn't really pay attention to that. Rather, devices are= expected to have a unique public/private key pair that's used to claim= the name, and conflicts are detected by noticing that the client making a = claim to a name has signed their claim with the wrong key (wrong meaning no= t the key that was used last time). And then that client doesn't get th= e name. This is FCFS naming.

As long as there is a single SRP namespa= ce, it's fine for it to span more than one network link, because the FC= FS naming process ensures that there will be no duplicate names. If a devic= e moves from Thread to WiFi, we want it to keep the same name.

Thank you for the clarification.
=
=C2=A0

The problem is t= hat mDNS currently lacks the capability to defend names using FCFS, and so = when this roaming occurs, if there is an overlap between the lifetime of th= e SRP registration and the lifetime of the mDNS advertisement, we need a st= rategy for dealing with that.

The strategy I'm proposing is that = we allow the conflict to exist, and let the application figure out which in= formation to use. Ultimately though we want WiFi clients to use SRP, with F= CFS naming, and that solves the problem.

a= llowing conflict at Public WiFi may be better for user privacy ? or WiFi cl= ients using SRP with FCFS naming is an opt-in in a smart home environment ?=

We could do what the Dis= covery Proxy does and give each link its own name, but I didn't suggest= going that route because I think it's confusing. Is a device with the = same name in a different domain the same device that's moved to a diffe= rent network, or a different device? The application still has to figure th= is out, so we haven't gained anything. Additionally, the app needs to d= o more work, because now it has to have a list of domains to query (or the = API for finding names has to know to query multiple domains).

Also, w= ith that model, when a device roams to a new link, until it's discovere= d to have roamed, there is no name the app can use to immediately reference= the device, because now the name changes from link to link. So the app has= to always be doing discovery just to find the device when it roams, even i= f it isn't interested in other devices that have the same service type.=

So th= at's why I tend to prefer the model where we do our best to avoid confl= icts, but when we have duplicate information, we allow it to coexist. The a= pp should be able to fairly easily figure out which information to use, and= the period of coexistence should be brief, so if there is a cost to disamb= iguating, it will be paid only infrequently.

Yes, the discovery is the base cost.
If the app and t= he device exchanged some trust credentials (TOFU public key/psk/...), it=20 can know the real device when it finds two devices with the same=20 name. If the app trusts anything without authentication, then there may be = some problem.
=C2=A0
--000000000000f5108605c9d6c31c-- From nobody Wed Aug 18 09:31:03 2021 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2FB93A07E0; Wed, 18 Aug 2021 09:31:00 -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 b9b0p7NkCEJc; Wed, 18 Aug 2021 09:30:55 -0700 (PDT) Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com [IPv6:2607:f8b0:4864:20::834]) (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 6CAD23A07D2; Wed, 18 Aug 2021 09:30:55 -0700 (PDT) Received: by mail-qt1-x834.google.com with SMTP id l3so1996338qtk.10; Wed, 18 Aug 2021 09:30:55 -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:cc; bh=NCoGhQlXVu8RHW+FkovUatXmOMqjL/ZCe6J7NISgIzk=; b=JX+pGHkMtKB4ljLtYJx9QrrcPM+BfZ8Azxj7hkwlndTg9KOVPDof/fS8JRcObX7sze BcbdAYeIaoLMIGW8QDWcMDMROOfESiCc8gOuldVyFHi6X6/Jzm4nh1S9lkYmrJxfhW7e LqaEuYDGjlq1IunKfhbi1PQtT7aM0/ThsjByrsMNQhY6/oNIWTm0DIp1qRb8me7lap1S e5N85VpCr4PO5ryDTy3yD7Fs3spzuYuBaEXbD2X15AS37HXVAIfJJlSzKH+CwpXUt0+7 XXNTSZ8d0uQ3LFgXKuIiL4s+J6+tEJKNoQLXUbSpfGqZbpdZqiUx2WJyT3dmZFMbIDzq EwUg== 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:cc; bh=NCoGhQlXVu8RHW+FkovUatXmOMqjL/ZCe6J7NISgIzk=; b=EK/RrtfxrRNwSw1eobIX28npurgIYccUdvmnuMS+fIUwC25zAvJEup25s993XYJqtG WnL13tJvtfpz6ydk75pcLhD46ilEuo/CiGza/8LntOjxdfAUFf0w0X7113YZWV+wpqRf 4Td4acj44GD2BUR8r9tSJtcjDHheWySiNl8bsViQqggEZbzREhzX15yZ6GB8yprRA7l7 UoMOX+BUcePIa7+laDHvaUfMueiSz71B8m/sD57W1SrZykVeb5DSDr0xwvHnS/aUdreZ QgtyudVjHPCN6SkiG0kpKnvaSchDqP4tAciqgIvRZCNARLJBGeEqLXI9bnFQT/vVcdjK kOeQ== X-Gm-Message-State: AOAM5303TfrPgXr6vKa7MuVQzu/xZOUDvKmOw3Xc1BaiH6wBCuiidVU6 g6zv4PCvTS88ykyuFzx5ou8KKJ7xcpQVh1g+LBO/GnTfaYU= X-Google-Smtp-Source: ABdhPJxSbChQswEr0OD30b1utVy55LilqdSH5XMA0nR1qrLIBlgXR/+SvfXW9wjXdpX6GQDImIvj2cGAblijSi1faMI= X-Received: by 2002:ac8:1498:: with SMTP id l24mr8438034qtj.169.1629304252874; Wed, 18 Aug 2021 09:30:52 -0700 (PDT) MIME-Version: 1.0 From: Chris Box Date: Wed, 18 Aug 2021 17:30:42 +0100 Message-ID: To: dnssd Cc: dnsop@ietf.org Content-Type: multipart/alternative; boundary="00000000000039431c05c9d7f528" Archived-At: Subject: [dnssd] Adoption call for draft-sekar-dns-ul-03 into DNSSD X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2021 16:31:01 -0000 --00000000000039431c05c9d7f528 Content-Type: text/plain; charset="UTF-8" WG members, This email starts a call to adopt https://datatracker.ietf.org/doc/html/draft-sekar-dns-ul-03 into the DNSSD working group. What is this? Abstract: This document proposes a new EDNS0 option that can be used by DNS Update clients and DNS servers to include a lease lifetime in a DNS Update or response, allowing a server to garbage collect stale resource records that have been added by DNS Updates Adoption means that formal change control passes from the authors to the working group. All subsequent substantive changes require WG rough consensus. Adoption represents a commitment that the DNSSD WG will spend time on the draft, with the aim of progressing it towards publication. Note that in theory the draft could fit the charters of both DNSOP and DNSSD, but we're proposing DNSSD as this specific functionality is required as part of draft-ietf-dnssd-srp which is already well advanced. The relevant charter text is: 2. To develop an improved, scalable solution for service discovery that can operate in multi-link networks, where devices may be in neighboring or non-neighboring links, applicable to the scenarios above. The solution will consider tradeoffs between reusing/extending existing protocols and developing entirely new protocols. This email is being copied to DNSOP to solicit additional feedback from the expertise there, but note this is NOT a call to adopt into DNSOP. You should be aware this draft is covered by an IPR disclosure. Details of Apple's licensing terms can be found at https://datatracker.ietf.org/ipr/1236/. Within DNSSD we are asking two questions: 1) If you have read this six-page draft and are content with it, or would like to amend/discuss it further inside the working group, please speak up now. 2) If you believe that this document is not something the DNSSD working group should be working on, please also say so. For this call to succeed, we'll need statements of explicit support from people who have read the draft. The document does not have to be perfect, but it needs to be solving a problem the WG wants to solve in a way approximately as described in the draft. Please send statements in support or against, as responses to this email. This call will be open until 2021-09-03 23:59 UTC. Thanks, Chris --00000000000039431c05c9d7f528 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
WG members,

This email starts a call to adopt https://datatracker.i= etf.org/doc/html/draft-sekar-dns-ul-03 into the DNSSD working group.

What is this? Abstract:
=C2=A0 =C2=A0This document proposes a new EDNS0 option that can be u= sed by DNS
=C2=A0 =C2=A0Update cl= ients and DNS servers to include a lease lifetime in a DNS
=C2=A0 =C2=A0Update or response, allowing a serve= r to garbage collect stale
=C2=A0= =C2=A0resource records that have been added by DNS Updates

Adoption means that formal change control passes from the = authors to the working group. All subsequent substantive changes require WG= rough consensus. Adoption represents a commitment that the DNSSD WG will s= pend time on the draft, with the aim of progressing it towards publication.=
=C2=A0 =C2=A0
Note that in theory the draft could fit = the charters of both DNSOP and DNSSD, but we're proposing DNSSD as this= specific functionality is required as part of=C2=A0draft-ietf-dnssd-srp=C2=A0w= hich is already well advanced. The relevant charter text is:

=
2. To develop an improved, scalable sol= ution for service discovery=C2=A0
=C2=A0 =C2=A0that can operate in multi-link networks, where devices may be=
=C2=A0 =C2=A0in neighboring or n= on-neighboring links, applicable to
=C2=A0 =C2=A0the scenarios above.=C2=A0 The solution will consider trade= offs between
=C2=A0 =C2=A0reusing= /extending existing protocols and developing entirely new
= =C2=A0 =C2=A0protocols.=C2=A0
=C2= =A0 =C2=A0
This email is being copied to DNSOP to solicit additio= nal feedback from the expertise there, but note this is NOT a call to adopt= into DNSOP.

You should be aware this draft is cov= ered by an IPR disclosure. Details of Apple's licensing terms can be fo= und at https://datatrack= er.ietf.org/ipr/1236/.
=C2=A0 =C2=A0
Within DNSSD w= e are asking two questions:
1) If you have read this six-page dra= ft and are content with it, or would like to amend/discuss it further insid= e the working group, please speak up now.
2) If you believe that = this document is not something the DNSSD working group should be working on= , please also say so.

For this call to succeed= , we'll need statements of explicit support from people who have read t= he draft. The document does not have to be perfect, but it needs to be solv= ing a problem the WG wants to solve in a way approximately as described in = the draft.

Please send statements in support or ag= ainst, as responses to this email. This call will be open until 2021-09-03 = 23:59 UTC.
=C2=A0
Thanks,
Chris

--00000000000039431c05c9d7f528-- From nobody Wed Aug 18 09:54:33 2021 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D8C23A08D9 for ; Wed, 18 Aug 2021 09:54:30 -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 BOW5A8eOr3dI for ; Wed, 18 Aug 2021 09:54:24 -0700 (PDT) Received: from mail-pj1-x1034.google.com (mail-pj1-x1034.google.com [IPv6:2607:f8b0:4864:20::1034]) (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 5D27E3A08D5 for ; Wed, 18 Aug 2021 09:54:24 -0700 (PDT) Received: by mail-pj1-x1034.google.com with SMTP id u13-20020a17090abb0db0290177e1d9b3f7so9333328pjr.1 for ; Wed, 18 Aug 2021 09:54:24 -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=yNnst8DKRI7ypMSKH4tgSzgOv9Q/sIm+YQuCsbCJCz4=; b=ZsoVFsiRQy/QYg1gmvkOXFzkM5oAshSzgyplwb4EzNVcXqvMP12/kWJK4Sv2R/wpbc jCWhpaZDYC98p2TL7zxgVtw2yfB0QwtQvKD+6K9g7YrIipSUFGPUCGvJz5+sLVT9uy04 6iPKnEmfNcQ8Guygh+ocsfVl7xqq7LOSvUD2yk64o9JnH16o5Wc/ccgd/VpWM62efL60 B3Jf5bv68JxOELn/FMqgzdhW+juw8y8Ej7I+CTHt11GGY7293Xu6vXX5NEU1eZhnNGZi +Q+K+1sEK2hDf/M8p6fF3UFk19G1jyLLOUbCAjb/uhnkYMKfLbdK4AdbBq8Aooj4Is2H BB5Q== 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=yNnst8DKRI7ypMSKH4tgSzgOv9Q/sIm+YQuCsbCJCz4=; b=VmXJddahBynAjiKaVKXszApbTWQZPMq/PKeWZ4WtMdDpo2RN4eeNNC8e3pWuK8mjMv 3C45nEvoF9ScfAvER3GKr0ri3uqmAem4iNcyayKsHcLmAagvUHPK5+PmeOY23acTuPcN 9f7KR7k1s4yZaapy+5VvnM/5LaCZ/mRFpojGogJ9EYyPNTKnlc8TdehhK0Ein3/Y0D1H jX76LHAuBDOZ4ZmJyADN4Vj1Jzmte1r8vW1tBL1aKoCeWgtmJl6CC8zlxK5BMP2AS4Za ZWrStNsJQlmld6oV20lLwM5a4yeWUvF5fR80jAp76gynBb+rsjYIQ6titKx2LIMV7OTA MDUQ== X-Gm-Message-State: AOAM531/EzU1hoQU17dFJGJOHsqnAbagc9PxgwwBrvh1VNofGL5giENj C5TFg+D2FelqMFq0WoeIyjVbyWiaC9BQqtA7cCU= X-Google-Smtp-Source: ABdhPJwg2Hb36DQtaRA2JzgW/vRKmXF+A8F2IQ4kUJPoxfqn+FhBSCSW575RdPBLvNf9vXGUSm8Rdr5VMXMLFs9iJ8k= X-Received: by 2002:a17:902:6507:b029:12d:2292:f750 with SMTP id b7-20020a1709026507b029012d2292f750mr8026401plk.54.1629305662974; Wed, 18 Aug 2021 09:54:22 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: David Schinazi Date: Wed, 18 Aug 2021 09:54:11 -0700 Message-ID: To: Chris Box Cc: dnssd Content-Type: multipart/alternative; boundary="00000000000045aecb05c9d8497e" Archived-At: Subject: Re: [dnssd] Adoption call for draft-sekar-dns-ul-03 into DNSSD X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2021 16:54:31 -0000 --00000000000045aecb05c9d8497e Content-Type: text/plain; charset="UTF-8" [ DNSOP to BCC to limit cross-posting ] Speaking as an individual contributor, I have read the draft and support adoption in DNSSD. David On Wed, Aug 18, 2021 at 9:31 AM Chris Box wrote: > WG members, > > This email starts a call to adopt > https://datatracker.ietf.org/doc/html/draft-sekar-dns-ul-03 into the > DNSSD working group. > > What is this? Abstract: > This document proposes a new EDNS0 option that can be used by DNS > Update clients and DNS servers to include a lease lifetime in a DNS > Update or response, allowing a server to garbage collect stale > resource records that have been added by DNS Updates > > Adoption means that formal change control passes from the authors to the > working group. All subsequent substantive changes require WG rough > consensus. Adoption represents a commitment that the DNSSD WG will spend > time on the draft, with the aim of progressing it towards publication. > > Note that in theory the draft could fit the charters of both DNSOP and > DNSSD, but we're proposing DNSSD as this specific functionality is required > as part of draft-ietf-dnssd-srp > which is already > well advanced. The relevant charter text is: > > 2. To develop an improved, scalable solution for service discovery > that can operate in multi-link networks, where devices may be > in neighboring or non-neighboring links, applicable to > the scenarios above. The solution will consider tradeoffs between > reusing/extending existing protocols and developing entirely new > protocols. > > This email is being copied to DNSOP to solicit additional feedback from > the expertise there, but note this is NOT a call to adopt into DNSOP. > > You should be aware this draft is covered by an IPR disclosure. Details of > Apple's licensing terms can be found at > https://datatracker.ietf.org/ipr/1236/. > > Within DNSSD we are asking two questions: > 1) If you have read this six-page draft and are content with it, or would > like to amend/discuss it further inside the working group, please speak up > now. > 2) If you believe that this document is not something the DNSSD working > group should be working on, please also say so. > > For this call to succeed, we'll need statements of explicit support from > people who have read the draft. The document does not have to be perfect, > but it needs to be solving a problem the WG wants to solve in a way > approximately as described in the draft. > > Please send statements in support or against, as responses to this email. > This call will be open until 2021-09-03 23:59 UTC. > > Thanks, > Chris > > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd > --00000000000045aecb05c9d8497e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
[ DNSOP to BCC to limit cross-posting ]
Speaking as an individual contributor, I have read the draft and sup= port adoption in DNSSD.

David

On Wed, Aug 18, 2021= at 9:31 AM Chris Box <chris= .box.ietf@gmail.com> wrote:
=
WG members,

This email starts a call to adopt= https://datatracker.ietf.org/doc/html/draft-sekar-dns-ul-03= into the DNSSD working group.

What is this? A= bstract:
=C2=A0 =C2=A0This document prop= oses a new EDNS0 option that can be used by DNS
=C2=A0 =C2=A0Update clients and DNS servers to include a lea= se lifetime in a DNS
=C2=A0 =C2= =A0Update or response, allowing a server to garbage collect stale
=C2=A0 =C2=A0resource records that have be= en added by DNS Updates

Adoption means that= formal change control passes from the authors to the working group. All su= bsequent substantive changes require WG rough consensus. Adoption represent= s a commitment that the DNSSD WG will spend time on the draft, with the aim= of progressing it towards publication.
=C2=A0 =C2=A0
N= ote that in theory the draft could fit the charters of both DNSOP and DNSSD= , but we're proposing DNSSD as this specific functionality is required = as part of=C2=A0draft-ietf-dnssd-srp=C2=A0which is already we= ll advanced. The relevant charter text is:

2. To develop an improved, scalable solution for service = discovery=C2=A0
=C2=A0 =C2=A0that= can operate in multi-link networks, where devices may be
= =C2=A0 =C2=A0in neighboring or non-neighboring lin= ks, applicable to
=C2=A0 =C2=A0th= e scenarios above.=C2=A0 The solution will consider tradeoffs between
=C2=A0 =C2=A0reusing/extending existin= g protocols and developing entirely new
=C2=A0 =C2=A0protocols.=C2=A0
=C2=A0 =C2=A0
This email is being copied to DNSOP to solicit additional feedback from = the expertise there, but note this is NOT a call to adopt into DNSOP.
=

You should be aware this draft is covered by an IPR dis= closure. Details of Apple's licensing terms can be found at https://datatrack= er.ietf.org/ipr/1236/.
=C2=A0 =C2=A0
Within DNSSD w= e are asking two questions:
1) If you have read this six-page dra= ft and are content with it, or would like to amend/discuss it further insid= e the working group, please speak up now.
2) If you believe that = this document is not something the DNSSD working group should be working on= , please also say so.

For this call to succeed= , we'll need statements of explicit support from people who have read t= he draft. The document does not have to be perfect, but it needs to be solv= ing a problem the WG wants to solve in a way approximately as described in = the draft.

Please send statements in support or ag= ainst, as responses to this email. This call will be open until 2021-09-03 = 23:59 UTC.
=C2=A0
Thanks,
Chris

_______________________________________________
dnssd mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/listinfo/dnssd
--00000000000045aecb05c9d8497e-- From nobody Wed Aug 18 14:10:18 2021 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB46F3A0878 for ; Wed, 18 Aug 2021 14:10:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, 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.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=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 R-SwezdK_seb for ; Wed, 18 Aug 2021 14:10:13 -0700 (PDT) Received: from ma1-aaemail-dr-lapp03.apple.com (ma1-aaemail-dr-lapp03.apple.com [17.171.2.72]) (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 CE25B3A0869 for ; Wed, 18 Aug 2021 14:10:12 -0700 (PDT) Received: from pps.filterd (ma1-aaemail-dr-lapp03.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp03.apple.com (8.16.0.42/8.16.0.42) with SMTP id 17IL8oi5002753; Wed, 18 Aug 2021 14:10:11 -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=Emn3h1qkc2bnbrPWqKfqHF9anXT/WmJ8Q17vGS3eKvc=; b=hHYPtiAUBnQ1fbQmwqrN/QrN/iVzTzBTgAoyEj314LXwArYXzOPw9APwybT4Wr5OjWjp jtNwwH6r7VG8jOcTIsI61C4Bm6C7OUO42PaLMwo7mSye0nBEbfC2NVwpCEMH8oDjWHqu FTM4UkZp5l557KAu7RKBJLx0FJyNaqnY0Mh5zJ0bCyi/owU941m9UGVpAD06QU31No3K RuyQowsjmKA5n8FzomLoaVOH9uBuIRYrRSOIAnZtdML7kfpP70tq1Z2cR/3pPCyIcTnI +DYmpXS+dFtELkJbey7Q9SNf7W11BTMjFMmotlrUFO4WHq8ns4C2MDXRewuIxaTbzP7B lw== Received: from rn-mailsvcp-mta-lapp04.rno.apple.com (rn-mailsvcp-mta-lapp04.rno.apple.com [10.225.203.152]) by ma1-aaemail-dr-lapp03.apple.com with ESMTP id 3aectvejf6-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 18 Aug 2021 14:10:10 -0700 Received: from rn-mailsvcp-mmp-lapp02.rno.apple.com (rn-mailsvcp-mmp-lapp02.rno.apple.com [17.179.253.15]) by rn-mailsvcp-mta-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.9.20210415 64bit (built Apr 15 2021)) with ESMTPS id <0QY200QZW04X5660@rn-mailsvcp-mta-lapp04.rno.apple.com>; Wed, 18 Aug 2021 14:10:09 -0700 (PDT) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp02.rno.apple.com by rn-mailsvcp-mmp-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.9.20210415 64bit (built Apr 15 2021)) id <0QY100700ZM3OQ00@rn-mailsvcp-mmp-lapp02.rno.apple.com>; Wed, 18 Aug 2021 14:10:09 -0700 (PDT) X-Va-A: X-Va-T-CD: cdaa14cfcfc144345f8b3130a3d22b5b X-Va-E-CD: 6f754f8131a85880569787de3c991531 X-Va-R-CD: 3ebf9e977f2df3b3c0fd53fa98ff3072 X-Va-CD: 0 X-Va-ID: 1e01d29d-32ad-4685-b2c4-e6b4d67a490e X-V-A: X-V-T-CD: cdaa14cfcfc144345f8b3130a3d22b5b X-V-E-CD: 6f754f8131a85880569787de3c991531 X-V-R-CD: 3ebf9e977f2df3b3c0fd53fa98ff3072 X-V-CD: 0 X-V-ID: 17029eca-c47c-499f-940c-04f0f0ebb674 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-08-18_07:2021-08-17, 2021-08-18 signatures=0 Received: from smtpclient.apple (unknown [17.11.85.144]) by rn-mailsvcp-mmp-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.9.20210415 64bit (built Apr 15 2021)) with ESMTPSA id <0QY200R9W04X3W00@rn-mailsvcp-mmp-lapp02.rno.apple.com>; Wed, 18 Aug 2021 14:10:09 -0700 (PDT) From: Manuel Roman Message-id: <2301D501-01DD-4739-8CBA-900BC4514869@apple.com> Content-type: multipart/alternative; boundary="Apple-Mail=_421BB511-CC8A-4ED2-8F3B-B80882E8DD77" MIME-version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Date: Wed, 18 Aug 2021 14:10:08 -0700 In-reply-to: Cc: Chris Box , dnssd To: David Schinazi References: X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-08-18_07:2021-08-17, 2021-08-18 signatures=0 Archived-At: Subject: Re: [dnssd] Adoption call for draft-sekar-dns-ul-03 into DNSSD X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2021 21:10:18 -0000 --Apple-Mail=_421BB511-CC8A-4ED2-8F3B-B80882E8DD77 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I have read the document and I would like to support its adoption. This = contribution is key to the success to application protocols running on = Thread such as Matter. Thanks, Manuel > On Aug 18, 2021, at 9:54 AM, David Schinazi = wrote: >=20 > [ DNSOP to BCC to limit cross-posting ] >=20 > Speaking as an individual contributor, I have read the draft and = support adoption in DNSSD. >=20 > David >=20 > On Wed, Aug 18, 2021 at 9:31 AM Chris Box > wrote: > WG members, >=20 > This email starts a call to adopt = https://datatracker.ietf.org/doc/html/draft-sekar-dns-ul-03 = into the = DNSSD working group. >=20 > What is this? Abstract: > This document proposes a new EDNS0 option that can be used by DNS > Update clients and DNS servers to include a lease lifetime in a DNS > Update or response, allowing a server to garbage collect stale > resource records that have been added by DNS Updates >=20 > Adoption means that formal change control passes from the authors to = the working group. All subsequent substantive changes require WG rough = consensus. Adoption represents a commitment that the DNSSD WG will spend = time on the draft, with the aim of progressing it towards publication. > =20 > Note that in theory the draft could fit the charters of both DNSOP and = DNSSD, but we're proposing DNSSD as this specific functionality is = required as part of draft-ietf-dnssd-srp = which is = already well advanced. The relevant charter text is: >=20 > 2. To develop an improved, scalable solution for service discovery=20 > that can operate in multi-link networks, where devices may be > in neighboring or non-neighboring links, applicable to > the scenarios above. The solution will consider tradeoffs between > reusing/extending existing protocols and developing entirely new > protocols.=20 > =20 > This email is being copied to DNSOP to solicit additional feedback = from the expertise there, but note this is NOT a call to adopt into = DNSOP. >=20 > You should be aware this draft is covered by an IPR disclosure. = Details of Apple's licensing terms can be found at = https://datatracker.ietf.org/ipr/1236/ = . > =20 > Within DNSSD we are asking two questions: > 1) If you have read this six-page draft and are content with it, or = would like to amend/discuss it further inside the working group, please = speak up now. > 2) If you believe that this document is not something the DNSSD = working group should be working on, please also say so. >=20 > For this call to succeed, we'll need statements of explicit support = from people who have read the draft. The document does not have to be = perfect, but it needs to be solving a problem the WG wants to solve in a = way approximately as described in the draft. >=20 > Please send statements in support or against, as responses to this = email. This call will be open until 2021-09-03 23:59 UTC. > =20 > Thanks, > Chris >=20 > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd = > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd --Apple-Mail=_421BB511-CC8A-4ED2-8F3B-B80882E8DD77 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I = have read the document and I would like to support its adoption. This = contribution is key to the success to application protocols running on = Thread such as Matter.

Thanks,
Manuel


On Aug 18, 2021, at 9:54 AM, = David Schinazi <dschinazi.ietf@gmail.com> wrote:

[ DNSOP to BCC to limit cross-posting = ]

Speaking as an individual = contributor, I have read the draft and support adoption in DNSSD.

David

On Wed, Aug 18, 2021 at 9:31 AM Chris Box <chris.box.ietf@gmail.com> wrote:
WG members,

This email starts a call to adopt https://datatracker.ietf.org/doc/html/draft-sekar-dns-ul-03= into the DNSSD working group.

What is this? Abstract:
   This = document proposes a new EDNS0 option that can be used by = DNS
 =  Update clients and DNS servers to include a lease lifetime in a = DNS
 =  Update or response, allowing a server to garbage collect = stale
   resource records that have been added by DNS = Updates

Adoption means that formal change control passes from the = authors to the working group. All subsequent substantive changes require = WG rough consensus. Adoption represents a commitment that the DNSSD WG = will spend time on the draft, with the aim of progressing it towards = publication.
   
Note = that in theory the draft could fit the charters of both DNSOP and DNSSD, = but we're proposing DNSSD as this specific functionality is required as = part of draft-ietf-dnssd-srp which is = already well advanced. The relevant charter text is:

2. To develop an improved, scalable solution for service = discovery 
   that can operate in multi-link networks, where = devices may be
   in neighboring or non-neighboring links, = applicable to
   the scenarios above.  The solution will = consider tradeoffs between
   reusing/extending existing = protocols and developing entirely new
  =  protocols. 
  =  
This email is being copied to DNSOP to = solicit additional feedback from the expertise there, but note this is = NOT a call to adopt into DNSOP.

You should be aware this draft is = covered by an IPR disclosure. Details of Apple's licensing terms can be = found at https://datatracker.ietf.org/ipr/1236/.
   
Within DNSSD we are asking = two questions:
1) If you have read this six-page = draft and are content with it, or would like to amend/discuss it further = inside the working group, please speak up now.
2) = If you believe that this document is not something the DNSSD working = group should be working on, please also say so.

For this call to = succeed, we'll need statements of explicit support from people who have = read the draft. The document does not have to be perfect, but it needs = to be solving a problem the WG wants to solve in a way approximately as = described in the draft.

Please send statements in support or against, as responses to = this email. This call will be open until 2021-09-03 23:59 UTC.
 
Thanks,
Chris

_______________________________________________
dnssd mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/listinfo/dnssd
_______________________________________________
dnssd = mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/listinfo/dnssd

= --Apple-Mail=_421BB511-CC8A-4ED2-8F3B-B80882E8DD77-- From nobody Thu Aug 19 02:31:51 2021 Return-Path: X-Original-To: dnssd@ietf.org Delivered-To: dnssd@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CAD73A0865; Thu, 19 Aug 2021 02:31:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 7.36.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <162936550953.8926.4748821430083495114@ietfa.amsl.com> Date: Thu, 19 Aug 2021 02:31:49 -0700 Archived-At: Subject: [dnssd] The DNSSD WG has placed draft-sekar-dns-ul in state "Call For Adoption By WG Issued" X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2021 09:31:50 -0000 The DNSSD WG has placed draft-sekar-dns-ul in state Call For Adoption By WG Issued (entered by Chris Box) The document is available at https://datatracker.ietf.org/doc/draft-sekar-dns-ul/ From nobody Thu Aug 19 04:04:59 2021 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B27863A0A09 for ; Thu, 19 Aug 2021 04:04:56 -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, 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.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=iotconsultancy.nl 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 fBCCiujgSaO1 for ; Thu, 19 Aug 2021 04:04:50 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-eopbgr140139.outbound.protection.outlook.com [40.107.14.139]) (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 B57A83A0A03 for ; Thu, 19 Aug 2021 04:04:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RINWWSDHROTbr2qmHqRarx8qYiNSaMDHDmYQPGEpVc2bqBD/Kg44ui5eGUcgS7QI+riic1nD4P5TBO1S+xpmn+w3n5Lm3bphZt8hVZsCVqq93AI/UsLqaPt8ladAVe/Hg9SWACbhtWsLs0CKClA1WXSrfgkqLkVRQNOAO76TilidxUwff+CluXKTxCusboukW2Pj2bwcI7OS9ZCjxV68Fat3y4frouU/PZFUVO8YtTQVEewlQlGsGPYZupVs0r9FGpAAl94+9ZV9KivPS53mYi+UIyntmfmgwbPObGIvCPWufQ9Dcc2lDo7xKrmSCycasADBygv7jZ0YhNsUKz7S6Q== 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=zzftw/UL23QHa1LGV3ywkn0ohPj+UHD60olGSqhKD6U=; b=lMdHba5m5FPJ3N1bJRvcmVL7jE7xQfKqZtVdOFxUTXN/ojU5qJDTITphBAq3pqwOH87MzscnvtIfxBOH9bhYsGp/mSkSsDF2R+rvZ+xTfJjqL4GNrogBuBdMnaYiQve2uxqEr0JBlq2BBKiLbkAMAfql/tB32VO2XR5eeusiVrORBMDetPRd/n+3JqvG4XJRsAgjqMfW2j+PoE9gm6FJxl+VeLSH+4fbDNuGvkVECKQW5oOzunk9kpWak/oLB5bkYIR8RtIoJ18DQA5ZAI5k+m8TIQmLBx/1KRR6Kx8d0am36uPknFxF1SEGrTFYnE2ELxLenlM2JhAUcM4M8VX2Ew== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=iotconsultancy.nl; dmarc=pass action=none header.from=iotconsultancy.nl; dkim=pass header.d=iotconsultancy.nl; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iotconsultancy.nl; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zzftw/UL23QHa1LGV3ywkn0ohPj+UHD60olGSqhKD6U=; b=FT1D/HEoQ65itu9cAtDE0r3bk7G8lsE65n/ZwK7ROmzFZJ9jHpaB+VeOEQpsZsMkN5JguoJFav8SS8Y4Icq03v/lWbNWHIyW8YkIHUiPTCVbf9BjlgrDm3aLL4Tm8fq/mN/YtwuORssuvLnVS/JhbZChPuV17Wt0HAwps6VL/T0= Received: from AM8P190MB0979.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:1d3::8) by AM9P190MB1075.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:265::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4415.16; Thu, 19 Aug 2021 11:04:45 +0000 Received: from AM8P190MB0979.EURP190.PROD.OUTLOOK.COM ([fe80::44fa:5ced:a434:f7e8]) by AM8P190MB0979.EURP190.PROD.OUTLOOK.COM ([fe80::44fa:5ced:a434:f7e8%9]) with mapi id 15.20.4436.019; Thu, 19 Aug 2021 11:04:45 +0000 From: Esko Dijk To: DNSSD CC: Ted Lemon Thread-Topic: [dnssd] WGLC for draft-ietf-dnssd-srp / review Thread-Index: AdeU1hR5DMbuavatScqtDGs87zCR8g== Date: Thu, 19 Aug 2021 11:04:45 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none; ietf.org; dmarc=none action=none header.from=iotconsultancy.nl; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e0823b1a-4eed-49e7-6df5-08d963012754 x-ms-traffictypediagnostic: AM9P190MB1075: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: jIPKrMb9MZeavX2yPX3xQMburV17WUW2poZTuswSMpxqjygZsQCasexHcmKwSayVlDJ/CHg2VXIwBoYNrOMaT3Zzumv4UVqPC+HecAv9rD85KL3NQpXaFahB/YXQBZd6pL9KduZtEaVwcxDSspcEV0Y/brNIbApGGvD97UEiluUMduLkx6kWL5Jm+MRKh+BrsPn9Se+BXtv21zVp7SqHj4jtE7RkoGOpzDUryKueX4HwpjMnDNZmjldzH5IXPisRu84C8NwFZgkHHYZerpyZZcX/yzYiGOP7suiTp5BeyeboyDYnMlJswmoqxgPKr6W4LHV9j3DBueFgrN5zBwxxbzOWfi3Zaf6wm66cxxtU6ISeSsPK6D6GzeaJEogkfeG5K3hSeG1wlfQ7JuoOKM5m+DnGk43qo07tWUz+1K9u3w+RY82xnbKsOH9u4Q/HlZJ45VsrgYYkP41RlsdnqtXCHTeIoN/MiIlfQdR2IsZbKbhMl/eY16bCKDQbzrY3lBFvGE1lAt7J2ns1f2SI/ghPokH7x+zMgweYErrJAY8nxyU3AASHEjJMlctarP9UgIohMAFs3WKxOIz8Yr15vtSCAwnpVOq6DwTcCgHLoyzMyQ3YR3Y5vy4s1U91eemzYohDnxgl33G244HqcXm4XDwnNCuKcul4M408wgvRGqo783gCK4G8WoNoJsXrfu3q6WBKYEwP1lI0OCei6SL9eWvmmg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM8P190MB0979.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(376002)(346002)(136003)(366004)(39830400003)(396003)(66946007)(66476007)(4001150100001)(9686003)(76116006)(52536014)(33656002)(66556008)(55016002)(66446008)(9326002)(8936002)(186003)(8676002)(86362001)(83380400001)(6916009)(64756008)(38100700002)(122000001)(6506007)(38070700005)(53546011)(7696005)(2906002)(30864003)(71200400001)(316002)(44832011)(5660300002)(4326008)(478600001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?RjMxOC9kQnBZTmFDUEwrelp0WGc0Q1AxWklocCtTYllTRWZpRjJoekhxMjFt?= =?utf-8?B?RkNFOHhMSTRvcU1nQjdlNzQ3RTU5ZXJ1L01lMWZCUjArSnd6R1doVERhQW5s?= =?utf-8?B?OW1JRXEzTGw3UHc0dTUwSkhtUlRpR0liNlgydGtkNXVPd2lnUnB3QWJHdjVv?= =?utf-8?B?WXRtWXgyWjhkYWdnd3dqcGM0T3o3bHBHbG8xMUVZMWhjRW81cUsvZ2JNYmtJ?= =?utf-8?B?NGRNRmxqa1FTSVVtWjh6WTIxQlFOK2V4L2pMMVdPSVFnck5OYmM3SG15dFI4?= =?utf-8?B?cmJWc0t2N3Jac1JscCt6OVhSMDFsWTVzV2ZXT0FDR3R3b1pkL0xxSXVSWEZn?= =?utf-8?B?QjA3c3FzSkV5bkZnR2ZqbWdoN1pCNWxnL3plV21oWlRYc2hBc3ZSVEhzQU5S?= =?utf-8?B?bTlFSGJBdDhCbW4zVC9BMWlzaGlEV3ZrODVPaGFST3F0NWFZcWxYU3cvWGFQ?= =?utf-8?B?UEdxSnIvbXlEellINElLdHFCOVQ4aXNVbXA5VHJmZHZXMTRpcGlVLzVYTFow?= =?utf-8?B?NnRoK1F1L1F2WEYxVFI1Y0prQnQvT3VmZU83Q2IwcHRrZ3duUnl6ZTNVNHAy?= =?utf-8?B?a1BPKzFEV0FoVHhTcGJJRENNY0dFK2t2VTRDL0JqNzQzRDBGbjJsenA4V0pa?= =?utf-8?B?VWJyOHRDQ2RVZURqYjZkeThCR2lWMXVVVG9sWDdjRmdjWkFVODAreUxtNHQ5?= =?utf-8?B?TUFML2dsS2R1MGt5ZXVIclZnaXF2cDc0cXJ2WnZNL2cveU5BV3lmQWExaUoz?= =?utf-8?B?c0lBWkEwQk1pSlpzVm9XZFZ5ZXJPTzYrKzdzUnVGV2x5dEd6SXNDdlA3Mk1y?= =?utf-8?B?SW9WZ0VGN2ZiSWcydzRlUUJjR2xxTzFleG1WeEJjVHRFb1hYd0x2YXRoUlBU?= =?utf-8?B?c3RNR0wxSWNmcjZKaFA4NW5FWnlNTHFCSG1IM2ZhbkQwamlJRVliZXh5NFhy?= =?utf-8?B?MS9oaFh6TlVldlc1Vmk3b2lGZGdxQXprY1RXL05sZ2lnajFQVTFJOFZOMnFE?= =?utf-8?B?RkhhMW14N1piWkk2K0Rmc09xRUhrM0k3djIxUEcwaXdSb1ZtM2x0dUZiNjYz?= =?utf-8?B?TVFnV1NvYTRDbjE0RXdhK2RyL2ZwM3ZDOXVxeE4vZHRmdmZ0RjI0cC9DMDM1?= =?utf-8?B?czNoQ3JWYmlpTU9oMXo0a3hrbVdlMzMrQ0JKdHJVcHJMaDVha0FoeGlhOGhm?= =?utf-8?B?YVRIOGFSa1l0Uzg5emo0T3N5U3c1cGo0Z09yTFBmTFh0cUZxWThnMzJub1l5?= =?utf-8?B?dy9XNlVoR2xRR2R5dkRQeE9HTytVb2c5TmxMbkdpbm9LU0pNUndPQW5zT1RM?= =?utf-8?B?SHQ2a040T2xCRUhGbWhNQ3pTL2RsL0hhVERVaDBBalhwQzB0SnVydVRTdytk?= =?utf-8?B?cmVZaDJ1OVFLbEsrUGE0N1E5R01meW1yaWdCZHVQNExHek54NE5FMGszdlpx?= =?utf-8?B?Sk5mbXl0SUF0RGk1d2cvK1c5b1FEbU5JaUoxZ2htUitqN2psUkhOSzY2azJK?= =?utf-8?B?Zm1MNVBaNFM2bWFlNWliRE5qVUxnZmhTZmd2ZTY5K0xVa09yYm5JcjNNNk9v?= =?utf-8?B?TVJJUjlwWDcvNmovbk9FN2cxbmpKYnpxOUhnREFZanNva053T0pxbmtrdmd4?= =?utf-8?B?dCszYzdvQTJoWm9CaDRPTEJxT1Vib2lZUys4QlBBVFc3Y2FXNWswSFNwVDdI?= =?utf-8?B?TGpJTVZISG5lYjJkYVdqeFhHbFVRcHJGdW1QbGpocUIzY1I4TGVISjIzcDIv?= =?utf-8?B?WldzZW5qemEwS0NqcUlFOWJMc1FTWTVEKzNSbU5QNWFVVmRrVWlwS0hkZW1W?= =?utf-8?Q?1D25WOptMlfE6AO0LuYsxSjv5VF7BdYk1tW7I=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_AM8P190MB0979F1E05706056DC1B950E5FDC09AM8P190MB0979EURP_" MIME-Version: 1.0 X-OriginatorOrg: iotconsultancy.nl X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM8P190MB0979.EURP190.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: e0823b1a-4eed-49e7-6df5-08d963012754 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Aug 2021 11:04:45.4761 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 58bbf628-15d2-46bc-820b-863b6774d44b X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: C7mE22waEuxvXOVwMVJ9zd5ri+8xBTRZcbLr94plNcUPe0ATOIiBqxpmDUF8rARZfvhcDv6W36FhE3xSfoT6TR1xKDEM+FIH9VxErqVIT58= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9P190MB1075 Archived-At: Subject: Re: [dnssd] WGLC for draft-ietf-dnssd-srp / review X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2021 11:04:57 -0000 --_000_AM8P190MB0979F1E05706056DC1B950E5FDC09AM8P190MB0979EURP_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8sDQoNCkhlcmUgbXkgcmVzcG9uc2UgdG8gdGhlIFdHTEMgZm9yIGRyYWZ0LWlldGYtZG5z c2Qtc3JwIGFjY29tcGFuaWVkIGJ5IHJldmlldyBjb21tZW50cyBmb3IgdGhlIGRyYWZ0Lg0KSW4g c3VtbWFyeSwgSSBiZWxpZXZlIHRoZSBkb2N1bWVudCBhcGFydCBmcm9tIFNlY3Rpb24gNSBpcyBy ZWFkeSB0byBiZSBwdWJsaXNoZWQgYWZ0ZXIgdGhlIHJldmlldyBjb21tZW50cyBhcmUgYWRkcmVz c2VkOiBhcyB0aGVzZSBjb21tZW50cyBhcmUgbW9zdGx5IG9uIGVkaXRvcmlhbCBpc3N1ZXMsIHRl eHQgbG9jYXRpb24gYW5kIHJlc29sdmluZyBwb3RlbnRpYWwgdW5jbGFyaXRpZXMuIFRoZSBTUlAg cHJvdG9jb2wgb3ZlcmFsbCBsb29rcyB1c2VmdWwsIHNvbGlkIGFuZCB3ZWxsLWRlc2NyaWJlZC4N Cg0KVGhlIHNwZWNpZmljIHBhcnQgb2YgU2VjdGlvbiA1IG9uIFNsZWVwIFByb3h5IGhhcyBoYWQg bGVzcyB3b3JrIGl0IHNlZW1zLCBhcyBhIGZldyBvZiBteSBvcmlnaW5hbCAtMDQgcmV2aWV3IGNv bW1lbnRzIGFyZSBzdGlsbCBvcGVuIGFuZCBJIGRvbuKAmXQgc2VlIGhvdyB0aGlzIGZ1bmN0aW9u IGNvdWxkIGxlYWQgdG8gaW50ZXJvcGVyYWJsZSBpbXBsZW1lbnRhdGlvbnMuIFRvIHJlc29sdmUg dGhpcywgcG9zc2libGUgYWN0aW9ucyBhcmU6DQoNCiAgMS4gIE1vdmUgdGhlIFNsZWVwIFByb3h5 IGRlZmluaXRpb24vZGV0YWlscyBvdXQgb2YgdGhpcyBkcmFmdCwgaW50byBhIHNlcGFyYXRlIG9u ZS4gVGhpcyBjb3VsZCBwcm9ncmVzcyBTUlAgaW4gdGhlIGJlc3Qgd2F5Lg0KICAyLiAgQWRkIG1v cmUgZGV0YWlscyBvbiB0aGUgU2xlZXAgUHJveHksIHRvIGEgZnVsbHkgaW50ZXJvcGVyYWJsZSBp bXBsZW1lbnRhdGlvbiBiZWNvbWVzIHBvc3NpYmxlLg0KICAzLiAgS2VlcCBjdXJyZW50IFNlY3Rp b24gNSB0ZXh0IChvbmx5IG1pbm9yIGFkZGl0aW9ucy9jaGFuZ2VzL2ZpeGVzKSwgYW5kIGFkZCBh IHNlbnRlbmNlIHNheWluZyB0aGF0IG1vcmUgZGV0YWlscyBjYW4gYmUgZGVmaW5lZCBpbiBhIGZ1 dHVyZSBkb2N1bWVudCAoZS5nLiBhZnRlciBpbXBsZW1lbnRhdGlvbnMgaGF2ZSBiZWVuIHRlc3Rl ZCDigJMgY2xpZW50cyB2cyBzZXJ2ZXJzIG9mIGRpZmZlcmVudCBwYXJ0aWVzKQ0KUmVsYXRlZCBx dWVzdGlvbjogYXJlIGFueSBpbXBsZW1lbnRhdGlvbnMgdXNpbmcgU2xlZXAgUHJveHk/DQoNCkJl c3QgcmVnYXJkcw0KRXNrbw0KDQpEZXRhaWxlZCByZXZpZXcgY29tbWVudHMgbGlzdDoNCg0KKioq IEFic3RyYWN0DQo4MDIuMTEgKFdpLUZpKSBhbmQgODAyLjE1LjQgKElvVCkgbmV0d29ya3MNCi0+ IGFkZCAnSUVFRScgc28gIklFRUUgODAyLjExIChXaS1GaSkgYW5kIDgwMi4xNS40IChJb1QpIG5l dHdvcmtzIg0KQXMgYW4gZWRpdG9yaWFsIGNvbW1lbnQsIGluIGdlbmVyYWwgdGhlIGFic3RyYWN0 IHNob3VsZCBub3QgY29udGFpbiBtb3JlIGRldGFpbHMgdGhhbiB0aGUgbWFpbiB0ZXh0Lg0KU28g dHlwaWNhbGx5IG9uZSB3b3VsZCBzZWUgYmFjayB0aGVzZSB0ZXJtcyBhZ2FpbiBpbiBhbiBpbnRy b2R1Y3Rpb24uDQoNCioqKiAyLjIuMQ0KIlJGQyA2NzYzIGRlc2NyaWJlcyB0aGUgZGV0YWlscyBv ZiB3aGF0IGVhY2ggb2YgdGhlc2UgdHlwZXMgb2YgdXBkYXRlcyBjb250YWlucyINCi0+IG5vdCBl dmVyeXRoaW5nIGNvbnRhaW5lZCBpbiB0aGVzZSB1cGRhdGVzIGlzIGV4cGxhaW5lZCBpbiBSRkMg Njc2My4gU3BlY2lmaWNhbGx5LCB0aGUgIktleSBSUiIgaXMgbm90IGluIHRoYXQgUkZDLiBBbm90 aGVyIFJGQyByZWYgY2FuIGJlIGFkZGVkIGhlcmUgdGhhdCBkZWZpbmVzIEtleSBSUiBhcyBkZWZp bml0aXZlIHNvdXJjZSBvZiBpbmZvcm1hdGlvbi4NCg0KKioqIDIuMi4zLjENCiJTUlAgY2xpZW50 cyBhcmUgYWxsb3dlZCB0byBzZW5kIHVwZGF0ZXMgdG8gdGhlIGdlbmVyaWMgZG9tYWluICJkZWZh dWx0LnNlcnZpY2UuYXJwYSIiDQotPiBJbiBzZWN0aW9uIDIuMS4qIGl0IGxvb2tzIGFzIGlmIG9u bHkgY29uc3RyYWluZWQgaG9zdHMgY2FuIGRvIHRoaXMuIENhbiBmdWxsLWZlYXR1cmVkIGhvc3Rz IGFsc28gZG8gdGhpcz8gSWYgbm90IHdlIGNhbiBzYXkgIkNvbnN0cmFpbmVkLU5vZGUgU1JQIGNs aWVudHMgYXJlIC4uLiIgICBJZiB5ZXMsIHRoZW4gSSB3b3VsZCBleHBlY3Qgc2VjdGlvbiAyLjEu MSB0byBtZW50aW9uIHRoaXMgdXNlIGZvciB0aGUgZnVsbC1mZWF0dXJlZCBob3N0cy4NCg0KKioq IDIuMi41LjENCmR1cGxpY2F0ZWQgc2VudGVuY2UgIlRoaXMga2V5IHBhaXIgTVVTVCBiZSB1bmlx dWUgdG8gdGhlIGRldmljZS4iDQoNCioqKiAyLjIuNS40DQpEb2VzIHRoZSBzdGF0ZW1lbnQgaGVy ZSBpbXBseSB0aGF0IHRoaXMgZHJhZnQgZm9ybWFsbHkgdXBkYXRlcyBSRkMgMjc4Mj8NCihRdWVz dGlvbiB0byB0aGUgV0cuIE1heWJlIG5vdDogc2luY2UgdGhlIHVwZGF0ZSBvbmx5IGFwcGxpZXMg aW4gU1JQIGNvbnRleHQgbm90IGZvciBTUlYgcmVjb3JkcyBpbiBnZW5lcmFsLiBCdXQgbWF5YmUg eWVzOiBSRkMgMjc4MiBzYXlzICJVbmxlc3MgYW5kIHVudGlsIHBlcm1pdHRlZCBieSBmdXR1cmUg c3RhbmRhcmRzIGFjdGlvbiwgbmFtZSBjb21wcmVzc2lvbiBpcyBub3QgdG8gYmUgdXNlZCBmb3Ig dGhpcyBmaWVsZC4iIHdoaWNoIHdvdWxkIG1ha2UgaXQgcHJvcGVyIHRvIHJlZmVyIHRvIHRoZSBT UlAgZHJhZnQgYXMgc3VjaCBmdXR1cmUgYWN0aW9uLikNCg0KKioqIDIuMi41LjUuMg0KInVwZGF0 ZSB0aGF0IGRlbGV0ZXMgdGhlIFBUUiByZWNvcmQgd2hvc2UgdGFyZ2V0IGlzIHRoZSBzZXJ2aWNl IGluc3RhbmNlIG5hbWUuIg0KLT4gVGhpcyBsb29rcyBsaWtlIGEgc2luZ2xlIFBUUiByZWNvcmQu IFByaW9yIHNlY3Rpb24gMi4yLjEgbWVudGlvbnMgdGhhdCB0aGUgc2VydmljZSBpbnN0YW5jZSBu YW1lIG1heSBiZSByZWZlcnJlZCB0byBieSBtdWx0aXBsZSBQVFIgcmVjb3Jkcy4gIFNvIGluIGNh c2Ugb2YgbXVsdGlwbGUsIGl0IGlzIG5vdCByZXF1aXJlZCB0byBoYXZlIG11bHRpcGxlIGluc3Ry dWN0aW9ucyB0byBkZWxldGUgdGhlc2UgbXVsdGlwbGUgUFRSIHJlY29yZHM/DQooSS5lLiB0aGVy ZSdzIG5vIHJpc2sgb2YgbGluZ2VyaW5nIFBUUiByZWNvcmRzIHRoYXQgd291bGQgcG9pbnQgdG8g YSBzZXJ2aWNlIGluc3RhbmNlIHRoYXQncyBkZWxldGVkPykNCg0KKioqIDIuMyB0aXRsZQ0KW05p dF0gLT4gbWF5IGdpdmUgdGhlIGltcHJlc3Npb24gdGhhdCBhbGwgU1JQIHNlcnZlciBiZWhhdmlv ciBpcyBzcGVjaWZpZWQgaW4gaGVyZS4NClNvbWV3aGVyZSBpbiAyLjMgLyAyLjMuKiBpdCBjb3Vs ZCBtZW50aW9uIHRoYXQgbW9yZSBub3JtYXRpdmUgYmVoYXZpb3IgaXMgc3BlY2lmaWVkIGluIG90 aGVyIHNlY3Rpb25zIHRvbywgbGlrZSBTZWN0aW9ucyAzIGFuZCA0Lg0KDQoqKiogMi4zLjENCkdy YW1tYXIgdG8gYmUgZml4ZWQ6ICJFYWNoIGluc3RydWN0aW9uIGNvbnNpc3RzIHNvbWUgY29tYmlu YXRpb24iDQoNCioqKiAyLjMuMS4xDQoiaWYgdGhlIFNlcnZpY2UgRGlzY292ZXJ5IHVwZGF0ZSBp cyBhbiAiQWRkIHRvIGFuIFJSU2V0IiBpbnN0cnVjdGlvbiwgdGhlIFNlcnZpY2UgRGVzY3JpcHRp b24gSW5zdHJ1Y3Rpb24gZG9lcyBub3QgbWF0Y2ggaWYiDQotPiBmb3IgbWUgdW5jbGVhciwgc2Vl IHNlcGFyYXRlIG1haWwgdGhyZWFkIG9uIHRoaXMgc2VjdGlvbi4NCg0KKioqIDIuMy4xLjINCltO aXRdIEJ1bGxldDoNCiIqICBTZXJ2aWNlIERlc2NyaXB0aW9ucyBJbnN0cnVjdGlvbnMgZG8gbm90 IG1vZGlmeSBhbnkgb3RoZXIgUlJzLiINCi0+IGJlc3QgcmVwaHJhc2VkIHRvDQogIiogIG5vIFJS IHVwZGF0ZXMgb3RoZXIgdGhhbiB0aGUgb25lcyBkZWZpbmVkIGFib3ZlLiINCg0KVGhhdCB3b3Vs ZCBmaXQgYmV0dGVyIGluIHRoZSBzdHlsZSBvZiB0aGUgcHJldmlvdXMgYnVsbGV0IHBvaW50cyBp biB0aGUgbGlzdC4NCg0KKioqIDIuMy4xLjMNCiJJZiBhIGxpbmstc2NvcGUgYWRkcmVzcyBvciBJ UHY0IGF1dG9jb25maWd1cmF0aW9uIGFkZHJlc3MgaXMgcHJvdmlkZWQgYnkgdGhlIFNSUCBjbGll bnQsIHRoZQ0KICBTUlAgc2VydmVyIE1VU1QgdHJlYXQgdGhpcyBhcyBpZiBubyBhZGRyZXNzIHJl Y29yZHMgd2VyZSByZWNlaXZlZDsgdGhhdCBpcywgdGhlIEhvc3QgRGVzY3JpcHRpb24gaXMgbm90 IHZhbGlkLiINCi0+IFRoaXMgc2VlbXMgcmF0aGVyIHN0cmljdC4gSWYgdGhlIGNsaWVudCBwcm92 aWRlcyAxIHJvdXRhYmxlIElQIGFkZHJlc3MgYW5kIDEgbGluay1sb2NhbCBhZGRyZXNzLCBjb3Vs ZG4ndCB0aGUgU1JQIHNlcnZlciBqdXN0IGlnbm9yZSB0aGUgbGluay1sb2NhbCBhZGRyZXNzPw0K VGhpcyBtaWdodCBoYXZlIHNvbWUgYmVuZWZpdHMgZm9yIGZ1dHVyZS9iYWNrd2FyZHMgY29tcGF0 aWJpbGl0eSAsIGluIGNhc2Ugb2YgZnV0dXJlIGNhc2VzIHdoZXJlIGxpbmstbG9jYWwgYWRkcmVz c2VzIGFyZSB0byBiZSB1c2VkIGZvciBzb21lIHJlYXNvbi4gKElmIG9ubHkgZm9yIGRlYnVnL2Rp YWdub3N0aWMgcHVycG9zZXMpDQpJIGFncmVlIHRoYXQgaWYgdGhlIGNsaWVudCBzZW5kcyBvbmx5 IGxpbmstbG9jYWwgYWRkcmVzcyhlcykgdGhlbiB0aGUgU1JQIHNlcnZlciB0cmVhdHMgaXQgYXMg aWYgbm8gYWRkcmVzcyByZWNvcmRzIHdlcmUgcmVjZWl2ZWQuDQoNCioqKiAyLjMuMg0KW05pdF0g Im11c3QgaGF2ZSB0aGF0IEhvc3QgRGVzY3JpcHRpb24gaW5zdHJ1Y3Rpb24gYXMgdGhlIHRhcmdl dCBvZiBpdHMgU1JWIHJlY29yZCINCi0+IGNvdWxkIHJlcGhyYXNlIHRvICJNVVNUIGhhdmUgdGhl IGhvc3RuYW1lIG9mIHRoYXQgSG9zdCBEZXNjcmlwdGlvbiBJbnN0cnVjdGlvbiBhcyB0aGUgdGFy Z2V0IG9mIGl0cyBTUlYgcmVjb3JkIiAgdG8gYmUgbW9yZSBwcmVjaXNlLg0KU2ltaWxhciBjb21t ZW50cyBjYW4gYmUgZ2l2ZW4gZm9yIHRoZSByZW1haW5kZXIgb2YgdGhlIHNlY3Rpb24gdGV4dCB0 aGF0IHRhbGtzIGFib3V0IGluc3RydWN0aW9ucyBwb2ludGluZyB0byBpbnN0cnVjdGlvbnMuICAo SXQncyBtb3JlIGxpa2UgbmFtZXMgaW4gaW5zdHJ1Y3Rpb25zIGJlaW5nIGVxdWFsIHRvIG5hbWVz IHRoYXQgYXJlIHVzZWQgaW4gb3RoZXIgaW5zdHJ1Y3Rpb25zKQ0KKG5vdCBzdXJlIGlmIE1VU1Qg b3IgbXVzdCBpcyBkZXNpcmVkIGhlcmUgYnkgdGhlIHdheSkNCg0KIkZvciBleGFtcGxlLCBhIERO UyB1cGRhdGUgdGhhdCBjb250YWlucyBhbiBSUnNldA0KICAgQWRkIHRvIGEgU2VydmljZSBOYW1l IGFuZCBhbiBSUnNldCBBZGQgdG8gYSBTZXJ2aWNlIEluc3RhbmNlIE5hbWUsDQogICB3aGVyZSB0 aGUgU2VydmljZSBOYW1lIGRvZXMgbm90IHJlZmVyZW5jZSB0aGUgU2VydmljZSBJbnN0YW5jZSBO YW1lLA0KICAgaXMgbm90IGEgdmFsaWQgU1JQIHVwZGF0ZSBtZXNzYWdlIg0KLT4gJ1JSc2V0IEFk ZCcgcmVmZXJzIHByb2JhYmx5IHRvIHRoZSAiQWRkIFRvIEFuIFJSc2V0IiBzZW1hbnRpY3Mgb2Yg UkZDIDIxMzY/IElmIHNvIGl0IHdvdWxkIGJlIGdvb2QgdG8gdXNlIHRoYXQgZXhhY3Qgc2FtZSBu YW1pbmcgIkFkZCBUbyBBbiBSUnNldCIgaW5jbHVkaW5nIHRoZSBxdW90ZXMgaGVyZS4NCldpdGgg cHJlc2VudCB0ZXh0IEknbSB3b25kZXJpbmcgaWYgSSBtaXNzZWQgc29tZXRoaW5nIGluIHRoZSBE TlMgc3BlY3MgdGhhdCdzIGNhbGxlZCAiUlJzZXQgQWRkIi4NCg0KKioqIDIuMy4zDQoiSWYgYW55 IGV4aXN0aW5nIEtFWSByZWNvcmQgY29ycmVzcG9uZGluZyB0byBhDQogICBLRVkgcmVjb3JkIGlu IHRoZSBTUlAgVXBkYXRlIGRvZXMgbm90IG1hdGNoIHRoZSBLRVkgc2FtZSByZWNvcmQgaW4NCiAg IHRoZSBTUlAgVXBkYXRlICINCi0+IGdyYW1tYXIgaXNzdWUuICdtYXRjaCB0aGUgS0VZIHNhbWUg cmVjb3JkJyAgICBBbmQgYSBiaXQgY29uZnVzaW5nOiBjYW4gYSBLRVkgcmVjb3JkIGluIGFuIHVw ZGF0ZSBjb3JyZXNwb25kIHRvIGEgc3RvcmVkIEtFWSByZWNvcmQgYnV0IG5vdCBtYXRjaCBhdCB0 aGUgc2FtZSB0aW1lPw0KICBQZXJoYXBzIHRoZSAnbmFtZScgY29uY2VwdCBzaG91bGQgYmUgaW50 cm9kdWNlZCBoZXJlIHRvIGNsYXJpZnkuIChQcmVzdW1hYmx5IHRoZSBzZXJ2ZXIgd2lsbCBjaGVj ayBpZiBhbiBleGlzdGluZyBTZXJ2aWNlIEluc3RhbmNlIE5hbWUgb3IgZXhpc3RpbmcgSG9zdG5h bWUgaXMgc3RvcmVkIGFuZCBsb29rIHVwIHRoZSBhc3NvY2lhdGVkIEtFWSBmb3IgdGhhdC4pDQoN CiJLRVkgcmVjb3JkIHVwZGF0ZXMgb21pdHRlZCBmcm9tIFNlcnZpY2UgRGVzY3JpcHRpb24gdXBk YXRlIGFyZQ0KICAgcHJvY2Vzc2VkIGFzIGlmIHRoZXkgaGFkIGJlZW4gZXhwbGljaXRseSBwcmVz ZW50OiBldmVyeSBTZXJ2aWNlDQogICBEZXNjcmlwdGlvbiB0aGF0IGlzIHVwZGF0ZWQgTVVTVCwg YWZ0ZXIgdGhlIHVwZGF0ZSwgaGF2ZSBhIEtFWSBSUiwNCiAgIGFuZCBpdCBtdXN0IGJlIHRoZSBz YW1lIEtFWSBSUiB0aGF0IGlzIHByZXNlbnQgaW4gdGhlIEhvc3QNCiAgIERlc2NyaXB0aW9uIHRv IHdoaWNoIHRoZSBTZXJ2aWNlIERlc2NyaXB0aW9uIHJlZmVycy4iDQotPiBDYW4gd2UgcmVwbGFj ZSBoZXJlICdTZXJ2aWNlIERlc2NyaXB0aW9uIHVwZGF0ZScgYnkgJ1NlcnZpY2UgRGVzY3JpcHRp b24gSW5zdHJ1Y3Rpb24nID8NCkUuZy4NCiJLRVkgcmVjb3JkIHVwZGF0ZXMgb21pdHRlZCBmcm9t IFNlcnZpY2UgRGVzY3JpcHRpb24gSW5zdHJ1Y3Rpb25zIGFyZQ0KICAgcHJvY2Vzc2VkIGFzIGlm IHRoZXkgaGFkIGJlZW4gZXhwbGljaXRseSBwcmVzZW50OiBldmVyeSBTZXJ2aWNlDQogICBEZXNj cmlwdGlvbiB0aGF0IGlzIHVwZGF0ZWQgdGhyb3VnaCBhIFNlcnZpY2UgRGVzY3JpcHRpb24gSW5z dHJ1Y3Rpb24gTVVTVCwgYWZ0ZXIgdGhlIHVwZGF0ZSwgaGF2ZSBhIEtFWSBSUiwNCiAgIGFuZCBp dCBtdXN0IGJlIHRoZSBzYW1lIEtFWSBSUiB0aGF0IGlzIHByZXNlbnQgaW4gdGhlIEhvc3QNCiAg IERlc2NyaXB0aW9uIEluc3RydWN0aW9uIHRvIHdoaWNoIHRoZSBTZXJ2aWNlIERlc2NyaXB0aW9u IEluc3RydWN0aW9uIHJlZmVycy4iDQoNCiJPdGhlcndpc2UsIHRoZSBzZXJ2ZXIgdmFsaWRhdGVz IHRoZSBTUlAgVXBkYXRlIHVzaW5nIFNJRygwKSBvbiB0aGUNCiAgIHB1YmxpYyBrZXkgaW4gdGhl IEtFWSByZWNvcmQgb2YgdGhlIEhvc3QgRGVzY3JpcHRpb24gdXBkYXRlLiINCi0+IHdoYXQgYWJv dXQ6DQoiT3RoZXJ3aXNlLCB0aGUgc2VydmVyIHZhbGlkYXRlcyB0aGUgU1JQIFVwZGF0ZSB1c2lu ZyBTSUcoMCkgYWdhaW5zdCB0aGUNCiAgIHB1YmxpYyBrZXkgaW4gdGhlIEtFWSByZWNvcmQgb2Yg dGhlIEhvc3QgRGVzY3JpcHRpb24gSW5zdHJ1Y3Rpb24uIg0KDQooVXNpbmcgJ0luc3RydWN0aW9u JyBhbmQgJ3ZhbGlkYXRlcyBYIGFnYWluc3QgWScgaW5zdGVhZCBvZiAndmFsaWRhdGlvbnMgWCBv biBZJyApDQoNCioqKiAzDQoiU1JQIHVwZGF0ZSBzZXJ2ZXJzIE1VU1QgY2hlY2siDQotPiJTUlAg c2VydmVycyBNVVNUIGNoZWNrIg0KDQoqKiogNC4xDQpbTml0XSAiIE1VU1QgYmUgcmVtb3ZlZCBh dCB0aGUgc2FtZSB0aW1lLWl0IGlzIG5ldmVyIHZhbGlkIGZvciBhIHNlcnZpY2UiDQotPiAiIE1V U1QgYmUgcmVtb3ZlZCBhdCB0aGUgc2FtZSB0aW1lIC0tIGl0IGlzIG5ldmVyIHZhbGlkIGZvciBh IHNlcnZpY2UgIiBvcg0KLT4gIiBNVVNUIGJlIHJlbW92ZWQgYXQgdGhlIHNhbWUgdGltZTogaXQg aXMgbmV2ZXIgdmFsaWQgZm9yIGEgc2VydmljZSAiDQoNCjNyZCBwYXJhZ3JhcGggbWVudGlvbnMg dGhhdCBhIFNSUCBpcyBieSBkZWZhdWx0IGNvbmZpZ3VyZWQgd2l0aCBhIDIgaG91ciBMZWFzZSBs aW1pdCBhbmQgMTQtZGF5IEtFWSByZXRhaW5pbmcgdGltZSBsaW1pdDsgYW5kIHRoZW4gaXQgc2F5 cyB0aGF0IGNvbnN0cmFpbmVkIGRldmljZXMgbWF5IG5lZ290aWF0ZSBsb25nZXIgbGVhc2VzLiBU aGlzIGxvb2tzIGluY29ycmVjdCwgYXMgbGVhc2VzIGJleW9uZCBjb25maWd1cmVkIHVwcGVyIGxp bWl0cyB3b24ndCBiZSBnaXZlbiBieSB0aGUgc2VydmVyLg0KUHJvYmFibHkgc29tZXRoaW5nIGVs c2UgaXMgbWVhbnQgaGVyZSB3aXRoICduZWdvdGlhdGUnPyBGb3IgZXhhbXBsZSBpZiBvbmUgY29u ZmlndXJlcyAnZGVmYXVsdCB2YWx1ZXMnIGZvciBMZWFzZSBhbmQgS2V5LUxlYXNlIGluIHRoZSBz ZXJ2ZXIsIHRoZSBzZXJ2ZSBtYXkgZXh0ZW5kIHRvIHRoZXNlIGRlZmF1bHQgdmFsdWVzIGlmIHRo ZSBjbGllbnQgYXNrcyBmb3Igc29tZXRoaW5nIHNob3J0ZXIuIElmIHRoZSBjbGllbnQgYXNrcyBm b3Igc29tZXRoaW5nIGxvbmdlciB0aGFuIHRoZSAnZGVmYXVsdCB2YWx1ZXMnLCB0aGUgc2VydmVy IGdyYW50cyB0aGUgbG9uZ2VyIHZhbHVlcyB1cCB0byBhIGhhcmQgbGltaXQgdGhhdCBpcyBhbHNv IGNvbmZpZ3VyZWQgaW4gdGhlIHNlcnZlci4NCg0KKioqIDUgU2xlZXAgUHJveHkNClRoZSBpbnRy b2R1Y3Rpb24gdGV4dCBzaG91bGQgY2xhcmlmeSB3aGV0aGVyIFNsZWVwIFByb3h5IHN1cHBvcnQg Zm9yIGFuIFNSUCBzZXJ2ZXIgaXMgT1BUSU9OQUwgb3IgTUFOREFUT1JZLg0KQWxzbyB0byBtYWtl IG1vcmUgY2xlYXIgdGhhdCBmb3IgY2xpZW50cyB0aGUgdXNlIG9mIHRoaXMgZnVuY3Rpb24gaXMg b3B0aW9uYWwvT1BUSU9OQUwuIChUaGUgbGFzdCBwYXJhZ3JhcGggc2F5cyBzbyBmb3IgY29uc3Ry YWluZWQgaG9zdHMsIGJ1dCBub3RoaW5nIGZvciB0aGUgZnVsbC1mZWF0dXJlZCBob3N0cy4pDQoN CkluIHJlbGF0aW9uIHRvIGFib3ZlLCB0aGUgc2FtZSBxdWVzdGlvbnMgZnJvbSBteSByZXZpZXcg b2YgLTA0IG9mIDIwMjAtMTAtMTMgc3RpbGwgYXBwbHk6DQotIEhvdyB3b3VsZCBhIHNlcnZpY2Xi gJlzIGhvc3Qga25vdyB0aGF0IHRoZSBzZXJ2ZXIgaXMgY2FwYWJsZSB0byBkbyB0aGlzPyBJZiBp dCBkb2Vzbid0IGtub3cgdGhlbiBpdCBjYW5ub3QgdHJ1c3QgdGhlIG1lY2hhbmlzbSB0byB3b3Jr IGFuZCBnbyB0byBzbGVlcC4NCi0gT3IsIGlzIHRoZXJlIGEgd2F5IGZvciB0aGUgU1JQIHNlcnZl ciB0byByZWplY3QgYW4gdXBkYXRlIHdpdGggRUROUygwKSBPV05FUiBvcHRpb24gc3VjaCB0aGF0 IHRoZSBzZXJ2aWNl4oCZcyBob3N0IGtub3dzIG5vdCB0byB1c2UgaXQgYWdhaW4/DQoNCltOaXRd ICJBbm90aGVyIHVzZSBvZiBTUlAgaXMgZm9yIGRldmljZXMgdGhhdCBzbGVlcCB0byByZWR1Y2Ug cG93ZXIgY29uc3VtcHRpb24iDQotPiBpZGVhbGx5IGl0IHNob3VsZCBtZW50aW9uIHNvbWV3aGVy ZSB0aGF0IHRoZSBkZXZpY2UgdGhhdCBzbGVlcHMgaXMgYW4gU1JQIGNsaWVudC4gT3RoZXJ3aXNl IHRoZSBzdGF0ZW1lbnQgaXMgYSBiaXQgdG9vIGdlbmVyaWMuIEUuZy4NCiJBbm90aGVyIHVzZSBv ZiBTUlAgaXMgZm9yIFNSUCBjbGllbnQgZGV2aWNlcyB0aGF0IHNsZWVwIHRvIHJlZHVjZSBwb3dl ciBjb25zdW1wdGlvbiwgd2hpbGUgYmVpbmcgYWJsZSB0byBvZmZlciByZWdpc3RlcmVkIHNlcnZp Y2Uocykgd2l0aG91dCBpbnRlcnJ1cHRpb24uIg0KDQoidGhlIGRldmljZSBpbmNsdWRlcyBhbiBF RE5TKDApIE9XTkVSIE9wdGlvbiBbSS1ELmNoZXNoaXJlLWVkbnMwLW93bmVyLW9wdGlvbl0iDQot PiB0aGUgcmVmZXJlbmNlIGhlcmUgaXMgSW5mb3JtYXRpb25hbDsgaG93IGNhbiB0aGlzIGJlPyBU byBpbXBsZW1lbnQgdGhlIHNsZWVwIHByb3h5IGZ1bmN0aW9uIGl0IGlzIG5vcm1hdGl2ZSB0byBp bmNsdWRlIHRoZSBvcHRpb24uDQoNCiJXaGVuIHRoZSBETlMgc2VydmVyIHJlY2VpdmVzIGEgVENQ IFNZTiBvciBVRFAgcGFja2V0IGFkZHJlc3NlZCB0byINCi0+ICJXaGVuIHRoZSBTbGVlcCBQcm94 eSByZWNlaXZlcyBhIFRDUCBTWU4gb3IgVURQIHBhY2tldCBhZGRyZXNzZWQgdG8iDQooc2VlIGFs c28gYmVsb3cgY29tbWVudCkNCg0KInRoZSBTbGVlcCBQcm94eSBtdXN0IGJlIG9uIHRoZSBzYW1l IGxpbmsiDQotPiB0aGUgdGVybSAiU2xlZXAgUHJveHkiIGlzIG5vdCBpbnRyb2R1Y2VkLiBJbiB0 aGUgcHJpb3IgdGV4dCB3aGVuIGl0IHNheXMgInNob3VsZCBzZXQgdXAgYSBwcm94eSIgdGhlIG5h bWUgY291bGQgYmUgZm9ybWFsbHkgaW50cm9kdWNlZCBlLmcuICJzaG91bGQgc2V0IHVwIGEgU2xl ZXAgUHJveHkiIG9yICJzaG91bGQgc2V0IHVwIGEgcHJveHksIGNhbGxlZCB0aGUgU2xlZXAgUHJv eHksICINCg0KT3ZlcmFsbCwgSSBtaXNzIHNvbWUgZGV0YWlscyBhYm91dCB3aGF0IHRoZSBTbGVl cCBQcm94eSBkb2VzIG9uY2UgaXQgcmVjZWl2ZXMgYSBUQ1AgU1lOIG9yIFVEUCBwYWNrZXQgYW5k IGl0IGhhcyB3b2tlbiB1cCB0aGUgc2xlZXB5IGRldmljZS4gRG9lcyBpdCB0aGVuIHN0b3AgdGhl IEFSUC9ORCBwcm94eWluZyBmb3IgdGhlIHNsZWVweSBkZXZpY2UgcmlnaHQgYXdheT8gQW5kIHdo ZW4gd291bGQgaXQgYWdhaW4gcmVzdW1lIHByb3h5aW5nPw0KV2hhdCBkb2VzIHRoZSBwcm94eSBk byB3aXRoIHRoZSByZWNlaXZlIFRDUCBTWU4gb3IgVURQIHBhY2tldCwgZGlzY2FyZCBvciBmb3J3 YXJkIHRvIHRoZSB3b2tlbiBzbGVlcHkgZGV2aWNlPyAoQWZ0ZXIgaG93IG11Y2ggd2FpdGluZyB0 aW1lPykNCg0KKioqIDYuMQ0KIlNlcnZpY2UgRGlzY292ZXJ5IFByb3RvY29sIHNlcnZlcnMiDQot PiBpcyB0aGlzIHRlcm0gZGVmaW5lZD8gU2hvdWxkIHdlIHNheSBTUlAgc2VydmVycyBoZXJlPw0K DQoiYSBwcm9taXNlIG1hZGUgYnkgdGhlIHJlZ2lzdHJhdGlvbiBwcm90b2NvbCINCi0+ICJhIHBy b21pc2UgbWFkZSBieSB0aGUgc2VydmljZSByZWdpc3RyYXRpb24gcHJvdG9jb2wiDQoNCiJyZXBs YWNpbmcgYWxsIG9yIHBhcnQgb2YgdGhlIHNlcnZpY2UgcmVnaXN0cmF0aW9uIGluZm9ybWF0aW9u IHdpdGggaW5mb3JtYXRpb24gcHJvdmlkZWQgYnkgYW4gU1JQIGNsaWVudCINCi0+IHRoZSAiU1JQ IGNsaWVudCIgbWVudGlvbmVkIGhlcmUgSSB0aGluayBzaG91bGQgYmUgIkROUyBjbGllbnQiLiBC ZWNhdXNlIHRoZSBjYXNlIG1lbnRpb25lZCBsb29rZWQgbGlrZSBhbiBhdXRoZW50aWNhdGVkIChu b24tU1JQKSBETlMgY2xpZW50IG1ha2luZyBETlMgdXBkYXRlcyB0byByZWNvcmRzIHRoYXQgd2Vy ZSBhZGRlZCBieSBhbiBTUlAgY2xpZW50Lg0KDQoqKiogNyAiUHJpdmFjeSBDb25zaWRlcmF0aW9u cyINClRoaXMgdGV4dCBtZW50aW9ucyB0aGUgcmVxdWlyZW1lbnRzIGZvciBUTFMuIFBlcmhhcHMg dGhlIFRMUyBiaXRzIGFyZSBiZXR0ZXIgcGxhY2VkIGluIFNlY3Rpb24gNiwgYW5kIFNlY3Rpb24g NyBpZiBuZWVkZWQgY2FuIHJlZmVyIGJhY2sgdG8gdGhhdC4gVG8gbWUgVExTIHNlZW1zIG9uZSBv ZiB0aGUga2V5IGluZ3JlZGllbnRzIHRvIHNlY3VyZSB0aGUgcHJvdG9jb2wgc28gSSdkIGV4cGVj dCB0byByZWFkIHNvbWV0aGluZyAvIG1vc3QtdGhpbmdzIGFib3V0IHRoaXMgaW4gU2VjdGlvbiA2 LiAgIChNYXliZSBJJ20gd3JvbmcgaGVyZSBpbiBjYXNlIFRMUyBjYW4ndCBwcm92aWRlIHRoZSBh dXRoZW50aWNhdGlvbiAtIHNpbmNlIGluIHNvbWUgZGVwbG95bWVudHMgdGhlIGNsaWVudCBtYXkg aGF2ZSBubyB0cnVzdCBhbmNob3Igb2YgdGhlIGRvbWFpbiBpbnN0YWxsZWQgYSBwcmlvcmksIHNv IGl0IGNhbid0IGF1dGhlbnRpY2F0ZSB0aGUgU1JQIHNlcnZlciBldmVuIHdoZW4gVExTIGlzIHVz ZWQuKQ0KDQoqKiogOS4yDQoiQXZhaWxhYmlsaXR5IG9mIEROUyBTZXJ2aWNlIERpc2NvdmVyeSBT ZXJ2aWNlIFJlZ2lzdHJhdGlvbiBQcm90b2NvbA0KICAgU2VydmljZSBmb3IgYSBnaXZlbiBkb21h aW4gaXMgYWR2ZXJ0aXNlZCB1c2luZyB0aGUNCiAgICJfZG5zc2Qtc3JwLl90Y3AuPGRvbWFpbj4u IiAgU1JWIHJlY29yZCBnaXZlcyB0aGUgdGFyZ2V0IGhvc3QgYW5kDQogICBwb3J0IHdoZXJlIERO U1NEIFNlcnZpY2UgUmVnaXN0cmF0aW9uIFNlcnZpY2UgaXMgcHJvdmlkZWQgZm9yIHRoZQ0KICAg bmFtZWQgZG9tYWluLiINCg0KLT4gc2VlbXMgbGlrZSBhIGdyYW1tYXIgaXNzdWUgaGVyZS4gV2Fz IHRoaXMgbWVhbnQgYXMgYSBzaW5nbGUgc2VudGVuY2UsIG9yIGFzIDIgc2VudGVuY2VzIHNlcGFy YXRlZCBieSBhIGRvdCBiZWZvcmUgdGhlICJTUlYgcmVjb3JkIiB0ZXh0Pw0KRS5nLiBJIGNvdWxk IGludGVycHJldCBhcyAidXNpbmcgdGhlIFggU1JWIHJlY29yZCB3aGljaCBnaXZlcyB0aGUgWSIg b3IgYXMgInVzaW5nIHRoZSBYIG5hbWUuIFRoZSBTUlYgcmVjb3JkIGdpdmVzIHRoZSBZIi4NClNp bWlsYXIgcG9pbnQgZm9yIDkuMy4NCg0KDQoNCg0KDQpGcm9tOiBEYXZpZCBTY2hpbmF6aSA8ZHNj aGluYXppLmlldGZAZ21haWwuY29tPg0KU2VudDogTW9uZGF5LCBBdWd1c3QgMTYsIDIwMjEgMjA6 MDkNClRvOiBFc2tvIERpamsgPGVza28uZGlqa0Bpb3Rjb25zdWx0YW5jeS5ubD4NCkNjOiBETlNT RCA8ZG5zc2RAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW2Ruc3NkXSBXR0xDIGZvciBkcmFmdC1p ZXRmLWRuc3NkLXNycA0KDQpIaSBFc2tvLA0KDQpUaGF0J3MgcmVhc29uYWJsZSwgd2UgY2FuIHdh aXQgYSBmZXcgbW9yZSBkYXlzIGZvciB5b3UgdG8gcmV2aWV3Lg0KDQpEYXZpZA0KDQpPbiBTdW4s IEF1ZyAxNSwgMjAyMSBhdCAxOjM3IFBNIEVza28gRGlqayA8ZXNrby5kaWprQGlvdGNvbnN1bHRh bmN5Lm5sPG1haWx0bzplc2tvLmRpamtAaW90Y29uc3VsdGFuY3kubmw+PiB3cm90ZToNCkhlbGxv IERhdmlkLA0KDQpEdWUgdG8gaG9saWRheSBJIG1pc3NlZCB0aGlzIGxhc3QgY2FsbC4gSGF2aW5n IHJldmlld2VkIGFuIGVhcmxpZXIgdmVyc2lvbiBJIHdvdWxkIGxpa2UgdG8gY2hlY2sgaWYgdGhl IGlzc3VlcyBhcmUgc29sdmVkIG5vdzsgYW5kIGNhbiBhbnN3ZXIgdGhlIHF1ZXN0aW9uIGJ5IFR1 ZXNkYXkgb3IgV2VkbmVzZGF5IGlmIHRoYXTigJlzIG9rLiAoSW5zdGVhZCBvZiB0b2RheSkNCg0K QmVzdCByZWdhcmRzDQpFc2tvDQoNCkZyb206IGRuc3NkIDxkbnNzZC1ib3VuY2VzQGlldGYub3Jn PG1haWx0bzpkbnNzZC1ib3VuY2VzQGlldGYub3JnPj4gT24gQmVoYWxmIE9mIERhdmlkIFNjaGlu YXppDQpTZW50OiBXZWRuZXNkYXksIEp1bHkgMjgsIDIwMjEgMjM6NTcNClRvOiBETlNTRCA8ZG5z c2RAaWV0Zi5vcmc8bWFpbHRvOmRuc3NkQGlldGYub3JnPj4NClN1YmplY3Q6IFtkbnNzZF0gV0dM QyBmb3IgZHJhZnQtaWV0Zi1kbnNzZC1zcnANCg0KSGkgRE5TU0QgZW50aHVzaWFzdHMsDQoNClRo aXMgZW1haWwgc3RhcnRzIGFuIG9mZmljaWFsIFdvcmtpbmcgR3JvdXAgTGFzdCBDYWxsIGZvciBk cmFmdC1pZXRmLWRuc3NkLXNycC4gVGhpcyBjYWxsIGFza3Mgd2hldGhlciB3ZSBiZWxpZXZlIHRo ZSBkb2N1bWVudCBpcyByZWFkeSBmb3IgcHVibGljYXRpb24uIEFzIHN1Y2ggd2UgYXJlIGFza2lu ZyB0d28gcXVlc3Rpb25zOg0KDQoxKSBpZiB5b3UgYmVsaWV2ZSB0aGlzIGRvY3VtZW50IGlzIG5v dCByZWFkeSB0byBwdWJsaXNoLCBwbGVhc2Ugc3BlYWsgdXAgbm93DQoNCjIpIGlmIHlvdSBoYXZl IHJlYWQgdGhlIGRvY3VtZW50IGFuZCB0aGluayBpdCBpcyByZWFkeSwgcGxlYXNlIHNheSBzbyBh cyB3ZWxsDQoNCkZvciB0aGlzIGNhbGwgdG8gc3VjY2VlZCwgd2UnbGwgbmVlZCBzdGF0ZW1lbnRz IG9mIGV4cGxpY2l0IHN1cHBvcnQgZnJvbSBwZW9wbGUgd2hvIGhhdmUgcmVhZCB0aGUgZHJhZnQu IFBsZWFzZSBzZW5kIHN0YXRlbWVudHMgaW4gZWl0aGVyIGRpcmVjdGlvbiBhcyByZXNwb25zZXMg dG8gdGhpcyBlbWFpbC4gVGhpcyBjYWxsIHdpbGwgYmUgb3BlbiB1bnRpbCAyMDIxLTA4LTE1IDIz OjU5IFVUQy4NCg0KVGhhbmtzLA0KRGF2aWQNCg== --_000_AM8P190MB0979F1E05706056DC1B950E5FDC09AM8P190MB0979EURP_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVC My0xMWQxLUEyOUYtMDBBQTAwQzE0ODgyIiB4bWxuczptPSJodHRwOi8vc2NoZW1hcy5taWNyb3Nv ZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9S RUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250 ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBj b250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8c3R5bGU+PCEt LQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpXaW5n ZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9DQpAZm9udC1mYWNlDQoJe2Zv bnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAy IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGku TXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJZm9udC1zaXplOjExLjBw dDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNv SHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFy YWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJ bWFyZ2luLXRvcDowaW47DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsN CgltYXJnaW4tbGVmdDouNWluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29s b3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQt b25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2Vj dGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEu MGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBE ZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6NjQxMzU0MTUxOw0KCW1zby1s aXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxNTQ3OTY4MzM2IDE5MTQy MDA1NzIgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2 ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFy dC1hdDoyOw0KCW1zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDotOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh bnMtc2VyaWY7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0K QGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNv dXJpZXIgTmV3IixzZXJpZjt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciLHNlcmlm O30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1p bHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyIsc2VyaWY7fQ0KQGxpc3QgbDA6bGV2 ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv gqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0K QGxpc3QgbDENCgl7bXNvLWxpc3QtaWQ6NzgyMDcwMzc4Ow0KCW1zby1saXN0LXR5cGU6aHlicmlk Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotNzE2NTYwNzIyIDY3Njk4NzA1IDY3Njk4NzEzIDY3 Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4 NzE1O30NCkBsaXN0IGwxOmxldmVsMQ0KCXttc28tbGV2ZWwtdGV4dDoiJTFcKSI7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMTpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMTps ZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0 LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDE6bGV2ZWw0DQoJe21zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47fQ0KQGxpc3QgbDE6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxv d2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDE6bGV2ZWw2DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0 O30NCkBsaXN0IGwxOmxldmVsNw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwx OmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwxOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpvbA0KCXttYXJn aW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3Bp ZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRh dGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8 Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSIgc3R5bGU9IndvcmQt d3JhcDpicmVhay13b3JkIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5IZWxsbyw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGVyZSBteSByZXNwb25z ZSB0byB0aGUgV0dMQyBmb3IgZHJhZnQtaWV0Zi1kbnNzZC1zcnAgYWNjb21wYW5pZWQgYnkgcmV2 aWV3IGNvbW1lbnRzIGZvciB0aGUgZHJhZnQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5JbiBzdW1tYXJ5LCBJIGJlbGlldmUgdGhlIGRvY3VtZW50IGFwYXJ0IGZyb20gU2Vj dGlvbiA1IGlzIHJlYWR5IHRvIGJlIHB1Ymxpc2hlZCBhZnRlciB0aGUgcmV2aWV3IGNvbW1lbnRz IGFyZSBhZGRyZXNzZWQ6IGFzIHRoZXNlIGNvbW1lbnRzIGFyZSBtb3N0bHkgb24gZWRpdG9yaWFs IGlzc3VlcywgdGV4dCBsb2NhdGlvbiBhbmQgcmVzb2x2aW5nIHBvdGVudGlhbCB1bmNsYXJpdGll cy4gVGhlIFNSUCBwcm90b2NvbA0KIG92ZXJhbGwgbG9va3MgdXNlZnVsLCBzb2xpZCBhbmQgd2Vs bC1kZXNjcmliZWQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBzcGVjaWZpYyBwYXJ0IG9m IFNlY3Rpb24gNSBvbiBTbGVlcCBQcm94eSBoYXMgaGFkIGxlc3Mgd29yayBpdCBzZWVtcywgYXMg YSBmZXcgb2YgbXkgb3JpZ2luYWwgLTA0IHJldmlldyBjb21tZW50cyBhcmUgc3RpbGwgb3BlbiBh bmQgSSBkb27igJl0IHNlZSBob3cgdGhpcyBmdW5jdGlvbiBjb3VsZCBsZWFkIHRvIGludGVyb3Bl cmFibGUgaW1wbGVtZW50YXRpb25zLiBUbyByZXNvbHZlIHRoaXMsIHBvc3NpYmxlDQogYWN0aW9u cyBhcmU6PG86cD48L286cD48L3A+DQo8b2wgc3R5bGU9Im1hcmdpbi10b3A6MGluIiBzdGFydD0i MSIgdHlwZT0iMSI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4t bGVmdDowaW47bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzIiPk1vdmUgdGhlIFNsZWVwIFByb3h5IGRl ZmluaXRpb24vZGV0YWlscyBvdXQgb2YgdGhpcyBkcmFmdCwgaW50byBhIHNlcGFyYXRlIG9uZS4g VGhpcyBjb3VsZCBwcm9ncmVzcyBTUlAgaW4gdGhlIGJlc3Qgd2F5LjxvOnA+PC9vOnA+PC9saT48 bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxp c3Q6bDEgbGV2ZWwxIGxmbzIiPkFkZCBtb3JlIGRldGFpbHMgb24gdGhlIFNsZWVwIFByb3h5LCB0 byBhIGZ1bGx5IGludGVyb3BlcmFibGUgaW1wbGVtZW50YXRpb24gYmVjb21lcyBwb3NzaWJsZS48 bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MGluO21zby1saXN0OmwxIGxldmVsMSBsZm8yIj5LZWVwIGN1cnJlbnQgU2VjdGlvbiA1 IHRleHQgKG9ubHkgbWlub3IgYWRkaXRpb25zL2NoYW5nZXMvZml4ZXMpLCBhbmQgYWRkIGEgc2Vu dGVuY2Ugc2F5aW5nIHRoYXQgbW9yZSBkZXRhaWxzIGNhbiBiZSBkZWZpbmVkIGluIGEgZnV0dXJl IGRvY3VtZW50IChlLmcuIGFmdGVyIGltcGxlbWVudGF0aW9ucyBoYXZlIGJlZW4NCiB0ZXN0ZWQg 4oCTIGNsaWVudHMgdnMgc2VydmVycyBvZiBkaWZmZXJlbnQgcGFydGllcyk8bzpwPjwvbzpwPjwv bGk+PC9vbD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJlbGF0ZWQgcXVlc3Rpb246IGFyZSBhbnkg aW1wbGVtZW50YXRpb25zIHVzaW5nIFNsZWVwIFByb3h5PzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5CZXN0IHJlZ2FyZHM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkVza288 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RGV0YWlsZWQgcmV2aWV3IGNvbW1lbnRzIGxpc3Q6PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPioqKiBBYnN0cmFjdDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+ODAyLjExIChXaS1GaSkgYW5kIDgwMi4xNS40IChJb1QpIG5ldHdvcmtz PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tJmd0OyBhZGQgJ0lFRUUnIHNv ICZxdW90O0lFRUUgODAyLjExIChXaS1GaSkgYW5kIDgwMi4xNS40IChJb1QpIG5ldHdvcmtzJnF1 b3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BcyBhbiBlZGl0b3JpYWwg Y29tbWVudCwgaW4gZ2VuZXJhbCB0aGUgYWJzdHJhY3Qgc2hvdWxkIG5vdCBjb250YWluIG1vcmUg ZGV0YWlscyB0aGFuIHRoZSBtYWluIHRleHQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5TbyB0eXBpY2FsbHkgb25lIHdvdWxkIHNlZSBiYWNrIHRoZXNlIHRlcm1zIGFnYWlu IGluIGFuIGludHJvZHVjdGlvbi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+KioqIDIuMi4xPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mcXVvdDtSRkMgNjc2MyBkZXNjcmli ZXMgdGhlIGRldGFpbHMgb2Ygd2hhdCBlYWNoIG9mIHRoZXNlIHR5cGVzIG9mIHVwZGF0ZXMgY29u dGFpbnMmcXVvdDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0mZ3Q7IG5v dCBldmVyeXRoaW5nIGNvbnRhaW5lZCBpbiB0aGVzZSB1cGRhdGVzIGlzIGV4cGxhaW5lZCBpbiBS RkMgNjc2My4gU3BlY2lmaWNhbGx5LCB0aGUgJnF1b3Q7S2V5IFJSJnF1b3Q7IGlzIG5vdCBpbiB0 aGF0IFJGQy4gQW5vdGhlciBSRkMgcmVmIGNhbiBiZSBhZGRlZCBoZXJlIHRoYXQgZGVmaW5lcyBL ZXkgUlIgYXMgZGVmaW5pdGl2ZSBzb3VyY2Ugb2YgaW5mb3JtYXRpb24uPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPioqKiAyLjIuMy4xPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mcXVvdDtTUlAgY2xpZW50cyBhcmUgYWxsb3dlZCB0byBzZW5kIHVwZGF0ZXMgdG8gdGhlIGdl bmVyaWMgZG9tYWluICZxdW90O2RlZmF1bHQuc2VydmljZS5hcnBhJnF1b3Q7JnF1b3Q7PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tJmd0OyBJbiBzZWN0aW9uIDIuMS4qIGl0 IGxvb2tzIGFzIGlmIG9ubHkgY29uc3RyYWluZWQgaG9zdHMgY2FuIGRvIHRoaXMuIENhbiBmdWxs LWZlYXR1cmVkIGhvc3RzIGFsc28gZG8gdGhpcz8gSWYgbm90IHdlIGNhbiBzYXkgJnF1b3Q7Q29u c3RyYWluZWQtTm9kZSBTUlAgY2xpZW50cyBhcmUgLi4uJnF1b3Q7Jm5ic3A7Jm5ic3A7IElmIHll cywgdGhlbiBJIHdvdWxkIGV4cGVjdCBzZWN0aW9uIDIuMS4xIHRvIG1lbnRpb24gdGhpcyB1c2Ug Zm9yIHRoZQ0KIGZ1bGwtZmVhdHVyZWQgaG9zdHMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPioq KiAyLjIuNS4xPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5kdXBsaWNhdGVk IHNlbnRlbmNlICZxdW90O1RoaXMga2V5IHBhaXIgTVVTVCBiZSB1bmlxdWUgdG8gdGhlIGRldmlj ZS4mcXVvdDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+KioqIDIuMi41LjQ8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRvZXMgdGhlIHN0YXRlbWVudCBoZXJlIGltcGx5IHRo YXQgdGhpcyBkcmFmdCBmb3JtYWxseSB1cGRhdGVzIFJGQyAyNzgyPzxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+KFF1ZXN0aW9uIHRvIHRoZSBXRy4gTWF5YmUgbm90OiBzaW5j ZSB0aGUgdXBkYXRlIG9ubHkgYXBwbGllcyBpbiBTUlAgY29udGV4dCBub3QgZm9yIFNSViByZWNv cmRzIGluIGdlbmVyYWwuIEJ1dCBtYXliZSB5ZXM6IFJGQyAyNzgyIHNheXMgJnF1b3Q7VW5sZXNz IGFuZCB1bnRpbCBwZXJtaXR0ZWQgYnkgZnV0dXJlIHN0YW5kYXJkcyBhY3Rpb24sIG5hbWUgY29t cHJlc3Npb24gaXMgbm90IHRvIGJlIHVzZWQgZm9yIHRoaXMNCiBmaWVsZC4mcXVvdDsgd2hpY2gg d291bGQgbWFrZSBpdCBwcm9wZXIgdG8gcmVmZXIgdG8gdGhlIFNSUCBkcmFmdCBhcyBzdWNoIGZ1 dHVyZSBhY3Rpb24uKTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4qKiogMi4yLjUuNS4yPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mcXVvdDt1cGRhdGUgdGhhdCBkZWxldGVz IHRoZSBQVFIgcmVjb3JkIHdob3NlIHRhcmdldCBpcyB0aGUgc2VydmljZSBpbnN0YW5jZSBuYW1l LiZxdW90OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LSZndDsgVGhpcyBs b29rcyBsaWtlIGEgc2luZ2xlIFBUUiByZWNvcmQuIFByaW9yIHNlY3Rpb24gMi4yLjEgbWVudGlv bnMgdGhhdCB0aGUgc2VydmljZSBpbnN0YW5jZSBuYW1lIG1heSBiZSByZWZlcnJlZCB0byBieSBt dWx0aXBsZSBQVFIgcmVjb3Jkcy4mbmJzcDsgU28gaW4gY2FzZSBvZiBtdWx0aXBsZSwgaXQgaXMg bm90IHJlcXVpcmVkIHRvIGhhdmUgbXVsdGlwbGUgaW5zdHJ1Y3Rpb25zIHRvIGRlbGV0ZSB0aGVz ZSBtdWx0aXBsZQ0KIFBUUiByZWNvcmRzPzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+KEkuZS4gdGhlcmUncyBubyByaXNrIG9mIGxpbmdlcmluZyBQVFIgcmVjb3JkcyB0aGF0 IHdvdWxkIHBvaW50IHRvIGEgc2VydmljZSBpbnN0YW5jZSB0aGF0J3MgZGVsZXRlZD8pPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPioqKiAyLjMgdGl0bGUgPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5bTml0XSAtJmd0OyBtYXkgZ2l2ZSB0aGUgaW1wcmVzc2lvbiB0aGF0IGFs bCBTUlAgc2VydmVyIGJlaGF2aW9yIGlzIHNwZWNpZmllZCBpbiBoZXJlLjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U29tZXdoZXJlIGluIDIuMyAvIDIuMy4qIGl0IGNvdWxk IG1lbnRpb24gdGhhdCBtb3JlIG5vcm1hdGl2ZSBiZWhhdmlvciBpcyBzcGVjaWZpZWQgaW4gb3Ro ZXIgc2VjdGlvbnMgdG9vLCBsaWtlIFNlY3Rpb25zIDMgYW5kIDQuPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPioqKiAyLjMuMTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+R3Jh bW1hciB0byBiZSBmaXhlZDogJnF1b3Q7RWFjaCBpbnN0cnVjdGlvbiBjb25zaXN0cyBzb21lIGNv bWJpbmF0aW9uJnF1b3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPioqKiAyLjMuMS4xPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mcXVvdDtpZiB0aGUgU2VydmljZSBEaXNj b3ZlcnkgdXBkYXRlIGlzIGFuICZxdW90O0FkZCB0byBhbiBSUlNldCZxdW90OyBpbnN0cnVjdGlv biwgdGhlIFNlcnZpY2UgRGVzY3JpcHRpb24gSW5zdHJ1Y3Rpb24gZG9lcyBub3QgbWF0Y2ggaWYm cXVvdDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0mZ3Q7IGZvciBtZSB1 bmNsZWFyLCBzZWUgc2VwYXJhdGUgbWFpbCB0aHJlYWQgb24gdGhpcyBzZWN0aW9uLjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4qKiogMi4zLjEuMjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+W05pdF0gQnVsbGV0OjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+JnF1b3Q7KiZuYnNwOyBTZXJ2aWNlIERlc2NyaXB0aW9ucyBJbnN0cnVjdGlvbnMgZG8gbm90 IG1vZGlmeSBhbnkgb3RoZXIgUlJzLiZxdW90OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+LSZndDsgYmVzdCByZXBocmFzZWQgdG8gPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDsmcXVvdDsqJm5ic3A7IG5vIFJSIHVwZGF0ZXMgb3RoZXIgdGhh biB0aGUgb25lcyBkZWZpbmVkIGFib3ZlLiZxdW90OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5U aGF0IHdvdWxkIGZpdCBiZXR0ZXIgaW4gdGhlIHN0eWxlIG9mIHRoZSBwcmV2aW91cyBidWxsZXQg cG9pbnRzIGluIHRoZSBsaXN0LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4qKiogMi4zLjEuMzxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+JnF1b3Q7SWYgYSBsaW5rLXNjb3Bl IGFkZHJlc3Mgb3IgSVB2NCBhdXRvY29uZmlndXJhdGlvbiBhZGRyZXNzIGlzIHByb3ZpZGVkIGJ5 IHRoZSBTUlAgY2xpZW50LCB0aGU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOyBTUlAgc2VydmVyIE1VU1QgdHJlYXQgdGhpcyBhcyBpZiBubyBhZGRyZXNzIHJlY29y ZHMgd2VyZSByZWNlaXZlZDsgdGhhdCBpcywgdGhlIEhvc3QgRGVzY3JpcHRpb24gaXMgbm90IHZh bGlkLiZxdW90OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LSZndDsgVGhp cyBzZWVtcyByYXRoZXIgc3RyaWN0LiBJZiB0aGUgY2xpZW50IHByb3ZpZGVzIDEgcm91dGFibGUg SVAgYWRkcmVzcyBhbmQgMSBsaW5rLWxvY2FsIGFkZHJlc3MsIGNvdWxkbid0IHRoZSBTUlAgc2Vy dmVyIGp1c3QgaWdub3JlIHRoZSBsaW5rLWxvY2FsIGFkZHJlc3M/PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIG1pZ2h0IGhhdmUgc29tZSBiZW5lZml0cyBmb3IgZnV0 dXJlL2JhY2t3YXJkcyBjb21wYXRpYmlsaXR5ICwgaW4gY2FzZSBvZiBmdXR1cmUgY2FzZXMgd2hl cmUgbGluay1sb2NhbCBhZGRyZXNzZXMgYXJlIHRvIGJlIHVzZWQgZm9yIHNvbWUgcmVhc29uLiAo SWYgb25seSBmb3IgZGVidWcvZGlhZ25vc3RpYyBwdXJwb3Nlcyk8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkkgYWdyZWUgdGhhdCBpZiB0aGUgY2xpZW50IHNlbmRzIG9ubHkg bGluay1sb2NhbCBhZGRyZXNzKGVzKSB0aGVuIHRoZSBTUlAgc2VydmVyIHRyZWF0cyBpdCBhcyBp ZiBubyBhZGRyZXNzIHJlY29yZHMgd2VyZSByZWNlaXZlZC48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+KioqIDIuMy4yPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5bTml0XSAm cXVvdDttdXN0IGhhdmUgdGhhdCBIb3N0IERlc2NyaXB0aW9uIGluc3RydWN0aW9uIGFzIHRoZSB0 YXJnZXQgb2YgaXRzIFNSViByZWNvcmQmcXVvdDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPi0mZ3Q7IGNvdWxkIHJlcGhyYXNlIHRvICZxdW90O01VU1QgaGF2ZSB0aGUgaG9z dG5hbWUgb2YgdGhhdCBIb3N0IERlc2NyaXB0aW9uIEluc3RydWN0aW9uIGFzIHRoZSB0YXJnZXQg b2YgaXRzIFNSViByZWNvcmQmcXVvdDsmbmJzcDsgdG8gYmUgbW9yZSBwcmVjaXNlLjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U2ltaWxhciBjb21tZW50cyBjYW4gYmUgZ2l2 ZW4gZm9yIHRoZSByZW1haW5kZXIgb2YgdGhlIHNlY3Rpb24gdGV4dCB0aGF0IHRhbGtzIGFib3V0 IGluc3RydWN0aW9ucyBwb2ludGluZyB0byBpbnN0cnVjdGlvbnMuJm5ic3A7IChJdCdzIG1vcmUg bGlrZSBuYW1lcyBpbiBpbnN0cnVjdGlvbnMgYmVpbmcgZXF1YWwgdG8gbmFtZXMgdGhhdCBhcmUg dXNlZCBpbiBvdGhlciBpbnN0cnVjdGlvbnMpPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4obm90IHN1cmUgaWYgTVVTVCBvciBtdXN0IGlzIGRlc2lyZWQgaGVyZSBieSB0aGUg d2F5KTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mcXVvdDtGb3IgZXhhbXBsZSwgYSBETlMgdXBk YXRlIHRoYXQgY29udGFpbnMgYW4gUlJzZXQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOyZuYnNwOyBBZGQgdG8gYSBTZXJ2aWNlIE5hbWUgYW5kIGFuIFJSc2V0IEFk ZCB0byBhIFNlcnZpY2UgSW5zdGFuY2UgTmFtZSw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOyZuYnNwOyB3aGVyZSB0aGUgU2VydmljZSBOYW1lIGRvZXMgbm90IHJl ZmVyZW5jZSB0aGUgU2VydmljZSBJbnN0YW5jZSBOYW1lLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7IGlzIG5vdCBhIHZhbGlkIFNSUCB1cGRhdGUgbWVz c2FnZSZxdW90OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LSZndDsgJ1JS c2V0IEFkZCcgcmVmZXJzIHByb2JhYmx5IHRvIHRoZSAmcXVvdDtBZGQgVG8gQW4gUlJzZXQmcXVv dDsgc2VtYW50aWNzIG9mIFJGQyAyMTM2PyBJZiBzbyBpdCB3b3VsZCBiZSBnb29kIHRvIHVzZSB0 aGF0IGV4YWN0IHNhbWUgbmFtaW5nICZxdW90O0FkZCBUbyBBbiBSUnNldCZxdW90OyBpbmNsdWRp bmcgdGhlIHF1b3RlcyBoZXJlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ V2l0aCBwcmVzZW50IHRleHQgSSdtIHdvbmRlcmluZyBpZiBJIG1pc3NlZCBzb21ldGhpbmcgaW4g dGhlIEROUyBzcGVjcyB0aGF0J3MgY2FsbGVkICZxdW90O1JSc2V0IEFkZCZxdW90Oy48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+KioqIDIuMy4zPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mcXVvdDtJZiBhbnkgZXhpc3RpbmcgS0VZIHJlY29yZCBjb3JyZXNwb25kaW5nIHRv IGE8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyBLRVkg cmVjb3JkIGluIHRoZSBTUlAgVXBkYXRlIGRvZXMgbm90IG1hdGNoIHRoZSBLRVkgc2FtZSByZWNv cmQgaW48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyB0 aGUgU1JQIFVwZGF0ZSAmcXVvdDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pi0mZ3Q7IGdyYW1tYXIgaXNzdWUuICdtYXRjaCB0aGUgS0VZIHNhbWUgcmVjb3JkJyZuYnNwOyZu YnNwOyZuYnNwOyBBbmQgYSBiaXQgY29uZnVzaW5nOiBjYW4gYSBLRVkgcmVjb3JkIGluIGFuIHVw ZGF0ZSBjb3JyZXNwb25kIHRvIGEgc3RvcmVkIEtFWSByZWNvcmQgYnV0IG5vdCBtYXRjaCBhdCB0 aGUgc2FtZSB0aW1lPzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 IFBlcmhhcHMgdGhlICduYW1lJyBjb25jZXB0IHNob3VsZCBiZSBpbnRyb2R1Y2VkIGhlcmUgdG8g Y2xhcmlmeS4gKFByZXN1bWFibHkgdGhlIHNlcnZlciB3aWxsIGNoZWNrIGlmIGFuIGV4aXN0aW5n IFNlcnZpY2UgSW5zdGFuY2UgTmFtZSBvciBleGlzdGluZyBIb3N0bmFtZSBpcyBzdG9yZWQgYW5k IGxvb2sgdXAgdGhlIGFzc29jaWF0ZWQgS0VZIGZvciB0aGF0Lik8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+JnF1b3Q7S0VZIHJlY29yZCB1cGRhdGVzIG9taXR0ZWQgZnJvbSBTZXJ2aWNlIERlc2Ny aXB0aW9uIHVwZGF0ZSBhcmU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOyZuYnNwOyBwcm9jZXNzZWQgYXMgaWYgdGhleSBoYWQgYmVlbiBleHBsaWNpdGx5IHByZXNl bnQ6IGV2ZXJ5IFNlcnZpY2U8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOyZuYnNwOyBEZXNjcmlwdGlvbiB0aGF0IGlzIHVwZGF0ZWQgTVVTVCwgYWZ0ZXIgdGhlIHVw ZGF0ZSwgaGF2ZSBhIEtFWSBSUiw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOyZuYnNwOyBhbmQgaXQgbXVzdCBiZSB0aGUgc2FtZSBLRVkgUlIgdGhhdCBpcyBwcmVz ZW50IGluIHRoZSBIb3N0PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDsmbmJzcDsgRGVzY3JpcHRpb24gdG8gd2hpY2ggdGhlIFNlcnZpY2UgRGVzY3JpcHRpb24gcmVm ZXJzLiZxdW90OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LSZndDsgQ2Fu IHdlIHJlcGxhY2UgaGVyZSAnU2VydmljZSBEZXNjcmlwdGlvbiB1cGRhdGUnIGJ5ICdTZXJ2aWNl IERlc2NyaXB0aW9uIEluc3RydWN0aW9uJyA/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5FLmcuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mcXVvdDtL RVkgcmVjb3JkIHVwZGF0ZXMgb21pdHRlZCBmcm9tIFNlcnZpY2UgRGVzY3JpcHRpb24gSW5zdHJ1 Y3Rpb25zIGFyZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5i c3A7IHByb2Nlc3NlZCBhcyBpZiB0aGV5IGhhZCBiZWVuIGV4cGxpY2l0bHkgcHJlc2VudDogZXZl cnkgU2VydmljZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5i c3A7IERlc2NyaXB0aW9uIHRoYXQgaXMgdXBkYXRlZCB0aHJvdWdoIGEgU2VydmljZSBEZXNjcmlw dGlvbiBJbnN0cnVjdGlvbiBNVVNULCBhZnRlciB0aGUgdXBkYXRlLCBoYXZlIGEgS0VZIFJSLDxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7IGFuZCBpdCBt dXN0IGJlIHRoZSBzYW1lIEtFWSBSUiB0aGF0IGlzIHByZXNlbnQgaW4gdGhlIEhvc3Q8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyBEZXNjcmlwdGlvbiBJ bnN0cnVjdGlvbiB0byB3aGljaCB0aGUgU2VydmljZSBEZXNjcmlwdGlvbiBJbnN0cnVjdGlvbiBy ZWZlcnMuJnF1b3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZxdW90O090aGVyd2lzZSwgdGhl IHNlcnZlciB2YWxpZGF0ZXMgdGhlIFNSUCBVcGRhdGUgdXNpbmcgU0lHKDApIG9uIHRoZTxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7IHB1YmxpYyBrZXkg aW4gdGhlIEtFWSByZWNvcmQgb2YgdGhlIEhvc3QgRGVzY3JpcHRpb24gdXBkYXRlLiZxdW90Ozxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LSZndDsgd2hhdCBhYm91dDo8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZxdW90O090aGVyd2lzZSwgdGhlIHNl cnZlciB2YWxpZGF0ZXMgdGhlIFNSUCBVcGRhdGUgdXNpbmcgU0lHKDApIGFnYWluc3QgdGhlPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsgcHVibGljIGtl eSBpbiB0aGUgS0VZIHJlY29yZCBvZiB0aGUgSG9zdCBEZXNjcmlwdGlvbiBJbnN0cnVjdGlvbi4m cXVvdDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+KFVzaW5nICdJbnN0cnVjdGlvbicgYW5kICd2 YWxpZGF0ZXMgWCBhZ2FpbnN0IFknIGluc3RlYWQgb2YgJ3ZhbGlkYXRpb25zIFggb24gWScgKTxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4qKiogMzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+JnF1b3Q7U1JQIHVwZGF0ZSBzZXJ2ZXJzIE1VU1QgY2hlY2smcXVvdDs8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0mZ3Q7JnF1b3Q7U1JQIHNlcnZlcnMgTVVT VCBjaGVjayZxdW90OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4qKiogNC4xPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5bTml0XSAmcXVvdDsgTVVTVCBiZSByZW1vdmVkIGF0 IHRoZSBzYW1lIHRpbWUtaXQgaXMgbmV2ZXIgdmFsaWQgZm9yIGEgc2VydmljZSZxdW90OzxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LSZndDsgJnF1b3Q7IE1VU1QgYmUgcmVt b3ZlZCBhdCB0aGUgc2FtZSB0aW1lIC0tIGl0IGlzIG5ldmVyIHZhbGlkIGZvciBhIHNlcnZpY2Ug JnF1b3Q7IG9yPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tJmd0OyAmcXVv dDsgTVVTVCBiZSByZW1vdmVkIGF0IHRoZSBzYW1lIHRpbWU6IGl0IGlzIG5ldmVyIHZhbGlkIGZv ciBhIHNlcnZpY2UgJnF1b3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjNyZCBwYXJhZ3JhcGgg bWVudGlvbnMgdGhhdCBhIFNSUCBpcyBieSBkZWZhdWx0IGNvbmZpZ3VyZWQgd2l0aCBhIDIgaG91 ciBMZWFzZSBsaW1pdCBhbmQgMTQtZGF5IEtFWSByZXRhaW5pbmcgdGltZSBsaW1pdDsgYW5kIHRo ZW4gaXQgc2F5cyB0aGF0IGNvbnN0cmFpbmVkIGRldmljZXMgbWF5IG5lZ290aWF0ZSBsb25nZXIg bGVhc2VzLiBUaGlzIGxvb2tzIGluY29ycmVjdCwgYXMgbGVhc2VzIGJleW9uZCBjb25maWd1cmVk DQogdXBwZXIgbGltaXRzIHdvbid0IGJlIGdpdmVuIGJ5IHRoZSBzZXJ2ZXIuPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Qcm9iYWJseSBzb21ldGhpbmcgZWxzZSBpcyBtZWFu dCBoZXJlIHdpdGggJ25lZ290aWF0ZSc/IEZvciBleGFtcGxlIGlmIG9uZSBjb25maWd1cmVzICdk ZWZhdWx0IHZhbHVlcycgZm9yIExlYXNlIGFuZCBLZXktTGVhc2UgaW4gdGhlIHNlcnZlciwgdGhl IHNlcnZlIG1heSBleHRlbmQgdG8gdGhlc2UgZGVmYXVsdCB2YWx1ZXMgaWYgdGhlIGNsaWVudCBh c2tzIGZvciBzb21ldGhpbmcgc2hvcnRlci4gSWYgdGhlDQogY2xpZW50IGFza3MgZm9yIHNvbWV0 aGluZyBsb25nZXIgdGhhbiB0aGUgJ2RlZmF1bHQgdmFsdWVzJywgdGhlIHNlcnZlciBncmFudHMg dGhlIGxvbmdlciB2YWx1ZXMgdXAgdG8gYSBoYXJkIGxpbWl0IHRoYXQgaXMgYWxzbyBjb25maWd1 cmVkIGluIHRoZSBzZXJ2ZXIuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPioqKiA1IFNsZWVwIFBy b3h5PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgaW50cm9kdWN0aW9u IHRleHQgc2hvdWxkIGNsYXJpZnkgd2hldGhlciBTbGVlcCBQcm94eSBzdXBwb3J0IGZvciBhbiBT UlAgc2VydmVyIGlzIE9QVElPTkFMIG9yIE1BTkRBVE9SWS48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkFsc28gdG8gbWFrZSBtb3JlIGNsZWFyIHRoYXQgZm9yIGNsaWVudHMg dGhlIHVzZSBvZiB0aGlzIGZ1bmN0aW9uIGlzIG9wdGlvbmFsL09QVElPTkFMLiAoVGhlIGxhc3Qg cGFyYWdyYXBoIHNheXMgc28gZm9yIGNvbnN0cmFpbmVkIGhvc3RzLCBidXQgbm90aGluZyBmb3Ig dGhlIGZ1bGwtZmVhdHVyZWQgaG9zdHMuKTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbiByZWxh dGlvbiB0byBhYm92ZSwgdGhlIHNhbWUgcXVlc3Rpb25zIGZyb20gbXkgcmV2aWV3IG9mIC0wNCBv ZiAyMDIwLTEwLTEzIHN0aWxsIGFwcGx5OjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+LSBIb3cgd291bGQgYSBzZXJ2aWNl4oCZcyBob3N0IGtub3cgdGhhdCB0aGUgc2VydmVy IGlzIGNhcGFibGUgdG8gZG8gdGhpcz8gSWYgaXQgZG9lc24ndCBrbm93IHRoZW4gaXQgY2Fubm90 IHRydXN0IHRoZSBtZWNoYW5pc20gdG8gd29yayBhbmQgZ28gdG8gc2xlZXAuPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tIE9yLCBpcyB0aGVyZSBhIHdheSBmb3IgdGhlIFNS UCBzZXJ2ZXIgdG8gcmVqZWN0IGFuIHVwZGF0ZSB3aXRoIEVETlMoMCkgT1dORVIgb3B0aW9uIHN1 Y2ggdGhhdCB0aGUgc2VydmljZeKAmXMgaG9zdCBrbm93cyBub3QgdG8gdXNlIGl0IGFnYWluPzxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5bTml0XSAmcXVvdDtBbm90aGVyIHVzZSBvZiBTUlAgaXMg Zm9yIGRldmljZXMgdGhhdCBzbGVlcCB0byByZWR1Y2UgcG93ZXIgY29uc3VtcHRpb24mcXVvdDs8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0mZ3Q7IGlkZWFsbHkgaXQgc2hv dWxkIG1lbnRpb24gc29tZXdoZXJlIHRoYXQgdGhlIGRldmljZSB0aGF0IHNsZWVwcyBpcyBhbiBT UlAgY2xpZW50LiBPdGhlcndpc2UgdGhlIHN0YXRlbWVudCBpcyBhIGJpdCB0b28gZ2VuZXJpYy4g RS5nLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+JnF1b3Q7QW5vdGhlciB1 c2Ugb2YgU1JQIGlzIGZvciBTUlAgY2xpZW50IGRldmljZXMgdGhhdCBzbGVlcCB0byByZWR1Y2Ug cG93ZXIgY29uc3VtcHRpb24sIHdoaWxlIGJlaW5nIGFibGUgdG8gb2ZmZXIgcmVnaXN0ZXJlZCBz ZXJ2aWNlKHMpIHdpdGhvdXQgaW50ZXJydXB0aW9uLiZxdW90OzxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mcXVvdDt0aGUgZGV2aWNlIGluY2x1ZGVzIGFuIEVETlMoMCkgT1dORVIgT3B0aW9uIFtJ LUQuY2hlc2hpcmUtZWRuczAtb3duZXItb3B0aW9uXSZxdW90OzxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+LSZndDsgdGhlIHJlZmVyZW5jZSBoZXJlIGlzIEluZm9ybWF0aW9u YWw7IGhvdyBjYW4gdGhpcyBiZT8gVG8gaW1wbGVtZW50IHRoZSBzbGVlcCBwcm94eSBmdW5jdGlv biBpdCBpcyBub3JtYXRpdmUgdG8gaW5jbHVkZSB0aGUgb3B0aW9uLjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mcXVvdDtXaGVuIHRoZSBETlMgc2VydmVyIHJlY2VpdmVzIGEgVENQIFNZTiBvciBV RFAgcGFja2V0IGFkZHJlc3NlZCB0byZxdW90Ow0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4tJmd0OyAmcXVvdDtXaGVuIHRoZSBTbGVlcCBQcm94eSByZWNlaXZlcyBhIFRD UCBTWU4gb3IgVURQIHBhY2tldCBhZGRyZXNzZWQgdG8mcXVvdDs8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPihzZWUgYWxzbyBiZWxvdyBjb21tZW50KTxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mcXVvdDt0aGUgU2xlZXAgUHJveHkgbXVzdCBiZSBvbiB0aGUgc2FtZSBsaW5r JnF1b3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tJmd0OyB0aGUgdGVy bSAmcXVvdDtTbGVlcCBQcm94eSZxdW90OyBpcyBub3QgaW50cm9kdWNlZC4gSW4gdGhlIHByaW9y IHRleHQgd2hlbiBpdCBzYXlzICZxdW90O3Nob3VsZCBzZXQgdXAgYSBwcm94eSZxdW90OyB0aGUg bmFtZSBjb3VsZCBiZSBmb3JtYWxseSBpbnRyb2R1Y2VkIGUuZy4gJnF1b3Q7c2hvdWxkIHNldCB1 cCBhIFNsZWVwIFByb3h5JnF1b3Q7IG9yICZxdW90O3Nob3VsZCBzZXQgdXAgYSBwcm94eSwgY2Fs bGVkIHRoZSBTbGVlcCBQcm94eSwgJnF1b3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk92ZXJh bGwsIEkgbWlzcyBzb21lIGRldGFpbHMgYWJvdXQgd2hhdCB0aGUgU2xlZXAgUHJveHkgZG9lcyBv bmNlIGl0IHJlY2VpdmVzIGEgVENQIFNZTiBvciBVRFAgcGFja2V0IGFuZCBpdCBoYXMgd29rZW4g dXAgdGhlIHNsZWVweSBkZXZpY2UuIERvZXMgaXQgdGhlbiBzdG9wIHRoZSBBUlAvTkQgcHJveHlp bmcgZm9yIHRoZSBzbGVlcHkgZGV2aWNlIHJpZ2h0IGF3YXk/IEFuZCB3aGVuIHdvdWxkIGl0IGFn YWluDQogcmVzdW1lIHByb3h5aW5nPzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+V2hhdCBkb2VzIHRoZSBwcm94eSBkbyB3aXRoIHRoZSByZWNlaXZlIFRDUCBTWU4gb3IgVURQ IHBhY2tldCwgZGlzY2FyZCBvciBmb3J3YXJkIHRvIHRoZSB3b2tlbiBzbGVlcHkgZGV2aWNlPyAo QWZ0ZXIgaG93IG11Y2ggd2FpdGluZyB0aW1lPyk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Kioq IDYuMTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+JnF1b3Q7U2VydmljZSBE aXNjb3ZlcnkgUHJvdG9jb2wgc2VydmVycyZxdW90OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+LSZndDsgaXMgdGhpcyB0ZXJtIGRlZmluZWQ/IFNob3VsZCB3ZSBzYXkgU1JQ IHNlcnZlcnMgaGVyZT88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+JnF1b3Q7YSBwcm9taXNlIG1h ZGUgYnkgdGhlIHJlZ2lzdHJhdGlvbiBwcm90b2NvbCZxdW90OzxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+LSZndDsgJnF1b3Q7YSBwcm9taXNlIG1hZGUgYnkgdGhlIHNlcnZp Y2UgcmVnaXN0cmF0aW9uIHByb3RvY29sJnF1b3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZx dW90O3JlcGxhY2luZyBhbGwgb3IgcGFydCBvZiB0aGUgc2VydmljZSByZWdpc3RyYXRpb24gaW5m b3JtYXRpb24gd2l0aCBpbmZvcm1hdGlvbiBwcm92aWRlZCBieSBhbiBTUlAgY2xpZW50JnF1b3Q7 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tJmd0OyB0aGUgJnF1b3Q7U1JQ IGNsaWVudCZxdW90OyBtZW50aW9uZWQgaGVyZSBJIHRoaW5rIHNob3VsZCBiZSAmcXVvdDtETlMg Y2xpZW50JnF1b3Q7LiBCZWNhdXNlIHRoZSBjYXNlIG1lbnRpb25lZCBsb29rZWQgbGlrZSBhbiBh dXRoZW50aWNhdGVkIChub24tU1JQKSBETlMgY2xpZW50IG1ha2luZyBETlMgdXBkYXRlcyB0byBy ZWNvcmRzIHRoYXQgd2VyZSBhZGRlZCBieSBhbiBTUlAgY2xpZW50LjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4qKiogNyAmcXVvdDtQcml2YWN5IENvbnNpZGVyYXRpb25zJnF1b3Q7PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIHRleHQgbWVudGlvbnMgdGhlIHJlcXVp cmVtZW50cyBmb3IgVExTLiBQZXJoYXBzIHRoZSBUTFMgYml0cyBhcmUgYmV0dGVyIHBsYWNlZCBp biBTZWN0aW9uIDYsIGFuZCBTZWN0aW9uIDcgaWYgbmVlZGVkIGNhbiByZWZlciBiYWNrIHRvIHRo YXQuIFRvIG1lIFRMUyBzZWVtcyBvbmUgb2YgdGhlIGtleSBpbmdyZWRpZW50cyB0byBzZWN1cmUg dGhlIHByb3RvY29sIHNvIEknZCBleHBlY3QgdG8gcmVhZCBzb21ldGhpbmcNCiAvIG1vc3QtdGhp bmdzIGFib3V0IHRoaXMgaW4gU2VjdGlvbiA2LiZuYnNwOyZuYnNwOyAoTWF5YmUgSSdtIHdyb25n IGhlcmUgaW4gY2FzZSBUTFMgY2FuJ3QgcHJvdmlkZSB0aGUgYXV0aGVudGljYXRpb24gLSBzaW5j ZSBpbiBzb21lIGRlcGxveW1lbnRzIHRoZSBjbGllbnQgbWF5IGhhdmUgbm8gdHJ1c3QgYW5jaG9y IG9mIHRoZSBkb21haW4gaW5zdGFsbGVkIGEgcHJpb3JpLCBzbyBpdCBjYW4ndCBhdXRoZW50aWNh dGUgdGhlIFNSUCBzZXJ2ZXIgZXZlbiB3aGVuDQogVExTIGlzIHVzZWQuKTxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4qKiogOS4yPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m cXVvdDtBdmFpbGFiaWxpdHkgb2YgRE5TIFNlcnZpY2UgRGlzY292ZXJ5IFNlcnZpY2UgUmVnaXN0 cmF0aW9uIFByb3RvY29sPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDsmbmJzcDsgU2VydmljZSBmb3IgYSBnaXZlbiBkb21haW4gaXMgYWR2ZXJ0aXNlZCB1c2luZyB0 aGU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyAmcXVv dDtfZG5zc2Qtc3JwLl90Y3AuJmx0O2RvbWFpbiZndDsuJnF1b3Q7Jm5ic3A7IFNSViByZWNvcmQg Z2l2ZXMgdGhlIHRhcmdldCBob3N0IGFuZDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7Jm5ic3A7IHBvcnQgd2hlcmUgRE5TU0QgU2VydmljZSBSZWdpc3RyYXRpb24g U2VydmljZSBpcyBwcm92aWRlZCBmb3IgdGhlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDsmbmJzcDsgbmFtZWQgZG9tYWluLiZxdW90OzxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+LSZndDsgc2VlbXMgbGlrZSBhIGdyYW1tYXIgaXNzdWUgaGVyZS4gV2Fz IHRoaXMgbWVhbnQgYXMgYSBzaW5nbGUgc2VudGVuY2UsIG9yIGFzIDIgc2VudGVuY2VzIHNlcGFy YXRlZCBieSBhIGRvdCBiZWZvcmUgdGhlICZxdW90O1NSViByZWNvcmQmcXVvdDsgdGV4dD88bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkUuZy4gSSBjb3VsZCBpbnRlcnByZXQg YXMgJnF1b3Q7dXNpbmcgdGhlIFggU1JWIHJlY29yZCB3aGljaCBnaXZlcyB0aGUgWSZxdW90OyBv ciBhcyAmcXVvdDt1c2luZyB0aGUgWCBuYW1lLiBUaGUgU1JWIHJlY29yZCBnaXZlcyB0aGUgWSZx dW90Oy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNpbWlsYXIgcG9pbnQg Zm9yIDkuMy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlk ICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj5Gcm9tOjwvYj4gRGF2aWQgU2NoaW5hemkgJmx0O2RzY2hpbmF6aS5pZXRmQGdt YWlsLmNvbSZndDsgPGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgQXVndXN0IDE2LCAyMDIxIDIw OjA5PGJyPg0KPGI+VG86PC9iPiBFc2tvIERpamsgJmx0O2Vza28uZGlqa0Bpb3Rjb25zdWx0YW5j eS5ubCZndDs8YnI+DQo8Yj5DYzo8L2I+IEROU1NEICZsdDtkbnNzZEBpZXRmLm9yZyZndDs8YnI+ DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtkbnNzZF0gV0dMQyBmb3IgZHJhZnQtaWV0Zi1kbnNzZC1z cnA8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgRXNrbyw8bzpwPjwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYXQncyByZWFzb25hYmxl LCB3ZSBjYW4gd2FpdCBhIGZldyBtb3JlIGRheXMgZm9yIHlvdSB0byByZXZpZXcuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRhdmlkPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFN1biwg QXVnIDE1LCAyMDIxIGF0IDE6MzcgUE0gRXNrbyBEaWprICZsdDs8YSBocmVmPSJtYWlsdG86ZXNr by5kaWprQGlvdGNvbnN1bHRhbmN5Lm5sIj5lc2tvLmRpamtAaW90Y29uc3VsdGFuY3kubmw8L2E+ Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGlu IDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5IZWxsbyBEYXZpZCw8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPkR1ZSB0byBob2xpZGF5IEkgbWlzc2VkIHRoaXMgbGFzdCBjYWxsLiBIYXZp bmcgcmV2aWV3ZWQgYW4gZWFybGllciB2ZXJzaW9uIEkgd291bGQgbGlrZSB0byBjaGVjayBpZiB0 aGUgaXNzdWVzIGFyZSBzb2x2ZWQgbm93OyBhbmQgY2FuIGFuc3dlciB0aGUgcXVlc3Rpb24gYnkg VHVlc2RheSBvciBXZWRuZXNkYXkNCiBpZiB0aGF04oCZcyBvay4gKEluc3RlYWQgb2YgdG9kYXkp PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5CZXN0IHJlZ2FyZHM8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+RXNrbzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGlu Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+RnJvbTo8L2I+IGRuc3NkICZsdDs8YSBocmVm PSJtYWlsdG86ZG5zc2QtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmRuc3NkLWJv dW5jZXNAaWV0Zi5vcmc8L2E+Jmd0Ow0KPGI+T24gQmVoYWxmIE9mIDwvYj5EYXZpZCBTY2hpbmF6 aTxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIEp1bHkgMjgsIDIwMjEgMjM6NTc8YnI+DQo8 Yj5Ubzo8L2I+IEROU1NEICZsdDs8YSBocmVmPSJtYWlsdG86ZG5zc2RAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj5kbnNzZEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFtk bnNzZF0gV0dMQyBmb3IgZHJhZnQtaWV0Zi1kbnNzZC1zcnA8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5IaSBETlNTRCBlbnRodXNpYXN0cyw8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoaXMg ZW1haWwgc3RhcnRzIGFuIG9mZmljaWFsIFdvcmtpbmcgR3JvdXAgTGFzdCBDYWxsIGZvciZuYnNw O2RyYWZ0LWlldGYtZG5zc2Qtc3JwLiBUaGlzIGNhbGwgYXNrcyB3aGV0aGVyIHdlIGJlbGlldmUg dGhlIGRvY3VtZW50IGlzIHJlYWR5IGZvciBwdWJsaWNhdGlvbi4gQXMgc3VjaCB3ZSBhcmUgYXNr aW5nIHR3bw0KIHF1ZXN0aW9uczo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjEpIGlmIHlvdSBiZWxpZXZlIHRoaXMgZG9jdW1lbnQgaXMg bm90IHJlYWR5IHRvIHB1Ymxpc2gsIHBsZWFzZSBzcGVhayB1cCBub3c8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjIpIGlmIHlvdSBoYXZl IHJlYWQgdGhlIGRvY3VtZW50IGFuZCB0aGluayBpdCBpcyByZWFkeSwgcGxlYXNlIHNheSBzbyBh cyB3ZWxsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj5Gb3IgdGhpcyBjYWxsIHRvIHN1Y2NlZWQsIHdlJ2xsIG5lZWQgc3RhdGVtZW50cyBv ZiBleHBsaWNpdCBzdXBwb3J0IGZyb20gcGVvcGxlIHdobyBoYXZlIHJlYWQgdGhlIGRyYWZ0LiBQ bGVhc2Ugc2VuZCBzdGF0ZW1lbnRzIGluIGVpdGhlciBkaXJlY3Rpb24gYXMgcmVzcG9uc2VzIHRv IHRoaXMgZW1haWwuIFRoaXMNCiBjYWxsIHdpbGwgYmUgb3BlbiB1bnRpbCAyMDIxLTA4LTE1IDIz OjU5IFVUQy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPlRoYW5rcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+RGF2aWQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRt bD4NCg== --_000_AM8P190MB0979F1E05706056DC1B950E5FDC09AM8P190MB0979EURP_-- From nobody Thu Aug 19 04:19:21 2021 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 411363A0C83 for ; Thu, 19 Aug 2021 04:19:10 -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, 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.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=iotconsultancy.nl 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 Ut4t5lVpLpLv for ; Thu, 19 Aug 2021 04:19:02 -0700 (PDT) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30111.outbound.protection.outlook.com [40.107.3.111]) (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 691E23A0C3E for ; Thu, 19 Aug 2021 04:19:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Oi9I8S7+fUW3kgw/wuw2EodY9XBbdm8HOk9aQqJda0T6w8raq8gxqCJ8ICc+rgoP8QCSp+KPLoP1i7cSwJRT8LTGm6eNMM7bjoz/gOd+LdfNxhUgwpI4eU4xTrsuzcSxLdALwWyMIFwy+PKN+o7yZ8BBYfNVAge2440e+DkCaJErzd8lMtDcCFTYyCFv0JoO6gsSA5ShSSzAW8EzqIcmYwoIXhLSU6j45KFGaEG8qXABtnZH+aH7tML3q8xf4XPBixQSpR+SNfNW3BoPZSleEqZaIZXtHcDjGaSlNSEcDi/4hBI/NKPxuE4jwZ4K1XcZEuPqG1DUhBhSKVtZxZNfsA== 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=wqvN6azP6KceWe5Fy+LCu2IeltRJ5w8ALsn1uwgkiZI=; b=QUu50cSrIdRmBi1yjOGQpG4E3X16qYcRMWtoleYGoSu2xI9KH29XxISGLCr0G1qadRcnCJOEjrCFkhoYHSJ3hcNuYE8wzbfrcTWpuql5WbDsx4mK2+2ZRicE/FmG2ovXuyPuw2oAF0C0FWOWRfCYS2eTSZUllCKbEXq8Lc0L3uZqCSM3zc0+BEB3ay9ZfCJ9OkaUXrWGGCM05LSdRWz4OeoAR8W2f0Wq85yhGCGvz054O3PdwwKP9TsxfLAlSCZbHG+HoQh9ImaERIMNAiuhw9jgc+r+KYzfVkmPIVS5yMD0bxKcC7lrd+WPk7IZys/EDSCipLP3KL7AtYKPZrR3Cw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=iotconsultancy.nl; dmarc=pass action=none header.from=iotconsultancy.nl; dkim=pass header.d=iotconsultancy.nl; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iotconsultancy.nl; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=wqvN6azP6KceWe5Fy+LCu2IeltRJ5w8ALsn1uwgkiZI=; b=sseD9s9zIv2SiryBwt30b1OzZKaA0iJsy4Up0rdLQmtVJ5ob/DfJmVOyWIjRYGSZ1dBV3C3ZyPExSQsr0Bnf4AEhL+/gTh+OkZhrfWx1UkBH/7zie4xALJxAhCW67QgV/1Xld7x9IBHzOOa9Mhc46slXzLYrjCVPDTK6wnkIvYU= Received: from AM8P190MB0979.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:1d3::8) by AM9P190MB1508.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:3ed::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4415.17; Thu, 19 Aug 2021 11:18:58 +0000 Received: from AM8P190MB0979.EURP190.PROD.OUTLOOK.COM ([fe80::44fa:5ced:a434:f7e8]) by AM8P190MB0979.EURP190.PROD.OUTLOOK.COM ([fe80::44fa:5ced:a434:f7e8%9]) with mapi id 15.20.4436.019; Thu, 19 Aug 2021 11:18:58 +0000 From: Esko Dijk To: DNSSD CC: Ted Lemon Thread-Topic: [dnssd] WGLC for draft-ietf-dnssd-srp / review Thread-Index: AdeU1hR5DMbuavatScqtDGs87zCR8gAFV4PA Date: Thu, 19 Aug 2021 11:18:58 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none; ietf.org; dmarc=none action=none header.from=iotconsultancy.nl; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: cf0e13f9-8ff2-427a-af7f-08d963032388 x-ms-traffictypediagnostic: AM9P190MB1508: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: iLHVv6NE6yBgwXF3Hgp0kIhQkIX+4G/avRtbpLXzHqew5nxM1jNW+pSapochQZfSoBr52Uee6o5cYyD0M/o7xvHXyoJmuwy3NIBQtprb9epOQenCzikbfFv+bYImJAXV0npjaRNRE5wLG/zu12X7xSqeS/pl6T1sNJvmzLELVVqUbMJYMNLf+DI9dAirHBoZFIF00KwInmGQzuXd6wjdw48BJmxAISLxHWF8P+3f6vNlcDymhXCeaT0/5czY8v79vbWrO4prza7pNyiNGKSOwLhU42MiFlI5k2JhEQHcl30dkbb1lx/xMku9mOeEUZZeXrwe8+ZujVpWp1VbZpyYU50Njsm2/4dr6QWFN+PyThQ5Zb2Hbkr0FygqJmW9c9ECzJSJrK+ELsCbcESj+kIFl1z00YKuZn5aPozRILCp8puQb8349JgfhRY90cvpV224FlkFKTlcALbH6LWjI+QVzxzrMubTyAIFrgCedL7nJ7OO9i8tboLpwtyYh4KA5Zhdb7MD75mAsjIfdMjMxfmcnqxwAFMaLAAVJyHu1q5moYCAaAqQuMny5aDiGJNzhTX6nU6r3szV0aicOeMXr+c/IX1c3X5NxYFT+9uu5iAadlJpBmPl+lXfz174P+LAzwuXlhIDuvVE+mn/LTiQz39Sa4XFaefwODgbiZNHKALGoN7b9hz6N493tO09gfQli7JK7c+H8WclOeMwOVnVUrDG0g== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM8P190MB0979.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(396003)(346002)(136003)(376002)(39830400003)(366004)(66476007)(66556008)(64756008)(66446008)(8936002)(86362001)(2940100002)(4001150100001)(53546011)(66946007)(8676002)(6916009)(6506007)(83380400001)(2906002)(52536014)(30864003)(7696005)(33656002)(76116006)(71200400001)(55016002)(9686003)(122000001)(316002)(4326008)(44832011)(38100700002)(508600001)(38070700005)(5660300002)(186003); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?SGxNWlJuZW1oaFo2UDNuRXh4a29kbW9waTBON1QvMHpEaGN2UlRMbFM1dGpX?= =?utf-8?B?Nk1iTC9ib0JSSVNJR3loVDFLc1Z6bzB6VVBScnBzUTBvamczVVpMOEZWVHE3?= =?utf-8?B?dFJoTE53b2YyOEVGK1U4UE5vL0RWem5uRXQ1M3RnUng4dXplMElueHhwV0Jj?= =?utf-8?B?TGV0QUkwV1MxeUNpUThwRGdkZGp6SXBVdDhGN2M2MDN3UWNhbG02WEl4UThH?= =?utf-8?B?eHIxaFNRZWQwUC9vRFV3Z2doZ1lkaXJGTTRGY1lRUWVucmRoc3Q1MGFtQUt0?= =?utf-8?B?TEdJN05CdVUzMExCYWF1aFRmWDBibjB1b1Q0amVOMVI0dGx1KzZtY2xJWUVX?= =?utf-8?B?QVFxa0dtdktvUHlkZHZDa3duYWJJMHNpTkd2TUd4RkJsSEQvS0FYQkdNbjBh?= =?utf-8?B?TzUwZmhHWHJHNGJDVWlMMjF5VDV1cElKc3kzQkduSk1pZkMxOCt3YUZTNVdC?= =?utf-8?B?dUlaWW9Oazc1UDRhSFJDZ1REdWR3NE5SS3FPWCtUN0wyODVLMVRwSlE5TTZD?= =?utf-8?B?K29MTkhZM1dRZC9RdXZyR3R2eHhQZGRMakU1VlVTUEhvR3B2aVU1V21sdGJy?= =?utf-8?B?WExxRGJqYjE4ZWV2SG8zMWg2SytMazBRMUp2MnI4d0xpeXp1b0lOMDhjTEM2?= =?utf-8?B?VEQyOXhvaDdlLzkxSzdLd2RYRVg3cTRqMFVQZGVoNTV3KzRsR3c3Wk94ckVD?= =?utf-8?B?NENGU0VSbWdreXpTRW11ZXRWWUJEWnY5L2JNM2QwR0FLbDE3eGNrUVRyc2hl?= =?utf-8?B?S0NENjEzMDhJdzVxVmJQWUdPaTRUSWgyMXMrbG82clpMdnNrM05RekNiNnRL?= =?utf-8?B?TE9WeHdDdEhSSlZjanFoa0hUelQxWmhGMThjNmV1VDc0K0YybEVOeFI5eGJI?= =?utf-8?B?ZnBLOFV1K3JlT3oxaisrNGNXNUtKTUQxLzVxMStndW9obWlqdWhyVTFqbnVm?= =?utf-8?B?VTFKcWIyeDJKeTA4SEtJaHk4UTU4dDhSV2lvbGp5U0tJNkVCendtcklVa0Fo?= =?utf-8?B?RFUyMUl1UXFTdEpQTUljcHZRQmZaOVljbVRhVWpNdTFGK0F4bFN5a1N1UWN4?= =?utf-8?B?Mk5WZWxHb1A1dmdYdnpBei9sTFRYVkR3a2ZUd0xCbDRzTmExamdpWk9SMVd3?= =?utf-8?B?bWtlU1ZMc2xlVm1tclNHVXp1SVB5c3BIbjZ6UE01TUZKL1dJbWRtVUxieS95?= =?utf-8?B?QTRRWGlQTXd5U0ZRNTZZbTg0dXJDUEFiaDMyRFowTG1oTGk2UVpDa2lFSjll?= =?utf-8?B?dUMwOTdha0VSajAwc093blFjU3dmMzhpWXZVNDJUVjJIcmtrZmxvV2ZQRnhl?= =?utf-8?B?UkZTODgyL1NsU0JKQ2ZDc2hoWFNtV3Z2cElYaWsrcHEzbi94VlRiaUxhYStj?= =?utf-8?B?RHlZc3E5SGJweHgzK29BR3pzSlJhVDQyaHhpSitkb2cwamhvdElLWTVKUVNP?= =?utf-8?B?TlpRZW9uMkdWVFJOM2RCNUx6WE9NSHFORFRMcW5Od2RUMVFGZzVXNlJDUU9y?= =?utf-8?B?Sm9WaVlyWitEOHpxalRTZzM2UjNQVzhHVGNtanE1a2VSM1BEZDNpdGJ1clds?= =?utf-8?B?TzA2R1A1amZEN1Q3YStySXI3QndOVVI0c3JxamM3WDFzMlYrNVUrRERsMktk?= =?utf-8?B?TDY5aG1iSTBBQi91ZjRqZHpwVWhCcXlscW9MZXdVRjlaRWFsN3c4Qzh6RUIz?= =?utf-8?B?MDFoVHV5VXNJOGlOZnE5NDM3M3YySEY2UE1MK2ZWcE83NUV3ZmN4eUk4VWtY?= =?utf-8?B?REpQSng4eEpwQUZVUVBueGp1TDFkSCtnd0YwdzJERWxNc0U1bnVzL0ZrT0dI?= =?utf-8?B?d0c2aG0zOE1Ga1p0eXlPdkRmS0Q2UzVPbTVwUC9QYlBNYUpCM2ZVZEZhKzN5?= =?utf-8?Q?koF9BNZhis1jl?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_AM8P190MB0979C97C6F267BD5E1720A7BFDC09AM8P190MB0979EURP_" MIME-Version: 1.0 X-OriginatorOrg: iotconsultancy.nl X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM8P190MB0979.EURP190.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: cf0e13f9-8ff2-427a-af7f-08d963032388 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Aug 2021 11:18:58.1569 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 58bbf628-15d2-46bc-820b-863b6774d44b X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: gcTnahrCt+YOWT4TGU9j6X0e6n0hju9AF7EpduIaY9Bk2Nqy+ZBGcUIO5fWFsNAUXqHAQjmVS1OmZ8JmLIG6d4H84awZWhwao1dgFVqxONU= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9P190MB1508 Archived-At: Subject: Re: [dnssd] WGLC for draft-ietf-dnssd-srp / review X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2021 11:19:20 -0000 --_000_AM8P190MB0979C97C6F267BD5E1720A7BFDC09AM8P190MB0979EURP_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UFMgb25lIGZpbmFsIHJldmlldyBxdWVzdGlvbiBJIGZvcmdvdCB0byBpbmNsdWRlOg0KDQpXaGF0 IGRvIHRoZSBhdXRob3JzIC8gV0cgdGhpbmsgYWJvdXQgcmVnaXN0ZXJpbmcgdGhlIG5hbWUgZm9y IHRoZSBVRFAtYmFzZWQgU1JQIHNlcnZlciwgaS5lLiAiX2Ruc3NkLXNycC5fdWRwLjxkb21haW4+ LiIgPw0KSSB3cm90ZSBzb21lIHJlYXNvbnMgaW4gbXkgZW1haWwgb2YgMjAyMC0xMS0wMyB3aHkg dGhpcyBjb3VsZCBiZSB1c2VmdWwgYnV0IHRoaXMgYXNwZWN0IHdhc27igJl0IGRpc2N1c3NlZCBz byBmYXIuICBJbiBhbnkgY2FzZSBJ4oCZbSBmaW5lIGFsc28gdG8gbm90IGFkZCB0aGlzIGVudHJ5 IHRvIHRoZSByZWdpc3RlcmVkIHNlcnZpY2UgbmFtZXMuIChJZiB0aGUgaW50ZW50IGlzIHJlYWxs eSB0byBoYXZlIGEgVENQLW9ubHkgU1JQKQ0KDQpFc2tvDQoNCkZyb206IGRuc3NkIDxkbnNzZC1i b3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgRXNrbyBEaWprDQpTZW50OiBUaHVyc2RheSwg QXVndXN0IDE5LCAyMDIxIDEzOjA1DQpUbzogRE5TU0QgPGRuc3NkQGlldGYub3JnPg0KQ2M6IFRl ZCBMZW1vbiA8bWVsbG9uQGZ1Z3VlLmNvbT4NClN1YmplY3Q6IFJlOiBbZG5zc2RdIFdHTEMgZm9y IGRyYWZ0LWlldGYtZG5zc2Qtc3JwIC8gcmV2aWV3DQoNCkhlbGxvLA0KDQpIZXJlIG15IHJlc3Bv bnNlIHRvIHRoZSBXR0xDIGZvciBkcmFmdC1pZXRmLWRuc3NkLXNycCBhY2NvbXBhbmllZCBieSBy ZXZpZXcgY29tbWVudHMgZm9yIHRoZSBkcmFmdC4NCkluIHN1bW1hcnksIEkgYmVsaWV2ZSB0aGUg ZG9jdW1lbnQgYXBhcnQgZnJvbSBTZWN0aW9uIDUgaXMgcmVhZHkgdG8gYmUgcHVibGlzaGVkIGFm dGVyIHRoZSByZXZpZXcgY29tbWVudHMgYXJlIGFkZHJlc3NlZDogYXMgdGhlc2UgY29tbWVudHMg YXJlIG1vc3RseSBvbiBlZGl0b3JpYWwgaXNzdWVzLCB0ZXh0IGxvY2F0aW9uIGFuZCByZXNvbHZp bmcgcG90ZW50aWFsIHVuY2xhcml0aWVzLiBUaGUgU1JQIHByb3RvY29sIG92ZXJhbGwgbG9va3Mg dXNlZnVsLCBzb2xpZCBhbmQgd2VsbC1kZXNjcmliZWQuDQoNClRoZSBzcGVjaWZpYyBwYXJ0IG9m IFNlY3Rpb24gNSBvbiBTbGVlcCBQcm94eSBoYXMgaGFkIGxlc3Mgd29yayBpdCBzZWVtcywgYXMg YSBmZXcgb2YgbXkgb3JpZ2luYWwgLTA0IHJldmlldyBjb21tZW50cyBhcmUgc3RpbGwgb3BlbiBh bmQgSSBkb27igJl0IHNlZSBob3cgdGhpcyBmdW5jdGlvbiBjb3VsZCBsZWFkIHRvIGludGVyb3Bl cmFibGUgaW1wbGVtZW50YXRpb25zLiBUbyByZXNvbHZlIHRoaXMsIHBvc3NpYmxlIGFjdGlvbnMg YXJlOg0KDQogIDEuICBNb3ZlIHRoZSBTbGVlcCBQcm94eSBkZWZpbml0aW9uL2RldGFpbHMgb3V0 IG9mIHRoaXMgZHJhZnQsIGludG8gYSBzZXBhcmF0ZSBvbmUuIFRoaXMgY291bGQgcHJvZ3Jlc3Mg U1JQIGluIHRoZSBiZXN0IHdheS4NCiAgMi4gIEFkZCBtb3JlIGRldGFpbHMgb24gdGhlIFNsZWVw IFByb3h5LCB0byBhIGZ1bGx5IGludGVyb3BlcmFibGUgaW1wbGVtZW50YXRpb24gYmVjb21lcyBw b3NzaWJsZS4NCiAgMy4gIEtlZXAgY3VycmVudCBTZWN0aW9uIDUgdGV4dCAob25seSBtaW5vciBh ZGRpdGlvbnMvY2hhbmdlcy9maXhlcyksIGFuZCBhZGQgYSBzZW50ZW5jZSBzYXlpbmcgdGhhdCBt b3JlIGRldGFpbHMgY2FuIGJlIGRlZmluZWQgaW4gYSBmdXR1cmUgZG9jdW1lbnQgKGUuZy4gYWZ0 ZXIgaW1wbGVtZW50YXRpb25zIGhhdmUgYmVlbiB0ZXN0ZWQg4oCTIGNsaWVudHMgdnMgc2VydmVy cyBvZiBkaWZmZXJlbnQgcGFydGllcykNClJlbGF0ZWQgcXVlc3Rpb246IGFyZSBhbnkgaW1wbGVt ZW50YXRpb25zIHVzaW5nIFNsZWVwIFByb3h5Pw0KDQpCZXN0IHJlZ2FyZHMNCkVza28NCg0KRGV0 YWlsZWQgcmV2aWV3IGNvbW1lbnRzIGxpc3Q6DQoNCioqKiBBYnN0cmFjdA0KODAyLjExIChXaS1G aSkgYW5kIDgwMi4xNS40IChJb1QpIG5ldHdvcmtzDQotPiBhZGQgJ0lFRUUnIHNvICJJRUVFIDgw Mi4xMSAoV2ktRmkpIGFuZCA4MDIuMTUuNCAoSW9UKSBuZXR3b3JrcyINCkFzIGFuIGVkaXRvcmlh bCBjb21tZW50LCBpbiBnZW5lcmFsIHRoZSBhYnN0cmFjdCBzaG91bGQgbm90IGNvbnRhaW4gbW9y ZSBkZXRhaWxzIHRoYW4gdGhlIG1haW4gdGV4dC4NClNvIHR5cGljYWxseSBvbmUgd291bGQgc2Vl IGJhY2sgdGhlc2UgdGVybXMgYWdhaW4gaW4gYW4gaW50cm9kdWN0aW9uLg0KDQoqKiogMi4yLjEN CiJSRkMgNjc2MyBkZXNjcmliZXMgdGhlIGRldGFpbHMgb2Ygd2hhdCBlYWNoIG9mIHRoZXNlIHR5 cGVzIG9mIHVwZGF0ZXMgY29udGFpbnMiDQotPiBub3QgZXZlcnl0aGluZyBjb250YWluZWQgaW4g dGhlc2UgdXBkYXRlcyBpcyBleHBsYWluZWQgaW4gUkZDIDY3NjMuIFNwZWNpZmljYWxseSwgdGhl ICJLZXkgUlIiIGlzIG5vdCBpbiB0aGF0IFJGQy4gQW5vdGhlciBSRkMgcmVmIGNhbiBiZSBhZGRl ZCBoZXJlIHRoYXQgZGVmaW5lcyBLZXkgUlIgYXMgZGVmaW5pdGl2ZSBzb3VyY2Ugb2YgaW5mb3Jt YXRpb24uDQoNCioqKiAyLjIuMy4xDQoiU1JQIGNsaWVudHMgYXJlIGFsbG93ZWQgdG8gc2VuZCB1 cGRhdGVzIHRvIHRoZSBnZW5lcmljIGRvbWFpbiAiZGVmYXVsdC5zZXJ2aWNlLmFycGEiIg0KLT4g SW4gc2VjdGlvbiAyLjEuKiBpdCBsb29rcyBhcyBpZiBvbmx5IGNvbnN0cmFpbmVkIGhvc3RzIGNh biBkbyB0aGlzLiBDYW4gZnVsbC1mZWF0dXJlZCBob3N0cyBhbHNvIGRvIHRoaXM/IElmIG5vdCB3 ZSBjYW4gc2F5ICJDb25zdHJhaW5lZC1Ob2RlIFNSUCBjbGllbnRzIGFyZSAuLi4iICAgSWYgeWVz LCB0aGVuIEkgd291bGQgZXhwZWN0IHNlY3Rpb24gMi4xLjEgdG8gbWVudGlvbiB0aGlzIHVzZSBm b3IgdGhlIGZ1bGwtZmVhdHVyZWQgaG9zdHMuDQoNCioqKiAyLjIuNS4xDQpkdXBsaWNhdGVkIHNl bnRlbmNlICJUaGlzIGtleSBwYWlyIE1VU1QgYmUgdW5pcXVlIHRvIHRoZSBkZXZpY2UuIg0KDQoq KiogMi4yLjUuNA0KRG9lcyB0aGUgc3RhdGVtZW50IGhlcmUgaW1wbHkgdGhhdCB0aGlzIGRyYWZ0 IGZvcm1hbGx5IHVwZGF0ZXMgUkZDIDI3ODI/DQooUXVlc3Rpb24gdG8gdGhlIFdHLiBNYXliZSBu b3Q6IHNpbmNlIHRoZSB1cGRhdGUgb25seSBhcHBsaWVzIGluIFNSUCBjb250ZXh0IG5vdCBmb3Ig U1JWIHJlY29yZHMgaW4gZ2VuZXJhbC4gQnV0IG1heWJlIHllczogUkZDIDI3ODIgc2F5cyAiVW5s ZXNzIGFuZCB1bnRpbCBwZXJtaXR0ZWQgYnkgZnV0dXJlIHN0YW5kYXJkcyBhY3Rpb24sIG5hbWUg Y29tcHJlc3Npb24gaXMgbm90IHRvIGJlIHVzZWQgZm9yIHRoaXMgZmllbGQuIiB3aGljaCB3b3Vs ZCBtYWtlIGl0IHByb3BlciB0byByZWZlciB0byB0aGUgU1JQIGRyYWZ0IGFzIHN1Y2ggZnV0dXJl IGFjdGlvbi4pDQoNCioqKiAyLjIuNS41LjINCiJ1cGRhdGUgdGhhdCBkZWxldGVzIHRoZSBQVFIg cmVjb3JkIHdob3NlIHRhcmdldCBpcyB0aGUgc2VydmljZSBpbnN0YW5jZSBuYW1lLiINCi0+IFRo aXMgbG9va3MgbGlrZSBhIHNpbmdsZSBQVFIgcmVjb3JkLiBQcmlvciBzZWN0aW9uIDIuMi4xIG1l bnRpb25zIHRoYXQgdGhlIHNlcnZpY2UgaW5zdGFuY2UgbmFtZSBtYXkgYmUgcmVmZXJyZWQgdG8g YnkgbXVsdGlwbGUgUFRSIHJlY29yZHMuICBTbyBpbiBjYXNlIG9mIG11bHRpcGxlLCBpdCBpcyBu b3QgcmVxdWlyZWQgdG8gaGF2ZSBtdWx0aXBsZSBpbnN0cnVjdGlvbnMgdG8gZGVsZXRlIHRoZXNl IG11bHRpcGxlIFBUUiByZWNvcmRzPw0KKEkuZS4gdGhlcmUncyBubyByaXNrIG9mIGxpbmdlcmlu ZyBQVFIgcmVjb3JkcyB0aGF0IHdvdWxkIHBvaW50IHRvIGEgc2VydmljZSBpbnN0YW5jZSB0aGF0 J3MgZGVsZXRlZD8pDQoNCioqKiAyLjMgdGl0bGUNCltOaXRdIC0+IG1heSBnaXZlIHRoZSBpbXBy ZXNzaW9uIHRoYXQgYWxsIFNSUCBzZXJ2ZXIgYmVoYXZpb3IgaXMgc3BlY2lmaWVkIGluIGhlcmUu DQpTb21ld2hlcmUgaW4gMi4zIC8gMi4zLiogaXQgY291bGQgbWVudGlvbiB0aGF0IG1vcmUgbm9y bWF0aXZlIGJlaGF2aW9yIGlzIHNwZWNpZmllZCBpbiBvdGhlciBzZWN0aW9ucyB0b28sIGxpa2Ug U2VjdGlvbnMgMyBhbmQgNC4NCg0KKioqIDIuMy4xDQpHcmFtbWFyIHRvIGJlIGZpeGVkOiAiRWFj aCBpbnN0cnVjdGlvbiBjb25zaXN0cyBzb21lIGNvbWJpbmF0aW9uIg0KDQoqKiogMi4zLjEuMQ0K ImlmIHRoZSBTZXJ2aWNlIERpc2NvdmVyeSB1cGRhdGUgaXMgYW4gIkFkZCB0byBhbiBSUlNldCIg aW5zdHJ1Y3Rpb24sIHRoZSBTZXJ2aWNlIERlc2NyaXB0aW9uIEluc3RydWN0aW9uIGRvZXMgbm90 IG1hdGNoIGlmIg0KLT4gZm9yIG1lIHVuY2xlYXIsIHNlZSBzZXBhcmF0ZSBtYWlsIHRocmVhZCBv biB0aGlzIHNlY3Rpb24uDQoNCioqKiAyLjMuMS4yDQpbTml0XSBCdWxsZXQ6DQoiKiAgU2Vydmlj ZSBEZXNjcmlwdGlvbnMgSW5zdHJ1Y3Rpb25zIGRvIG5vdCBtb2RpZnkgYW55IG90aGVyIFJScy4i DQotPiBiZXN0IHJlcGhyYXNlZCB0bw0KICIqICBubyBSUiB1cGRhdGVzIG90aGVyIHRoYW4gdGhl IG9uZXMgZGVmaW5lZCBhYm92ZS4iDQoNClRoYXQgd291bGQgZml0IGJldHRlciBpbiB0aGUgc3R5 bGUgb2YgdGhlIHByZXZpb3VzIGJ1bGxldCBwb2ludHMgaW4gdGhlIGxpc3QuDQoNCioqKiAyLjMu MS4zDQoiSWYgYSBsaW5rLXNjb3BlIGFkZHJlc3Mgb3IgSVB2NCBhdXRvY29uZmlndXJhdGlvbiBh ZGRyZXNzIGlzIHByb3ZpZGVkIGJ5IHRoZSBTUlAgY2xpZW50LCB0aGUNCiAgU1JQIHNlcnZlciBN VVNUIHRyZWF0IHRoaXMgYXMgaWYgbm8gYWRkcmVzcyByZWNvcmRzIHdlcmUgcmVjZWl2ZWQ7IHRo YXQgaXMsIHRoZSBIb3N0IERlc2NyaXB0aW9uIGlzIG5vdCB2YWxpZC4iDQotPiBUaGlzIHNlZW1z IHJhdGhlciBzdHJpY3QuIElmIHRoZSBjbGllbnQgcHJvdmlkZXMgMSByb3V0YWJsZSBJUCBhZGRy ZXNzIGFuZCAxIGxpbmstbG9jYWwgYWRkcmVzcywgY291bGRuJ3QgdGhlIFNSUCBzZXJ2ZXIganVz dCBpZ25vcmUgdGhlIGxpbmstbG9jYWwgYWRkcmVzcz8NClRoaXMgbWlnaHQgaGF2ZSBzb21lIGJl bmVmaXRzIGZvciBmdXR1cmUvYmFja3dhcmRzIGNvbXBhdGliaWxpdHkgLCBpbiBjYXNlIG9mIGZ1 dHVyZSBjYXNlcyB3aGVyZSBsaW5rLWxvY2FsIGFkZHJlc3NlcyBhcmUgdG8gYmUgdXNlZCBmb3Ig c29tZSByZWFzb24uIChJZiBvbmx5IGZvciBkZWJ1Zy9kaWFnbm9zdGljIHB1cnBvc2VzKQ0KSSBh Z3JlZSB0aGF0IGlmIHRoZSBjbGllbnQgc2VuZHMgb25seSBsaW5rLWxvY2FsIGFkZHJlc3MoZXMp IHRoZW4gdGhlIFNSUCBzZXJ2ZXIgdHJlYXRzIGl0IGFzIGlmIG5vIGFkZHJlc3MgcmVjb3JkcyB3 ZXJlIHJlY2VpdmVkLg0KDQoqKiogMi4zLjINCltOaXRdICJtdXN0IGhhdmUgdGhhdCBIb3N0IERl c2NyaXB0aW9uIGluc3RydWN0aW9uIGFzIHRoZSB0YXJnZXQgb2YgaXRzIFNSViByZWNvcmQiDQot PiBjb3VsZCByZXBocmFzZSB0byAiTVVTVCBoYXZlIHRoZSBob3N0bmFtZSBvZiB0aGF0IEhvc3Qg RGVzY3JpcHRpb24gSW5zdHJ1Y3Rpb24gYXMgdGhlIHRhcmdldCBvZiBpdHMgU1JWIHJlY29yZCIg IHRvIGJlIG1vcmUgcHJlY2lzZS4NClNpbWlsYXIgY29tbWVudHMgY2FuIGJlIGdpdmVuIGZvciB0 aGUgcmVtYWluZGVyIG9mIHRoZSBzZWN0aW9uIHRleHQgdGhhdCB0YWxrcyBhYm91dCBpbnN0cnVj dGlvbnMgcG9pbnRpbmcgdG8gaW5zdHJ1Y3Rpb25zLiAgKEl0J3MgbW9yZSBsaWtlIG5hbWVzIGlu IGluc3RydWN0aW9ucyBiZWluZyBlcXVhbCB0byBuYW1lcyB0aGF0IGFyZSB1c2VkIGluIG90aGVy IGluc3RydWN0aW9ucykNCihub3Qgc3VyZSBpZiBNVVNUIG9yIG11c3QgaXMgZGVzaXJlZCBoZXJl IGJ5IHRoZSB3YXkpDQoNCiJGb3IgZXhhbXBsZSwgYSBETlMgdXBkYXRlIHRoYXQgY29udGFpbnMg YW4gUlJzZXQNCiAgIEFkZCB0byBhIFNlcnZpY2UgTmFtZSBhbmQgYW4gUlJzZXQgQWRkIHRvIGEg U2VydmljZSBJbnN0YW5jZSBOYW1lLA0KICAgd2hlcmUgdGhlIFNlcnZpY2UgTmFtZSBkb2VzIG5v dCByZWZlcmVuY2UgdGhlIFNlcnZpY2UgSW5zdGFuY2UgTmFtZSwNCiAgIGlzIG5vdCBhIHZhbGlk IFNSUCB1cGRhdGUgbWVzc2FnZSINCi0+ICdSUnNldCBBZGQnIHJlZmVycyBwcm9iYWJseSB0byB0 aGUgIkFkZCBUbyBBbiBSUnNldCIgc2VtYW50aWNzIG9mIFJGQyAyMTM2PyBJZiBzbyBpdCB3b3Vs ZCBiZSBnb29kIHRvIHVzZSB0aGF0IGV4YWN0IHNhbWUgbmFtaW5nICJBZGQgVG8gQW4gUlJzZXQi IGluY2x1ZGluZyB0aGUgcXVvdGVzIGhlcmUuDQpXaXRoIHByZXNlbnQgdGV4dCBJJ20gd29uZGVy aW5nIGlmIEkgbWlzc2VkIHNvbWV0aGluZyBpbiB0aGUgRE5TIHNwZWNzIHRoYXQncyBjYWxsZWQg IlJSc2V0IEFkZCIuDQoNCioqKiAyLjMuMw0KIklmIGFueSBleGlzdGluZyBLRVkgcmVjb3JkIGNv cnJlc3BvbmRpbmcgdG8gYQ0KICAgS0VZIHJlY29yZCBpbiB0aGUgU1JQIFVwZGF0ZSBkb2VzIG5v dCBtYXRjaCB0aGUgS0VZIHNhbWUgcmVjb3JkIGluDQogICB0aGUgU1JQIFVwZGF0ZSAiDQotPiBn cmFtbWFyIGlzc3VlLiAnbWF0Y2ggdGhlIEtFWSBzYW1lIHJlY29yZCcgICAgQW5kIGEgYml0IGNv bmZ1c2luZzogY2FuIGEgS0VZIHJlY29yZCBpbiBhbiB1cGRhdGUgY29ycmVzcG9uZCB0byBhIHN0 b3JlZCBLRVkgcmVjb3JkIGJ1dCBub3QgbWF0Y2ggYXQgdGhlIHNhbWUgdGltZT8NCiAgUGVyaGFw cyB0aGUgJ25hbWUnIGNvbmNlcHQgc2hvdWxkIGJlIGludHJvZHVjZWQgaGVyZSB0byBjbGFyaWZ5 LiAoUHJlc3VtYWJseSB0aGUgc2VydmVyIHdpbGwgY2hlY2sgaWYgYW4gZXhpc3RpbmcgU2Vydmlj ZSBJbnN0YW5jZSBOYW1lIG9yIGV4aXN0aW5nIEhvc3RuYW1lIGlzIHN0b3JlZCBhbmQgbG9vayB1 cCB0aGUgYXNzb2NpYXRlZCBLRVkgZm9yIHRoYXQuKQ0KDQoiS0VZIHJlY29yZCB1cGRhdGVzIG9t aXR0ZWQgZnJvbSBTZXJ2aWNlIERlc2NyaXB0aW9uIHVwZGF0ZSBhcmUNCiAgIHByb2Nlc3NlZCBh cyBpZiB0aGV5IGhhZCBiZWVuIGV4cGxpY2l0bHkgcHJlc2VudDogZXZlcnkgU2VydmljZQ0KICAg RGVzY3JpcHRpb24gdGhhdCBpcyB1cGRhdGVkIE1VU1QsIGFmdGVyIHRoZSB1cGRhdGUsIGhhdmUg YSBLRVkgUlIsDQogICBhbmQgaXQgbXVzdCBiZSB0aGUgc2FtZSBLRVkgUlIgdGhhdCBpcyBwcmVz ZW50IGluIHRoZSBIb3N0DQogICBEZXNjcmlwdGlvbiB0byB3aGljaCB0aGUgU2VydmljZSBEZXNj cmlwdGlvbiByZWZlcnMuIg0KLT4gQ2FuIHdlIHJlcGxhY2UgaGVyZSAnU2VydmljZSBEZXNjcmlw dGlvbiB1cGRhdGUnIGJ5ICdTZXJ2aWNlIERlc2NyaXB0aW9uIEluc3RydWN0aW9uJyA/DQpFLmcu DQoiS0VZIHJlY29yZCB1cGRhdGVzIG9taXR0ZWQgZnJvbSBTZXJ2aWNlIERlc2NyaXB0aW9uIElu c3RydWN0aW9ucyBhcmUNCiAgIHByb2Nlc3NlZCBhcyBpZiB0aGV5IGhhZCBiZWVuIGV4cGxpY2l0 bHkgcHJlc2VudDogZXZlcnkgU2VydmljZQ0KICAgRGVzY3JpcHRpb24gdGhhdCBpcyB1cGRhdGVk IHRocm91Z2ggYSBTZXJ2aWNlIERlc2NyaXB0aW9uIEluc3RydWN0aW9uIE1VU1QsIGFmdGVyIHRo ZSB1cGRhdGUsIGhhdmUgYSBLRVkgUlIsDQogICBhbmQgaXQgbXVzdCBiZSB0aGUgc2FtZSBLRVkg UlIgdGhhdCBpcyBwcmVzZW50IGluIHRoZSBIb3N0DQogICBEZXNjcmlwdGlvbiBJbnN0cnVjdGlv biB0byB3aGljaCB0aGUgU2VydmljZSBEZXNjcmlwdGlvbiBJbnN0cnVjdGlvbiByZWZlcnMuIg0K DQoiT3RoZXJ3aXNlLCB0aGUgc2VydmVyIHZhbGlkYXRlcyB0aGUgU1JQIFVwZGF0ZSB1c2luZyBT SUcoMCkgb24gdGhlDQogICBwdWJsaWMga2V5IGluIHRoZSBLRVkgcmVjb3JkIG9mIHRoZSBIb3N0 IERlc2NyaXB0aW9uIHVwZGF0ZS4iDQotPiB3aGF0IGFib3V0Og0KIk90aGVyd2lzZSwgdGhlIHNl cnZlciB2YWxpZGF0ZXMgdGhlIFNSUCBVcGRhdGUgdXNpbmcgU0lHKDApIGFnYWluc3QgdGhlDQog ICBwdWJsaWMga2V5IGluIHRoZSBLRVkgcmVjb3JkIG9mIHRoZSBIb3N0IERlc2NyaXB0aW9uIElu c3RydWN0aW9uLiINCg0KKFVzaW5nICdJbnN0cnVjdGlvbicgYW5kICd2YWxpZGF0ZXMgWCBhZ2Fp bnN0IFknIGluc3RlYWQgb2YgJ3ZhbGlkYXRpb25zIFggb24gWScgKQ0KDQoqKiogMw0KIlNSUCB1 cGRhdGUgc2VydmVycyBNVVNUIGNoZWNrIg0KLT4iU1JQIHNlcnZlcnMgTVVTVCBjaGVjayINCg0K KioqIDQuMQ0KW05pdF0gIiBNVVNUIGJlIHJlbW92ZWQgYXQgdGhlIHNhbWUgdGltZS1pdCBpcyBu ZXZlciB2YWxpZCBmb3IgYSBzZXJ2aWNlIg0KLT4gIiBNVVNUIGJlIHJlbW92ZWQgYXQgdGhlIHNh bWUgdGltZSAtLSBpdCBpcyBuZXZlciB2YWxpZCBmb3IgYSBzZXJ2aWNlICIgb3INCi0+ICIgTVVT VCBiZSByZW1vdmVkIGF0IHRoZSBzYW1lIHRpbWU6IGl0IGlzIG5ldmVyIHZhbGlkIGZvciBhIHNl cnZpY2UgIg0KDQozcmQgcGFyYWdyYXBoIG1lbnRpb25zIHRoYXQgYSBTUlAgaXMgYnkgZGVmYXVs dCBjb25maWd1cmVkIHdpdGggYSAyIGhvdXIgTGVhc2UgbGltaXQgYW5kIDE0LWRheSBLRVkgcmV0 YWluaW5nIHRpbWUgbGltaXQ7IGFuZCB0aGVuIGl0IHNheXMgdGhhdCBjb25zdHJhaW5lZCBkZXZp Y2VzIG1heSBuZWdvdGlhdGUgbG9uZ2VyIGxlYXNlcy4gVGhpcyBsb29rcyBpbmNvcnJlY3QsIGFz IGxlYXNlcyBiZXlvbmQgY29uZmlndXJlZCB1cHBlciBsaW1pdHMgd29uJ3QgYmUgZ2l2ZW4gYnkg dGhlIHNlcnZlci4NClByb2JhYmx5IHNvbWV0aGluZyBlbHNlIGlzIG1lYW50IGhlcmUgd2l0aCAn bmVnb3RpYXRlJz8gRm9yIGV4YW1wbGUgaWYgb25lIGNvbmZpZ3VyZXMgJ2RlZmF1bHQgdmFsdWVz JyBmb3IgTGVhc2UgYW5kIEtleS1MZWFzZSBpbiB0aGUgc2VydmVyLCB0aGUgc2VydmUgbWF5IGV4 dGVuZCB0byB0aGVzZSBkZWZhdWx0IHZhbHVlcyBpZiB0aGUgY2xpZW50IGFza3MgZm9yIHNvbWV0 aGluZyBzaG9ydGVyLiBJZiB0aGUgY2xpZW50IGFza3MgZm9yIHNvbWV0aGluZyBsb25nZXIgdGhh biB0aGUgJ2RlZmF1bHQgdmFsdWVzJywgdGhlIHNlcnZlciBncmFudHMgdGhlIGxvbmdlciB2YWx1 ZXMgdXAgdG8gYSBoYXJkIGxpbWl0IHRoYXQgaXMgYWxzbyBjb25maWd1cmVkIGluIHRoZSBzZXJ2 ZXIuDQoNCioqKiA1IFNsZWVwIFByb3h5DQpUaGUgaW50cm9kdWN0aW9uIHRleHQgc2hvdWxkIGNs YXJpZnkgd2hldGhlciBTbGVlcCBQcm94eSBzdXBwb3J0IGZvciBhbiBTUlAgc2VydmVyIGlzIE9Q VElPTkFMIG9yIE1BTkRBVE9SWS4NCkFsc28gdG8gbWFrZSBtb3JlIGNsZWFyIHRoYXQgZm9yIGNs aWVudHMgdGhlIHVzZSBvZiB0aGlzIGZ1bmN0aW9uIGlzIG9wdGlvbmFsL09QVElPTkFMLiAoVGhl IGxhc3QgcGFyYWdyYXBoIHNheXMgc28gZm9yIGNvbnN0cmFpbmVkIGhvc3RzLCBidXQgbm90aGlu ZyBmb3IgdGhlIGZ1bGwtZmVhdHVyZWQgaG9zdHMuKQ0KDQpJbiByZWxhdGlvbiB0byBhYm92ZSwg dGhlIHNhbWUgcXVlc3Rpb25zIGZyb20gbXkgcmV2aWV3IG9mIC0wNCBvZiAyMDIwLTEwLTEzIHN0 aWxsIGFwcGx5Og0KLSBIb3cgd291bGQgYSBzZXJ2aWNl4oCZcyBob3N0IGtub3cgdGhhdCB0aGUg c2VydmVyIGlzIGNhcGFibGUgdG8gZG8gdGhpcz8gSWYgaXQgZG9lc24ndCBrbm93IHRoZW4gaXQg Y2Fubm90IHRydXN0IHRoZSBtZWNoYW5pc20gdG8gd29yayBhbmQgZ28gdG8gc2xlZXAuDQotIE9y LCBpcyB0aGVyZSBhIHdheSBmb3IgdGhlIFNSUCBzZXJ2ZXIgdG8gcmVqZWN0IGFuIHVwZGF0ZSB3 aXRoIEVETlMoMCkgT1dORVIgb3B0aW9uIHN1Y2ggdGhhdCB0aGUgc2VydmljZeKAmXMgaG9zdCBr bm93cyBub3QgdG8gdXNlIGl0IGFnYWluPw0KDQpbTml0XSAiQW5vdGhlciB1c2Ugb2YgU1JQIGlz IGZvciBkZXZpY2VzIHRoYXQgc2xlZXAgdG8gcmVkdWNlIHBvd2VyIGNvbnN1bXB0aW9uIg0KLT4g aWRlYWxseSBpdCBzaG91bGQgbWVudGlvbiBzb21ld2hlcmUgdGhhdCB0aGUgZGV2aWNlIHRoYXQg c2xlZXBzIGlzIGFuIFNSUCBjbGllbnQuIE90aGVyd2lzZSB0aGUgc3RhdGVtZW50IGlzIGEgYml0 IHRvbyBnZW5lcmljLiBFLmcuDQoiQW5vdGhlciB1c2Ugb2YgU1JQIGlzIGZvciBTUlAgY2xpZW50 IGRldmljZXMgdGhhdCBzbGVlcCB0byByZWR1Y2UgcG93ZXIgY29uc3VtcHRpb24sIHdoaWxlIGJl aW5nIGFibGUgdG8gb2ZmZXIgcmVnaXN0ZXJlZCBzZXJ2aWNlKHMpIHdpdGhvdXQgaW50ZXJydXB0 aW9uLiINCg0KInRoZSBkZXZpY2UgaW5jbHVkZXMgYW4gRUROUygwKSBPV05FUiBPcHRpb24gW0kt RC5jaGVzaGlyZS1lZG5zMC1vd25lci1vcHRpb25dIg0KLT4gdGhlIHJlZmVyZW5jZSBoZXJlIGlz IEluZm9ybWF0aW9uYWw7IGhvdyBjYW4gdGhpcyBiZT8gVG8gaW1wbGVtZW50IHRoZSBzbGVlcCBw cm94eSBmdW5jdGlvbiBpdCBpcyBub3JtYXRpdmUgdG8gaW5jbHVkZSB0aGUgb3B0aW9uLg0KDQoi V2hlbiB0aGUgRE5TIHNlcnZlciByZWNlaXZlcyBhIFRDUCBTWU4gb3IgVURQIHBhY2tldCBhZGRy ZXNzZWQgdG8iDQotPiAiV2hlbiB0aGUgU2xlZXAgUHJveHkgcmVjZWl2ZXMgYSBUQ1AgU1lOIG9y IFVEUCBwYWNrZXQgYWRkcmVzc2VkIHRvIg0KKHNlZSBhbHNvIGJlbG93IGNvbW1lbnQpDQoNCiJ0 aGUgU2xlZXAgUHJveHkgbXVzdCBiZSBvbiB0aGUgc2FtZSBsaW5rIg0KLT4gdGhlIHRlcm0gIlNs ZWVwIFByb3h5IiBpcyBub3QgaW50cm9kdWNlZC4gSW4gdGhlIHByaW9yIHRleHQgd2hlbiBpdCBz YXlzICJzaG91bGQgc2V0IHVwIGEgcHJveHkiIHRoZSBuYW1lIGNvdWxkIGJlIGZvcm1hbGx5IGlu dHJvZHVjZWQgZS5nLiAic2hvdWxkIHNldCB1cCBhIFNsZWVwIFByb3h5IiBvciAic2hvdWxkIHNl dCB1cCBhIHByb3h5LCBjYWxsZWQgdGhlIFNsZWVwIFByb3h5LCAiDQoNCk92ZXJhbGwsIEkgbWlz cyBzb21lIGRldGFpbHMgYWJvdXQgd2hhdCB0aGUgU2xlZXAgUHJveHkgZG9lcyBvbmNlIGl0IHJl Y2VpdmVzIGEgVENQIFNZTiBvciBVRFAgcGFja2V0IGFuZCBpdCBoYXMgd29rZW4gdXAgdGhlIHNs ZWVweSBkZXZpY2UuIERvZXMgaXQgdGhlbiBzdG9wIHRoZSBBUlAvTkQgcHJveHlpbmcgZm9yIHRo ZSBzbGVlcHkgZGV2aWNlIHJpZ2h0IGF3YXk/IEFuZCB3aGVuIHdvdWxkIGl0IGFnYWluIHJlc3Vt ZSBwcm94eWluZz8NCldoYXQgZG9lcyB0aGUgcHJveHkgZG8gd2l0aCB0aGUgcmVjZWl2ZSBUQ1Ag U1lOIG9yIFVEUCBwYWNrZXQsIGRpc2NhcmQgb3IgZm9yd2FyZCB0byB0aGUgd29rZW4gc2xlZXB5 IGRldmljZT8gKEFmdGVyIGhvdyBtdWNoIHdhaXRpbmcgdGltZT8pDQoNCioqKiA2LjENCiJTZXJ2 aWNlIERpc2NvdmVyeSBQcm90b2NvbCBzZXJ2ZXJzIg0KLT4gaXMgdGhpcyB0ZXJtIGRlZmluZWQ/ IFNob3VsZCB3ZSBzYXkgU1JQIHNlcnZlcnMgaGVyZT8NCg0KImEgcHJvbWlzZSBtYWRlIGJ5IHRo ZSByZWdpc3RyYXRpb24gcHJvdG9jb2wiDQotPiAiYSBwcm9taXNlIG1hZGUgYnkgdGhlIHNlcnZp Y2UgcmVnaXN0cmF0aW9uIHByb3RvY29sIg0KDQoicmVwbGFjaW5nIGFsbCBvciBwYXJ0IG9mIHRo ZSBzZXJ2aWNlIHJlZ2lzdHJhdGlvbiBpbmZvcm1hdGlvbiB3aXRoIGluZm9ybWF0aW9uIHByb3Zp ZGVkIGJ5IGFuIFNSUCBjbGllbnQiDQotPiB0aGUgIlNSUCBjbGllbnQiIG1lbnRpb25lZCBoZXJl IEkgdGhpbmsgc2hvdWxkIGJlICJETlMgY2xpZW50Ii4gQmVjYXVzZSB0aGUgY2FzZSBtZW50aW9u ZWQgbG9va2VkIGxpa2UgYW4gYXV0aGVudGljYXRlZCAobm9uLVNSUCkgRE5TIGNsaWVudCBtYWtp bmcgRE5TIHVwZGF0ZXMgdG8gcmVjb3JkcyB0aGF0IHdlcmUgYWRkZWQgYnkgYW4gU1JQIGNsaWVu dC4NCg0KKioqIDcgIlByaXZhY3kgQ29uc2lkZXJhdGlvbnMiDQpUaGlzIHRleHQgbWVudGlvbnMg dGhlIHJlcXVpcmVtZW50cyBmb3IgVExTLiBQZXJoYXBzIHRoZSBUTFMgYml0cyBhcmUgYmV0dGVy IHBsYWNlZCBpbiBTZWN0aW9uIDYsIGFuZCBTZWN0aW9uIDcgaWYgbmVlZGVkIGNhbiByZWZlciBi YWNrIHRvIHRoYXQuIFRvIG1lIFRMUyBzZWVtcyBvbmUgb2YgdGhlIGtleSBpbmdyZWRpZW50cyB0 byBzZWN1cmUgdGhlIHByb3RvY29sIHNvIEknZCBleHBlY3QgdG8gcmVhZCBzb21ldGhpbmcgLyBt b3N0LXRoaW5ncyBhYm91dCB0aGlzIGluIFNlY3Rpb24gNi4gICAoTWF5YmUgSSdtIHdyb25nIGhl cmUgaW4gY2FzZSBUTFMgY2FuJ3QgcHJvdmlkZSB0aGUgYXV0aGVudGljYXRpb24gLSBzaW5jZSBp biBzb21lIGRlcGxveW1lbnRzIHRoZSBjbGllbnQgbWF5IGhhdmUgbm8gdHJ1c3QgYW5jaG9yIG9m IHRoZSBkb21haW4gaW5zdGFsbGVkIGEgcHJpb3JpLCBzbyBpdCBjYW4ndCBhdXRoZW50aWNhdGUg dGhlIFNSUCBzZXJ2ZXIgZXZlbiB3aGVuIFRMUyBpcyB1c2VkLikNCg0KKioqIDkuMg0KIkF2YWls YWJpbGl0eSBvZiBETlMgU2VydmljZSBEaXNjb3ZlcnkgU2VydmljZSBSZWdpc3RyYXRpb24gUHJv dG9jb2wNCiAgIFNlcnZpY2UgZm9yIGEgZ2l2ZW4gZG9tYWluIGlzIGFkdmVydGlzZWQgdXNpbmcg dGhlDQogICAiX2Ruc3NkLXNycC5fdGNwLjxkb21haW4+LiIgIFNSViByZWNvcmQgZ2l2ZXMgdGhl IHRhcmdldCBob3N0IGFuZA0KICAgcG9ydCB3aGVyZSBETlNTRCBTZXJ2aWNlIFJlZ2lzdHJhdGlv biBTZXJ2aWNlIGlzIHByb3ZpZGVkIGZvciB0aGUNCiAgIG5hbWVkIGRvbWFpbi4iDQoNCi0+IHNl ZW1zIGxpa2UgYSBncmFtbWFyIGlzc3VlIGhlcmUuIFdhcyB0aGlzIG1lYW50IGFzIGEgc2luZ2xl IHNlbnRlbmNlLCBvciBhcyAyIHNlbnRlbmNlcyBzZXBhcmF0ZWQgYnkgYSBkb3QgYmVmb3JlIHRo ZSAiU1JWIHJlY29yZCIgdGV4dD8NCkUuZy4gSSBjb3VsZCBpbnRlcnByZXQgYXMgInVzaW5nIHRo ZSBYIFNSViByZWNvcmQgd2hpY2ggZ2l2ZXMgdGhlIFkiIG9yIGFzICJ1c2luZyB0aGUgWCBuYW1l LiBUaGUgU1JWIHJlY29yZCBnaXZlcyB0aGUgWSIuDQpTaW1pbGFyIHBvaW50IGZvciA5LjMuDQoN Cg0KDQoNCg0KRnJvbTogRGF2aWQgU2NoaW5hemkgPGRzY2hpbmF6aS5pZXRmQGdtYWlsLmNvbTxt YWlsdG86ZHNjaGluYXppLmlldGZAZ21haWwuY29tPj4NClNlbnQ6IE1vbmRheSwgQXVndXN0IDE2 LCAyMDIxIDIwOjA5DQpUbzogRXNrbyBEaWprIDxlc2tvLmRpamtAaW90Y29uc3VsdGFuY3kubmw8 bWFpbHRvOmVza28uZGlqa0Bpb3Rjb25zdWx0YW5jeS5ubD4+DQpDYzogRE5TU0QgPGRuc3NkQGll dGYub3JnPG1haWx0bzpkbnNzZEBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW2Ruc3NkXSBXR0xD IGZvciBkcmFmdC1pZXRmLWRuc3NkLXNycA0KDQpIaSBFc2tvLA0KDQpUaGF0J3MgcmVhc29uYWJs ZSwgd2UgY2FuIHdhaXQgYSBmZXcgbW9yZSBkYXlzIGZvciB5b3UgdG8gcmV2aWV3Lg0KDQpEYXZp ZA0KDQpPbiBTdW4sIEF1ZyAxNSwgMjAyMSBhdCAxOjM3IFBNIEVza28gRGlqayA8ZXNrby5kaWpr QGlvdGNvbnN1bHRhbmN5Lm5sPG1haWx0bzplc2tvLmRpamtAaW90Y29uc3VsdGFuY3kubmw+PiB3 cm90ZToNCkhlbGxvIERhdmlkLA0KDQpEdWUgdG8gaG9saWRheSBJIG1pc3NlZCB0aGlzIGxhc3Qg Y2FsbC4gSGF2aW5nIHJldmlld2VkIGFuIGVhcmxpZXIgdmVyc2lvbiBJIHdvdWxkIGxpa2UgdG8g Y2hlY2sgaWYgdGhlIGlzc3VlcyBhcmUgc29sdmVkIG5vdzsgYW5kIGNhbiBhbnN3ZXIgdGhlIHF1 ZXN0aW9uIGJ5IFR1ZXNkYXkgb3IgV2VkbmVzZGF5IGlmIHRoYXTigJlzIG9rLiAoSW5zdGVhZCBv ZiB0b2RheSkNCg0KQmVzdCByZWdhcmRzDQpFc2tvDQoNCkZyb206IGRuc3NkIDxkbnNzZC1ib3Vu Y2VzQGlldGYub3JnPG1haWx0bzpkbnNzZC1ib3VuY2VzQGlldGYub3JnPj4gT24gQmVoYWxmIE9m IERhdmlkIFNjaGluYXppDQpTZW50OiBXZWRuZXNkYXksIEp1bHkgMjgsIDIwMjEgMjM6NTcNClRv OiBETlNTRCA8ZG5zc2RAaWV0Zi5vcmc8bWFpbHRvOmRuc3NkQGlldGYub3JnPj4NClN1YmplY3Q6 IFtkbnNzZF0gV0dMQyBmb3IgZHJhZnQtaWV0Zi1kbnNzZC1zcnANCg0KSGkgRE5TU0QgZW50aHVz aWFzdHMsDQoNClRoaXMgZW1haWwgc3RhcnRzIGFuIG9mZmljaWFsIFdvcmtpbmcgR3JvdXAgTGFz dCBDYWxsIGZvciBkcmFmdC1pZXRmLWRuc3NkLXNycC4gVGhpcyBjYWxsIGFza3Mgd2hldGhlciB3 ZSBiZWxpZXZlIHRoZSBkb2N1bWVudCBpcyByZWFkeSBmb3IgcHVibGljYXRpb24uIEFzIHN1Y2gg d2UgYXJlIGFza2luZyB0d28gcXVlc3Rpb25zOg0KDQoxKSBpZiB5b3UgYmVsaWV2ZSB0aGlzIGRv Y3VtZW50IGlzIG5vdCByZWFkeSB0byBwdWJsaXNoLCBwbGVhc2Ugc3BlYWsgdXAgbm93DQoNCjIp IGlmIHlvdSBoYXZlIHJlYWQgdGhlIGRvY3VtZW50IGFuZCB0aGluayBpdCBpcyByZWFkeSwgcGxl YXNlIHNheSBzbyBhcyB3ZWxsDQoNCkZvciB0aGlzIGNhbGwgdG8gc3VjY2VlZCwgd2UnbGwgbmVl ZCBzdGF0ZW1lbnRzIG9mIGV4cGxpY2l0IHN1cHBvcnQgZnJvbSBwZW9wbGUgd2hvIGhhdmUgcmVh ZCB0aGUgZHJhZnQuIFBsZWFzZSBzZW5kIHN0YXRlbWVudHMgaW4gZWl0aGVyIGRpcmVjdGlvbiBh cyByZXNwb25zZXMgdG8gdGhpcyBlbWFpbC4gVGhpcyBjYWxsIHdpbGwgYmUgb3BlbiB1bnRpbCAy MDIxLTA4LTE1IDIzOjU5IFVUQy4NCg0KVGhhbmtzLA0KRGF2aWQNCg== --_000_AM8P190MB0979C97C6F267BD5E1720A7BFDC09AM8P190MB0979EURP_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVC My0xMWQxLUEyOUYtMDBBQTAwQzE0ODgyIiB4bWxuczptPSJodHRwOi8vc2NoZW1hcy5taWNyb3Nv ZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9S RUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250 ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBj b250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8c3R5bGU+PCEt LQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2Ft YnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9 DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2 Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1z b0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGlu Ow0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6 LjVpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmO30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7 fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1z aXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJ bWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNv LWxpc3QtaWQ6NzgyMDcwMzc4Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRl bXBsYXRlLWlkczotNzE2NTYwNzIyIDY3Njk4NzA1IDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAz IDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1O30NCkBsaXN0IGww OmxldmVsMQ0KCXttc28tbGV2ZWwtdGV4dDoiJTFcKSI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93 ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7 fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6 bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwwOmxl dmVsNw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu O30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dl cjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1pZDox NDk2NjUyNzcxOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTk0ODQ1MDM2O30NCm9sDQoJe21h cmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBz cGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIg ZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4N Cjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIiBzdHlsZT0id29y ZC13cmFwOmJyZWFrLXdvcmQiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPlBTIG9uZSBmaW5hbCByZXZpZXcgcXVlc3Rpb24gSSBmb3Jnb3QgdG8gaW5j bHVkZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2hhdCBkbyB0aGUgYXV0aG9ycyAvIFdHIHRo aW5rIGFib3V0IHJlZ2lzdGVyaW5nIHRoZSBuYW1lIGZvciB0aGUgVURQLWJhc2VkIFNSUCBzZXJ2 ZXIsIGkuZS4gJnF1b3Q7X2Ruc3NkLXNycC5fdWRwLiZsdDtkb21haW4mZ3Q7LiZxdW90OyA/PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHdyb3RlIHNvbWUgcmVhc29ucyBp biBteSBlbWFpbCBvZiAyMDIwLTExLTAzIHdoeSB0aGlzIGNvdWxkIGJlIHVzZWZ1bCBidXQgdGhp cyBhc3BlY3Qgd2FzbuKAmXQgZGlzY3Vzc2VkIHNvIGZhci4mbmJzcDsgSW4gYW55IGNhc2UgSeKA mW0gZmluZSBhbHNvIHRvIG5vdCBhZGQgdGhpcyBlbnRyeSB0byB0aGUgcmVnaXN0ZXJlZCBzZXJ2 aWNlIG5hbWVzLiAoSWYgdGhlIGludGVudCBpcyByZWFsbHkgdG8gaGF2ZSBhIFRDUC1vbmx5DQog U1JQKTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Fc2tvPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAw aW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gZG5zc2QgJmx0 O2Ruc3NkLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IDxiPk9uIEJlaGFsZiBPZiA8L2I+DQpFc2tvIERp ams8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIEF1Z3VzdCAxOSwgMjAyMSAxMzowNTxicj4N CjxiPlRvOjwvYj4gRE5TU0QgJmx0O2Ruc3NkQGlldGYub3JnJmd0Ozxicj4NCjxiPkNjOjwvYj4g VGVkIExlbW9uICZsdDttZWxsb25AZnVndWUuY29tJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBS ZTogW2Ruc3NkXSBXR0xDIGZvciBkcmFmdC1pZXRmLWRuc3NkLXNycCAvIHJldmlldzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGVsbG8sPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkhlcmUgbXkgcmVzcG9uc2UgdG8gdGhlIFdHTEMgZm9yIGRyYWZ0LWlldGYtZG5zc2Qt c3JwIGFjY29tcGFuaWVkIGJ5IHJldmlldyBjb21tZW50cyBmb3IgdGhlIGRyYWZ0LjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SW4gc3VtbWFyeSwgSSBiZWxpZXZlIHRoZSBk b2N1bWVudCBhcGFydCBmcm9tIFNlY3Rpb24gNSBpcyByZWFkeSB0byBiZSBwdWJsaXNoZWQgYWZ0 ZXIgdGhlIHJldmlldyBjb21tZW50cyBhcmUgYWRkcmVzc2VkOiBhcyB0aGVzZSBjb21tZW50cyBh cmUgbW9zdGx5IG9uIGVkaXRvcmlhbCBpc3N1ZXMsIHRleHQgbG9jYXRpb24gYW5kIHJlc29sdmlu ZyBwb3RlbnRpYWwgdW5jbGFyaXRpZXMuIFRoZSBTUlAgcHJvdG9jb2wNCiBvdmVyYWxsIGxvb2tz IHVzZWZ1bCwgc29saWQgYW5kIHdlbGwtZGVzY3JpYmVkLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5UaGUgc3BlY2lmaWMgcGFydCBvZiBTZWN0aW9uIDUgb24gU2xlZXAgUHJveHkgaGFzIGhhZCBs ZXNzIHdvcmsgaXQgc2VlbXMsIGFzIGEgZmV3IG9mIG15IG9yaWdpbmFsIC0wNCByZXZpZXcgY29t bWVudHMgYXJlIHN0aWxsIG9wZW4gYW5kIEkgZG9u4oCZdCBzZWUgaG93IHRoaXMgZnVuY3Rpb24g Y291bGQgbGVhZCB0byBpbnRlcm9wZXJhYmxlIGltcGxlbWVudGF0aW9ucy4gVG8gcmVzb2x2ZSB0 aGlzLCBwb3NzaWJsZQ0KIGFjdGlvbnMgYXJlOjxvOnA+PC9vOnA+PC9wPg0KPG9sIHN0eWxlPSJt YXJnaW4tdG9wOjBpbiIgc3RhcnQ9IjEiIHR5cGU9IjEiPg0KPGxpIGNsYXNzPSJNc29MaXN0UGFy YWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwwIGxldmVsMSBsZm8zIj5N b3ZlIHRoZSBTbGVlcCBQcm94eSBkZWZpbml0aW9uL2RldGFpbHMgb3V0IG9mIHRoaXMgZHJhZnQs IGludG8gYSBzZXBhcmF0ZSBvbmUuIFRoaXMgY291bGQgcHJvZ3Jlc3MgU1JQIGluIHRoZSBiZXN0 IHdheS48bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwwIGxldmVsMSBsZm8zIj5BZGQgbW9yZSBkZXRhaWxz IG9uIHRoZSBTbGVlcCBQcm94eSwgdG8gYSBmdWxseSBpbnRlcm9wZXJhYmxlIGltcGxlbWVudGF0 aW9uIGJlY29tZXMgcG9zc2libGUuPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTGlzdFBh cmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMyI+ S2VlcCBjdXJyZW50IFNlY3Rpb24gNSB0ZXh0IChvbmx5IG1pbm9yIGFkZGl0aW9ucy9jaGFuZ2Vz L2ZpeGVzKSwgYW5kIGFkZCBhIHNlbnRlbmNlIHNheWluZyB0aGF0IG1vcmUgZGV0YWlscyBjYW4g YmUgZGVmaW5lZCBpbiBhIGZ1dHVyZSBkb2N1bWVudCAoZS5nLiBhZnRlciBpbXBsZW1lbnRhdGlv bnMgaGF2ZSBiZWVuDQogdGVzdGVkIOKAkyBjbGllbnRzIHZzIHNlcnZlcnMgb2YgZGlmZmVyZW50 IHBhcnRpZXMpPG86cD48L286cD48L2xpPjwvb2w+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SZWxh dGVkIHF1ZXN0aW9uOiBhcmUgYW55IGltcGxlbWVudGF0aW9ucyB1c2luZyBTbGVlcCBQcm94eT88 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QmVzdCByZWdhcmRzPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5Fc2tvPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRldGFpbGVkIHJl dmlldyBjb21tZW50cyBsaXN0OjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4qKiogQWJzdHJhY3Q8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjgwMi4xMSAoV2ktRmkpIGFuZCA4 MDIuMTUuNCAoSW9UKSBuZXR3b3JrczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+LSZndDsgYWRkICdJRUVFJyBzbyAmcXVvdDtJRUVFIDgwMi4xMSAoV2ktRmkpIGFuZCA4MDIu MTUuNCAoSW9UKSBuZXR3b3JrcyZxdW90OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+QXMgYW4gZWRpdG9yaWFsIGNvbW1lbnQsIGluIGdlbmVyYWwgdGhlIGFic3RyYWN0IHNo b3VsZCBub3QgY29udGFpbiBtb3JlIGRldGFpbHMgdGhhbiB0aGUgbWFpbiB0ZXh0LjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U28gdHlwaWNhbGx5IG9uZSB3b3VsZCBzZWUg YmFjayB0aGVzZSB0ZXJtcyBhZ2FpbiBpbiBhbiBpbnRyb2R1Y3Rpb24uPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPioqKiAyLjIuMTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ JnF1b3Q7UkZDIDY3NjMgZGVzY3JpYmVzIHRoZSBkZXRhaWxzIG9mIHdoYXQgZWFjaCBvZiB0aGVz ZSB0eXBlcyBvZiB1cGRhdGVzIGNvbnRhaW5zJnF1b3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4tJmd0OyBub3QgZXZlcnl0aGluZyBjb250YWluZWQgaW4gdGhlc2UgdXBk YXRlcyBpcyBleHBsYWluZWQgaW4gUkZDIDY3NjMuIFNwZWNpZmljYWxseSwgdGhlICZxdW90O0tl eSBSUiZxdW90OyBpcyBub3QgaW4gdGhhdCBSRkMuIEFub3RoZXIgUkZDIHJlZiBjYW4gYmUgYWRk ZWQgaGVyZSB0aGF0IGRlZmluZXMgS2V5IFJSIGFzIGRlZmluaXRpdmUgc291cmNlIG9mIGluZm9y bWF0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4qKiogMi4yLjMuMTxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+JnF1b3Q7U1JQIGNsaWVudHMgYXJlIGFsbG93ZWQgdG8g c2VuZCB1cGRhdGVzIHRvIHRoZSBnZW5lcmljIGRvbWFpbiAmcXVvdDtkZWZhdWx0LnNlcnZpY2Uu YXJwYSZxdW90OyZxdW90OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LSZn dDsgSW4gc2VjdGlvbiAyLjEuKiBpdCBsb29rcyBhcyBpZiBvbmx5IGNvbnN0cmFpbmVkIGhvc3Rz IGNhbiBkbyB0aGlzLiBDYW4gZnVsbC1mZWF0dXJlZCBob3N0cyBhbHNvIGRvIHRoaXM/IElmIG5v dCB3ZSBjYW4gc2F5ICZxdW90O0NvbnN0cmFpbmVkLU5vZGUgU1JQIGNsaWVudHMgYXJlIC4uLiZx dW90OyZuYnNwOyZuYnNwOyBJZiB5ZXMsIHRoZW4gSSB3b3VsZCBleHBlY3Qgc2VjdGlvbiAyLjEu MSB0byBtZW50aW9uIHRoaXMgdXNlIGZvciB0aGUNCiBmdWxsLWZlYXR1cmVkIGhvc3RzLjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4qKiogMi4yLjUuMTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+ZHVwbGljYXRlZCBzZW50ZW5jZSAmcXVvdDtUaGlzIGtleSBwYWlyIE1VU1Qg YmUgdW5pcXVlIHRvIHRoZSBkZXZpY2UuJnF1b3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPioq KiAyLjIuNS40PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Eb2VzIHRoZSBz dGF0ZW1lbnQgaGVyZSBpbXBseSB0aGF0IHRoaXMgZHJhZnQgZm9ybWFsbHkgdXBkYXRlcyBSRkMg Mjc4Mj88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPihRdWVzdGlvbiB0byB0 aGUgV0cuIE1heWJlIG5vdDogc2luY2UgdGhlIHVwZGF0ZSBvbmx5IGFwcGxpZXMgaW4gU1JQIGNv bnRleHQgbm90IGZvciBTUlYgcmVjb3JkcyBpbiBnZW5lcmFsLiBCdXQgbWF5YmUgeWVzOiBSRkMg Mjc4MiBzYXlzICZxdW90O1VubGVzcyBhbmQgdW50aWwgcGVybWl0dGVkIGJ5IGZ1dHVyZSBzdGFu ZGFyZHMgYWN0aW9uLCBuYW1lIGNvbXByZXNzaW9uIGlzIG5vdCB0byBiZSB1c2VkIGZvciB0aGlz DQogZmllbGQuJnF1b3Q7IHdoaWNoIHdvdWxkIG1ha2UgaXQgcHJvcGVyIHRvIHJlZmVyIHRvIHRo ZSBTUlAgZHJhZnQgYXMgc3VjaCBmdXR1cmUgYWN0aW9uLik8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+KioqIDIuMi41LjUuMjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+JnF1 b3Q7dXBkYXRlIHRoYXQgZGVsZXRlcyB0aGUgUFRSIHJlY29yZCB3aG9zZSB0YXJnZXQgaXMgdGhl IHNlcnZpY2UgaW5zdGFuY2UgbmFtZS4mcXVvdDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPi0mZ3Q7IFRoaXMgbG9va3MgbGlrZSBhIHNpbmdsZSBQVFIgcmVjb3JkLiBQcmlv ciBzZWN0aW9uIDIuMi4xIG1lbnRpb25zIHRoYXQgdGhlIHNlcnZpY2UgaW5zdGFuY2UgbmFtZSBt YXkgYmUgcmVmZXJyZWQgdG8gYnkgbXVsdGlwbGUgUFRSIHJlY29yZHMuJm5ic3A7IFNvIGluIGNh c2Ugb2YgbXVsdGlwbGUsIGl0IGlzIG5vdCByZXF1aXJlZCB0byBoYXZlIG11bHRpcGxlIGluc3Ry dWN0aW9ucyB0byBkZWxldGUgdGhlc2UgbXVsdGlwbGUNCiBQVFIgcmVjb3Jkcz88bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPihJLmUuIHRoZXJlJ3Mgbm8gcmlzayBvZiBsaW5n ZXJpbmcgUFRSIHJlY29yZHMgdGhhdCB3b3VsZCBwb2ludCB0byBhIHNlcnZpY2UgaW5zdGFuY2Ug dGhhdCdzIGRlbGV0ZWQ/KTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4qKiogMi4zIHRpdGxlIDxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+W05pdF0gLSZndDsgbWF5IGdpdmUg dGhlIGltcHJlc3Npb24gdGhhdCBhbGwgU1JQIHNlcnZlciBiZWhhdmlvciBpcyBzcGVjaWZpZWQg aW4gaGVyZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNvbWV3aGVyZSBp biAyLjMgLyAyLjMuKiBpdCBjb3VsZCBtZW50aW9uIHRoYXQgbW9yZSBub3JtYXRpdmUgYmVoYXZp b3IgaXMgc3BlY2lmaWVkIGluIG90aGVyIHNlY3Rpb25zIHRvbywgbGlrZSBTZWN0aW9ucyAzIGFu ZCA0LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4qKiogMi4zLjE8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkdyYW1tYXIgdG8gYmUgZml4ZWQ6ICZxdW90O0VhY2ggaW5zdHJ1 Y3Rpb24gY29uc2lzdHMgc29tZSBjb21iaW5hdGlvbiZxdW90OzxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4qKiogMi4zLjEuMTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+JnF1 b3Q7aWYgdGhlIFNlcnZpY2UgRGlzY292ZXJ5IHVwZGF0ZSBpcyBhbiAmcXVvdDtBZGQgdG8gYW4g UlJTZXQmcXVvdDsgaW5zdHJ1Y3Rpb24sIHRoZSBTZXJ2aWNlIERlc2NyaXB0aW9uIEluc3RydWN0 aW9uIGRvZXMgbm90IG1hdGNoIGlmJnF1b3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4tJmd0OyBmb3IgbWUgdW5jbGVhciwgc2VlIHNlcGFyYXRlIG1haWwgdGhyZWFkIG9u IHRoaXMgc2VjdGlvbi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+KioqIDIuMy4xLjI8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPltOaXRdIEJ1bGxldDo8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZxdW90OyombmJzcDsgU2VydmljZSBEZXNjcmlwdGlv bnMgSW5zdHJ1Y3Rpb25zIGRvIG5vdCBtb2RpZnkgYW55IG90aGVyIFJScy4mcXVvdDs8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0mZ3Q7IGJlc3QgcmVwaHJhc2VkIHRvIDxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7JnF1b3Q7KiZuYnNwOyBu byBSUiB1cGRhdGVzIG90aGVyIHRoYW4gdGhlIG9uZXMgZGVmaW5lZCBhYm92ZS4mcXVvdDs8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhdCB3b3VsZCBmaXQgYmV0dGVyIGluIHRoZSBzdHlsZSBv ZiB0aGUgcHJldmlvdXMgYnVsbGV0IHBvaW50cyBpbiB0aGUgbGlzdC48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+KioqIDIuMy4xLjM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZxdW90O0lmIGEgbGluay1zY29wZSBhZGRyZXNzIG9yIElQdjQgYXV0b2NvbmZpZ3VyYXRpb24g YWRkcmVzcyBpcyBwcm92aWRlZCBieSB0aGUgU1JQIGNsaWVudCwgdGhlPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgU1JQIHNlcnZlciBNVVNUIHRyZWF0IHRoaXMg YXMgaWYgbm8gYWRkcmVzcyByZWNvcmRzIHdlcmUgcmVjZWl2ZWQ7IHRoYXQgaXMsIHRoZSBIb3N0 IERlc2NyaXB0aW9uIGlzIG5vdCB2YWxpZC4mcXVvdDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPi0mZ3Q7IFRoaXMgc2VlbXMgcmF0aGVyIHN0cmljdC4gSWYgdGhlIGNsaWVu dCBwcm92aWRlcyAxIHJvdXRhYmxlIElQIGFkZHJlc3MgYW5kIDEgbGluay1sb2NhbCBhZGRyZXNz LCBjb3VsZG4ndCB0aGUgU1JQIHNlcnZlciBqdXN0IGlnbm9yZSB0aGUgbGluay1sb2NhbCBhZGRy ZXNzPzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBtaWdodCBoYXZl IHNvbWUgYmVuZWZpdHMgZm9yIGZ1dHVyZS9iYWNrd2FyZHMgY29tcGF0aWJpbGl0eSAsIGluIGNh c2Ugb2YgZnV0dXJlIGNhc2VzIHdoZXJlIGxpbmstbG9jYWwgYWRkcmVzc2VzIGFyZSB0byBiZSB1 c2VkIGZvciBzb21lIHJlYXNvbi4gKElmIG9ubHkgZm9yIGRlYnVnL2RpYWdub3N0aWMgcHVycG9z ZXMpPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGFncmVlIHRoYXQgaWYg dGhlIGNsaWVudCBzZW5kcyBvbmx5IGxpbmstbG9jYWwgYWRkcmVzcyhlcykgdGhlbiB0aGUgU1JQ IHNlcnZlciB0cmVhdHMgaXQgYXMgaWYgbm8gYWRkcmVzcyByZWNvcmRzIHdlcmUgcmVjZWl2ZWQu PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPioqKiAyLjMuMjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+W05pdF0gJnF1b3Q7bXVzdCBoYXZlIHRoYXQgSG9zdCBEZXNjcmlwdGlv biBpbnN0cnVjdGlvbiBhcyB0aGUgdGFyZ2V0IG9mIGl0cyBTUlYgcmVjb3JkJnF1b3Q7PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tJmd0OyBjb3VsZCByZXBocmFzZSB0byAm cXVvdDtNVVNUIGhhdmUgdGhlIGhvc3RuYW1lIG9mIHRoYXQgSG9zdCBEZXNjcmlwdGlvbiBJbnN0 cnVjdGlvbiBhcyB0aGUgdGFyZ2V0IG9mIGl0cyBTUlYgcmVjb3JkJnF1b3Q7Jm5ic3A7IHRvIGJl IG1vcmUgcHJlY2lzZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNpbWls YXIgY29tbWVudHMgY2FuIGJlIGdpdmVuIGZvciB0aGUgcmVtYWluZGVyIG9mIHRoZSBzZWN0aW9u IHRleHQgdGhhdCB0YWxrcyBhYm91dCBpbnN0cnVjdGlvbnMgcG9pbnRpbmcgdG8gaW5zdHJ1Y3Rp b25zLiZuYnNwOyAoSXQncyBtb3JlIGxpa2UgbmFtZXMgaW4gaW5zdHJ1Y3Rpb25zIGJlaW5nIGVx dWFsIHRvIG5hbWVzIHRoYXQgYXJlIHVzZWQgaW4gb3RoZXIgaW5zdHJ1Y3Rpb25zKTxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+KG5vdCBzdXJlIGlmIE1VU1Qgb3IgbXVzdCBp cyBkZXNpcmVkIGhlcmUgYnkgdGhlIHdheSk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+JnF1b3Q7 Rm9yIGV4YW1wbGUsIGEgRE5TIHVwZGF0ZSB0aGF0IGNvbnRhaW5zIGFuIFJSc2V0PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsgQWRkIHRvIGEgU2Vydmlj ZSBOYW1lIGFuZCBhbiBSUnNldCBBZGQgdG8gYSBTZXJ2aWNlIEluc3RhbmNlIE5hbWUsPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsgd2hlcmUgdGhlIFNl cnZpY2UgTmFtZSBkb2VzIG5vdCByZWZlcmVuY2UgdGhlIFNlcnZpY2UgSW5zdGFuY2UgTmFtZSw8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyBpcyBub3Qg YSB2YWxpZCBTUlAgdXBkYXRlIG1lc3NhZ2UmcXVvdDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPi0mZ3Q7ICdSUnNldCBBZGQnIHJlZmVycyBwcm9iYWJseSB0byB0aGUgJnF1 b3Q7QWRkIFRvIEFuIFJSc2V0JnF1b3Q7IHNlbWFudGljcyBvZiBSRkMgMjEzNj8gSWYgc28gaXQg d291bGQgYmUgZ29vZCB0byB1c2UgdGhhdCBleGFjdCBzYW1lIG5hbWluZyAmcXVvdDtBZGQgVG8g QW4gUlJzZXQmcXVvdDsgaW5jbHVkaW5nIHRoZSBxdW90ZXMgaGVyZS48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPldpdGggcHJlc2VudCB0ZXh0IEknbSB3b25kZXJpbmcgaWYg SSBtaXNzZWQgc29tZXRoaW5nIGluIHRoZSBETlMgc3BlY3MgdGhhdCdzIGNhbGxlZCAmcXVvdDtS UnNldCBBZGQmcXVvdDsuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPioqKiAyLjMuMzxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+JnF1b3Q7SWYgYW55IGV4aXN0aW5nIEtFWSBy ZWNvcmQgY29ycmVzcG9uZGluZyB0byBhPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDsmbmJzcDsgS0VZIHJlY29yZCBpbiB0aGUgU1JQIFVwZGF0ZSBkb2VzIG5vdCBt YXRjaCB0aGUgS0VZIHNhbWUgcmVjb3JkIGluPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDsmbmJzcDsgdGhlIFNSUCBVcGRhdGUgJnF1b3Q7PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tJmd0OyBncmFtbWFyIGlzc3VlLiAnbWF0Y2ggdGhlIEtF WSBzYW1lIHJlY29yZCcmbmJzcDsmbmJzcDsmbmJzcDsgQW5kIGEgYml0IGNvbmZ1c2luZzogY2Fu IGEgS0VZIHJlY29yZCBpbiBhbiB1cGRhdGUgY29ycmVzcG9uZCB0byBhIHN0b3JlZCBLRVkgcmVj b3JkIGJ1dCBub3QgbWF0Y2ggYXQgdGhlIHNhbWUgdGltZT88bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOyBQZXJoYXBzIHRoZSAnbmFtZScgY29uY2VwdCBzaG91bGQg YmUgaW50cm9kdWNlZCBoZXJlIHRvIGNsYXJpZnkuIChQcmVzdW1hYmx5IHRoZSBzZXJ2ZXIgd2ls bCBjaGVjayBpZiBhbiBleGlzdGluZyBTZXJ2aWNlIEluc3RhbmNlIE5hbWUgb3IgZXhpc3Rpbmcg SG9zdG5hbWUgaXMgc3RvcmVkIGFuZCBsb29rIHVwIHRoZSBhc3NvY2lhdGVkIEtFWSBmb3IgdGhh dC4pPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZxdW90O0tFWSByZWNvcmQgdXBkYXRlcyBvbWl0 dGVkIGZyb20gU2VydmljZSBEZXNjcmlwdGlvbiB1cGRhdGUgYXJlPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsgcHJvY2Vzc2VkIGFzIGlmIHRoZXkgaGFk IGJlZW4gZXhwbGljaXRseSBwcmVzZW50OiBldmVyeSBTZXJ2aWNlPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsgRGVzY3JpcHRpb24gdGhhdCBpcyB1cGRh dGVkIE1VU1QsIGFmdGVyIHRoZSB1cGRhdGUsIGhhdmUgYSBLRVkgUlIsPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsgYW5kIGl0IG11c3QgYmUgdGhlIHNh bWUgS0VZIFJSIHRoYXQgaXMgcHJlc2VudCBpbiB0aGUgSG9zdDxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7IERlc2NyaXB0aW9uIHRvIHdoaWNoIHRoZSBT ZXJ2aWNlIERlc2NyaXB0aW9uIHJlZmVycy4mcXVvdDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPi0mZ3Q7IENhbiB3ZSByZXBsYWNlIGhlcmUgJ1NlcnZpY2UgRGVzY3JpcHRp b24gdXBkYXRlJyBieSAnU2VydmljZSBEZXNjcmlwdGlvbiBJbnN0cnVjdGlvbicgPzxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RS5nLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+JnF1b3Q7S0VZIHJlY29yZCB1cGRhdGVzIG9taXR0ZWQgZnJvbSBTZXJ2 aWNlIERlc2NyaXB0aW9uIEluc3RydWN0aW9ucyBhcmU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyBwcm9jZXNzZWQgYXMgaWYgdGhleSBoYWQgYmVlbiBl eHBsaWNpdGx5IHByZXNlbnQ6IGV2ZXJ5IFNlcnZpY2U8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyBEZXNjcmlwdGlvbiB0aGF0IGlzIHVwZGF0ZWQgdGhy b3VnaCBhIFNlcnZpY2UgRGVzY3JpcHRpb24gSW5zdHJ1Y3Rpb24gTVVTVCwgYWZ0ZXIgdGhlIHVw ZGF0ZSwgaGF2ZSBhIEtFWSBSUiw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOyZuYnNwOyBhbmQgaXQgbXVzdCBiZSB0aGUgc2FtZSBLRVkgUlIgdGhhdCBpcyBwcmVz ZW50IGluIHRoZSBIb3N0PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDsmbmJzcDsgRGVzY3JpcHRpb24gSW5zdHJ1Y3Rpb24gdG8gd2hpY2ggdGhlIFNlcnZpY2UgRGVz Y3JpcHRpb24gSW5zdHJ1Y3Rpb24gcmVmZXJzLiZxdW90OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mcXVvdDtPdGhlcndpc2UsIHRoZSBzZXJ2ZXIgdmFsaWRhdGVzIHRoZSBTUlAgVXBkYXRlIHVz aW5nIFNJRygwKSBvbiB0aGU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOyZuYnNwOyBwdWJsaWMga2V5IGluIHRoZSBLRVkgcmVjb3JkIG9mIHRoZSBIb3N0IERlc2Ny aXB0aW9uIHVwZGF0ZS4mcXVvdDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pi0mZ3Q7IHdoYXQgYWJvdXQ6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m cXVvdDtPdGhlcndpc2UsIHRoZSBzZXJ2ZXIgdmFsaWRhdGVzIHRoZSBTUlAgVXBkYXRlIHVzaW5n IFNJRygwKSBhZ2FpbnN0IHRoZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7Jm5ic3A7IHB1YmxpYyBrZXkgaW4gdGhlIEtFWSByZWNvcmQgb2YgdGhlIEhvc3QgRGVz Y3JpcHRpb24gSW5zdHJ1Y3Rpb24uJnF1b3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPihVc2lu ZyAnSW5zdHJ1Y3Rpb24nIGFuZCAndmFsaWRhdGVzIFggYWdhaW5zdCBZJyBpbnN0ZWFkIG9mICd2 YWxpZGF0aW9ucyBYIG9uIFknICk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+KioqIDM8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZxdW90O1NSUCB1cGRhdGUgc2VydmVycyBN VVNUIGNoZWNrJnF1b3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tJmd0 OyZxdW90O1NSUCBzZXJ2ZXJzIE1VU1QgY2hlY2smcXVvdDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+KioqIDQuMTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+W05pdF0gJnF1 b3Q7IE1VU1QgYmUgcmVtb3ZlZCBhdCB0aGUgc2FtZSB0aW1lLWl0IGlzIG5ldmVyIHZhbGlkIGZv ciBhIHNlcnZpY2UmcXVvdDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0m Z3Q7ICZxdW90OyBNVVNUIGJlIHJlbW92ZWQgYXQgdGhlIHNhbWUgdGltZSAtLSBpdCBpcyBuZXZl ciB2YWxpZCBmb3IgYSBzZXJ2aWNlICZxdW90OyBvcjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+LSZndDsgJnF1b3Q7IE1VU1QgYmUgcmVtb3ZlZCBhdCB0aGUgc2FtZSB0aW1l OiBpdCBpcyBuZXZlciB2YWxpZCBmb3IgYSBzZXJ2aWNlICZxdW90OzxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4zcmQgcGFyYWdyYXBoIG1lbnRpb25zIHRoYXQgYSBTUlAgaXMgYnkgZGVmYXVsdCBj b25maWd1cmVkIHdpdGggYSAyIGhvdXIgTGVhc2UgbGltaXQgYW5kIDE0LWRheSBLRVkgcmV0YWlu aW5nIHRpbWUgbGltaXQ7IGFuZCB0aGVuIGl0IHNheXMgdGhhdCBjb25zdHJhaW5lZCBkZXZpY2Vz IG1heSBuZWdvdGlhdGUgbG9uZ2VyIGxlYXNlcy4gVGhpcyBsb29rcyBpbmNvcnJlY3QsIGFzIGxl YXNlcyBiZXlvbmQgY29uZmlndXJlZA0KIHVwcGVyIGxpbWl0cyB3b24ndCBiZSBnaXZlbiBieSB0 aGUgc2VydmVyLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UHJvYmFibHkg c29tZXRoaW5nIGVsc2UgaXMgbWVhbnQgaGVyZSB3aXRoICduZWdvdGlhdGUnPyBGb3IgZXhhbXBs ZSBpZiBvbmUgY29uZmlndXJlcyAnZGVmYXVsdCB2YWx1ZXMnIGZvciBMZWFzZSBhbmQgS2V5LUxl YXNlIGluIHRoZSBzZXJ2ZXIsIHRoZSBzZXJ2ZSBtYXkgZXh0ZW5kIHRvIHRoZXNlIGRlZmF1bHQg dmFsdWVzIGlmIHRoZSBjbGllbnQgYXNrcyBmb3Igc29tZXRoaW5nIHNob3J0ZXIuIElmIHRoZQ0K IGNsaWVudCBhc2tzIGZvciBzb21ldGhpbmcgbG9uZ2VyIHRoYW4gdGhlICdkZWZhdWx0IHZhbHVl cycsIHRoZSBzZXJ2ZXIgZ3JhbnRzIHRoZSBsb25nZXIgdmFsdWVzIHVwIHRvIGEgaGFyZCBsaW1p dCB0aGF0IGlzIGFsc28gY29uZmlndXJlZCBpbiB0aGUgc2VydmVyLjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4qKiogNSBTbGVlcCBQcm94eTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+VGhlIGludHJvZHVjdGlvbiB0ZXh0IHNob3VsZCBjbGFyaWZ5IHdoZXRoZXIgU2xlZXAg UHJveHkgc3VwcG9ydCBmb3IgYW4gU1JQIHNlcnZlciBpcyBPUFRJT05BTCBvciBNQU5EQVRPUlku PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbHNvIHRvIG1ha2UgbW9yZSBj bGVhciB0aGF0IGZvciBjbGllbnRzIHRoZSB1c2Ugb2YgdGhpcyBmdW5jdGlvbiBpcyBvcHRpb25h bC9PUFRJT05BTC4gKFRoZSBsYXN0IHBhcmFncmFwaCBzYXlzIHNvIGZvciBjb25zdHJhaW5lZCBo b3N0cywgYnV0IG5vdGhpbmcgZm9yIHRoZSBmdWxsLWZlYXR1cmVkIGhvc3RzLik8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+SW4gcmVsYXRpb24gdG8gYWJvdmUsIHRoZSBzYW1lIHF1ZXN0aW9ucyBm cm9tIG15IHJldmlldyBvZiAtMDQgb2YgMjAyMC0xMC0xMyBzdGlsbCBhcHBseTo8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0gSG93IHdvdWxkIGEgc2VydmljZeKAmXMgaG9z dCBrbm93IHRoYXQgdGhlIHNlcnZlciBpcyBjYXBhYmxlIHRvIGRvIHRoaXM/IElmIGl0IGRvZXNu J3Qga25vdyB0aGVuIGl0IGNhbm5vdCB0cnVzdCB0aGUgbWVjaGFuaXNtIHRvIHdvcmsgYW5kIGdv IHRvIHNsZWVwLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LSBPciwgaXMg dGhlcmUgYSB3YXkgZm9yIHRoZSBTUlAgc2VydmVyIHRvIHJlamVjdCBhbiB1cGRhdGUgd2l0aCBF RE5TKDApIE9XTkVSIG9wdGlvbiBzdWNoIHRoYXQgdGhlIHNlcnZpY2XigJlzIGhvc3Qga25vd3Mg bm90IHRvIHVzZSBpdCBhZ2Fpbj88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+W05pdF0gJnF1b3Q7 QW5vdGhlciB1c2Ugb2YgU1JQIGlzIGZvciBkZXZpY2VzIHRoYXQgc2xlZXAgdG8gcmVkdWNlIHBv d2VyIGNvbnN1bXB0aW9uJnF1b3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4tJmd0OyBpZGVhbGx5IGl0IHNob3VsZCBtZW50aW9uIHNvbWV3aGVyZSB0aGF0IHRoZSBkZXZp Y2UgdGhhdCBzbGVlcHMgaXMgYW4gU1JQIGNsaWVudC4gT3RoZXJ3aXNlIHRoZSBzdGF0ZW1lbnQg aXMgYSBiaXQgdG9vIGdlbmVyaWMuIEUuZy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZxdW90O0Fub3RoZXIgdXNlIG9mIFNSUCBpcyBmb3IgU1JQIGNsaWVudCBkZXZpY2Vz IHRoYXQgc2xlZXAgdG8gcmVkdWNlIHBvd2VyIGNvbnN1bXB0aW9uLCB3aGlsZSBiZWluZyBhYmxl IHRvIG9mZmVyIHJlZ2lzdGVyZWQgc2VydmljZShzKSB3aXRob3V0IGludGVycnVwdGlvbi4mcXVv dDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+JnF1b3Q7dGhlIGRldmljZSBpbmNsdWRlcyBhbiBF RE5TKDApIE9XTkVSIE9wdGlvbiBbSS1ELmNoZXNoaXJlLWVkbnMwLW93bmVyLW9wdGlvbl0mcXVv dDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0mZ3Q7IHRoZSByZWZlcmVu Y2UgaGVyZSBpcyBJbmZvcm1hdGlvbmFsOyBob3cgY2FuIHRoaXMgYmU/IFRvIGltcGxlbWVudCB0 aGUgc2xlZXAgcHJveHkgZnVuY3Rpb24gaXQgaXMgbm9ybWF0aXZlIHRvIGluY2x1ZGUgdGhlIG9w dGlvbi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+JnF1b3Q7V2hlbiB0aGUgRE5TIHNlcnZlciBy ZWNlaXZlcyBhIFRDUCBTWU4gb3IgVURQIHBhY2tldCBhZGRyZXNzZWQgdG8mcXVvdDsNCjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LSZndDsgJnF1b3Q7V2hlbiB0aGUgU2xl ZXAgUHJveHkgcmVjZWl2ZXMgYSBUQ1AgU1lOIG9yIFVEUCBwYWNrZXQgYWRkcmVzc2VkIHRvJnF1 b3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4oc2VlIGFsc28gYmVsb3cg Y29tbWVudCk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+JnF1b3Q7dGhlIFNsZWVwIFByb3h5IG11 c3QgYmUgb24gdGhlIHNhbWUgbGluayZxdW90OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+LSZndDsgdGhlIHRlcm0gJnF1b3Q7U2xlZXAgUHJveHkmcXVvdDsgaXMgbm90IGlu dHJvZHVjZWQuIEluIHRoZSBwcmlvciB0ZXh0IHdoZW4gaXQgc2F5cyAmcXVvdDtzaG91bGQgc2V0 IHVwIGEgcHJveHkmcXVvdDsgdGhlIG5hbWUgY291bGQgYmUgZm9ybWFsbHkgaW50cm9kdWNlZCBl LmcuICZxdW90O3Nob3VsZCBzZXQgdXAgYSBTbGVlcCBQcm94eSZxdW90OyBvciAmcXVvdDtzaG91 bGQgc2V0IHVwIGEgcHJveHksIGNhbGxlZCB0aGUgU2xlZXAgUHJveHksICZxdW90OzxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5PdmVyYWxsLCBJIG1pc3Mgc29tZSBkZXRhaWxzIGFib3V0IHdoYXQg dGhlIFNsZWVwIFByb3h5IGRvZXMgb25jZSBpdCByZWNlaXZlcyBhIFRDUCBTWU4gb3IgVURQIHBh Y2tldCBhbmQgaXQgaGFzIHdva2VuIHVwIHRoZSBzbGVlcHkgZGV2aWNlLiBEb2VzIGl0IHRoZW4g c3RvcCB0aGUgQVJQL05EIHByb3h5aW5nIGZvciB0aGUgc2xlZXB5IGRldmljZSByaWdodCBhd2F5 PyBBbmQgd2hlbiB3b3VsZCBpdCBhZ2Fpbg0KIHJlc3VtZSBwcm94eWluZz88bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldoYXQgZG9lcyB0aGUgcHJveHkgZG8gd2l0aCB0aGUg cmVjZWl2ZSBUQ1AgU1lOIG9yIFVEUCBwYWNrZXQsIGRpc2NhcmQgb3IgZm9yd2FyZCB0byB0aGUg d29rZW4gc2xlZXB5IGRldmljZT8gKEFmdGVyIGhvdyBtdWNoIHdhaXRpbmcgdGltZT8pPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPioqKiA2LjE8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZxdW90O1NlcnZpY2UgRGlzY292ZXJ5IFByb3RvY29sIHNlcnZlcnMmcXVvdDs8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0mZ3Q7IGlzIHRoaXMgdGVybSBkZWZp bmVkPyBTaG91bGQgd2Ugc2F5IFNSUCBzZXJ2ZXJzIGhlcmU/PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZxdW90O2EgcHJvbWlzZSBtYWRlIGJ5IHRoZSByZWdpc3RyYXRpb24gcHJvdG9jb2wmcXVv dDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0mZ3Q7ICZxdW90O2EgcHJv bWlzZSBtYWRlIGJ5IHRoZSBzZXJ2aWNlIHJlZ2lzdHJhdGlvbiBwcm90b2NvbCZxdW90OzxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mcXVvdDtyZXBsYWNpbmcgYWxsIG9yIHBhcnQgb2YgdGhlIHNl cnZpY2UgcmVnaXN0cmF0aW9uIGluZm9ybWF0aW9uIHdpdGggaW5mb3JtYXRpb24gcHJvdmlkZWQg YnkgYW4gU1JQIGNsaWVudCZxdW90OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+LSZndDsgdGhlICZxdW90O1NSUCBjbGllbnQmcXVvdDsgbWVudGlvbmVkIGhlcmUgSSB0aGlu ayBzaG91bGQgYmUgJnF1b3Q7RE5TIGNsaWVudCZxdW90Oy4gQmVjYXVzZSB0aGUgY2FzZSBtZW50 aW9uZWQgbG9va2VkIGxpa2UgYW4gYXV0aGVudGljYXRlZCAobm9uLVNSUCkgRE5TIGNsaWVudCBt YWtpbmcgRE5TIHVwZGF0ZXMgdG8gcmVjb3JkcyB0aGF0IHdlcmUgYWRkZWQgYnkgYW4gU1JQIGNs aWVudC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+KioqIDcgJnF1b3Q7UHJpdmFjeSBDb25zaWRl cmF0aW9ucyZxdW90OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyB0 ZXh0IG1lbnRpb25zIHRoZSByZXF1aXJlbWVudHMgZm9yIFRMUy4gUGVyaGFwcyB0aGUgVExTIGJp dHMgYXJlIGJldHRlciBwbGFjZWQgaW4gU2VjdGlvbiA2LCBhbmQgU2VjdGlvbiA3IGlmIG5lZWRl ZCBjYW4gcmVmZXIgYmFjayB0byB0aGF0LiBUbyBtZSBUTFMgc2VlbXMgb25lIG9mIHRoZSBrZXkg aW5ncmVkaWVudHMgdG8gc2VjdXJlIHRoZSBwcm90b2NvbCBzbyBJJ2QgZXhwZWN0IHRvIHJlYWQg c29tZXRoaW5nDQogLyBtb3N0LXRoaW5ncyBhYm91dCB0aGlzIGluIFNlY3Rpb24gNi4mbmJzcDsm bmJzcDsgKE1heWJlIEknbSB3cm9uZyBoZXJlIGluIGNhc2UgVExTIGNhbid0IHByb3ZpZGUgdGhl IGF1dGhlbnRpY2F0aW9uIC0gc2luY2UgaW4gc29tZSBkZXBsb3ltZW50cyB0aGUgY2xpZW50IG1h eSBoYXZlIG5vIHRydXN0IGFuY2hvciBvZiB0aGUgZG9tYWluIGluc3RhbGxlZCBhIHByaW9yaSwg c28gaXQgY2FuJ3QgYXV0aGVudGljYXRlIHRoZSBTUlAgc2VydmVyIGV2ZW4gd2hlbg0KIFRMUyBp cyB1c2VkLik8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+KioqIDkuMjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+JnF1b3Q7QXZhaWxhYmlsaXR5IG9mIEROUyBTZXJ2aWNlIERp c2NvdmVyeSBTZXJ2aWNlIFJlZ2lzdHJhdGlvbiBQcm90b2NvbDxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7IFNlcnZpY2UgZm9yIGEgZ2l2ZW4gZG9tYWlu IGlzIGFkdmVydGlzZWQgdXNpbmcgdGhlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDsmbmJzcDsgJnF1b3Q7X2Ruc3NkLXNycC5fdGNwLiZsdDtkb21haW4mZ3Q7LiZx dW90OyZuYnNwOyBTUlYgcmVjb3JkIGdpdmVzIHRoZSB0YXJnZXQgaG9zdCBhbmQ8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyBwb3J0IHdoZXJlIEROU1NE IFNlcnZpY2UgUmVnaXN0cmF0aW9uIFNlcnZpY2UgaXMgcHJvdmlkZWQgZm9yIHRoZTxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7IG5hbWVkIGRvbWFpbi4m cXVvdDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyA8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0mZ3Q7IHNlZW1zIGxpa2UgYSBn cmFtbWFyIGlzc3VlIGhlcmUuIFdhcyB0aGlzIG1lYW50IGFzIGEgc2luZ2xlIHNlbnRlbmNlLCBv ciBhcyAyIHNlbnRlbmNlcyBzZXBhcmF0ZWQgYnkgYSBkb3QgYmVmb3JlIHRoZSAmcXVvdDtTUlYg cmVjb3JkJnF1b3Q7IHRleHQ/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5F LmcuIEkgY291bGQgaW50ZXJwcmV0IGFzICZxdW90O3VzaW5nIHRoZSBYIFNSViByZWNvcmQgd2hp Y2ggZ2l2ZXMgdGhlIFkmcXVvdDsgb3IgYXMgJnF1b3Q7dXNpbmcgdGhlIFggbmFtZS4gVGhlIFNS ViByZWNvcmQgZ2l2ZXMgdGhlIFkmcXVvdDsuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5TaW1pbGFyIHBvaW50IGZvciA5LjMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBp biAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IERhdmlkIFNjaGluYXpp ICZsdDs8YSBocmVmPSJtYWlsdG86ZHNjaGluYXppLmlldGZAZ21haWwuY29tIj5kc2NoaW5hemku aWV0ZkBnbWFpbC5jb208L2E+Jmd0Ow0KPGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgQXVndXN0 IDE2LCAyMDIxIDIwOjA5PGJyPg0KPGI+VG86PC9iPiBFc2tvIERpamsgJmx0OzxhIGhyZWY9Im1h aWx0bzplc2tvLmRpamtAaW90Y29uc3VsdGFuY3kubmwiPmVza28uZGlqa0Bpb3Rjb25zdWx0YW5j eS5ubDwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBETlNTRCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRu c3NkQGlldGYub3JnIj5kbnNzZEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+ IFJlOiBbZG5zc2RdIFdHTEMgZm9yIGRyYWZ0LWlldGYtZG5zc2Qtc3JwPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIEVza28sPG86cD48L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGF0J3MgcmVhc29uYWJsZSwgd2UgY2FuIHdhaXQgYSBm ZXcgbW9yZSBkYXlzIGZvciB5b3UgdG8gcmV2aWV3LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5EYXZpZDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBTdW4sIEF1ZyAxNSwgMjAyMSBhdCAx OjM3IFBNIEVza28gRGlqayAmbHQ7PGEgaHJlZj0ibWFpbHRvOmVza28uZGlqa0Bpb3Rjb25zdWx0 YW5jeS5ubCI+ZXNrby5kaWprQGlvdGNvbnN1bHRhbmN5Lm5sPC9hPiZndDsgd3JvdGU6PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2lu LWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkhlbGxvIERh dmlkLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+RHVlIHRvIGhvbGlkYXkgSSBtaXNzZWQg dGhpcyBsYXN0IGNhbGwuIEhhdmluZyByZXZpZXdlZCBhbiBlYXJsaWVyIHZlcnNpb24gSSB3b3Vs ZCBsaWtlIHRvIGNoZWNrIGlmIHRoZSBpc3N1ZXMgYXJlIHNvbHZlZCBub3c7IGFuZCBjYW4gYW5z d2VyIHRoZSBxdWVzdGlvbiBieSBUdWVzZGF5IG9yIFdlZG5lc2RheQ0KIGlmIHRoYXTigJlzIG9r LiAoSW5zdGVhZCBvZiB0b2RheSk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkJlc3QgcmVn YXJkczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5Fc2tvPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRp bmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj5Gcm9tOjwv Yj4gZG5zc2QgJmx0OzxhIGhyZWY9Im1haWx0bzpkbnNzZC1ib3VuY2VzQGlldGYub3JnIiB0YXJn ZXQ9Il9ibGFuayI+ZG5zc2QtYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7DQo8Yj5PbiBCZWhhbGYg T2YgPC9iPkRhdmlkIFNjaGluYXppPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgSnVseSAy OCwgMjAyMSAyMzo1Nzxicj4NCjxiPlRvOjwvYj4gRE5TU0QgJmx0OzxhIGhyZWY9Im1haWx0bzpk bnNzZEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmRuc3NkQGlldGYub3JnPC9hPiZndDs8YnI+ DQo8Yj5TdWJqZWN0OjwvYj4gW2Ruc3NkXSBXR0xDIGZvciBkcmFmdC1pZXRmLWRuc3NkLXNycDxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkhpIEROU1NE IGVudGh1c2lhc3RzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+VGhpcyBlbWFpbCBzdGFydHMgYW4gb2ZmaWNpYWwgV29ya2luZyBHcm91 cCBMYXN0IENhbGwgZm9yJm5ic3A7ZHJhZnQtaWV0Zi1kbnNzZC1zcnAuIFRoaXMgY2FsbCBhc2tz IHdoZXRoZXIgd2UgYmVsaWV2ZSB0aGUgZG9jdW1lbnQgaXMgcmVhZHkgZm9yIHB1YmxpY2F0aW9u LiBBcyBzdWNoIHdlIGFyZSBhc2tpbmcgdHdvDQogcXVlc3Rpb25zOjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+MSkgaWYgeW91IGJlbGll dmUgdGhpcyBkb2N1bWVudCBpcyBub3QgcmVhZHkgdG8gcHVibGlzaCwgcGxlYXNlIHNwZWFrIHVw IG5vdzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+MikgaWYgeW91IGhhdmUgcmVhZCB0aGUgZG9jdW1lbnQgYW5kIHRoaW5rIGl0IGlzIHJl YWR5LCBwbGVhc2Ugc2F5IHNvIGFzIHdlbGw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkZvciB0aGlzIGNhbGwgdG8gc3VjY2VlZCwgd2Un bGwgbmVlZCBzdGF0ZW1lbnRzIG9mIGV4cGxpY2l0IHN1cHBvcnQgZnJvbSBwZW9wbGUgd2hvIGhh dmUgcmVhZCB0aGUgZHJhZnQuIFBsZWFzZSBzZW5kIHN0YXRlbWVudHMgaW4gZWl0aGVyIGRpcmVj dGlvbiBhcyByZXNwb25zZXMgdG8gdGhpcyBlbWFpbC4gVGhpcw0KIGNhbGwgd2lsbCBiZSBvcGVu IHVudGlsIDIwMjEtMDgtMTUgMjM6NTkgVVRDLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhhbmtzLDxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5EYXZpZDxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_AM8P190MB0979C97C6F267BD5E1720A7BFDC09AM8P190MB0979EURP_-- From nobody Thu Aug 19 04:26:04 2021 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B61B03A0CC8 for ; Thu, 19 Aug 2021 04:26:01 -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, 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.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=iotconsultancy.nl 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 DaOCxa_kCjUQ for ; Thu, 19 Aug 2021 04:25:55 -0700 (PDT) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2131.outbound.protection.outlook.com [40.107.20.131]) (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 079313A0CC5 for ; Thu, 19 Aug 2021 04:25:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CfV2rysykF20suVXw9ibCIwuaLCZOp2xojeKxHqXbJaljSZtnZRxbuLhrOwGuX8J9MREMboe1ToUqJeFWJZJGoM0IFlbV+jtMUCeEMk+BXrGEE4IAnUA0+fKCS9EnTGtdLJJHzmAon2TKuzave2kxHRTOoPjynNgsc1FptTJmDt8OTZndlARVj/rLkYfCYg0utARQFtn1E75EYHSstIwZM3SjiVdlU/NuWEcCx4zjb+WwnRwxDfmm8Ma9NA9dlFm8QkFpw991md+ipoCz2C7g/xWeNqmsmkXUMGXoYLf+Qf/x1ZSClwZwZ5BahLLdv348tp0KsNsBbM45ySih7c7/w== 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=kvHyUb5tlpp9LCW+sQpayTm6HGHgXKxiyGmHjP7Npmk=; b=iWczHj2c1WGk0JRek/KpcjPmGAyqRtADK1NZnGAoqIWPtIJ3RjwR5dm1OuXEyke1dWeGVLF0u9eiGvMolQYf7BMtB8JIlhubyKRTc1WBvpTGvBR4k4Wjauz1Cz2eTGTz5LrIiIGwrTvBRYkOb2xTs0hzi3UcF2W6GN5z9JzYdzWLRLUEGZfCFTD2BMYBlLn8EDy0kF3gKbWL4MPWWT2d5hiKF4wd1hSQHAn9+EZs/yDZyBF157Ag6GLxUjQXVdJKIW28+GoP2RDba+RGwrFJ/zngfq0wcKo57O9sgklQVzHMvQxWQ399x0/yGAR6Xvkn14anma2xRNxh7ImK/ncGlQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=iotconsultancy.nl; dmarc=pass action=none header.from=iotconsultancy.nl; dkim=pass header.d=iotconsultancy.nl; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iotconsultancy.nl; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=kvHyUb5tlpp9LCW+sQpayTm6HGHgXKxiyGmHjP7Npmk=; b=f98aqHzweeHP5Z46iAl8TDSQ6hB5SeAgyjXZQmMCt6MLV+n0la8vXLsXc9BHCQjTmU62wD5W1oOiridnS17hams30b/zAcVwUmbYi5s4Lkr+vMg9f22mEEPL7kcc9fZPFgrb45Wk3X1CSvfOMfF64A8LyU1d5j7mf48ANGIs0Cw= Received: from AM8P190MB0979.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:1d3::8) by AM4P190MB0082.EURP190.PROD.OUTLOOK.COM (2603:10a6:200:62::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4436.19; Thu, 19 Aug 2021 11:25:52 +0000 Received: from AM8P190MB0979.EURP190.PROD.OUTLOOK.COM ([fe80::44fa:5ced:a434:f7e8]) by AM8P190MB0979.EURP190.PROD.OUTLOOK.COM ([fe80::44fa:5ced:a434:f7e8%9]) with mapi id 15.20.4436.019; Thu, 19 Aug 2021 11:25:52 +0000 From: Esko Dijk To: DNSSD CC: Ted Lemon Thread-Topic: Parsing Service Discovery Instruction for SRP (2.3.1.1) Thread-Index: AdeUMwjaRIocQMs/T761taAG+UH0OwAuQKpQ Date: Thu, 19 Aug 2021 11:25:51 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none; ietf.org; dmarc=none action=none header.from=iotconsultancy.nl; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 0350abb9-8b99-44b7-76ca-08d963041a42 x-ms-traffictypediagnostic: AM4P190MB0082: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: n56xS2fYWSAm4rdbNO6WCSEuq9Lv19lY6/0u91kdAORbF5WAlPiJT9awCXvpyma4mO3c9g2jjLPEK3PYyVkc3Z5GLZnK5djz4ylp77NDQZTfrrJU3t8R1SaoKV73NjLU/IUP7l+dadYM+XInB4zYrpB+8UmqD4zxFYg+MgFsMWcTwR5fAHfkWAwC0c55QTKSUqKOYr/RrKhdp5XsJrCK945cPbnGVe9Sx7ynL+ICLHtTlgn/jGrLen9C2scuG4ZxrVZYA9sbOMSz9I5MZEP95kefqkK2MSwl+9J1/7GbH1O8gTbaHqWFIC6XFuSo3bfk06fBBpcUCzttLv8yy0LB0x/P5NodTcrhdgCvhffwyRl0r6o8hoAl6jsMs3lXbJuwoB69xlaUZtkPgP/H0tIF4Zu0NtGW/kzd1JeAKjLb+0xQdn3tkJQVqc6/4fxkifAQI7oYlIwrZ7ltuzQ7EIE93UzItv99mll/hu5vwWTKhgM1e9djuSY045l5FJcHVR6JMEamP1A7buIPU6Cmm7QQG+M5I1iIu/XAqA9HEEnCQb5RrtUkMDpCjg5+tyCr2+K8bwRlbQXN64RB4rgGPZ9FqyRgn8GqkZ0E1lNozqGrTyLv8tLNn8ilfLtkZ2oyHgw2uMQ1kn19SbeY1SP7wSYWSsvQDj0205TRaA1dBlgKoj85uM23NKxg5dEKqYYYvGkDjK8JbszslMf1jZVQNrze7pMzfpXYsNMTNvooMmRsrLfkpuLFdJ3yTso8EcOFZXc5aCfa4+MPFTq3dUjAcLG9foyWKevxVU7HqMJbYgncJ/Q= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM8P190MB0979.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(366004)(39830400003)(136003)(376002)(396003)(346002)(122000001)(38100700002)(44832011)(508600001)(4326008)(33656002)(166002)(2906002)(86362001)(83380400001)(9686003)(55016002)(8676002)(8936002)(66946007)(76116006)(5660300002)(186003)(316002)(6506007)(53546011)(7696005)(6916009)(71200400001)(38070700005)(66556008)(66476007)(64756008)(66446008)(52536014); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?SVdFVGorYThadEhXSkVTUDBVTXhLcERjTEVVTGhxZnRpWWdiL1Exdi8yaFll?= =?utf-8?B?S0JCcnpzRmZxUmNkbFJoeHJsU0MrL1VRdm5tN2xKODFpTlplUG1JTWU2M1Uy?= =?utf-8?B?cWhQWSt3TGI4MlNrREtEUVpOci9mcGw4STAwWUg3NU1TYXpOeWNIeGxMVEJT?= =?utf-8?B?SWl1K0owaWhsMHpEaXlkMDU3R1N0Y3JKQ2hkaDA0dDZKZE8zUTNlSDU1Nzgy?= =?utf-8?B?UTBuSXdlS25lYWNHTnRPYlh3WEx1bGJuMHFJaEJmMkJxOVRhTlJZNkh2TWNM?= =?utf-8?B?c1hDMzM5QzUwakF3dGMzejl6aGQvaXp6RlY1ZHRtWlRic0ZDQUdHdy9XRjYv?= =?utf-8?B?b001MWpjWlNRWHRqUTdpWGFEV2tBcmRmekxqOVVGUk8zV3RJVVlONDRnemdM?= =?utf-8?B?WW0zbi9KZHhVZ29ZZmhLTnNNRlJRK2NEYjF3eFBUVGRSWHVnWTQ1SGdsQjFT?= =?utf-8?B?M0tSUTRsazFQVFhtbCs3dUprbVEzNDdKK0FxQ2t4Y0RiTWZpdFRzbWQ0K25C?= =?utf-8?B?eWRhOGNhRTEyTTcyL2tEc2QvREVxM3FFaXViRE5vV09RQzZNYVVYWWs4eXgr?= =?utf-8?B?TEhjK1BDTFNQUFRqKzcxemJyUUhlcGhnZXdyTm9HeTF0S2xJS0YvdEcvN3RD?= =?utf-8?B?SFkxR0R4dDdRM3VqY1ZmMkJYcFMwc1ZEeTUzMDRrdXNuSCtQQURIN2VURVBZ?= =?utf-8?B?RnhLbDJ2dDVEbnBOaFJaMmpUZTdWOHdjSWFBczF3WXBQWUhhUC9OUnpPU0FF?= =?utf-8?B?bGNnVURSZXZIWDNjKzMrRkRMSXlGdEVrdjZHbzE1S3dVSDl0OXFXeWdXbmNx?= =?utf-8?B?NVUvQ1pEb1BQOUt1R3BjbkpvQjk5WUxVTGZZUEdLeUlJU3RVSUhNcndNR3g1?= =?utf-8?B?Rms5Y2JSWk94KzV4VHZTZUtGYVNNZlBHK0xaOTlNZW1PdE8rVE1LQ1N1TXR2?= =?utf-8?B?azJlWGgvZFd6YWpyTTRkSmxSUUVtUWJ2Ty9yNGdpNXdVUGlsVlhHOTN4bit1?= =?utf-8?B?Tk96di8vMVppc2E4SWN5SzBZRlhOZGRWSkQydEt1aGtpaVZldmVselpURHF0?= =?utf-8?B?cVFaa0ZVTHR4QXlNWlJxL1NKVHFYampEczVqRzI3MW43KzAzb2RlTkRwRUpE?= =?utf-8?B?eDFkbWtZYmp2SVFtaUxObzFzelh5OGVlM1JoVXFmako0VGx1VUVFWWczd1o3?= =?utf-8?B?b1IweDI5empHdml6NTl3OFBtYndia0RLNlRpRWhoRThJb1M3OUhqSE9mZmw4?= =?utf-8?B?YXFIRVV5WEZwUHZBREdPOXFZWGx3ZDAzWkZzWGRFRzdkbU5PMlJmeUlxMVZC?= =?utf-8?B?eVlnZWhsaUlkUHNwM3p5b1JnaGxjZGp1dVJ1eFBnQVZjNGtMeEEwamw2MUlW?= =?utf-8?B?YmY1VVVqbXNGS05NUTJmR08xc3NMbzBQM3NZMDlrNmFPN1dnTEgrTXhlRlYr?= =?utf-8?B?RXVjbFg4Yk1pUGN2cHNPNlVPOFNkYXdlcEVuTDFiZXhZdFlYTHFzdExVUlR4?= =?utf-8?B?SGY1MXR4OGdLbHRnY3pKTkVVcmYySmdUVUUrMSs4NnBkTzR1WVZkNGRnOXMy?= =?utf-8?B?cVZRblZHSlEzQ3hicHF2Y3V6MnRhWlBtdFh0aitNQkVwMk9nY3RXdDFINmhD?= =?utf-8?B?eERtd0R5ZVNBQjNkaFpQKytDblduQ3FweTc4aFdhRGRDMCtaNVVxa1VSbzhq?= =?utf-8?B?TE16Q3VOT0pOcmhCTUlnZkhBaU13UTZxZTMydk5OYVVQMXJmV1VUdk1EMm9q?= =?utf-8?B?NGtJNFVZQ2gxV3pwVDlHMXpLbjVjRjBKQXJvMEJqVDlReW82U3dUV2UwREla?= =?utf-8?B?MEJ5TzV4SnIvZVRJNjczZjRETHg5MTl2RGlyZk0xSEJHSUVwZThvak1pMTBS?= =?utf-8?Q?A+ZgiTt5cT8O5?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_AM8P190MB09792F669425E7BDD1C0E500FDC09AM8P190MB0979EURP_" MIME-Version: 1.0 X-OriginatorOrg: iotconsultancy.nl X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM8P190MB0979.EURP190.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 0350abb9-8b99-44b7-76ca-08d963041a42 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Aug 2021 11:25:52.0352 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 58bbf628-15d2-46bc-820b-863b6774d44b X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: uDNyiN+vZRALVAGZxxpmZWFNfGn5Kk0hW7xOULMccgdvkwV94OEX/rjEvyzUtIwBp3c5VQs9ddQAbpgqbX4sFC2PpWgGC83fE+P7cuLoAx0= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4P190MB0082 Archived-At: Subject: Re: [dnssd] Parsing Service Discovery Instruction for SRP (2.3.1.1) X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2021 11:26:02 -0000 --_000_AM8P190MB09792F669425E7BDD1C0E500FDC09AM8P190MB0979EURP_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QXMgYW4gYWx0ZXJuYXRpdmUgdG8gbXkgYmVsb3cgZW1haWwsIGhlcmUgaXMgYW5vdGhlciAoc2lt cGxlcikgdGV4dCBmb3IgU2VjdGlvbiAyLjMuMS4xIDoNCg0KDQoNCkFuIGluc3RydWN0aW9uIHdp dGhpbiBhbiBTUlAgVXBkYXRlIGlzIGEgU2VydmljZSBEaXNjb3ZlcnkgSW5zdHJ1Y3Rpb24gaWYN Cg0KDQoNCiAgICogIGl0IGNvbnRhaW5zIGV4YWN0bHkgb25lICJBZGQgdG8gYW4gUlJTZXQiIChb UkZDMjEzNl0sIFNlY3Rpb24gMi41LjE8aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv aHRtbC9yZmMyMTM2I3NlY3Rpb24tMi41LjE+KSBvciBleGFjdGx5IG9uZSAiRGVsZXRlIGFuIFJS IGZyb20gYW4gUlJTZXQiIChbUkZDMjEzNl0sIFNlY3Rpb24gMi41LjQ8aHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvaHRtbC9yZmMyMTM2I3NlY3Rpb24tMi41LjE+KSBSUiB1cGRhdGUs DQogICAgICAgbyAgd2hpY2ggdXBkYXRlcyBhIFBUUiB0eXBlIFJSLA0KICAgICAgIG8gIHdoaWNo IHBvaW50cyB0byBhIFNlcnZpY2UgSW5zdGFuY2UgTmFtZSB0aGF0IGlzIGJlaW5nIHVzZWQgaW4g YXQgbGVhc3Qgb25lIG90aGVyIEluc3RydWN0aW9uIGluIHRoaXMgU1JQIFVwZGF0ZSwNCg0KICAg KiBhbmQgaXQgY29udGFpbnMgbm8gb3RoZXIgUlIgVVBEQVRFcy4NCg0KVGhpcyBlbGltaW5hdGVz IGFsbCByZWZlcmVuY2VzIHRvIGV4dGVybmFsIFNlcnZpY2UgRGVzY3JpcHRpb24gSW5zdHJ1Y3Rp b25zIHRvIHNpbXBseSB0aGUgY29uZGl0aW9ucy4gRHVlIHRvIHRoZSBTZWN0aW9uIDIuMy4yIHJl cXVpcmVtZW50cyBvbiB0aGUg4oCcaW5zdHJ1Y3Rpb25z4oCdIGl0IGxvb2tzIGxpa2UgaXQgaXMg bm90IG5lY2Vzc2FyeSB0byBkZWZpbmUgdGhlc2UgYWxyZWFkeSBhcyBwYXJ0IG9mIHRoZSAyLjMu MS4xIHRleHQuICAoVGhlIFNlY3Rpb24gMi4zLjIgcmVxdWlyZW1lbnRzIHdpbGwgYWxyZWFkeSB3 ZWVkIG91dCB0aGUgYmFkIGNhc2VzLikNCg0KQmVzdCByZWdhcmRzDQpFc2tvDQoNCkZyb206IEVz a28gRGlqaw0KU2VudDogV2VkbmVzZGF5LCBBdWd1c3QgMTgsIDIwMjEgMTU6MjUNClRvOiBETlNT RCA8ZG5zc2RAaWV0Zi5vcmc+DQpDYzogVGVkIExlbW9uIDxtZWxsb25AZnVndWUuY29tPg0KU3Vi amVjdDogUGFyc2luZyBTZXJ2aWNlIERpc2NvdmVyeSBJbnN0cnVjdGlvbiBmb3IgU1JQICgyLjMu MS4xKQ0KDQpIaSBhbGwsIFRlZCwNCg0KV2hpbGUgZG9pbmcgbXkgU1JQIHJldmlldyBJIGZvdW5k IFNlY3Rpb24gMi4zLjEuMSBvbiBTZXJ2aWNlIERpc2NvdmVyeSBJbnN0cnVjdGlvbiBhIGJpdCBk aWZmaWN1bHQgdG8gcGFyc2U6DQoNCg0KImlmIHRoZSBTZXJ2aWNlIERpc2NvdmVyeSB1cGRhdGUg aXMgYW4gIkFkZCB0byBhbiBSUlNldCIgaW5zdHJ1Y3Rpb24sIHRoZSBTZXJ2aWNlIERlc2NyaXB0 aW9uIEluc3RydWN0aW9uIGRvZXMgbm90IG1hdGNoIGlmIg0KDQotPiBmb3IgbWUgdW5jbGVhciB3 aGF0IHRoZSAnZG9lcyBub3QgbWF0Y2gnIHJlZmVycyB0by4gIFdoYXQgaXMgbWF0Y2hlZCB3aXRo IHdoYXQ/DQoNCldoeSBpcyBTZXJ2aWNlIERpc2NvdmVyeSBJbnN0cnVjdGlvbiBtZW50aW9uaW5n IOKAnHRoZeKAnSBTZXJ2aWNlIERlc2NyaXB0aW9uIEluc3RydWN0aW9uPyAoV2hpY2ggb25lPykN Cg0KDQoNCiIgaWYgdGhlIFNlcnZpY2UgRGlzY292ZXJ5IEluc3RydWN0aW9uIGlzIGFuICJEZWxl dGUgYW4gUlIgZnJvbSBhbiAgUlJTZXQiIHVwZGF0ZSwgIg0KDQotPiB0aGUgYnVsbGV0IGxpc3Qg dHJpZXMgdG8gZGVmaW5lIHdoYXQgY29uc3RpdHV0ZXMgYSBTZXJ2aWNlIERpc2NvdmVyeSBJbnN0 cnVjdGlvbi4gTm93IHRoaXMgYnVsbGV0IHBvaW50IG1lbnRpb25zIGEgU2VydmljZSBEaXNjb3Zl cnkgSW5zdHJ1Y3Rpb24sIGV2ZW4gdGhvdWdoIHdlIGRvbid0IGtub3cgeWV0IHdoZXRoZXIgdGhp cyBpbnN0cnVjdGlvbiBjb25zdGl0dXRlcyBhIFNlcnZpY2UgRGlzY292ZXJ5IEluc3RydWN0aW9u IG9yIG5vdCEgVGhlIGJ1bGxldCBsaXN0IHdhcyB0aGVyZSBpbiB0aGUgZmlyc3QgcGxhY2UgdG8g ZmluZCB0aGlzIG91dCBzbyB0aGUgaW5zdHJ1Y3Rpb24gYXQgdGhpcyBwb2ludCBtYXkgb3IgbWF5 IG5vdCBiZSBvZiB0aGUgU2VydmljZSBEaXNjb3ZlcnkgSW5zdHIgdHlwZS4NCg0KDQoNCkJlbG93 ICBpcyBhbiBhdHRlbXB0ZWQgcmV3b3JkaW5nIG9mIHRoZSBlbnRpcmUgc2VjdGlvbiwgdG8gc2lt cGxpZnkgYW5kIGNsYXJpZnkg4oCTIHNvbWUgcGFydHMgSSBoYXZlIHByb2JhYmx5IHdyb25nIGJ1 dCBJIG5lZWQgdGhpcyB0byB1bmRlcnN0YW5kIHdoYXQgdGhlIGludGVuZGVkIGRlZmluaXRpb24g aXMgc28gSSBjYW4gZ2l2ZSByZXdvcmRpbmcgc3VnZ2VzdGlvbnMuDQoNCg0KDQpBbiBpbnN0cnVj dGlvbiB3aXRoaW4gYW4gU1JQIFVwZGF0ZSBpcyBhIFNlcnZpY2UgRGlzY292ZXJ5IEluc3RydWN0 aW9uIGlmDQoNCg0KDQogICAqICBpdCBjb250YWlucyBleGFjdGx5IG9uZSAiQWRkIHRvIGFuIFJS U2V0IiAoW1JGQzIxMzZdLCBTZWN0aW9uIDIuNS4xPGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2h0bWwvcmZjMjEzNiNzZWN0aW9uLTIuNS4xPikgb3IgZXhhY3RseSBvbmUgIkRlbGV0 ZSBhbiBSUiBmcm9tIGFuIFJSU2V0IiAoW1JGQzIxMzZdLCBTZWN0aW9uIDIuNS40PGh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvcmZjMjEzNiNzZWN0aW9uLTIuNS4xPikgUlIg dXBkYXRlIGJ1dCBubyBhZGRpdGlvbmFsIFJSIFVQREFURXMsDQogICAqICB3aGljaCB1cGRhdGVz IGEgUFRSIHR5cGUgUlIsDQogICAqICB3aGljaCBwb2ludHMgdG8gYSBTZXJ2aWNlIEluc3RhbmNl IE5hbWUsDQogICAqICBmb3Igd2hpY2ggU2VydmljZSBJbnN0YW5jZSBOYW1lIGFsc28gYSBTZXJ2 aWNlIERlc2NyaXB0aW9uIEluc3RydWN0aW9uIGlzIHByZXNlbnQgaW4gdGhlIHNhbWUgU1JQIFVw ZGF0ZSwNCiAgICogIGFuZCBpbiBjYXNlIHRoZSBzaW5nbGUgY29udGFpbmVkIFJSIHVwZGF0ZSBp cyAiQWRkIHRvIGFuIFJSU2V0IiwgdGhlIFNSUCBVcGRhdGUgYWxzbyBjb250YWlucyBhIFNlcnZp Y2UgRGVzY3JpcHRpb24gSW5zdHJ1Y3Rpb24gaW5jbHVkaW5nIG9uZSAiQWRkIHRvIGFuIFJSc2V0 IiBSUiB1cGRhdGUgZm9yIHRoZSBTUlYgdHlwZSBSUg0KICAgICAgZGVmaW5pbmcgdGhlIHNhbWUg U2VydmljZSBJbnN0YW5jZSBOYW1lOw0KICAgKiBvciBpbiBjYXNlIHRoZSBzaW5nbGUgY29udGFp bmVkIFJSIHVwZGF0ZSBpcyAiRGVsZXRlIGFuIFJSIGZyb20gYW4gUlJTZXQiLCB0aGUgU1JQIFVw ZGF0ZSBjb250YWlucyBubyBTZXJ2aWNlIERlc2NyaXB0aW9uIEluc3RydWN0aW9uIGluY2x1ZGlu ZyBhbiAiQWRkIHRvIGFuIFJSc2V0IiB1cGRhdGUgZm9yIHRoZSBzYW1lIFNlcnZpY2UgSW5zdGFu Y2UgTmFtZS4NCg0KDQoNCkNvcnJlY3Rpb25zL2ZlZWRiYWNrIGlzIHdlbGNvbWUhDQoNCg0KQmVz dCByZWdhcmRzDQpFc2tvDQoNCklvVGNvbnN1bHRhbmN5Lm5sICB8ICBFbWFpbC9UZWFtczogZXNr by5kaWprQGlvdGNvbnN1bHRhbmN5Lm5sPG1haWx0bzplc2tvLmRpamtAaW90Y29uc3VsdGFuY3ku bmw+ICAgIHwgICArMzEgNiAyMzg1IDgzMzkNCg0K --_000_AM8P190MB09792F669425E7BDD1C0E500FDC09AM8P190MB0979EURP_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVC My0xMWQxLUEyOUYtMDBBQTAwQzE0ODgyIiB4bWxuczptPSJodHRwOi8vc2NoZW1hcy5taWNyb3Nv ZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9S RUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250 ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBj b250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8c3R5bGU+PCEt LQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpXaW5n ZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9DQpAZm9udC1mYWNlDQoJe2Zv bnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAy IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGku TXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJZm9udC1zaXplOjExLjBw dDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNv SHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojMDU2M0MxOw0KCXRl eHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtz aXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2 LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25z ICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoyMDc3Nzc1NDU2Ow0KCW1zby1saXN0LXR5cGU6 aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczo3NDAyMjUyMTAgLTg5MjAyNjM5NCA2NzY5 ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5 MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6Ljc1aW47DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDsNCgltc28tZmFyZWFzdC1m b250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJY29s b3I6YmxhY2s7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDoxLjI1aW47DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyIsc2VyaWY7fQ0KQGxp c3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjEuNzVpbjsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJn aW4tbGVmdDoyLjI1aW47DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJv bDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjIuNzVpbjsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IixzZXJpZjt9DQpAbGlzdCBsMDps ZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6My4yNWluOw0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglm b250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0 OjMuNzVpbjsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBs aXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6NC4yNWluOw0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciLHNlcmlmO30NCkBsaXN0IGwwOmxldmVsOQ0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgltYXJnaW4tbGVmdDo0Ljc1aW47DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFt aWx5OldpbmdkaW5nczt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4t Ym90dG9tOjBpbjt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlm XS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQi Pg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94 bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjND MSIgdmxpbms9IiM5NTRGNzIiIHN0eWxlPSJ3b3JkLXdyYXA6YnJlYWstd29yZCI+DQo8ZGl2IGNs YXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgc3R5bGU9Im1hcmdpbjowaW4iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5BcyBhbiBhbHRlcm5hdGl2ZSB0byBteSBiZWxv dyBlbWFpbCwgaGVyZSBpcyBhbm90aGVyIChzaW1wbGVyKSB0ZXh0IGZvciBTZWN0aW9uIDIuMy4x LjEgOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDowaW47bWFyZ2luLXJpZ2h0OjBp bjttYXJnaW4tYm90dG9tOjBpbjttYXJnaW4tbGVmdDouNWluIj4NCjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5BbiBpbnN0cnVjdGlvbiB3aXRoaW4gYW4gU1JQIFVw ZGF0ZSBpcyBhIFNlcnZpY2UgRGlzY292ZXJ5IEluc3RydWN0aW9uIGlmDQo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjBpbjttYXJnaW4tcmlnaHQ6 MGluO21hcmdpbi1ib3R0b206MGluO21hcmdpbi1sZWZ0Oi41aW4iPg0KPHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6MGluO21hcmdpbi1yaWdodDowaW47bWFyZ2lu LWJvdHRvbTowaW47bWFyZ2luLWxlZnQ6LjVpbiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEy LjBwdDtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7ICombmJzcDsgaXQgY29udGFpbnMgZXhhY3Rs eSBvbmUgJnF1b3Q7QWRkIHRvIGFuIFJSU2V0JnF1b3Q7ICg8L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHQiPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2h0bWwvcmZjMjEzNiNzZWN0aW9uLTIuNS4xIj5bUkZDMjEzNl0sIFNlY3Rpb24mbmJzcDsyLjUu MTwvYT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPikgb3INCiBleGFjdGx5IG9uZSAmcXVvdDtE ZWxldGUgYW4gUlIgZnJvbSBhbiBSUlNldCZxdW90OyAoPC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvcmZjMjEzNiNzZWN0aW9uLTIuNS4xIj5bUkZD MjEzNl0sIFNlY3Rpb24mbmJzcDsyLjUuNDwvYT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPikg UlIgdXBkYXRlLDxicj4NCiZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtvJm5i c3A7IHdoaWNoIHVwZGF0ZXMgYSBQVFIgdHlwZSBSUiw8YnI+DQombmJzcDsmbmJzcDsgJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7byZuYnNwOyB3aGljaCBwb2ludHMgdG8gYSBTZXJ2aWNlIEluc3Rh bmNlIE5hbWUgdGhhdCBpcyBiZWluZyB1c2VkIGluIGF0IGxlYXN0IG9uZSBvdGhlciBJbnN0cnVj dGlvbiBpbiB0aGlzIFNSUCBVcGRhdGUsPG86cD48L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjxw IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6MGluO21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJv dHRvbTowaW47bWFyZ2luLWxlZnQ6LjVpbiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dDtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7ICogPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTIuMHB0Ij5hbmQgaXQgY29udGFpbnMgbm8gb3RoZXIgUlIgVVBEQVRFcy48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgZWxpbWluYXRlcyBhbGwgcmVmZXJlbmNlcyB0byBl eHRlcm5hbCBTZXJ2aWNlIERlc2NyaXB0aW9uIEluc3RydWN0aW9ucyB0byBzaW1wbHkgdGhlIGNv bmRpdGlvbnMuIER1ZSB0byB0aGUgU2VjdGlvbiAyLjMuMiByZXF1aXJlbWVudHMgb24gdGhlIOKA nGluc3RydWN0aW9uc+KAnSBpdCBsb29rcyBsaWtlIGl0IGlzIG5vdCBuZWNlc3NhcnkgdG8gZGVm aW5lIHRoZXNlIGFscmVhZHkgYXMgcGFydCBvZiB0aGUgMi4zLjEuMQ0KIHRleHQuICZuYnNwOyhU aGUgU2VjdGlvbiAyLjMuMiByZXF1aXJlbWVudHMgd2lsbCBhbHJlYWR5IHdlZWQgb3V0IHRoZSBi YWQgY2FzZXMuKTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CZXN0IHJlZ2FyZHM8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkVza288bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBp biAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBFc2tvIERpamsg PGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgQXVndXN0IDE4LCAyMDIxIDE1OjI1PGJyPg0K PGI+VG86PC9iPiBETlNTRCAmbHQ7ZG5zc2RAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBU ZWQgTGVtb24gJmx0O21lbGxvbkBmdWd1ZS5jb20mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFBh cnNpbmcgU2VydmljZSBEaXNjb3ZlcnkgSW5zdHJ1Y3Rpb24gZm9yIFNSUCAoMi4zLjEuMSk8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIGFsbCwgVGVkLDxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5XaGlsZSBkb2luZyBteSBTUlAgcmV2aWV3IEkgZm91bmQgU2VjdGlv biAyLjMuMS4xIG9uIFNlcnZpY2UgRGlzY292ZXJ5IEluc3RydWN0aW9uIGEgYml0IGRpZmZpY3Vs dCB0byBwYXJzZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW4iPiZxdW90O2lmIHRoZSBTZXJ2aWNl IERpc2NvdmVyeSB1cGRhdGUgaXMgYW4gJnF1b3Q7QWRkIHRvIGFuIFJSU2V0JnF1b3Q7IGluc3Ry dWN0aW9uLCB0aGUgU2VydmljZSBEZXNjcmlwdGlvbiBJbnN0cnVjdGlvbiBkb2VzIG5vdCBtYXRj aCBpZiZxdW90OzxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW4iPi0mZ3Q7IGZv ciBtZSB1bmNsZWFyIHdoYXQgdGhlICdkb2VzIG5vdCBtYXRjaCcgcmVmZXJzIHRvLiZuYnNwOyBX aGF0IGlzIG1hdGNoZWQgd2l0aCB3aGF0Pw0KPG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFy Z2luOjBpbiI+V2h5IGlzIFNlcnZpY2UgRGlzY292ZXJ5IEluc3RydWN0aW9uIG1lbnRpb25pbmcg 4oCcdGhl4oCdIFNlcnZpY2UgRGVzY3JpcHRpb24gSW5zdHJ1Y3Rpb24/IChXaGljaCBvbmU/KTxv OnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW4iPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPHAgc3R5bGU9Im1hcmdpbjowaW4iPiZxdW90OyBpZiB0aGUgU2VydmljZSBEaXNjb3Zlcnkg SW5zdHJ1Y3Rpb24gaXMgYW4gJnF1b3Q7RGVsZXRlIGFuIFJSIGZyb20gYW4mbmJzcDsgUlJTZXQm cXVvdDsgdXBkYXRlLCAmcXVvdDs8bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGlu Ij4tJmd0OyB0aGUgYnVsbGV0IGxpc3QgdHJpZXMgdG8gZGVmaW5lIHdoYXQgY29uc3RpdHV0ZXMg YSBTZXJ2aWNlIERpc2NvdmVyeSBJbnN0cnVjdGlvbi4gTm93IHRoaXMgYnVsbGV0IHBvaW50IG1l bnRpb25zIGEgU2VydmljZSBEaXNjb3ZlcnkgSW5zdHJ1Y3Rpb24sIGV2ZW4gdGhvdWdoIHdlIGRv bid0IGtub3cgeWV0IHdoZXRoZXIgdGhpcyBpbnN0cnVjdGlvbiBjb25zdGl0dXRlcyBhIFNlcnZp Y2UgRGlzY292ZXJ5DQogSW5zdHJ1Y3Rpb24gb3Igbm90ISBUaGUgYnVsbGV0IGxpc3Qgd2FzIHRo ZXJlIGluIHRoZSBmaXJzdCBwbGFjZSB0byBmaW5kIHRoaXMgb3V0IHNvIHRoZSBpbnN0cnVjdGlv biBhdCB0aGlzIHBvaW50IG1heSBvciBtYXkgbm90IGJlIG9mIHRoZSBTZXJ2aWNlIERpc2NvdmVy eSBJbnN0ciB0eXBlLjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW4iPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW4iPkJlbG93ICZuYnNwO2lzIGFu IGF0dGVtcHRlZCByZXdvcmRpbmcgb2YgdGhlIGVudGlyZSBzZWN0aW9uLCB0byBzaW1wbGlmeSBh bmQgY2xhcmlmeSDigJMgc29tZSBwYXJ0cyBJIGhhdmUgcHJvYmFibHkgd3JvbmcgYnV0IEkgbmVl ZCB0aGlzIHRvIHVuZGVyc3RhbmQgd2hhdCB0aGUgaW50ZW5kZWQgZGVmaW5pdGlvbiBpcyBzbyBJ IGNhbiBnaXZlIHJld29yZGluZyBzdWdnZXN0aW9ucy48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxl PSJtYXJnaW46MGluIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6MGluO21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTowaW47bWFyZ2luLWxl ZnQ6LjVpbiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+QW4g aW5zdHJ1Y3Rpb24gd2l0aGluIGFuIFNSUCBVcGRhdGUgaXMgYSBTZXJ2aWNlIERpc2NvdmVyeSBJ bnN0cnVjdGlvbiBpZg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDowaW47bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjBpbjttYXJnaW4t bGVmdDouNWluIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj4m bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OjBpbjttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206MGluO21hcmdpbi1sZWZ0Oi41aW4i Pg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNw OyAqJm5ic3A7IGl0IGNvbnRhaW5zIGV4YWN0bHkgb25lICZxdW90O0FkZCB0byBhbiBSUlNldCZx dW90OyAoPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48YSBocmVmPSJodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL3JmYzIxMzYjc2VjdGlvbi0yLjUuMSI+ W1JGQzIxMzZdLCBTZWN0aW9uJm5ic3A7Mi41LjE8L2E+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij4pIG9yDQogZXhhY3RseSBvbmUgJnF1b3Q7RGVsZXRlIGFuIFJSIGZyb20gYW4gUlJTZXQmcXVv dDsgKDwvc3Bhbj48YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1s L3JmYzIxMzYjc2VjdGlvbi0yLjUuMSI+W1JGQzIxMzZdLCBTZWN0aW9uJm5ic3A7Mi41LjQ8L2E+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4pIFJSIHVwZGF0ZSBidXQgbm8gYWRkaXRpb25hbCBS UiBVUERBVEVzLDxicj4NCiZuYnNwOyZuYnNwOyAqJm5ic3A7IHdoaWNoIHVwZGF0ZXMgYSBQVFIg dHlwZSBSUiw8YnI+DQombmJzcDsmbmJzcDsgKiZuYnNwOyB3aGljaCBwb2ludHMgdG8gYSBTZXJ2 aWNlIEluc3RhbmNlIE5hbWUsPGJyPg0KJm5ic3A7Jm5ic3A7ICombmJzcDsgZm9yIHdoaWNoIFNl cnZpY2UgSW5zdGFuY2UgTmFtZSBhbHNvIGEgU2VydmljZSBEZXNjcmlwdGlvbiBJbnN0cnVjdGlv biBpcyBwcmVzZW50IGluIHRoZSBzYW1lIFNSUCBVcGRhdGUsPGJyPg0KJm5ic3A7Jm5ic3A7ICom bmJzcDsgYW5kIGluIGNhc2UgdGhlIHNpbmdsZSBjb250YWluZWQgUlIgdXBkYXRlIGlzICZxdW90 O0FkZCB0byBhbiBSUlNldCZxdW90OywgdGhlIFNSUCBVcGRhdGUgYWxzbyBjb250YWlucyBhIFNl cnZpY2UgRGVzY3JpcHRpb24gSW5zdHJ1Y3Rpb24gaW5jbHVkaW5nIG9uZSAmcXVvdDtBZGQgdG8g YW4gUlJzZXQmcXVvdDsgUlIgdXBkYXRlIGZvciB0aGUgU1JWIHR5cGUgUlI8YnI+DQombmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZGVmaW5pbmcgdGhlIHNhbWUgU2VydmljZSBJbnN0YW5j ZSBOYW1lOzxicj4NCiZuYnNwOyZuYnNwOyAqIG9yIGluIGNhc2UgdGhlIHNpbmdsZSBjb250YWlu ZWQgUlIgdXBkYXRlIGlzICZxdW90O0RlbGV0ZSBhbiBSUiBmcm9tIGFuIFJSU2V0JnF1b3Q7LCB0 aGUgU1JQIFVwZGF0ZSBjb250YWlucyBubyBTZXJ2aWNlIERlc2NyaXB0aW9uIEluc3RydWN0aW9u IGluY2x1ZGluZyBhbiAmcXVvdDtBZGQgdG8gYW4gUlJzZXQmcXVvdDsgdXBkYXRlIGZvciB0aGUg c2FtZSBTZXJ2aWNlIEluc3RhbmNlIE5hbWUuPC9zcGFuPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6MGluO21hcmdpbi1yaWdodDowaW47bWFyZ2lu LWJvdHRvbTowaW47bWFyZ2luLWxlZnQ6LjVpbiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEy LjBwdDtjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9 Im1hcmdpbjowaW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5D b3JyZWN0aW9ucy9mZWVkYmFjayBpcyB3ZWxjb21lITxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IHN0eWxlPSJtYXJnaW46MGluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpi bGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ QmVzdCByZWdhcmRzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Fc2tvPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFn ZTpFTi1HQiI+SW9UY29uc3VsdGFuY3kubmw8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJtc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1HQiI+Jm5ic3A7IHwmbmJzcDsgRW1haWwvVGVhbXM6DQo8YSBocmVm PSJtYWlsdG86ZXNrby5kaWprQGlvdGNvbnN1bHRhbmN5Lm5sIj5lc2tvLmRpamtAaW90Y29uc3Vs dGFuY3kubmw8L2E+Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsgKzMxIDYNCjwvc3Bh bj4yMzg1IDgzMzk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_AM8P190MB09792F669425E7BDD1C0E500FDC09AM8P190MB0979EURP_-- From nobody Thu Aug 19 12:04:17 2021 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 252FF3A16E6 for ; Thu, 19 Aug 2021 12:04:14 -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 qL-oKv_JTAJg for ; Thu, 19 Aug 2021 12:04:09 -0700 (PDT) Received: from mail-pf1-x431.google.com (mail-pf1-x431.google.com [IPv6:2607:f8b0: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 0BFE13A16D9 for ; Thu, 19 Aug 2021 12:04:08 -0700 (PDT) Received: by mail-pf1-x431.google.com with SMTP id m26so6382487pff.3 for ; Thu, 19 Aug 2021 12:04:08 -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=ZEHDtQ3iin+dMEKEO430ceZ9s6pIcSwPIWeBmXvPbBo=; b=BxtAvkT1RtR/s6gKf8b8i8O6/Utyh9pMMrZyYc7rhozlFoc+W0dVY5916JSALxWpux cvm7oow5onUfYoV9QxNb4GnMGPvU33Pcprg84YHpE7qqjYPx2SOcOMIAEL4nGQ8sOzHH CPdOVuza5wldQScEG88HjZpHdo8HJcxgNzSvpxO/+6lV7o0jZ0WtQMay8XwCjVg325Xn BXv3hi+j8DvZK32SXxJwekgIGsBPJQCCaA85LAYx2ayHM4fk5be6ZeR8L5pA6vU+0YW5 DZyeFWArE9skjDorhGpghNB/rWh2HNXppdZe6uGTf4fnbgxzdKUzb5Lbdt3a804oxPIG SyBQ== 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=ZEHDtQ3iin+dMEKEO430ceZ9s6pIcSwPIWeBmXvPbBo=; b=hDWXl8SZ9LXXp3mhpkmKCtukPK8TpjwBdTs4t0GeoGE/nfQ1aWo6nk46N2dBaI1sHy 8a5v12e2oA6Alv/NLozOuNXCw0ROtjFl7KYoUMxhoQtsB+bPtZ/vJknVgI+UmdGerPK8 FAhUjFOxcuZ/0H14bgqynti9UVJLTLAuQDJoiFQpNQTGykUvgrIq53Dfnx4qlZbF/+wZ zA+kHhLh+Ju3qrhtRSMpH0TUfvvOnHjOqVhrXo+qiOaNn2ZZ0w4Dxk0nUMq1SsjIeIRB 0Y10ep9lQJ9Z8lCPE7RxO4YwPKCY8//IS9PYTbaFGHmun7lMoXyMLAea5jtKkyQpsYey dFGA== X-Gm-Message-State: AOAM530ajTiybcoPBx/vsezOZU+sOks0fQtwioVcCAz+VcHFEB9FKVm8 U6r2mz2lbxoShFdhb9oy+H1JglE0o5kR/NkU+NtYj4Joghs= X-Google-Smtp-Source: ABdhPJye3ETF9ahdTHD6qPgoQMR92sfG00+tH3PODMiOuu+GmgSgHPiRy6BR0kmK2wHF4BgqLsirMDhxV5pDc4FURfM= X-Received: by 2002:a05:6a00:d4a:b0:3e3:f6:6c71 with SMTP id n10-20020a056a000d4a00b003e300f66c71mr8047111pfv.22.1629399846887; Thu, 19 Aug 2021 12:04:06 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: David Schinazi Date: Thu, 19 Aug 2021 12:03:55 -0700 Message-ID: To: DNSSD Content-Type: multipart/alternative; boundary="0000000000001223e305c9ee378c" Archived-At: Subject: Re: [dnssd] WGLC for draft-ietf-dnssd-srp X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2021 19:04:14 -0000 --0000000000001223e305c9ee378c Content-Type: text/plain; charset="UTF-8" Hi everyone, During this Working Group Last Call, the chairs received statements of support from 11 people and no objections. I'd like to personally thank everyone who read and reviewed the draft, this work is exactly how we produce high-quality RFCs. However, we received multiple suggestions for minor changes, and Esko raised some concerns regarding Section 5 (Sleep Proxy). Based on this we are declaring the WGLC successful, and we are placing the document in the "Waiting for WG Chair Go-Ahead" state [1]. We expect the authors to submit a revised draft that addresses the comments received during WGLC. Once that is done, we'll give folks an opportunity to verify that their comments were addressed, and assuming they were we'll submit the draft to the IESG for publication. Thanks, David for the chairs [1] https://datatracker.ietf.org/doc/html/rfc6174#section-4.2.8 On Wed, Jul 28, 2021 at 2:57 PM David Schinazi wrote: > Hi DNSSD enthusiasts, > > This email starts an official Working Group Last Call > for draft-ietf-dnssd-srp. This call asks whether we believe the document is > ready for publication. As such we are asking two questions: > > 1) if you believe this document is not ready to publish, please speak up > now > > 2) if you have read the document and think it is ready, please say so as > well > > For this call to succeed, we'll need statements of explicit support from > people who have read the draft. Please send statements in either direction > as responses to this email. This call will be open until 2021-08-15 23:59 > UTC. > > Thanks, > David > --0000000000001223e305c9ee378c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi everyone,

During this Working Gr= oup Last Call, the chairs received
statements of support from 11 = people and no objections.

I'd like to personal= ly thank everyone who read and
reviewed the draft, this work is e= xactly how we produce
high-quality RFCs.

However, we received multiple suggestions for minor
changes, and= Esko raised some concerns regarding
Section 5 (Sleep Proxy).

Based on this we are declaring the WGLC successful,
and we are placing the document in the "Waiting for WG
<= div>Chair Go-Ahead" state [1]. We expect the authors to
subm= it a revised draft that addresses the comments
received during WG= LC. Once that is done, we'll give
folks an opportunity to ver= ify that their comments were
addressed, and assuming they were we= 'll submit the
draft to the IESG for publication.
<= br>
Thanks,
David for the chairs

[1]=C2=A0https://datatracker.ietf.org/doc/html/rfc6174#section-4.2.8

On Wed, Jul 28, 2021 at 2:57 PM David Schinazi <dschinazi.ietf@gmail.com> wrote:
Hi DNS= SD enthusiasts,

This email starts an official = Working Group Last Call for=C2=A0draft-ietf-dnssd-srp. This call asks wheth= er we believe the document is ready for publication. As such we are asking = two questions:

1) if you believe this document is = not ready to publish, please speak up now

2) if yo= u have read the document and think it is ready, please say so as well
=

For this call to succeed, we'll need statements of = explicit support from people who have read the draft. Please send statement= s in either direction as responses to this email. This call will be open un= til 2021-08-15 23:59 UTC.

Thanks,
David<= /div>
--0000000000001223e305c9ee378c-- From nobody Thu Aug 19 12:19:05 2021 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C1433A1847 for ; Thu, 19 Aug 2021 12:19:02 -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 Cc6D6xaZHIzP for ; Thu, 19 Aug 2021 12:18:57 -0700 (PDT) Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) (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 243083A184A for ; Thu, 19 Aug 2021 12:18:57 -0700 (PDT) Received: by mail-lf1-x129.google.com with SMTP id g13so15126704lfj.12 for ; Thu, 19 Aug 2021 12:18:57 -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=O5qXD8qoXKFj1htLL0Vyny0qub9B/E8LAMin+3CWq4M=; b=fzlr86XNa8hD/KM9EBHp6Krv+Am2RuFhVJzsQKdum1E/NBdSXN/vBX1E+aDFbyyPSh /Bbi7In3Y8XEQSh2rHuJLYrc1rt4Lx5nDvwjU+Q/DDichauUfY8+VNiitXzL10uHF3Rj NaVEtzO4ai86QPDOHxi3q6fIItVDsoJ4NzluXOOIDG7ISGjjEnc6qvgOEHwAqE/DMnUL m7ofGgR/GY8wsPCCGIuTrU7Emupeeo2NocivTU6RAdKX5wsBmuOMssCidvYd0HLL7eWL 3HrgGAtYHBmYs6FVU/VtPCpcd+KxzagyUWLaHCF3EYF8/ousk5+PPPzBpkRp3u13z9sw DujQ== 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=O5qXD8qoXKFj1htLL0Vyny0qub9B/E8LAMin+3CWq4M=; b=knCvMnaUfyWS6PnC1TRIqdgVObp3pOe1ZOuaeAQjz8l8jgeRjJoQwe3pVevh/aSI5Q igrk8M1BcE85N62yaPD604zEv4Vn3GKujYHhWRtANJMs7Bz28JDwvoCfQ7qSokGstNsc 6wFZV3kA5LcOoyTT0CK9PqahEw4v+cX66qRQnL+qEPpOKncxqSohWKYm74aXoDAAK36q z1ADsTT9JAd1dr5VJ9Lbjpsolz83H8dXndEV9iGDu91YD9NFH6xAAVjH+jAhPVRU6ZB3 soQK6HYsrhhHe13hSbDg4duXgfnrIb0Dzjji/ZuEjbXE+vVfeyhmTdYULLRlJFjc/AOl ZZNg== X-Gm-Message-State: AOAM5302AWzGk3Sofbe++IWdOZnwD4jx8EJa30Ym1PZWzTJ21vgXdgFz SetOypWeaTMBsMPqBAmQmEBg+VrAPDJCn4C4h8o= X-Google-Smtp-Source: ABdhPJz7a3hiSgiAN5ExGPQ/lbr1zJCWEYDL0ZiWnm4LPbK6x3jwelwgRlOpjwmNtYxt3gZNQznvmLYFeSkJbCLgRqc= X-Received: by 2002:ac2:5fd1:: with SMTP id q17mr11817441lfg.439.1629400733472; Thu, 19 Aug 2021 12:18:53 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Tim Wicinski Date: Thu, 19 Aug 2021 15:18:42 -0400 Message-ID: To: Chris Box Cc: dnssd Content-Type: multipart/alternative; boundary="000000000000ea59bc05c9ee6bcc" Archived-At: Subject: Re: [dnssd] Adoption call for draft-sekar-dns-ul-03 into DNSSD X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2021 19:19:03 -0000 --000000000000ea59bc05c9ee6bcc Content-Type: text/plain; charset="UTF-8" Hi I've read this document and I support the adoption. tim On Wed, Aug 18, 2021 at 12:31 PM Chris Box wrote: > WG members, > > This email starts a call to adopt > https://datatracker.ietf.org/doc/html/draft-sekar-dns-ul-03 into the > DNSSD working group. > > What is this? Abstract: > This document proposes a new EDNS0 option that can be used by DNS > Update clients and DNS servers to include a lease lifetime in a DNS > Update or response, allowing a server to garbage collect stale > resource records that have been added by DNS Updates > > Adoption means that formal change control passes from the authors to the > working group. All subsequent substantive changes require WG rough > consensus. Adoption represents a commitment that the DNSSD WG will spend > time on the draft, with the aim of progressing it towards publication. > > Note that in theory the draft could fit the charters of both DNSOP and > DNSSD, but we're proposing DNSSD as this specific functionality is required > as part of draft-ietf-dnssd-srp > which is already > well advanced. The relevant charter text is: > > 2. To develop an improved, scalable solution for service discovery > that can operate in multi-link networks, where devices may be > in neighboring or non-neighboring links, applicable to > the scenarios above. The solution will consider tradeoffs between > reusing/extending existing protocols and developing entirely new > protocols. > > This email is being copied to DNSOP to solicit additional feedback from > the expertise there, but note this is NOT a call to adopt into DNSOP. > > You should be aware this draft is covered by an IPR disclosure. Details of > Apple's licensing terms can be found at > https://datatracker.ietf.org/ipr/1236/. > > Within DNSSD we are asking two questions: > 1) If you have read this six-page draft and are content with it, or would > like to amend/discuss it further inside the working group, please speak up > now. > 2) If you believe that this document is not something the DNSSD working > group should be working on, please also say so. > > For this call to succeed, we'll need statements of explicit support from > people who have read the draft. The document does not have to be perfect, > but it needs to be solving a problem the WG wants to solve in a way > approximately as described in the draft. > > Please send statements in support or against, as responses to this email. > This call will be open until 2021-09-03 23:59 UTC. > > Thanks, > Chris > > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd > --000000000000ea59bc05c9ee6bcc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

H= i

I've re= ad this document and I support the adoption.

tim


<= div dir=3D"ltr" class=3D"gmail_attr">On Wed, Aug 18, 2021 at 12:31 PM Chris= Box <chris.box.ietf@gmail.c= om> wrote:
WG members,<= /div>

This email starts a call to adopt h= ttps://datatracker.ietf.org/doc/html/draft-sekar-dns-ul-03 into the DNS= SD working group.

What is this? Abstract:
=C2=A0 =C2=A0This document proposes a new EDNS0 = option that can be used by DNS
= =C2=A0 =C2=A0Update clients and DNS servers to include a lease lifetime in = a DNS
=C2=A0 =C2=A0Update or resp= onse, allowing a server to garbage collect stale
=C2=A0 =C2=A0resource records that have been added by DNS U= pdates

Adoption means that formal change co= ntrol passes from the authors to the working group. All subsequent substant= ive changes require WG rough consensus. Adoption represents a commitment th= at the DNSSD WG will spend time on the draft, with the aim of progressing i= t towards publication.
=C2=A0 =C2=A0
Note that in theor= y the draft could fit the charters of both DNSOP and DNSSD, but we're p= roposing DNSSD as this specific functionality is required as part of=C2=A0<= a href=3D"https://datatracker.ietf.org/doc/draft-ietf-dnssd-srp/" target=3D= "_blank">draft-ietf-dnssd-srp=C2=A0which is already well advanced. The = relevant charter text is:

2. To develop an improved, scalable solution for service discovery=C2=A0
=C2=A0 =C2=A0that can operate in m= ulti-link networks, where devices may be
=C2=A0 =C2=A0in neighboring or non-neighboring links, applicable to=
=C2=A0 =C2=A0the scenarios above= .=C2=A0 The solution will consider tradeoffs between
=C2=A0 =C2=A0reusing/extending existing protocols and d= eveloping entirely new
=C2=A0 =C2= =A0protocols.=C2=A0
=C2=A0 =C2=A0
This email is = being copied to DNSOP to solicit additional feedback from the expertise the= re, but note this is NOT a call to adopt into DNSOP.

You should be aware this draft is covered by an IPR disclosure. Details = of Apple's licensing terms can be found at https://datatracker.ietf.org/ipr/1= 236/.
=C2=A0 =C2=A0
Within DNSSD we are asking two = questions:
1) If you have read this six-page draft and are conten= t with it, or would like to amend/discuss it further inside the working gro= up, please speak up now.
2) If you believe that this document is = not something the DNSSD working group should be working on, please also say= so.

For this call to succeed, we'll need = statements of explicit support from people who have read the draft. The doc= ument does not have to be perfect, but it needs to be solving a problem the= WG wants to solve in a way approximately as described in the draft.
<= div>
Please send statements in support or against, as respons= es to this email. This call will be open until 2021-09-03 23:59 UTC.
<= div>=C2=A0
Thanks,
Chris

_______________________________________________
dnssd mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/listinfo/dnssd
--000000000000ea59bc05c9ee6bcc-- From nobody Mon Aug 23 11:04:31 2021 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F3743A0A29 for ; Mon, 23 Aug 2021 11:04:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, 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 x4qlMdGctK1k for ; Mon, 23 Aug 2021 11:04:23 -0700 (PDT) Received: from mx3.open-xchange.com (alcatraz.open-xchange.com [87.191.39.187]) (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 0F32D3A0A20 for ; Mon, 23 Aug 2021 11:04:22 -0700 (PDT) Received: from imap.open-xchange.com (imap.open-xchange.com [86.85.149.247]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx3.open-xchange.com (Postfix) with ESMTPSA id A347B6A0DD; Mon, 23 Aug 2021 20:04:19 +0200 (CEST) Received: from plato ([86.85.149.247]) by imap.open-xchange.com with ESMTPSA id 28i/JiPjI2FVIQAA3c6Kzw (envelope-from ); Mon, 23 Aug 2021 20:04:19 +0200 Message-ID: <9f82609a7bc482c4fadac10c0f5ffbc5886fab76.camel@powerdns.com> From: Peter van Dijk To: dnssd Date: Mon, 23 Aug 2021 20:04:18 +0200 In-Reply-To: References: Organization: PowerDNS.COM B.V. Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.30.5-1.1 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dnssd] draft-sekar-dns-ul X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2021 18:04:29 -0000 On Tue, 2021-07-27 at 23:01 +0000, Ted Lemon wrote: > So, please take a look at the document and comment here. You can find a copy of the document here: https://www.ietf.org/archive/id/draft-sekar-dns-ul-03.html Section 3 says: > Encoding the Update Lease Lifetime in an OPT RR requires minimal modification to a name server's front-end, and will cause servers that do not implement this extension to automatically return a descriptive error (NOTIMPL). In queries and responses, servers normally ignore options they do not recognise, so I suspect this sentence is wrong. The fix seems simple, though - a client checks for the option in the response, and if it's not there, the client knows that a lease limit has not been applied. Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ From nobody Fri Aug 27 02:55:57 2021 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 631913A2A0B for ; Fri, 27 Aug 2021 02:55:55 -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, 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.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=iotconsultancy.nl 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 YLVP6Flm26fG for ; Fri, 27 Aug 2021 02:55:49 -0700 (PDT) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70114.outbound.protection.outlook.com [40.107.7.114]) (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 BEE893A2A07 for ; Fri, 27 Aug 2021 02:55:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Ei4Gm4CW0cHflYeoXB5byp863ubknR6Lw83NYG4A6jw7xn3ARtk9SBtp05sYiyi3q5gVGzeFwQ4IgSUzI0h0vewCU9zvucNzTus4DTwL0/a+6kKDllfoAAQ840IsGL4KkBdThYRqLZpdB7CfPgMugDjlWVeLLhDF5X5ArMo10oESZG6WLzMXaXr6vict2xgEv6E8mGno7Y4SmY3f0/5gfuPjbWk0BrVrluFaHweG3DZsBbiod9U73GAtsdWXKgjtLWMc2TXtD++6adNlDRPzl3Wf+uuHRuzPrB6zo8s4eBtxA8dLBDYVGE5A2l3Z+CkEniER8VUCXU4lRb1Q9ostTA== 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=TIUeK3IyL14oUNY1d4IWwhs63kPvojd9RAFKrAd2sxM=; b=BK5DEawDJQkfPHuO39sOqWHyIIH14aAPyhqt3orUNwsGLyPTcPzKMsBDQNcF7bKBhEbw7XZtow+aLZvJcXAyAVaENfZknbCQgfNbUjKpylG+G0W2Nh6Rv6Ekq4b0uOpSVqGCOUXLRWjX2v+Y2MJjQ6ndqGG54bIfORHiRqVfZf7B0JLZUuEqNrYbk1jhkJRZ3qHV1B0p9KwSVaFd49WdgS1cL2DTKHEigzo0o7Q/H/Y+RKczkk1dsMx3yjn5rRV4SXQmmhgGDNAfT7ic7VNhvJPu6rJPzfYoo0Lk0alJ+ixQm6zj18BPWjb9WSSixVRD+u+qBAzyjIG4+qReQIgjXA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=iotconsultancy.nl; dmarc=pass action=none header.from=iotconsultancy.nl; dkim=pass header.d=iotconsultancy.nl; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iotconsultancy.nl; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=TIUeK3IyL14oUNY1d4IWwhs63kPvojd9RAFKrAd2sxM=; b=LiaBuqNjmOoYYTjvols9RurwgoEXCj3ZCqqF0hP6BOSUOjLcVLfu4VgwZaiEW/eCRZ1WCzQMoZ6YJEuGkMTH+jsCI/jWDVunGYLTYoyRhzgRYguSikfqFH1tn4Rhql3hgiIJn9LB74EcRGFNZMkf9Y9O3AXnFXQ+U8CBrY+jKYc= Received: from AM8P190MB0979.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:1d3::8) by AM4P190MB0017.EURP190.PROD.OUTLOOK.COM (2603:10a6:200:60::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4457.17; Fri, 27 Aug 2021 09:55:44 +0000 Received: from AM8P190MB0979.EURP190.PROD.OUTLOOK.COM ([fe80::915c:6cbb:95d3:13c7]) by AM8P190MB0979.EURP190.PROD.OUTLOOK.COM ([fe80::915c:6cbb:95d3:13c7%9]) with mapi id 15.20.4436.027; Fri, 27 Aug 2021 09:55:43 +0000 From: Esko Dijk To: Chris Box , dnssd Thread-Topic: [dnssd] Adoption call for draft-sekar-dns-ul-03 into DNSSD Thread-Index: AQHXlE55fAOTKX+ykEaBHuSlVPET8KuHJCdA Date: Fri, 27 Aug 2021 09:55:43 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=iotconsultancy.nl; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: fcefc46f-4256-43d8-fe63-08d96940d613 x-ms-traffictypediagnostic: AM4P190MB0017: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: LmQRxuD1yJ/SA0mgZvjRs/sIshKCi2LgW94W26eqsxDejAlYtwwHKXSvCqzxdBiYUH7H8EFH21S1AOSWC34F1yYP/nBrT0h3bLaZCZo3ooj0rpVDJVBb4rGoXi7GszC5SZXMbJJu9VPxyPsJgpTtBSOUaCYTo4QSxs1Sv78lxhQXakB2fVG9FrYfsVoW6Rb9ZIIK3OeCYD9mNpLTKQ4A2vRKoDsKmWIJSg+DfTKRAwWFMGV9IEm66ZLfQlTbke9gf5hRriY4OoWDO/vhgaYx5BRdtmwXukp8UuYL7Qz5/88l7swtN07xkJhFYZ5mOVJQ/P6XXAXj4WwZRgHe5D31ydWPWk4x3ZASBSrJcNKg4K7NEnOAtHiLVRfT6COJqMhJfZoQvMiaz78Bf33UO7QklDdhBuxItMhEXeDP3UWyVpKer1s1S3vTnhfhHuel4YGvBsdua/LJKhMyiIrv5ckw4gxA7aqQWx8s6GDwUxNV42dywxbXUrjZVMG4m+ZQkZbZg5A2K1NKg4pZxosLVvl8YW2KYcxQDjellc3USDzeSQynQNrBDsY5MpVufhn9H5C10LtAVLwQFPNHw+/mVe7LagA0IpRm1X0mYvqq05VP32g7oYlU9pTmQQ2z17poM9APPLGjheQsTcSHym2JYAmX6zURSKBSep/7Z7pvokfn3+9fczQjH6lqpLbg42nOSrsATzjHFVUv+jp4PVgGyAr3JGCrxZE28teKXgTOEdzKWuA83xRlGah5YidZDda+ys0nS8c4Efse6mw/wKHaRdJRnIx5UIubQkVdA76l11cSGXAT/hI/Ncq+XRAUEeHzW9wmgfLfk7b0Nc3VzOn/UnuxKw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM8P190MB0979.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(376002)(39830400003)(136003)(396003)(346002)(366004)(83380400001)(55016002)(44832011)(166002)(186003)(966005)(110136005)(5660300002)(7696005)(122000001)(316002)(76116006)(66946007)(9686003)(38100700002)(6506007)(8676002)(71200400001)(8936002)(64756008)(52536014)(66556008)(86362001)(38070700005)(478600001)(33656002)(66446008)(66476007)(53546011)(2906002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?enVsS21wMFA1QkgyRkd2L3ExRjAyb1pJUXdsM053YUQ3RFJJRnR4b0lFdzNM?= =?utf-8?B?UnFQSXVZMHlTWW5ENW5Pbld3TldTeVpVdzFYT210ekZFQStBK1NKWXZOWDlS?= =?utf-8?B?eHB2OHJ0ZldGd1ZKYzRwcjJpK291S09ZWGxvOEVDSUxYUGZQaWF6a0NjcERC?= =?utf-8?B?UTRJbTBjRXJwbGRhRVVhSUF2dlZYTTBkS0xJeEUveXBUVXRZYzljTno4SStw?= =?utf-8?B?T3p5a0hOdnQrOTVOVkc0NituVEFBeTZiMlc4WlhWdXNNOXFoNVU5NzlWWG54?= =?utf-8?B?Yjk0MFlFOUgxWERnMHUvS3V0elNJZFUzNHh6djFwK2p1QXFRcVFLR3ljSUkr?= =?utf-8?B?dFdNM1c3ZFVYdWNZRWhvblI3amR1K1VScDA1VmJZWnJWMlA0ckcwZk5VbXNW?= =?utf-8?B?cWVxVHAydDc5OTRXK0JWMnhhYWFzY3hvQWpiK3FXOVN4UkhCL2JtVkU4K3pZ?= =?utf-8?B?eXJWeVVoRVVDNTVVUkplLzRha01VdG9Fc290Z1FmbHc1eFdiMnA3ajFhVmZi?= =?utf-8?B?V0dCMStESmpaNmVvNmZVUU1XajBQZUpkaUJVUUpZNVIrb1UzK1JjSmdiV2lW?= =?utf-8?B?bVpIR014bkRmblVHTjUzSkg5cjZQVUtuSzBrcGlUYmFmU0ZyUjZtaHE4Rk9W?= =?utf-8?B?b1BXWmRkRkZmZGxCa21rUWVUL1kvZUJQVm0rTStYUktTTlhiT1FtSXNQYy9E?= =?utf-8?B?aVRVRThOQWhmeEY5YUpqWGlPVkJHdzdZNWRhS3h3by95Ti9SelFqMkVUYlZD?= =?utf-8?B?Q3dkSUoyczFuNFM3NiszRitFeWFFVkQ2MDZjR29HU1pqWUhSRWY1RmZBNFF4?= =?utf-8?B?TnZUaE02TzRqbEZwNUZud254NjZ0L1haczIzOTJJZEVUWlh2UDNCbDRGSGFU?= =?utf-8?B?eXFpd0hzeURDU1RzUUpSZzJYcUFYbnFBaVBjc0dTVGZ3OTJGRm9mTTV1Vi9z?= =?utf-8?B?Q1hkemgvdldZTHNOV3l3cUdBWUVjZ2t0UWFyaUtDelNCSWdQbEl3Wm1Da2dP?= =?utf-8?B?SmQzQ3dNWU5oTFhMQ3hKamxzN1lOTWhQaGN6dXp5ZmRxSms0T0lPbjcwYXpX?= =?utf-8?B?bWc2T2Q2VEJvTU41Y1NRL3VCcHE3SkpLRmRUdS9ISFBmcklSZFZLZ2w5c2J6?= =?utf-8?B?NWJSYzIyUG94RGF6YWRnVXlHTnZzeWV1K0x1MlAxMTFoYWNDUmIyeTRzUVNW?= =?utf-8?B?bnoxajl2MUc5NUhnTmg5TDFMTTBzMzRhSjRSTzRUd1JGbWJWVjBObHV5enhs?= =?utf-8?B?VXN2UmRSQTBQdk9IZXAwOVc2WHZUQUlreUQveHRPbFpwODVTTGRCVGtvMndu?= =?utf-8?B?WnVRWmt0M0dBNjlKUFpCdkpuS3J2cE5heWt0anJGN1YzM3ppQnRQaEU0TStn?= =?utf-8?B?S2Njc3NWcGVyYUxMM3VUWFMyckdvN1BBZURzL2I1OHNYZmJiUDE0MUk5aHBj?= =?utf-8?B?cDFwNzVJNnhNdVpJL3JyOTBnWUZockYwazkwTnFjbnB6L1VTWE5NUWFzT3cy?= =?utf-8?B?SlkrWUdLeHdRclJPMlEyVnQ5MUk3SEN0UjFPNG1mUE1telp1M2E2dVF1Z0c5?= =?utf-8?B?QS82MXczeWlvejYxTkRBTDc0WUxDUXhTVjNYU3lud0VWWmdWaVNkMGN1Q1A3?= =?utf-8?B?Ny9UbXg3SlVmOCthdFVuZk5SdUV0VWZqSWhPdTc1eCttZHBmVno2MmlmbmVJ?= =?utf-8?B?bkVQazBzWXVFaXdpSDJGZmt1Y2RRTVJQYURsYm9RaUFBQm5ZcndIS2R1d2dk?= =?utf-8?B?Tk8va2tSNXo4QWlkQ0hrM1NXaWs0Z1JrblVTbHM1MjlrZ0twYUlSWGc0cE9T?= =?utf-8?B?d3dTUUZ4WE5NZXE0NzV0MU83a2txZnpYcWcwUmxhc3Vqd1JtL29CWHEzbzhz?= =?utf-8?Q?hwB6lGIIlxKAw?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_AM8P190MB09799D03425E3661B3ED0089FDC89AM8P190MB0979EURP_" MIME-Version: 1.0 X-OriginatorOrg: iotconsultancy.nl X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM8P190MB0979.EURP190.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: fcefc46f-4256-43d8-fe63-08d96940d613 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Aug 2021 09:55:43.7694 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 58bbf628-15d2-46bc-820b-863b6774d44b X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: m9wbJ7kG8j8nCra5ZpxfTY6dscubwa4aHwwpbIEiDgYFVVj/ZgNqSCSsMS/OpsD8hPJbEZJYrnJNq6S2UcAgcSEOeWv6BszhI+YK8I6llw4= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4P190MB0017 Archived-At: Subject: Re: [dnssd] Adoption call for draft-sekar-dns-ul-03 into DNSSD X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2021 09:55:55 -0000 --_000_AM8P190MB09799D03425E3661B3ED0089FDC89AM8P190MB0979EURP_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWxsLA0KDQpJIGhhdmUgcmVhZCB0aGUgZHJhZnQsIGFuZCBzdXBwb3J0IGl0cyBhZG9wdGlvbiBp bnRvIHRoZSBETlNTRCBXRy4gSW50cm9kdWNpbmcgdGhlIGxlYXNlIGxpZmV0aW1lIHBsdXMgbmVn b3RpYXRpb24gbG9va3MgdXNlZnVsIHRvIGhhdmUsIGZvciB1c2UgY2FzZXMgd2l0aCBkeW5hbWlj IHNlcnZpY2UgY2hhbmdlcywgY29ubmVjdGl2aXR5IGNoYW5nZXMgYW5kIGludGVybWl0dGVudCBw b3dlcmluZyBvbi9vZmYgb2YgZGV2aWNlcy4NCkFsc28gaXQgaXMgcmVxdWlyZWQgZm9yIHRoZSBT UlAgdG8gYWR2YW5jZS4NCg0KSSBkbyBoYXZlIG9uZSByZXZpZXcgcXVlc3Rpb24gb24gU2VjdGlv biA1LjMgdGhhdCBtYXkgYmUgZnVydGhlciBkaXNjdXNzZWQgaWYgdGhpcyBiZWNvbWVzIGEgV0cg ZG9jdW1lbnQ6IGl0IHNheXMgdGhlIHNlcnZlciBzaG91bGRu4oCZdCBwZXJmb3JtIHRoZSByZWZy ZXNoIGlmIHRoZXJlIGlzID41MCUgbGVhc2UgdGltZSBsZWZ0LiAgSXMgdGhpcyBpbnRyb2R1Y2Vk IHRvIGF2b2lkIGNsaWVudHMgdGhhdCByZXBlYXRlZGx5IHJlZnJlc2ggYnkgbWlzdGFrZSBvciBi eSBkZXNpZ24/DQpJLmUuIHJlZHVjZSB0aGUgbW90aXZhdGlvbiBhIGNsaWVudCBtYXkgaGF2ZSB0 byByZXBlYXRlZGx5IHJlZnJlc2ggdG9vIG9mdGVuLg0KDQpMb29raW5nIGZyb20gYSDigJhob25l c3TigJkgY2xpZW50IHBlcnNwZWN0aXZlOiAgIG1heWJlIGEgY2xpZW50IGhhcyBhIGdvb2QgcmVh c29uIHRvIHJlZnJlc2ggZWFybGllciwgZS5nLiBpdCBpcyBub3cgYXdha2UgYW5kIHdpbGwgc2hv cnRseSBnbyB0byBzbGVlcCBhbmQgd2FudHMgdG8ga2VlcCB0aGUgc2VydmljZSByZWdpc3RyYXRp b24gYWN0aXZlIGR1cmluZyB0aGF0IHNsZWVwIHRpbWUuIChTZWUgU1JQIGRvY3VtZW50IGZvciB0 aGUg4oCcc2xlZXAgcHJveHnigJ0gZnVuY3Rpb24gdGhhdCB3b3VsZCBhbGxvdyBzbGVlcGluZyB3 aGlsZSBrZWVwaW5nIHNlcnZpY2VzIGFjdGl2ZS4pICAgT3IgbWF5YmUgdGhlIGNsaWVudCBoYXMg anVzdCBkZWNpZGVkIHRoYXQgYSBsb25nZXIgbGVhc2UgdGltZSBpcyBiZXR0ZXIgYW5kIGp1c3Qg d2FudHMgdG8gcmVmcmVzaCB0byBjb21tdW5pY2F0ZSB0aGUgbG9uZ2VyIGxlYXNlIHRpbWUgdG8g dGhlIHNlcnZlciBhdCB0aGUgbW9tZW50IG9mIG1ha2luZyB0aGlzIGRlY2lzaW9uICh3aGVyZSB0 aGUgZGVjaXNpb24gbWF5IGJlIHRyaWdnZXJlZCBieSBzb21lIGh1bWFuIFVJIGFjdGlvbnMgb3Ig YnkgaW50ZXJuYWwgc3RhdGUsIHNvZnR3YXJlIHVwZGF0ZSB3aXRoIHJlYm9vdCwgZXRjLikNCg0K QmVzdCByZWdhcmRzDQpFc2tvDQoNCkZyb206IGRuc3NkIDxkbnNzZC1ib3VuY2VzQGlldGYub3Jn PiBPbiBCZWhhbGYgT2YgQ2hyaXMgQm94DQpTZW50OiBXZWRuZXNkYXksIEF1Z3VzdCAxOCwgMjAy MSAxODozMQ0KVG86IGRuc3NkIDxkbnNzZEBpZXRmLm9yZz4NCkNjOiBkbnNvcEBpZXRmLm9yZw0K U3ViamVjdDogW2Ruc3NkXSBBZG9wdGlvbiBjYWxsIGZvciBkcmFmdC1zZWthci1kbnMtdWwtMDMg aW50byBETlNTRA0KDQpXRyBtZW1iZXJzLA0KDQpUaGlzIGVtYWlsIHN0YXJ0cyBhIGNhbGwgdG8g YWRvcHQgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1zZWthci1k bnMtdWwtMDMgaW50byB0aGUgRE5TU0Qgd29ya2luZyBncm91cC4NCg0KV2hhdCBpcyB0aGlzPyBB YnN0cmFjdDoNCiAgIFRoaXMgZG9jdW1lbnQgcHJvcG9zZXMgYSBuZXcgRUROUzAgb3B0aW9uIHRo YXQgY2FuIGJlIHVzZWQgYnkgRE5TDQogICBVcGRhdGUgY2xpZW50cyBhbmQgRE5TIHNlcnZlcnMg dG8gaW5jbHVkZSBhIGxlYXNlIGxpZmV0aW1lIGluIGEgRE5TDQogICBVcGRhdGUgb3IgcmVzcG9u c2UsIGFsbG93aW5nIGEgc2VydmVyIHRvIGdhcmJhZ2UgY29sbGVjdCBzdGFsZQ0KICAgcmVzb3Vy Y2UgcmVjb3JkcyB0aGF0IGhhdmUgYmVlbiBhZGRlZCBieSBETlMgVXBkYXRlcw0KDQpBZG9wdGlv biBtZWFucyB0aGF0IGZvcm1hbCBjaGFuZ2UgY29udHJvbCBwYXNzZXMgZnJvbSB0aGUgYXV0aG9y cyB0byB0aGUgd29ya2luZyBncm91cC4gQWxsIHN1YnNlcXVlbnQgc3Vic3RhbnRpdmUgY2hhbmdl cyByZXF1aXJlIFdHIHJvdWdoIGNvbnNlbnN1cy4gQWRvcHRpb24gcmVwcmVzZW50cyBhIGNvbW1p dG1lbnQgdGhhdCB0aGUgRE5TU0QgV0cgd2lsbCBzcGVuZCB0aW1lIG9uIHRoZSBkcmFmdCwgd2l0 aCB0aGUgYWltIG9mIHByb2dyZXNzaW5nIGl0IHRvd2FyZHMgcHVibGljYXRpb24uDQoNCk5vdGUg dGhhdCBpbiB0aGVvcnkgdGhlIGRyYWZ0IGNvdWxkIGZpdCB0aGUgY2hhcnRlcnMgb2YgYm90aCBE TlNPUCBhbmQgRE5TU0QsIGJ1dCB3ZSdyZSBwcm9wb3NpbmcgRE5TU0QgYXMgdGhpcyBzcGVjaWZp YyBmdW5jdGlvbmFsaXR5IGlzIHJlcXVpcmVkIGFzIHBhcnQgb2YgZHJhZnQtaWV0Zi1kbnNzZC1z cnA8aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1kbnNzZC1zcnAv PiB3aGljaCBpcyBhbHJlYWR5IHdlbGwgYWR2YW5jZWQuIFRoZSByZWxldmFudCBjaGFydGVyIHRl eHQgaXM6DQoNCjIuIFRvIGRldmVsb3AgYW4gaW1wcm92ZWQsIHNjYWxhYmxlIHNvbHV0aW9uIGZv ciBzZXJ2aWNlIGRpc2NvdmVyeQ0KICAgdGhhdCBjYW4gb3BlcmF0ZSBpbiBtdWx0aS1saW5rIG5l dHdvcmtzLCB3aGVyZSBkZXZpY2VzIG1heSBiZQ0KICAgaW4gbmVpZ2hib3Jpbmcgb3Igbm9uLW5l aWdoYm9yaW5nIGxpbmtzLCBhcHBsaWNhYmxlIHRvDQogICB0aGUgc2NlbmFyaW9zIGFib3ZlLiAg VGhlIHNvbHV0aW9uIHdpbGwgY29uc2lkZXIgdHJhZGVvZmZzIGJldHdlZW4NCiAgIHJldXNpbmcv ZXh0ZW5kaW5nIGV4aXN0aW5nIHByb3RvY29scyBhbmQgZGV2ZWxvcGluZyBlbnRpcmVseSBuZXcN CiAgIHByb3RvY29scy4NCg0KVGhpcyBlbWFpbCBpcyBiZWluZyBjb3BpZWQgdG8gRE5TT1AgdG8g c29saWNpdCBhZGRpdGlvbmFsIGZlZWRiYWNrIGZyb20gdGhlIGV4cGVydGlzZSB0aGVyZSwgYnV0 IG5vdGUgdGhpcyBpcyBOT1QgYSBjYWxsIHRvIGFkb3B0IGludG8gRE5TT1AuDQoNCllvdSBzaG91 bGQgYmUgYXdhcmUgdGhpcyBkcmFmdCBpcyBjb3ZlcmVkIGJ5IGFuIElQUiBkaXNjbG9zdXJlLiBE ZXRhaWxzIG9mIEFwcGxlJ3MgbGljZW5zaW5nIHRlcm1zIGNhbiBiZSBmb3VuZCBhdCBodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2lwci8xMjM2Ly4NCg0KV2l0aGluIEROU1NEIHdlIGFyZSBh c2tpbmcgdHdvIHF1ZXN0aW9uczoNCjEpIElmIHlvdSBoYXZlIHJlYWQgdGhpcyBzaXgtcGFnZSBk cmFmdCBhbmQgYXJlIGNvbnRlbnQgd2l0aCBpdCwgb3Igd291bGQgbGlrZSB0byBhbWVuZC9kaXNj dXNzIGl0IGZ1cnRoZXIgaW5zaWRlIHRoZSB3b3JraW5nIGdyb3VwLCBwbGVhc2Ugc3BlYWsgdXAg bm93Lg0KMikgSWYgeW91IGJlbGlldmUgdGhhdCB0aGlzIGRvY3VtZW50IGlzIG5vdCBzb21ldGhp bmcgdGhlIEROU1NEIHdvcmtpbmcgZ3JvdXAgc2hvdWxkIGJlIHdvcmtpbmcgb24sIHBsZWFzZSBh bHNvIHNheSBzby4NCg0KRm9yIHRoaXMgY2FsbCB0byBzdWNjZWVkLCB3ZSdsbCBuZWVkIHN0YXRl bWVudHMgb2YgZXhwbGljaXQgc3VwcG9ydCBmcm9tIHBlb3BsZSB3aG8gaGF2ZSByZWFkIHRoZSBk cmFmdC4gVGhlIGRvY3VtZW50IGRvZXMgbm90IGhhdmUgdG8gYmUgcGVyZmVjdCwgYnV0IGl0IG5l ZWRzIHRvIGJlIHNvbHZpbmcgYSBwcm9ibGVtIHRoZSBXRyB3YW50cyB0byBzb2x2ZSBpbiBhIHdh eSBhcHByb3hpbWF0ZWx5IGFzIGRlc2NyaWJlZCBpbiB0aGUgZHJhZnQuDQoNClBsZWFzZSBzZW5k IHN0YXRlbWVudHMgaW4gc3VwcG9ydCBvciBhZ2FpbnN0LCBhcyByZXNwb25zZXMgdG8gdGhpcyBl bWFpbC4gVGhpcyBjYWxsIHdpbGwgYmUgb3BlbiB1bnRpbCAyMDIxLTA5LTAzIDIzOjU5IFVUQy4N Cg0KVGhhbmtzLA0KQ2hyaXMNCg0K --_000_AM8P190MB09799D03425E3661B3ED0089FDC89AM8P190MB0979EURP_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5k b3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0K CXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0K ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1h eD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9 IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9k eSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSIgc3R5bGU9IndvcmQtd3Jh cDpicmVhay13b3JkIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5BbGwsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgaGF2ZSByZWFkIHRoZSBkcmFm dCwgYW5kIHN1cHBvcnQgaXRzIGFkb3B0aW9uIGludG8gdGhlIEROU1NEIFdHLiBJbnRyb2R1Y2lu ZyB0aGUgbGVhc2UgbGlmZXRpbWUgcGx1cyBuZWdvdGlhdGlvbiBsb29rcyB1c2VmdWwgdG8gaGF2 ZSwgZm9yIHVzZSBjYXNlcyB3aXRoIGR5bmFtaWMgc2VydmljZSBjaGFuZ2VzLCBjb25uZWN0aXZp dHkgY2hhbmdlcyBhbmQgaW50ZXJtaXR0ZW50IHBvd2VyaW5nIG9uL29mZiBvZg0KIGRldmljZXMu PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbHNvIGl0IGlzIHJlcXVpcmVk IGZvciB0aGUgU1JQIHRvIGFkdmFuY2UuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgZG8gaGF2 ZSBvbmUgcmV2aWV3IHF1ZXN0aW9uIG9uIFNlY3Rpb24gNS4zIHRoYXQgbWF5IGJlIGZ1cnRoZXIg ZGlzY3Vzc2VkIGlmIHRoaXMgYmVjb21lcyBhIFdHIGRvY3VtZW50OiBpdCBzYXlzIHRoZSBzZXJ2 ZXIgc2hvdWxkbuKAmXQgcGVyZm9ybSB0aGUgcmVmcmVzaCBpZiB0aGVyZSBpcyAmZ3Q7NTAlIGxl YXNlIHRpbWUgbGVmdC4gJm5ic3A7SXMgdGhpcyBpbnRyb2R1Y2VkIHRvIGF2b2lkIGNsaWVudHMg dGhhdCByZXBlYXRlZGx5DQogcmVmcmVzaCBieSBtaXN0YWtlIG9yIGJ5IGRlc2lnbj88bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkuZS4gcmVkdWNlIHRoZSBtb3RpdmF0aW9u IGEgY2xpZW50IG1heSBoYXZlIHRvIHJlcGVhdGVkbHkgcmVmcmVzaCB0b28gb2Z0ZW4uPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkxvb2tpbmcgZnJvbSBhIOKAmGhvbmVzdOKAmSBjbGllbnQgcGVy c3BlY3RpdmU6ICZuYnNwOyZuYnNwO21heWJlIGEgY2xpZW50IGhhcyBhIGdvb2QgcmVhc29uIHRv IHJlZnJlc2ggZWFybGllciwgZS5nLiBpdCBpcyBub3cgYXdha2UgYW5kIHdpbGwgc2hvcnRseSBn byB0byBzbGVlcCBhbmQgd2FudHMgdG8ga2VlcCB0aGUgc2VydmljZSByZWdpc3RyYXRpb24gYWN0 aXZlIGR1cmluZyB0aGF0IHNsZWVwIHRpbWUuIChTZWUgU1JQIGRvY3VtZW50DQogZm9yIHRoZSDi gJxzbGVlcCBwcm94eeKAnSBmdW5jdGlvbiB0aGF0IHdvdWxkIGFsbG93IHNsZWVwaW5nIHdoaWxl IGtlZXBpbmcgc2VydmljZXMgYWN0aXZlLikmbmJzcDsgJm5ic3A7T3IgbWF5YmUgdGhlIGNsaWVu dCBoYXMganVzdCBkZWNpZGVkIHRoYXQgYSBsb25nZXIgbGVhc2UgdGltZSBpcyBiZXR0ZXIgYW5k IGp1c3Qgd2FudHMgdG8gcmVmcmVzaCB0byBjb21tdW5pY2F0ZSB0aGUgbG9uZ2VyIGxlYXNlIHRp bWUgdG8gdGhlIHNlcnZlciBhdCB0aGUgbW9tZW50IG9mDQogbWFraW5nIHRoaXMgZGVjaXNpb24g KHdoZXJlIHRoZSBkZWNpc2lvbiBtYXkgYmUgdHJpZ2dlcmVkIGJ5IHNvbWUgaHVtYW4gVUkgYWN0 aW9ucyBvciBieSBpbnRlcm5hbCBzdGF0ZSwgc29mdHdhcmUgdXBkYXRlIHdpdGggcmVib290LCBl dGMuKTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CZXN0IHJlZ2FyZHM8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkVza288bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IGRuc3NkICZsdDtkbnNzZC1ib3VuY2Vz QGlldGYub3JnJmd0OyA8Yj5PbiBCZWhhbGYgT2YgPC9iPg0KQ2hyaXMgQm94PGJyPg0KPGI+U2Vu dDo8L2I+IFdlZG5lc2RheSwgQXVndXN0IDE4LCAyMDIxIDE4OjMxPGJyPg0KPGI+VG86PC9iPiBk bnNzZCAmbHQ7ZG5zc2RAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBkbnNvcEBpZXRmLm9y Zzxicj4NCjxiPlN1YmplY3Q6PC9iPiBbZG5zc2RdIEFkb3B0aW9uIGNhbGwgZm9yIGRyYWZ0LXNl a2FyLWRucy11bC0wMyBpbnRvIEROU1NEPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XRyBtZW1iZXJzLDxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIGVtYWlsIHN0 YXJ0cyBhIGNhbGwgdG8gYWRvcHQgPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvaHRtbC9kcmFmdC1zZWthci1kbnMtdWwtMDMiPg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1zZWthci1kbnMtdWwtMDM8L2E+IGludG8gdGhlIEROU1NE IHdvcmtpbmcgZ3JvdXAuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPldoYXQgaXMgdGhpcz8gQWJzdHJhY3Q6PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyAmbmJzcDtUaGlzIGRvY3VtZW50IHByb3Bv c2VzIGEgbmV3IEVETlMwIG9wdGlvbiB0aGF0IGNhbiBiZSB1c2VkIGJ5IEROUzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7ICZuYnNwO1Vw ZGF0ZSBjbGllbnRzIGFuZCBETlMgc2VydmVycyB0byBpbmNsdWRlIGEgbGVhc2UgbGlmZXRpbWUg aW4gYSBETlM8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPiZuYnNwOyAmbmJzcDtVcGRhdGUgb3IgcmVzcG9uc2UsIGFsbG93aW5nIGEgc2VydmVyIHRv IGdhcmJhZ2UgY29sbGVjdCBzdGFsZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7ICZuYnNwO3Jlc291cmNlIHJlY29yZHMgdGhhdCBoYXZl IGJlZW4gYWRkZWQgYnkgRE5TIFVwZGF0ZXM8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFkb3B0aW9uIG1lYW5zIHRoYXQgZm9ybWFs IGNoYW5nZSBjb250cm9sIHBhc3NlcyBmcm9tIHRoZSBhdXRob3JzIHRvIHRoZSB3b3JraW5nIGdy b3VwLiBBbGwgc3Vic2VxdWVudCBzdWJzdGFudGl2ZSBjaGFuZ2VzIHJlcXVpcmUgV0cgcm91Z2gg Y29uc2Vuc3VzLiBBZG9wdGlvbiByZXByZXNlbnRzIGEgY29tbWl0bWVudCB0aGF0IHRoZSBETlNT RCBXRyB3aWxsIHNwZW5kIHRpbWUgb24gdGhlIGRyYWZ0LCB3aXRoDQogdGhlIGFpbSBvZiBwcm9n cmVzc2luZyBpdCB0b3dhcmRzIHB1YmxpY2F0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Tm90ZSB0aGF0IGluIHRoZW9yeSB0 aGUgZHJhZnQgY291bGQgZml0IHRoZSBjaGFydGVycyBvZiBib3RoIEROU09QIGFuZCBETlNTRCwg YnV0IHdlJ3JlIHByb3Bvc2luZyBETlNTRCBhcyB0aGlzIHNwZWNpZmljIGZ1bmN0aW9uYWxpdHkg aXMgcmVxdWlyZWQgYXMgcGFydCBvZiZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtZG5zc2Qtc3JwLyI+ZHJhZnQtaWV0Zi1kbnNzZC1zcnA8 L2E+Jm5ic3A7d2hpY2gNCiBpcyBhbHJlYWR5IHdlbGwgYWR2YW5jZWQuIFRoZSByZWxldmFudCBj aGFydGVyIHRleHQgaXM6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+Mi4gVG8gZGV2ZWxvcCBhbiBpbXByb3ZlZCwgc2NhbGFibGUgc29sdXRpb24gZm9yIHNl cnZpY2UgZGlzY292ZXJ5Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsgJm5ic3A7dGhhdCBjYW4gb3BlcmF0ZSBpbiBtdWx0aS1s aW5rIG5ldHdvcmtzLCB3aGVyZSBkZXZpY2VzIG1heSBiZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7ICZuYnNwO2luIG5laWdoYm9yaW5n IG9yIG5vbi1uZWlnaGJvcmluZyBsaW5rcywgYXBwbGljYWJsZSB0bzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7ICZuYnNwO3RoZSBzY2Vu YXJpb3MgYWJvdmUuJm5ic3A7IFRoZSBzb2x1dGlvbiB3aWxsIGNvbnNpZGVyIHRyYWRlb2ZmcyBi ZXR3ZWVuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij4mbmJzcDsgJm5ic3A7cmV1c2luZy9leHRlbmRpbmcgZXhpc3RpbmcgcHJvdG9jb2xzIGFuZCBk ZXZlbG9waW5nIGVudGlyZWx5IG5ldzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7ICZuYnNwO3Byb3RvY29scy4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsg Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5UaGlzIGVtYWlsIGlzIGJlaW5nIGNvcGllZCB0byBETlNPUCB0byBzb2xpY2l0IGFkZGl0aW9u YWwgZmVlZGJhY2sgZnJvbSB0aGUgZXhwZXJ0aXNlIHRoZXJlLCBidXQgbm90ZSB0aGlzIGlzIE5P VCBhIGNhbGwgdG8gYWRvcHQgaW50byBETlNPUC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WW91IHNob3VsZCBiZSBhd2FyZSB0aGlzIGRyYWZ0 IGlzIGNvdmVyZWQgYnkgYW4gSVBSIGRpc2Nsb3N1cmUuIERldGFpbHMgb2YgQXBwbGUncyBsaWNl bnNpbmcgdGVybXMgY2FuIGJlIGZvdW5kIGF0DQo8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2lwci8xMjM2LyI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9pcHIvMTIz Ni88L2E+LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7ICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+V2l0aGluIEROU1NEIHdlIGFyZSBhc2tpbmcgdHdvIHF1ZXN0aW9uczo8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjEpIElmIHlv dSBoYXZlIHJlYWQgdGhpcyBzaXgtcGFnZSBkcmFmdCBhbmQgYXJlIGNvbnRlbnQgd2l0aCBpdCwg b3Igd291bGQgbGlrZSB0byBhbWVuZC9kaXNjdXNzIGl0IGZ1cnRoZXIgaW5zaWRlIHRoZSB3b3Jr aW5nIGdyb3VwLCBwbGVhc2Ugc3BlYWsgdXAgbm93LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MikgSWYgeW91IGJlbGlldmUgdGhhdCB0aGlzIGRv Y3VtZW50IGlzIG5vdCBzb21ldGhpbmcgdGhlIEROU1NEIHdvcmtpbmcgZ3JvdXAgc2hvdWxkIGJl IHdvcmtpbmcgb24sIHBsZWFzZSBhbHNvIHNheSBzby48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Rm9yIHRoaXMgY2FsbCB0byBzdWNjZWVkLCB3 ZSdsbCBuZWVkIHN0YXRlbWVudHMgb2YgZXhwbGljaXQgc3VwcG9ydCBmcm9tIHBlb3BsZSB3aG8g aGF2ZSByZWFkIHRoZSBkcmFmdC4gVGhlIGRvY3VtZW50IGRvZXMgbm90IGhhdmUgdG8gYmUgcGVy ZmVjdCwgYnV0IGl0IG5lZWRzIHRvIGJlIHNvbHZpbmcgYSBwcm9ibGVtIHRoZSBXRyB3YW50cyB0 byBzb2x2ZSBpbiBhIHdheSBhcHByb3hpbWF0ZWx5IGFzIGRlc2NyaWJlZA0KIGluIHRoZSBkcmFm dC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ UGxlYXNlIHNlbmQgc3RhdGVtZW50cyBpbiBzdXBwb3J0IG9yIGFnYWluc3QsIGFzIHJlc3BvbnNl cyB0byB0aGlzIGVtYWlsLiBUaGlzIGNhbGwgd2lsbCBiZSBvcGVuIHVudGlsIDIwMjEtMDktMDMg MjM6NTkgVVRDLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5UaGFua3MsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5DaHJpczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_AM8P190MB09799D03425E3661B3ED0089FDC89AM8P190MB0979EURP_--
Hi,

I'd like to add my support for publishing=
 the draft-ietf-dnssd-srp.
We have been experimenting and getting familia=
r with the OpenThread SRP implementation for Thread Border Routers and foun=
d that this technique is critical for bridging the gap between Thread netwo=
rks and the Infrastructure network.
The OpenThread SRP implementation is =
also being used in Matter <https://buildwithmatt=
er.com/> and is already integrated into the Matter SDK.
= 
regards
=
Saurabh | Samsung SmartThings