From nobody Fri Oct 2 10:50:01 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C23E1B300A for ; Fri, 2 Oct 2015 10:50:00 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable 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 HSfNaQjNERlR for ; Fri, 2 Oct 2015 10:49:58 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEB3E1B3008 for ; Fri, 2 Oct 2015 10:49:57 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id DC11020149 for ; Fri, 2 Oct 2015 13:49:56 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute4.internal (MEProxy); Fri, 02 Oct 2015 13:49:56 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h= content-type:date:from:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=5rWwgjMmQkn3SaXq iZGFPkFLHmY=; b=hTBjC/1GjxYWpbejwRT0CiJSU7NJaO56T4bruToFaTrUvsbl FLKJzZYayGMin1UCacNUvUZqlyZjrCi+Mggf1NdqBcjVINv/eQJXjAmrsCg4ETge yiFKP9Zr5WdHGOC1G0wJGpWCL9hVCtW8YGgBqhg0cEzCrKMEas0FI3RoDcQ= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:references:subject:to:x-sasl-enc:x-sasl-enc; s= smtpout; bh=5rWwgjMmQkn3SaXqiZGFPkFLHmY=; b=DezA7b3J8+6hxk90jrAa GTOJ1lrwb7TBxGjCkMM+Rnc1Mp/2ISwBhfV5C4KvAKGTQr5vQtVXgVPm1A+Vddof 67kWyYoXSqqtlIF2SQPeNwl/sZIZo+jtz0L6LizfMnXwIhFZ68hurAjrZaFbj2Um pZIeFABWKTmhCtkTX9iIFzI= X-Sasl-enc: MQA/KoWXwUJj0gT2kdrSilE/84ix48u4kqnPygNtXPYG 1443808196 Received: from dhcp-171-68-20-103.cisco.com (dhcp-171-68-20-103.cisco.com [171.68.20.103]) by mail.messagingengine.com (Postfix) with ESMTPA id 54E7EC00023; Fri, 2 Oct 2015 13:49:56 -0400 (EDT) From: Alissa Cooper Content-Type: multipart/alternative; boundary="Apple-Mail=_F5E9DCEC-5B4E-4D9A-A859-325EB766CADD" Date: Fri, 2 Oct 2015 10:49:55 -0700 References: <20151002163548.13742.44075.idtracker@ietfa.amsl.com> To: dispatch@ietf.org, geopriv mailing list Message-Id: <1B66F091-6880-4832-B63D-F47FFB6F9B0C@cooperw.in> Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) Archived-At: Subject: [dispatch] Fwd: WG Action: Formed Geographic JSON (geojson) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2015 17:50:00 -0000 --Apple-Mail=_F5E9DCEC-5B4E-4D9A-A859-325EB766CADD Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii FYI > Begin forwarded message: > > From: The IESG > Subject: WG Action: Formed Geographic JSON (geojson) > Date: October 2, 2015 at 9:35:48 AM PDT > To: "IETF-Announce" > Cc: geojson WG > Reply-To: ietf@ietf.org > > A new IETF working group has been formed in the Applications and > Real-Time Area. For additional information please contact the Area > Directors or the WG Chairs. > > Geographic JSON (geojson) > ------------------------------------------------ > Current Status: Proposed WG > > Chairs: > Erik Wilde > Martin Thomson > > Assigned Area Director: > Alissa Cooper > > Mailing list > Address: geojson@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/geojson > Archive: https://mailarchive.ietf.org/arch/search/?email_list=geojson > > Charter: > > GeoJSON is a format for encoding data about geographic features using > JavaScript Object Notation (JSON) [RFC7159]. Geographic features need not > be physical things; any thing with properties that are bounded in space > may be considered a feature. GeoJSON provides a means of representing > both the properties and spatial extent of features. > > The GeoJSON format specification was published at http://geojson.org in > 2008. GeoJSON today plays an important and growing role in many spatial > databases, web APIs, and open data platforms. Consequently the > implementers increasingly demand formal standardization, improvements in > the specification, guidance on extensibility, and the means to utilize > larger GeoJSON datasets. > > This WG will work on a GeoJSON Format RFC that specifies the format more > precisely, serves as a better guide for implementers, and improves > extensibility of the format. The work will start from an Internet-Draft > written by the original GeoJSON authors: draft-butler-geojson [1]. > > This WG will work on GeoJSON mappings of 'geo' URIs, reinforcing the use > of RFC 5870. > > This WG will work on a format for a streamable sequence of GeoJSON texts > based on RFC 7464 (JSON Text Sequences) to address the difficulties in > serializing very large sequences of features or feature sequences of > indeterminate length. > > GeoJSON objects represent geographic features only and do not specify > associations between geographic features and particular devices, users, > or facilities. Any association with a particular device, user, or > facility requires another protocol. When a GeoJSON object is used in a > context where it identifies the location of a device, user, or facility, > it becomes subject to the architectural, security, and privacy > considerations in RFC 6280, An Architecture for Location and Location > Privacy in Internet Applications. The application of those considerations > is specific to protocols that make use of GeoJSON objects and is out of > scope for the GeoJSON WG. Although the WG is chartered to improve the > extensibility of the format, extensions that would allow GeoJSON objects > to specify associations between geographic features and particular > devices, users, or facilities are not expected to be defined in the WG. > Should that be needed, re-chartering will be required. > > Deliverables: > > * A GeoJSON format specification document including mappings of 'geo' > URIs > * A document describing a format for a streamable sequence of GeoJSON > texts > > [1] https://tools.ietf.org/html/draft-butler-geojson > > Milestones: > > --Apple-Mail=_F5E9DCEC-5B4E-4D9A-A859-325EB766CADD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii FYI

Begin forwarded message:

From: = The IESG <iesg-secretary@ietf.org>
Subject: = WG Action: Formed = Geographic JSON (geojson)
Date: = October 2, 2015 at 9:35:48 AM = PDT
To: = "IETF-Announce" <ietf-announce@ietf.org>
Cc: geojson WG <geojson@ietf.org>
Reply-To: = ietf@ietf.org

A new IETF working group has been formed in = the Applications and
Real-Time Area. For additional = information please contact the Area
Directors or the WG = Chairs.

Geographic JSON (geojson)
------------------------------------------------
Current Status: Proposed WG

Chairs:
 Erik Wilde <dret@berkeley.edu>
 Martin Thomson <martin.thomson@gmail.com>

Assigned Area Director:
 Alissa Cooper = <alissa@cooperw.in>

Mailing = list
 Address: geojson@ietf.org
 To Subscribe: https://www.ietf.org/mailman/listinfo/geojson
 Archive: https://mailarchive.ietf.org/arch/search/?email_list=3Dgeojson<= /a>

Charter:

GeoJSON is a format for encoding data about geographic = features using
JavaScript Object Notation (JSON) = [RFC7159]. Geographic features need not
be physical = things; any thing with properties that are bounded in space
may be considered a feature. GeoJSON provides a means of = representing
both the properties and spatial extent of = features.

The GeoJSON format specification = was published at
http://geojson.org in
2008. GeoJSON today = plays an important and growing role in many spatial
databases, web APIs, and open data platforms. Consequently = the
implementers increasingly demand formal = standardization, improvements in
the specification, = guidance on extensibility, and the means to utilize
larger = GeoJSON datasets.

This WG will work on a = GeoJSON Format RFC that specifies the format more
precisely,= serves as a better guide for implementers, and improves
extensibility of the format. The work will start from an = Internet-Draft
written by the original GeoJSON authors: = draft-butler-geojson [1].

This WG will work = on GeoJSON mappings of 'geo' URIs, reinforcing the use
of = RFC 5870.

This WG will work on a format for = a streamable sequence of GeoJSON texts
based on RFC 7464 = (JSON Text Sequences) to address the difficulties in
serializing very large sequences of features or feature = sequences of
indeterminate length.

GeoJSON objects represent geographic features only and do not = specify
associations between geographic features and = particular devices, users,
or facilities. Any association = with a particular device, user, or
facility requires = another protocol. When a GeoJSON object is used in a
context= where it identifies the location of a device, user, or facility,
it becomes subject to the architectural, security, and = privacy
considerations in RFC 6280, An Architecture for = Location and Location
Privacy in Internet Applications. = The application of those considerations
is specific to = protocols that make use of GeoJSON objects and is out of
scope for the GeoJSON WG. Although the WG is chartered to = improve the
extensibility of the format, extensions that = would allow GeoJSON objects
to specify associations = between geographic features and particular
devices, users, = or facilities are not expected to be defined in the WG.
Should that be needed, re-chartering will be required.

Deliverables:

* A = GeoJSON format specification document including mappings of 'geo'
URIs
* A document describing a format for a = streamable sequence of GeoJSON
texts

[1] https://tools.ietf.org/html/draft-butler-geojson

Milestones:



= --Apple-Mail=_F5E9DCEC-5B4E-4D9A-A859-325EB766CADD-- From nobody Mon Oct 5 15:03:52 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B42D21A1BE7 for ; Mon, 5 Oct 2015 15:03:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 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, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 5UcUhUlcHzj0 for ; Mon, 5 Oct 2015 15:03:48 -0700 (PDT) Received: from mail-yk0-x236.google.com (mail-yk0-x236.google.com [IPv6:2607:f8b0:4002:c07::236]) (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 A4DF81A1BF4 for ; Mon, 5 Oct 2015 15:03:46 -0700 (PDT) Received: by ykdg206 with SMTP id g206so184117561ykd.1 for ; Mon, 05 Oct 2015 15:03:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=7Y38KagQYpe6JsK3CCGLuV3xRQquqEhdrQ5YGTy/r3E=; b=UOxvd7iVTWwU1Ns5U4K4EHYKCKCNH51NOofcSPzTBzOl0VNTIIGxRXRipW1G9yJdtx qI2jmWe4SFrGTzjmEuj6BMPgwyV9Eez24GXtjxraMC7culZ5ggh062ESbNrMsljXUdK9 I+Gjjk/6bLhlS+4Gsop1vYMsbN+jj7+h++7SUh9cf+/U9K7D5Bd+vLEBo9ejM5mDRllX BWbmeFPmMQ/octnQtN/vo1A8n3gAGSR57Qdj3VJOhIjNHmD4W4MGiyBqvoiil5qfcsIG 0bmhjmHtWpJB9IymqUD+oWOmc9HnXxwOUVHRcjJHc1KqVcuIkk1LecUCx6XwGMuOGPnS OXWA== MIME-Version: 1.0 X-Received: by 10.13.235.16 with SMTP id u16mr10033353ywe.26.1444082625845; Mon, 05 Oct 2015 15:03:45 -0700 (PDT) Received: by 10.37.25.4 with HTTP; Mon, 5 Oct 2015 15:03:45 -0700 (PDT) Date: Mon, 5 Oct 2015 17:03:45 -0500 Message-ID: From: Mary Barnes To: DISPATCH Content-Type: multipart/alternative; boundary=94eb2c086deaf0a693052162af91 Archived-At: Subject: [dispatch] Proposed new DISPATCH WG charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2015 22:03:50 -0000 --94eb2c086deaf0a693052162af91 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi all, Below please find a proposed new/updated charter for the DISPATCH WG. This charter reflects the merging of the APP and RAI areas. We will set aside some time during the DISPATCH WG session in Yokohama to discuss, but please do provide any comments on the mailing list prior to that. Regards, Mary on behalf of DISPATCH WG chairs, APPSAWG chairs and ART ADs =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 # Draft Charter for Dispatch Working Group The Dispatch working group is chartered to consider proposals for new work in the ART area and identify, or help create, an appropriate venue for the work. Guiding principles for the proposed new work include: 1. Providing a clear problem statement, motivation and deliverables for the proposed new work. 2. Ensuring there has been adequate mailing list discussion reflecting sufficient interest, individuals have expressed a willingness to contribute and there is WG consensus before new work is dispatched. 3. Looking for and identifying commonalities and overlap amongst published or ongoing protocol work. Such commonalities may indicate the possibility of reusing existing protocols or elements thereof published by other WGs, or expanding and/or refactoring the scope of deliverables in an active WG. 4. Protecting the architectural integrity of IETF protocols and ensuring that new work has general applicability. 5. Ensuring the new work considers the impact on security and privacy of both the network and the user. Options for handling new work include: - Directing the work to an existing WG. - Developing a proposal for a BOF. - Developing a charter for a new WG. - Making recommendations that documents be AD-sponsored (which ADs may or may not choose to follow). - By agreement with ART ADs, processing simple documents. - Deferring the decision for the new work. - Rejecting the new work. If the group decides that a particular topic needs to be addressed by a new WG, the normal IETF chartering process will be followed, including, for instance, IETF-wide review of the proposed charter. Proposals for large work efforts SHOULD lead to a BOF where the topic can be discussed in front of the entire IETF community. The DISPATCH WG will not do any protocol work. Specifically, DISPATCH will always opt to find a location for technical work; the only work that DISPATCH is not required to delegate (or defer, or reject) is administrative work such as IANA actions. Documents progressed as AD-sponsored would typically include those that do not have general applicability to IETF protocols, but rather are only applicable to specific use cases and network deployments, for which the scope must be clearly specified. Proposed new work may be deferred in cases where the WG does not have enough information for the chairs to determine consensus. New work may be rejected in cases where there is not sufficient WG interest or the proposal has been considered and rejected in the past, unless a substantially revised proposal is put forth, including compelling new reasons for accepting the work. A major objective of the DISPATCH WG is to provide timely, clear dispositions of new efforts. Thus, where there is consensus to take on new work, the WG will strive to quickly find a home for it. --94eb2c086deaf0a693052162af91 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all,=C2=A0

Below please find a propo= sed new/updated charter for the DISPATCH WG. This charter reflects the merg= ing of the APP and RAI areas.=C2=A0 We will set aside some time during the = DISPATCH WG session in Yokohama to discuss, but please do provide any comme= nts on the mailing list prior to that.

Regards,
Mary
on behalf of DISPATCH WG chairs, APPSAWG chairs and = ART ADs



=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94
# Draft Charter for Dispatch Working Group
<= div>
The Dispatch working group is chartered to consider prop= osals for new
work in the ART area and identify, or help create, = an appropriate venue
for the work.

Guidi= ng principles for the proposed new work include:

1= . Providing a clear problem statement, motivation and deliverables for
=C2=A0 =C2=A0the proposed new work.

2. Ensur= ing there has been adequate mailing list discussion reflecting
= =C2=A0 =C2=A0sufficient interest, individuals have expressed a willingness = to
=C2=A0 =C2=A0contribute and there is WG consensus before new w= ork is dispatched.

3. Looking for and identifying = commonalities and overlap amongst
=C2=A0 =C2=A0published or ongoi= ng protocol work. Such commonalities may indicate
=C2=A0 =C2=A0th= e possibility of reusing existing protocols or elements thereof
= =C2=A0 =C2=A0published by other WGs, or expanding and/or refactoring the sc= ope of
=C2=A0 =C2=A0deliverables in an active WG.

<= /div>
4. Protecting the architectural integrity of IETF protocols and e= nsuring
=C2=A0 =C2=A0that new work has general applicability.

5. Ensuring the new work considers the impact on secu= rity and privacy of
=C2=A0 =C2=A0both the network and the user.

Options for handling new work include:
- Directing the work to an existing WG.=C2=A0
- Deve= loping a proposal for a BOF.
- Developing a charter for a new WG.= =C2=A0
- Making recommendations that documents be AD-sponsored=C2= =A0
=C2=A0 (which ADs may or may not choose to follow).
- By agreement with ART ADs, processing simple documents.=C2=A0
= - Deferring the decision for the new work.=C2=A0
- Rejecting the = new work.

If the group decides that a particular t= opic needs to be addressed by a
new WG, the normal IETF charterin= g process will be followed, including,
for instance, IETF-wide re= view of the proposed charter. Proposals for
large work efforts SH= OULD lead to a BOF where the topic can be discussed
in front of t= he entire IETF community. The DISPATCH WG will not do any
protoco= l work. Specifically, DISPATCH will always opt to find a location
for technical work; the only work that DISPATCH is not required to
delegate (or defer, or reject) is administrative work such as IANA
=
actions. Documents progressed as AD-sponsored would typically include<= /div>
those that do not have general applicability to IETF protocols, b= ut
rather are only applicable to specific use cases and network
deployments, for which the scope must be clearly specified.
<= div>
Proposed new work may be deferred in cases where the WG = does not have
enough information for the chairs to determine cons= ensus. New work may
be rejected in cases where there is not suffi= cient WG interest or the
proposal has been considered and rejecte= d in the past, unless a
substantially revised proposal is put for= th, including compelling new
reasons for accepting the work.

A major objective of the DISPATCH WG is to provide tim= ely, clear
dispositions of new efforts. Thus, where there is cons= ensus to take on
new work, the WG will strive to quickly find a h= ome for it.



=
--94eb2c086deaf0a693052162af91-- From nobody Thu Oct 8 13:17:30 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BA511ACD29 for ; Thu, 8 Oct 2015 13:17:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 7cIWJjy7RhHE for ; Thu, 8 Oct 2015 13:17:26 -0700 (PDT) Received: from smtp112.ord1c.emailsrvr.com (smtp112.ord1c.emailsrvr.com [108.166.43.112]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DFC41ACD26 for ; Thu, 8 Oct 2015 13:17:26 -0700 (PDT) Received: from smtp7.relay.ord1c.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp7.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id E19773801DA; Thu, 8 Oct 2015 16:17:25 -0400 (EDT) Received: by smtp7.relay.ord1c.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 24C4A380306; Thu, 8 Oct 2015 16:17:25 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.24.222.64] ([UNAVAILABLE]. [128.107.241.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:587 (trex/5.4.2); Thu, 08 Oct 2015 20:17:25 GMT Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Cullen Jennings In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37AE6750@ESESSMB209.ericsson.se> Date: Thu, 8 Oct 2015 12:15:34 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7594FB04B1934943A5C02806D1A2204B37AC0CF1@ESESSMB209.ericsson.se> <3308F2DE-08F1-46A0-BC01-2445627BAD53@iii.ca> <56031836.3080407@nostrum.com> <4E205A3B-F608-48D3-9DA5-D2220A97D953@nostrum.com> <7594FB04B1934943A5C02806D1A2204B37AE6750@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.2104) Archived-At: Cc: DISPATCH list , Ben Campbell , SIPCORE Subject: Re: [dispatch] [sipcore] [Technical Errata Reported] RFC7315 (4474) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2015 20:17:29 -0000 My 2 cents is still more appropriate to fix it with a draft that epodes = it not an Errata. Imagine an SBC or Firewall that is checking the SIP = syntax using the ABNF. The odds of them seeing this change and = implementing it much better with an RFC than an errata. Total work = either way is minimal.=20 > On Sep 30, 2015, at 9:12 AM, Christer Holmberg = wrote: >=20 > Hi, >=20 >> (+sipcore, dispatch) >> (as individual) >>=20 >> I just realized this discussion did not include the sipcore or = dispatch lists, and probably should. >>=20 >> Recap: Christer proposed an errata (4474) to RFC 7315. It proposes = the following change: >>=20 >>> Section 5.4 says: >>>=20 >>> extension-access-info =3D gen-value >>>=20 >>> It should say: >>>=20 >>> extension-access-info =3D generic-param >>=20 >> The generic-param construction allows the NAME =3D VALUE syntax as in = the TS 24.229 extension Jean mentioned below. >>=20 >> Keeping in mind the RFC in question was for 3GPP: Is anyone aware of = implementations of 7315 that would be broken >> by this? =46rom Jean's example, it looks like 3GPP had already = assumed generic-param. >=20 > Correct. >=20 > Also, comparing RFC 3455 and RFC 7315, *all but one* of the new = access-info parameter values that were added in RFC 7315 follow the = generic-param syntax. So, it seems like we in IETF also assumed = generic-param when we did RFC 7315 (and/or we were not concerned about = parser issues), but nobody noticed the ABNF issue. >=20 > And, as I said earlier, I am pretty sure this header is mostly (only?) = used in 3GPP environments, and nobody in 3GPP objected to the change I = am now suggesting. It was discussed in 3GPP, and the outcome was to file = the errata. >=20 > Finally, as Jean indicated, 3GPP has defined a new value, = daylight-saving-time, which also uses the generic-param syntax. >=20 > Regards, >=20 > Christer >=20 >=20 > On 23 Sep 2015, at 16:23, A. Jean Mahoney wrote: >=20 >> FWIW - TS 24.229, which defines the values for access-info, considers=20= >> extension-access-info to be a generic-param, and not a gen-value as=20= >> specified RFC7315. 3GPP has defined one extension so far (7.2A.4): >>=20 >>=20 >> daylight-saving-time =3D "daylight-saving-time" EQUAL quoted-string >>=20 >> TS 124 229 - V12.9.0 - Digital cellular telecommunications system=20 >> (Phase 2+); Universal Mobile Telecommunications System (UMTS); LTE; = IP=20 >> multimedia call control protocol based on Session Initiation Protocol=20= >> (SIP) and Session Description Protocol (SDP); Stage 3 (3GPP TS 24.229=20= >> version 12.9.0 Release 12) The daylight-saving-time is an instance of=20= >> generic-param from the current extension-access-info component of the=20= >> P- Access-Network-Info header field defined in RFC >> 7315 [52]. >>=20 >>=20 >> Jean >>=20 >>=20 >>=20 >> On 9/23/15 3:47 PM, Cullen Jennings wrote: >>> I can see that it might have been better if it had been done this = way=20 >>> Christer is proposing but I don't see how you can change it now. = This=20 >>> change would break existing parsers that checked this. That does not=20= >>> seem like an errata level thing to me. >>>=20 >>>=20 >>>> On Sep 21, 2015, at 10:30 AM, Ben Campbell wrote: >>>>=20 >>>> sipcore and dispatch chairs: >>>>=20 >>>> Do you have any concerns about accepting Christer's errata? (I note=20= >>>> RFC 7315 was an orphaned sipping draft progressed as AD sponsored.) >>>>=20 >>>> Ben. >>>>=20 >>>> Forwarded message: >>>>=20 >>>>> From: Christer Holmberg >>>>> To: Ben Campbell >>>>> Cc: sipcore@ietf.org >>>>> Subject: Re: [sipcore] [Technical Errata Reported] RFC7315 (4474) >>>>> Date: Mon, 21 Sep 2015 10:26:26 +0000 >>>>>=20 >>>>> Any news on this? >>>>>=20 >>>>> Regards, >>>>>=20 >>>>> Christer >>>>>=20 >>>>> From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of=20 >>>>> Christer Holmberg >>>>> Sent: 14. syyskuuta 2015 23:24 >>>>> To: Ben Campbell >>>>> Cc: sipcore@ietf.org >>>>> Subject: Re: [sipcore] [Technical Errata Reported] RFC7315 (4474) >>>>>=20 >>>>> Hi Ben, >>>>>=20 >>>>> I am pretty sure generic-param was the original intention. The=20 >>>>> majority of all existing value follow the generic-param syntax, = and=20 >>>>> I can't think of any reason why new values would not follow the=20 >>>>> same syntax. That is how it works for other header fields too. >>>>>=20 >>>>> I think this is due to a mistake, where someone thought that=20 >>>>> extension-access-info represents the actual parameter name, and=20= >>>>> therefor only a value (gen-value) is needed. But,=20 >>>>> extension-access-info represents the whole rule (name AND value),=20= >>>>> why generic-param is needed :) >>>>>=20 >>>>> Regards, >>>>>=20 >>>>> Christer >>>>>=20 >>>>> Sent from my Windows Phone >>>>> ________________________________ >>>>> From: Ben Campbell >>>>> Sent: =E2=80=8E14/=E2=80=8E09/=E2=80=8E2015 21:31 >>>>> To: Christer Holmberg >>>>> Cc: sipcore@ietf.org >>>>> Subject: Re: [sipcore] [Technical Errata Reported] RFC7315 (4474)=20= >>>>> Hi Christer, >>>>>=20 >>>>> Is it your understanding that the use of generic-param was the=20 >>>>> actual intention at the time 7315 was published? Or was gen-value=20= >>>>> the original intention, but we now think that it should have been=20= >>>>> generic-param? >>>>>=20 >>>>> Thanks! >>>>>=20 >>>>> Ben. >>>>>=20 >>>>> On 14 Sep 2015, at 6:22, Christer Holmberg wrote: >>>>>=20 >>>>>> FYI, >>>>>>=20 >>>>>> I've now submitted the errata. >>>>>>=20 >>>>>> Regards, >>>>>>=20 >>>>>> Christer >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] >>>>>> Sent: 14. syyskuuta 2015 14:21 >>>>>> To: r.jesske@telekom.de; >>>>>> drage@alcatel-lucent.com; >>>>>> Christer Holmberg; >>>>>> iesg@ietf.org >>>>>> Cc: Christer Holmberg; >>>>>> rfc-editor@rfc-editor.org >>>>>> Subject: [Technical Errata Reported] RFC7315 (4474) >>>>>>=20 >>>>>> The following errata report has been submitted for RFC7315,=20 >>>>>> "Private Header (P-Header) Extensions to the Session Initiation=20= >>>>>> Protocol >>>>>> (SIP) >>>>>> for the 3GPP". >>>>>>=20 >>>>>> -------------------------------------- >>>>>> You may review the report below and at: >>>>>> http://www.rfc-editor.org/errata_search.php?rfc=3D7315&eid=3D4474 >>>>>>=20 >>>>>> -------------------------------------- >>>>>> Type: Technical >>>>>> Reported by: Christer Holmberg >>>>>> = >>>>> com>> >>>>>>=20 >>>>>> Section: 5.4 >>>>>>=20 >>>>>> Original Text >>>>>> ------------- >>>>>> extension-access-info =3D gen-value >>>>>>=20 >>>>>> Corrected Text >>>>>> -------------- >>>>>> extension-access-info =3D generic-param >>>>>>=20 >>>>>> Notes >>>>>> ----- >>>>>> Most of the pre-defined access-info values are following the=20 >>>>>> generic-param syntax. New access-info values (extensions) should=20= >>>>>> also be allowed to follow the generic-param syntax, in order to=20= >>>>>> allow both for a name and value of the extension. >>>>>>=20 >>>>>> Instructions: >>>>>> ------------- >>>>>> This erratum is currently posted as "Reported". If necessary,=20 >>>>>> please use "Reply All" to discuss whether it should be verified = or=20 >>>>>> rejected. >>>>>> When a decision is reached, the verifying party (IESG) can log in=20= >>>>>> to change the status and edit the report, if necessary. >>>>>>=20 >>>>>> -------------------------------------- >>>>>> RFC7315 (draft-drage-sipping-rfc3455bis-14) >>>>>> -------------------------------------- >>>>>> Title : Private Header (P-Header) Extensions to the >>>>>> Session Initiation Protocol (SIP) for the 3GPP >>>>>> Publication Date : July 2014 >>>>>> Author(s) : R. Jesske, K. Drage, C. Holmberg >>>>>> Category : INFORMATIONAL >>>>>> Source : IETF - NON WORKING GROUP >>>>>> Area : N/A >>>>>> Stream : IETF >>>>>> Verifying Party : IESG >>>>>>=20 >>>>>> _______________________________________________ >>>>>> sipcore mailing list >>>>>> sipcore@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/sipcore >>>>> _______________________________________________ >>>>> sipcore mailing list >>>>> sipcore@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sipcore >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From nobody Thu Oct 8 19:03:20 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40F3D1A6F38; Thu, 8 Oct 2015 19:03:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 9ldcGrIygDyO; Thu, 8 Oct 2015 19:03:13 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 678881A6F2F; Thu, 8 Oct 2015 19:03:11 -0700 (PDT) X-AuditID: c1b4fb30-f79626d000006adf-93-5617205d64e3 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id CA.15.27359.D5027165; Fri, 9 Oct 2015 04:03:10 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.226]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0248.002; Fri, 9 Oct 2015 04:03:09 +0200 From: Christer Holmberg To: Cullen Jennings Thread-Topic: [dispatch] [sipcore] [Technical Errata Reported] RFC7315 (4474) Thread-Index: AQHQ7t97nIYDUJCaWUq0zXVQ2fcq45474U6QgABWdwCAAEDu14AKWWCwgA5pe2uAAAkewIAMprMAgACkLFI= Date: Fri, 9 Oct 2015 02:03:08 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37B346AB@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37AC0CF1@ESESSMB209.ericsson.se> <3308F2DE-08F1-46A0-BC01-2445627BAD53@iii.ca> <56031836.3080407@nostrum.com> <4E205A3B-F608-48D3-9DA5-D2220A97D953@nostrum.com> <7594FB04B1934943A5C02806D1A2204B37AE6750@ESESSMB209.ericsson.se>, In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B37B346ABESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupkkeLIzCtJLcpLzFFi42KZGfG3RjdOQTzMYPJKRov5nafZLZZOWsBq 8WH9D0aLrz82sTmweCxZ8pPJ4/L5j4wes3Y+YQlgjuKySUnNySxLLdK3S+DKaPrTwFyw+Thj xYTWi+wNjN9XM3YxcnJICJhIPJ9+iwnCFpO4cG89WxcjF4eQwFFGib5Hy9ghnMWMEl+3z2Hp YuTgYBOwkOj+pw3SICKgLHFux11mEJtZIFni/aGDzCAlwgI+Eh/3iUCU+Eoca9rEDGEnSRzu X8IOYrMIqEjMv/WKEaScF6jm/to0iE0/mCSOfvoHVsMpYCXx4vQpsDsZgW77fmoNE8QqcYmm LytZIW4WkFiy5zwzhC0q8fLxP1aImnyJfZeWgs3hFRCUODnzCcsERpFZSNpnISmbhaQMIm4g 8eX9bShbW2LZwtfMELa+RPf700zI4gsY2VcxihanFiflphsZ6aUWZSYXF+fn6eWllmxiBMbd wS2/DXYwvnzueIhRgINRiYd3oZ1YmBBrYllxZe4hRmkOFiVx3mamB6FCAumJJanZqakFqUXx RaU5qcWHGJk4OKUaGGPm+ShFvTZM652Rsau4WnHP2n7bq32r/4myT++6bPHkQebmmE1XDyw3 1hJq743R+sDW2PkhRN5+8abFE8LenF2Rc1y+0DhBu2nX/m03GN5vWjHX8u7VaeH2jbNCGhXf FO38a/FASUnzveEXF7lXWZH6ZbMSAu68sHH3Oh/s87hboyDmXqdwgBJLcUaioRZzUXEiAMXu nHecAgAA Archived-At: Cc: DISPATCH list , Ben Campbell , SIPCORE Subject: Re: [dispatch] [sipcore] [Technical Errata Reported] RFC7315 (4474) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2015 02:03:17 -0000 --_000_7594FB04B1934943A5C02806D1A2204B37B346ABESESSMB209erics_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable Hi Cullen, So, you are suggesting a SIPCORE draft that updates the ABNF? Regards, Christer Sent from my Windows Phone ________________________________ From: Cullen Jennings Sent: =FD08/=FD10/=FD2015 23:17 To: Christer Holmberg Cc: Ben Campbell; SIPCORE;= DISPATCH list Subject: Re: [dispatch] [sipcore] [Technical Errata Reported] RFC7315 (4474= ) My 2 cents is still more appropriate to fix it with a draft that epodes it= not an Errata. Imagine an SBC or Firewall that is checking the SIP syntax = using the ABNF. The odds of them seeing this change and implementing it muc= h better with an RFC than an errata. Total work either way is minimal. > On Sep 30, 2015, at 9:12 AM, Christer Holmberg wrote: > > Hi, > >> (+sipcore, dispatch) >> (as individual) >> >> I just realized this discussion did not include the sipcore or dispatch = lists, and probably should. >> >> Recap: Christer proposed an errata (4474) to RFC 7315. It proposes the f= ollowing change: >> >>> Section 5.4 says: >>> >>> extension-access-info =3D gen-value >>> >>> It should say: >>> >>> extension-access-info =3D generic-param >> >> The generic-param construction allows the NAME =3D VALUE syntax as in th= e TS 24.229 extension Jean mentioned below. >> >> Keeping in mind the RFC in question was for 3GPP: Is anyone aware of imp= lementations of 7315 that would be broken >> by this? From Jean's example, it looks like 3GPP had already assumed gen= eric-param. > > Correct. > > Also, comparing RFC 3455 and RFC 7315, *all but one* of the new access-in= fo parameter values that were added in RFC 7315 follow the generic-param sy= ntax. So, it seems like we in IETF also assumed generic-param when we did = RFC 7315 (and/or we were not concerned about parser issues), but nobody not= iced the ABNF issue. > > And, as I said earlier, I am pretty sure this header is mostly (only?) us= ed in 3GPP environments, and nobody in 3GPP objected to the change I am now= suggesting. It was discussed in 3GPP, and the outcome was to file the erra= ta. > > Finally, as Jean indicated, 3GPP has defined a new value, daylight-saving= -time, which also uses the generic-param syntax. > > Regards, > > Christer > > > On 23 Sep 2015, at 16:23, A. Jean Mahoney wrote: > >> FWIW - TS 24.229, which defines the values for access-info, considers >> extension-access-info to be a generic-param, and not a gen-value as >> specified RFC7315. 3GPP has defined one extension so far (7.2A.4): >> >> >> daylight-saving-time =3D "daylight-saving-time" EQUAL quoted-string >> >> TS 124 229 - V12.9.0 - Digital cellular telecommunications system >> (Phase 2+); Universal Mobile Telecommunications System (UMTS); LTE; IP >> multimedia call control protocol based on Session Initiation Protocol >> (SIP) and Session Description Protocol (SDP); Stage 3 (3GPP TS 24.229 >> version 12.9.0 Release 12) The daylight-saving-time is an instance of >> generic-param from the current extension-access-info component of the >> P- Access-Network-Info header field defined in RFC >> 7315 [52]. >> >> >> Jean >> >> >> >> On 9/23/15 3:47 PM, Cullen Jennings wrote: >>> I can see that it might have been better if it had been done this way >>> Christer is proposing but I don't see how you can change it now. This >>> change would break existing parsers that checked this. That does not >>> seem like an errata level thing to me. >>> >>> >>>> On Sep 21, 2015, at 10:30 AM, Ben Campbell wrote: >>>> >>>> sipcore and dispatch chairs: >>>> >>>> Do you have any concerns about accepting Christer's errata? (I note >>>> RFC 7315 was an orphaned sipping draft progressed as AD sponsored.) >>>> >>>> Ben. >>>> >>>> Forwarded message: >>>> >>>>> From: Christer Holmberg >>>>> To: Ben Campbell >>>>> Cc: sipcore@ietf.org >>>>> Subject: Re: [sipcore] [Technical Errata Reported] RFC7315 (4474) >>>>> Date: Mon, 21 Sep 2015 10:26:26 +0000 >>>>> >>>>> Any news on this? >>>>> >>>>> Regards, >>>>> >>>>> Christer >>>>> >>>>> From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of >>>>> Christer Holmberg >>>>> Sent: 14. syyskuuta 2015 23:24 >>>>> To: Ben Campbell >>>>> Cc: sipcore@ietf.org >>>>> Subject: Re: [sipcore] [Technical Errata Reported] RFC7315 (4474) >>>>> >>>>> Hi Ben, >>>>> >>>>> I am pretty sure generic-param was the original intention. The >>>>> majority of all existing value follow the generic-param syntax, and >>>>> I can't think of any reason why new values would not follow the >>>>> same syntax. That is how it works for other header fields too. >>>>> >>>>> I think this is due to a mistake, where someone thought that >>>>> extension-access-info represents the actual parameter name, and >>>>> therefor only a value (gen-value) is needed. But, >>>>> extension-access-info represents the whole rule (name AND value), >>>>> why generic-param is needed :) >>>>> >>>>> Regards, >>>>> >>>>> Christer >>>>> >>>>> Sent from my Windows Phone >>>>> ________________________________ >>>>> From: Ben Campbell >>>>> Sent: =FD14/=FD09/=FD2015 21:31 >>>>> To: Christer Holmberg >>>>> Cc: sipcore@ietf.org >>>>> Subject: Re: [sipcore] [Technical Errata Reported] RFC7315 (4474) >>>>> Hi Christer, >>>>> >>>>> Is it your understanding that the use of generic-param was the >>>>> actual intention at the time 7315 was published? Or was gen-value >>>>> the original intention, but we now think that it should have been >>>>> generic-param? >>>>> >>>>> Thanks! >>>>> >>>>> Ben. >>>>> >>>>> On 14 Sep 2015, at 6:22, Christer Holmberg wrote: >>>>> >>>>>> FYI, >>>>>> >>>>>> I've now submitted the errata. >>>>>> >>>>>> Regards, >>>>>> >>>>>> Christer >>>>>> >>>>>> -----Original Message----- >>>>>> From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] >>>>>> Sent: 14. syyskuuta 2015 14:21 >>>>>> To: r.jesske@telekom.de; >>>>>> drage@alcatel-lucent.com; >>>>>> Christer Holmberg; >>>>>> iesg@ietf.org >>>>>> Cc: Christer Holmberg; >>>>>> rfc-editor@rfc-editor.org >>>>>> Subject: [Technical Errata Reported] RFC7315 (4474) >>>>>> >>>>>> The following errata report has been submitted for RFC7315, >>>>>> "Private Header (P-Header) Extensions to the Session Initiation >>>>>> Protocol >>>>>> (SIP) >>>>>> for the 3GPP". >>>>>> >>>>>> -------------------------------------- >>>>>> You may review the report below and at: >>>>>> http://www.rfc-editor.org/errata_search.php?rfc=3D7315&eid=3D4474 >>>>>> >>>>>> -------------------------------------- >>>>>> Type: Technical >>>>>> Reported by: Christer Holmberg >>>>>> >>>>> com>> >>>>>> >>>>>> Section: 5.4 >>>>>> >>>>>> Original Text >>>>>> ------------- >>>>>> extension-access-info =3D gen-value >>>>>> >>>>>> Corrected Text >>>>>> -------------- >>>>>> extension-access-info =3D generic-param >>>>>> >>>>>> Notes >>>>>> ----- >>>>>> Most of the pre-defined access-info values are following the >>>>>> generic-param syntax. New access-info values (extensions) should >>>>>> also be allowed to follow the generic-param syntax, in order to >>>>>> allow both for a name and value of the extension. >>>>>> >>>>>> Instructions: >>>>>> ------------- >>>>>> This erratum is currently posted as "Reported". If necessary, >>>>>> please use "Reply All" to discuss whether it should be verified or >>>>>> rejected. >>>>>> When a decision is reached, the verifying party (IESG) can log in >>>>>> to change the status and edit the report, if necessary. >>>>>> >>>>>> -------------------------------------- >>>>>> RFC7315 (draft-drage-sipping-rfc3455bis-14) >>>>>> -------------------------------------- >>>>>> Title : Private Header (P-Header) Extensions to the >>>>>> Session Initiation Protocol (SIP) for the 3GPP >>>>>> Publication Date : July 2014 >>>>>> Author(s) : R. Jesske, K. Drage, C. Holmberg >>>>>> Category : INFORMATIONAL >>>>>> Source : IETF - NON WORKING GROUP >>>>>> Area : N/A >>>>>> Stream : IETF >>>>>> Verifying Party : IESG >>>>>> >>>>>> _______________________________________________ >>>>>> sipcore mailing list >>>>>> sipcore@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/sipcore >>>>> _______________________________________________ >>>>> sipcore mailing list >>>>> sipcore@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sipcore > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch --_000_7594FB04B1934943A5C02806D1A2204B37B346ABESESSMB209erics_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
Hi Cullen,
So, you are suggesting a SIPCORE draft that updates the ABNF?

Regards,

Christer

Sent from my Windows Phone

From: Cullen Jennings
Sent: =FD08= /=FD10/=FD2015 23:17
To: Christer Holmberg Cc: Ben Campbell; SIPCORE; DISPATCH list
Subject: Re: [= dispatch] [sipcore] [Technical Errata Reported] RFC7315 (4474)


My 2 cents is still more appropriate to fix it with a draft that epodes&nbs= p; it not an Errata. Imagine an SBC or Firewall that is checking the SIP sy= ntax using the ABNF. The odds of them seeing this change and implementing i= t much better with an RFC than an errata. Total work either way is minimal.


> On Sep 30, 2015, at 9:12 AM, Christer Holmberg <christer.holmberg@e= ricsson.com> wrote:
>
> Hi,
>
>> (+sipcore, dispatch)
>> (as individual)
>>
>> I just realized this discussion did not include the sipcore or dis= patch lists, and probably should.
>>
>> Recap: Christer proposed an errata (4474) to RFC 7315. It proposes= the following change:
>>
>>> Section 5.4 says:
>>>
>>> extension-access-info  =3D gen-value
>>>
>>> It should say:
>>>
>>> extension-access-info  =3D generic-param
>>
>> The generic-param construction allows the NAME =3D VALUE syntax as= in the TS 24.229 extension Jean mentioned below.
>>
>> Keeping in mind the RFC in question was for 3GPP: Is anyone aware = of implementations of 7315 that would be broken
>> by this? From Jean's example, it looks like 3GPP had already assum= ed generic-param.
>
> Correct.
>
> Also, comparing RFC 3455 and RFC 7315, *all but one* of the new access= -info parameter values that were added in RFC 7315 follow the generic-param= syntax.  So, it seems like we in IETF also assumed generic-param when= we did RFC 7315 (and/or we were not concerned about parser issues), but nobody noticed the ABNF issue.
>
> And, as I said earlier, I am pretty sure this header is mostly (only?)= used in 3GPP environments, and nobody in 3GPP objected to the change I am = now suggesting. It was discussed in 3GPP, and the outcome was to file the e= rrata.
>
> Finally, as Jean indicated, 3GPP has defined a new value, daylight-sav= ing-time, which also uses the generic-param syntax.
>
> Regards,
>
> Christer
>
>
> On 23 Sep 2015, at 16:23, A. Jean Mahoney wrote:
>
>> FWIW - TS 24.229, which defines the values for access-info, consid= ers
>> extension-access-info to be a generic-param, and not a gen-value a= s
>> specified RFC7315. 3GPP has defined one extension so far (7.2A.4):=
>>
>>
>> daylight-saving-time =3D "daylight-saving-time" EQUAL qu= oted-string
>>
>> TS 124 229 - V12.9.0 - Digital cellular telecommunications system =
>> (Phase 2+); Universal Mobile Telecommunications System (UMTS);= LTE; IP
>> multimedia call control protocol based on Session Initiation Proto= col
>> (SIP) and Session Description Protocol (SDP); Stage 3 (3GPP TS 24.= 229
>> version 12.9.0 Release 12) The daylight-saving-time is an instance= of
>> generic-param from the current extension-access-info component of = the
>> P- Access-Network-Info header field defined in RFC
>> 7315 [52].
>>
>>
>> Jean
>>
>>
>>
>> On 9/23/15 3:47 PM, Cullen Jennings wrote:
>>> I can see that it might have been better if it had been done t= his way
>>> Christer is proposing but I don't see how you can change it no= w. This
>>> change would break existing parsers that checked this. That do= es not
>>> seem like an errata level thing to me.
>>>
>>>
>>>> On Sep 21, 2015, at 10:30 AM, Ben Campbell <ben@nostrum= .com> wrote:
>>>>
>>>> sipcore and dispatch chairs:
>>>>
>>>> Do you have any concerns about accepting Christer's errata= ? (I note
>>>> RFC 7315 was an orphaned sipping draft progressed as AD sp= onsored.)
>>>>
>>>> Ben.
>>>>
>>>> Forwarded message:
>>>>
>>>>> From: Christer Holmberg <christer.holmberg@ericsson= .com>
>>>>> To: Ben Campbell <ben@nostrum.com>
>>>>> Cc: sipcore@ietf.org <sipcore@ietf.org>
>>>>> Subject: Re: [sipcore] [Technical Errata Reported] RFC= 7315 (4474)
>>>>> Date: Mon, 21 Sep 2015 10:26:26 +0000
>>>>>
>>>>> Any news on this?
>>>>>
>>>>> Regards,
>>>>>
>>>>> Christer
>>>>>
>>>>> From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of
>>>>> Christer Holmberg
>>>>> Sent: 14. syyskuuta 2015 23:24
>>>>> To: Ben Campbell
>>>>> Cc: sipcore@ietf.org
>>>>> Subject: Re: [sipcore] [Technical Errata Reported] RFC= 7315 (4474)
>>>>>
>>>>> Hi Ben,
>>>>>
>>>>> I am pretty sure generic-param was the original intent= ion. The
>>>>> majority of all existing value follow the generic-para= m syntax, and
>>>>> I can't think of any reason why new values would not f= ollow the
>>>>> same syntax. That is how it works for other header fie= lds too.
>>>>>
>>>>> I think this is due to a mistake, where someone though= t that
>>>>> extension-access-info  represents the actual para= meter name, and
>>>>> therefor only a value (gen-value) is needed. But,
>>>>> extension-access-info represents the whole rule (name = AND value),
>>>>> why generic-param is needed :)
>>>>>
>>>>> Regards,
>>>>>
>>>>> Christer
>>>>>
>>>>> Sent from my Windows Phone
>>>>> ________________________________
>>>>> From: Ben Campbell<mailto:ben@nostrum.com>
>>>>> Sent: =FD14/=FD09/=FD2015 21:31
>>>>> To: Christer Holmberg<mailto:christer.holmberg@ericsson.com>
>>>>> Cc: sipcore@ietf.org<mailto:sipcore@ietf.org>
>>>>> Subject: Re: [sipcore] [Technical Errata Reported] RFC= 7315 (4474)
>>>>> Hi Christer,
>>>>>
>>>>> Is it your understanding that the use of generic-param= was the
>>>>> actual intention at the time 7315 was published? Or wa= s gen-value
>>>>> the original intention, but we now think that it shoul= d have been
>>>>> generic-param?
>>>>>
>>>>> Thanks!
>>>>>
>>>>> Ben.
>>>>>
>>>>> On 14 Sep 2015, at 6:22, Christer Holmberg wrote:
>>>>>
>>>>>> FYI,
>>>>>>
>>>>>> I've now submitted the errata.
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Christer
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: RFC Errata System [mailto:rfc-editor@rfc-editor.org]
>>>>>> Sent: 14. syyskuuta 2015 14:21
>>>>>> To: r.jesske@telekom.de<mailto:r.jesske@telekom.de>;
>>>>>> drage@alcatel-lucent.com<mailto:drage@alcatel-l= ucent.com>;
>>>>>> Christer Holmberg;
>>>>>> iesg@ietf.org<= mailto:iesg@ietf.org>
>>>>>> Cc: Christer Holmberg;
>>>>>> rfc-editor@rfc-editor.org<mailto:rfc-editor@rfc= -editor.org>
>>>>>> Subject: [Technical Errata Reported] RFC7315 (4474= )
>>>>>>
>>>>>> The following errata report has been submitted for= RFC7315,
>>>>>> "Private Header (P-Header) Extensions to the = Session Initiation
>>>>>> Protocol
>>>>>> (SIP)
>>>>>> for the 3GPP".
>>>>>>
>>>>>> --------------------------------------
>>>>>> You may review the report below and at:
>>>>>> http://www.rfc-editor.org/errata_search.php= ?rfc=3D7315&eid=3D4474
>>>>>>
>>>>>> --------------------------------------
>>>>>> Type: Technical
>>>>>> Reported by: Christer Holmberg
>>>>>> <christer.holmberg@ericsson.com<mailto:chris= ter.holmberg@ericsson.
>>>>>> com>>
>>>>>>
>>>>>> Section: 5.4
>>>>>>
>>>>>> Original Text
>>>>>> -------------
>>>>>> extension-access-info  =3D gen-value
>>>>>>
>>>>>> Corrected Text
>>>>>> --------------
>>>>>> extension-access-info  =3D generic-param
>>>>>>
>>>>>> Notes
>>>>>> -----
>>>>>> Most of the pre-defined access-info values are fol= lowing the
>>>>>> generic-param syntax. New access-info values (exte= nsions) should
>>>>>> also be allowed to follow the generic-param syntax= , in order to
>>>>>> allow both for a name and value of the extension.<= br> >>>>>>
>>>>>> Instructions:
>>>>>> -------------
>>>>>> This erratum is currently posted as "Reported= ". If necessary,
>>>>>> please use "Reply All" to discuss whethe= r it should be verified or
>>>>>> rejected.
>>>>>> When a decision is reached, the verifying party (I= ESG) can log in
>>>>>> to change the status and edit the report, if neces= sary.
>>>>>>
>>>>>> --------------------------------------
>>>>>> RFC7315 (draft-drage-sipping-rfc3455bis-14)
>>>>>> --------------------------------------
>>>>>> Title       &nb= sp;       : Private Header (P-Header) Extensi= ons to the
>>>>>> Session Initiation Protocol (SIP) for the 3GPP
>>>>>> Publication Date    : July 2014
>>>>>> Author(s)       = ;    : R. Jesske, K. Drage, C. Holmberg
>>>>>> Category       =      : INFORMATIONAL
>>>>>> Source       &n= bsp;      : IETF - NON WORKING GROUP
>>>>>> Area       &nbs= p;        : N/A
>>>>>> Stream       &n= bsp;      : IETF
>>>>>> Verifying Party     : IESG
>>>>>>
>>>>>> _______________________________________________ >>>>>> sipcore mailing list
>>>>>> sipcore@ietf.org<mailto:sipcore@ietf.org>
>>>>>> https://www.ietf.org/mailman/listinfo/sipcore
>>>>> _______________________________________________
>>>>> sipcore mailing list
>>>>> sipcore@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/sipcore
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www= .ietf.org/mailman/listinfo/dispatch

--_000_7594FB04B1934943A5C02806D1A2204B37B346ABESESSMB209erics_-- From nobody Wed Oct 14 07:21:06 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC5941A212D; Wed, 14 Oct 2015 07:21:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 lOji1xrZrUbc; Wed, 14 Oct 2015 07:21:02 -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 B2B151A00A7; Wed, 14 Oct 2015 07:21:02 -0700 (PDT) Received: from [10.0.1.9] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t9EEKua9062938 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 14 Oct 2015 09:20:57 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.9] From: "Ben Campbell" To: "Christer Holmberg" Date: Wed, 14 Oct 2015 09:20:56 -0500 Message-ID: <80DA0B29-EDE9-4DDE-948B-463A364A2E0F@nostrum.com> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37B346AB@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37AC0CF1@ESESSMB209.ericsson.se> <3308F2DE-08F1-46A0-BC01-2445627BAD53@iii.ca> <56031836.3080407@nostrum.com> <4E205A3B-F608-48D3-9DA5-D2220A97D953@nostrum.com> <7594FB04B1934943A5C02806D1A2204B37AE6750@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37B346AB@ESESSMB209.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.2r5141) Archived-At: Cc: DISPATCH list , SIPCORE , Cullen Jennings Subject: Re: [dispatch] [sipcore] [Technical Errata Reported] RFC7315 (4474) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2015 14:21:04 -0000 On 8 Oct 2015, at 21:03, Christer Holmberg wrote: > Hi Cullen, > > So, you are suggesting a SIPCORE draft that updates the ABNF? This is where the chairs will point out that special-purpose extensions are generally not in scope for sipcore :-) If so, this might could also be done as AD sponsored. Ben. From nobody Sun Oct 18 00:52:32 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A0091B2DFE; Sun, 18 Oct 2015 00:52:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 VAYD_Y5Kh7_I; Sun, 18 Oct 2015 00:52:28 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 684251A8A20; Sun, 18 Oct 2015 00:52:27 -0700 (PDT) X-AuditID: c1b4fb3a-f79136d0000071e2-b7-56234fb99de2 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 63.02.29154.9BF43265; Sun, 18 Oct 2015 09:52:25 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.61]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0248.002; Sun, 18 Oct 2015 09:52:24 +0200 From: Christer Holmberg To: Ben Campbell Thread-Topic: [sipcore] [dispatch] [Technical Errata Reported] RFC7315 (4474) Thread-Index: AQHRAjatMgpPsiF4akOaFmByCBAVyZ5q8SAAgAX+TUk= Date: Sun, 18 Oct 2015 07:52:24 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37B5BC73@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37AC0CF1@ESESSMB209.ericsson.se> <3308F2DE-08F1-46A0-BC01-2445627BAD53@iii.ca> <56031836.3080407@nostrum.com> <4E205A3B-F608-48D3-9DA5-D2220A97D953@nostrum.com> <7594FB04B1934943A5C02806D1A2204B37AE6750@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37B346AB@ESESSMB209.ericsson.se>, <80DA0B29-EDE9-4DDE-948B-463A364A2E0F@nostrum.com> In-Reply-To: <80DA0B29-EDE9-4DDE-948B-463A364A2E0F@nostrum.com> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B37B5BC73ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpjkeLIzCtJLcpLzFFi42KZGfG3Rnenv3KYwcrt0hbzO0+zWyydtIDV 4sP6H4wWX39sYnNg8Viy5CeTx+XzHxk9Zu18whLAHMVlk5Kak1mWWqRvl8CVsW19acFmmYrP Z3ayNDC+lehi5OSQEDCROLrpMTuELSZx4d56NhBbSOAoo8TiBqUuRi4gezGjxJVL14GKODjY BCwkuv9pg9SICChJPG/eygJiMwukSHROW8YEYgsL+Ej8ObeHEaLGV2L3jX42CNtK4ubp2WBj WARUJVb98gcJ8wKVfNk2hwli1UdmiZ9Nt8DqOQXsJTbtOcsKYjMC3fb91BomiF3iEk1fVrJC 3CwgsWTPeWYIW1Ti5eN/rBA1+RLT9/SzQCwQlDg58wnLBEaRWUjaZyEpm4WkDCJuIPHl/W0o W1ti2cLXzBC2vkT3+9NMyOILGNlXMYoWpxYX56YbGemlFmUmFxfn5+nlpZZsYgRG3MEtv612 MB587niIUYCDUYmH98ERpTAh1sSy4srcQ4zSHCxK4rzNTA9ChQTSE0tSs1NTC1KL4otKc1KL DzEycXBKNTAG1C93eOR9eAfLmo+hK95J93Bo3Z29UqLg8BJ7lWNX/rTdf+17ozg3U/eXkV5J s0vhzKI1vCklFzoTxVKPiza0BL6t3cCx62vI6X8tN83EwzbYJG+SZc2dUmuvdocxYa9OR7Hb 8yPqaXNZVmz5VvDwfGnRwlnSE7wnXYrMXOL2yciumf/iaT4lluKMREMt5qLiRAA11kpKmQIA AA== Archived-At: Cc: DISPATCH list , SIPCORE , Cullen Jennings Subject: Re: [dispatch] [sipcore] [Technical Errata Reported] RFC7315 (4474) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Oct 2015 07:52:29 -0000 --_000_7594FB04B1934943A5C02806D1A2204B37B5BC73ESESSMB209erics_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable Hi, So, shall I address the draft to some WG, or? draft-holmberg-dispatch ? Regards, Christer Sent from my Windows Phone ________________________________ From: Ben Campbell Sent: =FD14/=FD10/=FD2015 17:21 To: Christer Holmberg Cc: Cullen Jennings; DISPATCH list; SIPCORE Subject: Re: [sipcore] [dispatch] [Technical Errata Reported] RFC7315 (4474= ) On 8 Oct 2015, at 21:03, Christer Holmberg wrote: > Hi Cullen, > > So, you are suggesting a SIPCORE draft that updates the ABNF? This is where the chairs will point out that special-purpose extensions are generally not in scope for sipcore :-) If so, this might could also be done as AD sponsored. Ben. --_000_7594FB04B1934943A5C02806D1A2204B37B5BC73ESESSMB209erics_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
Hi,

So, shall I address the draft to some WG, or?

draft-holmberg-dispatch ?

Regards,

Christer

Sent from my Windows Phone

From: Ben Campbell
Sent: =FD14= /=FD10/=FD2015 17:21
To: Christer Holmberg Cc: Cullen Jennings; DISPATCH list; SIPCORE
Subject: Re: [= sipcore] [dispatch] [Technical Errata Reported] RFC7315 (4474)

On 8 Oct 2015, at 21:03, Christer Holmberg wrote:<= br>
> Hi Cullen,
>
> So, you are suggesting a SIPCORE draft that updates the ABNF?

This is where the chairs will point out that special-purpose extensions are generally not in scope for sipcore :-) If so, this might could also be done as AD sponsored.

Ben.

--_000_7594FB04B1934943A5C02806D1A2204B37B5BC73ESESSMB209erics_-- From nobody Sun Oct 18 04:49:28 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D423F1A1A9D; Sun, 18 Oct 2015 04:49:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 CDJVU87NM925; Sun, 18 Oct 2015 04:49:26 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3BDE1A1A98; Sun, 18 Oct 2015 04:49:24 -0700 (PDT) X-AuditID: c1b4fb2d-f79626d000004282-36-56238742a455 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id B9.C0.17026.24783265; Sun, 18 Oct 2015 13:49:22 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.61]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0248.002; Sun, 18 Oct 2015 13:49:22 +0200 From: Christer Holmberg To: Ben Campbell , DISPATCH list , SIPCORE Thread-Topic: Draft new: draft-holmberg-dispatch-pani-abnf-00 [was: [sipcore] [dispatch] [Technical Errata Reported] RFC7315 (4474)] Thread-Index: AdEJmu30RT4yoyGuQwycw+O/R8vMMg== Date: Sun, 18 Oct 2015 11:49:21 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37B62FC0@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B37B62FC0ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrMLMWRmVeSWpSXmKPExsUyM+Jvja5Tu3KYwdlmc4v5nafZLZZOWsBq 8fXHJjYHZo8lS34yecza+YQlgCmKyyYlNSezLLVI3y6BK6NvfW3B64yKnz86GRsYj8d2MXJy SAiYSOxsnMsGYYtJXLi3Hsjm4hASOMoo0T79AROEs5hR4v+le6xdjBwcbAIWEt3/tEEaRASS JR7Ous8OUiMs0MgosXzmQRaIRBujxOJ7dSD1IgJ6EjuupoKYLAKqEr/3moCYvAK+Ere2eoIU MwKt/X5qDROIzSwgLnHryXwmiHMEJJbsOc8MYYtKvHz8jxXCVpJYe3g7C0R9vkR7WwdYDa+A oMTJmU9YJjAKzUIyahaSsllIyiDiBhLntm9kh7C1JZYtfM0MYetLbL89kxVZfAEj+ypG0eLU 4uLcdCNjvdSizOTi4vw8vbzUkk2MwFg5uOW37g7G1a8dDzEKcDAq8fA+OKIUJsSaWFZcmXuI UZqDRUmct4XpQaiQQHpiSWp2ampBalF8UWlOavEhRiYOTqkGxuAtE4M78+Xn+BsUlh6ICK47 KuXmo3Ob0/OO3f3Yk8Iy0lfrLr4M9/z4xf2LtF8jp9SaOVt2vfUpq8i6/uvyZtHCLjnONOVp EZMVjjAsqZrqKC3dcz8vo/bp1bNK/oe5TlxrXim58FFCQc8TJgOhcy9fPKp5tXzpa4MZOq5T nrMGz69LNxORU2Ipzkg01GIuKk4EAI7UgWV2AgAA Archived-At: Subject: [dispatch] Draft new: draft-holmberg-dispatch-pani-abnf-00 [was: [sipcore] [Technical Errata Reported] RFC7315 (4474)] X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Oct 2015 11:49:28 -0000 --_000_7594FB04B1934943A5C02806D1A2204B37B62FC0ESESSMB209erics_ Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Hi, Based on Ben=92s guidance, I=92ve submitted a draft which makes the ABNF up= date. NOTE: As RFC 7315 is an Informational RFC, I had to add the RFC as an Infor= mative reference in the draft, in order to pass the Idnits check. A new version of I-D, draft-holmberg-dispatch-pani-abnf-00.txt has been successfully submitted by Christer Holmberg and posted to the IETF= repository. Name: draft-holmberg-dispatch-pani-abnf Revision: 00 Title: P-Access-Network-Info ABNF Update Document date: 2015-10-18 Group: Individual Submission Pages: 4 URL: https://www.ietf.org/internet-drafts/draft-holmberg-dispatc= h-pani-abnf-00.txt Status: https://datatracker.ietf.org/doc/draft-holmberg-dispatch-pa= ni-abnf/ Htmlized: https://tools.ietf.org/html/draft-holmberg-dispatch-pani-ab= nf-00 Abstract: This document updates RFC 7315, by modifying the extension-access- info part of the P-Access-Network-Info header field Augmented Backus- Naur Form (ABNF). Regards, Christer From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmb= erg Sent: 18 October 2015 10:52 To: Ben Campbell Cc: DISPATCH list ; SIPCORE ; Cullen J= ennings Subject: Re: [sipcore] [dispatch] [Technical Errata Reported] RFC7315 (4474= ) Hi, So, shall I address the draft to some WG, or? draft-holmberg-dispatch ? Regards, Christer Sent from my Windows Phone ________________________________ From: Ben Campbell Sent: =FD14/=FD10/=FD2015 17:21 To: Christer Holmberg Cc: Cullen Jennings; DISPATCH list; SIPCORE Subject: Re: [sipcore] [dispatch] [Technical Errata Reported] RFC7315 (4474= ) On 8 Oct 2015, at 21:03, Christer Holmberg wrote: > Hi Cullen, > > So, you are suggesting a SIPCORE draft that updates the ABNF? This is where the chairs will point out that special-purpose extensions are generally not in scope for sipcore :-) If so, this might could also be done as AD sponsored. Ben. --_000_7594FB04B1934943A5C02806D1A2204B37B62FC0ESESSMB209erics_ Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable

Hi,

 = ;

Based on B= en=92s guidance, I=92ve submitted a draft which makes the ABNF update.=

 = ;

NOTE: As R= FC 7315 is an Informational RFC, I had to add the RFC as an Informative ref= erence in the draft, in order to pass the Idnits check.

 = ;

A new version of I-D, draft-holmberg-dispatch-pan= i-abnf-00.txt

has been successfully submitted by Christer Holmb= erg and posted to the IETF repository.

 

Name:       &n= bsp;         draft-holmberg-dispatc= h-pani-abnf

Revision:      &nbs= p;     00

Title:       &= nbsp;            P-A= ccess-Network-Info ABNF Update

Document date:      = ;        2015-10-18

Group:       &= nbsp;        Individual Submission<= /o:p>

Pages:       &= nbsp;         4

URL:       &nb= sp;    https://www.ietf.org/internet-drafts/draft-holmberg-dispatch-pani-abnf-00.t= xt

Status:       =   https://datatracker.ietf.org/doc/draft-holmberg-dispatch-pani-abnf/

Htmlized:       https://tools.ietf.org/html/draft-holmberg-dispatch-pani-abnf-00

 

 

Abstract:

   This document updates RFC 7315, by m= odifying the extension-access-

   info part of the P-Access-Network-In= fo header field Augmented Backus-

   Naur Form (ABNF).

        &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;

Regards,

 = ;

Christer

 

 = ;

 

From: = sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: 18 October 2015 10:52
To: Ben Campbell <ben@nostrum.com>
Cc: DISPATCH list <dispatch@ietf.org>; SIPCORE <sipcore@iet= f.org>; Cullen Jennings <fluffy@iii.ca>
Subject: Re: [sipcore] [dispatch] [Technical Errata Reported] RFC731= 5 (4474)

 

Hi,

So, shall I address the draft to some WG, or?

draft-holmberg-dispatch ?

Regards,

Christer

Sent from my Windows Phone


From: Ben Campbell
Sent: =FD14/=FD10/=FD2015 17:21
To: Chris= ter Holmberg
Cc: Cullen Jennings; DISPATCH list; SIPCORE
Subject: Re: [sipcore] [dispatch] [Technical Errata Reported] RFC7315 (4474)

On 8 Oct 2015, at 21:03, Christer Holmberg wrote:

> Hi Cullen,
>
> So, you are suggesting a SIPCORE draft that updates the ABNF?

This is where the chairs will point out that special-purpose extensions are generally not in scope for sipcore :-) If so, this might could also be done as AD sponsored.

Ben.

--_000_7594FB04B1934943A5C02806D1A2204B37B62FC0ESESSMB209erics_-- From nobody Sun Oct 18 10:57:43 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39E011AC406 for ; Sun, 18 Oct 2015 10:57:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.701 X-Spam-Level: X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 4TNcf5zXUury for ; Sun, 18 Oct 2015 10:57:41 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D41DA1A90F1 for ; Sun, 18 Oct 2015 10:57:40 -0700 (PDT) Received: from [192.168.2.129] ([188.100.175.162]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MBFgr-1ZfvbL2jZ7-00AE0R for ; Sun, 18 Oct 2015 19:57:38 +0200 To: dispatch@ietf.org References: From: "Sebastian G. " Openpgp: id=BFE90DE515B6F548CDE298939902921C2B944DAE X-Enigmail-Draft-Status: N1110 Message-ID: <5623DD8F.1040406@gmx.de> Date: Sun, 18 Oct 2015 19:57:35 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:HG3iq4243EkKuZhc9bN7y9oGb/LHvaIGFKFBfTPzk4L3oKvGKz2 xhjdX33cyyBn89NG/2PzMGGZ8t3U0n98V89teCMeRch0zmJgUyhCpD6IM6+a3Xgf65KTDyj uvhSIur7NGXd19SkN8HE9ySLVICvprtdbouAfpDyOPKGCoZij601g5sUj4b05xw/Eh9KP8u 65hFMCxqdWQ2sAIzbCPdg== X-UI-Out-Filterresults: notjunk:1;V01:K0:3D2OUn/n7QU=:grvW/slzvpdFqRoatUHobm /IOMaln+C8thp8xpANdD0u96RqO4H+47NRGEkuC2k+lUzfftPA4Xx4jgoZkxM7oPxf9Bjmgpx P8M9VPxpdFXA4skdHFP+xd5lHo1sk/9Pxa0fNHhYYMKjOzQ2tJBYr4b58Q8vfDLFKqcO0K34s LUJdslE/6iCg5XRJxQCoHX7hC3jkQyFlPVLaGAqwWYFeZaccN0W8cD1fYivbJVL1eE08H4f24 eMJwBu3hPc15r9mSeJvy35qzwFW9vYbOvbvXETWB0P6x/Z/bGuig188OYKui8S2xHrLSO/PvT nrrTGX6lJMClmSiV/WTZe+CfHLIvmoO9gKSBR/AmJ0zLWLo7sveW7G+GOwgmBUUBs8/Bdcg7Q sBDanPZs/ZQ+tORClGO/+5WkUpByNVM6dniaNvl72t5R0mHigE/MKUTV91uUHXr04IrmbjSnv 56k1CkepqZM7ydGBCf8jh7HDaScdQAdeUDFUiVvdx1HX4fpf0zge1/VXkuMuG6P9Xiy8sG46s fUFq+Gu+QzEPGRhuEJhQcFb1vWn6FBLCWU4HtxyIVikJAfau7jfv+P+2h/sDgR88Le3zd6F8a rSFLeILNlDu3F7VW4OkPuBkgSlP/aj71gMneBIxBJ48OwZdTyJmIpc0koO8aAxp6VM/UPGOFb t2Y3bNIiYXkx2h3dV3N2cAFfgodQ4o0pRSz5jJxIKaMgOmNreAvo6y9gcSnSJxTuC32HqDMBx fHbz26fpjQELpzol4e5mkHq02Y1KVi+U9S2fmzcIcImzuE6OS+0CGnYZ/1wniW69dx7Qsxgiy 52ZFEDc Archived-At: Subject: Re: [dispatch] Proposed charter for CELLAR: Codec Encoding for LossLess Archiving and Realtime transmission X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Oct 2015 17:57:42 -0000 08.09.2015, 16:49 Tessa Fallon: +1 (As late arrival) I support the creation of a working group. > *Proposed Name*: CELLAR: Codec Encoding for LossLess Archiving and Realtime > transmission > [...] I have nothing to add to this proposal. Best regards, Sebastian G. (bastik) From nobody Sun Oct 18 11:27:12 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57C881ACD0E; Sun, 18 Oct 2015 11:27:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 FKJZZORhFYqF; Sun, 18 Oct 2015 11:27:08 -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 C89651ACD0C; Sun, 18 Oct 2015 11:27:08 -0700 (PDT) Received: from [10.0.1.9] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t9IIR3pC098379 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sun, 18 Oct 2015 13:27:04 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.9] From: "Ben Campbell" To: "Christer Holmberg" Date: Sun, 18 Oct 2015 13:27:03 -0500 Message-ID: <90429FC5-4199-4386-8CEE-F7F9E45420CE@nostrum.com> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37B62FC0@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37B62FC0@ESESSMB209.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.2r5141) Archived-At: Cc: DISPATCH list , SIPCORE Subject: Re: [dispatch] Draft new: draft-holmberg-dispatch-pani-abnf-00 [was: [sipcore] [Technical Errata Reported] RFC7315 (4474)] X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Oct 2015 18:27:10 -0000 If 7315 is informational, why does the update need to be standards track? Ben. On 18 Oct 2015, at 6:49, Christer Holmberg wrote: > Hi, > > Based on Ben’s guidance, I’ve submitted a draft which makes the > ABNF update. > > NOTE: As RFC 7315 is an Informational RFC, I had to add the RFC as an > Informative reference in the draft, in order to pass the Idnits check. > > > A new version of I-D, draft-holmberg-dispatch-pani-abnf-00.txt > > has been successfully submitted by Christer Holmberg and posted to the > IETF repository. > > > > Name: draft-holmberg-dispatch-pani-abnf > > Revision: 00 > > Title: P-Access-Network-Info ABNF Update > > Document date: 2015-10-18 > > Group: Individual Submission > > Pages: 4 > > URL: > https://www.ietf.org/internet-drafts/draft-holmberg-dispatch-pani-abnf-00.txt > > Status: > https://datatracker.ietf.org/doc/draft-holmberg-dispatch-pani-abnf/ > > Htmlized: > https://tools.ietf.org/html/draft-holmberg-dispatch-pani-abnf-00 > > > > > > Abstract: > > This document updates RFC 7315, by modifying the extension-access- > > info part of the P-Access-Network-Info header field Augmented Backus- > > Naur Form (ABNF). > > > Regards, > > Christer > > > > > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer > Holmberg > Sent: 18 October 2015 10:52 > To: Ben Campbell > Cc: DISPATCH list ; SIPCORE ; > Cullen Jennings > Subject: Re: [sipcore] [dispatch] [Technical Errata Reported] RFC7315 > (4474) > > Hi, > > So, shall I address the draft to some WG, or? > > draft-holmberg-dispatch ? > > Regards, > > Christer > > Sent from my Windows Phone > ________________________________ > From: Ben Campbell > Sent: ‎14/‎10/‎2015 17:21 > To: Christer Holmberg > Cc: Cullen Jennings; DISPATCH > list; SIPCORE > Subject: Re: [sipcore] [dispatch] [Technical Errata Reported] RFC7315 > (4474) > On 8 Oct 2015, at 21:03, Christer Holmberg wrote: > >> Hi Cullen, >> >> So, you are suggesting a SIPCORE draft that updates the ABNF? > > This is where the chairs will point out that special-purpose > extensions > are generally not in scope for sipcore :-) If so, this might could > also > be done as AD sponsored. > > Ben. From nobody Sun Oct 18 11:27:52 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7A901ACD14; Sun, 18 Oct 2015 11:27:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 8LCwJ12j3Iad; Sun, 18 Oct 2015 11:27:48 -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 D536D1ACD0C; Sun, 18 Oct 2015 11:27:47 -0700 (PDT) Received: from [10.0.1.9] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t9IIRhPm098418 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sun, 18 Oct 2015 13:27:44 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.9] From: "Ben Campbell" To: "Christer Holmberg" Date: Sun, 18 Oct 2015 13:27:43 -0500 Message-ID: In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37B5BC73@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37AC0CF1@ESESSMB209.ericsson.se> <3308F2DE-08F1-46A0-BC01-2445627BAD53@iii.ca> <56031836.3080407@nostrum.com> <4E205A3B-F608-48D3-9DA5-D2220A97D953@nostrum.com> <7594FB04B1934943A5C02806D1A2204B37AE6750@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37B346AB@ESESSMB209.ericsson.se> <80DA0B29-EDE9-4DDE-948B-463A364A2E0F@nostrum.com> <7594FB04B1934943A5C02806D1A2204B37B5BC73@ESESSMB209.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.2r5141) Archived-At: Cc: DISPATCH list , SIPCORE , Cullen Jennings Subject: Re: [dispatch] [sipcore] [Technical Errata Reported] RFC7315 (4474) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Oct 2015 18:27:48 -0000 dispatch is the place to start. Thanks! Ben. On 18 Oct 2015, at 2:52, Christer Holmberg wrote: > Hi, > > So, shall I address the draft to some WG, or? > > draft-holmberg-dispatch ? > > Regards, > > Christer > > Sent from my Windows Phone > ________________________________ > From: Ben Campbell > Sent: ‎14/‎10/‎2015 17:21 > To: Christer Holmberg > Cc: Cullen Jennings; DISPATCH > list; SIPCORE > Subject: Re: [sipcore] [dispatch] [Technical Errata Reported] RFC7315 > (4474) > > On 8 Oct 2015, at 21:03, Christer Holmberg wrote: > >> Hi Cullen, >> >> So, you are suggesting a SIPCORE draft that updates the ABNF? > > This is where the chairs will point out that special-purpose > extensions > are generally not in scope for sipcore :-) If so, this might could > also > be done as AD sponsored. > > Ben. From nobody Sun Oct 18 11:59:16 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 802C61ACDF0; Sun, 18 Oct 2015 11:59:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 M2U-zj7N9MRL; Sun, 18 Oct 2015 11:59:13 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7340D1ACDEC; Sun, 18 Oct 2015 11:59:12 -0700 (PDT) X-AuditID: c1b4fb2d-f79626d000004282-98-5623ebfef875 Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 07.29.17026.EFBE3265; Sun, 18 Oct 2015 20:59:10 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.61]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.03.0248.002; Sun, 18 Oct 2015 20:59:09 +0200 From: Christer Holmberg To: Ben Campbell Thread-Topic: Draft new: draft-holmberg-dispatch-pani-abnf-00 [was: [sipcore] [dispatch] [Technical Errata Reported] RFC7315 (4474)] Thread-Index: AQHRCdKZNAGVRpZ6AEOpwBwyzxjoeZ5xml1Q Date: Sun, 18 Oct 2015 18:59:09 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37B6907F@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37B62FC0@ESESSMB209.ericsson.se> <90429FC5-4199-4386-8CEE-F7F9E45420CE@nostrum.com> In-Reply-To: <90429FC5-4199-4386-8CEE-F7F9E45420CE@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrILMWRmVeSWpSXmKPExsUyM+Jvje6/18phBp3XpSzmd55mt1g6aQGr xdcfm9gcmD2WLPnJ5DFr5xOWAKYoLpuU1JzMstQifbsEroxj0+8wFtyQqdjU+4SxgfGHdBcj J4eEgIlE67s57BC2mMSFe+vZuhi5OIQEjjJKvNp/nR3CWcwo8bu1Hcjh4GATsJDo/qcN0iAi oCTxvHkrC0iYWcBRYtqabJByYYFWRok1L1rZIGraGCUW36uDsI0kbh/ZyghiswioSmx4uBBs Ma+Ar8ScOcugFjcxSszb+4MZJMEpYC9x9dAzFhCbEei676fWMIHYzALiEreezGeCuFpAYsme 88wQtqjEy8f/WCFsJYkV2y8xQhynKbF+lz5Eq6LElO6HUHsFJU7OfMIygVFsFpKpsxA6ZiHp mIWkYwEjyypG0eLU4uLcdCNjvdSizOTi4vw8vbzUkk2MwDg6uOW37g7G1a8dDzEKcDAq8fA+ OKIUJsSaWFZcmXuIUZqDRUmct4XpQaiQQHpiSWp2ampBalF8UWlOavEhRiYOTqkGRiMfZw4f 46f+fT+sjp05PO/1pq0VpjYlF8w2mDvc3sq2cemru8G+cfu+eqpVnvvWlXVP7aCYauJc10Pr K2+2/17GN4F12a865cggSwXXKZvdHoVw53q9tFCY+2zSceZroiVJi3NDFyU/nLynPK5puqLX MbUas3CnRa7CvUaznv3O7r63vubJZiWW4oxEQy3mouJEAKNWtZOEAgAA Archived-At: Cc: DISPATCH list , SIPCORE Subject: Re: [dispatch] Draft new: draft-holmberg-dispatch-pani-abnf-00 [was: [sipcore] [Technical Errata Reported] RFC7315 (4474)] X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Oct 2015 18:59:14 -0000 SGksDQoNCj5JZiA3MzE1IGlzIGluZm9ybWF0aW9uYWwsIHdoeSBkb2VzIHRoZSB1cGRhdGUgbmVl ZCB0byBiZSBzdGFuZGFyZHMgdHJhY2s/DQoNCkdvb2QgcG9pbnQgLSBJIGd1ZXNzIGl0IGRvZXNu J3QgaGF2ZSB0byA6KQ0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoNCk9uIDE4IE9jdCAyMDE1 LCBhdCA2OjQ5LCBDaHJpc3RlciBIb2xtYmVyZyB3cm90ZToNCg0KPiBIaSwNCj4NCj4gQmFzZWQg b24gQmVu4oCZcyBndWlkYW5jZSwgSeKAmXZlIHN1Ym1pdHRlZCBhIGRyYWZ0IHdoaWNoIG1ha2Vz IHRoZSBBQk5GIA0KPiB1cGRhdGUuDQo+DQo+IE5PVEU6IEFzIFJGQyA3MzE1IGlzIGFuIEluZm9y bWF0aW9uYWwgUkZDLCBJIGhhZCB0byBhZGQgdGhlIFJGQyBhcyBhbiANCj4gSW5mb3JtYXRpdmUg cmVmZXJlbmNlIGluIHRoZSBkcmFmdCwgaW4gb3JkZXIgdG8gcGFzcyB0aGUgSWRuaXRzIGNoZWNr Lg0KPg0KPg0KPiBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtaG9sbWJlcmctZGlzcGF0Y2gt cGFuaS1hYm5mLTAwLnR4dA0KPg0KPiBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5 IENocmlzdGVyIEhvbG1iZXJnIGFuZCBwb3N0ZWQgdG8gdGhlIA0KPiBJRVRGIHJlcG9zaXRvcnku DQo+DQo+DQo+DQo+IE5hbWU6ICAgICAgICAgICAgICAgICBkcmFmdC1ob2xtYmVyZy1kaXNwYXRj aC1wYW5pLWFibmYNCj4NCj4gUmV2aXNpb246ICAgICAgICAgICAgMDANCj4NCj4gVGl0bGU6ICAg ICAgICAgICAgICAgICAgICBQLUFjY2Vzcy1OZXR3b3JrLUluZm8gQUJORiBVcGRhdGUNCj4NCj4g RG9jdW1lbnQgZGF0ZTogICAgICAgICAgICAgIDIwMTUtMTAtMTgNCj4NCj4gR3JvdXA6ICAgICAg ICAgICAgICAgIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KPg0KPiBQYWdlczogICAgICAgICAgICAg ICAgIDQNCj4NCj4gVVJMOiAgICAgICAgICAgIA0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9pbnRl cm5ldC1kcmFmdHMvZHJhZnQtaG9sbWJlcmctZGlzcGF0Y2gtcGFuaS1hYm5mDQo+IC0wMC50eHQN Cj4NCj4gU3RhdHVzOiAgICAgICAgIA0KPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC1ob2xtYmVyZy1kaXNwYXRjaC1wYW5pLWFibmYvDQo+DQo+IEh0bWxpemVkOiAgICAg ICANCj4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWhvbG1iZXJnLWRpc3BhdGNo LXBhbmktYWJuZi0wMA0KPg0KPg0KPg0KPg0KPg0KPiBBYnN0cmFjdDoNCj4NCj4gVGhpcyBkb2N1 bWVudCB1cGRhdGVzIFJGQyA3MzE1LCBieSBtb2RpZnlpbmcgdGhlIGV4dGVuc2lvbi1hY2Nlc3Mt DQo+DQo+IGluZm8gcGFydCBvZiB0aGUgUC1BY2Nlc3MtTmV0d29yay1JbmZvIGhlYWRlciBmaWVs ZCBBdWdtZW50ZWQgQmFja3VzLQ0KPg0KPiBOYXVyIEZvcm0gKEFCTkYpLg0KPg0KPg0KPiBSZWdh cmRzLA0KPg0KPiBDaHJpc3Rlcg0KPg0KPg0KPg0KPg0KPiBGcm9tOiBzaXBjb3JlIFttYWlsdG86 c2lwY29yZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQ2hyaXN0ZXIgDQo+IEhvbG1i ZXJnDQo+IFNlbnQ6IDE4IE9jdG9iZXIgMjAxNSAxMDo1Mg0KPiBUbzogQmVuIENhbXBiZWxsIDxi ZW5Abm9zdHJ1bS5jb20+DQo+IENjOiBESVNQQVRDSCBsaXN0IDxkaXNwYXRjaEBpZXRmLm9yZz47 IFNJUENPUkUgPHNpcGNvcmVAaWV0Zi5vcmc+OyANCj4gQ3VsbGVuIEplbm5pbmdzIDxmbHVmZnlA aWlpLmNhPg0KPiBTdWJqZWN0OiBSZTogW3NpcGNvcmVdIFtkaXNwYXRjaF0gW1RlY2huaWNhbCBF cnJhdGEgUmVwb3J0ZWRdIFJGQzczMTUNCj4gKDQ0NzQpDQo+DQo+IEhpLA0KPg0KPiBTbywgc2hh bGwgSSBhZGRyZXNzIHRoZSBkcmFmdCB0byBzb21lIFdHLCBvcj8NCj4NCj4gZHJhZnQtaG9sbWJl cmctZGlzcGF0Y2ggPw0KPg0KPiBSZWdhcmRzLA0KPg0KPiBDaHJpc3Rlcg0KPg0KPiBTZW50IGZy b20gbXkgV2luZG93cyBQaG9uZQ0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PiBGcm9tOiBCZW4gQ2FtcGJlbGw8bWFpbHRvOmJlbkBub3N0cnVtLmNvbT4NCj4gU2VudDog4oCO MTQv4oCOMTAv4oCOMjAxNSAxNzoyMQ0KPiBUbzogQ2hyaXN0ZXIgSG9sbWJlcmc8bWFpbHRvOmNo cmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4NCj4gQ2M6IEN1bGxlbiBKZW5uaW5nczxtYWls dG86Zmx1ZmZ5QGlpaS5jYT47IERJU1BBVENIIA0KPiBsaXN0PG1haWx0bzpkaXNwYXRjaEBpZXRm Lm9yZz47IFNJUENPUkU8bWFpbHRvOnNpcGNvcmVAaWV0Zi5vcmc+DQo+IFN1YmplY3Q6IFJlOiBb c2lwY29yZV0gW2Rpc3BhdGNoXSBbVGVjaG5pY2FsIEVycmF0YSBSZXBvcnRlZF0gUkZDNzMxNQ0K PiAoNDQ3NCkNCj4gT24gOCBPY3QgMjAxNSwgYXQgMjE6MDMsIENocmlzdGVyIEhvbG1iZXJnIHdy b3RlOg0KPg0KPj4gSGkgQ3VsbGVuLA0KPj4NCj4+IFNvLCB5b3UgYXJlIHN1Z2dlc3RpbmcgYSBT SVBDT1JFIGRyYWZ0IHRoYXQgdXBkYXRlcyB0aGUgQUJORj8NCj4NCj4gVGhpcyBpcyB3aGVyZSB0 aGUgY2hhaXJzIHdpbGwgcG9pbnQgb3V0IHRoYXQgc3BlY2lhbC1wdXJwb3NlIA0KPiBleHRlbnNp b25zIGFyZSBnZW5lcmFsbHkgbm90IGluIHNjb3BlIGZvciBzaXBjb3JlIDotKSBJZiBzbywgdGhp cyANCj4gbWlnaHQgY291bGQgYWxzbyBiZSBkb25lIGFzIEFEIHNwb25zb3JlZC4NCj4NCj4gQmVu Lg0K From nobody Sun Oct 18 12:10:27 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 171A01ACE32; Sun, 18 Oct 2015 12:10:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 tF_oo8tiV_RJ; Sun, 18 Oct 2015 12:10:24 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E0A91ACE01; Sun, 18 Oct 2015 12:10:23 -0700 (PDT) X-AuditID: c1b4fb30-f79626d000006adf-ce-5623ee9d0ec3 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 3D.CA.27359.D9EE3265; Sun, 18 Oct 2015 21:10:21 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.61]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0248.002; Sun, 18 Oct 2015 21:10:21 +0200 From: Christer Holmberg To: Ben Campbell Thread-Topic: [dispatch] Draft new: draft-holmberg-dispatch-pani-abnf-00 [was: [sipcore] [Technical Errata Reported] RFC7315 (4474)] Thread-Index: AQHRCdcYpH++Me34ZEiyqo0HYkD7qJ5xnW2Q Date: Sun, 18 Oct 2015 19:10:20 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37B691E1@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37B62FC0@ESESSMB209.ericsson.se> <90429FC5-4199-4386-8CEE-F7F9E45420CE@nostrum.com> <7594FB04B1934943A5C02806D1A2204B37B6907F@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37B6907F@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrILMWRmVeSWpSXmKPExsUyM+Jvje7cd8phBk27dCzmd55mt1g6aQGr xdcfm9gcmD2WLPnJ5DFr5xOWAKYoLpuU1JzMstQifbsEroyr644xFuxTrlj5YSFzA+MJpS5G Tg4JAROJPZ2fmCFsMYkL99azdTFycQgJHGWU+LOknx0kISSwmFHiyXrpLkYODjYBC4nuf9og YREBJYnnzVtZQMLMAo4S09Zkg7QKC7QySjTv3sUO4ogItDFKbJg1gRGiwUji6tW3TCA2i4Cq xMm/79lAbF4BX4kNU1+zQCw+xihxftt5sIs4Bfwk9u9eA3YEI9B130+tAWtmFhCXuPVkPhPE 1QISS/ach/pAVOLl43+sELaSxIrtlxghrtOUWL9LH6JVUWJK90N2iL2CEidnPmGZwCg2C8nU WQgds5B0zELSsYCRZRWjaHFqcVJuupGRXmpRZnJxcX6eXl5qySZGYBwd3PLbYAfjy+eOhxgF OBiVeHgfHFEKE2JNLCuuzD3EKM3BoiTO28z0IFRIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QD o0Lruv3LZwpfZRN2P7fo+KEkHzmRysNbA33j+p3vLxC9ZuBZNKt7ri5PttUD57yjvpoOy2av UpCduuh659PFryPn3/vw+5lrxd0/c+/H3nzgJdby5EzZIj39F/8CdF/8U2oy/LewO+eRvcz7 y4rrT5XLqmh+Cv2SkNx3aNPs1I6jDrNfnVG4lKHEUpyRaKjFXFScCADxxN7uhAIAAA== Archived-At: Cc: DISPATCH list , SIPCORE Subject: Re: [dispatch] Draft new: draft-holmberg-dispatch-pani-abnf-00 [was: [sipcore] [Technical Errata Reported] RFC7315 (4474)] X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Oct 2015 19:10:26 -0000 SGksDQoNCkkndmUgc3VibWl0dGVkIGEgbmV3IHZlcnNpb24sIC0wMSwgd2hlcmUgdGhlIGNhdGVn b3J5IGlzIGNoYW5nZWQgdG8gJ0luZm9ybWF0aW9uYWwnLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rl cg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogZGlzcGF0Y2ggW21haWx0bzpk aXNwYXRjaC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQ2hyaXN0ZXIgSG9sbWJlcmcN ClNlbnQ6IDE4IE9jdG9iZXIgMjAxNSAyMTo1OQ0KVG86IEJlbiBDYW1wYmVsbCA8YmVuQG5vc3Ry dW0uY29tPg0KQ2M6IERJU1BBVENIIGxpc3QgPGRpc3BhdGNoQGlldGYub3JnPjsgU0lQQ09SRSA8 c2lwY29yZUBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbZGlzcGF0Y2hdIERyYWZ0IG5ldzogZHJh ZnQtaG9sbWJlcmctZGlzcGF0Y2gtcGFuaS1hYm5mLTAwIFt3YXM6IFtzaXBjb3JlXSBbVGVjaG5p Y2FsIEVycmF0YSBSZXBvcnRlZF0gUkZDNzMxNSAoNDQ3NCldDQoNCkhpLA0KDQo+SWYgNzMxNSBp cyBpbmZvcm1hdGlvbmFsLCB3aHkgZG9lcyB0aGUgdXBkYXRlIG5lZWQgdG8gYmUgc3RhbmRhcmRz IHRyYWNrPw0KDQpHb29kIHBvaW50IC0gSSBndWVzcyBpdCBkb2Vzbid0IGhhdmUgdG8gOikNCg0K UmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KDQpPbiAxOCBPY3QgMjAxNSwgYXQgNjo0OSwgQ2hyaXN0 ZXIgSG9sbWJlcmcgd3JvdGU6DQoNCj4gSGksDQo+DQo+IEJhc2VkIG9uIEJlbuKAmXMgZ3VpZGFu Y2UsIEnigJl2ZSBzdWJtaXR0ZWQgYSBkcmFmdCB3aGljaCBtYWtlcyB0aGUgQUJORiANCj4gdXBk YXRlLg0KPg0KPiBOT1RFOiBBcyBSRkMgNzMxNSBpcyBhbiBJbmZvcm1hdGlvbmFsIFJGQywgSSBo YWQgdG8gYWRkIHRoZSBSRkMgYXMgYW4gDQo+IEluZm9ybWF0aXZlIHJlZmVyZW5jZSBpbiB0aGUg ZHJhZnQsIGluIG9yZGVyIHRvIHBhc3MgdGhlIElkbml0cyBjaGVjay4NCj4NCj4NCj4gQSBuZXcg dmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWhvbG1iZXJnLWRpc3BhdGNoLXBhbmktYWJuZi0wMC50eHQN Cj4NCj4gaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBDaHJpc3RlciBIb2xtYmVy ZyBhbmQgcG9zdGVkIHRvIHRoZSANCj4gSUVURiByZXBvc2l0b3J5Lg0KPg0KPg0KPg0KPiBOYW1l OiAgICAgICAgICAgICAgICAgZHJhZnQtaG9sbWJlcmctZGlzcGF0Y2gtcGFuaS1hYm5mDQo+DQo+ IFJldmlzaW9uOiAgICAgICAgICAgIDAwDQo+DQo+IFRpdGxlOiAgICAgICAgICAgICAgICAgICAg UC1BY2Nlc3MtTmV0d29yay1JbmZvIEFCTkYgVXBkYXRlDQo+DQo+IERvY3VtZW50IGRhdGU6ICAg ICAgICAgICAgICAyMDE1LTEwLTE4DQo+DQo+IEdyb3VwOiAgICAgICAgICAgICAgICBJbmRpdmlk dWFsIFN1Ym1pc3Npb24NCj4NCj4gUGFnZXM6ICAgICAgICAgICAgICAgICA0DQo+DQo+IFVSTDog ICAgICAgICAgICANCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0 LWhvbG1iZXJnLWRpc3BhdGNoLXBhbmktYWJuZg0KPiAtMDAudHh0DQo+DQo+IFN0YXR1czogICAg ICAgICANCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaG9sbWJlcmct ZGlzcGF0Y2gtcGFuaS1hYm5mLw0KPg0KPiBIdG1saXplZDogICAgICAgDQo+IGh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1ob2xtYmVyZy1kaXNwYXRjaC1wYW5pLWFibmYtMDANCj4N Cj4NCj4NCj4NCj4NCj4gQWJzdHJhY3Q6DQo+DQo+IFRoaXMgZG9jdW1lbnQgdXBkYXRlcyBSRkMg NzMxNSwgYnkgbW9kaWZ5aW5nIHRoZSBleHRlbnNpb24tYWNjZXNzLQ0KPg0KPiBpbmZvIHBhcnQg b2YgdGhlIFAtQWNjZXNzLU5ldHdvcmstSW5mbyBoZWFkZXIgZmllbGQgQXVnbWVudGVkIEJhY2t1 cy0NCj4NCj4gTmF1ciBGb3JtIChBQk5GKS4NCj4NCj4NCj4gUmVnYXJkcywNCj4NCj4gQ2hyaXN0 ZXINCj4NCj4NCj4NCj4NCj4gRnJvbTogc2lwY29yZSBbbWFpbHRvOnNpcGNvcmUtYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmIE9mIENocmlzdGVyIA0KPiBIb2xtYmVyZw0KPiBTZW50OiAxOCBP Y3RvYmVyIDIwMTUgMTA6NTINCj4gVG86IEJlbiBDYW1wYmVsbCA8YmVuQG5vc3RydW0uY29tPg0K PiBDYzogRElTUEFUQ0ggbGlzdCA8ZGlzcGF0Y2hAaWV0Zi5vcmc+OyBTSVBDT1JFIDxzaXBjb3Jl QGlldGYub3JnPjsgDQo+IEN1bGxlbiBKZW5uaW5ncyA8Zmx1ZmZ5QGlpaS5jYT4NCj4gU3ViamVj dDogUmU6IFtzaXBjb3JlXSBbZGlzcGF0Y2hdIFtUZWNobmljYWwgRXJyYXRhIFJlcG9ydGVkXSBS RkM3MzE1DQo+ICg0NDc0KQ0KPg0KPiBIaSwNCj4NCj4gU28sIHNoYWxsIEkgYWRkcmVzcyB0aGUg ZHJhZnQgdG8gc29tZSBXRywgb3I/DQo+DQo+IGRyYWZ0LWhvbG1iZXJnLWRpc3BhdGNoID8NCj4N Cj4gUmVnYXJkcywNCj4NCj4gQ2hyaXN0ZXINCj4NCj4gU2VudCBmcm9tIG15IFdpbmRvd3MgUGhv bmUNCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gRnJvbTogQmVuIENhbXBi ZWxsPG1haWx0bzpiZW5Abm9zdHJ1bS5jb20+DQo+IFNlbnQ6IOKAjjE0L+KAjjEwL+KAjjIwMTUg MTc6MjENCj4gVG86IENocmlzdGVyIEhvbG1iZXJnPG1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Bl cmljc3Nvbi5jb20+DQo+IENjOiBDdWxsZW4gSmVubmluZ3M8bWFpbHRvOmZsdWZmeUBpaWkuY2E+ OyBESVNQQVRDSCANCj4gbGlzdDxtYWlsdG86ZGlzcGF0Y2hAaWV0Zi5vcmc+OyBTSVBDT1JFPG1h aWx0bzpzaXBjb3JlQGlldGYub3JnPg0KPiBTdWJqZWN0OiBSZTogW3NpcGNvcmVdIFtkaXNwYXRj aF0gW1RlY2huaWNhbCBFcnJhdGEgUmVwb3J0ZWRdIFJGQzczMTUNCj4gKDQ0NzQpDQo+IE9uIDgg T2N0IDIwMTUsIGF0IDIxOjAzLCBDaHJpc3RlciBIb2xtYmVyZyB3cm90ZToNCj4NCj4+IEhpIEN1 bGxlbiwNCj4+DQo+PiBTbywgeW91IGFyZSBzdWdnZXN0aW5nIGEgU0lQQ09SRSBkcmFmdCB0aGF0 IHVwZGF0ZXMgdGhlIEFCTkY/DQo+DQo+IFRoaXMgaXMgd2hlcmUgdGhlIGNoYWlycyB3aWxsIHBv aW50IG91dCB0aGF0IHNwZWNpYWwtcHVycG9zZSANCj4gZXh0ZW5zaW9ucyBhcmUgZ2VuZXJhbGx5 IG5vdCBpbiBzY29wZSBmb3Igc2lwY29yZSA6LSkgSWYgc28sIHRoaXMgDQo+IG1pZ2h0IGNvdWxk IGFsc28gYmUgZG9uZSBhcyBBRCBzcG9uc29yZWQuDQo+DQo+IEJlbi4NCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpkaXNwYXRjaCBtYWlsaW5nIGxpc3QN CmRpc3BhdGNoQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2Rpc3BhdGNoDQo= From nobody Mon Oct 19 07:52:27 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91CC31A9108 for ; Mon, 19 Oct 2015 07:52:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 0X_Uoi8TMKbi for ; Mon, 19 Oct 2015 07:52:23 -0700 (PDT) Received: from mail-vk0-f52.google.com (mail-vk0-f52.google.com [209.85.213.52]) (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 96C961A90C5 for ; Mon, 19 Oct 2015 07:52:23 -0700 (PDT) Received: by vkgy127 with SMTP id y127so8875450vkg.0 for ; Mon, 19 Oct 2015 07:52:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=1pv0CDn0/jYpc9eR9hio84hgssZjs1rWzv8i6ijMKdc=; b=YLVg2s15iD/8EniUqsZt/gXkhQjhb2fdORb2FbdU2nfXGza/RKUarREhrk9l0A/QzB 8LjiLkkCtV/uzt4T6OkLDK+BS3qzeJ1rrhJZB8rfe0hOYCPnRDByRfTRTkpCCdU/0+cD pjqguNk8k0vwh0Gp2sjdSymCMnWjNGgC74VN8ambZT+97JVp0RKrsUXSsovApovxhQMk 8BDygjzBWZAfeWxY6tXh2RvMEM4v0CoRD00YHcEyZ++MYPRCHqoodlmWLghHpFh6UwAC s4CaXgZ+FnRpzX78CjxFgW82GIOPiY+93Z5pO1O2eH1z3e+4fERPWvkmwe7jNEnuR+Ec 0zCQ== X-Gm-Message-State: ALoCoQkOEP/Q/wM95KxUvCNqc2bwWMSM2y5T3F4u8J1vEQX5sYg7yH3MsvHBxyW+csaebLvUawMy MIME-Version: 1.0 X-Received: by 10.31.148.206 with SMTP id w197mr20962002vkd.100.1445266342299; Mon, 19 Oct 2015 07:52:22 -0700 (PDT) Received: by 10.31.139.17 with HTTP; Mon, 19 Oct 2015 07:52:22 -0700 (PDT) In-Reply-To: <5623DD8F.1040406@gmx.de> References: <5623DD8F.1040406@gmx.de> Date: Mon, 19 Oct 2015 16:52:22 +0200 Message-ID: From: Emanuel Lorrain To: dispatch@ietf.org Content-Type: multipart/alternative; boundary=001a113d2d34f05f5c0522764a9c Archived-At: Subject: Re: [dispatch] Proposed charter for CELLAR: Codec Encoding for LossLess Archiving and Realtime transmission X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2015 14:52:25 -0000 --001a113d2d34f05f5c0522764a9c Content-Type: text/plain; charset=UTF-8 +1 I support the creation of this working group. > *Proposed Name*: CELLAR: Codec Encoding for LossLess Archiving and > Realtime > > transmission > > [...] > > > Best regards, > Emanuel Lorrain > -- Tuesday, Wednesday and Thursday. PACKED vzw - Centre of Expertise in Digital Heritage Rue Delaunoystraat 58 #23 B-1080 Brussels Belgium phone: ++32 (0)2 2171405 emanuel@packed.be www.packed.be www.dca-project.eu www.projectcest.be www.scart.be --001a113d2d34f05f5c0522764a9c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1 I support the creation of this working group.

> *Proposed Name*: CELLAR: Codec Encoding for LossLess Archiving and Rea= ltime
> transmission
> [...]


Best regards,
=C2=A0
Emanuel Lorrain
--
Tuesda= y, Wednesday and Thursday.

PACKED vzw -=20 =20
Centre of Expertise in Digital Heritage
B-1080 Brussels=C2=A0
--001a113d2d34f05f5c0522764a9c-- From nobody Tue Oct 20 17:27:31 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 502F61ACE87 for ; Tue, 20 Oct 2015 17:27:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable 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 5djIb-dlvM25 for ; Tue, 20 Oct 2015 17:27:25 -0700 (PDT) Received: from smtp112.ord1c.emailsrvr.com (smtp112.ord1c.emailsrvr.com [108.166.43.112]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFFD21ACE6C for ; Tue, 20 Oct 2015 17:27:24 -0700 (PDT) Received: from smtp15.relay.ord1c.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp15.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 4CF6F3801D7; Tue, 20 Oct 2015 20:27:24 -0400 (EDT) Received: by smtp15.relay.ord1c.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 9CE89380207; Tue, 20 Oct 2015 20:27:23 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.24.119.195] ([UNAVAILABLE]. [128.107.241.177]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:587 (trex/5.4.2); Wed, 21 Oct 2015 00:27:24 GMT Content-Type: multipart/alternative; boundary="Apple-Mail=_AD143B75-ABB3-4DBB-950B-BB105E1540B4" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Cullen Jennings In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37B346AB@ESESSMB209.ericsson.se> Date: Tue, 20 Oct 2015 17:06:58 -0700 Message-Id: References: <7594FB04B1934943A5C02806D1A2204B37AC0CF1@ESESSMB209.ericsson.se> <3308F2DE-08F1-46A0-BC01-2445627BAD53@iii.ca> <56031836.3080407@nostrum.com> <4E205A3B-F608-48D3-9DA5-D2220A97D953@nostrum.com> <7594FB04B1934943A5C02806D1A2204B37AE6750@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37B346AB@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.2104) Archived-At: Cc: DISPATCH list , Ben Campbell , SIPCORE Subject: Re: [dispatch] [sipcore] [Technical Errata Reported] RFC7315 (4474) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2015 00:27:29 -0000 --Apple-Mail=_AD143B75-ABB3-4DBB-950B-BB105E1540B4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I had not really thought about where it should be done but seem like a = trivial draft that updates would be better than an errata for this. But = when in doubt, Dispatch seems like a fine place to send it to start.=20 > On Oct 8, 2015, at 7:03 PM, Christer Holmberg = wrote: >=20 > Hi Cullen, >=20 > So, you are suggesting a SIPCORE draft that updates the ABNF? >=20 > Regards, >=20 > Christer=20 >=20 > Sent from my Windows Phone > From: Cullen Jennings > Sent: =E2=80=8E08/=E2=80=8E10/=E2=80=8E2015 23:17 > To: Christer Holmberg > Cc: Ben Campbell ; SIPCORE = ; DISPATCH list > Subject: Re: [dispatch] [sipcore] [Technical Errata Reported] RFC7315 = (4474) >=20 >=20 > My 2 cents is still more appropriate to fix it with a draft that = epodes it not an Errata. Imagine an SBC or Firewall that is checking = the SIP syntax using the ABNF. The odds of them seeing this change and = implementing it much better with an RFC than an errata. Total work = either way is minimal.=20 >=20 >=20 > > On Sep 30, 2015, at 9:12 AM, Christer Holmberg = > = wrote: > >=20 > > Hi, > >=20 > >> (+sipcore, dispatch) > >> (as individual) > >>=20 > >> I just realized this discussion did not include the sipcore or = dispatch lists, and probably should. > >>=20 > >> Recap: Christer proposed an errata (4474) to RFC 7315. It proposes = the following change: > >>=20 > >>> Section 5.4 says: > >>>=20 > >>> extension-access-info =3D gen-value > >>>=20 > >>> It should say: > >>>=20 > >>> extension-access-info =3D generic-param > >>=20 > >> The generic-param construction allows the NAME =3D VALUE syntax as = in the TS 24.229 extension Jean mentioned below. > >>=20 > >> Keeping in mind the RFC in question was for 3GPP: Is anyone aware = of implementations of 7315 that would be broken > >> by this? =46rom Jean's example, it looks like 3GPP had already = assumed generic-param. > >=20 > > Correct. > >=20 > > Also, comparing RFC 3455 and RFC 7315, *all but one* of the new = access-info parameter values that were added in RFC 7315 follow the = generic-param syntax. So, it seems like we in IETF also assumed = generic-param when we did RFC 7315 (and/or we were not concerned about = parser issues), but nobody noticed the ABNF issue. > >=20 > > And, as I said earlier, I am pretty sure this header is mostly = (only?) used in 3GPP environments, and nobody in 3GPP objected to the = change I am now suggesting. It was discussed in 3GPP, and the outcome = was to file the errata. > >=20 > > Finally, as Jean indicated, 3GPP has defined a new value, = daylight-saving-time, which also uses the generic-param syntax. > >=20 > > Regards, > >=20 > > Christer > >=20 > >=20 > > On 23 Sep 2015, at 16:23, A. Jean Mahoney wrote: > >=20 > >> FWIW - TS 24.229, which defines the values for access-info, = considers=20 > >> extension-access-info to be a generic-param, and not a gen-value as=20= > >> specified RFC7315. 3GPP has defined one extension so far (7.2A.4): > >>=20 > >>=20 > >> daylight-saving-time =3D "daylight-saving-time" EQUAL quoted-string > >>=20 > >> TS 124 229 - V12.9.0 - Digital cellular telecommunications system=20= > >> (Phase 2+); Universal Mobile Telecommunications System (UMTS); LTE; = IP=20 > >> multimedia call control protocol based on Session Initiation = Protocol=20 > >> (SIP) and Session Description Protocol (SDP); Stage 3 (3GPP TS = 24.229=20 > >> version 12.9.0 Release 12) The daylight-saving-time is an instance = of=20 > >> generic-param from the current extension-access-info component of = the=20 > >> P- Access-Network-Info header field defined in RFC > >> 7315 [52]. > >>=20 > >>=20 > >> Jean > >>=20 > >>=20 > >>=20 > >> On 9/23/15 3:47 PM, Cullen Jennings wrote: > >>> I can see that it might have been better if it had been done this = way=20 > >>> Christer is proposing but I don't see how you can change it now. = This=20 > >>> change would break existing parsers that checked this. That does = not=20 > >>> seem like an errata level thing to me. > >>>=20 > >>>=20 > >>>> On Sep 21, 2015, at 10:30 AM, Ben Campbell > wrote: > >>>>=20 > >>>> sipcore and dispatch chairs: > >>>>=20 > >>>> Do you have any concerns about accepting Christer's errata? (I = note=20 > >>>> RFC 7315 was an orphaned sipping draft progressed as AD = sponsored.) > >>>>=20 > >>>> Ben. > >>>>=20 > >>>> Forwarded message: > >>>>=20 > >>>>> From: Christer Holmberg > > >>>>> To: Ben Campbell > > >>>>> Cc: sipcore@ietf.org > > >>>>> Subject: Re: [sipcore] [Technical Errata Reported] RFC7315 = (4474) > >>>>> Date: Mon, 21 Sep 2015 10:26:26 +0000 > >>>>>=20 > >>>>> Any news on this? > >>>>>=20 > >>>>> Regards, > >>>>>=20 > >>>>> Christer > >>>>>=20 > >>>>> From: sipcore [mailto:sipcore-bounces@ietf.org = ] On Behalf Of=20 > >>>>> Christer Holmberg > >>>>> Sent: 14. syyskuuta 2015 23:24 > >>>>> To: Ben Campbell > >>>>> Cc: sipcore@ietf.org > >>>>> Subject: Re: [sipcore] [Technical Errata Reported] RFC7315 = (4474) > >>>>>=20 > >>>>> Hi Ben, > >>>>>=20 > >>>>> I am pretty sure generic-param was the original intention. The=20= > >>>>> majority of all existing value follow the generic-param syntax, = and=20 > >>>>> I can't think of any reason why new values would not follow the=20= > >>>>> same syntax. That is how it works for other header fields too. > >>>>>=20 > >>>>> I think this is due to a mistake, where someone thought that=20 > >>>>> extension-access-info represents the actual parameter name, and=20= > >>>>> therefor only a value (gen-value) is needed. But,=20 > >>>>> extension-access-info represents the whole rule (name AND = value),=20 > >>>>> why generic-param is needed :) > >>>>>=20 > >>>>> Regards, > >>>>>=20 > >>>>> Christer > >>>>>=20 > >>>>> Sent from my Windows Phone > >>>>> ________________________________ > >>>>> From: Ben Campbell> > >>>>> Sent: =E2=80=8E14/=E2=80=8E09/=E2=80=8E2015 21:31 > >>>>> To: Christer Holmberg> > >>>>> Cc: sipcore@ietf.org = > > >>>>> Subject: Re: [sipcore] [Technical Errata Reported] RFC7315 = (4474)=20 > >>>>> Hi Christer, > >>>>>=20 > >>>>> Is it your understanding that the use of generic-param was the=20= > >>>>> actual intention at the time 7315 was published? Or was = gen-value=20 > >>>>> the original intention, but we now think that it should have = been=20 > >>>>> generic-param? > >>>>>=20 > >>>>> Thanks! > >>>>>=20 > >>>>> Ben. > >>>>>=20 > >>>>> On 14 Sep 2015, at 6:22, Christer Holmberg wrote: > >>>>>=20 > >>>>>> FYI, > >>>>>>=20 > >>>>>> I've now submitted the errata. > >>>>>>=20 > >>>>>> Regards, > >>>>>>=20 > >>>>>> Christer > >>>>>>=20 > >>>>>> -----Original Message----- > >>>>>> From: RFC Errata System [mailto:rfc-editor@rfc-editor.org = ] > >>>>>> Sent: 14. syyskuuta 2015 14:21 > >>>>>> To: r.jesske@telekom.de = >; > >>>>>> drage@alcatel-lucent.com = >; > >>>>>> Christer Holmberg; > >>>>>> iesg@ietf.org > > >>>>>> Cc: Christer Holmberg; > >>>>>> rfc-editor@rfc-editor.org = > > >>>>>> Subject: [Technical Errata Reported] RFC7315 (4474) > >>>>>>=20 > >>>>>> The following errata report has been submitted for RFC7315,=20 > >>>>>> "Private Header (P-Header) Extensions to the Session Initiation=20= > >>>>>> Protocol > >>>>>> (SIP) > >>>>>> for the 3GPP". > >>>>>>=20 > >>>>>> -------------------------------------- > >>>>>> You may review the report below and at: > >>>>>> http://www.rfc-editor.org/errata_search.php?rfc=3D7315&eid=3D4474= > >>>>>>=20 > >>>>>> -------------------------------------- > >>>>>> Type: Technical > >>>>>> Reported by: Christer Holmberg > >>>>>> >>>>>> com>> > >>>>>>=20 > >>>>>> Section: 5.4 > >>>>>>=20 > >>>>>> Original Text > >>>>>> ------------- > >>>>>> extension-access-info =3D gen-value > >>>>>>=20 > >>>>>> Corrected Text > >>>>>> -------------- > >>>>>> extension-access-info =3D generic-param > >>>>>>=20 > >>>>>> Notes > >>>>>> ----- > >>>>>> Most of the pre-defined access-info values are following the=20 > >>>>>> generic-param syntax. New access-info values (extensions) = should=20 > >>>>>> also be allowed to follow the generic-param syntax, in order to=20= > >>>>>> allow both for a name and value of the extension. > >>>>>>=20 > >>>>>> Instructions: > >>>>>> ------------- > >>>>>> This erratum is currently posted as "Reported". If necessary,=20= > >>>>>> please use "Reply All" to discuss whether it should be verified = or=20 > >>>>>> rejected. > >>>>>> When a decision is reached, the verifying party (IESG) can log = in=20 > >>>>>> to change the status and edit the report, if necessary. > >>>>>>=20 > >>>>>> -------------------------------------- > >>>>>> RFC7315 (draft-drage-sipping-rfc3455bis-14) > >>>>>> -------------------------------------- > >>>>>> Title : Private Header (P-Header) Extensions to = the > >>>>>> Session Initiation Protocol (SIP) for the 3GPP > >>>>>> Publication Date : July 2014 > >>>>>> Author(s) : R. Jesske, K. Drage, C. Holmberg > >>>>>> Category : INFORMATIONAL > >>>>>> Source : IETF - NON WORKING GROUP > >>>>>> Area : N/A > >>>>>> Stream : IETF > >>>>>> Verifying Party : IESG > >>>>>>=20 > >>>>>> _______________________________________________ > >>>>>> sipcore mailing list > >>>>>> sipcore@ietf.org = > > >>>>>> https://www.ietf.org/mailman/listinfo/sipcore = > >>>>> _______________________________________________ > >>>>> sipcore mailing list > >>>>> sipcore@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/sipcore = > >=20 > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch = --Apple-Mail=_AD143B75-ABB3-4DBB-950B-BB105E1540B4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

I had not really thought = about where it should be done but seem like a trivial draft that updates = would be better than an errata for this.  But when in doubt, = Dispatch seems like a fine place to send it to start. 

On Oct 8, 2015, at 7:03 PM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:

Hi= Cullen,

So, you are suggesting a SIPCORE = draft that updates the ABNF?

Regards,

Christer 

Sent from my Windows Phone

From: Cullen Jennings
Sent: =E2=80=8E08/=E2=80=8E10/=E2=80=8E2015 23:17
To: Christer = Holmberg
Cc: Ben Campbell; SIPCORE; DISPATCH list
Subject: Re: [dispatch] [sipcore] [Technical Errata Reported] RFC7315 = (4474)


My 2 cents is still more appropriate = to fix it with a draft that epodes  it not an Errata. Imagine an = SBC or Firewall that is checking the SIP syntax using the ABNF. The odds = of them seeing this change and implementing it much better with an RFC = than an errata. Total work either way is minimal. 


> On Sep 30, 2015, at 9:12 AM, Christer = Holmberg <christer.holmberg@ericsson.com> wrote:

> Hi,

>> (+sipcore, dispatch)
>> (as = individual)
>> 
>> I just = realized this discussion did not include the sipcore or dispatch lists, = and probably should.
>> 
>> = Recap: Christer proposed an errata (4474) to RFC 7315. It proposes the = following change:
>> 
>>> = Section 5.4 says:
>>> 
>>> extension-access-info  =3D gen-value
>>> 
>>> It should = say:
>>> 
>>> = extension-access-info  =3D generic-param
>> 
>> The generic-param = construction allows the NAME =3D VALUE syntax as in the TS 24.229 = extension Jean mentioned below.
>> 
>> Keeping in mind the RFC in question was for 3GPP: Is = anyone aware of implementations of 7315 that would be broken
>> by this? =46rom Jean's example, it looks like 3GPP = had already assumed generic-param.

> Correct.

> = Also, comparing RFC 3455 and RFC 7315, *all but one* of the new = access-info parameter values that were added in RFC 7315 follow the = generic-param syntax.  So, it seems like we in IETF also assumed = generic-param when we did RFC 7315 (and/or we were not concerned about = parser issues), but nobody noticed the ABNF issue.

> And, as I said earlier, I am = pretty sure this header is mostly (only?) used in 3GPP environments, and = nobody in 3GPP objected to the change I am now suggesting. It was = discussed in 3GPP, and the outcome was to file the errata.

> Finally, as Jean indicated, = 3GPP has defined a new value, daylight-saving-time, which also uses the = generic-param syntax.

> = Regards,

> Christer


> On 23 = Sep 2015, at 16:23, A. Jean Mahoney wrote:

>> FWIW - TS 24.229, which defines the values for = access-info, considers 
>> = extension-access-info to be a generic-param, and not a gen-value = as 
>> specified RFC7315. 3GPP has defined one = extension so far (7.2A.4):
>> 
>> 
>> daylight-saving-time =3D = "daylight-saving-time" EQUAL quoted-string
>> >> TS 124 229 - V12.9.0 - Digital cellular = telecommunications system 
>> (Phase 2+); = Universal Mobile Telecommunications System (UMTS); LTE; IP 
>> multimedia call control protocol based on Session = Initiation Protocol 
>> (SIP) and Session = Description Protocol (SDP); Stage 3 (3GPP TS 24.229 
>> version 12.9.0 Release 12) The daylight-saving-time = is an instance of 
>> generic-param from the = current extension-access-info component of the 
>> P- Access-Network-Info header field defined in = RFC
>> 7315 [52].
>> 
>> 
>> Jean
>> 
>> 
>> 
>> On 9/23/15 3:47 PM, = Cullen Jennings wrote:
>>> I can see that it = might have been better if it had been done this way 
>>> Christer is proposing but I don't see how you = can change it now. This 
>>> change would = break existing parsers that checked this. That does not 
>>> seem like an errata level thing to me.
>>> 
>>> 
>>>> On Sep 21, 2015, at 10:30 AM, Ben Campbell = <ben@nostrum.com> = wrote:
>>>> 
>>>>= sipcore and dispatch chairs:
>>>> 
>>>> Do you have any concerns about accepting = Christer's errata? (I note 
>>>> RFC 7315 = was an orphaned sipping draft progressed as AD sponsored.)
>>>> 
>>>> Ben.
>>>> 
>>>> = Forwarded message:
>>>> 
>>>>> From: Christer Holmberg <christer.holmberg@ericsson.com>
>>>>> To: Ben Campbell <ben@nostrum.com>
>>>>> Cc: sipcore@ietf.org <sipcore@ietf.org>
>>>>> Subject: Re: [sipcore] [Technical Errata = Reported] RFC7315 (4474)
>>>>> Date: Mon, = 21 Sep 2015 10:26:26 +0000
>>>>> 
>>>>> Any news on this?
>>>>> 
>>>>> = Regards,
>>>>> 
>>>>> Christer
>>>>> 
>>>>> = From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of 
>>>>> Christer Holmberg
>>>>> Sent: 14. syyskuuta 2015 23:24
>>>>> To: Ben Campbell
>>>>> Cc: sipcore@ietf.org
>>>>> Subject: Re: [sipcore] [Technical Errata = Reported] RFC7315 (4474)
>>>>> 
>>>>> Hi Ben,
>>>>> 
>>>>> = I am pretty sure generic-param was the original intention. The 
>>>>> majority of all existing value follow = the generic-param syntax, and 
>>>>> I = can't think of any reason why new values would not follow the 
>>>>> same syntax. That is how it works for = other header fields too.
>>>>> 
>>>>> I think this is due to a mistake, where = someone thought that 
>>>>> = extension-access-info  represents the actual parameter name, = and 
>>>>> therefor only a value = (gen-value) is needed. But, 
>>>>> = extension-access-info represents the whole rule (name AND = value), 
>>>>> why generic-param is = needed :)
>>>>> 
>>>>> Regards,
>>>>> 
>>>>> = Christer
>>>>> 
>>>>> Sent from my Windows Phone
>>>>> ________________________________
>>>>> From: Ben Campbell<mailto:ben@nostrum.com>
>>>>> Sent: =E2=80=8E14/=E2=80=8E09/=E2=80=8E201= 5 21:31
>>>>> To: Christer Holmberg<mailto:christer.holmberg@ericsson.com>
>>>>> Cc: sipcore@ietf.org<mailto:sipcore@ietf.org>
>>>>> Subject: Re: [sipcore] [Technical Errata = Reported] RFC7315 (4474) 
>>>>> Hi = Christer,
>>>>> 
>>>>> Is it your understanding that the use of = generic-param was the 
>>>>> actual = intention at the time 7315 was published? Or was gen-value 
>>>>> the original intention, but we now think = that it should have been 
>>>>> = generic-param?
>>>>> 
>>>>> Thanks!
>>>>> 
>>>>> = Ben.
>>>>> 
>>>>> On 14 Sep 2015, at 6:22, Christer = Holmberg wrote:
>>>>> 
>>>>>> FYI,
>>>>>> 
>>>>>> I've now submitted the errata.
>>>>>> 
>>>>>> Regards,
>>>>>> 
>>>>>> Christer
>>>>>> 
>>>>>> -----Original Message-----
>>>>>> From: RFC Errata System [mailto:rfc-editor@rfc-editor.org]
>>>>>> Sent: 14. syyskuuta 2015 14:21
>>>>>> To: r.jesske@telekom.de<mailto:r.jesske@telekom.de>;
>>>>>> drage@alcatel-lucent.com<mailto:drage@alcatel-lucent.com>;
>>>>>> Christer Holmberg;
>>>>>> iesg@ietf.org<mailto:iesg@ietf.org>
>>>>>> Cc: Christer Holmberg;
>>>>>> rfc-editor@rfc-editor.org<mailto:rfc-editor@rfc-editor.org>
>>>>>> Subject: [Technical Errata Reported] = RFC7315 (4474)
>>>>>> 
>>>>>> The following errata report has been = submitted for RFC7315, 
>>>>>> = "Private Header (P-Header) Extensions to the Session Initiation 
>>>>>> Protocol
>>>>>> (SIP)
>>>>>> for the 3GPP".
>>>>>> 
>>>>>> = --------------------------------------
>>>>>> You may review the report below and = at:
>>>>>> http://www.rfc-editor.org/errata_search.php?rfc=3D7315&eid=3D= 4474
>>>>>> 
>>>>>> = --------------------------------------
>>>>>> Type: Technical
>>>>>> Reported by: Christer Holmberg
>>>>>> <christer.holmberg@ericsson.com<mailto:christer.holmberg@= ericsson.
>>>>>> com>>
>>>>>> 
>>>>>> Section: 5.4
>>>>>> 
>>>>>> Original Text
>>>>>> -------------
>>>>>> extension-access-info  =3D = gen-value
>>>>>> 
>>>>>> Corrected Text
>>>>>> --------------
>>>>>> extension-access-info  =3D = generic-param
>>>>>> 
>>>>>> Notes
>>>>>> -----
>>>>>> Most of the pre-defined access-info = values are following the 
>>>>>> = generic-param syntax. New access-info values (extensions) = should 
>>>>>> also be allowed to = follow the generic-param syntax, in order to 
>>>>>> allow both for a name and value of = the extension.
>>>>>> 
>>>>>> Instructions:
>>>>>> -------------
>>>>>> This erratum is currently posted as = "Reported". If necessary, 
>>>>>> = please use "Reply All" to discuss whether it should be verified = or 
>>>>>> rejected.
>>>>>> When a decision is reached, the = verifying party (IESG) can log in 
>>>>>> to change the status and edit the = report, if necessary.
>>>>>> 
>>>>>> = --------------------------------------
>>>>>> RFC7315 = (draft-drage-sipping-rfc3455bis-14)
>>>>>>= --------------------------------------
>>>>>> = Title           &nb= sp;   : Private Header (P-Header) Extensions to the
>>>>>> Session Initiation Protocol (SIP) = for the 3GPP
>>>>>> Publication = Date    : July 2014
>>>>>> = Author(s)           : = R. Jesske, K. Drage, C. Holmberg
>>>>>> = Category           = : INFORMATIONAL
>>>>>> = Source           &n= bsp;  : IETF - NON WORKING GROUP
>>>>>> = Area           &nbs= p;    : N/A
>>>>>> = Stream           &n= bsp;  : IETF
>>>>>> Verifying = Party     : IESG
>>>>>> 
>>>>>> = _______________________________________________
>>>>>> sipcore mailing list
>>>>>> sipcore@ietf.org<mailto:sipcore@ietf.org>
>>>>>> https://www.ietf.org/mailman/listinfo/sipcore
>>>>> = _______________________________________________
>>>>> sipcore mailing list
>>>>> sipcore@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/sipcore

> = _______________________________________________
> = dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

= --Apple-Mail=_AD143B75-ABB3-4DBB-950B-BB105E1540B4-- From nobody Thu Oct 22 08:32:36 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94F3A1A21B1; Thu, 22 Oct 2015 08:19:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 1cvbW0YLIYtE; Thu, 22 Oct 2015 08:19:06 -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 86B291A1F1D; Thu, 22 Oct 2015 08:19:03 -0700 (PDT) Received: from [10.0.1.9] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t9MFIxPh054015 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 22 Oct 2015 10:19:00 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.9] From: "Ben Campbell" To: "Stephen Farrell" , DISPATCH Date: Thu, 22 Oct 2015 10:18:59 -0500 Message-ID: <2D88BA7A-6B89-465E-91FC-4FB6DC422434@nostrum.com> In-Reply-To: <20151022133935.26487.12997.idtracker@ietfa.amsl.com> References: <20151022133935.26487.12997.idtracker@ietfa.amsl.com> MIME-Version: 1.0 X-Mailer: MailMate (1.9.2r5141) Archived-At: Cc: The IESG , cellar-chairs@ietf.org Subject: Re: [dispatch] Stephen Farrell's Yes on charter-ietf-cellar-00-00: (with COMMENT) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2015 15:19:10 -0000 (+dispatch for now; we will setup a cellar list shortly). Does anyone have thoughts on Stephen's comment below? Thanks! Ben. On 22 Oct 2015, at 8:39, Stephen Farrell wrote: > Stephen Farrell has entered the following ballot position for > charter-ietf-cellar-00-00: Yes > [...] > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/charter-ietf-cellar/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > I wonder is there any interest in the security of the archived > stuff here, and whether the WG would want to possibly take > that on, most likely later. I'm not saying they should, as that > could be a lot of possibly contentious work, but if they did > want to do it, it'd be good to say in the charter. From nobody Thu Oct 22 09:02:51 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BE591A87CE for ; Thu, 22 Oct 2015 09:02:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622] autolearn=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 u2LF8PkCOwQ9 for ; Thu, 22 Oct 2015 09:02:45 -0700 (PDT) Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c:c05::22a]) (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 A071A1A0171 for ; Thu, 22 Oct 2015 09:02:45 -0700 (PDT) Received: by vkfw189 with SMTP id w189so49031124vkf.2 for ; Thu, 22 Oct 2015 09:02:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska_org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hy0wxqaQ9x54lqv3vI+Wvl+eveC6EC0CMS1IxlWS3UE=; b=ZgojnVxwVpDoNTSPmHcvBAbHctVGFy3NJ96xznUTAK3euMUSGbqDFhHlOq6qqR/6ym +H8PoNEKCmeNfivHU+UHkZPWznzgcgwk08K4yp7R0Dnvo/2r594omRABP1c/ft1Yt4fb +lv76uf3EN4jvYTSRNUJaDcAmK2+74VvLPzrlPuQeBoeC5LRYQ5MiM1TkWrETb924lfK SI0aT51khFqJPYwXbzdTpHjMWflIuSEe6fYuxqsZ6vw5zBzPlEq605X7yI/dgEcg97ru 98s+TCXWMhgKObzEtLlBCl+NzDXR8kt9I+B+AruXqKYIMGTdvlmXIGM9WTe2rKFuSojS P5Fg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=hy0wxqaQ9x54lqv3vI+Wvl+eveC6EC0CMS1IxlWS3UE=; b=gNydUmwuanpkk4fc413VL6q8Whu1egDawN+cSFTafR1EmRrMnfUKJhmOFHXXsw3kxn qo2UeRyjBOH3YrQx8qZXeb4YUBgdILTLWNpANK4xdpP4Kpl8CD4iFXmphPrkHO86Av/y Ns9BKyHFFen9LZJRZ6jxnlVhJuSz/VzvTkxx6n46Hhh/ihZqKn+AIgOnuSFwsQ++BFsu udO9B6s2RNALY36c7Cl8xIt9vERl8S6vh9kPXKv3GakgKUTwq/tnlTJMp9A9JhjYcxts kEYVK3FhSg2xUDDjU1IYrx0Lnx6tGDrmqot+nAnMD5mlvG+/79STbZQNqCQjLvU+74mN Da4g== X-Gm-Message-State: ALoCoQnE/jGzb8X4ET1cqH9yPdkSNfXTzPY3BdubjW4tV2Q5LRmmxPNlEhnsxcnIMcs8EAORWf5a MIME-Version: 1.0 X-Received: by 10.31.10.8 with SMTP id 8mr9685044vkk.157.1445529764852; Thu, 22 Oct 2015 09:02:44 -0700 (PDT) Received: by 10.31.15.196 with HTTP; Thu, 22 Oct 2015 09:02:44 -0700 (PDT) In-Reply-To: <2D88BA7A-6B89-465E-91FC-4FB6DC422434@nostrum.com> References: <20151022133935.26487.12997.idtracker@ietfa.amsl.com> <2D88BA7A-6B89-465E-91FC-4FB6DC422434@nostrum.com> Date: Thu, 22 Oct 2015 18:02:44 +0200 Message-ID: From: Steve Lhomme To: Ben Campbell Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: DISPATCH , The IESG , cellar-chairs@ietf.org Subject: Re: [dispatch] Stephen Farrell's Yes on charter-ietf-cellar-00-00: (with COMMENT) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2015 16:02:47 -0000 2015-10-22 17:18 GMT+02:00 Ben Campbell : > (+dispatch for now; we will setup a cellar list shortly). > > Does anyone have thoughts on Stephen's comment below? > > Thanks! > > Ben. > > > On 22 Oct 2015, at 8:39, Stephen Farrell wrote: > >> Stephen Farrell has entered the following ballot position for >> charter-ietf-cellar-00-00: Yes >> > > [...] > >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/charter-ietf-cellar/ >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> >> I wonder is there any interest in the security of the archived >> stuff here, and whether the WG would want to possibly take >> that on, most likely later. I'm not saying they should, as that >> could be a lot of possibly contentious work, but if they did >> want to do it, it'd be good to say in the charter. Does he mean security as in only allowing certain people to access the data ? IMO it's out of the scope and better handled out of the file format/streaming. It's more a transport/storage issue than format. There is encryption possible in WebM though that's working with a EME DRM module. http://www.webmproject.org/docs/webm-encryption/ If he means data safety, that's something we can work on. We already have the CRC for checking. In the past we also discussed redundancy but it was ruled out (again, better handled outside of the file format). > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch -- Steve Lhomme Matroska association Chairman From nobody Thu Oct 22 14:20:47 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F48B1B4225 for ; Thu, 22 Oct 2015 14:20:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 5JPH2S9GskD4 for ; Thu, 22 Oct 2015 14:20:44 -0700 (PDT) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [IPv6:2001:4b98:c:538::195]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82D231B4222 for ; Thu, 22 Oct 2015 14:20:43 -0700 (PDT) Received: from mfilter23-d.gandi.net (mfilter23-d.gandi.net [217.70.178.151]) by relay3-d.mail.gandi.net (Postfix) with ESMTP id 9056EA80BE for ; Thu, 22 Oct 2015 23:20:41 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter23-d.gandi.net Received: from relay3-d.mail.gandi.net ([IPv6:::ffff:217.70.183.195]) by mfilter23-d.gandi.net (mfilter23-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id nBadSowxOcpe for ; Thu, 22 Oct 2015 23:20:40 +0200 (CEST) X-Originating-IP: 84.114.129.144 Received: from localhost (chello084114129144.4.15.vie.surfer.at [84.114.129.144]) (Authenticated sender: michael@niedermayer.cc) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id 17CE7A80CA for ; Thu, 22 Oct 2015 23:20:39 +0200 (CEST) Date: Thu, 22 Oct 2015 23:19:48 +0200 From: Michael Niedermayer To: DISPATCH Message-ID: <20151022211948.GS4556@nb4> References: <20151022133935.26487.12997.idtracker@ietfa.amsl.com> <2D88BA7A-6B89-465E-91FC-4FB6DC422434@nostrum.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5gSG5rY/05f/Hi85" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [dispatch] Stephen Farrell's Yes on charter-ietf-cellar-00-00: (with COMMENT) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2015 21:20:46 -0000 --5gSG5rY/05f/Hi85 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Resending my reply from the mail address thats subscribed to dispatch after canceling the stuck reply On Thu, Oct 22, 2015 at 06:02:44PM +0200, Steve Lhomme wrote: > 2015-10-22 17:18 GMT+02:00 Ben Campbell : > > (+dispatch for now; we will setup a cellar list shortly). > > > > Does anyone have thoughts on Stephen's comment below? > > > > Thanks! > > > > Ben. > > > > > > On 22 Oct 2015, at 8:39, Stephen Farrell wrote: > > > >> Stephen Farrell has entered the following ballot position for > >> charter-ietf-cellar-00-00: Yes > >> > > > > [...] > > > >> The document, along with other ballot positions, can be found here: > >> https://datatracker.ietf.org/doc/charter-ietf-cellar/ > >> > >> > >> > >> ---------------------------------------------------------------------- > >> COMMENT: > >> ---------------------------------------------------------------------- > >> > >> > >> I wonder is there any interest in the security of the archived > >> stuff here, and whether the WG would want to possibly take > >> that on, most likely later. I'm not saying they should, as that > >> could be a lot of possibly contentious work, but if they did > >> want to do it, it'd be good to say in the charter. >=20 > Does he mean security as in only allowing certain people to access the > data ? IMO it's out of the scope and better handled out of the file > format/streaming. It's more a transport/storage issue than format. >=20 > There is encryption possible in WebM though that's working with a EME > DRM module. > http://www.webmproject.org/docs/webm-encryption/ >=20 > If he means data safety, that's something we can work on. We already > have the CRC for checking. In the past we also discussed redundancy > but it was ruled out (again, better handled outside of the file > format). forward error correction, that is to add redundancy to recover from damaged or lost parts of an archived file or stream/track, is something that sounds interresting. CRCs also exist at the video stream (FFv1) layer. Theres currently no means to restore lost frames, slices or disk sectors except through concealing them based on previous frames. The existing CRCs are sufficient though to correct rare bit errors, if that occurs in any actual use case. Adding some layer of protection to protect from damaged or unreadable disk sectors or other larger damges losslessly is possible and interresting. Iam not sure at which layer that would be best to do though. [...] --=20 Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB What does censorship reveal? It reveals fear. -- Julian Assange --5gSG5rY/05f/Hi85 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlYpUvQACgkQYR7HhwQLD6tIQQCdH43ZEJ+2UG9OyPgsMnErLAp8 qSsAoJNTlPzK9rbukT1w8IPOkzP4amhc =JzjI -----END PGP SIGNATURE----- --5gSG5rY/05f/Hi85-- From nobody Thu Oct 22 17:03:20 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 225BA1ACE36 for ; Thu, 22 Oct 2015 17:03:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 nM_m-AtxmI3o for ; Thu, 22 Oct 2015 17:03:15 -0700 (PDT) Received: from smtp64.ord1c.emailsrvr.com (smtp64.ord1c.emailsrvr.com [108.166.43.64]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8CD81ACD6B for ; Thu, 22 Oct 2015 17:03:15 -0700 (PDT) Received: from smtp25.relay.ord1c.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp25.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 02AB31801D2; Thu, 22 Oct 2015 20:03:15 -0400 (EDT) Received: by smtp25.relay.ord1c.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id BF6B11801D4; Thu, 22 Oct 2015 20:03:13 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [192.168.4.100] ([UNAVAILABLE]. [128.107.241.177]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:465 (trex/5.4.2); Fri, 23 Oct 2015 00:03:14 GMT Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Cullen Jennings In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37B691E1@ESESSMB209.ericsson.se> Date: Thu, 22 Oct 2015 18:03:10 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7594FB04B1934943A5C02806D1A2204B37B62FC0@ESESSMB209.ericsson.se> <90429FC5-4199-4386-8CEE-F7F9E45420CE@nostrum.com> <7594FB04B1934943A5C02806D1A2204B37B6907F@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37B691E1@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.2104) Archived-At: Cc: Ben Campbell , DISPATCH list , SIPCORE Subject: Re: [dispatch] Draft new: draft-holmberg-dispatch-pani-abnf-00 [was: [sipcore] [Technical Errata Reported] RFC7315 (4474)] X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2015 00:03:18 -0000 I read the draft and looks pretty simple to me. Hope we can move this = quickly.=20 > On Oct 18, 2015, at 1:10 PM, Christer Holmberg = wrote: >=20 > Hi, >=20 > I've submitted a new version, -01, where the category is changed to = 'Informational'. >=20 > Regards, >=20 > Christer >=20 > -----Original Message----- > From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of = Christer Holmberg > Sent: 18 October 2015 21:59 > To: Ben Campbell > Cc: DISPATCH list ; SIPCORE > Subject: Re: [dispatch] Draft new: = draft-holmberg-dispatch-pani-abnf-00 [was: [sipcore] [Technical Errata = Reported] RFC7315 (4474)] >=20 > Hi, >=20 >> If 7315 is informational, why does the update need to be standards = track? >=20 > Good point - I guess it doesn't have to :) >=20 > Regards, >=20 > Christer >=20 >=20 > On 18 Oct 2015, at 6:49, Christer Holmberg wrote: >=20 >> Hi, >>=20 >> Based on Ben=E2=80=99s guidance, I=E2=80=99ve submitted a draft which = makes the ABNF=20 >> update. >>=20 >> NOTE: As RFC 7315 is an Informational RFC, I had to add the RFC as an=20= >> Informative reference in the draft, in order to pass the Idnits = check. >>=20 >>=20 >> A new version of I-D, draft-holmberg-dispatch-pani-abnf-00.txt >>=20 >> has been successfully submitted by Christer Holmberg and posted to = the=20 >> IETF repository. >>=20 >>=20 >>=20 >> Name: draft-holmberg-dispatch-pani-abnf >>=20 >> Revision: 00 >>=20 >> Title: P-Access-Network-Info ABNF Update >>=20 >> Document date: 2015-10-18 >>=20 >> Group: Individual Submission >>=20 >> Pages: 4 >>=20 >> URL: =20 >> = https://www.ietf.org/internet-drafts/draft-holmberg-dispatch-pani-abnf >> -00.txt >>=20 >> Status: =20 >> https://datatracker.ietf.org/doc/draft-holmberg-dispatch-pani-abnf/ >>=20 >> Htmlized: =20 >> https://tools.ietf.org/html/draft-holmberg-dispatch-pani-abnf-00 >>=20 >>=20 >>=20 >>=20 >>=20 >> Abstract: >>=20 >> This document updates RFC 7315, by modifying the extension-access- >>=20 >> info part of the P-Access-Network-Info header field Augmented Backus- >>=20 >> Naur Form (ABNF). >>=20 >>=20 >> Regards, >>=20 >> Christer >>=20 >>=20 >>=20 >>=20 >> From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer=20= >> Holmberg >> Sent: 18 October 2015 10:52 >> To: Ben Campbell >> Cc: DISPATCH list ; SIPCORE ;=20 >> Cullen Jennings >> Subject: Re: [sipcore] [dispatch] [Technical Errata Reported] RFC7315 >> (4474) >>=20 >> Hi, >>=20 >> So, shall I address the draft to some WG, or? >>=20 >> draft-holmberg-dispatch ? >>=20 >> Regards, >>=20 >> Christer >>=20 >> Sent from my Windows Phone >> ________________________________ >> From: Ben Campbell >> Sent: =E2=80=8E14/=E2=80=8E10/=E2=80=8E2015 17:21 >> To: Christer Holmberg >> Cc: Cullen Jennings; DISPATCH=20 >> list; SIPCORE >> Subject: Re: [sipcore] [dispatch] [Technical Errata Reported] RFC7315 >> (4474) >> On 8 Oct 2015, at 21:03, Christer Holmberg wrote: >>=20 >>> Hi Cullen, >>>=20 >>> So, you are suggesting a SIPCORE draft that updates the ABNF? >>=20 >> This is where the chairs will point out that special-purpose=20 >> extensions are generally not in scope for sipcore :-) If so, this=20 >> might could also be done as AD sponsored. >>=20 >> Ben. > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From nobody Fri Oct 23 00:39:11 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4575E1B2EF0 for ; Fri, 23 Oct 2015 00:39:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 EyWAkxtD6u2q for ; Fri, 23 Oct 2015 00:39:05 -0700 (PDT) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B2541B2EE7 for ; Fri, 23 Oct 2015 00:39:04 -0700 (PDT) Received: from cm-84.208.86.220.getinternet.no ([84.208.86.220]:60640 helo=[192.168.0.116]) by server.dnsblock1.com with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.86) (envelope-from ) id 1ZpWwI-0004Yb-Sk; Fri, 23 Oct 2015 08:39:03 +0100 From: Bob Briscoe To: dispatch@ietf.org References: <561F8BA5.1070906@bobbriscoe.net> <561FEC69.4060901@bobbriscoe.net> <56254298.3070505@bobbriscoe.net> Message-ID: <5629E416.2030400@bobbriscoe.net> Date: Fri, 23 Oct 2015 08:39:02 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <56254298.3070505@bobbriscoe.net> Content-Type: multipart/alternative; boundary="------------000507090606030309090808" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Cc: "De Schepper, Koen \(Koen\)" Subject: [dispatch] A new initiative in the transport area: do DISPATCHers want such strategic work? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2015 07:39:09 -0000 This is a multi-part message in MIME format. --------------000507090606030309090808 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit DISPATCHers, We have a question at the end, addressed to DISPATCH people as 'customers' of the transport layer. Particularly about apps wanting low latency (i.e. nearly everything). * **Background* If you saw our stand at Bits N Bites, or the demo in the active queue management (AQM) WG in Prague, you will know what we're talking about... We showed a video feed from a panoramic camera at a football match delivered down a broadband access. You could pan and zoom the HD picture with finger gestures and the delay was so low it seemed to stick to your finger, while 100 flows per second of Web traffic and more than a dozen long-running flows were all being downloaded thru the same 40Mb/s access line. This wasn't Diffserv - not QoS at the expense of other traffic, so no need for permission to use a class. This was AQM for /all/ the packets in all the flows - all getting the same ultra-low delay. We didn't modify the apps at all, we just switched the stack underneath the TCP apps to a 'scalable' TCP. The interactive video app just auto-adjusted its buffer 'cos it detected very low delay and jitter. The stats are pretty stunning: zero congestion loss and ultra-low queuing latency (99th percentile of about 1 millisecond) with no reduction in link utilization either. The insight is that 'classic' TCPs (New Reno, Cubic etc.) have been scaling badly - the sawteeth are getting longer and the responsiveness has been getting slower as flow rates increase. The trick is to classify the old 'classic' TCP traffic behind a `semi-permeable membrane'. For flow-rate it's like the same queue, but for queuing delay it's a second queue. Then all the 'modern' apps can migrate to using the good queue, where r-t apps can safely coexist with apps using (scalable) TCP, (scalable) SCTP, RTP, etc. and they all get low delay, whether for Web browsing, gaming, interactive video, voice, http adaptive streaming, etc. * **The Question* This initiative is going to need standardisation across 3 different WGs in the transport area (AQM, TCPM and TSVWG), with incremental changes in access networks and updates to host stacks (we used DCTCP as the scalable TCP, which is already in Windows Server and there's a patch for Linux). So we're looking for feedback on this question: ==> From the ART/RAI viewpoint, does the potential benefit make it worth being this ambitious? *More Info* We've asked if we can give a heads-up about this in DISPATCH in Yokahoma. The work we're proposing is outside ART, but dispatch is the closest we've got to an RAI area meeting. And I promised the chairs I would start this thread on the dispatch mailing list, so people can prepare and ask questions. Drafts: The simple dual-queue algo (~15 lines of pseudocode in appendix) implemented as a Linux multiqueue qdisc: > The packet identifier: > The fix to TCP-ECN feedback: > (RFC7560 sets the requirements) Background paper with rationale in english and maths, plus experimental evaluation: Meetecho video of Koen's talk & demo in IETF-93 AQM WG (starts @ about 33 mins): Cheers Bob & Koen On 19/10/15 20:20, Bob Briscoe wrote: > Mary, Cullen, > > Draft is here: > (might > get updated tonight if we get it together) > Hopefully some DISPATCHy people saw the Bits-N-Bites demo in Prague. > > But we'll also introduce it on the list and respond to questions - > after I get some sleep after the draft deadline... > I'm pulling together a Web page with pointers to other backgroud > material too. > > Cheers > > > Bob > > On 17/10/15 07:45, Mary Barnes wrote: >> We have not yet finalized the agenda/topics for IETF-94. Cullen and I >> can raise this during our discussion with the ADs for which we're >> actually a bit overdue. Given what we have on the table right now, >> we ought to have some time. One suggestion, I would make that would >> help support the discussion of this topic would be if you guys could >> go ahead and post a note to the DISPATCH WG mailing list now and that >> will give folks some time to consider and that might help you get >> more input during the f2f session (and is consistent with the >> DISPATCH WG model of not presenting brand new topics during the f2f >> meeting) >> Regards, >> Mary. >> >> On Fri, Oct 16, 2015 at 4:13 PM, Cullen Jennings wrote: >> >> >> Mary, Thoughts? >> >> Bob, Is there a draft people could read about this? >> >> (Mary is traveling right now too so not sure when she can respond) >> >> > On Oct 15, 2015, at 12:11 PM, Bob Briscoe >> wrote: >> > >> > Cullen, >> > >> > Ta - so is there room for a slot for us in Yokahoma? >> > A nice long time like 20mins would be preferred, but we would >> understand if it had to be cut to a more normal 10-15mins. >> > >> > We'll go into a huddle to think up a title. >> > >> > >> > Bob >> > >> > On 15/10/15 15:13, Cullen Jennings wrote: >> >> Hi Bob, >> >> >> >> The RAI area never had an "area WG" and we used Dispatch for >> this. With the merge to become ART I think we will still continue >> to use dispatch for conversation where we want to get out to the >> whole area. >> >> >> >> Reading the charter, I agree it does not fit, but I still >> think it's the best place. >> >> >> >> Cullen >> >> >> >> >> >> >> >> >> >>> On Oct 15, 2015, at 5:19 AM, Bob Briscoe >> > wrote: >> >>> >> >>> Mary, Cullen (as dispatch chairs), >> >>> >> >>> Koen and I (and others in the transport area) are trying to >> find a way to get feedback/support from nominal 'customers'. >> >>> >> >>> I don't know how the ART area works these days, but in Prague >> Cullen told me that DISPATCH might be what we're looking for. >> However, having read the charter I'm not so sure. We're not >> proposing a new RAI WG. But we're trying to get the transport >> area to think strategically, so we want to know if that would be >> supported by 'customers' of the services offered by the transport >> layer. >> >>> >> >>> Our proposed direction is going to need standardisation >> across 3 different WGs in the transport area (AQM, TCPM and >> TSVWG), with incremental changes in access networks and senders >> and receivers. So we're looking for feedback on this question: >> >>> ==> From the ART/RAI viewpoint, does the potential benefit >> make it worth being this ambitious? >> >>> >> >>> We give background to what we're trying to do below. >> >>> Then you can say if you think a heads-up presentation in the >> DISPATCH session in Yokahoma would be appropriate/useful. >> >>> >> >>> >> >>> >> >>> Bob & Koen >> >>> >> >>> >> >>> ==Background== >> >>> >> >>> If you saw our stand at Bits and Bytes or the demo in the AQM >> WG in Prague, you will know what we're talking about... >> >>> We showed a video feed from a panoramic camera at a football >> match delivered down a DSL access. You could pan and zoom the HD >> picture with finger gestures and the delay was so low it seemed >> to stick to your finger, while 100 flows per second of Web >> traffic and more than a dozen long-running flows were all being >> downloaded thru the same 40Mb/s access line - all getting the >> same ultra-low delay. >> >>> >> >>> We didn't modify the apps at all, we just switched some to a >> 'scalable' TCP underneath them. The video app just auto-adjusted >> its buffer 'cos it detected very low delay and jitter. The stats >> are pretty stunning: zero congestion loss and ultra-low queuing >> latency with no reduction in link utilization for /all/ packets. >> Even throwing very high TCP load at it, it is hard to stop it >> being near-perfect. >> >>> >> >>> If you know Diffserv, think of it like this: you can get >> pretty much as good as Diffserv EF and better than AF, but for >> /all/ traffic. So you don't have to limit Diffserv EF to a small >> fraction of the capacity by separating out TCP traffic. in fact >> we need zero management or config; two queues (no per-flow >> queues); and less ops per packet than the simplest AQM (RED). >> >>> >> >>> The insight is that 'classic' TCPs (New Reno, Cubic etc.) are >> scaling badly - the sawteeth are getting bigger and the >> responsiveness is getting slower as flow rates increase. So we >> provide a migration path to 'scalable' TCPs instead. The trick is >> to ensure there is no 'classic' TCP in the same queue as all the >> 'modern' traffic. But it's OK to mix scalable TCPs with 'modern' >> traffic. >> >>> >> >>> >> >>> >> >>> >> >>> -- >> >>> ________________________________________________________________ >> >>> Bob Briscoe http://bobbriscoe.net/ >> >>> >> > >> > -- >> > ________________________________________________________________ >> > Bob Briscoe http://bobbriscoe.net/ >> > >> >> > > -- > ________________________________________________________________ > Bob Briscoehttp://bobbriscoe.net/ -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------000507090606030309090808 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit DISPATCHers,

We have a question at the end, addressed to DISPATCH people as 'customers' of the transport layer.
Particularly about apps wanting low latency (i.e. nearly everything).

Background

If you saw our stand at Bits N Bites, or the demo in the active queue management (AQM) WG in Prague, you will know what we're talking about...

We showed a video feed from a panoramic camera at a football match delivered down a broadband access. You could pan and zoom the HD picture with finger gestures and the delay was so low it seemed to stick to your finger, while 100 flows per second of Web traffic and more than a dozen long-running flows were all being downloaded thru the same 40Mb/s access line. This wasn't Diffserv - not QoS at the expense of other traffic, so no need for permission to use a class. This was AQM for /all/ the packets in all the flows - all getting the same ultra-low delay.

We didn't modify the apps at all, we just switched the stack underneath the TCP apps to a 'scalable' TCP. The interactive video app just auto-adjusted its buffer 'cos it detected very low delay and jitter. The stats are pretty stunning: zero congestion loss and ultra-low queuing latency (99th percentile of about 1 millisecond) with no reduction in link utilization either.

The insight is that 'classic' TCPs (New Reno, Cubic etc.) have been scaling badly - the sawteeth are getting longer and the responsiveness has been getting slower as flow rates increase. The trick is to classify the old 'classic' TCP traffic behind a `semi-permeable membrane'. For flow-rate it's like the same queue, but for queuing delay it's a second queue. Then all the 'modern' apps can migrate to using the good queue, where r-t apps can safely coexist with apps using (scalable) TCP, (scalable) SCTP, RTP, etc. and they all get low delay, whether for Web browsing, gaming, interactive video, voice, http adaptive streaming, etc.

The Question

This initiative is going to need standardisation across 3 different WGs in the transport area (AQM, TCPM and TSVWG), with incremental changes in access networks and updates to host stacks (we used DCTCP as the scalable TCP, which is already in Windows Server and there's a patch for Linux). So we're looking for feedback on this question:
==> From the ART/RAI viewpoint, does the potential benefit make it worth being this ambitious?

More Info

We've asked if we can give a heads-up about this in DISPATCH in Yokahoma. The work we're proposing is outside ART, but dispatch is the closest we've got to an RAI area meeting. And I promised the chairs I would start this thread on the dispatch mailing list, so people can prepare and ask questions.

Drafts:
The simple dual-queue algo (~15 lines of pseudocode in appendix) implemented as a Linux multiqueue qdisc:
    <draft-briscoe-aqm-dualq-coupled>
The packet identifier:
    <draft-briscoe-tsvwg-ecn-l4s-id>
The fix to TCP-ECN feedback:
    <draft-kuehlewind-tcpm-accurate-ecn> (RFC7560 sets the requirements)

Background paper with rationale in english and maths, plus experimental evaluation:
<http://www.bobbriscoe.net/projects/latency/dctth_preprint.pdf>

Meetecho video of Koen's talk & demo in IETF-93 AQM WG (starts @ about 33 mins):
    <http://ietf93.conf.meetecho.com/index.php/Recorded_Sessions#AQM>

Cheers



Bob & Koen

On 19/10/15 20:20, Bob Briscoe wrote:
Mary, Cullen,

Draft is here:
<https://tools.ietf.org/html/draft-briscoe-aqm-dualq-coupled> (might get updated tonight if we get it together)
Hopefully some DISPATCHy people saw the Bits-N-Bites demo in Prague.

But we'll also introduce it on the list and respond to questions - after I get some sleep after the draft deadline...
I'm pulling together a Web page with pointers to other backgroud material too.

Cheers


Bob

On 17/10/15 07:45, Mary Barnes wrote:
We have not yet finalized the agenda/topics for IETF-94. Cullen and I can raise this during our discussion with the ADs for which we're actually a bit overdue.  Given what we have on the table right now, we ought to have some time.  One suggestion, I would make that would help support the discussion of this topic would be if you guys could go ahead and post a note to the DISPATCH WG mailing list now and that will give folks some time to consider and that might help you get more input during the f2f session (and is consistent with the DISPATCH WG model of not presenting brand new topics during the f2f meeting)
Regards,
Mary. 

On Fri, Oct 16, 2015 at 4:13 PM, Cullen Jennings <fluffy@iii.ca> wrote:

Mary, Thoughts?

Bob, Is there a draft people could read about this?

(Mary is traveling right now too so not sure when she can respond)

> On Oct 15, 2015, at 12:11 PM, Bob Briscoe <research@bobbriscoe.net> wrote:
>
> Cullen,
>
> Ta - so is there room for a slot for us in Yokahoma?
> A nice long time like 20mins would be preferred, but we would understand if it had to be cut to a more normal 10-15mins.
>
> We'll go into a huddle to think up a title.
>
>
> Bob
>
> On 15/10/15 15:13, Cullen Jennings wrote:
>> Hi Bob,
>>
>> The RAI area never had an "area WG" and we used Dispatch for this. With the merge to become ART I think we will still continue to use dispatch for conversation where we want to get out to the whole area.
>>
>> Reading the charter, I agree it does not fit, but I still think it's the best place.
>>
>> Cullen
>>
>>
>>
>>
>>> On Oct 15, 2015, at 5:19 AM, Bob Briscoe <research@bobbriscoe.net> wrote:
>>>
>>> Mary, Cullen (as dispatch chairs),
>>>
>>> Koen and I (and others in the transport area) are trying to find a way to get feedback/support from nominal 'customers'.
>>>
>>> I don't know how the ART area works these days, but in Prague Cullen told me that DISPATCH might be what we're looking for. However, having read the charter I'm not so sure. We're not proposing a new RAI WG. But we're trying to get the transport area to think strategically, so we want to know if that would be supported by 'customers' of the services offered by the transport layer.
>>>
>>> Our proposed direction is going to need standardisation across 3 different WGs in the transport area (AQM, TCPM and TSVWG), with incremental changes in access networks and senders and receivers. So we're looking for feedback on this question:
>>> ==> From the ART/RAI viewpoint, does the potential benefit make it worth being this ambitious?
>>>
>>> We give background to what we're trying to do below.
>>> Then you can say if you think a heads-up presentation in the DISPATCH session in Yokahoma would be appropriate/useful.
>>>
>>>
>>>
>>> Bob & Koen
>>>
>>>
>>> ==Background==
>>>
>>> If you saw our stand at Bits and Bytes or the demo in the AQM WG in Prague, you will know what we're talking about...
>>> We showed a video feed from a panoramic camera at a football match delivered down a DSL access. You could pan and zoom the HD picture with finger gestures and the delay was so low it seemed to stick to your finger, while 100 flows per second of Web traffic and more than a dozen long-running flows were all being downloaded thru the same 40Mb/s access line - all getting the same ultra-low delay.
>>>
>>> We didn't modify the apps at all, we just switched some to a 'scalable' TCP underneath them. The video app just auto-adjusted its buffer 'cos it detected very low delay and jitter. The stats are pretty stunning: zero congestion loss and ultra-low queuing latency with no reduction in link utilization for /all/ packets. Even throwing very high TCP load at it, it is hard to stop it being near-perfect.
>>>
>>> If you know Diffserv, think of it like this: you can get pretty much as good as Diffserv EF and better than AF, but for /all/ traffic. So you don't have to limit Diffserv EF to a small fraction of the capacity by separating out TCP traffic. in fact we need zero management or config; two queues (no per-flow queues); and less ops per packet than the simplest AQM (RED).
>>>
>>> The insight is that 'classic' TCPs (New Reno, Cubic etc.) are scaling badly - the sawteeth are getting bigger and the responsiveness is getting slower as flow rates increase. So we provide a migration path to 'scalable' TCPs instead. The trick is to ensure there is no 'classic' TCP in the same queue as all the 'modern' traffic. But it's OK to mix scalable TCPs with 'modern' traffic.
>>>
>>>
>>>
>>>
>>> --
>>> ________________________________________________________________
>>> Bob Briscoe                               http://bobbriscoe.net/
>>>
>
> --
> ________________________________________________________________
> Bob Briscoe                               http://bobbriscoe.net/
>



-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/


-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------000507090606030309090808-- From nobody Fri Oct 23 09:57:27 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 911041A8718 for ; Fri, 23 Oct 2015 09:57:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=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 Bcy6s8GqMrte for ; Fri, 23 Oct 2015 09:57:25 -0700 (PDT) Received: from resqmta-ch2-01v.sys.comcast.net (resqmta-ch2-01v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:33]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 440641A870C for ; Fri, 23 Oct 2015 09:57:25 -0700 (PDT) Received: from resomta-ch2-02v.sys.comcast.net ([69.252.207.98]) by resqmta-ch2-01v.sys.comcast.net with comcast id Ygvc1r00427uzMh01gxQoN; Fri, 23 Oct 2015 16:57:24 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-02v.sys.comcast.net with comcast id YgxP1r00g3Ge9ey01gxQe5; Fri, 23 Oct 2015 16:57:24 +0000 To: dispatch@ietf.org References: <7594FB04B1934943A5C02806D1A2204B37B62FC0@ESESSMB209.ericsson.se> <90429FC5-4199-4386-8CEE-F7F9E45420CE@nostrum.com> <7594FB04B1934943A5C02806D1A2204B37B6907F@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37B691E1@ESESSMB209.ericsson.se> From: Paul Kyzivat Message-ID: <562A66F2.7040509@alum.mit.edu> Date: Fri, 23 Oct 2015 12:57:22 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37B691E1@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1445619444; bh=PEkLYbTPSpgvcMhn9IUT+TE2n8q5+NeLFd2G6mZdQOY=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=VpqOsk2dQYrly0qtr6c51ldUyHUyU7uqOY8ZctPlMaksh90l0hgG5U91bTujF/pOv bpsANQYIgW8ThCoq7VmNRoxYTX1spoozqt17B1jplymE4eVKkLZlwRebiqzUOYEpD2 BxcBY4SrRiXUmh4h5h5SGO+PGAEOh9doHN1shT64HHnrAuMH0bKsZFm0r3zdxy9wCK i/I6P1sRIiCtn+vD1f9k/czdu2WNP83vr1sNeyWCvNtWz9UGdS/q/M+nD1enEYaj+5 IqqdP4MddHyKsVObv+ZKBoqS8ktmE3lJxwZbBqrJjtO/iNtsbTbNiRFItJZlddMKkX QtjOKuo/hQCQg== Archived-At: Subject: Re: [dispatch] Draft new: draft-holmberg-dispatch-pani-abnf-00 [was: [sipcore] [Technical Errata Reported] RFC7315 (4474)] X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2015 16:57:26 -0000 Looks fine to me. Ship it!!! Thanks, Paul On 10/18/15 3:10 PM, Christer Holmberg wrote: > Hi, > > I've submitted a new version, -01, where the category is changed to 'Informational'. > > Regards, > > Christer > > -----Original Message----- > From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Christer Holmberg > Sent: 18 October 2015 21:59 > To: Ben Campbell > Cc: DISPATCH list ; SIPCORE > Subject: Re: [dispatch] Draft new: draft-holmberg-dispatch-pani-abnf-00 [was: [sipcore] [Technical Errata Reported] RFC7315 (4474)] > > Hi, > >> If 7315 is informational, why does the update need to be standards track? > > Good point - I guess it doesn't have to :) > > Regards, > > Christer > > > On 18 Oct 2015, at 6:49, Christer Holmberg wrote: > >> Hi, >> >> Based on Ben’s guidance, I’ve submitted a draft which makes the ABNF >> update. >> >> NOTE: As RFC 7315 is an Informational RFC, I had to add the RFC as an >> Informative reference in the draft, in order to pass the Idnits check. >> >> >> A new version of I-D, draft-holmberg-dispatch-pani-abnf-00.txt >> >> has been successfully submitted by Christer Holmberg and posted to the >> IETF repository. >> >> >> >> Name: draft-holmberg-dispatch-pani-abnf >> >> Revision: 00 >> >> Title: P-Access-Network-Info ABNF Update >> >> Document date: 2015-10-18 >> >> Group: Individual Submission >> >> Pages: 4 >> >> URL: >> https://www.ietf.org/internet-drafts/draft-holmberg-dispatch-pani-abnf >> -00.txt >> >> Status: >> https://datatracker.ietf.org/doc/draft-holmberg-dispatch-pani-abnf/ >> >> Htmlized: >> https://tools.ietf.org/html/draft-holmberg-dispatch-pani-abnf-00 >> >> >> >> >> >> Abstract: >> >> This document updates RFC 7315, by modifying the extension-access- >> >> info part of the P-Access-Network-Info header field Augmented Backus- >> >> Naur Form (ABNF). >> >> >> Regards, >> >> Christer >> >> >> >> >> From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer >> Holmberg >> Sent: 18 October 2015 10:52 >> To: Ben Campbell >> Cc: DISPATCH list ; SIPCORE ; >> Cullen Jennings >> Subject: Re: [sipcore] [dispatch] [Technical Errata Reported] RFC7315 >> (4474) >> >> Hi, >> >> So, shall I address the draft to some WG, or? >> >> draft-holmberg-dispatch ? >> >> Regards, >> >> Christer >> >> Sent from my Windows Phone >> ________________________________ >> From: Ben Campbell >> Sent: ‎14/‎10/‎2015 17:21 >> To: Christer Holmberg >> Cc: Cullen Jennings; DISPATCH >> list; SIPCORE >> Subject: Re: [sipcore] [dispatch] [Technical Errata Reported] RFC7315 >> (4474) >> On 8 Oct 2015, at 21:03, Christer Holmberg wrote: >> >>> Hi Cullen, >>> >>> So, you are suggesting a SIPCORE draft that updates the ABNF? >> >> This is where the chairs will point out that special-purpose >> extensions are generally not in scope for sipcore :-) If so, this >> might could also be done as AD sponsored. >> >> Ben. > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From nobody Fri Oct 23 13:07:54 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6214C1A6FF2; Fri, 23 Oct 2015 13:07:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 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, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 MiKgNrIMeWH1; Fri, 23 Oct 2015 13:07:51 -0700 (PDT) Received: from mail-yk0-x235.google.com (mail-yk0-x235.google.com [IPv6:2607:f8b0:4002:c07::235]) (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 89D0B1A1B59; Fri, 23 Oct 2015 13:07:51 -0700 (PDT) Received: by ykdr3 with SMTP id r3so131625929ykd.1; Fri, 23 Oct 2015 13:07:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=/XJ0ykwpd3kAqCtI8ItYzuuf2tpXOwLwnYhxoUVVqI4=; b=bmqZotvBLozUc9EsxZRxjHzSg1tSj6LwK+Jap5L90qU8GUhrIN9t2DNtvtIFWV6O8Q /2hxJUSprQSrofsBG+xXdtqwO7qqk5g4GB/lzpNejVmdgyj2rZchuWr1KBTzNYg+fvvK NPlE4Bvd/7JnmZVY7BFr1oCbWGrIchVthj6xAW2sR56Cm9DlNp5/CyJDSXfgfcGkS32P ndt1KqqEb8JZ7yYRTqjiSSxM6cM+tR3A/8V4OkXc+fyxRT4j8O5oYWxeBQ+nsJ6fiGpF uucBtD7tt6wcsqUjV/pmhsskRa2+kte+PbqFDdworfY97xGtl3WftmtOXMEyYpKJ8Iqn 2jig== MIME-Version: 1.0 X-Received: by 10.129.48.134 with SMTP id w128mr18513993yww.251.1445630870801; Fri, 23 Oct 2015 13:07:50 -0700 (PDT) Received: by 10.37.29.86 with HTTP; Fri, 23 Oct 2015 13:07:50 -0700 (PDT) Date: Fri, 23 Oct 2015 15:07:50 -0500 Message-ID: From: Mary Barnes To: DISPATCH Content-Type: multipart/alternative; boundary=001a114143f687cf9d0522cb2aae Archived-At: Cc: Cullen Jennings , Alexey Melnikov , art-ads@ietf.org Subject: [dispatch] IETF-94 DISPATCH Topics X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2015 20:07:53 -0000 --001a114143f687cf9d0522cb2aae Content-Type: text/plain; charset=UTF-8 Hi all, Below please find the topics proposed during the IETF-94 timeframe and plans for handling. Regards, Mary ============================================================== The following topics will be allocated agenda time at IETF-94: 1) Discussion of the new DISPATCH WG charter (5 minutes): https://mailarchive.ietf.org/arch/msg/dispatch/BhiAC1FENumiAa9NKpNxiB1Fwdk 2) OSRTP document (30 minutes): http://datatracker.ietf.org/doc/draft-johnston-dispatch-osrtp/ Charter proposal: https://mailarchive.ietf.org/arch/msg/dispatch/u4-gTan844X8_Vs0JVLWGbIg47g 3) HTTP problem statement document (15 minutes): https://www.ietf.org/archive/id/draft-nottingham-http-problem-07.txt 4) The font Primary Content type (15 minutes): https://tools.ietf.org/html/draft-lilley-font-toplevel-00 5) Ultra Low Latency for realtime applications (15 minutes) Proposal (including related drafts): https://mailarchive.ietf.org/arch/msg/dispatch/vn2Ew1MsmvnCeizFVx5dBoYS0z8 The following document is proposed to be AD sponsored (a separate email requesting comments will be posted): 6) P-Access-Network-Info ABNF Update: http://datatracker.ietf.org/doc/draft-holmberg-dispatch-pani-abnf/ --001a114143f687cf9d0522cb2aae Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi all,

Below please find t= he topics proposed during the IETF-94 timeframe and plans for handling.
=

Regards,

Mary

=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D

The following topics will = be allocated agenda time at IETF-94:

1) D= iscussion of the new DISPATCH WG charter (5 minutes):=C2=A0
https://mailarchive.ietf.org/arch/msg/dispatch= /BhiAC1FENumiAa9NKpNxiB1Fwdk

2) OSRTP document (30 minutes):=C2=A0http://datatrac= ker.ietf.org/doc/draft-johnston-dispatch-osrtp/
Charter proposal:=C2=A0https://mailarchive.iet= f.org/arch/msg/dispatch/u4-gTan844X8_Vs0JVLWGbIg47g

3) HTTP problem statement document (15 minutes= ): =C2=A0https://www.ietf.org/archive/id/draft-notti= ngham-http-problem-07.txt

4) The font Primary Content type (15 minutes): =C2=A0https:/= /tools.ietf.org/html/draft-lilley-font-toplevel-00=C2=A0=C2=A0= =C2=A0

5) =C2=A0Ultra Low Latency = for realtime applications (15 minutes)

Proposal (including related drafts):=C2=A0

https://mailarchive.ietf.org/arch/msg/dispatch/vn2Ew1MsmvnCeizFVx= 5dBoYS0z8


The following document= is proposed to be AD sponsored (a separate email requesting comments will = be posted):=C2=A0

6) P-Access-Network-Info ABNF Update: = =C2=A0 =C2=A0http://datatracker.ietf.org/doc/draft-hol= mberg-dispatch-pani-abnf/

--001a114143f687cf9d0522cb2aae-- From nobody Mon Oct 26 12:29:04 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BBC31B516C for ; Mon, 26 Oct 2015 12:29:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable 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 KA3i2D_BpPvI for ; Mon, 26 Oct 2015 12:29:03 -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 4255E1B5143 for ; Mon, 26 Oct 2015 12:23:43 -0700 (PDT) Received: from [10.0.1.10] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t9QJNfBw091911 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 26 Oct 2015 14:23:42 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.10] From: "Ben Campbell" To: "Michael Niedermayer" Date: Mon, 26 Oct 2015 14:23:54 -0500 Message-ID: <98E2EBE2-4580-4A12-A77C-FAE69185F171@nostrum.com> In-Reply-To: <20151022211948.GS4556@nb4> References: <20151022133935.26487.12997.idtracker@ietfa.amsl.com> <2D88BA7A-6B89-465E-91FC-4FB6DC422434@nostrum.com> <20151022211948.GS4556@nb4> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.2r5141) Archived-At: Cc: DISPATCH Subject: Re: [dispatch] Stephen Farrell's Yes on charter-ietf-cellar-00-00: (with COMMENT) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2015 19:29:04 -0000 On 22 Oct 2015, at 16:19, Michael Niedermayer wrote: [...] >>>> >>>> I wonder is there any interest in the security of the archived >>>> stuff here, and whether the WG would want to possibly take >>>> that on, most likely later. I'm not saying they should, as that >>>> could be a lot of possibly contentious work, but if they did >>>> want to do it, it'd be good to say in the charter. >> >> Does he mean security as in only allowing certain people to access >> the >> data ? IMO it's out of the scope and better handled out of the file >> format/streaming. It's more a transport/storage issue than format. >> >> There is encryption possible in WebM though that's working with a EME >> DRM module. >> http://www.webmproject.org/docs/webm-encryption/ >> > >> If he means data safety, that's something we can work on. We already >> have the CRC for checking. In the past we also discussed redundancy >> but it was ruled out (again, better handled outside of the file >> format). > > forward error correction, that is to add redundancy to recover from > damaged or lost parts of an archived file or stream/track, is > something that sounds interresting. CRCs also exist at the video > stream > (FFv1) layer. Theres currently no means to restore lost frames, slices > or disk sectors except through concealing them based on previous > frames. The existing CRCs are sufficient though to correct rare bit > errors, if that occurs in any actual use case. > Adding some layer of protection to protect from damaged or unreadable > disk sectors or other larger damges losslessly is possible and > interresting. Iam not sure at which layer that would be best to do > though. For the record, I think Stephen was asking more about confidentiality than about error correction. Do you think anything relative to error correction needs to be added to the charter? It seem to me that is something that could be added in a future recharter if people think something becomes needed beyond the currently planned work. Ben. From nobody Tue Oct 27 08:05:05 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3103C1A8F3B; Tue, 27 Oct 2015 08:05:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 yDdWKb50RpWY; Tue, 27 Oct 2015 08:04:59 -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 9FA511A8F46; Tue, 27 Oct 2015 08:03:29 -0700 (PDT) Received: from [10.0.1.10] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t9RF3P9h021554 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 27 Oct 2015 10:03:25 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.10] From: "Ben Campbell" To: "Stephen Farrell" , DISPATCH Date: Tue, 27 Oct 2015 10:03:40 -0500 Message-ID: In-Reply-To: <2D88BA7A-6B89-465E-91FC-4FB6DC422434@nostrum.com> References: <20151022133935.26487.12997.idtracker@ietfa.amsl.com> <2D88BA7A-6B89-465E-91FC-4FB6DC422434@nostrum.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.2r5141) Archived-At: Cc: The IESG , cellar-chairs@ietf.org Subject: Re: [dispatch] Stephen Farrell's Yes on charter-ietf-cellar-00-00: (with COMMENT) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2015 15:05:02 -0000 Hi, I don't see a concrete change to the proposed charter from this conversation so far. I'm going to release this for external review. If further discussion suggests a change, we can deal with that along with other external review comments. Thanks! Ben. On 22 Oct 2015, at 10:18, Ben Campbell wrote: > (+dispatch for now; we will setup a cellar list shortly). > > Does anyone have thoughts on Stephen's comment below? > > Thanks! > > Ben. > > > On 22 Oct 2015, at 8:39, Stephen Farrell wrote: > >> Stephen Farrell has entered the following ballot position for >> charter-ietf-cellar-00-00: Yes >> > > [...] > >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/charter-ietf-cellar/ >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> >> I wonder is there any interest in the security of the archived >> stuff here, and whether the WG would want to possibly take >> that on, most likely later. I'm not saying they should, as that >> could be a lot of possibly contentious work, but if they did >> want to do it, it'd be good to say in the charter. > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From nobody Tue Oct 27 12:16:41 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9B571ACE63 for ; Tue, 27 Oct 2015 12:16:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 E3VTlaAJ_6N5 for ; Tue, 27 Oct 2015 12:16:37 -0700 (PDT) Received: from relay2-d.mail.gandi.net (relay2-d.mail.gandi.net [IPv6:2001:4b98:c:538::194]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66D071ACE6D for ; Tue, 27 Oct 2015 12:16:37 -0700 (PDT) Received: from mfilter22-d.gandi.net (mfilter22-d.gandi.net [217.70.178.150]) by relay2-d.mail.gandi.net (Postfix) with ESMTP id 81F52C5A5C; Tue, 27 Oct 2015 20:16:35 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mfilter22-d.gandi.net Received: from relay2-d.mail.gandi.net ([IPv6:::ffff:217.70.183.194]) by mfilter22-d.gandi.net (mfilter22-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id 2wtXvtcyWzNc; Tue, 27 Oct 2015 20:16:33 +0100 (CET) X-Originating-IP: 84.114.129.144 Received: from localhost (chello084114129144.4.15.vie.surfer.at [84.114.129.144]) (Authenticated sender: michael@niedermayer.cc) by relay2-d.mail.gandi.net (Postfix) with ESMTPSA id DFED5C5A40; Tue, 27 Oct 2015 20:16:32 +0100 (CET) Date: Tue, 27 Oct 2015 20:15:36 +0100 From: Michael Niedermayer To: Ben Campbell Message-ID: <20151027191536.GY4556@nb4> References: <20151022133935.26487.12997.idtracker@ietfa.amsl.com> <2D88BA7A-6B89-465E-91FC-4FB6DC422434@nostrum.com> <20151022211948.GS4556@nb4> <98E2EBE2-4580-4A12-A77C-FAE69185F171@nostrum.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="T/Mbx1CndTR58uu2" Content-Disposition: inline In-Reply-To: <98E2EBE2-4580-4A12-A77C-FAE69185F171@nostrum.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: DISPATCH Subject: Re: [dispatch] Stephen Farrell's Yes on charter-ietf-cellar-00-00: (with COMMENT) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2015 19:16:39 -0000 --T/Mbx1CndTR58uu2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Oct 26, 2015 at 02:23:54PM -0500, Ben Campbell wrote: > On 22 Oct 2015, at 16:19, Michael Niedermayer wrote: >=20 >=20 > [...] >=20 > >>>> > >>>>I wonder is there any interest in the security of the archived > >>>>stuff here, and whether the WG would want to possibly take > >>>>that on, most likely later. I'm not saying they should, as that > >>>>could be a lot of possibly contentious work, but if they did > >>>>want to do it, it'd be good to say in the charter. > >> > >>Does he mean security as in only allowing certain people to > >>access the > >>data ? IMO it's out of the scope and better handled out of the file > >>format/streaming. It's more a transport/storage issue than format. > >> > >>There is encryption possible in WebM though that's working with a EME > >>DRM module. > >>http://www.webmproject.org/docs/webm-encryption/ > >> > > > >>If he means data safety, that's something we can work on. We already > >>have the CRC for checking. In the past we also discussed redundancy > >>but it was ruled out (again, better handled outside of the file > >>format). > > > >forward error correction, that is to add redundancy to recover from > >damaged or lost parts of an archived file or stream/track, is > >something that sounds interresting. CRCs also exist at the video > >stream > >(FFv1) layer. Theres currently no means to restore lost frames, slices > >or disk sectors except through concealing them based on previous > >frames. The existing CRCs are sufficient though to correct rare bit > >errors, if that occurs in any actual use case. > >Adding some layer of protection to protect from damaged or unreadable > >disk sectors or other larger damges losslessly is possible and > >interresting. Iam not sure at which layer that would be best to do > >though. >=20 > For the record, I think Stephen was asking more about > confidentiality than about error correction. >=20 > Do you think anything relative to error correction needs to be added > to the charter? It seem to me that is something that could be added > in a future recharter if people think something becomes needed > beyond the currently planned work. the charter is fine, i just wanted to comment on "data safety", which as it turns out the original question wasnt about ... [...] --=20 Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Rewriting code that is poorly written but fully understood is good. Rewriting code that one doesnt understand is a sign that one is less smart then the original author, trying to rewrite it will not make it better. --T/Mbx1CndTR58uu2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlYvzVgACgkQYR7HhwQLD6tt0QCfRNUIz3QNQicucpEdw77ettyI m2AAnjYvf7mhIDMGn5CqCyjNFwP5bm0X =a57r -----END PGP SIGNATURE----- --T/Mbx1CndTR58uu2-- From nobody Tue Oct 27 14:46:08 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71FB71B29B8; Tue, 27 Oct 2015 14:46:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 svA9M930cxTc; Tue, 27 Oct 2015 14:46:04 -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 70C7B1B29B7; Tue, 27 Oct 2015 14:46:04 -0700 (PDT) Received: from mutabilis-2.local (pool-71-164-199-31.dllstx.fios.verizon.net [71.164.199.31]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t9RLjxDC084862 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 27 Oct 2015 16:46:00 -0500 (CDT) (envelope-from mahoney@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-71-164-199-31.dllstx.fios.verizon.net [71.164.199.31] claimed to be mutabilis-2.local To: Christer Holmberg , Ben Campbell References: <7594FB04B1934943A5C02806D1A2204B37B62FC0@ESESSMB209.ericsson.se> <90429FC5-4199-4386-8CEE-F7F9E45420CE@nostrum.com> <7594FB04B1934943A5C02806D1A2204B37B6907F@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37B691E1@ESESSMB209.ericsson.se> From: "A. Jean Mahoney" Message-ID: <562FF092.3090605@nostrum.com> Date: Tue, 27 Oct 2015 16:45:54 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37B691E1@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: DISPATCH list , SIPCORE Subject: Re: [dispatch] Draft new: draft-holmberg-dispatch-pani-abnf-00 [was: [sipcore] [Technical Errata Reported] RFC7315 (4474)] X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2015 21:46:06 -0000 Hi Christer, The draft looks good to me. Just a few nits: 1. Introduction 2nd paragraph: "requires new values are required" => "requires new values". 4th paragraph: "have been followed" => "have been defined" You may also consider adding a reference to TS 24.229, which defines values for access-info, to the 4th paragraph. Thanks! Jean On 10/18/15 2:10 PM, Christer Holmberg wrote: > Hi, > > I've submitted a new version, -01, where the category is changed to 'Informational'. > > Regards, > > Christer > > -----Original Message----- > From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Christer Holmberg > Sent: 18 October 2015 21:59 > To: Ben Campbell > Cc: DISPATCH list ; SIPCORE > Subject: Re: [dispatch] Draft new: draft-holmberg-dispatch-pani-abnf-00 [was: [sipcore] [Technical Errata Reported] RFC7315 (4474)] > > Hi, > >> If 7315 is informational, why does the update need to be standards track? > > Good point - I guess it doesn't have to :) > > Regards, > > Christer > > > On 18 Oct 2015, at 6:49, Christer Holmberg wrote: > >> Hi, >> >> Based on Ben’s guidance, I’ve submitted a draft which makes the ABNF >> update. >> >> NOTE: As RFC 7315 is an Informational RFC, I had to add the RFC as an >> Informative reference in the draft, in order to pass the Idnits check. >> >> >> A new version of I-D, draft-holmberg-dispatch-pani-abnf-00.txt >> >> has been successfully submitted by Christer Holmberg and posted to the >> IETF repository. >> >> >> >> Name: draft-holmberg-dispatch-pani-abnf >> >> Revision: 00 >> >> Title: P-Access-Network-Info ABNF Update >> >> Document date: 2015-10-18 >> >> Group: Individual Submission >> >> Pages: 4 >> >> URL: >> https://www.ietf.org/internet-drafts/draft-holmberg-dispatch-pani-abnf >> -00.txt >> >> Status: >> https://datatracker.ietf.org/doc/draft-holmberg-dispatch-pani-abnf/ >> >> Htmlized: >> https://tools.ietf.org/html/draft-holmberg-dispatch-pani-abnf-00 >> >> >> >> >> >> Abstract: >> >> This document updates RFC 7315, by modifying the extension-access- >> >> info part of the P-Access-Network-Info header field Augmented Backus- >> >> Naur Form (ABNF). >> >> >> Regards, >> >> Christer >> >> >> >> >> From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer >> Holmberg >> Sent: 18 October 2015 10:52 >> To: Ben Campbell >> Cc: DISPATCH list ; SIPCORE ; >> Cullen Jennings >> Subject: Re: [sipcore] [dispatch] [Technical Errata Reported] RFC7315 >> (4474) >> >> Hi, >> >> So, shall I address the draft to some WG, or? >> >> draft-holmberg-dispatch ? >> >> Regards, >> >> Christer >> >> Sent from my Windows Phone >> ________________________________ >> From: Ben Campbell >> Sent: ‎14/‎10/‎2015 17:21 >> To: Christer Holmberg >> Cc: Cullen Jennings; DISPATCH >> list; SIPCORE >> Subject: Re: [sipcore] [dispatch] [Technical Errata Reported] RFC7315 >> (4474) >> On 8 Oct 2015, at 21:03, Christer Holmberg wrote: >> >>> Hi Cullen, >>> >>> So, you are suggesting a SIPCORE draft that updates the ABNF? >> >> This is where the chairs will point out that special-purpose >> extensions are generally not in scope for sipcore :-) If so, this >> might could also be done as AD sponsored. >> >> Ben. > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From nobody Tue Oct 27 15:02:43 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CD141B29DC; Tue, 27 Oct 2015 15:02:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 pEb0LI_3jB1y; Tue, 27 Oct 2015 15:02:39 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9A761B29DA; Tue, 27 Oct 2015 15:02:38 -0700 (PDT) X-AuditID: c1b4fb25-f79a26d00000149a-26-562ff47bfb9e Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id D0.E0.05274.B74FF265; Tue, 27 Oct 2015 23:02:36 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.61]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.03.0248.002; Tue, 27 Oct 2015 23:02:35 +0100 From: Christer Holmberg To: "A. Jean Mahoney" , Ben Campbell Thread-Topic: [dispatch] Draft new: draft-holmberg-dispatch-pani-abnf-00 [was: [sipcore] [Technical Errata Reported] RFC7315 (4474)] Thread-Index: AQHRCdioJHiLHvuz1060lsfM8JgPcp5/3UAAgAAVMzA= Date: Tue, 27 Oct 2015 22:02:34 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37B94F9B@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37B62FC0@ESESSMB209.ericsson.se> <90429FC5-4199-4386-8CEE-F7F9E45420CE@nostrum.com> <7594FB04B1934943A5C02806D1A2204B37B6907F@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37B691E1@ESESSMB209.ericsson.se> <562FF092.3090605@nostrum.com> In-Reply-To: <562FF092.3090605@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprIIsWRmVeSWpSXmKPExsUyM+JvrW7NF/0wg/cb2Czmd55mt1g6aQGr RUPnSlaLrz82sTmweCxZ8pPJY9bOJywBTFFcNimpOZllqUX6dglcGROaZ7AWHDGoWHPzBnsD 4xL9LkZODgkBE4lfHe1MELaYxIV769m6GLk4hASOMEo0brrDBOEsZpRYP/MwYxcjBwebgIVE 9z9tkAYRAW+Jk9uvsYKEmQUcJaatyQYpFxZoZZRo3r2LHcQREWhjlNgwawIjRIOVxPQ1T8Dm sAioShyaZQsS5hXwlXi25w8LxK7VTBILzxxiAUlwCmhLnPi8nx3EZgS67vupNWCXMguIS9x6 Mh/qagGJJXvOM0PYohIvH/9jhbCVJBbd/swEcZymxPpd+hCtihJTuh+yQ+wVlDg58wnLBEax WUimzkLomIWkYxaSjgWMLKsYRYtTi5Ny042M9VKLMpOLi/Pz9PJSSzYxAiPq4JbfqjsYL79x PMQowMGoxMNrUKEXJsSaWFZcmXuIUYKDWUmEtydbP0yINyWxsiq1KD++qDQntfgQozQHi5I4 bzPTg1AhgfTEktTs1NSC1CKYLBMHp1QDIzf/p13S/p+XTSzinr7snq7L0ikC6dermP6wh7U0 9C1ccED8GFPy2+7aC3k/DCK/FE73jjzDseZ0kM3kU4//7z58yWjdhxu11S/WV/tbPLh7MJW9 ibf+6sO4Ounp8gc7pz3Zs8dTenp13sH4a9qSa8yWR4WpNzdVz73Ju2eL7+nAiB1rgna++6rE UpyRaKjFXFScCACTKOQ2pAIAAA== Archived-At: Cc: DISPATCH list , SIPCORE Subject: Re: [dispatch] Draft new: draft-holmberg-dispatch-pani-abnf-00 [was: [sipcore] [Technical Errata Reported] RFC7315 (4474)] X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2015 22:02:41 -0000 SGkgSmVhbiwNCg0KVGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzISBJIHdpbGwgdXBkYXRlIHRoZSBk cmFmdCBhY2NvcmRpbmcgdG8geW91ciBzdWdnZXN0aW9ucy4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0 ZXINCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEEuIEplYW4gTWFob25leSBb bWFpbHRvOm1haG9uZXlAbm9zdHJ1bS5jb21dIA0KU2VudDogMjcgT2N0b2JlciAyMDE1IDIzOjQ2 DQpUbzogQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT47 IEJlbiBDYW1wYmVsbCA8YmVuQG5vc3RydW0uY29tPg0KQ2M6IERJU1BBVENIIGxpc3QgPGRpc3Bh dGNoQGlldGYub3JnPjsgU0lQQ09SRSA8c2lwY29yZUBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBb ZGlzcGF0Y2hdIERyYWZ0IG5ldzogZHJhZnQtaG9sbWJlcmctZGlzcGF0Y2gtcGFuaS1hYm5mLTAw IFt3YXM6IFtzaXBjb3JlXSBbVGVjaG5pY2FsIEVycmF0YSBSZXBvcnRlZF0gUkZDNzMxNSAoNDQ3 NCldDQoNCkhpIENocmlzdGVyLA0KDQpUaGUgZHJhZnQgbG9va3MgZ29vZCB0byBtZS4gSnVzdCBh IGZldyBuaXRzOg0KDQoxLiBJbnRyb2R1Y3Rpb24NCg0KMm5kIHBhcmFncmFwaDogInJlcXVpcmVz IG5ldyB2YWx1ZXMgYXJlIHJlcXVpcmVkIiA9PiAicmVxdWlyZXMgbmV3IHZhbHVlcyIuDQoNCjR0 aCBwYXJhZ3JhcGg6ICJoYXZlIGJlZW4gZm9sbG93ZWQiID0+ICJoYXZlIGJlZW4gZGVmaW5lZCIN Cg0KWW91IG1heSBhbHNvIGNvbnNpZGVyIGFkZGluZyBhIHJlZmVyZW5jZSB0byBUUyAyNC4yMjks IHdoaWNoIGRlZmluZXMgdmFsdWVzIGZvciBhY2Nlc3MtaW5mbywgdG8gdGhlIDR0aCBwYXJhZ3Jh cGguDQoNClRoYW5rcyENCg0KSmVhbg0KDQoNCk9uIDEwLzE4LzE1IDI6MTAgUE0sIENocmlzdGVy IEhvbG1iZXJnIHdyb3RlOg0KPiBIaSwNCj4NCj4gSSd2ZSBzdWJtaXR0ZWQgYSBuZXcgdmVyc2lv biwgLTAxLCB3aGVyZSB0aGUgY2F0ZWdvcnkgaXMgY2hhbmdlZCB0byAnSW5mb3JtYXRpb25hbCcu DQo+DQo+IFJlZ2FyZHMsDQo+DQo+IENocmlzdGVyDQo+DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+IEZyb206IGRpc3BhdGNoIFttYWlsdG86ZGlzcGF0Y2gtYm91bmNlc0BpZXRmLm9y Z10gT24gQmVoYWxmIE9mIA0KPiBDaHJpc3RlciBIb2xtYmVyZw0KPiBTZW50OiAxOCBPY3RvYmVy IDIwMTUgMjE6NTkNCj4gVG86IEJlbiBDYW1wYmVsbCA8YmVuQG5vc3RydW0uY29tPg0KPiBDYzog RElTUEFUQ0ggbGlzdCA8ZGlzcGF0Y2hAaWV0Zi5vcmc+OyBTSVBDT1JFIDxzaXBjb3JlQGlldGYu b3JnPg0KPiBTdWJqZWN0OiBSZTogW2Rpc3BhdGNoXSBEcmFmdCBuZXc6IA0KPiBkcmFmdC1ob2xt YmVyZy1kaXNwYXRjaC1wYW5pLWFibmYtMDAgW3dhczogW3NpcGNvcmVdIFtUZWNobmljYWwgRXJy YXRhIA0KPiBSZXBvcnRlZF0gUkZDNzMxNSAoNDQ3NCldDQo+DQo+IEhpLA0KPg0KPj4gSWYgNzMx NSBpcyBpbmZvcm1hdGlvbmFsLCB3aHkgZG9lcyB0aGUgdXBkYXRlIG5lZWQgdG8gYmUgc3RhbmRh cmRzIHRyYWNrPw0KPg0KPiBHb29kIHBvaW50IC0gSSBndWVzcyBpdCBkb2Vzbid0IGhhdmUgdG8g OikNCj4NCj4gUmVnYXJkcywNCj4NCj4gQ2hyaXN0ZXINCj4NCj4NCj4gT24gMTggT2N0IDIwMTUs IGF0IDY6NDksIENocmlzdGVyIEhvbG1iZXJnIHdyb3RlOg0KPg0KPj4gSGksDQo+Pg0KPj4gQmFz ZWQgb24gQmVu4oCZcyBndWlkYW5jZSwgSeKAmXZlIHN1Ym1pdHRlZCBhIGRyYWZ0IHdoaWNoIG1h a2VzIHRoZSBBQk5GIA0KPj4gdXBkYXRlLg0KPj4NCj4+IE5PVEU6IEFzIFJGQyA3MzE1IGlzIGFu IEluZm9ybWF0aW9uYWwgUkZDLCBJIGhhZCB0byBhZGQgdGhlIFJGQyBhcyBhbiANCj4+IEluZm9y bWF0aXZlIHJlZmVyZW5jZSBpbiB0aGUgZHJhZnQsIGluIG9yZGVyIHRvIHBhc3MgdGhlIElkbml0 cyBjaGVjay4NCj4+DQo+Pg0KPj4gQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWhvbG1iZXJn LWRpc3BhdGNoLXBhbmktYWJuZi0wMC50eHQNCj4+DQo+PiBoYXMgYmVlbiBzdWNjZXNzZnVsbHkg c3VibWl0dGVkIGJ5IENocmlzdGVyIEhvbG1iZXJnIGFuZCBwb3N0ZWQgdG8gDQo+PiB0aGUgSUVU RiByZXBvc2l0b3J5Lg0KPj4NCj4+DQo+Pg0KPj4gTmFtZTogICAgICAgICAgICAgICAgIGRyYWZ0 LWhvbG1iZXJnLWRpc3BhdGNoLXBhbmktYWJuZg0KPj4NCj4+IFJldmlzaW9uOiAgICAgICAgICAg IDAwDQo+Pg0KPj4gVGl0bGU6ICAgICAgICAgICAgICAgICAgICBQLUFjY2Vzcy1OZXR3b3JrLUlu Zm8gQUJORiBVcGRhdGUNCj4+DQo+PiBEb2N1bWVudCBkYXRlOiAgICAgICAgICAgICAgMjAxNS0x MC0xOA0KPj4NCj4+IEdyb3VwOiAgICAgICAgICAgICAgICBJbmRpdmlkdWFsIFN1Ym1pc3Npb24N Cj4+DQo+PiBQYWdlczogICAgICAgICAgICAgICAgIDQNCj4+DQo+PiBVUkw6DQo+PiBodHRwczov L3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaG9sbWJlcmctZGlzcGF0Y2gtcGFu aS1hYm4NCj4+IGYNCj4+IC0wMC50eHQNCj4+DQo+PiBTdGF0dXM6DQo+PiBodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1ob2xtYmVyZy1kaXNwYXRjaC1wYW5pLWFibmYvDQo+ Pg0KPj4gSHRtbGl6ZWQ6DQo+PiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaG9s bWJlcmctZGlzcGF0Y2gtcGFuaS1hYm5mLTAwDQo+Pg0KPj4NCj4+DQo+Pg0KPj4NCj4+IEFic3Ry YWN0Og0KPj4NCj4+IFRoaXMgZG9jdW1lbnQgdXBkYXRlcyBSRkMgNzMxNSwgYnkgbW9kaWZ5aW5n IHRoZSBleHRlbnNpb24tYWNjZXNzLQ0KPj4NCj4+IGluZm8gcGFydCBvZiB0aGUgUC1BY2Nlc3Mt TmV0d29yay1JbmZvIGhlYWRlciBmaWVsZCBBdWdtZW50ZWQgQmFja3VzLQ0KPj4NCj4+IE5hdXIg Rm9ybSAoQUJORikuDQo+Pg0KPj4NCj4+IFJlZ2FyZHMsDQo+Pg0KPj4gQ2hyaXN0ZXINCj4+DQo+ Pg0KPj4NCj4+DQo+PiBGcm9tOiBzaXBjb3JlIFttYWlsdG86c2lwY29yZS1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYgT2YgQ2hyaXN0ZXIgDQo+PiBIb2xtYmVyZw0KPj4gU2VudDogMTggT2N0 b2JlciAyMDE1IDEwOjUyDQo+PiBUbzogQmVuIENhbXBiZWxsIDxiZW5Abm9zdHJ1bS5jb20+DQo+ PiBDYzogRElTUEFUQ0ggbGlzdCA8ZGlzcGF0Y2hAaWV0Zi5vcmc+OyBTSVBDT1JFIDxzaXBjb3Jl QGlldGYub3JnPjsgDQo+PiBDdWxsZW4gSmVubmluZ3MgPGZsdWZmeUBpaWkuY2E+DQo+PiBTdWJq ZWN0OiBSZTogW3NpcGNvcmVdIFtkaXNwYXRjaF0gW1RlY2huaWNhbCBFcnJhdGEgUmVwb3J0ZWRd IFJGQzczMTUNCj4+ICg0NDc0KQ0KPj4NCj4+IEhpLA0KPj4NCj4+IFNvLCBzaGFsbCBJIGFkZHJl c3MgdGhlIGRyYWZ0IHRvIHNvbWUgV0csIG9yPw0KPj4NCj4+IGRyYWZ0LWhvbG1iZXJnLWRpc3Bh dGNoID8NCj4+DQo+PiBSZWdhcmRzLA0KPj4NCj4+IENocmlzdGVyDQo+Pg0KPj4gU2VudCBmcm9t IG15IFdpbmRvd3MgUGhvbmUNCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ PiBGcm9tOiBCZW4gQ2FtcGJlbGw8bWFpbHRvOmJlbkBub3N0cnVtLmNvbT4NCj4+IFNlbnQ6IOKA jjE0L+KAjjEwL+KAjjIwMTUgMTc6MjENCj4+IFRvOiBDaHJpc3RlciBIb2xtYmVyZzxtYWlsdG86 Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPg0KPj4gQ2M6IEN1bGxlbiBKZW5uaW5nczxt YWlsdG86Zmx1ZmZ5QGlpaS5jYT47IERJU1BBVENIIA0KPj4gbGlzdDxtYWlsdG86ZGlzcGF0Y2hA aWV0Zi5vcmc+OyBTSVBDT1JFPG1haWx0bzpzaXBjb3JlQGlldGYub3JnPg0KPj4gU3ViamVjdDog UmU6IFtzaXBjb3JlXSBbZGlzcGF0Y2hdIFtUZWNobmljYWwgRXJyYXRhIFJlcG9ydGVkXSBSRkM3 MzE1DQo+PiAoNDQ3NCkNCj4+IE9uIDggT2N0IDIwMTUsIGF0IDIxOjAzLCBDaHJpc3RlciBIb2xt YmVyZyB3cm90ZToNCj4+DQo+Pj4gSGkgQ3VsbGVuLA0KPj4+DQo+Pj4gU28sIHlvdSBhcmUgc3Vn Z2VzdGluZyBhIFNJUENPUkUgZHJhZnQgdGhhdCB1cGRhdGVzIHRoZSBBQk5GPw0KPj4NCj4+IFRo aXMgaXMgd2hlcmUgdGhlIGNoYWlycyB3aWxsIHBvaW50IG91dCB0aGF0IHNwZWNpYWwtcHVycG9z ZSANCj4+IGV4dGVuc2lvbnMgYXJlIGdlbmVyYWxseSBub3QgaW4gc2NvcGUgZm9yIHNpcGNvcmUg Oi0pIElmIHNvLCB0aGlzIA0KPj4gbWlnaHQgY291bGQgYWxzbyBiZSBkb25lIGFzIEFEIHNwb25z b3JlZC4NCj4+DQo+PiBCZW4uDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+IGRpc3BhdGNoIG1haWxpbmcgbGlzdA0KPiBkaXNwYXRjaEBpZXRmLm9y Zw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Rpc3BhdGNoDQo+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IGRpc3BhdGNo IG1haWxpbmcgbGlzdA0KPiBkaXNwYXRjaEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2Rpc3BhdGNoDQo+DQoNCg== From nobody Tue Oct 27 15:15:52 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FE151B29D0; Tue, 27 Oct 2015 15:15:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 xMl__eQAH37N; Tue, 27 Oct 2015 15:15:48 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBC741AD376; Tue, 27 Oct 2015 15:15:47 -0700 (PDT) X-AuditID: c1b4fb2d-f79626d000004282-9b-562ff7914343 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.125]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id C3.43.17026.197FF265; Tue, 27 Oct 2015 23:15:46 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.61]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0248.002; Tue, 27 Oct 2015 23:15:45 +0100 From: Christer Holmberg To: Christer Holmberg , "A. Jean Mahoney" , Ben Campbell Thread-Topic: [sipcore] [dispatch] Draft new: draft-holmberg-dispatch-pani-abnf-00 [was: [Technical Errata Reported] RFC7315 (4474)] Thread-Index: AQHREQM1QjJqAdDgkUaWrjRCEz8rFJ5/594A Date: Tue, 27 Oct 2015 22:15:44 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37B9501A@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37B62FC0@ESESSMB209.ericsson.se> <90429FC5-4199-4386-8CEE-F7F9E45420CE@nostrum.com> <7594FB04B1934943A5C02806D1A2204B37B6907F@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37B691E1@ESESSMB209.ericsson.se> <562FF092.3090605@nostrum.com> <7594FB04B1934943A5C02806D1A2204B37B94F9B@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37B94F9B@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprAIsWRmVeSWpSXmKPExsUyM+Jvre6k7/phBg8mslrM7zzNbrF00gJW i4bOlawWX39sYnNg8Viy5CeTx6ydT1gCmKK4bFJSczLLUov07RK4Mhaf2stY0GdR0b9wO0sD 4xWzLkZODgkBE4lHuw4yQ9hiEhfurWfrYuTiEBI4wijx9d8JZghnMaNER+9/1i5GDg42AQuJ 7n/aIHERgUZGiUl9u9hB4swCjhLT1mSDDBIWaGeUeLAoG6Kmg1HiYcd3FpAaEQEjicVN0SA1 LAKqElcvrGIHsXkFfCX6LnawgdhCAu+ZJF7+4QSxOQX8JLpfHwGLMwId9/3UGiYQm1lAXOLW k/lMEEcLSCzZcx7qAVGJl4//sULYShKLbn9mgjhNU2L9Ln2IVkWJKd0PodYKSpyc+YRlAqPY LCRTZyF0zELSMQtJxwJGllWMosWpxcW56UbGeqlFmcnFxfl5enmpJZsYgfF0cMtv3R2Mq187 HmIU4GBU4uE1qNALE2JNLCuuzD3EKMHBrCTC25OtHybEm5JYWZValB9fVJqTWnyIUZqDRUmc t4XpQaiQQHpiSWp2ampBahFMlomDU6qBcb6Yauc7wdcnDx0K4JffnT+18aj8A4EFu5Oy//+7 MqPg4oylhT+jNxX5iF9Qm3dle8Z80Zf/22crSesu3bNuMXeLS+7nznOiXuziqp895NhO6Yg5 +53cf5FlrUF34F4hRd3eSYZLg8tnzdkQ3aD71lcx3W3xDn1zP9ugUycuzZpb27eydLmSqBJL cUaioRZzUXEiAGJruHKjAgAA Archived-At: Cc: DISPATCH list , SIPCORE Subject: Re: [dispatch] [sipcore] Draft new: draft-holmberg-dispatch-pani-abnf-00 [was: [Technical Errata Reported] RFC7315 (4474)] X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2015 22:15:50 -0000 SGksDQoNClRoZSBuZXcgdmVyc2lvbiBjYW4gYmUgc2VlbiBhdDogaHR0cHM6Ly9naXRodWIuY29t L2NkaDR1L2RyYWZ0LXBhbmktYWJuZg0KDQpJJ2xsIHN1Ym1pdCBpdCB3aGVuIHRoZSBzdWJtaXNz aW9uIHdpbmRvdyBvcGVucy4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCkZyb206IHNpcGNvcmUgW21haWx0bzpzaXBjb3JlLWJvdW5jZXNAaWV0 Zi5vcmddIE9uIEJlaGFsZiBPZiBDaHJpc3RlciBIb2xtYmVyZw0KU2VudDogMjggT2N0b2JlciAy MDE1IDAwOjAzDQpUbzogQS4gSmVhbiBNYWhvbmV5IDxtYWhvbmV5QG5vc3RydW0uY29tPjsgQmVu IENhbXBiZWxsIDxiZW5Abm9zdHJ1bS5jb20+DQpDYzogRElTUEFUQ0ggbGlzdCA8ZGlzcGF0Y2hA aWV0Zi5vcmc+OyBTSVBDT1JFIDxzaXBjb3JlQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtzaXBj b3JlXSBbZGlzcGF0Y2hdIERyYWZ0IG5ldzogZHJhZnQtaG9sbWJlcmctZGlzcGF0Y2gtcGFuaS1h Ym5mLTAwIFt3YXM6IFtUZWNobmljYWwgRXJyYXRhIFJlcG9ydGVkXSBSRkM3MzE1ICg0NDc0KV0N Cg0KSGkgSmVhbiwNCg0KVGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzISBJIHdpbGwgdXBkYXRlIHRo ZSBkcmFmdCBhY2NvcmRpbmcgdG8geW91ciBzdWdnZXN0aW9ucy4NCg0KUmVnYXJkcywNCg0KQ2hy aXN0ZXINCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEEuIEplYW4gTWFob25l eSBbbWFpbHRvOm1haG9uZXlAbm9zdHJ1bS5jb21dDQpTZW50OiAyNyBPY3RvYmVyIDIwMTUgMjM6 NDYNClRvOiBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29t PjsgQmVuIENhbXBiZWxsIDxiZW5Abm9zdHJ1bS5jb20+DQpDYzogRElTUEFUQ0ggbGlzdCA8ZGlz cGF0Y2hAaWV0Zi5vcmc+OyBTSVBDT1JFIDxzaXBjb3JlQGlldGYub3JnPg0KU3ViamVjdDogUmU6 IFtkaXNwYXRjaF0gRHJhZnQgbmV3OiBkcmFmdC1ob2xtYmVyZy1kaXNwYXRjaC1wYW5pLWFibmYt MDAgW3dhczogW3NpcGNvcmVdIFtUZWNobmljYWwgRXJyYXRhIFJlcG9ydGVkXSBSRkM3MzE1ICg0 NDc0KV0NCg0KSGkgQ2hyaXN0ZXIsDQoNClRoZSBkcmFmdCBsb29rcyBnb29kIHRvIG1lLiBKdXN0 IGEgZmV3IG5pdHM6DQoNCjEuIEludHJvZHVjdGlvbg0KDQoybmQgcGFyYWdyYXBoOiAicmVxdWly ZXMgbmV3IHZhbHVlcyBhcmUgcmVxdWlyZWQiID0+ICJyZXF1aXJlcyBuZXcgdmFsdWVzIi4NCg0K NHRoIHBhcmFncmFwaDogImhhdmUgYmVlbiBmb2xsb3dlZCIgPT4gImhhdmUgYmVlbiBkZWZpbmVk Ig0KDQpZb3UgbWF5IGFsc28gY29uc2lkZXIgYWRkaW5nIGEgcmVmZXJlbmNlIHRvIFRTIDI0LjIy OSwgd2hpY2ggZGVmaW5lcyB2YWx1ZXMgZm9yIGFjY2Vzcy1pbmZvLCB0byB0aGUgNHRoIHBhcmFn cmFwaC4NCg0KVGhhbmtzIQ0KDQpKZWFuDQoNCg0KT24gMTAvMTgvMTUgMjoxMCBQTSwgQ2hyaXN0 ZXIgSG9sbWJlcmcgd3JvdGU6DQo+IEhpLA0KPg0KPiBJJ3ZlIHN1Ym1pdHRlZCBhIG5ldyB2ZXJz aW9uLCAtMDEsIHdoZXJlIHRoZSBjYXRlZ29yeSBpcyBjaGFuZ2VkIHRvICdJbmZvcm1hdGlvbmFs Jy4NCj4NCj4gUmVnYXJkcywNCj4NCj4gQ2hyaXN0ZXINCj4NCj4gLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCj4gRnJvbTogZGlzcGF0Y2ggW21haWx0bzpkaXNwYXRjaC1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYgT2YgDQo+IENocmlzdGVyIEhvbG1iZXJnDQo+IFNlbnQ6IDE4IE9jdG9i ZXIgMjAxNSAyMTo1OQ0KPiBUbzogQmVuIENhbXBiZWxsIDxiZW5Abm9zdHJ1bS5jb20+DQo+IENj OiBESVNQQVRDSCBsaXN0IDxkaXNwYXRjaEBpZXRmLm9yZz47IFNJUENPUkUgPHNpcGNvcmVAaWV0 Zi5vcmc+DQo+IFN1YmplY3Q6IFJlOiBbZGlzcGF0Y2hdIERyYWZ0IG5ldzogDQo+IGRyYWZ0LWhv bG1iZXJnLWRpc3BhdGNoLXBhbmktYWJuZi0wMCBbd2FzOiBbc2lwY29yZV0gW1RlY2huaWNhbCBF cnJhdGEgDQo+IFJlcG9ydGVkXSBSRkM3MzE1ICg0NDc0KV0NCj4NCj4gSGksDQo+DQo+PiBJZiA3 MzE1IGlzIGluZm9ybWF0aW9uYWwsIHdoeSBkb2VzIHRoZSB1cGRhdGUgbmVlZCB0byBiZSBzdGFu ZGFyZHMgdHJhY2s/DQo+DQo+IEdvb2QgcG9pbnQgLSBJIGd1ZXNzIGl0IGRvZXNuJ3QgaGF2ZSB0 byA6KQ0KPg0KPiBSZWdhcmRzLA0KPg0KPiBDaHJpc3Rlcg0KPg0KPg0KPiBPbiAxOCBPY3QgMjAx NSwgYXQgNjo0OSwgQ2hyaXN0ZXIgSG9sbWJlcmcgd3JvdGU6DQo+DQo+PiBIaSwNCj4+DQo+PiBC YXNlZCBvbiBCZW7igJlzIGd1aWRhbmNlLCBJ4oCZdmUgc3VibWl0dGVkIGEgZHJhZnQgd2hpY2gg bWFrZXMgdGhlIEFCTkYgDQo+PiB1cGRhdGUuDQo+Pg0KPj4gTk9URTogQXMgUkZDIDczMTUgaXMg YW4gSW5mb3JtYXRpb25hbCBSRkMsIEkgaGFkIHRvIGFkZCB0aGUgUkZDIGFzIGFuIA0KPj4gSW5m b3JtYXRpdmUgcmVmZXJlbmNlIGluIHRoZSBkcmFmdCwgaW4gb3JkZXIgdG8gcGFzcyB0aGUgSWRu aXRzIGNoZWNrLg0KPj4NCj4+DQo+PiBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtaG9sbWJl cmctZGlzcGF0Y2gtcGFuaS1hYm5mLTAwLnR4dA0KPj4NCj4+IGhhcyBiZWVuIHN1Y2Nlc3NmdWxs eSBzdWJtaXR0ZWQgYnkgQ2hyaXN0ZXIgSG9sbWJlcmcgYW5kIHBvc3RlZCB0byANCj4+IHRoZSBJ RVRGIHJlcG9zaXRvcnkuDQo+Pg0KPj4NCj4+DQo+PiBOYW1lOiAgICAgICAgICAgICAgICAgZHJh ZnQtaG9sbWJlcmctZGlzcGF0Y2gtcGFuaS1hYm5mDQo+Pg0KPj4gUmV2aXNpb246ICAgICAgICAg ICAgMDANCj4+DQo+PiBUaXRsZTogICAgICAgICAgICAgICAgICAgIFAtQWNjZXNzLU5ldHdvcmst SW5mbyBBQk5GIFVwZGF0ZQ0KPj4NCj4+IERvY3VtZW50IGRhdGU6ICAgICAgICAgICAgICAyMDE1 LTEwLTE4DQo+Pg0KPj4gR3JvdXA6ICAgICAgICAgICAgICAgIEluZGl2aWR1YWwgU3VibWlzc2lv bg0KPj4NCj4+IFBhZ2VzOiAgICAgICAgICAgICAgICAgNA0KPj4NCj4+IFVSTDoNCj4+IGh0dHBz Oi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1ob2xtYmVyZy1kaXNwYXRjaC1w YW5pLWFibg0KPj4gZg0KPj4gLTAwLnR4dA0KPj4NCj4+IFN0YXR1czoNCj4+IGh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWhvbG1iZXJnLWRpc3BhdGNoLXBhbmktYWJuZi8N Cj4+DQo+PiBIdG1saXplZDoNCj4+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1o b2xtYmVyZy1kaXNwYXRjaC1wYW5pLWFibmYtMDANCj4+DQo+Pg0KPj4NCj4+DQo+Pg0KPj4gQWJz dHJhY3Q6DQo+Pg0KPj4gVGhpcyBkb2N1bWVudCB1cGRhdGVzIFJGQyA3MzE1LCBieSBtb2RpZnlp bmcgdGhlIGV4dGVuc2lvbi1hY2Nlc3MtDQo+Pg0KPj4gaW5mbyBwYXJ0IG9mIHRoZSBQLUFjY2Vz cy1OZXR3b3JrLUluZm8gaGVhZGVyIGZpZWxkIEF1Z21lbnRlZCBCYWNrdXMtDQo+Pg0KPj4gTmF1 ciBGb3JtIChBQk5GKS4NCj4+DQo+Pg0KPj4gUmVnYXJkcywNCj4+DQo+PiBDaHJpc3Rlcg0KPj4N Cj4+DQo+Pg0KPj4NCj4+IEZyb206IHNpcGNvcmUgW21haWx0bzpzaXBjb3JlLWJvdW5jZXNAaWV0 Zi5vcmddIE9uIEJlaGFsZiBPZiBDaHJpc3RlciANCj4+IEhvbG1iZXJnDQo+PiBTZW50OiAxOCBP Y3RvYmVyIDIwMTUgMTA6NTINCj4+IFRvOiBCZW4gQ2FtcGJlbGwgPGJlbkBub3N0cnVtLmNvbT4N Cj4+IENjOiBESVNQQVRDSCBsaXN0IDxkaXNwYXRjaEBpZXRmLm9yZz47IFNJUENPUkUgPHNpcGNv cmVAaWV0Zi5vcmc+OyANCj4+IEN1bGxlbiBKZW5uaW5ncyA8Zmx1ZmZ5QGlpaS5jYT4NCj4+IFN1 YmplY3Q6IFJlOiBbc2lwY29yZV0gW2Rpc3BhdGNoXSBbVGVjaG5pY2FsIEVycmF0YSBSZXBvcnRl ZF0gUkZDNzMxNQ0KPj4gKDQ0NzQpDQo+Pg0KPj4gSGksDQo+Pg0KPj4gU28sIHNoYWxsIEkgYWRk cmVzcyB0aGUgZHJhZnQgdG8gc29tZSBXRywgb3I/DQo+Pg0KPj4gZHJhZnQtaG9sbWJlcmctZGlz cGF0Y2ggPw0KPj4NCj4+IFJlZ2FyZHMsDQo+Pg0KPj4gQ2hyaXN0ZXINCj4+DQo+PiBTZW50IGZy b20gbXkgV2luZG93cyBQaG9uZQ0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4+IEZyb206IEJlbiBDYW1wYmVsbDxtYWlsdG86YmVuQG5vc3RydW0uY29tPg0KPj4gU2VudDog 4oCOMTQv4oCOMTAv4oCOMjAxNSAxNzoyMQ0KPj4gVG86IENocmlzdGVyIEhvbG1iZXJnPG1haWx0 bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+DQo+PiBDYzogQ3VsbGVuIEplbm5pbmdz PG1haWx0bzpmbHVmZnlAaWlpLmNhPjsgRElTUEFUQ0ggDQo+PiBsaXN0PG1haWx0bzpkaXNwYXRj aEBpZXRmLm9yZz47IFNJUENPUkU8bWFpbHRvOnNpcGNvcmVAaWV0Zi5vcmc+DQo+PiBTdWJqZWN0 OiBSZTogW3NpcGNvcmVdIFtkaXNwYXRjaF0gW1RlY2huaWNhbCBFcnJhdGEgUmVwb3J0ZWRdIFJG QzczMTUNCj4+ICg0NDc0KQ0KPj4gT24gOCBPY3QgMjAxNSwgYXQgMjE6MDMsIENocmlzdGVyIEhv bG1iZXJnIHdyb3RlOg0KPj4NCj4+PiBIaSBDdWxsZW4sDQo+Pj4NCj4+PiBTbywgeW91IGFyZSBz dWdnZXN0aW5nIGEgU0lQQ09SRSBkcmFmdCB0aGF0IHVwZGF0ZXMgdGhlIEFCTkY/DQo+Pg0KPj4g VGhpcyBpcyB3aGVyZSB0aGUgY2hhaXJzIHdpbGwgcG9pbnQgb3V0IHRoYXQgc3BlY2lhbC1wdXJw b3NlIA0KPj4gZXh0ZW5zaW9ucyBhcmUgZ2VuZXJhbGx5IG5vdCBpbiBzY29wZSBmb3Igc2lwY29y ZSA6LSkgSWYgc28sIHRoaXMgDQo+PiBtaWdodCBjb3VsZCBhbHNvIGJlIGRvbmUgYXMgQUQgc3Bv bnNvcmVkLg0KPj4NCj4+IEJlbi4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4gZGlzcGF0Y2ggbWFpbGluZyBsaXN0DQo+IGRpc3BhdGNoQGlldGYu b3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGlzcGF0Y2gNCj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gZGlzcGF0 Y2ggbWFpbGluZyBsaXN0DQo+IGRpc3BhdGNoQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vZGlzcGF0Y2gNCj4NCg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCnNpcGNvcmUgbWFpbGluZyBsaXN0DQpzaXBjb3Jl QGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmUN Cg== From nobody Tue Oct 27 15:18:59 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E56A11B29F7; Tue, 27 Oct 2015 15:18:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 Xlhb7UQ8FJaX; Tue, 27 Oct 2015 15:18:55 -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 093201B29D8; Tue, 27 Oct 2015 15:18:54 -0700 (PDT) Received: from mutabilis-2.local (pool-71-164-199-31.dllstx.fios.verizon.net [71.164.199.31]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t9RMIok4088109 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 27 Oct 2015 17:18:51 -0500 (CDT) (envelope-from mahoney@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-71-164-199-31.dllstx.fios.verizon.net [71.164.199.31] claimed to be mutabilis-2.local To: Christer Holmberg , Ben Campbell References: <7594FB04B1934943A5C02806D1A2204B37B62FC0@ESESSMB209.ericsson.se> <90429FC5-4199-4386-8CEE-F7F9E45420CE@nostrum.com> <7594FB04B1934943A5C02806D1A2204B37B6907F@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37B691E1@ESESSMB209.ericsson.se> <562FF092.3090605@nostrum.com> <7594FB04B1934943A5C02806D1A2204B37B94F9B@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37B9501A@ESESSMB209.ericsson.se> From: "A. Jean Mahoney" Message-ID: <562FF845.4000404@nostrum.com> Date: Tue, 27 Oct 2015 17:18:45 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37B9501A@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: DISPATCH list , SIPCORE Subject: Re: [dispatch] [sipcore] Draft new: draft-holmberg-dispatch-pani-abnf-00 [was: [Technical Errata Reported] RFC7315 (4474)] X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2015 22:18:57 -0000 Thanks for the quick update! Looks good. Jean On 10/27/15 5:15 PM, Christer Holmberg wrote: > Hi, > > The new version can be seen at: https://github.com/cdh4u/draft-pani-abnf > > I'll submit it when the submission window opens. > > Regards, > > Christer > > -----Original Message----- > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg > Sent: 28 October 2015 00:03 > To: A. Jean Mahoney ; Ben Campbell > Cc: DISPATCH list ; SIPCORE > Subject: Re: [sipcore] [dispatch] Draft new: draft-holmberg-dispatch-pani-abnf-00 [was: [Technical Errata Reported] RFC7315 (4474)] > > Hi Jean, > > Thanks for your comments! I will update the draft according to your suggestions. > > Regards, > > Christer > > -----Original Message----- > From: A. Jean Mahoney [mailto:mahoney@nostrum.com] > Sent: 27 October 2015 23:46 > To: Christer Holmberg ; Ben Campbell > Cc: DISPATCH list ; SIPCORE > Subject: Re: [dispatch] Draft new: draft-holmberg-dispatch-pani-abnf-00 [was: [sipcore] [Technical Errata Reported] RFC7315 (4474)] > > Hi Christer, > > The draft looks good to me. Just a few nits: > > 1. Introduction > > 2nd paragraph: "requires new values are required" => "requires new values". > > 4th paragraph: "have been followed" => "have been defined" > > You may also consider adding a reference to TS 24.229, which defines values for access-info, to the 4th paragraph. > > Thanks! > > Jean > > > On 10/18/15 2:10 PM, Christer Holmberg wrote: >> Hi, >> >> I've submitted a new version, -01, where the category is changed to 'Informational'. >> >> Regards, >> >> Christer >> >> -----Original Message----- >> From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of >> Christer Holmberg >> Sent: 18 October 2015 21:59 >> To: Ben Campbell >> Cc: DISPATCH list ; SIPCORE >> Subject: Re: [dispatch] Draft new: >> draft-holmberg-dispatch-pani-abnf-00 [was: [sipcore] [Technical Errata >> Reported] RFC7315 (4474)] >> >> Hi, >> >>> If 7315 is informational, why does the update need to be standards track? >> >> Good point - I guess it doesn't have to :) >> >> Regards, >> >> Christer >> >> >> On 18 Oct 2015, at 6:49, Christer Holmberg wrote: >> >>> Hi, >>> >>> Based on Ben’s guidance, I’ve submitted a draft which makes the ABNF >>> update. >>> >>> NOTE: As RFC 7315 is an Informational RFC, I had to add the RFC as an >>> Informative reference in the draft, in order to pass the Idnits check. >>> >>> >>> A new version of I-D, draft-holmberg-dispatch-pani-abnf-00.txt >>> >>> has been successfully submitted by Christer Holmberg and posted to >>> the IETF repository. >>> >>> >>> >>> Name: draft-holmberg-dispatch-pani-abnf >>> >>> Revision: 00 >>> >>> Title: P-Access-Network-Info ABNF Update >>> >>> Document date: 2015-10-18 >>> >>> Group: Individual Submission >>> >>> Pages: 4 >>> >>> URL: >>> https://www.ietf.org/internet-drafts/draft-holmberg-dispatch-pani-abn >>> f >>> -00.txt >>> >>> Status: >>> https://datatracker.ietf.org/doc/draft-holmberg-dispatch-pani-abnf/ >>> >>> Htmlized: >>> https://tools.ietf.org/html/draft-holmberg-dispatch-pani-abnf-00 >>> >>> >>> >>> >>> >>> Abstract: >>> >>> This document updates RFC 7315, by modifying the extension-access- >>> >>> info part of the P-Access-Network-Info header field Augmented Backus- >>> >>> Naur Form (ABNF). >>> >>> >>> Regards, >>> >>> Christer >>> >>> >>> >>> >>> From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer >>> Holmberg >>> Sent: 18 October 2015 10:52 >>> To: Ben Campbell >>> Cc: DISPATCH list ; SIPCORE ; >>> Cullen Jennings >>> Subject: Re: [sipcore] [dispatch] [Technical Errata Reported] RFC7315 >>> (4474) >>> >>> Hi, >>> >>> So, shall I address the draft to some WG, or? >>> >>> draft-holmberg-dispatch ? >>> >>> Regards, >>> >>> Christer >>> >>> Sent from my Windows Phone >>> ________________________________ >>> From: Ben Campbell >>> Sent: ‎14/‎10/‎2015 17:21 >>> To: Christer Holmberg >>> Cc: Cullen Jennings; DISPATCH >>> list; SIPCORE >>> Subject: Re: [sipcore] [dispatch] [Technical Errata Reported] RFC7315 >>> (4474) >>> On 8 Oct 2015, at 21:03, Christer Holmberg wrote: >>> >>>> Hi Cullen, >>>> >>>> So, you are suggesting a SIPCORE draft that updates the ABNF? >>> >>> This is where the chairs will point out that special-purpose >>> extensions are generally not in scope for sipcore :-) If so, this >>> might could also be done as AD sponsored. >>> >>> Ben. >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From nobody Fri Oct 30 23:07:06 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 369E51B3491 for ; Fri, 30 Oct 2015 23:07:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 3a0-P94Qb6cX for ; Fri, 30 Oct 2015 23:07:03 -0700 (PDT) Received: from smtp64.ord1c.emailsrvr.com (smtp64.ord1c.emailsrvr.com [108.166.43.64]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C87D81B3490 for ; Fri, 30 Oct 2015 23:07:03 -0700 (PDT) Received: from smtp1.relay.ord1c.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp1.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 086BE380148 for ; Sat, 31 Oct 2015 02:07:03 -0400 (EDT) Received: by smtp1.relay.ord1c.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id A97B53800F4 for ; Sat, 31 Oct 2015 02:07:02 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [133.93.85.42] ([UNAVAILABLE]. [133.93.85.42]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:587 (trex/5.5.4); Sat, 31 Oct 2015 02:07:03 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Cullen Jennings In-Reply-To: <55E89DF9.9080707@nostrum.com> Date: Sat, 31 Oct 2015 12:30:06 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: <55E8845B.10457.14E9DDA9@fas_vm.surguttel.ru> <55E88E2B.7030006@alum.mit.edu> <55E89DF9.9080707@nostrum.com> To: DISPATCH list X-Mailer: Apple Mail (2.2104) Archived-At: Subject: Re: [dispatch] (Fwd) New Version Notification for draft-tveretin-dispatch-remote-01.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Oct 2015 06:07:05 -0000 You might want to have look at=20 draft-mahy-sip-remote-cc and=20 draft-mahy-mmusic-mbus-remotecc and the reasons the IETF decided not to publish them.=20 > On Sep 4, 2015, at 4:22 AM, Adam Roach wrote: >=20 > On 9/3/15 13:15, Paul Kyzivat wrote: >> On 9/3/15 1:33 PM, Anton Tveretin wrote: >>> Dear All, >>> I want to discuss new ideas. This is a new version of my draft. I = will insist on it. >>=20 >> Insist on what? >>=20 >>> I'm sure this is >>> not the final version - references need to check. I don't know if I = need comparison with RFC >>> 3891, or should I remove any reference to it. Some text is commented = out of XML. >>=20 >> I would expect to see *much* more in the Security Considerations = section. This functionality could be used to do lots of bad things. = There should be a discussion of the threats and how they can be = mitigated. >=20 > The thing is, we've already gone through this exercise, including the = security analysis to make sure it's safe to deploy. The comparison here = isn't against just RFC 3891; it's against the entire call-control = framework that we invested thousands of engineering hours in developing = and publishing. Reading and really understanding the philosophy of = RFC5850 will go a long way towards explaining how this kind of call = control needs to work. >=20 > In my opinion, the bullet list in section 1 of RFC5850 is some of the = most important text ever written on the topic of SIP. >=20 > /a >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From nobody Fri Oct 30 23:07:09 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14E4D1B3492 for ; Fri, 30 Oct 2015 23:07:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 wl0NYgKHz9LH for ; Fri, 30 Oct 2015 23:07:05 -0700 (PDT) Received: from smtp64.ord1c.emailsrvr.com (smtp64.ord1c.emailsrvr.com [108.166.43.64]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D74201B3490 for ; Fri, 30 Oct 2015 23:07:05 -0700 (PDT) Received: from smtp1.relay.ord1c.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp1.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 67EDF380148; Sat, 31 Oct 2015 02:07:05 -0400 (EDT) Received: by smtp1.relay.ord1c.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id DF77F3800F4; Sat, 31 Oct 2015 02:07:04 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [133.93.85.42] ([UNAVAILABLE]. [133.93.85.42]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:587 (trex/5.5.4); Sat, 31 Oct 2015 02:07:05 -0400 From: Cullen Jennings Content-Type: multipart/alternative; boundary="Apple-Mail=_9F8AC0F9-E49F-4CB2-ACA5-FBB95908EA8D" Date: Sat, 31 Oct 2015 15:03:20 +0900 Message-Id: <9FB3696B-90A0-40C2-BA62-9E18546879DC@iii.ca> To: DISPATCH list Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) Archived-At: Subject: [dispatch] WGLC draft-holmberg-dispatch-pani-abnf-01 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Oct 2015 06:07:07 -0000 --Apple-Mail=_9F8AC0F9-E49F-4CB2-ACA5-FBB95908EA8D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii After discussion with various chairs, Ads etc, Ben has decided to AD = sponsor the draft-holmberg-dispatch-pani-abnf draft. To help collect = input for Ben, we are going to run a 2 week working group last call on = this draft. Please send any comments to the dispatch list before the end = of Nov 16.=20 The draft is currently in https://github.com/cdh4u/draft-pani-abnf = and will be in the official = repository on Monday which will be the start of the WGLC period.=20 Thanks,=20 Mary & Cullen --Apple-Mail=_9F8AC0F9-E49F-4CB2-ACA5-FBB95908EA8D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
After discussion with various chairs, Ads = etc, Ben has decided to AD sponsor the = draft-holmberg-dispatch-pani-abnf draft. To help collect input for = Ben, we are going to run a 2 week working group last call on this draft. = Please send any comments to the dispatch list before the end of Nov = 16. 

The = draft is currently in https://github.com/cdh4u/draft-pani-abnf and will be = in the official repository on Monday which will be the start of the WGLC = period. 

Thanks, 

Mary & Cullen




= --Apple-Mail=_9F8AC0F9-E49F-4CB2-ACA5-FBB95908EA8D--