what is the cookbook (was thinosi in houston)

[Peter Furniss <[e-mail]>]

Dave,

Arising from the discussion about what should be in the agenda for Houston, 
I think we need to expose the discussion, because I'm not sure I'll cover all 
the views in the group.

The question is what kind of thing the "cookbook" is.

You said:

> 1.  In spite of our several discussions, I cannot definitely state what
> problem(s) your effort is trying to solve.  Therefore, I'd like a very
> terse statement(s) from you, in a list.  In particular, are there
> protocol technical deficiencies?  If so, which ones, e.g., smaller
> packets, greater processing efficiency,...whatever.  For the moment,
> assume that each problem to be solved will have a separate document.
> They are easier to combine than they are to separate.  List a candidate
> title for each document.
> 
> This is key.  I continue to believe that your effort is serving multiple
> masters and that it is confusing things, even if the various masters
> are worthy causes.


Yes, there certainly multiple problems, or aspects of it. Here's the list of 
factors (not in any special order, and attempting to be inclusive)

a) the OSI upper-layers leave options in the encodings, and do not 
recommend a preferred encoding

b) the OSI u-l documents are large and contain much material that is 
irrelevant to 90% of applications

c) the documents are inaccessible (i.e. paper versions are expensive)

d) the documents are impenetrable - it is hard to work out what to implement

e) OSI profiles are normally written as specific answers to the PICS of the 
base standards - so you need the base standard, and the PICS, and the 
profile, to establish that you only needed 5% of the base standard.

f) implementations have tended to be layered and general, which is not 
necessary

g) there is a need for definition of mappings of tcp-specified application 
protocols to the OSI infrastructure (not in the Internet proper of course)

h) there is a need for a (accessible) specification of the OSI u-l elements 
needed to support Directory Acces Protocol

i) there is a need for a (accessible) specification of the OSI u-l elements 
needed to support x.400 P7

j) there is a need for a (accessible) specification of the OSI u-l elements 
needed to support other OSI-based applications with simple requirements on 
the upper-layers.

( h and i are singled out because these are the OSI application protocols that 
are likely to be of greatest use in the Internet.  l is particularly z39.50 / SR )

Now there are answers to some of these other than developing documents in 
the IETF:
a) make a defect report on the base standards recommending a preferred 
encoding (I have)
c) get the OSI standards on-line (attempts being made but ...)
g) get ISO, ANSI, OIW, EWOS etc to define such mappings - has been and 
is being done in some cases
h) there is an ISP (International Standardised Profile) in the machinery - but 
note e)
i) as for h)

So the problem comes down to accessibility and usability of the specifications 
needed for "useful" application layer protocols, with the hope that making the 
specifications clearer will lead to better implementations.


> 2.  The document continues to have language about being able to do
> an implementation without reading the original ISO docs.  This puts
> it into the realm of an implementation guide.  

I don't understand. If we succeed, we have a *re-*specification of the 
protocol, not an implementation guide. Suppose we actually did it (for a single 
protocol in the layers perhaps) by editing the ISO text, chucking out 
irrelevancies and putting it in RFC format. Surely you wouldn't call that an 
implementation guide ? (If ISO were to do the converse to TCP, would that be 
an implementation guide ?)

>                                                                         While we MIGHT do that
> sort of thing in the IETF, we generally don't and I'd have to do some
> checking. To the extent that you are "profiling" ISO docs, you must
> and will write a separate doc which does only and exactly that.

This seems to be the central point. Yes we are profiling OSI *protocols*.  This 
profiling has been/is being done, in ISP format, as profiling ISO *documents*. 
These cannot be understood without reference to the base standard 
(sometimes referring to amendments that have not been published). The 
intent was to describe the same profiling in a manageable form - by building 
up from octets, rather than by subsetting 600 pages of specification.

We could reference the ISPs to define the profiles, and deem the present 
document to be advisory.

We could attempt brief summary profile, using ISO  terminology and not 
expecting to be standalone (or very comprehensible), and again deem the 
present document to be advisory.

We could treat the document as an independent specification of protocols 
that interwork with a subset of the OSI protocols, and have documents that 
define, in our terms, the use of the protocols made by particular applications, 
and somewhere a specification, in OSI terms, of what the interworking subset 
is.

At present we are nearest to the last of these, except its all in one document.

>                                                                                                        Refer
> to the SMI document used by SNMP.  It starts with the relevant ISO
> specs and states only what the limitations/clarifications are.  It is
> not a discussion; it is not pedagogical.  It is a spec.  your doc
> endeavors to be both spec and teaching tool.  This needs to be separated.

I've just had a careful look through the draft (and discovered a nasty editorial 
- the first "group III" paragraph on page 4 should be deleted). I agree nearly 
all of section 3 is tutorial. 2.4 ought to be phrased in non-implementation 
terms (it really relates to the "migrant" application to OSI infrastructure case). 
I don't think any of the rest of it is discussion or tutorial - it describes which 
application protocols can be carried, the relationship to the base standards, 
the service sequence, the formats and the octets. The requirement to 
interwork with ISO-based implementations means the reader may learn some 
things about the base standards, but the intent is just to state what must be 
sent and what might be received.

(or do we want to move the phrasing of the document to follow that last line 
more closely: this is a specification of what you MUST send and MAY receive 
- and if this becomes a full standard, we just have a migration path for the 
systems that do something else)

> If you detect that I'm turning up the heat, you're right.  Lingering
> fuzziness is almost always a bad thing and I think that it is past time
> to fix my concerns.  I've let things go this long so that I could make
> sure the problem wasn't simply my own ignorance.  I'm now convinced, and
> I don't want to waste any/more or your time or mine.  So let's find a way
> to improve the focus and progress.

Agreed. We must come to a conclusion on this. The above is not my attempt 
at the conclusion, and is probably rather defensive, but I would like to know 
what other people think.

(I've just noticed that the document does say "implementation" rather a lot. 
This may just be a carry-over from OSI style. I think a normal Internet RFC 
would say "host" at most of these points (for an end-to-end protocol), but that 
would be too restrictive in the OSI world. The real thing that ends up doing 
the real work is an implementation.)

Thanks

Peter