Subject: [Taps] finishing things

From: "Aaron Falk" <[email-masked]>
Date: Sat, 16 Nov 2019 15:11:15 +0800

Hey Working Group,

Before we meet on Tuesday I wanted to put an idea on the table that I 
think will shape our wg discussion.  What do you think of setting a goal 
of WGLC for our three in-progress docs before the March IETF?  This 
would require increasing wg activity, for example, having monthly calls 
to consider and resolve open issues.  I think we’re reaching a point 
where wg engagement is starting to drop and I’m concerned if we delay 
closing out the docs there will be few people engaged to do a serious 
review of the results.  A lot of work has gone into TAPS and I think we 
should aspire to finish strong.  Comments?  I’m especially interested 
to hear what the doc editors think.

--aaron

---

From: Michael Welzl <[email-masked]>
Date: Sat, 16 Nov 2019 15:13:57 +0800

I think this is a great idea.

Cheers,
Michael

> On Nov 16, 2019, at 3:11 PM, Aaron Falk <[email-masked]> wrote:
> 
> Hey Working Group,
> 
> Before we meet on Tuesday I wanted to put an idea on the table that I think will shape our wg discussion. What do you think of setting a goal of WGLC for our three in-progress docs before the March IETF? This would require increasing wg activity, for example, having monthly calls to consider and resolve open issues. I think we’re reaching a point where wg engagement is starting to drop and I’m concerned if we delay closing out the docs there will be few people engaged to do a serious review of the results. A lot of work has gone into TAPS and I think we should aspire to finish strong. Comments? I’m especially interested to hear what the doc editors think.
> 
> --aaron
> 
> _______________________________________________
> Taps mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/taps

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Sat, 16 Nov 2019 22:37:35 +0800

+1; we should allocate time on our agenda here to actually set the schedule for these interims, to avoid the ”let’s think about that later” problem.

Sent from my iPhone

> On 16 Nov 2019, at 15:13, Michael Welzl <[email-masked]> wrote:
>

---

From: Theresa Enghardt <[email-masked]>
Date: Sun, 17 Nov 2019 08:26:30 +0800

Agree to both aim for WGLC before March and scheduling more interims.

Speaking for myself, I'm pretty confident I'll have more time for TAPS
in the coming months than I had in the previous months.

Best,
Theresa

On 16.11.19 22:37, Brian Trammell (IETF) wrote:
> +1; we should allocate time on our agenda here to actually set the
> schedule for these interims, to avoid the ”let’s think about that
> later” problem.
>
> Sent from my iPhone
>
> On 16 Nov 2019, at 15:13, Michael Welzl <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>>> On Nov 16, 2019, at 3:11 PM, Aaron Falk <[email-masked]
>>> <mailto:[email-masked]>> wrote:
>>>
>>> Hey Working Group,
>>>
>>> Before we meet on Tuesday I wanted to put an idea on the table that
>>> I think will shape our wg discussion. What do you think of setting a
>>> goal of WGLC for our three in-progress docs before the March IETF?
>>> This would require increasing wg activity, for example, having
>>> monthly calls to consider and resolve open issues. I think we’re
>>> reaching a point where wg engagement is starting to drop and I’m
>>> concerned if we delay closing out the docs there will be few people
>>> engaged to do a serious review of the results. A lot of work has
>>> gone into TAPS and I think we should aspire to finish strong.
>>> Comments? I’m especially interested to hear what the doc editors think.
>>>
>>> --aaron
>>>
>>> [email-masked] <mailto:[email-masked]>
>> [email-masked] <mailto:[email-masked]>

---

From: "Aaron Falk" <[email-masked]>
Date: Sun, 17 Nov 2019 10:39:07 +0800

Excellent point.  Suppose at a minimum we assign an owner to each issue 
to propose and socialize a resolution?  If it’s already known or 
obvious, can the folks preparing for Tuesday’s meeting put names of 
nominal owners by issues?

---

From: Michael Welzl <[email-masked]>
Date: Sun, 17 Nov 2019 11:39:48 +0800

but many issues already have people assigned in github....   just a matter of making sure all are assigned to someone?  that should be easy

Sent from my iPhone

> On 17 Nov 2019, at 10:39, Aaron Falk <[email-masked]> wrote:
> 
> 
> Excellent point. Suppose at a minimum we assign an owner to each issue to propose and socialize a resolution? If it’s already known or obvious, can the folks preparing for Tuesday’s meeting put names of nominal owners by issues?
>

---

From: tom petch <[email-masked]>
Date: Sun, 17 Nov 2019 14:48:26 +0000

---- Original Message -----
From: "Aaron Falk" <[email-masked]>
To: "taps WG" <[email-masked]>
Sent: Saturday, November 16, 2019 7:11 AM
Subject: [Taps] finishing things

> to hear what the doc editors think.

Aaron

I am not sure which three you have in mind but suspect that it does not
include
draft-jholland-taps-api-yang

Tom Petch

> --aaron

------------------------------------------------------------------------
--------

---

From: "Aaron Falk" <[email-masked]>
Date: Mon, 18 Nov 2019 10:28:07 +0800

> draft-jholland-taps-api-yang

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

---

From: "Holland, Jake" <[email-masked]>
Date: Mon, 18 Nov 2019 03:55:15 +0000

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-masked]>
Date: 2019-11-18 at 10:28
To: tom petch <[email-masked]>
Cc: taps WG <[email-masked]>
Subject: Re: [Taps] finishing things

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

---

From: "Aaron Falk" <[email-masked]>
Date: Mon, 18 Nov 2019 14:16:26 +0800

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’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)
>
>
> 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: tom petch <[email-masked]>
Date: Tue, 19 Nov 2019 10:09:04 +0000

----- Original Message -----
From: "Aaron Falk" <[email-masked]>
Sent: Monday, November 18, 2019 2:28 AM

> did not slow down completion of the 3 wg drafts.  Thoughts?

I am still not sure which three I-Ds you have in mind!

The challenge with this I-D is that it may become dependent on common
security modules which emerge from Netconf at some future date; that
date could be a long way off.  I suggested to Jake that he should stay
with RYO security structures in which case I would see it as feasible to
incorporate it in the timescale you suggest, but that does depend on it
getting adequate review.

Tom Petch

---

From: Tommy Pauly <[email-masked]>
Date: Tue, 19 Nov 2019 18:12:06 +0800

> On Nov 19, 2019, at 6:09 PM, tom petch <[email-masked]> wrote:
> 
> From: "Aaron Falk" <[email-masked] <mailto:[email-masked]>>

Our three core documents are (from https://datatracker.ietf.org/wg/taps/documents/):

https://datatracker.ietf.org/doc/draft-ietf-taps-arch/
https://datatracker.ietf.org/doc/draft-ietf-taps-interface/
https://datatracker.ietf.org/doc/draft-ietf-taps-impl/

> incorporate it in the timescale you suggest, but that does depend on it

As this is an individual document, and we're not sure as a group if we want to adopt any such work, this won't be on the schedule for the short term. Good to know the possible dependency though!

Thanks,
Tommy

> https://www.ietf.org/mailman/listinfo/taps <https://www.ietf.org/mailman/listinfo/taps>