From ben@niven-jenkins.co.uk Tue Apr 12 14:17:30 2011 Return-Path: X-Original-To: rtg-dir@ietfc.amsl.com Delivered-To: rtg-dir@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E60A9E096B for ; Tue, 12 Apr 2011 14:17:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.058 X-Spam-Level: X-Spam-Status: No, score=-104.058 tagged_above=-999 required=5 tests=[AWL=-0.459, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6yjdAOQvMA6Z for ; Tue, 12 Apr 2011 14:17:30 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.64]) by ietfc.amsl.com (Postfix) with ESMTP id 0250DE07D4 for ; Tue, 12 Apr 2011 14:17:30 -0700 (PDT) Received: from host1.cachelogic.com ([212.44.43.80] helo=dhcp-108-devlan.cachelogic.com) by mail5.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1Q9kxl-00038k-Mc; Tue, 12 Apr 2011 22:17:30 +0100 From: Ben Niven-Jenkins Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 12 Apr 2011 22:17:26 +0100 Message-Id: <4DE543A2-1637-49E5-B5C3-4274FADFD4BA@niven-jenkins.co.uk> To: rtg-ads@tools.ietf.org Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: rtg-dir@ietf.org, draft-palanivelan-bfd-v2-gr.all@tools.ietf.org Subject: [RTG-DIR] RtgDir review: draft-palanivelan-bfd-v2-gr-10.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 21:17:31 -0000 Hello, I have been selected as the Routing Directorate reviewer for this draft. = The Routing Directorate seeks to review all routing or routing-related = drafts as they pass through IETF last call and IESG review. The purpose = of the review is to provide assistance to the Routing ADs. For more = information about the Routing Directorate, please see = http://www.ietf.org/iesg/directorate/routing.html As this is an Independent submission via the ISE these comments are = primarily for the use of the Routing ADs. Document: draft-palanivelan-bfd-v2-gr-10.txt Reviewer: Ben Niven-Jenkins Review Date: 12 April 2011 IETF LC End Date: N/A Intended Status: Historic Summary: I have significant concerns about this document and recommend = that the Routing ADs discuss these issues further with the authors. Comments: In places the text of the document is extremely hard to parse = and I had to read some sections multiple times to try to understand what = was written. Major Issues: Although I note that this is a Independent submission with an Intended = Status of Historic that documents a proposal that was rejected by the = BFD WG and that RFC5742 section 5 states "In general, the IESG has no = problem with rejected alternatives being made available to the = community;" in my opinion the document extends an IETF protocol in a way = that requires further review by the Routing ADs and/or the BFD WG before = being considered for publication, because: 1) The document introduces two new sections/fields into the Generic BFD = Control Packet format specified in RFC5880 section 4.1 without any = discussion or details of: A) Whether such a change would constitute or require a new version of = the BFD protocol, or B) Whether such a change is backwards compatible and/or interoperable = with existing BFD protocol version and implementations.=20 2) The document introduces a new BFD state machine that differs from the = existing state machine specified in RFC5880 in three ways: A) It expects implementations to transition between states based on the = value of the received Diag field whereas the existing BFD state machine = does not rely on the value of the Diag field to initiate state changes. = [Section 6.2 Paragraph 9] B) It removes the ability to transition out of the DOWN state. As = RFC5880 specifies that newly created BFD sessions start in the DOWN = state it would appear that the new state machine proposed in the = document removes the ability for a BFD session between neighbours to = bootstrap itself. [State diagram in Section 5] C) It introduces a new state "NEIGHBORRESTART" which appears (to me) to = be backwards compatible but given (A) and (B) above it would seem = prudent to be cautious and request a review from the BFD WG in order to = be certain. [State diagram in Section 5] 3) The document states in the abstract: This document is a historical record of some work and discussions in the bfd working group on a possible solution to the Graceful Restart issues with BFD. To keep the protocol simple, it was decided not to include this extension in the BFD standard. However from perusing the BFD mailing list archive it would appear IMO = that the above is not an accurate characterisation of the discussion = which appears to me have been reasonably hostile towards the proposal = with more than one participant expressing the view that the proposed = solution does not in fact solve the problem that it purports to.=20 As the document is claiming to record the outcome of discussions in the = BFD WG it would seem appropriate for the BFD WG to formally review the = document to ensure that the document is an accurate record of those = discussions. Minor Issues:=20 1) The document states that it addresses Graceful Restart issues with = BFD but its description of those issues in Section 2 paragraph 2 is not = particularly well explained and the text is extremely hard to parse. Ben From takeda.tomonori@lab.ntt.co.jp Thu Apr 21 22:22:52 2011 Return-Path: X-Original-To: rtg-dir@ietfc.amsl.com Delivered-To: rtg-dir@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 10BE2E07B6 for ; Thu, 21 Apr 2011 22:22:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.09 X-Spam-Level: X-Spam-Status: No, score=-100.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dpk5zqbTGj6o for ; Thu, 21 Apr 2011 22:22:51 -0700 (PDT) Received: from tama500.ecl.ntt.co.jp (tama500.ecl.ntt.co.jp [129.60.39.148]) by ietfc.amsl.com (Postfix) with ESMTP id A1E6AE07CA for ; Thu, 21 Apr 2011 22:22:50 -0700 (PDT) Received: from mfs6.rdh.ecl.ntt.co.jp (mfs6.rdh.ecl.ntt.co.jp [129.60.39.149]) by tama500.ecl.ntt.co.jp (8.14.4/8.14.4) with ESMTP id p3M5MjY2016742; Fri, 22 Apr 2011 14:22:45 +0900 (JST) Received: from mfs6.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs6.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id D81D065F1; Fri, 22 Apr 2011 14:22:44 +0900 (JST) Received: from imail2.m.ecl.ntt.co.jp (imail2.m.ecl.ntt.co.jp [129.60.5.247]) by mfs6.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id CFF3965EB; Fri, 22 Apr 2011 14:22:44 +0900 (JST) Received: from [127.0.0.1] ([129.60.80.55]) by imail2.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id p3M5MXEx023388; Fri, 22 Apr 2011 14:22:44 +0900 Message-ID: <4DB11061.4070809@lab.ntt.co.jp> Date: Fri, 22 Apr 2011 14:21:37 +0900 From: Tomonori TAKEDA User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: rtg-ads@tools.ietf.org Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: rtg-dir@ietf.org, draft-ietf-idr-bgp-identifier@tools.ietf.org Subject: [RTG-DIR] RtgDir review: draft-ietf-idr-bgp-identifier-13.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 05:22:52 -0000 Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://www.ietf.org/iesg/directorate/routing.html Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-idr-bgp-identifier-13.txt Reviewer: Tomonori Takeda Review Date: 22 April 2011 IETF LC End Date: 18 April 2011 Intended Status: Standards Track Summary: I have some minor concerns about this document that I think should be resolved before publication. Comments: This document is short, clearly written and easy to understand. I have one minor comment that should be clarified. o Major Issues: No major issues found. o Minor Issues: Section 3: It says, In addition to the OPEN message, the BGP Identifier is currently also used in the following areas: ... o In the Route Reflection (in lieu of the Cluster-id) within an AS, where only the BGP Identifier of an internal neighbor may be propagated in the route reflection related attributes. I am a bit confused about "in lieu of the Cluster-id". My reading of this text is that the BGP Identifier is used in CLUSTER_ID attribute in the Route Reflection, which is not usually correct. I guess text should be (by removing "in lieu of the Cluster-id") : In addition to the OPEN message, the BGP Identifier is currently also used in the following areas: ... o In the Route Reflection within an AS, where only the BGP Identifier of an internal neighbor may be propagated in the route reflection related attributes. or something like this. o Nits: None. Thanks, Tomonori From adrian@olddog.co.uk Wed Apr 27 15:15:41 2011 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98DBFE0785 for ; Wed, 27 Apr 2011 15:15:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.854 X-Spam-Level: X-Spam-Status: No, score=-1.854 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D4-kHkQ9b457 for ; Wed, 27 Apr 2011 15:15:37 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) by ietfa.amsl.com (Postfix) with ESMTP id 64E3FE062B for ; Wed, 27 Apr 2011 15:15:37 -0700 (PDT) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id p3RMFZ64030636 for ; Wed, 27 Apr 2011 23:15:35 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id p3RMFX3X030614 for ; Wed, 27 Apr 2011 23:15:35 +0100 From: "Adrian Farrel" To: Date: Wed, 27 Apr 2011 23:15:33 +0100 Message-ID: <064101cc0528$a1418c40$e3c4a4c0$@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: AcwFKJ8Ko83AXirGSw2Qi203j3zC7A== Content-Language: en-gb Subject: [RTG-DIR] Looking for a VRRP reviewer X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 22:15:41 -0000 Anyone familiar with VRRP or willing to bootstrap? Hint: the review is of a MIB module :-( Thanks, Adrian From acee.lindem@ericsson.com Wed Apr 27 15:26:42 2011 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52535E0752 for ; Wed, 27 Apr 2011 15:26:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rFJ41wmkDSvp for ; Wed, 27 Apr 2011 15:26:41 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfa.amsl.com (Postfix) with ESMTP id C74E9E0713 for ; Wed, 27 Apr 2011 15:26:41 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p3RMQagZ006511; Wed, 27 Apr 2011 17:26:41 -0500 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.54]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Wed, 27 Apr 2011 18:26:37 -0400 From: Acee Lindem To: "adrian@olddog.co.uk" Date: Wed, 27 Apr 2011 18:26:34 -0400 Thread-Topic: [RTG-DIR] Looking for a VRRP reviewer Thread-Index: AcwFKivWDGVdla2bTN2KaGu8AKP7Kw== Message-ID: References: <064101cc0528$a1418c40$e3c4a4c0$@olddog.co.uk> In-Reply-To: <064101cc0528$a1418c40$e3c4a4c0$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; boundary="Apple-Mail-10--781519545"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "rtg-dir@ietf.org" Subject: Re: [RTG-DIR] Looking for a VRRP reviewer X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 22:26:42 -0000 --Apple-Mail-10--781519545 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I've implemented VRRPv2 more than once I guess I can review the VRRPv3 = MIB. What is the due date?=20 Acee=20 On Apr 27, 2011, at 6:15 PM, Adrian Farrel wrote: > Anyone familiar with VRRP or willing to bootstrap? >=20 > Hint: the review is of a MIB module :-( >=20 > Thanks, > Adrian >=20 --Apple-Mail-10--781519545 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIM8jCCBDQw ggMcoAMCAQICECFWwVQHDV12M/Sr0yNv0sYwDQYJKoZIhvcNAQEFBQAwOTERMA8GA1UECgwIRXJp Y3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMTAeFw0xMDEwMDEyMDA0 NTlaFw0xMzEwMDEyMDA0NDhaMG8xETAPBgNVBAoMCEVyaWNzc29uMR8wHQYDVQQDDBZBY2VlIExp bmRlbSBMaW5kZW0gSUlJMRAwDgYDVQQFEwdlYWxmbGluMScwJQYJKoZIhvcNAQkBFhhhY2VlLmxp bmRlbUBlcmljc3Nvbi5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAI/Dc9ALiZuBMyuv bsc3eBxjXZpMi45Z0vzsUQZTJGTBeY7p9JsdzXC9J1uMisBxYVi39R3KJo6I4hXVp9wrA1rxh4AE bnP1+Gxfpj33uWEFYbBnVAJkIWYWF7CYTn8Zm/yd13vPXtuGA6ESeLnnJafwC9Y0YwUQ+4HX7PNv uauVAgMBAAGjggGEMIIBgDCBwAYDVR0fBIG4MIG1MIGyoIGvoIGshjdodHRwOi8vY3JsLnRydXN0 LnRlbGlhLmNvbS9Fcmljc3Nvbk5MSW5kaXZpZHVhbENBMDEuY3JshnFsZGFwOi8vbGRhcC50cnVz dC50ZWxpYS5jb20vY249RXJpY3Nzb24lMjBOTCUyMEluZGl2aWR1YWwlMjBDQTAxLG89RXJpY3Nz b24/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFzZTAjBgNVHREEHDAagRhhY2Vl LmxpbmRlbUBlcmljc3Nvbi5jb20wRgYDVR0gBD8wPTA7BgYqhXBrAQEwMTAvBggrBgEFBQcCARYj aHR0cDovL3d3dy5lcmljc3Nvbi5jb20vbGVnYWwuc2h0bWwwHQYDVR0OBBYEFAgOzAPuplmPr7C1 BTqV94OyqUdhMB8GA1UdIwQYMBaAFJYnw7jepV9dRD45UuVFsXZfYzCbMA4GA1UdDwEB/wQEAwIF oDANBgkqhkiG9w0BAQUFAAOCAQEAE1gyNW6c2t/YsLxW5sm67+gVGK0Lnge4ub+k8dgGrK7Mj7em nkOIFkjdv/tqdJ/SoUy/WEkBXba2TfpZ+lfluMgLYux1vSvqBUxYBsUHeNth2Q/Y6A9sCaDTBPlK vZ2jLz814NavrVfgTCLdxX6zNtGdwzhviz+FyqyxYF43Q86RP8Gd/Npaz1W8pmYAHm0+lezuTx5k F3Av3+SaZ/MR6s+RWuXEIdED36ajeQz+OG8Mh3nplofzdrOeoWGDz53YlfRhgj+TXo+H1lclZAvD WVaMMXPdb27h9Hngsq87dkCW9uAyv8DI993rdhqzlEgUyQIL32icAXfTmTYgoGPOwjCCBEUwggMt oAMCAQICEBPJ6v/eJq2p3KTKI4GDR+MwDQYJKoZIhvcNAQEFBQAwRDEaMBgGA1UECgwRVGVsaWFT b25lcmEgR3JvdXAxJjAkBgNVBAMMHVRlbGlhU29uZXJhIFB1YmxpYyBSb290IENBIHYxMB4XDTA2 MTAwNjEwMDA1M1oXDTE2MTAwMjA1MDQxN1owOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNVBAMM G0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALYQd+Q1HuuHxDyNGFlEPzCxuPPFO5W2xyr+nqCVnNJ4QYFe1HACqavqNLwUGIqIEyHv1rLn fub9LBc7dQpRHjl/dggin0ONOFJ36nbGEbfHjLJz2BzOWvwl84Sc+Fx09IrDU/SZSWFSfhqTu3TT 39h79brHdRkdPBUgBYgsiFKriHI0TjP5G8628H27BDzqUpzGLSYWgt6/tpwuOH5lcfNfHWMcCYXR lobv0Klu8lxG5amWqAnqrH6ECOyYJTRbHTsaTIZOHy9Qw/0eXPujKT7tU5xxSI2SdceJqzUbAz2o FRQ6Px7/GydpM/Rl+qYoGPcauHUL1aSeVJZqDFqcIF0CAwEAAaOCATwwggE4MBIGA1UdEwEB/wQI MAYBAf8CAQAwRgYDVR0gBD8wPTA7BgcqhXAjAgEBMDAwLgYIKwYBBQUHAgEWImh0dHBzOi8vcmVw b3NpdG9yeS50cnVzdC50ZWxpYS5jb20wgYkGA1UdHwSBgTB/MH2ge6B5hndsZGFwOi8vbGRhcC50 cnVzdC50ZWxpYS5jb20vY249VGVsaWFTb25lcmElMjBQdWJsaWMlMjBSb290JTIwQ0ElMjB2MSxv PVRlbGlhU29uZXJhJTIwR3JvdXA/YXV0aG9yaXR5cmV2b2NhdGlvbmxpc3Q/YmFzZTAOBgNVHQ8B Af8EBAMCAQYwHQYDVR0OBBYEFJYnw7jepV9dRD45UuVFsXZfYzCbMB8GA1UdIwQYMBaAFEXb8I+4 GmKhqCMbY4g4o9vgGmLxMA0GCSqGSIb3DQEBBQUAA4IBAQB2AEoqQz+M3Ra9alkpn/YnwhXIv6tP jhUvSuNs00Nhd0T9XhlIU3a65CaB/UKSqnayE0t7Q0Qq3r+x/GK3in/mik8i/PK2/q8HutzYFSzz 6Npztpo2JG7AEKOJPVaeebjng45m6vNC7RIfzU9sG2LBR/hewS8s6dFFn70w795xUwJBWZ67OzIK XrIVVvHTOYpbWA+MESKAXwFhnVONrOTWlVwrMUi4HbiPWpOk+xQbgehCEi7mu3cXsaU1Xq3kMXui NuC7VKoob8mFO9o9RT+dlirD2uRXwNpvCu3but6Kyhu0+nvy2iXGKjdlxlWTsdDyulXYz+OYCMZ9 lFWRzMIPMIIEbTCCA1WgAwIBAgIRAJywjASay5cieGNithuGWj0wDQYJKoZIhvcNAQEFBQAwOjEZ MBcGA1UEChMQUlNBIFNlY3VyaXR5IEluYzEdMBsGA1UECxMUUlNBIFNlY3VyaXR5IDIwNDggVjMw HhcNMDYxMDMxMjA0MjI3WhcNMTYxMTAxMTU0MjI1WjBEMRowGAYDVQQKDBFUZWxpYVNvbmVyYSBH cm91cDEmMCQGA1UEAwwdVGVsaWFTb25lcmEgUHVibGljIFJvb3QgQ0EgdjEwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDKTxADapCAq3mplX4R4gNt+WZe5QKGnaVEQSyY7lICKF5DuVdW PMLHDjzhw5IzDd860ZZx/0VrhGB3DmP4SDIWCKo2PxvY5NckdBWPWp/T2uaQdOAwgqHpN0pe1X7/ jel59WsWYXKGg/81Wth73ZK/geE7Gz9Pvj1LU6N4YhLMgooxKnCS+ZjB5icWAg+Qd1QpQhF46H1i bp6LsBWDp56MPpg8F5X6y7MGVcKYLdnLOPs84uxRW9qs1kBopzQBj6s5SyVh8A+j5liDBjghXYpw /+paGEdqHPeSFYxZKeJatmjEKLYlxcZWRKf436KvQA9jBhMEmytMNbGicR1mRH6tAgMBAAGjggFi MIIBXjAfBgNVHSMEGDAWgBQHw1EwpKrpRa41JPr/JCwz0LGdjDAdBgNVHQ4EFgQURdvwj7gaYqGo IxtjiDij2+AaYvEwEgYDVR0TAQH/BAgwBgEB/wIBBDCBhQYDVR0gBH4wfDA9BgkqhkiG9w0FBgEw MDAuBggrBgEFBQcCARYiaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhLmNvbTA7BgcqhXAj AgEBMDAwLgYIKwYBBQUHAgEWImh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYS5jb20wcAYD VR0fBGkwZzBloGOgYYZfaHR0cDovL3d3dy5yc2FzZWN1cml0eS5jb20vcHJvZHVjdHMva2Vvbi9y ZXBvc2l0b3J5L2NlcnRpZmljYXRlX3N0YXR1cy9SU0FfU2VjdXJpdHlfMjA0OF92My5DUkwwDgYD VR0PAQH/BAQDAgEGMA0GCSqGSIb3DQEBBQUAA4IBAQAEXpos2CnIm7/872ytSrEHWZgvhOUEkUm2 5PWf/XkWko41TaL9vIS1S6AdWChNqWmnYiS7GfaIiDM9s1D6K7hidWBDOm46bNdM3ZwhMyDCfkDJ SgeJ0w+7YmjvChu7gWqDZCsbtZ5gA1ixCTdDnuZB67JGSPGW6r73coraDP8diOpiQouMvM6bKuTP BH/1poLccsUxsKgrQ23JC9LWCRb8cYHkZjXFH1K44TsIl5Lne2oT0JI3pwdA2v6jO4p/OLHntP+n pjwPbedMPUZkDYCkd3LSxj8c3JTxtA8SlPCtIHE1hh65xihg1JRIliSphrqr9kbfwHdeVxPdOI5G tDYPMYICEjCCAg4CAQEwTTA5MREwDwYDVQQKDAhFcmljc3NvbjEkMCIGA1UEAwwbRXJpY3Nzb24g TkwgSW5kaXZpZHVhbCBDQTAxAhAhVsFUBw1ddjP0q9Mjb9LGMAkGBSsOAwIaBQCgggEbMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDQyNzIyMjYzNVowIwYJKoZI hvcNAQkEMRYEFIyN1y/E+/Pyc7APfwFRG0Nr+dtmMFwGCSsGAQQBgjcQBDFPME0wOTERMA8GA1UE CgwIRXJpY3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcN XXYz9KvTI2/SxjBeBgsqhkiG9w0BCRACCzFPoE0wOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNV BAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcNXXYz9KvTI2/SxjANBgkqhkiG 9w0BAQEFAASBgDbWG4pbnwoxdcu8oj1tnvMVUTFuX9V3w3XLpPAkfpuRkylk7zD09Ae23BbZz11A CGvnWz0LgSYrmeNWif/nGw82p5pJhZcP+zPW+kfoumgBTHSaAv7/GkmR1QYzkn5xMymgXFFDiX1/ 5mLw8vA4CdDjzUWqsIe23XwgIwcRPCeTAAAAAAAA --Apple-Mail-10--781519545-- From jmh@joelhalpern.com Wed Apr 27 15:27:15 2011 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3AC5E0776 for ; Wed, 27 Apr 2011 15:27:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.764 X-Spam-Level: X-Spam-Status: No, score=-102.764 tagged_above=-999 required=5 tests=[AWL=-0.165, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zp8vw84QGbn7 for ; Wed, 27 Apr 2011 15:27:15 -0700 (PDT) Received: from hermes.out.tigertech.net (hermes.out.tigertech.net [74.114.88.72]) by ietfa.amsl.com (Postfix) with ESMTP id 7C4BEE0713 for ; Wed, 27 Apr 2011 15:27:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 3C3BA4300E4; Wed, 27 Apr 2011 15:27:15 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.101] (pool-71-161-51-218.clppva.btas.verizon.net [71.161.51.218]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTPSA id B3AEE4300AC; Wed, 27 Apr 2011 15:27:14 -0700 (PDT) Message-ID: <4DB89842.90308@joelhalpern.com> Date: Wed, 27 Apr 2011 18:27:14 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: adrian@olddog.co.uk References: <064101cc0528$a1418c40$e3c4a4c0$@olddog.co.uk> In-Reply-To: <064101cc0528$a1418c40$e3c4a4c0$@olddog.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rtg-dir@ietf.org Subject: Re: [RTG-DIR] Looking for a VRRP reviewer X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 22:27:16 -0000 Well, once upon a time I was very familiar with it. I'll take it. Joel On 4/27/2011 6:15 PM, Adrian Farrel wrote: > Anyone familiar with VRRP or willing to bootstrap? > > Hint: the review is of a MIB module :-( > > Thanks, > Adrian > > From adrian@olddog.co.uk Wed Apr 27 15:35:13 2011 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CFCCE0785 for ; Wed, 27 Apr 2011 15:35:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.525 X-Spam-Level: X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GSD4tKAxKQhD for ; Wed, 27 Apr 2011 15:35:12 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) by ietfa.amsl.com (Postfix) with ESMTP id 77B5FE0713 for ; Wed, 27 Apr 2011 15:35:12 -0700 (PDT) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id p3RMZBCn002589 for ; Wed, 27 Apr 2011 23:35:11 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id p3RMZAdu002583 for ; Wed, 27 Apr 2011 23:35:11 +0100 From: "Adrian Farrel" To: References: <064101cc0528$a1418c40$e3c4a4c0$@olddog.co.uk> <4DB89842.90308@joelhalpern.com> In-Reply-To: <4DB89842.90308@joelhalpern.com> Date: Wed, 27 Apr 2011 23:35:03 +0100 Message-ID: <065601cc052b$5e34c130$1a9e4390$@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: AQKCTDsMlRdnFcdx0SThIaqupeplbQJWl1n9kvMJGfA= Content-Language: en-gb Subject: Re: [RTG-DIR] Looking for a VRRP reviewer X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 22:35:13 -0000 yea gods, they are fighting to do a review! I'll hand this over to Deborah and she can decide who wants to do it most :-) A > -----Original Message----- > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > Sent: 27 April 2011 23:27 > To: adrian@olddog.co.uk > Cc: rtg-dir@ietf.org > Subject: Re: [RTG-DIR] Looking for a VRRP reviewer > > Well, once upon a time I was very familiar with it. > I'll take it. > Joel > > On 4/27/2011 6:15 PM, Adrian Farrel wrote: > > Anyone familiar with VRRP or willing to bootstrap? > > > > Hint: the review is of a MIB module :-( > > > > Thanks, > > Adrian > > > > From stig@venaas.com Wed Apr 27 21:10:12 2011 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 768E5E0680 for ; Wed, 27 Apr 2011 21:10:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.374 X-Spam-Level: X-Spam-Status: No, score=-101.374 tagged_above=-999 required=5 tests=[AWL=1.225, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pz0-InewrfPW for ; Wed, 27 Apr 2011 21:10:00 -0700 (PDT) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by ietfa.amsl.com (Postfix) with ESMTP id 37451E0715 for ; Wed, 27 Apr 2011 21:10:00 -0700 (PDT) Received: from [10.21.74.52] (128-107-239-233.cisco.com [128.107.239.233]) by ufisa.uninett.no (Postfix) with ESMTPSA id D26857FD6; Thu, 28 Apr 2011 06:09:53 +0200 (CEST) Message-ID: <4DB8E889.7070509@venaas.com> Date: Wed, 27 Apr 2011 21:09:45 -0700 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: rtg-ads@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ietf-grow-unique-origin-as@tools.ietf.org, rtg-dir@ietf.org, grow-chairs@tools.ietf.org Subject: [RTG-DIR] RtgDir review: draft-ietf-grow-unique-origin-as-00 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 04:10:12 -0000 Hi, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://www.ietf.org/iesg/directorate/routing.html Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-grow-unique-origin-as-00 Reviewer: Stig Venaas Review Date: April 27, 2011 IETF LC End Date: Unknown Intended Status: Best Current Practice Summary: The document is well written, and I only have two very minor issues. Minor issues: 1: Regarding traceroute it says: enables service-level identification of a given server. Tools such as traceroute are also used to determine which location a given query is being routed to, although it may not reveal local-scope anycast instances, or if there are multiple servers within a given anycast node, which of the servers responded to a given query, in particular when multiple servers within an anycast node are connected to a single IP router. When utilizing these service level capabilities, Why is local-scope emphasized here? I would think that traceroute always gives you one node. It may be a particular global node, or a local node, depending on your location. It may not reveal local-scope, but it may not reveal global-scope either. They key thing is that you get only one. And you may not know what the scope is either. Am I missing something, or should the text be changed? 2: Regarding synchronization of instances it says: Additionally, while it goes without saying that anycasted services should always strive for exact synchronization across all instances of an anycasted service address, if local policies or data plane response manipulation techniques were to "influence" responses within a given region in such a way that those response are no longer authentic or that they diverge from what other nodes within an anycasted service were providing, then it should be an absolute necessity that those modified resources only be utilized by service consumers within that region or influencer's jurisdiction. Isn't this a bit DNS centric? I can think of anycast services where different nodes intentionally have different content. I'm not sure if it necessarily is important to restrict it to region or jurisdiction either. It all depends on the service. Maybe rephrase this to point out that this may be an important issue, depending on the service? Nit: In the paragraph above I found this line: a given region in such a way that those response are no longer ^^^^^^^^ s/response/responses That's all I have, Stig From db3546@att.com Thu Apr 28 06:34:29 2011 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 233B3E06EA for ; Thu, 28 Apr 2011 06:34:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K2ukxujCRNKA for ; Thu, 28 Apr 2011 06:34:28 -0700 (PDT) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by ietfa.amsl.com (Postfix) with ESMTP id 81C12E0669 for ; Thu, 28 Apr 2011 06:34:28 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: db3546@att.com X-Msg-Ref: server-11.tower-120.messagelabs.com!1303997667!14985379!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 13963 invoked from network); 28 Apr 2011 13:34:27 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-11.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 28 Apr 2011 13:34:27 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p3SDXPS7010223 for ; Thu, 28 Apr 2011 09:33:25 -0400 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p3SDXKIj010155 for ; Thu, 28 Apr 2011 09:33:21 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 28 Apr 2011 09:34:21 -0400 Message-ID: In-Reply-To: <4DB89842.90308@joelhalpern.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RTG-DIR] Looking for a VRRP reviewer Thread-Index: AcwFKklMYL9OZH19Qnu/VZC5HapTPAAfooxQ References: <064101cc0528$a1418c40$e3c4a4c0$@olddog.co.uk> <4DB89842.90308@joelhalpern.com> From: "BRUNGARD, DEBORAH A (ATTSI)" To: "Joel M. Halpern" , Cc: rtg-dir@ietf.org Subject: Re: [RTG-DIR] Looking for a VRRP reviewer X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 13:34:29 -0000 Much thanks Acee and Joel - as Acee was "I guess I can" and Joel was "I'll take it", we'll assign to Joel:-) -----Original Message----- From: rtg-dir-bounces@ietf.org [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Joel M. Halpern Sent: Wednesday, April 27, 2011 6:27 PM To: adrian@olddog.co.uk Cc: rtg-dir@ietf.org Subject: Re: [RTG-DIR] Looking for a VRRP reviewer Well, once upon a time I was very familiar with it. I'll take it. Joel On 4/27/2011 6:15 PM, Adrian Farrel wrote: > Anyone familiar with VRRP or willing to bootstrap? > > Hint: the review is of a MIB module :-( > > Thanks, > Adrian > > From jmh@joelhalpern.com Thu Apr 28 08:37:24 2011 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8473E071E for ; Thu, 28 Apr 2011 08:37:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.692 X-Spam-Level: X-Spam-Status: No, score=-102.692 tagged_above=-999 required=5 tests=[AWL=-0.093, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3R448PeVjmiL for ; Thu, 28 Apr 2011 08:37:24 -0700 (PDT) Received: from hermes.out.tigertech.net (hermes.out.tigertech.net [74.114.88.72]) by ietfa.amsl.com (Postfix) with ESMTP id 03365E070C for ; Thu, 28 Apr 2011 08:37:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id EC7574300BD; Thu, 28 Apr 2011 08:37:23 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.101] (pool-71-161-52-76.clppva.btas.verizon.net [71.161.52.76]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTPSA id 0EF36430052; Thu, 28 Apr 2011 08:37:22 -0700 (PDT) Message-ID: <4DB989B2.4050006@joelhalpern.com> Date: Thu, 28 Apr 2011 11:37:22 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: rtg-ads@tools.ietf.org, "rtg-dir@ietf.org" , draft-ietf-vrrp-unified-mib.all@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [RTG-DIR] RtgDir review: draft-ietf-vrrp-unified-mib-09.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 15:37:24 -0000 Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://www.ietf.org/iesg/directorate/routing.html Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-vrrp-unified-mib-09.txt Reviewer: Joel Halpern Review Date: 28-April-2011 IETF LC End Date: 2011-05-11 Intended Status: Proposed Standard Summary: I have significant concerns about this document and recommend that the Routing ADs discuss these issues further with the authors. Note: The document is very readable, and quite clear on its architecture. I appreciate that. Major issue: There seems to be an architectural disconnect between this MIB and RFC 5798. WHile I can understand the design in the MIB, and would not have any concern if that were the design in 5798, they appear not to match. Specifically, Section 6.1 of RFC 5798 says that a given Virtual Router has a Virtual Router ID (VRID) and a priority. That virtual router then has a list of Ipv4 addresses it is associated and a list of IPv6 addresses addresses it is associated with. There is a single priority for the entire virtual router. (As documented, conceptually, all VRs serve all address types, even if some of them may be configured with only IPv4 addresses or only IPv6 addresses.) In contrast, the MIB document goes to great trouble to diagram the virtual router as being dedicated to a single address family. In the MIB, conceptually, they are two routers for a given VRID. This is shown in the diagrams by having two different priorities for these two different routers, and different states (master vs backup) for the two virtual routers in the same box, even though they are using the same VRID. This is reflected in the base keying structure of the MIB. For all I know, this is the actual practice in deploying the protocol. But it is NOT what the RFC says. (And no, this can not be fixed as an errata to RFC 5798.) Minor issues: (These assume the structure as given in the MIB. If I am correct about the major issue needing to be addressesd, many of these will become OBE.) In the example in section 8, in the vrrpv3AssociatedIpAddrTable for VR1, it shows address Z as being active on rotuer VR1. However, the diagram shows address Z as only active on VR2. (And the table for VR2 shows Z as active there.) I presume this is a cut-and-paste error, and the line for Z in VR1 just needs to be removed. I presume that there is a good reason why vrrpv3RouterChecksumErrors, vrrpv3RouterVersionErrors, vrrpv3RouterVrIdErrors, and vrrpv3GlobalStatisticsDiscontinuityTime do not exist per interface? (I can understand why they are not per VRID, since with these errors, one could not associate them with a specific VRID. But they can be associated with a specific Interface.) Also, whether they remain associated with the physical router, or become a per-interface table, it would seem that they should be described in section 7 on the structure of the MIB. This description should also explain the scoping. Nit: Should the description of vrrpv3OperationsAcceptMode include a REFERENCE " RFC 5798 section 6.1" It seems odd to have one table Augment another in the same MIB document. Is this just for human readability? Yours, Joel M. Halpern line?