Subject: RE: [AAA-WG]: Diameter IETF Standard extensions vs. Vendor extensions

From: <[email-masked]>
Date: Wed, 12 Jun 2002 18:59:02 +0300

Hi Randy,

> a vendor may do whatever they wish.  the point is what they can do and
> still call it diameter.  when they call it diameter, the customer has
> a legitimate expectiation that vendor A's diameter will inter-operate
> with vendor B's diameter.  that is what standards are all about.

I agree.  I propose the following for vendor extensions:

We need a way for vendors to 'register' their extensions, so that there
is some paper trail.  

In the case when a vendor extensions is marked as mandatory, any failures
MUST be the fault of the sending side (the side which sends extension marked
as mandatory).  Also, the system MUST be able to work without the 
non-standard extension.  In summary, all vendor extensions MUST NOT
harm interoperability.

I propose to add this kind of text to 1.2 'Approach to Extensibility' and
to make the text in the IANA section more bullet-proof.  Also, a recommendation
that vendors submit documentation for consideration as Informational RFCs may 
be a good recommendation as well.

John

---

From: Randy Bush <[email-masked]>
Date: Wed, 12 Jun 2002 09:16:54 -0700

> MUST be the fault of the sending side (the side which sends extension
> marked as mandatory).  Also, the system MUST be able to work without the
> non-standard extension.  In summary, all vendor extensions MUST NOT harm
> interoperability.
> 
> to make the text in the IANA section more bullet-proof.  Also, a
> recommendation that vendors submit documentation for consideration as
> Informational RFCs may be a good recommendation as well.

makes sense to me.  or at least i don't think i will have this immediately
splatted in my face if i pass it to the iesg.

randy

---

From: "Glen Zorn" <[email-masked]>
Date: Wed, 12 Jun 2002 09:54:53 -0700

[email-masked] writes:

> non-standard extension.  

Please define the term "work". 

> In summary, all vendor extensions MUST NOT
> harm interoperability.
> 
> recommendation

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 12 Jun 2002 09:52:36 -0700 (PDT)

> > marked as mandatory).

We already have this language for Vendor-Specific AVPs.

But there is no 'M bit' for Vendor-Specific commands. I'm not even clear
this would make sense, except perhaps for accounting, where a
non-mandatory VSC could be interpretted as an ordinary ACR/ACA if the
accounting server did not support it. However, it could be argued that the
same effect could be obtained by just using ACR/ACA and adding some
vendor-specific AVPs, so this probably isn't worthwhile.

> > Also, the system MUST be able to work without the

Some Vendor-Specific AVPs are by their nature mandatory: for example,
anything relating to security. In RADIUS, a NAS can discard a
vendor-specific Filter attribute and deliver a different service than
what the RADIUS server requested without even sending an error message.
But in Diameter we are attempting to do better than that, so such an AVP would be
Vendor-Specific and carry the 'M' bit. That is a good thing, because if
the NAS doesn't implement the AVP, it's preferrable for the session not to
come up, and an error message to result, so the admin can debug it.

For similar reasons, I'm not sure what 'work' means in the context of a
Vendor-Specific Command (VSC). A VSC is only needed in cases where a
standard command with vendor-specific AVPs won't do the job. So if it were
possible to just add some AVPs to the Diameter Server dictionary,
presumably you wouldn't be using a VSC in the first place. That suggests
that a VSC by its nature implies code changes on both the NAS and Diameter
server.

If a NAS or Diameter server receives a VSC and doesn't have the code to
implement it, there really is no way to 'work', except to avoid sending
those VSCs in future.