RE: ASON reqts

[John Drake <jdrake@calient.net>]

Stephen,

If this I-D is progressed, it will be used as the basis for deciding between
2, 3, and 4, although I don't see any practical difference between 3 and 4.
I haven't seen 5 expressed by anyone (at least in the context of this I-D).

Thanks,

John

> -----Original Message-----
> From: Stephen Trowbridge [mailto:sjtrowbridge@lucent.com]
> Sent: Wednesday, May 14, 2003 6:49 AM
> To: Ash, Gerald R (Jerry), ALABS
> Cc: Wijnen, Bert (Bert); ccamp@ops.ietf.org
> Subject: Re: ASON reqts
> 
> 
> 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
>