At this point I think we understand each other's points, and I will wait
for Michael to comment as pen-holder.
Thank you for the prompt response and discussion.
Yours,
Joel
PS: While I sympathize with your reaction to paying for standards from
other SDOs, that is not what determines whether we reference them, or
whether those references are normative. No mater how much we wish
otherwise :-)
On 8/10/18 12:12 PM, Toerless Eckert wrote:
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
