[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: no overall type in Extended Attributes
Bernard Aboba <mailto://aboba@internaut.com> writes:
> Glen Zorn said:
>
> "As I mentioned a couple of times at the Dublin session, the current
> definition of the Extended Attributes
> (http://www.ietf.org/internet-drafts/draft-ietf-radext-extended-
> attributes-0
> 4.txt) doesn't in general allow the definition of an overall type for
> the
> Attribute in question: an Extended Attribute is basically just an
> unordered set of TLVs. This fact doesn't bother me much, if at all,
> but
> the second time I mentioned it there was some grumbling from the crowd,
> so
> I thought I'd bring it up one more time on the list..."
>
> One question is how the grouping semantic differs from that of Diameter
> (RFC 3588), and what the impact is. Looking at RFC 3588, it does seem
> that the agbility to name and define a Grouped AVP has some advantages.
Perhaps, but it also has disadvantages (such as the awkwardness of defining
new AVPs for simple, ad-hoc situations.
>
> For example, it enables a formal definition of the grouped AVP,
> including
> a grammar.
It's not clear that this is actually an advantage: a large majority of the
confusion I've seen reported by Diameter developers has been caused by ABNF.
> Without this, it is possible that the loose semantics would
> affect
> interoperability (e.g. arbitrary attribute groupings might not be
> supported understood).
I don't see how this could happen except for essentially the same reasons as
in Diameter (despite the over-specification of the protocol). From your
quotation of RFC 3588 below:
'The data for the optional AVPs is represented in hex since the format of
these AVPs is neither known at the time of definition of the Example-AVP
group, nor (likely) at the time when the example instance of this AVP is
interpreted - except by Diameter implementations which support the same set
of AVPs...note that AVPs may be present in the Grouped AVP value which the
receiver cannot interpret...'
>
> From RFC 3588 Section 4.4:
>
> 4.4. Grouped AVP Values
>
> The Diameter protocol allows AVP values of type 'Grouped.' This
> implies that the Data field is actually a sequence of AVPs. It is
> possible to include an AVP with a Grouped type within a Grouped
> type,
> that is, to nest them. AVPs within an AVP of type Grouped have the
> same padding requirements as non-Grouped AVPs, as defined in Section
> 4.
>
> 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.
>
> Every Grouped AVP defined MUST include a corresponding grammar,
> using
> ABNF [ABNF] (with modifications), as defined below.
>
> grouped-avp-def = name "::=" avp
>
> name-fmt = ALPHA *(ALPHA / DIGIT / "-")
>
> name = name-fmt
> ; The name has to be the name of an AVP,
> ; defined in the base or extended Diameter
> ; specifications.
>
> avp = header [ *fixed] [ *required] [ *optional]
> [ *fixed]
>
> header = "<" "AVP-Header:" avpcode [vendor] ">"
>
> avpcode = 1*DIGIT
> ; The AVP Code assigned to the Grouped AVP
>
> vendor = 1*DIGIT
> ; The Vendor-ID assigned to the Grouped AVP.
> ; If absent, the default value of zero is
> ; used.
>
> 4.4.1. Example AVP with a Grouped Data type
>
> The Example-AVP (AVP Code 999999) is of type Grouped and is used to
> clarify how Grouped AVP values work. The Grouped Data field has the
> following ABNF grammar:
>
> Example-AVP ::= < AVP Header: 999999 >
> { Origin-Host }
> 1*{ Session-Id }
> *[ AVP ]
>
> An Example-AVP with Grouped Data follows.
>
> The Origin-Host AVP is required (Section 6.3). In this case:
>
> Origin-Host = "example.com".
>
> One or more Session-Ids must follow. Here there are two:
>
> Session-Id =
> "grump.example.com:33041;23432;893;0AF3B81"
>
> Session-Id =
> "grump.example.com:33054;23561;2358;0AF3B82"
>
> optional AVPs included are
>
> Recovery-Policy = <binary>
> 2163bc1d0ad82371f6bc09484133c3f09ad74a0dd5346d54195a7cf0b35
> 2cabc881839a4fdcfbc1769e2677a4c1fb499284c5f70b48f58503a45c5
> c2d6943f82d5930f2b7c1da640f476f0e9c9572a50db8ea6e51e1c2c7bd
> f8bb43dc995144b8dbe297ac739493946803e1cee3e15d9b765008a1b2a
> cf4ac777c80041d72c01e691cf751dbf86e85f509f3988e5875dc905119
> 26841f00f0e29a6d1ddc1a842289d440268681e052b30fb638045f7779c
> 1d873c784f054f688f5001559ecff64865ef975f3e60d2fd7966b8c7f92
>
> Futuristic-Acct-Record = <binary>
> fe19da5802acd98b07a5b86cb4d5d03f0314ab9ef1ad0b67111ff3b90a0
> 57fe29620bf3585fd2dd9fcc38ce62f6cc208c6163c008f4258d1bc88b8
> 17694a74ccad3ec69269461b14b2e7a4c111fb239e33714da207983f58c
> 41d018d56fe938f3cbf089aac12a912a2f0d1923a9390e5f789cb2e5067
> d3427475e49968f841
>
> The data for the optional AVPs is represented in hex since the
> format
> of these AVPs is neither known at the time of definition of the
> Example-AVP group, nor (likely) at the time when the example
> instance
> of this AVP is interpreted - except by Diameter implementations
> which
> support the same set of AVPs. The encoding example illustrates how
> padding is used and how length fields are calculated. Also note
> that
> AVPs may be present in the Grouped AVP value which the receiver
> cannot interpret (here, the Recover-Policy and Futuristic-Acct-
> Record
> AVPs).
>
> This AVP would be encoded as follows:
>
> 0 1 2 3 4 5 6 7
> +-------+-------+-------+-------+-------+-------+-------+-------
> +
> 0 | Example AVP Header (AVP Code = 999999), Length = 468
> |
> +-------+-------+-------+-------+-------+-------+-------+-------
> +
> 8 | Origin-Host AVP Header (AVP Code = 264), Length = 19
> |
> +-------+-------+-------+-------+-------+-------+-------+-------
> +
> 16 | 'e' | 'x' | 'a' | 'm' | 'p' | 'l' | 'e' | '.'
> |
> +-------+-------+-------+-------+-------+-------+-------+-------
> +
> 24 | 'c' | 'o' | 'm' |Padding| Session-Id AVP Header
> |
> +-------+-------+-------+-------+-------+-------+-------+-------
> +
> 32 | (AVP Code = 263), Length = 50 | 'g' | 'r' | 'u' | 'm'
> |
> +-------+-------+-------+-------+-------+-------+-------+-------
> +
> . . .
> +-------+-------+-------+-------+-------+-------+-------+-------
> +
> 64 | 'A' | 'F' | '3' | 'B' | '8' | '1'
> |Padding|Padding|
> +-------+-------+-------+-------+-------+-------+-------+-------
> +
> 72 | Session-Id AVP Header (AVP Code = 263), Length = 51
> |
> +-------+-------+-------+-------+-------+-------+-------+-------
> +
> 80 | 'g' | 'r' | 'u' | 'm' | 'p' | '.' | 'e' | 'x'
> |
> +-------+-------+-------+-------+-------+-------+-------+-------
> +
> . . .
> +-------+-------+-------+-------+-------+-------+-------+-------
> +
> 104 | '0' | 'A' | 'F' | '3' | 'B' | '8' | '2'
> |Padding|
> +-------+-------+-------+-------+-------+-------+-------+-------
> +
> 112 | Recovery-Policy Header (AVP Code = 8341), Length = 223
> |
> +-------+-------+-------+-------+-------+-------+-------+-------
> +
> 120 | 0x21 | 0x63 | 0xbc | 0x1d | 0x0a | 0xd8 | 0x23 | 0x71
> |
> +-------+-------+-------+-------+-------+-------+-------+-------
> +
> . . .
> +-------+-------+-------+-------+-------+-------+-------+-------
> +
> 320 | 0x2f | 0xd7 | 0x96 | 0x6b | 0x8c | 0x7f | 0x92
> |Padding|
> +-------+-------+-------+-------+-------+-------+-------+-------
> +
> 328 | Futuristic-Acct-Record Header (AVP Code = 15930), Length =
> 137|
> +-------+-------+-------+-------+-------+-------+-------+-------
> +
> 336 | 0xfe | 0x19 | 0xda | 0x58 | 0x02 | 0xac | 0xd9 | 0x8b
> |
> +-------+-------+-------+-------+-------+-------+-------+-------
> +
> . . .
> +-------+-------+-------+-------+-------+-------+-------+-------
> +
> 464 | 0x41 |Padding|Padding|Padding|
> +-------+-------+-------+-------+
>
>
>
>
>
> --
> to unsubscribe send a message to radiusext-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>