Hi Jürgen, I think we both agree with the proposal to immediately proceed with an erratum and handle the bis separately.
I'm more optimist here if we agree on the scope I proposed below (existing errata, no changes to the existing guidelines, add guidelines for writing IANA-maintained modules). It is worth a try. Cheers, Med > -----Original Message----- > From: Jürgen Schönwälder <jschoenwaelder@constructor.university> > Sent: mercredi 5 avril 2023 19:36 > To: BOUCADAIR Mohamed INNOV/NET <mohamed.boucad...@orange.com> > Cc: Rob Wilton (rwilton) <rwilton=40cisco....@dmarc.ietf.org>; > Kathleen Moriarty <kathleen.moriarty.i...@gmail.com>; Stephan > Wenger <st...@stewe.org>; trust...@ietf.org; netmod@ietf.org; > Deen, Glenn <glenn_d...@comcast.com>; The IESG <i...@ietf.org> > Subject: Re: [netmod] [Trustees] draft-moriarty-yangsecuritytext > vs errata > > I am a pessimist when it comes to IETF time plans and the ability > to limit discussions to certain issues once a document goes > through a working group process. I also recall surprises during > the final stages of the IESG review, some wonderful issues came up > on things we did not intent to touch in the update. Well, as > poinful as it was, the feedback made things better at the end, but > the notion of "reasonable timeframe" in the IETF likely is > anything between 6 months and N years. Compared to that, an errata > can be done in April and this buys us time to do whatever update > we agree on in an IETF "reasonable timeframe". > > /js > > On Wed, Apr 05, 2023 at 01:10:59PM +0000, > mohamed.boucad...@orange.com wrote: > > Hi Rob, all, > > > > I also think an errata is pragmatic here. > > > > On the bis, I think that this can be handled separately. If we > scope the bis to be ** limited to very few items ** to cover areas > where we don’t have guidelines (e.g., add “Guidelines for IANA- > Maintained Modules”), and in addition to the few errata out there, > a bis can be delivered in a reasonable timeframe. A candidate text > for the Guidelines for IANA-Maintained Modules can be seen at: > https://datatracker.ietf.org/doc/draft-boucadair-netmod-iana- > registries/. > > > > Cheers, > > Med > > > > From: netmod <netmod-boun...@ietf.org> On Behalf Of Rob Wilton > > (rwilton) > > Sent: mercredi 5 avril 2023 14:17 > > To: Kathleen Moriarty <kathleen.moriarty.i...@gmail.com>; > Stephan > > Wenger <st...@stewe.org> > > Cc: trust...@ietf.org; netmod@ietf.org; Jürgen Schönwälder > > <jschoenwaelder@constructor.university>; Deen, Glenn > > <glenn_d...@comcast.com>; The IESG <i...@ietf.org> > > Subject: Re: [netmod] [Trustees] draft-moriarty-yangsecuritytext > vs > > errata > > > > Hi Kathleen, > > > > The short answer to your question is maybe. The longer answer > is my email reply to Stephan and Joel below. > > > > But if you are also okay, or at least don’t object, to the > errata path, then I will kick off a proposed errata so that it can > reviewed/discussed. > > > > Regards, > > Rob > > > > > > From: Kathleen Moriarty > > > <kathleen.moriarty.i...@gmail.com<mailto:kathleen.moriarty.ietf@gm > ail. > > com>> > > Sent: 04 April 2023 19:14 > > To: Stephan Wenger <st...@stewe.org<mailto:st...@stewe.org>> > > Cc: Rob Wilton (rwilton) > > <rwil...@cisco.com<mailto:rwil...@cisco.com>>; Jürgen > Schönwälder > > > <jschoenwaelder@constructor.university<mailto:jschoenwaelder@const > ruct > > or.university>>; Joel Halpern > > <j...@joelhalpern.com<mailto:j...@joelhalpern.com>>; Deen, Glenn > > <glenn_d...@comcast.com<mailto:glenn_d...@comcast.com>>; > > trust...@ietf.org<mailto:trust...@ietf.org>; > > netmod@ietf.org<mailto:netmod@ietf.org>; The IESG > > <i...@ietf.org<mailto:i...@ietf.org>> > > Subject: Re: [netmod] [Trustees] draft-moriarty-yangsecuritytext > vs > > errata > > > > 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<mailto: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<mailto:rwil...@cisco.com>> > > Date: Tuesday, April 4, 2023 at 09:47 > > To: Jürgen Schönwälder > > > <jschoenwaelder@constructor.university<mailto:jschoenwaelder@const > ruct > > or.university>>, Stephan Wenger > > <st...@stewe.org<mailto:st...@stewe.org>>, Joel Halpern > > <j...@joelhalpern.com<mailto:j...@joelhalpern.com>> > > Cc: Kathleen Moriarty > > > <kathleen.moriarty.i...@gmail.com<mailto:kathleen.moriarty.ietf@gm > ail. > > com>>, Deen, Glenn > > <glenn_d...@comcast.com<mailto:glenn_d...@comcast.com>>, > > trust...@ietf.org<mailto:trust...@ietf.org> > > <trust...@ietf.org<mailto:trust...@ietf.org>>, > > netmod@ietf.org<mailto:netmod@ietf.org> > > <netmod@ietf.org<mailto:netmod@ietf.org>>, The IESG > > <i...@ietf.org<mailto: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<mailto:jschoenwaelder@const > ru > > > ctor.university>> > > > Sent: 04 April 2023 16:43 > > > To: Stephan Wenger <st...@stewe.org<mailto:st...@stewe.org>> > > > Cc: Joel Halpern > <j...@joelhalpern.com<mailto:j...@joelhalpern.com>>; > > > Rob Wilton (rwilton) > <rwil...@cisco.com<mailto:rwil...@cisco.com>>; > > > Kathleen Moriarty > > > > <kathleen.moriarty.i...@gmail.com<mailto:kathleen.moriarty.ietf@gm > ai > > > l.com>>; Deen, Glenn > > > <glenn_d...@comcast.com<mailto:glenn_d...@comcast.com>>; > > > trust...@ietf.org<mailto:trust...@ietf.org>; > > > netmod@ietf.org<mailto:netmod@ietf.org>; The IESG > > > <i...@ietf.org<mailto: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<mailto:trustees- > boun...@ietf.org>> on > > > > behalf of Joel Halpern > > > <j...@joelhalpern.com<mailto:j...@joelhalpern.com>> > > > > Date: Tuesday, April 4, 2023 at 08:01 > > > > To: Rob Wilton (rwilton) > > > > > <rwilton=40cisco....@dmarc.ietf.org<mailto:rwilton=40cisco.com@dma > > > > rc.ietf.org>>, Kathleen > > > Moriarty > > > > <kathleen.moriarty.i...@gmail.com<mailto:kathleen.moriarty.ietf@gm > ai > > > l.com>> > > > > Cc: Deen, Glenn > > > > <glenn_d...@comcast.com<mailto:glenn_d...@comcast.com>>, > > > > trust...@ietf.org<mailto:trust...@ietf.org> > > > <trust...@ietf.org<mailto:trust...@ietf.org>>, > > > netmod@ietf.org<mailto:netmod@ietf.org> > > > <netmod@ietf.org<mailto:netmod@ietf.org>>, The IESG > > > <i...@ietf.org<mailto: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<mailto:kathleen.moriarty.ietf > > > > >> @gmail.com>> > > > > >> Sent: 03 April 2023 21:14 > > > > >> To: Rob Wilton (rwilton) > > > > >> <rwil...@cisco.com<mailto:rwil...@cisco.com>> > > > > >> Cc: Deen, Glenn > > > > >> <glenn_d...@comcast.com<mailto:glenn_d...@comcast.com>>; > > > > >> trust...@ietf.org<mailto:trust...@ietf.org>; > > > > >> netmod@ietf.org<mailto:netmod@ietf.org>; The IESG > > > > >> <i...@ietf.org<mailto: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<mailto:rwil...@cisco.com>> > > > wrote: > > > > >>> > > > > >>> I'm getting an out-of-office bounce from Glenn, so > adding > > > trust...@ietf.org<mailto: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<mailto:Kathleen.Moriarty.iet > > > > >>>> f...@gmail.com>; Deen, Glenn > > > > >>>> <glenn_d...@comcast.com<mailto:glenn_d...@comcast.com>> > > > > >>>> Cc: netmod@ietf.org<mailto:netmod@ietf.org>; The IESG > > > > >>>> <i...@ietf.org<mailto: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<mailto:netmod@ietf.org> > > > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > > > _______________________________________________ > > > > Trustees mailing list > > > > trust...@ietf.org<mailto:trust...@ietf.org> > > > > https://www.ietf.org/mailman/listinfo/trustees > > > > > > > _______________________________________________ > > > > netmod mailing list > > > > netmod@ietf.org<mailto: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/> > > > > > __________________________________________________________________ > ____ > > ___________________________________________________ > > > > Ce message et ses pieces jointes peuvent contenir des > informations > > confidentielles ou privilegiees et ne doivent donc pas etre > diffuses, > > exploites ou copies sans autorisation. Si vous avez recu ce > message > > par erreur, veuillez le signaler a l'expediteur et le detruire > ainsi que les pieces jointes. Les messages electroniques etant > susceptibles d'alteration, Orange decline toute responsabilite si > ce message a ete altere, deforme ou falsifie. Merci. > > > > This message and its attachments may contain confidential or > > privileged information that may be protected by law; they should > not be distributed, used or copied without authorisation. > > If you have received this email in error, please notify the > sender and delete this message and its attachments. > > As emails may be altered, Orange is not liable for messages that > have been modified, changed or falsified. > > Thank you. > > > > -- > 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/> _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
