Re: new version of the draft

Frank Kastenholz <kasten@ftp.com> Wed, 16 December 1992 16:03 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04417; 16 Dec 92 11:03 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04411; 16 Dec 92 11:03 EST
Received: from babyoil.ftp.com by CNRI.Reston.VA.US id aa13521; 16 Dec 92 11:05 EST
Received: by ftp.com id AA23413; Wed, 16 Dec 92 10:49:39 -0500
Date: Wed, 16 Dec 1992 10:49:39 -0500
Message-Id: <9212161549.AA23413@ftp.com>
To: brian@dxcern.cern.ch
Subject: Re: new version of the draft
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Frank Kastenholz <kasten@ftp.com>
Reply-To: kasten@ftp.com
Cc: criteria@ftp.com

Brian,

Thanks for your comments on the criteria document.

 
 > 5.2.1 Addressing
 > 
 > Why isn't this section headed "multicasting"?

It was at one point. I don't recall why we changed it :-)

 > I think the discussion should distinguish more clearly "multicasting
 > for service location" from "multicast applications". The former
 > is unnecessary and undesirable (e.g. see the IP over FibreChannel proposal
 > for ARP without multicast) and the latter do not necessarily
 > require multicast at the IP level.
 > 
 > So (at the most) this is a SHOULD.

Craig and I (as we said in the document) believe that multicast is an
essential feature for future applications. I admit that we are trying
to foretell what will be needed as new and neat applications are
developed; that we are going out on a bit of a limb. However, we
believe that v7 should represent a significant functional improvement
over v4 or else there will be little reason to change.

 > 
 > 5.2.2 Extensibility
 > 
 > Yes. No. My problem is that I don't understand what extensibility
 > means, so I don't know if I need it. I raised the possible
 > criterion of "compatibility with multiprotocol routers" and this
 > was shot down without trace (but I still want it :-). But isn't
 > it one form of extensibility?  What are the others?
 > 
 > This criterion needs work before I can judge whether it's a MUST,
 > a SHOULD, or null.

By extensibility we mean that additional things can be added to the
protocol over its lifetime and that these additions can be done in
such a way that nodes which are not upgraded to support the addition
can still communicate with those that are upgraded. One possible
solution to this would be options.

I now remember talk at the BOF about "compatibility with
multiprotocol routers." I do not think that this is an
"extensibility" issue so much as an issue for the media over which
IPv7 should operate. In effect, IPv7 must be able to co-exist on any
medium that supports multiple protocols (e.g. for Ethernet, it would
have its own ether-type value).  If it can co-exist on multi-protocol
media, then routers ought to be able to determine that a packet is an
IPv7 packet and process it accordingly.


--
Frank Kastenholz