Hi Dave,
Some comments in-line.
At 09:59 AM 2/25/2003 -0800, Dave Crocker wrote:
Folks,
Thursday, January 30, 2003, 10:05:11 AM, you wrote:
EB> Executive Summary: Accept John's second proposal. That is,
EB> take the charter as is, and insert a May 2003 deliverable of
EB> "lemonade Architecture, IESG and IETF Review, and Possible
EB> Rechartering".
I've waited to comment, because I was hoping to achieve some insight
that would allow a more directly constructive contribution. Alas, all
that has happened is time passing. Perhaps that is indicative of
something worth heeding by the WG...
With considerable regret, I find myself having to offer the following:
I believe Eric's suggestion is an excellent way to ensure that the
working group takes a long time, and is unproductive at the end of it.
At base, the charter does not tell me what concrete problem this
working group is solving or what use the output will be.
Here are the salient bits of text, from the opening paragraph of the
proposed charter -- and remember that the opening paragraph is
circulated independently, as the summary of the working group; therefore
it needs to summarize the problem and summarize the utility of the
output, if not also summarizing what will be done:
"...facilitate operation in environments which use Internet-based
technologies but which have link characteristics, device
characteristics, or service environments that are significantly
different from those common on the Internet..."
I think I contributed this text during a previous round of charter discussions;
sorry that it remains unclear. From my point of view, the basic
problem here is that there are a set of services which are being
contemplated or deployed in specific environments which are based on
IETF protocols but do not interoperate with them, either well or at all.
The list you saw above: link characteristics, device characteristics,
or service environments are the differences cited by those operating
those service environments as reasons for wanting "profiles" of
IETF protocols that meet their needs. From my point of view,
we need to encourage them to do the protocol work in a way that
maintains interoperability with the core IETF protocols. Hence
this language:
"A primary goal of this work is to ensure that those profiles and
enhancements continue to interoperate with the existing Internet
email protocols in use on the Internet, so that these environments
and more traditional Internet users have access to a seamless
service."
No doubt I am misinterpreting this, but it sure sounds as if the goal is
to create some sort of new email service and try to make sure it can be
gatewayed to existing Internet email services?
Actually, avoiding the need to gateway between services is one of
my own goals for this work. As it stands, some of those developing
these extensions are presuming that they will be able to handle
any interoperability problem with a gateway that shifts between their
version and the big-I Internet version. The intent of "seamless service"
was, I believe, trying to get that message across: you should not have
to have independent application layer protocols because you have
different service environments. Better text welcome, as always.
I personally believe that you may, however, have to describe how to
use a set of protocols in an interoperable way when there are different
service environments involved. In so doing, you may find some
part of the set which needs update or extension.
So...
For this effort to be productive, the charter must be much, much more
clear and precise about the concrete, technical or operational problems
that exist and must give a concrete, constrained description of what is
going to be done to solve them. And it must do this in simple, direct,
specific language.
While I would welcome this, we also have to be practical about
the scale of things we put into the charter. I think John's proposal
was to make this an early work item, so that later work can
be more focused about the problems which give rise to
these profiles of IETF messaging standards and what we can
do solve them in an interoperable way. I believe that knowing the
non-interoperable profiles exist is enough to identify the need
to go through that part of the exercise.
regards,
Ted Hardie