So, page 21 says:

> ... This provides an  
> earliest date which is reasonable.  Call this the current     
> reasonable date (CRD).  This value SHOULD NOT be stored in any        
> way, and applies to the current Registration attempt only.    
> Subsequent attempts MUST follow this proceedure again from    
> scratch.  The current reasonable date may only increase.

Firstly, "SHOULD NOT be stored in any way" surely means
"SHOULD NOT be permanently stored in any way", because
it must certainly be temporarily stored during the current
registration attempt.

Secondly, "The current reasonable date may only increase."
is unverifiable unless the previous CRD is stored for
comparison.

So I think the "SHOULD NOT" clause has to go. Perhaps you
mean:
  This value MUST NOT be used for any future Registration attempt.

Regards
   Brian

On 27/03/2018 10:48, internet-dra...@ietf.org wrote:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Autonomic Networking Integrated Model and 
> Approach WG of the IETF.
> 
>         Title           : Bootstrapping Remote Secure Key Infrastructures 
> (BRSKI)
>         Authors         : Max Pritikin
>                           Michael C. Richardson
>                           Michael H. Behringer
>                           Steinthor Bjarnason
>                           Kent Watsen
>       Filename        : draft-ietf-anima-bootstrapping-keyinfra-13.txt
>       Pages           : 91
>       Date            : 2018-03-26
> 
> Abstract:
>    This document specifies automated bootstrapping of a remote secure
>    key infrastructure (BRSKI) using manufacturer installed X.509
>    certificate, in combination with a manufacturer's authorizing
>    service, both online and offline.  Bootstrapping a new device can
>    occur using a routable address and a cloud service, or using only
>    link-local connectivity, or on limited/disconnected networks.
>    Support for lower security models, including devices with minimal
>    identity, is described for legacy reasons but not encouraged.
>    Bootstrapping is complete when the cryptographic identity of the new
>    key infrastructure is successfully deployed to the device but the
>    established secure connection can be used to deploy a locally issued
>    certificate to the device as well.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-13
> https://datatracker.ietf.org/doc/html/draft-ietf-anima-bootstrapping-keyinfra-13
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-bootstrapping-keyinfra-13
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> I-D-Announce mailing list
> i-d-annou...@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 

_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Reply via email to