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

Reply via email to