Re: [Dime] DOIC M-Bit usage (was Re: WLGC #2 for draft-ietf-dime-ovli-06)

> On Jan 23, 2015, at 3:28 AM, Wiehe, Ulrich (NSN - DE/Munich) <ulrich.wiehe@nsn.com> wrote:
> 
> Ben,
> 
> for my clarification:
> this issue seems to be a general thing and not related specifically to DOIC. 
> 
> Any potential modification, addition, clarification,... would not impact DOIC but RFC6733.
> Is this the correct understanding?

Not really. I think the way 6733 describes things was as intended for the general case. It's there so that the recipient doesn't have to recurse all the way through a bunch of nested group AVPs just to make sure there aren't any M-bits set.  

DOIC is unusual here, in that we are piggybacking info onto an existing application. We don't want to induce a failure in that application because of an error in DOIC.

> 
> Ulrich
> 
> -----Original Message-----
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Ben Campbell
> Sent: Thursday, January 22, 2015 10:34 PM
> To: Maria Cruz Bartolome
> Cc: dime@ietf.org
> Subject: [Dime] DOIC M-Bit usage (was Re: WLGC #2 for draft-ietf-dime-ovli-06)
> 
> Signed PGP part
> 
> On Jan 22, 2015, at 10:41 AM, Maria Cruz Bartolome <maria.cruz.bartolome@ericsson.com> wrote:
> 
> A) About 'M' bit:
> 
> My understanding of RFC6733:
> 
>      The 'M' bit, known as the Mandatory bit, indicates whether the
>      receiver of the AVP MUST parse and understand the semantics of the
>      AVP including its content.  The receiving entity MUST return an
>      appropriate error message if it receives an AVP that has the M-bit
>      set but does not understand it.  An exception applies when the AVP
>      is embedded within a Grouped AVP.  See Section 4.4 for details.
> 
>       4.4:
>   Receivers of a Grouped AVP that
>   does not have the 'M' (mandatory) bit set and one or more of the
>   encapsulated AVPs within the group has the 'M' (mandatory) bit set
>   MAY simply be ignored if the Grouped AVP itself is unrecognized.  The
>   rule applies even if the encapsulated AVP with its 'M' (mandatory)
>   bit set is further encapsulated within other sub-groups, i.e., other
>   Grouped AVPs embedded within the Grouped AVP.
> 
> 
> If the Grouped AVP does not have the 'M' bit set, but one (or more) of its sub-AVPs do have it, then the grouped AVP may be ignored (instead of sending an error) if the Grouped AVP itself is "unrecognized"
> But what "unrecognized" mean in this context? In my opinion, the grouped AVP is not recognized as long as mandatory sub-AVPs are missed, this includes conditionally mandatory (up to negotiation) sub AVPs.
> Then I would proposed a variant to your proposal 2 below:
> 
> That's not what "unrecognized" typically means in IETF specs. The common usage is to mean that the recipient doesn't recognize it, or doesn't know what it means. This is  distinct from "malformed" meaning it wasn't constructed correctly.  Missing mandatory sub-AVPs would fall into the "malformed" category, not the "unrecognized" category. .
> By definition, a DOIC cannot claim OC-Supported-Features or OC-OLR as unrecognized.
> 
> 
> 3) sub-AVPs of DOIC grouped AVPs MUST NOT  have the m-bit set unless the sub-avp is mandatory or conditionally mandatory (i.e. part of an extension explicitly negotiated in the feature vector).
> 
> Also, the M-bit doesn't mean the avp is mandatory to be present, just mandatory to be understood. By definition, you can't set the M-bit on an AVP that is not actually there.  (Other things may make it mandatory to be present, such as the feature or application definition, but that still doesn't necessarily mean it's mandatory to understand.) It's also possible that some new feature will involve an AVP that is not there all the time, but mandatory to understand when it is there..
> 
> 
> 
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime