Responses to comments on IETF Sig MIB draft 5

Beacham Gordon-CGB005 <[email protected]> Fri, 3 Sep 2004 12:47:01 -0700

Newsgroups	gmane.ietf.ipcdn
Message-ID	<D5A7E45D575DD61180130002A5DB377C065292AA@ca25exm01>

****************************************************
Part 1:
****************************************************

1) lines limited to 72 characters:
trailing blanks make line 26 too long (73 characters)
trailing blanks make line 99 too long (73 characters)
trailing blanks make line 2206 too long (73 characters) trailing blanks make line 2226 too long (73 characters) trailing blanks make line 2240 too long (73 characters) trailing blanks make line 2301 too long (73 characters)

AI: Fix in final formating.

2) some pages have more than 58 lines

AI: Fix in final formating.

3) pages not separated by FF character

AI: Fix in final formating.

4) the words "INTERNET-DRAFT" should be in upper left
corner of first page

AI: Changed.

5) IPR Boilerplate: OK, but note that alternative wording for "plural" authors has been presented on the wgchairs list:

By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of RFC 3668.

AI: Changed.

6) Internet-Draft boilerplate: text is OK, but formatting is strange.

No change. Not clear what is "strange".

7) Filename: broken by strange formatting on first page

AI: Changed.

8) author list: present, but mal-formatted

AI: Fixed formatting.

9) Introduction: missing. (2.2 #5)

AI: Added Introduction section.

10) IANA considerations: contradictory, (2.2 #7b) seems to apply, since an OID needs to be allocated.

AI: Added the following per 8/4 IPCDN reflector message from Dave Thaler.

The MIB module in this document uses the following IANA-assigned OBJECT IDENTIFIER values
recorded in the SMI Numbers registry:

Descriptor OBJECT IDENTIFIER Value
---------- -----------------------
pktcSigMib { mib-2 XXX }

Editor's Note (to be removed prior to publication): the IANA is requested to assign a value
for XXX under the mib-2 subtree and to record the assignment in the SMI Numbers registry.
When the assignment has been made, the RFC Editor is asked to replace XXX (here and in the
MIB module) with the assigned value and to remove this note.

11) authors' addresses: need cleanup
(e.g., the first in the list uses normal US postal
address format, but the last in the list doesn't.)

AI: Changed.

12) Keywords: text references RFC 2119, but it is missing from the list of normative references.

AI: Added normative reference: [RFC2119].

13) formal language use: MIB compilation: smilint objects to pktcSigDevCodecType (an index of pktcSigDevCodecEntry) being read-only. It should be not-accessible.

AI: Changed.

14) References:
[PKT-SP-MGCP-IO9-040113] is never cited.
[PKT-SP-PROV-IO8-040113] is never cited.
[PKT-SP-CODEC-IO5-040113] is never cited.
[PKT-SP-MIB-MTA-I08-040113] is never cited.
[ETSI TS 101 909-9] is never cited.
[TR 101 183] is never cited.
[RFC3289], while referenced in the MIB module, is not
cited in the text of the document.
[RFC3291], while referenced in the MIB module, is never cited.
[RFC3261] is never cited.
[RFC3435] is never cited.
MIB module IMPORTS from SNMP-FRAMEWORK-MIB, but it's
missing from the normative references and not cited in text.

AI: Deleted: [RFC3261], added normative references: [ITU-T-J169], [RFC3411]. Cited reference in introduction and overview sections.

****************************************************
Part 2:
****************************************************

1) abbreviations expanded on first use: need to add expansions for:
IPR
LCD
CRCX
MDCX
DSP
SDP
DOCSIS
CODEC (also shows up as "codec" and "Codec")
RTP
FSK
MAP
rg
rs
cr
"Blvd" needs a "."
"Inc" needs a "."
"Corp" needs a "."
PCMU
PCMA
FQDN
MIBMTA
RSIP
LCD
CMS
RJ

"frequences" should be "frequencies"
"playout" should be "play out" (where it is a verb rather than a noun) "dBm" also appears as "dbm"

AI: Expanded abbreviations on first use. Fixed spelling.

2) two spaces after end of sentence: document needs to be fixed so that TWO spaces occur after "." at the end of a sentence. (2223bis 3.1 (7)

AI: Fix in final formating.

3) Table of contents / order of sections: the sections of the document are not in the order specified by 2223bis section 4.

AI: Fixed. Added Introduction. Reordered references after IANA section. Moved IPR after author's addresses.

4) Authors' Addresses and IPR Boilerplate (Full Copyright Statement) sections are supposed to NOT have numbers.

AI: Changed.

5) On title page, an Author's name should be on a single line, as should his/her affiliation. 2223bis section 4.1

AI: Changed.

6) Document is inconsistant in the use of "a"/"an" before acronyms pronounced beginning with a vowel. (E.g. "MTA".) Suggest using "An" consistently.

AI: Changed.

7) Document uses both "endpoint" and "Endpoint". Is a distinction intended?

AI: Changed to lower case except at the start of a sentence.

8) "the widest range of marketplaces as is possible" ->
"the widest possible range of markets"

AI: Changed.

10) format of references:
a) Author lists need a "," before the "and" if
there are more than two authors. See the reference sections in 2223
bis for examples.
b) If there is more than one author, an "and" is needed
c) if there is more than one author, the last author's name is
written as "F. Lastname" rather than "Lastname, F."

AI: Changed formatting.

****************************************************
Part 3 (1-13), Part 4 (14-30)
****************************************************

1) guidelines 3.2 para 1: need to describe relationship to other modules. for example, interfaces MIB since ifIndex is part of indexing scheme.

AI: Added descriptive text to overview section.

2) guidelines 3.2 para 2: need to document in narrative MIB modules (other than SMIv2 docs) from which things are imported

AI: Duplicate, see above.

3) guidelines 3.7.2: IANA considerations section needs to note that the mib-2 oid assignment for the module identity is needed

AI: Duplicate, see part 1 # 10 above.

4) the module name and the module-identity descriptor don't follow the recommended practices in guidelines appendix C (second bullet) and other descriptors don't follow the recommended practices in the third and fifth bullets) (I assume TenthdBm is intended for re-use by other MIB modules)

AI: Changed module identity descriptor to pktcIetfSigMib per appendix C bullet 2.

5) TenthdBm: "This data type" -> "This textual convention"

AI: Changed.

6) PktcCodecType: "Textual Convention defines " -> "This textual convention defines"

AI: Changed.

7) PktcCodecType: the ASN.1 comments aren't technically part of the TC. The descriptions of what the various enumerations should be given in the DESCRIPTION clause. (The ASN.1 comments don't hurt, but they're not enough.)

AI: Changed.

8) PktcCodecType: the "MUST" is inappropriate. It sounds like the intent is to mandate how a registry would operate. Is the likelihood of additional values being added to this enumeration high enough to justify creating an IANA registry, rather than keeping the TC in this MIB module?

AI: Changed.

9) (general) What are "international objects"? Does this term need to be defined?

AI: The use of "international" is a legacy issue dating from initial MIB creation.

10) PktcRingCadence: is a "cadence period" the same thing as a "cadence cycle"?

AI: Changed period to cycle.

11) PktcRingCadence: the sentence "Each bit
after the third octet represents 50 ms and 1 represents
ring and 0 represents silent." might be clearer if the first "represents" were replaced with "corresponds to", and if the first "and" were "where". ("silent" -> "silence" wouldn't hurt.)

AI: Changed.

12) PktcRingCadence: are implementations required to enforce any constraints on the values of a) the bit count field, b) the repeatable field, c) the 3 on-off transition limit, d) values for bits beyond the bit count, e) an octet-string length other than the minimum required to encode whatever length is specified in the bit count field?

AI: Open. A separate reflector thread has been started to solicit comments from IPCDN members on adding normative requirements.

13) PktcSigType: is any guidance needed on when to use reserved(2) and when to use other(1)?

AI: Changed description.

14) pktcSigDevCodecComboIndex: where does the range
constraint (1..255) come from? There's nothing in the document to justify that particular upper bound.

AI: No change. See reflector discussion.

15) pktcSigDevCallerIdSigProtocol: the DESCRIPTION needs to spell out what is meant by each enumeration

AI: Changed description.

16) pktcSigDev*Cadence: wouldn't it be simpler to put these
ten objects into a table? just a thought....

AI: No change.

17) pktcSigDefMediaStreamDscp: There's no antecedant for
"the new connection". Is "new connections" intended?

AI: Added the following before sentence starting with "When" to provide context for "new connections":

Any currently active connections are not affected by updates to this object.

18) pktcSignalingIndex: where does the range constraint
(1..255) come from? There's nothing in the document to
justify that particular upper bound.

AI: No change. See reflector discussion.

19) pktcSigDefNcsReceiveUdpPort: where does the lower range constraint come from?

AI: No change. IANA registers ports 0-1023 and port 1024 is indicated as reserved.

20) pktcSigPowerRingFrequency: for each of the enumeration values, the DESCRIPTION clause should spell out what that value means.

AI: Changed description.

21) pktcSigPulseSignalType: should spell out what each enumeration value means in the DESCRIPTION.

AI: Changed description to list enumerations.

22) pktcSigPulseSignalFrequency: does the "must" mean "MUST"
in the sense that an attempt to write a value incompatible with the instance's pktcSigPulseSignalType must be rejected? What value does it take / can it be set to for "inapplicable" signal types?

AI: Changed must to MUST. Added description for returning inconsistent value for an inapplicable signal type.

23) pktcSigPulseSignalDbLevel: What value does it take / can it be set to an inapplicable signal types?

AI: Added description for returning inconsistent value for an inapplicable signal type.

24) pktcSigPulseSignalDuration: what happens when something attempts to set this to a value that doesn't fall on one of the increment boundaries, or on the wrong increment boundary for the specific signal type?

AI: Added description for returning inconsistent value for incorrect increment for a signal type.

25) pktcSigPulseSignalPulseInterval: same questions.

AI: Added description for returning inconsistent value for incorrect increment for a signal type.

26) pktcSigPulseSignalRepeatCount: "must" means "MUST", right? Same questions as (24) and (25).

AI: Change must to MUST. Added description for returning inconsistent value for incorrect range.

27) pktcSigDevCIDFskAfterRing: how does one know whether a system is "international" or not? Is the table supposed to be of defaults? When "not used", what happens when one tries to get/set this object?