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

[Sebastien Decugis <[e-mail]>]

 I also agree with these statements.

Beside, it is possible in many cases for a peer to decide whether the
remote peer is RFC3588 or rfc3588bis as a side effect of the new
security mechanism (indicated by the Inband-Security-Id AVP in the
CER/CEA exchange), in case an implementation really needs to know it.

Best regards,
Sebastien.


Le 30/07/2010 01:28, [e-mail] a écrit :
> 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
>>
> _______________________________________________
> DiME mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dime

-- 
Sebastien Decugis
Research fellow
Network Architecture Group
NICT (nict.go.jp)