Re: [Sidrops] Robert Wilton's No Objection on draft-ietf-sidrops-rp-06: (with COMMENT)

Di Ma <madi@rpstir.net> Thu, 09 April 2020 14:38 UTC

Return-Path: <madi@rpstir.net>
X-Original-To: sidrops@ietfa.amsl.com
Delivered-To: sidrops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98B1A3A07E9; Thu, 9 Apr 2020 07:38:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 YJ7vWgeUUz86; Thu, 9 Apr 2020 07:38:26 -0700 (PDT)
Received: from out20-50.mail.aliyun.com (out20-50.mail.aliyun.com [115.124.20.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B56B3A07AC; Thu, 9 Apr 2020 07:38:20 -0700 (PDT)
X-Alimail-AntiSpam: AC=CONTINUE; BC=0.1399586|-1; CH=green; DM=|CONTINUE|false|; DS=CONTINUE|ham_system_inform|0.0079605-3.23236e-05-0.992007; FP=0|0|0|0|0|-1|-1|-1; HT=e02c03307; MF=madi@rpstir.net; NM=1; PH=DS; RN=6; RT=6; SR=0; TI=SMTPD_---.HDdfjWw_1586443092;
Received: from 192.168.3.24(mailfrom:madi@rpstir.net fp:SMTPD_---.HDdfjWw_1586443092) by smtp.aliyun-inc.com(10.147.41.178); Thu, 09 Apr 2020 22:38:14 +0800
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Di Ma <madi@rpstir.net>
In-Reply-To: <158635214730.7934.5595563917251501429@ietfa.amsl.com>
Date: Thu, 9 Apr 2020 22:38:09 +0800
Cc: The IESG <iesg@ietf.org>, draft-ietf-sidrops-rp@ietf.org, SIDROps Chairs <sidrops-chairs@ietf.org>, sidrops@ietf.org, nathalie@ripe.net
Content-Transfer-Encoding: quoted-printable
Message-Id: <F72F3DE8-3C85-430E-B34B-38F45791ABA6@rpstir.net>
References: <158635214730.7934.5595563917251501429@ietfa.amsl.com>
To: Robert Wilton <rwilton@cisco.com>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/4qYpXf7eZ-Dp-0ra8SD1T8hiyZc>
Subject: Re: [Sidrops] Robert Wilton's No Objection on draft-ietf-sidrops-rp-06: (with COMMENT)
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Apr 2020 14:38:35 -0000

Robert,

Thanks for your review.

Please find our response in lines.

> 2020年4月8日 21:22,Robert Wilton via Datatracker <noreply@ietf.org> 写道:
> 
> Robert Wilton has entered the following ballot position for
> draft-ietf-sidrops-rp-06: 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-sidrops-rp/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Thanks for this - I think that this document is useful.  One issue with the
> IETF standard format is that it can be difficult to find which RFCs need to be
> read to fully solve a particular problem, particularly considering that some of
> those RFCs may be updated or obsoleted by other RFCs.  I agree with Warren's
> comment that it would make a good living document, if IETF had such things.
> 
> In terms of reading the document, I noted that it uses quite a lot of acronyms
> that I was not immediately familiar with and that are not defined in the
> document.  Perhaps the document could be improved by having a short terminology
> section?  The acronyms that didn't appear to be defined include CRL, INR, CA,
> ROA.
> 

This document is intended for implementors or operators who have already read RFC 6480, which we mentioned in first paragraph of the Introduction. Thus we expect readers already know those acronyms and related concepts.


> 4.2.1.  Manifest
> 
>   To determine whether a manifest is valid, the RP is required to
>   perform manifest-specific checks in addition to those specified in
>   [RFC6488].
> 
> I found the above paragraph as being unclear, in that I don't know what "those"
> is referring to, and hence I suggest more clearly identifying “those” checks.
> 

In this context "those" refers to the generic signed object checks described in 6488. We will improve this sentence by stating that explicitly.

> Finally, I agree with Alvaro's comment related to section 4.3:  This document
> probably shouldn't be giving recommendations.  Perhaps better to just keep this
> as "However, most RP software ignores such objects.", or combine it with the
> previous sentence.
> 
> 

My co-author Steve has responded to Alvaro in terms of deleting the recommendations. 

Di