Re: minutes of RIPv2 meeting in Amsterdam

Vince Fuller <vaf@valinor.stanford.edu> Fri, 16 July 1993 09:38 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00739; 16 Jul 93 5:38 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00735; 16 Jul 93 5:38 EDT
Received: from atlas.xylogics.com by CNRI.Reston.VA.US id aa03122; 16 Jul 93 5:37 EDT
Received: by atlas.xylogics.com id AA06668 (5.65c/UK-2.1-930202); Fri, 16 Jul 1993 05:37:45 -0400
Received: from Valinor.Stanford.EDU by atlas.xylogics.com with SMTP id AA02191 (5.65c/UK-2.1-930202); Fri, 16 Jul 1993 05:37:36 -0400
Received: by Valinor.Stanford.EDU (5.65/inc-1.0) id AA23576; Fri, 16 Jul 93 02:35:57 -0700
Date: Fri, 16 Jul 93 2:35:57 PDT
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Vince Fuller <vaf@valinor.stanford.edu>
To: Gary Scott Malkin <gmalkin@xylogics.com>
Cc: ietf-rip@xylogics.com, mwalnut@CNRI.Reston.VA.US
Office: Spruce Hall F15, (415) 723-6860
Usmail: Pine Hall 115, Stanford, CA, 94305-4122
Subject: Re: minutes of RIPv2 meeting in Amsterdam
In-Reply-To: Your message of Thu, 15 Jul 1993 10:01:16 -0400
Message-Id: <CMM.0.90.2.742815357.vaf@Valinor.Stanford.EDU>

    The use of the Routing Domain in RIP-2 is still unclear.  It was
    determined that the use of the field could not be sufficiently well
    defined to meet the varying needs of those few people who would like to
    use it.  The field also poses difficult MIB problems (discussed below).
    Therefore, it has been decided to remove the field from the protocol
    and leave a Must Be Zero field in its place.  Presumably, a motivated
    person could propose a third version of RIP which would define the use
    of this field.  This change does not, to the knowledge of those
    attending the meeting, invalidate any existing implementations and may
    therefore be made without requiring the specification to remain at the
    Proposed Standard level.

Unfortunately, I was unable to make the begining of the RIP-2 group meeting,
so I was unable to participate in the discussion which resulted in this
decision. I consider it to be a fairly serious mistake, since the routing
domain represents a fairly simple but powerful addition to the protocol.
I also feel that the MIB-based argument against the routing domain is
spurious at best: when we start deleting functionality from protocol specs
due to inadequacies in the network management architecture, something is
*seriously* wrong with the protocol design process. If the description of
the routing domain in the spec is not clear, that should be fixed.

	--Vince