Re: AD review of draft-ietf-vrrp-unified-mib
Rio Asnara <[email protected]> Sat, 15 Jan 2011 00:18:15 +0700
| Newsgroups | gmane.ietf.vrrp |
|---|---|
| Message-ID | <[email protected]> |
--===============1275124908== Content-Type: multipart/alternative; boundary=0016363b845ca921fa0499d19e6e --0016363b845ca921fa0499d19e6e Content-Type: text/plain; charset=ISO-8859-1 Please forgive my late to respond. This weekend I had a conference with friends from china to discuss about the SMSC, iVAS, CRBT as well as cellular network intelligence yes, I had planned to immediately implement as soon as possible :) Regards, Asnara On Fri, Jan 14, 2011 at 3:20 AM, Mukesh Gupta <[email protected]> wrote: > Asnara, > > > > Thanks for your interest. Do you have any timeline in mind? > > > > As you might know, IETF believes in rough consensus and running code. So, > having a few implementations of the draft would make all of us comfortable > with the quality of the draft. > > > > Regards > > Mukesh > > > > *From:* Rio Asnara [mailto:[email protected]] > *Sent:* Tuesday, January 11, 2011 12:12 AM > *To:* Mukesh Gupta > *Cc:* Kalyan (Srinivas)Tata; [email protected]; > [email protected]; [email protected]; > [email protected] > *Subject:* Re: [VRRP] AD review of draft-ietf-vrrp-unified-mib > > > > All, > I'm interested to implemented on my virtual system :) > > Regards, > Asnara > > > On Tue, Jan 11, 2011 at 5:56 AM, Mukesh Gupta <[email protected]> wrote: > > Kalyan, > > Thanks a lot. Please go ahead and address the comments and publish > the next rev. We all want this draft done asap :) > > - Mukesh > > Sent from my iPhone > > On Jan 10, 2011, at 2:12 PM, "Kalyan (Srinivas)Tata" <[email protected] > > > wrote: > > > Thanks Adrian for the review. I will update the draft (Once WG > > chairs confirm). I will getback if I need any clarifications. > > > > Thanks > > Kalyan > > > > -----Original Message----- > > From: [email protected] [mailto:[email protected]] On Behalf > > Of Adrian Farrel > > Sent: Saturday, January 08, 2011 11:37 AM > > To: [email protected] > > Cc: [email protected]; [email protected] > > Subject: [VRRP] AD review of draft-ietf-vrrp-unified-mib > > > > Hi, > > > > Don't panic! > > > > I have performed my AD review of your draft. The purpose of the > > review is to catch any nits or issues before the document goes > > forward to IETF last call and IESG review. By getting these issues > > out at this stage we can hope for a higher quality review and a > > smoother passage through the process. > > > > There are a good number of small issues that I believe can be fixed > > really easily. > > > > I appreciate that a number of these issues are inherited from RFC > > 2787, but this is an ideal chance to clean up. > > > > You will need a new revision to address these points, and I'd ask > > the WG chairs to evaluate whether the changes are large enough to > > warrant a further WG last call. > > > > I have moved the draft into "AD-review:Revised-ID-needed" state in > > the datatracker, and I look forward to seeing the new revision which > > I can put forward for IETF last call. > > > > Thanks for all your work with this draft, > > > > Adrian > > > > --- > > > > Document header > > > > OLD > > Document: draft-ietf-vrrp-unified-mib-08.txt July 2010 > > Intended Status: Proposed Standard > > NEW > > Document: draft-ietf-vrrp-unified-mib-08.txt July 2010 > > Obsoletes: 2787 (if approved) > > Intended Status: Proposed Standard > > END > > > > --- > > > > Abstract > > > > OLD > > This specification defines a Management Information Base (MIB) for > > NEW > > This specification defines a portion of the Management Information > > Base (MIB) for > > END > > > > --- > > > > Section 2 > > > > OLD > > This specification defines a Management Information Base (MIB) for > > NEW > > This specification defines a portion of the Management Information > > Base (MIB) for > > END > > > > --- > > > > Section 2 etc. > > > > Is it necessary to introduce the term "IPvX"? It is only used a > > couple of times, and the time it is used in the MIB module is a > > problem because the definition of the term is outside the module. > > (Typically, MIB modules are extracted from RFCs and have to survive > > as standalone > > text.) > > > > Can you: > > - remove "(IPvX)" form section 2 > > - remove the definition for section 3 > > - say "IPv4 and IPv6" in the two uses in section 6 and section 9 > > > > --- > > > > Section 4 > > > > You need to add text to describe what has changed from 2787. Not a > > lot of details - perhaps a series of bullet points. > > > > -- > > > > Section 6 etc. > > > > You need to say "MIB module" not "MIB" because there is only one > > MIB, and you are making just a module in the MIB. > > > > s/This MIB is designed/This MIB module is designed/ > > > > > > --- > > > > > > Section 7 > > > > Tables in the MIB include the following: > > > > In fact, there are exactly these three tables, so how about... > > > > This MIB module contains three tables: > > > > --- > > > > Section 8 > > > > Trivial, but... > > > > ----- MIB Tables For VRRP Router "VR 1": ----- > > > > ...should read "VR1" > > Similarly for VR2 later in the section. > > > > --- > > > > IMPORTS > > > > It is helpful, but mandatory, to show the RFC numbers from which > > things are imported. Thus... > > > > OLD > > IMPORTS > > MODULE-IDENTITY, OBJECT-TYPE, > > NOTIFICATION-TYPE, Counter32, > > Integer32, mib-2, Unsigned32 FROM SNMPv2-SMI > > > > TEXTUAL-CONVENTION, RowStatus, > > MacAddress, TruthValue, TimeStamp, > > TimeInterval FROM SNMPv2-TC > > > > MODULE-COMPLIANCE, OBJECT-GROUP, > > NOTIFICATION-GROUP FROM SNMPv2-CONF > > ifIndex FROM IF-MIB > > InetAddressType, InetAddress FROM INET-ADDRESS-MIB; > > NEW > > IMPORTS > > MODULE-IDENTITY, OBJECT-TYPE, > > NOTIFICATION-TYPE, Counter32, > > > > Integer32, mib-2, Unsigned32 > > FROM SNMPv2-SMI -- RFC2578 > > > > TEXTUAL-CONVENTION, RowStatus, > > MacAddress, TruthValue, TimeStamp, > > TimeInterval > > FROM SNMPv2-TC -- RFC2579 > > > > MODULE-COMPLIANCE, OBJECT-GROUP, > > NOTIFICATION-GROUP > > FROM SNMPv2-CONF -- RFC2580 > > > > ifIndex > > FROM IF-MIB -- RFC2863 > > > > > > InetAddressType, InetAddress > > FROM INET-ADDRESS-MIB; -- RFC3291 > > END > > > > --- > > > > Section 9 > > > > In order to ensure that references can be provided, it is customary > > to begin Section 9 (i.e. before the module BEGIN statement) with > > some text such as: > > > > This MIB module makes reference to the following documents > > [RFC2578], > > [RFC2579], [RFC2580], [RFC2863], [RFC3291], and [RFC4001]. > > > > --- > > > > Vrrpv3VrIdTC > > > > Typos > > (ifIndex)and IP version, serves to uniquely identify a > > Missing space. > > > > REFERENCE " RFC 5798 (Sections 3 and 5.2.3" > > Missing close brace. > > > > --- > > > > vrrpv3OperationsTable > > > > "Unified Operations table for a VRRP router which > > consists of a sequence (i.e., one or more conceptual > > rows) of 'vrrpv3OperationsEntry' items which describe > > the operational characteristics of a virtual router." > > > > I think "which describe" should read "each of which describes" > > > > --- > > > > vrrpv3OperationsEntry > > > > Rows in the table cannot be modified unless the value > > of 'vrrpv3OperStatus' has transitioned to > > 'initialize' state. > > > > I think a little more precision would help... > > > > A rows in this table cannot be modified unless the > > value > > of 'vrrpv3OperStatus' in the row has transitioned to > > 'initialize' state. > > > > --- > > > > vrrpv3OperationsInetAddrType > > > > As far as I can tell, you only support two values: ipv4(1) and ipv6 > > (2). > > Other values of the InetAddressType textual conventions are, I > > think, not supported. > > > > You should add this fact as a note to the DESCRIPTION clause. > > > > --- > > > > vrrpv3OperationsPrimaryIpAddr > > > > "In the case where there are more than one IP > > > > s/are/is/ > > > > --- > > > > vrrpv3OperationsVirtualMacAddr > > > > REFERENCE "STD 58 RFC 2578" > > > > I am not clear why this reference is cited. MacAddress is defined in > > RFC 2579, but you don't need to provide a reference because that is > > implicit in the IMPORTS clause. Perhaps you mean to give a reference > > to where the mapping from VRID to MAC address is defined? > > > > --- > > > > vrpv3OperStatus > > > > This object is incongruously named. > > To fit with the naming convention for the table you need one of: > > - vrpv3OperationsStatus > > - vrpv3OperationsOperStatus > > > > Note that there are many references to this object throughout the > > document. > > > > --- > > > > vrrpv3OperationsAcceptMode > > > > "Controls whether a virtual router in Master state > > will accept packets addressed to the address owner's > > IPv6 address as its own if it is not the IPv6 address > > owner. Default is False. > > This object is not relevant for rows representing VRRP > > over IPv4 and should be set to false." > > > > Should read... > > > > Default is false(2) > > > > ...and... > > > > should be set to false(2)." > > > > --- > > > > vrrpv3OperationsUpTime > > SYNTAX TimeStamp > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION > > "This is the value of the `sysUpTime' object when this > > virtual router (i.e., the `vrrpv3OperStatus') > > transitioned out of `initialized'." > > > > I am not saying that you MUST change this, but I wonder how useful > > it is, because to make sense of it, a management station must also > > read the current value of sysUpTime. > > > > > > An alternative is to supply the up time in timer ticks. That means > > that the management agent has to perform a computation each the row > > is read. If you did this you would have... > > > > SYNTAX TimeTicks > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION > > "This value represents the amount of time since this > > virtual router (i.e., the `vrrpv3OperStatus') > > transitioned out of `initialize'." > > > > I just need you to think about which you prefer (there is a trade- > > off) and make a decision. No need to tell me which you chose, or why. > > > > Note also s/initialized/initialize/ > > > > --- > > > > Creation and deletion of a vrrpv3OperationsTable row > > > > I'm slightly confused :-( > > > > We have... > > > > vrrpv3OperationsEntry > > > > Rows in the table cannot be modified unless the value > > > > of 'vrrpv3OperStatus' has transitioned to > > 'initialize' state. > > > > and > > > > vrrpv3OperationsRowStatus > > > > When `vrrpv3OperationsRowStatus' is set to > > active(1), no other objects in the conceptual row can > > be modified. > > > > In general, the instructions in the description of the rowStatus are > > good an detailed. But I have some difficulty with row creation. What > > I think is missing is a statement that the row must be created with > > operStatus set to initialize(1) and cannot transition to backup(2) or > > master(3) until rowStatus is transitioned to active(1). > > > > Similarly, there is an issue with row deletion. In order to delete, > > the row I must first set rowStatus to notInService(2), and later to > > delete(6). But, according to the description of operStatus, I cannot > > modify the row (including the rowStatus) until operStatus has gone > > to initialize(1). How do I get that to happen? > > > > I suspect this can be fixed by allowing rowStatus to be changed > > regardless of the value of operStatus. > > > > --- > > > > vrrpv3AssociatedIpAddrTable > > > > "The table of addresses associated with this virtual > > router." > > > > I think that there is just one table, and it contains the addresses > > of all virtual routers. What about... > > > > "The table of addresses associated with each virtual > > router." > > > > --- > > > > vrrpv3AssociatedIpAddrEntry > > > > OLD > > Rows in the table cannot be modified unless the value > > of `vrrpv3OperStatus' has transitioned to > > `initialize'. > > NEW > > Rows in the table cannot be modified unless the value > > of `vrrpv3OperStatus' for the corresponding entry in the > > vrrpv3OperationsTable has transitioned to initialize(1). > > END > > > > --- > > > > vrrpv3AssociatedIpAddr > > > > This object's name is odd given the convention for naming objects > > within their tables. You probably need: > > > > vrrpv3AssociatedIpAddrAddress > > > > --- > > > > vrrpv3AssociatedIpAddr > > > > You should add a statement the description that says that the > > content of the object is to be interpreted in the context of the > > setting of vrrpv3OperationsInetAddrType in the index of this row. > > > > --- > > > > VRRP Router Statistics > > > > Do you need a discontinuity timer for the three global objects: > > - vrrpv3RouterChecksumErrors > > - vrrpv3RouterVersionErrors > > - vrrpv3RouterVrIdErrors > > > > --- > > > > VRRP Router Statistics > > > > In the presence of an attack or a broken router or host nearby, is > > it possible that Countr32 will not be large enough for the up-time > > of this router? > > > > You can choose to use Counter64 or describe wrapping conditions. > > > > --- > > > > vrrpv3RouterVrIdErrors > > > > "The total number of VRRP packets received with an > > invalid VRID for this virtual router." > > > > This object is global, so it is wider than the scope of a single VR. > > I think you need: > > > > "The total number of VRRP packets received with a > > VRID that is not valid for any virtual router on this > > router." > > > > --- > > > > vrrpv3StatisticsAdvIntervalErrors > > > > "The total number of VRRP advertisement packets > > received for which the advertisement interval is > > different than the one configured for the local virtual > > router. > > > > Can you add a reference to vrrpv3OperationsAdvInterval > > > > --- > > > > vrrpv3ProtoError > > > > Don't you think this is a *really* dangerous notification? > > > > If a VR is under attack or receiving packets from a faulty speaker, > > it will spew notifications. > > > > You should probably either add some thresholding objects (which is a > > fair bit of work) or a single object to turn notifications on and > > off (with the default being "off"). > > > > --- > > > > Notifications > > > > As currently specified, both of the notifications will come from the > > management agent which will identify the physical router that > > sourced the notification, but not the VR. > > > > Don't you need to add some index values to the notifications as well? > > > > --- > > > > Section 11 > > > > Since you are obsoleting RFC 2787, is it your intention to ask IANA > > to deprecate {mib-2 68} ? > > > > --- > > > > Would you please consider adding > > > > --- > > > > Section 12 > > > > A reference to RFC 4001 needs to be added as it shows up in some > > REFERENCE clauses. > > > > --- > > > > Would you please consider adding a short section on migrating from > > VRRP-MIB to VRRPV3-MIB? > > > > _______________________________________________ > > vrrp mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/vrrp > > > > Scanned by Check Point Total Security Gateway. > > _______________________________________________ > > vrrp mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/vrrp > _______________________________________________ > vrrp mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/vrrp > > > --0016363b845ca921fa0499d19e6e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <span id=3D"result_box" class=3D"" lang=3D"en"><span title=3D"Click for alt= ernate translations" class=3D"hps">Please</span> <span title=3D"Click for a= lternate translations" class=3D"hps">forgive</span> <span title=3D"Click fo= r alternate translations" class=3D"hps">my</span> <span title=3D"Click for = alternate translations" class=3D"hps">late</span> <span title=3D"Click for = alternate translations" class=3D"hps">to</span> <span title=3D"Click for al= ternate translations" class=3D"hps">respond</span><span title=3D"Click for = alternate translations">.</span><br> <span title=3D"Click for alternate translations" class=3D"hps">This</span>= <span title=3D"Click for alternate translations" class=3D"hps">weekend</sp= an> <span title=3D"Click for alternate translations" class=3D"hps">I</span>= <span title=3D"Click for alternate translations" class=3D"hps">had</span> = <span title=3D"Click for alternate translations" class=3D"hps">a conference= </span> <span title=3D"Click for alternate translations" class=3D"hps">with= </span> <span title=3D"Click for alternate translations" class=3D"hps">frie= nds</span> <span title=3D"Click for alternate translations" class=3D"hps">f= rom</span> <span title=3D"Click for alternate translations" class=3D"hps">c= hina</span> <span title=3D"Click for alternate translations" class=3D"hps">= to</span> <span title=3D"Click for alternate translations" class=3D"hps">di= scuss</span> <span title=3D"Click for alternate translations" class=3D"hps"= >about the</span> <span title=3D"Click for alternate translations" class=3D= "hps">SMSC</span><span title=3D"Click for alternate translations">,</span> = <span title=3D"Click for alternate translations" class=3D"hps">iVAS</span><= span class=3D"" title=3D"Click for alternate translations">,</span> <span t= itle=3D"Click for alternate translations" class=3D"hps">CRBT</span> <span t= itle=3D"Click for alternate translations" class=3D"hps">as</span> <span tit= le=3D"Click for alternate translations" class=3D"hps">well as</span> <span = title=3D"Click for alternate translations" class=3D"hps">cellular</span> <s= pan title=3D"Click for alternate translations" class=3D"hps">network</span>= <span title=3D"Click for alternate translations" class=3D"hps">intelligenc= e</span><br> <br> <span title=3D"Click for alternate translations" class=3D"hps"></span>= </span><span id=3D"result_box" class=3D"" lang=3D"en"><span title=3D"Click = for alternate translations" class=3D"hps">yes</span><span class=3D"" title= =3D"Click for alternate translations">,</span> <span title=3D"Click for alt= ernate translations" class=3D"hps">I</span> <span title=3D"Click for altern= ate translations" class=3D"hps">had</span> <span title=3D"Click for alterna= te translations" class=3D"hps">planned</span> <span title=3D"Click for alte= rnate translations" class=3D"hps">to</span> <span title=3D"Click for altern= ate translations" class=3D"hps">immediately</span> <span title=3D"Click for= alternate translations" class=3D"hps">implement</span></span><span id=3D"r= esult_box" class=3D"" lang=3D"en"><span title=3D"Click for alternate transl= ations" class=3D"hps"></span><span title=3D"Click for alternate translation= s" class=3D"hps"> as soon as possible :)</span></span><br> <br>Regards,<br>Asnara<br><br><br><br><br><br><div class=3D"gmail_quote">On= Fri, Jan 14, 2011 at 3:20 AM, Mukesh Gupta <span dir=3D"ltr"><<a href= =3D"mailto:[email protected]">[email protected]</a>></span> wrote:<br>= <blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; borde= r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> <div link=3D"blue" vlink=3D"purple" lang=3D"EN-US"><div><p class=3D"MsoNorm= al"><span style=3D"font-size: 11pt; color: rgb(31, 73, 125);">Asnara,</span= ></p><p class=3D"MsoNormal"><span style=3D"font-size: 11pt; color: rgb(31, = 73, 125);">=A0</span></p> <p class=3D"MsoNormal"><span style=3D"font-size: 11pt; color: rgb(31, 73, 1= 25);">Thanks for your interest. =A0Do you have any timeline in mind?=A0 </s= pan></p><p class=3D"MsoNormal"><span style=3D"font-size: 11pt; color: rgb(3= 1, 73, 125);">=A0</span></p> <p class=3D"MsoNormal"><span style=3D"font-size: 11pt; color: rgb(31, 73, 1= 25);">As you might know, IETF believes in rough consensus and running code.= =A0 So, having a few implementations of the draft would make all of us comf= ortable with the quality of the draft.</span></p> <p class=3D"MsoNormal"><span style=3D"font-size: 11pt; color: rgb(31, 73, 1= 25);">=A0</span></p><p class=3D"MsoNormal"><span style=3D"font-size: 11pt; = color: rgb(31, 73, 125);">Regards=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 </span></p><p class=3D"MsoNormal"> <span style=3D"font-size: 11pt; color: rgb(31, 73, 125);">Mukesh</span></p>= <p class=3D"MsoNormal"><span style=3D"font-size: 11pt; color: rgb(31, 73, 1= 25);">=A0</span></p><div style=3D"border-width: 1pt medium medium; border-s= tyle: solid none none; border-color: rgb(181, 196, 223) -moz-use-text-color= -moz-use-text-color; padding: 3pt 0in 0in;"> <p class=3D"MsoNormal"><b><span style=3D"font-size: 10pt;">From:</span></b>= <span style=3D"font-size: 10pt;"> Rio Asnara [mailto:<a href=3D"mailto:asna= [email protected]" target=3D"_blank">[email protected]</a>] <br><b>Sent:</b= > Tuesday, January 11, 2011 12:12 AM<br> <b>To:</b> Mukesh Gupta<br><b>Cc:</b> Kalyan (Srinivas)Tata; <a href=3D"mai= lto:[email protected]" target=3D"_blank">[email protected]= g</a>; <a href=3D"mailto:[email protected]" target=3D"_blank">Adrian= [email protected]</a>; <a href=3D"mailto:draft-ietf-vrrp-unified-mib@tools= .ietf.org" target=3D"_blank">[email protected]</a>= ; <a href=3D"mailto:[email protected]" target=3D"_blank">[email protected]</a><br> <b>Subject:</b> Re: [VRRP] AD review of draft-ietf-vrrp-unified-mib</span><= /p></div><p class=3D"MsoNormal">=A0</p><p class=3D"MsoNormal" style=3D"marg= in-bottom: 12pt;">All,<br>I'm interested to implemented on my virtual s= ystem :)<br> <br>Regards,<br>Asnara<br><br><br></p><div><p class=3D"MsoNormal">On Tue, J= an 11, 2011 at 5:56 AM, Mukesh Gupta <<a href=3D"mailto:[email protected]= et" target=3D"_blank">[email protected]</a>> wrote:</p><p class=3D"MsoN= ormal"> Kalyan,<br><br>Thanks a lot. =A0Please go ahead and address the comments an= d publish<br>the next rev. We all want this draft done asap :)<br><br>- Muk= esh<br><br>Sent from my iPhone<br><br>On Jan 10, 2011, at 2:12 PM, "Ka= lyan (Srinivas)Tata" <<a href=3D"mailto:[email protected]" targe= t=3D"_blank">[email protected]</a></p> <div><div><p class=3D"MsoNormal">=A0> wrote:<br><br>> Thanks Adrian f= or the review. I will update the draft (Once WG<br>> chairs confirm). I = will getback if I need any clarifications.<br>><br>> Thanks<br>> K= alyan<br> ><br>> -----Original Message-----<br>> From: <a href=3D"mailto:vrr= [email protected]" target=3D"_blank">[email protected]</a> [mailto:<a = href=3D"mailto:[email protected]" target=3D"_blank">[email protected]= rg</a>] On Behalf<br> > Of Adrian Farrel<br>> Sent: Saturday, January 08, 2011 11:37 AM<br>= > To: <a href=3D"mailto:[email protected]" targ= et=3D"_blank">[email protected]</a><br>> Cc: <a= href=3D"mailto:[email protected]" target=3D"_blank">vrrp-chairs@t= ools.ietf.org</a>; <a href=3D"mailto:[email protected]" target=3D"_blank">vrrp@= ietf.org</a><br> > Subject: [VRRP] AD review of draft-ietf-vrrp-unified-mib<br>><br>&g= t; Hi,<br>><br>> Don't panic!<br>><br>> I have performed my= AD review of your draft. The purpose of the<br>> review is to catch any= nits or issues before the document goes<br> > forward to IETF last call and IESG review. By getting these issues<br>= > out at this stage we can hope for a higher quality review and a<br>>= ; smoother passage through the process.<br>><br>> There are a good nu= mber of small issues that I believe can be fixed<br> > really easily.<br>><br>> I appreciate that a number of these iss= ues are inherited from RFC<br>> 2787, but this is an ideal chance to cle= an up.<br>><br>> You will need a new revision to address these points= , and I'd ask<br> > the WG chairs to evaluate whether the changes are large enough to<br>&= gt; warrant a further WG last call.<br>><br>> I have moved the draft = into "AD-review:Revised-ID-needed" state in<br>> the datatrack= er, and I look forward to seeing the new revision which<br> > I can put forward for IETF last call.<br>><br>> Thanks for all y= our work with this draft,<br>><br>> Adrian<br>><br>> ---<br>>= ;<br>> Document header<br>><br>> OLD<br>> =A0 Document: draft-i= etf-vrrp-unified-mib-08.txt =A0 =A0 =A0 =A0 =A0 =A0 =A0 July 2010<br> > =A0 Intended Status: Proposed Standard<br>> NEW<br>> =A0 Documen= t: draft-ietf-vrrp-unified-mib-08.txt =A0 =A0 =A0 =A0 =A0 =A0 =A0 July 2010= <br>> =A0 Obsoletes: 2787 (if approved)<br>> =A0 Intended Status: Pro= posed Standard<br> > END<br>><br>> ---<br>><br>> Abstract<br>><br>> OLD<b= r>> =A0 This specification defines a Management Information Base (MIB) f= or<br>> NEW<br>> =A0 This specification defines a portion of the Mana= gement Information<br> > =A0 Base (MIB) for<br>> END<br>><br>> ---<br>><br>> Sec= tion 2<br>><br>> OLD<br>> =A0 This specification defines a Managem= ent Information Base (MIB) for<br>> NEW<br>> =A0 This specification d= efines a portion of the Management Information<br> > =A0 Base (MIB) for<br>> END<br>><br>> ---<br>><br>> Sec= tion 2 etc.<br>><br>> Is it necessary to introduce the term "IPv= X"? It is only used a<br>> couple of times, and the time it is used= in the MIB module is a<br> > problem because the definition of the term is outside the module.<br>&= gt; (Typically, MIB modules are extracted from RFCs and have to survive<br>= > as standalone<br>> text.)<br>><br>> Can you:<br>> - remove= "(IPvX)" form section 2<br> > - remove the definition for section 3<br>> - say "IPv4 and IPv= 6" in the two uses in section 6 and section 9<br>><br>> ---<br>&= gt;<br>> Section 4<br>><br>> You need to add text to describe what= has changed from 2787. Not a<br> > lot of details - perhaps a series of bullet points.<br>><br>> --= <br>><br>> Section 6 etc.<br>><br>> You need to say "MIB m= odule" not "MIB" because there is only one<br>> MIB, and = you are making just a module in the MIB.<br> ><br>> s/This MIB is designed/This MIB module is designed/<br>><br= >><br>> ---<br>><br>><br>> Section 7<br>><br>> =A0 Tab= les in the MIB include the following:<br>><br>> In fact, there are ex= actly these three tables, so how about...<br> ><br>> =A0 This MIB module contains three tables:<br>><br>> ---= <br>><br>> Section 8<br>><br>> Trivial, but...<br>><br>> = =A0 =A0 =A0 =A0 =A0 ----- =A0 MIB Tables For VRRP Router "VR 1": = =A0 -----<br> ><br>> ...should read "VR1"<br>> Similarly for VR2 later= in the section.<br>><br>> ---<br>><br>> IMPORTS<br>><br>>= ; It is helpful, but mandatory, to show the RFC numbers from which<br>> = things are imported. Thus...<br> ><br>> OLD<br>> =A0 =A0 =A0 IMPORTS<br>> =A0 =A0 =A0 =A0 =A0 MO= DULE-IDENTITY, OBJECT-TYPE,<br>> =A0 =A0 =A0 =A0 =A0 NOTIFICATION-TYPE, = Counter32,<br>> =A0 =A0 =A0 =A0 =A0 Integer32, mib-2, Unsigned32 =A0 =A0= =A0 =A0FROM SNMPv2-SMI<br>><br>> =A0 =A0 =A0 =A0 =A0 TEXTUAL-CONVENT= ION, RowStatus,<br> > =A0 =A0 =A0 =A0 =A0 MacAddress, TruthValue, TimeStamp,<br>> =A0 =A0= =A0 =A0 =A0 TimeInterval =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0FR= OM SNMPv2-TC<br>><br>> =A0 =A0 =A0 =A0 =A0 MODULE-COMPLIANCE, OBJECT-= GROUP,<br>> =A0 =A0 =A0 =A0 =A0 NOTIFICATION-GROUP =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0FROM SNMPv2-CONF<br> > =A0 =A0 =A0 =A0 =A0 ifIndex =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 FROM IF-MIB<br>> =A0 =A0 =A0 =A0 =A0 InetAddressType, In= etAddress =A0 =A0 =A0 =A0FROM INET-ADDRESS-MIB;<br>> NEW<br>> =A0 =A0= =A0 IMPORTS<br>> =A0 =A0 =A0 =A0 =A0 MODULE-IDENTITY, OBJECT-TYPE,<br> > =A0 =A0 =A0 =A0 =A0 NOTIFICATION-TYPE, Counter32,<br>><br>> =A0 = =A0 =A0 =A0 =A0 Integer32, mib-2, Unsigned32<br>> =A0 =A0 =A0 =A0 =A0 = =A0 =A0 FROM SNMPv2-SMI =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 -- RFC2578<br>><br>> =A0 =A0 =A0 =A0 =A0 TEXTUAL-CONVENTION,= RowStatus,<br> > =A0 =A0 =A0 =A0 =A0 MacAddress, TruthValue, TimeStamp,<br>> =A0 =A0= =A0 =A0 =A0 TimeInterval<br>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 FROM SNMPv2-T= C =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0-- RFC2579= <br>><br>> =A0 =A0 =A0 =A0 =A0 MODULE-COMPLIANCE, OBJECT-GROUP,<br> > =A0 =A0 =A0 =A0 =A0 NOTIFICATION-GROUP<br>> =A0 =A0 =A0 =A0 =A0 =A0= =A0 FROM SNMPv2-CONF =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0-- RFC2580<br>><br>> =A0 =A0 =A0 =A0 =A0 ifIndex<br>> =A0 = =A0 =A0 =A0 =A0 =A0 =A0 FROM IF-MIB =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 -- RFC2863<br> ><br>><br>> =A0 =A0 =A0 =A0 =A0 InetAddressType, InetAddress<br>&g= t; =A0 =A0 =A0 =A0 =A0 =A0 =A0 FROM INET-ADDRESS-MIB; =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0-- RFC3291<br>> END<br>><br>> ---<br>&g= t;<br>> Section 9<br>><br>> In order to ensure that references can= be provided, it is customary<br> > to begin Section 9 (i.e. before the module BEGIN statement) with<br>&g= t; some text such as:<br>><br>> =A0 This MIB module makes reference t= o the following documents<br>> [RFC2578],<br>> =A0 [RFC2579], [RFC258= 0], [RFC2863], [RFC3291], and [RFC4001].<br> ><br>> ---<br>><br>> Vrrpv3VrIdTC<br>><br>> Typos<br>>= =A0 =A0 =A0 =A0 =A0 =A0 =A0 (ifIndex)and IP version, serves to uniquely id= entify a<br>> Missing space.<br>><br>> =A0 =A0 =A0 =A0 =A0 REFEREN= CE " RFC 5798 (Sections 3 and 5.2.3"<br> > Missing close brace.<br>><br>> ---<br>><br>> vrrpv3Operati= onsTable<br>><br>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 "Unified Operatio= ns table for a VRRP router which<br>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0con= sists of a sequence (i.e., one or more conceptual<br> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0rows) of 'vrrpv3OperationsEntry'= ; items which describe<br>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0the operation= al characteristics of a virtual router."<br>><br>> I think "= ;which describe" should read "each of which describes"<br> ><br>> ---<br>><br>> vrrpv3OperationsEntry<br>><br>> =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0Rows in the table cannot be modified unless the = value<br>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0of 'vrrpv3OperStatus' = has transitioned to<br>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0'initialize&= #39; state.<br> ><br>> I think a little more precision would help...<br>><br>> = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0A rows in this table cannot be modified unle= ss the<br>> value<br>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0of 'vrrpv3O= perStatus' in the row has transitioned to<br> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0'initialize' state.<br>><br>= > ---<br>><br>> vrrpv3OperationsInetAddrType<br>><br>> As fa= r as I can tell, you only support two values: ipv4(1) and ipv6<br>> (2).= <br>> Other values of the InetAddressType textual conventions are, I<br> > think, not supported.<br>><br>> You should add this fact as a no= te to the DESCRIPTION clause.<br>><br>> ---<br>><br>> vrrpv3Ope= rationsPrimaryIpAddr<br>><br>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 "In t= he case where there are more than one IP<br> ><br>> s/are/is/<br>><br>> ---<br>><br>> vrrpv3Operations= VirtualMacAddr<br>><br>> =A0 =A0 =A0 =A0 =A0 REFERENCE "STD 58 R= FC 2578"<br>><br>> I am not clear why this reference is cited. M= acAddress is defined in<br> > RFC 2579, but you don't need to provide a reference because that i= s<br>> implicit in the IMPORTS clause. Perhaps you mean to give a refere= nce<br>> to where the mapping from VRID to MAC address is defined?<br> ><br>> ---<br>><br>> vrpv3OperStatus<br>><br>> This objec= t is incongruously named.<br>> To fit with the naming convention for the= table you need one of:<br>> - vrpv3OperationsStatus<br>> - vrpv3Oper= ationsOperStatus<br> ><br>> Note that there are many references to this object throughout = the<br>> document.<br>><br>> ---<br>><br>> vrrpv3OperationsA= cceptMode<br>><br>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 "Controls whethe= r a virtual router in Master state<br> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 will accept packets addressed to the addre= ss owner's<br>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 IPv6 address as its own = if it is not the IPv6 address<br>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 owner. = =A0Default is False.<br>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 This object is not= relevant for rows representing VRRP<br> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 over IPv4 and should be set to false."= ;<br>><br>> Should read...<br>><br>> =A0 Default is false(2)<br= >><br>> ...and...<br>><br>> =A0 should be set to false(2)."= ;<br>><br>> ---<br> ><br>> vrrpv3OperationsUpTime<br>> =A0 =A0 =A0 =A0 =A0 SYNTAX =A0 = =A0 =A0 TimeStamp<br>> =A0 =A0 =A0 =A0 =A0 MAX-ACCESS =A0 read-only<br>&= gt; =A0 =A0 =A0 =A0 =A0 STATUS =A0 =A0 =A0 current<br>> =A0 =A0 =A0 =A0 = =A0 DESCRIPTION<br>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 "This is the value= of the `sysUpTime' object when this<br> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 virtual router (i.e., the `vrrpv3OperStatu= s')<br>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 transitioned out of `initialize= d'."<br>><br>> I am not saying that you MUST change this, bu= t I wonder how useful<br> > it is, because to make sense of it, a management station must also<br>= > read the current value of sysUpTime.<br>><br>><br>> An altern= ative is to supply the up time in timer ticks. That means<br>> that the = management agent has to perform a computation each the row<br> > is read. If you did this you would have...<br>><br>> =A0 =A0 =A0= =A0 =A0 SYNTAX =A0 =A0 =A0 TimeTicks<br>> =A0 =A0 =A0 =A0 =A0 MAX-ACCES= S =A0 read-only<br>> =A0 =A0 =A0 =A0 =A0 STATUS =A0 =A0 =A0 =A0current<b= r>> =A0 =A0 =A0 =A0 =A0 DESCRIPTION<br>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 = "This value represents the amount of time since this<br> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 virtual router (i.e., the `vrrpv3OperStatu= s')<br>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 transitioned out of `initialize= '."<br>><br>> I just need you to think about which you prefe= r (there is a trade-<br> > off) and make a decision. No need to tell me which you chose, or why.<= br>><br>> Note also s/initialized/initialize/<br>><br>> ---<br>= ><br>> Creation and deletion of a vrrpv3OperationsTable row<br>><b= r> > I'm slightly confused :-(<br>><br>> We have...<br>><br>&g= t; =A0 =A0 =A0 vrrpv3OperationsEntry<br>><br>> =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0Rows in the table cannot be modified unless the value<br>><br= >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0of 'vrrpv3OperStatus' has tran= sitioned to<br> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0'initialize' state.<br>><br>= > and<br>><br>> =A0 =A0 =A0 vrrpv3OperationsRowStatus<br>><br>&= gt; =A0 =A0 =A0 =A0 =A0 =A0 =A0 When `vrrpv3OperationsRowStatus' is set= to<br>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 active(1), no other objects in the = conceptual row can<br> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 be modified.<br>><br>> In general, t= he instructions in the description of the rowStatus are<br>> good an det= ailed. But I have some difficulty with row creation. What<br>> I think i= s missing is a statement that the row must be created with<br> > operStatus set to initialize(1) and cannot transition to backup(2) or<= br>> master(3) until rowStatus is transitioned to active(1).<br>><br>= > Similarly, there is an issue with row deletion. In order to delete,<br= > > the row I must first set rowStatus to notInService(2), and later to<br= >> delete(6). But, according to the description of operStatus, I cannot<= br>> modify the row (including the rowStatus) until operStatus has gone<= br> > to initialize(1). How do I get that to happen?<br>><br>> I suspe= ct this can be fixed by allowing rowStatus to be changed<br>> regardless= of the value of operStatus.<br>><br>> ---<br>><br>> vrrpv3Asso= ciatedIpAddrTable<br> ><br>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 "The table of addresses assoc= iated with this virtual<br>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0router."= ;<br>><br>> I think that there is just one table, and it contains the= addresses<br>> of all virtual routers. What about...<br> ><br>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 "The table of addresses assoc= iated with each virtual<br>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0router."= ;<br>><br>> ---<br>><br>> vrrpv3AssociatedIpAddrEntry<br>><b= r>> OLD<br>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 Rows in the table cannot be = modified unless the value<br> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 of `vrrpv3OperStatus' has transitioned= to<br>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 `initialize'.<br>> NEW<br>&g= t; =A0 =A0 =A0 =A0 =A0 =A0 =A0 Rows in the table cannot be modified unless = the value<br>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 of `vrrpv3OperStatus' for= the corresponding entry in the<br> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 vrrpv3OperationsTable has transitioned to = initialize(1).<br>> END<br>><br>> ---<br>><br>> vrrpv3Associ= atedIpAddr<br>><br>> This object's name is odd given the conventi= on for naming objects<br> > within their tables. You probably need:<br>><br>> vrrpv3Associat= edIpAddrAddress<br>><br>> ---<br>><br>> vrrpv3AssociatedIpAddr<= br>><br>> You should add a statement the description that says that t= he<br> > content of the object is to be interpreted in the context of the<br>&g= t; setting of vrrpv3OperationsInetAddrType in the index of this row.<br>>= ;<br>> ---<br>><br>> VRRP Router Statistics<br>><br>> Do you= need a discontinuity timer for the three global objects:<br> > - vrrpv3RouterChecksumErrors<br>> - vrrpv3RouterVersionErrors<br>&g= t; - vrrpv3RouterVrIdErrors<br>><br>> ---<br>><br>> VRRP Router= Statistics<br>><br>> In the presence of an attack or a broken router= or host nearby, is<br> > it possible that Countr32 will not be large enough for the up-time<br>= > of this router?<br>><br>> You can choose to use Counter64 or des= cribe wrapping conditions.<br>><br>> ---<br>><br>> vrrpv3Router= VrIdErrors<br> ><br>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 "The total number of VRRP pac= kets received with an<br>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 invalid VRID for = this virtual router."<br>><br>> This object is global, so it is = wider than the scope of a single VR.<br> > I think you need:<br>><br>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 "Th= e total number of VRRP packets received with a<br>> =A0 =A0 =A0 =A0 =A0 = =A0 =A0 VRID that is not valid for any virtual router on this<br>> =A0 = =A0 =A0 =A0 =A0 =A0 =A0 router."<br> ><br>> ---<br>><br>> vrrpv3StatisticsAdvIntervalErrors<br>><= br>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 "The total number of VRRP advertis= ement packets<br>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 received for which the ad= vertisement interval is<br> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 different than the one configured for the = local virtual<br>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 router.<br>><br>> C= an you add a reference to vrrpv3OperationsAdvInterval<br>><br>> ---<b= r>><br>> vrrpv3ProtoError<br> ><br>> Don't you think this is a *really* dangerous notification?= <br>><br>> If a VR is under attack or receiving packets from a faulty= speaker,<br>> it will spew notifications.<br>><br>> You should pr= obably either add some thresholding objects (which is a<br> > fair bit of work) or a single object to turn notifications on and<br>&= gt; off (with the default being "off").<br>><br>> ---<br>&g= t;<br>> Notifications<br>><br>> As currently specified, both of th= e notifications will come from the<br> > management agent which will identify the physical router that<br>> = sourced the notification, but not the VR.<br>><br>> Don't you nee= d to add some index values to the notifications as well?<br>><br>> --= -<br> ><br>> Section 11<br>><br>> Since you are obsoleting RFC 2787, = is it your intention to ask IANA<br>> to deprecate {mib-2 68} ?<br>><= br>> ---<br>><br>> Would you please consider adding<br>><br> > ---<br>><br>> Section 12<br>><br>> A reference to RFC 4001= needs to be added as it shows up in some<br>> REFERENCE clauses.<br>>= ;<br>> ---<br>><br>> Would you please consider adding a short sect= ion on migrating from<br> > VRRP-MIB to VRRPV3-MIB?<br>><br>> ______________________________= _________________<br>> vrrp mailing list<br>> <a href=3D"mailto:vrrp@= ietf.org" target=3D"_blank">[email protected]</a><br>> <a href=3D"https://ww= w.ietf.org/mailman/listinfo/vrrp" target=3D"_blank">https://www.ietf.org/ma= ilman/listinfo/vrrp</a><br> ><br>> Scanned by Check Point Total Security Gateway.<br>> _______= ________________________________________<br>> vrrp mailing list<br>> = <a href=3D"mailto:[email protected]" target=3D"_blank">[email protected]</a><br>>= ; <a href=3D"https://www.ietf.org/mailman/listinfo/vrrp" target=3D"_blank">= https://www.ietf.org/mailman/listinfo/vrrp</a><br> _______________________________________________<br>vrrp mailing list<br><a = href=3D"mailto:[email protected]" target=3D"_blank">[email protected]</a><br><a hre= f=3D"https://www.ietf.org/mailman/listinfo/vrrp" target=3D"_blank">https://= www.ietf.org/mailman/listinfo/vrrp</a></p> </div></div></div><p class=3D"MsoNormal">=A0</p></div></div></blockquote></= div><br> --0016363b845ca921fa0499d19e6e-- --===============1275124908== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ vrrp mailing list [email protected] https://www.ietf.org/mailman/listinfo/vrrp --===============1275124908==--