I think your point about working on the YANG model may help validate or
refine elements of the -interface spec but I think that will only happen
if folks actually engage and work on it. IMO this is part of a larger
question of whether it is better to hold the documents to allow them to
mature as for more implementation and, in this case, alternative
analysis, or publish them and expect to revise them if TAPS gets
traction and we learn from experience what we got wrong. As I said in
my earlier note, given what I see is diminishing energy in the working
group I fear that waiting now will result in a reduced number of
reviewers for WGLC and the associated conversations. This is just One
Person’s Opinion and I will of course defer to wg consensus on what to
do but it’s my gut feeling we need to push for closure now.
Discussion welcome.
--aaron
On 18 Nov 2019, at 11:55, Holland, Jake wrote:
I mostly agree, with a caveat.
A couple of notes as author:
* I’d be willing to continue this work as a WG item if the WG
would like to adopt it, especially if it means some people will review
and assist :)
* I think it’s not currently mature enough to integrate into an
imminent last-call draft (particularly as regards the security
parameters, as mentioned previously on-list, but likely some other
areas are weak as well)
And my caveat, not as author but as wg participant:
Although I agree it would be nice to avoid blocking progress on the
other drafts, I wouldn’t be surprised if a wider detailed review and
discussion of the yang model could bring to light some ambiguities
that have been overlooked in the existing drafts, particularly
taps-interface. In that sense, it might make sense to get started
quickly, if we intend to do this.
* note that the same is true as more-complete API implementations
are developed, regardless of whether as a wg the issues are tackled
with the yang model. (The exercise of applying a new level of rigor
and specificity to the abstractions written in the current draft is
what’s likely to generate some insights that might be best applied
to text of the draft, not the yang model specifically).
* This is a point in tension with the goal of wrapping up the
existing drafts. Not sure how to handle it, but publishing
taps-interface without first trying to nail down specifics in some
detail, IMO, will dramatically increase the chances that we’ll need
to issue errata or live with regrets on the published language on taps
RFCs. Maybe that’s fine, there are many imperfect RFCs, but worth
thinking about.
Best,
Jake
From: Aaron Falk <[email protected]>
Date: 2019-11-18 at 10:28
To: tom petch <[email protected]>
Cc: taps WG <[email protected]>
Subject: Re: [Taps] finishing things
On 17 Nov 2019, at 22:48, tom petch wrote:
I am not sure which three you have in mind but suspect that it does
not
include
draft-jholland-taps-api-yang
Tom Petch
Thanks for bringing this up, Tom. Note that TAPS hasn’t adopted this
draft as a working group item. We have some options. It could be
absorbed into one of the TAPS docs if a) folks thought it was in-scope
and sufficiently useful and b) it was mature enough. If not, we could
consider adopting it in TAPS as a new work item. I’d prefer that it
did not slow down completion of the 3 wg drafts. Thoughts?
--aaron
_______________________________________________
Taps mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/taps
