From nobody Mon Jan 5 03:44:35 2015 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E6F41A3BA4; Mon, 5 Jan 2015 03:44:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.778 X-Spam-Level: X-Spam-Status: No, score=0.778 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779] autolearn=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 SmTAuBxq0XQS; Mon, 5 Jan 2015 03:44:31 -0800 (PST) Received: from kirsi1.inet.fi (mta-out1.inet.fi [62.71.2.203]) by ietfa.amsl.com (Postfix) with ESMTP id D21DC1A2130; Mon, 5 Jan 2015 03:44:29 -0800 (PST) Received: from poro.lan (80.220.64.126) by kirsi1.inet.fi (8.5.142.08) (authenticated as stenma-47) id 546BDD4B053732D9; Mon, 5 Jan 2015 13:44:28 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Markus Stenberg In-Reply-To: <20141217201155.19208.95569.idtracker@ietfa.amsl.com> Date: Mon, 5 Jan 2015 13:44:28 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <90A26CE2-87CC-4C8C-BEF9-FDF021C4FE97@iki.fi> References: <20141217201155.19208.95569.idtracker@ietfa.amsl.com> To: ietf@ietf.org X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/nTxrVYrIErK1S1QTvwYcyQXD8GU Cc: dnssd@ietf.org, Markus Stenberg Subject: Re: [dnssd] Last Call: (Requirements for Scalable DNS-SD/mDNS Extensions) to Informational RFC X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 11:44:33 -0000 (Sorry about the late reply, too much vacation.. *grin*) Comments: - in e.g. section 2, I find use of =E2=80=98DNS-SD/mDNS framework=E2=80=99= confusing. DNS-SD works across links just fine; it is plain DNS. I = would also omit the framework. Alternatively, perhaps DNS-SD+mDNS would = convey the meaning better. section 6.5 uses =E2=80=98DNS-SD + mDNS = implementation=E2=80=99 once. - use case F: is it really justified? it is just mentioned in REQ14. = based on my reading, if it was just added to C=E2=80=99s list of link = technologies, it would be also inherited by D and E.. - REQ2: Does it apply to C? Small business/homenet + scopes - what would = be the example? - REQ5: I am not sure what =E2=80=98integrate=E2=80=99 means here. = Unidirectional access (SSD -> DNS-SD/mDNS? SSD <- DNS-SD/mDNS?)? = Bidirectional? Cheers, -Markus= From nobody Wed Jan 7 00:09:05 2015 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D089E1A897F; Wed, 7 Jan 2015 00:08:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham 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 UPkEDz4Ue9F1; Wed, 7 Jan 2015 00:08:57 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 237691A8982; Wed, 7 Jan 2015 00:08:56 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: DraftTracker Mail System To: iesg@ietf.org, dnssd@ietf.org, dnssd-chairs@tools.ietf.org, draft-ietf-dnssd-requirements.all@tools.ietf.org, tjc@ecs.soton.ac.uk X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150107080856.4039.88510.idtracker@ietfa.amsl.com> Date: Wed, 07 Jan 2015 00:08:56 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/B8wyg8CxT24t7-Ua6Vc_49k9l6g Cc: iesg-secretary@ietf.org Subject: [dnssd] Last Call Expired: X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 08:08:59 -0000 Please DO NOT reply to this email. I-D: ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-dnssd-requirements/ IETF Last Call has ended, and the state has been changed to Waiting for Writeup. From nobody Thu Jan 8 07:47:48 2015 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 025561A0231 for ; Thu, 8 Jan 2015 07:47:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 lcFshDxYyXoa for ; Thu, 8 Jan 2015 07:47:37 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A05111A87EE for ; Thu, 8 Jan 2015 07:47:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=366; q=dns/txt; s=iport; t=1420732058; x=1421941658; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=j97D/liinVbzehU486w9RAPkEBgpZ/ic5rNI2YnXNlM=; b=TWwb4MjzW1RA1ZpZcRkfxbk6rGvg8UW6aNHqnQtLk164WRAqKdWQjs+5 W/H5iZDGMgT7wMdsZ73RfqSD1Uo/J0yV2SQkfkZPkDZ96K06BqBMc/7dn A1omh/TU/mlWQpXFjraHn04upGsKG5eG/L112g9gYGuJ6dqsHuri4p+ex U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhcFAAimrlStJA2E/2dsb2JhbABcgwaBLs0CQwEBAQEBfYQTHR1RAT5CJwSIP6MsoyEBAQEBBgEBAQEBAQEbkxaBEwWOM4kHgQ6CcY1vIoNugjR+AQEB X-IronPort-AV: E=Sophos;i="5.07,723,1413244800"; d="scan'208";a="111390364" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-1.cisco.com with ESMTP; 08 Jan 2015 15:47:38 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t08Flajo029957 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 8 Jan 2015 15:47:36 GMT Received: from xmb-aln-x04.cisco.com ([169.254.9.203]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0195.001; Thu, 8 Jan 2015 09:47:36 -0600 From: "Ralph Droms (rdroms)" To: "dnssd@ietf.org" Thread-Topic: draft-sullivan-dnssd-mdns-dns-interop-01 Thread-Index: AQHQK1psj8ONJ4j9N02H6iQyf7to/Q== Date: Thu, 8 Jan 2015 15:47:36 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.131.65.113] Content-Type: text/plain; charset="us-ascii" Content-ID: <310D7133A2ABA547B35BE877D504E97C@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [dnssd] draft-sullivan-dnssd-mdns-dns-interop-01 X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 15:47:46 -0000 Happy new year... At the last dnssd WG meeting, there was support for adopting draft-sullivan= -dnssd-mdns-dns-interop-01 as a work item. This e-mail is a consensus call= for adoption. Tim and I will make a consensus call next Friday, Jan 16. = Please comment to the list about adopting draft-sullivan-dnssd-mdns-dns-int= erop-01 before then. - Ralph From nobody Fri Jan 9 15:33:49 2015 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E6001A1A9F for ; Fri, 9 Jan 2015 15:33:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 BPcQx2VJM01e for ; Fri, 9 Jan 2015 15:33:46 -0800 (PST) Received: from mail-qc0-x22a.google.com (mail-qc0-x22a.google.com [IPv6:2607:f8b0:400d:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9084F1A1A94 for ; Fri, 9 Jan 2015 15:33:46 -0800 (PST) Received: by mail-qc0-f170.google.com with SMTP id x3so11542264qcv.1 for ; Fri, 09 Jan 2015 15:33:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=pBjz+ypu6hpn9CoMnXcZY574dHRLAolWf+IFcgGKoaM=; b=yLP+9/0t3uX8yEAHXdK/2XdlNZgvE5Aha16G/WuDYW+bIlhVIJJ3u6naD2rrxXE9b7 OXLOOBVcFkDWeRI6eI1dg/QL6YajXDwR92X1/QyNJoFY0b2cCpBYg0d2WTXu0MHCFkuZ 7BSxFTeXkeZ5fpa58nu+FiQgwq7aKOC1xkjqrsUVRDaw01Cmd3tBGlZ3hLHZuBGUOCqu 4EY4LJNDYHDqe8+47krTwptsnAnFMnAZfDYjSLgmpRjwWt+TCMLKBdTW3xlaLVij+XFT 9WpFyhevB0rgT/CE/6+7xj84KmsxKn9Flis09h9P1OWFW2NaFduQ54MQyu8aXiKGXFVo IwTg== X-Received: by 10.224.23.133 with SMTP id r5mr21377626qab.88.1420846425450; Fri, 09 Jan 2015 15:33:45 -0800 (PST) Received: from still.local ([50.127.155.45]) by mx.google.com with ESMTPSA id f77sm8313632qgd.49.2015.01.09.15.33.44 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 09 Jan 2015 15:33:44 -0800 (PST) Message-ID: <54B06558.2040003@gmail.com> Date: Fri, 09 Jan 2015 18:33:44 -0500 From: Tim Wicinski User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:36.0) Gecko/20100101 Thunderbird/36.0a2 MIME-Version: 1.0 To: dnssd@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dnssd] draft-sullivan-dnssd-mdns-dns-interop-01 X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2015 23:33:48 -0000 On 1/8/15 10:47 AM, Ralph Droms (rdroms) wrote: > Happy new year... > > At the last dnssd WG meeting, there was support for adopting draft-sullivan-dnssd-mdns-dns-interop-01 as a work item. This e-mail is a consensus call for adoption. Tim and I will make a consensus call next Friday, Jan 16. Please comment to the list about adopting draft-sullivan-dnssd-mdns-dns-interop-01 before then. > > I've read this document and feel it's worth adopting. I'll even volunteer to provide editorial feedback to the author(s) tim From nobody Mon Jan 12 10:17:03 2015 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 855381ACD1F for ; Mon, 12 Jan 2015 10:17:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 jJs7uTbrQS0e for ; Mon, 12 Jan 2015 10:16:59 -0800 (PST) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (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 128691ACD25 for ; Mon, 12 Jan 2015 10:16:59 -0800 (PST) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id EE317DA0173 for ; Mon, 12 Jan 2015 18:16:58 +0000 (UTC) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id D924553E07C; Mon, 12 Jan 2015 10:16:58 -0800 (PST) Received: from divertimento.ddns.nominum.com (64.89.225.115) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 12 Jan 2015 10:16:58 -0800 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon Date: Mon, 12 Jan 2015 10:16:55 -0800 Content-Transfer-Encoding: quoted-printable Message-ID: <3E234B87-E5F6-49E7-8D67-59C4BE35EF45@nominum.com> References: <5D36713D8A4E7348A7E10DF7437A4B923B004639@nkgeml512-mbx.china.huawei.com> To: X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [64.89.225.115] Archived-At: Cc: dnssd@ietf.org Subject: [dnssd] Fwd: OPS-DiR review of draft-ietf-dnssd-requirements X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2015 18:17:01 -0000 I've had some private chat with Sheng, and wanted to relay the outcome = of some of that discussion. I encourage the authors to consider = Sheng's review in its entirety as a last-call review more than an = ops-dir review, because I think he just did a general review without an = operational focus, but with that said, if you find useful information = there, I encourage you to apply it. In terms of specific issues, here are some conclusions from the = discussion: >> In section 2.1, the last (fifth) bullet item of technical issues is = actually the summaried requirement. The followed technical requirements = are actually the detailed requirements for the required mechanism in = this bullet item. I don't personally think any change is needed here, but Sheng's point is = that the fifth bullet item really isn't like the first four, and it = might be better expressed as an introduction for the detailed = requirements that follow it. I think his position makes sense, but = it's up to you how to address this, or whether to address it. >> The first paragraph of section 2.3 may need a little bit reorganized. = he current form does not clearly describe why the wireless mesh network = require mDNS need to support over multiple links in a wireless mesch = network. >=20 > The issue, which I think _is_ clearly stated, is that link scope and = subnet scope are not the same for LLNs, and that mDNS doesn't work = across entire LLN subnets because of this. If you don't think this is = clear, can you suggest text? >=20 > Your above rewording is much more clear. The current text = failed to say that mDNS also needs to be spanned multiple links to cover = the entire LLN subnet. So, there is a logic break. So Sheng's point here is that it isn't clear to the non-LLN-literate = reader that an LLN subnet contains multiple link scopes, and hence mDNS = won't work across an entire LLN subnet. I think it's worth clarifying = the text to make sure that the reader understands this point. Maybe = the following wording change would make it more clear: OLD: Emerging wireless mesh networking technologies such as RPL [RFC6550] and 6LoWPAN present several challenges for the current DNS-SD/mDNS design. First, Link-Local multicast scope [RFC4291] is defined as a single-hop neighborhood. A single subnet prefix in a wireless mesh network may often span multiple links, therefore a larger multicast scope is required to span it [RFC7346]. Multicast DNS is intentionally not specified for greater than Link-Local scope, because of the additional multicast traffic that would generate. NEW: Emerging wireless mesh networking technologies such as RPL [RFC6550] and 6LoWPAN present several challenges for the current DNS-SD/mDNS design. First, while it is normally the case on IPv6 networks that the Link-Local multicast scope [RFC4291] and subnet scope are identical, this is not the case for LLNs. In an LLN, the Link-Local scope is defined as a single-hop neighborhood. A single subnet prefix in a wireless mesh network may often span multiple links, therefore a larger multicast scope is required to span it [RFC7346]. Multicast DNS is intentionally not specified for greater than Link-Local scope, because of the additional multicast traffic that would generate. >> Section 3, use case A, it would be very useful if some adoption = status of Zero Configuration Network [ZC] could be given. For now, there = may be some concern over whether it is a widely used technology. I don't think that Sheng's point here is an actual problem that needs to = be addressed. At this point, the PAN use case may be a bit = hypothetical, and if it were the only use case for DNSSD, I'd say that = we were being premature, but since it's not, I think it's worth keeping = in mind, and needn't be removed. >> Section3, it seems all use cases are assuming the single exit router. = But the scerarios of multiple exit routers would be a common use case as = well. Is this left out of scope intentionally? If so, some explanation = for the reason may helpful. >=20 > Aren't at least (D) and (E) potentially multi-homed? I think you = have a good point here, although it's not an ops-dir point. I don't = actually see a reason for this section to mention whether or not the = sites are multi-homed. >=20 > Yes, I certainly believe D and E are potentially = multiple-homed, maybe C too. But again, it is the way of expression = implies the opposite: C clearly said "behind the single exit router"; = then D is "like C but..."; E is "like D but...". The stated differenties = in D and E do not include any words regarding to potential multiple exit = routers. I know that there was a desire to have a use case that's specifically = for a really simple home network, but the general homenet use case is = also a valid use case that we need to address, and the way the text is = structured, it implies that all the subsequent use cases are not = multi-homed, which I don't think is correct. So I think that this text = needs to be reworked to make it clear that the "single exit router" = restriction only applies to the simple home network use case and the = simple homenet network use case. If the multihomed homenet use case is = not going to be addressed by DNSSD, it should be explicitly excluded. = Was this in fact the intention of the working group? I'd be surprised, = because I would think there would have been a long argument about it, = which I don't remember seeing. >> Section 4, REQ8 looks a very fundemental requirement for all service = discovery mechanism. It does not look like a specific requirement for = SSD. This is true, and doesn't mean that the requirement should be deleted, = so I don't think you need to take any action here. >> Section 4, REQ13 may need reworded. The first sentense said "closely = reflection reality". The follow-up explanations are all about real-time = or close to real-time. I think Sheng's objection here stems from the colloquial meaning of = "closely reflect reality" within the IETF. It might be better to say = something like "closely reflect the current state of discoverable = services on the network." >> Section 4, REQ14, SSD requests some new functions on network devices. = It is a change to the network technology. So Sheng took "network technology" to include layers above layer 3, and = that's the basis of his complaint. I think the meaning here is fairly = clear, but you could address his complaint with the following wording = change: OLD: REQ14: SSD should operate over existing networks (as described by use cases A-F above) without requiring changes to the network technology or deployment. NEW: REQ14: SSD should operate over existing layer 2 and layer 3 networks (as described by use cases A-F above) without requiring=20 changes to the network technology or deployment. We didn't talk about the proposed changes to sections 5 and 6, and I = don't think the comments are necessarily actionable, although it can be = argued that the problems described in section 6 ought to be reflected in = requirements specified in section 4, if possible. Doug Otis also = mentioned this. If you can come up with specific requirements, I think = that would improve the document. If you can't, you should probably say = so explicitly.= From nobody Mon Jan 12 10:21:46 2015 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2793F1AC3BC for ; Mon, 12 Jan 2015 10:21:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 ZWnHC5JIcxb6 for ; Mon, 12 Jan 2015 10:21:42 -0800 (PST) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (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 AF6CE1A802F for ; Mon, 12 Jan 2015 10:21:42 -0800 (PST) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id 9B833DA016F for ; Mon, 12 Jan 2015 18:21:42 +0000 (UTC) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 8A98853E07C; Mon, 12 Jan 2015 10:21:42 -0800 (PST) Received: from divertimento.ddns.nominum.com (64.89.225.115) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 12 Jan 2015 10:21:42 -0800 From: Ted Lemon Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 12 Jan 2015 10:21:34 -0800 Message-ID: <457D08E9-E747-42B5-B272-CA304382249A@nominum.com> To: MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [64.89.225.115] Archived-At: Cc: dnssd@ietf.org Subject: [dnssd] Last Call review of Requirements document... X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2015 18:21:44 -0000 In addition to the comments Sheng sent in his OPS-DIR review, we also = had comments from Douglas Otis and Markus Stenberg. I would appreciate = it if the authors could address those comments. I don't think every = comment actually requires a change to the draft, and I think some were = already addressed during working group review, but there were some good = comments in both messages, and I'd like the authors to consider and = respond to them before I move forward with the IESG review. If = something was already addressed during the working group review, you can = address that comment by saying so. Thanks! (And thanks to Markus and Douglas for the last-call reviews!) From nobody Mon Jan 12 10:24:02 2015 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A3AD1ACD2B for ; Mon, 12 Jan 2015 10:24:00 -0800 (PST) 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] autolearn=ham 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 6He0AKFbH6bX; Mon, 12 Jan 2015 10:23:58 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C017E1AC3BC; Mon, 12 Jan 2015 10:23:58 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: dnssd@ietf.org, dnssd-chairs@tools.ietf.org, draft-ietf-dnssd-requirements.all@tools.ietf.org, tjc@ecs.soton.ac.uk X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150112182358.7108.43698.idtracker@ietfa.amsl.com> Date: Mon, 12 Jan 2015 10:23:58 -0800 From: IETF Secretariat Archived-At: Subject: [dnssd] ID Tracker State Update Notice: X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2015 18:24:00 -0000 IESG state changed to Waiting for AD Go-Ahead::Revised I-D Needed from Waiting for Writeup Waiting for authors to address Sheng's, Douglas' and Markus' comments. ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-dnssd-requirements/ From nobody Fri Jan 16 06:56:08 2015 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85B961ACD7E for ; Fri, 16 Jan 2015 06:56:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.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, GB_I_LETTER=-2, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 HHfo1IR_SJKX for ; Fri, 16 Jan 2015 06:56:02 -0800 (PST) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E056A1ACD73 for ; Fri, 16 Jan 2015 06:56:01 -0800 (PST) Received: by mail-wg0-f47.google.com with SMTP id l18so3764231wgh.6 for ; Fri, 16 Jan 2015 06:56:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=S+ZM0TK3RkoTC9mRV6KsmcMHiPB1TuAot1nF2yV56GI=; b=HEaXXafcJh/SUMlew4ZWGWCv2/Wy03uHVrSQETFAaKZkUq1VbM232tH41IY7FXZ1ve n7lGllesxM/TafEFxDr/6Yg3NVFJOVcvInwrhkcENtbpTbI/nkFNAOUU9cAy5wdiXBgG nl00a5p1zUdNaCpUt9az1N+/FJCUFe2yrNfwX1HhOnFcZt3+5LSooGnxrR9m9mHTs0Bc E3l2aN6NRWZMKsOi4im3M/R5cWvKs186s7zfnAucj6Nb1awaS1uizthRB13QJDSGwVos qymOzQRHsZE3he7LRMP6aCN4Ydj8GCjLMXWDGh3OVXP5dZgVJQjtezmgKYP84Fmg7Ii3 Z7aA== MIME-Version: 1.0 X-Received: by 10.194.62.19 with SMTP id u19mr30801658wjr.0.1421420160658; Fri, 16 Jan 2015 06:56:00 -0800 (PST) Received: by 10.194.236.106 with HTTP; Fri, 16 Jan 2015 06:56:00 -0800 (PST) Date: Fri, 16 Jan 2015 15:56:00 +0100 Message-ID: From: Daniel Migault To: dnssd Content-Type: multipart/alternative; boundary=047d7ba97cd4c0b4bd050cc62b88 Archived-At: Subject: [dnssd] comments draft-sullivan-dnssd-mdns-dns-interop-01 X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jan 2015 14:56:05 -0000 --047d7ba97cd4c0b4bd050cc62b88 Content-Type: text/plain; charset=UTF-8 Hi Andrew, By the way, thank you writing this document. Here are some small comments on the draft. BR, Daniel Comment 1: "That convention is the reason behind the development of Internationalized Domain Names for Applications (IDNA2008, [RFC5890], [RFC5891], [RFC5892],[RFC5893], [RFC5894], [RFC5895])." I think we should add one sentence to mention that RFC0952 was too restrictive. I would propose something like this: "This convention is too restrictive and prevent many native language to use their specific characters." Comment 2: "It does not restrict which Unicode code points may be used in those..." Unicode has not been defined previously. Maybe which should clarify this by saying that Unicode is the set of UTF-8/16/32 or simply removing Unicode the word Unicode in the sentence. I fell that in this document Unicode is UTF-8. Comment 3: "As a result, the sorts of application considerations that are appropriate to the general-purpose DNS name, and that resulted in the A-label/ U-label (see below) in IDNA2008, are not the right approach for DNS- SD." This is unclear to me what is behind that. Comment 4: 1.1. Conventions and terms used in this document I think we should also add that user is familiar with the mDNS naming convention. Maybe that is fine now as we define the owner name of DNS-SD. Comment 5: 2. Requirements for a profile for label interoperation I do not see specified how a profile will operate between the two naming convention. Regarding the current document, I would remove the word "profile". Comment 6: I would move to the beginning of section 2 the text below (instead of section3). DNS-SD specifies three portions of the owner name for a DNS-SD resource record. These are the portion, the portion, and the . The owner name made of these three parts is called the Service Instance Name. Comment 7: I would also provide an introduction to the section. I would probably start section 2 with something like that: "The goal of this section is to list requirements to ensure that a succession of labels is appropriately considered by either a DNS resolver or by a DNS-SD resolver. More specifically, there is not a one-to-one matching between IDNA2008 and UTF-8 and UTF-8 contains codes that do not belong to IDNA2008. As a result, requirements address the following goals: 1- An IDNA2008/LDH succession of labels formatted for DNS resolvers should not be considered as UTF-8 by DNS-SD resolvers. [I think the document does not detail that point] 2- An UTF-8 succession of label format for DNS-SD resolver should be handle in a defined way by DNS-SD resolver when interacting with the DNS. This requires the DNS-SD resolver to handle this succession of labels and either convert it to an acceptable IDNA format for DNS resolvers, to handle it independently of any DNS library, or to consider it as an opaque binary string." Comment 8: "Only some portions are implicated. In any case, if a given portion is implicated, the profile will need to apply to all labels in that portion." Maybe we should explain why we consider each portion individually. I propose the following text: Each of the portion have a specific function and is handled differently by the resolvers For example, the Instance portion target the end user, the Service portion the DNS-SD service itself, while the Domain portion provides a point of attachment to the DNS architecture. As a result, requirements for interoperability between DNS and mDNS shoudl be done on a portion basis. Each portion may be constituted by one o multiple label, in which case requirements apply to all the labels of the portion. Comment 9: Section 3.3 "The first of these is rejected because it represents a potentially significant increase in DNS lookup traffic for no value. ..." My understanding is that we will have multiple ways to represent a single entity. This may also raise some security issue. (Naming collision) Comment 10: Could the DNS-SD resolver perform a conversion UTF-8 to IDNA. Of ccourse this would consider some restriction on the codes used. The document specifies U-labels cannot contain upper case letters. What is not clear is that this is the only constraint. -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 --047d7ba97cd4c0b4bd050cc62b88 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Andrew,

By the way, thank y= ou writing this document. Here are some small comments on the draft.
BR,
Daniel

Comment 1:

"That c= onvention is the reason behind the development of Internationalized Domain = Names for Applications (IDNA2008, [RFC5890], [RFC5891], [RFC5892],[RFC5893]= , [RFC5894], [RFC5895])."

I think we should add one sentence t= o mention that RFC0952 was too restrictive.=C2=A0 I would propose something= like this:
=C2=A0
"This convention is too restrictive and preve= nt many native language to use their specific characters."


= Comment 2:

"It does not restrict which Unicode code points may= be used in those..."
Unicode has not been defined previously. Mayb= e which should clarify this by saying that Unicode is the set of UTF-8/16/3= 2 or simply removing Unicode the word Unicode in the sentence. I fell that = in this document Unicode is UTF-8.

Comment 3:

"As a res= ult, the sorts of application considerations that are appropriate
=C2=A0= =C2=A0 to the general-purpose DNS name, and that resulted in the A-label/=C2=A0=C2=A0 U-label (see below) in IDNA2008, are not the right approach = for DNS-
=C2=A0=C2=A0 SD."
This is unclear to me what is behind = that.=C2=A0

Comment 4:

1.1. Conventions and terms used in th= is document

I think we should also add that user is familiar with th= e mDNS naming convention. Maybe that is fine now as we define the owner nam= e of DNS-SD.

Comment 5:

2. Requirements for a profile for lab= el interoperation

I do not see specified how a profile will operate = between the two naming convention. Regarding the current document, I would = remove the word "profile".

Comment 6:

I would move= to the beginning of section 2 the text below (instead of section3).
=C2= =A0
=C2=A0=C2=A0 DNS-SD specifies three portions of the owner name for a= DNS-SD
=C2=A0=C2=A0 resource record.=C2=A0 These are the <Instance&g= t; portion, the <Service>
=C2=A0=C2=A0 portion, and the <Domain= >.=C2=A0 The owner name made of these three parts
=C2=A0=C2=A0 is cal= led the Service Instance Name.

Comment 7:

I would also provi= de an introduction to the section. I would probably start section 2 with so= mething like that:
=C2=A0
"The goal of this section is to list r= equirements to ensure that a succession of labels is appropriately consider= ed by either a DNS resolver or by a DNS-SD resolver. More specifically, the= re is not a one-to-one matching between IDNA2008 and UTF-8 and UTF-8 contai= ns codes that do not belong to IDNA2008. As a result, requirements address = the following goals:
1- An IDNA2008/LDH succession of labels formatted f= or DNS resolvers should not be considered as UTF-8 by DNS-SD resolvers. [I = think the document does not detail that point]
2- An UTF-8 succession of= label format for DNS-SD resolver should be handle in a defined way by DNS-= SD resolver when interacting with the DNS. This requires the DNS-SD resolve= r to handle this succession of labels and either convert it to an acceptabl= e IDNA format for DNS resolvers, to handle it independently of any DNS libr= ary, or to consider it as an opaque binary string."


Comment= 8:

=C2=A0=C2=A0 "Only some portions are implicated.=C2=A0 In a= ny case, if a
=C2=A0=C2=A0 given portion is implicated, the profile will= need to apply to all
=C2=A0=C2=A0 labels in that portion."

= Maybe we should explain why we consider each portion individually. I propos= e the following text:

Each of the portion have a specific function a= nd is handled differently by the resolvers For example, the Instance portio= n target the end user, the Service portion the DNS-SD service itself, while= the Domain portion provides a point of attachment to the DNS architecture.= As a result, requirements for interoperability between DNS and mDNS shoudl= be done on a portion basis. Each portion may be constituted by one o multi= ple label, in which case requirements apply to all the labels of the portio= n.


Comment 9:

Section 3.3
=C2=A0
"The first = of these is rejected because it represents a potentially
significant inc= rease in DNS lookup traffic for no value. ..."

My understanding= is that we will have multiple ways to represent a single entity. This may = also raise some security issue. (Naming collision)

Comment 10:
<= br>Could the DNS-SD resolver perform a conversion UTF-8 to IDNA. Of ccourse= this would consider some restriction on the codes used.

The docume= nt specifies U-labels cannot contain upper case letters. What is not clear = is that this is the only constraint.




--
Daniel Migault
Orange Labs --= Security
+33 6 70 72 69 58
--047d7ba97cd4c0b4bd050cc62b88-- From nobody Mon Jan 19 04:08:13 2015 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44F6C1B2A2E; Mon, 19 Jan 2015 04:08:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779] autolearn=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 V5Lm20S1Die5; Mon, 19 Jan 2015 04:08:05 -0800 (PST) Received: from jenni1.inet.fi (mta-out1.inet.fi [62.71.2.203]) by ietfa.amsl.com (Postfix) with ESMTP id ED38E1AD34D; Mon, 19 Jan 2015 04:08:04 -0800 (PST) Received: from kosame.lan (80.220.64.126) by jenni1.inet.fi (8.5.142.08) (authenticated as stenma-47) id 54AD8B92015018FC; Mon, 19 Jan 2015 14:08:03 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Markus Stenberg Date: Mon, 19 Jan 2015 14:08:03 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150119120637.22965.74544.idtracker@ietfa.amsl.com> To: HOMENET , dnssd@ietf.org X-Mailer: Apple Mail (2.1993) Archived-At: Cc: Markus Stenberg Subject: [dnssd] Fwd: New Version Notification for draft-stenberg-homenet-dnssd-hybrid-proxy-zeroconf-02.txt X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jan 2015 12:08:07 -0000 Old draft had expired, and the L bit was added in some HNCP version (-02 = or -03) so I added it here too. > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > To: Markus Stenberg , "Markus Stenberg" = > Subject: New Version Notification for = draft-stenberg-homenet-dnssd-hybrid-proxy-zeroconf-02.txt > Date: 19.1.2015 14.06.37 UTC+2 >=20 >=20 > A new version of I-D, = draft-stenberg-homenet-dnssd-hybrid-proxy-zeroconf-02.txt > has been successfully submitted by Markus Stenberg and posted to the > IETF repository. >=20 > Name: draft-stenberg-homenet-dnssd-hybrid-proxy-zeroconf > Revision: 02 > Title: Auto-Configuration of a Network of Hybrid = Unicast/Multicast DNS-Based Service Discovery Proxy Nodes > Document date: 2015-01-19 > Group: Individual Submission > Pages: 15 > URL: = http://www.ietf.org/internet-drafts/draft-stenberg-homenet-dnssd-hybrid-pr= oxy-zeroconf-02.txt > Status: = https://datatracker.ietf.org/doc/draft-stenberg-homenet-dnssd-hybrid-proxy= -zeroconf/ > Htmlized: = http://tools.ietf.org/html/draft-stenberg-homenet-dnssd-hybrid-proxy-zeroc= onf-02 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-stenberg-homenet-dnssd-hybrid-pro= xy-zeroconf-02 >=20 > Abstract: > This document describes how a proxy functioning between Unicast DNS- > Based Service Discovery and Multicast DNS can be automatically > configured using an arbitrary network-level state sharing mechanism. >=20 >=20 >=20 >=20 > 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. >=20 > The IETF Secretariat >=20