Re: [Anima] [Technical Errata Reported] RFC8995 (7263)
Rob Wilton (rwilton) wrote: > Okay, I can add a clarification to the errata to indicate that RFC 2119 > language is not required for the text to still be normative, and if > this text is updated, the other sections should be updated in a > consistent fashion. If you like. I don't have a strong opinion. Probably we should have used BCP14 language there. > An alternative resolution here is for me to reject the errata, > indicating that the text is still a normative requirement even though > it doesn’t use RFC 2119 language. Specifically, I don’t think that the > existing text is wrong, but consistently using RFC 2119 keywords may > add clarity. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] [Technical Errata Reported] RFC8995 (7263)
re: https://www.rfc-editor.org/errata/eid7263 I agree that the correct text is: idevid-issuer: The Issuer value from the pledge IDevID certificate MUST BE included to ensure unique interpretation of the serial- number. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] [Technical Errata Reported] RFC8995 (7263)
Hi Esko, Okay, I can add a clarification to the errata to indicate that RFC 2119 language is not required for the text to still be normative, and if this text is updated, the other sections should be updated in a consistent fashion. An alternative resolution here is for me to reject the errata, indicating that the text is still a normative requirement even though it doesn’t use RFC 2119 language. Specifically, I don’t think that the existing text is wrong, but consistently using RFC 2119 keywords may add clarity. Regards, Rob From: Esko Dijk Date: Monday, 15 January 2024 at 11:06 To: Rob Wilton (rwilton) , Buschart, Rufus , Michael Richardson Cc: RFC Errata System , Max Pritikin (pritikin) , tte+i...@cs.fau.de , michael.h.behrin...@gmail.com , kent+i...@watsen.net , war...@kumari.net , t...@cs.fau.de , shengji...@bupt.edu.cn , anima@ietf.org Subject: RE: [Anima] [Technical Errata Reported] RFC8995 (7263) Thanks Rob, Not sure if the 7263 got discussed on the call (probably not), but the discussion thread on it leads to your current proposal and I’m okay with that. Just on the side, I’m still wondering if this is helping overall, because for other fields there is similar wording used like “X is included” and in those other cases we don’t have errata to change these to a MUST. And all these requirements are effectively MUST. But maybe such consistency isn’t so important. The language in the given context may be just more unclear to some readers, for some fields/parameters. Esko From: Rob Wilton (rwilton) Sent: Monday, January 15, 2024 11:44 To: Buschart, Rufus ; Esko Dijk ; Michael Richardson Cc: RFC Errata System ; Max Pritikin (pritikin) ; tte+i...@cs.fau.de; michael.h.behrin...@gmail.com; kent+i...@watsen.net; war...@kumari.net; t...@cs.fau.de; shengji...@bupt.edu.cn; anima@ietf.org Subject: RE: [Anima] [Technical Errata Reported] RFC8995 (7263) Hi, I’m attempting to work through my errata backlog. For errata 7263, it looks like this was going to be discussed. Did this happen, and if so, what was the outcome please? My currently proposal is to edit the errata to change the “SHOULD BE” to “MUST be” and then mark the errata as HFDU. Does anyone have any opinions on this resolution? Regards, Rob From: Buschart, Rufus mailto:rufus.busch...@siemens.com>> Sent: Tuesday, December 13, 2022 8:11 AM To: Esko Dijk mailto:esko.d...@iotconsultancy.nl>>; Michael Richardson mailto:mcr+i...@sandelman.ca>> Cc: RFC Errata System mailto:rfc-edi...@rfc-editor.org>>; Max Pritikin (pritikin) mailto:priti...@cisco.com>>; tte+i...@cs.fau.de<mailto:tte+i...@cs.fau.de>; michael.h.behrin...@gmail.com<mailto:michael.h.behrin...@gmail.com>; kent+i...@watsen.net<mailto:kent+i...@watsen.net>; war...@kumari.net<mailto:war...@kumari.net>; Rob Wilton (rwilton) mailto:rwil...@cisco.com>>; t...@cs.fau.de<mailto:t...@cs.fau.de>; shengji...@bupt.edu.cn<mailto:shengji...@bupt.edu.cn>; anima@ietf.org<mailto:anima@ietf.org> Subject: Re: [Anima] [Technical Errata Reported] RFC8995 (7263) Hi! I do have a PTO today and will not be able to dial in ;-) Best regards Rufus From: Esko Dijk mailto:esko.d...@iotconsultancy.nl>> Sent: Tuesday, December 13, 2022 8:55:46 AM To: Buschart, Rufus (IT IPS SIP) mailto:rufus.busch...@siemens.com>>; Michael Richardson mailto:mcr+i...@sandelman.ca>> Cc: RFC Errata System mailto:rfc-edi...@rfc-editor.org>>; priti...@cisco.com<mailto:priti...@cisco.com> mailto:priti...@cisco.com>>; tte+i...@cs.fau.de<mailto:tte+i...@cs.fau.de> mailto:tte+i...@cs.fau.de>>; michael.h.behrin...@gmail.com<mailto:michael.h.behrin...@gmail.com> mailto:michael.h.behrin...@gmail.com>>; kent+i...@watsen.net<mailto:kent+i...@watsen.net> mailto:kent+i...@watsen.net>>; war...@kumari.net<mailto:war...@kumari.net> mailto:war...@kumari.net>>; rwil...@cisco.com<mailto:rwil...@cisco.com> mailto:rwil...@cisco.com>>; t...@cs.fau.de<mailto:t...@cs.fau.de> mailto:t...@cs.fau.de>>; shengji...@bupt.edu.cn<mailto:shengji...@bupt.edu.cn> mailto:shengji...@bupt.edu.cn>>; anima@ietf.org<mailto:anima@ietf.org> mailto:anima@ietf.org>> Subject: RE: [Anima] [Technical Errata Reported] RFC8995 (7263) Thanks Rufus, we even should have a call today at 17:00 CET - call-in details are here (https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fanima%2FF2Ojytj9qoxlE4XSjtMwXMf8oFs%2Fdata=05%7C01%7Crufus.buschart%40siemens.com%7C7833dd970f1b4580cfd908dadcdf735a%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638065150467953304%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=y1S2VmOjEyl6pW13kGRnzjCJTBDS%2BAZx22m9TgliFi8%3Dreserved=0
Re: [Anima] [Technical Errata Reported] RFC8995 (7263)
Thanks Rob, Not sure if the 7263 got discussed on the call (probably not), but the discussion thread on it leads to your current proposal and I’m okay with that. Just on the side, I’m still wondering if this is helping overall, because for other fields there is similar wording used like “X is included” and in those other cases we don’t have errata to change these to a MUST. And all these requirements are effectively MUST. But maybe such consistency isn’t so important. The language in the given context may be just more unclear to some readers, for some fields/parameters. Esko From: Rob Wilton (rwilton) Sent: Monday, January 15, 2024 11:44 To: Buschart, Rufus ; Esko Dijk ; Michael Richardson Cc: RFC Errata System ; Max Pritikin (pritikin) ; tte+i...@cs.fau.de; michael.h.behrin...@gmail.com; kent+i...@watsen.net; war...@kumari.net; t...@cs.fau.de; shengji...@bupt.edu.cn; anima@ietf.org Subject: RE: [Anima] [Technical Errata Reported] RFC8995 (7263) Hi, I’m attempting to work through my errata backlog. For errata 7263, it looks like this was going to be discussed. Did this happen, and if so, what was the outcome please? My currently proposal is to edit the errata to change the “SHOULD BE” to “MUST be” and then mark the errata as HFDU. Does anyone have any opinions on this resolution? Regards, Rob From: Buschart, Rufus mailto:rufus.busch...@siemens.com>> Sent: Tuesday, December 13, 2022 8:11 AM To: Esko Dijk mailto:esko.d...@iotconsultancy.nl>>; Michael Richardson mailto:mcr+i...@sandelman.ca>> Cc: RFC Errata System mailto:rfc-edi...@rfc-editor.org>>; Max Pritikin (pritikin) mailto:priti...@cisco.com>>; tte+i...@cs.fau.de<mailto:tte+i...@cs.fau.de>; michael.h.behrin...@gmail.com<mailto:michael.h.behrin...@gmail.com>; kent+i...@watsen.net<mailto:kent+i...@watsen.net>; war...@kumari.net<mailto:war...@kumari.net>; Rob Wilton (rwilton) mailto:rwil...@cisco.com>>; t...@cs.fau.de<mailto:t...@cs.fau.de>; shengji...@bupt.edu.cn<mailto:shengji...@bupt.edu.cn>; anima@ietf.org<mailto:anima@ietf.org> Subject: Re: [Anima] [Technical Errata Reported] RFC8995 (7263) Hi! I do have a PTO today and will not be able to dial in ;-) Best regards Rufus From: Esko Dijk mailto:esko.d...@iotconsultancy.nl>> Sent: Tuesday, December 13, 2022 8:55:46 AM To: Buschart, Rufus (IT IPS SIP) mailto:rufus.busch...@siemens.com>>; Michael Richardson mailto:mcr+i...@sandelman.ca>> Cc: RFC Errata System mailto:rfc-edi...@rfc-editor.org>>; priti...@cisco.com<mailto:priti...@cisco.com> mailto:priti...@cisco.com>>; tte+i...@cs.fau.de<mailto:tte+i...@cs.fau.de> mailto:tte+i...@cs.fau.de>>; michael.h.behrin...@gmail.com<mailto:michael.h.behrin...@gmail.com> mailto:michael.h.behrin...@gmail.com>>; kent+i...@watsen.net<mailto:kent+i...@watsen.net> mailto:kent+i...@watsen.net>>; war...@kumari.net<mailto:war...@kumari.net> mailto:war...@kumari.net>>; rwil...@cisco.com<mailto:rwil...@cisco.com> mailto:rwil...@cisco.com>>; t...@cs.fau.de<mailto:t...@cs.fau.de> mailto:t...@cs.fau.de>>; shengji...@bupt.edu.cn<mailto:shengji...@bupt.edu.cn> mailto:shengji...@bupt.edu.cn>>; anima@ietf.org<mailto:anima@ietf.org> mailto:anima@ietf.org>> Subject: RE: [Anima] [Technical Errata Reported] RFC8995 (7263) Thanks Rufus, we even should have a call today at 17:00 CET - call-in details are here (https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fanima%2FF2Ojytj9qoxlE4XSjtMwXMf8oFs%2Fdata=05%7C01%7Crufus.buschart%40siemens.com%7C7833dd970f1b4580cfd908dadcdf735a%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638065150467953304%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=y1S2VmOjEyl6pW13kGRnzjCJTBDS%2BAZx22m9TgliFi8%3Dreserved=0<https://mailarchive.ietf.org/arch/msg/anima/F2Ojytj9qoxlE4XSjtMwXMf8oFs/>). Maybe we could also briefly discuss the difference between "X does Y" versus "X MUST do Y" in an RFC, since no-one dared to comment on that yet ;-) Regards Esko -Original Message- From: Buschart, Rufus mailto:rufus.busch...@siemens.com>> Sent: Monday, December 12, 2022 22:23 To: Michael Richardson mailto:mcr+i...@sandelman.ca>>; Esko Dijk mailto:esko.d...@iotconsultancy.nl>> Cc: RFC Errata System mailto:rfc-edi...@rfc-editor.org>>; priti...@cisco.com<mailto:priti...@cisco.com>; tte+i...@cs.fau.de<mailto:tte+i...@cs.fau.de>; michael.h.behrin...@gmail.com<mailto:michael.h.behrin...@gmail.com>; kent+i...@watsen.net<mailto:kent+i...@watsen.net>; war...@kumari.net<mailto:war...@kumari.net>; rwil...@cisco.com<mailto:rwil...@cisco.com>; t...@cs.fau.de&l
Re: [Anima] [Technical Errata Reported] RFC8995 (7263)
Hi, I’m attempting to work through my errata backlog. For errata 7263, it looks like this was going to be discussed. Did this happen, and if so, what was the outcome please? My currently proposal is to edit the errata to change the “SHOULD BE” to “MUST be” and then mark the errata as HFDU. Does anyone have any opinions on this resolution? Regards, Rob From: Buschart, Rufus Sent: Tuesday, December 13, 2022 8:11 AM To: Esko Dijk ; Michael Richardson Cc: RFC Errata System ; Max Pritikin (pritikin) ; tte+i...@cs.fau.de; michael.h.behrin...@gmail.com; kent+i...@watsen.net; war...@kumari.net; Rob Wilton (rwilton) ; t...@cs.fau.de; shengji...@bupt.edu.cn; anima@ietf.org Subject: Re: [Anima] [Technical Errata Reported] RFC8995 (7263) Hi! I do have a PTO today and will not be able to dial in ;-) Best regards Rufus From: Esko Dijk mailto:esko.d...@iotconsultancy.nl>> Sent: Tuesday, December 13, 2022 8:55:46 AM To: Buschart, Rufus (IT IPS SIP) mailto:rufus.busch...@siemens.com>>; Michael Richardson mailto:mcr+i...@sandelman.ca>> Cc: RFC Errata System mailto:rfc-edi...@rfc-editor.org>>; priti...@cisco.com<mailto:priti...@cisco.com> mailto:priti...@cisco.com>>; tte+i...@cs.fau.de<mailto:tte+i...@cs.fau.de> mailto:tte+i...@cs.fau.de>>; michael.h.behrin...@gmail.com<mailto:michael.h.behrin...@gmail.com> mailto:michael.h.behrin...@gmail.com>>; kent+i...@watsen.net<mailto:kent+i...@watsen.net> mailto:kent+i...@watsen.net>>; war...@kumari.net<mailto:war...@kumari.net> mailto:war...@kumari.net>>; rwil...@cisco.com<mailto:rwil...@cisco.com> mailto:rwil...@cisco.com>>; t...@cs.fau.de<mailto:t...@cs.fau.de> mailto:t...@cs.fau.de>>; shengji...@bupt.edu.cn<mailto:shengji...@bupt.edu.cn> mailto:shengji...@bupt.edu.cn>>; anima@ietf.org<mailto:anima@ietf.org> mailto:anima@ietf.org>> Subject: RE: [Anima] [Technical Errata Reported] RFC8995 (7263) Thanks Rufus, we even should have a call today at 17:00 CET - call-in details are here (https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fanima%2FF2Ojytj9qoxlE4XSjtMwXMf8oFs%2Fdata=05%7C01%7Crufus.buschart%40siemens.com%7C7833dd970f1b4580cfd908dadcdf735a%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638065150467953304%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=y1S2VmOjEyl6pW13kGRnzjCJTBDS%2BAZx22m9TgliFi8%3Dreserved=0<https://mailarchive.ietf.org/arch/msg/anima/F2Ojytj9qoxlE4XSjtMwXMf8oFs/>). Maybe we could also briefly discuss the difference between "X does Y" versus "X MUST do Y" in an RFC, since no-one dared to comment on that yet ;-) Regards Esko -Original Message- From: Buschart, Rufus mailto:rufus.busch...@siemens.com>> Sent: Monday, December 12, 2022 22:23 To: Michael Richardson mailto:mcr+i...@sandelman.ca>>; Esko Dijk mailto:esko.d...@iotconsultancy.nl>> Cc: RFC Errata System mailto:rfc-edi...@rfc-editor.org>>; priti...@cisco.com<mailto:priti...@cisco.com>; tte+i...@cs.fau.de<mailto:tte+i...@cs.fau.de>; michael.h.behrin...@gmail.com<mailto:michael.h.behrin...@gmail.com>; kent+i...@watsen.net<mailto:kent+i...@watsen.net>; war...@kumari.net<mailto:war...@kumari.net>; rwil...@cisco.com<mailto:rwil...@cisco.com>; t...@cs.fau.de<mailto:t...@cs.fau.de>; shengji...@bupt.edu.cn<mailto:shengji...@bupt.edu.cn>; anima@ietf.org<mailto:anima@ietf.org> Subject: RE: [Anima] [Technical Errata Reported] RFC8995 (7263) Hello all! Thank you for working so intensively on my errata. I was invited by one of Siemens's representatives in the ANIMA WG to join your call next week. I hope I'll be able to make it and would be very happy to work with you on my proposed errata. And btw: I would love to have MUSTs in both paragraphs but didn't dare to propose this /Rufus > -Original Message- > From: Michael Richardson mailto:mcr+i...@sandelman.ca>> > Sent: Monday, 12 December 2022 21:52 > To: Esko Dijk > mailto:esko.d...@iotconsultancy.nl>> > Cc: RFC Errata System > mailto:rfc-edi...@rfc-editor.org>>; > priti...@cisco.com<mailto:priti...@cisco.com>; > tte+i...@cs.fau.de<mailto:tte+i...@cs.fau.de>; > michael.h.behrin...@gmail.com<mailto:michael.h.behrin...@gmail.com>; > kent+i...@watsen.net<mailto:kent+i...@watsen.net>; > war...@kumari.net<mailto:war...@kumari.net>; > rwil...@cisco.com<mailto:rwil...@cisco.com>; > t...@cs.fau.de<mailto:t...@cs.fau.de>; > shengji...@bupt.edu.cn<mailto:shengji...@bupt.edu.cn>; Buschart, Rufus (IT > IPS SIP) > mailto:rufus.busch...@siemens.com>>; > anima@ietf.org<mailto
Re: [Anima] [Technical Errata Reported] RFC8995 (7263)
Hi! I do have a PTO today and will not be able to dial in ;-) Best regards Rufus From: Esko Dijk Sent: Tuesday, December 13, 2022 8:55:46 AM To: Buschart, Rufus (IT IPS SIP) ; Michael Richardson Cc: RFC Errata System ; priti...@cisco.com ; tte+i...@cs.fau.de ; michael.h.behrin...@gmail.com ; kent+i...@watsen.net ; war...@kumari.net ; rwil...@cisco.com ; t...@cs.fau.de ; shengji...@bupt.edu.cn ; anima@ietf.org Subject: RE: [Anima] [Technical Errata Reported] RFC8995 (7263) Thanks Rufus, we even should have a call today at 17:00 CET - call-in details are here (https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fanima%2FF2Ojytj9qoxlE4XSjtMwXMf8oFs%2Fdata=05%7C01%7Crufus.buschart%40siemens.com%7C7833dd970f1b4580cfd908dadcdf735a%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638065150467953304%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=y1S2VmOjEyl6pW13kGRnzjCJTBDS%2BAZx22m9TgliFi8%3Dreserved=0). Maybe we could also briefly discuss the difference between "X does Y" versus "X MUST do Y" in an RFC, since no-one dared to comment on that yet ;-) Regards Esko -Original Message- From: Buschart, Rufus Sent: Monday, December 12, 2022 22:23 To: Michael Richardson ; Esko Dijk Cc: RFC Errata System ; priti...@cisco.com; tte+i...@cs.fau.de; michael.h.behrin...@gmail.com; kent+i...@watsen.net; war...@kumari.net; rwil...@cisco.com; t...@cs.fau.de; shengji...@bupt.edu.cn; anima@ietf.org Subject: RE: [Anima] [Technical Errata Reported] RFC8995 (7263) Hello all! Thank you for working so intensively on my errata. I was invited by one of Siemens's representatives in the ANIMA WG to join your call next week. I hope I'll be able to make it and would be very happy to work with you on my proposed errata. And btw: I would love to have MUSTs in both paragraphs but didn't dare to propose this /Rufus > -Original Message- > From: Michael Richardson > Sent: Monday, 12 December 2022 21:52 > To: Esko Dijk > Cc: RFC Errata System ; priti...@cisco.com; > tte+i...@cs.fau.de; michael.h.behrin...@gmail.com; > kent+i...@watsen.net; war...@kumari.net; rwil...@cisco.com; > t...@cs.fau.de; shengji...@bupt.edu.cn; Buschart, Rufus (IT IPS SIP) > ; anima@ietf.org > Subject: Re: [Anima] [Technical Errata Reported] RFC8995 (7263) > > > Esko Dijk wrote: > > The worry I have here is that by the time we get to the document update > > people may not be around anymore to remember why the 'SHOULD' > ought to > > be a 'MUST' and then the wrong change will be made. > > okay. > > Rob Wilton (rwilton) wrote: > > If the errata is "Hold for Doc Update" then the RFC editor won't > > automatically apply the diff. I'm pretty sure that is only ever done > > for verified errata. > > so, let's mark it this way for now. > > > There are also notes that can go along with the errata to give further > > information (e.g., what the proposed long-term resolution is) if that > > is helpful. > > If have consensus for the next text, then I think the RFC-editor site can do > the patch process, though, when we mark it as verified. > > -- > Michael Richardson. o O ( IPv6 IøT consulting ) >Sandelman Software Works Inc, Ottawa and Worldwide > > > ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] [Technical Errata Reported] RFC8995 (7263)
Thanks Rufus, we even should have a call today at 17:00 CET - call-in details are here (https://mailarchive.ietf.org/arch/msg/anima/F2Ojytj9qoxlE4XSjtMwXMf8oFs/). Maybe we could also briefly discuss the difference between "X does Y" versus "X MUST do Y" in an RFC, since no-one dared to comment on that yet ;-) Regards Esko -Original Message- From: Buschart, Rufus Sent: Monday, December 12, 2022 22:23 To: Michael Richardson ; Esko Dijk Cc: RFC Errata System ; priti...@cisco.com; tte+i...@cs.fau.de; michael.h.behrin...@gmail.com; kent+i...@watsen.net; war...@kumari.net; rwil...@cisco.com; t...@cs.fau.de; shengji...@bupt.edu.cn; anima@ietf.org Subject: RE: [Anima] [Technical Errata Reported] RFC8995 (7263) Hello all! Thank you for working so intensively on my errata. I was invited by one of Siemens's representatives in the ANIMA WG to join your call next week. I hope I'll be able to make it and would be very happy to work with you on my proposed errata. And btw: I would love to have MUSTs in both paragraphs but didn't dare to propose this /Rufus > -Original Message- > From: Michael Richardson > Sent: Monday, 12 December 2022 21:52 > To: Esko Dijk > Cc: RFC Errata System ; priti...@cisco.com; > tte+i...@cs.fau.de; michael.h.behrin...@gmail.com; > kent+i...@watsen.net; war...@kumari.net; rwil...@cisco.com; > t...@cs.fau.de; shengji...@bupt.edu.cn; Buschart, Rufus (IT IPS SIP) > ; anima@ietf.org > Subject: Re: [Anima] [Technical Errata Reported] RFC8995 (7263) > > > Esko Dijk wrote: > > The worry I have here is that by the time we get to the document update > > people may not be around anymore to remember why the 'SHOULD' > ought to > > be a 'MUST' and then the wrong change will be made. > > okay. > > Rob Wilton (rwilton) wrote: > > If the errata is "Hold for Doc Update" then the RFC editor won't > > automatically apply the diff. I'm pretty sure that is only ever done > > for verified errata. > > so, let's mark it this way for now. > > > There are also notes that can go along with the errata to give further > > information (e.g., what the proposed long-term resolution is) if that > > is helpful. > > If have consensus for the next text, then I think the RFC-editor site can do > the patch process, though, when we mark it as verified. > > -- > Michael Richardson. o O ( IPv6 IøT consulting ) >Sandelman Software Works Inc, Ottawa and Worldwide > > > ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] [Technical Errata Reported] RFC8995 (7263)
Hello all! Thank you for working so intensively on my errata. I was invited by one of Siemens's representatives in the ANIMA WG to join your call next week. I hope I'll be able to make it and would be very happy to work with you on my proposed errata. And btw: I would love to have MUSTs in both paragraphs but didn't dare to propose this /Rufus > -Original Message- > From: Michael Richardson > Sent: Monday, 12 December 2022 21:52 > To: Esko Dijk > Cc: RFC Errata System ; priti...@cisco.com; > tte+i...@cs.fau.de; michael.h.behrin...@gmail.com; > kent+i...@watsen.net; war...@kumari.net; rwil...@cisco.com; > t...@cs.fau.de; shengji...@bupt.edu.cn; Buschart, Rufus (IT IPS SIP) > ; anima@ietf.org > Subject: Re: [Anima] [Technical Errata Reported] RFC8995 (7263) > > > Esko Dijk wrote: > > The worry I have here is that by the time we get to the document update > > people may not be around anymore to remember why the 'SHOULD' > ought to > > be a 'MUST' and then the wrong change will be made. > > okay. > > Rob Wilton (rwilton) wrote: > > If the errata is "Hold for Doc Update" then the RFC editor won't > > automatically apply the diff. I'm pretty sure that is only ever done > > for verified errata. > > so, let's mark it this way for now. > > > There are also notes that can go along with the errata to give further > > information (e.g., what the proposed long-term resolution is) if that > > is helpful. > > If have consensus for the next text, then I think the RFC-editor site can do > the patch process, though, when we mark it as verified. > > -- > Michael Richardson. o O ( IPv6 IøT consulting ) >Sandelman Software Works Inc, Ottawa and Worldwide > > > smime.p7s Description: S/MIME cryptographic signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] [Technical Errata Reported] RFC8995 (7263)
Esko Dijk wrote: > The worry I have here is that by the time we get to the document update > people may not be around anymore to remember why the 'SHOULD' ought to > be a 'MUST' and then the wrong change will be made. okay. Rob Wilton (rwilton) wrote: > If the errata is "Hold for Doc Update" then the RFC editor won't > automatically apply the diff. I'm pretty sure that is only ever done > for verified errata. so, let's mark it this way for now. > There are also notes that can go along with the errata to give further > information (e.g., what the proposed long-term resolution is) if that > is helpful. If have consensus for the next text, then I think the RFC-editor site can do the patch process, though, when we mark it as verified. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] [Technical Errata Reported] RFC8995 (7263)
If the errata is "Hold for Doc Update" then the RFC editor won't automatically apply the diff. I'm pretty sure that is only ever done for verified errata. There are also notes that can go along with the errata to give further information (e.g., what the proposed long-term resolution is) if that is helpful. Thanks, Rob > -Original Message- > From: Esko Dijk > Sent: 12 December 2022 17:33 > To: Michael Richardson > Cc: RFC Errata System ; Max Pritikin (pritikin) > ; tte+i...@cs.fau.de; michael.h.behrin...@gmail.com; > kent+i...@watsen.net; war...@kumari.net; Rob Wilton (rwilton) > ; t...@cs.fau.de; shengji...@bupt.edu.cn; > rufus.busch...@siemens.com; anima@ietf.org > Subject: RE: [Anima] [Technical Errata Reported] RFC8995 (7263) > > > Yes, it SHOULD be, "SHOULD be" > > And I was saying it MUST be, "MUST be". > The worry I have here is that by the time we get to the document update > people may not be around anymore to remember why the 'SHOULD' ought to > be a 'MUST' and then the wrong change will be made. > So better fix the erratum before holding it for doc update. Dismiss it and > file a > new one if needed; I'm happy to propose some text and submit it. But maybe > that's not the right process here - I don't know how it normally works. > > Esko > > -Original Message- > From: Michael Richardson > Sent: Sunday, December 11, 2022 00:27 > To: Esko Dijk > Cc: RFC Errata System ; priti...@cisco.com; > tte+i...@cs.fau.de; michael.h.behrin...@gmail.com; kent+i...@watsen.net; > war...@kumari.net; rwil...@cisco.com; t...@cs.fau.de; > shengji...@bupt.edu.cn; rufus.busch...@siemens.com; anima@ietf.org > Subject: Re: [Anima] [Technical Errata Reported] RFC8995 (7263) > > Esko Dijk wrote: > > The proposed text still needs some work here; I would urge the WG not > > to accept this in current form. That said, using normative language in > > this specific part certainly helps to clarify the requirements for > > implementers. > > So, I agree, but "Hold for document update" means that we can, effectively > update it when we update the document. > > Yes, the rfc-editor can/will perform XML substitution for the errata process, > and so we should care a bit about the text proposed, but my take is that it's > better than what we had, and we can tweak this at our leisure. > > But... feel free to wordsmith! > > > idevid-issuer: The Issuer value from the pledge IDevID certificate > > SHOULD BE included to ensure unique interpretation of the serial- > > number. > > In the case of a nonceless (offline) voucher-request, an > > appropriate value MUST be configured from the same out-of-band > > source as the serial-number. > > Yes, it SHOULD be, "SHOULD be" ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] [Technical Errata Reported] RFC8995 (7263)
> Yes, it SHOULD be, "SHOULD be" And I was saying it MUST be, "MUST be". The worry I have here is that by the time we get to the document update people may not be around anymore to remember why the 'SHOULD' ought to be a 'MUST' and then the wrong change will be made. So better fix the erratum before holding it for doc update. Dismiss it and file a new one if needed; I'm happy to propose some text and submit it. But maybe that's not the right process here - I don't know how it normally works. Esko -Original Message- From: Michael Richardson Sent: Sunday, December 11, 2022 00:27 To: Esko Dijk Cc: RFC Errata System ; priti...@cisco.com; tte+i...@cs.fau.de; michael.h.behrin...@gmail.com; kent+i...@watsen.net; war...@kumari.net; rwil...@cisco.com; t...@cs.fau.de; shengji...@bupt.edu.cn; rufus.busch...@siemens.com; anima@ietf.org Subject: Re: [Anima] [Technical Errata Reported] RFC8995 (7263) Esko Dijk wrote: > The proposed text still needs some work here; I would urge the WG not > to accept this in current form. That said, using normative language in > this specific part certainly helps to clarify the requirements for > implementers. So, I agree, but "Hold for document update" means that we can, effectively update it when we update the document. Yes, the rfc-editor can/will perform XML substitution for the errata process, and so we should care a bit about the text proposed, but my take is that it's better than what we had, and we can tweak this at our leisure. But... feel free to wordsmith! > idevid-issuer: The Issuer value from the pledge IDevID certificate > SHOULD BE included to ensure unique interpretation of the serial- > number. > In the case of a nonceless (offline) voucher-request, an > appropriate value MUST be configured from the same out-of-band > source as the serial-number. Yes, it SHOULD be, "SHOULD be" ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] [Technical Errata Reported] RFC8995 (7263)
Esko Dijk wrote: > The proposed text still needs some work here; I would urge the WG not > to accept this in current form. That said, using normative language in > this specific part certainly helps to clarify the requirements for > implementers. So, I agree, but "Hold for document update" means that we can, effectively update it when we update the document. Yes, the rfc-editor can/will perform XML substitution for the errata process, and so we should care a bit about the text proposed, but my take is that it's better than what we had, and we can tweak this at our leisure. But... feel free to wordsmith! > idevid-issuer: The Issuer value from the pledge IDevID certificate > SHOULD BE included to ensure unique interpretation of the serial- > number. > In the case of a nonceless (offline) voucher-request, an > appropriate value MUST be configured from the same out-of-band > source as the serial-number. Yes, it SHOULD be, "SHOULD be" ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] [Technical Errata Reported] RFC8995 (7263)
Hi all, The proposed text still needs some work here; I would urge the WG not to accept this in current form. That said, using normative language in this specific part certainly helps to clarify the requirements for implementers. As a side question to all about IETF requirements language - what is the difference between "X is included." and "X MUST be included." ? For many years I have read sentences like "X is included" or "X is set to Y" as equivalent to a MUST. And such sentences are used a lot in RFCs. Surely we don't want to replace all of these cases by normative language? But if it helps to clarify things for this specific case, then fine to do it. The erratum motivation / note was not saying why this particular case needs normative language. A few points: * corrected text has "SHOULD BE" which isn't RFC 2119 compliant. * actually, the Registrar MUST include the idevid-issuer field, not intended as a "SHOULD". Reason: the Registrar wouldn't know if the MASA would need this field or not -- there is no signaling in-protocol by MASA to tell whether it wants this field -- so the only thing the Registrar can do is include it to cover all cases. There is no reason for the Registrar to exclude it. Or at least, I don't know one and no reason is given in the erratum note. Regards Esko -Original Message- From: Anima On Behalf Of RFC Errata System Sent: Friday, December 9, 2022 16:21 To: priti...@cisco.com; mcr+i...@sandelman.ca; tte+i...@cs.fau.de; michael.h.behrin...@gmail.com; kent+i...@watsen.net; war...@kumari.net; rwil...@cisco.com; t...@cs.fau.de; shengji...@bupt.edu.cn Cc: rufus.busch...@siemens.com; anima@ietf.org; rfc-edi...@rfc-editor.org Subject: [Anima] [Technical Errata Reported] RFC8995 (7263) The following errata report has been submitted for RFC8995, "Bootstrapping Remote Secure Key Infrastructure (BRSKI)". -- You may review the report below and at: https://www.rfc-editor.org/errata/eid7263 -- Type: Technical Reported by: Rufus Buschart Section: 5.5 Original Text - idevid-issuer: The Issuer value from the pledge IDevID certificate is included to ensure unique interpretation of the serial-number. In the case of a nonceless (offline) voucher-request, an appropriate value needs to be configured from the same out-of-band source as the serial-number. Corrected Text -- idevid-issuer: The Issuer value from the pledge IDevID certificate SHOULD BE included to ensure unique interpretation of the serial- number. In the case of a nonceless (offline) voucher-request, an appropriate value MUST be configured from the same out-of-band source as the serial-number. Notes - The current language is no language according to RFC 2119. Instructions: - This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -- RFC8995 (draft-ietf-anima-bootstrapping-keyinfra-45) -- Title : Bootstrapping Remote Secure Key Infrastructure (BRSKI) Publication Date: May 2021 Author(s) : M. Pritikin, M. Richardson, T. Eckert, M. Behringer, K. Watsen Category: PROPOSED STANDARD Source : Autonomic Networking Integrated Model and Approach Area: Operations and Management Stream : IETF Verifying Party : IESG ___ 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] [Technical Errata Reported] RFC8995 (7263)
RFC Errata System wrote: > The following errata report has been submitted for RFC8995, > "Bootstrapping Remote Secure Key Infrastructure (BRSKI)". > -- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid7263 > -- > Type: Technical > Reported by: Rufus Buschart Agreed. Please mark as hold for document update. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
[Anima] [Technical Errata Reported] RFC8995 (7263)
The following errata report has been submitted for RFC8995, "Bootstrapping Remote Secure Key Infrastructure (BRSKI)". -- You may review the report below and at: https://www.rfc-editor.org/errata/eid7263 -- Type: Technical Reported by: Rufus Buschart Section: 5.5 Original Text - idevid-issuer: The Issuer value from the pledge IDevID certificate is included to ensure unique interpretation of the serial-number. In the case of a nonceless (offline) voucher-request, an appropriate value needs to be configured from the same out-of-band source as the serial-number. Corrected Text -- idevid-issuer: The Issuer value from the pledge IDevID certificate SHOULD BE included to ensure unique interpretation of the serial- number. In the case of a nonceless (offline) voucher-request, an appropriate value MUST be configured from the same out-of-band source as the serial-number. Notes - The current language is no language according to RFC 2119. Instructions: - This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -- RFC8995 (draft-ietf-anima-bootstrapping-keyinfra-45) -- Title : Bootstrapping Remote Secure Key Infrastructure (BRSKI) Publication Date: May 2021 Author(s) : M. Pritikin, M. Richardson, T. Eckert, M. Behringer, K. Watsen Category: PROPOSED STANDARD Source : Autonomic Networking Integrated Model and Approach Area: Operations and Management Stream : IETF Verifying Party : IESG ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
