Re: [netlmm] AD review of draft-ietf-netlmm-pmipv6-mib
Jari Arkko <jari.arkko@piuha.net> Fri, 25 June 2010 06:25 UTC
Return-Path: <jari.arkko@piuha.net>
X-Original-To: netlmm@core3.amsl.com
Delivered-To: netlmm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E3D73A687E for <netlmm@core3.amsl.com>; Thu, 24 Jun 2010 23:25:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.462
X-Spam-Level:
X-Spam-Status: No, score=-0.462 tagged_above=-999 required=5 tests=[AWL=-1.121, BAYES_50=0.001, GB_I_LETTER=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, J_CHICKENPOX_47=0.6, MIME_HTML_ONLY=1.457]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qmh9hAOg4ETH for <netlmm@core3.amsl.com>; Thu, 24 Jun 2010 23:25:09 -0700 (PDT)
Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 9B27B3A68DA for <netlmm@ietf.org>; Thu, 24 Jun 2010 23:25:07 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 6C5D22CED4; Fri, 25 Jun 2010 09:25:09 +0300 (EEST)
X-Virus-Scanned: amavisd-new at piuha.net
Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KKrDIZZrNO6k; Fri, 25 Jun 2010 09:25:07 +0300 (EEST)
Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 0177A2CC62; Fri, 25 Jun 2010 09:25:05 +0300 (EEST)
Message-ID: <4C244584.6020601@piuha.net>
Date: Fri, 25 Jun 2010 08:58:28 +0300
From: Jari Arkko <jari.arkko@piuha.net>
User-Agent: Thunderbird 2.0.0.24 (X11/20100411)
MIME-Version: 1.0
To: "Glenn M. Keeni" <glenn@cysols.com>
References: <4C03BDE1.1010508@piuha.net> <4C1DDE10.2020300@cysols.com>
In-Reply-To: <4C1DDE10.2020300@cysols.com>
Content-Type: text/html; charset="ISO-2022-JP"
Content-Transfer-Encoding: 7bit
Cc: draft-ietf-netlmm-pmipv6-mib@tools.ietf.org, "netlmm@ietf.org" <netlmm@ietf.org>
Subject: Re: [netlmm] AD review of draft-ietf-netlmm-pmipv6-mib
X-BeenThere: netlmm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: NETLMM working group discussion list <netlmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netlmm>, <mailto:netlmm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netlmm>
List-Post: <mailto:netlmm@ietf.org>
List-Help: <mailto:netlmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netlmm>, <mailto:netlmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 25 Jun 2010 06:25:11 -0000
- at times the document was unclear about where a particular piece of MIB information is held (at the MAG vs. LMA)In the MIB design section there is text like <Quote> The PMIPV6-MIB is composed of the following groups of definitions: - pmip6Core: a generic group containing objects that are common to all the Proxy Mobile IPv6 entities. - pmip6Mag: this group models the mobile access gateway service. - pmip6Lma: this group models the local mobility anchor service. </Quote> That would imply that the all tables with prefix pmip6Mag (e.g. pmip6MagProxyCOATable) model a MAG service and as such would be held in the MAG. Is it necessary to explicitly specify the above?
Ok, that does help me! Perhaps you could still go through each description text for the objects and make sure that the text is clear on this point as well. If you can, be explicit in the text. (Now that I re-read pmip6MagProxyCOATable it is very clear and explicit.)
- in several places the document needs to be more explicit - some IP address issuesThe way network addresses are defined in MIBs ( after IPv6 came into being) is that they will always be in pairs - a type object [XXXX-AddressType] followed by the address object [XXXX-Address].
OK
In the case of this MIB the type will always be IPV6.
Ah, that was the part that I was missing. So you only support RFC 5213, not the IPv4 extension?
This is stated in the Compliance section e.g. <QUOTE> pmip6CoreCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP entities which implement the PMIPV6-MIB. There are a number of INDEX objects that cannot be represented in the form of OBJECT clauses in SMIv2, but for which there are compliance requirements, expressed in OBJECT clause form in this description: -- OBJECT pmip6BindingHomeAddressType -- SYNTAX InetAddressType { ipv6(2) } -- DESCRIPTION -- This MIB module requires support for global -- ipv6 addresses for the pmip6BindingHomeAddress -- object. -- </QUOTE>- not sure I understood the OID limit issueOK. Let me try. The InetAddress allows strings of length 0-255 octets. The maximum length of an index is 128 octets. So, inappropriate use InetAddress types in the index would lead to problems. Thus the warning is added to the description clauses. But, if the address type is IPv6 then we have only 16 octets, and it will not really be a problem. Does that make sense?
Not really :-( I understand that there is no issue when the address type is IPv6 and only 16 octets will be used. But when would there be an issue? What would be an inappropriate use of InetAddress types?
If there is no legitimate way to use the MIB beyond 16 bytes, why do we need to warn at all? Or is the issue that the address type must be ipv6, but for some other address type there might be a problem? If so, perhaps you should explicitly state that.
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 http://tools.ietf.org/html/rfc4282" rel="nofollow"><http://tools.ietf.org/html/rfc4282>] or other identifier such as a Media Access Control (MAC) address. " REFERENCE "RFC 5213 http://tools.ietf.org/html/rfc5213" rel="nofollow"><http://tools.ietf.org/html/rfc5213>: Section 2.2 http://tools.ietf.org/html/draft-ietf-netlmm-pmipv6-mib-02#section-2.2" rel="nofollow"><http://tools.ietf.org/html/draft-ietf-netlmm-pmipv6-mib-02#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.I am lost here. I have followed the definition of the "Mobile Node Identifier (MN-Identifier)" from RFC5213 section 2.2. ditto. Please give me a pointer here.
Section 2.2 just says:
Mobile Node Identifier (MN-Identifier)
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
for predictably identifying a mobile node. This is typically an
identifier such as a Network Access Identifier (NAI) [RFC4282] or
other identifier such as a Media Access Control (MAC) address.
Which isn't very precise. I wanted to know exactly what can appear in your MIB and what the encoding is. Are you expecting exacly a NAI from RFC4282, something formatted according to the subtype-identifier syntax from RFC 42833, or what?
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 http://tools.ietf.org/html/rfc5213" rel="nofollow"><http://tools.ietf.org/html/rfc5213>: Section 2.2 http://tools.ietf.org/html/draft-ietf-netlmm-pmipv6-mib-02#section-2.2" rel="nofollow"><http://tools.ietf.org/html/draft-ietf-netlmm-pmipv6-mib-02#section-2.2>" SYNTAX OCTET STRING (SIZE (0..255))As above, what is the encoding? Should the reference be Section 8.6 instead?Same as above. I have followed the definition of "Mobile Node Link-layer Identifier (MN-LL-Identifier)" from RFC5213 section 2.2. ditto. Please give me a pointer here.
Again, the terminology section of another RFC isn't a very good place to refer to. I would like to know exactly what format is required here. Section 2.2 just says:
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.
which does not tell at all what might appear here. Or do you mean that the MIB contains binary information that may be in very different formats depending on what type of link layer the MAG runs on? That would be OK as well, but you should be explicit about it.
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.Yes. It will be current mobile nodes. The description will be fixed.
OK.
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 http://tools.ietf.org/html/rfc5213" rel="nofollow"><http://tools.ietf.org/html/rfc5213>: Section 8.5 http://tools.ietf.org/html/draft-ietf-netlmm-pmipv6-mib-02#section-8.5" rel="nofollow"><http://tools.ietf.org/html/draft-ietf-netlmm-pmipv6-mib-02#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" rel="nofollow">http://www.iana.org/assignments/mobility-parameters/mobility-parameters.txt note the 3GPP etc items that do not appear in your list above...We will add 6 3GPP GERAN (6) 7 3GPP UTRAN (7) 8 3GPP E-UTRAN (8) 9 3GPP2 eHRPD (9) 10 3GPP2 HRPD (10) 11 3GPP2 1xRTT (11) 12 3GPP2 UMB (12) to the list. And provide reference to http://www.iana.org/assignments/mobility-parameters/mobility-parameters.txt" rel="nofollow">http://www.iana.org/assignments/mobility-parameters/mobility-parameters.txt
Good.
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?Will be "activated". We will add some text to the Description.
OK
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 http://tools.ietf.org/html/rfc5213" rel="nofollow"><http://tools.ietf.org/html/rfc5213>: Section 2 http://tools.ietf.org/html/draft-ietf-netlmm-pmipv6-mib-02#section-2" rel="nofollow"><http://tools.ietf.org/html/draft-ietf-netlmm-pmipv6-mib-02#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?It is typo. Will fix it: mobile node's => mobile nodes'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?As explained above, InetAddress can be potentially 255 octets long- thus the convention for MIBs using this object is to include the warning. The Compliance says that support for IPv6 addresses is required. In that case there will be no problems.
Ok. Please explain somewhere that with IPv6 address type which is required there can never be a problem.
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 http://tools.ietf.org/html/rfc5213" rel="nofollow"><http://tools.ietf.org/html/rfc5213>: Section 6.2 http://tools.ietf.org/html/draft-ietf-netlmm-pmipv6-mib-02#section-6.2" rel="nofollow"><http://tools.ietf.org/html/draft-ietf-netlmm-pmipv6-mib-02#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...The Description will be fixed.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?Not really. The same convention as in MIPv6 MIB is followed.
OK...
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 http://tools.ietf.org/html/rfc5213" rel="nofollow"><http://tools.ietf.org/html/rfc5213>: Section 5.1 http://tools.ietf.org/html/draft-ietf-netlmm-pmipv6-mib-02#section-5.1" rel="nofollow"><http://tools.ietf.org/html/draft-ietf-netlmm-pmipv6-mib-02#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.The idea was that the Timestamp may be of interest (it is more than just a number - tells us when the sessions was started etc.). The sequence number is of much less interest. Do we want to have the Sequence number ?
When in doubt, I would include more information. Either value might be useful for debugging, for instance.
(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 http://tools.ietf.org/html/rfc5213" rel="nofollow"><http://tools.ietf.org/html/rfc5213>: Section 5.1 http://tools.ietf.org/html/draft-ietf-netlmm-pmipv6-mib-02#section-5.1" rel="nofollow"><http://tools.ietf.org/html/draft-ietf-netlmm-pmipv6-mib-02#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?This table AUGMENTS the "Mobile IPv6 MIB" table. So effectively all Binding cache entries will be there. But, the augmented part will have information only for FLAG=1 entries. In that sense a Flag=0 will not appear in this part of the table.
OK
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 onThis is the first time that nemoStatus appears in the document.Typo - fixed.When using http://www.ibr.cs.tu-bs.de/bin/smitools.cgi" rel="nofollow">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 specificationAt least some of these seem real problems. Please fix.The new compiler now flags a warning if the DISPLAY-HINT for the TEXTUAL CONVENTIONS are not given. This will be fixed.
Thanks for your response. Hope my answers enable you to make the edits. Ask again if I missed or misunderstood something.
Jari
- [netlmm] AD review of draft-ietf-netlmm-pmipv6-mib Jari Arkko
- Re: [netlmm] AD review of draft-ietf-netlmm-pmipv… Glenn M. Keeni
- Re: [netlmm] AD review of draft-ietf-netlmm-pmipv… Glenn M. Keeni
- Re: [netlmm] AD review of draft-ietf-netlmm-pmipv… Glenn M. Keeni
- Re: [netlmm] AD review of draft-ietf-netlmm-pmipv… Jari Arkko
- Re: [netlmm] AD review of draft-ietf-netlmm-pmipv… Jari Arkko
- Re: [netlmm] AD review of draft-ietf-netlmm-pmipv… Glenn M. Keeni
- Re: [netlmm] AD review of draft-ietf-netlmm-pmipv… Glenn M. Keeni
- Re: [netlmm] AD review of draft-ietf-netlmm-pmipv… Jari Arkko