Re: [sidr] Last Call: <draft-ietf-sidr-rpki-oob-setup-04.txt> (An Out-Of-Band Setup Protocol For RPKI Production Services) to Proposed Standard

Rob Austein <> Fri, 06 January 2017 19:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9B7BF129D9C; Fri, 6 Jan 2017 11:10:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.001
X-Spam-Status: No, score=-5.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZWW5ObuqUaGw; Fri, 6 Jan 2017 11:10:53 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7917E129611; Fri, 6 Jan 2017 11:10:53 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "", Issuer "Grunchweather Associates" (not verified)) by (Postfix) with ESMTPS id CD2DD13998; Fri, 6 Jan 2017 19:10:51 +0000 (UTC)
Received: from (localhost [IPv6:::1]) by (Postfix) with ESMTP id 74B334602216; Fri, 6 Jan 2017 14:10:41 -0500 (EST)
Date: Fri, 06 Jan 2017 14:10:41 -0500
From: Rob Austein <>
To: "t.petch" <>
Subject: Re: [sidr] Last Call: <draft-ietf-sidr-rpki-oob-setup-04.txt> (An Out-Of-Band Setup Protocol For RPKI Production Services) to Proposed Standard
In-Reply-To: <00a001d26840$e5194580$>
References: <> <01f101d260f9$dee15c00$> <> <00a001d26840$e5194580$>
User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <>
Archived-At: <>
Cc: Rob Austein <>, Chris Morrow <>,,,, ietf <>
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 06 Jan 2017 19:10:54 -0000

At Fri, 6 Jan 2017 17:15:04 +0000, t.petch wrote:
> Looking some more at this, I would not want to try and troubleshoot this
> protocol with such a limited range of error messages.
> Not something I am likely to be doing but were I to, I would like to see
> an indication of the nature of the error (eg in attribute, element,
> certificate) and where the error was found (the relevant name) and for
> authentication errors, well, look at the certificate related TLS Alerts
> which suggest to me the level of detail that has found to be needed in
> at least some quarters.  And bear in mind that you are making no
> recommendation about most of the certificate options, just that you
> expect them to be the usual ones:-)
> As it is, I would not know where to place most errors into the three
> possibilities provided.

Sort of agree, but....

The <error/> PDU is optional, and in practice has not been used much
to date.  In practice, diagnosing errors generally involves looking in
some server log file, and errors to date have usually been reported
via email or voice.  We included the <error/> PDU because an earlier
reviewer insisted, but we don't have enough experience using with it
to know what kind of detail would really be useful.  That being the
case, my preference would be to leave the schema alone for now and
wait for experience, after which we can revise the protocol if we see
an opportunity for serious improvement.  YMMV.

FWIW, the three current error codes translate, roughly, to:

* "I don't understand what you want me to do";

* "I think I understand what you want me to do and am willing but I
  hit an authorization problem while trying to do it"; and

* "I don't feel like playing this game".

I don't see all that much ambiguity between these three very broad
categories, but I'm also not all that worried about it, because I
don't expect the current simplistic version of the <error/> PDU to
replace two human being having some kind of conversation after looking
at log files.  Again, YMMV.