[Tsv-art] Tsvart last call review of draft-thaler-iftype-reg-05

[Tommy Pauly via Datatracker <[e-mail]>]

Reviewer: Tommy Pauly
Review result: Ready with Nits

This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information.

When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC
[e-mail] if you reply to or forward this review.

Document: draft-thaler-iftype-reg-05

This document provides updated guidance on how to manage the IANA registries
for interface types and tunnel types. The document is clearly written, and explains
the history of the registries along with useful examples that provide the basis
for the updated guidance.

I do not see any concerns from a transport perspective; indeed, the guidance provided
with regards to the use of different transports for tunnels is quite clear and useful.
Section 4.1 is particularly illustrative of this, in pointing out how tunnels over raw UDP
need to be treated in a distinct manner from tunnels that use UDP as a component
(in the example provided, this tunnel type is Teredo).

Nits:

The one nit I have is with regards to Section 6.2.  This section begins by quoting the
IANAifType-MIB. It then provides a recommendation to change a specific sentence
to update the guidance on allocating transmission values. Based on the structure of
this section, I had expected the sentence being modified to be part of the quoted
paragraph, but this is not the case. Looking at the IANAifType-MIB itself, I could not
find the sentence to be changed at all (this can be seen at
"http://www.iana.org/assignments/ianaiftype-mib"). The only place I do see the
sentence in question, based on a web search, is at 
"http://oid-info.com/get/1.3.6.1.2.1.2.2.1.3". If this is the document that is meant to
be updated, it would be good to both include a reference to the document, and also
clarify the relationship of the quoted MIB text to the change. I may be misunderstanding
the intention here, but it does seem like an opportunity for clarification.