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

From: Keith McCloghrie <[email-masked]>
Date: Wed, 14 Feb 2007 07:20:01 -0800 (PST)

> >   ...
> >
> > - also consider a table in which one object, X, is the only object which
> >   doesn't have a MAX-ACCESS of read-only.  In a permanent row in such a
> >   table, X has to be writeable (otherwise, the row would be a readOnly row).
> 
> I think that that is too limiting.  I think that a permanent row should allow
> for an implementation to be read-only as for example in RFC4368
> 
>  ' mplsLcAtmStdIfConfStorageType OBJECT-TYPE
>       SYNTAX        StorageType
>       MAX-ACCESS    read-create
>       STATUS        current
>       DESCRIPTION
>           "The storage type for this conceptual row.
>            Conceptual rows having the value 'permanent(4)'
>            need not allow write-access to any columnar
>            objects in the row." '

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

So, taken literally and using my understanding of the intent of RFC 2579,
I have come to the conclusion that DESCRIPTIONs like
mplsLcAtmStdIfConfStorageType's are inconsistent with RFC 2579, from which
the TC's definition is IMPORTed; note: this includes some that I wrote :-(.

> Your comment suggests that an implementation which does not allow write access
> MUST change the storage type to readOnly.

I don't think it's a matter of "change".  I think it's a matter of not
supporting 'permanant' rows.  To take it one step further, it could be
argued that this construct:

         OBJECT   xxxStorageType
         MIN-ACCESS   read-only
         DESCRIPTION  " ...

is (by definition) incomplete without a SYNTAX clause, e.g., one way to
make it complete would be:

         OBJECT     xxxStorageType
         SYNTAX     StorageType {
                        other(1),       -- eh?
                        volatile(2),    -- e.g., in RAM
                        nonVolatile(3), -- e.g., in NVRAM
                        readOnly(5)     -- e.g., completely in ROM
                    }
         MIN-ACCESS read-only
         DESCRIPTION  " ...

Keith.

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

---

From: Keith McCloghrie <[email-masked]>
Date: Thu, 15 Feb 2007 05:58:07 -0800 (PST)

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

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

> It sounds like you're reading "e.g." as though it were "i.e."
 
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.

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

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

Keith.