Last Modified: 2005-07-08
| Done | Updates to RFC 793 to resolve conflict between diffserv and TCP interpretation of IP Precedence submitted for publication as Proposed Standard | |
| Done | Addition to RFC 2018 to use TCP SACK for detecting unnecessary retransmissions submitted for publication as Proposed Standard | |
| Done | Submit I-D on TCP Congestion Window Validation to IESG for consideration as a Proposed Standard | |
| Done | Submit I-D on Computing TCP's Retransmission Timer to IESG for consideration as a Proposed Standard. | |
| Done | submit revised ID for ECN to IESG for consideration as a proposed standard | |
| Done | submit ID on UDP-lite to IESG for consideration as a proposed standard | |
| Done | TCP-Friendly Rate Control (TFRC) unicast congestion control algorithm submitted to IESG for consideration as a proposed standard | |
| Done | Submit ID for SCTP unreliable transport mode to IESG for consideration as a Proposed Standard | |
| Mar 04 | Submit early retransmission to IESG for consideration as Experimental | |
| Mar 04 | Submit SCTP Implementer's Guide to IESG for consideration as an Informational RFC | |
| Apr 04 | Submit Eifel response to IESG for consideration as a Proposed Standard | |
| Jun 04 | ECN Nonce procedure submitted to IESG for consideration as Proposed Standard | |
| Sep 04 | Submit ID for SCTP API for consideration as an Informational RFC | |
| Sep 09 | TCP-Friendly Variable Rate Control unicast congestion control submitted to IESG for consideration as a Proposed Standard |
| RFC | Status | Title |
|---|---|---|
| RFC2861 | E | TCP Congestion Window Validation |
| RFC2883 | PS | An Extension to the Selective Acknowledgement (SACK) Option for TCP |
| RFC2988 | PS | Computing TCP's Retransmission Timer |
| RFC3042 | PS | Enhancing TCP's Loss Recovery Using Limited Transmit |
| RFC3168 | PS | The Addition of Explicit Congestion Notification (ECN) to IP |
| RFC3309 | PS | Stream Control Transmission Protocol (SCTP) Checksum Change |
| RFC3390 | PS | Increasing TCP's Initial Window |
| RFC3436 | PS | Transport Layer Security over Stream Control Transmission Protocol |
| RFC3448 | PS | TCP Friendly Rate Control (TFRC):Protocol Specification |
| RFC3517 | PS | A Conservative Selective Acknowledgment (SACK)-based Loss Recovery Algorithm for TCP |
| RFC3522 | E | The Eifel Detection Algorithm for TCP |
| RFC3540 | E | Robust ECN Signaling with Nonces |
| RFC3649 | E | HighSpeed TCP for Large Congestion Windows |
| RFC3708 | E | Using TCP DSACKs and SCTP Duplicate TSNs to Detect Spurious Retransmissions |
| RFC3742 | E | Limited Slow-Start for TCP with Large Congestion Windows |
| RFC3758 | Standard | SCTP Partial Reliability Extension |
| RFC3782 | Standard | The NewReno Modification to TCP's Fast Recovery Algorithm |
| RFC3828 | Standard | The UDP-Lite Protocol |
| RFC4015 | Standard | The Eifel Response Algorithm for TCP |
|
TSVWG - Transport Working Group - IETF 63
Meeting Notes, taken by Matt Zekauskas, brilliantly as always. Lights edits thereof by Allison Mankin, co-chair, co-AD. This meeting was singly chaired by Allison. Jon was absent in order to serve as the AD for the voipeer BOF. The Transport Area overflowed its scheduling boundaries beyond repair this meeting. 0. Agenda Bashing and Status Update === Several documents that are scheduled for WGLC: draft-ietf-tsvwg-sctpimpguide0-14.txt draft-ietf-tsvwg-diffserv-service-classes-01.txt (multiple revs before wg) draft-ietf-tsvwg-mlpp-that-works-02.txt The goal is to get these documents on the end August and first of September IESG agendas, and out the door. The working group should determine which other documents are ready. Allison then turned to tsvwg structure. Allison and Jon are considering adding a tsvwg co-chair, to help track documents, and move them along. They are looking for people that are active participants; if you are interested, please tell the chairs. They will do some interviewing. This is relevant to the absence of Jon in this meeting -- there is too much work and the area generates too many conflicts for participants. In addition: Allison and Jon have been thinking of restructuring the area for some time -- both for area or topic focus and for logistical breathing room. This split would entail taking an area with the topic of something like Real Time Applications and Operations (with groups like IPTEL, SIP...) out separate from Transport. There would be many details to discuss. We can have some discussion of the split on the list if you like, as this develops. ===================== 1. Francois Lefaucheur === draft-tsvwg-rsvp-dste-00.txt (first version as a wg doc) Francois started by reviewing the status of the document, which discusses the aggregation of RSVP reservations over MPLS TE tunnels (see slides). He noted the changes, which responded to comments here, as well as the responses from the MPLS WG due to a message asking for comments there. Francois said that the authors were not aware of any remaining outstanding issues, and feel the document is done. Should the document go to WGLC? Allison asked where the MPLS discussion occurred. It was on the MPLS list. She also verified that this has no MPLS extensions. Francois said the principal concern was with possible overlap with LSP-HEIR. With the most recent changes, there is no overlap and the two documents are consistent. Bob Braden said that he recently looked at RFCs and drafts about RSVP and tunneling. It seemed that they were all solving the same problem, and it wasn't clear which ones should be implemented. His conclusion was that the modularity is all wrong... the documents were taking little bits and slices of the problem... but it was really all the same problem. Another way would be to update earlier documents, rather than writing a new document with a different slice. He asked what others thought. Francois kind of agreed with Bob's analysis, but he wasn't shure he would come to the same conclusion. If we were to start over, maybe we would end up with a more generic and modulare framework; perhaps it is too late. First there was RSVP over IP, then aggregation in 3175, now LSP tunnels. The set of potential new documents is small, there are not too many situations left; Francois thought that this line of modification was basically over. Bob thought that perhaps we'll just replace RSVP with NSIS. [[say something about a snide comment? drop this? put a smiley?]] Bruce Davie said that as a co-author, they did try to position this draft with respect to the other drafts. Rather than viewing this as a "pigs ear", there was a set of design decisions when first tunnel draft was done, 3175 did more, and this is a delta to 3175. He didn't think the situation was as bad as Bob fears. Allison noted that people inherently use tunnels for non-coordinated purposes, that's the nature of tunnels. And many people have tried to make "clean tunnel" theory. Tunnels by design are clean on the inside, but an outside logic for them, the idea that they should be related to other types of tunnels is not clear - they're just meant to arrange for their own inside user's benefit. But one of the first comments given to Francois was to clarify the relation to the past RSVP* tunnel work, and that's in there. Allison said that she is willing to have a WGLC, but the WG needs to have written reviews from the people that call themselves the "RSVP team". Any objections? No one voiced objections. Allson called for a hum: People supporting wglc at this time? There was moderate support Allison declares enough support to go ahead. The requirement will be a least a couple of RSVP reviewers (from the RSVP team) to write during WGLC. ===================== 2. More Francois... === Generic aggregate RSVP reservations draft-lefaucheur-rsvp-ipsec-01.txt Francois next discussed for the second time an RSVP extension which combines two features of RSVP: aggregation into IPSec and aggregation into Diffserv regions (see his slides to get the picture). The open items mainly carry over from last time: clarifying text about what is responsible for managing the security association and what is responsible for mapping traffic onto the security associations; and moving the discussion of handling dynamic SPI/Security association updates out of the security considerations section. The authors would like more feedback, and wish to have the document accepted as a working group document. James Polk asked if IEPREP changes its charter as proposed would this document be better homed there. Allison stated that she did not think this document is directly pertinent to IEPREP -- it's not strongly tied to emergency service. It has a role, but she did not see IEPREP as the proper home. Allison's biggest concern is that we don't have a strong security group that can look at aggregating identities in SPI. She did not think RSVP extension was a concern, and was not worried about doing the document here. It fits with the nested VPN work. She did feel that we need to ask someone in IPsec as to whether extending the RSVP IPsec story, brning multiple identities and users, has any security problems. Some other WG has to go through the security issues; she will ask the security ADs about that. James said that he didn't read the draft but felt the problem was a good one to solve. Someone asked what's intent for nested VPN document? [That one is draft-baker-vpn-signaled-preemption, it needs to recover from expiration]. author: the last time it was discussed, Fred tried to get it into last call. We have gotten feedback on the mailing list; the document is now at -03. Allison asked if the changes on it could be summarized to the list, and then request last call on the list. We'll discuss it over on the mailing list. author: When we discussed, nested VPN was with Fred and James' bandwidth reduction draft. [draft-ietf-tsvwg-bw-reduction - expired currently] James stated that he will have a new revision of the bandwidth reduction draft within 5 days. Allison said that we have to discuss these drafts and go through the issues, and we can do that on the mailing list. Get the changes to the list so we can discuss them. James stated that he thought the nested VPN draft was agreed to become a working group document at last meeting. Allison said we also need a commitment from room to review. She asked for a hum of interest: hum if you will give effort and interest to this work. Allison declared the result "low but not absent". ===================== 3. Kwok-ho Chan === Kwok said he didn't make slides on the diffserv service class draft. They have received no comments; only spelling and grammatical cleanup has been done. They are essentially into WGLC, as mentioned. Aggregation of DiffServ Service Classes draft-chan-tsvwg-diffserv-class-aggr-02.txt He then went on to talk about the aggregation of DiffServ service classes draft (see slides). He mentioned the changes in the draft, which included using the EXP field of MPLS to send the aggregates, so DSCP doesn't change. James Polk asked about EXP being used to preserve DSCP. EXP only has 3 bits versus the six of DSCP -- is there a mapping? Kwok-ho responded yes. James then asked about preserving DSCP from one domain to the next - how do you make the policy decision that domain B must follow given domain A actions? Kwok-ho responded that they were thinking this would be like service classes, and certain DSCP values would be recommended. However, the end user is one that requested service from network. They want traffic treated certain way. Say Alice in Atlanta uses DSCP 3, and Bob uses DSCP 5. Don't you need to map them? Kwok said they want to avoid having a mapping function. James thought you couldn't complete avoid this. Brian Carpenter stated that mapping DSCP at administrative boundaries is part of the DiffServ architecture, you can't switch it off. It might be desirable that operators agree on a one-to-one mapping. Kwok agreed that a mapping function could be there. He then went back to his presentation, and showed a mapping of EXP bits. In his view the next steps are to get comments on the list, and make the document a working group document. He thinks it could be in WGLC within two IETF meetings. Allison stated that she did not see consensus around this draft yet; the working group needs to work on the structure of the idea. ===================== 4. Josef Babiarez === RT-ECN draft-babiarz-tsvwg-rtecn-04.txt Josef Babiarez discussed the RT-ECN draft. He began with associated drafts and a justification for new ECN semantics (see slides). He then discussed the updates, principally: * updated draft to meet requirements in floyd ECN draft * handle both ECN and non-ECN using same DSCP * addressed who rt flows reach when encountering 3168 router James Polk asked if Josef would expand on that. Josef said that when an alternate ECN mechanism encounters an RFC3168 router that is in congestion it should back off. James said that he read the draft last time, and this wasn't clear to him, nor is it clear what has changed to help. Josef said they now have a mechanism to test for non-conformance, and use that mechanism to test for router that is marking ECN bits as per 3168. David Black said that it was not clear to him that the mechanism works as advertised; James said that that was his concern as well. David said the reciever can figure out what's going wrong, but where is feedback to the sender? Josef said through application contro, for example SIP signalling. The ECN marking is sent to the end point, the end station gives this to application control, and the application control preempts the session. David said that in other words it is "not your problem"; the draft must contain an explicit MUST to implementers to do this. Colin Perkins said that in the AVT WG, there was pushback on application mechanisms. They don't think they work. James gave an example: suppose Alice & Bob are have an RTP real time flow. It can take multiple paths. In the limit, every packet could take different paths. These paths can have multiple different routers. The receiver gets an ECN notification from one of them. The server will tell Alice what to do. What can Alice do? She can't reroute traffic... Josef said that wasn't quite true; when a flow contains congestion, the application controller has a flow association, and it terminates the session. The issue is that the end point can terminate the session. James said that he didn't think it will necessarily have the desired effect. If the end point can't determine which intermediate routers the flow uses, it doesn't know that if the flow stops, that it would help reduce congestion. Magnus Westerlund stated that if a receiver gets one or two marked packets the response is usually to slow down, not terminate the flow. Josef said that could be a valid response. Magnus thought the use case seems to be admission control if get probe packet; Josef said to read the draft. Colin said that during establishment of new flows, he doesn't see how you can count absence of marked packets as an indication that you are allowed to admit a flow. Josef said that if traffic at time of session setup is below 20%, then packets won't be marked; Colin said that only makes sense if packets all follow same path and if congestion is stationary, neither is true. David echoed that there is still an opportunity to get in trouble if the path changes at wrong moment. Josef said that if the path changes, and there is now congestion, the flow will be preempted. Another participant [xxx] stated that his understanding from AVT is that these packets which you are going to send may have different characteristics than packets that consitute main flow. Therefore, they may follow a different path than main flow. Josef said they were using IP/UDP and he didn't see a differnece. David stated that all you need is a filter that puts RTP elsewhere. Then you are guaranteed to have the path switch. Fred Baker said it depended on how probing was done; suppose the probe was an RTP packet? However, there was another possibility; if a different DSCP was used. The topology might depend on the DSCP. Routes change over time, things fail and restore. Colin said it would only work if RTP packets were sent, and there was strong pushback from AVT to not use RTP for this. Allison thought there was an RTP NOP; Colin said there was a NOP draft under discussion. Wouldn't that be a possible manner of probing? Colin stated that he has no problem with marking RTP traffic, but this use would warp the architecture. Fred thought another way forward might be to look at the implication of probe traffic on other traffic. You have admitted traffic you would like to maintain. The concern he has is that additional (probe) traffic might preturb the already admitted traffic and hurt service for a different time. Josef said that's why they wanted to use a very lightweight RTP flow. A no-op or something similar. Magnus thought this might cause a preemption. Josef said to look at the draft - that's why there are two levels. One as an early indication of congestion, to stop permitting new traffic. There is a level between stop admitting and preemption. Another concern is that the threshold would depend on the type of traffic carried; however this draft assumes you own a DSCP, and don't expect other types of traffic in service classes. Colin asked if there were going to be different code points for voice, video, tcp? Allison said that we seem to have gotten past fine points and worked up to big points, which seems to be the way the IETF does things It's important that this discussion goes on but we are out of time; maybe the intersted parties could linger afterwards to discuss the issues, and also discuss them on the list. Allison asked David Black to shepherd the discussion; would like closure at "tree level" than "document level". David said that he would, and in his view the "tree level" is that the assumptions made by this draft don't match AVT and MMUSIC concepts. Allison said it's an important problem, and we need to work on it. [xxx: the first is, is it this draft?] (Editorial comment by Allison: no, the first is still, the concepts...) ===================== 5. Sally Floyd === draft-floyd-ecn-alternates-01.txt Sally Floyd quickly discussed the ECN alternates draft -- what you need to consider if you want to specify a new ECN behavior. She would like this to be not just her draft, but an official WG document, so she can get out of the business of consulting on ECN. She discussed the problem: how do routers know what to do; how do you deal with incremental deployment problems; can the new version co-exist with the old; and how you can evaluate alternate ECN semantics (see the slides for details). There has been one round of feedback and revisions were minor. Bob Briscoe said that he agreed with everything in the draft. He thought that Sally said that the ECN nonce is not a standard part of the default semantics, but informational. Sally replied that 3162 includes code points for ECN nonce, but doesn't include all details. Bob said that he is sensitive to this, because he is intending to write an alternative that uses codepoints for a different nonce. Allison said that the intent is to bring nonce to proposed standard; she thinks we need it. If you have a solution that improves upon it, this is valuable to know. Please contribute, but soon. The nonce was put out as an Experimental (as Sally said the bits were in the Standard), just as ECN was first Experimental and then went to Proposed Standard. There is a window of discussion about its effectiveness. Bob mentioned his SIGCOMM paper on use of the nonce bits. We encouraged his draft. (Editorial since this link was not provided at the time: http://www.acm.org/sigs/sigcomm/sigcomm2005/paper-BriJac.pdf). Sally said that the ecn alternates document was needed; there are alternate proposals that she hears about and this would save her work responding to them; she didn't think it would cause a flood of documents, or imply in any way that documents should or should not be approved. Allison asked if we should take a hum. Him to see if people would like to adopt it for guidance to world. "Hum if you think we could adopt as a working group document" <loud> Hum if oppose <none> Allison declares consensus to adopt as a working group document. Sally asked if the document should be informational; Allison thought it would be fine. Aaron Falk asked about the document status; he thought the document feels like a BCP instead of informational. Allison thought it could be. It could be replaced as we learn and evolve. Sally said that it could, but she hoped it would not need to be replaced. Allison thought Gorry gave good a good test: if you would want to keep the same number for new advice. Notetaker's report: it was not clear we came to closure, think BCP was the general feeling] ===================== 6. More Sally... === draft-ietf-tsvwg-quickstart-00.txt Sally then discussed the QuickStart draft (see slides for details). In summary: why not send data all at once if have super underutilized path. It's an "anti-congestion control" mechanism. All promised changes have been made. Open issues: * retransmitting SYN packets. Is there any implementation that would react badly if TCP sender retransmitts SYN packet with different ISN? * there are four free bits: use QuickStart nonce? Sally would like to have a QuickStart nonce, the co-authors are neutral. It's a way to get around the receiver lying. Randall Stewart noted that if he was going to scam QuickStart as a receiver, he would just always reduce the amount by 10 Kbits, so the sender wouldn't look at the nonce. Sally noted that if the sender was very conservative, or had reason to be suspicious, it would only use QuickStart if the original request was approved. Matt Mathis asked about handling the case where the request was reduced twice. Sally said that the nonce doesn't give any protection once the rate is reduced. Matt said that the random value might not need to change [xxx?]. Sally said they gave it a lot of thought but couldn't come up with any easy answer. ?3: if have few extra bits, if router indicates requested rate was way lower... get "that's really a small bit for this network". don't think we came up with that one, none seems as pressing. Sally said that Joe Touch offered to help improve the section on tunnels. The remaining items are a revision for tunnels, to decide about using a nonce, and any other feedback the group would provide. Please send feedback. Sally asked if there was a group of people that wanted to brainstorm with her on the draft... send email. Allison noted that there are a lot of "bright noncers" in the group; Bob Briscoe and Gorry Fairhurst offered to be among the quick start nonce think tank to resolve this. ===================== 7. Mark Handley === Internet Congestion Control Research Group (ICCRG) Mark Handley gave a brief presentation forshadowing his plenary talk tomorrow on a proposed research group in the IRTF: The Internet Congestion Control Research Group. There is a lot of work going on in improving congestion control: to better utilize "long fat networks", for realtime, for wireless and recovering from non-congestive packet loss. There are problems being faced by research networks today. However, there is no desparate need, and we have the opportunity to "do it right". How do you get all right people together to decide on really good ideas and map them into the real world? The IETF is not good at long-term discussion, and there doesn't appear to be another good venue. So, why not the IRTF? See <http://nrg.cs.ucl.ac.uk/mjh/iccrg> <http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg> Tell Aaron Falk (IRTF chair) if you think it is a good or bad idea. ===================== 8. Doug Leith === draft-leith-tcp-htcp-00.txt Doug discussed his H-TCP draft. Mark's talk was a good introduction. Doug gave motivation and background (see slides for details). He thought it was time to re-open discussion on congestion control algorithrms; there are two RFCs out there in this space that have gone through and seem to have stalled. [Editor: I think this refers to the deployment situation of RFC 3649 but I'm not sure...] Doug's guiding principle is to make the smallest changes to make things work again. He thought that was vital. H-TCP adjusts the increase rate as a function of the time of last backoff; and it is symmetric. The authors have been working on H-TCP for a while; there was an implementation at the Stanford Linear Accelerator Center (SLAC) in 2004 and the Hamilton Institute in 2005. The initial internet-draft is out there for comments. Please read it and comment. Allison said that TCPM asked that discussion on this draft happen here. She asked for a hum if there was interest in thorough reading and commenting: <moderate hum> Allison declared that there was interest, so the authors should return. [Notetaker comments: presumably after starting discussion on the ML :) ; Editor replies: yes, you are right!]. ===================== 9. Bob Briscoe === Bob Briscoe reported on two drafts that execute an idea that goes back to the INTSERV days: providing a controlled load service, using distributed measurement-based admission control. See the slides for detail. The two drafts: * a use case: draft-briscoe-tsvwg-cl-architecture-00.txt * a PHB: draft-briscoe-twvwg-cl-phb-00.txt This idea relates to RT-ECN, and RMD (in NSIS). The idea started in theory, and then moved to engineering. IETF protocols and functions [RSVP, DSCP, ECN] are used to implement the idea, but it breaks the original architectures. The environment is one where congestion events are rare, and you want to deal with them, but you'd like a cheap mechanism, and not have to deal with them all the time. The solution builds on IntServ over DiffServ. RSVP is used in the examples, but NSIS could be used in the future. Start with a non-controlled-load base, and overlay with IntServ over the edges. The egress nodes identify aggregates; identifiers are not carried in the traffic. There is microflow signalling across the network, but nodes in the middle ignore it. Impementation of this idea may encourage ECN. Bob walked through some examples, which without loss of generality, assume some flows are already present in the network. The controlled load service is end-to-end, and Bob believes it is more robust than IntServ, since there is no flow signalling or state in core or border region. They've been working on it at BT since 2000. Allison asked if it was aimed at commercial networks; Bob replied that BT is working on it for its own network. To move forward two things are needed: - agreement on PHB (either new or an addition to an existing one) Would need to consider if this is a working group draft eventually. - extension for RSVP for opaque ECN fraction object Fred Baker had a couple of questions and a comment. Question1: Does this only apply where the law of large numbers applies? Bob said yes; Fred said that the places where I find myself most worrying are places where the law of large numbers doesn't apply. You should make it really clear in the draft that this is an assumption. Question2: you want to have somewhere in the RSVP message the rate of ECN you are seeing in at least some of scenarios we are looking at... domain seeing ECN will also see loss. Is there value in having the loss rate too? Bob commented that loss is hard to measure in the middle of the network, and if you have loss you'll also get high ECN markings. Comment: On numbers carried forward and opaque ECN: we have numbers like that in adspec, maybe we should extend adspec? Sally commented about loss and ECN. 3168 strongly advises routers not to use ECN when marking rate is high, but drop packets instead -- as a way to not cheat about ECN. Keep that in mind. Fred said that as one of the people that makes the routers that would like to implement ECN, that's really hard. The discussion got to a level of detail about ECN that was very interesting and the notetaker lost details. Allison had to cut off discussion as we were out of time for this topic. If the area is split, maybe there will be more breathing room for more of this detail (where implementation/deployment meet ECN, diffserv and intserv). The notetaker points out that there is an audio record for anyone who needs to bring this back. The Chair reports that there was the group discuss chartering of these documents as yet; there was too much to do just understanding the basic goals and framework. ===================== 10. Mark Watson === draft-watson-tsvwg-fec-sf-00 Mark Watson discussed a draft based on work done in 3GPP: a generic framework for FEC for media flows. The folks at 3GPP felt that it was an idea that had broad applicability so they brought it to the IETF to see if it could be used more broadly. Mark stated the objectives (see slides for detail): extend the RMT FEC building block to streaming media, provide FEC without any assumption about FEC codec, and avoid the proliferation of FEC codes. The proposal is for an FEC streaming layer above UDP that provides protection for a "bundle" of UDP flows. Mark went on to describe the idea in more depth. Two things this note taker thought were worth putting here: FEC considers symbols to be received or lost. If two packets form one symbl, losing either packets makes the symbol unintelligable and you lose. The scheme provides "close to backwards compatability": if you understand the framework, you can read the underlying data packets even if you don't understand the particular FEC coding. Mark had a number of questions for TSVWG: * When bringing this work to the IETF, they thought of AVT, but the work is not specific to RTP. They thought of RMT, but the work is not specific to multicast, although that is a use case. Hence this presentation in the more general group: do we need this kind of generic approach to streaming? In 3GPP, they evaluated 2733 and ULP, but decided they were not appropriate. * Is this the right approach? * The relationship with ULP work (in AVT) -- probably different applicability. * venue for further work? AVT, RMT or TSVWG? Matt Mathis asked how strongly this work was tied to UDP, and not a more general IP mechanism? The answer was not very strongly tied. Stefan, co-author said that UDP was used for practical reasons; it was easy to build on top of UDP. It could be built on a lower layer, but then there are other issues. Allison thought that you could provide this on DCCP or DTLS. Magnus thought the main requirement was for use in multicast environment. Allison asked if others could imagine use cases, and the value this would provide; or imagine implications in other transports. She has had private discussions with Mark, and it seems that TSVWG is more relevent than a specific group. Is there enough energy here or is it big enough that it is too big for here? Since we were now late for the coffee break, she said to think about this question, and she or Mark W. would re-ask it on the mailing list. With that, the meeting was brought to a close. -- 30 -- |