So on the Charter, as at:
https://datatracker.ietf.org/doc/charter-ietf-taps/
This is a much longer rant than I wanted, so if you read no more, the
main point is in the next para:
I think the M18 milestone (also called No 3) is well-intentioned,
especially if targeted as an EXP RFC. To me this never was an interface
spec, although it needs some form of communication with the App, it is
the way you find out which protocol to use on an actual path from a set
of protocols that may offer a service.
Spencer asked the question:
"How important is it for the working group to begin work on the third
deliverable immediately?"
My take, is it is very important that the WG has item 3 (an EXP for
certain, or even a PS!) as their "goal" and starts attracting discussion
and individual IDs that can take this topic forward - I for one, would
want to start thinking about which potential ways could solve the
problems, and to discuss these via the mailing list to try and build an
ID. Yes, there are multiple possibilities, and many pitfalls, but I'd be
fine to try writing one draft, and expect others to collaborate or find
other ideas (probably better - who knows?). As the WG proceeds, it will
find out if methods are deployable or deplorable - just as mptcp did for
their protocol, and we could then decide to move forward or even give-up.
Adopting a specific draft early is maybe not so critical at the start,
(and that would be really OK), but I think there needs to be a clear aim
towards finding the mechanisms and identify issues. This is not an easy
topic to bring together, it's worth the work though!!!
What options are there?
--- I think with a Charter that allows this, and possibly milestone for
this topic, the group has a clear goal. The status needs to be EXP,
well a good AD will generally tell the WG if they don't achieve this
level of quality. Starting as non-EXP and, upgrading the status later
to EXP or expecting to publish as non-WG but widely used RFC seems to me
to be the wrong initial starting point. I personally do not see a
conflict with this activity and any other current IETF activity, so why
the hesitation here?
--- If people really see Charter text that said there can be no such
milestone, somehow this forces the group to prepare a "problem
statement", which although isn't bad, also isn't really the end-goal If
the protocol work needs a recharter, it punts and delays the decision to
sometime later - at the first two TAPS meetings there were many
researchers and people from industry around, all saying things, in
general I observe at the IETF: the longer we punt, the less wide the
contributions.
So, I suggest:
* Ensure the Charter permits the 3rd milestone (and if necessary try to
set some bounds to what it will say).
Setting a restriction that requires the IESG to approve a new Charter to
decide whether an EXP transport protocol can be published seems
soooooooo like a "wait-and-we-decide-later" tactic to me. That's bad for
the WG. And then, if our IETF process were to fail to sort this out
promptly, as-it-seems-it-may, I expect requests from the WG individual
draft authors to still progress this discussion and design using IDs and
the WG mailing lists and meetings (albeit with less visibility tha
having a WG milestone) and then to request to publish something. If the
charter forbids this, then a request to publish as independent
submission to become some sort of less-reviewed de-facto "experimental
RFC"... I don't see why we would do this.
Hope this is helpful, and people will be joining in this exciting and
hopefully useful venture!
Gorry
NiTS remaining:
/Specify the subset of those Transport Services, as identified in
item 1, /
- I'd remove this and other very specific references to the milestone
numbers, when published, the AD may adjust milestones, and this doesn't
to me seem to have to redo the charter text.
/The Working Group deliverables will help an application/
programmers
- mixer singular and plural /programmers/programmer/
Bullet:
/Quality-of-Service (QoS) and tunneling mechanisms and services/
I think should be
/definition of new Quality-of-Service (QoS) mechanisms/
- to align with other bullets.
_______________________________________________
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps
