Locator/ID Separation Protocol
charter-ietf-lisp-05

[Ballot comment]
Thanks for addressing my BLOCK. It's good to understand that they are going to develop a new NAT traversal technique rather than appropriate an existing one.

[Ballot comment]
* Does the applicability text have to be in a separate document, or
  can it be part of another document, e.g. if it's not too lengthy?

[Ballot comment]
“LISP deployments could benefit from more advanced internet-working”

Should this be “interworking”? If not, why not?

Editorial:

s/identified by the working as main LISP applications/identified by the working group as main LISP applications/ (add “group”)

s/The management of LISP protocol and deployments include data models, OAM/The management of LISP protocol and deployments including data models, OAM/ (“include” should be “including”)

s/LISP tunnel endpoints are separated from by a NAT/LISP tunnel endpoints are separated from one another by a NAT/ (add “one another”)

s/leveraging on/leveraging/ (remove “on”)

[Ballot block]
Per the following set of work "Privacy and Security: The WG will work on EID anonymity, VPN segmentation leveraging on the Instance ID, and traffic anonymization. The reuse of existing mechanisms will be prioritized.":

-- What is the threat model assumed for "traffic anonymization" and "EID anonymity"?  Could the desired security properties be clarified?

[Ballot comment]
Per the following set of work "Privacy and Security: The WG will work on EID anonymity, VPN segmentation leveraging on the Instance ID, and traffic anonymization. The reuse of existing mechanisms will be prioritized.":

-- What will the output of this work look like?  Which milestone is it associated with?

[Ballot block]
Is the NAT traversal work going to prioritize existing solutions (e.g. STUN, TURN, ICE), or have all those already been determined to be inadequate? If the latter, LISP should coordinate with TSVWG on its NAT traversal solution.

[Ballot comment]
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?

[Ballot comment]
# 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

[Ballot block]
I'm a little concerned about the unbounded scope the proposed charter gives the working group. I am balloting BLOCK until we have a chance to discuss this:

"The LISP WG is chartered to continue work on the LISP protocol, including extensions for which the working group has consensus on deeming them necessary".

It's very hard for me to imagine anything at all that would be out of scope according to that criterion, and that tells me the proposed charter should be made more specific. A first question to think about might be "necessary according to what metric or criterion?"

[Ballot 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?

Changed charter milestone "Submit LISP NAT Traversal document to the IESG for consideration (NAT Traversal)", set description to "Submit LISP NAT Traversal document to the IESG for consideration (NAT Traversal) [STANDARDS TRACK]"

Changed charter milestone "Submit LISP Yang model document to the IESG for consideration (Yang Models) [EXPERIMENTAL]", set description to "Submit LISP YANG model document to the IESG for consideration (YANG Models) [EXPERIMENTAL]"

[Ballot comment]
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?

[Ballot comment]
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...

Changed charter milestone "Submit LISP Applicability document(s) to the IESG for consideration (LISP Applicability)", set description to "Submit LISP Applicability document(s) to the IESG for consideration (LISP Applicability) [INFORMATIONAL]"

Changed charter milestone "Submit LISP Multicast document(s) to the IESG for consideration (Moving to Standard Track)", set description to "Submit LISP Multicast document(s) to the IESG for consideration [STANDARDS TRACK]"

Changed charter milestone "Submit LISP Mobility document(s) to the IESG for consideration (Mobility)", set description to "Submit LISP Mobility document(s) to the IESG for consideration (Mobility) [EXPERIMENTAL]"

Changed charter milestone "Submit LISP External Connectivity document(s) to the IESG for consideration (LISP External Connectivity)", set description to "Submit LISP External Connectivity document(s) to the IESG for consideration (LISP External Connectivity) [EXPERIMENTAL]"

Changed charter milestone "Submit LISP Privacy and Security document(s) to the IESG for consideration (Privacy and Security)", set description to "Submit LISP Privacy and Security document(s) to the IESG for consideration (Privacy and Security) [EXPERIMENTAL]"

Changed charter milestone "Submit LISP LCAF bis document to the IESG for consideration (Moving to Standard Track)", set description to "Submit LISP LCAF bis document to the IESG for consideration [STANDARDS TRACK]"

Changed charter milestone "Submit LISP DDT bis document to the IESG for consideration (Moving to Standard Track)", set description to "Submit LISP DDT bis document to the IESG for consideration [STANDARDS TRACK]"

Changed charter milestone "Submit LISP Geo-Coordinates document to the IESG for consideration (Mobility)", set description to "Submit LISP Geo-Coordinates document to the IESG for consideration (Mobility) [EXPERIMENTAL]"

Changed charter milestone "Submit LISP Traffic Engineering document to the IESG for consideration (Extension)", set description to "Submit LISP Traffic Engineering document to the IESG for consideration (Extension) [EXPERIMENTAL]"

Changed charter milestone "Submit LISP Yang model document to the IESG for consideration (Yang Models)", set description to "Submit LISP Yang model document to the IESG for consideration (Yang Models) [EXPERIMENTAL]"

Changed charter milestone "Submit LISP Reliable Transport document to the IESG for consideration (Map Server Reliable Transport)", set description to "Submit LISP Reliable Transport document to the IESG for consideration (Map Server Reliable Transport) [STANDARDS TRACK]"

Changed charter milestone "Submit LISP Name Encoding document to the IESG for consideration (Extension)", set description to "Submit LISP Name Encoding document to the IESG for consideration (Extension) [EXPERIMENTAL]"

Changed charter milestone "Submit a LISP interworking specification (6832bis) document to the IESG for consideration as Proposed Standard", set due date to July 2017 from April 2017

Changed charter milestone "Submit a LISP control-plane specification (6833bis) document to the IESG for consideration as Proposed Standard", set due date to July 2017 from April 2017

[Ballot comment]
I see:
  The LISP WG is chartered to continue work on the LISP base protocol
  and produce standard-track documents (unless the content of the
  document itself is of a different type, e.g., informational or
  experimental).

And I see a redundant sentence:
  Documents of these work items will as well target standard-track
  unless the main content of the document itself clearly demands for
  a different type (e.g., informational or experimental). In the latter
  case the Working Group needs to determine the proper document
  class.

I'm afraid that those two sentences are so generic that they don't add anything to the charter.
The following sentence is clear though, for the first set of deliverables:
  In order to produce a coherent set of documents, the first (and high
  priority) work item of the LISP Working Group is to develop a
  standard-track solution based on the completed Experimental RFCs
  and the experience gained from early deployments.

As AD, if you know already the track of each of the documents (the ones under "In parallel with the previous main work item, the LISP WG will work on the items listed below:") or want to provide guidance, my advice is to add the milestones and the respected expected status. 
See https://datatracker.ietf.org/wg/netconf/charter/ as an example.

[Ballot comment]
I see:
  The LISP WG is chartered to continue work on the LISP base protocol
  and produce standard-track documents (unless the content of the
  document itself is of a different type, e.g., informational or
  experimental).

And I see a redundant sentence:
  Documents of these work items will as well target standard-track
  unless the main content of the document itself clearly demands for
  a different type (e.g., informational or experimental). In the latter
  case the Working Group needs to determine the proper document
  class.

I'm afraid that those two sentences are so generic that they don't add anything to the charter.
The following sentence is clear though, for the first set of deliverables:
  In order to produce a coherent set of documents, the first (and high
  priority) work item of the LISP Working Group is to develop a
  standard-track solution based on the completed Experimental RFCs
  and the experience gained from early deployments.

As AD, if you know already the track of each of the documents (the ones under "In parallel with the previous main work item, the LISP WG will work on the
items listed below:") or want to provide guidance, my advice is to add milestones and the expected status. 
See https://datatracker.ietf.org/wg/netconf/charter/ as an example.

[Ballot comment]
I see:
  The LISP WG is chartered to continue work on the LISP base protocol
  and produce standard-track documents (unless the content of the
  document itself is of a different type, e.g., informational or
  experimental).

And I see a redundant sentence:
  Documents of these work items will as well target standard-track
  unless the main content of the document itself clearly demands for
  a different type (e.g., informational or experimental). In the latter
  case the Working Group needs to determine the proper document
  class.

I'm afraid that those two sentences are so generic that they don't add anything to the charter.
The following sentence is clear though, for the first set of deliverables:
  In order to produce a coherent set of documents, the first (and high
  priority) work item of the LISP Working Group is to develop a standard-
  track solution based on the completed Experimental RFCs and the
  experience gained from early deployments.

As AD, if you know already the track of each of the documents (the ones under "In parallel with the previous main work item, the LISP WG will work on the
items listed below:") or want to provide guidance, my advice is to add milestones and the expected status. 
See https://datatracker.ietf.org/wg/netconf/charter/ as an example.

[Ballot comment]
I see:
  The LISP WG is chartered to continue work on the LISP base protocol and
  produce standard-track documents (unless the content of the document
  itself is of a different type, e.g., informational or experimental).

And I see a redundant sentence:
  Documents of these work items will as well target standard-track unless the main
  content of the document itself clearly demands for a different type (e.g.,
  informational or experimental). In the latter case the Working Group needs to
  determine the proper document class.

I'm afraid that those two sentences are so generic that they don't add anything to the charter.
The following sentence is clear though, for the first set of deliverables:
  In order to
  produce a coherent set of documents, the first (and high priority) work item
  of the LISP Working Group is to develop a standard-track solution based on the
  completed Experimental RFCs and the experience gained from early deployments.

As AD, if you know already the track of each of the documents (the ones under "In parallel with the previous main work item, the LISP WG will work on the
items listed below:") or want to provide guidance, my advice is to add milestones and the expected status. 
See https://datatracker.ietf.org/wg/netconf/charter/ as an example.

[Ballot comment]
I see:
  The LISP WG is chartered to continue work on the LISP base protocol and
  produce standard-track documents (unless the content of the document
  itself is of a different type, e.g., informational or experimental).

And I see a redundant sentence:
  Documents of these work items will as well target standard-track unless the main
  content of the document itself clearly demands for a different type (e.g.,
  informational or experimental). In the latter case the Working Group needs to
  determine the proper document class.

I'm afraid that those two sentences are so generic that they don't add anything to the charter.
The following sentence is clear though, for the first set of deliverables:
  In order to
  produce a coherent set of documents, the first (and high priority) work item
  of the LISP Working Group is to develop a standard-track solution based on the
  completed Experimental RFCs and the experience gained from early deployments.

As AD, if you know already the track of each of the documents (the ones under "In parallel with the previous main work item, the LISP WG will work on the
items listed below:") or want to provide guidance, my advice is to add milestones and the expected status. 
See https://datatracker.ietf.org/wg/netconf/charter/ as an example.

[Ballot comment]
I'm a Yes, with a couple of comments.

I don't think

"Documents of these work items will as well target standard-track unless the main content of the document itself clearly demands for a different type (e.g., informational or experimental). In the latter case the Working Group needs to determine the proper document class."

is quite right. My understanding is that "determining the proper document class" is an IESG responsibility in RFC 2026 (which calls this "publication category"):

  The IESG is not bound by the action recommended when the
  specification was submitted.  For example, the IESG may decide to
  consider the specification for publication in a different category
  than that requested. 

The fix would be simple enough:

"In the latter case the Working Group needs to determine the recommended
                                                            ^^^^^^^^^^^
document class."

I didn't understand this:

"The LISP Working Group is chartered to work on the LISP technology, and only use solutions/technology developed in other working groups."

Is it saying that the LISP working group will not modify or extend solutions/technology developed in other working groups? Or is something else going on here?

[Ballot comment]
I had asked a clarification on which parts of the work of the WG will be going standards track and which parts experimental. The answer and suggested edits to the charter have made it clearer. Thank you.

For what it is worth, I believe the working group should not put the entire list of work items (9 previous RFCs to be re-worked plus 7 new ones) targeting standards track. The new charter text has language that the situation will be evaluated for the new charter items, but at least my read of it gives a default answer of "standards track".  In my view there are work items that would benefit from being targeted for an experimental round before made standards, and I thought the charter should have said that.

There was pushback for my suggestion to do that, however. I do not plan to stand in the way of the working group making this charter update, but I wanted to be on record that the I didn't think this was a good idea.

[Ballot comment]
I support Jari's concerns about clarity for what is on Standards Track and what is intended for Experimental.

I also have some concerns about the "The scope of the LISP technology is recognized to
range from unicast and multicast overlays at Layer 2 as well as at Layer 3,
including NAT traversal, VPNs, and supporting mobility as a general feature,
independently of whether it is a mobile user or a migrating Virtual
Machine (VM), hence being applicable in both Data Centers and public
Internet environments."

as that seems to basically claim that LISP is recognized and intended to solve all those problems in a Standards
track way - even when there are already clear and deployed standardized ways to do so.

I'd prefer to change "recognized" to "potentially applicable" or at a minimum "recognized to potentially range"

[Ballot comment]
- One advantage of doing a late review is that much has been said. I basically agree with all comments made the IESG so far. In particular with Jari: the charter is basically an initial promise. As such it should contain the right expectations (ex: standards track), and ideally the milestones (however, we don't have a clear consensus with the IESG on the milestones, so I won't insist).

- "Besides this main focus, the LISP WG may work on the following items:"
"May" is weird, when you have already adopted a WG. Ex: draft-ietf-lisp-yang-01.txt

- Finally,

  - Management models: Support for managing the LISP protocol and
deployments that include data models, as well as allowing for
programmable management interfaces. These management methods
should be considered for both the data-plane, control plane,
and mapping system components.

We speak about the management of the experimental RFCs or the new standards track document? Please clarify

[Ballot block]
Thank you for formulating a proposal for LISP work to continue to next step(s). The results will be interesting, and there's a group of people interested in doing the work.

The basics of the proposed charter seem good; learn from the experience and take what worked well into PS, ditch the not-so-well-worked parts, and continue some part of the work as experimental until we have more experience of it.

I will support a new charter for the working group, but first I have a question that I want discuss. I do think though that we should talk about the scoping of the charter. It is quite imprecise with respect to what will be on standards track and what is not. Could that or the process leading to that decision be clarified? Or am I missing something on this late hour when I read the charter? For instance, consider taking to PS things that we have published as RFCs before (possibly modified).

[Ballot block]
Thank you for formulating a proposal for LISP work to continue to next step(s). The results will be interesting, and there's a group of people interested in doing the work.

The basics of the proposed charter seem good; learn from the experience and take what worked well into PS, ditch the not-so-well-worked parts, and continue some part of the work as experimental until we have more experience of it.

I do think though that we should discuss the scoping of the charter. It is quite imprecise with respect to what will be on standards track and what is not. Could that or the process leading to that decision be clarified? Or am I missing something on this late hour when I read the charter?

Some early thoughts on what more specific scoping might mean: consider taking to PS things that we have published as RFCs before (possibly modified), bring new ideas to the WG but first as experimental work, document a rationale/bar on when an item is interesting at all to the WG.

[Ballot comment]
I agree with Terry that priorities should be spelled out. This is important given the number of potential new work items that keep popping up on the LISP mailing list.

[Ballot comment]
I think it is appropriate to take the both the experimental RFCs with early deployment experience and develop them into PS. Can the priority of that work be highlighted in the charter as more than just the "main"? eg it IS the number one priority, forsaking all others. ... And clearly once that is achieved a charter mod can certainly occur to readdress the priority balance.

My rationale is that while there may be fluctuations in the base spec there is a product/user base in existence, a following raft (10) of draft WG documents and even more Individual submissions,  that could be impacted by any necessary changes in moving from Experimental to PS.

I don't object to the additional scope of items, in fact I encourage it - but in a sane balance of making the base spec robust with reward of working on shiny new things in a way that informs the Experimental ==> PS tango. So these additional scope of "may" be worked need not be listed as a priority and the WG can establish its own ordering with that in mind.

I concur with others, having an explicit list of the WG (or liaison group) interactions spelled out here early would be beneficial to those target WGs and the sanity of the chairs and ADs in cross area coordination.

[Ballot comment]
I agree with Joel in that some more detail on the deliverables would be nice — also, some of the expected interactions should be called out; for example, for the multicast item I would expect interaction with the pim WG, etc.

[Ballot comment]
This text

"The LISP WG is chartered to continue work on the LISP base protocol with the
main objective to develop a standard solution based on the completed
Experimental RFCs and the experience gained from early deployments."

might be clearer if it said "a standards-track solution".

[Ballot comment]
I am sympathetic to the idea that we  should curating the existing work with an eye towards what worked and what didn't.

I would personally like to see the new work items more fleshed out with respect to what the deliverables are supposed to look like, mostly the mobile and multicast  items need to be fleshed out I think.

As previously discussed, the LISP work has matured and it is requesting to recharter with the main objective to develop a standard solution based on the completed Experimental RFCs and experience gained.