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
- new version of the draft Frank Kastenholz
- Re: new version of the draft John Curran
- Re: new version of the draft Brian Carpenter CERN-CN
- Re: new version of the draft Frank Kastenholz
- Re: new version of the draft Frank Kastenholz
- Re: new version of the draft Brian Carpenter CERN-CN
- Re: new version of the draft Steve Deering
- Re: new version of the draft Brian Carpenter CERN-CN
- Re: new version of the draft John Curran
- Re: new version of the draft Tony Li
- Re: new version of the draft Frank Kastenholz
- Re: new version of the draft Scott_Brim
- new version of the draft Tony Li
- Re: new version of the draft Beast (Donald E. Eastlake, 3rd)