I'm strongly opposed to both changes. Necessary raises the
bar much too high and we really need to focus on the current
set of documents. Just look at how many issues we already have open.
We have running code. The issues that are open relate to the description
of how the code runs.
Moreover I think that a major reason behind some of the open issues is a
problem of perspective that becomes much clearer with a wider view.
Remember, if we decide that other documents need to be
produced the charter can always be amended to say as much.
Not only is a charter that says "may produce some other
stuff" increase the liklihood of rathole exploration, I
suspect it would not pass muster with the IESG, which has a
pretty consistent track record of rejecting open-ended
charters. (It certainly would not have been acceptable in my
day, and not because of any objection of mine.)
Stating that it is in scope for a WG to describe an interface to
EXISTING specifications is not open ended, nor is it the type of thing
that the IESG has a habbit of rejecting. On the contrary it is exactly
the type of question they do ask.
If I was security AD the question I would be asking here is 'How will
this specification work with PKIX, SAML and XKMS?'