From nobody Thu May 2 21:00:45 2019 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 277661201D5 for ; Thu, 2 May 2019 21:00:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 EdxMCEf-_L_I for ; Thu, 2 May 2019 21:00:40 -0700 (PDT) Received: from oj.bangj.com (69-77-154-174.static.skybest.com [69.77.154.174]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B05812006F for ; Thu, 2 May 2019 21:00:40 -0700 (PDT) Received: from [172.16.25.146] (69-77-155-155.static.skybest.com [69.77.155.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id 5A7532EA08; Fri, 3 May 2019 00:00:39 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) From: Tom Pusateri In-Reply-To: Date: Fri, 3 May 2019 00:00:38 -0400 Cc: DNSSD Content-Transfer-Encoding: quoted-printable Message-Id: <68FEE2FE-00CB-4CA2-8219-62A31394829E@bangj.com> References: To: David Schinazi X-Mailer: Apple Mail (2.3445.104.8) Archived-At: Subject: Re: [dnssd] WGLC for draft-ietf-dnssd-srp X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2019 04:00:43 -0000 I=E2=80=99m breaking this review for draft-ietf-dnssd-srp into two = sections. 1. overall architecture 2. latest revision of the document I like the new distinction between constrained nodes and regular nodes. = This helps. Section 1. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D As we=E2=80=99re moving from the local link with mDNS to internet wide = service discovery over unicast DNS, I think it is necessary to ensure = all DNS messages that exit the local link be encrypted. a. This document purports to provide =E2=80=9Ca reasonably = secure mechanism=E2=80=9D that mentions no encryption. Encryption is = desirable for privacy with both link local and internet wide dns = messages. While legacy mDNS does not perform encryption, it is possible = to encrypt link-local announcements as well as internet wide area = announcements, queries, and responses. b. It provides limited authentication through =E2=80=9Cfirst = come, first serve=E2=80=9D semantics for change modifications but not = for the the initial registration of any service. c. It punts access control to the local administrator based on = IP address. d. It suggests the use of TCP to ensure client address = verification but then also seems to suggest UDP is ok too for RFC 2136 = unconstrained nodes. e. The use of anycast requires guarantees about network routing = operations that cannot be detected by SRP servers or clients. SRP = Updates sent to an anycast address can leak outside the domain through a = default route and even to another domain=E2=80=99s SRP servers. = Accepting these over UDP and requiring access control to be configured = by the same administrators that haven=E2=80=99t set up anycast routing = correctly seems like a bad idea. Random users can install devices = configured to use the anycast address out of the box in a network not = anticipating the deployment of SRP. f. describing an architecture where the DNS SRP server is not = typically on the same link but then requiring it to be so in order for = the sleep proxy to function as described suggests maybe the SRP = architecture needs to change. (section 2.6.2) Section 2. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D document comments Section 2, paragraph 2: There are restrictions placed on the domain name to use = including RFC 2119 terminology requiring it but there is no = justification for the imperatives (both in the v4 and v6 case). This = leaves the reader wondering why. Section 2, paragraph 3: _dnssd-srp._tcp is defined (add a period before as = in 2.3.2). Can there also be a _dnssd-srp-tls._tcp.? Section 2, paragraph 4: The wording makes it seem like =E2=80=9Cdefault.services.arpa=E2=80= =9D is defined in RFC 6761 Section 2.1, paragraph 1: The update terminology seems overloaded and a bit confusing in = the document overall. In this particular paragraph, the second sentence = is confusing with updates in the update that are records. Section 2.1, paragraph 3: the use of =E2=80=9Cboth=E2=80=9D follows a list of items making = it hard to discern what both refers to. It could be: 1. the three items in the list (but then both implies 2 = items not 3) 2. one or more TXT RRs (but more than 2 also isn=E2=80=99t= usually referred to as both) Section 2.1, last paragraph: KEY records are mentioned above but the details of these = aren=E2=80=99t explained in RFC 6763 Section 2.3, first paragraph: =E2=80=9Cit=E2=80=99s possible to do all the work of adding a = PTR resource record to the PTR RRset on the Service Name if it already = exists, or creating one if it doesn=E2=80=99t=E2=80=9D. This is = confusing because each service instance adds a PTR Service Name record = identically whether the RRset exists or not. Section 2.3, first and second paragraph: First it says =E2=80=9Cit is possible=E2=80=9D and then it says = =E2=80=9CAn SRP update is therefore implemented=E2=80=9D. But the logic = between these end caps is not explicit and so it reads awkwardly and = reader is left wondering what the =E2=80=9Ctherefore=E2=80=9D is there = for. Section 2.3, last paragraph: The document uses =E2=80=9Cupdate constraints=E2=80=9D but = should in this case use "update pre-requisites" since it=E2=80=99s = referring to the way 2136 does things. The second use of constraints = referring to section 2.4.2 seems correct. Section 2.3.2: This section seems out of place because it is only for testing = (manual client key installation etc.) and so should be moved to an = appendix. Section 2.3.3, paragraph 2: =E2=80=9Cas described earlier using _dns-update._udp=E2=80=9D - = I don=E2=80=99t see any other references to _dns-update._udp. Also, RFC = 2136-compliant servers shouldn=E2=80=99t be restricted to UDP. They can = support TLS, TCP, or UDP. (_dns-update-tls._tcp, _dns-update._tcp, and = _dns-update._udp). But earlier in 2.0, second to last paragraph, you require TCP to = prevent off-network spoofing so UDP should not be suggested here. Section 2.4, last paragraph: =E2=80=9Cwhat we describe here improves upon the security of = mDNS. The goal is not to provide the level of security of a network = managed by a skilled operator.=E2=80=9D In fact, we want to design protocols that provide security, = privacy, and protect users regardless of the skill of the operators. = mDNS has a level of protection afforded to it by it=E2=80=99s link local = nature. Once SRP leaves the link, it is open to a whole new host of = vulnerabilities and it has to address each of these in a way mDNS never = had to. Section 2.4.1.1, third paragraph: =E2=80=9Cservice description updates=E2=80=9D - it=E2=80=99s not = clear here what =E2=80=9Cupdates=E2=80=9D means. This is part of the = overloading of update in the document. Section 2.4.1.1, fifth paragraph: =E2=80=9Cit makes a claim=E2=80=9D - the paragraph discusses the = option to use different lease life times and then ends with a = declarative that it makes a claim that lasts much longer when it fact it = doesn=E2=80=99t have to. I suggest =E2=80=9Cit could make a claim=E2=80=9D= . Section 2.4.2: This section contains the meat of the =E2=80=9Cupdate=E2=80=9D = confusion. Service Discovery update, Service Description update, and = Host Description update need different terminology to distinguish an = update message, and SRP update, and these combination of records, that = combined in a specific way, comprise an SRP update. Maybe Service = Discovery group or bloc? And we already have resource records and RRsets = so maybe that terminology could be used in places? =E2=80=9CAn update is a Service Discovery update if=E2=80=9D - = When all of the records required must be in an SRP update, what does = =E2=80=9Cupdate=E2=80=9D mean here? =E2=80=9Cone of more TXT RRset updates=E2=80=9D - can this = =E2=80=9Cupdates=E2=80=9D be =E2=80=9Cresource records=E2=80=9D? =E2=80=9Cthere is a Service Instance Name update in the SRP = update that updates an SRV RR so that it points to the hostname being = updated by this update=E2=80=9D - ETOOMANYUPDATES in this sentence =E2=80=9CNote that if the definitions of each of these update = types are followed carefully, this means that many things that look very = much like SRP updates nevertheless are not=E2=80=9D - It seems that if = the definitions of each of these updates are followed carefully, you = would end up with a valid update. Stating that you don=E2=80=99t seems = to imply that the definitions are not descriptive enough. =E2=80=9Cis the same as the KEY record in the update=E2=80=9D - = again, it=E2=80=99s not clear what update you are referring to. And can = there be multiple KEY records in the same SRP update? Again, the Service = Description update vs the Host Description update make this confusing. =E2=80=9CThe server MAY add a Reverse Mapping=E2=80=9D - (why is = Reverse Mapping capitalized?) - Can the client add this? Would this be a = standard RFC 2136 update since the zone is different? =E2=80=9Cmaintenance functionality=E2=80=9D - provide a = reference in the document to what you mean here How do you delete an SRP announced service before the lease = lifetime of the service name PTR record expires? The rules don=E2=80=99t = seem to allow that. Section 2.5: If one service is announced via SRP and another service from the = same host is announced over SRP, how do you make A and AAAA record TTLs = consistent with both service records? =E2=80=9Cwhen adding RRs to an RRset, =E2=80=A6 MUST use the = same TTL=E2=80=9D - Seems like it would be impossible to achieve this = with Service PTR records in an RRset. I=E2=80=99m probably not = understanding it so it may need clarification. Section 2.6.1, second to last paragraph: How does a dual-use server decide an update is an SRP update or = an RFC 2136 update? Section 3.2: Do you need to specify which key to use for server signature = validation? Isn=E2=80=99t this already specified outside of SRP? Section 6.1: Throughout the document you reference default.services.arpa and = then in the IANA you request the services.arpa domain. Where is = default.services.arpa defined and/or managed? Is it a subdomain or a = leaf? Thanks, Tom From nobody Tue May 7 11:22:30 2019 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 3F88612027A for ; Tue, 7 May 2019 11:22:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id toTtG6ijGIhT for ; Tue, 7 May 2019 11:22:22 -0700 (PDT) Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (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 5C0BF120266 for ; Tue, 7 May 2019 11:22:22 -0700 (PDT) Received: by mail-lf1-x135.google.com with SMTP id j20so12584277lfh.2 for ; Tue, 07 May 2019 11:22:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=quGZD068rr4hM0X+GC8RDKkGDwofytlQzT5vImJGWcY=; b=GXUsMKczefDviEUfk36aM9UVtiUd9vNmeS9SDN7RGNTFJg7gCZFiuM5crQ6hDXC3EQ BI4l+3Z9Wj2EGW8XBiG/H2TQBrJJ4xx0pUrRvMPTVlxPY3pr9tpGt2lJhxSjdGCafDDp nrSf85Q13oYEDIvn5J5/IaLR6tdBrzPDBaABFqOvWQyJHT8rvUhyYdsBZW43eR9C/vFJ yDB6pmCJbKHNm3yZdRR8qCMMGgwm5ITgIfkp/VPXIWeVb+bxipk1viSpjGo9d01hDAKN 0E/DxLuDqTOzlt2ePDOWh0UaqwnHUZjGX3SCjardVfwdmJDkFzPIpZxy7N3rvdHH7qdG IjbA== 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=quGZD068rr4hM0X+GC8RDKkGDwofytlQzT5vImJGWcY=; b=tkOrBnFQgln+ftL9ZYwni/9DCRJQTSvYF+zNvBDDJItmM67q4YsgBA/4I+xGA9Tn+R vu5VNDzAH0i5n/15QCYH6uAAfPYRgPkWZtieyhC25YJE9dv6hTH/cIPvf9XhNxkLZoX5 w90E9YNw9a49mV4Nd/AIxU9faejrtGkJ64+WJdcI9qafBh5eNm1Uq5vS0hwVFXcFnHoS hC5A5U/lsPh8TPNSy9Neqw1DZlut3sYnKc7WFEZVL3NDorMQS1pdi84eyQ+jRzxhVAoa QQMwhbHu481zJVZmXuQsUCRvgNZytM3D9qbmWlFbRAN1XCkEXISiag/sDB6sGf6R6kyl +OaQ== X-Gm-Message-State: APjAAAV4NR0HUnKo6lqDdi4cI/jGxn0gPw94AC/f0QpTswnqbpuX+OgW mbA36n1KCQGPkFfS/gLmwP8qLhkvBehtXBlvmYQ= X-Google-Smtp-Source: APXvYqx4DwgOAHRODyauYTBmvlM7D+feeEc9JJjql1LMCx9cWE8+TPye2gwSjIEMwZQCsWPyWJJ9sRMjQvnJwuXaLeM= X-Received: by 2002:ac2:550f:: with SMTP id j15mr10438947lfk.73.1557253340615; Tue, 07 May 2019 11:22:20 -0700 (PDT) MIME-Version: 1.0 References: <19C8C2DA-8B57-44B2-9457-DCB395D95D62@apple.com> <9C4A5433-4490-43B3-B82B-EFFD52FF5AB4@cisco.com> In-Reply-To: <9C4A5433-4490-43B3-B82B-EFFD52FF5AB4@cisco.com> From: David Schinazi Date: Tue, 7 May 2019 11:22:09 -0700 Message-ID: To: "Jan Komissar (jkomissa)" Cc: Stuart Cheshire , DNSSD Content-Type: multipart/alternative; boundary="0000000000003157b50588504cfd" Archived-At: Subject: Re: [dnssd] WGLC for draft-ietf-dnssd-push 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, 07 May 2019 18:22:29 -0000 --0000000000003157b50588504cfd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks everyone. Since draft-ietf-dnssd-push already had successfully completed WGLC, and there was no opposition to the latest changes, we're declaring this WGLC successful. The document will be submitted to the IESG for publication shortly. David On Mon, Apr 29, 2019 at 8:38 AM Jan Komissar (jkomissa) wrote: > This draft looks fine to me. > > > > Jan. > > > > *From: *dnssd on behalf of David Schinazi < > dschinazi.ietf@gmail.com> > *Date: *Sunday, April 28, 2019 at 8:07 PM > *To: *Stuart Cheshire > *Cc: *DNSSD > *Subject: *Re: [dnssd] WGLC for draft-ietf-dnssd-push > > > > Thank you Stuart. > > > > To give working group members time to review this diff and your email, we > are extending this WGLC by a week, until 2019-05-06. > > > > For future reference, you can use rfcdiff with published draft names in > the URL: > > > https://tools.ietf.org//rfcdiff?url1=3Ddraft-ietf-dnssd-push-16&url2=3Ddr= aft-ietf-dnssd-push-19 > > > > > Speaking with WG chair hat off, I personally do not see any problem with > these changes and support publication. > > > > Thanks, > > David > > > > On Thu, Apr 25, 2019 at 10:13 PM Stuart Cheshire 40apple.com@dmarc.ietf.org> wrote: > > On 15 Apr 2019, at 10:07, David Schinazi wrote= : > > > This email starts another Working Group Last Call (WGLC) for > draft-ietf-dnssd-push, which will last for two weeks until 2019-04-29. As= a > reminder, this document has already passed WGLC but some slight changes t= o > the document warranted another WGLC. > > Thank you David. > > I have attached an HTML file of the output from < > https://tools.ietf..org/rfcdiff > > comparing draft-ietf-dnssd-push-16 with draft-ietf-dnssd-push-19. > > There are a variety of minor textual changes, such as replacing reference= s > to draft-ietf-dnsop-session-signal with references to RFC 8490, now that > this document is published. > > In terms of substantive changes, there are two: > > 1. DNS Push Notification RECONFIRM > > We realized that there is no useful response to a RECONFIRM request. We > changed RECONFIRM to be a unidirectional DSO message, and that results in > the deletion of the entire =E2=80=9CRECONFIRM Response=E2=80=9D section. = This simplifies > both code, and the document. > > 2. DNS Push Notification Updates > > Previously, Tom Pusateri and I thought that borrowing the DNS Update > encoding made sense. That was before DSO (RFC 8490). > > When implementing the current specification of DNS Push Notifications ove= r > DSO, Ted Lemon discovered that it has no way to express the DNS CLASS of > changes. > > We need to address the problem Ted Lemon discovered, and now that DNS Pus= h > uses DSO TLV encoding instead of traditional DNS messages, the incentive = to > follow strictly the existing DNS Update encoding has disappeared. > > To address this issue, we adopted a new, simpler, way of expressing > changes.. It=E2=80=99s broadly similar, but simpler. > > Please take a look at these changes and let us know if you see any > problems.. > > And if you *don=E2=80=99t* see any problems with these changes, please re= spond > saying that too. > > Stuart Cheshire > > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd > > --0000000000003157b50588504cfd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks everyone.

Since= draft-ietf-dnssd-push already had successfully completed WGLC, and
ther= e was no opposition to the latest changes, we're declaring this WGLCsuccessful. The document will be submitted to the IESG for publication
= shortly.

David

On Mon, Apr 29, 2019= at 8:38 AM Jan Komissar (jkomissa) <jkomissa@cisco.com> wrote:

This draft looks fine to me.

=C2=A0

Jan.

=C2=A0

From: = dnssd <dnssd-bounces@ietf.org= > on behalf of David Schinazi <dschinazi.ietf@gmail.com>
Date: Sunday, April 28, 2019 at 8:07 PM
To: Stuart Cheshire <cheshire=3D40apple.com@dmarc.ietf.org>
Cc: DNSSD <dn= ssd@ietf.org>
Subject: Re: [dnssd] WGLC for draft-ietf-dnssd-push

=C2=A0

Thank you Stuart.

=C2=A0

To give working group members time to review this di= ff and your email, we are extending this WGLC by a week, until 2019-05-06.<= u>

=C2=A0

For future reference, you can use rfcdiff with publi= shed draft names in the URL:

=C2=A0

Speaking with WG chair hat off, I personally do not = see any problem with these changes and support publication.

=C2=A0

Thanks,

David

=C2=A0

On Thu, Apr 25, 2019 at 10:13 PM Stuart Cheshire <= ;cheshire=3D40apple.com@dmarc.ietf.org> wrote:

On 15 Apr 2019, at 10:07, David Schinazi <dschinazi.ietf@gmail= .com> wrote:

> This email starts another Working Group Last Call (WGLC) for draft-iet= f-dnssd-push, which will last for two weeks until 2019-04-29. As a reminder= , this document has already passed WGLC but some slight changes to the docu= ment warranted another WGLC.

Thank you David.

I have attached an HTML file of the output from <https://tools.ietf..org/rfcdiff&g= t; comparing draft-ietf-dnssd-push-16 with draft-ietf-dnssd-push-19.

There are a variety of minor textual changes, such as replacing references = to draft-ietf-dnsop-session-signal with references to RFC 8490, now that th= is document is published.

In terms of substantive changes, there are two:

1. DNS Push Notification RECONFIRM

We realized that there is no useful response to a RECONFIRM request. We cha= nged RECONFIRM to be a unidirectional DSO message, and that results in the = deletion of the entire =E2=80=9CRECONFIRM Response=E2=80=9D section. This s= implifies both code, and the document.

2. DNS Push Notification Updates

Previously, Tom Pusateri and I thought that borrowing the DNS Update encodi= ng made sense. That was before DSO (RFC 8490).

When implementing the current specification of DNS Push Notifications over = DSO, Ted Lemon discovered that it has no way to express the DNS CLASS of ch= anges.

We need to address the problem Ted Lemon discovered, and now that DNS Push = uses DSO TLV encoding instead of traditional DNS messages, the incentive to= follow strictly the existing DNS Update encoding has disappeared.

To address this issue, we adopted a new, simpler, way of expressing changes= .. It=E2=80=99s broadly similar, but simpler.

Please take a look at these changes and let us know if you see any problems= ..

And if you *don=E2=80=99t* see any problems with these changes, please resp= ond saying that too.

Stuart Cheshire

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

--0000000000003157b50588504cfd-- From nobody Tue May 7 11:27:59 2019 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 25C04120252 for ; Tue, 7 May 2019 11:27:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VxOfuenj9tWo for ; Tue, 7 May 2019 11:27:51 -0700 (PDT) Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) (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 1CD891202C2 for ; Tue, 7 May 2019 11:27:51 -0700 (PDT) Received: by mail-lf1-x132.google.com with SMTP id h126so1422367lfh.4 for ; Tue, 07 May 2019 11:27:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=xIZ12h7j6BlIMoAqW0lWWIO9kYsOpnK16AMxhJcYQv0=; b=a9Vy7/QJvBi7RKGD7FUuHHgUHc4i3FJcAKNgck2FOu7JwMU6sQvRuE7plWD/qcdpuf ZN4JnKFz2TBuKEvewOwcJT67VQFaK6ktIz9nsfLXxH9rMVzD37yAzYhkwV3Uj0iRg5gN AyEUQKiZYebV60J9kANIDSpGk+odE57fITIg76ZbFtoGSsV4kIeM83z1wfaNl5Da1XKy IHyry0IJ/xr8ikOCyUiNv8qF7vNzTrt+4nTbrLa3MmGFVpMlNWmVWRHKf8aLnJ8d7WPn /i1mmEfRHLZf1FU44sObKfZnTX4vBxymPfyOOb+cqrilYI772Vp+2QksAYWEXisGr0Tz BkIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=xIZ12h7j6BlIMoAqW0lWWIO9kYsOpnK16AMxhJcYQv0=; b=dIITwcemWFa9xsnFPsXk3nn3BRzwwIlaUt8qFfeRfiXeJRudYfBRTJQQqhd2QH52+s QJFUioptvEHBpjQsC1rBUx38qZOvHYKDiRKCJEOMRQuV6bMQcMiATswFss5AK4aVe+3j yqaraipb/bdkVLP5hT4V9O5eceft2VoRod4k4pdUuYDyhk9sHSOHmK8A98uaeX2VBrRK lnAMZKpDIeOkpYxoj2NILUyfgqTWAKMvVXLKkUn0GfgnPe+067ZJbsyZrTnaKA7ImRMX reeS1T5klNNe5gmFTnadDR8+DYdGQEmBakoKoiVpSCLk7nwdDwEImdum+6TXhpI5wu8/ f6yw== X-Gm-Message-State: APjAAAWAMGvgOwi9jfYgKfTuKPZmn0UsGebKrToG2GdWPwUPGq81eTvu w0xzt2Af/ZLkqpHavQTIYpbtoJRuTowohTLOjpqjiw== X-Google-Smtp-Source: APXvYqzxodeTafr4sK+lNJSMg3r+dk+oFZJ2uxRWPDESASJVNn+p7DlzL4e5FFMNzesrB7eJMRJzCVMcDYlqr4ywstg= X-Received: by 2002:a05:6512:206:: with SMTP id a6mr3027448lfo.18.1557253669012; Tue, 07 May 2019 11:27:49 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: David Schinazi Date: Tue, 7 May 2019 11:27:38 -0700 Message-ID: To: DNSSD Content-Type: multipart/alternative; boundary="000000000000c449580588505f2a" Archived-At: Subject: Re: [dnssd] WGLC for draft-ietf-dnssd-mdns-relay 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, 07 May 2019 18:27:57 -0000 --000000000000c449580588505f2a Content-Type: text/plain; charset="UTF-8" Hi everyone, This WGLC has also failed due to lack of support. We encourage the authors to instigate more discussion of this topic on this mailing list. Thanks, David On Mon, Apr 15, 2019 at 10:07 AM David Schinazi wrote: > Hi everyone, > > This email starts a Working Group Last Call (WGLC) > for draft-ietf-dnssd-mdns-relay, which will last for two weeks until > 2019-04-29. As a reminder, the last WGLC failed due to lack of statements > of support. > > Please indicate support or raise any concerns in response to this email. > > Thanks, > David > --000000000000c449580588505f2a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi everyone,

This WGLC has also fai= led due to lack of support.
We encourage the authors to instigate= more discussion of this topic on this mailing list.

Thanks,
David

On Mon, Apr 15, 2019 at 10:07 AM David Schi= nazi <dschinazi.ietf@gmail.c= om> wrote:
Hi everyone,

This em= ail starts a Working Group Last Call (WGLC) for=C2=A0draft-ietf-dnssd-mdns-= relay, which will last for two weeks until 2019-04-29. As a reminder, the l= ast WGLC failed due to lack of statements of support.

<= div>Please indicate support or raise any concerns in response to this email= .

Thanks,
David
--000000000000c449580588505f2a-- From nobody Tue May 7 11:28:13 2019 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 31525120234 for ; Tue, 7 May 2019 11:28:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d_FBwVuqxRfJ for ; Tue, 7 May 2019 11:28:09 -0700 (PDT) Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (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 16F44120242 for ; Tue, 7 May 2019 11:28:09 -0700 (PDT) Received: by mail-lf1-x135.google.com with SMTP id d8so12560931lfb.8 for ; Tue, 07 May 2019 11:28:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=Un5H7KI8i+NkEYzUaHNTGLpHHM+kYpwftO8IJKIXovo=; b=b+UyEWb/atF3xZ2Q9CgCeiCynN7W/izrdNmXKfae6nSFXtQYn2xIu7iHpB1HfReZqZ R9J5zMkXSTcMVFWiBq/d7zG+7KwtWlCmzQN4u8iEhjiABwzFhPSJoDdZU9tNdqnYKrfa PAt89xAmrokuzmNvIE/dDB9W5WlBEIPyn8M2Md1oN7QI2bBB9TsjfE39kbwCYMkbuV5B YJxIo0SeWZ1Q9Bkllc60xcp/M7+CDcUrF1/gJGkPi5e69EGTeK6gpmAS4wkyNJfCwwoM wzTCKf7FR9ikonnNC0ty/DqtmVTxh0zWIGDgyYNEVPsra7Y31jBjMn2Qu5noV6/0pa+d Z2EA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=Un5H7KI8i+NkEYzUaHNTGLpHHM+kYpwftO8IJKIXovo=; b=n9V4DgJPvDwHWsvVPuewwvz2vPpufRCw8hPOcd1MMMGUhAVoN5/KK3nSj4NhCDRbu9 UwLALNa8jHCMpK7CW93YjFQmXCTYCweRZxd4bg4xowqhUAJzt6cBK3SccAIHD7y8J9BR 6Crrfnre1lYOHZfosGWM5aYNghYxhClPVaMf3kFrrfej/jkFkf+8Q9Ql0c4sZfrK9PfX fcNMzH1Q3Q9KEttEY1qdm97gkaHs57eQAg469YVFhpFoL6lK0yDk+hem/XcltXCP8pAP lI39UHPcrU70u74Rr8opXhNfPIpRD6uLxt10dHgRJjcVif4nbyRCw+72yFyr0Qv+TNpE XKSQ== X-Gm-Message-State: APjAAAVf7HNTVfDPDfVyaTcNu9c8oE99v6yc//cPY6pEr1g54jYdwu2c 7dcE4aT5pwXN4kR0dXjzfXVKtUPBgSENNqfCF2Irgg== X-Google-Smtp-Source: APXvYqyKAqpo7qBWZbIsmcG7Gy6UrcWFKK7nAjG4qZoSGTJ8XhjpBg1/5DslCDzhajT7GwvaXUi6i6HxH1BsTHWRm7o= X-Received: by 2002:ac2:550f:: with SMTP id j15mr10451896lfk.73.1557253687248; Tue, 07 May 2019 11:28:07 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: David Schinazi Date: Tue, 7 May 2019 11:27:56 -0700 Message-ID: To: DNSSD Content-Type: multipart/alternative; boundary="000000000000da8a1b05885060e4" Archived-At: Subject: Re: [dnssd] WGLC for draft-ietf-dnssd-srp X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2019 18:28:11 -0000 --000000000000da8a1b05885060e4 Content-Type: text/plain; charset="UTF-8" Hi everyone, Since there have been no written statements of support and the one review raises concerns, this WGLC was not successful. This document is now back in the "WG Document" stage. We believe the document can benefit from more discussion before moving it along in IETF process. Thanks, David On Mon, Apr 15, 2019 at 10:07 AM David Schinazi wrote: > Hi everyone, > > This email starts a Working Group Last Call (WGLC) > for draft-ietf-dnssd-srp, which will last for two weeks until 2019-04-29. > > Please indicate support or raise any concerns in response to this email. > > Thanks, > David > --000000000000da8a1b05885060e4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi everyone,

Since there= have been no written statements of support and the one review raises conce= rns, this WGLC was not successful.

This document i= s now back in the "WG Document" stage. We believe the document ca= n benefit from more discussion before moving it along in IETF process.

Thanks,
David

On Mon, Apr 15, 2019 at 1= 0:07 AM David Schinazi <dschinazi.ietf@gmail.com> wrote:
Hi = everyone,

This email starts a Working Group Last Call (W= GLC) for=C2=A0draft-ietf-dnssd-srp, which will last for two weeks until 201= 9-04-29.

Please indicate support or raise any conc= erns in response to this email.

Thanks,
= David
--000000000000da8a1b05885060e4-- From nobody Fri May 10 16:20:36 2019 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 5A2CA1200F7; Fri, 10 May 2019 16:20:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: David Schinazi via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 6.96.0 Auto-Submitted: auto-generated Precedence: bulk Cc: Tim Wicinski , tjw.ietf@gmail.com, dnssd@ietf.org, iesg-secretary@ietf.org, dnssd-chairs@ietf.org Message-ID: <155753043536.25928.16551356671786028998.idtracker@ietfa.amsl.com> Date: Fri, 10 May 2019 16:20:35 -0700 Archived-At: Subject: [dnssd] Publication has been requested for draft-ietf-dnssd-push-19 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: Fri, 10 May 2019 23:20:35 -0000 David Schinazi has requested publication of draft-ietf-dnssd-push-19 as Proposed Standard on behalf of the DNSSD working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-dnssd-push/ From nobody Fri May 17 00:47:28 2019 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 4380312004E; Fri, 17 May 2019 00:47:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Liang Xia via Datatracker To: Cc: draft-ietf-dnssd-push.all@ietf.org, dnssd@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.96.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Liang Xia Message-ID: <155807923913.14794.15819590021470228961@ietfa.amsl.com> Date: Fri, 17 May 2019 00:47:19 -0700 Archived-At: Subject: [dnssd] Secdir telechat review of draft-ietf-dnssd-push-19 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: Fri, 17 May 2019 07:47:20 -0000 Reviewer: Liang Xia Review result: Has Issues Nit: 1. Section 6.1, s/This connection is made to TCP port 853, the default port for DNS-over-TLS DNS over TLS [RFC7858]./This connection is made to TCP port 853, the default port for DNS-over-TLS [RFC7858]. 2. Table 2, RECONFIRM should be C-U TLV type. Comments: 1. why are UNSUBSCRIBE and RECONFIRM the client unidirectional message? 2. In UNSUBSCRIBE message, why do you choose to use SUBSCRIBE MESSAGE ID, not NAME+TYPE+CLASS? 3. In the section of Security Considerations: 1) you should also mention that TLS provides the anti-replay protection service for DNS Push; 2) maybe you need to consider the client authentication to achieve policy control and detect illegal client; 3) TLS WG are specifying the SNI encryption mechanism, will it influence your TLS name authentication? From nobody Fri May 17 08:59:31 2019 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 F2D6C12026C; Fri, 17 May 2019 08:59:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 tKwZxbo-xNJc; Fri, 17 May 2019 08:59:27 -0700 (PDT) Received: from oj.bangj.com (69-77-154-174.static.skybest.com [69.77.154.174]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1F5B12025E; Fri, 17 May 2019 08:59:23 -0700 (PDT) Received: from [172.16.10.110] (mta-107-13-246-59.nc.rr.com [107.13.246.59]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id DBDBD2FD85; Fri, 17 May 2019 11:59:22 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Tom Pusateri In-Reply-To: <155807923913.14794.15819590021470228961@ietfa.amsl.com> Date: Fri, 17 May 2019 11:59:22 -0400 Cc: secdir@ietf.org, draft-ietf-dnssd-push.all@ietf.org, dnssd@ietf.org, ietf@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <233D5D9C-F966-4D3D-A06B-841203564C61@bangj.com> References: <155807923913.14794.15819590021470228961@ietfa.amsl.com> To: Liang Xia X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [dnssd] Secdir telechat review of draft-ietf-dnssd-push-19 X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2019 15:59:29 -0000 Thanks for the review. I can confirm that both nits need fixed. As far as your comments: 1. UNSUBSCRIBE and RECONFIRM are unidirectional because they are already = acknowledged by the transport protocol and there is nothing the client = can do in response to a DNS level Stateful Operations acknowledgement = from the server. If an UNSUBSCRIBE fails, it=E2=80=99s because it=E2=80=99s not = subscribed and the end result either way is that it=E2=80=99s not = subscribed. A RECONFIRM may trigger additional queries from the server which may or = may not result in PUSH notifications but the client has to deal with the = situation the same until a PUSH notification is received. 2. As far as using the DNS header MESSAGE ID in an UNSUBSCRIBE, this is = a consequence of not reusing outstanding message IDs over stateful = operations. This means the server must keep the state of the message id = and so associating it with the subscription is natural. Will also address TLS comments. Thanks, Tom > On May 17, 2019, at 3:47 AM, Liang Xia via Datatracker = wrote: >=20 > Reviewer: Liang Xia > Review result: Has Issues >=20 > Nit: > 1. Section 6.1, s/This connection is made to TCP port 853, the default = port for > DNS-over-TLS DNS over TLS [RFC7858]./This connection is made to TCP = port 853, > the default port for DNS-over-TLS [RFC7858]. 2. Table 2, RECONFIRM = should be > C-U TLV type. >=20 > Comments: > 1. why are UNSUBSCRIBE and RECONFIRM the client unidirectional = message? > 2. In UNSUBSCRIBE message, why do you choose to use SUBSCRIBE MESSAGE = ID, not > NAME+TYPE+CLASS? 3. In the section of Security Considerations: > 1) you should also mention that TLS provides the anti-replay = protection > service for DNS Push; 2) maybe you need to consider the client > authentication to achieve policy control and detect illegal client; = 3) TLS > WG are specifying the SNI encryption mechanism, will it influence = your TLS > name authentication? >=20 > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd From nobody Thu May 30 08:12:26 2019 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 6D6F312023D for ; Thu, 30 May 2019 08:12:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 i3YPZoTtO8KS for ; Thu, 30 May 2019 08:12:23 -0700 (PDT) Received: from oj.bangj.com (69-77-154-174.static.skybest.com [69.77.154.174]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C43881201E9 for ; Thu, 30 May 2019 08:12:20 -0700 (PDT) Received: from [192.168.0.6] (unknown [204.116.194.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id F23AE30E9D for ; Thu, 30 May 2019 11:12:19 -0400 (EDT) From: Tom Pusateri Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: <1E8281A3-50CD-4526-86D2-A65B4A6C27CF@bangj.com> Date: Thu, 30 May 2019 11:12:19 -0400 To: DNSSD X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [dnssd] WG participation (or lack there of) 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, 30 May 2019 15:12:25 -0000 DNSSD, I=E2=80=99m struggling with the apparent lack of interest in the = work performed by this WG. The original mandate based on the EDUCAUSE = request seemed to show that we were working on a problem that needed an = interoperable solution. However, as time has gone by, we have seen little feedback from the = educational community and a general lack of participation from the = working group. Several calls for participation have ended in no response and I wonder = if we=E2=80=99re still solving a problem that people have. Vendors have introduced work-arounds in switches, access points, and = even bluetooth pairings. I think it is worth considering if we=E2=80=99re solving a problem worth = solving. Therefore, I am considering suspending my work in this working group and = am of the opinion that the wg should consider shutting down. If you object to the WG shutting down, then respond as such and include = how you=E2=80=99re willing to contribute in the next few months.=20 There is still some interesting security work going on but that may be = better served in a security working group where there is cryptographic = expertise. In a lively WG, we would have feedback from people who have previously = deployed the technology, vendors who have implemented the new = technology, and DNS experts that would guide the use of the protocol. We = would have multiple interoperable implementations and feedback from = those implementations. Thanks, Tom= From nobody Fri May 31 13:07:58 2019 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 310611200BA for ; Fri, 31 May 2019 13:07:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5M2jf2X5CUJv for ; Fri, 31 May 2019 13:07:55 -0700 (PDT) Received: from mail-pg1-x535.google.com (mail-pg1-x535.google.com [IPv6:2607:f8b0:4864:20::535]) (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 3F46F120033 for ; Fri, 31 May 2019 13:07:55 -0700 (PDT) Received: by mail-pg1-x535.google.com with SMTP id v11so4615147pgl.5 for ; Fri, 31 May 2019 13:07:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=UyzqaSPZdSG4+7KAMF1UeabwfUAYJt8pa/7hXwh41eU=; b=IMQB67PaGtjCWl3EBzjfIEen8cVkIG2zhFcjTuoP/COskmdsZxhiLsL7aIkDz9LWvE a4vP5f71b4IV9amvcmZFvN6TdplVyxQZEod/fSAsmiwyKLr3LKoZunODaoJgofKsIj2y qfDPfzCIA4x3RZITOvFYMW9xf3hEKiP1hlmySMtxDaFWZD4N/v7pRd3gRYU1ZVb3Otsk 8dfjQx1kOpiaUWJ22jBLs6ZZZi/OXewhOB70EDpMILqbywhOqJrppjbcqVRyg2s2q1ab 1hnDzRpYjUnBDt876oo5wfTmBeGyLlTAOa8iJ9FE0Bkit2JtF08FyV+GGqBeYd7EoUVy 5iOw== 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=UyzqaSPZdSG4+7KAMF1UeabwfUAYJt8pa/7hXwh41eU=; b=n4QWCeu+P2CDjQSxCWFufHoHS8YGLMtlIkUzIkJExo0LMgpjmLrrXwW3BBT4RuUt1s Vv9RRWKDmIpsleOVGzi8zcZZciNyML+v2H80ymCtyzjNpLP0r9pneIQmPiLGIAAAIBFe vC5l+3bY1Ac2nA1j1Ov275qjhAXDsmQ70ndxe1nZqR60s89gQwzvOGYXHZJJ19oAVFsJ cx9jXpYNLT/KTnrabS1/jn1sbNrQjYCE+emo2XX/ll7BjrO0Yn1L+zMrRSXKtLPS50+K ZeXuVaIhFtYY02gthGS0HNKnfBH0MtCewdohXTLB5MHdaq86MAGi0wyZl7mpgj1qcd3w QgGA== X-Gm-Message-State: APjAAAWwr5jAPN204c3SaVHtLMUPMLO0mjcr8KI0CzdTvvmxRphqS460 uPERkQjLe3jFDC51YLfTiNkyf2Ucv1k= X-Google-Smtp-Source: APXvYqwhTvLAso8R9kzDYaFXl7ijt8Rc6+h8IRscz4NeIM8Hov87XoM0OyM9oGCbAdEM0m3EUvJRbg== X-Received: by 2002:a63:78cf:: with SMTP id t198mr3301043pgc.82.1559333274498; Fri, 31 May 2019 13:07:54 -0700 (PDT) Received: from [17.230.172.14] ([17.230.172.14]) by smtp.gmail.com with ESMTPSA id m5sm5816078pgc.84.2019.05.31.13.07.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 31 May 2019 13:07:53 -0700 (PDT) From: Ted Lemon Message-Id: <1CC8AB7F-7AFE-4883-9751-0BC6CA0BDCA9@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_3470E964-DF4B-4035-9073-56342B72B874" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Fri, 31 May 2019 13:07:52 -0700 In-Reply-To: <1E8281A3-50CD-4526-86D2-A65B4A6C27CF@bangj.com> Cc: DNSSD To: Tom Pusateri References: <1E8281A3-50CD-4526-86D2-A65B4A6C27CF@bangj.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [dnssd] WG participation (or lack there of) X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2019 20:07:57 -0000 --Apple-Mail=_3470E964-DF4B-4035-9073-56342B72B874 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On May 30, 2019, at 8:12 AM, Tom Pusateri wrote: > If you object to the WG shutting down, then respond as such and = include how you=E2=80=99re willing to contribute in the next few months.=20= I do object. I=E2=80=99m a bit jammed up with pre-WWDC work right now = to comment at length, but will respond in more detail after WWDC. --Apple-Mail=_3470E964-DF4B-4035-9073-56342B72B874 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = May 30, 2019, at 8:12 AM, Tom Pusateri <pusateri@bangj.com> = wrote:
If you object = to the WG shutting down, then respond as such and include how you=E2=80=99= re willing to contribute in the next few months. 

I do object.   I=E2=80=99m a bit = jammed up with pre-WWDC work right now to comment at length, but will = respond in more detail after WWDC.

= --Apple-Mail=_3470E964-DF4B-4035-9073-56342B72B874-- From nobody Fri May 31 13:31:49 2019 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 070281200FF for ; Fri, 31 May 2019 13:31:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 8MoGjQWkOnBJ for ; Fri, 31 May 2019 13:31:46 -0700 (PDT) Received: from oj.bangj.com (69-77-154-174.static.skybest.com [69.77.154.174]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48E651200C1 for ; Fri, 31 May 2019 13:31:46 -0700 (PDT) Received: from [172.16.25.146] (69-77-155-155.static.skybest.com [69.77.155.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id 5D53231081; Fri, 31 May 2019 16:31:45 -0400 (EDT) From: Tom Pusateri Message-Id: <3FE4C383-658F-49A9-B5E9-5E1AE68C6255@bangj.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_6414F422-5C5C-44F6-9B8A-D000FAEB1995" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Fri, 31 May 2019 16:31:44 -0400 In-Reply-To: <1CC8AB7F-7AFE-4883-9751-0BC6CA0BDCA9@fugue.com> Cc: DNSSD To: Ted Lemon References: <1E8281A3-50CD-4526-86D2-A65B4A6C27CF@bangj.com> <1CC8AB7F-7AFE-4883-9751-0BC6CA0BDCA9@fugue.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [dnssd] WG participation (or lack there of) X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2019 20:31:48 -0000 --Apple-Mail=_6414F422-5C5C-44F6-9B8A-D000FAEB1995 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On May 31, 2019, at 4:07 PM, Ted Lemon wrote: >=20 > On May 30, 2019, at 8:12 AM, Tom Pusateri > wrote: >> If you object to the WG shutting down, then respond as such and = include how you=E2=80=99re willing to contribute in the next few months.=20= >=20 >=20 > I do object. I=E2=80=99m a bit jammed up with pre-WWDC work right = now to comment at length, but will respond in more detail after WWDC. >=20 Well, I was hoping you and Stuart objected. But it=E2=80=99s everyone = else that worries me. Where are the users, vendors, implementors aside = from the authors? Tom= --Apple-Mail=_6414F422-5C5C-44F6-9B8A-D000FAEB1995 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On = May 31, 2019, at 4:07 PM, Ted Lemon <mellon@fugue.com> = wrote:

On May 30, 2019, at = 8:12 AM, Tom Pusateri <pusateri@bangj.com> wrote:
If you object to the WG shutting down, then respond as such = and include how you=E2=80=99re willing to contribute in the next few = months. 

I do object.   I=E2=80=99m a bit = jammed up with pre-WWDC work right now to comment at length, but will = respond in more detail after WWDC.


Well, I was hoping you and Stuart objected. But it=E2=80=99s = everyone else that worries me. Where are the users, vendors, = implementors aside from the authors?

Tom
= --Apple-Mail=_6414F422-5C5C-44F6-9B8A-D000FAEB1995-- From nobody Fri May 31 13:58:23 2019 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 670791200FF for ; Fri, 31 May 2019 13:58:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ei0ABH7fTQF5 for ; Fri, 31 May 2019 13:58:19 -0700 (PDT) Received: from mail-pl1-x62d.google.com (mail-pl1-x62d.google.com [IPv6:2607:f8b0:4864:20::62d]) (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 C69691200C1 for ; Fri, 31 May 2019 13:58:19 -0700 (PDT) Received: by mail-pl1-x62d.google.com with SMTP id e5so2724816pls.13 for ; Fri, 31 May 2019 13:58:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=YQ0lBIQ5OJOh9MYnU3kZ6mqxUKLYdirSDJCDQPQ6q78=; b=cjYubnjlV1qVH/qHKcW6OJntgU3b4BrhGzvNwuVSNC9jJKt3z+yP8HTwTN6/BU9oqr 3QLE8Sz+BYvmJMPEx3n/zb5flgRo8wj7Ba4q6JxVr/Rx1pmfBJQTu0MCk6IvlFL891wV OOc9Bb2K7B4nuVHAWkdRlrhNSWZ309az7HcJBIcxShU3V5HmXwFZpFiSdbkug8hmZtci jT2xFHKjD4Rm7O1KwC8g2W+1DHT3F1edOXj9Qbdk1yXUXU/WFt0J+n0QXEcMGUPapAUJ 5LmlqeSZYi4x0BjXS0XnRRMk0worJXi8DWs+TKWIzHtTLOgCQrdxzF1/qndjcivEOaaK Ff1g== 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=YQ0lBIQ5OJOh9MYnU3kZ6mqxUKLYdirSDJCDQPQ6q78=; b=qHPmbGwYRlsm89UMm1xMp9dla+Rx99alNxKU6ifeuSqaDTh53Itwl2CRLySMt6dJwb UrBWz0+2vZ/Jct3trY7tzg828UGKlJxfBfHtcsMw2qPJs80GL+vge07UR2fJNzz0rd3B 0hyAAFiNegEumA7prM7PFL42dpZqILGQr9Z9tWKX242z1KLYo0hTplgKCg+55RgKvOuh BnOauZnDuziny04Nj/CyvWO0UWAWIdETFGPE/LMSZhso7MJhcOrblbZ6T96cw8pFNwE+ 1k1lx0PEZVh3ow0CNs24N0CBH4HVuGrl3MoDb8kQlBE2An04orA3JoxEAnaBdV6oppNr GYzg== X-Gm-Message-State: APjAAAWHB+SONLFRCHZv9QmbuLrH+ff5X1ZVuJuW4hFkIBw7HJX+BAq8 Hz+8IWgSyaQNNTRXMx4KXol8Q8k6xGg= X-Google-Smtp-Source: APXvYqwGjZNAUMZpUlGKCtLE9toEoNgg61c29BCTHD7FQJDxLXOQd9A6wsOb0W/TTNC0Jn3vebPuyw== X-Received: by 2002:a17:902:a582:: with SMTP id az2mr11829270plb.110.1559336298583; Fri, 31 May 2019 13:58:18 -0700 (PDT) Received: from [17.230.172.14] ([17.230.172.14]) by smtp.gmail.com with ESMTPSA id d5sm5469922pgi.86.2019.05.31.13.58.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 31 May 2019 13:58:18 -0700 (PDT) From: Ted Lemon Message-Id: <537B0D8C-9943-448E-9972-D3717E03878B@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_E66A3AF5-3825-41F8-B5D5-73F1811EC443" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Fri, 31 May 2019 13:58:04 -0700 In-Reply-To: <3FE4C383-658F-49A9-B5E9-5E1AE68C6255@bangj.com> Cc: DNSSD To: Tom Pusateri References: <1E8281A3-50CD-4526-86D2-A65B4A6C27CF@bangj.com> <1CC8AB7F-7AFE-4883-9751-0BC6CA0BDCA9@fugue.com> <3FE4C383-658F-49A9-B5E9-5E1AE68C6255@bangj.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [dnssd] WG participation (or lack there of) X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2019 20:58:21 -0000 --Apple-Mail=_E66A3AF5-3825-41F8-B5D5-73F1811EC443 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On May 31, 2019, at 1:31 PM, Tom Pusateri wrote: > Well, I was hoping you and Stuart objected. But it=E2=80=99s everyone = else that worries me. Where are the users, vendors, implementors aside = from the authors? As I said, I will have time to discuss it after the WWDC crunch is over. = If it=E2=80=99s okay with you, can we hold off until then? --Apple-Mail=_E66A3AF5-3825-41F8-B5D5-73F1811EC443 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = May 31, 2019, at 1:31 PM, Tom Pusateri <pusateri@bangj.com> = wrote:
Well, I was hoping you and Stuart objected. But it=E2=80=99s = everyone else that worries me. Where are the users, vendors, = implementors aside from the authors?

As I said, I will have time to discuss it after = the WWDC crunch is over.   If it=E2=80=99s okay with you, can we = hold off until then?

= --Apple-Mail=_E66A3AF5-3825-41F8-B5D5-73F1811EC443-- From nobody Fri May 31 17:33:29 2019 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 D8DEC1200F8 for ; Fri, 31 May 2019 17:33:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NO_DNS_FOR_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k5JZEv3oblb5 for ; Fri, 31 May 2019 17:33:26 -0700 (PDT) Received: from smtp86.ord1d.emailsrvr.com (smtp86.ord1d.emailsrvr.com [184.106.54.86]) (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 5618D12004D for ; Fri, 31 May 2019 17:33:26 -0700 (PDT) X-Auth-ID: ogud@ogud.com Received: by smtp19.relay.ord1d.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id 5B35D601FC; Fri, 31 May 2019 20:33:25 -0400 (EDT) X-Sender-Id: ogud@ogud.com Received: from olafurs-air.fios-router.home (pool-173-66-193-119.washdc.fios.verizon.net [173.66.193.119]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:25 (trex/5.7.12); Fri, 31 May 2019 20:33:25 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Olafur Gudmundsson In-Reply-To: <1E8281A3-50CD-4526-86D2-A65B4A6C27CF@bangj.com> Date: Fri, 31 May 2019 20:33:24 -0400 Cc: DNSSD Content-Transfer-Encoding: quoted-printable Message-Id: <80100734-B735-44BC-A3DF-E0EAA279305A@ogud.com> References: <1E8281A3-50CD-4526-86D2-A65B4A6C27CF@bangj.com> To: Tom Pusateri X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [dnssd] WG participation (or lack there of) 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: Sat, 01 Jun 2019 00:33:28 -0000 > On May 30, 2019, at 11:12 AM, Tom Pusateri wrote: >=20 > DNSSD, > I=E2=80=99m struggling with the apparent lack of interest in the = work performed by this WG. The original mandate based on the EDUCAUSE = request seemed to show that we were working on a problem that needed an = interoperable solution. >=20 > However, as time has gone by, we have seen little feedback from the = educational community and a general lack of participation from the = working group. >=20 > Several calls for participation have ended in no response and I wonder = if we=E2=80=99re still solving a problem that people have. >=20 > Vendors have introduced work-arounds in switches, access points, and = even bluetooth pairings. >=20 > I think it is worth considering if we=E2=80=99re solving a problem = worth solving. >=20 > Therefore, I am considering suspending my work in this working group = and am of the opinion that the wg should consider shutting down. >=20 > If you object to the WG shutting down, then respond as such and = include how you=E2=80=99re willing to contribute in the next few months.=20= >=20 > There is still some interesting security work going on but that may be = better served in a security working group where there is cryptographic = expertise. >=20 > In a lively WG, we would have feedback from people who have previously = deployed the technology, vendors who have implemented the new = technology, and DNS experts that would guide the use of the protocol. We = would have multiple interoperable implementations and feedback from = those implementations. >=20 > Thanks, > Tom > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd Tom,=20 I think you are right and with only 2 people interested in the work it = is time to close the WG=20 Olafur