The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] discussion on nexthop fast-reroute drafts
Hi, Please see my comment inline. > To: "Pan, Ping" <ppan@Ciena.com> > Cc: 'Naiming Shen' <naiming@redback.com>, > "'mpls@UU.NET'" <mpls@UU.NET>, > "'enke@redback.com'" <enke@redback.com>, > "'tian@redback.com'" <tian@redback.com> > Subject: Re: discussion on nexthop fast-reroute drafts > References: <829F074A10F98943A218DC363D09C92A019C95DE@w2ksjexg06.ciena.com> > > Yes, I agree partly... > > Source code is not neccessary for routers to be compatible > with each other. RFCs are. If a RFC is accepted that requires > licensing the technology, then at least some routers will > never support that technology because of the licensing, IMO. > This tends to place blackholes within compatibility of the > routers implimenting requirements. > > What happens if John Moy were to place the OSPF RFCs with > licence restrictions? > > Companies make a profit with their expertise in implimenting > technology features, marketing them, etc, and not placing IP > restrictions within IETF docs, IMO. > > I do believe in the past that I "liked" the Informational > RFC to provide that some technology was developed > and could be licensed. This is vs a "Standards Track" RFC > where there should be no licensing concerns and asking for > public comment. > > Isn't comments to modify wording or improve on the implimentation > illogical as to force the implimentation into the public > domain and invalidate the specific property rights? The questions/concerns on the IPR issues you raised are not new, and are really related to a much bigger topic than any specific draft or any working group. IETF has established procedures in dealing with the IPR issues (for years), and there is an IPR working group to refine these procedures. Please see Robert R's pointer in his email: --------------------------------------------------------------- http://www.ietf.org/ipr.html and particulary the belwo text: (C) Where the IESG knows of rights, or claimed rights under (A), the IETF Executive Director shall attempt to obtain from the claimant of such rights, a written assurance that upon approval by the IESG of the relevant Internet standards track specification(s), any party will be able to obtain the right to implement, use and distribute the technology or works when implementing, using or distributing technology based upon the specific specification(s) under openly specified, reasonable, non-discriminatory terms. ---------------------------------------------------------------- If you have an issue with these procedures, I suggest that you take it to the proper IETF authorities, and to the IPR working group. > > Or everyone that comments are given "free perpetual licencing" > and Tablarasa subrights theirs to the IETF/public for no charge. > > Thus, Tablarasa Networks specifies that if the following changes > are made, they are "owned by the public and the IETF standard > licencing clause is in effect". As has been stated many times, IETF takes input from individuals, and not from organizations. (Since you seem to claim to represent your employer, just curious: have your statements here been authorized by Tablarasa Networks?) Regards, -- Enke > > 6. RSVP Bypass Nexthop Object > > 2nd sentence: "neighbor does not aware" -> > "neighbor is not aware" > > 3rd sentence: ""to accept with an alternative" -> > "to accept an alternative" > > bit numbering.. > > Isn't the rightmost numbering of bits to start at > the 0 bit. > > thus bits "1" -> "0" > > and bit "2" -> "1" > > Or do you really wish to leave bit "0" unused. > > I also propose that the IETF, the public public support > dealing with these bits a implimentation to support the > addition of NACKs from the base "Request/Ack" support. > > So, if part or the whole of the short list of comments above > are accepted by the authors / representatives of their > respective companies, then their is an implied acceptance to > modification of the their companies IP rights. > > Further comments/suggestions are withheld... :-) > > Mitchell Erblich > Tablarasa Networks > --------------------- > > > > > "Pan, Ping" wrote: > > > > > -----Original Message----- > > > From: Erblichs [mailto:erblichs@earthlink.net] > > > Sent: Tuesday, April 06, 2004 10:54 PM > > > To: curtis@fictitious.org > > > Cc: Naiming Shen; mpls@UU.NET; Pan, Ping; enke@redback.com; > > > tian@redback.com > > > Subject: Re: discussion on nexthop fast-reroute drafts > > > > > > Interesting... > > > > > > I remember reading in a few RFCs, ex 3478 Graceful Restart > > > Mechanism for Label Distribution Protocol by Juniper and > > > Redback Feb 2003, that "IETF has been notified of > > > Intellectural Property rights ...." > > > > > > So, this has not prevented docs being accepted that restrict > > > compatibility in the past without licensing. > > > > > > I just wonder if people realize why different implimentations > > > don't communicate because of these items or why some routers > > > just ignore certain functionality that is specified in some RFCs. > > > > > > So, if my opinion means anything, I would second this > > > rejection for ALL docs with this type of clause. > > > > > > > I would like to agree with you, but why stop there? Let's open the source code on all routers. Let's make every router vendor to be non-profitable. Let's only work for the good of humanity. Let's pay for IETF ourselves every time we go. Let's... :-) > > > > Unfortunately, the reality is that this is a commercial industry. People spend a lot and work very hard to find the solution for their customers. When they do, they want to make sure that they are providing something unique to the customers, at least for a while. They will try not to implement the things that have been patented by others. But if their customers ask, they will do anyway. > > > > Thanks! > > > > - Ping
|
|