Re: [T1X1.5] RE: [IP-Optical] Re: Proposed text for the concatenation

[Lyndon Ong <lyndon_ong@eudoramail.com>]

Zhi-Wei,

First of all, I hope that you agree that having this exchange is a good
indication that this is a "fair and open process".  I'm surprised that this
should be in question, given that we progress via consensus (OK, "rough"
consensus) like many other standards bodies.

Secondly, part of the problem is that I would interpret "proprietary" as
meaning "exclusive", that is, intending to have exclusive control over some
technology (close to the dictionary definition).  I believe you interpret 
"proprietary"
as something that has not been commonly defined in ITU (or other accredited 
bodies).
Maybe "non-standard" would be a more neutral term.

Something like the arbitrary concatenation we have been talking about is,
I think, the latter case - it is not exclusive technology, but it is 
relatively
new and not everyone has taken advantage of it.  Our goal should be to
achieve interoperability for such features, not to prohibit them.  Agreeing
in common on how to identify them in signaling seems like a good step.

Cheers,

Lyndon


At 05:25 PM 5/24/2001 -0400, Zhi-Wei Lin wrote:
>I feel that I should at least try to explain my comments since people
>may mis-interpret.
>
>As I said several emails ago, and have sort of repeated...we can move in
>any direction as long as we make CLEAR what the method is for
>evaluating.
>
>I did not try to denigrate, nor belittle the work of the numerous
>authors. In fact I highly respect many of the authors of the documents.
>Maybe my analogies are too strong, in that case I apologize. But the
>fact remains that we seem to be looking at this from different angles
>and thus causing all the discussions. I think the reason is that we all
>have different backgrounds and different understanding of some basic
>terms.
>
>My proposal is to outline the specific metrics used for including and
>excluding the features, add the metric as part of the document so that a
>person picking up the document understands the rationales behind this,
>and list ALL the assumptions and limitations of the documents so that
>there is no misunderstanding.
>
>For example, are these the metrics for including features?????
>
>* There must be at least 2 vendors that support a feature. In that case,
>we need to quantify or show that this is indeed the case. Making claims
>without substantiation IMO would not help...
>* There must be at least one operator asking for the feature.
>* For each feature identified that are extensions of the standards, do
>we need to describe what it is, how it functions, what is needed to
>interoperate, what impacts it has on current networks, does it work with
>current networks, what is the scope of the feature (network-wide or
>enterprise only), is there any security considerations (allows malicious
>users to gain free service), etc. etc...
>
>OR maybe the metrics may be:
>
>* All features in the main body should conform to standards.
>* Any other features not part of standards may be described in an
>appendix, but no codepoints are assigned. Reserve a range of codepoints
>for proprietary extensions
>
>
>OR any other metrics that may be used. But we HAVE to enumerate this so
>that the telecom/internet community can look upon this and say, "yes,
>this was a fair and open process where any vendor or operator can apply
>the metrics to any feature without any subjective decision being made
>against any feature"...
>
>
>Zhi
>
>
>
>John Drake wrote:
> >
> > Eve,
> >
> > Okay, for the sake of discussion, we'll assume that the last two thirds of
> > the e-mail
> > don't exist and focus on the first third:
> >
> > "As for how many vendor is needed for a standard. Again this question
> > doesn't really apply. We as engineers and the development community has
> > to study a problem to make sure that it will not unduly impact existing
> > networks, that what we are looking at should be sound and technically
> > superior and that it will help provide added value to networks. As these
> > transport capabilities will likely require people of transport expertise
> > to study first, that's what we should do. Let's not get too "trigger
> > happy" and include something "just because it's there", and then decide
> > to remove when "standards say no". That like "putting the cart in front
> > of the horse".
> >
> > The way I read this, it says to me that the people involved in working on
> > the
> > draft are unqualifed to be working on it and that none of the work that 
> they
> > have
> > done over the past year is of any value, so my earlier comments still
> > obtain.
> >
> > Furthermore, your comments about slippery slope disturb me because they
> > follow
> > a pattern of filibustering and dissemination of FUD which seems to be aimed
> > at
> > preventing forward progress.
> >
> > Thanks,
> >
> > John
> >
> > -----Original Message-----
> > From: Eve Varma [mailto:evarma@lucent.com]
> > Sent: Thursday, May 24, 2001 10:30 AM
> > To: John Drake
> > Cc: 'Zhi-Wei Lin'; Mannie, Eric; 'Guo-Qiang Wang'; ccamp@ops.ietf.org;
> > ip-optical@lists.bell-labs.com; q11/15; t1x1.5
> > Subject: Re: [T1X1.5] RE: [IP-Optical] Re: Proposed text for the
> > concatenation
> >
> > Hi all,
> >
> > I don't think Zhi had any intent to denigrate other individuals whose
> > names were on the draft (in fact, several have expressed similar
> > concerns).  I think the key point was in the earlier part of the
> > message; as expressed in an earlier message from Juergen Heiles, there's
> > considerable concern that we're descending a slippery slope that could
> > ultimately have negative impacts.
> >
> >                        Cheers,
> >                             Eve
> >
> > John Drake wrote:
> > >
> > > I find this message to be very puzzling.  As far as I know, the 
> authors as
> > a
> > > group are extremely conversant with the
> > > subject matter in the draft and the draft represents their best current
> > > thinking.  You seem to be trying disparage them because you don't agree
> > with
> > > their solution, and I think that that is extremely unprofessional.
> > >
> > > The authors spent a long time working out the details of what is 
> presented
> > > in the draft, which you airily dismiss with:
> > >
> > > "As to how many companies and how many people's names are on the
> > > contribution. Let's be intelligent adults here. As someone once asked
> > > me, "if you see a million flies eating feces, would you also eat?"
> > > (sorry people! it is disgusting but I had to give an extreme analogy).
> > > Sometimes the majority may not be correct. I am not saying I am correct
> > > either. It all depends on the background knowledge base and the
> > > underlying motive of the people..."
> > >
> > > "As to how many processes followed, how many meetings held, how many
> > > conferences given, how many emails exchanged...an idea doesn't get
> > > better with repetition. As someone once said at some standards meeting
> > > "if an idea stinks, it doesn't matter how many times some idea is
> > > presented, it still stinks that many times". So the number of times is
> > > not a reason for making a decision."
> > >
> > > If you're not happy with the draft, you are perfectly free to remove your
> > > name from it, but don't denigrate the other
> > > authors.
> > >
> > > John
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: Zhi-Wei Lin [mailto:zwlin@lucent.com]
> > > Sent: Wednesday, May 23, 2001 8:38 PM
> > > To: Mannie, Eric
> > > Cc: 'Guo-Qiang Wang'; ccamp@ops.ietf.org;
> > > ip-optical@lists.bell-labs.com; q11/15; t1x1.5
> > > Subject: Re: [IP-Optical] Re: Proposed text for the concatenation
> > >
> > > Hi,
> > >
> > > I think your questions cannot be answered either way. Whether features
> > > are needed for one or two vendors is up to each vendor to decide what
> > > they want.
> > >
> > > As for how many vendor is needed for a standard. Again this question
> > > doesn't really apply. We as engineers and the development community has
> > > to study a problem to make sure that it will not unduly impact existing
> > > networks, that what we are looking at should be sound and technically
> > > superior and that it will help provide added value to networks. As these
> > > transport capabilities will likely require people of transport expertise
> > > to study first, that's what we should do. Let's not get too "trigger
> > > happy" and include something "just because it's there", and then decide
> > > to remove when "standards say no". That like "putting the cart in front
> > > of the horse".
> > >
> > > As to how many companies and how many people's names are on the
> > > contribution. Let's be intelligent adults here. As someone once asked
> > > me, "if you see a million flies eating feces, would you also eat?"
> > > (sorry people! it is disgusting but I had to give an extreme analogy).
> > > Sometimes the majority may not be correct. I am not saying I am correct
> > > either. It all depends on the background knowledge base and the
> > > underlying motive of the people...
> > >
> > > As to how many processes followed, how many meetings held, how many
> > > conferences given, how many emails exchanged...an idea doesn't get
> > > better with repetition. As someone once said at some standards meeting
> > > "if an idea stinks, it doesn't matter how many times some idea is
> > > presented, it still stinks that many times". So the number of times is
> > > not a reason for making a decision.
> > >
> > > Let's be technical, let the experts in the right group decide, and we
> > > should not jump the gun. Let's be adults and let's help make the telecom
> > > industry and the standards process a respectable place...
> > >
> > > "Mannie, Eric" wrote:
> > >
> > > > I don't work for a vendor :-) Who told you that some features are 
> needed
> > > > only for one or two vendors ? How do you quantify the number of vendors
> > > that
> > > > are needed to have a standard ? We work on a consensus based and this
> > > draft
> > > > has 17 companies on it with 30 people. Usually it is much much less at
> > the
> > > > IETF, you only have a small number of co-authors. I already gave a
> > summary
> > > > of the process that we followed, all the meetings that we hold, all the
> > > > conference call that we hold, all the e-mails that we exchanged, etc.
> > > >
> > > > You described one model in your e-mail, that's a valid model but 
> this is
> > > not
> > > > THE (only) model. There are plenty of other models that can be 
> fulfilled
> > > > with GMPLS.
> > > >
> > > > Kind regards,
> > > >
> > > > Eric
> > > >