Re: ASON reqts

[Stephen Trowbridge <sjtrowbridge@lucent.com>]

John,
I still think it is better to argue it out now and reach agreement
on what problem we are trying to solve.

If we accept this as a WG draft without doing this, we seem to be
accepting that we do have SOME problem to solve, and then arguing
later on what it was.
Regards,
Steve

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