Subject: [ipcdn] Comments on CableHome drafts

From: Nakanishi Greg-MGI8179 <[email-masked]>
Date: Thu, 3 Jul 2003 08:55:41 -0700

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.

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)

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].

4) CONTACT-INFO clause should include reference to IPCDN web page per 'draft-ietf-ops-mib-review-guidelines-01.txt' section 4.5

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.  

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.

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).

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?

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.

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.

Gateway Addressing MIB

1) Section 2.2, last sentence - "...software code image verification using techniques."  Should this be "...software code image verification techniques." ?

2) cabhCapTcpTimeWait DESCRIPTION - reference to [RFC793] not included in section 8 or 9.

3) cabhCapTcpTimeWait DEFVAL - should add comment "-- 5 minutes" to be consistent with UDP and ICMP timeout objects.

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?
b) While the cabhCdpLanAddrIp could exceed 115 character in theory, in practice I don't ever see this happening.  Is this sentence really needed?

2) Use of "CMP" : acronym needs to be expanded on first use and described.

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.

2) section 3.1, paragraph 2 - "CABH-PS-DEV-MIB" should be "CABH-IETF-PS-DEV-MIB"

3) Use of "CMP" and "CDC" : acronym needs to be expanded on first use and described.

4) cabhPsDevCspTrap  NOTIFICATION-TYPE - "CableHome Security Portal" used but not described.

cabhPsDevCapTrap  NOTIFICATION-TYPE - "CableHome Address Portal" used but not described.

cabhPsDevCtpTrap  NOTIFICATION-TYPE - "CableHome Test Portal" used but not described.

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. 

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)?

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).

Gateway Tools MIB

1) CTP should be in the glossary.

2) I think the Ping Tool and Connection Speed Tool should be described in the glossary.

Gateway QoS MIB

1) cabhPriorityQosBpEntry - Does the 113 number reflect the re-rooting of the MIB tree?

2) cabhPriorityQosBpDestEntry - same comment as #1

3) Reference to 1.1 spec should be updated to -I01.

_______________________________________________
IPCDN mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipcdn

---

From: "Kevin Luehrs" <[email-masked]>
Date: Thu, 10 Jul 2003 15:36:13 -0600

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
[email-masked]

-----Original Message-----
From: Nakanishi Greg-MGI8179 [mailto:[email-masked]] 
Sent: Thursday, July 03, 2003 9:56 AM
To: [email-masked]'
Subject: [ipcdn] Comments on 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.

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:

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>

<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

<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

<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>

<KL> as above </KL>

<KL> Agree. Authors will edit the document for the next draft. </KL>
_______________________________________________
IPCDN mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipcdn