Subject: [Hubmib] Re: 53rd AToMIB agenda items

From: Kaj Tesink <[email-masked]>
Date: Wed, 30 Jan 2002 12:02:12 -0500

At 08:54 PM 1/29/2002 -0800, C. M. Heard wrote:

>... the WIS MIB does need for the updated SONET-MIB (2558bis) to
>be published concurrently.  We have received three implementation
>reports on the list, but only one (Marconi's) claims support for
>sonetVTStuff2 and sonetFarEndVTStuff2.  We need a second implementation
>of those conformance groups in order to advance to draft.
>
>If the second report for sonetVTStuff2 and sonetFarEndVTStuff2 is not
>forthcoming by the time the WIS MIB has passed WG last call then my
>inclination would be to request that the SONET-MIB be recycled at
>proposed with the changes now in the 2558bis draft, with advancement
>to be requested when the reports are in hand.

the problem with the sonetVTStuff2 and sonetFarEndVTStuff2
is that, as per the conformance clause, you dont implement
it when you dont support VTs. so its optional in the sense of
you only support it when you need it. i see your logic but
i havent seen this logic applied in other cases yet.
it would be both a pity and a problem if you cant advance
the spec because of this; if you dont get the implementation feedback
now you may not get it two years from now either. in that case
the logical conclusion would be to dump the sonetVTStuff2 and
sonetFarEndVTStuff2? lets hope we can get some additional
implementation feedback.

we'll need some AD wisdom here on the process.

kaj

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

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 31 Jan 2002 15:42:36 +0100 (CET)

> sonetFarEndVTStuff2? lets hope we can get some additional

Perhaps Bert can comment on the MIB specific issues of how to handle
this.

In cases where there are some parts of a proposed standard that do not
have multiple interoperable implementations where the result has been
that those pieces have been lifted out of into a separate specification.

Then the core part can be advanced to draft standard while the other 
specification can be a proposed standard.

Of course, the fact that there isn't two independent interoperable 
implementations might mean that the feature isn't useful and it might
make sense to drop it completely. But there is this middle ground of 
separating out the less implemented parts.

  Erik

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 31 Jan 2002 16:48:14 -0500

> specification can be a proposed standard.

I'm wondering if the pain of splitting the stuff into separate documents
might be avoidable in this case by editing the MIB document to indicate
which OIDs are mandatory-to-implement and which are optional-to-implement.
I thought that was one use of the Conformance Clause, but might be 
confused.

Ran
[email-masked]

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 31 Jan 2002 16:48:14 -0500

Ran
[email-masked]

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 31 Jan 2002 15:42:36 +0100 (CET)

Erik