[rfc-i] [Ietf-and-github] New Version Notification for draft-kwatsen-git-xiax-automation-00.txt
henrik at levkowetz.com
Tue Feb 26 03:49:20 PST 2019
On 2019-02-25 23:52, Kent Watsen wrote:
> Ugh, there's an embarrassing typo in the Abstract, so much for last-minute edits ;)
> - I just posted a -01 to fix this
> FWIW, an earlier version of the tool keyed off the presence of
> "originalSrc" attributes to drive extractions and, by doing so, could
> extract content regardless if `xiax` or "prep tool" inserted it.
> Moving to the "xiax-block" lost this behavior, but I plan add back
> support for also extracting artwork/sourcecode without an associated
> xiax-block entry, thus able to extract all such content, regardless
> how placed, albeit without any of the other automation support.
For both xml2rfc version 2 <artwork>, and version 3 <sourcecode> (I don't
think you should touch v3 <artwork>, but that's a separate discussion),
I believe you should be using the "name" attribute, not the
"src"/"originalSrc" or xiax:src attributes to provide the file names
to export to; see https://tools.ietf.org/html/rfc7991#section-2.48.2.
The "name" attribute on <artwork> is also supported in the v2 schema.
If there are any specific reasons why you've not used "name" attribute,
which is provided with the intention of being used by extraction tools,
we should have a discussion and understand why.
Some additional comments on the draft (I looked at -01):
| 5. Updates to RFC 7991
| This section is just a placeholder for now, but it is expected that
| [RFC7991] will need to be modified in order to support some of this
| At a minimum, [RFC7991] should be updated to support attributes from
| other namespaces, such that the `rfc2xml` tool would neither process
| nor discard them.
Blanket acceptance of unknown attributes would make validation of schema
attributes go away. I'm fine with discussing specific new attributes for
specific elements, but not a blanket acceptance of any attributes as valid
in the input. Accepting wildcard attributes in specific namespaces for
<sourcecode> in the v3 grammar seems doable (I've just tested a grammar
tweak for that). I think this is what you're after, but the text in the
draft seems a bit too open-ended.
| 7. Previous Work
| o The RFC Submit [submit] tool has been modified to test YANG
| modules contained within I-Ds, and the resulting document page in
| Datatracker [datatracker] displays a new "Yang Validation" field
| containing a varying color yin-yang symbol (green if no errors,
| red if errors) along with counts. This tool is okay for what it
| is, but it neither aids authors between updates nor validates
| anything beyond YANG modules.
Additional info: The datatracker submission checking for YANG modules
was written to be easily extended, exactly for the purpose of adding
additional checkers in the future (I'm mentioning this as an additional
point in support of generalizing the tool work in this area).
| 10. Security Considerations
| 10.1. Automated Execution of Arbitrary Scripts
| o Allow arbitrary scripts, but don't execute them automatically when
| a document is extracted. This solution is appealing as it still
| ensures these scripts were executed on the author's computer at
| time of construction, and the scripts themselves can be extracted
| and audited on the reviewer's computer. If desired, after
| auditing a script, a reviewer could choose to manually execute it
| on their own computer.
Creating a generalized solution that would permit packaging of the verification
code in the document seems sooo tempting. But we've seen time and again that
if you make it possible to automate execution of arbitrary code, it will be
expanded to actually do the automation by someone, and then used by bad actors
down the road. -1.
| o Don't allow arbitrary scripts but, instead, support parameterized
| files that declare all the information necessary to construct the
| command(s) necessary to generate derived views and/or validate
I like this better, but it's a much larger apparatus. It might mean building
a registry of validation tools (for yang, the state of the art is such
that it seems feasible, but for other content that might not be so easy).
I think it's worth exploring, in any case.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: OpenPGP digital signature
More information about the rfc-interest