headers
Adhari, Hakim | 1 Oct 2011 10:51
Picon
Favicon

Deadline Extension: PAMS 2012 -- 2nd International Workshop on Protocols and Applications with Multi-Homing Support

 (Our apologies if you receive multiple copies of this CfP)

=================

Please consider to contribute to and/or forward to the appropriate groups the following opportunity to
submit and publish original scientific results to PAMS 2012.

The submission deadline has been extended to October 16, 2011.

=================

============== CALL FOR PAPERS ===============

2nd International Workshop on Protocols and Applications with Multi-Homing Support (PAMS 2012) In
conjunction with the 26th IEEE International Conference on Advanced Information Networkingand
Applications (AINA 2012) Fukuoka, Japan, March 26-29, 2012 http://tdrwww.iem.uni-due.de/pams2012.html

The intent of our workshop is to bring together people from research and industry, in order to provide a
discussion forum for state-of-the-art topics related to multi-homing on Network, Transport, Session
and Application Layers.
The PAMS workshop will include full-paper sessions as well as a poster session (with short presentations)
to introduce preliminary ideas as well as work in progress.

Workshops proceedings will be published by the IEEE CS Conference Publishing Service and will be included
in the Digital Library.

The main topics to be addressed include (but are not limited to):

    * Network Resilience by Multi-Homing
    * Network Architectures for Multi-Homed Systems
(Continue reading)

Permalink | Reply | 0 comments |
headers
Gorry Fairhurst | 6 Oct 2011 14:42
Picon
Picon

New TSVWG draft: Generic Aggregation of RSVP Reservations over PCN domains


The following draft is approved as a TSVWG work item:

"Generic Aggregation of Resource ReSerVation Protocol (RSVP)
for IPv4 And IPv6 Reservations over PCN domains"
http://tools.ietf.org/html/draft-karagiannis-pcn-tsvwg-rsvp-pcn-01

Authors, please upload a new revision of this draft as:
draft-ietf-tsvwg-rsvp-pcn-00

This draft has the support of the PCN working group and was discussed in 
TSVWG at IETF-81. Since this meeting, the Transport Area ADs have added 
the following milestone to our charter:

"May 2012 - Submit Encoding and Transport of (Pre-) Congestion 
Information from the Domain Egress to the Ingress to the IESG for 
consideration as a Proposed Standard RFC."

Best wishes,

Gorry & James.
Permalink | Reply | 1 comment |
headers
Georgios Karagiannis | 8 Oct 2011 10:22
Picon
Picon
Picon

Re: New TSVWG draft: Generic Aggregation of RSVP Reservations over PCN domains

Hi Gorry, Hi James,

Thanks, I have just submitted the draft:

draft-ietf-tsvwg-rsvp-pcn-00

Best regards,
Georgios

On 10/6/2011, "Gorry Fairhurst" <gorry <at> erg.abdn.ac.uk> wrote:

>
>The following draft is approved as a TSVWG work item:
>
>"Generic Aggregation of Resource ReSerVation Protocol (RSVP)
>for IPv4 And IPv6 Reservations over PCN domains"
>http://tools.ietf.org/html/draft-karagiannis-pcn-tsvwg-rsvp-pcn-01
>
>Authors, please upload a new revision of this draft as:
>draft-ietf-tsvwg-rsvp-pcn-00
>
>This draft has the support of the PCN working group and was discussed in
>TSVWG at IETF-81. Since this meeting, the Transport Area ADs have added
>the following milestone to our charter:
>
>"May 2012 - Submit Encoding and Transport of (Pre-) Congestion
>Information from the Domain Egress to the Ingress to the IESG for
>consideration as a Proposed Standard RFC."
>
>Best wishes,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michael Tuexen | 11 Oct 2011 08:32
Picon

Re: I-D Action: draft-ietf-tsvwg-sctpsocket-32.txt

On Oct 11, 2011, at 8:11 AM, internet-drafts <at> ietf.org wrote:

> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work
item of the Transport Area Working Group Working Group of the IETF.
> 
> 	Title           : Sockets API Extensions for Stream Control Transmission Protocol (SCTP)
> 	Author(s)       : Randall R. Stewart
>                          Michael Tuexen
>                          Kacheong Poon
>                          Peter Lei
>                          Vladislav Yasevich
> 	Filename        : draft-ietf-tsvwg-sctpsocket-32.txt
> 	Pages           : 113
> 	Date            : 2011-10-10
> 
>   This document describes a mapping of the Stream Control Transmission
>   Protocol (SCTP) into a sockets API.  The benefits of this mapping
>   include compatibility for TCP applications, access to new SCTP
>   features and a consolidated error and event notification scheme.
> 
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-sctpsocket-32.txt
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> This Internet-Draft can be retrieved at:
> ftp://ftp.ietf.org/internet-drafts/draft-ietf-tsvwg-sctpsocket-32.txt
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Gorry Fairhurst | 18 Oct 2011 13:22
Picon
Picon

WGLC Announcement for draft-ietf-tsvwg-source-quench - 18th October 2011


This email announces the start of a working group last call for
draft-ietf-tsvwg-source-quench-02.txt, "Deprecation of ICMP Source 
Quench messages". This document is now thought to be ready
to proceed to be published as a PS. Please send any comments to the
TSVWG list.

The draft is available at:
http://www.ietf.org/id/draft-ietf-tsvwg-source-quench-02.txt

The last call will run for TWO weeks, ending Wednesday 9th October 2011 
2011.

Emails saying "I support" or "I don't support" publication are also most 
helpful in judging the WG consensus. Please let us know if this draft is 
useful and seems to provide the correct advice.

James and Gorry
(TSVWG Chairs)
Permalink | Reply | 34 comments |
headers
Scott O. Bradner | 18 Oct 2011 14:05
Picon
Favicon

Re: WGLC Announcement for draft-ietf-tsvwg-source-quench - 18th October 2011,


why does section 6 use SHOULD rather than MUST?

seems to me that there are no known cases where any transport protocol
should ever respond to a Source Quench

Scott
Permalink | Reply | 7 comments |
headers
Joe Touch | 18 Oct 2011 23:20
Picon
Favicon

Re: WGLC Announcement for draft-ietf-tsvwg-source-quench - 18th October 2011,

I had suggested:

MUST ignore

SHOULD NOT send

The latter is weaker because there is no impact if a message is sent. However, I do prefer use of SHOULD only
with at least one known exception provided, or at least a clear metric to know when the exception is
appropriate. 

In this case SHOULD should not be driven by legacy cases. 

Joe

On Oct 18, 2011, at 5:05 AM, sob <at> harvard.edu (Scott O. Bradner) wrote:

> 
> why does section 6 use SHOULD rather than MUST?
> 
> seems to me that there are no known cases where any transport protocol
> should ever respond to a Source Quench
> 
> Scott
Permalink | Reply | 6 comments |
headers
Fernando Gont | 20 Oct 2011 17:09
Picon
Favicon

Re: WGLC Announcement for draft-ietf-tsvwg-source-quench - 18th October 2011,

Hi, Joe,

Thanks for your input! Please find my comments inline...

On 10/18/2011 06:20 PM, Joe Touch wrote:
> I had suggested:
> 
> MUST ignore
> 
> SHOULD NOT send
> 
> The latter is weaker because there is no impact if a message is sent.

Is there any valid reason *for* sending SQs?

My understanding of Scott's point is that the motivation for a "SHOULD
NOT" rather than "MUST NOT" should be that there are exceptions under
which it could make sense to behave in a different way (rather than
whether there may be a negative impact if the advise is not followed).

So I'd agree with Scott that this should be "MUST NOT send, MUST ignore
if received".

Thoughts?

Thanks!

Best regards,
--

-- 
Fernando Gont
(Continue reading)

Permalink | Reply | 5 comments |
headers
Joe Touch | 20 Oct 2011 19:25
Picon
Favicon

Re: WGLC Announcement for draft-ietf-tsvwg-source-quench - 18th October 2011,

Hi, Fernando,

My view:

- the doc needs MUST ignore on receipt

Anything beyond that isn't needed. If it's ignored, there's no point in 
sending it, but it does no harm.

I would prefer to not even make a statement about whether to send it.

A MUST NOT send could be (mis)interpreted as an opportunity for (yet 
another) needless suggestion that it should be interpreted as either an 
attack or a formal error worth reporting.

Joe

On 10/20/2011 8:09 AM, Fernando Gont wrote:
> Hi, Joe,
>
> Thanks for your input! Please find my comments inline...
>
> On 10/18/2011 06:20 PM, Joe Touch wrote:
>> I had suggested:
>>
>> MUST ignore
>>
>> SHOULD NOT send
>>
>> The latter is weaker because there is no impact if a message is sent.
(Continue reading)

Permalink | Reply | 4 comments |
headers
Gorry Fairhurst | 20 Oct 2011 21:51
Picon
Picon

Re: WGLC Announcement for draft-ietf-tsvwg-source-quench - 18th October 2011,

On 20/10/2011 18:25, Joe Touch wrote:
> Hi, Fernando,
>
> My view:
>
> - the doc needs MUST ignore on receipt
>
> Anything beyond that isn't needed. If it's ignored, there's no point in
> sending it, but it does no harm.
>
> I would prefer to not even make a statement about whether to send it.
>
> A MUST NOT send could be (mis)interpreted as an opportunity for (yet
> another) needless suggestion that it should be interpreted as either an
> attack or a formal error worth reporting.
>
> Joe
>
> On 10/20/2011 8:09 AM, Fernando Gont wrote:
>> Hi, Joe,
>>
>> Thanks for your input! Please find my comments inline...
>>
>> On 10/18/2011 06:20 PM, Joe Touch wrote:
>>> I had suggested:
>>>
>>> MUST ignore
>>>
>>> SHOULD NOT send
>>>
(Continue reading)

Permalink | Reply | 3 comments |

Gmane