Re: Change to Consensus statement in BGP Sec Reqs -08

This wording looks fine to me....



Russ

Geoff Huston wrote:
> I support this change and would also advise you to change the normative
> MUST and SHOULD in the latter two sections to non-normative text so that
> there is no confusion here.
> 
> Here is an example of such a change to the text
> 
> 
>   o  AS_PATH Feasibility Check: The AS_PATH list may correspond to a
>       valid list of autonomous systems according to the first
>       verification category listed in the "Areas to Secure" Section
>       above. Further study will determine the extent to which this
>       is a security requirement.
> 
>    o  Update Transit Check: Routing information carried through BGP
>       may include information that can be used to verify the re-
>       advertisement or modification by each autonomous system through
>       which the UPDATE has passed.  This check is more rigorous than the
>       "valid list of autonomous systems" above. Further study will
>       determine the extent to which this is a security requirement.
> 
> 
> 
> Geoff
> 
> 
> 
> 
> 
> Tony Tauber wrote:
>> As was noted during yesterday's meeting, I'm proposing changing part of
>> Sec 7 from:
>>
>> "The AS_PATH for specific prefixes may be protected in any proposed
>> security system in four ways, outlined below. Special Note: On the first
>> two categories below, the community has reached consensus; on the latter
>> two (AS_PATH Feasibility Check and Update Transit Check), the community
>> has not reached consensus."
>>
>> to
>>
>> "The AS_PATH for specific prefixes may be protected in any proposed
>> security system in four ways, outlined below. Special Note: On the
>> latter two categories below (AS_PATH Feasibility Check and Update
>> Transit Check), the requirement will be revisited in the future once
>> more experience has been garnered."
>>
>> There was support in the room including from Dave Ward who is our
>> shepherding AD who indicated publishing a consensus document which
>> states a lack of consensus is contradictory.
>>
>> The SIDR Co-Chairs also applauded this move as it allows them to
>> progress their work.
>>
>> Please send your comments and statements of support for or opposition to
>> this change to the text.
>>
>> Thanks,
>>
>> Tony
>>
>>
>> _______________________________________________
>> RPSEC mailing list
>> RPSEC <at> ietf.org
>> https://www1.ietf.org/mailman/listinfo/rpsec
> 
> 
> _______________________________________________
> RPSEC mailing list
> RPSEC <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/rpsec