Subject: [Dime] draft rfc3588biz-09 does not follow it's own MUSTs.

From: Ralph Loader <[email-masked]>
Date: Thu, 20 Dec 2007 13:59:35 +1300

The definition given for the Vendor-Specific-Application-Id does not 
follow the grammar specification that "MUST" be used according to 
section 4.4.

The grammar given in section 4.4 does not include '/' or parenthesis; 
but those are used in 6.11.  [While 4.4 does refer to RFC2434, the text 
makes it clear that it is the grammar given in section 4.4 that MUST be 
used.]

My preferred fix would be to alter the Vendor-Specific-Application-Id:

       <Vendor-Specific-Application-Id> ::= < AVP Header: 260 >
                                            { Vendor-Id }
                                            [ Auth-Application-Id ]
                                            [ Acct-Application-Id ]

And add new text imposing additional constraints; something like:

"A Vendor-Specific-Application-Id AVP MUST contain exactly one of 
Auth-Application-Id and Acct-Application_id.

If a request containing a Vendor-Specific-Application-Id with neither of 
these two sub-AVPs is received, the recipient SHOULD generate a reply 
with DIAMETER_MISSING_AVP result code, within which the Failed-AVP 
should contain either a Auth-Application-Id AVP or a Acct-Application-Id 
AVP.

If a request containing a Vendor-Specific-Application-Id with both 
Auth-Application-Id and Acct-Application-Id is received, then the 
recipient SHOULD generate a reply with 
DIAMETER_AVP_OCCURS_TOO_MANY_TIMES result code, in which the Failed-AVP 
contains the second occurrence of the Auth-Application-Id and 
Acct-Application-Id AVPs."

Alternatives:

1.  Do nothing, in which case author or implementors of Diameter 
applications may take "MUST"s less seriously.

2.  Allow the '( / )' construct either by including it in section 4.4 or 
by altering the section 4.4 to allow any RFC2434 notation.  If this is 
done, then section 7 will need some rework to cover the new error cases 
that arise from the extended grammar.

Ralph.

_______________________________________________
DiME mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dime

---

From: Victor Fajardo <[email-masked]>
Date: Wed, 19 Dec 2007 22:41:09 -0500

Hi Ralph,

> but those are used in 6.11.  [While 4.4 does refer to RFC2434, the 
> text makes it clear that it is the grammar given in section 4.4 that 
> MUST be used.]
>

I think adding references to 2434 in section 4.4 should regarding the 
'/' should be sufficient.

> Auth-Application-Id and Acct-Application_id.

Sure, we can re-iterate this again.

>
> If a request containing a Vendor-Specific-Application-Id with neither 
> of these two sub-AVPs is received, the recipient SHOULD generate a 
> reply with DIAMETER_MISSING_AVP result code, within which the 
> Failed-AVP should contain either a Auth-Application-Id AVP or a 
> Acct-Application-Id AVP.
>
> DIAMETER_AVP_OCCURS_TOO_MANY_TIMES result code, in which the 
> Failed-AVP contains the second occurrence of the Auth-Application-Id 
> and Acct-Application-Id AVPs."

I think this is redundant. If we make section 4.4 clear then the 
appropriate errors associated with any parsing violations against any 
ABNF will be implied as it is now. Otherwise, we risk writing a lot of 
text enumerating and describing every single error condition (like 
above) for every ABNF that is defined.

regards,
victor

> 2.  Allow the '( / )' construct either by including it in section 4.4 
> or by altering the section 4.4 to allow any RFC2434 notation.  If this 
> is done, then section 7 will need some rework to cover the new error 
> cases that arise from the extended grammar.
>
> Ralph.
>

---

From: Ralph Loader <[email-masked]>
Date: Thu, 20 Dec 2007 16:57:06 +1300

> '/' should be sufficient.

It's a major extension to the grammar for a single case that can be 
handled perfectly well without [it might be textually small, but e.g., 
it's a very major change for those of us who process the grammar with 
automated tools].  I'd prefer the more conservative approach of handling 
this special case as a special case.

> ABNF will be implied as it is now.

The trouble with extending the grammar specification is that the current 
error handling seems to assume the 4.4 grammar specification.  E.g., the 
current definition of DIAMETER_MISSING_AVP assumes that you can identify 
what AVP is missing.

> Otherwise, we risk writing a lot of 

This is already the route the diameter error handling has taken; by 
specifying different result codes for different violations of grammars.

If you extend the grammar specification, then yes, you do need to extend 
the error handling.

Ralph.

---

From: Rajith R <[email-masked]>
Date: Thu, 20 Dec 2007 12:36:49 +0530

<quote>
Acct-Application-Id AVPs
</quote>
Should not this be considered as contradicting AVPs?

Rajith
-----Original Message-----
From: Ralph Loader [mailto:[email-masked]] 
Sent: Thursday, December 20, 2007 6:30 AM
To: [email-masked]
Subject: [Dime] draft rfc3588biz-09 does not follow it's own MUSTs.

Alternatives:

Ralph.

---

From: Victor Fajardo <[email-masked]>
Date: Thu, 20 Dec 2007 08:37:07 -0500

Hi Ralph,

Thanks for the review.

> automated tools].  I'd prefer the more conservative approach of 
> handling this special case as a special case.
>

Sorry I meant if we put references to "RFC4234" (numbers got jumbled up) 
which already contains rules for alternatives (3.2). So I don't really 
consider it an extension since it already exist. We can also re-iterate 
the "\" rules in bis 4.4 to make the point clear. Since 4234 is the 
basis for ABNF parsing, I would expect your automated tools already 
handle such things.

> The trouble with extending the grammar specification is that the 
> current error handling seems to assume the 4.4 grammar specification.  
> E.g., the current definition of DIAMETER_MISSING_AVP assumes that you 
> can identify what AVP is missing.

See above.

>
>> Otherwise, we risk writing a lot of text enumerating and describing 
>> every single error condition (like above) for every ABNF that is 
>> defined.
>

Yes but you don't have to repeat the text everytime everywhere you find 
an ABNF.

>
> If you extend the grammar specification, then yes, you do need to 
> extend the error handling.

See above.

regards,
victor

---

From: Ralph Loader <[email-masked]>
Date: Fri, 21 Dec 2007 07:52:56 +1300

Victor,
> consider it an extension since it already exist.

  We can also re-iterate
> basis for ABNF parsing,

As far as I can understand your email, you are claiming that RFC3588 
allows Diameter applications to use arbitrary RFC 4234 ABNF to describe 
their AVPs?  That is NOT what the 3588 wording says:

    Every Grouped AVP defined MUST include a corresponding grammar, using
    ABNF [RFC4234] (with modifications), as defined below

Based in rfc4234 yes, "with modifications" [that severely restrict the 
grammar].  The grammar that "MUST" be used is that "defined below" the 
sentence.  I can't see any reasonable reading of that sentence that 
allows ABNF beyond that explicitly listed in section 4.4.

  I would expect your automated tools already
> handle such things.

I'm not sure on what grounds you have an expectation on code that that 
you've never hand any contact with whatsoever.  If I need to start 
supporting Diameter applications that use general RFC 4234 ABNF I will 
when the need arises...  until then, Diameter is quite complicated 
enough and I've no desire to generate unnecessary work for myself.

>> can identify what AVP is missing.

Just to re-iterate, the current section 7 error handling does not cover 
many error cases that can arise if Diameter application writers use 
arbitrary RFC4234 ABNF.

If 4.4 is to be interpreted or re-written to allow arbitrary ABNF, then 
section 7 needs revision [or ad hoc error handling needs to be done for 
AVPs that require it.]

> Yes but you don't have to repeat the text everytime everywhere you find 

As far as I can see, section 7 doesn't cover the error handling required 
for Vendor-Specific-Application-Id.  Specifically, the current 
DIAMETER_MISSING_AVP text assumes that the recipient can identify a 
specific AVP that is required but not present; that is not the case with 
a V-S-A-I that contains neither a Auth-Application-Id nor a 
Acct-Application-Id [but does contain a Vendor-Id].

Ralph.

---

From: Ralph Loader <[email-masked]>
Date: Fri, 21 Dec 2007 07:54:55 +1300

> Should not this be considered as contradicting AVPs?

Yes, you are right.  DIAMETER_CONTRADICTING_AVPS is better, and the 
section 7 text already covers this case, so there is no need to repeat it.

Ralph.

---

From: Victor Fajardo <[email-masked]>
Date: Thu, 20 Dec 2007 14:12:00 -0500

Hi Ralph,

> allows Diameter applications to use arbitrary RFC 4234 ABNF to 
> describe their AVPs?  That is NOT what the 3588 wording says:
>

Ok. I see your point. We can update the rules in 4.4 and update the 
error codes in section 7 to support the new rules.

regards,
victor