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

[<[e-mail]>]

I agree with Mark understanding, regarding to addition of missing *[AVP] in some commands and decision to keep the version number unchanged.
It would be great if other WG members confirm/contradict these statements.

Cheers,

Lionel 

> -----Message d'origine-----
> De : [e-mail] [mailto:[e-mail]] De 
> la part de jouni korhonen
> Envoyé : jeudi 29 juillet 2010 17:52
> À : Mark Jones
> Cc : [e-mail]
> Objet : Re: [Dime] last review of RFC3588bis before the proto 
> write-up -please comment
> 
> 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
> 
> _______________________________________________
> DiME mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dime
>