Re: AD review of draft-ietf-vrrp-unified-mib
Mukesh Gupta <[email protected]> Thu, 13 Jan 2011 12:20:41 -0800
| Newsgroups | gmane.ietf.vrrp |
|---|---|
| Message-ID | <[email protected]> |
--===============1134359193== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_497B6D90E0023142AF34948DEFFAB38D3B35815809EMBX01HQjnprn_" --_000_497B6D90E0023142AF34948DEFFAB38D3B35815809EMBX01HQjnprn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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]; Adrian.Farrel@huawei= .com; [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]<mailto:mu= [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]<= mailto:[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]> [mailto:vrrp-bo= [email protected]<mailto:[email protected]>] On Behalf > Of Adrian Farrel > Sent: Saturday, January 08, 2011 11:37 AM > To: [email protected]<mailto:draft-ietf-vrrp-uni= [email protected]> > Cc: [email protected]<mailto:[email protected]>; vrrp@i= etf.org<mailto:[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]<mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/vrrp > > Scanned by Check Point Total Security Gateway. > _______________________________________________ > vrrp mailing list > [email protected]<mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/vrrp _______________________________________________ vrrp mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/vrrp --_000_497B6D90E0023142AF34948DEFFAB38D3B35815809EMBX01HQjnprn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:x=3D"urn:schemas-microsoft-com:office:excel" xmlns:p=3D"urn:schemas-m= icrosoft-com:office:powerpoint" xmlns:a=3D"urn:schemas-microsoft-com:office= :access" xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s=3D"= uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs=3D"urn:schemas-microsof= t-com:rowset" xmlns:z=3D"#RowsetSchema" xmlns:b=3D"urn:schemas-microsoft-co= m:office:publisher" xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadshee= t" xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" xmlns= :odc=3D"urn:schemas-microsoft-com:office:odc" xmlns:oa=3D"urn:schemas-micro= soft-com:office:activation" xmlns:html=3D"http://www.w3.org/TR/REC-html40" = xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" xmlns:rtc=3D"http://m= icrosoft.com/officenet/conferencing" xmlns:D=3D"DAV:" xmlns:Repl=3D"http://= schemas.microsoft.com/repl/" xmlns:mt=3D"http://schemas.microsoft.com/share= point/soap/meetings/" xmlns:x2=3D"http://schemas.microsoft.com/office/excel= /2003/xml" xmlns:ppda=3D"http://www.passport.com/NameSpace.xsd" xmlns:ois= =3D"http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir=3D"http://= schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds=3D"http://www.w3= .org/2000/09/xmldsig#" xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint= /dsp" xmlns:udc=3D"http://schemas.microsoft.com/data/udc" xmlns:xsd=3D"http= ://www.w3.org/2001/XMLSchema" xmlns:sub=3D"http://schemas.microsoft.com/sha= repoint/soap/2002/1/alerts/" xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#"= xmlns:sp=3D"http://schemas.microsoft.com/sharepoint/" xmlns:sps=3D"http://= schemas.microsoft.com/sharepoint/soap/" xmlns:xsi=3D"http://www.w3.org/2001= /XMLSchema-instance" xmlns:udcs=3D"http://schemas.microsoft.com/data/udc/so= ap" xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udc= p2p=3D"http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf=3D"http:/= /schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss=3D"http://sche= mas.microsoft.com/office/2006/digsig-setup" xmlns:dssi=3D"http://schemas.mi= crosoft.com/office/2006/digsig" xmlns:mdssi=3D"http://schemas.openxmlformat= s.org/package/2006/digital-signature" xmlns:mver=3D"http://schemas.openxmlf= ormats.org/markup-compatibility/2006" xmlns:m=3D"http://schemas.microsoft.c= om/office/2004/12/omml" xmlns:mrels=3D"http://schemas.openxmlformats.org/pa= ckage/2006/relationships" xmlns:spwp=3D"http://microsoft.com/sharepoint/web= partpages" xmlns:ex12t=3D"http://schemas.microsoft.com/exchange/services/20= 06/types" xmlns:ex12m=3D"http://schemas.microsoft.com/exchange/services/200= 6/messages" xmlns:pptsl=3D"http://schemas.microsoft.com/sharepoint/soap/Sli= deLibrary/" xmlns:spsl=3D"http://microsoft.com/webservices/SharePointPortal= Server/PublishedLinksService" xmlns:Z=3D"urn:schemas-microsoft-com:" xmlns:= st=3D"" xmlns=3D"http://www.w3.org/TR/REC-html40"><head><META HTTP-EQUI= V=3D"Content-Type" CONTENT=3D"text/html; charset=3Dus-ascii"><meta name=3DG= enerator content=3D"Microsoft Word 12 (filtered medium)"><style><!-- /* Font Definitions */ @font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4;} @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} @font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:12.0pt; font-family:"Times New Roman","serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} span.EmailStyle17 {mso-style-type:personal-reply; font-family:"Calibri","sans-serif"; color:#1F497D;} .MsoChpDefault {mso-style-type:export-only;} @page WordSection1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;} div.WordSection1 {page:WordSection1;} --></style><!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--></head><body lang=3DEN-US link=3Dblue vli= nk=3Dpurple><div class=3DWordSection1><p class=3DMsoNormal><span style=3D'f= ont-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Asnara,<o= :p></o:p></span></p><p class=3DMsoNormal><span style=3D'font-size:11.0pt;fo= nt-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p= ><p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri"= ,"sans-serif";color:#1F497D'>Thanks for your interest. Do you have an= y timeline in mind? <o:p></o:p></span></p><p class=3DMsoNormal><span = style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'= ><o:p> </o:p></span></p><p class=3DMsoNormal><span style=3D'font-size:= 11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>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 qual= ity of the draft.<o:p></o:p></span></p><p class=3DMsoNormal><span style=3D'= font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p>&nb= sp;</o:p></span></p><p class=3DMsoNormal><span style=3D'font-size:11.0pt;fo= nt-family:"Calibri","sans-serif";color:#1F497D'>Regards &n= bsp; <o:p= ></o:p></span></p><p class=3DMsoNormal><span style=3D'font-size:11.0pt;font= -family:"Calibri","sans-serif";color:#1F497D'>Mukesh<o:p></o:p></span></p><= p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri","= sans-serif";color:#1F497D'><o:p> </o:p></span></p><div style=3D'border= :none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=3D= MsoNormal><b><span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-ser= if"'>From:</span></b><span style=3D'font-size:10.0pt;font-family:"Tahoma","= sans-serif"'> Rio Asnara [mailto:[email protected]] <br><b>Sent:</b> Tues= day, January 11, 2011 12:12 AM<br><b>To:</b> Mukesh Gupta<br><b>Cc:</b> Kal= yan (Srinivas)Tata; [email protected]; [email protected]; d= [email protected]; [email protected]<br><b>Subject:</b>= Re: [VRRP] AD review of draft-ietf-vrrp-unified-mib<o:p></o:p></span></p><= /div><p class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal style= =3D'margin-bottom:12.0pt'>All,<br>I'm interested to implemented on my virtu= al system :)<br><br>Regards,<br>Asnara<br><br><br><o:p></o:p></p><div><p cl= ass=3DMsoNormal>On Tue, Jan 11, 2011 at 5:56 AM, Mukesh Gupta <<a href= =3D"mailto:[email protected]">[email protected]</a>> wrote:<o:p></o:p>= </p><p class=3DMsoNormal>Kalyan,<br><br>Thanks a lot. Please go ahead= and address the comments and publish<br>the next rev. We all want this dra= ft 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><o:p></o:p></p><div><div><p = class=3DMsoNormal> > wrote:<br><br>> Thanks Adrian for the revie= w. 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:vrrp-b= [email protected]">[email protected]</a> [mailto:<a href=3D"mailto:vrrp-b= [email protected]">[email protected]</a>] On Behalf<br>> Of Adrian Far= rel<br>> Sent: Saturday, January 08, 2011 11:37 AM<br>> To: <a href= =3D"mailto:[email protected]">draft-ietf-vrrp-unif= [email protected]</a><br>> Cc: <a href=3D"mailto:vrrp-chairs@tools.= ietf.org">[email protected]</a>; <a href=3D"mailto:[email protected]">= [email protected]</a><br>> Subject: [VRRP] AD review of draft-ietf-vrrp-unif= ied-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>> revie= w is to catch any nits or issues before the document goes<br>> forward t= o IETF last call and IESG review. By getting these issues<br>> out at th= is stage we can hope for a higher quality review and a<br>> smoother pas= sage 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>> 27= 87, 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 t= o evaluate whether the changes are large enough to<br>> warrant a furthe= r WG last call.<br>><br>> I have moved the draft into "AD-review= :Revised-ID-needed" state in<br>> the datatracker, and I look forwa= rd to seeing the new revision which<br>> 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>> Document: draft-ietf-vrrp-unified-mib-08.txt  = ; July 2010<br>> Intend= ed Status: Proposed Standard<br>> NEW<br>> Document: draft-iet= f-vrrp-unified-mib-08.txt = July 2010<br>> Obsoletes: 2787 (if approved)<br>> Inten= ded Status: Proposed Standard<br>> END<br>><br>> ---<br>><br>&g= t; Abstract<br>><br>> OLD<br>> This specification defines a= Management Information Base (MIB) for<br>> NEW<br>> This spec= ification defines a portion of the Management Information<br>> Ba= se (MIB) for<br>> END<br>><br>> ---<br>><br>> Section 2<br>&= gt;<br>> OLD<br>> This specification defines a Management Info= rmation Base (MIB) for<br>> NEW<br>> This specification define= s a portion of the Management Information<br>> 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 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 sect= ion 3<br>> - say "IPv4 and IPv6" in the two uses in section 6 = and section 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 modul= e" 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>><b= r>> Section 7<br>><br>> Tables in the MIB include the follo= wing:<br>><br>> In fact, there are exactly these three tables, so how= about...<br>><br>> This MIB module contains three tables:<br>= ><br>> ---<br>><br>> Section 8<br>><br>> Trivial, but...<= br>><br>> ----- MIB Tables = For VRRP Router "VR 1": -----<br>><br>> ...should re= ad "VR1"<br>> Similarly for VR2 later in the section.<br>><= br>> ---<br>><br>> IMPORTS<br>><br>> It is helpful, but mand= atory, to show the RFC numbers from which<br>> things are imported. Thus= ...<br>><br>> OLD<br>> IMPORTS<br>> = MODULE-IDENTITY, OBJECT-TYPE,<br>> &= nbsp; NOTIFICATION-TYPE, Counter32,<br>> &nb= sp; Integer32, mib-2, Unsigned32 = FROM SNMPv2-SMI<br>><br>> TE= XTUAL-CONVENTION, RowStatus,<br>> Mac= Address, TruthValue, TimeStamp,<br>> = TimeInterval = FROM SNMPv2-TC<br>><br>> &n= bsp; MODULE-COMPLIANCE, OBJECT-GROUP,<br>> &= nbsp; NOTIFICATION-GROUP &= nbsp; FROM SNMPv2-CONF<br>> &nb= sp; ifIndex = FROM IF-MIB<br>> = InetAddressType, InetAddress FROM= INET-ADDRESS-MIB;<br>> NEW<br>> IMPORTS<br>>= MODULE-IDENTITY, OBJECT-TYPE,<br>> &= nbsp; NOTIFICATION-TYPE, Counter32,<br>><br>= > Integer32, mib-2, Unsigned32<br>>= ; FROM SNMPv2-SMI &= nbsp; = -- RFC2578<br>><br>>  = ; TEXTUAL-CONVENTION, RowStatus,<br>> = MacAddress, TruthValue, TimeStamp,<br>> &nb= sp; TimeInterval<br>> &= nbsp; FROM SNMPv2-TC  = ; -- RFC2579<br>>= <br>> MODULE-COMPLIANCE, OBJECT-GROUP= ,<br>> NOTIFICATION-GROUP<br>> &nb= sp; FROM SNMPv2-CONF  = ; &nb= sp; -- RFC2580<br>><br>> &nb= sp; ifIndex<br>> FROM I= F-MIB = -- RFC2863<br>><br>>= ;<br>> InetAddressType, InetAddress<b= r>> FROM INET-ADDRESS-M= IB; &= nbsp; -- RFC3291<br>> END<br>><br>> ---<br>><br>> Sect= ion 9<br>><br>> In order to ensure that references can be provided, i= t is customary<br>> to begin Section 9 (i.e. before the module BEGIN sta= tement) with<br>> some text such as:<br>><br>> This MIB mod= ule makes reference to the following documents<br>> [RFC2578],<br>> &= nbsp; [RFC2579], [RFC2580], [RFC2863], [RFC3291], and [RFC4001].<br>><br= >> ---<br>><br>> Vrrpv3VrIdTC<br>><br>> Typos<br>> = (ifIndex)and IP version, serves = to uniquely identify a<br>> Missing space.<br>><br>> = REFERENCE " RFC 5798 (Sections 3 and 5.2.3"= <br>> Missing close brace.<br>><br>> ---<br>><br>> vrrpv3Ope= rationsTable<br>><br>> &nbs= p; "Unified Operations table for a VRRP router which<br>> &n= bsp; consists of a sequence (i.e.,= one or more conceptual<br>> &= nbsp; rows) of 'vrrpv3OperationsEntry' items which describe<br>> &= nbsp; the operational chara= cteristics of a virtual router."<br>><br>> I think "which d= escribe" should read "each of which describes"<br>><br>&g= t; ---<br>><br>> vrrpv3OperationsEntry<br>><br>> = Rows in the table cannot be modifi= ed unless the value<br>>  = ; of 'vrrpv3OperStatus' has transitioned to<br>> &nb= sp; 'initialize' state.<br>><br>> I= think a little more precision would help...<br>><br>> = A rows in this table cannot be mod= ified unless the<br>> value<br>> &= nbsp; of 'vrrpv3OperStatus' in the row has transitioned to<br>= > 'initialize' st= ate.<br>><br>> ---<br>><br>> vrrpv3OperationsInetAddrType<br>&g= t;<br>> As far as I can tell, you only support two values: ipv4(1) and i= pv6<br>> (2).<br>> Other values of the InetAddressType textual conven= tions are, I<br>> think, not supported.<br>><br>> You should add t= his fact as a note to the DESCRIPTION clause.<br>><br>> ---<br>><b= r>> vrrpv3OperationsPrimaryIpAddr<br>><br>> &= nbsp; "In the case where there are more than one = IP<br>><br>> s/are/is/<br>><br>> ---<br>><br>> vrrpv3Oper= ationsVirtualMacAddr<br>><br>> REF= ERENCE "STD 58 RFC 2578"<br>><br>> I am not clear why this = reference is cited. MacAddress is defined in<br>> RFC 2579, but you don'= t need to provide a reference because that is<br>> implicit in the IMPOR= TS clause. Perhaps you mean to give a reference<br>> to where the mappin= g 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>> d= ocument.<br>><br>> ---<br>><br>> vrrpv3OperationsAcceptMode<br>= ><br>> "Control= s whether a virtual router in Master state<br>> &nb= sp; will accept packets addressed to the address owner= 's<br>> IPv6 address as= its own if it is not the IPv6 address<br>> = owner. Default is False.<br>> &= nbsp; This object is not relevant for rows repr= esenting VRRP<br>> over= IPv4 and should be set to false."<br>><br>> Should read...<br>&= gt;<br>> Default is false(2)<br>><br>> ...and...<br>><br= >> should be set to false(2)."<br>><br>> ---<br>><b= r>> vrrpv3OperationsUpTime<br>> SY= NTAX TimeStamp<br>> &nb= sp; MAX-ACCESS read-only<br>> = STATUS current<br>> &nb= sp; DESCRIPTION<br>> &q= uot;This is the value of the `sysUpTime' object when this<br>> &n= bsp; virtual router (i.e., the `vrrpv3Op= erStatus')<br>> transit= ioned out of `initialized'."<br>><br>> I am not saying that you = MUST change this, but I wonder how useful<br>> it is, because to make se= nse 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 perfor= m a computation each the row<br>> is read. If you did this you would hav= e...<br>><br>> SYNTAX  = ; TimeTicks<br>> MAX-ACCESS &n= bsp; read-only<br>> STATUS &nb= sp; current<br>> DESCRIP= TION<br>> "This va= lue represents the amount of time since this<br>> &= nbsp; virtual router (i.e., the `vrrpv3OperStatus')<br= >> transitioned out of = `initialize'."<br>><br>> I just need you to think about which yo= u prefer (there is a trade-<br>> off) and make a decision. No need to te= ll me which you chose, or why.<br>><br>> Note also s/initialized/init= ialize/<br>><br>> ---<br>><br>> Creation and deletion of a vrrp= v3OperationsTable row<br>><br>> I'm slightly confused :-(<br>><br>= > We have...<br>><br>> vrrpv3OperationsEntry<= br>><br>> Rows= in the table cannot be modified unless the value<br>><br>> &n= bsp; of 'vrrpv3OperStatus' has tra= nsitioned to<br>>  = ;'initialize' state.<br>><br>> and<br>><br>> &nbs= p; vrrpv3OperationsRowStatus<br>><br>> &n= bsp; When `vrrpv3OperationsRowStatus' is set to<br>>  = ; active(1), no other objects in = the conceptual row can<br>> &n= bsp; be modified.<br>><br>> In general, the instructions in the descr= iption of the rowStatus are<br>> good an detailed. But I have some diffi= culty with row creation. What<br>> I think is missing is a statement tha= t 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 tran= sitioned to active(1).<br>><br>> Similarly, there is an issue with ro= w 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 d= escription of operStatus, I cannot<br>> modify the row (including the ro= wStatus) until operStatus has gone<br>> to initialize(1). How do I get t= hat to happen?<br>><br>> I suspect this can be fixed by allowing rowS= tatus to be changed<br>> regardless of the value of operStatus.<br>><= br>> ---<br>><br>> vrrpv3AssociatedIpAddrTable<br>><br>> &nb= sp; "The table of addresses = associated with this virtual<br>> &nb= sp; router."<br>><br>> I think that there is just o= ne table, and it contains the addresses<br>> of all virtual routers. Wha= t about...<br>><br>> = "The table of addresses associated with each virtual<br>> &= nbsp; router."<br>><br>>= ; ---<br>><br>> vrrpv3AssociatedIpAddrEntry<br>><br>> OLD<br>&g= t; Rows in the table canno= t be modified unless the value<br>> &= nbsp; of `vrrpv3OperStatus' has transitioned to<br>>  = ; `initialize'.<br>> NEW<br>> &nbs= p; Rows in the table cannot be mo= dified unless the value<br>> &= nbsp; of `vrrpv3OperStatus' for the corresponding entry in the<br>> &nbs= p; vrrpv3OperationsTable has tran= sitioned 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 nee= d:<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 vrrpv3OperationsInetAd= drType in the index of this row.<br>><br>> ---<br>><br>> VRRP R= outer Statistics<br>><br>> Do you need a discontinuity timer for the = three global objects:<br>> - vrrpv3RouterChecksumErrors<br>> - vrrpv3= RouterVersionErrors<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 Count= r32 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>> = "The total number of = VRRP packets received with an<br>> &n= bsp; invalid VRID for this virtual router."<br>><br>> Thi= s object is global, so it is wider than the scope of a single VR.<br>> I= think you need:<br>><br>> = "The total number of VRRP packets received with a<br>>  = ; VRID that is not valid for any = virtual router on this<br>> &n= bsp; router."<br>><br>> ---<br>><br>> vrrpv3StatisticsAdvI= ntervalErrors<br>><br>> &nb= sp; "The total number of VRRP advertisement packets<br>> &nb= sp; received for which the advertisement= interval is<br>> diffe= rent than the one configured for the local virtual<br>> &n= bsp; router.<br>><br>> Can you add a refe= rence to vrrpv3OperationsAdvInterval<br>><br>> ---<br>><br>> vr= rpv3ProtoError<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<br>&g= t; 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<br>> management agent which will identi= fy the physical router that<br>> sourced the notification, but not the V= R.<br>><br>> Don't you need to add some index values to the notificat= ions as well?<br>><br>> ---<br>><br>> Section 11<br>><br>>= ; Since you are obsoleting RFC 2787, is it your intention to ask IANA<br>&g= t; to deprecate {mib-2 68} ?<br>><br>> ---<br>><br>> Would you = please consider adding<br>><br>> ---<br>><br>> Section 12<br>&g= t;<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 p= lease 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]">vrrp@i= etf.org</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= >> 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"_blank">https://www.ietf.org/mail= man/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">h= ttps://www.ietf.org/mailman/listinfo/vrrp</a><o:p></o:p></p></div></div></d= iv><p class=3DMsoNormal><o:p> </o:p></p></div></body></html>= --_000_497B6D90E0023142AF34948DEFFAB38D3B35815809EMBX01HQjnprn_-- --===============1134359193== 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 --===============1134359193==--