Re: [sidr] AD Review of draft-ietf-sidr-slurm-04

Di Ma <madi@zdns.cn> Tue, 06 February 2018 03:09 UTC

Return-Path: <madi@zdns.cn>
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 26DD612DA49; Mon, 5 Feb 2018 19:09:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.234
X-Spam-Level:
X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no 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 OmnOhWjiDp5G; Mon, 5 Feb 2018 19:09:26 -0800 (PST)
Received: from smtpbg327.qq.com (smtpbg327.qq.com [14.17.43.158]) (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 C2EFA12DA46; Mon, 5 Feb 2018 19:09:24 -0800 (PST)
X-QQ-mid: bizesmtp8t1517886536tuh8c6bq7
Received: from [192.168.216.94] (unknown [202.173.9.211]) by esmtp4.qq.com (ESMTP) with id ; Tue, 06 Feb 2018 11:08:55 +0800 (CST)
X-QQ-SSF: 00400000004000F0FG30B00A0000000
X-QQ-FEAT: lRUSrEWtKQDZhYAXFGWC1TMlJKQxkHiHXmaYuUgTOBKat4O/6g4atfNyDT1OU tqB/2kpl/NsBhOOKF2Vy9ChpJbCfyNSS7F8ALmZKHAeyyzTv9K3DlwiKqa56cop7mMG8Wkx ZfPjPg8Oulj6jUQfU34n3AIPXyd8vOtrFwCNofuB++wOIUPcWB1Pq6tmcWBs5CyHJXQLDXj KjU11vix1tDjm2aKsrxnxVjWLO4TxBc8Ms9wSVOJIAlIYn+mQ01ZFo9BhLvYE90Xl8kY8H5 dy5nBJ6HFNI/175+5SXaCps+9uv4QyU4DDOWbZwdUIsOow
X-QQ-GoodBg: 2
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
From: Di Ma <madi@zdns.cn>
In-Reply-To: <CAMMESsz1u-WNYw7s28khPRZ2s7kdFCdNNR6s6apky_637Q9gyg@mail.gmail.com>
Date: Tue, 6 Feb 2018 11:08:55 +0800
Cc: Chris Morrow <morrowc@ops-netman.net>, draft-ietf-sidr-slurm@ietf.org, sidr-chairs@ietf.org, sidr@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <3E39EC57-A0C2-4CB7-8563-F5D9F9C64291@zdns.cn>
References: <CAMMESsw1i_Am0UOS0Tx6yfz7kb_jsaxhMZtu5rcsoM4cDeVfkw@mail.gmail.com> <7487730B-1125-45FD-970B-0A6407129BEB@zdns.cn> <CAMMESsz1u-WNYw7s28khPRZ2s7kdFCdNNR6s6apky_637Q9gyg@mail.gmail.com>
To: Alvaro Retana <aretana.ietf@gmail.com>
X-Mailer: Apple Mail (2.3445.5.20)
X-QQ-SENDSIZE: 520
Feedback-ID: bizesmtp:zdns.cn:qybgweb:qybgweb18
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/1Pm--Ef10uR7eOI_JVDDsMdsN5A>
Subject: Re: [sidr] AD Review of draft-ietf-sidr-slurm-04
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.22
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: Tue, 06 Feb 2018 03:09:31 -0000

Hi, Alvaro,

A new version (-05) has been submitted for you to review.

The draft is updated based on the comments from you and Sriram.

And it places a more strict limit on the slurmVersion JOSN member compared to the previous version by saying:  

	“Future additions to the specifications in this document MUST use an incremented value for the “slurmVersion” member."


Di


> 在 2018年1月31日,23:39,Alvaro Retana <aretana.ietf@gmail.com>; 写道:
> 
> Di:
> 
> Hi!
> 
> Thanks for your prompt reply.  I look forward to an updated draft.
> 
> Alvaro.
> 
> On January 31, 2018 at 10:18:57 AM, Di Ma (madi@zdns.cn) wrote:
> 
>> Hi, Alvaro, 
>> 
>> Thanks for your comments. 
>> 
>> Please see my responses in lines. 
>> 
>> > 在 2018年1月30日,02:21,Alvaro Retana <aretana.ietf@gmail.com>; 写道: 
>> >  
>> > Dear authors: 
>> >  
>> > I just finished reading this document. 
>> >  
>> > I have some comments (below) that should be easy to address — please take a look. I need you to address the References before I start the IETF Last Call because of the DownRef to rfc6483. 
>> >  
>> > Thanks! 
>> >  
>> > Alvaro. 
>> >  
>> >  
>> >  
>> > Major: 
>> >  
>> > M1. Section 3.1: I'm not sure what the Normative result is form this piece of text: "JSON members that are not defined here MUST not be used in SLURM Files, however Relying Parties SHOULD ignore such unrecognized JSON members at the top level, while any deviations from the specification at lower levels MUST be considered an error." (s/MUST not/MUST NOT) If the not defined members MUST NOT be used, when would the RPs not ignore (or even better, treat as errors) them? IOW, why use SHOULD instead of MUST? 
>> >  
>> 
>> We authors think MUST is better than SHOULD. 
>> 
>> And we would like to update section 3.1 saying: 
>> 
>> "This document describes responses in the JSON [RFC7159] format. JSON members that are not defined here MUST not be used in SLURM Files and additional top-level members MUST be defined in RFCs that update this document. Relying parties MUST ignore unrecognized JSON members at the top level, while any deviations from the specification at lower levels MUST be considered an error.” 
>> 
>> Here is the consideration:  
>> The current document describes local exceptions with regards to ROAs and Router Certificates, which are significant to local control of routing. The thought here was that we would leave an option for future other ’top-level’ elements to describe local exceptions with regards to other (future) RPKI objects as long as they have fundamental effect in routing control , while maintaining backward compatibility. But this is not explicit in the document as written. The risk here, as written, is that implementations can just add stuff at will for their own purpose and we can end up with the same member name being re-used. 
>> 
>> 
>> >  
>> >  
>> > M2. Section 4.2: "Before an RP configures SLURM files from different source it MUST make sure there is no internal conflict among the INR assertions in these SLURM files. To do so, the RP SHOULD check the entries of SLURM file..." I think there's a Normative mismatch: "MUST make sure...no...conflict" vs "SHOULD check the entries"; the SHOULD leaves the door open to not always checking -- are there cases when the entries wouldn't be checked *and* the MUST can still be guaranteed? It seems to me like both keywords should be MUST. 
>> 
>> Yes.  
>> 
>> You are making sense here.  
>> 
>> >  
>> >  
>> > M3. Section 6: "...but if the RP updates its SLURM file over the network, it MUST verify the authenticity and integrity of the updated SLURM file." Please indicate that the mechanism to update files, and the authentication/integrity verification are outside the scope of this document. 
>> 
>> Agreed.  
>> 
>> We are going to add: 
>> 
>> "Yet the mechanism to update SLURM file to guarantee authentication and integrity is out of the scope of this document. " 
>> 
>> Besides, we need to change ‘source’ to ‘sources’ :-) 
>> 
>> >  
>> >  
>> > M4. References: 
>> >  
>> > M4.1. s/I-D.ietf-sidr-bgpsec-overview/rfc8205 ...and should be Normative. 
>> >  
>> > M4.2. I believe the following references should also be Normative: ietf-sidr-rpki-rtr-rfc6810-bis/rfc8210, rfc6483, rfc6810, rfc6811 and rfc7159. 
>> >  
>> > M4.3. [minor] Please update the references according to the Nits [1]. 
>> >  
>> > [1] https://tools.ietf.org/idnits?url=https://tools.ietf.org/id/draft-ietf-sidr-slurm-04.txt  
>> >  
>> >  
>> 
>> Agreed.  
>> 
>> >  
>> > Minor: 
>> >  
>> > P1. "Relying party software MAY modify other forms of output in comparable ways, but that is outside the scope of this document." If it’s out of scope, then there shouldn't be any Normative language. s/MAY/may 
>> 
>> Agreed. 
>> 
>> >  
>> > P2. “Locally Added Assertions" are sometimes called "Locally Adding Assertions". 
>> 
>> We authors are going to change 4.1 and 4.2 to say “Locally Added Assertions” because we refer to the elements. 
>> 
>> The lower case “locally adding assertions” in 3.2 is fine, because it describes an action. 
>> 
>> >  
>> > Nits: 
>> >  
>> > N1. s/control make use of RPKI data/control use of RPKI data 
>> 
>> Agreed. 
>> 
>> Di
> _______________________________________________
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr