Re: [Tsv-art] Nomcom candidates (including Transport AD)

[Spencer Dawkins at IETF]

On Wed, Jun 2, 2021 at 3:21 AM Zaheduzzaman Sarker  wrote:

> Thanks Martin for putting out your well compiled thoughts. It is even
> better that you are willing to standing for another term.
>
>
>
> Even though my experience is short I could not agree more with your
> message here. (Let’s see what I say after me term ends ). Sure, I can
> also share my experience and discuss with any interested person.
>

"Term". He said, "term".

Who's going to tell him? :D

Best,

Spencer

Re: [Tsv-art] Calling AD candidates

[Spencer Dawkins at IETF]

Hi, Martin,

Top-posting - I'd add two more items under "what's great about being an
AD", which would be

   - watching new working groups become productive and new chairs learn
   their roles successfully, and
   - I was told that past ADs have a lifetime invitation to the transport
   chairs/TSVART dinners - again, when we meet again :-)

But this is a great summary!

Best,

Spencer

On Thu, Aug 6, 2020 at 6:35 PM Martin Duke  wrote:

> As so often happens, Transport AD candidates are thin on the ground. I'll
> share some thoughts as someone who stepped into the role role with very
> little idea of IETF beyond the 2 or 3 working groups I was active in at the
> time.
>
> *TL;DR* being an AD is a professionally enriching and socially
> rewarding experience. It takes time but it usually doesn't hurt to ask your
> employer for that time. The procedural stuff is not hard at all. The most
> challenging thing is getting up to speed on unfamiliar subjects, which also
> probably has the biggest benefits.
>
> Others can judge if I've been successful, but at no point have I been
> overwhelmed or left without great advice and exceptional documentation on
> how to do things.
>
> Nominations happen here:
> https://datatracker.ietf.org/nomcom/2020/nominate/.
>
> *What's great about being an AD*:
> - Having an important say in shaping the area and the IETF as a whole,
> particularly by chartering groups and participating in IESG initiatives
> that interest you
> - Everyone has their examples of nonsense at the IETF but ADs are in a
> position to do something about it.
> - Working with some great WG chairs, and building our TSV community
> - Learning much more about what's going on in other areas, to become a
> more complete internet professional
> - There's a lot of freedom to focus on what you find most interesting
> - Meeting people from every corner of IETF - unfortunately I haven't
> gotten the full in-person version of this, but it remains true.
>
> *Time commitment*: This the biggest reason not to pursue the position.
> Like many things it depends on what you want to put into it, but it's not
> like a chair position that can be done in the margins of your day job.. I
> would definitely arrange with your employer to lose no less than 1/4, and
> probably half, of your current responsibilities.
>
> This is a huge mental obstacle for many people, but if your boss can be
> persuaded of the advantages for your organization, and that it will help
> you be a satisfied employee, you may be able to jettison the less appealing
> bits of your current work. That's how it turned out for me.
>
> *What's the work*? There's an official job description here:
> https://trac.ietf.org/trac/iesg/wiki/TransportExpertise
>
>  In roughly declining order of time commitment:
>
> 1. IESG review: you should review a healthy majority of documents that
> pass IETF Last Call. This can take a long time if you provide detailed
> reviews of everything, or not as much if you focus on the transport aspects
> of documents that have transport implications and lean on the area review
> team to do their usual good job.
>
> 2. Weekly meetings: No more than 3 hours unless you volunteer for more.
> Obviously, ramps up around IETF week.
>
> 3. AD Review: you really should take a close look at the document output
> of your WGLCs.
>
> 4. WG management: Chairs don't need to be micromanaged, but they'll
> sometimes ask your opinion.. You're also deeply involved in chartering,
> finding chairs, and BOFs in your area but these are not terribly frequent
> events.
>
> 5. IESG projects. This is purely optional, but you can take on a special
> project. For example, I was deeply involved in figuring out the remote
> meeting plan, and, well, you saw the result.
>
> 6. Miscellaneous: you will get random email about RFC errata, etc, and
> have to deal with it. It's not a huge time sink.
>
> I hope some of you will overcome the concern that you're "not ready" for
> this position, and/or the hesitation to ask your employer to explore an
> interesting opportunity.
>
> I happy to discuss further with interested people, either via email or
> using the chat or meeting technology of your choice.
>
> Thanks
> Martin
> ___
> Tsv-art mailing list
> tsv-...@ietf.org
> https://www.ietf.org/mailman/listinfo/tsv-art
>

E-mail comment on a comment Colin Perkins made about Network Tokens in today's TSVAREA session

[Spencer Dawkins at IETF]

The draft minutes from  https://codimd.ietf.org/notes-ietf-108-tsvarea say

"Colin: There’s a long history of this, to Brian and Jana’s points. One
outcome of SPUD and PLUS was that we believed we didn’t know how to solve
this well, and we started the Path Aware Networking Research Group. We
looked at what didn’t work before. Please look at that, and engage there."


At the risk of immodesty, I'd suggest starting with
https://datatracker.ietf.org/doc/draft-irtf-panrg-what-not-to-do/, which
talks specifically about obstacles to deployment for "Path-Awareness",
including end systems not trusting networks and networks not trusting end
systems.

(I'm the editor, but it IS a research group draft)

Best,

Spencer

Re: Dispatch-WG Draft On SRT (Secure Reliable Transport) FYI

[Spencer Dawkins at IETF]

Thank you, Patrick. I was wondering about this one :-)

Best,

Spencer

On Wed, Mar 18, 2020 at 4:55 PM Patrick McManus 
wrote:

> Hello tsv-area friends,
>
> As co-chair of the ART Dispatch WG I am writing to let you know about a
> draft that will be presented in that group on a 'as time allowed basis'
> during the virtual meeting next week. We believe you may have some interest
> and expertise in its content.
>
> The draft is https://datatracker.ietf.org/doc/draft-sharabayko-mops-srt/
>
> Abstract
>
>This document specifies Secure Reliable Transport (SRT) protocol.
>SRT is a user-level protocol over User Datagram Protocol and provides
>reliability and security optimized for low latency live video
>streaming, as well as generic bulk data transfer.  For this, SRT
>introduces control packet extension, improved flow control, enhanced
>congestion control and a mechanism for data encryption.
>
> After consultation with the transport and art AD's we believe this may be
> of interest to both communities. The goal of the dispatch WG is to help
> identify the next step of a draft that is not currently adopted by a WG
> (possibilities include but are not limited to a BoF, an existing WG, a new
> WG, or more refinement on mailing lists). The group makes recommendations
> but cannot actually require any of those actions. Come be part of our group!
>
> Information on the Dispatch WG mailing list is here:
> https://www.ietf.org/mailman/listinfo/dispatch
>
> The virtual  meeting is Monday at 22:10 UTC aka
> https://www.timeanddate.com/worldclock/fixedtime.html?msg=dispatch+meeting=20200323T2210=1440=2
>
> This work at least intersects with the interests of several areas and
> groups, so please tolerate multiple copies of this invitation.
>
> -Patrick
>

Re: Minutes are online now!

[Spencer Dawkins at IETF]

Hi, Mirja,

On Thu, Dec 12, 2019 at 4:07 AM Mirja Kuehlewind 
wrote:

> Hi all,
>
> The minutes are online now:
>
> https://datatracker.ietf.org/meeting/106/materials/minutes-106-tsvarea-00
>
> If you were at the session, please check and let us know if there are any
> edits needed!
>

I'm always hard to summarize :-)

For

  Spencer Dawkins: I wish I had explicitly asked for keepalives when I was
AD. People don't want to let us down by quitting.

I'd suggest

  Spencer Dawkins: I wish I had explicitly asked for keepalives when I was
AD, to periodically make sure chairs are willing to continue to serve.
People don't want to let us down by quitting.

For

  Spencer: We had ops/mgmt there because there was nowhere else to have it.
Now there's a WG for it, and they've already started arguing about
measuring QUIC.

I'd suggest

  Spencer: We had QUIC ops/mgmt considerations in the QUIC working group
charter because there was nowhere else to put it. Now that Media Operations
(MOPS) has been chartered, they're already talking about measuring
troubleshooting QUIC from an operator perspective in their first working
group session. Maybe this document should go into MOPS?

(And I understood Mark Nottingham to say my suggestion was "interesting",
but I haven't gone back to Meetecho to verify that)

Best,

Spencer

Draft Minutes for TSVAREA uploaded

[Spencer Dawkins at IETF]

My apologies for not getting these posted earlier, but this was a GREAT
session.

https://datatracker.ietf.org/meeting/103/materials/minutes-103-tsvarea-00

Please let us know what I got wrong.

Thanks!

Spencer, the outgoing TSV AD

Re: Final(?) Agenda for TSVAREA at IETF 103.

[Spencer Dawkins at IETF]

OK, I lied. This meeting is MONDAY - all other information including the
time of day was correct.

My apologies for being confused. Updating the online agenda now ...

Spencer

On Sat, Nov 3, 2018 at 5:32 PM Spencer Dawkins at IETF <
spencerdawkins.i...@gmail.com> wrote:

> TSVAREA Agenda - IETF 103
> Tuesday, November 5, 2018
> 11:20-12:20
> Room: Chitlada 2
> Co-conspirators: Spencer Dawkins and Mirja Kühlewind
>
> 11:20 Administrivia - ADs - 10 minutes
> Note Well
> Agenda Bash
> State of the Area
> 11:30 Evolution of Transport
> Topic: Feature Requests for Advanced UDP Proxying
> Presenter: Katharine Daly - 10 minutes + 5 minutes for Q
> Topic: QUIC tunneling addendums
> Remote Presenter: Lucas Pardue - 5 minutes + 5 minutes for Q
> Topic: Proxying Encrypted Transports
> Presenter: Thomas Fossati - 5 minutes + 5 minutes for Q
> General Q on this topic - 5 minutes
> Open Mike - ADs - balance of time
> Please tell us all what we need to know
> Please tell us all what we need to do differently in the future
> (It is not too soon to start blaming the outgoing AD!)
>
> The most up-to-date agenda is always at
> https://datatracker.ietf.org/doc/agenda-103-tsvarea/.
>
> Welcome to Bangkok, whether in person, on Meetecho, or via e-mail.
>
> Spencer and Mirja
>

TSV AD Office Hours at IETF 103

[Spencer Dawkins at IETF]

Dear All,

Mirja and I will be available for office hour visits about TSV-related
topics on Thursday at 13:50-15:50 in room Meeting 5 on the 7th floor.

That's during a meeting slot, so if you're unable to come then, please let
us know, and we can arrange another time that works for you. We'll be in
the hallways as usual.

We are happy to talk to anyone about anything that we can help with, but
appreciate when people let us know they plan to come, and what they plan to
talk about, so that we can be well prepared for discussion.

Best wishes, and travel safely.

Spencer

TSVAREA Minutes - IETF 102 (Draft)

[Spencer Dawkins at IETF]

Dear All,

I've (finally!) uploaded draft minutes for our meeting at IETF 102.

They're at
https://datatracker.ietf.org/meeting/102/materials/minutes-102-tsvarea-00.

There were some questions, especially during Ian Swett's presentation,
where the person asking the question didn't identify themselves. If you
have corrections, especially providing names, please let me/Mirja know.

Thanks!

Spencer

Re: statement regarding keepalives

[Spencer Dawkins at IETF]

Hi, Mikael,

On Fri, Jul 20, 2018 at 6:48 AM Mikael Abrahamsson  wrote:

>
> Hi,
>
> While I agree with the sentiment here, I have personally been in positions
> where application programmers were unable to (in a timely manner) modify
> whatever was running, to implement a keepalive protocol. In that case,
> turning on TCP keepalives was a very easy thing to do that immediately
> would yield operational benefits.
>
> So I'd like to see in the text that we recommend to do it as "high up" in
> the stack as possible, but still don't put off people turning on TCP
> keepalives "because the IETF doesn't recommend that", and thus they do
> nothing at all and the problem just persists.
>
> Also, should we talk about recommendations for what these timers should
> be? In my experience, it's typically in tens of seconds up to 5-10 minutes
> that makes sense for Internet use. Shorter than that might interrupt the
> connection prematurely, longer than that causes things to take too long to
> detect a problem. Of course it's up to the application/environment to
> choose the best value for each use-case, but some text on this might be
> worthwhile to have there?
>

This is exactly the kind of feedback I'd like to reflect in whatever
guidance we give, in whatever form. Thank you for that.

Other thoughts?

Spencer

(And, yes, there's a tension between "why would I tear down a perfectly
good idle connection because it might not work the next time I try to use
it? for real" and "OMG, I need to send a message to the other side, but my
idle connection is now timing out, so I have to set up a new connection,
secure it, and do whatever else I need to do with the other side before I
can send a message!!!". That's a good thing to include in our advice)

Re: statement regarding keepalives

[Spencer Dawkins at IETF]

Dear All,

Top-posting ... thank yous to David and Wes for your feedback.

I'd like to report back to the SEC ADs about our discussion tomorrow when
the IESG and IAB meet (immediately after the final meeting session).

If you have any other comments, they will be appreciated at any point in
time, but would be most useful if they arrive before then.

Thanks,

Spencer

On Fri, Jul 13, 2018 at 9:38 AM Black, David  wrote:

> +1 on Wes's comments, especially that "layers of functionality" is better
> than "aliveness" ;-).
>
> Thanks, --David
>
> > -Original Message-
> > From: tsv-area [mailto:tsv-area-boun...@ietf.org] On Behalf Of Wesley
> > Eddy
> > Sent: Thursday, July 12, 2018 9:06 PM
> > To: tsv-area@ietf.org
> > Subject: Re: statement regarding keepalives
> >
> > Hi Kent, I agree with the spirit of the statement / guidance you've
> drafted.
> >
> > You might want to tweak some of the wording, e.g. "test more aliveness"
> > could be "test more layers of functionality" or something like that, but
> > this is just a nit.
> >
> > I think the footnote recommending short-lived connections should be more
> > clear about why that's the recommendation.  What is the risk/danger/etc
> > of longer-lived connections.  That recommendation seems a bit naked as
> > currently described, and actually should probably be more than just a
> > footnote.
> >
> >
> >
> > On 7/12/2018 8:37 PM, Kent Watsen wrote:
> > > Dear TSVAREA,
> > >
> > > The folks working with the BBF asked the NETMOD WG to consider
> > modifying draft-ietf-netconf-netconf-client-server to support TCP
> keepalives
> > [1].  However, it is unclear what IETF's position is on the use of
> keepalives,
> > especially with regards to keepalives provided in protocol stacks (e.g.,
> >  over HTTP over TLS over TCP).
> > >
> > > After some discussion with Transport ADs (Spencer and Mijra) and the
> TLS
> > ADs (Eric and Ben), the following draft statement has been crafted.
> Spencer
> > and Mijra have requested TSVAREA critique it before, perhaps, developing
> a
> > consensus document around it in TSVWG.
> > >
> > > It would be greatly appreciated if folks here could review and provide
> > comments on the draft statement below.  The scope of the statement can
> > be increased or reduced as deemed appropriate.
> > >
> > > [1]
> > https://mailarchive.ietf.org/arch/msg/netconf/MOzcZKp2rSxPVMTGdmmrVI
> > nwx2M
> > >
> > > Thanks,
> > > Kent (and Mahesh) // NETCONF chairs
> > >
> > >
> > > = STATEMENT =
> > >
> > > When the initiator of a networking session needs to maintain a
> persistent
> > connection [1], it is necessary for it to periodically test the
> aliveness of the
> > remote peer.  In such cases, it is RECOMMENDED that the aliveness check
> > happens at the highest protocol layer possible that is most meaningful
> to the
> > application, to maximize the depth of the aliveness check.
> > >
> > > E.g., for an HTTPS connection to a simple webserver, HTTP-level
> keepalives
> > would test more aliveness than TLS-level keepalives.  However, for a
> > webserver that is accessed via a load-balancer that terminates TLS
> > connections, TLS-level aliveness checks may be the most meaningful check
> > that could be performed.
> > >
> > > In order to ensure aliveness checks can always occur at the highest
> protocol
> > layer, it is RECOMMENDED that protocol designers always include an
> > aliveness check mechanism in the protocol and, for client/server
> protocols,
> > that the aliveness check can be initiated from either peer, as sometimes
> the
> > "server" is the initiator of the underlying networking connection (e.g.,
> RFC
> > 8071).
> > >
> > > Some protocol stacks have a secure transport protocol layer (e.g.,
> TLS, SSH,
> > DTLS) that sits on top of a cleartext protocol layer (e.g., TCP, UDP).
> In such
> > cases, it is RECOMMENDED that the aliveness check occurs within
> protection
> > envelope afforded by the secure transport protocol layer.  In such
> cases, the
> > aliveness checks SHOULD NOT occur via the cleartext protocol layer, as an
> > adversary can block aliveness check messages in either direction and send
> > fake aliveness check messages in either direction.
> > >
> > > [1] While reasons may vary for why the initiator of a networking
> session
> > feels compelled to maintain a persistent connection.  If the session is
> > primarily quiet, and the use case can cope with the additional latency of
> > starting a new connection, it is RECOMMENDED to use short-lived
> > connections, instead of maintaining a long-lived persistent connection
> using
> > aliveness checks.
> > >
> > >
>
>

IETF 102 TSV AD office hours

[Spencer Dawkins at IETF]

Dear All,

We'll have our usual office hours in the McGill room during the first
Tuesday Afternoon session (1330 to 1530).

Please feel free to drop by, but if you can tell us you're coming and what
you'd like to talk about, we'd be ever so much more prepared!

Spencer, for Spencer and Mirja

Re: [www.ietf.org/rt #221339] TSV AD Office Hours for IETF 102

[Spencer Dawkins at IETF]

Hi, Liz,

On Mon, Jun 18, 2018 at 5:33 PM Liz Flynn via RT  wrote:

> Hi Spencer,
>
> Your office hours are now listed on the agenda. The room will be McGill.
>
> Please let us know if there's anything else!
>

You're a rock star. Thanks!

Spencer


> Thanks,
> Liz Flynn
> Secretariat
>
> On Mon Jun 18 07:19:31 2018, spencerdawkins.i...@gmail.com wrote:
>
>   Dear IESG Secretary (bcc), Mirja and I have reserved the IESG breakout
> room
>   for TSV AD Office Hours during the first Tuesday Afternoon session (1330
> to
>   1530). Could you add this to the formal agenda, and please let us know
> what
>   the actual room is?
>
>   Dear TSV Chairs and TSVAREA, Please let us know if you have any questions
>   or topics you'd like to discuss with us in a quiet room, so we'll be
>   prepared to talk. Travel safely, and we'll see (many of) you in Montreal!
>   Spencer
>
>
>

TSV AD Office Hours for IETF 102

[Spencer Dawkins at IETF]

Dear IESG Secretary (bcc),

Mirja and I have reserved the IESG breakout room for TSV AD Office Hours
during the first Tuesday Afternoon session (1330 to 1530).

Could you add this to the formal agenda, and please let us know what the
actual room is?

Dear TSV Chairs and TSVAREA,

Please let us know if you have any questions or topics you'd like to
discuss with us in a quiet room, so we'll be prepared to talk.

Travel safely, and we'll see (many of) you in Montreal!

Spencer

Fwd: [802.1 - 12663] Call for Comments on Nendica Draft Report ("The Lossless Network for Data Centers")

[Spencer Dawkins at IETF]

Dear TSVAREA,

Paul Congdon discussed the forthcoming IEEE 802.1Qcz "Congestion Isolation"
project in in TSVWG and in ICCRG last month, and even did a HotRFC slot on
this topic.

Paul has shared this recently opened 30-day call for comments on this
project, and has invited feedback from IETF participants. One need not be
an IEEE 802 participant to provide your thoughts. According to the details
below, the call for comments period ends on May 13.

I encourage those of you interested in providing feedback to please read
the report and do so.

Thank you, Paul, for soliciting feedback from the IETF.

Spencer

-- Forwarded message --
From: Roger Marks 
Date: Mon, Apr 16, 2018 at 8:05 PM
Subject: [802.1 - 12663] Call for Comments on Nendica Draft Report ("The
Lossless Network for Data Centers")
To: stds-802-...@listserv.ieee.org


Ballot due May 7: P802.1AS/D7.0
  Due May 11: P802.1CS/D1.4
For particulars see
  https://1.ieee802.org/active-ballots/
802.1 list help: https://1.ieee802.org/email-lists/
-

Dear 802.1 Participants,

See below for the 30-day Call for Comments on the Nendica Draft Report "The
Lossless Network for Data Centers". This is the first Nendica Draft Report
of the IEEE 802 “Network Enhancements for the Next Decade” Industry
Connections Activity, under 802.1.

I encourage you to participate, and to circulate this announcement as
widely as you wish, so that we can get input from a wide swath of
interested experts.

I also encourage you to consider other topics that might be worthy to
propose as Nendica Work Items.

I expect comments to be addressed at Nendica meetings on 23-24 May at the
802.1/802.3 Interim Session in Pittsburgh. Nendica also plans to meet on 7
May at the 802 Wireless Interim in Warsaw.

Cheers,

Roger Marks


*Call for Comments on Nendica Draft Report ("The Lossless Network for Data
Centers")*

   - Nendica  (the IEEE 802 “Network
   Enhancements for the Next Decade” Industry Connections Activity), within
   its Lossless Data Center Networks Work Item
   , has developed a
   Nendica Draft Report on "The Lossless Network for Data Centers". Nendica
is
   conducting a Call for Comments seeking the views of all interested
parties
   on this draft.
   - Nendica specifically solicits comments on the Nendica Draft report
   802.1-18-0007-04-ICne
    ("The
   Lossless Network for Data Centers").
   - The Call for Comments period is 2018-04-13 through
   2018-05-13 (Anywhere on Earth).
   - Participation is open to all and is encouraged. Nendica will address
   every comment but does not guarantee to accept every comment nor to
provide
   an explicit response. Feel free to notify the Nendica Chair
    of your contact information if you would like to have
   further discussions of your comment or of the topic in general; without
   such information, Nendica may be unable to reach you.
   - Submit comments using the comment submittal form
   
   .
   - Your comment may reference external documents by URL. Preferably,
   upload external documents as contributions using the Nendica document
   repository .
  - To contribute a new document, log in using an IEEE password
  .
  - You may also require external authorization. If you have
  difficulties, contact the Nendica Chair .
   - If you wish to submit a set of comments in batch form, do the
   following:
  - download and complete the batch comment spreadsheet
  
  - upload the completed spreadsheet file to the Nendica document
  repository 
  - submit a comment using the comment submittal form
  
and
  referring to the upload comment spreadsheet by document number or URL
   - For technical issues, you may contact the Work Item Editor
   , Paul Congdon.
   - You can review submitted comments
   
   .
   - Thank you for your participation and feedback.

===
Unsubscribe link: mailto:stds-802-1-l-signoff-requ...@listserv.ieee.org
IEEE. Fostering technological innovation and excellence 

Draft TSVAREA minutes posted for review

[Spencer Dawkins at IETF]

Dear Transporters,

Thanks to Magnus for taking notes for our session - I've posted minutes for
review at
https://datatracker.ietf.org/meeting/101/materials/minutes-101-tsvarea-00.

I worked with notes from Magnus and the Meetecho recording, but if I got
anything wrong, please let me know, and I'll update them before the
proceedings cutoff.

Thanks!

Spencer

Re: TSV AD Office Hours at IETF101

[Spencer Dawkins at IETF]

On Mon, Feb 26, 2018 at 10:15 AM, Mirja Kuehlewind (IETF) <
i...@kuehlewind.net> wrote:

> Hi all,
>
> we will hold the AD Office Hours for IETF101 in London on
>
> Wednesday, March 21, 15:20-16:50 (Afternoon session II).
>
> The room is not announced yet, so please check the agenda for further
> information.
>
> If you would like to discuss something with out, please come by! Or let us
> know in advance if you have something that needs further discussion!
>
> Mirja
>

The room for TSV AD office hours is in the formal agenda - it's the
Victoria Room, 1st floor east, but it's a scavenger hunt to find.

If you've already collected all the secretariat scavenger hunt stickers,
you should drop by!

Spencer

Fwd: CFP: Request for Conversation (HotRFC) lightning talks

[Spencer Dawkins at IETF]

Dear TSV Folk,

I wanted to make sure that people are aware of this opportunity to identify
potential collaborators, or to put an idea in front of a broader cross
section of the IETF community than people have had in the past, without
holding a BOF.

If you have an idea that doesn't fit in a chartered working group and
hasn't gotten as far as a BOF, please feel free to contact Aaron, as below.

Thanks!

Spencer

-- Forwarded message --
From: Aaron Falk 
Date: Thu, Mar 1, 2018 at 10:41 AM
Subject: CFP: Request for Conversation (HotRFC) lightning talks
To: IRTF Discuss , IETF WG Chairs ,
IETF Discussion , 101attend...@ietf.org


Do you have an idea, problem space, or proposal that IETFers should hear
about?

Do you want to propose IETF work but aren’t sure if your idea is ready or
who will be interested?

Get a slot at the Request for Conversation (HotRFC) lightning talk session.
Presenters will get 5 minutes and a slide or two to make their case for
collaboration. Interested folks can continue the discussion afterwards and
over the week. Goals include encouraging brainstorming conversations,
helping new work ideas to find co-collaborators, raising awareness of
relevant work going on elsewhere, and promote BarBofs. Slots can be
requested here  with a short
paragraph or slide.

Date is TBD but we are aiming for early Sunday evening.

Draft TSVAREA Minutes now available

[Spencer Dawkins at IETF]

Yes, they're late, but we didn't forget completely.

Thanks, David Black, for your help with this!

Minutes are at
https://datatracker.ietf.org/meeting/100/materials/minutes-100-tsvarea/.

Please let us know if there are any corrections or clarifications we should
make.

Thanks,

Spencer and Mirja

TSVAREA Agenda for IETF 100 posted, TSV AD Office Hours scheduled

[Spencer Dawkins at IETF]

Dear TSVers,

Mirja and I have posted the TSVAREA agenda at
https://datatracker.ietf.org/meeting/100/materials/agenda-100-tsvarea/. The
meeting is on Thursday afternoon at 18:10 in the Padang room. Our meeting
at IETF 100 will be short (one hour), and will focus on implementation
topics, and on coordinating specification work with interop testing. We
will have some open mike time as well.

Mirja and I have also scheduled TSV AD office hours for Wednesday at
15:20-16:50 in the Clark room. If you have questions, or want to provide
feedback, or have work that's gotten stuck, and pretty much anything else
about TSV topics, you're invited - and if you let us know that you're
coming, and what you need to talk about, we'll even be prepared.

Thanks, and travel safely, for those of you who are traveling.

Spencer, as AD

IETF 100 TSV AD Office Hours

[Spencer Dawkins at IETF]

Dear Stephanie,

Mirja and I plan to have TSV AD office hours on Wednesday, November 17,
at 1520-1650, in the Clark Room.

Could you add this to the agenda?

Thanks!

Spencer

IETF 99 TSVAREA minutes - DRAFT

[Spencer Dawkins at IETF]

TSVAREA minutes are now available at
https://datatracker.ietf.org/doc/minutes-99-tsvarea/00/, thanks to David
Black, who took awesome minutes, and no thanks to Spencer, who submitted
them one day after the draft minutes cutoff date.

Hey, yesterday was my 15th anniversary, OK? :p

Please provide comments before the "Corrections to submissions cutoff
date", which is September 4, 2017.

Thanks!

Spencer

Re: Proposal for revising RFC4445 or make RFC4445bis

[Spencer Dawkins at IETF]

...

On Mon, Jul 17, 2017 at 2:54 PM, Mirja Kühlewind <
mirja.kuehlew...@tik.ee.ethz.ch> wrote:

> I believe the problem that is addressed with this proposals is actually
> assessing streaming quality from the outside/network if you don’t have
> access to do the measurement on the endpoint in the app. Not saying that we
> need or should do this work but that’s why this might be relevant to
> transport as well as apps.
>

... and thanks to you all, for the feedback :-)

Spencer


>
>
> > Am 17.07.2017 um 14:50 schrieb Ali C. Begen :
> >
> >
> >
> > On Mon, Jul 17, 2017 at 8:43 PM, Mirja Kühlewind <
> mirja.kuehlew...@tik.ee.ethz.ch> wrote:
> > This is the area list, not a wg; we are not working on any document. The
> purpose of announcing this work here is to figure if there is any
> interested in this work and if so where it should be done.
> >
> > I know this is an area list, my comment was not specific to any wg.
> Streaming with TCP has a lot more to do at the app layer (actually in the
> application itself) rather than the transport layer. So, this topic does
> not belong in here at all IMO.
> >
> > -acbegen
> >
> >
> >
> > > Am 17.07.2017 um 14:16 schrieb Ali C. Begen  >:
> > >
> > > Well, I believe you wanna come up with some metrics for streaming
> video over http and want to extend MDI for that. Well, MDI was not designed
> for that at all, so extending it in that direction is not a good idea.
> Further, there is already tons of work other organizations have done to
> collect metrics for streaming over HTTP. Just look at what others did
> already, mpeg, dash-if, SVA and now almost all the existing work is being
> collected and becoming a single common spec out of CTA. I honestly don't
> think this WG should work on this given the amount of existing and ongoing
> work.
> > >
> > > -acbegen
> > >
> > > On Mon, Jul 17, 2017 at 7:45 PM, Huangyihong (Rachel) <
> rachel.hu...@huawei.com> wrote:
> > > Hi Ali,
> > >
> > >
> > >
> > > That’s one part that MDI could not do, and we hope some new metrics
> could be used, which is the intention of this work.
> > >
> > >
> > >
> > > As for the RTCP XR metrics, it’s not quite realistic in middle devices
> like routers, to implement them, e.g., post-repair metrics, which will need
> the devices to have the ability to decode and apply FEC repair mechanisms.
> So that’s why we need some ways like MDI, easy to calculate and be
> implemented in the network without having to be a RTP entity or TCP proxy.
> > >
> > >
> > >
> > > BR,
> > >
> > > Rachel
> > >
> > >
> > >
> > > 发件人: tsv-area [mailto:tsv-area-boun...@ietf.org] 代表 Ali C. Begen
> > > 发送时间: 2017年7月17日 19:31
> > > 收件人: Qin Wu 
> > > 抄送: tsv-area@ietf.org
> > > 主题: Re: 答复: Proposal for revising RFC4445 or make RFC4445bis
> > >
> > >
> > >
> > > You wanna use MDI to measure media delivery over TCP?
> > >
> > >
> > >
> > > On Mon, Jul 17, 2017 at 7:18 PM, Qin Wu  wrote:
> > >
> > > We have customers using MDI to address new needs, such as wifi
> performance measurement MDI falls short when measuring delivery of
> streaming media over tcp, that is why we think it should be extended. Yes,
> rtcp XR has its value. But I think they could be complimentary.
> > >
> > > Sent from HUAWEI AnyOffice
> > >
> > > 发件人： Ali C. Begen
> > >
> > > 收件人： Qin Wu;
> > >
> > > 抄送： tsv-area@ietf.org; 郑辉;
> > >
> > > 主题： Re: Proposal for revising RFC4445 or make RFC4445bis
> > >
> > > 时间： 2017-07-17 13:02:07
> > >
> > >
> > >
> > > I am really curious about who is using MDI anymore. Can you share data
> if you have it? RTCP XR is still extensively used and for non-RTP, it is a
> mixed of several things.
> > >
> > >
> > >
> > > -acbegen
> > >
> > >
> > >
> > > On Mon, Jul 17, 2017 at 1:39 PM, Qin Wu  wrote:
> > >
> > > Hi, All:
> > >
> > > We like to get a sense of this idea, more than 10 years ago, at the
> time of RFC4445 writing,
> > >
> > > The popularity of delivery of streaming media over packet swtiched
> network has just began,
> > >
> > > not all implementations support QoS methods to improve media delivery.
> Many service
> > >
> > > delivery systems may compose the network with QoS support or without
> QoS support. This add difficulty on characterizing dynamic behavior of the
> network.
> > >
> > >
> > >
> > > 10 years have passed, we see most of widely deployed implementions
> have adopted various different QoS mechanisms
> > >
> > > such as diffserv Intserv, Traffic Engineering, providing QoS guarantee
> to improve delivery of media streaming,
> > >
> > > especially for time senestive or loss senstive application become a
> must; Therefore we see a lot of value of MDI defined in RFC4445 since it
> provide s a handy diagnostic tool for operators and service providers to
> measure the peformance of the network carrying streaming media and quickly
> identify fault in the network.
> > >
> > >
> > >
> > > Today we 

Transport attention to 6lo draft on fragmentation

[Spencer Dawkins at IETF]

Dear Transporters,

Gab Montenegro, co-chair for 6lo, let me know that 6lo is considering
adoption of a draft about how 6lowpan forwards fragments.

The draft is https://datatracker.ietf.org/doc/draft-thubert-6lo-
forwarding-fragments.

Gab asked about getting TSV eyes on this draft, to help inform the working
groups conversation about adoption.

6lo is scheduled for 15:50-17:50 on Tuesday Afternoon (session II),
opposite MPTCP, but if you're available, informed, and opinionated, Gab
says the working group has time to discuss adoption at the end of their
agenda, and welcomes input.

Thanks!

Spencer, who also plans to attend, but is not the guiding light in TSV for
fragmentation issues ...

Re: [Panrg] Proposed Path Aware Networking RG

[Spencer Dawkins at IETF]

Brian, Bob, and Lars,

On Wed, Jul 12, 2017 at 7:52 AM, Bob Briscoe  wrote:

> Brian,
>
> 1/ The IRTF sounds like a good landing point for all the previous attempts
> to get the IETF to add path-awareness protocols.
>
> BTW, this goes back a lot further than SPUD. A good summary of pre-2007
> efforts in this space is in a section of Pasi's draft on this from 2007:
> https://tools.ietf.org/html/draft-sarolahti-tsvwg-crosslayer-01#section-6
> , which reminds us of TRIGTRAN (2002), INTERSEC (2003), ALIAS (2003) and
> TERNLI (2006).
>
> [I wrote this before seeing Lars's email pointing to TERNLI]
>
>
> 2/ The advantages of opacity (invisibility) of path characteristics should
> also be in scope.
>
> In general the tone of the text seems to be "awareness = good; unawareness
> = bad". If I have detected this tone correctly, it would represent an
> implicit value judgement; which would not be a good starting point for
> research.
>
> * You've alluded to potential security advantages in the phrase
> "exploration of trust and risk models".
>
> * There are also evolvability advantages. I recall David Clark (I think)
> saying that the rudimentary interface between transport and network was a
> feature not a bug. Admittedly it's a pain for the transport to have to
> discover available path capacity, path delay, etc. However, the alternative
> would have been to require all L2 technologies to be able to give
> information that would require them to make assumptions about the
> transport. That in turn would ossify transports and L2 technologies.
>
> We might be saying that the Internet is moving into a new phase where
> performance is now more important than evolvability. That's a point to
> debate, but I know you, at least, still believe that stack evolution will
> remain important.
>
>
> Bob
>
>
> On 12/07/17 07:21, Brian Trammell (IETF) wrote:
>
>> Greetings, all,
>>
>> We'll be having a first meeting of the proposed Path Aware Networking
>> (PAN) RG at IETF 99 in Prague next week, 13:30 Wednesday in Congress Hall
>> 3. Since bringing path awareness to the endpoint has been the focus, at
>> least in part, of a couple of running TSV working groups (MPTCP, TAPS),
>> this RG seems to be of general interest to the transport area.  Olivier
>> Bonaventure will give a review and overview of research to date in this
>> space, and Adrian Perrig will present a fully path-aware Internet
>> architecture, as an illustration of what is possible when path-awareness is
>> promoted to a first-order goal.
>>
>>  From our proposed charter (https://datatracker.ietf.org/
>> group/panrg/about):
>>
>> The Internet architecture assumes a division between the end-to-end
>> functionality of the transport layer and the properties of the path
>> between the
>> endpoints. The path is assumed to be invisible, homogeneous, singular,
>> with
>> dynamics solely determined by the connectivity of the endpoints and the
>> Internet
>> control plane. Endpoints have very little information about the paths
>> over which
>> their traffic is carried, and no control at all beyond the destination
>> address.
>>
>> Increased diversity in access networks, and ubiquitous mobile
>> connectivity, have
>> made this architecture's assumptions about paths less tenable. Multipath
>> protocols taking advantage of this mobile connectivity begin to show us a
>> way
>> forward, though: if endpoints cannot control the path, at least they can
>> determine the properties of the path by choosing among paths available to
>> them.
>>
>> This research group aims to support research in bringing path awareness to
>> transport and application layer protocols, and to bring research in this
>> space
>> to the attention of the Internet engineering and protocol design
>> community.
>>
>> The scope of work within the RG includes, but is not strictly limited to:
>>
>> - communication and discovery of information about the properties of a
>> path on
>>   local networks and in internetworks, exploration of trust and risk
>> models
>>   associated with this information, and algorithms for path selection at
>>   endpoints based on this information.
>>
>> - algorithms for making transport-layer scheduling decisions based on
>>   information about path properties.
>>
>> - algorithms for reconciling path selection at endpoints with widely
>> deployed
>>   routing protocols and network operations best practices.
>>
>> The research group's scope overlaps with existing IETF and IRTF efforts,
>> and
>> will collaborate with groups chartered to work on multipath transport
>> protocols
>> (MPTCP, QUIC, TSVWG), congestion control in multiply-connected
>> environments
>> (ICCRG), and alternate routing architectures (e.g. LISP), and is related
>> to
>> the questions raised in the multiple recent BoF sessions that have
>> addressed
>> path awareness and multiply-connected networks (e.g. SPUD, PLUS, BANANA).
>>
>> he PAN(P)RG intends to meet at each IETF meeting until a
>> 

Re: PRELIMINARY Minutes for TSVAREA at IETF 98

[Spencer Dawkins at IETF]

I've uploaded a new version of the TSVAREA meeting minutes, making a couple
of corrections.

The new version is at
https://www.ietf.org/proceedings/98/minutes/minutes-98-tsvarea-01.

I would love to know who was typing in Etherpad for each session - I don't
know, and I want to give credit for those notes, because they were very
valuable in producing minutes.

Beyond that - please do look at these minutes and send corrections, if you
were paying attention to either TSVAREA session in Chicago. The IESG
retreat is next week, and more than one of the topics we talked about are
going to be discussed, whether among the IESG members or in joint sessions
with the IAB. I'd love to have these minutes as correct as they can be.

And thanks for being Transport Folk.

Spencer

PRELIMINARY Minutes for TSVAREA at IETF 98

[Spencer Dawkins at IETF]

These are a couple of days overdue - my apologies.

You can retrieve them at
https://www.ietf.org/proceedings/98/minutes/minutes-98-tsvarea-00.

I especially want to thank the note-takers this time. If I missed your name
in the credits, please let me know, and I'll add it before the minutes are
final.

Please let me know if I got anything fabulously wrong, of course!

Spencer, as AD

Re: TSV AD office hours at IETF 97

[Spencer Dawkins at IETF]

Just to let people know - the TSV AD office hours are at 1300 today, in the
Bianco room, on the third floor of the Swissotel.

You can't get there via elevator from the conference center where most of
the IETF meeting rooms are - go to the hotel lobby and use the hotel
elevators.

(Funny story - Mirja and I made the reservation so long ago that the IESG
wiki still had IETF 97 room assignments - sorry!!!)

Spencer and Mirja

On Oct 21, 2016 1:50 PM, "Spencer Dawkins at IETF" <
spencerdawkins.i...@gmail.com> wrote:

> Just to let people know, Mirja and I will be available to talk about
> things that require TSV AD attention at 11:10-12:10 on Thursday Morning
> (session II).
>
> We have reserved Park Ballroom 3 for this.
>
> If you'd like to talk with us, please let us know that you're coming, and
> what you'd like to talk about (this time, we've reserved an hour, but can
> schedule other times if we need to).
>
> Thanks,
>
> Spencer and Mirja
>
>

TSV AD Office Hours at IETF 98 in Chicago

[Spencer Dawkins at IETF]

Mirja and I will be holding our usual TSV AD office hours, on Tuesday,
March 28, from 1300-1430 (Afternoon I slot).

We'll be in the IESG Breakout Room, which is BIANCO (3rd Floor).

If you have a question that hasn't been answered or a topic that's gotten
wedged, this is your best opportunity to corner both ADs in one place at
the same time.

This works best if we know that you're coming, and why, so we can prepare.

We are, of course, in Chicago all week. If this slot doesn't work for you,
please let us know, and we'll find a time that does work.

Travel safely, and we'll see you in the Windy City soon.

Spencer and Mirja

Draft IETF 96 TSVAREA Minutes now available for review

[Spencer Dawkins at IETF]

Draft minutes are available at
https://www.ietf.org/proceedings/96/minutes/minutes-96-tsvarea.

Please let Mirja and I know about any corrections.

Thank you, Mat Ford, for producing these minutes and reviewing them against
the MeetEcho recording for the meeting.

Spencer

IETF 96 BOFs and new topics

[Spencer Dawkins at IETF]

Just so TSV people are aware of things you may not already be tracking ...

>From Jari:
https://www.ietf.org/blog/2016/06/new-topics-at-the-berlin-meeting/

See you in Berlin,

Spencer

Starting up TSV-ART

[Spencer Dawkins at IETF]

Martin and I mentioned that we will be closing TSV-DIR and starting up a
TSV Area Review Team (TSV-ART), but we didn't actually solicit members when
we talked in Yokohama.

If you're willing to serve on TSV-ART (and a couple of people have already
stepped forward), please let Martin and I know by December 4.

Thanks!

Spencer, for Spencer and Martin

Fwd: Applications and Real-Time Area (ART)

[Spencer Dawkins at IETF]

Dear CDNI,

Those of you who are also subscribed to the IETF-Announce mailing list may
have seen this post, and if you read all the way to the bottom, you'll
notice that CDNI is moving to the new ART area, with Barry Leiba as your
responsible AD.

Martin and I discussed this with the CDNI chairs before we discussed it
with the IESG, and we all agreed that this was a good plan, especially
since most CDNI work is closer to ART than TSV.

I have enjoyed being your AD since 2013, and appreciate Daryl and Francois
as your chairs.

Please keep doing good work.

Spencer

-- Forwarded message --
From: IESG Secretary iesg-secret...@ietf.org
Date: May 29, 2015 14:27
Subject: Applications and Real-Time Area (ART)
To: IETF Announcement List ietf-annou...@ietf.org
Cc: i...@ietf.org

On 28 May, the IESG approved the creation of the Applications and
Real-Time (ART) Area, which will replace the existing Applications
(APP) and Real-time Applications and Infrastructure (RAI) Areas. All
existing working groups from those two areas will move into the new
ART Area, and the three existing area directors -- Alissa Cooper,
Barry Leiba, and Ben Campbell -- will be the ART ADs (or ART
Directors). In addition, the CDNI working group will move from TSV
to ART. Barry will be the responsible AD for CDNI, and no other AD
assignments will change.

The Secretariat will immediately begin working on the administrative
changes required, and the change from APP+RAI to ART will be effective
as soon as the administrative work can be completed.

TSV thoughts for the upcoming IESG retreat

[Spencer Dawkins at IETF]

Dear TSV maevens,

Martin and I will be meeting with the rest of the IESG during the first
week in May, and the IESG and IAB spend one day together.

It's worth your ADs asking if there are things that the TSV area needs the
IESG to think about.

Martin and I have collected significant input about what we should ask
Nomcom for in the position description for TSV ADs, so I think you can take
that as read (and, in any case, we'll be sending the position description
to TSV-Area for comments prior to launching it Nomcom-ward).

Is there anything else we should be aware of? If so, please reply on the
TSV-Area list.

Thanks,

Your humble ADs

IETF 92 BOF cutoff date is Friday, February 6

[Spencer Dawkins at IETF]

I pointed this out at the IAB SEMI workshop, but
http://www.ietf.org/meeting/important-dates-2015.html#ietf92 says the
cutoff date for IETF 92 BOF requests is fast approaching.

I note that there are currently no BOF requests in
http://trac.tools.ietf.org/bof/trac/wiki :-)

If you're thinking of requesting a BOF for Dallas, letting people know
really soon would be spectacular.

Spencer