Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-broadcast-consider-01.txt

From: Rolf Winter <[email-masked]>
Date: Wed, 2 Nov 2016 11:34:24 +0100

Hi Brian,

great that you found the document useful. Since the 00 version a lot has 
changed, and you might want to look at it again. We will look at RFC 
5374 and see where it should be mentioned in the document. Thanks for 
the hint!

Best,

Rolf

Am 10/31/16 um 8:25 PM schrieb Brian E Carpenter:
> Rolf,
>
> I read this draft (the -00 version) recently, since I'm co-author of
> draft-ietf-anima-grasp, which relies heavily on link-local multicast. I did
> find it useful, although I didn't in the end change anything as a result.
>
> Should you mention the MSEC work and RFC 5374 in particular?
>
> Regards
>    Brian Carpenter
>
> On 01/11/2016 03:08, Rolf Winter wrote:
>> Hi,
>>
>> Apologies, but I screwed up the draft naming convention and just
>> uploaded the 00 and a 01 version with correct naming. The 00 version is
>> the one that was adopted by the WG, the 01 version now addresses the
>> comments made by Eliot and Stephane.
>>
>> Sorry for the confusion.
>>
>> Best,
>>
>> Rolf
>>
>> Am 10/31/16 um 3:05 PM schrieb [email-masked]:
>>>
>>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>> This draft is a work item of the Internet Area Working Group of the IETF.
>>>
>>>         Title           : Privacy considerations for IP broadcast and multicast protocol designers
>>>         Authors         : Rolf Winter
>>>                           Michael Faath
>>>                           Fabian Weisshaar
>>> 	Filename        : draft-ietf-intarea-broadcast-consider-01.txt
>>> 	Pages           : 10
>>> 	Date            : 2016-10-31
>>>
>>> Abstract:
>>>    A number of application-layer protocols make use of IP broadcasts or
>>>    multicast messages for functions like local service discovery or name
>>>    resolution.  Some of these functions can only be implemented
>>>    efficiently using such mechanisms.  When using broadcasts or
>>>    multicast messages, a passive observer in the same broadcast/
>>>    multicast domain can trivially record these messages and analyze
>>>    their content.  Therefore, broadcast/multicast protocol designers
>>>    need to take special care when designing their protocols.
>>>
>>>
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-ietf-intarea-broadcast-consider/
>>>
>>> There's also a htmlized version available at:
>>> https://tools.ietf.org/html/draft-ietf-intarea-broadcast-consider-01
>>>
>>> A diff from the previous version is available at:
>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-intarea-broadcast-consider-01
>>>
>>>
>>> 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.
>>>
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>>
>>> _______________________________________________
>>> Int-area mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/int-area
>>>
>>
>> _______________________________________________
>> Int-area mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/int-area
>>

---

From: Eliot Lear <[email-masked]>
Date: Wed, 2 Nov 2016 11:51:15 +0100

Hi Rolf,

I apologize.  I had entirely forgotten about this draft.  I've put out
very much a -00 of my own draft-lear-network-helps-01.txt.  The key
point of my draft, to expropriate from Ecclesiastes,  is simply this:
there is a time for sharing.  But when doing so, (a) do so by design,
(b) use encryption where practicable, and (c) consider the tradeoffs (we
must acknowledge that there are tradeoffs, as engineers).   It is
ABSOLUTELY drafty, but I would like the idea of combining some
concepts.  What do people think?  I know mine stretches a bit beyond the
intarea...

Eliot

On 10/31/16 3:08 PM, Rolf Winter wrote:
> uploaded the 00 and a 01 version with correct naming. The 00 version
> is the one that was adopted by the WG, the 01 version now addresses
> the comments made by Eliot and Stephane.
>
> Sorry for the confusion.
>
> Best,
>
> Rolf
>

---

From: Joe Touch <[email-masked]>
Date: Wed, 2 Nov 2016 08:26:51 -0700

Hi, all,

I thought I mentioned this before, but regardless:

This doc should include a discussion of RFC3819, which explains where
and why broadcast is important in the Internet architecture.

Joe

On 11/2/2016 3:34 AM, Rolf Winter wrote:
> Hi Brian,
>
> great that you found the document useful. Since the 00 version a lot
> has changed, and you might want to look at it again. We will look at
> RFC 5374 and see where it should be mentioned in the document. Thanks
> for the hint!
>
> Best,
>
> Rolf
>

---

From: Rolf Winter <[email-masked]>
Date: Thu, 3 Nov 2016 16:02:48 +0100

Hi,

another thing we will look at for the next revision. Sorry that it 
slipped through.

Best,

Rolf