Subject: Front-end delays

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 14 Jun 2005 14:51:57 -0400

There has been a fair amount of effort in accelerating the tail end  
of the document process, i.e., after IETF last call. It is unclear  
whether this has succeeded (as there don't seem to be any published  
measurements), but I believe that the main problem with timeliness is  
now in the WG process itself. Each case is unique, but there are a  
disturbing number of modest-size documents that have taken 3 to 5  
years from first individual draft to RFC. In a separate message, I'll  
have more process- and people-oriented suggestions, but here are some  
simple things that would at least allow us to measure, and thus  
manage, delays:

(1) Problem: Currently, the mapping between charter items and drafts  
is often vague and those not intimately involved with the process are  
often left to guess which draft(s) meant to address which charter item.

Proposal: Once the I-Ds have been created, the charter is updated to  
reflect I-D names. This doesn't have to be done for every single  
draft, but doing such an update once for each IETF meeting seems  
easy, as there are no substantive changes.

(2) The I-D tracker should keep track of the charter deadline for  
each document so that the author and WG chairs can trivially see  
whether a document is on track or not. [This item can obviously be  
used to automatically generate (1).]

(3) At each WG meeting, it should be expected that after the agenda  
bashing, the delivery schedule for each draft is reviewed, maybe with  
a red (already out of schedule), yellow (likely to miss schedule) and  
green (possible/likely to meet schedule) indication.

(4) Just like the RFC editor and IANA provides statistics, each area  
should provide an overview of its status at the IESG plenary,  
indicating the major work items of each WG and whether the WG is  
generally on schedule or behind. Again, one could imagine a color  
coding, e.g., if 30% or more of the charter items are "in the red",  
the WG is flagged red.

Clearly, WG chairs and ADs could "game" the system to make the WG  
look on time, by continuously adjusting schedules or by having  
deadlines a decade out. That itself, however, would provide an  
indication that a WG is not meeting deadlines or is planning to be  
really slow. If one wanted to, one could indicate both original and  
current deadline for work items.

None of these items make things faster, but they would allow the IETF  
management to apply project management tools, such as reducing scope,  
replacing authors, or working group chairs, with some efficiency.  
More on hypotheses for why things are late in another note.

Henning

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: "Lucy E. Lynch" <[email-masked]>
Date: Tue, 14 Jun 2005 15:30:16 -0700 (PDT)

Excuse top posting, please.

Many of the issues related to WG progress can be managed using the
excellent web tools provided at tools.ietf.org - see for example:
http://tools.ietf.org/wg/ccamp/

This site makes review quick and easy. Clicking on a draft title
gets you not just txt but a nits check and diffs from any previous
versions. See:  draft-ietf-ccamp-gmpls-ason-lexicography-02.txt

The top menu includes links to email the WG Chair(s) and:
Drafts | Agendas | Minutes |  Charter | List Archive
making it easy to review the Charter, check the list archive for
comments on a given draft, and review minutes etc.

There is also a link to a Draft dependency graph at the top of the drafts
page. The graph shows you where cross area review might help a draft
progress, as well as highlighting blocking drafts, expired work, etc.

If every WG had and used such a page to triage work based on blocks and
cross-area dependencies things might move faster. Authors (and WG
reviewers) can also use the nits/diffs/and list archives to make sure that
individual documents are in shape to move forward.

Getting people to use the tools is a seperate issue. Just another mash
note from a tools.ietf.org fan...

Lucy E. Lynch 				Academic User Services
Computing Center			University of Oregon
llynch  @darkwing.uoregon.edu		(541) 346-1774

---

From: Keith Moore <[email-masked]>
Date: Tue, 14 Jun 2005 18:37:16 -0400

> often left to guess which draft(s) meant to address which charter item.

IMHO, at WG charter time we typically don't understand the problem
well enough to be specifying things like how many documents there should
be in the final product or what should be in those documents.    That,
and "published an I-D describing X" is not a very useful charter
milestone. To the extent we make milestones out of documents we should
require that the WG get rough consensus on those documents before they
are considered complete. 

The milestones we most need to track aren't the WG's final products,
but the preliminary steps, because the failure of a WG to address
important details early its lifetime is what seems to cause WGs to bog
down later.  

I don't see anything wrong with creating milestones like this:

- the WG needs to reach consensus on a document describing its
  scope in detail - design goals and non-goals, and identifying
  any effects that the WG's work might have on other concerns.
  this doesn't have to be published as an RFC, and it might 
  actually be better if it's not published as an RFC.  but it does
  need to get WG consensus.

- the WG needs to solicit external review of that document and 
  respond to that review and revise the document as appropriate

- the WG needs to entertain and review proposals for a solution
  (including soliciting external review)

- the proposers need to respond to review and revise their
  proposals

- the WG needs to choose one or more candidates for a solution
  from among the revised proposals

etc.

If we took pains to select useful milestones, a WG progress
tracker might be quite useful.

Keith

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 15 Jun 2005 05:05:07 -0400

> comments on a given draft, and review minutes etc.

These tools are useful, but don't track (for example) working group last 
calls. They don't even track interim meetings, at least based on my 
limited checks.

Finding list comments by draft in a mailing list works fine when a 
working group focuses on one main spec, but there are many working 
groups that progress literally dozens of specs at the same time. Just 
take a look at the active I-D list for SIPPING and AVT, to cite two 
groups I'm familiar with. In some cases, subject headers contain the 
draft title - in most cases, they don't and they may use such helpful 
subject headings like "Last call comments" or "IETF 62 discussion".

(Besides the problem that a search facility for the mailing list 
archives is non-existent. Not a problem for a small mailing list, but 
try flipping through the WG list which generates hundreds of messages a 
month and has been active for five years plus...)

> individual documents are in shape to move forward.

I'm sorry to say that for the drafts that took years to progress, 'nits' 
problems were not exactly the reason. I wish it was that easy to fix.

> note from a tools.ietf.org fan...

These are all useful tools and I commend whoever is working on them. 
They are just not quite up to the task to address the problems I 
mentioned, in my opinion.

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 15 Jun 2005 05:35:23 -0400

Keith,

I think there are two stages of chartering:

- the early "we don't quite know what we're doing and what shape this 
will take, just the general direction"

and the

- "most work items have drafts associated with them"

In my suggestion, a WG would amend the charter with additional detail 
once a draft has been started. Alternatively, if charter items are 
referencable (database) items rather than text, the I-D tracker could 
easily point to the charter item the draft addresses, without amending 
the charter.

Also, I think that part of the difficulty of having this discussion is 
that our experiences are biased by the working groups we participate in. 
There are at least two kinds, from what I can tell:

(1) Single "big-ticket" item: "Develop a [new] protocol to do X". There 
is one clear main spec, with auxiliary documents such as requirements, 
MIBs and such. This classical IETF approach used to dominate; I'm 
guessing that relatively few WGs follow this model today. Among the 
groups I attend, NSIS and ECRIT are relatively close to that model.

(2) Maintenance WG: A WG is maintaining a technology and producing a 
more-or-less steady stream of related extensions, specifications and 
updates. Examples I'm familiar with include MMUSIC, AVT, SIPPING, SIP, 
TSVWG.

Clearly, a WG with three specs on its charter can function well with 
manual processes and human memory. SIPPING, to continue the example, 
lists (http://tools.ietf.org/wg/sipping/) on the order of 40 drafts in 
various stages of being processed.

Btw, there are some WGs that make this a bit easier: See 
http://www.ietf.org/html.charters/6lowpan-charter.html for an example. 
(Unfortunately, my example isn't helped that in this particular case 
none of the drafts referenced seem to exist, although all but one 
deadline has passed.)

Henning

---

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 15 Jun 2005 07:33:55 -0500

Henning,

Thank you for a series of reasonable suggestions.

My thoughts are inline.

Spencer

> measurements), but I believe that the main problem with timeliness 
> is  now in the WG process itself. Each case is unique, but there are 
> a  disturbing number of modest-size documents that have taken 3 to 5 
> years from first individual draft to RFC. In a separate message, 
> I'll  have more process- and people-oriented suggestions, but here 
> are some  simple things that would at least allow us to measure, and 
> thus  manage, delays:

Whether "the main problem with timeliness is now in the WG process 
itself" is true or not, it is worth removing systemic sources of delay 
in the WG process.

> is often vague and those not intimately involved with the process 
> are  often left to guess which draft(s) meant to address which 
> charter item.
>

I like this suggestion. The gotcha is that "I-D creation" is not a 
one-step process, as many WGs start out with individual drafts that 
get renamed, and even combined, as they are adopted as WG drafts.

If your suggestion is "once the I-Ds have been adopted as WG I-Ds for 
a charter milestone ...", I think this would work well - and would 
also point out the milestones with approaching dates where the WG has 
not even agreed on baseline text.

There is one missing aspect to this - WG charters aren't consistent 
between "the WG thinks we're through" (we requested publication) and 
"the IETF thinks we're through" (the document has been approved for 
publication). We give WGs and ADs a lot of flexibility in specifying 
milestones - do we need this flexibility? If charters said, "we have 
three dates for each document - WG draft adopted, publication 
requested, approved for publication", and tracked these dates, we 
would know a lot more about where the delays in the process are than 
we know today.

> used to automatically generate (1).]

As you say, this is an obviously good thing to do, given (1).

> bashing, the delivery schedule for each draft is reviewed, maybe 
> with  a red (already out of schedule), yellow (likely to miss 
> schedule) and  green (possible/likely to meet schedule) indication.

Two points here -

The IETF face-to-face meeting is supposed to be our high-bandwidth 
exchange opportunity, so reviewing this schedule, with color coding, 
can also help us focus on what documents need our attention. This 
could also be a time for editors to say, "I need help", or even, "you 
need another editor".

A number of WGs are in constant tension between the current charter 
deliverables and adopting new work items. If a WG can say, "look, 
we're all green, except for two yellow documents that we have a plan 
to recover", that's got to help an AD agree to a new charter item.

> coding, e.g., if 30% or more of the charter items are "in the red", 

Back in the days of 40 or so APPS area working groups, the APPS ADs 
presented their report card for the APPS working groups at an APPS 
Open Area meeting, usually on Monday morning. I believe their 
classification was something like "on time", "late, but making 
progress", or "lost in the weeds". We probably don't need a 
quantitative scale for this - simply assigning colors would give the 
WGs a heads-up about what their ADs think, and how much "attention" 
the WG is likely to get in the next meeting cycle.

> current deadline for work items.

I can't believe we don't track original planned dates plus current 
forecast dates now. We also lose all track of when milestones were 
completed, because the dates are replaced by DONE. I would like to see 
this happen.

> None of these items make things faster, but they would allow the 
> IETF  management to apply project management tools, such as reducing 
> scope,  replacing authors, or working group chairs, with some 
> efficiency.  More on hypotheses for why things are late in another 
> note.
>
> Henning
>
>
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 15 Jun 2005 09:27:09 -0400

> itself" is true or not, it is worth removing systemic sources of delay 

You can also read it as "we've tried to reform the tail end of the 
process and we have either succeeded or run out of energy to do more" :-)

> one-step process, as many WGs start out with individual drafts that get 
> renamed, and even combined, as they are adopted as WG drafts.
> 
> If your suggestion is "once the I-Ds have been adopted as WG I-Ds for a 
> charter milestone ...", I think this would work well - and would also 
> point out the milestones with approaching dates where the WG has not 
> even agreed on baseline text.

Yes, that's what I meant. In some cases, this may also encourage early 
conversion, as documents often linger in draft-somebody state long after 
they have been adopted as draft-ietf (making them almost impossible to 
find for outsiders).

> three dates for each document - WG draft adopted, publication requested, 
> approved for publication", and tracked these dates, we would know a lot 
> more about where the delays in the process are than we know today.

I agree that having three dates would be even more useful, particular if 
they become standard "fields" in the charter "record". I'm happy to 
start with one, which is a lot better than zero. Ideally, the delta-t 
after the "submit to IESG" should be a lot more predictable, given the 
IESG process reforms.

> exchange opportunity, so reviewing this schedule, with color coding, can 
> also help us focus on what documents need our attention. This could also 
> be a time for editors to say, "I need help", or even, "you need another 
> editor".

Side motivation: A little bit of public accountability can't hurt. If 
somebody had gone out to design a design that discourages such 
accountability, the current system seems to meet that objective very well.

> deliverables and adopting new work items. If a WG can say, "look, we're 
> all green, except for two yellow documents that we have a plan to 
> recover", that's got to help an AD agree to a new charter item.

This also applies to authors. There are lots of authors that for 
whatever reason (inability to estimate time available or resume padding) 
volunteer for lots of drafts. Telling a prospective author/editor that 
they have three red drafts and that they might not be the best person to 
do this until these drafts have cleared can be helpful as well.

> presented their report card for the APPS working groups at an APPS Open 
> Area meeting, usually on Monday morning. I believe their classification 
> was something like "on time", "late, but making progress", or "lost in 
> the weeds". We probably don't need a quantitative scale for this - 
> simply assigning colors would give the WGs a heads-up about what their 
> ADs think, and how much "attention" the WG is likely to get in the next 
> meeting cycle.

I can well imagine a more detailed review during the area open meeting, 
but I think that having a high-level review of WG status during the 
plenary would be helpful. After all, this is the business of the IETF 
and would, among other things, also encourage cross-area review and 
maybe even yield some interesting questions from the floor, rather than 
re-visiting the NAT issue for the twentieth time.

> completed, because the dates are replaced by DONE. I would like to see 

This "DONE" also means that we have no easy way to look back and 
systematically compare how realistic WG charter deadlines are. My 
suspicion is that we meet less than 10% of our original charter 
deadlines, but I have no way to prove this except trying to somehow dig 
out mailing list archive messages at great tedium.

Henning

---

From: wayne <[email-masked]>
Date: Wed, 15 Jun 2005 09:20:48 -0500

> http://tools.ietf.org/wg/ccamp/

This link should be put on the font page of the IETF website.

Google shows no links to these tools from the IETF website, and only
one link on the entire Internet:

http://www.google.com/search?hl=en&lr=&safe=off&c2coff=1&q=link%3Atools.ietf.org%2F&btnG=Search

> note from a tools.ietf.org fan...

It is hard to get people to use tools when they don't know they exist
and are very hard to find.

-wayne

---

From: Edward Lewis <[email-masked]>
Date: Wed, 15 Jun 2005 11:06:39 -0400

>and are very hard to find.

I'd like to add a me too to that and a few suggestions...

I'd like to add that the datatracker be easier to find that having it 
"buried" under the IESG roster on the IESG page.  I've referenced the 
datatracker a lot recently, more so that I thought I ever would.  I 
think it ought to be up front on the IETF site (i.e., www.ietf.org), 
as this is the best indication of the current state of 
$topic-or-group.

Another tool that I was alerted to that I find helpful is the draft "differ" at
     http://tools.ietf.org/wg/<wg name>/<draft name>/
If it weren't for my WG chair telling me this was being done, I would 
have never seen it for documents I am editing.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

If you knew what I was thinking, you'd understand what I was saying.

---

From: David Hopwood <[email-masked]>
Date: Wed, 15 Jun 2005 16:43:28 +0100

wayne wrote:
> "Lucy E. Lynch" <[email-masked]> writes:
> 

Very useful. For example, apparently IESG is waiting for the authors of
RFC3546bis, while the authors thought they were waiting for IESG. I think
this kind of temporary deadlock probably happens a lot.

> This link should be put on the front page of the IETF website.

And on the top
"home | working groups | meetings | proceedings | I-D index | RFCs" bar.

-- 
David Hopwood <[email-masked]>

---

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 15 Jun 2005 20:06:08 +0200

Hi Henning and Lucy,

   First thanks, Lucy, for the ack on the wg tools :-)

More inline:

> calls. They don't even track interim meetings, at least based on my 

True on both counts.  I have code in place to track WG last calls, but
haven't had resources to handle the mails from all mailing list so far.
Possibly I'll have that in place before IETF-63.

> month and has been active for five years plus...)

Agreed.  I'll see if I can arrange a way to Google search individual
mailing lists, by more or less devious means.  Stay tuned.

> mentioned, in my opinion.

Again, agreed.  I've been thinking for a month or so about adding colour-
coding for the drafts, but in a slightly different way to begin with:

The submission dates for each draft are the fixed dates we have available
to work with currently, so I thought I'd simply arrange to have a time-
line for each draft, with the interval between each new version submission
colour-coded starting with green, with a gradient into yellow, orange and
red as a function of the time since the last update.

I'd like to change that to a colour indication related to schedule dates
in the charters when machine-readable dates are available for e.g. the
three milestone dates for a draft suggested by Spencer: "WG draft adopted,
publication requested, approved for publication".

Regards,

	Henrik

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 15 Jun 2005 15:02:26 -0400

> Possibly I'll have that in place before IETF-63.

Maybe an alternate approach would be to provide an interface which chairs 
would use to _issue_ last calls, which would update the tracker, send the 
announcement to the WG mailing list, and automatically send the chair(s) a 
reminder when the specified expiration date passes.

-- Jeff

---

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 15 Jun 2005 22:05:55 +0200

> reminder when the specified expiration date passes.

Sounds like a good idea.  However it requires direct integration with the
tracker, which means that the tools team can't just put up a prototype,
the way we've put up the tools.ietf.org/wg/<wg> pages.  

I've added this to the tool suggestions page,
http://tools.ietf.org/wiki/ToolSuggestions

	Henrik

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 15 Jun 2005 19:53:10 -0400

> tracker, which means that the tools team can't just put up a prototype,

Not really - one could associate the WGLC with just the draft name, and 
use that name as the key into the tracker. A similar approach could be 
used to track charter deadlines.

---

From: Henrik Levkowetz <[email-masked]>
Date: Thu, 16 Jun 2005 08:22:42 +0200

> used to track charter deadlines.

That won't feed the WGLC information into the tracker, which was the
most salient point of Jeffrey's idea, I thought.  Without that, you're
left with something close to what I first described.

	Henrik

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 16 Jun 2005 10:04:26 +0200

wayne wrote:

> Google shows no links to these tools from the IETF website

Google's "link" query is an odd beast, maybe it uses whatever
GoogleBot considers as "canonical" URL.  I get more realistic
results with ?q=fqdn.example+-site:fqdn.example

http://www.google.com/search?q=tools.ietf.org+-site:tools.ietf.org

About 162 hits.  Adding +site:ietf.org (i.e. only IETF links) I
get about 63 hits.  

Putting this and the I-D tracker on the main page is a good 
idea.  Such "Web site issues" are something you have already
heard about elsewhere. <gd&r>
                              Bye, Frank

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 16 Jun 2005 05:50:19 -0400

> left with something close to what I first described.

I was envisioning a "meta"-tracker, just like you already have for 
drafts on the WG overview page. In other words, it would show 
information from your database (WGLC date range, charter deadlines, 
etc.) as well as the state from the 'real' I-D tracker.

It obviously would be much better to have these integrated, but changing 
the I-D tracker seems to be somewhat difficult.

---

From: "Spencer Dawkins" <[email-masked]>
Date: Thu, 16 Jun 2005 06:04:00 -0500

Henning Schulzrinne wrote:
> It obviously would be much better to have these integrated, but
> changing the I-D tracker seems to be somewhat difficult.

My co-workers and I were looking at a specific working group home page
yesterday - the working group is showing "DONE" for all of its
milestones except for "Submit revised charter and milestones to IESG
for IESG consideration of more detailed deliverables and determination
of usefulness of continuation of WG", but when you look further down,
there are *30* Internet-Drafts listed.

The I-D Tracker shows clearly what is happening - 10 are in
"publication requested", and 14 are in the RFC Editor queue, but you
can't tell this from the WG home page.

As long as we are wishing for integration with the I-D tracker, it
would be nice to produce the I-D tracker output for the working group
when you view the home page (much more useful than saying "here are 30
Internet-Drafts; they may be approved, or not, and the working group
may still be working on them, or not").

Spencer

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 16 Jun 2005 15:37:50 +0200

Edward Lewis wrote:
> think it ought to be up front on the IETF site (i.e., www.ietf.org), as 
> this is the best indication of the current state of $topic-or-group.
> 

It's well understood that the ietf.org site is hard to navigate and needs
substantial reorganisation. But this is a major project and will take
time to plan and implement.

You can in fact find the tools page off the IESG Activities/Actions
page, so it's only one level down. And I agree, that page is in need
of a clean-up.

While we're talking, let me point to a recently created "operational
notes" page at http://www.ietf.org/u/ietfchair/opNotes.html
Comments welcome. That too is currently linked in an obscure place.
Nevertheless, Google found it in 0.38 seconds.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 16 Jun 2005 17:43:43 +0200

> left with something close to what I first described.

Could we focus on tools *requirements*? This is a very good
conversation but what we need to distill is functional requirements.
If that means re-engineering the I-D tracker, so be it, but let's
cross that bridge when we come to it.

It would also be good to distill education requirements, and feed
them to the EDU team.

    Brian

---

From: "Marshall Eubanks" <[email-masked]>
Date: Thu, 16 Jun 2005 12:36:55 -0400

On Thu, 16 Jun 2005 15:37:50 +0200
> time to plan and implement.

Dear Brian;

Since in a real way this is the public interface of the IETF (and since I have heard
lots of complaints about it over the years), wouldn't it make sense to

- specifically ask for public suggestions for improvements
- have a BOF or an open house in Paris or Vancouver devoted to discussing this

This was done in DC at IETF 61 for the IETF multicast video and it seemed to work well
(multicast video of 2 rooms is now unicast audio of all rooms).

Regards
Marshall

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 17 Jun 2005 10:27:49 +0200

Marshall,

> - have a BOF or an open house in Paris or Vancouver devoted to discussing this

I agree that we need public comment before action. The challenge with
web design is that explaining what's wrong and what would be better is
very hard to do except in front of the screen. I'm not sure a BOF style
meeting would succeed. Also, I'm pretty sure we can't prepare for this
by Paris - it's resource constrained.

    Brian

---

From: Lars Eggert <[email-masked]>
Date: Fri, 17 Jun 2005 10:59:12 +0200

On Jun 15, 2005, at 16:20 , wayne wrote:
> In <[email-masked]> "Lucy  
> E. Lynch" <[email-masked]> writes:
>

Let me suggest to put these links at the top of each WG charter page:

- http://tools.ietf.org/wg/<wg-name>/
- datatracker search for "filename includes WG name"
- http://rtg.ietf.org/~fenner/ietf/deps/viz/<wg-name>.pdf

Even only the first one would be great to have!

Lars
-- 
Lars Eggert                                     NEC Network Laboratories

---

From: "Marshall Eubanks" <[email-masked]>
Date: Fri, 17 Jun 2005 09:19:25 -0400

On Fri, 17 Jun 2005 10:27:49 +0200
> by Paris - it's resource constrained.

I agree, and have no doubt that Paris is too soon. However, I also know that feature creep
(add X to the front page, as in the
title of this thread) is not really a good way to do web design - 
and that the IETF site is ripe for a re-design. 

I (like, I suspect, many others) basically use Google as my initial IETF resource for
everything except meetings. (For example, when I first heard about IETF tools, I
went to Google and rapidly found the tools site and a bunch more.) Google basically solves
the forward problem (find out more about X), but it does little for the
inverse problem (which set of X's should I know about), and this, IMHO, is what the
IETF web site should assist with, and does not (much). This, of course, cannot be solved
by hiring a fancy web design shop in Venice Beach or Soho and telling them to go to it,
but will require thought and community input.

Regards
Marshall

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 17 Jun 2005 23:53:37 +0200

Lars Eggert wrote:
 
> put these links at the top of each WG charter page:

My temporary solution for the second link is a redirection:
http://purl.net/xyzzy/-ietf/ltru

Replace LTRU by any WG you're interested in.  Bye, Frank