PADLIPSKY@A.ISI.EDU (01/12/87)
Several messages were exchanged "off to the side" recently on the
FTAM Implications topic that I thought would be of interest (and
maybe even amusement) to all readers, so with Marshall Rose's kind
concurrence (which induced me to leave the last word with him...for
now), here they are:
[First he wrote (in reference to my public msg that contained the
observation that you can't do Top-down and Bottom-up simultaneously):]
2-Jan-87 12:28:36-EST,776;000000000001
Return-Path: <mrose@nrtc-gremlin.arpa>
Received: FROM NRTC-GREMLIN.ARPA BY USC-ISI.ARPA WITH TCP ; 2 Jan 87 12:25:24 EST
Received: from nrtc-gremlin by nrtc-gremlin.arpa id a015756; 2 Jan 87 9:24 PST
To: PADLIPSKY@a.isi.EDU
Subject: Re: "FTAM" Implications
In-reply-to: Your message of 30 Dec 86 10:42:00 -0500.
Date: Fri, 02 Jan 87 09:24:28 -0800
Message-ID: <15752.536606668@nrtc-gremlin.arpa>
From: Marshall Rose <mrose@nrtc-gremlin.arpa>
Nah. It just says that you can't do it all at once unless there are
timely communication between groups. If they all could have met at say,
NY, for a week, the problem would have been done. I put more blame on the
FTAM people for just not waiting for the presentation people to finish,
than anything else.
/mtr
[And then I wrote (with a sentence more at the end about including
his msg that I've deleted here since it made more sense to put his
msg first in this context):]
Marshall--
Rats. Here I went to all the trouble to compose the semielegant
bit of technicoaesthetic righteousness below and then when I
was in the midst of sending it I discovered that the msg I was
responding to was a private aside, not one you'd sent to TCP-IP.
If you think it would be amusing, do feel free to send it along
to the list anyway, with this preface on it so readers will know
there are no hard feelings going around (at least, I assume there
aren't).
cheers, map
I can't agree that the mismatch between what ISO FTAM needed and
what ISO Presentation offered can be passed off as just a peccadillo.
After all, on a practical level people apparently did waste time,
energy, and funds implementing to the DP in the unfullfilled but not
unreasonable expectation that the committee had "done its homework"
properly, and on a theoretical level the fact that the mismatch
happened at all still strikes me as being Wrong. Perhaps I was
too concise in my last msg, though, as to the reasoning, so as
one last shot in my current mini-salvo on the theme that Going
ISO Is Throwing Bad Money After Good (a brand-new Slogan), let's
try looking at it this way:
In the zeroth place, the designers of _any_ "Application" protocol
ought to be the best judges of what they need to virtualize. (If
they aren't, they shouldn't be the designers.) Therefore, they
shouldn't be expected/required to depend on whatever primitives
the Presntation committee happened to deem appropriate in the first
place. In other words, it's wrong to think of L6 as a monolith;
it should be a repository of the virtualizations dictated by the
L7 protocols that need them. Indeed, L6 is only defensible as
a separate layer at all because making it one might happen to
force modularity on the functions it offers; even that view assumes,
however, that there wouldn't be the desired modularity if there
were no layer boundary between the control and virtualization aspects
of an L7 protocol, and that doesn't have to be the case. We needn't
waste time on FTP's using Telnet on its control connection here, but as
things stand, L6 seems to be being treated as the de facto fiefdom
of its committee, and this amounts to letting non-carpenters dictate
the contents of the carpenters' toolboxes for all L7 carpenters,
not just FTAM.
That, without boring everybody, is a bit more on the It's Level [sic]
5-7 charge. Now to expand a bit on the other, related charge.
The relevant Slogan, assuming almost nobody ran off to find p. 215 of
The Book (especially since I didn't even bother to cite the page
last time) goes as follows:
The more layers, the more committees--
A bureaucrat's dream of the Feudal.
The more committees, the more disparities--
An implementor's nightmare of the futile.
That is, I take the FTAM misadventure to be evidence that it's
even worse to view a layer as a fiefdom than it is to view it
as a monolith. My vague understanding of "CASE" is that it wouldn't
have been invented if L6 hadn't "belonged" to the L6ers: another
case related to the FTAM one. But that's only a problem with
Presentation's being tardy, according to Marshall, or a problem that
would go away if L7ers could dictate what went into L6 (or even if
there were no pretense that 6 and 7 were different) according to
me. The real nastiness of the Layer-as-fiefdom psychology, it seems
to me, is exposed when you look at the deliberations of the
Reference Model Security Appendix committee. Two of them have
told me independently that the Security Appendix will call for the
vesting of _no_ security functionality in L5 (the "Session" level),
because--to paraphrase--there's nothing useful in the current L5
protocol (DIS or IS or whatever status it's reached). When you stop
and think that many approaches to "security" _require_ that audit
trails be kept on a per-session basis, I submit you should realize that
it's ludicrous for their approach to Security to have nothing to do
with their Session layer. What I think is happening is that, once
again, a committee's layer/"turf" if being viewed as sacred, and
it it gets things wrong the Reference Model gets distorted rather
than the layer/protocol gets fixed.
Now, not only don't I want this to go on too long, I also really
_don't_ want it to turn into "anything personal" with regard to
Marshall (whom I don't even know, and who probably isn't an ISORMite
in TCP-IPer's clothing to begin with), but my bottom line for all
this is that I think the recruiting poster we were originally
shown (when he said that FTAM looked like a good alternative to NFS)
turns out to have, when looked at under a magnifying glass, little
pictures of atrocities being committed in the background; if anybody
wants to join such an army, I can't stop them, of course--though I
do hope they won't do their campaign planning on TCP-IP. (Note that
I'm not saying I'm _for_ NFS, just against FTAM.) (Note also that
I'm not challenging his right to have shown the recruiting poster,
just what I take to be the implications of the poster.)
As a reward to those who have waded through all the metaphors, I'll
climb off the soapbox for now ... provided I don't have to rebut
the rebuttal, of course. (Which I hope and trust won't prove
to be necessary, since I should certainly be entitled to call
what I take to be Bad Art, Bad Art--which is really what all this
has been about, in some sense.)
[And finally he wrote:]
9-Jan-87 16:59:53-EST,2214;000000000001
Return-Path: <mrose@nrtc-gremlin.arpa>
Received: FROM NRTC-GREMLIN.ARPA BY USC-ISI.ARPA WITH TCP ; 9 Jan 87 16:57:16 EST
Received: from killer-rat by nrtc-gremlin.arpa id a013062; 9 Jan 87 13:56 PST
To: PADLIPSKY@a.isi.EDU
Subject: Re: "FTAM" Implications
In-reply-to: Your message of 08 Jan 87 16:21:16 -0500.
Date: Fri, 09 Jan 87 13:56:31 -0800
Message-ID: <15141.537227791@nrtc-gremlin.arpa>
From: Marshall Rose <mrose@nrtc-gremlin.arpa>
Mike - if you want to redistribute our last few messages back to
TCP-IP, fine with me. In response to your last message:
Since neither of us were on the two committees in question, it's
not really enlightening to second-guess why they did what they did.
However:
All ISO DPs are clearly marked as being subject to radical change.
If vendors want to implement the DP FTAM, then they do so at their
own risk. I imagine that they would do so just to say "We have an
FTAM" in order to scoop the market. Rather silly from the technical
viewpoing actually. From having observed the way standards bodies
operate, I know that unless a DP is based on some other existing
standard (e.g., a fully fleshed-out ECMA or ANSI contribution), that
the DP will change dramatically when it goes to DIS.
One observation I will make is, recently at a TCP/IP conference, a
speaker noted something to the effect that "the lack of
interoperability with TCP/IP offerings is what is pushing ISO
forward". My experience is quite the reverse: nothing has pushed
the acqusition of TCP/IP in the corporation I work for more than the
fact that ISO isn't ready yet (and the fact that if you look deep
enough through the sales glossies, you can figure that out).
As to the ISO poster: it's hard to argue with you, since I don't
like committees in general. As far as turf wars and all that
nonsense goes, the more I understand the ISO model, the more I like
it. I tend to like the final form of things more than the inital
stuff. So the security draft, for example, is a WD (working draft),
I believe, not even a DP. I'm ignoring it!
/mtr
-------