Re: [Anima] [Closed] Re: Shepherd review draft-ietf-anima-bootstrapping-keyinfra-09
On 20/06/2018 09:50, Toerless Eckert wrote: > Brian, Michael: For the purpose of BRSKI the only relevant aspect of the > ANI is that it is assumed to be a system that support BRSKI and ACP, > and then the document starts to define a bunch of requirements against > BRSKI, which instead of saying ANI could equally say "BRSKI devices that > also support ACP". So BRSKi really does not need to try to refer to a > complete definition of ANI or attempt one by itself, but rather clarify > the relationship to ANI that is used in the BRSKI document. > > To maintain the independence of BRSKI from unnecessary normative > references, maybe something like the following: I don't really care, but in any case the reference model will always be a "background reading" sort of reference, i.e. Informative. Brian > > The Autonomic Network Infrastructure consists > of devices supporting both BRSKI and target="I.D.ietf-anima-autonomic-control-plane"> (ACP). > In ANI devices, BRSKI relies ACP to connect BRSKI Registrar and > BRSKI Proxies. > > Not sure what value a reference to the reference model would have here in > this terminology. > > Cheers > Toerless > > On Wed, Jun 20, 2018 at 08:27:04AM +1200, Brian E Carpenter wrote: >> On 20/06/2018 03:38, Michael Richardson wrote: >>> On 31/05/18 04:23 PM, Brian E Carpenter wrote: On 01/06/2018 07:31, Michael Richardson wrote: > > Toerless Eckert wrote: > > On Thu, May 31, 2018 at 03:07:15PM -0400, Michael Richardson wrote: > >> > I would prefer to have the simple definition "ANI == systems > that support > >> > both BRSKI and ACP" in the doc itself. Threre is really no > single authoritative > >> > normative document for ANI, so it should simply be stated > equally in BRSKI and > >> > ACP. Rest of text is fine. > >> > >> I'm not getting what you are suggesting. > >> I think you are saying that we shouldn't point at ACP for the ANI > term, but > >> rather define it ourselves? > > > Yes. > > okay, I've copied text: > > ANI: "Autonomic Network Infrastructure". The ANI is the > infrastructure to enable Autonomic Networks. It includes ACP, > BRSKI and GRASP. Every Autonomic Network includes the ANI, > but not every ANI network needs to include autonomic functions > beyond the ANI (nor intent). An ANI network without further > autonomic functions can for example support secure zero touch > bootstrap > and stable connectivity for SDN networks - see > [I-D.ietf-anima-stable-connectivity] > Wrong answer, IMHO. draft-ietf-anima-reference-model defines the ANI at some length. That should be the (informative) reference for basic terminology. >>> >>> I think that you'd like us to change the text to say: >>> >>> The Autonomic Network Infrastructure as >>> defined by . >>> This document details specific requirements for pledges, >>> proxies and registrars when they are part of an ANI. >>> >>> is this correct? Or did you want us to retain some other words above? >>> >> >> Personally, I'm happy with the reference (and with it being informational). >> Duplication of definitions always creates a risk of confusion. >> >>Brian >> >> ___ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima > ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] [Closed] Re: Shepherd review draft-ietf-anima-bootstrapping-keyinfra-09
Brian, Michael: For the purpose of BRSKI the only relevant aspect of the ANI is that it is assumed to be a system that support BRSKI and ACP, and then the document starts to define a bunch of requirements against BRSKI, which instead of saying ANI could equally say "BRSKI devices that also support ACP". So BRSKi really does not need to try to refer to a complete definition of ANI or attempt one by itself, but rather clarify the relationship to ANI that is used in the BRSKI document. To maintain the independence of BRSKI from unnecessary normative references, maybe something like the following: The Autonomic Network Infrastructure consists of devices supporting both BRSKI and (ACP). In ANI devices, BRSKI relies ACP to connect BRSKI Registrar and BRSKI Proxies. Not sure what value a reference to the reference model would have here in this terminology. Cheers Toerless On Wed, Jun 20, 2018 at 08:27:04AM +1200, Brian E Carpenter wrote: > On 20/06/2018 03:38, Michael Richardson wrote: > > On 31/05/18 04:23 PM, Brian E Carpenter wrote: > >> On 01/06/2018 07:31, Michael Richardson wrote: > >>> > >>> Toerless Eckert wrote: > >>> > On Thu, May 31, 2018 at 03:07:15PM -0400, Michael Richardson wrote: > >>> >> > I would prefer to have the simple definition "ANI == systems > >>> that support > >>> >> > both BRSKI and ACP" in the doc itself. Threre is really no > >>> single authoritative > >>> >> > normative document for ANI, so it should simply be stated > >>> equally in BRSKI and > >>> >> > ACP. Rest of text is fine. > >>> >> > >>> >> I'm not getting what you are suggesting. > >>> >> I think you are saying that we shouldn't point at ACP for the ANI > >>> term, but > >>> >> rather define it ourselves? > >>> > >>> > Yes. > >>> > >>> okay, I've copied text: > >>> > >>> ANI: "Autonomic Network Infrastructure". The ANI is the > >>> infrastructure to enable Autonomic Networks. It includes ACP, > >>> BRSKI and GRASP. Every Autonomic Network includes the ANI, > >>> but not every ANI network needs to include autonomic functions > >>> beyond the ANI (nor intent). An ANI network without further > >>> autonomic functions can for example support secure zero touch > >>> bootstrap > >>> and stable connectivity for SDN networks - see > >>> [I-D.ietf-anima-stable-connectivity] > >>> > >> > >> Wrong answer, IMHO. > >> > >> draft-ietf-anima-reference-model defines the ANI at some length. > >> That should be the (informative) reference for basic terminology. > > > > I think that you'd like us to change the text to say: > > > > The Autonomic Network Infrastructure as > > defined by . > > This document details specific requirements for pledges, > > proxies and registrars when they are part of an ANI. > > > > is this correct? Or did you want us to retain some other words above? > > > > Personally, I'm happy with the reference (and with it being informational). > Duplication of definitions always creates a risk of confusion. > >Brian > > ___ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- --- t...@cs.fau.de ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] [Closed] Re: Shepherd review draft-ietf-anima-bootstrapping-keyinfra-09
On 20/06/2018 03:38, Michael Richardson wrote: > On 31/05/18 04:23 PM, Brian E Carpenter wrote: >> On 01/06/2018 07:31, Michael Richardson wrote: >>> >>> Toerless Eckert wrote: >>> > On Thu, May 31, 2018 at 03:07:15PM -0400, Michael Richardson wrote: >>> >> > I would prefer to have the simple definition "ANI == systems that >>> support >>> >> > both BRSKI and ACP" in the doc itself. Threre is really no single >>> authoritative >>> >> > normative document for ANI, so it should simply be stated equally >>> in BRSKI and >>> >> > ACP. Rest of text is fine. >>> >> >>> >> I'm not getting what you are suggesting. >>> >> I think you are saying that we shouldn't point at ACP for the ANI >>> term, but >>> >> rather define it ourselves? >>> >>> > Yes. >>> >>> okay, I've copied text: >>> >>> ANI: "Autonomic Network Infrastructure". The ANI is the >>> infrastructure to enable Autonomic Networks. It includes ACP, >>> BRSKI and GRASP. Every Autonomic Network includes the ANI, >>> but not every ANI network needs to include autonomic functions >>> beyond the ANI (nor intent). An ANI network without further >>> autonomic functions can for example support secure zero touch >>> bootstrap >>> and stable connectivity for SDN networks - see >>> [I-D.ietf-anima-stable-connectivity] >>> >> >> Wrong answer, IMHO. >> >> draft-ietf-anima-reference-model defines the ANI at some length. >> That should be the (informative) reference for basic terminology. > > I think that you'd like us to change the text to say: > > The Autonomic Network Infrastructure as > defined by . > This document details specific requirements for pledges, > proxies and registrars when they are part of an ANI. > > is this correct? Or did you want us to retain some other words above? > Personally, I'm happy with the reference (and with it being informational). Duplication of definitions always creates a risk of confusion. Brian ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] [Closed] Re: Shepherd review draft-ietf-anima-bootstrapping-keyinfra-09
On 31/05/18 04:23 PM, Brian E Carpenter wrote: On 01/06/2018 07:31, Michael Richardson wrote: Toerless Eckert wrote: > On Thu, May 31, 2018 at 03:07:15PM -0400, Michael Richardson wrote: >> > I would prefer to have the simple definition "ANI == systems that support >> > both BRSKI and ACP" in the doc itself. Threre is really no single authoritative >> > normative document for ANI, so it should simply be stated equally in BRSKI and >> > ACP. Rest of text is fine. >> >> I'm not getting what you are suggesting. >> I think you are saying that we shouldn't point at ACP for the ANI term, but >> rather define it ourselves? > Yes. okay, I've copied text: ANI: "Autonomic Network Infrastructure". The ANI is the infrastructure to enable Autonomic Networks. It includes ACP, BRSKI and GRASP. Every Autonomic Network includes the ANI, but not every ANI network needs to include autonomic functions beyond the ANI (nor intent). An ANI network without further autonomic functions can for example support secure zero touch bootstrap and stable connectivity for SDN networks - see [I-D.ietf-anima-stable-connectivity] Wrong answer, IMHO. draft-ietf-anima-reference-model defines the ANI at some length. That should be the (informative) reference for basic terminology. I think that you'd like us to change the text to say: The Autonomic Network Infrastructure as defined by . This document details specific requirements for pledges, proxies and registrars when they are part of an ANI. is this correct? Or did you want us to retain some other words above? ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] [Closed] Re: Shepherd review draft-ietf-anima-bootstrapping-keyinfra-09
Brian E Carpenter wrote: >> > An RFC specifying that would therefore have to declare itself to be >> > an update of GRASP. I don't think this is a big deal. It would become >> >> I think that you mean, update of BRSKI rather than "update of GRASP". > Possibly both, because GRASP already defines > transport-proto = IPPROTO_TCP / IPPROTO_UDP > IPPROTO_TCP = 6 > IPPROTO_UDP = 17 Ah right. I just don't care... someone else decide and tell me what. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] [Closed] Re: Shepherd review draft-ietf-anima-bootstrapping-keyinfra-09
On 01/06/2018 07:35, Michael Richardson wrote: > > Toerless Eckert wrote: > > 1. The GRASP specification of 4.1.1 should only describe what is > required > > and valid for the standard of GRASP objective, which is the TCP proxy. > > > Appendix C proxy option is not full/formally worked out, thats why > > its in an appendix. If the authors want to propose a formal GRASP > > It's not mandatory to implement, which is why it got pushed to the appendix. > If it wasn't worked out, then it would be removed. > > > 2. A value of IPPROTO_IPV6 which i guess would be desired for an > > appendix C proxy would IMHO be an extension to whats defined in GRASP. > > I think you mean, "defined in the GRASP object defined in CDDL", here. > > > An RFC specifying that would therefore have to declare itself to be > > an update of GRASP. I don't think this is a big deal. It would become > > I think that you mean, update of BRSKI rather than "update of GRASP". Possibly both, because GRASP already defines transport-proto = IPPROTO_TCP / IPPROTO_UDP IPPROTO_TCP = 6 IPPROTO_UDP = 17 On 01/06/2018 07:09, Toerless Eckert wrote: > Btw: The specific issue of extening transport options could have been > avoided by permitting 0..255 in GRASP. Except that it would implicitly lock us into to a particular IANA registry, allowing strange things like transport-proto = IPPROTO_TP and who's to say that we might not also want things like transport-proto = HTTPS I agree that we might want to revisit this in a GRASP update. Brian > ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] [Closed] Re: Shepherd review draft-ietf-anima-bootstrapping-keyinfra-09
On 01/06/2018 07:31, Michael Richardson wrote: > > Toerless Eckert wrote: > > On Thu, May 31, 2018 at 03:07:15PM -0400, Michael Richardson wrote: > >> > I would prefer to have the simple definition "ANI == systems that > support > >> > both BRSKI and ACP" in the doc itself. Threre is really no single > authoritative > >> > normative document for ANI, so it should simply be stated equally in > BRSKI and > >> > ACP. Rest of text is fine. > >> > >> I'm not getting what you are suggesting. > >> I think you are saying that we shouldn't point at ACP for the ANI > term, but > >> rather define it ourselves? > > > Yes. > > okay, I've copied text: > >ANI: "Autonomic Network Infrastructure". The ANI is the > infrastructure to enable Autonomic Networks. It includes ACP, > BRSKI and GRASP. Every Autonomic Network includes the ANI, > but not every ANI network needs to include autonomic functions > beyond the ANI (nor intent). An ANI network without further > autonomic functions can for example support secure zero touch > bootstrap > and stable connectivity for SDN networks - see > [I-D.ietf-anima-stable-connectivity] > Wrong answer, IMHO. draft-ietf-anima-reference-model defines the ANI at some length. That should be the (informative) reference for basic terminology. Brian ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] [Closed] Re: Shepherd review draft-ietf-anima-bootstrapping-keyinfra-09
Toerless Eckert wrote: > 1. The GRASP specification of 4.1.1 should only describe what is required > and valid for the standard of GRASP objective, which is the TCP proxy. > Appendix C proxy option is not full/formally worked out, thats why > its in an appendix. If the authors want to propose a formal GRASP It's not mandatory to implement, which is why it got pushed to the appendix. If it wasn't worked out, then it would be removed. > 2. A value of IPPROTO_IPV6 which i guess would be desired for an > appendix C proxy would IMHO be an extension to whats defined in GRASP. I think you mean, "defined in the GRASP object defined in CDDL", here. > An RFC specifying that would therefore have to declare itself to be > an update of GRASP. I don't think this is a big deal. It would become I think that you mean, update of BRSKI rather than "update of GRASP". -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] [Closed] Re: Shepherd review draft-ietf-anima-bootstrapping-keyinfra-09
Toerless Eckert wrote: > On Thu, May 31, 2018 at 03:07:15PM -0400, Michael Richardson wrote: >> > I would prefer to have the simple definition "ANI == systems that support >> > both BRSKI and ACP" in the doc itself. Threre is really no single authoritative >> > normative document for ANI, so it should simply be stated equally in BRSKI and >> > ACP. Rest of text is fine. >> >> I'm not getting what you are suggesting. >> I think you are saying that we shouldn't point at ACP for the ANI term, but >> rather define it ourselves? > Yes. okay, I've copied text: ANI: "Autonomic Network Infrastructure". The ANI is the infrastructure to enable Autonomic Networks. It includes ACP, BRSKI and GRASP. Every Autonomic Network includes the ANI, but not every ANI network needs to include autonomic functions beyond the ANI (nor intent). An ANI network without further autonomic functions can for example support secure zero touch bootstrap and stable connectivity for SDN networks - see [I-D.ietf-anima-stable-connectivity] -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] [Closed] Re: Shepherd review draft-ietf-anima-bootstrapping-keyinfra-09
On Thu, May 31, 2018 at 03:07:15PM -0400, Michael Richardson wrote: > > I would prefer to have the simple definition "ANI == systems that > support > > both BRSKI and ACP" in the doc itself. Threre is really no single > authoritative > > normative document for ANI, so it should simply be stated equally in > BRSKI and > > ACP. Rest of text is fine. > > I'm not getting what you are suggesting. > I think you are saying that we shouldn't point at ACP for the ANI term, but > rather define it ourselves? Yes. Thanks Toerless > >> > Without this term we can not nail down the explicit requirements > against > >> > ANI Pledges, Proxies, Registrars that we need from the document (and > distinguish > >> > from requirements against any non-ANI adaptation of BRSKI). I added > according > >> > comments into other parts of the doc. > >> > >> > g) Please replace "MASA server" with "MASA service" everywhere. > >> > >> I prefer to just say "MASA" actually. > >> Are you okay with that? > > > Yes. There are a few leftovers of "MASA server" in -14 though. Pls fix. > > fixed them all, I hope. > > >> There is no requirement that the Join Registrar is also the EST for the > >> purposes of ongoing certificate renewal. I don't know if you are > speaking > >> about certificate lifetime management (renewal, etc.) when you say > >> "EST Enrollment service". I'll assume that you mean that for the > moment. > >> > >> In a big network I would want the roles (bootstrap and initial > certificate, > >> vs certificate renewal) split up. > > > Lets in any case consider this issue closed or BRSKI, because it loooks > now like > > scope creep to me to discuss it for this draft. I'll probably have this > discussion > > on my hand for ACP anyhow, because (only) ACP needs to be concerned > about > > initial bootstrap and renewal (just working through that in ACP doc > because > > of the ongoing review of it). > > okay. > > > 4.1.1: > > >> transport-proto = IPPROTO_TCP / IPPROTO_UDP / IPPROTO_IPV6 > > > The way i see it, the normative approach with TCP circuit proxy would > > always only have TCP, right, e.g.: the line should say > > > transport-proto = IPPROTO_TCP ; Not considering non-normative > > ; options like Appendix C. > > I'll reply to Brian. > > -- > ] Never tell me the odds! | ipv6 mesh networks > [ > ] Michael Richardson, Sandelman Software Works| network architect > [ > ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails > [ > > ___ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- --- t...@cs.fau.de ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] [Closed] Re: Shepherd review draft-ietf-anima-bootstrapping-keyinfra-09
Brian E Carpenter wrote: > On 31/05/2018 13:53, Toerless Eckert wrote: > ... >> 4.1.1: >> >>> transport-proto = IPPROTO_TCP / IPPROTO_UDP / IPPROTO_IPV6 >> >> The way i see it, the normative approach with TCP circuit proxy would >> always only have TCP, right, e.g.: the line should say >> >> transport-proto = IPPROTO_TCP ; Not considering non-normative >> ; options like Appendix C. > There's kind of a general point about extensibility here. > We're using CDDL as a normative notation (which may well become > slightly awkward unless the CDDL draft advances soon), but are > we intending to interpret it formally? > In other words, > if we later want to add " / IPPROTO_UDP / IPPROTO_IPV6" > to implementations, do we have to circle back and update the BRSKI > RFC? (And so on for any other documents that cite intrinsically > extensible items like transport-proto.) I don't mind saying that only IPPROTO_TCP is normative in the CDDL, but I think that the point of listing a few options here is so that implementations actually check the value. > One option in this case is to include "/ IPPROTO_UDP / IPPROTO_IPV6" > in the syntax with a specific note that they are not currently > defined and MUST be treated as errors if received. I prefer this to the not listing them. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] [Closed] Re: Shepherd review draft-ietf-anima-bootstrapping-keyinfra-09
Toerless Eckert wrote: >> > f) IMPORTANT: Please add/define the term "ANI" >> >> > ANI - "Autonomic Network Infrastructure". Systems that support both BRSKI and >> > Autonomic Control plane - ACP ([I-D.ietf-anima-autonomic-control-plane]). ANI >> > systems (pledges, proxies, registrar) have specific requirements detailled in >> > the document. >> >> The Autonomic Network Infrastructure as >> defined by > />. This document details specific requirements for pledges, >> proxies and registrars when they are part of an ANI. >> >> Does this work for you? > I would prefer to have the simple definition "ANI == systems that support > both BRSKI and ACP" in the doc itself. Threre is really no single authoritative > normative document for ANI, so it should simply be stated equally in BRSKI and > ACP. Rest of text is fine. I'm not getting what you are suggesting. I think you are saying that we shouldn't point at ACP for the ANI term, but rather define it ourselves? >> > Without this term we can not nail down the explicit requirements against >> > ANI Pledges, Proxies, Registrars that we need from the document (and distinguish >> > from requirements against any non-ANI adaptation of BRSKI). I added according >> > comments into other parts of the doc. >> >> > g) Please replace "MASA server" with "MASA service" everywhere. >> >> I prefer to just say "MASA" actually. >> Are you okay with that? > Yes. There are a few leftovers of "MASA server" in -14 though. Pls fix. fixed them all, I hope. >> There is no requirement that the Join Registrar is also the EST for the >> purposes of ongoing certificate renewal. I don't know if you are speaking >> about certificate lifetime management (renewal, etc.) when you say >> "EST Enrollment service". I'll assume that you mean that for the moment. >> >> In a big network I would want the roles (bootstrap and initial certificate, >> vs certificate renewal) split up. > Lets in any case consider this issue closed or BRSKI, because it loooks now like > scope creep to me to discuss it for this draft. I'll probably have this discussion > on my hand for ACP anyhow, because (only) ACP needs to be concerned about > initial bootstrap and renewal (just working through that in ACP doc because > of the ongoing review of it). okay. > 4.1.1: >> transport-proto = IPPROTO_TCP / IPPROTO_UDP / IPPROTO_IPV6 > The way i see it, the normative approach with TCP circuit proxy would > always only have TCP, right, e.g.: the line should say > transport-proto = IPPROTO_TCP ; Not considering non-normative > ; options like Appendix C. I'll reply to Brian. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] [Closed] Re: Shepherd review draft-ietf-anima-bootstrapping-keyinfra-09
On 31/05/2018 13:53, Toerless Eckert wrote: > 4.1.1: > >> transport-proto = IPPROTO_TCP / IPPROTO_UDP / IPPROTO_IPV6 > > The way i see it, the normative approach with TCP circuit proxy would > always only have TCP, right, e.g.: the line should say > > transport-proto = IPPROTO_TCP ; Not considering non-normative >; options like Appendix C. There's kind of a general point about extensibility here. We're using CDDL as a normative notation (which may well become slightly awkward unless the CDDL draft advances soon), but are we intending to interpret it formally? In other words, if we later want to add " / IPPROTO_UDP / IPPROTO_IPV6" to implementations, do we have to circle back and update the BRSKI RFC? (And so on for any other documents that cite intrinsically extensible items like transport-proto.) One option in this case is to include "/ IPPROTO_UDP / IPPROTO_IPV6" in the syntax with a specific note that they are not currently defined and MUST be treated as errors if received. Brian ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
