Dear Meral,
Based on you comments, a new version of this draft was generated and submitted.
Thank you so much for pushing this work.
BR,
Zhiwei
---
A new version of I-D, draft-ietf-dmm-hnprenum-06.txt
has been successfully submitted by Zhiwei Yan and posted to the
IETF
Hello Dale,
O.K. I will take a crack at making this reorganization. If you have
text of course that will be appreciated. Right now I don't see why
anyone in the WG would object, but I hope at least some people will take
a look.
I can have the revised draft ready in a few days. I think
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 breaks it is a way that seems
disruptive to some
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 breaks it is a way that seems
>>> disruptive to some user traffic. The document is really guidance
>>> one how hosts might
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
>>
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
Hi Robert,
safe travel and here's another version for your consideration. The point
I'm trying to convey is that the jitter is real but must be accounted not
as part of propagation delay but as residence time. Hope I'm getting close.
Each RTM-capable
node on the explicit path receives an
On 2/15/17 11:20 AM, Greg Mirsky wrote:
Hi Robert,
yes, you've absolutely correct in your example. The importance of RTM
is to exclude and quantify, as much as possible, jitter from
propagation delay. I've updated the wording to reflect that. Below is
new text I propose, please let me know
Hi Robert,
yes, you've absolutely correct in your example. The importance of RTM is to
exclude and quantify, as much as possible, jitter from propagation delay.
I've updated the wording to reflect that. Below is new text I propose,
please let me know if it makes it clearer.
Each RTM-capable
HI Dale,
Thanks again for the comments. Please see inline.
On 2/13/17, 8:55 AM, "Dale R. Worley" wrote:
>"Sri Gundavelli (sgundave)" writes:
>> When we discussed this issue in the past, the general feedback from
>> the WG was that the draft should
Hi all,
The following reviewers have assignments:
For telechat 2017-02-16
Reviewer Type LC end Draft
Orit Levin Last Call 2017-01-31 draft-ietf-sidr-delta-protocol-07
Lucy Yong Last Call 2017-01-30
draft-ietf-sidr-rpki-rtr-rfc6810-bis-08
For
On 2/14/17 10:06 PM, Greg Mirsky wrote:
Hi Robert,
Section 5 Data Plane Theory of Operation has the following
recommendation on reading time value at ingress and egress:
Each RTM-capable
node on the explicit path receives an RTM packet and records the time
at which it receives
Reviewer: Francis Dupont
Review result: Ready with Issues
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
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
14 matches
Mail list logo