Subject: RE: [Entmib] #355: OSI State to Something New Spectrum

From: "Sharon Chisholm" <[email-masked]>
Date: Sun, 2 May 2004 05:01:51 -0400

hi

Actually, the issue was more/also whether there was consensus to change the
current MIB a lot to diverge from the ITU-T model. We've diverged from it as
has made sense to the working group, but there were a few requests for
changes such as object renaming which in my personal view didn't make sense
to do since they seemed non-value add changes. My take on consensus to
diverge further is that we are somewhat split on the issue.

Sharon

-----Original Message-----
From: Margaret Wasserman [mailto:[email-masked]] 
Sent: Saturday, May 01, 2004 11:28 AM
To: Randy Presuhn; [email-masked]
Subject: Re: [Entmib] #355: OSI State to Something New Spectrum

Hi Randy,

I did not see strong support for making changes to the Entity State 
MIB to bring it more in line with the ITU model, so I do not think 
that we have consensus to make these changes.

Unless you disagree with my assessment, Sharon should mark this issue 
as closed.

Margaret

At 12:30 PM -0800 3/25/04, Randy Presuhn wrote:
>Hi -
>
>>  From: "David T. Perkins" <[email-masked]>
>>  To: "Randy Presuhn" <[email-masked]>; 
>> <[email-masked]>
>>  Sent: Thursday, March 25, 2004 12:04 PM
>>  Subject: Re: [Entmib] #355: OSI State to Something New Spectrum
>...
>>  Randy - it gets back to a fundamental question, which is  "Is the 
>> ITU model and the specification for it worthwhile?"  In the 10+ years 
>> that I have asked this question, I have NEVER  gotten an answer. 
>> NEVER! In my own extensive analysis  (which included creating both 
>> state and alarm MIB modules  that are MUCH closer to the ITU models 
>> and specs than the  documents created in the IETF), it just isn't 
>> forth it.  Now, if someone would volunteer to show me an 
>> implementation  where the benefits surpass the costs, I'll create 
>> time to  learn from them, and change my tune. But pointing me to
>>  documents and manuals just doesn't cut it. Is this clear?
>...
>
>I think the difference here is in our understanding of "the ITU model". 
>It sounds like your understand it to mean *all* the stuff in X.731.
>However, that's *not* how X.731 was meant to be used.   It provides
>a core (Administrative/Usage/Operational states) of rather wide 
>applicability, and a bunch of other knobs and dials that an object 
>definer can use when appropriate.  I'm arguing to keep this thing 
>simple, i.e., not add anything (even from X.731) unless there is a 
>clear need for it.
>
>So, if one were defining an object class using X.731, and only 
>operational state was meaningful, then objects of that class simply 
>wouldn't have administrative or usage states.  This maps well to using 
>the TCs in this MIB module.  From my perspective, this alone would be 
>useful.  When one has to do this in something like the entity state 
>table, it is not as nice.  The workaround of adding additional "not 
>applicable" values to the enumerations is ugly, but it's the kind of 
>ugliness we're accustomed to in the SNMP world.
>
>Returning to your question: is having operational state worthwhile? 
>Absolutely, for the objects that need it.  Is having administrative 
>state worthwhile?  Same answer.  This is how X.731 was designed to be 
>used.
>
>Randy
>
>
>
>_______________________________________________
>Entmib mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/entmib

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

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

---

From: Margaret Wasserman <[email-masked]>
Date: Mon, 3 May 2004 07:35:45 -0400

Sharon corrected my understanding of issue #355 (see below).  But, my 
conclusion is much the same.

At this point we have had multiple WG Last Calls on this document 
and, according to our charter, we are quite overdue to send it to the 
IESG...  So, I think that it should require consensus of the group to 
make any major changes to the document at this point.  Do others 
agree with that position?

Given that we are split on this particular issue, I do not believe 
that we have consensus to make these changes so we should not make 
them.  Does that make sense?

Margaret

---

From: Margaret Wasserman <[email-masked]>
Date: Mon, 3 May 2004 07:35:45 -0400

Margaret

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 13 May 2004 17:13:15 +0300

Makes sense to me. I do not see major flaws in the current document. I do have my personal reservations on the granularity of some of the objects, and my personal opinions on the usefulness of another one or two the way that they are defined. So may have other. However, this work is useful, Sharon did a good job as editor, and this document is IMO at the appropriate level of quality to deserve a try on the standards track.

Regards,

Dan

> From: [email-masked] [mailto:[email-masked]]On 
> Behalf Of Margaret Wasserman
> Sent: 03 May, 2004 2:36 PM
> To: Sharon Chisholm
> Cc: [email-masked]
> Subject: RE: [Entmib] #355: OSI State to Something New Spectrum
> 
> 
>

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 13 May 2004 17:13:15 +0300

Regards,

Dan