[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



"Further, I'll add that any claims to the effect that this will somehow
entice vendors
to rush to include their "unique" features in the document, fall into the
category of FUD."

I agree completely.  The large group that has been working on the draft over
the past year
or so has NOT been falling over themselves adding proprietary bells and
whistles.  Rather
the feature set has been pretty much static over the lifetime of the
document.

Thanks,

John   

-----Original Message-----
From: Paul Bonenfant [mailto:pbonenfant@photuris.com]
Sent: Thursday, May 24, 2001 9:50 AM
To: 'Zhi-Wei Lin'; 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


Zhi,

Apologies in advance, it may seem like I'm picking on
you, but I'm not.  Honest.

I'm one of the N-30 (where N = the sum of [non-overlapping
subscribers to the ccamp, ip-optical, q11/15, and t1x1.5 
email exploders]) observers here, and I note that you are 
listed as an author of the draft.  

With all due respect, it seems a bit odd for the authors
to be debating the issue of what does/does-not belong in 
the draft with such vigor, over so many public email 
exploders, in response to a last call on the draft. How 
did the signaling for provisioning all of these features 
make it into the draft in the first place? What "metric" 
was used (in reference to another thread)?  IMO these 
_are_ fair questions. 

As an observer, it seems to me that all was well until it 
was recognized that one of the included features happened 
to be one that was once proposed in, but not supported by, 
T1X1 and/or ITU-T.  Oops.  Begin dilemma -- remove only
this feature, or all non/pre-standard features from the
draft?  Discussion ensues -- no end in sight. 

Well, perhaps we should discuss the "utility of a standard" 
metric.  I doubt (just a hunch here) that GMPLS-SONET/SDH 
is being developed solely for use in legacy equipment.  I
also doubt that carriers requesting "new" features will be 
pleased with a GMPLS-SONET/SDH draft that addresses none
of them. 

For what it's worth, I'll repeat that I support the proposal
to "tag" non/pre-standard items as such, and proceed with 
the draft in its current form.  Further, I'll add that any
claims to the effect that this will somehow entice vendors
to rush to include their "unique" features in the document,
fall into the category of FUD. 
  
Regards,

Paul

-----Original Message-----
From: Zhi-Wei Lin [mailto:zwlin@lucent.com]
Sent: Wednesday, May 23, 2001 11: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
>

_______________________________________________
IP-Optical mailing list
IP-Optical@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/ip-optical