CURRENT_MEETING_REPORT_



Reported by Jon Saperia/DEC

DECNETIV Minutes

At our meeting in Boulder we discussed/agreed on the following items:


 1. The general wording regarding a group's STATUS will be, for
    example; The implementation of the Network Management Group is
    mandatory for all systems which implement session layer
    communications.  For those groups which are required for all
    systems regardless; we will use the standard wording - The
    implementation of the Routing Layer Group is mandatory for all
    systems.

 2. Using the approach described above, we discussed the following
    groups and agreed as follows:
    System Group - Required if Session Layer is iplemented Network
    Managment Group - Required if Session Layer is implemented End
    Communications Layer Group - Required if Session Layer is
    implemented

      o Routing Group - Required
      o Circuit Group - Required
      o Adjacency Group - Required

    There are other groups that we did not discuss and will be proposed
    as Required unless they clearly do not make sense.

 3. Chuck Davin asked if we could work with people developing an X.25
    MIB to see if our X.25 section could be moved out.  Chris will
    investigate this.  If we can still effectively manage a decnet
    system with this change then we will move the X.25 section out.

 4. The phivExecPhysAddr object will be moved to the circuit group.

 5. All variables which use decnet versions such as the Management
    version will be treated not as sequences of INTEGERs but as
    DisplayStrings.

 6. All enumerated types will not start with 0, they will start with 1
    and a comment will be made in the DESCRIPTION field of each object
    when this change has been made.

 7. The phivSessionExecAddr object will be moved to the routing group.


                                  1






8. The Session Layer group will be combined with the Systems Group.

9. Several objects need to be put into tables, this will be done
   before we put the next revision out.

10. The object phivRouteMaxArea will be moved to the area group.

11. The SubAddr objects currently in the Routing group will be moved to
   the X.25 group.

12. The phivCircuitCommonType object will be modified to look like:



                                 2






    phivCircuitCommonType OBJECT-TYPE
           SYNTAX INTEGER {
                 DDCMP POINT (0)
                 DDCMP CONTROL (1)
                 DDCMP TRIBUTARY (2)
                 X25 (3)
                 DDCMP DMC (4)
                 Ethernet (6)
                 CI (7)
                 QP2 DTE20 (8)
                 BISYNC (9)
                 FDDI (15)
                 }
           ACCESS read-only
           STATUS mandatory
           DEFINITION
                 "Represents the type of the circuit.  For X.25 circuits, the
                 value must be set to X25.  For DDCMP and Ethernet circuits it
                 is read only and is the same value as the protocol of
                 the associated line."
           ::= { circuit 5 }

13. The follwing objects will be moved to the adjacency group:
         phivCircuitExecAdjacentNodeName
         phivCircuitExecAdjacentNodeAddr
14. The phivLineCounterTimer object will be deleted.
15. The phivLineDevice object will now be a DisplayString and the
    Communication DEVICE mnemonics section of the DESCRIPTION will be
    deleted.
    Nick will look through the level 1 routing information to see if
    this is required for end systems.


We did not have time to cover all items, but a great deal was
accomplished.  Our current goal is to have a draft we feel comfortable
putting in the drafts directory by the end of January.

Attendees

Chris Chiotasso          [email protected]
Anthony Chung            [email protected]
James (Chuck) Davin      [email protected]
Steven Hunter            [email protected]
Nik Langrind             [email protected]
Peter Lin                [email protected]
Oscar Newkerk            [email protected]
David Perkins            [email protected]
Kary Robertson
Jon Saperia              [email protected]



                                  3