Re: [Dime] Diameter Group: Type?

["David Lehmann" <[e-mail]>]

In addition, I don't know if it is wise to consider it an error if
received reserved bits are nonzero.  It limits future expansion, like
the one suggested.

 

The IETF mantra is "Be strict when sending, but liberal on receiving."
Notice SCTP's spec on chunk flags:

RFC 4960, section 3.2:

  Chunk Flags: 8 bits

 

      The usage of these bits depends on the Chunk type as given by the

      Chunk Type field.  Unless otherwise specified, they are set to 0

      on transmit and are ignored on receipt.

 

--

David Lehmann

Ulticom, Inc.

856-787-2952

 

From: [e-mail] [mailto:[e-mail]] On Behalf Of
David Lehmann
Sent: Tuesday, January 25, 2011 10:04 AM
To: Mark Jones; Erez Nassimi
Cc: [e-mail]
Subject: Re: [Dime] Diameter Group: Type?

 

I agree the RFC text should read "subsequent Diameter versions".
Applications should not be defining new flags.

 

--

David Lehmann

Ulticom, Inc.

856-787-2952

 

From: [e-mail] [mailto:[e-mail]] On Behalf Of
Mark Jones
Sent: Tuesday, January 25, 2011 8:33 AM
To: Erez Nassimi
Cc: [e-mail]
Subject: Re: [Dime] Diameter Group: Type?

 

Hi Erez,

The G-bit addition would not be backwards compatible with
implementations of existing Diameter applications. Looking at section
4.1 in RFC3588:

      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.

This text appears to allow the definition of your G-bit in some future
Diameter applications (though I wonder if this is a bug in the RFC which
should read "subsequent Diameter versions"). However implementations of
existing Diameter applications SHOULD reject the AVPs with your G-bit
set and return a permanent failure of DIAMETER_INVALID_AVP_BITS. 

How do you propose to make the G-bit addition harmless to existing
implementations?

Regards
Mark