------ Original Message ------ Received: Wed, 13 Apr 2011 10:29:47 AM PDT From: "Bhatia, Manav (Manav)" <[email protected]> To: Acee Lindem <[email protected]>Cc: "[email protected]" <[email protected]> Subject: Re: [OSPF] WG Last Call for Supporting Authentication Trailer for OSPFv3 - draft-ietf-ospf-auth-trai
> Ok, I give up - lets increase the sequence space to 64 bits! I seem to be the >only one who is opposing adding something that I have myself proposed in some > other draft! :) > > I am not very comfortable with mandating that upper 32 bits should be retrieved >from the non volatile storage because there may be devices that cannot do this It is okay if this is not mandated. I am quite happy that it is an option. > (i.e. may not be able to store data in nvram) and they will thus become non > compliant to the about-to-be-RFC. How does a device that's wants to do AT but > cant store info in nvram ever become compliant to this standard? > > I see two ways to deal with this: > > (1) The text on upper 32 bits should be a MAY and not a MUST, so that implementations that don't have nvram or don't want to implement this part of the spec still remain compliant to the standard. > > OR > > (2) We just increase the sequence space to 64 bits and don't say anything about it. We let a later RFC define how the upper 32 bits may be populated. > > Cheers, Manav I suggest the draft simply increases the space but doesn't mandate how it is used. However, the draft can offer suggestions that the upper 32-bits MAY be generated in some way such as nvram or date or whatever. I don't think it really matters exactly how the value is derived, and there are multiple methods that would work equally well. I agree that the draft shouldn't mandate which method is used. The draft could even say that if a vendor chooses they may leave the upper 32-bits as zeros. Thanks, Michael _______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
