Re: [salud] Barry Leiba's Discuss on draft-ietf-salud-alert-info-urns-12: (with DISCUSS and COMMENT)

Paul Kyzivat <> Tue, 13 May 2014 18:17 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 7B27F1A01C4 for <>; Tue, 13 May 2014 11:17:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2LzI8LfC-r1h for <>; Tue, 13 May 2014 11:17:15 -0700 (PDT)
Received: from ( [IPv6:2001:558:fe14:43:76:96:62:80]) by (Postfix) with ESMTP id 43BAB1A01AA for <>; Tue, 13 May 2014 11:17:15 -0700 (PDT)
Received: from ([]) by with comcast id 1USz1o0040mv7h058WH8xi; Tue, 13 May 2014 18:17:08 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([]) by with comcast id 1WH81o00i3ZTu2S3XWH8GT; Tue, 13 May 2014 18:17:08 +0000
Message-ID: <>
Date: Tue, 13 May 2014 14:17:08 -0400
From: Paul Kyzivat <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: "" <>
References: <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=q20140121; t=1400005028; bh=TrONUzQw9U2RzmwSTpR1UFEAbekDne40jhA3x7uaxnI=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=SNZkxywtHtiOtBj7lkA0SL7yr98avNZwqrLO/8zcVM3jY3BzXmI4YWI10QRYG9fH/ Ort153afqRyBhL1YoLMQbm2yDE+ciCzjzKFjlqX9T41P6JDn44l1JMU/Cb1IjLOlnp uANzn4NNRFKDsgfokMrA9jia2XrWEztquccRbuPe6aVM5TVcUU4PATZt8/MCI9ag7B /9TYvnTXZEUJ1sVkAMX7X5TeeYwqdwi77P8skKDNxz852iX4/hZQQdkC45jMU5g+sQ wQsL4157Z53+x4VeUfL8T8iCL8nrUkZF7rhNEX5cXp63U0MEgg5NePpCugduxdaiXE OInatMODPR/1g==
Subject: Re: [salud] Barry Leiba's Discuss on draft-ietf-salud-alert-info-urns-12: (with DISCUSS and COMMENT)
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, 13 May 2014 18:17:16 -0000

[NOTE: this message is to the WG, not back to Barry.]

See question at end

On 5/13/14 10:49 AM, Barry Leiba wrote:
> Hi, Paul, and thanks for the response.
>>> -- Sections 9.1, 9.2, 10.1 --
>>> I worry that we're painting ourselves into an undesirable corner here by
>>> using Standards Action for the registration policies.  Is it truly
>>> inappropriate to use Specification Required or Expert Review, and to let
>>> a designated expert that the IESG appoints stand in for (1) overall IETF
>>> review and (2) the demand that the registration be done in a Standards
>>> Track RFC?
>>> We have too many cases when we've later regretted using Standards Action
>>> or IETF Review (the registration of a URN NID being one of them; we're in
>>> the pocess of changing that policy in the urnbis working group).  And
>>> especially if you want other standards outside the IETF to use these,
>>> requiring them to get an IETF Standards Track RFC or to use private names
>>> doesn't seem reasonable.
>>> Can you please explain the reason for holding to Standards Action, and
>>> the harm that would be caused by using some form of expert review
>>> instead?
>> I often find it difficult to choose a policy.
> Indeed.
>> IMO the policies that are more "automatic" require more clarity about
>> criteria for what is a valid entry and what is not. In particular I find it
>> problematic to leave the decision to a designated expert without clear
>> guidance to the expert. (I serve as an expert on a registry where that
>> guidance is insufficient, and I am uncomfortable with that.)
> Absolutely so, which is why there should be clear guidance to the expert.
> But that's really no different to what we have with Standards Action:
> if we can't give guidance to the expert, then we can't give guidance
> to the IETF community as a whole, and then it's just a crap-shoot when
> someone needs to add a new entry and writes an I-D and submits it.
> We're also asking ADs to AD-sponsor drafts that are solely for the
> purpose of registering one of these things.  Let me tell you how
> annoying that is with URN NIDs, and for no good purpose.  The NID
> registration requests are already reviewed on a specific mailing list,
> and assigning a designated expert to make sure the comments have been
> addressed and to approve the registration would be a big help and
> would make the whole process more reasonable.  I think the same would
> be true here.
> But, yes, absolutely: clear guidance to the expert.
>> The use of Specification Required is "the easy way out", in that we can then
>> defer the decision about what is appropriate until later. Maybe by then we
>> will have more experience with use of this. We aren't really expecting to
>> see new public categories soon.
> Are you saying that we don't *know* what guidance to give to the
> expert?  Then how would we expect an individually submitted Standards
> Track draft to get any reasonable processing for this?

What I am tempted to reply is:


Yep, that is what I'm saying.

I would hope that these would be run through a WG - probably DISPATCH 
once SALUD closes. And there the pros/cons would be debated.

Else it would presumably be AD-sponsored, and the AD would be the 
sounding board.

We could spend more time trying to define guidelines for an expert. But 
it is not so each. Each category is a new dimension in a 
multidimensional space, with a unique domain of values. We want the 
dimensions to be independent, so that there aren't multiple ways to 
express the same thing. And there are better and worse ways to define 
things, and some things that make no sense at all. It is hard to 
describe "common sense" here.


But that might not be a wise thing to answer to the iesg.