Cutting to the chase:
How about allowing PROTO shepherds to post to the I-D tracker?
See whether draft-ietf-proto-wgchair-tracker-ext-01.txt
covers what you want. If not, immediately would be
a very good time to tell the PROTO team.
Brian
___
Adrian Farrel [EMAIL PROTECTED] writes:
But note that the current version of the tracker does not raise the
DISCUSS with anyone. It simply logs it.
I agree, and think this is an important observation.
This lack of communication may cause friction. IESG members raise
issues, which ends up the
I have had the same experience.
The tracker is not mentioned in any of the process documents or the desription
of ietf process or the web site (which continues to be useless).
The impression is of a clique who know their procedures internally, do nothing
to explain them to others then get
On 2007-01-09 14:03, Hallam-Baker, Phillip wrote:
...
The tracker is not mentioned in any of the process documents
That is normal; it's a tool used in support of the process,
and we could in theory use papyrus rolls instead.
I agree we need procedural documents too; that is
what IONs are for
On Tue, 9 Jan 2007 05:03:57 -0800
Hallam-Baker, Phillip [EMAIL PROTECTED] wrote:
I have had the same experience.
The tracker is not mentioned in any of the process documents or the
desription of ietf process or the web site (which continues to be
useless).
The impression is of a clique
Steve Bellovin wrote:
Dave, a lot of this discussion has boiled down to a single topic, one
that's been talked about for a very long time: early, cross-area review.
Unfortunately, we've tried several schemes that haven't worked and we
don't really know how to do better. All have had some
Dave Crocker [EMAIL PROTECTED] wrote:
However none cover the reason for Design Summaries (I'm changing the name,
a bit.) The nature of a Summary has the wg take a step back from daily
details and create a snapshot of the basic design and specification
decisions, to date, but not as a
The nature of a Summary has the wg take a step back from daily
details and create a snapshot of the basic design and specification
decisions, to date, but not as a list of individual decisions (or open
issues.)
This sounds as if it would be extremely helpful to folks sitting in
on WG
The IESG has approved the following document:
- 'Key Change Strategies for TCP-MD5 '
draft-bellovin-keyroll2385-04.txt as an Informational RFC
This document has been reviewed in the IETF but is not the product of an
IETF Working Group.
The IESG contact person is Russ Housley.
A URL of this
