[Iccrg] Re: Request to publish draft-irtf-iccrg-welzl-congestion-control-open-research-08

[michawe]

Hi,

The typical notice is fine with all of us authors, the "no derivatives" clause is not needed.

Thanks,

best,
Michael Welzl


On Jan 3, 2011, at 11:46 PM, RFC Editor wrote:

> Greetings All,
> 
> We are preparing to move
> draft-irtf-iccrg-welzl-congestion-control-open-research-08 to AUTH48.
> However, please clarify whether the "no derivatives" clause is
> required for this document.  We note that the Internet-Draft included
> the 6.c.iii paragraph from the Trust License Provisions, which (to our
> understanding) is not applicable to alternate stream publications.
> Please let us know which copyright statement should be applied to this
> document:  
> 
> *Copyright Notice (typical notice for alternate streams)
> 
> Copyright (c) 2010 IETF Trust and the persons identified as
> the document authors.  All rights reserved.
> 
> This document is subject to BCP 78 and the IETF Trust's Legal
> Provisions Relating to IETF Documents
> (http://trustee.ietf.org/license-info) in effect on the date of
> publication of this document.  Please review these documents
> carefully, as they describe your rights and restrictions with respect
> to this document. 
> 
> 
> *Copyright Notice (no derivative works)
> 
> Copyright (c) 2010 IETF Trust and the persons identified as
> the document authors.  All rights reserved.
> 
> This document is subject to BCP 78 and the IETF Trust's Legal
> Provisions Relating to IETF Documents
> (http://trustee.ietf.org/license-info) in effect on the date of
> publication of this document.  Please review these documents
> carefully, as they describe your rights and restrictions with respect
> to this document. 
> 
> This document may not be modified, and derivative works of it may not
> be created, except to format it for publication as an RFC or to
> translate it into languages other than English.
> 
> Please see http://trustee.ietf.org/license-info/ for more
> information.  
> 
> We will wait to hear from you before moving forward.
> 
> Thanks,
> RFC Editor/sg
> 
> 
> 
> 
> On Fri, Oct 01, 2010 at 03:29:44PM +0200, Aaron Falk wrote:
>> RFC Editor-
>> 
>> Please publish draft-irtf-iccrg-welzl-congestion-control-open-research-08 as an Informational IRTF RFC. The document has been approved for publication by the IRSG and also reviewed for IETF conflict by the IESG. See http://trac.tools.ietf.org/group/irtf/trac/ticket/29 for details on the IESG and prior reviews. Please copy all correspondence to the document shepherd, Wesley Eddy,  weddy at grc.nasa.gov.
>> 
>> The authors would like to have a few edits made as described by the message below.
>> 
>> --aaron
>> 
>> ---
>> Aaron Falk
>> Chair
>> Internet Research Task Force
>> http://www.irtf.org
>> 
>> 
>> 
>> 
>> On 9/29/10 5:43 PM, Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] wrote:
>>> Hi Aaron, the ICCRG document on open research issues in
>>> Internet congestion control has been through the IESG's
>>> review and is now ready for submission to the RFC Editor.
>>> 
>>> The authors and IESG agreed on the following request to
>>> the RFC Editor for modification of the draft prior to
>>> publication as an RFC (which they would like the RFC
>>> Editor to handle, rather than submit another revision):
>>> 
>>> RFC Editor Note
>>> 
>>> (1) Replace beginning of Section 3.5.3 with:
>>> 
>>>  3.5.3 Inelastic Multi-domain Pseudowires
>>> 
>>>  Extending pseudo-wires across multiple domains poses specific issues.
>>>  Pseudowires (PW) [RFC3985] may carry non-TCP data flows (e.g. TDM
>>>  traffic or Constant Bit Rate (CBR) ATM traffic) over a multi-domain 
>>>  IP network. Structure Agnostic TDM over Packet (SATOP) [RFC4553], 
>>>  Circuit Emulation over Packet Switched Networks (CESoPSN), TDM over 
>>>  IP, are not responsive to congestion control as discussed by
>>>  [RFC2914] (see also [RFC5033]). The same observation applies to ATM 
>>>  circuit emulating services (CES) interconnecting CBR equipment (e.g. 
>>>  PBX) across a Packet Switched Network (PSN).
>>> 
>>>  Moreover, it is not possible to simply reduce the flow rate of a TDM
>>>  PW or an ATM PW when facing packet loss. Providers can rate control 
>>>  corresponding incoming traffic but they may not be able to detect 
>>>  that PWs carry TDM or CBR ATM traffic (mechanisms for characterizing 
>>>  the traffic temporal properties may not necessarily be supported). 
>>> 
>>>  This can be illustrated with the following example. 
>>> 
>>> 
>>> (2) Add at the end of Section 3.8.4 Congestion Control in Multi-layered Networks
>>> 
>>>  Section 3.5.3 deals with Inelastic Multi-domain Pseudowires (PW), 
>>>  where the characteristics of the Pseudowire itself determines the 
>>>  characteristics of the traffic crossing the multi-domain PSN 
>>>  (and this independently of the characteristics of the traffic 
>>>  carried in the PW). A more complex situation arises when inelastic 
>>>  traffic is carried as part of a Pseudowire (e.g. inelastic traffic 
>>>  over Ethernet PW over PSN) whose edges do not have the means to 
>>>  characterize the properties of the traffic encapsulated into the
>>>  Ethernet frames. In this case, the problem explained in 
>>>  Section 3.5.3 is not limited to multi-domain Pseudowires but more 
>>>  generally induced by "Pseudowire carrying inelastic traffic" (over 
>>>  a single- or multi-domain PSN). The problem becomes even more
>>>  intricate when the Ethernet PW carries both inelastic and 
>>>  elastic traffic. Addressing this issue further comforts our 
>>>  observation that a general framework to efficiently deal with 
>>>  congestion control problems in multi-layer networks is absolutely
>>>  necessary but without harming its evolvability.
>>> 
>>> --
>>> Wes Eddy
>>> MTI Systems
>>> 
>>> 
>>>