[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [iesg-secretary #4197] Evaluation: draft-ietf-aaa-diameter - Diameter Base Protocol to
Thanks for the updates.
W.r.t.
> > 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.
>
My point was that that range seems/seemed not to be included in the
IANA instructions on how assignments are made in various ranges.
Thanks,
Bert
> -----Original Message-----
> From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]
> Sent: woensdag 15 januari 2003 13:28
> 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
>