Re: AD review of draft-ietf-vrrp-unified-mib
Rio Asnara <[email protected]> Tue, 11 Jan 2011 15:12:09 +0700
| Newsgroups | gmane.ietf.vrrp |
|---|---|
| Message-ID | <[email protected]> |
--===============0956064148== Content-Type: multipart/alternative; boundary=0016e6509cc61ee76104998da405 --0016e6509cc61ee76104998da405 Content-Type: text/plain; charset=ISO-8859-1 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 > --0016e6509cc61ee76104998da405 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable All,<br>I'm interested to implemented on my virtual system :)<br><br>Re= gards,<br>Asnara<br><br><br><br><div class=3D"gmail_quote">On Tue, Jan 11, = 2011 at 5:56 AM, Mukesh Gupta <span dir=3D"ltr"><<a href=3D"mailto:mukes= [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;">Kalyan,<br> <br> Thanks a lot. =A0Please go ahead and address the comments and publish<br> the next rev. We all want this draft done asap :)<br> <br> - Mukesh<br> <br> Sent from my iPhone<br> <br> On Jan 10, 2011, at 2:12 PM, "Kalyan (Srinivas)Tata" <<a href= =3D"mailto:[email protected]">[email protected]</a><br> <div><div></div><div class=3D"h5">=A0> wrote:<br> <br> > Thanks Adrian for the review. I will update the draft (Once WG<br> > chairs confirm). I will getback if I need any clarifications.<br> ><br> > Thanks<br> > Kalyan<br> ><br> > -----Original Message-----<br> > From: <a href=3D"mailto:[email protected]">[email protected]</= a> [mailto:<a href=3D"mailto:[email protected]">[email protected]</= a>] On Behalf<br> > Of Adrian Farrel<br> > Sent: Saturday, January 08, 2011 11:37 AM<br> > To: <a href=3D"mailto:[email protected]">draf= [email protected]</a><br> > Cc: <a href=3D"mailto:[email protected]">[email protected]= tf.org</a>; <a href=3D"mailto:[email protected]">[email protected]</a><br> > Subject: [VRRP] AD review of draft-ietf-vrrp-unified-mib<br> ><br> > 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 number of small issues that I believe can be fixed<br= > > really easily.<br> ><br> > I appreciate that a number of these issues are inherited from RFC<br> > 2787, but this is an ideal chance to clean 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> > warrant a further WG last call.<br> ><br> > I have moved the draft into "AD-review:Revised-ID-needed" st= ate in<br> > the datatracker, and I look forward to seeing the new revision which<b= r> > I can put forward for IETF last call.<br> ><br> > Thanks for all your work with this draft,<br> ><br> > Adrian<br> ><br> > ---<br> ><br> > Document header<br> ><br> > OLD<br> > =A0 Document: draft-ietf-vrrp-unified-mib-08.txt =A0 =A0 =A0 =A0 =A0 = =A0 =A0 July 2010<br> > =A0 Intended Status: Proposed Standard<br> > NEW<br> > =A0 Document: 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: Proposed Standard<br> > END<br> ><br> > ---<br> ><br> > Abstract<br> ><br> > OLD<br> > =A0 This specification defines a Management Information Base (MIB) for= <br> > NEW<br> > =A0 This specification defines a portion of the Management Information= <br> > =A0 Base (MIB) for<br> > END<br> ><br> > ---<br> ><br> > Section 2<br> ><br> > OLD<br> > =A0 This specification defines a Management Information Base (MIB) for= <br> > NEW<br> > =A0 This specification defines a portion of the Management Information= <br> > =A0 Base (MIB) for<br> > END<br> ><br> > ---<br> ><br> > Section 2 etc.<br> ><br> > Is it necessary to introduce the term "IPvX"? It is only use= d 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> > (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 IPv6" in the two uses in section 6 and secti= on 9<br> ><br> > ---<br> ><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 module" not "MIB" because the= re 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 Tables in the MIB include the following:<br> ><br> > In fact, there are exactly 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&qu= ot;: =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 MODULE-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 S= NMPv2-SMI<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 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0FROM 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, InetAddress =A0 =A0 =A0 =A0FROM I= NET-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-TC =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> > =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> ><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> > some text such as:<br> ><br> > =A0 This MIB module makes reference to the following documents<br> > [RFC2578],<br> > =A0 [RFC2579], [RFC2580], [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 uniquel= y identify a<br> > Missing space.<br> ><br> > =A0 =A0 =A0 =A0 =A0 REFERENCE " RFC 5798 (Sections 3 and 5.2.3&qu= ot;<br> > Missing close brace.<br> ><br> > ---<br> ><br> > vrrpv3OperationsTable<br> ><br> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 "Unified Operations table for a VRRP = router which<br> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0consists of a sequence (i.e., one or mo= re conceptual<br> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0rows) of 'vrrpv3OperationsEntry'= ; items which describe<br> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0the operational characteristics of a vi= rtual router."<br> ><br> > I think "which describe" should read "each of which des= cribes"<br> ><br> > ---<br> ><br> > vrrpv3OperationsEntry<br> ><br> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Rows in the table cannot be modified un= less the value<br> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0of 'vrrpv3OperStatus' has trans= itioned to<br> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0'initialize' 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= unless the<br> > value<br> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0of 'vrrpv3OperStatus' in the ro= w has transitioned to<br> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0'initialize' state.<br> ><br> > ---<br> ><br> > vrrpv3OperationsInetAddrType<br> ><br> > As far 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 note to the DESCRIPTION clause.<br> ><br> > ---<br> ><br> > vrrpv3OperationsPrimaryIpAddr<br> ><br> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 "In the case where there are more tha= n one IP<br> ><br> > s/are/is/<br> ><br> > ---<br> ><br> > vrrpv3OperationsVirtualMacAddr<br> ><br> > =A0 =A0 =A0 =A0 =A0 REFERENCE "STD 58 RFC 2578"<br> ><br> > I am not clear why this reference is cited. MacAddress is defined in<b= r> > 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 reference<b= r> > to where the mapping from VRID to MAC address is defined?<br> ><br> > ---<br> ><br> > vrpv3OperStatus<br> ><br> > This object is incongruously named.<br> > To fit with the naming convention for the table you need one of:<br> > - vrpv3OperationsStatus<br> > - vrpv3OperationsOperStatus<br> ><br> > Note that there are many references to this object throughout the<br> > document.<br> ><br> > ---<br> ><br> > vrrpv3OperationsAcceptMode<br> ><br> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 "Controls whether 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 I= Pv6 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 repre= senting 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> > =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&= #39; 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 `initialized'.&quo= t;<br> ><br> > I am not saying that you MUST change this, but 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 alternative 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-ACCESS =A0 read-only<br> > =A0 =A0 =A0 =A0 =A0 STATUS =A0 =A0 =A0 =A0current<br> > =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 prefer (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> ><br> > I'm slightly confused :-(<br> ><br> > We have...<br> ><br> > =A0 =A0 =A0 vrrpv3OperationsEntry<br> ><br> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Rows in the table cannot be modified un= less the value<br> ><br> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0of 'vrrpv3OperStatus' has trans= itioned to<br> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0'initialize' state.<br> ><br> > and<br> ><br> > =A0 =A0 =A0 vrrpv3OperationsRowStatus<br> ><br> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 When `vrrpv3OperationsRowStatus' is se= t to<br> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 active(1), no other objects in the concept= ual row can<br> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 be modified.<br> ><br> > In general, the instructions in the description of the rowStatus are<b= r> > good an detailed. But I have some difficulty with row creation. What<b= r> > I think is 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<b= r> > modify the row (including the rowStatus) until operStatus has gone<br> > to initialize(1). How do I get that to happen?<br> ><br> > I suspect this can be fixed by allowing rowStatus to be changed<br> > regardless of the value of operStatus.<br> ><br> > ---<br> ><br> > vrrpv3AssociatedIpAddrTable<br> ><br> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 "The table of addresses associated wi= th 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 associated wi= th each virtual<br> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0router."<br> ><br> > ---<br> ><br> > vrrpv3AssociatedIpAddrEntry<br> ><br> > OLD<br> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 Rows in the table cannot be modified unles= s 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> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 Rows in the table cannot be modified unles= s the value<br> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 of `vrrpv3OperStatus' for the correspo= nding entry in the<br> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 vrrpv3OperationsTable has transitioned to = initialize(1).<br> > END<br> ><br> > ---<br> ><br> > vrrpv3AssociatedIpAddr<br> ><br> > This object's name is odd given the convention for naming objects<= br> > within their tables. You probably need:<br> ><br> > vrrpv3AssociatedIpAddrAddress<br> ><br> > ---<br> ><br> > vrrpv3AssociatedIpAddr<br> ><br> > You should add a statement the description that says that the<br> > content of the object is to be interpreted in the context of the<br> > 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> > - 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 describe wrapping conditions.<br> ><br> > ---<br> ><br> > vrrpv3RouterVrIdErrors<br> ><br> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 "The total number of VRRP packets rec= eived 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.<b= r> > I think you need:<br> ><br> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 "The total number of VRRP packets rec= eived with a<br> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 VRID that is not valid for any virtual rou= ter 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 advertiseme= nt packets<br> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 received for which the advertisement inter= val 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> > Can you add a reference to vrrpv3OperationsAdvInterval<br> ><br> > ---<br> ><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 probably either add some thresholding objects (which is a<b= r> > fair bit of work) or a single object to turn notifications on and<br> > off (with the default being "off").<br> ><br> > ---<br> ><br> > Notifications<br> ><br> > As currently specified, both of the notifications will come from the<b= r> > management agent which will identify the physical router that<br> > sourced the notification, but not the VR.<br> ><br> > Don't you need to add some index values to the notifications as we= ll?<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 section on migrating from<br> > VRRP-MIB to VRRPV3-MIB?<br> ><br> > _______________________________________________<br> > vrrp mailing list<br> > <a href=3D"mailto:[email protected]">[email protected]</a><br> > <a href=3D"https://www.ietf.org/mailman/listinfo/vrrp" target=3D"_blan= k">https://www.ietf.org/mailman/listinfo/vrrp</a><br> ><br> > Scanned by Check Point Total Security Gateway.<br> > _______________________________________________<br> > vrrp mailing list<br> > <a href=3D"mailto:[email protected]">[email protected]</a><br> > <a href=3D"https://www.ietf.org/mailman/listinfo/vrrp" target=3D"_blan= k">https://www.ietf.org/mailman/listinfo/vrrp</a><br> _______________________________________________<br> vrrp mailing list<br> <a href=3D"mailto:[email protected]">[email protected]</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/vrrp" target=3D"_blank">ht= tps://www.ietf.org/mailman/listinfo/vrrp</a><br> </div></div></blockquote></div><br> --0016e6509cc61ee76104998da405-- --===============0956064148== 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 --===============0956064148==--