Virtual Router Redundancy Protocol (VRRP)
draft-ietf-vrrp-spec-v2-10

In Author's 48 Hours:

From: RFC Editor
Subject: authors 48 hours: RFC 3768
        NOW AVAILABLE
Date: Mon, 12 Apr 2004 15:08:22 -0700
To: bob.hinden@nokia.com
Cc: RFC Editor , Alex Zinin
    , Bill Fenner ,
    radia.perlman@sun.com, Mukesh.Gupta@nokia.com

[Ballot comment]
After discussing the issue, and after reading section 4.1 of draft-ietf-ipr-technology-rights-12.txt, and after considering that the IPR issues with VRRP are extremely well known in the community, I have decided that the evidence of implementation and the lack of comment in Last Call indicates that the community wants to consider the IPR issues with VRRP acceptable.
Of course, this assumption can be challenged at any time, as technology-rights says.

[Ballot comment]
I have 2 nits:

- It claims (in abstract) that RFC2338 will be made HISTORIC
  I am OK with that, but we should all be aware that we seem
  to decide that as well when we pass this document. And we
  then need to pass that on to RFC-Editor.
  But normally a new RFC just obsoletes an old one. Sop maybe
  some explanatory text as to why the old doc needs to be made
  HISTORIC makes sense
- I see a piece of IPR text at bottom of section 1 (top of
  page 4). Similar text is also repeated in IPR section (where
  it indeed belongs). Might as well removed it from page 4.

[Ballot discuss]
The document states that IPR claims have been filed against this protocol.
The interoperability report does not say that the implementations resulted from independent invocations of the licensing agreement (if any is needed).
Unfortunately, we can probably not ignore this issue.

[Ballot comment]
The document states that IPR claims have been filed against this protocol.
The interoperability report does not say that the implementations resulted from independent invocations of the licensing agreement (if any is needed). It's probably taken as implicit, but it would be nice to have it explicit.

[Ballot discuss]
Section 10, the security considerations, clearly indicates that incorrectly configured or hostile routers can become VRRP masters.  This statement proves the need for an authentication mechanism  However, previously supported authentication is being removed.  I believe that the section should be expanded to state what harm a malicious router can cause if it becomes the VRRP master.

[Ballot discuss]
The implementation report lists several implementations, but
does not include any information about which features of
the protocol are implemented by each implementation.  Also,
no details are provided regarding any type of interoperability
testing.

[Ballot comment]
Meta-comment:

(Bob wrote and gave some background on the version numbers,
pointing out that 2328 was also version 2, and that the early
versions would not have been interoperable with this in any
useful way.  Leaving the comment in for the record, but not
having this in the draft makes sense to me now)

The draft does a good job of motivating VRRP, but it doesn't seem to tackle
the question of the transition to this version.  Since this version specifies
that any other version number than 2 means the packet should be tossed,
clearly there is no aim for interoperability among versions (making historic
2328 being another clue here).  The only text about the previous version
I saw, though, was in describing why the authentication mechanisms were
tossed out, and that didn't seem to motivate it.

As a personal comment, I think some discussion of the need for a transition
(and motivation for why no backwards compatibility is required) would be
valuable.  It would not, obviously, affect protocol processing, though, so
this is just a comment.


Nits:

1.1

"currnet RFC Editor policies"--> current RFC Editor policies.

2.3
"that is more preferential than the current Master." seems clumsy;
would "that is preferred over the current Master." be better?

5.3.3
I think it would be valuable to make clear here that VRID is
a configured item.  It is mentioned later in section 6.1, but a
forward pointer or repeat of the text might be useful here. (Not
a protocol issue, obviously, just helpful to the new reader)

[Ballot comment]
Meta-comment:

The draft does a good job of motivating VRRP, but it doesn't seem to tackle
the question of the transition to this version.  Since this version specifies
that any other version number than 2 means the packet should be tossed,
clearly there is no aim for interoperability among versions (making historic
2328 being another clue here).  The only text about the previous version
I saw, though, was in describing why the authentication mechanisms were
tossed out, and that didn't seem to motivate it.

As a personal comment, I think some discussion of the need for a transition
(and motivation for why no backwards compatibility is required) would be
valuable.  It would not, obviously, affect protocol processing, though, so
this is just a comment.


Nits:

1.1

"currnet RFC Editor policies"--> current RFC Editor policies.

2.3
"that is more preferential than the current Master." seems clumsy;
would "that is preferred over the current Master." be better?

5.3.3
I think it would be valuable to make clear here that VRID is
a configured item.  It is mentioned later in section 6.1, but a
forward pointer or repeat of the text might be useful here. (Not
a protocol issue, obviously, just helpful to the new reader)

[Ballot comment]
Interop report seems a bit weak. In particular, I see nothing listed beyond
go/no-go testing. It seems to me that some indication of the actual
options in the protocol that were tested might be in order.

State Changes to In WG                                            from Pre AD Evaluation                                by Bill Fenner

State Changes to Pre AD Evaluation                                from Token@wg or Author                                by Bill Fenner