Subject: [AAA-WG]: RE: Decision time was: Mandatory Vendor-specific AVP's

From: <[email-masked]>
Date: Fri, 14 Jun 2002 17:05:05 +0300

Hi,

I can update the text.  If Randy thinks this will be sufficient for
the IESG, I will update the draft & publish it.

John

> -----Original Message-----
> From: ext Bernard Aboba [mailto:[email-masked]]
> Sent: 14 June, 2002 16:11
> To: Loughney John (NRC/Helsinki)
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]; 
> [email-masked]
> Subject: Re: Decision time was: Mandatory Vendor-specific AVP's
> 
> 
> > 1.2  Approach to Extensibility
> >
> >    The Diameter protocol is designed to be extensible. The 
> extensibility
> >    includes:
> >
> >       - Defining new AVP values.
> >       - Creating new AVPs
> >       - Creating new authentication/authorization applications
> >       - Creating new accounting applications
> >       - Application authentication procedures
> >
> >    Reuse of existing AVP values, AVPs, applications and 
> command codes are
> >    is strongly recommended.  Reuse simplifies 
> standardization effort,
> >    implentation effort and avoids potential interoperability issues.
> 
> change "are is strongly recommended" to "is RECOMMENDED."
> change "implentation" to "implementation"
> 
> >
> > 1.2.1  Standardized Extensions Versus Vendor-Specific Extensions
> >
> >    Diameter can be extended by standards track documents in 
> the IETF.
> >    The benefit of this is that the extensions become 
> Internet standards,
> >    allowing for wider possible deployment and higher assurance of
> >    interoperability.  It is strongly recommended that extensions to
> >    Diameter be made by standards-track RFCs.
> >
> >    Vendor-specific extensions are allowed, and MUST be 
> registered through
> >    IANA (see section 11.2).  However, vendor-specific 
> extensions MUST NOT
> >    harm interoperability of standards-based Diameter 
> implementations.
> 
> Don't understand meaning of "extensions" here. Is this VSCs? VSAs?
> Registration through IANA can't be mandatory for private 
> extensions and
> the sentence above seems to contradict text below. Recommend 
> deleting the
> above paragraph.
> 
> >
> >    Vendor-specific commands MUST NOT be used where an 
> existing command plus a
> >    vendor-specific AVPs would the same objective. If this 
> basic precept is
> 
> change "would the same" to "would meet the same"
> 
> >    followed, then most interoperability problems are solved.
> 
> change "are solved" to "can be avoided".
> 
> >    Vendor-specific commands MUST NOT be sent in response to standard
> >    commands.  Unsolicited VSCs
> >    sent from a AAA server to a NAS are to be treated as 
> non-mandatory. All
> 
> Change this to:
> 
> "Vendor-specific commands MUST NOT be sent except where they 
> are known to
> be supported as a result of capabilities negotiation between 
> the peers.
> Even where they are supported, Vendor-Specific commands MUST 
> NOT be sent
> in response to standard commands."
> 
> >    vendor-specific Diameter commands require Informational 
> RFCs documenting
> >    the command unless for Private Use as described in 
> Section 11.2.1.
> >
> >    As a general rule, any errors involving Vendor-specific 
> AVP marked with
> >    the 'M' bit are considered the fault of the side setting 
> the 'M' bit (see
> >    Section 4.1).
> 
> Add:
> 
> "A Diameter peer sending a command containing Vendor-Specific 
> AVPs marked
> with the 'M' bit, and receiving indication from its peer that 
> this AVP is
> not supported, SHOULD retry the command with the Vendor-Specific AVP
> removed, if this is feasible. This enables interoperability 
> for standard
> applications extended with Vendor-Specific AVPs marked with 
> the 'M' bit."
> 
> > 1.2.2  Defining New AVP Values
> >
> >    New applications should attempt to reuse AVPs defined in existing
> >    applications when possible, as opposed to creating new 
> AVPs. For AVPs
> >    of type Enumerated, it is possible the application requires a new
> >    value to communicate some service-specific information.
> >
> >    In order to allocate a new AVP value, a request MUST be 
> sent to IANA
> >    [IANA], with a detailed explanation of the value and 
> document on the
> >    value.
> >
> > 1.2.3  Creating New AVPs
> >
> >    When no existing AVP can be used appropriately to 
> communicate some
> >    service-specific information, a new AVP should be 
> created. The new
> >    AVP being defined MUST follow one of the types listed in 
> section 4.3.
> >    In the event that a logical grouping of AVPs is necessary, and
> >    multiple "groups" are possible in a given command, it is highly
> >    recommended that a Grouped AVP be used (see Section 4.5).
> >
> >    In order to create a new AVP, a request MUST be sent to 
> IANA, with a
> >    detailed explanation of the AVP, its type and possible values.
> >    Furthermore, the request MUST include the commands that 
> would make
> >    use of the AVP.
> >
> > 1.2.4  Creating New Authentication Applications
> >
> >    Should a new application require Diameter support, but 
> it cannot fit
> >    within an existing application without requiring major 
> changes to the
> >    specification, it may be desirable to create a new Diameter
> >    application. Major changes to an application include:
> 
> Add "Another reason to create a new Diameter application is if an
> extension cannot be implemented merely by adding AVPs to the 
> dictionary,
> requiring new code to be implemented on both both Diameter peers."
> 
> >
> >       - Requiring a whole different set of mandatory AVPs 
> to a command
> 
> Not clear whether this means "AVPs marked with the 'M' bit" or "AVPs
> required to be included within the command." I don't believe 
> that a new
> command is required just if some AVPs marked with the 'M' bit 
> are added to
> a command.
> 
> >       - Requiring a command that has a different number of 
> round trips
> >         to satisfy a request (e.g. application foo has a 
> command that
> >         requires one round trip, but new application bar 
> has a command
> >         that requires two round trips to complete).
> >       - The method used to authenticate the user is drastically
> >         different from any existing application, and the 
> authentication
> >         information cannot be carried within the AVPs defined in the
> >         application.
> 
> Don't agree that this should require a new command. For example, why
> should a NAS adding support for a new PPP authentication 
> method require an
> entirely new NASREQ application? This is particularly true since we
> recommend the opposite and discuss use of EAP as an 
> alternative later in
> the section. Recommend deletion.
> 
> >    Note that the creation of a new application should be viewed as a
> >    last resort.
> >
> >    New Diameter applications MUST define at least one 
> Command Code, the
> >    expected AVPs in an ABNF [ABNF] grammar (see section 
> 3.2), and MAY
> >    also define new AVPs. If the Diameter application has 
> any accounting
> >    requirements, it MUST also specify the AVPs that are to 
> be present in
> >    the Diameter Accounting messages (see section 9.3).
> >
> >    When possible, a new Diameter application SHOULD attempt 
> to re-use
> >    any existing Diameter AVP, in order to reduce the possibility of
> >    having multiple AVPs that carry similar information.
> >
> >    Every Diameter application specification MUST have an 
> IANA assigned
> >    Application Identifier (see section 2.4).
> >
> > 1.2.5  Creating New Accounting Applications
> >
> >    Services that have an Application Identifier MUST use the same
> >    identifier also to identify the service when Diameter 
> accounting is
> >    used.
> >
> >    There are services that only require the use of Diameter 
> accounting.
> >    Such services need to define the service specific AVPs 
> that must be
> >    carried in the Accounting-Request/Answer messages, but 
> do not need to
> >    define command codes. Application Identifiers are, however, still
> >    required for accounting due to the Diameter capability discovery
> 
> This might create some interoperability problems as discussed below.
> 
> >    process. Every accounting application MUST have either an IANA
> >    allocated Application Identifier, or a vendor specific 
> Application
> >    Identifier.
> >
> >    Note that the creation of a new application should be viewed as a
> >    last resort and should be used only when Vendor-Specific AVPs are
> >    insufficient. In most cases, reusing an existing 
> Application ID with
> >    Vendor-Specific AVPs should work. For example, many accounting
> >    servers are set up to write AVPs to disk, so they can handle even
> >    mandatory vendor-specific AVPs that they don't understand.
> 
> Change "mandatory vendor-specific AVPs that they don't understand" to
> "even Vendor-Specific AVPs marked with the 'M' bit that are 
> unsupported."
> 
> >
> >    This is why "disk writing" accounting servers should advertise
> >    themselves as "Relays" that can handle any Application 
> ID, including
> >    Vendor-Specific.
> 
> Recommend adding:
> 
> "Note that even when an accounting server advertises the "Relay"
> application it cannot be assumed it can handle unsupported 
> Vendor-Specific
> Commands. For example, while an accounting server can handle
> Vendor-Specific AVPs within an ACA by writing them to disk, it cannot
> assume that a Vendor-Specific Command is equivalent to an ACA, and
> carry out the same operation."
> 
> >    When possible, a new Diameter accounting application 
> SHOULD attempt
> >    to re-use any existing Diameter AVP, in order to reduce the
> >    possibility of having multiple AVPs that carry similar 
> information.
> >
> >    Every Diameter accounting application specification MUST 
> have an IANA
> >    assigned Application Identifier (see section 2.4).
> >
> > 1.2.6  Application Authentication Procedures
> >
> >    When possible, applications SHOULD be designed such that new
> >    authentication methods MAY be added without requiring 
> changes to the
> >    application.
> 
> Note that this contradicts earlier text which was requested 
> to be removed.
> 
> >    This MAY require that new AVP values be assigned to
> >    represent the new authentication transform, or any other 
> scheme that
> >    produces similar results. When possible, authentication 
> frameworks,
> >    such as Extensible Authentication Protocol [EAP], SHOULD be used.
> 
>