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

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?

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)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

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

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJUwWy4AAoJEIBWSmyV89QNV70P/ji24iU2Wr93uGIjK79hSNIR
Bnab4rva2MHeGufWvTzYsvXwCYUaWOeb7y4Z5T1dRgPOPw4JNKQ5cnoEMjIMmWJu
J4ocoZlAR7ujKBOlTnvf1FlFEPDQ6emanxcRZD9+nTQPaC54gnMgf6CfWyQBgIia
oVGMEg2C/+yzx4NtuGAwqpJ4dVe/33VMpl4lG7KG4JQMzLYxyWIiiLDvA8SQXoxU
rLLVvkvKWp2hKdjO7zxpTY6Vd2DqYawU/Z25yWBAUmDFWziJwh6HD2P38F/KNszZ
kpRJD3WrjGdlmPKatooNwCHz60hjP2lFXlS7vocNAWuug4dAyPNZarl3G+ZSAhtB
Wud/vThdWwknGM9TbumDW5FM8kJoUPSjTICtaSG3jsnW2qPKAcikSubmepc5KXDg
Dap50sTL9XfM1WNIqiM1H/DdsQnEJfqgPJ7Nce+mzllMAFHVL7hOIyf2zpb8vPtt
Nq5FuCbDr4qK7IZxX+OzFuUJC+aT3ajWt6lZLjZmcHnObOfgTCDggWspWXzlNY+X
oYgH3DT6/j4jNkOZGcw7cOw1xHIQQWwxLEJkLIQwJiKeZHcOYbZ69LuEZ8k7mXZ3
cCDvnggXLujLZE5F4D/LtLq5MMrwGWtLiNN1DOBX3iH5EKE/YK0nsbFD+DKR9AiF
LdvuO+g1/k8sGzWJgxkr
=+wlK
-----END PGP SIGNATURE-----

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime