Subject: [AAA-WG]: Request for IETF last call on Diameter-11 and Transport-07 drafts

From: Bernard Aboba <[email-masked]>
Date: Sat, 8 Jun 2002 18:16:40 -0700 (PDT)

The AAA WG has completed WG last call on the Diameter Base-10 and
Transport-07 documents. As a result of WG last call comments, no
changes were made to the Transport document, and 20 changes were
made to the Diameter Base document, with 5 comments rejected.

Based on this, the AAA WG recommends that the IESG initiate IETF last call
on the following documents, followed by consideration as IETF Proposed
Standards:

http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-11.txt
http://www.ietf.org/internet-drafts/draft-ietf-aaa-transport-07.txt

Comments received during this and previous AAA WG last calls (and their
resolution) are available for inspection at:

http://www.drizzle.com/~aboba/AAA/issues.html

This includes issues previously raised by the IESG, including Issues #268,
269 and 342.

---

From: Randy Bush <[email-masked]>
Date: Sat, 08 Jun 2002 21:32:47 -0700

> made to the Diameter Base document, with 5 comments rejected.

as ad, i will not be passing this to the iesg for review.  there
is one comment that has not been addressed by -11, vendor-specific
commands.  as i have repeatedly said, if i was to pass this to the
iesg, it is a sure show-stopper.

rather than saying it all over again, can folk please review the
mailing list archive on this.  essentially, the iesg has a hot-
button about mandatory vendor commands.

randy

---

From: Ignacio Goyret <[email-masked]>
Date: Mon, 10 Jun 2002 12:30:03 -0700

>button about mandatory vendor commands.

If that is true, it seems to me the IESG needs to get a big dose of
reality check. A fact of life is that the IETF and just about every
other standard body moves ever so slowly that vendors are forced
to add vendor specific extensions to satisfy their clients. Often,
those extensions become de-facto "standards".

Now, would you prefer those extension mechanisms to be ad-hoc, where
interoperability will probably be an issue or would you prefer that
vendor extension mechanisms be defined up front in a way that guarantees
interoperability?

---

From: David Frascone <[email-masked]>
Date: Mon, 10 Jun 2002 14:37:43 -0500

Perhaps I'm missing something here, so feel free to shoot me down, but the
key word I saw in that paragraph was "mandatory"

I understood his objection to mean that the Diameter protocol could now have
vendor specific commands that were mandatory to support.  Which, seemed 
like a no-brainer to me.

But, then again, perhaps I'm confused :)

-- 
David Frascone

     Programmers don't die, they just GOSUB without RETURN.

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 10 Jun 2002 12:29:52 -0700 (PDT)

> I understood his objection to mean that the Diameter protocol could not
> have vendor specific commands that were mandatory to support.  Which,
> seemed like a no-brainer to me.
>

I think that the question relates to how vendors can extend Diameter while
still retaining the ability to fall back to standardized capabilities if
one of the peers does not support the extension.

This is already possible with Vendor-Specific non-mandatory AVPs. If a
peer doesn't understand these, then they can ignore them. For mandatory
Vendor-Specific AVPs, an error results if the peer does not support them,
but the fault lies with the VSA sender.

Vendor-Specific Commands in Base-11 are mandatory, so a capabilities
negotiation cannot conclude successfully if one of the peers does not
support the VSC.

That's part of the reason why Diameter-11 indicates that VSCs are a last
resort. Interoperability will always be better when standardized commands
are reused with Vendor-Specific AVPs than when the same functionality is
implemented with vendor-specific commands.

The question is whether there is a way to avoid negotiation failure with
VSCs. For example, would it be possible to fall back from a VSC to use of
standardized commands, perhaps with Vendor-Specific AVPs?

---

From: "Glen Zorn" <[email-masked]>
Date: Mon, 10 Jun 2002 17:01:48 -0700

> vendor specific commands that were mandatory to support.  Which, seemed

Sure, but I can't find anything in the draft that says that support for
vendor-specific commands is recommended, let alone mandatory.

> But, then again, perhaps I'm confused :)

You and me, too.

---

From: "Glen Zorn" <[email-masked]>
Date: Thu, 27 Jun 2002 14:52:54 -0700

Some time ago, Randy Bush [mailto://[email-masked]] wrote:

> mailing list archive on this.

The archives are available again, so I attempted to review them.  However,
it appears that the archives are incomplete: I couldn't find a single
message in them on this topic from any IESG member.

> essentially, the iesg has a hot-

Given the above, I (and perhaps the rest of the WG) would _really_
appreciate it if you (or anyone else on the IESG) would take the time to
explain 1) where in the current document mandatory vendor commands are
specified and 2) how the mechanisms in the current protocol are dangerous to
interoperability.  It would be _extra_ wonderful if this explanation had
some technical qualities (as opposed to hot flashes) and evinced that the
explainer had actually read the document in question.