Subject: [secdir] SecDir review of draft-ietf-isis-rfc4971bis-01

From: Yaron Sheffer <[email-masked]>
Date: Fri, 5 Aug 2016 13:01:06 +0300

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the IESG.
These comments were written primarily for the benefit of the security
area directors.  Document editors and WG chairs should treat these
comments just like any other last call comments.

This document is a minor update to RFC4971, in order to correctly
support IPv6-only routers.

Summary

The document is ready for publication.

Details

The Security Considerations are unchanged from the original RFC and
cover the router capability feature reasonably. They still seem to
describe this quaint world where each router can rely on all its peers
to always send correct information. But at least we recommend to use
protocol-level integrity mechanisms in "high risk" situations.

Thanks,
	Yaron

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 8 Aug 2016 13:35:34 +0000

Yaron -

Thanx for your review.

   Les

> -----Original Message-----
> From: Yaron Sheffer [mailto:[email-masked]]
> Sent: Friday, August 05, 2016 3:01 AM
> To: IETF Security Directorate; The IESG; draft-ietf-isis-
> [email-masked]
> Subject: SecDir review of draft-ietf-isis-rfc4971bis-01
> 
> I have reviewed this document as part of the security directorate's ongoing
> effort to review all IETF documents being processed by the IESG.
> These comments were written primarily for the benefit of the security area
> directors.  Document editors and WG chairs should treat these comments
> just like any other last call comments.
> 
> This document is a minor update to RFC4971, in order to correctly support
> IPv6-only routers.
> 
> Summary
> 
> The Security Considerations are unchanged from the original RFC and cover
> the router capability feature reasonably. They still seem to describe this
> quaint world where each router can rely on all its peers to always send
> correct information. But at least we recommend to use protocol-level
> integrity mechanisms in "high risk" situations.
> 
> Thanks,
> 	Yaron