Last Call Review of draft-ietf-isis-auto-conf-04
review-ietf-isis-auto-conf-04-secdir-lc-perlman-2017-03-30-00

Request Review of draft-ietf-isis-auto-conf
Requested rev. no specific revision (document currently at 05)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2017-04-10
Requested 2017-03-22
Authors Bing Liu, Les Ginsberg, Bruno Decraene, Ian Farrer, Mikael Abrahamsson
Draft last updated 2017-03-30
Completed reviews Secdir Last Call review of -04 by Radia Perlman (diff)
Opsdir Last Call review of -04 by Will LIU (diff)
Genart Last Call review of -04 by Robert Sparks (diff)
Assignment Reviewer Radia Perlman
State Completed
Review review-ietf-isis-auto-conf-04-secdir-lc-perlman-2017-03-30
Reviewed rev. 04 (document currently at 05)
Review result Has Nits
Review completed: 2017-03-30

Review
review-ietf-isis-auto-conf-04-secdir-lc-perlman-2017-03-30

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 describes a touchless (autoconfiguring) implementation of
IS-IS.  I don't have any security comments, but I have some other comments.

They use the term "Double-Duplication". I don't know what that is. I think
they mean "both the system ID and router fingerprint are duplicated". To me
"double duplicate" would be that there were 3 or more systems with the same
information.

The terminology "NET" and "NSAP" have always been very confusing to most
IETF'ers (including me!). Might it be possible to stop using those terms?
Of course, it's not fair to pick on this document to start doing that. In
the early days of IS-IS, some implementations decided that NET should be
the NSAP minus the last byte. Others thought it should be a full size NSAP,
but with the last byte 0. The formal ISO definition in CLNP did not clarify
this sort of thing, at least to me. Anyway, is there an IETF IS-IS document
that explains what NET and NSAPs are, as opposed to saying (as in this
document) that "an NET is a type of NSAP", which I find very confusing.

In section 3.4.2, it says " Routers operating in auto-configuration mode
MUST NOT form adjacencies with routers which are NOT operating in
auto-configuration
mode. "

Why is that? I'd think it would be easier to deploy if you could gradually
introduce autoconfiguring routers in with existing implementations that
don't know about the A bit. Are you concerned about an actual area 0?

Other than those (mostly) editorial comments, which are only suggestions
anyway, this is ready for publication. I haven't been following IS-IS
recently, and I'm actually surprised that there hasn't been totally
autoconfiguring implementations up until now.

Radia