Steve,
I think the modified introduction text suffices to connect the PATHSEC and BGPsec terms, but I don’t think that referring to the SIDR WG charter for the PATHSEC goals is reasonable – an RFC is an archive document, whereas a WG charter is not.
The explanation of “calls for” in the cache discussion is fine.
As I previously noted on the TCPMD5 reference:
Ok – I was suggesting adding an informative reference to RFC 2385, but this
is a nit, and so if the responsible AD is happy with omitting that reference
entirely, I don’t have a problem.
From: Stephen Kent [mailto:kent@xxxxxxx]
Sent: Tuesday, October 01, 2013 5:08 PM
To: Black, David
Cc: achi@xxxxxxxxxx; General Area Review Team (gen-art@xxxxxxxx); stbryant@xxxxxxxxx; ietf@xxxxxxxx; sidr@xxxxxxxx
Subject: Re: Gen-ART review of draft-ietf-sidr-bgpsec-threats-06
David,
Since this doc logically precedes the BGPsec design, I still think it's appropriate to
use PATHSEC here. But, we can add a sentence to connect the terms. I propose this modified text for the introduction:
This document describes the security context in which PATHSEC is intended to operate. (The term "PATHSEC" is employed in this document to refer to any design used to achieve the path security goal described in the SIDR WG charter. The charter focuses on mechanisms that will enable an AS to determine if the AS_path represented in a route represents the path via which the NLRI traveled. Other SIDR documents use
the term "BGPsec" to refer to a specific design.) ...
The phrase "calls for" seems appropriate in the cache discussion. There is no MUST in the RFCs about using a local cache. The docs encourage RPs to maintain a local cache,
and 6481 states that not using one is "NOT RECOMMENDED." All of the RP software of which
I am aware does so, but it is not an absolute requirement.
I think we've agreed that quoted is a static assertion and thus need not be
annotated to reflect more recent RFCs.
Steve