Subject: RE: [AAA-WG]: Re: Issue 424: Record-Route AVP in Responses

From: <[email-masked]>
Date: Tue, 30 Sep 2003 10:03:47 +0300

Bernard Aboba wrote:

> > Yes, I guess we could allow Route-Record AVPs in responses well.
> > However, we still need to clarify how they get there... what
> > would be the best way to get this specified? Having NASREQ
> > update RFC3588? A new RFC that updates RFC3588?
> 
> We could submit an errata for RFC 3588, since it is RFC 3588 that is
> internally inconsistent.  Then we could clarify how they get there in
> NASREQ.
> 
> > BTW, the current text in NASREQ isn't consistent with what IMHO
> > would be the most logical way to add the Route-Records (proxies
> > add them to responses one by one). But there isn't any clearly
> > specified alternative it would be consistent with either...
> 
> Could you suggest new text?

Ok, here's a first attempt (I'd appreciate if somebody else could
also check that these make sense and don't create more
inconsistencies :-)

Errata for RFC3588:

o  Section 6.2.2: add the following text after the first paragraph:

   "A proxy or relay agent MUST append a Route-Record AVP to all 
   responses forwarded. The AVP contains the identity of the peer 
   the response was received from."

o  Section 10.1: Update the AVP occurrence table to specify that
   RAA/ASA/STA messages can have zero or more Route-Record AVPs.

Updates for NASREQ -13b:

o  Section 9.2: Remove the following list item:

   "4. Route-Record AVPs (in the proper order)"

o  Section 9.2: Remove the following bullet:

   "The Route-Record AVPs MUST be added to the Diameter message, in
   the same order they were present in the request.  The gateway's
   position in the forwarding should be properly recorded."

o  Section 9.2: Replace the bullet 

   "The response's Origin-Host information is created from the 
   FQDN of the source IP address of the RADIUS message."

   with

   "The response's Origin-Host information is created from the FQDN
   of the source IP address of the RADIUS message. The same FQDN
   is also stored to a Route-Record AVP."

o  Section 10.1: Update AVP occurrence table to specify that
   AAA message can have zero or more Route-Record AVPs.

A couple of related editorials/typos:

o  Section 9.3.3: Replace

   "...lookup on the source address and NAS-IP-Address
   attributes..." 

   with 

   "...lookup on the source address and NAS-IPv6-Address attribute..."

o  Section 9.3.3: Add to end of last paragraph
 
   "...other action is taken."

   (seems this was chopped off at some point)

(BTW, while figuring out these changes, I found a couple
of other inconsistencies in the RADIUS-Diameter translation.
I'll post these in a separate message.)

Best regards,
Pasi

---

From: Jari Arkko <[email-masked]>
Date: Tue, 30 Sep 2003 18:52:33 +0300

>    the response was received from."

Ok.

>    RAA/ASA/STA messages can have zero or more Route-Record AVPs.

Ok, but not sufficient. Also necessary to do the following:

- Add "* [ Route-Record ]" to Section 8.3.2 (RAA), 8.4.2
   (STA), and 8.5.2 (ASA).

- Update 10.2 the AVP occurrence table to say that ACA command
   also can have Route-Record AVPs.

- Add "* [ Route-Record ]" to Section 9.7.2.

Question: are there any other commands (maybe in other documents)
that would need this update? Note that your language requires adding
the AVPs to all responses.

>    AAA message can have zero or more Route-Record AVPs.

Ok.

>    (seems this was chopped off at some point)

Ok.

--Jari