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

Re: [Idr] WG Last Call on draft-ietf-idr-flow-spec-05.txt



I've avoided comment on this in detail as well, for a
number of reasons - specifically, as a co-author, an
implementer, one of the earliest evangelists, and very
heavily pushing operational deployment, all after working
with Juniper on implementation interoperability and spec
refinement over the earlier years of the draft.

Myself and *many* others helped push for this type of
capability in the late 2002 and early 2003 timeframe, as
it seemed a natural evolution to both destination and
source-based blackhole routing, and some BGP community-
based hacks that folks were doing already that provided
some flow-specesque capabilities.  Apparently, Juniper
had a separate parallel effort underway as well.

The fact that Robert, who was at Cisco at the time, was
"fully aware about Juniper's authors filing the patent
application for this work" surprises me, given that I
certainly wasn't, and while I can't speak for others
"authoritatively", I'm pretty sure Jared wasn't either.
The necessity for third party disclosure here comes to
mind, as Thomas pointed out, given that Robert was a
co-author as well, and we all presumably subscribed to
what was outlined in the boilerplate of every iteration
of the draft.

I've long understood the IETF IPR rules and the absolute
need for disclosure - and this has certainly been cemented
in my mind since I saw the flow-spec disclosure only a
few months ago on a draft that had been baking since 2003.
Personally, it's extremely disappointing to have invested
a considerable amount of time and effort into internal
development, interoperability testing with Juniper, spec
refinement, and operational deployment and operational
community education, only to find out some five years later
that your co-authors have IPR claims in this area.

So, to speak in fairness, I asked myself the question: would
I have behaved differently had I known about the IPR?  The
answer was yes, certainly.  As a matter of fact, my company
has made several concerted decisions to avoid working on,
or continuing work on, solutions based on technologies that
are not openly available.

When I talked to Pedro after the first disclosure and
explained why this was such a concern, and engaged with
several other colleagues (many of which I consider friends)
at Juniper on the topic, I was pretty bitter at first.  I
did get pushback from one individual there, but that seems
to have simply been the result of their lack of understanding
of IETF process and related IPR rules - and why they're NOT
simply "legalese", "mechanical", "overhead" "standards
politics" - but absolutely necessary, and why not following
these rules undermines the very foundation of open standards
development.

However, "it is what it is", and that's all water under the
bridge now..

I can say that from my perspective Pedro and several other
IETF participants from Juniper seem to have made virtuous
efforts to remedy my concerns as an IETF participant and
co-author, which are of course separate from the concerns
of my employer.  Furthermore, given that extreme tardiness
of disclosure and the associated ill-effects was my chief
concern, you can't completely ameliorate that.  I do
believe this incident has educated many folks, for the
better, and hope to avoid predicaments of this sort in the
future.

All that said...

I'm fine with the content of the disclosure, and believe the
work has merit.  There are other ways to accomplish the goals
as well, but those are well beyond IDR and heavier if openly
specified and using other machinery.  I would like to see this
document published, presumably as standards track.

-danny