Re: [secdir] Secdir review of draft-ietf-i2rs-protocol-security-requirements-10

Radia Perlman <> Thu, 15 September 2016 14:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 387F712B54F; Thu, 15 Sep 2016 07:29:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id AmwdTggFFlJB; Thu, 15 Sep 2016 07:29:32 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4003:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EE0EA12B899; Thu, 15 Sep 2016 06:43:23 -0700 (PDT)
Received: by with SMTP id m11so69369417oif.1; Thu, 15 Sep 2016 06:43:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=mv7ZLuhf7nBWK7zZqY88SJG8O8Q1sr2yotAeVf5Hw7w=; b=EFppS9yFovw3TQRMtYDweUHbfK9UEKryZPt8RkYV41qe7jWyyypGQ22nI3vRil3pQ9 PUnw+Ed9PSxt7IWvikDGgZtt18O4xJCFcMWPJeX2RjDkL2pTRXT05vWGCeVaRs9J7Bjh A21912rx3h2HZX7buozQkK7fBy4dU+64Z44mA6Wvhg13otadmEsxtsWz1H+qhle/aYE9 OONHDG7i4RzRE+1SDKa5MhYGbmSW97zW2yTzoew4FJUGdlyd0TgFC22LAoYPlJaCJ5dV r4isO+Da90XJ9kC0gOishJ+ba6BBf6S+uT5UcqVbnSWiRBEslPZI9F9EJhO8OZHRiYuj G5pQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=mv7ZLuhf7nBWK7zZqY88SJG8O8Q1sr2yotAeVf5Hw7w=; b=COHowaCTV5JuY3GAHhCdGCBzshd9KbMKnHunU/Eq5wFFIEH3wvh2WRpfY/36kwFYTp ck++IW1z4paeMkP6YbZGaIGZBWGWNUKBbINuPnInHAs/QU1X5gXmdNTIoWKLY6nrgHFB 2N1MhnNQwW9sbG9/hxIZrtx/q1gC8vzE8bzkI2zsrJ+UTNolqY4c0sdt28SwDgidlVp5 TQ1lH2D5PTBh7JFpcnvS//QKMofDn+PQloBTVtWdSP+etkzAetXF6M2pcXx6cNRZwWyB CqhbYk9M0Ee+33SCpZzRqv7ZKNuUNsC9im9jOmFdcainlK6ooeAuhn4DG+sog96sgycs 0ZlQ==
X-Gm-Message-State: AE9vXwNBA7QxHW3kLe+BEJQWP19o38AM1ra02D//sm/Unj6icVG0sC/QHfYboq2k5wL+LJz8rX40y5V2ckQeXA==
X-Received: by with SMTP id o82mr7846996oif.72.1473947003313; Thu, 15 Sep 2016 06:43:23 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Thu, 15 Sep 2016 06:43:22 -0700 (PDT)
From: Radia Perlman <>
Date: Thu, 15 Sep 2016 09:43:22 -0400
Message-ID: <>
To: "" <>, The IESG <>,
Content-Type: multipart/alternative; boundary="001a113d67588d1042053c8c07c0"
Archived-At: <>
Subject: Re: [secdir] Secdir review of draft-ietf-i2rs-protocol-security-requirements-10
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 15 Sep 2016 14:29:37 -0000

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

Document editors and WG chairs should treat these comments just like any
other last call comments.

I previously reviewed version 6, and they addressed my concerns, so I don't
have too much to say, but here are some comments that are just editorial,
and so fine to ignore.


Section 3.2 is called "New Security Features", though I'm not sure all the
features specified in the section are really secure features, such as
priority.   Or "an insecure protocol for read-only data constrained to
specific standard usages". Is that a security feature? Perhaps "New
features related to security"


In section 4.6 " The I2RS Architecture [RFC7921] defines a role or security
role as specifying read, write, or notification access by a I2RS client to data
within an agent's data model."

I'm not sure I'd say that the definition of a role is "specifying type of
access". Perhaps a definition of a role might be "a method of making access
control more manageable by creating a grouping of users, so that the access
controls can be specified for the role rather than for each of the
individuals." Though perhaps it's the word "defines" that's troubling me,
and instead it could be "RFC7921 specifies access control for a group as
being read, write, or notification...."