[sidr] bgpsec-spec S. 4.2 comments

["Sriram, Kotikalapudi" <[e-mail]>]

John Scudder asked the following question in an email to the
authors of draft-ietf-sidr-bgpsec-protocol:

>From: John G. Scudder <[e-mail]>
>Date: Wed, Apr 18, 2012 at 8:00 PM
>Subject: bgpsec-spec S. 4.2 comments
>
>A few misc questions/comments I noticed while perusing S. 4.2:
>
>  "A BGPSEC speaker MUST NOT generate an update message containing the
>  BGPSEC_Path_Signatures attribute unless it has selected, as the best
>  route to the given prefix, a route that it received in an update
>  message containing the BGPSEC_Path_Signatures attribute."
>
>What's the rationale for this MUST NOT? Certainly it's an assumption of the base
>protocol, but I assume it wouldn't need to be called out here unless it bore on
>some BGPSEC-specific issue. This is relevant in the context of draft-ietf-idr-add-
>paths, which allows non-best paths to be sent in BGP.
>

The authors have agreed that the above text in the bgpsec spec 
document (quoted by John) certainly seems problematic.
The authors agreed to make the following text substitution:
(there was also consensus on this at the SIDR Interim meeting April 30, 2012):

"If a BGPSEC router has received an _unsigned_ route from a peer and
if it chooses to propagate that route, then it MUST NOT attach any
BGPSEC_Path_Signatures attribute to the corresponding update being propagated."

It was also agreed that we further add (if not already clearly stated
elsewhere in the spec):

"If a BGPSEC router has received a _signed_ update,
and if it chooses to propagate that route, then the router SHOULD propagate
the corresponding update with BGPSEC_Path_Signatures attribute
(after adding its own signature)."

These substitutions would help keep the text unambiguous, and
also inclusive of (or at least not conflicting with) draft-ietf-idr-add-paths.

Sriram