Re: [radext] Fwd: New Version Notification for draft-winter-radext-fancyaccounting-01.txt

[Leaf yeh <[e-mail]>]

For the discussion in RADEXT session of IETF84:



Stefan - That draft is very specific about sending IPv6 and/or IPv4 counter values, so
so there are exactly three defined enum values for those two traffic classes



Acct-Traffic-Statistics.Stack-Type has three defined enum values for IPv4-only, IPv6-only & dual-stack. That means the container attribute, Acct-Traffic-Statistics, can appear 1+ times in the Accounting-Request message.



Stefan - All other values in these two attributes are reserved, suggesting that IETF Action is necessary to add new values.
IOW, there is *no* extensibility in that draft.

Sure: that's why the URN namespace option is devised to carry labels
with defined and published meanings, which ensures interop.

The 'labels with defined and published meanings' sounds that 'IETF Action is necessary to add new' labels.

Stefan - As I wrote earlier, I don't care much about that use case,



Draft-yeh do care the use case for deployment scenarios. It originated or derived from the requirements in Broadband Access defined in Broadband Forum.



Stefan - I could also
live with dropping that option 2. It's just that I believe openness in
this aspect doesn't hurt; the strings are compared char-by-char to find
the one with a specific meaning anyway and it technically makes no
difference at all whether it starts with "urn:" or not.

Option 2 sounds the use case for the 'tradtional opaque string' employed in VSA. The same flexibility could also be achieved through VSA or Extended-VSA. Why not use or Extended-VSA?





Best Regards,

Leaf





________________________________
From: [e-mail] [[e-mail]] on behalf of Stefan Winter [[e-mail]]
Sent: Monday, July 16, 2012 14:30
To: [e-mail]
Subject: Re: [radext] Fwd: New Version Notification for draft-winter-radext-fancyaccounting-01.txt

Hello,

> I haven't read the (competing?) drafts in a while, but one issue in your
> most recent mail caught my attention.
>
> What's the fundamental difference between a string type encoding using
> an (unregistered) user-private URN namespace and a Vendor
> Specific Enumeration for an integer type?  The latter is
> an officially discouraged technique, in the RADIUS Design Guidelines, as
> I recall.

There is no vendor-specific enumeration in the other draft at all. That
draft is very specific about sending IPv6 and/or IPv4 counter values, so
there are exactly three defined enum values for those two traffic classes.

The attribute is Acct-Traffic-Statistics.Stack-Type - the name suggests
that it is not meant to be extensible to carry more meaning than the IP
stack version.

When discussing DSCP traffic classes as something people might want to
count, the author introduced an entire new attribute for that,
Acct-Traffic-Statistics.DSCP-Type.

It is only meant to be used in conjunction with the IP stack one, to
report on the intersecting set of these two orthogonal properties.

All other values in these two attributes are reserved, suggesting that
IETF Action is necessary to add new values.

IOW, there is *no* extensibility in that draft. Assuming that people out
there will at some point want to count other conditions in their
accounting records, this forces them to hijack one of the reserved
numbers, therewith breaking semantics of these attributes and hampering
interop.

> Flexibility for small users, who can't be bothered with managed
> namespaces and codepoints is all well and good, but it seems to me that
> the purpose of doing work in the IETF is to guarantee a high level
> multi-vendor interoperability by formally defining such things.  No?

Sure: that's why the URN namespace option is devised to carry labels
with defined and published meanings, which ensures interop.

The non-URN strings are only meant for local use. They don't guarantee
any interoperability - if the accounting data is to be shared across
enterprises, they need to define a "proper" URN one and use that.

As I wrote earlier, I don't care much about that use case, I could also
live with dropping that option 2. It's just that I believe openness in
this aspect doesn't hurt; the strings are compared char-by-char to find
the one with a specific meaning anyway and it technically makes no
difference at all whether it starts with "urn:" or not.

And if we forbid that kind of use, my gut feeling from above applies
here at well: if people want to use it in a non-URN way, they will. So
if it doesn't hurt protocol-wise to provide a local-use loophole, and
might help some people, we can just as well do it.

(I am talking of local use as in the current IAB draft about protocol
extensions: http://tools.ietf.org/html/draft-iab-extension-recs-17,
Section 3.2.2; it might be useful to point to that reference in a later rev)

Greetings,

Stefan Winter

>
> Regards,
>
> Dave
>
> David B. Nelson
> Director of Technology
> Elbrys Networks, Inc.
> www.elbrys.com<http://www.elbrys.com/> <http://www.elbrys.com<http://www.elbrys.com/>>
> +1.603.570.2636
>
>
> _______________________________________________
> radext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/radext
>


--
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et
de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: [phone]
Fax: [phone]