On Thu, Sep 5, 2019 at 10:08 AM Kent Watsen <[email protected]> wrote:
> Hi Suresh, > > Thank you for your review. Comments below. > > Kent // as co-author > > > On Sep 5, 2019, at 10:41 AM, Suresh Krishnan via Datatracker < > [email protected]> wrote: > > Suresh Krishnan has entered the following ballot position for > draft-ietf-netmod-artwork-folding-09: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-netmod-artwork-folding/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > After some thought I think there are two things about this document that > make > me uncomfortable enough to ballot Discuss. > > a) Due to its home in the netmod WG it is highly likely that people > outside the > yang community have not paid enough attention to this work. Since this is > applicable to code fragments of all kinds, I think the home chosen for > this RFC > might have inadvertently limited input from the broader community. > > > Agreed. The original I-D was targeted for IAB stream. It wasn't going to > be presented in NETMOD, but did (by coercion). During the presentation I > mentioned that its applicability was more than NETMOD and that it should go > thru IAB, just like the "xml2rfc" RFCs (7749 and 7991). The working group > felt that it should stay in the WG and hence here we are. :sigh: > > It seemed self-evident that the scope of this draft did not fit the NETMOD WG charter. I assumed the work was permitted to start because (1) nobody else was willing to work on it and (2) nowhere else to put it. > > b) Given a) I think it is better that this document go forward as an > Informational document rather than a BCP so that use of this technique > becomes > optional, without the force of a BCP behind it. > > > I'm okay with this, modulo my comment to Alissa. Actually, if we only > view the RFC as specifying a format then, in my mind, it doesn't actually > contain the "best practice". FWIW, SHOULD appears only once, in a sentence > stating that folding SHOULD be automated, in a section titled "Goals". > That said, if not a BCP, then how to encourage people to use it, so that > automation works? For this reason alone, it seems that either the draft > should be a BCP or Datatracker is updated to auto-fold as needed. Perhaps > the right answer is to do Informational now and hope that Datatracker is > updated in time? > > > IMO Informational status is the only option. There is a simple solution that solves applicability: Add some text in this draft that UPDATES RFC 8407 so that only RFCs that contain YANG modules are required to use this line-wrap solution. Andy > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I do agree with my Abstaining colleagues that this should probably not be > on > the IETF stream but I think the work is useful enough to go forward. > > > It should've been on the IAB stream. Whether it should go forward, after > having the BCP attribute removed, or re-run via the IAB stream is up to the > IESG. > > > Kent // as co-author > > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
