This Working Group Did Not Meet, but held an Interim Meeting
NOTE: This charter is a snapshot of the 41st IETF Meeting in Los Angeles, California. It may now be out-of-date. Last Modified: 08-Oct-97
Chair(s):
Robert Moore <remoore@us.ibm.com>
Routing Area Director(s):
Joel Halpern <jhalpern@newbridge.com>
Routing Area Advisor:
Joel Halpern <jhalpern@newbridge.com>
Mailing Lists:
General Discussion:snanaumib@external.cisco.com
To Subscribe: snanaumib-request@cisco.com
Archive: ftp://ftp.cisco.com/snanaumib/mail-archive
Description of Working Group:
The SNA NAU MIB Working Group is chartered to define a set of managed objects for SNA Network Accessible Units. These objects will provide the ability to monitor and control those devices, providing fault, configuration, and performance management, and will be consistent with the SNMP framework and existing SNMP standards.
The working group has completed MIBs for base SNA NAU functions, for LU Type 6.2 or APPC (Advanced Program-to-Program Communication), and for APPN (Advanced Peer-to-Peer Networking). MIBs for Dependent LU Requester (DLUR) and for HPR (High Performance Routing) are nearing completion. The working group is currently working on a MIB for APPN Extended Border Node (EBN).
The working group will make sure that its work is aligned with the SNA DLC MIB Working Group, due to the close relationship between the devices being worked on by the two groups.
Goals and Milestones:
Done |
|
Begin discussion of proprietary MIBS and develop a single proposal. |
Done |
|
Post an Internet-Draft of the SNA NAU Services MIB. |
Done |
|
Submit the SNA NAU Services MIB to the IESG for consideration as a Proposed Standard. |
Done |
|
Post proprietary MIB modules. |
Done |
|
Develop and post a single proposal for structure of the MIB module. |
Done |
|
Meet at IETF to review proposed structure/walk through. |
Done |
|
Post Internet-Draft of the APPC MIB. |
Done |
|
Post second Internet-Draft of APPC MIB. |
Done |
|
Meet at IETF to review MIB (if necessary). |
Done |
|
Achieve consensus on the final Internet-Draft. |
Done |
|
Post Internet-Draft of the APPN MIB. |
Done |
|
Submit revised APPN MIB to as an Internet-Draft. |
Done |
|
Submit the APPC MIB Internet-Draft to the IESG for consideration as a Proposed Standard. |
Done |
|
Achieve consensus on the new SNA NAU MIB Internet-Draft. |
Done |
|
Post Internet-Draft of HPR MIB. |
Done |
|
Submit the SNA NAU MIB Internet-Draft to the IESG for consideration as a Proposed Standard. |
Done |
|
Submit revised HPR MIB as an Internet-Draft. |
Done |
|
Submit HPR MIB Internet-Draft to IESG for consideration as a Proposed Standard. |
Done |
|
Submit DLUR MIB to the IESG for consideration as a Proposed Standard. |
Aug 97 |
|
Post Internet-Draft of EBN MIB. |
Oct 97 |
|
Submit revised EBN MIB Internet-Draft. |
Dec 97 |
|
Submit APPN MIB to IESG for consideration as a Draft Standard. |
Dec 97 |
|
Submit APPC MIB to the IESG for consideration as a Draft Standard. |
Dec 97 |
|
Submit EBN MIB to IESG for consideration as a Proposed Standard. |
Internet-Drafts:
· Definitions of Managed Objects for Extended Border Node
· Definitions of Managed Objects for APPN
Request For Comments:
RFC |
Status |
Title |
RFC1665 |
PS |
Definitions of Managed Objects for SNA NAUs using SMIv2 |
RFC1666 |
PS |
Definitions of Managed Objects for SNA NAUs using SMIv2 |
RFC2051 |
PS |
Definitions of Managed Objects for APPC |
RFC2155 |
PS |
Definitions of Managed Objects for APPN using SMIv2 |
RFC2232 |
PS |
Definitions of Managed Objects for DLUR using SMIv2 |
RFC2238 |
PS |
Definitions of Managed Objects for HPR using SMIv2 |
Minutes of the SNA NAU Services MIB (snanau) Working Group
The IETF SNA NAU MIB WG and the AIW APPN MIBs SIG held a joint meeting in Raleigh, North Carolina at AIW 16 (3/18/98). Bob Moore chaired the meeting.
The following people were present:
Bob Moore, IBM remoore@us.ibm.com
Bob Clouston, Cisco rclousto@cisco.com
Victor Freyer, Cisco vfreyer@cisco.com
Jim Cobban, Nortel jcobban@nortel.ca
Matthew Finlayson, DCL mcf@datcon.co.uk
Mike Evans, DCL mike@datcon.co.uk
Dennis Chimienti, Wall Data dchimien@walldata.com
Mike Cambria, Lucent Tech. mcambria@lucent.com
Uwe Staebeler, HOB ustaebel@hob.de
Richard Wunderlich, HOB rwunder@hob.de
Sudhakar Velkanthan, IBM svelkant@us.ibm.com
Gary Dudley, IBM dudleyg@us.ibm.com
Ralph Case, IBM caser@us.ibm.com
Ed Tremblay, IBM tremblay@us.ibm.com
Bill Graves, IBM wgraves@us.ibm.com
Hwaam Lee, IBM hwaam@us.ibm.com
Special thanks to all those who contributed to the very successful technical discussions that took place during meeting.
The following items were discussed in the meeting:
I. First draft of v2 of the APPN MIB (ietf-snanau-appnmib-v2-00.txt)
· We agreed that given both the state of the MIB and the state of the IETF's thinking on demonstrating interoperability for MIB implementations, we should put version 2 of the APPN MIB forward for approval as a second Proposed Standard, rather than for approval as a Draft Standard.
· We reaffirmed our approval of the MLTG and link counter type objects that we had approved earlier.
· In discussing the previously approved Branch Extender objects, we decided that the whole question of how these objects fit into the rest of the MIB should be examined. This was done at a (somewhat) separate post-meeting; the results of this meeting are documented below, under item 8.
· We considered two alternatives for the Year-2000-unready object appnNodeMib Version:
- deprecate it, and add a Year-2000-ready replacement
- deprecate it, but don't define a replacement.
We agreed on the second of these two alternatives.
· We discussed how to correct the conformance clauses in the MIB. In the current draft both compliance and object group statements have been extended, without registering them under new OIDs. We discussed deprecating the existing definitions and replacing them with new superset definitions, versus keeping the existing definitions and adding new definitions containing only the deltas. Bob Moore will look into this issue, and come up with a proposed solution in the next draft.
II. First draft of the APPN Traps MIB (ietf-snanau-appntrapmib-00.txt)
· The only technical issue we discussed was splitting the conformance groups up, so that implementations would have the option of omitting the DLUR trap and its associated objects (e.g., if they didn't support DLUR) or the ISR counters trap (e.g., if they didn't support ISR). The group agreed to this change.
· With the inclusion of this one change to the conformance section, the MIB SIG (and the AIW) agreed to AIW Approved Pages status for ietf-snanau-appnmib-v2-00.txt. An updated version of the document will be distributed by 3/27, with electronic AIW Closed Pages status targeted for two weeks after that date.
III. Attendees were polled for any additional implementation experience for the DLUR and HPR MIBs (RFC 2232 and 2238, respectively), but no one responded.
IV. Status of the EBN MIB
The SIG / WG is still in agreement with the current draft, draft-ietf-snanau-ebnmib-01.txt. This MIB has been stalled for several months in the IETF, waiting for a review from Randy Presuhn. Since this is not the only MIB of ours that's awaiting Randy's review, and since there are also MIBs from the tn3270e WG on Randy's review queue, Bob Moore agreed to raise with Randy and with the Routing Area Director, Joel Halpern, the whole question of what to do about reviews for our MIBs.
V. HPR-IP MIB
We noted that the HPR-IP MIB had received AIW Closed Pages status as a part of the HPR-IP Architecture specification. (We also noted that the MIB was *not* a part of the Informational-RFC version of the specification that Gary Dudley submitted to the RFC Editor.) We agreed that we would handle this MIB in the same way we've been handling our other MIBs: create an Internet-Draft that includes it, get WG consensus on the I-D, and then submit it to the IESG for progression to Proposed Standard status.
VI. APPC MIB
We discussed the current and future status of this MIB. A question was raised about the possibility of subsetting the MIB (presumably fairly dramatically) to create something that APPN network nodes might implement to provide instrumentation for the APPN control sessions. There was consensus that this was probably a good idea, but nobody agreed to do it, and no network node vendor committed to implementing such a subset if it were defined.
VII. Schedule for Future Work
We discussed schedules for future work in the context of updating our IETF SNA NAU MIB WG charter. (We also discussed updating our AIW charter, but it's not as rigorous about requiring dates.) Taking the October 8, 1997 version of our IETF charter (i.e., the version on the IETF web site) as our starting point, we agreed to the following changes. All but the first of these apply to the section "Goals and Milestones."
· Update the second paragraph of the "Description of Working Group" section to reflect the current set of MIBs we're working on. A similar update will be made to our AIW charter.
· Mark the entry "Aug 97 Post Internet-Draft of EBN MIB" done.
· Mark the entry "Oct 97 Submit revised EBN MIB Internet-Draft" done. (This was actually done in Feb 98, but who's counting:-).)
· Delete the entry "Dec 97 Submit APPN MIB to IESG for consideration as a Draft Standard".
· Delete the entry "Dec 97 Submit APPC MIB to IESG for consideration as a Draft Standard".
· Change the date on the entry "Submit EBN MIB to IESG for consideration as a Proposed Standard" from Dec 97 to May 98.
Add the following entries:
Done Post v2 APPN MIB Internet-Draft
Done Post APPN Traps MIB Internet-Draft
May 98 Post revised APPN MIB v2 Internet-Draft
May 98 Post revised APPN Traps MIB Internet-Draft
May 98 Post HPR-IP MIB Internet-Draft
May 98 Submit EBN MIB Internet-Draft to IESG for consideration as a Proposed Standard
June98 Submit v2 APPN MIB Internet-Draft to IESG for consideration as a Proposed Standard
June 98 Submit APPN Trap MIB Internet-Draft to IESG for consideration as a Proposed Standard
June 98 Submit EBN MIB Internet-Draft to IESG consideration as a Proposed Standard
June 98 Submit HPR-IP Internet-Draft to IESG consideration as a Proposed Standard
VIII. Treatment of Branch Extenders in the APPN MIB:
Architecturally a Branch Extender (BX) is characterized as an APPN network node with certain additional capabilities, in somewhat the same way that an EBN is characterized. (In our MIBs a BX is ordinarily termed a Branch Network Node (BrNN); the two terms mean exactly the same things.) In fact a BX presents two "faces": an end node (EN) face upstream in the direction of the WAN, and a network node (NN) face downstream to nodes in the branch.
We decided that a BX should (actually "SHALL" in the new IETF lexicon) behave as follows in its implementation of the APPN MIB:
· It will return the value "endNode(2)" in the object appnNodeType. This was the item we discussed the most. There is certainly an argument for a BX to return the value "networkNode(1)" here, since this is how the architecture classifies a BX. In terms of MIB behavior, however, a BX acts more like an EN:
- Two of the appnNodeEnUniqueInfoAndCaps provide useful information, while the value of every object in the appnNodeNnUniqueInfoAndCaps group can be derived from the fact that a node is a BX.
- Since a BX does not exchange network topology with any other node, there is no basis for assuming that a BX implementation would be capable of supporting the network topology tables in the APPN MIB. In any case, these tables in a BX would contain no information that is unavailable via other tables in the APPN MIB.
· To insure that there is no confusion, a new object will be added to the APPN MIB. This object SHALL be implemented by all APPN nodes; it indicates whether the node is currently configured as a BX. As the MIB stands now, a BX is identified only by the fact that it has at least one active uplink or downlink. With the new object, a management application can identify a BX even if it does not currently have any uplinks or downlinks active. Plus it's marginally easier to identify a BX that does have active uplinks or downlinks, since the application need only look at a single object.
· A new conformance group will be defined for a BX, containing the following objects:
- appnLocalTgBranchLinkType
- appnNodeEnNnServer
- appnNodeEnLuSearch
This conformance group will also indicate that a BX returns "endNode(2)" as its node type.
· The whole conformance section will be worded in such a way that it's clear what a BX is supposed to do, regardless of whether someone is thinking of a BX as a NN or an EN. The comments throughout the MIB and the document prose prior to the MIB module will also be updated in this way.
· Prose will be added to the document explaining how a management application can discover the topology of a branch via the objects in the MIB.
The next planned meeting for the WG / SIG is at AIW 17; the date and location for AIW 17 have not yet been decided.
Minutes submitted by Bob Moore, IBM Networking Software.
None Received
Roster Not Submitted