Stephen and Fred,
One of the interesting issues with 5378 is that there has never
been consensus about what problem(s) it was trying to solve.
The WG reached consensus on the two documents without, IMO,
reaching consensus on the problem statement. Nothing in our
procedures prohibits that, whether it is wise or not in a
particular case.
However, to the extent to which "the problem" has been handing
off documents to other bodies, I believe it has always been a
distraction because there is a far easier solution... even
easier than the "go ask that set of authors" suggestion that
Fred proposes.
One thing that has always been vague, perhaps deliberately, is
just where the boundary of "use in the IETF for IETF purposes"
(a crude paraphrase of the intent that has dominated our
thinking since 2026 and before) lies. With the understanding
that their situations are a bit different because of different
basic IPR rules, other standards bodies have regularly
interpreted their equivalent principles as giving them the
ability to transfer change control to someone else _as a natural
part of their own work_. I say "regularly", rather than "often"
because, AFAIK, inter-SDO transfers have never been frequent
(except for specifications developed as national standards by
ISO Member Bodies and then transferred to ISO (or ISO/IEC) for
development and maintenance as International Standards).
Sometimes it might require a bit of a dance --for example, we
could define an IEEE WG as being joint with a shadow IETF one,
but then permit it to work under IEEE rules and approval and
publications process-- but the big issue is the handing over of
change control, not the handing over of the document and the
right to maintain it.
From that perspective, the "transfer" situation is entirely a
problem of definitions. It is up to the Trustees to get an
opinion from Counsel, but, as a common-sense matter and with the
understanding that I'm one of the more reluctant members of the
community to hand "do whatever you want" rights off to the Trust
without a formal copyright transfer, I just can't imagine an
author/ contributor who would be ok with the IETF using a
Contribution in IETF Standards work for the benefit of the
Internet community taking serious exception to the IETF's
delegating responsibility for that Standard and its maintenance
to some other body.
If I'm correct and transfer of a Standard to another SDO is
really a non-issue, then perhaps the question of what problem(s)
5378 was intended to solve becomes more relevant... or perhaps
it does not. But, given the problems the 5378/5377 model has
turned out to create, eliminating one of the major claimed
reasons for creating that model makes it much easier to consider
just repealing the things and doing a small update to 3978/4748
to de-glitch them.
john
--On Friday, January 09, 2009 0:59 +0000 Stephen Farrell
<stephen(_dot_)farrell(_at_)cs(_dot_)tcd(_dot_)ie> wrote:
+1 to fred's proposal, let the exceptions be just that and
don't bother most I-D authors,
Stephen.
On 8 Jan 2009, at 22:49, Fred Baker <fred(_at_)cisco(_dot_)com> wrote:
You asked me to make this comment publicly, so here it is.
In my opinion, we need a 5378-bis that keeps the good bits
but corrects the issue that has been problematic. The
question before the house is how best to achieve that. The
proposal here is to provide a work-around that enables an
internet draft author to state that s/he has not verified
...
From my perspective, the best approach involves keeping the
general case simple. The documents that have been
transferred outside the IETF in the past five years is a
single digit number, a tenth of a percent of all RFCs if
not a smaller fraction. From my perspective, the simplest
solution to the transfer issue is to ask the people
relevant to a document for which transfer has been suggested
whether they have an issue with transferring it, rather
than asking every document author his or her opinion on the
...
As to the other issues that 5378 addresses, I suspect that a
better approach will be to fall back to 3978/4748/2026
temporarily and move to 5378-bis when it comes rather than
to use this very general workaround to 5378's issues until
5378-bis is resolved. 3978 etc worked just fine for most
purposes...
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf