anchor.diff:  
   %% decode/4
   
  +%% AVP is defined in the dictionary ...
   decode(Name, {AvpName, Type}, Avp, Acc) ->
       d(Name, Avp#diameter_avp{name = AvpName, type = Type}, Acc);
   
  +%% ... or not.
   decode(Name, 'AVP', Avp, Acc) ->
       decode_AVP(Name, Avp, Acc).
  +
  +%% 6733, 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.
  +%%
  +%% The first sentence is slightly mangled, but take it to mean this:
  +%%
  +%%   An unrecognized AVP of type Grouped that does not set the 'M' bit
  +%%   MAY be ignored even if one of its encapsulated AVPs sets the 'M'
  +%%   bit.
  +%%
  +%% The text above is a change from RFC 3588, which instead says this:
  +%%
  +%%   Further, if any of the AVPs encapsulated within a Grouped AVP has
  +%%   the 'M' (mandatory) bit set, the Grouped AVP itself MUST also
  +%%   include the 'M' bit set.
  +%%
  +%% Both of these texts have problems. If the AVP is unknown then its
  +%% type is unknown since the type isn't sent over the wire, so the
  +%% 6733 text becomes a non-statement: don't know that the AVP not
  +%% setting the M-bit is of type Grouped, therefore can't know that its
  +%% data consists of encapsulated AVPs, therefore can't but ignore that
  +%% one of these might set the M-bit. It should be no worse if we know
  +%% the AVP to have type Grouped.
  +%%
  +%% Similarly, for the 3588 text: if we receive an AVP that doesn't set
  +%% the M-bit and don't know that the AVP has type Grouped then we
  +%% can't realize that its data contains an AVP that sets the M-bit, so
  +%% can't regard the AVP as erroneous on this account. Again, it should
  +%% be no worse if the type is known to be Grouped, but in this case
  +%% the RFC forces us to regard the AVP as erroneous. This is
  +%% inconsistent, and the 3588 text has never been enforced.
  +%%
  +%% So, if an AVP doesn't set the M-bit then we're free to ignore it,
  +%% regardless of the AVP's type. If we know the type to be Grouped
  +%% then we must ignore the M-bit on an encapsulated AVP. That means
  +%% packing such an encapsulated AVP into an 'AVP' field if need be,
  +%% not regarding the lack of a specific field as an error as is
  +%% otherwise the case. (The lack of an AVP-specific field being how we
  +%% defined the RFC's "unrecognized", which is slightly stronger than
  +%% "not defined".)
   
   %% d/3
   
  
positive.code:                              {Reason, Avp, erlang:get_stacktrace()}),
              {Rec, Failed} = Acc,
              {[Avp|Avps], {Rec, [rc(Reason, Avp) | Failed]}}
      end.
  
  %% decode_AVP/3
  %%
  
negative.code: 
  %% pack_AVP/3
  
  pack_AVP(Name, #diameter_avp{is_mandatory = M} = Avp, Acc) ->
      case pack_arity(Name, M) of
          0 ->
              {Rec, Failed} = Acc,
              {Rec, [{if M -> 5001; true -> 5008 end, Avp} | Failed]};
  