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

[Zhi-Wei Lin <zwlin@lucent.com>]

Hi Eric,

Some comments:

> Let's be democratic as you said, my notion of democracy is not to remove
> these two features from the draft because your don't implement them.

I never said to remove because I don't implement, nor did I ever say I
implement. You're jumping to conclusions. Let's all take your advice and
calm down. What I meant (and everyone can have their own interpretations
of some of my analogies) was that given the discussions of why something
is in and why we include and what the implications for the
interoprability, then we need to be precise and provide description of
the criteria for inclusion and provide adequate means to allow
interoperability.

Rob's suggestion of having two separate documents make sense, and is ONE
way forward. You might have other suggestions that may equally make
sense.

> We said *many* times that we didn't want to include all features from all
> manufacturers but just as small set of basic features that seems to be
> interesting for the industry. The proof is that you don't have in the draft

Again, in terms of metrics, what is considered "interesting for the
industry"? By the vendor community or the carrier community? I just want
us to be clear...no more, no less....

> You are trying to present this work as if it was made and decided by a small
> set of people, that's not right and not fair. The fact is that you didn't
> pay attention to it and came very late into the process trying to impose
> your own ideas to the group. We had exactly the same kind of discussion
> since more than two months with your colleagues one by one, I guess this is
> part of your strategy.

Again, please don't jump to conclusions and stay calm. I didn't mean to
criticize, maybe I did use some analogies to the extreme, but seems
everyone's temper was at edge...As to paying attention to the work,
etc., we all know how much discussion about adding features goes on on
the public email. Not to criticize anyone, but just stating a fact. I
also remember that this is been discussed continuously for a few months
as well, so it's not something that was simply started now. Maybe the
realization about the implications of adding this was something that
came to light for a few people, including myself...

And I'm not strategizing to take over the world...far from it, I'm
terrible at playing strategy or role-playing games... :-(

> We proposed, as requested by your colleagues, to make a distinction between
> what is defined in SDH/SONET and what is not. I agreed that's a good idea to
> clarify the draft. In addition, these two mechanisms are 100% optional. Now
> of course you want more, you want to remove everything (that's what you call
> democracy). Obviously, you don't want to reach a consensus, does it worth to
> continue these discussions ?

I don't see what I said would trigger you to say that I want to "remove
everything"? All I've tried to do is to try to inject some of my logic
into this discussion (obviously I failed miserably), by laying out the
rationales, and then deciding. This was based on all the back-and-forth
volleying of "standard, non-standard, proprietary" discussions. 


Zhi



"Mannie, Eric" wrote:
> 
> Hello Zhi,
> 
> Let's be adult as you said many times, we are speaking about TWO features
> (not hundreds as you like to present it):
> 
> - transparency.
> - concatenation.
> 
> You are afraid that implementation will not interoperate ? You should better
> speak first about the two signaling protocols that we have in GMPLS. GMPLS
> has options, like all control planes and nobody has to implement everything.
> This is signaling not a transmission format.
> 
> >So, what is the metric for deciding? I'm sure there are many vendors who
> >are reading this waiting to add their "unique" features to the document
> >as well...
> 
> We said *many* times that we didn't want to include all features from all
> manufacturers but just as small set of basic features that seems to be
> interesting for the industry. The proof is that you don't have in the draft
> these hundreds of famous features that are you are afraid by. What else
> should I repeat ?
> 
> Let's be democratic as you said, my notion of democracy is not to remove
> these two features from the draft because your don't implement them.
> 
> I understood from the many e-mails send by your company since three weeks
> that you don't want to see any transparency and any new form of
> concatenation in the draft. However this draft is not your product
> description. It is not a product description, it is a signaling
> specification with options.
> 
> You are trying to present this work as if it was made and decided by a small
> set of people, that's not right and not fair. The fact is that you didn't
> pay attention to it and came very late into the process trying to impose
> your own ideas to the group. We had exactly the same kind of discussion
> since more than two months with your colleagues one by one, I guess this is
> part of your strategy.
> 
> We proposed, as requested by your colleagues, to make a distinction between
> what is defined in SDH/SONET and what is not. I agreed that's a good idea to
> clarify the draft. In addition, these two mechanisms are 100% optional. Now
> of course you want more, you want to remove everything (that's what you call
> democracy). Obviously, you don't want to reach a consensus, does it worth to
> continue these discussions ?
> 
> Regards,
> 
> Eric
> 
> -----Original Message-----
> From: Zhi-Wei Lin [mailto:zwlin@lucent.com]
> Sent: Thursday, May 24, 2001 5:38 AM
> 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