Re: [tsvwg] Warren Kumari's Discuss on draft-ietf-tsvwg-le-phb-09: (with DISCUSS and COMMENT)
Brian E Carpenter <brian.e.carpenter@gmail.com> Wed, 27 February 2019 21:44 UTC
Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8984A131169; Wed, 27 Feb 2019 13:44:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zF0uDOVqJn-Y; Wed, 27 Feb 2019 13:44:49 -0800 (PST)
Received: from mail-pf1-x42f.google.com (mail-pf1-x42f.google.com [IPv6:2607:f8b0:4864:20::42f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F71613115E; Wed, 27 Feb 2019 13:44:49 -0800 (PST)
Received: by mail-pf1-x42f.google.com with SMTP id v21so8618711pfm.12; Wed, 27 Feb 2019 13:44:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=6GrK8I4TPg41nBIGrqg9W04a0EomRJAiMLmzYehrFh0=; b=J5NNf9LHfhsSq2Bwn/u1Wn2GcbobIDZTbVlXhxOYZRuXQO0r87498KYANZBllzGPmH kc2IxEElXrg/En+fAK4RDQNkT1crwL7xlEfQe03xgYgozMxfr2SpJ6CTkH0mGaa0ycMf YsfBq4bQ1RZ/C5y9z9XQMzZP77uqSd946NMtdD6qM6MOCjwWQudugCLwskPFeVyydppl VufA6HZv9xR9+VRCAnzHNAGDAKorz50f5gRGqrICqgjLs2e5InJOhBoI24q/KwJbbxPz vZOZcFX4nHh94yFhnR+11qNStCdXM4SXkwlpn1z8TtLhaVZ/BNPiUHnd//OYTDYce3Io JNfA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=6GrK8I4TPg41nBIGrqg9W04a0EomRJAiMLmzYehrFh0=; b=XBJ4XFYpI4aBosJbZJhOIaowypcmQVEoAavAzCVEqoFsiDBgvfT6KG8OqM2PgysgyT SiMrk+tRdICkpdDcXF6Zzo1D4YKscaE937y6cRXYrbYOZPb/ppRB395I1PeFKohQL0Cm zwp0q/97EJl6sc4Vmr61K7/cAdxGLPbCQbvDY3H6kQHO2oH6KMUc5sIb6KCHdoaEKlbY 025eAYHEIgVDXoAvIGOTenuwwbEAMMZlipLGN3hDT+JBF0kWjr+//8CC8buuSPcL6tca nip0w6bhP0dVgP4c2T738CJcQa6zsL8QgtQxAMyrYZdl0uyK4A4f2yWGhdYtSVH1HNUb 6gBA==
X-Gm-Message-State: AHQUAubOmgulJEde+FZm5G5eJ9piOsUhzBYmOGJKyAHfRDNAQ5pX9wU0 czsNDbhgk9JjBZcO1XOd8JnHQ6RN
X-Google-Smtp-Source: AHgI3IZCZTBB4TbCaLlwUtHSKaq5m9HSjAi9MOwN9LpQvma1zMTa9HJysOZzGLVtleLm+BkMyevCzA==
X-Received: by 2002:a63:360e:: with SMTP id d14mr5092967pga.179.1551303888253; Wed, 27 Feb 2019 13:44:48 -0800 (PST)
Received: from [192.168.178.30] ([118.148.79.176]) by smtp.gmail.com with ESMTPSA id s80sm11759931pgs.4.2019.02.27.13.44.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 27 Feb 2019 13:44:47 -0800 (PST)
To: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>, Warren Kumari <warren@kumari.net>
Cc: tsvwg@ietf.org, "BRUNGARD, DEBORAH A" <db3546@att.com>, IESG <iesg@ietf.org>, Roland Bless <roland.bless@kit.edu>, tsvwg-chairs <tsvwg-chairs@ietf.org>
References: <155068297765.31474.15865784466149137006.idtracker@ietfa.amsl.com> <72b082d6-6d8b-5b3d-ee5e-52e5a333aacd@kit.edu> <F64C10EAA68C8044B33656FA214632C89EF79DEE@MISOUT7MSGUSRDE.ITServices.sbc.com> <f38b43e8-d300-f44f-1f84-f7652e4f36e2@kit.edu> <F64C10EAA68C8044B33656FA214632C89EF7B8F6@MISOUT7MSGUSRDE.ITServices.sbc.com> <LEJPR01MB04609C8FCFADC32676FE0AB29C7A0@LEJPR01MB0460.DEUPRD01.PROD.OUTLOOK.DE> <CAKKJt-dQjobkMSKSRenMK3VeEQeny-cZb321dEu5trYCBx5ptg@mail.gmail.com> <CAHw9_iL=aSzLWGL8R4zu1Z4QbNeFHoFgozUPANUYGatm-LpZPg@mail.gmail.com> <CAKKJt-e+6OmqG3EcGwd+92YnL-a=Ry+ymYORdwgO0cxgb1FU6Q@mail.gmail.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <ed05bc00-2532-3f45-6821-215073f49cc2@gmail.com>
Date: Thu, 28 Feb 2019 10:44:46 +1300
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1
MIME-Version: 1.0
In-Reply-To: <CAKKJt-e+6OmqG3EcGwd+92YnL-a=Ry+ymYORdwgO0cxgb1FU6Q@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/HZxbq7t59HT3x1Fc0LJSCN_rIsI>
Subject: Re: [tsvwg] Warren Kumari's Discuss on draft-ietf-tsvwg-le-phb-09: (with DISCUSS and COMMENT)
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Feb 2019 21:44:53 -0000
On 28-Feb-19 10:18, Spencer Dawkins at IETF wrote: > Hi, Warren, > > On Wed, Feb 27, 2019 at 3:10 PM Warren Kumari <warren@kumari.net> wrote: > >> >> >> On Wed, Feb 27, 2019 at 12:17 PM Spencer Dawkins at IETF < >> spencerdawkins.ietf@gmail.com> wrote: >> >>> So, just to follow up, >>> >>> On Mon, Feb 25, 2019 at 2:48 AM <Ruediger.Geib@telekom.de> wrote: >>> >>>> Deborah, Warren, >>>> >>>> IETF doesn't specify SLAs or related text, I agree. The LE performance >>>> is worse than default forwarding. I'm unhappy if my peer demotes my traffic >>>> to LE and points to an IETF standard allowing this. What about: >>>> >>>> DISCUSSED CHANGE so far: >>>> Non-LE traffic (e.g., BE traffic) SHOULD NOT be >>>> remarked to LE on a regular basis. >>>> >>>> SOMEWHAT MORE PRECISELY DEFINED OPTION >>>> Non-LE traffic (e.g., BE traffic) MUST NOT be >>>> remarked to LE by default. >>>> >>>> I'd like to avoid LE to result in a "default below default" and prefer >>>> IETF standards not allow fancy interpretations. >>>> >>> >>> This document was approved on the last telechat, but we're having a >>> Discuss-level discussion about it now, which means that I should be taking >>> this conversation very seriously (because "new technical objections are >>> always in order"). >>> >>> Am I understanding that >>> >>> - Deborah (and, IIRC, Warren) are thinking that MUST is the wrong >>> answer, because we don't tell operators how to mark traffic in their >>> networks, but >>> >>> >> Warren is thinking that, if you provide any sort of SHOULD/MUST guidance >> regarding when it is appropriate to mark "abnormal" traffic, you have to be >> able to define what you mean by normal and abnormal... >> >> Personally I would think that just: "Non-LE traffic (e.g., BE traffic) >> SHOULD NOT be remarked to LE." (or MUST NOT) without any qualifiers would >> be best -- we are not the protocol police and don't have an enforcement >> arm, so we cannot really stop it. Where I think we run into trouble is >> saying "It is OK to do this on Thursdays when there is a half moon and the >> wind blows from the South-East, but not at other times" (what if these is >> only a slight breeze? Thursday where? or a waxing gibbous moon?) - I think >> we should just say "You shouldn't remark",with the understanding that some >> will and not open the "under these circumstances" can of worms at all. >> > > Given that no one around here gets paid by the BCP14 keyword ... when I've > gotten involved in previous conversations like this, one of the ways out > was not to SHOULD/MUST at all, but to explain clearly what happens if > someone does what they SHOULD NOT/MUST NOT do. Is that more helpful, or > more unhelpful? > > I'll wait for Ruediger to surface, but I'm imagining that he might say "but > someone might say, that's only a SHOULD NOT, so I'm conforming to IETF > standards-track documents, so It Sucks To Be My Neighbor, but I don't > care". We all know that SHOULD NOT means MUST NOT unless there's a compelling reason to do otherwise, and we all know that implementers and operators have no trouble finding a compelling reason when they want to. So it actually doesn't much matter, but fwiw I'd probably prefer SHOULD NOT. Brian > > Spencer > > >> >>> - Ruediger is thinking that SHOULD is the wrong answer, because that >>> allows LE to be a "default below default"? >>> >>> W >> >> >>> Let's start and see if I got that right. >>> >>> Spencer >>> >>> >>>> Regards, >>>> >>>> Ruediger >>>> >>>> -----Ursprüngliche Nachricht----- >>>> Von: tsvwg <tsvwg-bounces@ietf.org> Im Auftrag von BRUNGARD, DEBORAH A >>>> Gesendet: Samstag, 23. Februar 2019 17:33 >>>> An: Roland Bless <roland.bless@kit.edu>; Warren Kumari < >>>> warren@kumari.net>; The IESG <iesg@ietf.org> >>>> Cc: tsvwg-chairs@ietf.org; tsvwg@ietf.org >>>> Betreff: Re: [tsvwg] Warren Kumari's Discuss on >>>> draft-ietf-tsvwg-le-phb-09: (with DISCUSS and COMMENT) >>>> >>>> Hi Roland, >>>> >>>> On your comment: >>>> "In former times P2P file sharing traffic was throttled by some ISPs >>>> without telling the users. The danger is that the same thing happens with >>>> remarking traffic as LE, so IMHO the user should be informed at least that >>>> traffic is downgraded. Maybe consent is too strong, so I propose to delete >>>> "consent", but stay with "without knowledge of the user" or I will rephrase >>>> it accordingly. However, it's still a SHOULD NOT only." >>>> >>>> I can not comment on what some ISPs do and what is in their service >>>> contracts. I am fine with this as a "SHOULD NOT". I am not fine with saying >>>> anything about what a service operator needs to do regarding a service >>>> contract. IETF hasn't in the past made these statements (btw - ITU-T does >>>> not touch this either). Hint: I don't think pointing to this RFC will help >>>> you. >>>> >>>> As Brian suggested, just keep the first part of the sentence. >>>> >>>> Thanks! >>>> Deborah >>>> >>>> >>>> -----Original Message----- >>>> From: Roland Bless <roland.bless@kit.edu> >>>> Sent: Saturday, February 23, 2019 6:30 AM >>>> To: BRUNGARD, DEBORAH A <db3546@att.com>; Warren Kumari < >>>> warren@kumari.net>; The IESG <iesg@ietf.org> >>>> Cc: tsvwg-chairs@ietf.org; tsvwg@ietf.org >>>> Subject: Re: [tsvwg] Warren Kumari's Discuss on >>>> draft-ietf-tsvwg-le-phb-09: (with DISCUSS and COMMENT) >>>> >>>> Hi Deborah, >>>> >>>> On 22.02.19 at 18:14 BRUNGARD, DEBORAH A wrote: >>>>>> The main idea is that applications/users decide what traffic should >>>> go to the "background", i.e., which packet are marked as LE (end-to-end >>>> argument as hint: the >network lacks usually the application knowledge).. >>>>> >>>>> I'll take the opportunity to jump in here😊 >>>>> >>>>> This was my comment, I was confused, as there's a couple of places in >>>> this document which infer much more than previous RFCs on what a "user" can >>>> do vs. what a network operator can do. In my comment, I noted the sentence: >>>> >>>> Sorry, for causing confusion :-) >>>> I was trying to answer the IESG comments one by one and didn't arrive at >>>> yours yet, so I also jump in. >>>> >>>>> "However, non-LE traffic (e.g., BE traffic) SHOULD NOT be remarked to >>>>> LE on a regular basis without consent or knowledge of the user." >>>>> >>>>> I scanned other RFCs, I don't see this requirement that an operator >>>> needs to have the consent/knowledge of the user before remarking? Suggest >>>> simply dropping the "without consent..." from the sentence. >>>> >>>> Your impression is probably right that this is not really consistent, >>>> because some of the text stems from RFC 3662 and some was added within this >>>> I-D. >>>> At the time of RFC 3662, the view was probably more toward: LE is mainly >>>> a tool for network operators. >>>> Yes, it is, but it's also a different question _who_ is actually >>>> deciding what traffic is classified as LE. In the light of net neutrality >>>> debates, it would be fair if the user classifies its traffic as LE if it is >>>> eligible and I find it reasonable that providers should be transparent: if >>>> they use LE as tool and downgrade users' traffic, they should say so, e..g., >>>> inform the user that they downgrade under certain conditions. >>>> >>>> In former times P2P file sharing traffic was throttled by some ISPs >>>> without telling the users. The danger is that the same thing happens with >>>> remarking traffic as LE, so IMHO the user should be informed at least that >>>> traffic is downgraded. Maybe consent is too strong, so I propose to delete >>>> "consent", but stay with "without knowledge of the user" or I will rephrase >>>> it accordingly. However, it's still a SHOULD NOT only. >>>> >>>>> And the sentence in the abstract "Ideally, applications mark their >>>> packets as LE traffic, since they know the urgency of flows." You answered >>>> Warren "The main idea is that applications/users decide what traffic should >>>> go to the "background", i.e., which packet are marked as LE (end-to-end >>>> argument..". This is very confusing as it contradicts other RFCs where >>>> marking/re-markings are tools for a network operator. >>>> >>>> Besides the net-neutrality argument, the e2e argument is another good >>>> reason to only let user decide, what should go into this class. The user >>>> cannot harm the network this way, so there is no reason for the Diffserv >>>> domain to distrust this marking coming from the end-system. >>>> For other Diffserv PHBs this IS different, because they are elevated >>>> services (i.e., better than best-effort): a Diffserv domain should either >>>> do the initial marking or at least apply policing at the ingress boundary >>>> nodes - otherwise QoS guarantees may be at risk; here the markings from >>>> end-systems cannot be trusted at least policing is required that may >>>> include re-marking. So for the EF PHB for example, admission control and >>>> policing are essential. >>>> >>>>> It directly contradicts RFC8325/section 5.4: >>>>> "An alternative option to mapping is for the administrator to treat >>>> the wireless edge as the edge of the Diffserv domain and explicitly set (or >>>> reset) DSCP markings in the upstream direction according to administrative >>>> policy. This option is RECOMMENDED over mapping, as this typically is the >>>> most secure solution because the network administrator directly enforces >>>> the Diffserv policy across the IP network (versus an application developer >>>> and/or the developer of the operating system of the wireless endpoint >>>> device, who may be functioning completely independently of the network >>>> administrator)." >>>> >>>> Yes, that's exactly what I explained in the preceding text above: >>>> normally a Diffserv domain must strictly protect its network at the >>>> boundary. >>>> >>>>> I recognize this RFC maintains "no harm" saying "There is no incentive >>>> for DS domains to distrust this initial marking, because letting LE traffic >>>> enter a DS domain causes no harm. Thus, any policing such as limiting the >>>> rate of LE traffic is not necessary at the DS boundary." I'm a bit nervous >>>> on that assumption, I think most operators would agree with Warren's title, >>>> "hysterical raisins"😊 Can IETF really maintain (this is PS), "no worries"? >>>> >>>> Maybe I don't get the point. Under the assumption that this LE traffic >>>> would have been injected as normal default BE traffic otherwise, I don't >>>> see any negative consequences for the provider. It is a different thing if >>>> the user would refrain from injecting this traffic, because he/she wants to >>>> really only transmit this as background/scavenger traffic. >>>> But compared to the alternative that this traffic would traverse the >>>> domain as BE traffic otherwise, I would confirm the "no worries" >>>> property. >>>> >>>> Best regards, >>>> Roland >>>> >>>>> -----Original Message----- >>>>> From: iesg <iesg-bounces@ietf.org> On Behalf Of Bless, Roland (TM) >>>>> Sent: Thursday, February 21, 2019 10:04 AM >>>>> To: Warren Kumari <warren@kumari.net>; The IESG <iesg@ietf.org> >>>>> Cc: David Black <david.black@dell.com>; tsvwg-chairs@ietf.org; >>>>> tsvwg@ietf.org >>>>> Subject: Re: Warren Kumari's Discuss on draft-ietf-tsvwg-le-phb-09: >>>>> (with DISCUSS and COMMENT) >>>>> >>>>> Hi Warren, >>>>> >>>>> Am 20.02.19 um 18:16 schrieb Warren Kumari: >>>>>> --------------------------------------------------------------------- >>>>>> - >>>>>> DISCUSS: >>>>>> --------------------------------------------------------------------- >>>>>> - >>>>>> >>>>>> I believe that this should be trivial DISCUSS to address, but I >>>>>> thought it important enough to warrant it. I'm OK with basically >>>>>> whatever you answer, I just wanted to make sure this had been seen >>>> and considered. >>>>>> >>>>>> "An LE PHB SHOULD NOT be used for a customer’s "normal Internet" >>>>>> traffic nor should packets be "downgraded" to the LE PHB instead of >>>>>> being dropped, particularly when the packets are unauthorized >>>>>> traffic. " >>>>> >>>>> This was actually directly copied from RFC 3662. >>>>> >>>>>> Great, sounds good to me -- but in the USA at least, there is are >>>>>> many cell phone plans which are "unlimited", but after some amount of >>>>>> traffic (e.g 22GB) your connection gets throttled to a lower data >>>>>> rate. Is this traffic still 'a customer's "normal Internet" traffic"? >>>>>> Is it appropriate (whatever that means) to downgrade this traffic to >>>>>> the LE PHB? I understand not wanting to touch this issue with a 10 >>>>>> foot pole (and I don't know what the right answer is!), but you *did* >>>>>> open this can of worms by talking about what classification user >>>> traffic should have. >>>>>> >>>>>> Note: I'm happy to clear my DISCUSS no matter what the answer is, I >>>>>> just want to make sure it has been considered / discussed. >>>>> >>>>> The main idea is that applications/users decide what traffic should go >>>> to the "background", i.e., which packet are marked as LE (end-to-end >>>> argument as hint: the network lacks usually the application knowledge). >>>>> Operators must have good reasons to deliberately downgrade users' >>>> normal traffic. In case of throttled traffic, this would still be >>>> considered as being normal BE traffic. One case for downgrading BE traffic >>>> could be non-admitted multicast replication traffic as described in RFC >>>> 3754. >>>>> >>>>>> --------------------------------------------------------------------- >>>>>> - >>>>>> COMMENT: >>>>>> --------------------------------------------------------------------- >>>>>> - >>>>>> >>>>>> Major: >>>>>> "Some network providers keep link utilization below 50% to ensure >>>>>> that all traffic is forwarded without loss after rerouting caused by >>>>>> a link failure (cf.Section 6 of [RFC3439]). LE marked traffic can >>>>>> utilize the normally unused capacity and will be preempted >>>>>> automatically in case of link failure when 100% of the link capacity >>>>>> is required for all other traffic. " Yup - very true. But I think it >>>>>> needs to be mentioned that the provider will need to upgrade their >>>>>> monitoring / management system so that they can see the traffic lass.. >>>>>> If they monitoring circuit utilization using e.g interface counters >>>>>> (and not by traffic class), a link may have 1% "real" traffic and 90% >>>>>> LE traffic, and it will look like it it 91% "full". I don't have any >>>>>> suggested text to address this (and this is just a comment, so "well, >>>>>> duh, they should know that anyway!" is a fine >>>>>> answer.) >>>>> >>>>> Thanks for the hint, valid point, but indeed: if they use Diffserv, >>>> they should also monitor the resource shares for each PHB individually. >>>>> >>>>>> Nits: >>>>>> "A main problem is that multicast" -- I'm not sure you can say "A >>>>>> main" - main implies singular.; I'd suggest "The main" or "A major". >>>>> >>>>> Right. >>>>> >>>>>> "However,using the Lower Effort PHB for multicast requires to pay >>>>>> special" -- "requires paying"... >>>>> >>>>> Done. >>>>> >>>>> Regards >>>>> Roland >>>>> >>>> >>>> >> >> -- >> I don't think the execution is relevant when it was obviously a bad idea >> in the first place. >> This is like putting rabid weasels in your pants, and later expressing >> regret at having chosen those particular rabid weasels and that pair of >> pants. >> ---maf >> >
- [tsvwg] Warren Kumari's Discuss on draft-ietf-tsv… Warren Kumari
- Re: [tsvwg] Warren Kumari's Discuss on draft-ietf… Black, David
- Re: [tsvwg] Warren Kumari's Discuss on draft-ietf… Brian E Carpenter
- Re: [tsvwg] Warren Kumari's Discuss on draft-ietf… Warren Kumari
- Re: [tsvwg] Warren Kumari's Discuss on draft-ietf… Black, David
- Re: [tsvwg] Warren Kumari's Discuss on draft-ietf… Warren Kumari
- Re: [tsvwg] Warren Kumari's Discuss on draft-ietf… Bless, Roland (TM)
- Re: [tsvwg] Warren Kumari's Discuss on draft-ietf… BRUNGARD, DEBORAH A
- Re: [tsvwg] Warren Kumari's Discuss on draft-ietf… Brian E Carpenter
- Re: [tsvwg] Warren Kumari's Discuss on draft-ietf… Roland Bless
- Re: [tsvwg] Warren Kumari's Discuss on draft-ietf… BRUNGARD, DEBORAH A
- Re: [tsvwg] Warren Kumari's Discuss on draft-ietf… Ruediger.Geib
- Re: [tsvwg] Warren Kumari's Discuss on draft-ietf… Spencer Dawkins at IETF
- Re: [tsvwg] Warren Kumari's Discuss on draft-ietf… Warren Kumari
- Re: [tsvwg] Warren Kumari's Discuss on draft-ietf… Spencer Dawkins at IETF
- Re: [tsvwg] Warren Kumari's Discuss on draft-ietf… Brian E Carpenter
- Re: [tsvwg] Warren Kumari's Discuss on draft-ietf… Bless, Roland (TM)
- Re: [tsvwg] Warren Kumari's Discuss on draft-ietf… Ruediger.Geib
- Re: [tsvwg] Warren Kumari's Discuss on draft-ietf… Spencer Dawkins at IETF
- Re: [tsvwg] Warren Kumari's Discuss on draft-ietf… Warren Kumari
- Re: [tsvwg] Warren Kumari's Discuss on draft-ietf… BRUNGARD, DEBORAH A
- Re: [tsvwg] Warren Kumari's Discuss on draft-ietf… Spencer Dawkins at IETF
- Re: [tsvwg] Warren Kumari's Discuss on draft-ietf… Gorry Fairhurst
- Re: [tsvwg] Warren Kumari's Discuss on draft-ietf… Warren Kumari
- Re: [tsvwg] Warren Kumari's Discuss on draft-ietf… BRUNGARD, DEBORAH A
- Re: [tsvwg] Warren Kumari's Discuss on draft-ietf… Spencer Dawkins at IETF
- Re: [tsvwg] Warren Kumari's Discuss on draft-ietf… Bless, Roland (TM)
- Re: [tsvwg] Warren Kumari's Discuss on draft-ietf… Ruediger.Geib
- Re: [tsvwg] Warren Kumari's Discuss on draft-ietf… Dave Taht
- Re: [tsvwg] Warren Kumari's Discuss on draft-ietf… Bless, Roland (TM)
- Re: [tsvwg] Warren Kumari's Discuss on draft-ietf… Roland Bless
- Re: [tsvwg] Warren Kumari's Discuss on draft-ietf… Black, David