Re: [netmod] Alissa Cooper's Abstain on draft-ietf-netmod-artwork-folding-09: (with COMMENT)

[Ladislav Lhotka <[e-mail]>]

On Thu, 2019-09-05 at 17:17 +0200, Martin Bjorklund wrote:
> Kent Watsen <[e-mail]> wrote:
> > 
> > 
> > >> There has been discussion about how embedding YANG models in RFCs seems
> like a
> > >> poor fit for a number of reasons. By standardizing line-folding
> mechanisms and
> > >> claiming them as a best practice, this document reinforces the root of
> that
> > >> problem rather than trying to fix it.
> > > 
> > > Well said, I agree with Alissa's conclusion.
> 
> But the algorithm in the document isn't supposed to be used for YANG
> modules.  It is supposed to be used primarily for XML and JSON
> snippets (etc).

My main concern is YANG, or any other code that is supposed to be both read in
the RFC and extracted from it.

Lada

> 
> > Assuming 'a', yes, 'b' follows 'a'.  That said, the concern is nebulous
> > and how to address it more so.  Proposals?
> > 
> > Assuming the concern is process-overhead for minor spins
> 
> I think we need to understand what the "number of reasons" Alissa
> refers to really are, before we try to come up with solutions.
> 
> 
> /martin
> 
> 
> > , perhaps we
> > could leverage the module-versioning work as follows:
> > 
> >   * Initial and NBC modules go thru standard RFC publishing process (i.e.,
> >     there is still a need to publish YANG modules in RFCs).
> > 
> >   * BC modules can skip standard publishing process but, to be an "IETF"
> >     product (not some random fork), they would need to be released via an
> >     IETF-owned mechanism (e.g., an Git repo) with restricted write-access.
> > 
> > Thoughts?
> > 
> > Kent
> > 
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67