Re: Amsterdam BOF

Fred Baker <fbaker@acc.com> Mon, 19 April 1993 20:35 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa26286; 19 Apr 93 16:35 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa26282; 19 Apr 93 16:35 EDT
Received: from atlas.xylogics.com by CNRI.Reston.VA.US id aa07265; 19 Apr 93 16:35 EDT
Received: by atlas.xylogics.com id AA31541 (5.65c/UK-2.1-930202); Mon, 19 Apr 1993 16:35:37 -0400
Received: from SAFFRON.ACC.COM by atlas.xylogics.com with SMTP id AA15006 (5.65c/UK-2.1-930202); Mon, 19 Apr 1993 16:35:28 -0400
Received: by saffron.acc.com (4.1/SMI-4.1) id AA15910; Mon, 19 Apr 93 13:33:37 PDT
Date: Mon, 19 Apr 93 13:33:37 PDT
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Fred Baker <fbaker@acc.com>
Message-Id: <9304192033.AA15910@saffron.acc.com>
To: gmalkin@xylogics.com
Subject: Re: Amsterdam BOF
Cc: ietf-rip@xylogics.com, mrose@dbc.mtview.ca.us

>> ... since it's the MIB we're having trouble with, I thought you'd
>> like to know about it.  Perhaps someone from the NM Directorate
>> would like to attend.

As of recently, I *am* on the NMD, and I plan to be in attendance.

I don't think the fundamental issue is a MIB issue.  Jeff wants to
change the scope of the protocol specification to include unnumbered
links, which affects the way links are managed, and has what I consider
to be a proprietary protocol mechanism which he doesn't care to
interoperably document but wants reflected in the protocol
specification and the MIB - and by the way wants reflected in the OSPF
MIB as well.  These issues affect the MIB but are not essentially MIB
issues.  The MIB is little more than a list of the management values
that the protocol specifies.

If we accept his protocol (and I have no problem with the unnumbered
interfaces part), the MIB as he has proposed it is probably fine. The
issue is the "routing domains" aspect of the protocol, which he insists
is outside the scope of RIP-II.  I say that if it is outside the scope
of RIP-II, then no reference to it should occur within RIP-II.  If it
should be referred to within RIP-II, then either RIP-II or another RFC
should document the concept so that I and twenty other vendors can
interoperably implement it.

Fred