Hi all, FWIW, the proposed updates are now available at: https://datatracker.ietf.org/doc/draft-boucadair-netmod-rfc8407bis/
Cheers, Med & Qin > -----Message d'origine----- > De : BOUCADAIR Mohamed INNOV/NET > Envoyé : mardi 11 avril 2023 08:39 > À : 'Jürgen Schönwälder' <jschoenwaelder@constructor.university>; > 'Rob Wilton (rwilton)' <rwilton=40cisco....@dmarc.ietf.org>; > 'netmod@ietf.org' <netmod@ietf.org> > Cc : 'Kathleen Moriarty' <kathleen.moriarty.i...@gmail.com>; > 'Stephan Wenger' <st...@stewe.org>; 'trust...@ietf.org' > <trust...@ietf.org>; 'Deen, Glenn' <glenn_d...@comcast.com>; 'The > IESG' <i...@ietf.org> > Objet : RE: [netmod] [Trustees] draft-moriarty-yangsecuritytext vs > errata > > Hi Jürgen, all, > > I started exercising the proposed approach below. A diff to track > candidate changes can be seen at: https://author- > tools.ietf.org/diff?doc_1=rfc8407&url_2=https://boucadair.github.i > o/rfc8407bis/draft-boucadair-netmod-rfc8407bis.txt/. Please note > that this text is not submitted and not approved yet by Andy. > > When diving into the changes, I found that the security > considerations has a MUST that is broken since we have RFC8791. > That should be fixed as well. > > Major updates are as follows: > > * Added statements that the security template is not required > for > modules that follow [RFC8791]. > * Added guidelines for IANA-maintained modules. > * Added a note that RFC8792-folding of YANG modules can be > used if > and only if native YANG features (e.g., break line, "+") are > not sufficient. > > Minor changes: > > * Implemented errata 5693, 5800, 6899, and 7416. > * Updated the terminology with IANA-maintained/IETF modules. > * Added code markers for the security template. > * Updated the YANG security considerations template to reflect > the > latest version maintained in the Wiki. > * Added a statement that the RFCs that are listed in the > security > template are to be listed as normative references in > documents > that use the template. > * Added a note that folding of the examples should be done as > per > [RFC8792] conventions. > * Added tool validation checks to ensure that YANG modules fit > into > the line limits of an I-D. > * Added tool validation checks of JSON encoded examples. > * Updated many examples to be aligned with the consistent > indentation recommendation. > * Updated the IANA considerations to encourage registration > requests > to indicate whether a module is maintained by IANA or not. > > Cheers, > Med > > > -----Message d'origine----- > > De : BOUCADAIR Mohamed INNOV/NET > > Envoyé : jeudi 6 avril 2023 06:43 > > À : 'Jürgen Schönwälder' <jschoenwaelder@constructor.university> > > 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> Objet : RE: > > [netmod] [Trustees] draft-moriarty-yangsecuritytext vs errata > > > > 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 > > > > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
