Subject: [AAA-WG]: RE: [aaa-editors] Evaluation: draft-ietf-aaa-diameter - Diameter Base Protocol to Proposed Standard (fwd)

From: <[email-masked]>
Date: Mon, 2 Dec 2002 21:31:02 +0200

Hi,

> - I see (on page 11 and page 19) 3 different terms for the
>   same thing (or are they indeed meant to be different?). To
>   me it seems these all refer to the DIAMMIP document/application.
>   They use:
>   - Mobile IPv4
>   - MIPv4
>   - Mobile IP

Fixed.

> - Is there an explanation as to how the allocations were done
>   in sect 2.4 ??? why junp from 1 to 4 and 5 and then to the end?

Fixed.

> - I think SMB already mentioned it, but there are quiet a few
>   places where one should use example.net or example.com
>   instead of abc.com and mno.net

Fixed

> - Last sentence of sect 2.9. I think they mean RECOMMENDED
>   instead of recommended

Fixed

> - Sect 3
>   - In the diagram they use "Ver", in the legend below it they
>     use "Version"

Fixed

>   - In the diagram they use "RPETrrrr" in the legend below they
>     use "Command Flags"

Fixed.

>   - I find the use of the T-flag pretty complicated.

I tried to make it more simple & move details to appendix c.

>   - they specify that the reserved bits MUST be zero on sending
>     and that they cause an error upon receipt. I think that normally
>     I see that such reserved bits are ignored on receipt. If this
>     is intentionally, then I guess it is OK. I just wondered.

That makes sense.

>   - They claim that the version field MUST be 1. I guess that it
>     must contain a valid version, and that at the time of this writing
>     there is only version 1.

Well, as the there is only version 1, it must be 1.  Future versions
of this document will update this, if necessary.

>   - They talk about "Origin-Host" in the description of End-to-End
>     Identifier... but at that point I have no idea yet what "Origin-Host"
>     is supposed to be.

I put a reference in.

> - Last para of sect 4.
>       "Zero bytes are added..."
>   Mmm... I guess that "A number of zero-valued bytes are added"
>   Maybe it is just me with my poor undestanding of English?

Nope, your understanding of English is perfect in this case.

> - Sect 4.1 and sect 4.2
>   - First, I would remove the number 4.2 or otherwise renumber it to
>     4.1.1 It is still part of the AVP header.

fixed.

>   - But... more importantly:
>     I get confused here w.r.t. the value of zero (0) for Vendor-ID.
>     It is not clear to me if value of zero is used ever or that instead
>     one always leaves out the optional Vendor-ID field if the value is
>     supposed to be zero.
>     If the latter, are they saying that the field Vendor-ID SHOULD NEVER
>     contain a value of zero....
>     As I said, I find it confusing
>     By the way, vendor IDs (the SMI values they are using here) cannot be
>     zero, cause the value zero is RESERVED, see
>          http://www.iana.org/assignments/enterprise-numbers

Agreed & fixed.

>   - It would be an improvement I think if they actually mentioned that
>     they are indeed the Enterprise-Numbers as registered by IANA
>     (At least that is what I understood they are meant to be). It will
>     make it easier to find them. the IANA resgistry does not talk about
>     Vendor-ID.

It is actually mentioned under Vendor-ID section.

> - Bullet 1) on page 37 talks about "base Diameter standard". Is that
>   appropriate? Should it be "base Diameter protocol" ??

Yup.

> - top of page 38 talks about "standard AVP". Is that appropriate?
>   If it is another application specific AVP, it may be a vendor specific
>   one and so may not be a standard AVP ??

It means that an AVP that has been standardized in the IETF, not a 
vendor specific AVP. 

> - Section 4.4
>   I wonder if the use of IPAddress as a datatype may not be misleading.
>   MANY MANY people know this as a SNMP/SMI datatype to represent an
>   IPv4 address. And so I immediatly jumped up and though: what about IPv6.
>   Turns out that they use this datatype for both IPv4 and IPv6. And one
>   has to figure it out based on the length.
>   Mmmm... is this smart? I know that we have abandoned all that in the
>   SMI world, and we use a discriminated union instead namely an
>   InetAddressType and and InetAddress.

Discussed in IETF55, as a way to ensure compatibility with RADIUS.

More in another mail.

John