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

[jouni korhonen <[e-mail]>]

Hi Mark,

Thanks for the quick reply. Read below..


On Jul 27, 2010, at 9:36 PM, Mark Jones wrote:

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

Ack.


> 
> 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.

Personally I tend to agree. Some implementations I know just ignore excess AVPs outside ABFN with M=0, and continue processing the command like nothing happened. I.e. the assumed behavior from Section 1.2.3 quoted above..  

> 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

Ok.

> 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.

Right. Actually when reading Section 7 onwards then remaining text makes it quite clear that Failed-AVP is part of the error. Following that I would also add [Experimental-Result] to the Section 7.2 ABNF (as that AVP also has M=1).
> 
>>  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. ;)

Right, hearing more opinions wouldn't make harm though.

> 
>> 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.

Ok.


- Jouni


> 
> Regards
> Mark
> _______________________________________________
> DiME mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dime