it occurs to me that while this discussion is awesome, perhaps having it in
a thread not about the adoption of an already adopted draft would be good :)

(sadly gmail won't let me change the subject :( )

On Tue, Nov 1, 2016 at 9:29 PM, Brian Dickson <[email protected]
> wrote:

>
>
> On Tue, Nov 1, 2016 at 9:30 AM, Jeffrey Haas <[email protected]> wrote:
>
>> On Tue, Nov 01, 2016 at 05:23:38PM +0100, Job Snijders wrote:
>> > On Tue, Nov 01, 2016 at 11:07:19AM -0400, Jeffrey Haas wrote:
>> > > On Sun, Oct 30, 2016 at 05:10:01PM +0100, Job Snijders wrote:
>> > > > NEW2:
>> > > >     "Software MUST discard any routes from an EBGP peer, if no
>> import
>> > > >     policy was configured."
>> > >
>> > > I rather object to NEW2 and, if included, withdraw any support of this
>> > > draft.
>> > >
>> > > A fundamental issue with this behavior is that it dumps routes that
>> > > would have to be recovered via expensive refresh.
>> >
>> > Am I correct to understand that the word 'discard' has very specific
>> > meaning in this context? Does "discard" mean "forbidden to store in
>> > memory"?
>>
>> Discard traditionally means "to throw away".  To put into familiar
>> context,
>> "keep none" with policy reject.
>>
>> If you're just looking for "you can't use this without import policy
>> specified", you want something along the lines of:
>>
>> In the absence of configured import policy, BGP routes are ineligible for
>> route selection. (RFC 4271, section 9.1.1.)
>>
>
> This wording is consistent with what I want to have happen.
>
> (Fixing language in other IDs/RFCs is work for another day.)
>
> I cannot think of a better way of wording it, so my opinion is, "adopt
> this language".
>
> Support, BTW.
>
> BRian
>
> _______________________________________________
> GROW mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/grow
>
>
_______________________________________________
GROW mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/grow

Reply via email to