RE: ASON reqts

[John Drake <jdrake@calient.net>]

Regardless of what we do now, I'm sure there will be lots of arguments
later.  

> -----Original Message-----
> From: Stephen Trowbridge [mailto:sjtrowbridge@lucent.com]
> Sent: Wednesday, May 14, 2003 8:24 AM
> To: John Drake
> Cc: Ash, Gerald R (Jerry), ALABS; Wijnen, Bert (Bert);
> ccamp@ops.ietf.org
> Subject: Re: ASON reqts
> 
> 
> John,
> First, I think there is a big difference between 3 and 4 and 
> what should
> be done about it:
> For 3, G.7713.2 is OK, RFC 3474 is broken, and we just need 
> to fix RFC 3474
>   by superceding with something aligned with G.7713.2.
> For 4, G.7713.2 is broken (as is, by extension RFC 3474). 
> Here we need to
>   coordinate with ITU-T to fix both. It seems like a bad 
> strategy to try
>   to have IETF fly solo and develop a "better" solution to 
> ITU-T requirements
>   than what ITU-T did.


JD:  Given that G.7713.2 == RFC3474, what does it matter?  If it
is broken in one venue, there's a good chance it's broken in the
other.


> 
> Back to why it is important to decide where we are going with 
> this first:
> I think that some who support this as a WG document are doing 
> so because
> they want to see the base protocol and the ASON extensions 
> documented in
> a common place, and NOT because they were intending to open 
> the door to
> changing the protocol now. 


JD:  I don't buy this at all.  Until we get agreement on requirements
how do we know whether a given document supports those requirements?


> If we can get agreement over why 
> we are doing
> this now, I think we can avoid a lot of arguments later.


JD:  I completely disagree.  Regardless of what we do now, there will
be plenty of arguments later.


> Regards,
> Steve
> 
> John Drake wrote:
> > 
> > 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
> > >
>