ACK of register and purge packets

[Bruce Cole <[e-mail]>]

> Alignment with 1577++ and ipmc are good reasons but they are not the best
> reason.  There is currently no method for acknowledgement of a registration
> in the current NHRP specification which IMHO is a fundamental flaw.  If you
> are not registered you are not participating in the protocol fully as a
> client.  Therefore it is extrememly important that you are registered and
> that you can proceed as if that were the case.  Registration cries out for
> an acknowledgement mechanism.  Using the SRC=DST in request and reply
> packets fixes this hole and aligns this protocol with other address
> resolution protocols. Why replicate code in the registration packet
> processing when a simple "if" statement would suffice?

Ah, now I see.  Acknowledgment of registration packets is a good reason to do
this.  Personally I'd still rather see the registration packets use a separate
type code, and then just add an ACK bit instead of using the SRC=DST scheme.
But I won't argue further if I'm alone in this.

> Contrast this with a Purge request.  "There is no real need for an
> acknowledgement here since we already have to deal with the scenario in
> which the purge is never sent because the station that should have sent the
> purge crashed."  The only true way to be sure a cache entry has been purged
> is for the entry to time out. BTW, you did not address this in the note you
> sent out a few days ago.  I had suggested the removal of the ack for purges
> but this was not mentioned in your note of 10/31 where you included the new
> v5 of the NHRP spec.

Sorry, it was an oversight that I didn't list this as a proposal that came up
since the last IETF.  I didn't see any further discussion of your proposal.
Comments?

I also managed to leave off an additional proposal from the list I sent out:
    Proposal to make the internetwork layer address length 
    field be specified on a per address basis rather than one per packet.