headers
Phelan, Tom | 4 Aug 2008 18:12
Favicon

FW: Please ask your WG...

Hi All,

On request of the nomcom chair, please consider volunteering for the
nomcom.  See the message below.

Tom P.

-----Original Message-----
From: wgchairs-bounces <at> ietf.org [mailto:wgchairs-bounces <at> ietf.org] On
Behalf Of NomCom Chair
Sent: Sunday, August 03, 2008 10:43 AM
To: Working Group Chairs
Subject: Please ask your WG... 

To volunteer for the nomcom.
The nomcom process is (in my opinion) better served by a large pool of
volunteers drawn from a wide spectrum of IETF attendees.
As such, please ask on your individual mailing lists for folks to
volunteer.

Obviously, the exact method for doing so is up to you.
The most recent call for volunteers can be reference here:
    https://datatracker.ietf.org/public/show_nomcom_message.cgi?id=1617
Whether you copy that message, or reference is probably up to you and
the
habits of your working group mailing list.
If you want to reference or copy the status message I sent out, that can
be found at:
    https://datatracker.ietf.org/public/show_nomcom_message.cgi?id=1618
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dan Wing | 8 Aug 2008 03:24
Picon
Favicon

WGLC: draft-ietf-behave-dccp-01

Behave is commencing a 2-week WGLC for "Network Address Translation (NAT)
Behavioral Requirements for DCCP",
<http://tools.ietf.org/html/draft-ietf-behave-dccp-01>.  The WGLC will end on
August 21.

Please send comments to the author and to Behave.

-d
Permalink | Reply | 5 comments |
headers
Phelan, Tom | 8 Aug 2008 16:28
Favicon

Re: WGLC: draft-ietf-behave-dccp-01

Hi Remi,

Here are some comments.

Tom P.

Section 4.3:

"o  The filtering behavior for DCCP MAY be independent of the filtering
behavior for UDP."

Shouldn't that be "for UDP or any other protocol" or something similar.
Certainly it's acceptable for the DCCP filtering behavior to be
independent of TCP...

"REQ-4: A NAT MUST NOT respond to an unsolicited inbound DCCP-Listen
packet for at least 6 seconds after the packet is received."

What does "not respond" mean?  Not send the ICMP message? Not forward
the DCCP-Listen packet?  Both?  Maybe this could be clearer if it's
reworded in a positive vein -- "Upon receiving a DCCP-Listen packet a
NAT MUST..."

Section 5, REQ-5:

Is this saying that the "established connection idle timeout" cannot be
configured to be less than 2 hours 40 minutes?  I see this language is
stolen directly from behave-tcp, but I find it confusing.

Section 6:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Phelan, Tom | 12 Aug 2008 15:05
Favicon

Re: Review of draft-ietf-dccp-quickstart-00.txt

Hi Michael,

Thanks for the comments -- just what we need :-).

Tom P.

> -----Original Message-----
> From: Michael Scharf [mailto:michael.scharf <at> ikr.uni-stuttgart.de]
> Sent: Monday, August 11, 2008 2:32 PM
> To: Gorry Fairhurst; Phelan, Tom
> Cc: Arjuna Sathiaseelan
> Subject: Review of draft-ietf-dccp-quickstart-00.txt
> 
> Hi all,
> 
> I've been asked to have a look at "draft-ietf-dccp-quickstart-00.txt"
> and to provide feedback. But first, I'd like to state to two things
> up-front:
> 
>   * I am quite familiar with Quick-Start TCP (we have running code for
>     the Linux ), but, unfortunately, I'm not a DCCP expert. Thus, this
>     might be a somewhat TCP-biased review.
> 
>   * I'm not subscribed to the dccp mailinglist. Therefore, any
>     questions should be CC'ed to me. Please feel free to forward this
>     e-mail to the WG mailing list if desired.
> 
> 
> Summary:
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Gorry Fairhurst | 20 Aug 2008 23:19
Picon
Picon

Re: Review of draft-ietf-dccp-quickstart-00.txt


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,

Gorry and Arjuna

He wrote:
 > Hi all,
 >
 > I've been asked to have a look at "draft-ietf-dccp-quickstart-00.txt"
 > and to provide feedback. But first, I'd like to state to two things
 > up-front:
 >
 >   * I am quite familiar with Quick-Start TCP (we have running code for
 >     the Linux ), but, unfortunately, I'm not a DCCP expert. Thus, this
 >     might be a somewhat TCP-biased review.
 >
 >   * I'm not subscribed to the dccp mailinglist. Therefore, any
 >     questions should be CC'ed to me. Please feel free to forward this
 >     e-mail to the WG mailing list if desired.
 >
 >
 > Summary:
 >
(Continue reading)

Permalink | Reply | 0 comments |
headers
Gorry Fairhurst | 20 Aug 2008 18:01
Picon
Picon

Re: Review of draft-ietf-dccp-quickstart-00.txt

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 Arjuna

He wrote:
> Hi all,
> 
> I've been asked to have a look at "draft-ietf-dccp-quickstart-00.txt"
> and to provide feedback. But first, I'd like to state to two things
> up-front:
> 
>   * I am quite familiar with Quick-Start TCP (we have running code for
>     the Linux ), but, unfortunately, I'm not a DCCP expert. Thus, this
>     might be a somewhat TCP-biased review.
> 
>   * I'm not subscribed to the dccp mailinglist. Therefore, any
>     questions should be CC'ed to me. Please feel free to forward this
>     e-mail to the WG mailing list if desired.
> 
> 
> Summary:
> 
>   I've read the draft and think that it is a sound specification of
(Continue reading)

Permalink | Reply | 0 comments |
headers
Gorry Fairhurst | 21 Aug 2008 08:36
Picon
Picon

Fwd: Review of draft-ietf-dccp-quickstart-00.txt


The authors 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,

Gorry and Arjuna

He wrote:
> Hi all,
>
> I've been asked to have a look at "draft-ietf-dccp-quickstart-00.txt"
> and to provide feedback. But first, I'd like to state to two things
> up-front:
>
>   * I am quite familiar with Quick-Start TCP (we have running code for
>     the Linux ), but, unfortunately, I'm not a DCCP expert. Thus, this
>     might be a somewhat TCP-biased review.
>
>   * I'm not subscribed to the dccp mailinglist. Therefore, any
>     questions should be CC'ed to me. Please feel free to forward this
>     e-mail to the WG mailing list if desired.
>
>
> Summary:
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Gorry Fairhurst | 22 Aug 2008 15:27
Picon
Picon

Re: Review of draft-ietf-dccp-quickstart-00.txt


Tom - could you forward this and the previous mails to the dccp list 
(the IETF mail server is bouncing me due to a local DNS problem, which 
has just been fixed but may taked a week to reach all DNS caches!)

Gorry

---

Michael, see some new suggestions in-line from Arjuna and me:

Michael 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 
>> that would be interesting. Note though that the QS_rate is rather course, 
>> and so this may not be a significant issue.,
> 
> Wouldn't it be worth to just mention this rough granularity somewhere
> in the text? I mean, the rate to request for is an important aspect
> for a user of Quick-Start, and some guidance on its choice would be
> nice - even if the message is finally: "don't worry too much about
> it".
> 
OLD:
    For
(Continue reading)

Permalink | Reply | 0 comments |
headers
Phelan, Tom | 25 Aug 2008 15:43
Favicon

Working group last call for service codes

Hi All,

This is to announce the beginning of working group last call for "The
DCCP Service Code", draft-ietf-dccp-serv-codes-06.txt (see
http://www.ietf.org/internet-drafts/draft-ietf-dccp-serv-codes-06.txt).
Last call will run for two weeks, ending Monday, 8-Sep.

Please send detailed comments to the list.  Also, bare "I support" or "I
don't support" e-mails are quite useful.

Tom P.
Permalink | Reply | 10 comments |
headers
Eddie Kohler | 25 Aug 2008 17:48
Favicon

Re: Working group last call for service codes

My favorite thing in this new draft is the specific way you have identified 
changes to RFC4340.  Thanks!

Detailed comments.

    Service Codes allow a flexible correspondence between application-
    layer services and server port numbers, which affects how
    applications interact with DCCP. This decouples the use of ports for
    connection demultiplexing and state management from their use to
    indicate a desired service. An application identifies the requested
    service by the Service Code value in a DCCP-Request packet. Each
    application may listen on one or more ports associated with one or
    more Service Codes ([RFC4340], section 8.1.2).

=> This goes too far and may confuse readers.  Remember that ports are still 
primary.  Prefer:

    Service Codes allow applications to declare exactly which services
    are associated with server port numbers.  This can affects how
    applications interact with DCCP. ... Each application specifies
    one or more Service Codes for each listening port ([RFC4340], section
    8.1.2).

Do not capitalize Middleboxes except at the beginning of a sentence.

"Middleboxes that desire to identify the type of data being transported by a 
flow," => prefer "the type of data a flow claims to transport."  Since 
middleboxes can't, of course, trust the service code.  But you do make this 
clearer later on.
(Continue reading)

Permalink | Reply | 3 comments |

Gmane