RE: [iesg-secretary #4197] Evaluation: draft-ietf-aaa-diameter - Diameter Base Protocol to

["Michelle S. Cotton" <cotton@icann.org>]

John, Bert,

Please let me know if you need me to review
a revised draft of the document (for the 
IANA Considerations).

Thanks,

Michelle
IANA

-----Original Message-----
From: iesg-admin@ietf.org [mailto:iesg-admin@ietf.org]On Behalf Of
john.loughney@nokia.com
Sent: Wednesday, January 15, 2003 4:28 AM
To: bwijnen@lucent.com; iesg@ietf.org
Cc: aaa-editors@internaut.com
Subject: RE: [iesg-secretary #4197] Evaluation: draft-ietf-aaa-diameter
- Diameter Base Protocol to


Hi Bert,

> You have not changed IPAddress.
> Can you at least explain why you stick to your approach?

As discussed last night, I will make the change.
 
> > New more or less serious concerns/comments
> > - In section 6.2 and subsections. 
> >   Quite a few of the AVP descriptions state:
> >     This AVP SHOULD be placed as close to the Diameter 
> header as possible
> >   That is all nice, but there is no guidance as to which of 
> the many AVPs
> >   should be closest. Maybe there is no required/recommended 
> order... but
> >   the SHOULD at some 6 or more AVP descriptions makes me 
> wonder what order
> >   I should use.
> 
> I don't think I see an answer to the above yet.
> Must be that it is ALL CLEAR to the Diameter code implementers.

Will try to clean this up.

> > - Setc 6.15
> >   Again security, so I leave it to security ADs.
> >   But I wonder about the initialization of the counter at zero.
> >   I believe that in SNMP we took a random value at 
> initialization time
> >   and if I remember well, we did so for achieving better security
> >   I trusted the security geeks back then when they told me.

Agree, will fix.
 
> > - Sect 7.1 
> >   Is it important that the Result-code AVP be close to the 
> Diameter header?

Currently, I don't see a need for this.

> > - Sect 7.3
> >   States that Error-Message AVP is UTF8String. This 
> conflicts with page 52.
> >   I agree (as I wrote in my earlier comment) that 
> UTF8String is probably
> >   the better (derived) datatype.
> As per my previous message, this still conflicts with a table 
> earlier in the document

I've fixed it now.
> 
> > - sect 11.1
> >   I think that you are describing the assignment rules for 
> IETF IANA maintained
> >   AVP name space, which is identified by the absence of a 
> vendor-ID or a 
> >   vendor-ID of zero (not clear if both qualify or what, see 
> my ealier comment)
> >   Anyway, possibly this text (or text like this is better):

Fixed now.

> >   And then the text that starts with your 2nd para.
> >   
> >   W.r.t. to the actual values, it would be good to explain 
> if AVP code points
> >   255 and 256 are reserved or what? How about other missing 
> values in the gaps?
> >   Possibly IANA is happy with the ptr to sect 4.6.

I will work with IANA seperately in setting-up the Registry.

> >   Are the values 1-256 also there for "RADIUS backward 
> compatibility" ?
> >   If so (which I think) then better mention that, same as 
> you do mention it
> >   for the Command Codews

I believe it is mentionsed.

  AVP Codes 0-254 are managed separately as RADIUS Attribute Types [RADTYPE]. 

> >   The IETF IANA controlled AVP namespace if pretty big. So 
> is it required to
> >   be so strict w.r.t. release of blocks larger than 3AVPs 
> at a time? In other
> >   words, would 10 or 15 be a problem? Take the MIPv4 app as 
> an example, it
> >   needs 13 AVPs (if my counting is correct). Are those not 
> "normal" blocks
> >   of AVPs that a new APP would need, and should that not 
> fall in the normal
> >   allocation process?
> > 
> So i see no answer at all to the above ????

Handing out blocks larger than 3 was (I believe) a concern of
Scott's - he suggested 3.  This means, if someone (live MIPv4 Diam
App) needs more, it needs to be IETF Consensus.

> > - sect 11.3 
> >   - I am not sure the last para belongs in IANA 
> consideration section

OK.

> >   - Are values 0x01000000 to 0xfeffffff reserved or what?
> >     How about the value 0x00000000?
> > 
> Your sect 11.3 has changed. But I think it is now out of sync 
> with sect 2.4 Sect 2.4 says:

This all has been fixed now.
> 
>    The following Application Identifier values are defined:
> 
>       Diameter Common Messages      0
>       NASREQ                        1 [NASREQ]
>       Mobile-IP                     2 [DIAMMIP]
>       Diameter Base Accounting      3
>       Relay                         0xffffffff

to reflect the above.  Nothing else is currently reserved.

> And I still wonder who assigns (and under what rules) values in
> the range of  0x01000000 to 0xfeffffff


They are:

  Assignment of standards-track application IDs are by Designated Expert with 
  Specification Required [IANA].

  Vendor-Specific Application Identifiers, are for Private Use.  Vendor-Specific 
  Application Identifiers are assigned on a First Come, First Served basis by IANA.


> > Current Section 11.2.2
> >   - I think you are missing the 'T'-bit

fixed

> >   - I think if you look at your diagram on page 3, then one 
> would assume the 'R'-bit  to be bit zero, no? I believe that section 3.4 of
> >         draft-rfc-editor-rfc2223bis-02.txt
> >     tells us:  "bit zero the most significant bit in a word or field"

text changed to:

There are eight bits in the Command Flags field of the Diameter header. This document assigns bit 0 ('R'equest), bit 1 ('P'roxy), bit 2 ('E'rror) and bit 3 ('T'). Bits 4 through 7 MUST only be assigned via a Standards Action [IANA].


> >   - Same for the flags in sect 11.1.2 by the way

text changed to:

There are 8 bits in the AVP Flags field of the AVP header, defined in section 4. This document assigns bit 0 ('V'endor Specific), bit 1 ('M'andatory) and bit 2 ('P'rotected). The remaining bits should only be assigned via a Standards Action [IANA].


> > - I think that sect 11.7 should be renumberd and moved to 11.4.11
> >   The more cause then it is included in the set that is mentioned
> >   in sect 11.4 first para.
> So you see to think this is not the case

Fixed

 
> > - Reference to RFC1700 should be replaced with reference to RFC3232
> >   1700 is now HISTORIC
> > 
> You seem to have not bothered changing this?

Fixed

> I believe you have not addressed many of the following NITs.
> But then... they are just that... so ?
> 
> Bert
> > 
> > New NITs:
> > - section 7, 1st para
> >   s/are generally occur due to/generally occur due to/

fixed

> > - Last para on page 81.
> >   I see you only need to report the first error that is encountered.
> >   I know we had this in SNMPv1 (it would return NoSuchName for the
> >   first oid it could not return a value for). It resulted in many
> >   resends from mgmt apps to get it right via tryal-and-error.
> >   This was wrong, so we added that an agent can check the whole
> >   Message and return a NoSuchObject or NoSuchInstance or NotInView
> >   for any oid it cannot handle. It reduces the number of roundtrips
> >   dramaticvally. So just wondering if such would be a better approach
> >   here as well.

will double check

> > - last para sect 7.1
> >   s/non-recognize/non-recognized/ I think.

fixed

> > - sect 7.1.1 last para
> >   s/used required/used requires/ I think

fixed

> > - last para sect 7.2
> >   s/same that/same than/ I think

fixed

> > - sect 8.7 
> >   talks about "new command code values"... 
> >   I'd suggest to remove the word "new", no?

fixed

> > - sect 10, in the 0-1 description
> >   s/more than once instance/more than one instance/

fixed
> > - sect 11.1.1
> >   s/AVP Code/AVP Codes/ in sect title, to be consistent 
> with Command Codes?

fixed

> > - notation of hex values in sect 11.2.1 inconsistent with notation of
> >   hex values in sect 11.3 (upper/lower case, including 0x at beginning)

fixed

> > - sect 12, under "Realm Routing Table"
> >   s /table of Realms Names/table of Realm Names/ I think

fixed

> > - sect 13.1 2nd line
> >   s/with with/with/

fixed

> > - References
> >   - does [RADTYPE] not also have an RFC?

will check