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 protected]> On Behalf Of Suresh Krishnan via Datatracker Sent: Wednesday, June 12, 2019 9:01 PM To: The IESG <[email protected]> Cc: [email protected]; [email protected]; [email protected]; [email protected] 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&data=02%7C01%7Cdthaler%40microsoft.com%7C4f48dc41022245abd82c08d6efb3b30e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636959952444076572&sdata=f8gOQtJYpgeWqznxLu38jrNw1W6NfTT0Y9xDbSbawHk%3D&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&data=02%7C01%7Cdthaler%40microsoft.com%7C4f48dc41022245abd82c08d6efb3b30e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636959952444076572&sdata=jAusOr3MD%2FmCp4Vu%2B1dIZv5qjrZIFamQzFYAoee2Bro%3D&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 [email protected] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsoftwires&data=02%7C01%7Cdthaler%40microsoft.com%7C4f48dc41022245abd82c08d6efb3b30e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636959952444086561&sdata=PIYLbtpjGwxnB0lfNGQrcOna0TpamztqAEs3J%2BZXuco%3D&reserved=0 _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
