Re: [Gen-art] Gen-ART Telechat review of draft-ietf-vrrp-unified-mib-10

"Adrian Farrel" <adrian@olddog.co.uk> Mon, 03 October 2011 18:06 UTC

Return-Path: <adrian@olddog.co.uk>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96F7021F8CF6; Mon, 3 Oct 2011 11:06:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.488
X-Spam-Level:
X-Spam-Status: No, score=-2.488 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tgTBWgc1x7kq; Mon, 3 Oct 2011 11:06:48 -0700 (PDT)
Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id D914621F8CF0; Mon, 3 Oct 2011 11:06:47 -0700 (PDT)
Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id p93I9neU029895; Mon, 3 Oct 2011 19:09:49 +0100
Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id p93I9lAu029883 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 3 Oct 2011 19:09:48 +0100
From: Adrian Farrel <adrian@olddog.co.uk>
To: 'Ben Campbell' <ben@nostrum.com>, draft-ietf-vrrp-unified-mib.all@tools.ietf.org
References: <F652EB69-A187-43AA-82B9-34E263B87B77@nostrum.com>
In-Reply-To: <F652EB69-A187-43AA-82B9-34E263B87B77@nostrum.com>
Date: Mon, 03 Oct 2011 19:09:46 +0100
Message-ID: <01fd01cc81f7$a3734ed0$ea59ec70$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQI7959g4AkBDhhWQyvBQpOeO0MwepSL/dig
Content-Language: en-gb
Cc: gen-art@ietf.org, 'The IETF' <ietf@ietf.org>, tata_kalyan@yahoo.com
Subject: Re: [Gen-art] Gen-ART Telechat review of draft-ietf-vrrp-unified-mib-10
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: adrian@olddog.co.uk
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/gen-art>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 03 Oct 2011 18:06:48 -0000

Hi Ben,

Thanks for the review.

> Minor issues:
> 
> -- Section 7,  first paragraph: "During the review of this document, It
emerged
> that there are different possible interpretations of [RFC5798]. The Authors of
> that document and the VRRP working group were unable to reach consensus on
> which interpretation is correct."
> 
> That's rather unfortunate, since that RFC specifies the protocol this MIB is
_for_. I
> wish we could do better. From my limited knowledge here, I am agnostic as to
> whether the disagreement would make a substantive difference in the MIB. I put
> this in the "minor" section in hopes that it does not--but people more versed
in
> the protocol should think about this.

Yes, this is really unfortunate.

The WG (now closed) was unable to reach any firm conclusion. The authors of the
original spec were a bit vague and indecisive. 

We were left with no option other than for the authors of this document to:
- pick the interpretation they thought was most likely
- document the fact
- move on

My feeling is that the lack of decisiveness in the WG for an established
protocol (not widely deployed, but reasonably well implemented and deployed)
showed that this was not an important function in the protocol. In practice, it
did not matter which choice was made in the MIB module because no-one seemed to
care which choice was made in the protocol.

Thus, if VRRP was being advance on the protocol ladder, I would look for the
feature to be removed rather than for the issue to be resolved.

Cheers,
Adrian