[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: definitions versus protocols



At 03:02 PM 5/24/97 GMT, William Allen Simpson wrote:
[snip...]
>As I mentioned, the CAST and RC5 (sharing an author) don't provide
>enough information to write any code.  They just shim between real
>documents.  That's my objection.
>
>I have a strong prejudice for working on code, and therefore have
>principly limited my efforts to code-generating documents.
>
>If these are "algorithm/transform definitions, not protocols", then they
>would not be able to be on the Standards Track.  The IETF standardizes
>protocols, upon demonstrated interoperability.
>
>A shim would be easier to produce, but would only be an Informational RFC.

I disagree. According to RFC2026 (Internet Standards Process), these "shim"
docs fall into the class of Technical Specifications (as opposed to
Applicability Statements), the definition of which follows:

   A Technical Specification is any description of a protocol, service,
   procedure, convention, or format.  It may completely describe all of
   the relevant aspects of its subject, or it may leave one or more
   parameters or options unspecified.  A TS may be completely self-
   contained, or it may incorporate material from other specifications
   by reference to other documents (which might or might not be Internet
   Standards).

   A TS shall include a statement of its scope and the general intent
   for its use (domain of applicability).  Thus, a TS that is inherently
   specific to a particular context shall contain a statement to that
   effect.  However, a TS does not specify requirements for its use
   within the Internet;  these requirements, which depend on the
   particular context in which the TS is incorporated by different
   system configurations, are defined by an Applicability Statement.

They clearly don't have to be "protocols". Perhaps the "shim" specs fall
into the "convention" class. The "shim" specs "incorporates material from
other specs by reference to other documents". From Section 4.1.2 of that
same document, the following definition of the term "interoperable" is
provided:

   For the
   purposes of this section, "interoperable" means to be functionally
   equivalent or interchangeable components of the system or process in
   which they are used.

As for writing code from the "shim" specs, with the following specs in
hand, (1) base ESP draft, (2) RC5 (or CAST) "shim" spec, and (3) detailed
RC5 algorithm spec, I can clearly imagine writing a software module with a
calling sequence that looks something like this:

   ESP_RC5(key, IV, plaintext)

that would return the value of the resulting ciphertext. To do that I would
have to refer to the ESP draft for the padding spec for how to make it pad.
I'd also have to refer to the RC5 spec to code the algorithm. And the
"shim" spec would tell me how to use the key and IV. While no two
implementors would produce the same code, it's clear what the inputs are
and what the outputs need to be from the "shim" spec and thus I would argue
that the to implementors could demonstrate interoperability. )However, I
would suggest that the interoperability in this case would be in the
context of a complete ESP implementation.)

>From the above definitions and the description of Informational (from
RFC2026), I see no reason why the "shim" specs could not be Standards Track
documents.

[snip...]
>> B relating the transform drafts back to the base ESP draft (as you do and
>> the RC5/CAST drafts do), then they DO stand on their own as separable
>> transforms that support the packet formats as defined in ESP. They MUST be
>> read AND used in conjunction with ESP and ONLY in conjunction with ESP. If
>> you REALLY want them to stand on their own in the context of all the
>> working groups, then I would go further to say that they should just
>> describe the algorithms and not refer to any base packet formats. In that
>> way they could be referenced by any base protocol spec such as TLS or ECP
>> by way of IANA numbers. But in my relatively short IETF life, I wouldn't
>> expect to see that happen at this stage and would be grateful to fulfill
>> the intentions of the wg and the ESP draft (and for this purpose, we have
>> the IPSec DOI).
>>
>A very different vision.
>
>I am not in favor of transforms so general that they could be used
>without packet formats.  That's what the algorithm documents (like CAST
>just published as an RFC) should do.  The transforms are specific
>applications of the generic algorithms in concrete form.

I agree that I went further than was practical to make by point. However, I
still believe that the amount of overlap between the "transform"/"shim"
specs and the base ESP specs in your two drafts is excessive and
potentially problematic for implementors and I don't see a problem with the
"shim" approach.

Thanks for your comprehensive responses to my comments. 

I hope that the debate on doc structure does not put yet another
incremental drag on IPSec progress. We've certainly got enough of those. I
strongly encourage/beg-for the wg co-chairs (or the AD if needed) to
provide their guidance/leadership to get the group decision-focused wrt the
littany of seemingly endless obstacles (small and large alike) in front of
the group.

-Bob