Subject: Re: [Dime] AD Review of dime-qos-parameters-06.txt

From: "Hannes Tschofenig" <[email-masked]>
Date: Sat, 1 Nov 2008 21:01:32 +0200

Hi Dan, 

Thanks for your very detailed review! 

>Hi,
>
>This is the AD review of dime-qos-parameters-06.txt. I believe 
>that the document needs more work before it can be sent to 
>IETF Last Call. I am placing it in Revised ID Needed. 
>
>1. Although it is the work of the DIME Working Group, the 
>document includes in its scope according to the Introduction 
>section the
>definition of parameters    that can be reused for conveying QoS
>information within RADIUS and Diameter. I believe that there 
>is a need to add text that shows how specifically these 
>parameters will be used in each of the two protocols.

The description can be found in documents using this specification. 
For Diameter a description can be found in
http://tools.ietf.org/wg/dime/draft-ietf-dime-qos-attributes/

> Is there 
>a need for any supplementary documents to describe protocol 
>specific mapping and IANA allocations? 
I guess you refer to the IANA consideration section and the ability to
specify new parameters. 
Right? 

>
>2. Was the document reviewed by the RADIUS WG?

We have sent the WGLC announcements to DIME, RADEXT, NSIS, and TSVWG
(and to other SDOs). 

>
>3. This document will trigger again the issue of exceeding the 
>AAA scope of DIAMETER as described by RFC 3588, raised in a 
>number of previous occasions, last by Brian Carpenter in his 
>GenART review for draft-sun-dime-itu-t-rw. I suggest to put 
>text in the Introduction section mentioning the issue of scope 
>and referring to rfc3588bis as an Informational Reference.
No, this document doesn't. When used as described in
http://tools.ietf.org/wg/dime/draft-ietf-dime-qos-attributes/ then it is
totally in line with the scope of Diameter. 

However, when used in
http://www.ietf.org/internet-drafts/draft-ietf-dime-diameter-qos-06.txt then
there are again the same issues as previously raised already. 

>
>4. There are several places in the document where the authors 
>seem to write requirements about the behavior and mode of 
>provisioning of a QoS enabled network. I do not think that an 
>AAA parameters document is a good place for such requirements. 
>I would strongly prefer that the document focuses on 
>describing the QoS parameters carried by AAA protocols, and if 
>examples of usage are left, they be marked clearly as examples.  

This was indeed not the intention. I will search through the document to fix
these 
Cases. 

>
>5. Section 3.2 - Path PLR and Path PER are defined on packet 
>basis, so the claim that they describe the desired bit error 
>rate seems odd. 

Fixed. 

>
>6. Same -'where the PLR is defined to be the PLR added by each 
>such node' and 'the PER is defined to be the PER added by each 
>such node'
>seem to be broken as definitions - maybe that was intended to 
>be define is 'the Path PLR' and 'the Path PER' respectively. 

Fixed. 

>
>7. Section 3.3 - See comment #4 - certainly RFC 2119 keywords 
>usage seems unjustified here.

Fixed. 

>
>8. Section 4.1 and following - it would be good to mention 
>that Length all over this document is expressed in 32-bit words. 
>

Fixed. 

>9. It is not clear why there is a need to defined both TMOD-1 
>and TMOD-2. I suggest to add an explanation. 

>
>10. Section 4.2 - I suggest to add a normative reference to 
>IEEE 754 when referring the first time to single-precision 
>IEEE floating point format. It's a good moment, as the IEEE 
>standard was updated in June 2008, after more than two decades 
>of usage of the precedent version (but this does not affect 
>the way it is used here as far as I can tell)

Do you have a reference to the new standard? 

>
>11. The first phrase in 4.3 should appear also in 4.2 as the 
>two TMOD parameters have similar semantics. 

>
>12. Section 4.5 - there is no reference for the semantic of 
>the Path Jitter parameter value - probably section 3.4 in RFC2215

>
>13. I do not understand what is the reason to include Path 
>Jitter STAT4 (Reserved).

The format was copied from NSIS specifications. I will ask on the NSIS
mailing list for reasons why these parameters got included. 

>
>14. Section 4.6 - I do not believe that a AAA document should 
>include statements like 'The total PLR added across all QoS 
>aware nodes can range as high as 10^-1.'

Fixed. 

>
>15. Section 4.7 - in the first phrase s/PLR/PER/
>
Fixed. 

>16. Section 4.7 - I do not believe that a AAA document should 
>include statements like 'The total PER added across all QoS 
>aware nodes can range as high as 10^-1.'

Fixed. 

>
>17. Section 4.8 - I see no reason to refer here to [RFC2212]

RFC 2212 defines the slack term. 

>
>18. Section 4.8 - s/Path PLR/Slack Term/

Fixed. 

>
>19. Section 4.11 - I am not sure that quoting RFC4412 as a 
>reference for the semantic of the parameter value is fully 
>accurate. It may be good at most to say that what is referred 
>here is the resource-priority policy element 

RFC 4412 creates the registry this document refers to. 
[I-D.ietf-tsvwg-emergency-rsvp] converts the values in that registry from a
textual representation (in the form of, for example, 'dsn.flash') to
numerical values. We had a long discussion between NSIS and TSVWG on who
should create that registry. I did not have an opinion about that issue. 

>
>20. Section 4.11 - This I-D defines similarly ALRP parameter 
>as draft-ietf-tswg-emergency-rsvp and the two documents quote 
>each other with the apparent intent to keep the definitions in 
>sync. However draft-ietf-tswg-emergency-rsvp defines a policy 
>object which is a list of ALRPs, while here there is only one 
>instance. Why the difference? 

We only reference the registry. When one wants to convey multiple values
within RADIUS or Diameter for an authorization request (as an example) then
two separate objects have to be used. 

>
>21. Section 4.11 - if the intent is to keep the definitions 
>here and in draft-ietf-tswg-emergency-rsvp as close as 
>possible what are the ALRP Priority and Reserved octets 
>positions inversed in the two definitions?

When we wrote our document that was the format used in the NSIS documents. 
At that time we referenced the NSIS documents and only later the format was
changed. 
It seems that we have to align it now as well. 
>
>22. Section 4.12 should have a reference to the IANA registry 
>required to be defined for this parameter in Section 6.3. 

Fixed. 

>
>23.  Section 4.12 - what is 'the QoS Desired' object defined here? 
>
>24. Section 4.12 includes text about the behavior of the 
>network that looks mis-placed in an AAA document. 

Your feedback about Section 4.12 is good. Based on what you said I wonder
whether it wouldn't have been cleaner to put the functionality of the Excess
Treatment Parameter into the QoS attribute draft instead. 

I will need to check this with the group. 

>
>25. Section 4.13 could use a reorganization of the 
>description. The 16-bits in the payload have different 
>structure according to the PHB class type - they would better 
>get one generic name and specific descriptions for the three 
>cases covered by the object. 

I re-organized the section to make it more readable.  

>
>26. Section 4.14 - the semantic described in this section is 
>not identical with the one in RFC 4124 which is provided as 
>reference. 4124 says 0 is a reserved value - what semantics 
>does it have here? It is also not clear why this parameter was 
>defined to have an 8-bit representation

I will have to check with the NSIS group on this issue as the parameter
encoding is taken from there. 

>
>27. Section 4.15 - I strongly advice against presenting the 
>usages of the QoS Class parameters here especially in such 
>firm terms as here.
>Actually ITU-T Y.1541 Tables 2 and 3 make clear that these 
>class usages are only guidance (classes 1 to 5) and 
>provisional (classes 6,7). This is completely lost here. I 
>would prefer to just provide a pointer to the ITU-T document 
>and take out all the classes descriptions, or move them in an 
>Appendix, with all necessary description of their guidance and 
>provisional status. 

Sounds good to me. 

>
>28. Section 5 should provide a reference to the IANA registry 
>for Enterprise Numbers

Done. 

>
>29. Section 6.4 - It is not clear why there is a need to 
>create a registry for DSTE Class Type Parameters. If IETF WGs 
>or individuals writing RFCs and running them through the IETF 
>process will be allowed to add or modify values by Standards 
>Actions, this would modify the semantics defined in Section 
>4.14, which does not include any mention of extensibility for 
>these parameters. 

You are entirely correct. 

>
>30. Section 6.5 -  It is not clear why there is a need to 
>create a registry for Y.1541 Class Parameters. Who would take 
>the responsibility of running the Standard Action to modify or 
>add Object class values? In what conditions? When Y.1541 
>changes? In any case, this would modify the semantics defined 
>in Section 4.14, which does not include any mention of 
>extensibility for these parameters. 

Correct as well. 

>
>31. Section 7 - I disagree that this document does not raise 
>any security concerns. Actually the modification or 
>mis-configuration of the QoS parameters carries security 
>threats similar with the configuration operations that would 
>be performed for example in case the objects would be 
>configured by using a protocol like SNMP. QoS degradation may 
>lead to degradation of service that can make access to the 
>network resources difficult or impossible, or running 
>real-time applications impossible.
>We need text that explains what are the sensitive parameters, 
>and the recommended operational and deployment measures to 
>protect against security threats. 

We were planning to have that text in the QoS attribute draft rather than in
this draft. 

>
>32. The description of the [Y.1541] and [Y/1571] references 
>are incomplete. 
I messed it up in the XML2RFC description of the reference. 

Ciao
Hannes

>
>Thanks and Regards,
>
>Dan
>
>
> 
>_______________________________________________
>DiME mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/dime
>

_______________________________________________
DiME mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dime

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 2 Nov 2008 09:43:49 +0100

> -----Original Message-----
>

http://grouper.ieee.org/groups/754/

Dan

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Sat, 8 Nov 2008 23:19:57 +0200

Hi Dan, 

I updated the document again based on your comments: 
* Added a reference to IEEE 754
* Added text regarding the QoS parameter description (including additional
references)
* Adjustments to the header format as discussed on the DIME mailing list

Here is the latest version of the draft: 
http://www.tschofenig.priv.at/svn/draft-tschofenig-dime-diameter-qos/draft-i
etf-dime-qos-parameters-08.txt

Ciao
Hannes

---

From: "Glen Zorn" <[email-masked]>
Date: Sat, 8 Nov 2008 16:51:23 -0800

> http://www.tschofenig.priv.at/svn/draft-tschofenig-dime-diameter-
> qos/draft-ietf-dime-qos-parameters-08.txt

Still looks like (bad) RADIUS to me.

> AAA-DOCTORS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/aaa-doctors

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Sun, 9 Nov 2008 10:52:36 +0200

I really wonder why some of us always have such a strong opinion about the
packet formats. 
What format would you like? 
 
>From: Glen Zorn [mailto:[email-masked]] 
>Sent: 09 November, 2008 02:51
>To: 'Hannes Tschofenig'; 'ext Romascanu, Dan (Dan)'; [email-masked]
>Cc: [email-masked]; [email-masked]
>Subject: RE: [AAA-DOCTORS] [Dime] AD Review of 
>dime-qos-parameters-06.txt
>
>> Hi Dan,
>>

---

From: "Bernard Aboba" <[email-masked]>
Date: Sun, 9 Nov 2008 20:50:09 -0800

Glen Zorn said:

"Still looks like (bad) RADIUS to me."

Can someone explain the relationship of this document to (bad or good)
RADIUS?

Looking at the DIME WG charter, there is an item for the Diameter QoS
application
(http://www.ietf.org/internet-drafts/draft-ietf-dime-diameter-qos-06.txt), 
Which in turn has normative references to QoS Attributes for Diameter
(http://www.ietf.org/internet-drafts/draft-ietf-dime-qos-attributes-08.txt)
and this document.

None of these documents request allocation of any RADIUS attributes, or
describe RADIUS Attribute formats.

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Mon, 10 Nov 2008 08:41:23 +0200

Hi Bernard,

We have currently three documents in DIME that relate to QoS: The Diameter
QoS application specifies, as the name indicates, a Diameter application for
usage with QoS. The QoS attribute draft provides the encoding of classifiers
and AVPs relevant for QoS. The actual QoS parameters for an initial profile
are defined in the QoS parameters draft. These drafts in DIME focus on
Diameter usage. We have dependencies from the 3GPP on these documents. 

It is, however, quite easy to imagine that QoS parameters might also be
useful in a RADIUS context. In fact we had a document some time ago that
described how to re-use the same QoS parameter format for RADIUS. The
document is, however, expired now and would need a significant update given
the changes we have seen in the DIME documents. 

When it comes to the format then our believe so far was that the format of
the QoS parameters was not really important as the authorization decision
and related admission control procedures by the AAA server will require code
changes. Code changes to the AAA client will be needed as well since the
parameters need to be feed into a Traffic Control module.

Ciao
Hannes

>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Bernard Aboba
>Sent: 10 November, 2008 06:50
>To: 'ext Romascanu, Dan (Dan)'; [email-masked]
>Cc: [email-masked]; [email-masked]
>Subject: Re: [AAA-DOCTORS] [Dime] AD Review of 
>Can someone explain the relationship of this document to (bad 
>or good) RADIUS?
>
>Looking at the DIME WG charter, there is an item for the 
>Diameter QoS application 
>None of these documents request allocation of any RADIUS 
>attributes, or describe RADIUS Attribute formats.  
>
>
>

---

From: "Glen Zorn" <[email-masked]>
Date: Mon, 10 Nov 2008 14:43:14 -0600

> the changes we have seen in the DIME documents.

It's very simple: if these attributes/AVPs are meant to be used in RADIUS
then do the work in radext (or at the very least, follow the RADIUS design
guidelines); note that those attributes could be carried w/o any fuss in
Diameter as well.  If they are meant to be used in Diameter, then design
them as Diameter AVPs, using the features that Diameter enables (grouped
AVPs, etc.).  What you have done is neither, and have (predictably) ended up
with a mess.

---

From: Jan Engelhardt <[email-masked]>
Date: Tue, 11 Nov 2008 07:52:37 +0100 (CET)

>AVPs, etc.).  What you have done is neither, and have (predictably) ended up

In that case, should not RADIUS backwards compatibility be removed
from the rfc3588bis too?
_______________________________________________
DiME mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dime

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Tue, 11 Nov 2008 09:45:07 +0200

Glen, 

>It's very simple: if these attributes/AVPs are meant to be 
>used in RADIUS then do the work in radext (or at the very 
>least, follow the RADIUS design guidelines); note that those 
>attributes could be carried w/o any fuss in Diameter as well.  
>If they are meant to be used in Diameter, then design them as 
>Diameter AVPs, using the features that Diameter enables 
>(grouped AVPs, etc.).  What you have done is neither, and have 
>(predictably) ended up with a mess.

You obviously don't care too much about my arguments. 

There are three things: 

* The QoS can be carried in RADIUS and Diameter. 

* This approach is totally inline with the RADIUS design guidelines. 
The RADIUS design guidelines document does not require every info
element to following the standard encoding, as you know. 

* Where todo certain documents is a matter of taste and not really a bit
issue (at least so far). 
We had a RADIUS draft, as I mentioned, but we focused all our efforts on
the Diameter work. 

Ciao
Hannes

---

From: "David B. Nelson" <[email-masked]>
Date: Tue, 11 Nov 2008 07:02:39 -0500

Hannes Tschofenig writes...

> element to following the standard encoding, as you know.

The RADIUS Design Guidelines document is pragmatic.  It *strongly* suggests
(SHOULD not MUST) that attributes which could reasonably be implemented in a
data-dictionary driven RADIUS server as data dictionary entries be encoded
in the standard encoding.  Exceptions are made for (a) attributes which
would absolutely require code changes in the server, (b) attributes used as
authentication credentials payloads, and (c) attributes which are opaque to
the RADIUS server and RADIUS client.

This is not a matter of aesthetics or personal design choice -- it is
dictated by the usage.

BTW, *my* definition of opaque means that the data field of the attribute,
as described in the RADIUS document is a single string, whose contents are
defined in some non-RADIUS document.  Once the RADIUS attribute definition
starts breaking the attribute data payload into sub-fields it really isn't
opaque anymore.

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Tue, 11 Nov 2008 14:20:58 +0200

Hi David, 

>The RADIUS Design Guidelines document is pragmatic.  It 
>*strongly* suggests (SHOULD not MUST) that attributes which 
>could reasonably be implemented in a data-dictionary driven 
>RADIUS server as data dictionary entries be encoded in the 
>standard encoding.  Exceptions are made for (a) attributes 
>which would absolutely require code changes in the server, (b) 
>attributes used as authentication credentials payloads, and 
>(c) attributes which are opaque to the RADIUS server and RADIUS client.

I don't think that attributes can be opaque to the RADIUS client since the
client has todo something with them. 

The attributes are opaque to the RADIUS server and the respective component
(dealing with policy-based admission control) needs to be implemented (=code
changes). 

>
>This is not a matter of aesthetics or personal design choice 
>-- it is dictated by the usage.
>
>BTW, *my* definition of opaque means that the data field of 
>the attribute, as described in the RADIUS document is a single 
>string, whose contents are defined in some non-RADIUS 
>document.  Once the RADIUS attribute definition starts 
>breaking the attribute data payload into sub-fields it really 
>isn't opaque anymore.

Currently, we do not yet define the RADIUS attributes (and that would be a
RADEXT document) but they will then be defined as a string and within that
string there will be the content of the QoS parameters. 

Ciao
Hannes

---

From: <[email-masked]>
Date: Tue, 11 Nov 2008 16:23:46 +0200

Hi,

Would it be useful to add some text to the draft to explain
and justify the usage of the encoding format that you've chosen
for the qos parameters?

It is not obvious why is it be better to define separate
qos parameter header and formats instead of using normal Diameter
AVP header and formats to transfer the data.

BR,
Mikko

>From: [email-masked] [mailto:[email-masked]] On 
>Behalf Of ext Hannes Tschofenig
>Sent: 11 November, 2008 14:21
>To: 'David B. Nelson'; [email-masked]
>Subject: Re: [Dime] [AAA-DOCTORS] AD Review of

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Tue, 11 Nov 2008 16:52:56 +0200

Hi Mikko, 

the reason is that we essentially "copied" the format defined in the NSIS
group as they have been working on the definition of the QoS parameters. 
In the past folks in DIME did not have a problem with the format and I also
specifically asked for feedback on this issue. 

In fact, I even compiled a version of the draft with Diameter encoding once:
http://tools.ietf.org/html/draft-ietf-dime-qos-parameters-05
As one can see from that document it isn't totally easy either to use
Diameter AVPs as the format that is being referenced comes directly from a
various RFCs and there is the obvious question whether the format should be
taken as is or also "translated". For example, take a look at Section
3.11.3. of http://tools.ietf.org/html/draft-ietf-dime-qos-parameters-05
(PHB-Class AVP). 

Ciao
Hannes

>From: [email-masked] [mailto:[email-masked]] 
>Sent: 11 November, 2008 16:24
>To: [email-masked]; [email-masked]
>Subject: RE: [Dime] [AAA-DOCTORS] AD Review of 
>and justify the usage of the encoding format that you've 
>chosen for the qos parameters?
>
>It is not obvious why is it be better to define separate qos 
>parameter header and formats instead of using normal Diameter 
>>>*strongly* suggests (SHOULD not MUST) that attributes which could 
>>>reasonably be implemented in a data-dictionary driven RADIUS 
>server as 
>>>data dictionary entries be encoded in the standard encoding.  
>>>Exceptions are made for (a) attributes which would 
>absolutely require 
>>>code changes in the server, (b) attributes used as authentication 
>>>credentials payloads, and
>>I don't think that attributes can be opaque to the RADIUS 
>client since 
>>the client has todo something with them.
>>
>>The attributes are opaque to the RADIUS server and the respective 
>>component (dealing with policy-based admission control) needs to be 
>>implemented (=code changes).
>>
>>>

---

From: "Glen Zorn" <[email-masked]>
Date: Tue, 11 Nov 2008 16:42:34 -0600

> http://tools.ietf.org/html/draft-ietf-dime-qos-parameters-05

As luck would have it, I think that was the one I read :-) -- no wonder I
had no problem.

> 3.11.3. of http://tools.ietf.org/html/draft-ietf-dime-qos-parameters-05

What's wrong with it?  It seems at least as comprehensible as section 4.13
of -06...

...

---

From: "Glen Zorn" <[email-masked]>
Date: Tue, 11 Nov 2008 17:02:11 -0600

Tschofenig, Hannes (NSN - FI/Espoo) [mailto:// [email-masked]]

> * The QoS can be carried in RADIUS and Diameter.

If that is the intention, then these should be RADIUS attributes.

> element to following the standard encoding, as you know.

I think that you've got at least two people who disagree with you on that.

> * Where todo certain documents is a matter of taste and not really a

??!  You're not seriously suggesting that Diameter AVPs & RADIUS attributes
are technically equivalent, are you?

> We had a RADIUS draft, as I mentioned, but we focused all our efforts

That's the main problem: the -05 draft contained Diameter AVPs but -06
doesn't.  In fact, this is exactly the kind of application for which
Diameter was designed & I find it rather annoying what's being proposed are
poorly designed RADIUS attributes masquerading as Diameter AVPs.

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Wed, 12 Nov 2008 09:15:19 +0200

Hi Glen 

>> In fact, I even compiled a version of the draft with 
>Diameter encoding
>> once:
>As luck would have it, I think that was the one I read :-) -- 
>no wonder I had no problem.

That's indeed funny. 

>> For 
>> example, take a 
>> look at Section 3.11.3. of 
>What's wrong with it?  It seems at least as comprehensible as 
>section 4.13 of -06...

How should I understand this reasoning? 

We don't win anything with the Diameter based encoding since the
component of the Diameter server still has to implement code for
decoding of the following parameter: 

       0                   1
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      PHD ID CODE      |0 0 X 0|
      +---+---+---+---+---+---+---+---+

This is as good as the other encoding. 

Ciao
Hannes

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Wed, 12 Nov 2008 09:09:31 +0200

I agree with your description, David. 

>[mailto:[email-masked]] On Behalf Of ext David B. Nelson
>Sent: 11 November, 2008 16:14
>To: [email-masked]
>Hi Hannes,
>Maybe this is a matter of semantics.  Just as the RADIUS 
>Server does not comprise the complete set of server-side AAA 
>functionality (e.g. policy servers, location servers, 
>authentication back-ends, etc. are logically separate), the 
>RADIUS Client does not comprise the complete set of AAA 
>functionality in the NAS.  The RADIUS Client delivers 
>authorization information to the components of the NAS that 
>enforce access control.
>
>When you define the RADIUS Server and RADIUS Client in this 
>narrow sense, i.e. the code that deals with RADIUS PDUs, I 
>think you can claim the certain attributes are opaque to the 
>RADIUS Client (but certainly not to the NAS).
>
>-- Dave
>
>

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Wed, 12 Nov 2008 09:24:51 +0200

Hi Glen, 

>> Glen,
>> 
>> >It's very simple: if these attributes/AVPs are meant to be used in 
>> >RADIUS then do the work in radext (or at the very least, follow the 
>> >RADIUS design guidelines); note that those attributes could be 
>> >carried w/o any fuss in Diameter as well.
>> >Diameter AVPs, using the features that Diameter enables (grouped 
>> >AVPs, etc.).  What you have done is neither, and have

I counted one person. 

>
>> 
>> * Where todo certain documents is a matter of taste and not really a 
>> bit issue (at least so far).
>
>??!  You're not seriously suggesting that Diameter AVPs & 
>RADIUS attributes are technically equivalent, are you?

For example: Take a look at 
http://www.ietf.org/rfc/rfc4675.txt
In Section 4 it also defines the corresponding Diameter AVPs. 

Take a look at http://tools.ietf.org/html/draft-ietf-mip6-radius-06
This document was started in MIP6 and will be finished in MEXT. 

The decision on where todo certain work has been made on a case-by-case
basis and there isn't really any problem with it. 

All this has nothing todo with the relationship between RADIUS and
Diameter. 

>
>
>> We had a RADIUS draft, as I mentioned, but we focused all 
>our efforts 
>> on the Diameter work.
>
>That's the main problem: the -05 draft contained Diameter AVPs 
>but -06 doesn't.  In fact, this is exactly the kind of 
>application for which Diameter was designed & I find it rather 
>annoying what's being proposed are poorly designed RADIUS 
>attributes masquerading as Diameter AVPs.

Based on what you said at the beginning of your mail: Would an encoding
of the QoS parameters according to
http://www.ietf.org/internet-drafts/draft-ietf-radext-extended-attribute
s-05.txt make you "happy"? 

Ciao
Hannes

---

From: Avi Lior <[email-masked]>
Date: Fri, 14 Nov 2008 13:54:40 -0500

Folks are throwing around terms like RADIUS server and RADIUS client all over the place.

What is really lacking is a defintion - that we can all agree - of what is a RADIUS Server and a RADIUS Client.

> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of David B. Nelson
> Sent: November 11, 2008 9:14 AM
> To: [email-masked]
> --
> to unsubscribe send a message to
> [email-masked] with the word 'unsubscribe' in
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>