Fred,
Without being too abrupt, there were then , and are now, much better ways to
solve this problem.
A better approach would have been to fragment / reassemble at a higher layer.
That is the whole point of this document.
Ron
From: Templin (US), Fred L <[email protected]>
Sent: Thursday, November 29, 2018 1:08 PM
To: Joe Touch <[email protected]>; Stewart Bryant <[email protected]>
Cc: Ron Bonica <[email protected]>; int-area <[email protected]>;
[email protected]
Subject: RE: [Int-area] draft-ietf-intarea-frag-fragile-03
Hi, regardless of how old and obsolete NFSv2 is, the text in RFC1094 perfectly
addresses the point. I was working for Digital Equipment Corporation in the
late 1980’s when Sun Microsystems first came out with NFS. The two companies
tried to form an agreement where DEC would provide VAXen as NFS servers for
Sun clients, but many DEC VAX systems used an Ethernet line card called the
DELQA that was too slow to keep up with 10Mbps Ethernet line rates (!).
When the VAX received a burst of IP fragments of an 8KB NFS/UDP datagram,
it would drop one or more fragments and print “qerestart” in the system log.
The DELQA would then reset itself and the network would be out of service
until the restart completed. This rendered VAXen with DELQAs useless as an
NFS server, so DEC had to qualify which of the VAX product line could actually
support NFS. And, all because of IP fragmentation.
So, I think there is value in keeping the citation.
Thanks - Fred
From: Int-area [mailto:[email protected]] On Behalf Of Joe Touch
Sent: Thursday, November 29, 2018 8:41 AM
To: Stewart Bryant <[email protected]<mailto:[email protected]>>
Cc: Ron Bonica <[email protected]<mailto:[email protected]>>; int-area
<[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[email protected]>
Subject: Re: [Int-area] draft-ietf-intarea-frag-fragile-03
I would hope it would be evident from context, but sure.
Joe
On Nov 29, 2018, at 8:37 AM, Stewart Bryant
<[email protected]<mailto:[email protected]>> wrote:
Either way it is useful to give the reviewer a heads up as to nits giving
errors and this being OK.
S
On 29/11/2018 14:42, Joe Touch wrote:
They don’t need to be deleted if you include them deliberately. There is no
prohibition on citing such RFCs for your own documents historical background.
Joe
On Nov 29, 2018, at 4:06 AM, Stewart Bryant
<[email protected]<mailto:[email protected]>> wrote:
But, always worth including a "do be deleted" note to the reviewers to stop
then all sending in feedback about the nits failure.
Stewart
On 27/11/2018 20:42, Joe Touch wrote:
FWIW:
On 2018-11-27 12:22, Ron Bonica wrote:
Fred,
If the NFSv2 and iPERF issues are not blocking, I would like to omit them. The
following are rational:
...
- Mechanically, it is difficult to reference an RFC that has been obsoleted in
an internet draft. The NIT checker complains bitterly.
Those complaints are warnings only to help those who cite such documents
inadvertently; you can simply ignore them. (I do all the time - esp. for
historical discussions that cite early versions of newer RFCs or historical
standards).
Joe
_______________________________________________
Int-area mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/int-area<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_int-2Darea&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=FJe-ZLz5W_5P4zZNXPS2c1Uzn88Qj9c3vCcWT2wlPdw&s=j5WzcrfP668O1LWElFJ6h4LCpj4WKk7rkh-wSo4UuQg&e=>
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
