Skip to main content

A YANG Data Model for Tunnel Interface Types
RFC 8675

Yes

Éric Vyncke

No Objection

Warren Kumari
(Adam Roach)
(Alexey Melnikov)
(Alissa Cooper)
(Barry Leiba)
(Deborah Brungard)
(Ignas Bagdonas)
(Magnus Westerlund)

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

Éric Vyncke Yes

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.

Roman Danyliw No Objection

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

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

Warren Kumari No Objection

(Adam Roach; former steering group member) No Objection

No Objection (for -06)

                            

(Alexey Melnikov; former steering group member) No Objection

No Objection (for -06)

                            

(Alissa Cooper; former steering group member) No Objection

No Objection (for -06)

                            

(Barry Leiba; former steering group member) No Objection

No Objection (for -06)

                            

(Benjamin Kaduk; former steering group member) No Objection

No Objection (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-*.

(Deborah Brungard; former steering group member) No Objection

No Objection (for -06)

                            

(Ignas Bagdonas; former steering group member) No Objection

No Objection (for -06)

                            

(Magnus Westerlund; former steering group member) No Objection

No Objection (for -06)

                            

(Martin Vigoureux; former steering group member) No Objection

No Objection (2019-06-11 for -06)
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?

(Mirja Kühlewind; former steering group member) No Objection

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

(Suresh Krishnan; former steering group member) No Objection

No Objection (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.