Subject: [AAA-WG]: FW: AD review: draft-ietf-aaa-diameter-cc-04.txt

From: <[email-masked]>
Date: Tue, 27 Apr 2004 10:57:50 +0300

Hi all,

Here is the results of the AD review.  The authors will try to address
the technical comments on the list & start working on the editorial
issues.

John

> > > 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?
> 
> > > Is it OK if I type up those nits later this week?
> > 
> > Sure, shall we do a quick rev before submitting to the IESG?
> > 
> So here are my little nits and such:
> 
> First some things I worried/wondered about:
> 
> a. Sect 5.1.1 made we wonder if we really need this type of 
> complexity?
> 
> 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.
> 
> 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 refer 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.
> 
> d. On page 30... I started wondering... Mmmm there are a lot 
> of "may" cases
>    here. How will all the "may"-behaviour interoperate. Maybe just me.
> 
> 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?
> 
> 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.
> 
> 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.
> 
> h. User-Equipment-Info-Type AVP is defined as Unsigned32. 
>    I wonder if the type would not better be Enumerated
> 
> i. I see that various of your Enumerated datatypes start the list of
>    enumerations at zero. Is that wise? In the SMI we tend to 
> start at 1. The 
>    reason is that zero is often just an value that is there 
> after clean memory
>    has been obtained and while no one has yet initiated the 
> field. I can live
>    with it, just wanted to point it out.
> 
> j. I am surprised to see a Unsigned64 to ideintify 
> subsessions. Do we really
>    believe there will be that many? I can live with it... but ??
> 
> 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.
> 
> l. Section 8.46 
>    Is it SIP URL in this case, while it is SIP URI in sect 8.38?
> 
> 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?
> 
> n. I assume Bernard (or some RADIUS/DIAMETER expert has 
> checked sect 11
> 
> 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 
> 
> 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
> 
>    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.
> 
> 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?
> 
> I have not checked the appendices.
> 
> ---------
> 
> 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
>

---

From: <[email-masked]>
Date: Tue, 27 Apr 2004 14:01:39 +0300

This is assigned issue 34.