Subject: [newtrk] "Reviewed in the IETF" (was: Re: Document Action: 'US Secure Hash Algorithms (SHA and HMAC-SHA)'to Informational RFC)

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 7 Feb 2006 07:08:23 -0600

Not sure what Newtrk will be up to after Dallas, but the following exhange 
appeared on the IETF Discussion list:

>>> This document has been reviewed in the IETF but is not the product of an
>>> IETF Working Group.
>>
>>Was there a last call for this document?  I do not recall seeing it.
>>
> Informational RFCs do not require Last Calls.

Maybe I should go get a(nother) Diet Pepsi, but this just strikes me wrong

I'm not questioning that it's allowed by our current process - please don't 
think that.

I'm just a lot more comfortable with the idea that anything that gets 
"reviewed in the IETF" gets "last-called in the IETF", and that anything 
that doesn't get "last-called in the IETF" would list specific reviewers, 
rather than spreading the credit/blame in all directions.

Thoughts from others?

Spencer 

.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html

---

From: Eliot Lear <[email-masked]>
Date: Tue, 07 Feb 2006 14:55:23 +0100

Spencer Dawkins wrote:
> Not sure what Newtrk will be up to after Dallas, but the following
> exhange appeared on the IETF Discussion list:
>
This raises the question of where NEWTRK should go from here.  There are
a few possibilities:

   1. Further formalize the cruft process.  As it stands now we did a
      one-off involving only proposed standards prior to 2000.  We could
      give some thought to whether and when other documents should be
      reviewed.  For instance, What about draft and full?  Are they
      sacrosanct?  What about RFCs 2000-3000.  If we look at RFC 3000,
      that document is now five years old.  And then when if ever do we
      return to the PSes that are still live?
   2. Of the PSes that are still around, they should be advanced
      somehow.  I think if they've withstood the test of time and the
      decruft process, perhaps we should consider having them advanced
      at this point without an implementation report.  Certainly nobody
      is going to tinker with, for example, most telnet options.
   3. Should we combine draft/full standard status?  Hasn't time shown
      that doing the work for draft should be enough?

Just some thoughts.

Eliot
.

---

From: John C Klensin <[email-masked]>
Date: Tue, 07 Feb 2006 08:58:51 -0500

--On Tuesday, 07 February, 2006 07:08 -0600 Spencer Dawkins
<[email-masked]> wrote:

> I'm just a lot more comfortable with the idea that anything
> that gets "reviewed in the IETF" gets "last-called in the
> IETF", and that anything that doesn't get "last-called in the
> IETF" would list specific reviewers, rather than spreading the
> credit/blame in all directions.

In principle, I agree.  But we should not make this change
without considering the system of which it is a part.  Right
now, "reviewed in the IETF" is a code for "the IESG looked at it
and make a decision; it was not processed directly by the RFC
Editor".   The alternative today is a disclaimer about
non-approval by the IETF that is so strong as to imply that the
IETF (or at least the IESG) _has_ reviewed the document and
concluded that it is trash.

The RFC Editor does get independent submission documents which
were quietly posted as I-Ds and to which the IETF community paid
no attention.   But the cases you are talking about, and for
which you want to name reviewers, are in a gray area.  In many
cases, they have been posted as I-Ds, extensively discussed on
IETF-related mailing lists, updated several times as the result
of moderately broad IETF community feedback, etc.  In a few
cases, they have gotten more practical consideration, by more
members of the IETF community, than some documents that are
approved for standards-track designations.  To the extent to
which one insists that those go through the IESG to avoid the
disclaimer and to which you insist that the IESG issue a Last
Call in order to say "discussed in the IETF", you are increasing
the workload on the IESG (workload that RFC 3932 was, in part,
intended to reduce) and adding to the number of "noise" Last
Calls circulated in the community.  

I don't think either outcome is desirable.   Moreover, there is
a case to be made that, if I document is widely-circulated and
discussed in the IETF Community, but the IESG does not decide it
important enough to issue a Last Call, it should not be
distinguished from a similar document that goes through the
independent submission path.   Remember that we try to avoid
trying to get into the "seal of approval" model and that we want
to treat both IESG and IETF community time as valuable.  To that
end, I'd prefer to see the IESG issue Last Calls only on issues
for which the IESG believes that community feedback is important
and valuable ... not because they want to attach some particular
level of implied endorsement or avoid a different one.   That
might mean we need to rethink our definitions, especially of
"Informational".  But simply tuning the Last Call rules and
their relationship to specific language seems to me to be the
sort of point-tuning of procedures that keeps getting us into
trouble.

   john

p.s.  Some of the above comments would overlap significantly
with the TechSpec discussions, if the TechSpec discussions were
part of a WG effort.  But they aren't -- they are technically a
design team effort that uses an IETF mailing list -- so there
can't be any fatal overlap with them.

.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 07 Feb 2006 17:14:49 +0100

There will be a General Area open meeting in Dallas,
where both newtk and pesci next steps will be on the
agenda.

    Brian

.

---

From: Leslie Daigle <[email-masked]>
Date: Tue, 07 Feb 2006 11:38:57 -0500

Point of clarification: TechSpec is not a design team.  TechSpec is
in (pre)BoF state. There are 2 document editors, who are tracking
what is going on the public mailing list and updating the document
for discussion at our next (bof) meeting. Someone *is* being
a bit draconian about keeping the discussion focused on the stated
purpose, but she's still (afaik) being consistent with BoF
practices.

It could become a WG, if that's what's required.

.

---

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 7 Feb 2006 11:19:34 -0600

Dear John,

I've now had my first Diet Pepsi of the morning - it might be a detectable 
improvement in IETF process discussions if Ray provided Diet Pepsi in a 
faucet at my house every day, but I digress.

I'm still not entirely comfortable with our use of Informational to cover at 
least different types of documents ("Independent" and "Individual" 
submissions, plus working group Informationals), but it sounds like you have 
the same concerns (if I interpreted your note correctly). I'm also reacting 
to what seems like cases of the words we use not actually meaning what 
anyone outside the IETF would guess that they mean.

Thanks for the reminder on the larger picture. Up-leveling is always 
appropriate.

Spencer

From: "John C Klensin" <[email-masked]>

.

---

From: John C Klensin <[email-masked]>
Date: Tue, 07 Feb 2006 15:51:20 -0500

--On Tuesday, 07 February, 2006 11:38 -0500 Leslie Daigle
<[email-masked]> wrote:

> Point of clarification: TechSpec is not a design team.
> TechSpec is in (pre)BoF state. There are 2 document editors,
> who are tracking what is going on the public mailing list and
> updating the document for discussion at our next (bof)
> meeting. Someone *is* being a bit draconian about keeping the
> discussion focused on the stated purpose, but she's still
> (afaik) being consistent with BoF practices.

> It could become a WG, if that's what's required.

Leslie,

I raised that point because, in the midst of the DKIM discussion
on the IETF list, what I considered a very important point
largely got lost in the broader discussion.  In particular, the
question of "what is the status of agreements reached in pre-WG
discussions vis-a-vis constraining either the discussions of the
WG or responses to a hypothetical Last Call.   

If one looks narrowly at a set of discussions whose purpose is
to get a BOF together than might lead to either a WG or a non-WG
but standards track submission, then the nominal focus of those
discussions is to demonstrate community interest and ability to
reach meaningful consensus about something.  But, under any
procedures we have, the specifics of a substantive proposal that
comes out of the effort are proof of concept rather than in any
way binding on a future WG or a basis on which a Last Call
objection can be ignored because the issue has already been
discussed and decided.

We have language to describe the groups that produce such
substantive, but non-binding, decisions.  The term we use is
"design team" and we have some rather specific language in our
procedures about what design teams can and cannot do and, in
particular, about the degree to which design teams can assume
their outputs are binding on the community and that they have
change control over them.  It seems to me that the "design team"
constraints apply whether one comes into existence wrt an
existing WG or is pre-BOF, and regardless of what one calls the
group.  It also appears to me that we've only got three forms of
document-creation efforts -- individuals, design teams, and WGs.
If something is treated as a WG wrt the presumed authority of
the decisions it is making, then either it is a WG with a
charter on which there is community consensus or, intentionally
or not, it is a subversion of the process.  

As I understood it, that was the difficulty with both DKIM and
with Pesci.  The major difference between the two was that DKIM
really was treated the way we treat design teams: the group
produced a document, the community was not satisfied with it,
the group went back to the drawing board.  With DKIM, the group
produced a proposal but it was claimed that the proposal should
have some special status in the WG because it had been developed
by a group of people who were IETF-experienced, had put a lot of
energy into it, and had followed open procedures.  The other
difference is that I believe we need to be far more careful
about groups who are developing procedures than we do about
technical/ engineering work.

As another type of example that both of us have fought to keep
in balance, if the IAB were to produce a proposal for
standardization of some technology, the status of that proposal,
once it got into IETF processing, would be precisely equivalent
to the status accorded a design team proposal even though that
particular design team might well be presumed to have
above-average insights and mechanisms for determining community
consensus.

So, call it what you will, I believe that either (i) TechSpec
is, to the degree to which it produces a specific proposal or
set of proposal, constrained by the same constraints that apply
to design teams or (ii) it is an unchartered WG (an entity we
don't have) and will remain so until there is a
community-consensus charter and statement of tasks.

   regards,
      john

.

---

From: Leslie Daigle <[email-masked]>
Date: Tue, 07 Feb 2006 15:57:10 -0500

Then we're largely in agreement, as I was not being sensitive
to your specific point about status of the actual document
and eventual last call or other input.

What I was specifically addressing wrt TechSpec is that
there is no special status of the document because of its
editorship or who is providing input.  The design team
is open.

Which (to repeat myself) sounds like we're in agreement.

Leslie.

.

---

From: John C Klensin <[email-masked]>
Date: Tue, 07 Feb 2006 16:05:21 -0500

> Which (to repeat myself) sounds like we're in agreement.

  yes

thanks,
   john

.

---

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 7 Feb 2006 18:36:23 -0600

Dear John,

Your assessment of PESCI makes sense to me; I wasn't as close to DKIM but 
that's what the shouting sounded like in the next room, too.

I should mention to the list that Thomas Narten is doing a revision of his 
I-D on "how to run a successful BOF" (I've seen an interim version, and I 
like it even better than the 00 version. I'd wait for 01 if I hadn't read 
00, but I'd read 01 when it's posted, either way).

This draft is descriptive ("this is what has been observed to work"), but no 
one will be surprised if there are things that get described that we look at 
and say, "this should work better", so there may be a need for a follow-on 
document, too.

A clarification of BOF mailing lists as design team mailing lists might be 
very helpful, for example, especially since ADs can now request creation of 
BOF mailing lists on ietf.org before the BOF request is even approved, and 
they look a lot like WG mailing lists in the same domain.

Thanks,

Spencer

.