Subject: [Disman] draft-ietf-disman-event-mib-v2-06.txt: Issue-1 -> "MAY not"

From: Benoit Claise <[email-masked]>
Date: Mon, 18 Jul 2005 21:32:07 +0200

Dear all,

As pointed it out by Dave Shield in 
http://www1.ietf.org/mail-archive/web/disman/current/msg00648.html, one 
of the remaining issues in the draft is:

Another question:
   In a couple of places in this draft (mteObjectEntryStatus,
mteEventEntryStatus, etc), the description refers to the term
"MAY not".  What does this actually mean?

RFC 2119 defines "MAY" as referring to optional features,
and makes no mention of "MAY not".  Is this intended to be
a prohibition on making any changes to an active row?

If so:
  a)  Shouldn't the text use  "MUST NOT" ?
  b)  What's the purpose of the mteEventEnabled column
        if the value can't be changed?
  c)  What is the reason for this prohibition?

Specifically, we speak about:

mteObjectsEntryStatus OBJECT-TYPE 
    SYNTAX      RowStatus 
    MAX-ACCESS  read-create 
    STATUS      current 
    DESCRIPTION 
        "The control that allows creation and deletion of entries. 
        Once made active an entry MAY not be modified except to 
        delete it." 
    ::= { mteObjectsEntry 5 } 

mteEventEntryStatus OBJECT-TYPE 
    SYNTAX      RowStatus 
    MAX-ACCESS  read-create 
    STATUS      current 
    DESCRIPTION 
        "The control that allows creation and deletion of entries. 
        Once made active an entry MAY not be modified except to 
        modify the value of mteEventEnabled or to delete the entry." 
    ::= { mteEventEntry 5 } 

I share Dave's concern. It seems to me that MUST NOT is more appropriate in those two cases.

Feedback?

Regards, Benoit.

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 18 Jul 2005 15:19:10 -0700

Hi -

> From: "Benoit Claise" <[email-masked]>
> To: "Disman (E-mail)" <[email-masked]>
> Sent: Monday, July 18, 2005 12:32 PM
> Subject: [Disman] draft-ietf-disman-event-mib-v2-06.txt: Issue-1 -> "MAY not"
>

> I share Dave's concern. It seems to me that MUST NOT is more appropriate in those two cases.

Depending on what the WG would like the DESCRIPTION to mean,
let me suggest one of the two following for mteObjectsEntryStatus.
What implementations currently do could help us choose.

   This object allows creation and deletion of entries.
   When its value is 'active', attempts to set this object to any
   value other than 'destroy' MUST be rejected.  Likewise, attempts
   to set any of the of the other object instances in an active row
   MUST be rejected.

--or--

   This object allows creation and deletion of entries.
   When its value is 'active', implementations MAY reject requests
   to set this object to any value other than 'destroy'.  Likewise,
   implementations MAY reject requests to set any of the other
   object instances in an active row.

I would hope that the changes to mteEventEntryStatus would be similar.
My guess is that the first one was probably what was intended.
In both cases, note these requirements from the mib review guidelines:

     - The DESCRIPTION clause of the status column MUST specify which
       columnar objects (if any) have to be set to valid values before
       the row can be activated.  If any objects in cascading tables
       have to be populated with related data before the row can be
       activated, then this MUST also be specified.

     - The DESCRIPTION clause of the status column MUST specify whether
       or not it is possible to modify other columns in the same
       conceptual row when the status value is active(1).  Note that in
       many cases it will be possible to modify some writeable columns
       when the row is active but not others.  In such cases the
       DESCRIPTION clause for each writeable column SHOULD state whether
       or not that column can be modified when the row is active, and
       the DESCRIPTION clause for the status column SHOULD state that
       modifiability of other columns when the status value is active(1)
       is specified in the DESCRIPTION clauses for those columns (rather
       than listing the modifiable columns individually).

   - For conceptual rows that include a StorageType column:

     - The DESCRIPTION clause of the StorageType column MUST specify
       which read-write or read-create columnar objects in permanent(4)
       rows an agent must, at a minimum, allow to be writable.

Randy

---

From: Benoit Claise <[email-masked]>
Date: Tue, 19 Jul 2005 11:40:09 +0200

Hi Randy,

>My guess is that the first one was probably what was intended.
Unless I hear otherwise ... Let me modify the mteObjectsEntryStatus 
DESCRIPTION with your first proposition and the mteObjectsEntryStatus 
DESCRIPTION with:

 DESCRIPTION "This object allows creation and deletion of 
                         
              entries. When its value is 'active', attempts to
              set this object to any value other than 'destroy'
              MUST be rejected, except to modify the value of
              mteEventEnabled."

>       activated, then this MUST also be specified.
Before the mteTriggerEntryStatus is set to active, the mteTriggerObjects 
must point to the mteObjectsName in the mteObjectsTable. Right now, the 
corresponding mteObjectsEntryStatus doesn't have to be active before the 
mteTriggerEntryStatus.
I like this flexibility (the EVENT-MIB is complex enough already) but is 
it as designed?
Should we complement the mteTriggerEntryStatus DESCRIPTION with a 
sentence such as: The entry in the mteObjectsTable corresponding to the 
mteTriggerObject MUST be active before activating this entry?

Same remark with the mteTrigger*Event. Before the mteTriggerEntryStatus 
is set to active, the mteTrigger*Event must point to the mteEventName in 
the mteEventTable . Right now, the corresponding mteEventEntryStatus 
doesn't have to be active before the mteTriggerEntryStatus. Again, I 
like this flexibility, but is it as initially designed?

Regards, Benoit.

---

From: Dave Shield <[email-masked]>
Date: Tue, 19 Jul 2005 12:04:11 +0100

>    to set any of the of the other object instances in an active row

There's an extraneous "of the" in that text. 

> My guess is that the first one was probably what was intended.

Can I ask why?
There does seem to be a general tendency in a lot of MIBs to forbid
*any* alteration to existing rows, and I've never really understood
this.
  What is the fundamental objection to being able to tweak the
notification that is sent in response to some event, or the list
of varbinds that should be included?

Dave

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 26 Jul 2005 18:08:19 -0700

Hi -

> To: "Randy Presuhn" <[email-masked]>
> Cc: "Disman (E-mail)" <[email-masked]>
> Sent: Tuesday, July 19, 2005 2:40 AM
> Subject: Re: [Disman] draft-ietf-disman-event-mib-v2-06.txt: Issue-1 -> "MAYnot"
...
> I like this flexibility (the EVENT-MIB is complex enough already) but is

I, too, like this flexibility.  It simplifies things at both ends, especially when
one considers existance / validity checks that need to be performed anyway
if rows can be deleted.

> mteTriggerObject MUST be active before activating this entry?

In my opinion, no.

> like this flexibility, but is it as initially designed?
...

I think it is.

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 26 Jul 2005 18:19:52 -0700

Hi -

> From: "Dave Shield" <[email-masked]>
> Sent: Tuesday, July 19, 2005 4:04 AM
> Subject: Re: [Disman] draft-ietf-disman-event-mib-v2-06.txt: Issue-1 ->"MAY not"
...
> > My guess is that the first one was probably what was intended.

Because the second interpretation makes things even more complicated for
management applications.  My personal preference would have been to
require implementations to support modification while active, but I
don't recall that we had consensus for that.

> *any* alteration to existing rows, and I've never really understood

Yup.  Back in my days as an implementor, I couldn't understand it either.
Folks seem to think it makes things simpler, but in general I haven't
found it to be true.  A case where it *does* make sense is where a
row can be thought of as a marshalling area for the parameters of an
action invocation (remote procedure call).  But for the most part,
I think it simpler and more robust to define the behaviour when
dependencies aren't satisfied than it is to define a creation / deletion
hierarchy.

...

Personally, I don't have any.  I get the feeling that it may be
at least in part a question of how the different phases in the
validation of set requests are handled in various SNMP toolkits.

Looking ahead, it will be most interesting to see how netconf and
netconf data models deal with configuring things like this.

Randy