Hi Christer,
As document shepherd for this SCTP process, I'll have a first go at
responding. I think that for RFC4960 the Errata as filed still apply.
See below. The document authors can of course also propose answers to
these questions
Gorry
On 04/06/2018 10:17, Christer Holmberg wrot
Hi
On 04/06/2018 11:13, Christer Holmberg wrote:
Hi Gorry,
...
The information in this document does not update RFC4640 or the Errata
to that specification. The document is instead provided as input to
preparation of a new document that is expected to be a standards-track
replacement for RFC
+1, as Chair. I see we have caused a little confusion here - The WG will
not repeat this list of changes again as a part of the new .bis document.
There could always be potentially be further changes as the .bis
document passes through the WG - of course - but we'd rather expect this
spec is m
Thanks Russ - I believe we will deal with all these in the next revision,
Gorry
On 17/08/2018, 19:17, Russ Housley wrote:
Reviewer: Russ Housley
Review result: Ready
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being proce
I commented at the WG meeting, and would like to add a few comments here:
On 07/02/2019 13:27, Zaheduzzaman Sarker wrote:
Hi Stewart,
Thanks for a good review.
For the security consideration section, we can use stronger words if that is
required. This document merely specifies test cases when
Miguel A. Garcia wrote:
I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please wait for direction from your document shepherd
or AD before posting a new version
Thanks for your review! We will act on this and another detailed review
of NiTs, and expect to make a new revision in a few days.
Sorry for adding to your pain - being careful to work as an early pilot
for the new document format has probably left us continuing with more
NiTs than we should ha
Please see below.
On 05/06/2020 17:43, Mark Allman wrote:
Hi Stewart!
Thanks for the feedback. Sorry for the long RTT. I had a recent
deadline and am now trying to dig out.
Major issues:
As far as I can see this text only applies to exchanges between
applications and network support applic
I agree, see below.
On 07/06/2020 18:11, Benjamin Kaduk wrote:
On Sat, Jun 06, 2020 at 08:19:52AM +0100, Gorry Fairhurst wrote:
Please see below.
On 05/06/2020 17:43, Mark Allman wrote:
=
(3) Each time the RTO is used to detect a loss, the value of the RTO
MUST
See a few comments (marked GF) from the perspective of other transport
RFCs, in case this helps you find text...
Forwarded Message
Subject: Re: [tcpm] Genart last call review of
draft-ietf-tcpm-rto-consider-14
Date: Thu, 18 Jun 2020 11:00:15 +0100
From: Stewart Bryant
One minor nit on the new text, the term "controlled environment" is used
elsewhere in the RFC series in transport-related documents to describe
what you name "constrained environment".
Gorry
On 19/06/2020 16:02, Mark Allman wrote:
I just posted a new version of rto-consider (-16). The docume
Thanks Joel for these helpful comments.
We think these issues could be addressed with a small number of
additional clarifications, see below:
On 15/02/2021 22:46, Joel Halpern via Datatracker wrote:
Reviewer: Joel Halpern
Review result: Ready with Issues
I am the assigned Gen-ART reviewer fo
12 matches
Mail list logo
