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

From: Leaf yeh <[email-masked]>
Date: Fri, 3 Aug 2012 16:23:19 +0000

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: [email-masked] [[email-masked]] on behalf of Stefan Winter [[email-masked]]
Sent: Monday, July 16, 2012 14:30
To: [email-masked]
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
> [email-masked]
> 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: +352 424409 1
Fax: +352 422473

---

From: Leaf yeh <[email-masked]>
Date: Fri, 3 Aug 2012 16:38:53 +0000

If we consider to use the NAS-Filter-Rule for each user session, it sounds a DPI-fliter implementing for each user session. Does it sound something heavy on the popular NAS? On the contrary, I am thinking what the basic requirement or configuration on the NAS is necessay for the services in the user session?

Best Regards,

Leaf

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

Hello,

>> Realising that a known vocabulary of traffic classes is useful for
>> inter-op between ISPs, I introduced an - optional - fixed syntax for
>> specific accounting traffic classes by using URNs. Among those is, of
>> course, IPv6, as this was the original trigger for the accounting
>> traffic class discussion.
>
>   RFC 4849 defines the NAS-Filter-Rule attribute. It's based on the
> RFC3588 IPFilterRule, which is in turn largely FreeBSD firewall rules.
>
>   Why not just leverage that?  There's no need to have a new registry
> (string or integer) for traffic classes.  Instead, just describe the
> traffic by the filter rules it matches.
>
>   That allowss for nearly unlimited flexibility, without creating any
> new standard or registry.

I took a look at IPFilterRule some time ago. I realised that it's not
entirely flexible when I saw that the fictional use case of "traffic
with a specific DSCP value" isn't covered by that attribute.

Looking further, I checked RFC5777 - The FilterRule AVP with its
numerous Classifiers (which include, but are not limited to IP
addresses) looks like better suited *if* we really choose to go in the
direction of using the axact filter definition in the accounting data as
opposed to a semantic label.

I, in turn, have concerns with that ;-) I'll go into details of this in
another reply in the thread.

Greetings,

Stefan Winter

>> If the re-charter with an explicit mention of "RADIUS Accounting
>> Extensions for Traffic Statistics" gets adopted, I would like to suggest
>> adopting my draft for that topic.
>
>   I would like a discussion around the definition of traffic classes.
> But the document is largely OK for me.
>
>   Alan DeKok.
>

Tel: +352 424409 1
Fax: +352 422473

---

From: Alan DeKok <[email-masked]>
Date: Fri, 03 Aug 2012 10:30:47 -0700

Leaf yeh wrote:
> If we consider to use the NAS-Filter-Rule for each user session, it
> sounds a DPI-fliter implementing for each user session.

  My proposal was to have the NAS describe the flow by using
NAS-Filter-Rule.  I was not proposing that the server send
NAS-Filter-Rule in Access-Accept.

> Does it sound
> something heavy on the popular NAS? On the contrary, I am thinking what
> the basic requirement or configuration on the NAS is necessay for the
> services in the user session?

  That is internal to the NAS, and implementation-dependent.  My concern
is exporting a description of the flow, in a standards-based way.

  Using an enumerated type works (e.g. IPv4, IPv6).  But it's not easily
extensible, and it's not fine-grained.

  Using a URN scheme works.  It's more extensible, and fine-grained.
But it still requires a separate layer to tie the name to the
description of the flow.

  Using NAS-Filter-Rule means that it's extensible, fine-grained, and
the "name" of the flow describes exactly what data it matches.

  NAS-Filter-Rule has other issues, but it covers a large part of the
problem space.

  Alan DeKok.

---

From: Leaf yeh <[email-masked]>
Date: Fri, 3 Aug 2012 17:37:08 +0000

Stefan - That is at least my guess, your draft does not say anything
about how new values in this enum are assigned. I.e. your draft is
underspecified in that aspect.
Same as 'the lable in URN format', the codes enumerated in integer are defined or standarized in the draft.

Stefan - Even in your own draft, the shortcomings of that approach are obvious:
for DSCP, you created a whole new attribute!
Yes, I prefer using the new sub-attribute to get the extensibility for new usage or use case. :-)

Stefan - With the string, there is indeed one space of controlled vocabulary,
it's the "urn:ietf:radius-accounting:" prefix. But: if vendors have
their own NASes with more fine-grained reporting abilities than just "IP
version" or "DSCP value", they can define these in their own URN tree
and merrily use them - without any intervention of the IETF required.

But you also need IETF to standardize the prefix and the whole string. You need define a new standardized book for the URN tree in the new space you picked.

Stefan - This is the exact same approach that is used for RADIUS attributes in
general: there are IETF attributes, and there are Vendor-Specific ones.
Why not use VSA or Extended-VSA for  that you want? I meant we might not need 'String-Unspecified'. The problem cans solved within the exsiting protocol.

Stefan - As per your draft, "extensible" means that a new RFC needs to be
written, a new attribute defined, new ENUM values specified.

I supposed you need a new RFC to define a new lable in URN format for new use case. Right?

Stefan - And if that thing to report about proves to
be interesting enough for the IETF to care, *then* can it be blessed by
putting it into the IETF URN tree. Again, very similar to VSAs.
That is the same logic for the traditional standardized or vendor-specific attributes. Why not solved the problem within the exsiting protocol and comply wth the exsiting design guidelines. I still can't see the necessity or motivations to create something new.

Best Regards,
Leaf

________________________________
From: [email-masked] [[email-masked]] on behalf of Stefan Winter [[email-masked]]
Sent: Saturday, July 14, 2012 0:09
To: [email-masked]
Subject: Re: [radext] Fwd: New Version Notification for draft-winter-radext-fancyaccounting-01.txt

Hi,

> The sub-attribute, Acct-Traffic-Class-Name, here sounds create a new data type of string with additional specification. And the method of 'URN' does not really get advantages over the enumeration codes defined in  sub-attributes of the draft-yeh-radext-ext-traffic-statistics-03.

It's very obvious advantage is flexibility.

Your integer is limited to IETF actions if new values are to be
assigned. That is at least my guess, your draft does not say anything
about how new values in this enum are assigned. I.e. your draft is
underspecified in that aspect.
Even in your own draft, the shortcomings of that approach are obvious:
for DSCP, you created a whole new attribute!

With the string, there is indeed one space of controlled vocabulary,
it's the "urn:ietf:radius-accounting:" prefix. But: if vendors have
their own NASes with more fine-grained reporting abilities than just "IP
version" or "DSCP value", they can define these in their own URN tree
and merrily use them - without any intervention of the IETF required.

This is the exact same approach that is used for RADIUS attributes in
general: there are IETF attributes, and there are Vendor-Specific ones.

The analogy should be pretty obvious to see. I hope you are not going to
argue about the usefulness of VSAs; they have done a lot of good in the
last decades. Following that path sounds rather logical to me.

> I mean the enumeration problem of traffic type is still there, but introduced a more new type of string parser for this specified data type. Then the question will be why we need this kind of complexity to solve the same problem.

What extra parser are you talking about? It's a string, and it has a
value. A NAS can act very simply with that: if it is supposed to report
on IPv6 volumes, it puts the literal string

"urn:ietf:radius-accounting:ip:6"

into the attribute. A RADIUS server which is curious whether it got any
IPv6 volume statistics makes a simple equality check on incoming
Acct-Traffic-Class-Name attributes:

if ( Acct-Traffic-Class-Name == "urn:ietf:radius-accounting:ip:6" ) {
        do fancy stuff with IPv6 data;
}

An equality check is just about the simplest parser I can imagine. You
draft would need to compare integers, too.

> <quote>Option 2: Acct-Traffic-Class-Name string not starting with "urn:".
> This option is for local use of special-purpose accounting as defined
> by the NAS administrator, where no defined URN matches the meaning of
> the traffic to be counted. The meaning of the content needs to be
> communicated out-of-band between the NAS and RADIUS Server operator.
> Example: Acct-Traffic-Class-Name = "UDP traffic to AS2606". </quote>
>
> The 'non-urn' string sounds opaque or un-readable to the machine as the usual string. Right?

That's right. A RADIUS server can still be configured by the admin to
log them in a defined way if he so wants, using the same equality checks
as above.

> What kind of the out-of-band means will be needed for the data interpretation in the string? This also sounds new complexities.

In small environments, the NAS admin is also the RADIUS Server admin.
There is no complexity.

In larger environments, human communication between NAS admin and RADIUS
admin by a communication means of your choice needs to take place. For
example an e-mail

"
From: NAS Admin
To: RAIDUS Server admin
Subject: traffic counter installed!

Dear RADIUS Server admin,

you asked me to configure our NASes to report on the amount of UDP
traffic sent to AS2602, to find out who the guy is who swamps our
backbone with source-address-faked UDP packets. Just to let you know, I
configured that 5 minutes ago; the NASes will use the
Acct-Traffic-Class-Name label "UDP->AS2602" in their accounting records.
Hope you'll catch him!

Best regards,

Your NAS Admin"

Or Jabber. Or POTS. Or whatever you like.

Of course this does not scale; it's not very useful beyond enterprise
borders. For these, a proper definition and - guess what - a URN value
would be used to formalise things.

If that approach is seen as too liberal (I can sort of understand that),
the draft can be changed to limit itself to option 1 only (urn: prefix
MUST be used).

That would still allow non-IETF groups to define their own filters. What
I don't like about it is that some people *will* ignore the requirement
and send arbitrary strings anyway - so why not spell out that
possibility explicitly. It is certainly the most painless way for little
enterprises which couldn't be bothered to make their own URN registry.

> Stefan - The main question seems to be: should the format be extensible
> to support arbitrary accounting needs? Or should it be limited to a few
> fixed values, centrally managed by the IETF?
>
> a. Nesting-TVL with its sub-attributes does not mean that it can't be extensible in the future to define new sub-attribute for the necessary provisioning scenario.
> b. Fixed and extensible. To make a proposed standard managed by IETF is why we come here. Right?

Again, you prove my point with your own draft.

As per your draft, "extensible" means that a new RFC needs to be
written, a new attribute defined, new ENUM values specified. For
*everything*. One example is DSCP. Funny thing is, I don't care much
about DSCP. I only used it as an example of something people *might
want*. Your reaction is that the draft needs a new attribute to carry
the DSCP values.

Whereas as per my draft, "extensible" means that if an organisation or
individual has its own idea about what it wants to get stats about, it
can just carry on and do it. And if that thing to report about proves to
be interesting enough for the IETF to care, *then* can it be blessed by
putting it into the IETF URN tree. Again, very similar to VSAs.

Greetings,

Stefan Winter

>
>
> Stefan - Spending time uselessly arguing on
> off-topic aspects doesn't contribute to a solution.
>
> Agreed. I suggest to ask the chairs to solve the argument between us. OK?
>
>
> Best Regards,
> Leaf
>
>
>
> ________________________________________
> Sent: Thursday, July 12, 2012 21:32
> To: [email-masked]
>> Welcome debate or competition on the same topic: RADIUS Accounting Extensions for Traffic Statistics. Hope the WG could figure out the solution on this topic soon. The problem looks not so difficult.
>
> Indeed. The main question seems to be: should the format be extensible
> to support arbitrary accounting needs? Or should it be limited to a few
> fixed values, centrally managed by the IETF?
>
> I argue for the first, you for the second.
>
>> Stefan - This is the consequence of Leaf's decision to first suggest numerous other, inferior, approaches, and then, when these were repelled, copying the approach from my -00 with slightly different wording with his name as the author; unsurprisingly, the two drafts are now very close to each other.
>>
>> History on this topic in my memory for your correction:
>> 1.  draft-yeh-radext-dual-stack-access-00 (2011-3-7) put forward the topic & 1st solution of RADIUS Accounting Extensions for Traffic Statistics for dual stack, and presented in IETF80;
>> 2.  After IETF80 Radext session, draft-winter-radext-fancyaccounting-00 (2011-3-31) put forward the 2nd solution of TLV with extended-type space;
>> 3.  draft-yeh-radext-dual-stack-access-02 expired in 2011-09-30
>> 4.  draft-winter-radext-fancyaccounting-00 expired in 2011-10-02
>> 5.  The IETF82 presentation (<thismessage:/>http://www.ietf.org/proceedings/82/slides/radext-2.pdf ) with draft-yeh-radext-ext-traffic-statistics-01 re-triggered the discussion on the attribute design of Acct-Traffic-Statistics;
>> 6.  After got the hint in the meeting minutes of Radext IETF82 (<thismessage:/>http://www.ietf.org/mail-archive/web/radext/current/msg07489.html ), I asked for the cooperation with Stefan on this topic several times, but it looks to bump;
>> 7.  After the discussion on the mailing list of Radext, draft-yeh-radext-ext-traffic-statistics-02 adopted the date type of nesting-TLV;
>> 8.  Around more than 1 week before I submitted draft-yeh-radext-ext-traffic-statistics-03, I asked Stefan for his revision and cooperation on my draft again, but failed.
>
> Thanks for this timeline - it perfectly proves my point. The TLV
> structure was first introduced in your point 2 by me. It reappeared in
> point 7. - This time, the author was you, while the concept was the same.
>
> The fact that you repeatedly put up slides in the time between 2 and 7
> which were calling the TLV approach "design 3" does not mean it was your
> idea and design. The draft, idea and structure were there long before
> you did that.
>
> In that light, isn't it understandable that I don't fancy becoming a
> co-author of "your" draft with you as an editor?
>
> If that's not a sufficient justification for me being upset, here's
> another one: following IETF80, I created fancyaccounting-00 because I
> was trying to *help* you - you presented a good problem statement, and I
> had an easy solution in my mind. And yet, when I uploaded it *and* got
> positive feedback from the WG, you indicated that you are not interested
> in the topic in a subsequent meeting, making it all stall. That is not nice.
>
> That's my only reply on that topic. Spending time uselessly arguing on
> off-topic aspects doesn't contribute to a solution.
>
>> Stefan - I believe my draft is more thorough and thought-out in many aspects. The only difference is that his draft has an integer enumerator for traffic classes, while my draft uses a string.
>>
>> The above 2 statements sounds contradictory.
>
> Not at all. My previous mail contained reasons and argument why I did
> it, and it enumerated why it is a good idea.
>
> Your reply conveniently cuts out these, and doesn't present
> counter-arguments against them. You just state you don't like it. Too bad.
>
>> Stefan - The string can do the same well-defined enumeration of known traffic classes that the integer can also do, and more.
>>
>> This sounds something real on the aspect of technology or Radius attribute design, which asks for the discussion within the WG.
>
> Indeed.
>
> Stefan Winter
>
>>
>>
>> Best Regards,
>> Leaf
>>
>>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On Behalf Of Stefan Winter
>> Sent: Thursday, July 12, 2012 4:20 PM
>> To: [email-masked]
>> Subject: [radext] Fwd: New Version Notification for draft-winter-radext-fancyaccounting-01.txt
>>
>> Hello,
>>
>> since the interest on the topic of RADIUS Accounting for subsets of the total traffic has risen again, I have revived my old, expired -00 version of "fancyaccounting". The major change to -00 is that I drop the enumerated integer as a means to express which traffic is counted, and use only the string type instead.
>>
>> Realising that a known vocabulary of traffic classes is useful for inter-op between ISPs, I introduced an - optional - fixed syntax for specific accounting traffic classes by using URNs. Among those is, of course, IPv6, as this was the original trigger for the accounting traffic class discussion.
>>
>> The advantage of the URN/freetext model is that it can be expanded arbitrarily and yet have a defined meaning; while still allowing a local admin to count "whatever" by choosing not to use a URN. I would like to thank Klaas Wierenga for his inspiration in that regard!
>>
>> The other changes are cleanups (move of Integer64 to radius-extensions) and tighter semenatic requirements of when to send what; including a way to express which bytes exactly to count - a suggestion I got some 2 years ago when discussing -00.
>>
>> This is an individual submission which is in sort of a competition with draft-yeh-radext-ext-traffic-statistics. This is the consequence of Leaf's decision to first suggest numerous other, inferior, approaches, and then, when these were repelled, copying the approach from my -00 with slightly different wording with his name as the author; unsurprisingly, the two drafts are now very close to each other. I believe my draft is more thorough and thought-out in many aspects. The only difference is that his draft has an integer enumerator for traffic classes, while my draft uses a string. The string can do the same well-defined enumeration of known traffic classes that the integer can also do, and more.
>>
>> If the re-charter with an explicit mention of "RADIUS Accounting Extensions for Traffic Statistics" gets adopted, I would like to suggest adopting my draft for that topic.
>>
>> Greetings,
>>
>> Stefan Winter
>>
>>
>> -------- Original Message --------
>> Subject: New Version Notification for
>> draft-winter-radext-fancyaccounting-01.txt
>> Date: Thu, 12 Jul 2012 01:16:54 -0700
>> From: [email-masked]
>> To: [email-masked]
>>
>>
>> A new version of I-D, draft-winter-radext-fancyaccounting-01.txt
>> has been successfully submitted by Stefan Winter and posted to the IETF repository.
>>
>> Filename:      draft-winter-radext-fancyaccounting
>> Revision:      01
>> Title:                 RADIUS Accounting for traffic classes
>> Creation date:         2012-07-12
>> WG ID:                 Individual Submission
>> Number of pages: 9
>> URL:
>> http://www.ietf.org/internet-drafts/draft-winter-radext-fancyaccounting-01.txt
>> Status:
>> http://datatracker.ietf.org/doc/draft-winter-radext-fancyaccounting
>> Htmlized:
>> http://tools.ietf.org/html/draft-winter-radext-fancyaccounting-01
>> Diff:
>> http://tools.ietf.org/rfcdiff?url2=draft-winter-radext-fancyaccounting-01
>>
>> Abstract:
>>     This document specifies new attributes for RADIUS Accounting to
>>     enable NAS reporting of subsets of the total traffic in a user
>>     session.
>>
>>
>>
>>
>>
>> The IETF Secretariat
>>
>>
>>

Tel: +352 424409 1
Fax: +352 422473

---

From: Leaf yeh <[email-masked]>
Date: Fri, 3 Aug 2012 17:41:28 +0000

The use case presented below sounds some requirement on traffic statistics of the border router. Is it worth a new draft for it?

Best Regards,
Leaf

________________________________
From: [email-masked] [[email-masked]] on behalf of Stefan Winter [[email-masked]]
Sent: Monday, July 16, 2012 15:02
To: Peter Deacon
Cc: [email-masked]; Alan DeKok
Subject: Re: [radext] Fwd: New Version Notification for draft-winter-radext-fancyaccounting-01.txt

Hi,

> Your origional response mentioned only class labels be replaced with
> filter rules.  Nothing was said about configuring those rules in the NAS
> by pushing parameters via Access-Accept.  I think this configuration
> would be useful.

That certainly sounds useful indeed (but is again nothing I would put
into this *accounting* draft).

> However to use filter rules as the analogy we still have and use
> Filter-Id.  If anything I would prefer to see both options made
> avaliable enabling people to choose the solution which best fits their
> needs.
>
> Not all problems can be or are best solved by pushing filters as syntax
> is limited.

That's right - and my main concern with restricting the traffic
descriptor to the exact syntax used. Here is one use case which is
(almost) taken from real life, and hopefully shows that pushing the
exact syntax over and over again in every accounting packet may be less
than practical.

Our network is a science network, interconnected with other national
science networks over a common backbone ("GEANT"). Since users sometimes
use resources outside the scienitfic networks ("the internet"), there is
also an outlet on that common backbone to peer with the world at large,
called the Dante World Service (DWS).

Intra-GEANT traffic is subsidised, DWS is not. A science network *might*
want to find out which of their connected entities cause which fraction
of traffic on DWS, to send a bill about that traffic - but not the GEANT
one.

(Disclaimer: the wish to send bills for that is entirely fictional and
only made up here for argument purposes; the rest of the example is real
life though)

The classification "GEANT or DWS" is not simple - there are some 50 ASes
in the GEANT backbone, most of which have multiple IP prefixes in their
announcement.

A NAS would thus need to know a three-digit amount of IP prefixes to
classify traffic. Getting the list to the NAS alone is a daunting task,
but luckily it needs to be done just one time.

Sending the exact filter definition with hundreds of prefixes in *every
accounting packet* sounds extremely impractical to me! If I had a
traffic label called "urn:geant:dws-traffic" - I would be a lot happier
than with receiving a huge blob of IP filter rules all the time.

Greetings,

Stefan Winter

Tel: +352 424409 1
Fax: +352 422473

---

From: Stefan Winter <[email-masked]>
Date: Fri, 03 Aug 2012 19:47:46 +0200

Hi,

> 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.
>

The sentences you write above do not contradict my statement, which you
sort of quote (proper email style is to add indentation levels. It makes
reading email so much easier!)

So, what exactly do you want to say?

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

Learn to quote. That last sentence is yours, and the above ones are
collated from several non-contiguous parts of my earlier mails, right?

Quoting from my draft : "New values for this registry are assigned on
expert review basis."

expert review != document action.

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

Stop quoting me out of context. The use case I referred to is about
people who want their own label, but are negligent enough not to go for
a urn namespace value.

Your sentence above makes it sound like I don't care about real life use
cases, such as yours. I do care about IPv6 accounting; it's where this
all started from.

> 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?
>

Option two is about the uncontrolled string values. Usage of VSAs
requires people to care enough to register a VSA; which is equivalent to
defining a URN label. So, option 2 has nothing to do with VSAs.
Actually, expisting practice of such negligent people revealed that if
the only option to transmit their data is a VSA, they'll hijack proper
IETF attributes or make up VSAs that they didn't actually register. I
prefer that not to happen; giving them an uncontrolled environment where
they are all on their own and can't expect interop sounds like a way to
go to me.

Greetings,

Stefan Winter
>
>  
>
>  
>
> Best Regards,
>
> Leaf
>
>  
>
>  
>
> ------------------------------------------------------------------------
> *From:* [email-masked] [[email-masked]] on behalf of
> Stefan Winter [[email-masked]]
> *Sent:* Monday, July 16, 2012 14:30
> *To:* [email-masked]
> *Subject:* Re: [radext] Fwd: New Version Notification for
> extensions: http://tools.ietf.org/html/draft-iab-extension-recs-17
> <http://tools.ietf.org/html/draft-iab-extension-recs-17>,
> > www.elbrys.com <http://www.elbrys.com/> <http://www.elbrys.com
> <http://www.elbrys.com/>>
> > +1.603.570.2636
> >
> >

---

From: Stefan Winter <[email-masked]>
Date: Fri, 03 Aug 2012 19:52:33 +0200

Hi,

> defined or standarized in the draft.

The magic words are "expert review".

> new usage or use case. :-)

If that smiley was to mean something funny, I don't get it.

> But you also need IETF to standardize the prefix and the whole string.
> You need define a new standardized book for the URN tree in the new
> space you picked.

Book? It's an IANA registry.

> Why not use VSA or Extended-VSA for  that you want? I meant we might
> not need 'String-Unspecified'. The problem cans solved within the
> exsiting protocol.

See my other mail.

> I supposed you need a new RFC to define a new lable in URN format for

No.

> That is the same logic for the traditional standardized or
> vendor-specific attributes. Why not solved the problem within the
> exsiting protocol and comply wth the exsiting design guidelines. I
> still can't see the necessity or motivations to create something new.

What's new about the very basic data type string? Or using strings as
label for something?

What makes you think using using a string to express a label value is
against the design guidelines?

Greetings,

Stefan Winter

> *Sent:* Saturday, July 14, 2012 0:09
> *To:* [email-masked]
> > The sub-attribute, Acct-Traffic-Class-Name, here sounds create a new
> data type of string with additional specification. And the method of
> 'URN' does not really get advantages over the enumeration codes
> defined in  sub-attributes of the
> draft-yeh-radext-ext-traffic-statistics-03.
>
> > I mean the enumeration problem of traffic type is still there, but
> introduced a more new type of string parser for this specified data
> type. Then the question will be why we need this kind of complexity to
> solve the same problem.
>
> > What kind of the out-of-band means will be needed for the data
> interpretation in the string? This also sounds new complexities.
>
> > a. Nesting-TVL with its sub-attributes does not mean that it can't
> be extensible in the future to define new sub-attribute for the
> necessary provisioning scenario.
> > Subject: Re: [radext] Fwd: New Version Notification for
> >> Welcome debate or competition on the same topic: RADIUS Accounting
> Extensions for Traffic Statistics. Hope the WG could figure out the
> solution on this topic soon. The problem looks not so difficult.
> >
> >> Stefan - This is the consequence of Leaf's decision to first
> suggest numerous other, inferior, approaches, and then, when these
> were repelled, copying the approach from my -00 with slightly
> different wording with his name as the author; unsurprisingly, the two
> drafts are now very close to each other.
> >>
> >> 1.  draft-yeh-radext-dual-stack-access-00 (2011-3-7) put forward
> the topic & 1st solution of RADIUS Accounting Extensions for Traffic
> Statistics for dual stack, and presented in IETF80;
> >> 2.  After IETF80 Radext session,
> draft-winter-radext-fancyaccounting-00 (2011-3-31) put forward the 2nd
> solution of TLV with extended-type space;
> >> 5.  The IETF82 presentation
> (http://www.ietf.org/proceedings/82/slides/radext-2.pdf ) with
> draft-yeh-radext-ext-traffic-statistics-01 re-triggered the discussion
> on the attribute design of Acct-Traffic-Statistics;
> >> 6.  After got the hint in the meeting minutes of Radext IETF82
> (http://www.ietf.org/mail-archive/web/radext/current/msg07489.html ),
> I asked for the cooperation with Stefan on this topic several times,
> but it looks to bump;
> >> 7.  After the discussion on the mailing list of Radext,
> draft-yeh-radext-ext-traffic-statistics-02 adopted the date type of
> nesting-TLV;
> >> 8.  Around more than 1 week before I submitted
> draft-yeh-radext-ext-traffic-statistics-03, I asked Stefan for his
> revision and cooperation on my draft again, but failed.
> >
> >> Stefan - I believe my draft is more thorough and thought-out in
> many aspects. The only difference is that his draft has an integer
> enumerator for traffic classes, while my draft uses a string.
> >>
> >> Stefan - The string can do the same well-defined enumeration of
> known traffic classes that the integer can also do, and more.
> >>
> >> This sounds something real on the aspect of technology or Radius
> attribute design, which asks for the discussion within the WG.
> >
> > Indeed.
> >
> > Stefan Winter
> >
> >>
> >>
> >> Best Regards,
> >> Leaf
> >>
> >>
> >> Subject: [radext] Fwd: New Version Notification for
> >> since the interest on the topic of RADIUS Accounting for subsets of
> the total traffic has risen again, I have revived my old, expired -00
> version of "fancyaccounting". The major change to -00 is that I drop
> the enumerated integer as a means to express which traffic is counted,
> and use only the string type instead.
> >>
> >> The advantage of the URN/freetext model is that it can be expanded
> arbitrarily and yet have a defined meaning; while still allowing a
> local admin to count "whatever" by choosing not to use a URN. I would
> like to thank Klaas Wierenga for his inspiration in that regard!
> >>
> >> The other changes are cleanups (move of Integer64 to
> radius-extensions) and tighter semenatic requirements of when to send
> what; including a way to express which bytes exactly to count - a
> suggestion I got some 2 years ago when discussing -00.
> >>
> >> This is an individual submission which is in sort of a competition
> with draft-yeh-radext-ext-traffic-statistics. This is the consequence
> of Leaf's decision to first suggest numerous other, inferior,
> approaches, and then, when these were repelled, copying the approach
> from my -00 with slightly different wording with his name as the
> author; unsurprisingly, the two drafts are now very close to each
> other. I believe my draft is more thorough and thought-out in many
> aspects. The only difference is that his draft has an integer
> enumerator for traffic classes, while my draft uses a string. The
> string can do the same well-defined enumeration of known traffic
> classes that the integer can also do, and more.
> >>
> Extensions for Traffic Statistics" gets adopted, I would like to
> suggest adopting my draft for that topic.
> >>
> >> Greetings,
> >>
> >> Stefan Winter
> >>
> >>

---

From: Leaf yeh <[email-masked]>
Date: Fri, 3 Aug 2012 17:54:44 +0000

Alan - My concern

I believe it is worth a brand new draft.

Best Regards,

Leaf

________________________________
From: [email-masked] [[email-masked]] on behalf of Alan DeKok [[email-masked]]
Sent: Saturday, August 04, 2012 1:30
To: Leaf yeh
Cc: [email-masked]
Subject: Re: [radext] Fwd: New Version Notification for draft-winter-radext-fancyaccounting-01.txt

  Alan DeKok.

---

From: Stefan Winter <[email-masked]>
Date: Fri, 03 Aug 2012 20:07:21 +0200

Hi,

> The use case presented below sounds some requirement on traffic
> statistics of the border router. Is it worth a new draft for it?
>

Since my example was made up, I'm not personally interested. But it
sounds like a GoodThing in principle. So, why not.

Stefan

> *Sent:* Monday, July 16, 2012 15:02
> *To:* Peter Deacon
> *Cc:* [email-masked]; Alan DeKok