Subject: [Dime] rfc3588bis next revision; was Re: Diameter Group: Type?

From: jouni korhonen <[email-masked]>
Date: Thu, 18 Aug 2011 15:17:52 +0300

Folks,

We had a discussion on unused (reserved) flags in AVP header.  Here is proposed text to Section 4.1 regarding reserved AVP flags:

OLD:

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

NEW:

      The AVP Flags field informs the receiver how each attribute must
      be handled.  It is RECOMMENDED that new Diameter applications do 
      not to define additional AVP Flag bits. The sender of the AVP MUST
      set 'r' (reserved) bits to 0 and the receiver MUST ignore all 'r'
      (reserved) bits. Unrecognized bits SHOULD be considered an error.
      ...

Then proposed additional text to Section 1.3.4

   AVP Flag bits

      An existing application changes the meaning/semantics of their
      AVP Flags or adds new flag bits then a new Diameter application
      MUST be created.

Any comments?

- Jouni

On Mar 17, 2011, at 11:35 PM, Avi Lior wrote:

> Hi All,
> 
> Just summarizing and reasserting my objection.
> 
> There are two issues here:
> A) Should we have a bit definition for a grouped AVP.
> 
> B) Can bits be defined by Applications etc; and
> 
> WRT to (A). And putting aside (B).  I haven't heard any compelling reason
> to add the G-bit.  As stated by more then one person: You either support
> the
> AVP based on its command code or not - whether its a grouped AVP or not
> only becomes when you have to dive in to it - and you would only do that
> for an AVP that you support. And you would know the type of the AVP
> (whether it is an int or a group etc) if you support the AVP.
> 
> 
> 
> As to B) I agree with Glen.  As per the specification an Application can
> define its own AVP flag.
> Thus if an application writer can design a new Application and add a G-Bit
> if they want.
> 
> What we cant do is add the G-bit as a general mechanism that can be
> applied to all application (like the M-bit) and this is because (as
> mentioned on this thread) the specification was not written properly and
> we cant deal with such modification and not break things.  See "the
> senders shall set to zero(clear) and receivers shall ignore" discussion.
> We can't fix that in BIS since it will break existing applications.  We
> could say that new applications shall include the above statement.  We can
> also RECOMMEND that new application don't define their own AVP bits (if we
> want).  This may create a bit of a war as those entities that have done so
> come out of the wood work.  Do we know anyone that has done that?
> 
> Here is some text:
> 
> It is recommended that new Applications not define their own AVP flags
> bits.
> 
> New Applications shall treat any reserved AVP flag bits as follows:  The
> sender of the AVP shall clear (set to zero) all reserved AVP flag bits and
> receivers shall ignore all reserved AVP flag bits.
> 
> 
> Is there anything to fix in BIS.  Yes.
> 
> We need to state somewhere that if an existing application changes the
> meaning/semantics of their AVP Flags then a new Application ID must be
> assigned to that application.
> 
> This could be added to the section describing when to get a new
> Application ID.
> 
> In V2 we can support properly the notion of applications defining their
> own Flag bits (yuck) or not (my vote)
> 
> 
> -- Avi Lior
> --Bridgewater Systems
> 
> 
> 
> 
>> 
>

---

From: Glen Zorn <[email-masked]>
Date: Sun, 28 Aug 2011 16:48:20 +0700

>       (reserved) bits. Unrecognized bits SHOULD be considered an error.

If you're going to say "SHOULD NOT", why not just say it?  Also, I would
prefer that we maintain the policy of strictness in reception and
tolerance in transmission (RFC 1958). I.e.,

       The AVP Flags field informs the receiver how each attribute must
       be handled.  New Diameter applications SHOULD NOT define
       additional AVP Flag bits. The sender of the AVP MUST set 'r'
       (reserved) bits to 0 and the receiver SHOULD ignore all 'r'
       (reserved) bits. Unrecognized bits SHOULD be considered an error.

...

---

From: jouni korhonen <[email-masked]>
Date: Mon, 29 Aug 2011 10:46:13 +0300

>       (reserved) bits. Unrecognized bits SHOULD be considered an error.

This works for me. Anyone else?

- Jouni

---

From: <[email-masked]>
Date: Tue, 30 Aug 2011 15:38:55 +0200

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de jouni korhonen
Envoyé : lundi 29 août 2011 09:46
À : Glen Zorn
Cc : [email-masked]
Objet : Re: [Dime] rfc3588bis next revision; was Re: Diameter Group: Type?

[Lionel] if "the receiver SHOULD ignore all 'r' (reserved) bits", how would the receiver be able detect "Unrecognized bits"? Is it implied "if not ignored, unrecognized bits SHOULD be considered an error"?

- Jouni

_______________________________________________
DiME mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dime

---

From: Glen Zorn <[email-masked]>
Date: Tue, 30 Aug 2011 22:15:56 +0700

On 8/30/2011 8:38 PM, [email-masked] wrote:

...

> [Lionel] if "the receiver SHOULD ignore all 'r' (reserved) bits", how would the receiver be able detect "Unrecognized bits"? Is it implied "if not ignored, unrecognized bits SHOULD be considered an…

I suppose so, & if the implementation ignores both "SHOULDS", maybe just
go non-linear? ;-)

...

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 30 Aug 2011 17:19:30 +0200

Hi,

As the document is now in IETF Last Call, please do not make any changes
until the end of the Last Call period. 

All agreed edits should be incorporated in the post IETFLC version
together with other changes resulting from LC comments. 

Thanks and Regards,

Dan

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Glen Zorn
> Sent: Tuesday, August 30, 2011 6:16 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [Dime] rfc3588bis next revision; was Re: Diameter Group:
> Type?
> 
> > [Lionel] if "the receiver SHOULD ignore all 'r' (reserved) bits",
how
> would the receiver be able detect "Unrecognized bits"? Is it implied
> "if not ignored, unrecognized bits SHOULD be considered an error"?
> >
>