Subject: Re: [Dime] AD review of draft-ietf-dime-diameter-api

From: "David Frascone" <[email-masked]>
Date: Tue, 15 Jul 2008 19:08:02 -0400

I have generated a new draft, at
http://dave.frascone.com/files/public/draft-ietf-diameter-api-07.txt
It is being reviewed, and I will submit it after the reviews are completed.

-Dave

On Mon, Jun 16, 2008 at 9:11 AM, Romascanu, Dan (Dan) <[email-masked]>
wrote:

> Please find below the AD review of draft-ietf-dime-diameter-api. I have
> divided the comments into Technical and Editorial.
>
> Although the document has reached a certain level of maturity it looks
> like another I-D would be needed before we can go to IETF Last Call. I
> suggest to address in the revised I-D also comments from other
> reviewers, I have seen comments from Sebastien Decugis, there may be
> other.
>
> Thanks and Regards,
>
> Dan
>
> Technical Comments
>
> T1. Section 1 - using the term 'standardized API' is not appropriate.
> The WG charter speaks about 'An informational RFC on a Diameter API' and
> the document itself targets Informational. It looks like the document
> should not claim that the API described here is the 'standardized' API.
>
> T2. The typedef enum in Section 3.1.12 is copied twice, and never closes
> - missing probably } AAAReturnCodes;
>
> T3. The data types in Section 3.1.14 do not correspond with the data
> types defined in Section 4.2 of RFC3588 (missing Unsigned32, Unsigned64,
> Float32, Float64)
>
> T4. The list of result codes returned from remote servers in Section
> 3.1.18 does not seem to match anything from RFC3588. I am looking at
> Section 7.1. Do I need to look into some other place?
>
>
> Editorial Comments
>
> E1 Section 3.1.7 has the wrong title - it should probably be 'Server
> Identifier' or 'Serving Peer Identifier'
>
> E2 - section 3.1.12 -
>
> AAA_ERR_NOMEM:  This code is returned if the operation caused memory to
> be exhausted.
>
> In reality it is not necessarily this operation that caused memory to be
> exhausted. I believe that a more accurate description would be 'The code
> is returned if there is no enough memory to execute the operation'.
>
> E3 - section 3.1.20 seems to have borrowed text from 3.1.19. It would
> also benefit from a short explanation of each field
>
> E4 - The descriptions of the various functions in section 3.4 are
> inconsistent in mentioning when fields refer to pointers (sometimes they
> do , sometimes the do not)
>
> E5 - Section 3.7, pag. 40 - in the first paragraph, third sentence the
> word 'directly' appears twice
>
>
>
>
>
>
>
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime
>
_______________________________________________
DiME mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dime