Re: [sidr] Terry Manderson's No Objection on draft-ietf-sidr-delta-protocol-07: (with COMMENT)

"Alvaro Retana (aretana)" <aretana@cisco.com> Fri, 17 February 2017 14:56 UTC

Return-Path: <aretana@cisco.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CFDB1294A7; Fri, 17 Feb 2017 06:56:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.521
X-Spam-Level:
X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 A34bQpMFclXC; Fri, 17 Feb 2017 06:56:43 -0800 (PST)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9E5B1293E8; Fri, 17 Feb 2017 06:56:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22748; q=dns/txt; s=iport; t=1487343403; x=1488553003; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=IUHqqO3JxND1rb+HU5vLtIbUckj9T7jJweEfNMgmDEQ=; b=d8F4+0HQSfKJOtNNwu7zNaNj7UOT6256CNRlJTEAcgcY+wIwts8UW/jJ uS87qpwuiVBj8JrwyGZ6spgZVy73A/bOFdq2QmlVKXQhw/Be67c+5EUcX er8pKXT36C40di4HIH0yGuxj2snJg/DKTqUlwiSahZJbX7e75qEPYi0rJ I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DyAQCjDqdY/5tdJa1eGQEBAQEBAQEBAQEBBwEBAQEBgm9iYTFYB4NSigiiHYMdgg+CDC6FdAIaggU/GAECAQEBAQEBAWIohHEGI1YQAgEIPwMCAgIwFBECBAENBYlsDrBWgiUriywBAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYZMggWCaoMXgQYJEQGDIi6CMQWJDoxPhiQBhnCLKIF7hReJdogwim0BHzh4CFEVPREBhDQdGYFIdQEEiDiBIYENAQEB
X-IronPort-AV: E=Sophos;i="5.35,172,1484006400"; d="scan'208,217";a="386842918"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Feb 2017 14:56:41 +0000
Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v1HEufMe025239 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 17 Feb 2017 14:56:41 GMT
Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 17 Feb 2017 08:56:41 -0600
Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1210.000; Fri, 17 Feb 2017 08:56:41 -0600
From: "Alvaro Retana (aretana)" <aretana@cisco.com>
To: Tim Bruijnzeels <tim@ripe.net>, Terry Manderson <terry.manderson@icann.org>, "sidr-chairs@ietf.org" <sidr-chairs@ietf.org>, "morrowc@ops-netman.net" <morrowc@ops-netman.net>, "sandy@tislabs.com" <sandy@tislabs.com>
Thread-Topic: [sidr] Terry Manderson's No Objection on draft-ietf-sidr-delta-protocol-07: (with COMMENT)
Thread-Index: AQHSh/jZg3PcEJPtD0S+zGbVhzl8aqFsJDuAgAE4rIA=
Date: Fri, 17 Feb 2017 14:56:41 +0000
Message-ID: <3A008C78-B846-4F8F-A813-C54C276FAEFD@cisco.com>
References: <148721059915.31454.12790381111112907537.idtracker@ietfa.amsl.com> <47B3699A-B344-4BA5-A131-309A6DF04FBD@ripe.net>
In-Reply-To: <47B3699A-B344-4BA5-A131-309A6DF04FBD@ripe.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.1e.0.170107
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.117.15.3]
Content-Type: multipart/alternative; boundary="_000_3A008C78B8464F8FA813C54C276FAEFDciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/XgtzooXxRLto-P8jNqwwvu2JQzI>
Cc: "draft-ietf-sidr-delta-protocol@ietf.org" <draft-ietf-sidr-delta-protocol@ietf.org>, The IESG <iesg@ietf.org>, "sidr@ietf.org" <sidr@ietf.org>
Subject: Re: [sidr] Terry Manderson's No Objection on draft-ietf-sidr-delta-protocol-07: (with COMMENT)
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidr/>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 17 Feb 2017 14:56:45 -0000

Hi!

I just want to provide a little bit more background on the topic below – and ask the Chairs to take an action to confirm with the WG.

During the discussion resulting from my AD review of this document [1], the topic of whether the intent of the document was to replace rsync or not came up (see M16 in my review) – after some discussion we came to a way forward [2], which was to formally Update in RFC6480, RFC6481, and RFC7730 to change the mandatory to implement requirement for rsync and leave instead “a retrieval mechanism(s) consistent with the accessMethod element value(s)”.

Even though this discussion happened on the sidr list, I sent a message to the WG asking for review of the changes [3]…but no reply was received.

As Terry mentions below, these changes removed “the quality of a mandatory to implement retrieval mechanism”: rsync is no longer mandatory to implement, but neither is RRDP.  I personally think that is ok because it also allows to more flexibility; rsync or RRDP (or anything else “consistent with the accessMethod element value(s)”), or both can be implemented as primary and/or backup.

**Chairs**:  Given that this is a significant change, and that the WG may have not been focused on the discussion, and that we now have a little more time given the fact that the IESG review of this document was deferred until Mar/2…  Please explicitly ask the WG to review the Updates to RFC6480, RFC6481 and RFC7730.  I think that a week of discussion on the list should be enough.

Thanks!!

Alvaro.


[1] https://mailarchive.ietf.org/arch/msg/sidr/u1WO8jNlvn-JzoVduhpPOKHjMfI/?qid=61717c3126a62454b45c426ced5d3344
[2] https://mailarchive.ietf.org/arch/msg/sidr/a6kQUe7y456oLmTDrvrBqwR5oRI/?qid=61717c3126a62454b45c426ced5d3344
[3] https://mailarchive.ietf.org/arch/msg/sidr/2d_dDJ5Ck2PMptK_N2tRGQNEDBk/?qid=61717c3126a62454b45c426ced5d3344

On 2/16/17, 10:17 AM, "iesg on behalf of Tim Bruijnzeels" <iesg-bounces@ietf.org<mailto:iesg-bounces@ietf.org> on behalf of tim@ripe.net<mailto:tim@ripe.net>> wrote:


On 16 Feb 2017, at 03:03, Terry Manderson <terry.manderson@icann.org<mailto:terry.manderson@icann.org>> wrote:
Terry Manderson has entered the following ballot position for
draft-ietf-sidr-delta-protocol-07: No Objection
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.
The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-sidr-delta-protocol/
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------
Thank you for this work, it is clear and well written. While I have never
(ever) been enamoured by RSYNC, and I much prefer this direction on a
personal level, the updates to the existing RFCs regarding RSYNC does two
things. The first is it demotes RSYNC to 'just another access mechanism',
and the second is it appears to remove the quality of a mandatory to
implement retrieval mechanism. Am I reading that correctly? If this is
intentional and has workgroup consensus so be it and onwards we move..

Initially this was written as an additional protocol, next to rsync. The idea was that rsync would be replaced altogether at some point, but the way to get there was intentionally left out of this document because we felt it should just focus on protocol.

The changes you mention were made following AD review comments on 7 January. The intent as I understood it was to defer the question which retrieval mechanism is mandatory to another document, but leave the specifications generic.