This seems consistent with previous discussions.
Gorry
Hi all,
We have proofread the DCCP spec in detail for AUTH48, and have found a
number of technical nits. There was one thing that I wanted to mention
explicitly before AUTH48 ends.
We propose to change the default value of the
for the proceedings and tell
the WG.
3) We will do a last call to everyone on the DCCP list for corrections to
the notes for final version of the note for proceedings. This will be well
before the deadline of April 21, Friday.
If you notice anything amiss, please do let Tom and I know!
Best wishes,
Gorry
Although I agree that CN packets are a function of the media codec, they
*COULD* offer a mitigation to the effects of longer delay paths.
When the Path RTT is short (e.g. less than a tenth of a second), then
the TFRC algorithm already grows a window in a short time (e.g. still
much less
WG Internet Draft: draft-ietf-DCCP-tfrc-voip -05.txt
TCP Friendly Rate Control (TFRC):
the Small-Packet (SP) Variant
Dear DCCP WG,
The Chairs would like to say sorry for the long delay in processing the
I-D below, following its WGLC. We now intend to progress this.
While preparing the
A reminer that the WGLC is currently on-going - anyone interested in
this I-D is welcome to send questions and requests for clarification
within the WGLC period.
Best wishes,
Gorry Tom
(DCCP WG Chairs)
Original Message
Dear DCCP WG,
The Chairs would like to say sorry
Eddie said:
snip
No valid implementation would use a large s for X_calc and
a small s for t_ipi. They are the same variable and must
take the same value in both calculations. (If the app changes
s between feedback packets, then maybe the cached X_calc
used a different value of s than t_ipi;
We need as a WG to understand what it means to use Service Codes - how
these should be used by applications, how midboxes may leverage them,
and what are the implications of allowing flexible assignments (more
opportunities for applications to pretend to be what they are not??)
There was
Colin, I have just a few queries (mainly wording) about your I-D.
Best wishes,
Gorry
---
In Section 4.2, you don't define or reference SIP when first used:
for example by performing a SIP re-invite...
- Perhaps say: Session Initiation Protocol, SIP [24]
In Section 4.2 (towards the end) the
I've uploaded advance copies of the slides that I have currently received
for tomorrow's meeting of the DCCP WG.
Other presenters - please could you send copies of your slides to me, and I
will ensure they are uploaded. Advance copies of the presentations are
extremely useful for people intend
Sally,
I think the argument you put at the end of your email would be fine to
address my concerns on different MSS.
That leaves the issue of very small MTUs that was again raised at the
meeting today.
Clearly we can have small MTUs 576 B.
An example of a very small MTU is:
small packet sizes recognize that
it is largely their problem.
So I think a simple warning as Sally proposed would suffice.
Richard.
Gorry Fairhurst wrote:
Sally,
I think the argument you put at the end of your email would be fine to
address my concerns on different MSS
to contribute?
Best wishes,
Gorry Fairhurst
(DCCP WG Co-Chair)
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : The DCCP Service Code
Author(s) : G. Fairhurst
Filename: draft-fairhurst-dccp-serv-codes-01.txt
Pages : 15
Date:
Forwarded email in relation to ICCRG work:
From: Erblichs [EMAIL PROTECTED]
Please forward if you think it is appropriate,,
Authors,
Layout/per RFC question,
Can I suggest a different per RFC layout.
In my opinion, each RFC listing item should include the type of
Ian,
I can see what you are saying, and indeed this is an interesting problem
area, in that it impacts what we understand as correct behaviour, but
also impinges on what we may accept as accceptable implementation cost.
I'll let others figure out their advice to you...
Gorry
Ian McDonald
in such a clustered fashion that you wouldn't see
any packets with an intact header but erroneous payload
(which is the only situation where the scheme would
yield any benefit). I think that it was Gorry Fairhurst
who said this.
I figured that the only convincing way to prove him
wrong
then
modified.
Eddie
Gorry Fairhurst wrote:
TFRC.bis is a maintainance version of TFRC, to correct the TFRC
specification and will obsolete it when published. The stated milestone
date is July 2007 - my notes show this is currently pending inputs from
implementors (please do contribute
I'd like to put forward this document as an Individual Submission to be
discussed at the next WG meeting (NOT as the WG Chair this time!)
Thoughts on the direction, usefulness and comments on the text are welcome!
Best wishes,
Gorry
Original Message
Subject: New Version
Please see note enclosed, also if you would like to have any agenda time
at this meeting to report status of discuss issues relating to a draft,
please do send an email to the Chairs,
Best wishes,
Gorry Tom
Original Message
Subject: Internet-Drafts Submission Cutoff
Sally, co-Editors,
Here are a list of issues we have found from the email discussions we
have been involved with, and/or our research. Please don't take these as
corrections, but they are things that we'd like you to consider
(apologies in advance if these are wrongly attributed to
I have updated this I-D with corrections received from others and some
new additions to section 4.
Comments and questions are welcome...
best wishes,
Gorry
---
draft-fairhurst-dccp-serv-codes-03.txt.
http://www.ietf.org/internet-drafts/draft-fairhurst-dccp-serv-codes-03.txt
Abstract
Ian McDonald wrote:
On 2/28/07, Gorry Fairhurst [EMAIL PROTECTED] wrote:
2) Ian - In section 4.3 of RFC3448 we have the equation for X as:
If (p 0)
Calculate X_calc using the TCP throughput equation.
X = max(min(X_calc, 2*X_recv), s/t_mbi);
I have been
PROTECTED]
Gorry Fairhurst [EMAIL PROTECTED]
jabber: [EMAIL PROTECTED]
1. Agenda Bashing (10 minutes) - Chair
* Agenda changes
* Election of Scribe for Proceedings
* Jabber Scribe
2. Document Status (5 minutes) - Chair
* Milestones.
New WG I-D on DTLS
Thanks,
When it comes to use htonl/ntohl with a socket opt, I guess others may
have more clue than me... please do also reply!
See in-line.
Gorry
Ian McDonald wrote:
On 3/6/07, Gorry Fairhurst [EMAIL PROTECTED] wrote:
I have updated this I-D with corrections received from others
Colin Perkins wrote:
Gorry,
Some comments/thoughts inline.
On 26 Mar 2007, at 12:09, Gorry Fairhurst wrote:
This email is to start a discussion on the use and requirements for
protocol
keep-alive packets in DCCP. This is a follow-up to discussing the
RTP/DCCP
draft.
A keep-alive packet
Arjuna Sathiaseelan wrote:
I have some doubts.
The question is Who has control over Who? Does the application layer control
the transport protocol, or do transport protocols have their own autonomy?
So if the application does'nt send any data, should the transport protocol
send keep alives by
Breaking the cross-post between list... (just to DCCP).
So, as far as DCCP is concerned, 576B also seems big to me. There are
apps doing bulk transfers with this size (albeit with a lack of working
PMTUD to know better).
1500 B at 10 ms spacing is 1.2 Mbps - which is not small.
One
(into April)
Gorry
Phelan, Tom wrote:
Hi Gorry,
See inline...
Tom P.
-Original Message-
From: Gorry Fairhurst [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 27, 2007 10:58 AM
To: Arjuna Sathiaseelan
Cc: dccp@ietf.org
Subject: Re: [dccp] Why do we have or should have keep-alive packets
you tell what its purpose is?
Do we need to reserve zero-length packets for use by only one of these
functions?
Tom P.
-Original Message-
From: Gorry Fairhurst [mailto:[EMAIL PROTECTED] Sent: Monday, March
26, 2007 7:09 AM
To: [EMAIL PROTECTED]; dccp@ietf.org
Subject: [dccp] Why do we
Thanks for your comments.
Please see comments and questions in-line, all thoughts welcome. When we
conclude these issues, I'll post a revised I-D.
Best wishes,
Gorry
Gorry,
* General comment:
The draft argues that services codes allow the decoupling of service
identification from
Eddie Kohler wrote:
Tom,
The addition of service codes by DCCP allows us to break this
demultiplexing/identifying duality. We can now say that the *exclusive*
use of port numbers is for demultiplexing, and the *exclusive* use of
service codes is for identifying applications. This implies a
Colin,
The form of the IANA line to update the registry should normatively be a
big-endian 32-bit number (RFC 4340, 19.8), the 4 character ascii is an
alternative represenation.
3. I believe the draft needs to define a value for its IANA-
registered DCCP
service codes, as service codes
On 25/7/07 12:32, Mark Handley [EMAIL PROTECTED] wrote:
OK, here's a draft draft on the issue. I think this is in keeping
with your mail, but provides background too, and I think changes how
IANA allocates DCCP ports. Comments? Flames?
Shall I turn this into a proper draft, or is there
-Original Message-
From: Sally Floyd [mailto:[EMAIL PROTECTED]
Sent: den 20 augusti 2007 02:27
To: Eddie Kohler
Cc: Gorry Fairhurst; Golam Sarwar; Sebastien Ardon; 'dccp'
working group; Roksana Boreli
Subject: Re: [dccp] DCCP for VoIP
This sounds like a very interesting idea. While
I have just uploaded a new version of the Service Codes draft. The main
focus of this revision was to consolidate the text towards some
solutions (previous revisions included a range of options gathered from
the list and seeking to answer questions that were raised).
- Historical
Eddie, thank you for your comments, this has been very helpful.
I'm pleased to try to address the issues you raised (see below), and
will make a new revision soon. My belief is that draft is converging
(and it is shortening each rev). I note that several fundamental issues
will still need to
Eddie Kohler wrote:
snip
SC=0 allows Unix-like implementations to associate a valid Service Code
with every socket, without changing the procedure used for opening
sockets (i.e., without adding extra setsockopt calls or adding members
to struct sockaddr). Linux for a time used SC=0 this
Eddie Kohler wrote:
Gorry Fairhurst wrote:
Eddie Kohler wrote:
snip
If the application requires a new Service Code, one may either be
chosen a value from the private range (Section 2.3), or a new Service
Code may be requested from the IANA.
Private Use range is intended for interim
Dear all,
We have a provisional Agenda slot for DCCP, and the WG Chairs would
welcome requests for Agenda slots for short presentations on active
drafts relating to DCCP and congestion control. Please copy all requests
to both chairs.
Best wishes,
Tom Gorry
The provisional agenda is at:
I finished a revision of the SC draft (rev -02) last month. In this
revision, I decided to step-back from the problem of easier allocation
of server ports to Service Codes.
One possibility would be to find a way to allow easier allocation of
DCCP server ports (e.g. also from a specific DCCP
I have some questions, actually nearly all of these relate to the one
paragraph on PMTU with DTLS, the last para of section 5.
Best wishes,
Gorry
--
1)
/DTLS implementations SHOULD control the use of the DF-bit in concert/
I have just finished reading the latest rev of 3448.bis. I have only a
few questions. I think this is a good sign, and look forward to your
response and the presentation in the DCCP meeting.
Best wishes,
Gorry
---
Page 14
/because many implementations do not use delayed acknowledgements... we
You can find the agenda and presentation materials at
http://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=70
Presentation slides will be uploaded prior to the meeting time, and
afterwards (as necessary).
IPR reminder - RFC 3979
Thanks Tom.
We started thinking in our Intro about firewalls, and in the process
picked up a lot of text on NATs. We *did* intend to write in terms of
DCCP client and server, so let us know what we got wrong.
We could be happy to split the NAT stuff towards the NAT draft, when and
if that
During the WG meeting today we looked at the following set of questions
posed by implementors. Could people in the working group please look at
these questions and see if they are able to help with answers?
Questions relayed by gorry to the list:
1) Input is solicited how DCCP is being used
Since Service Codes are freely assigned, and application developers are
encouraged to ask for what they need, it would be nice for these
developers to also know which port to use in some loosely coordinated
fashion! Free assignment of ports with Service Codes is one alternative,
but has many
Thursday 1610-1700; Meet outside Capilano.
This email announces a short meeting to focus on the way in which ports
and service codes should be reflected in the DCCP protocol.
The aim is to move forward from the discussion on allocating ports
following the DCCP meeting yesterday, and the tsvarea
Here are the first cut DRAFT meeting minutes from our session.
http://www3.ietf.org/proceedings/07dec/minutes/dccp.txt
Comments and corrections are appreciated. Please submit all amendments
and/or corrections by 31 December 2007.
Thanks
Gorry Tom
DCCP WG co-chairs
Yes, this could be explained clearer - and probably should be.
My thinking was:
* The TCP RTO was 3 RTTs+variance term.
* TFRC does not usually provide prompt feedback of status from
a receiver. It could be up to one RTT later before a sender
receives feedback.
Hence, NFT is (3RTT)+RTT.
I have uploaded the final version of the minutes including all currently
requested corrections (and spelling mistakes, etc). Please let us know
if any further corrections are required.
Best wishes,
Gorry Tom
for the process following completion of the WGLC
shall be me, as the dccp Co-Chair (Gorry Fairhurst).
Best wishes,
Gorry Fairhurst
(DCCP WG Co-Chair)
See also in-line comments from me (this has opened some new questions on
the text).
Phelan, Tom wrote:
Hi Pasi,
Thanks for the careful reading and comments. See inline...
Tom P.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Monday, January 14, 2008
I have the following comments, which I'd like to be taken into
consideration during this WGLC:
There are two issues I'd like clarified:
---
Page 7, section 3.5, para 2.
Alternatively, DTLS over DCCP implemenations MAY choose to use its own
PMTU Discovery...
- The recent comments from Pasi,
Vladimir, said I could forward this to the authors and list.
To remind people, we're expecting a revised I-D that addresses the
comments from the reviewers and any from this list. We then hope to be
able to start a WGLC.
Best wishes,
Gorry
(DCCP WG Co-Chair)
Hello Gorry,
I have not
.
The WG Chair will then prepare a write-up for submission to the IESG.
Any further comments on the process or issues with this draft
should be directed to the WG Chairs.
Best wishes,
Gorry Fairhurst
(DCCP WG Chair)
1, 2007.
(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?
Gorry Fairhurst
Dear all,
I've just posted a new revision of the Service Codes draft. This version
contains the result of some discussion on the IANA procedures and some
editorial work to prepare this for a WGLC.
I'd appreciate inputs from those interested in the IANA procedures to
help determine if the
I've uploaded a draft agenda at:
https://datatracker.ietf.org/meeting/71/materials.html
If you are listed as a presenter and have not yet contacted the Chairs -
please email us as soon as possible:-)
If you have slides ready, then please do send them. (Please send by noon
Monday 10th at the
as an PROPOSED
STANDARD RFC.
Please *DO* forward any comments to the list. The document shepherd for
the process following completion of the WGLC shall be me, as the dccp
Co-Chair (Gorry Fairhurst).
Best wishes,
Gorry Tom
(DCCP WG Co-Chairs)
Rate Control (TFRC.bis) (Sally Floyd - Proxy, 5 min) - WGLC
Faster Restart (Sally Floyd - Proxy, 10 min)
DCCP CCID4: TFRC with Small Packets (Sally Floyd - Proxy, 10 min)
Gorry Fairhurst (me)
WG Chairs slides
Service Codes (Gorry Fairhurst, 15 min)
Michele (to be confirmed)
IANA Allocation
I understand that RFC3448 will be obsoleted by publication of this
documents. Implementors of TFRC need to carefully consider the new draft
within the last-call!
As for RFC4242 (CCID-3), the language in the RFC is clear:
3.1. Relationship with TFRC
The congestion control mechanisms
. This document is intended for publication as an PROPOSED
STANDARD RFC.
Please *DO* forward any comments to the list. The document shepherd for
the process following completion of the WGLC shall be me, as the dccp
Co-Chair (Gorry Fairhurst).
Best wishes,
Gorry Tom
(DCCP WG Co-Chairs)
Here is a reply to your much earlier email - which I think I forgot to
send. Sorry, I was doing several things at once and didn't reply earlier.
Thanks for your comments. I am going to prepare a new revision and post
a URL to cover the changes from your comments, the ones from the WG
meeting
I've just submitted draft-ietf-dccp-serv-codes-05.txt. This revision
incorporates feedback around the last DCCP WG meeting via the list and
meeting, and recent comments from Colin on the interim version:
Tom Phelan suggested clarification was needed for the usage of well-
known ports
This includes a copy of Gen-ART review comments for TFRC.bis,
Gorry
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
The authors have now completed a new version of this draft, and would
like to receive any comments that people may have.
Best wishes,
Gorry Arjuna
A new version of I-D, draft-fairhurst-tsvwg-dccp-qs-03.txt has been
successfuly submitted by Gorry Fairhurst and posted to the IETF repository
,
On 2008-6-20, at 16:07, ext Gorry Fairhurst wrote:
I received this email from Alfred (cc'ed above), who has kindly
allowed me to forward this to the dccp list. It asks about the use of
IPsec SPD's with DCCP Service Codes... an interesting question - do
others have ideas on how this should be handled
The current DCCP agenda is at:
http://www.ietf.org/proceedings/08jul/agenda/dccp.txt
Please could all people listed as speakers now confirm with the chairs
whether they will be present and wish to present (the chairs can also
arrange for slides to be presented, if they are sent ahead of the
We received the following helpful review comments from Michael Scharf,
as below. THANKS Michael!!!
Please see in-line our responses. We would appreciate any further
comments or questions people may have and then intend to produce a
revised document at the end of next week.
Best wishes,
We received the following helpful review comments from Michael Scharf,
as below. THANKS!!!
Please see in-line our responses. We would appreciate any further
comments or questions people may have and then intend to produce a
revised document at the end of next week.
Best wishes,
Gorry and
Scharf wrote:
Some minor comments inline
On Wed, 20 Aug 2008 at 17:01:10, Gorry Fairhurst wrote:
* Section 2.1: The term natural media rate is rather vague. For
VBR traffic, is it the average rate? Or the peak rate?
Good question, we intended to leave this open, but if you have suggestions
Eddie Kohler wrote:
My favorite thing in this new draft is the specific way you have
identified changes to RFC4340. Thanks!
Good to see I finally addressed that issue. Thanks for your feedback.
Detailed comments.
Service Codes allow a flexible correspondence between application-
.
Thanks,
Gorry
--
Dr Gorry Fairhurst, School of Engineering.
The University of Aberdeen is a charity registered in
Scotland No SC013683.
Phelan, Tom wrote:
Hi Gorry,
See inline for comments on comments :-). Sorry it took so long :-(.
Tom P.
[snipped]
I added a ref in 3.2:
NEW:
Network address and port translators, known collectively as NATs
[RFC2663], may interpret DCCP ports [RFC2993] [ID.Behave-DCCP].
I also updated
Thanks,
These all seem reasonable requests. I'm picking-up the editorial job
from Gerrit and will prepare a new rev. after we receive your comments
on 2.3 and following.
Gorry.
Phelan, Tom wrote:
Hi Gorry,
General comment
The need for this and the technical approach seem solid to me, but
Thanks for these comments.
Dan Wing wrote:
The introduction mentions that DCCP simultaneous open can
be disabled (turned
off). However, there is no further information regarding
this. Is there a
reason why a DCCP stack would want to disable this
functionality? As you
know, there is no
This draft looks good to me. I have a few comments on the DCCP aspects
of NAT traversal. (Some of these are editorial, a few were also noted
earlier but do not seem to have resulted in new text or discussion).
I look forward to seeing new text or feedback on these topics,
Best wishes,
Gorry
as a normative reference in
draft-ietf-behave-dccp-03.txt (now in LC).
Gorry Fairhurst
(as document author)
,
Gorry Fairhurst
(Co-Chair to DCCP)
---
Phelan, Tom wrote:
Hi All,
This is to announce the start of Working Group Last Call for
draft-ietf-dccp-simul-open-05 (see
http://www.ietf.org/internet-drafts/draft-ietf-dccp-simul-open-05.txt
for a copy). The last call will end on Friday, 14-Nov-2008.
Please
Thanks Magnus,
I think these are helpful comments, and include an initial response
below. Although the WGLC has now closed, I'd also like to encourage
anyone on the list to also send comments to the list before the WG meeting.
It seems useful to use some of the time at the DCCP meeting to
Thanks for your comments.
Please see responses in line,
Eddie Kohler wrote:
The document's basic outline seems fine. Using a new packet type for
this purpose seems fine. The document is not ready to publish yet,
because of a high typo load and lack of specificity in how packets are
Thanks Eddie, this is really valuable, more replies in-line.
Eddie Kohler wrote:
Gorry Fairhurst wrote:
- It is not reasonable to restrict Listen packets to carry no
options. A use may be found for Listen options one day. It suffices
to say that Listen packets are currently ignored
Drfat copies of the notes from the meeting in Minneapolis have been
uploaded to:
http://www.ietf.org/proceedings/08nov/minutes/dccp.txt
Thanks as ever to our note-taker and jabber scribe (and the audio
record). Please read and send any comments, questions, or corrections to
the WG list.
Dear WG,
The Last Call for WG comments has now concluded, and I'd like to offer
up a new interim revision of the simultaneous-open draft, to replace
draft-ietf-dccp-simul-open-05. Please check this is correct and that
this addresses all issues.
The new text is available here:
Thanks Magnus,
Please see my comments in-line.
Gorry
Magnus Westerlund wrote:
Hi,
Some comments on the new draft:
Section 2.2.1: One of the bullets is missing an a to read At the time
...
Will be fixed.
Figure 2: Is the figure really correct with the listen' state. Does it
really take
Thanks Tom,
I will read and update the draft, and get back on any comments that I
can't see how to easily implement.
Gorry
Phelan, Tom wrote:
Hi Gorry,
See http://www.phelan-4.com/dccp/simul-open-06-tp-comments.pdf for
suggested text changes, questions and comments. Changes from your -06
This email is pleased to announce a new revision of the Quick-Start
spec. for DCCP. This draft follows a detailed review by the authors, as
well as inputs from several people in this and TSV groups. There are
many changes to the text - but very little change to the protocol
specification
wishes,
Gorry Fairhurst
(DCCP Co-Chair)
Authors, WG,
Here are my comments on CCID-4 rev 0-02,
http://tools.ietf.org/html/draft-ietf-dccp-ccid4-02
Best wishes,
Gorry
Overall:
- The document will need revised boiler plate to address new IETF rules
for I-D submission.
Abstract:
- It's good to say also that this
Sally,
This is great, many thanks. I am pleased to see this is again
progressing, and suggest we put this on the agenda for the DCCP meeting
in San Francisco.
I hope we can upload this soon after the I-D archives re-open on
2009-03-24. I have some comments below.
Best wishes,
Gorry
---
74th IETF Meeting
San Francisco, CA
March 22-27, 2009
Host: Juniper
Early-Bird registration cutoff is tomorrow, Friday, March 13 at 17:00 PT
(24:00 UTC). After that time, the registration fee will increase by $150
USD to $785 USD.
Online registration for the IETF meeting is at:
Dear DCCP WG,
Please note that our session in San Francisco has been re-scheduled for
1740-1940. Unless there is a lot of feedback and discussion (which may
be good), I expect that we will not use all our allocated time.
I'll send an email next week on the agenda items. Please do join us on
Thanks Sally,
As arjuna said, we appreciate your review and Vincent's review.
All you comments were useful. Here are our proposed updates to the draft
text.
Gorry Arjuna
Sally Floyd wrote:
Gorry and Arjuna -
This looks fine to me.
One sentence needs to be corrected:
Section 2.4 says
Chair: Gorry Fairhurst
Notetaker: Pasi Sarolahti
1. Agenda Bashing
* Sally Floyd: I haven not been to IETF for a while. I see that there
are not many people in the WG, does this mean that DCCP is going to be
dormant?
* Gorry: Many of the documents on our charter
. This last call will end on midnight UTC on 16th April 2009
(allowing a few extra days for those traveling home from the IETF). If
you would like to review this, but may need extra time, please contact
me as soon as possible.
Gorry Fairhurst
(DCCP Co-Chair)
David,
Many thanks for you review comments. These were all useful and have
resulted in the changes below. I am preparing an updated I-D rev -09 to
include these changes.
---
Section 3.2: Middlebox [RFC3234] implementors therefore need to note
that new DCCP connections are identified by the
,
--David
-Original Message-
From: Gorry Fairhurst [mailto:go...@erg.abdn.ac.uk]
Sent: Monday, April 27, 2009 4:08 PM
To: Black, David
Cc: hous...@vigilsec.com; tphe...@sonusnet.com;
lars.egg...@nokia.com; dccp@ietf.org
Subject: Re: Gen-ART review of draft-ietf-dccp-serv-codes-08
David
Authors, WG,
This note closes the IETF DCCP WGLC on CCID 4. During the LC, comments
were received from Arjuna (below) and to this I would also like to add
the following two comments. Please could the authors now issue a revised
ID to address these issues?
Best wishes,
Gorry Fairhurst
DCCP
Thanks for this review, it is much appreciated. All these comments are
valid, and I have made the corrections in my copy of the draft. I plan
to issue a new revision on conclusion of the Last Call.
Best wishes,
Gorry
Miguel A. Garcia wrote:
I have been selected as the General Area Review
the following two comments. Please could the authors now issue a
revised ID to address these issues?
Thanks, I made the changes suggested by Arjuna.
Best wishes,
Gorry Fairhurst
DCCP Chair
---
Comments from WG Chair:
1) During the WG in San Francisco, the WG talked about whether the
dependency
1 - 100 of 130 matches
Mail list logo
