From nobody Fri Sep 1 00:00:25 2017 Return-Path: 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 19906133280; Thu, 31 Aug 2017 23:59:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 khhEJ17sxwvH; Thu, 31 Aug 2017 23:59:40 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 133C7133174; Thu, 31 Aug 2017 23:59:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=46152; q=dns/txt; s=iport; t=1504249179; x=1505458779; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=OCVcTD8UJ8w/FMbswvfqL5cF+zEIAAaPxleozhQ/ZNY=; b=CKzV3cIwVpm6tHWxhioTw52d0r7CZPeF9bXqQunngALteiitIlzRl6BG QxPB1flbuJOwLInzrsUA6eCNhOnTq5B9mafEMwa2uZcZzf+0rCjAzJzi5 o4CMNr2MQummtiYTVHHvHIlBf49TB/Qr83TiBzXcDZ2AvUIc/CMsW8WET Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BvAQDvBKlZ/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhD6BFY8LkHErd4dCkAAuhRkChFEVAQIBAQEBAQEBayiFGAEBAQE?= =?us-ascii?q?CARoJTQkFCwsYIAEGAwICISURBgEMBgIBAReJfgMNCBCvXYInJ4cUDYQaAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBGAWDKoNQgWMrgXBYNYJXhTGCYQWKCJYrPIdbYYc?= =?us-ascii?q?fhHaCE4Vng1mHG4xOgQSIczUigQ0yIQgcFUmEXzkcgWk+NgWKWQEBAQ?= X-IronPort-AV: E=Sophos;i="5.41,457,1498521600"; d="scan'208,217";a="654323011" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Sep 2017 06:59:33 +0000 Received: from [10.55.221.36] (ams-bclaise-nitro3.cisco.com [10.55.221.36]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v816xXfG020836; Fri, 1 Sep 2017 06:59:33 GMT To: Spencer Dawkins at IETF , Michael Tuexen Cc: Stefan Winter , "ops-dir@ietf.org" , draft-ietf-tsvwg-sctp-ndata.all@ietf.org, "tsvwg@ietf.org" , "ietf@ietf.org" , IESG IESG References: <150287547583.12471.9085655210334710687@ietfa.amsl.com> <1a39dff3-55a9-fe1d-7e19-a0fbd0b2751b@restena.lu> <5CEB294C-AAC8-4F03-901D-487CD62BB491@fh-muenster.de> <41a1e8f1-2398-4d94-7021-638acdd58eb7@cisco.com> <1FFDADBA-4132-4D3B-B68C-A89A50AF1E24@fh-muenster.de> <0E628ABF-6E0E-40A6-87EE-CA94A93FE0A5@fh-muenster.de> From: Benoit Claise Message-ID: <78e79022-4f9b-c093-27fb-b6392d4cc689@cisco.com> Date: Fri, 1 Sep 2017 08:59:32 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------4BCF4298F57F46930484D486" Content-Language: en-US Archived-At: Subject: Re: [tsvwg] [OPS-DIR] Opsdir last call review of draft-ietf-tsvwg-sctp-ndata-12 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Sep 2017 06:59:44 -0000 This is a multi-part message in MIME format. --------------4BCF4298F57F46930484D486 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 8/31/2017 11:01 PM, Spencer Dawkins at IETF wrote: > Hi, Michael, > > On Thu, Aug 31, 2017 at 2:56 PM, Michael Tuexen > wrote: > > > > On 31. Aug 2017, at 15:46, Spencer Dawkins at IETF > > wrote: > > > > Hi, Michael, > > > > On Thu, Aug 31, 2017 at 8:25 AM, Michael Tuexen > > wrote: > > > On 31. Aug 2017, at 14:50, Spencer Dawkins at IETF > > wrote: > > > > > > Just interjecting ... > > > > > > On Thu, Aug 31, 2017 at 7:25 AM, Michael Tuexen > > wrote: > > > > > > > On 31. Aug 2017, at 14:14, Benoit Claise > wrote: > > > > > > > > Hi Michael, > > > >>> On 30. Aug 2017, at 18:51, Benoit Claise > > wrote: > > > >>> > > > >>> Michael, > > > >>> > > > >>> I stumbled on the same point as Stefan. > > > >> Hi Benoit, > > > >> > > > >> thanks for reviewing the document. See my comments in-line. > > > >> > > > >> Best regards > > > >> Michael > > > >>> First of, I had to review RFC4960 for TSN/SSN. I was not > sure whether TSN was per stream or not > > > >>> It would have helped me to repeat this information in the > intro. > > > >>> Ok, to be candid, I deduced this information from figure 1 > and 2. > > > >>>>>>> And the rest are only musings not needing any action > if the authors don't want > > > >>>>>>> to action on them: > > > >>>>>>> > > > >>>>>>> The introduction presents a good use case, quoting: > "e.g., when the > > > >>>>>>> transmission of an urgent > > > >>>>>>>  message is blocked from transmission because the > sender has started > > > >>>>>>>  the transmission of another, possibly large, message". > > > >>>>>>> > > > >>>>>>> The later queueing example in figure 1 has three SIDs > being queued > > > >>>>>>> simultanseously. It is not clear which of those "has > already started" and which > > > >>>>>> There is actually one message queued for stream 0, > three messages for stream 1, > > > >>>>>> and one message for stream 2. > > > >>>>>>> are the important ones being delayed. For a better > understanding of the reader, > > > >>>>>> The figure is about in which sequence they are put on > the wire. So no > > > >>>>>> transmission has startet. This examples also does not > deal with the case > > > >>>>>> of one stream having a higher priority than another. > That would be an > > > >>>>>> example using a priority scheduler. This examples > illustrates the round > > > >>>>>> robin scheduler. > > > >>>>>> The point here is that a single scheduler (the round > robin scheduler, for > > > >>>>>> example) behaves differently when user message > interleaving is used or not. > > > >>>>>> That is an important point: You can even use the > schedulers with regular > > > >>>>>> DATA chunk, i.e. with user message interleaving being > negotiated. > > > >>> This was my source of confusion. > > > >>> With figure 1 and figure 2, you want to show the effect of > Round Robin Scheduler with and without User Message Interleaving, > while we were expecting the figure 2 to be the solution from this > spec. Hence Stefan and I were looking for this "urgent message" in > figure 2. > > > >> I don't know what you mean with "solution from this spec" > means. This spec introduces > > > >> stream schedulers and a protocol extension to allow > interleaving of user messages. > > > >> Using this to implement an "urgent" concept is only one > possibility: usage of a > > > >> strict priority scheduler (SCTP_SS_PRIO). So this "urgent" > is misleading. It seems > > > >> to ring the wrong bells. That is why I suggested to remove > it... > > > >>>>>>> it might be useful to revise the figure so that the > head-of-line blocking > > > >>>>>>> happens for SID 1 because transmission of  0 and 2 has > already started (and > > > >>>>>>> declare SID 1 to be the "important" message). The > ASCII art would just have to > > > >>>>>>> indent SID 1 content a bit (placing 0 and 2 earlier in > time), and the resulting > > > >>>>>>> serialisation would then put all the SID 1 messages at > the very end, when 0 and > > > >>>>>>> 2 have been completely submitted (right?). > > > >>>>>> One could think about adding another example based on > the priority scheduler > > > >>>>>> and giving stream 1 a higher priority. But for > illustrating the point of > > > >>>>>> schedulers behaving differently depending on the > negotiation of user message > > > >>>>>> interleaving this seems not necessary. > > > >>>>> That second example might indeed be useful. > > > >>>>> > > > >>>>> It's simply a bit strange that in the introduction you > speak about an > > > >>>>> "urgent" message (something deserving a higher-priority > sending) and > > > >>>>> that another transmission has already started - but then > the example has > > > >>>>> none of those two. > > > >>> Exactly. > > > >>> Please add this extra example. > > > >>> This would also clarify from the introduction that when > you write ... > > > >>> > > > >>>   The sending of such large messages over > > > >>>   SCTP as specified in [RFC4960] can result in a form of > sender side > > > >>>   head of line blocking (e.g., when the transmission of an > urgent > > > >>>   message is blocked from transmission because the sender > has started > > > >>>   the transmission of another, possibly large, message). > > > >>> > > > >>> .. the notion of transmission urgency is not within a > stream but across streams, and that can be achieved with a > priority scheduler. > > > >> I would actually prefer to remove the word "urgent" from > that sentence. This just rings the wrong bells. > > > > That's a missed opportunity in mind, but your call. > > > Hmm. Let me remove the word "urgent"... > > > > > > Yes, please! I wasn't wild about it, either. > > It's done: > > > https://github.com/sctplab/sctp-idata/commit/cf7b331512cd85d6195eb88fa96360673293323f > > > > > > > >>> The text might have to be rephrased to explain that this > spec provides the ability to create stream scheduler with > different relative stream treatments. > > > >> What about: > > > >> > > > >> OLD TEXT > > > >>    This document also defines several stream schedulers for > general SCTP > > > >>    associations.  The stream schedulers may behave > differently depending > > > >>    on whether user message interleaving has been negotiated > for the > > > >>    association or not. > > > >> > > > >> NEW TEXT > > > >>    This document also defines several stream schedulers for > general SCTP > > > >>    associations allowing different relative stream treatments. > > > >>    The stream schedulers may behave differently depending > > > >>    on whether user message interleaving has been negotiated > for the > > > >>    association or not. > > > >> > > > >> Would that address this issue? > > > > ok. > > > Fixed. > > > >> > > > >>> And also that urgent message would be placed in this high > priority stream scheduler (reliable, I guess, but that's > orthogonal) stream. > > > >> I really would like to get rid of this. I don't think > giving the strict > > > >> priority scheduler as specific role here is a good idea. > > > >> > > > >> The RR scheduler was chosen as the simplest scheduler to > illustrate > > > >> that scheduler can behave differently when using > interleaving or not. > > > >>>> What about removing the word "urgent" from that sentence. > > > >>>>> In fact I wonder why you speak about urgent things in > the introduction > > > >>>>> at all. Neither the scheduler nor the interleaving are > designed to help > > > >>>>> urgent things to be sent earlier. > > > >>>>> > > > >>>>> All they do is make the transmission fairer so that > *all* chunks get a > > > >>>>> more even serialised distribution on the wire. > > > >>>> That is not true in general. If you use the priority > scheduler, one > > > >>>> stream gets preferred treatment. It also makes sure that > the time > > > >>>> of a message spent in the stream queue is shorter. So > these messages > > > >>>> get sent earlier. > > > >>>> In the case of the round robin scheduler, you are right > that this is > > > >>>> about getting fairer treatment. If you take the WFQ > scheduler, the > > > >>>> streams don't get the same treatment, but it depends on > the weight > > > >>>> given to the stream. > > > >>>>> So, rather than saying that the spec helps urgent things > to be sent > > > >>>>> earlier, it should maybe rather state that the spec > helps every message > > > >>>>> getting an equal, and equally distributed, share of the > medium. > > > >>>> It is not meant that the spec does this. It was one > example, what > > > >>>> a particular stream scheduler does. But there are > multiple schedulers > > > >>>> defined in the document. > > > >>>> > > > >>>> The RR scheduler example is not intended to illustrate > what you can do > > > >>>> with all the schedulers, but that using message > interleaving or not > > > >>>> has an impact on the scheduler. That is meant by stating: > > > >>>> > > > >>>> This document also defines several stream schedulers for > general SCTP associations. > > > >>>> The stream schedulers may behave differently depending on > whether user message > > > >>>> interleaving has been negotiated for the association or not. > > > >>>> > > > >>>> This is followed by illustrating this using the RR scheduler. > > > >>>> > > > >>>> Best regards > > > >>> Also, I don't see the value of the last sentence in this > paragraph, especially with RFC2119 MAY. > > > >>> > > > >>>   This section defines several stream schedulers.  The stream > > > >>>   schedulers may behave differently depending on whether > user message > > > >>>   interleaving has been negotiated for the association or > not.  An > > > >>>   implementation MAY implement any subset of them. > > > >> During the review the question was brought up which > scheduler have to be implemented > > > >> by an implementation. This sentence was add to address it. > > > >> If you want, I can remove it. > > > > The point is that the MAY is that sentence doesn't mean > anything. > > > > Maybe you mean: > > > > > > > > An implementation MUST implement at least one stream scheduler. > > > That would require an implementation to implement at least one of > > > the ones being listed. You are right in the sense that an > implementation > > > MUST implement at least one stream scheduler, but the original > text > > > allows that one not to be specified in this document. > > > > > > Are you saying that an implementation MUST implement one of > list defined > > > by this document? > > > > > > I'm pretty sure (and this came up in my AD review) the problem > is that the original specification DID define a stream scheduler, > that's wasn't called a stream scheduler, but SCTP implementations > did schedule streams. And that didn't matter until there was more > than one way to schedule streams (as in this document). > > The original specification did NOT specify a stream scheduler > and left this completely implementation > > specific. > > Right now Linux is using (and only supporting a single > scheduler) what we call in this document > > SCTP_SS_FCFS. FreeBSD's default scheduler is what we call in > this document SCTP_SS_RR and > > Solaris uses one of these, forgot which one. Among these kernel > implementations, only FreeBSD > > supports multiple streams schedulers and its selection. Possibly > other closed source SCTP > > implementations might support other schedulers. Don't know. > > > > Thanks for getting that right for me ... > > > > Spencer > > > >  > So you're working out better wording that says something like > "in addition to the way the original specification scheduled > streams, we're defining more of them". I think. > > I think we wanted to say something like: > > > > Here is a list of schedulers. Your implementation might support > some of them, but this is > > left open. So you can't rely on it. > > > > The list of schedulers we specified includes the ones being used > as default by FreeBSD, Linux and > > Solaris and was extended by the ones supported by FreeBSD and > the one explicitly required by > > WebRTC, which is SCTP_SS_WFQ. > > > > What about this change: > > > > OLD TEXT: > >    An implementation MAY implement any subset of them. > > > > NEW TEXT: > >    An implementation MAY implement any subset of them. If the > implementation > >    is used for WebRTC Datachannels as specified in > [I-D.ietf-rtcweb-data-channel] > >    it MUST implement the Weighted Fair Queueing Scheduler > defined in Section 3.6. > > > > That works for me, but I'll let Benoit reply. > Benoit? > > > Since I'm not sure which timezone Benoit is in (except that I know > it's Yang Central Time), I'll respond by saying that I did talk with > Benoit on the call, after sending him this privately: > > > This is tripping over the same thing I was tripping over - SCTP > standards haven't had a stream scheduler, but SCTP implementations > scheduled streams. So Michael was thinking that you were asking > about forcing existing implementations to implement one of the new > ones. > > His response was to propose text basically saying "in addition to > what you're doing now, you MAY do one or more of the following". > > I'm sorry I garbled my point so badly. > > Benoit said on the call (if I understood him correctly) that my > explanation (filtered through your correction) worked for him. The > point I was trying to make earlier was that SCTP implementations > scheduled streams somehow, and that your document wasn't an effort to > tell them to stop doing what they were doing, but that implementers > now had more standardized options than they did before. > > I think your proposed text says that well. > > At this point, I think you're ready to submit a revised ID to reflect > the comments you've received. I'll review your changes, and that will > give Benoit a chance to interrupt if he needs to - no interrupt needed. I'll trust the venerable Spencer. Regards, Benoit > he's quite responsive, especially when he doesn't spend the evening on > a telechat. > > Thanks, and it's always a pleasure. > > Spencer > > > > > Spencer > > > > Best regards > > Michael > > > > > > ? > > > > > > Spencer > > > > > > --------------4BCF4298F57F46930484D486 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 8/31/2017 11:01 PM, Spencer Dawkins at IETF wrote:
Hi, Michael,

On Thu, Aug 31, 2017 at 2:56 PM, Michael Tuexen <tuexen@fh-muenster.de> wrote:

> On 31. Aug 2017, at 15:46, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> wrote:
>
> Hi, Michael,
>
> On Thu, Aug 31, 2017 at 8:25 AM, Michael Tuexen <tuexen@fh-muenster.de> wrote:
> > On 31. Aug 2017, at 14:50, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> wrote:
> >
> > Just interjecting ...
> >
> > On Thu, Aug 31, 2017 at 7:25 AM, Michael Tuexen <tuexen@fh-muenster.de> wrote:
> >
> > > On 31. Aug 2017, at 14:14, Benoit Claise <bclaise@cisco.com> wrote:
> > >
> > > Hi Michael,
> > >>> On 30. Aug 2017, at 18:51, Benoit Claise <bclaise@cisco.com> wrote:
> > >>>
> > >>> Michael,
> > >>>
> > >>> I stumbled on the same point as Stefan.
> > >> Hi Benoit,
> > >>
> > >> thanks for reviewing the document. See my comments in-line.
> > >>
> > >> Best regards
> > >> Michael
> > >>> First of, I had to review RFC4960 for TSN/SSN. I was not sure whether TSN was per stream or not
> > >>> It would have helped me to repeat this information in the intro.
> > >>> Ok, to be candid, I deduced this information from figure 1 and 2.
> > >>>>>>> And the rest are only musings not needing any action if the authors don't want
> > >>>>>>> to action on them:
> > >>>>>>>
> > >>>>>>> The introduction presents a good use case, quoting: "e.g., when the
> > >>>>>>> transmission of an urgent
> > >>>>>>>  message is blocked from transmission because the sender has started
> > >>>>>>>  the transmission of another, possibly large, message".
> > >>>>>>>
> > >>>>>>> The later queueing example in figure 1 has three SIDs being queued
> > >>>>>>> simultanseously. It is not clear which of those "has already started" and which
> > >>>>>> There is actually one message queued for stream 0, three messages for stream 1,
> > >>>>>> and one message for stream 2.
> > >>>>>>> are the important ones being delayed. For a better understanding of the reader,
> > >>>>>> The figure is about in which sequence they are put on the wire. So no
> > >>>>>> transmission has startet. This examples also does not deal with the case
> > >>>>>> of one stream having a higher priority than another. That would be an
> > >>>>>> example using a priority scheduler. This examples illustrates the round
> > >>>>>> robin scheduler.
> > >>>>>> The point here is that a single scheduler (the round robin scheduler, for
> > >>>>>> example) behaves differently when user message interleaving is used or not.
> > >>>>>> That is an important point: You can even use the schedulers with regular
> > >>>>>> DATA chunk, i.e. with user message interleaving being negotiated.
> > >>> This was my source of confusion.
> > >>> With figure 1 and figure 2, you want to show the effect of Round Robin Scheduler with and without User Message Interleaving, while we were expecting the figure 2 to be the solution from this spec. Hence Stefan and I were looking for this "urgent message" in figure 2.
> > >> I don't know what you mean with "solution from this spec" means. This spec introduces
> > >> stream schedulers and a protocol extension to allow interleaving of user messages.
> > >> Using this to implement an "urgent" concept is only one possibility: usage of a
> > >> strict priority scheduler (SCTP_SS_PRIO). So this "urgent" is misleading. It seems
> > >> to ring the wrong bells. That is why I suggested to remove it...
> > >>>>>>> it might be useful to revise the figure so that the head-of-line blocking
> > >>>>>>> happens for SID 1 because transmission of  0 and 2 has already started (and
> > >>>>>>> declare SID 1 to be the "important" message). The ASCII art would just have to
> > >>>>>>> indent SID 1 content a bit (placing 0 and 2 earlier in time), and the resulting
> > >>>>>>> serialisation would then put all the SID 1 messages at the very end, when 0 and
> > >>>>>>> 2 have been completely submitted (right?).
> > >>>>>> One could think about adding another example based on the priority scheduler
> > >>>>>> and giving stream 1 a higher priority. But for illustrating the point of
> > >>>>>> schedulers behaving differently depending on the negotiation of user message
> > >>>>>> interleaving this seems not necessary.
> > >>>>> That second example might indeed be useful.
> > >>>>>
> > >>>>> It's simply a bit strange that in the introduction you speak about an
> > >>>>> "urgent" message (something deserving a higher-priority sending) and
> > >>>>> that another transmission has already started - but then the example has
> > >>>>> none of those two.
> > >>> Exactly.
> > >>> Please add this extra example.
> > >>> This would also clarify from the introduction that when you write ...
> > >>>
> > >>>   The sending of such large messages over
> > >>>   SCTP as specified in [RFC4960] can result in a form of sender side
> > >>>   head of line blocking (e.g., when the transmission of an urgent
> > >>>   message is blocked from transmission because the sender has started
> > >>>   the transmission of another, possibly large, message).
> > >>>
> > >>> .. the notion of transmission urgency is not within a stream but across streams, and that can be achieved with a priority scheduler.
> > >> I would actually prefer to remove the word "urgent" from that sentence. This just rings the wrong bells.
> > > That's a missed opportunity in mind, but your call.
> > Hmm. Let me remove the word "urgent"...
> >
> > Yes, please! I wasn't wild about it, either.
> It's done:
> https://github.com/sctplab/sctp-idata/commit/cf7b331512cd85d6195eb88fa96360673293323f
> >
> > >>> The text might have to be rephrased to explain that this spec provides the ability to create stream scheduler with different relative stream treatments.
> > >> What about:
> > >>
> > >> OLD TEXT
> > >>    This document also defines several stream schedulers for general SCTP
> > >>    associations.  The stream schedulers may behave differently depending
> > >>    on whether user message interleaving has been negotiated for the
> > >>    association or not.
> > >>
> > >> NEW TEXT
> > >>    This document also defines several stream schedulers for general SCTP
> > >>    associations allowing different relative stream treatments.
> > >>    The stream schedulers may behave differently depending
> > >>    on whether user message interleaving has been negotiated for the
> > >>    association or not.
> > >>
> > >> Would that address this issue?
> > > ok.
> > Fixed.
> > >>
> > >>> And also that urgent message would be placed in this high priority stream scheduler (reliable, I guess, but that's orthogonal) stream.
> > >> I really would like to get rid of this. I don't think giving the strict
> > >> priority scheduler as specific role here is a good idea.
> > >>
> > >> The RR scheduler was chosen as the simplest scheduler to illustrate
> > >> that scheduler can behave differently when using interleaving or not.
> > >>>> What about removing the word "urgent" from that sentence.
> > >>>>> In fact I wonder why you speak about urgent things in the introduction
> > >>>>> at all. Neither the scheduler nor the interleaving are designed to help
> > >>>>> urgent things to be sent earlier.
> > >>>>>
> > >>>>> All they do is make the transmission fairer so that *all* chunks get a
> > >>>>> more even serialised distribution on the wire.
> > >>>> That is not true in general. If you use the priority scheduler, one
> > >>>> stream gets preferred treatment. It also makes sure that the time
> > >>>> of a message spent in the stream queue is shorter. So these messages
> > >>>> get sent earlier.
> > >>>> In the case of the round robin scheduler, you are right that this is
> > >>>> about getting fairer treatment. If you take the WFQ scheduler, the
> > >>>> streams don't get the same treatment, but it depends on the weight
> > >>>> given to the stream.
> > >>>>> So, rather than saying that the spec helps urgent things to be sent
> > >>>>> earlier, it should maybe rather state that the spec helps every message
> > >>>>> getting an equal, and equally distributed, share of the medium.
> > >>>> It is not meant that the spec does this. It was one example, what
> > >>>> a particular stream scheduler does. But there are multiple schedulers
> > >>>> defined in the document.
> > >>>>
> > >>>> The RR scheduler example is not intended to illustrate what you can do
> > >>>> with all the schedulers, but that using message interleaving or not
> > >>>> has an impact on the scheduler. That is meant by stating:
> > >>>>
> > >>>> This document also defines several stream schedulers for general SCTP associations.
> > >>>> The stream schedulers may behave differently depending on whether user message
> > >>>> interleaving has been negotiated for the association or not.
> > >>>>
> > >>>> This is followed by illustrating this using the RR scheduler.
> > >>>>
> > >>>> Best regards
> > >>> Also, I don't see the value of the last sentence in this paragraph, especially with RFC2119 MAY.
> > >>>
> > >>>   This section defines several stream schedulers.  The stream
> > >>>   schedulers may behave differently depending on whether user message
> > >>>   interleaving has been negotiated for the association or not.  An
> > >>>   implementation MAY implement any subset of them.
> > >> During the review the question was brought up which scheduler have to be implemented
> > >> by an implementation. This sentence was add to address it.
> > >> If you want, I can remove it.
> > > The point is that the MAY is that sentence doesn't mean anything.
> > > Maybe you mean:
> > >
> > > An implementation MUST implement at least one stream scheduler.
> > That would require an implementation to implement at least one of
> > the ones being listed. You are right in the sense that an implementation
> > MUST implement at least one stream scheduler, but the original text
> > allows that one not to be specified in this document.
> >
> > Are you saying that an implementation MUST implement one of list defined
> > by this document?
> >
> > I'm pretty sure (and this came up in my AD review) the problem is that the original specification DID define a stream scheduler, that's wasn't called a stream scheduler, but SCTP implementations did schedule streams. And that didn't matter until there was more than one way to schedule streams (as in this document).
> The original specification did NOT specify a stream scheduler and left this completely implementation
> specific.
> Right now Linux is using (and only supporting a single scheduler) what we call in this document
> SCTP_SS_FCFS. FreeBSD's default scheduler is what we call in this document SCTP_SS_RR and
> Solaris uses one of these, forgot which one. Among these kernel implementations, only FreeBSD
> supports multiple streams schedulers and its selection. Possibly other closed source SCTP
> implementations might support other schedulers. Don't know.
>
> Thanks for getting that right for me ...
>
> Spencer
>
>  > So you're working out better wording that says something like "in addition to the way the original specification scheduled streams, we're defining more of them". I think.
> I think we wanted to say something like:
>
> Here is a list of schedulers. Your implementation might support some of them, but this is
> left open. So you can't rely on it.
>
> The list of schedulers we specified includes the ones being used as default by FreeBSD, Linux and
> Solaris and was extended by the ones supported by FreeBSD and the one explicitly required by
> WebRTC, which is SCTP_SS_WFQ.
>
> What about this change:
>
> OLD TEXT:
>    An implementation MAY implement any subset of them.
>
> NEW TEXT:
>    An implementation MAY implement any subset of them. If the implementation
>    is used for WebRTC Datachannels as specified in [I-D.ietf-rtcweb-data-channel]
>    it MUST implement the Weighted Fair Queueing Scheduler defined in Section 3.6.
>
> That works for me, but I'll let Benoit reply.
Benoit?

Since I'm not sure which timezone Benoit is in (except that I know it's Yang Central Time), I'll respond by saying that I did talk with Benoit on the call, after sending him this privately:

This is tripping over the same thing I was tripping over - SCTP standards haven't had a stream scheduler, but SCTP implementations scheduled streams. So Michael was thinking that you were asking about forcing existing implementations to implement one of the new ones. 

His response was to propose text basically saying "in addition to what you're doing now, you MAY do one or more of the following". 

I'm sorry I garbled my point so badly.

Benoit said on the call (if I understood him correctly) that my explanation (filtered through your correction) worked for him. The point I was trying to make earlier was that SCTP implementations scheduled streams somehow, and that your document wasn't an effort to tell them to stop doing what they were doing, but that implementers now had more standardized options than they did before.

I think your proposed text says that well. 

At this point, I think you're ready to submit a revised ID to reflect the comments you've received. I'll review your changes, and that will give Benoit a chance to interrupt if he needs to -
no interrupt needed. I'll trust the venerable Spencer.

Regards, Benoit
he's quite responsive, especially when he doesn't spend the evening on a telechat.

Thanks, and it's always a pleasure.

Spencer
 
>
> Spencer
>
> Best regards
> Michael
> >
> > ?
> >
> > Spencer
>
>



--------------4BCF4298F57F46930484D486-- From nobody Fri Sep 1 03:30:45 2017 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 88E331331A1; Fri, 1 Sep 2017 03:30:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tsvwg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.59.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150426184451.4631.12475076538959935884@ietfa.amsl.com> Date: Fri, 01 Sep 2017 03:30:44 -0700 Archived-At: Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-sctp-ndata-13.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Sep 2017 10:30:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group WG of the IETF. Title : Stream Schedulers and User Message Interleaving for the Stream Control Transmission Protocol Authors : Randall R. Stewart Michael Tuexen Salvatore Loreto Robin Seggelmann Filename : draft-ietf-tsvwg-sctp-ndata-13.txt Pages : 22 Date : 2017-09-01 Abstract: The Stream Control Transmission Protocol (SCTP) is a message oriented transport protocol supporting arbitrarily large user messages. This document adds a new chunk to SCTP for carrying payload data. This allows a sender to interleave different user messages that would otherwise result in head of line blocking at the sender. The interleaving of user messages is required for WebRTC Datachannels. Whenever an SCTP sender is allowed to send user data, it may choose from multiple outgoing SCTP streams. Multiple ways for performing this selection, called stream schedulers, are defined in this document. A stream scheduler can choose to either implement, or not implement, user message interleaving. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-ndata/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tsvwg-sctp-ndata-13 https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-sctp-ndata-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-sctp-ndata-13 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Sep 1 08:34:23 2017 Return-Path: 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 BB569133061 for ; Fri, 1 Sep 2017 08:34:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.821 X-Spam-Level: X-Spam-Status: No, score=-0.821 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dell.com header.b=r+KlxRAJ; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=qI5wfUYZ 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 FRF2DKNQ55EJ for ; Fri, 1 Sep 2017 08:34:19 -0700 (PDT) Received: from esa8.dell-outbound.iphmx.com (esa8.dell-outbound.iphmx.com [68.232.149.218]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 369D5132FE0 for ; Fri, 1 Sep 2017 08:34:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1504280059; x=1535816059; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=LkEMTjFcKQjSsYNlO6Wf96U3FHkh8VwixWXYdIAZseY=; b=r+KlxRAJm+YuMCm7HhwvCIlI+rZ7WbHAc4jWWeki0aI7ScYEq0OBNZEg nzSAK4ot/CtxtO1IYOxwDcvsQ1NLd8n7SLf7oZ+uPEXSJzxvEQ2hCBSn7 yS0HVZ+QE61yJxLzHrkKBA4BMwI0cKGgnGqsnqADZJkKBtRHSDdSqHVEq k=; Received: from esa4.dell-outbound2.iphmx.com ([68.232.154.98]) by esa8.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Sep 2017 10:34:18 -0500 From: "Black, David" Received: from mailuogwdur.emc.com ([128.221.224.79]) by esa4.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Sep 2017 21:34:18 +0600 Received: from maildlpprd54.lss.emc.com (maildlpprd54.lss.emc.com [10.106.48.158]) by mailuogwprd51.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v81FYHdc008018 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 1 Sep 2017 11:34:17 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com v81FYHdc008018 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1504280057; bh=KE6dzFo9LtTKDRtTKJT01Pu9qaA=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=qI5wfUYZmwNf3ADmnzy4IsT/R8GHZY2Eaqbx83CPArLd+R8sZx57ySsLJ92o0bgSw flQDoQuj8rNlk1kpy329QN42Yc6p2Ofr4Y6pCFDNOgDi6fHSju6hHCVGe0JkiMPDqY ao330Fs6MF3QyPmzgKjtN123KVKorqPZGIAEsojU= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com v81FYHdc008018 Received: from mailusrhubprd53.lss.emc.com (mailusrhubprd53.lss.emc.com [10.106.48.18]) by maildlpprd54.lss.emc.com (RSA Interceptor) for ; Fri, 1 Sep 2017 11:33:43 -0400 Received: from MXHUB305.corp.emc.com (MXHUB305.corp.emc.com [10.146.3.31]) by mailusrhubprd53.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v81FY1ow030695 (version=TLSv1.2 cipher=AES128-SHA256 bits=128 verify=FAIL) for ; Fri, 1 Sep 2017 11:34:01 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB305.corp.emc.com ([10.146.3.31]) with mapi id 14.03.0352.000; Fri, 1 Sep 2017 11:34:00 -0400 To: "tsvwg@ietf.org" Thread-Topic: draft-ietf-tsvwg-tunnel-congestion-feedback - update Thread-Index: AdMjN7swOWLmBVbyRDOxKO/ZV/+c2Q== Date: Fri, 1 Sep 2017 15:34:00 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.44.126] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd53.lss.emc.com X-RSA-Classifications: public Archived-At: Subject: [tsvwg] draft-ietf-tsvwg-tunnel-congestion-feedback - update X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Sep 2017 15:34:21 -0000 QmFzZWQgb24gZGlzY3Vzc2lvbiBpbiBQcmFndWUgYW1vbmcgdGhlIFRTVldHIGNoYWlycyBhbmQg dGhlIEFEcywgdGhpcyBkcmFmdCBpcyBiZWluZyByZXR1cm5lZCB0byB0aGUgV0cgZm9yIGZ1cnRo ZXIgd29yayBiZWNhdXNlIHRoZSBjb25jZXJucyBhcm91bmQgaW50ZXJhY3Rpb24gd2l0aCBleGlz dGluZyBjb25nZXN0aW9uIGNvbnRyb2wgbmVlZCBzb21lIHNlcmlvdXMgdGVjaG5pY2FsIGF0dGVu dGlvbi4NCg0KSW4gb3JkZXIgZm9yIHRoaXMgZHJhZnQgdG8gbW92ZSBmb3J3YXJkLCBpdCB3aWxs IGJlIG5lY2Vzc2FyeSB0byBhZGRyZXNzIHByYWN0aWNhbCB1c2Ugb2YgdGhpcyB0dW5uZWwgY29u Z2VzdGlvbiBmZWVkYmFjayBtZWNoYW5pc20sIGluY2x1ZGluZyB3cml0aW5nIHVwIGF0IGxlYXN0 IG9uZSBjb21wbGV0ZSBleGFtcGxlIG9mIGl0cyB1c2UgaW4gdGhlIGJvZHkgb2YgdGhlIGRyYWZ0 IG9yIGFuIGFwcGVuZGl4LiAgDQoNClRoYW5rcywgLS1EYXZpZA0KDQotLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KRnJvbTogSUVURiBTZWNyZXRhcmlhdCBbbWFpbHRvOmlldGYtc2VjcmV0YXJp YXQtcmVwbHlAaWV0Zi5vcmddIA0KU2VudDogRnJpZGF5LCBTZXB0ZW1iZXIgMSwgMjAxNyAxMToy OSBBTQ0KVG86IEJsYWNrLCBEYXZpZCA8ZGF2aWQuYmxhY2tAZW1jLmNvbT47IGRyYWZ0LWlldGYt dHN2d2ctdHVubmVsLWNvbmdlc3Rpb24tZmVlZGJhY2tAaWV0Zi5vcmc7IHRzdndnLWNoYWlyc0Bp ZXRmLm9yZw0KU3ViamVjdDogSUVURiBXRyBzdGF0ZSBjaGFuZ2VkIGZvciBkcmFmdC1pZXRmLXRz dndnLXR1bm5lbC1jb25nZXN0aW9uLWZlZWRiYWNrDQoNCg0KVGhlIElFVEYgV0cgc3RhdGUgb2Yg ZHJhZnQtaWV0Zi10c3Z3Zy10dW5uZWwtY29uZ2VzdGlvbi1mZWVkYmFjayBoYXMgYmVlbg0KY2hh bmdlZCB0byAiV0cgRG9jdW1lbnQiIGZyb20gIldhaXRpbmcgZm9yIFdHIENoYWlyIEdvLUFoZWFk IiBieSBEYXZpZCBCbGFjazoNCg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtaWV0Zi10c3Z3Zy10dW5uZWwtY29uZ2VzdGlvbi1mZWVkYmFjay8NCg0K From nobody Fri Sep 1 08:42:52 2017 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 956C9133175 for ; Fri, 1 Sep 2017 08:42:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.59.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150428057160.3237.13257355423560512730.idtracker@ietfa.amsl.com> Date: Fri, 01 Sep 2017 08:42:51 -0700 From: IETF Secretariat Archived-At: Subject: [tsvwg] Milestones changed for tsvwg WG X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Sep 2017 15:42:52 -0000 Changed milestone "Submit "Guidelines for DiffServ to IEEE 802.11 Mapping" as a Proposed Standard RFC", set state to active from review, accepting new milestone. Changed milestone "Submit " Transport Options for UDP" as a Proposed Standard RFC", set state to active from review, accepting new milestone. Changed milestone "Submit "Forward Error Correction (FEC) Framework Extension to Sliding Window Codes" as a Proposed Standard RFC", set state to active from review, accepting new milestone. Changed milestone "Submit "Sliding Window Random Linear Code (RLC) Forward Erasure Correction (FEC) Scheme for FECFRAME" as a Proposed Standard RFC", set state to active from review, accepting new milestone. Changed milestone "Submit "Low Latency, Low Loss, Scalable Throughput (L4S) Internet Service: Architecture" as an Informational RFC", set state to active from review, accepting new milestone. Changed milestone "Submit "DualQ Coupled AQM for Low Latency, Low Loss and Scalable Throughput" as an Experimental RFC", set state to active from review, accepting new milestone. Changed milestone "Submit "Identifying Modified Explicit Congestion Notification (ECN) Semantics for Ultra-Low Queuing Delay" as an Experimental RFC", set state to active from review, accepting new milestone. URL: https://datatracker.ietf.org/wg/tsvwg/about/ From nobody Fri Sep 1 13:22:58 2017 Return-Path: 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 6463B1343B9; Fri, 1 Sep 2017 13:22:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.799 X-Spam-Level: X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 L-eafzR0eFNL; Fri, 1 Sep 2017 13:22:53 -0700 (PDT) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (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 0BAAC1344A0; Fri, 1 Sep 2017 13:22:53 -0700 (PDT) Received: by mail-yw0-x233.google.com with SMTP id h127so5988965ywf.3; Fri, 01 Sep 2017 13:22:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=21bqjA0clXl7xx9uJAzIltJd1R3yEfquXjjTzYDIhTE=; b=CVOO2rFI907W6msJ4N/x7aX/2vbT6a78+eVA8tmOAaCI+qpTpwsNI0q+MJjmm5LErh nE00D7zKqVLSOnHpYvxT+W1JBF4m7E9W+joqset2FUuYMsJbdFXCfB/3tHOYIzj6fOJe CqUGFVR0aE9bUisYcROlpGk+HYMKZuWNxzqaH7jN6SOYs/EXs6x3Q0Iz8mJ0dsRlusOQ yeHAr7Dn/7+1JZrSlAhiFcOEz6ajyj+GJydQtnFUAmb99uufqfg/Iq5d8uxLIxAq80Pz CfKfd8pZF5fPXWyAb6Y8ppogE4AKJqBfxPKjhq2TzyQt9LxVvElgpYojUiC2UyBiNap8 Asng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=21bqjA0clXl7xx9uJAzIltJd1R3yEfquXjjTzYDIhTE=; b=THzLnanmI25o2GXfDspQ72klw4nuenoGFXNXn4chMKBT5rL8K2wO4oaGsYGqsxj0I1 qDr5UHy01SVp3kYFCidwERYbLnpTz9d3aV5SI25mx9Q/Z6LiEjdVdGQake3q1k4LwbW3 yIt/8yxB7GzrNnK2AzLQUx2hiwUVol+0JvWrDvlIl8FvogeF57Us2hEVB8Ku0TbaIzkn C5sj0xxx0y7uFWV3zYjOwGcX2BdHL0WcjA03l2Iw7CGvQ97HZofATZ3NYdwn6ATYLowH v7aHjgbGFrGYB0mBikNIeLzpQbJGy5Zv2EvdqnepHX9cissT30sTvNTBefG/0LWX/6oj BIyg== X-Gm-Message-State: AHPjjUhdlyf19fLvzuVWmrljdtEqpBVTE/joiXZ/ssyU6YUzrCirPY2M 6UWyJ6kFI8tBnZvSCkCzqgmSlm/+wQ== X-Google-Smtp-Source: ADKCNb45QdPI8rbBqixy+dSStWXsUXS8j/jPx1UA+kThhPfn5kwRa1ulA7nP915+km9CEPJvzkJxmtUeC2SVTzBL1io= X-Received: by 10.37.207.139 with SMTP id f133mr2614813ybg.75.1504297371963; Fri, 01 Sep 2017 13:22:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.2.148 with HTTP; Fri, 1 Sep 2017 13:22:51 -0700 (PDT) In-Reply-To: References: <150377526319.25828.13085691478621902018.idtracker@ietfa.amsl.com> <6B8221AA-0A42-4409-BDA9-63215B0789F2@fh-muenster.de> <7C366691-31F9-44B3-AF7A-F877B13EF27A@fh-muenster.de> <68C4E71D-B044-4DC3-B570-97C0AD0578F6@fh-muenster.de> From: Spencer Dawkins at IETF Date: Fri, 1 Sep 2017 15:22:51 -0500 Message-ID: To: Michael Tuexen Cc: Eric Rescorla , Gorry Fairhurst , draft-ietf-tsvwg-sctp-ndata@ietf.org, The IESG , "tsvwg@ietf.org" , "tsvwg-chairs@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c05c7a87e1618055826862b" Archived-At: Subject: Re: [tsvwg] Eric Rescorla's No Objection on draft-ietf-tsvwg-sctp-ndata-12: (with COMMENT) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Sep 2017 20:22:56 -0000 --94eb2c05c7a87e1618055826862b Content-Type: text/plain; charset="UTF-8" Hi, Eric, On Wed, Aug 30, 2017 at 8:11 AM, Michael Tuexen wrote: > > > On 29. Aug 2017, at 15:09, Eric Rescorla wrote: > > > > > > > > On Tue, Aug 29, 2017 at 12:24 AM, Michael Tuexen > wrote: > > > On 29. Aug 2017, at 01:04, Eric Rescorla wrote: > > > > > > > > > > > > On Mon, Aug 28, 2017 at 3:39 PM, Michael Tuexen > wrote: > > > > On 28. Aug 2017, at 22:56, Eric Rescorla wrote: > > > > > > > > > > > > > > > > On Mon, Aug 28, 2017 at 1:42 PM, Michael Tuexen < > tuexen@fh-muenster.de> wrote: > > > > > On 26. Aug 2017, at 21:21, Eric Rescorla wrote: > > > > > > > > > > Eric Rescorla has entered the following ballot position for > > > > > draft-ietf-tsvwg-sctp-ndata-12: No Objection > > > > > > > > > > When responding, please keep the subject line intact and reply to > all > > > > > email addresses included in the To and CC lines. (Feel free to cut > this > > > > > introductory paragraph, however.) > > > > > > > > > > > > > > > Please refer to https://www.ietf.org/iesg/ > statement/discuss-criteria.html > > > > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > > > > > > > > > > The document, along with other ballot positions, can be found here: > > > > > https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-ndata/ > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------ > ---------- > > > > > COMMENT: > > > > > ------------------------------------------------------------ > ---------- > > > > > > > > > Hi Eric, > > > > > > > > thanks for the review. See my responses in-line. > > > > > > > > Best regards > > > > Michael > > > > > TECHNICAL > > > > > I'm not sure I am following the rules about interleaving multiple > > > > > messages in the same flight. > > > > > > > > > > The sender MUST NOT fragment more than one user message in any > given > > > > > stream at any time. At any time, a sender MAY fragment multiple > user > > > > > messages, each of them on different streams. > > > > > > > > > > So, say I have one stream and the application sends M1 and M2 and > both > > > > > need to be fragmented, so I have M1a, M1b and M2a and M2b. Does > this > > > > > mean that I can't send M2a until M1{a,b} has been acknowledged? > > > > No, that is not what is meant. > > > > > > > > Assume M1 is sent before M2 and you end up in M1a (first fragment), > > > > M1b (second fragment), M2a (first fragment) and M2b (second > fragment). > > > > You would assign the TSNs in a way that they are increasing for > > > > M1a, M1b, M2a, and M2b. So you are not interleaving messages on > > > > the same stream. That is the point. So you would not send them as > > > > M1a, M2a, M2b, M1b. You should also not send M1a, M2, M1b (assuming > > > > that M2 doesn't need to be fragmented). > > > > > > > > I agree, the above text is not as clear as possible. So what about > stating > > > > it as: > > > > > > > > The sender MUST NOT assign TSNs to more than one user message in > any given > > > > stream at any time. At any time, a sender MAY assign TSNs to > multiple user > > > > messages, each of them on different streams. > > > > > > > > Perhaps you might instead say: > > > > > > > > The user messages within a given stream must have strictly > increasing TSNs > > > Not sure what you are suggesting, since TSN are assigned to chunks, not > > > user messages. > > > > > > The problem here is that your text focuses on TSN *assignment* which > is not > > > really the relevant property (it's an implementation artifact) rather > what appears > > > on the wire is. So, the requirement here seems to be that you allocate > TSNs > > > to fragments of user messages in order. > > The next sentence in the document states: > > > > The sender MUST assign TSNs in a way that the receiver can make progress. > > One way to achieve this is to assign a higher TSN to the later fragments > of > > a user message and send out the TSNs in sequence. > > > > The reason not to mandate this is that you might you more complex schemes > > in case of load-sharing between multiple paths. > > > > That's fine, but I don't find the current text clear and this doesn't > help. Why don't > > you try listing the requirements on what appears on the wire from the > receiver's > > perspective in response to this message, and then we can discuss how to > > write it in the doc. > Let me make another suggestion: > > OLD TEXT: > > The sender MUST NOT fragment more than one user message in any given > stream at any time. At any time, a sender MAY fragment multiple user > messages, each of them on different streams. > > The sender MUST assign TSNs in a way that the receiver can make > progress. One way to achieve this is to assign a higher TSN to the > later fragments of a user message and send out the TSNs in sequence. > > > NEW TEXT: > > The sender MUST NOT process (move user data into I-DATA chunks and > assign > a TSN to it) for more than one user message in any given stream at any > time. > At any time, a sender MAY process multiple user messages, each of them > on > different streams. > > The sender MUST assign TSNs to I-DATA chunks in a way that the receiver > can make progress. One way to achieve this is to assign a higher TSN > to the > later fragments of a user message and send out the I-DATA chunks such > that > the TSNs are in sequence. > > Does that address your issue? > Michael has submitted -13 which includes this text. Diff is at https://tools.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-sctp-ndata-13.txt. I'm planning to send an Approved notice for -13. If you see a problem, please let me know. Thanks, Spencer > > Best regards > Michael > > > > -Ekr > > > > > > > > > > > Just considering the simple case of non-fragmented user > > > messages, you can't guarantee that user messages of a particular stream > > > have increasing TSNs, since there can be wrap arounds due to chunks > > > belonging to other streams. The TSN are 32-bit numbers with serial > arithmetic... > > > > > > Hmm... You don't think of these as being infinite precision but taken > mod 2^32? > > In most cases, yes. But I need to take into account that the numbers can > wrap > > and how this is handled by receivers. That is why the document states > some > > limitations you the number of outstanding MIDs and FSNs. > > > > Best regards > > Michael > > > > > > -Ekr > > > > > > > > > > > > > > > Best regards > > > Michael > > > > > > > > > > > > > > > > > use MID to reassemble correctly. And given this requirement, why do > > > > > you need MID? > > > > You need some id to know which fragments belong to the same > > > > user message. You can't derive that from the TSN. > > > > > > > > Yeah, I thought you could but after some thought I see you cannot. > > > > > > > > > > > > -Ekr > > > > > > > > > Because fragementation is indicated by index, not range, > > > > > what happens if you have to reduce MTU? So, say I have a message of > > > > > size 2K which I fragment into 1K/1K and then I have to decrease > > > > > my MTU to 512 bytes? > > > > SCTP can't adopt, so IP fragmentation will be used. > > > > > > > > The reason is that once you sent a DATA chunk or an I-DATA chunk > > > > you assigned a TSN will is used for reliable transfer. So you > > > > have to retransmit it and you can't change the user data contained > > > > in it. This has not changed from the base spec. > > > > > > > > Changing the information from index to range for handling reassembly > > > > would not really help, since you still do reliable transfer by using > the > > > > TSN assigned to the DATA or I-DATA chunk and you need to retransmit > it. > > > > > > > > > > > > > > > EDITORIAL > > > > > I think it would be helpful to indicate that B has to be > > > > > set for the first chunk in S 2.1. Or perhaps move the overview of > > > > > how the sender behaves in S 2.2.2 up in the document? > > > > Considering this comment and the ones I got from other people > > > > it seems like referring to RFC 4960 and RFC 7053 for the fields > > > > which haven't changed and only describing the new fields doesn't > > > > seem to work well. > > > > > > > > I'll add text describing the "old fields". > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --94eb2c05c7a87e1618055826862b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Eric,

On Wed, Aug 30, 2017 at 8:11 AM, Michael Tuexen = <tuexen@fh-mu= enster.de> wrote:

> On 29. Aug 2017, at 15:09, Eric Rescorla <ekr@rtfm.com> wrote:
>
>
>
> On Tue, Aug 29, 2017 at 12:24 AM, Michael Tuexen <tuexen@fh-muenster.de> wrote:
> > On 29. Aug 2017, at 01:04, Eric Rescorla <ekr@rtfm.com> wrote:
> >
> >
> >
> > On Mon, Aug 28, 2017 at 3:39 PM, Michael Tuexen <tuexen@fh-muenster.de> wrote:
> > > On 28. Aug 2017, at 22:56, Eric Rescorla <ekr@rtfm.com> wrote:
> > >
> > >
> > >
> > > On Mon, Aug 28, 2017 at 1:42 PM, Michael Tuexen <tuexen@fh-muenster.de> wrote:
> > > > On 26. Aug 2017, at 21:21, Eric Rescorla <ekr@rtfm.com> wrote:
> > > >
> > > > Eric Rescorla has entered the following ballot position= for
> > > > draft-ietf-tsvwg-sctp-ndata-12: No Objection
> > > >
> > > > When responding, please keep the subject line intact an= d reply to all
> > > > email addresses included in the To and CC lines. (Feel = free to cut this
> > > > introductory paragraph, however.)
> > > >
> > > >
> > > > Please refer to https:/= /www.ietf.org/iesg/statement/discuss-criteria.html
> > > > for more information about IESG DISCUSS and COMMENT pos= itions.
> > > >
> > > >
> > > > The document, along with other ballot positions, can be= found here:
> > > > https://datatracker= .ietf.org/doc/draft-ietf-tsvwg-sctp-ndata/
> > > >
> > > >
> > > >
> > > > --------------------------------------------------= --------------------
> > > > COMMENT:
> > > > --------------------------------------------------= --------------------
> > > >
> > > Hi Eric,
> > >
> > > thanks for the review. See my responses in-line.
> > >
> > > Best regards
> > > Michael
> > > > TECHNICAL
> > > > I'm not sure I am following the rules about interle= aving multiple
> > > > messages in the same flight.
> > > >
> > > >=C2=A0 =C2=A0The sender MUST NOT fragment more than one = user message in any given
> > > >=C2=A0 =C2=A0stream at any time.=C2=A0 At any time, a se= nder MAY fragment multiple user
> > > >=C2=A0 =C2=A0messages, each of them on different streams= .
> > > >
> > > > So, say I have one stream and the application sends M1 = and M2 and both
> > > > need to be fragmented, so I have M1a, M1b and M2a and M= 2b. Does this
> > > > mean that I can't send M2a until M1{a,b} has been a= cknowledged?
> > > No, that is not what is meant.
> > >
> > > Assume M1 is sent before M2 and you end up in M1a (first fra= gment),
> > > M1b (second fragment), M2a (first fragment) and M2b (second = fragment).
> > > You would assign the TSNs in a way that they are increasing = for
> > > M1a, M1b, M2a, and M2b. So you are not interleaving messages= on
> > > the same stream. That is the point. So you would not send th= em as
> > > M1a, M2a, M2b, M1b. You should also not send M1a, M2, M1b (a= ssuming
> > > that M2 doesn't need to be fragmented).
> > >
> > > I agree, the above text is not as clear as possible. So what= about stating
> > > it as:
> > >
> > >=C2=A0 =C2=A0The sender MUST NOT assign TSNs to more than one= user message in any given
> > >=C2=A0 =C2=A0stream at any time.=C2=A0 At any time, a sender = MAY assign TSNs to multiple user
> > >=C2=A0 =C2=A0messages, each of them on different streams.
> > >
> > > Perhaps you might instead say:
> > >
> > > The user messages within a given stream must have strictly i= ncreasing TSNs
> > Not sure what you are suggesting, since TSN are assigned to chunk= s, not
> > user messages.
> >
> > The problem here is that=C2=A0 your text focuses on TSN *assignme= nt* which is not
> > really the relevant property (it's an implementation artifact= ) rather what appears
> > on the wire is. So, the requirement here seems to be that you all= ocate TSNs
> > to fragments of user messages in order.
> The next sentence in the document states:
>
> The sender MUST assign TSNs in a way that the receiver can make progre= ss.
> One way to achieve this is to assign a higher TSN to the later fragmen= ts of
> a user message and send out the TSNs in sequence.
>
> The reason not to mandate this is that you might you more complex sche= mes
> in case of load-sharing between multiple paths.
>
> That's fine, but I don't find the current text clear and this = doesn't help. Why don't
> you try listing the requirements on what appears on the wire from the = receiver's
> perspective in response to this message, and then we can discuss how t= o
> write it in the doc.
Let me make another suggestion:

OLD TEXT:

=C2=A0 =C2=A0The sender MUST NOT fragment more than one user message in any= given
=C2=A0 =C2=A0stream at any time.=C2=A0 At any time, a sender MAY fragment m= ultiple user
=C2=A0 =C2=A0messages, each of them on different streams.

=C2=A0 =C2=A0The sender MUST assign TSNs in a= way that the receiver can make
=C2=A0 =C2=A0progress.=C2=A0 One way to achieve this is to assign a higher = TSN to the
=C2=A0 =C2=A0later fragments of a user message and send out the TSNs in seq= uence.


NEW TEXT:

=C2=A0 =C2=A0The sender MUST NOT process (move user data into I-DATA chunks= and assign
=C2=A0 =C2=A0a TSN to it) for more than one user message in any given strea= m at any time.
=C2=A0 =C2=A0At any time, a sender MAY process multiple user messages, each= of them on
=C2=A0 =C2=A0different streams.

=C2=A0 =C2=A0The sender MUST assign TSNs to I-DATA chunks in a way that the= receiver
=C2=A0 =C2=A0can make progress.=C2=A0 One way to ach= ieve this is to assign a higher TSN to the
=C2=A0 =C2=A0later fragments of a user message and send out the I-DA= TA chunks such that
=C2=A0 =C2=A0the TSNs are in sequence.

Does that address your issue?

Michael h= as submitted -13 which includes this text. Diff is at=C2=A0https:= //tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-tsvwg-sctp-ndata-13.txt.

I'm planning to send an Approved notice for -13. = If you see a problem, please let me know.

Thanks,<= /div>

Spencer
=C2=A0

Best regards
Michael
>
> -Ekr
>
> >
> >
> > Just considering the simple case of non-fragmented user
> > messages, you can't guarantee that user messages of a particu= lar stream
> > have increasing TSNs, since there can be wrap arounds due to chun= ks
> > belonging to other streams. The TSN are 32-bit numbers with seria= l arithmetic...
> >
> > Hmm... You don't think of these as being infinite precision b= ut taken mod 2^32?
> In most cases, yes. But I need to take into account that the numbers c= an wrap
> and how this is handled by receivers. That is why the document states = some
> limitations you the number of outstanding MIDs and FSNs.
>
> Best regards
> Michael
> >
> > -Ekr
> >
> >
> >
> >
> > Best regards
> > Michael
> > >
> > >
> > >
> > > > use MID to reassemble correctly. And given this require= ment, why do
> > > > you need MID?
> > > You need some id to know which fragments belong to the same<= br> > > > user message. You can't derive that from the TSN.
> > >
> > > Yeah, I thought you could but after some thought I see you c= annot.
> > >
> > >
> > > -Ekr
> > >
> > > > Because fragementation is indicated by index, not range= ,
> > > > what happens if you have to reduce MTU? So, say I have = a message of
> > > > size 2K which I fragment into 1K/1K and then I have to = decrease
> > > > my MTU to 512 bytes?
> > > SCTP can't adopt, so IP fragmentation will be used.
> > >
> > > The reason is that once you sent a DATA chunk or an I-DATA c= hunk
> > > you assigned a TSN will is used for reliable transfer. So yo= u
> > > have to retransmit it and you can't change the user data= contained
> > > in it. This has not changed from the base spec.
> > >
> > > Changing the information from index to range for handling re= assembly
> > > would not really help, since you still do reliable transfer = by using the
> > > TSN assigned to the DATA or I-DATA chunk and you need to ret= ransmit it.
> > > >
> > > >
> > > > EDITORIAL
> > > > I think it would be helpful to indicate that B has to b= e
> > > > set for the first chunk in S 2.1. Or perhaps move the o= verview of
> > > > how the sender behaves in S 2.2.2 up in the document? > > > Considering this comment and the ones I got from other peopl= e
> > > it seems like referring to RFC 4960 and RFC 7053 for the fie= lds
> > > which haven't changed and only describing the new fields= doesn't
> > > seem to work well.
> > >
> > > I'll add text describing the "old fields".
> > > >
> > > >
> > >
> > >
> >
> >
>
>


--94eb2c05c7a87e1618055826862b-- From nobody Fri Sep 1 13:31:53 2017 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BA8B134437 for ; Fri, 1 Sep 2017 13:31:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.59.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150429791230.6539.1116304409960929181.idtracker@ietfa.amsl.com> Date: Fri, 01 Sep 2017 13:31:52 -0700 From: IETF Secretariat Archived-At: Subject: [tsvwg] Milestones changed for tsvwg WG X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Sep 2017 20:31:52 -0000 Changed milestone "Submit "Sliding Window Random Linear Code (RLC) Forward Erasure Correction (FEC) Scheme for FECFRAME" as a Proposed Standard RFC", added draft-ietf-tsvwg-rlc-fec-scheme to milestone. URL: https://datatracker.ietf.org/wg/tsvwg/about/ From nobody Fri Sep 1 13:52:02 2017 Return-Path: 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 421BA132EF8 for ; Fri, 1 Sep 2017 13:52:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.821 X-Spam-Level: X-Spam-Status: No, score=-0.821 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dell.com header.b=m/6V+LNJ; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=VJlBm1/v 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 4rCJFFMeAPuu for ; Fri, 1 Sep 2017 13:51:58 -0700 (PDT) Received: from esa8.dell-outbound.iphmx.com (esa8.dell-outbound.iphmx.com [68.232.149.218]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 952E2133218 for ; Fri, 1 Sep 2017 13:51:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1504299118; x=1535835118; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=jtGzHWukGPoyNi7uiKRl84hR1StRZtaRlTmp5KZB57E=; b=m/6V+LNJVWW1mYmZd5Zob8NSvlV1SDT1KeOoywL4wu9lVl0gPEIw7B65 Dm60rlyir0DBsldN/XtpoQE5jLKewuYZ/H0xY/xPMp4BUmwsz11qJq/Oy gF9kEUSDv4m04id9GZkjRoJ/XHIx75kiluD9ToiqtBKZJ3VCDObovSzpV A=; Received: from esa3.dell-outbound2.iphmx.com ([68.232.154.63]) by esa8.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Sep 2017 15:51:58 -0500 From: "Black, David" Received: from mailuogwdur.emc.com ([128.221.224.79]) by esa3.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Sep 2017 02:42:17 +0600 Received: from maildlpprd51.lss.emc.com (maildlpprd51.lss.emc.com [10.106.48.155]) by mailuogwprd52.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v81KpuDB024694 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 1 Sep 2017 16:51:56 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com v81KpuDB024694 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1504299117; bh=GyEEOWKC8yQLHdzKyi9pqtZeMmY=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=VJlBm1/vt5zr91YoJYObSNu5ZZPTR+mJW3Ok9VkfTd/Zpu+xIjjXyKSO6cgYH87ax KRDvumkClVZSSPkc8+vhyn4k/ejzQg66Wdbwxa827V3Hz0h7qtTHvMvbVfjWSZ/k9N y0T7/zY97xC00MFfeKTuOnlM0MlLeLrEaWLYXTR4= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com v81KpuDB024694 Received: from mailusrhubprd02.lss.emc.com (mailusrhubprd02.lss.emc.com [10.253.24.20]) by maildlpprd51.lss.emc.com (RSA Interceptor) for ; Fri, 1 Sep 2017 16:51:44 -0400 Received: from MXHUB306.corp.emc.com (MXHUB306.corp.emc.com [10.146.3.32]) by mailusrhubprd02.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v81Kpkb9002683 (version=TLSv1.2 cipher=AES128-SHA256 bits=128 verify=FAIL) for ; Fri, 1 Sep 2017 16:51:46 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB306.corp.emc.com ([10.146.3.32]) with mapi id 14.03.0352.000; Fri, 1 Sep 2017 16:51:45 -0400 To: "tsvwg@ietf.org" Thread-Topic: [tsvwg] Milestones changed for tsvwg WG Thread-Index: AQHTI2FbxEdRLBYEDUajyZp07ESN7KKgflTQ Date: Fri, 1 Sep 2017 20:51:45 +0000 Message-ID: References: <150429791230.6539.1116304409960929181.idtracker@ietfa.amsl.com> In-Reply-To: <150429791230.6539.1116304409960929181.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.44.126] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd02.lss.emc.com X-RSA-Classifications: public Archived-At: Subject: Re: [tsvwg] Milestones changed for tsvwg WG X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Sep 2017 20:52:00 -0000 VGhpcyBhbmQgdGhlIHByZXZpb3VzIG1lc3NhZ2Ugb24gbWlsZXN0b25lIGNoYW5nZXMgcmVmbGVj dCBuZXcgbWlsZXN0b25lcyBhZGRlZCBmcm9tIHRoZSBQcmFndWUgbWVldGluZy4gICANCg0KVGhh bmtzLCAtLURhdmlkDQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiB0 c3Z3ZyBbbWFpbHRvOnRzdndnLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBJRVRGIFNl Y3JldGFyaWF0DQo+IFNlbnQ6IEZyaWRheSwgU2VwdGVtYmVyIDEsIDIwMTcgNDozMiBQTQ0KPiBU bzogdHN2d2dAaWV0Zi5vcmcNCj4gU3ViamVjdDogW3RzdndnXSBNaWxlc3RvbmVzIGNoYW5nZWQg Zm9yIHRzdndnIFdHDQo+IA0KPiBDaGFuZ2VkIG1pbGVzdG9uZSAiU3VibWl0ICJTbGlkaW5nIFdp bmRvdyBSYW5kb20gTGluZWFyIENvZGUgKFJMQykgRm9yd2FyZA0KPiBFcmFzdXJlIENvcnJlY3Rp b24gKEZFQykgU2NoZW1lIGZvciBGRUNGUkFNRSIgYXMgYSBQcm9wb3NlZCBTdGFuZGFyZCBSRkMi LA0KPiBhZGRlZCBkcmFmdC1pZXRmLXRzdndnLXJsYy1mZWMtc2NoZW1lIHRvIG1pbGVzdG9uZS4N Cj4gDQo+IFVSTDogaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy93Zy90c3Z3Zy9hYm91dC8N Cg0K From nobody Fri Sep 1 14:46:34 2017 Return-Path: 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 23EF31341D1; Fri, 1 Sep 2017 14:46:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.601 X-Spam-Level: X-Spam-Status: No, score=-3.601 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dell.com header.b=xiA0pmuk; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=hQx+FgXg 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 Yh5heAh3PwDo; Fri, 1 Sep 2017 14:46:06 -0700 (PDT) Received: from esa1.dell-outbound.iphmx.com (esa1.dell-outbound.iphmx.com [68.232.153.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4761E13465E; Fri, 1 Sep 2017 14:46:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1504301937; x=1535837937; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=V9A77kD36qa3KfOE5aQLmBAYyJNdeObN54luehsjoIY=; b=xiA0pmukMqc8xhh+TWNI33nPkIJNoOT9cKNF0ijBev+LRPfiOkwg9CUQ Qn4PNah2rPTtilm/Ra9BAYT/7qcJ1nnvmX6WOOUZBSq67tGDtqYRx9cvu NKKQhq5Ypws5X9BrTIi0VTMH+dX7TFXEoobU1cehpe2BNZ09fpThoD/cM Q=; Received: from esa2.dell-outbound2.iphmx.com ([68.232.153.202]) by esa1.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Sep 2017 16:38:53 -0500 From: "Black, David" Received: from mailuogwhop.emc.com ([168.159.213.141]) by esa2.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Sep 2017 03:38:51 +0600 Received: from maildlpprd06.lss.emc.com (maildlpprd06.lss.emc.com [10.253.24.38]) by mailuogwprd03.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v81Lk00h014784 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 1 Sep 2017 17:46:00 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com v81Lk00h014784 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1504302360; bh=y/44bVrTpQ2Lrj0+/Ao2pGKIwBQ=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=hQx+FgXggilm5dBknKY2SNq4Yxi12tO/qTG6Qey5YOpzM870O6nw2Nu9p+SRcswLS 6su2ri/xUTt6ZRH0pcfBHayEIYjJYI/TzM/w6ViG/WVt5CsfHz2P8GYtCQATseNMZH PyFJCZd7iFbPNQEHS7FBstIfm1iuc5x7aTGymRFM= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com v81Lk00h014784 Received: from mailusrhubprd51.lss.emc.com (mailusrhubprd51.lss.emc.com [10.106.48.24]) by maildlpprd06.lss.emc.com (RSA Interceptor); Fri, 1 Sep 2017 17:44:56 -0400 Received: from MXHUB321.corp.emc.com (MXHUB321.corp.emc.com [10.146.3.99]) by mailusrhubprd51.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v81LjiBt025824 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Fri, 1 Sep 2017 17:45:45 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB321.corp.emc.com ([10.146.3.99]) with mapi id 14.03.0352.000; Fri, 1 Sep 2017 17:45:44 -0400 To: Brian Carpenter , "gen-art@ietf.org" CC: "draft-ietf-tsvwg-ecn-experimentation.all@ietf.org" , "tsvwg@ietf.org" Thread-Topic: Genart telechat review of draft-ietf-tsvwg-ecn-experimentation-05 Thread-Index: AQHTIsZAf8GsSgkmu0q70NA4hkw3sKKgjxdg Date: Fri, 1 Sep 2017 21:45:44 +0000 Message-ID: References: <150423129417.4604.2689843099266054478@ietfa.amsl.com> In-Reply-To: <150423129417.4604.2689843099266054478@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.44.126] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd51.lss.emc.com X-RSA-Classifications: public Archived-At: Subject: Re: [tsvwg] Genart telechat review of draft-ietf-tsvwg-ecn-experimentation-05 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Sep 2017 21:46:08 -0000 QnJpYW4sDQoNClRoYW5rcyBmb3IgdGhlIHByb21wdCByZXZpZXcuDQoNCj4gQ29tbWVudDogVmVy eSBjbGVhciBmcm9tIHRoZSB0ZWNobmljYWwgc3RhbmRwb2ludC4gDQoNClRoYW5rIHlvdSENCg0K PiBJIHVuZGVyc3RhbmQgdGhlIGRlc2lyZSBmb3IgYnJldml0eSwgYnV0IHRoaXMgYm90aGVycyBt ZSBhIGJpdC4gV2hhdCBpcw0KPiB0aGUgcmVhZGVyIHRvIG1ha2Ugb2YgUkZDMzE2OCBTZWN0aW9u IDIwLjIsIGZvciBleGFtcGxlPyBNeSBmZWVsaW5nIGlzDQo+IHRoYXQgYSBzaG9ydCBBcHBlbmRp eCBvdXRsaW5pbmcgdGhlIHNwZWNpZmljIHVwZGF0ZXMgd291bGQgYmUgdXNlZnVsLg0KPiBUaGVy ZSdzIGFscmVhZHkgdG9vIG11Y2ggc3BhZ2hldHRpIHRvIHVudGFuZ2xlLg0KDQpSRkMgMzE2OCBT ZWN0aW9uIDIwLjIgaXMgdGhlIHJhdGlvbmFsZSBmb3IgdGhlIEVDTiBOb25jZSBhbmQgaGVuY2Ug d291bGQgYmUNCmRlbGV0ZWQuIFJlcXVlc3Qgbm90ZWQsIEknbGwgY29uc3VsdCB3aXRoIHRoZSBk cmFmdCBzaGVwaGVyZCBhbmQgcmVzcG9uc2libGUNCkFEIHRvIGZpZ3VyZSBvdXQgd2hldGhlciB0 byBkbyB0aGlzLg0KDQo+IEkgc2VlIG5vIHJlYXNvbiB3aHkgUkZDMzU0MCBhbmQgUkZDNTYyMiBu ZWVkIHRvIGJlIG5vcm1hdGl2ZSByZWZlcmVuY2VzDQo+IChhbmQgdGhlcmVmb3JlIGRvd25yZWZz KS4gVGhleSBhcmVuJ3QgcmVxdWlyZWQgcmVhZGluZyBpbiBvcmRlciB0bw0KPiB1bmRlcnN0YW5k IHRoaXMgZHJhZnQuDQoNCk9UT0gsIGJvdGggYXJlIGFmZmVjdGVkIGJ5IHRoaXMgZHJhZnQ6DQoN CkluIHJldmVyc2Ugb3JkZXIsIHRoaXMgZHJhZnQgdXBkYXRlcyBSRkMgNTYyMiAtIHRoYXQgc2Vl bXMgdG8gbWVyaXQgYQ0Kbm9ybWF0aXZlIHJlZmVyZW5jZS4gICAgVGhpcyBkcmFmdCBhbHNvIHBy b3ZpZGVzIHRoZSByYXRpb25hbGUgZm9yIHRoZQ0Kc3RhdHVzIGNoYW5nZSBvZiBSRkMgMzU0MCB0 byBIaXN0b3JpYywgd2hpY2ggYWxzbyBzZWVtcyB0byBtZXJpdCBhDQpub3JtYXRpdmUgcmVmZXJl bmNlLg0KDQpUaGFua3MsIC0tRGF2aWQNCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+IEZyb206IEJyaWFuIENhcnBlbnRlciBbbWFpbHRvOmJyaWFuLmUuY2FycGVudGVyQGdtYWls LmNvbV0NCj4gU2VudDogVGh1cnNkYXksIEF1Z3VzdCAzMSwgMjAxNyAxMDowMiBQTQ0KPiBUbzog Z2VuLWFydEBpZXRmLm9yZw0KPiBDYzogZHJhZnQtaWV0Zi10c3Z3Zy1lY24tZXhwZXJpbWVudGF0 aW9uLmFsbEBpZXRmLm9yZzsgdHN2d2dAaWV0Zi5vcmcNCj4gU3ViamVjdDogR2VuYXJ0IHRlbGVj aGF0IHJldmlldyBvZiBkcmFmdC1pZXRmLXRzdndnLWVjbi1leHBlcmltZW50YXRpb24tMDUNCj4g DQo+IFJldmlld2VyOiBCcmlhbiBDYXJwZW50ZXINCj4gUmV2aWV3IHJlc3VsdDogUmVhZHkgd2l0 aCBJc3N1ZXMNCj4gDQo+IEdlbi1BUlQgTGFzdCBDYWxsIHJldmlldyBvZiBkcmFmdC1pZXRmLXRz dndnLWVjbi1leHBlcmltZW50YXRpb24tMDUNCj4gDQo+IEkgYW0gdGhlIGFzc2lnbmVkIEdlbi1B UlQgcmV2aWV3ZXIgZm9yIHRoaXMgZHJhZnQuIFRoZSBHZW5lcmFsIEFyZWENCj4gUmV2aWV3IFRl YW0gKEdlbi1BUlQpIHJldmlld3MgYWxsIElFVEYgZG9jdW1lbnRzIGJlaW5nIHByb2Nlc3NlZA0K PiBieSB0aGUgSUVTRyBmb3IgdGhlIElFVEYgQ2hhaXIuICBQbGVhc2UgdHJlYXQgdGhlc2UgY29t bWVudHMganVzdA0KPiBsaWtlIGFueSBvdGhlciBsYXN0IGNhbGwgY29tbWVudHMuDQo+IA0KPiBG b3IgbW9yZSBpbmZvcm1hdGlvbiwgcGxlYXNlIHNlZSB0aGUgRkFRIGF0DQo+IDxodHRwOi8vd2lr aS50b29scy5pZXRmLm9yZy9hcmVhL2dlbi90cmFjL3dpa2kvR2VuQXJ0ZmFxPi4NCj4gDQo+IERv Y3VtZW50OiBkcmFmdC1pZXRmLXRzdndnLWVjbi1leHBlcmltZW50YXRpb24tMDUudHh0DQo+IFJl dmlld2VyOiBCcmlhbiBDYXJwZW50ZXINCj4gUmV2aWV3IERhdGU6IDIwMTctMDktMDENCj4gSUVU RiBMQyBFbmQgRGF0ZTogMjAxNy0wOS0xNA0KPiBJRVNHIFRlbGVjaGF0IGRhdGU6IDIwMTctMDkt MTQNCj4gDQo+IFN1bW1hcnk6IFJlYWR5IHdpdGggKG1pbm9yKSBpc3N1ZXMNCj4gLS0tLS0tLS0N Cj4gDQo+IENvbW1lbnQ6IFZlcnkgY2xlYXIgZnJvbSB0aGUgdGVjaG5pY2FsIHN0YW5kcG9pbnQu DQo+IC0tLS0tLS0tDQo+IA0KPiBNaW5vciBJc3N1ZXM6DQo+IC0tLS0tLS0tLS0tLS0NCj4gDQo+ ID4gMy4gIEVDTiBOb25jZSBhbmQgUkZDIDM1NDANCj4gLi4uDQo+ID4gbyAgVXBkYXRlcyBSRkMg MzE2OCBbUkZDMzE2OF0gdG8gcmVtb3ZlIGRpc2N1c3Npb24gb2YgdGhlIEVDTiBOb25jZQ0KPiA+ ICAgIGFuZCB1c2Ugb2YgRUNUKDEpIGZvciB0aGF0IE5vbmNlLiAgVGhlIHNwZWNpZmljIHRleHQg dXBkYXRlcyBhcmUNCj4gPiAgICBvbWl0dGVkIGZvciBicmV2aXR5Lg0KPiANCj4gSSB1bmRlcnN0 YW5kIHRoZSBkZXNpcmUgZm9yIGJyZXZpdHksIGJ1dCB0aGlzIGJvdGhlcnMgbWUgYSBiaXQuIFdo YXQgaXMNCj4gdGhlIHJlYWRlciB0byBtYWtlIG9mIFJGQzMxNjggU2VjdGlvbiAyMC4yLCBmb3Ig ZXhhbXBsZT8gTXkgZmVlbGluZyBpcw0KPiB0aGF0IGEgc2hvcnQgQXBwZW5kaXggb3V0bGluaW5n IHRoZSBzcGVjaWZpYyB1cGRhdGVzIHdvdWxkIGJlIHVzZWZ1bC4NCj4gVGhlcmUncyBhbHJlYWR5 IHRvbyBtdWNoIHNwYWdoZXR0aSB0byB1bnRhbmdsZS4NCj4gDQo+IEkgc2VlIG5vIHJlYXNvbiB3 aHkgUkZDMzU0MCBhbmQgUkZDNTYyMiBuZWVkIHRvIGJlIG5vcm1hdGl2ZSByZWZlcmVuY2VzDQo+ IChhbmQgdGhlcmVmb3JlIGRvd25yZWZzKS4gVGhleSBhcmVuJ3QgcmVxdWlyZWQgcmVhZGluZyBp biBvcmRlciB0bw0KPiB1bmRlcnN0YW5kIHRoaXMgZHJhZnQuDQo+IA0KPiAtLQ0KDQo= From nobody Fri Sep 1 16:41:20 2017 Return-Path: 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 5BE8E13446A; Fri, 1 Sep 2017 16:41:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[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] 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 5KfcNi2WnDgk; Fri, 1 Sep 2017 16:41:17 -0700 (PDT) Received: from mail-pg0-x230.google.com (mail-pg0-x230.google.com [IPv6:2607:f8b0:400e:c05::230]) (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 77D741341EE; Fri, 1 Sep 2017 16:41:17 -0700 (PDT) Received: by mail-pg0-x230.google.com with SMTP id r133so4371881pgr.3; Fri, 01 Sep 2017 16:41:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=hDCk0VMGGlkMiInDdnnyB5P+AHh4pvKg3x9PcZ0jeEI=; b=a/Bfa66OKH8JS7kUKzl/JkE/N+ixr0LZQwsri97MEaQbBsfrG4wo3ikktfniLELafP RAUrxykNDfeS8LWK/hpoiFf7uZCiETcI987U8URBIeqHPMJFuNszkp5UQ25HCJoE7f9g C4g7u6b2vJ34Uq9Mr/T1hwJWDFl+5VDqeui3iuOTgVUFiq8w6E/WGcV8mcRWFjv0z16q aeJuWRxTTl1Nn1qQo6UpyWcdEoeGM5IXaZs+UnBZq+q26d4xYbEjB2Q2vmXKCPSWwmFN jZiHktP3rOgQwe4m0sW6wt1TpElFOxdhChkZnZydWZzVMJp9teGU6+f3IZWVKE1rztsr /I9A== 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:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=hDCk0VMGGlkMiInDdnnyB5P+AHh4pvKg3x9PcZ0jeEI=; b=rBCeWf+jj5HyAY0WetIooSfvq+bpHuVG0tIN2A31vuLx6prEMy0jzVZ4nrsRmSfhEA YqF+GR25rnyUu1cDhJY83TLcpnypMf2X8kVeH6EvfWNXbxcR4H82siiTBR0OxmprCc3D OknE7lBplmr+HH8ed80Kiub/Wt+i/FfK007ywcC55/BozZKEZhDgwqvED/2MZOog/gIt bb4G9yU/QPdaM+S/uJ2yksi4VjErUq4bW5CHuta/nW6N/M/hfkMF8AOhRp+n5HgAIiFP 8tOoF2CmqWvNn9Jxv17c+du3jio8IHUmOEfAgVNV/AlPknAGnu/0lbv4m5jgVmRsEF1U XiLQ== X-Gm-Message-State: AHPjjUg47/rd8Ru08W0RoRTNN+wan9YxJu0+J4eGSnXDB598zbeQlKmK g8PNnGo9p4CA7yMf X-Google-Smtp-Source: ADKCNb7d13D/Sg5dFNXiu2uMObUUjITdW5g+u0sloZgWZLXJXPoh2ombo4vVjt57PWAUzKcLKMN8ig== X-Received: by 10.98.75.2 with SMTP id y2mr4188047pfa.305.1504309276652; Fri, 01 Sep 2017 16:41:16 -0700 (PDT) Received: from ?IPv6:2406:e007:57a7:1:28cc:dc4c:9703:6781? ([2406:e007:57a7:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id 27sm1507796pfk.91.2017.09.01.16.41.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 01 Sep 2017 16:41:15 -0700 (PDT) To: "Black, David" , "gen-art@ietf.org" Cc: "draft-ietf-tsvwg-ecn-experimentation.all@ietf.org" , "tsvwg@ietf.org" References: <150423129417.4604.2689843099266054478@ietfa.amsl.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <6afe85ba-83c5-5945-fd37-dc313eb22162@gmail.com> Date: Sat, 2 Sep 2017 11:41:23 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [tsvwg] Genart telechat review of draft-ietf-tsvwg-ecn-experimentation-05 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Sep 2017 23:41:19 -0000 On 02/09/2017 09:45, Black, David wrote: > Brian, > > Thanks for the prompt review. > >> Comment: Very clear from the technical standpoint. > > Thank you! > >> I understand the desire for brevity, but this bothers me a bit. What is >> the reader to make of RFC3168 Section 20.2, for example? My feeling is >> that a short Appendix outlining the specific updates would be useful. >> There's already too much spaghetti to untangle. > > RFC 3168 Section 20.2 is the rationale for the ECN Nonce and hence would be > deleted. Request noted, I'll consult with the draft shepherd and responsible > AD to figure out whether to do this. Thanks. It's not intended as a blocking issue. > >> I see no reason why RFC3540 and RFC5622 need to be normative references >> (and therefore downrefs). They aren't required reading in order to >> understand this draft. > > OTOH, both are affected by this draft: > > In reverse order, this draft updates RFC 5622 - that seems to merit a > normative reference. This draft also provides the rationale for the > status change of RFC 3540 to Historic, which also seems to merit a > normative reference. Well, my understanding is that a normative reference is needed only when the citing document cannot be understood and implemented without reading the cited document. Again it's not a blocking comment - although there is a technical error in the Last Call message: it flags the downref to 5622, but not that to 3540. I don't know if that's a tool error or an AD error ;-). Brian > > Thanks, --David > > >> -----Original Message----- >> From: Brian Carpenter [mailto:brian.e.carpenter@gmail.com] >> Sent: Thursday, August 31, 2017 10:02 PM >> To: gen-art@ietf.org >> Cc: draft-ietf-tsvwg-ecn-experimentation.all@ietf.org; tsvwg@ietf.org >> Subject: Genart telechat review of draft-ietf-tsvwg-ecn-experimentation-05 >> >> Reviewer: Brian Carpenter >> Review result: Ready with Issues >> >> Gen-ART Last Call review of draft-ietf-tsvwg-ecn-experimentation-05 >> >> I am the assigned Gen-ART reviewer for this draft. The General Area >> Review Team (Gen-ART) reviews all IETF documents being processed >> by the IESG for the IETF Chair. Please treat these comments just >> like any other last call comments. >> >> For more information, please see the FAQ at >> . >> >> Document: draft-ietf-tsvwg-ecn-experimentation-05.txt >> Reviewer: Brian Carpenter >> Review Date: 2017-09-01 >> IETF LC End Date: 2017-09-14 >> IESG Telechat date: 2017-09-14 >> >> Summary: Ready with (minor) issues >> -------- >> >> Comment: Very clear from the technical standpoint. >> -------- >> >> Minor Issues: >> ------------- >> >>> 3. ECN Nonce and RFC 3540 >> ... >>> o Updates RFC 3168 [RFC3168] to remove discussion of the ECN Nonce >>> and use of ECT(1) for that Nonce. The specific text updates are >>> omitted for brevity. >> >> I understand the desire for brevity, but this bothers me a bit. What is >> the reader to make of RFC3168 Section 20.2, for example? My feeling is >> that a short Appendix outlining the specific updates would be useful. >> There's already too much spaghetti to untangle. >> >> I see no reason why RFC3540 and RFC5622 need to be normative references >> (and therefore downrefs). They aren't required reading in order to >> understand this draft. >> >> -- > From nobody Sat Sep 2 06:25:21 2017 Return-Path: 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 ABDCF132EC0 for ; Sat, 2 Sep 2017 06:25:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 HZFIufjK3aBQ for ; Sat, 2 Sep 2017 06:25:12 -0700 (PDT) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (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 4E560132E79 for ; Sat, 2 Sep 2017 06:25:06 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id c85so4927697ywa.0 for ; Sat, 02 Sep 2017 06:25:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pjjCbHeL5qv2+/PiIgKkQp7g7C78rb/4PpG5V1z9R5c=; b=ykKzxhFw2H8VrU7+AYIdQgTslWEGcv2M8I4d76FyeV0N5do01UqlhifE2xPa4F6udn zvgmhFQSsi5ZWeMsdsPXQKRmHIzlsjfXLA0Clr1nuNAjafI+CfYKLvzCqhwC6S44A1xI mD2Kyka+HA51/MaIzhhXWyt/b9+y473tOZ9BjOJpCaZ5NK1yzAQJTnw1JbpQNUkooYFQ Rzwl3OSSMM+/CmR8Pi6egRM+MnywtjsDelX2nntwVXKFqsnVp8kNtHq/fe8ON0QkzS9U SsmKtqC8osIIp9I9haQxO9WU0ascb/M9BMbKchSk4bELZeQIWHkfajF5f6d3ak3ZrInE wJCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=pjjCbHeL5qv2+/PiIgKkQp7g7C78rb/4PpG5V1z9R5c=; b=qBynVXPgn1797YSe/6mVWGyZRcRE83LvnDOtC1uetjS1W4UflNgI5T2qF8rMHlBwt4 DkK3YM50XiQaE56CIqcDU644nULUJUSBFNCoFlLWjR9ZobIV2puybI3vGlZ1cF35pr6o IH+n23ddjtB9PpaKoctxbJcWH2bKB8RK1dfgmrZJKqnGmfWHvc2IYEUYyGM2KwTcZt3G H5azAU4tKLQdt7KbXbDg1U3RVRu4t+9xJdvQdozAEPpiCiXb7fm+SpyzBJQ3xRGKuoMw roMvUKldSRPmyBLWPFfeqUBseOV/qy0VOkteWaJ9Tv2GA9MHmZ03Eo3mSBqE6sBjuusW MF1Q== X-Gm-Message-State: AHPjjUgujzCxxDXiV5x+/IakpWWXvqPFihq0YiHuUqQ/kad0yT56e0C1 cx9Xm6PFMWHmxO44qfvur0eLZ2nrtUCE X-Google-Smtp-Source: ADKCNb6UgpD0qzDNbOWCFvVvs65lFHuV5kw8nRPzW35+1lT+qo8HbFKXRqTsFmBJ0FgiA9tBvmfCE5SvONeKkiisFvE= X-Received: by 10.37.4.204 with SMTP id 195mr4517116ybe.289.1504358705551; Sat, 02 Sep 2017 06:25:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.218.130 with HTTP; Sat, 2 Sep 2017 06:24:24 -0700 (PDT) In-Reply-To: References: <150377526319.25828.13085691478621902018.idtracker@ietfa.amsl.com> <6B8221AA-0A42-4409-BDA9-63215B0789F2@fh-muenster.de> <7C366691-31F9-44B3-AF7A-F877B13EF27A@fh-muenster.de> <68C4E71D-B044-4DC3-B570-97C0AD0578F6@fh-muenster.de> From: Eric Rescorla Date: Sat, 2 Sep 2017 07:24:24 -0600 Message-ID: To: Spencer Dawkins at IETF Cc: Michael Tuexen , Gorry Fairhurst , draft-ietf-tsvwg-sctp-ndata@ietf.org, The IESG , "tsvwg@ietf.org" , "tsvwg-chairs@ietf.org" Content-Type: multipart/alternative; boundary="001a11c01966428940055834ce77" Archived-At: Subject: Re: [tsvwg] Eric Rescorla's No Objection on draft-ietf-tsvwg-sctp-ndata-12: (with COMMENT) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Sep 2017 13:25:15 -0000 --001a11c01966428940055834ce77 Content-Type: text/plain; charset="UTF-8" LGTM On Fri, Sep 1, 2017 at 2:22 PM, Spencer Dawkins at IETF < spencerdawkins.ietf@gmail.com> wrote: > Hi, Eric, > > On Wed, Aug 30, 2017 at 8:11 AM, Michael Tuexen > wrote: > >> >> > On 29. Aug 2017, at 15:09, Eric Rescorla wrote: >> > >> > >> > >> > On Tue, Aug 29, 2017 at 12:24 AM, Michael Tuexen >> wrote: >> > > On 29. Aug 2017, at 01:04, Eric Rescorla wrote: >> > > >> > > >> > > >> > > On Mon, Aug 28, 2017 at 3:39 PM, Michael Tuexen < >> tuexen@fh-muenster.de> wrote: >> > > > On 28. Aug 2017, at 22:56, Eric Rescorla wrote: >> > > > >> > > > >> > > > >> > > > On Mon, Aug 28, 2017 at 1:42 PM, Michael Tuexen < >> tuexen@fh-muenster.de> wrote: >> > > > > On 26. Aug 2017, at 21:21, Eric Rescorla wrote: >> > > > > >> > > > > Eric Rescorla has entered the following ballot position for >> > > > > draft-ietf-tsvwg-sctp-ndata-12: No Objection >> > > > > >> > > > > When responding, please keep the subject line intact and reply to >> all >> > > > > email addresses included in the To and CC lines. (Feel free to >> cut this >> > > > > introductory paragraph, however.) >> > > > > >> > > > > >> > > > > Please refer to https://www.ietf.org/iesg/stat >> ement/discuss-criteria.html >> > > > > for more information about IESG DISCUSS and COMMENT positions. >> > > > > >> > > > > >> > > > > The document, along with other ballot positions, can be found >> here: >> > > > > https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-ndata/ >> > > > > >> > > > > >> > > > > >> > > > > ------------------------------------------------------------ >> ---------- >> > > > > COMMENT: >> > > > > ------------------------------------------------------------ >> ---------- >> > > > > >> > > > Hi Eric, >> > > > >> > > > thanks for the review. See my responses in-line. >> > > > >> > > > Best regards >> > > > Michael >> > > > > TECHNICAL >> > > > > I'm not sure I am following the rules about interleaving multiple >> > > > > messages in the same flight. >> > > > > >> > > > > The sender MUST NOT fragment more than one user message in any >> given >> > > > > stream at any time. At any time, a sender MAY fragment >> multiple user >> > > > > messages, each of them on different streams. >> > > > > >> > > > > So, say I have one stream and the application sends M1 and M2 and >> both >> > > > > need to be fragmented, so I have M1a, M1b and M2a and M2b. Does >> this >> > > > > mean that I can't send M2a until M1{a,b} has been acknowledged? >> > > > No, that is not what is meant. >> > > > >> > > > Assume M1 is sent before M2 and you end up in M1a (first fragment), >> > > > M1b (second fragment), M2a (first fragment) and M2b (second >> fragment). >> > > > You would assign the TSNs in a way that they are increasing for >> > > > M1a, M1b, M2a, and M2b. So you are not interleaving messages on >> > > > the same stream. That is the point. So you would not send them as >> > > > M1a, M2a, M2b, M1b. You should also not send M1a, M2, M1b (assuming >> > > > that M2 doesn't need to be fragmented). >> > > > >> > > > I agree, the above text is not as clear as possible. So what about >> stating >> > > > it as: >> > > > >> > > > The sender MUST NOT assign TSNs to more than one user message in >> any given >> > > > stream at any time. At any time, a sender MAY assign TSNs to >> multiple user >> > > > messages, each of them on different streams. >> > > > >> > > > Perhaps you might instead say: >> > > > >> > > > The user messages within a given stream must have strictly >> increasing TSNs >> > > Not sure what you are suggesting, since TSN are assigned to chunks, >> not >> > > user messages. >> > > >> > > The problem here is that your text focuses on TSN *assignment* which >> is not >> > > really the relevant property (it's an implementation artifact) rather >> what appears >> > > on the wire is. So, the requirement here seems to be that you >> allocate TSNs >> > > to fragments of user messages in order. >> > The next sentence in the document states: >> > >> > The sender MUST assign TSNs in a way that the receiver can make >> progress. >> > One way to achieve this is to assign a higher TSN to the later >> fragments of >> > a user message and send out the TSNs in sequence. >> > >> > The reason not to mandate this is that you might you more complex >> schemes >> > in case of load-sharing between multiple paths. >> > >> > That's fine, but I don't find the current text clear and this doesn't >> help. Why don't >> > you try listing the requirements on what appears on the wire from the >> receiver's >> > perspective in response to this message, and then we can discuss how to >> > write it in the doc. >> Let me make another suggestion: >> >> OLD TEXT: >> >> The sender MUST NOT fragment more than one user message in any given >> stream at any time. At any time, a sender MAY fragment multiple user >> messages, each of them on different streams. >> >> The sender MUST assign TSNs in a way that the receiver can make >> progress. One way to achieve this is to assign a higher TSN to the >> later fragments of a user message and send out the TSNs in sequence. >> >> >> NEW TEXT: >> >> The sender MUST NOT process (move user data into I-DATA chunks and >> assign >> a TSN to it) for more than one user message in any given stream at any >> time. >> At any time, a sender MAY process multiple user messages, each of them >> on >> different streams. >> >> The sender MUST assign TSNs to I-DATA chunks in a way that the receiver >> can make progress. One way to achieve this is to assign a higher TSN >> to the >> later fragments of a user message and send out the I-DATA chunks such >> that >> the TSNs are in sequence. >> >> Does that address your issue? >> > > Michael has submitted -13 which includes this text. Diff is at > https://tools.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-sctp-ndata-13.txt. > > I'm planning to send an Approved notice for -13. If you see a problem, > please let me know. > > Thanks, > > Spencer > > >> >> Best regards >> Michael >> > >> > -Ekr >> > >> > > >> > > >> > > Just considering the simple case of non-fragmented user >> > > messages, you can't guarantee that user messages of a particular >> stream >> > > have increasing TSNs, since there can be wrap arounds due to chunks >> > > belonging to other streams. The TSN are 32-bit numbers with serial >> arithmetic... >> > > >> > > Hmm... You don't think of these as being infinite precision but taken >> mod 2^32? >> > In most cases, yes. But I need to take into account that the numbers >> can wrap >> > and how this is handled by receivers. That is why the document states >> some >> > limitations you the number of outstanding MIDs and FSNs. >> > >> > Best regards >> > Michael >> > > >> > > -Ekr >> > > >> > > >> > > >> > > >> > > Best regards >> > > Michael >> > > > >> > > > >> > > > >> > > > > use MID to reassemble correctly. And given this requirement, why >> do >> > > > > you need MID? >> > > > You need some id to know which fragments belong to the same >> > > > user message. You can't derive that from the TSN. >> > > > >> > > > Yeah, I thought you could but after some thought I see you cannot. >> > > > >> > > > >> > > > -Ekr >> > > > >> > > > > Because fragementation is indicated by index, not range, >> > > > > what happens if you have to reduce MTU? So, say I have a message >> of >> > > > > size 2K which I fragment into 1K/1K and then I have to decrease >> > > > > my MTU to 512 bytes? >> > > > SCTP can't adopt, so IP fragmentation will be used. >> > > > >> > > > The reason is that once you sent a DATA chunk or an I-DATA chunk >> > > > you assigned a TSN will is used for reliable transfer. So you >> > > > have to retransmit it and you can't change the user data contained >> > > > in it. This has not changed from the base spec. >> > > > >> > > > Changing the information from index to range for handling reassembly >> > > > would not really help, since you still do reliable transfer by >> using the >> > > > TSN assigned to the DATA or I-DATA chunk and you need to retransmit >> it. >> > > > > >> > > > > >> > > > > EDITORIAL >> > > > > I think it would be helpful to indicate that B has to be >> > > > > set for the first chunk in S 2.1. Or perhaps move the overview of >> > > > > how the sender behaves in S 2.2.2 up in the document? >> > > > Considering this comment and the ones I got from other people >> > > > it seems like referring to RFC 4960 and RFC 7053 for the fields >> > > > which haven't changed and only describing the new fields doesn't >> > > > seem to work well. >> > > > >> > > > I'll add text describing the "old fields". >> > > > > >> > > > > >> > > > >> > > > >> > > >> > > >> > >> > >> >> > --001a11c01966428940055834ce77 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
LGTM

On Fri, Sep 1, 2017 at 2:22 PM, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> wrote:
Hi, Eric,

On Wed, Aug 30, 2017 at 8:1= 1 AM, Michael Tuexen <tuexen@fh-muenster.de> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">

> On 29. Aug 2017, at 15:09, Eric Rescorla <ekr@rtfm.com> wrote:
>
>
>
> On Tue, Aug 29, 2017 at 12:24 AM, Michael Tuexen <tuexen@fh-muenster.de> wro= te:
> > On 29. Aug 2017, at 01:04, Eric Rescorla <ekr@rtfm.com> wrote:
> >
> >
> >
> > On Mon, Aug 28, 2017 at 3:39 PM, Michael Tuexen <tuexen@fh-muenster.de>= wrote:
> > > On 28. Aug 2017, at 22:56, Eric Rescorla <ekr@rtfm.com> wrote:
> > >
> > >
> > >
> > > On Mon, Aug 28, 2017 at 1:42 PM, Michael Tuexen <tuexen@fh-muenster.de> wrote:
> > > > On 26. Aug 2017, at 21:21, Eric Rescorla <ekr@rtfm.com> wrote:
> > > >
> > > > Eric Rescorla has entered the following ballot position= for
> > > > draft-ietf-tsvwg-sctp-ndata-12: No Objection
> > > >
> > > > When responding, please keep the subject line intact an= d reply to all
> > > > email addresses included in the To and CC lines. (Feel = free to cut this
> > > > introductory paragraph, however.)
> > > >
> > > >
> > > > Please refer to https:/= /www.ietf.org/iesg/statement/discuss-criteria.html
> > > > for more information about IESG DISCUSS and COMMENT pos= itions.
> > > >
> > > >
> > > > The document, along with other ballot positions, can be= found here:
> > > > https://datatracker= .ietf.org/doc/draft-ietf-tsvwg-sctp-ndata/
> > > >
> > > >
> > > >
> > > > --------------------------------------------------= --------------------
> > > > COMMENT:
> > > > --------------------------------------------------= --------------------
> > > >
> > > Hi Eric,
> > >
> > > thanks for the review. See my responses in-line.
> > >
> > > Best regards
> > > Michael
> > > > TECHNICAL
> > > > I'm not sure I am following the rules about interle= aving multiple
> > > > messages in the same flight.
> > > >
> > > >=C2=A0 =C2=A0The sender MUST NOT fragment more than one = user message in any given
> > > >=C2=A0 =C2=A0stream at any time.=C2=A0 At any time, a se= nder MAY fragment multiple user
> > > >=C2=A0 =C2=A0messages, each of them on different streams= .
> > > >
> > > > So, say I have one stream and the application sends M1 = and M2 and both
> > > > need to be fragmented, so I have M1a, M1b and M2a and M= 2b. Does this
> > > > mean that I can't send M2a until M1{a,b} has been a= cknowledged?
> > > No, that is not what is meant.
> > >
> > > Assume M1 is sent before M2 and you end up in M1a (first fra= gment),
> > > M1b (second fragment), M2a (first fragment) and M2b (second = fragment).
> > > You would assign the TSNs in a way that they are increasing = for
> > > M1a, M1b, M2a, and M2b. So you are not interleaving messages= on
> > > the same stream. That is the point. So you would not send th= em as
> > > M1a, M2a, M2b, M1b. You should also not send M1a, M2, M1b (a= ssuming
> > > that M2 doesn't need to be fragmented).
> > >
> > > I agree, the above text is not as clear as possible. So what= about stating
> > > it as:
> > >
> > >=C2=A0 =C2=A0The sender MUST NOT assign TSNs to more than one= user message in any given
> > >=C2=A0 =C2=A0stream at any time.=C2=A0 At any time, a sender = MAY assign TSNs to multiple user
> > >=C2=A0 =C2=A0messages, each of them on different streams.
> > >
> > > Perhaps you might instead say:
> > >
> > > The user messages within a given stream must have strictly i= ncreasing TSNs
> > Not sure what you are suggesting, since TSN are assigned to chunk= s, not
> > user messages.
> >
> > The problem here is that=C2=A0 your text focuses on TSN *assignme= nt* which is not
> > really the relevant property (it's an implementation artifact= ) rather what appears
> > on the wire is. So, the requirement here seems to be that you all= ocate TSNs
> > to fragments of user messages in order.
> The next sentence in the document states:
>
> The sender MUST assign TSNs in a way that the receiver can make progre= ss.
> One way to achieve this is to assign a higher TSN to the later fragmen= ts of
> a user message and send out the TSNs in sequence.
>
> The reason not to mandate this is that you might you more complex sche= mes
> in case of load-sharing between multiple paths.
>
> That's fine, but I don't find the current text clear and this = doesn't help. Why don't
> you try listing the requirements on what appears on the wire from the = receiver's
> perspective in response to this message, and then we can discuss how t= o
> write it in the doc.
Let me make another suggestion:

OLD TEXT:

=C2=A0 =C2=A0The sender MUST NOT fragment more than one user message in any= given
=C2=A0 =C2=A0stream at any time.=C2=A0 At any time, a sender MAY fragment m= ultiple user
=C2=A0 =C2=A0messages, each of them on different streams.

=C2=A0 =C2=A0The sender= MUST assign TSNs in a way that the receiver can make
=C2=A0 =C2=A0progress.=C2=A0 One way to achieve this is to assign a higher = TSN to the
=C2=A0 =C2=A0later fragments of a user message and send out the TSNs in seq= uence.


NEW TEXT:

=C2=A0 =C2=A0The sender MUST NOT process (move user data into I-DATA chunks= and assign
=C2=A0 =C2=A0a TSN to it) for more than one user message in any given strea= m at any time.
=C2=A0 =C2=A0At any time, a sender MAY process multiple user messages, each= of them on
=C2=A0 =C2=A0different streams.

=C2=A0 =C2=A0The sender MUST assign TSNs to I-DATA chunks in a way that the= receiver
=C2=A0 =C2=A0can make progress= .=C2=A0 One way to achieve this is to assign a higher TSN to the
=C2=A0 =C2=A0later fragments of a user message and send out the I-DA= TA chunks such that
=C2=A0 =C2=A0the TSNs are in sequence.

Does that address your issue?

Michael has submitted -13 which includes this text. Diff is at=C2=A0https://tools.ietf.org/rfcdiff?url2=3Ddraft-ie= tf-tsvwg-sctp-ndata-13.txt.

I'm plann= ing to send an Approved notice for -13. If you see a problem, please let me= know.

Thanks,

Spencer
=C2=A0

Best regards
= Michael
>
> -Ekr
>
> >
> >
> > Just considering the simple case of non-fragmented user
> > messages, you can't guarantee that user messages of a particu= lar stream
> > have increasing TSNs, since there can be wrap arounds due to chun= ks
> > belonging to other streams. The TSN are 32-bit numbers with seria= l arithmetic...
> >
> > Hmm... You don't think of these as being infinite precision b= ut taken mod 2^32?
> In most cases, yes. But I need to take into account that the numbers c= an wrap
> and how this is handled by receivers. That is why the document states = some
> limitations you the number of outstanding MIDs and FSNs.
>
> Best regards
> Michael
> >
> > -Ekr
> >
> >
> >
> >
> > Best regards
> > Michael
> > >
> > >
> > >
> > > > use MID to reassemble correctly. And given this require= ment, why do
> > > > you need MID?
> > > You need some id to know which fragments belong to the same<= br> > > > user message. You can't derive that from the TSN.
> > >
> > > Yeah, I thought you could but after some thought I see you c= annot.
> > >
> > >
> > > -Ekr
> > >
> > > > Because fragementation is indicated by index, not range= ,
> > > > what happens if you have to reduce MTU? So, say I have = a message of
> > > > size 2K which I fragment into 1K/1K and then I have to = decrease
> > > > my MTU to 512 bytes?
> > > SCTP can't adopt, so IP fragmentation will be used.
> > >
> > > The reason is that once you sent a DATA chunk or an I-DATA c= hunk
> > > you assigned a TSN will is used for reliable transfer. So yo= u
> > > have to retransmit it and you can't change the user data= contained
> > > in it. This has not changed from the base spec.
> > >
> > > Changing the information from index to range for handling re= assembly
> > > would not really help, since you still do reliable transfer = by using the
> > > TSN assigned to the DATA or I-DATA chunk and you need to ret= ransmit it.
> > > >
> > > >
> > > > EDITORIAL
> > > > I think it would be helpful to indicate that B has to b= e
> > > > set for the first chunk in S 2.1. Or perhaps move the o= verview of
> > > > how the sender behaves in S 2.2.2 up in the document? > > > Considering this comment and the ones I got from other peopl= e
> > > it seems like referring to RFC 4960 and RFC 7053 for the fie= lds
> > > which haven't changed and only describing the new fields= doesn't
> > > seem to work well.
> > >
> > > I'll add text describing the "old fields".
> > > >
> > > >
> > >
> > >
> >
> >
>
>



--001a11c01966428940055834ce77-- From nobody Sat Sep 2 11:38:01 2017 Return-Path: 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 AAEEC1321A2; Sat, 2 Sep 2017 11:37:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 zy2_AmAhR-GA; Sat, 2 Sep 2017 11:37:52 -0700 (PDT) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (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 2A68F132FE7; Sat, 2 Sep 2017 11:37:52 -0700 (PDT) Received: by mail-yw0-x229.google.com with SMTP id h127so12366633ywf.3; Sat, 02 Sep 2017 11:37:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=fB2cskDpRkosKDonYY+IczVRuUZ727D3nexbqCSh4N0=; b=CAUTjFSzZx6RAvAENGGnD7SG69NcCinWn/NILLy1Q1jMYNzz02cgmeHejk60kaFet5 LMK17OBknMPe/Udt1svuE9HhLBw+PPghTLNkvuER1Dkutcwd06RIma7ZJeTHk51XfnDd 6alMo1QJi2lP790O8/Gd5q5D75JaiAhzaY9FSYEDo8E6kYo+X2gKf+Ph0sSG+HTcFc8x xPUGcgos7zQqAtiBuHbluylk8edZgMwT8UwYS0pu/441AF1yo60Su5wOor0zsI0mwSFS T8qMY/izM3fE8OySjJAfrsKAgHwt6wSiRLqu1PwF0NqDKuDJphz0xnGt43EUCwrSmyeV KXaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=fB2cskDpRkosKDonYY+IczVRuUZ727D3nexbqCSh4N0=; b=sQhLXQFeYWANDbeQR1lfzodJFSY6LeXbwyW+tKCRJaPHWOemqmcFLYH20y9q0SGevV JJ0+P1TQ28vvQUX/GzMxl/+F/7T7+s2XRYPjSlcnGEpCyerZkIqnMgo52eVMk6KIshIM qw2ru4GJJT1dLk3jVQIjrdwaBrE1Tcso/P/YO1zyUZNMwoxtwviiXfWgNu/LWnFkykLh cAzoYGac2ZFYq7ZqXImESYZeuRuasxuIFcFEg2AHZ451LoAxURZiJ6bJYWFuF1OEC5VL sBeE7rBqucQ8brs1F4YcVUikKzwsEssxMHlf/fslAkYEyG0sQtKaZA9C5emAsysKF6RA fvOQ== X-Gm-Message-State: AHPjjUgyLfrZgidepawt2F6VQSLZ0t418WhPDu8kggYCXhi1BpADNukQ 9G9ByM9QXrKLYV2k8CLMUw0nzRGQew== X-Google-Smtp-Source: ADKCNb7NgNhpKNh+N+5eIJBAn5vcQHzZArnupRinBxr4/mAk7hGHeNSYYxltVw0trVbn6KLD/TMmjFX4ip113aBMUpE= X-Received: by 10.37.88.86 with SMTP id m83mr5174211ybb.170.1504377471275; Sat, 02 Sep 2017 11:37:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.2.148 with HTTP; Sat, 2 Sep 2017 11:37:50 -0700 (PDT) In-Reply-To: <6afe85ba-83c5-5945-fd37-dc313eb22162@gmail.com> References: <150423129417.4604.2689843099266054478@ietfa.amsl.com> <6afe85ba-83c5-5945-fd37-dc313eb22162@gmail.com> From: Spencer Dawkins at IETF Date: Sat, 2 Sep 2017 13:37:50 -0500 Message-ID: To: Brian E Carpenter Cc: "Black, David" , "gen-art@ietf.org" , "draft-ietf-tsvwg-ecn-experimentation.all@ietf.org" , "tsvwg@ietf.org" Content-Type: multipart/alternative; boundary="001a114166d4c898960558392c79" Archived-At: Subject: Re: [tsvwg] Genart telechat review of draft-ietf-tsvwg-ecn-experimentation-05 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Sep 2017 18:37:54 -0000 --001a114166d4c898960558392c79 Content-Type: text/plain; charset="UTF-8" Hi, Brian, On Fri, Sep 1, 2017 at 6:41 PM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > On 02/09/2017 09:45, Black, David wrote: > > Brian, > > > > Thanks for the prompt review. > > > >> Comment: Very clear from the technical standpoint. > > > > Thank you! > > > >> I understand the desire for brevity, but this bothers me a bit. What is > >> the reader to make of RFC3168 Section 20.2, for example? My feeling is > >> that a short Appendix outlining the specific updates would be useful. > >> There's already too much spaghetti to untangle. > > > > RFC 3168 Section 20.2 is the rationale for the ECN Nonce and hence would > be > > deleted. Request noted, I'll consult with the draft shepherd and > responsible > > AD to figure out whether to do this. > > Thanks. It's not intended as a blocking issue. > > > > >> I see no reason why RFC3540 and RFC5622 need to be normative references > >> (and therefore downrefs). They aren't required reading in order to > >> understand this draft. > > > > OTOH, both are affected by this draft: > > > > In reverse order, this draft updates RFC 5622 - that seems to merit a > > normative reference. This draft also provides the rationale for the > > status change of RFC 3540 to Historic, which also seems to merit a > > normative reference. > > Well, my understanding is that a normative reference is needed only > when the citing document cannot be understood and implemented > without reading the cited document. > > Again it's not a blocking comment - although there is a technical error > in the Last Call message: it flags the downref to 5622, but not that to > 3540. > I don't know if that's a tool error or an AD error ;-). As Bran is too polite to say, the AD sees the generated Last Call announcement before it's sent. I just regenerated the Last Call announcement, and it's still only naming one draft as a normative downref. But the AD didn't notice that, so blaming the tools was the wrong answer :-) It's a 3-day weekend in the US, so any updated Last Call announcement won't go out until Tuesday, anyway. So, let's talk about that. I just re-read the draft, focusing on the places where it refers to RFC 3540. This draft explains the ECN Nonce experiment inline, although it cites 3540 as its reference, and explains that the experiment required ECT(0) and ECT(1), but the experiment is over, and hasn't been deployed on the Internet in any significant way, so we want ECT(1) back, for other experiments. It also refers to 3540 when it changes a registration in the Transmission Control Protocol (TCP) Header Flags registry, but I believe this draft explains the IANA actions requested well enough that IANA wouldn't need to read 3540 to carry out the requested action. I could be convinced that this draft explains why we want ECT(1) back well enough that it's not necessary to actually read 3540, and since we're declaring 3540 Historic, we actually kinda hope no one reads it in the future except archaeologists in cyberspace. But unless that reference really is informational, it remains a normative downref that was omitted from the Last Call announcement. David, I don't mind re-issuing the Last Call announcement if you think still think the reference is normative, but you might want to take a look at the text in the draft, and see how badly it needs to be normative, before letting me know. Spencer --001a114166d4c898960558392c79 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Brian,

On Fri, Sep 1, 2017 at 6:41 PM, Brian E Carpenter <bri= an.e.carpenter@gmail.com> wrote:
On 02/09/2017 09:45, Black,= David wrote:
> Brian,
>
> Thanks for the prompt review.
>
>> Comment: Very clear from the technical standpoint.
>
> Thank you!
>
>> I understand the desire for brevity, but this bothers me a bit. Wh= at is
>> the reader to make of RFC3168 Section 20.2, for example? My feelin= g is
>> that a short Appendix outlining the specific updates would be usef= ul.
>> There's already too much spaghetti to untangle.
>
> RFC 3168 Section 20.2 is the rationale for the ECN Nonce and hence wou= ld be
> deleted. Request noted, I'll consult with the draft shepherd and r= esponsible
> AD to figure out whether to do this.

Thanks. It's not intended as a blocking issue.

>
>> I see no reason why RFC3540 and RFC5622 need to be normative refer= ences
>> (and therefore downrefs). They aren't required reading in orde= r to
>> understand this draft.
>
> OTOH, both are affected by this draft:
>
> In reverse order, this draft updates RFC 5622 - that seems to merit a<= br> > normative reference.=C2=A0 =C2=A0 This draft also provides the rationa= le for the
> status change of RFC 3540 to Historic, which also seems to merit a
> normative reference.

Well, my understanding is that a normative reference is needed only<= br> when the citing document cannot be understood and implemented
without reading the cited document.

Again it's not a blocking comment - although there is a technical error=
in the Last Call message: it flags the downref to 5622, but not that to 354= 0.
I don't know if that's a tool error or an AD error ;-).

As Bran is too polite to say, the AD sees the generate= d Last Call announcement before it's sent.=C2=A0

I just regenerated the Last Call announcement, and it's still only n= aming one draft as a normative downref. But the AD didn't notice that, = so blaming the tools was the wrong answer :-)

It&#= 39;s a 3-day weekend in the US, so any updated Last Call announcement won&#= 39;t go out until Tuesday, anyway.=C2=A0

So, let&#= 39;s talk about that.

I just re-read the draft, fo= cusing on the places where it refers to RFC 3540.=C2=A0

This draft explains the ECN Nonce experiment inline, although it cite= s 3540 as its reference, and explains that the experiment required ECT(0) a= nd ECT(1), but the experiment is over, and hasn't been deployed on the = Internet in any significant way, so we want ECT(1) back, for other experime= nts.

It also refers to 3540 when it changes a regi= stration in the Transmission Control Protocol (TCP) Header Flags registry, = but I believe this draft explains the IANA actions requested well enough th= at IANA wouldn't need to read 3540 to carry out the requested action.= =C2=A0

I could be convinced that this draft explai= ns why we want ECT(1) back well enough that it's not necessary to actua= lly read 3540, and since we're declaring 3540 Historic, we actually kin= da hope no one reads it in the future except archaeologists in cyberspace.<= /div>

But unless that reference really is informational,= it remains a normative downref that was omitted from the Last Call announc= ement.

David, I don't mind re-issuing the Last= Call announcement if you think still think the reference is normative, but= you might want to take a look at the text in the draft, and see how badly = it needs to be normative, before letting me know.

= Spencer
--001a114166d4c898960558392c79-- From nobody Mon Sep 4 19:09:18 2017 Return-Path: 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 A41AA1321A6; Mon, 4 Sep 2017 19:09:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 fh_idjb2qMm3; Mon, 4 Sep 2017 19:09:09 -0700 (PDT) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (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 587A0126C19; Mon, 4 Sep 2017 19:09:09 -0700 (PDT) Received: by mail-yw0-x22a.google.com with SMTP id w204so7690162ywg.3; Mon, 04 Sep 2017 19:09:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=J7Lr1tc9qlUUa0fpzxF0LpD0f2RQ2zpSTgiERB+3RBc=; b=BUFRW1SV2O6vnuQA74dsxt4U+PkkLgrS9j/c0xYlVsgmozgK3G5SYRUSGveMSxK23/ de08SGoybUqXeMVXHT7Y9OmYY3IEQDm7a3R6zqkPci/PYcwjugw3HYcOeQHmnCXbJttF sn9vr+bp4eqguPFwHToprfx3eZ1Ltb20D62nipLnroMtxq0xTEaA3DgS8hXI5+vzm/+B LBzFxeZ5C0jBuiyFNsAHY2CqH5lSp7SYwgvTO9Zba7h+NTPKuDinvnnO6LAxM4zZe0qE xrk0+OhYOTujDm0q2uCiLLdr2kPyOyTaAl0vfrFKnSaouvTBYVYC3w+kTTWKkBIuC5rt pPbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=J7Lr1tc9qlUUa0fpzxF0LpD0f2RQ2zpSTgiERB+3RBc=; b=IGuDHgvarE+rKa9ytX6r62S+XpsX3YYmtCweB3cjyZWmn5ksLNN0JE6VnvxggKcuqH eFQFmN8/OzzPR+ITfy/K2MW7itn8jrndEHjNkuM67azsDD9CWGBG9rJ56Zh3AzLk18nN tzmju6PkTe93D0Tu5IrMOSpFExetGu48CQuO4QaDTNs6EeLWg6a9oGzFVLVjyHObo4os iogTkPCf5zNJmjVD0eiXfTkokgyAWY/cB58zqDNUuv/1HYWAP8vxc0lJn4c+NPSbK8Jy CDSAx9jMrPQVo1DUF8yijl7ci7UZvVxcb2g1KgjFSiOOTM+iUsO9lw1rDheu7qBZfd3X qijw== X-Gm-Message-State: AHPjjUhVoj00Gyg0hSHqJLSqlDyVURTABE8CCBUPm/C+QXSQ+oOygV8Q gJd2P7CYPi2VsymvNNTS4vX0ns+R3A== X-Google-Smtp-Source: ADKCNb6DSPwszHAOzNiSSQGfamORoKB80MvvVFksqC8RRdf+AhvD1W+Of7mnaPYXU0uZ8D5o1q3SpIWIStYQ0sHk+Ag= X-Received: by 10.37.108.86 with SMTP id h83mr1937064ybc.211.1504577348505; Mon, 04 Sep 2017 19:09:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.2.148 with HTTP; Mon, 4 Sep 2017 19:09:08 -0700 (PDT) Received: by 10.37.2.148 with HTTP; Mon, 4 Sep 2017 19:09:08 -0700 (PDT) In-Reply-To: References: <150423129417.4604.2689843099266054478@ietfa.amsl.com> <6afe85ba-83c5-5945-fd37-dc313eb22162@gmail.com> From: Spencer Dawkins at IETF Date: Mon, 4 Sep 2017 21:09:08 -0500 Message-ID: To: Brian E Carpenter Cc: "draft-ietf-tsvwg-ecn-experimentation.all@ietf.org" , "Black, David" , "gen-art@ietf.org" , "tsvwg@ietf.org" Content-Type: multipart/alternative; boundary="001a1148ac346517b7055867b6db" Archived-At: Subject: Re: [tsvwg] Genart telechat review of draft-ietf-tsvwg-ecn-experimentation-05 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 02:09:10 -0000 --001a1148ac346517b7055867b6db Content-Type: text/plain; charset="UTF-8" Just to end the suspense, On Sep 2, 2017 13:37, "Spencer Dawkins at IETF" < spencerdawkins.ietf@gmail.com> wrote: Hi, Brian, On Fri, Sep 1, 2017 at 6:41 PM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > On 02/09/2017 09:45, Black, David wrote: > > Brian, > > > > Thanks for the prompt review. > > > >> Comment: Very clear from the technical standpoint. > > > > Thank you! > > > >> I understand the desire for brevity, but this bothers me a bit. What is > >> the reader to make of RFC3168 Section 20.2, for example? My feeling is > >> that a short Appendix outlining the specific updates would be useful. > >> There's already too much spaghetti to untangle. > > > > RFC 3168 Section 20.2 is the rationale for the ECN Nonce and hence would > be > > deleted. Request noted, I'll consult with the draft shepherd and > responsible > > AD to figure out whether to do this. > > Thanks. It's not intended as a blocking issue. > > > > >> I see no reason why RFC3540 and RFC5622 need to be normative references > >> (and therefore downrefs). They aren't required reading in order to > >> understand this draft. > > > > OTOH, both are affected by this draft: > > > > In reverse order, this draft updates RFC 5622 - that seems to merit a > > normative reference. This draft also provides the rationale for the > > status change of RFC 3540 to Historic, which also seems to merit a > > normative reference. > > Well, my understanding is that a normative reference is needed only > when the citing document cannot be understood and implemented > without reading the cited document. > > Again it's not a blocking comment - although there is a technical error > in the Last Call message: it flags the downref to 5622, but not that to > 3540. > I don't know if that's a tool error or an AD error ;-). As Bran is too polite to say, the AD sees the generated Last Call announcement before it's sent. I just regenerated the Last Call announcement, and it's still only naming one draft as a normative downref. But the AD didn't notice that, so blaming the tools was the wrong answer :-) It's a 3-day weekend in the US, so any updated Last Call announcement won't go out until Tuesday, anyway. So, let's talk about that. I just re-read the draft, focusing on the places where it refers to RFC 3540. This draft explains the ECN Nonce experiment inline, although it cites 3540 as its reference, and explains that the experiment required ECT(0) and ECT(1), but the experiment is over, and hasn't been deployed on the Internet in any significant way, so we want ECT(1) back, for other experiments. It also refers to 3540 when it changes a registration in the Transmission Control Protocol (TCP) Header Flags registry, but I believe this draft explains the IANA actions requested well enough that IANA wouldn't need to read 3540 to carry out the requested action. I could be convinced that this draft explains why we want ECT(1) back well enough that it's not necessary to actually read 3540, and since we're declaring 3540 Historic, we actually kinda hope no one reads it in the future except archaeologists in cyberspace. But unless that reference really is informational, it remains a normative downref that was omitted from the Last Call announcement. David, I don't mind re-issuing the Last Call announcement if you think still think the reference is normative, but you might want to take a look at the text in the draft, and see how badly it needs to be normative, before letting me know. Spencer Mirja and I talked this morning, and the score is It's normative:2 It's informative:2 between me, Brian, David, and Mirja, so I took that as a sign that moving that reference to Informative References isn't obviously ok. I edited the Last Call text and re-issued the Last Call requests for both the draft and the status change document, so they stay in sync. The Secretariat was likely off today (US Labor Day), so it might take a day for the Last Calls to pop out. Thanks to everyone for your help. Spencer --001a1148ac346517b7055867b6db Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Just to end the suspense,

On Sep 2, 2017 13:37, "Spencer Dawk= ins at IETF" <spen= cerdawkins.ietf@gmail.com> wrote:
Hi, Brian,

On Fri, Sep 1, 2017 at = 6:41 PM, Brian E Carpenter <brian.e.carpenter@gmail.com><= /span> wrote:
On 02/09/2017 09:45, Black, David wrote= :
> Brian,
>
> Thanks for the prompt review.
>
>> Comment: Very clear from the technical standpoint.
>
> Thank you!
>
>> I understand the desire for brevity, but this bothers me a bit. Wh= at is
>> the reader to make of RFC3168 Section 20.2, for example? My feelin= g is
>> that a short Appendix outlining the specific updates would be usef= ul.
>> There's already too much spaghetti to untangle.
>
> RFC 3168 Section 20.2 is the rationale for the ECN Nonce and hence wou= ld be
> deleted. Request noted, I'll consult with the draft shepherd and r= esponsible
> AD to figure out whether to do this.

Thanks. It's not intended as a blocking issue.

>
>> I see no reason why RFC3540 and RFC5622 need to be normative refer= ences
>> (and therefore downrefs). They aren't required reading in orde= r to
>> understand this draft.
>
> OTOH, both are affected by this draft:
>
> In reverse order, this draft updates RFC 5622 - that seems to merit a<= br> > normative reference.=C2=A0 =C2=A0 This draft also provides the rationa= le for the
> status change of RFC 3540 to Historic, which also seems to merit a
> normative reference.

Well, my understanding is that a normative reference is needed only<= br> when the citing document cannot be understood and implemented
without reading the cited document.

Again it's not a blocking comment - although there is a technical error=
in the Last Call message: it flags the downref to 5622, but not that to 354= 0.
I don't know if that's a tool error or an AD error ;-).

As Bran is too polite to say, the AD sees the ge= nerated Last Call announcement before it's sent.=C2=A0

I just regenerated the Last Call announcement, and it's still = only naming one draft as a normative downref. But the AD didn't notice = that, so blaming the tools was the wrong answer :-)

It's a 3-day weekend in the US, so any updated Last Call announcement= won't go out until Tuesday, anyway.=C2=A0

So,= let's talk about that.

I just re-read the dra= ft, focusing on the places where it refers to RFC 3540.=C2=A0
This draft explains the ECN Nonce experiment inline, although i= t cites 3540 as its reference, and explains that the experiment required EC= T(0) and ECT(1), but the experiment is over, and hasn't been deployed o= n the Internet in any significant way, so we want ECT(1) back, for other ex= periments.

It also refers to 3540 when it changes = a registration in the Transmission Control Protocol (TCP) Header Flags regi= stry, but I believe this draft explains the IANA actions requested well eno= ugh that IANA wouldn't need to read 3540 to carry out the requested act= ion.=C2=A0

I could be convinced that this draft ex= plains why we want ECT(1) back well enough that it's not necessary to a= ctually read 3540, and since we're declaring 3540 Historic, we actually= kinda hope no one reads it in the future except archaeologists in cyberspa= ce.

But unless that reference really is informatio= nal, it remains a normative downref that was omitted from the Last Call ann= ouncement.

David, I don't mind re-issuing the = Last Call announcement if you think still think the reference is normative,= but you might want to take a look at the text in the draft, and see how ba= dly it needs to be normative, before letting me know.

Spencer

= Mirja and I talked this morning, and the score is=C2=A0

It's normative:2
It's= informative:2

between me, Brian, David, and Mirja, so = I took that as a sign that moving that reference to Informative References = isn't obviously ok.

I edited the Last Call text and= re-issued the Last Call requests for both the draft and the status change = document, so they stay in sync.

The Secretariat was lik= ely off today (US Labor Day), so it might take a day for the Last Calls to = pop out.

Thanks to everyone for your help.

Spencer
--001a1148ac346517b7055867b6db-- From nobody Tue Sep 5 08:38:19 2017 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 517C9132D54; Tue, 5 Sep 2017 08:38:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.60.0 Auto-Submitted: auto-generated Precedence: bulk CC: gorry@erg.abdn.ac.uk, tsvwg@ietf.org, draft-ietf-tsvwg-ecn-experimentation@ietf.org, spencerdawkins.ietf@gmail.com, Gorry Fairhurst , tsvwg-chairs@ietf.org Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <150462589132.14449.3312088028036891617.idtracker@ietfa.amsl.com> Date: Tue, 05 Sep 2017 08:38:11 -0700 Archived-At: Subject: [tsvwg] Last Call: (Explicit Congestion Notification (ECN) Experimentation) to Proposed Standard X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 15:38:11 -0000 The IESG has received a request from the Transport Area Working Group WG (tsvwg) to consider the following document: - 'Explicit Congestion Notification (ECN) Experimentation' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2017-09-19. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This memo updates RFC 3168, which specifies Explicit Congestion Notification (ECN) as a replacement for packet drops as indicators of network congestion. It relaxes restrictions in RFC 3168 that would otherwise hinder experimentation towards benefits beyond just removal of loss. This memo summarizes the anticipated areas of experimentation and updates RFC 3168 to enable experimentation in these areas. An Experimental RFC is required to take advantage of any of these enabling updates. In addition, this memo makes related updates to the ECN specifications for RTP in RFC 6679 and for DCCP in RFC 4341, RFC 4342 and RFC 5622. This memo also records the conclusion of the ECN Nonce experiment in RFC 3540, and provides the rationale for reclassification of RFC 3540 as Historic; this reclassification enables new experimental use of the ECT(1) codepoint. Please note that this is a second Last Call, necessary because the first Last Call announcement omitted notification of a normative downref to RFC 3540, the document being moved to Historic. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-experimentation/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-experimentation/ballot/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: rfc5622: Profile for Datagram Congestion Control Protocol (DCCP) Congestion ID 4: TCP-Friendly Rate Control for Small Packets (TFRC-SP) (Experimental - IETF stream) rfc3540: Robust Explicit Congestion Notification (ECN) Signaling with Nonces (Experimental - IETF stream) From nobody Wed Sep 6 07:58:58 2017 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 19AC1132494; Wed, 6 Sep 2017 07:58:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.60.0 Auto-Submitted: auto-generated Precedence: bulk Cc: gorry@erg.abdn.ac.uk, The IESG , tsvwg@ietf.org, spencerdawkins.ietf@gmail.com, Gorry Fairhurst , draft-ietf-tsvwg-sctp-ndata@ietf.org, rfc-editor@rfc-editor.org, tsvwg-chairs@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Message-ID: <150470992509.15252.984721263190960109.idtracker@ietfa.amsl.com> Date: Wed, 06 Sep 2017 07:58:45 -0700 Archived-At: Subject: [tsvwg] Protocol Action: 'Stream Schedulers and User Message Interleaving for the Stream Control Transmission Protocol' to Proposed Standard (draft-ietf-tsvwg-sctp-ndata-13.txt) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Sep 2017 14:58:45 -0000 The IESG has approved the following document: - 'Stream Schedulers and User Message Interleaving for the Stream Control Transmission Protocol' (draft-ietf-tsvwg-sctp-ndata-13.txt) as Proposed Standard This document is the product of the Transport Area Working Group. The IESG contact persons are Mirja Kühlewind and Spencer Dawkins. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-ndata/ Technical Summary The Stream Control Transmission Protocol (SCTP) is a message oriented transport protocol supporting arbitrarily large user messages. This document adds a new chunk to SCTP for carrying payload data. This allows a sender to interleave different user messages that would otherwise result in head of line blocking at the sender. The interleaving of user messages is required for WebRTC Datachannels. Whenever an SCTP sender is allowed to send user data, it may choose from multiple outgoing SCTP streams. Multiple ways for performing this selection, called stream schedulers, are defined. A stream scheduler can choose to either implement, or not implement, user message interleaving. Working Group Summary Nothing out of the ordinary. Document Quality This document is one of several relating to WebRTC Datachannels, and has received inputs from other related WGs. The FreeBSD kernel implementation and the userland stack usrsctp (which shares most of the code) both support sending and receiving of I-DATA chunks. An implementation of interleaving schedulers was planned for the IETF 99 timeframe. Personnel Who is the Document Shepherd? Gorry Fairhurst Who is the Responsible Area Director? Spencer Dawkins From nobody Fri Sep 8 11:35:40 2017 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 05D2A132D47; Fri, 8 Sep 2017 11:35:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tsvwg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.60.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150489573199.17168.12901470642025184308@ietfa.amsl.com> Date: Fri, 08 Sep 2017 11:35:32 -0700 Archived-At: Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-ieee-802-11-07.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Sep 2017 18:35:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group WG of the IETF. Title : Diffserv to IEEE 802.11 Mapping Authors : Tim Szigeti Jerome Henry Fred Baker Filename : draft-ietf-tsvwg-ieee-802-11-07.txt Pages : 35 Date : 2017-09-08 Abstract: As internet traffic is increasingly sourced-from and destined-to wireless endpoints, it is crucial that Quality of Service be aligned between wired and wireless networks; however, this is not always the case by default. This document specifies a set Differentiated Services Code Point (DSCP) to IEEE 802.11 User Priority (UP) mappings to reconcile the marking recommendations offered by the IETF and the IEEE so as to maintain consistent QoS treatment between wired and IEEE 802.11 wireless networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ieee-802-11/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tsvwg-ieee-802-11-07 https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-ieee-802-11-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-ieee-802-11-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Sep 11 13:11:42 2017 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FD961331F2 for ; Mon, 11 Sep 2017 13:11:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.60.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150516070112.9840.4495165963731892027.idtracker@ietfa.amsl.com> Date: Mon, 11 Sep 2017 13:11:41 -0700 From: IETF Secretariat Archived-At: Subject: [tsvwg] Milestones changed for tsvwg WG X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Sep 2017 20:11:41 -0000 Changed milestone "Submit "Guidelines for DiffServ to IEEE 802.11 Mapping" as a Proposed Standard RFC", resolved as "Done". Changed milestone "Submit 'Tunnel Congestion Feedback' as an Informational RFC", set due date to December 2018 from April 2017. URL: https://datatracker.ietf.org/wg/tsvwg/about/ From nobody Mon Sep 11 13:31:33 2017 Return-Path: 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 24276132A65 for ; Mon, 11 Sep 2017 13:31:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.5 X-Spam-Level: X-Spam-Status: No, score=-5.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dell.com header.b=U87o9Uk6; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=lgUm92Bc 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 xJ8igbaBuiek for ; Mon, 11 Sep 2017 13:31:30 -0700 (PDT) Received: from esa6.dell-outbound.iphmx.com (esa6.dell-outbound.iphmx.com [68.232.149.229]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5702D132351 for ; Mon, 11 Sep 2017 13:31:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1505161890; x=1536697890; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=aB6mm2ROlu+7SKirpHHO5A3+po9bwwzex9lOkJeJze8=; b=U87o9Uk6bYX+L8EBSdv4pfrQRCXHr9cWNUZbMlsa3dFd0JLlcKCABL+1 yySjAt/ZQxuh8ayFC6w6uhje75/RrO5pZ9BPIwsfm2WmeXdXcSyhESEQR lzeFM8J+U1tfCNqf5ARBw0PKCfszTSOyqtqFcM7Z4dHqzwyi5XEtm0aCM 4=; Received: from esa6.dell-outbound2.iphmx.com ([68.232.154.99]) by esa6.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Sep 2017 15:31:28 -0500 From: "Black, David" Received: from mailuogwhop.emc.com ([168.159.213.141]) by esa6.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Sep 2017 02:31:28 +0600 Received: from maildlpprd05.lss.emc.com (maildlpprd05.lss.emc.com [10.253.24.37]) by mailuogwprd04.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v8BKVR9E016665 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 11 Sep 2017 16:31:27 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com v8BKVR9E016665 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1505161887; bh=VSU+HssMwMzZ1zMVbXnSWDF9cyQ=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=lgUm92BcNOtDpPzlcFMwyKFzAR4TCFkDorBjyDKk8rEpgBk+EJ1I1niON1Q0++ydh hlL4mDrU9ydIfiKxGrmzzp3foXW+XS09Dbm6dRzeNKN49JnyiFyQ61YTBaK1KN6xZ2 dmTf4Nweri3g8dI+Bq1Ro9xT0Nb/O3RaMcOJHUbU= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com v8BKVR9E016665 Received: from mailusrhubprd52.lss.emc.com (mailusrhubprd52.lss.emc.com [10.106.48.25]) by maildlpprd05.lss.emc.com (RSA Interceptor) for ; Mon, 11 Sep 2017 16:30:40 -0400 Received: from MXHUB305.corp.emc.com (MXHUB305.corp.emc.com [10.146.3.31]) by mailusrhubprd52.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v8BKSr0B006906 (version=TLSv1.2 cipher=AES128-SHA256 bits=128 verify=FAIL) for ; Mon, 11 Sep 2017 16:31:08 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB305.corp.emc.com ([10.146.3.31]) with mapi id 14.03.0352.000; Mon, 11 Sep 2017 16:30:55 -0400 To: "tsvwg@ietf.org" Thread-Topic: [tsvwg] Milestones changed for tsvwg WG Thread-Index: AQHTKzoy8nKeTH0hLkeYlp6tWhv8qqKwIRjw Date: Mon, 11 Sep 2017 20:30:54 +0000 Message-ID: References: <150516070112.9840.4495165963731892027.idtracker@ietfa.amsl.com> In-Reply-To: <150516070112.9840.4495165963731892027.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.44.138] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd52.lss.emc.com X-RSA-Classifications: public Archived-At: Subject: Re: [tsvwg] Milestones changed for tsvwg WG X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Sep 2017 20:31:32 -0000 Rmlyc3Qgb2YgYWxsLCB0aGlzIHJlZmxlY3RzIHN1Ym1pc3Npb24gb2YgdGhlIFJGQyBQdWJsaWNh dGlvbiByZXF1ZXN0IGZvciB0aGUgRGlmZnNlcnYgdG8gODAyLjExIGRyYWZ0IC0gbWFueSB0aGFu a3MgdG8gYWxsIHdobyBoYXZlIGNvbnRyaWJ1dGVkIHRvIGdldHRpbmcgdGhhdCBkcmFmdCB0byB0 aGlzIHN0YWdlLg0KDQpUaGUgb3RoZXIgbWlsZXN0b25lIHVwZGF0ZSByZWZsZWN0cyB0aGUgVHVu bmVsIENvbmdlc3Rpb24gRmVlZGJhY2sgZHJhZnQgcmV0dXJuaW5nIHRvIHRoZSBXRyBmb3IgZnVy dGhlciB3b3JrLg0KDQpBdCB0aGlzIHBvaW50LCB3ZSdyZSBhY3R1YWxseSBvbiBzY2hlZHVsZSB3 cnQgb3VyIG1pbGVzdG9uZXMgLi4uIG5pY2UuDQoNClRoYW5rcywgLS1EYXZpZA0KDQoNCj4gLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogdHN2d2cgW21haWx0bzp0c3Z3Zy1ib3Vu Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSUVURiBTZWNyZXRhcmlhdA0KPiBTZW50OiBNb25k YXksIFNlcHRlbWJlciAxMSwgMjAxNyA0OjEyIFBNDQo+IFRvOiB0c3Z3Z0BpZXRmLm9yZw0KPiBT dWJqZWN0OiBbdHN2d2ddIE1pbGVzdG9uZXMgY2hhbmdlZCBmb3IgdHN2d2cgV0cNCj4gDQo+IENo YW5nZWQgbWlsZXN0b25lICJTdWJtaXQgIkd1aWRlbGluZXMgZm9yIERpZmZTZXJ2IHRvIElFRUUg ODAyLjExIE1hcHBpbmciDQo+IGFzDQo+IGEgUHJvcG9zZWQgU3RhbmRhcmQgUkZDIiwgcmVzb2x2 ZWQgYXMgIkRvbmUiLg0KPiANCj4gQ2hhbmdlZCBtaWxlc3RvbmUgIlN1Ym1pdCAnVHVubmVsIENv bmdlc3Rpb24gRmVlZGJhY2snIGFzIGFuDQo+IEluZm9ybWF0aW9uYWwNCj4gUkZDIiwgc2V0IGR1 ZSBkYXRlIHRvIERlY2VtYmVyIDIwMTggZnJvbSBBcHJpbCAyMDE3Lg0KPiANCj4gVVJMOiBodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL3dnL3RzdndnL2Fib3V0Lw0KDQo= From nobody Tue Sep 12 19:56:06 2017 Return-Path: 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 680DF1333E0; Tue, 12 Sep 2017 19:56:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 PX84_kVf5Xbe; Tue, 12 Sep 2017 19:56:01 -0700 (PDT) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::22c]) (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 F27F913292F; Tue, 12 Sep 2017 19:56:00 -0700 (PDT) Received: by mail-yw0-x22c.google.com with SMTP id s62so32213564ywg.0; Tue, 12 Sep 2017 19:56:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=lr5xgTBJJsFu87e4pUSPX3f2vccMYM+lrJ2dUlVVEjw=; b=Ahwu7tZIEdIlvtXZj2MrVnbXlqqOiTZiNRcWv67SolK3zLPiaZF7j3jaVX8hyXhT/v z5ihN/42BZZADf9b/NIra+7+AXFAbDbLobt4LHpgJpYzp7RBRmv+YWxUXINjiMva5KOx qmFXaxX0AMeQU+W8i9yjTXkq1NevCK8UenYhg6ytNgceT2myf5o0T7pywt8F2aB7m1KW iob0qD3VQkxHNrlWV1GAa1TKVgmES4rWk6AVp9wCLUv9SoDyzd/d63oiC1S9Jq0ueEzV aV6KEmUH+4fnPWB8ymHC4wOqHQZS09Sm1w4Y6dl3qkB+Hs5/RURSCQrNpcpttPw9dLO8 OXww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=lr5xgTBJJsFu87e4pUSPX3f2vccMYM+lrJ2dUlVVEjw=; b=B8hcL8eq/jnXiFsvpUuhyzxBPth+TVYS9zi19DruGTL38rbPVDA1rZM1u+CZof8uh+ SWarwNNEFvJaDeq+B0+JX6y0HPbLSrJjd7vQI13lcOui50WEQuiVqrDz8Tgp6VuZZmkh kAQxA46175W4WmEOKHzeD8bPz5o6cjS85/OcxBKx7QqSdWDSqNKueXLFVvH+Q6e65Nbp gNwfbYLHAY6+ubeRHCCwVOA8SQPC9ZvLa5xKOsEOupdwtCR4CrM7Td71fwpaXOVM2N/Q caAFqq8SzU8NyRzeFlsdw+gawL2VOhR/IqsRmzfHFfXObFgHmuTwJqYlDDct5w6cHhg4 rVcQ== X-Gm-Message-State: AHPjjUjIj+i0MnrCF+562lga1HqPvFHLRfYQAkvwL63bcNYsLYgyzCAB o0aF+mYhkrwozQ/f8mPpio3kFpkSaxlHtcvj3ahoMQ== X-Google-Smtp-Source: AOwi7QDgHpui7dsu7dbbIm3tQSxNXLGMe+K3Ka6soNKHWIh9XocbmDdeDWd81LB2KR1eaKtjLkOyOsPOlqSgmi7Dvp0= X-Received: by 10.37.216.14 with SMTP id p14mr11838989ybg.75.1505271359865; Tue, 12 Sep 2017 19:55:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.2.15 with HTTP; Tue, 12 Sep 2017 19:55:59 -0700 (PDT) From: Spencer Dawkins at IETF Date: Tue, 12 Sep 2017 21:55:59 -0500 Message-ID: To: David Black Cc: "David L. Black" , "tsvwg@ietf.org" , draft-ietf-tsvwg-ieee-802-11@ietf.org Content-Type: multipart/alternative; boundary="001a114fd3b2b207930559094c71" Archived-At: Subject: [tsvwg] AD Evaluation comments for draft-ietf-tsvwg-ieee-802-11-07 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Sep 2017 02:56:03 -0000 --001a114fd3b2b207930559094c71 Content-Type: text/plain; charset="UTF-8" This was a very dense read, and I found only a few things to ask about, and half of those are nits. Nice work. Please take a look at my evaluation comments, and let me know how you'd like to proceed. Thanks, as always. Spencer Nit, but it's in the Abstract ... This document specifies a set Differentiated Services Code Point (DSCP) to IEEE 802.11 User Priority (UP) mappings should this be "... set of Differentiated Services Code Point ..."? I'm looking at this text, There is also a recommendation from the Global System for Mobile Communications Association (GSMA), specifically their Mapping Quality of Service (QoS) Procedures of Proxy Mobile IPv6 (PMIPv6) and WLAN [RFC7561] specification. This GSMA specification was developed without reference to existing IETF specifications for various services, referenced in Section 1.1. and I'm not quite sure how an IETF-stream Informational RFC produced by a working group becomes "a recommendation from GSMA" and "a GSMA specification". I recognize the names of the RFC 7561 authors, and I see the connection, but I would have thought that the reference would have been to something more obviously tied to GSMA. Is there any reference that could be cited, to help people who didn't sit two desks away from one of the authors see the connection? In this text, This document assumes and RECOMMENDS that all wireless access points (as the bridges between wired-and-wireless networks) support the ability to: is "bridges" the right word here? I would read that as saying that wireless access points are a layer two-layer two bridge. If you have readers who are familiar with IEEE 802.1 bridging, they may be more confused than I was. A nit - "unusued" -> "unused" I really appreciate the inclusion of Section 6, as an overview of IEEE 802.11 QoS. I'd suggest that this not be titled as "Appendix" - which https://www.rfc-editor.org/rfc/pdfrfc/rfc7322.txt.pdf doesn't think is part of an RFC body, so at a minimum they would move it behind the security considerations, but I'd be OK if you left it as a normal Section in the body. Alternatively, if you're happier with this material as an Appendix, it's probably better to slide it to the back material. A nit - "oftheir" -> "of their" I'm looking at the last paragraph of the Security Considerations, and I'm thinking that Finally, it should be noted that the recommendations put forward in this document are not intended to address all attack vectors leveraging QoS marking abuse. Mechanisms that may further help mitigate security risks include strong device- and/or user- authentication, access-control, rate limiting, control-plane policing, encryption and other techniques; however, the implementation recommendations for such mechanisms are beyond the scope of this document to address in detail. Suffice it to say that the security of the devices and networks implementing QoS, including QoS mapping between wired and wireless networks, SHOULD be considered in actual deployments. is missing the (perhaps obvious) point that the mechanisms you list under "further help" aren't specific to wireless networks, but should be considered for any network that implements QoS. That might be covered in the last sentence, but that's not what I'm getting out of the last sentence. --001a114fd3b2b207930559094c71 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This was a very dense read, and= I found only a few things to ask about, and half of those are nits.
<= div class=3D"gmail_extra">
Nice work.

Please = take a look at my evaluation comments, and let me know how you'd like t= o proceed.

Thanks, as always.

Spencer

Nit, but it's in the Abs= tract ...

=C2=A0 =C2=A0This document specifies a set Differentiated
=C2=A0 =C2=A0Services Code Point (DSCP) to IEEE 802.11 U= ser Priority (UP) mappings
=C2=A0 =C2=A0
should this be "... set of Differentiate= d Services Code Point ..."?

=
I'm looking at this text,

=C2=A0 =C2=A0There is al= so a recommendation from the Global System for Mobile
=C2=A0 =C2=A0Communications Association (GSMA), specifically the= ir Mapping Quality
=C2=A0 =C2=A0of Service = (QoS) Procedures of Proxy Mobile IPv6 (PMIPv6) and WLAN
=C2=A0 =C2=A0[RFC7561] specification.=C2=A0 This GSMA specific= ation was developed
=C2=A0 =C2=A0without re= ference to existing IETF specifications for various
=C2=A0 =C2=A0services, referenced in Section 1.1. =C2=A0
=C2=A0 =C2=A0
and I&= #39;m not quite sure how an IETF-stream Informational RFC produced by a wor= king group becomes "a recommendation from GSMA" and "a GSMA = specification". I recognize the names of the RFC 7561 authors, and I s= ee the connection, but I would have thought that the reference would have b= een to something more obviously tied to GSMA. Is there any reference that c= ould be cited, to help people who didn't sit two desks away from one of= the authors see the connection?

=
In this text,
=C2=A0 =C2=A0This document assumes and R= ECOMMENDS that all wireless access points
= =C2=A0 =C2=A0(as the bridges between wired-and-wireless networks) support t= he
=C2=A0 =C2=A0ability to:
=C2=A0 =C2=A0
is "bri= dges" the right word here? I would read that as saying that wireless a= ccess points are a layer two-layer two bridge. If you have readers who are = familiar with IEEE 802.1 bridging, they may be more confused than I was.

A nit - = "unusued" -> "unused"

I really appreciate the inclusion of= Section 6, as an overview of IEEE 802.11 QoS. I'd suggest that this no= t be titled as "Appendix" - which https://www.rfc-editor.org/rfc/pdfrfc/rf= c7322.txt.pdf doesn't think is part of an RFC body, so at a minimum= they would move it behind the security considerations, but I'd be OK i= f you left it as a normal Section in the body. Alternatively, if you're= happier with this material as an Appendix, it's probably better to sli= de it to the back material.

A nit - "oftheir" -> "of their"= ;

I'm looking at the last paragraph of the Security Consideratio= ns, and I'm thinking that

=C2=A0 =C2=A0Finally, it= should be noted that the recommendations put forward in
=C2=A0 =C2=A0this document are not intended to address all at= tack vectors
=C2=A0 =C2=A0leveraging QoS ma= rking abuse.=C2=A0 Mechanisms that may further help
=C2=A0 =C2=A0mitigate security risks include strong device- and/or= user-
=C2=A0 =C2=A0authentication, access-= control, rate limiting, control-plane
=C2= =A0 =C2=A0policing, encryption and other techniques; however, the
=C2=A0 =C2=A0implementation recommendations for such= mechanisms are beyond the
=C2=A0 =C2=A0sco= pe of this document to address in detail.=C2=A0 Suffice it to say that
=C2=A0 =C2=A0the security of the devices and ne= tworks implementing QoS, including
=C2=A0 = =C2=A0QoS mapping between wired and wireless networks, SHOULD be considered=
=C2=A0 =C2=A0in actual deployments.
<= div class=3D"gmail_extra">
is missing t= he (perhaps obvious) point that the mechanisms you list under "further= help" aren't specific to wireless networks, but should be conside= red for any network that implements QoS. That might be covered in the last = sentence, but that's not what I'm getting out of the last sentence.=
--001a114fd3b2b207930559094c71-- From nobody Tue Sep 12 21:42:50 2017 Return-Path: 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 7B71B133B33; Tue, 12 Sep 2017 21:42:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, SPF_PASS=-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 ycXCgZToFts9; Tue, 12 Sep 2017 21:42:48 -0700 (PDT) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (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 D86B91243F6; Tue, 12 Sep 2017 21:42:47 -0700 (PDT) Received: by mail-wm0-x231.google.com with SMTP id g206so4079236wme.0; Tue, 12 Sep 2017 21:42:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=z6f3FAuCaLyL4VsaQExGfRL5jCX+BDSfHullF7Uf+1I=; b=GET+aM8lV/KZksMQ3xrDxY8yMAJcbMmMQj7w9NYQYG8xRlGRjrbEIGXlzJ170RPWOu yl6413LRi2ynaCdaBC28Ha/lwSRxXz5tsNp7/tcxNrrlEBSBpC3U0Pi6GylyXhKXinQN R1rY7ReViul5v1UQeCxAmuXebYw4WrKAlMoPcf+VE12q/GlkExcXH858LwS7j5upf5Dw uXo+MmNKBtFgxhzI1DbQNnQcWHci9l0SA5SOizrp6g2IboA5c5OzOGmBxne2PdEqSAdP QaVYCX/M082O93+7betQosOkYClCGZ+hoK6LSAmy/qyG+ydEL6gM1XoeJy1iRTdRbwvK VHxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=z6f3FAuCaLyL4VsaQExGfRL5jCX+BDSfHullF7Uf+1I=; b=obBZPzbFy2WYSuImcutzeMgvYTXSYICplkZ2KXL8P58uV8FNhPnBOtx0wUXd0Nn/mO k+4k90pdvT9IEgMkCI++1Uswzg4/3xrZcweO9kPdfAse7yFYlyhetxTXwe0rq4AZJqv0 aNnqjzeBMv1JdD8QQXmbE+r2F+eY4ElQTZmc/0YPfXcyCU/nEj6UfcdQyWbLBr1nNC1a H1WWORsofQZ+JltqiIS3G6wWmM9teCVj3C6VeZRWpHQuag9viiqCEXJ4RIvsKfRmmLF+ ImxjcBK1/fmyAr/jTqcFq/bxtpI8lD6Im05vCDlDfNg8VGKwDz/7PZQsh2UTsSw4+PaZ pwPw== X-Gm-Message-State: AHPjjUgbZGYEnuE44ft/kwmA0e1pc1jTxImMmbpKBpn+a9Ug5nSSrR1R o9W//6LstU4hdA== X-Google-Smtp-Source: AOwi7QC+oeaB1mltYUyq8Evk7eDPb2NtEuY25YMAvCh7ry/i2oP3mMBff0gqPTgfByZSX5/VYBHz9g== X-Received: by 10.28.99.84 with SMTP id x81mr1249570wmb.148.1505277766095; Tue, 12 Sep 2017 21:42:46 -0700 (PDT) Received: from ?IPv6:2601:646:c005:a10:b546:44b4:f5bc:2d37? ([2601:646:c005:a10:b546:44b4:f5bc:2d37]) by smtp.gmail.com with ESMTPSA id p71sm300191wmd.40.2017.09.12.21.42.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 12 Sep 2017 21:42:45 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.6\)) From: Fred Baker In-Reply-To: Date: Tue, 12 Sep 2017 21:42:42 -0700 Cc: David Black , "David L. Black" , "tsvwg@ietf.org" , draft-ietf-tsvwg-ieee-802-11@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Spencer Dawkins at IETF X-Mailer: Apple Mail (2.3445.1.6) Archived-At: Subject: Re: [tsvwg] AD Evaluation comments for draft-ietf-tsvwg-ieee-802-11-07 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Sep 2017 04:42:49 -0000 On Sep 12, 2017, at 7:55 PM, Spencer Dawkins at IETF = wrote: >=20 > I'm looking at this text, >=20 > There is also a recommendation from the Global System for Mobile > Communications Association (GSMA), specifically their Mapping = Quality > of Service (QoS) Procedures of Proxy Mobile IPv6 (PMIPv6) and WLAN > [RFC7561] specification. This GSMA specification was developed > without reference to existing IETF specifications for various > services, referenced in Section 1.1. =20 > =20 > and I'm not quite sure how an IETF-stream Informational RFC produced = by a working group becomes "a recommendation from GSMA" and "a GSMA = specification". I recognize the names of the RFC 7561 authors, and I see = the connection, but I would have thought that the reference would have = been to something more obviously tied to GSMA. Is there any reference = that could be cited, to help people who didn't sit two desks away from = one of the authors see the connection? You might take a look at RFC 7561 section 4.2 and reference [6]. It says = that it mandates GSMA-specified DSCP mappings.= From nobody Wed Sep 13 09:42:54 2017 Return-Path: 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 A84351326FE; Wed, 13 Sep 2017 09:42:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.698 X-Spam-Level: X-Spam-Status: No, score=-1.698 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URI_WP_DIRINDEX=1] autolearn=no 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 8onHstD_VArN; Wed, 13 Sep 2017 09:42:45 -0700 (PDT) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (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 B487313305E; Wed, 13 Sep 2017 09:42:45 -0700 (PDT) Received: by mail-yw0-x236.google.com with SMTP id v72so1793198ywa.3; Wed, 13 Sep 2017 09:42:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vNGZugPvMnf/rqcRhJLpdJRerOLjoyz53wqtOgGWLwU=; b=Ni3bcXWwcl6/mPW/B8VwrbqZPw2nOs4g0HBaA/tYB10kZU4PpXxn5bGoIYpja17dsO 4mSzUWF3JoD8RW7bovi+NOYGHsWZjNdvvFELMp9KaBle33P+RXMTcQKrLy+4zUuIUbMA fFVdQjZ2+fIm5mb9BZXFUgRL44Qq/pAyK3SKQ1xSViaaKPCF0Hk48g8IJWAPR6+2d2zR 0nYlZWYRCPaMZLNo7nZLCs63MuScilZD2/k0lRVZf+UtpEMTvNIlowyKQJk8zJK2r4u2 m7usQXRxQ7F+9qHW2l6jlTeAhJ7VbtXgme1bhbbV0kke+Q+BeDZkOP4aFu0Wu65kEtv6 x2VA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=vNGZugPvMnf/rqcRhJLpdJRerOLjoyz53wqtOgGWLwU=; b=pcc47g0nzRPocYP/CXWHBncdCnSogVr6zKpwuYzLLWTwWt0kVwNgBKodR0ahAMgZEN Mu0AIeyXyU6VM9BoZNKhUzcZTD9TmcVUI/5bP0k9/BzQEYoyVUvJzYwVoDsjgb2ctIvF um0NH3EE2aRTIkegQbJBGsVGxBB95d/7MloELVw9jj1Ek9xDN3fPRaYSPj5RxOR0nwDY uwc+XpZE7Q1TSOURPMGe5A3WI20bAAqUlrN6RWtU2fO0iKLIUI2NBqIb2oMImF/cBL2h pdmiJvTmroaCO0d4JjTlKJ0OBG4UKegsSXco5MbWztgVx/eYjh2u63jLKEjuH6E9j0ur 6jzA== X-Gm-Message-State: AHPjjUjyrRbJ+5c0mqQd93AqtypFmQXbIyqpgvv4mztlUXSrshqft1/1 qqCEQMcewmzgJ9SKgzvxJ8eab1qgk1HuNKOaW6o= X-Google-Smtp-Source: ADKCNb7Xx2pc7LKwzxoyir4jGv0u2VxN1T3Pca69dwZKkTtmKxZPep90J8P8bc7kw0h+i5jMlM/KjeFw0BSKZ/3dw08= X-Received: by 10.129.167.67 with SMTP id e64mr9114563ywh.85.1505320964653; Wed, 13 Sep 2017 09:42:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.2.15 with HTTP; Wed, 13 Sep 2017 09:42:44 -0700 (PDT) In-Reply-To: References: From: Spencer Dawkins at IETF Date: Wed, 13 Sep 2017 11:42:44 -0500 Message-ID: To: Fred Baker Cc: David Black , "David L. Black" , "tsvwg@ietf.org" , draft-ietf-tsvwg-ieee-802-11@ietf.org Content-Type: multipart/alternative; boundary="94eb2c146c7e5f0940055914d92c" Archived-At: Subject: Re: [tsvwg] AD Evaluation comments for draft-ietf-tsvwg-ieee-802-11-07 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Sep 2017 16:42:48 -0000 --94eb2c146c7e5f0940055914d92c Content-Type: text/plain; charset="UTF-8" Hi, Fred, On Tue, Sep 12, 2017 at 11:42 PM, Fred Baker wrote: > On Sep 12, 2017, at 7:55 PM, Spencer Dawkins at IETF < > spencerdawkins.ietf@gmail.com> wrote: > > > > I'm looking at this text, > > > > There is also a recommendation from the Global System for Mobile > > Communications Association (GSMA), specifically their Mapping Quality > > of Service (QoS) Procedures of Proxy Mobile IPv6 (PMIPv6) and WLAN > > [RFC7561] specification. This GSMA specification was developed > > without reference to existing IETF specifications for various > > services, referenced in Section 1.1. > > > > and I'm not quite sure how an IETF-stream Informational RFC produced by > a working group becomes "a recommendation from GSMA" and "a GSMA > specification". I recognize the names of the RFC 7561 authors, and I see > the connection, but I would have thought that the reference would have been > to something more obviously tied to GSMA. Is there any reference that could > be cited, to help people who didn't sit two desks away from one of the > authors see the connection? > > You might take a look at RFC 7561 section 4.2 and reference [6]. It says > that it mandates GSMA-specified DSCP mappings. Thanks for the feedback. I'm actually asking a stupider question than you think. I saw the reference to [6] in RFC 7561, but I was scanning for "GSMA", and the only occurrence to that string that I saw was in the Informative References section. [6] 3GPP, "Guidelines for IPX Provider networks (Previously Inter-Service Provider IP Backbone Guidelines)", GSMA Official Document IR.34 v11.0, November 2014, . If a reader is persistent enough to click through the references in an RFC that's listed as a reference, the reader can figure this out, but it isn't obvious. So I think I'm asking if you can add [6] as a reference in your draft, perhaps pointing to There is also a recommendation from the Global System for Mobile Communications Association (GSMA), You'll know best where to point it, of course, but I'd like to point to the actual GSMA recommendation if we're going to say This GSMA specification was developed without reference to existing IETF specifications for various services, referenced in Section 1.1. which seemed to refer back to *RFC 7561* as the GSMA recommendation, which is what confused me in the first place :-) Spencer, who is noting with bemusement that neither TSV AD balloted on RFC 7561 when it was approved ... how did we miss THAT one??? --94eb2c146c7e5f0940055914d92c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Fred,

On Tue, Sep 12, 2017 at 11:42 PM, Fred Baker <= ;fredbaker.ie= tf@gmail.com> wrote:
On Sep 12, 2017, at 7:55 PM, Spencer Da= wkins at IETF <spencerd= awkins.ietf@gmail.com> wrote:
>
> I'm looking at this text,
>
>=C2=A0 =C2=A0 There is also a recommendation from the Global System for= Mobile
>=C2=A0 =C2=A0 Communications Association (GSMA), specifically their Map= ping Quality
>=C2=A0 =C2=A0 of Service (QoS) Procedures of Proxy Mobile IPv6 (PMIPv6)= and WLAN
>=C2=A0 =C2=A0 [RFC7561] specification.=C2=A0 This GSMA specification wa= s developed
>=C2=A0 =C2=A0 without reference to existing IETF specifications for var= ious
>=C2=A0 =C2=A0 services, referenced in Section 1.1.
>
> and I'm not quite sure how an IETF-stream Informational RFC produc= ed by a working group becomes "a recommendation from GSMA" and &q= uot;a GSMA specification". I recognize the names of the RFC 7561 autho= rs, and I see the connection, but I would have thought that the reference w= ould have been to something more obviously tied to GSMA. Is there any refer= ence that could be cited, to help people who didn't sit two desks away = from one of the authors see the connection?

You might take a look at RFC 7561 section 4.2 and reference [6]. It = says that it mandates GSMA-specified DSCP mappings.

<= /div>
Thanks for the feedback. I'm actually a= sking a stupider question than you think.
<= br>
I saw the reference to [6] in RFC 7561,= but I was scanning for "GSMA", and the only occurrence to that s= tring that I saw was in the Informative References section.=C2=A0

=C2=A0 =C2=A0[6] =C2=A03GPP, "Guidelines for IPX Provider = networks (Previously
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 Inter-Service Provider IP Backbone Guidelines)", GSMA Official<= /div>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Document IR.34 = v11.0, November 2014,
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 <htt= p://www.gsma.com/newsroom/wp-content/uploads/
=C2=A0 =C2=A0 =C2=A0 =C2=A0 IR.34-v11.0.pdf>.

If a reader is persistent= enough to click through the references in an RFC that's listed as a re= ference, the reader can figure this out, but it isn't obvious.

So I think I&#= 39;m asking if you can add [6] as a reference in your draft, perhaps pointi= ng to=C2=A0

=C2=A0 =C2=A0There is also a recommendatio= n from the Global System for Mobile
=C2=A0 = =C2=A0Communications Association (GSMA),=C2=A0

You'll know best where to = point it, of course, but I'd like to point to the actual GSMA recommend= ation if we're going to say

<= div class=3D"gmail_extra">=C2=A0 =C2=A0This GSMA specification was develope= d
=C2=A0 =C2=A0 without reference to existing IETF specifications for va= rious
=C2=A0 =C2=A0 services, referenced in Section 1.1.

which seemed to r= efer back to *RFC 7561* as the GSMA recommendation, which is what confused = me in the first place :-)

Spencer, who is noting with bemusement that neither TSV= AD balloted on RFC 7561 when it was approved ... how did we miss THAT one?= ??
--94eb2c146c7e5f0940055914d92c-- From nobody Wed Sep 13 13:13:05 2017 Return-Path: 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 52FA8132ED2 for ; Wed, 13 Sep 2017 13:13:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dell.com header.b=zHV389NA; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=AQ4nQMGj 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 nRV0t4lm7Dcl for ; Wed, 13 Sep 2017 13:13:02 -0700 (PDT) Received: from esa8.dell-outbound.iphmx.com (esa8.dell-outbound.iphmx.com [68.232.149.218]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1C07132D45 for ; Wed, 13 Sep 2017 13:13:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1505333582; x=1536869582; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=B/eWSsB1fpvJPrIac9fwHbgg+fSFRLCYrf/+h+2iW4M=; b=zHV389NAEkJcsMk1yIqCkPzcokaAh/PYrE86Lvh0IZf92pZ8Tlv45Udq yKtO/tbg6nC4W0/cXx3usCAeKzwJ7jXpb2CY8XgiDorMoGn82iivbFtkI eV5oRTV0RP1I8gq+CN6Y0TBwkaUQLGDyHplZvhLgn6MZhhqY2btCvc3PI w=; Received: from esa3.dell-outbound2.iphmx.com ([68.232.154.63]) by esa8.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Sep 2017 15:13:01 -0500 From: "Black, David" Received: from mailuogwdur.emc.com ([128.221.224.79]) by esa3.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Sep 2017 02:06:30 +0600 Received: from maildlpprd56.lss.emc.com (maildlpprd56.lss.emc.com [10.106.48.160]) by mailuogwprd52.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v8DKCxfL023461 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 13 Sep 2017 16:13:00 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com v8DKCxfL023461 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1505333580; bh=NRpuyl1lnXDPRCU13NUyn0SzTuc=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=AQ4nQMGjAJRZqNeCyop60wdai/lItx3m4jSvyie4QkTohZW+3nTPJy4l7LoOySL0H mHGcP9iuZidqlEC4+4+EC+lbtvugERm9AUJIy4ZO4+MBLdrGbUClBuSNfhSi9pUPT8 +wE7tUVaTgMSDXJ3Shft+wH+kg5LbJqwUUg+AlR8= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com v8DKCxfL023461 Received: from mailusrhubprd54.lss.emc.com (mailusrhubprd54.lss.emc.com [10.106.48.19]) by maildlpprd56.lss.emc.com (RSA Interceptor) for ; Wed, 13 Sep 2017 16:12:24 -0400 Received: from MXHUB318.corp.emc.com (MXHUB318.corp.emc.com [10.146.3.96]) by mailusrhubprd54.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v8DKCmiI003480 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL) for ; Wed, 13 Sep 2017 16:12:49 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB318.corp.emc.com ([10.146.3.96]) with mapi id 14.03.0352.000; Wed, 13 Sep 2017 16:12:48 -0400 To: "tsvwg@ietf.org" Thread-Topic: I-D Action: draft-jennings-rtcweb-deps-19.txt Thread-Index: AQHTLIeepAGpJaMwWUGtC0Uv6b62aqKzPm1Q Date: Wed, 13 Sep 2017 20:12:47 +0000 Message-ID: References: <150530389818.30519.3616862163266039612@ietfa.amsl.com> In-Reply-To: <150530389818.30519.3616862163266039612@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.44.138] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd54.lss.emc.com X-RSA-Classifications: public Archived-At: Subject: [tsvwg] FW: I-D Action: draft-jennings-rtcweb-deps-19.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Sep 2017 20:13:04 -0000 Normally, I don't forward announcements of related drafts to the WG list, b= ut this one is special ;-). As indicated in Section 1.2 of this draft (https://tools.ietf.org/html/draf= t-jennings-rtcweb-deps-19#section-1.2), all of the TSVWG drafts on which We= bRTC depends are now at the RFC Editor, so TSVWG is no longer a possible ca= use of delay to WebRTC. Many thanks to the authors of the sctp-ndata draft (Randy, Michael, Salvato= re, Robin) and everyone else who helped us get to this point. --David (on behalf of the TSVWG chairs and the TSV ADs) -----Original Message----- From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of inte= rnet-drafts@ietf.org Sent: Wednesday, September 13, 2017 7:58 AM To: i-d-announce@ietf.org Subject: I-D Action: draft-jennings-rtcweb-deps-19.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : WebRTC Dependencies Author : Cullen Jennings Filename : draft-jennings-rtcweb-deps-19.txt Pages : 10 Date : 2017-09-13 Abstract: This draft will never be published as an RFC and is meant purely to help track the IETF dependencies from the W3C WebRTC documents. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-jennings-rtcweb-deps/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-jennings-rtcweb-deps-19 https://datatracker.ietf.org/doc/html/draft-jennings-rtcweb-deps-19 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-jennings-rtcweb-deps-19 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Fri Sep 15 17:49:50 2017 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A8DCF13247A; Fri, 15 Sep 2017 17:49:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tsvwg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.61.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150552298362.9141.13848649912496245759@ietfa.amsl.com> Date: Fri, 15 Sep 2017 17:49:43 -0700 Archived-At: Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-ieee-802-11-08.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Sep 2017 00:49:44 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group WG of the IETF. Title : Diffserv to IEEE 802.11 Mapping Authors : Tim Szigeti Jerome Henry Fred Baker Filename : draft-ietf-tsvwg-ieee-802-11-08.txt Pages : 35 Date : 2017-09-15 Abstract: As internet traffic is increasingly sourced-from and destined-to wireless endpoints, it is crucial that Quality of Service be aligned between wired and wireless networks; however, this is not always the case by default. This document specifies a set of Differentiated Services Code Point (DSCP) to IEEE 802.11 User Priority (UP) mappings to reconcile the marking recommendations offered by the IETF and the IEEE so as to maintain consistent QoS treatment between wired and IEEE 802.11 wireless networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ieee-802-11/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tsvwg-ieee-802-11-08 https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-ieee-802-11-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-ieee-802-11-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Sep 15 17:56:16 2017 Return-Path: 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 324251323B4; Fri, 15 Sep 2017 17:56:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 ddtkouCUuHGX; Fri, 15 Sep 2017 17:56:13 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 072C3126B71; Fri, 15 Sep 2017 17:56:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5736; q=dns/txt; s=iport; t=1505523373; x=1506732973; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=iCuAsBdpO0fsVRKAKGe39IQJ7oNkrkSqUXn916TxIv0=; b=BIZoMsSgYVxhB0xt/g5qy4okEflYILo/muFD6OBmEwXDn3N08J7WsE3l AEb2xk9XdO2jJJEMkVeIKs9oyBz1qMeZ4TvdPyXSK+HmIdC8YAF17smNG IKt4512/IR3Qq8H2+ApQnk/ARUWuJSeIF39ooO9X0XXOvJ2ifby4YnK5O g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CbAADRdbxZ/4ENJK1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1pkbicHg26KII90gXSIO41sghIKI4UZAhqEEj8YAQIBAQEBAQE?= =?us-ascii?q?BayiFGAEBAQEBAiMEDUUMBAIBCBEEAQEDAiMDAgICHxEUAQgIAgQBDQUIihMDF?= =?us-ascii?q?RCrT4FtOoc4DYNqAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWBDoIZBIICgzODKIJ?= =?us-ascii?q?YhTOCYAWgSTwCj1yEboIchWqDfoZ9jFqILQIRGQGBOAEfOIENdxVJhxx2AQGIB?= =?us-ascii?q?IEPAQEB?= X-IronPort-AV: E=Sophos;i="5.42,399,1500940800"; d="scan'208";a="296009682" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 16 Sep 2017 00:56:11 +0000 Received: from XCH-RCD-008.cisco.com (xch-rcd-008.cisco.com [173.37.102.18]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id v8G0uBJi011154 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 16 Sep 2017 00:56:11 GMT Received: from xch-rcd-010.cisco.com (173.37.102.20) by XCH-RCD-008.cisco.com (173.37.102.18) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 15 Sep 2017 19:56:11 -0500 Received: from xch-rcd-010.cisco.com ([173.37.102.20]) by XCH-RCD-010.cisco.com ([173.37.102.20]) with mapi id 15.00.1263.000; Fri, 15 Sep 2017 19:56:11 -0500 From: "Tim Szigeti (szigeti)" To: Spencer Dawkins at IETF , David Black CC: "David L. Black" , "tsvwg@ietf.org" , "draft-ietf-tsvwg-ieee-802-11@ietf.org" Thread-Topic: AD Evaluation comments for draft-ietf-tsvwg-ieee-802-11-07 Thread-Index: AQHTLDvXI3dHIpVmrkWr5z05jMdi7aK2tLCA Date: Sat, 16 Sep 2017 00:56:10 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.132.12.130] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [tsvwg] AD Evaluation comments for draft-ietf-tsvwg-ieee-802-11-07 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Sep 2017 00:56:15 -0000 SGkgU3BlbmNlciwNCg0KVGhhbmsgeW91IHZlcnkgbXVjaCBmb3IgZ2l2aW5nIHRoaXMgZG9jdW1l bnQgYSB0aG9yb3VnaCByZWFkLiBXZSByZWFsbHkgYXBwcmVjaWF0ZSB5b3VyIGZlZWRiYWNrIGFu ZCBzdWdnZXN0aW9ucywgYWxsIG9mIHdoaWNoIGhhdmUgYmVlbiBpbXBsZW1lbnRlZCBpbiB0aGUg bGF0ZXN0IHZlcnNpb24gKHYwOCkganVzdCBwb3N0ZWQuDQoNCkNoZWVycywNCg0KLXRpbQ0KDQo+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFNwZW5jZXIgRGF3a2lucyBhdCBJ RVRGIFttYWlsdG86c3BlbmNlcmRhd2tpbnMuaWV0ZkBnbWFpbC5jb21dDQo+IFNlbnQ6IFR1ZXNk YXksIFNlcHRlbWJlciAxMiwgMjAxNyA3OjU2IFBNDQo+IFRvOiBEYXZpZCBCbGFjaw0KPiBDYzog RGF2aWQgTC4gQmxhY2s7IHRzdndnQGlldGYub3JnOyBkcmFmdC1pZXRmLXRzdndnLWllZWUtODAy LTExQGlldGYub3JnDQo+IFN1YmplY3Q6IEFEIEV2YWx1YXRpb24gY29tbWVudHMgZm9yIGRyYWZ0 LWlldGYtdHN2d2ctaWVlZS04MDItMTEtMDcNCj4gDQo+IFRoaXMgd2FzIGEgdmVyeSBkZW5zZSBy ZWFkLCBhbmQgSSBmb3VuZCBvbmx5IGEgZmV3IHRoaW5ncyB0byBhc2sgYWJvdXQsIGFuZA0KPiBo YWxmIG9mIHRob3NlIGFyZSBuaXRzLg0KPiANCj4gTmljZSB3b3JrLg0KPiANCj4gUGxlYXNlIHRh a2UgYSBsb29rIGF0IG15IGV2YWx1YXRpb24gY29tbWVudHMsIGFuZCBsZXQgbWUga25vdyBob3cg eW91J2QNCj4gbGlrZSB0byBwcm9jZWVkLg0KPiANCj4gVGhhbmtzLCBhcyBhbHdheXMuDQo+IA0K PiBTcGVuY2VyDQo+IA0KPiBOaXQsIGJ1dCBpdCdzIGluIHRoZSBBYnN0cmFjdCAuLi4NCj4gDQo+ IMKgIMKgVGhpcyBkb2N1bWVudCBzcGVjaWZpZXMgYSBzZXQgRGlmZmVyZW50aWF0ZWQNCj4gwqAg wqBTZXJ2aWNlcyBDb2RlIFBvaW50IChEU0NQKSB0byBJRUVFIDgwMi4xMSBVc2VyIFByaW9yaXR5 IChVUCkgbWFwcGluZ3MNCj4gDQo+IHNob3VsZCB0aGlzIGJlICIuLi4gc2V0IG9mIERpZmZlcmVu dGlhdGVkIFNlcnZpY2VzIENvZGUgUG9pbnQgLi4uIj8NCj4gDQo+IEknbSBsb29raW5nIGF0IHRo aXMgdGV4dCwNCj4gDQo+IMKgIMKgVGhlcmUgaXMgYWxzbyBhIHJlY29tbWVuZGF0aW9uIGZyb20g dGhlIEdsb2JhbCBTeXN0ZW0gZm9yIE1vYmlsZQ0KPiDCoCDCoENvbW11bmljYXRpb25zIEFzc29j aWF0aW9uIChHU01BKSwgc3BlY2lmaWNhbGx5IHRoZWlyIE1hcHBpbmcgUXVhbGl0eQ0KPiDCoCDC oG9mIFNlcnZpY2UgKFFvUykgUHJvY2VkdXJlcyBvZiBQcm94eSBNb2JpbGUgSVB2NiAoUE1JUHY2 KSBhbmQgV0xBTg0KPiDCoCDCoFtSRkM3NTYxXSBzcGVjaWZpY2F0aW9uLsKgIFRoaXMgR1NNQSBz cGVjaWZpY2F0aW9uIHdhcyBkZXZlbG9wZWQNCj4gwqAgwqB3aXRob3V0IHJlZmVyZW5jZSB0byBl eGlzdGluZyBJRVRGIHNwZWNpZmljYXRpb25zIGZvciB2YXJpb3VzDQo+IMKgIMKgc2VydmljZXMs IHJlZmVyZW5jZWQgaW4gU2VjdGlvbiAxLjEuDQo+IA0KPiBhbmQgSSdtIG5vdCBxdWl0ZSBzdXJl IGhvdyBhbiBJRVRGLXN0cmVhbSBJbmZvcm1hdGlvbmFsIFJGQyBwcm9kdWNlZCBieSBhDQo+IHdv cmtpbmcgZ3JvdXAgYmVjb21lcyAiYSByZWNvbW1lbmRhdGlvbiBmcm9tIEdTTUEiIGFuZCAiYSBH U01BDQo+IHNwZWNpZmljYXRpb24iLiBJIHJlY29nbml6ZSB0aGUgbmFtZXMgb2YgdGhlIFJGQyA3 NTYxIGF1dGhvcnMsIGFuZCBJIHNlZSB0aGUNCj4gY29ubmVjdGlvbiwgYnV0IEkgd291bGQgaGF2 ZSB0aG91Z2h0IHRoYXQgdGhlIHJlZmVyZW5jZSB3b3VsZCBoYXZlIGJlZW4gdG8NCj4gc29tZXRo aW5nIG1vcmUgb2J2aW91c2x5IHRpZWQgdG8gR1NNQS4gSXMgdGhlcmUgYW55IHJlZmVyZW5jZSB0 aGF0IGNvdWxkDQo+IGJlIGNpdGVkLCB0byBoZWxwIHBlb3BsZSB3aG8gZGlkbid0IHNpdCB0d28g ZGVza3MgYXdheSBmcm9tIG9uZSBvZiB0aGUNCj4gYXV0aG9ycyBzZWUgdGhlIGNvbm5lY3Rpb24/ DQo+IA0KPiBJbiB0aGlzIHRleHQsDQo+IA0KPiDCoCDCoFRoaXMgZG9jdW1lbnQgYXNzdW1lcyBh bmQgUkVDT01NRU5EUyB0aGF0IGFsbCB3aXJlbGVzcyBhY2Nlc3MgcG9pbnRzDQo+IMKgIMKgKGFz IHRoZSBicmlkZ2VzIGJldHdlZW4gd2lyZWQtYW5kLXdpcmVsZXNzIG5ldHdvcmtzKSBzdXBwb3J0 IHRoZQ0KPiDCoCDCoGFiaWxpdHkgdG86DQo+IA0KPiBpcyAiYnJpZGdlcyIgdGhlIHJpZ2h0IHdv cmQgaGVyZT8gSSB3b3VsZCByZWFkIHRoYXQgYXMgc2F5aW5nIHRoYXQgd2lyZWxlc3MNCj4gYWNj ZXNzIHBvaW50cyBhcmUgYSBsYXllciB0d28tbGF5ZXIgdHdvIGJyaWRnZS4gSWYgeW91IGhhdmUg cmVhZGVycyB3aG8gYXJlDQo+IGZhbWlsaWFyIHdpdGggSUVFRSA4MDIuMSBicmlkZ2luZywgdGhl eSBtYXkgYmUgbW9yZSBjb25mdXNlZCB0aGFuIEkgd2FzLg0KPiANCj4gQSBuaXQgLSAidW51c3Vl ZCIgLT4gInVudXNlZCINCj4gDQo+IEkgcmVhbGx5IGFwcHJlY2lhdGUgdGhlIGluY2x1c2lvbiBv ZiBTZWN0aW9uIDYsIGFzIGFuIG92ZXJ2aWV3IG9mIElFRUUgODAyLjExDQo+IFFvUy4gSSdkIHN1 Z2dlc3QgdGhhdCB0aGlzIG5vdCBiZSB0aXRsZWQgYXMgIkFwcGVuZGl4IiAtIHdoaWNoDQo+IGh0 dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL3JmYy9wZGZyZmMvcmZjNzMyMi50eHQucGRmIGRvZXNu J3QgdGhpbmsgaXMgcGFydCBvZg0KPiBhbiBSRkMgYm9keSwgc28gYXQgYSBtaW5pbXVtIHRoZXkg d291bGQgbW92ZSBpdCBiZWhpbmQgdGhlIHNlY3VyaXR5DQo+IGNvbnNpZGVyYXRpb25zLCBidXQg SSdkIGJlIE9LIGlmIHlvdSBsZWZ0IGl0IGFzIGEgbm9ybWFsIFNlY3Rpb24gaW4gdGhlIGJvZHku DQo+IEFsdGVybmF0aXZlbHksIGlmIHlvdSdyZSBoYXBwaWVyIHdpdGggdGhpcyBtYXRlcmlhbCBh cyBhbiBBcHBlbmRpeCwgaXQncyBwcm9iYWJseQ0KPiBiZXR0ZXIgdG8gc2xpZGUgaXQgdG8gdGhl IGJhY2sgbWF0ZXJpYWwuDQo+IA0KPiBBIG5pdCAtICJvZnRoZWlyIiAtPiAib2YgdGhlaXIiDQo+ IA0KPiBJJ20gbG9va2luZyBhdCB0aGUgbGFzdCBwYXJhZ3JhcGggb2YgdGhlIFNlY3VyaXR5IENv bnNpZGVyYXRpb25zLCBhbmQgSSdtDQo+IHRoaW5raW5nIHRoYXQNCj4gDQo+IMKgIMKgRmluYWxs eSwgaXQgc2hvdWxkIGJlIG5vdGVkIHRoYXQgdGhlIHJlY29tbWVuZGF0aW9ucyBwdXQgZm9yd2Fy ZCBpbg0KPiDCoCDCoHRoaXMgZG9jdW1lbnQgYXJlIG5vdCBpbnRlbmRlZCB0byBhZGRyZXNzIGFs bCBhdHRhY2sgdmVjdG9ycw0KPiDCoCDCoGxldmVyYWdpbmcgUW9TIG1hcmtpbmcgYWJ1c2UuwqAg TWVjaGFuaXNtcyB0aGF0IG1heSBmdXJ0aGVyIGhlbHANCj4gwqAgwqBtaXRpZ2F0ZSBzZWN1cml0 eSByaXNrcyBpbmNsdWRlIHN0cm9uZyBkZXZpY2UtIGFuZC9vciB1c2VyLQ0KPiDCoCDCoGF1dGhl bnRpY2F0aW9uLCBhY2Nlc3MtY29udHJvbCwgcmF0ZSBsaW1pdGluZywgY29udHJvbC1wbGFuZQ0K PiDCoCDCoHBvbGljaW5nLCBlbmNyeXB0aW9uIGFuZCBvdGhlciB0ZWNobmlxdWVzOyBob3dldmVy LCB0aGUNCj4gwqAgwqBpbXBsZW1lbnRhdGlvbiByZWNvbW1lbmRhdGlvbnMgZm9yIHN1Y2ggbWVj aGFuaXNtcyBhcmUgYmV5b25kIHRoZQ0KPiDCoCDCoHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQgdG8g YWRkcmVzcyBpbiBkZXRhaWwuwqAgU3VmZmljZSBpdCB0byBzYXkgdGhhdA0KPiDCoCDCoHRoZSBz ZWN1cml0eSBvZiB0aGUgZGV2aWNlcyBhbmQgbmV0d29ya3MgaW1wbGVtZW50aW5nIFFvUywgaW5j bHVkaW5nDQo+IMKgIMKgUW9TIG1hcHBpbmcgYmV0d2VlbiB3aXJlZCBhbmQgd2lyZWxlc3MgbmV0 d29ya3MsIFNIT1VMRCBiZQ0KPiBjb25zaWRlcmVkDQo+IMKgIMKgaW4gYWN0dWFsIGRlcGxveW1l bnRzLg0KPiANCj4gaXMgbWlzc2luZyB0aGUgKHBlcmhhcHMgb2J2aW91cykgcG9pbnQgdGhhdCB0 aGUgbWVjaGFuaXNtcyB5b3UgbGlzdCB1bmRlcg0KPiAiZnVydGhlciBoZWxwIiBhcmVuJ3Qgc3Bl Y2lmaWMgdG8gd2lyZWxlc3MgbmV0d29ya3MsIGJ1dCBzaG91bGQgYmUgY29uc2lkZXJlZA0KPiBm b3IgYW55IG5ldHdvcmsgdGhhdCBpbXBsZW1lbnRzIFFvUy4gVGhhdCBtaWdodCBiZSBjb3ZlcmVk IGluIHRoZSBsYXN0DQo+IHNlbnRlbmNlLCBidXQgdGhhdCdzIG5vdCB3aGF0IEknbSBnZXR0aW5n IG91dCBvZiB0aGUgbGFzdCBzZW50ZW5jZS4NCg== From nobody Mon Sep 18 10:26:56 2017 Return-Path: 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 01C64132992; Mon, 18 Sep 2017 10:26:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dell.com header.b=QYKiVl4e; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=leR1S/20 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 45MZI3UmGirc; Mon, 18 Sep 2017 10:26:50 -0700 (PDT) Received: from esa3.dell-outbound.iphmx.com (esa3.dell-outbound.iphmx.com [68.232.153.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4195133061; Mon, 18 Sep 2017 10:26:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1505755591; x=1537291591; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Wdg4dE52Jr+f1WAuC0uEpeyC2TlO5kBhx3h+90JgBxQ=; b=QYKiVl4ejHxS0qmgWg/gGBafHGtekwIJ64wWHuAX+MYTqV3lQ1PdwY2s VSAtbMgIohFFVJ7JwpHs/bAKWCX5Lb03ylcIJF6Td1kkJ3vrVRAgxJYAe aSV2vwnzzdkPHe6X2kcvmZ6z77uY40RTYX5PRfigiJLlNQjlOeyeVnw4j 4=; Received: from esa5.dell-outbound2.iphmx.com ([68.232.153.203]) by esa3.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Sep 2017 12:26:31 -0500 From: "Black, David" Received: from mailuogwdur.emc.com ([128.221.224.79]) by esa5.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Sep 2017 23:19:57 +0600 Received: from maildlpprd56.lss.emc.com (maildlpprd56.lss.emc.com [10.106.48.160]) by mailuogwprd51.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v8IHQj0b002790 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 18 Sep 2017 13:26:48 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com v8IHQj0b002790 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1505755609; bh=LgkvaC2EK/hU12QJ26XFPdOgAUg=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=leR1S/20GjiXWgWgymib2biHsY03hBou0LARS/00KjbQ66ICb+vXH5dcRhWyDxc5T GRpA6X4V9i+X3bo6uPSAFr75WQgv69XUclbKJk5kbINsZxWzgJd3vJF2j3t5DLcdAv D2kKP7bV9XmyXKDU2dDE+Oo2scpNYAcgd4C7tIiM= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com v8IHQj0b002790 Received: from mailusrhubprd53.lss.emc.com (mailusrhubprd53.lss.emc.com [10.106.48.18]) by maildlpprd56.lss.emc.com (RSA Interceptor); Mon, 18 Sep 2017 13:26:33 -0400 Received: from MXHUB306.corp.emc.com (MXHUB306.corp.emc.com [10.146.3.32]) by mailusrhubprd53.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v8IHQbdW009949 (version=TLSv1.2 cipher=AES128-SHA256 bits=128 verify=FAIL); Mon, 18 Sep 2017 13:26:37 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB306.corp.emc.com ([10.146.3.32]) with mapi id 14.03.0352.000; Mon, 18 Sep 2017 13:26:36 -0400 To: "Tim Szigeti (szigeti)" , Spencer Dawkins at IETF CC: "tsvwg@ietf.org" , "draft-ietf-tsvwg-ieee-802-11@ietf.org" Thread-Topic: AD Evaluation comments for draft-ietf-tsvwg-ieee-802-11-07 Thread-Index: AQHTLDvXSq+UxrknR0ODuGgkGJv9zaK298IAgAP1DQA= Date: Mon, 18 Sep 2017 17:26:36 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.44.138] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd53.lss.emc.com X-RSA-Classifications: public Archived-At: Subject: Re: [tsvwg] AD Evaluation comments for draft-ietf-tsvwg-ieee-802-11-07 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Sep 2017 17:26:53 -0000 VGhlIHRleHQgdGhhdCBTcGVuY2VyIHF1b3RlZCBicmluZ3MgdXAgc29tZXRoaW5nIGVsc2UgLi4u IEknZCBzdWdnZXN0IHNvbWUgZWRpdG9yaWFsIHJlcGhyYXNpbmcgb2YgYXQgbGVhc3QgdGhlIHdv cmRzICJTSE9VTEQgYmUgY29uc2lkZXJlZCIgaW46DQoNCiAgIFN1ZmZpY2UgaXQgdG8gc2F5IHRo YXQNCiAgICB0aGUgc2VjdXJpdHkgb2YgdGhlIGRldmljZXMgYW5kIG5ldHdvcmtzIGltcGxlbWVu dGluZyBRb1MsIGluY2x1ZGluZw0KICAgIFFvUyBtYXBwaW5nIGJldHdlZW4gd2lyZWQgYW5kIHdp cmVsZXNzIG5ldHdvcmtzLCBTSE9VTEQgYmUNCiAgIGNvbnNpZGVyZWQgaW4gYWN0dWFsIGRlcGxv eW1lbnRzLg0KDQpiZWZvcmUgc29tZW9uZSBvbiB0aGUgSUVTRyBub3RlcyB0aGUgcmVsZXZhbmNl IG9mIFNlY3Rpb24gMiBvZiBSRkMgNjkxOSAgdG8gdGhhdCB0ZXh0OiANCglodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvcmZjNjkxOSNzZWN0aW9uLTINCmFuZCBub3RpY2VzIHRoZSBwdWJsaWNh dGlvbiBkYXRlIG9mIFJGQyA2OTE5IDotKSA6LSkuDQoNClRoYW5rcywgLS1EYXZpZA0KDQo+IC0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFRpbSBTemlnZXRpIChzemlnZXRpKSBb bWFpbHRvOnN6aWdldGlAY2lzY28uY29tXQ0KPiBTZW50OiBGcmlkYXksIFNlcHRlbWJlciAxNSwg MjAxNyA4OjU2IFBNDQo+IFRvOiBTcGVuY2VyIERhd2tpbnMgYXQgSUVURiA8c3BlbmNlcmRhd2tp bnMuaWV0ZkBnbWFpbC5jb20+OyBCbGFjaywgRGF2aWQNCj4gPGRhdmlkLmJsYWNrQGVtYy5jb20+ DQo+IENjOiBCbGFjaywgRGF2aWQgPGRhdmlkLmJsYWNrQGVtYy5jb20+OyB0c3Z3Z0BpZXRmLm9y ZzsgZHJhZnQtaWV0Zi10c3Z3Zy0NCj4gaWVlZS04MDItMTFAaWV0Zi5vcmcNCj4gU3ViamVjdDog UkU6IEFEIEV2YWx1YXRpb24gY29tbWVudHMgZm9yIGRyYWZ0LWlldGYtdHN2d2ctaWVlZS04MDIt MTEtMDcNCj4gDQo+IEhpIFNwZW5jZXIsDQo+IA0KPiBUaGFuayB5b3UgdmVyeSBtdWNoIGZvciBn aXZpbmcgdGhpcyBkb2N1bWVudCBhIHRob3JvdWdoIHJlYWQuIFdlIHJlYWxseQ0KPiBhcHByZWNp YXRlIHlvdXIgZmVlZGJhY2sgYW5kIHN1Z2dlc3Rpb25zLCBhbGwgb2Ygd2hpY2ggaGF2ZSBiZWVu DQo+IGltcGxlbWVudGVkIGluIHRoZSBsYXRlc3QgdmVyc2lvbiAodjA4KSBqdXN0IHBvc3RlZC4N Cj4gDQo+IENoZWVycywNCj4gDQo+IC10aW0NCj4gDQo+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj4gPiBGcm9tOiBTcGVuY2VyIERhd2tpbnMgYXQgSUVURiBbbWFpbHRvOnNwZW5jZXJk YXdraW5zLmlldGZAZ21haWwuY29tXQ0KPiA+IFNlbnQ6IFR1ZXNkYXksIFNlcHRlbWJlciAxMiwg MjAxNyA3OjU2IFBNDQo+ID4gVG86IERhdmlkIEJsYWNrDQo+ID4gQ2M6IERhdmlkIEwuIEJsYWNr OyB0c3Z3Z0BpZXRmLm9yZzsgZHJhZnQtaWV0Zi10c3Z3Zy1pZWVlLTgwMi0xMUBpZXRmLm9yZw0K PiA+IFN1YmplY3Q6IEFEIEV2YWx1YXRpb24gY29tbWVudHMgZm9yIGRyYWZ0LWlldGYtdHN2d2ct aWVlZS04MDItMTEtMDcNCj4gPg0KPiA+IFRoaXMgd2FzIGEgdmVyeSBkZW5zZSByZWFkLCBhbmQg SSBmb3VuZCBvbmx5IGEgZmV3IHRoaW5ncyB0byBhc2sgYWJvdXQsIGFuZA0KPiA+IGhhbGYgb2Yg dGhvc2UgYXJlIG5pdHMuDQo+ID4NCj4gPiBOaWNlIHdvcmsuDQo+ID4NCj4gPiBQbGVhc2UgdGFr ZSBhIGxvb2sgYXQgbXkgZXZhbHVhdGlvbiBjb21tZW50cywgYW5kIGxldCBtZSBrbm93IGhvdyB5 b3UnZA0KPiA+IGxpa2UgdG8gcHJvY2VlZC4NCj4gPg0KPiA+IFRoYW5rcywgYXMgYWx3YXlzLg0K PiA+DQo+ID4gU3BlbmNlcg0KPiA+DQo+ID4gTml0LCBidXQgaXQncyBpbiB0aGUgQWJzdHJhY3Qg Li4uDQo+ID4NCj4gPiDCoCDCoFRoaXMgZG9jdW1lbnQgc3BlY2lmaWVzIGEgc2V0IERpZmZlcmVu dGlhdGVkDQo+ID4gwqAgwqBTZXJ2aWNlcyBDb2RlIFBvaW50IChEU0NQKSB0byBJRUVFIDgwMi4x MSBVc2VyIFByaW9yaXR5IChVUCkgbWFwcGluZ3MNCj4gPg0KPiA+IHNob3VsZCB0aGlzIGJlICIu Li4gc2V0IG9mIERpZmZlcmVudGlhdGVkIFNlcnZpY2VzIENvZGUgUG9pbnQgLi4uIj8NCj4gPg0K PiA+IEknbSBsb29raW5nIGF0IHRoaXMgdGV4dCwNCj4gPg0KPiA+IMKgIMKgVGhlcmUgaXMgYWxz byBhIHJlY29tbWVuZGF0aW9uIGZyb20gdGhlIEdsb2JhbCBTeXN0ZW0gZm9yIE1vYmlsZQ0KPiA+ IMKgIMKgQ29tbXVuaWNhdGlvbnMgQXNzb2NpYXRpb24gKEdTTUEpLCBzcGVjaWZpY2FsbHkgdGhl aXIgTWFwcGluZyBRdWFsaXR5DQo+ID4gwqAgwqBvZiBTZXJ2aWNlIChRb1MpIFByb2NlZHVyZXMg b2YgUHJveHkgTW9iaWxlIElQdjYgKFBNSVB2NikgYW5kIFdMQU4NCj4gPiDCoCDCoFtSRkM3NTYx XSBzcGVjaWZpY2F0aW9uLsKgIFRoaXMgR1NNQSBzcGVjaWZpY2F0aW9uIHdhcyBkZXZlbG9wZWQN Cj4gPiDCoCDCoHdpdGhvdXQgcmVmZXJlbmNlIHRvIGV4aXN0aW5nIElFVEYgc3BlY2lmaWNhdGlv bnMgZm9yIHZhcmlvdXMNCj4gPiDCoCDCoHNlcnZpY2VzLCByZWZlcmVuY2VkIGluIFNlY3Rpb24g MS4xLg0KPiA+DQo+ID4gYW5kIEknbSBub3QgcXVpdGUgc3VyZSBob3cgYW4gSUVURi1zdHJlYW0g SW5mb3JtYXRpb25hbCBSRkMgcHJvZHVjZWQgYnkNCj4gYQ0KPiA+IHdvcmtpbmcgZ3JvdXAgYmVj b21lcyAiYSByZWNvbW1lbmRhdGlvbiBmcm9tIEdTTUEiIGFuZCAiYSBHU01BDQo+ID4gc3BlY2lm aWNhdGlvbiIuIEkgcmVjb2duaXplIHRoZSBuYW1lcyBvZiB0aGUgUkZDIDc1NjEgYXV0aG9ycywg YW5kIEkgc2VlIHRoZQ0KPiA+IGNvbm5lY3Rpb24sIGJ1dCBJIHdvdWxkIGhhdmUgdGhvdWdodCB0 aGF0IHRoZSByZWZlcmVuY2Ugd291bGQgaGF2ZSBiZWVuDQo+IHRvDQo+ID4gc29tZXRoaW5nIG1v cmUgb2J2aW91c2x5IHRpZWQgdG8gR1NNQS4gSXMgdGhlcmUgYW55IHJlZmVyZW5jZSB0aGF0IGNv dWxkDQo+ID4gYmUgY2l0ZWQsIHRvIGhlbHAgcGVvcGxlIHdobyBkaWRuJ3Qgc2l0IHR3byBkZXNr cyBhd2F5IGZyb20gb25lIG9mIHRoZQ0KPiA+IGF1dGhvcnMgc2VlIHRoZSBjb25uZWN0aW9uPw0K PiA+DQo+ID4gSW4gdGhpcyB0ZXh0LA0KPiA+DQo+ID4gwqAgwqBUaGlzIGRvY3VtZW50IGFzc3Vt ZXMgYW5kIFJFQ09NTUVORFMgdGhhdCBhbGwgd2lyZWxlc3MgYWNjZXNzIHBvaW50cw0KPiA+IMKg IMKgKGFzIHRoZSBicmlkZ2VzIGJldHdlZW4gd2lyZWQtYW5kLXdpcmVsZXNzIG5ldHdvcmtzKSBz dXBwb3J0IHRoZQ0KPiA+IMKgIMKgYWJpbGl0eSB0bzoNCj4gPg0KPiA+IGlzICJicmlkZ2VzIiB0 aGUgcmlnaHQgd29yZCBoZXJlPyBJIHdvdWxkIHJlYWQgdGhhdCBhcyBzYXlpbmcgdGhhdCB3aXJl bGVzcw0KPiA+IGFjY2VzcyBwb2ludHMgYXJlIGEgbGF5ZXIgdHdvLWxheWVyIHR3byBicmlkZ2Uu IElmIHlvdSBoYXZlIHJlYWRlcnMgd2hvIGFyZQ0KPiA+IGZhbWlsaWFyIHdpdGggSUVFRSA4MDIu MSBicmlkZ2luZywgdGhleSBtYXkgYmUgbW9yZSBjb25mdXNlZCB0aGFuIEkgd2FzLg0KPiA+DQo+ ID4gQSBuaXQgLSAidW51c3VlZCIgLT4gInVudXNlZCINCj4gPg0KPiA+IEkgcmVhbGx5IGFwcHJl Y2lhdGUgdGhlIGluY2x1c2lvbiBvZiBTZWN0aW9uIDYsIGFzIGFuIG92ZXJ2aWV3IG9mIElFRUUg ODAyLjExDQo+ID4gUW9TLiBJJ2Qgc3VnZ2VzdCB0aGF0IHRoaXMgbm90IGJlIHRpdGxlZCBhcyAi QXBwZW5kaXgiIC0gd2hpY2gNCj4gPiBodHRwczovL3d3dy5yZmMtZWRpdG9yLm9yZy9yZmMvcGRm cmZjL3JmYzczMjIudHh0LnBkZiBkb2Vzbid0IHRoaW5rIGlzIHBhcnQNCj4gb2YNCj4gPiBhbiBS RkMgYm9keSwgc28gYXQgYSBtaW5pbXVtIHRoZXkgd291bGQgbW92ZSBpdCBiZWhpbmQgdGhlIHNl Y3VyaXR5DQo+ID4gY29uc2lkZXJhdGlvbnMsIGJ1dCBJJ2QgYmUgT0sgaWYgeW91IGxlZnQgaXQg YXMgYSBub3JtYWwgU2VjdGlvbiBpbiB0aGUgYm9keS4NCj4gPiBBbHRlcm5hdGl2ZWx5LCBpZiB5 b3UncmUgaGFwcGllciB3aXRoIHRoaXMgbWF0ZXJpYWwgYXMgYW4gQXBwZW5kaXgsIGl0J3MNCj4g cHJvYmFibHkNCj4gPiBiZXR0ZXIgdG8gc2xpZGUgaXQgdG8gdGhlIGJhY2sgbWF0ZXJpYWwuDQo+ ID4NCj4gPiBBIG5pdCAtICJvZnRoZWlyIiAtPiAib2YgdGhlaXIiDQo+ID4NCj4gPiBJJ20gbG9v a2luZyBhdCB0aGUgbGFzdCBwYXJhZ3JhcGggb2YgdGhlIFNlY3VyaXR5IENvbnNpZGVyYXRpb25z LCBhbmQgSSdtDQo+ID4gdGhpbmtpbmcgdGhhdA0KPiA+DQo+ID4gwqAgwqBGaW5hbGx5LCBpdCBz aG91bGQgYmUgbm90ZWQgdGhhdCB0aGUgcmVjb21tZW5kYXRpb25zIHB1dCBmb3J3YXJkIGluDQo+ ID4gwqAgwqB0aGlzIGRvY3VtZW50IGFyZSBub3QgaW50ZW5kZWQgdG8gYWRkcmVzcyBhbGwgYXR0 YWNrIHZlY3RvcnMNCj4gPiDCoCDCoGxldmVyYWdpbmcgUW9TIG1hcmtpbmcgYWJ1c2UuwqAgTWVj aGFuaXNtcyB0aGF0IG1heSBmdXJ0aGVyIGhlbHANCj4gPiDCoCDCoG1pdGlnYXRlIHNlY3VyaXR5 IHJpc2tzIGluY2x1ZGUgc3Ryb25nIGRldmljZS0gYW5kL29yIHVzZXItDQo+ID4gwqAgwqBhdXRo ZW50aWNhdGlvbiwgYWNjZXNzLWNvbnRyb2wsIHJhdGUgbGltaXRpbmcsIGNvbnRyb2wtcGxhbmUN Cj4gPiDCoCDCoHBvbGljaW5nLCBlbmNyeXB0aW9uIGFuZCBvdGhlciB0ZWNobmlxdWVzOyBob3dl dmVyLCB0aGUNCj4gPiDCoCDCoGltcGxlbWVudGF0aW9uIHJlY29tbWVuZGF0aW9ucyBmb3Igc3Vj aCBtZWNoYW5pc21zIGFyZSBiZXlvbmQgdGhlDQo+ID4gwqAgwqBzY29wZSBvZiB0aGlzIGRvY3Vt ZW50IHRvIGFkZHJlc3MgaW4gZGV0YWlsLsKgIFN1ZmZpY2UgaXQgdG8gc2F5IHRoYXQNCj4gPiDC oCDCoHRoZSBzZWN1cml0eSBvZiB0aGUgZGV2aWNlcyBhbmQgbmV0d29ya3MgaW1wbGVtZW50aW5n IFFvUywgaW5jbHVkaW5nDQo+ID4gwqAgwqBRb1MgbWFwcGluZyBiZXR3ZWVuIHdpcmVkIGFuZCB3 aXJlbGVzcyBuZXR3b3JrcywgU0hPVUxEIGJlDQo+ID4gY29uc2lkZXJlZA0KPiA+IMKgIMKgaW4g YWN0dWFsIGRlcGxveW1lbnRzLg0KPiA+DQo+ID4gaXMgbWlzc2luZyB0aGUgKHBlcmhhcHMgb2J2 aW91cykgcG9pbnQgdGhhdCB0aGUgbWVjaGFuaXNtcyB5b3UgbGlzdCB1bmRlcg0KPiA+ICJmdXJ0 aGVyIGhlbHAiIGFyZW4ndCBzcGVjaWZpYyB0byB3aXJlbGVzcyBuZXR3b3JrcywgYnV0IHNob3Vs ZCBiZQ0KPiBjb25zaWRlcmVkDQo+ID4gZm9yIGFueSBuZXR3b3JrIHRoYXQgaW1wbGVtZW50cyBR b1MuIFRoYXQgbWlnaHQgYmUgY292ZXJlZCBpbiB0aGUgbGFzdA0KPiA+IHNlbnRlbmNlLCBidXQg dGhhdCdzIG5vdCB3aGF0IEknbSBnZXR0aW5nIG91dCBvZiB0aGUgbGFzdCBzZW50ZW5jZS4NCg== From nobody Mon Sep 18 14:24:07 2017 Return-Path: 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 31FCB132D89; Mon, 18 Sep 2017 14:24:06 -0700 (PDT) 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, HTML_MESSAGE=0.001, SPF_PASS=-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 W_ZleA5b4ex5; Mon, 18 Sep 2017 14:24:03 -0700 (PDT) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (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 E97691321DE; Mon, 18 Sep 2017 14:24:02 -0700 (PDT) Received: by mail-yw0-x229.google.com with SMTP id o143so1268115ywd.12; Mon, 18 Sep 2017 14:24:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UDZJ/bIx3iC36DCfxI0OJedzv1QvLOkvbVBk3sQs2qg=; b=oY4F/qAyt39KVvA2pg8jrTFw97rExh4jiZhB+CKyiiVWQZiUxB+EGG9rVQH1fkNLBd 7JhW30XaN1fUmCqkWiEnyPe/7qn5TCM3B28jBlhhwBotDEgP9i5QLgsFnfKzP65I5MTd flIITQOoubm14SnShNfSHd/n02H7761QYA41V2Lkx5jw/pcOuzib+glPwARmoyL4flHA CchSXCka4EWiRMXUaopC8iRqzafX8mp2fL5aPhViUSFor/ldUwKCg5XFRYlnrOYGEMNK Q0B9DLdfoeZAxzNmCEcHTJbB5G9ovkOVJ0ZhvmaYilrz8VSazcl0ns6m3laLFImVlZ7X 7ypg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=UDZJ/bIx3iC36DCfxI0OJedzv1QvLOkvbVBk3sQs2qg=; b=dn7691bK1VAVo5xl20G3HIILZo6fKBOryKmFwpvNtgTI3+p8QjWfeTr9PTBX1wFyP6 bj8NaFJXYyd313wsEoai5J7FZsb6vPo8Cn1Mdxp3zmae4YahvRzjkwTanmY3kFUjxorU 2QhlMq9rD9JgOgAjG+c6giLpXyFCPIjPElMuJZiEjumbY0QmGwdQ4/h2KB5wMsoTEBRj k6AL01bsL1z/Mq2PLO82WOsnPLSrADWPxnpI1brg6HPK3MF+TsDobdaCD1DWkPomu6Es WFTkomPt4HUMaZOSqIi8nBMZqxbosSQ/8ryZiPXXPYrGSQ2PqpwADa4rd0el2OGXhqe9 nKDw== X-Gm-Message-State: AHPjjUhExqzSCfHp4x6S6XK7ytui3ctcBHlCwxkKBCV6OopQI5P0M1+O WAdPpKw8H3tj76iij1ub0o1rHjakNJb1EV8IGM4= X-Google-Smtp-Source: ADKCNb591lv5pDLMUo1beiubDzmzCOsfbuY8BjUieJtp0L/WQq7+YveB+8J2joR2xBi24//5X/6kudPbu5Rn/hno08E= X-Received: by 10.129.123.194 with SMTP id w185mr29990611ywc.333.1505769840688; Mon, 18 Sep 2017 14:24:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.2.15 with HTTP; Mon, 18 Sep 2017 14:24:00 -0700 (PDT) In-Reply-To: References: From: Spencer Dawkins at IETF Date: Mon, 18 Sep 2017 16:24:00 -0500 Message-ID: To: "Black, David" Cc: "Tim Szigeti (szigeti)" , "tsvwg@ietf.org" , "draft-ietf-tsvwg-ieee-802-11@ietf.org" Content-Type: multipart/alternative; boundary="001a1149390477c26305597d5c68" Archived-At: Subject: Re: [tsvwg] AD Evaluation comments for draft-ietf-tsvwg-ieee-802-11-07 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Sep 2017 21:24:06 -0000 --001a1149390477c26305597d5c68 Content-Type: text/plain; charset="UTF-8" Dear All, On Mon, Sep 18, 2017 at 12:26 PM, Black, David wrote: > The text that Spencer quoted brings up something else ... I'd suggest some > editorial rephrasing of at least the words "SHOULD be considered" in: > > Suffice it to say that > the security of the devices and networks implementing QoS, including > QoS mapping between wired and wireless networks, SHOULD be > considered in actual deployments. > > before someone on the IESG notes the relevance of Section 2 of RFC 6919 > to that text: > https://tools.ietf.org/html/rfc6919#section-2 > and notices the publication date of RFC 6919 :-) :-). > > Thanks, --David > > > -----Original Message----- > > From: Tim Szigeti (szigeti) [mailto:szigeti@cisco.com] > > Sent: Friday, September 15, 2017 8:56 PM > > To: Spencer Dawkins at IETF ; Black, > David > > > > Cc: Black, David ; tsvwg@ietf.org; > draft-ietf-tsvwg- > > ieee-802-11@ietf.org > > Subject: RE: AD Evaluation comments for draft-ietf-tsvwg-ieee-802-11-07 > > > > Hi Spencer, > > > > Thank you very much for giving this document a thorough read. We really > > appreciate your feedback and suggestions, all of which have been > > implemented in the latest version (v08) just posted. > I'm good to go with v08, but please let me know if anything will change in response to David's previous e-mail in this thread, so we don't start Last Call with comments that should be addressed. Thanks, Spencer > > > Cheers, > > > > -tim > > > > > -----Original Message----- > > > From: Spencer Dawkins at IETF [mailto:spencerdawkins.ietf@gmail.com] > > > Sent: Tuesday, September 12, 2017 7:56 PM > > > To: David Black > > > Cc: David L. Black; tsvwg@ietf.org; draft-ietf-tsvwg-ieee-802-11@ > ietf.org > > > Subject: AD Evaluation comments for draft-ietf-tsvwg-ieee-802-11-07 > > > > > > This was a very dense read, and I found only a few things to ask > about, and > > > half of those are nits. > > > > > > Nice work. > > > > > > Please take a look at my evaluation comments, and let me know how you'd > > > like to proceed. > > > > > > Thanks, as always. > > > > > > Spencer > > > > > > Nit, but it's in the Abstract ... > > > > > > This document specifies a set Differentiated > > > Services Code Point (DSCP) to IEEE 802.11 User Priority (UP) > mappings > > > > > > should this be "... set of Differentiated Services Code Point ..."? > > > > > > I'm looking at this text, > > > > > > There is also a recommendation from the Global System for Mobile > > > Communications Association (GSMA), specifically their Mapping > Quality > > > of Service (QoS) Procedures of Proxy Mobile IPv6 (PMIPv6) and WLAN > > > [RFC7561] specification. This GSMA specification was developed > > > without reference to existing IETF specifications for various > > > services, referenced in Section 1.1. > > > > > > and I'm not quite sure how an IETF-stream Informational RFC produced by > > a > > > working group becomes "a recommendation from GSMA" and "a GSMA > > > specification". I recognize the names of the RFC 7561 authors, and I > see the > > > connection, but I would have thought that the reference would have been > > to > > > something more obviously tied to GSMA. Is there any reference that > could > > > be cited, to help people who didn't sit two desks away from one of the > > > authors see the connection? > > > > > > In this text, > > > > > > This document assumes and RECOMMENDS that all wireless access points > > > (as the bridges between wired-and-wireless networks) support the > > > ability to: > > > > > > is "bridges" the right word here? I would read that as saying that > wireless > > > access points are a layer two-layer two bridge. If you have readers > who are > > > familiar with IEEE 802.1 bridging, they may be more confused than I > was. > > > > > > A nit - "unusued" -> "unused" > > > > > > I really appreciate the inclusion of Section 6, as an overview of IEEE > 802.11 > > > QoS. I'd suggest that this not be titled as "Appendix" - which > > > https://www.rfc-editor.org/rfc/pdfrfc/rfc7322.txt.pdf doesn't think > is part > > of > > > an RFC body, so at a minimum they would move it behind the security > > > considerations, but I'd be OK if you left it as a normal Section in > the body. > > > Alternatively, if you're happier with this material as an Appendix, > it's > > probably > > > better to slide it to the back material. > > > > > > A nit - "oftheir" -> "of their" > > > > > > I'm looking at the last paragraph of the Security Considerations, and > I'm > > > thinking that > > > > > > Finally, it should be noted that the recommendations put forward in > > > this document are not intended to address all attack vectors > > > leveraging QoS marking abuse. Mechanisms that may further help > > > mitigate security risks include strong device- and/or user- > > > authentication, access-control, rate limiting, control-plane > > > policing, encryption and other techniques; however, the > > > implementation recommendations for such mechanisms are beyond the > > > scope of this document to address in detail. Suffice it to say that > > > the security of the devices and networks implementing QoS, including > > > QoS mapping between wired and wireless networks, SHOULD be > > > considered > > > in actual deployments. > > > > > > is missing the (perhaps obvious) point that the mechanisms you list > under > > > "further help" aren't specific to wireless networks, but should be > > considered > > > for any network that implements QoS. That might be covered in the last > > > sentence, but that's not what I'm getting out of the last sentence. > --001a1149390477c26305597d5c68 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear All,

On Mon, Sep 18, 2017 at 12:26 PM, Black, David &= lt;David.Black@de= ll.com> wrote:
The text tha= t Spencer quoted brings up something else ... I'd suggest some editoria= l rephrasing of at least the words "SHOULD be considered" in:

=C2=A0 =C2=A0Suffice it to say that
=C2=A0 =C2=A0 the security of the devices and networks implementing QoS, in= cluding
=C2=A0 =C2=A0 QoS mapping between wired and wireless networks, SHOULD be =C2=A0 =C2=A0considered in actual deployments.

before someone on the IESG notes the relevance of Section 2 of RFC 6= 919=C2=A0 to that text:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://tools.ietf.org/html= /rfc6919#section-2
and notices the publication date of RFC 6919 :-) :-).

Thanks, --David

> -----Original Message-----
> From: Tim Szigeti (szigeti) [mailto:szigeti@cisco.com]
> Sent: Friday, September 15, 2017 8:56 PM
> To: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>; Black, David
> <david.black@emc.com>=
> Cc: Black, David <david.blac= k@emc.com>; tsvwg@ietf.org; dr= aft-ietf-tsvwg-
> ieee-802-11@ietf.org
> Subject: RE: AD Evaluation comments for draft-ietf-tsvwg-ieee-802-11-<= wbr>07
>
> Hi Spencer,
>
> Thank you very much for giving this document a thorough read. We reall= y
> appreciate your feedback and suggestions, all of which have been
> implemented in the latest version (v08) just posted.

I'm good to go with v08, but please let = me know if anything will change in response to David's previous e-mail = in this thread, so we don't start Last Call with comments that should b= e addressed.

Thanks,=C2=A0

Spencer

>
> Cheers,=C2=A0
>
> -tim
>
> > -----Original Message-----
> > From: Spencer Dawkins at IETF [mailto:spencerdawkins.ietf@gmail.com]
> > Sent: Tuesday, September 12, 2017 7:56 PM
> > To: David Black
> > Cc: David L. Black; tsvwg@ietf.= org; draft-iet= f-tsvwg-ieee-802-11@ietf.org
> > Subject: AD Evaluation comments for draft-ietf-tsvwg-ieee-802-11-= 07
> >
> > This was a very dense read, and I found only a few things to ask = about, and
> > half of those are nits.
> >
> > Nice work.
> >
> > Please take a look at my evaluation comments, and let me know how= you'd
> > like to proceed.
> >
> > Thanks, as always.
> >
> > Spencer
> >
> > Nit, but it's in the Abstract ...
> >
> > =C2=A0 =C2=A0This document specifies a set Differentiated
> > =C2=A0 =C2=A0Services Code Point (DSCP) to IEEE 802.11 User Prior= ity (UP) mappings
> >
> > should this be "... set of Differentiated Services Code Poin= t ..."?
> >
> > I'm looking at this text,
> >
> > =C2=A0 =C2=A0There is also a recommendation from the Global Syste= m for Mobile
> > =C2=A0 =C2=A0Communications Association (GSMA), specifically thei= r Mapping Quality
> > =C2=A0 =C2=A0of Service (QoS) Procedures of Proxy Mobile IPv6 (PM= IPv6) and WLAN
> > =C2=A0 =C2=A0[RFC7561] specification.=C2=A0 This GSMA specificati= on was developed
> > =C2=A0 =C2=A0without reference to existing IETF specifications fo= r various
> > =C2=A0 =C2=A0services, referenced in Section 1.1.
> >
> > and I'm not quite sure how an IETF-stream Informational RFC p= roduced by
> a
> > working group becomes "a recommendation from GSMA" and = "a GSMA
> > specification". I recognize the names of the RFC 7561 author= s, and I see the
> > connection, but I would have thought that the reference would hav= e been
> to
> > something more obviously tied to GSMA. Is there any reference tha= t could
> > be cited, to help people who didn't sit two desks away from o= ne of the
> > authors see the connection?
> >
> > In this text,
> >
> > =C2=A0 =C2=A0This document assumes and RECOMMENDS that all wirele= ss access points
> > =C2=A0 =C2=A0(as the bridges between wired-and-wireless networks)= support the
> > =C2=A0 =C2=A0ability to:
> >
> > is "bridges" the right word here? I would read that as = saying that wireless
> > access points are a layer two-layer two bridge. If you have reade= rs who are
> > familiar with IEEE 802.1 bridging, they may be more confused than= I was.
> >
> > A nit - "unusued" -> "unused"
> >
> > I really appreciate the inclusion of Section 6, as an overview of= IEEE 802.11
> > QoS. I'd suggest that this not be titled as "Appendix&qu= ot; - which
> > https://www.rfc-editor.org/rfc/p= dfrfc/rfc7322.txt.pdf doesn't think is part
> of
> > an RFC body, so at a minimum they would move it behind the securi= ty
> > considerations, but I'd be OK if you left it as a normal Sect= ion in the body.
> > Alternatively, if you're happier with this material as an App= endix, it's
> probably
> > better to slide it to the back material.
> >
> > A nit - "oftheir" -> "of their"
> >
> > I'm looking at the last paragraph of the Security Considerati= ons, and I'm
> > thinking that
> >
> > =C2=A0 =C2=A0Finally, it should be noted that the recommendations= put forward in
> > =C2=A0 =C2=A0this document are not intended to address all attack= vectors
> > =C2=A0 =C2=A0leveraging QoS marking abuse.=C2=A0 Mechanisms that = may further help
> > =C2=A0 =C2=A0mitigate security risks include strong device- and/o= r user-
> > =C2=A0 =C2=A0authentication, access-control, rate limiting, contr= ol-plane
> > =C2=A0 =C2=A0policing, encryption and other techniques; however, = the
> > =C2=A0 =C2=A0implementation recommendations for such mechanisms a= re beyond the
> > =C2=A0 =C2=A0scope of this document to address in detail.=C2=A0 S= uffice it to say that
> > =C2=A0 =C2=A0the security of the devices and networks implementin= g QoS, including
> > =C2=A0 =C2=A0QoS mapping between wired and wireless networks, SHO= ULD be
> > considered
> > =C2=A0 =C2=A0in actual deployments.
> >
> > is missing the (perhaps obvious) point that the mechanisms you li= st under
> > "further help" aren't specific to wireless networks= , but should be
> considered
> > for any network that implements QoS. That might be covered in the= last
> > sentence, but that's not what I'm getting out of the last= sentence.

--001a1149390477c26305597d5c68-- From nobody Mon Sep 18 21:15:38 2017 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E8DD91270AB; Mon, 18 Sep 2017 21:15:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tsvwg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.62.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150579452990.15699.15965169363254244751@ietfa.amsl.com> Date: Mon, 18 Sep 2017 21:15:29 -0700 Archived-At: Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-ieee-802-11-09.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Sep 2017 04:15:30 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group WG of the IETF. Title : Diffserv to IEEE 802.11 Mapping Authors : Tim Szigeti Jerome Henry Fred Baker Filename : draft-ietf-tsvwg-ieee-802-11-09.txt Pages : 35 Date : 2017-09-18 Abstract: As internet traffic is increasingly sourced-from and destined-to wireless endpoints, it is crucial that Quality of Service be aligned between wired and wireless networks; however, this is not always the case by default. This document specifies a set of Differentiated Services Code Point (DSCP) to IEEE 802.11 User Priority (UP) mappings to reconcile the marking recommendations offered by the IETF and the IEEE so as to maintain consistent QoS treatment between wired and IEEE 802.11 wireless networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ieee-802-11/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tsvwg-ieee-802-11-09 https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-ieee-802-11-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-ieee-802-11-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Sep 18 21:19:01 2017 Return-Path: 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 0D3AF1329AD; Mon, 18 Sep 2017 21:19:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.519 X-Spam-Level: X-Spam-Status: No, score=-14.519 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 MFt8OVGvIL-I; Mon, 18 Sep 2017 21:18:58 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA28A1270AB; Mon, 18 Sep 2017 21:18:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=28256; q=dns/txt; s=iport; t=1505794737; x=1507004337; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=pC6HUuaPK6+wumttz00SuwqCBP9Yg8xOVAIgjXh5rP0=; b=QlO6lEXNhGmbR8ENr4KJR7D3lXGSJJPoDole0dKvyH2HQOSgx5DEe4d/ vA7rKJw4+fElbC+lCNowyT8jmM26m3g0GoIBobj6m4wrQwDKqKAEaGWeE h2yKN9cEAx3ETrGi4fOHQcLyzDL7Wv8ajYkvvJnu/1ggqlgK1Lst6Aul6 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DAAAAZmcBZ/5tdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm9rZG4nB4NuiiCPd4F0iDuNaw6CBAojhRgCGoQwPxgBAgEBAQE?= =?us-ascii?q?BAQFrKIUYAQEBAQEBASMEBkwMBAIBCBEEAQEoAwICAh8RFAkIAgQOBQiJR0wDD?= =?us-ascii?q?QgQqTKBbTqHPA2DXwEBAQEBAQEBAQEBAQEBAQEBAQEBARgFgycEggKDM4Mogli?= =?us-ascii?q?BaD8HKIJdgmAFhz+ZDTwCh1mHNE+EboIchWqDfoZ9jFqILgIRGQGBOAEfOIENd?= =?us-ascii?q?xVJhxx2AQGHBoEPAQEB?= X-IronPort-AV: E=Sophos;i="5.42,416,1500940800"; d="scan'208,217";a="295256201" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Sep 2017 04:18:55 +0000 Received: from XCH-ALN-008.cisco.com (xch-aln-008.cisco.com [173.36.7.18]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v8J4It3I027650 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 19 Sep 2017 04:18:55 GMT Received: from xch-rcd-010.cisco.com (173.37.102.20) by XCH-ALN-008.cisco.com (173.36.7.18) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 18 Sep 2017 23:18:55 -0500 Received: from xch-rcd-010.cisco.com ([173.37.102.20]) by XCH-RCD-010.cisco.com ([173.37.102.20]) with mapi id 15.00.1263.000; Mon, 18 Sep 2017 23:18:55 -0500 From: "Tim Szigeti (szigeti)" To: Spencer Dawkins at IETF , "Black, David" CC: "tsvwg@ietf.org" , "draft-ietf-tsvwg-ieee-802-11@ietf.org" Thread-Topic: AD Evaluation comments for draft-ietf-tsvwg-ieee-802-11-07 Thread-Index: AQHTLDvXI3dHIpVmrkWr5z05jMdi7aK2tLCAgASNOACAAEJVAIAAH2nA Date: Tue, 19 Sep 2017 04:18:54 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.19.22.199] Content-Type: multipart/alternative; boundary="_000_dc3d512a82ba44a39e286fdfbafbbf83XCHRCD010ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [tsvwg] AD Evaluation comments for draft-ietf-tsvwg-ieee-802-11-07 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Sep 2017 04:19:01 -0000 --_000_dc3d512a82ba44a39e286fdfbafbbf83XCHRCD010ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgU3BlbmNlciwNCg0KSSBtYWRlIHRoZSBtaW5vciBjaGFuZ2UgcmVxdWVzdGVkOyBub3cgdGhl IHNlbnRlbmNlIGF2b2lkcyB0aGUgbG9hZGVkIHRlcm0g4oCYc2hvdWxkIGNvbnNpZGVy4oCZLg0K DQpTdWZmaWNlIGl0IHRvIHNheSB0aGF0IHRoZSBzZWN1cml0eSBvZiB0aGUgZGV2aWNlcyBhbmQg bmV0d29ya3MgaW1wbGVtZW50aW5nIFFvUywgaW5jbHVkaW5nIFFvUyBtYXBwaW5nIGJldHdlZW4g d2lyZWQgYW5kIHdpcmVsZXNzIG5ldHdvcmtzLCBtZXJpdHMgY29uc2lkZXJhdGlvbiBpbiBhY3R1 YWwgZGVwbG95bWVudHMuDQoNCihUaGFua3MgRGF2aWQgZm9yIGJyaW5naW5nIHRoaXMgdG8gb3Vy IGF0dGVudGlvbikuDQoNCldpdGggdGhhdCBkb25lLCBJIHRoaW5rIHdl4oCZcmUgcmVhZHkgZm9y IExhc3QgQ2FsbC4NCg0KVGhhbmtzLA0KDQotdGltDQoNCg0KRnJvbTogU3BlbmNlciBEYXdraW5z IGF0IElFVEYgW21haWx0bzpzcGVuY2VyZGF3a2lucy5pZXRmQGdtYWlsLmNvbV0NClNlbnQ6IE1v bmRheSwgU2VwdGVtYmVyIDE4LCAyMDE3IDI6MjQgUE0NClRvOiBCbGFjaywgRGF2aWQNCkNjOiBU aW0gU3ppZ2V0aSAoc3ppZ2V0aSk7IHRzdndnQGlldGYub3JnOyBkcmFmdC1pZXRmLXRzdndnLWll ZWUtODAyLTExQGlldGYub3JnDQpTdWJqZWN0OiBSZTogQUQgRXZhbHVhdGlvbiBjb21tZW50cyBm b3IgZHJhZnQtaWV0Zi10c3Z3Zy1pZWVlLTgwMi0xMS0wNw0KDQpEZWFyIEFsbCwNCg0KT24gTW9u LCBTZXAgMTgsIDIwMTcgYXQgMTI6MjYgUE0sIEJsYWNrLCBEYXZpZCA8RGF2aWQuQmxhY2tAZGVs bC5jb208bWFpbHRvOkRhdmlkLkJsYWNrQGRlbGwuY29tPj4gd3JvdGU6DQpUaGUgdGV4dCB0aGF0 IFNwZW5jZXIgcXVvdGVkIGJyaW5ncyB1cCBzb21ldGhpbmcgZWxzZSAuLi4gSSdkIHN1Z2dlc3Qg c29tZSBlZGl0b3JpYWwgcmVwaHJhc2luZyBvZiBhdCBsZWFzdCB0aGUgd29yZHMgIlNIT1VMRCBi ZSBjb25zaWRlcmVkIiBpbjoNCg0KICAgU3VmZmljZSBpdCB0byBzYXkgdGhhdA0KICAgIHRoZSBz ZWN1cml0eSBvZiB0aGUgZGV2aWNlcyBhbmQgbmV0d29ya3MgaW1wbGVtZW50aW5nIFFvUywgaW5j bHVkaW5nDQogICAgUW9TIG1hcHBpbmcgYmV0d2VlbiB3aXJlZCBhbmQgd2lyZWxlc3MgbmV0d29y a3MsIFNIT1VMRCBiZQ0KICAgY29uc2lkZXJlZCBpbiBhY3R1YWwgZGVwbG95bWVudHMuDQoNCmJl Zm9yZSBzb21lb25lIG9uIHRoZSBJRVNHIG5vdGVzIHRoZSByZWxldmFuY2Ugb2YgU2VjdGlvbiAy IG9mIFJGQyA2OTE5ICB0byB0aGF0IHRleHQ6DQogICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9yZmM2OTE5I3NlY3Rpb24tMg0KYW5kIG5vdGljZXMgdGhlIHB1YmxpY2F0aW9uIGRh dGUgb2YgUkZDIDY5MTkgOi0pIDotKS4NCg0KVGhhbmtzLCAtLURhdmlkDQoNCj4gLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogVGltIFN6aWdldGkgKHN6aWdldGkpIFttYWlsdG86 c3ppZ2V0aUBjaXNjby5jb208bWFpbHRvOnN6aWdldGlAY2lzY28uY29tPl0NCj4gU2VudDogRnJp ZGF5LCBTZXB0ZW1iZXIgMTUsIDIwMTcgODo1NiBQTQ0KPiBUbzogU3BlbmNlciBEYXdraW5zIGF0 IElFVEYgPHNwZW5jZXJkYXdraW5zLmlldGZAZ21haWwuY29tPG1haWx0bzpzcGVuY2VyZGF3a2lu cy5pZXRmQGdtYWlsLmNvbT4+OyBCbGFjaywgRGF2aWQNCj4gPGRhdmlkLmJsYWNrQGVtYy5jb208 bWFpbHRvOmRhdmlkLmJsYWNrQGVtYy5jb20+Pg0KPiBDYzogQmxhY2ssIERhdmlkIDxkYXZpZC5i bGFja0BlbWMuY29tPG1haWx0bzpkYXZpZC5ibGFja0BlbWMuY29tPj47IHRzdndnQGlldGYub3Jn PG1haWx0bzp0c3Z3Z0BpZXRmLm9yZz47IGRyYWZ0LWlldGYtdHN2d2ctDQo+IGllZWUtODAyLTEx QGlldGYub3JnPG1haWx0bzppZWVlLTgwMi0xMUBpZXRmLm9yZz4NCj4gU3ViamVjdDogUkU6IEFE IEV2YWx1YXRpb24gY29tbWVudHMgZm9yIGRyYWZ0LWlldGYtdHN2d2ctaWVlZS04MDItMTEtMDcN Cj4NCj4gSGkgU3BlbmNlciwNCj4NCj4gVGhhbmsgeW91IHZlcnkgbXVjaCBmb3IgZ2l2aW5nIHRo aXMgZG9jdW1lbnQgYSB0aG9yb3VnaCByZWFkLiBXZSByZWFsbHkNCj4gYXBwcmVjaWF0ZSB5b3Vy IGZlZWRiYWNrIGFuZCBzdWdnZXN0aW9ucywgYWxsIG9mIHdoaWNoIGhhdmUgYmVlbg0KPiBpbXBs ZW1lbnRlZCBpbiB0aGUgbGF0ZXN0IHZlcnNpb24gKHYwOCkganVzdCBwb3N0ZWQuDQoNCkknbSBn b29kIHRvIGdvIHdpdGggdjA4LCBidXQgcGxlYXNlIGxldCBtZSBrbm93IGlmIGFueXRoaW5nIHdp bGwgY2hhbmdlIGluIHJlc3BvbnNlIHRvIERhdmlkJ3MgcHJldmlvdXMgZS1tYWlsIGluIHRoaXMg dGhyZWFkLCBzbyB3ZSBkb24ndCBzdGFydCBMYXN0IENhbGwgd2l0aCBjb21tZW50cyB0aGF0IHNo b3VsZCBiZSBhZGRyZXNzZWQuDQoNClRoYW5rcywNCg0KU3BlbmNlcg0KDQo+DQo+IENoZWVycywN Cj4NCj4gLXRpbQ0KPg0KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gRnJvbTog U3BlbmNlciBEYXdraW5zIGF0IElFVEYgW21haWx0bzpzcGVuY2VyZGF3a2lucy5pZXRmQGdtYWls LmNvbTxtYWlsdG86c3BlbmNlcmRhd2tpbnMuaWV0ZkBnbWFpbC5jb20+XQ0KPiA+IFNlbnQ6IFR1 ZXNkYXksIFNlcHRlbWJlciAxMiwgMjAxNyA3OjU2IFBNDQo+ID4gVG86IERhdmlkIEJsYWNrDQo+ ID4gQ2M6IERhdmlkIEwuIEJsYWNrOyB0c3Z3Z0BpZXRmLm9yZzxtYWlsdG86dHN2d2dAaWV0Zi5v cmc+OyBkcmFmdC1pZXRmLXRzdndnLWllZWUtODAyLTExQGlldGYub3JnPG1haWx0bzpkcmFmdC1p ZXRmLXRzdndnLWllZWUtODAyLTExQGlldGYub3JnPg0KPiA+IFN1YmplY3Q6IEFEIEV2YWx1YXRp b24gY29tbWVudHMgZm9yIGRyYWZ0LWlldGYtdHN2d2ctaWVlZS04MDItMTEtMDcNCj4gPg0KPiA+ IFRoaXMgd2FzIGEgdmVyeSBkZW5zZSByZWFkLCBhbmQgSSBmb3VuZCBvbmx5IGEgZmV3IHRoaW5n cyB0byBhc2sgYWJvdXQsIGFuZA0KPiA+IGhhbGYgb2YgdGhvc2UgYXJlIG5pdHMuDQo+ID4NCj4g PiBOaWNlIHdvcmsuDQo+ID4NCj4gPiBQbGVhc2UgdGFrZSBhIGxvb2sgYXQgbXkgZXZhbHVhdGlv biBjb21tZW50cywgYW5kIGxldCBtZSBrbm93IGhvdyB5b3UnZA0KPiA+IGxpa2UgdG8gcHJvY2Vl ZC4NCj4gPg0KPiA+IFRoYW5rcywgYXMgYWx3YXlzLg0KPiA+DQo+ID4gU3BlbmNlcg0KPiA+DQo+ ID4gTml0LCBidXQgaXQncyBpbiB0aGUgQWJzdHJhY3QgLi4uDQo+ID4NCj4gPiAgICBUaGlzIGRv Y3VtZW50IHNwZWNpZmllcyBhIHNldCBEaWZmZXJlbnRpYXRlZA0KPiA+ICAgIFNlcnZpY2VzIENv ZGUgUG9pbnQgKERTQ1ApIHRvIElFRUUgODAyLjExIFVzZXIgUHJpb3JpdHkgKFVQKSBtYXBwaW5n cw0KPiA+DQo+ID4gc2hvdWxkIHRoaXMgYmUgIi4uLiBzZXQgb2YgRGlmZmVyZW50aWF0ZWQgU2Vy dmljZXMgQ29kZSBQb2ludCAuLi4iPw0KPiA+DQo+ID4gSSdtIGxvb2tpbmcgYXQgdGhpcyB0ZXh0 LA0KPiA+DQo+ID4gICAgVGhlcmUgaXMgYWxzbyBhIHJlY29tbWVuZGF0aW9uIGZyb20gdGhlIEds b2JhbCBTeXN0ZW0gZm9yIE1vYmlsZQ0KPiA+ICAgIENvbW11bmljYXRpb25zIEFzc29jaWF0aW9u IChHU01BKSwgc3BlY2lmaWNhbGx5IHRoZWlyIE1hcHBpbmcgUXVhbGl0eQ0KPiA+ICAgIG9mIFNl cnZpY2UgKFFvUykgUHJvY2VkdXJlcyBvZiBQcm94eSBNb2JpbGUgSVB2NiAoUE1JUHY2KSBhbmQg V0xBTg0KPiA+ICAgIFtSRkM3NTYxXSBzcGVjaWZpY2F0aW9uLiAgVGhpcyBHU01BIHNwZWNpZmlj YXRpb24gd2FzIGRldmVsb3BlZA0KPiA+ICAgIHdpdGhvdXQgcmVmZXJlbmNlIHRvIGV4aXN0aW5n IElFVEYgc3BlY2lmaWNhdGlvbnMgZm9yIHZhcmlvdXMNCj4gPiAgICBzZXJ2aWNlcywgcmVmZXJl bmNlZCBpbiBTZWN0aW9uIDEuMS4NCj4gPg0KPiA+IGFuZCBJJ20gbm90IHF1aXRlIHN1cmUgaG93 IGFuIElFVEYtc3RyZWFtIEluZm9ybWF0aW9uYWwgUkZDIHByb2R1Y2VkIGJ5DQo+IGENCj4gPiB3 b3JraW5nIGdyb3VwIGJlY29tZXMgImEgcmVjb21tZW5kYXRpb24gZnJvbSBHU01BIiBhbmQgImEg R1NNQQ0KPiA+IHNwZWNpZmljYXRpb24iLiBJIHJlY29nbml6ZSB0aGUgbmFtZXMgb2YgdGhlIFJG QyA3NTYxIGF1dGhvcnMsIGFuZCBJIHNlZSB0aGUNCj4gPiBjb25uZWN0aW9uLCBidXQgSSB3b3Vs ZCBoYXZlIHRob3VnaHQgdGhhdCB0aGUgcmVmZXJlbmNlIHdvdWxkIGhhdmUgYmVlbg0KPiB0bw0K PiA+IHNvbWV0aGluZyBtb3JlIG9idmlvdXNseSB0aWVkIHRvIEdTTUEuIElzIHRoZXJlIGFueSBy ZWZlcmVuY2UgdGhhdCBjb3VsZA0KPiA+IGJlIGNpdGVkLCB0byBoZWxwIHBlb3BsZSB3aG8gZGlk bid0IHNpdCB0d28gZGVza3MgYXdheSBmcm9tIG9uZSBvZiB0aGUNCj4gPiBhdXRob3JzIHNlZSB0 aGUgY29ubmVjdGlvbj8NCj4gPg0KPiA+IEluIHRoaXMgdGV4dCwNCj4gPg0KPiA+ICAgIFRoaXMg ZG9jdW1lbnQgYXNzdW1lcyBhbmQgUkVDT01NRU5EUyB0aGF0IGFsbCB3aXJlbGVzcyBhY2Nlc3Mg cG9pbnRzDQo+ID4gICAgKGFzIHRoZSBicmlkZ2VzIGJldHdlZW4gd2lyZWQtYW5kLXdpcmVsZXNz IG5ldHdvcmtzKSBzdXBwb3J0IHRoZQ0KPiA+ICAgIGFiaWxpdHkgdG86DQo+ID4NCj4gPiBpcyAi YnJpZGdlcyIgdGhlIHJpZ2h0IHdvcmQgaGVyZT8gSSB3b3VsZCByZWFkIHRoYXQgYXMgc2F5aW5n IHRoYXQgd2lyZWxlc3MNCj4gPiBhY2Nlc3MgcG9pbnRzIGFyZSBhIGxheWVyIHR3by1sYXllciB0 d28gYnJpZGdlLiBJZiB5b3UgaGF2ZSByZWFkZXJzIHdobyBhcmUNCj4gPiBmYW1pbGlhciB3aXRo IElFRUUgODAyLjEgYnJpZGdpbmcsIHRoZXkgbWF5IGJlIG1vcmUgY29uZnVzZWQgdGhhbiBJIHdh cy4NCj4gPg0KPiA+IEEgbml0IC0gInVudXN1ZWQiIC0+ICJ1bnVzZWQiDQo+ID4NCj4gPiBJIHJl YWxseSBhcHByZWNpYXRlIHRoZSBpbmNsdXNpb24gb2YgU2VjdGlvbiA2LCBhcyBhbiBvdmVydmll dyBvZiBJRUVFIDgwMi4xMQ0KPiA+IFFvUy4gSSdkIHN1Z2dlc3QgdGhhdCB0aGlzIG5vdCBiZSB0 aXRsZWQgYXMgIkFwcGVuZGl4IiAtIHdoaWNoDQo+ID4gaHR0cHM6Ly93d3cucmZjLWVkaXRvci5v cmcvcmZjL3BkZnJmYy9yZmM3MzIyLnR4dC5wZGYgZG9lc24ndCB0aGluayBpcyBwYXJ0DQo+IG9m DQo+ID4gYW4gUkZDIGJvZHksIHNvIGF0IGEgbWluaW11bSB0aGV5IHdvdWxkIG1vdmUgaXQgYmVo aW5kIHRoZSBzZWN1cml0eQ0KPiA+IGNvbnNpZGVyYXRpb25zLCBidXQgSSdkIGJlIE9LIGlmIHlv dSBsZWZ0IGl0IGFzIGEgbm9ybWFsIFNlY3Rpb24gaW4gdGhlIGJvZHkuDQo+ID4gQWx0ZXJuYXRp dmVseSwgaWYgeW91J3JlIGhhcHBpZXIgd2l0aCB0aGlzIG1hdGVyaWFsIGFzIGFuIEFwcGVuZGl4 LCBpdCdzDQo+IHByb2JhYmx5DQo+ID4gYmV0dGVyIHRvIHNsaWRlIGl0IHRvIHRoZSBiYWNrIG1h dGVyaWFsLg0KPiA+DQo+ID4gQSBuaXQgLSAib2Z0aGVpciIgLT4gIm9mIHRoZWlyIg0KPiA+DQo+ ID4gSSdtIGxvb2tpbmcgYXQgdGhlIGxhc3QgcGFyYWdyYXBoIG9mIHRoZSBTZWN1cml0eSBDb25z aWRlcmF0aW9ucywgYW5kIEknbQ0KPiA+IHRoaW5raW5nIHRoYXQNCj4gPg0KPiA+ICAgIEZpbmFs bHksIGl0IHNob3VsZCBiZSBub3RlZCB0aGF0IHRoZSByZWNvbW1lbmRhdGlvbnMgcHV0IGZvcndh cmQgaW4NCj4gPiAgICB0aGlzIGRvY3VtZW50IGFyZSBub3QgaW50ZW5kZWQgdG8gYWRkcmVzcyBh bGwgYXR0YWNrIHZlY3RvcnMNCj4gPiAgICBsZXZlcmFnaW5nIFFvUyBtYXJraW5nIGFidXNlLiAg TWVjaGFuaXNtcyB0aGF0IG1heSBmdXJ0aGVyIGhlbHANCj4gPiAgICBtaXRpZ2F0ZSBzZWN1cml0 eSByaXNrcyBpbmNsdWRlIHN0cm9uZyBkZXZpY2UtIGFuZC9vciB1c2VyLQ0KPiA+ICAgIGF1dGhl bnRpY2F0aW9uLCBhY2Nlc3MtY29udHJvbCwgcmF0ZSBsaW1pdGluZywgY29udHJvbC1wbGFuZQ0K PiA+ICAgIHBvbGljaW5nLCBlbmNyeXB0aW9uIGFuZCBvdGhlciB0ZWNobmlxdWVzOyBob3dldmVy LCB0aGUNCj4gPiAgICBpbXBsZW1lbnRhdGlvbiByZWNvbW1lbmRhdGlvbnMgZm9yIHN1Y2ggbWVj aGFuaXNtcyBhcmUgYmV5b25kIHRoZQ0KPiA+ICAgIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQgdG8g YWRkcmVzcyBpbiBkZXRhaWwuICBTdWZmaWNlIGl0IHRvIHNheSB0aGF0DQo+ID4gICAgdGhlIHNl Y3VyaXR5IG9mIHRoZSBkZXZpY2VzIGFuZCBuZXR3b3JrcyBpbXBsZW1lbnRpbmcgUW9TLCBpbmNs dWRpbmcNCj4gPiAgICBRb1MgbWFwcGluZyBiZXR3ZWVuIHdpcmVkIGFuZCB3aXJlbGVzcyBuZXR3 b3JrcywgU0hPVUxEIGJlDQo+ID4gY29uc2lkZXJlZA0KPiA+ICAgIGluIGFjdHVhbCBkZXBsb3lt ZW50cy4NCj4gPg0KPiA+IGlzIG1pc3NpbmcgdGhlIChwZXJoYXBzIG9idmlvdXMpIHBvaW50IHRo YXQgdGhlIG1lY2hhbmlzbXMgeW91IGxpc3QgdW5kZXINCj4gPiAiZnVydGhlciBoZWxwIiBhcmVu J3Qgc3BlY2lmaWMgdG8gd2lyZWxlc3MgbmV0d29ya3MsIGJ1dCBzaG91bGQgYmUNCj4gY29uc2lk ZXJlZA0KPiA+IGZvciBhbnkgbmV0d29yayB0aGF0IGltcGxlbWVudHMgUW9TLiBUaGF0IG1pZ2h0 IGJlIGNvdmVyZWQgaW4gdGhlIGxhc3QNCj4gPiBzZW50ZW5jZSwgYnV0IHRoYXQncyBub3Qgd2hh dCBJJ20gZ2V0dGluZyBvdXQgb2YgdGhlIGxhc3Qgc2VudGVuY2UuDQoNCg== --_000_dc3d512a82ba44a39e286fdfbafbbf83XCHRCD010ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4u RW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN Cgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30N CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRt YXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRh PSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJv ZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSBTcGVuY2VyLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBtYWRlIHRoZSBt aW5vciBjaGFuZ2UgcmVxdWVzdGVkOyBub3cgdGhlIHNlbnRlbmNlIGF2b2lkcyB0aGUgbG9hZGVk IHRlcm0g4oCYc2hvdWxkIGNvbnNpZGVy4oCZLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0idGV4dC1pbmRlbnQ6NS4yNXB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+U3VmZmljZSBpdCB0byBzYXkgdGhhdCB0aGUgc2VjdXJpdHkgb2YgdGhlIGRldmlj ZXMgYW5kIG5ldHdvcmtzIGltcGxlbWVudGluZyBRb1MsIGluY2x1ZGluZyBRb1MgbWFwcGluZyBi ZXR3ZWVuIHdpcmVkIGFuZCB3aXJlbGVzcw0KIG5ldHdvcmtzLCBtZXJpdHMgY29uc2lkZXJhdGlv biBpbiBhY3R1YWwgZGVwbG95bWVudHMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4oVGhhbmtzIERhdmlkIGZvciBicmlu Z2luZyB0aGlzIHRvIG91ciBhdHRlbnRpb24pLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+V2l0aCB0aGF0IGRvbmUsIEkg dGhpbmsgd2XigJlyZSByZWFkeSBmb3IgTGFzdCBDYWxsLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhhbmtzLDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+LXRpbTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBp biAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt dG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3Nw YW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gU3BlbmNlciBEYXdraW5zIGF0IElF VEYgW21haWx0bzpzcGVuY2VyZGF3a2lucy5pZXRmQGdtYWlsLmNvbV0NCjxicj4NCjxiPlNlbnQ6 PC9iPiBNb25kYXksIFNlcHRlbWJlciAxOCwgMjAxNyAyOjI0IFBNPGJyPg0KPGI+VG86PC9iPiBC bGFjaywgRGF2aWQ8YnI+DQo8Yj5DYzo8L2I+IFRpbSBTemlnZXRpIChzemlnZXRpKTsgdHN2d2dA aWV0Zi5vcmc7IGRyYWZ0LWlldGYtdHN2d2ctaWVlZS04MDItMTFAaWV0Zi5vcmc8YnI+DQo8Yj5T dWJqZWN0OjwvYj4gUmU6IEFEIEV2YWx1YXRpb24gY29tbWVudHMgZm9yIGRyYWZ0LWlldGYtdHN2 d2ctaWVlZS04MDItMTEtMDc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+RGVhciBBbGwsPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+T24gTW9uLCBTZXAgMTgsIDIwMTcgYXQgMTI6MjYgUE0sIEJsYWNrLCBEYXZpZCAmbHQ7 PGEgaHJlZj0ibWFpbHRvOkRhdmlkLkJsYWNrQGRlbGwuY29tIiB0YXJnZXQ9Il9ibGFuayI+RGF2 aWQuQmxhY2tAZGVsbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPlRoZSB0ZXh0IHRoYXQgU3BlbmNlciBxdW90ZWQgYnJpbmdzIHVwIHNvbWV0 aGluZyBlbHNlIC4uLiBJJ2Qgc3VnZ2VzdCBzb21lIGVkaXRvcmlhbCByZXBocmFzaW5nIG9mIGF0 IGxlYXN0IHRoZSB3b3JkcyAmcXVvdDtTSE9VTEQgYmUgY29uc2lkZXJlZCZxdW90OyBpbjo8YnI+ DQo8YnI+DQombmJzcDsgJm5ic3A7U3VmZmljZSBpdCB0byBzYXkgdGhhdDxicj4NCiZuYnNwOyAm bmJzcDsgdGhlIHNlY3VyaXR5IG9mIHRoZSBkZXZpY2VzIGFuZCBuZXR3b3JrcyBpbXBsZW1lbnRp bmcgUW9TLCBpbmNsdWRpbmc8YnI+DQombmJzcDsgJm5ic3A7IFFvUyBtYXBwaW5nIGJldHdlZW4g d2lyZWQgYW5kIHdpcmVsZXNzIG5ldHdvcmtzLCBTSE9VTEQgYmU8YnI+DQombmJzcDsgJm5ic3A7 Y29uc2lkZXJlZCBpbiBhY3R1YWwgZGVwbG95bWVudHMuPGJyPg0KPGJyPg0KYmVmb3JlIHNvbWVv bmUgb24gdGhlIElFU0cgbm90ZXMgdGhlIHJlbGV2YW5jZSBvZiBTZWN0aW9uIDIgb2YgUkZDIDY5 MTkmbmJzcDsgdG8gdGhhdCB0ZXh0Ojxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA8 YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjkxOSNzZWN0aW9uLTIiIHRh cmdldD0iX2JsYW5rIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjkxOSNzZWN0aW9u LTI8L2E+PGJyPg0KYW5kIG5vdGljZXMgdGhlIHB1YmxpY2F0aW9uIGRhdGUgb2YgUkZDIDY5MTkg Oi0pIDotKS48YnI+DQo8YnI+DQpUaGFua3MsIC0tRGF2aWQ8bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KJmd0OyAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLTxicj4NCiZndDsgRnJvbTogVGltIFN6aWdldGkgKHN6aWdldGkpIFttYWlsdG86 PGEgaHJlZj0ibWFpbHRvOnN6aWdldGlAY2lzY28uY29tIj5zemlnZXRpQGNpc2NvLmNvbTwvYT5d PGJyPg0KJmd0OyBTZW50OiBGcmlkYXksIFNlcHRlbWJlciAxNSwgMjAxNyA4OjU2IFBNPGJyPg0K Jmd0OyBUbzogU3BlbmNlciBEYXdraW5zIGF0IElFVEYgJmx0OzxhIGhyZWY9Im1haWx0bzpzcGVu Y2VyZGF3a2lucy5pZXRmQGdtYWlsLmNvbSI+c3BlbmNlcmRhd2tpbnMuaWV0ZkBnbWFpbC5jb208 L2E+Jmd0OzsgQmxhY2ssIERhdmlkPGJyPg0KJmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRhdmlk LmJsYWNrQGVtYy5jb20iPmRhdmlkLmJsYWNrQGVtYy5jb208L2E+Jmd0Ozxicj4NCiZndDsgQ2M6 IEJsYWNrLCBEYXZpZCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRhdmlkLmJsYWNrQGVtYy5jb20iPmRh dmlkLmJsYWNrQGVtYy5jb208L2E+Jmd0OzsNCjxhIGhyZWY9Im1haWx0bzp0c3Z3Z0BpZXRmLm9y ZyI+dHN2d2dAaWV0Zi5vcmc8L2E+OyBkcmFmdC1pZXRmLXRzdndnLTxicj4NCiZndDsgPGEgaHJl Zj0ibWFpbHRvOmllZWUtODAyLTExQGlldGYub3JnIj5pZWVlLTgwMi0xMUBpZXRmLm9yZzwvYT48 YnI+DQomZ3Q7IFN1YmplY3Q6IFJFOiBBRCBFdmFsdWF0aW9uIGNvbW1lbnRzIGZvciBkcmFmdC1p ZXRmLXRzdndnLWllZWUtODAyLTExLTA3PGJyPg0KJmd0Ozxicj4NCiZndDsgSGkgU3BlbmNlciw8 YnI+DQomZ3Q7PGJyPg0KJmd0OyBUaGFuayB5b3UgdmVyeSBtdWNoIGZvciBnaXZpbmcgdGhpcyBk b2N1bWVudCBhIHRob3JvdWdoIHJlYWQuIFdlIHJlYWxseTxicj4NCiZndDsgYXBwcmVjaWF0ZSB5 b3VyIGZlZWRiYWNrIGFuZCBzdWdnZXN0aW9ucywgYWxsIG9mIHdoaWNoIGhhdmUgYmVlbjxicj4N CiZndDsgaW1wbGVtZW50ZWQgaW4gdGhlIGxhdGVzdCB2ZXJzaW9uICh2MDgpIGp1c3QgcG9zdGVk LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkknbSBnb29kIHRvIGdvIHdpdGggdjA4LCBidXQgcGxlYXNlIGxldCBtZSBrbm93IGlm IGFueXRoaW5nIHdpbGwgY2hhbmdlIGluIHJlc3BvbnNlIHRvIERhdmlkJ3MgcHJldmlvdXMgZS1t YWlsIGluIHRoaXMgdGhyZWFkLCBzbyB3ZSBkb24ndCBzdGFydCBMYXN0IENhbGwgd2l0aCBjb21t ZW50cyB0aGF0IHNob3VsZCBiZSBhZGRyZXNzZWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcywmbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U3BlbmNlcjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxl ZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZndDs8YnI+DQomZ3Q7IENoZWVycywmbmJzcDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyAt dGltPGJyPg0KJmd0Ozxicj4NCiZndDsgJmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxi cj4NCiZndDsgJmd0OyBGcm9tOiBTcGVuY2VyIERhd2tpbnMgYXQgSUVURiBbbWFpbHRvOjxhIGhy ZWY9Im1haWx0bzpzcGVuY2VyZGF3a2lucy5pZXRmQGdtYWlsLmNvbSI+c3BlbmNlcmRhd2tpbnMu aWV0ZkBnbWFpbC5jb208L2E+XTxicj4NCiZndDsgJmd0OyBTZW50OiBUdWVzZGF5LCBTZXB0ZW1i ZXIgMTIsIDIwMTcgNzo1NiBQTTxicj4NCiZndDsgJmd0OyBUbzogRGF2aWQgQmxhY2s8YnI+DQom Z3Q7ICZndDsgQ2M6IERhdmlkIEwuIEJsYWNrOyA8YSBocmVmPSJtYWlsdG86dHN2d2dAaWV0Zi5v cmciPnRzdndnQGlldGYub3JnPC9hPjsgPGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYtdHN2d2ct aWVlZS04MDItMTFAaWV0Zi5vcmciPg0KZHJhZnQtaWV0Zi10c3Z3Zy1pZWVlLTgwMi0xMUBpZXRm Lm9yZzwvYT48YnI+DQomZ3Q7ICZndDsgU3ViamVjdDogQUQgRXZhbHVhdGlvbiBjb21tZW50cyBm b3IgZHJhZnQtaWV0Zi10c3Z3Zy1pZWVlLTgwMi0xMS0wNzxicj4NCiZndDsgJmd0Ozxicj4NCiZn dDsgJmd0OyBUaGlzIHdhcyBhIHZlcnkgZGVuc2UgcmVhZCwgYW5kIEkgZm91bmQgb25seSBhIGZl dyB0aGluZ3MgdG8gYXNrIGFib3V0LCBhbmQ8YnI+DQomZ3Q7ICZndDsgaGFsZiBvZiB0aG9zZSBh cmUgbml0cy48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgTmljZSB3b3JrLjxicj4NCiZn dDsgJmd0Ozxicj4NCiZndDsgJmd0OyBQbGVhc2UgdGFrZSBhIGxvb2sgYXQgbXkgZXZhbHVhdGlv biBjb21tZW50cywgYW5kIGxldCBtZSBrbm93IGhvdyB5b3UnZDxicj4NCiZndDsgJmd0OyBsaWtl IHRvIHByb2NlZWQuPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IFRoYW5rcywgYXMgYWx3 YXlzLjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBTcGVuY2VyPGJyPg0KJmd0OyAmZ3Q7 PGJyPg0KJmd0OyAmZ3Q7IE5pdCwgYnV0IGl0J3MgaW4gdGhlIEFic3RyYWN0IC4uLjxicj4NCiZn dDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7VGhpcyBkb2N1bWVudCBzcGVjaWZp ZXMgYSBzZXQgRGlmZmVyZW50aWF0ZWQ8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwO1NlcnZp Y2VzIENvZGUgUG9pbnQgKERTQ1ApIHRvIElFRUUgODAyLjExIFVzZXIgUHJpb3JpdHkgKFVQKSBt YXBwaW5nczxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBzaG91bGQgdGhpcyBiZSAmcXVv dDsuLi4gc2V0IG9mIERpZmZlcmVudGlhdGVkIFNlcnZpY2VzIENvZGUgUG9pbnQgLi4uJnF1b3Q7 Pzxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBJJ20gbG9va2luZyBhdCB0aGlzIHRleHQs PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDtUaGVyZSBpcyBhbHNv IGEgcmVjb21tZW5kYXRpb24gZnJvbSB0aGUgR2xvYmFsIFN5c3RlbSBmb3IgTW9iaWxlPGJyPg0K Jmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDtDb21tdW5pY2F0aW9ucyBBc3NvY2lhdGlvbiAoR1NNQSks IHNwZWNpZmljYWxseSB0aGVpciBNYXBwaW5nIFF1YWxpdHk8YnI+DQomZ3Q7ICZndDsgJm5ic3A7 ICZuYnNwO29mIFNlcnZpY2UgKFFvUykgUHJvY2VkdXJlcyBvZiBQcm94eSBNb2JpbGUgSVB2NiAo UE1JUHY2KSBhbmQgV0xBTjxicj4NCiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7W1JGQzc1NjFdIHNw ZWNpZmljYXRpb24uJm5ic3A7IFRoaXMgR1NNQSBzcGVjaWZpY2F0aW9uIHdhcyBkZXZlbG9wZWQ8 YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwO3dpdGhvdXQgcmVmZXJlbmNlIHRvIGV4aXN0aW5n IElFVEYgc3BlY2lmaWNhdGlvbnMgZm9yIHZhcmlvdXM8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZu YnNwO3NlcnZpY2VzLCByZWZlcmVuY2VkIGluIFNlY3Rpb24gMS4xLjxicj4NCiZndDsgJmd0Ozxi cj4NCiZndDsgJmd0OyBhbmQgSSdtIG5vdCBxdWl0ZSBzdXJlIGhvdyBhbiBJRVRGLXN0cmVhbSBJ bmZvcm1hdGlvbmFsIFJGQyBwcm9kdWNlZCBieTxicj4NCiZndDsgYTxicj4NCiZndDsgJmd0OyB3 b3JraW5nIGdyb3VwIGJlY29tZXMgJnF1b3Q7YSByZWNvbW1lbmRhdGlvbiBmcm9tIEdTTUEmcXVv dDsgYW5kICZxdW90O2EgR1NNQTxicj4NCiZndDsgJmd0OyBzcGVjaWZpY2F0aW9uJnF1b3Q7LiBJ IHJlY29nbml6ZSB0aGUgbmFtZXMgb2YgdGhlIFJGQyA3NTYxIGF1dGhvcnMsIGFuZCBJIHNlZSB0 aGU8YnI+DQomZ3Q7ICZndDsgY29ubmVjdGlvbiwgYnV0IEkgd291bGQgaGF2ZSB0aG91Z2h0IHRo YXQgdGhlIHJlZmVyZW5jZSB3b3VsZCBoYXZlIGJlZW48YnI+DQomZ3Q7IHRvPGJyPg0KJmd0OyAm Z3Q7IHNvbWV0aGluZyBtb3JlIG9idmlvdXNseSB0aWVkIHRvIEdTTUEuIElzIHRoZXJlIGFueSBy ZWZlcmVuY2UgdGhhdCBjb3VsZDxicj4NCiZndDsgJmd0OyBiZSBjaXRlZCwgdG8gaGVscCBwZW9w bGUgd2hvIGRpZG4ndCBzaXQgdHdvIGRlc2tzIGF3YXkgZnJvbSBvbmUgb2YgdGhlPGJyPg0KJmd0 OyAmZ3Q7IGF1dGhvcnMgc2VlIHRoZSBjb25uZWN0aW9uPzxicj4NCiZndDsgJmd0Ozxicj4NCiZn dDsgJmd0OyBJbiB0aGlzIHRleHQsPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZuYnNw OyAmbmJzcDtUaGlzIGRvY3VtZW50IGFzc3VtZXMgYW5kIFJFQ09NTUVORFMgdGhhdCBhbGwgd2ly ZWxlc3MgYWNjZXNzIHBvaW50czxicj4NCiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7KGFzIHRoZSBi cmlkZ2VzIGJldHdlZW4gd2lyZWQtYW5kLXdpcmVsZXNzIG5ldHdvcmtzKSBzdXBwb3J0IHRoZTxi cj4NCiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7YWJpbGl0eSB0bzo8YnI+DQomZ3Q7ICZndDs8YnI+ DQomZ3Q7ICZndDsgaXMgJnF1b3Q7YnJpZGdlcyZxdW90OyB0aGUgcmlnaHQgd29yZCBoZXJlPyBJ IHdvdWxkIHJlYWQgdGhhdCBhcyBzYXlpbmcgdGhhdCB3aXJlbGVzczxicj4NCiZndDsgJmd0OyBh Y2Nlc3MgcG9pbnRzIGFyZSBhIGxheWVyIHR3by1sYXllciB0d28gYnJpZGdlLiBJZiB5b3UgaGF2 ZSByZWFkZXJzIHdobyBhcmU8YnI+DQomZ3Q7ICZndDsgZmFtaWxpYXIgd2l0aCBJRUVFIDgwMi4x IGJyaWRnaW5nLCB0aGV5IG1heSBiZSBtb3JlIGNvbmZ1c2VkIHRoYW4gSSB3YXMuPGJyPg0KJmd0 OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IEEgbml0IC0gJnF1b3Q7dW51c3VlZCZxdW90OyAtJmd0OyAm cXVvdDt1bnVzZWQmcXVvdDs8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgSSByZWFsbHkg YXBwcmVjaWF0ZSB0aGUgaW5jbHVzaW9uIG9mIFNlY3Rpb24gNiwgYXMgYW4gb3ZlcnZpZXcgb2Yg SUVFRSA4MDIuMTE8YnI+DQomZ3Q7ICZndDsgUW9TLiBJJ2Qgc3VnZ2VzdCB0aGF0IHRoaXMgbm90 IGJlIHRpdGxlZCBhcyAmcXVvdDtBcHBlbmRpeCZxdW90OyAtIHdoaWNoPGJyPg0KJmd0OyAmZ3Q7 IDxhIGhyZWY9Imh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL3JmYy9wZGZyZmMvcmZjNzMyMi50 eHQucGRmIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3d3dy5yZmMtZWRpdG9yLm9yZy9yZmMv cGRmcmZjL3JmYzczMjIudHh0LnBkZjwvYT4gZG9lc24ndCB0aGluayBpcyBwYXJ0PGJyPg0KJmd0 OyBvZjxicj4NCiZndDsgJmd0OyBhbiBSRkMgYm9keSwgc28gYXQgYSBtaW5pbXVtIHRoZXkgd291 bGQgbW92ZSBpdCBiZWhpbmQgdGhlIHNlY3VyaXR5PGJyPg0KJmd0OyAmZ3Q7IGNvbnNpZGVyYXRp b25zLCBidXQgSSdkIGJlIE9LIGlmIHlvdSBsZWZ0IGl0IGFzIGEgbm9ybWFsIFNlY3Rpb24gaW4g dGhlIGJvZHkuPGJyPg0KJmd0OyAmZ3Q7IEFsdGVybmF0aXZlbHksIGlmIHlvdSdyZSBoYXBwaWVy IHdpdGggdGhpcyBtYXRlcmlhbCBhcyBhbiBBcHBlbmRpeCwgaXQnczxicj4NCiZndDsgcHJvYmFi bHk8YnI+DQomZ3Q7ICZndDsgYmV0dGVyIHRvIHNsaWRlIGl0IHRvIHRoZSBiYWNrIG1hdGVyaWFs Ljxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBBIG5pdCAtICZxdW90O29mdGhlaXImcXVv dDsgLSZndDsgJnF1b3Q7b2YgdGhlaXImcXVvdDs8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZn dDsgSSdtIGxvb2tpbmcgYXQgdGhlIGxhc3QgcGFyYWdyYXBoIG9mIHRoZSBTZWN1cml0eSBDb25z aWRlcmF0aW9ucywgYW5kIEknbTxicj4NCiZndDsgJmd0OyB0aGlua2luZyB0aGF0PGJyPg0KJmd0 OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDtGaW5hbGx5LCBpdCBzaG91bGQgYmUg bm90ZWQgdGhhdCB0aGUgcmVjb21tZW5kYXRpb25zIHB1dCBmb3J3YXJkIGluPGJyPg0KJmd0OyAm Z3Q7ICZuYnNwOyAmbmJzcDt0aGlzIGRvY3VtZW50IGFyZSBub3QgaW50ZW5kZWQgdG8gYWRkcmVz cyBhbGwgYXR0YWNrIHZlY3RvcnM8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwO2xldmVyYWdp bmcgUW9TIG1hcmtpbmcgYWJ1c2UuJm5ic3A7IE1lY2hhbmlzbXMgdGhhdCBtYXkgZnVydGhlciBo ZWxwPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDttaXRpZ2F0ZSBzZWN1cml0eSByaXNrcyBp bmNsdWRlIHN0cm9uZyBkZXZpY2UtIGFuZC9vciB1c2VyLTxicj4NCiZndDsgJmd0OyAmbmJzcDsg Jm5ic3A7YXV0aGVudGljYXRpb24sIGFjY2Vzcy1jb250cm9sLCByYXRlIGxpbWl0aW5nLCBjb250 cm9sLXBsYW5lPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDtwb2xpY2luZywgZW5jcnlwdGlv biBhbmQgb3RoZXIgdGVjaG5pcXVlczsgaG93ZXZlciwgdGhlPGJyPg0KJmd0OyAmZ3Q7ICZuYnNw OyAmbmJzcDtpbXBsZW1lbnRhdGlvbiByZWNvbW1lbmRhdGlvbnMgZm9yIHN1Y2ggbWVjaGFuaXNt cyBhcmUgYmV5b25kIHRoZTxicj4NCiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7c2NvcGUgb2YgdGhp cyBkb2N1bWVudCB0byBhZGRyZXNzIGluIGRldGFpbC4mbmJzcDsgU3VmZmljZSBpdCB0byBzYXkg dGhhdDxicj4NCiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7dGhlIHNlY3VyaXR5IG9mIHRoZSBkZXZp Y2VzIGFuZCBuZXR3b3JrcyBpbXBsZW1lbnRpbmcgUW9TLCBpbmNsdWRpbmc8YnI+DQomZ3Q7ICZn dDsgJm5ic3A7ICZuYnNwO1FvUyBtYXBwaW5nIGJldHdlZW4gd2lyZWQgYW5kIHdpcmVsZXNzIG5l dHdvcmtzLCBTSE9VTEQgYmU8YnI+DQomZ3Q7ICZndDsgY29uc2lkZXJlZDxicj4NCiZndDsgJmd0 OyAmbmJzcDsgJm5ic3A7aW4gYWN0dWFsIGRlcGxveW1lbnRzLjxicj4NCiZndDsgJmd0Ozxicj4N CiZndDsgJmd0OyBpcyBtaXNzaW5nIHRoZSAocGVyaGFwcyBvYnZpb3VzKSBwb2ludCB0aGF0IHRo ZSBtZWNoYW5pc21zIHlvdSBsaXN0IHVuZGVyPGJyPg0KJmd0OyAmZ3Q7ICZxdW90O2Z1cnRoZXIg aGVscCZxdW90OyBhcmVuJ3Qgc3BlY2lmaWMgdG8gd2lyZWxlc3MgbmV0d29ya3MsIGJ1dCBzaG91 bGQgYmU8YnI+DQomZ3Q7IGNvbnNpZGVyZWQ8YnI+DQomZ3Q7ICZndDsgZm9yIGFueSBuZXR3b3Jr IHRoYXQgaW1wbGVtZW50cyBRb1MuIFRoYXQgbWlnaHQgYmUgY292ZXJlZCBpbiB0aGUgbGFzdDxi cj4NCiZndDsgJmd0OyBzZW50ZW5jZSwgYnV0IHRoYXQncyBub3Qgd2hhdCBJJ20gZ2V0dGluZyBv dXQgb2YgdGhlIGxhc3Qgc2VudGVuY2UuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_dc3d512a82ba44a39e286fdfbafbbf83XCHRCD010ciscocom_-- From nobody Tue Sep 19 15:46:26 2017 Return-Path: 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 1BBB0132944; Tue, 19 Sep 2017 15:46:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 EIgH-zbESkrq; Tue, 19 Sep 2017 15:46:23 -0700 (PDT) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (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 4484513219E; Tue, 19 Sep 2017 15:46:23 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id u205so767907ywa.5; Tue, 19 Sep 2017 15:46:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=nzldbrPcsEex10XVzjwvhQLSUH9GT2GkUy5mOWFB85o=; b=TFokv8Nb5xmdzZoVUddnk2DRG+jnOhHb4SGN+pYRmVESKanUWU4Op6/PvOAOwGrOLW wRkrJEPZS4CURtsLQMBp+VlVU3LrSmY5LUA8JlUNPYp5J3hDCc7VkpVYpe2Kgjc1Lgfs mCk/We8Hg4x4ZgRROfojws0LYAg2wrEuURVuQQJPSLj6u0/TeCTBJngxPDmmlM6exbxt EeuygISVZiK08MnBGMoGZhvrk1ro+m7Qk9qgmWZPEunnWRmNa/UTdGXNMmp+apvngCW2 RpRyRnjnubXONVDtet13Bu0C4edpll3l2Q2NlSdPq5JZmBsYwwwbugtl34jCGT53J0UK hOMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=nzldbrPcsEex10XVzjwvhQLSUH9GT2GkUy5mOWFB85o=; b=WCWt1YzjrKPpj42n2X4EcDpoQG1jWsbG9K4eexpBzBG6jZx+jLdMEjUR98LVp6T+Jv YapOZsV1+GmPR+Zt50c1sKocBlsifbQzhja5/+/HFzw1120m8ldGh/meAM3E1SBWJ1VM GwDxIBAw99km2Jmswk0OmeZbGncWnOWvtdHG18kFW4HUYfquaoFVnSsh3tCdXq+jp5Qx K0Igs+1NQgBMj3nH0xAIRE+nGWvpbABEPhBj62B4X//Wn1YAy9mX2cbsjioXkbHRbM1D X7DFMg/r1W3H3ZauLNzrXUrNT/rjT4sh+/hQFKCK7QX1BCkJ6Ni22C014krYUw2jawAl p14Q== X-Gm-Message-State: AHPjjUjTxUttyQ6xO7lZPWxDl69t1XDI8G2LZ36jmeipKMAuOx07Ffmn YuLQbJrSlxLZHzQiSsU1AspeIQ3Wr8uRBvGNzkw= X-Google-Smtp-Source: AOwi7QBpTuG5l0oBSpjc3r/9IM9P0X6uwagJsb24P1HSqpS2go9LNhfnNeVTGsS40M6K7vBREyzygmn5P7FUScPQ/2Y= X-Received: by 10.37.107.13 with SMTP id g13mr1919188ybc.211.1505861182131; Tue, 19 Sep 2017 15:46:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.2.15 with HTTP; Tue, 19 Sep 2017 15:46:21 -0700 (PDT) In-Reply-To: References: From: Spencer Dawkins at IETF Date: Tue, 19 Sep 2017 17:46:21 -0500 Message-ID: To: "Tim Szigeti (szigeti)" Cc: "Black, David" , "tsvwg@ietf.org" , "draft-ietf-tsvwg-ieee-802-11@ietf.org" Content-Type: multipart/alternative; boundary="089e082659d4d794cb055992a09d" Archived-At: Subject: Re: [tsvwg] AD Evaluation comments for draft-ietf-tsvwg-ieee-802-11-07 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Sep 2017 22:46:25 -0000 --089e082659d4d794cb055992a09d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear David the Document Shepherd, On Mon, Sep 18, 2017 at 11:18 PM, Tim Szigeti (szigeti) wrote: > Hi Spencer, > > > > I made the minor change requested; now the sentence avoids the loaded ter= m > =E2=80=98should consider=E2=80=99. > > > > Suffice it to say that the security of the devices and networks > implementing QoS, including QoS mapping between wired and wireless > networks, merits consideration in actual deployments. > > > > (Thanks David for bringing this to our attention). > > > > With that done, I think we=E2=80=99re ready for Last Call. > Ready for me to pull the trigger? Spencer --089e082659d4d794cb055992a09d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear David the Document Shepherd,

On Mon, Sep 18, 2017 at 11:18 PM, Tim Szig= eti (szigeti) <szigeti@cisco.com> wrote:

Hi Spencer,=

=C2=A0

I made the minor change r= equested; now the sentence avoids the loaded term =E2=80=98should consider= =E2=80=99.

=C2=A0

Suffice it to say that the security of the devices and networks impleme= nting QoS, including QoS mapping between wired and wireless networks, merits consideration in actual deployments.=

=C2=A0

(Thanks David for bringin= g this to our attention).

=C2=A0

With that done, I think w= e=E2=80=99re ready for Last Call.

<= br>
Ready for me to pull the trigger?

Sp= encer=C2=A0
--089e082659d4d794cb055992a09d-- From nobody Wed Sep 20 15:45:42 2017 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 12C0F1243F6; Wed, 20 Sep 2017 15:45:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tsvwg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.62.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150594754103.24956.4959685476000689054@ietfa.amsl.com> Date: Wed, 20 Sep 2017 15:45:41 -0700 Archived-At: Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-experimentation-06.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Sep 2017 22:45:41 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group WG of the IETF. Title : Explicit Congestion Notification (ECN) Experimentation Author : David Black Filename : draft-ietf-tsvwg-ecn-experimentation-06.txt Pages : 18 Date : 2017-09-20 Abstract: This memo updates RFC 3168, which specifies Explicit Congestion Notification (ECN) as a replacement for packet drops as indicators of network congestion. It relaxes restrictions in RFC 3168 that would otherwise hinder experimentation towards benefits beyond just removal of loss. This memo summarizes the anticipated areas of experimentation and updates RFC 3168 to enable experimentation in these areas. An Experimental RFC is required to take advantage of any of these enabling updates. In addition, this memo makes related updates to the ECN specifications for RTP in RFC 6679 and for DCCP in RFC 4341, RFC 4342 and RFC 5622. This memo also records the conclusion of the ECN nonce experiment in RFC 3540, and provides the rationale for reclassification of RFC 3540 as Historic; this reclassification enables new experimental use of the ECT(1) codepoint. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-experimentation/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-experimentation-06 https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-ecn-experimentation-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-ecn-experimentation-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Sep 20 15:46:01 2017 Return-Path: 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 B348D13433D; Wed, 20 Sep 2017 15:45:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.001 X-Spam-Level: X-Spam-Status: No, score=-5.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dell.com header.b=aO4pRPkQ; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=OtCsTiXK 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 6bS1vAnEM7nV; Wed, 20 Sep 2017 15:45:43 -0700 (PDT) Received: from esa1.dell-outbound.iphmx.com (esa1.dell-outbound.iphmx.com [68.232.153.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28584134300; Wed, 20 Sep 2017 15:45:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1505947388; x=1537483388; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=+WyOzOfyo8dWQ2rYgIwHCfc8UKMwgyiZj4y81Phs/k8=; b=aO4pRPkQT/pNvqewJR2APi9gaskBw8LdP5K4Kg8aNqkxcHFBl2RQBonn j7NDrGmLTb8zpDWkfjxzVNoyNj9nKf7ExDg8kKcHkkgcDOag9ep22HSCL pUSAGeosgk134JbHIudsiDhBGFUKTDMiCn+TLMEqxPsRwA5n2R9T+iiI9 I=; Received: from esa5.dell-outbound2.iphmx.com ([68.232.153.203]) by esa1.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Sep 2017 17:43:07 -0500 From: "Black, David" Received: from mailuogwdur.emc.com ([128.221.224.79]) by esa5.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Sep 2017 04:36:29 +0600 Received: from maildlpprd55.lss.emc.com (maildlpprd55.lss.emc.com [10.106.48.159]) by mailuogwprd54.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v8KMjZfY025488 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 20 Sep 2017 18:45:40 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com v8KMjZfY025488 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1505947540; bh=X95SPHqFzN8+HYMWVaTZSXIACzY=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=OtCsTiXKqZbajYj6cZW0YKX2oYCgsazVPV6P/w0v5tSP56zePv+S7XzWEuuM9kZoo FkDy8W+ZJS1ifPQWHiq7Ujbr6gyYJ/jtJbNnrM89BuY8bmTr+JfPZXKrw0P44IHxXX 3VGr08LgFfY2V650GmhpevUuu5XJTxmGVlZPExVk= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com v8KMjZfY025488 Received: from mailusrhubprd02.lss.emc.com (mailusrhubprd02.lss.emc.com [10.253.24.20]) by maildlpprd55.lss.emc.com (RSA Interceptor); Wed, 20 Sep 2017 18:44:40 -0400 Received: from MXHUB309.corp.emc.com (MXHUB309.corp.emc.com [10.146.3.35]) by mailusrhubprd02.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v8KMjEQ8024949 (version=TLSv1.2 cipher=AES128-SHA256 bits=128 verify=FAIL); Wed, 20 Sep 2017 18:45:14 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB309.corp.emc.com ([10.146.3.35]) with mapi id 14.03.0352.000; Wed, 20 Sep 2017 18:45:14 -0400 To: Brian E Carpenter , "gen-art@ietf.org" CC: "draft-ietf-tsvwg-ecn-experimentation.all@ietf.org" , "tsvwg@ietf.org" Thread-Topic: Genart telechat review of draft-ietf-tsvwg-ecn-experimentation-05 Thread-Index: AQHTIsZAf8GsSgkmu0q70NA4hkw3sKKgjxdggABmDoCAHYckYA== Date: Wed, 20 Sep 2017 22:45:13 +0000 Message-ID: References: <150423129417.4604.2689843099266054478@ietfa.amsl.com> <6afe85ba-83c5-5945-fd37-dc313eb22162@gmail.com> In-Reply-To: <6afe85ba-83c5-5945-fd37-dc313eb22162@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.105.8.135] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd02.lss.emc.com X-RSA-Classifications: public Archived-At: Subject: Re: [tsvwg] Genart telechat review of draft-ietf-tsvwg-ecn-experimentation-05 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Sep 2017 22:45:46 -0000 QnJpYW4sDQoNCkknbSBhYm91dCB0byBwb3N0IHRoZSAtMDYgdmVyc2lvbiBvZiB0aGlzIGRyYWZ0 LiAgIFRoZSBjb25jZXJuIG9uIFJGQyAzMTY4IGltcGFjdCBvZiB0aGUgRUNOIG5vbmNlIHJlbW92 YWwgd2FzIHJlc29sdmVkIGJ5IGxpc3RpbmcgdGhlIGZvdXIgbWFqb3IgY2hhbmdlcyAoYW5kIHlv dSB3ZXJlIGNvcnJlY3QgdGhhdCB0aGUgY2hhbmdlIHRvIFNlY3Rpb24gMjAuMiBpcyBzdWJ0bGUg LSBJIGdvdCBpdCB3cm9uZyBvbiBteSBmaXJzdCBhdHRlbXB0IGluIHJlc3BvbmRpbmcgdG8geW91 ciBlbWFpbCkuICBIZXJlJ3MgdGhlIHNwZWNpZmljIHRleHQgdGhhdCBJJ3ZlIGFkZGVkIHRvIFNl Y3Rpb24gMyBvZiB0aGUgZHJhZnQ6DQoNCiAgIFRoZSBmb3VyIHByaW1hcnkgdXBkYXRlcyB0byBS RkMgMzE2OCB0aGF0IHJlbW92ZSBkaXNjdXNzaW9uIG9mIHRoZQ0KICAgRUNOIG5vbmNlIGFuZCB1 c2Ugb2YgRUNUKDEpIGZvciB0aGF0IG5vbmNlIGFyZToNCg0KICAgMS4gIFJlbW92ZSB0aGUgcGFy YWdyYXBoIGluIFNlY3Rpb24gNSB0aGF0IGltbWVkaWF0ZWx5IGZvbGxvd3MNCiAgICAgICBGaWd1 cmUgMTsgdGhpcyBwYXJhZ3JhcGggZGlzY3Vzc2VzIHRoZSBFQ04gbm9uY2UgYXMgdGhlDQogICAg ICAgbW90aXZhdGlvbiBmb3IgdHdvIEVDVCBjb2RlcG9pbnRzLg0KDQogICAyLiAgUmVtb3ZlIFNl Y3Rpb24gMTEuMiAiQSBEaXNjdXNzaW9uIG9mIHRoZSBFQ04gbm9uY2UuIiBpbiBpdHMNCiAgICAg ICBlbnRpcmV0eS4NCg0KICAgMy4gIFJlbW92ZSB0aGUgbGFzdCBwYXJhZ3JhcGggb2YgU2VjdGlv biAxMiwgd2hpY2ggc3RhdGVzIHRoYXQgRUNUKDEpDQogICAgICAgbWF5IGJlIHVzZWQgYXMgcGFy dCBvZiB0aGUgaW1wbGVtZW50YXRpb24gb2YgdGhlIEVDTiBub25jZS4NCg0KICAgNC4gIFJlbW92 ZSB0aGUgZmlyc3QgdHdvIHBhcmFncmFwaHMgb2YgU2VjdGlvbiAyMC4yLCB3aGljaCBkaXNjdXNz DQogICAgICAgdGhlIEVDTiBub25jZSBhbmQgYWx0ZXJuYXRpdmVzLiAgTm8gY2hhbmdlcyBhcmUg bWFkZSB0byB0aGUgcmVzdA0KICAgICAgIG9mIFNlY3Rpb24gMjAuMiwgd2hpY2ggZGlzY3Vzc2Vz IGFsdGVybmF0ZSB1c2VzIGZvciB0aGUgZm91cnRoDQogICAgICAgRUNOIGNvZGVwb2ludC4NCg0K ICAgQWRkaXRpb25hbCBtaW5vciBjaGFuZ2VzIHJlbW92ZSBvdGhlciBtZW50aW9ucyBvZiB0aGUg RUNOIG5vbmNlIGFuZA0KICAgaW1wbGljYXRpb25zIHRoYXQgRUNUKDEpIGlzIGludGVuZGVkIGZv ciB1c2UgYnkgdGhlIEVDTiBub25jZTsgdGhlDQogICBzcGVjaWZpYyB0ZXh0IHVwZGF0ZXMgYXJl IG9taXR0ZWQgZm9yIGJyZXZpdHkuDQoNClRoZSBwcm92ZXJiaWFsICJyZXN0IG9mIHRoZSBzdG9y eSIgaXMgdGhhdCBhbiBSRkMgMzE2OGJpcyBlZmZvcnQgYXBwZWFycyB0byBiZSBhIGdvb2QgaWRl YSwgZS5nLiwgYXMgUkZDIDYwNDAgaGFzIGFscmVhZHkgbWFkZSBzb21lIHZpc2libGUgY2hhbmdl cy4gVGhlIHByZWZlcnJlZCAzMTY4YmlzIHRpbWluZyBhcHBlYXJzIHRvIGJlIGFmdGVyIHdlIHVu ZGVyc3RhbmQgdGhlIG91dGNvbWVzIG9mIHRoZSBjdXJyZW50IHByb3Bvc2VkIG9mIGV4cGVyaW1l bnRzLCBhcyB0aGV5J3JlIGxpa2VseSB0byByZXN1bHQgaW4gYW5vdGhlciByb3VuZCBvZiBjaGFu Z2VzIHRvIFJGQyAzMTY4Lg0KDQpNYW55IHRoYW5rcywgYW5kIGNoYWxrIHRoaXMgdXAgYXMgb25l IG1vcmUgaW5zdGFuY2Ugd2hlcmUgYSBHZW5BUlQgcmV2aWV3IGhhcyB2aXNpYmx5IGltcHJvdmVk IHRoZSBxdWFsaXR5IG9mIGEgZHJhZnQsICAtLURhdmlkDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCj4gRnJvbTogQnJpYW4gRSBDYXJwZW50ZXIgW21haWx0bzpicmlhbi5lLmNhcnBl bnRlckBnbWFpbC5jb21dDQo+IFNlbnQ6IEZyaWRheSwgU2VwdGVtYmVyIDEsIDIwMTcgNzo0MSBQ TQ0KPiBUbzogQmxhY2ssIERhdmlkIDxkYXZpZC5ibGFja0BlbWMuY29tPjsgZ2VuLWFydEBpZXRm Lm9yZw0KPiBDYzogZHJhZnQtaWV0Zi10c3Z3Zy1lY24tZXhwZXJpbWVudGF0aW9uLmFsbEBpZXRm Lm9yZzsgdHN2d2dAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IEdlbmFydCB0ZWxlY2hhdCByZXZp ZXcgb2YgZHJhZnQtaWV0Zi10c3Z3Zy1lY24tDQo+IGV4cGVyaW1lbnRhdGlvbi0wNQ0KPiANCj4g T24gMDIvMDkvMjAxNyAwOTo0NSwgQmxhY2ssIERhdmlkIHdyb3RlOg0KPiA+IEJyaWFuLA0KPiA+ DQo+ID4gVGhhbmtzIGZvciB0aGUgcHJvbXB0IHJldmlldy4NCj4gPg0KPiA+PiBDb21tZW50OiBW ZXJ5IGNsZWFyIGZyb20gdGhlIHRlY2huaWNhbCBzdGFuZHBvaW50Lg0KPiA+DQo+ID4gVGhhbmsg eW91IQ0KPiA+DQo+ID4+IEkgdW5kZXJzdGFuZCB0aGUgZGVzaXJlIGZvciBicmV2aXR5LCBidXQg dGhpcyBib3RoZXJzIG1lIGEgYml0LiBXaGF0IGlzDQo+ID4+IHRoZSByZWFkZXIgdG8gbWFrZSBv ZiBSRkMzMTY4IFNlY3Rpb24gMjAuMiwgZm9yIGV4YW1wbGU/IE15IGZlZWxpbmcgaXMNCj4gPj4g dGhhdCBhIHNob3J0IEFwcGVuZGl4IG91dGxpbmluZyB0aGUgc3BlY2lmaWMgdXBkYXRlcyB3b3Vs ZCBiZSB1c2VmdWwuDQo+ID4+IFRoZXJlJ3MgYWxyZWFkeSB0b28gbXVjaCBzcGFnaGV0dGkgdG8g dW50YW5nbGUuDQo+ID4NCj4gPiBSRkMgMzE2OCBTZWN0aW9uIDIwLjIgaXMgdGhlIHJhdGlvbmFs ZSBmb3IgdGhlIEVDTiBOb25jZSBhbmQgaGVuY2Ugd291bGQNCj4gYmUNCj4gPiBkZWxldGVkLiBS ZXF1ZXN0IG5vdGVkLCBJJ2xsIGNvbnN1bHQgd2l0aCB0aGUgZHJhZnQgc2hlcGhlcmQgYW5kDQo+ IHJlc3BvbnNpYmxlDQo+ID4gQUQgdG8gZmlndXJlIG91dCB3aGV0aGVyIHRvIGRvIHRoaXMuDQo+ IA0KPiBUaGFua3MuIEl0J3Mgbm90IGludGVuZGVkIGFzIGEgYmxvY2tpbmcgaXNzdWUuDQo+IA0K PiA+DQo+ID4+IEkgc2VlIG5vIHJlYXNvbiB3aHkgUkZDMzU0MCBhbmQgUkZDNTYyMiBuZWVkIHRv IGJlIG5vcm1hdGl2ZQ0KPiByZWZlcmVuY2VzDQo+ID4+IChhbmQgdGhlcmVmb3JlIGRvd25yZWZz KS4gVGhleSBhcmVuJ3QgcmVxdWlyZWQgcmVhZGluZyBpbiBvcmRlciB0bw0KPiA+PiB1bmRlcnN0 YW5kIHRoaXMgZHJhZnQuDQo+ID4NCj4gPiBPVE9ILCBib3RoIGFyZSBhZmZlY3RlZCBieSB0aGlz IGRyYWZ0Og0KPiA+DQo+ID4gSW4gcmV2ZXJzZSBvcmRlciwgdGhpcyBkcmFmdCB1cGRhdGVzIFJG QyA1NjIyIC0gdGhhdCBzZWVtcyB0byBtZXJpdCBhDQo+ID4gbm9ybWF0aXZlIHJlZmVyZW5jZS4g ICAgVGhpcyBkcmFmdCBhbHNvIHByb3ZpZGVzIHRoZSByYXRpb25hbGUgZm9yIHRoZQ0KPiA+IHN0 YXR1cyBjaGFuZ2Ugb2YgUkZDIDM1NDAgdG8gSGlzdG9yaWMsIHdoaWNoIGFsc28gc2VlbXMgdG8g bWVyaXQgYQ0KPiA+IG5vcm1hdGl2ZSByZWZlcmVuY2UuDQo+IA0KPiBXZWxsLCBteSB1bmRlcnN0 YW5kaW5nIGlzIHRoYXQgYSBub3JtYXRpdmUgcmVmZXJlbmNlIGlzIG5lZWRlZCBvbmx5DQo+IHdo ZW4gdGhlIGNpdGluZyBkb2N1bWVudCBjYW5ub3QgYmUgdW5kZXJzdG9vZCBhbmQgaW1wbGVtZW50 ZWQNCj4gd2l0aG91dCByZWFkaW5nIHRoZSBjaXRlZCBkb2N1bWVudC4NCj4gDQo+IEFnYWluIGl0 J3Mgbm90IGEgYmxvY2tpbmcgY29tbWVudCAtIGFsdGhvdWdoIHRoZXJlIGlzIGEgdGVjaG5pY2Fs IGVycm9yDQo+IGluIHRoZSBMYXN0IENhbGwgbWVzc2FnZTogaXQgZmxhZ3MgdGhlIGRvd25yZWYg dG8gNTYyMiwgYnV0IG5vdCB0aGF0IHRvIDM1NDAuDQo+IEkgZG9uJ3Qga25vdyBpZiB0aGF0J3Mg YSB0b29sIGVycm9yIG9yIGFuIEFEIGVycm9yIDstKS4NCj4gDQo+ICAgICBCcmlhbg0KPiANCj4g Pg0KPiA+IFRoYW5rcywgLS1EYXZpZA0KPiA+DQo+ID4NCj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCj4gPj4gRnJvbTogQnJpYW4gQ2FycGVudGVyIFttYWlsdG86YnJpYW4uZS5jYXJw ZW50ZXJAZ21haWwuY29tXQ0KPiA+PiBTZW50OiBUaHVyc2RheSwgQXVndXN0IDMxLCAyMDE3IDEw OjAyIFBNDQo+ID4+IFRvOiBnZW4tYXJ0QGlldGYub3JnDQo+ID4+IENjOiBkcmFmdC1pZXRmLXRz dndnLWVjbi1leHBlcmltZW50YXRpb24uYWxsQGlldGYub3JnOyB0c3Z3Z0BpZXRmLm9yZw0KPiA+ PiBTdWJqZWN0OiBHZW5hcnQgdGVsZWNoYXQgcmV2aWV3IG9mIGRyYWZ0LWlldGYtdHN2d2ctZWNu LWV4cGVyaW1lbnRhdGlvbi0NCj4gMDUNCj4gPj4NCj4gPj4gUmV2aWV3ZXI6IEJyaWFuIENhcnBl bnRlcg0KPiA+PiBSZXZpZXcgcmVzdWx0OiBSZWFkeSB3aXRoIElzc3Vlcw0KPiA+Pg0KPiA+PiBH ZW4tQVJUIExhc3QgQ2FsbCByZXZpZXcgb2YgZHJhZnQtaWV0Zi10c3Z3Zy1lY24tZXhwZXJpbWVu dGF0aW9uLTA1DQo+ID4+DQo+ID4+IEkgYW0gdGhlIGFzc2lnbmVkIEdlbi1BUlQgcmV2aWV3ZXIg Zm9yIHRoaXMgZHJhZnQuIFRoZSBHZW5lcmFsIEFyZWENCj4gPj4gUmV2aWV3IFRlYW0gKEdlbi1B UlQpIHJldmlld3MgYWxsIElFVEYgZG9jdW1lbnRzIGJlaW5nIHByb2Nlc3NlZA0KPiA+PiBieSB0 aGUgSUVTRyBmb3IgdGhlIElFVEYgQ2hhaXIuICBQbGVhc2UgdHJlYXQgdGhlc2UgY29tbWVudHMg anVzdA0KPiA+PiBsaWtlIGFueSBvdGhlciBsYXN0IGNhbGwgY29tbWVudHMuDQo+ID4+DQo+ID4+ IEZvciBtb3JlIGluZm9ybWF0aW9uLCBwbGVhc2Ugc2VlIHRoZSBGQVEgYXQNCj4gPj4gPGh0dHA6 Ly93aWtpLnRvb2xzLmlldGYub3JnL2FyZWEvZ2VuL3RyYWMvd2lraS9HZW5BcnRmYXE+Lg0KPiA+ Pg0KPiA+PiBEb2N1bWVudDogZHJhZnQtaWV0Zi10c3Z3Zy1lY24tZXhwZXJpbWVudGF0aW9uLTA1 LnR4dA0KPiA+PiBSZXZpZXdlcjogQnJpYW4gQ2FycGVudGVyDQo+ID4+IFJldmlldyBEYXRlOiAy MDE3LTA5LTAxDQo+ID4+IElFVEYgTEMgRW5kIERhdGU6IDIwMTctMDktMTQNCj4gPj4gSUVTRyBU ZWxlY2hhdCBkYXRlOiAyMDE3LTA5LTE0DQo+ID4+DQo+ID4+IFN1bW1hcnk6IFJlYWR5IHdpdGgg KG1pbm9yKSBpc3N1ZXMNCj4gPj4gLS0tLS0tLS0NCj4gPj4NCj4gPj4gQ29tbWVudDogVmVyeSBj bGVhciBmcm9tIHRoZSB0ZWNobmljYWwgc3RhbmRwb2ludC4NCj4gPj4gLS0tLS0tLS0NCj4gPj4N Cj4gPj4gTWlub3IgSXNzdWVzOg0KPiA+PiAtLS0tLS0tLS0tLS0tDQo+ID4+DQo+ID4+PiAzLiAg RUNOIE5vbmNlIGFuZCBSRkMgMzU0MA0KPiA+PiAuLi4NCj4gPj4+IG8gIFVwZGF0ZXMgUkZDIDMx NjggW1JGQzMxNjhdIHRvIHJlbW92ZSBkaXNjdXNzaW9uIG9mIHRoZSBFQ04gTm9uY2UNCj4gPj4+ ICAgIGFuZCB1c2Ugb2YgRUNUKDEpIGZvciB0aGF0IE5vbmNlLiAgVGhlIHNwZWNpZmljIHRleHQg dXBkYXRlcyBhcmUNCj4gPj4+ICAgIG9taXR0ZWQgZm9yIGJyZXZpdHkuDQo+ID4+DQo+ID4+IEkg dW5kZXJzdGFuZCB0aGUgZGVzaXJlIGZvciBicmV2aXR5LCBidXQgdGhpcyBib3RoZXJzIG1lIGEg Yml0LiBXaGF0IGlzDQo+ID4+IHRoZSByZWFkZXIgdG8gbWFrZSBvZiBSRkMzMTY4IFNlY3Rpb24g MjAuMiwgZm9yIGV4YW1wbGU/IE15IGZlZWxpbmcgaXMNCj4gPj4gdGhhdCBhIHNob3J0IEFwcGVu ZGl4IG91dGxpbmluZyB0aGUgc3BlY2lmaWMgdXBkYXRlcyB3b3VsZCBiZSB1c2VmdWwuDQo+ID4+ IFRoZXJlJ3MgYWxyZWFkeSB0b28gbXVjaCBzcGFnaGV0dGkgdG8gdW50YW5nbGUuDQo+ID4+DQo+ ID4+IEkgc2VlIG5vIHJlYXNvbiB3aHkgUkZDMzU0MCBhbmQgUkZDNTYyMiBuZWVkIHRvIGJlIG5v cm1hdGl2ZQ0KPiByZWZlcmVuY2VzDQo+ID4+IChhbmQgdGhlcmVmb3JlIGRvd25yZWZzKS4gVGhl eSBhcmVuJ3QgcmVxdWlyZWQgcmVhZGluZyBpbiBvcmRlciB0bw0KPiA+PiB1bmRlcnN0YW5kIHRo aXMgZHJhZnQuDQo+ID4+DQo+ID4+IC0tDQo+ID4NCg== From nobody Wed Sep 20 19:03:35 2017 Return-Path: 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 6D6581320DC; Wed, 20 Sep 2017 19:03:29 -0700 (PDT) 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 d4G3HZiQaGRh; Wed, 20 Sep 2017 19:03:27 -0700 (PDT) Received: from mail-pg0-x22f.google.com (mail-pg0-x22f.google.com [IPv6:2607:f8b0:400e:c05::22f]) (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 2CAC21252BA; Wed, 20 Sep 2017 19:03:27 -0700 (PDT) Received: by mail-pg0-x22f.google.com with SMTP id b11so2702389pgn.12; Wed, 20 Sep 2017 19:03:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=0XnJndgfewHE3yVyAxePqpTE8GN/GmGNZNIjcxBDWgw=; b=LHYS9ylDWjL/ln7niCGJDUYV/o9r5aonJO0JoLhdWN+0AEKrMY0aWjoNjdsy1KZCjB PvMxprb6u9IBfEqfj68Co6cjicqDdymq3eQJdPDx+/vd4KkvUjPLiL6gZaQMFpbFNgPu U5Mh5f0tVhVU+AuIhOHBgrP8opfuzFWKmbw9X+Tlfb0Wv1v40hLpi0Ek1cuwupa+qOXI Qy9yfvPKRvBKBPSFrePSyqs+FRftO/pFhi3kEU93sc97ajlwkv3xwOvDGoeZHstupGXJ LcaXyytmxUdcXMV55bOT+l8lcNYw9cNK7rv3um2zuNfuukFWnllZa2+oFQ0M9A0au8qr 7ZVg== 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:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=0XnJndgfewHE3yVyAxePqpTE8GN/GmGNZNIjcxBDWgw=; b=Q9/iF8tX3e+chS7QttWQbXSqumRv875S0I4qnJJI0WGUOVP/vSlTUrwB1ro0SLm/w6 oUMNwiGTAZHTCeoIx728Aiwm1xpj3pL/jl7OKVgu1hzsKJWpTY0x9K3aZiwvlJWfrAYx YUAkrTth2w78O2UUYj0jRGayQxEICYRs41dDROIKjHslAvxWjrXgz3MEgZiJmo/SUuo8 IG8vEDxLZqieHTwmzke27XgFYxXdlgGmZ9ovWDmp1+YwdvlERHAKvTPCp7FHAjyE529s I9XFXbRBCZgZ+450tkVR1mJx8OHgQPFkk/ZNJK11HJCjpiczwyT7VeDbsFyxMMFAt/Xi tucQ== X-Gm-Message-State: AHPjjUjCmd3CDAiPF34hSTMEMTfIXzxiI38XmNgMamUHkPrCUNUSWPBn 9nE0V2mFlQIzAplnkC7V9iBgTA== X-Google-Smtp-Source: AOwi7QA7QGP4WflYvQDPah0Nuacm6TfsEgPfguRVLo25F/fVB7PS3qLmGLvIPNlucHTvKmRkOfp3Bg== X-Received: by 10.99.180.65 with SMTP id n1mr4164977pgu.313.1505959404851; Wed, 20 Sep 2017 19:03:24 -0700 (PDT) Received: from ?IPv6:2406:e001:3f51:1:28cc:dc4c:9703:6781? ([2406:e001:3f51:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id s76sm308990pfj.119.2017.09.20.19.03.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 20 Sep 2017 19:03:23 -0700 (PDT) To: "Black, David" , "gen-art@ietf.org" Cc: "draft-ietf-tsvwg-ecn-experimentation.all@ietf.org" , "tsvwg@ietf.org" References: <150423129417.4604.2689843099266054478@ietfa.amsl.com> <6afe85ba-83c5-5945-fd37-dc313eb22162@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Thu, 21 Sep 2017 14:03:27 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [tsvwg] Genart telechat review of draft-ietf-tsvwg-ecn-experimentation-05 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Sep 2017 02:03:29 -0000 Thanks David. That completely responds to my comments. Regards Brian On 21/09/2017 10:45, Black, David wrote: > Brian, > > I'm about to post the -06 version of this draft. The concern on RFC 3168 impact of the ECN nonce removal was resolved by listing the four major changes (and you were correct that the change to Section 20.2 is subtle - I got it wrong on my first attempt in responding to your email). Here's the specific text that I've added to Section 3 of the draft: > > The four primary updates to RFC 3168 that remove discussion of the > ECN nonce and use of ECT(1) for that nonce are: > > 1. Remove the paragraph in Section 5 that immediately follows > Figure 1; this paragraph discusses the ECN nonce as the > motivation for two ECT codepoints. > > 2. Remove Section 11.2 "A Discussion of the ECN nonce." in its > entirety. > > 3. Remove the last paragraph of Section 12, which states that ECT(1) > may be used as part of the implementation of the ECN nonce. > > 4. Remove the first two paragraphs of Section 20.2, which discuss > the ECN nonce and alternatives. No changes are made to the rest > of Section 20.2, which discusses alternate uses for the fourth > ECN codepoint. > > Additional minor changes remove other mentions of the ECN nonce and > implications that ECT(1) is intended for use by the ECN nonce; the > specific text updates are omitted for brevity. > > The proverbial "rest of the story" is that an RFC 3168bis effort appears to be a good idea, e.g., as RFC 6040 has already made some visible changes. The preferred 3168bis timing appears to be after we understand the outcomes of the current proposed of experiments, as they're likely to result in another round of changes to RFC 3168. > > Many thanks, and chalk this up as one more instance where a GenART review has visibly improved the quality of a draft, --David > >> -----Original Message----- >> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] >> Sent: Friday, September 1, 2017 7:41 PM >> To: Black, David ; gen-art@ietf.org >> Cc: draft-ietf-tsvwg-ecn-experimentation.all@ietf.org; tsvwg@ietf.org >> Subject: Re: Genart telechat review of draft-ietf-tsvwg-ecn- >> experimentation-05 >> >> On 02/09/2017 09:45, Black, David wrote: >>> Brian, >>> >>> Thanks for the prompt review. >>> >>>> Comment: Very clear from the technical standpoint. >>> >>> Thank you! >>> >>>> I understand the desire for brevity, but this bothers me a bit. What is >>>> the reader to make of RFC3168 Section 20.2, for example? My feeling is >>>> that a short Appendix outlining the specific updates would be useful. >>>> There's already too much spaghetti to untangle. >>> >>> RFC 3168 Section 20.2 is the rationale for the ECN Nonce and hence would >> be >>> deleted. Request noted, I'll consult with the draft shepherd and >> responsible >>> AD to figure out whether to do this. >> >> Thanks. It's not intended as a blocking issue. >> >>> >>>> I see no reason why RFC3540 and RFC5622 need to be normative >> references >>>> (and therefore downrefs). They aren't required reading in order to >>>> understand this draft. >>> >>> OTOH, both are affected by this draft: >>> >>> In reverse order, this draft updates RFC 5622 - that seems to merit a >>> normative reference. This draft also provides the rationale for the >>> status change of RFC 3540 to Historic, which also seems to merit a >>> normative reference. >> >> Well, my understanding is that a normative reference is needed only >> when the citing document cannot be understood and implemented >> without reading the cited document. >> >> Again it's not a blocking comment - although there is a technical error >> in the Last Call message: it flags the downref to 5622, but not that to 3540. >> I don't know if that's a tool error or an AD error ;-). >> >> Brian >> >>> >>> Thanks, --David >>> >>> >>>> -----Original Message----- >>>> From: Brian Carpenter [mailto:brian.e.carpenter@gmail.com] >>>> Sent: Thursday, August 31, 2017 10:02 PM >>>> To: gen-art@ietf.org >>>> Cc: draft-ietf-tsvwg-ecn-experimentation.all@ietf.org; tsvwg@ietf.org >>>> Subject: Genart telechat review of draft-ietf-tsvwg-ecn-experimentation- >> 05 >>>> >>>> Reviewer: Brian Carpenter >>>> Review result: Ready with Issues >>>> >>>> Gen-ART Last Call review of draft-ietf-tsvwg-ecn-experimentation-05 >>>> >>>> I am the assigned Gen-ART reviewer for this draft. The General Area >>>> Review Team (Gen-ART) reviews all IETF documents being processed >>>> by the IESG for the IETF Chair. Please treat these comments just >>>> like any other last call comments. >>>> >>>> For more information, please see the FAQ at >>>> . >>>> >>>> Document: draft-ietf-tsvwg-ecn-experimentation-05.txt >>>> Reviewer: Brian Carpenter >>>> Review Date: 2017-09-01 >>>> IETF LC End Date: 2017-09-14 >>>> IESG Telechat date: 2017-09-14 >>>> >>>> Summary: Ready with (minor) issues >>>> -------- >>>> >>>> Comment: Very clear from the technical standpoint. >>>> -------- >>>> >>>> Minor Issues: >>>> ------------- >>>> >>>>> 3. ECN Nonce and RFC 3540 >>>> ... >>>>> o Updates RFC 3168 [RFC3168] to remove discussion of the ECN Nonce >>>>> and use of ECT(1) for that Nonce. The specific text updates are >>>>> omitted for brevity. >>>> >>>> I understand the desire for brevity, but this bothers me a bit. What is >>>> the reader to make of RFC3168 Section 20.2, for example? My feeling is >>>> that a short Appendix outlining the specific updates would be useful. >>>> There's already too much spaghetti to untangle. >>>> >>>> I see no reason why RFC3540 and RFC5622 need to be normative >> references >>>> (and therefore downrefs). They aren't required reading in order to >>>> understand this draft. >>>> >>>> -- >>> From nobody Sat Sep 23 11:08:59 2017 Return-Path: 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 EE60F1286C7; Sat, 23 Sep 2017 11:08:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.5 X-Spam-Level: X-Spam-Status: No, score=-5.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dell.com header.b=XjHMrqjJ; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=SDiHYsia 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 QftZxhudgFnN; Sat, 23 Sep 2017 11:08:57 -0700 (PDT) Received: from esa6.dell-outbound.iphmx.com (esa6.dell-outbound.iphmx.com [68.232.149.229]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2411713295C; Sat, 23 Sep 2017 11:08:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1506190137; x=1537726137; h=from:cc:to:subject:date:message-id:references: in-reply-to:mime-version; bh=9oh23G2QUoRTR2QQT1L+Yl+0v03H4buPunqLfMDHeus=; b=XjHMrqjJSV3sRz/DzW+0LvM7y1BdlzsSwdYjt6z/nkmv0D5++ZXEp2w2 8cwpz7NoUIKCVJqf9CQZqnyDXV+I6Ut8DaE1+S6l+hOy48pV/qwOCvnP3 fkUtQ8Z+IyrnGHtbhTTkNPbt6CRC4HwD2Uv5OU+mrZTOnK9bGBFAnCJK9 s=; Received: from esa6.dell-outbound2.iphmx.com ([68.232.154.99]) by esa6.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Sep 2017 13:08:56 -0500 From: "Black, David" Cc: "tsvwg@ietf.org" , "draft-ietf-tsvwg-ieee-802-11@ietf.org" , "Black, David" Received: from mailuogwhop.emc.com ([168.159.213.141]) by esa6.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Sep 2017 00:08:56 +0600 Received: from maildlpprd06.lss.emc.com (maildlpprd06.lss.emc.com [10.253.24.38]) by mailuogwprd03.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v8NI8riH001294 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 23 Sep 2017 14:08:55 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com v8NI8riH001294 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1506190135; bh=cqLL4bjTF2exqxAMCtXy0gjUSQk=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=SDiHYsiavFIfCww5Xi4lgw9r23xpMjRohFY27fC+It5LsWsTV3nJrWKIjjiuaihJk XXtHIopbJJuXgoaY7NdXD8xrg3UAjyrNhtPUXUrOaChXI3o8MvxPrm/J3n71/dpfEy QmLjnVhhrig9HYTHiSdFkS/EY8CjBnyBeV0WnEeA= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com v8NI8riH001294 Received: from mailusrhubprd01.lss.emc.com (mailusrhubprd01.lss.emc.com [10.253.24.19]) by maildlpprd06.lss.emc.com (RSA Interceptor); Sat, 23 Sep 2017 14:08:37 -0400 Received: from MXHUB310.corp.emc.com (MXHUB310.corp.emc.com [10.146.3.36]) by mailusrhubprd01.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v8NI8bEh011460 (version=TLSv1.2 cipher=AES128-SHA256 bits=128 verify=FAIL); Sat, 23 Sep 2017 14:08:37 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB310.corp.emc.com ([10.146.3.36]) with mapi id 14.03.0352.000; Sat, 23 Sep 2017 14:08:37 -0400 To: Spencer Dawkins at IETF , "Tim Szigeti (szigeti)" Thread-Topic: AD Evaluation comments for draft-ietf-tsvwg-ieee-802-11-07 Thread-Index: AQHTLDvXSq+UxrknR0ODuGgkGJv9zaK298IAgAP1DQCAAIaqAIAAc+wAgAE1a4CABbhwkA== Date: Sat, 23 Sep 2017 18:08:36 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.102.147] Content-Type: multipart/alternative; boundary="_000_CE03DB3D7B45C245BCA0D243277949362FC6A341MX307CL04corpem_" MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd01.lss.emc.com X-RSA-Classifications: public Archived-At: Subject: Re: [tsvwg] AD Evaluation comments for draft-ietf-tsvwg-ieee-802-11-07 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Sep 2017 18:08:59 -0000 --_000_CE03DB3D7B45C245BCA0D243277949362FC6A341MX307CL04corpem_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiBSZWFkeSBmb3IgbWUgdG8gcHVsbCB0aGUgdHJpZ2dlcj8NCg0KWWVzLCBwbGVhc2UgZG8sIFRo YW5rcywgLS1EYXZpZA0KDQpGcm9tOiBTcGVuY2VyIERhd2tpbnMgYXQgSUVURiBbbWFpbHRvOnNw ZW5jZXJkYXdraW5zLmlldGZAZ21haWwuY29tXQ0KU2VudDogVHVlc2RheSwgU2VwdGVtYmVyIDE5 LCAyMDE3IDY6NDYgUE0NClRvOiBUaW0gU3ppZ2V0aSAoc3ppZ2V0aSkgPHN6aWdldGlAY2lzY28u Y29tPg0KQ2M6IEJsYWNrLCBEYXZpZCA8ZGF2aWQuYmxhY2tAZW1jLmNvbT47IHRzdndnQGlldGYu b3JnOyBkcmFmdC1pZXRmLXRzdndnLWllZWUtODAyLTExQGlldGYub3JnDQpTdWJqZWN0OiBSZTog QUQgRXZhbHVhdGlvbiBjb21tZW50cyBmb3IgZHJhZnQtaWV0Zi10c3Z3Zy1pZWVlLTgwMi0xMS0w Nw0KDQpEZWFyIERhdmlkIHRoZSBEb2N1bWVudCBTaGVwaGVyZCwNCg0KT24gTW9uLCBTZXAgMTgs IDIwMTcgYXQgMTE6MTggUE0sIFRpbSBTemlnZXRpIChzemlnZXRpKSA8c3ppZ2V0aUBjaXNjby5j b208bWFpbHRvOnN6aWdldGlAY2lzY28uY29tPj4gd3JvdGU6DQpIaSBTcGVuY2VyLA0KDQpJIG1h ZGUgdGhlIG1pbm9yIGNoYW5nZSByZXF1ZXN0ZWQ7IG5vdyB0aGUgc2VudGVuY2UgYXZvaWRzIHRo ZSBsb2FkZWQgdGVybSDigJhzaG91bGQgY29uc2lkZXLigJkuDQoNClN1ZmZpY2UgaXQgdG8gc2F5 IHRoYXQgdGhlIHNlY3VyaXR5IG9mIHRoZSBkZXZpY2VzIGFuZCBuZXR3b3JrcyBpbXBsZW1lbnRp bmcgUW9TLCBpbmNsdWRpbmcgUW9TIG1hcHBpbmcgYmV0d2VlbiB3aXJlZCBhbmQgd2lyZWxlc3Mg bmV0d29ya3MsIG1lcml0cyBjb25zaWRlcmF0aW9uIGluIGFjdHVhbCBkZXBsb3ltZW50cy4NCg0K KFRoYW5rcyBEYXZpZCBmb3IgYnJpbmdpbmcgdGhpcyB0byBvdXIgYXR0ZW50aW9uKS4NCg0KV2l0 aCB0aGF0IGRvbmUsIEkgdGhpbmsgd2XigJlyZSByZWFkeSBmb3IgTGFzdCBDYWxsLg0KDQoNClNw ZW5jZXINCg== --_000_CE03DB3D7B45C245BCA0D243277949362FC6A341MX307CL04corpem_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0 cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k aWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1 cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGEgbmFtZT0iX01haWxFbmRDb21wb3NlIj4mZ3Q7IFJlYWR5IGZvciBtZSB0byBwdWxsIHRoZSB0 cmlnZ2VyPzxvOnA+PC9vOnA+PC9hPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+WWVzLCBwbGVh c2UgZG8sDQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoYW5rcywgLS1E YXZpZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6 MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+IFNwZW5jZXIgRGF3a2lucyBhdCBJRVRGIFttYWlsdG86c3BlbmNlcmRh d2tpbnMuaWV0ZkBnbWFpbC5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgU2VwdGVt YmVyIDE5LCAyMDE3IDY6NDYgUE08YnI+DQo8Yj5Ubzo8L2I+IFRpbSBTemlnZXRpIChzemlnZXRp KSAmbHQ7c3ppZ2V0aUBjaXNjby5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBCbGFjaywgRGF2aWQg Jmx0O2RhdmlkLmJsYWNrQGVtYy5jb20mZ3Q7OyB0c3Z3Z0BpZXRmLm9yZzsgZHJhZnQtaWV0Zi10 c3Z3Zy1pZWVlLTgwMi0xMUBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogQUQgRXZh bHVhdGlvbiBjb21tZW50cyBmb3IgZHJhZnQtaWV0Zi10c3Z3Zy1pZWVlLTgwMi0xMS0wNzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5EZWFyIERh dmlkIHRoZSBEb2N1bWVudCBTaGVwaGVyZCw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5PbiBNb24sIFNlcCAxOCwgMjAxNyBhdCAxMToxOCBQTSwgVGltIFN6aWdldGkgKHN6 aWdldGkpICZsdDs8YSBocmVmPSJtYWlsdG86c3ppZ2V0aUBjaXNjby5jb20iIHRhcmdldD0iX2Js YW5rIj5zemlnZXRpQGNpc2NvLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJs b2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4w cHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmln aHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+SGkgU3BlbmNlciw8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JIG1hZGUgdGhlIG1pbm9yIGNoYW5nZSByZXF1ZXN0ZWQ7 IG5vdyB0aGUgc2VudGVuY2UgYXZvaWRzIHRoZSBsb2FkZWQgdGVybSDigJhzaG91bGQgY29uc2lk ZXLigJkuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvO3RleHQtaW5kZW50OjUuMjVwdCI+DQo8c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+U3VmZmljZSBpdCB0byBzYXkgdGhhdCB0aGUgc2VjdXJpdHkgb2Yg dGhlIGRldmljZXMgYW5kIG5ldHdvcmtzIGltcGxlbWVudGluZyBRb1MsIGluY2x1ZGluZyBRb1Mg bWFwcGluZyBiZXR3ZWVuIHdpcmVkIGFuZCB3aXJlbGVzcyBuZXR3b3JrcywgbWVyaXRzIGNvbnNp ZGVyYXRpb24gaW4gYWN0dWFsIGRlcGxveW1lbnRzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPihUaGFua3MgRGF2aWQgZm9yIGJyaW5naW5nIHRoaXMgdG8g b3VyIGF0dGVudGlvbikuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+V2l0aCB0aGF0IGRvbmUsIEkgdGhpbmsgd2XigJlyZSByZWFkeSBmb3IgTGFzdCBDYWxs Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNwZW5jZXImbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9k eT4NCjwvaHRtbD4NCg== --_000_CE03DB3D7B45C245BCA0D243277949362FC6A341MX307CL04corpem_-- From nobody Sun Sep 24 16:51:13 2017 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 654EF13213D; Sun, 24 Sep 2017 16:51:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Eric Rescorla To: "The IESG" Cc: draft-ietf-tsvwg-ecn-experimentation@ietf.org, Gorry Fairhurst , tsvwg-chairs@ietf.org, gorry@erg.abdn.ac.uk, tsvwg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.62.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150629707140.4996.1867978439109440854.idtracker@ietfa.amsl.com> Date: Sun, 24 Sep 2017 16:51:11 -0700 Archived-At: Subject: [tsvwg] Eric Rescorla's No Objection on draft-ietf-tsvwg-ecn-experimentation-06: (with COMMENT) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Sep 2017 23:51:11 -0000 Eric Rescorla has entered the following ballot position for draft-ietf-tsvwg-ecn-experimentation-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-experimentation/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Having a document which is sort of a verbal patch on another document is pretty hard to read. I recognize that this seems to be customary in some areas, so I'm not marking this as DISCUSS, but I really wish you would do a bis instead. INLINE COMMENTS Line 98 This memo updates RFC 3168 [RFC3168] which specifies Explicit Congestion Notification (ECN) as a replacement for packet drops as indicators of network congestion. It relaxes restrictions in RFC Replacement or additional indicator? Line 164 that for congestion indicated by ECN, a different sender congestion response (e.g., reduce the response so that the sender backs off by a smaller amount) may be appropriate by comparison to nit: reducing Line 170 couples the backoff change to Congestion Marking Differences changes (next bullet). This is at variance with RFC 3168's requirement that a sender's congestion control response to ECN I'm having a lot of trouble reading this sentence. It seems like you are comparing the ECN response to a lost response, but these other two drafts also are about a less aggressive response. Perhaps this would be clearer as: "indicated by loss. Two examples of such a reduced response are..." From nobody Sun Sep 24 17:10:10 2017 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BB36132992; Sun, 24 Sep 2017 17:10:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Brian Carpenter To: Cc: draft-ietf-tsvwg-ecn-experimentation.all@ietf.org, tsvwg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.62.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150629820260.5004.13229146476923387593@ietfa.amsl.com> Date: Sun, 24 Sep 2017 17:10:02 -0700 Archived-At: Subject: [tsvwg] Genart telechat review of draft-ietf-tsvwg-ecn-experimentation-06 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 00:10:03 -0000 Reviewer: Brian Carpenter Review result: Ready Gen-ART telechat review of draft-ietf-tsvwg-ecn-experimentation-06 I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at . Document: draft-ietf-tsvwg-ecn-experimentation-06.txt Reviewer: Brian Carpenter Review Date: 2017-09-25 IETF LC End Date: 2017-09-19 IESG Telechat date: 2017-09-28 Summary: Ready -------- Comment: -------- Thanks for handling my Last Call comments. From nobody Mon Sep 25 06:08:35 2017 Return-Path: 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 09F6E1342F8; Mon, 25 Sep 2017 06:08:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 ozRBn8HEfeqC; Mon, 25 Sep 2017 06:08:27 -0700 (PDT) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (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 4D48D134224; Mon, 25 Sep 2017 06:08:27 -0700 (PDT) Received: by mail-yw0-x22e.google.com with SMTP id w9so4644899ywi.11; Mon, 25 Sep 2017 06:08:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=zgjh+yIJwD5kwzKtSUJEE9RCKoTBSLYPxwmbudvfZJg=; b=BYymzIun97Ah0laKY7MGG8Y3Nc2BuJgQy3kekTqpNsnYudq3jjQaRqT4v2XTLW854m zS/BXjtsDZ5Y+dsjdfkgHUP8EbuNqTTOOAvAjQ+fB+u/76XKTcyxSp8kr8gsTMesya6f QKZScC0jE1F5EvM0C9Znpwh+Ikr7FWdY7UsxbCsN8lmTfvBUzeBpA5+gGM2Eg2fGlEMl mAeLm/qBYsCiRP5SVRhSDk142JD9lHM8ZpQxX3Fi8LT3RaZs/KNtzKvNCF5KuHepgHhY coZRQJiKojyFovRaC/OWBiWtE9U0HISYwx07YIvVE9uNmB48cG1BhWNsakVYGpYx8Xww sCTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=zgjh+yIJwD5kwzKtSUJEE9RCKoTBSLYPxwmbudvfZJg=; b=Hqoccc/Yi06WKJmN4aomSscHjCERSytvWJCBragiCcfxAfYOZ+FJFj06VUo+hoRP8N TI2bqeJtsYZCK9b1BqZ80B2MSXaC7eo8mZJAWaULqnRxd2OQnNqD4C4s9YCIdlLHnw5K ppu0hCxct8F43+QmBhHUmxMnMl67bXlNdDrA6LVoTJzF64OgGz783U5VjjeB4Xyy8+Kb rI0bU1KR2kWdaGLtvT05Ar/KLIR2ucisQZgb5Rpb+3r0Bms0It7hKzp5Qd90SoeL7bxI /4uGJ8SqqckqKK5aLHorU5enXETtF5bbxft+0jG6wJ4Ki6CR7GA8S+Fuc6bsPlLYn9/0 SC7g== X-Gm-Message-State: AHPjjUjQ58oFOQ59Qbw7iVu03fHI55K3SagCtQ2PxLxBcbPHE/+QqrT8 RdSOqoedqAI9B0PWUMsmvF3G8UfTGZzuZJ7sd3SHbLyK X-Google-Smtp-Source: AOwi7QCKEpSmCPMPjzRDLMUCOqhZ5X7PWlQ0UbyvEOnzr4yaWrnnSaOylIDTOX0xeAj7ZAYN1WgmuwAhjZmquUuVkHQ= X-Received: by 10.37.20.136 with SMTP id 130mr4842116ybu.134.1506344906086; Mon, 25 Sep 2017 06:08:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.2.71 with HTTP; Mon, 25 Sep 2017 06:08:25 -0700 (PDT) In-Reply-To: <150629707140.4996.1867978439109440854.idtracker@ietfa.amsl.com> References: <150629707140.4996.1867978439109440854.idtracker@ietfa.amsl.com> From: Spencer Dawkins at IETF Date: Mon, 25 Sep 2017 21:08:25 +0800 Message-ID: To: Eric Rescorla Cc: The IESG , "gorry@erg.abdn.ac.uk" , draft-ietf-tsvwg-ecn-experimentation@ietf.org, "tsvwg-chairs@ietf.org" , "tsvwg@ietf.org" Content-Type: multipart/alternative; boundary="001a113e8252095bfe055a0341db" Archived-At: Subject: Re: [tsvwg] Eric Rescorla's No Objection on draft-ietf-tsvwg-ecn-experimentation-06: (with COMMENT) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 13:08:29 -0000 --001a113e8252095bfe055a0341db Content-Type: text/plain; charset="UTF-8" Hi, Eric, On Mon, Sep 25, 2017 at 7:51 AM, Eric Rescorla wrote: > Eric Rescorla has entered the following ballot position for > draft-ietf-tsvwg-ecn-experimentation-06: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-experimentation/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Having a document which is sort of a verbal patch on another document is > pretty > hard to read. I recognize that this seems to be customary in some areas, > so I'm > not marking this as DISCUSS, but I really wish you would do a bis instead. > I'll let the author and shepherd field the INLINE COMMENTS, but I should respond to your high-order bit as the AD. For this draft, the key point is telling implementers "don't even think about touching ECT(1) unless you're participating in an experiment on ECT(1)". After discussion about Brian Carpenter's Gen-ART review, which included the point you raised about clarity, I think we agreed that the key point was clear enough (and Brian thanked us for making changes based on his Last Call review, so we are sensitive to this concern). We have at least two experiments queued up now (L4S and TCP with Alternative Backoff), and we may have more. The transport community has been waiting for years to be able to use one of the ECT codepoints for experiments, and I'd prefer not to hold them up for an ECN -bis now. But I agree that this is spaghetti, because it is a patch on another document, and I would support an ECN -bis at some point. (It's possible that we'll do enough thinking about ECN when we're adding ECN support in QUIC that an ECN -bis will look like a really good idea at that point) And thanks for raising this topic. Spencer > INLINE COMMENTS > Line 98 > This memo updates RFC 3168 [RFC3168] which specifies Explicit > Congestion Notification (ECN) as a replacement for packet drops as > indicators of network congestion. It relaxes restrictions in RFC > Replacement or additional indicator? > > Line 164 > that for congestion indicated by ECN, a different sender > congestion response (e.g., reduce the response so that the sender > backs off by a smaller amount) may be appropriate by comparison to > nit: reducing > > Line 170 > couples the backoff change to Congestion Marking Differences > changes (next bullet). This is at variance with RFC 3168's > requirement that a sender's congestion control response to ECN > I'm having a lot of trouble reading this sentence. It seems like you are > comparing the ECN response to a lost response, but these other two drafts > also > are about a less aggressive response. Perhaps this would be clearer as: > > "indicated by loss. Two examples of such a reduced response are..." > > > --001a113e8252095bfe055a0341db Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Eric,

On Mon, Sep 25, 2017 at 7:51 AM, Eric Rescorla &= lt;ekr@rtfm.com> wrote:
Eric Resc= orla has entered the following ballot position for
draft-ietf-tsvwg-ecn-experimentation-06: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/<= wbr>statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/<= wbr>doc/draft-ietf-tsvwg-ecn-experimentation/



-----------------------------------------------------------------= -----
COMMENT:
-----------------------------------------------------------------= -----

Having a document which is sort of a verbal patch on another document is pr= etty
hard to read. I recognize that this seems to be customary in some areas, so= I'm
not marking this as DISCUSS, but I really wish you would do a bis instead.<= br>

I'll let the author and shepherd fi= eld the INLINE COMMENTS, but I should respond to your high-order bit as the= AD.

For this draft, the key point is telling impl= ementers "don't even think about touching ECT(1) unless you're= participating in an experiment on ECT(1)".

A= fter discussion about Brian Carpenter's Gen-ART review, which included = the point you raised about clarity, I think we agreed that the key point wa= s clear enough (and Brian thanked us for making changes based on his Last C= all review, so we are sensitive to this concern).

= We have at least two experiments queued up now (L4S and TCP with Alternativ= e Backoff), and we may have more. The transport community has been waiting = for years to be able to use one of the ECT codepoints for experiments, and = I'd prefer not to hold them up for an ECN -bis now.

But I agree that this is spaghetti, because it is a patch on another = document, and I would support an ECN -bis at some point.

(It's possible that we'll do enough thinking about ECN when = we're adding ECN support in QUIC that an ECN -bis will look like a real= ly good idea at that point)

And thanks for raising= this topic.

Spencer
=C2=A0
INLINE COMMENTS
Line 98
=C2=A0 =C2=A0This memo updates RFC 3168 [RFC3168] which specifies Explicit<= br> =C2=A0 =C2=A0Congestion Notification (ECN) as a replacement for packet drop= s as
=C2=A0 =C2=A0indicators of network congestion.=C2=A0 It relaxes restriction= s in RFC
Replacement or additional indicator?

Line 164
=C2=A0 =C2=A0 =C2=A0 that for congestion indicated by ECN, a different send= er
=C2=A0 =C2=A0 =C2=A0 congestion response (e.g., reduce the response so that= the sender
=C2=A0 =C2=A0 =C2=A0 backs off by a smaller amount) may be appropriate by c= omparison to
nit: reducing

Line 170
=C2=A0 =C2=A0 =C2=A0 couples the backoff change to Congestion Marking Diffe= rences
=C2=A0 =C2=A0 =C2=A0 changes (next bullet).=C2=A0 This is at variance with = RFC 3168's
=C2=A0 =C2=A0 =C2=A0 requirement that a sender's congestion control res= ponse to ECN
I'm having a lot of trouble reading this sentence. It seems like you ar= e
comparing the ECN response to a lost response, but these other two drafts a= lso
are about a less aggressive response. Perhaps this would be clearer as:

"indicated by loss. Two examples of such a reduced response are...&quo= t;



--001a113e8252095bfe055a0341db-- From nobody Mon Sep 25 09:29:57 2017 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B34AD1344C0; Mon, 25 Sep 2017 09:29:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.62.1 Auto-Submitted: auto-generated Precedence: bulk CC: "David L. Black" , tsvwg@ietf.org, david.black@emc.com, draft-ietf-tsvwg-ieee-802-11@ietf.org, spencerdawkins.ietf@gmail.com, tsvwg-chairs@ietf.org Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <150635697972.27499.3655096650868677152.idtracker@ietfa.amsl.com> Date: Mon, 25 Sep 2017 09:29:39 -0700 Archived-At: Subject: [tsvwg] Last Call: (Diffserv to IEEE 802.11 Mapping) to Proposed Standard X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 16:29:40 -0000 The IESG has received a request from the Transport Area Working Group WG (tsvwg) to consider the following document: - 'Diffserv to IEEE 802.11 Mapping' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2017-10-09. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract As internet traffic is increasingly sourced-from and destined-to wireless endpoints, it is crucial that Quality of Service be aligned between wired and wireless networks; however, this is not always the case by default. This document specifies a set of Differentiated Services Code Point (DSCP) to IEEE 802.11 User Priority (UP) mappings to reconcile the marking recommendations offered by the IETF and the IEEE so as to maintain consistent QoS treatment between wired and IEEE 802.11 wireless networks. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ieee-802-11/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ieee-802-11/ballot/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: rfc4594: Configuration Guidelines for DiffServ Service Classes (Informational - IETF stream) rfc3662: A Lower Effort Per-Domain Behavior (PDB) for Differentiated Services (Informational - Independent Submission Editor stream) From nobody Tue Sep 26 12:21:24 2017 Return-Path: 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 9263C134325 for ; Tue, 26 Sep 2017 12:21:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=ietf@kuehlewind.net header.d=kuehlewind.net 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 MrYlyGtAbWuI for ; Tue, 26 Sep 2017 12:21:21 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C96B513432D for ; Tue, 26 Sep 2017 12:21:20 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net; b=VA50pdRmdDaDJtFKQOt+YQv9vRBsEWbJTmcwkigMcQxLpTjQT2yPEIPJuFsYnY1QCPZC9qsmR/7Mx6eB2D1FIsGViUTOHqB7INkJKAhJ2RnQQF0n2radg1utNsbCk8X34xXROZ2bZNFQ3aWC0V+irHr6qkwS3cZrw1i8QLSqzp8=; h=Received:Received:Subject:To:Cc:References:From:Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Language:Content-Transfer-Encoding:X-PPP-Message-ID:X-PPP-Vhost; Received: (qmail 11498 invoked from network); 26 Sep 2017 21:14:37 +0200 Received: from nb-10510.ethz.ch (HELO ?82.130.103.143?) (82.130.103.143) by kuehlewind.net with ESMTPSA (DHE-RSA-AES128-SHA encrypted, authenticated); 26 Sep 2017 21:14:36 +0200 To: Spencer Dawkins at IETF , Eric Rescorla Cc: "gorry@erg.abdn.ac.uk" , "tsvwg@ietf.org" , draft-ietf-tsvwg-ecn-experimentation@ietf.org, The IESG , "tsvwg-chairs@ietf.org" References: <150629707140.4996.1867978439109440854.idtracker@ietfa.amsl.com> From: =?UTF-8?Q?Mirja_K=c3=bchlewind?= Message-ID: <9d171d18-2317-2683-6cb4-a0df6e1f27ce@kuehlewind.net> Date: Tue, 26 Sep 2017 21:14:36 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-PPP-Message-ID: <20170926191436.11488.37789@lvps83-169-45-111.dedicated.hosteurope.de> X-PPP-Vhost: kuehlewind.net Archived-At: Subject: Re: [tsvwg] Eric Rescorla's No Objection on draft-ietf-tsvwg-ecn-experimentation-06: (with COMMENT) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Sep 2017 19:21:23 -0000 Hi Ekr, what Spencer was saying between the lines was that a bis would need to include much more changes and would take much longer because here is basically a whole list that would need to be fixed. We discussed that in the group but would like to get out these changes needed for the experiments quickly and eventually make a real bis at a later point of time. Mirja On 25.09.2017 15:08, Spencer Dawkins at IETF wrote: > Hi, Eric, > > On Mon, Sep 25, 2017 at 7:51 AM, Eric Rescorla > wrote: > > Eric Rescorla has entered the following ballot position for > draft-ietf-tsvwg-ecn-experimentation-06: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-experimentation/ > > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Having a document which is sort of a verbal patch on another document is > pretty > hard to read. I recognize that this seems to be customary in some areas, > so I'm > not marking this as DISCUSS, but I really wish you would do a bis instead. > > > I'll let the author and shepherd field the INLINE COMMENTS, but I should > respond to your high-order bit as the AD. > > For this draft, the key point is telling implementers "don't even think about > touching ECT(1) unless you're participating in an experiment on ECT(1)". > > After discussion about Brian Carpenter's Gen-ART review, which included the > point you raised about clarity, I think we agreed that the key point was > clear enough (and Brian thanked us for making changes based on his Last Call > review, so we are sensitive to this concern). > > We have at least two experiments queued up now (L4S and TCP with Alternative > Backoff), and we may have more. The transport community has been waiting for > years to be able to use one of the ECT codepoints for experiments, and I'd > prefer not to hold them up for an ECN -bis now. > > But I agree that this is spaghetti, because it is a patch on another > document, and I would support an ECN -bis at some point. > > (It's possible that we'll do enough thinking about ECN when we're adding ECN > support in QUIC that an ECN -bis will look like a really good idea at that point) > > And thanks for raising this topic. > > Spencer > > INLINE COMMENTS > Line 98 >    This memo updates RFC 3168 [RFC3168] which specifies Explicit >    Congestion Notification (ECN) as a replacement for packet drops as >    indicators of network congestion.  It relaxes restrictions in RFC > Replacement or additional indicator? > > Line 164 >       that for congestion indicated by ECN, a different sender >       congestion response (e.g., reduce the response so that the sender >       backs off by a smaller amount) may be appropriate by comparison to > nit: reducing > > Line 170 >       couples the backoff change to Congestion Marking Differences >       changes (next bullet).  This is at variance with RFC 3168's >       requirement that a sender's congestion control response to ECN > I'm having a lot of trouble reading this sentence. It seems like you are > comparing the ECN response to a lost response, but these other two drafts > also > are about a less aggressive response. Perhaps this would be clearer as: > > "indicated by loss. Two examples of such a reduced response are..." > > > From nobody Tue Sep 26 12:41:54 2017 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2615913339A; Tue, 26 Sep 2017 12:41:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind?= To: "The IESG" Cc: draft-ietf-tsvwg-ecn-experimentation@ietf.org, Gorry Fairhurst , tsvwg-chairs@ietf.org, gorry@erg.abdn.ac.uk, tsvwg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.62.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150645491115.20804.4979473918843941790.idtracker@ietfa.amsl.com> Date: Tue, 26 Sep 2017 12:41:51 -0700 Archived-At: Subject: [tsvwg] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-?= =?utf-8?q?ietf-tsvwg-ecn-experimentation-06=3A_=28with_COMMENT=29?= X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Sep 2017 19:41:51 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-tsvwg-ecn-experimentation-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-experimentation/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 1) section 2 actually seems a bit redundant to me but I guess that not a problem. I guess I would also be okay with the doc if section 2 would not be there, but maybe this overview actually helps others who are less familiar with ECN. 2) I guess it could actually be helpful to include a tiny bit of reasoning why the ECN Nonce experiment is concluded instead of just saying that it was never deployed and further point to an appendix of a draft (which is actually appendix C and not B.1 I believe). I know this was discussed, but having one sentence saying something in the lines like this is probably not to hard: "The experiment is concludes with the result that ECN Nonce does not provide a reliable integrity protection as the other end can always pretend to not support this optional feature." 3) This sentence is a bit unclear: "In addition, until the conclusion of the L4S experiment, use of ECT(1) in IETF RFCs is not appropriate, as the IETF may decide to allocate ECT(1) exclusively for L4S usage if the L4S experiment is successful." I guess the L4S exp RFC would use ECT(1), so the sentence to not really make sense to me. Also given that there is no RFC for L4S yet, we actually don't know if there is finally community/group consensus to publish that RFC. I guess it actually to early to say something like this. I know why you want to have this sentence in there, but from the processing point of view that does not seems to be the correct thing to do and it might be better to just remove it. Otherwise, if you want to keep it or something similar but maybe less specific, following up on the feedback provided by IANA, the TCP flag should probably be just marked as reserved with reference to this RFC. 4) I'm not certain about this part: "An exception to this requirement occurs in responding to an ongoing attack. For example, as part of the response, it may be appropriate to drop more ECT-marked TCP SYN packets than TCP SYN packets marked with not-ECT. " Maybe it's to late here and that's the reason I don't get it, but what would be the reason to rather drop ETC marked SYNs? Can you explain? I do understand that there is no reason to not drop ECT-marked SYNs in an attack situation (meaning don't try to mark, drop immediately) but I don't understand why you should drop ECT-marked SYNs preferentially? If the assumption is that attacker would more likely use ECN than non-attackers because the will usually not be dropped but marked, I'm uncertain if that is true and still not sure if the above recommendation is appropriate. In any case I think this needs at least more explanation in the document. 5) As a side note on this sentence: "Random ECT values MUST NOT be used, as that may expose RTP to differences in network treatment of traffic marked with ECT(1) and ECT(0) and differences in associated endpoint congestion responses, e.g., as proposed in [I-D.ietf-tsvwg-ecn-l4s-id]." I think random marking is anyway not a good idea because this is sometimes used (incorrectly) as input for ECMP. Therefore I actually think the reference to the l4s draft is actually not needed here. From nobody Tue Sep 26 20:55:21 2017 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0273F13219E; Tue, 26 Sep 2017 20:55:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Adam Roach To: "The IESG" Cc: draft-ietf-tsvwg-ecn-experimentation@ietf.org, Gorry Fairhurst , tsvwg-chairs@ietf.org, gorry@erg.abdn.ac.uk, tsvwg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.62.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150648451400.24991.2310533028306743183.idtracker@ietfa.amsl.com> Date: Tue, 26 Sep 2017 20:55:14 -0700 Archived-At: Subject: [tsvwg] Adam Roach's No Objection on draft-ietf-tsvwg-ecn-experimentation-06: (with COMMENT) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Sep 2017 03:55:14 -0000 Adam Roach has entered the following ballot position for draft-ietf-tsvwg-ecn-experimentation-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-experimentation/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 3 ends with the following text: Additional minor changes remove other mentions of the ECN nonce and implications that ECT(1) is intended for use by the ECN nonce; the specific text updates are omitted for brevity. I'm not sure I follow what's meant here. Is this basically saying "there are other, less substantive edits required to RFC 3168, but those changes are left as an exercise for the reader"? From nobody Tue Sep 26 21:10:42 2017 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 22A4F133074; Tue, 26 Sep 2017 21:10:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Adam Roach To: "The IESG" Cc: draft-ietf-tsvwg-ecn-experimentation@ietf.org, Gorry Fairhurst , tsvwg-chairs@ietf.org, gorry@erg.abdn.ac.uk, tsvwg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.62.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150648543513.25072.17250980051282018281.idtracker@ietfa.amsl.com> Date: Tue, 26 Sep 2017 21:10:35 -0700 Archived-At: Subject: [tsvwg] Adam Roach's No Objection on draft-ietf-tsvwg-ecn-experimentation-06: (with COMMENT) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Sep 2017 04:10:35 -0000 Adam Roach has entered the following ballot position for draft-ietf-tsvwg-ecn-experimentation-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-experimentation/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 3 ends with the following text: Additional minor changes remove other mentions of the ECN nonce and implications that ECT(1) is intended for use by the ECN nonce; the specific text updates are omitted for brevity. I'm not sure I follow what's meant here. Is this basically saying "there are other, less substantive edits required to RFC 3168, but those changes are left as an exercise for the reader"? [Sorry for the additional noise, but I noticed one more issue that you'll want to correct] Section 9 says "See Appendix B.1 of [I-D.ietf-tsvwg-ecn-l4s-id] for discussion of alternatives to the ECN nonce." I beleive that this should refer to Appendix C.1 rather than Appendix B.1. From nobody Wed Sep 27 00:13:49 2017 Return-Path: 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 69CEF1321B6; Wed, 27 Sep 2017 00:13:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.751 X-Spam-Level: X-Spam-Status: No, score=-2.751 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BRBL_LASTEXT=1.449, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no 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 dXT2QQw_zkNL; Wed, 27 Sep 2017 00:13:43 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 743291320B5; Wed, 27 Sep 2017 00:13:43 -0700 (PDT) Received: from [10.5.95.81] (unknown [85.255.236.29]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id BCF641B00153; Wed, 27 Sep 2017 08:13:41 +0100 (BST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: "Gorry (erg)" X-Mailer: iPhone Mail (14G60) In-Reply-To: <150645491115.20804.4979473918843941790.idtracker@ietfa.amsl.com> Date: Wed, 27 Sep 2017 08:13:40 +0100 Cc: The IESG , draft-ietf-tsvwg-ecn-experimentation@ietf.org, tsvwg-chairs@ietf.org, tsvwg@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <150645491115.20804.4979473918843941790.idtracker@ietfa.amsl.com> To: =?utf-8?Q?Mirja_K=C3=BChlewind?= Archived-At: Subject: Re: [tsvwg] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft?= =?utf-8?q?-ietf-tsvwg-ecn-experimentation-06=3A_=28with_COMMENT=29?= X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Sep 2017 07:13:48 -0000 Mirja, thanks for the review. I was document shepherd and have some observat= ions. > On 26 Sep 2017, at 20:41, Mirja K=C3=BChlewind wrote= : >=20 > Mirja K=C3=BChlewind has entered the following ballot position for > draft-ietf-tsvwg-ecn-experimentation-06: No Objection >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) >=20 >=20 > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-experimentation/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > 1) section 2 actually seems a bit redundant to me but I guess that not a > problem. I guess I would also be okay with the doc if section 2 would not b= e > there, but maybe this overview actually helps others who are less familiar= with > ECN. >=20 > 2) I guess it could actually be helpful to include a tiny bit of reasoning= why > the ECN Nonce experiment is concluded instead of just saying that it was n= ever > deployed and further point to an appendix of a draft (which is actually > appendix C and not B.1 I believe). I know this was discussed, but having o= ne > sentence saying something in the lines like this is probably not to hard: "= The > experiment is concludes with the result that ECN Nonce does not provide a > reliable integrity protection as the other end can always pretend to not > support this optional feature." That argument was presented along with others - although I suggest this is n= ot really a new argument.=20 There is value in a protection mechanism in a transport protocol, and had th= e nonce mechanism been deployed, senders could require this when using ECN -= or could alternatively have opted for some other fallback method, knowing t= he receiver would not honour the nonce. I do not think this extra sentence i= s correct, nor important - the unusuability was a consequence of non deploym= ent. > 3) This sentence is a bit unclear: > "In addition, until the conclusion of the L4S experiment, use of > ECT(1) in IETF RFCs is not appropriate, as the IETF may decide to > allocate ECT(1) exclusively for L4S usage if the L4S experiment is > successful." > I guess the L4S exp RFC would use ECT(1), so the sentence to not really ma= ke > sense to me. I see this issue. The bashed text does seem too contorted! I suggest we say something simpler like ECT(1) is reserved for use by TSVWG= . (This will be used by L4S, until this experiment is concluded or this allo= cation is made permanent).=20 > Also given that there is no RFC for L4S yet, we actually don't > know if there is finally community/group consensus to publish that RFC. I g= uess > it actually to early to say something like this. I know why you want to ha= ve > this sentence in there, but from the processing point of view that does no= t > seems to be the correct thing to do and it might be better to just remove i= t. > Otherwise, if you want to keep it or something similar but maybe less > specific, following up on the feedback provided by IANA, the TCP flag shou= ld > probably be just marked as reserved with reference to this RFC. >=20 I think reserving ECT(1) for this RFC could make sense. > 4) I'm not certain about this part: > "An exception to this requirement occurs in > responding to an ongoing attack. For example, as part of the > response, it may be appropriate to drop more ECT-marked TCP SYN > packets than TCP SYN packets marked with not-ECT. " > Maybe it's to late here and that's the reason I don't get it, but what wou= ld be > the reason to rather drop ETC marked SYNs? Can you explain? I do understan= d > that there is no reason to not drop ECT-marked SYNs in an attack situation= > (meaning don't try to mark, drop immediately) but I don't understand why y= ou > should drop ECT-marked SYNs preferentially? If the assumption is that atta= cker > would more likely use ECN than non-attackers because the will usually not b= e > dropped but marked, I'm uncertain if that is true and still not sure if th= e > above recommendation is appropriate. In any case I think this needs at lea= st > more explanation in the document. >=20 I suggest SYN attacks need to be considered - and I would like to see that n= oted here - however, stating what reaction is needed in this case, should be= the subject of the TCPM ID. > 5) As a side note on this sentence: > "Random ECT values MUST NOT be used, as that may expose RTP to > differences in network treatment of traffic marked with ECT(1) and > ECT(0) and differences in associated endpoint congestion > responses, e.g., as proposed in [I-D.ietf-tsvwg-ecn-l4s-id]." > I think random marking is anyway not a good idea because this is sometimes= used > (incorrectly) as input for ECMP. Therefore I actually think the reference t= o > the l4s draft is actually not needed here. >=20 Gorry= From nobody Wed Sep 27 17:54:32 2017 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DD3F1344C5; Wed, 27 Sep 2017 17:54:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ben Campbell To: "The IESG" Cc: draft-ietf-tsvwg-ecn-experimentation@ietf.org, Gorry Fairhurst , tsvwg-chairs@ietf.org, gorry@erg.abdn.ac.uk, tsvwg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.62.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150656006611.13804.15109883563794101461.idtracker@ietfa.amsl.com> Date: Wed, 27 Sep 2017 17:54:26 -0700 Archived-At: Subject: [tsvwg] Ben Campbell's No Objection on draft-ietf-tsvwg-ecn-experimentation-06: (with COMMENT) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Sep 2017 00:54:26 -0000 Ben Campbell has entered the following ballot position for draft-ietf-tsvwg-ecn-experimentation-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-experimentation/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Substantive: General: I agree with Ekr's comment specifying RFC updates as text"patches" is confusing and unfriendly to the reader. While I don't necessarily agree that we should do bis drafts instead, I hope people will remember that we never actually render an "updated" RFC with the patches applied. I think this sort of thing would be easier to understand if we just spoke of the changes at a conceptual level and avoid getting wrapped around changing specific words to other specific words. I don't expect that to change with this particular draft, but I think the IESG should consider some guidance here. (And I fully recognize that a lot of update drafts in ART do the same thing.) -1, first paragraph: "An Experimental RFC MUST be published for any protocol or mechanism that takes advantage of any of these enabling updates." This seems like an odd use of 2119 language, at least for something other than a BCP. Furthermore, I don't think this paragraph is the real authority on the matter, since there is much more precise text scattered through the draft about this particular requirement. Therefore, I suggest removing the 2119 language and stating this descriptively. (e.g. "Mechanisms that take advantage of these updates are to be specified in experimental RFCs.") Speaking of which, there are several references to requiring experimental RFCs. Are those expected to be IETF stream RFCs? -5, first "patch": Are there existing implementations that would become noncompliant with the new text? -9, 1st paragraph: "As a process memo that only removes limitations on proposed experiments, there are no protocol security considerations." I am skeptical that removing limitations from experiments can be assumed to be security neutral on its face. Please consider documenting the thought process that led to that conclusion. Editorial: -1, 2nd paragraph: " There is no need to make changes for protocols ... I'm a bit confused--those hypothetical standards track RFCs will need to make the sort of changes that this paragraph says are not needed. Is the point that _this_ document does not need to make those changes? -2, Congestion Response Difference: "As discussed further in Section 4.1, an ECN congestion indication communicates a higher likelihood that a shorter queue exists at the network bottleneck node by comparison to a packet drop that indicates congestion [I-D.ietf-tcpm-alternativebackoff-ecn]." I'm not sure what is being compared here. Is it a high chance of shorter queue, or higher chance of a short queue? -- (same paragraph): "(next bullet)" There are no bullets. -2, Congestion Marking Difference: The first sentence is hard to parse. Please consider breaking it into simpler sentences. -3, first paragraph: "As specified in RFC 3168, ... [stuff]... , as specified in experimental RFC 3540 [RFC3540]. This is hard to parse. In particular, I have trouble deciphering which part is supposed to be specified in 3168 vs 3540. -- 2nd paragraph: "but might equally have been due to re- marking of the ECN field by an erroneous middlebox or router." I think "erroneous" modified "re-marking" rather than "middlebox or router". -4.2, 1st paragraph: "... prevent the aggressive low latency traffic starving conventional traffic ... " Is there a missing "from" between "traffic" and "starving" Or maybe an "of" after "starving"? From nobody Wed Sep 27 21:46:15 2017 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C8021344E5; Wed, 27 Sep 2017 21:46:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Susan Hares To: Cc: ietf@ietf.org, draft-ietf-tsvwg-ecn-experimentation.all@ietf.org, tsvwg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.62.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150657397335.13683.13507499187577499408@ietfa.amsl.com> Date: Wed, 27 Sep 2017 21:46:13 -0700 Archived-At: Subject: [tsvwg] Opsdir telechat review of draft-ietf-tsvwg-ecn-experimentation-06 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Sep 2017 04:46:13 -0000 Reviewer: Susan Hares Review result: Has Issues This is an OPS-DIR Review which focus the work on issues in deployed technology based on this RFC. Summary: Has issues as guide to experimental RFC . To me these operational issues General comment: Thank you david for addressing this Area. Better ECN control is critical to many portions of the network. My comments on this draft are because I really hope you can do quality experiments. How this might be resolved: if there is a operational guidelines section (or separate document), that covered: a) how to set-up and determine if a ECT(1) experiment success or fails b) how to manage your ECT(1) experiment in your network. c) how to manage and detect if your ECT experiment is running into problems with other IETF technology (TRILL, MPLS VPNs, IPVPNs, BIER and NV03 technology). d) Recommending a monitoring structure (e.g. yang modules, netconf/restconf and monitoring tools0 Major issues: #1 There is nothing in this document which provide guidelines to the authors of experimental RFCs based in this draft on specific ways to monitor the ECN experiments, report the ECN experimental data, or disable the experimental data. If the success or failure of an experiment is based on "popular vote" determined by deployment, then say state this point. I personally would object to that because you cannot tell if a limited experiment in a specific location (E.g. a data center) might be successful in another location. If the success or failure of an experimental RFC is based on a specific set of criteria for ECN, then it would be good to give an operational suggestion on how to: a) design an experiment, b) run an experiment and collect data, and c) report ths data in order to standardize the ECN experiments using ECT(1). page 10 section 4.2 last 2 paragraphs in sentence, hinted that you have an experiment in mind without specifying the experiment's success or failure criteria other than popular vote. Is this true? if it is, this is problematic. If I misunderstood your text, then please have someone re-read the text. I have read lots of papers on ECN. 2) No discussion was given on how the TCP layer experimentation would impact routing layer handdlng of ECN. For example, the trill WG has the draft draft-ietf-trill-ecn-support. Automated tunnel set-up for MPLS VPNS or IP VPNS may look at the ECN ECT(0) or ECT(1). TRILL's ECN supports the layer-2 within the data centers. Some IP VPNS or MPLS VPNS may be needed for the data-center to business site or data-center backup traffic. As written, this draft allows loosening of the RFC3168 draft but does not provide guidelines for network interaction. 3) Some networks also use the diff-service markings to guide traffic in the network. This document does not suggest an operational check list on how to design an experiment that supports or does not support these markings. 4) Modern operational IETF protocols and data modules for automating the tracking of these experiments should be suggests Editorial: Some reviews have hinted that the text is repeats several sets of language. People have found this lacked clarity. One wonders why the authors did not simply provide a set of bis documents for RFC3168, RFC6679, RFC 4341, RFC4342, and RFC5622 if it is just updating the language in the specifications. This document tries to be both revision of the specifications and the architectural guidelines for experiments. The dual nature does not lead to clarity on either subject. I did not do editorial nits due to the higher level issues. From nobody Thu Sep 28 01:24:08 2017 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3979E1355A2; Thu, 28 Sep 2017 01:24:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benoit Claise To: "The IESG" Cc: draft-ietf-tsvwg-ecn-experimentation@ietf.org, Gorry Fairhurst , tsvwg-chairs@ietf.org, gorry@erg.abdn.ac.uk, tsvwg@ietf.org, shares@ndzh.com X-Test-IDTracker: no X-IETF-IDTracker: 6.62.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150658704722.13642.16407521705140305125.idtracker@ietfa.amsl.com> Date: Thu, 28 Sep 2017 01:24:07 -0700 Archived-At: Subject: [tsvwg] Benoit Claise's Discuss on draft-ietf-tsvwg-ecn-experimentation-06: (with DISCUSS and COMMENT) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Sep 2017 08:24:07 -0000 Benoit Claise has entered the following ballot position for draft-ietf-tsvwg-ecn-experimentation-06: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-experimentation/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Below is Sue Hares' OPS DIR review. I would like to DISCUSS some points. I'm of two minds. On one side, I read: The scope of this memo is limited to these three areas of experimentation. This memo expresses no view on the likely outcomes of the proposed experiments and does not specify the experiments in detail. Additional experiments in these areas are possible, e.g., on use of ECN to support deployment of a protocol similar to DCTCP [I-D.ietf-tcpm-dctcp] beyond DCTCP's current applicability that is limited to data center environments. The purpose of this memo is to remove constraints in standards track RFCs that stand in the way of these areas of experimentation. On the other side: An Experimental RFC MUST be published for any protocol or mechanism that takes advantage of any of these enabling updates. Btw, the MUST is just plain wrong, as Ben mentioned. So, if you go in the direction of providing requirements for the experiments (as opposed to just removing the specification constraints), then I agree with Sue. The document title goes in the direction: if it would say something such as "Removing constraints to the ECN experimentation", that would be a different story. Reviewer: Susan Hares Review result: Has Issues This is an OPS-DIR Review which focus the work on issues in deployed technology based on this RFC. Summary: Has issues as guide to experimental RFC . To me these operational issues General comment: Thank you david for addressing this Area. Better ECN control is critical to many portions of the network. My comments on this draft are because I really hope you can do quality experiments. How this might be resolved: if there is a operational guidelines section (or separate document), that covered: a) how to set-up and determine if a ECT(1) experiment success or fails b) how to manage your ECT(1) experiment in your network. c) how to manage and detect if your ECT experiment is running into problems with other IETF technology (TRILL, MPLS VPNs, IPVPNs, BIER and NV03 technology). d) Recommending a monitoring structure (e.g. yang modules, netconf/restconf and monitoring tools0 Major issues: #1 There is nothing in this document which provide guidelines to the authors of experimental RFCs based in this draft on specific ways to monitor the ECN experiments, report the ECN experimental data, or disable the experimental data. If the success or failure of an experiment is based on "popular vote" determined by deployment, then say state this point. I personally would object to that because you cannot tell if a limited experiment in a specific location (E.g. a data center) might be successful in another location. If the success or failure of an experimental RFC is based on a specific set of criteria for ECN, then it would be good to give an operational suggestion on how to: a) design an experiment, b) run an experiment and collect data, and c) report ths data in order to standardize the ECN experiments using ECT(1). page 10 section 4.2 last 2 paragraphs in sentence, hinted that you have an experiment in mind without specifying the experiment's success or failure criteria other than popular vote. Is this true? if it is, this is problematic. If I misunderstood your text, then please have someone re-read the text. I have read lots of papers on ECN. 2) No discussion was given on how the TCP layer experimentation would impact routing layer handdlng of ECN. For example, the trill WG has the draft draft-ietf-trill-ecn-support. Automated tunnel set-up for MPLS VPNS or IP VPNS may look at the ECN ECT(0) or ECT(1). TRILL's ECN supports the layer-2 within the data centers. Some IP VPNS or MPLS VPNS may be needed for the data-center to business site or data-center backup traffic. As written, this draft allows loosening of the RFC3168 draft but does not provide guidelines for network interaction. 3) Some networks also use the diff-service markings to guide traffic in the network. This document does not suggest an operational check list on how to design an experiment that supports or does not support these markings. 4) Modern operational IETF protocols and data modules for automating the tracking of these experiments should be suggests ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- And again, I can only agree with Sue's comment below, as stressed by Ekr and Ben also. However, this point was answered by Spencer and Mirja, so let's move on. Editorial: Some reviews have hinted that the text is repeats several sets of language. People have found this lacked clarity. One wonders why the authors did not simply provide a set of bis documents for RFC3168, RFC6679, RFC 4341, RFC4342, and RFC5622 if it is just updating the language in the specifications. This document tries to be both revision of the specifications and the architectural guidelines for experiments. The dual nature does not lead to clarity on either subject. From nobody Thu Sep 28 02:24:19 2017 Return-Path: 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 789411345B6; Thu, 28 Sep 2017 02:24:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.499 X-Spam-Level: X-Spam-Status: No, score=-5.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dell.com header.b=alaBMbDA; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=fgbYg/4E 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 6nCpuY3E9M43; Thu, 28 Sep 2017 02:24:16 -0700 (PDT) Received: from esa6.dell-outbound.iphmx.com (esa6.dell-outbound.iphmx.com [68.232.149.229]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A0F11345B3; Thu, 28 Sep 2017 02:24:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1506590656; x=1538126656; h=from:cc:to:subject:date:message-id:references: in-reply-to:mime-version; bh=FrKCOSdVq57oZzfq4ZPuM2NLJfbo70jswV4YOoyaLp4=; b=alaBMbDAVMbFyluS3D9zQemm103YYvZx/KJ0pjG7Lxvx3oZ1pMn5DM+d NdsMdpSmBGkugDRqz5hco9tx7D1KzIygbsKYKOhLguqUurGL8sLvE3g1L c9Bdr5PuT+zZW1f9+1nDfiYdCqTzWXXJJrgDVqopP2GCrPD1syyis/0us 0=; Received: from esa6.dell-outbound2.iphmx.com ([68.232.154.99]) by esa6.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Sep 2017 04:24:12 -0500 From: "Black, David" Cc: "Black, David" , "draft-ietf-tsvwg-ecn-experimentation@ietf.org" , Gorry Fairhurst , "tsvwg-chairs@ietf.org" , "tsvwg@ietf.org" , "shares@ndzh.com" Received: from mailuogwdur.emc.com ([128.221.224.79]) by esa6.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Sep 2017 15:24:11 +0600 Received: from maildlpprd54.lss.emc.com (maildlpprd54.lss.emc.com [10.106.48.158]) by mailuogwprd54.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v8S9O6XO018812 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 28 Sep 2017 05:24:09 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com v8S9O6XO018812 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1506590651; bh=OHBIG2PK45X7A075gxGUHoAWPG4=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=fgbYg/4EbkVA75ULSAbu8lgt16JfVxDn+juG/GtTIk94J8EgMKjP0y/WdOt0bq4he /4zq40qi4ePRLVhkBK4P7u7doKHNTMxKUT+d2/Cr5wIKtmPWLi9NVOle2Vnir/Lp1h dca7eocZSGUVjU4BRTG6yyC7OEdYOB8hCuTdS8M0= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com v8S9O6XO018812 Received: from mailusrhubprd01.lss.emc.com (mailusrhubprd01.lss.emc.com [10.253.24.19]) by maildlpprd54.lss.emc.com (RSA Interceptor); Thu, 28 Sep 2017 05:23:50 -0400 Received: from MXHUB314.corp.emc.com (MXHUB314.corp.emc.com [10.146.3.92]) by mailusrhubprd01.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v8S9Nq23014986 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Thu, 28 Sep 2017 05:23:52 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB314.corp.emc.com ([10.146.3.92]) with mapi id 14.03.0352.000; Thu, 28 Sep 2017 05:23:52 -0400 To: Benoit Claise , The IESG Thread-Topic: Benoit Claise's Discuss on draft-ietf-tsvwg-ecn-experimentation-06: (with DISCUSS and COMMENT) Thread-Index: AQHTODMpsBs1l5kto0GlU4vj3a6FvKLKBpce Date: Thu, 28 Sep 2017 09:23:51 +0000 Message-ID: References: <150658704722.13642.16407521705140305125.idtracker@ietfa.amsl.com> In-Reply-To: <150658704722.13642.16407521705140305125.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_CE03DB3D7B45C245BCA0D243277949362FC912D3MX307CL04corpem_" MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd01.lss.emc.com X-RSA-Classifications: public Archived-At: Subject: Re: [tsvwg] Benoit Claise's Discuss on draft-ietf-tsvwg-ecn-experimentation-06: (with DISCUSS and COMMENT) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Sep 2017 09:24:18 -0000 --_000_CE03DB3D7B45C245BCA0D243277949362FC912D3MX307CL04corpem_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Quick comment on the Discuss topic from vacation - this is a "removing cons= traints" draft - it is not intended to provide guidelines on how to design,= run and/or evaluate ECN experiments. Those guidelines will almost certainl= y vary by experiment, and hence are (IMHO) better directly addressed in the= context of each experiment. The limited guidelines here are intended to pr= ovide some basic boundaries that all experiments must respect in order to a= void potentially serious congestion control consequences. The IESG will hav= e the opportunity to evaluate each experiment in turn when its draft is (or= drafts are) evaluated for publication as Experimental RFCs. I'll comment on the rest of Sue's helpful review when I'm back from vacatio= n, in about a week or so. Thanks, --David ... Sent from my Android not-so-smartphone. -------- Original message -------- From: Benoit Claise Date: 9/28/17 9:24 AM (GMT+00:00) To: The IESG Cc: draft-ietf-tsvwg-ecn-experimentation@ietf.org, Gorry Fairhurst , tsvwg-chairs@ietf.org, gorry@erg.abdn.ac.uk, tsvwg@ietf.org= , shares@ndzh.com Subject: Benoit Claise's Discuss on draft-ietf-tsvwg-ecn-experimentation-06= : (with DISCUSS and COMMENT) Benoit Claise has entered the following ballot position for draft-ietf-tsvwg-ecn-experimentation-06: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-experimentation/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Below is Sue Hares' OPS DIR review. I would like to DISCUSS some points. I'= m of two minds. On one side, I read: The scope of this memo is limited to these three areas of experimentation. This memo expresses no view on the likely outcomes of the proposed experiments and does not specify the experiments in detail. Additional experiments in these areas are possible, e.g., o= n use of ECN to support deployment of a protocol similar to DCTCP [I-D.ietf-tcpm-dctcp] beyond DCTCP's current applicability that is limited to data center environments. The purpose of this memo is to remove constraints in standards track RFCs that stand in the way of these areas of experimentation. On the other side: An Experimental RFC MUST be published for any protocol or mechanism that takes advantage of any of these enabling updates. Btw, the MUST is just plain wrong, as Ben mentioned. So, if you go in the direction of providing requirements for the experiment= s (as opposed to just removing the specification constraints), then I agree w= ith Sue. The document title goes in the direction: if it would say something su= ch as "Removing constraints to the ECN experimentation", that would be a diffe= rent story. Reviewer: Susan Hares Review result: Has Issues This is an OPS-DIR Review which focus the work on issues in deployed techno= logy based on this RFC. Summary: Has issues as guide to experimental RFC . To me these operational issues General comment: Thank you david for addressing this Area. Better E= CN control is critical to many portions of the network. My comments on this draft are because I really hope you can do quality experimen= ts. How this might be resolved: if there is a operational guidelines section (o= r separate document), that covered: a) how to set-up and determine if a ECT(1= ) experiment success or fails b) how to manage your ECT(1) experiment in your network. c) how to manage and detect if your ECT experiment is running into problems with other IETF technology (TRILL, MPLS VPNs, IPVPNs, BIER and NV0= 3 technology). d) Recommending a monitoring structure (e.g. yang modules, netconf/restconf and monitoring tools0 Major issues: #1 There is nothing in this document which provide guidelines to the author= s of experimental RFCs based in this draft on specific ways to monitor the ECN experiments, report the ECN experimental data, or disab= le the experimental data. If the success or failure of an experiment is based on "popular vote" determined by deployment, then say state this point. I personally would object to that because you cannot tell if a limited experiment in a specific location (= E.g. a data center) might be successful in another location. If the success or failure of an experimental RFC is based on a specific s= et of criteria for ECN, then it would be good to give an operational suggest= ion on how to: a) design an experiment, b) run an experiment and collect data= , and c) report ths data in order to standardize the ECN experiments using ECT(1). page 10 section 4.2 last 2 paragraphs in sentence, hinted that you have an experiment in mind without specifying the experiment's success or failure criteria other than popular vote. Is this true? if it is, this is problematic. If I misunderstood your text, then please have someone re-read the text. I have read lots of papers on ECN. 2) No discussion was given on how the TCP layer experimentation would impac= t routing layer handdlng of ECN. For example, the trill WG has the draft draft-ietf-trill-ecn-support. Automated tunnel set-up for MPLS VPNS or IP VPNS may look at the ECN ECT(0)= or ECT(1). TRILL's ECN supports the layer-2 within the data centers. Some IP VPNS or MPLS VPNS may be needed for the data-center to business site or data-center backup traffic. As written, this draft allows loosening of the RFC3168 draft but does not provide guidelines for network interaction. 3) Some networks also use the diff-service markings to guide traffic in th= e network. This document does not suggest an operational check list on how to desi= gn an experiment that supports or does not support these markings. 4) Modern operational IETF protocols and data modules for automating the tracking of these experiments should be suggests ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- And again, I can only agree with Sue's comment below, as stressed by Ekr an= d Ben also. However, this point was answered by Spencer and Mirja, so let's move on. Editorial: Some reviews have hinted that the text is repeats several sets of language. People have found this lacked clarity. One wonders why the authors did not simply provide a set of bis documents for RFC3168, RFC6679, RFC 4341, RFC43= 42, and RFC5622 if it is just updating the language in the specifications. This document tries to be both revision of the specifications and the architectural guidelines for experiments. The dual nature does not lead to clarity on either subject. --_000_CE03DB3D7B45C245BCA0D243277949362FC912D3MX307CL04corpem_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Quick comment on the Discuss topic from vacation - this is a "rem= oving constraints" draft - it is not intended to provide guidelines on= how to design, run and/or evaluate ECN experiments. Those guidelines will = almost certainly vary by experiment, and hence are (IMHO) better directly addressed in the context of each experiment. Th= e limited guidelines here are intended to provide some basic boundaries tha= t all experiments must respect in order to avoid potentially serious conges= tion control consequences. The IESG will have the opportunity to evaluate each experiment in turn when its dra= ft is (or drafts are) evaluated for publication as Experimental RFCs. =

I'll comment on the rest of Sue's helpful review when I'm back from va= cation, in about a week or so. 

Thanks, --David ... Sent from m= y Android not-so-smartphone.


-------- Original message --------
From: Benoit Claise <bclaise@cisco.com>
Date: 9/28/17 9:24 AM (GMT+00:00)
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-tsvwg-ecn-experimentation@ietf.org, Gorry Fairhurst <= ;gorry@erg.abdn.ac.uk>, tsvwg-chairs@ietf.org, gorry@erg.abdn.ac.uk, tsv= wg@ietf.org, shares@ndzh.com
Subject: Benoit Claise's Discuss on draft-ietf-tsvwg-ecn-experimentati= on-06: (with DISCUSS and COMMENT)

Benoit Claise has entered the following ballot pos= ition for
draft-ietf-tsvwg-ecn-experimentation-06: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-experimentati= on/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Below is Sue Hares' OPS DIR review. I would like to DISCUSS some points. I'= m of
two minds. On one side, I read:

       The scope of this memo is limited to t= hese three areas of
       experimentation.  This memo expre= sses no view on the likely outcomes
       of the proposed experiments and does n= ot specify the experiments in
       detail.  Additional experiments i= n these areas are possible, e.g., on
       use of ECN to support deployment of a = protocol similar to DCTCP
       [I-D.ietf-tcpm-dctcp] beyond DCTCP's c= urrent applicability that is
       limited to data center environments.&n= bsp; The purpose of this memo is to
       remove constraints in standards track = RFCs that stand in the way of
       these areas of experimentation.

On the other side:

   An Experimental RFC MUST be published for any protocol
   or mechanism that takes advantage of any of these enabling upd= ates.

Btw, the MUST is just plain wrong, as Ben mentioned.
So, if you go in the direction of providing requirements for the experiment= s
(as opposed to just removing the specification constraints), then I agree w= ith
Sue. The document title goes in the direction: if it would say something su= ch
as "Removing constraints to the ECN experimentation", that would = be a different
story.

Reviewer: Susan Hares
Review result: Has Issues

This is an OPS-DIR Review which focus the work on issues in deployed techno= logy
based on this RFC.

Summary: Has issues as guide to experimental RFC .  To me these operat= ional
issues General comment: Thank you david for addressing this Area.  Bet= ter ECN
control is critical to many portions of the network.
            &nb= sp;            =           My comments on this = draft are because I
            &nb= sp;            =           really hope you can = do quality experiments.

How this might be resolved: if there is a operational guidelines section (o= r
separate document), that covered: a) how to set-up and determine if a ECT(1= )
experiment success or fails b) how to manage your ECT(1) experiment in your=
network. c) how to manage and detect if your ECT experiment is running into=
problems with other IETF technology (TRILL, MPLS VPNs, IPVPNs, BIER and NV0= 3
technology). d) Recommending a monitoring structure (e.g. yang modules,
netconf/restconf and monitoring tools0

Major issues:

#1 There is nothing in this document which provide guidelines to the author= s of
experimental RFCs based in this draft on specific ways to
    monitor the ECN experiments, report the ECN experimental= data, or disable
    the experimental data.   If the success or fai= lure of an experiment is
    based on "popular vote" determined by deployme= nt, then say state this
    point.  I personally would object to that
   because you cannot tell if a limited experiment in a specific = location (E.g.
   a data center) might be successful in another location.

  If the success or failure of an experimental RFC is based on a speci= fic set
  of criteria for ECN, then it would be good to give an operational su= ggestion
  on how to: a) design an experiment, b) run an experiment and collect= data,
  and c) report ths
 data in order to standardize the ECN experiments using ECT(1).

 page 10 section 4.2 last 2 paragraphs in sentence, hinted that you ha= ve an
 experiment in mind without specifying the experiment's success or fai= lure
 criteria other than popular vote.  Is this true?  if it is,= this is
 problematic.  If I misunderstood your text, then please
have someone re-read the text.

I have read lots of papers on ECN.

2) No discussion was given on how the TCP layer experimentation would impac= t
routing layer handdlng of ECN.

For example, the trill WG has the draft draft-ietf-trill-ecn-support.
Automated tunnel set-up for MPLS VPNS or IP VPNS may look at the ECN ECT(0)=   or
ECT(1).  TRILL's ECN supports the layer-2 within the data centers.&nbs= p; Some IP
VPNS or MPLS VPNS may be needed for the data-center to business site
 or data-center backup traffic.

 As written, this draft allows loosening of the RFC3168 draft but does= not
 provide guidelines  for network interaction.

3)  Some networks also use the diff-service markings to guide traffic = in the
network.
    This document does not suggest an operational check list= on how to design
    an experiment that supports or does not support these ma= rkings.

4) Modern operational IETF protocols and data modules for automating the tracking of these experiments should be suggests


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

And again, I can only agree with Sue's comment below, as stressed by Ekr an= d Ben also.
However, this point was answered by Spencer and Mirja, so let's move on.

Editorial:
Some reviews have hinted that the text is repeats several sets of language.=
People have found this lacked clarity.  One wonders why the authors di= d not
simply provide a set of bis documents for RFC3168, RFC6679, RFC 4341, RFC43= 42,
and RFC5622 if it is just updating the language in the specifications.

This document tries to be both revision of the specifications and the
architectural guidelines for experiments.  The dual nature does not le= ad to
clarity on either subject.


 --_000_CE03DB3D7B45C245BCA0D243277949362FC912D3MX307CL04corpem_-- From nobody Thu Sep 28 06:02:42 2017 Return-Path: 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 73308132026; Thu, 28 Sep 2017 06:02:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.947 X-Spam-Level: X-Spam-Status: No, score=0.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 Fs2BWZd4QJoC; Thu, 28 Sep 2017 06:02:34 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 B49DC134714; Thu, 28 Sep 2017 06:02:32 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=184.157.84.200; From: "Susan Hares" To: "'Black, David'" , "'Benoit Claise'" , "'The IESG'" Cc: , "'Gorry Fairhurst'" , , References: <150658704722.13642.16407521705140305125.idtracker@ietfa.amsl.com> In-Reply-To: Date: Thu, 28 Sep 2017 09:02:28 -0400 Message-ID: <008801d3385a$0a2b2c50$1e8184f0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0089_01D33838.831BFD50" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEEYzckBxlWi+t0M8ej/45zgvXyVQMMpQ6FpE971vA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [tsvwg] Benoit Claise's Discuss on draft-ietf-tsvwg-ecn-experimentation-06: (with DISCUSS and COMMENT) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Sep 2017 13:02:40 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0089_01D33838.831BFD50 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit David: Have a great vacation. I'll be glad to chat with you when you get back. Thank you for letting me know it is a "removing constraints" draft. Perhaps there are a few principles for operations that could be suggested in this draft. I think you could improve the success of your experiments by providing a templates for the "operational" issues. Cheerily, Sue Hares From: Black, David [mailto:David.Black@dell.com] Sent: Thursday, September 28, 2017 5:24 AM To: Benoit Claise; The IESG Cc: Black, David; draft-ietf-tsvwg-ecn-experimentation@ietf.org; Gorry Fairhurst; tsvwg-chairs@ietf.org; tsvwg@ietf.org; shares@ndzh.com Subject: Re: Benoit Claise's Discuss on draft-ietf-tsvwg-ecn-experimentation-06: (with DISCUSS and COMMENT) Quick comment on the Discuss topic from vacation - this is a "removing constraints" draft - it is not intended to provide guidelines on how to design, run and/or evaluate ECN experiments. Those guidelines will almost certainly vary by experiment, and hence are (IMHO) better directly addressed in the context of each experiment. The limited guidelines here are intended to provide some basic boundaries that all experiments must respect in order to avoid potentially serious congestion control consequences. The IESG will have the opportunity to evaluate each experiment in turn when its draft is (or drafts are) evaluated for publication as Experimental RFCs. I'll comment on the rest of Sue's helpful review when I'm back from vacation, in about a week or so. Thanks, --David ... Sent from my Android not-so-smartphone. -------- Original message -------- From: Benoit Claise Date: 9/28/17 9:24 AM (GMT+00:00) To: The IESG Cc: draft-ietf-tsvwg-ecn-experimentation@ietf.org, Gorry Fairhurst , tsvwg-chairs@ietf.org, gorry@erg.abdn.ac.uk, tsvwg@ietf.org, shares@ndzh.com Subject: Benoit Claise's Discuss on draft-ietf-tsvwg-ecn-experimentation-06: (with DISCUSS and COMMENT) Benoit Claise has entered the following ballot position for draft-ietf-tsvwg-ecn-experimentation-06: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-experimentation/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Below is Sue Hares' OPS DIR review. I would like to DISCUSS some points. I'm of two minds. On one side, I read: The scope of this memo is limited to these three areas of experimentation. This memo expresses no view on the likely outcomes of the proposed experiments and does not specify the experiments in detail. Additional experiments in these areas are possible, e.g., on use of ECN to support deployment of a protocol similar to DCTCP [I-D.ietf-tcpm-dctcp] beyond DCTCP's current applicability that is limited to data center environments. The purpose of this memo is to remove constraints in standards track RFCs that stand in the way of these areas of experimentation. On the other side: An Experimental RFC MUST be published for any protocol or mechanism that takes advantage of any of these enabling updates. Btw, the MUST is just plain wrong, as Ben mentioned. So, if you go in the direction of providing requirements for the experiments (as opposed to just removing the specification constraints), then I agree with Sue. The document title goes in the direction: if it would say something such as "Removing constraints to the ECN experimentation", that would be a different story. Reviewer: Susan Hares Review result: Has Issues This is an OPS-DIR Review which focus the work on issues in deployed technology based on this RFC. Summary: Has issues as guide to experimental RFC . To me these operational issues General comment: Thank you david for addressing this Area. Better ECN control is critical to many portions of the network. My comments on this draft are because I really hope you can do quality experiments. How this might be resolved: if there is a operational guidelines section (or separate document), that covered: a) how to set-up and determine if a ECT(1) experiment success or fails b) how to manage your ECT(1) experiment in your network. c) how to manage and detect if your ECT experiment is running into problems with other IETF technology (TRILL, MPLS VPNs, IPVPNs, BIER and NV03 technology). d) Recommending a monitoring structure (e.g. yang modules, netconf/restconf and monitoring tools0 Major issues: #1 There is nothing in this document which provide guidelines to the authors of experimental RFCs based in this draft on specific ways to monitor the ECN experiments, report the ECN experimental data, or disable the experimental data. If the success or failure of an experiment is based on "popular vote" determined by deployment, then say state this point. I personally would object to that because you cannot tell if a limited experiment in a specific location (E.g. a data center) might be successful in another location. If the success or failure of an experimental RFC is based on a specific set of criteria for ECN, then it would be good to give an operational suggestion on how to: a) design an experiment, b) run an experiment and collect data, and c) report ths data in order to standardize the ECN experiments using ECT(1). page 10 section 4.2 last 2 paragraphs in sentence, hinted that you have an experiment in mind without specifying the experiment's success or failure criteria other than popular vote. Is this true? if it is, this is problematic. If I misunderstood your text, then please have someone re-read the text. I have read lots of papers on ECN. 2) No discussion was given on how the TCP layer experimentation would impact routing layer handdlng of ECN. For example, the trill WG has the draft draft-ietf-trill-ecn-support. Automated tunnel set-up for MPLS VPNS or IP VPNS may look at the ECN ECT(0) or ECT(1). TRILL's ECN supports the layer-2 within the data centers. Some IP VPNS or MPLS VPNS may be needed for the data-center to business site or data-center backup traffic. As written, this draft allows loosening of the RFC3168 draft but does not provide guidelines for network interaction. 3) Some networks also use the diff-service markings to guide traffic in the network. This document does not suggest an operational check list on how to design an experiment that supports or does not support these markings. 4) Modern operational IETF protocols and data modules for automating the tracking of these experiments should be suggests ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- And again, I can only agree with Sue's comment below, as stressed by Ekr and Ben also. However, this point was answered by Spencer and Mirja, so let's move on. Editorial: Some reviews have hinted that the text is repeats several sets of language. People have found this lacked clarity. One wonders why the authors did not simply provide a set of bis documents for RFC3168, RFC6679, RFC 4341, RFC4342, and RFC5622 if it is just updating the language in the specifications. This document tries to be both revision of the specifications and the architectural guidelines for experiments. The dual nature does not lead to clarity on either subject. ------=_NextPart_000_0089_01D33838.831BFD50 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

David:

 

Have a great vacation.   I’ll be glad to chat with = you when you get back.

 

Thank you for letting me know it is a “removing = constraints” draft.   Perhaps there are a few principles = for operations that could be suggested in this draft.   I = think you could improve the success of your experiments by providing a = templates for the “operational” issues.  =

 

Cheerily,  Sue Hares

 

From:= = Black, David [mailto:David.Black@dell.com]
Sent: Thursday, = September 28, 2017 5:24 AM
To: Benoit Claise; The = IESG
Cc: Black, David; = draft-ietf-tsvwg-ecn-experimentation@ietf.org; Gorry Fairhurst; = tsvwg-chairs@ietf.org; tsvwg@ietf.org; = shares@ndzh.com
Subject: Re: Benoit Claise's Discuss on = draft-ietf-tsvwg-ecn-experimentation-06: (with DISCUSS and = COMMENT)

 

Quick comment on the Discuss topic from vacation - = this is a "removing constraints" draft - it is not intended to = provide guidelines on how to design, run and/or evaluate ECN = experiments. Those guidelines will almost certainly vary by experiment, = and hence are (IMHO) better directly addressed in the context of each = experiment. The limited guidelines here are intended to provide some = basic boundaries that all experiments must respect in order to avoid = potentially serious congestion control consequences. The IESG will have = the opportunity to evaluate each experiment in turn when its draft is = (or drafts are) evaluated for publication as Experimental = RFCs. 

 

I'll comment on the rest of Sue's helpful review when = I'm back from vacation, in about a week or = so. 

 

Thanks, --David ... Sent from = my Android not-so-smartphone.

 

 

-------- Original message = --------

From: Benoit = Claise <bclaise@cisco.com> =

Date: 9/28/17 9:24 AM = (GMT+00:00)

To: The IESG = <iesg@ietf.org> =

Subject: Benoit Claise's = Discuss on draft-ietf-tsvwg-ecn-experimentation-06: (with DISCUSS and = COMMENT)

 

Benoit Claise has entered the following = ballot position for
draft-ietf-tsvwg-ecn-experimentation-06: = Discuss

When responding, please keep the subject line intact and = reply to all
email addresses included in the To and CC lines. (Feel = free to cut this
introductory paragraph, however.)


Please = refer to https:= //www.ietf.org/iesg/statement/discuss-criteria.html
for more = information about IESG DISCUSS and COMMENT positions.


The = document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-experimentat= ion/



-------------------------------------------------= ---------------------
DISCUSS:
------------------------------------= ----------------------------------

Below is Sue Hares' OPS DIR = review. I would like to DISCUSS some points. I'm of
two minds. On one = side, I read:

       The scope of = this memo is limited to these three areas = of
       experimentation.  This = memo expresses no view on the likely = outcomes
       of the proposed = experiments and does not specify the experiments = in
       detail.  Additional = experiments in these areas are possible, e.g., = on
       use of ECN to support = deployment of a protocol similar to = DCTCP
       [I-D.ietf-tcpm-dctcp] = beyond DCTCP's current applicability that = is
       limited to data center = environments.  The purpose of this memo is = to
       remove constraints in = standards track RFCs that stand in the way = of
       these areas of = experimentation.

On the other side:

   An = Experimental RFC MUST be published for any protocol
   or = mechanism that takes advantage of any of these enabling = updates.

Btw, the MUST is just plain wrong, as Ben = mentioned.
So, if you go in the direction of providing requirements = for the experiments
(as opposed to just removing the specification = constraints), then I agree with
Sue. The document title goes in the = direction: if it would say something such
as "Removing = constraints to the ECN experimentation", that would be a = different
story.

Reviewer: Susan Hares
Review result: Has = Issues

This is an OPS-DIR Review which focus the work on issues = in deployed technology
based on this RFC.

Summary: Has issues = as guide to experimental RFC .  To me these operational
issues = General comment: Thank you david for addressing this Area.  Better = ECN
control is critical to many portions of the = network.
          &= nbsp;           &n= bsp;            = My comments on this draft are because = I
           &n= bsp;           &nb= sp;           really = hope you can do quality experiments.

How this might be resolved: = if there is a operational guidelines section (or
separate document), = that covered: a) how to set-up and determine if a ECT(1)
experiment = success or fails b) how to manage your ECT(1) experiment in = your
network. c) how to manage and detect if your ECT experiment is = running into
problems with other IETF technology (TRILL, MPLS VPNs, = IPVPNs, BIER and NV03
technology). d) Recommending a monitoring = structure (e.g. yang modules,
netconf/restconf and monitoring = tools0

Major issues:

#1 There is nothing in this document = which provide guidelines to the authors of
experimental RFCs based in = this draft on specific ways to
    monitor the ECN = experiments, report the ECN experimental data, or = disable
    the experimental data.   If the = success or failure of an experiment is
    based on = "popular vote" determined by deployment, then say state = this
    point.  I personally would object to = that
   because you cannot tell if a limited experiment in = a specific location (E.g.
   a data center) might be = successful in another location.

  If the success or failure = of an experimental RFC is based on a specific set
  of criteria = for ECN, then it would be good to give an operational = suggestion
  on how to: a) design an experiment, b) run an = experiment and collect data,
  and c) report ths
 data = in order to standardize the ECN experiments using = ECT(1).

 page 10 section 4.2 last 2 paragraphs in sentence, = hinted that you have an
 experiment in mind without specifying = the experiment's success or failure
 criteria other than popular = vote.  Is this true?  if it is, this = is
 problematic.  If I misunderstood your text, then = please
have someone re-read the text.

I have read lots of = papers on ECN.

2) No discussion was given on how the TCP layer = experimentation would impact
routing layer handdlng of = ECN.

For example, the trill WG has the draft = draft-ietf-trill-ecn-support.
Automated tunnel set-up for MPLS VPNS = or IP VPNS may look at the ECN ECT(0)  or
ECT(1).  TRILL's = ECN supports the layer-2 within the data centers.  Some IP
VPNS = or MPLS VPNS may be needed for the data-center to business = site
 or data-center backup traffic.

 As written, = this draft allows loosening of the RFC3168 draft but does = not
 provide guidelines  for network = interaction.

3)  Some networks also use the diff-service = markings to guide traffic in the
network.
    This = document does not suggest an operational check list on how to = design
    an experiment that supports or does not = support these markings.

4) Modern operational IETF protocols and = data modules for automating the
tracking of these experiments should = be = suggests


-----------------------------------------------------= -----------------
COMMENT:
----------------------------------------= ------------------------------

And again, I can only agree with = Sue's comment below, as stressed by Ekr and Ben also.
However, this = point was answered by Spencer and Mirja, so let's move = on.


Editorial:
Some reviews have hinted that the text is = repeats several sets of language.
People have found this lacked = clarity.  One wonders why the authors did not
simply provide a = set of bis documents for RFC3168, RFC6679, RFC 4341, RFC4342,
and = RFC5622 if it is just updating the language in the = specifications.

This document tries to be both revision of the = specifications and the
architectural guidelines for = experiments.  The dual nature does not lead to
clarity on either = subject.

------=_NextPart_000_0089_01D33838.831BFD50--