Proxy Mobile IPv6 Management Information Base
RFC 6475
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2020-01-21 |
08 | (System) | Received changes through RFC Editor sync (added Verified Errata tag) |
2015-10-14 |
08 | (System) | Notify list changed from netlmm-chairs@ietf.org, draft-ietf-netlmm-pmipv6-mib@ietf.org, jonne.soininen@renesasmobile.com to (None) |
2013-02-13 |
08 | Martin Stiemerling | Request for Last Call review by TSVDIR Completed: Ready. Reviewer: Martin Stiemerling. |
2012-08-22 |
08 | (System) | post-migration administrative database adjustment to the No Objection position for Sean Turner |
2012-08-22 |
08 | (System) | post-migration administrative database adjustment to the Yes position for Dan Romascanu |
2012-08-22 |
08 | (System) | post-migration administrative database adjustment to the No Objection position for Stephen Farrell |
2012-08-22 |
08 | (System) | post-migration administrative database adjustment to the No Objection position for Adrian Farrel |
2012-05-08 |
08 | (System) | RFC published |
2012-04-10 |
08 | Brian Haberman | Responsible AD changed to Brian Haberman from Jari Arkko |
2011-11-28 |
08 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2011-11-23 |
08 | (System) | IANA Action state changed to Waiting on RFC Editor from Waiting on Authors |
2011-11-22 |
08 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2011-11-22 |
08 | (System) | IANA Action state changed to In Progress |
2011-11-22 |
08 | Cindy Morgan | State changed to RFC Ed Queue from Approved-announcement sent. |
2011-11-22 |
08 | Amy Vezza | IESG state changed to Approved-announcement sent |
2011-11-22 |
08 | Amy Vezza | IESG has approved the document |
2011-11-22 |
08 | Amy Vezza | Closed "Approve" ballot |
2011-11-22 |
08 | Amy Vezza | Approval announcement text regenerated |
2011-11-22 |
08 | Amy Vezza | Ballot writeup text changed |
2011-11-22 |
08 | Jari Arkko | State changed to Approved-announcement to be sent from IESG Evaluation::AD Followup. |
2011-10-25 |
08 | Dan Romascanu | [Ballot Position Update] Position for Dan Romascanu has been changed to Yes from Discuss |
2011-10-25 |
08 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2011-10-25 |
08 | (System) | New version available: draft-ietf-netlmm-pmipv6-mib-08.txt |
2011-10-17 |
08 | Jari Arkko | State changed to IESG Evaluation::Revised ID Needed from IESG Evaluation::AD Followup. |
2011-10-17 |
08 | Jari Arkko | Sent a request for the authors to make an update of the draft. We only need to solve Dan's issues and we could approve the … Sent a request for the authors to make an update of the draft. We only need to solve Dan's issues and we could approve the document. |
2011-10-07 |
08 | Stephen Farrell | [Ballot comment] The secdir review identified that we might want to update the boilerplate security considerations a bit - do we want to do that … [Ballot comment] The secdir review identified that we might want to update the boilerplate security considerations a bit - do we want to do that now? (This is really for the OAM^h^h^hOPS ADs:-) "RFC 3826 details how to use AES with SNMPv3. Again, this never made it into the boilerplate. Perhaps some new enthusiastic ADs get engaged to revise the boilerplate? ;-)" The SEC and OPS ADs should come back to this. |
2011-10-07 |
08 | Stephen Farrell | [Ballot Position Update] Position for Stephen Farrell has been changed to No Objection from Discuss |
2011-09-27 |
08 | Dan Romascanu | [Ballot discuss] (revised after the publication of draft-7) The DISCUSS is based in part on the MIB Doctor review performed by Harrie Hazewinkel 1. (cleared) … [Ballot discuss] (revised after the publication of draft-7) The DISCUSS is based in part on the MIB Doctor review performed by Harrie Hazewinkel 1. (cleared) 2. The definition of the TC is not in the document, but yet it needs being fixed as the semantics of objects here depends upon it. > Pmip6MNLlIdentifier ::= TEXTUAL-CONVENTION > DISPLAY-HINT "255a" > STATUS current > DESCRIPTION > "An identifier that identifies the attached interface of a > mobile node. For those interfaces that have a link-layer > identifier, this identifier can be based on that. The > link-layer identifier, in some cases, is generated by the > mobile node and conveyed to the mobile access gateway. This > identifier of the attached interface must be stable as seen > by any of the mobile access gateways in a given Proxy Mobile > IPv6 domain. In some other cases, there might not be any > link-layer identifier associated with the mobile node's > interface. An identifier value of all zeroes is not > considered a valid identifier and cannot be used as an > interface identifier." > " > REFERENCE > "RFC 5213: Section 8.6" > SYNTAX OCTET STRING (SIZE (0..255)) What is an all zeroes value for a string identifier of a variable size. Does this mean a string of any size where each character is 0x? or only maximal size? What about the null string? 3. Is the Pmip6MnInterfaceATT TC supposed to be updated, as IANA maintains the mobility parameters register as per RFC 5213: Section 8.5? If so the TC needs also to be placed in a separate MIB module to be maintained by IANA. Now this TC is imported from a future RFC which will need to be approved and published in order for this document to be published. Why is not the MIB module defining the TC part of this document? Similar for another 3 TCs imported from the same MIB 4. (cleared) 5. In the DESCRIPTION clause of pmip6Status: The value of this object SHOULD remain unchanged across reboots of the managed entity. Why is this a SHOULD? In which conditions are exceptions allowed, and what is the behavior for such cases? |
2011-09-27 |
08 | Dan Romascanu | [Ballot discuss] (revised after the publication of draft-7) The DISCUSS is based in part on the MIB Doctor review performed by Harrie Hazewinkel 1. (cleared) … [Ballot discuss] (revised after the publication of draft-7) The DISCUSS is based in part on the MIB Doctor review performed by Harrie Hazewinkel 1. (cleared) 2. The definition of the TC is not in the document, but yet it needs being fixed as the semantics of objects here depends upon it. > Pmip6MNLlIdentifier ::= TEXTUAL-CONVENTION > DISPLAY-HINT "255a" > STATUS current > DESCRIPTION > "An identifier that identifies the attached interface of a > mobile node. For those interfaces that have a link-layer > identifier, this identifier can be based on that. The > link-layer identifier, in some cases, is generated by the > mobile node and conveyed to the mobile access gateway. This > identifier of the attached interface must be stable as seen > by any of the mobile access gateways in a given Proxy Mobile > IPv6 domain. In some other cases, there might not be any > link-layer identifier associated with the mobile node's > interface. An identifier value of all zeroes is not > considered a valid identifier and cannot be used as an > interface identifier." > " > REFERENCE > "RFC 5213: Section 8.6" > SYNTAX OCTET STRING (SIZE (0..255)) What is an all zeroes value for a string identifier of a variable size. Does this mean a string of any size where each character is 0x? or only maximal size? What about the null string? 3. Is the Pmip6MnInterfaceATT TC supposed to be updated, as IANA maintains the mobility parameters register as per RFC 5213: Section 8.5? If so the TC needs also to be placed in a separate MIB module to be maintained by IANA. Now this TC is imported from a future RFC which will need to be approved and published in order for this document to be published. Why is not the MIB module defining the TC part of this document? Similar for another 3 TCs imported from the same MIB 4. (cleared) 5. In the DESCRIPTION clause of pmip6Status: The value of this object SHOULD remain unchanged across reboots of the managed entity. Why is this a SHOULD? In which conditions are exceptions allowed, and what is the behavior for such cases? |
2011-09-27 |
08 | Dan Romascanu | [Ballot comment] 1. Some of the DESCRIPTION clauses of enumerated or BITS objects or TCs do not explain the significance of each enumerated value or … [Ballot comment] 1. Some of the DESCRIPTION clauses of enumerated or BITS objects or TCs do not explain the significance of each enumerated value or bit. For example Pmip6PBUAccessTechnologyType, pmip6Capabilities, etc. 2. (cleared) |
2011-09-27 |
08 | Dan Romascanu | [Ballot discuss] (revised after the publication of draft-7) The DISCUSS is based in part on the MIB Doctor review performed by Harrie Hazewinkel 1. (cleared) … [Ballot discuss] (revised after the publication of draft-7) The DISCUSS is based in part on the MIB Doctor review performed by Harrie Hazewinkel 1. (cleared) 2. The following comment in the MIB review does not seem to have been addressed: > Pmip6MNLlIdentifier ::= TEXTUAL-CONVENTION > DISPLAY-HINT "255a" > STATUS current > DESCRIPTION > "An identifier that identifies the attached interface of a > mobile node. For those interfaces that have a link-layer > identifier, this identifier can be based on that. The > link-layer identifier, in some cases, is generated by the > mobile node and conveyed to the mobile access gateway. This > identifier of the attached interface must be stable as seen > by any of the mobile access gateways in a given Proxy Mobile > IPv6 domain. In some other cases, there might not be any > link-layer identifier associated with the mobile node's > interface. An identifier value of all zeroes is not > considered a valid identifier and cannot be used as an > interface identifier." > " > REFERENCE > "RFC 5213: Section 8.6" > SYNTAX OCTET STRING (SIZE (0..255)) What is an all zeroes value for a string identifier of a variable size. Does this mean a string of any size where each character is 0x? or only maximal size? What about the null string? 3. Is the Pmip6MnInterfaceATT TC supposed to be updated, as IANA maintains the mobility parameters register as per RFC 5213: Section 8.5? If so the TC needs also to be placed in a separate MIB module to be maintained by IANA. Now this TC is imported from a future RFC which will need to be approved and published in order for this document to be published. Why is not the MIB module defining the TC part of this document? 4. (cleared) 5. In the DESCRIPTION clause of pmip6Status: The value of this object SHOULD remain unchanged across reboots of the managed entity. Why is this a SHOULD? In which conditions are exceptions allowed, and what is the behavior for such cases? |
2011-09-27 |
08 | Adrian Farrel | [Ballot comment] Thanks for addressing my concerns |
2011-09-27 |
08 | Adrian Farrel | [Ballot Position Update] Position for Adrian Farrel has been changed to No Objection from Discuss |
2011-09-26 |
07 | (System) | New version available: draft-ietf-netlmm-pmipv6-mib-07.txt |
2011-09-21 |
08 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2011-09-21 |
06 | (System) | New version available: draft-ietf-netlmm-pmipv6-mib-06.txt |
2011-07-28 |
08 | Jari Arkko | [Note]: changed to 'Jonne Soininen (jonne.soininen@renesasmobile.com) is the document shepherd.' |
2011-07-28 |
08 | Jari Arkko | State Change Notice email list has been changed to netlmm-chairs@tools.ietf.org, draft-ietf-netlmm-pmipv6-mib@tools.ietf.org, jonne.soininen@renesasmobile.com from netlmm-chairs@tools.ietf.org, draft-ietf-netlmm-pmipv6-mib@tools.ietf.org |
2011-05-12 |
08 | Amy Vezza | State changed to IESG Evaluation::Revised ID Needed from Waiting for AD Go-Ahead. |
2011-05-12 |
08 | Amy Vezza | Removed from agenda for telechat |
2011-05-12 |
08 | Sean Turner | [Ballot comment] I'm hoping to change the boiler plate text, but don't want to hold this document up for that discussion. I've copied my DISCUSS … [Ballot comment] I'm hoping to change the boiler plate text, but don't want to hold this document up for that discussion. I've copied my DISCUSS here, though there is NOTHING for the authors do with it. With the addition of the Transport Security Model (RFC 5590/5591) to SNMPv3 I'd like to see the following paragraph from the Security Considerations aligned with the one in RFC 5591: OLD: 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). NEW: It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the USM and Transport Security Model cryptographic mechanisms (for authentication and privacy). Can we work in references for RFC 3414 (USM) and RFC 5591 (Transport Security Model). |
2011-05-12 |
08 | Sean Turner | [Ballot Position Update] Position for Sean Turner has been changed to No Objection from Discuss |
2011-05-12 |
08 | Adrian Farrel | [Ballot comment] I really would prefer it if documents didn't show up for AD review with unresilved idnits. --- … [Ballot comment] I really would prefer it if documents didn't show up for AD review with unresilved idnits. --- I would find it helpful if the IMPORTS clause was enhanced to indicate which documents the imports come from. An example of this can be seen in Section 7 of RFC 4803. --- The copyright issue in the MIB module itself must be resolved before the I-D progresses. --- It would be nice to include a DISPLAY-HINT for Pmip6TimeStamp64. --- There is something wrong in the DESCRIPTION of Pmip6TimeStamp64 "A 64-bit unsigned integer field containing a timestamp. The value indicates the number of seconds since January 1, 1970, 00:00 UTC, by using a fixed point format. In this format, the integer number of seconds is contained in the first 48 bits of the field, and the remaining 16 bits indicate the number of 1/65536 fractions of a second. " The second line says the value indicates the number of seconds, but the description goes on to say it indicates the number of fractions of a second. How about: s/the number of seconds since/the elapsed time since/ --- Please do not include sitations (such as [RFC1234]) within the MIB module itself as this is standalone text. The REFERENCE clause should be enough. --- Please don't include unstable URLs (e.g. pointers to Internet-Drafts) in REFERENCE clauses. --- I think there is dubious utility to using RFC 2119 language within DESCRIPTION clauses. --- I'm surprised pmip6Status doesn't have a DEFVAL --- Did I miss something? This module is for IPv6 proxy mobile, right? So all addresses will be IPv6? So why use InetAddressType? Surely the use of that SYNTAX only means that you have to write restriction clauses and have error handling? Or is the point that you also want to allow zone indexes? --- I want to check that pmip6MagBLEntry is really intended to augment mip6MnBLEntry. The alternative is that you really wanted a sparse augmentation. Similarly for pmip6BindingCacheEntry augmenting mip6BindingCacheEntry. --- -- pmip6Stats:pmip6BindingRegcounters s/counters/Counters/ --- I think the use of counter and gauge is not completely right. Counter should be used for counts of events (i.e. increasing counts). Gauge should be used to show the number of things that exist (i.e. a count that can go up or down). Integer should be used for fixed (although changeable through configuration) value. So, I would have thuught (a MIB Doctor may disagree)... Pmip6TimeStamp64 is an integer pmip6LmaHomeNetworkPrefixLifeTime is an integer --- Should Pmip6PBUAccessTechnologyType be in an IANA MIB module so that it gets updated in lockstep with the IANA registry? |
2011-05-12 |
08 | Adrian Farrel | [Ballot discuss] I have only done a very cursory review of this document. It seems to me that there may be a large number of … [Ballot discuss] I have only done a very cursory review of this document. It seems to me that there may be a large number of nits related to how the MIB module is written, and the Responsible AD may want to ensure that the document has been updated after MIB Doctor review *before* it is presented for IESG review. I am entering a Discuss because of the volume of minor Comments I have generated. None of the Comments stands on its own as a point worthy of a Discuss, but there are so many that I feel the document cannot be described as ready for publication. In order to make this Discuss actionable, I ask that the authors make an attempt to address a serious percentage of my Comments. |
2011-05-12 |
08 | Adrian Farrel | [Ballot Position Update] New position, Discuss, has been recorded |
2011-05-12 |
08 | Ralph Droms | [Ballot Position Update] New position, No Objection, has been recorded |
2011-05-12 |
08 | Gonzalo Camarillo | [Ballot Position Update] New position, No Objection, has been recorded |
2011-05-11 |
08 | Ron Bonica | [Ballot Position Update] New position, No Objection, has been recorded |
2011-05-11 |
08 | Robert Sparks | [Ballot comment] The document currently contains: -- Authors' note: -- It is not clear if the … [Ballot comment] The document currently contains: -- Authors' note: -- It is not clear if the Copyright notice should be a part -- of above description. It was a requirement sometime ago -- but the submission tool at ietf.org complained so it is -- removed for now. That should be removed before approving the document. Guidance on where to include the copyright notice can be found at <http://www.ietf.org/iesg/statement/copyright.html> |
2011-05-11 |
08 | Robert Sparks | [Ballot Position Update] New position, No Objection, has been recorded |
2011-05-11 |
08 | Sean Turner | [Ballot discuss] With the addition of the Transport Security Model (RFC 5590/5591) to SNMPv3 I'd like to see the following paragraph from the Security Considerations … [Ballot discuss] With the addition of the Transport Security Model (RFC 5590/5591) to SNMPv3 I'd like to see the following paragraph from the Security Considerations aligned with the one in RFC 5591: OLD: 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). NEW: It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the USM and Transport Security Model cryptographic mechanisms (for authentication and privacy). Can we work in references for RFC 3414 (USM) and RFC 5591 (Transport Security Model). |
2011-05-11 |
08 | Sean Turner | [Ballot discuss] Sorry 'bout that I forgot I'm not supposed to save stuff here. |
2011-05-11 |
08 | Sean Turner | [Ballot discuss] Working on it. |
2011-05-11 |
08 | Sean Turner | [Ballot Position Update] New position, Discuss, has been recorded |
2011-05-11 |
08 | David Harrington | [Ballot comment] I support the discusses filed by Dan I support the first discuss by Stephen. |
2011-05-11 |
08 | David Harrington | [Ballot Position Update] New position, No Objection, has been recorded |
2011-05-11 |
08 | Stewart Bryant | [Ballot Position Update] New position, No Objection, has been recorded |
2011-05-10 |
08 | (System) | State changed to Waiting for AD Go-Ahead from In Last Call. |
2011-05-09 |
08 | Stephen Farrell | [Ballot comment] The secdir review identified that we might want to update the boilerplate security considerations a bit - do we want to do that … [Ballot comment] The secdir review identified that we might want to update the boilerplate security considerations a bit - do we want to do that now? (This is really for the OAM^h^h^hOPS ADs:-) "RFC 3826 details how to use AES with SNMPv3. Again, this never made it into the boilerplate. Perhaps some new enthusiastic ADs get engaged to revise the boilerplate? ;-)" The SEC and OPS ADs should come back to this. |
2011-05-09 |
08 | Stephen Farrell | [Ballot discuss] (1) Pmip6MNIdentifier and Pmip6MNLlIdentifier - these can contain identifiers for the MN and so can (I believe) identify people, so I don't understand … [Ballot discuss] (1) Pmip6MNIdentifier and Pmip6MNLlIdentifier - these can contain identifiers for the MN and so can (I believe) identify people, so I don't understand why they are not in the list of sensitive read-only objects? (2) starting from 1 with Pmip6MNIndex would imply that one can guess values - is that a potential problem, if so, perhaps this also needs to be in the list of sensitive objects? |
2011-05-09 |
08 | Stephen Farrell | [Ballot discuss] (1) Pmip6MNIdentifier and Pmip6MNLlIdentifier - these can contain identifiers for the MN and so can (I believe) identify people, so I don't understand … [Ballot discuss] (1) Pmip6MNIdentifier and Pmip6MNLlIdentifier - these can contain identifiers for the MN and so can (I believe) identify people, so I don't understand why they are not in the list of sensitive read-only objects? (2) starting from 1 with Pmip6MNIndex would imply that one can guess values - is that a potential problem, if so, perhaps this also needs to be in the list of sensitive objects? (3) The secdir review identified that we might want to update the boilerplate security considerations a bit - do we want to do that now? (This is really for the OAM ADs) "RFC 3826 details how to use AES with SNMPv3. Again, this never made it into the boilerplate. Perhaps some new enthusiastic ADs get engaged to revise the boilerplate? ;-)" |
2011-05-09 |
08 | Stephen Farrell | [Ballot Position Update] New position, Discuss, has been recorded |
2011-05-08 |
08 | Pete Resnick | [Ballot Position Update] New position, No Objection, has been recorded |
2011-05-08 |
08 | Dan Romascanu | [Ballot comment] 1. Some of the DESCRIPTION clauses of enumerated or BITS objects or TCs do not explain the significance of each enumerated value or … [Ballot comment] 1. Some of the DESCRIPTION clauses of enumerated or BITS objects or TCs do not explain the significance of each enumerated value or bit. For example Pmip6PBUAccessTechnologyType, pmip6Capabilities, etc. 2. Objects like pmip6Status could use TruthValue SYNTAX |
2011-05-08 |
08 | Dan Romascanu | [Ballot discuss] The DISCUSS is based in part on the MIB Doctor review performed by Harrie Hazewinkel 1. The following comment in the MIB review … [Ballot discuss] The DISCUSS is based in part on the MIB Doctor review performed by Harrie Hazewinkel 1. The following comment in the MIB review does not seem to have been addressed: > The PMIPV6-MIB is composed of the following groups of definitions: The groups do not align with the object groups defined in the MIB itself. IMO, the rest of the section would need some rewriting as it does not reflect the MIB definition. > - pmip6Core: a generic group containing objects that are > common to all the Proxy Mobile IPv6 entities. Objects > belonging to this group will be implemented on the > corresponding Proxy Mobile IPv6 entity. pmip6BindingCacheTable > belongs to this group. For instance, the pmip6BindingCacheTable has an object that is pmip6BindingTimeRecentlyAccepted and that is part of the pmip6BindingCacheGroup. Also I am not finding a core group in the object group definitions, but there is a core complaince (pmip6CoreCompliance) 2. The following comment in the MIB review does not seem to have been addressed: > Pmip6MNLlIdentifier ::= TEXTUAL-CONVENTION > DISPLAY-HINT "255a" > STATUS current > DESCRIPTION > "An identifier that identifies the attached interface of a > mobile node. For those interfaces that have a link-layer > identifier, this identifier can be based on that. The > link-layer identifier, in some cases, is generated by the > mobile node and conveyed to the mobile access gateway. This > identifier of the attached interface must be stable as seen > by any of the mobile access gateways in a given Proxy Mobile > IPv6 domain. In some other cases, there might not be any > link-layer identifier associated with the mobile node's > interface. An identifier value of ALL_ZERO is not considered > a valid identifier and cannot be used as an interface > identifier. > " > REFERENCE > "RFC 5213: Section 8.6" > SYNTAX OCTET STRING (SIZE (0..255)) What is the ALL_ZERO value? 3. Is the Pmip6PBUAccessTechnologyType TC supposed to be updated, as IANA maintains th emobility parameters register as per RFC 5213: Section 8.5? If so the TC needs also to be placed in a separate MIB module to be maintained by IANA. 4. I do not see the relation between the DESCRIPTION clause of pmip6Compliance2 and the included compliance clauses themselves. 5. In the DESCRIPTION clause of pmip6Status: The value of this object SHOULD remain unchanged across reboots of the managed entity. Why is this a SHOULD? In which conditions are exceptions allowed, and what is the behavior for such cases? Default on disabled(2) or it does not matter? |
2011-05-08 |
08 | Dan Romascanu | [Ballot Position Update] New position, Discuss, has been recorded |
2011-04-14 |
08 | Samuel Weiler | Request for Telechat review by SECDIR Completed. Reviewer: Vincent Roca. |
2011-04-12 |
08 | Peter Saint-Andre | [Ballot Position Update] New position, No Objection, has been recorded |
2011-04-12 |
08 | Amy Vezza | Last call sent |
2011-04-12 |
08 | Amy Vezza | State changed to In Last Call from Last Call Requested. The following Last Call Announcement was sent out: From: The IESG <iesg-secretary@ietf.org> To: IETF-Announce <ietf-announce@ietf.org> … State changed to In Last Call from Last Call Requested. The following Last Call Announcement was sent out: From: The IESG <iesg-secretary@ietf.org> To: IETF-Announce <ietf-announce@ietf.org> Reply-To: ietf@ietf.org Subject: Last Call: <draft-ietf-netlmm-pmipv6-mib-05.txt> (Proxy Mobile IPv6 Management Information Base) to Proposed Standard The IESG has received a request from an individual submitter to consider the following document: - 'Proxy Mobile IPv6 Management Information Base' <draft-ietf-netlmm-pmipv6-mib-05.txt> as a 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 2011-05-10. 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. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-netlmm-pmipv6-mib/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-netlmm-pmipv6-mib/ |
2011-04-12 |
08 | Jari Arkko | Telechat date has been changed to 2011-05-12 from 2011-04-14 |
2011-04-12 |
08 | Jari Arkko | Last Call was requested |
2011-04-12 |
08 | Jari Arkko | State changed to Last Call Requested from AD Evaluation::External Party. |
2011-04-12 |
08 | Jari Arkko | Last Call text changed |
2011-04-12 |
08 | Jari Arkko | Ballot has been issued |
2011-03-29 |
05 | (System) | New version available: draft-ietf-netlmm-pmipv6-mib-05.txt |
2011-03-28 |
08 | David Harrington | Assignment of request for Telechat review by TSVDIR to Bernard Aboba was rejected |
2011-03-16 |
08 | David Harrington | Request for Last Call review by TSVDIR is assigned to Martin Stiemerling |
2011-03-16 |
08 | David Harrington | Request for Last Call review by TSVDIR is assigned to Martin Stiemerling |
2011-03-07 |
08 | Amanda Baber | Upon approval of this document, IANA understands that a single action needs to be completed. In the SMI Network Management MGMT Codes with prefix (iso.org.dod.internet.mgmt.mib-2 … Upon approval of this document, IANA understands that a single action needs to be completed. In the SMI Network Management MGMT Codes with prefix (iso.org.dod.internet.mgmt.mib-2 (1.3.6.1.2.1)) located at: http://www.iana.org/assignments/smi-numbers a new MIB should be registered as follows: Decimal: tbd Name: pmip6MIB Description: PMIPV6-MIB References: [ RFC-to-be ] IANA understands that this is the only action required to be completed upon approval of this document. |
2011-03-04 |
08 | Samuel Weiler | Request for Telechat review by SECDIR is assigned to Vincent Roca |
2011-03-04 |
08 | Samuel Weiler | Request for Telechat review by SECDIR is assigned to Vincent Roca |
2011-03-02 |
08 | David Harrington | Request for Telechat review by TSVDIR is assigned to Bernard Aboba |
2011-03-02 |
08 | David Harrington | Request for Telechat review by TSVDIR is assigned to Bernard Aboba |
2011-02-28 |
08 | Jari Arkko | Placed on agenda for telechat - 2011-04-14 |
2011-02-28 |
08 | Jari Arkko | [Ballot Position Update] New position, Yes, has been recorded for Jari Arkko |
2011-02-28 |
08 | Jari Arkko | Ballot has been issued |
2011-02-28 |
08 | Jari Arkko | Created "Approve" ballot |
2011-02-28 |
08 | (System) | Ballot writeup text was added |
2011-02-28 |
08 | (System) | Last call text was added |
2011-02-28 |
08 | (System) | Ballot approval text was added |
2011-02-28 |
08 | Jari Arkko | State changed to AD Evaluation::External Party from AD Evaluation::AD Followup. Waiting for MIB doctors to respond to the new version |
2011-02-08 |
08 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2011-02-08 |
04 | (System) | New version available: draft-ietf-netlmm-pmipv6-mib-04.txt |
2011-02-08 |
08 | Jari Arkko | State changed to AD Evaluation::Revised ID Needed from AD Evaluation::External Party. waiting for the authors... |
2011-01-18 |
08 | Jari Arkko | Sent a reminder to the MIB doctors that we still have not seen the review... |
2010-10-22 |
08 | Jari Arkko | MIB doctor reviewer has a review, but we're still waiting for it (he was asking for format in which we desire it). Send it now... … MIB doctor reviewer has a review, but we're still waiting for it (he was asking for format in which we desire it). Send it now... deadline is soon! |
2010-09-07 |
08 | Jari Arkko | Dear doctors, I would like to get your review of this document. The document has been revised once to address my AD review concerns. The … Dear doctors, I would like to get your review of this document. The document has been revised once to address my AD review concerns. The new document looks good to me. When I compile it with my tools (replacing YYY with a number), I get only the warnings below that seem consistent with what the document itself says. In other words, I think it is ready to be looked at by you. > Your request has been processed by the command > > smistrip -d mibs docs/netlmmmib.txt > smilint -s -e -l 6 mibs/PMIPV6-MIB 2>report.txt > > You can access any intermediately created files, the processing report (which might be empty if no errors or warnings have been found), and output files (in case of a conversion request) for reading and download from a temporary server directory <http://www.ibr.cs.tu-bs.de/projects/libsmi/tools/tmp/4Pxr6k/> for approx. 24 hours. > > While processing your request the following errors and/or warnings have been found: > > mibs/PMIPV6-MIB:407: [5] {index-exceeds-too-large} warning: index of row `pmip6MagProxyCOAEntry' can exceed OID size limit by 142 subidentifier(s) > mibs/PMIPV6-MIB:540: [5] {index-exceeds-too-large} warning: index of row `pmip6MagHomeNetworkPrefixEntry' can exceed OID size limit by 654 subidentifier(s) > mibs/PMIPV6-MIB:1473: [5] {index-exceeds-too-large} warning: index of row `pmip6LmaLMAAEntry' can exceed OID size limit by 142 subidentifier(s) > mibs/PMIPV6-MIB:1646: [5] {index-exceeds-too-large} warning: index of row `pmip6LmaHomeNetworkPrefixEntry' can exceed OID size limit by 654 subidentifier(s) > |
2010-09-07 |
08 | Jari Arkko | State Changes to AD Evaluation::External Party from AD Evaluation::AD Followup by Jari Arkko |
2010-09-07 |
08 | Jari Arkko | Waiting for MIB doctor review. |
2010-09-07 |
08 | Jari Arkko | Checking with smilint: Your request has been processed by the command smistrip -d mibs docs/netlmmmib.txt smilint -s -e -l 6 mibs/PMIPV6-MIB 2>report.txt You can access … Checking with smilint: Your request has been processed by the command smistrip -d mibs docs/netlmmmib.txt smilint -s -e -l 6 mibs/PMIPV6-MIB 2>report.txt You can access any intermediately created files, the processing report (which might be empty if no errors or warnings have been found), and output files (in case of a conversion request) for reading and download from a temporary server directory for approx. 24 hours. While processing your request the following errors and/or warnings have been found: mibs/PMIPV6-MIB:407: [5] {index-exceeds-too-large} warning: index of row `pmip6MagProxyCOAEntry' can exceed OID size limit by 142 subidentifier(s) mibs/PMIPV6-MIB:540: [5] {index-exceeds-too-large} warning: index of row `pmip6MagHomeNetworkPrefixEntry' can exceed OID size limit by 654 subidentifier(s) mibs/PMIPV6-MIB:1473: [5] {index-exceeds-too-large} warning: index of row `pmip6LmaLMAAEntry' can exceed OID size limit by 142 subidentifier(s) mibs/PMIPV6-MIB:1646: [5] {index-exceeds-too-large} warning: index of row `pmip6LmaHomeNetworkPrefixEntry' can exceed OID size limit by 654 subidentifier(s) |
2010-09-07 |
08 | Jari Arkko | Responses from the authors look good. |
2010-08-20 |
08 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2010-08-20 |
03 | (System) | New version available: draft-ietf-netlmm-pmipv6-mib-03.txt |
2010-08-09 |
08 | Jari Arkko | Sent a reminder to the authors about a draft update. |
2010-05-31 |
08 | Jari Arkko | State Changes to AD Evaluation::Revised ID Needed from AD Evaluation by Jari Arkko |
2010-05-31 |
08 | Jari Arkko | I have reviewed this draft. Overall, I think it is in good shape, but I did see a number of issues. Please issue a new … I have reviewed this draft. Overall, I think it is in good shape, but I did see a number of issues. Please issue a new draft that corrects them and/or adds more clarifying text. The main issues were: - at times the document was unclear about where a particular piece of MIB information is held (at the MAG vs. LMA) - in several places the document needs to be more explicit - some IP address issues - not sure I understood the OID limit issue > - pmip6MagProxyCOATable : models the Proxy Care-of > Addresses configured on the > egress interfaces of the > mobile access gateway. From this description it is unclear where this table is. Is this a MAG or a LMA table? > - pmip6MagHomeNetworkPrefixTable : contains the Home Network > Prefixes assigned to the > mobile node's connected > interfaces. Is this "the mobile node"? or all mobile nodes currently attached to this mag? Same issue in pmip6LmaHomeNetworkPrefixTable. > - pmip6LmaLMAATable : contains the LMA Addresses > that are configured on the > local mobility anchor. Each > LMA Address acts as a > transport endpoint of the > tunnel between the local > mobility anchor and the mobile > access gateway. From this desccription it is unclear from whose point of view this information is presented. Does this table exist at the MAGs or the LMAs? > Pmip6MNIdentifier ::= TEXTUAL-CONVENTION > STATUS current > DESCRIPTION > "The identity of a mobile node in the Proxy Mobile IPv6 > domain. This is the stable identifier of a mobile node > that the mobility entities in a Proxy Mobile IPv6 domain > can always acquire and use it for predictably identifying > a mobile node. This is typically an identifier such as > Network Access Identifier (NAI) [RFC4282] or other > identifier such as a Media Access Control (MAC) address. > " > REFERENCE > "RFC 5213: Section 2.2" > SYNTAX OCTET STRING (SIZE (0..255)) > This description should be more accurate about the encoding of the identifier. Do you mean that its the same encoding as in RFC 4283? Are there other alternatives than NAIs? Please be more precise. Section 2.2 is not a very good reference in this sense, because it too lacks specificity. > Pmip6MNLlIdentifier ::= TEXTUAL-CONVENTION > STATUS current > DESCRIPTION > "An identifier that identifies the attached interface of a > mobile node. For those interfaces that have a link-layer > identifier, this identifier can be based on that. The > link-layer identifier in some cases is generated by the > mobile node and conveyed to the mobile access gateway. This > identifier of the attached interface must be stable as seen > by any of the mobile access gateways in a given Proxy Mobile > IPv6 domain. In some other cases, there might not be any > link-layer identifier associated with the mobile node's > interface. An identifier value of ALL_ZERO is not considered > a valid identifier and cannot be used as an interface > identifier. > " > REFERENCE > "RFC 5213: Section 2.2" > SYNTAX OCTET STRING (SIZE (0..255)) As above, what is the encoding? Should the reference be Section 8.6 instead? > Pmip6MNIndex ::= TEXTUAL-CONVENTION > DISPLAY-HINT "d" > STATUS current > DESCRIPTION > "A unique integer value, greater than zero, assigned to each > mobile node in a PMIPv6-Domain by the management system. > It is recommended that values are assigned contiguously > starting from 1. The value for each mobile node must remain > constant at least from one re-initialization of the entity's > network management system to the next re-initialization. > " > SYNTAX Integer32 (1..2147483647) > Due to roaming, there is an infinite number of potential visited mobile nodes. Are these indexes for the *current* mobile nodes, i.e., those currently attached to the domain? Or something else? Please specify. > Pmip6PBUAccessTechnologyType ::= TEXTUAL-CONVENTION > STATUS current > DESCRIPTION > "This specifies the access technology which connects the > mobile node to the access link on the mobile access gateway. > " > REFERENCE > "RFC 5213: Section 8.5" > SYNTAX INTEGER > { > reserved (0), > logicalNetworkInterface(1), > pointToPointInterface (2), > ethernet (3), > wirelessLan (4), > wimax (5) > } Perhaps you should explicitly state that the namespace from RFC 5213 should be used: http://www.iana.org/assignments/mobility-parameters/mobility-parameters.txt note the 3GPP etc items that do not appear in your list above... > pmip6FixedMagLinkLocalAddressOnAllAccessLinksType OBJECT-TYPE > SYNTAX InetAddressType > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "The InetAddressType of the > pmip6FixedMagLinkLocalAddressOnAllAccessLinks > that follows. > " > ::= { pmip6Conf 2 } > pmip6FixedMagLinkLocalAddressOnAllAccessLinks OBJECT-TYPE > SYNTAX InetAddress > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "This variable indicates the link-local address value > that all the mobile access gateways should use on > any of the access links shared with any of the > mobile nodes in that Proxy Mobile IPv6 domain. If > this variable is initialized to ALL_ZERO value, it > implies the use of fixed link-local address mode is > not enabled for that Proxy Mobile IPv6 domain." > REFERENCE > "RFC 5213: Section 2.2, 6.8, 6.9.1.1, 6.9.3, 9.3" > ::= { pmip6Conf 3 } I'm not sure I understand this. There's an IPv6 link local address, but is there an IPv4 one? If not, why do we need the -Type object? And where is the IPv4 default router and DHCP server address stored in? Here there is room for just one address, not two as would expect to require in a dual stack environment... but maybe I'm missing something. (Same issue in pmip6Binding table) > pmip6MagProxyCOAState OBJECT-TYPE > SYNTAX INTEGER { > unknown(1), > activated(2), > tunneled(3) > } > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "This object indicates the state of the Proxy-CoA: > unknown -- The state of the Proxy-CoA > cannot be determined. > activated -- The Proxy-CoA is ready to establish > tunnel > tunneled -- The Proxy-CoA is used to set up the > bi-directional tunnel. > " > ::= { pmip6MagProxyCOAEntry 3 } Do we use activated or tunneled, if the system is otherwise up but the MAG has no mobile nodes, and has not had to send a Proxy Binding Update yet? > pmip6MagHomeNetworkPrefixTable OBJECT-TYPE > SYNTAX SEQUENCE OF PMip6MagHomeNetworkPrefixEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "A table representing the Home Network Prefixes > assigned to the mobile node's connected interfaces. > This table shows the prefixes registered in the > binding update list entry. > " > REFERENCE > "RFC 5213: Section 2, 6.1, 6.2" > ::= { pmip6MagConf 2 } The description has been written as if there was just one mobile node and one BUL entry. Please update the specification, I presume that you meant that this table contains ALL prefixes of ALL mobile nodes for which there exists ANY BUL in this MAG? > pmip6MagHomeNetworkPrefixEntry OBJECT-TYPE > SYNTAX PMip6MagHomeNetworkPrefixEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "An entry in the Home Network Prefixes table. > > Implementers need to be aware that if the total > number of octets in pmip6MagHomeNetworkPrefix > exceeds 114 then OIDs of column > instances in this row will have more than 128 > sub-identifiers and cannot be accessed using > SNMPv1, SNMPv2c, or SNMPv3. I do not understand this. The pmip6MagHomeNetworkPrefix is of type InetAddress, so in this case its length would always be 16, no? (Same issue in pmip6LmaLMAAEntry and pmip6LmaHomeNetworkPrefixEntry) > pmip6MagHomeNetworkPrefixLifeTime OBJECT-TYPE > SYNTAX Gauge32 > UNITS "seconds" > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The lifetime (in seconds) granted to the mobile > node for this registration. > " > REFERENCE > "RFC 5213: Section 6.2, 6.7" > ::= { pmip6MagHomeNetworkPrefixEntry 4 } > > The lifetime in the PBA? The lifetime in the last RA sent out to the mobile node? The remaining lifetime? Please specify... > pmip6MagBLTable OBJECT-TYPE > SYNTAX SEQUENCE OF Pmip6MagBLEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "This table corresponds to the Binding Update List(BL) Is there a particular reason to drop the U from the abbreviation? > pmip6MagBLTimeRecentlyAccepted OBJECT-TYPE > SYNTAX DateAndTime > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The 64-bit timestamp value of the most recently > accepted Proxy Binding Update message sent for this > mobile node. This is the time-of-day on the mobile > access gateway, when the proxy binding acknowledgement > message with the Status field set to 0 > was received. If the Timestamp option is not present > in the Proxy Binding Update message (i.e., when the > sequence number based scheme is in use), the value MUST > be set to ALL_ZERO. > " > REFERENCE > "RFC 5213: Section 5.1, 8.1" > ::= { pmip6MagBLEntry 9 } I'm curious why the last timestamp is in this table, but the last sequence number is not. Sequence numbers and timestamps are equal alternatives in RFC 5213. (Same issue in pmip6Binding table) > pmip6BindingPBUFlag OBJECT-TYPE > SYNTAX TruthValue > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "true(1) if the local mobility anchor accepted the > binding update with Proxy Registration Flag from a > mobile access gateway. > false(0) implies that the binding cache is from a > mobile node. > " > REFERENCE > "RFC 5213: Section 5.1, 8.1" > ::= { pmip6BindingCacheEntry 1 } Please specify what is expected to happen for Flag=0 entries otherwise. Do they even show up in this table, and if they do, how do the values in the entries get filled? Or would a client Mobile IP host simply lead to the creation of another entry in a Mobile IPv6 MIB table, not here? > sensitivity/vulnerability: > nemoStatus: The value of this object is used to enable or disable > the PMIPv6 functionality on a PMIPv6 entity. Access to this MO > may be abused to disrupt the communication that depends on This is the first time that nemoStatus appears in the document. When using http://www.ibr.cs.tu-bs.de/bin/smitools.cgi I got these errors: > mibs/PMIPV6-MIB:88: [2] {bad-identifier-case} `YYY' should start with a lower case letter > mibs/PMIPV6-MIB:88: [2] {object-identifier-not-prefix} Object identifier element `YYY' name only allowed as first element > mibs/PMIPV6-MIB:407: [5] {index-exceeds-too-large} warning: index of row `pmip6MagProxyCOAEntry' can exceed OID size limit by 136 subidentifier(s) > mibs/PMIPV6-MIB:537: [5] {index-exceeds-too-large} warning: index of row `pmip6MagHomeNetworkPrefixEntry' can exceed OID size limit by 648 subidentifier(s) > mibs/PMIPV6-MIB:1462: [5] {index-exceeds-too-large} warning: index of row `pmip6LmaLMAAEntry' can exceed OID size limit by 136 subidentifier(s) > mibs/PMIPV6-MIB:1640: [5] {index-exceeds-too-large} warning: index of row `pmip6LmaHomeNetworkPrefixEntry' can exceed OID size limit by 648 subidentifier(s) > mibs/PMIPV6-MIB:145: [5] {type-without-format} warning: type `Pmip6MNIdentifier' has no format specification > mibs/PMIPV6-MIB:160: [5] {type-without-format} warning: type `Pmip6MNLlIdentifier' has no format specification At least some of these seem real problems. Please fix. |
2010-05-31 |
08 | Jari Arkko | State Changes to AD Evaluation from Publication Requested by Jari Arkko |
2010-05-06 |
08 | Cindy Morgan | # (1.a) Who is the Document Shepherd for this document? Has the Document # Shepherd personally reviewed this version of the document and, in particular, … # (1.a) Who is the Document Shepherd for this document? Has the Document # Shepherd personally reviewed this version of the document and, in particular, # does he or she believe this version is ready for forwarding to the IESG for # publication? Document Shepherd is Jonne Soininen (WG co-Chair for NETLMM). I have personally processed and reviewed the document and I do believe - as much as I understand the MIB - the document is ready to be forwarded for publication # (1.b) Has the document had adequate review both from key WG members and from # key non-WG members? Does the Document Shepherd have any concerns about the # depth or breadth of the reviews that have been performed? This document has had as much review as we could get for a MIB. I have no personal concerns about the reviews. # (1.c) Does the Document Shepherd have concerns that the document needs more # review from a particular or broader perspective, e.g., security, operational # complexity, someone familiar with AAA, internationalization or XML? This document needs to be reviewed by the MIB doctors. # (1.d) Does the Document Shepherd have any specific concerns or issues with # this document that the Responsible Area Director and/or the IESG should be # aware of? For example, perhaps he or she is uncomfortable with certain parts # of the document, or has concerns whether there really is a need for it. In # any event, if the WG has discussed those issues and has indicated that it # still wishes to advance the document, detail those concerns here. Has an # IPR disclosure related to this document been filed? If so, please include a # reference to the disclosure and summarize the WG discussion and conclusion # on this issue. I have no concerns on the document. # (1.e) How solid is the WG consensus behind this document? Does it # represent the strong concurrence of a few individuals, with others # being silent, or does the WG as a whole understand and agree with it? The WG consensus is behind this document. # (1.f) Has anyone threatened an appeal or otherwise indicated extreme # discontent? If so, please summarise the areas of conflict in separate # email messages to the Responsible Area Director. (It should be in a # separate email because this questionnaire is entered into the ID Tracker.) Nobody has threatened to appeal. # (1.g) Has the Document Shepherd personally verified that the document # satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and # http://tools.ietf.org/tools/idnits/). Boilerplate checks are not # enough; this check needs to be thorough. Has the document met all formal # review criteria it needs to, such as the MIB Doctor, media type and URI # type reviews? Yes, I run the nits script on the draft and it gave no warnings or errors # (1.h) Has the document split its references into normative and informative? # Are there normative references to documents that are not ready for # advancement or are otherwise in an unclear state? If such normative # references exist, what is the strategy for their completion? Are there # normative references that are downward references, as described in # [RFC3967]? If so, list these downward references to support the Area # Director in the Last Call procedure for them [RFC3967]. There is a split to normative and informative references. There is no normative document that would be in a dubious state. # (1.i) Has the Document Shepherd verified that the document IANA # consideration section exists and is consistent with the body of the # document? If the document specifies protocol extensions, are reservations # requested in appropriate IANA registries? Are the IANA registries clearly # identified? If the document creates a new registry, does it define the # proposed initial contents of the registry and an allocation procedure for # future registrations? Does it suggest a reasonable name for the new # registry? See [RFC2434]. If the document describes an Expert Review # process has Shepherd conferred with the Responsible Area Director so that # the IESG can appoint the needed Expert during the IESG Evaluation? Yes, IANA considerations section does exist and seems to be in line with the rest of the document. # (1.j) Has the Document Shepherd verified that sections of the document that # are written in a formal language, such as XML code, BNF rules, MIB # definitions, etc., validate correctly in an automated checker? This is a MIB. I used http://www.simpleweb.org/ietf/mibs/validate/ and I think everything went ok. It complained on some parts of the descriptions. (Mostly "'" within description or a reserved word word within the description texts). However, I thought this would be an error of the tool rather than the MIB. I might be wrong, though. # (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 is the MIB for Proxy Mobile IPv6. Working Group Summary There is a consensus in Netlmm WG that this specification is ready to be published as a proposed standard. Document Quality The document has gone through reviews and a successful WGLC. Personel Responsible AD is Jari Arkko and the document shepherd is Jonne Soininen. |
2010-05-06 |
08 | Cindy Morgan | Draft Added by Cindy Morgan in state Publication Requested |
2010-05-06 |
08 | Cindy Morgan | [Note]: 'Jonne Soininen (Jonne.Soininen@nsn.com) is the document shepherd.' added by Cindy Morgan |
2010-01-23 |
02 | (System) | New version available: draft-ietf-netlmm-pmipv6-mib-02.txt |
2009-09-15 |
01 | (System) | New version available: draft-ietf-netlmm-pmipv6-mib-01.txt |
2009-07-30 |
00 | (System) | New version available: draft-ietf-netlmm-pmipv6-mib-00.txt |