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."
- [RTG-DIR] Rtgdir telechat review of draft-ietf-in… Carlos Pignataro
- Re: [RTG-DIR] [Int-area] Rtgdir telechat review o… Stephane Bortzmeyer
- Re: [RTG-DIR] Rtgdir telechat review of draft-iet… Rolf Winter
- Re: [RTG-DIR] [Int-area] Rtgdir telechat review o… Carlos Pignataro (cpignata)
- Re: [RTG-DIR] Rtgdir telechat review of draft-iet… Carlos Pignataro (cpignata)
- Re: [RTG-DIR] Rtgdir telechat review of draft-iet… Rolf Winter