Subject: [MIB-DOCTORS] Clarification on the usage of the StorageType TC from RFC 2579

From: "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Tue, 13 Feb 2007 16:47:30 +0200

Keith McCloghrie and Bert Wijnen have recently discussed some aspects
related to the StorageType TC in RFC 2579.

Keith and Bert reached the conclusion that there is a need for
clarification of the paragraph in RFC 2579 which says:

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

Which should be interpreted as:

            MIB designers are encouraged to think about the
            behaviour of a 'permanent' row, i.e., a row in which
            some columnar objects are writeable, but the row 
            cannot be deleted.  If any behaviour is required in
            such rows in order for them to make protocol sense,
            then that behaviour needs to be specified either as
            a maximum level of access in an OBJECT-TYPE's 
            DESCRIPTION, or as a minimum level of access in a
            DESCRIPTION in a MODULE-COMPLIANCE statement.

Also, the following paragraph:

            "Describes the memory realization of a conceptual row.  A
            row which is volatile(2) is lost upon reboot.  A row which
            is either nonVolatile(3), permanent(4) or readOnly(5), is
            backed up by stable storage.  A row which is permanent(4)
            can be changed but not deleted.  A row which is readOnly(5)
            cannot be changed nor deleted.

should be understood to state that:

            A row which is permanent(4) can have some of its content
changed,
            but it cannot be deleted nor created.  A row which is
readOnly(5)
            can have none of its content changed, and cannot be deleted
nor
            created.

            The intent of the above text in RFC2579 is to also indicate
            that rows which are permanent(4) or readOnly(5) cannot be 
            created.

Please reply if you agree with this clarifications above or have
questions or comments until February 23rd, COB the latest. 

If we have consensus this clarification should be included in a future
revision of RFC 4181 or even of RFC 2579 if this one will be revised.
Until then we shall post this clarification on an OPS Area wiki page
where we plan to maintain temporarily the RFC 4181 additions and
clarifications. 

Dan

_______________________________________________
MIB-DOCTORS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mib-doctors

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 13 Feb 2007 16:10:29 +0100

>             DESCRIPTION in a MODULE-COMPLIANCE statement.

I thought I understood the RFC 2579 language; I am pretty sure I do
_not_ understand the above interpretation of it. Why do you talk about
"any behaviour"? I thought the question is whether any of the columns
of a permanent row should be writable. The last part of the sentence I
am not sure I do understand either.

My reference example of an implementation of the RFC 2579 rule is text
that goes like this (taken from an existing RFC):

         Conceptual rows having the value `permanent' must allow write
         access to the columnar objects A, B, C. If an implementation
         supports the X feature, write access must be also allowed to
         the columnar objects D, E, F.

Is the goal to state that such writability requirements can be stated
not only in the StorageType object but also in the module compliance
statement? If that is the case, I would simply write:

         Every usage of this textual convention is required to specify
         the columnar objects which a permanent(4) row (i.e., a row in
         which some columnar objects are writeable but the row cannot
         be deleted) must at a minimum allow to be writable. This
         specification may be provided as part of the DESCRIPTION
         clause of the OBJECT-TYPE definition or a MODULE-COMPLIANCE
         definition.

OK, this text still is not that simple... But at least it does not
talk about "any behaviour is required in such rows in order for them
to make protocol sense", which I find a bit difficult to take on as
a clarification. ;-)

/js

-- 
Juergen Schoenwaelder		 Jacobs University Bremen
<http://www.eecs.iu-bremen.de/>	 P.O. Box 750 561, 28725 Bremen, Germany

---

From: "David B Harrington" <[email-masked]>
Date: Tue, 13 Feb 2007 11:01:16 -0500

Comment inline 

> -----Original Message-----
> From: Romascanu, Dan (Dan) [mailto:[email-masked]] 
> Sent: Tuesday, February 13, 2007 9:48 AM
> To: MIB Doctors (E-mail); [email-masked]
> Subject: [MIB-DOCTORS] Clarification on the usage of the 
> StorageType TC fromRFC 2579
> 
> 

The quoted paragraph discusses the fact that volatile(2) data is lost
upon reboot.
I think it is important for MIB designers to state the volatility of
writable columns in permanent(4) rows.
>             but it cannot be deleted nor created.  A row which is

s/it/the row/

>             can have none of its content changed, and cannot 
I find the following paragraph confusing. "the above text" seems
somewhat ambiguous; is it referring to the new text or the old text?
Only the old text is in rfc2579; therefore "the above text in rfc2579"
is the text we are correcting. The intent of rfc2579 was to be
unambiguous, but it failed, hence the need for the new text. Doesn't
the new text make it clear that permanent or readOnly cannot be
created? Then why do we need this paragraph discussing the intent of
the original? If this is justification for the changes, or to
demonstarte backwards compatibility with the intent of the original,
then I would start the discussion with the problem statement, not
state the problem with the original, after making the changes.

---

From: Keith McCloghrie <[email-masked]>
Date: Tue, 13 Feb 2007 11:13:26 -0800 (PST)

Hi Juergen,

> "any behaviour"?

because the behaviour required to make protocol sense (a term already
used in RFC 2578's section 7.3) is not just about objects which need to
be writable, but can also be about objects which need to be read-only.

> I thought the question is whether any of the columns
> OK, this text still is not that simple...

That's the point: the original text wasn't right; Bert and I tried to
write new text to correct it but could not get the new text to be right
without it getting unacceptably complicated.  Your attempt is similar to
ours in that it's both: a) still not that simple and b) still not right.

- the access supported by a compliant implementation falls within a
  range: minimal <= compliant <= maximal, as stated in RFC 2580:

     The MIN-ACCESS clause, which need not be present, is used to define
     the minimal level of access for the object named in the correspondent
     OBJECT clause.  If this clause is absent, the minimal level of access
     is the same as the maximal level specified in the correspondent
     invocation of the OBJECT-TYPE macro. 

- to say "... must at a minimum allow to be writeable" is to state a
  "minimal level of access", and RFC 2580's section 5 says:

      The MODULE-COMPLIANCE macro is used to convey a minimum set of
      requirements ...

  So, "is required to specify ... must at a minimum allow to be writeable"
  needs to be in a MODULE-COMPLIANCE statement.

- It's also possible to have objects with MAX-ACCESS of read-write/create
  but in a permanent row, write access to them doesn't make protocol
  sense.  For an example, suppose one object which contains the maximum
  size of another object in the same row; this likely has a maximal level
  of access of read-only in a permanent row, and that maximal access needs
  to be specified in the OBJECT-TYPE's DESCRIPTION.

  So, to say "... may be provided ... OBJECT-TYPE ... or MODULE-COMPLIANCE"
  is incorrect.  Where it is "provided" is determined based on whether it
  is minimal or maximal.

But, also consider the inverse:

- if no MIN-ACCESS is specified for the columnar objects which have
  a MAX-ACCESS of read-write/read-create, then they are implicitly
  required to be writable.  Thus, it is their *omission* (not their
  inclusion) from the MODULE-COMPLIANCE statement which specifies that
  they are required to be writable !!

- 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).
  That shouldn't be specified in an OBJECT-TYPE, not only because it's
  a minimal requirement, but also because if a new version of the MIB
  module defines additional read-write objects in the same row, then
  the reason that the original object had to be writable has gone away,
  but the object's semantics haven't changed, and nor should its
  OBJECT-TYPE's DESCRIPTION.

- to say "Every usage of this textual convention is required to specify ..."
  is an overstatement because if all the columnar objects in the row have
  a MIN-ACCESS of read-only, then none are requried to be writable, and
  the behaviour is fully specified using MIN-ACCESS without using any
  DESCRIPTION clauses.

So, a table such as diffServDataPathTable in RFC 3289, has this:

       ... Conceptual rows
       having the value 'permanent' need not allow write-access to any
       columnar objects in the row."
 
in diffServDataPathStorage's OBJECT-TYPE, and this:

    OBJECT       diffServDataPathStart
    MIN-ACCESS   read-only
    DESCRIPTION
       "Write access is not required."

    OBJECT       diffServDataPathStorage
    MIN-ACCESS   read-only
    DESCRIPTION
       "Write access is not required."

    OBJECT       diffServDataPathStatus
    SYNTAX       RowStatus { active(1) }
    MIN-ACCESS   read-only
    DESCRIPTION
       "Write access is not required, and active is the only status that
       needs to be supported."

in the "ReadOnly" MODULE-COMPLIANCE, and this:

    OBJECT diffServDataPathStatus
    SYNTAX RowStatus { active(1) }
    WRITE-SYNTAX RowStatus { createAndGo(4), destroy(6) }
    DESCRIPTION
       "Support for createAndWait and notInService is not required."

in the "Full" MODULE-COMPLIANCE.

The above sentence quoted from diffServDataPathStorage's OBJECT-TYPE is
in the wrong place.  Instead, the "Full" MODULE-COMPLIANCE should
contain this:

    OBJECT       diffServDataPathStart
    MIN-ACCESS   read-only
    DESCRIPTION
       "Write access is not required in 'permanent' rows."

    OBJECT       diffServDataPathStorage
    MIN-ACCESS   read-only
    DESCRIPTION
       "Write access is not required in 'permanent' rows."

    OBJECT       diffServDataPathStatus
    SYNTAX       RowStatus { active(1) }
    MIN-ACCESS   read-only
    DESCRIPTION
       "Write access is not required in 'permanent' rows."

> But at least it does not
 
I don't believe the wording is ambiguous, because the end of the
sentence qualifies "any" as being:

                ... either as a maximum level of access
                ... or as a minimum level of access

but wordsmith-ing it not a problem, e.g., to "If a minimal or maximal
behaviour is required ...".

It is my belief that the whole purpose of the paragraph in question is
to make the MIB designer think about 'permanent' rows, and the proposed
rephrasing of it is intended to fulfill that purpose.

Also note that Dan's message proposed two changes; the second one
(which I didn't see you comment on) was to clarify that a readOnly or
permanent row cannot be created via SNMP, which is implicit in RFC 2579
based on the "e.g., partially in ROM" and "e.g., completely in ROM"
comments.

Keith.

---

From: Keith McCloghrie <[email-masked]>
Date: Tue, 13 Feb 2007 11:29:49 -0800 (PST)

Hi Dave,

> writable columns in permanent(4) rows.

You're right.  The two replacement sentences (beginning "A row which ...")
are intended to replace only the last two sentences in the paragraph,
not the whole paragraph.

> >             but it cannot be deleted nor created.  A row which is
 
Yes, that's an improvement.

> I find the following paragraph confusing.

You're right, the message got garbled -- when the replacement sentences
were added to the message, the "following paragraph" should been deleted.

Keith.

>  "the above text" seems

---

From: "Eduardo Cardona" <[email-masked]>
Date: Tue, 13 Feb 2007 10:05:54 -0700

I though that the original text was clear, 
For me, it means to define (in the Object's DESCRIPTION clause of the
object that invokes the TC StorageType) the subset of  columnar objects
that need writable access for a row of type 'permanent' 

What is the problem to be solved? 

>From a classical view of StorageType I think that those specification
requirements are orthogonal to the  compliance to either support SYNTAX
'permanent' or support Write-Access On all of any objects within the
row. 
In other words, I though the Compliance statement are on top of the
"behavior"/protocol specification.

Same cases could be seen when the Compliance statement indicates e.g.
SYNTAX of 'volatile' and 'nonVilatile' only, 
-> The spec requirements ( in the StorageType object DESCRIPTION) does
not apply to that particular compliance.

The other case is if each Compliance statement defines its own behavior
of StorageType writable object for permanent type rows, I don't think
the text is clear about that possibility (if possible or being
considered)

Thanks

Eduardo 

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Tuesday, February 13, 2007 8:10 AM
To: Romascanu, Dan (Dan)
Cc: MIB Doctors (E-mail); [email-masked]
Subject: [IETFMIBS] Re: [MIB-DOCTORS] Clarification on the usage of
theStorageType TC from RFC 2579

/js

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 14 Feb 2007 10:12:48 +0100

> Hi Juergen,

[...]

Thanks for the long explanation which is really helpful. I did cut it
from this response because I like to focus on the meta question first.

> rephrasing of it is intended to fulfill that purpose.

This is where I have a problem. The issue is much more complex as your
long response indicates and any attempt to squeeze that into a single
2-3 sentence paragraph will lead to text that the average MIB author
will not really understand. And this is why I doubt such a "clarification"
is actually helpful. Instead, I believe this topic warrants a longer
writeup (if we believe this topic to be important), like a section that
eventually becomes part of a revised version of RFC 4181.

> based on the "e.g., partially in ROM" and "e.g., completely in ROM"

I did not comment because I considered this rather obvious - in fact I
consider the RFC 2579 language pretty clear since creating something
at runtime to be (partially) stored in ROM is going to be difficult.

/js

---

From: "Wijnen, Bert \(Bert\)" <[email-masked]>
Date: Wed, 14 Feb 2007 11:03:05 +0100

W.r.t. 

> > permanent row cannot be created via SNMP, which is implicit in RFC 
> > 2579 based on the "e.g., partially in ROM" and "e.g., completely in
ROM"
> > comments.
> 
> I did not comment because I considered this rather obvious - 
> in fact I consider the RFC 2579 language pretty clear since 
> creating something at runtime to be (partially) stored in ROM 
> is going to be difficult.
> 

Let me add here that the discussion was mainly caused by me.
I had never payed enough attention to the "partially or
completely in ROM" text. I implemented SNMP agents on computer
platforms. And I allowed creation of readOnly and permanent 
rows. However, once created, they would follow all the rules.
And let me note that the fact that "cannot be deleted" was
explicitly mentioned, while "cannot be created" was not listed in
the DESCRIPTION clause made me think I was right. Had I realized 
this (i.e. if it had been explicitly stated that creation was 
also not allowed) way back when we did the TCs, I would have 
spoken up. You probably would have convinced me I was wrong, but
at least we would have considered computing plaforms where 
the readOnly and permamnet would be stored in a config file
on disk, as opposed to ROM.

Hope this explains why the discussion on this started between Keith 
and myself.

Bert

---

From: "Tom Petch" <[email-masked]>
Date: Wed, 14 Feb 2007 10:01:56 +0100

<inline>
Tom Petch

----- Original Message -----
From: "Keith McCloghrie" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; ""MIB Doctors (E-mail)"" <[email-masked]>
Sent: Tuesday, February 13, 2007 8:13 PM
Subject: Re: [IETFMIBS] Re: [MIB-DOCTORS] Clarification on the usage of the

>   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 comment suggests that an implementation which does not allow write access
MUST change the storage type to readOnly.

Generally I agree with the comment that this is complex and best addressed in
RFC4181bis

---

From: "Wijnen, Bert \(Bert\)" <[email-masked]>
Date: Wed, 14 Feb 2007 13:45:03 +0100

W.r.t. 

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

I'd like to let everyone know, that I (when I was AD) wanted
such text in the DESCRIPTION clauses if no write access was
needed to any column for a permanent row. I wanted that based
on the current guidamce in RFC2579:

Keith has convinced me that the text I wanted in DESCRIPTION clauses
was confusing/incorrect. So that is why we have this clarification
discussion, so we (MIB doctors) can give consistent advise.

Bert

---

From: Keith McCloghrie <[email-masked]>
Date: Wed, 14 Feb 2007 06:42:55 -0800 (PST)

> from this response because I like to focus on the meta question first.
 
OK.

> eventually becomes part of a revised version of RFC 4181.
 
Bert and I came to the conclusion that writing a new section for
a revised version of RFC 4181 is non-trivial, and we needed to alert
the community to the issue before going any further.  Bert and I also
agree that the current paragraph in RFC 2579, on which Bert and others
were basing their MIB reviews, is at least confusing and possibly 
incorrect.  I (and perhaps Bert as well) think it's both and therefore
should be replaced.  I agree that a "longer writeup" is warranted.  I
suggest the community should aim to have a new explanatory section
(e.g., an improved version of the explanation in my previous message)
*and* a new rule/guidance for MIB designers.

In the interim period, i.e., prior to the availability of such new
explanatory section and rule/guidance, I suggest that MIB reviews
should no longer be based on the current paragraph in RFC 2579.  So,
what should they be based on ??

My suggestion is to have a sentence/paragraph which makes MIB designers
think about 'permanent' rows -- specifically, to make them think harder
and longer than just adopting the expedient of adding this statement to
their OBJECT-TYPE(s):

       Conceptual rows having the value 'permanent' need not allow
       write-access to any columnar objects in the row.

In fact, I think that it would make more sense (than the above statement)
to have the DESCRIPTION of a StorageType object say that 'permanent' rows
aren't allowed.  Note: this would limit the maximal access which makes
protocol sense and thus would belong in the OBJECT-TYPE.  Note also that
the current paragraph in 2579 has the implicit assumption that 'permanent'
rows are possible/allowed.

Keith.