Re: ASON reqts - Moving on?

[Stephen Trowbridge <sjtrowbridge@lucent.com>]

Adrian,

Adrian Farrel wrote:
snip
> The motives are to
> - make those requirements accessible to the IETF community
>    in a form and format with which they are familiar
Two issues here: "accessibility" and "form and format"
In terms of accessibility, the "original" ASON requirements
(G.8080, G.7713, etc.) have all been sent via liaison from
ITU-T to IETF. Those that haven't been translated to html
or pdf by the secretariat for direct access from the IETF site
are available from the SG15 FTP site.

In terms of form and format, give me a break. There have been
multiple forms/formats/sets of vocabulary involved with
virtually every corner of the telecom field that I have
been involved with over the last 25 years. But many of the
smartest people I know are also in this field, and as long
as people are willing to work together and try to understand,
there has never been a problem. For example, SONET and SDH
have different names for almost everything, but by now
anyone involved with these technologies is bi-lingual and
can understand a concept perfectly well no matter which
terminology it is described in. SONET people even understand
it when Maarten Vissers describes equipment functions using
triangles and tapezoids. So I don't think there is a pressing
need to "translate" these specifications to ASCII/IETF-ese.

Doing translations creates its own set of problems. First of
all, one has to worry about the accuracy of the translation.
Second, it creates a maintenance problem: once something is
documented in two places, which is the controlling document?
When a correction or update needs to occur, it now needs to
happen in both places.

Of course, if people aren't willing to work together and try
to understand, no amount of spoon feeding, ASCII translation,
etc. will help this.

> - provide a basis for determining whether current protocol
>   solutions fully address the requirements.
So we started with requirements documents (not all IETF) and
produced protocol solutions, and now we should decide whether
the protocol solutions met the requirements by producing a
translation of the requirements? It seems like it would be
better to do this kind of validation against the ORIGINAL
requirements than against a translation: then you don't need
to decide whether an apparent mismatch is an unmet requirement
or a bad translation. If a problem is found, it can be fixed
at its source instead of in some downstream document.

To assess the motivation you expressed for embarking on this
effort, it kind of sounds like "2 (keep the protocol the same
and document everythinig in IETF) unless the editors decide
to switch to 3, 4, or 5 later*!?)

Regards,
Steve