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

From: "Michael Barnes" <[email-masked]>
Date: Wed, 13 Apr 2011 12:01:17 -0700

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