Subject: [Softwires] Suresh Krishnan's No Objection on draft-ietf-softwire-iftunnel-06: (with COMMENT)

From: Suresh Krishnan via Datatracker <[email-masked]>
Date: Wed, 12 Jun 2019 21:00:32 -0700

Suresh Krishnan has entered the following ballot position for
draft-ietf-softwire-iftunnel-06: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-softwire-iftunnel/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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.

---

From: <[email-masked]>
Date: Thu, 13 Jun 2019 05:26:00 +0000

Hi Suresh, 

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : Suresh Krishnan via Datatracker [mailto:[email-masked]]
> Envoyé : jeudi 13 juin 2019 06:01
> À : The IESG
> Cc : [email-masked]; Yong Cui; softwire-
> [email-masked]; [email-masked]; [email-masked]
> Objet : Suresh Krishnan's No Objection on draft-ietf-softwire-iftunnel-06:
> (with COMMENT)
> 
> to go one way or another but not do both to avoid any confusion.

[Med] These codes are already in the registry. This I-D is just echoing what is recorded in the current authoritative registry. 
If one of these codes is relaxed, the YANG module will be updated by IANA to reflect that. 

I do think that draft-thaler-iftype-reg is the right place to include a recommendation to encourage tunnel protocol designers to register their tunnel types rather than to reuse the generic UDP type. 

 In any
> case I

[Med] That is the best reference we have for UDP. It is certainly better than 4087.

---

From: Dave Thaler <[email-masked]>
Date: Thu, 13 Jun 2019 17:52:40 +0000

As the Designated Expert for the tunnel type registry, I'd like to respond to some of the IESG comments.

Ben Kaduk writes:
> 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.

This document does *not* create a registry.  If there's somewhere that implies it does,
that language should be fixed.   This document merely specifies an alternate format in
which the contents of the already existing registry can be retrieved.   It does not
make any changes to the entries in the existing registry.

Some registries can already be retrieved in multiple formats.  Let's take
https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml
as an example, which can be retrieved in CSV, XML, HTML, or Plain Text formats.
Say a document was written to propose how it should come back in JSON or CBOR format.
I doubt you were argue that such a draft would be odd without adding every missing port
entry into that same document.

Other IESG members had similar comments as Ben, which I responded to above.
Perhaps the document's wording could be better worded, but I don't think it's appropriate
to make any changes to the content of the registry in a draft that merely adds another
format for an existing registry, when (like port numbers) the registration policy
is not RFC Required.

Suresh Krishnan writes:
> 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).

Your comment is really on RFC 4087 (which added Teredo to the registry) not on this document,
since this document does not change what entries are already in the registry.  The reason
teredo was added was that the protocol was different and it was important for management
purposes, and API exposure to app purposes, to know which protocol was configured, 
whereas udp(8) in general was really just a point-to-point configured tunnel like an ip-in-ip tunnel was.

Dave

-----Original Message-----
From: Softwires <[email-masked]> On Behalf Of Suresh Krishnan via Datatracker
Sent: Wednesday, June 12, 2019 9:01 PM
To: The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: [Softwires] Suresh Krishnan's No Objection on draft-ietf-softwire-iftunnel-06: (with COMMENT)

When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)

Please refer to https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fiesg%2Fstatement%2Fdiscuss-criteria.html&amp;data=02%7C01%7Cdthaler%40microsoft.com%7C4f48dc41022245abd82c08d6efb3b30e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636959952444076572&amp;sdata=f8gOQtJYpgeWqznxLu38jrNw1W6NfTT0Y9xDbSbawHk%3D&amp;reserved=0
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-softwire-iftunnel%2F&amp;data=02%7C01%7Cdthaler%40microsoft.com%7C4f48dc41022245abd82c08d6efb3b30e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636959952444076572&amp;sdata=jAusOr3MD%2FmCp4Vu%2B1dIZv5qjrZIFamQzFYAoee2Bro%3D&amp;reserved=0

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.

_______________________________________________
Softwires mailing list
[email-masked]
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsoftwires&amp;data=02%7C01%7Cdthaler%40microsoft.com%7C4f48dc41022245abd82c08d6efb3b30e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636959952444086561&amp;sdata=PIYLbtpjGwxnB0lfNGQrcOna0TpamztqAEs3J%2BZXuco%3D&amp;reserved=0