We can consider this an editing error since we forgot to put markers around the boilerplate. Nobody likely understood that these markers, which were originally introduced for code components and to support tools, have second legal meaning. This is for me the more subtle news that likely more people need to understand. A grep over the RFCs found BEGIN TEMPLATE TEXT only in RFC 7382. So BEGIN TEMPLATE TEXT is likely not widely known and hence we forgot to include it.
What kind of errata this is, I have no clue. I am also not concerned about setting a precedent. I think we should be pragmatic here. /js On Tue, Apr 04, 2023 at 03:18:11PM +0000, Stephan Wenger wrote: > Hi, > Whether to use an erratum as a mechanism to address our little problem is not > the Trust’s business, and I think the Trust doesn’t and shouldn’t care—after > all, an accepted erratum is an integral part of the (modified) RFC. > However, as an IETF participant I have to ask: Is using errata to change the > outlicensing regime of (part of) an RFC a precedent the responsible people > should set? We are not talking about correcting a typo here… > Of course, pragmatically speaking and for this particular case, using an > erratum may well be the right way forward for all the reasons Rob points out. > But, if the timing were the driving force for selecting errata over new > RFCs, I would rather suggest the IEEE folks have to wait a bit longer, while > you guys rev the RFC. > Thanks, > Stephan > > From: Trustees <trustees-boun...@ietf.org> on behalf of Joel Halpern > <j...@joelhalpern.com> > Date: Tuesday, April 4, 2023 at 08:01 > To: Rob Wilton (rwilton) <rwilton=40cisco....@dmarc.ietf.org>, Kathleen > Moriarty <kathleen.moriarty.i...@gmail.com> > Cc: Deen, Glenn <glenn_d...@comcast.com>, trust...@ietf.org > <trust...@ietf.org>, netmod@ietf.org <netmod@ietf.org>, The IESG > <i...@ietf.org> > Subject: Re: [Trustees] [netmod] draft-moriarty-yangsecuritytext vs errata > If I am reading you correctly Rob, you are expecting a revision of the > relevant RFC? If that is so, we can probably live with an erratum. > The problem otherwise is that folks may not see the erratum, and thus > not know what the rules are. I am willing to be flexible on the > question of whether this is a legitimate erratum, as that is not the > trust's call. (I think it is a stretch, but so it goes.) > > Yours, > > Joel > > On 4/4/2023 10:56 AM, Rob Wilton (rwilton) wrote: > > Hi Kathleen, > > > > Thanks. It is unclear to me in your reply as to what the "this" refers to > > in "this was viewed as cleaner". I.e., does it mean an errata, or AD > > sponsoring your draft? > > > > For, me, if we can get away with doing an errata, i.e., it is sufficient to > > meet the trusts requirements, then I believe that is a better path for the > > following reasons: > > (1) Quicker and less work, and I understand that you are under time > > pressure here. > > (2) We don't end up with the security template in another RFC. > > (3) I'm proposing that the OPS area discussions and refinements to the > > current template text to make it clear about what is expected to be > > documented. E.g., my reading of the template is that implies that > > many/most YANG paths or subtrees should be documented (and this is > > seemingly the practice that many WGs have been following), but the text in > > RFC 8407 describing how the template should be used is somewhat is > > different since it refers to documents paths that are "especially > > disruptive if abused" or "especially sensitive information or that raise > > significant privacy concerns". I.e., the aim is to document the exception > > paths, not giving an overview of all paths/subtrees in the module. Hence, > > I think that this would end up somewhat changing the template text, and > > having one less copy of it seems easier. > > > > Thanks, > > Rob > > > > > >> -----Original Message----- > >> From: Kathleen Moriarty <kathleen.moriarty.i...@gmail.com> > >> Sent: 03 April 2023 21:14 > >> To: Rob Wilton (rwilton) <rwil...@cisco.com> > >> Cc: Deen, Glenn <glenn_d...@comcast.com>; trust...@ietf.org; > >> netmod@ietf.org; The IESG <i...@ietf.org> > >> Subject: Re: draft-moriarty-yangsecuritytext vs errata > >> > >> Hello Rob! > >> > >> Thank you for your offer of AD sponsorship. We also reviewed the idea of > >> using > >> errata and I think this was viewed as cleaner in that it would be readily > >> apparent that the template text could be used with the need for > >> explanation. I > >> think (and correct if I left anything out), either works to achieve the > >> objective > >> for this since we’re working directly with the IEEE. > >> > >> Best regards, > >> Kathleen > >> > >> Sent from my mobile device > >> > >>> On Apr 3, 2023, at 1:30 PM, Rob Wilton (rwilton) <rwil...@cisco.com> > >>> wrote: > >>> > >>> I'm getting an out-of-office bounce from Glenn, so adding > >>> trust...@ietf.org > >> in the hope that either Kathleen or one of the other trustees is give an > >> answer > >> more quickly. > >>> Thanks, > >>> Rob > >>> > >>> > >>>> -----Original Message----- > >>>> From: Rob Wilton (rwilton) > >>>> Sent: 03 April 2023 18:19 > >>>> To: kathleen.moriarty.i...@gmail.com; Deen, Glenn > >>>> <glenn_d...@comcast.com> > >>>> Cc: netmod@ietf.org; The IESG <i...@ietf.org> > >>>> Subject: draft-moriarty-yangsecuritytext vs errata > >>>> > >>>> Hi Glenn, Kathleen, > >>>> > >>>> In addition to discussing draft-moriarty-yangsecuritytext in the NETMOD > >>>> WG > >>>> session on Friday (where the conclusion was to go the AD sponsored > >>>> path), I > >>>> also raised this issue with the IESG/IAB at the end of the IETF week, and > >>>> someone had the suggestion of filling an errata against the YANG Author > >>>> Guidelines (RFC 8407) to add the missing <BEGIN TEMPLATE TEXT> and > >> <END > >>>> TEMPLATE TEXT> markers to section 3.7.1 of RFC 8407. > >>>> > >>>> I know that you offered a RFC 8407-bis path, but did you also consider > >> whether > >>>> adding these markers as errata (which I would regard as being as in-scope > >> and > >>>> appropriate and could be marked as 'verified')? If this approach worked > >> from > >>>> your side, and if there are no objections from the authors or NETMOD, > >>>> then > >> I > >>>> was wondering if that could be a more expedient path forward. > >>>> > >>>> Please let me know if errata would be sufficient from a trust > >>>> perspective, > >>>> otherwise, I'll go the AD sponsored route on Kathleen's draft. > >>>> > >>>> Regards, > >>>> Rob > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > _______________________________________________ > Trustees mailing list > trust...@ietf.org > https://www.ietf.org/mailman/listinfo/trustees > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Jürgen Schönwälder Constructor University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <https://constructor.university/> _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
