A YANG Data Model for Tunnel Interface Types
draft-ietf-softwire-iftunnel-07

A few editorial nits:
-- Section 3.  Typo. s/identies/identities/

-- Appendix.  Typo.  s/paramters/parameters/

Process note:  I'm assuming that draft-boucadair-netmod-softwire-iftunnel is the original version of this draft.  I couldn't find a clear e-mail thread about it.  If it is, please indicate it in the "Replaces" field.

I agree with Tom Petch that adding "tunnelType Registry" or "tunnelType  
Definitions" more prominently on the IANA website is advisable.

On a more general note, it's pretty weird to me to go and create a
registry with a fairly long list of initial population but then claim
that it is not intended to be complete and should be supplemented by
additional registrations for existing protocols.  Either it should be
complete, or we can just have a small sample of initial registrations to
"get a feel" for what they look like and what needs to be included.
Then, most registrations would be done as standalone registrations and
it would not feel like the outliers were getting rejected.

Appendix A

The example module's namespace was not changed to reflect the move away
from ietf-*.

Hello,

I am a bit puzzled because the Abstract recognizes that the document is built onto an incomplete data-set and that makes me wonder whether the model will be usable until the data-set is completed.

Also, I really do not understand the update you propose to the registry. It seems that you point to the technology spec rather than to the original mib module definition, but I quickly looked and none of the specs I parsed define the mib entry/value, so getting rid of the existing reference appears to me as a clear loss of information. I think you should keep the original reference and add a new one if needed, but not simply replace.

And if you have undertaken this effort of tidying the registry, why not complete it with the missing values?

Thanks David Black for the TSV-ART review! I would also prefer to see an update of the registry.

I have a hard time seeing the need for a generic UDP tunnel type (8) and also specific instances of UDP tunneling such as Teredo (14). I think it is better to go one way or another but not do both to avoid any confusion. In any case I think RFC8085 *should not* be the sole reference for UDP tunneling as it does not specify UDP tunneling but provides guidelines for designers of UDP based tunneling mechanisms.