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

[Steve Donovan <[e-mail]>]

I would propose the following resolution to the M-bit issue:

1) We say that new extensions MUST NOT require the M-bit be set for new 
sub-AVPs of the OC-Supported-Features AVP or the OC-OLR AVP.

2) We indicate that if there a new extension includes behavior that 
requires 6733 defined M-bit behavior then the new extension can define a 
new AVP.  It just can't make that new AVP part of OC-Supported-Features 
or OC-OLR.

Does this address everyone's concerns?

Steve

On 1/23/15 3:46 AM, Maria Cruz Bartolome wrote:
> See below
> Thanks
>
> -----Original Message-----
> From: Ben Campbell [mailto:[e-mail]]
> Sent: jueves, 22 de enero de 2015 22:34
> To: Maria Cruz Bartolome
> Cc: Steve Donovan; [e-mail]
> Subject: DOIC M-Bit usage (was Re: [Dime] 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 <[e-mail]> 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..
>
> [MCruz] Any mandatory or conditionally mandatory AVP, it is as well mandatory to be understood by any DOIC-enabled.
>
> -----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-----