Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-reqs

On Tue, Jan 14, 2014 at 6:38 PM, Sriram, Kotikalapudi
<kotikalapudi.sriram@nist.gov> wrote:
> I support publication of this document as an RFC.

As do I.
W

> I have some comments listed below that are meant to help improve clarity.
>
> 3.2 (current) A BGPsec design must allow the receiver of a BGP announcement  to determine, to a strong level of certainty, that the received PATH attribute accurately represents the sequence of eBGP exchanges that propagated the prefix from the origin AS to the receiver, particularly if an AS has added or deleted any AS number other than its own in the path attribute.  This includes  modification to the number of AS prepends.
>
> 3.2 (suggested rewording) A BGPsec design must allow the receiver of a BGP announcement  to determine, to a strong level of certainty, that the received PATH attribute accurately represents the sequence of eBGP exchanges that propagated the prefix from the origin AS to the receiver. Specifically, if an AS has deleted any ASN from the AS PATH it received or added an ASN other than its own then the verification of the update (if propagated) MUST fail at its neighboring  BGPsec routers.  This includes modification to the number of AS prepends, i.e. an AS in the path MUST NOT be able to modify the AS prepends (if any) of preceding ASs in the AS PATH.
>
> 3.4 (current) A BGPsec design MUST be amenable to incremental deployment. This implies that incompatible protocol capabilities MUST be negotiated.
>
> "Negotiating incompatible protocol" -- the phrase doesn't sound right to me.
>
> 3.4 (suggested rewording) A BGPsec design MUST be amenable to incremental deployment. This implies that a BGPsec capable router MUST be backward compatible and MUST negotiate BGP-4 protocol with a BGP-4 only neighbor,  and MUST interoperate with the BGP-4 only neighbor.
>
> 3.4 and 3.13 are related (overlapping). You may consider combining them.
>
> In 3.14, this statement "Such mechanisms  SHOULD conform with [I-D.ietf-sidr-ltamgmt]" seems a bit abrupt. You should state what in [I-D.ietf-sidr-ltamgmt] is relevant here to "best path and other routing decisions."  Note: You do speak about [I-D.ietf-sidr-ltamgmt] more specifically again in 3.17.
>
> Sriram
>
> _______________________________________________
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr