Subject: RE: [Pana] FW: [issue112] 'M' flag clarification

From: [email-masked]
Date: Fri, 5 Nov 2004 09:36:34 +0200

I Agree. I'll update the issue.
- Dan

> -----Original Message-----
> From: ext Yoshihiro Ohba [mailto:[email-masked]]
> Sent: 05 November, 2004 00:14
> To: Forsberg Dan (Nokia-NRC/Helsinki)
> Cc: [email-masked]
> Subject: Re: [Pana] FW: [issue112] 'M' flag clarification
> 
> 
> Hi Dan,
> 
> On Thu, Nov 04, 2004 at 05:34:28PM +0200, 
> [email-masked] wrote:
> > Dan Forsberg <[email-masked]> added the comment:
> > 
> > Proposed text for issue112 ('M' flag clarification):
> > 
> > Change from (section 7.3 AVP Header):
> > 
> >       "M(andatory)
> > 
> >          The 'M' Bit, known as the Mandatory bit, indicates whether
> >          support of the AVP is required.
> > 
> >       V(endor)
> > 
> >          The 'V' bit, known as the Vendor-Specific bit, indicates
> >          whether the optional Vendor-Id field is present in the AVP
> >          header."
> > 
> > To: 
> > 
> >       "M(andatory)
> > 
> >          The 'M' Bit, known as the Mandatory bit, indicates whether
> >          support of the AVP is required.  If an AVP with the 'M' bit
> >          set is received by a PaC or PAA and either the AVP or its
> >          value is unrecognized, the message MUST be rejected.
> >  
> >          AVPs with the 'M' bit cleared are informational only and a
> >          receiver that receives a message with such an AVP 
> that is not
> >          supported, or whose value is not supported, MAY 
> simply ignore
> >          the AVP.
> > 
> >       V(endor)
> > 
> >          The 'V' bit, known as the Vendor-Specific bit, indicates
> >          whether the optional Vendor-Id field is present in the AVP
> >          header.  When set the AVP Code belongs to the specific
> >          vendor code address space."
> > 
> > 
> > Add to the end of section 7.3:
> > 
> >    "Unless otherwise noted, AVPs defined in this document 
> will have the
> >    following default AVP Flags field settings:
> > 
> >          The 'M' bit MUST be set.  The 'V' bit MUST NOT be set.
> > 
> >    In case PaC or PAA receives an unknown AVP with 'M' bit set, the
> >    message MUST be discarded."
> 
> I think the last sentence is already mentioned in the M bit
> definition and thus might not be needed here.
> 
> Yoshihiro Ohba
> 
> 
> > 
> > ----------
> > status: Pending -> Text Proposed
> > ___________________________________________________
> > PANA Issues <[email-masked]>
> > <http://danforsberg.info:8080/pana-issues/issue112>
> > ___________________________________________________
> 
> > _______________________________________________
> > Pana mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/pana
> 
> 

_______________________________________________
Pana mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pana

---

From: "MORAND Lionel RD-CORE-ISS" <[email-masked]>
Date: Tue, 9 Nov 2004 19:33:50 +0100

See my comment below.

> I think the last sentence is already mentioned in the M bit definition

> and thus might not be needed here.

==> An unknown AVP or AVP value for an AVP with the M-bit set should
cause the following error: PANA_AVP_UNSUPPORTED (5001) and not be
silently discarded. 

Lionel

---

From: [email-masked]
Date: Mon, 15 Nov 2004 10:28:26 +0200

Hi Lionel, 

Thanks for catching this! How about this (see issue112):

      "M(andatory)

         If an AVP with the 'M' bit set is received by a PaC or PAA
         and either the AVP or its value is unrecognized, the message
         MUST be rejected and the receiver SHOULD send a PANA-Error
         message. If the AVP was unrecognized the PANA-Error message
         result code MUST be PANA_AVP_UNSUPPORTED.  If the AVP value
         was unrecognized the The PANA-Error message MUST be
         PANA_INVALID_AVP_VALUE.  In either case the PANA-Error
         message MUST carry a Failed-AVP AVP containing the offending
         mandatory AVP.
 
         AVPs with the 'M' bit cleared are informational only and a
         receiver that receives a message with such an AVP that is not
         supported, or whose value is not supported, MAY simply ignore
         the AVP."

Br,
- Dan

> From: ext MORAND Lionel RD-CORE-ISS
> [mailto:[email-masked]]
> Sent: 09 November, 2004 20:34
> To: Forsberg Dan (Nokia-NRC/Helsinki); [email-masked]
> Cc: [email-masked]
> Subject: RE : [Pana] FW: [issue112] 'M' flag clarification
> 
> 
> See my comment below.
> 
> definition

---

From: "MORAND Lionel RD-CORE-ISS" <[email-masked]>
Date: Thu, 18 Nov 2004 04:42:56 +0100

Hi Dan,

Thanks for this proposed update!
It is OK for me except one thing: "the receiver SHOULD send a PANA-Error message."
>From my point of view, the non-support of a M-bit AVP (or AVP value) implies an interoperability problem between the sender and the receiver. In this case, an error message MUST be sent to the originator of the message in order to inform the sender about this interoperability problem. But perhaps do you have another interpretation?

Cheers,

Lionel

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] 
Envoyé : lundi 15 novembre 2004 09:28
À : MORAND Lionel RD-CORE-ISS; [email-masked]
Cc : [email-masked]
Objet : RE: RE : [Pana] FW: [issue112] 'M' flag clarification

Hi Lionel, 

      "M(andatory)

 

Br,
- Dan

---

From: [email-masked]
Date: Thu, 18 Nov 2004 09:32:58 +0200

Lionel,

Good point. I fixed the text:

     If an AVP with the 'M' bit set is received by a PaC or PAA
     and either the AVP or its value is unrecognized, the message
     MUST be rejected and the receiver MUST send a PANA-Error
     message. If the AVP was unrecognized the PANA-Error message
     result code MUST be PANA_AVP_UNSUPPORTED.  If the AVP value
     was unrecognized the The PANA-Error message result code MUST
     be PANA_INVALID_AVP_VALUE.  In either case the PANA-Error
     message MUST carry a Failed-AVP AVP containing the offending
     mandatory AVP.

Br,
- Dan

> Sent: 18 November, 2004 05:43
> Subject: RE : RE : [Pana] FW: [issue112] 'M' flag clarification
> 
> 
> Hi Dan,
> 
> From my point of view, the non-support of a M-bit AVP (or AVP 
> value) implies an interoperability problem between the sender 
> and the receiver. In this case, an error message MUST be sent 
> to the originator of the message in order to inform the 
> sender about this interoperability problem. But perhaps do 
> you have another interpretation?
> 
> Cheers,
> 
> Lionel
>