Re: Liaison handling (Re: IAB comments on draft-baker-liaisons-00.txt)

[Stephen J Trowbridge <sjtrowbridge@lucent.com>]

Harald,
Yes and No.

You will remember that not so long ago we had a situation where
documents moving through the IETF process would disappear into
black holes. They would take inordinate amounts of time to move
through the system, and it wasn't widely visible whose court the
ball was in to take the next step.

This process attempts to do for liaison statements what ID tracker
did for these documents. What the mechanism can do for us is to
make it visible to the world which items require a response, from
whom, and by when. Individuals still have the responsibility to
take action, but this kind of public display of the status and who
is on the hook has a way of dramatically increasing the probability
that the needed response is generated on time. I believe that the
tools and mechanisms can do more to get the responses generated than
any amount of private cajoling that Scott can do of WG chairs (just
as ID tracker can do more to keep IDs moving through the process
than any amount of bugging you do of the various ADs and WG chairs).

Thank you for the observation that this is not ITU only. I would even
go so far as to say that we are not trying to solve an ITU problem at
all: we are trying to solve an IETF problem. ITU has experts who are
capable of developing solutions on their own without IETF input
(there are times they thought they could get a better solution WITH
IETF input, but when IETF doesn't respond ...).
It is IETF that is missing the opportunity to influence the directions
of global standardization OUTSIDE of IETF by not responding to (or
spontaneously generating, where appropriate) liaison statements.
Regards,
Steve

On 8/27/2003 7:44 AM, Harald Tveit Alvestrand wrote:
> Fred,
> 
> --On 25. august 2003 14:15 -0700 Fred Baker <fred@cisco.com> wrote:
> 
> 
>>But understand that the objective here is not to send documents to the
>>IETF. It is to get replies from the IETF that are authoritative, and get
>>them on a schedule. Apart from that, there is no point to sending liaison
>>statements. And the ITU feels that it is not getting authoritative
>>replies on a schedule.
> 
> 
> my personal take is that we have a problem here that mechanism can't fix.
> The IETF relies on personal responsibility to get its work done; in the 
> particular case of liaison statements, we've relied on liaisons (persons) 
> to follow up and use their best judgment in making sure the relationship 
> works, and call upon the resources of the rest of the IETF as needed.
> 
> That mechanism has failed.
> 
> With all respect to Scott: If the ITU has been sending liaison statements 
> to the IETF that the IETF has not responded to, and the ITU thinks it 
> should, Scott, as our liaison to the ITU, has a problem.
> That problem may involve the fact that other people aren't responding when 
> he asks them to - but if there is an organizational base problem, and we 
> don't look at the base problem, the only result of adding more mechanism 
> will be to make the base problem better documented.
> 
> Since Scott has been part of the process that produced this document, I 
> must assume that Scott thinks that this process will help him, in ways that 
> the current "statements@ietf.org" mechanism cannot. Scott, can you confirm 
> that?
> 
> But this document is not aimed at the ITU only; it's aimed at liaisons in 
> general. So I'd think one logical step would be to ask the people we have 
> made responsible for our liaison relationships:
> 
> - Do you see the problems described in this document?
> - Will the processes described in this document make a significant 
> difference in solving them?
> 
> Our liaison people are listed on the IAB web page. They should be easy to 
> ask.
> 
>                     Harald
> 
> 
> 
>