From nobody Thu Dec 1 06:08:09 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1117A1294EC for ; Thu, 1 Dec 2016 06:08:08 -0800 (PST) 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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CaiJAuOPmvJc for ; Thu, 1 Dec 2016 06:08:06 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 556631294C6 for ; Thu, 1 Dec 2016 06:08:06 -0800 (PST) Received: (qmail 2575 invoked from network); 1 Dec 2016 14:08:08 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 1 Dec 2016 14:08:08 -0000 Date: 1 Dec 2016 14:07:43 -0000 Message-ID: <20161201140743.28859.qmail@ary.lan> From: "John Levine" To: dispatch@ietf.org In-Reply-To: <724a13e5-e422-b55c-2b36-ba3e63620e48@rolandturner.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dispatch] draft-levine-herkula-oneclick, additional security consideration X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2016 14:08:08 -0000 >unsubscribe button (in the dialogue box that could pop up if the user >clicked This is Spam), they established three criteria: > > * that a List-Unsubscribe: header was present > * that the message authenticated, and > * that the sender was in good standing in terms of its complaint rate. > >It may be argued, with some strength, that the third item really makes >no difference, but it would appear to be a relevant consideration to >address in Security Considerations, and perhaps an option to suggest. That's a policy issue. Some mailers care, some don't. R's, John From nobody Fri Dec 9 11:18:29 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6627C1295F0 for ; Fri, 9 Dec 2016 11:18:28 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fccoffice.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ft_0zRFloXEg for ; Fri, 9 Dec 2016 11:18:25 -0800 (PST) Received: from mx0b-0024ed01.pphosted.com (mx0b-0024ed01.pphosted.com [148.163.153.198]) (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 DEC12129515 for ; Fri, 9 Dec 2016 11:18:24 -0800 (PST) Received: from pps.filterd (m0102175.ppops.net [127.0.0.1]) by mx0b-0024ed01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id uB9JF5cW011745; Fri, 9 Dec 2016 19:18:23 GMT Received: from gcc01-cy1-obe.outbound.protection.outlook.com (mail-cy1gcc01lp0015.outbound.protection.outlook.com [23.103.198.15]) by mx0b-0024ed01.pphosted.com with ESMTP id 277gt6gfb6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 09 Dec 2016 19:18:23 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fccoffice.onmicrosoft.com; s=selector1-fcc-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ugx8peLoJTfB4HCPBhqanIrJ6PcFH5S0z+D9NbFXbJI=; b=JZAwXAShUkjf52u99x3o+50cnatguljDCPljq1aK952mG7kmaX6VSa6QLfJadT77cCtSsKdSCati2DnWGVIGMri8U+1tCrPMxz1Pm1uVH53vMDFYxHqS2tyf2e2w1zKpJ677JVX2wI4EopCwnxgAEzXyk8thcLthulKss67rn7g= Received: from CY1PR09MB0634.namprd09.prod.outlook.com (10.160.151.21) by CY1PR09MB0635.namprd09.prod.outlook.com (10.160.151.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.771.8; Fri, 9 Dec 2016 19:18:22 +0000 Received: from CY1PR09MB0634.namprd09.prod.outlook.com ([10.160.151.21]) by CY1PR09MB0634.namprd09.prod.outlook.com ([10.160.151.21]) with mapi id 15.01.0771.011; Fri, 9 Dec 2016 19:18:21 +0000 From: Henning Schulzrinne To: "Drage, Keith (Nokia - GB)" , DISPATCH Thread-Topic: Comments on draft-schulzrinne-dispatch-callinfo-spam-00 Thread-Index: AdIi6EsgJRc68dIMSDq6ikujmk9hPAQ34fbM Date: Fri, 9 Dec 2016 19:18:21 +0000 Message-ID: References: <949EF20990823C4C85C18D59AA11AD8BADF8BC74@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8BADF8BC74@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.104.54.21] x-ms-office365-filtering-correlation-id: 704ea191-661a-45d3-59fe-08d420682408 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CY1PR09MB0635; x-microsoft-exchange-diagnostics: 1; CY1PR09MB0635; 7:kZd3+E60ufTS9np+zBv+0cHfE7MJAfP8BrGYkV6nGIUNGjmo+tSkuPjLIPRplfDQTbvIdEhGnFm7b6ItG1/Pg6PkGJMhoZ94UMXMd7Ko2721e0LKfZap24/g8LsDhBWCD8rgQ0jPJ2ojijA69mJz5INIvXG5BPnRAjEtocPkwc0/CIu4mzRC0J9EOKVR3cuxS6tct3+kYMkeHVU+v/U+6v9mAs9Fb2SPTpLNNNXRRKCrIEfoU8B4ldBcZNOOTdSQK68MOMWzXxjfKHAWE6DDDRwecK/GAuV4KvIpsWwDOXJ2gmK2V0g7oWbvjuFi5RO6o5l5PNYM11nVr1K+714XSDAoCIfVkw+BpFvaNVsSXbHlxNkEcDtQG9IlYXg6m2Uu2xMdTPCS8BNpXdlxZp2FpJuV0AvUzGqHtsOMvz4UsAssaFD+jRvZ3QN9lmYoh4wE3zYpNqfVgVOrNqZK7/7dMQ== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705)(82608151540597)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041248)(20161123560025)(20161123555025)(20161123562025)(20161123564025)(6072148); SRVR:CY1PR09MB0635; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0635; x-forefront-prvs: 015114592F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39850400002)(39450400003)(39840400002)(39410400002)(189002)(199003)(377454003)(3660700001)(6116002)(102836003)(3846002)(7906003)(66066001)(790700001)(7736002)(74316002)(2906002)(5660300001)(54356999)(6436002)(3280700002)(606005)(50986999)(76176999)(19609705001)(77096006)(92566002)(99286002)(229853002)(6506006)(105586002)(7696004)(38730400001)(33656002)(86362001)(189998001)(2950100002)(101416001)(9686002)(2900100001)(76576001)(68736007)(81156014)(106356001)(107886002)(345774005)(230783001)(8676002)(5001770100001)(122556002)(81166006)(97736004)(8936002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0635; H:CY1PR09MB0634.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: fcc.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR09MB0634EB6E5859E526F1551949EA870CY1PR09MB0634namp_" MIME-Version: 1.0 X-OriginatorOrg: fcc.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Dec 2016 19:18:21.8166 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72970aed-3669-4ca8-b960-dd016bc72973 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0635 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-12-09_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609300000 definitions=main-1612090265 Archived-At: Subject: Re: [dispatch] Comments on draft-schulzrinne-dispatch-callinfo-spam-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 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 Dec 2016 19:18:28 -0000 --_000_CY1PR09MB0634EB6E5859E526F1551949EA870CY1PR09MB0634namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Keith, Thank you for your extensive comments. I'm creating -01, with comments inli= ne. ________________________________ From: dispatch on behalf of Drage, Keith (Nokia= - GB) Sent: Monday, October 10, 2016 10:38 AM Subject: [dispatch] Comments on draft-schulzrinne-dispatch-callinfo-spam-00 1) Section 1, 1st paragraph, uses the term "illegal telemarketing" but= the abstract just says "telemarketing". I assume both legal and illegal te= lemarketing would fall in scope. >> Noted. 2) Section 1, and section 3. I think any use of the term "emergency" n= eeds to distance itself from any emergency call in for example "112" or "91= 1" usage. I would not expect this capability to be used on such emergency c= alls, if there is additional data to be provided on such calls, then we hav= e a defined way of doing that. >> -01 will clarify that this is related to alerts and warnings, not 911/11= 2. The term "reverse 911" is sometimes used, but it is a trademark for a sp= ecific product. 3) Section 1: Text "The Call-Info header field MAY be signed using a future "ppt" extension to [I-D.ietf-stir-rfc4474bis]. To ensure that an untrusted originating caller does not mislead the called party, a new feature tag, sip.call-info.spam, indicates whether the terminating carrier will remove untrusted information." I don't know whether it is intended to define this in the timeframe of this= i-d. If yes, then I assume it will be replaced by a normative reference la= ter in the document. If no, I suggest it is removed, as we should not reall= y hint that future work plan that may or may not exist. >> This is a question to the STIR crowd on my part: Is any extension work n= eeded or can the signing already be done? From what I can tell, stir-passpo= rt-extensions. My suggestion would be to do this as a separate draft once 4= 474bis has shipped. 4) Section 1: I would suggest avoing the use of normative language in = section 1, which is labelled introduction, particularly as in this case it = comes before section 2 which contains the RFC 2119 language. These requirem= ents need to appear later in the document. >> I have moved the operational material from the introduction into a new s= ection. 5) Section 1: " SIP entities MUST add a new Call-Info header field, rather than add parameters to an existing one. There MAY be several Call-Info header fields in one request." It is not clear to me whether multiple generators of Call-Info header field= parameters in accordance with this draft along the call path would create = multiple Call-Info header fields, or would be permitted to combine them int= o one Call-Info header field. Given that there is no indication of which en= tity generated the data, it probably does not matter that they have to be s= eparate Call-Info header fields, only that they are distinct from other Cal= l-Info header field usages. >> My text is unclear. What I meant was that the entity 'b' should do somet= hing like (assuming the first line was already there) Call-Info: ;purpose=3Dinfo; spam=3D0.95; source=3D"a.example.com", Call-Info: ;purpose=3Dinfo; type=3D"fraud"; source=3D"b.example.com" Rather than Call-Info: ;purpose=3Dinfo; spam=3D0.95; source=3D"a.example.com"; ty= pe=3D"fraud"; source=3D"b.example.com" (leaving aside whether you could even do that in this case, given the param= eter duplication). I will try to amplify, but please take a look to see if I succeeded. 6) Section 3: Values with parameters and types. There are hints that c= ertain parameters carry values, eg. "spam" with a percentage, but no indica= tion of how the syntax of this works. >> I have added an ABNF section. 7) Section 3: There are other parameters and types that could well car= ry values, such as "business" which could be followed by a company name of = business registration number. Obviously that may sometimes apppear in the F= rom or Calling Party ID, but there may be instances where more specific and= different information would be inserted there. >> To keep complexity low and avoid non-standard syntax (type=3Dbusiness=3D= "EIN"), I would suggest adding a suitable field if that should be desired. = There are several plausible ones; for example, in the US, you could have a = local state license number, e.g., for contractors, or the FEIN (Federal Emp= loyer Identification Number, the "social security" number for businesses) o= r, for banks, the mortgage lender number. Or it could be the DUNS (Dun & Br= adstreet number, assigned to just about any entity). Thus, since you can't = easily tell by looking at the number what kind of identifier this is, it se= ems to make more sense to define them as parameters. However, I suspect tha= t a better option is to use the extended CNAM model, i.e., a vCard referenc= e. 8) Section 3. "spam" appears both as a parameter in its own right, an= d as a "type" Under what conditions do you expect one versus the other to b= e used? >> Good question. Sometimes, the inserting entity will have only spam-likel= ihood information, sometimes only type information, sometimes both. For exa= mple, a charity or political may still be considered unwanted, with a non-z= ero spam rating, based on crowd sourced information. This allows some diffe= rentiation - I may decide to accept a charity call even though it has a non= -zero spam rating. I have added a bit of text. 9) Section 5: For types, Section 3 states "Additional labels are regis= tered with IANA." However there seems to be no registration of the values d= efined under types. >> I have added an IANA registration section. 10) Section 6. The mechanism defined in the security considerations doe= s not cater for spoofing by MITM attackers between the registrar and the UA= . Additional security that uses the same security tunnel for both the REGIS= TER and the subsequent messages would be needed for that. >> I'm not sure I fully understand this comment. Are you saying that SIP-ov= er-TLS would be needed to prevent a MITM to insert bogus information? Would= n't this be the same problem as for (say) verstat or indeed any of the othe= r REGISTER feature capabilities, at least the ones that may have security-r= elevant properties? For now, I'll add a note about possible MITM attacks an= d elaborate as I better understand the concern and possible specific soluti= ons. Keith >> Henning _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch --_000_CY1PR09MB0634EB6E5859E526F1551949EA870CY1PR09MB0634namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Keith,

 

Thank you for your extensive comments. I’m creatin= g -01, with comments inline.

 

 

From: dispat= ch <dispatch-bounces@ietf.org> on behalf of Drage, Keith (Nokia - GB) <keith.drage@nokia.com>
Sent: Monday, October 10, 2016 10:38 AM
Subject: [dispatch] Comments on draft-schulzrinne-dispatch-callinfo-= spam-00

 

1)      Sectio= n 1, 1st paragraph, uses the term "illegal telemarketing" but the= abstract just says "telemarketing". I assume both legal and ille= gal telemarketing would fall in scope.

 

>> Noted.

 

2)      Sectio= n 1, and section 3. I think any use of the term "emergency" needs= to distance itself from any emergency call in for example "112" = or "911" usage. I would not expect this capability to be used on such emergency calls, if = there is additional data to be provided on such calls, then we have a defin= ed way of doing that.


>> -01 will clarify that this is related to alerts and warn= ings, not 911/112. The term "reverse 911" is sometimes used, but = it is a trademark for a specific product.

3)      Sectio= n 1: Text "The Call-Info header field MAY be signed<= /p>

   using a future "ppt&q= uot; extension to [I-D.ietf-stir-rfc4474bis].  To

   ensure that an untrusted o= riginating caller does not mislead the

   called party, a new featur= e tag, sip.call-info.spam, indicates

   whether the terminating ca= rrier will remove untrusted information."

 

I don't know whether it is intended to = define this in the timeframe of this i-d. If yes, then I assume it will be = replaced by a normative reference later in the document. If no, I suggest it is removed, as we should not really hint tha= t future work plan that may or may not exist.

 

>> This is a question to t= he STIR crowd on my part: Is any extension work needed or can the signing already be done? From what I can tell, stir-passport-extensions. M= y suggestion would be to do this as a separate draft once 4474bis has shipp= ed.

 


4)      Section 1: I would suggest avoing the use = of normative language in section 1, which is labelled introduction, particu= larly as in this case it comes before section 2 which contains the RFC 2119= language. These requirements need to appear later in the document.

>> I have moved the operational material from th= e introduction into a new section.



5)      Section 1:

"   SIP entities MUST add a new Call-Info header field, rath= er than add
   parameters to an existing one.  There MAY be several Call= -Info header
   fields in one request."

It is not clear to me whether multiple generators of Call-Info header field= parameters in accordance with this draft along the call path would create = multiple Call-Info header fields, or would be permitted to combine them int= o one Call-Info header field. Given that there is no indication of which entity generated the data, it probabl= y does not matter that they have to be separate Call-Info header fields, on= ly that they are distinct from other Call-Info header field usages.

>> My text is unclear. What I meant was that the= entity ‘b’ should do something like (assuming the first line w= as already there)

Call-Info: <url> ;purpose=3Dinfo; spam=3D0.95; s= ource=3D”a.example.com”,
Call-Info: <url> ;purpose=3Dinfo; type=3D”fraud”; source= =3D”b.example.com”

Rather than

Call-Info: <url> ;purpose=3Dinfo; spam=3D0.95; s= ource=3D”a.example.com”; type=3D”fraud”; source=3D&= #8221;b.example.com”

(leaving aside whether you could even do that in this = case, given the parameter duplication).

I will try to amplify, but please take a look to see i= f I succeeded.


6)      Section 3: Values with parameters and type= s. There are hints that certain parameters carry values, eg. "spam&quo= t; with a percentage, but no indication of how the syntax of this works.

>> I have added a= n ABNF section.


7)      Section 3: There are other parameters and = types that could well carry values, such as "business" which coul= d be followed by a company name of business registration number. Obviously = that may sometimes apppear in the From or Calling Party ID, but there may be instances where more specific and different information would be in= serted there.

>> To keep comple= xity low and avoid non-standard syntax (type=3Dbusiness=3D”EIN”= ), I would suggest adding a suitable field if that should be desired. There are several plausible ones; for example, in the US, you could have a= local state license number, e.g., for contractors, or the FEIN (Federal Em= ployer Identification Number, the “social security” number for = businesses) or, for banks, the mortgage lender number. Or it could be the DUNS (Dun & Bradstreet number, assigned to = just about any entity). Thus, since you can’t easily tell by looking = at the number what kind of identifier this is, it seems to make more sense = to define them as parameters. However, I suspect that a better option is to use the extended CNAM model, i.e., a vCard refe= rence.


8)       Section 3. "spam" appears = both as a parameter in its own right, and as a "type" Under what = conditions do you expect one versus the other to be used?

>> Good question. Sometimes, the inserting entit= y will have only spam-likelihood information, sometimes only type informati= on, sometimes both. For example, a charity or political may still be considered unwanted, with a non-zero spam rating, based on cr= owd sourced information. This allows some differentiation – I may dec= ide to accept a charity call even though it has a non-zero spam rating. I h= ave added a bit of text.

 


9)      Section 5: For types, Section 3 states &qu= ot;Additional labels are registered with IANA." However there seems to= be no registration of the values defined under types.

>> I have added a= n IANA registration section.


10)     Section 6. The mechanism defined in the securit= y considerations does not cater for spoofing by MITM attackers between the = registrar and the UA. Additional security that uses the same security tunne= l for both the REGISTER and the subsequent messages would be needed for that.

>> I’m not sure I fully understand this co= mment. Are you saying that SIP-over-TLS would be needed to prevent a MITM t= o insert bogus information? Wouldn’t this be the same problem as for (say) verstat or indeed any of the other REGISTER feature capabilit= ies, at least the ones that may have security-relevant properties? For now,= I’ll add a note about possible MITM attacks and elaborate as I bette= r understand the concern and possible specific solutions.


Keith

>> Henning

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

--_000_CY1PR09MB0634EB6E5859E526F1551949EA870CY1PR09MB0634namp_-- From nobody Sat Dec 10 23:55:13 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B63B12959F for ; Sat, 10 Dec 2016 23:55:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.687 X-Spam-Level: X-Spam-Status: No, score=-4.687 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=rolandturner.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yMND04_S-wRj for ; Sat, 10 Dec 2016 23:55:11 -0800 (PST) Received: from sg.rolandturner.com (sg.rolandturner.com [175.41.138.242]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7D03129500 for ; Sat, 10 Dec 2016 23:55:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=rolandturner.com; s=0.rolandturner.com; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject; bh=HBFd9y0493/Rv+ZE4sGHbztIKylPaVkxLBy5m+HdjBM=; b=rLNf3CsvzztiYzr4aIJl1Ve3ftequYdpHFAeLCnG5RaeXdjMXSDnJ+OS7SqCx74w63McGaRk0hTJnWLPuz0TrZER7BDyGRFS/Rk33sxLZFqgrOjhgkSfio5Y/f9Y38epoPBGX4m7VWrz0dAgtVoQNdrj4G7qpi3h+SgMLIB5fGo=; Received: from [202.156.169.29] (port=42326 helo=[10.179.69.102]) by sg.rolandturner.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from ) id 1cFyyS-0006MK-VC for dispatch@ietf.org; Sun, 11 Dec 2016 07:55:08 +0000 To: dispatch@ietf.org References: <20161201140743.28859.qmail@ary.lan> From: Roland Turner Message-ID: Date: Sun, 11 Dec 2016 15:55:08 +0800 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <20161201140743.28859.qmail@ary.lan> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dispatch] draft-levine-herkula-oneclick, additional security consideration X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Dec 2016 07:55:12 -0000 On 12/01/2016 10:07 PM, John Levine wrote: >> unsubscribe button (in the dialogue box that could pop up if the user >> clicked This is Spam), they established three criteria: >> >> * that a List-Unsubscribe: header was present >> * that the message authenticated, and >> * that the sender was in good standing in terms of its complaint rate. >> >> It may be argued, with some strength, that the third item really makes >> no difference, but it would appear to be a relevant consideration to >> address in Security Considerations, and perhaps an option to suggest. > That's a policy issue. Some mailers care, some don't. I agree, that is the nature of security considerations. Are you arguing for not including this concern and potential countermeasure? - Roland From nobody Sun Dec 11 12:34:42 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A83AA129476 for ; Sun, 11 Dec 2016 12:34:41 -0800 (PST) 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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8diYComhTNGz for ; Sun, 11 Dec 2016 12:34:40 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52AF1126BF7 for ; Sun, 11 Dec 2016 12:34:40 -0800 (PST) Received: (qmail 23676 invoked from network); 11 Dec 2016 20:34:41 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 11 Dec 2016 20:34:41 -0000 Date: 11 Dec 2016 20:34:13 -0000 Message-ID: <20161211203413.59975.qmail@ary.lan> From: "John Levine" To: dispatch@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dispatch] draft-levine-herkula-oneclick, additional security consideration X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Dec 2016 20:34:41 -0000 >I agree, that is the nature of security considerations. Are you arguing >for not including this concern and potential countermeasure? Well, actually, I'm saying that the IETF review is over and it's in the RFC editor's hopper, so it's too late. R's, John From nobody Thu Dec 15 19:57:37 2016 Return-Path: X-Original-To: dispatch@ietf.org Delivered-To: dispatch@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 14E8C129480; Thu, 15 Dec 2016 19:57:28 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Joel Halpern To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148186064804.24550.3460112022117949321.idtracker@ietfa.amsl.com> Date: Thu, 15 Dec 2016 19:57:28 -0800 Archived-At: Cc: dispatch@ietf.org, ietf@ietf.org, draft-mohali-dispatch-cause-for-service-number.all@ietf.org Subject: [dispatch] Review of draft-mohali-dispatch-cause-for-service-number-12 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2016 03:57:28 -0000 Reviewer: Joel Halpern Review result: Ready with Issues Major: This document defines a new code for use in SIP, and specifies new behavior both for the code itself and for its use in history-info. I am thus confused as to how this can be an informational RFC. It looks like it either Proposed Standard or experimental. Yes, I see that RFC 4458, which this updates is Informational. But just because we did it wrong before does not make that behavior correct now. In addition to my understanding of the roles of different RFCs, I note that RFC 3969 and the IANA registry both state that this assignment must be made by a standards track RFC. Minor: Given our emphasis on IPv6 over IPv4, would it not make sense for the examples to use IPv6 addresses? (Inspired by the Id-Nits alert.) From nobody Thu Dec 15 20:29:01 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC892129522; Thu, 15 Dec 2016 20:28:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.796 X-Spam-Level: X-Spam-Status: No, score=-4.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UlQMtzjaj_UX; Thu, 15 Dec 2016 20:28:55 -0800 (PST) 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 1910C129458; Thu, 15 Dec 2016 20:28:55 -0800 (PST) Received: from [10.0.1.39] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id uBG4SrRl049861 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 15 Dec 2016 22:28:54 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.39] From: "Ben Campbell" To: "Joel Halpern" Date: Thu, 15 Dec 2016 22:28:53 -0600 Message-ID: <9E288F8F-BD52-49D0-83B2-472F1B223127@nostrum.com> In-Reply-To: <148186064804.24550.3460112022117949321.idtracker@ietfa.amsl.com> References: <148186064804.24550.3460112022117949321.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5310) Archived-At: Cc: gen-art@ietf.org, dispatch@ietf.org, ietf@ietf.org, draft-mohali-dispatch-cause-for-service-number.all@ietf.org Subject: Re: [dispatch] Review of draft-mohali-dispatch-cause-for-service-number-12 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2016 04:28:57 -0000 Hi Joel, Thanks for the comments. There has been a fair amount of discussion about the status of the draft. The situation is clearly not optimal, and I welcome input on how to straighten it out. The rational so far has been that this draft updates RFC 4588, which is informational. It adds some additional values and related semantics for the "cause" parameter from 4588. It does not register new parameters; rather it adds itself as a reference in the existing "cause" registration. This is mainly a courtesy to readers. (There is no sub-registry for "cause" parameter values.) We might could get by without that change, since in a perfect world people following the IANA reference to 4588 would notice the "Updated by..." tag. The gotcha is that RFC 4588 would not be possible as an informational today; it would not have standing to register the "cause" parameter. But at the time it was published, there was a lack of clarity around the "standards action" policy for the SIP URI parameters registry. Making the new values from _this_ draft standards track, when the parameter itself is not, doesn't seem appropriate. We had some discussion about whether we should promote 4588 to PS, but there was not consensus to do so when it was published, and I don't see reason to expect that to have changed. This draft is primarily intended to meet a need in 3GPP, where I understand they are effectively already doing this. Would it help to more tightly scope this as "Here's something 3GPP is doing..." rather than as a general mechanism? Thanks! Ben. On 15 Dec 2016, at 21:57, Joel Halpern wrote: > Reviewer: Joel Halpern > Review result: Ready with Issues > > Major: > This document defines a new code for use in SIP, and specifies new > behavior both for the code itself and for its use in history-info. I > am thus confused as to how this can be an informational RFC. It looks > like it either Proposed Standard or experimental. Yes, I see that RFC > 4458, which this updates is Informational. But just because we did it > wrong before does not make that behavior correct now. In addition to > my understanding of the roles of different RFCs, I note that RFC 3969 > and the IANA registry both state that this assignment must be made by > a standards track RFC. > > Minor: > Given our emphasis on IPv6 over IPv4, would it not make sense for > the examples to use IPv6 addresses? (Inspired by the Id-Nits alert.) From nobody Thu Dec 15 20:35:38 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9957F12953B; Thu, 15 Dec 2016 20:35:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1jpheVUCvDyL; Thu, 15 Dec 2016 20:35:35 -0800 (PST) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 4A274129522; Thu, 15 Dec 2016 20:35:35 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 364312464C8; Thu, 15 Dec 2016 20:35:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1481862935; bh=6vXV2rr/B3UwgrS0xbTS4N2j0NwrC8S+WT4aJ6HSYzM=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=TKyct95vbs8amrnYnJLmYGBk9/W7JcR2CUeqIDPe2Jn0318I2oiO/C+FQQedbY6P/ L4AXHDgJatqCQJMy3BWs1QuwBqXbh70Heg+NIHQ7TXRKJgfoA5q+RS0HPkVexQtYoR iTTF40ZyJR16dR3woox4eicXYssA7+acUwG2k3c4= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 70812240F4B; Thu, 15 Dec 2016 20:35:34 -0800 (PST) To: Ben Campbell , Joel Halpern References: <148186064804.24550.3460112022117949321.idtracker@ietfa.amsl.com> <9E288F8F-BD52-49D0-83B2-472F1B223127@nostrum.com> From: "Joel M. Halpern" Message-ID: Date: Thu, 15 Dec 2016 23:35:33 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <9E288F8F-BD52-49D0-83B2-472F1B223127@nostrum.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: gen-art@ietf.org, dispatch@ietf.org, ietf@ietf.org, draft-mohali-dispatch-cause-for-service-number.all@ietf.org Subject: Re: [dispatch] Review of draft-mohali-dispatch-cause-for-service-number-12 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2016 04:35:36 -0000 I see your point about this adding a value to the entry created by RFC 4458. Is there a reason this can not simply be PS? The fact that 4458 is Informational does not, as far as I can tell, justify continuing the error. While this is for a 3GPP usage, it appears to have been reviewed by the Dispatch WG sufficiently to justify PS. One could argue that there is a down-ref issue, but the fact that the field is in a standards-track required registry would seem to make that a moot point. Yours, Joel PS: It would seem that WG discussion of that sort is something we would like to see in Shepherd writeups. On 12/15/16 11:28 PM, Ben Campbell wrote: > Hi Joel, > > Thanks for the comments. There has been a fair amount of discussion > about the status of the draft. The situation is clearly not optimal, and > I welcome input on how to straighten it out. > > The rational so far has been that this draft updates RFC 4588, which is > informational. It adds some additional values and related semantics for > the "cause" parameter from 4588. It does not register new parameters; > rather it adds itself as a reference in the existing "cause" > registration. This is mainly a courtesy to readers. (There is no > sub-registry for "cause" parameter values.) We might could get by > without that change, since in a perfect world people following the IANA > reference to 4588 would notice the "Updated by..." tag. > > The gotcha is that RFC 4588 would not be possible as an informational > today; it would not have standing to register the "cause" parameter. But > at the time it was published, there was a lack of clarity around the > "standards action" policy for the SIP URI parameters registry. Making > the new values from _this_ draft standards track, when the parameter > itself is not, doesn't seem appropriate. We had some discussion about > whether we should promote 4588 to PS, but there was not consensus to do > so when it was published, and I don't see reason to expect that to have > changed. > > This draft is primarily intended to meet a need in 3GPP, where I > understand they are effectively already doing this. Would it help to > more tightly scope this as "Here's something 3GPP is doing..." rather > than as a general mechanism? > > Thanks! > > Ben. > > On 15 Dec 2016, at 21:57, Joel Halpern wrote: > >> Reviewer: Joel Halpern >> Review result: Ready with Issues >> >> Major: >> This document defines a new code for use in SIP, and specifies new >> behavior both for the code itself and for its use in history-info. I >> am thus confused as to how this can be an informational RFC. It looks >> like it either Proposed Standard or experimental. Yes, I see that RFC >> 4458, which this updates is Informational. But just because we did it >> wrong before does not make that behavior correct now. In addition to >> my understanding of the roles of different RFCs, I note that RFC 3969 >> and the IANA registry both state that this assignment must be made by >> a standards track RFC. >> >> Minor: >> Given our emphasis on IPv6 over IPv4, would it not make sense for >> the examples to use IPv6 addresses? (Inspired by the Id-Nits alert.) From nobody Thu Dec 15 20:51:37 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9775912953C; Thu, 15 Dec 2016 20:51:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.796 X-Spam-Level: X-Spam-Status: No, score=-4.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zVyTyrSyRmw7; Thu, 15 Dec 2016 20:51:33 -0800 (PST) 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 D813912952C; Thu, 15 Dec 2016 20:51:33 -0800 (PST) Received: from [10.0.1.39] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id uBG4pVNS051867 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 15 Dec 2016 22:51:32 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.39] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ben Campbell In-Reply-To: Date: Thu, 15 Dec 2016 22:51:31 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <148186064804.24550.3460112022117949321.idtracker@ietfa.amsl.com> <9E288F8F-BD52-49D0-83B2-472F1B223127@nostrum.com> To: "Joel M. Halpern" X-Mailer: Apple Mail (2.3259) Archived-At: Cc: General Area Review Team , dispatch@ietf.org, ietf@ietf.org, draft-mohali-dispatch-cause-for-service-number.all@ietf.org Subject: Re: [dispatch] Review of draft-mohali-dispatch-cause-for-service-number-12 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2016 04:51:35 -0000 > On Dec 15, 2016, at 10:35 PM, Joel M. Halpern = wrote: >=20 > I see your point about this adding a value to the entry created by RFC = 4458. > Is there a reason this can not simply be PS? The fact that 4458 is = Informational does not, as far as I can tell, justify continuing the = error. While this is for a 3GPP usage, it appears to have been reviewed = by the Dispatch WG sufficiently to justify PS. > One could argue that there is a down-ref issue, > but the fact that the field is in a standards-track required registry = would seem to make that a moot point. >=20 Do you think it makes sense to make some new values for =E2=80=9Ccause=E2=80= =9D into a proposed standard when =E2=80=9Ccause=E2=80=9D itself is = informational? That seems like a pretty big downref issue, as such = issues go. (For the record, I could be convinced to re-run this LC as = PS, but I suspect that would lead to objections in the opposite = direction.) Right now, the situation is a standards-action registry with a = informational entry. That=E2=80=99s clearly broken, but I=E2=80=99m not = sure that _this_ draft is the place to fix it. Also, if it makes any difference=E2=80=94even there there was discussion = in dispatch, this is not a dispatch work item. > Yours, > Joel >=20 > PS: It would seem that WG discussion of that sort is something we = would like to see in Shepherd writeups. There=E2=80=99s two paragraphs on the subject in section (1) of the = shepherd writeup :-) (but it wasn=E2=80=99t a working group discussion = per se.) Thanks! Ben. >=20 > On 12/15/16 11:28 PM, Ben Campbell wrote: >> Hi Joel, >>=20 >> Thanks for the comments. There has been a fair amount of discussion >> about the status of the draft. The situation is clearly not optimal, = and >> I welcome input on how to straighten it out. >>=20 >> The rational so far has been that this draft updates RFC 4588, which = is >> informational. It adds some additional values and related semantics = for >> the "cause" parameter from 4588. It does not register new parameters; >> rather it adds itself as a reference in the existing "cause" >> registration. This is mainly a courtesy to readers. (There is no >> sub-registry for "cause" parameter values.) We might could get by >> without that change, since in a perfect world people following the = IANA >> reference to 4588 would notice the "Updated by..." tag. >>=20 >> The gotcha is that RFC 4588 would not be possible as an informational >> today; it would not have standing to register the "cause" parameter. = But >> at the time it was published, there was a lack of clarity around the >> "standards action" policy for the SIP URI parameters registry. Making >> the new values from _this_ draft standards track, when the parameter >> itself is not, doesn't seem appropriate. We had some discussion about >> whether we should promote 4588 to PS, but there was not consensus to = do >> so when it was published, and I don't see reason to expect that to = have >> changed. >>=20 >> This draft is primarily intended to meet a need in 3GPP, where I >> understand they are effectively already doing this. Would it help to >> more tightly scope this as "Here's something 3GPP is doing..." rather >> than as a general mechanism? >>=20 >> Thanks! >>=20 >> Ben. >>=20 >> On 15 Dec 2016, at 21:57, Joel Halpern wrote: >>=20 >>> Reviewer: Joel Halpern >>> Review result: Ready with Issues >>>=20 >>> Major: >>> This document defines a new code for use in SIP, and specifies = new >>> behavior both for the code itself and for its use in history-info. = I >>> am thus confused as to how this can be an informational RFC. It = looks >>> like it either Proposed Standard or experimental. Yes, I see that = RFC >>> 4458, which this updates is Informational. But just because we did = it >>> wrong before does not make that behavior correct now. In addition = to >>> my understanding of the roles of different RFCs, I note that RFC = 3969 >>> and the IANA registry both state that this assignment must be made = by >>> a standards track RFC. >>>=20 >>> Minor: >>> Given our emphasis on IPv6 over IPv4, would it not make sense for >>> the examples to use IPv6 addresses? (Inspired by the Id-Nits = alert.) From nobody Thu Dec 15 21:07:12 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6398129553; Thu, 15 Dec 2016 21:07:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YsEuubBB5JRT; Thu, 15 Dec 2016 21:07:10 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 2595A129549; Thu, 15 Dec 2016 21:07:10 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id CF98E401ED4; Thu, 15 Dec 2016 21:07:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1481864829; bh=WPhARhfE/nNCXhgZanIR3g9xth5XWN0+BERVhwquwTo=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=RuFuhb9Z1mhczfXR6zg/IGnfJMBfssSNmrdyyg4Uo5uPNqPnRqqpoXZCwYI3gcOMl IUNeWZ0PY7XHZBZEfuqTo7gpQT2igpUvSMqfLfXJC7CbQzJRqXtLQ2Z9/25fdIl4B2 7tSZMMisg5r88b4RRwqZCPokMySWu9IOdXWSkiGY= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id C7D421C00F6; Thu, 15 Dec 2016 21:07:08 -0800 (PST) To: Ben Campbell References: <148186064804.24550.3460112022117949321.idtracker@ietfa.amsl.com> <9E288F8F-BD52-49D0-83B2-472F1B223127@nostrum.com> From: "Joel M. Halpern" Message-ID: <50a163d3-0ca0-fdd0-7cb8-b09de0a5a5e2@joelhalpern.com> Date: Fri, 16 Dec 2016 00:07:07 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: General Area Review Team , dispatch@ietf.org, ietf@ietf.org, draft-mohali-dispatch-cause-for-service-number.all@ietf.org Subject: Re: [dispatch] Review of draft-mohali-dispatch-cause-for-service-number-12 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2016 05:07:12 -0000 At this point I will defer to the relevant ADs. As far as I can tell, although the entry was created by an Informational RFC, the registry still claims that it is standards track. And since this document is defining behavior, it behaves more like a standards track document than an Informational one. But it is up to you folks. In teh end, all I can do is raise the question, not decide it :-) Yours, Joel On 12/15/16 11:51 PM, Ben Campbell wrote: > >> On Dec 15, 2016, at 10:35 PM, Joel M. Halpern wrote: >> >> I see your point about this adding a value to the entry created by RFC 4458. >> Is there a reason this can not simply be PS? The fact that 4458 is Informational does not, as far as I can tell, justify continuing the error. While this is for a 3GPP usage, it appears to have been reviewed by the Dispatch WG sufficiently to justify PS. >> One could argue that there is a down-ref issue, >> but the fact that the field is in a standards-track required registry would seem to make that a moot point. >> > > Do you think it makes sense to make some new values for “cause” into a proposed standard when “cause” itself is informational? That seems like a pretty big downref issue, as such issues go. (For the record, I could be convinced to re-run this LC as PS, but I suspect that would lead to objections in the opposite direction.) > > Right now, the situation is a standards-action registry with a informational entry. That’s clearly broken, but I’m not sure that _this_ draft is the place to fix it. > > Also, if it makes any difference—even there there was discussion in dispatch, this is not a dispatch work item. > >> Yours, >> Joel >> >> PS: It would seem that WG discussion of that sort is something we would like to see in Shepherd writeups. > > There’s two paragraphs on the subject in section (1) of the shepherd writeup :-) (but it wasn’t a working group discussion per se.) > > Thanks! > > Ben. > >> >> On 12/15/16 11:28 PM, Ben Campbell wrote: >>> Hi Joel, >>> >>> Thanks for the comments. There has been a fair amount of discussion >>> about the status of the draft. The situation is clearly not optimal, and >>> I welcome input on how to straighten it out. >>> >>> The rational so far has been that this draft updates RFC 4588, which is >>> informational. It adds some additional values and related semantics for >>> the "cause" parameter from 4588. It does not register new parameters; >>> rather it adds itself as a reference in the existing "cause" >>> registration. This is mainly a courtesy to readers. (There is no >>> sub-registry for "cause" parameter values.) We might could get by >>> without that change, since in a perfect world people following the IANA >>> reference to 4588 would notice the "Updated by..." tag. >>> >>> The gotcha is that RFC 4588 would not be possible as an informational >>> today; it would not have standing to register the "cause" parameter. But >>> at the time it was published, there was a lack of clarity around the >>> "standards action" policy for the SIP URI parameters registry. Making >>> the new values from _this_ draft standards track, when the parameter >>> itself is not, doesn't seem appropriate. We had some discussion about >>> whether we should promote 4588 to PS, but there was not consensus to do >>> so when it was published, and I don't see reason to expect that to have >>> changed. >>> >>> This draft is primarily intended to meet a need in 3GPP, where I >>> understand they are effectively already doing this. Would it help to >>> more tightly scope this as "Here's something 3GPP is doing..." rather >>> than as a general mechanism? >>> >>> Thanks! >>> >>> Ben. >>> >>> On 15 Dec 2016, at 21:57, Joel Halpern wrote: >>> >>>> Reviewer: Joel Halpern >>>> Review result: Ready with Issues >>>> >>>> Major: >>>> This document defines a new code for use in SIP, and specifies new >>>> behavior both for the code itself and for its use in history-info. I >>>> am thus confused as to how this can be an informational RFC. It looks >>>> like it either Proposed Standard or experimental. Yes, I see that RFC >>>> 4458, which this updates is Informational. But just because we did it >>>> wrong before does not make that behavior correct now. In addition to >>>> my understanding of the roles of different RFCs, I note that RFC 3969 >>>> and the IANA registry both state that this assignment must be made by >>>> a standards track RFC. >>>> >>>> Minor: >>>> Given our emphasis on IPv6 over IPv4, would it not make sense for >>>> the examples to use IPv6 addresses? (Inspired by the Id-Nits alert.) > > From nobody Mon Dec 19 09:11:15 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEA7B129C1B for ; Mon, 19 Dec 2016 09:11:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id deNRaficd2Yy for ; Mon, 19 Dec 2016 09:11:12 -0800 (PST) Received: from smtp120.iad3a.emailsrvr.com (smtp120.iad3a.emailsrvr.com [173.203.187.120]) (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 17D0C1294C7 for ; Mon, 19 Dec 2016 09:11:12 -0800 (PST) Received: from smtp32.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp32.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 530905941; Mon, 19 Dec 2016 12:11:11 -0500 (EST) X-Auth-ID: fluffy@iii.ca Received: by smtp32.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id B124F5983; Mon, 19 Dec 2016 12:11:10 -0500 (EST) X-Sender-Id: fluffy@iii.ca Received: from [10.1.3.253] (d75-159-45-76.abhsia.telus.net [75.159.45.76]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.12); Mon, 19 Dec 2016 12:11:11 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\)) From: Cullen Jennings In-Reply-To: <50a163d3-0ca0-fdd0-7cb8-b09de0a5a5e2@joelhalpern.com> Date: Mon, 19 Dec 2016 10:11:09 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1BDDB9BA-E712-4DC8-9194-A16DF97F84D1@iii.ca> References: <148186064804.24550.3460112022117949321.idtracker@ietfa.amsl.com> <9E288F8F-BD52-49D0-83B2-472F1B223127@nostrum.com> <50a163d3-0ca0-fdd0-7cb8-b09de0a5a5e2@joelhalpern.com> To: Joel Halpern X-Mailer: Apple Mail (2.3226) Archived-At: Cc: Ben Campbell , DISPATCH , IETF , draft-mohali-dispatch-cause-for-service-number.all@ietf.org Subject: Re: [dispatch] Review of draft-mohali-dispatch-cause-for-service-number-12 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 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 Dec 2016 17:11:14 -0000 > On Dec 15, 2016, at 10:07 PM, Joel M. Halpern = wrote: >=20 > At this point I will defer to the relevant ADs. +1 on that :-) > As far as I can tell, although the entry was created by an = Informational RFC, the registry still claims that it is standards track. > And since this document is defining behavior, it behaves more like a = standards track document than an Informational one. >=20 > But it is up to you folks. In teh end, all I can do is raise the = question, not decide it :-) So the registry takes PS to change it. And by the current SIP rules, I = suspect (not sure) that an update to 4458 would also have to be PS. So = really not sure how one gets around this not being PS.=20 >=20 > Yours, > Joel >=20 > On 12/15/16 11:51 PM, Ben Campbell wrote: >>=20 >>> On Dec 15, 2016, at 10:35 PM, Joel M. Halpern = wrote: >>>=20 >>> I see your point about this adding a value to the entry created by = RFC 4458. >>> Is there a reason this can not simply be PS? The fact that 4458 is = Informational does not, as far as I can tell, justify continuing the = error. While this is for a 3GPP usage, it appears to have been reviewed = by the Dispatch WG sufficiently to justify PS. >>> One could argue that there is a down-ref issue, >>> but the fact that the field is in a standards-track required = registry would seem to make that a moot point. >>>=20 >>=20 >> Do you think it makes sense to make some new values for =E2=80=9Ccause=E2= =80=9D into a proposed standard when =E2=80=9Ccause=E2=80=9D itself is = informational? That seems like a pretty big downref issue, as such = issues go. (For the record, I could be convinced to re-run this LC as = PS, but I suspect that would lead to objections in the opposite = direction.) >>=20 >> Right now, the situation is a standards-action registry with a = informational entry. That=E2=80=99s clearly broken, but I=E2=80=99m not = sure that _this_ draft is the place to fix it. >>=20 >> Also, if it makes any difference=E2=80=94even there there was = discussion in dispatch, this is not a dispatch work item. >>=20 >>> Yours, >>> Joel >>>=20 >>> PS: It would seem that WG discussion of that sort is something we = would like to see in Shepherd writeups. >>=20 >> There=E2=80=99s two paragraphs on the subject in section (1) of the = shepherd writeup :-) (but it wasn=E2=80=99t a working group discussion = per se.) >>=20 >> Thanks! >>=20 >> Ben. >>=20 >>>=20 >>> On 12/15/16 11:28 PM, Ben Campbell wrote: >>>> Hi Joel, >>>>=20 >>>> Thanks for the comments. There has been a fair amount of discussion >>>> about the status of the draft. The situation is clearly not = optimal, and >>>> I welcome input on how to straighten it out. >>>>=20 >>>> The rational so far has been that this draft updates RFC 4588, = which is >>>> informational. It adds some additional values and related semantics = for >>>> the "cause" parameter from 4588. It does not register new = parameters; >>>> rather it adds itself as a reference in the existing "cause" >>>> registration. This is mainly a courtesy to readers. (There is no >>>> sub-registry for "cause" parameter values.) We might could get by >>>> without that change, since in a perfect world people following the = IANA >>>> reference to 4588 would notice the "Updated by..." tag. >>>>=20 >>>> The gotcha is that RFC 4588 would not be possible as an = informational >>>> today; it would not have standing to register the "cause" = parameter. But >>>> at the time it was published, there was a lack of clarity around = the >>>> "standards action" policy for the SIP URI parameters registry. = Making >>>> the new values from _this_ draft standards track, when the = parameter >>>> itself is not, doesn't seem appropriate. We had some discussion = about >>>> whether we should promote 4588 to PS, but there was not consensus = to do >>>> so when it was published, and I don't see reason to expect that to = have >>>> changed. >>>>=20 >>>> This draft is primarily intended to meet a need in 3GPP, where I >>>> understand they are effectively already doing this. Would it help = to >>>> more tightly scope this as "Here's something 3GPP is doing..." = rather >>>> than as a general mechanism? >>>>=20 >>>> Thanks! >>>>=20 >>>> Ben. >>>>=20 >>>> On 15 Dec 2016, at 21:57, Joel Halpern wrote: >>>>=20 >>>>> Reviewer: Joel Halpern >>>>> Review result: Ready with Issues >>>>>=20 >>>>> Major: >>>>> This document defines a new code for use in SIP, and specifies = new >>>>> behavior both for the code itself and for its use in history-info. = I >>>>> am thus confused as to how this can be an informational RFC. It = looks >>>>> like it either Proposed Standard or experimental. Yes, I see that = RFC >>>>> 4458, which this updates is Informational. But just because we = did it >>>>> wrong before does not make that behavior correct now. In addition = to >>>>> my understanding of the roles of different RFCs, I note that RFC = 3969 >>>>> and the IANA registry both state that this assignment must be made = by >>>>> a standards track RFC. >>>>>=20 >>>>> Minor: >>>>> Given our emphasis on IPv6 over IPv4, would it not make sense for >>>>> the examples to use IPv6 addresses? (Inspired by the Id-Nits = alert.) >>=20 >>=20 >=20 From nobody Mon Dec 19 09:31:26 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E62EE129BDF; Mon, 19 Dec 2016 09:31:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.019 X-Spam-Level: X-Spam-Status: No, score=-5.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HxCWx_OyxvTQ; Mon, 19 Dec 2016 09:31:19 -0800 (PST) Received: from relais-inet.orange.com (mta241.mail.business.static.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DABA6129472; Mon, 19 Dec 2016 09:31:18 -0800 (PST) Received: from opfedar07.francetelecom.fr (unknown [xx.xx.xx.9]) by opfedar20.francetelecom.fr (ESMTP service) with ESMTP id 404801203C9; Mon, 19 Dec 2016 18:31:17 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.69]) by opfedar07.francetelecom.fr (ESMTP service) with ESMTP id 0C9A6C0057; Mon, 19 Dec 2016 18:31:17 +0100 (CET) Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILMA2.corporate.adroot.infra.ftgroup ([fe80::bc1c:ad2f:eda3:8c3d%18]) with mapi id 14.03.0319.002; Mon, 19 Dec 2016 18:31:15 +0100 From: To: Cullen Jennings , Joel Halpern Thread-Topic: Review of draft-mohali-dispatch-cause-for-service-number-12 Thread-Index: AQHSV1CHvHTQY58KVkSYsqTpbOYMOaEJ6muAgAAB3YCAAAR2gIAABFyAgAWBSYCAABPscA== Date: Mon, 19 Dec 2016 17:31:14 +0000 Message-ID: <26405_1482168677_58581965_26405_11893_1_8B970F90C584EA4E97D5BAAC9172DBB81C884468@OPEXCLILMA4.corporate.adroot.infra.ftgroup> References: <148186064804.24550.3460112022117949321.idtracker@ietfa.amsl.com> <9E288F8F-BD52-49D0-83B2-472F1B223127@nostrum.com> <50a163d3-0ca0-fdd0-7cb8-b09de0a5a5e2@joelhalpern.com> <1BDDB9BA-E712-4DC8-9194-A16DF97F84D1@iii.ca> In-Reply-To: <1BDDB9BA-E712-4DC8-9194-A16DF97F84D1@iii.ca> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Ben Campbell , DISPATCH , IETF , "draft-mohali-dispatch-cause-for-service-number.all@ietf.org" Subject: Re: [dispatch] Review of draft-mohali-dispatch-cause-for-service-number-12 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 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 Dec 2016 17:31:21 -0000 SGksDQoNCklmIEkgY2FuIHN1Z2dlc3QgYW4gYWx0ZXJuYXRpdmU6IHRvIG1ha2UgdGhpcyBkb2N1 bWVudCBvYnNvbGV0ZSBSRkM0NDU4IChhZGRpbmcgUkZDNDQ1OCBjb250ZW50KSB3aXRoIHRoZSBh cmd1bWVudCB0aGF0IFJGQzQ0NTggd2FzIGluZm9ybWF0aW9uYWwgYnV0IGJlY2F1c2UgaXQgZGVm aW5lZCBTSVAgcHJvdG9jb2wgZWxlbWVudCBhbmQgcHJvY2VkdXJlcywgaXQgaXMgb2Jzb2xldGVk IHRvIGFsaWduIHdpdGggSUVURiBydWxlcyBhbmQgSUFOQSByZWdpc3RyYXRpb24gb2YgdGhpcyBw YXJhbWV0ZXIgd2l0aCBubyB0ZWNobmljYWwgbW9kaWZpY2F0aW9uLiBUaGUganVzdGlmaWNhdGlv biBpcyBub3QgcmVhbGx5IHN0cm9uZyBidXQgaXQgd291bGQgY29ycmVjdCB0aGUgY3VycmVudCBz aXR1YXRpb24uDQoNCkJSLA0KTWFyaWFubmUNCg0KLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0t DQpEZcKgOiBDdWxsZW4gSmVubmluZ3MgW21haWx0bzpmbHVmZnlAaWlpLmNhXSANCkVudm95w6nC oDogbHVuZGkgMTkgZMOpY2VtYnJlIDIwMTYgMTg6MTENCsOAwqA6IEpvZWwgSGFscGVybg0KQ2PC oDogQmVuIENhbXBiZWxsOyBESVNQQVRDSDsgSUVURjsgZHJhZnQtbW9oYWxpLWRpc3BhdGNoLWNh dXNlLWZvci1zZXJ2aWNlLW51bWJlci5hbGxAaWV0Zi5vcmcNCk9iamV0wqA6IFJlOiBSZXZpZXcg b2YgZHJhZnQtbW9oYWxpLWRpc3BhdGNoLWNhdXNlLWZvci1zZXJ2aWNlLW51bWJlci0xMg0KDQoN Cj4gT24gRGVjIDE1LCAyMDE2LCBhdCAxMDowNyBQTSwgSm9lbCBNLiBIYWxwZXJuIDxqbWhAam9l bGhhbHBlcm4uY29tPiB3cm90ZToNCj4gDQo+IEF0IHRoaXMgcG9pbnQgSSB3aWxsIGRlZmVyIHRv IHRoZSByZWxldmFudCBBRHMuDQoNCisxIG9uIHRoYXQgOi0pDQoNCj4gQXMgZmFyIGFzIEkgY2Fu IHRlbGwsIGFsdGhvdWdoIHRoZSBlbnRyeSB3YXMgY3JlYXRlZCBieSBhbiBJbmZvcm1hdGlvbmFs IFJGQywgdGhlIHJlZ2lzdHJ5IHN0aWxsIGNsYWltcyB0aGF0IGl0IGlzIHN0YW5kYXJkcyB0cmFj ay4NCj4gQW5kIHNpbmNlIHRoaXMgZG9jdW1lbnQgaXMgZGVmaW5pbmcgYmVoYXZpb3IsIGl0IGJl aGF2ZXMgbW9yZSBsaWtlIGEgc3RhbmRhcmRzIHRyYWNrIGRvY3VtZW50IHRoYW4gYW4gSW5mb3Jt YXRpb25hbCBvbmUuDQo+IA0KPiBCdXQgaXQgaXMgdXAgdG8geW91IGZvbGtzLiAgSW4gdGVoIGVu ZCwgYWxsIEkgY2FuIGRvIGlzIHJhaXNlIHRoZSANCj4gcXVlc3Rpb24sIG5vdCBkZWNpZGUgaXQg Oi0pDQoNClNvIHRoZSByZWdpc3RyeSB0YWtlcyBQUyB0byBjaGFuZ2UgaXQuIEFuZCBieSB0aGUg Y3VycmVudCBTSVAgcnVsZXMsIEkgc3VzcGVjdCAobm90IHN1cmUpIHRoYXQgYW4gdXBkYXRlIHRv IDQ0NTggd291bGQgYWxzbyBoYXZlIHRvIGJlIFBTLiBTbyByZWFsbHkgbm90IHN1cmUgaG93IG9u ZSBnZXRzIGFyb3VuZCB0aGlzIG5vdCBiZWluZyBQUy4gDQoNCg0KPiANCj4gWW91cnMsDQo+IEpv ZWwNCj4gDQo+IE9uIDEyLzE1LzE2IDExOjUxIFBNLCBCZW4gQ2FtcGJlbGwgd3JvdGU6DQo+PiAN Cj4+PiBPbiBEZWMgMTUsIDIwMTYsIGF0IDEwOjM1IFBNLCBKb2VsIE0uIEhhbHBlcm4gPGptaEBq b2VsaGFscGVybi5jb20+IHdyb3RlOg0KPj4+IA0KPj4+IEkgc2VlIHlvdXIgcG9pbnQgYWJvdXQg dGhpcyBhZGRpbmcgYSB2YWx1ZSB0byB0aGUgZW50cnkgY3JlYXRlZCBieSBSRkMgNDQ1OC4NCj4+ PiBJcyB0aGVyZSBhIHJlYXNvbiB0aGlzIGNhbiBub3Qgc2ltcGx5IGJlIFBTPyAgVGhlIGZhY3Qg dGhhdCA0NDU4IGlzIEluZm9ybWF0aW9uYWwgZG9lcyBub3QsIGFzIGZhciBhcyBJIGNhbiB0ZWxs LCBqdXN0aWZ5IGNvbnRpbnVpbmcgdGhlIGVycm9yLiAgV2hpbGUgdGhpcyBpcyBmb3IgYSAzR1BQ IHVzYWdlLCBpdCBhcHBlYXJzIHRvIGhhdmUgYmVlbiByZXZpZXdlZCBieSB0aGUgRGlzcGF0Y2gg V0cgc3VmZmljaWVudGx5IHRvIGp1c3RpZnkgUFMuDQo+Pj4gT25lIGNvdWxkIGFyZ3VlIHRoYXQg dGhlcmUgaXMgYSBkb3duLXJlZiBpc3N1ZSwgYnV0IHRoZSBmYWN0IHRoYXQgDQo+Pj4gdGhlIGZp ZWxkIGlzIGluIGEgc3RhbmRhcmRzLXRyYWNrIHJlcXVpcmVkIHJlZ2lzdHJ5IHdvdWxkIHNlZW0g dG8gbWFrZSB0aGF0IGEgbW9vdCBwb2ludC4NCj4+PiANCj4+IA0KPj4gRG8geW91IHRoaW5rIGl0 IG1ha2VzIHNlbnNlIHRvIG1ha2Ugc29tZSBuZXcgdmFsdWVzIGZvciDigJxjYXVzZeKAnSBpbnRv IA0KPj4gYSBwcm9wb3NlZCBzdGFuZGFyZCB3aGVuIOKAnGNhdXNl4oCdIGl0c2VsZiBpcyBpbmZv cm1hdGlvbmFsPyAgVGhhdCBzZWVtcyANCj4+IGxpa2UgYSBwcmV0dHkgYmlnIGRvd25yZWYgaXNz dWUsIGFzIHN1Y2ggaXNzdWVzIGdvLiAoRm9yIHRoZSByZWNvcmQsIA0KPj4gSSBjb3VsZCBiZSBj b252aW5jZWQgdG8gcmUtcnVuIHRoaXMgTEMgYXMgUFMsIGJ1dCBJIHN1c3BlY3QgdGhhdCANCj4+ IHdvdWxkIGxlYWQgdG8gb2JqZWN0aW9ucyBpbiB0aGUgb3Bwb3NpdGUgZGlyZWN0aW9uLikNCj4+ IA0KPj4gUmlnaHQgbm93LCB0aGUgc2l0dWF0aW9uIGlzIGEgc3RhbmRhcmRzLWFjdGlvbiByZWdp c3RyeSB3aXRoIGEgaW5mb3JtYXRpb25hbCBlbnRyeS4gVGhhdOKAmXMgY2xlYXJseSBicm9rZW4s IGJ1dCBJ4oCZbSBub3Qgc3VyZSB0aGF0IF90aGlzXyBkcmFmdCBpcyB0aGUgcGxhY2UgdG8gZml4 IGl0Lg0KPj4gDQo+PiBBbHNvLCBpZiBpdCBtYWtlcyBhbnkgZGlmZmVyZW5jZeKAlGV2ZW4gdGhl cmUgdGhlcmUgd2FzIGRpc2N1c3Npb24gaW4gZGlzcGF0Y2gsIHRoaXMgaXMgbm90IGEgZGlzcGF0 Y2ggd29yayBpdGVtLg0KPj4gDQo+Pj4gWW91cnMsDQo+Pj4gSm9lbA0KPj4+IA0KPj4+IFBTOiBJ dCB3b3VsZCBzZWVtIHRoYXQgV0cgZGlzY3Vzc2lvbiBvZiB0aGF0IHNvcnQgaXMgc29tZXRoaW5n IHdlIHdvdWxkIGxpa2UgdG8gc2VlIGluIFNoZXBoZXJkIHdyaXRldXBzLg0KPj4gDQo+PiBUaGVy ZeKAmXMgdHdvIHBhcmFncmFwaHMgb24gdGhlIHN1YmplY3QgaW4gc2VjdGlvbiAoMSkgb2YgdGhl IHNoZXBoZXJkIA0KPj4gd3JpdGV1cCA6LSkgIChidXQgaXQgd2FzbuKAmXQgYSB3b3JraW5nIGdy b3VwIGRpc2N1c3Npb24gcGVyIHNlLikNCj4+IA0KPj4gVGhhbmtzIQ0KPj4gDQo+PiBCZW4uDQo+ PiANCj4+PiANCj4+PiBPbiAxMi8xNS8xNiAxMToyOCBQTSwgQmVuIENhbXBiZWxsIHdyb3RlOg0K Pj4+PiBIaSBKb2VsLA0KPj4+PiANCj4+Pj4gVGhhbmtzIGZvciB0aGUgY29tbWVudHMuIFRoZXJl IGhhcyBiZWVuIGEgZmFpciBhbW91bnQgb2YgZGlzY3Vzc2lvbiANCj4+Pj4gYWJvdXQgdGhlIHN0 YXR1cyBvZiB0aGUgZHJhZnQuIFRoZSBzaXR1YXRpb24gaXMgY2xlYXJseSBub3QgDQo+Pj4+IG9w dGltYWwsIGFuZCBJIHdlbGNvbWUgaW5wdXQgb24gaG93IHRvIHN0cmFpZ2h0ZW4gaXQgb3V0Lg0K Pj4+PiANCj4+Pj4gVGhlIHJhdGlvbmFsIHNvIGZhciBoYXMgYmVlbiB0aGF0IHRoaXMgZHJhZnQg dXBkYXRlcyBSRkMgNDU4OCwgDQo+Pj4+IHdoaWNoIGlzIGluZm9ybWF0aW9uYWwuIEl0IGFkZHMg c29tZSBhZGRpdGlvbmFsIHZhbHVlcyBhbmQgcmVsYXRlZCANCj4+Pj4gc2VtYW50aWNzIGZvciB0 aGUgImNhdXNlIiBwYXJhbWV0ZXIgZnJvbSA0NTg4LiBJdCBkb2VzIG5vdCByZWdpc3RlciANCj4+ Pj4gbmV3IHBhcmFtZXRlcnM7IHJhdGhlciBpdCBhZGRzIGl0c2VsZiBhcyBhIHJlZmVyZW5jZSBp biB0aGUgZXhpc3RpbmcgImNhdXNlIg0KPj4+PiByZWdpc3RyYXRpb24uIFRoaXMgaXMgbWFpbmx5 IGEgY291cnRlc3kgdG8gcmVhZGVycy4gKFRoZXJlIGlzIG5vIA0KPj4+PiBzdWItcmVnaXN0cnkg Zm9yICJjYXVzZSIgcGFyYW1ldGVyIHZhbHVlcy4pIFdlIG1pZ2h0IGNvdWxkIGdldCBieSANCj4+ Pj4gd2l0aG91dCB0aGF0IGNoYW5nZSwgc2luY2UgaW4gYSBwZXJmZWN0IHdvcmxkIHBlb3BsZSBm b2xsb3dpbmcgdGhlIA0KPj4+PiBJQU5BIHJlZmVyZW5jZSB0byA0NTg4IHdvdWxkIG5vdGljZSB0 aGUgIlVwZGF0ZWQgYnkuLi4iIHRhZy4NCj4+Pj4gDQo+Pj4+IFRoZSBnb3RjaGEgaXMgdGhhdCBS RkMgNDU4OCB3b3VsZCBub3QgYmUgcG9zc2libGUgYXMgYW4gDQo+Pj4+IGluZm9ybWF0aW9uYWwg dG9kYXk7IGl0IHdvdWxkIG5vdCBoYXZlIHN0YW5kaW5nIHRvIHJlZ2lzdGVyIHRoZSANCj4+Pj4g ImNhdXNlIiBwYXJhbWV0ZXIuIEJ1dCBhdCB0aGUgdGltZSBpdCB3YXMgcHVibGlzaGVkLCB0aGVy ZSB3YXMgYSANCj4+Pj4gbGFjayBvZiBjbGFyaXR5IGFyb3VuZCB0aGUgInN0YW5kYXJkcyBhY3Rp b24iIHBvbGljeSBmb3IgdGhlIFNJUCANCj4+Pj4gVVJJIHBhcmFtZXRlcnMgcmVnaXN0cnkuIE1h a2luZyB0aGUgbmV3IHZhbHVlcyBmcm9tIF90aGlzXyBkcmFmdCANCj4+Pj4gc3RhbmRhcmRzIHRy YWNrLCB3aGVuIHRoZSBwYXJhbWV0ZXIgaXRzZWxmIGlzIG5vdCwgZG9lc24ndCBzZWVtIA0KPj4+ PiBhcHByb3ByaWF0ZS4gV2UgaGFkIHNvbWUgZGlzY3Vzc2lvbiBhYm91dCB3aGV0aGVyIHdlIHNo b3VsZCBwcm9tb3RlIA0KPj4+PiA0NTg4IHRvIFBTLCBidXQgdGhlcmUgd2FzIG5vdCBjb25zZW5z dXMgdG8gZG8gc28gd2hlbiBpdCB3YXMgDQo+Pj4+IHB1Ymxpc2hlZCwgYW5kIEkgZG9uJ3Qgc2Vl IHJlYXNvbiB0byBleHBlY3QgdGhhdCB0byBoYXZlIGNoYW5nZWQuDQo+Pj4+IA0KPj4+PiBUaGlz IGRyYWZ0IGlzIHByaW1hcmlseSBpbnRlbmRlZCB0byBtZWV0IGEgbmVlZCBpbiAzR1BQLCB3aGVy ZSBJIA0KPj4+PiB1bmRlcnN0YW5kIHRoZXkgYXJlIGVmZmVjdGl2ZWx5IGFscmVhZHkgZG9pbmcg dGhpcy4gV291bGQgaXQgaGVscCANCj4+Pj4gdG8gbW9yZSB0aWdodGx5IHNjb3BlIHRoaXMgYXMg IkhlcmUncyBzb21ldGhpbmcgM0dQUCBpcyBkb2luZy4uLiIgDQo+Pj4+IHJhdGhlciB0aGFuIGFz IGEgZ2VuZXJhbCBtZWNoYW5pc20/DQo+Pj4+IA0KPj4+PiBUaGFua3MhDQo+Pj4+IA0KPj4+PiBC ZW4uDQo+Pj4+IA0KPj4+PiBPbiAxNSBEZWMgMjAxNiwgYXQgMjE6NTcsIEpvZWwgSGFscGVybiB3 cm90ZToNCj4+Pj4gDQo+Pj4+PiBSZXZpZXdlcjogSm9lbCBIYWxwZXJuDQo+Pj4+PiBSZXZpZXcg cmVzdWx0OiBSZWFkeSB3aXRoIElzc3Vlcw0KPj4+Pj4gDQo+Pj4+PiBNYWpvcjoNCj4+Pj4+ICAg VGhpcyBkb2N1bWVudCBkZWZpbmVzIGEgbmV3IGNvZGUgZm9yIHVzZSBpbiBTSVAsIGFuZCBzcGVj aWZpZXMgDQo+Pj4+PiBuZXcgYmVoYXZpb3IgYm90aCBmb3IgdGhlIGNvZGUgaXRzZWxmIGFuZCBm b3IgaXRzIHVzZSBpbiANCj4+Pj4+IGhpc3RvcnktaW5mby4gIEkgYW0gdGh1cyBjb25mdXNlZCBh cyB0byBob3cgdGhpcyBjYW4gYmUgYW4gDQo+Pj4+PiBpbmZvcm1hdGlvbmFsIFJGQy4gIEl0IGxv b2tzIGxpa2UgaXQgZWl0aGVyIFByb3Bvc2VkIFN0YW5kYXJkIG9yIA0KPj4+Pj4gZXhwZXJpbWVu dGFsLiAgWWVzLCBJIHNlZSB0aGF0IFJGQyA0NDU4LCB3aGljaCB0aGlzIHVwZGF0ZXMgaXMgDQo+ Pj4+PiBJbmZvcm1hdGlvbmFsLiAgQnV0IGp1c3QgYmVjYXVzZSB3ZSBkaWQgaXQgd3JvbmcgYmVm b3JlIGRvZXMgbm90IA0KPj4+Pj4gbWFrZSB0aGF0IGJlaGF2aW9yIGNvcnJlY3Qgbm93LiAgSW4g YWRkaXRpb24gdG8gbXkgdW5kZXJzdGFuZGluZyANCj4+Pj4+IG9mIHRoZSByb2xlcyBvZiBkaWZm ZXJlbnQgUkZDcywgSSBub3RlIHRoYXQgUkZDIDM5NjkgYW5kIHRoZSBJQU5BIA0KPj4+Pj4gcmVn aXN0cnkgYm90aCBzdGF0ZSB0aGF0IHRoaXMgYXNzaWdubWVudCBtdXN0IGJlIG1hZGUgYnkgYSBz dGFuZGFyZHMgdHJhY2sgUkZDLg0KPj4+Pj4gDQo+Pj4+PiBNaW5vcjoNCj4+Pj4+ICBHaXZlbiBv dXIgZW1waGFzaXMgb24gSVB2NiBvdmVyIElQdjQsIHdvdWxkIGl0IG5vdCBtYWtlIHNlbnNlIGZv ciANCj4+Pj4+IHRoZSBleGFtcGxlcyB0byB1c2UgSVB2NiBhZGRyZXNzZXM/ICAoSW5zcGlyZWQg YnkgdGhlIElkLU5pdHMgDQo+Pj4+PiBhbGVydC4pDQo+PiANCj4+IA0KPiANCg0KCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18K CkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGlu Zm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQg ZG9uYwpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNh dGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBs ZSBzaWduYWxlcgphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBp ZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJs ZXMgZCdhbHRlcmF0aW9uLApPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBj ZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuCgpUaGlz IG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3Ig cHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Owp0aGV5 IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9y aXNhdGlvbi4KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNl IG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNo bWVudHMuCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9y IG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4K VGhhbmsgeW91LgoK From nobody Mon Dec 19 09:41:00 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5107E129C1D; Mon, 19 Dec 2016 09:40:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FvI3mqLnOH1V; Mon, 19 Dec 2016 09:40:57 -0800 (PST) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::22c]) (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 843DD124281; Mon, 19 Dec 2016 09:40:57 -0800 (PST) Received: by mail-oi0-x22c.google.com with SMTP id w63so152486071oiw.0; Mon, 19 Dec 2016 09:40:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=4qjdYHQesciJZ8rApZ5y5YYFzququpBbryzUpmtZ00Q=; b=sd8CjbiZcxV5EJ9ricXP+0cSLLsKIyGvu+S3g7GS3snu3/6q9LhLDZ4GGM9vFa0Yf7 HbP/UmWhvRejPc+E+INlrpr13sGxipQhQTP5VvRLTByvU6PKsfbbtSDEiN7u/wFzWkqD R8SJicpTRbvLT54D5L9twGWmemRUjOatSHoUYMbHL670TT2vz0N0Lio3OmKdiCIEhPTz gQ5OA75RPvZi2lA3MbxN+MOn7zRr9UqHDH8bljGClqMlkFb4/ZvsoQ5eP3Lmg4Hw/imV 8kOMQAQQ8vYLn5GVF3TlhjIcIgXOXsxeOefnX3eQfCZCND/5QO/hNc4zGQ/EEHVTZzgg uFZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=4qjdYHQesciJZ8rApZ5y5YYFzququpBbryzUpmtZ00Q=; b=NpblYA04KUZOOT8dS7bC9cpip94bqMtqA63V7OJ3Nu4TX7edTp8fQi30f37twIf9Ob /RL5tHy4ZgT3skfGV619xurFZApgV7g+pOiax1wj8DYQOTX/LLJGryIGz4QJKvWoqCr0 i6batsF5yl7Iit53DEqUy9qmP6KNhOGFRXZDWug3ZTUv5e76X3j7q2LQ0hBsA/z8EuDq VV2dp3SWC6WcIo1Ayd6nGUT7sBE8ra/Zp2uCuiobHzJzgwVVFujkmTqIi1hOJ8lNT6yS pw2UonRcO1sxV+eUSvLQQGlXLDGdYR9Lh5X7lgLqMMeDe3ejYLbd9fWxJD3+QotAekYD LwZw== X-Gm-Message-State: AIkVDXLc4QurR+g3SWd78nQAUhZsQsjwfWsf3p8vJgjiH6TS5sCpE74Koqj5B7jV616aVW99NNVi7gLtI59s5A== X-Received: by 10.202.87.5 with SMTP id l5mr9254445oib.17.1482169256861; Mon, 19 Dec 2016 09:40:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.26.9 with HTTP; Mon, 19 Dec 2016 09:40:56 -0800 (PST) In-Reply-To: <1BDDB9BA-E712-4DC8-9194-A16DF97F84D1@iii.ca> References: <148186064804.24550.3460112022117949321.idtracker@ietfa.amsl.com> <9E288F8F-BD52-49D0-83B2-472F1B223127@nostrum.com> <50a163d3-0ca0-fdd0-7cb8-b09de0a5a5e2@joelhalpern.com> <1BDDB9BA-E712-4DC8-9194-A16DF97F84D1@iii.ca> From: Mary Barnes Date: Mon, 19 Dec 2016 11:40:56 -0600 Message-ID: To: Cullen Jennings Content-Type: multipart/alternative; boundary=001a113df4560d68da0544066c7b Archived-At: Cc: DISPATCH , Ben Campbell , Joel Halpern , IETF , draft-mohali-dispatch-cause-for-service-number.all@ietf.org Subject: Re: [dispatch] Review of draft-mohali-dispatch-cause-for-service-number-12 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 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 Dec 2016 17:40:59 -0000 --001a113df4560d68da0544066c7b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Dec 19, 2016 at 11:11 AM, Cullen Jennings wrote: > > > On Dec 15, 2016, at 10:07 PM, Joel M. Halpern > wrote: > > > > At this point I will defer to the relevant ADs. > > +1 on that :-) > > > As far as I can tell, although the entry was created by an Informationa= l > RFC, the registry still claims that it is standards track. > > And since this document is defining behavior, it behaves more like a > standards track document than an Informational one. > > > > But it is up to you folks. In teh end, all I can do is raise the > question, not decide it :-) > > So the registry takes PS to change it. And by the current SIP rules, I > suspect (not sure) that an update to 4458 would also have to be PS. So > really not sure how one gets around this not being PS. > [MB] I don't have a problem to make this document PS, but then I think we need to revise 4458 as PS (in which case I hope we don't reopen the can of worms around that one as it's something that I don't think we'd approve today). [/MB] > > > > > Yours, > > Joel > > > > On 12/15/16 11:51 PM, Ben Campbell wrote: > >> > >>> On Dec 15, 2016, at 10:35 PM, Joel M. Halpern > wrote: > >>> > >>> I see your point about this adding a value to the entry created by RF= C > 4458. > >>> Is there a reason this can not simply be PS? The fact that 4458 is > Informational does not, as far as I can tell, justify continuing the > error. While this is for a 3GPP usage, it appears to have been reviewed = by > the Dispatch WG sufficiently to justify PS. > >>> One could argue that there is a down-ref issue, > >>> but the fact that the field is in a standards-track required registry > would seem to make that a moot point. > >>> > >> > >> Do you think it makes sense to make some new values for =E2=80=9Ccause= =E2=80=9D into a > proposed standard when =E2=80=9Ccause=E2=80=9D itself is informational? = That seems like a > pretty big downref issue, as such issues go. (For the record, I could be > convinced to re-run this LC as PS, but I suspect that would lead to > objections in the opposite direction.) > >> > >> Right now, the situation is a standards-action registry with a > informational entry. That=E2=80=99s clearly broken, but I=E2=80=99m not s= ure that _this_ > draft is the place to fix it. > >> > >> Also, if it makes any difference=E2=80=94even there there was discussi= on in > dispatch, this is not a dispatch work item. > >> > >>> Yours, > >>> Joel > >>> > >>> PS: It would seem that WG discussion of that sort is something we > would like to see in Shepherd writeups. > >> > >> There=E2=80=99s two paragraphs on the subject in section (1) of the sh= epherd > writeup :-) (but it wasn=E2=80=99t a working group discussion per se.) > >> > >> Thanks! > >> > >> Ben. > >> > >>> > >>> On 12/15/16 11:28 PM, Ben Campbell wrote: > >>>> Hi Joel, > >>>> > >>>> Thanks for the comments. There has been a fair amount of discussion > >>>> about the status of the draft. The situation is clearly not optimal, > and > >>>> I welcome input on how to straighten it out. > >>>> > >>>> The rational so far has been that this draft updates RFC 4588, which > is > >>>> informational. It adds some additional values and related semantics > for > >>>> the "cause" parameter from 4588. It does not register new parameters= ; > >>>> rather it adds itself as a reference in the existing "cause" > >>>> registration. This is mainly a courtesy to readers. (There is no > >>>> sub-registry for "cause" parameter values.) We might could get by > >>>> without that change, since in a perfect world people following the > IANA > >>>> reference to 4588 would notice the "Updated by..." tag. > >>>> > >>>> The gotcha is that RFC 4588 would not be possible as an informationa= l > >>>> today; it would not have standing to register the "cause" parameter. > But > >>>> at the time it was published, there was a lack of clarity around the > >>>> "standards action" policy for the SIP URI parameters registry. Makin= g > >>>> the new values from _this_ draft standards track, when the parameter > >>>> itself is not, doesn't seem appropriate. We had some discussion abou= t > >>>> whether we should promote 4588 to PS, but there was not consensus to > do > >>>> so when it was published, and I don't see reason to expect that to > have > >>>> changed. > >>>> > >>>> This draft is primarily intended to meet a need in 3GPP, where I > >>>> understand they are effectively already doing this. Would it help to > >>>> more tightly scope this as "Here's something 3GPP is doing..." rathe= r > >>>> than as a general mechanism? > >>>> > >>>> Thanks! > >>>> > >>>> Ben. > >>>> > >>>> On 15 Dec 2016, at 21:57, Joel Halpern wrote: > >>>> > >>>>> Reviewer: Joel Halpern > >>>>> Review result: Ready with Issues > >>>>> > >>>>> Major: > >>>>> This document defines a new code for use in SIP, and specifies ne= w > >>>>> behavior both for the code itself and for its use in history-info. = I > >>>>> am thus confused as to how this can be an informational RFC. It > looks > >>>>> like it either Proposed Standard or experimental. Yes, I see that > RFC > >>>>> 4458, which this updates is Informational. But just because we did > it > >>>>> wrong before does not make that behavior correct now. In addition = to > >>>>> my understanding of the roles of different RFCs, I note that RFC 39= 69 > >>>>> and the IANA registry both state that this assignment must be made = by > >>>>> a standards track RFC. > >>>>> > >>>>> Minor: > >>>>> Given our emphasis on IPv6 over IPv4, would it not make sense for > >>>>> the examples to use IPv6 addresses? (Inspired by the Id-Nits alert= .) > >> > >> > > > > --001a113df4560d68da0544066c7b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Dec 19, 2016 at 11:11 AM, Cullen Jennings <= ;fluffy@iii.ca> wrote:

> On Dec 15, 2016, at 10:07 PM, Joel M. Halpern <jmh@joelhalpern.com> wrote:
>
> At this point I will defer to the relevant ADs.

+1 on that :-)

> As far as I can tell, although the entry was created by an Information= al RFC, the registry still claims that it is standards track.
> And since this document is defining behavior, it behaves more like a s= tandards track document than an Informational one.
>
> But it is up to you folks.=C2=A0 In teh end, all I can do is raise the= question, not decide it :-)

So the registry takes PS to change it. And by the current SIP rules,= I suspect (not sure) that an update to 4458 would also have to be PS. So r= eally not sure how one gets around this not being PS.
= [MB] I don't have a problem to make this document PS, but then I think = we need to revise 4458 as PS (in which case I hope we don't reopen the = can of worms around that one as it's something that I don't think w= e'd approve today). [/MB]=C2=A0



>
> Yours,
> Joel
>
> On 12/15/16 11:51 PM, Ben Campbell wrote:
>>
>>> On Dec 15, 2016, at 10:35 PM, Joel M. Halpern <jmh@joelhalpern.com> wrote:
>>>
>>> I see your point about this adding a value to the entry create= d by RFC 4458.
>>> Is there a reason this can not simply be PS?=C2=A0 The fact th= at 4458 is Informational does not, as far as I can tell, justify continuing= the error.=C2=A0 While this is for a 3GPP usage, it appears to have been r= eviewed by the Dispatch WG sufficiently to justify PS.
>>> One could argue that there is a down-ref issue,
>>> but the fact that the field is in a standards-track required r= egistry would seem to make that a moot point.
>>>
>>
>> Do you think it makes sense to make some new values for =E2=80=9Cc= ause=E2=80=9D into a proposed standard when =E2=80=9Ccause=E2=80=9D itself = is informational?=C2=A0 That seems like a pretty big downref issue, as such= issues go. (For the record, I could be convinced to re-run this LC as PS, = but I suspect that would lead to objections in the opposite direction.)
>>
>> Right now, the situation is a standards-action registry with a inf= ormational entry. That=E2=80=99s clearly broken, but I=E2=80=99m not sure t= hat _this_ draft is the place to fix it.
>>
>> Also, if it makes any difference=E2=80=94even there there was disc= ussion in dispatch, this is not a dispatch work item.
>>
>>> Yours,
>>> Joel
>>>
>>> PS: It would seem that WG discussion of that sort is something= we would like to see in Shepherd writeups.
>>
>> There=E2=80=99s two paragraphs on the subject in section (1) of th= e shepherd writeup :-)=C2=A0 (but it wasn=E2=80=99t a working group discuss= ion per se.)
>>
>> Thanks!
>>
>> Ben.
>>
>>>
>>> On 12/15/16 11:28 PM, Ben Campbell wrote:
>>>> Hi Joel,
>>>>
>>>> Thanks for the comments. There has been a fair amount of d= iscussion
>>>> about the status of the draft. The situation is clearly no= t optimal, and
>>>> I welcome input on how to straighten it out.
>>>>
>>>> The rational so far has been that this draft updates RFC 4= 588, which is
>>>> informational. It adds some additional values and related = semantics for
>>>> the "cause" parameter from 4588. It does not reg= ister new parameters;
>>>> rather it adds itself as a reference in the existing "= ;cause"
>>>> registration. This is mainly a courtesy to readers. (There= is no
>>>> sub-registry for "cause" parameter values.) We m= ight could get by
>>>> without that change, since in a perfect world people follo= wing the IANA
>>>> reference to 4588 would notice the "Updated by...&quo= t; tag.
>>>>
>>>> The gotcha is that RFC 4588 would not be possible as an in= formational
>>>> today; it would not have standing to register the "ca= use" parameter. But
>>>> at the time it was published, there was a lack of clarity = around the
>>>> "standards action" policy for the SIP URI parame= ters registry. Making
>>>> the new values from _this_ draft standards track, when the= parameter
>>>> itself is not, doesn't seem appropriate. We had some d= iscussion about
>>>> whether we should promote 4588 to PS, but there was not co= nsensus to do
>>>> so when it was published, and I don't see reason to ex= pect that to have
>>>> changed.
>>>>
>>>> This draft is primarily intended to meet a need in 3GPP, w= here I
>>>> understand they are effectively already doing this. Would = it help to
>>>> more tightly scope this as "Here's something 3GPP= is doing..." rather
>>>> than as a general mechanism?
>>>>
>>>> Thanks!
>>>>
>>>> Ben.
>>>>
>>>> On 15 Dec 2016, at 21:57, Joel Halpern wrote:
>>>>
>>>>> Reviewer: Joel Halpern
>>>>> Review result: Ready with Issues
>>>>>
>>>>> Major:
>>>>>=C2=A0 =C2=A0This document defines a new code for use i= n SIP, and specifies new
>>>>> behavior both for the code itself and for its use in h= istory-info.=C2=A0 I
>>>>> am thus confused as to how this can be an informationa= l RFC.=C2=A0 It looks
>>>>> like it either Proposed Standard or experimental.=C2= =A0 Yes, I see that RFC
>>>>> 4458, which this updates is Informational.=C2=A0 But j= ust because we did it
>>>>> wrong before does not make that behavior correct now.= =C2=A0 In addition to
>>>>> my understanding of the roles of different RFCs, I not= e that RFC 3969
>>>>> and the IANA registry both state that this assignment = must be made by
>>>>> a standards track RFC.
>>>>>
>>>>> Minor:
>>>>>=C2=A0 Given our emphasis on IPv6 over IPv4, would it n= ot make sense for
>>>>> the examples to use IPv6 addresses?=C2=A0 (Inspired by= the Id-Nits alert.)
>>
>>
>


--001a113df4560d68da0544066c7b-- From nobody Mon Dec 19 10:22:45 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C5EC1295A2; Mon, 19 Dec 2016 10:22:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5 X-Spam-Level: X-Spam-Status: No, score=-5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PLQG1RGuMw2h; Mon, 19 Dec 2016 10:22:40 -0800 (PST) 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 2E026129583; Mon, 19 Dec 2016 10:22:40 -0800 (PST) Received: from [10.0.1.39] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id uBJIMcKF051215 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 19 Dec 2016 12:22:39 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.39] From: "Ben Campbell" To: marianne.mohali@orange.com Date: Mon, 19 Dec 2016 12:22:38 -0600 Message-ID: In-Reply-To: <26405_1482168677_58581965_26405_11893_1_8B970F90C584EA4E97D5BAAC9172DBB81C884468@OPEXCLILMA4.corporate.adroot.infra.ftgroup> References: <148186064804.24550.3460112022117949321.idtracker@ietfa.amsl.com> <9E288F8F-BD52-49D0-83B2-472F1B223127@nostrum.com> <50a163d3-0ca0-fdd0-7cb8-b09de0a5a5e2@joelhalpern.com> <1BDDB9BA-E712-4DC8-9194-A16DF97F84D1@iii.ca> <26405_1482168677_58581965_26405_11893_1_8B970F90C584EA4E97D5BAAC9172DBB81C884468@OPEXCLILMA4.corporate.adroot.infra.ftgroup> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailer: MailMate (1.9.6r5318) Archived-At: Cc: DISPATCH , Joel Halpern , IETF , Cullen Jennings , "draft-mohali-dispatch-cause-for-service-number.all@ietf.org" Subject: Re: [dispatch] Review of draft-mohali-dispatch-cause-for-service-number-12 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 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 Dec 2016 18:22:42 -0000 Hi, Am I correct in assuming that you would intend the merged draft as PS? = If so, there's no _functional_ difference between that and promoting = 4458 to PS. It seems to me that a key issue in this discussion is about = whether it would be _necessary_ and _reasonable_ to promote 4458 (or the = mechanism therein) in order to make this draft PS. Given that this draft depends on the mechanism in RFC 4458, promoting it = to PS and not also promoting 4458 would create a downref. While the IESG = can approve downrefs, I'm not sure it would make sense to approve this = particular downref unless people already think 4458 is mature enough to = promote. (I have my doubts that they do, based on the comment from Mary = and offline comments from others.) Thanks, Ben. On 19 Dec 2016, at 11:31, marianne.mohali@orange.com wrote: > Hi, > > If I can suggest an alternative: to make this document obsolete = > RFC4458 (adding RFC4458 content) with the argument that RFC4458 was = > informational but because it defined SIP protocol element and = > procedures, it is obsoleted to align with IETF rules and IANA = > registration of this parameter with no technical modification. The = > justification is not really strong but it would correct the current = > situation. > > BR, > Marianne > > -----Message d'origine----- > De=C2=A0: Cullen Jennings [mailto:fluffy@iii.ca] > Envoy=C3=A9=C2=A0: lundi 19 d=C3=A9cembre 2016 18:11 > =C3=80=C2=A0: Joel Halpern > Cc=C2=A0: Ben Campbell; DISPATCH; IETF; = > draft-mohali-dispatch-cause-for-service-number.all@ietf.org > Objet=C2=A0: Re: Review of = > draft-mohali-dispatch-cause-for-service-number-12 > > >> On Dec 15, 2016, at 10:07 PM, Joel M. Halpern = >> wrote: >> >> At this point I will defer to the relevant ADs. > > +1 on that :-) > >> As far as I can tell, although the entry was created by an = >> Informational RFC, the registry still claims that it is standards = >> track. >> And since this document is defining behavior, it behaves more like a = >> standards track document than an Informational one. >> >> But it is up to you folks. In teh end, all I can do is raise the >> question, not decide it :-) > > So the registry takes PS to change it. And by the current SIP rules, I = > suspect (not sure) that an update to 4458 would also have to be PS. So = > really not sure how one gets around this not being PS. > > >> >> Yours, >> Joel >> >> On 12/15/16 11:51 PM, Ben Campbell wrote: >>> >>>> On Dec 15, 2016, at 10:35 PM, Joel M. Halpern = >>>> wrote: >>>> >>>> I see your point about this adding a value to the entry created by = >>>> RFC 4458. >>>> Is there a reason this can not simply be PS? The fact that 4458 is = >>>> Informational does not, as far as I can tell, justify continuing = >>>> the error. While this is for a 3GPP usage, it appears to have been = >>>> reviewed by the Dispatch WG sufficiently to justify PS. >>>> One could argue that there is a down-ref issue, but the fact that >>>> the field is in a standards-track required registry would seem to = >>>> make that a moot point. >>>> >>> >>> Do you think it makes sense to make some new values for =E2=80=9Ccaus= e=E2=80=9D = >>> into >>> a proposed standard when =E2=80=9Ccause=E2=80=9D itself is informatio= nal? That = >>> seems >>> like a pretty big downref issue, as such issues go. (For the record, >>> I could be convinced to re-run this LC as PS, but I suspect that >>> would lead to objections in the opposite direction.) >>> >>> Right now, the situation is a standards-action registry with a = >>> informational entry. That=E2=80=99s clearly broken, but I=E2=80=99m n= ot sure = >>> that _this_ draft is the place to fix it. >>> >>> Also, if it makes any difference=E2=80=94even there there was discuss= ion = >>> in dispatch, this is not a dispatch work item. >>> >>>> Yours, >>>> Joel >>>> >>>> PS: It would seem that WG discussion of that sort is something we = >>>> would like to see in Shepherd writeups. >>> >>> There=E2=80=99s two paragraphs on the subject in section (1) of the = >>> shepherd >>> writeup :-) (but it wasn=E2=80=99t a working group discussion per se= =2E) >>> >>> Thanks! >>> >>> Ben. >>> >>>> >>>> On 12/15/16 11:28 PM, Ben Campbell wrote: >>>>> Hi Joel, >>>>> >>>>> Thanks for the comments. There has been a fair amount of = >>>>> discussion >>>>> about the status of the draft. The situation is clearly not >>>>> optimal, and I welcome input on how to straighten it out. >>>>> >>>>> The rational so far has been that this draft updates RFC 4588, >>>>> which is informational. It adds some additional values and related >>>>> semantics for the "cause" parameter from 4588. It does not = >>>>> register >>>>> new parameters; rather it adds itself as a reference in the = >>>>> existing "cause" >>>>> registration. This is mainly a courtesy to readers. (There is no >>>>> sub-registry for "cause" parameter values.) We might could get by >>>>> without that change, since in a perfect world people following the >>>>> IANA reference to 4588 would notice the "Updated by..." tag. >>>>> >>>>> The gotcha is that RFC 4588 would not be possible as an >>>>> informational today; it would not have standing to register the >>>>> "cause" parameter. But at the time it was published, there was a >>>>> lack of clarity around the "standards action" policy for the SIP >>>>> URI parameters registry. Making the new values from _this_ draft >>>>> standards track, when the parameter itself is not, doesn't seem >>>>> appropriate. We had some discussion about whether we should = >>>>> promote >>>>> 4588 to PS, but there was not consensus to do so when it was >>>>> published, and I don't see reason to expect that to have changed. >>>>> >>>>> This draft is primarily intended to meet a need in 3GPP, where I >>>>> understand they are effectively already doing this. Would it help >>>>> to more tightly scope this as "Here's something 3GPP is doing..." >>>>> rather than as a general mechanism? >>>>> >>>>> Thanks! >>>>> >>>>> Ben. >>>>> >>>>> On 15 Dec 2016, at 21:57, Joel Halpern wrote: >>>>> >>>>>> Reviewer: Joel Halpern >>>>>> Review result: Ready with Issues >>>>>> >>>>>> Major: >>>>>> This document defines a new code for use in SIP, and specifies >>>>>> new behavior both for the code itself and for its use in >>>>>> history-info. I am thus confused as to how this can be an >>>>>> informational RFC. It looks like it either Proposed Standard or >>>>>> experimental. Yes, I see that RFC 4458, which this updates is >>>>>> Informational. But just because we did it wrong before does not >>>>>> make that behavior correct now. In addition to my understanding >>>>>> of the roles of different RFCs, I note that RFC 3969 and the IANA >>>>>> registry both state that this assignment must be made by a = >>>>>> standards track RFC. >>>>>> >>>>>> Minor: >>>>>> Given our emphasis on IPv6 over IPv4, would it not make sense = >>>>>> for >>>>>> the examples to use IPv6 addresses? (Inspired by the Id-Nits >>>>>> alert.) >>> >>> >> > > > _______________________________________________________________________= __________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations = > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = > recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les = > messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, = > deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or = > privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and = > delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have = > been modified, changed or falsified. > Thank you. From nobody Mon Dec 19 10:31:43 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBA081295A7; Mon, 19 Dec 2016 10:31:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5 X-Spam-Level: X-Spam-Status: No, score=-5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8W7q7oS_Zz-f; Mon, 19 Dec 2016 10:31:36 -0800 (PST) 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 237A312959C; Mon, 19 Dec 2016 10:31:36 -0800 (PST) Received: from [10.0.1.39] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id uBJIVY8G052035 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 19 Dec 2016 12:31:35 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.39] From: "Ben Campbell" To: "Cullen Jennings" Date: Mon, 19 Dec 2016 12:31:34 -0600 Message-ID: In-Reply-To: <1BDDB9BA-E712-4DC8-9194-A16DF97F84D1@iii.ca> References: <148186064804.24550.3460112022117949321.idtracker@ietfa.amsl.com> <9E288F8F-BD52-49D0-83B2-472F1B223127@nostrum.com> <50a163d3-0ca0-fdd0-7cb8-b09de0a5a5e2@joelhalpern.com> <1BDDB9BA-E712-4DC8-9194-A16DF97F84D1@iii.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.6r5318) Archived-At: Cc: DISPATCH , Joel Halpern , IETF , draft-mohali-dispatch-cause-for-service-number.all@ietf.org Subject: Re: [dispatch] Review of draft-mohali-dispatch-cause-for-service-number-12 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 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 Dec 2016 18:31:38 -0000 On 19 Dec 2016, at 11:11, Cullen Jennings wrote: >> On Dec 15, 2016, at 10:07 PM, Joel M. Halpern >> wrote: >> >> At this point I will defer to the relevant ADs. > > +1 on that :-) :-) > >> As far as I can tell, although the entry was created by an >> Informational RFC, the registry still claims that it is standards >> track. >> And since this document is defining behavior, it behaves more like a >> standards track document than an Informational one. >> >> But it is up to you folks. In teh end, all I can do is raise the >> question, not decide it :-) > > So the registry takes PS to change it. To reiterate a previous comment on the thread: This draft does not add an entry to the registry, rather it adds a reference to an existing entry. The only point of the registry change is to make it convenient for implementors to discover that this draft updates 4458, which registered the entry in the first place. I'm not convinced that's completely necessary. But it might make sense to relax the standards action for this particular entry for historical reasons. (Recognizing that the SIP URI parameter registry is messed up, also for "historical reasons".) > And by the current SIP rules, I suspect (not sure) that an update to > 4458 would also have to be PS. So really not sure how one gets around > this not being PS. I think this is the important decision to make. Setting the draft status based on the registration policy is an exercise in dog-wagging. > > >> >> Yours, >> Joel >> >> On 12/15/16 11:51 PM, Ben Campbell wrote: >>> >>>> On Dec 15, 2016, at 10:35 PM, Joel M. Halpern >>>> wrote: >>>> >>>> I see your point about this adding a value to the entry created by >>>> RFC 4458. >>>> Is there a reason this can not simply be PS? The fact that 4458 is >>>> Informational does not, as far as I can tell, justify continuing >>>> the error. While this is for a 3GPP usage, it appears to have been >>>> reviewed by the Dispatch WG sufficiently to justify PS. >>>> One could argue that there is a down-ref issue, >>>> but the fact that the field is in a standards-track required >>>> registry would seem to make that a moot point. >>>> >>> >>> Do you think it makes sense to make some new values for “cause” >>> into a proposed standard when “cause” itself is informational? >>> That seems like a pretty big downref issue, as such issues go. (For >>> the record, I could be convinced to re-run this LC as PS, but I >>> suspect that would lead to objections in the opposite direction.) >>> >>> Right now, the situation is a standards-action registry with a >>> informational entry. That’s clearly broken, but I’m not sure >>> that _this_ draft is the place to fix it. >>> >>> Also, if it makes any difference—even there there was discussion >>> in dispatch, this is not a dispatch work item. >>> >>>> Yours, >>>> Joel >>>> >>>> PS: It would seem that WG discussion of that sort is something we >>>> would like to see in Shepherd writeups. >>> >>> There’s two paragraphs on the subject in section (1) of the >>> shepherd writeup :-) (but it wasn’t a working group discussion >>> per se.) >>> >>> Thanks! >>> >>> Ben. >>> >>>> >>>> On 12/15/16 11:28 PM, Ben Campbell wrote: >>>>> Hi Joel, >>>>> >>>>> Thanks for the comments. There has been a fair amount of >>>>> discussion >>>>> about the status of the draft. The situation is clearly not >>>>> optimal, and >>>>> I welcome input on how to straighten it out. >>>>> >>>>> The rational so far has been that this draft updates RFC 4588, >>>>> which is >>>>> informational. It adds some additional values and related >>>>> semantics for >>>>> the "cause" parameter from 4588. It does not register new >>>>> parameters; >>>>> rather it adds itself as a reference in the existing "cause" >>>>> registration. This is mainly a courtesy to readers. (There is no >>>>> sub-registry for "cause" parameter values.) We might could get by >>>>> without that change, since in a perfect world people following the >>>>> IANA >>>>> reference to 4588 would notice the "Updated by..." tag. >>>>> >>>>> The gotcha is that RFC 4588 would not be possible as an >>>>> informational >>>>> today; it would not have standing to register the "cause" >>>>> parameter. But >>>>> at the time it was published, there was a lack of clarity around >>>>> the >>>>> "standards action" policy for the SIP URI parameters registry. >>>>> Making >>>>> the new values from _this_ draft standards track, when the >>>>> parameter >>>>> itself is not, doesn't seem appropriate. We had some discussion >>>>> about >>>>> whether we should promote 4588 to PS, but there was not consensus >>>>> to do >>>>> so when it was published, and I don't see reason to expect that to >>>>> have >>>>> changed. >>>>> >>>>> This draft is primarily intended to meet a need in 3GPP, where I >>>>> understand they are effectively already doing this. Would it help >>>>> to >>>>> more tightly scope this as "Here's something 3GPP is doing..." >>>>> rather >>>>> than as a general mechanism? >>>>> >>>>> Thanks! >>>>> >>>>> Ben. >>>>> >>>>> On 15 Dec 2016, at 21:57, Joel Halpern wrote: >>>>> >>>>>> Reviewer: Joel Halpern >>>>>> Review result: Ready with Issues >>>>>> >>>>>> Major: >>>>>> This document defines a new code for use in SIP, and specifies >>>>>> new >>>>>> behavior both for the code itself and for its use in >>>>>> history-info. I >>>>>> am thus confused as to how this can be an informational RFC. It >>>>>> looks >>>>>> like it either Proposed Standard or experimental. Yes, I see >>>>>> that RFC >>>>>> 4458, which this updates is Informational. But just because we >>>>>> did it >>>>>> wrong before does not make that behavior correct now. In >>>>>> addition to >>>>>> my understanding of the roles of different RFCs, I note that RFC >>>>>> 3969 >>>>>> and the IANA registry both state that this assignment must be >>>>>> made by >>>>>> a standards track RFC. >>>>>> >>>>>> Minor: >>>>>> Given our emphasis on IPv6 over IPv4, would it not make sense >>>>>> for >>>>>> the examples to use IPv6 addresses? (Inspired by the Id-Nits >>>>>> alert.) >>> >>> >> From nobody Mon Dec 19 22:58:18 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4925129CCB for ; Mon, 19 Dec 2016 22:58:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yandex.ru 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 2Q0eJeD8H7e8 for ; Mon, 19 Dec 2016 22:58:15 -0800 (PST) Received: from forward15o.cmail.yandex.net (forward15o.cmail.yandex.net [37.9.109.212]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D767912953A for ; Mon, 19 Dec 2016 22:58:14 -0800 (PST) Received: from mxback10j.mail.yandex.net (mxback10j.mail.yandex.net [5.45.198.24]) by forward15o.cmail.yandex.net (Yandex) with ESMTP id 4C4FE21947 for ; Tue, 20 Dec 2016 09:58:12 +0300 (MSK) Received: from web43j.yandex.ru (web43j.yandex.ru [5.45.198.146]) by mxback10j.mail.yandex.net (nwsmtp/Yandex) with ESMTP id QlktjX58o6-wCIC5bSM; Tue, 20 Dec 2016 09:58:12 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1482217092; bh=mLJBfNbBfTNtD5LxyZ1w9GcuqmYAER//1fE0n7SzR64=; h=From:To:Subject:Message-Id:Date; b=bf88SD5LAGTWbbQ1ZQurNbSWzG4VxZ0DQikJIiWnovaIB3pvV0128ArmZYDoCI9Xf euoJEIhtN0JiFs1A6LwW/wKOPcicK3GFL+rDjnUatzjf5ApO7DF4cw3YK16EFRgQ+l 8R7dHxg5+JmWCfzTLvIDlsym3ga2kPZ3EdKd35r0= Authentication-Results: mxback10j.mail.yandex.net; dkim=pass header.i=@yandex.ru Received: by web43j.yandex.ru with HTTP; Tue, 20 Dec 2016 09:58:12 +0300 From: Anton Tveretin To: DISPATCH list MIME-Version: 1.0 Message-Id: <830721482217092@web43j.yandex.ru> X-Mailer: Yamail [ http://yandex.ru ] 5.0 Date: Tue, 20 Dec 2016 11:58:12 +0500 Content-Transfer-Encoding: 7bit Content-Type: text/plain Archived-At: Subject: Re: [dispatch] Review of draft-mohali-dispatch-cause-for-service-number-12 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2016 06:58:16 -0000 My 2 cents. AFAIK originally it was common to promote a published RFC; the RFC would start as a PS, then - as independent implementations appear - get STD status. So nothing is wrong with assigning RFC 4458 STD. Indeed, keeping it STD should be better to avoid implementation conflicts. From nobody Tue Dec 20 07:28:30 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0956129A75 for ; Tue, 20 Dec 2016 07:28:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5 X-Spam-Level: X-Spam-Status: No, score=-5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ywXqRb_oa8zD for ; Tue, 20 Dec 2016 07:28:27 -0800 (PST) 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 D0367129A20 for ; Tue, 20 Dec 2016 07:28:27 -0800 (PST) Received: from [10.0.1.39] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id uBKFSPTa064151 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 20 Dec 2016 09:28:27 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.39] From: "Ben Campbell" To: "Anton Tveretin" Date: Tue, 20 Dec 2016 09:28:26 -0600 Message-ID: <68E7FF87-0AB5-498D-8787-034D4CE69346@nostrum.com> In-Reply-To: <830721482217092@web43j.yandex.ru> References: <830721482217092@web43j.yandex.ru> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5318) Archived-At: Cc: DISPATCH list Subject: Re: [dispatch] Review of draft-mohali-dispatch-cause-for-service-number-12 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2016 15:28:29 -0000 On 20 Dec 2016, at 0:58, Anton Tveretin wrote: > My 2 cents. AFAIK originally it was common to promote a published RFC; > the RFC would start as a PS, then - as independent implementations > appear - get STD status. > So nothing is wrong with assigning RFC 4458 STD. Indeed, keeping it > STD should be better to avoid implementation conflicts. In this case we would be talking about Informational to PS. We certainly have the ability to do that, if we think the RFC in question is sufficiently mature. That's an open question for RFC 4458. From nobody Tue Dec 20 09:16:20 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E71E1129B80 for ; Tue, 20 Dec 2016 09:16:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.8 X-Spam-Level: X-Spam-Status: No, score=-5.8 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, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 2D7kmHFq9oms for ; Tue, 20 Dec 2016 09:16:18 -0800 (PST) Received: from resqmta-po-02v.sys.comcast.net (resqmta-po-02v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:161]) (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 00EA9129514 for ; Tue, 20 Dec 2016 09:16:15 -0800 (PST) Received: from resomta-po-05v.sys.comcast.net ([96.114.154.229]) by resqmta-po-02v.sys.comcast.net with SMTP id JNzgcXWiooagNJO1Ocx7ns; Tue, 20 Dec 2016 17:16:14 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1482254174; bh=c0jRT74W94kkqS9VF4uhE2RpARVudFXdlvNImcF5WG0=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=V4tFICkdiB2/D5TrF766TpgytCZdqbrISVfJzwd28NrjxhSoXLhAlDciIJFnced2y cm52ymrsUZB+ed0zAF0TpDXdqkGeQHPyq2ZcIt8SbgdLzJpqhPxtK8nFv26DGwtpjo pg0R49W62DBvndCX7ffTeXe/wSDRLFSbcHZnKOAnjRA7c2x+CW0pe5Bv3nVUWZlP0q aR69kkMisXNt7aTeMhOZMpIhiy9cIxat9glqdebt/G0Itd3ZkDDlYN843n5DVx4WsR hV5lqlPQlNJJYePZowbIKWWSfaANEvgcPDxxDpL7P0D93ZU7QfIToG4f6ea7wymPoT DEwuicEzz2x6g== Received: from [192.168.1.110] ([73.186.127.100]) by resomta-po-05v.sys.comcast.net with SMTP id JO1NcazRFzYm9JO1Oc7O16; Tue, 20 Dec 2016 17:16:14 +0000 To: dispatch@ietf.org References: <830721482217092@web43j.yandex.ru> <68E7FF87-0AB5-498D-8787-034D4CE69346@nostrum.com> From: Paul Kyzivat Message-ID: <30c4112c-55c6-ac98-78e0-f5e76c6c1e64@comcast.net> Date: Tue, 20 Dec 2016 12:16:13 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <68E7FF87-0AB5-498D-8787-034D4CE69346@nostrum.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfAZvU1CoMzMAYIAKqir1DOOseqsll0ePjLIiIWprlApv3sT2bpn0ANJPYzIf194h7pipbf4BDy2Bi/rognPAR7lHBLITO8Ou9jyNbUgCwzfgXt7SRBRS 7D1KZokhq/UR3RQsno504G3P0TWIMjVUF7+to47na1RnE3GylXtgj9l/uHC93+WWqACJn3XXxGJ65w== Archived-At: Subject: Re: [dispatch] Review of draft-mohali-dispatch-cause-for-service-number-12 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2016 17:16:20 -0000 On 12/20/16 10:28 AM, Ben Campbell wrote: > On 20 Dec 2016, at 0:58, Anton Tveretin wrote: > >> My 2 cents. AFAIK originally it was common to promote a published RFC; >> the RFC would start as a PS, then - as independent implementations >> appear - get STD status. >> So nothing is wrong with assigning RFC 4458 STD. Indeed, keeping it >> STD should be better to avoid implementation conflicts. > > In this case we would be talking about Informational to PS. We certainly > have the ability to do that, if we think the RFC in question is > sufficiently mature. That's an open question for RFC 4458. AFAIK the distinction between "Informational" and "PS" is not a matter of maturity. An informational document can be very mature and still not deserve to be a PS. Isn't the distinction that one is describing the rules for normative behavior while the other is not? ISTM that reclassification needs to be justified on the basis that the original classification was in error. Thanks, Paul From nobody Tue Dec 20 14:49:45 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEA8E12960E; Tue, 20 Dec 2016 14:49:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5 X-Spam-Level: X-Spam-Status: No, score=-5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u2fVFZ4Nn4cp; Tue, 20 Dec 2016 14:49:39 -0800 (PST) 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 E16F1129432; Tue, 20 Dec 2016 14:49:38 -0800 (PST) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id uBKMnaSt005888 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 20 Dec 2016 16:49:38 -0600 (CST) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local To: Ben Campbell , Joel Halpern References: <148186064804.24550.3460112022117949321.idtracker@ietfa.amsl.com> <9E288F8F-BD52-49D0-83B2-472F1B223127@nostrum.com> From: Adam Roach Message-ID: <67748928-2d86-58d7-0cff-919470b67815@nostrum.com> Date: Tue, 20 Dec 2016 16:49:36 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <9E288F8F-BD52-49D0-83B2-472F1B223127@nostrum.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: gen-art@ietf.org, dispatch@ietf.org, ietf@ietf.org, draft-mohali-dispatch-cause-for-service-number.all@ietf.org Subject: Re: [dispatch] Review of draft-mohali-dispatch-cause-for-service-number-12 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2016 22:49:40 -0000 On 12/15/16 22:28, Ben Campbell wrote: > The gotcha is that RFC 4588 would not be possible as an informational > today; it would not have standing to register the "cause" parameter. > But at the time it was published, there was a lack of clarity around > the "standards action" policy for the SIP URI parameters registry. I don't think that's true. We're talking about a registry established by RFC 3969, which says: "SIP and SIPS URI parameters and values for these parameters MUST be documented in a standards-track RFC in order to be registered by IANA." ...and... "For the purposes of this registry, the parameter for which IANA registration is requested MUST be defined by a standards-track RFC." These are not ambiguous statements. We just botched our communication with IANA. But I think we can do the right thing here without going back and fixing all of the issues with our ancestral documents. I mean, sure, maybe we should clean that up too, but I don't see the value in blocking new work on doing so. In terms of publishing draft-mohali-dispatch-cause-for-service-number, I think there are two reasonable paths forward: The first would be forming consensus that the two statements I quote from 3969 above -- and the reinforcing statement in 5727 -- were all incorrect, and that we want to explicitly (i.e., in a new document) reverse those statements and update the corresponding registration policy. Then, we publish -mohali- as informational.[1] The second would be implicitly accepting established consensus around this registry, and consequently changing -mohali- to PS. Rather than figuring out which of these is easier (clearly, the second is less work), I think the real question here is: do we think we got the registration policy for SIP URI parameters wrong? /a ____ [1] We *might* or might *not* also decide to then do something about RFC 4458 in this case, but that's a completely separate decision. From nobody Tue Dec 20 15:03:14 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48574129422; Tue, 20 Dec 2016 15:03:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5 X-Spam-Level: X-Spam-Status: No, score=-5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ai44zt_ZDbnX; Tue, 20 Dec 2016 15:03:09 -0800 (PST) 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 2BFCD129406; Tue, 20 Dec 2016 15:03:09 -0800 (PST) Received: from [10.0.1.39] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id uBKN37w2007123 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 20 Dec 2016 17:03:08 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.39] From: "Ben Campbell" To: "Adam Roach" Date: Tue, 20 Dec 2016 17:03:06 -0600 Message-ID: In-Reply-To: <67748928-2d86-58d7-0cff-919470b67815@nostrum.com> References: <148186064804.24550.3460112022117949321.idtracker@ietfa.amsl.com> <9E288F8F-BD52-49D0-83B2-472F1B223127@nostrum.com> <67748928-2d86-58d7-0cff-919470b67815@nostrum.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5318) Archived-At: Cc: dispatch@ietf.org, gen-art@ietf.org, Joel Halpern , ietf@ietf.org, draft-mohali-dispatch-cause-for-service-number.all@ietf.org Subject: Re: [dispatch] Review of draft-mohali-dispatch-cause-for-service-number-12 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2016 23:03:10 -0000 On 20 Dec 2016, at 16:49, Adam Roach wrote: > On 12/15/16 22:28, Ben Campbell wrote: >> The gotcha is that RFC 4588 would not be possible as an informational >> today; it would not have standing to register the "cause" parameter. >> But at the time it was published, there was a lack of clarity around >> the "standards action" policy for the SIP URI parameters registry. > > I don't think that's true. We're talking about a registry established > by RFC 3969, which says: > > "SIP and SIPS URI parameters and values for these parameters MUST be > documented in a standards-track RFC in order to be registered by > IANA." > > ...and... > > "For the purposes of this registry, the parameter for which IANA > registration is requested MUST be defined by a standards-track > RFC." > > These are not ambiguous statements. We just botched our communication > with IANA. For the record, I did not say the RFC was ambiguous. I said "we had a lack of clarity". I think having one policy listed in IANA and another in the RFC counts. I offer as evidence of said lack of clarity the fact that RAI got things wrong with 4458 (My typo of it as 4588 above upthread couldn't help, either) :-) > > But I think we can do the right thing here without going back and > fixing all of the issues with our ancestral documents. I mean, sure, > maybe we should clean that up too, but I don't see the value in > blocking new work on doing so. > > In terms of publishing draft-mohali-dispatch-cause-for-service-number, > I think there are two reasonable paths forward: > > The first would be forming consensus that the two statements I quote > from 3969 above -- and the reinforcing statement in 5727 -- were all > incorrect, and that we want to explicitly (i.e., in a new document) > reverse those statements and update the corresponding registration > policy. Then, we publish -mohali- as informational.[1] > > The second would be implicitly accepting established consensus around > this registry, and consequently changing -mohali- to PS. I think a potential third option is to consider whether -mohali- really needs to modify the registry. (I'm not saying it doesn't--I'm saying we should think about it.) > > Rather than figuring out which of these is easier (clearly, the second > is less work), I think the real question here is: do we think we got > the registration policy for SIP URI parameters wrong? > Keep in mind that the registry is not the only concern mentioned so far. Both 4458 and -mohali- define protocol. Reviewers have objected to that as well. From nobody Tue Dec 20 15:27:49 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26BD2129694; Tue, 20 Dec 2016 15:27:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.999 X-Spam-Level: X-Spam-Status: No, score=-4.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-3.1] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HBZKXcM4hV5H; Tue, 20 Dec 2016 15:27:47 -0800 (PST) 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 DAF73129437; Tue, 20 Dec 2016 15:27:46 -0800 (PST) Received: from unnumerable.local ([47.186.56.40]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id uBKNRjXp009257 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK); Tue, 20 Dec 2016 17:27:46 -0600 (CST) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [47.186.56.40] claimed to be unnumerable.local To: Ben Campbell , Adam Roach References: <148186064804.24550.3460112022117949321.idtracker@ietfa.amsl.com> <9E288F8F-BD52-49D0-83B2-472F1B223127@nostrum.com> <67748928-2d86-58d7-0cff-919470b67815@nostrum.com> From: Robert Sparks Message-ID: Date: Tue, 20 Dec 2016 17:27:45 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------94E9583D5F35954B6EB6B176" Archived-At: Cc: gen-art@ietf.org, dispatch@ietf.org, ietf@ietf.org, draft-mohali-dispatch-cause-for-service-number.all@ietf.org Subject: Re: [dispatch] Review of draft-mohali-dispatch-cause-for-service-number-12 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2016 23:27:48 -0000 This is a multi-part message in MIME format. --------------94E9583D5F35954B6EB6B176 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit I still think the shepherd's writeup caught this correctly: > draft-mohali-dispatch-service-number-translation > does not register a URI parameter; it just adds a reference > to an existing registration. The decision to keep these > documents informational is not intended to set precedent; > RFC 5727 remains the BCP for the SIP change process. I personally see no win in trying to force this document to be PS (and fixing the things in it, and in what 3gpp plans to do with it to let it fly as PS) or in changing the registry at this point. This has an odor, but it is not really making the world worse, and the energy that it would require from ours and the 3gpp communities to remove the odor does not strike me as the right place to make our investements. Hold your noses and let this go please. One more general comment inline below: RjS On 12/20/16 5:03 PM, Ben Campbell wrote: > On 20 Dec 2016, at 16:49, Adam Roach wrote: > >> On 12/15/16 22:28, Ben Campbell wrote: >>> The gotcha is that RFC 4588 would not be possible as an >>> informational today; it would not have standing to register the >>> "cause" parameter. But at the time it was published, there was a >>> lack of clarity around the "standards action" policy for the SIP URI >>> parameters registry. >> >> I don't think that's true. We're talking about a registry established >> by RFC 3969, which says: >> >> "SIP and SIPS URI parameters and values for these parameters MUST be >> documented in a standards-track RFC in order to be registered by >> IANA." >> >> ...and... >> >> "For the purposes of this registry, the parameter for which IANA >> registration is requested MUST be defined by a standards-track RFC." >> >> These are not ambiguous statements. We just botched our communication >> with IANA. > > For the record, I did not say the RFC was ambiguous. I said "we had a > lack of clarity". I think having one policy listed in IANA and another > in the RFC counts. I offer as evidence of said lack of clarity the > fact that RAI got things wrong with 4458 (My typo of it as 4588 above > upthread couldn't help, either) :-) >> >> But I think we can do the right thing here without going back and >> fixing all of the issues with our ancestral documents. I mean, sure, >> maybe we should clean that up too, but I don't see the value in >> blocking new work on doing so. >> >> In terms of publishing >> draft-mohali-dispatch-cause-for-service-number, I think there are two >> reasonable paths forward: >> >> The first would be forming consensus that the two statements I quote >> from 3969 above -- and the reinforcing statement in 5727 -- were all >> incorrect, and that we want to explicitly (i.e., in a new document) >> reverse those statements and update the corresponding registration >> policy. Then, we publish -mohali- as informational.[1] >> >> The second would be implicitly accepting established consensus around >> this registry, and consequently changing -mohali- to PS. > > I think a potential third option is to consider whether -mohali- > really needs to modify the registry. (I'm not saying it doesn't--I'm > saying we should think about it.) > >> >> Rather than figuring out which of these is easier (clearly, the >> second is less work), I think the real question here is: do we think >> we got the registration policy for SIP URI parameters wrong? >> > > Keep in mind that the registry is not the only concern mentioned so > far. Both 4458 and -mohali- define protocol. Reviewers have objected > to that as well. We have _MANY_ Informational documents that define protocol. That, by itself, is not the metric for "not Informational". --------------94E9583D5F35954B6EB6B176 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

I still think the shepherd's writeup caught this correctly:

   draft-mohali-dispatch-service-number-translation  
   does not register a URI parameter; it just adds a reference  
   to an existing registration. The decision to keep these  
   documents informational is not intended to set precedent; 
   RFC 5727 remains the BCP for the SIP change process.
I personally see no win in trying to force this document to be PS (and fixing the things in it, and in what 3gpp plans to do with it to let it fly as PS) or in changing the registry at this point. This has an odor, but it is not really making the world worse, and the energy that it would require from ours and the 3gpp communities to remove the odor does not strike me as the right place to make our investements.

Hold your noses and let this go please.

One more general comment inline below:

RjS

On 12/20/16 5:03 PM, Ben Campbell wrote:
On 20 Dec 2016, at 16:49, Adam Roach wrote:

On 12/15/16 22:28, Ben Campbell wrote:
The gotcha is that RFC 4588 would not be possible as an informational today; it would not have standing to register the "cause" parameter. But at the time it was published, there was a lack of clarity around the "standards action" policy for the SIP URI parameters registry.

I don't think that's true. We're talking about a registry established by RFC 3969, which says:

"SIP and SIPS URI parameters and values for these parameters MUST be
documented in a standards-track RFC in order to be registered by
IANA."

...and...

"For the purposes of this registry, the parameter for which IANA
registration is requested MUST be defined by a standards-track RFC."

These are not ambiguous statements. We just botched our communication with IANA.

For the record, I did not say the RFC was ambiguous. I said "we had a lack of clarity". I think having one policy listed in IANA and another in the RFC counts. I offer as evidence of said lack of clarity the fact that RAI got things wrong with 4458 (My typo of it as 4588 above upthread couldn't help, either) :-)

But I think we can do the right thing here without going back and fixing all of the issues with our ancestral documents. I mean, sure, maybe we should clean that up too, but I don't see the value in blocking new work on doing so.

In terms of publishing draft-mohali-dispatch-cause-for-service-number, I think there are two reasonable paths forward:

The first would be forming consensus that the two statements I quote from 3969 above -- and the reinforcing statement in 5727 -- were all incorrect, and that we want to explicitly (i.e., in a new document) reverse those statements and update the corresponding registration policy. Then, we publish -mohali- as informational.[1]

The second would be implicitly accepting established consensus around this registry, and consequently changing -mohali- to PS.

I think a potential third option is to consider whether -mohali- really needs to modify the registry. (I'm not saying it doesn't--I'm saying we should think about it.)


Rather than figuring out which of these is easier (clearly, the second is less work), I think the real question here is: do we think we got the registration policy for SIP URI parameters wrong?


Keep in mind that the registry is not the only concern mentioned so far. Both 4458 and -mohali- define protocol. Reviewers have objected to that as well.
We have _MANY_ Informational documents that define protocol. That, by itself, is not the metric for "not Informational".

--------------94E9583D5F35954B6EB6B176-- From nobody Tue Dec 20 15:49:05 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 681261296A9; Tue, 20 Dec 2016 15:49:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5 X-Spam-Level: X-Spam-Status: No, score=-5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0_ohmhOv4LKd; Tue, 20 Dec 2016 15:49:03 -0800 (PST) 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 4BEDC12960E; Tue, 20 Dec 2016 15:49:03 -0800 (PST) Received: from [10.0.1.39] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id uBKNn21r011135 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 20 Dec 2016 17:49:02 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.39] From: "Ben Campbell" To: "Robert Sparks" Date: Tue, 20 Dec 2016 17:49:01 -0600 Message-ID: In-Reply-To: References: <148186064804.24550.3460112022117949321.idtracker@ietfa.amsl.com> <9E288F8F-BD52-49D0-83B2-472F1B223127@nostrum.com> <67748928-2d86-58d7-0cff-919470b67815@nostrum.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5318) Archived-At: Cc: gen-art@ietf.org, dispatch@ietf.org, ietf@ietf.org, draft-mohali-dispatch-cause-for-service-number.all@ietf.org Subject: Re: [dispatch] Review of draft-mohali-dispatch-cause-for-service-number-12 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2016 23:49:04 -0000 On 20 Dec 2016, at 17:27, Robert Sparks wrote: > I still think the shepherd's writeup caught this correctly: > >> draft-mohali-dispatch-service-number-translation >> does not register a URI parameter; it just adds a reference >> to an existing registration. The decision to keep these >> documents informational is not intended to set precedent; >> RFC 5727 remains the BCP for the SIP change process. > > I personally see no win in trying to force this document to be PS (and > fixing the things in it, and in what 3gpp plans to do with it to let > it fly as PS) or in changing the registry at this point. This has an > odor, but it is not really making the world worse, and the energy that > it would require from ours and the 3gpp communities to remove the odor > does not strike me as the right place to make our investements. > > Hold your noses and let this go please. In case it has been unclear from my other comments, this is my preference as an individual as well. One thing for people to keep in mind is that, as mentioned in the quote above, all the registration change does is add this draft to the references for the entry that 4458 originally registered. Given that this draft updates 4458, that seems appropriate. The fact that 4458 registered that incorrectly is a problem we might fix someday, but that doesn't mean _this_ draft has to fix it. > > One more general comment inline below: > > RjS > [...] >> >> Keep in mind that the registry is not the only concern mentioned so >> far. Both 4458 and -mohali- define protocol. Reviewers have objected >> to that as well. > We have _MANY_ Informational documents that define protocol. That, by > itself, is not the metric for "not Informational". Would people find the informational status more palatable if the draft clarified that this is for 3GPP, and that we don't endorse it for other contexts? From nobody Wed Dec 21 00:11:46 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF92A1293F8 for ; Wed, 21 Dec 2016 00:11:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 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, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yandex.ru 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 6_WjI28cRPrc for ; Wed, 21 Dec 2016 00:11:42 -0800 (PST) Received: from forward3o.cmail.yandex.net (forward3o.cmail.yandex.net [37.9.109.247]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97FC41294A1 for ; Wed, 21 Dec 2016 00:11:42 -0800 (PST) Received: from mxback8g.mail.yandex.net (mxback8g.mail.yandex.net [77.88.29.169]) by forward3o.cmail.yandex.net (Yandex) with ESMTP id 9784420FFD; Wed, 21 Dec 2016 11:11:39 +0300 (MSK) Received: from web12g.yandex.ru (web12g.yandex.ru [95.108.252.112]) by mxback8g.mail.yandex.net (nwsmtp/Yandex) with ESMTP id Dvmbsky5ub-BcJaQWBS; Wed, 21 Dec 2016 11:11:38 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1482307898; bh=AfYLrkA071R0sPo6TvE+tJ17i1u1RyaGZHYDxUc637w=; h=From:To:Cc:In-Reply-To:References:Subject:Message-Id:Date; b=GPYvPzm6l0sZtvsciWql3fcgIzY+XU18X6ExeFvEfxPvT4q0+dAWxXPEHs9jsieWp XOFLg1WwTQjr093gaaRdqZo+zn41f2sVGSbxAgPRnp5Rvw/8lyG8OxRdVqDiUmSLct KdCo4qrSUpyrR6yb/ttYs0U5DH+1WcLq6WmlOQG0= Authentication-Results: mxback8g.mail.yandex.net; dkim=pass header.i=@yandex.ru Received: by web12g.yandex.ru with HTTP; Wed, 21 Dec 2016 11:11:38 +0300 From: Anton Tveretin To: Alexey Melnikov In-Reply-To: <538a7100-6cf8-80cd-0282-b4341af9170f@isode.com> References: <6492861479110589@web38j.yandex.ru> <538a7100-6cf8-80cd-0282-b4341af9170f@isode.com> MIME-Version: 1.0 Message-Id: <6839131482307898@web12g.yandex.ru> X-Mailer: Yamail [ http://yandex.ru ] 5.0 Date: Wed, 21 Dec 2016 13:11:38 +0500 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=utf-8 Archived-At: Cc: DISPATCH list Subject: Re: [dispatch] Request to form a new WG: JMAP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 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 Dec 2016 08:11:45 -0000 Hello Alexey, At this point, I don't go into details; the new WG would be a better venue. Most essential notes concerning the WG creation are: Why the drafts are proposed STD? I think there is at most one STD per organization per applicability. IETF has SMTP, POP, IMAP, and these 3 protocols have different applicabilities. This is not a limitation to publish RFCs (common examples: FTP vs HTTP, L2TP vs PPTP), but all except one should be INFO. For these reasons, I chose not to publish the NGMTP (New-Generation Mail Transfer Protocol) through IETF, but keep it by myself. Now I see different applicabilities for NGMTP and JMAP, and even possible integration. Also, neither of -00 version of the drafts contains Security Considerations. As a conclusion, I support a formation of a new WG, and I am ready to give few comments on existing drafts. Regards, Anton. 21.11.2016, 22:51, "Alexey Melnikov" : >  Hi Anton, > >>   On 14 Nov 2016, at 17:03, Anton Tveretin wrote: >> >>   Hello, >>   Would this protocol be UNI only? > >  I don't understand the question. Can you elaborate? > >>   So, forwarding would be SMTP? In that case, there will be interworking. >>   Did anyone consider experience with GSM MMS? The message is submitted and retrieved with WAP (binary form of HTTP, to be simple), but inter-domain transmission is with SMTP. >>   Or, is the intent to have one more closed (private) system? > >  The intent is still to use SMTP for message relaying. > >  Best Regards, >  Alexey From nobody Sat Dec 24 07:01:52 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ABBE12940A for ; Sat, 24 Dec 2016 07:01:52 -0800 (PST) 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, RCVD_IN_MSPIKE_H2=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eqT2TiUvco6U for ; Sat, 24 Dec 2016 07:01:47 -0800 (PST) Received: from smtp.smtpout.orange.fr (smtp03.smtpout.orange.fr [80.12.242.125]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 470DB1293E1 for ; Sat, 24 Dec 2016 07:01:46 -0800 (PST) Received: from macbook-pro-de-julien-elie.home ([92.170.5.52]) by mwinf5d50 with ME id Pr1i1u00417Lgi403r1iYV; Sat, 24 Dec 2016 16:01:45 +0100 X-ME-Helo: macbook-pro-de-julien-elie.home X-ME-Auth: anVsaWVuLmVsaWU0ODdAd2FuYWRvby5mcg== X-ME-Date: Sat, 24 Dec 2016 16:01:45 +0100 X-ME-IP: 92.170.5.52 From: =?UTF-8?Q?Julien_=c3=89LIE?= Organization: TrigoFACILE -- http://www.trigofacile.com/ To: dispatch@ietf.org Message-ID: <72631ecb-c85b-6d3f-5113-b5dbadb6cbfd@trigofacile.com> Date: Sat, 24 Dec 2016 16:01:42 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: [dispatch] Maturity level of NNTP and Netnews-related RFCs X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Dec 2016 15:01:52 -0000 Hi all, I think that RFCs related to NNTP and Netnews can be good candidates to advance from Proposed Standards to Internet Standards. NNTP - RFC 3977 "Network News Transfer Protocol (NNTP)" - RFC 4642 "Using TLS with NNTP" - RFC 4643 "NNTP Extension for Authentication" - RFC 4644 "NNTP Extension for Streaming Feeds" - RFC 6048 "NNTP Additions to LIST Command" Netnews Article Format - RFC 5536 "Netnews Article Format" - RFC 5537 "Netnews Architecture and Protocols" Netnews URI Schemes - RFC 5538 "The 'news' and 'nntp' URI Schemes" Are obsolete RFCs also candidates to Internet Standards? (They once were widely-implemented standards at their time; I mean RFCs 850, 977, 1036, 1849.) Regarding the criteria given in Section 2.2 of RFC 6410 "Reducing the Standards Track to Two Maturity Levels": (1) Examples of two independent interoperating implementations with widespread deployment and successful operational experience: Examples of news servers implementing NNTPv2 (RFC 3977) and related extensions: o INN (InterNetNews) https://www.eyrie.org/~eagle/software/inn/ o private news servers like Giganews (news.giganews.com) Examples of news clients implementing NNTPv2 (RFC 3977) and related extensions: o tin http://www.tin.org/ o Gnus, the Emacs newsreader http://www.gnus.org/ o Python library https://docs.python.org/3/library/nntplib.html (2) There are no errata against the specification that would cause a new implementation to fail to interoperate with deployed ones. Hmmm, maybe: o erratum 4468 in RFC 5537? (but I am unsure it is an interoperability failure; non-compliant messages sent by ancient versions of a few news clients are rejected by compliant news servers) o erratum 4708 in RFC 5538? (very minor) Though RFC 3977 has lots of errata, I don't think they would cause interoperability failures. They should be considered more than wording improvements and consistency than interoperability failures. (3) There are no unused features in the specification that greatly increase implementation complexity. Not that I am aware of. (4) If the technology required to implement the specification requires patented or otherwise controlled technology, then the set of implementations must demonstrate at least two independent, separate and successful uses of the licensing process. Not applicable. Could you please tell me if my proposal to make the above RFCs as Internet Standards is receivable, and if that is the case, how to proceed? Thanks, -- Julien ÉLIE « I had some words with my wife, and she had some paragraphs with me. » (Sigmund Freud) From nobody Thu Dec 29 15:34:16 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F50912988F for ; Thu, 29 Dec 2016 15:34:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8a99Zt6Q3R3v for ; Thu, 29 Dec 2016 15:34:10 -0800 (PST) Received: from mail-lf0-x243.google.com (mail-lf0-x243.google.com [IPv6:2a00:1450:4010:c07::243]) (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 E6ECE129715 for ; Thu, 29 Dec 2016 15:34:09 -0800 (PST) Received: by mail-lf0-x243.google.com with SMTP id t196so16646469lff.3 for ; Thu, 29 Dec 2016 15:34:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=nQm4kASQb4VVMkOAac/7LzdK+mwxLH3ZPlj9aPcqdSI=; b=j6zya2wAsuNUgCTGvw+LATQf/DD2+YLyz3kV6wvU6nrzLmLUZbj6q7WCIL0GibDLZW BwLqndu6lV5LD4DKxIpALB3eKiEClAtNF91daNlXciKIshBlQbbNHZMyRDii4MqNZAI/ nTQYmrgzTdx/WqBqJynzApB/1s+JMoYdAjLTG9jLDulZfZ20B9VP9P/Egf294zrPRF5I Ek+oT2UcZGkLAWoNKdpiWNWZWCCvnopN9pXKZ5k4rVJyc0kI2mZqVLJpCg7hJyTBl0nN tNjYuWBAm+USHbocFJRgcv+142cwVLvJgz3fqyR76qD12jwZIBIlkYjoqIXoVKWFcZbm EXPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-transfer-encoding; bh=nQm4kASQb4VVMkOAac/7LzdK+mwxLH3ZPlj9aPcqdSI=; b=q2oZHcSsfukTPeS8VFxRSFFE+VtfZGiXYN6Liv5ZGdQgUlPVZ59SGDv1ZzI3/0wh2N tj9iWqzKH4MGgOBYysmFfc0Fb4i0eM4y1qmcRgtCVQdFSd70q3YU9NGhkkicy+G2yMyl ZuvzcHVZXGNMIbS2BKDTM3D3PfDT3UqPWb51i5jopMTCqjvyty0DmPqiVcF2f3NpDtmk uCcx24/m8KVD6Y2LxFxI1BbUBV8IEJYnrE/dD+rXPGhbvvk9QjWI+PO7bqi9G/U0037N h0pGG0Qiaf6dVD/idTkTnNpvZgtSOeJeRSYhnKYzqIz0bXo4K75KghUHA3WtazbiHDkL MB0Q== X-Gm-Message-State: AIkVDXK8a1Fw93tlvM6TrJwRHFty2EO3EvpfxBD+EvTuBngikzmGbjGUTcDHqa8/P3U26vnAaENXy2ZsXfruLA== X-Received: by 10.25.66.70 with SMTP id p67mr15598184lfa.138.1483054448081; Thu, 29 Dec 2016 15:34:08 -0800 (PST) MIME-Version: 1.0 Sender: barryleiba.mailing.lists@gmail.com Received: by 10.25.22.84 with HTTP; Thu, 29 Dec 2016 15:34:07 -0800 (PST) In-Reply-To: <72631ecb-c85b-6d3f-5113-b5dbadb6cbfd@trigofacile.com> References: <72631ecb-c85b-6d3f-5113-b5dbadb6cbfd@trigofacile.com> From: Barry Leiba Date: Thu, 29 Dec 2016 18:34:07 -0500 X-Google-Sender-Auth: ToQxi2sZyCsMP_H5hpED3qrIZS8 Message-ID: To: =?UTF-8?B?SnVsaWVuIMOJTElF?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: dispatch@ietf.org Subject: Re: [dispatch] Maturity level of NNTP and Netnews-related RFCs X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Dec 2016 23:34:14 -0000 > I think that RFCs related to NNTP and Netnews can be good candidates to > advance from Proposed Standards to Internet Standards. One snag here has traditionally been that there are lots of prerequisites (normative references) that are still at PS. The major ones here are the MIME specs (2045 and 2047) and base64 (4648). One possible solution to that is to invoke RFC 3967 and say that these are reasonable downrefs because they're stable and mature... but 3967 is clear that in such a case, using downrefs is not the right answer, and instead the downrefs should be progressed first. To that end, there've been a couple of attempts to start pushing the whole batch of SMTP (RFC 5321), message format (RFC 5322), MIME (RFCs 2045 thru 2049), and several others up to IS, enabling others batches such as NNTP to go afterward. See the aborted YAM working group for one such attempt. RFCs 5321 and 5322 are really the linchpins for this; we'd need to start with those. Barry > NNTP > - RFC 3977 "Network News Transfer Protocol (NNTP)" > - RFC 4642 "Using TLS with NNTP" > - RFC 4643 "NNTP Extension for Authentication" > - RFC 4644 "NNTP Extension for Streaming Feeds" > - RFC 6048 "NNTP Additions to LIST Command" > > Netnews Article Format > - RFC 5536 "Netnews Article Format" > - RFC 5537 "Netnews Architecture and Protocols" > > Netnews URI Schemes > - RFC 5538 "The 'news' and 'nntp' URI Schemes" > > > > Are obsolete RFCs also candidates to Internet Standards? (They once were > widely-implemented standards at their time; I mean RFCs 850, 977, 1036, > 1849.) > > > > Regarding the criteria given in Section 2.2 of RFC 6410 "Reducing the > Standards Track to Two Maturity Levels": > > (1) Examples of two independent interoperating implementations with > widespread deployment and successful operational experience: > > Examples of news servers implementing NNTPv2 (RFC 3977) and related > extensions: > o INN (InterNetNews) https://www.eyrie.org/~eagle/software/inn/ > o private news servers like Giganews (news.giganews.com) > > Examples of news clients implementing NNTPv2 (RFC 3977) and related > extensions: > o tin http://www.tin.org/ > o Gnus, the Emacs newsreader http://www.gnus.org/ > o Python library https://docs.python.org/3/library/nntplib.html > > > (2) There are no errata against the specification that would cause a new > implementation to fail to interoperate with deployed ones. > > Hmmm, maybe: > o erratum 4468 in RFC 5537? (but I am unsure it is an interoperability > failure; non-compliant messages sent by ancient versions of a few news > clients are rejected by compliant news servers) > o erratum 4708 in RFC 5538? (very minor) > > Though RFC 3977 has lots of errata, I don't think they would cause > interoperability failures. They should be considered more than wording > improvements and consistency than interoperability failures. > > > (3) There are no unused features in the specification that greatly increa= se > implementation complexity. > > Not that I am aware of. > > > (4) If the technology required to implement the specification requires > patented or otherwise controlled technology, then the set of implementati= ons > must demonstrate at least two independent, separate and successful uses o= f > the licensing process. > > Not applicable. > > > > > Could you please tell me if my proposal to make the above RFCs as Interne= t > Standards is receivable, and if that is the case, how to proceed? > > Thanks, > > -- > Julien =C3=89LIE > > =C2=AB I had some words with my wife, and she had some paragraphs with > me. =C2=BB (Sigmund Freud) > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch