RE: I-D ACTION:draft-ietf-ipcdn-bpiplus-mib-13.txt
"Eduardo Cardona" <[email protected]>
| Newsgroups | gmane.ietf.ipcdn |
|---|---|
| Message-ID | <[email protected]> |
Bert, IPCDN participants,
as you may noticed a new draft (13) was published on time for I-D cutoff
for the upcoming meeting
Bert,
Thanks for all the detailed comments, below are the clarification notes
added to the published draft.
>From the POV of significant changes I only see item 1. as a possible
change of requirements by defining persistence where the Draft was not
clear:
Recently updates to BPI OSS requirements introduces persistent
requirement to configurable structures like
docsBpi2CmtsProvisionedCmCertEntry, docsBpi2CmtsCACertEntry
In a generalized way MULTICAST SAID assignments and CM authorization for
static Multicast are the areas where persistent requirements have been
added to maintain consistency around user configured data.
Below is the list of items in your review with the appropriate comments
as are now in draft-13
Thanks
Eduardo
More or less serious:
1. I see various read-write and/or read-create objects and I do
not see any text in the DESCRIPTION clauses (non STorageType objects)
that tell me what the expected behavior is w.r.t. persistency of such
objects. SO what happens after a restart/reboot?
<edo>
read-write objects:
docsBpi2CmAuthReset:
N/A testing purposes see description
docsBpi2CmDeviceCmCert:
-added persistence, already a requirement that might be implicit in
current description but not explicit.
docsBpi2CmtsDefaultAuthLifetime
docsBpi2CmtsDefaultTEKLifetime
Added to both objects:
"This object value persist after reinitialization of the managed
system."
docsBpi2CmtsDefaultSelfSignedManufCertTrust:
BPI spec calls for a testing object not recommended as an operational
parameter Do not persist Description clarified "this" instead of "the"
docsBpi2CmtsCheckCertValidityPeriods:
With a period validity of 20 years and re-issued certificated within 2
years of expiration do not indicates any usage of this object rather
than testing No need of persistence. added
"This object value needs not to persist after reinitialization of the
managed system.."
docsBpi2CodeCvcUpdate
added first sentence:
"then the content of this object is discarded."
See BPI spec pointed by REFERENCE section D.3.3.2.2.
read-write objects in non-dynamic tables:
docsBpi2CmtsAuthEntry
Entries are deleted after CM de-registers
docsBpi2CmtsTEKEntry
Entries are deleted when the SAID expires
read-create:
docsBpi2CmtsMulticastAuthEntry, docsBpi2CmtsIpMulticastMapEntry
A Multicast Group ca be mapped by the CMTS to primary. Static or dynamic
SA.
For the MulticastMapEntry
it is not expected to have a multicast group mapped to a primary SA to
persist after reboot
Typically a static SA mapped to a multicast group is required to
persist, It implies entries in MulticastAuthEntry for specific
authorized CMs
Operator may decide also to create a MulticastMapEntry with SAIDType
dynamic to track the multicast group with a specific SAID.
If that condition is valid, there is no way to know a CMTS dynamically
created MulticastMapEntry vs a provisioned one
- It requires the introduction of StorageType in MulticastMapTable with
syntax read-only:
depending on CMTS created or provisioned entries the row storage type
could be
defined as :
e.g SAIDType = primary will be volatile
SAIDtype = static will be non-volatile
SAIDType = dynamic:non-volatile for provisioned entries,
volatile for CMTS dynamically mapped multicast group. The
main advantage is to allow the BPI and OSS spec to concrete define the
management requirements for this cases, including the mandate of
persistence.
MulticastAuthEntry form the point of view of the MIB management
perspective and operations should be stated as persistent explicitly.
docsBpi2CmtsMulticastAuthEntry
Added : SAIDs of type static
Row entries persist after reinitialization of
the managed system.
docsBpi2CmtsIpMulticastMapEntry
added:
docsBpi2CmtsIpMulticastMapStorageType OBJECT-TYPE
SYNTAX StorageType
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The storage type for this conceptual row."
::= { docsBpi2CmtsIpMulticastMapEntry 15 }
docsBpi2CmtsIpMulticastSAType
added:
SNMP created entries set this object by default
to 'static' if not set at row creation.
docsBpi2CmtsProvisionedCmCertEntry
Added:(updates to OSSI specification:
Row entries persist after reinitialization of
the managed system.
REFERENCE
"Data-Over-Cable Service Interface Specifications:
Operations Support System Interface Specification
SP-OSSIv2.0-I05-040407, Section 6.2.14"
docsBpi2CmtsCACertEntry
Added (updates to OSSI specification:
Row entries with trust status 'trusted', 'untrusted',
or 'root' persist after reinitialization of the managed
system."
REFERENCE
"Data-Over-Cable Service Interface Specifications:
Operations Support System Interface Specification
SP-OSSIv2.0-I05-040407, Section 6.2.14"
</edo>
2. I see a number of ZeroBasedCOunter32 objects that have text aka:
(for example docsBpi2CmAuthentInfos)
DESCRIPTION
"The value of this object is the count of times the CM
has transmitted an Authentication Information message,
since reboot."
It is OK to tell us that a ZeroBasedCOunter32 object must start with
zero
at (re-)boot time or at row creation.
But from that point on, a ZeroBasedCounter32 behaves exactly the same
as a Counter32, and so it is incorrect to say "count of X since
reboot"
because the Counter32 may have wrapped!. Possibly this is not gonna
happen in practice, but literally the claim is incorrect.
3. For these ZeroBasedCounter32 objects, I also see no word about a
possible
discontinuity timer. Why not. Can there NEVER be a discontinuity? Of
if
there is one does that mean ALL counters experience a discontionuity?
The latter is what you basically state (or cause) by not pointing to
a
specific discontinuity timer. Because then by default it is
sysUpTime, and
so that means that when you DO experience a discontinuity, then you
MUST
reset sysUpTime and that means that a discontinuity for EVERYONE
(object)
that assumes the default. If such is intended, then fine, but it
would be
good to then state that sysUpTime is the discontinuity timer.
<edo>
docsBpi2CmAuthentInfos
docsBpi2CmAuthRequests
docsBpi2CmAuthReplies
docsBpi2CmAuthRejects
docsBpi2CmAuthInvalids
discontinuity is sysUpTime
removed counts since reboot
added:
"Reinitialization of this counter occurs at boot time.
Discontinuities of this counter are indicated by sysUpTime."
docsBpi2CmTEKKeyRequests
docsBpi2CmTEKKeyReplies
docsBpi2CmTEKKeyRejects
docsBpi2CmTEKInvalids
docsBpi2CmTEKAuthPends
discontinuity is sysUpTime
removed since registration
added:
"Reinitialization of this counter occurs at boot time.
Discontinuities of this counter are indicated by sysUpTime."
docsBpi2CmIpMulticastSAMapRequests
docsBpi2CmIpMulticastSAMapReplies
docsBpi2CmIpMulticastSAMapRejects
Delete:
"Since entry creation"
Add:
"Discontinuities of this counter are indicated by sysUpTime."
docsBpi2CmtsAuthentInfos
docsBpi2CmtsAuthRequests
docsBpi2CmtsAuthReplies
docsBpi2CmtsAuthRejects
docsBpi2CmtsAuthInvalids
docsBpi2CmtsSAMapRequests
docsBpi2CmtsSAMapReplies
docsBpi2CmtsSAMapRejects
Add:
"Discontinuities of this counter are indicated by sysUpTime and
ifCounterDiscontinuityTime for the associated ifIndex."
Delete:
"since entry creation"
docsBpi2CmtsAuthCmInfos
docsBpi2CmtsAuthCmRequests
docsBpi2CmtsAuthCmReplies
docsBpi2CmtsAuthCmRejects
docsBpi2CmtsAuthCmInvalids
updated Entry object to indicate MAC interface dependency for IfIndex
"Discontinuities of this counter are indicated by sysUpTime and
ifCounterDiscontinuityTime for the associated ifIndex."
Delete:
"since entry creation"
docsBpi2CmtsKeyRequests
docsBpi2CmtsKeyReplies
docsBpi2CmtsKeyRejects
docsBpi2CmtsTEKInvalids
"Discontinuities of this counter are indicated by sysUpTime and
ifCounterDiscontinuityTime for the associated ifIndex."
Delete:
"since registration"
docsBpi2CmtsIpMulticastSAMapRequests
docsBpi2CmtsIpMulticastSAMapReplies
docsBpi2CmtsIpMulticastSAMapRejects
Added:
"Discontinuities of this counter are indicated by sysUpTime and
ifCounterDiscontinuityTime for the associated ifIndex."
Delete:
"since entry creation"
</edo>
4. I see that for some objects you speak about a "null string" or "NULL
string".
The base data type for such objects is OCTET STRING. In all those
cases
I suspect (but I am not sure) that you mean the zero-length octet
string.
Otherwise I do not understand what "null string" means.
Pls explain and fix.
<edo>
Added:
docsBpi2CodeCvcUpdate OBJECT-TYPE
Reading this object always returns the zero-length string."
docsBpi2CmtsCACertThumbprint OBJECT-TYPE
Note: The zero-length string must be returned if this object is
not supported by the CMTS."
docsBpi2CmtsCACert OBJECT-TYPE
Note: The zero-length string must be returned, on reads, if the
entire certificate is not retained in the CMTS."
docsBpi2CmtsProvisionedCmCert OBJECT-TYPE
Note: The zero-length string must be returned, on reads, if the
entire certificate is not retained in the CMTS."
docsBpi2CmtsAuthBpkmCmCert OBJECT-TYPE
Note: The zero-length string must be returned if the entire
certificate is not retained in the CMTS."
docsBpi2CmDeviceCmCert OBJECT-TYPE
Note: This object can be set only when the value is the
zero-length string. Once the object contains the
certificate, its access MUST be read-only."
</edo>
5. For docsBpi2CmtsAuthCmExpiresOld I see:
Note: For CMs running in BPI mode, implementation of this
object is optional and MAY vary."
Mmm... that sounds like a MODULE-COMPLIANCE aspect and I would rather
see such things in MODULE-COMPLIANCE and not in object DESCRIPTION
clauses.
A CMTS keeps track of the old and new authentication keys for example to
do seamless traffic Key updates (using a hand-shacking algorithm based
on the authentication key (old or new), CMs running in 1.0 mode follows
BPI protocol (RFC 3083) which has no concept of old/ new key expire
time, therefore the CMTS only have to track the most recent
authentication key expire to validate outstanding BPI security requests.
Rather than a Compliance statement ( the object MUST be supported) I
believe an indication of
"Note: For CMs running in BPI mode, this object value has no
meaning, therefore the CMTS may not instantiate this object
for those CM entries."
6. I see:
-- Note: the following object has been obsoleted
docsBpi2CmtsAuthCmReset OBJECT-TYPE
SYNTAX INTEGER {
noResetRequested(1),
invalidateAuth(2),
sendAuthInvalid(3),
invalidateTeks(4)
}
MAX-ACCESS read-write
STATUS current
So the --Note: is out of sync with the actual status!?
What is it? If it IS obsoleted, then status should sya so,
And DESCRIPTION clause should explain why it was obsoleted.
And the ASN.1 comment line then of course is no longer needed.
<edo>
The note applies to docsBpi2CmtsAuthCmGraceTime which was already
removed
In draft 12
Draft 11
docsBpi2CmtsAuthCmLifetime ::= { docsBpi2CmtsAuthEntry 7 }
-- Note: the following object has been obsoleted
docsBpi2CmtsAuthCmGraceTime ::= { docsBpi2CmtsAuthEntry 8 }
docsBpi2CmtsAuthCmReset ::= { docsBpi2CmtsAuthEntry 9 }
docsBpi2CmtsAuthCmLifetime ::= { docsBpi2CmtsAuthEntry 7 }
-- Note: the following object has been obsoleted -- remove
docsBpi2CmtsAuthCmReset ::= { docsBpi2CmtsAuthEntry 8 }
</edo>
7. I see:
docsBpi2CmtsAuthCACertIndexPtr OBJECT-TYPE
SYNTAX Integer32 (0..10000)
And find that a strange limit (range). And nowhere, not even in the
docsBpi2CmtsCACertTable do I see an explanation why that range makes
sense (assuming that it does).
<edo>
docsBpi2CmtsAuthCACertIndexPtr follows the size of
docsBpi2CmtsCACertIndex
Changed to
SYNTAX Unsigned32 (1..4294967295)
docsBpi2CmIpMulticastIndex, docsBpi2CmtsIpMulticastIndex
SYNTAX Unsigned32 (1..4294967295)
</edo>
8. When I see:
docsBpi2CmtsIpMulticastAddressType InetAddressType,
docsBpi2CmtsIpMulticastAddress InetAddress,
docsBpi2CmtsIpMulticastMaskType InetAddressType,
docsBpi2CmtsIpMulticastMask InetAddress,
I wonder if (in the same row) docsBpi2CmtsIpMulticastMaskType will
ever
have a different value then docsBpi2CmtsIpMulticastAddressType !??
It seems to me that should NOT be allowed, cause otherwise I am not
sure how the ANDing of the Mask is going to work/happen.
So the next question then is why you do not do:
docsBpi2CmtsIpMulticastAddressType InetAddressType,
docsBpi2CmtsIpMulticastAddress InetAddress,
docsBpi2CmtsIpMulticastMask InetAddress,
And let docsBpi2CmtsIpMulticastAddressType be the discriminator for
both
InetAddresses. One less object, and less change for error/conflict.
But thinking even further, Possibly the best thing to do is to use
docsBpi2CmtsIpMulticastAddressType InetAddressType,
docsBpi2CmtsIpMulticastAddress InetAddress,
docsBpi2CmtsIpMulticastPrefixLength
InetAddressPrefixLength,
Are not such masks always setup that they basically specify a prefix
length?
If so, then this is the way to do it with the TCs from
INET-ADDRESS-MIB.
9. I see various uses of InetAddress as for example here:
docsBpi2CmtsIpMulticastAddress OBJECT-TYPE
SYNTAX InetAddress
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This object represents the IP multicast address
to be mapped, in conjunction with
docsBpi2CmtsIpMulticastMask."
The TC for InetAddress (in RFC3291 or its follow on) clearly state
that
you MUST specify which InetAddressType controls the format of this
object
as per DESCRIPTION from InetAddress TC:
An InetAddress value is always interpreted within the context
of an InetAddressType value. Every usage of the InetAddress
textual convention is required to specify the InetAddressType
object which provides the context. ...
<edo>
This issue was brought up before and Rich Woundy exposed a detail
explanation of the design requirements in favor of a netmask instead of
an InetPrefixLength /RFC2373/3513
See...
From: Woundy, Richard [mailto:[email protected]]
Sent: Wednesday, February 19, 2003 8:04 AM
To: 'Wijnen, Bert (Bert)'; IPCDN WG (E-mail)
Cc: Thomas Narten (E-mail); Erik Nordmark (E-mail); Randy Bush (E-mail)
Subject: RE: [ipcdn] InetAddress or PrefixLength as a mask
Perhaps a clarification note for object multicast netmask objects.
"This object needs not to represent a contiguous netmask i.e. to assign
to same multicast SAID multicast IPv6 addresses based on multicast
scopes and/or multicast group Ids."
added to docsBpi2CmtsIpMulticastAddress and docsBpi2CmtsIpMulticastMask:
"The address type of this object is specified by the value of the object
docsBpi2CmtsIpMulticastAddressType.
Deleted object docsBpi2CmtsIpMulticastMaskType
</edo>
10. I see:
docsBpi2CmtsIpMulticastMapControl OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This object controls and reflects the IP multicast
address mapping entry. There is no restriction on the
ability to change values in this row while the row is
active. Inactive rows need not be timed out."
Mmm... that "need not be timed out" seems in conflict with the
RowStatus
TC DESCRIPTION clause in RFC2579. Can you explain why this is?
Also, a RowSTatus object MUST specify in its DESCRIPTION clause
under
which conditions
- the row can be activated
- which columns (if any) can bve changed while in the active state.
I am missing the first.
<edo>
Removed the prohibition to age out inactive row entries.
Added:
"A created row can be set to active only after the corresponding
instances of
docsBpi2CmtsIpMulticastAddress, docsBpi2CmtsIpMulticastMask,
docsBpi2CmtsIpMulticastSAId and docsBpi2CmtsIpMulticastSAType have all
been set, otherwise the status of this object is 'notReady'".
</edo>
11. You specify:
--
-- The BPI+ MIB Conformance Statements (with a placeholder for
-- notifications)
--
docsBpi2Notification OBJECT IDENTIFIER
::= { docsBpi2MIB 2 }
docsBpi2Conformance OBJECT IDENTIFIER
::= { docsBpi2MIB 3 }
docsBpi2Compliances OBJECT IDENTIFIER
::= { docsBpi2Conformance 1 }
docsBpi2Groups OBJECT IDENTIFIER
::= { docsBpi2Conformance 2 }
Why not be (more) consistent with other MIB modules and follow the
suggested OID subtrees as per MIB guidelines,
draft-ietf-ops-mib-review-guidelines-03.txt, appendix D:
xxxMIB
|
+-- xxxNotifications(0)
+-- xxxObjects(1)
+-- xxxConformance(2)
|
+-- xxxCompliances(1)
+-- xxxGroups(2)
This is not mandatiory, but consistency is always useful/helpful
<edo>
Updated to follow the OPS recommendations
docsBpi2Notification OBJECT IDENTIFIER
::= { docsBpi2MIB 0 }
docsBpi2Conformance OBJECT IDENTIFIER
::= { docsBpi2MIB 2 }
</edo>
12. I see:
docsBpi2CmtsProvisionedCmCertStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Standard RowStatus object except:
a) if a row has ever been activated,
a set to docsBpi2CmtsProvisionedCmCert need not succeed,
b) inactive rows need not be timed out."
So you are changing the rules of the RowStatus TC? Seems not allowed
to me.
<edo>
Removed the prohibition to age out inactive row entries.
Removed the sentence " if a row has ever been activated, a destroy
setting need not succeed."
"Standard RowStatus objects except:
a) if a row has ever been activated,
a set to docsBpi2CmtsCACert need not succeed,
changed to:
" The status of this conceptual row. An attempt
to set writable columnar values while this row is active
behaves as follows:
- Sets to the object docsBpi2CmtsCACertTrust are allowed.
- Sets to the object docsBpi2CmtsCACert will return an error
inconsistentValue'."
<edo>
Nits/administrativia:
1. The RFC editor wants all references to have at least one citation
in the document. ALso for the normative references to RFCs from
which you import. See MIB review guidelines, sect 3.5
You need to add a citation somehwere for [RFC3411], [RFC2021],
[RFC3291], [RFC2670]
<edo>
Added references
</edo>
2. I see:
docsBpi2CmtsCACertSubject OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The subject name exactly as it is encoded in the
X509 certificate.
The organizationName portion of the certificate's subject
name must be present. All other fields are optional. Any
optional field present must be prepended with <CR>
(carriage return) <LF> (line feed) ASCII characters.
Ordering of fields present must conform to:
organizationName <CR> <LF>
countryName <CR> <LF>
A 7-bit ASCII character (which CR and LF are) does get represented
exactly
the same when UTF-8 encoded. But it is kind of weird to speak about
ASCII characters when discussing the content of a UTF-8 based OCTET
STRING.
I checked with our UTF-8 and Unicode expert (Patrik Faltstrom) and
he comes
up with this suggestion:
Replace sentence:
Any
optional field present must be prepended with <CR>
(carriage return) <LF> (line feed) ASCII characters.
with:
Any
optional field present must be prepended with <CR>
(carriage return, U+000D) and <LF> (line feed, U+000A).
You have this in a number of objects, pls check them all.
<edo>
</edo>
3. I see:
docsBpi2CmDeviceCmCert OBJECT-TYPE
SYNTAX DocsX509ASN1DEREncodedCertificate
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The X509 DER-encoded cable modem certificate.
Note: This object can be set only when the value is the
null string. Once the object contains the certificate, its
access MUST be read-only."
Maybe this is just wording.
- First, I already discussed the "null string" issue. I think you
mean
a zero length string or maybe better "zero length certificate" or
"zero length OCTET STRING" or "zero length value".
- Now, it seems to me that if the requirement is that the object has
a zero length value in order for a SET to be accepted, then, when
someone tries a SET while there is already a value, that then the
system ought to return a error that explains what is wrong. I.e.
an error that would otherwise not occur. If you get a notWritable,
then the management station does not necassarily know why that is,
see bullet 2 page 20 of RFC3416 or point 9 on page 21.
Maybe a better error would be a inconsistentValue, point 10 on page
21 of RFC3416?? Does that not seem a better way to indicate this
error?
<edo>
Added in description
"otherwise an error 'inconsistentValue'
is returned"
</edo>
4. I see:
docsBpi2CmTEKDataEncryptAlg OBJECT-TYPE
SYNTAX INTEGER {
none(0),
des56CbcMode(1),
des40CbcMode(2)
}
MAX-ACCESS read-only
I understand that this is read-only and so can only report what is in
the
Cm. But I would not be surprised if this will cause questions from
the
security folk. Is this the only envryption that is supported?
<edo>
Added a note in the security section
BPI+ Encryption Algorithms:
BPI+ Traffic Encryption Keys TEK uses DES 56 or 40 bits encryption
ciphers, due their cryptographic strength weakness, future revisions
of BPI+ specification [1] should introduce advanced encryption
algorithms to overcome the progress in cheaper and faster decryption
tools. CM BPI+ Authentication algorithms uses triple DES, which
guarantees strong BPI+ Authentication Traffic encryption keys updates
</edo>
5. I see:
docsBpi2CmtsDefaultSelfSignedManufCertTrust OBJECT-TYPE
SYNTAX INTEGER {
trusted (1),
untrusted (2)
}
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This object determines the default trust of
self-signed manufacturer certificate entries, contained in
docsBpi2CmtsCACertTable, created after setting the object."
I cannot say that I understand what "afetr setting the object" means.
which object?
<edo>
"after setting the object"
Changed to:
"after setting this object"
</edo>