Last Call Review of draft-ietf-lisp-type-iana-04
review-ietf-lisp-type-iana-04-secdir-lc-kaufman-2017-01-12-00

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: Ready

No security concerns.

This document proposes creation of two new IANA registries and defines a new
message type within the Locator/ID Separation Protocol (RFC6830). The first
registry should have been created by RFC6830, which assigned codes to 5 values
for a four bit field. This document proposes creating a registry for holding
those 5 values and a sixth value for the purpose of holding experimental
extensions.

Because the 4 bit field can only ever support 16 values and several independent
extensions are already being proposed, the proposal is to reserve the value 15
for experimental extensions where it has a 12 bit sub-type field to distinguish
those extensions. This document proposes to create a second IANA registry for
holding up to 4096 assigned values for that field, to be handed out on a first
come first served basis.

While future extensions might have security implications, defining these new
registries does not.

I don't know what IANA's experience has been with first come first served
registries. With no review procedure, they are subject to abuse and I don't
know who gets to exercise judgment as to whether a particular request is
abusive.

The document states that the subtypes of value 15 are reserved for Experimental
Use. My sense is that the intention of the authors is that should an
experimental protocol be promoted to standards track that it will at that time
be assigned on of the 16 values from the 4 bit field. This might be an
unfortunate restriction for two reasons: 1) Given that there are only 16 types
available and 6 have already been assigned, it seems possible that this space
would eventually be exhausted; and 2) Requiring that protocols change syntax
when they are promoted from experimental to standards track places a burden on
implementers who often end up supporting both syntaxes indefinitely (and having
interoperability problems if they don't). There's no reason obvious to me why
subtypes could not be kept for standardized usage later. That is one of the
advantages of having an IANA registry over reserving them for private use.

The intended status of this document is listed as Experimental. This seems
wrong to me. While any future documents defining uses of newly assigned values
might well be experimental, I would expect that this document would seek the
same status as RFC6830 (and this document should be incorporated into any
future revisions of that one).

--Charlie