On Thu, 2019-09-05 at 17:17 +0200, Martin Bjorklund wrote: > Kent Watsen <[email protected]> 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 _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
