[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
comments on draft-ietf-sming-reqs-02.txt
- To: SMIng WG <sming@ops.ietf.org>
- Subject: comments on draft-ietf-sming-reqs-02.txt
- From: Juergen Schoenwaelder <schoenw@ibr.cs.tu-bs.de>
- Date: Fri, 29 Jun 2001 21:07:35 +0200
- Delivery-date: Fri, 29 Jun 2001 12:08:01 -0700
- Envelope-to: sming-data@psg.com
Frank and I have discussed the latest revision of the requirements
draft <draft-ietf-sming-reqs-02.txt>. Below are our consolidated
comments. Most of them are purely editorial. Some are probably
not. The order below is aligned with the structure of the document -
not with the importance of the comment.
01: The document talks in many places about a data modeling language
while we prefer the term data definition language. Some suggested
wording changes reflect this. (Note that the charter calls for a
data definition language and not a data modeling language.)
02: The abstract contains redundant text. Furthermore, the second
paragraph establishes a requirement and we think that it belongs
to the other requirements into the body of the document and not
into the abstract. Our proposal is to use the following
replacement text:
This document describes the requirements of a data definition language,
suitable for the modeling of network management constructs, that can
be directly mapped into SNMP [1] and COPS-PR [9] protocol operations.
The purpose of this document is to ensure that a subsequent
language specification is complete and consistent with the stated
requirements.
03: The Introduction talks about an object-oriented data modeling
language, which we believe is not called for explicitely in the
charter. There is also a sentence which does not make any sense at
all. Our proposal is to use the following replacement text:
This document describes the requirements for a new data definition
language that can be mapped into SNMP [1] and COPS-PR [9] protocol
operations. It may also be translated into SMIv2 [3,4,5] MIBs and
SPPI [10] PIBs. Concepts such as structures, attributes, methods,
conventions for organization into reusable data structures, and
mechanisms for representing relationships are discussed.
04: We suggest to change the last sentence in the first paragraph in the
section Motivation to the following text:
The result is that management interfaces for network protocols,
services and applications such as DHCP or Differentiated Services
may be represented in many different inconsistent fashions.
05: We also propose to replace the second paragraph with the following
text:
The SMIng working group will develop a new data definition language
to align the languages SMIv2 and SPPI since these are very similar.
06: In the third paragraph in section Motivation, please replace
"properties" with "their attributes". This is the only place where
the term property is used and we better not confuse people.
07: The third paragraph in section Motivation is kind of funny since
all the examples listed there are either rejected or nice to have
features later on.
08: We propose to reword the first paragraph in section 4:
The following sections define the requirements for the definition
of a new data definition language. The requirements have been
organized as follows: accepted requirements (Section 4.1),
nice-to-have requirements (Section 4.2), and rejected requirements
(Section 4.3). Appendix A contains a summary of the requirements
discussion that was generated in the SMIng working group.
We also propose to move the following sentence from section 4 into
section 1 and into the abstract:
This memo captures the results of the working group discussions
regarding the SMIng requirements process.
09: We suggest to remove the "Number" fields which contain the original
requirement number since this becomes irrelevant once this document
has been published.
10: The Type values "should" and "must" do not really make sense since
we already distinguish between accepted, nice to have and rejected
requirements. The proposal is to combine "should" and "must" into
a "fix" type:
* fix: considered a fix for a known problem in SMIv2 and/or SPPI
Note that the requirements that use "should" or "must" must be
updated.
11: Change the definitions of "new" as follows to remove requirement
language:
* new: considered a new feature
12: We suggest to replace
* NMRG: exists in the current NMRG specification proposal, but
not in SMIv2 or SPPI.
with:
* NMRG: exists in the NMRG proposal, but not in SMIv2 or SPPI.
13: We think there is no difference between WG and Individual. We
propose to remove Individual and to change all occurences of
Individual to WG.
14: Typo in 4.1.1: "should de" -> "should be"
15: We think that 4.1.4 as described is Type new (neither SMIv2 nor
SPPI are defined in ABNF) and it actually comes from the NMRG. In
fact, the title does not really match the description and this is
where the confusion comes in. Perhaps this needs to be split into
two requirements.
16: Typo in 4.1.5 "not-accessible"
17: It is interesting that we still have emtpy motivations, although
the WG process said that requirements without motivations will be
dropped. We should either add missing motivations or follow our
rules and drop things.
18: Add the following motivation for 4.1.8:
Already in SMIv2 and SPPI.
19: Remove the last sentence in 4.1.9. It is of course the job of the
WG to figure out how to address the requirements.
20: The SMIv2 is still alive. So change "SMI allowed" to "SMI allows"
in 4.1.12.
21: We propose to replace all occurences of "should" with "must" in
4.1.X and all occurences of "must" with "should" in 4.2.Y.
22: Remove "and OIDs that can be used to identify things" from 4.1.17
since this is already covered by 4.1.12.
23: The Type of 4.1.18 is new and not should.
24: Remove "standard format for" in the description of 4.1.18.
25: Remove the first sentence in the Notes of 4.1.18. We also suggest
to reformulate the second sentence as follows:
Discriminated unions have the property that the union attribute
type is constrained by the value of the discriminator attribute.
26: 4.1.19 is From SMI, SPPI and not just SPPI.
27: 4.1.20: We suggest to remove the sentence "A row pointer is a
special case of an instance pointer."
28: 4.1.21: Type should be "align"
29: We suggest to reword the description of 4.1.23:
SMIng must support a mechanism to derive new types from base types
that provide additional semantics (e.g., Counters, Gauges,
Strings, etc.). It may be desirable to also allow the derivation
of new types from derived types. New types must be as restrictive
or more restrictive than the types that they are specializing.
30: Change the title of 4.1.24 to:
Units, Formats and Defaults of Defined Types and Attributes
31: We think that 4.1.24 is of Type "fix" rather than "new".
32: The last sentence of the Motivation in 4.1.24 should be a Note.
33: We think that 4.1.25 is a nice to have requirement and belongs
into section 4.2. There are many issues associated with arrays and
I think they really belong into the category of things that SMIng
should support if we find a way to do it that is simple and easy
to use. Currently, there is not even agreement on the precise
access semantics of multi-valued attributes not how they could
potentially be mapped to SMIv2/SPPI constructs and SNMP/COPS-PR
protocol operations.
Note also that the last paragraph in the notes does not express a
clear requirement that arrays must be supported. (Despite that, we
do not understand what the "general problem" is.) The notes
already discuss issues with potential solutions - which we think
does not belong here.
34: 4.1.26 is unclear. The title says tables while the description
talks about attribute groupings, a phrase which is used to explain
requirement 4.1.29 (structures). This one also has an empty
motivation so this should probably just be dropped.
35: We suggest to replace 4.1.27 and 4.1.28 with the following:
4.1.27 Table Existence Relationships (1)
Type: align
From: SMI, SPPI
Description: SMIng must support INDEX, AUGMENTS, and EXTENDS in
the SNMP/COPS-PR protocol mappings.
Motivation: These three table existence relationships exist
either in the SMIv2 or the SPPI.
4.1.28 Table Existence Relationships (2)
Type: new
From: NMRG
Description: SMIng must support EXPANDS and REORDERS relationships
in the SNMP/COPS-PR protocol mappings.
Motivation: A REORDERS statement allows to swap indexing orders.
An EXPANDS statement formally states that there is a 1:n existence
relationship between table rows.
The fact that EXPANDS was mentioned in a note in another
requirement is not an argument to skip it here where it belong.
36: Take a break.
37: The note in 4.1.29 should be removed as it is neither possible nor
desirable to treat arbitrary attribute groupings as atomic data
structures in all protocol mappings.
38: We suggest to replace phrases suchs as "structures", "compound
types", "attribute grouping", "grouping of attributes" with just a
single term throughout the document. We suggest "attribute groups".
39: Typo in 4.1.30: "reuse attribute combination" -> "reuse of attribute
groups"
40: We suggest to remove the last sentence of the Motivation of 4.1.30.
We believe what the text says is wrong and it does not add to the
motivation.
41: We suggest to remove the last sentence of the Notes of 4.1.31
since it repeats the first sentence. We suggest to add:
Inheritance could help to add attributes to an attribute group
that are specific to a certain protocol mapping and do not appear
in the protocol neutral attribute group.
42: We think 4.1.33 should be of Type align.
43: We suggest to add "multiple" in 4.1.35:
Description: SMIng must allow the specification of uniqueness
constraints on attributes. SMIng should allow the specification
of multiple independent uniqueness constraints for a single
attribute group.
44: 4.1.36 is From SMI, SPPI.
45: 4.1.37 is From WG and Type is fix.
46: 4.1.38 is From NMRG and Type fix.
47: The motivation is wrong in 4.1.39. We suggest to use the following
text:
Motivation: This capability exists in SMIv2 and SPPI. The NMRG
proposal has the ability to express much of this information at
the protocol-dependent layer. Some compliance or conformance
information may be protocol-independent, therefore there is also
a need to be able to express this information in the protocol
independent part.
48: Typo in 4.1.39 Description: "mapping" -> "mappings"
49: 4.1.40 should be Type fix.
50: 4.2.2 should be Type new.
51: At first glance, it is somewhat confusing that discriminated
unions are required while unions are just nice to have. A
discriminated union is a more precise form of a union and hence
support for unions will fall out when doing discriminated unions.
And since discriminated unions are required, the nice to have
feature of unions will fall out anyway. There is certainly the
issue whether unions without a discriminator are desirable,
although arbitrary unions are classified as nice to have here.
We are confused (and hungry?)
52: We believe that 4.2.3 should be an accepted requirement and be
moved to section 4.1. We need to be able to distinguish between
reusable definitions and "final" definitions that should not be
further refined.
53: 4.2.5 should be of Type fix.
54: Replace "language" with "syntax" in the Note of 4.2.5.
55: We suggest to replace the Note of 4.3.1 with the following:
Notes: The SMIng language itself can not require what compilers
do that translate SMIng into something else. So this seems to
fall out of the scope of the current WG charter.
56: We believe that 4.3.2 is right now confusing a solution with the
problem statement. We believe that the underlying problem must be
solved and that this is a requirement. We also believe that the
solution mentioned in 4.3.2 should not be a requirement. (Still
following?)
Here is our proposal: We suggest to redefine 4.3.2 as shown below
and to move the new definition into section 4.1.
4.1.x Instance Naming
Type: align
From: SMI, SPPI
Description: Instance naming in SMIv2 and SPPI is different. SMIng
must align the instance naming (either in the protocol neutral
model or the protocol mappings).
Motivation: COPS-PR and SNMP have different instance identification
schemes that must be handled.
Notes: A solution requires to investigate how close the naming
schemes dictated by the protocols are. Perhaps it is feasible
to have a single instance naming scheme in both SNMP and COPS-PR,
even though the current SPPI and SMIv2 are different.
57: We do not understand requirement 4.3.4. Perhaps it is about
defining existence relations in the protocol neutral part while
4.1.27 and 4.1.28 focus on the protocol specific mappings in the
current SMIng proposal. Unless someone can explain this more
precisely, we suggest to remove this one completely. (There is no
value in documenting and rejecting requirements we do not even
understand.)
58: 4.3.5 should be dropped since it has no Motivation and the
Description and Notes do not help to explain what this is all
about.
59: 4.3.7 has no Motivation. Remove it.
60: COPS-PR requires subject categories in order to function. So 4.3.8
is a requirement (at least for the SMIng to COPS-PR mapping) that
must be addressed. We suggest to put it into 4.1 and to remove the
Note (which obviously was written by an SNMP bigot ;-).
61: 4.3.11 and 4.3.12 have no Motivation and should be dropped
altogether.
62: It does not make sense to keep 4.3.13 if we drop 4.1.12 (see above).
63: We suggest to remove the last two sentences in the Notes of 4.3.14
since we do not really understand what they say.
64: 4.3.15 should have Type fix.
65: 4.3.15 should be moved to section 4.1. The Notes should be
replaced with:
Notes: The 32 rule was added back in the days where compilers
could not deal with long identifiers. This rule is continuously
violated these days and it does not make sense to keep it.
66: ** important ** We believe that the document must explain what
"rejected requirement" means. Our understanding is that a rejected
requirement listed in 4.3 just means that the stated issue need
not be addressed by SMIng. It does not imply that SMIng must not
address it.
67: We suggest to remove 4.3.16 altogether as it is kind of out of
scope and 4.1.4 already requires a self-contained ABNF
specification which will help.
68: 4.3.17 should have Type fix.
69: We believe this belongs to section 4.1. The argument that this is
a no-brainer does not hold since SMIv2 and SPPI both suffer from
strange import rules. We suggest to remove the Notes.
70: The reasoning in the Notes of 4.3.18 is broken. SMIng is not only
used by the IETF.
71: We believe that 4.3.18 should be "nice to have". See also the
comments in Appendix A.
72: We suggest to remove the last sentence from the Notes in 4.3.20.
73: 4.3.21 should have Type fix.
74: The Notes in 4.3.21 seem to be in direct conflict with the
Motivation. This requirement proposed to drop the container for
module meta information for simplicity and the argument to drop
this proposal for simplicity is hard to understand.
75: We suggest to complete remove 4.3.22 as it is already handled by
4.1.8. It is a duplicate.
76: 4.3.23 should have Type fix.
77: We disagree with the Notes since ISO date strings are much easier
to read. We suggest to completely remove 4.3.23. This is also one
of the many little syntactic details that hardly qualify as a
separate requirement.
78: We have problems with the Notes in 4.3.24. We also believe that
this is one of the many little syntactic details that hardly
qualify as a separate requirement. So we suggest to remove it.
79: The last sentence in the Notes of 4.3.25 actually comes to the
conclusion that 4.3.25 is a requirement. So it should be in 4.1
rather than 4.3. Some rewording might help to get things straight
and the Notes should be deleted:
4.3.25 Assign OIDs in the Protocol Mappings
Type: new
From: NMRG
Description: SMIng should not assign OIDs to reusable definition of
attributes, attribute groups, events, etc. Instead, SNMP and
COPS-PR mappings should assign OIDs to the mapped items.
Motivation: Assignment of OIDs in protocol neutral definitions can
complicate reuse. OIDs of synonymous attributes are not the same
in SMI and SPPI definitions. MIBs and PIBs are already registered
in different parts of the OID namespace.
80: In the Notes of 4.3.26, replace "other requirements" with "other
requirements (4.1.9)".
81: 4.3.27 should have Type fix.
82: We propose to replace the Notes in 4.3.27 with the following text:
Notes: We believe that every odd numbered version of the SMI
must allow hyphens while every even numbered version disallows
hyphens. This means that the resolution of this issue depends
on whether SMIng will finally become SMIv3 or not.
83: 4.3.28 is From SPPI.
84: The Motivation of 4.3.28 is a bit unclear and the Notes are to
some extend wrong. We also believe that this belongs into 4.1 or
at least into 4.2. Note that the notes say that there are no
issues with this requirement. We suggest the following replacement
text:
4.x.y Referencing Tagged Rows
Type: align
From: SPPI
Description: PIB and MIB row attributes reference a group of entries
in another table. SPPI formalizes this by introducing PIB-TAG and
PIB-REFERENCES clauses. This functionality must be retained in
SMIng.
Motivation: SPPI formalizes tag references. Some MIBs also use tag
references (see SNMP-TARGET-MIB in RFC2573) even though SMIv2
does not provide a formal notation.
85: Clarify the last sentence in the Acknowledgements: ".. on the
original NIM draft and SMIng requirements draft."
86: We suggest to list people only once in a reference (affects [3,4]).
Also, [5] is missing a few names.
87: We are now leaving to the frameworkpub [11].
/js
--
Juergen Schoenwaelder Technical University Braunschweig
<schoenw@ibr.cs.tu-bs.de> Dept. Operating Systems & Computer Networks
Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany
Fax: +49 531 391 5936 <URL:http://www.ibr.cs.tu-bs.de/~schoenw/>