Subject: [Int-area] WGLC for draft-ietf-intarea-broadcast-consider

From: Juan Carlos Zuniga <[email-masked]>
Date: Mon, 6 Mar 2017 22:09:55 +0100

Dear Int-Area WG,

A review of draft-ietf-intarea-broadcast-consider has been published. Since
there was good support for this document from the beginning and the new
version addresses the pending comments, we believe it is ready for WG Last
Call.

This email starts an Int-Area WG Last Call on:

https://tools.ietf.org/html/draft-ietf-intarea-broadcast-consider-02

Please respond to this email to support the document and/or send comments
by 2017-03-20.

In addition, to satisfy RFC 6702 "Promoting Compliance with Intellectual
Property Rights (IPR)":
Are you personally aware of any IPR that applies to
draft-ietf-intarea-hostname-practice?
If so, has this IPR been disclosed in compliance with IETF IPR rules?
(See RFCs 3979, 4879, 3669, and 5378 for more details.)

Best,

Juan Carlos Zuniga & Wassim Haddad
(Int-Area WG co-chairs)

---

From: Rolf Winter <[email-masked]>
Date: Tue, 7 Mar 2017 14:28:33 +0100

Dear chairs,

I am not aware of any IPR related to this document.

Best,

Rolf

Am 3/6/17 um 10:09 PM schrieb Juan Carlos Zuniga:
> Dear Int-Area WG,
>
> A review of draft-ietf-intarea-broadcast-consider has been published.
> Since there was good support for this document from the beginning and
> the new version addresses the pending comments, we believe it is ready
> for WG Last Call.
>
> Please respond to this email to support the document and/or send
> comments by 2017-03-20.
>
> _______________________________________________
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area
>

---

From: Joe Touch <[email-masked]>
Date: Tue, 7 Mar 2017 11:35:47 -0800

Hi, all,

I think it would be useful to include a section explaining what is meant
by broadcast and multicast, and the current state of these.  In
particular, highlighting the following as context for these considerations:

    - all 1's broadcast is supposed to never transit routers (RFC1812)

    - as a default, subnet-directed broadcast shouldn't be going past
routers either (RFC2644)

    - multicast in IPv6 may have limited scope (e.g., not all uses are
to "all-nodes")

    - duplicate address detection in IPv6 sends only to the multicast
group that would be joined by another party with the same address

    - relays, such as for DHCP, proxy ARP, etc., can extend the scope of
broadcast and multicast beyond the originator's original intent

These each limit (or extend) who can see a broadcast/multicast message -
and can be used in consideration of the extent to which information in
the message leaks out.

I.e., "all broadcast is not equal", and "all multicast is not equal".

Joe

On 3/6/2017 1:09 PM, Juan Carlos Zuniga wrote:
> In addition, to satisfy RFC 6702 "Promoting Compliance with
> Intellectual Property Rights (IPR)":

---

From: Joe Touch <[email-masked]>
Date: Tue, 7 Mar 2017 11:39:38 -0800

FWIW, in addition, it would be useful to at least mention that
LANE-style alternatives (RFC2225) to broadcast have similar issues with
sharing information, but only with the centralized (broadcast/multicast)
emulating server.

Joe

On 3/7/2017 11:35 AM, Joe Touch wrote:
>
> Hi, all,
>
> I think it would be useful to include a section explaining what is
> meant by broadcast and multicast, and the current state of these.  In
>     - relays, such as for DHCP, proxy ARP, etc., can extend the scope
> of broadcast and multicast beyond the originator's original intent
>
> These each limit (or extend) who can see a broadcast/multicast message
> - and can be used in consideration of the extent to which information
> in the message leaks out.
>
>> the new version addresses the pending comments, we believe it is
>> ready for WG Last Call.
>>

---

From: t.petch <[email-masked]>
Date: Thu, 9 Mar 2017 17:13:01 +0000

I wonder if the mix of SHOULD and should is intentional.

And I cannot recall seeing RFC2119 as an Informative Reference before.

s.1
/  entierly/  entirely/

And I am surprised at the lack of mention of IPv6 which did its bit for
the planet by eliminating broadcast.

Tom Petch

----- Original Message -----
From: "Juan Carlos Zuniga" <[email-masked]>
To: <[email-masked]>
Sent: Monday, March 06, 2017 9:09 PM

> A review of draft-ietf-intarea-broadcast-consider has been published.
Since
> Please respond to this email to support the document and/or send
comments
> In addition, to satisfy RFC 6702 "Promoting Compliance with
Intellectual
> Juan Carlos Zuniga & Wassim Haddad

------------------------------------------------------------------------
--------

---

From: Joe Touch <[email-masked]>
Date: Thu, 9 Mar 2017 10:42:07 -0800

> the planet by eliminating broadcast.

IPv4 had two kinds of broadcast:
    - all 1's (like IPv6 all-nodes link local)
    - subnet-directed, which RFC2644 turned into a subset of all 1's on
a link

IPv6 has the following kinds of multicast that are effectively broadcast:
    - all-nodes link-local (like IPv4 all 1's)
    - all-nodes site-local (arguably similar to subnet-directed, but
un-doing the one-hop restriction of RFC2644)
    - all the multicast addresses that work over other scopes, limited
only by function
        e.g., NTP can be "broadcast" everywhere

And, depending on implementation, IPv6 anycast might use broadcast too.

So IPv6 didn't remove any of IPv4's broadcast; it just gave alternatives
that may or may not be used - some of which can "broadcast" even wider.

Joe

---

From: Rolf Winter <[email-masked]>
Date: Fri, 10 Mar 2017 09:35:30 +0100

Tom,

see inline.

> And I cannot recall seeing RFC2119 as an Informative Reference before.

Will be fixed.

> /  entierly/  entirely/

thanks, will be fixed, too.

> the planet by eliminating broadcast.

Multicast in many cases is not any better from the perspective of the 
size of the receiver group, which is why this traffic is more sensitive 
to privacy concerns. The document therefore discusses both broadcast and 
multicast. We will update the document, including a section on broadcast 
and multicast properties as suggested by Joe earlier. It should be much 
clearer then.

Thanks,

Rolf