Re: The (perceived) requirement to be an IETF Standard
Eric Travis <travis@gst.com> Mon, 24 June 2002 13:46 UTC
Message-ID: <3D1722BE.5030103@gst.com>
Date: Mon, 24 Jun 2002 09:46:38 -0400
From: Eric Travis <travis@gst.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020615 Debian/1.0.0-3
MIME-Version: 1.0
To: Daniel Shell <dshell@cisco.com>
Cc: adrian.hooke@jpl.nasa.gov, tcpsat@grc.nasa.gov
Subject: Re: The (perceived) requirement to be an IETF Standard
References: <4.3.2.7.2.20020624085057.0b481ef0@lint.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-tcpsat@grc.nasa.gov
Precedence: bulk
Status: RO
Content-Length: 3448
Lines: 96
Dan, Daniel Shell wrote: > Eric > > This my opinion on SCPS. > > If NASA/JPL decide that this is SCPS and it family the "space standard" > then do it. Do not expect much commercial support for a new IP protocol. I'm afraid that you are mistaken... There is *nobody* advocating a "new IP protocol", IPv4 and IPv6 do nicely with the identified space extensions - if that's what a mission eventually chooses to use. I think you will find that all the testing that Will had previously referenced was over IPv4. Commercial support means different things to different "industries"; The space community is well supported by industry, it's just that it may not be yours. Diversity is generally a good thing. The overlap between the traditional Internet economy and the spaceborne community is likely to be terribly small except when the data hits a groundstation - then it is more of a traditional networking environment. Spacecraft have been operating a long time without commercial support from "Internet-related" companies... The ability to purchase flight qualified hardware/software from companies such as your own would be nice, but it is hardly a critical requirement. So, while it is a cool idea to stitch up end-to-end connections from an orbiting instrument to a principle investigator in Lyon, a compelling reason to do so (economic or technical) has yet to surface. In time, it may still come - until then, mission architects always have had that option. BTW: SCPS is not a "NASA/JPL" thing; Please let's try and get past these attempts at marginalizing, OK? You are inadvertantly insulting more people that you might imagine who have never been affiliated with NASA, let alone JPL. > Also there are lot of options using IP that NASA has not even explored > and should be look at > such as RTP, and other enhancements ongoing in the IETF. There is always the promise of something brighter on the horizon. RTP is not really a suitable solution for reliable bulk data transfer. I would have expected a reference to something like SCTP in such an argument. Surely this isn't all just a case of "Not Invented Here"... > Also there are lot of options using IP that NASA has not even explored > and should be look at > such as RTP, and other enhancements ongoing in the IETF. Well... the space community (the folks who *are* intended to use the SCPS recommendations) has already "given them legitimacy" by standardizing them; You may not think much of the standards organizations (plural) that cover the community of interest - and that is your right. > So why not? Lack of return on investment? Lack of forseeable benefit to the IETF (what motivation is there for the an IETF area director to put this on an agenda)? Lack of forseeable benefit to the space community? I'm afraid that if this is as cogent the argument gets for bringing niche community requirments (how many spacecraft get launched each year that are not telecommunication bent-pipes?) then we're not going to get very far in convincing those who capable of supporting an IETF effort. I'm still faced with the question: Why? Based on your response, I can only conclude that there is no compelling need/benefit for the IETF to attempt to standardize what happens in niche communities. Terrestrial wireless will eventually have a huge impact on the Internet, but communications to space based entities? Not in the foreseeable future. Eric
- The (perceived) requirement to be an IETF Standard Eric Travis
- Re: The (perceived) requirement to be an IETF Sta… Daniel Shell
- Re: The (perceived) requirement to be an IETF Sta… Eric Travis
- Re: The (perceived) requirement to be an IETF Sta… David Carek
- Re: The (perceived) requirement to be an IETF Sta… Adrian J. Hooke