Subject: Re: I-D ACTION:draft-ietf-atommib-sonetaps-mib-07.txt

From: Joan Cucchiara <[email-masked]>
Date: Thu, 02 May 2002 15:53:51 -0400

Hello,

Minor Question on the use of the transmission
Sub ID in the MIB.

Although the subID for this MIB is eventually 
assigned by IANA when it becomes an RFC, just
wondering why there is the use of the transmission
branch here? In other words, could this possibly
end up being assigned under mib-2 branch?

To explain my question a little more, I didn't see
any sonetAPS interface type listed in the IANAifType TC and
so was just wondering (usually when there is an ifType
then there is MIB under transmission branch).

 thanks, 
  -Joan

[email-masked] wrote:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the AToM MIB Working Group of the IETF.
> 
>         Title           : Definitions of Managed Objects for SONET Linear APS
>                           Architectures
>         Author(s)       : J. Johnson, M. Thatcher, J. Kuhfeld
>         Filename        : draft-ietf-atommib-sonetaps-mib-07.txt
>         Pages           : 43
>         Date            : 24-Apr-02
> 
> This memo defines a portion of the Management Information Base (MIB)
> for use with network management protocols in TCP/IP based internets.
> In particular it defines objects for managing networks using SONET
> linear Automatic Protection Switching (APS) architectures.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-atommib-sonetaps-mib-07.txt
> 
> To remove yourself from the IETF Announcement list, send a message to
> ietf-announce-request with the word unsubscribe in the body of the message.
> 
> Internet-Drafts are also available by anonymous FTP. Login with the username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
>         "get draft-ietf-atommib-sonetaps-mib-07.txt".
> 
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
>         [email-masked].
> In the body type:
>         "FILE /internet-drafts/draft-ietf-atommib-sonetaps-mib-07.txt".
> 
> NOTE:   The mail server at ietf.org can return the document in
>         MIME-encoded form by using the "mpack" utility.  To use this
>         feature, insert the command "ENCODING mime" before the "FILE"
>         command.  To decode the response(s), you will need "munpack" or
>         a MIME-compliant mail reader.  Different MIME-compliant mail readers
>         exhibit different behavior, especially when dealing with
>         "multipart" MIME messages (i.e. documents which have been split
>         up into multiple messages), so check your local documentation on
>         how to manipulate these messages.
> 
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> 
>   ------------------------------------------------------------------------
> Content-Type: text/plain
> Content-ID:     <[email-masked]>

---

From: "C. M. Heard" <[email-masked]>
Date: Thu, 2 May 2002 14:48:41 -0700 (PDT)

> end up being assigned under mib-2 branch?

What difference would that make (other than another
delay in getting this thing published)?

> then there is MIB under transmission branch).

This is not a hard-and-fast requirement, of course.  Here is
what http://www.iana.org/assignments/ianaiftype-mib says:

               Quite often, a media-specific MIB's
               OID-subtree assignment within MIB-II's 'transmission'
               subtree will be the same as its ifType value.
               However, in some circumstances this will not be the
               case, and implementors must not pre-assume any
               specific relationship between ifType values and
               transmission subtree OIDs.

One could argue that transmission is the right place for the
APS-MIB, since it is (effectively) an extension of the SONET-MIB,
and the latter is registered under transmission.  For whatever it's
worth, the WIS MIB (<draft-ietf-hubmib-wis-mib-03.txt>) is also
being registered under transmission for that reason.  Neither the
APS-MIB nor ETHER-WIS gets a unique interface type because they
use the already-defined sonet(39) (and sonetPath(50), in the case
of ETHER-WIS).  I'll grant that this is a weak argument, but there
really is no strong argument for rooting a MIB module in any
particular place.

//cmh

P.S.  For another example see the IPOA-MIB.

---

From: Joan Cucchiara <[email-masked]>
Date: Sat, 04 May 2002 14:46:27 -0400

Hello,

Could the ApsSwitchCommand and ApsControlCommand TCs 
specify what error codes the Agent is to return 
under the various conditions?

For example, the noCmd(1), says this value may not
be written, so if it was written would
the agent return a wrongValue error?

Also, if manualSwitchWorkToProtect(6) is already
switch to the protection channel, would the agent
return an inconsistentValue error?

Also, in the description of the apsCommandSwitch object,
it states "...If the APS switch command cannot be executed
because an equal or higher priority request is in effect, an
error is returned."  What error would this be?

If this could be clarified in the TCs and objects in the
MIB that would be appreciated.

  thanks, Joan

---

From: Mike Thatcher <[email-masked]>
Date: Mon, 06 May 2002 02:45:50 -0700

> the agent return a wrongValue error?
According to RFC 1905, 4.2.5, wrongValue is the appropriate response.

> return an inconsistentValue error?

Yes, since the description states that this command can only be applied to a 
working channel.

> error is returned."  What error would this be?

Again according to 1905 4.2.5, Inconsistent value error is the only appropriate 
response.

> MIB that would be appreciated.

I don't believe a clarification is required. RFC 1905 4.2.5 is clear about error 
returns for set processing.

miket

---

From: Joan Cucchiara <[email-masked]>
Date: Mon, 06 May 2002 09:05:19 -0400

> Again according to 1905 4.2.5, Inconsistent value error is the only appropriate

Based on the description of the object (quoted above), would think that
this
error should be resourceUnavailable...if the resource weren't being 
taken up by the equal or higher priority request, then the set should
probably succeed, right?  Why do you think this is inconsistentValue?

Could you explain a little more please?

> returns for set processing.

Okay, that is up to you.  My request to explicitly state the SNMP error
codes
was because I think that this would be helpful and avoid doubt, and also
may lead to greater interoperability.  I do see that more and more MIBs
are stating error codes so think this is generally a plus. 

just my 2 cents,
  thanks, 
   -Joan

---

From: Mike Thatcher <[email-masked]>
Date: Mon, 06 May 2002 15:05:57 -0700

>>Joan Cucchiara wrote:
...
> Could you explain a little more please?

I was looking at the new request being inconsistent with the existing request. I 
don't see the resource as unavailable, since it is available and is being 
operated on, just the command couldn't execute because of conflict with existing 
request.  If you think the resourceUnavailable is a better return code, I can 
live with that.

miket

---

From: Joan Cucchiara <[email-masked]>
Date: Mon, 06 May 2002 20:53:47 -0400

> request.  If you think the resourceUnavailable is a better return code, I can

Hi Mike,

I can see your point, but do think resourceUnavailable is more
meaningful error
in this situation.

  thanks, Joan