I presume that the authors will come to closure on the additional/changed
wording in 4.3.2, I'll start the publication request at this time noting
consensus was reached.
thanks!
On Thu, Mar 23, 2017 at 11:57 AM, Adam Chappell
wrote:
> Yes, agreed - 4.3.2 using the UN
> If ISPs do not turn this *on* on their customer connections, it will not
> do anything - and given that those ISPs that *need* to turn this on are
> the ones that are not caring today, I'm still not seeing why they would
> turn this on tomorrow.
not quite. if ntt and l3 told fiber@home "on or
On Thu, Mar 23, 2017 at 03:41:03PM +0100, Adam Chappell wrote:
> I think the focus on RFC1998 Sec. 4 and the desire to be a practical
> example, rather than an exhaustive list of possibilities is important.
> With that in mind, I wonder if section 4.3 should really encourage
> *location-based*
Gert Doering wrote on 23/03/2017 08:45:
> Please explain to me how this is going to work if "lazy upstream ISP"
> keeps being lazy, and does nothing.
I agree. However the motivation for the proposed solution comes from the
desire to fix the problem in the future when RPKI and BGPSEC are
I think the focus on RFC1998 Sec. 4 and the desire to be a practical
example, rather than an exhaustive list of possibilities is important.
With that in mind, I wonder if section 4.3 should really encourage
*location-based* manipulation of LOCAL_PREF?
(I must humbly acknowledge that the original
Brian, Sriram and Randy:
Let me suggest we take the rest of this discussion on these IDR two drafts
offline from IDR. The IDR Chairs noted when the
draft-ietf-idr-route-leak-detection mitigation was adopted that there was
overlap between you two documents. We also noted interests in
Hi,
On Thu, Mar 23, 2017 at 12:08:39AM +0200, Nick Hilliard wrote:
> Gert Doering wrote:
> > If ISPs do not turn this *on* on their customer connections, it will not
> > do anything - and given that those ISPs that *need* to turn this on are
> > the ones that are not caring today, I'm still not