Re: comments on draft-ietf-sming-reqs-02.txt

[Frank Strauss <strauss@ibr.cs.tu-bs.de>]

Hi!

Jamie> Juergen & Frank, thanks for the extensive feedback.  I have
Jamie> finally gotten through all 87 points.
Jamie> 1.  I have incorporated the editorial comments into the draft. [...]

Thanks, Jamie! I've
(a) compared your updated document against our 87-item-list,
(b) added a few very minor editorial changes (see diff below), and
(c) extracted those 31 comments that are still open (unchanged, only with
    some minor clearifications in square brackets) so that it is easier
    to give further comments on the interesting issues (see list below).

I hope to see some more input on the open issues until the deadline on
Friday.

 -frank




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.

15: We think that 4.1.4 as described [...] (neither SMIv2 nor
    SPPI are defined in ABNF) [...] 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.

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.

    [This affects 4.1.26, 4.3.5, 4.3.7, 4.3.11, 4.3.12, see also
    comments #58, #59, #61.]

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.

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.

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

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.

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.

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.

69: We believe this [4.3.17] 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.

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.

    [The remaining reasoning which says that the MODULE-INDENTITY is
    `not a problem' is still a bad argument for denying simplification
    If it would be an argument, we would have to move lots of stuff
    from 4.1 and 4.2 to 4.3.]

75: We suggest to complete remove 4.3.22 as it is already handled by
    4.1.8. It is a duplicate.

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.

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.

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.



111c111
<           The purpose of this document is to ensure that subsequent a
---
>           The purpose of this document is to ensure that a subsequent
130,132d129
<       <t>
<         Conventions used in this document:  
<       </t>
210c207
<                     <t>new: considered a new feature
---
>                     <t>new: considered a new feature.
573c570
<                     the union type attribute is constrained by the value of the
---
>                     the union attribute type is constrained by the value of the
733c730
<                     and EXTENDS in the SNMP/COPS_PR protocol mappings.
---
>                     and EXTENDS in the SNMP/COPS-PR protocol mappings.
1667c1664,1665
<                     overlapped with other requirements <xref target="issue5">
---
>                     overlapped with other requirements (<xref target="issue5">
>                   namespace control</xref>)
1823c1821
<         NIM and SMIng requirements draft.
---
>         NIM and SMIng requirements drafts.