Skip to main content

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

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
Roman Danyliw
No Objection
Comment (2019-06-11 for -06) Not sent
A few editorial nits:
-- Section 3.  Typo. s/identies/identities/

-- Appendix.  Typo.  s/paramters/parameters/
Warren Kumari
No Objection
Adam Roach Former IESG member
No Objection
No Objection (for -06) Not sent

                            
Alexey Melnikov Former IESG member
No Objection
No Objection (for -06) Not sent

                            
Alissa Cooper Former IESG member
No Objection
No Objection (for -06) Not sent

                            
Alvaro Retana Former IESG member
No Objection
No Objection (2019-06-11 for -06) Sent
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.
Barry Leiba Former IESG member
No Objection
No Objection (for -06) Not sent

                            
Benjamin Kaduk Former IESG member
No Objection
No Objection (2019-06-12 for -06) Sent
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 IESG member
No Objection
No Objection (for -06) Not sent

                            
Ignas Bagdonas Former IESG member
No Objection
No Objection (for -06) Not sent

                            
Magnus Westerlund Former IESG member
No Objection
No Objection (for -06) Not sent

                            
Martin Vigoureux Former IESG member
No Objection
No Objection (2019-06-11 for -06) Sent
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 IESG member
No Objection
No Objection (2019-06-05 for -06) Sent
Thanks David Black for the TSV-ART review! I would also prefer to see an update of the registry.
Suresh Krishnan Former IESG member
No Objection
No Objection (2019-06-12 for -06) Sent
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.