That
sounds reasonable.
Monica
A. Lazer
Advanced Transport Technology and
Architecture Planning
![](bin00003.bin)
![](gif00000.gif)
908 234 8462
mlazer@att.com
-----Original
Message-----
From: Guo-Qiang Wang
[mailto:guoqiang@nortelnetworks.com]
Sent: Friday, May 25, 2001 9:23 AM
To: 'Lyndon Ong'; Zhi-Wei Lin;
John Drake
Cc: 'Eve Varma'; Mannie, Eric;
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 concatena tion
Hi,
From my observation for the past two weeks, it
seems to me that we do have some
"interworking" problem even within this
small group discussion. The issues are either
syntactical ("should we put arbitrary
concatenation into GMPLS spec"), or semantically
("what is proprietary"). We can imagine
how hard it will be if we extend this discussion
to a large scope.
Our purpose is to define a "standard"
GMPLS which has to be widely accepted and supported by vendors and carriers. To
not jeopardize the last call process, I will suggest
you guys separate GMPLS
(transport portion) as two drafts:
1. Standard draft:
This portion spec
is based on current ITU/T1X1 transport standard, and agreed by
all you
people. This draft can get into last call now without delaying GMPLS
progress.
2. Non-standard draft:
This is for
people who are working on innovation/revolution/evolution for next
generation
transport. Eventually it may be merged into GMPLS if can get
industry
acceptance.
Doing so we can avoid endless discussion without
getting any significant progress,
also we give the implementation flexibility to
vendor/carrier. In their PICS (Protocol
Implementation Conformation Specification), if they
only implement standard portion,
they simply reference to GMPLS RFC. If they
implement both, they reference to
GMPLS RFC and X-draft for interworking purpose.
Regards,
G.Q Wang
Emerging
Network Technology
Nortel Networks
Tel: (613)765-4195 (ESN 395-4195)
Fax: (613)768-1140
guoqiang@nortelnetworks.com
-----Original
Message-----
From: Lyndon
Ong [SMTP:lyndon_ong@eudoramail.com]
Sent: Friday,
May 25, 2001 1:25 AM
To: Zhi-Wei
Lin; John Drake
Cc: 'Eve
Varma'; Mannie, Eric; Wang, Guo-Qiang [KAN:0V10:EXCH]; 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
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
> > > >