Definition of Managed Objects for the Optimized Link State Routing Protocol Version 2
draft-ietf-manet-olsrv2-mib-12
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2014-04-08
|
12 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2014-03-19
|
12 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2014-02-26
|
12 | (System) | RFC Editor state changed to RFC-EDITOR from REF |
2014-01-13
|
12 | (System) | RFC Editor state changed to REF from EDIT |
2013-12-02
|
12 | (System) | RFC Editor state changed to EDIT from MISSREF |
2013-07-03
|
12 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2013-07-03
|
12 | (System) | IANA Action state changed to Waiting on RFC Editor from Waiting on Authors |
2013-07-02
|
12 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2013-07-02
|
12 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2013-06-27
|
12 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2013-06-26
|
12 | Cindy Morgan | State changed to RFC Ed Queue from Approved-announcement sent |
2013-06-26
|
12 | (System) | RFC Editor state changed to MISSREF |
2013-06-26
|
12 | (System) | Announcement was received by RFC Editor |
2013-06-25
|
12 | (System) | IANA Action state changed to In Progress |
2013-06-25
|
12 | (System) | IANA Action state changed to In Progress |
2013-06-25
|
12 | Cindy Morgan | State changed to Approved-announcement sent from Approved-announcement to be sent |
2013-06-25
|
12 | Cindy Morgan | IESG has approved the document |
2013-06-25
|
12 | Cindy Morgan | Closed "Approve" ballot |
2013-06-25
|
12 | Cindy Morgan | Ballot approval text was generated |
2013-06-25
|
12 | Adrian Farrel | State changed to Approved-announcement to be sent from Approved-announcement to be sent::AD Followup |
2013-06-25
|
12 | Adrian Farrel | Ballot approval text was generated |
2013-06-25
|
12 | Adrian Farrel | Ballot writeup was changed |
2013-06-24
|
12 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2013-06-24
|
12 | Ulrich Herberg | New version available: draft-ietf-manet-olsrv2-mib-12.txt |
2013-06-24
|
11 | Adrian Farrel | Additional working group review completed with no further comments, but the MIB Doctor has raised a couple of further concerns. |
2013-06-24
|
11 | Adrian Farrel | State changed to Approved-announcement to be sent::Revised I-D Needed from Approved-announcement to be sent::External Party |
2013-06-13
|
11 | Adrian Farrel | Final check with working group on latest set of changes |
2013-06-13
|
11 | Adrian Farrel | State changed to Approved-announcement to be sent::External Party from Approved-announcement to be sent::AD Followup |
2013-06-12
|
11 | Ulrich Herberg | New version available: draft-ietf-manet-olsrv2-mib-11.txt |
2013-06-09
|
10 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2013-06-09
|
10 | Robert Cole | New version available: draft-ietf-manet-olsrv2-mib-10.txt |
2013-06-07
|
09 | Tero Kivinen | Closed request for Last Call review by SECDIR with state 'No Response' |
2013-05-30
|
09 | Cindy Morgan | State changed to Approved-announcement to be sent::Revised I-D Needed from IESG Evaluation - Defer |
2013-05-30
|
09 | Benoît Claise | [Ballot Position Update] Position for Benoit Claise has been changed to Yes from No Objection |
2013-05-30
|
09 | Spencer Dawkins | [Ballot comment] I'm a No Objection, but I am somewhat confused about the Security Considerations section, which if I'm reading it correctly can be summarized … [Ballot comment] I'm a No Objection, but I am somewhat confused about the Security Considerations section, which if I'm reading it correctly can be summarized as - this protocol is often used in tactical applications where, if you screw up security, people can die - older versions of SNMP had security problems - SNMPv3 is RECOMMENDED, but not REQUIRED Am I misreading the text? Is it obvious to users of the protocol (and the related MIB) what the tradeoffs are? I'm assuming this isn't intended to be "SNMPv3 is RECOMMENDED unless you already have a working SNMPv2c implementation and you'd rather spend engineering resources on something else" :D |
2013-05-30
|
09 | Spencer Dawkins | [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins |
2013-05-30
|
09 | Adrian Farrel | Ballot writeup was changed |
2013-05-30
|
09 | Gonzalo Camarillo | [Ballot Position Update] New position, No Objection, has been recorded for Gonzalo Camarillo |
2013-05-30
|
09 | Stephen Farrell | [Ballot comment] - intro: I think section 9 is important here and could be either moved up or else maybe add a sentence to the … [Ballot comment] - intro: I think section 9 is important here and could be either moved up or else maybe add a sentence to the intro saying that section 9 tells you when this might be useful/reasonable. - WillingnessTC - Nice. Should you add "happy to throw car-keys into the bowl" as well? Even nicer, you then say: "The williness ranges..." Please make no change so as to amuse future RFC readers who're as easily amused by adolescent word-play as me:-) (BTW, I also doubt that this'll be very useful since its too fine-grained but will be happy and interested to hear if your experience shows me to be wrong.) - p12, s/HNDP/NHDP/ ? - p21, repeated text in the definition of olsrv2FHoldTime and how is someone writing this value supposed to know the time require to traverse the MANET? - p46 (and elsewhere): 16777215 is a LOT. Makes me wonder if there's a DoS vector there somewhere. - p77 s/privacy/confidentiality/ but does SNMP security even do that? (Sorry, didn't have time to check.) |
2013-05-30
|
09 | Stephen Farrell | [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell |
2013-05-29
|
09 | Pete Resnick | [Ballot Position Update] New position, No Objection, has been recorded for Pete Resnick |
2013-05-29
|
09 | Richard Barnes | [Ballot Position Update] New position, No Objection, has been recorded for Richard Barnes |
2013-05-29
|
09 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko |
2013-05-29
|
09 | Benoît Claise | [Ballot comment] The list of comments is the ongoing discussion points between the MIB doctor, the authors, and myself. For documentation purposes only before the … [Ballot comment] The list of comments is the ongoing discussion points between the MIB doctor, the authors, and myself. For documentation purposes only before the IESG telechat, while the good discussion continues via email. 1. 6.2. Relationship to the NHDP-MIB OLSRv2 depends on the neighborhood information that is discovered by [RFC6130]. In order to access the Objects relating to discovered neighbors, the State Group tables of the NHDP-MIB [RFC6779] module are aligned with this MIB module. This is accomplished through the use of the AUGMENTS capability of SMIv2 and the definition of TEXTUAL-CONVENTIONS in the NHDP-MIB module: specifically the NeighborRouterIndex. These object types are used to develop indexes into common NHDP-MIB module and routing protocol State Group tables. The values of these objects and the semantics of each individual value SHOULD be identical for the two MIB modules within a given SNMP context. This will allow for improved cross referencing of information across the two MIB modules within a given SNMP context. Clarify what the "The values of these objects" is: 2. Checking nits according to http://www.ietf.org/id-info/checklist : ------------------------------------------------------------------- ** There is 1 instance of lines with control characters in the document. - Most probably, the RFC editors will pick that up, but since I spotted it. In the following, replace RFCYYYY -> RFC YYYY RFCXXXX -> RFC XXXX * 1) The reference to RFCYYYY within the DESCRIPTION clauses * * of the MIB module point to this draft and are to be * * assigned by the RFC Editor. * * * * 2) The reference to RFCXXXX throughout this document point * * to the current draft-ietf-manet-olsrv2-xx.txt. This * * needs to be replaced with the XXXX RFC number for the * * OLSRv2 publication. * 3. Issue RMP-012 Location olsrv2THoldTime OBJECT-TYPE olsrv2AHoldTime OBJECT-TYPE Issue: Since this is required to be fit the constraints of the exponent-mantissa notation in RFC 5497, the syntax should at least constrain the range. With "C" nailed down as 1/1024 second, rather than the 1/1000 second interval the object type is defined in terms of, the permitted values for this object are: 125, 250, 375, 500, 625, 750, 875, 1000, 1125, 1250, 1375, 1500, 1625, 1750, 1875, 2000, 2250, 2500, 2750, 3000, 3250, 3500, 3750, 4000, 4500, 5000, 5500, 6000, 6500, 7000, 7500, 8000, 9000, 10000, 11000, 12000, 13000, 14000, 15000, 16000, 18000, 20000, 22000, 24000, 26000, 28000, 30000, 32000, 36000, 40000, 44000, 48000, 52000, 56000, 60000, and so on up to 3,932,160 (I think). My concern is whether the operator of a management system will be able to guess/calculate these values on the fly, and whether they might be astonished to discover that this object can be set to 28, 30, 32, and 36 seconds, but not 34. Suggestion: this seems to be a candidate for a textual convention, possibly punting on the upper reaches, but being explicit at least up to 60 seconds or so. 4. Issue RMP-033 Location: throughout the MIB module Issue: labels from the OLSRv2 specification are widely used in DESCRIPTIONS, without a key identifying the OBJECT-TYPEs to which they correspond. Not sure what they refer to, I haven't investigated whether they are correct. Specific examples: Location: olsrv2IibLinkSetEntry OBJECT-TYPE Text: (L_in_metric, L_out_metric, L_mpr_selector)" Location: olsrv2IibLinkSetInMetric OBJECT-TYPE Text: L_neighbor_iface_addr_list Location: olsrv2IibLinkSetOutMetric OBJECT-TYPE Text: L_neighbor_iface_addr_list Location: olsrv2Iib2HopSetEntry OBJECT-TYPE Text: (N2_in_metric, N2_out_metric)" Location: olsrv2Iib2HopSetInMetric OBJECT-TYPE Text: N2_2hop_iface_addr, N2_neighbor_iface_addr_list. Location: olsrv2Iib2HopSetOutMetric OBJECT-TYPE Text: N2_2hop_iface_addr, N2_neighbor_iface_addr_list. Location: olsrv2LibOrigSetEntry OBJECT-TYPE Text: (O_orig_addr, O_time)" Location: olsrv2LibLocAttNetSetEntry OBJECT-TYPE Text: (AL_net_addr, AL_dist, AL_metric) Location: olsrv2LibLocAttNetSetMetric OBJECT-TYPE Text: AL_net_addr Location: olsrv2NibNeighborSetEntry OBJECT-TYPE Text: N_orig_addr N_in_metric N_out_metric N_will_flooding N_will_routing N_flooding_mpr N_routing_mpr N_mpr_selector N_advertised Location: olsrv2NibNeighborSetNAdvertised OBJECT-TYPE Text: N_mpr_selector Location: olsrv2TibAdRemoteRouterSetEntry OBJECT-TYPE Text: (AR_orig_addr, AR_seq_number, AR_time) Location: olsrv2TibRouterTopologySetEntry OBJECT-TYPE Text: " (TR_from_orig_addr, TR_to_orig_addr, TR_seq_number, TR_metric, TR_time)" Location: olsrv2TibRouterTopologySetFromOrigIpAddr OBJECT-TYPE Text: TR_to_orig_addr Location: olsrv2TibRouterTopologySetToOrigIpAddr OBJECT-TYPE Text: TR_to_orig_addr Location: olsrv2TibRouterTopologySetSeqNo OBJECT-TYPE Text: TR_from_orig_addr Location: olsrv2TibRouterTopologySetMetric OBJECT-TYPE Text: TR_from_orig_addr TR_to_orig_addr." Location: olsrv2TibRoutableAddressTopologySetEntry OBJECT-TYPE Text: (TA_from_orig_addr, TA_dest_addr, TA_seq_number, TA_metric, TA_time)" Location: olsrv2TibRoutableAddressTopologySetFromOrigIpAddr OBJECT-TYPE Text: TA_dest_addr Location: olsrv2TibRoutableAddressTopologySetDestIpAddr OBJECT-TYPE Text: TA_from_orig_addr Location: olsrv2TibRoutableAddressTopologySetSeqNo OBJECT-TYPE Text: TA_from_orig_addr Location: olsrv2TibRoutableAddressTopologySetMetric OBJECT-TYPE Text: TA_from_orig_addr Location: olsrv2TibAttNetworksSetEntry OBJECT-TYPE Text: (AN_orig_addr, AN_net_addr, AN_seq_number, AN_dist, AN_metric, AN_time)" Location: olsrv2TibAttNetworksSetOrigIpAddr OBJECT-TYPE Text: AN_net_addr." Location: olsrv2TibAttNetworksSetNetIpAddr OBJECT-TYPE Text: AN_orig_addr." Location: olsrv2TibAttNetworksSetSeqNo OBJECT-TYPE Text: AN_orig_addr" Location: olsrv2TibAttNetworksSetDist OBJECT-TYPE Text: AN_net_addr AN_orig_addr." Location: olsrv2TibAttNetworksSetMetric OBJECT-TYPE Text: AN_orig_addr AN_net_addr." Suggestion: assuming these are useful links into the OLSRv2 specification, I suggest accompanying each one with the label of the corresponding object-type from the mib module. 5. Issue RMP-036 Location: olsrv2LinkMetricType OBJECT-TYPE Issue: With the allocation of metric types under IANA control, it may make sense to define a textual convention (spun off into an IANA-maintained MIB module) to support metric type selection. 6. Issue RMP-056 Issue: In some cases the indexing structure does not appear to provide any support for intelligent retrieval of table contents. Did the working group go through the use cases they intended these tables to support to determine whether the indexing structure made sense? |
2013-05-29
|
09 | Benoît Claise | [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise |
2013-05-25
|
09 | Robert Cole | New version available: draft-ietf-manet-olsrv2-mib-09.txt |
2013-05-13
|
08 | Barry Leiba | [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba |
2013-05-09
|
08 | Benoît Claise | Telechat date has been changed to 2013-05-30 from 2013-05-16 |
2013-05-09
|
08 | Benoît Claise | State changed to IESG Evaluation - Defer from IESG Evaluation |
2013-05-09
|
08 | Sean Turner | [Ballot comment] Thanks for being so quick to resolve my discuss. |
2013-05-09
|
08 | Sean Turner | [Ballot Position Update] Position for Sean Turner has been changed to No Objection from Discuss |
2013-05-09
|
08 | Sean Turner | [Ballot discuss] Revised (I think this might just be a ctrl-x/ctrl-v issue but was asked to provide a little more rationale on my discuss) The … [Ballot discuss] Revised (I think this might just be a ctrl-x/ctrl-v issue but was asked to provide a little more rationale on my discuss) The 2nd to last paragraph in this document: It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], Section 8, including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). differs somewhat from what I thought was last agreed with the MIB doctors (and what's in RFC 6779): Implementations SHOULD provide the security features described by the SNMPv3 framework (see [RFC3410]), and implementations claiming compliance to the SNMPv3 standard MUST include full support for authentication and privacy via the User-based Security Model (USM) [RFC3414] with the AES cipher algorithm [RFC3826]. Implementations MAY also provide support for the Transport Security Model (TSM) [RFC5591] in combination with a secure transport such as SSH [RFC5592] or TLS/DTLS [RFC6353]. My primary issue here is that a requirement to "consider" is not the same an MTI (mandatory to implement). Further, the RFC 3414 mechanisms referred to in RFC 3410 for authentication are HMAC-based and for privacy are CBC-DES-based. Don't really have a problem with the authentication protocols (see RFC 6151 and 6194) but I do have a really big problem with the CBC-DES-based privacy mechanism. The reworded boiler plate takes in to account the AES-based privacy mechanism RFC 3414 refers to as a draft. I can not believe you'd really use a DES-based mechanism instead of the AES-based mechanism and if you are I'd like to see some text about that. The bit about the TSM is a nod to reality about how the data will be gathered. I'm guessing here but I suspect that SSH is used with the router so you could just say SSH is required as opposed to the current wishy washy one or the approach in the new boiler plate. |
2013-05-09
|
08 | Sean Turner | Ballot discuss text updated for Sean Turner |
2013-05-09
|
08 | Ulrich Herberg | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2013-05-09
|
08 | Ulrich Herberg | New version available: draft-ietf-manet-olsrv2-mib-08.txt |
2013-05-09
|
07 | Sean Turner | [Ballot discuss] Any reason this one doesn't have the boilerplate: https://svn.tools.ietf.org/area/ops/trac/wiki/mib-security Isn't the 2nd to last paragraph missing for the security considerations? |
2013-05-09
|
07 | Sean Turner | [Ballot Position Update] New position, Discuss, has been recorded for Sean Turner |
2013-05-09
|
07 | Stewart Bryant | [Ballot Position Update] New position, No Objection, has been recorded for Stewart Bryant |
2013-05-08
|
07 | Brian Haberman | [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman |
2013-05-03
|
07 | Alexey Melnikov | Request for Telechat review by GENART Completed: Ready. Reviewer: Alexey Melnikov. |
2013-05-03
|
07 | Alexey Melnikov | Request for Telechat review by GENART Completed: Ready with Nits. Reviewer: Alexey Melnikov. |
2013-05-02
|
07 | Jean Mahoney | Request for Telechat review by GENART is assigned to Alexey Melnikov |
2013-05-02
|
07 | Jean Mahoney | Request for Telechat review by GENART is assigned to Alexey Melnikov |
2013-05-02
|
07 | Martin Stiemerling | [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling |
2013-04-30
|
07 | Joel Jaeggli | [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli |
2013-04-30
|
07 | (System) | IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed |
2013-04-30
|
07 | Adrian Farrel | State changed to IESG Evaluation from Waiting for AD Go-Ahead::AD Followup |
2013-04-30
|
07 | Adrian Farrel | Placed on agenda for telechat - 2013-05-16 |
2013-04-30
|
07 | Adrian Farrel | Changed consensus to Yes from Unknown |
2013-04-30
|
07 | Adrian Farrel | Ballot has been issued |
2013-04-30
|
07 | Adrian Farrel | [Ballot Position Update] New position, Yes, has been recorded for Adrian Farrel |
2013-04-30
|
07 | Adrian Farrel | Created "Approve" ballot |
2013-04-29
|
07 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2013-04-29
|
07 | Ulrich Herberg | New version available: draft-ietf-manet-olsrv2-mib-07.txt |
2013-04-28
|
06 | Adrian Farrel | Small changes to address performance directorate review. |
2013-04-28
|
06 | Adrian Farrel | State changed to Waiting for AD Go-Ahead::Revised I-D Needed from Waiting for AD Go-Ahead |
2013-04-23
|
06 | (System) | State changed to Waiting for AD Go-Ahead from In Last Call |
2013-04-13
|
06 | (System) | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2013-04-13
|
06 | Amanda Baber | IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-manet-olsrv2-mib-06. Authors should review the comments and/or questions below. Please report any inaccuracies and respond to any questions as soon … IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-manet-olsrv2-mib-06. Authors should review the comments and/or questions below. Please report any inaccuracies and respond to any questions as soon as possible. IANA understands that, upon approval of this document, there is a single action which IANA must complete. In the SMI Network Management MGMT Codes Internet-standard MIB (iso.org.dod.internet.mgmt.mib-2) sub-registry of the Network Management Parameters registry located at: http://www.iana.org/assignments/smi-numbers a new MIB will be registered as follows: Decimal: [ TBD by IANA at time of registration ] Name: OLSRv2-MIB Description: Optimized Link State Routing Protocol version 2 References: [ RFC-to-be ] IANA understands this to be the only action required of IANA upon approval of this document. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed. |
2013-04-12
|
06 | Jean Mahoney | Request for Last Call review by GENART is assigned to Alexey Melnikov |
2013-04-12
|
06 | Jean Mahoney | Request for Last Call review by GENART is assigned to Alexey Melnikov |
2013-04-11
|
06 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Ondřej Surý |
2013-04-11
|
06 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Ondřej Surý |
2013-04-09
|
06 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2013-04-09
|
06 | Amy Vezza | The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Subject: Last Call: (Definition of Managed Objects for the … The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Subject: Last Call: (Definition of Managed Objects for the Optimized Link State Routing Protocol version 2) to Proposed Standard The IESG has received a request from the Mobile Ad-hoc Networks WG (manet) to consider the following document: - 'Definition of Managed Objects for the Optimized Link State Routing Protocol version 2' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-04-23. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines the Management Information Base (MIB) module for configuring and managing the Optimized Link State Routing protocol version 2 (OLSRv2). The OLSRv2-MIB module is structured into state information, performance metrics, and notifications. This additional state and performance information is useful to troubleshoot problems and performance issues of the routing protocol. Different levels of compliance allow implementers to use smaller subsets of all defined objects, allowing for this MIB module to be deployed on more constrained routers. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-mib/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-mib/ballot/ No IPR declarations have been submitted directly on this I-D. |
2013-04-09
|
06 | Amy Vezza | State changed to In Last Call from Last Call Requested |
2013-04-09
|
06 | Adrian Farrel | Last call was requested |
2013-04-09
|
06 | Adrian Farrel | Ballot approval text was generated |
2013-04-09
|
06 | Adrian Farrel | State changed to Last Call Requested from AD Evaluation::Point Raised - writeup needed |
2013-04-09
|
06 | Adrian Farrel | Last call announcement was changed |
2013-04-09
|
06 | Adrian Farrel | Last call announcement was generated |
2013-04-08
|
06 | Ulrich Herberg | New version available: draft-ietf-manet-olsrv2-mib-06.txt |
2013-04-02
|
05 | Adrian Farrel | State changed to AD Evaluation::Point Raised - writeup needed from AD Evaluation |
2013-04-02
|
05 | Adrian Farrel | Further AD review comment ==== Ooops, I just ran idnits. Looks like the references are in a bit of a mess as well. [OLSRv2] … Further AD review comment ==== Ooops, I just ran idnits. Looks like the references are in a bit of a mess as well. [OLSRv2] Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg, "The Optimized Link State Routing Protocol version 2", draft-ietf-manet-olsr-17 (work in progress), October 2012. *** should read draft-ietf-manet-olsrv2 Do you really need a normative reference to RFC 3781? This is a Downref (which we can handle if necessary), but I don't see why it is referenced. Because these both show as Downrefs, and because Downrefs get called out in IETF last call, I need an answer to these points before I can go forward. If answering them involves respinning the document, then it would be good to pick up the other points as well. Thanks, Adrian |
2013-04-02
|
05 | Adrian Farrel | Last call announcement was changed |
2013-04-02
|
05 | Adrian Farrel | Last call announcement was generated |
2013-04-02
|
05 | Adrian Farrel | Last call announcement was generated |
2013-04-02
|
05 | Adrian Farrel | Ballot writeup was changed |
2013-04-02
|
05 | Adrian Farrel | Ballot writeup was generated |
2013-04-02
|
05 | Adrian Farrel | AD Review ==== Thanks for your work on this document, and sorry for the long time it has taken me to review it. it looks … AD Review ==== Thanks for your work on this document, and sorry for the long time it has taken me to review it. it looks like you have done a really thorough job - I can normally pick a few holes in a MIB I think the only big question we are going to get (again) is about the level of write (and create) access. Do you think that it would be helpful to add an Informational reference to draft-nguyen-manet-management-00 and some discussion in the document about why you have some level of write access? Maybe this is just a little more text in Section 9. I think you should think about this while I run the IETF last call. That will attract an OPS Dir review that may dwell on the point further. --- My other comments are quite small and can all be taken as IETF last call comments to be fixed later... The RFC Editor might become confused by the different uses of "XXXX" in the document. It would be worth sorting them out just to make life easier. --- Tiny point... In olsrv2AHoldTime you have... a value = 3 x olsrv2TcInterval is recommended. But in draft-ietf-manet-olsrv2-15 you have a value >= 3 x TC_INTERVAL is RECOMMENDED. --- I think olsrv2LinkMetricType needs to be mentioned in Section 8 because, according to Section 5.5 of draft-ietf-manet-olsrv2-19, the consequences of a change are quite significant. --- Possibly just me being puzzled: Are you sure that olsrv2TibRoutableAddressTopologySetIndex can really be limited to Integer32 (0..65535)? I agree that larger would be a great validation of OLSRv2, but I wondered how quickly we might reach that threshold. Ditto olsrv2TibRouterTopologySetIndex |
2013-03-09
|
05 | Adrian Farrel | State changed to AD Evaluation from Publication Requested |
2013-03-04
|
05 | Cindy Morgan | Changes are expected over time. This version is dated January 9, 2013. (1.a) Stan Ratliff (sratliff@cisco.com) is the document shepherd for this document. … Changes are expected over time. This version is dated January 9, 2013. (1.a) Stan Ratliff (sratliff@cisco.com) is the document shepherd for this document. The shepherd has personally reviewed the document, and believes it is ready for forwarding to the IESG for publication. (1.b) The document has had adequate review from both key working group members and from key non-WG members. The shepherd does not have any concerns about the depth or breadth of the reviews that have been performed. (1.c) The shepherd does not have any concerns about the document needing additional review. (1.d) The shepherd does not have any concerns or issues with the document that the responsible Area Director or the IESG need to be aware of. IPR disclosures were not necessary, therefore, none have been filed. (1.e) Working group consensus behind this document is solid. The document represents strong concurrence of the working group as a whole, the the WG understands and agrees with the document. (1.f) No one has threatened appeal or has indicated discontent with the document. (1.g) The document shepherd has run the "idnits" tool against the document. The document has met all required formal review criteria. (1.h) The document has split its references into normative and informative. There is a normative reference to draft-ietf-manet-olsrv2-17, which is currently in IESG evaluation, with one DISCUSS but enough votes to pass, once the DISCUSS is resolved. The shepard is confident that OLSRv2 will be published soon. Other than that, to the shepherd's knowledge, there are no normative references to documents that are not ready for advancement or are in an unclear state. There are no downward references. (1.i) The shepherd has verified that document IANA consideration section exists, and is consistent with the body of the document. No protocol extensions are requested. The necessary IANA registries are clearly defined. No new registries are requested. No expert review has been requested. (1.j) The document has been run through the "smilint" checker. Warnings exist due to references to "FLOAT-TC-MIB", however, those references appear to be due to a deficiency of the tool (e.g., RFC6340 is 'too new' to be in view by the tool). (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This document defines a portion of the Management Information Base (MIB) for use with the Optimized Link State Routing Protocol version 2 developed in the MANET working group. Working Group Summary The process for reaching working group consensus on this was smooth; no controversy existed. Working group consensus behind the document is solid. Document Quality This document shepherd is not aware of existing implementations of this MIB. Review by MIB doctor was discussed within the working group, however, the WG consensus was that this review was unnecessary, as the WG contains sufficient expertise to determine applicability of all objects, and correctness of the MIB. |
2013-03-04
|
05 | Cindy Morgan | Note added 'Stan Ratliff (sratliff@cisco.com) is the document shepherd.' |
2013-03-04
|
05 | Adrian Farrel | Intended Status changed to Proposed Standard |
2013-03-04
|
05 | Adrian Farrel | IESG process started in state Publication Requested |
2013-03-04
|
05 | (System) | Earlier history may be found in the Comment Log for draft-cole-manet-olsrv2-mib |
2013-03-04
|
05 | Adrian Farrel | Shepherding AD changed to Adrian Farrel |
2013-03-04
|
05 | Ulrich Herberg | Changed protocol writeup |
2013-02-28
|
05 | Joseph Macker | IETF WG state changed to WG Consensus: Waiting for Write-Up from WG Consensus: Waiting for Write-Up |
2013-02-28
|
05 | Joseph Macker | IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call |
2012-12-04
|
05 | Stan Ratliff | IETF state changed to In WG Last Call from WG Document |
2012-11-05
|
05 | Stan Ratliff | Document entering WGLC. There will be a 2-week last-call period, ending on 12/28/2012 |
2012-11-05
|
05 | Robert Cole | New version available: draft-ietf-manet-olsrv2-mib-05.txt |
2012-05-11
|
04 | Ulrich Herberg | New version available: draft-ietf-manet-olsrv2-mib-04.txt |
2011-07-06
|
03 | (System) | Document has expired |
2011-01-02
|
03 | (System) | New version available: draft-ietf-manet-olsrv2-mib-03.txt |
2010-07-12
|
02 | (System) | New version available: draft-ietf-manet-olsrv2-mib-02.txt |
2009-11-09
|
01 | (System) | New version available: draft-ietf-manet-olsrv2-mib-01.txt |
2009-05-12
|
00 | (System) | New version available: draft-ietf-manet-olsrv2-mib-00.txt |