Locator/ID Separation Protocol
charter-ietf-lisp-04-06
Yes
Jim Guichard
No Objection
Erik Kline
Francesca Palombini
Murray Kucherawy
Paul Wouters
Robert Wilton
Zaheduzzaman Sarker
No Record
Roman Danyliw
Warren Kumari
Summary: Has enough positions to pass.
Ballot question: "Is this charter ready for external review?"
Jim Guichard
Yes
Andrew Alston
No Objection
Comment
(2023-11-30 for -04-04)
Not sent
Supporting John's block.
Erik Kline
No Objection
Francesca Palombini
No Objection
John Scudder
(was Block)
No Objection
Comment
(2023-11-30 for -04-04)
Sent
I’m removing my BLOCK in anticipation of the changes Luigi proposed. Remaining comment: "LISP technology has a wide span of potential applications beyond simple routing." As Martin pointed out, this statement on its own doesn't seem to add anything. To the extent there is something concrete here, doesn't the final bullet capture it?
Lars Eggert
No Objection
Comment
(2023-11-30 for -04-04)
Sent
# GEN AD review of charter-ietf-lisp-04-04 CC @larseggert ## Comments ### "LISP", paragraph 1 ``` - LISP for Traffic Engineering: Specifics on how to do traffic engineering on LISP deployments could be useful. For instance, encode in a mapping not only the routing locators associated to EIDs, but also an ordered set of re-encapsulating tunnel routers (RTRs) used to specify a path. ``` "Could be useful" is a pretty weak motivator. Does anyone want to *deploy* this? If not, does it deserve to be a work item? ### "LISP", paragraph 0 ``` - NAT-Traversal: Support for a NAT-traversal solution in deployments where LISP tunnel endpoints are separated from by a NAT (e.g., LISP mobile node). ``` Stick it into UDP and use existing NAT traversal solutions. Re-engineering all that does not seem worthwhile. ### "LISP", paragraph 2 ``` - LISP External Connectivity: [RFC6832] defines the Proxy ETR element, to be used to connect LISP sites with non-LISP sites. However, LISP deployments could benefit from more advanced internet-working, for instance by defining mechanisms to discover such external connectivity. ``` "Could benefit" is a pretty weak motivator. Does anyone want to *deploy* this? If not, does it deserve to be a work item? ### "LISP", paragraph 1 ``` - Mobility: Some LISP deployment scenarios include endpoints that move across different LISP xTRs and/or LISP xTRs that are themselves mobile. Support needs to be provided to achieve seamless connectivity. ``` "Some deployment scenarios include it" is a pretty weak motivator. Does anyone want to *deploy* this? If not, does it deserve to be a work item? ## Notes This review is in the ["IETF Comments" Markdown format][ICMF], You can use the [`ietf-comments` tool][ICT] to automatically convert this review into individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT]. [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md [ICT]: https://github.com/mnot/ietf-comments [IRT]: https://github.com/larseggert/ietf-reviewtool
Martin Duke
No Objection
Comment
(2023-11-27 for -04-01)
Sent
What does this sentence mean? "The scope of the LISP technology is potentially applicable to have a large span" Does it mean "LISP technology has a wide span of potential applications?" and if so, is that a useful statement in a charter without more specifics?
Murray Kucherawy
No Objection
Paul Wouters
No Objection
Robert Wilton
No Objection
Zaheduzzaman Sarker
No Objection
Éric Vyncke
No Objection
Comment
(2023-11-27 for -04-01)
Sent
Nice to see LISP continuing to evolve. Minor issues: - s/Yang/YANG/ - even if LISPers know, suggest to expand acronyms on first use - what is the intended status of the last work item (use cases), I suggest informational - sigh for having a work item about NAT in 2023...
Roman Danyliw
No Record
Warren Kumari
No Record