Ketan Talaulikar has entered the following ballot position for draft-ietf-lisp-geo-19: 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/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lisp-geo/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks to the authors and the WG for their work on this document. Thanks as well for the updates to address my comments in the original DISCUSS ballot - it looks good enough now for an experimental track document and hopefully can be refined with more specifics down the line. Please also find below some comments on this document updated for v19: Support of other DISCUSS positions: 1) I support Deb's DISCUSS position related to the reference to OSPF/ISIS/BGP individual drafts that carry similar extensions. Those documents have expired several years ago. None of them were adopted by their respective WGs - presumably due to lack of interest by the community? The case for changing existing LISP extensions for geo-coordinates (also an experimental RFC8060 section 4.3) for the (sole?) reason of bringing consistency across routing protocols does not look sound to me. Were there any implementations/deployments of the encoding of RFC8060 that necessitate this change? Other comments/suggestions: a) Please consider removing all references to other routing protocols individual drafts that have expired. I think this document needs to make its case independently and the format needs alignment with what is specified in the IETF. FWIW, geo-coordinates were already there in RFC 8060 so there doesn't need to be a justification for why they are needed in the protocol beyond what was said in RFC 8060. _______________________________________________ lisp mailing list -- [email protected] To unsubscribe send an email to [email protected]
