FWD: Re: draft-iesg-vendor-extensions-00.txt

[Thomas Narten <narten@us.ibm.com>]

------- Forwarded Message

From: Bernard Aboba <aboba@internaut.com>
To: Thomas Narten <narten@us.ibm.com>
Date: Mon, 6 Jan 2003 21:11:00 -0800 (PST)
Subject: Re: draft-iesg-vendor-extensions-00.txt

The AAA WG is probably not the best place to get a fair hearing, although
if you're looking to fill out your list of types of extensions, we can
probably help :)

To paraphrase Casey Stengel: "I've been in this game a hundred years,
and my WG comes up with new ways to break interoperability that I didn't
even knew existed".

Some comments:

I like the distinction relating to minor extensions that carry extensions
as opaque data. However, I would like more examples:

a. Do Diameter vendor-specific attributes qualify? If they have the 'M'
bit set? If they don't have the 'M' bit set?

b. Do RADIUS vendor-specific attributes qualify? These are always ignored
if they aren't understood.

c. Do LDAP schema extensions qualify?

d. What about L2TP extensions?

Is the key destinction whether they can be ignored if not understood?


"   Major extensions should be well, and publicly, documented and checked
   by the IETF community to be sure that the extension does not defeat
   safeguards designed into the protocol, such as security functions, or
   undermine its architectural integrity."

This is good in theory -- but I worry about how we will carry this out.
As you mention later, this requires careful thinking in the IANA
considerations as to how extensions are to be reviewed, and I wonder how
many documents really do this thinking -- or whether we have the people
and process to get it done once the WG is completed. This is perhaps
something that the directorates -- the pool of potential designated
experts -- could help with.

Section 3

"
    o All major extensions to IETF protocols should be done with direct
      involvement of the IETF.

    o The decision on whether an extension is major or minor should be
      done with the direct involvement of the IETF."

The second bullet seems reasonable, but I'm not so sure about the first.
3GPP and 3GPP2 are continually coming to us with lists of things they want
us to do for them. Is it ever ok to say no, or is there a process by which
they can do the work but have it reviewed or supervised by the IETF after
the fact? The problem is that even if we think that the work items make
sense, they often don't come with committed resources attached so that
they're likely to become yet another half-completed work item within a WG
that already has its share. So we may want to say no even if we feel that
the work should be done in IETF. What happens then?

For example, we just got a new request from 3GPP2 to do Diameter MIPv6 as
a new mechanism for IPsec dynamic keying. Given that we're still
struggling to figure out how to salvage MIPv4/AAA keys and Diameter
MIPv4, can we say "please go have this baby in a darkened room somewhere
and never bring it to church on Sunday"? Or do we have to adopt it and bring
it home to live with us? Remember that a response of "please don't do
this" is typically taken as seriously as adolescents take Teen Abstinence.

What if the SDOs don't listen? What do we do then? For example, IEEE
802.11f "extended" RADIUS recently with some IEEE vendor-specific
attributes (opaque data, so perhaps we can look the other way) as well as
re-interpretting the use of existing attributes (changing the nature of
the protocol, not OK). The solution to this is more likely to be an
improved liason process, rather than a dictate in an RFC. Remember, we're
talking more about relationships between sovereign nations here, rather
than relations between the federal government and the states.





On Mon, 6 Jan 2003, Thomas Narten wrote:

> Dunno if you've seen this yet, but we finally got some thoughts
> written down on the subject.
>
> Note sure where the best place to discuss it is. ietf list maybe? No
> place seems ideal. aaa list? :-)
>
> Thomas
>

------- End of Forwarded Message