Re: [salud] Gen-art LC review of draft-ietf-salud-alert-info-urns-12 and also Area Director's review

"DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com> Tue, 06 May 2014 23:39 UTC

Return-Path: <keith.drage@alcatel-lucent.com>
X-Original-To: salud@ietfa.amsl.com
Delivered-To: salud@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F032A1A068E; Tue, 6 May 2014 16:39:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IQ-K89e2bOEh; Tue, 6 May 2014 16:39:03 -0700 (PDT)
Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id 626BF1A0643; Tue, 6 May 2014 16:39:02 -0700 (PDT)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s46Ncp80014806 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 6 May 2014 18:38:52 -0500 (CDT)
Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s46NcnON023830 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 7 May 2014 01:38:50 +0200
Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.4]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Wed, 7 May 2014 01:38:50 +0200
From: "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com>
To: "Dale R. Worley" <worley@ariadne.com>, Alexey Melnikov <alexey.melnikov@isode.com>, "rlb@ipv.sx" <rlb@ipv.sx>
Thread-Topic: [salud] Gen-art LC review of draft-ietf-salud-alert-info-urns-12 and also Area Director's review
Thread-Index: AQHPaVyH217b9U6DvE6jczFj0NykWZs0NBGg
Date: Tue, 6 May 2014 23:38:49 +0000
Message-ID: <949EF20990823C4C85C18D59AA11AD8B1965E3@FR712WXCHMBA11.zeu.alcatel-lucent.com>
References: <535E50C1.2060100@isode.com> <201405061853.s46Ire8K007213@hobgoblin.ariadne.com>
In-Reply-To: <201405061853.s46Ire8K007213@hobgoblin.ariadne.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.239.27.39]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/salud/xL5bnRWoGP-Xs4dyyymGV8exBpo
Cc: "draft-ietf-salud-alert-info-urns.all@tools.ietf.org" <draft-ietf-salud-alert-info-urns.all@tools.ietf.org>, "gen-art@ietf.org" <gen-art@ietf.org>, "salud@ietf.org" <salud@ietf.org>
Subject: Re: [salud] Gen-art LC review of draft-ietf-salud-alert-info-urns-12 and also Area Director's review
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: Tue, 06 May 2014 23:39:06 -0000

> > 13.  User Agent Behaviour
> >
> >    The User Agent (UA) MUST produce a reasonable rendering 
> regardless of
> >    the combination of URIs (of any schemes) in the Alert-Info header
> >    field.
> >
> > This MUST is not well defined to be implementable. How can 
> conformance 
> > or violation of this requirement can be tested? I suggest you avoid 
> > using RFC
> > 2119 language here.
> 
> The authors agree and will change the MUST to "must".

Can we avoid lower case forms of RFC 2119 language as this just leaves the reader with the question as to whether there was an editing error.

I would suggest "The User Agent (UA) is expected to produce..."


Regards

Keith
 

> -----Original Message-----
> From: salud [mailto:salud-bounces@ietf.org] On Behalf Of Dale 
> R. Worley
> Sent: 06 May 2014 19:54
> To: Alexey Melnikov; rlb@ipv.sx
> Cc: draft-ietf-salud-alert-info-urns.all@tools.ietf.org; 
> gen-art@ietf.org; salud@ietf.org
> Subject: Re: [salud] Gen-art LC review of 
> draft-ietf-salud-alert-info-urns-12 and also Area Director's review
> 
> 2014-04-28 14:59 GMT+02:00 Alexey Melnikov 
> <alexey.melnikov@isode.com>om>:
> >
> > I am the assigned Gen-ART reviewer for this draft. For 
> background on 
> > Gen-ART, please see the FAQ at
> >
> > <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
> >
> > Please resolve these comments along with any other Last 
> Call comments 
> > you may receive.
> >
> > Document: draft-ietf-salud-alert-info-urns-12.txt
> > Reviewer: Alexey Melnikov
> > Review Date: 27 April 2014
> > IETF LC End Date: 25 April 2014
> > IESG Telechat date: (if known) N/A
> >
> > Summary: Ready with nits/questions.
> >
> >
> > Major issues:
> > None
> >
> > Minor issues:
> >
> > 13.  User Agent Behaviour
> >
> >    The User Agent (UA) MUST produce a reasonable rendering 
> regardless of
> >    the combination of URIs (of any schemes) in the Alert-Info header
> >    field.
> >
> > This MUST is not well defined to be implementable. How can 
> conformance 
> > or violation of this requirement can be tested? I suggest you avoid 
> > using RFC
> > 2119 language here.
> 
> The authors agree and will change the MUST to "must".
> 
> Because we had another comment regarding this paragraph from 
> our Area Director (Richard Barnes), we will add following 
> text at the end of that paragraph:
> 
>     In particular, unless the containing message is a request and is
>     immediately rejected, the UA SHOULD provide some alert 
> unless it is
>     explicitly instructed not to (for example, by Alert-Info URIs that
>     it understands, the presence of a Replaces or Joins header field,
>     local policy, or direction of the user).
> 
> > Has this been submitted to the urn-nid@apps.ietf.org 
> mailing list for 
> > 2 weeks review? (as per RFC 3406)
> 
> The urn-nid review started 3 Oct 2013:
> http://www.ietf.org/mail-archive/web/urn-nid/current/msg01218.html
> There were no comments.
> 
> > Nits/editorial comments:
> >
> >  "REQ-4: has been deleted.  To avoid confusion, the number 
> will not be 
> > reused".
> >
> >  I find this to be rather unusual. Are these requirements 
> used in RFPs?
> 
> We did not want a renumbering of the requirements in order to 
> avoid confusion when people sent comments on the 
> requirements. It makes sense to renumber the requirements 
> now, and we will do so.
> 
> > In Section 7:
> >
> > date              = [CC] YY [ "-" MM ["-" DD] ]
> >
> >
> > Is there a need for having 2 octet years? Are you trying to 
> save some 
> > bytes here at the expense of extra (albeit minor) complexity?
> 
> We believe it is valuable to allow just YY, but are willing 
> remove it if necessary to pass the gen-art review.
> 
> Overall, we have strived to allow brevity in the date formats.
> Allowing CC to be optional changes the number of permitted 
> date formats from 4 (including complete absence) to 7, but it 
> only increases the number of distinct choices in code that 
> processes dates from 3 to 4.  Given that CC can only be "20" 
> for the next 86 years, and the general desirability of 
> brevity, we think that it is as reasonable to make CC 
> optional as it is to make MM and DD optional.
> 
> Dale [for the authors of draft-ietf-salud-alert-info-urns]
> 
> _______________________________________________
> salud mailing list
> salud@ietf.org
> https://www.ietf.org/mailman/listinfo/salud
>