From nobody Thu Oct 8 12:19:31 2020 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 7AE2C3A0C5F for ; Thu, 8 Oct 2020 12:19:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.6 X-Spam-Level: X-Spam-Status: No, score=-17.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 oW6xt6ttMvll for ; Thu, 8 Oct 2020 12:19:28 -0700 (PDT) Received: from mail-ot1-x32f.google.com (mail-ot1-x32f.google.com [IPv6:2607:f8b0:4864:20::32f]) (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 BEB1C3A0D29 for ; Thu, 8 Oct 2020 12:19:24 -0700 (PDT) Received: by mail-ot1-x32f.google.com with SMTP id n61so6602237ota.10 for ; Thu, 08 Oct 2020 12:19:24 -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=Zr8ysnEVE+yyA9FtMZ/Iybt9XRtwYt/DMlBiewKWrI0=; b=G+jjAWlP1YZX8ar0V/MxOWhqb009EYuWUZhRrpMjP1QHJosH1Zcy18gVX5OXOmYYRF 2OoslPvaIZ3JaLOMy8YzgxABgRmBkcO+Su+JcPsGfJ3miI2N00fgVV7xrrsjtc05mpi1 0yDgU6UgE8CUlTRp5UT5YQZKqppCK/nuXWrTx0o5Y5BB412dxFhZ8qxPmtjkmWH89iJX SxKIQoUbNh1FvjeJUGM2jmAPdL8FB6kxnuAwaWRg0b5LQ1pP1nDC954JnVL9Zhw7IwSm zcbIVDBwLb8YblmxWVZcvmcWsivMm3EO7ZoEjmbzYFbD7EtsScXoMkicfAgLL9D7phgY 4F0A== 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=Zr8ysnEVE+yyA9FtMZ/Iybt9XRtwYt/DMlBiewKWrI0=; b=E3XSJ+fxOAbZUQaroeelPJtStqS/uwuX24K2NC1oMJRJQQi4bcXdSmkfcaAdtIQiZ+ WvBZp130Qq9fm5ZFGjWa9t4akWSw1usVMfQDKY+R6EzByUpXhCczMsFWPFmOBYsdcfvX eYyIa92YRNRC7FLQfNiUXEeHxmM7N1UBjqX4ILzDdzCbTGCQSCRnv9vKrHrbAbEFeAa8 rim3ImU3Dxuu3Pm3ZKQd2OkD8uvNo+6MlE1OuXgELCaWytXYZ9zdo7657SzoTSq1ElXF eU3TUp1zzxNmO2vdz+Ae1k5UmlmeE3PkZRDZN9tCNDPLQLuHfTr6hgpXUhpr0lbC3/3D WKJQ== X-Gm-Message-State: AOAM5305Z0N2jWYDuDhhSUs+pEBqzeWuxTCIycu/rpAKmjTcPH9VonGP u5ZPPOsmkWGC8VmUnb2tY2KSh9RyY0WCIg5EYvFbtj8dUtSQtA== X-Google-Smtp-Source: ABdhPJxpjB5qvqSfQ3x3dRzXeJ+5Apxv9/uzv/TnBBilnUU9bfswie31UjDvJ6kzoCVw1kMa3JNR7a572EZXWLsg7dI= X-Received: by 2002:a9d:7993:: with SMTP id h19mr2539997otm.129.1602184763233; Thu, 08 Oct 2020 12:19:23 -0700 (PDT) MIME-Version: 1.0 From: Jonathan Hui Date: Thu, 8 Oct 2020 12:19:11 -0700 Message-ID: To: dnssd@ietf.org Content-Type: multipart/alternative; boundary="000000000000adb5eb05b12db5c9" Archived-At: Subject: [dnssd] Review of draft-ietf-dnssd-srp-02 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, 08 Oct 2020 19:19:30 -0000 --000000000000adb5eb05b12db5c9 Content-Type: text/plain; charset="UTF-8" I have reviewed this document. I believe this document addresses a real pain point in constrained networks - namely how constrained devices can publish services with minimal round trips (i.e. one per update) and avoids the need for expensive multicast. This is of great interest to the Thread Group and Project CHIP efforts, both of which are based on IPv6. Overall, I found the document well-written and easy to understand. Detailed comments/questions below: Intended status: Informational > Why not standards track? [RFC6763] that allows services to automatically register their It's not clear to me at this point what "automatic" really means. It becomes clear later in the doc (e.g. Section 2.6.1), but I think it would help to be clear in the Introduction. Manual configuration of the registraton domain can be done either by > Typo: "registraton" -> "registration" using UDP unless TCP is required due to the size of the update. It > is the responsibility of a Constrained-Node Network supporting SRP to > provide appropriate anycast routing to deliver the DNS updates to the > appropriate server. It is the responsibility of the SRP server > Is "appropriate" well-understood here? I could use some clarification on what requirements are placed on the Constrained-Node Network to support SRP anycast. For example, can there be more than one SRP server on the network? If so, does the anycast address always need to map to the same SRP server for a given host? o The Host Description records for a service are a KEY RR, used to > claim exclusive ownership of the service registration, and one or > more RRs of type A or AAAA, giving the IPv4 or IPv6 address(es) of > the host where the service resides. > Are there recommendations/thoughts on how an SRP server should handle SRP updates containing multiple IPv6 addresses of varying scopes? Is this a topic within scope of this document? updates do not include update prerequisites. The specified in Typo: "The specified in..." o An SRP server is not required to implement general DNS Update > prerequsite processing. > Typo: "prerequsite" -> "prerequisite" The service generates a public/private key pair. This key pair MUST > be stored in stable storage; if there is no writable stable storage > on the client, the client MUST be pre-configured with a public/ > private key pair in read-only storage that can be used. This key > pair MUST be unique to the device. > Strictly speaking, we require the service to retain the key pair for as long as it would like to make updates to its existing service information. For example, should we recommend that a device generate a new key pair after factory reset (if it has the ability to do that)? I'm thinking that the public key can serve as a static identifier. update is constructed by the client, it MUST include include an > Typo: "include include" updates, and MUST reject updates that would otherwise be SRP updates > updates if they do not include leases. > Typo: "SRP updates updates" lease time Section 2.6.1. Shorter TTLs will result in more frequent > data refreshes; this increases latency on the client side, and > increases load on any caching resolvers and on the authoritative > server. Longer TTLs will increase the likelihood that data in caches Worth mentioning effect on network utilization? Or is that already implied? addresses in the records in question. In addition, proxy should Typo: "In addition, *the* proxy should..." specified in [I-D.ietf-dnsop-algorithm-update] section 3.1, in the > "section 3.1" link not pointing to the appropriate doc. 4. Privacy Considerations Should we mention UDP here? Should we mention the public key here? specification in [RFC8375]Section 7. "Section 7" link not pointing to the appropriate doc. Thanks. -- Jonathan Hui --000000000000adb5eb05b12db5c9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I have reviewed th= is document.

I believe=C2=A0this document addresse= s a real pain point in constrained networks - namely how constrained device= s can publish services with minimal round trips (i.e. one per update) and a= voids the need for expensive multicast. This is of great interest to the Th= read Group and Project CHIP efforts, both of which are based on IPv6.
=

Overall, I found the document well-written and easy to = understand.

Detailed comments/questions below:

Intended status: Informational

Why not standards track?

[RFC6763] that= allows services to automatically register their
It's not clear to me at this point what=C2=A0"automat= ic" really means. It becomes clear later in the doc (e.g. Section 2.6.= 1), but I think it would help to be clear in the Introduction.
Manual configuration of the registraton domain can be done either b= y

Typo: "registraton" = -> "registration"

using UDP unless TCP is = required due to the size of the update.=C2=A0 It
is the responsibility o= f a Constrained-Node Network supporting SRP to
provide appropriate anyca= st routing to deliver the DNS updates to the
appropriate server.=C2=A0 I= t is the responsibility of the SRP server

<= /div>
Is "appropriate" well-understood here? I could use some= clarification on what requirements are placed on the Constrained-Node Netw= ork to support SRP anycast. For example, can there be more than one SRP ser= ver on the network? If so, does the anycast address always need to map to t= he same SRP server for a given host?

o =C2=A0The Host = Description records for a service are a KEY RR, used to
=C2=A0 =C2=A0cla= im exclusive ownership of the service registration, and one or
=C2=A0 = =C2=A0more RRs of type A or AAAA, giving the IPv4 or IPv6 address(es) of=C2=A0 =C2=A0the host where the service resides.

Are there recommendations/thoughts on how an SRP server s= hould handle SRP updates containing multiple IPv6 addresses of varying scop= es? Is this a topic within scope of this document?

=
= updates do not include update prerequisites. The specified in

Typo: "The specified in..."
=

o =C2=A0An SRP server is not required to implement general D= NS Update
=C2=A0 =C2=A0prerequsite processing.

Typo: "prerequsite" -> "prerequisite&qu= ot;=C2=A0

The service generates a public/private key pa= ir.=C2=A0 This key pair MUST
be stored in stable storage; if there is no= writable stable storage
on the client, the client MUST be pre-configure= d with a public/
private key pair in read-only storage that can be used.= =C2=A0 This key
pair MUST be unique to the device.

Strictly speaking, we require the service to retain t= he key pair for as long as it would like to make updates to its existing se= rvice information. For example, should we recommend that a device generate = a new key pair after factory reset (if it has the ability to do that)? I= 9;m thinking that the public key can serve as a static identifier.

update is constructed by the client, it MUST include include an=

Typo: "include include&quo= t;

updates, and MUST reject updates that would othe= rwise be SRP updates
updates if they do not include leases.

Typo: "SRP updates=C2=A0updates"
lease time Section 2.6.1.=C2=A0 Shorter= TTLs will result in more frequent
data refreshes; this increases latenc= y on the client side, and
increases load on any caching resolvers and on= the authoritative
server.=C2=A0 Longer TTLs will increase the likelihoo= d that data in caches

Worth mentioning effe= ct=C2=A0on network utilization? Or is that already implied?

<= /div>
addresses in the records in question.=C2=A0 In addition, proxy should<= /font>

Typo: "In addition,=C2=A0the= =C2=A0proxy should..."

specified in [I-D.ietf-= dnsop-algorithm-update] section 3.1, in the
"section 3.1" link not pointing to the appropriate do= c.

4. Privacy Considerations
Should we mention UDP here?

Should we= mention the public key here?

specification in [RFC8375= ]Section 7.

"Section 7" li= nk not pointing to the appropriate doc.

Thanks.

--
Jonathan Hui

--000000000000adb5eb05b12db5c9-- From nobody Thu Oct 8 14:13:54 2020 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 435533A0D74 for ; Thu, 8 Oct 2020 14:13:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.6 X-Spam-Level: X-Spam-Status: No, score=-17.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 re6nITuYlj0h for ; Thu, 8 Oct 2020 14:13:50 -0700 (PDT) Received: from mail-ot1-x32a.google.com (mail-ot1-x32a.google.com [IPv6:2607:f8b0:4864:20::32a]) (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 9D77D3A0D6E for ; Thu, 8 Oct 2020 14:13:50 -0700 (PDT) Received: by mail-ot1-x32a.google.com with SMTP id q21so6956532ota.8 for ; Thu, 08 Oct 2020 14:13:50 -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=ANiQ/9yZIl+qVezXGnHMC9/twb4wrK8qNVcQI3HLkh4=; b=HvBFsiWwI2H0/FSq3G2XdYujF/5VYtZkVNyRR29YAAu9ijnOmUUCMi6eNJJPP4h+aA efI5ZrUvH30+Mk2tWJWVnGdyjtIOk4lJEG4tPdQVXVcUvCR+SubvHzPihotfNlhLKIT0 OKllUqTZpvNOLP78gJH4nll0Xx7qA7f7XGvVEEaBzDPzEQDOTRqGqFFzmyZcB9eVbkCY 8JIDzapPgUGDqK/WiE8Ici5/7/dptgVhY0gcdso4gdy9RKHXH+JW8NAXGTCLI9UJHo+w FcUWAxHqpoO6FObSj93s5VAB3khMehR1dvaK4Czi1Y3PFhBMUd4yWcqYhGrduVQvfBb9 5VPw== 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=ANiQ/9yZIl+qVezXGnHMC9/twb4wrK8qNVcQI3HLkh4=; b=JDHAHVP8Eh7dnXiqx2tUGo9dTybBSioNcdrbu1Hkel8Dne2oMxVWShrwsy+e9rkYM9 z9jhVKPfd7GeZc+bZyvlXwQK8d5mSJtqPo++aSgWcE/PYsslZJs86GGmV7iGdHhJKThW 2FX0gG4r46vFfKGqjzvyent3E3hoo30mIv8Y4841f0JkSah/WTjd04hJ76G4hzIKzyyx bj9HBgutyoh9fK446yAqwcpVqQ1ywzBMI5bAR5Zi0B146gwZbG6zDz6xZSM3RNr58jex GTi9wUj64W1nvnoDdcDeXjHyHpjnfGLHsLfRMWPuf3yn8QmtTu3XGAkq+P9Ha+8aWjZ+ zFoA== X-Gm-Message-State: AOAM532L8cHcthDD/Bwl2+J9O31gWtOeDwskVjkmdn4q+auApl4InWM4 HP2ygtjqPvxqb9RPekmE0gCnRPRJy2OGddw2lXi3pc+WoXNccg== X-Google-Smtp-Source: ABdhPJyQH+huVIHQyzGOiixXvPhGzqJcJ7L5IB4Sl+Iw78v5PHBtjltB2FvcHg4Sp3vn8vLY8UWtAfq143Lb19vEiys= X-Received: by 2002:a9d:7993:: with SMTP id h19mr2841076otm.129.1602191629412; Thu, 08 Oct 2020 14:13:49 -0700 (PDT) MIME-Version: 1.0 From: Jonathan Hui Date: Thu, 8 Oct 2020 14:13:38 -0700 Message-ID: To: dnssd@ietf.org Content-Type: multipart/alternative; boundary="000000000000ef62ff05b12f4e55" Archived-At: Subject: [dnssd] Review of draft-sctl-advertising-proxy-00 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, 08 Oct 2020 21:13:52 -0000 --000000000000ef62ff05b12f4e55 Content-Type: text/plain; charset="UTF-8" I have reviewed this document. I believe this document addresses a real pain point for constrained networks - namely how legacy clients can discover services offered by constrained devices using a service registry. As mentioned in my review of draft-ietf-dnssd-srp-02, this is of great interest to the Thread Group and Project CHIP efforts, both of which are based on IPv6. Overall, this document looks like a great start. Are there considerations for having multiple Advertising Proxies and SRP servers active on the same link? Is that within scope of this document? More targeted comments: 2.4. No Address Suppression I see this addresses one of my questions in my review of draft-ietf-dnssd-srp-02. disconnecting and then reconnecting to the network. The service > registry has no reliable automatic way to determine whether a device > that registered records has failed or disconnected from the network. > Would we permit implementations that do have visibility into whether a device has disconnected from the network? I realize this is a layer violation and technology specific. their records in a unicast DNS namespace, there is a presumption they > they will only register addresses with sufficient scope to be usable Typo: "they they" 3. Security Considerations > I know draft-ietf-dnssd-srp-02 describes cryptographic mechanisms to enforce first-come, first-serve naming. I presume with the introduction of Advertising Proxy, the same guarantees do not extend to legacy devices publishing via mDNS. Should we mention that here? An Advertising Proxy may made data visible to eavesdroppers on the Typo: "may made data" -> "may make data" Thanks. -- Jonathan Hui --000000000000ef62ff05b12f4e55 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I have reviewed this document.

I believe this document addresses a real pain point for constrained netw= orks - namely how legacy clients can discover services offered by constrain= ed devices using a service registry. As mentioned in my review of draft-iet= f-dnssd-srp-02, this is of great interest to the Thread Group and Project C= HIP efforts, both of which are based on IPv6.

Over= all, this document looks like a great start.

Are t= here considerations for having multiple Advertising Proxies and SRP servers= active on the same link? Is that within scope of this document?
=
More targeted comments:
<= br>
2.4.=C2=A0 No Address Suppression
<= br>
I see this addresses one of my questions in my review of=C2= =A0draft-ietf-dnssd-srp-02.

disconnecting and then reco= nnecting to the network.=C2=A0 The service
registry has no reliable auto= matic way to determine whether a device
that registered records has fail= ed or disconnected from the network.

=
Would we permit implementations that do have visibility into whether a= device has disconnected from the network? I realize this is a layer violat= ion and technology specific.

their records in a unicast= DNS namespace, there is a presumption they
they will only register addr= esses with sufficient scope to be usable

=
Typo: "they they"

3.=C2=A0 Security Cons= iderations

I know draft-ietf-dns= sd-srp-02 describes cryptographic mechanisms to enforce first-come, first-s= erve naming. I presume with the introduction of Advertising Proxy, the same= guarantees do not extend to legacy devices publishing via mDNS. Should we = mention that here?

An Advertising Proxy may made data v= isible to eavesdroppers on the

Typo:= "may made data" -> "may make data"

Thanks.

--
Jonathan Hui
<= div>
--000000000000ef62ff05b12f4e55-- From nobody Tue Oct 13 06:40:56 2020 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 0B6843A102D for ; Tue, 13 Oct 2020 06:40:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.8 X-Spam-Level: X-Spam-Status: No, score=-2.8 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_DNSWL_LOW=-0.7, 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 FY604wsfBGRt for ; Tue, 13 Oct 2020 06:40:44 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80110.outbound.protection.outlook.com [40.107.8.110]) (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 38E533A1009 for ; Tue, 13 Oct 2020 06:40:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XMr7kZ46o0uTwF7oPBUg1q7Tn1/fKbrk7HgI+doQdxqpJdZk1mBVeY6jL90joREWhXnli/56alotgLDi2ZHLRvsyXWLFt4wxSjWKh2KvSL2wmDWSYXt5yj/yMqmgayr4scgVgkkB/Ykb+93lUptFNyT4zTluRW44UVMo65ntHNRVYCAcwxhcnReGI4exzSsrWuk5XX3NKt0sKIQ6TGoBoa6CEP48VaTdB0zaV8fiq1mYnhaFz4aWGOm4UMf5bY5HAfzHLdKHa5f8DNkooMIMA9sISFqka36UHY44IgG4Qlc/RY4HIAiQKujIRj0L4YTOXVkzJ6JUh0LUH+c7gTAu3A== 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=moGp+WKQyCe2O3+OnJhHCiHL+0o3boQqnR/Tsoas5lU=; b=lxLkWSfe9fHQCw82UTLmlJcqhwF8qLWndxwNJf9yYlKZzEpW9Fwtg1IUkAXkdYFmW4+7hY++GMbTdRTNcXpMO3mx+6NdC9uuTJKS5vW1ZSCgje8uhAOGg+dSeVMujjZvX3Pc6Qflz2WVH5cI2/PFK4TWu2DbKsbk0MMXH0tRJULdMU302tyEauQMDnmG9bTFw3vU6hCaS33TXOvDnLlQZ+1CxB5IPMuH6R/pPSAPDEXBRHpFCBvR1e7BbUqHZpNAUfat5CsvPP0fLbxXJYGroERO0s/tE/tXa52/5a4GfeCXo3Z0SnCgy7YnwnDr/flPHX58hs0N3IQ9WxW8aO9Jqw== 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=moGp+WKQyCe2O3+OnJhHCiHL+0o3boQqnR/Tsoas5lU=; b=xhYWVYr+G8JuxlXOojgoIWZ6hcjo1p6oiWyy6VGAwnaSJmCUqg8cGySLzgXt5i2qcyhgeu47HuLMFoCskAX7RPQSLiUNSP1H+XgvdiH/4IpsO9E+r31ufmtUqP5lnpb9/X6mjzbIMZecLiflm6VBqxzAOpGh8qfqsrs5o6ycXPI= Received: from AM8P190MB0979.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:1d3::8) by AM0P190MB0578.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:1a1::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3455.21; Tue, 13 Oct 2020 13:40:40 +0000 Received: from AM8P190MB0979.EURP190.PROD.OUTLOOK.COM ([fe80::b0bf:bd8a:de8f:55fa]) by AM8P190MB0979.EURP190.PROD.OUTLOOK.COM ([fe80::b0bf:bd8a:de8f:55fa%5]) with mapi id 15.20.3477.020; Tue, 13 Oct 2020 13:40:40 +0000 From: Esko Dijk To: "dnssd@ietf.org" Thread-Topic: Review of draft-ietf-dnssd-srp-04; and relation to CoRE Resource Directory Thread-Index: AdahZCdWnFqFugrYTgawM9Kzp4FPCA== Date: Tue, 13 Oct 2020 13:40:40 +0000 Message-ID: Accept-Language: en-US, nl-NL 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-originating-ip: [2001:1c02:3103:f000:89dc:581d:1c08:f7fd] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f690ffad-a4ab-49aa-484b-08d86f7d9328 x-ms-traffictypediagnostic: AM0P190MB0578: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 30j+fjrQNWOZt6SxQLDzaLFMTgwt4z5BgKEUX6MiFPXSGbmoPjNVDQAc9JiHooipf9aJDAoDcTeW0Nq9kZBaQbZ8JlrUBdPdkdgDuTnMR1JXKwiedW1ARNR8h+Jrj6m8yxqcW/5eU1fSOVzOgDoJahzkHbKKtSkQvshoxOaVkIYELDxGt+1rs6YLkT0I4mFf3RpH0zUylWvE3prWnMkFRyouSI9S1vx9jd4KJbfeXjMjJTxmMBC+TFlErpYzZ4iZPi1zYQ20GqZLc2b77tgoxEjsMY1gmrV9v9R/HWiApTLzXAyiwTV4exgpolATuBQx 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:(136003)(366004)(346002)(396003)(39830400003)(376002)(478600001)(5660300002)(86362001)(83380400001)(186003)(2906002)(66446008)(64756008)(66476007)(76116006)(66556008)(33656002)(9686003)(316002)(8676002)(66946007)(8936002)(55016002)(52536014)(6506007)(9326002)(6916009)(44832011)(71200400001)(7696005); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: vqUTGzDtxQlL6X4JfDzxlD62JoBwh8dPDdOgNTO059soCGxj0SZjsoBTaU2VAPNioTiASjaB3MebmKgrlwl7SQ8p9oKZpkGhi6jHren+u4AMWnqG8oOe0DfGEvVLf+qL4WODL+mwhqZBs11AyuNdMRMBmA5zC/URLpwXAcv459uPNCsfEHdbKaNU8iVrRdLiaNsqfMZBRRfXB2Jk2MaVrEIWMXfN6Z2GldcPBWhhTemT8ziVk5EJghRGPHSFEhmSeM6rJ/OGvlXLBQXjzPzbcnpSwmjVkrD8Cg+lR1ZEqdZJKN8q4E1Chwr7aFJhDbIK+WE9hlfEyTzULg6vEECd3L3dNlYfHW7qxcf0DXtNcaizXtRydgPbTpH2OtgqfQr2jwwAkle6waoU4Au0hfMQH3cgJo9M66jqEF3XNpVWFUcqzOtN9/1jMR5t5UBN0lXxAXqwGCIsydjIyw0Uf7nfgX8ts06zYx+A/DkDCcSS0Wx8TYRouTlBmBg3YbgR7Zgb926OszsG9aekH31SX1AQA4ylJ06qVgEsRCjFUq4LZGa53x+NajKL0zM3CQBL4ONMtL/aiG4mj4RqmO5rRgkb4ZYx1wPTSmxAyr/sYDjYXtrAA0A3A0nXTVL8Kpn3xwKj0a5lQMnS31wxkrtUIF7VylILrSXaMp7dZ9YVAHjZbTsCMCiTsVslDOjVGLUPdM2Bo/v5EIPnatqxCjrzevTRwQ== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_AM8P190MB09797A6986A3187C2178F440FD040AM8P190MB0979EURP_" 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: f690ffad-a4ab-49aa-484b-08d86f7d9328 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Oct 2020 13:40:40.2644 (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: SKNvmHj/eBVWc5rlBJwEjtDBLNeW2o78I22yaznhu8D4gWeZgxDyG4Z7Xl5ogoSIt0c1Mtvm3jqhKP3K1aBR10k5oMnKXSarRROzTfC+rYk= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0P190MB0578 Archived-At: Subject: [dnssd] Review of draft-ietf-dnssd-srp-04; and relation to CoRE Resource Directory 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, 13 Oct 2020 13:40:55 -0000 --_000_AM8P190MB09797A6986A3187C2178F440FD040AM8P190MB0979EURP_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8sDQoNCg0KDQpJ4oCZdmUgcmV2aWV3ZWQgcmVjZW50bHkgU1JQIGRyYWZ0LWlldGYtZG5z c2Qtc3JwLTA0IGFuZCBhbHNvIENvUkUgcmVzb3VyY2UgZGlyZWN0b3J5IChkcmFmdC1pZXRmLWNv cmUtcmVzb3VyY2UtZGlyZWN0b3J5LCBsYXRlc3QgR2l0aHViIGRyYWZ0KSB0byBzZWUgaWYgdGhl c2UgYXJlIGFwcGxpY2FibGUgc2VydmljZSBkaXNjb3Zlcnkgc29sdXRpb25zIGZvciBjb25zdHJh aW5lZCBkZXZpY2VzIChzcGVjaWZpY2FsbHkgNkxvV1BBTiB3aXJlbGVzcyBtZXNoIG5ldHdvcmsg bm9kZXMsIHRoYXQgbWF5IG9wZXJhdGUgdXNpbmcgdGhlIFRocmVhZCBwcm90b2NvbCBvciBvdGhl cikuIEZvciBTUlAgc2VlIHRoZSByZXN1bHRzIG9mIG15IGluaXRpYWwgcmV2aWV3IGJlbG93OyBo b3BlIHRoaXMgaGVscHMgaW4gaW1wcm92aW5nIHRoZSBkb2N1bWVudCBmdXJ0aGVyLg0KDQoNCg0K Qm90aCBTUlAgYW5kIFJEIHRhcmdldCBzaW1pbGFyIHVzZSBjYXNlcy4gSXQgd291bGQgYmUgaW50 ZXJlc3RpbmcgdG8gdW5kZXJzdGFuZCBpZiBzZXJ2aWNlcyByZWdpc3RlcmVkIHVuZGVyIG9uZSBm b3JtYXQgKGUuZy4gRE5TLVNEIFNSUCkgY2FuIGJlIHF1ZXJpZWQvZGlzY292ZXJlZCB1c2luZyBh bm90aGVyIGZvcm1hdCAoZS5nLiBDb1JFIFJEKTsgYnV0IHRoYXTigJlzIGZ1dHVyZSB3b3JrIGZv ciBtZS4gKGRyYWZ0LWlldGYtY29yZS1yZC1kbnMtc2QgYWxyZWFkeSBwcm92aWRlcyBhIHN0YXJ0 IGZvciB0aGlzLikNCg0KDQoNCkJlc3QgcmVnYXJkcw0KDQpFc2tvDQoNCg0KDQotLS0gUmV2aWV3 IC0wNA0KDQpPdmVyYWxsOiB0aGUgZHJhZnQgbmljZWx5IGJ1aWxkcyBvbiBleGlzdGluZy9vdGhl ciBjb21wb25lbnRzIGluIElFVEYgYW5kIFNSUCBsb29rcyBsaWtlIGEgcG90ZW50aWFsbHkgZ29v ZCBzb2x1dGlvbiBmb3IgSW9UL2NvbnN0cmFpbmVkIGRldmljZXMuDQoNCg0KDQpTZWN0aW9uIDIN Cg0KIl9kbnNzZC1zcnAuX3RjcDx6b25lPiINCg0KIl9kbnNzZC1zcnAtdGxzLl90Y3A8em9uZT4i DQoNCi0+IHRoZXNlIHNob3VsZCBoYXZlICJfdGNwLjx6b25lPiIgd2l0aCBhIGRvdCBiZWZvcmUg PHpvbmU+LCByaWdodD8NCg0KDQoNClNlY3Rpb24gMiB0ZXh0ICh1cCB0byB0aGUgMi4xIGhlYWRl cikgY291bGQgYmUgbW9yZSBjbGVhcmx5IHNwbGl0IGluIHRoZSB0d28gdmFyaWFudHM6IGZ1bGwt ZmVhdHVyZWQgaG9zdCwgYW5kIGNvbnN0cmFpbmVkIGhvc3QuIEluaXRpYWxseSBJIHdhcyBjb25m dXNlZCBoZXJlIGJ5IHRoZSBtaXh0dXJlIG9mIGJvdGgsIHRoaW5raW5nIHRoYXQgdGhlIGNvbnN0 cmFpbmVkIGRldmljZXMgYWxzbyBuZWVkZWQgdG8gdXNlIERIQ1B2NCBEb21haW4gTmFtZSBvcHRp b24gb3IgTkQgRE5TIFNlYXJjaCBMaXN0IG9wdGlvbi4NCg0KQnV0IGxhdGVyIGl0IHR1cm5zIG91 dCB0aGlzIGlzbid0IG5lZWRlZCBhbmQgdGhlc2UgTUFZIHVzZSB0aGUgZGVmYXVsdCBkb21haW4g b25seS4gQ3JlYXRpbmcgYSBuZXcgU2VjdGlvbiAyLjEgd2l0aCB0d28gc3Vic2VjdGlvbnMgd291 bGQgc29sdmUgdGhpcyBlLmcuDQoNCjIuMSBQcm90b2NvbCB2YXJpYW50cw0KDQoyLjEuMSBGdWxs LWZlYXR1cmVkIGhvc3RzDQoNCjIuMS4yIENvbnN0cmFpbmVkIGhvc3RzICAob3I6IENvbnN0cmFp bmVkIG5vZGVzKQ0KDQoyLjQuMSAvIDIuNC4xLjENCldoYXQgc2VlbXMgdG8gYmUgbWlzc2luZyBp biB0aGVzZSBzZWN0aW9ucyBpcyB0aGUgc2VydmljZeKAmXMgaG9zdCByZXF1aXJlZCBvciByZWNv bW1lbmRlZCBiZWhhdmlvciwgaW4gY2FzZSB0aGUgcmVnaXN0cmF0aW9uIGZhaWxzLiBGb3IgZXhh bXBsZSBpZiB0aGUgbmFtZSBpcyBhbHJlYWR5IHRha2VuIGJ5IGFub3RoZXIgZGV2aWNlLCB3aGF0 IHdvdWxkIGl0IGRvPyBFLmcuIGRlZmluZSBhIG5ldyBuYW1lPw0KKEF0IHRoaXMgcG9pbnQgaW4g dGhlIGRyYWZ0IHRoZSByZWFkZXIgZG9lc27igJl0IHlldCBrbm93IGhvdyB0aGUgU1JQIHNlcnZl ciB3aWxsIGNvbXBhcmUgdGhlIHRvLWJlLXJlZ2lzdGVyZWQgbmFtZShzKSB0byBleGlzdGluZyBu YW1lKHMpIGluIHRoZSByZWdpc3RyeS4gRS5nLiBpcyBpdCBiYXNlZCBvbiBjaGVja2luZyBTZXJ2 aWNlIEluc3RhbmNlIE5hbWUgb25seT8gSSB3b3VsZCBleHBlY3QgdGhhdCBkZXNjcmliZWQgaW4g Mi40LjMgc29tZXdoZXJlLikNCg0KMi40LjMuMQ0KVHlwbzog4oCcSW5zdHJydWN0aW9uc+KAnQ0K DQoyLjUNCuKAnFRoZSBUVEwgc2hvdWxkIG5ldmVyIGJlIGxvbmdlciB0aGFuIHRoZSBsZWFzZSB0 aW1lIFNlY3Rpb24gMi42LjHigJ0NCi0+IHR5cG8/IENoYW5nZSB0byBlLmcuIOKAnFRoZSBUVEwg c2hvdWxkIG5ldmVyIGJlIGxvbmdlciB0aGFuIHRoZSBsZWFzZSB0aW1lIChzZWUgU2VjdGlvbiAy LjYuMSku4oCdDQoNCjIuNi4xDQrigJwgIEEgZGVmYXVsdCAgbGltaXQgb2YgdHdvIGhvdXJzIGZv ciB0aGUgTGVhc2UgYW5kIDE0IGRheXMgZm9yIHRoZSBTSUcoMCkgS0VZIGFyZSBjdXJyZW50bHkg dGhvdWdodCB0byBiZSBnb29kIGNob2ljZXMu4oCdDQotPiB0aGlzIGlzIGludGVyZXN0aW5nIHRv IGNvbXBhcmUgdG8gdGhlIGFzc3VtcHRpb25zIG9mIENvUkUgUmVzb3VyY2UgRGlyZWN0b3J5IGRl ZmF1bHQgbGVhc2UgdGltZSwgd2hpY2ggaXMgMjUgaG91cnMuDQpUaGF0IGlzIHF1aXRlIGEgbGFy Z2UgZGlmZmVyZW5jZS4gU2luY2UgYm90aCBzcGVjcyB0YXJnZXQgY29uc3RyYWluZWQgbm9kZXMs IEkgd291bGQgZXhwZWN0IHRoZSB2YWx1ZXMgdG8gYmUgY2xvc2VyPw0KSXMgdGhlIDI1IGhvdXJz IHRvbyBsb25nLCBvciB0aGUgMiBob3VycyB0b28gc2hvcnQ/DQoNCldoYXQgSSBkbyBsaWtlIGEg bG90IGluIHRoaXMgZHJhZnQgaXMgdGhhdCB0aGUgU1JQIHNlcnZlciBjYW4gc2hvcnRlbiBvciBs ZW5ndGhlbiB0aGUgbGVhc2UgdGltZSwgYW5kIHRoZSBjbGllbnQgaG9ub3JzIHRoaXMuIENvUkUg UkQgZG9lc24ndCBoYXZlIHRoaXMgZmVhdHVyZSENClRoaXMgcHJvdmlkZXMgYW4g4oCYb3V0IG9m IHRoZSBib3jigJkgc3RhbmRhcmQgbWV0aG9kIGZvciBoaWdoZXIgYWRhcHRpdml0eSB0byBkaWZm ZXJlbnQgdXNlIGNhc2VzLCBpZiBuZWVkZWQuDQoNCg0KMi42LjIgU2xlZXAgUHJveHkNCg0KVGhp cyB0cmlnZ2VycyBzb21lIHF1ZXN0aW9uczoNCg0KICAqICAgSXQgaXMgbWVudGlvbmVkIHRoYXQg dGhlIHNsZWVwIHByb3h5IG1heSBiZSBvbiBhbm90aGVyIGxpbmsuIEhvdyB3b3VsZCBhIFNSUCBz ZXJ2ZXIgc2V0IHVwIGEgc2xlZXAgcHJveHkgb24gYW5vdGhlciBsaW5rIHRoYW4gdGhlIG9uZSBp dCBpcyBjdXJyZW50bHkgYXR0YWNoZWQgdG8/IEhvdyB3b3VsZCBpdCBrbm93IHdoYXQgbGluayB0 byBjaG9vc2UgdG8gc2V0IGl0IHVwPw0KICAqICAgSG93IHdvdWxkIGEgc2VydmljZeKAmXMgaG9z dCBrbm93IHRoYXQgdGhlIHNlcnZlciBpcyBjYXBhYmxlIHRvIGRvIHRoaXM/IElmIGl0IGRvZXNu J3Qga25vdyB0aGVuIGl0IGNhbm5vdCB0cnVzdCB0aGUgbWVjaGFuaXNtIHRvIHdvcmsgYW5kIGdv IHRvIHNsZWVwLg0KICAqICAgT3IsIGlzIHRoZXJlIGEgd2F5IGZvciB0aGUgU1JQIHNlcnZlciB0 byByZWplY3QgYW4gdXBkYXRlIHdpdGggRUROUygwKSBPV05FUiBvcHRpb24gc3VjaCB0aGF0IHRo ZSBzZXJ2aWNl4oCZcyBob3N0IGtub3dzIG5vdCB0byB1c2UgaXQgYWdhaW4/DQoNCk92ZXJhbGws IGlzIHNsZWVwIHByb3h5IHN1cHBvcnQgbWFuZGF0b3J5IGZvciB0aGUgU1JQIHNlcnZlcj8gVGhp cyBzZWVtcyBub3QgY2xlYXIuDQoNCg0KDQrigJxXaGVuIGEgRE5TIHNlcnZlciByZWNlaXZlcyBh IEROUyBVcGRhdGUgd2l0aCBhbiBFRE5TKDApIE9XTkVSIE9wdGlvbiwgdGhhdA0KDQogICBzaWdu aWZpZXMgdGhhdCB0aGUgU1JQIHNlcnZlciBzaG91bGQgc2V0IHVwIGEgcHJveHnigJ0NCg0KLT4g aXMgdGhlcmUgYSBkaWZmZXJlbmNlIGJldHdlZW4gRE5TIHNlcnZlciBhbmQgU1JQIHNlcnZlcj8g SXMgaXQgdGhlIHNhbWUgZW50aXR5IGhlcmU/DQoNCldlIGFsc28gaGF2ZSDigJxTUlAgZnVuY3Rp b27igJ0gdGhhdCBhIEROUyBzZXJ2ZXIgY2FuIGltcGxlbWVudC4gU29tZSBjbGFyaWZpY2F0aW9u IG9mIHRlcm1zIGNvdWxkIGhlbHAgaGVyZSENCg0KDQoNCjMuMQ0KDQrigJxGb3IgQW55Y2FzdCB1 cGRhdGVzLCB0aGlzIHZhbGlkYXRpb24gbXVzdCBiZSBlbmZvcmNlZCBieSBldmVyeSByb3V0ZXLi gJ0NCg0KIC0+IHRvIGNsYXJpZnkgdGhpcyBhIGJpdCwgZS5nLiAiRm9yIHVwZGF0ZXMgc2VudCB0 byBhbiBhbnljYXN0IGRlc3RpbmF0aW9uIElQIGFkZHJlc3Mgb2YgYW4gU1JQIHNlcnZlciINCg0K KCBTb21lb25lIG1pZ2h0IGJlIHRoaW5raW5nIG90aGVyd2lzZSBhYm91dCB1cGRhdGVzIHRvIGFu eWNhc3QgYWRkcmVzc2VzPykNCg0KIkROUy1TRCByZWdpc3RyYXRpb24gcHJvdG9jb2wgY2xpZW50 cyINCi0+IGlzIHRoaXMgdGhlIHNhbWUgYXMgU1JQIGNsaWVudHM/DQoNCjMuMiBhbmQgZW50aXJl IGRvY3VtZW50DQpUaGUgdGVybSDigJxTUlAgY2xpZW504oCdIGlzIHVzZWQsIHNvbWV0aW1lcyBm b3IgdGhlIHJlZ2lzdGVyaW5nIHNlcnZpY2XigJlzIGhvc3QgYW5kIHNvbWV0aW1lcyBmb3IgYSBj bGllbnQgdXNpbmcgb25seSB0aGUgc2VydmljZSBsb29rdXAgZnVuY3Rpb24uDQpJcyB0aGF0IGNv cnJlY3Q/IFNob3VsZCBpdCBiZSBleHBsYWluZWQgaW4gYSB0ZXJtaW5vbG9neSBzZWN0aW9uPyBB bmQgd2UgaGF2ZSBhbHNvIGFib3ZlIEROUy1TRCByZWdpc3RyYXRpb24gcHJvdG9jb2wgY2xpZW50 Lg0KQWxzbyDigJxTUlAgc2VydmVy4oCdIHZzIOKAnFNSUCBTZXJ2ZXLigJ0gYXJlIGJvdGggdXNl ZC4NCg0KMy4yDQoNClRoaXMgc2F5cyBub3RoaW5nIGFib3V0IHRoZSBTSUcoMCkgdmFsaWRhdGlv biByZXF1aXJlZCBieSB0aGUgU1JQIHNlcnZlci4gVGhhdCBzZWVtcyBzdHJhbmdlLCBnaXZlbiB0 aGUgdGl0bGU/DQoNClRpdGxlIGNvdWxkIGJlIGNoYW5nZWQgdG8gZS5nLiDigJx2YWxpZGF0aW5n IFNSUCBzZXJ2ZXIgcmVzcG9uc2Vz4oCdLiAgQW5kIHBlcmhhcHMgYWRkIHNvbWUgU0lHKDApIHZh bGlkYXRpb24gY29uc2lkZXJhdGlvbnMgYnkgdGhlIFNSUCBzZXJ2ZXIsIGlmIHdlIGhhdmUgYW55 LiAoRS5nLiBhdm9pZCBjZXJ0YWluIGFsZ29yaXRobXM/IFRyeSBvbmx5IG9uZSBvciB0cnkgbXVs dGlwbGU/IE1heWJlIHRoZSBrZXkgYWxyZWFkeSBlbmNvZGVzIHRoZSB1c2VkIGFsZ29yaXRobSDi gJMgSSBkaWRu4oCZdCBsb29rIGludG8gdGhhdDsgaW4gd2hpY2ggY2FzZSB0aGVyZSBjb3VsZCBi ZSBpbnZhbGlkIGFsZ29yaXRobXMgb3IgcGFyYW1ldGVycyBzcGVjaWZpZWQgZXRjLikNCg0KDQoz LjMuDQoNCiJTUlAgc2VydmVycyBTSE9VTEQgaW1wbGVtZW50IHRoZSBhbGdvcml0aG1zIC4uLiBz dGFydGluZyB3aXRoIGFsZ29yaXRobSBudW1iZXIgMTMiDQoNCi0+IGlzIHNvbWV3aGF0IGFtYmln dW91cy4gIENhbiBiZSBpbnRlcnByZXRlZCBpbiB0aGUgZXh0cmVtZSBjYXNlIGFzIGEgc2VydmVy IFNIT1VMRCBpbXBsZW1lbnQgYWxnb3JpdGhtIDYgLCBldmVuIHRob3VnaCBSRkMgODYyNCBzYXlz IGl0IE1VU1QgTk9UIGRvIHRoaXMuDQoNClRvIGJlIGNsZWFyZXIgaXQgY291bGQgYmUgcmVwaHJh c2VkIHRvDQoNCiJTUlAgc2VydmVycyBTSE9VTEQgaW1wbGVtZW50IGFsbCBhbGdvcml0aG1zIHNw ZWNpZmllZCBpbiBbUkZDIDg2MjRdIHNlY3Rpb24gMy4xIHRoYXQgYXJlIG51bWJlcmVkIDEzIG9y IGhpZ2hlciBhbmQgaGF2ZSBhICJNVVNUIiwgIlJFQ09NTUVOREVEIiwgb3IgIk1BWSIgZGVzaWdu YXRpb24gaW4gdGhlIHZhbGlkYXRpb24gY29sdW1uIG9mIHRoZSB0YWJsZS4iDQooVGhlIGV4cHJl c3Npb24g4oCcc3RhcnRpbmcgd2l0aCDigKYgbnVtYmVyIFjigJwgZmVlbHMgbGVzcyBmYW1pbGlh ciB0byBtZSBhcyBhIG5vbi1uYXRpdmUgc3BlYWtlci4gSXMgaXQgZXF1YWwgdG8g4oCcWCBhbmQg aGlnaGVyIG51bWJlcnPigJ0gPyBPciBkbyBJIGhhdmUgdG8gc3RhcnQgd2l0aCBYLikNCg0KDQo1 DQoNCkkgZG9uJ3QgdW5kZXJzdGFuZCB0aGUgZnVsbCBkZXRhaWxzIG9mIHdoYXQgaXMgcmVxdWVz dGVkIGhlcmUg4oCTIGJ1dCBsb29raW5nIG9uIGhpZ2ggbGV2ZWwgaXQgc2F5cyAidGhlcmUgbXVz dCBiZSBhIGRlbGVnYXRpb24iLg0KDQpGb3Igd2hvbSBpcyB0aGlzIHJlcXVpcmVtZW50PyAgSW1w bGVtZW50ZXJzIG9mIFNSUCBzZXJ2ZXJzLCBzeXN0ZW0gYWRtaW5zLCBvciBJQU5BLCBJQ0FOTiAs IC4uLiA/DQoNCkl0IHNlZW1zIDYuMSBhbHJlYWR5IGhhcyB0aGUgSUFOQSBwYXJ0IG9mIHRoZSBy ZXF1aXJlbWVudC4gQXJlIHRoZXJlIGV4cGxpY2l0IHJlcXVpcmVtZW50cyBvbiBvdGhlcnM/DQoN CjYuMiAvIDYuMw0Kd2h5IG5vIFVEUCBzZXJ2aWNlIGRlc2NyaXB0aW9uPw0KVGhlIGNvbnN0cmFp bmVkIGRldmljZXMgd291bGQgdXNlIFVEUCB0byByZWdpc3RlciBhbmQgYWxzbyB0byBxdWVyeSBm b3Igc2VydmljZXMgcG9zc2libHksIHNvIEkgd291bGQgZXhwZWN0IGFuICJfZG5zc2Qtc3JwLl91 ZHAuPGRvbWFpbj4uIiB0byBiZSBkZWZpbmVkIGF0IGxlYXN0Lg0KRXZlbiBpZiBvbiB0aGUgY29u c3RyYWluZWQgbmV0d29yayB0aGVyZSBtYXkgYmUgYSBjdXN0b20gd2F5IHRvIHByb3ZpZGUgdGhl IGhvc3QvcG9ydCBvZiB0aGUgU1JQIHNlcnZlciB0byBub2Rlcy4gIEFmdGVyIGFsbCBpdCAqbWln aHQqIHVzZSBETlMtU0QgZm9ybWF0IHRvIGRpc3RyaWJ1dGUgc3VjaCBpbmZvcm1hdGlvbiwgb3Ig bm90Pw0KQW5vdGhlciBjb25zaWRlcmF0aW9uOiBpZiBVRFAgaXMgc3VwcG9ydGVkLCB0aGVuIFVE UCtEVExTIG1heSBiZSB0b28/ICBBbHRob3VnaCB0aGF0IHdvdWxkIHNldmVyZWx5IGluY3JlYXNl IHRoZSByZXNvdXJjZSB1c2FnZSAocG93ZXIsIG5ldHdvcmsgYmFuZHdpZHRoKSBvZiBjb25zdHJh aW5lZCBkZXZpY2VzIHBlcmhhcHMgd2UgZG9u4oCZdCB3YW50IHRvIHJ1bGUgdGhhdCBvdXQuDQoN Cg0KNi40DQoNCmFkZHJlc3MgIlRCRDEiIGlzIG5vdCB1c2VkIGluIHRoZSByZXN0IG9mIHRoZSBk b2N1bWVudC4gSSB0aGluayB0aGVyZSBzaG91bGQgYmUgb3V0c2lkZSBzZWN0aW9uIDYgYSBzZWN0 aW9uIHRoYXQgZGVzY3JpYmVzIHRoZSB1c2FnZSBvZiBUQkQxLg0KDQooQ2FuIGJlIHNob3J0KQ0K DQoNCg0KUmVmZXJlbmNlcw0KDQpSRkMgMjEzNiBuZWVkcyB0byBiZSBhIG5vcm1hdGl2ZSByZWZl cmVuY2UuIEp1c3Qgc2VhcmNoaW5nIGZvciAiMjEzNiIgaW4gdGhlIHRleHQgcmV2ZWFscyBtYW55 IHBsYWNlcyB3aGVyZSBpdCBpcyBwb2ludGVkIHRvIFJGQyAyMTM2IGZvciBub3JtYXRpdmUgb3Bl cmF0aW9uLg0KDQpSRkMgMjkzMSAoU0lHKDApKSBuZWVkcyB0byBiZSBhIG5vcm1hdGl2ZSByZWZl cmVuY2UuICBUaGUgU1JQIHNlcnZlciBwZXJmb3JtcyB0aGlzIHZhbGlkYXRpb24gYW5kIGl0IGlz IG1hbmRhdG9yeSB0byBwZXJmb3JtIGl0LiBBbHNvIHNlcnZpY2UtcHVibGlzaGluZyBjbGllbnRz IG5lZWQgdG8gYWRkIHRoZSBzaWduYXR1cmUgYWx3YXlzLg0KDQpSRkMgNzg1OCBpcyBhbHNvIG5v cm1hdGl2ZSBmb3IgdGhlIHNhbWUgcmVhc29ucy4NCg0KW0ktRC5pZXRmLWRuc3NkLXB1c2hdIG5l ZWRzIHRvIGJlIGEgbm9ybWF0aXZlIHJlZmVyZW5jZSB0b28sIGFzIGluIFNlY3Rpb24gMiB0aGUg ZnVsbC1mZWF0dXJlZCBkZXZpY2VzIGFyZSByZXF1aXJlZCB0byB1c2UgaXQgdG8gImRpc2NvdmVy IHRoZSB6b25lIGFwZXggb2YgdGhlIGNsb3Nlc3QgZW5jbG9zaW5nIEROUyB6b25lIHVzaW5nIFNP QSBxdWVyaWVzIi4NCg0KcmVwbGFjZSBbSS1ELmlldGYtZG5zc2QtcHVzaF0gIC0+IFJGQyA4NzY1 DQoNCnVwZGF0ZSBbSS1ELmlldGYtZG5zb3AtYWxnb3JpdGhtLXVwZGF0ZV0gdG8gUkZDIDg2MjQN Cg0KQXBwZW5kaWNlcw0KQW4gZXhhbXBsZSDigJhzZXJ2aWNlIGRlc2NyaXB0aW9u4oCZIGZvciBh biBJb1QgZGV2aWNlIGFuZCBpdHMgZW5jb2RpbmcgKGUuZy4gc2l6ZSBvZiBlbnRpcmUgVURQIHJl Z2lzdHJhdGlvbiBtZXNzYWdlKSB3b3VsZCBiZSBvZiBpbnRlcmVzdCBoZXJlLiAoTm90IHJlcXVp cmVkIG9mIGNvdXJzZSwgYnV0IG5pY2UgdG8gaGF2ZSkNClRoaXMgY291bGQgZmFjaWxpdGF0ZSBz b21lIGluaXRpYWwgY29tcGFyaXNvbiBhZ2FpbnN0IENvUkUgUkQuDQoNCklvVGNvbnN1bHRhbmN5 Lm5sICB8ICBFbWFpbC9UZWFtczogZXNrby5kaWprQGlvdGNvbnN1bHRhbmN5Lm5sPG1haWx0bzpl c2tvLmRpamtAaW90Y29uc3VsdGFuY3kubmw+DQoNCg== --_000_AM8P190MB09797A6986A3187C2178F440FD040AM8P190MB0979EURP_ 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 dDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUx Nw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7 bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt c2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdp bjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y ZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0 LWlkOjY0MTM1NDE1MTsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0 ZS1pZHM6MTU0Nzk2ODMzNiAxOTE0MjAwNTcyIDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3 Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwwOmxl dmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6MjsNCgltc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6LTsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6 bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0K QGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNv dXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGww OmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2Rpbmdz O30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30N Ci0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6 ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2 OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0t LT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1 NEY3MiIgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3JkIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbiI+PHNwYW4gbGFuZz0iTkwiPkhlbGxvLDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluIj48c3BhbiBsYW5nPSJOTCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW4iPknigJl2 ZSByZXZpZXdlZCByZWNlbnRseSBTUlAgZHJhZnQtaWV0Zi1kbnNzZC1zcnAtMDQgYW5kIGFsc28g Q29SRSByZXNvdXJjZSBkaXJlY3RvcnkgKGRyYWZ0LWlldGYtY29yZS1yZXNvdXJjZS1kaXJlY3Rv cnksIGxhdGVzdCBHaXRodWIgZHJhZnQpIHRvIHNlZSBpZiB0aGVzZSBhcmUgYXBwbGljYWJsZSBz ZXJ2aWNlIGRpc2NvdmVyeSBzb2x1dGlvbnMgZm9yIGNvbnN0cmFpbmVkIGRldmljZXMgKHNwZWNp ZmljYWxseQ0KIDZMb1dQQU4gd2lyZWxlc3MgbWVzaCBuZXR3b3JrIG5vZGVzLCB0aGF0IG1heSBv cGVyYXRlIHVzaW5nIHRoZSBUaHJlYWQgcHJvdG9jb2wgb3Igb3RoZXIpLiBGb3IgU1JQIHNlZSB0 aGUgcmVzdWx0cyBvZiBteSBpbml0aWFsIHJldmlldyBiZWxvdzsgaG9wZSB0aGlzIGhlbHBzIGlu IGltcHJvdmluZyB0aGUgZG9jdW1lbnQgZnVydGhlci48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxl PSJtYXJnaW46MGluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGlu Ij5Cb3RoIFNSUCBhbmQgUkQgdGFyZ2V0IHNpbWlsYXIgdXNlIGNhc2VzLiBJdCB3b3VsZCBiZSBp bnRlcmVzdGluZyB0byB1bmRlcnN0YW5kIGlmIHNlcnZpY2VzIHJlZ2lzdGVyZWQgdW5kZXIgb25l IGZvcm1hdCAoZS5nLiBETlMtU0QgU1JQKSBjYW4gYmUgcXVlcmllZC9kaXNjb3ZlcmVkIHVzaW5n IGFub3RoZXIgZm9ybWF0IChlLmcuIENvUkUgUkQpOyBidXQgdGhhdOKAmXMgZnV0dXJlIHdvcmsg Zm9yIG1lLiAoZHJhZnQtaWV0Zi1jb3JlLXJkLWRucy1zZA0KIGFscmVhZHkgcHJvdmlkZXMgYSBz dGFydCBmb3IgdGhpcy4pPG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbiI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbiI+QmVzdCByZWdhcmRzPG86 cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbiI+RXNrbzxvOnA+PC9vOnA+PC9wPg0K PHAgc3R5bGU9Im1hcmdpbjowaW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1h cmdpbjowaW4iPi0tLSBSZXZpZXcgLTA0PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2lu OjBpbiI+T3ZlcmFsbDogdGhlIGRyYWZ0IG5pY2VseSBidWlsZHMgb24gZXhpc3Rpbmcvb3RoZXIg Y29tcG9uZW50cyBpbiBJRVRGIGFuZCBTUlAgbG9va3MgbGlrZSBhIHBvdGVudGlhbGx5IGdvb2Qg c29sdXRpb24gZm9yIElvVC9jb25zdHJhaW5lZCBkZXZpY2VzLjxvOnA+PC9vOnA+PC9wPg0KPHAg c3R5bGU9Im1hcmdpbjowaW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdp bjowaW4iPlNlY3Rpb24gMjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW4iPjxz cGFuIGxhbmc9Ik5MIj4mcXVvdDtfZG5zc2Qtc3JwLl90Y3AmbHQ7em9uZSZndDsmcXVvdDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbiI+PHNwYW4gbGFuZz0iTkwi PiZxdW90O19kbnNzZC1zcnAtdGxzLl90Y3AmbHQ7em9uZSZndDsmcXVvdDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbiI+LSZndDsgdGhlc2Ugc2hvdWxkIGhhdmUg JnF1b3Q7X3RjcC4mbHQ7em9uZSZndDsmcXVvdDsgd2l0aCBhIGRvdCBiZWZvcmUgJmx0O3pvbmUm Z3Q7LCByaWdodD8mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluIj5TZWN0aW9uIDIgdGV4 dCAodXAgdG8gdGhlIDIuMSBoZWFkZXIpIGNvdWxkIGJlIG1vcmUgY2xlYXJseSBzcGxpdCBpbiB0 aGUgdHdvIHZhcmlhbnRzOiBmdWxsLWZlYXR1cmVkIGhvc3QsIGFuZCBjb25zdHJhaW5lZCBob3N0 LiBJbml0aWFsbHkgSSB3YXMgY29uZnVzZWQgaGVyZSBieSB0aGUgbWl4dHVyZSBvZiBib3RoLCB0 aGlua2luZyB0aGF0IHRoZSBjb25zdHJhaW5lZCBkZXZpY2VzIGFsc28gbmVlZGVkIHRvDQogdXNl IERIQ1B2NCBEb21haW4gTmFtZSBvcHRpb24gb3IgTkQgRE5TIFNlYXJjaCBMaXN0IG9wdGlvbi48 bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluIj5CdXQgbGF0ZXIgaXQgdHVybnMg b3V0IHRoaXMgaXNuJ3QgbmVlZGVkIGFuZCB0aGVzZSBNQVkgdXNlIHRoZSBkZWZhdWx0IGRvbWFp biBvbmx5LiBDcmVhdGluZyBhIG5ldyBTZWN0aW9uIDIuMSB3aXRoIHR3byBzdWJzZWN0aW9ucyB3 b3VsZCBzb2x2ZSB0aGlzIGUuZy48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGlu Ij4yLjEgUHJvdG9jb2wgdmFyaWFudHM8bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46 MGluIj4yLjEuMSBGdWxsLWZlYXR1cmVkIGhvc3RzPG86cD48L286cD48L3A+DQo8cCBzdHlsZT0i bWFyZ2luOjBpbiI+Mi4xLjIgQ29uc3RyYWluZWQgaG9zdHMmbmJzcDsgKG9yOiBDb25zdHJhaW5l ZCBub2Rlcyk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Mi40LjEgLyAyLjQuMS4xPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaGF0IHNlZW1zIHRvIGJlIG1pc3NpbmcgaW4g dGhlc2Ugc2VjdGlvbnMgaXMgdGhlIHNlcnZpY2XigJlzIGhvc3QgcmVxdWlyZWQgb3IgcmVjb21t ZW5kZWQgYmVoYXZpb3IsIGluIGNhc2UgdGhlIHJlZ2lzdHJhdGlvbiBmYWlscy4gRm9yIGV4YW1w bGUgaWYgdGhlIG5hbWUgaXMgYWxyZWFkeSB0YWtlbiBieSBhbm90aGVyIGRldmljZSwgd2hhdCB3 b3VsZCBpdCBkbz8gRS5nLiBkZWZpbmUgYSBuZXcgbmFtZT88bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPihBdCB0aGlzIHBvaW50IGluIHRoZSBkcmFmdCB0aGUgcmVhZGVyIGRv ZXNu4oCZdCB5ZXQga25vdyBob3cgdGhlIFNSUCBzZXJ2ZXIgd2lsbCBjb21wYXJlIHRoZSB0by1i ZS1yZWdpc3RlcmVkIG5hbWUocykgdG8gZXhpc3RpbmcgbmFtZShzKSBpbiB0aGUgcmVnaXN0cnku IEUuZy4gaXMgaXQgYmFzZWQgb24gY2hlY2tpbmcgU2VydmljZSBJbnN0YW5jZSBOYW1lIG9ubHk/ IEkgd291bGQgZXhwZWN0IHRoYXQgZGVzY3JpYmVkDQogaW4gMi40LjMgc29tZXdoZXJlLik8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Mi40LjMuMTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+VHlwbzog4oCcSW5zdHJydWN0aW9uc+KAnTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4yLjU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPuKAnFRoZSBUVEwgc2hv dWxkIG5ldmVyIGJlIGxvbmdlciB0aGFuIHRoZSBsZWFzZSB0aW1lIFNlY3Rpb24gMi42LjHigJ08 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0mZ3Q7IHR5cG8/IENoYW5nZSB0 byBlLmcuIOKAnFRoZSBUVEwgc2hvdWxkIG5ldmVyIGJlIGxvbmdlciB0aGFuIHRoZSBsZWFzZSB0 aW1lIChzZWUgU2VjdGlvbiAyLjYuMSku4oCdPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjIuNi4x PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj7igJwmbmJzcDsgQSBkZWZhdWx0 Jm5ic3A7IGxpbWl0IG9mIHR3byBob3VycyBmb3IgdGhlIExlYXNlIGFuZCAxNCBkYXlzIGZvciB0 aGUgU0lHKDApIEtFWSBhcmUgY3VycmVudGx5IHRob3VnaHQgdG8gYmUgZ29vZCBjaG9pY2VzLuKA nTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LSZndDsgdGhpcyBpcyBpbnRl cmVzdGluZyB0byBjb21wYXJlIHRvIHRoZSBhc3N1bXB0aW9ucyBvZiBDb1JFIFJlc291cmNlIERp cmVjdG9yeSBkZWZhdWx0IGxlYXNlIHRpbWUsIHdoaWNoIGlzIDI1IGhvdXJzLjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhdCBpcyBxdWl0ZSBhIGxhcmdlIGRpZmZlcmVu Y2UuIFNpbmNlIGJvdGggc3BlY3MgdGFyZ2V0IGNvbnN0cmFpbmVkIG5vZGVzLCBJIHdvdWxkIGV4 cGVjdCB0aGUgdmFsdWVzIHRvIGJlIGNsb3Nlcj88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPklzIHRoZSAyNSBob3VycyB0b28gbG9uZywgb3IgdGhlIDIgaG91cnMgdG9vIHNo b3J0PzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaGF0IEkgZG8gbGlrZSBhIGxvdCBpbiB0aGlz IGRyYWZ0IGlzIHRoYXQgdGhlIFNSUCBzZXJ2ZXIgY2FuIHNob3J0ZW4gb3IgbGVuZ3RoZW4gdGhl IGxlYXNlIHRpbWUsIGFuZCB0aGUgY2xpZW50IGhvbm9ycyB0aGlzLiBDb1JFIFJEIGRvZXNuJ3Qg aGF2ZSB0aGlzIGZlYXR1cmUhPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5U aGlzIHByb3ZpZGVzIGFuIOKAmG91dCBvZiB0aGUgYm944oCZIHN0YW5kYXJkIG1ldGhvZCBmb3Ig aGlnaGVyIGFkYXB0aXZpdHkgdG8gZGlmZmVyZW50IHVzZSBjYXNlcywgaWYgbmVlZGVkLjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBzdHlsZT0ibWFyZ2luOjBpbiI+Mi42LjIgU2xlZXAgUHJveHk8bzpwPjwvbzpwPjwvcD4NCjxw IHN0eWxlPSJtYXJnaW46MGluIj5UaGlzIHRyaWdnZXJzIHNvbWUgcXVlc3Rpb25zOjxvOnA+PC9v OnA+PC9wPg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgdHlwZT0iZGlzYyI+DQo8bGkgc3R5 bGU9Im1hcmdpbi10b3A6MGluO21hcmdpbi1ib3R0b206MGluO21zby1saXN0OmwwIGxldmVsMSBs Zm8xIj5JdCBpcyBtZW50aW9uZWQgdGhhdCB0aGUgc2xlZXAgcHJveHkgbWF5IGJlIG9uIGFub3Ro ZXIgbGluay4gSG93IHdvdWxkIGEgU1JQIHNlcnZlciBzZXQgdXAgYSBzbGVlcCBwcm94eSBvbiBh bm90aGVyIGxpbmsgdGhhbiB0aGUgb25lIGl0IGlzIGN1cnJlbnRseSBhdHRhY2hlZCB0bz8gSG93 IHdvdWxkIGl0IGtub3cgd2hhdCBsaW5rDQogdG8gY2hvb3NlIHRvIHNldCBpdCB1cD88bzpwPjwv bzpwPjwvbGk+PGxpIHN0eWxlPSJtYXJnaW4tdG9wOjBpbjttYXJnaW4tYm90dG9tOjBpbjttc28t bGlzdDpsMCBsZXZlbDEgbGZvMSI+SG93IHdvdWxkIGEgc2VydmljZeKAmXMgaG9zdCBrbm93IHRo YXQgdGhlIHNlcnZlciBpcyBjYXBhYmxlIHRvIGRvIHRoaXM/IElmIGl0IGRvZXNuJ3Qga25vdyB0 aGVuIGl0IGNhbm5vdCB0cnVzdCB0aGUgbWVjaGFuaXNtIHRvIHdvcmsgYW5kIGdvIHRvIHNsZWVw LjxvOnA+PC9vOnA+PC9saT48bGkgc3R5bGU9Im1hcmdpbi10b3A6MGluO21hcmdpbi1ib3R0b206 MGluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj5PciwgaXMgdGhlcmUgYSB3YXkgZm9yIHRoZSBT UlAgc2VydmVyIHRvIHJlamVjdCBhbiB1cGRhdGUgd2l0aCBFRE5TKDApIE9XTkVSIG9wdGlvbiBz dWNoIHRoYXQgdGhlIHNlcnZpY2XigJlzIGhvc3Qga25vd3Mgbm90IHRvIHVzZSBpdCBhZ2Fpbj88 bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwIHN0eWxlPSJtYXJnaW46MGluIj5PdmVyYWxsLCBpcyBz bGVlcCBwcm94eSBzdXBwb3J0IG1hbmRhdG9yeSBmb3IgdGhlIFNSUCBzZXJ2ZXI/IFRoaXMgc2Vl bXMgbm90IGNsZWFyLjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW4iPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW4iPuKAnFdoZW4gYSBETlMgc2Vy dmVyIHJlY2VpdmVzIGEgRE5TIFVwZGF0ZSB3aXRoIGFuIEVETlMoMCkgT1dORVIgT3B0aW9uLCB0 aGF0PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbiI+Jm5ic3A7Jm5ic3A7IHNp Z25pZmllcyB0aGF0IHRoZSBTUlAgc2VydmVyIHNob3VsZCBzZXQgdXAgYSBwcm94eeKAnTxvOnA+ PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW4iPi0mZ3Q7IGlzIHRoZXJlIGEgZGlmZmVy ZW5jZSBiZXR3ZWVuIEROUyBzZXJ2ZXIgYW5kIFNSUCBzZXJ2ZXI/IElzIGl0IHRoZSBzYW1lIGVu dGl0eSBoZXJlPzxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW4iPldlIGFsc28g aGF2ZSDigJxTUlAgZnVuY3Rpb27igJ0gdGhhdCBhIEROUyBzZXJ2ZXIgY2FuIGltcGxlbWVudC4g U29tZSBjbGFyaWZpY2F0aW9uIG9mIHRlcm1zIGNvdWxkIGhlbHAgaGVyZSE8bzpwPjwvbzpwPjwv cD4NCjxwIHN0eWxlPSJtYXJnaW46MGluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIHN0eWxl PSJtYXJnaW46MGluIj4zLjE8bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluIj7i gJxGb3IgQW55Y2FzdCB1cGRhdGVzLCB0aGlzIHZhbGlkYXRpb24gbXVzdCBiZSBlbmZvcmNlZCBi eSBldmVyeSByb3V0ZXLigJ08bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluIj4m bmJzcDstJmd0OyB0byBjbGFyaWZ5IHRoaXMgYSBiaXQsIGUuZy4gJnF1b3Q7Rm9yIHVwZGF0ZXMg c2VudCB0byBhbiBhbnljYXN0IGRlc3RpbmF0aW9uIElQIGFkZHJlc3Mgb2YgYW4gU1JQIHNlcnZl ciZxdW90OzxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW4iPigmbmJzcDtTb21l b25lIG1pZ2h0IGJlIHRoaW5raW5nIG90aGVyd2lzZSBhYm91dCB1cGRhdGVzIHRvIGFueWNhc3Qg YWRkcmVzc2VzPyk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+JnF1b3Q7RE5TLVNEIHJlZ2lzdHJh dGlvbiBwcm90b2NvbCBjbGllbnRzJnF1b3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4tJmd0OyBpcyB0aGlzIHRoZSBzYW1lIGFzIFNSUCBjbGllbnRzPzxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4zLjIgYW5kIGVudGlyZSBkb2N1bWVudDxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+VGhlIHRlcm0g4oCcU1JQIGNsaWVudOKAnSBpcyB1c2VkLCBzb21l dGltZXMgZm9yIHRoZSByZWdpc3RlcmluZyBzZXJ2aWNl4oCZcyBob3N0IGFuZCBzb21ldGltZXMg Zm9yIGEgY2xpZW50IHVzaW5nIG9ubHkgdGhlIHNlcnZpY2UgbG9va3VwIGZ1bmN0aW9uLjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXMgdGhhdCBjb3JyZWN0PyBTaG91bGQg aXQgYmUgZXhwbGFpbmVkIGluIGEgdGVybWlub2xvZ3kgc2VjdGlvbj8gQW5kIHdlIGhhdmUgYWxz byBhYm92ZSBETlMtU0QgcmVnaXN0cmF0aW9uIHByb3RvY29sIGNsaWVudC48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFsc28g4oCcU1JQIHNlcnZlcuKAnSB2cyDigJxTUlAg U2VydmVy4oCdIGFyZSBib3RoIHVzZWQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjMuMjxvOnA+ PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW4iPlRoaXMgc2F5cyBub3RoaW5nIGFib3V0 IHRoZSBTSUcoMCkgdmFsaWRhdGlvbiByZXF1aXJlZCBieSB0aGUgU1JQIHNlcnZlci4gVGhhdCBz ZWVtcyBzdHJhbmdlLCBnaXZlbiB0aGUgdGl0bGU/DQo8bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxl PSJtYXJnaW46MGluIj5UaXRsZSBjb3VsZCBiZSBjaGFuZ2VkIHRvIGUuZy4g4oCcdmFsaWRhdGlu ZyBTUlAgc2VydmVyIHJlc3BvbnNlc+KAnS4mbmJzcDsgQW5kIHBlcmhhcHMgYWRkIHNvbWUgU0lH KDApIHZhbGlkYXRpb24gY29uc2lkZXJhdGlvbnMgYnkgdGhlIFNSUCBzZXJ2ZXIsIGlmIHdlIGhh dmUgYW55LiAoRS5nLiBhdm9pZCBjZXJ0YWluIGFsZ29yaXRobXM/IFRyeSBvbmx5IG9uZSBvciB0 cnkgbXVsdGlwbGU/IE1heWJlIHRoZSBrZXkgYWxyZWFkeQ0KIGVuY29kZXMgdGhlIHVzZWQgYWxn b3JpdGhtIOKAkyBJIGRpZG7igJl0IGxvb2sgaW50byB0aGF0OyBpbiB3aGljaCBjYXNlIHRoZXJl IGNvdWxkIGJlIGludmFsaWQgYWxnb3JpdGhtcyBvciBwYXJhbWV0ZXJzIHNwZWNpZmllZCBldGMu KTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbiI+My4zLjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9 Im1hcmdpbjowaW4iPiZxdW90O1NSUCBzZXJ2ZXJzIFNIT1VMRCBpbXBsZW1lbnQgdGhlIGFsZ29y aXRobXMgLi4uIHN0YXJ0aW5nIHdpdGggYWxnb3JpdGhtIG51bWJlciAxMyZxdW90OzxvOnA+PC9v OnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW4iPi0mZ3Q7IGlzIHNvbWV3aGF0IGFtYmlndW91 cy4mbmJzcDsgQ2FuIGJlIGludGVycHJldGVkIGluIHRoZSBleHRyZW1lIGNhc2UgYXMgYSBzZXJ2 ZXIgU0hPVUxEIGltcGxlbWVudCBhbGdvcml0aG0gNiAsIGV2ZW4gdGhvdWdoIFJGQyA4NjI0IHNh eXMgaXQgTVVTVCBOT1QgZG8gdGhpcy4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdp bjowaW4iPlRvIGJlIGNsZWFyZXIgaXQgY291bGQgYmUgcmVwaHJhc2VkIHRvIDxvOnA+PC9vOnA+ PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW4iPiZxdW90O1NSUCBzZXJ2ZXJzIFNIT1VMRCBpbXBs ZW1lbnQgYWxsIGFsZ29yaXRobXMgc3BlY2lmaWVkIGluIFtSRkMgODYyNF0gc2VjdGlvbiAzLjEg dGhhdCBhcmUgbnVtYmVyZWQgMTMgb3IgaGlnaGVyIGFuZCBoYXZlIGEgJnF1b3Q7TVVTVCZxdW90 OywgJnF1b3Q7UkVDT01NRU5ERUQmcXVvdDssIG9yICZxdW90O01BWSZxdW90OyBkZXNpZ25hdGlv biBpbiB0aGUgdmFsaWRhdGlvbiBjb2x1bW4gb2YgdGhlIHRhYmxlLiZxdW90OzxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+KFRoZSBleHByZXNzaW9uIOKAnHN0YXJ0aW5nIHdp dGgg4oCmIG51bWJlciBY4oCcIGZlZWxzIGxlc3MgZmFtaWxpYXIgdG8gbWUgYXMgYSBub24tbmF0 aXZlIHNwZWFrZXIuIElzIGl0IGVxdWFsIHRvIOKAnFggYW5kIGhpZ2hlciBudW1iZXJz4oCdID8g T3IgZG8gSSBoYXZlIHRvIHN0YXJ0IHdpdGggWC4pPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluIj41 PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbiI+SSBkb24ndCB1bmRlcnN0YW5k IHRoZSBmdWxsIGRldGFpbHMgb2Ygd2hhdCBpcyByZXF1ZXN0ZWQgaGVyZSDigJMgYnV0IGxvb2tp bmcgb24gaGlnaCBsZXZlbCBpdCBzYXlzICZxdW90O3RoZXJlIG11c3QgYmUgYSBkZWxlZ2F0aW9u JnF1b3Q7LjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW4iPkZvciB3aG9tIGlz IHRoaXMgcmVxdWlyZW1lbnQ/Jm5ic3A7IEltcGxlbWVudGVycyBvZiBTUlAgc2VydmVycywgc3lz dGVtIGFkbWlucywgb3IgSUFOQSwgSUNBTk4gLCAuLi4gPzxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5 bGU9Im1hcmdpbjowaW4iPkl0IHNlZW1zIDYuMSBhbHJlYWR5IGhhcyB0aGUgSUFOQSBwYXJ0IG9m IHRoZSByZXF1aXJlbWVudC4gQXJlIHRoZXJlIGV4cGxpY2l0IHJlcXVpcmVtZW50cyBvbiBvdGhl cnM/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjYuMiAvIDYuMzxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+d2h5IG5vIFVEUCBzZXJ2aWNlIGRlc2NyaXB0aW9uPzxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIGNvbnN0cmFpbmVkIGRldmljZXMgd291 bGQgdXNlIFVEUCB0byByZWdpc3RlciBhbmQgYWxzbyB0byBxdWVyeSBmb3Igc2VydmljZXMgcG9z c2libHksIHNvIEkgd291bGQgZXhwZWN0IGFuICZxdW90O19kbnNzZC1zcnAuX3VkcC4mbHQ7ZG9t YWluJmd0Oy4mcXVvdDsgdG8gYmUgZGVmaW5lZCBhdCBsZWFzdC48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkV2ZW4gaWYgb24gdGhlIGNvbnN0cmFpbmVkIG5ldHdvcmsgdGhl cmUgbWF5IGJlIGEgY3VzdG9tIHdheSB0byBwcm92aWRlIHRoZSBob3N0L3BvcnQgb2YgdGhlIFNS UCBzZXJ2ZXIgdG8gbm9kZXMuJm5ic3A7IEFmdGVyIGFsbCBpdCAqPGI+bWlnaHQ8L2I+KiB1c2Ug RE5TLVNEIGZvcm1hdCB0byBkaXN0cmlidXRlIHN1Y2ggaW5mb3JtYXRpb24sIG9yIG5vdD88bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFub3RoZXIgY29uc2lkZXJhdGlvbjog aWYgVURQIGlzIHN1cHBvcnRlZCwgdGhlbiBVRFArRFRMUyBtYXkgYmUgdG9vPyZuYnNwOyBBbHRo b3VnaCB0aGF0IHdvdWxkIHNldmVyZWx5IGluY3JlYXNlIHRoZSByZXNvdXJjZSB1c2FnZSAocG93 ZXIsIG5ldHdvcmsgYmFuZHdpZHRoKSBvZiBjb25zdHJhaW5lZCBkZXZpY2VzIHBlcmhhcHMgd2Ug ZG9u4oCZdCB3YW50IHRvIHJ1bGUgdGhhdCBvdXQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluIj42 LjQ8bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluIj5hZGRyZXNzICZxdW90O1RC RDEmcXVvdDsgaXMgbm90IHVzZWQgaW4gdGhlIHJlc3Qgb2YgdGhlIGRvY3VtZW50LiBJIHRoaW5r IHRoZXJlIHNob3VsZCBiZSBvdXRzaWRlIHNlY3Rpb24gNiBhIHNlY3Rpb24gdGhhdCBkZXNjcmli ZXMgdGhlIHVzYWdlIG9mIFRCRDEuPG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBp biI+KENhbiBiZSBzaG9ydCk8bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluIj5SZWZlcmVuY2VzPG86 cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbiI+UkZDIDIxMzYgbmVlZHMgdG8gYmUg YSBub3JtYXRpdmUgcmVmZXJlbmNlLiBKdXN0IHNlYXJjaGluZyBmb3IgJnF1b3Q7MjEzNiZxdW90 OyBpbiB0aGUgdGV4dCByZXZlYWxzIG1hbnkgcGxhY2VzIHdoZXJlIGl0IGlzIHBvaW50ZWQgdG8g UkZDIDIxMzYgZm9yIG5vcm1hdGl2ZSBvcGVyYXRpb24uPG86cD48L286cD48L3A+DQo8cCBzdHls ZT0ibWFyZ2luOjBpbiI+UkZDIDI5MzEgKFNJRygwKSkgbmVlZHMgdG8gYmUgYSBub3JtYXRpdmUg cmVmZXJlbmNlLiZuYnNwOyBUaGUgU1JQIHNlcnZlciBwZXJmb3JtcyB0aGlzIHZhbGlkYXRpb24g YW5kIGl0IGlzIG1hbmRhdG9yeSB0byBwZXJmb3JtIGl0LiBBbHNvIHNlcnZpY2UtcHVibGlzaGlu ZyBjbGllbnRzIG5lZWQgdG8gYWRkIHRoZSBzaWduYXR1cmUgYWx3YXlzLjxvOnA+PC9vOnA+PC9w Pg0KPHAgc3R5bGU9Im1hcmdpbjowaW4iPlJGQyA3ODU4IGlzIGFsc28gbm9ybWF0aXZlIGZvciB0 aGUgc2FtZSByZWFzb25zLjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW4iPltJ LUQuaWV0Zi1kbnNzZC1wdXNoXSBuZWVkcyB0byBiZSBhIG5vcm1hdGl2ZSByZWZlcmVuY2UgdG9v LCBhcyBpbiBTZWN0aW9uIDIgdGhlIGZ1bGwtZmVhdHVyZWQgZGV2aWNlcyBhcmUgcmVxdWlyZWQg dG8gdXNlIGl0IHRvICZxdW90O2Rpc2NvdmVyIHRoZSB6b25lIGFwZXggb2YgdGhlIGNsb3Nlc3Qg ZW5jbG9zaW5nIEROUyB6b25lIHVzaW5nIFNPQSBxdWVyaWVzJnF1b3Q7LjxvOnA+PC9vOnA+PC9w Pg0KPHAgc3R5bGU9Im1hcmdpbjowaW4iPnJlcGxhY2UgW0ktRC5pZXRmLWRuc3NkLXB1c2hdJm5i c3A7IC0mZ3Q7IFJGQyA4NzY1PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbiI+ dXBkYXRlIFtJLUQuaWV0Zi1kbnNvcC1hbGdvcml0aG0tdXBkYXRlXSB0byBSRkMgODYyNDxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5BcHBlbmRpY2VzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5BbiBleGFtcGxlIOKAmHNlcnZpY2UgZGVzY3JpcHRpb27igJkgZm9yIGFuIElv VCBkZXZpY2UgYW5kIGl0cyBlbmNvZGluZyAoZS5nLiBzaXplIG9mIGVudGlyZSBVRFAgcmVnaXN0 cmF0aW9uIG1lc3NhZ2UpIHdvdWxkIGJlIG9mIGludGVyZXN0IGhlcmUuIChOb3QgcmVxdWlyZWQg b2YgY291cnNlLCBidXQgbmljZSB0byBoYXZlKTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+VGhpcyBjb3VsZCBmYWNpbGl0YXRlIHNvbWUgaW5pdGlhbCBjb21wYXJpc29uIGFn YWluc3QgQ29SRSBSRC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9Im1z by1mYXJlYXN0LWxhbmd1YWdlOkVOLUdCIj5Jb1Rjb25zdWx0YW5jeS5ubDwvc3Bhbj48L2I+PHNw YW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLUdCIj4mbmJzcDsgfCZuYnNwOyBFbWFp bC9UZWFtczoNCjxhIGhyZWY9Im1haWx0bzplc2tvLmRpamtAaW90Y29uc3VsdGFuY3kubmwiPjxz cGFuIHN0eWxlPSJjb2xvcjojMDU2M0MxIj5lc2tvLmRpamtAaW90Y29uc3VsdGFuY3kubmw8L3Nw YW4+PC9hPiZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjxzcGFuIGxhbmc9ImVuLU5MIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_AM8P190MB09797A6986A3187C2178F440FD040AM8P190MB0979EURP_-- From nobody Thu Oct 29 09:24:56 2020 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 C36283A0B93; Thu, 29 Oct 2020 09:24:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dnssd@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.21.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dnssd@ietf.org Message-ID: <160398868975.20914.15256889153198384707@ietfa.amsl.com> Date: Thu, 29 Oct 2020 09:24:49 -0700 Archived-At: Subject: [dnssd] I-D Action: draft-ietf-dnssd-srp-05.txt 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, 29 Oct 2020 16:24:54 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Extensions for Scalable DNS Service Discovery WG of the IETF. Title : Service Registration Protocol for DNS-Based Service Discovery Authors : Ted Lemon Stuart Cheshire Filename : draft-ietf-dnssd-srp-05.txt Pages : 24 Date : 2020-10-29 Abstract: The Service Registration Protocol for DNS-Based Service Discovery uses the standard DNS Update mechanism to enable DNS-Based Service Discovery using only unicast packets. This makes it possible to deploy DNS Service Discovery without multicast, which greatly improves scalability and improves performance on networks where multicast service is not an optimal choice, particularly 802.11 (Wi-Fi) and 802.15.4 (IoT) networks. DNS-SD Service registration uses public keys and SIG(0) to allow services to defend their registrations against attack. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnssd-srp/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dnssd-srp-05 https://datatracker.ietf.org/doc/html/draft-ietf-dnssd-srp-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnssd-srp-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Oct 29 09:27:50 2020 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 8DA153A005C for ; Thu, 29 Oct 2020 09:27:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 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, T_SPF_TEMPERROR=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=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 MyeFK1Hjv8wv for ; Thu, 29 Oct 2020 09:27:45 -0700 (PDT) Received: from mail-il1-x12d.google.com (mail-il1-x12d.google.com [IPv6:2607:f8b0:4864:20::12d]) (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 B47D23A0112 for ; Thu, 29 Oct 2020 09:27:45 -0700 (PDT) Received: by mail-il1-x12d.google.com with SMTP id z2so3615715ilh.11 for ; Thu, 29 Oct 2020 09:27:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=iXHvavqAWJPvB8GlSm0hEJTOfCws/+WGzvlcgEIMlBw=; b=HpqZZh76RF34+I632CmCDZe+hLyLzMaF0HaPY2zRqIlOdGrFbhwb9GwdPfYE44yTpv 3j0tlAvCtxY5xBJ6eDV4E0zjazryD2IQ/cv97bQzLhQ1VV6WQ5EkWRnoIJ3MVZMJaAQx xSnUHFyihqY89ID6cGGvO7+mCXHOBXiIwJm7P1zA8E2btxG9dgi1o3HNlBIYXwzPIgTB UdUCFQs32gfcE6LGjKPAywhDbjiR9qCQaGQdWriJdrh7fHKpjgHQrYdafPiTZn3AsssW ODO3PN4Y6BkY/mpruseR4fW1gO9uy2Nxl5EAI/8NOzOLsAxBNKtb7nLgrAjG04mnD6li GXsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=iXHvavqAWJPvB8GlSm0hEJTOfCws/+WGzvlcgEIMlBw=; b=Knm7lkeImtZqor7QQ0Zun0Pt3843M9gRBp9sao2DOJC3TS0HeN/btZpWQl05TlUDm0 kG5II/NWeIcoAtRak/b15xCJnHyfzuplS3MhcmRtae1k/7WESmsXBgqjwEkvt639IEg1 5NUZnBuWi2FAOy0NvbDVvd6AAsZ1qAMa4FRcAzhBToh9hBJO3p8vXes2NMyOqTofAGuU qF+YsqgS4OzK0zd4qx3Q7hfLhCziE1+ZuYb1fMS1k9/Xx3hwh++7wR+QmYBdXpaUUGtL rq30Um3GKNPu4WzISODWA4eqpv2dqFjTUGFpxM67ocCUWycZhbTk+Wbsub/Ov+Wsrsdo XuHg== X-Gm-Message-State: AOAM530KFWRHll2xPqagD1n8KW6RJSuIqk3cOBSzJd3BwT1wdetU/HLH Smwl8pZ9gYJAI7jZILHd4DE/BCoZVUZWlA== X-Google-Smtp-Source: ABdhPJyD7Hwx0lAAagsD6HKLoNM6tcnHVDbUjnSlCwY8gXvYgQ1Rz5YbnKiaGKGbc4FPS3eSukz67g== X-Received: by 2002:a92:b003:: with SMTP id x3mr4033808ilh.4.1603988864807; Thu, 29 Oct 2020 09:27:44 -0700 (PDT) Received: from mithrandir.lan (c-24-91-177-160.hsd1.nh.comcast.net. [24.91.177.160]) by smtp.gmail.com with ESMTPSA id s5sm2517071ilj.60.2020.10.29.09.27.43 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 29 Oct 2020 09:27:44 -0700 (PDT) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_2903EA17-C50C-462A-9253-39BFAA0133EA" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.20.0.2.11\)) Date: Thu, 29 Oct 2020 12:27:42 -0400 In-Reply-To: Cc: dnssd@ietf.org To: Jonathan Hui References: X-Mailer: Apple Mail (2.3654.20.0.2.11) Archived-At: Subject: Re: [dnssd] Review of draft-ietf-dnssd-srp-02 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, 29 Oct 2020 16:27:49 -0000 --Apple-Mail=_2903EA17-C50C-462A-9253-39BFAA0133EA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Jonathan, thanks for the thorough review. Sorry for taking so long to = respond. I have updated the draft with changes to address your = comments. Diffs can be found here: = https://tools.ietf.org/rfcdiff?difftype=3D--hwdiff&url2=3Ddraft-ietf-dnssd= -srp-05.txt = I have additional work to do on this based on Esko=E2=80=99s review, but = I=E2=80=99ll do that in a separate update so the diffs don=E2=80=99t get = confused. Comments below: > On Oct 8, 2020, at 3:19 PM, Jonathan Hui = wrote: >=20 > I have reviewed this document. >=20 > I believe this document addresses a real pain point in constrained = networks - namely how constrained devices can publish services with = minimal round trips (i.e. one per update) and avoids the need for = expensive multicast. This is of great interest to the Thread Group and = Project CHIP efforts, both of which are based on IPv6. >=20 > Overall, I found the document well-written and easy to understand. >=20 > Detailed comments/questions below: >=20 > Intended status: Informational >=20 > Why not standards track? Because I accidentally put =E2=80=9Cinfo=E2=80=9D in the XML instead of = =E2=80=9Cstd=E2=80=9D. :) >=20 > [RFC6763] that allows services to automatically register their >=20 > It's not clear to me at this point what "automatic" really means. It = becomes clear later in the doc (e.g. Section 2.6.1), but I think it = would help to be clear in the Introduction. Thanks, this is a really good catch. I=E2=80=99ve substantially updated = the introduction to explain this in more detail. >=20 > Manual configuration of the registraton domain can be done either by >=20 > Typo: "registraton" -> "registration" :) > using UDP unless TCP is required due to the size of the update. It > is the responsibility of a Constrained-Node Network supporting SRP to > provide appropriate anycast routing to deliver the DNS updates to the > appropriate server. It is the responsibility of the SRP server >=20 > Is "appropriate" well-understood here? I could use some clarification = on what requirements are placed on the Constrained-Node Network to = support SRP anycast. For example, can there be more than one SRP server = on the network? If so, does the anycast address always need to map to = the same SRP server for a given host? Interesting, this was actually fixed in a newer version. So the whole = discussion of how to configure SRP on =E2=80=9Cconstrained-node = networks=E2=80=9D is now left up to the specification for that network = type. >=20 > o The Host Description records for a service are a KEY RR, used to > claim exclusive ownership of the service registration, and one or > more RRs of type A or AAAA, giving the IPv4 or IPv6 address(es) of > the host where the service resides. >=20 > Are there recommendations/thoughts on how an SRP server should handle = SRP updates containing multiple IPv6 addresses of varying scopes? Is = this a topic within scope of this document? I=E2=80=99ve added a paragraph to the validation section saying that = link-scope and IPv4 autoconf addresses are invalid, and registrations = that include them should be treated as invalid registrations. I=E2=80=99v= e also mentioned that addresses must be in scope for all potential = clients of the SRP server, but haven=E2=80=99t explained this in more = detail. I may add a section about this later. >=20 > updates do not include update prerequisites. The specified in >=20 > Typo: "The specified in..." Oops! > o An SRP server is not required to implement general DNS Update > prerequsite processing. >=20 > Typo: "prerequsite" -> "prerequisite"=20 >=20 :) > The service generates a public/private key pair. This key pair MUST > be stored in stable storage; if there is no writable stable storage > on the client, the client MUST be pre-configured with a public/ > private key pair in read-only storage that can be used. This key > pair MUST be unique to the device. >=20 > Strictly speaking, we require the service to retain the key pair for = as long as it would like to make updates to its existing service = information. For example, should we recommend that a device generate a = new key pair after factory reset (if it has the ability to do that)? I'm = thinking that the public key can serve as a static identifier. Yes, that=E2=80=99s intended. I=E2=80=99ve added some text. >=20 > update is constructed by the client, it MUST include include an >=20 > Typo: "include include" :) >=20 > updates, and MUST reject updates that would otherwise be SRP updates > updates if they do not include leases. >=20 > Typo: "SRP updates updates" Wow. :) >=20 > lease time Section 2.6.1. Shorter TTLs will result in more frequent > data refreshes; this increases latency on the client side, and > increases load on any caching resolvers and on the authoritative > server. Longer TTLs will increase the likelihood that data in caches >=20 > Worth mentioning effect on network utilization? Or is that already = implied? OK. I added text. >=20 > addresses in the records in question. In addition, proxy should >=20 > Typo: "In addition, the proxy should..." :) >=20 > specified in [I-D.ietf-dnsop-algorithm-update] section 3.1, in the >=20 > "section 3.1" link not pointing to the appropriate doc. I=E2=80=99ve updated to point to the RFC. >=20 > 4. Privacy Considerations >=20 > Should we mention UDP here? Dunno what you mean about this. >=20 > Should we mention the public key here? I=E2=80=99ve added some text. I think we may also want to allow the = client to say =E2=80=9Cdon=E2=80=99t show my key.=E2=80=9D >=20 > specification in [RFC8375]Section 7. >=20 > "Section 7" link not pointing to the appropriate doc. >=20 I=E2=80=99m not following this. > Thanks. >=20 > -- > Jonathan Hui >=20 > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd --Apple-Mail=_2903EA17-C50C-462A-9253-39BFAA0133EA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Jonathan, thanks for the thorough review. Sorry for taking so = long to respond.  I have updated the draft with changes to address = your comments. Diffs can be found here: https://tools.ietf.org/rfcdiff?difftype=3D--hwdiff&url2=3Dd= raft-ietf-dnssd-srp-05.txt

I have additional work to do on this based on Esko=E2=80=99s = review, but I=E2=80=99ll do that in a separate update so the diffs = don=E2=80=99t get confused. Comments below:


On Oct 8, 2020, at 3:19 PM, Jonathan Hui <jonhui=3D40google.com@dmarc.ietf.org> wrote:

I have reviewed this = document.

I = believe this document addresses a real pain point in constrained = networks - namely how constrained devices can publish services with = minimal round trips (i.e. one per update) and avoids the need for = expensive multicast. This is of great interest to the Thread Group and = Project CHIP efforts, both of which are based on IPv6.

Overall, I found the = document well-written and easy to understand.

Detailed comments/questions = below:

Intended status: Informational

Why not standards = track?
Because I accidentally put =E2=80=9Cinfo=E2=80=9D in = the XML instead of =E2=80=9Cstd=E2=80=9D. :)

[RFC6763] that allows services to automatically register = their

It's not clear to me at this point what "automatic" = really means. It becomes clear later in the doc (e.g. Section 2.6.1), = but I think it would help to be clear in the = Introduction.
=

Thanks, this is a really good catch. I=E2=80=99v= e substantially updated the introduction to explain this in more = detail.

Manual configuration of the registraton domain can be done = either by

Typo: "registraton" -> = "registration"

:)

using UDP unless TCP is required due to the size of the = update.  It
is the responsibility of a = Constrained-Node Network supporting SRP to
provide = appropriate anycast routing to deliver the DNS updates to the
appropriate server.  It is the responsibility of the SRP = server

Is "appropriate" well-understood here? = I could use some clarification on what requirements are placed on the = Constrained-Node Network to support SRP anycast. For example, can there = be more than one SRP server on the network? If so, does the anycast = address always need to map to the same SRP server for a given = host?
Interesting, this was actually fixed in a newer = version. So the whole discussion of how to configure SRP on = =E2=80=9Cconstrained-node networks=E2=80=9D is now left up to the = specification for that network type.

o =  The Host Description records for a service are a KEY RR, used = to
   claim exclusive ownership of the service = registration, and one or
   more RRs of type A = or AAAA, giving the IPv4 or IPv6 address(es) of
  =  the host where the service resides.

Are there recommendations/thoughts on how an SRP server = should handle SRP updates containing multiple IPv6 addresses of varying = scopes? Is this a topic within scope of this document?

I=E2=80=99ve added a paragraph to the validation = section saying that link-scope and IPv4 autoconf addresses are invalid, = and registrations that include them should be treated as invalid = registrations.  I=E2=80=99ve also mentioned that addresses must be = in scope for all potential clients of the SRP server, but haven=E2=80=99t = explained this in more detail. I may add a section about this = later.


updates do not include update prerequisites. The specified = in

Typo: "The specified = in..."

Oops!

o  An SRP server is not required to = implement general DNS Update
   prerequsite = processing.

Typo: "prerequsite" -> = "prerequisite" 

:)

The service generates a public/private key = pair.  This key pair MUST
be stored in stable = storage; if there is no writable stable storage
on the = client, the client MUST be pre-configured with a public/
private key pair in read-only storage that can be used.  = This key
pair MUST be unique to the device.

Strictly speaking, we require the service to retain the key = pair for as long as it would like to make updates to its existing = service information. For example, should we recommend that a device = generate a new key pair after factory reset (if it has the ability to do = that)? I'm thinking that the public key can serve as a static = identifier.
Yes, that=E2=80=99s intended.  I=E2=80=99ve added = some text.


update is constructed by the client, it MUST include include = an

Typo: "include include"
:)


updates, and MUST reject updates that would otherwise be SRP = updates
updates if they do not include leases.

Typo: "SRP = updates updates"

Wow. :)


lease time Section 2.6.1.  = Shorter TTLs will result in more frequent
data refreshes; = this increases latency on the client side, and
increases = load on any caching resolvers and on the authoritative
server.  Longer TTLs will increase the likelihood that = data in caches

Worth mentioning effect on network utilization? Or is = that already = implied?

OK.  I added text.


addresses in the records in question.  In addition, = proxy should

Typo: "In addition, the proxy = should..."

:)


specified in [I-D.ietf-dnsop-algorithm-update] section 3.1, = in the

"section 3.1" link not pointing to the = appropriate = doc.

I=E2=80=99ve updated to point to the = RFC.


4. = Privacy Considerations

Should we mention UDP = here?

Dunno what you mean about = this.


Should = we mention the public key = here?

I=E2=80=99ve added some text. I think we = may also want to allow the client to say =E2=80=9Cdon=E2=80=99t show my = key.=E2=80=9D


specification in [RFC8375]Section 7.

"Section 7" link not = pointing to the appropriate doc.


I=E2=80=99m not following = this.

Thanks.

--
Jonathan Hui

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

= --Apple-Mail=_2903EA17-C50C-462A-9253-39BFAA0133EA-- From nobody Thu Oct 29 12:31:49 2020 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 485693A084D for ; Thu, 29 Oct 2020 12:31:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XNX-lp-9p_YA for ; Thu, 29 Oct 2020 12:31:46 -0700 (PDT) Received: from mail-oi1-x233.google.com (mail-oi1-x233.google.com [IPv6:2607:f8b0:4864:20::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EFF33A003F for ; Thu, 29 Oct 2020 12:31:46 -0700 (PDT) Received: by mail-oi1-x233.google.com with SMTP id 9so4219260oir.5 for ; Thu, 29 Oct 2020 12:31:46 -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=b+/wMby9Bq57udhlAG/QwFuenhFOdPQ7bLlOBnlIR24=; b=elo98VMYS9NBFSSaHfapWyCu5WClp2yYLjdGtthl4ZezFb8iy+QlD1zsyDMM1OddxP hKFj/ayW75Fg2gXzHZTVf3DZmt/zs+u9w9PPH3275ZWtip9sbulbagTFXgrhuJafcvGX ond4sOrrysg8yMX3rBDi/JPGRMyIBmazNzpbrHAHWtx52VLsnk+enNtfyQflv0bNYbKf 99mwS9J1qk6Kr/8bJ2+c2A/3Op3OuuhA9mO7u81tb7RH5/YHSWx/ui1EvYOPwmZb0iuU 7eZm0numiivVbs1P+OneJsUIsqseje/qgTWhgu57HXwFtCNCT9VF1SlimjjJCg+poI8q X9iQ== 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=b+/wMby9Bq57udhlAG/QwFuenhFOdPQ7bLlOBnlIR24=; b=nvDwDnt8JFDHdDyjEq+ILlAFs0tCwaXEBHFjWr+4B8YAiZxoIgcc3ZVQMb66no7Ujw TX8h4yKhfTS/1QqQOtDJLabmRxoGGuL9bu3sP/eiAOeV28G5mYY/qVlV/oRjVUdsZ4r0 aknIjYA+Nojj/m+NNB3j+Ssp3eBRa4qtXhoIpl1J6nX25dX5JqaHWfKrFrqQ09hfXIkP 5iAynm5Smerhnt90OpeZDjC/MvrkUnCbsxDOFtDPtVQUjLXBNMXflYqkiUmGqjbB7bYX UsrF/Mk7SVhZLcDujMZIQz9LbUFKYiBTJWNyBL+5cCzabTj2eFaDfo/GSYRbBoTWOAf6 6EMw== X-Gm-Message-State: AOAM533qfhxgXUErcMX7FxWB7vqRFfWTqiZ5LkikaF0FdSxEBHjjZ8vm KEuyEXYzrRASBAYNoYv/+tl/VTjiiDJf23P69D82WFyfnGpdiHw+ X-Google-Smtp-Source: ABdhPJzqiH3/XgneKzaIWzqG9e2Rij1W7udMQCpZRpSZRdGcKoleqW/Rr2TG7KZ7HSrZ5lON0Jk6yRnFJuLQsYJvR7o= X-Received: by 2002:aca:6746:: with SMTP id b6mr877611oiy.24.1603999905062; Thu, 29 Oct 2020 12:31:45 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Jonathan Hui Date: Thu, 29 Oct 2020 12:31:33 -0700 Message-ID: To: Ted Lemon Cc: dnssd@ietf.org Content-Type: multipart/alternative; boundary="00000000000090131205b2d454da" Archived-At: Subject: Re: [dnssd] Review of draft-ietf-dnssd-srp-02 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, 29 Oct 2020 19:31:48 -0000 --00000000000090131205b2d454da Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Ted, Thanks for working to resolve my comments! Responses below: On Thu, Oct 29, 2020 at 9:27 AM Ted Lemon wrote: > On Oct 8, 2020, at 3:19 PM, Jonathan Hui < > jonhui=3D40google.com@dmarc.ietf.org> wrote: > > Intended status: Informational >> > > Why not standards track? > > Because I accidentally put =E2=80=9Cinfo=E2=80=9D in the XML instead of = =E2=80=9Cstd=E2=80=9D. :) > Draft-05 still indicates Informational. > [RFC6763] that allows services to automatically register their > > > It's not clear to me at this point what "automatic" really means. It > becomes clear later in the doc (e.g. Section 2.6.1), but I think it would > help to be clear in the Introduction. > > Thanks, this is a really good catch. I=E2=80=99ve substantially updated t= he > introduction to explain this in more detail. > The additional 4.5 paragraphs of text in the introduction looks great and the detail is certainly helpful. > using UDP unless TCP is required due to the size of the update. It >> is the responsibility of a Constrained-Node Network supporting SRP to >> provide appropriate anycast routing to deliver the DNS updates to the >> appropriate server. It is the responsibility of the SRP server >> > > Is "appropriate" well-understood here? I could use some clarification on > what requirements are placed on the Constrained-Node Network to support S= RP > anycast. For example, can there be more than one SRP server on the networ= k? > If so, does the anycast address always need to map to the same SRP server > for a given host? > > > Interesting, this was actually fixed in a newer version. So the whole > discussion of how to configure SRP on =E2=80=9Cconstrained-node networks= =E2=80=9D is now > left up to the specification for that network type. > Somehow I reviewed an older draft. The latest text looks good to me! > o The Host Description records for a service are a KEY RR, used to >> claim exclusive ownership of the service registration, and one or >> more RRs of type A or AAAA, giving the IPv4 or IPv6 address(es) of >> the host where the service resides. >> > > Are there recommendations/thoughts on how an SRP server should handle SRP > updates containing multiple IPv6 addresses of varying scopes? Is this a > topic within scope of this document? > > I=E2=80=99ve added a paragraph to the validation section saying that link= -scope > and IPv4 autoconf addresses are invalid, and registrations that include > them should be treated as invalid registrations. I=E2=80=99ve also menti= oned that > addresses must be in scope for all potential clients of the SRP server, b= ut > haven=E2=80=99t explained this in more detail. I may add a section about = this later. > Updated text looks good to me. > The service generates a public/private key pair. This key pair MUST >> be stored in stable storage; if there is no writable stable storage >> on the client, the client MUST be pre-configured with a public/ >> private key pair in read-only storage that can be used. This key >> pair MUST be unique to the device. >> > > Strictly speaking, we require the service to retain the key pair for as > long as it would like to make updates to its existing service information= . > For example, should we recommend that a device generate a new key pair > after factory reset (if it has the ability to do that)? I'm thinking that > the public key can serve as a static identifier. > > Yes, that=E2=80=99s intended. I=E2=80=99ve added some text. > Updated text looks good to me. > lease time Section 2.6.1. Shorter TTLs will result in more frequent >> data refreshes; this increases latency on the client side, and >> increases load on any caching resolvers and on the authoritative >> server. Longer TTLs will increase the likelihood that data in caches > > > Worth mentioning effect on network utilization? Or is that already implie= d? > > OK. I added text. > Typo: "be an + issue for" -> "be an issue for" Otherwise, the updated text looks good. > 4. Privacy Considerations > > > Should we mention UDP here? > > Dunno what you mean about this. > The current text recommends using TLS when using TCP to mitigate privacy concerns. Are there any recommendations or warnings to state here when host implementations are using UDP? > Should we mention the public key here? > > I=E2=80=99ve added some text. I think we may also want to allow the clien= t to say > =E2=80=9Cdon=E2=80=99t show my key.=E2=80=9D > Updated text looks good. Giving the client that flexibility sounds interesting. > specification in [RFC8375]Section 7. > > > "Section 7" link not pointing to the appropriate doc. > > I=E2=80=99m not following this. > The "Section 7" link in https://tools.ietf.org/html/draft-ietf-dnssd-srp-05 points to https://tools.ietf.org/html/draft-ietf-dnssd-srp-05#section-7. Thanks! -- Jonathan Hui --00000000000090131205b2d454da Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Ted,

Thanks for workin= g to resolve my comments! Responses below:

On Thu, Oct 29, 2020 at 9= :27 AM Ted Lemon <mellon@fugue.com> wrote:

Intended status: Informational

Why not standards track?
<= /div>
Because I accidentally put = =E2=80=9Cinfo=E2=80=9D in the XML instead of =E2=80=9Cstd=E2=80=9D. :)

Draft-05 still indicates Info= rmational.
<= div dir=3D"ltr">
[RFC6763] = that allows services to automatically register their

It's not clear to me at this point what=C2=A0"aut= omatic" really means. It becomes clear later in the doc (e.g. Section = 2.6.1), but I think it would help to be clear in the Introduction.
Thanks, this is a reall= y good catch. I=E2=80=99ve substantially updated the introduction to explai= n this in more detail.

Th= e additional 4.5 paragraphs of text in the introduction looks great and the= detail is certainly helpful.
using UDP unless TCP is required due to the size of the update.=C2=A0= It
is the responsibility of a Constrained-Node Network supporting SRP t= o
provide appropriate anycast routing to deliver the DNS updates to the<= br>appropriate server.=C2=A0 It is the responsibility of the SRP server

Is "appropriate" well-und= erstood here? I could use some clarification on what requirements are place= d on the Constrained-Node Network to support SRP anycast. For example, can = there be more than one SRP server on the network? If so, does the anycast a= ddress always need to map to the same SRP server for a given host?

Int= eresting, this was actually fixed in a newer version. So the whole discussi= on of how to configure SRP on =E2=80=9Cconstrained-node networks=E2=80=9D i= s now left up to the specification for that network type.
=

Somehow I reviewed an older draft. The lat= est text looks good to me!
o =C2=A0The Host Description records for a service are a KEY RR, used to=C2=A0 =C2=A0claim exclusive ownership of the service registration, and o= ne or
=C2=A0 =C2=A0more RRs of type A or AAAA, giving the IPv4 or IPv6 a= ddress(es) of
=C2=A0 =C2=A0the host where the service resides.

Are there recommendations/thoughts on how= an SRP server should handle SRP updates containing multiple IPv6 addresses= of varying scopes? Is this a topic within scope of this document?
I=E2=80=99ve added a pa= ragraph to the validation section saying that link-scope and IPv4 autoconf = addresses are invalid, and registrations that include them should be treate= d as invalid registrations.=C2=A0 I=E2=80=99ve also mentioned that addresse= s must be in scope for all potential clients of the SRP server, but haven= =E2=80=99t explained this in more detail. I may add a section about this la= ter.

Updated text looks good to= me.
The service generates a pu= blic/private key pair.=C2=A0 This key pair MUST
be stored in stable stor= age; if there is no writable stable storage
on the client, the client MU= ST be pre-configured with a public/
private key pair in read-only storag= e that can be used.=C2=A0 This key
pair MUST be unique to the device.

Strictly speaking, we require the = service to retain the key pair for as long as it would like to make updates= to its existing service information. For example, should we recommend that= a device generate a new key pair after factory reset (if it has the abilit= y to do that)? I'm thinking that the public key can serve as a static i= dentifier.
Yes, that= =E2=80=99s intended.=C2=A0 I=E2=80=99ve added some text.

Updated text looks good to me.
lease time Section 2.6.1.=C2=A0 Sho= rter TTLs will result in more frequent
data refreshes; this increases la= tency on the client side, and
increases load on any caching resolvers an= d on the authoritative
server.=C2=A0 Longer TTLs will increase the likel= ihood that data in caches

Worth mentioning = effect=C2=A0on network utilization? Or is that already implied?
=
OK.=C2=A0 I ad= ded text.

Typo: "be an=C2= =A0+ issue for" -> "be an issue for"

=
Otherwise, the updated text looks good.
4. Privacy Considerati= ons

Should we mention UDP here?
Dunno w= hat you mean about this.

The cu= rrent text recommends using TLS when using TCP to mitigate privacy concerns= . Are there any recommendations or warnings to state here when host impleme= ntations are using UDP?
Should we mention the public key here?=
I= =E2=80=99ve added some text. I think we may also want to allow the client t= o say =E2=80=9Cdon=E2=80=99t show my key.=E2=80=9D=

Updated text looks good. Giving the client that flexibi= lity sounds interesting.
<= div dir=3D"ltr">
specification in [RFC8375]Section 7.

"Section 7" link not pointing t= o the appropriate doc.
I=E2=80=99m not following this.


Thank= s!

--
Jonathan Hui

--00000000000090131205b2d454da--