Subject: [AAA-WG]: Issue 80: Editorial changes

From: Pat Calhoun <[email-masked]>
Date: Mon, 18 Jun 2001 10:30:37 -0700

All,

In an attempt to close this issue, I'd like to propose the following text:

- in Definition of End-to-end identifier, included definition for locally 
consumed incorrect. Reference appropriate section. 

The text now reads:

"   End-to-End Identifier
      Unlike the Hop-by-Hop Identifier, the End-to-End Identifier is
      used to detect duplicate messages, and relay agents MUST NOT
      modify this field. The sender of a request or answer message MUST
      insert a locally unique value in this field. The combination of
      the Origin-Host AVP and this field is used to detect duplicates.
      An Answer message which is received with a previously seen End-
      to-End Identifier, and is to be locally consumed (see Section 5.2)
      SHOULD be silently discarded.:

- 15.1.2 is not up to date (bit numbers) 

yes, I had caught this one earlier, and the following text solves this
one:

"15.1.2  AVP Flags

   There are 8 bits in the AVP Flags field of the AVP header, defined in
   section 4.0. This document assigns bit 8 ('V'endor Specific), bit 7
   ('M'andatory) and bit 6 ('P'rotected). The remaining bits should only
   be assigned via a Standards Action [12]."

- 15.4 does not include protocol errors 

yup, this one too

"15.4  Result-Code AVP Values

   As defined in Section 9.1, the Result-Code AVP (AVP Code 268) defines
   the values 1001, 2001-2002, 3001-3009, 4001-4003 and 5001-5015.

   All remaining values are available for assignment via IETF Consensus
   [12]."

- In 10.3, update Session-ID format with full Diameter-Identity 

right, so how about the following:

"10.3  Session-Id AVP

   [...]
   <diameterIdentity>;<high 32 bits>;<low 32 bits>[;<optional value>]

   [...]
   Example, in which the standard port is used and there is no optional
   value:

      aaa://diameter/accesspoint7.acme.com;1876543210;523
   or
      accesspoint7.acme.com;1876543210;523

   Example, in which a non-standard port is used and there is an
   optional value:

      accesspoint7.acme.com:831;1876543210;523;[email-masked]"

- All AVPs share same scope/numbering space (even inside a Grouped-AVP) 
- M AVP within a non-M grouped AVP 

ok, how about:

"4.5  Grouped AVP Values

   [...]
   The AVP Code numbering space of all AVPs included in a Grouped AVP is
   the same as for non-grouped AVPs. Further, if any of the AVPs
   encapsulated within a Grouped AVP has the 'M' (mandatory) bit set,
   the Grouped AVP itself MUST also include the 'M' bit set.

- in 10.3 second paragraph, remove reference to multiple Session-IDs. 

ok.

Thanks,

PatC

---

From: "Fredrik Johansson" <[email-masked]>
Date: Tue, 19 Jun 2001 08:33:18 +0200

Hi,

Shouldn't the End-to-End Identifier be a monotonically increased number as
the hop-by-hop id, otherwise you'll have to keep a lot of IDs stored for
every Origin-Host.

"   End-to-End Identifier
      Unlike the Hop-by-Hop Identifier, the End-to-End Identifier is
      used to detect duplicate messages, and relay agents MUST NOT
      modify this field. The sender of a request or answer message MUST
      insert a locally unique value in this field. The combination of
      the Origin-Host AVP and this field is used to detect duplicates.
      An Answer message which is received with a previously seen End-
      to-End Identifier, and is to be locally consumed (see Section 5.2)
      SHOULD be silently discarded. The End-to-End identifier is a
	monotonically increasing number, whose start value was randomly
	generated."

/Fredrik

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]]On Behalf Of
>Pat Calhoun
>Sent: den 18 juni 2001 19:31
>To: [email-masked]
>Subject: [AAA-WG]: Issue 80: Editorial changes
>
>
>All,
>

---

From: Pat Calhoun <[email-masked]>
Date: Tue, 19 Jun 2001 05:41:22 -0700

> 	monotonically increasing number, whose start value was randomly

We could, but you cannot assume that packets will arrive in order, so your
table of e2e ids will have holes in it. Perhaps short-term holes are better
than long term ones, though.

PatC

---

From: Jacques Caron <[email-masked]>
Date: Tue, 19 Jun 2001 14:59:05 +0200

We could use wording and code similar to that found in RFC2401 (IPsec)... 
Or we can just give a "lifetime" to End-to-End identifiers. I think the 
latter is probably better than the former, since in high traffic scenarios 
we could have a duplicate coming back loooong after (in terms of numbers of 
requests).

Jacques.

>than long term ones, though.

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

---

From: Pat Calhoun <[email-masked]>
Date: Tue, 19 Jun 2001 06:41:13 -0700

> we could have a duplicate coming back loooong after (in terms of numbers of 

and how would you assign a lifetime? On a very high density NAS, there will be
many requests sent. So I see three alternatives:
1. As you state, something similar to RFC 2402, where a sliding window is used
   (see section 3.4.3 of RFC 2402 for more details). This is probably my preferred
   approach. We would have to state the window size, of course, and in my opinion
   a window of 128 is safer.
2. Not specify a method, and leave it to implementation (a few will like this too)
3. Specify that the list of identifiers must be maintained (what it is now), 
   define how it is done, but allow for local optimizations.

Again, my preference is #1 above.

PatC