Re: [netmod] [Anima] looking for practical advice on managing YANG source in XML format RFCs

[Christian Hopps]

I didn’t think you were actually looking for a non-xml solution, but as you 
mentioned in an earlier mail there’s my org-rfc setup which makes all this yang 
stuff pretty simple. The source of the YANG module is in the single org-mode 
formatted draft source, along with support for YANG validation of the module 
and examples, generating YANG trees, downloading YANG dependencies etc.. :)

An example use: https://github.com/choppsv1/draft-chopps-netmod-geo-location 


Thanks,
Chris.

> On Jun 14, 2021, at 10:09 AM, Michael Richardson  
> wrote:
> 
> 
> Carsten Bormann  wrote:
>> On 14. Jun 2021, at 03:09, Michael Richardson  wrote:
>>> 
>>> 1) how to process yang files with -DD-MM into XML.
>>> 2) how to generate yang tree files.
>>> 3) how do I get my YANG includes downloaded, and do I put them into my repo?
>>> 4) how to do this with MT Makefiles?
> 
>> I people could tell me what they need, we could develop a feature in
>> kramdown-rfc to handle this.
> 
> One possibility is that kramdown-rfc ought to look for, and include the
> latest foo--MM-DD.yang file, when told to ::include foo.yang.
> Alternatively, it could perhaps do the -MM-DD substitution itself.
> 
>> (This would presumably also include support for YANG-SID files.)
> 
> That's mostly just a question about including the results, and it's not that
> hard thing to add to the main Makefile.
> 
> But, as I said, I xml2rfc doesn't have a useful include functionality, for
> when not working with kramdown.
> 
> --
> Michael Richardson. o O ( IPv6 IøT consulting )
>   Sandelman Software Works Inc, Ottawa and Worldwide
> 
> 
> 
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] [Anima] looking for practical advice on managing YANG source in XML format RFCs

[Michael Richardson]

Carsten Bormann  wrote:
cb> How about
>>
cb> {::include foo--??-??.yang}
>>
cb> and, if there is no such file, kramdown-rfc expands the wild card in
cb> the directory and uses the numerically latest file?
>>
>> You'd use shell globs?

> Yes.  Any need to go beyond that?

>> I think it might be better to use PCRE.

> Much more typing and backslash-mangling, and I don’t see the use case.

DOS/Windows people don't get shell globs, and "?" is not something they know.

>> It might be better to have this as "winclude"

> So ‘loseclude’ would be including all matches?

hah.

> (What does the “w” stand for?)

wildcard.

cb> (There might also be a use-case for actually including all these
cb> files, so I’m still in thinking mode, but I think this is close.)

--
]   Never tell me the odds! | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works| network architect  [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[



___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] YANG Versioning Weekly Call Minutes - 2021-06-08

[Andy Bierman]

On Mon, Jun 14, 2021 at 10:40 AM Sterne, Jason (Nokia - CA/Ottawa) <
jason.ste...@nokia.com> wrote:

> Hi guys,
>
> I can understand that concern; and in particular for something like the
> new import by "revision-or-derived". Ignoring that extension can mean tools
> may not build the right schema (although is that any worse than today
> without using import by revision ?).
>
> Despite that issue, I'd still advocate for revision-or-derived to be taken
> to standard now. It is part of a few things that cause problems today that
> really need to be addressed in the short term.
>
> But for things like the rev:non-backwards-compatible tag, and using YANG
> semver, do those actually cause any new problems (vs what they help solve)
> ? It doesn't cause tools to build the wrong thing, or servers to implement
> the wrong thing.  It only helps supply information about what is already
> happening today (particularly in vendor modules, but also in standard
> modules) that isn't being described at all (NBC changes that really do
> impact the client, but the module name is kept the same). The WG had a fair
> bit of discussion 2-3 years ago that this versioning work was needed and
> should be adopted and progressed. That is still the case IMO.
>
>
The all-or-none approach to the versioning work is producing more "none"
than "all". ;-)

YANG was designed to be used in a linear and singular release train.
This is clearly not the way the real world can use YANG.
Ignoring this pain point is making the problem worse over time.

There are many corner-cases that the DT is spending a lot of time on that
do not cause the deployment problems that a revision label could solve.

My original point: Fix this problem with the best engineering solution
possible
even if that means a new YANG language version.  Import-by-semver should
not be super-complicated and it should not be optional for a compiler to
use.

Import-by-exact-revision is flawed and not worth preserving.


Jason
>

Andy


>
> > -Original Message-
> > From: Kent Watsen 
> > Sent: Monday, June 14, 2021 1:17 PM
> > To: Andy Bierman 
> > Cc: Sterne, Jason (Nokia - CA/Ottawa) ;
> > netmod@ietf.org
> > Subject: Re: [netmod] YANG Versioning Weekly Call Minutes - 2021-06-08
> >
> >
> > > I meant the current work is using extensions instead of new language
> > statements.
> > > Not that the yang-version will never be changed in the future.
> >
> > Ah, okay.
> >
> >
> > > It is not a matter of "when" if new functionality is added via
> extensions.
> > > In theory the WG could add new functionality to YANG 1.1 this way for
> > years.
> > > In practice it might be difficult to achieve widespread
> interoperability if
> > nobody
> > > agrees what "YANG next"  actually contains. Also, YANG 1.1 clearly
> says a
> > tool MAY
> > > skip over and ignore ANY external statement, so it is problematic to
> use
> > extension-stmt
> > > as if it was defining real statements. It is better to have a tool
> clearly fail
> > > with an "unsupported YANG version" error than it is to silently ignore
> > external statements.
> >
> > Agreed.
> >
> >
> > K.
> >
>
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] YANG Versioning Weekly Call Minutes - 2021-06-08

[Sterne, Jason (Nokia - CA/Ottawa)]

Hi guys,

I can understand that concern; and in particular for something like the new 
import by "revision-or-derived". Ignoring that extension can mean tools may not 
build the right schema (although is that any worse than today without using 
import by revision ?).

Despite that issue, I'd still advocate for revision-or-derived to be taken to 
standard now. It is part of a few things that cause problems today that really 
need to be addressed in the short term.

But for things like the rev:non-backwards-compatible tag, and using YANG 
semver, do those actually cause any new problems (vs what they help solve) ? It 
doesn't cause tools to build the wrong thing, or servers to implement the wrong 
thing.  It only helps supply information about what is already happening today 
(particularly in vendor modules, but also in standard modules) that isn't being 
described at all (NBC changes that really do impact the client, but the module 
name is kept the same). The WG had a fair bit of discussion 2-3 years ago that 
this versioning work was needed and should be adopted and progressed. That is 
still the case IMO.

Jason

> -Original Message-
> From: Kent Watsen 
> Sent: Monday, June 14, 2021 1:17 PM
> To: Andy Bierman 
> Cc: Sterne, Jason (Nokia - CA/Ottawa) ;
> netmod@ietf.org
> Subject: Re: [netmod] YANG Versioning Weekly Call Minutes - 2021-06-08
> 
> 
> > I meant the current work is using extensions instead of new language
> statements.
> > Not that the yang-version will never be changed in the future.
> 
> Ah, okay.
> 
> 
> > It is not a matter of "when" if new functionality is added via extensions.
> > In theory the WG could add new functionality to YANG 1.1 this way for
> years.
> > In practice it might be difficult to achieve widespread interoperability if
> nobody
> > agrees what "YANG next"  actually contains. Also, YANG 1.1 clearly says a
> tool MAY
> > skip over and ignore ANY external statement, so it is problematic to use
> extension-stmt
> > as if it was defining real statements. It is better to have a tool clearly 
> > fail
> > with an "unsupported YANG version" error than it is to silently ignore
> external statements.
> 
> Agreed.
> 
> 
> K.
> 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] YANG Versioning Weekly Call Minutes - 2021-06-08

[Kent Watsen]

> I meant the current work is using extensions instead of new language 
> statements.
> Not that the yang-version will never be changed in the future.

Ah, okay.


> It is not a matter of "when" if new functionality is added via extensions.
> In theory the WG could add new functionality to YANG 1.1 this way for years.
> In practice it might be difficult to achieve widespread interoperability if 
> nobody
> agrees what "YANG next"  actually contains. Also, YANG 1.1 clearly says a 
> tool MAY
> skip over and ignore ANY external statement, so it is problematic to use 
> extension-stmt
> as if it was defining real statements. It is better to have a tool clearly 
> fail
> with an "unsupported YANG version" error than it is to silently ignore 
> external statements.

Agreed.


K.


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] YANG Versioning Weekly Call Minutes - 2021-06-08

[Andy Bierman]

On Mon, Jun 14, 2021 at 9:38 AM Kent Watsen  wrote:

>
>
> > Good thing we are not discussing YANG-next...
>>
>> Sarcasm?  ;)
>>
>
> No. The NETMOD WG has repeatedly decided not to produce a new YANG language
> version in which the yang-version string is changed.
>
>
> That’s not possibly true.   It's a matter of “when", not “if”, unless
> you’re anticipating YANG moving to HISTORIC.
>
>
I meant the current work is using extensions instead of new language
statements.
Not that the yang-version will never be changed in the future.

It is not a matter of "when" if new functionality is added via extensions.
In theory the WG could add new functionality to YANG 1.1 this way for years.
In practice it might be difficult to achieve widespread interoperability if
nobody
agrees what "YANG next"  actually contains. Also, YANG 1.1 clearly says a
tool MAY
skip over and ignore ANY external statement, so it is problematic to use
extension-stmt
as if it was defining real statements. It is better to have a tool clearly
fail
with an "unsupported YANG version" error than it is to silently ignore
external statements.



K.
>
>
Andy
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] YANG Versioning Weekly Call Minutes - 2021-06-08

[Kent Watsen]

> > Good thing we are not discussing YANG-next...
> 
> Sarcasm?  ;)
> 
> No. The NETMOD WG has repeatedly decided not to produce a new YANG language
> version in which the yang-version string is changed. 

That’s not possibly true.   It's a matter of “when", not “if”, unless you’re 
anticipating YANG moving to HISTORIC.


K.

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] [Tools-discuss] [Anima] looking for practical advice on managing YANG source in XML format RFCs

[Salz, Rich]

Netmod and anima moved to bcc.

>You'd use shell globs?
I think it might be better to use PCRE.
  
Horrible idea to use PCRE instead of globs.


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] [Anima] looking for practical advice on managing YANG source in XML format RFCs

[Carsten Bormann]

On 2021-06-14, at 18:26, Michael Richardson  wrote:
> 
>cb> How about
> 
>cb> {::include foo--??-??.yang}
> 
>cb> and, if there is no such file, kramdown-rfc expands the wild card in
>cb> the directory and uses the numerically latest file?
> 
> You'd use shell globs?

Yes.  Any need to go beyond that?

> I think it might be better to use PCRE.

Much more typing and backslash-mangling, and I don’t see the use case.

> It might be better to have this as "winclude"

So ‘loseclude’ would be including all matches?

(What does the “w” stand for?)

>cb> (There might also be a use-case for actually including all these
>cb> files, so I’m still in thinking mode, but I think this is close.)

Grüße, Carsten

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] [Anima] looking for practical advice on managing YANG source in XML format RFCs

[Michael Richardson]

Carsten Bormann  wrote:
>> One possibility is that kramdown-rfc ought to look for, and include
>> the latest foo--MM-DD.yang file, when told to ::include foo.yang.
>> Alternatively, it could perhaps do the -MM-DD substitution itself.

cb> How about

cb> {::include foo--??-??.yang}

cb> and, if there is no such file, kramdown-rfc expands the wild card in
cb> the directory and uses the numerically latest file?

You'd use shell globs?
I think it might be better to use PCRE.
It might be better to have this as "winclude"

cb> (There might also be a use-case for actually including all these
cb> files, so I’m still in thinking mode, but I think this is close.)

>> for when not working with kramdown.

cb> What? :-)

Yes, it causes me confusion too.
Basically, I'm trying to contribute YANG modules (as pull-requests) to drafts
for which I'm not an author, and I don't really want to have to convince them 
to upgrade.

-- 
]   Never tell me the odds! | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works| network architect  [ 
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[ 






signature.asc
Description: PGP signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] [Anima] looking for practical advice on managing YANG source in XML format RFCs

[Carsten Bormann]

I can’t help you with your dark desires to use XML, but I would propose the 
following fix for that:

— use xi:include or src= for the XML source (I forget which one works), with a 
static name
— simply generate a symlink from the most recent .yang to the static name in 
the Makefile
— use --expand for generating the submission XML.

Grüße, Carsten

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] [Anima] looking for practical advice on managing YANG source in XML format RFCs

[Michael Richardson]

Carsten Bormann  wrote:
> On 14. Jun 2021, at 03:09, Michael Richardson 
> wrote:
>> 
>> 1) how to process yang files with -DD-MM into XML.  2) how to
>> generate yang tree files.  3) how do I get my YANG includes
>> downloaded, and do I put them into my repo?  4) how to do this with MT
>> Makefiles?

> I people could tell me what they need, we could develop a feature in
> kramdown-rfc to handle this.  (This would presumably also include
> support for YANG-SID files.)

But, part of the question is, how does one do this with just XML.
As wonderful as kramdown is, and it's always my preference, sometimes it is
hard to convince a design team that has started on XML to go that way.
(sunk cost fallacy, etc.)

I looked at Kent's XIAX repo documentation, and what I saw was that it might
take XML as input, paste the YANG in, but leave enough meta-data in the XML so 
that
the XML can be processed again.  So this is an in-place edit.  I worry that
such a workflow would be confusing to some authors who might edit in the
wrong place.

Kent, I didn't look extensively at that repo you said to clone.

As to editing in YIN, which is an XML syntax way to represent
YANG well... I don't mind if someone wants to store YANG that way, but I
sure don't want to edit that way.

So at this point, the best I can do is to bring my "insert-figures" hack into
a repo, rename the XML to another name, and generate draft-foobar.xml in the
top-Makefile.

-- 
]   Never tell me the odds! | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works| network architect  [ 
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[ 





signature.asc
Description: PGP signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] [Anima] looking for practical advice on managing YANG source in XML format RFCs

[Carsten Bormann]

> One possibility is that kramdown-rfc ought to look for, and include the
> latest foo--MM-DD.yang file, when told to ::include foo.yang.
> Alternatively, it could perhaps do the -MM-DD substitution itself.

How about

{::include foo--??-??.yang}

and, if there is no such file, kramdown-rfc expands the wild card in the 
directory and uses the numerically latest file?

(There might also be a use-case for actually including all these files, so I’m 
still in thinking mode, but I think this is close.)

> for when not working with kramdown.

What? :-)

Grüße, Carsten

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] YANG Versioning Weekly Call Minutes - 2021-06-08

[Andy Bierman]

On Mon, Jun 14, 2021 at 3:34 AM Kent Watsen  wrote:

>
>
> > Good thing we are not discussing YANG-next...
>
> Sarcasm?  ;)
>

No. The NETMOD WG has repeatedly decided not to produce a new YANG language
version in which the yang-version string is changed.


> I do wonder if it’s not about time we make another go at that
> effort...perhaps a 111-hum on interest?
>
> That said, there’s a world apart from WG-interest and author-commitments.
>
> In either case, said effort wouldn’t complete for some time, which may be
> disagreeable to the versioning rollout.


I agree there is little WG interest for this work.


>
>
> Kent
>

Andy
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] [Anima] looking for practical advice on managing YANG source in XML format RFCs

[Michael Richardson]

Carsten Bormann  wrote:
> On 14. Jun 2021, at 03:09, Michael Richardson  
wrote:
>>
>> 1) how to process yang files with -DD-MM into XML.
>> 2) how to generate yang tree files.
>> 3) how do I get my YANG includes downloaded, and do I put them into my 
repo?
>> 4) how to do this with MT Makefiles?

> I people could tell me what they need, we could develop a feature in
> kramdown-rfc to handle this.

One possibility is that kramdown-rfc ought to look for, and include the
latest foo--MM-DD.yang file, when told to ::include foo.yang.
Alternatively, it could perhaps do the -MM-DD substitution itself.

> (This would presumably also include support for YANG-SID files.)

That's mostly just a question about including the results, and it's not that
hard thing to add to the main Makefile.

But, as I said, I xml2rfc doesn't have a useful include functionality, for
when not working with kramdown.

--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide






signature.asc
Description: PGP signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] YANG Versioning Weekly Call Minutes - 2021-06-08

[Kent Watsen]

> Good thing we are not discussing YANG-next...

Sarcasm?  ;)

I do wonder if it’s not about time we make another go at that effort...perhaps 
a 111-hum on interest?

That said, there’s a world apart from WG-interest and author-commitments.

In either case, said effort wouldn’t complete for some time, which may be 
disagreeable to the versioning rollout. 

Kent
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] [Anima] looking for practical advice on managing YANG source in XML format RFCs

[Kent Watsen]

Hi Michael!

There isn’t a standard of any sort, but as an active author of a large number 
of drafts, I’ve been force to automate as much as possible:

  - validating the schema
  - validating examples
  - generating tree diagrams
  - stitching all off the above into an XML file
  - on a per-build basis 

AFAIK, my system is more complete than used by other authors, most whom seem to 
do it manually, with mixed results...

I author in XML v3 with macros that get expanded in the source, you may have 
linked my INSERT_TEXT_IN_FILE macro earlier, that ‘insert-figures’ consumes.  
It’s effectively the same, with little improvements here and there. 

There’s no “tool” to do it*, each draft begins as a copy/paste of one prior, 
and then the Makefile, refs/validate-all.sh, and refs/gen-trees.sh files are 
tweaked as needed.   For examples: see the top-10 repos listed here: 
https://github.com/netconf-wg. 

* I was previously working on ‘xiax’ here: https://github.com/kwatsen/xiax. 

K. 

> On Jun 13, 2021, at 9:10 PM, Michael Richardson  wrote:
> 
> 
> Hi, I'm not a regular netmod reader.
> I subscribe via IMAP to look into what's going on.  If I'm asking a FAQ, I
> appologize as I didn't find anything in the 25K messages archived.
> I saw Christian's message in 2019 about org-rfc-export.
> I'm not sure if I should Reply-To: tools or netmod.
> 
> I'm looking for advice on how to manage things.
> A summary of my questions:
> 
> 1) how to process yang files with -DD-MM into XML.
> 2) how to generate yang tree files.
> 3) how do I get my YANG includes downloaded, and do I put them into my repo?
> 4) how to do this with MT Makefiles?
> 
> When we were working on RFC8995 and RFC8366, in the days before Martin
> Thompson's makefile was around, I just put pyang processing into my simple
> Makefile.  It's here:  
> https://github.com/anima-wg/anima-bootstrap/blob/master/Makefile
> 
> The perl script at: 
> https://github.com/anima-wg/anima-bootstrap/blob/master/insert-figures
> was then developed to insert stuff into the XML.  It's rather hacky in some 
> ways.
> It started it's life as just something to find the latest @-MM-DD yang
> file which the Makefile created. (Kent wrote that sed line three quarters of
> a decade ago, and the sed line now is old enough to trick-or-treat)
> Over time, it grew the ability to insert other bits of code or diagrams.
> I keep using it, even when I've moved to Markdown because it inserts the
> right artwork stuff, and knows to deal with YANG stuff.  I also keep using my
> Makefile, because except for the simplest uses, the MT ones are too
> complicated for me to hack.
> 
> With kramdown source, I can mostly just add stuff to the MT Makefile to
> generate the files I need, and then mostly (without insert-figures), I can
> use the ::include mechanism in kramdown to get the right things.  But, no
> magic -MM-DD stuff.
> 
> So now I am collaborating with some co-authors which want to stick to XMLv3
> rather than kramdown, and whose understanding of Makefiles is poor.  I want
> to stick with the normal stuff so that all the github/etc. tooling works for
> everyone involved.
> 
> I'm looking for advice on how do this this?
> 
> --
> Michael Richardson. o O ( IPv6 IøT consulting )
>   Sandelman Software Works Inc, Ottawa and Worldwide
> 
> 
> 
> 
> ___
> Anima mailing list
> an...@ietf.org
> https://www.ietf.org/mailman/listinfo/anima
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] looking for practical advice on managing YANG source in XML format RFCs

[Ladislav Lhotka]

Hi Michael,

you can check my project YANG-I-D [1] for some ideas.

The most elegant way of including YANG modules in RFCs would be to treat the 
RFC source as a compound XML document combining xml2rfc with YANG modules in 
the YIN syntax - if only xml2rfc could process it.

Lada

[1] https://github.com/llhotka/YANG-I-D

Michael Richardson  writes:

> Hi, I'm not a regular netmod reader.
> I subscribe via IMAP to look into what's going on.  If I'm asking a FAQ, I
> appologize as I didn't find anything in the 25K messages archived.
> I saw Christian's message in 2019 about org-rfc-export.
> I'm not sure if I should Reply-To: tools or netmod.
>
> I'm looking for advice on how to manage things.
> A summary of my questions:
>
> 1) how to process yang files with -DD-MM into XML.
> 2) how to generate yang tree files.
> 3) how do I get my YANG includes downloaded, and do I put them into my repo?
> 4) how to do this with MT Makefiles?
>
> When we were working on RFC8995 and RFC8366, in the days before Martin
> Thompson's makefile was around, I just put pyang processing into my simple
> Makefile.  It's here:  
> https://github.com/anima-wg/anima-bootstrap/blob/master/Makefile
>
> The perl script at: 
> https://github.com/anima-wg/anima-bootstrap/blob/master/insert-figures
> was then developed to insert stuff into the XML.  It's rather hacky in some 
> ways.
> It started it's life as just something to find the latest @-MM-DD yang
> file which the Makefile created. (Kent wrote that sed line three quarters of
> a decade ago, and the sed line now is old enough to trick-or-treat)
> Over time, it grew the ability to insert other bits of code or diagrams.
> I keep using it, even when I've moved to Markdown because it inserts the
> right artwork stuff, and knows to deal with YANG stuff.  I also keep using my
> Makefile, because except for the simplest uses, the MT ones are too
> complicated for me to hack.
>
> With kramdown source, I can mostly just add stuff to the MT Makefile to
> generate the files I need, and then mostly (without insert-figures), I can
> use the ::include mechanism in kramdown to get the right things.  But, no
> magic -MM-DD stuff.
>
> So now I am collaborating with some co-authors which want to stick to XMLv3
> rather than kramdown, and whose understanding of Makefiles is poor.  I want
> to stick with the normal stuff so that all the github/etc. tooling works for
> everyone involved.
>
> I'm looking for advice on how do this this?
>
> --
> Michael Richardson. o O ( IPv6 IøT consulting )
>Sandelman Software Works Inc, Ottawa and Worldwide
>
>
>
>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod