[AAA-WG]: DCC draft 05: summary of changes

[<[e-mail]>]

Hi AAA folks,

we published the DCC draft 05 sometime ago but we actually didn't send the
summary of changes, what the AD requested, to the working group.

The summary of main changes is given below. If no one objects, the document 
should be ready for IESG review.

Regards
Marco

1- Some of the abbreviations used along the document was expanded (e.g. SIP --> Session Initiation Protocol).
2- Consistent use of AAA Server and home AAA Diameter Server terminology along the document: AAA Server to indicate
    generically the AAA server (RADIUS/Diameter AAA server) and Home AAA Diameter Server.
3- RADIUS Interworking section reworked according to DCC issue 33. RADIUS related text in section 2 moved to the
    interworking section.
4- Added reference in section 2 to the RFC 3588 section 2.8 where the roles of Diameter agents are defined.
5- Added reference in section 3 to the RFC 3588 section 3.2 where the ABNF of the command is defined.
6- Section 4.1: added rules how to include RADIUS vendor specific attributes in service specific documents as discussed in 
    aaa mailing-list (http://www.merit.edu/mail.archives/aaa-wg/msg00537.html).

        When service specific documents include RADIUS vendor specific attributes that could be used as input in the rating 
         process, the rules described in [NASREQ] for formatting the Diameter AVP MUST be followed. For example, the
         AVP code used is the vendor attribute type code, the Vendor-Specific flag MUST be set to 1 and the Vendor-ID
         MUST be set to the IANA Vendor identification value. The Diameter AVP data field contains only the attribute 
         value of the RADIUS attribute.
7- Clarified in section 5.1 the applicability of the basic tariff time change mechanism for time based services as discussed in the
    mailing list (http://www.merit.edu/mail.archives/aaa-wg/msg00414.html).
8- Added in section 5.1.1 better explanation of rating-group and service-identifier as well as graphical representation of the
    relation between service-identifiers, rating-groups, credit pools and credit-control (sub-)session, as requested by AD review.
9- Rewrite of second paragraph in section 5.5 to clarify server initiated re-authorization at different granularirty, as requested by
    AD review.
10- Section 5.7: rewrite of sixth paragraph to clarify the reason of Tx definition. Requested by AD review.
11- Section 7: added following sentence to clarify why stop Tx action is not mentioned when moving to Idle state.

          The Tx timer, which is used to control the waiting time in the Credit control client in the PENDING state, is stopped
          when exiting the Pending state. The stopping of the Tx timer is omitted in the state machine when the new state is 
          Idle since moving to Idle state implies the clearing of the session and all the variables associated to it.
12- Section 7: Diameter DCC server state machine clarified for one-time event
       (http://www.merit.edu/mail.archives/aaa-wg/msg00575.html).

More can be found from the below extract of the conversation we (authors) had with the AD.

> > > > > One thing I did notice in various ABNF specifications 
> in sect 8
> > > > > is that you use curly and sqaure brackets seemingly at will.
> > > > > Not sure if that is correct... you may want to check.
> > > > > It occurs quite a number of times.
> > > > > 
> > > OK, I think I now see that it comes from the base diameter 
> > spec when 
> > >   <..> fixed AVP spec positions
> > >   {..} are required AVP specs
> > >   [..] are optional AVP specs
> > > 
> > > So.. probably this is known/obvious for people who do AAA 
> > > every day. For
> > > the not so AAA-adicted, it might be good to repeat that 
> sort of info
> > > somehwere in the beginning of the doc, or maybe to add a 
> > > reference about
> > > this that it is additional ABNF notation on top of that 
> in RFC3588?
> > 
> > OK, we will add a note that ABNF notation can be found from the
> > RFC3588.
> > 
> great and thanks
> 
> 
> > > b. On page 23/24 (possibly at other places too), I see 
> > > several terms used
> > >    like these:
> > >      - home Diameter AAA server
> > >      - home AAA server
> > >      - home AAA
> > >      - Diameter AAA server
> > >      - Diameter home AAA (sect 5.7 and sect 6.5)
> > >      - AAA server (sect 6.5)
> > >      - ...
> > >    Do they all mean the same server? Maybe not.
> > >    But are ther 4 different types?
> > >    Pls try to be very consistent when using those terms.
> > 
> > You are right. We'll use AAA server to indicate generically 
> AAA servers
> > (may be RADIUS/DIAMETER AAA) and home Diameter AAA server.
> > We'll update consistently the doc.
> > 
> great
> 
> > > c.Sect 5.5 2nd para.
> > >     (sub-)session level, credit pool level granularity, 
> > service-identifier
> > >     level granularity or rating-group granularity. To 
> > request credit re-
> > >     authorization at credit pool granularity the server 
> > includes in the
> > >     RAR message the G-S-U-Pool-Identifier AVP indicating 
> > the affected
> > >   How are sub-sessions and various other "levels" 
> > defined/identified/known?
> > >   Maybe I missed that in the doc... Mmm.. you refe to sect 
> > 5.1.1 but some
> > >   of the explanation may be in sect 5.1
> > >   Mmm.. I see that that sect 5.1.1 is also the section that 
> > made my eyes glaze 
> > >   over and wonder if all that compelxity is needed.
> > 
> > This level of granularities refer to the sect. 5.1.1. The 
> server knows
> > what is running in the client because it authorized the 
> credit. What 
> > service (service-id) or what group of services (rating-group) or
> > what pool (pool-id) is authorized it is then known.
> > The server may want to request credit re-authorization at different 
> > level: for the whole pool, just for one service or just for one
> > rating-group.
> > 
> > Do you recommend a slight rewrite the 2nd paragraph with a 
> better explanation and
> > perhaps add the definition of those levels in the 
> terminology section?
> > 
> Probably will help.
> 
> 
> > > e. Page 36 talks about "AAA server or agent" I guess server 
> > and agent are
> > >    meant to be synonyms here? Are they? Why are we 
> > confiusing people here?
> > 
> > Server and agent are not synonyms in this chapter. There can be
> > transport level connection between Clinet and Relay/Proxy agent and
> > between Relay/Proxy agent and Server (can be also beteween relay and
> > proxy agents), I doesn't need to be direct connection between Client
> > and Server. The section 2.5 in RFC3588 clarifies how transport
> > connection are set between clients, relays, proxies and servers.
> > 
> So is a "server" never an "agent"?
> And is an agent always a "proxy agent" or a "relay agent" ??
> I think that is what I am reading in 3588  sections 2.5 and 2.8.
> Maybe a reference to that would help. As you can see I was confused...
> probably because I am not a daily reader of AAA or RADIUS text :-(
> 
> > > f. Page 36/37 talks about "increased risk of premature 
> > failover" and about
> > >    "congestive collapse". Maybe those risks should be 
> spelled out in
> > >    security considerations? In any event it seems quite 
> > hidden to me the
> > >    way it is described in a long piece of text.
> > 
> > These are considerations about setting too low value for the 
> > Tw timer, 
> > probably copied from RFC 3539, to motivate the introduction 
> of the Tx
> > timer. Perhaps we could rephrase and add a reference to the 
> RFC 3539.
> > What about this?
> >  
> >    The AAA transport profile [AAATRANS] defines the application 
> >    layer watchdog algorithm that enables failover from a peer that 
> >    has failed and is controlled by the timer Twinit. The 
> recommended 
> >    default value for Twinit is 30 seconds. Twinit may be set as low 
> >    as 6 seconds, however, according to [AAATRANS] setting too low 
> >    value for Twinit is likely to result in an increased probability 
> >    of duplicates, as well as an increase in spurious failover and 
> >    failback attempts. Since the Diameter base protocol is common to 
> >    several different types of AAA applications that may be run in 
> >    the same service element, tuning the timer Twinit to a 
> lower value 
> >    in order to satisfy the requirements of real-time 
> > applications, such 
> >    as the Diameter Credit Control application, will certainly 
> > materialize 
> >    the above mentioned problems. For prepaid services, however, the 
> >    end user expects an answer from the network in a 
> > reasonable time, thus 
> >    the Diameter credit control client shall react faster than the 
> >    underlying base protocol. Therefore this specification 
> >    defines the timer Tx that is used by the credit-control 
> client (as 
> >    defined in section 13) to supervise the communication with 
> > the credit-
> >    control server. When the timer Tx elapses the 
> > credit-control client 
> >    takes an action to the end user according to the Credit-Control-
> >    Failure-Handling AVP.
> > 
> That is probably goodness. My main concern was that there was/is no 
> wording in the security considerations section that points 
> out this "risk"
> COuld be a one or two-liner with a ref to this section.
> 
> > > g. Have the state-diagrams been checked rigorously?
> > >    For example, page 46. the 3rd and 4th cases, should the 
> > also not be a
> > >    Stop Tx action? Also for 7th, 8th, 9th and 10th case on 
> > that page?
> > >    I wondered about such things at other places in the 
> > state diagrams too.
> > 
> > Tx is stopped when exiting the Pending state. Actually we purposely
> > omitted the stop Tx action when the new state is Idle because the
> > whole session is cleared. Therefore all the states associated with
> > the session are cleared too.
> > 
> Maybe that should be a generic piece of text at the beginning of the
> section on state diagrams? Then I would have understood.
> 
> > There has been two WGLCs for the draft and in addition to the
> > failure handling & state machine have been widely discussed 
> > on the mailing list, so we think that state-diagrams are 
> rather good 
> > shape.
> > 
> OK... as long as you are happy. As I said, I did not walk through them
> all in detail. So I am trusting you and the WG.
> 
> > > h. User-Equipment-Info-Type AVP is defined as Unsigned32. 
> > >    I wonder if the type would not better be Enumerated
> > 
> > It seems that we have forgot to update AVP type, when we 
> > updated the AVP. It should be Enumerated. 
> > 
> OK
> 
> 
> > > k. Section 8.28 in the examples, pls do NOT use "provider.com" and
> > >    "vendor.com". RFC2606 prescribes to use names like 
> > > "provider.example.com"
> > >    and "vendor.example.net" or some such.
> > > 
> > 
> > We'll update accordingly.
> > 
> good
> 
> > > l. Section 8.46 
> > >    Is it SIP URL in this case, while it is SIP URI in sect 8.38?
> > 
> > Should be SIP URI, we'll correct it.
> > 
> OK
> 
> > > m. I am confused by the AVPs defined in Sect 8.49 and 8.50
> > >    8.49 defines various types. Is the formatting of those values
> > >    indeed such that they are UTF-8 ? I have not checked. 
> > May I assume
> > >    that someone DID check/verify?
> > 
> > Probably you are right. A better data type should be OctetString.
> > Should UTF-8 format be needed it can be encoded in an 
> OctetString AVP.
> > 
> Well, if the AVP is supposed to transport "human readable" material,
> then we (IETF) DOES want UTF-8. 
> If not, then OctetString is probably better.
> It is just that I could not quickly see that all possible formats
> would be (easily) representable in UTF-8.
> 
> > > n. I assume Bernard (or some RADIUS/DIAMETER expert has 
> > > checked sect 11
> > 
> > The comments from WG chairs are covered in the DCC issue 33:
> > http://www.merit.edu/mail.archives/aaa-wg/msg00448.html
> > 
> > We'll change the doc. accordingly.
> > 
> good
> 
> > > o. In the IANA considerations you state many times "this 
> > specification
> > >    assigns xxx". 
> > >    - first, I suspect that IANA should officially do the 
> assignment.
> > >      so it would have been better to say something aka:
> > >      "Iana has assigned xxx" If you want a specific 
> value, you can 
> > >       ask IANA to use value xxx.
> > >    - second, I suspect that IANA needs to add the values to 
> > the registries
> > >      on their web pages. You do never tell IANA that they 
> > indeed need to do
> > >      that 
> > 
> > We can change the language.  In practice, we know that IANA 
> > is overloaded.
> 
> Yeah... I rmember that for the rfc3588 thing. So I can see 
> why you do this.
> 
> > In setting-up the Diameter IANA registry, I had to write 
> the complete
> > registry for IANA.  Life will be more complicated as 
> several Diameter
> > applications will go to RFC shortly, so I thought it 
> prudent to start
> > staking out the values.  Do you think this is aproblem.  
> > 
> The "propblem" is that if you put in real numbers in an I-D, then some
> implementers may start using those numbers before they are actually
> approved and assigned. We recently had a serious conflict 
> because of that
> in the RSVP space. So that is my serious concern.
> 
> > I could modify the text:
> > 
> > 	"this specification assigns xxx". 
> > to:
> > 
> > 	"this specification requests that IANA assigns xxx". 
> >  
> 
> I'd probably do it like in tghis format:
> 
>       "IANA has assigned xxx for such and such"
>       [IANA pls fill in xxx (suggested value 123) and remove 
> this note]
> 
> The "xxx" then also occurs at other places in the document.
> Mmm... yep elaborative... but such is our process.
> Not sure what is wise. Are we currently absolutely sure that 
> the values
> you used are correct and do not conflict with any other such values in
> other IDs or RFCs?? Are we absolutely sure nobody will make us change 
> things during IETF Last Call and IESG review?
> 
> 
> > > p. Security considerations.
> > >    You claim that DIAMBASE not only tells/assume that IPsec 
> > or TLS are used.
> > >    But DIAMBASE in fact REQUIRES (MUST language) the 
> > implementation of IPsec
> > >    and even explains how to do it (which is important). 
> > Same for TLS.
> > >
> > >    Second section uses lower case must/shall where I think 
> > uppercase MUST/SHALL
> > >    would be appropriate. I also suspect that the last 
> > sentence of 2nd
> > >    para may worry/bother security ADs.
> > > 
> > >    3rd para: "economical consequences" ?? DO you mean 
> "financial" ??
> > > 
> > >    last 2 paragraphs in sect 14 seem weak to me. WOnder 
> > what sec ADs have to say
> > >
> > 
> > We will update section according to your comments.
> > Two last paragraphs deal with security threat, which are common to
> > all Diameter application and not only to this application, since
> > Diameter do not provide application level security.
> >  
> > >    sect 14.1 talks about "agent"... is that same as "server"?
> > >    It also talks about "Diameter Routing Table" ... has 
> > that term been explained?
> > >    Last para in sect 14.1 points to an informative reference?
> > > 
> > >    I would recommend to have one of the secuirty ADs take a 
> > > look at this.
> > > 
> > 
> > "agent" is not same as server, it can be Diameter relay or proxy
> > agent. 
> > 
> Same concern as above. Add a ref to the proper place in 3588
> 
> > Diameter routing table has been explained in the RFC3588, 
> section 2.7.
> > We can add reference to that section.
> > 
> Would be good I think
> 
> > Diameter EAP handles this problem much more widely, but we do not
> > want to copy all that text here and because the Diameter EAP is also
> > work in progress status, we should point to an informative 
> reference,
> > Does this cause problems?
> > 
> Is that draft-ietf-aaa-eap-05.txt ??
> What is the status?
> So maybe indeed an informative ref anbd say that that work is 
> looking at 
> a more wider solution.
> 
> > > q. I wonder if references to documents that are cited in 
> > sections 8.x should
> > >    not all be normative. For example, [RAD802.1X] is 
> > normative (correctly
> > >    in my view), but [SIP] is informative (incorrectly in my 
> > view). [IPv4]
> > >    and [IPv6Addr] seem normative to me too?
> > 
> > OK, we will do re-checking.
> > 
> > 
> > We'll also check and updates all the below nits you pointed out.
> > 
> Great,
> 
> Bert
> > > ---------
> > > 
> > > Following are mainly nits/admin things:
> > > 
> > > 1. Results if idnits script. Just check, not all of it 
> means error.
> > >    But non-ASCII characters is not good. The long lines 
> > > can/will probably
> > >    be hadnled by RFC-Editor. But if you can fix it, so much 
> > > the better.
> > >     This idnits tool is available at: 
> > > http://ietf.levkowetz.com/tools/idnits/
> > >     $ idnits <drafts/draft-ietf-aaa-diameter-cc-04.txt
> > >     idnits 1.26, (21 Apr 2004)
> > > 
> > >     The document seems to use RFC 2026 boilerplate...
> > >     The document seems to lack an RFC 2026 Section 10.4(C) 
> > > Permission Grants Notice
> > >     -- however, there's a paragraph with a matching 
> > > beginning. Boilerplate error?
> > >     There are 298 instances of too long lines in the document,
> > >     -- the longest one being 1 character in excess of 72.
> > >        Line 1447 contains non-ascii character in position 37.
> > >        Line 3852 contains non-ascii character in position 49.
> > >        Line 5336 contains non-ascii character in position 39.
> > >        Line 5353 contains non-ascii character in position 51.
> > >     There are 4 instances of lines with non-ascii characters 
> > > in the document.
> > > 
> > >     Warnings:
> > >       The document seems to lack an RFC 2026 Section 10.4(B) 
> > > IPR Disclosure Invitation
> > >       There are 178 instances of lines with hyphenated line 
> > > breaks in the document.
> > > 
> > >       Line 2285 has weird spacing: '...quested  to en...'
> > >       Line 2295 has weird spacing: '...mporary   end ...'
> > >       Line 4755 has weird spacing: '...session  for s...'
> > > 
> > > 2.In the abstract, pls expand the SIP acronym
> > > 
> > > 3.In the body of the document, pls expand the acronyms when 
> > > used for the
> > >   first time
> > > 
> > > 4.One but last para of sect 1 states:
> > >    To fulfill these requirements, it is necessary to facilitate
> > >    communication between the network element providing the 
> > > service (e.g.
> > >    NAS, SIP Proxy, Application Server etc.) and a 
> > > credit-control server.
> > >   That seems to say that this doc does much more than what we 
> > > see in the abstract
> > > 
> > > 5.Last para of sect 1.2, 2nd line: s/intermediates/intermediate/
> > > 
> > > 6.Sect 1.3 talks about a value of "4" for Auth-Application-Id.
> > >   Is that already assigned? If not we should list in IANA 
> > > considerations sect.
> > >   Aha, I see it is in IANA considerations. So it should 
> > > really be a TBA instead
> > >   of pre-assuming it will get value 4 assigned by IANA.
> > > 
> > >   Same question in sect 3.1 and possibly at some more places
> > > 
> > > 7.Seect 3. Where are those code points for CCR and CCA defined?
> > >   In this doc? Then we need IANA considereations. In 
> fact, maybe the
> > >   doc should say TBA-by-IANA instead if this is the case, because
> > >   I see it in IANA considerations.
> > > 
> > > 8.Bottom page13 and top of page14. Is this another form of 
> > > (implicit) subtyping?
> > > 
> > > 9.Sect 5.1 4 para 2 but last line
> > >   s/the closing the/closing the/
> > > 
> > > 10.When I see  things like on page 18:
> > >      Where multiple G-S-U-Pool-Reference AVPs with the same 
> > > G-S-U-Pool-
> > >      Identifier are provided within a 
> > > Multiple-Services-Credit-Control AVP
> > >    Then I wonder if a ptr to where those AVPs are defined 
> > woul not be
> > >    useful/helpful.
> > >    Same for things like:
> > >      RECOMMENDED that Diameter credit-control clients 
> > > maintain a PENDING-U
> > >      message queue and restarts the Tx timer every time a 
> > CCR[Update]
> > > 
> > > 11.Let me also point out that the notaion CCR[Update] in the text
> > >    cam make people think that [Update] is a citation. I bet 
> > > the RFC-Editor
> > >    will not be happy with that. It occurs several times.
> > > 
> > > 12.Top of page 20 
> > >      the concerned service.  Additional service event 
> > > information to be
> > >      rated MAY be sent as service specific AVPs or MAY be 
> > > sent within the
> > >      Service-Parameter-Info AVP at command level.
> > >    So is it the server or the client who "MAY" send this?
> > >    And why is the Upper case MAY? 
> > > 
> > > 13.Somewhat towrds the bottom of page 20 (3rd pare from 
> > bottom) I see:
> > >      There MUST be maximum one instance of the same unit type 
> > > in one Answer
> > >      message. However, in case multiple quotas are conveyed 
> > > to the credit
> > >      control client in the Multiple-Services-Credit-Control 
> > > AVPs, it is
> > >      possible to carry two instances of the same unit type 
> > > associated to a
> > >      service-identifier/rating-group for instance when a 
> > > tariff time change
> > >      is expected.
> > >    Is that good english? Is the last one really a sentence?
> > >    I have a hard time understanding what it says
> > > 
> > > 14.Top of page 21:
> > >      Two different approaches are defined for the first 
> > > interrogation to
> > >      suit properly in all the possible architectures. The 
> > > first approach
> > >    Again... is that a sentence? And if so what does it mean?
> > > 
> > > 15. 2nd line page 23
> > >     s/contribute/co-operate/ ??
> > > 
> > > 16. Page 24, 1st para, one but last line.
> > >     Talks about setting a value to 1 (for an 
> "intermediate request".
> > >     and referes to sect 8.2
> > >     But sect 82. does not talk about "intermediate" requests. 
> > > I guess that
> > >     the UPDATE-REQUESTS are intermendiate... but that is not 
> > > immediately clear.
> > > 
> > > 17.Sect 5.5 talks about value 4 for RAR messages. See my 
> > > earlier comment
> > >    on that value.
> > > 
> > > 18. Sect 5.6 talks about "top-up". I probably can guess what 
> > > it means. But maybe
> > >     it is better to explain it.
> > > 
> > > 19.first para sect 5.6.2, last word:  s/follow/follows/
> > > 
> > > 20.Page 36 talks about "timer Twinit". Might want to explain 
> > > what it is.
> > >    Possibly also for timers Tx and Tcc
> > > 
> > > 21. Page 52 2nd case. I think under action column, you want 
> > > to s/=!/!=/ ??
> > > 
> > > 22. Table on page 54/55.. WOuld it not be good to explain 
> > > what codes M, P, V
> > >     and Y mean?
> > > 
> > > 23. Page 65 towards bottom
> > >     s/has been occurred/has occurred/
> > >     
> > > 24. Sect 8.32
> > >     s/enumerated/Enumerated/
> > > 
> > > 25. Sect 8.33 
> > >     Validity-Time in seconds. But since when? Since the AVP 
> > > is received by the
> > >     Client? 
> > > 
> > > 26. Top of page 85
> > >     s/kind threat/kind of threat/
> > > 
> > > Bert