Re: [Anima] [Cbor] CDDL-02 section 2.2.2 choices
Brian E Carpenter wrote: > On 20/06/2018 05:53, Michael Richardson wrote: >> >> Carsten Bormann wrote: >> > 2.2.2 says: >> >> >> It is not an error if a name is first used with a "/=" or "//=" >> >> (there is no need to “create it" with "="). >> >> > The intention is indeed to say that no initial rule with a “=“ is needed. >> > Any ideas how we can clarify this some more? >> >> Neither Max nor I saw this while we were perusing this part. >> May I suggest that it be moved to be the second paragraph? >> >> > You could also make use of the convention (not currently checked by any >> > tool, but that could be done) to mark an extension point with a dollar >> > sign: >> >> > $transport-proto /= IPPROTO_TCP >> >> > (See section 3.9 for more about that convention.) >> >> Ah, interesting. thank you. > However: I suggest not using that in the BRSKI draft. Our emergency plan > if CDDL is not yet close to being an RFC is to add a normative appendix > to GRASP specifying the subset of CDDL that we use, and I'd like to > keep that subset as small as possible. > Even better, CBOR could wrap up the CDDL spec in Montreal. I don't believe that BRSKI will enter the RFC-EDITOR queue before CDDL. If it does, we could fix stuff as you suggest. -- 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 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] WG Last Call on draft-ietf-anima-bootstrapping-keyinfra-15
We had positive feedback on the last call, and no negative feedback. For the time being (or until someone with more experience than me shows me a better option ;-), i will not declare the last-call finished, until the authors had a chance to answer how they want to resolve the last-call comment from me about the only mayor issue, which was how to make GRASP announcemments for IP-in-IP work. As said in before, any solution that works is fine. Including moving IP-in-IP out to another doc. Cheers toerless On Thu, May 31, 2018 at 03:56:08AM +0200, Toerless Eckert wrote: > Dear ANIMA WG, > > After thorough review and discussions on the mailing list and in bootstrap > meetings, leading to the -15 version the authors and WG chairs think the draft > is now mature enough for working group last call. > > This e-mail starts a two-weeks period for evaluation of this document by the > WG. > > Please provide your feedback on the ANIMA mailing list by end of June 14th, > 2018. > > Thanks and best regards > > Toerless (for the ANIMA chairs). > > ___ > 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] references to code ?
I did not push this further because it seemed non-obvious to me after the discussion here, what would be needed to include the information in the final RFC and whether that would be appreciated by others. I hope in the absence of suhc text, there is motivation for a small followup RFC with implementation experience after we have the RFC. Wrt to providing implementation information as input to the reviewers, i will be happy to include it into the shepherd writeup for the IESG once i can close the last call. Cheers Toerless On Tue, Jun 19, 2018 at 11:31:50AM -0400, Michael Richardson wrote: > On 31/05/18 02:43 PM, Toerless Eckert wrote: > > Thanks, Eliot > > > > Good point, forgot to ask/mention this point in my previous emails. > > > > As an ANIMA contributor, i would love for a draft/->RFC like BRSKI to > > mention known existing implementations, especially open source, even if > > just PoC. > > I did not hear a WG consensus to add a section on known implementations. > > I did not object to it, but found it a waste of time as it will be removed > before publication. I note that the Shepherd could just reference this > thread which contains a number of references to implementations. > > ___ > 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, 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] [Cbor] CDDL-02 section 2.2.2 choices
On 20/06/2018 05:53, Michael Richardson wrote: > > Carsten Bormann wrote: > > 2.2.2 says: > > >> It is not an error if a name is first used with a "/=" or "//=" > >> (there is no need to “create it" with "="). > > > The intention is indeed to say that no initial rule with a “=“ is > needed. > > Any ideas how we can clarify this some more? > > Neither Max nor I saw this while we were perusing this part. > May I suggest that it be moved to be the second paragraph? > > > You could also make use of the convention (not currently checked by any > > tool, but that could be done) to mark an extension point with a dollar > > sign: > > > $transport-proto /= IPPROTO_TCP > > > (See section 3.9 for more about that convention.) > > Ah, interesting. thank you. However: I suggest not using that in the BRSKI draft. Our emergency plan if CDDL is not yet close to being an RFC is to add a normative appendix to GRASP specifying the subset of CDDL that we use, and I'd like to keep that subset as small as possible. Even better, CBOR could wrap up the CDDL spec in Montreal. Regards 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 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] transport-proto IANA considerations
On 20/06/2018 03:29, Michael Richardson wrote: > On 19/06/18 11:08 AM, Michael Richardson wrote: >> From our document: >> >> transport-proto /= IPPROTO_TCP ; note this is an extensible CDDL choice >> ; and can be added to in subsequent >> ; specifications using the /= and //= > In further discussion about whether or not we now need an IANA registry > in BRSKI to deal with this, we concluded that we did not, because GRASP > already dealt with that in section 2.9.5.1, note 3, so we decided to > refer to that instead: > > transport-proto /= IPPROTO_TCP ; note this can be any value from the > ; IANA protocol registry, as per > ; [GRASP] section 2.9.5.1, note 3. > > > We have also removed all referenced to IPPROTO_UDP and IPPROTO_IPV6 from > the normative section. That's a great solution; and as "note 3" says we can always add an IANA registry if we want values outside 0..255 for some reason. (It's an obvious convention to use the same symbolic names as the socket API, but that doesn't seem necessary to state.) Brian ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] CDDL-02 section 2.2.2 choices
Carsten Bormann wrote: > 2.2.2 says: >> It is not an error if a name is first used with a "/=" or "//=" >> (there is no need to “create it" with "="). > The intention is indeed to say that no initial rule with a “=“ is needed. > Any ideas how we can clarify this some more? Neither Max nor I saw this while we were perusing this part. May I suggest that it be moved to be the second paragraph? > You could also make use of the convention (not currently checked by any > tool, but that could be done) to mark an extension point with a dollar > sign: > $transport-proto /= IPPROTO_TCP > (See section 3.9 for more about that convention.) Ah, interesting. thank you. -- 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 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] references to code ?
On 31/05/18 02:43 PM, Toerless Eckert wrote: Thanks, Eliot Good point, forgot to ask/mention this point in my previous emails. As an ANIMA contributor, i would love for a draft/->RFC like BRSKI to mention known existing implementations, especially open source, even if just PoC. I did not hear a WG consensus to add a section on known implementations. I did not object to it, but found it a waste of time as it will be removed before publication. I note that the Shepherd could just reference this thread which contains a number of references to implementations. ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
[Anima] transport-proto IANA considerations
On 19/06/18 11:08 AM, Michael Richardson wrote: From our document: transport-proto /= IPPROTO_TCP ; note this is an extensible CDDL choice ; and can be added to in subsequent ; specifications using the /= and //= In further discussion about whether or not we now need an IANA registry in BRSKI to deal with this, we concluded that we did not, because GRASP already dealt with that in section 2.9.5.1, note 3, so we decided to refer to that instead: transport-proto /= IPPROTO_TCP ; note this can be any value from the ; IANA protocol registry, as per ; [GRASP] section 2.9.5.1, note 3. We have also removed all referenced to IPPROTO_UDP and IPPROTO_IPV6 from the normative section. ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] CDDL-02 section 2.2.2 choices
Hi Michael, 2.2.2 says: It is not an error if a name is first used with a "/=" or "//=" (there is no need to “create it" with "="). The intention is indeed to say that no initial rule with a “=“ is needed. Any ideas how we can clarify this some more? You could also make use of the convention (not currently checked by any tool, but that could be done) to mark an extension point with a dollar sign: $transport-proto /= IPPROTO_TCP (See section 3.9 for more about that convention.) Grüße, Carsten > On Jun 19, 2018, at 17:08, Michael Richardson wrote: > > Signed PGP part > > In draft-ietf-anima-bootstrapping-keyinfra-15, we specify a protocol value > for GRASP. In this normative part of the document, there is only one choice, > but it is our intention to allow additional choices, as per section 2.2.2 > of cddl-02. > > We think that we should specify our single "choice", using /=, rather than =, > as this should clue the reader in to expect multiple values here. > > From our document: > > transport-proto /= IPPROTO_TCP ; note this is an extensible CDDL choice > ; and can be added to in subsequent > ; specifications using the /= and //= > > It is unclear in section 2.2.2 if we can say foo /= without having said > foo = 1 / 2 / 3 > previously, but it seems like it should be reasonable to do in order to > indicate that implementations should expect future values. > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > > ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
[Anima] CDDL-02 section 2.2.2 choices
In draft-ietf-anima-bootstrapping-keyinfra-15, we specify a protocol value for GRASP. In this normative part of the document, there is only one choice, but it is our intention to allow additional choices, as per section 2.2.2 of cddl-02. We think that we should specify our single "choice", using /=, rather than =, as this should clue the reader in to expect multiple values here. From our document: transport-proto /= IPPROTO_TCP ; note this is an extensible CDDL choice ; and can be added to in subsequent ; specifications using the /= and //= It is unclear in section 2.2.2 if we can say foo /= without having said foo = 1 / 2 / 3 previously, but it seems like it should be reasonable to do in order to indicate that implementations should expect future values. -- 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
