The Routing Over Large Clouds Mailing List Archive by date

[Carl Marcinik <carlm@fore.com>]

>> I still don't understand the need for a son-of-1577 spec to *mandate* that a
>> server implement both ATMARP and NHRP: isn't it sufficient to state
>> that there exist two protocols and that servers may come across clients
>> implementing both. This is the approach that IETF specs have always taken in
> 
>> the past and implementors decide what makes sense in their products. I don't
> 
>> believe this approach would lead to many "wrong" choices in this case.
>
>The "son-of-1577" spec mandate is based on the consensus decision(s) made at 
>the Danver's meeting in the joint rolc & ip-atm session.

Well, consensus can change based on new understanding, etc. It seems that
in the ARP/NHRP case it has.

> 
>It is still the same ATMARP from the clients perspective, please call it
>the same. 
> 
>> I agree. But in addition, I think that the 1577v2 client behaviour
>> should not mention ATMARPv1. It only needs to mention ATMARPv2. A 1577v2
>> client implementor should not need to go back and refer to 1577 itself.
>
>Especially since RFC1577++ obsoletes RFC1577.
>
>> This is an entirely seperate issue from whether a ATMARPv2 server has to 
>> understand ATMARPv1 which I think is an implementation choice.
>
>It goes without saying that I disagree with this 100%.  Backward
>compatibility is very important.  This is only an update to RFC1577
>really, not a replacement. 
>
>Mark
>