ppp draft issues - ff03 or no ff03

Hi all,
Another detail on the PPP draft for L2TPv3:

In section 4.3, the current draft requires each end to remove
the ff03 (ACF) from the PPP packet before sending it through
the tunnel; with the receiving end restoring (or inserting)
the ff03 if needed downstream from it.

This text creates a problem for a LAC interfacing to a link
that can use ACFC: unless the LAC snoops the LCP negotiation,
it has no way to know whether ACFC is in effect and so it would
not know for certain whether the ff03 should be inserted on
packets going to the client.

Since snooping LCP is a dangerous business for a number of
reasons, that should be off our list of options.

We have a few alternatives:
1) Neither end adds nor removes any bytes.
   In other words, the packet on the tunnel is identical
   to the packet on the wire to/from the client.

   The disadvantage here is that the LNS needs to know the
   requirements of the link from the LAC (eg, if it is ATM,
   the ACF field should be eliminated, etc).
   I do not advocate this alternative.

2) ACF MUST be eliminated before sending the packet on the
   tunnel.

   In this case, the LAC needs to know whether the ACF must be
   reinserted on output to the client. For this, we should
   require implementation of RFC 3437 so the LAC can learn
   the negotiated ACFC setting.

   Note that for robustness reasons, the receiver SHOULD be
   able to handle incoming packets that have ff03 or not.

   This alternative seems more reasonable to me.


Note that RFC2661 did not mandate this ff03 elimination, so
keeping this would be a departure from that RFC and a fairly
obscure interop difference.

Opinions, please?

-Ignacio

PS: This draft expired recently but a new one is in the works.
In the meantime, you can look here for the last version:
http://tools.ietf.org/html/draft-ietf-l2tpext-l2tp-ppp-05