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

[Ben Campbell <[e-mail]>]

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

What's the point of 2)? It still introduces a way that a DOIC extension might cause the application transaction to fail. Do we want that?

On Jan 23, 2015, at 7:17 AM, Steve Donovan <[e-mail]> wrote:

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


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

iQIcBAEBCgAGBQJUwmV/AAoJEIBWSmyV89QNk/gQAMTubMzk/y3Ia3thiWAH8K/2
j9VnwHFsza62G3uMLmYQ8tZNsXgidOF+F6WwC6hZRZK/QX3tNTLbnF4FjyFn2fhO
eE0D00mDbp/kngMITrxVHTGghocSBxGHyNntQKwrIxV7gVYIxEbMUL8ouKvO9Do8
NOi9K/he1iiK0pCNcQ9UstU8ZQm5kPyqMVGLhsHLEe779qTfE6fF5ppeJgATPyJl
1wNHgBoh9XcGPJdYO4MzcSn/hO9+tC9Ngp2lO0w4Q2SHgwh1W3kRODwLtNWq8pcg
JcSb6UtcQ/jVdOCF23/eZ3OhXgC8q01j2tp0YGVXGqPf4ePPU10uAW/8lioEwbRH
iiqOiSSEPbjjMb3yVDc/cu78Iq8NGr8n7iEiQwlPCs8Vlv7Nj7xv2Lmyk8LlDz4q
/HAozquUXgHwaYuKtzH7QBf+79rinPJAjomv10tzMSHk/Tu5aq0KFI41jqUra1i/
0xu9TnMDmEseL5rjMpkQ1Cw69H/etoh7+93jt3nGJUoLL7+eGoq0Z8pkl3Ukeihu
1DjigPWkbsfGtp0Iw0FKvtVMjSqFgFyH2y/k3u2Xiiz5k/e6mdqp3UnsHuc6MPUy
4fULg+SShkAMnk5BFjG4KKFWdTBhVn5X8O8lhgzfJ46SYkdAo2qw9YEd19CtJK5E
yvE5D9UmNsXqEjh+t/yp
=mnr3
-----END PGP SIGNATURE-----