Subject: RE: [AAA-WG]: Clarification on ABNF Command specification

From: Cain Brian-BCAIN1 <[email-masked]>
Date: Wed, 25 Jul 2001 10:34:01 -0500

> -----Original Message-----
> From: Pat Calhoun [mailto:[email-masked]]
> 
> On Tue, Jul 24, 2001 at 05:18:58PM -0500, Cain Brian-BCAIN1 wrote:
> > 
> > from -07, Section 3.2:
> >       fixed            = [qual] "<" avp-spec ">"
> >                          ; Defines the fixed position of an AVP
> > 
> >       required         = [qual] "{" avp-spec "}"
> >                          ; The AVP MUST be present
> > 
> >       optional         = [qual] "[" avp-name "]"
> >                          ; The avp-name in the 'optional' 
> rule cannot
> >                          ; evaluate to any AVP Name which 
> is included
> >                          ; in a fixed or required rule.
> > 
> > Fixed AVPs are implicitly required, correct?  And from 
> this, it appears that
> > it may be legal for AVPs to appear in both the fixed and 
> required sections.
> > Is there a logical reason for any AVP to appear in both?
> 
> A fixed AVP is required, but has a specific location in the packet. A
> required AVP must also be present, but may appear anywhere in 
> the packet.

Anywhere, as long as it's after those fixed at the beginning, and before
those fixed at the end, right?

And can the same AVP appear as both a fixed and required AVP in one
Command/Grouped AVP?

> PatC

---

From: Erik Guttman <[email-masked]>
Date: Wed, 25 Jul 2001 17:46:37 +0200 (MEST)

Brian,

> those fixed at the end, right?

      diameter-message = header  [ *fixed] [ *required] [ *optional]
                         [ *fixed]

Right, though the required AVPs come before the optional ones according
to the grammar.

> And can the same AVP appear as both a fixed and required AVP in one

This is not forbidden by the grammar.  The only rule which limits which
AVPs may appear in a command message is:

      optional         = [qual] "[" avp-name "]"
                         ; The avp-name in the 'optional' rule cannot
                         ; evaluate to any AVP Name which is included
                         ; in a fixed or required rule.
                         
This rule prevents an 'optional' AVP from overriding a rule elsewhere.
For instance:

   <blah> ::= 1*1{Foo-AVP} *[AVP]

If you sent a <blah> with two Foo-AVPs this would violate the rule
above.

Erik

---

From: Cain Brian-BCAIN1 <[email-masked]>
Date: Wed, 25 Jul 2001 14:31:59 -0500

> From: Jacques Caron [mailto:[email-masked]]
> Subject: RE: [AAA-WG]: Clarification on ABNF Command specification
> 
...
> And also some AVPs might be fixed in some commands and not in others 
> [though I guess those that must be at the start or at the end are 
> presumably protocol-related rather than application-related?].

Well, I think this kinda puts a nail in the coffin of your idea.  I think
it's best not to associate any particular AVP with the format of the
command/grouped AVP it could/might/should be contained in.

> And honestly I'm less and less convinced about the whole ABNF 
> thing. I 
> would at least separate all the protocol-related AVPs (e.g. 
> Route-Record, 
> Source-Route...) from the command-code specific AVPs in some 
> way. See also 
> my comment about the additional 
> accounting-application-specific AVPs in the 
> same accounting messages as per 2.6 in a previous post...

I think I'd appreciate a division between protocol-impacting and
non-protocol impacting AVPs.  But, I'm content to go with it the way it is
now.

From Pat:
>well, I have personally never seen WG consensus on this particular change
>request, nor an issue. I also must admit that re-architecting the specs
>for mere convenience is probably something that should have been done prior
>to the imminent WG last call :(

True.  In order to prevent further delays, it may be best to let sleeping
dogs lie on this one.

-Brian

---

From: Cain Brian-BCAIN1 <[email-masked]>
Date: Thu, 26 Jul 2001 11:11:08 -0500

> From: Erik Guttman [mailto:[email-masked]]
> Subject: Re: [AAA-WG]: Clarification on ABNF Command specification
...
> Brian,
> 
> The intent is to allow radius-like flexibility while adding three
> constraints - 
> 1: AVPs can be fixed at the beginning and end (order and number)
> 2: AVPs can be required in the middle (number not order) 
> 3: AVPs can be stuck in optionally (no order or number restrictions 
> as long as it doesn't conflict with numbering restrictions in the 
> 'required' section).  
> 
> If this is ambiguous in the current text I will open an issue with 
> suggested new text.

In the interest of interoperability, it probably would not be a bad thing to
explicitly state that the AVPs needn't be contiguous.  "The AVP MUST be
present" does seem to imply that "this AVP MUST occur at least min times, at
most max times, anywhere in the required section, and all occurrences
needn't be in a contiguous block," but the latter could be more helpful.
It's not important to me that a change in the text be made, but if it's
unclear to anyone else, maybe it's worth considering.

On a side note, I noticed that we have a Result-Code AVP value defined for:

>      DIAMETER_AVP_OCCURS_TOO_MANY_TIMES 5010

but we don't have a "DIAMETER_AVP_OCCURS_TOO_FEW_TIMES" -- it looks like we
should use "DIAMETER_MISSING_AVP" instead?  Perhaps that needs to be made
more explicit?  The text for MISSING_AVP says "The request did not contain
an AVP that is required" which does seem to imply "did not contain an AVP
that is required, or as many occurrences of an AVP that are required", but
again, maybe it's better to make it more explicit.  Food for thought.