Re: [Dime] last review of RFC3588bis before the proto write-up - please comment

[Mark Jones <[e-mail]>]

Hi Jouni,

I agree with your proposed editorial changes. See inline for my
comments on the ABNF issues.

On Wed, Jul 21, 2010 at 8:42 AM, jouni korhonen <[e-mail]> wrote:
> For the following I must to hear comments _before_ I proceed with the completion of the Proto Write-up:
>
>  o RFC3588bis keeps version as 1 so a RFC3588 node does not really know if it is
>   connecting with another RFC3588 or RFC3588bis node, or vice versa.
>   In Sections
>   5.4.1, 5.4.2, 5.5.1, 5.5.2, and 7.2 we actually _change_ the existing command
>   ABNFs that are more than just adding optional AVPs or sending less AVPs than
>   before (for example adding *[AVP] to a request, which means the receiver may
>   see AVPs that are beyond the ABNF it knows). According to the RFC3588bis
>   Section 1.3.3 this could mean an allocation of a new command code, which again
>   would require an allocation of a new application id for applications using the
>   new command.. This would impact backwards compatibility with RFC3588.
>

Sections 5.4.1, 5.4.2, 5.5.1 and 5.5.2 added *[ AVP ] to
DPR/DPA/DWR/DWA respectively. This was presumably added for
consistency with the ABNF for other base protocol commands. I view the
change as editorial because RFC3588 also says:

   "An implementation MAY add arbitrary non-mandatory AVPs to any command
   defined in an application, including vendor-specific AVPs without
   needing to define a new application."

Although this text was reworked in 3588bis, an implementation strictly
coded to RFC3588 is not going to barf a 5008 if these commands do
contain extra "non-mandatory" AVPs.

There is no reason to exclude *[AVP] from these commands and the
omission from the ABNF was probably an oversight. I suspect it would
have been approved if raised as an Errata on RFC3588.

Section 7.2 adds two optional AVPs to an ABNF that already had *[ AVP
] so the new format would not result in 5008 or 5009. The Failed-AVP
AVP has the M-bit set but RFC3588 was sufficiently vague on whether
mandatory meant presence or comprehension that a 5008 is unlikely.
Given the descriptions of the missing AVPs, I think these are clearly
oversights and they would have been approved as Errata.

>   Can we expect then receiving errors like 5008 and 5009 when the other end is
>   fully RFC3588 compliant and the other is RFC3588bis compliant? Is this unlikely
>   to happen?

No and no. Silence from the other stack implementers obviously means
they agree. ;)

>   Can a change to AVP multiplicity in ABNF considered such ABNF change
>   that requires a new command code?

It is tough to generalize; Did the ABNF contradict normative text?

I think of 3588bis as a collection of Errata. There were several
places in RFC3588 where ambiguity could create interop issues. When
we've hit those, we've been able to consult (and refer partners to)
3588bis in much the same way as we'd consult Errata.

Regards
Mark