Hi Di, This addresses my concerns thanks! Yours, Daniel -----Original Message----- From: Di Ma [mailto:madi@xxxxxxx] Sent: Tuesday, February 27, 2018 6:14 AM To: Daniel Migault <daniel.migault@xxxxxxxxxxxx> Cc: secdir <secdir@xxxxxxxx>; ietf@xxxxxxxx; draft-ietf-sidr-slurm.all@xxxxxxxx; sidr@xxxxxxxx Subject: Re: [sidr] Secdir last call review of draft-ietf-sidr-slurm-06 Daniel, Thanks for your review. Please see my responses in lines. > 在 2018年2月20日，23:00，Daniel Migault <daniel.migault@xxxxxxxxxxxx> 写道： > > Reviewer: Daniel Migault > Review result: Has Nits > > Hi, > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > The summary of the review is Ready with nits: > > • section 1: Introduction > > However, an RPKI relying party may want to override some of the > information expressed via putative TAs and the certificates > > <mglt>It seems that TA is being used for the first time here. The > acronym should be extended to ease the reading of the document. I am > reading it as Trust Anchor.</mglt> > Yes. We will use Trust Anchor for its first use. > > • section 2. RPKI RPs with SLURM > > SLURM provides a simple way to enable RPs to establish a local, > > <mglt>It seems to me the acronym RP is used for the first time. It > seems that it should be expanded to ease the reading of the document. > I am reading it as Relaying Party.</mglt> Yes. We will use Relaying Party for its first use. > > > • section 6 Security considerations > > <mglt>I My reading is that the section catches the criticality of the > SLURM files and that network operators are already familiar > provisioning critical data. As such I believe the section is > sufficiently clear.</mglt> > > • whole document: > > <mglt>It seems that BGPSec, and BGPsec are used together. I believe > this should be harmonized to BGPsec.</mglt> We will use BGPsec throughout this document as used by RFC 8205. Di
