IETF
tsvwg
tsvwg@jabber.ietf.org
Friday, 9 November 2012< ^ >
martin.stiemerling has set the subject to: TSVWG mtg at IETF 85
Room Configuration

GMT+0
[00:07:55] jlcJohn leaves the room
[00:26:07] Magnus leaves the room
[00:26:09] Magnus joins the room
[00:48:18] Magnus leaves the room
[00:48:20] Magnus joins the room
[00:50:04] Magnus leaves the room: Replaced by new connection
[00:50:05] Magnus joins the room
[00:50:43] Magnus leaves the room: Replaced by new connection
[00:50:44] Magnus joins the room
[00:54:17] Magnus leaves the room: Replaced by new connection
[00:54:17] Magnus joins the room
[01:08:58] Magnus leaves the room
[01:08:58] Magnus joins the room
[01:09:03] Magnus leaves the room
[01:09:05] Magnus joins the room
[01:15:18] Magnus leaves the room: Replaced by new connection
[01:15:18] Magnus joins the room
[01:16:24] Magnus leaves the room: Replaced by new connection
[01:17:40] Magnus joins the room
[01:18:51] Magnus leaves the room: Replaced by new connection
[01:18:51] Magnus joins the room
[02:30:41] wesley.m.eddy joins the room
[02:33:45] Magnus leaves the room: Replaced by new connection
[02:33:46] Magnus joins the room
[02:36:02] Magnus leaves the room
[02:36:06] Magnus joins the room
[02:38:20] Magnus leaves the room
[02:38:27] Magnus joins the room
[02:41:12] Magnus leaves the room
[02:42:58] Magnus joins the room
[02:43:45] Magnus leaves the room
[02:43:49] Magnus joins the room
[02:45:34] Magnus leaves the room: Replaced by new connection
[02:45:34] Magnus joins the room
[02:51:18] Magnus leaves the room: Replaced by new connection
[02:51:19] Magnus joins the room
[02:59:18] Magnus leaves the room: Replaced by new connection
[02:59:19] Magnus joins the room
[03:00:50] Magnus leaves the room
[03:32:33] wesley.m.eddy leaves the room
[03:40:58] Magnus joins the room
[03:41:45] Magnus leaves the room
[03:45:16] wesley.m.eddy joins the room
[05:56:36] wesley.m.eddy leaves the room
[10:55:00] Eliot Lear joins the room
[10:55:05] Eliot Lear leaves the room
[13:43:37] rscheff joins the room
[13:49:58] wesley.m.eddy joins the room
[13:57:16] jlcJohn joins the room
[14:02:46] <rscheff> 9) Chairs - Work Group Overview
[14:02:55] <rscheff> http://www.ietf.org/proceedings/85/slides/slides-85-tsvwg-16.pptx
[14:02:59] <rscheff> starting in 2 min
[14:03:06] <rscheff> time to check the audio...
[14:03:11] <rscheff> anyone remote?
[14:03:19] martin.stiemerling joins the room
[14:06:02] <rscheff> slide 2
[14:06:11] <rscheff> note well
[14:06:48] <rscheff> slide 3 - other notes
[14:07:48] <rscheff> slide 4 - tsvwg agenda
[14:08:01] <rscheff> slide 6
[14:08:27] <rscheff> slide 7
[14:08:37] martin.stiemerling leaves the room: Replaced by new connection
[14:08:39] martin.stiemerling joins the room
[14:10:31] <rscheff> slide 8 - agenda fri 1/3
[14:10:45] <rscheff> slide 9 - agenda 2/3
[14:10:58] <rscheff> slide 10 - agenda 3/3
[14:11:41] <rscheff> 10) RSVP support for PCN
[14:11:46] <rscheff> http://www.ietf.org/proceedings/85/slides/slides-85-tsvwg-1.ppt
[14:12:20] <rscheff> slide 1
[14:13:00] Wolfgang Beck joins the room
[14:13:37] <rscheff> audio good remote?
[14:13:46] <rscheff> slide 2
[14:13:52] <Wolfgang Beck> its working
[14:13:58] <Wolfgang Beck> thanks for scribing!
[14:14:06] <rscheff> slide 3 - main changes
[14:14:29] martin.stiemerling leaves the room: Replaced by new connection
[14:14:30] martin.stiemerling joins the room
[14:14:34] gorryf joins the room
[14:14:42] <rscheff> slide 4 - new comments
[14:14:54] <martin.stiemerling> wrote to the trouble desk to send somebody to check the audoi
[14:15:42] <Wolfgang Beck> audio is working for me
[14:16:17] <rscheff> (high pitched noise here in the room - probably beyond the threshold of the codec)
[14:16:36] <rscheff> slide 4 - new comments 2
[14:16:50] <rscheff> slide 5 of course :9
[14:18:18] <rscheff> slide 6 - next steps
[14:18:53] <rscheff> bob on the mic, did review
[14:20:24] <rscheff> 11) SCTP NAT Support
http://www.ietf.org/proceedings/85/slides/slides-85-tsvwg-4.pdf
[14:20:55] <rscheff> slide 2
[14:26:23] <rscheff> mice failed to verify in-room noise
[14:26:48] <rscheff> modification of doc unclear if authors have time until orlando
[14:27:32] <rscheff> will try to have multihomed by orlando; if that cannt be done, publish with single home spec only
[14:27:58] <rscheff> WG meeting reconvens in Salon A
[14:27:59] gorryf leaves the room
[14:28:24] <rscheff> Please use audio stream of Salon A in 1 minute
[14:28:45] <Wolfgang Beck> ok
[14:28:56] wesley.m.eddy leaves the room
[14:30:48] <Wolfgang Beck> http://ietf85streaming.dnsalias.net/ietf/ietf854.m3u file not found :-/
[14:31:41] <rscheff> checking
[14:31:55] <rscheff> noise followed us
[14:32:34] <rscheff> troubleshooting local noise
[14:33:10] <rscheff> is the remote stream online?
[14:33:24] <jlcJohn> I've thoroughly failed to find a working Salon A audio feed.
[14:34:04] <rscheff> sorry... secretariat is working on this
[14:34:04] Lars joins the room
[14:34:12] <rscheff> notified the chairs
[14:34:24] <rscheff> 13) Recommendations for Transport Port Uses
[14:34:40] wesley.m.eddy joins the room
[14:34:52] <rscheff> sorry, previous presentations, no slides
[14:35:14] <rscheff> 12) Yoshifumi - SCTP Failover *NEW WG DRAFT* (10)
draft-ietf-tsvwg-sctp-failover
[14:35:20] <rscheff> please read draft
[14:36:18] <rscheff> author mentiones about the timing when/how sctp sessions terminate. not mentioned in that specific draft, since this is a more general question
[14:36:33] <rscheff> 13) Joe - Recommendations for Transport Port Uses (10)
draft-ietf-tsvwg-port-use
[14:36:57] <rscheff> gorry won't be shaved to impersonate joe...
[14:37:18] <rscheff> slide 1
[14:37:45] <rscheff> no remote audio from this room...
[14:38:04] <rscheff> going to continue
[14:38:04] <martin.stiemerling> Hi remote participants
[14:38:14] <rscheff> ADs to comment to remote participants
[14:38:16] <martin.stiemerling> We did change rooms because of audio issues and
[14:38:25] <martin.stiemerling> this room does not have an audio feed
[14:38:29] <rscheff> we could change back...
[14:38:32] <Wolfgang Beck> i had working audio in the previous room
[14:38:34] <rscheff> slide 2
[14:38:35] <martin.stiemerling> Is ok for you to not having the audio feed
[14:38:43] Pasi S joins the room
[14:38:46] <martin.stiemerling> if it is not ok, we could go back to the other room
[14:38:54] <rscheff> (after this presentations)
[14:39:24] <Wolfgang Beck> well, its pretty pointless without audio. but to change rooms for 2-3 remote participants..
[14:39:25] <rscheff> @wolfgang, john - guess you vote for getting remote audio back?
[14:39:26] <jlcJohn> Hmm... the lack of audio does rather preclude "participation"...
[14:39:51] <rscheff> (and documentations of comments on the mike)
[14:40:15] <jlcJohn> I don't like "voting" for all those folks to move...
[14:40:16] <rscheff> slide 3 - current status
[14:40:20] <Wolfgang Beck> rscheff just needs to speed up on his typing :)
[14:40:30] <jlcJohn> ;^)
[14:40:34] <martin.stiemerling> We stay in this room, as changing the room would be too much disturbing for the group as we again move.
[14:40:36] <rscheff> i'm not trained to transcribe
[14:40:40] tuexen joins the room
[14:40:44] <martin.stiemerling> Sorry guys
[14:40:58] <rscheff> will transcribe the questions/comments if i manage
[14:41:04] <rscheff> slide 5
[14:41:15] <martin.stiemerling> me thinking on how to make you getting audio
[14:41:30] <rscheff> comment from lars for point 1
[14:41:37] <rscheff> i like this
[14:41:44] <rscheff> its even worse,
[14:41:55] <rscheff> more secure to bind to higher port
[14:42:01] <rscheff> justify the advise
[14:42:11] <rscheff> legacy systems still out there
[14:42:26] <rscheff> (different person commenting)
[14:42:34] <rscheff> slide 6 - issue 2
[14:43:11] <rscheff> carsten again:
[14:43:14] <martin.stiemerling> not sure if skype would could it
[14:43:14] <rscheff> tried to do this
[14:43:24] <martin.stiemerling> should we trying it?
[14:43:54] <rscheff> it would be easy if certains bits are allowed
[14:43:58] <rscheff> michael
[14:44:01] <jlcJohn> I don't use skype, so it might not help me much.
[14:44:13] <rscheff> same protocol on same port (encry, unencry)
[14:44:21] <rscheff> discussion btwn michael and carsten
[14:44:26] <rscheff> problem of 1st byte:
[14:45:04] <rscheff> first byte identifies protocol, could negotiate
[14:45:18] <rscheff> gorry: can we allocate some values for these uses
[14:45:32] <rscheff> for this WG: good thing,
[14:45:39] <rscheff> make sure people knwo about it
[14:45:49] <jlcJohn> what slide # are we on?
[14:45:53] <rscheff> lars: sufficient to alloc 1 byte for non-tls
[14:46:06] <rscheff> carsten: 1st bytes of tls is one of these 5 vals; already works
[14:46:14] <rscheff> need to agree that this continue to work
[14:46:38] <rscheff> lars: spending one byte on each packet - problem of the protocol
[14:46:51] <rscheff> slide 7 - issue 3
[14:47:28] tuexen leaves the room
[14:47:49] <rscheff> martin: good to give advice from iana to people
[14:47:57] <rscheff> would be really useful
[14:48:00] <rscheff> to have advice here
[14:48:10] <rscheff> ---: higher layer multiplexing
[14:48:36] <rscheff> if proto does not have high level mux, there may be pushback on this
[14:48:43] <rscheff> slide 8 - issue 4
[14:49:39] <rscheff> david:
[14:49:51] <rscheff> two problems stated, one ignore
[14:50:08] <rscheff> ignores collision prevention in priv nets
[14:50:45] <rscheff> if noone runs a registriy, this causes a lot of headaches, particular in private nets
[14:51:13] <rscheff> will work this one out with joe
[14:51:25] <rscheff> slide 9 - udp expectations
[14:52:26] <rscheff> lars: we wrote a draft. if there is something missing in that draft, speak up. should be in that draft not here
[14:52:35] <rscheff> ---: sounds bogus
[14:52:51] <rscheff> we should run everything over UDP
[14:52:56] <rscheff> can be arbitrarily fast
[14:53:38] <rscheff> david: look 5405 if anythign has changed.
[14:53:43] <rscheff> joe needs to read 5405
[14:53:50] Lars leaves the room
[14:54:10] Lars joins the room
[14:54:17] <rscheff> bob: assigned ports should nto be used, i disagree with that
[14:54:35] <rscheff> slide 10, issue 6
[14:55:07] <rscheff> lars: i had a case like this
[14:55:16] <rscheff> i cann't open FW holes for dynamic ports
[14:55:27] <rscheff> doesn't help you
[14:55:44] <rscheff> ---: ip multicast is also waste
[14:55:57] <rscheff> iana can not figure out if every req is stupid
[14:56:45] <rscheff> lars: mdns ext bof - may explains how to use for discoverya
[14:56:58] <rscheff> --: had a service discovery protocol,
[14:57:12] <rscheff> were not adopted, need to understand why that didn't work
[14:57:34] <rscheff> slide 11- final issue
[14:58:24] <rscheff> lars: people are unclear about a demux field in their own protocols..
[14:58:45] <rscheff> do not need separate port numbers for their new proto
[14:58:54] <rscheff> comment on slide issue 1
[14:59:07] <rscheff> trusted entity, guarantee behavior
[14:59:19] <rscheff> shoudl that concept be abondones
[14:59:36] <rscheff> we have 801.2x
[14:59:42] <rscheff> what is next...
[14:59:52] <rscheff> lars: if you look at proposal
[15:00:14] <rscheff> use of user port is implied and host ports bar is higher
[15:00:26] <rscheff> port number doesnt tell anything about security,
[15:00:31] <rscheff> that is missing on the drafte
[15:00:43] <rscheff> chair:
[15:01:00] <rscheff> all comments also need to be sent to the list
[15:01:26] <rscheff> chairs need to track the open issues that were raised
[15:01:41] <rscheff> let other WGs know that we are working on this
[15:01:51] <rscheff> Q: Audio
[15:02:11] <rscheff> Martin AD, we are not moving...
[15:02:19] <rscheff> no audio... (my poor fingers)
[15:02:29] <rscheff> 14) Randy and Michael - SCTP drafts (20)
draft-tuexen-tsvwg-sctp-dtls-encaps DTLS Encap of SCTP for RTCWEB
draft-stewart-tsvwg-sctpecn ECN for SCTP *ADOPT?*
draft-tuexen-tsvwg-sctp-multipath Load Sharing for SCTP
[15:02:47] <rscheff> slide 2
[15:02:55] <rscheff> sctpecn draft
[15:03:09] <rscheff> doc is done
[15:03:13] <rscheff> its implemented
[15:03:15] <rscheff> all details there
[15:03:50] <rscheff> doc is ready, ask for WG item
[15:04:18] <rscheff> against adoption of this draft?
[15:04:29] <rscheff> group has previously shown interest
[15:04:50] <rscheff> no comments
[15:04:54] <rscheff> outcome to the list
[15:04:56] <rscheff> slide 3
[15:05:07] <rscheff> sctp over dtls
[15:05:39] <rscheff> running in single homed mode
[15:06:44] <rscheff> comments to the list please
[15:06:58] <rscheff> will ask for rtcweb WG item
[15:07:22] <rscheff> mike westlund (rtcweb chair): i hope this work will progress
[15:07:36] <rscheff> its in the architecture of rtcweb
[15:08:04] <rscheff> rtcweb has made decision to go with that route
[15:08:18] <rscheff> if tsvwg does not adopt, rtcweb will have to adopt
[15:08:45] <rscheff> comments on this draft?
[15:08:54] <rscheff> who has read that draft?
[15:08:59] <rscheff> show of hands
[15:09:11] <rscheff> 2 ADs... 3 people
[15:09:46] <rscheff> liaese with rtcweb chair
[15:10:05] <jlcJohn> (I do hope you meant 3 people _other_than_ ADs...)
[15:10:15] <rscheff> martin (AD): already 400 k users with this
[15:10:23] <rscheff> encourage people reading this doc
[15:10:36] <rscheff> as sctp gets more wide adoption
[15:10:41] wesley.m.eddy leaves the room
[15:10:55] <rscheff> slide 4 -sctp sack
[15:11:41] <rscheff> optimizes tls handshake
[15:11:47] <rscheff> implemented fro years
[15:11:52] <rscheff> adoption for wg item
[15:12:21] <rscheff> nned to registrer this flag with IANA
[15:12:41] <rscheff> problem when someone else does a private flag, poises problem
[15:12:47] <rscheff> 3 major kernels already do thjis
[15:13:27] <rscheff> has 2 review cycles
[15:14:49] <rscheff> anyone following remotely still?
[15:15:01] <Wolfgang Beck> yes
[15:15:10] <jlcJohn> +1
[15:15:11] <Wolfgang Beck> thx for your heroic efforts for the transcript
[15:15:14] <rscheff> comments?
[15:15:23] <rscheff> read thiss draft?
[15:15:28] <rscheff> 6 people
[15:15:39] <rscheff> all reads in adooption as wg item
[15:15:52] martin.stiemerling leaves the room: Replaced by new connection
[15:15:53] martin.stiemerling joins the room
[15:16:05] <rscheff> group will be asked
[15:16:21] <rscheff> process question
[15:16:30] <rscheff> next step is adoption
[15:16:35] <rscheff> respond on the list
[15:16:47] <rscheff> slide 5 sctp multipath
[15:17:18] <rscheff> implemented in freebas
[15:17:29] <rscheff> didn'T know how to handle congestion control
[15:17:35] <rscheff> solved by MPTCP CC
[15:17:52] <rscheff> document how to do loadsharing in the sctp framework
[15:18:07] <rscheff> similar problem sctp and mptcp
[15:18:21] <rscheff> need to adress a couple of divergences
[15:18:29] <rscheff> had asked baout wg adoption last time
[15:18:40] <rscheff> will this rfc be read?
[15:18:55] <rscheff> asked companies that implement sctp
[15:19:08] <rscheff> cannt comment on future products
[15:19:20] <rscheff> need to lower the bar
[15:19:31] <rscheff> content isn't there yet
[15:19:47] <rscheff> shouldn't be a problem with workload
[15:20:51] <rscheff> who has read
[15:20:54] <rscheff> 1 person
[15:21:17] <rscheff> yoshifumi: please make a comment to mptcp WG
[15:21:20] <Wolfgang Beck> sctp is mostly used in call signalling / datacenters; no point in doing multipath if you have Gb links
[15:21:39] <rscheff> (faster error recovery springs to mind)
[15:21:44] <rscheff> (my comment)
[15:22:06] <Wolfgang Beck> @rscheff: SCTP already does multihoming, doesn't it?
[15:22:35] <martin.stiemerling> it has multihoming, but you cannot use the multiple paths at the same time
[15:22:41] <martin.stiemerling> the other paths are for failover
[15:22:46] <rscheff> micharel: loadsharing will help doing faster failover
[15:22:50] <rscheff> not the main focus
[15:22:56] <rscheff> (brought your commetn to the mike)
[15:23:02] <rscheff> we need to review
[15:23:20] <rscheff> need to see discusson on the list on this draft
[15:23:31] <rscheff> slide 6 heads up
[15:23:54] <rscheff> (multihoming != coupled congestion control across multiple paths)
[15:25:08] <rscheff> there will be 2 short docs around this, info
[15:25:40] <rscheff> rtcweb limits to 2G chunks, but that is too small according to them
[15:25:45] <rscheff> need to interleave
[15:26:00] <rscheff> doc will be short, 4-5 pages, hard implementation
[15:26:03] <Wolfgang Beck> yes. load balancing across links: probably not necessary until cheap home routers supporrt SCTP-- fast failover from on link to another is definitely useful
[15:26:15] <rscheff> lars: why do they need to send such large objects
[15:26:49] <rscheff> head of line blocking is the issue on large objects
[15:27:03] <jlcJohn> what is meant by "large"?
[15:27:11] <rscheff> >200 M
[15:27:16] <jlcJohn> thx
[15:27:28] <rscheff> should add another field to solve the field
[15:27:32] <rscheff> the problem
[15:28:06] <rscheff> rtcweb don't want to have their protocol to do chunking
[15:28:10] <rscheff> push this to sctp
[15:28:33] <rscheff> there are consideration when you have ordered/unordered messages
[15:28:40] <rscheff> will be brought to WG
[15:28:49] <rscheff> will write a draft
[15:28:55] <rscheff> change of applicability for SCTP
[15:29:16] <rscheff> 16) Applicability Statement for the use of IPv6 UDP
[15:29:25] <rscheff> http://www.ietf.org/proceedings/85/slides/slides-85-tsvwg-2.pptx
[15:30:03] <rscheff> slide 1; 2 drafts
[15:30:14] <rscheff> slide 3
[15:31:13] <rscheff> slide 4
[15:31:56] <rscheff> slide 5
[15:32:40] <rscheff> slide 6
[15:32:43] tuexen joins the room
[15:33:56] <rscheff> slide 7 - next steps
[15:34:03] <rscheff> current drafts are not fully updated
[15:34:37] <rscheff> please review
[15:34:40] <rscheff> questions?
[15:35:02] <rscheff> has implications on middlebox design
[15:35:07] <rscheff> need more reviews
[15:35:20] <rscheff> gorry will bring this to WGLC
[15:35:39] <rscheff> 17) Reactions to Signaling from ECN
[15:35:44] <rscheff> http://www.ietf.org/proceedings/85/slides/slides-85-tsvwg-12.pdf
[15:36:23] <rscheff> sorry
[15:36:24] <rscheff> 15) RSVP Application ID Profiles
[15:36:32] <rscheff> http://www.ietf.org/proceedings/85/slides/slides-85-tsvwg-15.pptx
[15:37:16] <rscheff> slide 2
[15:37:31] <rscheff> slide 3
[15:38:36] <rscheff> slide 4 - open issues
[15:38:57] <rscheff> comments?
[15:39:02] <rscheff> who has read?
[15:39:16] <rscheff> sting will change when this becomes RFC
[15:39:24] <rscheff> refernce will change to the rfc number
[15:39:39] <rscheff> reviewed 3rd version
[15:39:56] <rscheff> satisfied with changes, draft is useful, can be adopted
[15:40:06] <rscheff> 4 people have read
[15:40:16] <rscheff> comment on adoption status
[15:40:24] <rscheff> ---:adopt
[15:40:30] <rscheff> start adoption call
[15:40:34] <rscheff> formally call now
[15:40:45] <rscheff> respond to them on the list
[15:41:25] <rscheff> [16:35:57] <rscheff> 17) Reactions to Signaling from ECN
[16:36:02] <rscheff> http://www.ietf.org/proceedings/85/slides/slides-85-tsvwg-12.pdf
[15:43:55] <rscheff> mirja: rmcat chair
[15:44:00] <rscheff> have read early version
[15:44:18] <rscheff> wanted to be broader on congestion events
[15:44:28] <rscheff> defautl: invoke CC
[15:44:40] <rscheff> later conversation: swapping codecs
[15:44:43] <rscheff> as mehtod
[15:44:50] <rscheff> instead of CC reaction
[15:45:07] <rscheff> one reaction is CC, other types need to be considered
[15:45:16] <rscheff> mirja: why is this only for ECN
[15:45:23] <rscheff> it could be for ecn and loss,but
[15:45:34] <rscheff> not a compelling argument
[15:45:50] <rscheff> draft a follow on to ecn to rtp
[15:46:03] <rscheff> therefor brought to tsvwg
[15:46:11] <rscheff> broader scope doc
[15:46:22] <rscheff> mirja: call for reviews on rmcat list
[15:46:37] <rscheff> --: agree to respond in different ways
[15:46:49] <rscheff> given rmcat, and what we want to do on CC is unknown
[15:47:09] Pasi S leaves the room
[15:47:11] <rscheff> what to do, what needs to be done, doc does not specify
[15:47:21] <rscheff> we dont know what we want to do
[15:47:22] martin.stiemerling leaves the room: Replaced by new connection
[15:47:22] martin.stiemerling joins the room
[15:47:54] <rscheff> initial we had recommendations in the spec
[15:48:00] <rscheff> to echange cc algo
[15:48:06] <rscheff> (trfc at the time)
[15:48:17] <rscheff> we don#t want to make any recommendation
[15:48:35] <rscheff> it is a value to consider other reactions
[15:48:40] <rscheff> like to get this in the doc
[15:49:07] <rscheff> michael welzl: clear if this is a survey or a recommendation
[15:49:21] <rscheff> in the past this awas a recommendation
[15:49:24] <rscheff> now we want to have a little section on CC
[15:49:41] <rscheff> ppoint people to RMCat is not normal
[15:49:58] <rscheff> gorry: we don't knwo what the doc should say
[15:50:02] <rscheff> add more flesh to this
[15:50:16] <rscheff> covers multiple responses
[15:50:30] tuexen leaves the room
[15:50:30] <rscheff> obviously in our charter, doc belongs currently to this group
[15:50:58] <rscheff> http://www.ietf.org/proceedings/85/slides/slides-85-tsvwg-11.pdf
[15:51:23] <rscheff> guidelines for adding ECN to protos that encaps IP
[15:51:25] <rscheff> slide 2
[15:51:56] <jlcJohn> (Sorry to be commenting without hearing Bob's presentation...)
I support this work, but wonder whether it belongs in TSVWG: transport can only
specify the meaning of ECN bits set by sender and the interpretation of ECN bits
received: not how tunnels might modify them.
[15:53:18] <rscheff> gorry: believe this belongs to this WG at he moment
[15:54:03] gorryf joins the room
[15:54:03] <rscheff> tunnel endpoint needs to propagate this
[15:54:26] <rscheff> draft is a guideline to people in other groups who write specs in this area
[15:54:50] <rscheff> most tunnel protos are ietfs
[15:54:59] Lars leaves the room
[15:55:06] Lars joins the room
[15:55:31] <rscheff> dropped as bob had no time to spend on this in the last 18 month
[15:55:38] <rscheff> had a lot of comments
[15:55:53] <gorryf> As chair: if there are concerns about whether this is in the tsvwg charter please email the chairs.
[15:56:01] <rscheff> added three arrangements
[15:56:06] <rscheff> (ascii pictures)
[15:56:15] <rscheff> slide 5
[15:56:18] <rscheff> (graphs)
[15:56:28] <rscheff> we cannt be too prescriptive
[15:56:48] <rscheff> specific about three modes, rather than beeing too general
[15:57:35] <rscheff> guideline as to when these modes are applicable
[15:58:01] <rscheff> time running out
[15:58:16] <rscheff> need good coauthors and volunteers
[15:58:28] <rscheff> because the distinct requirements of each of these modes
[15:58:35] Wolfgang Beck leaves the room
[15:59:09] <rscheff> like reviews, ask for adoption at next ietf
[15:59:28] <rscheff> intended status BCP
[15:59:35] <rscheff> david black:
[15:59:43] <rscheff> clearly in scope
[16:00:00] <rscheff> past rfc settle this question (ecn in tunnels)
[16:00:09] <rscheff> signing up as reviewer
[16:00:41] <rscheff> meeting concludes
[16:00:50] <rscheff> final remarks by gorry
[16:00:54] <jlcJohn> thx, Richard!
[16:01:03] <rscheff> bye from gorry, james
[16:01:15] <rscheff> (hope this wasn't too bad)
[16:01:33] Lars leaves the room
[16:07:00] gorryf leaves the room
[16:19:25] martin.stiemerling leaves the room
[16:26:49] Lars joins the room
[16:30:03] rscheff leaves the room: Computer went to sleep
[16:32:44] gorryf joins the room
[16:32:50] gorryf leaves the room
[16:33:28] gorryf joins the room
[16:47:15] gorryf leaves the room
[17:08:53] Lars leaves the room
[17:59:19] gorryf joins the room
[18:03:33] gorryf leaves the room
[18:05:57] gorryf joins the room
[18:07:33] gorryf leaves the room
[18:24:28] gorryf joins the room
[18:31:02] gorryf leaves the room
[18:48:56] martin.stiemerling joins the room
[18:52:28] martin.stiemerling leaves the room: Replaced by new connection
[18:52:30] martin.stiemerling joins the room
[18:55:03] martin.stiemerling leaves the room
[20:08:41] gorryf joins the room
[20:08:44] gorryf leaves the room
[20:11:33] gorryf joins the room
[20:13:22] gorryf leaves the room
Powered by ejabberd Powered by Erlang Valid XHTML 1.0 Transitional Valid CSS!