[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [ipcdn] AD (MIB Dcotor) review of: draft-ietf-ipcdn-bpiplus-mib-11.txt
Thanks again for all the comments
Summary of actions for new draft
1. Agree, fixed
2. WHen I compile (syntax check) with smilint I get:
.\DOCS-IETF-BPI2-MIB:3076: [4] {compliance-group-status} warning:
current compliance statement `docsBpi2CmtsCompliance' includes
obsolete group `docsBpi2ObsoleteObjectsGroup'
>>>
Will remove docsBpi2ObsoleteObjectsGroup from CMTS compliance module as
GROUP clause
Rename GROUP-OBJECT docsBpi2ObsoleteObjectsGroup as
docsBpi2CmtsObsoleteObjectsGroup
3. Agree done
4. Agree done,
5. Agree done
Technical issues/questions
a. I am not sure I understand the relationship between RFC3083 and
this I-D. Would a device implement both MIB modules?
- If not,
>>>
Yes and No. Specs and MIBS are for capability compliances
BPI + is an enhancement of the BPI protocol, but BPI+ became a
different protocol.
Will propose to add a section in Overview (MIB Module Implementation)
to point to the specs references)
Something among:
BPI compliant devices support rfc 3083 (CM/CMTS)
BPI+ compliant devices support BPIPlus MIB BPI+, CM/CMTS.
Particularly, the CM, if instructed (configured) to
fall back to DOCSIS "1.0 mode" will support BPI compliant
<<<
- If yes, I see a lot of duplication and I wonder if that is
good, in fact I doubt it.
>>>
IT does not seems to be good for the duplication as yoou pointed
but the added objects ( 50+) in BPI+ look "very disorganized" if you add
all of them at the end of the respective tables, specially where peer
objects
are at initial tables OIDs
The bottom line, consider BPI and BPI + as different protocols, then
independent MIBS are needed
Two cases as examples
BPI has only one Auth key, so Param1 of Auth key, now should (?) match
OLD Auth key BPI+;
NEW Auth Key is exclusive of BPI+
Some parameters ranges ( protocol FSM fninite state machine) were
extended out of the original range
which would imply objects deprecation
An operator would have many capable 1.1/2.0 CMs but still manage them as
1.0 configured network in other words, CM operating as 1.0 modems with a
1.0 management system. It will imply support both MIBS simultaneously
for management and only one operational mode
Similar case as will happen with Ipv4/v6 transitions, IpForward MIB,
a vendor new box support v4/v6 dual stack but the box can also be
configured to support only IPv4 stack
Operator has legacy ipv4 boxes managemnt system but not IPv6
deployments.
What mib is going an operator to use? IMO, will use old Ipv4 Ipforward
Same case are DOCSIS transitions, the mib selection is a device
specification requirements, based on operator requests, RFPs, etc. ( in
this case MSO by CL standards).
I would agree that a whole grain of Compliance statements would be good,
but all those details are in the DOCSIS specs, The section I will add
will show all this references : here is a draft....
2.2 MIB Module implementation
This section describe the overall implementation framework of BPI+ MIB
module to clarify the relation with BPI MIB [RFC3083].
BPI/BPI+ MIB requirements depends both on the device specification
compliance and additionally for CM, of its DOCSIS operational mode when
connected to a partcular CMTS type
2.2.1 DOCSIS Specification Compliance Classification
DOCSIS currently defines three kinds of interoperable specification
compliance devices based on the DOCSIS RFI specifications:
DOCSIS 1.0 CM/CMTS defined in [3]
DOCSIS 1.1 CM/CMTS defined in [4]
DOCSIS 2.0 CM/CMTS defined in [5]
2.2.2 DOCSIS Operational Modes
DOCSIS operational mode refers to the CM specification compliance set of
functionalities and the interoperability requirements to connect to a
specific CMTS type (2.0, 1.1, 1.0). In general this document calls
DOCSIS 1.1 mode a configuration where a DOCSIS 2.0/1.1 CM can
interoperate with a 1.1 CMTS; in the same way, a DOCSIS 1.0 mode is a
configuration where a DOCSIS 2.0/1.1/1.0 CM can interoperate with a 1.0
CMTS. In the CMTS side a 2.0 CMTS can support simultaneously CMs
configured in either DOCSIS 2.0, 1.1 or 1.0 mode. For the scope of the
BPI+ requirements DOCSIS 2.0 mode is equivalent to DOCSIS 1.1 mode (*)
2.2.3 BPI/BPI+ MIB implementation:
Based on CM perational modes and CM/CMTS specification compliances below
is a summary of Baseline Privacy Interface MIB modules requirements
(BPI and BPI+)
1. DOCSIS 1.0 CM/CMTS only implements BPI MIB per [6],
2. DOCSIS 2.0 and 1.1 CMTS only implements BPI+ MIB per [8]
and[7] respectively
3. DOCSIS 2.0 and 1 1 CM in DOCSIS 1.0 mode implements BPI MIB
plus the BPI+ MIB objects associated with Authentication of
Downloaded Images
4. DOCSIS 2.0 and 1.1 CM in DOCSIS 1.1 mode (*) implements only
BPI+ MIB
5. DOCSIS 2.0 and 1.1 CM BPI MIB requirements are in [8] and [7]
respectively
<<<
b. I do not understand why one is Unsigned32 and the other Integer32
docsBpi2CmTEKSAId OBJECT-TYPE
SYNTAX Unsigned32 (1..16383)
docsBpi2CmIpMulticastSAId OBJECT-TYPE
SYNTAX Integer32 (0..16383)
docsBpi2CmtsAuthPrimarySAId OBJECT-TYPE
SYNTAX Integer32 (0..16383)
docsBpi2CmtsTEKSAId OBJECT-TYPE
SYNTAX Unsigned32 (1..16383)
docsBpi2CmtsIpMulticastSAId OBJECT-TYPE
SYNTAX Integer32 (0..16383)
docsBpi2CmtsMulticastAuthSAId OBJECT-TYPE
SYNTAX Unsigned32 (1..16383)
Oh well, a couple of TCs seems justified too, maybe a
DocsSAId and a DocsSAIdOrNone (or DocsSAIdOrZero) TC
>>>
Before the above list (integer32 vs Unsigned32) all were integer32
A previous discussion and revision recommended for indexes to use
Unsigned32
------------------------
> - 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.
-> certainly. fixed all integer32 INDEX objects syntax to Unsigned32.
This includes the following objects:
docsBpi2CmTEKSAId
docsBpi2CmIpMulticastIndex
docsBpi2CmCryptoSuiteIndex
docsBpi2CmtsTEKSAId
docsBpi2CmtsIpMulticastIndex
docsBpi2CmtsMulticastAuthSAId
docsBpi2CmtsCACertIndex
--------------------------
The change in indexes does not interfere with the wire compatibility of
already implemented systems,
The changes in the columnar values will..
The two Textual conventions can be used ( will try to get those on time
today)
1..16383 Unsinged are all index
0..16383 are columnar values
optimally SAIds are in range 0 (unknown) 1 to 16383
range 1 to 16383 is needed for Indexing tables ( only known SAIds can
create entries)
Which is all consistent
DocsSAId and
DocsSAIdOrZero (maybe)
<<<<
- Why is there a reference to RFC2819?
>>> Agree , should be RFC 2021 RMON2-MIB; done
- Since you import from docsIfMib (RFC2670), you must have
a normative reference to RFC2670
>>> Agree, done
- Since you import from IF-MIB, you must have a normative
reference to RFC2863
>>> Agree, done
- I see no citations to RFC3414 and RFC3415, neither do I
see any IMPORTS from those RFCs. So I do not see why they
are in the references section at all, let alone in the
normative references section
>>> Agree, done
- In section 2, I recommend to use "MIB module" instead of "MIB"
It occures several times. This to recognize that there is
only one (single) MIB that is composed of mul;tiple MIB modules.
>>> Agree, done (~ 5 places ?)
- docsBpi2ObsoleteObjectsGroup OBJECT-GROUP
Pls add to DESCRIPTION why this is/was obsoleted.
>>> will do, proposed text below:
Before was : docsBpi2ObsoleteObjectsGroup
docsBpi2CmtsObsoleteObjectsGroup OBJECT-GROUP
OBJECTS {
docsBpi2CmtsAuthCmGraceTime,
docsBpi2CmtsTEKGraceTime
}
STATUS obsolete
DESCRIPTION
"This is a collection of obsolete CMTS BPI+ objects.
The MIB objects in this group were conceived in early
draft versions of this document, and kept to maintain a
continuous and uniform OID structure with pre-RFC field
implementations.
Particularly, the objects reports Grace Time timeouts; a
CMTS does not require knowledge of those Security
associations parameters, which are sole CM responsibility."
::= { docsBpi2Groups 4 }
<<<
- Your MODULE-COMPLIANCE says that an implementation is only
required to support IPv4. You may want to add to the DESCRIPTION
clause(s) why only IPv4 (or why not IPv6) needs to be supported.
>>>
will add (borrow from MTA MIB; )
" Support for address types other than 'ipv4(1)'
is not presently specified and therefore, is not
required. It may be defined in future versions of
this MIB module."
<<<
Thanks
Eduardo
-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
Sent: Tuesday, October 14, 2003 9:16 AM
To: Ipcdn (E-mail)
Subject: [ipcdn] AD (MIB Dcotor) review of:
draft-ietf-ipcdn-bpiplus-mib-11.txt
Did I review this one before? I need to dive into my archives
to check, but it feels like I did.
Anyway, here is comments based on my first quick check.
I need to look some more into this document, so consider this review
incomplete.
1. When compiling (for SYNTAX checking) with SMICng I get:
W: f(bpiplus.mi2), (104,22) Revision date not in proper order
- most recent comes first
2. WHen I compile (syntax check) with smilint I get:
.\DOCS-IETF-BPI2-MIB:3076: [4] {compliance-group-status} warning:
current compliance statement `docsBpi2CmtsCompliance' includes
obsolete group `docsBpi2ObsoleteObjectsGroup'
3. Checking with checkpage.awk I get:
$ /bin/checkpage.awk < drafts/draft-ietf-ipcdn-bpiplus-mib-11.txt
Bad chars at 3899
Bad chars at 3907
Bad chars at 4189
-: 3 lines containing non-US-ASCII characters
4. Since this is a very first (formal) publication (as RFC) of this
MIB module, the tradition (and guideline) is to have one and only
one REVISION clause. I see that you have instructions to RFC editor
to remove the extra one. WHy not just remove them now (or move them
to an appendix to be removed later).
5. In the following, I see that the DESCRIPTION clause is out of sync
with the actual enumrations ??!!:
DocsBpkmSAType ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"The value of this object is the type of security
association. The values of the named-numbers are associated
with the BPKM SA-Type attributes:
'primary' corresponds to code '0', 'static' to code '1'
'dynamic' to code '2'.
'none' value must only be used if the SA type has yet
to be determined. "
REFERENCE
"DOCSIS Baseline Privacy Plus Interface
specification, Section 4.2.2.24"
SYNTAX INTEGER {
none(0),
primary(1),
static(2),
dynamic(3)
}
Or are the "code '0'" different codes at some other place.
If that is the case, then maybe the ENUMs should sync up with
those codes. no?
Technical issues/questions
a. I am not sure I understand the relationship between RFC3083 and
this I-D. Would a device implement both MIB modules?
- If not, does that mean that this MIB Module obsoletes the MIB
in 3083? If so it needs to be specified. And if it does obsolte
3083, then the normal process would be to deprecate/obsolete
pieces in 3083 that are no longer used and to add new objects
that are new, but keep the old one.
This method does work too... and I think is acceptable as long
as we do so consciously.
- If yes, I see a lot of duplication and I wonder if that is
good, in fact I doubt it.
In any event, it would be wise to document the relationship between
these documents better than currently done in the overview section
b. I do not understand why one is Unsigned32 and the other Integer32
docsBpi2CmTEKSAId OBJECT-TYPE
SYNTAX Unsigned32 (1..16383)
docsBpi2CmIpMulticastSAId OBJECT-TYPE
SYNTAX Integer32 (0..16383)
docsBpi2CmtsAuthPrimarySAId OBJECT-TYPE
SYNTAX Integer32 (0..16383)
docsBpi2CmtsTEKSAId OBJECT-TYPE
SYNTAX Unsigned32 (1..16383)
docsBpi2CmtsIpMulticastSAId OBJECT-TYPE
SYNTAX Integer32 (0..16383)
docsBpi2CmtsMulticastAuthSAId OBJECT-TYPE
SYNTAX Unsigned32 (1..16383)
Oh well, a couple of TCs seems justified too, maybe a
DocsSAId and a DocsSAIdOrNone (or DocsSAIdOrZero) TC
c.
Administrative comments and NITs:
- Why is there a reference to RFC2819?
- Since you import from docsIfMib (RFC2670), you must have
a normative reference to RFC2670
- Since you import from IF-MIB, you must have a normative
reference to RFC2863
- I see no citations to RFC3414 and RFC3415, neither do I
see any IMPORTS from those RFCs. So I do not see why they
are in the references section at all, let alone in the
normative references section
- In section 2, I recommend to use "MIB module" instead of "MIB"
It occures several times. This to recognize that there is
only one (single) MIB that is composed of mul;tiple MIB modules.
- docsBpi2ObsoleteObjectsGroup OBJECT-GROUP
Pls add to DESCRIPTION why this is/was obsoleted.
- Your MODULE-COMPLIANCE says that an implementation is only
required to support IPv4. You may want to add to the DESCRIPTION
clause(s) why only IPv4 (or why not IPv6) needs to be supported.
Thanks,
Bert
_______________________________________________
IPCDN mailing list
IPCDN@ietf.org
https://www1.ietf.org/mailman/listinfo/ipcdn
_______________________________________________
IPCDN mailing list
IPCDN@ietf.org
https://www1.ietf.org/mailman/listinfo/ipcdn