Re: [OSPF] WG Last Call for Supporting Authentication Trailer for OSPFv3 - draft-ietf-ospf-auth-trai

["Michael Barnes" <[e-mail]>]

------ Original Message ------
Received: Wed, 13 Apr 2011 10:29:47 AM PDT
From: "Bhatia, Manav (Manav)" <[e-mail]>
To: Acee Lindem <[e-mail]>Cc: "[e-mail]" <[e-mail]>
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