Subject: [karp] WGLC of draft-ietf-karp-ospf-analysis-03

From: Brian Weis <[email-masked]>
Date: Fri, 18 May 2012 12:24:28 -0700

Folks,

The KARP Analysis of OSPF document has been stable for some time, and the authors believe it is in accordance with both the KARP Design Guide (RFC 6518) and the Threats-Reqs draft (draft-ietf-karp-threats-reqs-05). The chairs are therefore asking for a WG last call, with the view of sending this to our AD for publication as an Informational RFC. Please send any remaining comments you have on this document to the list by June 1, 2012.
	<http://tools.ietf.org/html/draft-ietf-karp-ospf-analysis-03>

Thanks,
Brian & Joel

---

From: Sean Turner <[email-masked]>
Date: Sat, 19 May 2012 15:55:47 -0400

Quick question:

Should the OSPFv3 section discuss RFC 6506: Supporting Authentication 
Trailer for OSPFv3?

spt

On 5/18/12 3:24 PM, Brian Weis wrote:
> Brian&  Joel
> _______________________________________________
> karp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/karp
>

---

From: Sam Hartman <[email-masked]>
Date: Mon, 28 May 2012 07:26:03 -0400

>>>>> "Sean" == Sean Turner <[email-masked]> writes:

    Sean> Quick question: Should the OSPFv3 section discuss RFC 6506:
    Sean> Supporting Authentication Trailer for OSPFv3?

I guess we can update to add a reference if you like. I kind of view
 this as work that lead to that RFC though.

---

From: Sean Turner <[email-masked]>
Date: Mon, 28 May 2012 14:06:21 -0400

On 5/28/12 7:26 AM, Sam Hartman wrote:
>>>>>> "Sean" == Sean Turner<[email-masked]>  writes:
>

I think it's worth pointing out that one of the follow-on documents that 
this analysis was going to produce is completed.

Also should this sentence be changed:

OLD:

A security solution will be developed for OSPFv2 and OSPFv3 based on the 
OSPFv2 cryptographic authentication option.

NEW:

A security solution will be developed for OSPFv3 based on the OSPFv2 
cryptographic authentication option.

Shouldn't this draft also discuss the

Only talking about OPSFv3?  It seems odd to develop a security solution 
for OSPv2 based on the already defined OSPFv3 option.

Isn't [I-D.ietf-ospf-security-extension-manual-keying] also a solution 
output that should be discussed in s5?

some nits from nitchecker:

Need an IANA considerations section.

r/I-D.ietf-opsec-routing-protocols-crypto-issues/RFC6309

r/draft-ietf-opsec-routing-protocols-crypto-issues/RFC6309

r/draft-ietf-karp-threats-reqs-04/draft-ietf-karp-threats-reqs-05

r/draft-ietf-ospf-security-extension-manual-keying-01/draft-ietf-ospf-security-extension-manual-keying-02

spt

---

From: Sam Hartman <[email-masked]>
Date: Mon, 28 May 2012 15:58:51 -0400

Yes. The intent is to move towards OSPF v2-like options not v3-like
options.