Subject: Re: complex extensions attacking IETF protocols

From: "Bernard Aboba" <[email-masked]>
Date: Wed, 4 Nov 1998 23:02:24 -0800

>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).

Quoting from the RFC:

   "Designated experts.... are typically named at the time a document that
    creates a new numbering space is published as an RFC"

I think the issue here is that it may be necessary to require independent
review of name space allocation *prior* to publication as an RFC. From
what I can tell, there is no requirement that an IANA considerations section
be included early in the discussion process. This means
that it is possible for a document to reach Proposed Standards status
before control over the name space is ceded, and the name space
ownership becomes public knowledge. I for one would like to see an
IANA considerations section, as well as disclosure of name space usage,
included in documents advanced along the standards track. This would
make the scope of the protocol more explicit, making it more difficult to
produce "iceberg" documents which on the surface look like interoperable
protocols while carrying a hidden payload of private extensions.

---

From: "Ralph E. Droms" <[email-masked]>
Date: Fri, 6 Nov 1998 06:43:30 -0500 (EST)

On Wed, 4 Nov 1998, Bernard Aboba wrote:
> review of name space allocation *prior* to publication as an RFC.

That review will be provided by WG members and WG chairs.  As the
development of documented guidelines for IANA considerations raises
everyone's awareness of the issue, it will (or should, anyway) become less
likely that de facto name space allocation will take place prior to formal
review and publication as an RFC.

Even with this heightened awareness, it will still be possible for vendors
who choose not to work within the IETF standards processes to present de
facto standards that are already instantiated in shipping products.  But
that problem extends beyond the IANA allocation process to the entire IETF
protocol development and standardization process.

- Ralph

---

From: "Ralph E. Droms" <[email-masked]>
Date: Fri, 6 Nov 1998 06:43:30 -0500 (EST)

- Ralph

---

From: Thomas Narten <[email-masked]>
Date: Fri, 06 Nov 1998 08:02:47 -0500

> review of name space allocation *prior* to publication as an RFC.

That is really what the intent is, and what is happening in practice
now. Ideally, WGs would address name space allocation issues early on
in the design process. In practice, this doesn't always
happen. Looking at the above requirement in a literal sense, the IESG
during its normal review process sends documents that lack an
appropriate IANA considerations section back to the
WG/authors. Documents are not published as RFCs until the IANA
Considerations issues have been dealt with satisfactorily. Note that
this has only been going on for a year or so, so there are plenty of
existing RFCs that haven't done this. But all new RFCs are
scrutinized, including those that are reissued versions of older
documents.

> From what I can tell, there is no requirement that an IANA
> considerations section be included early in the discussion
> process. This means that it is possible for a document to reach
> Proposed Standards status before control over the name space is
> ceded, and the name space ownership becomes public knowledge.

If I understand you correctly, your concern is that the draft at issue
could already have inappropriately carved up a name space before the
document is published as an RFC for the first time? If that is an
issue, folks *should* be raising specific objections during the Last
Call, when all this stuff should already be documented.

> I for one would like to see an IANA considerations section, as well
> as disclosure of name space usage, included in documents advanced
> along the standards track.

This should be taking place now. I'd be interested in hearing of
specific examples to the contrary.

Thomas

---

From: Thomas Narten <[email-masked]>
Date: Fri, 06 Nov 1998 08:02:47 -0500

Thomas