Geoff,

My reasoning is that   without a specific policy statement, such as "B should 
be announcing this route, signed A", then we can demonstrate that B did 
announce it, but not if B should have announced it.   With that policy object 
then we can construct the route filter to check that not only did B announce it 
but if they should be doing so.  From an operational perspective that has value.

Andrew

On Feb 23, 2011, at 6:01 PM, Geoff Huston wrote:

> Andrew,
> 
> I hope I was neutral in neither agreeing or disagreeing as to its utility in 
> my comment.
> 
> I was simply checking your assertion that "it would be useful to have a 
> relationship object" and gently trying to understand your reasoning behind 
> holding that view.
> 
>  Geoff
> 
> 
> 
> On 24/02/2011, at 9:12 AM, Andrew Lange wrote:
> 
>> Geoff,
>> 
>> Do you disagree as to its utility? 
>> 
>> Andrew
>> 
>> On Feb 23, 2011, at 4:16 PM, Geoff Huston wrote:
>> 
>>> 
>>> On 24/02/2011, at 8:09 AM, Robert Loomans wrote:
>>> 
>>>> 
>>>> On 24/02/2011, at 09:17, Andrew Lange wrote:
>>>> 
>>>>> From a work item perspective, it would be useful to have a relationship 
>>>>> object signed that says "I'm AS_A, and I have AS_B and AS_Q as legitimate 
>>>>> connections." 
>>>> 
>>>> Geoff published a (now expired) draft for just such an object: 
>>>> http://tools.ietf.org/html/draft-huston-sidr-aao-profile-03
>>>> 
>>> 
>>> and I can push it out again.
>>> 
>>> Andrew, I assume you are serious in claiming that this would be useful to 
>>> have in this context.
>>> 
>>> Geoff
>>> 
>>> _______________________________________________
>>> sidr mailing list
>>> [email protected]
>>> https://www.ietf.org/mailman/listinfo/sidr
>> 
> 
> --
> 
> Geoff Huston
> Chief Scientist, APNIC
> 
> +61 7 3858 3100
> [email protected]
> 
> 
> 
> 
> _______________________________________________
> sidr mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/sidr

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr

Reply via email to