Layer Independent OAM Management in the Multi-Layer Environment
charter-ietf-lime-01

Changed charter milestone "Sumit the Applicability document to IESG for review as an Informational RFC", set description to "Submit the Applicability document to IESG for review as an Informational RFC"

[Ballot comment]
A clause crept in between -10 and -11. While I don't want to block on it, I do want to raise it because it is a subject that got a lot of discussion on the LIME mailing list going right back to when it was the TIME mailing list. it is one of the topics that was in the original proposal, but was scoped out to get focus in the work...

  including management mechanisms to facilitate
  mapping between OAM mechanisms at different layers

This concept was spoken against in strong terms in the RTGWG meeting in Toronto suggesting it is even a dangerous idea.

I would suggest, therefore, that if it is to be added to the charter, it should be described in more detail.

[Ballot comment]
Is the working assumption that the same administrative domain manages all the layers, if you're using what LIME produces?

I'm thinking of a VoIP carrier that has one operations group that runs all their SIP servers, another that runs their WAN IP network, and one or more groups that runs their access networks, for example.

If that's obviously in scope, out of scope, or silly, please carry on.

[Ballot comment]

I would suggest that this WG also consider the potential impact
of ciphertext becoming much more common in networks to
be managed. It would be a pity if this work assumed that all
or most data is cleartext. I'd say just adding a sentence that
this is in scope for consideration would be enough.

[Ballot comment]
The second architecture milestone seems aggressive given that the architecture is described as covering every technology and every layer. Harmonizing across all of those seems like it will be more than six months' worth of work.

[Ballot comment]
This is fine to go for external review.

I'm not clear on the distinction between the architecture work and the applicability work. Do these necessarily need to be two separate documents? Sounds like they have a lot of crossover. (Generally, I don't like when charters specify which *documents* need to be produced. I prefer charters to list the specific work that needs to be completed and leave how to organize the documents to the WG to decide.)