Subject: [Idr] WG adoption call for draft-ymbk-idr-bgp-open-policy (5/20 to 6/3/2017).

From: "Susan Hares" <[email-masked]>
Date: Sat, 20 May 2017 05:33:52 -0400

This begins a 2 week WG Adoption call for draft-ymbk-idr-bgp-open-policy
(5/20 to 6/3/2017) 

The authors should indicate if they know of any IPR related to this
document.  You can find the document at: 

https://datatracker.ietf.org/doc/draft-ymbk-idr-bgp-open-policy/

Sue Hares

---

From: Randy Bush <[email-masked]>
Date: Sun, 21 May 2017 14:18:55 +0900

> document.  You can find the document at: 

hi sue,

i know of no ipr on this document

randy, who so old and stuck in the mud that he does not believe authors should declare support

---

From: Alexander Azimov <[email-masked]>
Date: Mon, 22 May 2017 16:22:05 +0300

Hi Susan,

I am not aware of any IPR.

2017-05-21 8:18 GMT+03:00 Randy Bush <[email-masked]>:

> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr
>

-- 
| Alexander Azimov  | HLL l QRATOR
| tel.: +7 499 241 81 92
| mob.: +7 915 360 08 86
| skype: mitradir
| mailto: [email-masked]
| visit: www.qrator.net

---

From: Matthias Waehlisch <[email-masked]>
Date: Wed, 24 May 2017 00:00:52 +0200

Hi,

  +1 for adoption. I read the document and like the slim "algorithmic" 
approach, which gives an additional perspective compared to 
draft-ietf-idr-route-leak-detection-mitigation.

Cheers
  matthias

On Sat, 20 May 2017, Susan Hares wrote:

> 
> This begins a 2 week WG Adoption call for draft-ymbk-idr-bgp-open-policy (5/20 to 6/3/2017)
> 
>  
> 
> The authors should indicate if they know of any IPR related to this document.  You can find the
> document at:
> 
>  
> 

-- 
Matthias Waehlisch
.  Freie Universitaet Berlin, Computer Science
.. http://www.cs.fu-berlin.de/~waehl

---

From: Daniel Ginsburg <[email-masked]>
Date: Wed, 24 May 2017 08:48:55 +0300

+1 Yes/Support

On May 24, 2017 01:01, "Matthias Waehlisch" <[email-masked]>
wrote:

Hi,

Cheers
  matthias

(5/20 to 6/3/2017)
> The authors should indicate if they know of any IPR related to this
document.  You can find the

---

From: Brian Dickson <[email-masked]>
Date: Wed, 24 May 2017 13:46:09 -0700

Support.

Brian

---

From: "Carlos M. Martinez" <[email-masked]>
Date: Tue, 30 May 2017 11:43:12 -0300

Support adoption

---

From: <[email-masked]>
Date: Tue, 30 May 2017 16:27:13 +0000

Hi Sue, authors, all,

Unfortunately, I'm not up-to-date on this subject, so please take my comments with a grain of salt.

Support.
As it looks like a valid idea, with incremental deployment and incremental benefits.

Possible comments:
- possibly, there could be additional usage/value if the iOTC attribute were carrying the role within the AS, rather than being only a flag. For example it could be used in routing policies (as a read-only-memory) e.g. to set the preference of routes. Indeed, my understanding is that this info is double checked hence more reliable than a BGP community that the receiver could set with no additional checks. So a priori a better source of info for a routing policy
- a priori, as per current text, the iOTC attribute seems advertised over EBGP session and not removed on the reception side. I'm not sure whether this is a design goal or a bug.
- Possibly, the "Strict mode" could be the only one/the mandated behavior. To allow for backward compatibility, the non-compliant peer could tag routes with "well-known" BGP communities, to be defined by this document, and indicating the role (on a per route basis).

Regards,
--Bruno

From: Idr [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: Saturday, May 20, 2017 11:34 AM
To: 'idr wg'
Subject: [Idr] WG adoption call for draft-ymbk-idr-bgp-open-policy (5/20 to 6/3/2017).

The authors should indicate if they know of any IPR related to this document.  You can find the document at:

Sue Hares

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.