A YANG Data Model for Tunnel Interface Types
RFC 8675

Note: This ballot was opened for revision 06 and is now closed.

Éric Vyncke Yes

(Ignas Bagdonas) No Objection

(Deborah Brungard) No Objection

(Alissa Cooper) No Objection

Roman Danyliw No Objection

Comment (2019-06-11 for -06)
No email
send info
A few editorial nits:
-- Section 3.  Typo. s/identies/identities/

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

Benjamin Kaduk No Objection

Comment (2019-06-12 for -06)
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-*.

(Suresh Krishnan) No Objection

Comment (2019-06-12 for -06)
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.

Warren Kumari No Objection

(Mirja Kühlewind) No Objection

Comment (2019-06-05 for -06)
Thanks David Black for the TSV-ART review! I would also prefer to see an update of the registry.

(Barry Leiba) No Objection

(Alexey Melnikov) No Objection

Alvaro Retana No Objection

Comment (2019-06-11 for -06)
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.

(Adam Roach) No Objection

Martin Vigoureux No Objection

Comment (2019-06-11 for -06)

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?

(Magnus Westerlund) No Objection