Subject: Re: [Gen-art] Gen-ART review of draft-ietf-sidr-bgpsec-threats-06

From: Stephen Kent <[email-masked]>
Date: Tue, 01 Oct 2013 17:07:36 -0400

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

---

From: "Black, David" <[email-masked]>
Date: Tue, 1 Oct 2013 21:12:35 -0400

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.

Thanks,
--David

From: Stephen Kent [mailto:[email-masked]]
Sent: Tuesday, October 01, 2013 5:08 PM
To: Black, David
Cc: [email-masked]; General Area Review Team ([email-masked]); [email-masked]; [email-masked]; [email-masked]
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.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 02 Oct 2013 11:03:40 -0400

David,

> 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 revised intro text now paraphrases the text from the SIDR charter that
describes the path security goals.

Steve

---

From: "Black, David" <[email-masked]>
Date: Wed, 2 Oct 2013 15:01:25 -0400

Sounds good - I look forward to seeing the revised draft.

Thanks,
--David

From: Stephen Kent [mailto:[email-masked]]
Sent: Wednesday, October 02, 2013 11:04 AM
To: Black, David
Cc: [email-masked]; General Area Review Team ([email-masked]); [email-masked]; [email-masked]; [email-masked]
Subject: Re: Gen-ART review of draft-ietf-sidr-bgpsec-threats-06

David,

Steve,

Steve