Rob, Multiple instances could be confusing, agreed. You’ll be going a -bis soon anyway to update the considerations, is that correct?
Thank you, Kathleen Sent from my mobile device > On Apr 4, 2023, at 1:52 PM, Stephan Wenger <st...@stewe.org> wrote: > > > Hi Rob, > Thanks for your detailed response. I will not stand in the way of the errata > round, as it seems well justified. > Stephan > > From: Rob Wilton (rwilton) <rwil...@cisco.com> > Date: Tuesday, April 4, 2023 at 09:47 > To: Jürgen Schönwälder <jschoenwaelder@constructor.university>, Stephan > Wenger <st...@stewe.org>, Joel Halpern <j...@joelhalpern.com> > Cc: Kathleen Moriarty <kathleen.moriarty.i...@gmail.com>, 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: [netmod] [Trustees] draft-moriarty-yangsecuritytext vs errata > > Hi Stephan, Joel, > > I'm basically coming at this from a similar position as Jürgen. > > I regard RFC 8407 as providing general guidance to authors of YANG modules > both within and outside the IETF. I.e., it is providing best practice > guidelines for how YANG modules should be written and documented in > specifications. As such, it seems entirely reasonable to me that the at the > time that the draft was approved by the Netmod WG that the consensus was that > the security considerations template (or the updated wiki that is references) > could be used by specifications outside of the IETF. > > From the conversations that I had with Glenn recently, my interpretation was > that template text in RFCs SHOULD have the BEGIN/END TEMPLATE TEXT markers > around the template text to ensure that the appropriate IETF trust licence > applies to the template text. If that interpretation is correct, then the > lack of these markers just looks like a mistake in RFC 8407. > > Joel, to answer the specific question that you asked: No, I don’t think that > we would necessarily rev RFC 8407, but it is a possible outcome. The current > text in RFC 8407 allows for an updated template to be provided on the wiki > page and used in RFCs without necessarily needing to bis RFC 8407. Hence I > think that there are various questions with unknown answers before we end up > going down the RFC 8407 bis path, e.g., (i) does the community agree with my > proposed template changes (noting that I haven't even written or provided > them yet, only proposed changing them), (ii) can this be done just by > updating the wiki, (iii) is this clarification worth the effort of opening > RFC 8407 up for. I.e., if we ask the IEEE to wait for a bis version of this > document then I have no realistic idea about how long they could be waiting > or even if this would happen at all. > > Having a copy of the template text in a separate RFC also has its downsides > for the IETF community because there would then be three copies of the > security template, and if the template text does change as I propose then it > seems more likely that authors would end up picking the wrong template for > their documents. > > As for the precedence of using errata, I would be okay with that too - i.e., > I think that just shows that we can be pragmatic and not get stuck in running > extra process only for processes sake. > > Regards, > Rob > > > > -----Original Message----- > > From: Jürgen Schönwälder <jschoenwaelder@constructor.university> > > Sent: 04 April 2023 16:43 > > To: Stephan Wenger <st...@stewe.org> > > Cc: Joel Halpern <j...@joelhalpern.com>; Rob Wilton (rwilton) > > <rwil...@cisco.com>; Kathleen Moriarty <kathleen.moriarty.i...@gmail.com>; > > Deen, Glenn <glenn_d...@comcast.com>; trust...@ietf.org; > > netmod@ietf.org; The IESG <i...@ietf.org> > > Subject: Re: [netmod] [Trustees] draft-moriarty-yangsecuritytext vs errata > > > > 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
