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

[Stefan Winter <[e-mail]>]

Hi,

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

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

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.

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

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.

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

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:* [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
> <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]
>
>
>
>
>
> _______________________________________________
> radext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/radext