Re: [salud] Gen-art LC review of draft-ietf-salud-alert-info-urns-12 and also Area Director's review (Dale R. Worley) Tue, 06 May 2014 18:53 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id A96091A01C4 for <>; Tue, 6 May 2014 11:53:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
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] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id K7lqKuP2G75T for <>; Tue, 6 May 2014 11:53:51 -0700 (PDT)
Received: from ( [IPv6:2001:558:fe14:44:76:96:59:227]) by (Postfix) with ESMTP id 03D5D1A0234 for <>; Tue, 6 May 2014 11:53:50 -0700 (PDT)
Received: from ([]) by with comcast id yhWi1n0021ZXKqc5CitniC; Tue, 06 May 2014 18:53:47 +0000
Received: from ([]) by with comcast id yitm1n00G1KKtkw3hitm59; Tue, 06 May 2014 18:53:47 +0000
Received: from ( []) by (8.14.7/8.14.7) with ESMTP id s46IrjhZ007221; Tue, 6 May 2014 14:53:45 -0400
Received: (from worley@localhost) by (8.14.7/8.14.7/Submit) id s46Ire8K007213; Tue, 6 May 2014 14:53:40 -0400
Date: Tue, 6 May 2014 14:53:40 -0400
Message-Id: <>
From: (Dale R. Worley)
Sender: (Dale R. Worley)
To: Alexey Melnikov <>,
In-reply-to: <> (
References: <>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=q20140121; t=1399402427; bh=b5Pe++g4y9MYXrMBbyiMNrN+MPPThZ5j9qHNuBktuig=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=nNYEymEqBzFpRJ+uWOO3QAPE2JK+zxXiVEAoTOUIlUQJ21Oy9fe/Zal2dOCfyp6Tq ehMUhp61F6TEDotn7mCOx1z9//eN+bDeNwaN+ddbNEvBOOfWo4LkHnHdVAOLaWDdo7 jGV2UXkzz/Mj+MXrrV2d16SIzj39k1bTX/6UH6JnZ3CIMKYCYK4t5Q/XulVOWQuKwH qee1GXJBbg51oXrrBsHJpxqEwcJ1JmYSu7psdunHginvf+nET0EITLOjAIhQdnK5y9 4KShtq6KAmBIUHk9AdpYAv3uWb9VlMsltMOevCFEzr19Yix9O1RD8OzGffKasoYrvX eVKpKM3SBm9Cw==
Subject: Re: [salud] Gen-art LC review of draft-ietf-salud-alert-info-urns-12 and also Area Director's review
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Sip ALerting for User Devices working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 06 May 2014 18:53:52 -0000

2014-04-28 14:59 GMT+02:00 Alexey Melnikov <>om>:
> I am the assigned Gen-ART reviewer for this draft. For background on
> Gen-ART, please see the FAQ at
> <>.
> 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 mailing list for 2
> weeks review? (as per RFC 3406)

The urn-nid review started 3 Oct 2013:
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]