[salud] Review comments on draft-ietf-salud-alert-info-urns-13

Christer Holmberg <christer.holmberg@ericsson.com> Thu, 04 September 2014 08:00 UTC

Return-Path: <christer.holmberg@ericsson.com>
X-Original-To: salud@ietfa.amsl.com
Delivered-To: salud@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id ABAA11A6F62 for <salud@ietfa.amsl.com>; Thu, 4 Sep 2014 01:00:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id eC1JOnTHedl8 for <salud@ietfa.amsl.com>; Thu, 4 Sep 2014 01:00:36 -0700 (PDT)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F2641A6F57 for <salud@ietf.org>; Thu, 4 Sep 2014 01:00:36 -0700 (PDT)
X-AuditID: c1b4fb3a-f79da6d0000008c7-b4-54081c21614c
Received: from ESESSHC022.ericsson.se (Unknown_Domain []) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 27.1E.02247.12C18045; Thu, 4 Sep 2014 10:00:34 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([]) by ESESSHC022.ericsson.se ([]) with mapi id 14.03.0174.001; Thu, 4 Sep 2014 10:00:33 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: "salud@ietf.org" <salud@ietf.org>
Thread-Topic: Review comments on draft-ietf-salud-alert-info-urns-13
Thread-Index: Ac/IFf+gMZjC49hSQeiq/vmrqzhpOA==
Date: Thu, 4 Sep 2014 08:00:33 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1D439271@ESESSMB209.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D439271ESESSMB209erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrJLMWRmVeSWpSXmKPExsUyM+Jvja6SDEeIwdJ+Vou7HQcYLV6eKHNg 8pi8/yuzx5IlP5kCmKK4bFJSczLLUov07RK4Mt5db2MquGVRMXHmPvYGxn2GXYycHBICJhLn nn1nhbDFJC7cW8/WxcjFISRwlFFi8duNTCAJIYHFjBKHdyh3MXJwsAlYSHT/0wYJiwioSlxf 3c0CYjML2Ems2L+EHcQWFrCXmPZ9CyNEjYvE1Yc3mCFsPYmXd5rBRrIIqEgsm7+NCWQkr4Cv xK+2VJAwI9AJ30+tYYIYKS5x68l8JojTBCSW7DnPDGGLSrx8/I8VpFVCQFFieb8cRHm+xJuW e2DX8AoISpyc+YRlAqPwLCSTZiEpm4WkDCKuI7Fg9yc2CFtbYtnC18ww9pkDj5mQxRcwsq9i FC1OLS7OTTcy0kstykwuLs7P08tLLdnECIybg1t+W+1gPPjc8RCjAAejEg/vg//sIUKsiWXF lbmHGKU5WJTEeReemxcsJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgdFk5YezC69varp/bFKH zfc9az2fPmfcWhDHlW067WWWbsZ+SY9Ql8Nzf6kfWiQt4HLOfJZU2oa4KUE3/NR/XU7q3RqU lKO2le1s+apai5qPponhj7hDl8n9Sc7svfIkdtPpWtYL3xtWWhw92Z+wNPjtKhGd+68Pp/zb 8aB7D/f/fYKrBWv2pP1VYinOSDTUYi4qTgQA/dDCiHwCAAA=
Archived-At: http://mailarchive.ietf.org/arch/msg/salud/-T6Ir1zfa1Cu0GMmOL2BY6VmixU
Subject: [salud] Review comments on draft-ietf-salud-alert-info-urns-13
X-BeenThere: salud@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Sip ALerting for User Devices working group discussion list <salud.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/salud>, <mailto:salud-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/salud/>
List-Post: <mailto:salud@ietf.org>
List-Help: <mailto:salud-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/salud>, <mailto:salud-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Sep 2014 08:00:38 -0000


I have reviewed the latest version of the alert-urn draft. In general it looks ok, but I have a few comments (of which one is pure editorial) that I request the authors to address.



As it is now allowed to use the Alert-Info header field in any non-100 provisional response, I assume the value could actually change from one
response to another.

Eventhough RFC3261 does not explicitly forbid it, perhaps it would be good to explicitly mention that in this draft, because I assume there could be use cases where
e.g. one value is received in a 181, and another value in a subsequent 180.


Section 4.1:


                This is pure editorial, but for alignment purpose I suggest to change "in all provisional responses..." to "in any non-100 provisional response..."


Section 4.2:


This section is below the "Updates to RFC 3261" section, but it is unclear exactly what is updated.

The first paragraph of section 20.4/RFC 3261 already says that a proxy can insert a A-I header. If you want to explicitly say
that a proxy can also modify an existing header, shouldn't that be text that you add to e.g. the same paragraph?