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

[Dave Thaler <[e-mail]>]

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 <[e-mail]> On Behalf Of Suresh Krishnan via Datatracker
Sent: Wednesday, June 12, 2019 9:01 PM
To: The IESG <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: [Softwires] Suresh Krishnan's No Objection on draft-ietf-softwire-iftunnel-06: (with COMMENT)

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://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



----------------------------------------------------------------------
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.


_______________________________________________
Softwires mailing list
[e-mail]
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