From nobody Mon Nov 2 16:16:29 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 42A493A0A16 for ; Mon, 2 Nov 2020 16:16:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.886 X-Spam-Level: X-Spam-Status: No, score=-1.886 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NO_DNS_FOR_FROM=0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no 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 B6mXzcaYa3jR for ; Mon, 2 Nov 2020 16:16:24 -0800 (PST) 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 1F5503A09F0 for ; Mon, 2 Nov 2020 16:16:23 -0800 (PST) Received: by mail-qk1-x729.google.com with SMTP id x20so13274979qkn.1 for ; Mon, 02 Nov 2020 16:16:23 -0800 (PST) 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=9MyxoN++B29m0RRMnn5zUHwiT+yp14aUyNaGj4kZTok=; b=t6VmPeNkEvWj6YC9ZZc68jNLYvIu011rQmn0s79RWY2Y1I9iEG1g2nk4NX4kbN83FX aVbxx5NDd0f8QHAudHTHqSYpOxqO2/ktGHsuhpFPFexMDPA+SxrVmWV89EjZh4/ooDEV DGk+GeklNEsxoaVLw+VFS5uWaE5P/Z9eQL3j8c0j/7huqL0Y9+KMyhqdoJ80DBTzoxA8 StFdi3PZRVxUpWHKOIeCjpBQjLulNmZcJ+NKXK12r6YaNJqjl9KTclBqiR+MZkhrwSOe PQxKBtSBJOzk0Vd8lCm9G3HRLNzpyKhM9W4Y/V5KfActt/umd/ahJxt4FLscqYYrfTyK MtnA== 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=9MyxoN++B29m0RRMnn5zUHwiT+yp14aUyNaGj4kZTok=; b=JvrXMBNL+YUjSbuVOyBpeQipwsQcinhb7whSPBiEgUbSUuc22lRR5VvqBPoLVeQmh+ +XRvmfYAGM3dMmou0m53RomGpRmo+Vt8yS3jmcjVmNgcJWb7Tx0Q9lRNL9yOnByrr/oL cWNHOBsH7ozAJAyHqY1YoNsPJx0dt4VwF/zfRZpIzC6F1aRQKLxEa2Y8Fj7Jy1jNa1GH 3ZMCrqco+PMeW+wZUE7aff4qc27USYHwwLVtn/4xMXboC9poQOt3EbwNpcrrTZRXI5On EIK7s7JIJLF7/XBrBxYLds75aiFqSb9O/IdrrcWG0DsADBcM4zpGA3+tE+Xw7JpcMxUs viWA== X-Gm-Message-State: AOAM533tsQy8Cp6macgeIhfa9KTg35fp8QtR+Q/z/RmgreipaCI8/wP5 4/1/ZMRdq8Ik4bQfW8z1i7rlxayl2HFk/Q== X-Google-Smtp-Source: ABdhPJzvJzDwB8qx71imJ609Xd5jCsl3Xd3nNUL20YK3FFKZk8gL1IohVA/s/kIqDiJFr9/B8S4lPw== X-Received: by 2002:a37:a84e:: with SMTP id r75mr17880596qke.232.1604362582473; Mon, 02 Nov 2020 16:16:22 -0800 (PST) Received: from mithrandir.lan (c-24-91-177-160.hsd1.nh.comcast.net. [24.91.177.160]) by smtp.gmail.com with ESMTPSA id a21sm9077530qkk.98.2020.11.02.16.16.21 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Nov 2020 16:16:21 -0800 (PST) From: Ted Lemon Message-Id: <5205F6F9-50B1-4785-A311-880B1FD0AC30@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_D269ACFD-3273-460F-8182-55F25AB1655F" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.20.0.2.11\)) Date: Mon, 2 Nov 2020 19:16:19 -0500 In-Reply-To: Cc: DNSSD To: Esko Dijk References: X-Mailer: Apple Mail (2.3654.20.0.2.11) Archived-At: Subject: Re: [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, 03 Nov 2020 00:16:27 -0000 --Apple-Mail=_D269ACFD-3273-460F-8182-55F25AB1655F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Oct 13, 2020, at 9:40 AM, Esko Dijk = wrote: > I=E2=80=99ve reviewed recently SRP draft-ietf-dnssd-srp-04 and also = CoRE resource directory (draft-ietf-core-resource-directory, latest = Github draft) to see if these are applicable service discovery solutions = for constrained devices (specifically 6LoWPAN wireless mesh network = nodes, that may operate using the Thread protocol or other). For SRP see = the results of my initial review below; hope this helps in improving the = document further. > =20 > Both SRP and RD target similar use cases. It would be interesting to = understand if services registered under one format (e.g. DNS-SD SRP) can = be queried/discovered using another format (e.g. CoRE RD); but that=E2=80=99= s future work for me. (draft-ietf-core-rd-dns-sd already provides a = start for this.) Stuart and I discussed this at length with the author of that document. = It=E2=80=99s not as simple as it sounds. First, there are no common set = of parameters to publish in core RD, so any translation would have to be = based on heuristics. But Core RD and DNS-SD have fairly different core = assumptions, and as a consequence, there didn=E2=80=99t seem to be an = obvious mapping. One problem is that DNS-SD has semantics, which Core RD = doesn=E2=80=99t. DNS-SD has a bit of free-form additional data in the = form of the TXT record, but most of the data is structured and is just = about finding a service. Core RD is a lot more general than that. My conclusion, which I think Stuart shared, is that there isn=E2=80=99t = a lot of commonality: it actually seemed to us to make a lot more sense = to use DNS-SD as a way to discover the local Core RD server; this would = for example allow multiple Core RD servers to be advertised in the case = that, as appears to be the case, different application layers require = different versions of Core RD. That said, this is indeed out of scope, but I think it=E2=80=99s an = interesting question that should be explored. > --- Review -04 > Overall: the draft nicely builds on existing/other components in IETF = and SRP looks like a potentially good solution for IoT/constrained = devices. > =20 > Section 2 > "_dnssd-srp._tcp" > "_dnssd-srp-tls._tcp" > -> these should have "_tcp." with a dot before , right?=20 Sure, that makes sense. I think the < confused things a bit. :) =20 > Section 2 text (up to the 2.1 header) could be more clearly split in = the two variants: full-featured host, and constrained host. Initially I = was confused here by the mixture of both, thinking that the constrained = devices also needed to use DHCPv4 Domain Name option or ND DNS Search = List option. > But later it turns out this isn't needed and these MAY use the default = domain only. Creating a new Section 2.1 with two subsections would solve = this e.g. > 2.1 Protocol variants > 2.1.1 Full-featured hosts > 2.1.2 Constrained hosts (or: Constrained nodes) That=E2=80=99s a nice clarification=E2=80=94thanks! > 2.4.1 / 2.4.1.1 > What seems to be missing in these sections is the service=E2=80=99s = host required or recommended behavior, in case the registration fails. = For example if the name is already taken by another device, what would = it do? E.g. define a new name? > (At this point in the draft the reader doesn=E2=80=99t yet know how = the SRP server will compare the to-be-registered name(s) to existing = name(s) in the registry. E.g. is it based on checking Service Instance = Name only? I would expect that described in 2.4.3 somewhere.) Good point. I have added text. > =20 > 2.4.3.1 > Typo: =E2=80=9CInstrructions=E2=80=9D Fixed. > =20 > 2.5 > =E2=80=9CThe TTL should never be longer than the lease time Section = 2.6.1=E2=80=9D > -> typo? Change to e.g. =E2=80=9CThe TTL should never be longer than = the lease time (see Section 2.6.1).=E2=80=9D Fixed > 2.6.1 > =E2=80=9C A default limit of two hours for the Lease and 14 days for = the SIG(0) KEY are currently thought to be good choices.=E2=80=9D > -> this is interesting to compare to the assumptions of CoRE Resource = Directory default lease time, which is 25 hours. > That is quite a large difference. Since both specs target constrained = nodes, I would expect the values to be closer? > Is the 25 hours too long, or the 2 hours too short? I suspect that the CoRE RD lifetime is aimed at sleepy end devices as a = default, where SRP is aimed at powered devices as a default. Since this = is just a default, it makes a lot of sense that a sleepy end device = would negotiate a (possibly much) longer lease. I=E2=80=99ve added some = text pointing out that this is a negotiable time period and specifically = mentioning sleepy devices. =20 > What I do like a lot in this draft is that the SRP server can shorten = or lengthen the lease time, and the client honors this. CoRE RD doesn't = have this feature! > This provides an =E2=80=98out of the box=E2=80=99 standard method for = higher adaptivity to different use cases, if needed. Yup. My DHCP roots showing, perhaps. :) =20 > 2.6.2 Sleep Proxy > This triggers some questions: > It is mentioned that the sleep proxy may be on another link. How would = a SRP server set up a sleep proxy on another link than the one it is = currently attached to? How would it know what link to choose to set it = up? > How would a service=E2=80=99s host know that the server is capable to = do this? If it doesn't know then it cannot trust the mechanism to work = and go to sleep. > Or, is there a way for the SRP server to reject an update with EDNS(0) = OWNER option such that the service=E2=80=99s host knows not to use it = again? > Overall, is sleep proxy support mandatory for the SRP server? This = seems not clear. Remember that SRP is a registration protocol. It is not necessary that = the SRP registration service and the DNS server that is answering = queries be the same server; DNS for example provides the idea of primary = and secondary, where the secondary replicates the primary=E2=80=99s = database. That said, I=E2=80=99m somewhat inclined to say that Sleep = Proxy should be a separate document, because I think this is a lot less = baked than the rest of this document, and I don=E2=80=99t want to delay = this document because of the state of Sleep Proxy. =20 > =E2=80=9CWhen a DNS server receives a DNS Update with an EDNS(0) OWNER = Option, that > signifies that the SRP server should set up a proxy=E2=80=9D > -> is there a difference between DNS server and SRP server? Is it the = same entity here? > We also have =E2=80=9CSRP function=E2=80=9D that a DNS server can = implement. Some clarification of terms could help here! This is a good point. I=E2=80=99ve clarified that at the top of section = 2. =20 > 3.1 > =E2=80=9CFor Anycast updates, this validation must be enforced by = every router=E2=80=9D > -> to clarify this a bit, e.g. "For updates sent to an anycast = destination IP address of an SRP server" > ( Someone might be thinking otherwise about updates to anycast = addresses?) I=E2=80=99ve clarified. > =20 > "DNS-SD registration protocol clients" > -> is this the same as SRP clients? Yes, good catch. > =20 > 3.2 and entire document > The term =E2=80=9CSRP client=E2=80=9D is used, sometimes for the = registering service=E2=80=99s host and sometimes for a client using only = the service lookup function. > Is that correct? Should it be explained in a terminology section? And = we have also above DNS-SD registration protocol client. > Also =E2=80=9CSRP server=E2=80=9D vs =E2=80=9CSRP Server=E2=80=9D are = both used. Fixed the latter. I didn=E2=80=99t find any instances of the = former=E2=80=94can you point me to one in the update? =20 > 3.2 > This says nothing about the SIG(0) validation required by the SRP = server. That seems strange, given the title? > Title could be changed to e.g. =E2=80=9Cvalidating SRP server = responses=E2=80=9D. And perhaps add some SIG(0) validation = considerations by the SRP server, if we have any. (E.g. avoid certain = algorithms? Try only one or try multiple? Maybe the key already encodes = the used algorithm =E2=80=93 I didn=E2=80=99t look into that; in which = case there could be invalid algorithms or parameters specified etc.) It=E2=80=99s pointing out a limitation, so there=E2=80=99s no need to = mention the case where the limitation is not present. =20 > 3.3. > "SRP servers SHOULD implement the algorithms ... starting with = algorithm number 13" > -> is somewhat ambiguous. Can be interpreted in the extreme case as a = server SHOULD implement algorithm 6 , even though RFC 8624 says it MUST = NOT do this. > To be clearer it could be rephrased to=20 > "SRP servers SHOULD implement all algorithms specified in [RFC 8624] = section 3.1 that are numbered 13 or higher and have a "MUST", = "RECOMMENDED", or "MAY" designation in the validation column of the = table." > (The expression =E2=80=9Cstarting with =E2=80=A6 number X=E2=80=9C = feels less familiar to me as a non-native speaker. Is it equal to =E2=80=9C= X and higher numbers=E2=80=9D ? Or do I have to start with X.) Nice. > =20 > 5 > I don't understand the full details of what is requested here =E2=80=93 = but looking on high level it says "there must be a delegation". > For whom is this requirement? Implementers of SRP servers, system = admins, or IANA, ICANN , ... ? > It seems 6.1 already has the IANA part of the requirement. Are there = explicit requirements on others? Good point. I=E2=80=99ve added some clarification. =20 > 6.2 / 6.3 > why no UDP service description? > The constrained devices would use UDP to register and also to query = for services possibly, so I would expect an "_dnssd-srp._udp.." = to be defined at least. > Even if on the constrained network there may be a custom way to = provide the host/port of the SRP server to nodes. After all it *might* = use DNS-SD format to distribute such information, or not? > Another consideration: if UDP is supported, then UDP+DTLS may be too? = Although that would severely increase the resource usage (power, network = bandwidth) of constrained devices perhaps we don=E2=80=99t want to rule = that out. We=E2=80=99re assuming this is discovered using a network-specific = mechanism. =20 > 6.4 > address "TBD1" is not used in the rest of the document. I think there = should be outside section 6 a section that describes the usage of TBD1. > (Can be short) I=E2=80=99ve updated this section because it was actually pretty bad. = However, we haven=E2=80=99t specified a use for the anycast address; the = point of the IANA request is to allocate it so that it can be used in = situations where it is needed. =20 > References > RFC 2136 needs to be a normative reference. Just searching for "2136" = in the text reveals many places where it is pointed to RFC 2136 for = normative operation. > RFC 2931 (SIG(0)) needs to be a normative reference. The SRP server = performs this validation and it is mandatory to perform it. Also = service-publishing clients need to add the signature always. > RFC 7858 is also normative for the same reasons. > [I-D.ietf-dnssd-push] needs to be a normative reference too, as in = Section 2 the full-featured devices are required to use it to "discover = the zone apex of the closest enclosing DNS zone using SOA queries". > replace [I-D.ietf-dnssd-push] -> RFC 8765 > update [I-D.ietf-dnsop-algorithm-update] to RFC 8624 Wow, thanks for going over those. I apologize for not catching these = earlier. > Appendices > An example =E2=80=98service description=E2=80=99 for an IoT device and = its encoding (e.g. size of entire UDP registration message) would be of = interest here. (Not required of course, but nice to have) > This could facilitate some initial comparison against CoRE RD. I don=E2=80=99t see the two protocols as being in competition, so I = think this would be confusing. Unless CoRE RD does something like FCFS = naming, for instance, it would likely be quite a bit more compact. --Apple-Mail=_D269ACFD-3273-460F-8182-55F25AB1655F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Oct 13, 2020, at 9:40 AM, = Esko Dijk <esko.dijk@iotconsultancy.nl> wrote:
I=E2=80=99ve = reviewed recently SRP draft-ietf-dnssd-srp-04 and also CoRE resource = directory (draft-ietf-core-resource-directory, latest Github draft) to = see if these are applicable service discovery solutions for constrained = devices (specifically 6LoWPAN wireless mesh network nodes, that may = operate using the Thread protocol or other). For SRP see the results of = my initial review below; hope this helps in improving the document = further.
 
Both = SRP and RD target similar use cases. It would be interesting to = understand if services registered under one format (e.g. DNS-SD SRP) can = be queried/discovered using another format (e.g. CoRE RD); but that=E2=80=99= s future work for me. (draft-ietf-core-rd-dns-sd already provides a = start for this.)


Stuart and I discussed this = at length with the author of that document. It=E2=80=99s not as simple = as it sounds. First, there are no common set of parameters to publish in = core RD, so any translation would have to be based on heuristics. But = Core RD and DNS-SD have fairly different core assumptions, and as a = consequence, there didn=E2=80=99t seem to be an obvious mapping. One = problem is that DNS-SD has semantics, which Core RD doesn=E2=80=99t. = DNS-SD has a bit of free-form additional data in the form of the TXT = record, but most of the data is structured and is just about finding a = service. Core RD is a lot more general than that.

My conclusion, which I think Stuart shared, is = that there isn=E2=80=99t a lot of commonality: it actually seemed to us = to make a lot more sense to use DNS-SD as a way to discover the local = Core RD server; this would for example allow multiple Core RD servers to = be advertised in the case that, as appears to be the case, different = application layers require different versions of Core RD.

That said, this is indeed out of scope, but I = think it=E2=80=99s an interesting question that should be = explored.

--- Review -04
Overall: the draft nicely builds on = existing/other components in IETF and SRP looks like a potentially good = solution for IoT/constrained devices.
 
Section 2
"_dnssd-srp._tcp<zone>"
"_dnssd-srp-tls._tcp<zone>"
->= these should have "_tcp.<zone>" with a dot before <zone>, = right? 

Sure, = that makes sense. I think the &lt; confused things a bit. = :)
 
Section 2 text (up to the 2.1 header) = could be more clearly split in the two variants: full-featured host, and = constrained host. Initially I was confused here by the mixture of both, = thinking that the constrained devices also needed to use DHCPv4 Domain = Name option or ND DNS Search List option.
But later it turns out this isn't = needed and these MAY use the default domain only. Creating a new Section = 2.1 with two subsections would solve this e.g.
2.1 = Protocol variants
2.1.1 Full-featured hosts
2.1.2 Constrained hosts  (or: = Constrained nodes)

That=E2=80=99s a nice = clarification=E2=80=94thanks!

2.4.1 / 2.4.1.1
What seems to be missing = in these sections is the service=E2=80=99s host required or recommended = behavior, in case the registration fails. For example if the name is = already taken by another device, what would it do? E.g. define a new = name?
(At this point in = the draft the reader doesn=E2=80=99t yet know how the SRP server will = compare the to-be-registered name(s) to existing name(s) in the = registry. E.g. is it based on checking Service Instance Name only? I = would expect that described in 2.4.3 = somewhere.)

Good = point. I have added text.

 
2.4.3.1
Typo: = =E2=80=9CInstrructions=E2=80=9D

Fixed.

 
2.5
=E2=80=9CThe TTL should = never be longer than the lease time Section 2.6.1=E2=80=9D
-> typo? Change to e.g. = =E2=80=9CThe TTL should never be longer than the lease time (see Section = 2.6.1).=E2=80=9D

Fixed

 2.6.1
=E2=80=9C  A = default  limit of two hours for the Lease and 14 days for the = SIG(0) KEY are currently thought to be good choices.=E2=80=9D
-> this is interesting = to compare to the assumptions of CoRE Resource Directory default lease = time, which is 25 hours.
That = is quite a large difference. Since both specs target constrained nodes, = I would expect the values to be closer?
Is the 25 hours too long, or the 2 hours too = short?

I suspect that = the CoRE RD lifetime is aimed at sleepy end devices as a default, where = SRP is aimed at powered devices as a default. Since this is just a = default, it makes a lot of sense that a sleepy end device would = negotiate a (possibly much) longer lease.  I=E2=80=99ve added some = text pointing out that this is a negotiable time period and specifically = mentioning sleepy devices.
 
What I do like a lot in this draft is that the = SRP server can shorten or lengthen the lease time, and the client honors = this. CoRE RD doesn't have this feature!
This provides an =E2=80=98out of the box=E2=80=99 = standard method for higher adaptivity to different use cases, if = needed.

Yup. My DHCP = roots showing, perhaps. :)
 
2.6.2 = Sleep Proxy
This triggers some questions:
  • It is mentioned that the sleep proxy may be on another link. = How would a SRP server set up a sleep proxy on another link than the one = it is currently attached to? How would it know what link to choose to = set it up?
  • How would a service=E2=80=99s host know = that the server is capable to do this? If it doesn't know then it cannot = trust the mechanism to work and go to sleep.
    • Or, is there = a way for the SRP server to reject an update with EDNS(0) OWNER option = such that the service=E2=80=99s host knows not to use it again?
Overall,= is sleep proxy support mandatory for the SRP server? This seems not = clear.

Remember that = SRP is a registration protocol. It is not necessary that the SRP = registration service and the DNS server that is answering queries be the = same server; DNS for example provides the idea of primary and secondary, = where the secondary replicates the primary=E2=80=99s database. That = said, I=E2=80=99m somewhat inclined to say that Sleep Proxy should be a = separate document, because I think this is a lot less baked than the = rest of this document, and I don=E2=80=99t want to delay this document = because of the state of Sleep Proxy.
 
=E2=80=9CWhe= n a DNS server receives a DNS Update with an EDNS(0) OWNER Option, = that
   signifies that the SRP server should set up a = proxy=E2=80=9D
-> is there a difference between DNS server and SRP = server? Is it the same entity here?
We also have =E2=80=9CSRP function=E2=80= =9D that a DNS server can implement. Some clarification of terms could = help here!

This is a = good point. I=E2=80=99ve clarified that at the top of section = 2.
 
3.1
=E2=80=9CFor Anycast updates, this = validation must be enforced by every router=E2=80=9D
 -> = to clarify this a bit, e.g. "For updates sent to an anycast destination = IP address of an SRP server"
( Someone might be thinking = otherwise about updates to anycast = addresses?)

I=E2=80=99ve= clarified.

 
"DNS-SD registration protocol clients"
-> is this the same as = SRP clients?

Yes, good = catch.

 
3.2 and entire = document
The term = =E2=80=9CSRP client=E2=80=9D is used, sometimes for the registering = service=E2=80=99s host and sometimes for a client using only the service = lookup function.
Is that = correct? Should it be explained in a terminology section? And we have = also above DNS-SD registration protocol client.
Also =E2=80=9CSRP = server=E2=80=9D vs =E2=80=9CSRP Server=E2=80=9D are both = used.

Fixed the = latter. I didn=E2=80=99t find any instances of the former=E2=80=94can = you point me to one in the update?
 
3.2
This says = nothing about the SIG(0) validation required by the SRP server. That = seems strange, given the title?
Title could be changed to e.g. = =E2=80=9Cvalidating SRP server responses=E2=80=9D.  And perhaps add = some SIG(0) validation considerations by the SRP server, if we have any. = (E.g. avoid certain algorithms? Try only one or try multiple? Maybe the = key already encodes the used algorithm =E2=80=93 I didn=E2=80=99t look = into that; in which case there could be invalid algorithms or parameters = specified etc.)

It=E2=80= =99s pointing out a limitation, so there=E2=80=99s no need to mention = the case where the limitation is not present.
 
3.3.
"SRP servers SHOULD implement the = algorithms ... starting with algorithm number 13"
-> is = somewhat ambiguous.  Can be interpreted in the extreme case as a = server SHOULD implement algorithm 6 , even though RFC 8624 says it MUST = NOT do this.
To be clearer it could be rephrased to 
"SRP = servers SHOULD implement all algorithms specified in [RFC 8624] section = 3.1 that are numbered 13 or higher and have a "MUST", "RECOMMENDED", or = "MAY" designation in the validation column of the table."
(The expression = =E2=80=9Cstarting with =E2=80=A6 number X=E2=80=9C feels less familiar = to me as a non-native speaker. Is it equal to =E2=80=9CX and higher = numbers=E2=80=9D ? Or do I have to start with = X.)

Nice.

 
5
I don't = understand the full details of what is requested here =E2=80=93 but = looking on high level it says "there must be a delegation".
For whom = is this requirement?  Implementers of SRP servers, system admins, = or IANA, ICANN , ... ?
It seems 6.1 already has the IANA part of the = requirement. Are there explicit requirements on others?

Good = point. I=E2=80=99ve added some clarification.
 
6.2 / 6.3
why no UDP service description?
The constrained devices = would use UDP to register and also to query for services possibly, so I = would expect an "_dnssd-srp._udp.<domain>." to be defined at = least.
Even if on the = constrained network there may be a custom way to provide the host/port = of the SRP server to nodes.  After all it *might* = use DNS-SD format to distribute such information, or not?
Another consideration: if = UDP is supported, then UDP+DTLS may be too?  Although that would = severely increase the resource usage (power, network bandwidth) of = constrained devices perhaps we don=E2=80=99t want to rule that out.

We=E2=80= =99re assuming this is discovered using a network-specific = mechanism.
 
6.4
address = "TBD1" is not used in the rest of the document. I think there should be = outside section 6 a section that describes the usage of TBD1.
(Can be = short)

I=E2=80= =99ve updated this section because it was actually pretty bad. However, = we haven=E2=80=99t specified a use for the anycast address; the point of = the IANA request is to allocate it so that it can be used in situations = where it is needed.
 
References
RFC 2136 = needs to be a normative reference. Just searching for "2136" in the text = reveals many places where it is pointed to RFC 2136 for normative = operation.
RFC 2931 (SIG(0)) needs to be a normative reference.  = The SRP server performs this validation and it is mandatory to perform = it. Also service-publishing clients need to add the signature = always.
RFC 7858 is also normative for the same reasons.
[I-D.ietf-dnssd-push] needs to be a normative reference too, = as in Section 2 the full-featured devices are required to use it to = "discover the zone apex of the closest enclosing DNS zone using SOA = queries".
replace [I-D.ietf-dnssd-push]  -> RFC 8765
update = [I-D.ietf-dnsop-algorithm-update] to RFC = 8624

Wow, thanks for = going over those. I apologize for not catching these = earlier.

Appendices
An example =E2=80=98service = description=E2=80=99 for an IoT device and its encoding (e.g. size of = entire UDP registration message) would be of interest here. (Not = required of course, but nice to have)
This could facilitate some initial comparison = against CoRE RD.

I don=E2=80=99t see the two protocols as being in = competition, so I think this would be confusing. Unless CoRE RD does = something like FCFS naming, for instance, it would likely be quite a bit = more compact.


= --Apple-Mail=_D269ACFD-3273-460F-8182-55F25AB1655F-- From nobody Mon Nov 2 16:17:19 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 70F2A3A0A29 for ; Mon, 2 Nov 2020 16:17:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NO_DNS_FOR_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 7GZWu2lnROri for ; Mon, 2 Nov 2020 16:17:17 -0800 (PST) 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 D2C773A09F0 for ; Mon, 2 Nov 2020 16:17:16 -0800 (PST) Received: by mail-qk1-x729.google.com with SMTP id k9so13259712qki.6 for ; Mon, 02 Nov 2020 16:17:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=zCrl8YmLGtKSDaiBPzlEeJur5QR+5G4hy1MTxGGStk4=; b=pooBZr/eenlqPQaoq2smfqPOvJP2U787G0A4ViSaKnNzdnt/czobyZQT6XcQ8IgbRw T29B9WZQKYQcOnOR/LsKE5yDpPkz/9OhRuYWbZOFQecXK91IOZ1vQ/rFJPcw5s6i6Iye zlC+U5XrGxHmFAAxJGqmpmvA1Fbi1hHG9qOn4ymaInnZ/xck4cjdWrS73yxbmRQZ7gzV 2/RffPo6eOwp014rz2K/IHjSj5Rz9sbNxKfepfVbaIWoaoFxmSrdF4GvSwstJyt7FO+q PjAdJ8FAJEva2p1Ld9TcLi9/mosCQpFX6hvq1ouXoAKbnHLD/toqmLf6NOIhkzBuDdcT TU2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=zCrl8YmLGtKSDaiBPzlEeJur5QR+5G4hy1MTxGGStk4=; b=JjvidTru3S8nWcY+2iIFttUGLoh9CPd/a/OOkCW9TJYRTKsWlD2mf+ganmrc8S/xrH js69oIzAYFT9vRoBAXXAJrQ9CPCCisnH2NIEgm/U0B0/7gyPJJZnXA+8M8MrL/0aSeaJ sQV/rAQ4Xr+0R482EgTqm2IOHOQuCt4GtTuBPbinniy/xO9+w/UPjVYm5Sa3l9XjBpD+ 2YxYNMWYvcgCO4vicxxA02MOJ2cXPDVhNp+EFDr05tVPMXMrLDClNR0pp3R5O4Jhbusw fsFj9JKK+T7vGjxErv6mWmafFPZo83wTAqwjHCxBAHe+4oBkmuN2MRiD9VvELCFr51sC 4N/A== X-Gm-Message-State: AOAM530wj7bR80UcQxKCPLeJ46L3snrsyeXCtkprj8sclOc5PvhbM9aj 7GyKWV6Jp1ZoWg0Imo1dLwsBEw== X-Google-Smtp-Source: ABdhPJyS1GuBv1ufnTEDvg7qyAvCAnkrCIYbCha/K67XQwQhj8KfhQ1MrQoIvKnex58f26ssV4w9jw== X-Received: by 2002:a37:58c1:: with SMTP id m184mr17175924qkb.305.1604362635451; Mon, 02 Nov 2020 16:17:15 -0800 (PST) Received: from mithrandir.lan (c-24-91-177-160.hsd1.nh.comcast.net. [24.91.177.160]) by smtp.gmail.com with ESMTPSA id a21sm9077530qkk.98.2020.11.02.16.17.14 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Nov 2020 16:17:14 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.20.0.2.11\)) From: Ted Lemon In-Reply-To: Date: Mon, 2 Nov 2020 19:17:14 -0500 Cc: "dnssd@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Esko Dijk X-Mailer: Apple Mail (2.3654.20.0.2.11) Archived-At: Subject: Re: [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, 03 Nov 2020 00:17:18 -0000 Oh, two things I forgot to say in the reply. First, thanks very much for = the thorough and thoughtful review. It is much appreciated. Secondly, I am afraid that I left it too late and missed the posting = deadline. Not sure what to do about that in the short term, but I will = upload it as soon as I can. From nobody Tue Nov 3 03:32: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 DC6CF3A0317 for ; Tue, 3 Nov 2020 03:32:46 -0800 (PST) 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 arZv4DIrqlTJ for ; Tue, 3 Nov 2020 03:32:43 -0800 (PST) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2096.outbound.protection.outlook.com [40.107.20.96]) (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 29B393A02C1 for ; Tue, 3 Nov 2020 03:32:42 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BhPeAcEvY2xsAkwMzfK1dtCHSVDxo4vPAwPbcT6KjAbn5yRDJTU4rHZ1dYS8wpfMvyzp+iJYFhAhiXiicUAQsrY05Wlz+/1OZXolWRUOHsT4i90IsQy6P7vVodVs/BGZ40XqFrdGln+UQ81V9m4T5PV2LEyns+qDLOFRisL/Uhpl8jrwpS0YPUaaA/frzxI610k3Uev/zBRXUGXdwlhpNKr0slAiWSh5LCfGBQv4fkZrNFU13JLxmAgShTAKwaflLRHCulhkJskx4Jcl2kxp8pdqy/PCemrOU05CEIzX1TxYbza9kUwdCj/7FOlcpuOE0P1csvcLLZ/KiyF5tUwvCw== 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=oRHAosUmsyQaL4DfFJt+Cn+kiwNQu8siAN+M0JveO+M=; b=ZUowKNd1Nkb7KoNsxGCSbgKAwORVF4lXuWZh49pRaOlrOLokjBOFPRhYRkHn4eF+jIaara0GM0l9C92tMpndXGnVg7374m67P7nm0E5ekr55+Fr+LwHLBS0+GEqJACvyvWgPAYznAH0Yr5AMv4Gu1K5FokJU/YhisuIjY43QAaqtsKxRUuHFTj2K7Gpj9HOt8b/b0lC+sZDEW+ZQPSHizInlmleS9pjzNP1hA43cXX2JweuNh6W8Eg+BbV5CcjWuABuk2/7MwXojQ0bG8WVFbPymkLhsqoM6H4I4ZNJspPKojBJfGjpKQWStrquPnvb7hknCJVs1XMPMkdYyeIvmnw== 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=oRHAosUmsyQaL4DfFJt+Cn+kiwNQu8siAN+M0JveO+M=; b=VBy3XRv+7AisjxojJe/GFpCMxaeb2cHQRAJlO353PGjB62cJ7mDAEIVK0njGrd/vsoxlarNutavGosKxUTW3qNDmGb9QByk8aDuuj+erwTH8UZgfV281ouDQctWJbE9ms/ZDK0XSUfYOXQNUkbXnDb0p1jAH58zXH/nixp1XPbU= Received: from AM8P190MB0979.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:1d3::8) by AM9P190MB1236.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:260::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3499.18; Tue, 3 Nov 2020 11:32: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.3499.032; Tue, 3 Nov 2020 11:32:40 +0000 From: Esko Dijk To: Ted Lemon CC: DNSSD Thread-Topic: [dnssd] Review of draft-ietf-dnssd-srp-04; and relation to CoRE Resource Directory Thread-Index: AdahZCdWnFqFugrYTgawM9Kzp4FPCAQEmYGAABAPmvA= Date: Tue, 3 Nov 2020 11:32:39 +0000 Message-ID: References: <5205F6F9-50B1-4785-A311-880B1FD0AC30@fugue.com> In-Reply-To: <5205F6F9-50B1-4785-A311-880B1FD0AC30@fugue.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: fugue.com; dkim=none (message not signed) header.d=none;fugue.com; dmarc=none action=none header.from=iotconsultancy.nl; x-originating-ip: [2001:1c02:3103:f000:2d67:acc9:5b43:df37] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 35b59962-72db-4c90-7022-08d87fec2c0a x-ms-traffictypediagnostic: AM9P190MB1236: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 7gGhYrXfHzyp0W4djM1xZ0ZbYnO5KnK91ReNky7pMVYWHVRXdpQCwvwPkrsUBe22Q6DntNr6ZCgMxcqZdgMDFs+pM6PhUmnkSjHBVXlntpWZCs+oKIHbqkKDfRJxNQdUEF5U1Xv+mkwpLXk+q1Zave/eRlr3A8F2j7dePCCBrsynTT7YC5hCv/4qT/OynUOqkwhIpxxHJyy2LLYiNtxm659uZCIWfrCmq+/QCwSzJ9VnpN1IStux1CzcbyHH6FdEsbYMbnqSJ/2yQ+KrNyg/FZKfYwwxj1kig6DTnbLZO2vUfwaLHKnzb3AkQ3aUVKTv 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)(396003)(366004)(346002)(136003)(9686003)(5660300002)(66476007)(76116006)(7696005)(33656002)(66446008)(66556008)(64756008)(52536014)(71200400001)(66946007)(6916009)(4326008)(9326002)(44832011)(8676002)(83380400001)(86362001)(186003)(316002)(478600001)(8936002)(55016002)(2906002)(6506007); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: G6b3v/uZ3XEZG++SJvxYKkDWxt/w9z3eDPlAKz8Pf0qQfFEHISTypWBEjZ9Kz6J+C9kGp/zX1qEIVvuGnBZts7UvJntKyu6glU0P5+HeH51tYFfTefPogTqa5LqHcS6wpCDLvHOez/fAkmoQO7fWwGlatJY8egx4tZheKC7FnzUz9YXptZmt6YoQSgpemCpNbSlidvXHJSTs0Dq4r6D69M21Vww4ZY+1iHrruH8m0zr2FRMEW9dUTf1pr/0vwusY6cUPrre4e1HP8CCjt5SM7ApaXh/HmVmAnJnZDOKOZciiUz7AkGMDvCNXJslMyDNpqOEFUIax2MWvlBLG/eudf24TkiwcWYF928fZxuP87rux1eRj0lfu1o7mBHuWHKoLlkzkwEZ5V8q+h1as6wMtJNCMJTUfw+CqWfMQhKf8NgNPdLflRF8KYrqvySfiUBItKuxeJF8VnxNf0r/IfWNNzY0tQWNqWQUQNPj166h1MDcmLQx3xNe81V1tQQox3Y8EFBHSlqRwUcmal+r6SYMmhsJRtIi+nvHXWF3r/lxmx6bZ2Qa8Ir3dRiNO5hYHtohmL60rYEYdg9qkG9yVuUoMmHwjzWg/6hm9tVZ7lfi5ycnu8+qhLFU6whwhzN0Y/57E+ZUpNfuYK2ZcU8VkIxui+2c6ShkbYoTDnIH1ugcYIT6GOEMHLqMJROsCx41DdMj/dvPc8wvw/t0mJI+ewfz74w== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_AM8P190MB09794FA65E2295764589AAE4FD110AM8P190MB0979EURP_" 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: 35b59962-72db-4c90-7022-08d87fec2c0a X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Nov 2020 11:32:39.9342 (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: lk1c6fynA/IAkxJx+MgoFic9GqgErSW5xTWwjwu8cIDEc8FukdoAt344dxHpW1IIfgHbvPe0J18kNNncWZwHkX4W7dpYiWiGtHDHW+byHpM= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9P190MB1236 Archived-At: Subject: Re: [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, 03 Nov 2020 11:32:47 -0000 --_000_AM8P190MB09794FA65E2295764589AAE4FD110AM8P190MB0979EURP_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gVGVkLA0KDQpMb29raW5nIGZvcndhcmQgdG8gdGhlIHVwZGF0ZWQgdmVyc2lvbiDigJMg SSB3aWxsIHJldmlldyB0aGUgY2hhbmdlcyBzb21lIHRpbWUgYWZ0ZXIgeW91IGhhdmUgcG9zdGVk IGl0LiBBbmQgYmVsb3cgZnVydGhlciByZXNwb25zZXMgdG8geW91ciByZXBseToNCg0KPiBTdHVh cnQgYW5kIEkgZGlzY3Vzc2VkIHRoaXMgYXQgbGVuZ3RoIHdpdGggdGhlIGF1dGhvciBvZiB0aGF0 IGRvY3VtZW50LiBJdOKAmXMgbm90IGFzIHNpbXBsZSBhcyBpdCBzb3VuZHMuIEZpcnN0LCB0aGVy ZSBhcmUgbm8gY29tbW9uIHNldCBvZiBwYXJhbWV0ZXJzIHRvIHB1Ymxpc2ggaW4gY29yZSBSRCwg c28gYW55IHRyYW5zbGF0aW9uIHdvdWxkIGhhdmUgdG8gYmUgYmFzZWQgb24gaGV1cmlzdGljcy4N CiA+IEJ1dCBDb3JlIFJEIGFuZCBETlMtU0QgaGF2ZSBmYWlybHkgZGlmZmVyZW50IGNvcmUgYXNz dW1wdGlvbnMsIGFuZCBhcyBhIGNvbnNlcXVlbmNlLCB0aGVyZSBkaWRu4oCZdCBzZWVtIHRvIGJl IGFuIG9idmlvdXMgbWFwcGluZy4NCg0KWWVzIEkgcmVjYWxsIGZyb20gb25lIG9mIHRoZSBhdXRo b3JzIHRoYXQgZG9pbmcgdGhpcyBtYXBwaW5nIGlzIGhhcmQsIGlmIG5vdCBpbXBvc3NpYmxlLiBJ biBteSB2aWV3IGl0IG1pZ2h0IHN0aWxsIHdvcmsgaWYgd2UgYXNzdW1lIGEgbGltaXRlZCBzdWJz ZXQgb2YgRE5TLVNEIHNlbWFudGljcyB0aGF0IGNhbiBiZSBtYXBwZWQgdG8gYSBsaW1pdGVkIHN1 YnNldCBvZiBDb1JFLVJEIHNlbWFudGljcywgYW5kIHZpY2UgdmVyc2EuICAoVW5kZXIgdGhlIGFz c3VtcHRpb24gdGhhdCB0aGlzIHN0aWxsIHdvdWxkIGJlIHJlbGV2YW50IGZvciB0aGUgYXBwbGlj YXRpb25zL3N5c3RlbXMgdGhhdCB3b3VsZCB1c2UgZWl0aGVyIEROUy1TRCBvciBDb1JFIGZvciB0 aGVpciBpbml0aWFsLCBiYXNpYyBzZXJ2aWNlIGRpc2NvdmVyeeKApikgICBBcyBhbiBleGFtcGxl IG9mIGEgc3Vic2V0LCB0aGUgQ29SRSBSRCBkcmFmdCBzaW5jZSAtMTQgZGVmaW5lcyBhIHN1YnNl dCBvZiB0aGUgQ29SRSBMaW5rIEZvcm1hdCB0aGF0IGl0IGFpbXMgdG8gc3VwcG9ydCwgZ2l2ZW4g dGhhdCB0aGUgZnVsbCBmb3JtYXQgd2FzIHRvbyBjb21wbGV4IGZvciBkZXZlbG9wZXJzIHRvIGdl dCBpdCByaWdodCBhbmQgZXZlbiB3YXMgaGFyZCBmb3IgdGhlIGV4cGVydHMgdG8gYWdyZWUgb24g aW50ZXJwcmV0YXRpb24uIFNvIGRvaW5nIHNvbWUgdW5kZXJzdGFuZGFibGUgc3Vic2V0cyBtYXkg YmUgdGhlIG9ubHkgd2F5IOKAkyBvciBnaXZlIHVwIG9uIHRoZSBpZGVhLiAgSW4gdGhlIFJEIGNh c2UgdGhlIGZ1bGwgTGluayBGb3JtYXQgY2FuIHN0aWxsIGJlIHVzZWQgYnV0IGxlYWRzIHRvIGlt cGxlbWVudGF0aW9uLXNwZWNpZmljIGJlaGF2aW9yIG9mIHRoZSBSRCBpbiBjYXNlIHN0YXRlbWVu dHMgYXJlIHVzZWQgdGhhdCBnbyBiZXlvbmQgdGhlIHN1YnNldC4NCg0KPiBPbmUgcHJvYmxlbSBp cyB0aGF0IEROUy1TRCBoYXMgc2VtYW50aWNzLCB3aGljaCBDb3JlIFJEIGRvZXNu4oCZdC4gRE5T LVNEIGhhcyBhIGJpdCBvZiBmcmVlLWZvcm0gYWRkaXRpb25hbCBkYXRhIGluIHRoZSBmb3JtIG9m IHRoZSBUWFQgcmVjb3JkLCBidXQgbW9zdCBvZiB0aGUgZGF0YSBpcyBzdHJ1Y3R1cmVkIGFuZCBp cyBqdXN0IGFib3V0IGZpbmRpbmcgYSBzZXJ2aWNlLiBDb3JlIFJEIGlzIGEgbG90IG1vcmUgZ2Vu ZXJhbCB0aGFuIHRoYXQuDQoNClRydWU7IGl0IHdvdWxkIGJlIGludGVyZXN0aW5nIGZvciBtZSB0 byBsZWFybiB0aGVzZSBzZW1hbnRpY3MgYW5kIHNlZSBob3cgdGhleSBjb3VsZCBtYXAgdG8gQ29S RSBMaW5rIEZvcm1hdC4gQmVjYXVzZSBMaW5rIEZvcm1hdCBpcyBleHRlbmRpYmxlIChSRkMgNjY5 MCAsIGluaGVyaXRzIFdlYiBMaW5raW5nIFJGQyA1OTg4LCB3aGljaCBpbmhlcml0cyBSREYsIHNv IG5ldyByZWxhdGlvbiB0eXBlcyB3aXRoIHNwZWNpZmljIHNlbWFudGljcyBjYW4gYmUgZnJlZWx5 IGRlZmluZWQuICkgdGhpcyBjYW4gYmUgZGVmaW5lZC4NClZpY2UgdmVyc2Egc29tZSBDb1JFIExp bmsgRm9ybWF0IHNlbWFudGljcyB3b3VsZCBuZWVkIHRvIGJlIHJlbW92ZWQgaW4gdGhlIHRyYW5z bGF0aW9uIHRvIEROUy1TRCBwcm9iYWJseSwgYnV0IHRoZSBiYXNpYyBzZXJ2aWNlIGRpc2NvdmVy eSBhc3BlY3QgKGluIExpbmsgRm9ybWF0IHRoaXMgaXMgdGhlIOKAnGhvc3Rz4oCdIHJlbGF0aW9u IHR5cGUpIGNvdWxkIGJlIGF0IGxlYXN0IGF0dGVtcHRlZC4NCg0KPiBJIHN1c3BlY3QgdGhhdCB0 aGUgQ29SRSBSRCBsaWZldGltZSBpcyBhaW1lZCBhdCBzbGVlcHkgZW5kIGRldmljZXMgYXMgYSBk ZWZhdWx0LCB3aGVyZSBTUlAgaXMgYWltZWQgYXQgcG93ZXJlZCBkZXZpY2VzIGFzIGEgZGVmYXVs dC4NCg0KQWdyZWUsIENvUkUgdGFyZ2V0cyBjb25zdHJhaW5lZCBkZXZpY2VzIGluY2x1ZGluZyBz bGVlcHkgZGV2aWNlcyDigJMgYW5kIHByb2JhYmx5IGxlc3MgZHluYW1pY3MgZS5nLiBhIHNlbnNv ciB0aGF0IGp1c3Qgc2l0cyBhdCBvbmUgbG9jYXRpb24gMjQvNyBhbmQgd2FrZXMgdXAgb25jZSBp biBhIHdoaWxlLg0KDQo+ICA+IFRoZSB0ZXJtIOKAnFNSUCBjbGllbnTigJ0gaXMgdXNlZCwgc29t ZXRpbWVzIGZvciB0aGUgcmVnaXN0ZXJpbmcgc2VydmljZeKAmXMgaG9zdCBhbmQgc29tZXRpbWVz IGZvciBhIGNsaWVudCB1c2luZyBvbmx5IHRoZSBzZXJ2aWNlIGxvb2t1cCBmdW5jdGlvbi4NCj4g PiBJcyB0aGF0IGNvcnJlY3Q/IFNob3VsZCBpdCBiZSBleHBsYWluZWQgaW4gYSB0ZXJtaW5vbG9n eSBzZWN0aW9uPyBBbmQgd2UgaGF2ZSBhbHNvIGFib3ZlIEROUy1TRCByZWdpc3RyYXRpb24gcHJv dG9jb2wgY2xpZW50Lg0KPiA+IEFsc28g4oCcU1JQIHNlcnZlcuKAnSB2cyDigJxTUlAgU2VydmVy 4oCdIGFyZSBib3RoIHVzZWQuDQo+DQo+IEZpeGVkIHRoZSBsYXR0ZXIuIEkgZGlkbuKAmXQgZmlu ZCBhbnkgaW5zdGFuY2VzIG9mIHRoZSBmb3JtZXLigJRjYW4geW91IHBvaW50IG1lIHRvIG9uZSBp biB0aGUgdXBkYXRlPw0KDQpMb29raW5nIGF0IHRoZSB0ZXh0ICgtMDUpIGFnYWluLCBJIHNlZSB0 aGF0IOKAmGNsaWVudOKAmSwg4oCYU1JQIGNsaWVudOKAmSBhbmQg4oCYRE5TLVNEIHJlZ2lzdHJh dGlvbiBwcm90b2NvbCBjbGllbnTigJkgYXJlIHVzZWQgZm9yIG1vc3RseSB0aGUgc2FtZSBjb25j ZXB0IOKAkyB0aGUgU1JQIGNsaWVudCBwdWJsaXNoaW5nIHRoZSBzZXJ2aWNlLiBUaGUgbG9va3Vw IGFzcGVjdCBvbmx5IGFwcGVhcnMgaW4gU2VjdGlvbiAxIHRleHQNCuKAnE9uY2UgcHVibGlzaGVk LCB0aGVzZSBzZXJ2aWNlcyBjYW4gYmUgcmVhZGlseSBkaXNjb3ZlcmVkIGJ5IGNsaWVudHMgdXNp bmcgc3RhbmRhcmQgRE5TIGxvb2t1cHPigJ0gLiBIZXJlIGl0IGlzIGNsZWFyIHRoYXQgdGhlIGNs aWVudCBpcyBhcyBhIHN0YW5kYXJkIEROUyBjbGllbnQgd2hlbiBkb2luZyB0aGlzIHNvIG5vIGFt YmlndWl0eS4NCkluIFNlY3Rpb24gMy4yIEkgd2FzIHRoaW5raW5nIHRoYXQgdGhlIOKAmGNsaWVu dOKAmSBoZXJlIGdldHRpbmcgdGhlIHJlc3BvbnNlIGZyb20gdGhlIOKAmEROUyBzZXJ2ZXLigJkg bXVzdCBiZSBhIEROUyBjbGllbnQgYmVjYXVzZSBpdCBkaWQgbm90IHNheSDigJhTUlAgc2VydmVy 4oCZIGhlcmUuIFdlIGNvdWxkIGNoYW5nZSBoZXJlIOKAmEROUyBzZXJ2ZXJz4oCZIHRvIOKAmFNS UCBzZXJ2ZXJz4oCZIGp1c3QgdG8gYmUgY2xlYXIuDQooQmVjYXVzZSB0aGUgbG9va3VwIGZ1bmN0 aW9uIGlzIG5vdCBkZXNjcmliZWQgaW4gdGhpcyBkcmFmdCBidXQgaW4gb3RoZXIgUkZDcyDigJMg c3RhbmRhcmQgRE5TLVNEIG9yIG1ETlMgcXVlcmllcyBldGMg4oCTIHRoZSBwb3NzaWJpbGl0eSBv ZiBjb25mdXNpb24gaXMgY3VycmVudGx5IG1pbmltYWwgdGhvdWdoLikNCg0KPiA+IDMuMiBUaGlz IHNheXMgbm90aGluZyBhYm91dCB0aGUgU0lHKDApIHZhbGlkYXRpb24gcmVxdWlyZWQgYnkgdGhl IFNSUCBzZXJ2ZXIuIFRoYXQgc2VlbXMgc3RyYW5nZSwgZ2l2ZW4gdGhlIHRpdGxlPw0KPiA+IFRp dGxlIGNvdWxkIGJlIGNoYW5nZWQgdG8gZS5nLiDigJx2YWxpZGF0aW5nIFNSUCBzZXJ2ZXIgcmVz cG9uc2Vz4oCdLiAgQW5kIHBlcmhhcHMgYWRkIHNvbWUgU0lHKDApIHZhbGlkYXRpb24gY29uc2lk ZXJhdGlvbnMgYnkgdGhlIFNSUCBzZXJ2ZXIsIGlmIHdlIGhhdmUgYW55LiAoRS5nLiBhdm9pZCBj ZXJ0YWluIGFsZ29yaXRobXM/DQogPiA+IFRyeSBvbmx5IG9uZSBvciB0cnkgbXVsdGlwbGU/IE1h eWJlIHRoZSBrZXkgYWxyZWFkeSBlbmNvZGVzIHRoZSB1c2VkIGFsZ29yaXRobSDigJMgSSBkaWRu 4oCZdCBsb29rIGludG8gdGhhdDsgaW4gd2hpY2ggY2FzZSB0aGVyZSBjb3VsZCBiZSBpbnZhbGlk IGFsZ29yaXRobXMgb3IgIHBhcmFtZXRlcnMgc3BlY2lmaWVkIGV0Yy4pDQo+DQo+IEl04oCZcyBw b2ludGluZyBvdXQgYSBsaW1pdGF0aW9uLCBzbyB0aGVyZeKAmXMgbm8gbmVlZCB0byBtZW50aW9u IHRoZSBjYXNlIHdoZXJlIHRoZSBsaW1pdGF0aW9uIGlzIG5vdCBwcmVzZW50Lg0KDQpXaGF0IGFi b3V0IGNoYW5naW5nIHRoZSB0aXRsZSBmb3IgdGhpcyBzZWN0aW9uIDMuMiB0byDigJxTUlAgU2Vy dmVyIFJlc3BvbnNlIFZhbGlkYXRpb27igJ0gPyAgVGhhdCB3b3VsZCBmaXQgdGhlIGN1cnJlbnQg dGV4dCBiZXN0Lg0KRm9yZ2V0IHdoYXQgSSBzYWlkIGFib3V0IHRoZSBzZWxlY3Rpb24gb2YgU0lH KDApIGFsZ29yaXRobXMgYmVjYXVzZSB0aGF04oCZcyBhbHJlYWR5IGluIDMuMyBJIHNlZS4NCg0K PiA+IFRoZSBjb25zdHJhaW5lZCBkZXZpY2VzIHdvdWxkIHVzZSBVRFAgdG8gcmVnaXN0ZXIgYW5k IGFsc28gdG8gcXVlcnkgZm9yIHNlcnZpY2VzIHBvc3NpYmx5LCBzbyBJIHdvdWxkIGV4cGVjdCBh biAiX2Ruc3NkLXNycC5fdWRwLjxkb21haW4+LiIgdG8gYmUgZGVmaW5lZCBhdCBsZWFzdC4NCj4g PiBFdmVuIGlmIG9uIHRoZSBjb25zdHJhaW5lZCBuZXR3b3JrIHRoZXJlIG1heSBiZSBhIGN1c3Rv bSB3YXkgdG8gcHJvdmlkZSB0aGUgaG9zdC9wb3J0IG9mIHRoZSBTUlAgc2VydmVyIHRvIG5vZGVz LiAgQWZ0ZXIgYWxsIGl0ICptaWdodCogdXNlIEROUy1TRCBmb3JtYXQgdG8gZGlzdHJpYnV0ZSBz dWNoIGluZm9ybWF0aW9uLCBvciBub3Q/DQo+ID4gQW5vdGhlciBjb25zaWRlcmF0aW9uOiBpZiBV RFAgaXMgc3VwcG9ydGVkLCB0aGVuIFVEUCtEVExTIG1heSBiZSB0b28/ICBBbHRob3VnaCB0aGF0 IHdvdWxkIHNldmVyZWx5IGluY3JlYXNlIHRoZSByZXNvdXJjZSB1c2FnZSAocG93ZXIsIG5ldHdv cmsgYmFuZHdpZHRoKSBvZiBjb25zdHJhaW5lZCBkZXZpY2VzIHBlcmhhcHMgd2UgZG9u4oCZdCB3 YW50IHRvIHJ1bGUgdGhhdCBvdXQuDQo+DQo+IFdl4oCZcmUgYXNzdW1pbmcgdGhpcyBpcyBkaXNj b3ZlcmVkIHVzaW5nIGEgbmV0d29yay1zcGVjaWZpYyBtZWNoYW5pc20uDQoNCkFncmVlOyBpdCB3 aWxsIGJlIG5ldHdvcmstc3BlY2lmaWMgYW5kIGl0IG1heSBub3QgaW52b2x2ZSBhIEROUy1TRCBk ZXNjcmlwdGlvbiBhdCBhbGwuIEUuZy4ganVzdCBhbiBJUCBhZGRyZXNzIGFuZCBhIHBvcnQgY29u ZmlndXJhdGlvbi4gU29tZSBvZiB0aGVzZSBuZXR3b3JrLXNwZWNpZmljIG1lYW5zIG1heSBpbiB0 aGUgZnV0dXJlIHVzZSBETlMtU0QgZGVzY3JpcHRpb25zIHRvIHB1Ymxpc2ggLyDigJhwdXNo4oCZ IGF2YWlsYWJsZSBuZXR3b3JrIHNlcnZpY2VzIHRvIGNsaWVudHMuDQpBbmQgb25lIG9mIHRoZXNl IHNlcnZpY2VzIG1heSBiZSBhIFVEUC1iYXNlZCBTUlAgc2VydmVyIHdoZXJlIHRoZSBjbGllbnQg Y2FuIHRoZW4gY2hvb3NlIHRvIHJlZ2lzdGVyLiBUaGVuIHRoaXMgZGVzY3JpcHRpb24gd291bGQg dXNlICJfZG5zc2Qtc3JwLl91ZHAuPGRvbWFpbj4uIiAgLCBob3dldmVyIHRoaXMgaXMgbm90IGZv cm1hbGx5IGRlZmluZWQgaW4gdGhlIElBTkEgU2VydmljZSBOYW1lcyByZWdpc3RyeSBzbyB0aGUg cGVvcGxlIGRvaW5nIHRoaXMNCndvdWxkIGhhdmUgdG8gcmVnaXN0ZXIgdGhhdCBlbnRyeS4gIFRo YXQgaXMgc3RpbGwgb2theSwgdGhvdWdoIEkgY29uc2lkZXJlZCBpdCBiZXR0ZXIgaWYgdGhlIHBy ZXNlbnQgZHJhZnQgd291bGQgYWxyZWFkeSBmb3JtYWxseSByZXNlcnZlIHRoZSBzZXJ2aWNlIG5h bWUgIl9kbnNzZC1zcnAuX3VkcC48ZG9tYWluPi4iIGZvciB0aGlzIHB1cnBvc2UganVzdCB0byBi ZSBjb21wbGV0ZS4NCg0KQW5vdGhlciBhcmd1bWVudCB3aHkgdGhpcyBpcyBuZWVkZWQgaXMgdGhl IGZvbGxvd2luZzogdGhlIHByZXNlbnQgZHJhZnQgc2F5cyBSRkMgMjEzNiBpcyB0aGUgd2F5IGZv ciB0aGUgY2xpZW50IHRvIHNlbmQgaXRzIEROUyB1cGRhdGVzIHRvIHRoZSBTUlAgc2VydmVyLiBB bmQgdGhhdCBkZWZpbmVzIGJvdGggVURQIGFuZCBUQ1AuIElmIHdlIHdhbnQgdG8gbnVkZ2UgcGVv cGxlIHRvd2FyZHMgdXNpbmcgVENQIGFuZCBub3QgVURQIHdoZXJlIHBvc3NpYmxlLCB0aGVuDQp0 aGlzIHNob3VsZCBiZSBtYWRlIGV4cGxpY2l0IEkgdGhpbmsgaW4gU2VjdGlvbiAyLjMuMSDigJMg YWRkIGEgYnVsbGV0IOKAnENsaWVudHMgU0hPVUxEL01VU1QgdXNlIFRDUOKAnS4gIElmIFVEUCBh bmQgVENQIGFyZSB0cmVhdGVkIGFzIGVxdWFscyBhcyBpbiBSRkMgMjEzNiB0aGVuIEkgd291bGQg YXNzdW1lIGJvdGggbmVlZCB0byBiZSBzdXBwb3J0ZWQgYXMgd2VsbCBmb3IgdGhlIFNSUCBzZXJ2 ZXIsIHBvdGVudGlhbGx5Lg0KU28gaXMgaXQgaW50ZW5kZWQgdGhhdCB0aGUgbm9uLWNvbnN0cmFp bmVkIGNsaWVudHMgY2FuIG9ubHkgZGlzY292ZXIgdGhlIFRDUC1iYXNlZCBTUlAgc2VydmVyLCBh bmQgbm90IHRoZSBVRFAtYmFzZWQgU1JQIHNlcnZlcj8gSWYgc28gdGhlbiBvbmx5IGRlZmluaW5n IHRoZSBUQ1AtYmFzZWQgc2VydmljZSBkZXNjcmlwdGlvbiBpcyBlbm91Z2guDQpOb3RlOiBJ4oCZ bSBhc3N1bWluZyBpbiB0aGUgYWJvdmUgdGhhdCBUQ1AvVURQIGJhc2VkIHNlcnZpY2VzIG9mIFNS UCBzZXJ2ZXIgYXJlIHNlcGFyYXRlbHkgYWR2ZXJ0aXNlZCBpbiBETlMtU0QgaWYgYm90aCBhcmUg cHJlc2VudCwgYnV0IEkgbWF5IGJlIHRvdGFsbHkgd3JvbmcgaGVyZS4gSWYgSeKAmW0gd3Jvbmcg dGhlbiBwbGVhc2UgaWdub3JlIHRoaXMgYXJndW1lbnQuDQoNCj4gVW5sZXNzIENvUkUgUkQgZG9l cyBzb21ldGhpbmcgbGlrZSBGQ0ZTIG5hbWluZywgZm9yIGluc3RhbmNlLCBpdCB3b3VsZCBsaWtl bHkgYmUgcXVpdGUgYSBiaXQgbW9yZSBjb21wYWN0Lg0KDQpSRCBkb2VzIGhhdmUgRkNGUyBuYW1p bmcgYnV0IOKAkyBiZWNhdXNlIHRoZXJlIGlzIG5vIGRlZmF1bHQgc2VjdXJpdHkgc29sdXRpb24g 4oCTIGl0IGlzIHJhdGhlciBpbmRpcmVjdGx5IGRlZmluZWQuICBSRCBkcmFmdCBzYXlzIHRoYXQg cmVnaXN0ZXJpbmcgY2xpZW50cyBNVVNUIHVzZSB1bmlxdWUgbmFtZXMgYW5kIHBvaW50cyB0byBz b21lIG1lY2hhbmlzbXMgZm9yIGNsaWVudHMgdG8gZ2VuZXJhdGUgcmFuZG9tIFVVSUQgbmFtZXMg aW4gY2FzZSB0aGVyZSBmaXJzdCBhdHRlbXB0IGF0IHJlZ2lzdHJhdGlvbiB3aXRoIGEgbmFtZSBm YWlsZWQuDQpUaGUgY2FzZSB3aGVyZSBubyBzZWN1cml0eSBpcyB1c2VkIGJlY29tZXMgYWxzbyB0 cmlja3kgdGhlbjsgYXMgdGhlIFJEIHNlcnZlciBtYXkgYmUgdW5hYmxlIHRvIGRpc3Rpbmd1aXNo IGEgbmFtZS1jb2xsaXNpb24gZnJvbSBhIGxlZ2l0aW1hdGUgY2xpZW50IG1ha2luZyBhIHNlcnZp Y2UgdXBkYXRlLiBUaGUgZXhwZWN0YXRpb24gdGhlcmUgaXMgdGhhdCBjbGllbnRzIHdpbGwgY2hv b3NlIHJhbmRvbSAvIFVVSUQgbmFtZXMgaW4gdGhhdCBjYXNlIHRvIHB1c2ggdGhlIHByb2JhYmls aXR5IG9mIGNvbGxpc2lvbiB0byAwJS4gKERvZXNu4oCZdCB3b3JrIGFnYWluc3QgYXR0YWNrZXJz LikNCkFuZCBSROKAmXMgTGluayBGb3JtYXQgY2FuIGluIHNvbWUgY2FzZXMgYmUgcmF0aGVyIGlu ZWZmaWNpZW50IOKAkyB0aGVyZeKAmXMgbm93IGFuIGVmZm9ydCB0byBkZWZpbmUgYSBuZXcgYmlu YXJ5IGZvcm1hdCBDb1JBTCB0aGF0IGNvdWxkIHJlcGxhY2UgaXQuICBBbiBSRCBjb3VsZCBoYW5k bGUgYm90aCBMaW5rIEZvcm1hdCBhbmQgQ29SQUwgaW4gcHJpbmNpcGxlLg0KDQpFc2tvDQoNCg== --_000_AM8P190MB09794FA65E2295764589AAE4FD110AM8P190MB0979EURP_ 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 bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtz aXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2 LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25z ICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDo2MDUxNjE2MTM7DQoJbXNvLWxpc3QtdGVtcGxh dGUtaWRzOjIxNDMwNzkzOTg7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9w Oi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9 DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1m b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDMN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0K CWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJv bDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5z aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZl bDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C tzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5 bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28t YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDps ZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1 bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwv eG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQg djpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hh cGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIg bGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSIgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3JkIj4N CjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IZWxsbyBU ZWQsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkxvb2tpbmcgZm9yd2FyZCB0byB0aGUgdXBkYXRl ZCB2ZXJzaW9uIOKAkyBJIHdpbGwgcmV2aWV3IHRoZSBjaGFuZ2VzIHNvbWUgdGltZSBhZnRlciB5 b3UgaGF2ZSBwb3N0ZWQgaXQuIEFuZCBiZWxvdyBmdXJ0aGVyIHJlc3BvbnNlcyB0byB5b3VyIHJl cGx5OjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7IFN0dWFydCBhbmQgSSBkaXNjdXNzZWQg dGhpcyBhdCBsZW5ndGggd2l0aCB0aGUgYXV0aG9yIG9mIHRoYXQgZG9jdW1lbnQuIEl04oCZcyBu b3QgYXMgc2ltcGxlIGFzIGl0IHNvdW5kcy4gRmlyc3QsIHRoZXJlIGFyZSBubyBjb21tb24gc2V0 IG9mIHBhcmFtZXRlcnMgdG8gcHVibGlzaCBpbiBjb3JlIFJELCBzbyBhbnkgdHJhbnNsYXRpb24g d291bGQgaGF2ZSB0byBiZSBiYXNlZCBvbiBoZXVyaXN0aWNzLg0KPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmZ3Q7IEJ1dCBDb3JlIFJEIGFuZCBETlMtU0QgaGF2 ZSBmYWlybHkgZGlmZmVyZW50IGNvcmUgYXNzdW1wdGlvbnMsIGFuZCBhcyBhIGNvbnNlcXVlbmNl LCB0aGVyZSBkaWRu4oCZdCBzZWVtIHRvIGJlIGFuIG9idmlvdXMgbWFwcGluZy48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+WWVzIEkgcmVjYWxsIGZyb20gb25lIG9mIHRoZSBhdXRob3JzIHRoYXQg ZG9pbmcgdGhpcyBtYXBwaW5nIGlzIGhhcmQsIGlmIG5vdCBpbXBvc3NpYmxlLiBJbiBteSB2aWV3 IGl0IG1pZ2h0IHN0aWxsIHdvcmsgaWYgd2UgYXNzdW1lIGEgbGltaXRlZCBzdWJzZXQgb2YgRE5T LVNEIHNlbWFudGljcyB0aGF0IGNhbiBiZSBtYXBwZWQgdG8gYSBsaW1pdGVkIHN1YnNldCBvZiBD b1JFLVJEIHNlbWFudGljcywgYW5kIHZpY2UNCiB2ZXJzYS4mbmJzcDsgKFVuZGVyIHRoZSBhc3N1 bXB0aW9uIHRoYXQgdGhpcyBzdGlsbCB3b3VsZCBiZSByZWxldmFudCBmb3IgdGhlIGFwcGxpY2F0 aW9ucy9zeXN0ZW1zIHRoYXQgd291bGQgdXNlIGVpdGhlciBETlMtU0Qgb3IgQ29SRSBmb3IgdGhl aXIgaW5pdGlhbCwgYmFzaWMgc2VydmljZSBkaXNjb3ZlcnnigKYpJm5ic3A7Jm5ic3A7IEFzIGFu IGV4YW1wbGUgb2YgYSBzdWJzZXQsIHRoZSBDb1JFIFJEIGRyYWZ0IHNpbmNlIC0xNCBkZWZpbmVz IGEgc3Vic2V0IG9mIHRoZQ0KIENvUkUgTGluayBGb3JtYXQgdGhhdCBpdCBhaW1zIHRvIHN1cHBv cnQsIGdpdmVuIHRoYXQgdGhlIGZ1bGwgZm9ybWF0IHdhcyB0b28gY29tcGxleCBmb3IgZGV2ZWxv cGVycyB0byBnZXQgaXQgcmlnaHQgYW5kIGV2ZW4gd2FzIGhhcmQgZm9yIHRoZSBleHBlcnRzIHRv IGFncmVlIG9uIGludGVycHJldGF0aW9uLiBTbyBkb2luZyBzb21lIHVuZGVyc3RhbmRhYmxlIHN1 YnNldHMgbWF5IGJlIHRoZSBvbmx5IHdheSDigJMgb3IgZ2l2ZSB1cCBvbiB0aGUgaWRlYS4mbmJz cDsNCiBJbiB0aGUgUkQgY2FzZSB0aGUgZnVsbCBMaW5rIEZvcm1hdCBjYW4gc3RpbGwgYmUgdXNl ZCBidXQgbGVhZHMgdG8gaW1wbGVtZW50YXRpb24tc3BlY2lmaWMgYmVoYXZpb3Igb2YgdGhlIFJE IGluIGNhc2Ugc3RhdGVtZW50cyBhcmUgdXNlZCB0aGF0IGdvIGJleW9uZCB0aGUgc3Vic2V0Ljxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7IE9uZSBwcm9ibGVtIGlzIHRoYXQgRE5TLVNEIGhh cyBzZW1hbnRpY3MsIHdoaWNoIENvcmUgUkQgZG9lc27igJl0LiBETlMtU0QgaGFzIGEgYml0IG9m IGZyZWUtZm9ybSBhZGRpdGlvbmFsIGRhdGEgaW4gdGhlIGZvcm0gb2YgdGhlIFRYVCByZWNvcmQs IGJ1dCBtb3N0IG9mIHRoZSBkYXRhIGlzIHN0cnVjdHVyZWQgYW5kIGlzIGp1c3QgYWJvdXQgZmlu ZGluZyBhIHNlcnZpY2UuIENvcmUgUkQgaXMgYSBsb3QgbW9yZQ0KIGdlbmVyYWwgdGhhbiB0aGF0 LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UcnVlOyBpdCB3b3VsZCBiZSBpbnRlcmVzdGluZyBm b3IgbWUgdG8gbGVhcm4gdGhlc2Ugc2VtYW50aWNzIGFuZCBzZWUgaG93IHRoZXkgY291bGQgbWFw IHRvIENvUkUgTGluayBGb3JtYXQuIEJlY2F1c2UgTGluayBGb3JtYXQgaXMgZXh0ZW5kaWJsZSAo UkZDIDY2OTAgLCBpbmhlcml0cyBXZWIgTGlua2luZyBSRkMgNTk4OCwgd2hpY2ggaW5oZXJpdHMg UkRGLCBzbyBuZXcgcmVsYXRpb24gdHlwZXMgd2l0aCBzcGVjaWZpYw0KIHNlbWFudGljcyBjYW4g YmUgZnJlZWx5IGRlZmluZWQuICkgdGhpcyBjYW4gYmUgZGVmaW5lZC48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlZpY2UgdmVyc2Egc29tZSBDb1JFIExpbmsgRm9ybWF0IHNl bWFudGljcyB3b3VsZCBuZWVkIHRvIGJlIHJlbW92ZWQgaW4gdGhlIHRyYW5zbGF0aW9uIHRvIERO Uy1TRCBwcm9iYWJseSwgYnV0IHRoZSBiYXNpYyBzZXJ2aWNlIGRpc2NvdmVyeSBhc3BlY3QgKGlu IExpbmsgRm9ybWF0IHRoaXMgaXMgdGhlIOKAnGhvc3Rz4oCdIHJlbGF0aW9uIHR5cGUpIGNvdWxk IGJlIGF0IGxlYXN0IGF0dGVtcHRlZC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyBJIHN1 c3BlY3QgdGhhdCB0aGUgQ29SRSBSRCBsaWZldGltZSBpcyBhaW1lZCBhdCBzbGVlcHkgZW5kIGRl dmljZXMgYXMgYSBkZWZhdWx0LCB3aGVyZSBTUlAgaXMgYWltZWQgYXQgcG93ZXJlZCBkZXZpY2Vz IGFzIGEgZGVmYXVsdC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWdyZWUsIENvUkUgdGFyZ2V0 cyBjb25zdHJhaW5lZCBkZXZpY2VzIGluY2x1ZGluZyBzbGVlcHkgZGV2aWNlcyDigJMgYW5kIHBy b2JhYmx5IGxlc3MgZHluYW1pY3MgZS5nLiBhIHNlbnNvciB0aGF0IGp1c3Qgc2l0cyBhdCBvbmUg bG9jYXRpb24gMjQvNyBhbmQgd2FrZXMgdXAgb25jZSBpbiBhIHdoaWxlLg0KPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZndDsgJm5ic3A7Jmd0OyBUaGUgdGVybSDigJxTUlAgY2xpZW504oCdIGlz IHVzZWQsIHNvbWV0aW1lcyBmb3IgdGhlIHJlZ2lzdGVyaW5nIHNlcnZpY2XigJlzIGhvc3QgYW5k IHNvbWV0aW1lcyBmb3IgYSBjbGllbnQgdXNpbmcgb25seSB0aGUgc2VydmljZSBsb29rdXAgZnVu Y3Rpb24uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7ICZndDsgSXMg dGhhdCBjb3JyZWN0PyBTaG91bGQgaXQgYmUgZXhwbGFpbmVkIGluIGEgdGVybWlub2xvZ3kgc2Vj dGlvbj8gQW5kIHdlIGhhdmUgYWxzbyBhYm92ZSBETlMtU0QgcmVnaXN0cmF0aW9uIHByb3RvY29s IGNsaWVudC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsgJmd0OyBB bHNvIOKAnFNSUCBzZXJ2ZXLigJ0gdnMg4oCcU1JQIFNlcnZlcuKAnSBhcmUgYm90aCB1c2VkLjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyBGaXhlZCB0aGUgbGF0dGVyLiBJIGRpZG7i gJl0IGZpbmQgYW55IGluc3RhbmNlcyBvZiB0aGUgZm9ybWVy4oCUY2FuIHlvdSBwb2ludCBtZSB0 byBvbmUgaW4gdGhlIHVwZGF0ZT88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TG9va2luZyBhdCB0 aGUgdGV4dCAoLTA1KSBhZ2FpbiwgSSBzZWUgdGhhdCDigJhjbGllbnTigJksIOKAmFNSUCBjbGll bnTigJkgYW5kIOKAmEROUy1TRCByZWdpc3RyYXRpb24gcHJvdG9jb2wgY2xpZW504oCZIGFyZSB1 c2VkIGZvciBtb3N0bHkgdGhlIHNhbWUgY29uY2VwdCDigJMgdGhlIFNSUCBjbGllbnQgcHVibGlz aGluZyB0aGUgc2VydmljZS4gVGhlIGxvb2t1cCBhc3BlY3Qgb25seSBhcHBlYXJzIGluIFNlY3Rp b24gMSB0ZXh0DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPuKAnE9uY2Ug cHVibGlzaGVkLCB0aGVzZSBzZXJ2aWNlcyBjYW4gYmUgcmVhZGlseSBkaXNjb3ZlcmVkIGJ5IGNs aWVudHMgdXNpbmcgc3RhbmRhcmQgRE5TIGxvb2t1cHPigJ0gLiBIZXJlIGl0IGlzIGNsZWFyIHRo YXQgdGhlIGNsaWVudCBpcyBhcyBhIHN0YW5kYXJkIEROUyBjbGllbnQgd2hlbiBkb2luZyB0aGlz IHNvIG5vIGFtYmlndWl0eS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklu IFNlY3Rpb24gMy4yIEkgd2FzIHRoaW5raW5nIHRoYXQgdGhlIOKAmGNsaWVudOKAmSBoZXJlIGdl dHRpbmcgdGhlIHJlc3BvbnNlIGZyb20gdGhlIOKAmEROUyBzZXJ2ZXLigJkgbXVzdCBiZSBhIERO UyBjbGllbnQgYmVjYXVzZSBpdCBkaWQgbm90IHNheSDigJhTUlAgc2VydmVy4oCZIGhlcmUuIFdl IGNvdWxkIGNoYW5nZSBoZXJlIOKAmEROUyBzZXJ2ZXJz4oCZIHRvIOKAmFNSUCBzZXJ2ZXJz4oCZ IGp1c3QgdG8gYmUgY2xlYXIuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4o QmVjYXVzZSB0aGUgbG9va3VwIGZ1bmN0aW9uIGlzIG5vdCBkZXNjcmliZWQgaW4gdGhpcyBkcmFm dCBidXQgaW4gb3RoZXIgUkZDcyDigJMgc3RhbmRhcmQgRE5TLVNEIG9yIG1ETlMgcXVlcmllcyBl dGMg4oCTIHRoZSBwb3NzaWJpbGl0eSBvZiBjb25mdXNpb24gaXMgY3VycmVudGx5IG1pbmltYWwg dGhvdWdoLik8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyAmZ3Q7IDMuMiBUaGlzIHNheXMg bm90aGluZyBhYm91dCB0aGUgU0lHKDApIHZhbGlkYXRpb24gcmVxdWlyZWQgYnkgdGhlIFNSUCBz ZXJ2ZXIuIFRoYXQgc2VlbXMgc3RyYW5nZSwgZ2l2ZW4gdGhlIHRpdGxlPzxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyAmZ3Q7IFRpdGxlIGNvdWxkIGJlIGNoYW5nZWQg dG8gZS5nLiDigJx2YWxpZGF0aW5nIFNSUCBzZXJ2ZXIgcmVzcG9uc2Vz4oCdLiZuYnNwOyBBbmQg cGVyaGFwcyBhZGQgc29tZSBTSUcoMCkgdmFsaWRhdGlvbiBjb25zaWRlcmF0aW9ucyBieSB0aGUg U1JQIHNlcnZlciwgaWYgd2UgaGF2ZSBhbnkuIChFLmcuIGF2b2lkIGNlcnRhaW4gYWxnb3JpdGht cz8NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jmd0OyAmZ3Q7 IFRyeSBvbmx5IG9uZSBvciB0cnkgbXVsdGlwbGU/IE1heWJlIHRoZSBrZXkgYWxyZWFkeSBlbmNv ZGVzIHRoZSB1c2VkIGFsZ29yaXRobSDigJMgSSBkaWRu4oCZdCBsb29rIGludG8gdGhhdDsgaW4g d2hpY2ggY2FzZSB0aGVyZSBjb3VsZCBiZSBpbnZhbGlkIGFsZ29yaXRobXMgb3IgJm5ic3A7cGFy YW1ldGVycyBzcGVjaWZpZWQgZXRjLik8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZndDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsgSXTigJlz IHBvaW50aW5nIG91dCBhIGxpbWl0YXRpb24sIHNvIHRoZXJl4oCZcyBubyBuZWVkIHRvIG1lbnRp b24gdGhlIGNhc2Ugd2hlcmUgdGhlIGxpbWl0YXRpb24gaXMgbm90IHByZXNlbnQuPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPldoYXQgYWJvdXQgY2hhbmdpbmcgdGhlIHRpdGxlIGZvciB0aGlzIHNl Y3Rpb24gMy4yIHRvIOKAnFNSUCBTZXJ2ZXIgUmVzcG9uc2UgVmFsaWRhdGlvbuKAnSA/Jm5ic3A7 IFRoYXQgd291bGQgZml0IHRoZSBjdXJyZW50IHRleHQgYmVzdC4NCjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Rm9yZ2V0IHdoYXQgSSBzYWlkIGFib3V0IHRoZSBzZWxlY3Rp b24gb2YgU0lHKDApIGFsZ29yaXRobXMgYmVjYXVzZSB0aGF04oCZcyBhbHJlYWR5IGluIDMuMyBJ IHNlZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyAmZ3Q7IFRoZSBjb25zdHJhaW5lZCBk ZXZpY2VzIHdvdWxkIHVzZSBVRFAgdG8gcmVnaXN0ZXIgYW5kIGFsc28gdG8gcXVlcnkgZm9yIHNl cnZpY2VzIHBvc3NpYmx5LCBzbyBJIHdvdWxkIGV4cGVjdCBhbiAmcXVvdDtfZG5zc2Qtc3JwLl91 ZHAuJmx0O2RvbWFpbiZndDsuJnF1b3Q7IHRvIGJlIGRlZmluZWQgYXQgbGVhc3QuPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7ICZndDsgRXZlbiBpZiBvbiB0aGUgY29u c3RyYWluZWQgbmV0d29yayB0aGVyZSBtYXkgYmUgYSBjdXN0b20gd2F5IHRvIHByb3ZpZGUgdGhl IGhvc3QvcG9ydCBvZiB0aGUgU1JQIHNlcnZlciB0byBub2Rlcy4mbmJzcDsgQWZ0ZXIgYWxsIGl0 ICo8Yj5taWdodDwvYj4qIHVzZSBETlMtU0QgZm9ybWF0IHRvIGRpc3RyaWJ1dGUgc3VjaCBpbmZv cm1hdGlvbiwgb3Igbm90PzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0 OyAmZ3Q7IEFub3RoZXIgY29uc2lkZXJhdGlvbjogaWYgVURQIGlzIHN1cHBvcnRlZCwgdGhlbiBV RFArRFRMUyBtYXkgYmUgdG9vPyZuYnNwOyBBbHRob3VnaCB0aGF0IHdvdWxkIHNldmVyZWx5IGlu Y3JlYXNlIHRoZSByZXNvdXJjZSB1c2FnZSAocG93ZXIsIG5ldHdvcmsgYmFuZHdpZHRoKSBvZiBj b25zdHJhaW5lZCBkZXZpY2VzIHBlcmhhcHMgd2UgZG9u4oCZdCB3YW50IHRvIHJ1bGUgdGhhdCBv dXQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7IDxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyBXZeKAmXJlIGFzc3VtaW5nIHRoaXMgaXMg ZGlzY292ZXJlZCB1c2luZyBhIG5ldHdvcmstc3BlY2lmaWMgbWVjaGFuaXNtLjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5BZ3JlZTsgaXQgd2lsbCBiZSBuZXR3b3JrLXNwZWNpZmljIGFuZCBpdCBt YXkgbm90IGludm9sdmUgYSBETlMtU0QgZGVzY3JpcHRpb24gYXQgYWxsLiBFLmcuIGp1c3QgYW4g SVAgYWRkcmVzcyBhbmQgYSBwb3J0IGNvbmZpZ3VyYXRpb24uIFNvbWUgb2YgdGhlc2UgbmV0d29y ay1zcGVjaWZpYyBtZWFucyBtYXkgaW4gdGhlIGZ1dHVyZSB1c2UgRE5TLVNEIGRlc2NyaXB0aW9u cyB0byBwdWJsaXNoIC8g4oCYcHVzaOKAmQ0KIGF2YWlsYWJsZSBuZXR3b3JrIHNlcnZpY2VzIHRv IGNsaWVudHMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbmQgb25lIG9m IHRoZXNlIHNlcnZpY2VzIG1heSBiZSBhIFVEUC1iYXNlZCBTUlAgc2VydmVyIHdoZXJlIHRoZSBj bGllbnQgY2FuIHRoZW4gY2hvb3NlIHRvIHJlZ2lzdGVyLiBUaGVuIHRoaXMgZGVzY3JpcHRpb24g d291bGQgdXNlICZxdW90O19kbnNzZC1zcnAuX3VkcC4mbHQ7ZG9tYWluJmd0Oy4mcXVvdDsmbmJz cDsgLCBob3dldmVyIHRoaXMgaXMgbm90IGZvcm1hbGx5IGRlZmluZWQgaW4gdGhlIElBTkEgU2Vy dmljZSBOYW1lcyByZWdpc3RyeQ0KIHNvIHRoZSBwZW9wbGUgZG9pbmcgdGhpczxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+d291bGQgaGF2ZSB0byByZWdpc3RlciB0aGF0IGVu dHJ5LiZuYnNwOyBUaGF0IGlzIHN0aWxsIG9rYXksIHRob3VnaCBJIGNvbnNpZGVyZWQgaXQgYmV0 dGVyIGlmIHRoZSBwcmVzZW50IGRyYWZ0IHdvdWxkIGFscmVhZHkgZm9ybWFsbHkgcmVzZXJ2ZSB0 aGUgc2VydmljZSBuYW1lICZxdW90O19kbnNzZC1zcnAuX3VkcC4mbHQ7ZG9tYWluJmd0Oy4mcXVv dDsgZm9yIHRoaXMgcHVycG9zZSBqdXN0IHRvIGJlIGNvbXBsZXRlLjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5Bbm90aGVyIGFyZ3VtZW50IHdoeSB0aGlzIGlzIG5lZWRlZCBpcyB0aGUgZm9sbG93 aW5nOiB0aGUgcHJlc2VudCBkcmFmdCBzYXlzIFJGQyAyMTM2IGlzIHRoZSB3YXkgZm9yIHRoZSBj bGllbnQgdG8gc2VuZCBpdHMgRE5TIHVwZGF0ZXMgdG8gdGhlIFNSUCBzZXJ2ZXIuIEFuZCB0aGF0 IGRlZmluZXMgYm90aCBVRFAgYW5kIFRDUC4gSWYgd2Ugd2FudCB0byBudWRnZSBwZW9wbGUgdG93 YXJkcyB1c2luZyBUQ1AgYW5kDQogbm90IFVEUCB3aGVyZSBwb3NzaWJsZSwgdGhlbiA8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnRoaXMgc2hvdWxkIGJlIG1hZGUgZXhwbGlj aXQgSSB0aGluayBpbiBTZWN0aW9uIDIuMy4xIOKAkyBhZGQgYSBidWxsZXQg4oCcQ2xpZW50cyBT SE9VTEQvTVVTVCB1c2UgVENQ4oCdLiZuYnNwOyBJZiBVRFAgYW5kIFRDUCBhcmUgdHJlYXRlZCBh cyBlcXVhbHMgYXMgaW4gUkZDIDIxMzYgdGhlbiBJIHdvdWxkIGFzc3VtZSBib3RoIG5lZWQgdG8g YmUgc3VwcG9ydGVkIGFzIHdlbGwgZm9yIHRoZSBTUlAgc2VydmVyLCBwb3RlbnRpYWxseS48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNvIGlzIGl0IGludGVuZGVkIHRoYXQg dGhlIG5vbi1jb25zdHJhaW5lZCBjbGllbnRzIGNhbiBvbmx5IGRpc2NvdmVyIHRoZSBUQ1AtYmFz ZWQgU1JQIHNlcnZlciwgYW5kIG5vdCB0aGUgVURQLWJhc2VkIFNSUCBzZXJ2ZXI/IElmIHNvIHRo ZW4gb25seSBkZWZpbmluZyB0aGUgVENQLWJhc2VkIHNlcnZpY2UgZGVzY3JpcHRpb24gaXMgZW5v dWdoLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Tm90ZTogSeKAmW0gYXNz dW1pbmcgaW4gdGhlIGFib3ZlIHRoYXQgVENQL1VEUCBiYXNlZCBzZXJ2aWNlcyBvZiBTUlAgc2Vy dmVyIGFyZSBzZXBhcmF0ZWx5IGFkdmVydGlzZWQgaW4gRE5TLVNEIGlmIGJvdGggYXJlIHByZXNl bnQsIGJ1dCBJIG1heSBiZSB0b3RhbGx5IHdyb25nIGhlcmUuIElmIEnigJltIHdyb25nIHRoZW4g cGxlYXNlIGlnbm9yZSB0aGlzIGFyZ3VtZW50LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7 IFVubGVzcyBDb1JFIFJEIGRvZXMgc29tZXRoaW5nIGxpa2UgRkNGUyBuYW1pbmcsIGZvciBpbnN0 YW5jZSwgaXQgd291bGQgbGlrZWx5IGJlIHF1aXRlIGEgYml0IG1vcmUgY29tcGFjdC48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+UkQgZG9lcyBoYXZlIEZDRlMgbmFtaW5nIGJ1dCDigJMgYmVjYXVz ZSB0aGVyZSBpcyBubyBkZWZhdWx0IHNlY3VyaXR5IHNvbHV0aW9uIOKAkyBpdCBpcyByYXRoZXIg aW5kaXJlY3RseSBkZWZpbmVkLiZuYnNwOyBSRCBkcmFmdCBzYXlzIHRoYXQgcmVnaXN0ZXJpbmcg Y2xpZW50cyBNVVNUIHVzZSB1bmlxdWUgbmFtZXMgYW5kIHBvaW50cyB0byBzb21lIG1lY2hhbmlz bXMgZm9yIGNsaWVudHMgdG8gZ2VuZXJhdGUgcmFuZG9tIFVVSUQNCiBuYW1lcyBpbiBjYXNlIHRo ZXJlIGZpcnN0IGF0dGVtcHQgYXQgcmVnaXN0cmF0aW9uIHdpdGggYSBuYW1lIGZhaWxlZC48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBjYXNlIHdoZXJlIG5vIHNlY3Vy aXR5IGlzIHVzZWQgYmVjb21lcyBhbHNvIHRyaWNreSB0aGVuOyBhcyB0aGUgUkQgc2VydmVyIG1h eSBiZSB1bmFibGUgdG8gZGlzdGluZ3Vpc2ggYSBuYW1lLWNvbGxpc2lvbiBmcm9tIGEgbGVnaXRp bWF0ZSBjbGllbnQgbWFraW5nIGEgc2VydmljZSB1cGRhdGUuIFRoZSBleHBlY3RhdGlvbiB0aGVy ZSBpcyB0aGF0IGNsaWVudHMgd2lsbCBjaG9vc2UgcmFuZG9tIC8gVVVJRA0KIG5hbWVzIGluIHRo YXQgY2FzZSB0byBwdXNoIHRoZSBwcm9iYWJpbGl0eSBvZiBjb2xsaXNpb24gdG8gMCUuIChEb2Vz buKAmXQgd29yayBhZ2FpbnN0IGF0dGFja2Vycy4pPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5BbmQgUkTigJlzIExpbmsgRm9ybWF0IGNhbiBpbiBzb21lIGNhc2VzIGJlIHJh dGhlciBpbmVmZmljaWVudCDigJMgdGhlcmXigJlzIG5vdyBhbiBlZmZvcnQgdG8gZGVmaW5lIGEg bmV3IGJpbmFyeSBmb3JtYXQgQ29SQUwgdGhhdCBjb3VsZCByZXBsYWNlIGl0LiZuYnNwOyBBbiBS RCBjb3VsZCBoYW5kbGUgYm90aCBMaW5rIEZvcm1hdCBhbmQgQ29SQUwgaW4gcHJpbmNpcGxlLjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Fc2tvPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_AM8P190MB09794FA65E2295764589AAE4FD110AM8P190MB0979EURP_-- From nobody Tue Nov 3 04:46:07 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 615693A093D for ; Tue, 3 Nov 2020 04:46:06 -0800 (PST) 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, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3972AVyhCzCW for ; Tue, 3 Nov 2020 04:46:04 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 B57D13A08F6 for ; Tue, 3 Nov 2020 04:46:04 -0800 (PST) Received: from pps.filterd (m0049295.ppops.net [127.0.0.1]) by m0049295.ppops.net-00191d01. (8.16.0.43/8.16.0.43) with SMTP id 0A3CZJDf049127; Tue, 3 Nov 2020 07:46:03 -0500 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049295.ppops.net-00191d01. with ESMTP id 34hmvs0huq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 03 Nov 2020 07:46:03 -0500 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 0A3Ck21q000600; Tue, 3 Nov 2020 07:46:02 -0500 Received: from zlp30488.vci.att.com (zlp30488.vci.att.com [135.47.91.93]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 0A3CjwgM000536 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 3 Nov 2020 07:45:58 -0500 Received: from zlp30488.vci.att.com (zlp30488.vci.att.com [127.0.0.1]) by zlp30488.vci.att.com (Service) with ESMTP id 10670400A0A8; Tue, 3 Nov 2020 12:45:58 +0000 (GMT) Received: from GAALPA1MSGEX1CC.ITServices.sbc.com (unknown [135.50.89.110]) by zlp30488.vci.att.com (Service) with ESMTPS id F1415400A0A7; Tue, 3 Nov 2020 12:45:57 +0000 (GMT) Received: from GAALPA1MSGEX1CB.ITServices.sbc.com (135.50.89.109) by GAALPA1MSGEX1CC.ITServices.sbc.com (135.50.89.110) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2044.4; Tue, 3 Nov 2020 07:45:57 -0500 Received: from GAALPA1MSGEX1CB.ITServices.sbc.com ([135.50.89.109]) by GAALPA1MSGEX1CB.ITServices.sbc.com ([135.50.89.109]) with mapi id 15.01.2044.006; Tue, 3 Nov 2020 07:45:57 -0500 From: "STARK, BARBARA H" To: "'Ted Lemon'" CC: "'dnssd@ietf.org'" Thread-Topic: [dnssd] Review of draft-ietf-dnssd-srp-04; and relation to CoRE Resource Directory Thread-Index: AdahZCdWnFqFugrYTgawM9Kzp4FPCAQPG+kAAA+b7wA= Date: Tue, 3 Nov 2020 12:45:57 +0000 Message-ID: <2eaa00ed3ab846d08c09a64dab67d3ce@att.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.81.76] x-tm-snts-smtp: DFF9B20E0E7A5EBDE82CE44A42F8654B88125665BFCCDD725DB833B1951299052 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-11-03_08:2020-11-03, 2020-11-03 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 bulkscore=0 phishscore=0 suspectscore=0 mlxscore=0 impostorscore=0 lowpriorityscore=0 priorityscore=1501 spamscore=0 clxscore=1011 malwarescore=0 adultscore=0 mlxlogscore=626 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2011030086 Archived-At: Subject: Re: [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, 03 Nov 2020 12:46:06 -0000 > Oh, two things I forgot to say in the reply. First, thanks very much for = the > thorough and thoughtful review. It is much appreciated. >=20 > Secondly, I am afraid that I left it too late and missed the posting dead= line. > Not sure what to do about that in the short term, but I will upload it as= soon > as I can. Hi Ted, Since dnssd isn't meeting in IETF 109, the posting deadline isn't highly re= levant. But perhaps after you do post something, it might be good to schedu= le an interim. Thx, Barbara From nobody Tue Nov 3 05:07:48 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 10DE23A09D5 for ; Tue, 3 Nov 2020 05:07:47 -0800 (PST) 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, NO_DNS_FOR_FROM=0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no 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 saJrQDmpYDN0 for ; Tue, 3 Nov 2020 05:07:45 -0800 (PST) Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com [IPv6:2607:f8b0:4864:20::835]) (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 717FA3A09C6 for ; Tue, 3 Nov 2020 05:07:45 -0800 (PST) Received: by mail-qt1-x835.google.com with SMTP id m65so11445625qte.11 for ; Tue, 03 Nov 2020 05:07:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=5VZTxNDgd1dwvUqFf4Xy2vnezBe6q5gwSjXZ5gzygck=; b=pXENPlvSot3l1P0yize7q5zXcHSQyayz4klffIyQBXQXLEaCxPjm4W9m89IQdqg6OT 1V/GSRbmHHHmz44g3HAdfCdQFu8ozLtNgEvLX4FarsBTk3njUk3BJrWz1YFFb4JZe02m D79H/k3+50f4K7b6JFLa4aJPH/AAgGcgt6HG8+BsxSELKsUXJCMlQuOoVgRLw0MJBdqk WibAHcfngIi2OYYsDPn8tEUl4vrf7M3XZ53uFg0Wjg75zDmqlb4U0Sx9MwfTVj8+M0LK hHwjP6tWYyCPFUfmEeZynZJfwIo8kN9Fw5LFNrMduYgls+pMbGoal54Bbtaf4Ccxs2lS fa+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=5VZTxNDgd1dwvUqFf4Xy2vnezBe6q5gwSjXZ5gzygck=; b=XmonrynMTe0mCfwTU/BXy9eW4v2jazkcdEL++AiwrQ3gjAvQG4UcMhwMNn3BfeFe4f jl8hlZfK/QEwii/x8vMZKT3lPOQll3xW69FH1xvkPVhWd1oO2hcH4Y2qK0EeI+bMeWSO 1O/lg48CYKVCdJhteZpIMb/BdJIcyBt3w+Cx3L2Glwbt5v+DQM1XglRclIuMzbAgDhx7 gyIpNVJTOmLPh35xB+jpVb5ofXKBoYXANWv1ybeQDM0RQTzHUlilNpZRw72WEi0pD7yM O1b1IH1IDv9dyWIAySpGdSAh/zDxKkzhD5wNkmRsVJ11pIQIrCPGfegGj+Kh9TZCIE+e MszA== X-Gm-Message-State: AOAM531TK0eSHaLLc6f/R5CbvIvS7COBIEVmPYeTggPVMF4OqLIbQebN /prkmzGFwE6RTpf4WAzTM94pdiR7DUk/mA== X-Google-Smtp-Source: ABdhPJz8oXIDcbcLeUJpxRUx3OCM/AJpOaJzSatfAVuVZI3AyqexzEamihvrlo6DHR7jskLBg9l4gA== X-Received: by 2002:aed:2746:: with SMTP id n64mr17673897qtd.212.1604408864042; Tue, 03 Nov 2020 05:07:44 -0800 (PST) Received: from [192.168.4.114] (c-24-91-177-160.hsd1.ma.comcast.net. [24.91.177.160]) by smtp.gmail.com with ESMTPSA id o2sm6531956qkd.12.2020.11.03.05.07.43 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 03 Nov 2020 05:07:43 -0800 (PST) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Ted Lemon Mime-Version: 1.0 (1.0) Date: Tue, 3 Nov 2020 08:07:41 -0500 Message-Id: <6AA57B75-2EC5-4C6C-8815-AE3A161A3622@fugue.com> References: <2eaa00ed3ab846d08c09a64dab67d3ce@att.com> Cc: dnssd@ietf.org In-Reply-To: <2eaa00ed3ab846d08c09a64dab67d3ce@att.com> To: "STARK, BARBARA H" X-Mailer: iPhone Mail (18B84) Archived-At: Subject: Re: [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, 03 Nov 2020 13:07:47 -0000 I think that would be good, yes. There will be a bunch of additional stuff t= o work on=E2=80=94the srp updates are just the beginning. Some of this stuff= potentially implicates homenet as well.=20 FYI what=E2=80=99s coming is more on the advertising proxy, a way to discove= r local advertising proxies, a way to add replication to a local (unmanaged)= SRP service, and possibly more. So yeah, it would be good to do an interim s= o we can get all that out on the table and talk about it. :) > On Nov 3, 2020, at 07:46, STARK, BARBARA H wrote: >=20 > =EF=BB=BF >>=20 >> Oh, two things I forgot to say in the reply. First, thanks very much for t= he >> thorough and thoughtful review. It is much appreciated. >>=20 >> Secondly, I am afraid that I left it too late and missed the posting dead= line. >> Not sure what to do about that in the short term, but I will upload it as= soon >> as I can. >=20 > Hi Ted, > Since dnssd isn't meeting in IETF 109, the posting deadline isn't highly r= elevant. But perhaps after you do post something, it might be good to schedu= le an interim. > Thx, > Barbara From nobody Sun Nov 8 12:18:35 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 045DE3A0A4A for ; Sun, 8 Nov 2020 12:18:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.119 X-Spam-Level: X-Spam-Status: No, score=-1.119 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_NEUTRAL=0.779] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kirale-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 04qaYMWhfYaj for ; Sun, 8 Nov 2020 12:18:32 -0800 (PST) Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com [IPv6:2a00:1450:4864:20::636]) (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 348763A0A73 for ; Sun, 8 Nov 2020 12:18:32 -0800 (PST) Received: by mail-ej1-x636.google.com with SMTP id i19so9328872ejx.9 for ; Sun, 08 Nov 2020 12:18:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kirale-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=/BNkl4M7kBJ3F0ZQYpCojSUHZh514Lh004POdazR8FQ=; b=aO1ZEhVX/twk6j9DWSLJovdBGLaPqRo0gy3ANyAGxLcNTpvvBTngzyE+/if3xez3cx gZ0CLzXVdGFuJRhaGDh0BxCQNoVrrtVedC8qbkUYisOVdfBcGZSS3bR5e3UrxgOfc9Eo R0QQ8MKyC5RKxchwb84z0Co33dJKhUyMO0XjuViyDmm+V7/JcR4l3FqD+GFepEjFnCSc JgH3QSMPLXSLSQxup6iG2yg81xYjB4KJcwINipqQnNADef3HY60Xz7ZHKz4hXwqB5eBK e4hHapXKzP95qHBbFqwmSHGPcft0GQKnygdb0dR3X38pbimkI2ql44eY4ExxuQZfPQmM nF+g== 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=/BNkl4M7kBJ3F0ZQYpCojSUHZh514Lh004POdazR8FQ=; b=HkX9bRh3FA6G49I5heCp8CpNxa/C/HW/qSo+wH+qy0OtvMZnWFfbs2lT6DWqyYjdI+ lUuYFmqnF0/6zDRFdAVEAw12v1yvbHOWVmcc3c5phY2YwTgIVrmG9g8rTj1XYAciidhU wAO6JGPtccjGG3HSA3c5H0AV+yPRdxgOb0imB95s7SbsQ8gqpvdMYxVWTv/98cuWpzV0 3UrrOjBFGVe68WVcyGbfvaim6VoKFWDZ2Ec1+ISmSTJhS9CIDvqBgMMu8k0QBTYigPow 83KGUQ3W+AldRBzZ6gX4LYnvpD6rtNsulXolCdg/RRbfpDQGYyOaGAvKNRoCVGhDbfQX 9f5w== X-Gm-Message-State: AOAM533kpjFeYx+V/aGgoO0wxv/TP/rHBpPdb2nlf0kH50+1DmQ/hiUv rm/IdXh7PxH8CfJS4VFoBXgtRefM1cZEA0HdQe6sivTkOaGPsA== X-Google-Smtp-Source: ABdhPJx72oE6pDmP4WloOgA+tSlSYYWd0T7UBrUdDTdZD6yA3AiyC6PdH3BTWThnI69KtJdZnkNiQ8e8V5cQWmPEaEY= X-Received: by 2002:a17:906:804:: with SMTP id e4mr11812550ejd.420.1604866710253; Sun, 08 Nov 2020 12:18:30 -0800 (PST) MIME-Version: 1.0 From: Manuel Amutio Date: Sun, 8 Nov 2020 21:18:18 +0100 Message-ID: To: dnssd@ietf.org Content-Type: multipart/alternative; boundary="0000000000002d4cc105b39e26ca" Archived-At: Subject: [dnssd] Review of draft-ietf-dnssd-srp-05 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, 08 Nov 2020 20:18:34 -0000 --0000000000002d4cc105b39e26ca Content-Type: text/plain; charset="UTF-8" Hi, I've revised the current version "draft_05" and in general it looks good to me. I believe that it is an important improvement in the use of automatic discovery of network services and it is greatly useful for IoT constrained devices. Leave my comments below. Best, Manuel /------------- Typos --------------/ Page 9, first paragraph: "This key pair MUST be unique to the device" is repeated twice. "+" symbol appears twice. Page 12, second paragraph: "Instrructions" /------------- Doubts -------------/ Page 9, section 2.4.1.1 Service Behavior: "the key MAY be overwritten as a result of a full reset of the device (e.g., a "factory reset")" What happens then? Page 10, section 2.4.2 Removing published services: "To remove a service registration, the client retransmits its most recent update..." "However, in some cases a client may not have retained sufficient state to know that some service instance is pointing to a host that it is removing." Then, how is it able to retransmit an update of something that no longer knows? Page 15, section 2.6.2. Sleep Proxy: This feature conditions the location of SRP Server, right? If we thought in a Border Router, it would only be useful for external traffic going through BR, but not for traffic initiated in the mesh network. Maybe I have misunderstood it. Regarding the protocol used, I don't see a clear drawback to not allow using UDP for the constrained devices. If the DNS service allows it, I believe that this new protocol should support it too. --0000000000002d4cc105b39e26ca Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I've=C2=A0revised th= e current version "draft_05" and in general it looks good to me. = I believe that it is an important improvement in the use of automatic disco= very of network services and it is greatly useful for IoT constrained devic= es.

Leave my comments below.

Best,
Manuel

/------------- Typos --------------/
Page 9,= first paragraph:
"This key pair MUST be unique to the device"= ; is repeated twice.
"+" symbol appears twice.

Page 12= , second paragraph:
"Instrructions"

<= div>/------------- Doubts -------------/
Page 9, section 2.4.1.1 = Service Behavior:
"the key MAY be overwritten as a result of a ful= l reset of the device (e.g., a "factory reset")"

What happens then?

Page 10, section 2.4.2 Removing published= services:
"To remove a service registration, the client retransmi= ts its most recent update..."
"However, in some cases a clie= nt may not have retained sufficient state to know that some service instanc= e is pointing to a host that it is removing."

Then, how= is it able to retransmit an update of something that no longer knows?
=
Page 15, section 2.6.2. Sleep Proxy:
This feature conditions the lo= cation of SRP Server, right?
If we thought in a Border Router, it= would only be useful for external traffic going through BR, but not for tr= affic initiated=C2=A0in the mesh network.=C2=A0
Maybe I have misu= nderstood it.

Regarding the protocol used, I don&#= 39;t see a clear drawback to not=C2=A0allow using UDP for the=C2=A0constrai= ned devices. If the DNS service allows it, I believe that this new protocol= should support it too.


--0000000000002d4cc105b39e26ca-- From nobody Wed Nov 18 08:53:26 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 0096D3A097A for ; Wed, 18 Nov 2020 08:53:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.886 X-Spam-Level: X-Spam-Status: No, score=-1.886 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NO_DNS_FOR_FROM=0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no 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 sQBok1Z6ALxf for ; Wed, 18 Nov 2020 08:53:22 -0800 (PST) Received: from mail-qv1-xf36.google.com (mail-qv1-xf36.google.com [IPv6:2607:f8b0:4864:20::f36]) (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 1F65A3A0C93 for ; Wed, 18 Nov 2020 08:53:21 -0800 (PST) Received: by mail-qv1-xf36.google.com with SMTP id v20so1347793qvx.4 for ; Wed, 18 Nov 2020 08:53:21 -0800 (PST) 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=oWZVtZXreUJrrnQ92Z2sF7AbsgnJ5DWydvefy0YevCQ=; b=SWGZWCzRLOhOaBzFI9YgRANSe7Ev0n23uZLFCxI6Y5a//t89pFyaxmnSflLHvKP4Fa QovbULttb+2GPFAnKeJNIEv1BAs2bPnG0ZpW4AMbu5q57ubGJSn/bBdu64qHdfb3pgbq WB4FrxNcLoQSyJ9mH8dAgAZVF4o84CyKbqW+lgKuWirBM4MnO8z5QDPM/hMagIx7kk0W 46WuYlgeUjRBPeOvzY1W5n9IS+9n6ie+pTkU7rsGYfcFADtCOW/287XJcemnCnoXZv0I 85B1vdqHwdJR8BE5Ol17G5BNjO9LDcHEngC7Bh2QIaHInyZF601t2Rv0LrHibhnjPoVs tQrA== 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=oWZVtZXreUJrrnQ92Z2sF7AbsgnJ5DWydvefy0YevCQ=; b=RIuhGVDYc1H7d7mKY/ksAdcvnlES1rhpfkH7GsxGusN2mnhUqf+5srrqAO73dicAir 3U5C1TJJbo1lH8EVbmHOVeJL60HMY7ZpwewS+XFhxJbLqJ7ZjdRISpDQrrg5tygofQ25 dHqo4lKvdQMHm/KQyZkZtXI52gYzWjgGcLIYUTbEby7WKfwGpk5iZF8JEF3ukesjWzfT ff/FQca9OOBvgUhhtHJiXEukv9OHXuuGOniHfSc07BDQpuw9H2u4UDw4ayZ4Hth3EJx1 lWzq/QucF45xnmEuq1FK7h8JCYGBvcHreCahJ3C4tCd4L6w4dgO8Glv6o7C0J0gAN6dW 8NNg== X-Gm-Message-State: AOAM532HUCVYTd3b5fW0jYqQZzWbDcAVA9oxwQN0be/qbWX/OXQhtuUK biq3lJLqtJdn1+VlRPuXD38/kw+13ovbr0Vw X-Google-Smtp-Source: ABdhPJxaKXJycAdmb7LrKilxtiaow2TRtUO0zaWdpbYrmlTzwThwz9UTKtwFBfHxeSzo3oUhNtHZxg== X-Received: by 2002:a05:6214:17c1:: with SMTP id cu1mr5970674qvb.32.1605718400699; Wed, 18 Nov 2020 08:53:20 -0800 (PST) Received: from mithrandir.lan (c-24-91-177-160.hsd1.ma.comcast.net. [24.91.177.160]) by smtp.gmail.com with ESMTPSA id k4sm12860220qki.2.2020.11.18.08.53.19 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 18 Nov 2020 08:53:19 -0800 (PST) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_898DC835-255B-49B8-81E0-0663404D6716" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.21\)) Date: Wed, 18 Nov 2020 11:53:18 -0500 In-Reply-To: Cc: DNSSD To: Esko Dijk References: <5205F6F9-50B1-4785-A311-880B1FD0AC30@fugue.com> X-Mailer: Apple Mail (2.3654.40.0.2.21) Archived-At: Subject: Re: [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: Wed, 18 Nov 2020 16:53:25 -0000 --Apple-Mail=_898DC835-255B-49B8-81E0-0663404D6716 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Nov 3, 2020, at 6:32 AM, Esko Dijk = wrote: > Looking forward to the updated version =E2=80=93 I will review the = changes some time after you have posted it. Great, thanks. I may just put it up somewhere else, but it=E2=80=99s = easier if it=E2=80=99s in the datatracker. > And below further responses to your reply: > =20 > > Stuart and I discussed this at length with the author of that = document. It=E2=80=99s not as simple as it sounds. First, there are no = common set of parameters to publish in core RD, so any translation would = have to be based on heuristics. > > But Core RD and DNS-SD have fairly different core assumptions, and = as a consequence, there didn=E2=80=99t seem to be an obvious mapping. > =20 > Yes I recall from one of the authors that doing this mapping is hard, = if not impossible. In my view it might still work if we assume a limited = subset of DNS-SD semantics that can be mapped to a limited subset of = CoRE-RD semantics, and vice versa. (Under the assumption that this = still would be relevant for the applications/systems that would use = either DNS-SD or CoRE for their initial, basic service discovery=E2=80=A6)= As an example of a subset, the CoRE RD draft since -14 defines a = subset of the CoRE Link Format that it aims to support, given that the = full format was too complex for developers to get it right and even was = hard for the experts to agree on interpretation. So doing some = understandable subsets may be the only way =E2=80=93 or give up on the = idea. In the RD case the full Link Format can still be used but leads = to implementation-specific behavior of the RD in case statements are = used that go beyond the subset.=20 > > One problem is that DNS-SD has semantics, which Core RD doesn=E2=80=99= t. DNS-SD has a bit of free-form additional data in the form of the TXT = record, but most of the data is structured and is just about finding a = service. Core RD is a lot more general than that. > =20 > True; it would be interesting for me to learn these semantics and see = how they could map to CoRE Link Format. Because Link Format is = extendible (RFC 6690 , inherits Web Linking RFC 5988, which inherits = RDF, so new relation types with specific semantics can be freely = defined. ) this can be defined. > Vice versa some CoRE Link Format semantics would need to be removed in = the translation to DNS-SD probably, but the basic service discovery = aspect (in Link Format this is the =E2=80=9Chosts=E2=80=9D relation = type) could be at least attempted. The semantics of DNS-SD are detailed in RFC 6763. Briefly, services are = identified by service type, which is generally something like _hap._udp, = indicating both the service and transport. Services are discovered in = domains. For any given domain, the list of services of a particular type = can be found by querying for PTR records on the name .. Each PTR record points to a service instance: a specific = instance of the service being discovered. The target of the PTR record = is a name; on this name there should be an SRV record and possibly also = a TXT record. The SRV record=E2=80=99s target name should have one or = more A and AAAA records, which indicate which host to contact; the SRV = record has the port. The TXT record contains a list of name/value pairs, = so basically a dictionary. The data is just text=E2=80=94it=E2=80=99s = not typed. So when you get a service list, you choose a service from that list, and = then to resolve it you look up the service instance and the host = records. This gives you the information you need to contact the service = and possibly some information _about_ the service instance other than = the protocol it uses (that=E2=80=99s the service type). In order to map this into Core RD, I think you=E2=80=99d need a single = data structure for enumerating services, which could just be a = dictionary keyed by service type. For each type, there would be an array = of instance names. Instances would be looked up in a second dictionary, = with the instance name as key. For each instance, you=E2=80=99d have a = dictionary with at least three keys: hostname, port and parameters. = Parameters would be a dictionary with arbitrary key names, and each = datum would be a text string. And then you=E2=80=99d need a dictionary = keyed by hostname, each element of which would be an array of IP = addresses. To be honest, I=E2=80=99m not convinced that there=E2=80=99s much = utility than this. > > > The term =E2=80=9CSRP client=E2=80=9D is used, sometimes for the = registering service=E2=80=99s host and sometimes for a client using only = the service lookup function. > > > Is that correct? Should it be explained in a terminology section? = And we have also above DNS-SD registration protocol client. > > > Also =E2=80=9CSRP server=E2=80=9D vs =E2=80=9CSRP Server=E2=80=9D = are both used. > >=20 > > Fixed the latter. I didn=E2=80=99t find any instances of the = former=E2=80=94can you point me to one in the update? > =20 > Looking at the text (-05) again, I see that =E2=80=98client=E2=80=99, = =E2=80=98SRP client=E2=80=99 and =E2=80=98DNS-SD registration protocol = client=E2=80=99 are used for mostly the same concept =E2=80=93 the SRP = client publishing the service. The lookup aspect only appears in Section = 1 text > =E2=80=9COnce published, these services can be readily discovered by = clients using standard DNS lookups=E2=80=9D . Here it is clear that the = client is as a standard DNS client when doing this so no ambiguity. > In Section 3.2 I was thinking that the =E2=80=98client=E2=80=99 here = getting the response from the =E2=80=98DNS server=E2=80=99 must be a DNS = client because it did not say =E2=80=98SRP server=E2=80=99 here. We = could change here =E2=80=98DNS servers=E2=80=99 to =E2=80=98SRP = servers=E2=80=99 just to be clear. > (Because the lookup function is not described in this draft but in = other RFCs =E2=80=93 standard DNS-SD or mDNS queries etc =E2=80=93 the = possibility of confusion is currently minimal though.) I=E2=80=99m seeing it now. I=E2=80=99ve gone through and specifically = qualified each instance, and also clarified some text that talks about = updates from SRP clients and also from non-SRP DNS Update clients. =20 >=20 > > > 3.2 This says nothing about the SIG(0) validation required by the = SRP server. That seems strange, given the title? > > > Title could be changed to e.g. =E2=80=9Cvalidating SRP server = responses=E2=80=9D. And perhaps add some SIG(0) validation = considerations by the SRP server, if we have any. (E.g. avoid certain = algorithms? > > > Try only one or try multiple? Maybe the key already encodes the = used algorithm =E2=80=93 I didn=E2=80=99t look into that; in which case = there could be invalid algorithms or parameters specified etc.) > > > > It=E2=80=99s pointing out a limitation, so there=E2=80=99s no need = to mention the case where the limitation is not present. > =20 > What about changing the title for this section 3.2 to =E2=80=9CSRP = Server Response Validation=E2=80=9D ? That would fit the current text = best. > Forget what I said about the selection of SIG(0) algorithms because = that=E2=80=99s already in 3.3 I see. Probably authentication rather than validation, but yes, that makes = sense. I=E2=80=99ve updated. > > > The constrained devices would use UDP to register and also to = query for services possibly, so I would expect an = "_dnssd-srp._udp.." to be defined at least. > > > Even if on the constrained network there may be a custom way to = provide the host/port of the SRP server to nodes. After all it *might* = use DNS-SD format to distribute such information, or not? > > > Another consideration: if UDP is supported, then UDP+DTLS may be = too? Although that would severely increase the resource usage (power, = network bandwidth) of constrained devices perhaps we don=E2=80=99t want = to rule that out. > >=20 > > We=E2=80=99re assuming this is discovered using a network-specific = mechanism. > =20 > Agree; it will be network-specific and it may not involve a DNS-SD = description at all. E.g. just an IP address and a port configuration. = Some of these network-specific means may in the future use DNS-SD = descriptions to publish / =E2=80=98push=E2=80=99 available network = services to clients. > And one of these services may be a UDP-based SRP server where the = client can then choose to register. Then this description would use = "_dnssd-srp._udp.." , however this is not formally defined in = the IANA Service Names registry so the people doing this > would have to register that entry. That is still okay, though I = considered it better if the present draft would already formally reserve = the service name "_dnssd-srp._udp.." for this purpose just to be = complete. The assumption in the document is that if you can do DNS service = discovery, you can do the update using TLS+TCP. This assumption may be = unwarranted, but FWIW the only use case so far for SRP over UDP is on = Thread, and I really don=E2=80=99t want to make Thread clients go = through a series of DNS queries to identify the local browsing domain. = That said, we may want to rethink that=E2=80=94I=E2=80=99m not at all = sure that I have that right, particularly since we will probably be = using DNS-SD for off-mesh service discovery anyway. But the thing I = don=E2=80=99t want to have happen is for the UDP and TCP services to be = treated as interchangeable. =20 > Another argument why this is needed is the following: the present = draft says RFC 2136 is the way for the client to send its DNS updates to = the SRP server. And that defines both UDP and TCP. If we want to nudge = people towards using TCP and not UDP where possible, then=20 > this should be made explicit I think in Section 2.3.1 =E2=80=93 add a = bullet =E2=80=9CClients SHOULD/MUST use TCP=E2=80=9D. If UDP and TCP = are treated as equals as in RFC 2136 then I would assume both need to be = supported as well for the SRP server, potentially. > So is it intended that the non-constrained clients can only discover = the TCP-based SRP server, and not the UDP-based SRP server? If so then = only defining the TCP-based service description is enough. > Note: I=E2=80=99m assuming in the above that TCP/UDP based services of = SRP server are separately advertised in DNS-SD if both are present, but = I may be totally wrong here. If I=E2=80=99m wrong then please ignore = this argument. Yes, that=E2=80=99s the theory. :) > =20 > > Unless CoRE RD does something like FCFS naming, for instance, it = would likely be quite a bit more compact. > =20 > RD does have FCFS naming but =E2=80=93 because there is no default = security solution =E2=80=93 it is rather indirectly defined. RD draft = says that registering clients MUST use unique names and points to some = mechanisms for clients to generate random UUID names in case there first = attempt at registration with a name failed. > The case where no security is used becomes also tricky then; as the RD = server may be unable to distinguish a name-collision from a legitimate = client making a service update. The expectation there is that clients = will choose random / UUID names in that case to push the probability of = collision to 0%. (Doesn=E2=80=99t work against attackers.) > And RD=E2=80=99s Link Format can in some cases be rather inefficient = =E2=80=93 there=E2=80=99s now an effort to define a new binary format = CoRAL that could replace it. An RD could handle both Link Format and = CoRAL in principle. I think moving from name to identifier makes a fair amount of sense, as = long as there is a way to say what should be displayed in the UI. For = IoT devices you=E2=80=99re going to have dozens of light bulbs, as an = example, so it makes sense to have a type of light bulb rather than a = name of light bulb. --Apple-Mail=_898DC835-255B-49B8-81E0-0663404D6716 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Nov 3, 2020, at 6:32 AM, = Esko Dijk <esko.dijk@iotconsultancy.nl> wrote:
Looking forward to the updated version =E2=80=93 I = will review the changes some time after you have posted it. =

Great, thanks. = I may just put it up somewhere else, but it=E2=80=99s easier if it=E2=80=99= s in the datatracker.

And = below further responses to your reply:
 
> Stuart and I = discussed this at length with the author of that document. It=E2=80=99s = not as simple as it sounds. First, there are no common set of parameters = to publish in core RD, so any translation would have to be based on = heuristics.
 > = But Core RD and DNS-SD have fairly different core assumptions, and as a = consequence, there didn=E2=80=99t seem to be an obvious mapping.
 
Yes I recall from one of = the authors that doing this mapping is hard, if not impossible. In my = view it might still work if we assume a limited subset of DNS-SD = semantics that can be mapped to a limited subset of CoRE-RD semantics, = and vice versa.  (Under the assumption that this still would be = relevant for the applications/systems that would use either DNS-SD or = CoRE for their initial, basic service discovery=E2=80=A6)   As = an example of a subset, the CoRE RD draft since -14 defines a subset of = the CoRE Link Format that it aims to support, given that the full format = was too complex for developers to get it right and even was hard for the = experts to agree on interpretation. So doing some understandable subsets = may be the only way =E2=80=93 or give up on the idea.  In the RD = case the full Link Format can still be used but leads to = implementation-specific behavior of the RD in case statements are used = that go beyond the subset. 
> One problem is that DNS-SD has semantics, = which Core RD doesn=E2=80=99t. DNS-SD has a bit of free-form additional = data in the form of the TXT record, but most of the data is structured = and is just about finding a service. Core RD is a lot more general than = that.
 
True; it would be = interesting for me to learn these semantics and see how they could map = to CoRE Link Format. Because Link Format is extendible (RFC 6690 , = inherits Web Linking RFC 5988, which inherits RDF, so new relation types = with specific semantics can be freely defined. ) this can be = defined.
Vice = versa some CoRE Link Format semantics would need to be removed in the = translation to DNS-SD probably, but the basic service discovery aspect = (in Link Format this is the =E2=80=9Chosts=E2=80=9D relation type) could = be at least attempted.


The semantics of DNS-SD are detailed = in RFC 6763. Briefly, services are identified by service type, which is = generally something like _hap._udp, indicating both the service and = transport. Services are discovered in domains. For any given domain, the = list of services of a particular type can be found by querying for PTR = records on the name <service type>.<domain>. Each PTR record = points to a service instance: a specific instance of the service being = discovered. The target of the PTR record is a name; on this name there = should be an SRV record and possibly also a TXT record. The SRV = record=E2=80=99s target name should have one or more A and AAAA records, = which indicate which host to contact; the SRV record has the port. The = TXT record contains a list of name/value pairs, so basically a = dictionary. The data is just text=E2=80=94it=E2=80=99s not = typed.

So when you get a service list, you choose a = service from that list, and then to resolve it you look up the service = instance and the host records. This gives you the information you need = to contact the service and possibly some information _about_ the service = instance other than the protocol it uses (that=E2=80=99s the service = type).

In order to map this into Core RD, I think you=E2=80= =99d need a single data structure for enumerating services, which could = just be a dictionary keyed by service type. For each type, there would = be an array of instance names. Instances would be looked up in a second = dictionary, with the instance name as key. For each instance, you=E2=80=99= d have a dictionary with at least three keys: hostname, port and = parameters. Parameters would be a dictionary with arbitrary key names, = and each datum would be a text string. And then you=E2=80=99d need a = dictionary keyed by hostname, each element of which would be an array of = IP addresses.

To be honest, I=E2=80=99m not convinced that = there=E2=80=99s much utility than this.

>  > The term =E2=80=9CSRP client=E2=80= =9D is used, sometimes for the registering service=E2=80=99s host and = sometimes for a client using only the service lookup function.
> > Is that correct? = Should it be explained in a terminology section? And we have also above = DNS-SD registration protocol client.
> > Also =E2=80=9CSRP server=E2=80=9D vs = =E2=80=9CSRP Server=E2=80=9D are both used.
> 
> Fixed the latter. I = didn=E2=80=99t find any instances of the former=E2=80=94can you point me = to one in the update?
 
Looking at the text (-05) = again, I see that =E2=80=98client=E2=80=99, =E2=80=98SRP client=E2=80=99 = and =E2=80=98DNS-SD registration protocol client=E2=80=99 are used for = mostly the same concept =E2=80=93 the SRP client publishing the service. = The lookup aspect only appears in Section 1 text
=E2=80=9COnce published, = these services can be readily discovered by clients using standard DNS = lookups=E2=80=9D . Here it is clear that the client is as a standard DNS = client when doing this so no ambiguity.
In Section 3.2 I was thinking that the = =E2=80=98client=E2=80=99 here getting the response from the =E2=80=98DNS = server=E2=80=99 must be a DNS client because it did not say =E2=80=98SRP = server=E2=80=99 here. We could change here =E2=80=98DNS servers=E2=80=99 = to =E2=80=98SRP servers=E2=80=99 just to be clear.
(Because the lookup = function is not described in this draft but in other RFCs =E2=80=93 = standard DNS-SD or mDNS queries etc =E2=80=93 the possibility of = confusion is currently minimal though.)

I=E2=80=99m seeing it now. I=E2=80=99ve gone through = and specifically qualified each instance, and also clarified some text = that talks about updates from SRP clients and also from non-SRP DNS = Update clients.
 
> > 3.2 This says nothing about the SIG(0) = validation required by the SRP server. That seems strange, given the = title?
> > Title = could be changed to e.g. =E2=80=9Cvalidating SRP server = responses=E2=80=9D.  And perhaps add some SIG(0) validation = considerations by the SRP server, if we have any. (E.g. avoid certain = algorithms?
 > = > Try only one or try multiple? Maybe the key already encodes the = used algorithm =E2=80=93 I didn=E2=80=99t look into that; in which case = there could be invalid algorithms or  parameters specified = etc.)
>
> It=E2=80=99s pointing = out a limitation, so there=E2=80=99s no need to mention the case where = the limitation is not present.
 
What about changing the title for this section = 3.2 to =E2=80=9CSRP Server Response Validation=E2=80=9D ?  That = would fit the current text best.
Forget what I said about the selection of SIG(0) = algorithms because that=E2=80=99s already in 3.3 I = see.

Probably = authentication rather than validation, but yes, that makes sense. I=E2=80=99= ve updated.

> = > The constrained devices would use UDP to register and also to query = for services possibly, so I would expect an = "_dnssd-srp._udp.<domain>." to be defined at least.
> > Even if on the = constrained network there may be a custom way to provide the host/port = of the SRP server to nodes.  After all it *might* = use DNS-SD format to distribute such information, or not?
> > Another = consideration: if UDP is supported, then UDP+DTLS may be too?  = Although that would severely increase the resource usage (power, network = bandwidth) of constrained devices perhaps we don=E2=80=99t want to rule = that out.
> 
> We=E2=80=99re = assuming this is discovered using a network-specific mechanism.
 
Agree; it will be = network-specific and it may not involve a DNS-SD description at all. = E.g. just an IP address and a port configuration. Some of these = network-specific means may in the future use DNS-SD descriptions to = publish / =E2=80=98push=E2=80=99 available network services to = clients.
And one = of these services may be a UDP-based SRP server where the client can = then choose to register. Then this description would use = "_dnssd-srp._udp.<domain>."  , however this is not formally = defined in the IANA Service Names registry so the people doing this
would have to register = that entry.  That is still okay, though I considered it better if = the present draft would already formally reserve the service name = "_dnssd-srp._udp.<domain>." for this purpose just to be = complete.

The = assumption in the document is that if you can do DNS service discovery, = you can do the update using TLS+TCP. This assumption may be unwarranted, = but FWIW the only use case so far for SRP over UDP is on Thread, and I = really don=E2=80=99t want to make Thread clients go through a series of = DNS queries to identify the local browsing domain. That said, we may = want to rethink that=E2=80=94I=E2=80=99m not at all sure that I have = that right, particularly since we will probably be using DNS-SD for = off-mesh service discovery anyway. But the thing I don=E2=80=99t want to = have happen is for the UDP and TCP services to be treated as = interchangeable.
 
Another argument why this is needed is the = following: the present draft says RFC 2136 is the way for the client to = send its DNS updates to the SRP server. And that defines both UDP and = TCP. If we want to nudge people towards using TCP and not UDP where = possible, then 
this should be made = explicit I think in Section 2.3.1 =E2=80=93 add a bullet =E2=80=9CClients = SHOULD/MUST use TCP=E2=80=9D.  If UDP and TCP are treated as equals = as in RFC 2136 then I would assume both need to be supported as well for = the SRP server, potentially.
So is it intended that the non-constrained = clients can only discover the TCP-based SRP server, and not the = UDP-based SRP server? If so then only defining the TCP-based service = description is enough.
Note: = I=E2=80=99m assuming in the above that TCP/UDP based services of SRP = server are separately advertised in DNS-SD if both are present, but I = may be totally wrong here. If I=E2=80=99m wrong then please ignore this = argument.

Yes, = that=E2=80=99s the theory. :)

 
> Unless CoRE RD does = something like FCFS naming, for instance, it would likely be quite a bit = more compact.
 
RD does have FCFS naming = but =E2=80=93 because there is no default security solution =E2=80=93 it = is rather indirectly defined.  RD draft says that registering = clients MUST use unique names and points to some mechanisms for clients = to generate random UUID names in case there first attempt at = registration with a name failed.
The case where no security is used becomes also = tricky then; as the RD server may be unable to distinguish a = name-collision from a legitimate client making a service update. The = expectation there is that clients will choose random / UUID names in = that case to push the probability of collision to 0%. (Doesn=E2=80=99t = work against attackers.)
And = RD=E2=80=99s Link Format can in some cases be rather inefficient =E2=80=93= there=E2=80=99s now an effort to define a new binary format CoRAL that = could replace it.  An RD could handle both Link Format and CoRAL in = principle.

I think moving = from name to identifier makes a fair amount of sense, as long as there = is a way to say what should be displayed in the UI. For IoT devices = you=E2=80=99re going to have dozens of light bulbs, as an example, so it = makes sense to have a type of light bulb rather than a name of light = bulb.

= --Apple-Mail=_898DC835-255B-49B8-81E0-0663404D6716-- From nobody Wed Nov 18 13:39:46 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 21DDB3A0D2C for ; Wed, 18 Nov 2020 13:39:45 -0800 (PST) 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, NO_DNS_FOR_FROM=0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01] autolearn=no 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 hB2a2f5BjPTJ for ; Wed, 18 Nov 2020 13:39:43 -0800 (PST) Received: from mail-qv1-xf35.google.com (mail-qv1-xf35.google.com [IPv6:2607:f8b0:4864:20::f35]) (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 415593A0D2B for ; Wed, 18 Nov 2020 13:39:42 -0800 (PST) Received: by mail-qv1-xf35.google.com with SMTP id v20so1838982qvx.4 for ; Wed, 18 Nov 2020 13:39:42 -0800 (PST) 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=NDu6IAOMZXCFOrqW9PlVNQ1zmHzZAQCYk/t9Cua3oAg=; b=AeUUhqprknHsuNJI9gJ8l+3ET362YD7TEWGHUPG5AVHkuwsFV3b6HbEgbV5dzvxda7 PKbO/wGDCz8fjK282wJwyGDcjmx86hv/chfgfa5PwQrNkISbLvJCMKJAY+yOjtvfnxzp tNFAatvm5tis4Nc2yhadRimPCXqu6dOu1Na/eYXloyCJSCWr5ur3pqoyUjpPxLat+6w0 gY9wv/k0/duK31wMFqLRORFBiErQIEvvsW7op9JhdJazu1qHTxXkGfohJEVLvUNiTwLx jp+t7Yjh0eGocMQZyelxlr0SXviO13U66YhJscB4o29UYkxJ04O0gesBvK6lAaUlmcdW EEQA== 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=NDu6IAOMZXCFOrqW9PlVNQ1zmHzZAQCYk/t9Cua3oAg=; b=MqXGObLmIRq3AyVsMYBAAV/1+WoF3LtcNF/JcHYS18r3cX7VRTNi7MruwtY6EwKrbE GAou4UuJZSle4pHclqgFp0eyyhnicED/ZlqDTuA9l5Hg6ywYe9kVuFaq/xzUXiGHO3pa 6ETjqCAibkSYw6PwnyWBV4vClWymrinRE741p5yz2L+NnUdeWEGpJnMubf/69TAFlXCJ pNkBI2v4NEnqnpJ4Ou8fFhbIQgG/FAc+5bRQmmWWEwNGRI4l1oKN25XAoWBxm/I6Xg1Z v8H8IqaSEw9wB3j0WPhCaK3H6hEPrRMK2+FBUzb/GofIkToAFo+fNMZ7xV0Dvox1Qe4t pq7A== X-Gm-Message-State: AOAM532G77gOv32aYRtU5CwCyIrocJAaPeFnYjZXLFS+YLj3Qw848iUZ FAayLQFxYAS8VZxcs4QdJ3nzCxEg8NTz8/WA X-Google-Smtp-Source: ABdhPJy/f58BlXjlkMSAADth7+d89lc+yV2XuMFXaPLttzIuDot3h4AdNnIB1uTHfNRdgQo7N19wXw== X-Received: by 2002:a05:6214:32f:: with SMTP id j15mr7441614qvu.35.1605735582033; Wed, 18 Nov 2020 13:39:42 -0800 (PST) Received: from mithrandir.lan (c-24-91-177-160.hsd1.nh.comcast.net. [24.91.177.160]) by smtp.gmail.com with ESMTPSA id t205sm7379116qke.35.2020.11.18.13.39.40 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 18 Nov 2020 13:39:40 -0800 (PST) From: Ted Lemon Message-Id: <843154D5-2D1A-4CD6-9922-64B01FA2DC1A@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_CBBF5A56-D901-4E8E-8372-7027D8ECB1B3" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.21\)) Date: Wed, 18 Nov 2020 16:39:39 -0500 In-Reply-To: Cc: dnssd@ietf.org To: Manuel Amutio References: X-Mailer: Apple Mail (2.3654.40.0.2.21) Archived-At: Subject: Re: [dnssd] Review of draft-ietf-dnssd-srp-05 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 Nov 2020 21:39:45 -0000 --Apple-Mail=_CBBF5A56-D901-4E8E-8372-7027D8ECB1B3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thank you for the comments, Manuel! > /------------- Typos --------------/ > Page 9, first paragraph: > "This key pair MUST be unique to the device" is repeated twice. > "+" symbol appears twice. What I get for manually applying a diff=E2=80=94thanks for catching it! = :) > Page 12, second paragraph: > "Instrructions" Got it. > /------------- Doubts -------------/ > Page 9, section 2.4.1.1 Service Behavior: > "the key MAY be overwritten as a result of a full reset of the device = (e.g., a "factory reset")" >=20 > What happens then? Good question. I=E2=80=99ve clarified: When the device changes ownership, it may be appropriate to erase the = old key and install a new one. Therefore the key MAY be overwritten as a = result of a full reset of the device (e.g., a "factory reset=E2=80=9D) >=20 > Page 10, section 2.4.2 Removing published services: > "To remove a service registration, the client retransmits its most = recent update..."=20 > "However, in some cases a client may not have retained sufficient = state to know that some service instance is pointing to a host that it = is removing." >=20 > Then, how is it able to retransmit an update of something that no = longer knows?=20 The notion is that an SRP update with just the host information, and = with a lease time of zero, will remove all services advertised by that = host, even if the SRP client doesn=E2=80=99t enumerate them in the = update. I=E2=80=99ve re-written the text in this paragraph as follows: SRP clients are normally expected to remove all service instances when = removing a host. However, in some cases a SRP client may not have = retained sufficient state to know that some service instance is pointing = to a host that it is removing. An SRP server can assume that all = service instances pointing to a host entry that's being removed are no = longer valid. Therefore, SRP servers MAY remove all service instances = pointing to a host when a host is removed, even if the SRP client = doesn't remove them explicitly. > Page 15, section 2.6.2. Sleep Proxy: > This feature conditions the location of SRP Server, right? > If we thought in a Border Router, it would only be useful for external = traffic going through BR, but not for traffic initiated in the mesh = network.=20 > Maybe I have misunderstood it. Bear in mind that SRP is a general protocol specification, and stub = routers, like the Thread border router, are individual use cases. I = don=E2=80=99t think there=E2=80=99s any value in implementing sleep = proxy service for a Thread border router=E2=80=94Thread already has its = own way of handling sleepy end devices. > Regarding the protocol used, I don't see a clear drawback to not allow = using UDP for the constrained devices. If the DNS service allows it, I = believe that this new protocol should support it too. I also think it makes sense to use UDP for SRP registrations. Anyway, thanks for the comments, I will be updating the draft to address = your and Esko=E2=80=99s comments, as well as Jonathan=E2=80=99s comments = that followed my previous update, shortly. :) --Apple-Mail=_CBBF5A56-D901-4E8E-8372-7027D8ECB1B3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Thank= you for the comments, Manuel!

/------------- Typos = --------------/
Page 9, first paragraph:
= "This key pair MUST be unique to the device" is repeated twice.
"+" symbol appears twice.

What = I get for manually applying a diff=E2=80=94thanks for catching it! = :)

Page 12, second = paragraph:
"Instrructions"

Got = it.

/------------- = Doubts -------------/
Page 9, section 2.4.1.1 = Service Behavior:
"the key MAY be overwritten as a = result of a full reset of the device (e.g., a "factory reset")"

What happens = then?

Good question. I=E2=80=99ve clarified:

When the device changes ownership, it may be = appropriate to erase the old key and install a new one. Therefore the = key MAY be overwritten as a result of a full reset of the device (e.g., = a "factory reset=E2=80=9D)


Page 10, section 2.4.2 Removing published = services:
"To remove a service registration, the = client retransmits its most recent update..."
= "However, in some cases a client may not have retained sufficient state = to know that some service instance is pointing to a host that it is = removing."

Then, how is it able to = retransmit an update of something that no longer knows?

The = notion is that an SRP update with just the host information, and with a = lease time of zero, will remove all services advertised by that host, = even if the SRP client doesn=E2=80=99t enumerate them in the = update.

I=E2=80=99ve re-written the = text in this paragraph as follows:

SRP clients are = normally expected to remove all service instances when removing a host. =  However, in some cases a SRP client may not have retained = sufficient state to know that some service instance is pointing to a = host that it is removing.  An SRP server can assume that all = service instances pointing to a host entry that's being removed are no = longer valid.  Therefore, SRP servers MAY remove all service = instances pointing to a host when a host is removed, even if the SRP = client doesn't remove them explicitly.

Page 15, section = 2.6.2. Sleep Proxy:
This feature conditions the = location of SRP Server, right?
If we thought in a = Border Router, it would only be useful for external traffic going = through BR, but not for traffic initiated in the mesh = network. 
Maybe I have misunderstood = it.

Bear in mind = that SRP is a general protocol specification, and stub routers, like the = Thread border router, are individual use cases. I don=E2=80=99t think = there=E2=80=99s any value in implementing sleep proxy service for a = Thread border router=E2=80=94Thread already has its own way of handling = sleepy end devices.

Regarding the protocol used, I don't see a clear drawback to = not allow using UDP for the constrained devices. If the DNS = service allows it, I believe that this new protocol should support it = too.

I also = think it makes sense to use UDP for SRP registrations.

Anyway, thanks for the comments, I will = be updating the draft to address your and Esko=E2=80=99s comments, as = well as Jonathan=E2=80=99s comments that followed my previous update, = shortly. :)

= --Apple-Mail=_CBBF5A56-D901-4E8E-8372-7027D8ECB1B3-- From nobody Wed Nov 18 13:47:36 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 61EF33A0D40; Wed, 18 Nov 2020 13:47:31 -0800 (PST) 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.23.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dnssd@ietf.org Message-ID: <160573605134.22535.15610395002207257379@ietfa.amsl.com> Date: Wed, 18 Nov 2020 13:47:31 -0800 Archived-At: Subject: [dnssd] I-D Action: draft-ietf-dnssd-srp-06.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: Wed, 18 Nov 2020 21:47:32 -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-06.txt Pages : 27 Date : 2020-11-18 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 is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-dnssd-srp-06.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnssd-srp-06 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 Nov 19 02:15:14 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 8055D3A142C for ; Thu, 19 Nov 2020 02:15:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.118 X-Spam-Level: X-Spam-Status: No, score=-1.118 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_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kirale-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 Pnhu93k_dx7T for ; Thu, 19 Nov 2020 02:15:07 -0800 (PST) Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com [IPv6:2a00:1450:4864:20::634]) (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 C57B23A13E2 for ; Thu, 19 Nov 2020 02:15:02 -0800 (PST) Received: by mail-ej1-x634.google.com with SMTP id y17so7068613ejh.11 for ; Thu, 19 Nov 2020 02:15:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kirale-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mH8/SRm3AhVAULNwS7gn2nBtV2ft9U2oictW6qvfwfo=; b=RDoRGPQ8jbhj+JDRjC31CEE/s4tyxWOZELNkLhGDS2HXSQ6xM0aDHaPRUfPme2ZJAN WwGt+WiWuMFgIX+RBQD0xa4UuHpRKHJrDeK4Xf58oyXWj2PgGo78hcSm2wewMzY44Kes TBNCspr3Ukh4xW7LWzMXjGdLwvQUPxJjOXUjAaj43tb+lgf12Grtkc8wG6iJcTHV9SDD ilwngaGrlSC540MaASxdJl/qVeaFnx95vImhTqWjhkMy/86tfO+cwK/lyb0zAFI1xLhr xwq0/o3OQ0A3MpoC6UvEFg2rrZGnKf8uLt4/HtRvjm7AbV/3z7iY726baMiBfq00twW1 7FbA== 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=mH8/SRm3AhVAULNwS7gn2nBtV2ft9U2oictW6qvfwfo=; b=mT4ORz9CWh0YXzewgRFWWsTiGuO3pAaYbLAA2GZNLCx6/hls5407frskjTSoOocGGk DBga8XnI6BmHvW61GH3pMDePLS6Jaw1pqC3ENaT/2ryGa6P6hEY+G2a3cXSYuHfbgUh6 FuLE4VQIU8Yd6/w3e0DdcXIV9qGkIDRfCHdXq7onf/a9J/XQbiSYCMdjMbSlGOMIu9qQ kY0AmnCZoV+8SkX0somqiDddmISCFduXOf43kWcbfhYhljfN4wYLJ6l7zsELKn1nSly4 oP+wemkVDZt8AIwyswO55mxw5lWZePlGu/GtBsm8Ac3EaUh55UEpew/6r0C1pA2HTYEF ++ow== X-Gm-Message-State: AOAM531Z+HNWB5Jq695E4v6C8Q335EplfgWUpOufx2QITUkMI6vCs7pA hvx67HxLclAUMFSTr6BiWYDH4Pt7XIjKAMkuX/RVjw== X-Google-Smtp-Source: ABdhPJxfiG+gVXL8e98ZblJNxjUmWUUHZ+Ufvp5WH5owOmGABis5oNTWXbm9kavYwZQiCbIr91eIG8O5fyXEvCsbEMU= X-Received: by 2002:a17:906:90c7:: with SMTP id v7mr4880877ejw.236.1605780901098; Thu, 19 Nov 2020 02:15:01 -0800 (PST) MIME-Version: 1.0 References: <843154D5-2D1A-4CD6-9922-64B01FA2DC1A@fugue.com> In-Reply-To: <843154D5-2D1A-4CD6-9922-64B01FA2DC1A@fugue.com> From: Manuel Amutio Date: Thu, 19 Nov 2020 11:14:50 +0100 Message-ID: To: Ted Lemon Cc: dnssd@ietf.org Content-Type: multipart/alternative; boundary="000000000000328fd905b47300c4" Archived-At: Subject: Re: [dnssd] Review of draft-ietf-dnssd-srp-05 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 Nov 2020 10:15:12 -0000 --000000000000328fd905b47300c4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for the clarifications Ted. Regarding my first doubt, I still fail to understand how a device which has lost its security material, for instance after a factory reset, could then claim its right to dispose (remove or update) of the service that was created before. I understand that, under such circumstances, the device will use another security material to create a new service which has not to do with the first one and thus, the first service will be removed by the server when its lifetime has expired, right? Best, Manuel El mi=C3=A9., 18 nov. 2020 a las 22:39, Ted Lemon () escr= ibi=C3=B3: > Thank you for the comments, Manuel! > > /------------- Typos --------------/ > Page 9, first paragraph: > "This key pair MUST be unique to the device" is repeated twice. > "+" symbol appears twice. > > > What I get for manually applying a diff=E2=80=94thanks for catching it! := ) > > Page 12, second paragraph: > "Instrructions" > > > Got it. > > /------------- Doubts -------------/ > Page 9, section 2.4.1.1 Service Behavior: > "the key MAY be overwritten as a result of a full reset of the device > (e.g., a "factory reset")" > > What happens then? > > > Good question. I=E2=80=99ve clarified: > > When the device changes ownership, it may be appropriate to erase the old > key and install a new one. Therefore the key MAY be overwritten as a resu= lt > of a full reset of the device (e.g., a "factory reset=E2=80=9D) > > > Page 10, section 2.4.2 Removing published services: > "To remove a service registration, the client retransmits its most recent > update..." > "However, in some cases a client may not have retained sufficient state t= o > know that some service instance is pointing to a host that it is removing= ." > > Then, how is it able to retransmit an update of something that no longer > knows? > > > The notion is that an SRP update with just the host information, and with > a lease time of zero, will remove all services advertised by that host, > even if the SRP client doesn=E2=80=99t enumerate them in the update. > > I=E2=80=99ve re-written the text in this paragraph as follows: > > SRP clients are normally expected to remove all service instances when > removing a host. However, in some cases a SRP client may not have retain= ed > sufficient state to know that some service instance is pointing to a host > that it is removing. An SRP server can assume that all service instances > pointing to a host entry that's being removed are no longer valid. > Therefore, SRP servers MAY remove all service instances pointing to a hos= t > when a host is removed, even if the SRP client doesn't remove them > explicitly. > > > Page 15, section 2.6.2. Sleep Proxy: > This feature conditions the location of SRP Server, right? > If we thought in a Border Router, it would only be useful for external > traffic going through BR, but not for traffic initiated in the mesh > network. > Maybe I have misunderstood it. > > > Bear in mind that SRP is a general protocol specification, and stub > routers, like the Thread border router, are individual use cases. I don= =E2=80=99t > think there=E2=80=99s any value in implementing sleep proxy service for a= Thread > border router=E2=80=94Thread already has its own way of handling sleepy e= nd devices. > > Regarding the protocol used, I don't see a clear drawback to not allow > using UDP for the constrained devices. If the DNS service allows it, I > believe that this new protocol should support it too. > > > I also think it makes sense to use UDP for SRP registrations. > > Anyway, thanks for the comments, I will be updating the draft to address > your and Esko=E2=80=99s comments, as well as Jonathan=E2=80=99s comments = that followed my > previous update, shortly. :) > > --000000000000328fd905b47300c4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for the clarifications Ted.

Regarding = my first doubt,=C2=A0I still fail to understand how a device which has lost= its security material,=20 for instance after a factory reset, could then claim its right to dispose (= remove or=C2=A0update) of the service that was created before.
I understand that, under such=C2=A0circumstances, the device w= ill use another security material to create a new service which has not to = do with the first one and thus, the first service will be removed by the se= rver when its lifetime has=C2=A0expired, right?

Be= st,
Manuel


El mi=C3=A9., 18 nov. 2020 a= las 22:39, Ted Lemon (<mellon@fugue= .com>) escribi=C3=B3:
Thank you for the co= mments, Manuel!

/------------- Typos --------------/
Page 9, first paragraph:
= "This key pair MUST be unique to the device" is repeated twice.<= br> "+" symbol appears twice.
<= div>
What I get for manually applying a diff=E2=80=94thanks for ca= tching it! :)

Page 12, second paragraph:
"Instrructions"

Got it.

/------------- Doubts -------------/
Page 9, section 2.4.1.1 Service Behavior:
"the key MAY be= overwritten as a result of a full reset of the device (e.g., a "facto= ry reset")"

What happens then?
=

Good question. I=E2=80=99ve clarified:

When the device changes ownership, it may be ap= propriate to erase the old key and install a new one. Therefore the key MAY= be overwritten as a result of a full reset of the device (e.g., a "fa= ctory reset=E2=80=9D)


Page 10, section 2.4.2 Removing published services:=
"To remove a service registration, the client retransmits its mos= t recent update..."
"However, in some cases a client may not= have retained sufficient state to know that some service instance is point= ing to a host that it is removing."

Then, how is it abl= e to retransmit an update of something that no longer knows?

The notion is that an SRP update with j= ust the host information, and with a lease time of zero, will remove all se= rvices advertised by that host, even if the SRP client doesn=E2=80=99t enum= erate them in the update.

I=E2=80=99ve re-written = the text in this paragraph as follows:

SRP c= lients are normally expected to remove all service instances when removing = a host.=C2=A0 However, in some cases a SRP client may not have retained suf= ficient state to know that some service instance is pointing to a host that= it is removing.=C2=A0 An SRP server can assume that all service instances = pointing to a host entry that's being removed are no longer valid.=C2= =A0 Therefore, SRP servers MAY remove all service instances pointing to a h= ost when a host is removed, even if the SRP client doesn't remove them = explicitly.

Page 15, section 2.6.2. Sleep Proxy:
This f= eature conditions the location of SRP Server, right?
If we though= t in a Border Router, it would only be useful for external traffic going th= rough BR, but not for traffic initiated=C2=A0in the mesh network.=C2=A0
Maybe I have misunderstood it.
Bear in mind that SRP is a general protocol specification, and stub= routers, like the Thread border router, are individual use cases. I don=E2= =80=99t think there=E2=80=99s any value in implementing sleep proxy service= for a Thread border router=E2=80=94Thread already has its own way of handl= ing sleepy end devices.

Regarding the protocol used, I don't see a clear drawba= ck to not=C2=A0allow using UDP for the=C2=A0constrained devices. If the DNS= service allows it, I believe that this new protocol should support it too.=

I also think it makes sense t= o use UDP for SRP registrations.

Anyway, thanks for the= comments, I will be updating the draft to address your and Esko=E2=80=99s = comments, as well as Jonathan=E2=80=99s comments that followed my previous = update, shortly. :)

--000000000000328fd905b47300c4-- From nobody Thu Nov 19 02:43:17 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 12AB73A13E9 for ; Thu, 19 Nov 2020 02:43:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.886 X-Spam-Level: X-Spam-Status: No, score=-1.886 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NO_DNS_FOR_FROM=0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no 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 WTVYddVrV_Kn for ; Thu, 19 Nov 2020 02:43:14 -0800 (PST) Received: from mail-il1-x12c.google.com (mail-il1-x12c.google.com [IPv6:2607:f8b0:4864:20::12c]) (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 652AB3A13E8 for ; Thu, 19 Nov 2020 02:43:14 -0800 (PST) Received: by mail-il1-x12c.google.com with SMTP id h6so4889432ilj.8 for ; Thu, 19 Nov 2020 02:43:13 -0800 (PST) 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=yeJ/41RCScgeFNBLja7zZ6m6HR4XgHC+ULNYAHEyi0c=; b=INpqMEJhJ1zy3TeuM/t3AzFWiLrM7Fs78dKOsLGzjhonMHMmFgFvceomz05a1OM9wN uLVwELWyekad9sh9jgAiKIo7VcCvuhGJjQr9Um5NnanKhHeu/FMAJFtMvRuO4h9yfMa2 iLpXhsdnAqE6Gm9jXDLgIGjEZU9msUA/RYS9AI1vFmxswnGiSRMxMaoEHZ8sSX4u+McP ptMtzxZ2V+iVtUuI0ZYGGkPaqx5j3A01flvtzufqxSCuHMcMp6quj9zgQHwdG+Xh0mrK cxD4YMMajAEFhgsyKFk9rtmScgNwn/+yKEPlTsnGMBxHKLLnrh+7ogesk7q4cRz3Ek5m AsFw== 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=yeJ/41RCScgeFNBLja7zZ6m6HR4XgHC+ULNYAHEyi0c=; b=q3TbLzf3BEzP5PvXJbcUBEL+KBzJ/97UxjU/zvxA2Ogy0aHDQdOujZwOq+yMvIc9B0 SqPGu+AYSGszI+iE17FoA4ViPmCcCGCXV15HgLQ3nL0mC4y8vGGGZQHICsA0zIDD9vMX mhZuqVwgsBA3cxAhQwoovPAgNGJvlWA5IEsWYd2R51987yThEEdvvM7Ik+zvdP805fSz llei78SAWQzAF+jLfdR7wG+WLr/G3+42w43ACl/Cb+CTaGbDT35ylmk/nCqRm2goleMX TFzGl2dxKQUFOa6MiKgg9fW5gAcwhfA2n/7lh9nE/iC6a0DiQ0XSZgjgsh7gGi7VVBuQ OFWg== X-Gm-Message-State: AOAM53173JbssMDr6Do4L517O1JPKzpfPmkWm0e3w62cZkqeqvdDIMXA CY6e17SMuE9gez6XUJe5VkHvGQ== X-Google-Smtp-Source: ABdhPJyp+EzMbNfGhQIS910yKzIvkJWaQSobi0wjGJqk+V/7DlePef1AmSBW1Gws4+ChcYjEo5OGfQ== X-Received: by 2002:a92:dc02:: with SMTP id t2mr21173560iln.82.1605782593221; Thu, 19 Nov 2020 02:43:13 -0800 (PST) Received: from mithrandir.lan (c-24-91-177-160.hsd1.nh.comcast.net. [24.91.177.160]) by smtp.gmail.com with ESMTPSA id i14sm17502208ilb.2.2020.11.19.02.43.12 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Nov 2020 02:43:12 -0800 (PST) From: Ted Lemon Message-Id: <693293B1-04A9-4F6C-AA0A-BE5F1A099BD4@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_CFFE8DC4-F4C4-417D-98A6-A77BBC64A594" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.21\)) Date: Thu, 19 Nov 2020 05:43:11 -0500 In-Reply-To: Cc: dnssd@ietf.org To: Manuel Amutio References: <843154D5-2D1A-4CD6-9922-64B01FA2DC1A@fugue.com> X-Mailer: Apple Mail (2.3654.40.0.2.21) Archived-At: Subject: Re: [dnssd] Review of draft-ietf-dnssd-srp-05 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 Nov 2020 10:43:16 -0000 --Apple-Mail=_CFFE8DC4-F4C4-417D-98A6-A77BBC64A594 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Nov 19, 2020, at 5:14 AM, Manuel Amutio wrote: > Regarding my first doubt, I still fail to understand how a device = which has lost its security material, for instance after a factory = reset, could then claim its right to dispose (remove or update) of the = service that was created before. It can=E2=80=99t, and the document doesn=E2=80=99t suggest that it can. The expectation is that this would be done when the ownership of the = object changes, so that it would be deployed in a different context = where the name it claimed would not be used. --Apple-Mail=_CFFE8DC4-F4C4-417D-98A6-A77BBC64A594 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Nov 19, 2020, at 5:14 AM, Manuel Amutio <mamutio@kirale.com> = wrote:
Regarding my first doubt, I = still fail to understand how a device which has lost its security = material, for instance after a factory reset, could then claim its right = to dispose (remove or update) of the service that was created = before.

It can=E2=80=99t= , and the document doesn=E2=80=99t suggest that it can.

The expectation is that this would be done when = the ownership of the object changes, so that it would be deployed in a = different context where the name it claimed would not be = used.


= --Apple-Mail=_CFFE8DC4-F4C4-417D-98A6-A77BBC64A594-- From nobody Thu Nov 19 03:22:18 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 237BA3A0977 for ; Thu, 19 Nov 2020 03:22:17 -0800 (PST) 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 RXbZAZiVWum0 for ; Thu, 19 Nov 2020 03:22:14 -0800 (PST) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2109.outbound.protection.outlook.com [40.107.21.109]) (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 5CC053A0975 for ; Thu, 19 Nov 2020 03:22:13 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=deZC9Dq3dcjjuGjGVyl/dM4ax6BelzaJv2lLE1oNzeHPmH40Q8oTRgTzFmBxgBqjk5o8JB005oOqhi004wjZCVshtLSYlTFpRE7cSJ5rgy3ZhTJFfNRVfVPUoOJV57Lz7voadH7shgJBQCiF5LrLN9nZaQOT4yz6eyaw9w/inwHxsmSRLp/6uarPq4H7F/Lwp3gP66gv3QeFctx1jLzxvYrRrqOQzoy75kiTqJ6AV2LNf45Bkv+0D25xILFlKuSRRrE/DpJzzwVSawhGGQJDpafs7QXdD6WW+3KUGOjfTCw0w+2//xc5Sdlu9wsMkzN3WufP5/T5rg7Wc83zGnSGBg== 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=uwRbpn1pyaUv+2VxOtAEHJgPXEgd1sHFbLt+HGgSUog=; b=jKiB42ygVB7dKHdGHV4kZBOjJususwko0EFKQT+dNXTWzh+Q3/ULHcYzPzU2N6yCdj7QrSz9lavUOWxBlIomiUCu0Nmy22WrvXULJQribjzpRD1LSSHwu5Z9UhAE3q1ZqcZ8PZc8cISHrCIbq0P0/V0t/2R8tA8gvyTptBjmdc1INMvQ2iKZhrjCM/9hLreO5CtdL2e9kF6V92o1QIfbqD4E48vB9VBcsbcVnfv1PcDEJxEw5ZfT636RDwz+ZfxTegyxjRdWLbd1qULAu8Xw8YGdqbZg6h9v5y5HM8KXDlR0lSzZ812Erw3KFvQl+W5IGetSh3IDib2KrYI1PxtafQ== 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=uwRbpn1pyaUv+2VxOtAEHJgPXEgd1sHFbLt+HGgSUog=; b=yxe9N83JTx3cHFJ3AOTUtl+umYBjBcQPWGWSbxdDE9HzwrLf4oi/zsL+34nEj6DJJzJR9214OrmKs6csf7viBdQZR8OK+YJCVjDLkadKRmJHrGD9bY0yIMag87HT+ZXxjLd4AFsyqxUNyH61cCsyENtu7iJceKc2kuvOlAwuUjI= Received: from AM8P190MB0979.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:1d3::8) by AM4P190MB0178.EURP190.PROD.OUTLOOK.COM (2603:10a6:200:62::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3589.22; Thu, 19 Nov 2020 11:22:10 +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.3589.021; Thu, 19 Nov 2020 11:22:10 +0000 From: Esko Dijk To: Ted Lemon , Manuel Amutio CC: "dnssd@ietf.org" Thread-Topic: [dnssd] Review of draft-ietf-dnssd-srp-05 Thread-Index: AQHWtgxfaHtCkbQClkW8r+5qwWox9qnOeomAgADS/wCAAAfsgIAACLtw Date: Thu, 19 Nov 2020 11:22:10 +0000 Message-ID: References: <843154D5-2D1A-4CD6-9922-64B01FA2DC1A@fugue.com> <693293B1-04A9-4F6C-AA0A-BE5F1A099BD4@fugue.com> In-Reply-To: <693293B1-04A9-4F6C-AA0A-BE5F1A099BD4@fugue.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: fugue.com; dkim=none (message not signed) header.d=none;fugue.com; dmarc=none action=none header.from=iotconsultancy.nl; x-originating-ip: [2001:1c02:3103:f000:359f:a59d:3362:237] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 66c08c93-667c-4484-5733-08d88c7d5b40 x-ms-traffictypediagnostic: AM4P190MB0178: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: hXtZQ7yfoc8icrrmpVTAFl0NrM/bWEtZ9SCZaikLZbSkO/7qmx3SKuTYlokux8yft8fn0vei913o6awG4QH4D66psNmp9w60bemSjfdeDJk4Te0sUctgbDZZvELrcMkBNqR08KLVdTePXN/w7PFUQ1MELa8hd/N+0Hw+Y5bRSY9qRsJTb8Z4Abu8N8VV4+2Y0phTMqhCbxg94XkUMLXUsuJRWROW9xOU7SIve7fRe7PfLd2nRRVIs6xTvIwnzgqAssRyfOkrOltCe0Rgqwd8q2RtAeeTNWhnLXIScDUxhAtg8ygJC/Fet7NpPc8yci9VC0ZhaKAN6XoKpg/43yOxbg== 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)(346002)(396003)(376002)(136003)(508600001)(52536014)(71200400001)(316002)(6506007)(53546011)(8676002)(110136005)(8936002)(66446008)(66946007)(66556008)(64756008)(66476007)(2906002)(5660300002)(33656002)(76116006)(55016002)(44832011)(83380400001)(7696005)(86362001)(186003)(4326008)(9686003); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: QNpB865CTKn/DMVvikJCXsk/cvE/ilTJ8UghW6V+v0hUigciStjTad0RIqqmfCPNAOjZ3KK9zklgf3i1Fhnduc0rojBc2qD2zCUs6tu+t43m6Xw4XC8aH1/UTnlf1eOzH6BufE9UpF29tgX++Plq/I1pP0KmxmOyXreqAsoLoHOfka4pWm6M0wfZAyzk28HhgjyuCiPP76B7yYampKkwxOd02A4dVYsVk8xB7QehM4g09ryYQjni/Go/y8Ri8ohm4S2vPB1YbSB4wRs6fcvBo0E+e1/2y0GXbnBnaSTD5wUouQyOBcaZAg2wuJiggWEHI3R7rBdQ+ukcEoiWsdGuwDXtFmfkQCM86mdvLOxJIdHf8jDMr7xGqmL5/c2tRd//R9RYK+pXMu3ZaDkg++IqqzPM5ztU6YpkYnlFzYPSfDuPZB+WU367MkmYMo9uzos67a9SLhQuxF/tJNo0uIxQv3bYFtbGKAA8PAoBGSvsQe8tC+KLfaUl7sa5txFOvCuXP85iBCjsn12VXG/LO2MN18lQlXM4cXcSPLLiwlE+kyLPgKCooxkUm5X4pwSxKF/Y9HlPvRN7Ms/al6iHa6Ey/ocyPgSl16u+L0xLm5qvKlgNS/JVxbUxrQiLhyFH1CZ7+woPx0tLcwj62h8I6TZtrc0DSlbR4WlW2CveB4+YLVD7PFJuLWCI9tCYhHu/XQJ1Sij91KxfI4IdPhCYDIIS4g== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_AM8P190MB0979A8AF4C5352F4F040D137FDE00AM8P190MB0979EURP_" 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: 66c08c93-667c-4484-5733-08d88c7d5b40 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Nov 2020 11:22:10.1185 (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: 9OX9Nbup4zhK1uBqLJqmtv5fzVXmLTdsK2rvoXjGsXHNbUX1nO158ZWjIs2GKSggkQsh7djFErOI1HcwINio4sJtBLzqDrFM3cyvGi3xNtc= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4P190MB0178 Archived-At: Subject: Re: [dnssd] Review of draft-ietf-dnssd-srp-05 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 Nov 2020 11:22:17 -0000 --_000_AM8P190MB0979A8AF4C5352F4F040D137FDE00AM8P190MB0979EURP_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB0aGluayBtYW55IGZhY3RvcnkgcmVzZXRzIGFyZSBkb25lIHRvIHJlc29sdmUg4oCYZXJyb3Li gJkgY29uZGl0aW9ucyBpbiBwcm9kdWN0cy4gSXQgaXMgb2Z0ZW4gcGFydCBvZiBhIHZlbmRvcuKA mXMgdHJvdWJsZXNob290aW5nIHJvdXRpbmUsIHRvIGdldCB0aGUgcHJvZHVjdCBiYWNrIHRvIGEg d2VsbC1kZWZpbmVkIHN0YXRlLiBFc3BlY2lhbGx5IGZvciBJb1QgdHlwZSBwcm9kdWN0cyB0aGF0 IGRvbuKAmXQgaGF2ZSBtdWNoIHVzZXItc3BlY2lmaWMgZGF0YSBzdG9yZWQgaW5zaWRlIHRoaXMg Y2FuIHdvcmsgd2VsbC4gQW4gSW9UIGRldmljZSB2ZW5kb3IgY291bGQgaW4gdGhpcyBjYXNlIG1h a2UgdGhlIHB1YmxpYy9wcml2YXRlIGtleSBwZXJzaXN0IGFjcm9zcyBmYWN0b3J5LXJlc2V0cyBv ZiB0aGUgZGV2aWNlOyB0aGF0IHdvdWxkIGJlIHRoZSBtb3N0IGVsZWdhbnQgb3B0aW9uLiAgVXNl cnMgdGhhdCByZXNldCBhIGRldmljZSBmb3IgdGhpcyByZWFzb24gd291bGQgdHlwaWNhbGx5IGV4 cGVjdCB0byBnZXQgdGhlIHNhbWUgbmFtZSBiYWNrIGFnYWluIChhdCBsZWFzdCBhdCBVSSBsZXZl bCDigJMgdGhpcyBtYXkgb3IgbWF5IG5vdCBiZSBlcXVhbCB0byB0aGUgU1JQIHJlZ2lzdGVyZWQg bmFtZeKApikNCg0KSW4gY2FzZSB0aGUgSW9UIGRldmljZSBpcyBkZXNpZ25lZCB0byBnZW5lcmF0 ZSBhIG5ldyBrZXlwYWlyIHRoZW4gdGhlIGNvbnNlcXVlbmNlIHdvdWxkIGJlIHRoYXQgdGhlIGRl dmljZSBjYW7igJl0IGNsYWltIHRoZSBzYW1lIG5hbWUgYWdhaW4sIGlmIHRoZSBTUlAgc2VydmVy IHN0aWxsIGhhcyB0aGUgZW50cnkgc3RvcmVkLiBTbyBJIGFzc3VtZSBpdCB3aWxsIHRyeSBhIG5l dyBuYW1lIHRoZW4uDQoNCkRvbuKAmXQgdGhpbmsgdGhhdCB0aGUgU1JQIGRyYWZ0IG5lZWRzIHRv IGdvIGludG8gdGhlc2UgKGRlc2lnbikgZGV0YWlscyB0aG91Z2gsIGRvaW5nIGFueSBvZiBhYm92 ZSBzY2VuYXJpb3Mgc2hvdWxkIGJlIGZlYXNpYmxlIGZvciBhIHByb2R1Y3QuDQoNCkVza28NCg0K RnJvbTogZG5zc2QgPGRuc3NkLWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBUZWQgTGVt b24NClNlbnQ6IFRodXJzZGF5LCBOb3ZlbWJlciAxOSwgMjAyMCAxMTo0Mw0KVG86IE1hbnVlbCBB bXV0aW8gPG1hbXV0aW9Aa2lyYWxlLmNvbT4NCkNjOiBkbnNzZEBpZXRmLm9yZw0KU3ViamVjdDog UmU6IFtkbnNzZF0gUmV2aWV3IG9mIGRyYWZ0LWlldGYtZG5zc2Qtc3JwLTA1DQoNCk9uIE5vdiAx OSwgMjAyMCwgYXQgNToxNCBBTSwgTWFudWVsIEFtdXRpbyA8bWFtdXRpb0BraXJhbGUuY29tPG1h aWx0bzptYW11dGlvQGtpcmFsZS5jb20+PiB3cm90ZToNClJlZ2FyZGluZyBteSBmaXJzdCBkb3Vi dCwgSSBzdGlsbCBmYWlsIHRvIHVuZGVyc3RhbmQgaG93IGEgZGV2aWNlIHdoaWNoIGhhcyBsb3N0 IGl0cyBzZWN1cml0eSBtYXRlcmlhbCwgZm9yIGluc3RhbmNlIGFmdGVyIGEgZmFjdG9yeSByZXNl dCwgY291bGQgdGhlbiBjbGFpbSBpdHMgcmlnaHQgdG8gZGlzcG9zZSAocmVtb3ZlIG9yIHVwZGF0 ZSkgb2YgdGhlIHNlcnZpY2UgdGhhdCB3YXMgY3JlYXRlZCBiZWZvcmUuDQoNCkl0IGNhbuKAmXQs IGFuZCB0aGUgZG9jdW1lbnQgZG9lc27igJl0IHN1Z2dlc3QgdGhhdCBpdCBjYW4uDQoNClRoZSBl eHBlY3RhdGlvbiBpcyB0aGF0IHRoaXMgd291bGQgYmUgZG9uZSB3aGVuIHRoZSBvd25lcnNoaXAg b2YgdGhlIG9iamVjdCBjaGFuZ2VzLCBzbyB0aGF0IGl0IHdvdWxkIGJlIGRlcGxveWVkIGluIGEg ZGlmZmVyZW50IGNvbnRleHQgd2hlcmUgdGhlIG5hbWUgaXQgY2xhaW1lZCB3b3VsZCBub3QgYmUg dXNlZC4NCg0KDQo= --_000_AM8P190MB0979A8AF4C5352F4F040D137FDE00AM8P190MB0979EURP_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFs LCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCglmb250LXNpemU6 MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bh bi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp ZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJ e3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpk aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4 PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0i MSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5 IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIiBzdHlsZT0id29yZC13cmFw OmJyZWFrLXdvcmQiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkkgdGhpbmsgbWFueSBmYWN0b3J5IHJlc2V0cyBhcmUgZG9uZSB0byByZXNvbHZlIOKA mGVycm9y4oCZIGNvbmRpdGlvbnMgaW4gcHJvZHVjdHMuIEl0IGlzIG9mdGVuIHBhcnQgb2YgYSB2 ZW5kb3LigJlzIHRyb3VibGVzaG9vdGluZyByb3V0aW5lLCB0byBnZXQgdGhlIHByb2R1Y3QgYmFj ayB0byBhIHdlbGwtZGVmaW5lZCBzdGF0ZS4gRXNwZWNpYWxseSBmb3IgSW9UIHR5cGUgcHJvZHVj dHMgdGhhdCBkb27igJl0IGhhdmUgbXVjaA0KIHVzZXItc3BlY2lmaWMgZGF0YSBzdG9yZWQgaW5z aWRlIHRoaXMgY2FuIHdvcmsgd2VsbC4gQW4gSW9UIGRldmljZSB2ZW5kb3IgY291bGQgaW4gdGhp cyBjYXNlIG1ha2UgdGhlIHB1YmxpYy9wcml2YXRlIGtleSBwZXJzaXN0IGFjcm9zcyBmYWN0b3J5 LXJlc2V0cyBvZiB0aGUgZGV2aWNlOyB0aGF0IHdvdWxkIGJlIHRoZSBtb3N0IGVsZWdhbnQgb3B0 aW9uLiZuYnNwOyBVc2VycyB0aGF0IHJlc2V0IGEgZGV2aWNlIGZvciB0aGlzIHJlYXNvbiB3b3Vs ZCB0eXBpY2FsbHkNCiBleHBlY3QgdG8gZ2V0IHRoZSBzYW1lIG5hbWUgYmFjayBhZ2FpbiAoYXQg bGVhc3QgYXQgVUkgbGV2ZWwg4oCTIHRoaXMgbWF5IG9yIG1heSBub3QgYmUgZXF1YWwgdG8gdGhl IFNSUCByZWdpc3RlcmVkIG5hbWXigKYpPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkluIGNhc2Ug dGhlIElvVCBkZXZpY2UgaXMgZGVzaWduZWQgdG8gZ2VuZXJhdGUgYSBuZXcga2V5cGFpciB0aGVu IHRoZSBjb25zZXF1ZW5jZSB3b3VsZCBiZSB0aGF0IHRoZSBkZXZpY2UgY2Fu4oCZdCBjbGFpbSB0 aGUgc2FtZSBuYW1lIGFnYWluLCBpZiB0aGUgU1JQIHNlcnZlciBzdGlsbCBoYXMgdGhlIGVudHJ5 IHN0b3JlZC4gU28gSSBhc3N1bWUgaXQgd2lsbCB0cnkgYSBuZXcgbmFtZSB0aGVuLjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5Eb27igJl0IHRoaW5rIHRoYXQgdGhlIFNSUCBkcmFmdCBuZWVkcyB0 byBnbyBpbnRvIHRoZXNlIChkZXNpZ24pIGRldGFpbHMgdGhvdWdoLCBkb2luZyBhbnkgb2YgYWJv dmUgc2NlbmFyaW9zIHNob3VsZCBiZSBmZWFzaWJsZSBmb3IgYSBwcm9kdWN0LjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5Fc2tvPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gZG5zc2QgJmx0O2Ruc3NkLWJvdW5jZXNA aWV0Zi5vcmcmZ3Q7IDxiPk9uIEJlaGFsZiBPZiA8L2I+DQpUZWQgTGVtb248YnI+DQo8Yj5TZW50 OjwvYj4gVGh1cnNkYXksIE5vdmVtYmVyIDE5LCAyMDIwIDExOjQzPGJyPg0KPGI+VG86PC9iPiBN YW51ZWwgQW11dGlvICZsdDttYW11dGlvQGtpcmFsZS5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBk bnNzZEBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW2Ruc3NkXSBSZXZpZXcgb2Yg ZHJhZnQtaWV0Zi1kbnNzZC1zcnAtMDU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPk9uIE5vdiAxOSwgMjAyMCwgYXQgNToxNCBBTSwgTWFudWVsIEFtdXRpbyAmbHQ7PGEg aHJlZj0ibWFpbHRvOm1hbXV0aW9Aa2lyYWxlLmNvbSI+bWFtdXRpb0BraXJhbGUuY29tPC9hPiZn dDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5SZWdhcmRpbmcgbXkgZmlyc3QgZG91YnQs Jm5ic3A7SSBzdGlsbCBmYWlsIHRvIHVuZGVyc3RhbmQgaG93IGEgZGV2aWNlIHdoaWNoIGhhcyBs b3N0IGl0cyBzZWN1cml0eSBtYXRlcmlhbCwgZm9yIGluc3RhbmNlIGFmdGVyIGEgZmFjdG9yeSBy ZXNldCwgY291bGQgdGhlbiBjbGFpbSBpdHMgcmlnaHQgdG8NCiBkaXNwb3NlIChyZW1vdmUgb3Im bmJzcDt1cGRhdGUpIG9mIHRoZSBzZXJ2aWNlIHRoYXQgd2FzIGNyZWF0ZWQgYmVmb3JlLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkl0IGNhbuKAmXQsIGFuZCB0aGUgZG9jdW1lbnQgZG9lc27igJl0IHN1 Z2dlc3QgdGhhdCBpdCBjYW4uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPlRoZSBleHBlY3RhdGlvbiBpcyB0aGF0IHRoaXMgd291bGQgYmUgZG9u ZSB3aGVuIHRoZSBvd25lcnNoaXAgb2YgdGhlIG9iamVjdCBjaGFuZ2VzLCBzbyB0aGF0IGl0IHdv dWxkIGJlIGRlcGxveWVkIGluIGEgZGlmZmVyZW50IGNvbnRleHQgd2hlcmUgdGhlIG5hbWUgaXQg Y2xhaW1lZCB3b3VsZCBub3QgYmUgdXNlZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0K PC9odG1sPg0K --_000_AM8P190MB0979A8AF4C5352F4F040D137FDE00AM8P190MB0979EURP_-- From nobody Thu Nov 19 05:03:55 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 AB3183A0E27; Thu, 19 Nov 2020 05:03:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 0Juj0moT6zyR; Thu, 19 Nov 2020 05:03:52 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE44B3A0E08; Thu, 19 Nov 2020 05:03:50 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id F174C389D1; Thu, 19 Nov 2020 08:04:48 -0500 (EST) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id WKnrgaOcaTuo; Thu, 19 Nov 2020 08:04:48 -0500 (EST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 5CEA3389CD; Thu, 19 Nov 2020 08:04:48 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id DC0CA18B; Thu, 19 Nov 2020 08:03:48 -0500 (EST) From: Michael Richardson To: Esko Dijk , Ted Lemon , Manuel Amutio , "dnssd\@ietf.org" , iotops@ietf.org In-Reply-To: References: <843154D5-2D1A-4CD6-9922-64B01FA2DC1A@fugue.com> <693293B1-04A9-4F6C-AA0A-BE5F1A099BD4@fugue.com> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [dnssd] persistence of naming/identities across "factory" resets (wasRe: Review of draft-ietf-dnssd-srp-05) 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 Nov 2020 13:03:55 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable This thread from dnssd, CCed to iotops. Esko Dijk wrote: > I think many factory resets are done to resolve =E2=80=98error=E2=80= =99 conditions in > products. It is often part of a vendor=E2=80=99s troubleshooting rout= ine, to > get the product back to a well-defined state. Especially for IoT type > products that don=E2=80=99t have much user-specific data stored insid= e this can > work well. An IoT device vendor could in this case make the > public/private key persist across factory-resets of the device; that > would be the most elegant option. Users that reset a device for this > reason would typically expect to get the same name back again (at lea= st > at UI level =E2=80=93 this may or may not be equal to the SRP registe= red name=E2=80=A6) This is actually a pretty big architectural issue. I strongly think that we need to be able qualify the different kinds of factory resets, and we probably need to be able to interrogate a device as = to what kind of reset it just made. We also need to be able to backup device configuration and identity info a number of different encrypted ways. This is in support of devices that need to be repaired, but afterward should continue identically. Possibly that means using the same private keys. Possibly the private keys need to be *removed* before being sent out for repair, and then restored afterwards. Possibly also in some cases we need to be able to force a new identity on t= he device (because it was resold). We need to be do this generically across different device types without need a per-device "APP" > In case the IoT device is designed to generate a new keypair then the > consequence would be that the device can=E2=80=99t claim the same nam= e again, > if the SRP server still has the entry stored. So I assume it will try= a > new name then. > Don=E2=80=99t think that the SRP draft needs to go into these (design= ) details > though, doing any of above scenarios should be feasible for a product. I agree that SRP need not go into it. It would be nice if we could explain these different device models in a way that a future version of SRP could normatively reference. =2D- ] Never tell me the odds! | ipv6 mesh network= s [ ] Michael Richardson, Sandelman Software Works | IoT architect = [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [ =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl+2bTQACgkQgItw+93Q 3WW/1AgAi1k5KISyaXl4zn2jJlwoIzlgn3Aw10Amd16rD/gwSEmqXcLrNezwrEgM Q7RuyBq5P+/nFyIqhQZcL8JUStBUwzzn+pgErjVGJm//b5fUOgC/B2B75kl+0HCm 6EieYJbXpJ1ZqxLRl+KzfAA0m02V8ws6pVa23KxbhiQ5l+9NI+VyHImsrhIxfjpf wD4eFD4D1uWP0h0SZ8QYry4fSswjEwPFey/wKASPUGOFTnqptkCTJUImwZpVPlrJ wAnEmSeOfn0O8vf9JGlKtVv2M3WiDYhgAetVLfHcD1Qq1UWK2tKp2kmsI5ftYByN o84mUgLBWdEASqocv22vjcxLgfWqDQ== =GhQm -----END PGP SIGNATURE----- --=-=-=--