I-X stands for Issue-X and R-X stands for Response to Issue-X As fo now there are 20 issues. The summary is given below. Details of Issues and responses ==============================> I-1. >>> >>> - 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? R-1. -> This is a MAG table. Text has been added to clarify which table is where. I-2. >> >> >>> >>> - 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? R-2. Fixed the text contains the Home Network Prefixes assigned to interfaces of all mobile nodes attached to the MAG. I-2.1. >> >> Same issue in pmip6LmaHomeNetworkPrefixTable. R-2.1. -> This table has HNPs of all mobile nodes anchored on a LMA. (This table has "pmip6MagBLlMnIdentifier" in Indexes.) Fixed the text. contains the list of Home Network Prefixes assigned to the connected interfaces of the mobiles nodes anchored on a LMA. I-3. >>> >>> - 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? R-3. -> This is a LMA table. Text has been added to clarify which table is where. I-4. >> >> >>> >>> 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. R-4. -> Fixed the DESCRIPTION and REFERENCE "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. Various forms of identifiers can be used to identify a mobile node (MN). Two examples are a Network Access Identifier (NAI) [RFC4282] and an opaque identifier applicable to a particular application. " REFERENCE "RFC 4283: Section 3" I-5. >> >> >>> >>> 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? R-5. -> Fixed the REFERENCE I-6. >> >> >>> >>> 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. R-6. -> Fixed the DESCRIPTION. The scope is that of the current mobile nodes. I-7. >> >> >>> >>> 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... R-7. -> Fixed the SYNTAX There are 7 3GPP/3GPP2 items. We have to add those as (6) -- (12). 0 Reserved (0) 1 Virtual (1) 2 PPP (2) 3 IEEE 802.3 (3) 4 IEEE 802.11a/b/g (4) 5 IEEE 802.16e (5) 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) I-8. >> >> >>> >>> 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. >> >> I-9. >> >> (Same issue in pmip6Binding table) >> >> R-8,9 -> that is the way it is done in MIBS (MIPv6MIB, NeMoMIB). The MIB itself is not constrained to work for any specified InetAddress type. However it defines a compliance e.g. pmip6CoreCompliance where only IPv6 address types are required to be implemented. I-10 >>> >>> 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? R-10. -> The DESCRIPTION is fixed. activated -- The Proxy-CoA is ready to establish a tunnel. This state SHOULD be indicated when the MAG is up but has no mobile node. I-11. >> >> >>> >>> 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? R-11. -> Fixed the DESCRIPTION. "A table representing the Home Network Prefixes assigned to the connected interfaces of mobile nodes attached to the MAG. I-12. >> >> >>> >>> 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? >> >> R-12. The InetAddress type allows strings of length 0-255 octets. The maximum length of an index is 128 octets. So, use of inappropriate InetAddress types in the index would lead to problems. Thus a warning is added to the description clauses. But, if the address type is IPv6 as explained in R-8 then we have only 16 octets, and it will not really be a problem. I-13. >> >> (Same issue in pmip6LmaLMAAEntry and pmip6LmaHomeNetworkPrefixEntry) >> >> R-13. -> See R-12. I-14. >>> >>> 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... R-14. -> DESCRIPTION fixed. "The lifetime parameter (in seconds) that will be advertised in Router Advertisements by the MAG for this Home Network Prefix. " I-15. >> >> >>> >>> 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? R-15. -> This abbreviation is consistent with "RFC 4295" (mip6MnBLTable). I-16. >> >> >>> >>> 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. >> >> R-16. We already have mip6MnBLMaxSeq [RFC4295] this should do. I-17. >> >> (Same issue in pmip6Binding table) R-17 -> We already have mip6BindingMaxSeq [RFC4295] this should do. I-18. >> >> >>> >>> 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? R-18. -> 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. If Flag=0 the remaining entries of this table will not be available/accessible. The DESCRIPTION is updated. I-19. >> >> >>> >>> 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. R-19. -> Typo fixed. nemoStatus -> pmip6Status I-20 >> >> 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. R-20. -> Done. Added Display hints for the textual conventions that are causing warnings from the updated MIB compiler. >> >> Summary of Responses/Actions ==========================================> R-1 : This is a MAG table. Text has been added to clarify which table is where. R-2 : Fixed the text. R-2.1: Fixed the text. R-3 : This is a LMA table. Text has been added to clarify which table is where. R-4 : Fixed the DESCRIPTION and REFERENCE R-5 : Fixed the REFERENCE R-6 : Fixed the DESCRIPTION. R-7 : There are 7 3GPP/3GPP2 items. Add those as (6) -- (12) Fixed the Object SYNTAX R-8 : That is the way it is done in MIBS (MIPv6MIB, NeMoMIB). The MIB itself is not constrained to work for any specified InetAddress type. However it defines a compliance e.g. pmip6CoreCompliance where only IPv6 address types are required to be implemented. R-9 : Same as for I-8. R-10 : The DESCRIPTION is fixed. R-11 : The DESCRIPTION is fixed. R-12 : The InetAddress type allows strings of length 0-255 octets. The maximum length of an index is 128 octets. So, use of inappropriate InetAddress types in the index would lead to problems. Thus a warning is added to the description clauses. But, if the address type is IPv6 as explained in I-8 then we have only 16 octets, and it will not really be a problem. R-13 : Same as for I-12 R-14 : DESCRIPTION fixed "The lifetime parameter (in seconds) that will be advertised in Router Advertisements by the MAG for this Home Network Prefix. " R-15 : Consistent with RFC4295 R-16 : We already have mip6MnBLMaxSeq [RFC4295] this should do. R-17 : We already have mip6BindingMaxSeq [RFC4295] this should do. R-18 : The DESCRIPTION is updated. R-19 : Fix Typo nemoStatus -> pmip6Status. R-20 : Added Display hints for the textual conventions that are causing warnings from the updated MIB compiler.