Subject: [AAA-WG]: Issue 97

From: Pat Calhoun <[email-masked]>
Date: Thu, 2 Aug 2001 15:20:46 -0700

All,

Issue 97 recommends that an approach be adopted that allows for the
path to a home server be static for a given session. The proposal is
to introduce a new AVP, but I believe that the Source-Route AVP would
work just as well.

Do folks disagree with this feature?

My personal inclination is not to adopt it, but of course I will listen
to WG consensus.

PatC

---

From: "Kevin Purser" <[email-masked]>
Date: Thu, 2 Aug 2001 16:45:08 -0700

Inconsistencies in NASREQ AVP tables
Submitter name: Kevin Purser
Submitter email address: [email-masked]
Date first submitted: August 2, 2001
Reference: none
Document: NASREQ-07
Comment type: 'E'ditorial
Priority: 'S' Must fix
Section: 10.1
Rationale/Explanation of issue:

The following AVPs are listed as being mandatory, while the corresponding
ABNF definitions (sections 3.1 and 4.2) do not mandate them:

   Attribute Name                | AAR | AAA | DER | DEA |
   ------------------------------|-----+-----+-----+-----|
   Destination-Realm             | 0   | 1   | 1   | 0   |
   EAP-Payload                   | 0   | 0   | 1   | 1   |
   NAS-IP-Address                | 1   | 0   | 1   | 0   |
   NAS-Port                      | 1   | 0   | 1   | 0   |

Requested change:
According to the ABNF definitions, they should be:

   Attribute Name                | AAR | AAA | DER | DEA |
   ------------------------------|-----+-----+-----+-----|
   Destination-Realm             | 0   | 0   | 1   | 0   |
   EAP-Payload                   | 0   | 0   | 1   | 0   |
   NAS-IP-Address                | 0   | 0   | 0   | 0   |
   NAS-Port                      | 0   | 0   | 0   | 0   |

-Kev

=================================
Kevin Purser, Software Engineer
Ericsson, Inc.
---------------------------------------------
2100 Shattuck Ave.
Berkeley, CA  94704
Phone (510) 305-6100
=================================

---

From: Mark Eklund <[email-masked]>
Date: Mon, 6 Aug 2001 18:36:38 -0400 (EDT)

All,

I wanted to give some input on issue 109.

Issue 109 states that there is overhead involved in having to
create a sample missing AVP.  That is true.  The suggested fix
is to create a Missing-AVP of type integer to hold the missing
AVP.  There is one problem with this.  If the AVP is vendor
specific, you need to create a new Missing-Vendor-AVP to hold
the vendor ID.  If there is a vendor specific and an IETF AVP 
missing, you would have to somehow group them.  So now you have
to create a grouped avp to hold the Missing-AVP and the
Missing-Vendor-AVP.  

In my opinion the overhead of creating a some fake data for the
payload is much less than the extra overhead listed above.

-mark

---

From: Tony Johansson <[email-masked]>
Date: Tue, 07 Aug 2001 06:39:16 -0700

Mark Eklund wrote:

> the vendor ID.

I'm not really following you. If a peer finds out that a vendor specific
AVP is missing, means that it also know the specific vendor Id. Right?
So you would still use the same Missing-AVP, but with the Vendor Id set
in the Missing-AVP header. I don't see any need for a new
Missing-Vendor-AVP.

> If there is a vendor specific and an IETF AVP
> missing, you would have to somehow group them.

>  So now you have

If there is more than one AVP missing you would simply add multiple
Missing-AVP AVPs and for those that are vendor specific you would make
use of the vendor Id in the AVP header.

However, if people rather wants to use a grouped AVP in the case of
multiple Missing-AVP AVPs. I'm fine with that too. I just saw it simpler
to add multiple Missing AVP AVPs.

> payload is much less than the extra overhead listed above.

see comments above...

Regards,

/Tony

---

From: Pat Calhoun <[email-masked]>
Date: Tue, 7 Aug 2001 06:41:34 -0700

I think Mark's comment is that if the AVP in question is vendor-specific,
how would you flag that info.

If Missing-AVP is assigned the code 999, and the missing avp is AVP 600,
you would have something like:
AVPCode = 999
Vendor-Id = 0
Data = 600

Now, if the missing AVP was 600, but vendor-id is 555, you MUST NOT do
the following:
AVPCode = 999
Vendor-Id = 555
Data = 600

because AVP 999/555 is different from 999/0. So I believe that Mark is
stating the following is needed:

AVP Code = 777 (Grouped AVP)
	AVP Code = 999
		Data = 600
	Vendor-Id = 888
		Data = 555

(I used bogus AVP codes above)

PatC

---

From: Mark Eklund <[email-masked]>
Date: Tue, 7 Aug 2001 09:59:02 -0400 (EDT)

Pat, you saved me some typing.  That is what I meant.
-mark

---

From: "Fredrik Johansson" <[email-masked]>
Date: Tue, 7 Aug 2001 16:08:54 +0200

I probably missed something earlier, but didn't we ones have the mechanism
to include the entire missing avp header? So if you know that one avp is
missing (vendor specific or not) you create the whole avp header, which
includes the vendor id if it is vendor specific.

Isn't that something we can go back to and use?

/Fredrik

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]]On Behalf Of
>Pat Calhoun
>Sent: den 7 augusti 2001 15:42
>To: Tony Johansson
>Cc: Mark Eklund; [email-masked]
>Subject: Re: [AAA-WG]: Issue 109 Request for a new AVP called
>Missing-AVP
>
>

---

From: Mark Eklund <[email-masked]>
Date: Tue, 7 Aug 2001 10:18:24 -0400 (EDT)

We had what I described.  A failed-avp that contained an integer
of the AVP value, a Failed-Vendor-Id, and an Offending-AVP of
type grouped that held both of them.  See
 
http://www.diameter.org/issues.html#Issue #30

as to when it got changed in base 05.

-mark

---

From: Tony Johansson <[email-masked]>
Date: Tue, 07 Aug 2001 07:23:17 -0700

Ahhh, your are absolutely right. So what I suggested would actually add on
more overhead :(

/Tony

---

From: "Fredrik Johansson" <[email-masked]>
Date: Tue, 7 Aug 2001 16:58:24 +0200

Ok,

So a missing avp is included as a whole avp in the Failed-Avp AVP (with its
payload set to zeros). If several avp's are missing, they're all included in
the Failed-Avp AVP.

Does it mean that if the missing avp is of type uint32 I have to add 4 zeros
at the end? And if it is of type octet string, then I don't need to add
anything at the end?

/Fredrik

>Mark Eklund
>Sent: den 7 augusti 2001 16:18
>To: Fredrik Johansson
>Cc: Pat Calhoun; Tony Johansson; [email-masked]
>Subject: RE: [AAA-WG]: Issue 109 Request for a new AVP called
>Missing-AVP
>
>

---

From: Jacques Caron <[email-masked]>
Date: Tue, 07 Aug 2001 17:34:25 +0200

Hi,

What about just having an 8-byte value, consisting of the Vendor-Ip (which 
can be 0 for non-vendor-specific AVPs?) and the AVP code for the missing AVP?

Simple and easy. Could even put a whole list of missing AVPs in a single 
AVP (the number of AVPs would be AVP length - header length / 8).

Just my CHF 0.02 :-)

Jacques.

> >> >> > payload is much less than the extra overhead listed above.

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

---

From: Pat Calhoun <[email-masked]>
Date: Tue, 7 Aug 2001 09:11:21 -0700

> AVP (the number of AVPs would be AVP length - header length / 8).

But that would put is back in the mode os supporting AVPs of type complex.
This issue is already solved using the existing AVP set.

> Just my CHF 0.02 :-)

Just my EUR 0.02 :)

PatC