Subject: Request for Agenda Items for VRRP session at Chicago IETF

From: Bob Hinden <[email-masked]>
Date: Mon, 06 Jul 1998 10:21:27 -0700

The VRRP working group will meet for one session at the Chicago IETF.  It is:

  Tuesday, August 25 at 0900-1000

The tentative agenda is:

  - Finalizing VRRP MIB w/ goal of moving it to Proposed Standard

  - Start process of collecting implementation information in preparation
    for moving VRRP (RFC 2338) to Draft Standard

Please me proposed agenda items including topic description and
length of time required.

Thanks,

Bob Hinden
VRRP w.g. Chair

---

From: Scott Barvick <[email-masked]>
Date: Mon, 06 Jul 1998 17:41:24 -0400

I believe there were several points raised on both the spec and the MIB
after the last IETF.  Some seemed to have been resolved and some just
didn't get discussed anymore.  Can we get the resolved items into new
drafts and get a list of the open items that seemed to need action.

Because I imagine that several implementations will be getting ready to
ship soon, I'd like to get those items that might cause version problems
resolved now.  The TTL issue comes to mind.  There were comments that it
should be 1 instead of 255. 

Also, getting another round of the MIB that has the
vrrpOperAssoIpAddrTable indexed by ifindex.vrid.ipaddress (not
ipAddrIndex) and the vrrpOperProtocol field added to the vrrpOperTable
as agreed (?) before Chicago would be very helpful.

These were just from memory (I didn't go back through the archives) so
there may be others.

Scott

-- 
Scott Barvick
[email-masked]
(978) 952-6000 x162

---

From: Matt Holdrege <[email-masked]>
Date: Mon, 06 Jul 1998 15:08:59 -0700

>    for moving VRRP (RFC 2338) to Draft Standard

What's the latest with IPR?

Didn't Cisco send a note to this list a few months ago saying (something
along the lines of) that they wouldn't allow any other company to ship
VRRP? How can this move to draft standard with IPR restrictions?

If anyone has more encouraging news, I'd love to hear it.

---

From: Tony Li <[email-masked]>
Date: Mon, 6 Jul 1998 15:27:22 -0700 (PDT)

|  Didn't Cisco send a note to this list a few months ago saying (something
|  along the lines of) that they wouldn't allow any other company to ship
|  VRRP? How can this move to draft standard with IPR restrictions?

More correctly: they said that they felt that a VRRP implementation would
infringe on the HSRP patent.

Of course, if you contact Cisco to try to get a license (for VRRP or HSRP),
you get black holed.

As to progressing the specification, RFC 2026, section 10.3.2 reads:

10.3.2. Standards Track Documents

   (A)  Where any patents, patent applications, or other proprietary
      rights are known, or claimed, with respect to any specification on
      the standards track, and brought to the attention of the IESG, the
      IESG shall not advance the specification without including in the
      document a note indicating the existence of such rights, or
      claimed rights.  Where implementations are required before
      advancement of a specification, only implementations that have, by
      statement of the implementors, taken adequate steps to comply with
      any such rights, or claimed rights, shall be considered for the
      purpose of showing the adequacy of the specification.

Thus, lacking licensing, it may be difficult to demonstrate
implementations.  I would read this as saying that the implementors must
either license or must make some convincing argument (to what audience?)
that the Cisco patent is not pertinent.

Tony

---

From: Acee Lindem <[email-masked]>
Date: Mon, 06 Jul 1998 18:54:05 -0400

> that the Cisco patent is not pertinent.

Possibly, an updated RFC is required with Cisco's claim documented.
However, I'd hope the IP law issues could be debated/negotiated by the 
IP lawyers. 

-- 
Acee

---

From: Bob Hinden <[email-masked]>
Date: Mon, 06 Jul 1998 15:56:33 -0700

Matt,

>What's the latest with IPR?

Nothing new that I am aware of.  Cisco and IBM have made statements
regarding IPR (see minutes for more details).

>VRRP? How can this move to draft standard with IPR restrictions?

My understanding of the process is that there is no direct correlation with
IPR issues and moving to Draft standard as long as the IETF procedures for
moving documents to Draft standard are followed (e.g., multiple independent
implementations, six months after Proposed status, etc.).  I aware of one
(and reasonably sure of a second) shipping VRRP product implementations and
more in progress.  I believe that this will meet the multiple
implementation requirements for Draft.

The IESG does not take a position on the merits of IPR claims.  It comes
down to each company considering adding a protocol to its products to
evaluate the clams and decide if it thinks there is any infringement.

Bob

---

From: Tony Li <[email-masked]>
Date: Mon, 6 Jul 1998 16:04:01 -0700 (PDT)

|  Possibly, an updated RFC is required with Cisco's claim documented.
|  However, I'd hope the IP law issues could be debated/negotiated by the 
|  IP lawyers. 

Acee,

I don't see how either of these is relevant to satisfying RFC 2026.

Tony

---

From: Acee Lindem <[email-masked]>
Date: Mon, 06 Jul 1998 19:18:24 -0400

> I don't see how either of these is relevant to satisfying RFC 2026.

--  10.3.2. Standards Track Documents
>       claimed rights.  

Why couldn't this be satisfied via documentation in a revision of
the RFC? 

>       Where implementations are required before

As exemplified by your comment that the audience isn't specified, this is
a rather nebulous requirement and possibly one that can best be handled
by the IP lawyers, vis-a-vis, the IESG. 

Acee

---

From: Tony Li <[email-masked]>
Date: Mon, 6 Jul 1998 16:28:11 -0700 (PDT)

|  >    (A)  Where any patents, patent applications, or other proprietary
|  >       rights are known, or claimed, with respect to any specification on
|  >       the standards track, and brought to the attention of the IESG, the
|  >       IESG shall not advance the specification without including in the
|  >       document a note indicating the existence of such rights, or
|  >       claimed rights.  
|  
|  Why couldn't this be satisfied via documentation in a revision of
|  the RFC? 

As this is legalese, you should notice that the requirement is to note the
existence of the patent.  Yes, that could be trivially satisfied.  Note
also that it is NOT necessary to document the details of the claim.

|  >       Where implementations are required before
|  >       advancement of a specification, only implementations that have, by
|  >       statement of the implementors, taken adequate steps to comply with
|  >       any such rights, or claimed rights, shall be considered for the
|  >       purpose of showing the adequacy of the specification.
|  
|  As exemplified by your comment that the audience isn't specified, this is
|  a rather nebulous requirement and possibly one that can best be handled
|  by the IP lawyers, vis-a-vis, the IESG. 

I should have also included paragraph B:

   (B)  The IESG disclaims any responsibility for identifying the
      existence of or for evaluating the applicability of any claimed
      copyrights, patents, patent applications, or other rights in the
      fulfilling of the its obligations under (A), and will take no
      position on the validity or scope of any such rights.

This is also to say that the IESG _cannot_ deliberate on the applicability
of a patent.

Thus, the onus is still on the implementors.  What's not clear is how
seriously this will be taken.  If an implementor claims that no licensing
is necessary, is that sufficient?  Obviously the IESG/IETF incur no
liability by believing them.  But that means that we could trivially also
have situations where the implementors fibbed big and we ended up with
specs based on infringing implementations.  

Yes, this is a messy area.  No the process is not very clear here, and I
don't think we've seen an analogous situation before in the IETF.

Tony

---

From: Bob Hinden <[email-masked]>
Date: Mon, 06 Jul 1998 16:47:22 -0700

Tony,

>I don't see how either of these is relevant to satisfying RFC 2026.

Given that RFC 2026 was published in October 1996 and VRRP (RFC-2338) was
published as a Proposed Standard in April 1998, the IESG must have had a
different interpretation.

I reread section 10 in RFC2026.  The section quoted is part of section 10.3
pertaining to rights and permissions of contributed work.  A good example
of this was when Sun Microsystems turned over rights to RPC and XDR to the
IETF.  These protocols would not be made a standard until all IPR rights
were resolved.  

I do not think Section 10.3.2 applies to IPR claims made against IETF
developed technology (e.g., VRRP).  

Bob

---

From: Bob Hinden <[email-masked]>
Date: Mon, 06 Jul 1998 17:05:42 -0700

Tony,

Yes, this is all terribly messy.  

>specs based on infringing implementations.  

I think that the IESG's approach is two fold: 1) They publish all IPR
notices/disclosures/etc. on the IETF web site (www.ietf.org/ipr.html), and
2) They wait to see if multiple implementations get built.  If multiple
implementations do get built, then they assume that the IPR issues have
been resolved.  If not, then the protocol never gets to Draft Standard and
eventually times out.

>don't think we've seen an analogous situation before in the IETF.

Yes, very messy.  I think this is the first time I am aware of that an
organization has tried to use it's IPR claims to keep people from
exercising an open standard (as opposed to licensing it).  Not good form IMHO.

Bob

---

From: Venkat Prasad <[email-masked]>
Date: Mon, 06 Jul 1998 17:02:39 -0700

> don't think we've seen an analogous situation before in the IETF.

The Compression Control Protocol from PPPEXT working group went
through similar IP issues 

- vp

---

From: Tony Li <[email-masked]>
Date: Mon, 6 Jul 1998 17:07:15 -0700 (PDT)

|  I do not think Section 10.3.2 applies to IPR claims made against IETF
|  developed technology (e.g., VRRP).  

Based on previous experience dealing with IPR claims made against IETF
developed technology in other WGs, it has most certainly been applied
before.

Tony

---

From: Tony Li <[email-masked]>
Date: Mon, 6 Jul 1998 17:22:31 -0700 (PDT)

|  Yes, very messy.  I think this is the first time I am aware of that an
|  organization has tried to use it's IPR claims to keep people from
|  exercising an open standard (as opposed to licensing it).  Not good form IMHO.

Umm....  I'd say that it's pretty clear that it's not the first case.  I
was involved in a similar situation with another standard where the
criteria for non-discrimanatory licensing was met, but the 'reasonable'
criteria was clearly out the door.

In this case, the IPR owner had a shaky claim that they were using as a
club over the heads of the WG.  

This IS the first case that I've seen where a company has offered to
license if their contribution was accepted (as required) and then been
turned away.

Tony

---

From: Bob Hinden <[email-masked]>
Date: Mon, 06 Jul 1998 17:26:35 -0700

Tony,

>developed technology in other WGs, it has most certainly been applied

Good thing we have the IESG to sort this stuff out :-)

Bob