[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Re: draft-iesg-vendor-extensions-00.txt
Formally this I-D has expired.
Are we planning any more work on this?
Are we planning on an IESG statement instead?
The question on vendor-extensions is coming up in NetConf,
and if I have something I can point them to, that would be great
If we do not complete and get to conclusion/consensus on the
serious issues we discuss in IESG, then it is kind of tough
to get a consistent message out to the community.
Thanks,
Bert
> -----Original Message-----
> From: Thomas Narten [mailto:narten@us.ibm.com]
> Sent: woensdag 8 januari 2003 18:23
> To: iesg@ietf.org
> Subject: FWD: Re: draft-iesg-vendor-extensions-00.txt
>
>
> ------- 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
>