Re: [dnssd] Barry Leiba's Yes on draft-ietf-dnssd-prireq-05: (with COMMENT)

Christian Huitema <huitema@huitema.net> Wed, 26 February 2020 05:02 UTC

Return-Path: <huitema@huitema.net>
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 144243A0D83 for <dnssd@ietfa.amsl.com>; Tue, 25 Feb 2020 21:02:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 Dy8ySBrW4thq for <dnssd@ietfa.amsl.com>; Tue, 25 Feb 2020 21:02:03 -0800 (PST)
Received: from mx36-out10.antispamcloud.com (mx36-out10.antispamcloud.com [209.126.121.30]) (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 EFA323A0D33 for <dnssd@ietf.org>; Tue, 25 Feb 2020 21:02:02 -0800 (PST)
Received: from xse432.mail2web.com ([66.113.197.178] helo=xse.mail2web.com) by mx170.antispamcloud.com with esmtp (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1j6oWs-000J1E-0x for dnssd@ietf.org; Wed, 26 Feb 2020 05:42:39 +0100
Received: from xsmtp21.mail2web.com (unknown [10.100.68.60]) by xse.mail2web.com (Postfix) with ESMTPS id 48S37b0Cr6z529Z for <dnssd@ietf.org>; Tue, 25 Feb 2020 20:42:35 -0800 (PST)
Received: from [10.5.2.31] (helo=xmail09.myhosting.com) by xsmtp21.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1j6oWo-0000E9-Se for dnssd@ietf.org; Tue, 25 Feb 2020 20:42:34 -0800
Received: (qmail 24489 invoked from network); 26 Feb 2020 04:42:34 -0000
Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.58.46.215]) (envelope-sender <huitema@huitema.net>) by xmail09.myhosting.com (qmail-ldap-1.03) with ESMTPA for <dschinazi.ietf@gmail.com>; 26 Feb 2020 04:42:34 -0000
To: Barry Leiba <barryleiba@computer.org>, The IESG <iesg@ietf.org>
Cc: draft-ietf-dnssd-prireq@ietf.org, dnssd-chairs@ietf.org, dnssd@ietf.org, David Schinazi <dschinazi.ietf@gmail.com>
References: <158267919299.11026.3193133978474704307.idtracker@ietfa.amsl.com>
From: Christian Huitema <huitema@huitema.net>
Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mQENBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAG0J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PokBOQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1a5AQ0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAYkCPgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8=
Message-ID: <640b12c8-a4be-0c0a-6760-e7fa02364fb7@huitema.net>
Date: Tue, 25 Feb 2020 20:42:39 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0
MIME-Version: 1.0
In-Reply-To: <158267919299.11026.3193133978474704307.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Originating-IP: 66.113.197.178
X-Spampanel-Domain: xsmtpout.mail2web.com
X-Spampanel-Username: 66.113.197.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.197.0/24@xsmtpout.mail2web.com
X-Spampanel-Outgoing-Class: unsure
X-Spampanel-Outgoing-Evidence: Combined (0.15)
X-Recommended-Action: accept
X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0eYBE/I2+wvb5IJ3WTuccampSDasLI4SayDByyq9LIhVUZbR67CQ7/vm /hHDJU4RXkTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDoeDwbaJnZ2TaZhv/Bk6d8Jj9 EvBvwu01uVCaGVBWGqtdvLx5KYAWSN549sC5h70a2rBNMmEsKEibQwSU1xBeOHButNDpi1WUXRkr He1vFsZaZad0VL/QynhFAlbT36L8Bo/amW5kihSpmXVC8ht5WQZ6weYgSzquK2hxskqXvy8woCTx LKweTbuJ+19zsyHVGVmhMAaQ/AfCRwRe7yHm5oY+NYmsSGn+svMubxnbgm1cr18FZBEPC2/c16Xd 7sC9aC4xteE1WLqGS9YoqrsZ2DyteN0e+ECCv9/f+GPymkgDVo7QBKA4MctKq4ifYPcXFRL2K3LA EfDXVOdt7wDbusYnuEVWSxKMHbU0zkNM3EElFDaoLuOPKc8gc82pKfhB7T02ZXdoQxMs//iOE4Fl hiCv9TR+UxzLZWL8hwGBjhoI3W+YcuHfP5PkZb5A+wE5qGdpH54Oa3V8I76VOEvlwLCanpZsarZa LIRpEqA8mZECoO4gCQkfvynnCsTu+Y7qY55nZvlhWdT03ric3ufdO7reFVMZHeVGIiZUgGBcYb32 ie80q3LAG2MiIaIREzT1xNjuO97khcUFBr/guEWv1bdCp3Zd9clP8wSiJZWbJCj+xRrjVmRxpGtS cvUmgj1LuUBMDB4bqTTFWoXNjuPDO12jZAOanSBpz6Rja2u/0jJLGJAvVDcbFpoDcCeICPWuh+Xw USsu3r8c/nSA6bEnnvysta6u1iHEyuS7GD1uvcq2dHZOyIPu+ID36td2YpU6JOYIJd4MvQ0Nf4Ec bvHO1diDanHV9KirFAIIecsyj+YNTo81GR+jDXFsz/ZQnbbTizvwlZsrbltGiZoUh+c+5pFVgpT1 b21uZVckGp0ccOa2XhkGbmsUNPNkere1WheNsVXmhO8BzADiszcWR9bz/SDtF09JpSbuuCeiIDK0 C/0=
X-Report-Abuse-To: spam@quarantine11.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/RxG_N_OE0wq3U7gA5rHhEY1n33E>
Subject: Re: [dnssd] Barry Leiba's Yes on draft-ietf-dnssd-prireq-05: (with COMMENT)
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." <dnssd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnssd>, <mailto:dnssd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnssd/>
List-Post: <mailto:dnssd@ietf.org>
List-Help: <mailto:dnssd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnssd>, <mailto:dnssd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Feb 2020 05:02:12 -0000

Thanks for the review, Barry. We will address your comments in the next
revision of the draft.

I am not enthusiastic about "normative references in informational
documents". I will wait for Eric's advice on that one, assuming that he
will carry the IESG consensus on that topic.

-- Christian Huitema

On 2/25/2020 5:06 PM, Barry Leiba via Datatracker wrote:
> Barry Leiba has entered the following ballot position for
> draft-ietf-dnssd-prireq-05: Yes
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-dnssd-prireq/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> It’s useful to have this analysis; thanks.  Just some editorial comments below.
>  Please consider them; none needs any explicit response.  Please take specific
> note of the last one, about the references.
>
> General: “i.e.” and “e.g.” always need a comma after them.
>
> — Section 1 —
>
>    There are cases when nodes connected to a network want to provide or
>    consume services without exposing their identity to the other parties
>
> Nit: “their identities” (or “a node… wants… its identity”)
>
>    Consider for example a traveler
>
> Nit: “Consider, for example, a traveler”
>
>    Disclosing Information  In this document "disclosing information" is
>       also focused on disclosure by data conveyed via messages on the
>       service discovery protocol layer.
>
> Do you mean “disclosure of data” (not “by”)?
>
> — Section 2 —
>
>    All these attackers can either be passive, i.e.
>    they just listen to network traffic they have access to, or active,
>    i.e. they additionally can craft and send (malicious) packets.
>
> Style: You decide, of course, but I find this easier to read with parentheses,
> rather than “i.e.”s:
>
> SUGGEST
>    All these attackers can either be passive (they
>    just listen to network traffic they have access to) or active
>    (they additionally can craft and send malicious packets).
> END
>
>    on-link  An on-link attacker is on the same network link as victim
>       devices engaging in service discovery; thus, the external attacker
>       is in the same multicast domain.
>
> The second line should say “on-link attacker”.
>
>    MITM  A Man in the Middle (MITM) attacker either controls (parts of)
>       a network link or can trick two parties to send traffic via him;
>
> Nit: “Man-in-the-Middle” needs hyphens when it modifies “attacker”.
> Style: I know that “him” matches “Man”, so maybe we should leave it as is. 
> Still, it jarred me.  I would say “via the attacker.”
>
> — Section 3.1.1 —
> I love the ASCII-art stick figures.  :-)
>
>    just for tracking people or as a preliminary to targeted attacks.
>
> “preliminary” isn’t a noun.  Maybe “preliminary step”, or maybe “preamble”?  Or
> you could remove “as a”, and it would work.  Yes, I think the last is the best
> fix here.
>
> — Section 3.1.2 —
>
>    such as
>    for example an airport's lounge.
>
> Nit: “for example” needs to be set off with commas before and after it.
>
> — Section 3.1.3 —
>
>    to further attacks, from theft to device specific hacking.
>
> Nit: hyphenate “device-specific”.
>
>    "fingerprint" of the person, allowing identification.
>
> Style: I would say “facilitating identification”, or maybe “risking
> identification”.
>
> — Section 3.2 —
>
>    This is mainly relevant for unicast based discovery
>
> Nit: hyphenate “unicast-based”.
>
> — Section 3.2.4 —
>
>    o  Some attributes like the paper size available in a printer,
>
> Fruit flies like a banana?  The attributes are not paticularly fond of
> anything: “Some attributes, such as the paper size available in a printer,”
>
>    Combinations of attributes have more information power than specific
>    attributes
>
> Style: I would say, “than individual attributes”
>
>    Information contained in TXT records does not only breach privacy
>
> Nit: make it “…records not only breaches privacy”
>
>    Further, TXT records often contain version information about services
>    allowing potential attackers
>
> You need a comma after “services” — otherwise, the meaning isn’t quite as you
> want it.
>
> — Section 3.2.5 —
>
>    An argument is sometimes made that devices providing services can be
>    identified by observing the local traffic, and that trying to hide
>    the presence of the service is futile.  However,
>
> Given what you say below this, I think it would help to emphasize the point
> here, so may I suggest this?:
>
> NEW
>    An argument is sometimes made that devices providing services can be
>    identified by observing the local traffic, and that trying to hide
>    the presence of the service is futile.  However, there are good
>    reasons for the doscovery service layer to avoid unnecessary exposure:
> END
>
> — Section 3.2.6 —
>
>    services, such as for example some private messaging services.
>
> “such as” already means “for example”, so you don’t need both.  I would just
> remove “for example”.
>
> — Section 3.4.1 —
>
>    can perform, the proxy may have some way to wake the device, as
>    implied in RFC6762 [RFC6762]
>
> 6762 is 50 pages-ish; do you mind adding a section to the citation to help the
> reader find the implication?
>
> — Section 3.4.2 —
>
>    Further it may cause an unnecessary level
>    of power consumption which is particularly problematic
>
> Nit: this needs a comma after “further” and another after “consumption”.
>
>    unauthorized observers, while also managing to do that efficiently.
>
> You’re missing an antecedent to “that”.  I think you need to say, “to do its
> job efficiently,” or something like that.
>
> — Section 3.4.3 —
>
>    establishment requires active participation of the user, such as
>    entering a password or PIN.
>
> I submit that “clicking OK” is also active participation.  Maybe “more
> significant participation” is better?
>
> — Section 4 —
>
>    lead to a solution that does not transmit privacy violating DNS-SD
>
> Nit: hyphenate “privacy-violating”.
>
>    mechanisms should be used on deeper layer network protocols and on
>    how to actually connect to services in a privacy preserving way,
>
> Nit: hyphenate “deeper-layer” and “privacy-preserving”.
>
> — Section 4.2 —
>
>    4.  Avoid disclosure of information about the services they offer to
>        unauthorized clients.
>
> This sounds like it’s talking about services that they offer to unauthorized
> clients.  I don’t actually think readers will misunderstand it, but they might
> trip over it.  Maybe move “to unauthorized clients” after “disclosure”?  That
> way, you can make the same change in bullet 3 and keep them parallel and clear.
>
> — Section 4.3 —
>
>        Further, it would
>        increase power consumption which is critical for IoT devices.
>
> Increased power consumption isn’t what’s critical; just the opposite.  Maybe
> “which is damaging to IoT devices.”
>
> — Section 7 —
> Do with this comment what you will: I’m one who believes that Informational
> documents do have Normative References.  Those are the references that are
> critical to the understanding of the document.  Clearly, the DNSSD and mDNS
> documents are in that category, and I think there are others.  You needn’t
> reply on this, and you needn’t do it if you disagree, but I think it would be
> best to identify the key documents that readers of this need to be familiar
> with, and move them into Normative References.
>
>
>