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

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.

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.

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.

The document speaks of a "Digital Equipment Corporation" protocol.  Digital doesn't exist any more; the text should be reworded.

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)