Ooopss.. diff was not pointing to absolute label for second URL, here is working one: http://tools.ietf.org//rfcdiff?url1=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/54c9c16f3444b1db13c7cb05744e543dfcdfb63b/draft-ietf-anima-autonomic-control-plane/draft-ietf-anima-autonomic-control-plane-14.txt&url2=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/57825aac69216fd01d388810ee804c7f25e8ab7d/draft-ietf-anima-autonomic-control-plane/draft-ietf-anima-autonomic-control-plane-14-jh3.txt On Wed, Jun 06, 2018 at 10:37:00PM +0200, Toerless Eckert wrote: > On Mon, May 14, 2018 at 11:15:58PM -0400, Joel M. Halpern wrote: > > (Sorry about the excess caps. Did not intentd to shout.) > > > > From some off-line disucssions, I understand that the actual address > > allocation is tied to the registration process. The registration process is > > not described in this document. > > > > As far as I can tell, the ACP does not depend upon the address allocation > > strategy. The address allocation strategy does require the ACP. And it > > requires and is closely coupled to the registration process. > > > > If that is true, the address allocation seems to be better described with > > the registration process. Which I presume is in the BRSKI document. > > > > All I would put in here is the basic ULA allocation (hash based generation) > > mechanism. > > Hi Joel (round 3) > > Here is the github version after the fixes discussed below > > https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/master/draft-ietf-anima-autonomic-control-plane/draft-ietf-anima-autonomic-control-plane-14-jh3.txt > > Here is the diff vs. the prior version (round 2) > > http://tools.ietf.org//rfcdiff?url1=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/54c9c16f3444b1db13c7cb05744e543dfcdfb63b/draft-ietf-anima-autonomic-control-plane/draft-ietf-anima-autonomic-control-plane-14.txt&url2=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/master/draft-ietf-anima-autonomic-control-plane/draft-ietf-anima-autonomic-control-plane-14-jh3.txt > > Alas (but i think for the better), after > all the questions from and discussion with you, i tried to figure out how > to best document the answers to the questions you raised, and it started > answering why we need multiple address range - because have to waste > 48/46 bits on Registrar-IDs. Ok, Why ? Because we want multiple uncoordinated > registrars. Ok, what is a registrar. Especially when ACP does not use > BRSKI, which it claims it can. And how does certificate maintenance work > when you have multiple registrars. Aka: once i started to write text to > asnwer your questions i kinda got sucked into having the spec also answer > other questions. > > So, with this rev., we now define and use the term "ACP Registrar", > and define that thats a BRSKI Registrar in ANI nodes, but it can be > anything in non-ANI ACP nodes. Does not have to be software. It could > be you, if you want the job. Maybe Netconf or other protocols that > want to compete with BRSKI. > > Actually, verified i can be a registrar a long time ago, using old > crypto PKI CLI on ACP capable routers to manually hack in certificates > with specific properties i wanted. And getting them via web interface from > a CA. > > So, i think this is a very clean solution of documentation. The normative > part of the spec now has what i think was the minimum to define the > requirements for any ACP registrar including the most simple address > allocation example. > > So, then there is an informative section explaining the need for the > multiple address spaces because of those uncoordinated registrars. > And an informative section about how you would need to set up > such uncoordinated registrars, aka: each with their own sub-CA. All > in section 10.3 now. > > Then of course the whole point you made about about ACP addresses > being identifiers or not. So i wanted to document the point that they > are, but that also meant to explain how the ACP address information > will survive in the presence of renewal and re-enrollment with a different registrar > (which may not know the nodes assigned ACP address unless its presented > during re-enrollment/renewal). Then of course the case where a cert > is revoked maybe indirectly, because the registrar was attacked, not > the ACP node gets a new cert from another registrar but of course this is > is the only case where you want it to get a certificate with new ACP > address information (because the prior registrar became untrusted so > you don't trust what ACP information it assigned). > > So, this ended up being two new normative subsections in 6.1.3 - > re-enrollment and failing certificates, describing the requirements against ACP nodes > during renewal or failure of their cert. > > The informative part of the doc also got a section about registrars documenting > hopefully the key pieces: how it works in general (so folks get > an idea how they would be built with or without BRSKI), what parameters > they need, discussion about that multi-registrar renewal and sub-CA > case, and finally a discussion about how registrars could integrate > with centralized policy control. After all, the world is SDN, so if > we'd only document the cool distributed registrar case, this wouldn't sell well > in todays world *sigh*. > > The reasoning for this new text sections is all summarized/documented in the changelog for -14. > > I'd like to point out that even though this is a bunch of additional text, > it is in no way changing the way the ACP or registrars are meant to > operate. It is really just adding missing documentation about it. > > Hope this answers your questions and resolves your discuss. > > Cheers > Toerless -- --- tte@xxxxxxxxx
