Subject: [AAA-WG]: Diameter Issues found @ Connectathon

From: Pat Calhoun <[email-masked]>
Date: Fri, 9 Mar 2001 07:15:00 -0800 (PST)

All,

Here are some issues that were found in the protocol during the
interoperability testing that occurred this week. I would suggest that we fix
the protocol but would be interested in hearing any comments.

1) Vendor-Id AVP (Base Protocol)

Someone brought up the fact that the Vendor-Name was changed to Vendor-Id. This
now requires in order to implement Diameter, an enterprise number must be 
received from IANA. This really doesn't make a whole lot of sense, and the
group felt that moving back to Vendor-Name was the correct approach. Further,
the Vendor-Name could also include some "product" information for those vendors
that have many client and server products (e.g. say abc has FAs and NASes, as
well as a server).

2) Result-Code in MRI (Base Protocol)

The Base Protocol defines the Message-Reject-Ind command to include the
Result-Code AVP. This really does violate the protocol, since if the
Result-Code is to be present in the MRI, it should also be present in the DRI
(and all -Ind messages). Therefore, the group agreed that the Result-Code must
not be present in the MRI, and instead be replaced with some other AVP, such
as the Message-Reject-Code AVP (new).

3) DIAMETER_STILL_WORKING (Base Protocol)

The base protocol is not clear about this one, but receiving the above error
does imply that another message will eventually be received with the same
Identifier in the header. This needs to be clarified, since many vendors use
the identifier to match request/responses, and don't expect more than one
message with the same id.

4) Peer State Machine (Base Protocol)

The state machine is still not clear on how to deal with race conditions, and
testing showed that further clarifications are required when a TCP or SCTP
connection is established. My recommendation is that the initiator of the
connection (the one that calls connect()) should be the one that sends the
first DRI. Upon receiving the DRI, the receiver (one that calls listen())
checks whether another connection is in the process of being established, and
if so, it will do an election process. If the identifier in the received
Diameter header is equal or greater than the one it had sent, it will tear
down the other connection. Otherwise, the incoming connection is shutdown. 

So the receiver is always the one that does the election check, and the fact
that the DRIs aren't sent simultaneously on the same connection makes it easier
to make such a check.

5) Unknown Vendor-Specific Commands

The MRI is used to inform a peer that an unknown command code has been 
received. However, if the command code is vendor specific, there is no way
to state this. Therefore, a new AVP, called the Unknown-Vendor-Id needs to
be created to inform a peer of the possible vendor-id/command code combination.
Of course, this AVP only needs to be present if it was a vendor-specific
command code.

6) Treatment of Route-Record (Base Protocol)

An issue arose where a host sent me a packet with the route-record different
from the fqdn that gets resolved via DNS. So when the corresponding response
was received, I would throw the packet away when I determined that I didn't
know how to get to the host in the route-record.

This led to a discussion which resulted in an agreement that the Origin-FQDN
in  the DRI SHOULD be saved by Diameter implementations, since this MUST be
the same  name as the one that would be present in the Route-Record.

Of course, if the Origin-FQDN presented is the same as the one that is
resolved  by DNS, this is not an issue, but the above clarification can really
reduce potential problems in the field (hey, it took me 45 minutes to figure
out what was going on, and I have source code).

So I propose a clarification in the Route-Record AVP that states that the name
in the AVP is the same as the one that was in the Origin-FQDN in the DRI.

7) HAR (MIP)

An issue arose and it was agreed that the Home-Agent AVP MUST be present in
the HAR. The HAR is the message that is sent towards the Home Agent.

8) RADIUS-style MIP Challenge/Response (MIP)

The Mobile IP Challenge/Response I-D supports a RADIUS compatibility mode. In
this mode, the response in constructed in a way that is compatible with
existing RADIUS servers. The problem is that the challenge advertised to the
mobile needs to be known by the AAAH in order to compute the response, and the
challenge is never sent in a Diameter message. So a new Diameter AVP needs to
be created that would encapsulate the Challenge. This would ONLY need to be
done if the MN-AAA authentication extension was created using the RADIUS mode,
and this is known by the FA via the SPI.

9) Authorization-Lifetime in AMR (MIP)

The MIP extension currently requires that the Authorization-Lifetime AVP be
present in the AMR (from the foreign agent). I have no idea why it was done
this way, but I know that many Foreign Agents will be perfectly happy to
receive whatever value they get from the AAAH, so it doesn't make sense for
this AVP to always be present in the message. I would like to recommend that
this AVP become optional in the AMR.

10) Authorization-Lifetime and KEYs (MIP)

Although it really isn't clearly stated, the Authorization-Lifetime and the
session key lifetimes MUST be the same. This clarification is required in the
document.

11) Flags in Diameter header (Base Protocol)

The current (01) I-D states:

	"A Diameter node MUST NOT set these flags in any other combination.
	 A Diameter node receiving a message in which these flags are not
	 set appropriately SHOULD NOT reject the message for this reason,
	 but MAY log the event for diagnosis."

This sort-of implies that it isn't mandatory to set the bits. Some additional
language needs to be added to make it clear that setting these bits is a MUST.

12) HA in visited network

(see e-mail I sent yesterday)

Although NASREQ was tested (well, not the tunneling AVPs), and as well as the
Accounting extension, no issues were found in any of those I-Ds.

Comments appreciated,

PatC

---

From: "David Mitton" <[email-masked]>
Date: Fri, 09 Mar 2001 12:40:40 -0500

>that have many client and server products (e.g. say abc has FAs and NASes, as
...

Two issues:

1) They will need an SMI code if they wish to implement any VSAs 
anyways.  This has not been a problem for RADIUS manufacturers.  More 
importantly they will need an SMI if they are doing any 
MIBs!   Unfortunately, it seems that AAA programmers' don't usually know 
what the SNMP engineers are up to.

2) I would suggest that perhaps the better name for this AVP would be 
Product-ID, and that would remove some of the confusion with the AVP 
Vendor-ID header field.

Dave.
---------------------------------------------------------------
David Mitton                                  ESN: 248-4570
Advisor, Nortel Networks                      978-288-4570 Direct
Wireless Solutions, IP Mobility
Billerica, MA 01821                    [email-masked]

---

From: Patrice Calhoun <[email-masked]>
Date: Fri, 9 Mar 2001 10:38:26 -0800 (PST)

> >interoperability testing that occurred this week. I would suggest that we
> fix >the protocol but would be interested in hearing any comments.
> >
> >group felt that moving back to Vendor-Name was the correct approach.
> Further, >the Vendor-Name could also include some "product" information for
> those  >vendors
> >that have many client and server products (e.g. say abc has FAs and NASes,
> as >well as a server).
> ...
> 
> Two issues:
> 

Right, but a manufacturer that wants to only sell servers, or perhaps doesn't
want VSAs, shouldn't need an SMI code simply to implement the protocol, right?

> Product-ID, and that would remove some of the confusion with the AVP 

ok.

PatC

---

From: David Spence <[email-masked]>
Date: Mon, 12 Mar 2001 11:24:43 -0500

> that have many client and server products (e.g. say abc has FAs and NASes, as

I like Vendor-ID.  It is not hard to apply for one.  And you need one anyway
to insert in the Vendor-ID field of the AVP header.  If you use an
unregistered, free-format identifier in a Vendor-Name AVP and a different,
registered, fixed-format identifier in the Vendor-ID field of the AVP
headers, how am I supposed to match them?  Keep it consistent throughout. 
Use the IANA-registered enterprise numbers.

-- 
David Spence                            email: [email-masked]
Interlink Networks, Inc.                phone: (734) 821-1203
775 Technology Drive, Suite 200         fax:   (734) 821-1235
Ann Arbor, MI 48108           
U.S.A.

---

From: David Spence <[email-masked]>
Date: Mon, 12 Mar 2001 11:33:07 -0500

> want VSAs, shouldn't need an SMI code simply to implement the protocol, right?

So make the Vendor-ID AVP optional.  Only include it if there are
vendor-specific AVPs or command codes that the equipment understands or may
send.  Otherwise it doesn't matter.

---

From: Pat Calhoun <[email-masked]>
Date: Mon, 12 Mar 2001 08:38:19 -0800 (PST)

> to insert in the Vendor-ID field of the AVP header.  

Only if you plan to send vendor-specific AVPs, and I would claim that there
are plenty of RADIUS implementations that support RFC-only attributes. So
requiring that one gets an SMI seems unnecessary.

> If you use an
> headers, how am I supposed to match them?

Why would you need to match them? You cannot really use the Vendor-Id in the
DRI to know what vendor-specific AVPs are supported, since an implementation
may in fact support many vendor-specific AVPs from many different vendors.

>  Keep it consistent throughout. 

Consistency is good, but only if used for the same purpose. The intent of the
vendor-id in the DRI is only to know the manufacturer of the implementation or
device, nothing else.

> send.  Otherwise it doesn't matter.

ok, so if I understand correctly, in the DRI the Vendor-Name represents the
name of the manufacturer, and the vendor-id would state which manufacturer's
vendor-specific AVPs are supported. Is this correct?

PatC

---

From: David Spence <[email-masked]>
Date: Mon, 12 Mar 2001 12:20:00 -0500

I guess I was assuming that the purpose for putting vendor information in
the DRI was to allow a Diameter peer to signal which vendor specific AVPs
and command codes it understands.  Of course I could configure that in my
"Clients file", but in that case I could configure the manufacturer's name
too.  I certainly don't mind a text Vendor-Name AVP that could be used for
logging purposes, but I think it might be useful to send zero or more
Vendor-Id AVPs to indicate the enterprise numbers of the supported
vendor-specific protocol elements as well.

---

From: Pat Calhoun <[email-masked]>
Date: Mon, 12 Mar 2001 09:19:54 -0800 (PST)

> and command codes it understands.

I just read section 6.1.1 in the base, and you are correct in your assumption.
I somehow missed that one. When I eliminated the Vendor-Name AVP, I guess I
thought it would make sense to add vendor-ids in the capabilities negotiation
phase of the DRI.

Of course, having the vendor-id be used for both capabilities discovery AND to
recognize the vendor of the peer doesn't work.

>  Of course I could configure that in my
> too. 

Less configuration == better protocol.

> I certainly don't mind a text Vendor-Name AVP that could be used for

OK, so it sounds like both are needed.

Any objections?

PatC

---

From: "Mark Jones" <[email-masked]>
Date: Mon, 12 Mar 2001 14:54:02 -0500

I would like to see the Vendor-ID stay as a required AVP in the DRI to
indicate the vendor of the peer. There have been many times when debugging
RADIUS problems that it would have been invaluable to know the identity of
the client/server. As David mentioned, it really is no big deal to obtain an
enterprise number for this purpose.

However even with the Vendor-ID and Firmware-ID AVPs in the DRI, I still
feel we're missing a product name AVP to complete the identification. The
presence of this AVP would be mandatory if the peer is not fully identified
by the Vendor-ID and Firmware-ID.

I did not understand from the DRI description in the draft how adding a
Vendor-ID AVP to this message indicates the vendor-specific capabilities of
the peer. Wouldn't one also need to add a list of supported vendor-specific
command and AVP codes?

Regards,
       Mark

---

From: Pat Calhoun <[email-masked]>
Date: Mon, 12 Mar 2001 12:48:19 -0800 (PST)

> by the Vendor-ID and Firmware-ID.

looks like we've come full circle, but I will restate my position just in case
you missed it.

The Vendor-Name should be put back in the protocol, and it is a string. It
contains whatever you want (e.g. "Pat Calhoun's Network Access Server and Fish
Fryer, oh and it includes Diameter"), and the Firmware Revision 1.0 (do you
really see a need for a second version of such a product :).

So what you've asked for is there in my proposal to put Vendor-Name back in
(oh, and it reduces the round trip time from implementor to IANA down to zero).
> the peer. Wouldn't one also need to add a list of supported vendor-specific

The basic idea was that the Vendor-Id would be used to identify which
vendor-specific AVPs could be supported, but you have a point that this may be
pointless without knowing in advance *which* AVPs are supported. Therefore,
perhaps the Vendor-Id in the DRI doesn't make a whole lot of sense.

PatC

---

From: "Mark Jones" <[email-masked]>
Date: Mon, 12 Mar 2001 18:14:09 -0500

Pat,

> really see a need for a second version of such a product :).

Thanks for the explanation. I had misunderstood your intended use of the
Vendor-Name AVP. So the Vendor-Name AVP would be mandatory in the DRI
message and should contain the vendor name ("Pat Calhoun") and the vendor's
name for the product ("Network Access Server and Fish Fryer"). Is that
correct? This would certainly meet my debugging aid requirement but I think
changing the AVP name to Vendor-Product-Name would give a strong hint that
it is expected to contain more than just the vendor name.

> perhaps the Vendor-Id in the DRI doesn't make a whole lot of sense.

Keeping this AVP does allow a Diameter server to check whether it even has a
dictionary for that vendor and if not, return a Message-Reject-Ind
containing the unsupported Vendor-Id. This also allows for a limited form of
capabilities negotiation in that devices could offer the same service with
vendor-specific bells and whistles or the vanilla version as documented in
the extension RFC depending on what the peer supported.

Regards,
       Mark

---

From: Pat Calhoun <[email-masked]>
Date: Mon, 12 Mar 2001 16:22:42 -0800 (PST)

> correct? 

The vendor name was a string, and could contain whatever the developer wanted.
It could be as simple as "Pat Calhoun", and could be as complex as the example
I had provided. I would hope that developers that had many products would be
smart enough to include qualifying strings...

> This would certainly meet my debugging aid requirement but I think

.... but of course, this would be even better. So the contents wouldn't be any
different, but the AVP name makes it sounds like it should contain more. Of
course, now I could argue that the AVP name you proposed wouldn't include the
vendor's name, but just the product name, and we'd be back to square one.

Another method is to add clarifying text to Vendor-Name, to make it clear it
could contain whatever they wanted.

ok.

PatC

---

From: "Fredrik Johansson" <[email-masked]>
Date: Tue, 13 Mar 2001 00:37:29 +0100

Pat,

I beleive that we agreed on having the Home-Agent AVP mandatory in the AMA
not the HAR (hopefully the HA will know its own address), but the diameter
client in the FA should not be forced to parse the registration reply but
should be able to find the HA address in the AMA.

/Fredrik

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]]On
>Behalf Of Pat Calhoun
>Sent: den 9 mars 2001 16:15
>To: [email-masked]; [email-masked]
>Cc: [email-masked]
>Subject: [diameter] Diameter Issues found @ Connectathon
>
>
>All,
>

---

From: Pat Calhoun <[email-masked]>
Date: Mon, 12 Mar 2001 16:56:47 -0800 (PST)

> should be able to find the HA address in the AMA.

Agreed about the AMA, but it must also be in the HAR in cases where the HAR is
proxied (say in a visited network).

PatC

---

From: Paul Funk <[email-masked]>
Date: Tue, 13 Mar 2001 11:15:42 -0500

I agree that the name of the AVP should be Product-ID (or possibly 
Product-Name, which is more suggestive of a text value). 

I'm not sure if the preceding discussion was clear enough as to the 
content of this AVP. My suggestion is that the content of the AVP be 
the product name itself, and that it be understood in conjunction with 
Firmware-Revision; that is, Firmware-Revision is the version number of 
the product named in Product-ID. The Product-ID could contain the 
manufacturer's name, not alone but as a brand modifier, e.g., "Toyota 
Corolla". 

The combination of Product-ID and Firmware-Revision is a definitive 
indication of what AVPs a Diameter peer supports. Granted this must 
be configured in advance. But exchanging Vendor-IDs is not an 
adequate means of discovering capabilities, since a vendor can define 
a new AVP without adding ot to all devices it manufactures, nor does 
equipment in the field magically get upgraded when new AVPs appear.

Paul

>> Product-ID, and that would remove some of the confusion with the AVP 

Paul Funk
Funk Software, Inc.
617 497-6339
[email-masked]

---

From: David Spence <[email-masked]>
Date: Tue, 13 Mar 2001 17:41:04 -0500

I like the Vendor-Product-Name AVP as discussed in this thread.  I also urge
inclusion of a Vendor-ID AVP that could appear in a DRI message zero or more
times to indicate at least partial support for vendor specific AVPs and
Command Codes.  But I guess we do need to agree on how it would work.

My idea would be that it would indicate Vendor-IDs that I support, not
Vendor-IDs I expect my peer to support.  So there would be no need to
respond to a DRI with an MRI whenever I don't support some of your
Vendor-IDs.  It would merely be a hint at the sender's capabilities.  So if
I include a Vendor-ID AVP in my DRI for Vendor X, it means that I have
included (at least some of) Vendor X's AVPs in my dictionary and may know
how to process them.  If later you send me a Vendor X Foobar AVP with the M
bit set and I don't happen to support the Foobar AVP, then I would have to
reject the message.  If the M bit is not set and I don't support the Foobar
AVP then I may ignore it.  But at least it would be worthwhile for you to
include Vendor X AVPs in the the messages you send me.  If I do not include
a Vendor-ID AVP in my DRI that advertises support for Vendor-X, then you
have a very high degree of assurance that I will not understand Vendor X
AVPs and if you have any degraded way of mapping Vendor X AVPs to standard
AVPs you should really do it.

In our RADIUS server, we have a vendor ID item in our "RADIUS Clients"
configuration file.  The server uses it to decide whether to include
vendor-specific attributes in messages sent to the client.  We don't go so
far as to configure lists of supported vendor-specific attributes for each
RADIUS client (although you can do that on a server-wide basis), yet the
per-client configuration feature we do provide seems to be useful. 
Including the information in the DRI message would be even better because it
makes one less thing for the network administrator to have to configure. 
One could still include a configuration item to override or augment the DRI
information for a particular client.

Therefore, my recommendation is to provide a simple capability (Vendor-IDs
that I mostly support) in the DRI but not worry about complexities such as:
here is a list of all the command codes I support and which AVPs I allow and
require for each command code and under what circumstances ad infinitum.  In
short, I think a simple, numeric Vendor-ID AVP would be useful and further
complexities probably unwarranted.

---

From: "Mark Jones" <[email-masked]>
Date: Tue, 20 Mar 2001 17:34:31 -0500

I have been giving the implementation of the DRI some further thought and
have a few comments and questions.

I think the communication of a device reboot event should be decoupled from
the identity/capability exchange since the establishment of the transport
connection does not necessarily imply a reboot of either peer. For example,
a routing proxy may wait until it has a command destined for a particular
Diameter peer before establishing a connection. New event types in the
Device-Status-Indicator command should be used to communicate the device
reboot events instead. If this proposal is accepted, I suggest renaming the
Device-Reboot-Indicator command to Device-Capability-Indicator.

Command names aside, I understand that the capabilities of a Diameter peer
are unlikely to be fully described by the list of extension ids that it
supports. The receiver of the DRI also needs to be aware of the
vendor-specific AVPs and commands supported by the peer and I agree that we
should not attempt to communicate this in the DRI. It follows that this
capability set must already be known by the receiver in order for any
vendor-specific AVPs/commands to be exchanged. In other words, the receiver
must know that firmware revision [x] running on product [y] from device
vendor [z] supports a given set of extensions and/or vendor-specific
AVPs/commands. Hence, the DRI should contain these device identity AVPs in a
machine-friendly format in order for the peer to lookup the device's
capability set. I think this requirement would be better served by three
separate AVPs (Firmware-Revision/Product-Id/Vendor-Id) than the free-format
Vendor-Product-Name AVP that was proposed for debugging purposes.

Does the inclusion of an extension id in the DRI imply that the device
supports the functionality described in the extension using only the
commands and attributes defined in the extension, i.e. without addition of
any mandatory vendor-specific commands/attributes? Would it be valid for a
device claiming support for the Mobile-IP extension to discard an AMA
command because it was missing a vendor-specific AVP that the device's
vendor considered mandatory?

Regards,
       Mark

---

From: "Mark Jones" <[email-masked]>
Date: Tue, 20 Mar 2001 20:33:06 -0500

> Whatcha think of that?

I agree that works great for extensions produced by WGs but I'm concerned
about the vendor-specific AVPs and commands. If a vendor comes up with a
slight variant on mobile IP registration which includes a few additional
vendor-specific AVPs, I just can not see them publishing a new extension
document for it. From my RADIUS experience, they will simply add the AVPs to
the dictionary for their Diameter server (and maybe to their device
documentation if we're lucky). Some vendor's even treat their RADIUS VSAs as
proprietary information available solely under NDA! My proposal comes out of
a reluctant acceptance that the same thing will happen with Diameter and at
least the base protocol could provide a means of discovering the identity of
the device.

Adding the list of supported extension ids to the DRI is useful only if
"supports" means the device implements the functionality described in the
extension using only the commands and attributes defined in the extension,
i.e. without addition of any mandatory vendor-specific AVPs/commands. The
extensions then become a useful baseline ensuring interoperability amongst
devices from different vendors. I do not remember seeing confirmation of
this in the Diameter drafts but I may have missed it.

I'm lukewarm on the idea of adding a list of the supported vendor ids to the
DRI. On one hand, it does allow the Diameter server to check whether it has
a dictionary for that vendor. On the other, the server still has no idea if
it has the latest dictionary for that vendor so it still risks receiving
unknown VSA. What is your opinion?

Regards,
       Mark

---

From: "Mark Jones" <[email-masked]>
Date: Wed, 21 Mar 2001 13:21:32 -0500

> Well, vendor specific AVPs are ignored by applications/servers that do not
> know how to handle them.  (Unless, of course, the M bit is set.  Then, an
> error (MRI) would be returned).
>
> So, Vendor attributes are currently supported exactly like in
> RADIUS.  In fact,
> you can send any extra AVPs you want, and if they are not
> supported/expected,
> they will just be ignored.
>

The approach of ignoring unknown VSAs is (mostly) harmless but it frequently
results in a failure to setup the desired service for the subscriber. When
the finger pointing stops, the result will be that the Diameter server
dictionary gets updated with the AVPs whether they were published in an
extension or not.

> But, a server can *also* advertise that it knows how to handle specific
> vendor AVPs, or optional AVPs by documentint those AVPs in an
> extension, and
> then advertising that the extension is supported.
>
> So, I still think that my preposal handles both cases.

Don't get me wrong; I think extension ids in the DRI are an excellent idea.
I am certainly not arguing for their removal or replacement by vendor ids.
But if I understand your proposal correctly, vendors MUST publish the
extensions documenting their vendor-specific AVPs/commands. If they do not
then their vendor-specific AVPs/commands will simply be ignored by Diameter
servers. This sounds like a recipe for a Diameter device only working
predictably with a Diameter server if they are both provided by the same
vendor. I just don't see the motivation for a vendor to publish their
extensions especially if they are also pushing their own Diameter server.

The intent of my original email was to stress the importance of the devices
identifying themselves (Vendor/Product/Firmware) in the DRI. Although this
does not solve the problem, it at least gives third-party Diameter server
vendors a chance at interoperability because they can build a knowledge base
of the vendor-specific quirks of the devices.

> Adding a list of vendor ids or supported AVPs to a DRI is very
> ugly, in my
> opinion.  That's why I'm pushing registering extensions so that several
> commands/avps/whatever can be supported with only one addition to the DRI.
>

I agree that value of the supported vendor ids in the DRI is pretty limited
and adding supported AVPs/commands is way too verbose.

BTW, I've seen no reaction to my email on the WG mailing lists. Even if I
was deemed totally out-to-lunch, somebody is usually kind enough to tell me
why. I was unable to attend IETF50 so was there some DRI decision taken down
there that would invalidate this discussion? I assume you are in attendence.

Regards,
       Mark

---

From: David Frascone <[email-masked]>
Date: Tue, 20 Mar 2001 17:20:56 -0600

I agree that there needs to be a mechanism to exchange what AVPs might be 
supported, but I disagree with your method.  

I would prefer to allow extensions to not only specify AVPs in new command
codes, but also specify new sets of AVPs for extensions.

For example, extension 123 could be a list of 5 AVPs that some application 
needs supported with existing command codes defined in the base protocol or
other extensions drafts.

So, in my opinion, the current protocol could easily support mandating the 
support of particular AVPs, by loosening the definition of "extension" to 
handle arbitrary AVPs.

Whatcha think of that?

---

From: David Frascone <[email-masked]>
Date: Wed, 21 Mar 2001 10:46:42 -0600

So, Vendor attributes are currently supported exactly like in RADIUS.  In fact,
you can send any extra AVPs you want, and if they are not supported/expected,
they will just be ignored.

But, a server can *also* advertise that it knows how to handle specific 
vendor AVPs, or optional AVPs by documentint those AVPs in an extension, and
then advertising that the extension is supported.

> unknown VSA. What is your opinion?

Adding a list of vendor ids or supported AVPs to a DRI is very ugly, in my 
opinion.  That's why I'm pushing registering extensions so that several
commands/avps/whatever can be supported with only one addition to the DRI.

-Dave

---

From: Patrice Calhoun <[email-masked]>
Date: Fri, 30 Mar 2001 09:32:43 -0800 (PST)

Again, sorry for the latency.

[command code renaming discussing deleted - I think it's a little late for
this now, but I will let the WG decide]

> any mandatory vendor-specific commands/attributes? 

yes

> Would it be valid for a

If a vendor wishes to do the above, then they will not interoperate with
anyone, and may see limited market penetration. I don't think that the specs
have anything to say about broken implementations.

PatC

---

From: Patrice Calhoun <[email-masked]>
Date: Fri, 30 Mar 2001 09:52:21 -0800 (PST)

> Agreed about the AMA, but it must also be in the HAR in cases where the HAR
> is proxied (say in a visited network).

I was trying to make this change, but I am not sure that making the Home-Agent
AVP mandatory makes sense, since the AMA may indicate a failure, possibly by
the AAAH, in which case there was never a Home Agent involved in the
transaction.

Therefore, I propose adding the following sentence to the AMA command code
text:

" A successful AMA message MUST include the MIP-Home-Agent-Address AVP."

PatC

---

From: "Mark Jones" <[email-masked]>
Date: Fri, 30 Mar 2001 17:29:15 -0500

> this now, but I will let the WG decide]

I should have spotted this earlier but I honestly thought the
Device-Reboot-Indication was only sent on device reboot until I re-read the
description much later. The proposal was to rename the
Device-Reboot-Indication command to Device-Capability-Indication since the
command is sent on session establishment and not necessarily device reboot.

> > any mandatory vendor-specific commands/attributes?

It seems obvious to me too but I see a loophole in the current drafts since
the command specification in the extension documents contain "* [ AVP ]" to
indicate that any other AVP may be present (including a mandatory
vendor-specific AVP). I dislike conformance battles with other vendors so
how about adding the following text to the Extension-Id AVP description to
keep us honest:

"A Diameter peer that includes an Extension-Id AVP in the DRI SHALL support
the functionality described in the associated extension using only the
commands defined in the extension and without the addition of mandatory
vendor-specific AVPs."

Too severe? This text may ensure that Diameters peers never receive a DRI
with an Extension-Id AVP :)

Regards,
       Mark

---

From: "Fredrik Johansson" <[email-masked]>
Date: Sat, 31 Mar 2001 12:25:31 +0200

That will do,

/Fredrik

>From: Patrice Calhoun [mailto:[email-masked]]
>Sent: den 30 mars 2001 19:52
>To: Pat Calhoun
>Cc: Fredrik Johansson; [email-masked]; [email-masked];
>[email-masked]
>Subject: RE: [diameter] Diameter Issues found @ Connectathon
>
>