re: Comments on CableHome drafts
Kevin Luehrs <k.luehrs <at> cablelabs.com>
2003-07-10 21:36:13 GMT
To Greg and other IPCDN WG participants;
Please see responses inline.
Kevin
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kevin Luehrs
Project Director, CableHome Engineering
CableLabs
400 Centennial Parkway
Louisville, CO 80027
303 661 9100
fax 303 661 9199
k.luehrs <at> cablelabs.com
-----Original Message-----
From: Nakanishi Greg-MGI8179 [mailto:gnakanishi <at> motorola.com]
Sent: Thursday, July 03, 2003 9:56 AM
To: 'ipcdn <at> ietf.org'
Subject: [ipcdn] Comments on CableHome drafts
Comments on the CableHome drafts ---
General
1) Some of the lines exceed 72 characters. I didn't do an exhaustive
search, but for the lines that I saw exceeding 72 characters they have
trailing space characters. I don't really know how important the this is
to correct.
<KL> We agree this should be fixed and authors will correct it in the
next draft of each MIB i-d. </KL>
2) "Status of this Memo" section - The reference "[1]" to RFC2026 should
be removed.
Per "Ad Review of I-Ds" doc:
Do not add a numbered reference in the ID boilerplate to RFC 2026 (makes
it harder for the RFC editor to process the document when they strip off
the ID boilerplate)
<KL> We agree this should be fixed and authors will correct it in the
next draft of each MIB i-d. </KL>
3) Section 1 - Another "not sure how important this is" comment. The
form of the references used in the draft doesn't match the "Boilerplate
for IETF MIB Documents" doc. E.g. the draft uses [1] where as the
boilerplate doc uses [RFC3410].
<KL> Unless there is widespread objection to the existing language I
propose that we leave it as-is. </KL>
4) CONTACT-INFO clause should include reference to IPCDN web page per
'draft-ietf-ops-mib-review-guidelines-01.txt' section 4.5
<KL> Add to the next draft of the i-d. </KL>
5) Table objects that support dynamic row creation - Per
'draft-ietf-ops-mib-review-guidelines-01.txt' section 4.6.3:
- There either MUST be one columnar object with a SYNTAX value of
StorageType [RFC2579] and a MAX-ACCESS value of read-create, or
else the row object (table entry) DESCRIPTION clause MUST specify
what happens to dynamically-created rows after an agent restart.
I think a description on what happens to the row on a restart needs to
be added for most table objects in the CH MIBs.
6) Inclusion of CableHome 1.1 objects? - Is the intent to standardize on
the CableHome 1.1 objects as well? Some time ago, I recall the group
felt it was premature to include CableHome 1.1; however, it's been a
while and things may have changed. There are a number of CableHome 1.1
objects defined in the MIB. However, none of the descriptive sections
of the draft (e.g. overview, glossary, references) address CableHome
1.1.
<KL> It was our intention from the beginning to include CableHome 1.1
objects in the i-d/IETF version of the CableHome MIBs. We plan to update
at least the CableHome 1.1 specification to replace references to
CableLabs reference numbers with RFC numbers for the MIBs, when RFC
numbers are assigned to the MIBs.
CableHome 1.1 is referenced in the compliances section of each
applicable MIB, e.g. (PSDev MIB):,
-- conditionally mandatory group
GROUP cabhPsDevAttribGroup
DESCRIPTION
"This group is implemented only in CableHome 1.1 PS
elements, not CableHome 1.0 PS elements."
-- conditionally mandatory group
GROUP cabhPsDevPsStatsGroup
DESCRIPTION
"This group is implemented only in CableHome 1.1 PS
elements, not CableHome 1.0 PS elements."
::= { cabhPsCompliances 1}
Please submit a proposal for descriptive text for the overview,
glossary, and references sections of the i-d.
</KL>
7) Section 7 - Needs to be updated to comply with "Security Guidelines
for IETF MIB Modules". In particular, a discussion of the security
sensitivity of specific objects.
<KL> We agree this needs to be added. Authors will add text for the next
draft of each MIB i-d. </KL>
8) Section 8 - CableHome 1.0 spec reference should be updated to -I04.
CableHome 1.1 refence should be added, if needed. (see comment 6
above).
<KL> Agree. Authors will edit the document for the next draft. </KL>
9) Section 8/9 - The "Boilerplate for IETF MIB Documents" show the
reference to RFC3410 as Informative, whereas the draft includes it in
the Normative section. Is the reference where it belongs?
<KL> This reference should be moved to the Informative section. Authors
will edit the document for the next draft. </KL>
10) Conversion errors from source document - Looks there are a few
non-ASCII characters. Looks like the main errors occurred in converting
bullet items and left/right quotation marks, but there were others as
well. I found the following characters in the draft that should be some
other character:
- Latin small letter u with circumflex (original was a bullet character,
I think)
- Latin small letter o with circumflex (original was a left quote, I
think)
- Latin small letter o with diaeresis (original was a right quote, I
think)
- Latin capital letter o with diaeresis
- Latin capital letter AE
I've noticed these in the Config MIB and the Device MIB, for sure. I
didn't notice it the other MIBs, but didn't do a thorough search.
<KL> Agree that these errors should be corrected. Authors will edit the
document for the next draft to make these corrections. </KL>
11) Glossary - Each draft has a different set of terms in the glossary.
I guess this is good in that the only the terms applicable to the
particular draft is included. However, it seems easier and more
consistent if only one all-inclusive glossary was written and included
in all drafts. Just a thought to consider.
<KL> Our preference is to define in the glossary only those terms used
in the document. If general WG consensus is that we use the same
glossary for each cable-gateway MIB i-d then we will respect the group's
wishes. </KL>
Gateway Addressing MIB
1) Section 2.2, last sentence - "...software code image verification
using techniques." Should this be "...software code image verification
techniques." ?
<KL> Agree that this correction should be made. Authors will edit the
document for the next draft to make this correction. </KL>
2) cabhCapTcpTimeWait DESCRIPTION - reference to [RFC793] not included
in section 8 or 9.
<KL> Agree that this reference should be added to the Normative
References section of the i-d. Authors will edit the document for the
next draft. </KL>
3) cabhCapTcpTimeWait DEFVAL - should add comment "-- 5 minutes" to be
consistent with UDP and ICMP timeout objects.
<KL> Agree that this comment should be added for consistency. Authors
will edit the document for the next draft. </KL>
Gateway Configuration MIB
1) cabhCdpLanAddrEntry DESCRIPTION - The description states:
Implementors need to be aware that if the size
of cabhCdpLanAddrIp exceeds 115 octets then OIDs
of column instances in this table will have more
than 128 sub-identifiers and cannot be accessed
using SNMPv1, SNMPv2c, or SNMPv3.
a) Does the 115 number reflect the re-rooting of the MIB tree?
<EC-KL> This number is Rich Woundy's estimate for the maximum length of
cabhCdpLanAddrIp without exceeding limits imposed by SNMPv1, v2c, and v3
on OID length, assuming re-rooting under the mib-2 branch (Rich - please
clarify as needed). Eduardo contacted IETF OPS groups for clarification
on how this should be calculated in a standard manner but he has so far
received no response. </EC-KL>
b) While the cabhCdpLanAddrIp could exceed 115 character in theory, in
practice I don't ever see this happening. Is this sentence really
needed?
<EC> This is a common policy to guarantee the extensibility of the mib
as IETF recommends. </EC>
2) Use of "CMP" : acronym needs to be expanded on first use and
described.
<KL> Agree. Authors will edit the document for the next draft. </KL>
3) Use of InetAddressType - The MIB uses the "old" convention of pairing
INetAddressType and InetAddress objects together. Should we adopt the
"new" convention of allowing multiple InetAddress objects refer to a
single INetAddressType? E.g. cabhCdpPoolStartType and
cabhCdpPoolEndType could be combined into a single 'poolType' object as
it makes no sense for cabhCdpPoolStartType and cabhCdpPoolEndType to
have different values.
4) cabhCdpWanDnsServerTable - What value would the ServerIpType and
ServerIp objects in rows 2 and 3 have if there is only one DNS server?
Should this be specified in the description?
Gateway Device MIB
1) section 3.1, paragraph 1 - I think this paragraph is obsolete.
<KL> Agree. Authors will edit the document to update for the next draft.
</KL>
2) section 3.1, paragraph 2 - "CABH-PS-DEV-MIB" should be
"CABH-IETF-PS-DEV-MIB"
<KL> Agree. Authors will edit the document to update for the next draft.
</KL>
3) Use of "CMP" and "CDC" : acronym needs to be expanded on first use
and described.
<KL> Agree. Authors will edit the document to update for the next draft.
</KL>
4) cabhPsDevCspTrap NOTIFICATION-TYPE - "CableHome Security Portal"
used but not described.
<KL> Agree that the description should be edited to provide a more
relevant reference. Authors
will edit the document to update for the next draft. </KL>
cabhPsDevCapTrap NOTIFICATION-TYPE - "CableHome Address Portal" used
but not described.
<KL> Agree that the description should be edited to provide a more
complete reference. Authors
will edit the document to update for the next draft. </KL>
cabhPsDevCtpTrap NOTIFICATION-TYPE - "CableHome Test Portal" used but
not described.
<KL> Agree that the description should be edited to provide a more
complete reference. Authors
will edit the document to update for the next draft. </KL>
Gateway Security MIB
1) section 2.8 - Seems odd that CDP is defined here but never referred
to in the draft. Perhaps it should be deleted. It the glossary should
describe the CSP, instead.
<KL> Agree that 'CDP' should not be defined in the Security MIB if it is
not used. Authors will remove this
definition from the document for the next draft. </KL>
2) cabhSecFwPolicyOperStatus - Since this is a "new" MIB, should the
deprecated completeFromMgt(3) comment be deleted? Which then raises the
question, should failed(4) be renumbered to failed(3)?
<KL> We agree with Greg, that the deprecated object be deleted from the
i-d version of the Security MIB, and agree that 'failed(4)' should be
renumbered to failed(3). This will create some confusion with existing
vendor products but can be corrected with a software upgrade, and it is
preferable to submitting a "new" i-d MIB to the IETF with a deprecated
object. </KL>
3) Section 3 - Needs to be updated to describe additional MIB objects
that were added since the last draft. e.g. the Kerberos objects. Also,
all the 1.1 objects, if they are going to be included (see General
comment #6).
<KL> Agree. There are also other recent changes introduced via the
CableHome Engineering Change process. Authors will edit the document for
the next draft. </KL>
Gateway Tools MIB
1) CTP should be in the glossary.
<KL> Agree. Authors will edit the document for the next draft. </KL>
2) I think the Ping Tool and Connection Speed Tool should be described
in the glossary.
<KL> Agree. Authors will edit the document for the next draft. </KL>
Gateway QoS MIB
1) cabhPriorityQosBpEntry - Does the 113 number reflect the re-rooting
of the MIB tree?
<KL> See the response for the similar question under Gateway
Configuration MIB, above. </KL>
2) cabhPriorityQosBpDestEntry - same comment as #1
<KL> as above </KL>
3) Reference to 1.1 spec should be updated to -I01.
<KL> Agree. Authors will edit the document for the next draft. </KL>
_______________________________________________
IPCDN mailing list
IPCDN <at> ietf.org
https://www1.ietf.org/mailman/listinfo/ipcdn
RSS Feed