Subject: Re: complex extensions attacking IETF protocols

From: "Bernard Aboba" <[email-masked]>
Date: Wed, 4 Nov 1998 09:42:26 -0800

>
>Brian E Carpenter writes:
>> Let me ask an operational question: are there any specific changes
>> we should make to RFC 2026 that would make the IETF more resistant to
>> the type of manipulation people have been hypothesising?
>

Here are some thoughts:

1. I think we need to pay more attention to the IANA considerations section
of proposals. Many of the worst abuses of the process occur in misuse
of number spaces, including attribute/message numbers, "domains of
interpretation",
vendor-specific extensions, etc. It is probably worthwhile to consider
requiring
an IANA considerations section be present earlier on in document
development,
and reducing the time period in which a non-IANA entity is in control of
such
number spaces. Presently, the transition may occur well after a document
reaches
proposed standard status, but I think that is often too late. The IANA
process,
while not perfect, does require disclosure of intent before granting use of
a number.
This has the effect of throwing light on an activity.

2. Particular care needs to be taken in preventing a document already at
proposed
standard from being used for a different purpose than the one for which it
was
developed, without explicit consideration of the new intended use.  I would
even
go so far as to suggest that new intended uses for existing proposed
standard protocols
should require formation of a new WG to define the scope of the new use. At
the
very least, the new use should be described in a document, and if not
deserving
of proposed status on its own, should be classified as experimental or
informational.

---

From: Thomas Narten <[email-masked]>
Date: Wed, 04 Nov 1998 14:29:07 -0500

"Bernard Aboba" <[email-masked]> writes:

> 1. I think we need to pay more attention to the IANA considerations
> section of proposals. Many of the worst abuses of the process occur
> in misuse of number spaces, including attribute/message numbers,
> "domains of interpretation", vendor-specific extensions, etc. It is
> probably worthwhile to consider requiring an IANA considerations
> section be present earlier on in document development, and reducing
> the time period in which a non-IANA entity is in control of such
> number spaces. Presently, the transition may occur well after a
> document reaches proposed standard status, but I think that is often
> too late. The IANA process, while not perfect, does require
> disclosure of intent before granting use of a number.  This has the
> effect of throwing light on an activity.

I believe that the issue you raise has already been addressed. There
is now a BCP RFC on this topic (RFC 2434 issued just last
month). Furthermore, the IESG has in practice for quite some time been
requiring that all documents include an IANA Considerations section
where appropriate.

> 2. Particular care needs to be taken in preventing a document
> already at proposed standard from being used for a different purpose
> than the one for which it was developed, without explicit
> consideration of the new intended use.  I would even go so far as to
> suggest that new intended uses for existing proposed standard
> protocols should require formation of a new WG to define the scope
> of the new use. At the very least, the new use should be described
> in a document, and if not deserving of proposed status on its own,
> should be classified as experimental or informational.

This is a much harder nut to crack. Once a protocol is documented in
an RFC (or any permanent place for that matter) and implemented, it in
some sense becomes tool for performing useful actions. Preventing
folks from using tools (e.g., hammers) for dealing with problems other
those for which the tool was designed (e.g., pounding nails) is
something folks have been grappling with for a long time.

Thomas

---

From: Thomas Narten <[email-masked]>
Date: Wed, 04 Nov 1998 14:29:07 -0500

Thomas