The IP over ATM Mailing List Archive by date

[Craig Partridge <craig@aland.bbn.com>]

    If we were beginning at the beginning I'd support the fixed length
    approach but at this stage I fear that the cure could be worse than 
    the disease.

Bryan:

    I'm also concerned that we don't blow up a bunch of existing ATM ARP
software without a reason.

    What I'd suggest is that we take a two step approach to the RFC 1577
revisions:

    * initially, just focus on those wording changes necessary to fix
    ambiguities and confusions in the current spec.

    * then look at more substantive changes, and work our way up from
    minor ones like, can we get rid of the InARP message at the start
    and should we change the ARP NACK format, to major ones like fixed
    formats.

I think by working this way, we'll get a chance to improve the spec and by
handling the changes in a disciplined manner (working our way from "this must
be changed" to "this should be changed" to "it would very nice if this could
be changed") we'll avoid confusion.  I think this method also maximizes folks'
chance to stand up and say "that change isn't essential and will really
hurt deployment."

Craig