From nobody Sun Apr 2 23:35:10 2017 Return-Path: X-Original-To: avt@ietf.org Delivered-To: avt@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D6420129568; Sun, 2 Apr 2017 23:35:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: avt@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149120130883.4340.8657178335007558252@ietfa.amsl.com> Date: Sun, 02 Apr 2017 23:35:08 -0700 Archived-At: Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-rfc5285-bis-09.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.22 List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 06:35:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Core Maintenance of the IETF. Title : A General Mechanism for RTP Header Extensions Authors : David Singer Harikishan Desineni Roni Even Filename : draft-ietf-avtcore-rfc5285-bis-09.txt Pages : 22 Date : 2017-04-02 Abstract: This document provides a general mechanism to use the header extension feature of RTP (the Real-Time Transport Protocol). It provides the option to use a small number of small extensions in each RTP packet, where the universe of possible extensions is large and registration is de-centralized. The actual extensions in use in a session are signaled in the setup information for that session. This document obsoletes RFC5285. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtcore-rfc5285-bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-avtcore-rfc5285-bis-09 https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rfc5285-bis-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-avtcore-rfc5285-bis-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Apr 6 15:07:37 2017 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85B561294A8; Thu, 6 Apr 2017 15:07:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vgnyGpqd2BYw; Thu, 6 Apr 2017 15:07:33 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E91612945E; Thu, 6 Apr 2017 15:07:33 -0700 (PDT) Received: from [10.0.1.63] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v36M7VKe090708 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 6 Apr 2017 17:07:32 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.63] From: "Ben Campbell" To: draft-ietf-avtcore-rfc5285-bis.all@ietf.org, "IETF AVTCore WG" Date: Thu, 06 Apr 2017 17:07:31 -0500 Message-ID: References: <149120130883.4340.8657178335007558252@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5347) Archived-At: Subject: [AVTCORE] Fwd: I-D Action: draft-ietf-avtcore-rfc5285-bis-09.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 22:07:36 -0000 Hi, I think this version is ready for IETF Last Call. I will request it shortly. Thanks! Ben. Forwarded message: > From: internet-drafts@ietf.org > To: i-d-announce@ietf.org > Cc: avt@ietf.org > Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-rfc5285-bis-09.txt > Date: Sun, 02 Apr 2017 23:35:08 -0700 > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Audio/Video Transport Core > Maintenance of the IETF. > > Title : A General Mechanism for RTP Header > Extensions > Authors : David Singer > Harikishan Desineni > Roni Even > Filename : draft-ietf-avtcore-rfc5285-bis-09.txt > Pages : 22 > Date : 2017-04-02 > > Abstract: > This document provides a general mechanism to use the header > extension feature of RTP (the Real-Time Transport Protocol). It > provides the option to use a small number of small extensions in > each > RTP packet, where the universe of possible extensions is large and > registration is de-centralized. The actual extensions in use in a > session are signaled in the setup information for that session. > This > document obsoletes RFC5285. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-avtcore-rfc5285-bis/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-avtcore-rfc5285-bis-09 > https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rfc5285-bis-09 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-avtcore-rfc5285-bis-09 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt From nobody Thu Apr 6 15:36:08 2017 Return-Path: X-Original-To: avt@ietf.org Delivered-To: avt@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AA52A129687; Thu, 6 Apr 2017 15:36:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk CC: avtcore-chairs@ietf.org, ben@nostrum.com, magnus.westerlund@ericsson.com, draft-ietf-avtcore-rfc5285-bis@ietf.org, avt@ietf.org, Magnus Westerlund Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <149151816060.21907.16803316102326405811.idtracker@ietfa.amsl.com> Date: Thu, 06 Apr 2017 15:36:00 -0700 Archived-At: Subject: [AVTCORE] Last Call: (A General Mechanism for RTP Header Extensions) to Proposed Standard X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.22 List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 22:36:01 -0000 The IESG has received a request from the Audio/Video Transport Core Maintenance WG (avtcore) to consider the following document: - 'A General Mechanism for RTP Header Extensions' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2017-04-20. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document provides a general mechanism to use the header extension feature of RTP (the Real-Time Transport Protocol). It provides the option to use a small number of small extensions in each RTP packet, where the universe of possible extensions is large and registration is de-centralized. The actual extensions in use in a session are signaled in the setup information for that session. This document obsoletes RFC5285. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-avtcore-rfc5285-bis/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-avtcore-rfc5285-bis/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Fri Apr 7 14:49:47 2017 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79E70127871 for ; Fri, 7 Apr 2017 14:49:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jeAjGa7u6bv3 for ; Fri, 7 Apr 2017 14:49:35 -0700 (PDT) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26D3D127097 for ; Fri, 7 Apr 2017 14:49:35 -0700 (PDT) Received: by mail-qk0-x22e.google.com with SMTP id h67so73982051qke.0 for ; Fri, 07 Apr 2017 14:49:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=caReqXfm1xzl+3X99oqp5s/RlHer4kPqs7m/yaVnl60=; b=sXwLI5ea5kaK/PLKdjFlhwpFILxeEnywnuWzPBmmfbMhyd+9QMMfxPN61tTAn+cVpi wQvgiye9Y5SNi7NT6v4foCd8n4AvioTM/kgiBKOK8gqTYnhM61Psz5U7HtJmkBz7H714 UPN4j5feRKeXSE25nSkvCIXjZihYbkh5z0EcKI/A8A8QA908p2TuZhyVQrYi7rf+FV0T N532aouAnyM7BKLvtyTJ2kBc2vw2OsjgSWuiM692lqXoaYRVnKYzo33PNdSdIWAB7gVo GpiGQtGxisCs3M7br+3QjuvGOh8NnKHJZFXaZO1fvL+o9gfrRnr5Att6+I/S24ORdWix 5b+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=caReqXfm1xzl+3X99oqp5s/RlHer4kPqs7m/yaVnl60=; b=FpWGCCZ+XIIhtYLAs48H36fFzX9z70oHPDvrfK8sfppkeUUr5zl+FRUyR4i+D6Mx17 v36ozewlDkv9jbDhXIv4qIzxKuacqs1ZSHAxdCxIZwHuBLXRI8/MubGpQQdLJgMPfmGs BtwG297lvxkv/3HhX9WAcZK423b+16FKsoZf+SQrbWGJs9SNAN2cRNsLwo5D/NJ/PqxI oaho/GAJC8nUrRooxqncDOgdLV0SMm4xx8KkNLBEWySwrLTdpNp6V2L3COZ/ClFPOJlQ b0vuBKZmkfpkuMRpssLfzkdWKAnrhCaZWj0YbIjq4CMDHbDcXnRSWLiRKIaveiZcGbEN 2eag== X-Gm-Message-State: AN3rC/5E2drHK2K8N2OA+dA9UlhDQSLhFgluQuzvZEUW4zp8bQblidaXjOoAgYNCEc7SK6rrkD3gIkmom2qGGA== X-Received: by 10.55.159.136 with SMTP id i130mr12793517qke.94.1491601773865; Fri, 07 Apr 2017 14:49:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.54.2 with HTTP; Fri, 7 Apr 2017 14:49:03 -0700 (PDT) From: Ted Hardie Date: Fri, 7 Apr 2017 14:49:03 -0700 Message-ID: To: avt@ietf.org, jonathan Content-Type: multipart/alternative; boundary=001a114d8db6e0b146054c9a996d Archived-At: Subject: [AVTCORE] draft-ietf-avtcore-mprtp-03 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 21:49:41 -0000 --001a114d8db6e0b146054c9a996d Content-Type: text/plain; charset=UTF-8 Howdy, I was asked to review this draft in Chicago; sorry for not getting to it sooner. First, the security considerations seem to be TBD entirely, which seems surprising. I was particularly interested to see how this draft would tackle linkability, since it is an ongoing discussion in other groups (e.g. QUIC). I think that the security considerations, when written, need to tackle both linkability (the ability of an observer to cross-correlate traffic on two different paths as belonging to the same endpoint) and consent freshness. Second, I believe this requirement: Multipath RTP (MPRTP) MUST be backwards compatible; an MPRTP Stream needs to fall back to be compatible with legacy RTP stacks if MPRTP support is not successfully negotiated. may need re-wording. I initially misread this team that MPRTP would appear to be non-multipath RTP if the MPRTP support were not available (following what was said about NAT bindings); it seems you mean instead that an MPRTP stack must fall back to non-multipath RTP. Clarifying this would be useful. On the use cases, the use case for fault tolerance has some very simple applications that I have seen proposed in the past. In one case, ambulance telemetry was sent over multiple cellular networks--there, full duplication was appropriate and the receiver simply threw away any information already received from a different interface. Load balancing applications are harder, and I believe the draft may want to explicitly consider how differential packet traversal times across different paths will impact the number of applications that can use this. If I understand this correctly, a system with a playout buffer would be able to interleave RTP packets from different subflows successfully. A system without such a buffer or with one too small for late arrivals will end up losing information. There are ways to get around this, but the document does not go into them in detail. Will they be covered by later documents? Also, the document says: In contrast to RTCP, SDP offers a reliable communication channel so that no separate retransmissions logic is necessary. In SDP, especially when combined with ICE, connectivity check mechanisms including sophisticated rules are readily available. While SDP is not inherently protected, suitable security may need to be applied anyway to the basic session setup. It's not clear what the draft means when it is saying "SDP offers a reliable communication channel"; does this man to say SIP? I am not currently subscribed to this list, so if there are comments in response, please cc me. thanks, Ted --001a114d8db6e0b146054c9a996d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Howdy,

I was asked to review t= his draft in Chicago; sorry for not getting to it sooner.

Firs= t, the security considerations seem to be TBD entirely, which seems surpris= ing.=C2=A0 I was particularly interested to see how this draft would tackle= linkability, since it is an ongoing discussion in other groups (e.g. QUIC)= .=C2=A0 I think that the security considerations, when written, need to tac= kle both linkability (the ability of an observer to cross-correlate traffic= on two different paths as belonging to the same endpoint) and consent fres= hness.=C2=A0

Second, I believe this requirement:
Multipath RTP (MPRTP) MUST be backwards compatible; an MPRTP Stream needs to fall back to be compatible with legacy RTP stacks if MPRTP support is not successfully negotiated.
may need = re-wording. I initially misread this team that MPRTP would appear to be non= -multipath RTP if the MPRTP support were not available (following what was = said about NAT bindings); it seems you mean instead that an MPRTP stack mus= t fall back to non-multipath RTP.=C2=A0 Clarifying this would be useful.
On the use cases,=C2=A0 the use case for fault tolerance ha= s some very simple applications that I have seen proposed in the past.=C2= =A0 In one case, ambulance telemetry was sent over multiple cellular networ= ks--there, full duplication was appropriate and the receiver simply threw a= way any information already received from a different interface.=C2=A0 Load= balancing applications are harder, and I believe the draft may want to exp= licitly consider how differential packet traversal times across different p= aths will impact the number of applications that can use this.=C2=A0 If I u= nderstand this correctly, a system with a playout buffer would be able to i= nterleave RTP packets from different subflows successfully.=C2=A0 A system = without such a buffer or with one too small for late arrivals will end up l= osing information.=C2=A0 There are ways to get around this, but the documen= t does not go into them in detail.=C2=A0 Will they be covered by later docu= ments?

Also, the document says:
In contrast to RTCP, SDP offers a reliable
communica=
tion channel so that no separate retransmissions logic is
necessary.  In SDP, especially when combined with ICE, connectivity
check mechanisms including sophisticated rules are readily available.

While SDP is not inherently protected, suitable security may need to
be applied anyway to the basic session setup.
It= 's not clear what the draft means when it is saying "SDP offers a = reliable
communication channel"; does this man to say SI= P?

I am not currently subscribed to this list, so if ther= e are comments in response, please cc me.

thanks,

=
Ted
--001a114d8db6e0b146054c9a996d-- From nobody Mon Apr 10 18:02:05 2017 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C7E21242F5; Mon, 10 Apr 2017 18:01:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lIBQ2h1bgmBK; Mon, 10 Apr 2017 18:01:54 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9627C127873; Mon, 10 Apr 2017 18:01:53 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DKQ75239; Tue, 11 Apr 2017 01:01:51 +0000 (GMT) Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml702-cah.china.huawei.com (10.201.108.43) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 11 Apr 2017 02:01:50 +0100 Received: from NKGEML513-MBS.china.huawei.com ([169.254.2.8]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0235.001; Tue, 11 Apr 2017 09:01:42 +0800 From: "Huangyihong (Rachel)" To: "avt@ietf.org" , "avtext@ietf.org" Thread-Topic: [avtcore][avtext] WGLC for draft-ietf-avtext-lrr-04 Thread-Index: AdKyXy6C5yuvZ52QRpuGLK0PQ1UraA== Date: Tue, 11 Apr 2017 01:01:42 +0000 Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBB9C3FBF05@nkgeml513-mbs.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.78.110] Content-Type: multipart/alternative; boundary="_000_51E6A56BD6A85142B9D172C87FC3ABBB9C3FBF05nkgeml513mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.58EC2B00.0017, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.2.8, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 451e18718710bf961dcbf11db739a259 Archived-At: Subject: [AVTCORE] [avtcore][avtext] WGLC for draft-ietf-avtext-lrr-04 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 01:01:56 -0000 --_000_51E6A56BD6A85142B9D172C87FC3ABBB9C3FBF05nkgeml513mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi WG, It is agreed that draft-ietf-avtext-lrr-04 is stable enough for the next st= ep. Therefore, this email starts a working group last call for draft-ietf-a= vtext-lrr-04. This WGLC runs until April 28th. So please have a look at the= draft and send your comments to the avt list by then. Thanks. The draft is now available at https://datatracker.ietf.org/doc/html/draft-i= etf-avtext-lrr-04. BR, Rachel (co-chair) --_000_51E6A56BD6A85142B9D172C87FC3ABBB9C3FBF05nkgeml513mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi WG,

 

It is agreed that draft-ietf-av= text-lrr-04 is stable enough for the next step. Therefore, this email start= s a working group last call for draft-ietf-avtext-lrr-04. This WGLC runs un= til April 28th. So please have a look at the draft and send your comments to the avt list by then. T= hanks.

 

The draft is now available at <= a href=3D"https://datatracker.ietf.org/doc/html/draft-ietf-avtext-lrr-04"> https://datatracker.ietf.org/doc/html/draft-ietf-avtext-lrr-04.

 

BR,

Rachel (co-chair)

 

--_000_51E6A56BD6A85142B9D172C87FC3ABBB9C3FBF05nkgeml513mbschi_-- From nobody Thu Apr 20 07:58:38 2017 Return-Path: X-Original-To: avt@ietf.org Delivered-To: avt@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 71112129AAA; Thu, 20 Apr 2017 07:58:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Carlos Martinez To: Cc: draft-ietf-avtcore-rfc5285-bis.all@ietf.org, ietf@ietf.org, avt@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149270030040.22369.16996023581425987557@ietfa.amsl.com> Date: Thu, 20 Apr 2017 07:58:20 -0700 Archived-At: Subject: [AVTCORE] Opsdir last call review of draft-ietf-avtcore-rfc5285-bis-09 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.22 List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 14:58:20 -0000 Reviewer: Carlos Martinez Review result: Ready I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. With the caveat that I'm not fully familiar with the topic, I have not found any serious issues with the document and I believe the document to be ready. I found the document well-written and providing adequate references along the text. Being a -bis document I believe this is particularly important. Thanks, -Carlos From nobody Fri Apr 28 01:43:30 2017 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E11C129AF6; Fri, 28 Apr 2017 01:43:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s54qjVglUsVH; Fri, 28 Apr 2017 01:43:18 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE38B12778D; Fri, 28 Apr 2017 01:40:01 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DLX40314; Fri, 28 Apr 2017 08:39:59 +0000 (GMT) Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.301.0; Fri, 28 Apr 2017 09:39:58 +0100 Received: from NKGEML513-MBS.china.huawei.com ([169.254.2.108]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0235.001; Fri, 28 Apr 2017 16:39:53 +0800 From: "Huangyihong (Rachel)" To: "avt@ietf.org" , "avtext@ietf.org" Thread-Topic: [avtext] [avtcore] extended WGLC for draft-ietf-avtext-lrr-04 Thread-Index: AQHSv/sB7+55mJmzLE+Jf56bGerlRQ== Date: Fri, 28 Apr 2017 08:39:53 +0000 Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBB9C451A44@nkgeml513-mbs.china.huawei.com> References: <51E6A56BD6A85142B9D172C87FC3ABBB9C3FBF05@nkgeml513-mbs.china.huawei.com> In-Reply-To: <51E6A56BD6A85142B9D172C87FC3ABBB9C3FBF05@nkgeml513-mbs.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.78.110] Content-Type: multipart/alternative; boundary="_000_51E6A56BD6A85142B9D172C87FC3ABBB9C451A44nkgeml513mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.5902FFE0.0022, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.2.108, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: b5c9c7d2e9792c7d41ff1807c69c2fa5 Archived-At: Subject: [AVTCORE] [avtext] [avtcore] extended WGLC for draft-ietf-avtext-lrr-04 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Apr 2017 08:43:21 -0000 --_000_51E6A56BD6A85142B9D172C87FC3ABBB9C451A44nkgeml513mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I'll extend this WGLC for another week (until 5/5) as I didn't see any feed= back in the list. If you think this draft has no further issues and ready for the next step, = please don't be silent and express it in the list. We'll appreciate it. BR, Rachel (co-chair) From: avtext [mailto:avtext-bounces@ietf.org] On Behalf Of Huangyihong (Rac= hel) Sent: Tuesday, April 11, 2017 9:02 AM To: avt@ietf.org; avtext@ietf.org Subject: [avtext] [avtcore] WGLC for draft-ietf-avtext-lrr-04 Hi WG, It is agreed that draft-ietf-avtext-lrr-04 is stable enough for the next st= ep. Therefore, this email starts a working group last call for draft-ietf-a= vtext-lrr-04. This WGLC runs until April 28th. So please have a look at the= draft and send your comments to the avt list by then. Thanks. The draft is now available at https://datatracker.ietf.org/doc/html/draft-i= etf-avtext-lrr-04. BR, Rachel (co-chair) --_000_51E6A56BD6A85142B9D172C87FC3ABBB9C451A44nkgeml513mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

&n= bsp;

I’= ;ll extend this WGLC for another week (until 5/5) as I didn’t see any= feedback in the list.

&n= bsp;

If you = think this draft has no further issues and ready for the next step, please = don’t be silent and express it in the list. We’ll appreciate it= .

&n= bsp;

BR,

Rachel = (co-chair)

&n= bsp;

From: avtext [mail= to:avtext-bounces@ietf.org] On Behalf Of Huangyihong (Rachel)
Sent: Tuesday, April 11, 2017 9:02 AM
To: avt@ietf.org; avtext@ietf.org
Subject: [avtext] [avtcore] WGLC for draft-ietf-avtext-lrr-04

 

Hi WG,

 

It is agreed that draft-ietf-av= text-lrr-04 is stable enough for the next step. Therefore, this email start= s a working group last call for draft-ietf-avtext-lrr-04. This WGLC runs un= til April 28th. So please have a look at the draft and send your comments to the avt list by then. T= hanks.

 

The draft is now available at <= a href=3D"https://datatracker.ietf.org/doc/html/draft-ietf-avtext-lrr-04"> https://datatracker.ietf.org/doc/html/draft-ietf-avtext-lrr-04.

 

BR,

Rachel (co-chair)

 

--_000_51E6A56BD6A85142B9D172C87FC3ABBB9C451A44nkgeml513mbschi_-- From nobody Sun Apr 30 01:17:08 2017 Return-Path: X-Original-To: avt@ietf.org Delivered-To: avt@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D2A1129537; Sun, 30 Apr 2017 01:17:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: avt@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149354022026.2907.13022594628838923597@ietfa.amsl.com> Date: Sun, 30 Apr 2017 01:17:00 -0700 Archived-At: Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-rfc5285-bis-10.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.22 List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Apr 2017 08:17:00 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Core Maintenance of the IETF. Title : A General Mechanism for RTP Header Extensions Authors : David Singer Harikishan Desineni Roni Even Filename : draft-ietf-avtcore-rfc5285-bis-10.txt Pages : 22 Date : 2017-04-30 Abstract: This document provides a general mechanism to use the header extension feature of RTP (the Real-Time Transport Protocol). It provides the option to use a small number of small extensions in each RTP packet, where the universe of possible extensions is large and registration is de-centralized. The actual extensions in use in a session are signaled in the setup information for that session. This document obsoletes RFC5285. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtcore-rfc5285-bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-avtcore-rfc5285-bis-10 https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rfc5285-bis-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-avtcore-rfc5285-bis-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/