On Fri, Aug 10, 2018 at 10:12:37AM -0400, Joel M. Halpern wrote: > > Imho, the reference model text is correct. Just like in the non-autonomic > > input (third bullet item), this vendor-redirect/cloud-registrar would > > lead to an automatically set up remote ACP peer thats enterred into the > > adjacency table. > <jmh>I can't find anything in the bootstrap document redirect section that > suggests the behavior you indicate.</jmh> Thats true, the BRSKI documents defines key cryptographic aspects of a cloud registrar and there are a lot of options for a full solution, and the conclusion was to do these things as followup work from BRSKI / ACP. > > Hmm.. ACP is an overlay network that tries to match the underlay when > > it can (link-local-adjacencies) and that uses remote adjacencies when > > it needs to go over non-autonomic parts of the network. > > > > Not quite sure what text to most easily add to make this any clearer.. > > Any suggestions ? > <jmh>The text mixes both uses of adjacency without distinction. One could > seaprate the usage. One could add explanatory text. Something to clarify > the situation. </jmH> Hmm.. it does clearly distinguish the three cases through bullet points, each one describing one of the three cases. Maybe i'm just confused what you think is missing and Michael immediately sees it. > > 802.1AR as already referenced by ACP > <jmh>My only concern is that it appears to need to be a normative reference > here, as it seems to be needed for understanding this document. </jmh> I don't think its necessary to read 802.1AR to understand the security reason why its used. BRSKI does that explanation, and BRSKI is already normative. Personally, i dislike to have "pay-to-read" documents as normative references, as much as i do appreciate every SDOs need to finance itself. > > The security model of nodes without writable persistent storage comes > > to mind as use-case for non-persistent LDevID (boot from DVD/RO-Flash > > only, power-cycle recreates known "good" state on device). > > <jmh>The text as written implicitly requires persistent storage. If the > intention is to allow both models (as I would hope) please tune the text in > section 3.3.2. Maybe a sentence at the end: On devices without persistent storage for the LDevID, a powercycle should behave like a factory reset. > > chair hat on: > > There can not be a draft covering this yet, because the current > > ANIMA charter didn't allow us to do this. We've got individual drafts > > lined up for this topic, we just need to get through the rechartering, > > we have started the discuss with our AD and wanted to then bring this to > > the WG. > <jmh>How can this informational documents say "ASA must ..." if there is no > definition of what they must do. If the WG has not addressed this topic, > then reword this. Maybe "It is expected that wide deployment in the future > will need ..." </jmh> I think 6.1 is just missing the (*). Cheers Toerless
