[Rats] use case draft --- adopting or dropping or ???

[Michael Richardson <[e-mail]>]

I've been asked what happens with the use case draft.
I've been asked why the working group hasn't adopted it yet, etc.

I want to remind of three things:
  1) the IESG doesn't want to publish use case documents on their own, so
     this document is never going forward as it is.

  2) the intention of this document was that it be a live collection of use
     cases and pointers to users of attestation.

  3) that the WG chairs can put a document on the agenda even if it's not a
     WG document.

The only reason to adopt the use case document into being a WG document is if
makes it easier to do scheduling, as we have a guideline that WG documents
get priority on the agenda.  The WG chairs can also declare a document as a
WG document by fiat, they don't actually have to Call for Adoption; that's
just the most consensus friendly path that we tend to take.

It may also help others to find the document in the WG list.
I am agnostic as to what the name on the document is though.
It takes the same amount of effort to write/maintain the document.
Other organizations tend to do things like approve travel more easily for
authors of WG documents.

At this point we are merging pieces of the use case document into the
architecture document, but it seems reasonable that some detailed use cases
might not fit into the architecture document.  Specifically, it might be that
the additional user doesn't provide any motivation for any unique
architecture components.

My proposal is that the use case document will linger in the state that it
is, that additions and edits will be welcome, but that there will be no
specific effort on the document until after the Feb. Hackathon/Tutorial.
Once the architecture is more mature, that a revision to the use case
document will occur connecting use cases to architectural structures.

I further propose that some users will want to write detailed profiles of
RATS as unique documents within the IETF or within other organizations.
That, as this happens, the more extensive textual description of the case
will become a reference to that document.  Such a profile document would have
to start with a problem statement (use case description) anyway.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [





--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-