Subject: Re: Choice of Data Model SMI vs XML vs. UML

From: David Spence <[email-masked]>
Date: Tue, 09 Jan 2001 19:17:30 -0500

Juergen Schoenwaelder wrote:
>... 
> >> David's proposal comes yet again from another different angle. Its
> >> main background is the observation that AVP combinations that can
> >> be meaningfully combined in a message are actually not well
> >> defined.
> 
> Erik> I do not know that this is a very big issue.  If DIAMETER
> Erik> command codes specify what MUST be there and how to interpret
> Erik> it, other AVPs which are present should not prevent proper
> Erik> interpretation of the command.
> 
> Erik> We have been around this point a number of times - there are
> Erik> good reasons to use the RADIUS approach as it is flexible:
> Erik> Specify what is required, allow arbitrary ordering and
> Erik> additional AVP message components.  No one has argued for
> Erik> removing this flexibility, though there has been discussion
> Erik> about how this would facilitate a formal ABNF for the protocol.
> 
> There are again two issues here. The first one is a protocol issue,
> namely whether it is legal so ship additional AVPs with a message.
> The second one is the question which set of AVPs actually consitute a
> given message. Even the current specs use a kind of a BNF notation
> trying to make that clear. But there are issues because the specs do
> not really say what the semantics of the BNF notation are.
>...

It's actually worse than that.  The presence of the BNF gives one the
impression that the permissible contents of each message are specified.  But
the BNF is not complete.  The BNF for both the AA-Request and AA-Answer
messages in draft-calhoun-diameter-nasreq-05.txt contain the line:

   [<Authorization AVPs>]

But the term <Authorization AVPs> is not expanded.  The implication might be
that any of the AVPs defined in section 6 would do.  Section 6, however, is
divided into subsections.  Some of the subsections, such as section 6.2,
"Framed Access Authorization AVPs", and section 6.3, "Non-Framed Access
Authorization AVPs", can be inferred to be mutually exclusive, i.e., you
would not expect to find an attribute defined in 6.2 and an attribute
defined in 6.3 to appear in the same message.  But the draft does not state
that explicitly.  Even if the draft were to state that explicitly, one might
then assume that any of the attributes from section 6.2 could be
meaningfully combined when providing a framed access service.  What, then,
would it mean if the Framed-IPX-Network and Framed-AppleTalk-Network AVPs
were included in the same message?  My problem with the BNF is that it
appears to specify permissible messages but does not.  RADIUS, at least,
does not make that pretension.

-- 
David Spence                            email: [email-masked]
Interlink Networks, Inc.                phone: (734) 821-1203
775 Technology Drive, Suite 200         fax:   (734) 821-1235
Ann Arbor, MI 48108           
U.S.A.

---

From: Pat Calhoun <[email-masked]>
Date: Tue, 9 Jan 2001 18:50:21 -0800 (PST)

> What, then,

I actually do not see why one cannot run both IPX and Appletalk over the same
PPP connection. Am I missing something fundamental?

In any case, I do agree (and I don't think that anyone has argued this) that
the BNF needs to change. However, how drastic must the change be? This is a
real question, because if one was to attempt to define all possible
combinations, the RFC would be ungodly long (perhaps as an appendix it would
be ok).

PatC

---

From: David Spence <[email-masked]>
Date: Wed, 10 Jan 2001 12:43:07 -0500

> PPP connection. Am I missing something fundamental?

Well, of course, you're right.  But in some ways it underlines the problem,
namely, that there isn't any model that says one way or the other.