Re: ASON reqts

[Stephen Trowbridge <sjtrowbridge@lucent.com>]

All,
I have a growing sense of unease that we could be headed
for trouble here because, among those who seem to support that
this becomes a WG document, there seem to be (among those who
indicate a reason) a wide variety of different motivations about
WHY this should be a WG document and what the posters expect
will happen as a result.

Perhaps more helpful than just a Yes/No preference, it would
be more helpful to characterize the reasons so that, if this
becomes a WG document, we know we have a consensus on why we
are doing this and what we are trying to accomplish.

I think I have detected the following motivations from different
posts in the thread:

1. Those who don't want this to be a WG document (we are done with
   this version of the specifications, lets get some experience
   with them before considering any further change or evolution).

2. Those who think this should be a WG document so that ASON extensions
   currently standardized in ITU-T will get standards track status in
   IETF (no intent to change the protocol, but document the superset
   in one place so that we don't get so many GMPLS implementations
   that don't support the ASON extensions).

3. Those who think there is nothing wrong with the ITU-T extensions to
   meet the ASON requirements, but believe that RFC 3474 didn't translate
   G.7713.2 properly and this draft is a first step to fixing RFC 3474.

4. Those who think that even the ITU-T extensions don't meet the ASON
   requirements, so IETF should now take it over and do it better starting
   with this draft.

5. Those who think that ITU-T didn't get the requirements right, so we
   need to look at everything from scratch.

There may be other motivations which I haven't detected or characterized,
but these seem to be the main camps.

So I don't think it is enough to just count how many say it should be
a WG document. I think that those in camp #2 above might be pretty upset
if the result of making this a WG document turns out to be a rototilling
of the protocol driven by those in camps #4 and #5. We will have a much
smoother time if we agree on why we are doing this and what we are trying
to accomplish as a result.

Once we settle on which of 1-5 we are trying to accomplish:
- If it is 1, 2, or 3, we can handle in IETF.
- If it is 4 or 5, we had better send a liaison to ITU-T.

Please let me know if I missed any proposed purposes for this draft.
Otherwise, for those of you who support this being a WG draft, I think
it might be helpful if you would indicate which of (2-5) characterizes
why you support this so we can make sure we are on the same page as to
what we are trying to accomplish.

Regards,
Steve