Re: [sidr] AD Review of draft-ietf-sidr-rpki-rtr-rfc6810-bis-07

Stephen Kent <> Thu, 26 May 2016 15:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 33F3C12D710 for <>; Thu, 26 May 2016 08:15:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.627
X-Spam-Status: No, score=-4.627 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FSL_HELO_HOME=1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id B5T-3MlruV5C for <>; Thu, 26 May 2016 08:15:47 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EF6A912D70A for <>; Thu, 26 May 2016 08:15:46 -0700 (PDT)
Received: from ([]:37574 helo=COMSEC.fios-router.home) by with esmtp (Exim 4.77 (FreeBSD)) (envelope-from <>) id 1b5x0k-000AeM-6L for; Thu, 26 May 2016 11:15:46 -0400
From: Stephen Kent <>
References: <> <> <>
Message-ID: <>
Date: Thu, 26 May 2016 11:15:47 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [sidr] AD Review of draft-ietf-sidr-rpki-rtr-rfc6810-bis-07
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Secure Interdomain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 26 May 2016 15:15:48 -0000


> ...
>> It means that most of the code one needs to deal with version one is
>> the same as the code one needs to deal with version zero.  Feel free
>> to suggest better text.
> When I think about protocol compatibility I think about on-the-wire
> behavior and packets, not about the implementation internals.

I'm not sure what the phrase "on-the-wire behavior" means. Certainly
it is not enough to agree on data formats, i.e., the format of data on 
the wire.
There also must be consistent behavior by each end of a 
connection/session/ ...
(in terms of externally-visible processing) of the agreed upon data format.
Otherwise,  the behavior of "compatible" implementations may vary 
and  users will not see the versions as "compatible."

I think your latter comments match my sense of "compatibility",
but I just wanted to make sure we are on the same page.