Subject: RE: [Hubmib] SONET MIB process issues

From: "C. M. Heard" <[email-masked]>
Date: Fri, 1 Feb 2002 16:38:55 -0800 (PST)

Ken,

You are the 2nd implementation we are looking for;  Marconi submitted
an implementation report some time ago that included the VT-related
groups (along with all the other SONET-MIB object groups).  If you will
submit an implementation report to Faye Ly, then we can get the SONET-MIB
advanced to Draft Standard.

Regards,

Mike Heard

On Fri, 1 Feb 2002, Chapman, Ken wrote:

> We implement them.  Are we the only one?  Or are we the one you are looking
> for?
> 	Ken
> ++++++++++++++++++++++++++++++++++++++++++++++
> Ken Chapman           Unisphere Networks, Inc.
>                       M/S 2380
> Tel: +1 978 589 0288  10 Technology Park Drive
> Fax: +1 978 589 0800  Westford, MA 01886
> Email: [email-masked]
> ++++++++++++++++++++++++++++++++++++++++++++++
> 
> 
> > -----Original Message-----
> > From: RJ Atkinson [mailto:[email-masked]]
> > Sent: Friday, February 01, 2002 9:46 AM
> > To: [email-masked]
> > Subject: Re: [Hubmib] SONET MIB process issues
> > 
> > 
> > All,
> > 
> > 	I'm not sure how IETF get this wedged, but we somehow need to fix
> > the processes such that optional-to-implement stuff can remain in RFCs
> > even if we can only locate 1 implementation of it -- subject to
> > discretion of the ADs responsible for the applicable WG of course.
> > 
> > 	If this is some interpretation of the IAB, then a method for the IAB
> > to revisit that should be found.  If this is in RFC-2026, then a 
> > constrainted edit of the relevant text needs to happen.
> > 
> > 	We need to remain enough flexibility in our processes that we can
> > still also apply common sense (and give the ADs responsible for a given WG
> > and that WG's documents more discretion/flexibility in how to handle things
> > in unusual circumstances -- such as this).
> > 
> > IMHO,
> > 
> > Ran
> > [email-masked]
> > Speaking only for myself
> > 
> > On Thursday, January 31, 2002, at 11:48 , C. M. Heard wrote:
> > > Actually, the SONET-MIB conformance statements already do that, and state
> > > that sonetVTStuff2 and sonetFarEndVTStuff2 are required only of NEs that
> > > implement VTs.  The problem is that we have only one implementation
> > > report that claims to have implemented those groups, and it requires
> > > two to advance to draft standard.
> > >
> > > Unfortunately, it's not really legal to split stuff up by moving the
> > > objects in question into a new MIB module, because they could be
> > > (in principle) be mentioned in an IMPORTS clause.  But an IMPORTS
> > > clause has to specify what module a descriptor is being IMPORTed
> > > from, so relocating an object would cause a problem in compiling
> > > any MIB module that references it.  RFC 2578 does not mention this
> > > particular problem, but it does disallow changing the descriptor
> > > associated with an existing object for this very reason.
> > >
> > > The other options are to recycle at proposed and wait for more
> > > implementation reports or to deprecate/obsolete the objects to
> > > effectively remove them from the standard.
> > >
> > > Some time ago (on the mibs list, I think it was) I think you said
> > > that it might make more sense for MIB modules to be BCPs rather
> > > than being on the standards track, and the more I am around them
> > > the more I agree with that.
> > >
> > > //cmh

---

From: "Faye Ly" <[email-masked]>
Date: Sun, 03 Feb 2002 17:26:06 -0800

Ken,

Your help will be greatly appreciated.  Here is
the questions you need to fill in case you are
interested in providing the information.

>1. Have you implemented RFC 2558/1595?
>2. If yes, what is the implemented objects/tables compared to the
>attached compliance statements? 3. Are you willing to publish the name of 
>your company in the
>implementation experience report?

Best,

-faye

-- current compliance statements

sonetCompliance2 MODULE-COMPLIANCE
    STATUS  current
    DESCRIPTION
            "The compliance statement for SONET/SDH interfaces."

    MODULE  -- this module
        MANDATORY-GROUPS { sonetMediumStuff2, sonetSectionStuff2 }

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

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

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

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

Tesink                      Standards Track                    [Page 57]

RFC 2558                   SONET/SDH Objects                  March 1999

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

        OBJECT      sonetSESthresholdSet
        MIN-ACCESS  read-only
        DESCRIPTION
          "Write access is not required, and only one
          of the enumerated values need be supported."

        GROUP       sonetLineStuff2
        DESCRIPTION
            "Implementation of this group is mandatory for all
             SONET/SDH systems that terminate SONET/SDH Lines,
             Paths or Virtual Tributaries."

        GROUP       sonetFarEndLineStuff2
        DESCRIPTION
            "Implementation of this group is optional for all
             SONET/SDH systems that terminate SONET/SDH Lines,
             Paths or Virtual Tributaries, and that
             provide for a far end block error (FEBE)
             information at the SONET/SDH Line Layer."

        GROUP       sonetPathStuff2
        DESCRIPTION
            "Implementation of this group is mandatory for all
             SONET/SDH systems that terminate SONET/SDH
             Paths or Virtual Tributaries."

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

        GROUP       sonetFarEndPathStuff2
        DESCRIPTION
            "Implementation of this group is optional for all
             SONET/SDH systems that terminate SONET/SDH
             Paths or Virtual Tributaries, and that process
             Far End information."

        GROUP       sonetVTStuff2
        DESCRIPTION
            "Implementation of this group is mandatory for all
             SONET/SDH systems that terminate SONET/SDH Virtual
             Tributaries."

Tesink                      Standards Track                    [Page 58]

RFC 2558                   SONET/SDH Objects                  March 1999

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

        GROUP       sonetFarEndVTStuff2
        DESCRIPTION
            "Implementation of this group is optional for all
             SONET/SDH systems that terminate the SONET/SDH
             floating Virtual Tributaries, and that process
             Far End information."

    ::= { sonetCompliances 2 }

>From: "C. M. Heard" <[email-masked]>
>To: "Chapman, Ken" <[email-masked]>
>CC: AToMMIB Mailing List <[email-masked]>,        Faye Ly 
><[email-masked]>, Nathan Kohn <[email-masked]>
>Subject: RE: [Hubmib] SONET MIB process issues
>Date: Fri, 1 Feb 2002 16:38:55 -0800 (PST)
>
>Ken,
>

_________________________________________________________________
Join the world’s largest e-mail service with MSN Hotmail. 
http://www.hotmail.com

---

From: "Chapman, Ken" <[email-masked]>
Date: Mon, 4 Feb 2002 10:17:20 -0500

Faye,
Sorry for not responding sooner.
To answer your questions:

       Yes.

2. If yes, what is the implemented objects/tables compared to the
   attached compliance statements?
       Quoting from the Unisphere Networks ERX product family Agent
Capabilities statement:

    SUPPORTS        SONET-MIB  -- RFC 2558
        INCLUDES  { sonetMediumStuff2,
                    sonetSectionStuff2,
                    sonetLineStuff2,
                    sonetFarEndLineStuff2,
                    sonetPathStuff2,
                    sonetFarEndPathStuff2,
                    sonetVTStuff2,
                    sonetFarEndVTStuff2 }
        VARIATION   sonetMediumLineCoding
            ACCESS      read-only
            DESCRIPTION
                "Only supports NRZ (4)."
        VARIATION   sonetMediumLineType
            ACCESS      read-only
            DESCRIPTION
                "Only supports Multi-Mode (4)."
        VARIATION   sonetMediumLoopbackConfig
            DESCRIPTION
                "Only supports setting one loopback state at a time; a value
                with more than one bit set will be rejected.  Setting
                sonetOtherLoop (bit 3) is also not a valid operation."

3. Are you willing to publish the name of your company in the
   implementation experience report?
       Yes.

Please let me know if there is more information required.
Cheers,
	Ken

> From: Faye Ly [mailto:[email-masked]]
> Sent: Sunday, February 03, 2002 8:26 PM
> To: [email-masked]; Chapman, Ken
> Cc: [email-masked]; [email-masked]
> > > We implement them.  Are we the only one?  Or are we the 
> one you are 
> >looking
> > > for?
> > > 	Ken
> > > > still also apply common sense (and give the ADs 
> responsible for a 
> >given WG
> > > > and that WG's documents more discretion/flexibility in 
> how to handle 
> >things
> > > > > Actually, the SONET-MIB conformance statements 
> already do that, and 
> >state
> > > > > that sonetVTStuff2 and sonetFarEndVTStuff2 are 
> required only of NEs 
> >that
> Join the world's largest e-mail service with MSN Hotmail. 
> http://www.hotmail.com
> 

======================================= 
This email message is for the sole use of the intended recipient (s) and may
contain confidential and privileged information, including without
limitation, Confidential and/or Proprietary Information belonging to
Unisphere Networks, Inc. Any unauthorized review, use, disclosure or
distribution is prohibited. If you are not the intended recipient, please
contact the sender by reply email and destroy all copies of the original
message.

---

From: "Faye Ly" <[email-masked]>
Date: Mon, 04 Feb 2002 15:29:26 -0800

Ken,

This is great!  Thank you so much.

-faye

>From: "Chapman, Ken" <[email-masked]>
>To: 'Faye Ly' <[email-masked]>, [email-masked]
>CC: [email-masked], [email-masked], "Scano, John"  
><[email-masked]>
>Date: Mon, 4 Feb 2002 10:17:20 -0500
>
>Faye,

_________________________________________________________________
Chat with friends online, try MSN Messenger: http://messenger.msn.com