Re: [Taps] FW: QUIC API (was: Re: Small size of core QUIC library to replace TCP for embedded system)

[Spencer Dawkins at IETF]

On Tue, Aug 11, 2020 at 7:40 AM Mirja Kuehlewind  wrote:

> Maybe this is also interesting for taps as a reference...
>

I sure hope so!

Best,

Spencer


>
> On 10.08.20, 22:35, "QUIC on behalf of Dirkjan Ochtman" <
> quic-boun...@ietf.org on behalf of dirk...@ochtman.nl> wrote:
>
> On Fri, Aug 7, 2020 at 12:57 AM Martin Duke 
> wrote:
> > On this subject, (speaking as individual) I think it would be useful
> to define a QUIC application API. SCTP did one (
> https://datatracker.ietf.org/doc/rfc6458/) and the idea that an
> application would have to be written separately for each quic
> implementation is silly.
>
> For what it's worth, for the hyper library (the most popular HTTP
> library in the Rust ecosystem) we're trying to define a set of Rust
> traits (abstract interfaces) that cover the basic QUIC API insofar as
> H3 support needs it.
>
>
> https://github.com/hyperium/h3/blob/master/design/PROPOSAL.md#4-public-api
>
> Kind regards,
>
> Dirkjan
>
>
> ___
> Taps mailing list
> Taps@ietf.org
> https://www.ietf.org/mailman/listinfo/taps
>
___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] Eric Rescorla's No Objection on draft-ietf-taps-minset-08: (with COMMENT)

[Spencer Dawkins at IETF]

FWIW,

On Sun, Sep 16, 2018 at 7:03 AM Michael Welzl  wrote:

>
> >> > S 7.2.
>> >> >
>> >> > o  Disable MPTCP
>> >> >Protocols: MPTCP
>> >> >Automatable because the usage of multiple paths to
>> communicate to
>> >> >the same end host relates to knowledge about the network, not
>> the
>> >> >application.
>> >> >
>> >> > I don't think I understand how this is automatable. Is the theory
>> that
>> >> > the host auto-negotiates MPTCP? But what if the app doesn't want it
>> no
>> >> > matter what.
>> >>
>> >> Then the application wants more than what this design of strictly
>> >> "application-specific knowledge" is giving it. That's the trade-off
>> here -
>> >> there may be many reasons for applications to want things beyond this
>> >> document, but if we weren't strict about these limitations, this would
>> >> have hardly become a "minimal set".
>> >>
>> >> That's reasonable, but it seems like a somewhat confusing definition.
>> >
>> > What is it that’s confusingly defined? “application-specific
>> knowledge”? “Automatable"? Happy to fix if you tell me what.
>> >
>> > Automatable, I think.
>>
>> Okay, so this is what we have in the text:
>>
>> " The transport features of IETF transport protocols that do not
>>require application-specific knowledge and could therefore be
>>utilized by a transport system on its own without involving the
>>application are called "Automatable". "
>>
>> and "application-specific knowledge" is defined as "knowledge that only
>> applications have."
>>
>> I'm guessing that the issue that you have with "automatable" is that it
>> sounds too much as if the application's input really isn't needed here, no
>> matter what. I'd like to use a "weaker" word in that sense... because of
>> that, we once called it "Potentially automatable", but then that was too
>> long and clumsy.
>> Do you have any suggestions?
>>
>
> Not really. I guess the thing that I'm saying is that MPTCP is something
> that the stack could automatically decide to use, but it can't
> automatically decide *not* to use if the application wants that. That's
> what's puzzling me about “automatable"
>
>
> You’re right about disabling MPTCP: typically the decision to do so would
> depend not only on knowledge about the net or OS, but also the type of data
> that an application has. Sticking with the specs as minset is doing, I
> searched, and found, in RFC 6897:
>
> Section 3.1: "The following sections summarize the performance effect of
> MPTCP as seen by an application.”
>
> and in there, we have things like:
> **
>The benefits of MPTCP regarding throughput and resilience may come at
>some cost regarding data delivery delay and delay jitter.
> (..)
>Applications with high real-time requirements might be affected by
>such a scenario.  One possible remedy is to disable MPTCP for such
>jitter-sensitive applications, either by using the basic API defined
>in this document, or by other means, such as system policies.
> **
>
> I guess the decision on whether to use MPTCP or not is actually a mix of
> knowledge about the network and app requirements. A better interface (IMO)
> would have the app tell its requirements, such that a system below it could
> automate its decision. I hope we get to that
> with draft-ietf-taps-interface, but that’s beyond minset - I think minset
> should therefore recommend exposure of “Disable MPTCP” and call it
> “Optimizing”, not “Automatable”. However, I think we should still not
> recommend exposure of adding and removing paths, as these really don’t make
> sense without net-specific knowledge.
>

Speaking as an individual contributor in PANRG, and not as an AD, I'm not
sure that PANRG would be ready to recommend that yet, even with
net-specific knowledge!

Do you agree? If so, I’ll make that update in the next version - that was a
> great catch indeed!
>

Speaking as the responsible AD, yes, it was, and thank you, Eric, for
catching it.

Spencer


> Cheers,
> Michael
>
>
>
___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] Alissa Cooper's Discuss on draft-ietf-taps-minset-08: (with DISCUSS and COMMENT)

[Spencer Dawkins at IETF]

Hi, Alissa,

On Wed, Sep 12, 2018 at 2:22 PM Alissa Cooper  wrote:

> Alissa Cooper has entered the following ballot position for
> draft-ietf-taps-minset-08: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-taps-minset/
>
>
>
> --
> DISCUSS:
> --
>
> I was wondering about why this document is going for informational rather
> than
> proposed standard. I see that draft-ietf-taps-interface-01 has a normative
> reference to it, so this is effectively setting up a downref situation.
> That
> isn't necessarily a problem, but if the point is for this document to
> recommend
> an actual minimal set of transport services to be supported and exposed
> via the
> API specified in draft-ietf-taps-interface and other APIs, shouldn't that
> set
> be normative?
>

Understood. I'll need to talk about this with the TAPS chairs, and that
won't happen before the telechat tomorrow morning, but I will talk with the
TAPS chairs, and you'll have an answer.

(So, "do we need to discuss that on this telechat?", "no, the Discuss is
clear and actionable". - just to save wear and tear on the Secretariat!)

Thanks,

Spencer


> --
> COMMENT:
> --
>
> It seems like this document will be in need of updating once QUIC is
> published.
> Is the plan to publish this now and then publish an update next year? Why
> is
> that preferable to waiting and just publishing once?
>
>
>
___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] Genart last call review of draft-ietf-taps-minset-06

[Spencer Dawkins at IETF]

Hi, Michael,

On Fri, Aug 31, 2018, 15:35 Michael Welzl  wrote:

> Hi Spencer,
>
> See below:
>
> On Aug 31, 2018, at 7:41 PM, Spencer Dawkins at IETF <
> spencerdawkins.i...@gmail.com> wrote:
>
> Thanks, Robert, for the careful read, and thanks, Michael, for the quick
> response. I have one thought, on Robert's last question.
>
> On Fri, Aug 31, 2018 at 3:37 AM Michael Welzl  wrote:
>
>> Hi,
>>
>> Thank you very much for this careful review!  We just posted a revision (
>> -07 ) that, we believe, addresses these comments.
>>
>> A few answers in line below:
>>
>> > On 28 Aug 2018, at 23:38, Robert Sparks  wrote:
>> >
>> > Reviewer: Robert Sparks
>> > Review result: Ready with Nits
>
>
> ...
>
>
>> > In Appendix A.1, this document had to "slightly change" the
>> > characterization of features  from those in RFC8303, introducing this
>> > "ADDED" construct. That feels out of balance. Is this a warning sign
>> > that RFC8303 needs adjusting?
>>
>> It isn't: different from this document, RFC 8303 does not make any
>> changes or derive anything from the services that protocols offer - it just
>> reflects what the protocol specifications say.
>>
>> In the minset document, there are only 3 items using the "ADDED"
>> construct, and this is only meant to streamline the derivation a little.
>> Take "Unreliably transfer a message", for example.
>> This is based on (from RFC 8303) "Unreliably transfer a message, with
>> congestion control" for SCTP, and "Unreliably transfer a message, without
>> congestion control" for UDP(-Lite). The added "Unreliably transfer a
>> message" leaves the choice of congestion control open, such that an
>> application CAN simply say "Unreliably transfer a message" without having
>> to care about the choice of congestion control (unless it wants to care,
>> which comes at the cost of binding itself to either UDP(-Lite) or SCTP).
>>
>
> Michael, this explanation helps a lot, but since I happen to know that
> Robert is out of town for the three-day weekend in the US, I'll guess on
> his behalf that "ADDED" may not be the word you're looking for - at a
> minimum, "transfer unreliably" in RFC 8303 being divided into "transfer
> unreliably with congestion control" and "transfer unreliably without
> congestion control" in this draft doesn't look like addition to me.
>
> Is this more about "refactoring the protocol-independent definition in RFC
> 8303”?
>
>
> Yes, “refactoring” is exactly right - it’s not adding anything new. We
> could just as well have left this without the “ADDED” cases and then had
> more explanations in the “discussions” section (appendix A.3), but these
> are so minor that they don’t really merit a “discussion”, hence we felt
> that this way it’s shorter and clearer.
>
> If that helps, I can rename “ADDED” into “REFACTORED”?
>

I'll let you and Robert resynchronize on this, now that I think you'll be
talking about the same thing.

I'll watch, if I'm needed, of course.

Spencer

Cheers,
> Michael
>
> But, whatever it is, if you two can figure out how to describe what's
> happening, that will probably help figure you and Robert agree on an
> understanding about how to handle his comment.
>
> Spencer
>
>
>
>
___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] Publication has been requested for draft-ietf-taps-minset-04

[Spencer Dawkins at IETF]

Hi, Michael,

On Wed, Aug 22, 2018 at 8:50 AM Michael Welzl  wrote:

>
>
> > On 22 Aug 2018, at 15:20, Spencer Dawkins at IETF <
> spencerdawkins.i...@gmail.com> wrote:
> >
> > Hi, Michael,
> > On Wed, Aug 22, 2018 at 7:49 AM Michael Welzl 
> wrote:
> > Hi,
> >
> >
> > > On 21 Aug 2018, at 22:27, Spencer Dawkins at IETF <
> spencerdawkins.i...@gmail.com> wrote:
> > >
> > > Hi, Aaron,
> > >
> > > On Tue, Aug 21, 2018 at 1:44 PM Aaron Falk 
> wrote:
> > > Glad to see rapid convergence on these comments. My turn for a nit:
> > >
> > > On 21 Aug 2018, at 2:48, Michael Welzl wrote:
> > >
> > > I'm not sure if you saw my suggestion about qualifying the reference
> to [I-D.ietf-taps-transport-security] as "Section 5 of
> [I-D.ietf-taps-transport-security]", but assuming that we're good on that
> one 
> > >
> > >
> > > I saw it and agree. I thought that it's not necessary for the specific
> sentence that you ended up proposing, but now I agree that even in this
> sentence it's better. I'll update it to include "Section 5 of" just ahead
> of this reference.
> > >
> > > The likelihood of an ID having it's sections renumbered is high enough
> that I don't think we should embed the section number in an RFC. I'd
> suggest using the section name as well in case one or both changes the
> reader is likely to make the connection: "Section 5 on Security Features
> and Transport Dependencies of ..."
> > >
> > >
> > > I totally agree on this one. I only suggested adding the section
> number because I couldn't find any mention of the minimum set in the
> abstract or Introduction for [I-D.ietf-taps-transport-security], so a
> reader would have to scroll through the Table of Contents to notice it. I
> had a nagging feeling when I made the suggestion - thanks for fixing it.
> >
> > Done (in my local copy). Actually I thought of the same thing but wasn't
> sure for one reason or another... I should have just gone for it!
> >
> >
> > > If I might make one other observation, there are a few places visible
> in https://tools.ietf.org/rfcdiff?url2=draft-ietf-taps-minset-05.txt for
> Section A (I think A.1) where there seems to be a missing newline between
> "Implementation over TCP:" and "Implementation over UDP:" - I saw more than
> one occurrence, but I think the first one to check is under "Specify
> checksum coverage used by the sender" for "Protocols: UDP-Lite". I had
> thought to make that observation as a response to the Last Call
> announcement, but Aaron sent his suggested change before I did that.
> >
> > I don't see this; "Implementation over UDP" seems to start on a new line
> everywhere. What I do see is that an extra empty line has unintentionally
> ended up in there in a few places. Do you mean that there SHOULD be an
> extra empty line?
> >
> > I'm not sure what I'm seeing is what you're seeing. Let's talk before
> asking you to type :-)
> >
> > I'm looking at the bottom of page 29, top of page 30, in the HTML
> version. That's for
> >
> >o  Specify checksum coverage used by the sender
> >   Protocols: UDP-Lite
> >
> > What I'm seeing in HTML for this section, is
> >
> >o  Specify checksum coverage used by the sender
> >   Protocols: UDP-Lite
> >   Functional because application-specific knowledge is necessary to
> >   decide for which parts of the data it can be acceptable to lose
> >   data integrity.
> >
> >
> >
> > Welzl & GjessingExpires February 21, 2019  [Page 29]
> >
> > Internet-Draft Minimal Transport ServicesAugust 2018
> >
> >
> >   Implementation: via SET_CHECKSUM_COVERAGE.UDP-Lite.
> >   Implementation over TCP: do nothing (TCP does not offer to limit
> >   the checksum length, but transmitting data with an intact checksum
> >   will not yield a semantically wrong result).  Implementation over
> >
> > So, I'm not seeing a newline before "Implementation" here.
> >
> >   UDP: if checksum coverage is set to cover payload data, do
> >   nothing.  Else, either do nothing (transmitting data with an
> >   intact checksum will not yield a semantically wrong result), or
> >   use the transport feature "Disable checksum when sending".
> >
> > But since I always use the HTML version, and that's not even the
> canonical version, I checked the s

Re: [Taps] Publication has been requested for draft-ietf-taps-minset-04

[Spencer Dawkins at IETF]

Hi, Michael,
On Wed, Aug 22, 2018 at 7:49 AM Michael Welzl  wrote:

> Hi,
>
>
> > On 21 Aug 2018, at 22:27, Spencer Dawkins at IETF <
> spencerdawkins.i...@gmail.com> wrote:
> >
> > Hi, Aaron,
> >
> > On Tue, Aug 21, 2018 at 1:44 PM Aaron Falk  wrote:
> > Glad to see rapid convergence on these comments. My turn for a nit:
> >
> > On 21 Aug 2018, at 2:48, Michael Welzl wrote:
> >
> > I'm not sure if you saw my suggestion about qualifying the reference to
> [I-D.ietf-taps-transport-security] as "Section 5 of
> [I-D.ietf-taps-transport-security]", but assuming that we're good on that
> one ...
> >
> >
> > I saw it and agree. I thought that it's not necessary for the specific
> sentence that you ended up proposing, but now I agree that even in this
> sentence it's better. I'll update it to include "Section 5 of" just ahead
> of this reference.
> >
> > The likelihood of an ID having it's sections renumbered is high enough
> that I don't think we should embed the section number in an RFC. I'd
> suggest using the section name as well in case one or both changes the
> reader is likely to make the connection: "Section 5 on Security Features
> and Transport Dependencies of ..."
> >
> >
> > I totally agree on this one. I only suggested adding the section number
> because I couldn't find any mention of the minimum set in the abstract or
> Introduction for [I-D.ietf-taps-transport-security], so a reader would have
> to scroll through the Table of Contents to notice it. I had a nagging
> feeling when I made the suggestion - thanks for fixing it.
>
> Done (in my local copy). Actually I thought of the same thing but wasn't
> sure for one reason or another... I should have just gone for it!
>
>
> > If I might make one other observation, there are a few places visible in
> https://tools.ietf.org/rfcdiff?url2=draft-ietf-taps-minset-05.txt for
> Section A (I think A.1) where there seems to be a missing newline between
> "Implementation over TCP:" and "Implementation over UDP:" - I saw more than
> one occurrence, but I think the first one to check is under "Specify
> checksum coverage used by the sender" for "Protocols: UDP-Lite". I had
> thought to make that observation as a response to the Last Call
> announcement, but Aaron sent his suggested change before I did that.
>
> I don't see this; "Implementation over UDP" seems to start on a new line
> everywhere. What I do see is that an extra empty line has unintentionally
> ended up in there in a few places. Do you mean that there SHOULD be an
> extra empty line?


I'm not sure what I'm seeing is what you're seeing. Let's talk before
asking you to type :-)

I'm looking at the bottom of page 29, top of page 30, in the HTML version.
That's for

   o  Specify checksum coverage used by the sender
  Protocols: UDP-Lite

What I'm seeing in HTML for this section, is

   o  Specify checksum coverage used by the sender
  Protocols: UDP-Lite
  Functional because application-specific knowledge is necessary to
  decide for which parts of the data it can be acceptable to lose
  data integrity.



Welzl & GjessingExpires February 21, 2019  [Page 29]

Internet-Draft Minimal Transport ServicesAugust 2018


  Implementation: via SET_CHECKSUM_COVERAGE.UDP-Lite.
  Implementation over TCP: do nothing (TCP does not offer to limit
  the checksum length, but transmitting data with an intact checksum
  will not yield a semantically wrong result).  Implementation over

So, I'm not seeing a newline before "Implementation" here.

  UDP: if checksum coverage is set to cover payload data, do
  nothing.  Else, either do nothing (transmitting data with an
  intact checksum will not yield a semantically wrong result), or
  use the transport feature "Disable checksum when sending".

But since I always use the HTML version, and that's not even the canonical
version, I checked the same thing in the TXT version, but it also looks
like

   o  Specify checksum coverage used by the sender
  Protocols: UDP-Lite
  Functional because application-specific knowledge is necessary to
  decide for which parts of the data it can be acceptable to lose
  data integrity.



Welzl & GjessingExpires February 21, 2019  [Page 29]
Internet-Draft Minimal Transport ServicesAugust 2018


  Implementation: via SET_CHECKSUM_COVERAGE.UDP-Lite.
  Implementation over TCP: do nothing (TCP does not offer to limit
  the checksum length, but transmitting data with an intact checksum
  will not yield a semantically wrong result).  Implementation over

and I

Re: [Taps] Publication has been requested for draft-ietf-taps-minset-04

[Spencer Dawkins at IETF]

Hi, Michael,

On Mon, Aug 20, 2018 at 9:11 AM Michael Welzl  wrote:

> Hi,
>
> Thanks again !
>
>
> > On 20 Aug 2018, at 15:52, Spencer Dawkins at IETF <
> spencerdawkins.i...@gmail.com> wrote:
> >
> > Hi, Michael,
> >
> > On Mon, Aug 20, 2018 at 3:57 AM Michael Welzl 
> wrote:
> > Hi Spencer!
> >
> > Thank you so much for your detailed work and all these comments!
> > I'm commenting in line below, and marking my comments with "MW:".
> > I'm terminating my responses with a "--".
> >
> > I'm attaching an update which incorporates the changes described in this
> email, but I'm delaying its submission until it's clear that this
> conversation has converged.
> >
> > We're pretty darned converged. I have a couple of follow-ups below, but
> I deleted everything that we're already good on (and thank you for those,
> in advance).
> >
> > My only significant question is on Section 7.
>
> Great - it seems this is also the only one that calls for a change of the
> version that I now have. So, I'm removing the rest and just keeping this:
>
>
> > --
> >
> > This text in 7.  Security Considerations
> >
> >Authentication, confidentiality protection, and integrity protection
> >are identified as transport features by [RFC8095].  As currently
> >deployed in the Internet, these features are generally provided by a
> >protocol or layer on top of the transport protocol; no current full-
> >featured standards-track transport protocol provides all of these
> >transport features on its own.  Therefore, these transport features
> >are not considered in this document, with the exception of native
> >authentication capabilities of TCP and SCTP for which the security
> >considerations in [RFC5925] and [RFC4895] apply.  The minimum
> >security requirements for a transport system are discussed in a
> >separate document [I-D.ietf-taps-transport-security].
> >
> > confuses me, because I think at least two things are in play. First, I
> think the point you're probably making is that the underlying transport
> protocols remain unmodified, so the security considerations for each of
> those protocols apply unchanged, and this document isn't doing anything to
> create new security considerations. So, modulo SECDIR and SEC AD comments,
> I think that's all you need to say.
> >
> > Second, you guys are the experts, but I think a reference to
> [I-D.ietf-taps-transport-security] isn't actually needed for this document,
> because that document surveys security protocols, rather than specifying
> minimum security requirements. That document might someday discuss the
> minimum security requirements, in the way this document discusses the
> minimum set of transport services, but at least in
> https://tools.ietf.org/html/draft-ietf-taps-transport-security-02 that
> document is much more comparable to RFCs 8095 and 8304 than to this
> document.
> >
> > MW: I would agree about [I-D.ietf-taps-transport-security] if it didn't
> have section 5.
> > I believe section 5 in this document is an effort to do the same as
> minset does, here;
> > are you maybe asking for this section of
> [I-D.ietf-taps-transport-security] to use a
> > more authoritative tone?  Either way, as things stand now, the existence
> of
> > [I-D.ietf-taps-transport-security] is used as a justification to not
> include the
> > security related features of TCP and SCTP in the minimum set, and I
> think this
> > citation is necessary.
> >
> > So, for what it's worth, I wouldn't have ever noticed that Section 5 of
> [I-D.ietf-taps-transport-security] provided the equivalent of this
> document, based on the Abstract and Introduction, which both talk about
> surveys a lot more than minimum sets, but that's not your problem to solve
> (and I'm not providing AD comments on documents that the working group is
> still working on, because you guys are more likely to get stuff right than
> I am, so no action required from anyone else).
> >
> > But what is for you ...
> >
> > At a minimum, I'd suggest qualifying the reference to
> [I-D.ietf-taps-transport-security]  as "Section 5 of
> [I-D.ietf-taps-transport-security] ", because I don't suppose that any
> other reviewer is more likely to figure this out than I am, but ...
> >
> > Quoting from the Introduction in -02 of
> I-D.ietf-taps-transport-security, what that draft is covering is
> >
> >This document provides a survey of commonly used or notable network
> >security protocols, with a focus on how they

Re: [Taps] Publication has been requested for draft-ietf-taps-minset-04

[Spencer Dawkins at IETF]

Hi, Michael,

On Mon, Aug 20, 2018 at 3:57 AM Michael Welzl  wrote:

> Hi Spencer!
>
> Thank you so much for your detailed work and all these comments!
> I'm commenting in line below, and marking my comments with "MW:".
> I'm terminating my responses with a "--".
>
> I'm attaching an update which incorporates the changes described in this
> email, but I'm delaying its submission until it's clear that this
> conversation has converged.
>

We're pretty darned converged. I have a couple of follow-ups below, but I
deleted everything that we're already good on (and thank you for those, in
advance).

My only significant question is on Section 7.

Spencer


> --
>
> This text in 7.  Security Considerations
>
>Authentication, confidentiality protection, and integrity protection
>are identified as transport features by [RFC8095].  As currently
>deployed in the Internet, these features are generally provided by a
>protocol or layer on top of the transport protocol; no current full-
>featured standards-track transport protocol provides all of these
>transport features on its own.  Therefore, these transport features
>are not considered in this document, with the exception of native
>authentication capabilities of TCP and SCTP for which the security
>considerations in [RFC5925] and [RFC4895] apply.  The minimum
>security requirements for a transport system are discussed in a
>separate document [I-D.ietf-taps-transport-security].
>
> confuses me, because I think at least two things are in play. First, I
> think the point you're probably making is that the underlying transport
> protocols remain unmodified, so the security considerations for each of
> those protocols apply unchanged, and this document isn't doing anything to
> create new security considerations. So, modulo SECDIR and SEC AD comments,
> I think that's all you need to say.
>
> Second, you guys are the experts, but I think a reference to
> [I-D.ietf-taps-transport-security] isn't actually needed for this document,
> because that document surveys security protocols, rather than specifying
> minimum security requirements. That document might someday discuss the
> minimum security requirements, in the way this document discusses the
> minimum set of transport services, but at least in
> https://tools.ietf.org/html/draft-ietf-taps-transport-security-02 that
> document is much more comparable to RFCs 8095 and 8304 than to this
> document.
>
> MW: I would agree about [I-D.ietf-taps-transport-security] if it didn't
> have section 5.
> I believe section 5 in this document is an effort to do the same as minset
> does, here;
> are you maybe asking for this section of
> [I-D.ietf-taps-transport-security] to use a
> more authoritative tone?  Either way, as things stand now, the existence of
> [I-D.ietf-taps-transport-security] is used as a justification to not
> include the
> security related features of TCP and SCTP in the minimum set, and I think
> this
> citation is necessary.
>

So, for what it's worth, I wouldn't have ever noticed that Section 5
of  [I-D.ietf-taps-transport-security] provided the equivalent of this
document, based on the Abstract and Introduction, which both talk about
surveys a lot more than minimum sets, but that's not your problem to solve
(and I'm not providing AD comments on documents that the working group is
still working on, because you guys are more likely to get stuff right than
I am, so no action required from anyone else).

But what is for you ...

At a minimum, I'd suggest qualifying the reference to
[I-D.ietf-taps-transport-security]  as "Section 5 of
[I-D.ietf-taps-transport-security] ", because I don't suppose that any
other reviewer is more likely to figure this out than I am, but ...

Quoting from the Introduction in -02 of  I-D.ietf-taps-transport-security,
what that draft is covering is

   This document provides a survey of commonly used or notable network
   security protocols, with a focus on how they interact and integrate
   with applications and transport protocols.  Its goal is to supplement
   efforts to define and catalog transport services [RFC8095] by
   describing the interfaces required to add security protocols.  It
   examines Transport Layer Security (TLS), Datagram Transport Layer
   Security (DTLS), Quick UDP Internet Connections with TLS (QUIC +
   TLS), MinimalT, CurveCP, tcpcrypt, Internet Key Exchange with
   Encapsulating Security Protocol (IKEv2 + ESP), SRTP (with DTLS), and
   WireGuard.

I may be confused about this, but I'm not seeing an obvious pattern match
between those protocols and "security related features of TCP and SCTP in
the minimum set". Is that document talking about what you hope it's talking
about?

Assuming so ... I'm probably struggling with the idea that there is no
minimal set of transport services that doesn't involve one of the protocols
listed in I-D.ietf-taps-transport-security or a near equivalent. That may
really be the right thing 

Re: [Taps] Publication has been requested for draft-ietf-taps-minset-04

[Spencer Dawkins at IETF]

Dear TAPsters,

I've completed my AD review for this document, and have two high-level
responses:

   - This looks good, and
   - I only have 8 pages of comments ...

Please look these over, and ask for explanations if you need them. When we
work through my comments, I'll request Last Call.

And thanks for your work to date.

Spencer

I'm looking at this text

   Because the considered
   transport protocols conjointly cover a wide range of transport
   features, there is reason to hope that the resulting set (and the
   reasoning that led to it) will also apply to many aspects of other
   transport protocols.

and wondering whether it's accurate to say "many aspects of other transport
protocols that may be in use today, or may be designed in the future"?

Part of my question is wrapped up in discussions about whether QUIC is a
one-off new transport protocol, or whether QUIC is the first example of a
new generation of transport protocols that are now worth designing because
we know how to deploy them.

This text

   For example, it does not help an
   application that talks to a library which offers its own
   communication interface if only the underlying Berkeley Sockets API
   is extended to offer "unordered message delivery", but the library
   only exposes an ordered bytestream.

read oddly to me - I think the first "only" could be removed, unless I'm
missing your point, but please take a look at that sentence for clarity.

This text

   This "minimal set" can be implemented one-sided over TCP (or UDP, if
   certain limitations are put in place).  This means that a sender-side
   transport system can talk to a standard TCP (or UDP) receiver, and a
   receiver-side transport system can talk to a standard TCP (or UDP)
   sender.

was a bit difficult for me to read, and seems to mix explaining what
"one-sided" means with the explanation that "one-sided" also applies to
UDP, if certain limitations are put in place. I wonder if it is accurate to
say

   This "minimal set" can be implemented "one-sided" over TCP.  This means
   that a sender-side transport system can talk to a standard TCP receiver,
   and a receiver-side transport system can talk to a standard TCP sender.
   If certain limitations are put in place, the "minimal set" can also be
   implemented "one-sided" over UDP.

Is "ungrouped communication" in

   For ungrouped connections, early configuration is necessary because
   it allows the transport system to know which protocols it should try
   to use.

a well-understood term? I can guess at the meaning, but I'd be guessing,
and RFCs 8095 and 8304 don't define or use either term.(Further down, I
also see "grouped communications", and I'm guessing what that means, too,
and Section 3.2.1 is even called "Connection groups", but doesn't clearly
define what that means)

I don't disagree with

  Note that this decision tree is not optimal for all cases.  For
   example, if an application wants to use "Specify checksum coverage
   used by the sender", which is only offered by UDP-Lite, and
   "Configure priority or weight for a scheduler", which is only offered
   by SCTP, the above decision tree will always choose UDP-Lite, making
   it impossible to use SCTP's schedulers with priorities between
   grouped connections.  The transport system must know which choice is
 ^^
   more important for the application in order to make the best
   ^^
   decision.  We caution implementers to be aware of the full set of
   trade-offs, for which we recommend consulting the list in
   Appendix A.2.1 when deciding how to initialize a connection.

but I'm not sure how a general-purpose transport system will know which
choice is more important for any arbitrary application. I see the Is this
advice transport system implementers can act on?

This isn't a big deal, but

  This also means that the active opening side is assumed to be the
   first side sending data.

seems really reasonable for the vast majority of (client-server)
applications, but I wonder if peer-to-peer applications will trip over a
problem here ("I open a connection to you, but you already had data queued
for me since we last connected and you sent it immediately" could be a
scenario for SMTP or DTN, I guess). But I'll let you folks think about that..

This is a nit, but

  o  A buffer limit (in bytes); when the sender has less then the
  than

In this text,

  o  Reliability: this parameter is used to convey a choice of: fully
  reliable (!UDP), unreliable without congestion control, unreliable
  (!UDP), partially reliable (see [RFC3758] and [RFC7496] for
  details on how to specify partial reliability) (!UDP).

it took me some re-reading to figure out that "unreliable (!UDP)" meant
something besides JUST "unreliable" (because UDP is "unreliable without
congestion control"). Could 

Re: [Taps] virtual interim meeting

[Spencer Dawkins at IETF]

Hi, Aaron,

On Mon, Apr 30, 2018 at 10:25 AM, Aaron Falk  wrote:

> We’d like to hold an interim call to discuss the new docs.
>
>- Duration: 2hrs
>- Method: WebEx
>- Time zones to accommodate: PDT, EDT, BST, CEST
>- Schedule: w/o May 14
>
> Agenda:
>
>1. open issues in draft-ietf-taps-interface-00.txt (Brian)
>2. open issues in draft-ietf-taps-arch-00.txt (Tommy)
>3. open issues in draft-ietf-taps-impl-00.txt (Anna) (if submitted)
>4. open issues in draft-ietf-taps-transport-security-01.txt (Chris)
>(if submitted)
>
> The hasn’t been approved yet but I’d like to quickly agree on a date.
> Please use this Doodle if you plan to attend and contribute. (If you just
> want to lurk, you are welcome but don’t make us schedule around you. :)
>
> LINK: https://doodle.com/poll/w92dudq592bvuzb6
>
> (This is the first time I’ve scheduled an interim so I may get a few
> process bits wrong...)
>

We don't do a lot of virtual interims in TSV, but we'll make that happen,
even if we have to adjust a few things along the way.

Spencer
___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] Alissa Cooper's No Objection on charter-ietf-taps-01-00: (with COMMENT)

[Spencer Dawkins at IETF]

Hi, Kathleen and EKR,

On Tue, Jan 30, 2018 at 6:50 PM, Christopher Wood <
christopherwoo...@gmail.com> wrote:

> Hi Spencer,
>
> On Tue, Jan 30, 2018 at 4:42 PM, Spencer Dawkins at IETF
> <spencerdawkins.i...@gmail.com> wrote:
> > Dear TAPsters,
> >
> > On Wed, Jan 24, 2018 at 10:20 AM, Alissa Cooper <ali...@cooperw.in>
> wrote:
> >>
> >> Alissa Cooper has entered the following ballot position for
> >> charter-ietf-taps-01-00: No Objection
> >>
> >> When responding, please keep the subject line intact and reply to all
> >> email addresses included in the To and CC lines. (Feel free to cut this
> >> introductory paragraph, however.)
> >>
> >>
> >>
> >> The document, along with other ballot positions, can be found here:
> >> https://datatracker.ietf.org/doc/charter-ietf-taps/
> >>
> >>
> >>
> >> --
> >> COMMENT:
> >> --
> >>
> >> Since the point of this update is to add security analysis to the
> charter
> >> scope, would it make sense to specify how the WG plans to engage with
> the
> >> security area, as is typically done when there is overlap or coupling
> >> between
> >> work in different WGs? E.g., will the WG be seeking early review from
> the
> >> security area on relevant drafts?
> >
> >
> > Alissa has a reasonable question here. Could you let me know what you're
> > thinking about the best way to interact with the security area for this
> > work?
>
> I imagined we'd circulate polished drafts to SecDispatch or SAAG for
> review. However, if there is relevant precedent in this sort of
> cross-area collaboration, it'd make sense to follow that instead.


Could you let me know if this proposed way of TAPS coordinating with the
security community makes sense to you folks?

If so, I'll add it to the updated TAPS charter.

(I'm not seeing a SecDispatch working group or non-WG mailing list - am I
missing something? :-)

Thanks,

Spencer
___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] Benoit Claise's No Objection on charter-ietf-taps-01-00: (with COMMENT)

[Spencer Dawkins at IETF]

Hi, Benoit,

On Thu, Jan 25, 2018 at 8:31 AM, Benoit Claise  wrote:

> Benoit Claise has entered the following ballot position for
> charter-ietf-taps-01-00: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/charter-ietf-taps/
>
>
>
> --
> COMMENT:
> --
>
> Agree with Ben and Adam.  I completely missed the subtleties of this
> change.
>
> The "or" in the following excerpt really don't help
>The following topics are out of scope for this Working Group:
>- Extension, modification, or creation of transport or
>  security protocols
>
> What is out of scope: A, B, or maybe C or D?
>
> Not blocking this recharter, but please improve.
>

Agreed. I had stuffed more text into an existing bullet, and the new text
would almost certainly be clearer in its own bullet, so separating into

   - Extension, modification, or creation of transport protocols

   - Extension, modification, or creation of security protocols

Thanks,

Spencer
___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] Alissa Cooper's No Objection on charter-ietf-taps-01-00: (with COMMENT)

[Spencer Dawkins at IETF]

Dear TAPsters,

On Wed, Jan 24, 2018 at 10:20 AM, Alissa Cooper  wrote:

> Alissa Cooper has entered the following ballot position for
> charter-ietf-taps-01-00: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/charter-ietf-taps/
>
>
>
> --
> COMMENT:
> --
>
> Since the point of this update is to add security analysis to the charter
> scope, would it make sense to specify how the WG plans to engage with the
> security area, as is typically done when there is overlap or coupling
> between
> work in different WGs? E.g., will the WG be seeking early review from the
> security area on relevant drafts?
>

Alissa has a reasonable question here. Could you let me know what you're
thinking about the best way to interact with the security area for this
work?

Thanks,

Spencer
___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] Ben Campbell's No Objection on charter-ietf-taps-01-00: (with COMMENT)

[Spencer Dawkins at IETF]

Hi, Ben,

On Jan 24, 2018 9:42 AM, "Ben Campbell" <b...@nostrum.com> wrote:



> On Jan 24, 2018, at 8:38 AM, Spencer Dawkins at IETF <
spencerdawkins.i...@gmail.com> wrote:
>
> Hi, Ben,
>
> On Wed, Jan 24, 2018 at 3:53 AM, Mirja Kühlewind <i...@kuehlewind.net>
wrote:
> Hi Ben,
>
> this change rather removed the restriction to not analyze features of
security protocols (other than tcpinc); this is mainly the first sentence.
As we see a closer integration of TLS with QUIC and we in general think
that security features are important, it is actually an important change to
allow us to do some additional work in this space.
>
> What Mirja said, but more than that - when I chartered TAPS, I was
thinking about choosing between transport protocols, but that's morphing
into choosing paths based on the way each potential path supports those
transport protocols, and paths can differ in the way they treat transport
security. So the working group should be including transport security in
its analysis, and that was excluded in the current charter.
>
> Does that help?

Yes, and it answers the question I just asked in response to Mirja’s email
:-)

Would it make sense to put “include transport security in it’s analysis” in
the explicitly in-scope bits?


That doesn't seem obviously wrong.

We may have been more focused on removing the prohibition than saying what
should happen, now that the prohibition has been removed :-)

Let me talk to the TAPSters about specific wording.

And thanks for asking.

Spencer



>
> Spencer
>
>
> Mirjas
>
>
> On 24.01.2018 04:42, Ben Campbell wrote:
> Ben Campbell has entered the following ballot position for
> charter-ietf-taps-01-00: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/charter-ietf-taps/
>
>
>
> --
> COMMENT:
> --
>
> Do I read correctly that the only change from the previous charter is to
remove
> the paragraph about coordinating with TCPINC? If so, I'm not sure that
change
> is important enough to justify rechartering, but I won't get in the way if
> other people agree with it.
>
>
>
> ___
> Taps mailing list
> Taps@ietf.org
> https://www.ietf.org/mailman/listinfo/taps
___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] Ben Campbell's No Objection on charter-ietf-taps-01-00: (with COMMENT)

[Spencer Dawkins at IETF]

Hi, Ben,

On Wed, Jan 24, 2018 at 3:53 AM, Mirja Kühlewind 
wrote:

> Hi Ben,
>
> this change rather removed the restriction to not analyze features of
> security protocols (other than tcpinc); this is mainly the first sentence.
> As we see a closer integration of TLS with QUIC and we in general think
> that security features are important, it is actually an important change to
> allow us to do some additional work in this space.
>

What Mirja said, but more than that - when I chartered TAPS, I was thinking
about choosing between transport protocols, but that's morphing into
choosing paths based on the way each potential path supports those
transport protocols, and paths can differ in the way they treat transport
security. So the working group should be including transport security in
its analysis, and that was excluded in the current charter.

Does that help?

Spencer


> Mirjas
>
>
> On 24.01.2018 04:42, Ben Campbell wrote:
>
>> Ben Campbell has entered the following ballot position for
>> charter-ietf-taps-01-00: No Objection
>>
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut this
>> introductory paragraph, however.)
>>
>>
>>
>> The document, along with other ballot positions, can be found here:
>> https://datatracker.ietf.org/doc/charter-ietf-taps/
>>
>>
>>
>> --
>> COMMENT:
>> --
>>
>> Do I read correctly that the only change from the previous charter is to
>> remove
>> the paragraph about coordinating with TCPINC? If so, I'm not sure that
>> change
>> is important enough to justify rechartering, but I won't get in the way if
>> other people agree with it.
>>
>>
>>
> ___
> Taps mailing list
> Taps@ietf.org
> https://www.ietf.org/mailman/listinfo/taps
>
___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] One RFC, or two, for draft-ietf-taps-transports-usage and draft-ietf-taps-transports-usage-udp

[Spencer Dawkins at IETF]

Just to make a long-delayed decision ...

Based on responses to my question to TAPS about whether
draft-ietf-taps-transports-usage-udp should be folded into
draft-ietf-taps-transports-usage, I am seeing no support in the working
group for that, and reasons why the draft-ietf-taps-transports-usage-udp
draft is useful without reference to the draft-ietf-taps-transports-usage.

For these reasons, I ask that the authors submit an updated
draft-ietf-taps-transports-usage draft, taking into account the ballot
comments from Eric, Mirja, Ben, and Benoit.

I see that the draft-ietf-taps-transports-usage-udp draft has already been
updated to reflect comments received during balloting. I'll send the
Approved e-mails for both drafts as a set.

Thanks to everyone who provided input.

Spencer, as AD

On Wed, Sep 13, 2017 at 11:47 PM, Spencer Dawkins at IETF <
spencerdawkins.i...@gmail.com> wrote:

> Dear TAPS working group,
>
> Multiple ADs have asked why these two drafts aren't a single draft, in
> their ballots. Those are non-blocking comments, but I'd like to explore
> that, before making a decision about what should happen, and when.
>
> It occurs to me that these ADs are reading both drafts pretty much
> back-to-back in preparation for balloting during IESG Evaluation.
>
> If people reading the two drafts back-to-back find the split to be a
> distraction, I'd like to understand the views of the working group as to
> how often you expect people to read both drafts, in order to do TAPS.
>
> I could imagine that people working on complete TAPS APIs might need to
> read both drafts.
>
> What about other folks you expect to read these documents? Do you expect
> that some communities only need to read one of them?
>
> Thanks in advance for any thoughts you can share.
>
> Spencer, as responsible AD for TAPS
>
___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] One RFC, or two, for draft-ietf-taps-transports-usage and draft-ietf-taps-transports-usage-udp

[Spencer Dawkins at IETF]

Hi, Tommy

On Wed, Sep 20, 2017 at 9:31 PM, Tommy Pauly <tpa...@apple.com> wrote:

> Hi Spencer,
>
> As an API implementer, I would say this:
>
> - I did need to reference the content of both documents (or the equivalent
> information that is included in the documents, before they were complete)
> in our implementation
> - However, implementing the API details for unconnected datagram-based
> protocols and connected stream-based is very different, even if they reside
> behind a common interface. To that end, both documents are necessary, but
> can be looked at separately while implementing an API for the protocols. I
> could imagine splitting up work between implementers to each focus on one
> of the documents, without needing to reference the other excessively.
>

This is the other half of the input I needed. Thanks for that.

My theory was that most readers would not be reading both documents
back-to-back, but that's the way ADs would review the documents during IESG
Evaluation (they were even on the same telechat). So it's more disorienting
for us, than for pretty much anyone else :-)

Spencer


>
> Thanks,
> Tommy
>
>
> On Sep 18, 2017, at 9:05 AM, Spencer Dawkins at IETF <
> spencerdawkins.i...@gmail.com> wrote:
>
> Dear TAPSters,
>
> On Thu, Sep 14, 2017 at 11:02 AM, Gorry Fairhurst <go...@erg.abdn.ac.uk>
> wrote:
>
>> On 14/09/2017, 15:55, Spencer Dawkins at IETF wrote:
>>
>>> And, following up during the actual telechat ...
>>>
>>> On Wed, Sep 13, 2017 at 11:47 PM, Spencer Dawkins at IETF <
>>> spencerdawkins.i...@gmail.com <mailto:spencerdawkins.i...@gmail.com>>
>>> wrote:
>>>
>>> Dear TAPS working group,
>>>
>>> Multiple ADs have asked why these two drafts aren't a single
>>> draft, in their ballots. Those are non-blocking comments, but I'd
>>> like to explore that, before making a decision about what should
>>> happen, and when.
>>>
>>> It occurs to me that these ADs are reading both drafts pretty much
>>> back-to-back in preparation for balloting during IESG Evaluation.
>>>
>>> If people reading the two drafts back-to-back find the split to be
>>> a distraction, I'd like to understand the views of the working
>>> group as to how often you expect people to read both drafts, in
>>> order to do TAPS.
>>>
>>> I could imagine that people working on complete TAPS APIs might
>>> need to read both drafts.
>>>
>>> What about other folks you expect to read these documents? Do you
>>> expect that some communities only need to read one of them?
>>>
>>> Thanks in advance for any thoughts you can share.
>>>
>>> Spencer, as responsible AD for TAPS
>>>
>>>
>>> Both documents were approved on the telechat today, pending comment
>>> resolution of comments received during IESG Evaluation.
>>>
>>> So, my request to the working group to consider whether the suggestion
>>> to combine these documents makes life easier for the readers you expect
>>> will need to read one, the other, or both documents REALLY IS an honest
>>> question, and not the IESG requiring fabulously late major editorial
>>> changes without an active Discuss, because That Would Be Wrong.
>>>
>>> Either answer works. We'll Do The Right Thing.
>>>
>>> "Thanks in advance for your thoughts" :-)
>>>
>>> Spencer, as responsible AD, who the IESG said they trusted to "Do The
>>> Right Thing"
>>>
>>>
>>> ___
>>> Taps mailing list
>>> Taps@ietf.org
>>> https://www.ietf.org/mailman/listinfo/taps
>>>
>>
>> There was a proposal from IESG to consider whether we should merge the
>> two usage documents. So after giving this some more thought, here is my 2c
>> about why I think we should keep the two documents:
>>
>> First, I accept it may be easier for someone reviewing the history of
>> TAPS and the rationale for design decisions to read just a single document
>> - putting all the material in one place is always easier. However, if
>> published in consecutive RFCs, I'm not convinced the material would be
>> really hard for a reader to find.
>>
>> I suggested there were two reasons behind separating this out when we did
>> the work. First, the old and incomplete documentation for UDP needed a
>> slightly different approach to finding the relevent RFCs. 

Re: [Taps] One RFC, or two, for draft-ietf-taps-transports-usage and draft-ietf-taps-transports-usage-udp

[Spencer Dawkins at IETF]

Dear TAPSters,

On Thu, Sep 14, 2017 at 11:02 AM, Gorry Fairhurst <go...@erg.abdn.ac.uk>
wrote:

> On 14/09/2017, 15:55, Spencer Dawkins at IETF wrote:
>
>> And, following up during the actual telechat ...
>>
>> On Wed, Sep 13, 2017 at 11:47 PM, Spencer Dawkins at IETF <
>> spencerdawkins.i...@gmail.com <mailto:spencerdawkins.i...@gmail.com>>
>> wrote:
>>
>> Dear TAPS working group,
>>
>> Multiple ADs have asked why these two drafts aren't a single
>> draft, in their ballots. Those are non-blocking comments, but I'd
>> like to explore that, before making a decision about what should
>> happen, and when.
>>
>> It occurs to me that these ADs are reading both drafts pretty much
>> back-to-back in preparation for balloting during IESG Evaluation.
>>
>> If people reading the two drafts back-to-back find the split to be
>> a distraction, I'd like to understand the views of the working
>> group as to how often you expect people to read both drafts, in
>> order to do TAPS.
>>
>> I could imagine that people working on complete TAPS APIs might
>> need to read both drafts.
>>
>> What about other folks you expect to read these documents? Do you
>> expect that some communities only need to read one of them?
>>
>> Thanks in advance for any thoughts you can share.
>>
>> Spencer, as responsible AD for TAPS
>>
>>
>> Both documents were approved on the telechat today, pending comment
>> resolution of comments received during IESG Evaluation.
>>
>> So, my request to the working group to consider whether the suggestion to
>> combine these documents makes life easier for the readers you expect will
>> need to read one, the other, or both documents REALLY IS an honest
>> question, and not the IESG requiring fabulously late major editorial
>> changes without an active Discuss, because That Would Be Wrong.
>>
>> Either answer works. We'll Do The Right Thing.
>>
>> "Thanks in advance for your thoughts" :-)
>>
>> Spencer, as responsible AD, who the IESG said they trusted to "Do The
>> Right Thing"
>>
>>
>> ___
>> Taps mailing list
>> Taps@ietf.org
>> https://www.ietf.org/mailman/listinfo/taps
>>
>
> There was a proposal from IESG to consider whether we should merge the two
> usage documents. So after giving this some more thought, here is my 2c
> about why I think we should keep the two documents:
>
> First, I accept it may be easier for someone reviewing the history of TAPS
> and the rationale for design decisions to read just a single document -
> putting all the material in one place is always easier. However, if
> published in consecutive RFCs, I'm not convinced the material would be
> really hard for a reader to find.
>
> I suggested there were two reasons behind separating this out when we did
> the work. First, the old and incomplete documentation for UDP needed a
> slightly different approach to finding the relevent RFCs. Second, the
> community of interest in using UDP at the IETF is typically to be found
> outside the TSV area, partly because of the wide variety of uses. A second
> document made this easier for these people to read. That's still the case
> for the material that was retained in the UDP usage document.
>
> It would be my hope that the UDP document could form a long-needed part of
> the documentation for UDP. I expect this would continue to be a useful
> resource for anyone who wishes to build datagram support into a new stack,
> or just wants to program to this API, and avoids people needing to wade
> through 50-60 pages to find a section on a UDP API. I'd also hope (??!!)
> this document could be maintained in future as the API continues to develop.
>
> Gorry
>

Gorry's e-mail captured pretty much everything I need to know. I have one
more question, because I know that people have implemented TAPSish APIs and
demonstrated them.

If you worked on one of those APIs, did you have to read both documents?

Thanks in advance, and asking for (14) friends ...

Spencer, as responsible AD
___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

[Taps] One RFC, or two, for draft-ietf-taps-transports-usage and draft-ietf-taps-transports-usage-udp

[Spencer Dawkins at IETF]

Dear TAPS working group,

Multiple ADs have asked why these two drafts aren't a single draft, in
their ballots. Those are non-blocking comments, but I'd like to explore
that, before making a decision about what should happen, and when.

It occurs to me that these ADs are reading both drafts pretty much
back-to-back in preparation for balloting during IESG Evaluation.

If people reading the two drafts back-to-back find the split to be a
distraction, I'd like to understand the views of the working group as to
how often you expect people to read both drafts, in order to do TAPS.

I could imagine that people working on complete TAPS APIs might need to
read both drafts.

What about other folks you expect to read these documents? Do you expect
that some communities only need to read one of them?

Thanks in advance for any thoughts you can share.

Spencer, as responsible AD for TAPS
___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] Eric Rescorla's No Record on draft-ietf-taps-transports-usage-08: (with COMMENT)

[Spencer Dawkins at IETF]

FWIW,

On Mon, Sep 11, 2017 at 9:53 AM, Mirja Kuehlewind (IETF) <
i...@kuehlewind.net> wrote:

> Hi Micheal,
>
> I also just caught that, assuming is was an copy-and-past left over; I
> think the best options are either:
>
> ***
> [RFC7413] states that TCP implementations "MUST NOT use TFO by default,
> but only use TFO if requested explicitly by the application on a
> per-service-port basis" [RFC7413].
> ***
> -> explicit citation
>
> or
>
> ***
> TCP implementations can not use TFO by default, but only use TFO if
> requested explicitly by the application on a per-service-port basis
> [RFC7413].
> ***
> -> no normative language


Either of these would work. My suggestion is that the document use the
first option, because it's perfectly accurate, and likely more accessible
for future readers, but I'm happy to support either option for this text.

Spencer
___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] Fwd: New Version Notification for draft-ietf-taps-transports-usage-udp-05.txt

[Spencer Dawkins at IETF]

Hi, Aaron,

On Thu, Aug 31, 2017 at 10:11 AM, Aaron Falk <aaron.f...@gmail.com> wrote:

> Pull the trigger!
>

Done. It's a pleasure doing business with you (and Zahed, of course).

Spencer


>
> On Wed, Aug 30, 2017 at 9:05 AM Spencer Dawkins at IETF <
> spencerdawkins.i...@gmail.com> wrote:
>
>> Gorry,
>>
>> On Wed, Aug 30, 2017 at 4:21 AM, Gorry Fairhurst <go...@erg.abdn.ac.uk>
>> wrote:
>>
>>>
>>> This new revision updates the draft to address AD review comments, and
>>> to align the source with ID's that have now been published as RFCs.
>>>
>>
>> It absolutely does. Thank you for that.
>>
>> I've seen updated drafts for both -transport and -transport-udp, and
>> think they're ready for Last Call. Any objection from shepherd/chairs to me
>> pulling the trigger?
>>
>> Thanks,
>>
>> Spencer
>>
>>
>>>
>>> Best wishes,
>>>
>>> Gorry & Tom
>>>
>>>  Original Message 
>>> Subject:New Version Notification for draft-ietf-taps-transports-
>>> usage-udp-05.txt
>>> Date:   Wed, 30 Aug 2017 02:19:23 -0700
>>> From:   internet-dra...@ietf.org
>>> To: Tom Jones <t...@erg.abdn.ac.uk>, Godred Fairhurst <
>>> go...@erg.abdn.ac.uk>, Gorry Fairhurst <go...@erg.abdn.ac.uk>
>>>
>>>
>>>
>>> A new version of I-D, draft-ietf-taps-transports-usage-udp-05.txt
>>> has been successfully submitted by Godred Fairhurst and posted to the
>>> IETF repository.
>>>
>>> Name:   draft-ietf-taps-transports-usage-udp
>>> Revision:   05
>>> Title:  Features of the User Datagram Protocol (UDP) and
>>> Lightweight UDP (UDP- Lite) Transport Protocols
>>> Document date:  2017-08-30
>>> Group:  taps
>>> Pages:  21
>>> URL:https://www.ietf.org/internet-drafts/draft-ietf-taps-
>>> transports-usage-udp-05.txt
>>> Status: https://datatracker.ietf.org/doc/draft-ietf-taps-
>>> transports-usage-udp/
>>> Htmlized:   https://tools.ietf.org/html/draft-ietf-taps-transports-
>>> usage-udp-05
>>> Htmlized:   https://datatracker.ietf.org/doc/html/draft-ietf-taps-
>>> transports-usage-udp-05
>>> Diff:   https://www.ietf.org/rfcdiff?url2=draft-ietf-taps-
>>> transports-usage-udp-05
>>>
>>> Abstract:
>>>This is an informational document that describes the transport
>>>protocol interface primitives provided by the User Datagram Protocol
>>>(UDP) and the Lightweight User Datagram Protocol (UDP-Lite) transport
>>>protocols.  It identifies the datagram services exposed to
>>>applications and how an application can configure and use the
>>>features offered by the Internet datagram transport service.  RFC
>>>documents the usage of transport features provided by IETF transport
>>>protocols, describing the way UDP, UDP-Lite and other transport
>>>protocols expose their services to applications and how an
>>>application can configure and use the features that make up these
>>>services.  This document provides input to and context for that
>>>document, as well as offering a road map to documentation that may be
>>>of help to users of the UDP and UDP-Lite protocols.
>>>
>>>XXX RFC-Ed Note - please replace RFC with the published RFC
>>>number for I-D.ietf-taps-transports-usage, when these documents are
>>>both published XXX.
>>>
>>>
>>>
>>>
>>> Please note that it may take a couple of minutes from the time of
>>> submission
>>> until the htmlized version and diff are available at tools.ietf.org.
>>>
>>> The IETF Secretariat
>>>
>>> ___
>>> Taps mailing list
>>> Taps@ietf.org
>>> https://www.ietf.org/mailman/listinfo/taps
>>>
>> ___
>> Taps mailing list
>> Taps@ietf.org
>> https://www.ietf.org/mailman/listinfo/taps
>>
>
___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] Fwd: New Version Notification for draft-ietf-taps-transports-usage-udp-05.txt

[Spencer Dawkins at IETF]

Gorry,

On Wed, Aug 30, 2017 at 4:21 AM, Gorry Fairhurst 
wrote:

>
> This new revision updates the draft to address AD review comments, and to
> align the source with ID's that have now been published as RFCs.
>

It absolutely does. Thank you for that.

I've seen updated drafts for both -transport and -transport-udp, and think
they're ready for Last Call. Any objection from shepherd/chairs to me
pulling the trigger?

Thanks,

Spencer


>
> Best wishes,
>
> Gorry & Tom
>
>  Original Message 
> Subject:New Version Notification for draft-ietf-taps-transports-usa
> ge-udp-05.txt
> Date:   Wed, 30 Aug 2017 02:19:23 -0700
> From:   internet-dra...@ietf.org
> To: Tom Jones , Godred Fairhurst <
> go...@erg.abdn.ac.uk>, Gorry Fairhurst 
>
>
>
> A new version of I-D, draft-ietf-taps-transports-usage-udp-05.txt
> has been successfully submitted by Godred Fairhurst and posted to the
> IETF repository.
>
> Name:   draft-ietf-taps-transports-usage-udp
> Revision:   05
> Title:  Features of the User Datagram Protocol (UDP) and
> Lightweight UDP (UDP- Lite) Transport Protocols
> Document date:  2017-08-30
> Group:  taps
> Pages:  21
> URL:https://www.ietf.org/internet-
> drafts/draft-ietf-taps-transports-usage-udp-05.txt
> Status: https://datatracker.ietf.org/
> doc/draft-ietf-taps-transports-usage-udp/
> Htmlized:   https://tools.ietf.org/html/d
> raft-ietf-taps-transports-usage-udp-05
> Htmlized:   https://datatracker.ietf.org/
> doc/html/draft-ietf-taps-transports-usage-udp-05
> Diff:   https://www.ietf.org/rfcdiff?
> url2=draft-ietf-taps-transports-usage-udp-05
>
> Abstract:
>This is an informational document that describes the transport
>protocol interface primitives provided by the User Datagram Protocol
>(UDP) and the Lightweight User Datagram Protocol (UDP-Lite) transport
>protocols.  It identifies the datagram services exposed to
>applications and how an application can configure and use the
>features offered by the Internet datagram transport service.  RFC
>documents the usage of transport features provided by IETF transport
>protocols, describing the way UDP, UDP-Lite and other transport
>protocols expose their services to applications and how an
>application can configure and use the features that make up these
>services.  This document provides input to and context for that
>document, as well as offering a road map to documentation that may be
>of help to users of the UDP and UDP-Lite protocols.
>
>XXX RFC-Ed Note - please replace RFC with the published RFC
>number for I-D.ietf-taps-transports-usage, when these documents are
>both published XXX.
>
>
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
> ___
> Taps mailing list
> Taps@ietf.org
> https://www.ietf.org/mailman/listinfo/taps
>
___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] AD review for draft-ietf-taps-transports-usage-06

[Spencer Dawkins at IETF]

Hi, Michael,

On Fri, Aug 25, 2017 at 12:45 PM, Michael Welzl <mich...@ifi.uio.no> wrote:

> Hi!
>
> Thanks a lot - I addressed them all. Details below, in line;
>

That all looks fine to me. I'll be putting this and the UDP draft out for
Last Call together, if that works for the chairs.

Spencer


> cheers,
> Michael
>
>
> On Aug 24, 2017, at 10:18 PM, Spencer Dawkins at IETF <
> spencerdawkins.i...@gmail.com> wrote:
>
> These are all editorial.
>
> Thanks,
>
> Spencer
>
> A nit - in this text,
>
>Transport Protocol:  an implementation that provides one or more
>   different transport services using a specific framing and header
>   format on the wire.
>
> one path through the "or" statement says "provides one different header",
> which reads oddly. Perhaps s/different//?
>
>
> done.  Note that this definition is already published in RFC 8095, but I
> think it’s a minor issue - just easier to read with your fix, and surely
> not a semantic difference, so I did as you suggest.
>
>
> This text
>
>   The TAPS working group intends to describe an (abstract) interface
>for applications to make use of Transport Services, such that
>applications are no longer directly tied to a specific protocol.
>
> Is pointing to the TAPS working group, which will conclude someday. It’s
> probably better to point to “this specification”, and it’s probably good to
> think of the text as appearing in an RFC, so “intends to describe” is
> probably better as “describes” (at Last Call time, intentions don’t matter).
>
>
> Done  (replacements as you proposed)
>
>
> This text
>
>Transport protocols
>provide communication between processes that operate on network
>endpoints, which means that they allow for multiplexing of
>communication between the same IP addresses, and normally this
>multiplexing is achieved using port numbers.
>
> Confused me - are any of the transport protocols you’re describing not
> using port numbers for multiplexing? If not, s/normally//
>
>
> Done
>
>
> A nit - you have an “SCPT” in Section 3.3.
>
>
> Thanks, fixed
>
>
> In this text,
>
>The following three removed limitations directly
>translate into transport features that are visible to an application
>using SCTP: 1) it allows for preservation of message delineations; 2)
>these messages, do not require to be in order or reliably transferred
>unless the application wants it; 3) multi-homing is supported.
>
> I’m not parsing the description labeled “2)”. I THINK you’re saying “it
> does not provide in-order or reliable delivery unless the application wants
> that”, but I’m not sure.
>
>
> You’re right, and I replaced my item 2) with your text proposal
>
>
> In this sentence,
>
>   Section 10 of the SCTP base protocol specification [RFC4960]
>specifies the interaction with the application (which this RFC calls
>the "Upper Layer Protocol" (ULP)).
>
> Your draft is going to be the default for “this RFC” when it’s published
> as an RFC.  Better to say “which SCTP calls”, I think.
>
>
> Done
>
>
> In this sentence,
>
>The functionality exposed to the ULP through the all these APIs is
>considered here.
>
> “The all these” is garbled.
>
>
> Fixed.
>
> Cheers,
> Michael
>
>
___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] AD Evaluation on the relationship between draft-ietf-taps-transports-usage-06 and draft-ietf-taps-transports-usage-udp-04

[Spencer Dawkins at IETF]

Hi, Michael,

On Fri, Aug 25, 2017 at 12:47 PM, Michael Welzl <mich...@ifi.uio.no> wrote:

>
> On Aug 24, 2017, at 10:24 PM, Spencer Dawkins at IETF <
> spencerdawkins.i...@gmail.com> wrote:
>
> Just to make these documents a bit more digestible by reviewers, ADs, and
> readers, who will almost certainly be reading them as a set ...
>
> I'm OK with the separation of the Pass 1 analysis of UDP(-lite) into a
> separate draft, but I wish the relationship was a little clearer. It seems
> like https://tools.ietf.org/html/draft-ietf-taps-transports-
> usage-06#section-3.4 has more text describing UDP(-lite) than it needs,
> if it's just going to say "The set of Pass 1 primitives for UDP and
> UDP-Lite is documented in [FJ16].".
>
> If this makes sense to the working group, that description of UDP could be
> integrated into https://tools.ietf.org/html/draft-ietf-taps-transports-
> usage-udp-04#section-3, which only has a one-sentence description of UDP
> itself before beginning its analysis.
>
>
> I agreed with the authors of the other document that this is the right way
> forward. This text in the -usage draft consisted of 3 paragraphs, followed
> by the sentence that you quote above (“The set of …”). I removed these
> preceding three paragraphs now.
>
>
> Is there any chance that each document could provide a pointer to the
> other document, in the Abstract and Introduction sections, and be clearer
> about the relationship there?
>
>
> While there was a pointer to the other document in the intro of the -usage
> draft already, I agree it wasn’t very clear, sorry!
> I now added, to both the intro and the abstract:
>
> "For UDP and UDP-Lite, the first step of the protocol analysis -- a
> discussion of relevant RFC text -- is documented in [FJ16].”
>
> Thanks a lot for your review!
>
> Cheers,
> Michael
>

Oh, thank you! The fast path to IESG approval is to confuse the ADs as
little as possible :-)

Spencer
___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

[Taps] AD review for draft-ietf-taps-transports-usage-06

[Spencer Dawkins at IETF]

These are all editorial.


Thanks,


Spencer


A nit - in this text,


   Transport Protocol:  an implementation that provides one or more

  different transport services using a specific framing and header

  format on the wire.


one path through the "or" statement says "provides one different header",
which reads oddly. Perhaps s/different//?


This text


  The TAPS working group intends to describe an (abstract) interface

   for applications to make use of Transport Services, such that

   applications are no longer directly tied to a specific protocol.


Is pointing to the TAPS working group, which will conclude someday. It’s
probably better to point to “this specification”, and it’s probably good to
think of the text as appearing in an RFC, so “intends to describe” is
probably better as “describes” (at Last Call time, intentions don’t matter).


This text


   Transport protocols

   provide communication between processes that operate on network

   endpoints, which means that they allow for multiplexing of

   communication between the same IP addresses, and normally this

   multiplexing is achieved using port numbers.


Confused me - are any of the transport protocols you’re describing not
using port numbers for multiplexing? If not, s/normally//


A nit - you have an “SCPT” in Section 3.3.

In this text,


   The following three removed limitations directly

   translate into transport features that are visible to an application

   using SCTP: 1) it allows for preservation of message delineations; 2)

   these messages, do not require to be in order or reliably transferred

   unless the application wants it; 3) multi-homing is supported.


I’m not parsing the description labeled “2)”. I THINK you’re saying “it
does not provide in-order or reliable delivery unless the application wants
that”, but I’m not sure.


In this sentence,


  Section 10 of the SCTP base protocol specification [RFC4960]

   specifies the interaction with the application (which this RFC calls

   the "Upper Layer Protocol" (ULP)).


Your draft is going to be the default for “this RFC” when it’s published as
an RFC.  Better to say “which SCTP calls”, I think.


In this sentence,


   The functionality exposed to the ULP through the all these APIs is

   considered here.


“The all these” is garbled.
___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

[Taps] AD review of draft-ietf-taps-transports-usage-udp-04

[Spencer Dawkins at IETF]

I'm actually pretty positive on this draft - most of what follows is
editorial.

Thanks,

Spencer

This text

  This document is intended as a contribution to the Transport Services
   (TAPS) working group to assist in analysis of the UDP and UDP-Lite
   transport interface.

Refers to the TAPS working group, which will conclude someday. It’s
probably better if you say that this document provided details for the Pass
1 analysis of UDP and UDP-Lite that is used in
draft-ietf-taps-transports-usage-06, or something like that.

In this text

   Neither UDP nor UDP-Lite provide congestion control, retransmission,
   nor do they have support to optimise fragmentation and other
   transport functions.

Is “optimizing fragmentation” the best way to describe what UDP is not
doing there? Perhaps “assist in application-level packetization that would
avoid IP fragmentation?”

I may be very confused about this next one, but in

  Messages passed to the send
  primitive that cannot be sent atomically in a datagram will not be
  sent by the network layer, generating an error.

Is this “atomically in an IP datagram”? With IP-level fragmentation
available, I’m not sure what “atomically” is telling the reader.

If we’re going to “go there”, this text

  The acceptable maximum packet size can be determined using
  Packetization-Layer-Path MTU Discovery (PLPMTUD) [RFC4821] or Path
  MTU Discovery [RFC1191] [I-D.ietf-6man-rfc1981bis].

Makes PMTUD sound like an equally good alternative. What ended up in -08 of
[I-D.ietf-6man-rfc1981bis], and in RFC 8201, and I saw that your reference
was to -06, is

  If ICMPv6 filtering prevents reception of ICMPv6 Packet Too Big
   messages, the source will not learn the actual path MTU.
   Packetization Layer Path MTU Discovery [RFC4821] does not rely upon
   network support for ICMPv6 messages and is therefore considered more
   robust than standard PMTUD.  It is not susceptible to "black holed"
   connections caused by filtering of ICMPv6 message.  See [RFC4890] for
   recommendations regarding filtering ICMPv6 messages.


I know we don’t have a great story for discovering maximum packet sizes,
but I’d like to be at least as discouraging about PMTUD as RFC 8201, and
concerns about earlier versions of the text almost prevented RFC 8201 from
being published as an Internet Standard, and I’m pretty sure being more
encouraging would gather Discusses -
https://datatracker.ietf.org/doc/rfc8201/history/ is instructive.
___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] draft-fairhurst-taps-transports-usage-udp-01

[Spencer Dawkins at IETF]

Hi, Aaron,

On Sat, Apr 2, 2016 at 3:20 PM, Aaron Falk <aaron.f...@gmail.com> wrote:

>
>
> On Sat, Apr 2, 2016 at 3:17 PM, Spencer Dawkins at IETF <
> spencerdawkins.i...@gmail.com> wrote:
>
>> Hi, Aaron and Gorry,
>>
>> On Sat, Apr 2, 2016 at 2:33 PM, Aaron Falk <aaron.f...@gmail.com> wrote:
>>
>>> Couple of minor comments on the draft
>>> <https://tools.ietf.org/html/draft-fairhurst-taps-transports-usage-udp-01>
>>> :
>>>
>>>- No mention of ECN in phase 2.  Am I missing something?
>>>- You had asked about what app-oriented IETF groups might be able to
>>>review the API.  It's a good question for 
>>> draft-ietf-taps-transports-usage
>>>as well.  Wonder if the wg has any suggestions?  Perhaps we should raise
>>>the question in APPSAWG although they don't seem to be meeting this 
>>> IETF...
>>>
>>>
>> If you can corner Mary Barnes, Cullen Jennings, or Murray Kucherawy at
>> the welcome reception, you might ask if Dispatch is the right place to ask
>> about these drafts - now that APP is part of ART, Dispatch has a broader
>> scope than just RAI, and they are meeting this time (on Monday morning, so
>> ask fast) ...
>>
>> Spencer
>>
>
>
> So, is DISPATCH the new APPSAWG?  If so, we need to add it to our conflict
> avoid list (esp since we conflict with it this week).
>
> --aaron
>

I'm not entirely clear on that, but I think it's kinda turning into the ART
Open Area Meeting (APPSAWG actually works on stuff that doesn't have its
own working group, like TSVWG). So, DISPATCH is more like TSVAREA than
TSVWG.

In related news, I just talked to Cullen, and he said Dispatch puts up
advertisements for drafts all the time. Is all you/Gorry want to do is get
a slide into the chair slide deck that says "these drafts in TSV could use
ART clue and attention", that should be fine (but putting together a slide
that says whatever you want to ask is the key action).

I hope that helps,

Spencer
___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Re: [Taps] draft-fairhurst-taps-transports-usage-udp-01

[Spencer Dawkins at IETF]

Hi, Aaron and Gorry,

On Sat, Apr 2, 2016 at 2:33 PM, Aaron Falk  wrote:

> Couple of minor comments on the draft
> 
> :
>
>- No mention of ECN in phase 2.  Am I missing something?
>- You had asked about what app-oriented IETF groups might be able to
>review the API.  It's a good question for draft-ietf-taps-transports-usage
>as well.  Wonder if the wg has any suggestions?  Perhaps we should raise
>the question in APPSAWG although they don't seem to be meeting this IETF...
>
>
If you can corner Mary Barnes, Cullen Jennings, or Murray Kucherawy at the
welcome reception, you might ask if Dispatch is the right place to ask
about these drafts - now that APP is part of ART, Dispatch has a broader
scope than just RAI, and they are meeting this time (on Monday morning, so
ask fast) ...

Spencer
___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

[Taps] So, catching back up on the charter

[Spencer Dawkins at IETF]

If I might make a couple of observations, and ask a question ...

Obs: document status:

This is actually not as nailed down as you might think. The IESG can, and
sometimes does, discuss the proper status for a document as late as IESG
Evaluation (I've been involved in one of those conversations today for a
document on this Thursday's telechat, although that doesn't happen every
telechat). It's good to start out with a goal in mind, but you actually
have some flexibility.

Obs: milestones in general:

Some folks might understand this better than I did when I became an AD, so
I apologize if I'm boring anyone, but the food chain works like this:

The charter text, and this doesn't include the milestones, is a matter for
the IESG, in consultation with the community. Rechartering goes back to the
IESG and to the community.

The milestone text is a matter for the AD, in consultation with the working
group. Additions, changes and deletions that are within scope of the agreed
charter don't go back to the IESG. We often stick document status
in milestones, and that doesn't go back to the IESG, either.

Milestone dates are a matter for the chairs, in consultation with the
working group. An AD might have opinions about how fast a working group
should be moving, but we don't approve milestone date changes.

The high-order bit is, you really want work described in the charter text
unless you want to go back to the IESG, but a working group can
add/change/remove milestones for work that's described in the charter at
whatever time seems appropriate. So, please look most carefully at the
non-milestone charter text, because that's what's most difficult to change.

I would expect TAPS to add milestones when TAPS is ready to adopt an
individual draft (the draft name is one of the milestone attributes), and
work on it as a group. After that, the draft needs to reflect the editor's
understanding of what the working group thinks.

Q: So, my question:

How important is it for the working group to begin work on the third
deliverable immediately?

Thanks,

Spencer, as AD
___
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps