Re: [RTG-DIR] [Int-area] Rtgdir telechat review of draft-ietf-intarea-broadcast-consider-05

"Carlos Pignataro (cpignata)" <cpignata@cisco.com> Tue, 16 January 2018 05:16 UTC

Return-Path: <cpignata@cisco.com>
X-Original-To: rtg-dir@ietfa.amsl.com
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 973C21267BB; Mon, 15 Jan 2018 21:16:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.53
X-Spam-Level:
X-Spam-Status: No, score=-14.53 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 k7NAuIUUql9a; Mon, 15 Jan 2018 21:16:52 -0800 (PST)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B22D124D68; Mon, 15 Jan 2018 21:16:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11022; q=dns/txt; s=iport; t=1516079812; x=1517289412; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=WVi+w4KqHqZ/2CPvrMX7o7BT0zdGwaM5ssgtvaNy4vc=; b=XJaAlWevh6/99clRzslHrAb6kRjgAYRneZFPBycuZ1WWA08EAPJTlT4x WKY2j7+en5ZD/0TjDqEKdTSkOF/azf4zY+XT+ErGnbp1Cgth0PmLcfL2t W6Z2/N10u3V22mCpXZP8b9xoGQ2Du7stYSwbcxqs0Mj0S8Od4PrOhJJ4Q U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0BFAgBAil1a/51dJa1cGQEBAQEBAQEBAQEBAQcBAQEBAYNBgVonB4QMmQOTXYdnCoU7AhqEN0MUAQEBAQEBAQEBayiFJAYjTwcQAgEIPwMCAgIwFBECBA4FiU9kqAKCJ4lKAQEBAQEBAQEBAQEBAQEBAQEBAQEBHYZRgVeCEoMFgy8EhQYxgjQFmXKJcgKVSYIZhh2LWpZ4AhEZAYE7ATYigVBvFT0qAYF/glQcGYFOeIw3gRcBAQE
X-IronPort-AV: E=Sophos; i="5.46,366,1511827200"; d="scan'208,217"; a="57101336"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Jan 2018 05:16:51 +0000
Received: from XCH-RTP-017.cisco.com (xch-rtp-017.cisco.com [64.101.220.157]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id w0G5Go0h004774 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 16 Jan 2018 05:16:50 GMT
Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-017.cisco.com (64.101.220.157) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 16 Jan 2018 00:16:49 -0500
Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1320.000; Tue, 16 Jan 2018 00:16:50 -0500
From: "Carlos Pignataro (cpignata)" <cpignata@cisco.com>
To: Stephane Bortzmeyer <bortzmeyer@nic.fr>
CC: "rtg-dir@ietf.org" <rtg-dir@ietf.org>, "int-area@ietf.org" <int-area@ietf.org>, "draft-ietf-intarea-broadcast-consider.all@ietf.org" <draft-ietf-intarea-broadcast-consider.all@ietf.org>
Thread-Topic: [RTG-DIR] [Int-area] Rtgdir telechat review of draft-ietf-intarea-broadcast-consider-05
Thread-Index: AQHTjO8UnicGv65GJEC9DfSUsx13xKN1dTWAgADXKQA=
Date: Tue, 16 Jan 2018 05:16:50 +0000
Message-ID: <6FA12EB1-F02D-491E-BC0E-7E2BA84277D2@cisco.com>
References: <151590364970.3170.13650222639051565830@ietfa.amsl.com> <20180115162643.tm63bmzizoo4xtgv@nic.fr>
In-Reply-To: <20180115162643.tm63bmzizoo4xtgv@nic.fr>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.70.231.26]
Content-Type: multipart/alternative; boundary="_000_6FA12EB1F02D491EBC0E7E2BA84277D2ciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-dir/ngip_SVyK1jxtsWtHzpD7i6Lgdw>
Subject: Re: [RTG-DIR] [Int-area] Rtgdir telechat review of draft-ietf-intarea-broadcast-consider-05
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Routing Area Directorate <rtg-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-dir/>
List-Post: <mailto:rtg-dir@ietf.org>
List-Help: <mailto:rtg-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Jan 2018 05:16:54 -0000

Hi, Stephane,

Thanks for the follow-up, please see inline.

On Jan 16, 2018, at 1:26 AM, Stephane Bortzmeyer <bortzmeyer@nic.fr<mailto:bortzmeyer@nic.fr>> wrote:

On Sat, Jan 13, 2018 at 08:20:49PM -0800,
Carlos Pignataro <cpignata@cisco.com<mailto:cpignata@cisco.com>> wrote
a message of 118 lines which said:

The document talks about "a passive observer in the same
broadcast/multicast domain". It does not seem to cover, however, how
exactly is bcast/mcast different from unicast, when the passive
observer has an interface is promiscuous mode or has a packet
capture library.

Most modern local networks are switched. It means a "passive observer
in promiscuous mode" cannot see the unicast traffic (except the one
directed to her, of course), only the broadcast one. Of course, one
can always tap an intercontinental fiber optic :-) but I believe the
draft addresses the case of a more ordinary observer, listening on an
Ethernet or WiFi, without physically breaking of anything.

It seems to me, reading in-between lines a bit (and therefore non-authoritatively), that the draft is mostly scoped for WiFi networks. This seems to be supported by the first sentence of the second paragraph of the Abstract of the paper:

“To answer this question, the broadcast traffic of two fairly large wireless networks was analyzed."

But the main point is that the draft does not describe what you are saying above, nor the relationship between the characteristics of the access technology, the use of IP-layer [b|m]cast, and the use of identifiers embedded at the application level.


One of the demos I like to make, when talking about privacy in
meetings for non-IETF people, is to enumerate the list of devices and
names I see :-) This is possible only if this information is
broadcasted.


Same as above, my comment is that the text in the draft seems to lack scope specificity. Clearly the subject matter is important. But the draft does not seem to unequivocally explain (I may have missed it) the intersection between service, resource, and application discovery, the use of identifiers, and the access — all happening at a different layer — for the demo.

Based on this citation, should [TRAC2016] be Normative? And is it readily
available?

It's on Sci-Hub :-) I attach it here.
<faath2016.pdf>

Scanning through the paper, it seems that the methodology used is important to understand the conclusions (i.e., normative?).

Sorry for not being clear, a pointer to the paper on the references would help.

Thanks!

—
Carlos Pignataro, carlos@cisco.com<mailto:carlos@cisco.com>

“Sometimes I use big words that I do not fully understand, to make myself sound more photosynthesis."