Subject: More last call comments on trunk-mib WG drafts

From: Gary Hanson <[email-masked]>
Date: Thu, 5 Mar 1998 17:30:19 -0800 (PST)

Here are the rest of my comments on the various trunk-mib WG drafts
for the most recent last call.

Regards,
Gary

General comments on the DS3-MIB and DS1-MIB drafts
--------------------------------------------------

1.  Because the DS3-MIB and DS1-MIB are each used for a variety of
    possible physical line types (i.e., DS3 and E3 for ds3(30)
    interfaces; DS1, E1, DS2, and E2 for ds1(18) interfaces) there
    is the potential for some ambiguity in how the DESCRIPTION of
    objects use the terms "ds1", "e1", "ds3", "DS1", "E1", "DS3",
    and "E3".

    Specifically:
    - If only "DS1" is used in some statement, it may not be clear
      whether the statement applies only to DS1 physical line types,
      or only to DS1 and E1 physical line types, or to all four of
      the DS1, E1, DS2, and E2 physical line types.
    - If only "DS3" is used in some statement, it may not be clear
      whether the statement applies only to DS3 physical line types,
      or to DS3 and E3 physical line types.
    - If significance is to be attached to the usage of (for example)
      "ds1" instead of "DS1", where the former applies to all of DS1,
      E1, DS2, and E2 physical line types, it becomes less clear if
      "ds1" is sometimes used to refer to only a subset of these
      physical line types.

    Here are some examples of ambiguity in actual object DESCRIPTIONs
    that make it unclear precisely for which physical line types they
    apply:
    - dsx3LineLength (says "ds3 line" instead of "DS3/E3 line")
    - dsx3TransmitClockSource (says "DS3 interface" instead of "DS3/E3
      interface")
    - dsx3LineLength (says "ds3 line" instead of "DS3/E3 line")
    - dsx3LoopbackStatus (says "DS3 interface" instead of "DS3/E3
      interface")
    - dsx3Channelization (says "ds3/e3" instead of "DS3/E3", says
      "DS3" instead of "DS3/E3", says "DS1s" instead of "DS1s/E1s",
      says "DS2s" instead of "DS2s/E2s", and says "DS2 or DS1 entries"
      instead of "ds1 entries for DS2/E2 or DS1/E1 interfaces")
    - dsx3CurrentUASs (says "DS3 interface" instead of "DS3/E3
      interface", ditto for related UAS objects in other tables)
    - dsx1LineType (says "DS1 Line" instead of "ds1 interface line" or
      "DS1/E1/DS2/E2 line" or something closer to how the dsx3LineType
      DESCRIPTION is phrased)
    - dsx1LoopbackConfig (says "DS1 interface" instead of "DS1/E1
      interface")
    - dsx1LineLength (says "ds1 line" instead of "DS1/E1 line")
    - dsx1LineStatusLastChange (says "DS1" instead of "DS1/E1/DS2/E2")
    - dsx1LoopbackStatus (says "DS1 interface" instead of "DS1/E1
      interface")
    - dsx1Channelization (says "ds1/e1" instead of "DS1/E1/DS2/E2",
      says "DS1" instead of "DS1/E1", says "DS2" instead of "DS2/E2",
      and says "DS1s" instead of DS1s/E1s")
    - dsx1Current* (says "DS1 interface" instead of "DS1/E1 interface",
      ditto for other statistics tables)
    - ds1NearEndOptionalConfigGroup (says "DS1" instead of "DS1/E1/DS2/
      E2" in GROUP DESCRIPTION under ds1Compliance; says "DS1 and DS2"
      instead of "DS1/E1/DS2/E2" in its own DESCRIPTION)
    - ds1DS2Group (says "DS2" instead of "DS2/E2" in GROUP DESCRIPTION
      under ds1Compliance; says "DS2 (6,312 kbps) and E2 (8,448 kbps)"
      in its own DESCRIPTION)
    - ds1TransStatsGroup (says "DS1" instead of "DS1/E1" in GROUP
      DESCRIPTION under ds1Compliance; says "ds1" instead of "DS1/E1"
      in its own DESCRIPTION)
    - ds1ChanMappingGroup (says "DS3" instead of "DS3/E3" and "DS3s
      into DS1s" instead of "DS3s/E3s or DS2s/E2s into DS2s/E2s or
      DS1s/E1s" in GROUP DESCRIPTION under ds1Compliance; says "DS3"
      instead of "DS3/E3" and "DS2/E2" in its own DESCRIPTION)
    - ds1Ds2Compliance (says "DS2" instead of "DS2/E2")
    - ds1NearEndConfigGroup (says "DS1" instead of "DS1/E1")
    - ds1NearEndStatisticsGroup (says "DS1" instead of "DS1/E1")
    - ds1NearEndOptionalTrapGroup (says "DS1 and DS2" instead of
      "DS1/E1/DS2/E2")

    I am not sure if it is worthwhile to overhaul all such references
    in the documents on this go-round of the RFCs, since most of us
    can read between the lines, but it may be worth clarifying for next
    time, unless the E1, DS2, E2, and E3 users see too much ambiguity
    that may lead to deviations in implementations.  I have proposed
    some specific fixes in my comments below that I think address the
    more ambiguous references.

    The only inconsistency I would adhere to would be in the section
    headings and the introductory MIB comments where I think "DS3" and
    "DS1" would be commonly understood to refer to the various physical
    line types, and for which the "ds3" or "ds1" spellings would appear
    out of place.

Comments on draft-ietf-trunkmib-ds3-mib-08.txt
----------------------------------------------

Substantive comments:
1.  Was dsx3Ds1ForRemoteLoop intended to have a MIN-ACCESS of read-only
    as had been done for dsx3LoopbackConfig and others?  There is no
    clause currently specifying this.

Editorial clarification comments:
1.  Change "ifGeneralGroup needs" to "ifGeneralInformationGroup and
    ifCounterDiscontinuityGroup need" in 1st sentence of section 3.1.
2.  Change "enabledDS1" to "enabledDs1" in 2nd paragraph of section
    3.2.2.
3.  Change "type DS1" to "ifType ds1" in 2nd paragraph of section 3.2.2.
4.  Change "enabledDS0" to "enabledDs0" in 4th paragraph of section
    3.2.2.
5.  Add a short paragraph at the end of section 3.2.2 clarifying:
    "Note that the ifStackTable is still used to define the relationships
    between the sub-layers of the interface (e.g., 24 ds0 interfaces are
    stacked on top of each of 28 ds1 interfaces, each of which in turn is
    stacked on top of the single ds3 interface)."
6.  Change "ifType of DS1" to "ifType of ds1" in 2nd paragraph of
    section 3.2.3.
7.  Change "enabledDS1" to "enabledDs1" in 3rd paragraph of section
    3.2.3.
8.  Add a short paragraph at the end of section 3.2.3 clarifying:
    "Note that the ifStackTable is still used to define the relationships
    between the sub-layers of the interface (e.g., 28 ds1 interfaces that
    represent individual DS1s are stacked in groups of 4 on top of 7 ds1
    interfaces representing DS2s, each of which in turn is stacked on top
    of the single ds3 interface)."
9.  Add the phrase "at any fifteen minute interval boundary or" after the
    start of the 3rd sentence in the 3rd paragraph of section 3.4.2 that
    begins: "Objects may decrease", since this is an even more common
    case than the one currently described.
10. Some terminology is not defined for E3 within section 3.4.  I am not
    sure if this will render the specification ambiguous, or if it is
    perfectly acceptable to E3 users.  Some examples:
    - E3 definitions for UAS Performance Parameter in section 3.4.2 (only
      refers to DS3)
    - E3 definitions for LOS Failure State in section 3.4.3 (only refers
      to DS3)
    Since I have no text to propose for these, I will only raise these as
    potential holes, of which I don't mind putting off fixes until the
    next go-round.
11. Change "this interval" to "this value" in last sentence of
    DESCRIPTION for dsx3ValidIntervals.
12. Change "dsx1LineLoop and dsx1InwardLoop" to "dsx3LineLoop and
    dsx3InwardLoop" in text for dsx3DualLoop within DESCRIPTION for
    dsx3LoopbackConfig.
13. Change "dsx3loopbackState" to "dsx3LoopbackState" in DESCRIPTION
    for dsx3LineStatus.
14. Change "dsx3loopbackConfig" to "dsx3LoopbackConfig" in DESCRIPTION
    for dsx3LineStatus.
15. Change "DS3" to "DS3/E3" in DESCRIPTION for dsx3TransmitClockSource.
16. Change "ds3 line" to "DS3/E3 line" in DESCRIPTION for dsx3LineLength.
17. Change "DS3 interface" to "DS3/E3 interface" in DESCRIPTION for
    dsx3LoopbackStatus.
18. Change "ds3/e3" to "DS3/E3" in DESCRIPTION for dsx3Channelization.
19. Change "DS3" to "DS3/E3" in DESCRIPTION for dsx3Channelization (in
    two places).
20. Change "DS1s" to "DS1s/E1s" in DESCRIPTION for dsx3Channelization.
21. Change "enabledDS3 indicated" to "enabledDs2 indicates" in
    DESCRIPTION for dsx3Channelization.
22. Change "DS2s" to "DS2s/E2s" in DESCRIPTION for dsx3Channelization.
23. Change "DS2 or DS1 entries" to "ds1 entries for DS2/E2 or DS1/E1
    interfaces" in DESCRIPTION for dsx3Channelization.
24. Change "ifTable.  " to "ifTable." at end of DESCRIPTION for
    dsx3Channelization.
25. Change "ds1/e1" to "DS1/E1" in DESCRIPTION for dsx3Ds1ForRemoteLoop.
26. Change "ds3/e3" to "DS3/E3" in DESCRIPTION for dsx3Ds1ForRemoteLoop.
27. Change "ds1" to "DS1/E1" in DESCRIPTION for dsx3Ds1ForRemoteLoop.
28. Add "initiated by setting dsx3SendCode to dsx3SendDS1LoopCode" to the
    end of the 1st sentence of the DESCRIPTION for dsx3Ds1ForRemoteLoop.
29. Change "DS1" to "DS1/E1" in DESCRIPTION for dsx3Ds1ForRemoteLoop.
30. Change "ds1s/e1s" to "DS1s/E1s" in DESCRIPTION for
    dsx3Ds1ForRemoteLoop.
31. Change "DS3 interface" to "DS3/E3 interface" in DESCRIPTIONs for
    dsx3CurrentUASs, dsx3IntervalUASs, and dsx3TotalUASs.
32. Change "obsolete" to "deprecated" in DESCRIPTION for
    ds3DeprecatedGroup, because of the ambiguity of the term "obsolete".
33. Update reference [5] to refer to RFC 2233.
34. Change "DS1 and E1" to "DS1, E1, DS2, and E2" in reference [6].
35. Add draft-ietf-atommib-perfhistTC-01.txt document to references in
    section 8, and add reference into 1st paragraph of Abstract text on
    page 1.
36. Change "ds3/e3" to "DS3/E3" in 2nd paragraph of section 9.
37. Add "dsx3Ds1ForRemoteLoop" to 1st list of objects in section 9.
38. Change "dsx3LineStatusChangeTrabEnable" to
    "dsx3LineStatusChangeTrapEnable" in 3rd list of objects in section 9.
39. Update LAST-UPDATED clause in MODULE-IDENTITY macro for DS3-MIB.
40. Add REVISION clause in MODULE-IDENTITY macro for DS3-MIB.  (It is a
    good idea to have this clause even in the first REVISION.  Its
    DESCRIPTION can say something like: "Initial revision, published as
    part of RFC XXXX.")
 
Editorial spelling/grammar/layout comments:
1.  Change "rfcTBD" to "RFC XXXX" (in three places) in Abstract text on
    page 1.
2.  Change "RFC1407" to "RFC 1407" (in three places) in section 2.1.
3.  Change "is to set" to "is to be set" in item (15) in section 2.1.
4.  Change "these values" to "the following value" in 2nd sentence of
    section 3.
5.  Change "assoication" to "association" in two places in 3rd paragraph
    of section 3.2.1.
6.  Fix unfortunate page breaks at bottom of pages 6, 8, and 61 (unless
    at the expense of introducing page breaks within the figure on page
    63).
7.  Change "Channelized" to "channelized" in 2nd paragraph of section
    3.2.2.
8.  Change "behaviour" to "behavior" in 1st sentence of section 3.2.4.
9.  Change "be request" to "be requested" in 3rd paragraph of section
    3.2.4.
10. Change "is currently applies" to "currently applies" in 3rd paragraph
    of section 3.2.4.
11. Change "This objects" to "This object" in 3rd paragraph of section
    3.2.4.
12. Indent (or bulletize) the last three paragraphs of section 3.2.4.
13. Reduce indentation of 4th heading, for "Loss of Signal (LOS) defect",
    in section 3.4.3.
14. Change "propoer" to "proper" in DESCRIPTION of dsx3LineIndex.
15. Change "is can" to "it can" in DESCRIPTION for dsx3LoopbackStatus.
16. Change "occurance" to "occurrence" in DESCRIPTION of dsx3IntervalUASs.
17. Change "inteval" to "interval" in DESCRIPTION of dsx3IntervalUASs.
18. Add "Table" after "Total" in MIB comment introducing dsx3TotalTable.
19. Add "Table" after "Current" in MIB comment introducing
    dsx3FarEndCurrentTable.
20. Add "Table" after "Total" in MIB comment introducing
    dsx3FarEndTotalTable.
21. Change "throug h" to "through" in DESCRIPTION of dsx3FracTable.
22. Change "Ds3" to "DS3" in MIB comment introducing ds3Traps.
23. Fix line breaks within ds3Groups and ds3Compliances.  (It seems that
    everything from "-- conformance information" up to just before
    "MODULE  -- this module" has been indented inadvertently, making for
    unfortunate line breaks.)
24. Change "rfc1407" to "RFC 1407" (in two places) in Appendix A.
25. Change "RFC1213" to "RFC 1213" in Appendix A.
26. Change "Unavialable" to "Unavailable" in heading for Appendix B.
27. Add blank line after heading for Appendix B.
28. Change "RFC1595" to "RFC 1595" in reference [7].
29. Change "mischevious" to "mischievous" in 3rd paragraph of section 9,
    and add a period to the end of the sentence.

Comments on draft-ietf-trunkmib-ds1-mib-08.txt
----------------------------------------------
 
Substantive comments:
    None, unless clarifications listed below are considered substantive
    instead of editorial.
 
Editorial clarification comments:
1.  Add an item (21) to list in section 2.1, saying something like:
    "A table of mappings from a channelized interface and channel number
    to a DS1/E1/DS2/E2 interface has been added."
2.  Add an item (22) to list in section 2.1, saying something lie:
    "Changed SYNTAX of dsx1Fdl from an enumerated integer using 1, 2, 4, 8
    to an INTEGER (1..15) representing a bitmap, to match most existing
    agent implementations."
3.  No clarification has been added to the overview (section 3) that
    discusses what DS2 and E2 are based on.  (This may be considered
    unnecessary, since DS2/E2 users probably know where to look, anyway.)
4.  Change "ifGeneralGroup needs" to "ifGeneralInformationGroup and
    ifCounterDiscontinuityGroup need" in 1st sentence of section 3.1.
5.  Change "T1" to "DS1" in four places in 3rd paragraph of section 3.2.1.
6.  Change "enabledDS0" to "enabledDs0" in 3rd paragraph of section 3.2.3.
7.  Add statement to 3rd paragraph of section 3.2.3 saying: "If the
    dsx1Channelization is set to disabled, the 24 DS0s are destroyed."
    - Actually, this text is similar to that in section 3.3.1 of the
      draft-ietf-trunkmib-ds0-mib-05.txt document, so the two should
      probably be aligned by using identical text.  It is important to
      clarify that the agent is being expected to automatically destroy
      the DS0 interfaces in this case.
8.  Add a short paragraph at the end of section 3.2.3 clarifying:
    "Note that the ifStackTable is still used to define the relationships
    between the sub-layers of the interface (e.g., 24 ds0 interfaces are
    stacked on top of each of 28 ds1 interfaces, each of which in turn is
    stacked on top of the single ds3 interface)."
9.  Change "ifType of DS1" to "ifType of ds1" in 2nd paragraph of
    section 3.2.4.
10. Change "enabledDS1" to "enabledDs1" in 3rd paragraph of section
    3.2.4.
11. Add statement to 2nd paragraph of section 3.2.4 saying: "If the
    dsx1Channelization is set to disabled, the 7 DS1s are destroyed."
    - Again, compare with text in related sections of the DS3-MIB and
      DS0-MIB drafts.  It is important to clarify what is being expected
      of the agent in each of these cases where the channelization is
      disabled.
12. Add a short paragraph at the end of section 3.2.4 clarifying:
    "Note that the ifStackTable is still used to define the relationships
    between the sub-layers of the interface (e.g., 28 ds1 interfaces that
    represent individual DS1s are stacked in groups of 4 on top of 7 ds1
    interfaces representing DS2s, each of which in turn is stacked on top
    of the single ds3 interface)."
13. Some terminology is not defined for DS2 and/or E2 within section 3.4.
    I am not sure if this will render the specification ambiguous, or if
    it is perfectly acceptable to DS2 and E2 users.  Some examples:
    - DS2/E2 definitions for PCV Error Event in section 3.4.1 (only refers
      to DS1 and E1)
    - E2 definitions for OOF and AIS Defects in section 3.4.2 (only refers
      to DS1, E1, and DS2)
    - DS2/E2 definitions for ES and SES Performance Parameter in section
      3.4.3 (only refers to DS1 and E1)
    - E1/DS2/E3 definitions for UAS Performance Parameter in section
      3.4.3 (only refers to DS1)
    Since I have no text to propose for these, I will only raise these as
    potential holes, of which I don't mind putting off fixes until the
    next go-round.
14. Add the phrase "at any fifteen minute interval boundary or" after the
    start of the 3rd sentence in the 3rd paragraph of section 3.4.2 that
    begins: "Objects may decrease", since this is an even more common
    case than the one currently described.
15. Change "four" to "five" and change "DS1 Channel Table" to "DS1 Channel
    Mapping" in list of MIB comments that precede the dsx1ConfigTable.
16. Change "ds0/ds0bundle mibs" to "DS0 and DS0 Bundle MIBs" in
    DESCRIPTION for dsx1LineIndex.  Also change in "[New Definition]" in
    3rd paragraph of Appendix A.
17. Change "this interval" to "this value" in last sentence of
    DESCRIPTION for dsx1ValidIntervals.
18. Change "DS1 Line  implementing  this  circuit" to "DS1, E1, DS2, or
    E2 application implementing this interface" in DESCRIPTION for
    dsx1LineType.  (This at least would make the DESCRIPTION consistent
    with that for dsx3LineType in the DS3-MIB.)
19. Change "ds1 line" to "DS1/E1 line" in DESCRIPTION for dsx1LineLength.
20. Change "DS1" to "DS1/E1/DS2/E2" in DESCRIPTION for
    dsx1LineStatusLastChange.
21. Change "DS1 to "DS1/E1" in DESCRIPTION for dsx1LoopbackStatus.
22. Change "Ds2/E2 or DS3/E3" to "DS2/E2 or DS3/E3, or of the DS2/E2 on
    its parent DS3/E3" in DESCRIPTION for dsx1Ds1ChannelNumber.
23. Change "DS1/E1 does not have a parent DS3/E3" to "DS1/E1/DS2/E2"
    does not have a parent interface" in DESCRIPTION for
    dsx1Ds1ChannelNumber.
24. Change "ds1/e1" to "DS1/E1/DS2/E2" in DESCRIPTION for
    dsx1Channelization.
25. Change "a DS1" to "a DS1/E1" in DESCRIPTION for dsx1Channelization.
26. Change "DS2" to "DS2/E2" in DESCRIPTION for dsx1Channelization.
27. Change "DS1s.  " to "DS1s/E1s." in DESCRIPTION for dsx1Channelization.
28. Add sentence to the end of dsx1Channelization (similar to that for
    dsx3Channelization in the DS3-MIB, including the fix suggested above):
    "Setting this object will cause the creation or deletion of either ds1
    entries for DS1/E1 interfaces or ds0 entries for DS0 interfaces in the
    ifTable."
29. Change "DS1" to "DS1/E1" in DESCRIPTION for various objects in the
    dsx1CurrentTable, dsx1IntervalTable, and dsx1TotalTable.
    - Excluded would be dsx1*BESs, since there is no standard defined for
      them for E1 (although, personally, I think DS1's definition for ESF
      would be adequate to cover E1 as well).  
    - Frankly, I was surprised that noone felt that DS2 and E2 would be
      deserving of statistics gauges, but I would not want to force them
      to be mandatory for these cases.
30. Change "Channel Table" to "Channel Mapping Table" in MIB comments
    that introduce dsx1ChanMappingTable.
31. Change "DS3" to "DS3/E3" (in two places) in DESCRIPTION for
    dsx1ChanMappingTable.
32. Change "DS1" to "DS1/E1" (in two places) in DESCRIPTION for
    dsx1ChanMappingTable.
33. Change "DS2s" to "DS2s/E2s" in DESCRIPTION for dsx1ChanMappingTable.
34. Change "DS2" to "DS2/E2" (in two places) in DESCRIPTION for
    dsx1ChanMappingTable.
35. Change "ds1 ifEntry" to "ds1(18) ifEntry" in DESCRIPTION for
    dsx1ChanMappingEntry (in two places).
36. Change "DS1 ifEntry" to "ds1(18) ifEntry" in DESCRIPTION for
    dsx1ChanMappingEntry.
37. Change "DS1 channel number" to "channel number" in last sentence of
    DESCRIPTION for dsx1ChanMappingEntry.
38. Change "ds1 ifEntry" to "ds1(18) ifEntry" in DESCRIPTION for
    dsx1ChanMappedIfIndex.
39. Change "DS1" to "DS1/E1/DS2/E2" in DESCRIPTION for
    dsx1ChanMappedIfIndex.
40. Change "T1" to "DS1" in DESCRIPTION for ds1Compliance.
41. Change "DS1" to "DS1/E1/DS2/E2" in GROUP DESCRIPTION for
    ds1NearEndOptionalConfigGroup under ds1Compliance.
42. Change "DS2" to "DS2/E2" in GROUP DESCRIPTION for ds1DS2Group
    under ds1Compliance.
43. Change "DS1" to "DS1/E1" in GROUP DESCRIPTION for ds1TransStatsGroup
    under ds1Compliance.
44. Change "unFramed" to "unframed" in GROUP DESCRIPTION for
    ds1TransStatsGroup under ds1Compliance.
45. Change "mapping a DS3 Channel (ds1ChannelNumber) to ifIndex" to
    "mapping from DS3/E3 ifIndex and channel number to DS1/E1 or DS2/E2
    ifIndex, or from DS2/E2 ifIndex and channel number to DS1/E1 ifIndex"
    in GROUP DESCRIPTION for ds1ChanMappingGroup under ds1Compliance.
46. Change "DS3s into DS1s" to "DS3s/E3s or DS2s/E2s into DS2s/E2s or
    DS1s/E1s" in GROUP DESCRIPTION for ds1ChanMappingGroup under
    ds1Compliance.
47. Change "dsx1Att-54016(4)" to "dsx1Att54016(4)" in MIN-ACCESS
    DESCRIPTION for dsx1Fdl under ds1MibT1PriCompliance, to match changes
    made to the enumeration descriptors when dsx1Fdl was changed to an
    INTEGER bitmap.
48. Change "dsx1Fdl-none(8)" to "dsx1FdlNone(8)" in MIN-ACCESS DESCRIPTION
    for dsx1Fdl under ds1MibE1PriCompliance, to match changes made to the
    enumeration descriptors when dsx1Fdl was changed to an INTEGER bitmap.
49. Change "DS2" to "DS2/E2" in DESCRIPTION for ds1Ds2Compliance.
50. Change "DS1" to "DS1/E1" in DESCRIPTION for ds1NearEndConfigGroup.
51. Change "DS1" to "DS1/E1" in DESCRIPTION for ds1NearEndStatisticsGroup.
52. Change "obsolete" to "deprecated" in DESCRIPTION for
    ds1DeprecatedGroup, because of the ambiguity of the term "obsolete".
53. Change "DS1 and DS2" to "DS1/E1/DS2/E2" in DESCRIPTION for
    ds1NearEndOptionalConfigGroup.
54. Change "systems" to "interfaces" in DESCRIPTION for ds1DS2Group.
55. Change "ds1" to "DS1/E1" in DESCRIPTION for ds1TransStatsGroup.
56. Change "DS1 and DS2" to "DS1/E1/DS2/E2" in DESCRIPTION for
    ds1NearEndOptionalTrapGroup.
57. Change "an mapping of DS3 Channel (ds1ChannelNumber) to ifIndex" to
    "a mapping from DS3/E3 ifIndex and channel number to DS1/E1 or DS2/E2
    ifIndex, or from DS2/E2 ifIndex and channel number to DS1/E1 ifIndex"
    in DESCRIPTION for ds1ChanMappingGroup.
58. Remove reference [5] from section 8, since it is superseded by
    reference [21], and is no longer referenced in the document text.
59. Update reference [21] to refer to RFC 2233, since it was published as
    an RFC already.
60. Verify whether reference [23] for T1.102 was intended to be used in
    the document text.  I couldn't find any usage of it.  If not, remove
    reference [22] from section 8.
61. Add draft-ietf-atommib-perfhistTC-01.txt document to references in
    section 8, and add reference into 1st paragraph of Abstract text on
    page 1.
62. Change "ds1/e1" to "DS1/E1/DS2/E2" in 2nd paragraph of section 9.
63. Change "dsx1LineStatusChangeTrabEnable" to
    "dsx1LineStatusChangeTrapEnable" in 3rd list of objects in section 9.
64. Update LAST-UPDATED clause in MODULE-IDENTITY macro for DS1-MIB.
65. Add REVISION clause in MODULE-IDENTITY macro for DS1-MIB.  (It is a
    good idea to have this clause even in the first REVISION.  Its
    DESCRIPTION can say something like: "Initial revision, published as
    part of RFC XXXX.")
 
Editorial spelling/grammar/layout comments:
1.  Change "rfcTBD" to "RFC XXXX" (in three places) in Abstract text on
    page 1.
2.  Change "RFC1406" to "RFC 1406" (in two places) in section 2.1.
3.  Add period to end of item (20) in list in section 2.1.
4.  Change "these values" to "the following value" in 2nd sentence of
    section 3.
5.  Change "Channelized" to "channelized" in 2nd paragraph of section
    3.2.3.
6.  Fix unfortunate page breaks at bottom of pages 9, 10, and 79.
7.  Change "Channelized" to "channelized" in 2nd paragraph of section
    3.2.4.
8.  Change "behaviour" to "behavior" in 1st sentence of section 3.2.5.
9.  Change "be request" to "be requested" in 3rd paragraph of section
    3.2.5.
10. Change "is currently applies" to "currently applies" in 4th paragraph
    of section 3.2.5.
11. Change "This objects" to "This object" in 4th paragraph of section
    3.2.5.
12. Indent (or bulletize) the last three paragraphs of section 3.2.5.
13. Reduce indentation of 3rd error event heading, for "Line Coding
    Violation (LCV) Error Count", in section 3.4.1.
14. Change "An Severely" to "A Severely" under SEFS Performance
    Parameter in section 3.4.3.
15. Add a comma before and after "grouping the result in 60-second long
    groups" in 2nd paragraph under Degraded Minutes Performance
    Parameter in section 3.4.3.
16. Change "UAS counts the PREVIOUS" to "UAS counts for the PREVIOUS"
    in 2nd paragraph under UAS Performance Parameter in section 3.4.3.
17. Change "are received, or detected failures, that are" to "are for
    received or detected failures, and are" in 1st sentence of section
    3.4.4.
18. Change "specifed" to "specified" in last paragraph of DESCRIPTION
    for dsx1LineCoding".
19. Change "is can" to "it can" in DESCRIPTION for dsx1LoopbackStatus.
20. Change "indicated" to "indicates" in DESCRIPTION for
    dsx1Ds1ChannelNumber.
21. Change "indicated" to "indicates" in DESCRIPTION for
    dsx1Ds1Channelization.
22. Change "occurance" to "occurrence" in DESCRIPTION for
    dsx1IntervalUASs.
23. Change "inteval" to "interval" in DESCRIPTION for dsx1IntervalUASs.
24. Relocate dsx1ChanMappingTable objects to follow the dsx1FracTable
    objects.  The current location of this text between the near-end and
    far-end statistics seems to be an unintuitive placement.  (Note that
    moving it does not change OID values, so there is no real substantive
    change.)
25. Change "Ds1" to "DS1" in MIB comment introducing ds1Traps.
26. Change "into an ifIndex" to "to an ifIndex" in DESCRIPTION for
    dsx1ChanMappingTable (in two places).
27. Change "onto an ifIndex" to "to an ifIndex" in DESCRIPTION for
    dsx1ChanMappingTable.
28. Change "instance dsx1LineStatus" to "instance of dsx1LineStatus" in
    DESCRIPTION for dsx1LineStatusChange.
29. Change "a 'M-Channel'" to "an 'M-Channel'" in MIN-ACCESS DESCRIPTION
    for dsx1Fdl.
30. Change "different to" to "different than" in MIN-ACCESS DESCRIPTION
    for dsx1Fdl.
31. Increase indentation for MIN-ACCESS DESCRIPTION text for
    dsx1Channelization under ds1MibE1PriCompliance.
32. Increase indentation for MIN-ACCESS DESCRIPTION text for
    dsx1Channelization under ds1Ds2Compliance.
33. Decrease indentation of first line of DESCRIPTION for
    ds1TransStatsGroup.
34. Change "rfc1406" to "RFC 1406" (in two places) in Appendix A.
35. Change "ds0/ds0bundle mibs" to "DS0 and DS0 Bundle MIBs" in "[New
    Definition]" in 3rd paragraph of Appendix A.
36. Change "RFC1213" to "RFC 1213" in Appendix A.
37. Change "Unavialable" to "Unavailable" in heading for Appendix B.
38. Reduce indentation of reference [10].
39. Change "Types" to "Type" in reference [17].
40. Change "RFC1595" to "RFC 1595" in reference [18].
41. Change "Ds0 and DS0Bundle" to "DS0 and DS0 Bundle" in reference 19.
42. Change "mischevious" to "mischievous" in 3rd paragraph of section 9,
    and add a period to the end of the sentence.

Comments on draft-ietf-trunkmib-ds0-mib-05.txt
----------------------------------------------
 
Substantive comments:
1.  I have already commented on the dsx0BundleMappedIfIndex issue.  If
    my proposed fix is accepted, then section 3.3.2 would need to be
    rewritten.  Here is some sample text that could be used in that
    section:

  ------------------------- start proposed text -----------------------
  3.3.2.  Usage of ifIndex Mapping for DS0Bundle

  An example is given here to explain the ifIndex mapping objects in the
  DS0Bundle MIB to help the implementor use the objects correctly.

  Assume that a DS1 (with ifIndex 1) is channelized into DS0s.  There will
  be 24 DS0s in the ifTable.  Assume the entries in the ifTable for the
  DS0s are created in channel order and the ifIndex values are 2 through
  25.  Now, assume that there are two bundles on the DS1.  The first one
  uses channels 1,4,5,6,7,8,9, and 10.  The second uses channels 2 and 3.
  There will be two ifTable entries for these bundles, with values of 26
  and 27 for ifIndex.  There will be an entry in the dsx0BundleTable for
  each bundle.  The entries will be as follows:

          dsx0BundleTable Entries

          dsx0BundleIndex    dsx0BundleIfIndex
          1                  26
          2                  27

  There will be an entry in the dsx0ConfigTable for each DS0.  The entries
  will be as follows:

          dsx0ConfigTable Entries

          ifIndex  dsx0Ds0ChannelNumber   dsx0Ds0BundleMappedIfIndex
          2        1                      26
          3        2                      27
          4        3                      27
          5        4                      26
          6        5                      26
          7        6                      26
          8        7                      26
          9        8                      26
          10       9                      26
          11       10                     26
          12       11                     0
          13       12                     0
          ......
          25       24                     0

  ------------------------- end proposed text -----------------------

    In addition, some of the DS0-MIB and DS0BUNDLE-MIB text would also
    have to change, as noted before (including MIB comments introducing
    the affected objects and tables).
2.  I am not familiar with BONDING, so I am uncertain whether it was
    intended to define dsx0BondStatus with a MAX-ACCESS of read-create.
    With my naive understanding, it would appear that the object is used
    by the agent to indicate status to the manager, as opposed to being
    used by the manager to control the agent.  Is this an error?

Editorial clarification comments:
1.  Change "four" to "three" in 1st sentence of section 1 of DS0 MIB
    draft, since most other RFCs cite just 3 components of the SNMPv2
    network management framework, even if they then lists 4 RFCs.
    - By the way, I am not sure I understand when (if ever) it will
      become inappropriate to still refer to RFC 1213, since the latest
      RFC on INTERNET OFFICIAL PROTOCOL STANDARDS (RFC 2200) still says
      RFC 1213 is the recommended standard for MIB-II, and it only lists
      its replacements (RFC 1907 for the system and snmp group, RFC 2011
      for the ip and icmp groups, RFC 2012 for the tcp group, and RFC
      2013 for the udp group) as elective standards at either the draft
      or proposed maturity level.
 
      Based on this, I (as one agent implementor) am confused about
      whether the support for RFC 1213 should be replaced by support for
      these other SMIv2-based MIBs, independent of the version(s) and
      variation(s) of SNMP in use by the agent.  The fact that (in some
      cases) their content changed at the same time they were recast in
      SMIv2 makes it somewhat unclear what is expected of implementors.
      It appears that SMIv2 MIBs are NOT supposed to import items defined
      in SMIv1 MIBs, so although I understand that everybody can't move
      all at once from RFC 1213 to the newer MIB-II MIBs, it does seem
      inconsistent to consider the newer MIB-II MIBs elective at the same
      time that they are supposed to be the source of IMPORTS for newly
      defined SMIv2 MIBs.

      I know that this is beyond the scope of the trunk-mib WG, but it
      is an important question for the current round of MIBs that are
      being considered at this time by the IESG, since a few lines of
      informative boilerplate verbage are indeed being thrown into each
      RFC.  I wonder whether the IESG shouldn't ask the RFC editor to put
      some common verbage into these boilerplate lines, indepedent of the
      actual content of drafts coming from the various WGs.
2.  Change "rfc1573" to "RFC 2233" in 1st sentence of section 3.2.  (Note
    that the equivalent introductory sentence is missing from both the
    DS3-MIB and the DS1-MIB draft documents.)
3.  Change "ifGeneralGroup needs" to "ifGeneralInformationGroup and
    ifCounterDiscontinuityGroup need" in 2nd sentence of section 3.2.
4.  Change "enabledDS0" to "enabledDs0" in 3rd paragraph of section 3.3.1.
5.  Fix inconsistencies in example described in section 3.3.2, where DS0
    channel 4 is being used in two different bundles.  I think it was
    intended that the second bundle would use channels 2 and 3 instead of
    3 and 4.  The table at the end of the section would need to have the
    "3" in its last row changed to "2" in this case.
    - These fixes can be ignored if the substantive change about the
      dsx0BundleMappedIfIndex (described above) is accepted.
6.  Change "dsx0ChanMappedIfIndex" to "dsx0BundleMappedIfIndex" in heading
    for 3rd column in the 2nd table of section 3.3.2.
    - This change can be ignored if the substantive change about the
      dsx0BundleMappedIfIndex (described above) is accepted.
7.  Change "DS1" to "DS1/E1" in 1st paragraph of section 4.2.
8.  Change "group" to "groups" in 1st paragraph of section 4.2.
9.  Change "ds1/e1" to "DS1/E1" in DESCRIPTION for dsx0Ds0ChannelNumber.
10. Change "T1" to "DS1" in DESCRIPTION for dsx0RobbedBitSignalling.
11. Change "DS1" to "DS1/E1" in DESCRIPTION for dsx0ChanMappingTable.
12. Add "done = false" before "while done == false" in DESCRIPTION for
    dsx0BundleNextIndex, so that the pseudo code initialized its control
    variable.
13. Change "DS1" to "DS1/E1" in DESCRIPTION for dsx0BundleMappingTable.
    - This change can be ignored if the substantive change about the
      dsx0BundleMappedIfIndex (described above) is accepted.
14. Change "DS1/E1/DS2/E2" to "DS1, E1, DS2, and E2" in reference [6].
15. Change "Types" to "Type" in reference [7].
16. Why is draft-ietf-atommib-sonetng-02.txt included as a reference
    (i.e., reference [8]) in this draft, but not in the DS3-MIB and the
    DS1-MIB drafts?  Is the sonetng-02 draft also ready for approval?
    Will the RFC editor align all of these references?
17. Change "dsx0RobberBitSignalling" to "dsx0RobbedBitSignalling" in 2nd
    paragraph of section 9.
18. Some objects appear to be missing from the 1st list in section 9.  I
    would believe that the following objects could also cause loss of
    traffic if they are set to certain values in certain cases:
    - dsx0BundleRowStatus
    - dsx0BondMode
    - dsx0BondStatus (if this really IS read-create; see item above)
    - dsx0BondRowStatus
19. I question whether three items in the 2nd list in section 9 shouldn't
    be considered harmful to traffic if modified in some cases.  We may
    want to move the following objects to the 1st list:
    - dsx0IdleCode
    - dsx0SeizedCode
    - dsx0TransmitCodesEnable
20. Update LAST-UPDATED clause in MODULE-IDENTITY macros for DS0-MIB and
    for DS0BUNDLE-MIB.
21. Add REVISION clause in MODULE-IDENTITY macros for DS0-MIB and for
    DS0BUNDLE-MIB.  (It is a good idea to have this clause even in the
    first REVISION.  Its DESCRIPTION can say something like: "Initial
    revision, published as part of RFC XXXX.")
 
Editorial spelling/grammar/layout comments:
1.  Change "rfcTBD" to "RFC XXXX" (in two places) in Abstract text on
    page 1.
2.  Change "rfc1595" to "RFC 1595" in 1st paragraph of Abstract on page 1.
3.  Add newline after heading for section 3.1, to separate it from text.
4.  Fix unfortunate page breaks at bottom of page 6.
5.  Change "Channelized" to "channelized" in 2nd paragraph of section
    3.3.1.
6.  Change "Mapping" to "mapping" in 1st sentence of section 3.3.2.
    - This change can be ignored if the substantive change about the
      dsx0BundleMappedIfIndex (described above) is accepted.
7.  Change "Channelized" to "channelized" in 2nd paragraph of section
    3.3.2.
    - This change can be ignored if the substantive change about the
      dsx0BundleMappedIfIndex (described above) is accepted.
8.  Add newline after heading for section 4.1, to separate it from text.
9.  Add newline after heading for section 4.2, to separate it from text.
10. Change "Ds0" to "DS0" in heading for section 5.
11. Change "two table:" to "two tables:" in MIB comments introducing the
    dsx0ConfigTable.
12. Change "the DS0" to "The DS0" in MIB comments introducing the
    dsx0ConfigTable.
13. Add missing period at end of DESCRIPTION for dsx0ConfigEntry.
14. Change "in enabled" to "is enabled" in DESCRIPTION for dsx0SeizedCode.
15. Change "recieved" to "received" in DESCRIPTION for dsx0ReceivedCode.
16. Change "siezed" to "seized" in DESCRIPTION for dsx0ReceivedCode.
17. Change "DS0 Channel Table" to "DS0 Channel Mapping Table" in MIB
    comments introducing dsx0ChanMappingTable.
18. Change "Ds0" to "DS0" in heading for section 6.
19. Change "Ds0" to "DS0" in MIB comments introducing dsx0BundleNextIndex.
20. Change "RFC1903" to "RFC 1903" in DESCRIPTION for dsx0BundleNextIndex.
21. Change "alorithm" to "algorithm" in DESCRIPTION for
    dsx0BundleNextIndex.
22. Remove extra spaces at start of DESCRIPTION for dsx0BundleTable, and
    between "be" and "used".
23. Remove extra spaces at end of DESCRIPTION for dsx0BundleMappingTable.
    - This change can be ignored if the substantive change about the
      dsx0BundleMappedIfIndex (described above) is accepted.
24. Change "the DS0 Bonding Table" to "The DS0 Bonding Table" in MIB
    comments introducing dsx0BondingTable.
25. Change "RFC2233" to "RFC 2233" in reference [5].
26. Change "mischevious" to "mischievous" in 3rd paragraph of section 9,
    and add a period to the end of the sentence.

End of comments.

---

From: Jason Perreault <[email-masked]>
Date: Thu, 12 Mar 1998 09:50:38 -0500

I agree with Gary's objection to the dsx0BundleMappingTable. This table
currently contains one entry per bundle, and is indexed by

	<ds1_ifIndex>.<lowest_numbered_ds0_channel_assigned_to_bundle>

and yields the ifIndex of the bundle.

With this structure, it is not possible to find the ds0Bundle ifIndex,
if any,
for an arbitrary ds0.

Options:

- Adopt Gary's original suggestion to add an attribute to
dsx0ConfigTable,
  to report the ds0Bundle ifIndex for that DS0, if any
(InterfaceIndexOrZero).

- Change the dsx0BundleMappingTable to be indexed by any ds0 channel,
  and return the ds0Bundle ifIndex for that DS0, if any
(InterfaceIndexOrZero).
  (But if the first suggestion is implemented, you could get there in
two steps,
   first by mapping <ds1 ifIndex>.<ds0 channel> to ds0 ifIndex via 
   dsx0ChanMappingTable, then by looking up the ds0's ds0Bundle ifIndex
in
   in dsx0ConfigTable.)

- Make both of these changes, if efficiency warrants being able to
determine 
  ds0Bundle ifIndex from ds0 ifIndex *and* from { ds1 ifIndex, ds0
channel}.
  (But I don't expect it does.)

Regards,

Jason Perreault
Redstone Communications Inc.
[email-masked]