Re: [netmod] [Trustees] draft-moriarty-yangsecuritytext vs errata

[[e-mail]]

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.io/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' <[e-mail]>
> Cc : Rob Wilton (rwilton) <rwilton=[e-mail]>;
> Kathleen Moriarty <[e-mail]>; Stephan
> Wenger <[e-mail]>; [e-mail]; [e-mail];
> Deen, Glenn <[e-mail]>; The IESG <[e-mail]>
> 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
> <[e-mail]>
> > Sent: mercredi 5 avril 2023 19:36
> > To: BOUCADAIR Mohamed INNOV/NET
> <[e-mail]>
> > Cc: Rob Wilton (rwilton) <rwilton=[e-mail]>;
> > Kathleen Moriarty <[e-mail]>; Stephan
> Wenger
> > <[e-mail]>; [e-mail]; [e-mail]; Deen,
> Glenn
> > <[e-mail]>; The IESG <[e-mail]>
> > 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,
> [e-mail]
> > 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
> > >

_________________________________________________________________________________________________________________________

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.