IPCDN Interim Meeting
2/13/03
Notes taken by Greg Nakanishi
- references/citations in
abstract are not allowed per
RFC-Editor policy
- 2nd para in abstract seems
not needed. but I can live
with it
- Title of sect 1 is not
inline with MIB boilerplate
- 3rd para in section 1 is
not needed, in fact I'd rather
see it removed. The RFC3410 explains all that.
- DESCRIPTION clause of
MODULE-IDENTITY is missing the
MIB copyright statement
- I had asked in earlier
email:
Mmm.. did I review rev 07. I can't quickly find that I
did send a review report.
I am assuming that you will take care of all the comments
that are (in my view) to be expected based on the review
of the subscriber mib I did, right?
- Is this MIB obsoleting an
earlier (RFC) version?
If so, then that should noted on front page/abstract
and we should see a revision statement that lists the
original RFC.
If this is the first time this MIB gets published as an
RFC, then we want to see only one simple revisions clause
with a DESCRIPTION aka:
"Initial version, published as RFC xxxx."
-- RFC-editor assigns xxxx
We do not want to see long lists of changes that happened
during initial revisions of Internet Drafts
All above comments accepted
as-is.
- And how did you decide to
assign the
docsBpi2MIB MODULE-IDENTITY
...
::= { docsIfMib 6 }
I worry a lot about this practice, cause it is very difficult
to keep track and to ensure that no conflicts arise.
The MIB will be re-rooted to
a yet to be determined location.
- I worry about:
X509Certificate ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"An X509 digital certificate encoded as an
ASN.1 DER
object."
SYNTAX OCTET
STRING (SIZE (0..1400))
The reason is that this is not some X509 generic Certificate
but a special one for your IPCDN use.
How about renaming it to DocsX509ASN1DEREncodedCertificate ??
Accept name change.
- docsBpi2CmAuthReset OBJECT-TYPE
Would it be wise to add a docsBpi2CmAuthLastReset object
similar as what was done in the subscriber MIB module?
New object will not be added. docsBpi2CmAuthReset description will be updated to indicate that this object is for testing purposes only. Operators are not likely to perform BPI+ authorization resets for real customers.
- objects like:
docsBpi2CmAuthRejects
OBJECT-TYPE
SYNTAX
Counter32
MAX-ACCESS
read-only
STATUS
current
DESCRIPTION
"The value of this object is the count of
times the CM
has received an Authorization Reject message, since
reboot."
require that a Counter starts at zero. But those are NOT the
semantics of a Counter32. If this is what you want, I think you
need to use the ZeroBasedCounter32 as per RFC2021.
Pls read draft-ietf-ops-mib-review-guidelines-00.txt sect 4.6
specifically 4.6.1.2
- You have quite a few of
those objects
docsBpi2CmAuthRejectErrorString OBJECT-TYPE
SYNTAX SnmpAdminString
(SIZE (0..128))
MAX-ACCESS
read-only
STATUS
current
DESCRIPTION
"The value of this object is the
Display-String in
S/Display-String/text string/ ??
Same for docsBpi2CmAuthInvalidErrorString
And for docsBpi2CmTEKKeyRejectErrorString
docsBpi2CmTEKInvalidErrorString
docsBpi2CmIpMulticastSAMapRejectErrorString
docsBpi2CmtsAuthInvalidErrorString
- docsBpi2CmTEKDataEncryptAlg
OBJECT-TYPE
SYNTAX
INTEGER {
none(0),
des56CbcMode(1),
des40CbcMode(2)
}
We recommend to start Enumerations from 1.
Possibly the 1 and 2 for the desXxxx enumerations are so
numbered
to align with some other place. If so, then starting with zero
seems acceptable. But pls add some explanation in that case
Same question for similar xxxCrypto object
The attendees found an acceptable compromise on MIB enumerations:
1. The standard policy will be that enumerations will start from 1.
2. If there is a really good reason to deviate from that policy, e.g. to match the enumeration in protocol messages, then the author needs to explain the enumeration rationale in the MIB object DESCRIPTION.
As a general rule, it is up to the MIB authors to choose which of the two cases above applies.
- docsBpi2CmTEKDataAuthentAlg OBJECT-TYPE
SYNTAX
INTEGER {
none(0)
}
An object that can only have one value that is ALWAYS zero?
What is the use of that? Maybe future extensibility, but if so,
then please say so in DESCRIPTION clause, otherwise this
seems nonsense and bloat.
Same question for similar xxxCrypto object
Add description
“for future extensibility”.
- docsBpi2CmIpMulticastIndex OBJECT-TYPE
SYNTAX
Integer32 (1..1000)
It is valid. But for INDEX objects we prefer Unsigned32 with
a range. see again the mib review guidelines doc
I think this occurs a few more time in this MIB module.
As I say, it is valid, but since your still working on this
MIB module, might as well use the recommended method.
Accepted – change to Unsigned32.
- docsBpi2CmIpMulticastAddress OBJECT-TYPE
SYNTAX
InetAddress
MAX-ACCESS
read-only
STATUS
current
DESCRIPTION
"This object represents the IP multicast
address
to be mapped."
you MUST specify with InetAddressType object defines the context
or type of this object. You did it correct in subscriber mib.
Accepted – will update
description is specify which InetAddressType object defines the type of this
object.
- docsBpi2CmtsDefaultSelfSignedManufCertTrust OBJECT-TYPE
SYNTAX INTEGER
{
trusted (1),
untrusted (2)
}
Seems to me that docsBpi2CmtsDefaultSelfSignedManufCertTrusted
descriptor with a syntax of TruthValue is more appropriate
Accepted. Change name (e.g. docsBpi2CmtsDefaultSelfSignedManufCertTrusted) and make it a truthValue
- docsBpi2CmtsCheckCertValidityPeriods OBJECT-TYPE
SYNTAX
TruthValue
MAX-ACCESS
read-write
STATUS
current
DESCRIPTION
"Setting this object to TRUE causes all chained and
The better wording is:
"Setting this object to 'true' causes all chained and
This occurs a few more times in this MIB module
Accepted.
- docsBpi2CmtsAuthCmBpiVersion
OBJECT-TYPE
SYNTAX
INTEGER {
bpi (0),
bpiPlus (1)
}
Any special reason why enumeration cannot start at 1?
Leave it as-is. Add additional description to describe linkage to ‘modem capabilities’ TLV.
- docsBpi2CmtsAuthCmReset
OBJECT-TYPE
Yet another way in which you guys do resets.
No change to object. Add description to text part of document comparing the CM and CMTS reset objects.
- docsBpi2CmtsAuthCmInfos OBJECT-TYPE
SYNTAX
Counter32
MAX-ACCESS read-only
STATUS
current
DESCRIPTION
"The value of this object is the count of
times the
CMTS has received an Authentication Information message
from
this CM, since entry creation."
ZeroBasedCounter32 ??
You have several of those
If enumeration has to start at 0, author to put description for Why. Otherwise start enumeration at 1.
- docsBpi2CmtsAuthBpkmCmCertValid OBJECT-TYPE
SYNTAX INTEGER
{
unknown (0),
validCmChained (1),
validCmTrusted (2),
invalidCmUntrusted (3),
invalidCAUntrusted (4),
invalidCmOther (5),
invalidCAOther (6)
}
Any special reason to start ENUMERATION with zero??
- docsBpi2CmtsTEKSAType
OBJECT-TYPE
SYNTAX
INTEGER {
none(0),
primary(1),
static(2),
dynamic(3)
}
Any special reason to start ENUMERATION with zero??
There are more of those... I won’t list them anymore,
I guess you get the gist.
- I wonder if it would not
be better to have 2 compliance
statements, one for CM and one for CMTS.
It is unclear to me if any GROUPS are mandatory. I think
some are, but it depends if your are CM or CMTS
- -- relaxation on IP addressing
OBJECT
docsBpi2CmIpMulticastAddressType
-- SYNTAX InetAddressType { ipv4(1) }
Pls make it a real SYNTAX clause and not a comment.
That SMICng barks at it is something we know and SMICng
should be fixed.
- You have citations in
DESCRIPTION clauses. We normally do not
do that, cause they will be lost when people extract the
MIB module from the RFC.
- Mmm.. you start off with
some OBSOLETED object group right
away here? You might want to say something about when/why that
happened.
Note that obsolete objects can actually be removed when re-rooting of mibs takes place.
General comment for
CableLabs certification – Matt, Greg W expressed desire to keep draft-05
through CW26, instead of draft-08. Adoption by CableLabs should wait until RFC
publication – hence the need to re-root this MIB.
- References need to be split
in normative and informative
- You have picked up the new
MIB boilerplate, but you still
have a lot of old MIB boilerplate references included, which
make no sense anymore
- The new MIB boilerplate
has [RFC2578], [RFC2579] and [RFC2580]
as citations, but they do not show as such in the references
section
- The security
considerations section is not compliant with the
new MIB security guidelines. The subscriber MIB has
done a much better job. You should too.
- I see 3 names in
CONTACT-INFO while only two are listed
i. on front page and only two are listed in Author's addresses?
Accepted.
Goal is to publish draft-09 by the end of the month.
For all IPCDN MIBs: All new DOCSIS MIBs should have the module name changed. Use the convention DOCS-IETF-XXX-MIB.
-
first
para of sect 1 is redundant
OK
- This is the first RFC-to
be. So we do not want to see
longs list of REVISION clauses with pre-RFC changes
- IfDirection, probably
better named DocsRFMacIfDirection
it is not generic TC.
In any event, it conflicts with IfDirection in RFC3289
(which I guess should have had another name too).
Accepted.
- In general, I'd like your
TCs to start with DocsXxxx
Accepted.
- We prefer integer-based
INDEX objects to be Unsigned32
(with a range that excludes zero)
- You seem to have used
RFC2851 when understanding InetAddresType
and InetAddress. Pls see the newer RFC3291, which also explains
that you can use one InetAddressType to specify the type of
multiple Addresses. That will reduce the size of the MIB module
somewhat I expect. The xxxMask objects probably should be
InetAddressPrefixLength TC
- RFC3291 also has InetPort
as a TC that you probably should use
- I am not happy with
docsQosPktClassIpProtocol OBJECT-TYPE
SYNTAX
Integer32 (0..258)
See RFC3289
diffServMultiFieldClfrProtocol OBJECT-TYPE
SYNTAX
Unsigned32 (0..255)
And you will hopefully understand why
Object will be changed to Unsigned32. Bert to look further into if this is
acceptable.
- When I see things like:
docsQosPktClassState OBJECT-TYPE
SYNTAX INTEGER
{
active(1),
inactive(2)
}
I always wonder if a TruthValue is not better
OK, name object docsQosPktClassStateActive and change syntax to TruthValue.
- Have you checked your use
of VLANID with other MIB modules
where they use it?
Further investigation needed.
- docsQosParamSetServiceClassName
OBJECT-TYPE
SYNTAX
DisplayString
Is this intended for human consumption? Then RFC2277 says it
must allow for internatioalization, so an SnmpAdminString or
some other UTF-8 based TC seems better
Keep as DisplayString because DOCSIS object is restricted to ASCII. Restrict Range between 2 to 16.
- For Counter (both 32 or
64) you must specify a discontinuity
object (often a timer). See the Counter32 and Counter64 specs
in RFC2578
Accepted. Add reference to a discontinuity object.
-
docsQosServiceFlowTimeActive OBJECT-TYPE
SYNTAX
Counter32
UNITS
"seconds"
MAX-ACCESS
read-only
STATUS current
DESCRIPTION "The
total time that service flow has been active."
I would say "The number of seconds that the flow has been
active."
That way I can see it has Counter32 semantics, otherwise that is
hard
to see.
Accepted.
- docsQosServiceClassTable
Can you pls add a StorageType object or specify the persistency
behavior of entries in this table?
Accepted.
- OBJECT
docsQosPktClassInetSourceAddrType
-- SYNTAX InetAddressType { ipv4(1) }
Remove the two dashed. This is a valid statement. SMICng
needs fixing
Accepted.
- docsQosMaxParamBurst – typos in description.
- DocsQoSParamAndMask – typo in description.
- The references only refer to DOCSIS 1.1. Also reference DOCSIS 2.0.
|
Name |
Company |
Email |
|
Richard
Woundy |
Comcast |
|
|
Jean-François
Mulé |
CableLabs |
|
|
Matt
Osman |
CableLabs |
|
|
Diego R.
Mazzola |
TI |
|
|
Greg
Nakanishi |
Motorola |
|
|
David
Raftus |
IMedia |
|
|
Azlina
Ahmad |
Cisco |
|
|
Will
Murwin |
Motorola |
|
|
Doug
Jones |
Yas |
|
|
Matt
Schmitt |
Arris |
|
|
Eduardo
Cardona |
CableLabs |
|
|
Bert
Wijnen |
Lucent |
|
|
Alexander
Katsnelson |
CableLabs |
|
|
Kevin
Luehrs |
CableLabs |
|
|
Thomas
Narten |
IBM |
|
|
Michael
Patrick |
Motorola |
|
|
Wilson
Sawyer |
Arris |
|
|
Greg
White |
CableLabs |