Subject: [Dime] WGLC Comments on draft-ietf-dime-rfc3588bis-17.txt, pp. 7-13

From: "Glen Zorn" <[email-masked]>
Date: Fri, 5 Jun 2009 17:30:13 +0700

EDITORIAL

Section 1
Change "Over time, AAA was needed on many new access technologies," to "Over
time, AAA support was needed for many new access technologies," 

Under "Server-initiated messages", change "Support for server-initiated
messages is mandatory in" to "Support for server-initiated messages is
mandatory in Diameter."

Under "Transition support", suggest changing removing the reference to RFC
4005 by changing "This capability, described in [RFC4005], enables Diameter
support" to "This capability enables Diameter support";  the translation
mechanism in 4005 is broken & will hopefully soon be replaced.

Under "Capability negotiation", change "attribute-value pairs" to
"Attribute-Value Pairs (AVPs)".

Section 1.1
Change "Attribute Value Pairs (AVPs)" to "AVPs".

Change "All data delivered by the protocol is in the form of an AVPs." to
"All data delivered by the protocol is in the form of AVPs."

Suggest changing "AVPs may be added arbitrarily to Diameter messages, so
long as the requirements of the message's ABNF (Section 3.2) are met." to
"AVPs may be arbitrarily added to Diameter messages, the only restriction
being that the Augmented Backus-Naur Form (ABNF, [RFC5234]) Command Code
syntax specification (Section 3.2) is satisfied." and deleted the
(incorrect) ABNF definition in section 1.2

Change "service specific" to "service-specific"

Change "The Diameter base protocol provides the minimum requirements needed
for a AAA protocol, as required by [RFC2989]." to "The Diameter base
protocol satisfies the minimum requirements for a AAA protocol, as specified
by [RFC2989]." 

Section 1.1.1

The subject of this subsection is, by definition, a moving target; the list
of applications is likely to be obsolete almost as soon as the document is
published.  It would be really nice if we could just point to a stable
reference (maybe a BCP?) that would be up-to-date (almost) all the time and
just consist of a slightly modified version of this section + references.

Change "Note that this document obsoletes [RFC3588]" to "Note that this
document obsoletes RFC 3588"; I doubt that it obsoletes the _reference to_
RFC 3588 ;-).

Section 1.1.3

In the first sentence, is "deprecates" really the word we want to use?  How
about "obsoletes" instead?

Change "introduced in this document focuses" to "introduced in this document
focus"

Change "An overview of some the major changes are shown below" to "An
overview of some the major changes is given below"

Change "Inband-Security AVP exposes certain security risk" to
"Inband-Security AVP creates certain security risks"

Change "for vendor-specific uses.  The new specification relaxes the
allocation of command codes for vendor specific uses.  See Section 11.2.1
for details." to "for vendor-specific uses (see Section 11.2.1 for details).

Change "widely used discovery schemes.  The rest has been deprecated.  (See
Section 5.2 for details)." to "widely used discovery schemes; the rest have
been deprecated (see Section 5.2 for details)."

Change "clarification on election process" to "clarification of the election
process"

Change "Result-Code AVP values etc." to "Result-Code AVP values, etc."

Section 1.2

Is the definition of AAA really necessary?  Seems like the acronym was
already defined...

If my rewrite suggestion regarding section 1.1 (above) is not accepted,
change "Abstracted Backus-Naur Form [RFC5234]" to "Augmented Backus-Naur
Form [RFC5234]".  Maybe we could use a second-order BNF but we don't have
one ;-)

~ gwz

Half a loaf is better than no loafing at all.
  --T-Bone Slim

---

From: Victor Fajardo <[email-masked]>
Date: Fri, 05 Jun 2009 08:43:42 -0400

Thanks. I'll incorporate the changes.

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

---

From: "Glen Zorn" <[email-masked]>
Date: Fri, 5 Jun 2009 20:42:47 +0700

...

> > just consists of a slightly modified version of this section +
> references.
> >

Any thoughts on this idea?

---

From: Victor Fajardo <[email-masked]>
Date: Fri, 05 Jun 2009 10:04:38 -0400

I tend to agree with you specially since majority of this text refers to 
diameter applications. I guess the original assumption when this section 
was first written was that there will be very few diameter applications 
and its worthwhile referencing them in the base to show their 
association. Since this is no longer the case, this section does not 
seem useful other than the reference for the transport profile.

> ...
>
>   
>>> Section 1.1.1
>>>
>>> The subject of this subsection is, by definition, a moving target;
>>>       
>> the list
>>     
>>> of applications is likely to be obsolete almost as soon as the
>>>       
>> document is
>>     
>>> published.  It would be really nice if we could just point to a
>>>       
>> stable
>>     
>>> reference (maybe a BCP?) that would be up-to-date (almost) all the
>>>       
>> time and
>>

---

From: Qin Wu <[email-masked]>
Date: Thu, 18 Jun 2009 18:33:51 +0800

Hi,
May I have some comments on draft-ietf-dime-rfc3588bis-17?

Regards!
-Qin
[snip]
"
1.  Introduction
.............
Server-initiated messages

While RADIUS server-initiated messages are defined in [RFC5176],
support is optional.  This makes it difficult to implement
features such as unsolicited disconnect or reauthentication/
reauthorization 
"
 [Qin] Reauthentication/reauthoriation is not necessary to be server-initiated?
  e.g., In RFC5296"EAP Extensions for EAP Re-authentication Protocol (ERP)
   ", EAP Re-authentication is host/peer initiated, isn't it?
   So it is not very accurate to say the reauthentcation is server-initiated .

"
 on demand across a heterogeneous deployment.
 Support for server-initiated messages is mandatory in
"    
[Qin]: The last sentence is not complete. I guess we should say 
  "
To tackle this issue, support for server-initiated message is mandaroty in Diameter.
   "

[snip]
"
Peer discovery and configuration

RADIUS implementations typically require that the name or address
of servers or clients be manually configured, along with the
corresponding shared secrets.  This results in a large
administrative burden, and creates the temptation to reuse the
RADIUS shared secret, which can result in major security
vulnerabilities if the Request Authenticator is not globally and
temporally unique as required in [RFC2865].  Through DNS, Diameter
enables dynamic discovery of peers. 
"

[Qin]: In order to align the contents in this paragraph with other paragraphs, the similar anchor point should be appended, i.e., 
      s/
      "
      Diameter enables dynamic discovery of peers. 
      "
      /
      "
      Diameter enables dynamic discovery of peers (section 5.2).
      "

[snip]
"
1.1.1.  Description of the Document Set
[snip]
"
   The Mobile IPv4 [RFC4004] application defines a Diameter application
   that allows a Diameter server to perform AAA functions for Mobile
   IPv4 services to a mobile node.
"
   [Qin]: Do we need to add some references to Diameter support for Mobile IPv6 
    and Diameter support for Proxy Mobile IPv6? 

[snip]
"
2.9.  Diameter Path Authorization

   As noted in Section 2.2, Diameter provides transmission level
   security for each connection using TLS.  Therefore, each connection
   can be authenticated, replay and integrity protected.
"
   [Qin]: In which situation the Diameter Path Authorization will be used?
   Diameter Path Authoirzation will be performed between the Diameter Client and server?
   or between different Proxys or Relays? What is the main difference between Path authorization and service authorization?
"
   In addition to authenticating each connection, each connection as
   well as the entire session MUST also be authorized.  Before
   initiating a connection, a Diameter Peer MUST check that its peers
   are authorized to act in their roles.  For example, a Diameter peer
   may be authentic, but that does not mean that it is authorized to act
   as a Diameter Server advertising a set of Diameter applications.

   Prior to bringing up a connection, authorization checks are performed
   at each connection along the path.  Diameter capabilities negotiation
   (CER/CEA) also MUST be carried out, in order to determine what
   Diameter applications are supported by each peer. 
"

 [Qin]: What's the relationship between capabilities negotiation and Path Authorization?
 Why we mention capability negotation in this section?

[snip]
"
8.  Diameter User Sessions
[snip]
"
   An access device that does not expect to send a re-authorization or a
   session termination request to the server MAY include the Auth-
   Session-State AVP with the value set to NO_STATE_MAINTAINED as a hint
   to the server.  
"
 [Qin] 
What does the re-authorization means here? What's the difference between re-authorization and re-authentication? 
 [Qin] 
Why does the server  not maintain the state for Diameter User session  in some situation mentioned above?
[snip]
"
8.3.  Server-Initiated Re-Auth

   A Diameter server may initiate a re-authentication and/or re-
   authorization service for a particular session by issuing a Re-Auth-
   Request (RAR).
"
[Qin] Can you provide some reference as regarding this mechanism?
"
   For example, for pre-paid services, the Diameter server that
   originally authorized a session may need some confirmation that the
   user is still using the services.
"
[Qin] If the security information(e.g., keys) is expired, do we need to depend on
 Server-Initiated Re-auth to renew the security information? In this case, it seems
 that the Client also can initiate this Re-auth?
"
   An access device that receives a RAR message with Session-Id equal to
   a currently active session MUST initiate a re-auth towards the user,
   if the service supports this particular feature.  Each Diameter
   application MUST state whether service-initiated re-auth is
"
   [Qin]: s/service-initiated/server-initiated
"
   supported, since some applications do not allow access devices to
   prompt the user for re-auth.
"

---

From: Victor Fajardo <[email-masked]>
Date: Thu, 18 Jun 2009 09:21:47 -0400

Hi Qin,

Thanks for the review.

>    So it is not very accurate to say the reauthentcation is server-initiated .

mmm ... the statement above is just giving an example of 
server-initiated messages. i don't think it stating that re-authz are 
server-initiated only.

> To tackle this issue, support for server-initiated message is mandaroty in Diameter.

Ok.

>       Diameter enables dynamic discovery of peers (section 5.2).

Ok.

>     and Diameter support for Proxy Mobile IPv6? 

In reference to Glen's comments, I actually would like to trim down this 
section so that it does not refer to any diameter applications. There 
are and will be very many diameter applications and I don't think it's 
useful to iterate them. I think its best just to describe a general 
relationship of diameter to the transport profile.

>    or between different Proxys or Relays? What is the main difference between Path authorization and service authorization?

path authorization can be performed between any diameter peers (clients, 
servers, proxy/relay) to verify if they can do what they claim to do; 
i.e. through authorization cerficates. so path authorization can also 
deal with validating the application a diameter node supports and 
possibly its role for that application. AFAIK, service authorization is 
a concept used within the diameter application itself and is independent 
of path authorization.

>  Why we mention capability negotation in this section?
see above.

we mention it here because the capabilities exchange tells you the 
applications a peer support and the part of the path authorization helps 
you verify whether the peer can really do what it claim to do; i.e. 
through authorization certificates.

> What does the re-authorization means here? What's the difference between re-authorization and re-authentication? 

In this case, re-authorization is tied to a session. if a user is not 
expected to ask for re-authorization, then the server may not need to 
keep state. re-authorization and re-authentication are two(2) different 
concepts ... one deals with policing and the other deals with proving 
your identity again.

> Why does the server  not maintain the state for Diameter User session  in some situation mentioned above?

see above.

> [Qin] Can you provide some reference as regarding this mechanism?

I'm guessing diameter credit-control has server-initiated RAR ...

>  that the Client also can initiate this Re-auth?

Yes the client can perform re-auth in this scenario. The base protocol 
does not limit what the diameter applications can do. it simply provides 
a framework for it.

>    prompt the user for re-auth.

Ok.

regards,
victor

---

From: Qin Wu <[email-masked]>
Date: Sun, 21 Jun 2009 11:33:19 +0800

Hi, Vicotor:
Thank for your feedback. I have a few more followup comments below, Please see inline.

Regards!
-Qin
----- Original Message ----- 
From: "Victor Fajardo" <[email-masked]>
To: "Qin Wu" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, June 18, 2009 9:21 PM
Subject: Re: [Dime] Review of draft-ietf-dime-rfc3588bis-17

> server-initiated messages. i don't think it stating that re-authz are 
[Qin]:  As described in draft-ietf-dime-rfc3588bis-17,
"
This makes it difficult to implement features such as unsolicited disconnect or reauthentication/ reauthorization 
"
It seems reauthentication/reauthorization is a generic feature used here which, I am afraid, does not include EAP re-authentification case
described in RFC5296. In this sense, I would like to suggest reword as:
"
This makes it difficult to implement features such as unsolicited disconnect or reauthentication/ reauthorization for Credit control.
"
[snip]

> I'm guessing diameter credit-control has server-initiated RAR ...

[Qin]
Does it seem confusion to use the terminology "Re-Auth" in Credit Control  which conflicts with
the terminology "Re authentication" used in the RFC5296 or Diameter Re-authentication WG draft?
i.e, Does Re-auth in Credit control has the same meaning as the Re-auth in the EAP reauthentication described in the RFC5296?

> does not limit what the diameter applications can do. it simply provides 

[Qin] As you mentioned above, the credit-control has server-initiated RAR, it seems the 
server-initiated RAR has different meaning from what I examplified above, hasn't it?

---

From: "Reith, Lothar" <[email-masked]>
Date: Sun, 21 Jun 2009 23:54:06 +0200

Dear all,

please find below a list of comments regarding the Last Call on: draft-ietf-dime-qos-attributes (Quality of Service Attributes for Diameter) to Proposed Standard

Where applicable, I have stated the issue and a proposed solution to fix the issue.

1. issue:  in Section 3.1 it is stated that
"QoS Resources AVP .......describes a list of policies" 

however, the ABNF definition in the line below specifies that the QoS Resource AVP contains a list of QoS-Rules. 

proposed solution: replace "describes a list of policies" by  "contains a list of QoS-Rules"

Background:
The question is if the term policies and QoS-Rules are meant synonymous in the context of the document. If that is the case, I suggest to replace the term "policies" with "Qos-Rules", as it is the only occurance of that term within the document. If that is not the case,  the meaning of the term policy in this document needs be defined, given that the term "policy" is somewhat overloaded. For example, one could define, that the terms "policy" and "QoS-Rule" are being used synonymously in the context of the document, except when referring to RFC5226 as a policy. Or one could state that a "QoS-Rule" is a type of "policy". 

Alternative Solution: replace "describes a list of policies" by "contains a list of policy rules" 

2.  issue: section 4.1.8.23 discusses Ethernet "user-priority".  I would recommend to review with IEEE on this to verify if "user-priority" or "P-bits" would be the most appropriate term. In addition, there seems to no consideration yet for the "drop eligibility indicator" contained in an S-Tag with Ethertype 0x88a8. It should be possible to formulate a QoS-Rule which considers the "drop eligibility indicator". Also it should be possible to formulate a mark action, which sets the value of the  "drop eligibility indicator" bit to 1. Along these lines, it should also be possible to formulate a QoS-Rule which considers MPLS EXP Bits of an incoming packet. And it should be possible to mark MPLS EXP bits.

3. issue in section 4.2.1: charging granularity not compliant with consumer protection legislation (at least in Germany)
Proposed Solution:  I would recommend to multiply the values by 10, in order to arrive at a granularity of one tenth of a second (split-second). This would allow to comply with some consumer protection regulations in the area of charging accuracy, such as a "telecommunication customer protection law" effective in Germany. I know of one voice switch vendor, who had to reprogramm his voice-switch accounting software because of that law, as a metering granularity of one second was not good enough to meet the legal demands in all cases. This was due to the possible errors in measuring the time at the start of a call and at the end of a call could add up to more than one second, even though the time measurement itself had a granularity of one second. As a minimum, the range must be doubled to a measurement granularity of a half-second, in order to be on the safe side regarding compliance with this law.

4.issues in section 5.1 the actions drop, shape and mark may require some further scrutiny and refinement

4.1 Issue regarding the drop action: Drop action does not differentiate, if the dropped packet shall get accounted.
one possible solution (not necessary the proposed solution): differentiate between
- drop without counting, i.e. drop without charging for the delivery to the point, where the packet gets dropped, because the packet did not get delivered to the customer, such as discarding unsolicited out of profile downstream traffic from some source in the Internet.
- drop after counting, i.e. drop with charging for the delivery of the packet to the point where it got discarded (if legally allowed). This may be applicable to out of profile upstream traffic.

4.2 Issue regarding a lack of unambiguity of the definition of the shape action:
- shape to which token bucket size and depletion rate?
- which bytes of the incoming packet count for depleting the token bucket? All bytes of the layer 2 Frame in case of a QoS-Rule at the Ethernet layer, where an IP header may not even be present? In this context: Is the term bandwidth in the "bandwidth AVP" defined as "net data rate" as in ANCP, or differently defined or undefined? 

4.3. Issue regarding the completeness of the scope of the mark action:
- only TOS byte, or also MPLS EXP bits and Ethernet P-bits ?
- only absolute mark, or also remarking rule  that depends on the previous setting the field?
Proposed solution regarding the first item: split the mark action into 3 different mark actions,  mark-TOS byte, mark-MPLS_EXP-bit and mark-P-bits. Consider to allow the presence of multiple mark actions in a single QoS-Rule. 
Proposed solution regarding the second item: Add actions for re-mark-TOS byte, re-mark-MPLS_EXP-bit and re-mark-P-bits, where the result of the re-mark-action depends on the former setting of the field being re-marked.

5. Issue in section 5.4 I do not quite understand the semantic differences between QoS Available, QoS Authorized and QoS Reserved, in particular if QoS Reserved is already accounting relevant. 
Solution: Verify and make sure that there is indeed a semantic difference, and that accounting for QoS Reserved is compliant with consumer protection laws.

6. issue in section 7.5 there is an example on how this may apply in combination with Diameter Credit Control, and it is stated there that " In this case the User is charged as soon as the Service Element (CC client) receives the service request. "
Proposed solution: Verify if  a procedure which starts charging without knowing, if the the QoS-Resource can actually be allocated does not violate consumer protection laws.

7. reading further on in this short section 7.5 it states the following:
 "In this case the client uses the "QoS-Desired" QoS-Semantics parameter in the QoS-Resources AVP that it sends to the Accounitng server. The server responds with a "QoS-Available" QoS-Semantics parameter in the QoS-Resources AVP"

This raises some doubts if the "accounting server" acts as an authorization server. There should be clear separation of accounting and authorization.
Proposed solution: Change the wording to make clear, that the accounting server does not authorize anything, otherwise, do not call it an accounting server,  but rather an authorization and accounting server, which would imply that both functions are combined in one server (which in large implementations is usually not the case). 

8. reading further on, there is a  Message shown   "CCA (Granted-Units, QoS-Resources(QoS-Authorized))"  which makes me wonder, what is being authorized here with DCC. Is it an authorization for a certain number of granted-Units delivered with a higher QoS and charged extra using a one time charge because of delivering these granted units with higher QoS?

If that would be the case,   it would  in my view be a bad practice, as the one-time charge mechanism would effectively be used for session based charging, but without the reservation mechanism. What happens, if the Granted-Units cannot be delivered with the higher QoS, say in case of an outage? Session based charging can handle this by means of not confirming the reservation within a time limit.  It would require extra complex logic to handle this situation, where the One-Time charge would have to be cancelled or compensated by a one-time bonus of same amount.

Proposed solution for issue 8: Use another example, which does not suggest to re-invent session based online charging using one-time charging events.

Best Regards,

Lothar Reith

Competence Practice Communications Technology

Detecon International GmbH 
Oberkasseler Str. 2 
53227 Bonn - Germany
 
Phone: +49 228 700 2958
Mobile: +49 175 580 4892
Fax: +49 228 700 2107
mailto:[email-masked] 
http://www.detecon.com 

Detecon International GmbH
Aufsichtsrat: Hans-Jürgen Wickenhöfer (acting)
Geschäftsführung: Dr. Klaus Hofmann, Andreas Baumann
Handelsregister: Amtsgericht Bonn HRB 2093
Sitz der Gesellschaft: Bonn

==========================================================================================================================================================================
[Dime]Last Call: draft-ietf-dime-qos-attributes (Quality of Service Attributes for Diameter) to Proposed Standard

    * To: IETF-Announce <ietf-announce at ietf.org>
    * Subject: [Dime] Last Call: draft-ietf-dime-qos-attributes (Quality of Service Attributes for Diameter) to Proposed Standard
    * From: The IESG <iesg-secretary at ietf.org>
    * Date: Mon, 8 Jun 2009 07:08:51 -0700 (PDT)
    * Cc: dime at ietf.org
    * Delivered-to: dime at core3.amsl.com
    * List-archive: <http://www.ietf.org/mail-archive/web/dime>
    * List-help: <mailto:[email-masked]?subject=help>
    * List-id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
    * List-post: <mailto:[email-masked]>
    * List-subscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:[email-masked]?subject=subscribe>
    * List-unsubscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:[email-masked]?subject=unsubscribe>
    * Reply-to: ietf at ietf.org

The IESG has received a request from the Diameter Maintenance and 
Extensions WG (dime) to consider the following document:

- 'Quality of Service Attributes for Diameter '
   <draft-ietf-dime-qos-attributes-12.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
ietf at ietf.org mailing lists by 2009-06-22. Exceptionally, 
comments may be sent to iesg at ietf.org instead. In either case, please 
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-dime-qos-attributes-12.txt

IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=16192&rfc_flag=0

    * Prev by Date: [Dime] WGLC Comments on draft-ietf-dime-rfc3588bis-17.txt, pp. 14-20
    * Next by Date: Re: [Dime] New draft for Diameter ERP: poll for adoption
    * Previous by thread: [Dime] WGLC Comments on draft-ietf-dime-rfc3588bis-17.txt, pp. 14-20
    * Next by thread: [Dime] Fwd: New Version Notification for draft-korhonen-dime-mip6-feature-bits-01
    * Index(es):
          o Date
          o Thread

Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.

---

From: Victor Fajardo <[email-masked]>
Date: Mon, 22 Jun 2009 09:46:26 -0400

Hi Qin,

> This makes it difficult to implement features such as unsolicited disconnect or reauthentication/ reauthorization for Credit control.

I'm not sure I fully understand. Do you mean you don't want a generic 
statement because it would not include EAP ? I was thinking the 
opposite. A generic statement would encompass a broader scope right ?

> i.e, Does Re-auth in Credit control has the same meaning as the Re-auth in the EAP reauthentication described in the RFC5296?

I'm not too sure about the history for Diameter CC nor the reasoning for 
its terminology. I guess the more pertinent question is how this relates 
to bis. At least for bis the term "Re-Auth" can indicate authorization 
and/or authentication.

> server-initiated RAR has different meaning from what I examplified above, hasn't it?

Ok. Then I'm not really sure what your comparing re-auth againts. Are 
you comparing client vs. server re-auth ? In that case, is there 
anything broken in the bis that relates to this ?

regards,
victor

---

From: Qin Wu <[email-masked]>
Date: Tue, 23 Jun 2009 15:49:53 +0800

Hi, Victor:
Please see inline.
----- Original Message ----- 
From: "Victor Fajardo" <[email-masked]>
To: "Qin Wu" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, June 22, 2009 9:46 PM
Subject: Re: [Dime] Review of draft-ietf-dime-rfc3588bis-17

> opposite. A generic statement would encompass a broader scope right ?

[Qin]: Surely we need the generic statement here. However as described in the section 5.5 of RFC4006, the reauthentication/ reauthorization mentioned in the section 8.3 of draft-ietf-dime-rfc3588bis-17 is initiated by the server and only applicable for real-time credit control and can not be applicable for EAP Re-authentication described in RFC5296 or Diameter Support for EAP Re-authentication Protocol. Because EAP Re-authentication is initiated by the Client/Peer. That's my difficulty. What am I missing?

> to bis. At least for bis the term "Re-Auth" can indicate authorization 

[Qin]: I agree. However the "Re-Auth" is also used in the Diameter Support for EAP Re-authentication Protocol.
It seems they have different meanings and scope.
 
> anything broken in the bis that relates to this ?

[Qin]: See above.
Since Re-authentication is defined in the credit control in the RFC 4006, I am just confused if the same terms"Re-authentication" is used in the Diameter ERP as well  If the folks have no difficulty to distinguish the Re-authentication in the Diameter ERP from the Reauthentication in the Credit control application,
then I have no strong feeling against it.
If my understanding is not right, please correct me.

---

From: jouni korhonen <[email-masked]>
Date: Wed, 24 Jun 2009 11:26:11 +0300

Hi,

Just a quick note here..

On Jun 23, 2009, at 10:49 AM, Qin Wu wrote:

[snip]

> Since Re-authentication is defined in the credit control in the RFC  
> 4006, I am just confused if the same terms"Re-authentication"

We are talking about RAR command here, right? That is defined in Base  
protocol and used in several places, including 4006, 4005, and a bunch  
of SDO specs defined applications.

> is used in the Diameter ERP as well  If the folks have no difficulty  
> to distinguish the Re-authentication in the Diameter ERP from the  
> Reauthentication in the Credit control application,

Use different application-id ?

Jouni

---

From: Qin Wu <[email-masked]>
Date: Wed, 24 Jun 2009 16:59:41 +0800

Hi, Jouni and Victor:
Thank for Jouni's clarification, I guess I misunderstand this widely used terms"Re-auth"
Since they have been used by different applications as command code, e.g., NASReq, Credit control, I think I am okay with
the current description in the rfc3588bis. But I still want to point out the Re-auth in the EAP re-authentication
is client initiated and has the meaning, quite different from the other applications, am I right?

Regards!
-Qin

---

From: jouni korhonen <[email-masked]>
Date: Wed, 24 Jun 2009 12:46:14 +0300

Hi Qin,

On Jun 24, 2009, at 11:59 AM, Qin Wu wrote:

> Since they have been used by different applications as command code,  
> e.g., NASReq, Credit control, I think I am okay with
> the current description in the rfc3588bis. But I still want to point  
> out the Re-auth in the EAP re-authentication

When a NAS (authenticator) receives a RAR, the NAS can initiate EAP  
(re-)authentication at any time just by issuing EAP-Request/Identity  
towards the client/peer.

Cheers,
	Jouni

---

From: Qin Wu <[email-masked]>
Date: Wed, 24 Jun 2009 17:51:59 +0800

Hi, Jouni:
----- Original Message ----- 
From: "jouni korhonen" <[email-masked]>
To: "Qin Wu" <[email-masked]>
Cc: "Victor Fajardo" <[email-masked]>; <[email-masked]>
Sent: Wednesday, June 24, 2009 5:46 PM
Subject: Re: [Dime] Review of draft-ietf-dime-rfc3588bis-17

> (re-)authentication at any time just by issuing EAP-Request/Identity  

[Qin]: It is a example which is not relected in the RFC4005 or other SDO specs, am I right?

---

From: Mark Jones <[email-masked]>
Date: Tue, 30 Jun 2009 11:23:30 -0400

Hi Lothar,

Thanks for the thorough review. Comments inline. 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Reith, Lothar
> Sent: June 21, 2009 5:54 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [Dime] Last Call: draft-ietf-dime-qos-attributes 
> (Quality of Service Attributes for Diameter) to Proposed Standard
> 
>  
> Dear all,
> 
> please find below a list of comments regarding the Last Call 
> on: draft-ietf-dime-qos-attributes (Quality of Service 
> Attributes for Diameter) to Proposed Standard
> 
> however, the ABNF definition in the line below specifies that 
> the QoS Resource AVP contains a list of QoS-Rules. 
> 
> The question is if the term policies and QoS-Rules are meant 
> synonymous in the context of the document. If that is the 
> case, I suggest to replace the term "policies" with 
> "Qos-Rules", as it is the only occurance of that term within 
> the document. If that is not the case,  the meaning of the 
> term policy in this document needs be defined, given that the 
> term "policy" is somewhat overloaded. For example, one could 
> define, that the terms "policy" and "QoS-Rule" are being used 
> synonymously in the context of the document, except when 
> referring to RFC5226 as a policy. Or one could state that a 
> "QoS-Rule" is a type of "policy". 
> 

Agreed. We change this to "list of QoS policy rules" in the next revision.

> 2.  issue: section 4.1.8.23 discusses Ethernet 
> "user-priority".  I would recommend to review with IEEE on 
> this to verify if "user-priority" or "P-bits" would be the 
> most appropriate term. 

We've reused the terms from the IEEE specs wherever possible. The IEEE 802.1D-2004 spec uses "user_priority parameter" rather than "P-bits" and so we assumed this was the most appropriate term.

> In addition, there seems to no 
> consideration yet for the "drop eligibility indicator" 
> contained in an S-Tag with Ethertype 0x88a8. It should be 
> possible to formulate a QoS-Rule which considers the "drop 
> eligibility indicator". Also it should be possible to 
> formulate a mark action, which sets the value of the  "drop 
> eligibility indicator" bit to 1. Along these lines, it should 
> also be possible to formulate a QoS-Rule which considers MPLS 
> EXP Bits of an incoming packet. And it should be possible to 
> mark MPLS EXP bits.
> 

This draft does not claim exhaustive support for all ethertype flags and features. The IEEE features will contine to be a moving target and so we focused on the ones required to satisfy current SDO requirements while ensuring that all the groups AVPs can be easily extended to handle new features. 

> 3. issue in section 4.2.1: charging granularity not compliant 
> with consumer protection legislation (at least in Germany)
> Proposed Solution:  I would recommend to multiply the values 
> by 10, in order to arrive at a granularity of one tenth of a 
> second (split-second). This would allow to comply with some 
> consumer protection regulations in the area of charging 
> accuracy, such as a "telecommunication customer protection 
> law" effective in Germany. I know of one voice switch vendor, 
> who had to reprogramm his voice-switch accounting software 
> because of that law, as a metering granularity of one second 
> was not good enough to meet the legal demands in all cases. 
> This was due to the possible errors in measuring the time at 
> the start of a call and at the end of a call could add up to 
> more than one second, even though the time measurement itself 
> had a granularity of one second. As a minimum, the range must 
> be doubled to a measurement granularity of a half-second, in 
> order to be on the safe side regarding compliance with this law.
> 

Agreed. We propose keeping the existing AVPs which use the Diameter Time datatype and adding a "fractional" AVP of type Unsigned32 to add additional precision to both the absolute and relative timestamps in the draft.

> 4.issues in section 5.1 the actions drop, shape and mark may 
> require some further scrutiny and refinement
> 
> 4.1 Issue regarding the drop action: Drop action does not 
> differentiate, if the dropped packet shall get accounted.
> - drop without counting, i.e. drop without charging for the 
> delivery to the point, where the packet gets dropped, because 
> the packet did not get delivered to the customer, such as 
> discarding unsolicited out of profile downstream traffic from 
> some source in the Internet.
> - drop after counting, i.e. drop with charging for the 
> delivery of the packet to the point where it got discarded 
> (if legally allowed). This may be applicable to out of 
> profile upstream traffic.
> 

This is a QoS AVP draft and we have purposely avoided introducing charging aspects in the actions. The AVPs that determine the charging characteristics associated with the actions can always be added by applications that use these QoS AVPs and additionally require charging.

> - shape to which token bucket size and depletion rate?

This is covered in the companion I-D on QoS-Parameters (draft-ietf-dime-qos-parameters).

> - which bytes of the incoming packet count for depleting the 
> token bucket? All bytes of the layer 2 Frame in case of a 
> QoS-Rule at the Ethernet layer, where an IP header may not 
> even be present? In this context: Is the term bandwidth in 
> the "bandwidth AVP" defined as "net data rate" as in ANCP, or 
> differently defined or undefined? 
> 

This is not defined currently in the QoS-Parameters draft. We feel this kind of detail will be ironed out when the actual deployment gets done and the operator then states which part of the traffic contributes to the depleting counters. 

> Proposed solution regarding the first item: split the mark 
> action into 3 different mark actions,  mark-TOS byte, 
> mark-MPLS_EXP-bit and mark-P-bits. Consider to allow the 
> presence of multiple mark actions in a single QoS-Rule. 
> Proposed solution regarding the second item: Add actions for 
> re-mark-TOS byte, re-mark-MPLS_EXP-bit and re-mark-P-bits, 
> where the result of the re-mark-action depends on the former 
> setting of the field being re-marked.
> 

Please see response to comment 2.

> 5. Issue in section 5.4 I do not quite understand the 
> semantic differences between QoS Available, QoS Authorized 
> and QoS Reserved, in particular if QoS Reserved is already 
> accounting relevant. 
> Solution: Verify and make sure that there is indeed a 
> semantic difference, and that accounting for QoS Reserved is 
> compliant with consumer protection laws.
> 

Agreed that we need to expand the description of these values. The QoS-Authorized is delivered by the Authorization Server. The QoS-Available is what the client is able to apply (QoS-Available < QoS-Authorized).

> 6. issue in section 7.5 there is an example on how this may 
> apply in combination with Diameter Credit Control, and it is 
> stated there that " In this case the User is charged as soon 
> as the Service Element (CC client) receives the service request. "
> Proposed solution: Verify if  a procedure which starts 
> charging without knowing, if the the QoS-Resource can 
> actually be allocated does not violate consumer protection laws.
> 

Agreed. We'll clarify this. Charging for a given QoS must not start before the QoS-Resource is reserved.

>  "In this case the client uses the "QoS-Desired" 
> QoS-Semantics parameter in the QoS-Resources AVP that it 
> sends to the Accounitng server. The server responds with a 
> "QoS-Available" QoS-Semantics parameter in the QoS-Resources AVP"
> 

This is a typo and the server responds with QoS-Authorized as shown in Figure 6.

> This raises some doubts if the "accounting server" acts as an 
> authorization server. There should be clear separation of 
> accounting and authorization.
> Proposed solution: Change the wording to make clear, that the 
> accounting server does not authorize anything, otherwise, do 
> not call it an accounting server,  but rather an 
> authorization and accounting server, which would imply that 
> both functions are combined in one server (which in large 
> implementations is usually not the case). 
> 

Agreed that the accounting server does not authorize QoS. We'll separate these two functions onto distinct servers for clarity. 

> 8. reading further on, there is a  Message shown   "CCA 
> (Granted-Units, QoS-Resources(QoS-Authorized))"  which makes 
> me wonder, what is being authorized here with DCC. Is it an 
> authorization for a certain number of granted-Units delivered 
> with a higher QoS and charged extra using a one time charge 
> because of delivering these granted units with higher QoS?
> 
> If that would be the case,   it would  in my view be a bad 
> practice, as the one-time charge mechanism would effectively 
> be used for session based charging, but without the 
> reservation mechanism. What happens, if the Granted-Units 
> cannot be delivered with the higher QoS, say in case of an 
> outage? 

We are certainly not proposing a change in DCCA behaviour. Even if the QoS was reserved, an outage could still prevent delivery as you point out. Persumably, if Granted-Units (with/without QoS-Reserved) can not be subsquently delivered then the DCCA refund procedure would apply.

> Session based charging can handle this by means of 
> not confirming the reservation within a time limit.  It would 
> require extra complex logic to handle this situation, where 
> the One-Time charge would have to be cancelled or compensated 
> by a one-time bonus of same amount.
> 
> Proposed solution for issue 8: Use another example, which 
> does not suggest to re-invent session based online charging 
> using one-time charging events.
> 

Agreed. We have no intention of reinventing DCCA here. We'll either clarify ensuring DCCA compliance or use a non-DCCA example.

Regards
Mark

> ==============================================================
> ==============================================================
> ==============================================
> [Dime]Last Call: draft-ietf-dime-qos-attributes (Quality of 
> Service Attributes for Diameter) to Proposed Standard
> 
>     * Subject: [Dime] Last Call: 
> draft-ietf-dime-qos-attributes (Quality of Service Attributes 
> for Diameter) to Proposed Standard
>     * List-subscribe: 
> <https://www.ietf.org/mailman/listinfo/dime>, 
> <mailto:[email-masked]?subject=subscribe>
>     * List-unsubscribe: 
> <https://www.ietf.org/mailman/listinfo/dime>, 
> <mailto:[email-masked]?subject=unsubscribe>
>     * Prev by Date: [Dime] WGLC Comments on 
> draft-ietf-dime-rfc3588bis-17.txt, pp. 14-20
>     * Previous by thread: [Dime] WGLC Comments on 
> draft-ietf-dime-rfc3588bis-17.txt, pp. 14-20
>     * Next by thread: [Dime] Fwd: New Version Notification 
> for draft-korhonen-dime-mip6-feature-bits-01
>     * Index(es):
>           o Date
>           o Thread
> 
> Note: Messages sent to this list are the opinions of the 
> senders and do not imply endorsement by the IETF.