Subject: [Entmib] Confirmming Meeting Consensus

From: [email-masked]
Date: Mon, 8 Dec 2003 08:24:11 -0500

Hi All,

During the meeting in Minneapolis, there was agreement
in the room on a few points, an dI'd like to confirm
that consensus on the mailing list.

In particular, we reached agreement at the meeting on
the following points:

 - We will deprecate the Alias Mapping Table so that the Entity
   MIB can advance to Draft Standard.
 
 - Future extensions to the Entity MIB should be handled as
   separate MIBs that augment the Entity MIB.
 
 - The Entity State MIB is currently too complex and should be
   simplified.

Please feel free to express your opinion on any of these
points on the mailing list.

Thanks,
Margaret

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 8 Dec 2003 14:43:30 +0100

>    MIB can advance to Draft Standard.

Well, this is what it takes...
  
>    separate MIBs that augment the Entity MIB.

Not sure how useful such a blanket statement is.
 
>  - The Entity State MIB is currently too complex and should be

I like to know what precisely people find too complex before subscribing 
to such a blanket statement. Can someone please explain (and perhaps
suggest what precisely needs to be removed)?

/js

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 8 Dec 2003 14:43:30 +0100

/js

---

From: Keith McCloghrie <[email-masked]>
Date: Mon, 8 Dec 2003 14:36:29 -0800 (PST)

> Well, this is what it takes...
   
It would be better to deprecate only the entity2Compliance statement,
and leave the objects and group with "current" status.  Specifically,
create a new entity3Compliance which is the same as entity2Compliance
except for having the "GROUP entityMappingGroup" removed.  This would
make implementation of the Alias Mapping Table the equivalent of a
"MAY".  There are many other RFCs which are at DRAFT STANDARD Status
which contain MAYs.  I find it very difficult to believe that a check
was made that all of their MAYs were implemented before they were
permitted to become DRAFT.  For example, to take a recent example,
"MAY" appears more than 80 times in RFC 3550; was it checked that
every one of those 80 has been implemented ??

Keith.

---

From: Keith McCloghrie <[email-masked]>
Date: Mon, 8 Dec 2003 14:36:29 -0800 (PST)

Keith.

---

From: "Syam Madanapalli" <[email-masked]>
Date: Tue, 9 Dec 2003 14:44:10 +0530

I am wondering if the following draft brings any interest
for the Entity State MIB.

State Model for IPv6 Interfaces
http://www.ietf.org/internet-drafts/draft-syam-ipv6-state-model-00.txt

But this state model is only for IPv6 Interfaces whereas Entity State MIB
covers every thing.

Thank you,
Syam

---

From: "Syam Madanapalli" <[email-masked]>
Date: Tue, 9 Dec 2003 14:44:10 +0530

Thank you,
Syam

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 9 Dec 2003 11:08:52 +0100

On Mon, Dec 08, 2003 at 02:36:29PM -0800, Keith McCloghrie wrote:

> "MAY".

Interesting proposal. Anyway, how many implementation reports did we 
get for these objects? None or just one and we need two?

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 9 Dec 2003 11:08:52 +0100

/js

---

From: "David T. Perkins" <[email-masked]>
Date: Tue, 9 Dec 2003 08:23:32 -0800 (PST)

HI,

I find the document specified below troubling.
The many reasons inlcude:
 1) there is already a well known state model for interfaces,
    which is specified in the IF MIB module. 
    a) The document does not specify why the IF state model
       should be replaced (or augmented) with another model.
    b) The document does not compare it's states and
       transitions those from the IF state model
 2) the state model in the document is primarily based
    on that found in X.731, but is not the same.
    a) the connection between the two models needs
       to be explained.
    b) the terminology used is that from the "TELCO" industry
       sector and not from the Internet DATACOM industry sector
 3) The state model doesn't support redundancy (and thus, is
    not sufficiently general to be used for physical
    (and logical) components that support redundancy)
 4) In many components, it can not be determined if the
    component is "operational", when it is administratively
    disabled.

Finally, it was sort of strange that the security section specified
a reference to SNMPv1 when the document is a model and does not
contain SNMP object nor notification definitions.

> > suggest what precisely needs to be removed)?
regards,
/david t. perkins

---

From: "David T. Perkins" <[email-masked]>
Date: Tue, 9 Dec 2003 08:23:32 -0800 (PST)

HI,

regards,
/david t. perkins

---

From: "Syam Madanapalli" <[email-masked]>
Date: Wed, 10 Dec 2003 11:27:36 +0530

>        should be replaced (or augmented) with another model.

IF state model does not provide the flexibility in defining the states.
When ifOperStatus is down, we do not why it is down. For example
in IPv6, the DAD may fail, there is no way to specify this in the state
info.

>        transitions those from the IF state model

Yep, this document is definitely not complete. The reason behind in
publishing the draft in this form is to see if this approach is useful for
defining
the states. After confirming the usefulness we can complete the draft.

>     on that found in X.731, but is not the same.

True

>        sector and not from the Internet DATACOM industry sector

True. But if the concept of State representation is useful we can define
this with Datacom terminology.

>     (and logical) components that support redundancy)

The current draft does not support this.

>     component is "operational", when it is administratively

What if an entity is Operational and it is locked by the administrator?

> contain SNMP object nor notification definitions.

As I mentioned earlier the draft is not complete by itself. This can be done
if the approach is useful.

---

From: "Syam Madanapalli" <[email-masked]>
Date: Wed, 10 Dec 2003 11:27:36 +0530

True

---

From: Keith McCloghrie <[email-masked]>
Date: Wed, 10 Dec 2003 07:39:18 -0800 (PST)

> in IPv6, the DAD may fail, there is no way to specify this in the state
 
On the contrary, the IF state model provides plenty of flexibility.
Each different type of media has its own failure conditions which
are specified in media-specific extensions.  So, if you want to define
IPv6-specific failures, then you need to define an IPv6-specific
extension.

Keith.

---

From: Keith McCloghrie <[email-masked]>
Date: Wed, 10 Dec 2003 07:39:18 -0800 (PST)

Keith.