Re: [Dime] RFC3588bis; Result-Codes and AVP flags

[Mark Jones <[e-mail]>]

On Mon, Mar 14, 2011 at 5:58 AM, jouni korhonen <[e-mail]> wrote:
> Folks,
>
> A couple of things still need to be clarified. I have the forthcoming -27 on my table, so..
>
> 1) What was the conclusion on this Result-Code mismatch? See mail from Sebastien that pointed this out:
> http://www.ietf.org/mail-archive/web/dime/current/msg04616.html
>
> Glen also rightfully pointed out that these changes cause changes in peer behavior. So, a) are people happy with the new categorization currently in RFC3588bis? Or b) should we go back to existing RFC3588 categorization regarding Result-Code values?? (note that the numbering of the values is wrong as there are overlaps with IANA registry but that is easily fixable)
>
> Raise your opinion. If you prefer a) then also state how to handle the "deprecated" values.
>

To remain backwards compatible, an RFC3588bis implementation will need
to handle both the RFC3588 values and RFC3588bis values. Doesn't this
mean that they can't be simply removed from the RFC or IANA registry
but instead must be somehow marked as 'deprecated'? Sounds messy so
unless these incorrect categorizations in RFC3588 are causing IOT
issues, my vote is (b); leave them be.

>
> 2) Discussion on AVP flags. RFC3588bis-26 Section 4.1 says:
>
>      The AVP Flags field informs the receiver how each attribute must
>      be handled.  The 'r' (reserved) bits are unused and SHOULD be set
>      to 0.  Note that subsequent Diameter applications MAY define
>      additional bits within the AVP Header, and an unrecognized bit
>      SHOULD be considered an error.
>
> See the discussion around here, which ended without a firm conclusion:
> http://www.ietf.org/mail-archive/web/dime/current/msg04626.html
>
> I would say we stay with the existing text. Any opinions against keeping the existing text? If yes, propose the new text.
>

I expressed my opinion on per-app AVP flags on the thread so let's
hear some new voices. However, nothing is broken and if there is no
consensus for change then I guess it stays as is. I do agree with
David Lehman on rewording the text on setting unused bits though.
Something like: "The 'r' (reserved) bits are unused and MUST be set to
0 by the sender and ignored by the receiver".

Regards
Mark

> - jouni
>
>
>
> On Jan 26, 2011, at 4:31 AM, Sebastien Decugis wrote:
>
>> Hello,
>>
>> I just compared the Result-Code values described in rfc3588bis-26
>> section 7.1.x with existing IANA registry, and found several
>> differences, which are currently not reflected in the IANA
>> Considerations section -- I believe someone is already working on this
>> section (although I lost track of whom) so I thought I would write down
>> the differences I found to help in this work -- I hope this is not
>> redundant.
>>
>> DIAMETER_COMMAND_UNSUPPORTED:
>> - value 3001 in IANA registry,
>> - value 5019 in 3588bis.
>>
>> DIAMETER_INVALID_HDR_BITS:
>> - value 3008 in IANA,
>> - value 5020 in 3588bis
>> - also,
>>
>> DIAMETER_INVALID_AVP_BITS:
>> - value 3009 in IANA,
>> - value 5021 in rfc3588bis
>>
>> DIAMETER_UNKNOWN_PEER:
>> - value 3010 in IANA,
>> - value 5018 in rfc3588bis (conflicts with IANA)
>>
>> DIAMETER_INVALID_BIT_IN_HEADER:
>> - 5013 in IANA,
>> - 3011 in rfc3588bis
>> - seems redundant with DIAMETER_INVALID_HDR_BITS.
>>
>> DIAMETER_INVALID_MESSAGE_LENGTH:
>> - value 5015 in IANA,
>> - value 3012 in rfc3588bis
>>
>> DIAMETER_INVALID_AVP_BIT_COMBO:
>> - value 5016 in IANA
>> - not defined in rfc3588bis
>> - is it deprecated? it seems redundant with DIAMETER_INVALID_AVP_BITS
>> anyway...
>>
>> Hope this helps,
>> Sebastien.
>>
>> --
>> Sebastien Decugis
>> Research fellow
>> Network Architecture Group
>> NICT (nict.go.jp)
>>
>> _______________________________________________
>> DiME mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dime
>
>