Subject: Re: [IETFMIBS] Re: [MIB-DOCTORS] Clarification on the usage of the

From: Randy Presuhn <[email-masked]>
Date: Thu, 15 Feb 2007 04:03:27 -0500 (EST)

Hi -

>From: Keith McCloghrie <[email-masked]>
>Sent: Feb 14, 2007 10:20 AM
>To: [email-masked]
>Cc: [email-masked], [email-masked], Keith McCloghrie <[email-masked]>
>Subject: Re: [IETFMIBS] Re: [MIB-DOCTORS] Clarification on the usage of the
...
>Your interpretation would be consistent with RFC 2579 *if* the latter said:
>
>                permanent(4),   -- e.g., partially or completely in ROM
>                readOnly(5)     -- e.g., completely in ROM
>
>but it doesn't, and  http://www.m-w.com/dictionary/partial  says:
>
>    of or relating to a part rather than the whole : not general or total
...

It sounds like you're reading "e.g." as though it were "i.e."

I guess I'm just inordinately dense, but after all this discussion,
I still don't see a real problem.  The hypothetical complecations
set forth arise from the assumption that a permanent row MUST
manifest at least one read-write instance.  However, no matter
how many read-write objects are present, at a protocol level
they may still all appear to be read-only due to access control,
so even the "protocol sense" argument doesn't seem helpful here.

So far, all the proposed solutions seem worse than whatever
the problem is.  That for some tables on some systems rows
marked "permanent" might be indistinguishable from those
marked "readOnly" doesn't seem to me to be a real problem,
whether in theory or in operation.

Randy

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

---

From: Randy Presuhn <[email-masked]>
Date: Fri, 16 Feb 2007 12:17:52 +0700 (GMT+07:00)

Hi -

>Sent: Feb 15, 2007 8:58 PM
>To: [email-masked]
>Cc: [email-masked], [email-masked]
>Your response addresses only one part of the problem.  The part you
>don't address is that specifying a minimal level of access in an
>OBJECT-TYPE always causes a conflict, or a redundancy, or both.
>
>Specifically, statements such as:
>
>       Conceptual rows having the value 'permanent' must allow
>       write-access to the XXX columnar object in the row.
>or
>       Conceptual rows having the value 'permanent' need not allow
>       write-access to any columnar objects in the row.
>
>do not belong in an OBJECT-TYPE, because all MODULE-COMPLIANCE
>statements (by definition) specify a minimal level of access for
>every object in that MIB, either explicitly or implicitly.

I disagree with the claim that the function of the MODULE-COMPLIANCE
statements makes it inappropriate to include information regarding
the semantics of a row whose storage type is permanent.
Since this is a multi-object constraint, I'd argue that it really
does belong in the DESCRIPTION for the OBJECT-TYPE(s)
affected.

>  Thus,
>
>a) in the common case of specifying two MODULE-COMPLIANCE statements,
>with one as readOnly and the other as a "full", including either of
>the above statements is in the OBJECT-TYPE conflicts with one of
>the MODULE-COMPLIANCE statements;

No, it does not, or at least no more than any of the other language
included, for example, to identify which objects must be written in order
for a row to be created.  A sane reader recognizes that readOnly
implementations are by definition crippled.  If it is logically necessary
(based on the MIB's funtion) for an object in a permanent row to
be writeable, then a readOnly MODULE-COMPLIANCE is pointless.

>b) in the common case of specifying just a readOnly MODULE-COMPLIANCE,
>a "need not allow" statement in the OBJECT-TYPE is redundant, and

Redundancy isn't bad if it improves clarity.

>a "must allow" statement in the OBJECT-TYPE conflicts with the
>MODULE-COMPLIANCE statement.

See comments above on the lameness of readOnly compliance.

>No.  First, my interpretation is that the part that is "e.g.," is the
>storage medium, not the level of access; the DESCRIPTION confirms this
>interpretation because it says:
>
>     A row which is permanent(4) can be changed but not deleted.

???  Though some media preclude deletion, it is just as
possible for an implementation to preclude deletion of
something that exists in an alterable medium.

>Second, since something in ROM cannot be changed, "completely in ROM"
>is not even an example of 'permanent'.

That is why the degenerate case of a "permanent" row with
no alterable elements should really be readOnly.  The whole
point of providing "permanent" was to allow objects (in the OO
sense) instantiated from ROM-like media, but with alterable
attributes.  *Which* attributes would need to be alterable
depends on just what instances of that class need to do, and
not just an implementor whim.

>If you want to use the access control argument, then the statement
>in StorageType's DESCRIPTION:
>
>            Every usage of this textual convention is required to
>            specify the columnar objects which a permanent(4) row must
>            at a minimum allow to be writable."
>
>is meaningless, and should just be ignored.
>
>Indeed, that would be simple and solve the problem.

I believe the rationale for the sentence in the StorageType
description was to spell out the difference between permanent
and readOnly rows.  If an implementation does not support
rows that can be modified, then it shouldn't use the
StorageType value of permanent.

Randy