Hi, Dan,
Thank you for this review. I'm confident both comments can be clarified
in a minor revision.
However, I did have a question about the end at "Nits/editorial
comments:" -- was there additional feedback intended there, or was this
section intended to be empty?
Thanks,
Joe
On 12/15/2014
Hi, Ole,
On 2/14/2017 10:33 AM, otr...@employees.org wrote:
>> *If* you care about packet loss, then your only option is to probe the path
>> with with
>> synthetic data that exactly mimics the live data, or not to probe at all and
>> live
>> with the 1280. As I said 1280 is pretty close to 14
Brian (et al.),
On 2/10/2017 11:45 AM, Brian E Carpenter wrote:
>> practice the
>> Internet breaks the mechanism. However it breaks it is a way that seems
>> disruptive to some user traffic. The document is really guidance
>> one how hosts might use ICMP for optimization, and arguable need
>> no
Hi, Brian,
On 2/15/2017 1:26 PM, Brian E Carpenter wrote:
> On 16/02/2017 10:12, Joe Touch wrote:
>> Brian (et al.),
>>
>>
>> On 2/10/2017 11:45 AM, Brian E Carpenter wrote:
>>>> practice the
>>>> Internet breaks the mechanism. However it br
On 2/16/2017 7:59 AM, Stewart Bryant wrote:
>
>
> On 14/02/2017 23:00, Templin, Fred L wrote:
>> Unless there is operational assurance of
>> some size X>1280, however, tunnels have to use fragmentation to
>> guarantee that - at a minimum - packets up to 1280 will get through.
>
> In that case the
On 2/16/2017 11:59 AM, Brian E Carpenter wrote:
> On 17/02/2017 04:59, Stewart Bryant wrote:
>>
>> On 14/02/2017 23:00, Templin, Fred L wrote:
>>> Unless there is operational assurance of
>>> some size X>1280, however, tunnels have to use fragmentation to
>>> guarantee that - at a minimum - packe
On 2/16/2017 1:29 PM, Stewart Bryant wrote:
>
>
> On 16/02/2017 18:49, Joe Touch wrote:
>>
>> On 2/16/2017 7:59 AM, Stewart Bryant wrote:
>>>
>>> On 14/02/2017 23:00, Templin, Fred L wrote:
>>>> Unless there is operational assurance of
Hi, Stewart,
On 4/24/2017 10:12 AM, Stewart Bryant wrote:
> Minor issues:
>
> A node MUST NOT reduce its estimate of the Path MTU below the IPv6
> minimum link MTU.
>
> SB> I missed this last time.
> SB>
> SB> Presumably you mean "A node MUST NOT reduce its estimate of the
> SB> Path MTU below
Hi, Stewart,
On 4/26/2017 1:48 AM, Stewart Bryant wrote:
>
>
> On 25/04/2017 19:26, Joe Touch wrote:
>> Hi, Stewart,
>>
>> ...
>>
>>> SB>
>>> SB> Otherwise I would have thought that this was entirely a matter
>>> SB> for the
Hi, Fred,
On 4/26/2017 1:08 PM, Fred Baker wrote:
>> Individual packets and fragments can be smaller than the MTU, of course.
>> Nothing forces fragments to push up against any MTU limit at all. But I
>> would not describe that has a host changing its path MTU; it's just
>> sending packets.
> I d
On 4/26/2017 1:30 PM, Brian E Carpenter wrote:
>>> Individual packets and fragments can be smaller than the MTU, of course.
>>> Nothing forces fragments to push up against any MTU limit at all. But I
>>> would not describe that has a host changing its path MTU; it's just
>>> sending packets.
>> I
On 4/27/2017 5:36 AM, Stewart Bryant wrote:
> ...
> So this seems to me to be an argument of principle vs pragmatism, and
> in general pragmatism has served the Internet well so far.
>
> I think pragmatism is what Fred and Brian arguing for. It is certainly
> the general approach that I support.
Hi, Bob,
AOK. Thanks,
Joe
On 5/5/2017 5:32 AM, Bob Hinden wrote:
>> On Apr 25, 2017, at 9:26 PM, Joe Touch wrote:
>>
>> Hi, Stewart,
>>
>>
>> On 4/24/2017 10:12 AM, Stewart Bryant wrote:
>>> Minor issues:
>>>
>>> A node MUST NOT
Hi, Brian,
See comments below…
Joe
> On Sep 15, 2018, at 3:32 PM, Brian E Carpenter
> wrote:
>
> Dear 杨术,
>
> I have added Joe Touch in Cc because one point below overlaps
> with his TSVART review.
> On 2018-09-16 06:41, 杨术 wrote:
>> Dear Brian,
>>
>
Hi, Brian,
> On Sep 16, 2018, at 1:44 PM, Brian E Carpenter
> wrote:
>
> Hi Joe,
> On 2018-09-17 05:15, Joe Touch wrote:
>> Hi, Brian,
>>
>> See comments below…
>>
>> Joe
>>
>>> On Sep 15, 2018, at 3:32 PM, Brian E Carpenter
>
Hi, Brian,
On 9/16/2018 3:59 PM, Brian E Carpenter wrote:
>>> So should
>>> the AFBR include a frag header just in case?
>> That won’t help. The frag header would be generated at the tunnel ingress
>> and has to be unique there (which has no relation to a frag header of the
>> inner packet, if
Hi, all,
Including both TSV ADs, the WG chairs, and the authors in this response.
See below.
PS - it would be useful to include the document authors in Gen-ART
posts; we received this message indirectly by the IESG.
Joe
> Original Message
> Subject: [Gen-art] [Gen-ART] review
On 8/13/2012 7:14 AM, philip.eard...@bt.com wrote:
Ben,
Thanks for your review.
The right status isn't clear-cut (I think), but when we (Chairs & Wes)
discussed it, Info seemed best
* mainly because precedent seems to be that API docs are informational, for
example socket API extensions for
Unix time != the Posix time API. One is a time scale; the other is the
interface to obtain potentially many different time scales.
I dove into these issues here: draft-touch-time
Joe
> On Nov 8, 2019, at 7:34 AM, Burleigh, Scott C (US 312B)
> wrote:
>
> I disagree. From Wikipedia:
>
> Uni
The draft is more about time scales than protocols used to sync them. NTP is
mentioned largely in its use of UTC. PTP supports a variety of time scales so
it doesn’t add much to the discussion.
Joe
> On Nov 8, 2019, at 8:24 AM, Stewart Bryant wrote:
>
>
>
>> On 8 Nov 2
kuehlewind-system-ports (6th March, 2020)
Date: Mon, 17 Feb 2020 15:06:40 -0800
From: Joe Touch
To: Gorry Fairhurst , ts...@ietf.org
I object on process grounds at a minimum and call for its "last calls"
to be revoked by the sponsoring AD and WG chair as follows:
1) this do
21 matches
Mail list logo
